SEM: 5.1 literal/data values was RE: ADMIN: Minutes of telecon 11th July 2002

I was and remain underwhelmed by the discussion.

> Can I point out that I already did this once! See the thread beginning
> with:
> and in particular:

To recap ...

> > Unfortunately, the interaction of UnambiguousProperty and datatypes
> > makes this problematical. Imagine, for example, that a datatype
> > consisting of integers in the range 0-999 is used as a unique-id/key
> > for instances of the class Person such that all persons have exactly
> > one unique-id, all unique-ids are integers in the range 0-999, and
> > unique-id is an UnambiguousProperty.  In order to function correctly,
> > a reasoner is now required to understand the properties of datatypes,
> > e.g., that the cardinality of this particular datatype is 1,000, and
> > that as a result no model can contain more than 1,000 instances of
> > Person (note that this would not be the case if unique-ids were reals
> > in the range 0-999).
> Can't I set up this example without any recourse to datatypes at all.
> e.g.
> I form one thousand URIs.
> For each one I form the class: oneOf[x] (giving me 1000 classes).
> I form the disjoint union of these 1000 classes, giving me oneOf 1000
> distinct URIs.
> You are missing the crucial point that the reasoner has to know about
> the properties of the datatype (i.e., that there are exactly 1,000
> integers in the range 0-999, neither more nor less) and may also need
> to consider complex interactions resulting from the predicates defined
> on the datatypes. This is what makes the formal properties unclear and
> could lead to decidability problems.

To give an example of a problematic datatype, in XML Schema we could construct a
datatype consisting of all two character strings. Then we could try naming a few
billion individuals with this set.

This datatype is finite. Unfortunately the exact number interacts unfortunately
with Unicode definition, and with issues such as whether or not unicode strings
that are not in normal form C are permitted. The definition of Unicode changes
over time.

So, Ian is right to indicate that permitting this would mean that creating a
complete reasoner would become an unreasonable task.

However, there is a tail and there is a dog.

For me the dog is reasoning about the things people really want to say, and the
tail is the logical and computational properties analysis that Ian and Peter are
so good at. I would be quite happy to permit unambiguous datatype properties and
indicate that implementations are not expected to resolve the cardinality

I am moderately in favour of the rigour that the DL community bring to our
discussion. However, I would like to see the concern about completeness being,
we must correctly document where an OWL reasoner is not expected to be complete,
as opposed to, OWL must be implementable in a sound and complete fashion.


Received on Tuesday, 16 July 2002 05:41:40 UTC