Re: draft response JBolleman-1, JBolleman-2

On 17/10/11 20:19, Axel Polleres wrote:
> Andy, all,
>
> I have adapted the response draft for Jerven Bolleman (essentially incorporating your arguments), see
>   http://www.w3.org/2009/sparql/wiki/CommentResponse:JBolleman-1
>
> Please check especially the following (I wasn't 100% sure what you meant by
>> By the way, an "ORDER BY *" is still not a gauaranteed total ordering.
> but I guess it was in spirit this:
>   --------
> First of all, note that a shortcut like "ORDER BY *" as you suggest would not guarantee a predicable total order of results (for instance when blank nodes are returned, since two separate calls are not guaranteed to return the same blank node identifiers).
>   --------

While its's true that bNodes don't sort predictably, there are more 
important and significant cases though that would matter:
Why not refer to the text in:

http://www.w3.org/TR/sparql11-query/#modOrderBy

(which is SPARQL 1.0 text)

	Andy

>
> I just see Jerven asking about the state of his comment (will answer him offlist that we're at it, but I'd appreciate feedback to get this oune out quickly


>
> thanks a lot,
> Axel
>
>
> On 17 May 2011, at 17:41, Andy Seaborne wrote:
>
>>
>>
>> On 17/05/11 13:40, Axel Polleres wrote:
>>> Hi all,
>>>
>>> drafted a response to
>>>
>>>    http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2011May/0016.html
>>>    http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2011May/0017.html
>>>
>>> at
>>>    http://www.w3.org/2009/sparql/wiki/CommentResponse:JBolleman-1
>>>
>>> please check/acknowledge
>>>
>>> thanks,
>>> Axel
>>
>> We did consider things in this area [1] and so we can say we actively
>> were aware of the issue and choose, on time resource issue grounds, not
>> to address the matter. (voting record?)
>>
>> [1]  http://www.w3.org/2009/sparql/wiki/Feature:Cursors
>>
>> Let's at least say this is a protocol issue not a query issue.  Existing
>> HTTP mechanisms are applicable like ETags for consistency and ranges for
>> slicing. Client side paging off a stream of results is also a candidate
>> mechanism.
>>
>> Cursors, paging, (transactions) etc are about controlling the flow of
>> results and about results over multiple requests, not in defining results.
>>
>> I think this clear-cut separation is important because it then can
>> address interactions with update, system restarts and anything that
>> means the server would loose state or simple re-execution of the query
>> would produce different answers even in a deterministic query processor.
>>
>> By the way, an "ORDER BY *" is still not a gauaranteed total ordering.
>>
>>          Andy
>>
>>
>

Received on Monday, 17 October 2011 20:16:33 UTC