W3C home > Mailing lists > Public > www-webont-wg@w3.org > September 2002

Re: LANG: issue 5.1 - Uniform treatment of literal/data values

From: Jim Hendler <hendler@cs.umd.edu>
Date: Wed, 18 Sep 2002 18:06:21 -0400
Message-Id: <p05111727b9aea7618fb2@[205.253.57.80]>
To: Ian Horrocks <horrocks@cs.man.ac.uk>, www-webont-wg@w3.org

At 3:26 PM +0100 9/18/02, Ian Horrocks wrote:
>I promised to say something about the possible use of key constraints
>in this context, so here it is.
>
>Carsten Lutz, Ulrike Sattler, Carlos Areces and myself have been
>looking into the idea of reasoning w.r.t. a set of "key" axioms. These
>are axioms of the form "C hasKey k1,...,kn", where C is a class and k1
>to kn are a list of functional datatype properties (in general these
>could be functional paths, but this usually leads to undecidability).
>
>In its simplest form the class C would be Thing, and there would only
>be a single functional datatype property in each axiom, e.g., "Thing
>hasKey k". Adding this axiom would be equivalent to making the
>datatype property k inverse functional. Referring to Dan's state code
>example, adding the axiom "Thing hasKey stateCode" would support the
>desired entailment.
>
>The problem of reasoning w.r.t. such axioms is similar to (but worse
>than) the problem of reasoning with nominals (i.e., classes defined
>extensionally using the oneOf constructor) - in fact it is easy to see
>that the expressive power of keys subsumes that of nominals because if
>keyProp is an key for Thing and ranges over the integers, then
>restriction classes of the form "onProperty keyProp toValue i", where
>i is an integer, can be used as nominals. It is, however, still
>possible to separate reasoning w.r.t. datatypes from reasoning
>w.r.t. the object domain (using a more sophisticated datatype
>reasoner) s.t. a hybrid reasoner is sound and complete iff both the
>object and datatype reasoners are sound and complete.
>
>Obviously this work is still at a relatively early stage, so I don't
>want to suggest that it represents any kind of "compromise solution"
>to the problem (even if such a compromise were acceptable).
>
>Regards, Ian
>
>[1] http://lists.w3.org/Archives/Public/www-webont-wg/2002Apr/0261.html


I think some sort of compromise is needed, here is a half-baked 
proposal that might be useful in continuing the discussion

Suppose we continue to have data and object properties distinguished, 
but with some sort of syntactic construct that would let one do an 
association that allows keys- as follows:

:SSnum a owl:dataTypeProperty.
:Individual a owl:class.
:Individual a owl:ObjectTypeProperty.
:SSnum owl:dataDesignatesUniqueObject :Individual.   (needs a better name)

which would be a syntactically special way to say inverseFunctional 
on a datatype.  (This would allow keys and some other similar uses). 
The advantage is that there would be a syntactic flag to know this is 
occuring so that Fact and other reasoners could say "If you use this 
property, you may not get completeness" -- in short, this is a 
variant on Jeremy's "here be dragons" approach -- but since, at least 
I think, the inverseFunctional on datatypes would mostly be used by 
people doing things to instances (rather than class reasoning) this 
wouldn't be a major problem.
  Dan's states examples seem to be satisfied by this (details left as 
exercise to reader) and it also allows distinguished data and type 
classes for tools like RIC that can profit from knowing which is 
which.

  -JH
p.s. Please note this message doesn't say "chair neutrality off" - 
I'm not putting forth my personal preference here, but trying to get 
discussion restarted.
-- 
Professor James Hendler				  hendler@cs.umd.edu
Director, Semantic Web and Agent Technologies	  301-405-2696
Maryland Information and Network Dynamics Lab.	  301-405-6707 (Fax)
Univ of Maryland, College Park, MD 20742	  240-731-3822 (Cell)
http://www.cs.umd.edu/users/hendler
Received on Wednesday, 18 September 2002 18:06:30 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:57:52 GMT