Document policy for implicitly mirrored relations with the same label

[cmungall]

We have some cases where a relation in RO and a relation in BFO have different IRIs and the same label

1. This used to be the case for http://purl.obolibrary.org/obo/RO_0000052 (previously called "inheres_in") and BFO:0000197 which has the rdfs:label of "inheres in" in http://purl.obolibrary.org/obo/bfo/2020/bfo-core.owl (for simplicitly we are only talking about the non-temporalized version of BFO, there are other issues for the temporalized, let's not mix concerns here)
2. This is still the case for located_in http://purl.obolibrary.org/obo/RO_0001025 / http://purl.obolibrary.org/obo/BFO_0000171.

I will call these "implicitly mirrored relations". It is implicit because there is no formal axiom guaranteeing any kind of consistency. But there is an arguable implicit contract here based on the fact we want to be consistent in our terminology.

Please note: this issue is not for discussing whether one of these IDs should be ceded in favor of the other. Please consult the existing RO documentation and discuss this in the appropriate place, not here. The fact is that implicit mirroring exists and we should have better guidance.

I propose we crystalize existing practice:

1. If a BFO term and RO term are implicitly intended to be aligned (different ID/IRIs same label) then logical axioms should be logically consistent. Non-logical axioms such as text definitions should be consistent but may be worded differently.
   • precedent: located_in. See should contained_in be a sub-property of located_in? #693
   • concretizes (under discussion): See add process to domain to range of concretizes #650
   • note that this does not preclude structural rewrites that are entailment preserving. See the discussion in should contained_in be a sub-property of located_in? #693 how we have two D and two R axioms on located_in
2. If there is need for aligned IDs to become decoupled then RO is free to give a different label (provided we have agreement and we give the community warning of course)
   • precedent: inheres_in changing to characteristic_of in 2018: This is a proposed update that changes inheres in to the characteristic of model #284
3. RO can always add completely new relations with desired D/Rs if the BFO one is too abstract

[bpeters42]

Discussed on 10/7 call: There is broad support for this proposal to 'crystalize existing practice'. We are assuming that with this agreement we would start to go through relations and execute? @cmungall is that what you had in mind?

Bill Duncan points out that in some cases it needs to be clarified what version of BFO is being referred to in this alignment.