Re: a bnode URI scheme?!

Sandro Hawke wrote:

>
>Sorry if I'm being a bit slow.  Can you explain again the differences
>in how some software is supposed-to/entitled-to behave on getting
>
>    <a> <b> <c>
>vs
>    :_a <b> <c> 
>
>and thus what the effects (disadvantages) are of (consistently)
>Skolemizing the graph, or getting the authors to name their conceptual
>entities?
>  
>

Here's a real-world example.  Your calendering software exports your 
address book as RDF that looks like that address example in the RDF 
primer (i.e. with a bNode in the position of the address resource).  You 
publish it on the web. Someone else in the world has the same name (and 
same address) in her address book and publishes on in the web RDF also.  
Now any RDF processor that supports RDF semantics could compare those 
two different RDF documents and determine that both documents are 
referring to the same address (by finding the lean sub-graph in the 
merge of the two models). It has no need to understand anything about 
what an address is to be able to do this.

Now consider the case where the calender tool exports a skolemized 
version instead. Now if an RDF processor encounters those two documents 
it will appear as if that name has two address resources.  Only if the 
processor has access to that particular schema (e.g. an OWL schema) and 
knows how to handle it, can it determine that those two address 
resources are in fact the same. When you consider this cost of this 
extra burden, consider how much easier it is for people to agree on a 
shared vocabulary with informal meanings than to write an OWL schema.

So that's the cost of skolemizing but a benefit is that you can 
reference those resources externally, which you can't do for bNodes.  
Hence the (probably minor) need for a bnode URI scheme.

>No, I agree tools should understand them.  But you seem to be trying
>to give authors ways to work around the challenges bNodes present, and
>it seems to be better all around to have the authors just not use
>bNodes (or link to content which uses bNodes) in awkward ways.
>
Writing this email made me realize a work-around that avoids bNodes: if 
everyone skolemized by creating an URI that was a hash of the bNode's 
extension (e.g. like urn:sha1:df34e3900...) then we'd all independently 
create the same URI. This is can be an expensive operation but so is 
finding a lean sub-graph.

-- adam

Received on Friday, 12 March 2004 16:35:22 UTC