- From: Howard Katz <howardk@fatdog.com>
- Date: Wed, 2 Jun 2004 07:22:35 -0700
- To: "Steve Harris" <S.W.Harris@ecs.soton.ac.uk>, "DAWG public list" <public-rdf-dawg@w3.org>
> 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