Glossary of terms

This defined vocabulary aims at providing all essential terms to describe datasets of functional trait measurements and facts for ecological research. The vocabulary builds on the Darwin Core Standard and it’s extensions (terms of DWC are referenced thus in field ‘Refines’; the full Darwin Core Standard can be found here: http://rs.tdwg.org/dwc/terms/index.htm).

The glossary of terms is ordered into a core section with essential columns for trait data, extensions which are allowing to provide additional layers of information, as well as a vocabulary for metadata information of particular importance for trait data.

Another section provides defined terms and structure for trait Thesauri, i.e. lists of trait definitions.

We provide four extensions of the vocabulary, that allow for additional information on the trait measurement.

• the Taxon extension provides further terms for specifying the taxonomic resolution of the observation.
• the Occurrence extension contains information on the level of individual specimens, such as date and location and method of sampling and preservation, or physiological specifications of the phenotype, such as sex, life stage or age.
• the MeasurementOrFact extension takes information at the level of single measurements or reported values, such as the original literature from where the value is cited, the method of measurement or statistical method of aggregation.
• The BiodiversityExploratories extension provides columns for localisation for trait data from the Biodiversity Exploratories sites (www.biodiversity-exploratories.de).

This glossary of terms is available as

• this human-readable reference (html file), including commentaries and further definitions
• a csv table file (the ‘source’ file, TraitDataStandard.csv)
  
• a machine readable RDF ontology file, compliant with semantic web standards accessible via an API (produced by and hosted on GFBio Terminology Server, coming soon!)

Core traitdata terms

For the essential primary data (trait value, taxon assignment, trait name), the trait data standard recommends to report the original naming and value scheme as used by the data provider. However, to ensure compatibility with other datasets, the original data provider’s information should be duplicated into standardized columns indexed by appending Std to the column name. This ensures compatibility on the provider’s side and transparency for data users on the reported measurements and facts, and enables checking for inconsistencies and misspellings in the complete dataset provided by the author. If provided, the standardized fields allow merging heterogeneous data sources into a single table to perform further analyses. This practice of double bookkeeping of trait data has successfully established for the TRY database on plant traits, for instance (Kattge et al. 2011. TRY – a global database of plant traits. Global Change Biology, 17, 2905–2935).

By linking to (public) ontologies via the field taxonID, further taxonomic information can be extracted for analysis. Alternatively, taxonID may also link to an accompanying datasheet that contains information on the taxonomic resolution or specification of the observation.

Similarly, linking to trait terminologies (a ‘Thesaurus’) via the field traitID allows an unambiguous interpretation of the trait measurement. If no online ontology is available, an accompanying dataset should specify the trait definition. For setting up such a Thesaurus, we propose the use of terms provided in section ‘Traitlist’ below.

Metadata vocabulary

For datasets collate from multiple other datasets There is the set of information that applies to the entire trait-dataset, which classifies them as metadata.

To retain the rights of the original data contributor, the field rightsHolder states the person or organization that owns or manages the rights to the data; bibliographicCitation states a bibliographic reference which should be cited when the data is used; and license specifies under which terms and conditions the data can be used, re-used and/or published. This information always applies to one single fact or measurement,

Further information on the larger dataset which originally contained this entry can be stored in datasetID, datasetName, author . These columns should hence give credit to the person who compiled the original dataset and signs responsible for the correct identification and reporting of the rights holder. These information usually may be kept in the metadata of the dataset, but if datasets from different sources are merged, those should be referred to by a unique identifier (datasetID) or be reported as additional columns in the merged dataset (author, license, …; see Dublin Core Metadata standards, Ref).

Since trait data are of great use for synthesis studies, information about how the data may be distributed, re-used and attributed to are of particular importance for trait datasets. Most researchers encourage re-use of their published datasets while making sure they are sufficiently credited. The use of permissive licenses for traitdata publications, such as Creative Commons Attribution or Creative Commons Zero/Public Domain release, has been established as the gold standard.

Individual measurements and facts will likely already belong to a larger set of traits or a separate trait database before they are added to a combined trait database. To retain the rights of the original data contributor, the field rightsHolder states the person or organisation who owns or manages the rights to the data; bibliographicCitation states a bibliographic reference which should be cited when the data is used; and license specifies under which terms and conditions the data can be used, re-used and/or published. This information always applies to one single fact or measurement, further information on the larger dataset which originally contained this entry can be stored in datasetID, datasetName,authorLastname and authorFirstname. These columns should hence give credit to the person who compiled the original dataset and signs responsible for the correct identification and reporting of the rights holder.

These data are required when combining datasets from different sources. We suggest integrating a datasetID referencing to an external data sheet or adding columns to the dataset to keep important information about authorship and terms of use at the measurement level.

Terms for Thesauri

A trait thesaurus or ontology assigns descriptive trait names with A) an unambiguous definition of the trait and B) an expected format of measured values or reported facts, and might additionally provide C) semantic relationships for deriving a hierarchical or tree-based classification of traits.

Traits are not only defined in terms of their interpretation, but are ideally also standardised in terms of numerical units and, even more important, the use of harmonized factor levels. This is challenging, given the range of data types that fall within datasets of functional traits. Numerical values represent measurements of length, volumes, ratios, rates or timespans. Integer values may apply to count data (e.g. eggs per clutch). Binary data (encoded as 0 or 1) or logical data (coded as TRUE or FALSE) may apply to qualitative traits such as specific behaviour during mating (e.g. are territories defended) or specialisation to a given habitat (e.g. species restricted to relicts of primeval forests). Many traits are categorical and allow for a constrained set of factor levels, such as sex differences in wing morphology (both sexes winged, both sexes unwinged, only males winged, only females winged) or unconstrained entries such as color. Categorical traits often are ordinal, i.e. they have a logical sequence as in the case of life stages or hibernation stages, or habitat preference traits such as horizontal stratum use. Finally there are specific formats of multivariate trait values, e.g. x-y-z coordinates of a landmark measured in a standardized 3D space [ref] or relative abundance of chain-lengths in biochemical compounds []. To cope with this variety of data types, definitions should refer to other well-defined terms of other ontologies that describe standard units, morphological body parts, protein characteristics (Protein Ontology) or chemical terms (e.g. the ChEBI, http://www.obofoundry.org/ontology/chebi.html).

Online ontologies extend into (machine readable) semantic web resources by providing a hierarchical classification of traits or a relational tree of functional traits. Each trait definition may link to a broader or narrower term. For instance, the definition of ‘femur length of first leg, left side’ is narrower than ‘femur length’ which is narrower than ‘leg trait’ which is narrower than ‘locomotion trait’. (Ref semantic database methods) This links traits of similar functional meaning and allows cross-taxon comparative studies at the level of broader terms.

Ontologies for functional traits are being developed for different organism groups, mostly centered around certain research questions or subjects of study. To date, the TRY database takes the most inclusive approach on functional traits for vascular plants (Kattge). For some animal groups, similar approaches do exist, but few are available as an online ontology.

As a starting point for creating an ontology for functional traits, we propose the following terms for trait lists (also termed ‘Thesaurus’), to describe functional traits that are in the focus of the research project.

Using this standardized terminology will allow merging trait definitions from multiple sources. We encourage providing these lookup tables as an open resource on public terminology servers to enable a global referencing. The benefit of such classifications will increase if open Application Programming Interfaces (APIs) provide a way to extract the definitions and higher-level trait hierarchies programmatically via software tools. To harmonize trait data across databases, future trait standard initiatives should provide this functionality. Online ontologies hosted with accredited ontology servers have the advantage of providing a persistent and direct link of the term on the internet (a Uniform Resource Identifier, URI). Terminology portals or registries, such as the GFBio Terminology Service or ontobee, may provide a central host for trait ontologies.

Extension: Taxon

This section provides terms to specify taxonomic resolution and hierarchical depth of the observed measurement or fact.

Especially when only providing a ‘scientificName’ an entry in kingdom is recommended to identify homonyms. Additionally, class, order, phylum, family and genus are variables to filter the dataset by. The entry taxonRank should be specified to name the hierarchical level to which the observation applies, i.e. if data were measured on a verified instance of species “Agrotis exclamationis”, taxonRank would be “species”. If the reported fact was generali

If the dataset provides a URI within taxonID that maps to a taxonomic online reference or lookup table of an unambiguous and commonly accepted or verified species name, most of these information are redundant. They should be provided nonetheless to enable sorting and analysis by higher hierarchical levels.

Extension: Measurement or Fact

This section provides additional information about a reported measurement or fact and in most cases can easily be included as extra columns to the core dataset.

As a high-level discrimination of the source of the measurement or fact, the Darwin Core Term basisOfRecord takes an entry about the type of trait data recorded: Were they taken by own measurement (distinguish “LivingSpecimen”, “PreservedSpecimen”, “FossilSpecimen”) or taken from literature (“literatureData”), from an existing trait database (“traitDatabase”), or is it expert knowledge (“expertKnowledge”). It is highly recommended to provide further detail about the source in the column basisOfRecordDescription.

To keep track of potential sources of noise or bias in measured data, the method of measurement (measurementMethod), the person conducting the measurement (measurementDeterminedBy), and the date at which the measurement was obtained (measurementDeterminedDate) are recorded. Authors would often report aggregate data of repeated or pooled measurements, e.g. by weighing multiple individuals simultaneously and calculating an average. In these cases, recording the number of individuals (individualCount) along with a dispersion measure (e.g. variance or standard deviation, dispersion) or range of values (e.g. min and max of values observed in the field measurementValueMin, measurementValueMax) is adviced. The field statisticalMethod names the method for data aggregation (e.g. mean or median) as well as the variation or range (e.g. reporting variance or standard deviation).

For data not obtained from own measurement, the field references provides a precise reference to the source of data (e.g. a book or existing database) or the authority of expert knowledge. For literature data, the original source might report trait values on the family or genus level, but the dataset author infers and reports the trait data at species level (e.g. if the entire genus reportedly shares the same trait value). To preserve this information, the column measurementResolution should report the taxon rank for which the reported value was originally assessed.

Extension: Occurrence

This category of terms contains further information about the individual specimen or occurrence that has been observed and measured. Especially for analyses of intra-specific trait variation, this composes valuable data. It also helps tracking the methodology and primary source of the data and keep the reference to the actual specimen (e.g. for museum collections or related data analysis).

For both literature and measured data, trait values may be recorded for different sub-categories of individuals of a taxon to capture polymorphisms, for instance differentiated by sex or life stage. The template provides the fields sex, lifeStage, age, and morphotype for this distinction.

Sampling may be further specified using a unique identifier for the sampling event (eventID) which references to an external dataset. The record of a samplingProtocol may capture bias in samling methods. Further procedures and methods of preservation should be reported in preparations.

Seasonal variation of traits may be recored by assigning a date and time of sampling to the occurrence, using the fields year, month and day, depending on resolution. Further field definitions of the Darwin Core Standard can be applied instead, to refer to a geological stratum, for instance.

To capture geographic variation of traits, a set of fields for georeferencing can put the observation into spatial and ecological context (habitat, decimalLongitude, decimalLatitude, elevation, geodeticDatum, verbatimLocality, country, countryCode). The field locationID may be used to reference the occurrence to a dataset-specific or global identifier. This allows the trait data to double as observation data, e.g. for upload to the GBIF database.

For most trait data compiled from literature or expert knowledge, the level of information on an ‘occurrence’ would not apply, since no specific individual has been observed. In this case, the field ‘occurrenceID’ should be left blank in the core data. In cases where different aggregate ranges or averages are reported for male and female individuals, the columns sex or developmental stage may be used without the reference to an occurrence ID.

Extension: Biodiversity Exploratories

This section records location in the context of the Biodiversity Exploratories project (www.biodiversity-exploratories.de). The field OriginExploratories flags trait measurements originating from samples in the project context. Exploratory and ExploType allow to place the sample within a region or a landscape type (Grassland or Forest). From ExploratotriesPlotID a detailled georeference can be inferred. Additional spatial resolution, e.g. on subplots, may be provided in locationID of the Occurence extension.

Trait data uploaded to the Biodiversity Exploratories Information System (BExIS) should use the vocabulary in a single-file longtable format (no DwC-Archives supported).