search

OBOFoundry / COB

An experimental ontology containing key terms from Open Biological and Biomedical Ontologies (OBO)
https://obofoundry.github.io/COB
Creative Commons Zero v1.0 Universal
36 stars 8 forks source link

Articulate criteria for inclusion or non-inclusion of BFO classes #13

Open cmungall opened 5 years ago

cmungall commented 5 years ago

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 https://github.com/BFO-ontology/BFO/issues/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 commented 5 years ago

I like the approach in BFO-ontology/BFO#221 https://github.com/BFO-ontology/BFO/issues/221, and in particular the use of data properties.

On Fri, Mar 1, 2019 at 5:45 PM Chris Mungall notifications@github.com wrote:

Carried on from #11 https://github.com/OBOFoundry/Experimental-OBO-Core/issues/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 https://github.com/OBOFoundry/Experimental-OBO-Core/issues/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 https://github.com/BFO-ontology/BFO/issues/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 https://github.com/OBOFoundry/Experimental-OBO-Core/issues/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