W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > January to March 2006

Re: The theoreticians got rid of the OrderedMerge

From: Seaborne, Andy <andy.seaborne@hp.com>
Date: Thu, 26 Jan 2006 10:43:51 +0000
Message-ID: <43D8A7E7.2000401@hp.com>
To: Enrico Franconi <franconi@inf.unibz.it>
CC: Pat Hayes <phayes@ihmc.us>, RDF Data Access Working Group <public-rdf-dawg@w3.org>



Enrico Franconi wrote:
> On 25 Jan 2006, at 20:42, Pat Hayes wrote:
>> Wait: G' is not required to be the same graph as G, even in basic  
>> SPARQL. If we do that, then we get compulsory told bnodes for all  
>> conforming engines. So the IRIs and literals in G and G' are the  
>> same, but the bnodeIDs might be (should be, IMO) different. In more  
>> direct language, the answer set can have (has) a different bnode  
>> scope than the dataset graph.
> 

Through out this, isn't it s/IRI/blank node label/?

> We have two options here:
> 
> 1) The current text says that a standard SPARQL engine (say, of type  
> A) should return the same IRIs as in the original graph. According to  
> my (limited) sampling of the available implementations, engines of  
> type A are the vast majority of existing engines (I found only one  
> not returning the same IRIs, probably done via a post-process of  
> renaming); this shows that actually it is easier for implementations  
> to return the same IRIs as in the original graph (it actually is: it  
> is just a subgraph matching after all).

ARQ is type A locally and type B remotely.

> Engines (say, of type B) which do not necessarily return the same  
> IRIs as in the original graph will still be SPARQL-compliant  
> extensions of SPARQL: they have just to declare their different  
> semantics (where G is not necessarily equal to G'). This was the aim  
> of our (successful, so far) game on the parametric semantics: to  
> define a framework were it is possible/necessary to formally define  
> the semantics of the extension in order to be called SPARQL-compliant.
> This is my favourite choice.
> 
> 2) The dual option is of course a standard SPARQL where engines (of  
> type B) do not *necessarily* return the same IRIs as in the original  
> graph. This is obtained by deleting the condition that in standard  
> SPARQL G=G'. Engines  (of type A) which do return the same IRIs as in  
> the original graph will still be standard SPARQL engines (i.e.,  
> engines of type A would be also engines of type B), but users  
> wouldn't know that *in addition* they preserve IRIs names. Engines  
> may *optionally* declare themselves as SPARQL-compliant extensions of  
> SPARQL: they have just to declare their different semantics (i.e.,  
> G=G'). This case is bizzarre since after all engines of type A are  
> also engines of type B (the standard ones), so implementors may tend  
> not to declare the different semantics.
> 
> Andy, what do you think?

It is important to note that the XML result set format also scopes blank node 
labels to the result set. Over the wire, it's always type B.  But that is 
regardless of whether G=G'.

What local query does is a local matter and not covered by the spec.

	Andy

> 
> cheers
> --e.
Received on Thursday, 26 January 2006 10:44:18 GMT

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