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

Re: Bandwidth efficiency

From: Steve Harris <S.W.Harris@ecs.soton.ac.uk>
Date: Wed, 2 Jun 2004 14:33:13 +0100
To: DAWG public list <public-rdf-dawg@w3.org>
Message-ID: <20040602133313.GA7484@login.ecs.soton.ac.uk>

On Wed, Jun 02, 2004 at 05:58:28 -0700, Howard Katz wrote:
> > The situation where the namespaces are declared after the results is not
> > much better as the client cant interpret them untill its parsed all the
> > namespace decls anyway.
> Right. So what you're saying is that the tradeoff is basically between :
> (1) taking processing time to compute the namespace of every uri in the
> result set before they depart the scene, or
> (2) leaving it to the client to do the inverse operation following arrival,

I dont think I follow. If the server just streams the results with fully
qualified URIs then the server and client doesnt have to do anything, but
it takes more bandwidth.
> I wouldn't have thought that (1) was all that expensive offhand -- I need to
> have some hands-on play with this one.

It means that the sever has to hold onto the reuslt set, which can be
quite large.
> There's one other alternative of course, but only if the store was created
> to your own specification (which makes me realize I only have a vague
> understanding of the various possible scenarios) :
> (3) store the namespace (or at least some sort of integer key representation
> of it) along with the uri for each node in the repository as it's added.
> Then there's no latency or bandwith issues on the way out. However there
> might be other internal processing issues that would arise in the area of
> self-consistency and the like, and of course increased data size.

Thats what 3store v1 did, for prety much that reason, actually to
reconstruct RDF/XML cheaply. It was too much overhead though. Slows down
assertion and query.
> Our painful motto: No free lunch in computerland,

Too true

- Steve
Received on Wednesday, 2 June 2004 09:33:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:00:26 UTC