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

Hi there

Bijan Parsia wrote:
> 
> On 1 Oct 2007, at 11:20, Danny Ayers wrote:
> 
>> On 01/10/2007, Bijan Parsia <bparsia@cs.man.ac.uk> wrote:
>>>
>>> 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.
>>
>> Hi Bijan,
>>
>> Quick question, would these 'legitimise', and enable OWL tools to work 
>> with
>> foaf:mbox_sha1sum (allowing person-identity smushing as with
>> foaf:mbox, which is an ObjectProperty IFP)?

Thanks for this; v interesting.

> Ideally, yes. That is one of the use cases. One bit of research I've not 
> yet done is to survey the smushing code out there and see how closely it 
> aligns with what we're proposing.

One thing I believe you'll see in code, but not currently expressed 
anywhere formally --- the ignoring of language tags. So if one document 
mentions my mbox_sha1sum in a context where there is no xml:lang set, 
and in another it is xml:lang="en", ... the equality test on the literal 
strings is only w.r.t. the textual payload, and not the language. 
(Perhaps RIF can already express this as a rule nowadays?). So people's 
data merging habits go a bit beyond what is strictly justified even by 
OWL Full, which has no way of saying things like "ignoring the lang"...

  My sense, based on my old
> understanding of how smushing generally works, is that it's pretty much 
> the same, i.e., missing keys aren't a problem, same key causes a merge, 
> multiple keys are ok (i.e., no functional constraints), explicit values 
> only, etc. The big difference is that FOAF typically works on bnode 
> subjects, which, under standard BNode semantics are existential 
> variables, thus wouldn't (technically speaking) fall under our proposal.
> 
> However, the common, deployed semantics for BNodes is that they are 
> local names, not existential variables. SPARQL treats them that way. RIF 
> shall as well, I'm pretty sure. SPARQL/OWL probably will. So, we should 
> work that fact into the proposal as well.

Could you spell out the distinction in super-simple terms, for the 
logically impaired? By which I mean, er, ... me.

cheers,

Dan

Received on Monday, 1 October 2007 16:19:16 UTC