Re: defaults

From: Frank van Harmelen <Frank.van.Harmelen@cs.vu.nl>
Subject: Re: defaults
Date: Tue, 22 Jan 2002 17:46:27 +0100

> "Smith, Michael K" wrote:
> > 
> > It seems clear that we cannot impose default reasoning on our description
> > logic framework.
> > 
> > If defaults are really needed to support an 'input completion' model, there
> > is a potential, but ugly and partial, solution.  At the f2f we identified a
> > number of features we seem to be leaning towards that will not be given a
> > semantic interpretation by any formal definition.  This broad category of
> > annotations includes support for versioning (though this could be made part
> > of the namespace formalization), lexical labeling, and perhaps 'frame
> > description' information (designed to recapture details of the original
> > input grouping of statements).  All of these elements will have an
> > operational significance for various uses of OWL, but no semantic weight.
> 
> And Tim Finin wrote:
> 
> > I think the only answer to providing some support for defaults is to do it
> > they way it's been done in KL-TWO (as I recall) and Classic.  The idea was,
> > if I remember right, to include conventions for providing defaults that
> > was outside the core of the language and for which no semantics was given.
> > This would give people with a strong need for working with defaults a
> > standard way to do it in OWL without doing damage to the semantics of
> > the core language.  Perhaps a few years of experimentation 
> > with the mechanism would help us engineer a better solution.
> 
> I want to add my voice to the above. 
> 
> - On the one hand, we will not be able to come up with a treatment of
> defaults that is both commonly accepted, formally sound and
> computationally tractable (we seem to have wide agreement on this) 
> 
> - On the other hand, there are many application areas where some form of
> defaults are absolutely required, and in fact provide some of the main
> justifications over purely text-based solutions. (We seem to have some,
> but perhaps not universal agreement on this) 
> 
> Like Mike and Tim above, I think we should simply provide the syntactic
> hooks for "defaults" (whatever they may mean), so that implementors can
> do with it what they like. (This puts defaults in the same category as
> version-labelling, I would think).  

I think of Michael's and Tim's suggestions as diametrically opposed.
Michael is asking for something outside of the logic underlying OWL;  Tim
is asking for some ability to affect the logic underlying OWL in an
undefined way.

I view Frank's attempt to merge the two as the worst possible approach.
(No joke.)  It manages, in one small package, to
1/ destroy any possible semantics we choose to supply
2/ make it look as if we are actually doing something about defaults
3/ give implementors permission to do whatever they want and claim that
   they are just following the standard

> To be clear: I don't particularly like this approach (I don't think
> anybody does), but it is  simply a practical way out of a thorny issue.  

Expediency is terrible reason to do something that violates one's
fundamental principles!

> Frank.
>   ----


All that said, there will be a part of OWL that is not part of the logic
underlying OWL, or, at least, that I hope will not be part of the logic
underlying OWL.  This is precisely the part of OWL that deals with
ontologies (or documents, or ...).  Yes, this part of OWL interacts with
the logic underlying OWL, and, maybe, there could be a formal treatment of
it, but it does not inhabit the same conceptual space as interpretations,
models, and entailment.

Such constructs (e.g., daml:imports) can indeed have impact on the
behaviour of OWL implementations, of course, but this is generally in terms
of determining what pieces of syntax are fed into an OWL reasoner, and
definitely not in terms of affecting the OWL reasoner in any other way.

It may turn out that there is a way of making some version of defaults fit
into this part of OWL.  I expect that any such version of defaults will be
a very weak (or very strong) version of something like input completion.


peter

Received on Tuesday, 22 January 2002 12:37:56 UTC