Roles/Qualities interplay in the 20230405 release

[psiotwo]

What is the expected handling of the duplicate quality/role concepts in the current HP version? Unifying them (for quality:PATO:0000001 = BFO:0000019) and (for role: CHEBI:50906 = BFO:0000023) is obviously incorrect, because of different axiomatisations (BFO quality being disjoint with BFO realizable entity, i.e. also role, while CHEBI role is subClassOf PATO quality).

Thanks in advance for any hint.

[pnrobinson]

@matentzn @cmungall thoughts?

[matentzn]

@psiotwo can you define what you mean by "expected handling"?

We don't use BFO:0000023 or BFO:0000019 in HPO directly - they may be imported if they are needed to define external terms, but we don't use them for defining phenotypes. So if you must handle, handle them with robot remove --term BFO:0000023.

The question how to handle them (independent of HPO), in general, is tricky and important. In my personal opinion, I would say that the classes should be equivalent, and the axiomisations unified. How and which ontology community will move their axiomatisation only ChatGPT with GPT5 knows.

[psiotwo]

@matentzn in the previous HPO version, unifying both quality concepts and both role concepts didn't cause unsatisfiability problems. Although this unification - per se - is just a technical operation that I do not want to defend here as semantically correct (maybe it is not), in the current HPO version you cannot align these anymore without causing the unsatisfiability of many concepts. This also means that the final HPO artifact contains pairs of concepts (although if from imported ontologies) sharing the same label.

[matentzn]

@psiotwo I tried to merge the entire BFO and the two equivalent axioms you indicated into HPO, and so many things that have nothing to do with HPO become unsatisfiable. The root cause would seem to be this axiom:

SubClassOf(obo:CHEBI_50906 obo:PATO_0000001)

Which is in RO.

I checked with the RO team on slack, to see what the history is.

I did not find any axioms in HPO BASE (HPO minus imports) that could cause problems. Can you confirm? Did you identify and HPO base axioms that are incompatible with BFO?

[psiotwo]

@matentzn - yes, agree, I pinpointed this axiom to be the root cause as well. Currently, I postprocess the ontology and remove this axiom, but I would expect to see the released ontology terminologically coherent.

[matentzn]

In what way is it not coherent? If you check on slack (obo-relations channel), you will see that BFO:role and Chebi:role have nothing to do with each other. From my point of view HPO is coherent, but I may be missing something as I am not using a full DL reasoner. So once again, which HPO axioms (not imported) do you think are false?

[matentzn]

@psiotwo can you confirm that the discussion on slack has satisfied your inquiry so we can close it?

[psiotwo]

@matentzn, yes, I will try hp-base.owl.

Still, it is not completely clear to me where the responsibility is. I wasn't able to find any information about the intended use of hp-full.owl and its guarantees w.r.t. OBO Foundry principles. So I expect that for some use cases, terminological ambiguities are not a serious problem. For cases where they are a problem, I would have thought that presenting a single role/quality concept would be more correct (which I assume would however require not using OWL import mechanism to avoid inheriting problems like this from the imported ontologies - again I assume this would complicate the current pipeline).

[matentzn]

Again, I dont disagree with you, but this is a fundamental issue in all of OBO - every single ontology importing Chebi and BFO will have the same problem. It is bad that these two classes have the same name "role", but they mean entirely different things apparently (which I also didn't know). It cannot be the problem of an ontology to disambiguate terminological overlap in other ontologies. And your problem would not really be solved by us forcably removing BFO:role from the ontology (which is easy to do) because the moment you merge HPO with another ontology, the terminological ambiguity is back!

OBO Foundry principles by the way are not clearly applicable here. We have decided years ago in the OBO Dashboard to only test base axioms for terminological issues.

I would have thought that presenting a single role/quality concept would be more correct

I think this is mixing up terminological concerns too much.. they are classes that are accidentally called the same thing (which is unfortunate), but they are not, at all, intended to refer to the same or even similar concepts!

[psiotwo]

... but they are not, at all, intended to refer to the same or even similar concepts!

Even worse, I would say ...

I think we are aligned @matentzn I agree of course with your reasoning, but I think these issues deserve constant visibility. I am happy to share the problem with the CHEBI community and annoy also others ;-).

[matentzn]

Sounds good :) Thanks @psiotwo closing this issue here!