Discussion: Define the relationship between COB and RO

[matentzn]

At the moment (perhaps that is wrong), COB imports RO, I am assuming because it is integrating RO properties like:

COB/src/ontology/components/cob-to-external.tsv

Line 116 in 9bf639a

COB:0000047 has part owl:equivalentProperty BFO:0000051 has part . semapv:ManualMappingCuration

Is this correct, or should we simply remove the RO import altogether? Wouldn't most of our COB validation infrastructure also require importing the RO property semantics to work?

Note: I think if, roughly speaking, COB is our core ontology (classes), RO our relationship ontology and OMO our metadata ontology, a bit of interdependency is hardly avoidable, may I could be wrong.

In case we want to import mapped properties from RO correctly, while faithfully reflecting their semantics (domains, ranges etc), we need to import not just RO but all of the RO dependencies. That is quite a lot of ontologies we need to consider.

My sense is that instead of doing the usual (using base files), we should simply import from ro-full.owl, and remove all COB related stuff during postprocessing. That way, we get the important axioms we need between say UBERON and IAO classes from RO full for reasoning, without the need of having IAO, UBERON and many others being direct dependencies of COB.

If we just import RO-base, this is also possible, but we will loose some domain range constraints logic.

see #258

Or we ditch the import - I am not sure that is correct as we will have some naked (semantic-less) RO properties in COB.owl.

[matentzn]

For now I decided on an anti-base approach, which is the closest to what we want I think;

https://github.com/OBOFoundry/COB/pull/259/files#diff-b5cff610e700b24d9b974278f2e29dce8d3b5a1cf28d60c34e4e6fc0f6907203R109

Basically deleting everything pertaining to the COB namespace, but keeping the rest of the axioms in the full release.

remove --base-iri http://purl.obolibrary.org/obo/COB_ --axioms internal --preserve-structure false --trim false \

[anitacaron]

Bring this related discussion here.

• Remove redundant domain in occurs in (BFO:0000066) oborel/obo-relations#797

[matentzn]

Oh wow. This makes the issue much bigger:

1. COB defines, for example, a relation "occurs in" which is mapped to RO BFO:0000066.
2. This relationship has a domain "process". In RO its only "occurrent".
3. When RO imports COB, it also "inherits" that domain form COB.

So, we now have two places where we update core relations. How to deal?

[cmungall]

There are some very complex nuanced issues here. I have talked about this on various calls and issues but have not had time to coalesce everything.

Basically I think we need to expressionize domains and range
https://docs.google.com/presentation/d/1VU9nS_QBy-OLv2WjlbBeX_lD2mU4vVH4Oqqm5yGNMKc/edit#slide=id.p

See:

• Create a release product that uses COB as upper ontology oborel/obo-relations#780

However @jamesaoverton and @bpeters42 are not keen on this. I don't want to misrepresent the position but very briefly the alternative is to match D/Rs to "closest" COB class and I haven't had time to write down why this won't work...

[jamesaoverton]

I propose to replace RO domains and ranges that we don't want in COB (e.g. BFO 'independent continuant') with disjunctions of terms that we do want in COB, e.g. 'independent continuant' -> "'material entity' or 'immaterial entity'". I've done this for RO core relations in the context of OBI, and it seemed to work fine.

[wdduncan]

FWIW, I like @jamesaoverton proposal. It seems more straight forward to implement.

[cmungall]

It looks like we're now forking this discussion. Please see the slide deck linked here: oborel/obo-relations#780