Closed fdschneider closed 6 years ago
After looking into the TraitBank definitions of the EOL project, I suggest to organise the template categories after the type of data they refer to. From a database point of view, we have three layers of information:
_original
) furthermore, if no online ontologies are referenced, there can be user-specific tables that contain:
This structure fits into separate data tables, as suggested by the EOL TraitBank standard, and can be combined into an Darwin Core Archive. E.g. one can refer to the information given in tables 2 and 3 by using the fields measurementID and occurenceID.
This atructure will be reflected in v0.3 (see d05233a6f02352d523be076077078aba64cde921 ; 751647a19777469195f058d89c4a2a4b88e09079).
I prepared an Excel-sheet (see 568c81ffa33956840c9dfed41240948d6ea78590) reflecting this structure. It could be used to manually prepare data for upload.
However, a minimal R-script version should provide a transfer of the user-provided data into standardised data, i.e. provide
I just updated the trait data standard / template definitions. See: http://fdschneider.de/bexis_traits/traitdatastandard.html
I was also working on the R package today and it now is quite functional. Check it out at https://github.com/fdschneider/traitdataform. A couple of bugs remain. I will provide a package vignette and some examples in the next couple of days.
The current structure of the trait data standard is very useful and should be easy to understand for the user. I think this can be our final structure.
Ok. Thanks. I'll close this for now. If comments of our trait experts unravel flaws in this structure, we'll come back later.
Does the current structure of the template make sense? The template is currently split into six (seven) categories:
as a particular class of columns for the exploratories:
and containing potential metainformation for data tables that are combined from multiple datasets (i.e. aggregated data)