obophenotype
Various CHEBI entities asserted as direct subclasses of IC
Uberon term It appears latest release is asserting various CHEBI chemical entities, for example glycogen http://purl.obolibrary.org/obo/CHEBI_28087 are direct subclasses of BFO independent continuant...
Bug description
See https://ontobee.org/ontology/rdf/UBERON?iri=http://purl.obolibrary.org/obo/CHEBI_28087
When I check the 'SubClass Of' relationships of CHEBI:28087 glycogen in uberon-full.obo uberon-full.owl from the latest Uberon release, I find that 'glycogen' is indeed a direct subclass of 'independent continuant', but also find it to be a direct subclass of CHEBI:24384 glycogens.
Please note that Uberon relies on the assertions in ChEBI that it imports.
It has been asserted in ChEBI that CHEBI:28087 glycogen 'has role' some 'Saccharomyces cerevisiae metabolite' 'has role' some 'Escherichia coli metabolite'
The property has role has "Domains (intersection):" independent continuant, thus it is inferred that CHEBI:28087 glycogen must be an 'independent continuant'.
Again, the direct subclass relation of 'glycogen' originates from ChEBI, more specifically, the assertions of 'glycogen' having roles 'Saccharomyces cerevisiae metabolite' and 'Escherichia coli metabolite'.
If you think that any of the above assertions in ChEBI were incorrect, then please raise a ticket in the ChEBI repo or contact CHEBI directly.
I'm reopening, this is an uberon pipeline issue. We should not be in the business of injecting asserted axioms even if they are entailed.
I disagree with the premise that it is a Uberon pipeline issue.
The Uberon pipeline is working exactly as it should. The proper fix here would be for CHEBI to explicitly assert that CHEBI’s chemical entity is a independent continuant, instead of letting the reasoner infer that only for some terms (the terms that have a has_role relationship).
If you are suggesting changing the definition of the main product of an ontology so it does not involve reasoning over imported ontologies, but only over Uberon’s “base”, why not but this is discussion that should rather happen in a wider context, like the ODK or the OBO Foundry.
Agreed! Discussion on injection here:
- https://github.com/OBOFoundry/OBOFoundry.github.io/issues/1443
Still open
The proper fix here would be for CHEBI to explicitly assert that CHEBI’s chemical entity is a independent continuant
This is a complicated ask because getting anything like this in CHEBI is impossible, and because the ask actually conflicts with current guidance about using COB, IC is above the shoreline. Some COB people say to just omit these. But they are on D/R constraints in RO, hence the issue here.
Note also that my proposal for above the shoreline classes in COB would solve this issue elegantly and straightforwardly
- https://github.com/OBOFoundry/COB/issues/213
But I have zero buy in....
Given that we are unlikely to see progress on any of these fronts, I think your suggestion of solving at the ODK level via some kind of optional "don't inject entailments after reasoning" is the way to go. I don't know if this is best done at the ROBOT level of some kind of post-processing step. It may be quite a bit of work. I would be tempted to put in some kind of hack in the uberon pipeline using obo-sed.pl but I end up making more work for everyone when I do this sort of thing! But I do want to acknowledge that wherever this fix should or could happen, it's not great behavior from a user perspective, and it manifests in a file we produce :-(
I think your suggestion of solving at the ODK level via some kind of optional "don't inject entailments after reasoning" is the way to go
(No definitive proposal in the following, just writing out some thoughts.)
ROBOT’s reason command has a --exclude-external-entities option which could come in handy here, except that it determines which entities are “external” by looking at whether the entities are declared in the “main” ontology. This means it wouldn’t work here, because the standard ODK workflow is to merge in all the imports before reasoning:
robot merge ...
reason ...
relax ...
reduce ...
so by the time we reach the reasoning step, the imports closure has been collapsed and therefore there is no longer any distinction between a “main ontology” and “imported ontologies” – all entities would appear to be declared in the “main” ontology.
So, maybe a way around that would be to do something like
robot reason --exclude-external-entities true ...
merge ...
relax ...
reduce ...
That is, we reason first, before collapsing the imports closure. Imported axioms would still be visible from the reasoner (so we shouldn’t lose any inference that we actually want), but externally declared entities would be correctly detected as such and any inferred axiom that concerns them would not be injected (thanks to --include-external-entities).
At least in theory. Obviously this would require some fair amount of testing to ensure this produces the kind of result we want.
Another option (that would require updating ROBOT) would be to be able to do something like this:
robot merge ...
reason --exclude-external-entities base-iris --base-iri http://purl.obolibrary.org/obo/UBERON_
relax ...
reduce ...
where the base-iris value would change the behaviour of --exclude-external-entities so that it decides whether an entity is “external” or not based on whether its IRI is in the namespace specified by --base-iri option (instead of deciding that based on whether the entity is declared in the “main” ontology).
I don’t think I would like that, because as a general rule I don’t like the idea of using an entity’s IRI to decide anything – IRIs should be “opaque”, we should never look at what an IRI looks like and infer anything from that. But… maybe we can accept that this particular horse has already left the barn quite a while ago. There are already several places in our workflows where we do exactly this kind of thing. Notably, the entire -base system, as currently implemented in the ODK, is entirely relying on “base IRIs” to decide whether a given entity belongs to the base or not!
Notably, the entire -base system, as currently implemented in the ODK, is entirely relying on “base IRIs” to decide whether a given entity belongs to the base or not!
In my opinion that was only ever a workaround for projects that didn't intentionally provide a base. The base file should be "the axioms asserted by an ontology project", vs. the ones received from outside. Everything edited in an ontology's edit file should be part of the base (e.g., SWRL rules in RO, etc.).
In my opinion that was only ever a workaround for projects that didn't intentionally provide a base
But for projects that do provide a base (whether intentionally or because they didn’t change the ODK default behaviour, which is to always produce a base alongside the “full” release), that base is constructed precisely by removing axioms pertaining to “external entities” – and which entities are “external” is determined by looking at whether their IRI falls within the ontology’s namespace.
This is not a “workaround”, this is how a base SHOULD be constructed as per the (hopefully) agreed-upon recommendations: The “base” version of an ontology is made by basically running the same pipeline as for producing the full release, but with an additional remove step:
robot merge ...
reason ...
relax ...
reduce ...
remove --base-iri {BASEIRI} --axioms external --preserve-structure false --trim false
@gouttegd yes I agree that's how it's recommended now, it's just a bit different from the original conception (which also didn't include inferences). I guess we're getting off topic for this repo. I feel like for the ChEBI/BFO issue here, since it won't be added to ChEBI, that COB should provide some centralized bridge files that would alleviate this issue. But I think @cmungall is also pointing out that wouldn't be a full solution until also the COB and BFO interface issues are resolved.