search

nvs-vocabs / OBISVocabs

A repository for the management of issues related to vocabularies used by the OBIS community.
2 stars 0 forks source link

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

Open meliezer opened 2 years ago

meliezer commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

@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 commented 2 years ago

@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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

meliezer commented 2 years ago

@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 commented 2 years ago

@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 commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

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

derek-mba commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

I am noting here for the people in this thread https://github.com/iobis/obis-issues/issues/196.

JoBeja commented 2 years ago

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 commented 2 years ago

Hi Jo, Yes, of course. I also know https://mof.obis.org/ It's really an important work! I was referring to https://github.com/nvs-vocabs/OBISVocabs/issues/15#issuecomment-920923841 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.