Tidy long-table formats (Wickham 2014) are the most predictable and compatible format for the core content of trait datasets and should be used for standalone uploads on low-threshold repositories.

Besides the core trait data (value, trait & taxon), harmonized entries should be added as duplicates (see ‘Glossary’). If data contain multi-layered information on the measurement or occurrence (including geolocation and date information), further columns may be added to the core set of columns (see description of Extensions). For reasons of reproducibility and openness, data should not be uploaded in proprietary spreadsheet formats (like ‘.xlsx’) but rather in comma-separated text files (‘.csv’ or ‘.txt’).

There are two possibilities to integrate further information to the core trait data columns:

• within the same data file: add further columns to the core dataset using column names as described in the ETS and its extensions, concerning the measurement or the occurrence of the specimen.
• in separate data files: the main file refers to additional data files via unique identifiers, encoding each individual occurrence of a species (occurrenceID), single measurements or reported facts (measurementID), locations of sampling (locationID) and sampling campaigns (eventID). It is recommended to use Darwin Core Archives (DwC-A, Robertson et al. 2009).

For chosing one or the other, the trade-off is data-consistency and readability vs. avoidance of content duplication:

For standalone dataset publications on a hosting service with only little information content beside the core traitdata columns, the first would be the preferred format, since it facilitates an analysis of cofactors and correlations further down the road. If datasets of different source are merged, the information is readily available without the risk of breaking the reference to an external datasheet. Other cases, where key data columns would be placed in the same table as the core data are traits assessed on a higher level of organisation, e.g. microbial functional traits assessed at the community level taken from a soil sample. Here, location or measurement information are in the primary focus of the investigation (see vocabulary extensions below). A general definition, whether a column describes asset data or is part of the central dataset is ill advised. Therefore, our glossary of terms and its extensions should be used to describe the scientific data according to the study context.

The latter links separate data sheets by identifiers, which has the advantage of tidy datasets and avoids duplication of verbose information (Wickham 2014). As a rule of thumb, the columns of the ‘Measurement or Fact’ and ‘Occurrence’ extension would be stored in a separate data sheet. The use of Darwin Core Archives (http://eol.org/info/structured_data_archives, DwC-A; Robertson et al. 2009) is the recommended structure for GBIF (GBIF 2017, http://tools.gbif.org/dwca-assistant/) or EOL TraitBank (Parr et al. 2016, http://eol.org/info/cp_archives). These are .zip archives containing data table txt-files along with a descriptive metadata file (in .xml format). Detailled descriptions and tools for validation can be found on the website of EOL (http://eol.org/info/cp_archives) and GBIF (http://tools.gbif.org/dwca-assistant/).

The metadata of any dataset that employs this data structure should refer to the respective version of the Ecological Traitdata Standard as “Schneider et al. 2017 Ecological Traitdata Standard v1.0, DOI: XXXX.xxxx, URL: https://ecologicaltraitdata.github.io/ETS/v1.0/”. In addition to the versioned online reference, the dataset should also cite the methods paper “Schneider et al. (in preparation) …” for an explanation of the rationale.