Open turbomam opened 3 months ago
?s2 | ?s1 |
---|---|
http://purl.obolibrary.org/obo/BFO_0000023 | http://purl.obolibrary.org/obo/CHEBI_50906 |
http://purl.obolibrary.org/obo/CHEBI_50906 | http://purl.obolibrary.org/obo/BFO_0000023 |
In addition to the equivalence axiom
PREFIX owl: <http://www.w3.org/2002/07/owl#>
SELECT
*
WHERE {
?s1 owl:equivalentClass ?s2 .
filter(isiri(?s1))
filter(isiri(?s2))
}
?s1 | ?s2 |
---|---|
http://purl.obolibrary.org/obo/BFO_0000023 | http://purl.obolibrary.org/obo/CHEBI_50906 |
@cmungall @pbuttigieg
Is this a good design? I can only speak to the fact that it breaks some code NMDC uses to load ontologies into a relational database.
Is this a consequence of the switch from Elk 0.4.3 to Elk 0.5.0?
It looks pretty silly in Protege, even with reasoning off
Maybe it's coming from PATO?
grep -r -C 3 CHEBI_50906 imports/*owl | grep -C 3 BFO_0000023
imports/omp_import.owl- <rdfs:label rdf:datatype="http://www.w3.org/2001/XMLSchema#string">role</rdfs:label> imports/omp_import.owl- </owl:Class> -- imports/pato_import.owl- <!-- http://purl.obolibrary.org/obo/BFO_0000023 --> imports/pato_import.owl- imports/pato_import.owl- <owl:Class rdf:about="http://purl.obolibrary.org/obo/BFO_0000023"> imports/pato_import.owl: <owl:equivalentClass rdf:resource="http://purl.obolibrary.org/obo/CHEBI_50906"/> imports/pato_import.owl: <rdfs:subClassOf rdf:resource="http://purl.obolibrary.org/obo/CHEBI_50906"/> imports/pato_import.owl- <obo:IAO_0000115 xml:lang="en">A realizable entity the manifestation of which brings about some result or end that is not essential to a continuant in virtue of the kind of thing that it is but that can be served or participated in by that kind of continuant in some kinds of natural, social or institutional contexts.</obo:IAO_0000115> -- -- imports/pato_import.owl- imports/pato_import.owl- <owl:Class rdf:about="http://purl.obolibrary.org/obo/CHEBI_24432"> imports/pato_import.owl- <rdfs:subClassOf rdf:resource="http://purl.obolibrary.org/obo/BFO_0000023"/> imports/pato_import.owl: <rdfs:subClassOf rdf:resource="http://purl.obolibrary.org/obo/CHEBI_50906"/> imports/pato_import.owl- <obo:IAO_0000115>A role played by the molecular entity or part thereof within a biological context.</obo:IAO_0000115> imports/pato_import.owl- <oboInOwl:hasRelatedSynonym>biological function</oboInOwl:hasRelatedSynonym> -- -- imports/pato_import.owl- imports/pato_import.owl- <owl:Class rdf:about="http://purl.obolibrary.org/obo/CHEBI_33232"> imports/pato_import.owl- <rdfs:subClassOf rdf:resource="http://purl.obolibrary.org/obo/BFO_0000023"/> imports/pato_import.owl: <rdfs:subClassOf rdf:resource="http://purl.obolibrary.org/obo/CHEBI_50906"/> imports/pato_import.owl- <obo:IAO_0000115>Intended use of the molecular entity or part thereof by humans.</obo:IAO_0000115> imports/pato_import.owl- <rdfs:label>application</rdfs:label> -- imports/pato_import.owl: <!-- http://purl.obolibrary.org/obo/CHEBI_50906 --> imports/pato_import.owl- imports/pato_import.owl: <owl:Class rdf:about="http://purl.obolibrary.org/obo/CHEBI_50906"> imports/pato_import.owl- <rdfs:subClassOf rdf:resource="http://purl.obolibrary.org/obo/BFO_0000023"/> imports/pato_import.owl- <obo:IAO_0000115>A role is particular behaviour which a material entity may exhibit.</obo:IAO_0000115> imports/pato_import.owl- <rdfs:label>role</rdfs:label> -- imports/pato_import.owl- imports/pato_import.owl- <owl:Class rdf:about="http://purl.obolibrary.org/obo/CHEBI_51086"> imports/pato_import.owl- <rdfs:subClassOf rdf:resource="http://purl.obolibrary.org/obo/BFO_0000023"/> imports/pato_import.owl: <rdfs:subClassOf rdf:resource="http://purl.obolibrary.org/obo/CHEBI_50906"/> imports/pato_import.owl- <obo:IAO_0000115>A role played by the molecular entity or part thereof within a chemical context.</obo:IAO_0000115> imports/pato_import.owl- <rdfs:label>chemical role</rdfs:label>
Of course, ENVO doesn't assert this, you can mouse over the source equivalence axiom in Protege and see this comes from PATO.
And of course, ENVO merges all imports and inferences in one envo.owl bundle (as per OBO standards) which launders the inferred subClassOf axiom, making it look like ENVO is the cause, but ENVO is just following OBO standards.
jinx
your method is better
I updated the issue title
Note a lot of discussions on BFO vs CHEBI role: https://github.com/oborel/obo-relations/issues/467
Also COB does not seem to think they are the same:
COB:0000114 role owl:equivalentClass BFO:0000023 role . semapv:ManualMappingCuration
COB:0000502 characteristic sssom:superClassOf CHEBI:50906 role The ChEBI notion of a role doesn't strictly follow the BFO sense of either being a role or disposition, meaning that it's hard, if not impossible, to impose BFO order to this branch of ChEBI. See issue #173 semapv:ManualMappingCuration
For this specific issue, it would be good if ENVO was moved to "base imports". ENVO isnt proper ODK so this is a bit of a mission. Recently did this for Mondo as well: https://github.com/monarch-initiative/mondo/pull/6639/files#diff-1376bbad1ef43bed6c9aed84b7d52471e63c87277b2b3f72ed0a5bdef481b638
However, the easiest way out for now is to get your users to use the envo base file - but when you do, make sure it is reasoned and reduced in the Makefile.
I would like to be more proficient with base files, here in EnvO and in NMDCO.
I tried to build NMDCO with base files but there were a lot of dangling owl:Things. I hadn't reasoned or reduced. For NMDCO, for the time being, I'm doing
robot remove --input $@.tmp.owl \
--term CHEBI:50906 --term BFO:0000023 \
--select self --axioms equivalent --axioms subclass --trim false \
--output $@
These long discussions don't get us anywhere. If PATO is asserting something that gunks up downstream processes, it should clean it up.
And there's no good reason - from the OBO perspective - that CHEBI should have a role class other than BFO:role. The definition is basically the same, but CHEBI uses less precise language.
OBO works like a federation, until it doesn't.
Can we use ODK or robot to remove CHEBI role from all imports ?