Re: The theoreticians got rid of the OrderedMerge

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.

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).
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?

cheers
--e.

Received on Thursday, 26 January 2006 09:39:04 UTC