- From: Andy Seaborne <andy.seaborne@epimorphics.com>
- Date: Fri, 21 Oct 2011 09:20:57 +0100
- 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 UTC