- From: Pat Hayes <phayes@ihmc.us>
- Date: Thu, 26 Jan 2006 10:06:13 -0600
- To: Enrico Franconi <franconi@inf.unibz.it>
- Cc: 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)? The problem is, how do we say what the scope is of bnodes in the answer document? Right now we say its that document. It is hard to see what else we could reasonably say, given that the document, once sent, could be archived for a decade on a disc drive in Azerbaijan and should still be meaningful when read. Seems to me that the best thing to do is to keep the basic definitions flexible (G equivalent to G', no other constraints), keep the current SPARQL spec requiring that bnodes in an XML answer document are local to it, so no told bnodes there, but to keep open the possibility that answers might get sent in other formats, and those then might use other ways to indicate bnode scoping. This then doesn't require any told-bnode-style extensions to re-write the basic SPARQL specs or definitions, just to use a different format for sending answers in documents. >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) For the record, I want to keep the basic defs as flexible as possible, to allow for all possibilities. 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. -- --------------------------------------------------------------------- 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 16:06:27 UTC