Define a continuum of OBOFoundry compatible ontologies

[ddooley]

Ontologies wishing to join OBOFoundry need to be categorized about the level of their compliance to the technical requirements of full Foundry compatibility including upper level alignment to BFO (or COB?). The idea is to provide a rough evolution path for curators to be aware of, so that ontologies which aren't really compatible can still be granted provisional membership with the provisio that they have committed to some greater end target in the spectrum. (The dashboard may also provide some metric objectives here too).

Thus an ontology having only an is-a hierarchy involving a variety of concepts that doesn't include BFO parent classes could be categorized as an "provisional member" (or better name). Another which has BFO parent classes in it, but has duplicate terms that need to be harmonized with pertinent Foundry ontologies could be called a "non-normalized member". (@pbuttigieg does this capture what you were thinking?)

The task is to define the names and definitions of these general levels of compatibility. We can get a list going below. Possibly a candidate could have a few of the following. For starters I pitch:

• Provisional member: strictly is-a hierarchy involving a variety of entity types; not organized under BFO, possibly not having Foundry compliant URIs.
• Non-normalized member: a significant portion of the terms (and relations) are already represented in one or more other Foundry ontologies, indicating future work is required to assess their MERIOT status.
• Normalized member: The vast majority of active terms native to the ontology are not duplicated elsewhere in the Foundry, or are themselves considered a core reference (allows for a few competing anatomy ontologies for example).
• BFO (or COB) integrated member: The ontology provides BFO parent classes and is satisfiable if the whole of BFO is loaded with it (if not already loaded). ...

[matentzn]

Does this relate to the distinction of domain and application ontologies?

Not sure about BFO integrated member just like that, because, imagine, all root terms simply inheriting from BFO:entity.. Maybe better to define a notion fo COB-completeness, meaning that all classes that fall under a COB concept must be aligned with it? Not sure.

[ddooley]

Re. Domain and application ontologies - not directly. One can register either in OBOFoundry but not need to commit to any further work on them if they are a "BFO integrated member". These states are just to identify evolutionary / development commitments/objectives.

[matentzn]

I have added this ticket to the next oboc meeting agenda!

[nlharris]

see also #1140 and #1213

[mellybelly]

In the past we have not required BFO (or any other upper ontology) compliance since there is no OBO principle and suggestions towards that end were not met with community consensus. Also, I don't think that an import of BFO or other upper ontology makes for a necessarily better ontology. If we do have add a principle about requiring adhering to upper ontologies, then ontologies such as COB and CARO should be included as they may provide additional support for ensuring orthogonality and consistent classification across the OBO library. Examples of use (e.g. example subclassing/axioms) for all recommended upper ontologies should be included in the principle.

[ddooley]

Ah, I see, the relationship between OBOFoundry and BFO is a bit more arms length than I thought (so some negotiation about what BFO has for a description at top of OBOFoundry ontology list?). I'll say the basic need I see that brings harmonization and validation is upper level disjointness between occurrents and continuants, qualities, ICE, material entities, etc. Relations from RO sometimes do this indirectly with domain and range constraints, but it seems to me the basic BFO (or perhaps COB) distinctions are exactly what brings patterned use - the basic language - for constructing sentences with OBOFoundry ontologies about the world.

[jamesaoverton]

This issue is narrower but related: #1126

[nicolevasilevsky]

@matentzn will address this as discussed on the OBO call (12/01/20)

[cmungall]

suggest closing in favor of #1140

[nlharris]

ok by me...