feature request #6794
Updated by Andreas Müller almost 7 years ago
Terms, terms structures and term collections need to be improved. Currently the only structures we have for terms are vocabularies (ordered and unordered) and part-of and kind-of relations, where for each term only exactly one parent kind-of and one parent part-of is allowed. Further more we do have FeatureTree and -Node as structure but only for features.
Generally what we need are
1. containers to group terms in collections, where each term might be part of many collections. how ever it is probably a good idea to let a term belong to exactly one vocabulary.
2. structures to sort terms also in the above containers
3. structures to build term trees according to relationship types like part-of and kind-of (do we also need mixed trees? does it make sense)
4. concept relationships between terms similar to taxon relationships with a relationship type based on set semantic (taxon relationship types can be reused) or other semantic
To achieve this we could do the following
* Open FeatureTree to all terms, rename it TermTree, add termtype to it to define what kind of term is handled (but discuss if a tree could also have different types included, e.g. leaves could be of different type than inner nodes (SDD)), so we could further define termtype, e.g. by being a set or defining different types for root, inner nodes and leaves, ...). These trees can also be used for sorted lists and maybe even for unordered sets of
terms. FeatureNodes may be renamed to TermNode (1, 2, 3)
* Common base class (or at least interface) TermCollection for vocabularies and TermTree to easy retrieve term collections available to choose from. (1)
* New class TermRelationship that combines terms with a relationship and relationship type, similar to taxon relationships
A general problem is when should a term be referenced directly and when should we use a term mode which is more or less a wrapper around a term which is a term within a given collection. We need this for 2 and 3 somehow (even if for 2 we only have a Set/List on TermCollection side on relational level we still need an M:N table as a term can be part of >1 such collections. If such a table is needed we can also make it a class and attache some more attributes if required.
Term relationships could work without such a TermNode but then we have different structures to define relationships between terms, one that uses term nodes as source and target of the relationships and one directly linking to terms, and if we keep the current part-of and kind-of structure a 3rd one that linking directly from one term to another (source information - "who says this is a child" is difficult to handle in this).
The simplest solution would be to only use TermNode for all relations. But this might be an overhead and also the handling in tree structures is still different to undefined relationships as the tree structure has a term as source but a node as target while general relationships have either both terms or nodes.
We could also consider nodes and relationships to be very similar, one handles a structure where each node can only be one time part of a relationship within a given graph (however in theory it is possible that a term is source for many relationships in this graph as terms may have multipe nodes), but these graphs are difficult to travers . Relationships require alternating traversion, from rel to term to rel to term ...
But as they differ only in the target type we may have them with a common base class (but then TermRelationship can not inherit from RelatioshipBase!) and store in the same table.
This makes it easy to query all terms belonging to a TermCollection as such a base class may have the attribute "termCollection" similar to current "featureTree" in FeatureNode or "classification" in TaxonNode. This is a unidirectional relationship as it may be a huge set. An exception might be terms belonging to a vocabulary as they directly point to there vocabulary (or can this be handled differently? We could also use something like TermNode but this is overhead and not necessary
Another open question is if we want to allow any kind of structure within vocabularies. Probably it is better to not allow semantic structure as this could lead to inconsistency. But purely to make terms easier to find it might be helpful to use hierarchies in large vocabularies.
For consistency it might be helpful to also use a term tree for this, algorithms may only be implemented once then. However, the model becomes more complex then with each term being represented by 2 objects instead of one. The first representing the term, the second representing its positions in the vocabulary.
If we don't have a hierarchy structure within vocabularies, vocabularies with existing structure such as TDWG areas may require an extra graph to represent the hierarchie, which is maybe not wanted. Hierarchy might become an optional attribute of a vocabulary, with still each term directly linking to the vocabulary but optionally being part of a tree which the vocabulary holds the root for.
### Questions
What about inapplicableif and onlyapplicableif, can this be used for ohter term types too, or do we still need special FeatureNodes or simply don't use these fields for other term nodes.