Document design pattern for "shadow" relations

[cmungall]

This is a brief summary, I will try and explain in more detail later

With an ontology life BFO, we end up with many entities projecting "shadows" or parallel-category counterparts:

• An island (material entity)
• The site surrounded by the island (site)
• The spatial region which the site occupies (SR)
• The history of the island (occurrent)

Also

• A disease process (process)
• A disease disposition (disposition)
• The mereological sum of qualities that have their basis in the disease (quality)
• The location of the disease process (ME)
• The site of that location (site)
• The SR which that site occupies (SR)
• A disease diagnosis (GDC)
• A concretization of the diagnosis (SDC)
• etc

Also

• The function of a macromolecule
• The macromolecule
• The activity of that macromolecule as it exercises it's function
• The GDC that is the sequence of that macromolecule
• The representation of that GDC as an information artefact in a computer

And so on

I believe I just invented the term "shadow" in this context but I am sure I am not the first to try and formalize this.

We have projection relations (again, my terminology) that project between these. These are generally 1:1 (modulo temporal considerations for now). An example is the occupies relation #310

In my experience, users of ontologies such as curators will often select the wrong relation R to connect two domain classes or individuals A and B, when A and B are from different shadow categories AC and BC. This happens if R holds only between AC-AC or BC-BC. This happens even with experienced ontology developers. A recent example from ENVO was using has-part to connect a site to a material entity, which is invalid. The solution here is to use the appropriate projection relation, in order to get A and B to a place where they can talk to one another. i.e. rather than saying A SubClassOf R some B, we say A SubClassOf P some (R some B).

Another problem is the need to either make shadow relations (which has bad engineering consequences when working with OWL), or the need to make complex axioms like A SubClassOf P some (R some (inverseOf(P) some B)).

I would like this to be documented better, as I believe it is a frequent tripping up point for ontologies developed with BFO as an upper ontology. Many people may be creating incoherent ontologies but be unaware of it as they are underusing reasoning. I think a good start is to document all projection relations (e.g. tag them) and define a general DP.

I happen to think this is all very abstract and complicated - but is necessitated if one has an ontology with parallel shadow categories (or if you are connecting two ontologies with entities in shadow categories). For this reason I am starting to be very against proliferation of categories, and favor having very strong use cases for committing to additional categories/upper classes. I will write more on this topic in another forum...

TODO:

Document the connection between this and the need to often create various combinations of union classes, see Shulz disease ontologies paper...

[github-actions[bot]]

This issue has not seen any activity in the past 2 years. It will be closed automatically 60 days from now if no action is taken.

[github-actions[bot]]

This issue has been closed automatically because it has not been updated in over two years. Please re-open if you still need this to be addressed.