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.