Example 1 - Apply standard terms for matrices

If trait data have been collated at the species level from different literature sources or from expert knowledge, or as aggregated measurements collated from raw data, they usually are reported in a observation-level wide-table format, with a column of values for each trait recorded and a row for each species (or taxon) for which data were available. The wide-table format is widely used for the production of lookup-tables at the species level, which may either report qualitative facts (from literature or expert knowledge) or aggregated quantitative traits (averages or ranges of trait values for this taxon).

This wide-table format is straightforward for maintaining and managing new data for the data author. In terms of analysis, it allows to easily correlate traits with each other and analyse trade-offs between traits. However, wide-tables need to clearly differentiate missing data and traits not applicable to a given taxon (often filled in as ‘NA’ or dummy numbers, e.g., ‘999’). Additional information (e.g., on variation of means or literature source) may be stored in secondary columns or accompanying datasheets. When applying the data standard to wide-table data, the columns for taxa or individuals may be labelled using the terms of the ETS. Taxon concepts should be referenced to globally available concepts using URIs, e.g., by referring to GBIF Taxonomy. Taxa authors and fine-grained higher taxonomy must then be consistent with the linked concept, or may be omitted as redundant and to avoid confusion.

Remarks should be provided in a human-readable form within the table and provided with further detail in the metadata, if necessary.

For wide tables, it is essential that the multiple trait columns are labelled in unambiguous ways and be linked to trait concepts provided in the metadata or a secondary spreadsheet.

Example 2 - provide structure in long-table

In observation wide-tables, each row is centered around a single physical occurrence of a species, e.g., phenotypic variation of traits within species would usually be recorded per observation where each replicate taken on a distinct individual specimen would be recorded in a row, with the respective trait values stored in columns (see Table B1). Those data are common in investigations of evolutionary trade-offs and trait correlation, or of intra-specific variation along environmental gradients. Occurrence data would also capture phenotypic variation arising from morphotypes and sexual dimorphism. This format is the most intuitive for recording own empirical measurements and therefore is common for measured quantitative data but rarely found for reported qualitative facts obtained from the literature.

A more effective method that allows for high flexibility and easier data merging is the storage of traitdata in long-table formats (Wickham 2014; Parr et al. 2016). This data format corresponds has a row-based structure: each row contains a single measurement or fact of a specific trait, referenced to a single specimen (or one occurrence of an individual organism at a particular space and time) which is assigned to a specific taxon (see Table B2). Identifiers can provide structure and link measurements that are correlated by assigning a unique ID for each single individual. Also, multivariate trait measurements can be recorded in this format by linking multiple rows via a unique measurement identifier. Long-table datasets purport multiple advantages for data handling (e.g., filtering, sub-setting and aggregating data), visualization (e.g., plot measured values by factor variable or taxon) and statistical modelling (e.g., ANOVA for testing difference of trait value by sex) (Wickham 2014). As long-table data share a larger set of columns, merging of datasets is in most cases easier for the end-user.

However, a disadvantage of the long-table data structure is the mixing of units or even factor levels in the ‘traitValue’ column. The mixed content of this column prohibits filtering data based on their values. Data-splitting techniques or a database system are tools to disentangle the data. Note also, how the datasets become bulkier, as many information and labels are now repeated on all measurements as instances of the same individual organism (i.e., one occurrence).

Example 3 - apply ETS extensions in trait-data table

If data contain covariate information, the two-dimensional data table can cover these by adding more columns. The three extensions of the ETS complement the core terms according to different layers of metadata information: 1) the “taxon” extension includes terms to describe more details on the taxon concept applied, 2) the “Measurement or Fact” extension adds information on the methodology or context of the measurement of the trait value, and 3) the “occurrence” extension provides terms to describe the individual specimen and its observation context.

A data table for instance should report on the taxonomic resolution of the trait observation, especially if it is reported on something else than the species level (by setting taxonRank: genus). The additional terms for taxon hierarchies (kingdom to genus) would allow the data user to extract information on genera or families, but this would be redundant with an unambiguous taxon concept has being provided within taxonID. Further columns would provide detail on the measurement accuracy (measurementResolution) or the number of individuals on which an aggregated measure has been determined (by reporting individualCount: n and aggregateMeasure: ‘TRUE’). Data providers can easily contain information on sex or life stage of the specimen (using terms sex or lifeStage), or on the location of sampling (e.g., verbatimLocality, all ‘occurrence’ terms).

If data are provided in a single two-dimensional data table that applies standard terms of the ETS, this may increase readability and facilitate re-use by synthesis researchers as they do not need to process information stored elsewhere. Data tables conforming to the same data standard can be merged with ease.

Example 4 - apply ETS extensions in relational databse

Two-dimensional spreadsheets are however limited in the number and complexity of co-variates they can contain. As such, for datasets containing multi-layered information on observations, traits, taxa and environmental context, the use of relational database structures may be indicated. Relational databases help to avoid content duplication, as the core table will only maintain identifiers, that relate to secondary data tables containing multiple specifications on the identifier level. For instance, the core table may specify ‘occurrenceID’ for which specific information can be found in a lookup table. The ETS may be applied to describe columns within the individual data tables of relational databases. Compatibility with other database structures is warranted, as ETS terms map to terms of the Darwin Core Standard used in other suggested database structures for trait data, like the generic structure for plant trait databases (Kattge et al. 2011) or the TraitBank structure (Parr et al. 2016).

For publishing relational databases, it is however important to provide sufficient information on how the individual data tables are related, e.g., in a machine readable metadata specification (e.g., in EML language). Further, it must be ensured that data tables are always contained in a single data publication and are not distributed independently of each other, as this would cause issues of broken links if data are updated or lost. Both requirements are met if data are released as a packaged archive, for instance following the Darwin Core Archive specification (Robertson et al. 2009).