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

On Wed, Jun 09, 2004 at 02:07:21PM +0100, Seaborne, Andy wrote:
> 
> > > -- 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.

This came up during the telecon. I think the outcome was that it
depended on what extra bit you had in the respones. It could be
a boolean say there were more results; it could be a count of
those results:

query	response	server	network
limit	extra bit	effort	burden
-----   ---------	------	------
none	none		full	full
10	none		light1	light
10	boolean		light2	light
11	none		light2	light
10	count		full	light

where "light" meant the effort was shortcutted by the limit.
"light2" means the server had to compute one more tuple (or
the existance of) than "light1".

In the above, I assume tuples as the unit of measure. Rob raised
the issue that (correct me here) the client could be doing some
inferencing which would give more [or fewer, i note] results than
specified in the limit. I think that's fine, that it does't reduce
the utility of specifying a limit.

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

-- 
-eric

office: +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA
cell:   +1.857.222.5741

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.

Received on Wednesday, 9 June 2004 18:06:21 UTC