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

Re: The theoreticians got rid of the OrderedMerge

From: Enrico Franconi <franconi@inf.unibz.it>
Date: Thu, 26 Jan 2006 12:01:28 +0100
Message-Id: <25F06229-BC5A-4000-BA75-6CA6358EABCF@inf.unibz.it>
Cc: Pat Hayes <phayes@ihmc.us>, RDF Data Access Working Group <public-rdf-dawg@w3.org>
To: andy.seaborne@hp.com

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

> 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)?
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.
[pls note that I'm quite ignorant about the deep issues involving the  
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.

Received on Thursday, 26 January 2006 11:01:45 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:50 UTC