RO core imports minimal classes

[mark-jensen]

Users of BFO are being instructed to import the classes only version of BFO found here

and the RO core found here

Due to RO core having a minimal subset of BFO classes, this leads to duplication of some labels, defintions and so forth.

Why does RO core need to import the BFo classes? Any way to resolve this?

@cmungall @jamesaoverton @zhengj2007

[cmungall]

They're required for domain and range constraints, and other axioms.

I guess we could refactor further, split into a

1. bridging axiom module,
2. an import module,
3. and a core-core

So BFO could bring in 1 and 3 and ditch 2.

But this kind of thing happens all over the place and we have no good general solution. It's far worse for more dynamic ontologies. See https://github.com/ontodev/robot/issues/38

BFO could also just make its own RO core mirror e.g. as bfo/imports/ro_import.owl, but the modularization may not be straightforward see #106

[zhengj2007]

Hi Mark,

If the BFO classes are defined exactly in both BFO 2.0 and RO, it won't show duplicated labels, definitions, etc. when you view the ontology in Protege or after merged them in one OWL file. However, I found the same issues since sometime the labels, definitions provided as English in one OWL file but String in another OWL. If we can keep them same, the issue can be solved even RO import BFO.

Jie

On 4/8/2016 12:29 PM, Mark Jensen wrote:

Users of BFO are being instructed to import the classes only version of BFO found here http://purl.obolibrary.org/obo/bfo.owl

and the RO core found here http://purl.obolibrary.org/obo/ro/core.owl

Due to RO core having a minimal subset of BFO classes, this leads to duplication of some labels, defintions and so forth.

Why does RO core need to import the BFo classes? Any way to resolve this?

@cmungall https://github.com/cmungall @jamesaoverton https://github.com/jamesaoverton @zhengj2007 https://github.com/zhengj2007

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/oborel/obo-relations/issues/107

[nlharris]

What is the status of this?

[nlharris]

Can this be closed?

[gouttegd]

The problem is still very much present.

RO contains (in the bfo-classes-minimal.owl component) definitions for some BFO-owned classes that conflict with the definitions found in BFO itself. I guess those definitions were aligned with the BFO definitions at some point, but over time BFO definitions have been updated and those changes have not been reflected in bfo-classes-minimal.owl (that component seems to be manually maintained).

This causes issues as soon as one tries to import both BFO and RO in the same ontology.

There would be several approaches to fix the problem:

1. Replace the manually maintained bfo-classes-minimal.owl component (along with the bfo-axioms.owl component, which contains disjointness axioms) by a proper ODK-style import module, and get the BFO classes needed in RO from that module. This would be the best solution IMHO.

2. Keep the bfo-classes-minimal.owl component, and simply update the definitions it contains to align with the current definitions in BFO. This would be the “least invasive” solution, but it can only be temporary as it is bound to break again next time changes happen in BFO.

3. Alternatively, keep the bfo-classes-minimal.owl component, but remove the definitions from it, so that there would be no risk of conflicts with the BFO definitions.

4. Alternatively, keep the bfo-classes-minimal.owl component exactly as it is, but strip the definitions at release time, at least in the -base product.

[wdduncan]

I think bfo-classes-minimal.owl was used for BFO-2. Before we create ODK workflows to maintain it, we may want to determine if BFO-2 is still actively maintained.

I do not think it is. BFO development is now active in BFO-2020. Perhaps @phismith or @alanruttenberg can comment on the current status of BFO-2?

[matentzn]

Nice call @gouttegd thanks for having investigated this issue! Very valuable. Can you see how a BFO BOT module would differ from BFO-minimal + BFO axioms?

[gouttegd]

I’ve just pushed my branch (#707) if you want to look at it yourself.

Of course, if BFO-2 is indeed “frozen” and will never change again, then option 2 (keeping the manually maintained copy within RO after updating just once to match the latest definitions in BFO) becomes viable – though I still think a proper import would be cleaner.

[gouttegd]

This was fixed by #709, which implemented option 2 described in my comment from 27 March.

[zhengj2007]

I think the bfo-classes-minimal.owl was made from BFO Graz version which is not an official release. Later I made the BFO2.0 official release that contains only BFO classes request by Barry in 2019. I think we should switch to BFO-2020 which is an ISO version. However, it contains relations, some might be conflicting with RO relations. If we decide to use BFO-2020, we may need to request to have a class only version.