Re: draft response JBolleman-1, JBolleman-2

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).
 --------

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 19:20:15 UTC