OMIM PMID, UMLS, and Orphanet mappings out of date

[joeflack4]

Overview

@twhetzel I don't know how important these are, if we're using them at all, but I just noticed some very old code: https://github.com/monarch-initiative/omim/blob/main/omim2obo/parsers/omim_txt_parser.py#L433

You can see the output of that function used here: https://github.com/monarch-initiative/omim/blob/main/omim2obo/main.py#L417-L424

This is hard coded to a local file called updated_01_2020_to_08_2021.json, but there's a todo about getting this from the OMIM API.

[twhetzel]

does anything call that method?

[joeflack4]

Yeah. You can see it in the second code block I linked. That code block and directly below it shows IAO:0000142 and skos:exactMatch that are created based on this data.

[twhetzel]

@joeflack4 can you summarize the consequences of that code block as it currently is and point out what data is effected because of this and if this relates to any data we are actually using?

[joeflack4]

The consequence, in summary, is the title itself: "OMIM's PMID, UMLS, and Orphanet mappings out of date".

Basically, that file is hard coded to a specific date: updated_01_2020_to_08_2021.json.

What's needed is to get this file through the API instead .

I don't know if these mappings are used for anything or how they might be used. I was wondering if you might know. If not, Nico should know.

[matentzn]

Are these mappings making their way into omim.owl? If not, delete the file to avoid confusion.

[twhetzel]

I don't know if these mappings are used for anything or how they might be used.

Ok, this is what I was asking for if/how these mappings are used. @joeflack4 can you follow-up on Nico's question to see if these mappings are making their way into the omim.owl file and need this other information?

[joeflack4]

@matentzn I just want to be really clear before I start removing stuff. So, it is true that updated_01_2020_to_08_2021.json is currently being used to add these mappings to omim.owl. Also there is a legacy_omim.ttl that Dazhi created which also adds mappings. They're both old.

So when you delete the file, I interpret that you mean that I can do any of these things:
a. Remove these old files, as well as the code that processes them.
b. Remove these files, but leave the code, should we need it later. And add exception handling so that it doesn't error out if these files are missing.

Do you have a preference?

[matentzn]

If they effect omim.owl they effect our alignment system, so no, in this case I think it's a bug, and these files need to be updated (ideally as part of the build). Does OMIM provide any up to date mappings?

[twhetzel]

@matentzn how is this effecting the alignment system? The code looks like it's using the static file (updated_01_2020_to_08_2021.json) to add additional annotations to an OMIM class for PubMed, UMLS, and Orphanet. Where are these annotations used in downstream processing of the omim.owl file?

[matentzn]

The lexical matching will use the mappings for matching (lexmatch).

[twhetzel]

Thanks, I see them now in the omim.sssom.tsv file

OMIM:615119	mitochondrial complex 4 deficiency, nuclear type 6	skos:exactMatch	MONDO:0014051		semapv:UnspecifiedMatching
OMIM:615119	mitochondrial complex 4 deficiency, nuclear type 6	skos:exactMatch	Orphanet:1561		semapv:UnspecifiedMatching
OMIM:615119	mitochondrial complex 4 deficiency, nuclear type 6	skos:exactMatch	UMLS:C3554534		semapv:UnspecifiedMatching

FWIW, the OMIM API has a limit of 5,000 calls per day.

Also, IAO:0000142 is 'mentions'.

[joeflack4]

@twhetzel @matentzn I can figure it out from here you guys. There's already some starter code for calling the API for this.

@twhetzel I'll let you know if I run into any API rate limit issues.
@twhetzel Just need to know what you think the relative priority is for this. March board may be a no go as I have some vacation time next week.

[twhetzel]

I left in Backlog for March and it's fine if it carries over to April. Thanks for checking.