Cleanup: EMSL identifiers

[bmeluch]

Skip to the bottom for actual discussion questions

this first part is just my notes

Making sure I understand the current situation re: EMSL identifiers in NMDC

• Identifiers in NMDC should be resolvable
• Some EMSL identifiers currently in NMDC do not actually resolve, they are only useful internally
• EMSL is changing their public-facing data access and we don't know what it will look like yet
• We would rather have no external identifiers for users than confusing ones
• Therefore, EMSL identifiers currently in NMDC should be removed (some or all?)
• Once we know what the new EMSL database looks like, we can restructure our EMSL identifier prefixes to be resolvable

EMSL prefixes defined in the schema

First two resolve, last two do not.

emsl.project: "https://bioregistry.io/emsl.project:"
my_emsl: "https://release.my.emsl.pnnl.gov/released_data/"

emsl: "http://example.org/emsl_in_mongodb/"
emsl_uuid_like: "http://example.org/emsl_uuid_like/"

EMSL-specific identifier slots in the schema

• Biosample: emsl_biosample_identifiers - regex pattern restriction does not specify prefix
• Study: emsl_project_identifiers - regex pattern restriction requires emsl.project:, does not seem to be populated

Example EMSL identifiers currently in Mongo

Biosample

Does not resolve.

 "id": "nmdc:bsm-13-115vwp18",
 "emsl_biosample_identifiers": [
    "emsl:63ca4088-6647-11eb-ae93-0242ac130002"
]

DataGeneration

Does not resolve. But it is easy to derive a working MyEMSL link from that six-digit number (DMS dataset ID) and convert this to a my_emsl: formatted identifier if that would be helpful.

"id": "nmdc:omprc-13-xemx6b61",
"alternative_identifiers": [
    "emsl:456424"
]

DataObject

First resolves, second does not.

"id": "nmdc:dobj-11-e2309414",
"alternative_identifiers": [
    "my_emsl:1014276"
]

"id": "nmdc:dobj-13-3122df44",
 "alternative_identifiers": [
    "emsl:output_749047"
]

Questions

1. Should EMSL data identifiers (currently the MyEMSL links) go on DataGeneration at all, or should they go on the raw DataObject? Are we linking out to represent the raw data or the process of producing raw data? Both?
2. Is there a way to link to EMSL biosamples/biomaterials in a way that external users could see?
3. DataObjects could be either raw or processed data, hence the output in emsl:output_749047, but our processed DataObjects don't correspond to anything stored at EMSL afaik. So all this does is say what raw data this processed data came from. Can we remove these and instead use the has_input/output connections through WorkflowExecution?

Possible actions

Some combination of the following?

1. Remove the emsl: and emsl_uuid_like: prefixes and any slot values that use them.
2. Try to (re)populate all possible slots with something that resolves (MyEMSL links for data, project pages for studies, not sure if possible for biosamples).
3. Remove ALL the EMSL prefixes and identifier slots, don't waste time repopulating them, wait to see how ScienceCentral develops.
4. A secret fourth option I haven't thought of.

@lamccue @mslarae13 @brynnz22 thoughts?

[brynnz22]

Hey @bmeluch I have one thought right now. You mentioned in the first part "We would rather have no external identifiers for users than confusing ones". I am not sure what all is meant by confusing ones, but I am thinking from the view of what we are doing in the Material Processing Squad that we should still keep alternative identifiers even if we can't make them resolvable. Some of them still mean something to us, as developers in EMSL, and we are using them/may use them in our squad to help track down that data/information to help us find more context around it.