New term 'has characteristic' and inverse (formerly: inheres in/bearer of) changed meaning and violates BFO

[mark-jensen]

I'm a bit late to the party here, but: We just updated the CCO to use the latest RO and was surprised to see in the definitions for these terms (RO_0000052 & ..53) a major change from their previous versions. RO is now allowing these terms to relate a SDC to any other entity, not just an IC, despite BFO making very clear [050-003] that an SDC depends only on an IC which is not a spatial region. Unless, I misunderstand the interpretation.

More pragmatically: Why were these terms not deprecated and replaced with new ones since their meanings are now different? Is that not best practice when a potentially breaking change is introduced by redefining a term? Depending on usage, e.g., asserting quality RO_0000052 process, other users of RO could start to see undesirable results if they have used the prior interpretation of RO_0000052 & 53 while integrating with other data that uses the new one.

[cmungall]

They were not deprecated as the meaning was unchanged, these were always used in the more general sense.

On Fri, Mar 10, 2023 at 10:11 AM Mark Jensen @.***> wrote:

I'm a bit late to the party here, but: We just updated the CCO to use the latest RO and was surprised to see in the definitions for these terms (RO_0000052 & ..53) a major change from their previous versions. RO is now allowing these terms to relate a SDC to any other entity, not just an IC, despite BFO making very clear [050-003] that an SDC depends only on an IC which is not a spatial region. Unless, I misunderstand the interpretation.

More pragmatically: Why were these terms not deprecated and replaced with new ones since their meanings are now different? Is that not best practice when a potentially breaking change is introduced by redefining a term? Depending on usage, e.g., asserting quality RO_0000052 process, other users of RO could start to see undesirable results if they have used the prior interpretation of RO_0000052 & 53 while integrating with other data that uses the new one.

— Reply to this email directly, view it on GitHub https://github.com/oborel/obo-relations/issues/694, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAMMOJCHMQF2ADGL7SIZUTW3NVD3ANCNFSM6AAAAAAVWZDCVI . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[wdduncan]

From what I recall, BFO always only permitted SDCs to inhere in ICs (sans spatial regions). However, this was impractical b/c other ontologies needed define so-called "qualities of processes". The question of "qualities of processes" lead to development of process profile, which was not accepted by the community at large.

So, permitting SDCs to inhere in processes became a de facto practice, even though though this practice was not in line with the BFO specification. However, this happened a while ago and there may be parts of the story I am misremembering.

[cmungall]

This is correct, and apologies for the brevity of my earlier message @mark-jensen

I have been meaning gather the relevant different strands of documentation here, but here is the brief history

In the 00s, the PATO community decided to adopt BFO (this was in itself quite an involved process that not everyone agreed on). Specifically, this meant (1) adopting inheres_in (2) rooting the root of PATO in BFO quality.

At this time, and is still the case, PATO had many of what we started calling "qualities" (previously "attributes") as being applicable to processes. Heart rate being the exemplar. It is important to note that at the time the PATO community made this decision, qualities of processes was not sanctioned by BFO.

An early marker paper here was Representing Phenotypes in OWL, presented at OWLED 2007. That paper itself was based on A Formal Theory of Substances, Qualities, and Universals, by Neuhaus, Grenon, and Smith, from 2004, which allowed qualities of processes.

Some time after that, BFO went from becoming a paper ontology to a computable artifact, and at that time, the restriction prohibiting qualities of processes went into place. This was done without consulting the community using the ontology, and there were repeated pleas to restrict this or at least justify this, but this was not successful. So for a while things were in an odd state, with one of the main ontologies used for representing phenotypes apparently contradicting the upper ontology being used.

As @wdduncan states, at one point "process profiles" were added to BFO but various issues were pointed out on the mailing list. And I believe this class has been deleted from the latest BFO (despite some OBO ontologies using this)

There was a lot of back and forth, but eventually a resolution was reached at the 2018 RO Denver meeting. There were a lot of representatives from OBO and BFO at this meeting, including Barry. I can't seem to find the internal notes, we were all unanimous that the solution should be for RO to make a more general relation. @leechuck made this PR in this repo, based on agreement reached at this meeting:

• https://github.com/oborel/obo-relations/pull/284

At the Denver meeting we discussed extensively where obsoletion or broadening the exiting URI was best. We all agreed that reuse was best as in fact the relation had always meant the same thing as far as RO and its users was concerned.

Despite reaching agreement, we had a further 3 years of discussions and announcements before this was finally merged (in #442), as we wanted to make sure everyone fully understood this change and had time to prepare for it. Like all such things, we could probably have done a better job.

Also relevant: https://github.com/OBOFoundry/COB/issues/65

I'll close this now but feel free to continue discussion, if anyone has additional links to meeting notes etc it would be useful to record here.

Apologies if this caught you unawares @mark-jensen. Right now there are no plans to add the more specific BFO-equivalent relation in RO but others are welcome do this in other ontologies if they feel having this oddly constrained axiom provides value. Hope this helps!