bridge CHEBI:role to BFO:role #467
Comments
|
One question we should look at before I fully endorse this is why exactly the axiom is not imported from go. Is it in go or go plus? |
|
It's in |
|
So maybe that’s the right thing to do, move to go plus across the board? Is
there anything speaking against that?
…On Fri, 18 Jun 2021 at 21:25, Jim Balhoff ***@***.***> wrote:
It's in go-base.owl (and go-plus.owl). It's not in go.owl; I don't think
folks should be importing from go.owl if they're doing cross-ontology
work, because it filters out all external references.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#467 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABV6HJ32VC3KYW2A3TN4TKLTTOFQ5ANCNFSM466DJAXQ>
.
|
|
@matentzn not sure I follow - @balhoff said it was in go-plus already? But in any case, I think this is moot, it doesn't belong in GO. See: OBOFoundry/OBOFoundry.github.io#1443 (and see my comment from 3 days ago about the relationship between injected axioms and base files, which seems to me to be undefined). I like Jim's pragmatic suggestion of moving this to RO. Obviously CHEBI is the correct place, but we know that it is hard for CHEBI to provide axioms like this. RO is a good substitute as it is fairly central. I think we should follow the practice recommended in the injection ticket, and tag it as an intentional injection, and we could get CHEBI's "signature" on it. But let's look at the deeper problem here: over-enthusiasm in use of BFO. We are constantly seeing these kinds of issues caused by over-used of BFO classes instead of plain common-sense classification. One characteristic of these issues is that the tests to find them are highly brittle (as is in evidence here), and frequently manifest themselves downstream where they become hard and costly to debug. Let's look at this example with CHEBI modeling "acid" as a role. If we were following common-sense, we would model "acid" as a chemical entity and not a role, as per every definition of acid, ever, e.g In fact even the text definition in CHEBI itself says this is a molecular entity:
If ontologies really want to over-ontologize and represent ordinary things using confusing BFO classes, this should be clearly signified in both the label and the definition. E.g. "acid role". But really the most sensible thing to do here is just model it consistent with the text definition: a molecular entity that is capable of X. It's time we in OBO stopped setting ourselves pointless crossword puzzle reasoning exercises that consume a lot of time and energy and focused on solving real problems. We must simplify our ontologies and avoid pointless costly abstractions that don't solve actual biologists' needs. |
|
@cmungall I totally agree with your points. However it seemed a lower barrier task to slip this axiom into RO rather than ask for a reworking of the CHEBI hierarchy. 😅 But probably we've been avoiding the real issue for too long. Given that experienced ontology editors make this "mistake" over and over again, it's probably not the right model. Do you think the situation is as clear-cut for "hormone"? That's another one which frequently causes trouble. |
|
I agree with all you say: fwiw, my whole point was that maybe, instead of
pulling from go.owl, all our ontologies that refer to go should instead use
go-plus; but obviously yeah your points go much deeper than that. so then,
so what should we do then? organise meeting with chebi and ask them to
reconsider the role branch?
…On Mon, 21 Jun 2021 at 00:31, Jim Balhoff ***@***.***> wrote:
@cmungall <https://github.com/cmungall> I totally agree with your points.
However it seemed a lower barrier task to slip this axiom into RO rather
than ask for a reworking of the CHEBI hierarchy. 😅 But probably we've
been avoiding the real issue for too long. Given that experienced ontology
editors make this "mistake" over and over again, it's probably not the
right model.
Do you think the situation is as clear-cut for "hormone"? That's another
one which frequently causes trouble.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#467 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABV6HJ5ZTYSSXBMMALHSYZDTTZMZPANCNFSM466DJAXQ>
.
|
|
@balhoff I brought this up again in the COB repo here OBOFoundry/COB#169 |
I strongly support this. It will massively improve integration and co-ordination. It is particularly important for phenotype ontologies where patterns commonly define compound entities using GO-consistent patterns. |
|
On the broader ticket - it makes sense for bridging axioms such as the one discussed in this ticket to live in an upper ontology. Not sure whether it makes sense for them to live only in COB - forcing any ontology who wants it to adopt broader COB commitments. |
nlharris
added
GO
|
It happened again (obophenotype/human-phenotype-ontology#7224) so I opened a PR: #528 |
|
Was fixed by @cthoyt in OBOFoundry/COB#173 |
|
So can this be closed now? |
In GO there is an axiom: role EquivalentTo role
This equates the role class in CHEBI to the one used in RO, and catches cases when chemical roles (specifically dependent continuants) are accidentally used as chemicals (material entities).
When I merge several OBO ontologies together, like GO, Uberon, MP, and HP, I often run into disjointness violations with use of chemical roles. Generally this is because this bridging axiom is randomly placed in GO and not imported into other ontologies.
Can we add this axiom to RO? It would be nice to have this shared across all these ontologies. Maybe this will be the sort of thing COB is used for down the road, but this is an immediate problem and RO is a nice central place.
I'm putting an example explanation for one of these problems in the next comment.
The text was updated successfully, but these errors were encountered: