bnodes

Hi Bijan,

You wrote:

> However, the common, deployed semantics for BNodes is that they are  
> local names, not existential variables. SPARQL treats them that way.  
and 
> 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 wondering why you think most of the world is violating rdf-semantics, do you have any stats or at least examples? Note that a tool doesn't need to enforce lean-graphs all of the time, but for a tool complaint with rdf-semanrics the following graph

eg:joesText foaf:maker [ foaf:name "jo"].

expresses the same content as

eg:joesText foaf:maker [ foaf:name "jo"].
eg:joesText foaf:maker [ foaf:name "jo"].


Not treating b-nodes as existential varaiables would mean that the union of a graph with itself would be a different graph. Or for an aggregator: 
whenever we aggregate the first graph we add two triples to our aggregated graph, and if I got your "sane" interpretation right eg:joesText has a new maker, which without further knowledge is not considered to ow:sameAs to any of the exitisting foaf:makerS.
I  was wondering why you think SPARQL treats b-nodes as local names, afaik sparql doesn't guarantee that a query against two graphs expressing the same content yields to the same result but it doesn't require an implementation to keep redundant b-nodes neither.

More generally, what's your motivation to change the semantic of b-nodes, if you don't like/need existential variables why don't you just assign URIs (urn:uuid) to you nodes? What's the particularity of "local" names, do they have to change when they change context? what's the advantage of it?

reto



-- 
Reto Bachmann-Gmür
Talis Information Limited

Book your free place now at Talis Insight 2007 www.talis.com/insight
Find out more about Talis at www.talis.com
Shared InovationTM
 
Any views or personal opinions expressed within this email may not be those of Talis Information Ltd.