How to explicitly document what typecode the minter should use

[aclum]

How should the schema capture explicitly what typecode the minter should use when there are multiple valid typecode option? Currently there is a workaround where the first typecode listed is used.
See microbiomedata/nmdc-runtime#592

@eecavanna @turbomam @sierra-moxon @kheal @brynnz22 @mslarae13

[eecavanna]

Adding @SamuelPurvine, who has expressed interest in this topic.

[SamuelPurvine]

Unsure if this is a/the avenue to bring up a discussion about this, but I wanted to mention a concern I have with respect to having multiple typecodes that refer to the same thing. Specifically I'm referring to using omprc IDs to refer to data_generation entities (whihc will be using dgns, dgms, others?). I completely get how hard it is to change the omprcs if they are embedded in files or entries for some of our data, I'm super sympathetic! I'm also aware that I have ignorance around ID structures and best practices, and I am fine piping down on my concern. That said...
My specific concern relates to a potential user's confusion and irritation at having to keep track of multiple human readable codes that refer to the same thing. A user trawling through our data would likely find legacy data that uses omprc IDs for data generations that point to mass spec files (for example), but then "new" data (when/how ever that is defined) would carry the dgxy IDs, and would naturally wonder why the schism. They would dig into documentation, hopefully complete and easy to find, that would explain that these IDs are to be used interchangeably and it's a choice we made. I was wondering if it would be useful to advocate that when/where possible, we update data_generation IDs to use the new typecode for legacy data?
I point to the example of GOLD using their semi-hierarchical ID structure (Gs -> Gb -> Gp -> Ga), wherein once a user cottons on to knowing which ID points to which level of data, are able to quickly understand an ID and learn how to navigate to get higher (or lower) level data. If I had to also know that Gd referred to data from an analysis, and would need to track both (Ga being the other) to gather all related data, I would definitely be less inclined to use that system to trawl for information.
I fully recognize I likely missed this particular decision in December 2023, or chose not to argue the point, I was pretty ill and foggy at the time. I would have advocated for changing to data generation IDs whenever at all practicable to reduce confusion for all data we are tracking. I'm happy to quiet down about the issue :)

[brynnz22]

Hey Sam! This is explained in the publication I sent you earlier; lesson 4: https://journals.plos.org/plosbiology/article?id=10.1371/journal.pbio.2001414. Meaning should not be relied on through identifiers for the same reasons we are seeing - things evolve and become obsolete. A user can look at a record's metadata to understand what it is - not the identifier.

[aclum]

This will become increasingly important as our IDs propagate to other systems. For the re-iding efforts I had to manually coordinate with IMG for example to provide the new IDs.

[SamuelPurvine]

So then one would not be excoriated for pointing out that the type codes in our Napa IDs don't really fit the imprecation to not embed meaning in an identifier, rather we might have chosen to define a range of type codes that could exist, say 1000 or 10,000 to be safe, and assign types to type code IDs (e.g. 00001 = Data Object, 00002 = Omics Processing OR Data Generation), making things look like napa:00001-11-BLORTY12, yes?
Additionally, we feel that many/most users will be able to relatively easily access the metadata fields that will help them determine what kind of data is being presented, in this case the thing that generated a data object from a biologically derived sample that was then used for follow on analyses, yes?

[aclum]

You are correct, in Napa we decided on transparent identifiers instead of complete opaque. While there is always room for improvement the data portal filters have options for filtering on the full spelling of the OmicsProcessing/DataGeneration type. If using the API all records have the what the data type is, currently via omics_type.has_raw_value, in the records. Traversing collections is an acknowledged pain point currently and there is work being done to require less expertise to traverse all the collections to connect data files with Biosample or OmicsProcessing/DataGeneration.

[turbomam]

I agree with @brynnz22 . I regret that we ever created semantic ids. That doesn't mean that I think this situation is easy to fix.

[mslarae13]

Sounds like a decision has been made to keep omprc.
@turbomam are you aware of any LinkML attribute we could put on DataGeneration to capture that this class replaced OmicsProcessing and provide clear technical documentation that omprc WAS a valid typecode for this new class, but new records will be minted with the new typecode.

FYI @lamccue @SamuelPurvine @brynnz22 @aclum

[mslarae13]

https://linkml.io/linkml-model/latest/docs/deprecated_element_has_exact_replacement/ ?

[aclum]

"WAS" should be "IS".

…

On Tue, Jul 23, 2024 at 11:13 AM Montana ***@***.***> wrote: https://linkml.io/linkml-model/latest/docs/deprecated_element_has_exact_replacement/ ? — Reply to this email directly, view it on GitHub <#2125 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB6RD3YHORK2QBIVYWI3HZDZN2MMPAVCNFSM6AAAAABLBLGRWCVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAMJSHE3TCOI> . You are receiving this because you were mentioned.Message ID: ***@***.*** .com>