RE: query through web API

> am i making myself clear, re, being able to map back the tabular data
> into the graph without intervention?
> i wonder how joseki does this, with RDQL
> i wonder if there's a better way

Yes - that's clear.  In Jena1, RDQL query execution was carried out in the
query engine, not the storage.  As it was processing the statements anyway
as it computed the query result bindings,  it just kept a record of them as
it went for any successful result binding.

Jena2 is more efficient in query execution and the triple patterns from the
query are passed down to the inference or storage graphs.  If it's a
database, it gets compiled into an SQL statement that builds the variable
bindings, without the triples being involved.  So, to find the graph induced
by a query, it does it by substitution.  For each result binding, the values
of the variables are substituted back into the query expression to create
the statements which caused the match.  These are gathered together into a
single model and shipped as the result of the Joseki operation.

This substitution way of doing it isn't too expensive as it only operates on
successful matches.  Recording as you execute the query may be cheaper in
terms of not recreating statements objects (but Jena caches these anyway)
but has a small overhead on unsuccessful matches which mounts up.

Which is a long way of saying it does it like you describe, if my
Perl-understanding is correct.

This effect is the if the client application really does want variable
bindings, the result is a subgraph of the original and the client
"re-executes" the query on the much smaller result graph to build locally
the variable bindings.  I chose the "subgraph" paradigm of query results as
it seemed more general as a building block.  Other "query languages" in
Joseki exploit this - e.g. "fetch"ing returns a subgraph that is about a
resource, where the aboutness is determined by the server, not the query.

As the result subgraph is presumable much smaller, and in memory, the
overhead is small but not insignificant if the client is a low powered
device.  In order to help clients that don't want the overhead, they can ask
for a different format for the results as an optional extra.  If the RDQL
query request also has "format=BV" (or the full URI
http://jena.hpl.hp.com/2003/07/query/BV), the result is not a subgraph but a
graph encoding the variable bindings (see [1]).  There is an example in the
Python library show this - see Pyseki/py-ex-6.  Sorry - I haven't written a
Perl client library yet.

The query-over-POST is really a different way of shipping the same as the
query-over-GET where the request is very long (and so intermediate caching
is unlikely) or the application wants to force the query to go to the other
end, even in the presence of invisible, aggressive web caches.

For your add operations, do they all become a single protocol operation of
merging/smushing in a new piece of RDF into the server-side graph?  This
would avoid the API leaking into the triple store.

	Andy

[1] http://www.w3.org/2003/03/rdfqr-tests/recording-query-results.html



jo walsh <mailto:jo@abduction.org>
wrote [23 September 2003 21:33] ::
> hello,
> 
> i have a homegrown perl RESTful RDF API which is rather like joseki,
> but meant for model-annotation[0]. past versions of it have had
> specific common queries hardcoded, with variables in a GET query
> string to be dropped into the slots of SquishQL queries (more
> homegrown perl). 
> 
> - i'd like to be able to GET the RDF graphs corresponding to
> arbitrary SquishQL results, returned as XML, just like in
> http://www.joseki.org/protocol.html
> But I'm banging my head against being able to change the tabular data
> that i get back from Squish, into bucket-o-triples form,
> programmatically. 
> 
> e.g. in my existing code i wind up doing things like this:
> 
>     my $q = qq( SELECT ?pred, ?object
>                 WHERE
>                 ('$id' ?pred ?object)
>         	);
>     my @bits = $self->rdf->query($q);
>     @bits = map { [$id, $_->[0],$_->[1]] } @bits;
> 
> (then the array of arrays goes straight into a serialiser...)
> 
> am i making myself clear, re, being able to map back the tabular data
> into the graph without intervention?
> i wonder how joseki does this, with RDQL
> i wonder if there's a better way
> 
> - also i'd like to be able to cache the queries inside the model, and
> refer to them with URIs... i thought this was a kludgy idea until i
> read the HTTP POST section of that joseki protocol doc... perhaps it
> still is... i would wind up describing the API inside the triplestore.
> 
> 
> yours, confused,
> metazool
> 
> 
> [0] http://mutemap.openmute.org/doc/mesh.html partial doc...

Received on Wednesday, 24 September 2003 07:34:59 UTC