W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > April to June 2007

Re: from & from named

From: Seaborne, Andy <andy.seaborne@hp.com>
Date: Fri, 15 Jun 2007 17:20:01 +0100
Message-ID: <4672BC31.8000301@hp.com>
To: Olivier Corby <Olivier.Corby@sophia.inria.fr>
CC: public-rdf-dawg@w3.org

Olivier Corby wrote:
> I have found a strange side effect of the rdf merge for building the 
> default graph as shown in the example below:
> 
> select ?person ?topic ?src
> from uri1
> from uri2
> from named uri1
> from named uri2
> where {
>     ?person c:recommends ?doc
>     graph ?src { ?doc c:subject ?topic }
> }
> 
> If the value of ?doc is an uri, it may succeed, but if it is a blank 
> node, it always fails because the rdf merge that produces the default 
> graph has relabeled the blank nodes.
> 
> So depending whether the values of ?doc are uri or blanknodes in the 
> target graphs, the query succeeds or fails. From a *user point of view* 
> this is incomprehensible.
> 
> Olivier
> 

Olivier,

It's not the RDF merge of uri1 and uri2 that is the issue here - even if there 
were only one FROM then the query need not necessarily match a blank node ?doc 
across graphs.

Just reading a graph from the same uri twice should allocate different blank 
nodes.  For example:
   copy the document at uri1 to uri3
   Read uri3
The blank nodes should be all different from reading uri1.

When reading some document, any blank node labels in the document at uri1 is 
scoped to the document only.  Implicit blank nodes should get new blank nodes 
created on each parsing.  Assuming anything outside that isn't blessed by RDF.

So
FROM uri1
FROM NAMED uri1

can give different blank nodes if the document is read twice.  It would be 
wrong of SPARQL to conclude otherwise.

To put it another way, blank node labels aren't global identifiers whereas 
URIs are.

	Andy

-- 
Hewlett-Packard Limited
Registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England
Received on Friday, 15 June 2007 16:20:13 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:36 GMT