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

eMoF for 'Reproductive condition of biological entity specified elsewhere' #15

Open
meliezer opened this issue Sep 16, 2021 · 20 comments
Open

Comments

@meliezer
Copy link

MeasurementType

Reproductive condition of biological entity specified elsewhere

Issue

reproductiveCondition is included in the occurrence extension, but not mentioned in OBIS documentation. I believe that such information would be lost after harvesting the DwC-A format.
We should follo the approach of lifeStage and use our eMoF with:
Reproductive condition of biological entity specified elsewhere a textual P06 (XXXX).
Currently I'm not aware of a related vocabulary, so ID will remain empty.
I'm not asking yet to create this P01 term, which is also very useful for SeaDataNet, since the discussion is still open.
Anyway, we should decide and update the guidelines.

Thank you.

@meliezer
Copy link
Author

@pieterprovoost Maybe OBIS could interpret this value and save it as reproductiveCondition in OBIS CSV file?
I wonder if today a similar case in which I save lifeStage in eMoF and not in occurrence: this values is saved in OBIS as lifeStage by interpreting eMoF?

@pieterprovoost
Copy link

@meliezer We currently do not populate/modify any occurrence values from eMoF, and usually recommend populating the occurrence fields in addition to creating eMoF records (although that's not reflected in the manual). If you would like to have this option discussed in the SG or QC task team please create an issue in https://github.com/iobis/obis-issues

@meliezer
Copy link
Author

@pieterprovoost Thank you. Good to know!
I understand you don't object to this new term. I'll wait for more responses. I actually wanted to discuss it in the other repository, but then I've sued a wrong link.

@rubenpp7
Copy link

Hi @meliezer , at EurOBIS we recommend data providers to use lifeStage and Sex in the eMoF extension and not in the occurrence extension when possible (to avoid redundancies) so indeed we may need to agree on some guidelines here

@meliezer
Copy link
Author

Hi @rubenpp7 , currently I only write upon need under occurrenceRemarks: This record is being referred by the 'Extended Measurement Or Facts' file for supplying more occurrence related information.

@derek-mba
Copy link

I'm glad to see a EurOBIS response (even though I disagree with the approach!). Most of our CPR Survey users really don't care about the eMoFs. If they can get the data they want from the occurrence record, they're happy. So, I fully support providing Lifestage and Sex in both. The entirety of the eMoF structure is a redundancy (though valuable), but if the fields are available I don't think we should be discouraging using them.

@wardappeltans
Copy link

We recommend eMoF because of the standardisation by linking to controlled vocabularies (the ID terms in eMoF), but are happy if you want to duplicate to make it compliant with other systems (eg GBIF).

@albenson-usgs
Copy link

OBIS-USA is in agreement with @derek-mba. Part of it is being compliant with other systems but over and above that is the fact that it's following the standard. People who are familiar with Darwin Core and less familiar with OBIS will be looking for that information in existing Darwin Core terms.

@meliezer
Copy link
Author

Maybe OBIS should propose a new IPT extension 'Vocabulary' (not only for OBIS) which simply includes few terms: eventId, occurrenceId, concept (or term) and conceptID? As simple key value list to be used for ANY term. In such a case, user will see for example occurrence terms in the occurrence table while the related ID will be found in the new extension. e.g. lifeStage nauplii in the occurrence extension and related term 'nauplii' and termID 'S1130' in the new extension.
eventId is obligatory in case of eventCore.
occurrenceId is obligatory in case of occurrenceCore.

@albenson-usgs
Copy link

@meliezer that isn't necessary because there are already IRI analogs for most Darwin Core terms see section 3.7 here.

@meliezer
Copy link
Author

@albenson-usgs it's not clear how this resolves the need for specifying a vocabulary. I do see https://dwc.tdwg.org/list/#dwc_lifeStage, but how should I note that I'm using http://vocab.nerc.ac.uk/collection/S11/current/S1130/ as a lifeStage?

@albenson-usgs
Copy link

@meliezer the way that I've heard it described is that you add a column in the table with dwciri:lifeStage as the header and put http://vocab.nerc.ac.uk/collection/S11/current/S1130/ in the column. Admittedly I don't know of anyone doing this currently and I think there might need to be some updates to the IPT to make this work but we shouldn't propose a new extension when the standard already provides the means. We just have to figure out how to implement it.

@derek-mba
Copy link

I confess, the CPR Survey dataset only has "S1130" in the LifeStage column of the occurrence record. In the eMoF record it has the full URL because @rubenpp7 was much more demanding 🙂

You certainly can supply the full URL in the LifeStage column.

In the associated eMoF, I have:

measurementType	= "lifestage"
measurementTypeID	= "http://vocab.nerc.ac.uk/collection/P01/current/LSTAGE01/"
measurementValue	= "S1130"
measurementValueID	= "http://vocab.nerc.ac.uk/collection/S11/current/S1130/"

@meliezer
Copy link
Author

@albenson-usgs an example of a similar long discussion: tdwg/dwc#102
I don't believe we want to dive into it. In case OBIS e EurOBIS find it interesting i could also propose it myself to IPT and see whether they propose a good alternative.

@meliezer
Copy link
Author

@derek-mba of course supplying the full URL is great to machines, but what about humans that wants to filter by value?...

@derek-mba
Copy link

That's why the eMoF has both Value and ValueID - we still supply the same Value that we used in the Occurrence record, but the ValueID is the same thing in machine readable format. As I understand it, this was the driver behind eMoF in the first place, because GBIF and the IPT make no demands on the actual vocab used, just that a vocabulary should be used.

@meliezer
Copy link
Author

I know, and eMoF is a more complicated solution to this issue. Maybe we should simply focus on whether or not have the terms also in occurrence. IMHO yes. I think about a poor human that see lifeStage empty and doesn't know it could hide in the eMoF extension :) Furthermore, OBIS current doesn't look at facts in eMoF.

@albenson-usgs
Copy link

I am noting here for the people in this thread iobis/obis-issues#196.

@JoBeja
Copy link
Contributor

JoBeja commented Sep 29, 2021

Hi Menashè,
Your last comment is not exactly true.
OBIS is looking at eMoF via the vocabulary working group. One of the aims is to analyse what already exists in terms of parameter mapping and provide guidance so that the nodes can proceed with dataset updates. If there is a lifeStage field that is included in eMoF but not mapped to an existing vocabulary this will be highlighted to the nodes.
e.g we found that a number of datasets use an incorrect P01 for specimen length,, some didn't even use a P01 but an S06 or other collection. These instances should be corrected first so that something else can eventually be built on top of it.

@meliezer
Copy link
Author

Hi Jo,
Yes, of course. I also know https://mof.obis.org/
It's really an important work!
I was referring to #15 (comment)
I'm sorry that this discussion continues here and not as a new issue in https://github.com/iobis/obis-issues in case someone wants to switch repository.

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

7 participants