Re: multiple inheritance in ontolingua

Tom Gruber <gruber@HPP.Stanford.EDU>
Message-id: <199406022158.OAA27979@HPP.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 2 Jun 1994 14:58:37 -0800
To: ronny@zeppo.logica.co.uk (Ronny)
From: Tom Gruber <gruber@HPP.Stanford.EDU>
Subject: Re: multiple inheritance in ontolingua
Cc: ontolingua@HPP.Stanford.EDU

References: <9405250843.AA29539@zeppo.logica.co.uk>
            <199405312204.AA02113@quark.isi.edu>

>When describing our ontology, it happens that we introduce a multiple-
>inheritance conflict. As far as we know, there is no construction in ontolingua
>to solve this problem, i.e. to enforce the target language to decide in an
>unambiguous way when this problem arises unless you know it beforehand and
>specify the property that you want explicitly at the level where the problem
>occurs.
>
>We would like very much to know what the point of view of the ontolingua
>developers and users regarding this problem is...

As Bob MacGregor put it, resolving multiple inheritance is an issue of
nonmonotonic default logic.  I hope that the documentation isn't misleading
about this, but Ontolingua doesn't guarantee that defaults will work in
target systems (i.e., we don't do defaults).

What to do?

Although this sounds like a workaround, I would suggest that the _best_
solution would be to get consensus on the definitions of concepts in the
ontology so that there are no conflicts in inherited values or slot
constraints.  After all, the ontology is supposed to be specifying an
agreement about a shared conceptualization (prior to, and independent of
inference or the state of agents' working memory), so it ought to be
monotonic.

Failing that, I would suggest distinguishing between slot values and
default slot values as follows.  Define a facet for inherited values:

(define-relation default-slot-value (?class ?slot ?value)
  "If class C has an inherited-slot-value V for slot S, it means that the
slot _could_ have that value.  In other words, it is consistent for the
slot to have that value, but it doesn't have to.  We represent this
consistency assumption by hypothesizing that there exists an instance of
the class with that slot value.  This isn't really what is meant by
defaults, but it is sufficient to force the consistency requirement in a
monotonic system."
  :def (and (class ?class)
            (binary-relation ?slot)
            (exists (?x) (and (instance-of ?x ?class)
                              (has-value ?x ?slot ?value))))

  :issues ("This hypothesizes the existance of an instance with the default
            value.  It might be a false assumption, but it seems silly to
            say a slot has a default if nobody takes it as value."))

Then, in the definition of a class, you might assert the default like this:
In normal ontolingua syntax:

(define-class C (?x)
  :def ...
  :axiom-def (default-slot-value C S some-value))

You say it in :axiom-def instead of the :def clause because a sentence in
the :def clause would be saying something about a particuluar ?x that is
the instance of C.  In the generic frame syntax, which is succinct for
facet-like statements, it would be

(define-frame C
  :template-slots ((S (default-slot-value some-value)
                      (slot-value-type type-of-s))
                   (another-slot ...)))

Your target system gets to figure out how to merge the multiple values of a
default-slot-value facet, using whatever symbol-level trick desired.   But
the semantics of the common ontology doesn't have to depend on the
symbol-level choice.

tom