- From: Dan Brickley <danbri@danbri.org>
- Date: Mon, 01 Oct 2007 18:18:56 +0200
- To: Bijan Parsia <bparsia@cs.man.ac.uk>
- CC: Danny Ayers <danny.ayers@gmail.com>, Owl Dev <public-owl-dev@w3.org>
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