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.
> 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
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.
--
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.
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.
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.
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.
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/bfo-discuss/CALGFikcZOgK8OzX6TaEz%3DhA1vuh58sz2Q2SUyvrQO0XEwUt3bQ%40mail.gmail.com.
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/bfo-discuss/f673b781-a4c1-45ac-8a3e-5b932d06f61en%40googlegroups.com.