feature request #6794
Improve term structure
20%
Description
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
- 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.
- structures to sort terms also in the above containers
- 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)
- 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 node 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.
Related issues
Associated revisions
ref #6794 remove setRoot from FeatureTree
ref #6794 add termType to FeatureTree and FeatureNode
ref #6794 Fix termType comparison
ref #6794 Adapt taxeditor to model changes (feature tree/node generics)
ref #6794 Add generics to FeatureNode and FeatureTree
ref #6794 Add termType check to DefinedTermBase and TermVocabulary
ref #6794 fix early setting of termType during term loading
ref #6794 fix termType settings in deleteTerms test and clean it up
ref #6794 deproxy term of feature node
ref #6794 adapt FeatureTreeController property path to new FeatureNode structure
ref #6794 remove setRoot from FeatureTree
ref #6794 add termType to FeatureTree and FeatureNode
ref #6794 Fix termType comparison
ref #6794 Add generics to FeatureNode and FeatureTree
ref #6794 Add termType check to DefinedTermBase and TermVocabulary
ref #6794 fix early setting of termType during term loading
ref #6794 fix termType settings in deleteTerms test and clean it up
ref #6794 deproxy term of feature node
ref #6794 adapt FeatureTreeController property path to new FeatureNode structure
ref #6794 add TermRelationshipType
ref #6794 add TermRelationshipType to test data
ref #6794 adapt TermsDataSet-with_auditing_info in some packages after merge problem solved
ref #6794 add term relation type to TermType and fix TermRelationType class
ref #6794 add TermRelation and TermRelationBase
ref #6794 add TermRelation and rename FeatureNode -> TermTreeNode
ref #6794 rename TermVocabulary table to TermCollection and remaining rename FeatureNode -> TermTreeNode
ref #6794 update script for name changes in FeatureNode and TermVocabulary
ref #6794 change FeatureTree to TermTree
ref #6794 add TermCollection and subclasses including TermTree
ref #6794 adjust hibernate configuration to new TermCollection and adjust test data
ref #6794 update script for graph_id and root_id
cleanup and ref #6794 rename TermTreeDaoImpl
ref #6794 fix FeatureNodeServiceImplTest
ref #6794 move term relations down to TermCollection
ref #6794 add TermRelation and rename FeatureNode -> TermTreeNode
ref #6794 change FeatureTree to TermTree
ref #6794 add TermCollection and subclasses including TermTree
ref #6794 adapt TermCollection test data to boolean values in TermCollection
ref #6794 remove references to TermVocabulary.iterator()
ref #6794 change schema version and add missing attributes to updateScript
ref #6794 FeatureTreeMover first implementation (not yet ready)
ref #6794 update some imports to model changes and add ITermTree
ref #6794 add TermRelation and rename FeatureNode -> TermTreeNode
ref #6794 change FeatureTree to TermTree
ref #6794 add TermCollection and subclasses including TermTree
cleanup and ref #6794 rename TermTreeDaoImpl
ref #6794 add TermRelation and rename FeatureNode -> TermTreeNode
ref #6794 remove FeatureTree class
ref #6794 remove FeatureTree from hibernate.cfg
ref #6794 remove duplicate TermRelationshipType in test/hibernate.cfg.xml
ref #6794 minor adaptations of tests
ref #6794 finalize FeatureTreeMover (update treeindex)
ref #6794 rename TermTreeNode -> TermNode
ref #6794 rename TermTreeNode -> TermNode
ref #6794 rename getFeatureNode -> getTermNode in cdmlib-print
ref #6794 rename TermTreeNode -> TermNode
ref #6794 rename some parameters, methods and classes
ref #6794 add TermNodeService and TermTreeService and make FeatureXXX services deprecated
ref #6794 ignore FeatureTest
ref #6794 remove FeatureTree from some hibernate.cfgs again
ref #6794 add TermTreeService and TermNodeService to httpInvokerServices
ref #6794 adapt jsonConfigurations.xml from FeatureTree/Node -> TermTree/Node
ref #6794 some adaptations in Jaxb to FeatureTree -> TermTree
ref #6794 javadoc update FeatureTree -> TermTree
ref #6794 delete FeatureDao
ref #6794 remove FeatureNodeService from BatchValidationUtil
ref #6794 adapt TaxEditor to new term structure (rename FeatureNode and FeatureTree)
ref #6794 Fix compile error
ref #6794 rename IFeatureTreeDao in ITermTreeDao
ref #6794 rename TermTree.NewInstance and set old version to deprecated
(cherry picked from commit 08b758e2bfba66c82fbc5a636e455edcccb9fa11)
ref #6794 rename other TermTree.NewInstance methods and set old version to deprecated
ref #6794 Replace FeatureTreeService with TermTreeService
ref #6794 TermTreeNode-> TermNode in cdmlib-apps
ref #6794 Fix potential ClassCastException
ref #6794 Add progress monitor break point
ref #6794 Fix endless loop in OWL export
History
#1 Updated by Andreas Müller over 3 years ago
- Description updated (diff)
#2 Updated by Andreas Müller over 3 years ago
- Description updated (diff)
#3 Updated by Andreas Müller over 3 years ago
- Description updated (diff)
#4 Updated by Andreas Müller over 3 years ago
- Target version changed from Unassigned CDM tickets to CDM UML 5.0
#5 Updated by Andreas Müller over 2 years ago
- Priority changed from New to Highest
#6 Updated by Andreas Müller over 2 years ago
- Target version changed from CDM UML 5.0 to CDM UML 5.5
#7 Updated by Andreas Müller almost 2 years ago
- Related to feature request #8123: Make available features a DB preference added
#8 Updated by Andreas Müller almost 2 years ago
- Related to task #7515: TypeDesignationStatusComparator to sort by vocabulary first and then by term order added
#9 Updated by Patrick Plitzner almost 2 years ago
- Related to feature request #8146: Adapt taxeditor UI to structure and property term type added
#11 Updated by Andreas Müller almost 2 years ago
Current idea for a solution:
Collections:
- Common base class TermCollection(Base) for all Vocabularies and Graphs (Trees, Lists, Relationship Graphs)
- TermVocabulary: has a Set of Terms
- OrderedTermVocabulary: like TermVocabulary but with additional TermTree functionality, where all terms are at the same time terms within the TermTree, allows to define a Vocabulary and its default feature tree at the same time
- TermTree: like current FeatureTree, for sets, lists and ordered and unordered trees
- TermGraph: Set of TermRelationships
- Attributes for trees: orderRelevant, allowsDuplicates, isFlat; for graphs: directed
- common method: getElements
Relationship:
- common base class TermRelationshipBase
- Relates to exactly 1 TermCollection
- TermNode (or TermTreeNode) for hierarchical and flat structures, relates a child term to the parent/root node, allows tree index
- TermRelationship for Graph structure, relates 2 terms (child, relatedToTerm)
Terms:
- remove OrderedTermBase
- term belongs to single vocabulary
- term has multiple TermRelationshipBases
Others:
- Collections and TermNode do have count cache
Open issues:
- root = collection? => difficult due to inheritance from IdentifiableEntity
- how to call "child" in TermRelationshipBase (fromTerm, child, baseTerm)
- need to distinguish Term.fromRelationships and Term.toRelationships?
- interface for subtrees as they are also term collections
#12 Updated by Andreas Kohlbecker almost 2 years ago
- Related to task #8166: Adapt dataportal to term structure changes added
#13 Updated by Andreas Müller over 1 year ago
- Related to bug #8251: LazyInitializationException (LIE) in featureTree webservice added
#14 Updated by Andreas Müller over 1 year ago
- Related to feature request #8241: Rename FeatureTreeEditor to TermTreeEditor added
#15 Updated by Andreas Müller over 1 year ago
- Target version changed from CDM UML 5.5 to CDM UML 5.15
#16 Updated by Andreas Müller over 1 year ago
- Status changed from New to In Progress
- % Done changed from 0 to 20
#17 Updated by Andreas Müller over 1 year ago
- Target version changed from CDM UML 5.15 to CDM UML 5.8
#18 Updated by Andreas Kohlbecker over 1 year ago
- Related to task #8405: Adapt cdm-vaadin to term structure changes added
#19 Updated by Andreas Müller over 1 year ago
- Related to bug #8407: Fix "FeatureTest" added
#20 Updated by Andreas Kohlbecker over 1 year ago
- Related to task #8434: Change FeatureTree contollers to TermTree controllers added
#21 Updated by Andreas Kohlbecker over 1 year ago
- Related to feature request #8432: Improve "default" feature tree handling added
#22 Updated by Andreas Kohlbecker over 1 year ago
- Description updated (diff)
#23 Updated by Andreas Müller over 1 year ago
- Related to feature request #8474: Make TermCollection.orderRelevant usable for TermTrees added
#24 Updated by Andreas Müller over 1 year ago
- Related to feature request #8476: Implement support for TermCollection.isFlat in TaxEditor added
#25 Updated by Andreas Müller over 1 year ago
- Related to feature request #8477: Implement support for TermCollection.allowDuplicates in TaxEditor added
#26 Updated by Andreas Müller over 1 year ago
- Target version changed from CDM UML 5.8 to CDM UML 5.15
#27 Updated by Andreas Müller about 1 year ago
- Related to task #8466: Delete FeatureTree tables added
#28 Updated by Andreas Müller about 1 year ago
- Related to feature request #8647: Allow selecting named areas, ranks, presence-absence terms from term trees/collections added
#29 Updated by Andreas Müller about 1 year ago
- Related to feature request #6849: [DISCUSS] How to handle "kind of" term creation in TermEditor added
#30 Updated by Andreas Müller 7 months ago
- Target version changed from CDM UML 5.15 to CDM UML 5.19
#31 Updated by Andreas Müller 2 months ago
- Blocks feature request #9305: Include additional TypeDesignationStatus sort order (term tree) in CDM terms added
#32 Updated by Andreas Müller 3 days ago
- Related to feature request #9409: [Decision] Which terms should be editable in term tree editor (and vocabulary editor) added