Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Discussion: Define the relationship between COB and RO #260

Open
matentzn opened this issue Apr 4, 2024 · 7 comments
Open

Discussion: Define the relationship between COB and RO #260

matentzn opened this issue Apr 4, 2024 · 7 comments

Comments

@matentzn
Copy link
Contributor

matentzn commented Apr 4, 2024

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

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
Copy link
Contributor Author

matentzn commented Apr 4, 2024

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 \

@matentzn matentzn changed the title Discussion: COB depends on RO, what to do with the RO dependencies? Discussion: Define the relationship between COB and RO Apr 5, 2024
@anitacaron
Copy link

Bring this related discussion here.

@matentzn
Copy link
Contributor Author

matentzn commented Apr 5, 2024

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
Copy link
Contributor

cmungall commented Apr 5, 2024

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:

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
Copy link
Member

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
Copy link
Member

wdduncan commented Apr 5, 2024

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

@cmungall
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants