remove "OBO" prefix mapping

[balhoff]

I'm wondering if anyone else agrees that we should remove the "OBO": "http://purl.obolibrary.org/obo/" prefix mapping. To me it's a bad practice for one prefix expansion to overlap another. There are many other prefix expansions that include http://purl.obolibrary.org/obo/ as a substring. Anywhere that Biolink model needs to refer to an OBO term, it should use the specific ontology prefixes.

I noticed this in implementing the MetaKnowledgeGraph service for the Ontology KP; I end up with OBO as a valid prefix for nearly every Biolink category, which is not useful.

[saramsey]

Hi Jim, there are URLs in OBO ontology sources that we use, that reduce to CURIEs like OBO:core#connected_to. For example, this in uberon-ext.owl (line 3472):

<owl:ObjectProperty rdf:about="http://purl.obolibrary.org/obo/core#connected_to"/>

How would this URL be shortened?

[cmungall]

If you could report these on the uberon tracker, this would be great

(I know exactly where these are coming from. Most of uberon uses the RO relation. But there was an uberon module that dealt with fish and dinosaurs that was managed sepparately and when we merged it in some relation IDs didn;t mesh)

any of the following work

• drop until fixed upstream. I promise you spatial connections between bones of extinct vertebrates probably isn't the most relevant edge type in translator, cool as they are :-)
• keep the full URI
• we create a prefix UBERON.NONAMESPACE => http://purl.obolibrary.org/obo/core#

[balhoff]

Thanks for the feedback @saramsey! I favor Chris's last suggestion, adding UBERON.NONAMESPACE => http://purl.obolibrary.org/obo/core#. We can still also fix the IDs at the source (Uberon).

There are a few others, for example OBO:envo#has_increased_levels_of, which I think we can handle the same way we did for similar relations in PATO:

PATO-PROPERTY: 'http://purl.obolibrary.org/obo/pato#'

All of these kinds of ids are really mistakes from the OBO Foundry perspective, and we (OBO) should get around to fixing them.

There are some that I think can be changed or removed:

• OBO:xref => should be OIO:hasDbXref, which is what the OBO file syntax xref translates to
• OBO:intersection_of => this is part of the OBO file format but not a legitimate relation on its own

What do you think?

As an aside, I also noticed we have multiple mappings to the same expansion:

• "oboInOwl": "http://www.geneontology.org/formats/oboInOwl#"
• "oboformat": "http://www.geneontology.org/formats/oboInOWL#" (almost! this one is just a mistake)
• "OIO": "http://www.geneontology.org/formats/oboInOwl#"

I'm not sure what the policy is here.

[balhoff]

I'm working on getting rid of those problem Uberon relations: obophenotype/uberon-phenoscape-ext#26, obophenotype/uberon-phenoscape-ext#27

[sierra-moxon]

@balhoff @saramsey, so the solution here is to replace the following prefixes with the new expansions?
OBO:nbo# with prefix NBO-PROPERTY ('http://purl.obolibrary.org/obo/nbo#')
OBO:doid# with prefix DOID-PROPERTY ('http://purl.obolibrary.org/obo/doid#')
OBO:uo# with prefix UO-PROPERTY ('http://purl.obolibrary.org/obo/uo#')
OBO:core# with prefix UBERON.NONAMESPACE ('http://purl.obolibrary.org/obo/core#')

OBO:xref -> OIO:hasDbXref

I don't have a good handle on the downstream ramifications of removing oboformat as a prefix or replacing oboInOwl with OIO. @cmungall is there a preferred option here?

(This PR attempts to do the work above).