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

Streamability II

From: Seaborne, Andy <andy.seaborne@hp.com>
Date: Wed, 16 Jun 2004 13:27:48 +0100
Message-ID: <E864E95CB35C1C46B72FEA0626A2E8080361582C@0-mail-br1.hpl.hp.com>
To: RDF Data Access Working Group <public-rdf-dawg@w3.org>


I took the original action in the telecon of 8 June to draft text because I
*didn't* propose this as a requirement but said I understood the
requirement.

Personally, I think this a bit small for a "requirement" but it is concrete
enough to be one.  Also, I would imagine that it is an easy feature to have
in any reasonable protocol design and there is no reason why it should not
be the only form of multiple results.  An XML results format could meet it
with a SAX parser - we can discuss later devices that only do DOM and
whether we want a custom (non-XML, non-RDF) format.

Therefore, I'm neutral as to making it a requirement or a design objective.

------------------------------

Current text:

"""
When returning multiple results there must be a form of the protocol
that allows streaming of results.  In this form, the results must be
returned to the client so that all the data in one result are
available before all the data for the next result.  This does not
require an ordering of results.
"""

Messages so far:

Andy: original proposed text
http://lists.w3.org/Archives/Public/public-rdf-dawg/2004AprJun/0566.html
Dave: generalized to any form with the possibility of multiple results 
http://lists.w3.org/Archives/Public/public-rdf-dawg/2004AprJun/0569.html
Andy: ACK to Dave
http://lists.w3.org/Archives/Public/public-rdf-dawg/2004AprJun/0604.html

See also:

Jim: proposes blocks of results requested by the client
http://lists.w3.org/Archives/Public/public-rdf-dawg/2004AprJun/0576.html
Andy's reply: issues with server state and DOS.
http://lists.w3.org/Archives/Public/public-rdf-dawg/2004AprJun/0606.html

See also previous discussion between Andy and Farrukh around:
http://lists.w3.org/Archives/Public/public-rdf-dawg/2004AprJun/0469.html

- - - - - - - -
Discussion:


Client usage:

Janne asked for an example of client usage: Suppose we have the query: "get
all the names of people that Johhny Lee Outlaw knows"

SELECT ?name
WHERE  (?x  foaf:name  "Johnny Lee Outlaw")
       (?x  foaf:knows  ?y)
       (?y  foaf:name  ?name)

There are expected to be several ?names that match.

This could be done in a loop,

for $row in each binding of variables:
  $name = $row.getVariable("name") .
  // Do something with this $name
  <table row>Email address: $email</table row>
  end for

With a streamable protocol the loop above can be executed the first time as
soon as the first result binding (row in the result table) arrives.  This is
Jim's example of do something with first 100 results while the server is
still dealing with the next 100 done in the style of iterators.  The above
code does nto require all the results to be in memory at the same time.

In Jena the classes are: QueryResults [1] for the iterator and ResultBinding
[2] for each row of the conceptual result table.

[1]
http://jena.sourceforge.net/javadoc/com/hp/hpl/jena/rdql/QueryResults.html
[2]
http://jena.sourceforge.net/javadoc/com/hp/hpl/jena/rdql/ResultBinding.html

See also java.sql.ResultSet.  The API style is to deliver one row of the
result set to the application at a time with java.sql.ResultSet#next() &
java.sql.ResultSet#isLast() Result set can be TYPE_FORWARD_ONLY.


Rob said that the fact that the wording does not talk about the client
requesting streamability.

Suggestion:

- - - - - - - -
When returning multiple results, the client may request
that results be streamed.  In this form, the results must be
returned to the client so that all the data in one result are
available before all the data for the next result.  This does not
require an ordering of results.
- - - - - - - -

	Andy
Received on Wednesday, 16 June 2004 08:30:20 GMT

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