(Dynamic) Taxon Concept¶

• Table of contents
• (Dynamic) Taxon Concept
• Introduction
• Types of Concepts
  • Description Based
  • Name Based
  • Externally defined
• Concept Borders
• Dynamic Concepts
  • Provenance
  • Changeable Data
• Dynamic Concept Attributes
• Use-Cases
  • Taxonomic backbone for other checklists/taxonomic lists
  • Taxonomic backbone for specimen data
  • Citation
• Dasta Model implications
  • Split NameUsage and TaxonConcept

Introduction¶

Taxon concepts describe a set of organisms that belong to this concept. They are used to group organisms in those belonging to the concept and those not belonging to it and they somehow describe certain characters of the organisms belonging to the concept.

Types of Concepts¶

The way how concepts are described may differ, though they finally always relate to characters of organisms or potential organisms.
However, in the way how concepts are described, the following differences exist

Description Based¶

Description based concepts explicitly define which values/states for a given character the organism may have and may not have to belong to the concept. This description may be morphological, molecular or any other as long as helps to distinguish the affiliation of an organism to the concept.
Often the description of the concept itself does not contain all characters but only those needed to distinguish it from it direct neighbors. In this case also the descriptions of the parent concepts are essential to come to a complete concept description. All descriptions of a parent concept must also be true for the given concept.
Sometimes also the additive descriptions of all child concepts are included in the given concepts definition.

Name Based¶

Name based concepts do define taxon names or groups of taxon names (homotypic groups) that belong to the concept. This works because a taxon name is always based on a type specimen (or a group of type specimens) and these specimens do have characters and also in the protologue of the name (or the names basionym) a description exists.
So indirectly name based concepts are also based on descriptions.
Named Based concepts by definition include all child concepts while parent concepts are only part of the concept as fas as the parent may defines external/neighboring concepts.
For this concept type the completeness of the homotypic groups in the synonymy is essential (but it might be a (regionally) filtered completeness)

Externally defined¶

Some concepts only refer to concepts defined elsewhere. So these concepts are not really concepts on their rather than kind of exact copies of the original concept.

Concept Borders¶

The border between 2 concepts can be described by either explicitly defining which (combination of) character states belong to the given concept (internal definition) but it can also be described by saying that certain character states do NOT belong to the given taxon or even better they belong to another (neighboring?) concept (external definition). In this case the internal definitions of neighboring concepts are explicit part of the complete definition of the given concept.

Dynamic Concepts¶

Traditionally taxon concepts are published in print publication. So they are defined by the unchangeable data explicitly mentioned in the publication or in related or referenced publications.
More recently concepts are also published online. As online publications usually are no persistent the concept definition may change over time. This makes it difficult to verify a statement like "organism A belongs to concept B" at a later time as the concept B may have changed in the meanwhile.
Therefore concepts must either guarantee that the stay persistent for long time/ever or they must clearly declare that they are not persistent.

Provenance¶

If concepts change over time it is essential for many usecases that relationships between old concepts and more recent concepts are defined.
These relationships may be defined by the well known set based relationships

• concruent (does not make much sense for concept provenance)
• included in/includes
• overlapping
• distinct

Further more it may be important to know the

• (time based) direction of the relationship

to know which concept is successor and which is the precursor. This is especially useful for usecases where someone refers to an old concept and wants a list of current concepts that are possible successors of the old concept.

At the same time it may important to know if a concept is a

• direct successor/precursor

as this way we retrieve information on the type of transformation that took place when reorganizing a set of concepts (the set of all direct successor relations and the set of all precursors of these successors define the type of tranformation that took place when a concept outdated.

Further interesting relationships might be

• deleted (a concept may be completely deleted and not transformed into another concept if it turned out to be not a valid concept, e.g. because the type specimen does not exist anymore and no similar specimen was found or because the concept has a regional filter and it turned out that the concept never existed in the given region and therefore it was fully removed from the list of current concepts)
• neighboring concepts (and explicit list of external concepts that are part of the full definition of the given concept)
  

Changeable Data¶

Not every change in a database should define a new concept. E.g. correcting a type in a name or in a description should not create a new concept.
But for users relaying on the definition of concepts it is essential to know how far a concept may change over time without the concept being marked as outdated and getting a successor concept.
So there might be exact rules, e.g. by defining that each type specimen which is directly or indirectly added or removed from a concept will result in a new concept. This is mostly an objective definition. A more subjective definition could be that a concept changes only if a type specimen is added or removed from the concept and by editorial definition it is decided that this type specimen changes the characteristics of the concept. In this case it might also be important to include information on the decision making editor into the concept.

Dynamic Concept Attributes¶

From the above we may retrieve the following attributes a Dynamic/Online Taxon Concept should have information on

• how it is defined, by secundum, by description and/or by names/homotypic groups
• how far external definitions (concepts) belong to the given concept definition and therefore also need to be available in the database as long as the given concept is available
• how far the concept definition is persistent or not
  • this may include information on which data is persistent (only the concept identifier and the provenance or all concept defining information or parts of concept defining information such as the internal definitions)
  • in detail also an expiration date (for online availability) or/and a service level agreement (7/24 availability) could be included
• how far provenance is supported for persistent concepts ** this may include information on the type of provenance
• time period in which the concept was considered being a current concept in its given context
  • this includes information if a concept is a current concept at the given time (might be computed by the number of successors being 0)
• data changing rules
• editor (important if data changing rules depend on editorial decisions)

Use-Cases¶

Taxonomic backbone for other checklists/taxonomic lists¶

E.g.

• INSPIRE
• GermanSL
• Red Lists
• tbc

Taxonomic lists like the German Red Lists or the GermanSL (for vegetation data) may want to link their taxa to (current condepts of) other taxonomies such as Euro+Med or EU-NOMEN.
They may do this by matching their names with names existing in the backbone. As long as the match is successful they can easily link to the current concept in Euro+Med.
If the name does not match because it is not (yet) included in the backbone the matching needs to be done manually if possible.

• name matches
  • if continous (on-the-fly) matching/linking is possible => persistence of concepts is not necessary => The result is a single current concept.
  • if discontinous linkage to concept => persistence and provenance is necessary => The result is a single concept (not necessarily current) and a list of possible current concepts.
  • if discontinous linkage to homotypic group persistence and provenance is not necessary => The result is a single current concept (and a list of former concepts if wanted)
• name manually matched
  • to concept = persistence and provenance necessary => The result is a single concept (not necessarily current) and a list of possible current concepts.
  • to homotypic group => persistence and prov not necessary => result is a single current concept

• concept (set of homotypic groups) matching

  • input: set of homotypic groups (if list has no homotypic information each name has its own HG)'
  • (possible) output:
    
    • a list of concepts: with a list of input HGs attached that match this concept
    • a list of HGs: with a list of input HGs(or names) matching this HG
    • list of non matching input HGs: input HGs which did not match for ANY name in the group
    • list of non matching input Names: input names that did not match, but another name it its own HG did match (so we consider the HG itself as matching)
    • name-HG mapping: a mapping for each input name to the backbone HG
    • HG-HG mapping: a mapping for each input HG to the backbone HG
    • Conflicting HGs: input HGs that map to >1 output HG

• Match updating (for discontinous linkage)

  • input: all backbone concepts currently linked to in the list; output: all concepts from the input list, that are no "current" concepts anymore with a list of possible current concepts and the relationship to them
  • input: timestamp; output: all concepts outdated since then
  • input: timestamp; output: all HGs that changed the current concept affiliation since then

• For the rare case of HGs being split in the backbone:

  • some services indicating theses splits ... (tbc)

For this usecase the completeness of names and homotypic groups is essential

Taxonomic backbone for specimen data¶

Citation¶

Dasta Model implications¶

Split NameUsage and TaxonConcept¶