search

monarch-initiative / mondo

Mondo Disease Ontology
http://obofoundry.org/ontology/mondo
Creative Commons Attribution 4.0 International
229 stars 52 forks source link

Additional xrefs for MONDO:0100096, COVID-19 #2251

Closed dhimmel closed 3 years ago

dhimmel commented 3 years ago

Mondo term (ID and Label):

COVID-19 http://purl.obolibrary.org/obo/MONDO_0100096 MONDO:0100096

Xref that should be fixed (ID and label):

Current xrefs as per ontobee

database_cross_reference: SCTID:840539006; ICD10:U07.1; ICD11:RA01.2; ICD11:RA01.0; ICD10:U07.2; DOID:0080600

  1. mesh:C000657245 https://id.nlm.nih.gov/mesh/C000657245.html COVID-19
  2. snomedct:840539006 Disease caused by Severe acute respiratory syndrome coronavirus 2 (disorder) source
  3. snomedct:1240751000000100 - Disease caused by 2019-nCoV (novel coronavirus) [UK SNOMED code]

I think 2 is better than 3 since 3 might be a UK SNOMED-CT term only.

Your nano-attribution (ORCID) https://orcid.org/0000-0002-3012-7446

Other comments:

Let me know if this is the optimal way to improve MONDO xrefs. There are likely other xrefs I'd like to improve so any guidance on how I can be most helpful and impactful here would be appreciated. I'd be interested in submitting PRs to the source to add these if that is straightforward (but would need a tutorial).

nicolevasilevsky commented 3 years ago

Hi @dhimmel! We can remove the UK SNOMED xref. Do you want to do it and do a PR? I'd be happy to meet with you and walk you through it. Do you want to email me and we can find some time to meet?

Here is our editors guide for reference: https://mondo.readthedocs.io/en/latest/editors-guide/

dhimmel commented 3 years ago

Hi @nicolevasilevsky. The docs are helpful. Let me try making a PR myself, and I'll report back if I get stuck.

Notes from my process:

dhimmel commented 3 years ago

Here's a screenshot of the editing process in protege (for memory's sake):

2020-11-09_protege-editing-MONDO-xrefs

nicolevasilevsky commented 3 years ago

much more QC at the editor level would be ideal (for example restricting the type of xrefs, requiring standard prefixes, etc), but I'm guessing that's not possible with protege at the moment?

I like this idea. Not sure if this is possible, @matentzn ?

matentzn commented 3 years ago

I totally agree it would be ideal.. Unfortunately we are hindered by two things to do this: missing expert programmers that can do this (the docs on writing such plugins is so bad that even people with experience take too long to write anything reasonable), 2) politics -> chronic weariness of Protege and its dried out funding prevent any concerted efforts to find resources. We are basically pushing all this stuff now into continuous integration -> the whole phalanx of checks is run by travis or something like that before a branch can be merged. It is annoying, of course, to not get feedback earlier, but I cant see a way forward on this unless someone finds around 1 FTE for a year to pay someone to clean this mess up (which will never happen).

dhimmel commented 3 years ago

@matentzn thanks for the info on the limitations the field is working with. The CI checks seem like a reasonable alternative. Immediate feedback is ideal, but my main concern is standardized data and schema enforcement which can all happen at the CI level. Looking forward to learning more about the SPARQL violation queries and contributing them whenever possible.

matentzn commented 3 years ago

I totally agree. Even all this SPARQL checking is not ideal - if we had the resources (I would love to do it), we would dig into shape languages like shex and shacl, and do this kind of constraint checking in there. Right now, we basically encode antipatterns (like a piece of broken ontology) in a SPARQL query - and if the query returns something, that's considered a violation. It works well enough, but its not nice that these checks are not centralised somewhere and more easily reusable across ontologies.. :P Anyways, a super cool subject!