Is there a mechanism to deal with obsoleted/merged concepts?

[larrybabb]

OMIM had a code prior to April 2014 #608967 which was related to Familial Thoracic Aortic Aneurysm http://www.omim.org/entry/608967?search=608967&highlight=608967 but it was "moved to" #609192 http://www.omim.org/entry/609192.

I believe this is a scenarios that will continue to happen over time. Concepts get renumbered, merged, split, and so on. In Snomed they track the "active" concept id and maintain an "equivalence" cross reference of the obsoleted or inactive concepts. Again, nothing unexpected or unusual in terms of authoring and maintaining a public coding repository.

My question is related to how does Monarch deal with this (or plan to deal with this)? If try to lookup OMIM:608967 in monarch I (expect) hope to find the mapped equivalent MIM concept 609192. Likewise when searching on inactive snomed codes, assuming they will eventually be formally mapped into the ontology.

I don't believe "Equivalent IDS" is the answer because I presume it is only capable of handling a single concept from a unique namespace in this list. But maybe it could? If so, would it be important to qualify which instance of the multiple equivalent id concepts from the same namespace is the currently active id? Would you consider an "obsolete references" area for capturing concepts that are no longer active but where once published and thus need to be hooked into the ability of finding/locating/computing on older data? I'm not sure that "References" is the right solution (if it is the solution) since References does not strictly isolate the notion of obsolete equivalent concepts. If it is "References" then can we treat all concepts in the References list as these "obsolete" equivalent types?

Well that's my concern. Any feedback/direction would be appreciated as we plan to integrate and depend more deeply on Monarch's ontology, we do need to understand how to manage this in the long run. (not too long I fear).

[jmcmurry]

@cmungall is the best one to comment on this; You make excellent points. cc: @TomConlin

[TomConlin]

in the Information Artifact Ontology there is the AnnotationProperty replaced by
http://purl.obolibrary.org/obo/IAO_0100001
Definition: Use on obsolete terms, relating the term to another term that can be used as a substitute.

We would need to get our hands on, or create the terms to map then maintain that mapping as its own local ingest.

Some sources will redirect from obsoleted terms to their replacement(s) terms/tombstones transparently others, not so much.

[kshefchek]

This how this is currently translated into RDF via dipper:

OBO:OMIM_608967 a owl:Class ; rdfs:label "Moved to 609192" ; OBO:IAO_0100001 OBO:OMIM_609192 ; OIO:hasExactSynonym "MOVED TO 609192" ; owl:deprecated true .

Would it be correct to make OMIM:608967 and OMIM:609192 equivalent?

We should also add something in scigraph so that owl:deprecated classes never become clique leaders. See https://scigraph-data.monarchinitiative.org/scigraph/graph/OMIM:608967?project=%2A

We should add this as another use case for the resolver service.

[cmungall]

No, we'd keep it as is. The app should be sensitive to OBO:IAO_0100001 (replaced_by) and either redirect or provide info to the user

[kshefchek]

That works. We should write some tests to make sure we don't have annotations to deprecated ids, see https://scigraph-data.monarchinitiative.org/scigraph/graph/neighbors/OMIM:608967?project=*

[cmungall]

@kshefchek if you do this call you can see the owl:deprecated axiom:

https://scigraph-data.monarchinitiative.org/scigraph/graph/neighbors/OMIM:608967?depth=1&blankNodes=false&direction=BOTH&project=%2A

so there are a few moving pieces here. Fixes to annotations should be done upstream, but we're deliberately lagging the OMIM pipeline just now. At source, we have 12 annotations for OMIM:608967, and 39 for OMIM:609192. We need to coordinate with @drseb here, but I assume there will be a semi-manual migration of annotations from the former to the latter (assuming the latter annotations don't subsume the former).

Now in theory we could just declare these as equivalent and have the propagation happen automatically, but this is dangerous. At a minimum, we need to make sure IDs don't get split (which would result in a 3-node clique).

It's safest just to follow the GO annotation practice of semi-automatically migrating annotations to obsolete nodes. It's difficult at the moment because of the asynchrony but this will get smoother over time.