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

RE: Minutes of RDF DAWG telecon Tuesday 2004-06-08 for review

From: Seaborne, Andy <andy.seaborne@hp.com>
Date: Wed, 9 Jun 2004 14:07:21 +0100
Message-ID: <E864E95CB35C1C46B72FEA0626A2E8080361545D@0-mail-br1.hpl.hp.com>
To: RDF Data Access Working Group <public-rdf-dawg@w3.org>

> > -- 3.10 Result Limits
> > 
> > straw poll: who's convinced this is a requirements? are we close
> > to a decision here?
> AndyS: RDQL does not have a limit. Joseki provides limits.
> PatH: it could mean 2 things: I don't want more than 10 answers
>   and the next ones after that or *just* 10

It occurred to me that one way of differentiating between exactly 10 and
more than 10 (and an unknown number) when we have "LIMIT 10" is to ask for
11.  If 11 results return up, it is more than 10.  Otherwise, it is exact
and 10 or less.  This is making the (trailing) flag we discussed a matter of
whether the 11th slot gets filled at all.

Hence, no requirement for a special flag and the client can decide whether
to ask for 11 if it needes to know the difference.  It still might be a
better design overall to have a flag.

	Andy

> AndyS: seen this to prevent error conditions
> EricP: SQL has it
> RobS: there are other things in SQL that we don't have
> Steve: can affect latency
> AndyS: can be either a query or a protocol issue
> EricP: arguing from the point of view of a straightforward
>   implementation (for both client and server)
> Yoshio: but then we need a way to specify the snapshot of the database
> RobS: what is understood as a "result"
> Kevin: do we want an exact upper bound? could cause more impl burden on
> the server
> DanC: does "upper bound" appeal to somebody?
> Kevin: yes
> FarrukhNajmi: +1
> PatH: DQL could, by request, give a count of results
> DanC: motivation to spend time on this is in discussing/bounderaries
> with 
> other groups
Received on Wednesday, 9 June 2004 09:08:03 GMT

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