Generate an ontology that is COB rewired to OBO classes

[cmungall]

One way people could start using COB right now:

Take COB, rewire all IDs to be the corresponding OBO/BFO class IDs. Call this artefact $OBO/cob/obo-cob-subset.owl (open to better names)

People could start using this right now when building import modules for their ontologies

TBD: retain, superimpose, or remove COB axioms?

• superimpose: creates inconsistencies (e.g. CHEBI)
• retain (i.e pure rewiring). latent inconsistencies
• remove COB axioms, only use axioms from non-COB to wire upper level. This is probably safest at first.
  • variant of above: only bring in a subset of COB axioms necessary for gap filling but nothing that causes incoherencies

[matentzn]

I like the variant of the above.

[bpeters42]

I guess there are different goals: If the goal is to expose inconsistencies, we would stick to the established COB approach (using all axioms), so that is clearly not the goal here. If the goal is to have something usable now, we should still consistently push and make people aware of looming inconsistencies; otherwise I am worried that people will say 'we already adopted COB, and are so compatible...' .So I am with the variant that Nico also supported, but with the goal of constantly adding more axioms as things get resolved.

On Tue, Oct 13, 2020 at 12:38 PM Nico Matentzoglu notifications@github.com wrote:

I like the variant of the above.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/OBOFoundry/COB/issues/147#issuecomment-707964231, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADJX2IVW3TTRGNNZ7ABFYVLSKSUCJANCNFSM4SPG6AEQ .

-- Bjoern Peters Professor La Jolla Institute for Allergy and Immunology 9420 Athena Circle La Jolla, CA 92037, USA Tel: 858/752-6914 Fax: 858/752-6987 http://www.liai.org/pages/faculty-peters

[cmungall]

OK, done a first pass, this is what it looks like:

[jamesaoverton]

Use case: OBI imports BFO "classes only" http://purl.obolibrary.org/obo/bfo/2014-05-03/classes-only.owl but (in theory) this COB rewired should cleanly slot in its place. If it doesn't, it could be because OBI uses a BFO class that's not covered by COB.

[cmungall]

@matentzn asked for an implementation guide. Here is a rough sketch of how this would work

BFO ME is a root in COB-rewired, so for these ontologies

their cob_import would have a single class (for the branches) shown, with ME in it. They would add a subClassOf axiom corresponding to the edge in this diagram (or this could be extracted from a central COB bridge file)

if we look further down at DRON:

dron would have an is-a to OBI processed material. Their cob_import would therefore include both OBI PM and BFO ME. Simple.

let's look in some other spots

PATO is a root in cobrw

So PATO does not have any bridge axioms connecting to COB, it's already a root.

PATO does need to import various other ontologies for its logical definitions, so it's cob_import will reflect the extract that is done there

more later...