Mono Hierarchy Restriction

[Michael DeBellis]

I have a very basic question: what is the justification for the mono hierarchy restriction in BFO? I understand why mono-hierarchies are strongly recommended in OOP languages because which class ends up handling a message can get too complex with multiple inheritance so it is virtually always better to stick with single inheritance. But I don't see the rational for having this restriction in OWL since OWL is just set theory and it is common when modeling with sets to have elements belong to more than one set and to have sets that don't subsume each other but still have non-empty intersections. I'm sure there are good justifications for it, I've just never seen them. If anyone can point me to a paper or a place in the BFO manual that explains the rational I would appreciate it. 

Michael

[Barry Smith]

Three prongs to this, all based on the idea that if ontology developers follow a common set of traffic rules then the likelihood of interoperability of the results will be greater:

1. monohierarchy allows a common rule for definitions of terms (each definition takes the form A =def B which Cs, where B is the immediate parent of A in the hierarchy). Application of this rule breaks if there is no unique parent.

2. errors: experience shows that when polyhierarchy is allowed more errors will be made, e.g. of the form (damaged foot is a foot, damaged foot is a damage)

3. all the benefits of polyhierarchy can still be had via use of defined classes

BS   

On Mon, Jul 12, 2021 at 1:39 PM Michael DeBellis <mdebe...@gmail.com> wrote:

I have a very basic question: what is the justification for the mono hierarchy restriction in BFO? I understand why mono-hierarchies are strongly recommended in OOP languages because which class ends up handling a message can get too complex with multiple inheritance so it is virtually always better to stick with single inheritance. But I don't see the rational for having this restriction in OWL since OWL is just set theory and it is common when modeling with sets to have elements belong to more than one set and to have sets that don't subsume each other but still have non-empty intersections. I'm sure there are good justifications for it, I've just never seen them. If anyone can point me to a paper or a place in the BFO manual that explains the rational I would appreciate it. 

Michael

--
You received this message because you are subscribed to the Google Groups "BFO Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bfo-discuss...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bfo-discuss/7e7f3e70-5055-4e37-987b-d5cab234498cn%40googlegroups.com.

[David Poole]

> On Jul 12, 2021, at 10:47 AM, Barry Smith <ifo...@gmail.com> wrote:
>
> [CAUTION: Non-UBC Email]

> Three prongs to this, all based on the idea that if ontology developers follow a common set of traffic rules then the likelihood of interoperability of the results will be greater:
>
> 1. monohierarchy allows a common rule for definitions of terms (each definition takes the form A =def B which Cs, where B is the immediate parent of A in the hierarchy). Application of this rule breaks if there is no unique parent.

This is an argument *against* monohierarchies.
> A =def B which C


suppose B is also defined as
B = def S which D

therefore
A = S which D and C

which (unless C is not defined for S) is the same as
A = S which C and D

So A has two immediate superclasses:
S which D and
S which C

We just happened to give a name to the first. Often we want to give names to both.

In geology we work with tens of differentia, and there are names for all sorts of subsets of them. monohierarchies just don’t work, becuase there is no top level split which all of the classes use.

David


——
David Poole,
Department of Computer Science,
University of British Columbia,
https://cs.ubc.ca/~poole
po...@cs.ubc.ca

> 2. errors: experience shows that when polyhierarchy is allowed more errors will be made, e.g. of the form (damaged foot is a foot, damaged foot is a damage)
> 3. all the benefits of polyhierarchy can still be had via use of defined classes
>
> BS
>
> On Mon, Jul 12, 2021 at 1:39 PM Michael DeBellis <mdebe...@gmail.com> wrote:
> I have a very basic question: what is the justification for the mono hierarchy restriction in BFO? I understand why mono-hierarchies are strongly recommended in OOP languages because which class ends up handling a message can get too complex with multiple inheritance so it is virtually always better to stick with single inheritance. But I don't see the rational for having this restriction in OWL since OWL is just set theory and it is common when modeling with sets to have elements belong to more than one set and to have sets that don't subsume each other but still have non-empty intersections. I'm sure there are good justifications for it, I've just never seen them. If anyone can point me to a paper or a place in the BFO manual that explains the rational I would appreciate it.
>
> Michael
>
> --
> You received this message because you are subscribed to the Google Groups "BFO Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to bfo-discuss...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/bfo-discuss/7e7f3e70-5055-4e37-987b-d5cab234498cn%40googlegroups.com.
>
> --
> You received this message because you are subscribed to the Google Groups "BFO Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to bfo-discuss...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/bfo-discuss/CAN_82SQe%2Bvuw3H%2B3Xq9eF9gaJ%3DoFn6muADj-jiJt%2BTfYuWOC3g%40mail.gmail.com.

[Barry Smith]

On Thu, Jul 15, 2021 at 1:22 PM David Poole <po...@cs.ubc.ca> wrote:

> On Jul 12, 2021, at 10:47 AM, Barry Smith <ifo...@gmail.com> wrote:
>
> [CAUTION: Non-UBC Email]
> Three prongs to this, all based on the idea that if ontology developers follow a common set of traffic rules then the likelihood of interoperability of the results will be greater:
>
> 1. monohierarchy allows a common rule for definitions of terms (each definition takes the form A =def B which Cs, where B is the immediate parent of A in the hierarchy). Application of this rule breaks if there is no unique parent.

This is an argument *against* monohierarchies.
 A =def B which C

suppose B is also defined as
B = def S which D

 

therefore
A = S which D and C

which (unless C is not defined for S) is the same as
A = S which C and D

So A has two immediate superclasses:

S which D and
S which C

We just happened to give a name to the first. Often we want to give names to both.

In geology we work with tens of differentia, and there are names for all sorts of subsets of them. monohierarchies just don’t work, becuase there is no top level split which all of the classes use.

This happens in all disciplines. I am most familiar with medicine, where we have, for instance

meningitis =def. disease of the meninges which is infectious

meningitis =def. infectious disease of the meninges

Some people choose one, some choose the other. 

Some people think that the major axis for classifying the disease should be bodily location. Some think it should be type of disease.

If half the developers of an ontology take one route and the other half take the other route, this can cause problems. If 10 developers take 10 different routes all the more so.  

Note that enforcing one route rather than the other doesn't stop you from making any of the assertions you want to make.   

Enforcing single inheritance does indeed have a price, which is that you have to choose the main axis for your classifications. This can be hard. I would be interested in seeing examples of cases where it is impossible.

BS

 

David


——
David Poole, 
Department of Computer Science,   
University of British Columbia,   
https://cs.ubc.ca/~poole
po...@cs.ubc.ca



> 2. errors: experience shows that when polyhierarchy is allowed more errors will be made, e.g. of the form (damaged foot is a foot, damaged foot is a damage)
> 3. all the benefits of polyhierarchy can still be had via use of defined classes
>
> BS   
>
> On Mon, Jul 12, 2021 at 1:39 PM Michael DeBellis <mdebe...@gmail.com> wrote:
> I have a very basic question: what is the justification for the mono hierarchy restriction in BFO? I understand why mono-hierarchies are strongly recommended in OOP languages because which class ends up handling a message can get too complex with multiple inheritance so it is virtually always better to stick with single inheritance. But I don't see the rational for having this restriction in OWL since OWL is just set theory and it is common when modeling with sets to have elements belong to more than one set and to have sets that don't subsume each other but still have non-empty intersections. I'm sure there are good justifications for it, I've just never seen them. If anyone can point me to a paper or a place in the BFO manual that explains the rational I would appreciate it.
>
> Michael
>
> --
> You received this message because you are subscribed to the Google Groups "BFO Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to bfo-discuss...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/bfo-discuss/7e7f3e70-5055-4e37-987b-d5cab234498cn%40googlegroups.com.
>
> --
> You received this message because you are subscribed to the Google Groups "BFO Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to bfo-discuss...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/bfo-discuss/CAN_82SQe%2Bvuw3H%2B3Xq9eF9gaJ%3DoFn6muADj-jiJt%2BTfYuWOC3g%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "BFO Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bfo-discuss...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/bfo-discuss/C7778618-7448-4B97-91F7-25562DF04D99%40cs.ubc.ca.

[Chris Mungall]

David, you are correct, strict monohierarchies don't work in domains where you have multiple ways of classifying the same thing.

What I think keeps getting confused here is a general ontology engineering principle about how ontologies are built vs what the end product is that people use.

The general engineering principle is: assert monohierarchies, infer polyhierarchies. But end-users don't care. They see the polyhierarchy, which is what they need to get the right results from their queries. But as someone who builds ontologies, you will thank yourself in 2 years time if you don't assert polyhierarchies willy-nilly, because these are hard to maintain, and error-prone. Use sensible OWL definitions and a reasoner to maintain the polyhierarchy.

This is an engineering principle, and not a hard and fast rule. I have occasionally asserted dual superclasses where the polyhierchy is common knowledge and the concepts are resistant to axiomatization. I documented this, and the sky didn't fall down.

I think we have generally all agreed on this nuance as a community, but I am never sure, and frequently someone will make a sweeping statement to the effect that all polyhierarchies are evil, citing an old BFO paper, ignoring the crucial assert-vs-infer qualifier, causing no end of confusion. So much so that I wrote this in an attempt to stem the misinformation: Single Inheritance Principle Considered Dangerous

You might ask - for engineering ontologies, how do I decide which one to assert, and which to infer?

 - sometimes it doesn't matter, often you can assert to a very general genus and let your many differentia do the work of classification. See "Rector normalization" .

 - in general you should be following documented design patterns when building a large ontology and these will dictate the form of the textual and OWL definition. For the meningitis example you can see the Mondo design patterns where we have recommend structures for classifying by infectious agent and by body site and for the combination.

 - See also this summary of this excellent paper on writing good definitions from Selja Seppälä, Alan Ruttenberg, and Barry Smith

To view this discussion on the web visit https://groups.google.com/d/msgid/bfo-discuss/CAN_82SQOLvy%2BZy05hsA8%3DeDEazdr8FmUbxK%2B_a2D_sp0E2%3DKqg%40mail.gmail.com.

[Michael DeBellis]

The request for something that is impossible to model without using multiple inheritance is a strawman.  You can model things with rules, arrays,  tables, or data definitions in COBOL programs with enough effort. The question shouldn't be "is it impossible to model something without using multiple inheritance" but rather "does the benefit of excluding by fiat one of the fundamental capabilities of the OWL language exceed the cost?"  

But as someone who builds ontologies, you will thank yourself in 2 years time if you don't assert polyhierarchies willy-nilly, because these are hard to maintain, and error-prone. 

That's also a strawman. Of course if you do anything "willy-nilly" you are going to cause errors. You could say the same thing about most features of any language: "if you use Description Logic axioms willy-nilly you will also find your ontology hard to maintain and error-prone". In fact I've seen far more errors in ontologies defined by new users who put every axiom they could think of even when they weren't needed than I have from using multiple inheritance. That doesn't mean we should forbid people from defining axioms with DL it means we should provide guidance on how to use it. I agree we should also provide guidance on how to use multiple inheritance but I'm still not convinced that there is a sound reason for excluding it.

There is also the issue of refactoring. Often in the first pass of a model using multiple inheritance can be an intuitive way to start and as one proceeds it becomes obvious that certain axes should be converted to component classes rather than using multiple inheritance. That is an argument to not exclude it completely because prematurely deciding on the wrong axis for the mono-hierarchy could cause far more problems than starting with multiple inheritance and then refactoring to a mono-hierarchy based on one axis when an understanding of the best axis to use emerges. 

What I was asking for (and haven't yet seen) are papers or sections of books that describe in detail why multiple inheritance (of primitive classes) is always bad and must be excluded by fiat. For example, if I did some digging I could find some articles or books on object-oriented programming that provided detailed examples where using multiple inheritance caused problems with message handling. 

Michael

You received this message because you are subscribed to a topic in the Google Groups "BFO Discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/bfo-discuss/cLsu6sMOOqk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to bfo-discuss...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bfo-discuss/CAN9AifuVo5Hd1Y7E-1J1JzbTVFqszm92wFQp1LAN4W7azq4kQQ%40mail.gmail.com.

[Chris Mungall]

On Thu, Jul 15, 2021 at 4:23 PM Michael DeBellis <mdebe...@gmail.com> wrote:

The request for something that is impossible to model without using multiple inheritance is a strawman.  You can model things with rules, arrays,  tables, or data definitions in COBOL programs with enough effort. The question shouldn't be "is it impossible to model something without using multiple inheritance" but rather "does the benefit of excluding by fiat one of the fundamental capabilities of the OWL language exceed the cost?"  

Sorry, I am a bit lost by your phrasing, and I suspect I may have miscommunicated something.

I certainly don't want to exclude (any fundamental capability of the OWL language.

Again, this is my position: https://douroucouli.wordpress.com/2019/05/10/ontotip-single-inheritance-principle-considered-dangerous/

But as someone who builds ontologies, you will thank yourself in 2 years time if you don't assert polyhierarchies willy-nilly, because these are hard to maintain, and error-prone. 

That's also a strawman. Of course if you do anything "willy-nilly" you are going to cause errors.

I'm not just idly throwing around opinions, this is decades of experience of the group of ontologists that have built OBO, which is itself based on huge amounts of experience going back to the 90s from Rector et al. If you are building large ontologies with compositional classes, ignore this experience at your peril. 

 

You could say the same thing about most features of any language: "if you use Description Logic axioms willy-nilly you will also find your ontology hard to maintain and error-prone". In fact I've seen far more errors in ontologies defined by new users who put every axiom they could think of even when they weren't needed than I have from using multiple inheritance.

Oh I think we are in agreement here, these rococo axioms are the worst. I have seen the same thing as you, and it's a big problem. Often these decorative axioms don't reveal themselves to be problems for some time after which they can be hard to back out.

See slides 23-25 of my talk on design patterns. Ontology editors should only be authoring logical axioms if they are experts in both OWL and the domain and they are aware of all the usual traps. (this goes for FOL too of course). TNot many people have this combined expertise. This is why in OBO we have design patterns authored by OWL experts which constrain what is possible and give guidance for people doing day to day editing. See slides 26 onwards

 

That doesn't mean we should forbid people from defining axioms with DL it means we should provide guidance on how to use it.

Music to my ears! Things like the Protege tutorial are extremely helpful here (thank you for keeping this up to date). But even with good tutorials, many people just don't develop a knack.

 

I agree we should also provide guidance on how to use multiple inheritance but I'm still not convinced that there is a sound reason for excluding it.

Again, to try and be as absolutely clear as possible: MI is totally fine. But if you have a large ontology (1000s-10s of 1000s) classes which have a compositional aspect, you will have an enormous maintenance problem unless you have a strategy for inferring the majority of these.

And again, this is engineering guidance, not rules handed down by fiat from ontology gods. It's intended as analogous to "use structured programming, don't make spaghetti code with GOTOs" in SE; or Codd normalization in RDBMSs. Good engineers have a sense of when it's OK to bend the rules and novice engineers have a set of guidelines that will help them

 

There is also the issue of refactoring. Often in the first pass of a model using multiple inheritance can be an intuitive way to start and as one proceeds it becomes obvious that certain axes should be converted to component classes rather than using multiple inheritance. That is an argument to not exclude it completely because prematurely deciding on the wrong axis for the mono-hierarchy could cause far more problems than starting with multiple inheritance and then refactoring to a mono-hierarchy based on one axis when an understanding of the best axis to use emerges. 

For sure. Most ontologies I work on started as naive asserted polyhierarchies later refactored according to the Rector pattern.

 

What I was asking for (and haven't yet seen) are papers or sections of books that describe in detail why multiple inheritance (of primitive classes) is always bad and must be excluded by fiat. For example, if I did some digging I could find some articles or books on object-oriented programming that provided detailed examples where using multiple inheritance caused problems with message handling. 

Did any of the links I provided in the previous email help?

There is a lot less funding for ontologies than SE so you just aren't going to find the same level of quantitative studies. But I think there are a lot of case studies and simple lessons from experience, see many of Alan Rector's papers.

To a large extent this is common sense, just like structured programming and database normalization. If you have two trees (Skeleton ontologies in Rector's terminology) and combine them into a lattice, there is recapitulation of the skeleton hierarchies in the lattice. If you assert these multiple times you violate the DRY principle.

The the slides and papers linked from

https://douroucouli.wordpress.com/2019/06/29/ontotip-learn-the-rector-normalization-technique/

 

To view this discussion on the web visit https://groups.google.com/d/msgid/bfo-discuss/CALGFikcZOgK8OzX6TaEz%3DhA1vuh58sz2Q2SUyvrQO0XEwUt3bQ%40mail.gmail.com.

[Woland's Cat]

On 16/07/2021 00:23, Michael DeBellis wrote:

What I was asking for (and haven't yet seen) are papers or sections of books that describe in detail why multiple inheritance (of primitive classes) is always bad and must be excluded by fiat. For example, if I did some digging I could find some articles or books on object-oriented programming that provided detailed examples where using multiple inheritance caused problems with message handling. 

Michael

This is an aside, but in programming languages, MI works perfectly well if implemented properly. I can say this confidently because I have used the Eiffel language for 25 years, which does just that. It is only the terrible C++ attempt at MI that made everyone thing MI was too hard, and caused the current mainstream languages to be all SI.

--
Thomas Beale
Health IT blog | Culture blog | The Objective Stance | ORC-ID

[Anthony Petosa]

>   See slides 26 onwards

Slide 27. I would modify this slide to read as follows, starting from the top of the pyramid downward: Ontological Realism Experts, OWL Experts, OWL Modelers, OWL Model End-Users. Note, I did not include CLIF, for instance, since I thought to mention the grammar that is overwhelmingly implemented for ontological representation (i.e., OWL). Not dismissing anything else; just stating was is used in practice. The reason there are so many Rococo OWL models is primarily due to the fact that many models use OWL in a 'willy-nilly' fashion and do not first think through the problem set in terms of Ontological Realism.

[Thomas Beale]

Great references, thank you. I have to say though, from your SI post, the FMA phalanges example looks like questionable modelling, and if anything, supports Barry's argument against MI in ontologies. It is easy to see that entities called '(any) phalanx of middle finger' and 'proximal phalanx of (any) finger' as being sibling children of '(any) phalanx of (any) finger' is likely to cause problems and raises the question of what the factoring logic was. Presumably if limb or gross anatomical structure (finger, liver, etc) is logically prior to limb sub-structure (proximal / distal X, left / right X etc) then one might have expected to see

phalanx of finger  

IS-A

phalanx of middle finger

IS-A

proximal phalanx of middle finger  

with 'proximal phalanx of (any) finger' being inferrable by discovering that all 'phalanx of X finger' have a 'proximal' child?

- thomas

[Chris Mungall]

That's different from my experience - the most egregious abuses of OWL have been in attempts to overmodel ontological realism in OWL, which is often not up to the task. But we are getting into the realm of n=1 anecdata here.

Others are welcome to adapt the pyramid as they see fit - having realism experts at the top is not necessary in my experience, and can actually hinder if the realism experts are not use-case driven and focus on philosophical problems not relevant to the domain, but YMMV.

I love CLIF, hopefully there will be tool support and adoption one day.

To view this discussion on the web visit https://groups.google.com/d/msgid/bfo-discuss/f673b781-a4c1-45ac-8a3e-5b932d06f61en%40googlegroups.com.

[Anthony Petosa]

>  That's different from my experience - the most egregious abuses of OWL have been in attempts to overmodel ontological realism in OWL, which is often not up to the task.

I've seen plenty of cases where Ontological Realism is ignored with the end result being an information silo with yet another data structure representation.

I am interested in a few good examples regarding your point. Note, I am not disagreeing with you. Rather, I am curious as to the types of use-cases, with specific examples if possible, where Ontological Realism poses a challenge to its implementation in practice.