EDIT

• Table of contents
• Taxonomic View (Taxonomic Classification)
  • Situation In CDM v1.0
  • Solution for CDM v2.0
  • Merging of taxonomic views
  • Use Of Synonyms

Taxonomic View (Taxonomic Classification)¶

This page is thought to explain the idea of a taxonomic view in the CDM

Situation In CDM v1.0¶

In the version 1.0 of the CDM taxonomic concepts were related to each by the use of Taxon- and SynonymRelationships. The classification of taxa could be expressed by using TaxonRelationships of type "is taxonomically included in". The TaxonRelationship of this type combined 2 taxa of type Taxon with each other one of them being the parent, one being the child. Additional information like a reference (who says it is a child) could also be stored.

Some problems arised by handling taxonomic classifications this way. For example it was impossible to define the whole classification tree and especially the root taxon (or better the root taxa, explanation see below) for this tree (forest). In case of each taxon having a maximum of one parent it was possible in theory as you could traverse the whole graph of taxa and determine the root elements but for performance reason this is a deprecated way to do it and also it has the mentioned limitations.

As a work-around several methods have been implemented to retrieve the root of a taxonomic tree/classification by using queries like "Give me all taxa that do not have any parent". If you wanted to restrict your search on a special taxonomic view, you could additionally pass the sec reference of the root taxon to the method assuming that the sec reference represents more or less the taxonomic view.

This method implies that a taxonomic classification more or less uses taxa that all use the same reference. This may be the preferred way of handling taxa in the pure way (a taxon name mentioned in a taxonomic classification is something slightly different compared to the same taxon name mentioned somewhere else). However often users want to go an other way and for example "reuse" taxa. This means the same taxon can be used in different taxanomic views. Therefor the taxa of different views may have very different sec references and may also have multiple parents.

Also on the programmatic side there was a serious limitation as for performance reasons the CDM Library stored the parent of a taxon in a cache field. This definetly worked only if a taxon has not more then one taxon.

Solution for CDM v2.0¶

To overcome the problems mentioned above the following solution that separates classification from concept data is proposed for CDM v2.0.

1. Creating a new class TaxonomicView that represents one classification / taxonomic view. A taxonomic view may consist of several distinct trees as not all the parts of the classification may be known yet. Therefore there may be multiple root nodes in the view. Therefore in general the taxonomic view rather represents a forest than a tree also the idea is that the abstract objects it represents is exactly one tree contains all included taxa and there relationship.

2. Creating a new class TaxonNode that represents a taxon within its classification and also knows about its unique parent (the parent within the respective classification)

3. Deleting the taxon relationship type "is taxonomically included in" from the list of TaxonRelationshipTypes.

4. Separating business logic that handles classification logic in the Taxon class and moving it mainly to the TaxonNode class.

The resulting model (except for operations) may look like the following

!taxonomicView.png!

Merging of taxonomic views¶

Sometimes it may be needed to merge 2 taxonomic views. This may be the case when

• It shows that the 2 taxonomic views belong to the same general view but represent different and distinct parts of it. This case is easy to implement by changing the taxonomic view information of all taxon nodes of the first view to the second and accordingly updating the list of nodes in the second view. The first view will not be deleted (as it may be identifiable) but gets an attribute TaxonomicView mergedInto that points to the second view.

• It shows that 2 views are not distinct but differ in a subtree part.

E.g. there may be the Euro+Med view that includes botanical taxa and there may be some special view from Taraxacum experts ("Taraxacum view") that takes over the E+M classification but may differ in the classification for Taraxacum.

The +greedy solution+ for this use case may be that we create a new taxonomic view ("Taraxacum view"), copy all nodes from Euro+Med, and delete all subnodes of the node representign Taraxacum.

A more +sophisticated solution+ may be to create a new "Taraxacum view" that includes only Taraxacum and it's subnodes and to add to Taraxacum (1) the information what the parent node from the "Euro+Med" view is and (2) that it replaces the Taraxacum node of "Euro+Med" within the alternative "Taraxacum view". (3) In the Taraxacum view we only have to store which that the Taraxacum node is the node that connects this view to the more general "Euro+Med" view.

The later can be easily implemented by adding one attribute to the TaxonNode class that stands for the node this node replaces in some other view and by adding an attribute that points to this connection node. All other information is immanent and can easily be retrieved (e.g. the information what the higher (more general) view of this view is can be retrieved by using the connection node, from there getting the node it replaces and the view of the replaced node then is the higher view

Use Of Synonyms¶

Synonyms in general are handled on the concept level not on the classification level. Anyway some users expressed there need to use a concept defined somewhere but using a synonym name within the taxonomic view they handle.

There are different possibilities to handle this situation:

• The pure way: You create a new Taxon that consists of the taxonomic name (synonym name) you want to use and that has a concept relationship of type "is congruent to" to the concept you want to refere to. The secundum reference of the new Taxon must then be your view (or better the reference that represents your view (To be discussed: "What is the best reference to use here"))

• The pragmatic way: A TaxonNode gets an additional attribute called "nameToBeUsed" (type: TaxonNameBase) that represents the synonym name that you want to use in your classification. This way is not a proper use of the concept idea because a concept by definition is a pair of (!TaxonName, SecundumReference) so saying that a node links to a Taxon and than using another name sounds contradictionary.

• The pragmatic way 2: An alternative to the "pragamtic way" may be to store the Synonym you want to refer to instead of the TaxonNameBase. This restricts the