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

On 1 Oct 2007, at 17:18, Dan Brickley wrote:
[snip]
>> 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.

I share that belief. BTW, if anyone else wanted to do that survey,  
I'd welcome it :) It's not like I've got a free plate just waiting  
for things to fill it up.

> 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?).

Doubt that they're this far along.

> 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"...

Personally, I'd prefer to handle this at the datatype level. We  
should just bite some bullet and come up with a decent, lang  
sensitive model for literals and xsd:string.

>  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.

Sure.

Do you believe that if you start from the following graph:

	s p o.
	_:x p o.

and delete the second triple to get:
	s p o.

that you have lost anything? If not, then you buy and want to use the  
existential variable semantics of BNodes. If not, then you want the  
local name version.

Do you think it's harmless to go from
	s p o.

to
	s p o.
	_x p _y.
	_z p o.
?

If so, you're existentially inclined (drink zee bitter coffee).

Are you content for the following triple:
	s p _:x.

To be replaced by:

	s rdf:type [a owl:Restriction;
		owl:onProperty p;
		owl:someValuesFrom owl:Thing]

?

If so, then you are pro-existential variable semantics. If not, then  
you are sane, er, in favor of a somewhat different approach like most  
of the world.

(I'm simplifying a bunch, obviously.)

Cheers,
Bijan.

Received on Monday, 1 October 2007 16:30:14 UTC