RE: RDF QLs within a larger language

Dirk,

I wasn't thinking of having a controlled flow - just a simple, single TCP
stream. It is an RDF graph (c.f the ResultSet vocabulary), its just that the
RDF serialization is written so that all of row 1 is done before row 2 is
started.  A custom serializer at the server is necessary that takes result
sets and streams out serialized RDF.

The client plugs the incoming stream into an incremental parser that splits
out the triples as it sees it and looks at the triple stream to build result
rows.  Think SAX for result rows.

e.g. a result set like:

@prefix rs:      <http://jena.hpl.hp.com/2003/03/result-set#> .

[]    rdf:type rs:ResultSet ;
      rs:solution 
         [ rs:binding  
                [ rs:value    <http://example.org/y> ;
                  rs:variable "a"
                ] ;
           rs:binding 
                [ rs:value    "B1" ;
                  rs:variable "b"
                ] ;
          ] ;
      rs:solution
          # Only one - ?b was optional.
          [ rs:binding
                [ rs:value    <http://example.org/z> ;
                  rs:variable "a"
                ] ;
          ] ;
... etc etc ...
	. 

does have all the data for solution 1 before solution 2.

Now the client can incrementally parse this and generate each row of the
result set from rs:solution because it knows at the-above-RDF level that all
the rs:solution data is available in the same place in the stream.  A client
can choose to read in an RDF graph with a standard N3 parser if it wishes to
and not benefit.

As I said, it is not a good idea :-) - it only saves the client from having
to have such a parser. Better to have an explicitly streamable format and
ask for it by MIME type as there is so much custom server and client code.

	Andy


-------- Original Message --------
> From: Dirk-Willem van Gulik <mailto:dirkx@webweaving.org>
> Date: 28 June 2004 17:40
> 
> On Mon, 28 Jun 2004, Seaborne, Andy wrote:
> 
> > 1/ The streamability requirement as the result is a graph.  While it
> > is possible to insist that the serialized graph come back in a useful
> > order, this does not feel like a useful way to go.  It is effectively
> > a new serialization that is compatible with the unrestricted one.
> 
> Given that relatively simple/primitive protocols like, say, one build
> around HTTP GET based on a single TCP channel almost always lack an
> async throttle or stop; I'd suggest that once an aswer has started
> comming 
> it is essentially unstoppable wihtout 'breaking the connection'. So you
> have to wait until it is all there. And if you reconnect all you can use
> are simple things like Byte ranges or other record based deliniators.
> 
> So having an order within chunks on that level of granulairyt (i.e. in
> the 
> req/response) is of very little use; unless you use an async/multiplex
> protocol, or one iwth a cmd channel, like beep or ftp, order within the
> serialization is not going to matter. So I'd rather not bother about
> useful other in those granules - but ensure that you can get some
> control 
> over replies on a higher lever; i.e. hints/allow more refined queries
> and/or warnings/limits (say GET-if-modified, GET-if-smaller-than) or
> whatever.
> 
> It may matter on the receiving end - i.e. for efficient memory use - but
> in actual practice that is a) highly system dependent and b) often
> driven 
> to some level of optimization by the developers as a natural thing.
> 
> Dw

Received on Monday, 28 June 2004 13:35:25 UTC