Articulate criteria for inclusion or non-inclusion of BFO classes

[cmungall]

Carried on from #11

OBO-Core will consist of:

1. classes from upper levels of domain ontologies
2. some subset of BFO
3. subClassOf axioms connecting the two (which ideally come from the domain ontologies, but may may inject at first)

One of the use cases (presumably, but this should be explicitly stated somewhere) is that domain ontologies should only need to import obo-core and not BFO in their release version. This provides a more usable upper level.

What are the criteria for deciding on the subset of 2? We may have different implicit ideas, see #11. For example, a usability criteria is to remove as much abstraction as possible and make it user friendly.

However, an engineering consideration is that any class that is required for reasoning must be present in the domain ontology. This often entails including the superclass closure (or more formally, the SLME module) of any referenced BFO class. i.e. we end up pulling in everything in bfo above a certain level.

The alternative is to use the BFO "bokeh" pattern BFO-ontology/BFO#221. This adds additional complexity to the build process but has good usability outcomes

Are we all aware of these tradeoffs, should we discuss further on a call? @bpeters42 @jamesaoverton @rctauber @dosumis ?

[bpeters42]

I like the approach in BFO-ontology/BFO#221 <BFO-ontology/BFO#221>, and in particular the use of data properties.

…

On Fri, Mar 1, 2019 at 5:45 PM Chris Mungall ***@***.***> wrote: Carried on from #11 <#11> OBO-Core will consist of: 1. classes from upper levels of domain ontologies 2. some subset of BFO 3. subClassOf axioms connecting the two (which ideally come from the domain ontologies, but may may inject at first) One of the use cases (presumably, but this should be explicitly stated somewhere) is that domain ontologies should only need to import obo-core and not BFO in their release version. This provides a more usable upper level. What are the criteria for deciding on the subset of 2? We may have different implicit ideas, see #11 <#11>. For example, a usability criteria is to remove as much abstraction as possible and make it user friendly. However, an engineering consideration is that any class that is required for reasoning must be present in the domain ontology. This often entails including the superclass closure (or more formally, the SLME module) of any referenced BFO class. i.e. we end up pulling in everything in bfo above a certain level. The alternative is to use the BFO "bokeh" pattern BFO-ontology/BFO#221 <BFO-ontology/BFO#221>. This adds additional complexity to the build process but has good usability outcomes Are we all aware of these tradeoffs, should we discuss further on a call? @bpeters42 <https://github.com/bpeters42> @jamesaoverton <https://github.com/jamesaoverton> @rctauber <https://github.com/rctauber> @dosumis <https://github.com/dosumis> ? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#13>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANN9IuYzCTzMBDiLQg4reFzySA01YAJjks5vSdfVgaJpZM4baGFJ> .

-- 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