Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Discussion: New field for distinguishing event types #63

Open
timrobertson100 opened this issue Feb 24, 2021 · 3 comments
Open

Discussion: New field for distinguishing event types #63

timrobertson100 opened this issue Feb 24, 2021 · 3 comments

Comments

@timrobertson100
Copy link
Member

timrobertson100 commented Feb 24, 2021

It came up in the TDWG Genomic IG discussion that the event core is inadequate to model the needs of the GGBN, but is almost acceptable.

While we all agree that more extensive changes to the star schema limitation are needed soon, we'd like to make a simple change that allows us to progress things now. Specifically, the problem as I understood it, is that there is no way to broadly categorize the type of event (e.g. distinguishing between the collecting event in the field and the tissue extraction in the lab within the same core table). A proposal was to bring in a field to allow this to the event core which would be sufficient to progress with data exchange. It was voiced that basisOfRecord using a different vocabulary could be used but this would not be strictly in line with the current definition.

CC @gdadade @tucotuco @thomasstjerne @dschigel @MattBlissett for info and request comments. I propose we discuss here and then we'll know where and how to target a more specific request (e.g. Darwin Core)

@mdoering
Copy link
Member

basisOfRecord is a record level term and as such could also apply to event records. The definition is a good fit:

The specific nature of the data record.

The current vocabulary is the problem. If there are only a few entries needed it does make sense to me though as we not only have the major classes in there (Occurrence, Taxon, Event), but also subtypes for Occurrences. @tucotuco This might then as well be appropriate for Events?

A new eventType term would probably be less invasive though.

@dschigel
Copy link

I understand the choice is to see all sampling / subsampling steps as a single series (e.g. forest -> plot -> soil sample -> lab sample -> DNA extract -> PCR product -> run), where a solution can come in a form of parent-child relationships or separate field samples (which needs to be documented to inform downstream users on the way how signal from a natural population is captured) from the lab (sub)samples which are part of the processing pipeline, and also includes steps that can distort / decrease the original community signal, i.e. separating samples as capture technique from samples as processing steps. This choice is for species mixes such as eDNA and metabarcoding samples; tissue samples from a single species specimen is another story where @gdadage will certainly have things to say. Note that there are two goals that may have a mismatch of data standards solutions: one goal it to tabulate all processing steps as accurately as possible, which e.g. is very welcome to optimize storage and access to physical material locally, another goal is to have enough data elements to enable adequate data discovery and enable reuse.

@tucotuco
Copy link
Collaborator

tucotuco commented Aug 17, 2021

Sorry, I am not sure how I missed this one. I agree with Marcus that this could be done with new Darwin Core classes for use with basisOfRecord, but I suspect that there will be a lot of demand for a lot of different event types. It will be much easier to eventType as a new field into practice with a recommendation to follow a controlled vocabulary than it will to use basisOfRecord. I strongly recommend that this term be proposed, as there are lots of instances where it would be useful. There is a similar need and a new proposal for materialSampleType, which could act as a good template for an eventType term proposal.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants