Open GoogleCodeExporter opened 9 years ago
Original comment by ahsan.mo...@gmail.com
on 3 Nov 2010 at 7:46
Original comment by yjaq...@gmail.com
on 25 Nov 2010 at 12:07
Original comment by yjaq...@gmail.com
on 26 Nov 2010 at 3:39
I tried to follow the steps described by Lavanya, and deleted (in the demo
version) the relationship between 'cicadas' and 'Auchenorrhyncha'. Then I tried
to create a new relationship to the concept 'Cicacidae', but the system only
shows the previous concept 'Auchenorrhyncha', and does not give the possibility
to select a different concept! However, it should be possible to browse for a
new concept and then select a new preferred term. The problem is also what
happens to the corresponding terms in other languages? In the 'recent changes'
list the relationship appears as deleted, but since the system is extremely
slow today, I was not able to validate this change. I also checked in the
development version (http://202.73.13.50:55123/agrovocdevv10i), and there
'cicadas' is still shown as non-preferred term of 'Auchenorrhyncha', but when
you click on 'cicadas' then there is NO relationship.
So, the solution should be as follows:
1. delete the existing relationship between preferred and non-preferred term.
After validation the deleted non-preferred term should not be shown anymore
under the preferred term;
2. Select a new preferred term and create relationship;
3. after validation the non-preferred term should appear under the new
preferred term.
Original comment by johannsen.gudrun2@gmail.com
on 2 Dec 2010 at 10:40
I have tried to do the steps said above by Gudrun in the development version.
I have done the following steps
I deleted the relationship between Eumycetes and fungi and did the validation,
After validation still the term 'Eumycetes' is existing under fungi which is
not correct
I suggest this problem should be given high priority.
Original comment by lavanyak...@gmail.com
on 3 Dec 2010 at 9:19
The relation hasRelatedTerm was removed between Eumycetes and fungi. But,
Eumycetes is existing under fungi as fungi is the preferred term and Eumycetes
is the non preferred term of the concept
http://aims.fao.org/aos/agrovoc/c_314. So removing only the hasRelatedTerm
relationship will not remove the term. You will have to delete the term
Eumycetes but WB only allow to deprecate the term and cannot delete completely.
Original comment by sachit.r...@gmail.com
on 13 Jan 2011 at 5:21
Here is the step to move a term from one concept to another:
1. Delete all the relationships between that term and all the other terms of
that concept.
2. Delete hasLexication relationship between that term and with the concept.
3. If that concept is preferred term, we will have to assign some another term
in the same language as Preferred term
4. Find all the term in different languages which are the translation of that
term and perform all the above actions.
(It is correct to find terms in other language that have same termcode with the
term to be deleted?)
5. Create the new term with the same label and languages in the new concept.
6. Reassign all the datatype properties to the new term from old term.
Following things has to be kept in mind for this action:
- All the term-term relationship of that term with other terms in that concept
will be lost.
- Should we keep the same termcode or assign new term code?
- What about all other datatype properties, should we move them with the term
or not? For example: hasSpellingVariant, hasFAOCode,..
- Do we need the validation for this action or restrict this action for special
users only (Like Administrator).
- As this process involves a series of actions, if rejected while validating we
will have to revert back all the values to original. But validation can handle
only one action at a time, we cannot revert back list of actions as there is no
mechanism to memorize that this process involves these many actions. There will
be the need for new workflow for validation to handle such situation.
Original comment by sachit.r...@gmail.com
on 27 Jan 2011 at 9:57
The complexity of this issue and the impacts based on the model are such that
we have decided to move it to a later version
Original comment by yjaq...@gmail.com
on 23 Feb 2011 at 3:14
Original comment by yjaq...@gmail.com
on 10 Mar 2011 at 11:52
Original issue reported on code.google.com by
lavanyak...@gmail.com
on 2 Nov 2010 at 10:55