W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > October to December 2011

Re: draft response JBolleman-1, JBolleman-2

From: Andy Seaborne <andy.seaborne@epimorphics.com>
Date: Fri, 21 Oct 2011 09:20:57 +0100
Message-ID: <4EA12B69.7030103@epimorphics.com>
To: public-rdf-dawg@w3.org


On 20/10/11 23:35, Axel Polleres wrote:
> Since the author of the comment intervened already, unless any more comments,
> I would like to close/send this comment, by the end of the week. please, let me know if any objections.
>

OK.

	Andy

> thanks,
> Axel
>
>
> On 17 Oct 2011, at 22:21, Axel Polleres wrote:
>
>> Updated with the link to http://www.w3.org/TR/sparql11-query/#modOrderBy as suggested.
>>
>> best,
>> Axel
>>
>> On 17 Oct 2011, at 22:16, Andy Seaborne wrote:
>>
>>>
>>>
>>> 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 Friday, 21 October 2011 08:21:43 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:47 GMT