- From: Enrico Franconi <franconi@inf.unibz.it>
- Date: Thu, 26 Jan 2006 12:01:28 +0100
- To: andy.seaborne@hp.com
- Cc: Pat Hayes <phayes@ihmc.us>, RDF Data Access Working Group <public-rdf-dawg@w3.org>
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 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:01:45 UTC