incubator-jena-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Seaborne <>
Subject Re: Model/Graph for a remote SPARQL endpoint
Date Sat, 11 Feb 2012 20:42:01 GMT
On 11/02/12 02:04, Stephen Allen wrote:
> Is there a preferred way to represent a remote SPARQL endpoint in a manner
> that is interchangeable with a local model/graph?  I have code that
> generates RDF using Jena objects, and I want to store them in either a
> remote or local graph store (configurable).

SPARQL? I.e. don't work in terms of API calls but in terms of SPARQL.  A 
simple DatasetGraph can wrap local/remote issues.

> I see there is a GraphSPARQLService, but it doesn't appear finished (also,
> I think I would want a DatasetGraph level interface).

It's read-only and work by mapping all Graph.find to a remote query.

> Also I note the DatasetGraphAccessorHTTP in Fuseki, which I believe is an
> implementation of "SPARQL 1.1 Graph Store HTTP Protocol" [1].  This looks
> close to what I want, but forces you to add a dependency on Fuseki, and it
> does not have streaming support for inserts or a natural API that accepts
> Jena objects.

DatasetGraphAccessorHTTP is supposed to migrate sometime.

What do you mean by "natural API that accepts Jena objects"?  The grap 
store protocol is put/get of whole graphs only.

If the graph is small, then get - do some operations - put might be 
workable. This has transaction semantics (use etags).  Just depends on 
the size of the graph.

And if not, maybe a design where changes are accumulated locally, then 
enacted at the end all at once on the potentially remote graph (with 
local mirror?).

> Basically I think I'm looking for a Connection object similar to JDBC or
> Sesame's RepositoryConnection [2].  You could connect to either a local
> DatasetGraph or a remote endpoint.  For the remote endpoint case, I don't
> think it's possible to accomplish fully with standard SPARQL because of two
> issues: 1) no transaction support across multiple queries/updates and 2)
> local blank nodes identifiers.
> Does anyone have any ideas?  Should I start designing such a thing?  The
> blank node problem could be solved with skolemization [3], and we could
> initially ignore the transaction issue (thus support Auto Commit mode only).

Bnodes can be handled by enabling bNode label output, and using <_:...> 
on input.

But do think about whether bNodes are the right thing to use in the 
first place.

> To add transaction support, we would have to add an extension to SPARQL 1.1
> Protocol [4].  An extra parameter to indicate the type of transaction (READ
> or WRITE, transaction level) and transaction ID seems like it might be a
> good approach. The transaction ID could be a client generated UUID, which
> would save a round-trip.  Or maybe a cookie would be a better approach?


Alternative: E-Tags give transactions for consistency.  No abort though 
and client crash has no roll back but its the web way.


> -Stephen
> [1]
> [2]
> [3]
> [4]

View raw message