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

Re: draft response JBolleman-1, JBolleman-2

From: Andy Seaborne <andy.seaborne@epimorphics.com>
Date: Tue, 17 May 2011 16:41:07 +0100
Message-ID: <4DD29713.2020108@epimorphics.com>
To: public-rdf-dawg@w3.org


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 Tuesday, 17 May 2011 15:41:39 GMT

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