Re: The theoreticians got rid of the OrderedMerge

>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