Re: The theoreticians got rid of the OrderedMerge

>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/?

No. Since the definitions talk about unions, all the triples are 
being treated there like they are in one big graph, so you can't have 
different bnodes with the same bnode label. Thats why we have to be 
very careful about what is standardized apart from what.

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

Right, that is exactly appropriate IMO.

>>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'.

No, its not. If the definitions require G=G', then scoping answer 
bnodes to the result document is wrong, so our XML result set 
definition would be illegal. The definitions require answer bnodes to 
be in the same scope as G', so if they are scoped separately from G 
in the XML then G' must be bnode-distinct from G in that case.

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

A local query can be processed on the basis that G'=G, which is a 
legal option, and then 'told bnodes' will work at the local level, 
which is also legal. So this is covered by the spec. Or, if you think 
it shouldn't, then the right thing to say is that G' is equivalent to 
G but shares no bnodes with G at all. But I see no harm in leaving 
the flexibility in the definitions, to allow local query processing 
to be conformant, with or without told bnodes, so long as it doesn't 
use the XML output format.

Pat

>
>	Andy
>
>>
>>cheers
>>--e.


-- 
---------------------------------------------------------------------
IHMC		(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.	(850)202 4416   office
Pensacola			(850)202 4440   fax
FL 32502			(850)291 0667    cell
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

Received on Thursday, 26 January 2006 15:55:23 UTC