W3C home > Mailing lists > Public > public-owl-wg@w3.org > December 2007

Re: ISSUE-47 (compound keys): REPORTED: 6.2-Compound Keys

From: Bijan Parsia <bparsia@cs.man.ac.uk>
Date: Mon, 3 Dec 2007 11:12:43 +0000
Message-Id: <08B8CA32-96E4-4DE6-A6E7-5B60CC0B8D83@cs.man.ac.uk>
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
To: Jeremy Carroll <jjc@hpl.hp.com>

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:	

That page has some useful links (though the bibliography is not  
comprehensive yet).

Even speccing very easy keys:

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:

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  

Received on Monday, 3 December 2007 11:11:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:42:01 UTC