Re: defaults

>
>Hmm, very unlikely?  Not by my metrics.  My understanding is that
>
>         Student => Person
>         Employee => Person
>	Student - employmentCategory -> notWorking
>	Employee - employmentCategory -> working
>	John -> Student
>	John -> Employee
>
>is a perfect tie by that heuristic, as is the Nixon diamond.


One possible solution which avoids 'non-clean' tie-breaking and 
mantains much of the spirit of defaults is as follows.

Assume we have a frame language with the following properties.

1) Slots can have multiple values

2) There is both a 'value' facet and a 'default-value' facet.

3) values are of course non-overridable (i.e., they are definitional)

4) default-values can be overridden

Let's suppose frame f1 inherites default value d1 for slot s1 from 
superclass super1.  We then say that  the triple (f1 s1 d1) holds 
unless one or both of the following conditions apply:

	a) (f1 s1 v1) holds for some non-default value v1
                    b) (f1 s1 d2) holds for a default value d2, 
inherited from class super2,
                          and super2 is a subclass of super1

The advantage of this solution is that it does not try to come up 
with random mechanisms to solve the kind of ties that occur in the 
Nixon diamond.  It only requires a small change to the notion of 
default. A default is not seen any longer as something which applies 
unless something else applies.  Now a default is something which 
holds unless something else rules it out. So, in teh nixon diamond 
you will simply have both defaults applying. If the slot in question 
has max-cardinality 1, then a constraint checking mechanism will 
signal a constraint violation and the knowledge engineer will have to 
fix the model. If no cardinality constraint applies, then it means 
that it is OK for multiple defaults to apply for this particular 
slot.  Of course the two defaults may be mutually inconsistent, but 
this case will be no different from what could happen with ordinary 
values. If the language allows multiple values for a slot, then of 
course somebody may end up with x and the-opposite-of-x as values for 
the same slot of the same frame.

This mechanism works fine for frame systems in which subclass-of 
chains cannot have circularities. Given that daml+oil admits 
circularities, condition (b) above would have to be modified, to 
avoid a default overriding itself.


Enrico

Received on Thursday, 24 January 2002 09:58:32 UTC