- From: Eric Prud'hommeaux <eric@w3.org>
- Date: Thu, 10 Jun 2004 07:06:29 +0900
- To: "Seaborne, Andy" <andy.seaborne@hp.com>
- Cc: RDF Data Access Working Group <public-rdf-dawg@w3.org>
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