Provide guidelines discouraging BFO shadow classes

[cmungall]

The use of BFO encourages redundant representation of the same concept across multiple ontologies, where there is a single core concept and many 'shadows'. Examples:

• air temperature, air temperature measurement, air temperature datum (e.g https://github.com/EnvironmentOntology/envo/issues/387)
• various disease shadows, etc. See e.g. http://www.ontobee.org/search?ontology=IDOBRU&keywords=human+brucellosis&submit=Search+terms
• physical geographic areas and their abstract 2D immaterial counterparts

Counter-examples would be something like COVID-19 and SARS-CoV-2 -- even though infectious disease hierarchies may shadow virus hierarchies, these represent what most biologists would agree are truly distinct concepts, with different nomenclature, specialities, etc.

My own view (which may not be shared by others in OBO, but which is based on extensive experience) is that these are deeply problematic for many reasons including:

• they confuse users
• they serve no real user requirements, only ontologist requirements
• they are frequently incorrectly logically encoded
• they lead to ragged lattices
• they complexify existing difficult modularity issues
• shadow hierarchies typically fall out of sync
• even where exemplary practices are followed (e.g. rector normalization) OWL has well-known shortcomings e.g for shadowing a partonomy

Even if we cannot reach consensus here, we desperately need to issue guidelines concerning the ontology scope principle.

Consider the situation where I maintain an ontology with class "Foo", and an ontologist wants a class "Foo datum". I consider "foo datum" to be trivial and confusing and do not want to include it in my ontology. The ontologist therefore goes ahead and adds "foo datum" to their application ontology which is much narrower in scope than is appropriate for the Foo concept.

How do we resolve these situations? Should it be a freeforall with "application ontologies" creating shadow classes? Should I be compelled to accept "Foo datum" in my ontology? Should we create a single dump autogenerated robot/dosdp template driven ontology called the "Datum" ontology that auto-shadows massive chunks of OBO?

The above scenario may hold for other kinds of shadows beyond Datum shadows.

[ddooley]

I really really like the idea of a Datum ontology operating directly off of given branches or terms from OBOFoundry ontologies. Most of your points seem to support it. Such confusion about "temperature of air" vs "air temperature datum" out there. Separating it into a Datum ontology with 'is about' linkage to source ontology would help in the MIEROT phase of ontology building with simple instructions: "If you see an ontology entity representing a quality or characteristic you need to measure, find the corresponding measure in the Datum ontology."

About the hypothetical Datum ontology structure ... I've cut it for later discussion.

[matentzn]

My still limited experience with OBO suggests that this ticket is already about 5 levels too complex to be dealt with coherently. I don't know now whether I should address and give an opinion on every single assumption, or comment on the overall problem - maybe this is best proposed on a call so that at least we know what the practical consequences are.

[smrgeoinfo]

Perhaps thinking about this in a W3C Semantic Sensor Network (SSN) context would help.

• Air temperature is a phenomenon that we can 'observe/measure'. There are lots of possible contexts/intentions (surface, inside my lab, at 100 mBar in atmosphere...), and measurement procedures that might be used for this observation.
• Air temperature datum (ignoring the ambiguity of the word datum-- see defs ) is an Observation Result-- it has a binding with the phenomenon, with the procedure by which the result was obtained, and with the 'featureOfInterest' (that context/intention thing).

[wdduncan]

Perhaps some guidance is needed about when (or why) one would need to create a "shadow class" (such as "temperature measurement datatum")? Or we could to some kind of agreement about how represent such datums? E.g.:

:temp1 a :temprature-air-quality;
   inverse(:is-about) [a :datum; owl:hasValue "0 Celsius", "32 Fahrenheit"] .

[cmungall]

@matentzn - my proposal is to recommend against creating shadow classes. If shadow classes are to be retained, then proponents need to do more work to address existing problems. How are these axiomatized? Who owns them? How do they related to the scope requirements?

@ddooley - that proposal is a good starting point for proponents to flesh out. I assume that this would be largely automated, with rules for which terms can be shadowed for different aspects. Details that need worked out include design patterns and how the two hierarchies will stay in sync. I think you will find you need a functional + inverse functional OP to use here, and even then shadowing existentials is a known issue.

@smrgeoinfo - I like SSNO, it is very practical. But I don't think SSNO compels you to have parallel semi-redundant hierarchies that frequently fall out of sync. This is my objection.

@wdduncan - yes, my objection is to duplication/redundancy with classes, as you point out it is trivial to still have instances of the shadow that leverage the core class (but you need a functional + inverse functional OP)