DiversityTaxonNames (version 1.0, 29. March 2005):
Documentation of the information model
By G. Hagedorn, M. Weiss, & D. Triebel 2005
Note: With the move to SQL server, the model documenter tool used in earlier Workbench model documentations is no longer available. As a result, this documentation is less complete and relies more strongly on graphical screen shots from the SQL-Server modeling tool. The symbols at the end of the connections between the tables correspond to "1" (key-symbol) and "n" (infinity) in standard ER-diagrams. The SQL Server data types are explained at the end of this document.
Besides the screen shots below, a Microsoft T-SQL-Script for the generation of the tables is provided.
Entity relationship diagram 1: Overview
A short introduction:
- "TaxonName" is the central entity, containing the nomenclatural information. Most items are expected to be undisputed nomenclatural facts. Some data items include editorial opinion (nomenclatural status, but also the accepted spelling which may involve orthographical or grammatical corrections as required by ICBN). However, it is expected that within a project agreement can be achieved on the information contained in TaxonName, i.e. collaborators can "correct" information without consultation.
- "TaxonHierarchy", "TaxonAcceptedName" and "TaxonSynonymy" represent a higher level of taxonomic opinion, where different editors and different digitized data sources need to be kept separate. This is achieved by making a "Project" attribute part of the primary key. Editors that wish to collaborate and form agreement may work in a single project, editors that desire to define separate opinions work in separate projects. Furthermore, if the opinion is based on published information, the reference and page number may be recorded (in ...RefText, ...RefID, ...RefDetail). The duality of representing editorial opinion and remaining true to a digitized sources causes some problems. For example, a species accepted in a referenced source may not longer be accepted by the project editors. To avoid a further complication of the model, the "IgnoreButKeepForReference" attribute (default "false") may be set to "true", indicating that the statement is true from the perspective of the referenced source, but should be ignored when representing editorial opinion.
- "TaxonHierarchy" contains information about the hierarchical position of the taxa. For each project, a name may be referred to a single parent taxon. The attribute "NameParentID" may, however, be Null, in which case "HierarchyPositionIsUncertain" should be true.
- "TaxonAcceptedName" contains the accepted names ("valid or preferred taxon names"). For each project, a name in "TaxonName" may be either be accepted (a corresponding record in "TaxonAcceptedName" exists) or not. Examples for not accepted names are synonyms of accepted names and nomenclaturally rejected names.
- "TaxonSynonymy" contains names, which are synonym to other names. Here a single name may be a synonym of multiple accepted names ("pro parte synonym"). The "pro parte" or corresponding sensu information is captured in the "ConceptSuffix" attribute, which is part of the primary key.
- "TaxonNameExternalID" and "TaxonNameExternalDatabase" document the sources of the names.
- Entities ending with "_Enum" ("TaxonNameNomenclaturalStatus_Enum", "TaxonNameNomenclaturalCode_Enum", "TaxonNameTaxonomicRank_Enum" and "TaxonNameCreationType_Enum") contain enumerated values or strings; all have the same fields shown in the last ER diagram further below.
Entity relationship diagram 2: Details
The tables shown are identical to those in diagram 1, but the arrangement had to be changed to be able to show data type and description of each column. Furthermore, some "housekeeping" fields ("LogInsertedBy", etc.) not shown in the overview diagram are included here.
Unfortunately, some labels in the diagram are in German. "Spaltenname" translates to "column name", "Datentyp-Kurzform" to "data type", and "Beschreibung" to "column description".
Entity relationship diagram 3: Template for enumeration tables
Known problems
Although "IgnoreButKeepForReference" offers some opportunities to mark information as according to reference, but not according to current opinion, it does not function properly. It is not possible to keep information about a taxon name being accepted in multiple references in the database, because NameID (but not RefID) is part of the primary key of AcceptedName. SQL Server does not support the inclusion of bit-type data in a primary key, and making RefID part of primary key is difficult because a reference may be expressed either as text, or through ID with optional text.
| Type | Description |
|---|
| binary | binary data type, length 0 to 8000 bytes. |
| char | character data type, length 0 to 8000 bytes. |
| varbinary | Variable-length binary data type, length 0 to 8000 bytes. |
| varchar | Variable-length character data type, length 0 to 8000 bytes. |
| text | Text data type (= "Memo", unlimited length). |
| nchar | Unicode character data type. |
| ntext | Unicode text data type (= "Memo", unlimited length). |
| nvarchar | Unicode variable-length character data type. |
| |
| binary | binary data type. |
| bit | bit data type (i.e. Boolean, 0 = false or 1 = true). |
| char | character data type. |
| datetime | 8-byte date/time data type. |
| smalldatetime | 4-byte date/time data type. |
| decimal | decimal data type. |
| tinyint | 1-byte integer data type (= "byte"). |
| smallint | 2-byte integer data type. |
| Int | 4-byte integer data type. |
| real | 4-byte real data type (= "single"). |
| float | 8-byte float data type (= "double"). |
We are interested in your opinion. If you see any problems with the model that you would like to bring to our attention, please contact us by sending an email to name@gmail.com, please replace name with g.m.hagedorn!
Documentation created on 29. March 2005; last update: 2005-03-30, email address revised 2010-08-05.
