RE: Bandwidth efficiency

> From: public-rdf-dawg-request@w3.org
> [mailto:public-rdf-dawg-request@w3.org]On Behalf Of Steve Harris
> Sent: Wednesday, June 02, 2004 6:33 AM

> 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.

Whoops, you said it better than my summary did, which went a bit astray I
think.  I was just thinking out loud about the cost of determining the qname
equivalent of each uri in the result set at emit time. Please ignore my
muddled thought processes!

> > 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.

Right.

> > 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 10:22:28 UTC