Predict DOID mappings to UMLS, MeSH, and EFO

[cthoyt]

@allenbaron @lschriml there is a tiny issue with the way some of the entries are normalized, but this is the outline of generating the DOID mappings

Issues

• MONDO and IDO both have some conflicts with how their identifiers are checked, which is part of a larger discussion on local identifiers that will come up in the workshop next week
• ORDO and CIDO both are in a format that could not be parsed as either OBO nor OWL via pronto

[bgyori]

There is an important issue with this that just caused issues in INDRA through which I noticed this. Namely, the script doesn't take into account mappings that are already provided by DOID to MeSH, and adds redundant predictions for these. @cthoyt could you look into this and remove these predictions?

[bgyori]

Another issue is that a lot of one-to-many mappings are added as predicted exact matches. I think it would be better to leave these out or improve the script to take more features into account when deciding what mappings to propose. For instance here (for convenience this is not directly from predictions.tsv but a derived table):

EFO    0000182 hepatocellular carcinoma        DOID    DOID:3571       liver cancer
EFO    0000182 hepatocellular carcinoma        DOID    DOID:684        hepatocellular carcinoma
EFO    0000182 hepatocellular carcinoma        DOID    DOID:686        liver carcinoma
EFO    0000182 hepatocellular carcinoma        DOID    DOID:687        hepatoblastoma

there is an exact match at the name level so that single mapping could be proposed.

[cthoyt]

There is an important issue with this that just caused issues in INDRA through which I noticed this. Namely, the script doesn't take into account mappings that are already provided by DOID to MeSH, and adds redundant predictions for these. @cthoyt could you look into this and remove these predictions?

I think this is an issue with the redundant prefixes in the identifiers. I think a potential solution would to start standardizing identifiers in the main files, then provide an export that uses Identifiers.org rules for import in INDRA, since using a non-general solution is requiring writing custom handling for this in many places

Another issue is that a lot of one-to-many mappings are added as predicted exact matches. I think it would be better to leave these out or improve the script to take more features into account when deciding what mappings to propose. For instance here (for convenience this is not directly from predictions.tsv but a derived table):

That's an excellent idea. It seems totally obvious that one is better than the others. I think the current logic outputs all mappings returned by Gilda, but somewhere inside the scored match object if it has an "exact match" then that's definitely good enough to only keep it.

[bgyori]

These issues haven't yet been resolved, I will try to do something about it now.