- From: Reto Bachmann-Gmür <rbg@talis.com>
- Date: Tue, 02 Oct 2007 10:30:46 +0200
- To: bparsia@cs.man.ac.uk
- CC: public-owl-dev@w3.org
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.
Received on Tuesday, 2 October 2007 08:31:06 UTC