Re: question: datatype reasoning?

On January 29, Jim Hendler writes:
> 
> At 16:38 -0500 1/29/03, Peter F. Patel-Schneider wrote:
> >From: Jim Hendler <hendler@cs.umd.edu>
> >Subject: question: datatype reasoning?
> >Date: Thu, 23 Jan 2003 21:25:50 -0500
> >
> >>
> >>  I was asked the following by a colleague, we tried to find the answer
> >>  in the Semantics document, but we couldn't quite work out the
> >>  details.  Question is, does a complete Owl Lite or DL reasoner have
> >>  to do complete datatype reasoning?  i.e. for all the XML schema
> >>  primitive types, does a complete OWL reasoner have to be able to do
> >>  the correct class reasoning, etc -- knowing integers are numbers,
> >>  URIs are strings, etc. and appropriately applying these.
> >
> >A complete OWL reasoner does have to do reasoning with numbers, etc.
> >As Ian has pointed out, the design of OWL DL has been carefully worked out
> >so that this is not as hard as one might think.
> >
> >>    If the answer is that an OWL system must do so, do we have any
> >>  implementation evidence to offer in this space?  If we don't expect
> >>  complete datatype reasoning, what level of such do we expect, and
> >>  where will we specify it (document-wise)
> >
> >RACER handles lots of inferences with respect to such datatypes, in a
> >even-more-powerful datatype theory.
> >
> >>    thanks
> >>    JH
> >
> >peter
> 
> Speaking as chair:
> 
> 
> Let me be even, even, even clearer -
>   Which document says what is and is not expected to be implemented?
>   Which document says what datatype inferences are required to be a 
> complete reasoner for Lite, DL, Full?
> 
> The fact that DL and Racer can handle some datatypes is not what I am 
> asking - I am asking exactly what an OWL reasoner is expected to do 
> to be considered complete (or, rhetorically questioningly, are we 
> giving up completeness as a requirement for Lite and DL, in which 
> case why do they exist??)
> 
> In short, if this is in a current document - where is it?  If not, 
> where will it go.  We cannot have a language specification that 
> doesn't bother mentioning some large part of our spec.
> 
> If there is a particular datatype theory we expect, then we must 
> specify it.  If these isn't, we must say what is expected
> 
> I don't see how we can go to LC with a major part of our expectations 
> on implementations unspecified.
>   -JH
> 
> Taking off my chair hat -- personal opinion:
>   I think that we shoudl try to set minimal expectations on datatype 
> reasoning, letting good systems get a benefit by offering more, but 
> still considering systems to be complete OWL reasoners if they don't 
> handle all datatype cases -- I think we should basically say correct 
> handling of strings and integers (w/some definition) is all that is 
> required and leave everything else gravy.
>   Otherwise, I think we can spend months arguing details
> 
> Consider this for your headache pleasure -- if I give you an 
> allDifferent list with 366 instances of type xsd:date all of which 
> have the same year, then this document is consistent if that year is 
> a leap year, but inconsistent if it isn't (and I believe that 
> specifying the axiomization of what is and isn't a leap year requires 
> expressivity way beyond what we expect in an OWL reasoner.)

Just to follow up on what I said on the telecon. 

Firstly, the allDifferent list would necessarily be OWL full as in OWL
DL it could only be applied to individuals, and as OWL full is
necessarily incomplete the problem of what to do with it doesn't
arise. The only place that data values can occur in OWL DL/Lite is at
the end of datatype properties, and the only way this kind of
inference can arise is through the use of cardinality restrictions on
datatype properties. E.g., if the type system we adopt allows me to
specify a sub-range of date, I could talk about the intersection of a
minCardinality 366 restrictions on some date property and an
allValuesFrom restriction on the same property with the range being a
suitable 1 year sub-range of date. A reasoner can deal with this by
asking the type-system "oracle" if it is possible to have x1,..,x366
s.t. they are all values of the given type and all pairwise not equal.

As for as the question of completeness is concerned, I agree with Jim
that demanding complete reasoning of this kind for all XMLS/RDF
datatypes may be setting the bar impossibly high. I think we should
allow implementors to support subsets of the the available
datatypes. Maybe we should, as Jim suggests, specify some minimum set
of datatypes that need to be supported. A reasoner could then claim
completeness if it was complete *for the datatypes it
supported*. Users would be able to choose a reasoner that supported
the datatypes they needed in their application.

Regards, Ian

Received on Tuesday, 4 February 2003 05:47:56 UTC