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.