W3C home > Mailing lists > Public > public-owl-dev@w3.org > October to December 2007

Re: [TF:DbE] The easiest keys there are

From: Bijan Parsia <bparsia@cs.man.ac.uk>
Date: Mon, 1 Oct 2007 09:01:26 +0100
Message-Id: <2FC1FF7C-8FEF-47CC-88CC-9CF2892703B0@cs.man.ac.uk>
To: Owl Dev <public-owl-dev@w3.org>

On Sep 28, 2007, at 6:51 PM, Bijan Parsia wrote:

> Hi folks,
> The OWLED task force on DatabasEsque features:
> 	http://code.google.com/p/owl1-1/wiki/DatabasEsque
> Well, at least Uli and me, have been doing a bit of work on keys  
> (aka, inverseFunctional datatype properties) prompted by a visit to  
> Manchester by Matthew Pocock. Some sort of keys is a pretty high  
> value feature. However, if you check out this poster:
> 	http://webont.org/owled/taskforces/dbe/keys_poster.pdf
> (Bit of explanation: Bits in the tan clouds correspond to the  
> asserted parts of the kb. So you see the named entities, e.g., m1  
> or s1, in there. s1, for example, is known to have a key, but we  
> don't know what the key is.)

Oops. Part of my message got omitted (as indicated by the uncompleted  
sentence). Sorry about that. The poster, as it stands, is too  
confusing to work through directly, IMHO. (E.g., I had trouble  
working through it :)). It was a poster designed in some haste for  
OWLED and to be support someone explaining various options. My point  
in posting a link to it is to help give a sense that keys, in  
general, are a non-trivial addition to the language.

The proposal I outlined is for a restricted form of first order key  
reasoning (i.e., no checking or working with missing keys, working on  
named individuals only, limited or no use of keys in class  
expressions, a few other things). The goal is something useful,  
usable, and very implementable (on top of current systems).

Received on Monday, 1 October 2007 08:01:47 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:58:15 UTC