Re: draft response JBolleman-1, JBolleman-2

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.

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 Thursday, 20 October 2011 22:55:21 UTC