Handling deprecated and merged OMIM IDs

[allenbaron]

@sbello am I remembering right that OMIM reuses their ID numbers? Is that an old practice that they stopped or does it continue?

I noticed that some OMIM IDs deprecated quite some time ago (2007 & 2018) have persisted and not been reused (see search for 15900).

This has led me to wonder:
Should we should retain old OMIM IDs that were deprecated and merged on the relevant active diseases in DO?
The main advantage would be to provide mappings that are correct for older resources that have data encoded with these old OMIM IDs. It would be similar to what we are doing for deprecated DOIDs using oboInOwl:hasAlternativeId.

This same question could apply to other resources mapped by DO that deprecate terms: Orphanet, etc.

A specific example is 'myofibrillar myopathy 3' (DOID:0080094) which corresponds to OMIM:609200. This DO record could also include mappings to OMIM:15900 (merged to OMIM:609200), OMIM:310450 (merged to OMIM:15900), and now OMIM:182920 (merged to OMIM:609200).

It's not 100% clear to me what the downsides of this approach would be.

1. I guess retaining deprecated OMIM IDs could get pretty messy in less straightforward cases. A good example would be the recent deprecation of OMIM:252700 (DOID:12798) where it was merged into two separate records OMIM:607014 (DOID:0111390) and OMIM:607016 (DOID:0060222).
2. There would also be an expansion in the number of mappings to other resources which could confuse curators.
3. The presence of deprecated OMIM terms could cause users unforeseen issues.

Perhaps we could ameliorate some of the confusion by more fully using skos mappings and only including the current, most correct OMIM ID as an oboInOwl:hasDbXref. For the two cases mentioned above that could look like:

1. 'myofibrillar myopathy 3' (DOID:0080094) would have only OMIM:609200 as oboInOwl:hasDbXref and would also have the following skos relationships:
   • skos:exactMatch OMIM:609200
   • *skos:closeMatch OMIM:15900
   • *skos:closeMatch OMIM:310450
   • *skos:closeMatch OMIM:182920
     *I think skos:closeMatch makes the most sense when one OMIM ID is merged into another. Having more than one exactMatch in a resource would probably be messy due to its transitivity and skos:relatedMatch is too ambiguous.
2. DOID:0111390 (OMIM:607014) and DOID:0060222 (OMIM:607016) would retain only their respective OMIM IDs as oboInOwl:hasDbXref and these would also be added as skos:exactMatch. Additionally:
   • each could have skos:relatedMatch (or broadMatch) added for OMIM:252700
   • oboInowl:OMIM:25700 would be removed from DOID:12798 and could be added as skos:relatedMatch or possibly skos:closeMatch since this disease was mapped to it before it was deprecated and the equivalence should still hold.

Thoughts @sbello @lschriml?