tdwg / gbwg Goto Github PK

I recommend using a TDWG mailing list, but we could also create a Google group, if people prefer.

I am no currently able to access https://lists.tdwg.org/mailman/listinfo, but I will try again later or @timrobertson100 to do it.

and

@timrobertson100

Following on from #4 - I don't seem to be able to create GH Projects. Is this a permissions issue (I don't seem to have admin rights here, which would be needed for me and @raissameyer) or should we use Labels to mark TG-specific issues instead?

Dear GBWG team @ramonawalls

@raissameyer and I have created a task group proposal to consolidate this multi-year thread here.

This issue is to notify the GBWG community and respond to questions. It's also a chance to consolidate issues like #3

or

The IG should come up with definitions for environmental sample, environmental DNA (in comparison to single species samples), abiotic versus biotic environments etc.

Examples from Droege et al. 2016 doi: 10.1093/database/baw125:

• Material sample: The physical result of a sampling (or subsampling) event. In biological collections, the material sample is typically collected, and either preserved or destructively processed. (see http://terms.tdwg.org/wiki/dwc:MaterialSample)
• Environmental sample: A material sample that (i) represents taxonomic biodiversity from across the tree of life (e.g. blood, gut), (ii) represents abiotic substrate or environment (e.g. soil, water, ice core) or (iii) an assemblage of both
• Environmental DNA: The physical result of DNA extraction of an environmental sample containing DNA of multiple taxa. Often completely consumed during sequencing
• Ancient environmental DNA: The physical result of DNA extraction of an environmental sample older than 100 years (e.g. teeth) containing DNA of multiple taxa. Usually completely processed during sequencing
• Tissue sample: A material sample dedicated to a single taxon (e.g. leaf, muscle, leg), often chemically or physically treated to preserve biomolecules from degrading. May contain tissue/DNA of other taxa, e.g. endosymbionts, pathogens, destruents

Examples from GBIF Publishing DNA derived data glossary (https://docs.gbif-uat.org/publishing-dna-derived-data/1.0/en/#glossary):

• Community (bulk) DNA: DNA from bulk samples (e.g. plankton samples or Malaise trap samples consisting of several individuals from many species). For the purpose of this guide, bulk sample DNA is included in the eDNA concept.
• Environmental DNA (eDNA): DNA from an environmental sample, e.g. soil, water, air or host organism. An often used definition is that environmental DNA is the genetic material (DNA) obtained from environmental samples without any obvious evidence of biological source material (Thomsen and Willerslev 2015)

Hi @wdduncan

The MIxS IRIs are going to be essential for this Task Group. Great that you are developing them!

Would you know if there is a Beta release just for us to experiment with? If so, would you mind linking to that resource here?

Best,
Raïssa

This came up in the GSC. See GenomicsStandardsConsortium/mixs#90. MIxS does not have terms to say who carried out various roles in a project, and DwC only has a few roles, like who did the identification or took a measurement. Does GGBN have terms like this?

@79-6d

Hey,

So relationship between samples was brought up in MIxS meeting yesterday. It makes me wonder what is the best way to represent biological replicates and technical replicates of sequence based data in DwC?

As recommended in the guidelines to publish DNA-derived data through biodiversity data platforms:

We do, however, recommend including an eventID for each core record, to indicate the association between occurrences derived from the same sampling event.

Can I understand that this can be used to address technical replicates since technical replicates are sub-samples of a sample? What about biological replicates? and what do you think about the use of resource relationship extension?

@timrobertson100 Do you think that perhaps this is interesting to be included in the the guidelines to publish DNA-derived data through biodiversity data platforms?

I just gonna dump some other information that I can find here:
Please see this google doc for more info.

If I understand correctly, the attributes as mentioned in ENA and INSDC samples are not part of MIxS? (can someone please correct me if I am wrong? thank you) But I think this information is important and should be represented in DwC imho.

ENA

Parent child relationships are established via ‘sample composed of’ and ‘sample derived from’ attributes.

These attributes are captured within the child sample and their value is a list of INSDC sample IDs (comma separated) or a range (no spaces) e.g.:

sample derived from: ERS123456,ERS123654,ERS123123
sample composed of: SAME1234567-SAME1235000

Example use: https://www.ebi.ac.uk/ena/browser/view/SAMEA6150246 (click additional attributes)

GGBN

uses resource relationships from DwC

NCBI

NCBI uses the same relationship attributes that are present in EBI BioSample:
(you can view BioSample attribute definitions here: https://www.ncbi.nlm.nih.gov/biosample/docs/attributes/)

same as indicates that the same physical sample has multiple BioSample records
https://www.ncbi.nlm.nih.gov/biosample/?term=SAMEA4447240

derived from indicates where one BioSample was derived from another BioSample
https://www.ncbi.nlm.nih.gov/biosample/?term=SAMN13192999

family role relationships to other samples in the same study; can include multiple relationships
https://www.ncbi.nlm.nih.gov/biosample/?term=SAMN01090941

child of indicates parentage; only applicable to sexual organisms, for bacteria use 'derived from'
https://www.ncbi.nlm.nih.gov/biosample/?term=SAMN00690380

Related issues:

microbiomedata/nmdc-metadata#287
GenomicsStandardsConsortium/mixs#36

Thank you so much!

Recommendation from guidelines to publish DNA-derived data through biodiversity data platforms

The current recommendation is to publish data as Occurrence core (Category I or II) with the DNA derived data extension. This approach compensates for limitations of the DwC star schema, which would not allow any occurrence-level data in extension files (such as processed barcode sequences) to point to records in an event core file. We do, however, recommend including an eventID for each core record, to indicate the association between occurrences derived from the same sampling event

Concern raised during meeting on 2021-02-09

using the extended Measurements of Fact extension, if another extension is added they can only use the occurrence core, no longer the event core.

Challenge because a lot of the observations include environmental data, image based data and aggregating everything into events is what their community wants.

Similarly I also think that many environmental measurements such as depth related terms will have to be replicated many times for each occurrence record.

The specification/definition of terms may impact structure of the data model implementations.
For example, in a relational model, many-to-many relations between tables often result in complex schemas and/or result in ad-hoc work arounds. They also may create issue for denormalized schemas, such as star schemas.

Some examples from the healthcare domain:
one patient can be under the care of many physicians; one physician can care for many patients
one tooth surface can contain many fillings; one filling can cover many tooth surfaces
one anatomical site can contain many cancers; one cancer can be located in multiple anatomical sites

In each of the examples above, the definitions for patient, physician, tooth surface, anatomical site, cancer may be agnostic with respect to the arity of relation between the entities. However, issues arise when creating a data model to capture this information, or even when preparing spreadsheets for submission.

e.g. https://to.be.decided/MIXS:0000056

Create a spreadsheet in which each package only contains terms for the package; i.e., remove the core terms from the packages.

Similar to the existing mapping DwC-ABCD and DwC-MIxs, there is a mapping between ABCD and MIxS needed. The new MIxS 6 version should be taken into account.

Interestingly and somewhat confusingly, the GSC doesn't seem to want to include licensing information in its MIxS list (see here)

The DwC reuse of the dc:license seems wise in most cases.
Other relevant terms include:

dcterms:accessRights 
dcterms:references
dcterms:rights
dcterms:rightsHolder

We should include the recommendation to use these DC classes in our GBWG TG report for managing omics data across the UNESCO/OBIS/GBIF digital ecosystem, to allow them to comply with the "R" in FAIR.

Fields like this will become more important as Nagoya and other regulatory frameworks come into play around digital sequence information.

and

and

Hi @cmungall,

I had a look at the Simple Standard for Sharing Ontology Mappings (SSSOM), which looks like a good option to perform semantically precise mapping of related DwC and MIxS terms (I've had an exemplary first go at this below).

Would you think that SSSOM could be a suitable option for this? Or should I be looking at some other guides?

Best,
Raïssa

While most MIxS terms specify a constrained value syntax, many of the mapped DwC terms are "verbatim".

We will have to consider this in addition to the definitions when choosing mapping predicates. We will add a column to the mapping spreadsheet to capture this.

Moreover, the mapping predicates may change depending on the direction of the mapping (e.g. see issue #15).

Example
For MIxS elevation the value syntax is constrained to be {float}{unit}, however for verbatimElevation it could be anything, e.g. 1 m 5 cm, so {float}{unit}{float}{unit}, etc.
Here, for taking MIxS into DwC skos:exactMatch is fine, however, if the mapping goes from DwC to MIxS there is no guarantee that the value syntax pattern will be matched. We are currently mapping in the direction of DwC to MIxS, so it would be a skos:broadMatch (because the subject is DwC and the object is MIxS, the DwC would always be broader because there could be a wider range of syntax coming from verbatim)

CALeDNA is an important GGBN member and holds a big collection of environmental samples. The publication of those sample data is due in 2021 and currently done with ABCD-GGBN-Enviro. This use cae will be used for discussion in the IG.

or

and

or {

and

}

and

or {

and

}

or

and

Hey,

I am wondering if there is any documentation on how to map BIOM format (OTU tables) to Darwin Core?

I have seen some example like BIOWIDE eDNA Fungi dataset which has OTU's information, so there should be some degree of mapping between information from BIOM formatted OTU tables to Darwin Core right?

Thanks so much!

A few years ago all MIxS terms (as well as DwC, ABCD and GGBN) have been added to terms.tdwg.wiki to have them all in one place. This platform won't last forever, the standards are maintained elsewhere.
For MIxS the URI http://gensc.org/ns/mixs/TERMNAME is used, see e.g. https://terms.tdwg.org/wiki/mixs:samp_size

Please note, that this URI resolves to terms.tdwg.org! Depending on decisions for MIxS6.0 this might need to be changed by GSC.

GGBN is using ABCD2.1 as an interim solution between ABCD2.06 and ABCD3.0.

In ABCD2.1 the following MIxS terms have been included and hence need no mapping (they will be included in ABCD3.0 as well):

• sample_size
• sieving

In GGBN v1 the following MIxS terms have been included and hence need no mapping:

• estimated_size
• pool_dna_extracts
• lib_reads_seqd
• lib_screen
• lib_size
• lib_vector
• lib_const_meth
• adapters
• mid
• chimera_check
• assembly
• sop
• finishing_strategy
• annotation_source
• seq_quality_check

or

or

or

or

Hi @timrobertson100 and @thomasstjerne,

Looking at the MIxS-relevant part of this collection of extensions that GBIF offers, I noted that they vary in scope and that some focus on MIxS, while others also cover parts of GGBN and MIQE, however I'm wondering how they relate to each other.

Are these extensions sequential or are they independent?

And how do they, including GBIF’s DNA derived data extension relate to the 2012 extension built by @tucotuco et al.?

Best,
Raïssa