Re: The theoreticians got rid of the OrderedMerge

Enrico Franconi wrote:
> On 26 Jan 2006, at 11:43, Seaborne, Andy 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, I guess Pat really meant what he wrote. RIs and literals in G and  
> G' are the same by definition of graph-equivalence, but bnodeIDs may  
> be or may not be the same in G and G'.


I understand that about Pat's text - it was yours saying discussing how IRIs 
can be renamed by type B engines that I thought was really about blank node 
labels.

example:
 >> Engines (say, of type B) which do not necessarily return the same
 >>IRIs as in the original graph


> 
>> 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'.
> 
> So, you are saying that the protocol disallows any possible extension  
> of SPARQL to be of type A remotely as well (so that it will be able  
> to answer queries with told bnodes)?

No, not "disallows".  I'm noting that the current text in the XML result set 
doc says that labels are scoped to the XML file.  The XML file is a standalone 
unit of information that can be interpreted without reference to anything 
else.  In particular, two XML results can't be related by blank node labels 
unless the application/client has some other piece of information.

The labels may have wider scope - they may not - it does not say (I don't read 
"scoped to XML doc" as "only scoped to XML doc" - an engine can just dump in 
global, non-IRI identifiers for blank node labels but clients can't rely on on 
that fact, or the stablility of them unless the service makes additional 
information known.

[[ARQ provides both modes.  The default is blank node labels in the XML file 
are  allocated for the file (they will start at "b0" IIRC and count up as new 
bNodes are encounter in the result stream).]]

> Can't we just say that the protocol is neutral, and passes on  
> whatever data comes from the core local engine? The protocol should  
> not take any semantic decision, I guess.

I see the results format as being as neutral as possible in it's current form 
because it gives the minimal requirement (labels only guaranteed to be scoped 
to the document).

	Andy

> [pls note that I'm quite ignorant about the deep issues involving the  
> protocol]
> I'd just would like to make sure that - if we go with the second  
> option (the one backed by Pat) - type A extensions will be possible  
> in the future, while still being somehow 'SPARQL compliant'.
> I expect many applications immediately asking for type A services.
> 
> cheers
> --e.

Received on Thursday, 26 January 2006 11:24:52 UTC