Biodiversity Informatics

The Berlin Taxonomic Information Model

Central entities

Name, NameHistory, NomStatusRel, and RelName
To preserve the history of the name editing process, names are stored in two tables Name and NameHistory. The Name table contains the set of names currently in use by a system. The NameCache and FullNameCache fields contain the Latin names without and including author strings as calculated from their component fields by a trigger functions according to nomenclatural rules valid for a specific project. In addition, these cache fields can be used to capture preliminary (unstructured) names if needed (e.g. in imports). The NameHistory table is structured very similarly with a few exceptions: the name string fields preserve their value and AuthorTeam as well as BasAuthorTeam are carrying their respective content as strings and not as a pointer to the author tables. A self-referential pointer (SuccNameHistId) links a name to its successor within the editing history. An additional pointer (CurrentNameFk) gives for every name the name currently in use. (N.B.: this does not represent a synonymic relationship, but just a history of edits to the name itself).
The NomStatusRel table is used to assign one or several nomenclatural status values (e.g. 'nom. illeg.' or 'nom. nud.') to a name. The catalogue of name status values  for a given project is defined in the NomStatus table. To express relations between taxon names considered to be nomenclatural rather than a taxonomic opinion the RelName table can link arbitrary entries of the name table. The type of this relation (e.g. 'is later homonym of' or 'is basionym for') is indicated with a pointer to the RelNameQualifier table.

References
References of any kind (e.g. nomenclatural references, references for taxonomic opinions, factual data references) are accommodated in a single recurrent structure reference. By using the self referential pointer InRefFk references can be defined as part of references in the same table (e.g. article as a part of a given book). The type of a reference is indicated with a pointer (RefCategoryFk) to the RefCategory table which defines the list of reference types. Since all attributes for the different reference types are accommodated in a single entity, a client program hast to decide which attributes to use for a given reference category. Trigger functions may be used to support this process and to preserve data integrity.
Citations are created with the RefDetail table which contains a pointer to the Reference table and a field (Details) which accommodates the exact position in the reference as a string (e.g. page number, table number, record id in a database).

PotTaxon and RelPTaxon
The PotTaxon table’s primary key combines name identifiers with reference identifiers (without the reference details). This combination enables the system to preserve statements on taxa as they were given in the original information sources (e.g. status of a name or distribution information). The RelPTaxon table is used to express directed binary relations between any two entries of the PTaxon table. This includes taxonomic inclusions (i.e. the classification system) and any kind of synonym and concept relations. The type of the relation is specified in the table RelPTQualifier (as indicated with RelQualifierFk). The source of the relationship is indicated by the attribute RelRefFk.  Holding all kinds of binary relations in a single table provides a convenient and transparent way to query the links between taxa, and it greatly facilitates the implementation of client-sided navigation functions.

 

Print Page
© Botanic Garden and Botanical Museum Berlin-Dahlem, Freie Universität Berlin
Page editor, Date (this page): 08. January 2007
http://