The envo.owl release file contains a cyclic assertion that ChEBI role is a subClassOf BFO role and vice versa

[turbomam]

PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
SELECT
*
WHERE {
    ?s2 rdfs:subClassOf ?s1 .
    ?s1 rdfs:subClassOf ?s2 .
}

?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

[turbomam]

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

[turbomam]

@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

[turbomam]

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>

[cmungall]

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.

[turbomam]

jinx

your method is better

I updated the issue title

[matentzn]

Note a lot of discussions on BFO vs CHEBI role: oborel/obo-relations#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.

[turbomam]

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 $@

[pbuttigieg]

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 ?

[pbuttigieg]

this isn't an ENVO issue - I'm closing it

@turbomam please post on the CHEBI tracker