feature request #10196
Updated by Andreas Müller over 1 year ago
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: * fix "FIXME 10196" * think about sub-termtype "Character States" * fix "TODO 10196" (2 left, but only in jaxb and sdd.out, so not so important for now