forked from EcologicalTraitData/ETS
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathstructure.Rmd
32 lines (21 loc) · 4.11 KB
/
structure.Rmd
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
---
title: "Structure of trait data"
bibliography: biblio.bib
csl: amnat.csl
---
Tidy long-table formats [@wickham14] 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'](index.html)).
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](index.html)).
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, @robertson09].
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 option would be preferred, 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 second option links separate data sheets by identifiers, which has the advantage of tidy datasets and avoids duplication of verbose information [@wickham14]. 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; @robertson09] is the recommended structure for GBIF [@gbif17, http://tools.gbif.org/dwca-assistant/] or EOL TraitBank [@parr16, http://eol.org/info/cp_archives]. These are .zip archives containing data table txt-files along with a descriptive metadata file (in .xml format). Detailed 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.
## R Tools
The R package 'traitdataform' (https://www.github.com/fdschneider/traitdataform) provides tools to transfer heterogeneous datasets into a longtable format and to create standardised taxa and trait columns, based on public ontologies. See the package documentation site and vignettes for further information.
# References