The Simplified Entity Relationship Diagram can be accessed to provide clarity and aid in the understanding of the descriptions below.
The basic entity that underpins the Species+ database is a "taxon concept". A taxon concept is a unique combination of a scientific name and its corresponding author/year. Each taxon concept has an automatically generated unique numeric identifier and a “rank” property, indicating its place in the taxonomic hierarchy. "Ranks" include: kingdom, phylum, class, order, family, subfamily, species, subspecies, and variety.
Another property of a taxon concept is its name status. This property is used to differentiate between accepted names and synonyms. Both accepted names and synonyms are types of taxon concepts, uniquely identified by a numeric ID.
Accepted names have a "parent" property, whereby they can be arranged in a taxonomic tree. Synonyms do not require a parent property to be defined; they are linked to the taxonomic tree by means of a synonymy relationship, whereby a given accepted name can have several synonyms and a synonym can be linked to several accepted names.
The numeric identifiers of taxon concepts are permanent and represent the same scientific name and author/year combination at all times. It is possible for a taxon concept to undergo certain changes, such higher taxonomy changes (e.g. relocation to a different family) or name status changes (e.g. promoting a synonym to an accepted name). Yet, its identifier will remain the same.
The following entities are in place:
Taxon concepts might be subject to a number of nomenclature changes, such as splits (i.e. one taxon concept splitting into two or more taxon concepts) lumps (i.e. two or more taxon concepts lumping into one taxon concept) or name status swap (i.e. a synonym becoming an accepted name, or vice versa).The taxon concept, name status and unique identifier considerations outlined above are at the core of the nomenclature changes management process in Species+. The example below illustrates the expected effects that a split will have on the underlying structure.
Example: Elevation of the subspecies Antilocapra americana mexicana to species level, resulting in Antilocapra americana splitting into two taxa: Antilocapra americana and Antilocapra mexicana.
Effects on taxon concepts:
Effects on associated data entities:
The split may require that some information, such as common names, distribution, legislation, etc, would need to be copied or transferred from Antilocapra americana to Antilocapra mexicana. For example, historic CITES listing information might need to be copied over to the newly created species, whereas distribution information might be divided between the two newly split species according to the range of the new taxa. This transfer of data is carried out by UNEP-WCMC at the time of the nomenclature updates.
Nomenclature changes typically involve a large number of operations and a formal representation of the different types of changes is not straightforward. The API does not aim to expose that formal representation or the log of all changes performed as that would require API consumers to build complex logic around parsing and processing particular steps, and the integration would be susceptible to adjustments in the way nomenclature changes are handled.
Instead, the API exposes the current state of data with enough information to detect changes to relevant structures in the destination system. Because all operations that affect a particular taxon concept automatically update the timestamp of the last modification, API consumers will know which taxa were changed by fetching the list of taxa changed since the last run of the synchronisation mechanism. The assumption is that API consumers will store the Species+ identifier in their systems. With that in place, new taxa can be detected by the fact that a given identifier is not present in the destination database and changes to the taxonomic tree can be detected by comparing the parent property.