Project

General

Profile

Actions

feature request #10196

closed

Hybrid structure-state terms

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

Status:
Closed
Priority:
Priority14
Category:
cdm
Target version:
Start date:
Due date:
% Done:

90%

Estimated time:
Severity:
normal
Tags:

Description

copied from #10133#note-1

some structures can also be used as states in a character matrix. We need to decide how to handle them.
Solutions are:

  1. Duplicate them (and link to each other)
  2. Create a new term type "Structure-State" (or "State-Structure")
  3. Handle as special structures that can be used in state context, too
  4. Handle as special states that can be used in structure context, too
  5. any other

Solution 1:

  • Pro: easy to implement, mostly on data level, only the way how to link them needs to be discussed
  • Con: redundancy on all levels (editing, snynchronization, evaluation, ...)

Solution 2:

Pro: No redundancy

  • Con:
    • the current term model requires that these terms come in a separate vocabulary as vocabularies only allow terms of the same term type (and of a subtype? - needs to be checked!);
    • same problem in the structure tree (TermGraphBase);
    • same problem with state tree/list (TermGraphBase)
    • Class State preferrably changed to DefinedTerm to make StateData.state work with hybrid structures, too (also Feature.supportedCategoricalEnumerations, but maybe not a strict requirement)

Solution 3:

  • Pro: No redundancy
  • Con:
    • problem with state tree/list (TermGraphBase)
    • Class State preferrably changed to DefinedTerm to make StateData.state work with hybrid structures, too (also Feature.supportedCategoricalEnumerations, but maybe not a strict requirement)

Solution 4:

  • Pro: No redundancy
  • Con:
    • Character.structure needs to be adapted to allow a state, too
    • structure tree (TermGraphBase) needs to be adapted, to allow states, too, at least for kind-of relationships

Solution 5: ??

Some ideas:

  • maybe State (or StateData.state) needs to be much more flexibel anyway, not only for descriptions but also for other types of CategoricalData. Generally a State is an entry in a selection list for a given feature. In the most general way it could be any CdmBase. But even less general one can imagine that each DefinedTermBase could be a possible entry . So if we do want to allow this State might be only a default for values that are not available elsewhere. E.g. some databases handle endemism as separate feature while the default is to handle it as a distribution with one of the endemic status. "Endemic (for the given area)" this way could stay a distribution status (PresenceAbsenceTerm) while it can still be used as a state in CategoricalData.
    Are there any serious issues if we handle it this way?

  • The structure-state terms always seem to be kind-of structures related to their parent (NoK: Ja ich glaube so ist das)

Final solution:

  • like above states can be any defined terms now where ever they are currently used, so this is in StateData, Feature.supportedCategoricalEnumerations and FeatureState
  • in TaxEditor the Feature.supportedCategoricalEnumerations combo is extended by structure vocabularies (or collections later)

Open issues:

  • think about sub-termtype "Character States"
  • fix "TODO 10196" (2 left, but only in jaxb and sdd.out, so not so important for now

Related issues

Related to EDIT - feature request #6794: Improve term structureIn ProgressAndreas Müller

Actions
Copied from EDIT - feature request #10133: Improve ontology state vocabulariesClosedAndreas Müller

Actions
Actions

Also available in: Atom PDF