Project

General

Profile

feature request #6794

Improve term structure

Added by Andreas Müller over 1 year ago. Updated 17 days ago.

Status:
New
Priority:
Highest
Category:
cdm
Target version:
Start date:
07/09/2017
Due date:
% Done:

0%

Severity:
normal

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

  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.


Related issues

Related to Edit - feature request #8123: Make available Features a DB preference New 02/22/2019
Related to Edit - task #7515: TypeDesignationStatusComparator to sort by vocabulary first and then by term order New 06/26/2018
Related to Edit - feature request #8146: Adapt taxeditor UI to structure and property term type New 02/27/2019
Related to Edit - task #8166: Adapt dataportal to term structure changes New 03/06/2019

Associated revisions

Revision 15e58dad (diff)
Added by Andreas Müller 21 days ago

ref #6794 remove setRoot from FeatureTree

Revision ffe5e099 (diff)
Added by Andreas Müller 21 days ago

ref #6794 add termType to FeatureTree and FeatureNode

Revision ba989ecb (diff)
Added by Patrick Plitzner 18 days ago

ref #6794 Fix termType comparison

Revision 2fe68f38 (diff)
Added by Patrick Plitzner 17 days ago

ref #6794 Adapt taxeditor to model changes (feature tree/node generics)

Revision c693e3b1 (diff)
Added by Patrick Plitzner 17 days ago

ref #6794 Add generics to FeatureNode and FeatureTree

Revision 86dbc0fc (diff)
Added by Patrick Plitzner 15 days ago

ref #6794 Add termType check to DefinedTermBase and TermVocabulary

Revision 64cf9d1d (diff)
Added by Andreas Müller 14 days ago

ref #6794 fix early setting of termType during term loading

Revision f4e9f32a (diff)
Added by Andreas Müller 14 days ago

ref #6794 fix termType settings in deleteTerms test and clean it up

Revision ee6886b5 (diff)
Added by Patrick Plitzner 14 days ago

ref #6794 deproxy term of feature node

Revision 30fc7ac4 (diff)
Added by Andreas Müller 13 days ago

ref #6794 adapt FeatureTreeController property path to new FeatureNode structure

History

#1 Updated by Andreas Müller over 1 year ago

  • Description updated (diff)

#2 Updated by Andreas Müller over 1 year ago

  • Description updated (diff)

#3 Updated by Andreas Müller over 1 year ago

  • Description updated (diff)

#4 Updated by Andreas Müller over 1 year ago

  • Target version changed from Unassigned CDM tickets to CDM UML 5.0

#5 Updated by Andreas Müller 10 months ago

  • Priority changed from New to Highest

#6 Updated by Andreas Müller 10 months ago

  • Target version changed from CDM UML 5.0 to CDM UML 5.5

#7 Updated by Andreas Müller 25 days ago

#8 Updated by Andreas Müller 25 days ago

  • Related to task #7515: TypeDesignationStatusComparator to sort by vocabulary first and then by term order added

#9 Updated by Patrick Plitzner 20 days ago

#11 Updated by Andreas Müller 17 days 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 12 days ago

  • Related to task #8166: Adapt dataportal to term structure changes added

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 40 MB)