- From: Bijan Parsia <bparsia@cs.man.ac.uk>
- Date: Mon, 3 Dec 2007 11:12:43 +0000
- To: Jeremy Carroll <jjc@hpl.hp.com>
- Cc: "Peter F. Patel-Schneider" <pfps@research.bell-labs.com>, ian.horrocks@comlab.ox.ac.uk, hendler@cs.rpi.edu, public-owl-wg@w3.org
On 3 Dec 2007, at 09:32, Jeremy Carroll wrote: > Peter F. Patel-Schneider wrote: > >> In any case, there should probably be some explanation of why the >> issue >> is not being considered, and "no implementions" sounds acceptable >> to me. > > I had hoped for a little bit more - four years ago when we > postponed this, we were told that work was being done in the area. > > This feature is a feature that many of HP's users would like, and > which HP would be likely to support (in an OWL Full sort of way) if > there was an appropriate construct. > > I note that relational databases have routinely supported a similar > functionality for decades. > > So - please could someone summarize the current state of research > on this issue? Keys and compound keys are being worked on by an OWLED Task Force: http://code.google.com/p/owl1-1/wiki/DatabasEsque That page has some useful links (though the bibliography is not comprehensive yet). Even speccing very easy keys: http://code.google.com/p/owl1-1/wiki/EasyKeyProposal Proved to be a bit challenging. (MUCH more challenging than I thought.) The short answer is that, technically speaking, keys as aliases for rules with (positive) equalities in the head are pretty reasonable (esp. since we can spec them by translation to rules) -- even compound keys. Syntax can be tricky and the introduction of computation makes it even trickier, esp when you lift it to the class definition level (where the difference between a compound key and a functional restriction to an n-ary data predicate evaporates). There was a lengthy thread: http://lists.w3.org/Archives/Public/public-owl-dev/2007JulSep/0211.html We've started a preprocessing based implementation of this key proposal. It'll have two modes: one generates corresponding rules and the other works directly (but treats reasoners as an oracle). Most people seem fairly comfortable with having a specific syntax for keys, though at the moment we are just using annotations on data properties to indicate Keydom. Compound keys would require, obviously, more. Hope this helps. Perhaps further discussion to devolve to public-owl- dev? If we can put together (out of group) a coherent proposal and some implementation/user experience, then we could raise it again in group. Cheers, Bijan.
Received on Monday, 3 December 2007 11:11:11 UTC