Open cmungall opened 2 months ago
Re-upping the priority on this. Options 1 and 2 are both simple to implement, and the status quo is highly suboptimal
Upping the priority on this
This has been dealt with for a while and already been released:
https://github.com/monarch-initiative/mondo/pull/7736/files
mondo.obo is an odd beast. In general the .obo files for any OBO project are
I much prefer 1, and having an explicit foo-basic ontology, with obo and owl and json isomorphic versions
However, 2 is common practice, which arose from the fact that a certain cluster of tools with implicit profiles that only accepted .obo pushed their requirements (this is coupled with confusing ad-hoc choices about which browser uses which version). But it makes a certain amount of sense, and is a standard, albeit very de-facto.
However, mondo.obo is an entirely different beast. It appears to be mondo-base.obo. This is getting ahead of things. Tools are not yet ready for base files. It's not clear who the intended audience for mondo.obo is. People who like .obo because it is simple will not be satisfied because it is has dangling classes. The leading obo format based bioinformatics tool, pronto, breaks on it (https://github.com/althonos/pronto/issues/225).
bioportal consumes mondo.obo and is unusable because of the dangling classes.
On top of this there is nothing in the OBO metadata to help: https://obofoundry.org/ontology/mondo
"As OWL. xrefs can be used as proxy for equivalence. Uses Mondo IDs."
The "as OWL" statement is false. I may be responsible for the opaque comments about proxy equivalence.
Happy with either of two options:
In addition we should add a base release https://obofoundry.org/ontology/mondo and we should be encouraging consumers to adapt their tools to accept this