- From: Jim Hendler <hendler@cs.umd.edu>
- Date: Wed, 9 Jun 2004 17:55:16 -0400
- To: "Seaborne, Andy" <andy.seaborne@hp.com>, RDF Data Access Working Group <public-rdf-dawg@w3.org>
At 14:07 +0100 6/9/04, 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. > > Andy [snip] Andy - referring to two of your messages at the same time (this one and the one on streamable results) I wonder if both of these are needed -- a lot of query systems I've played for have protocols which work by returning the number of answers and the first one, and then have a mechanism for requesting the next N - if we were to design that as the streamable interface, would there still be a need for 3.10? -JH (note: in practice there is often something that keeps the system from having to actually count the results when there is a large number - usually just some flag that says "*many"" when the number is greater than some parameter -- that could either be in the design or could just be how people really implement for efficiency) -- Professor James Hendler http://www.cs.umd.edu/users/hendler Director, Semantic Web and Agent Technologies 301-405-2696 Maryland Information and Network Dynamics Lab. 301-405-6707 (Fax) Univ of Maryland, College Park, MD 20742 240-277-3388 (Cell)
Received on Wednesday, 9 June 2004 17:55:32 UTC