Andy, I like the idea. I've been using the jena-client [1] code to do very similar operations for quite a while now. It actually is pretty feature complete at this point (documentation at [2]), and I would like to merge it into the official release (it's already up to date against 3.0.0). I also used ARQ's classes instead of trying to extract everything into a public API.
I think jena-client provides all of the features (and a few more) that you've added except for one implementation detail: GSP support. Instead, when you add or remove DatasetGraphs or Models, it translates that into INSERT/DELETE DATA update queries (a fetch command could be implemented by building a CONSTRUCT query). I actually tried to avoid adding GSP support for two reasons: 1) it complicates the usage, instead of just a query and update endpoint, you also need a GSP endpoint. And 2) GSP is a subset of the query+update functionality. To my knowledge, the only argument for using GSP instead of just query+update would be performance/scalability. Although, when I have encountered those issues, I've attempted to fix the problem in query+update instead (i.e. adding streaming support for update). However, parsing large SPARQL INSERT DATA operations is still slower than parsing NT (not to mention rdf/thrift). There are potential solutions for that (a sparql/thrift implementation, even if it only did INSERT/DELETE DATA as binary and left queries as string blobs), but obviously that doesn't exist yet. Additionally, 3rd party remote stores such as Sesame do not have streaming SPARQL update support, and likely won't in the foreseeable future as it would be a big undertaking (Sesame uses JavaCC+JJTree to build an AST of the update query in memory). But why limit ourselves based on their implementation? One of the motivating features of jena-client was the ability to perform large streaming updates (not just inserts/deletes) to a remote store. This made up somewhat for the lack of remote transactions. But maybe that isn't too great of an argument, when we could just go ahead and implement remote transaction support (here is a proposal I haven't worked on in over a year [3]). We're behind Sesame here, they've had remote transactions for quite a while now. One aspect of your code I do not like is the transaction handling. It is effectively always in "auto-commit" mode. Jena-client's is more like JDBC in that the transaction operations are exposed on the Connection object. If the user chooses not to use the transaction mechanism then it will default to using "auto-commit", but the user can always control it explicitly, which is important. That made it made fairly straightforward to build a Spring Transaction Manager [4] class for my company's project. It is pretty nice to use Spring annotations to perform transactions. I will release that as a GitHub project if/when jena-client is released. Maybe we can use jena-client as a base to work from? If we feel we want to add the separate GSP operations, then I think the extension point would be to add a new GSP interface similar to Updater [5] (but lacking the generic update query functionality). I can start working on moving it from SVN's experimental branch to the Git master tomorrow (I also have to update the documentation to use a lambda instead of an anonymous inner class in the example). -Stephen [1] https://svn.apache.org/repos/asf/jena/Experimental/jena-client/ [2] https://svn.apache.org/repos/asf/jena/Experimental/jena-client/jena-client.mdtext [3] http://people.apache.org/~sallen/sparql11-transaction/ [4] http://docs.spring.io/spring/docs/current/spring-framework-reference/html/transaction.html [5] https://svn.apache.org/repos/asf/jena/Experimental/jena-client/src/main/java/org/apache/jena/client/Updater.java On Sun, Aug 2, 2015 at 3:05 PM, Andy Seaborne <[email protected]> wrote: > Stephen, all, > > Recently on users@ there was a question about the s-* in java. That got > me thinking about an interface to pull together all SPARQL operations into > one application-facing place. We have jena-jdbc, and jena-client already - > this is my sketch take. > > [1] RDFConnection > > Currently, it's a sketch-for-discussion; it's a bit DatasetAccessor-like + > SPARQL query + SPARQL Update. And some whole-dataset-REST-ish operations > (that Fuseki happens to support). It's a chance to redo things a bit. > > RDFConnection uses the existing SPARQL+RDF classes and abstractions in > ARQ, not strings, [*] rather than putting all app-visible clases in one > package. > > Adding an equivalent of DatabaseClient to represent one place would be > good - and add the admin operations, for Fuseki at least. Also, a > streaming load possibility. > > Comments? > Specific use cases? > > Andy > > (multi-operation transactions ... later!) > > [*] You can use strings as well - that's the way to get arbitrary > non-standard extensions through. > > [1] > https://github.com/afs/AFS-Dev/blob/master/src/main/java/projects/rdfconnection/RDFConnection.java >
