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

RE: RDF QLs within a larger language

From: Dirk-Willem van Gulik <dirkx@webweaving.org>
Date: Mon, 28 Jun 2004 09:39:37 -0700 (PDT)
To: "Seaborne, Andy" <andy.seaborne@hp.com>
Cc: "Eric Prud'hommeaux" <eric@w3.org>, public-rdf-dawg@w3.org
Message-ID: <20040628093311.T92233@skutsje.san.webweaving.org>



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 12:49:45 GMT

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