W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2005

Re: Updated SPARQL Query Results XML Format draft

From: Lee Feigenbaum <feigenbl@us.ibm.com>
Date: Wed, 13 Jul 2005 15:24:05 -0400
To: RDF Data Access Working Group <public-rdf-dawg@w3.org>
Message-ID: <OF0B55C764.3995E87F-ON8525703D.006A58DE-8525703D.006A9307@us.ibm.com>

Andy Seaborne wrote on 07/13/2005 11:24:49 AM:
 
> Steve Harris wrote:

> >>When ORDER BY is given, the result format may record index="1",
> >>index="2" on the <result> element.  (Side issue - "may" or "should" do
> >>this?)
> > 
> > 
> > I dont see the point to this really, but how does it interact with 
OFFSET?
> > Shouldn't the count start from OFFSET + 1?
> 
> I suggest that the indexes in the result file do not relate to the 
> rows prior to 
> limit/offset - they are there just to provide an ordering on the 
solutions. 
> Start at 1, and are sequential.
> 
> Ideally, the result set should be in the order 1,2,3,...

You're suggesting that the indexes are there to allow the server to build 
the
XML results in any order and have the client rearrange them? I feel that 
that
puts an unnecessary burden on the client and provides little benefit for 
the
server which must still calculate the proper indexes. 

Is there a use case that drives this decision?

> >>However when there are duplicates should it generate indexes 1, 2, 2, 
3
> >>where items #2 and #3 are duplicates?  (A query with ORDER BY but no
> >>SELECT DISTINCT).
> > 
> > 
> > Strong "no" from me. Any numbering should be monotonic.
> 
> +1
> Whether the query processor has applied a total ordering or not should 
not be 
> reflected in the results (if it matters, use <link/>).

+1

Lee
Received on Wednesday, 13 July 2005 19:24:13 GMT

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