Here is a summary/draft to try to pull the discussions together:
There would be three main interfaces: one application facing and two for
the two SPARQL protocols.
(all names provisional!)
== RDFConnection
* The application facing API
* RDFConnectionFactory (name?) to make the things.
* It builds on the two SPARQL protocols.
* Autocommit provided (client-side)
* No mention of QueryExecution
Results processed in a style that means RDFConnection gets to manage the
result set. Probably also one operation to execute and copy the results
because this is a recurring support area. Tryi to get smart and pass
aroudn a stream uis
* Composed of SPARQLProtocolConnection (query+update) and
SPARQLGraphStoreProtocol
* It is easier to add operations than remove them esp from a
application=facing API like RDFConnection so start cautious. There could
be useful compound operations or ones applicable only sometimes, but for
now, roughly a 1-1 match to a SPARQL operation.
= SPARQLProtocol
* The operations of Query, Update
* Explicit transactions only (client-side)
= SPARQLGraphStoreProtocol
* DatasetAccessor with renaming to make it clear how the operations
refer to HTTP operations - we might as well call them gspGET, gspPOST,
gspPUT, gspDELETE or something like that and have RDFConnection have
task focused names (e.g. loadFile, addModel, ...)
* Deprecate DatasetAccessor (and DatasetGraphAccessor?)
* Explicit transactions only (client-side)
== Notes/Questions:
* loadFile can be done two ways - GSP and INSERT DATA (GSP is more
efficient - but if no GSP handlers is available, it can switch to SPARQl
Protocol means.
* Is bulk delete a major requirement (more a question of how much to
design for it - not whether to have it or not e.g. may be only in
SPARQLProtocol).
* QueryExecution (or indeed the QueryStatement version) is going to be a
problem because calling the operation only sets it up, not actually
executes it. And I would like to avoid, at least to the application
getting into excessive nesting of try-with-resources. That is valuable
for RDFConnection itself.
JDBC has statement objects for some reasons that don't apply to Jena:
Prepared statements (server side) and parameterised queries (Jena has
different mechanisms - may show in RDFConnection and happen client side)
* non-HTTP remote connection in the future.
Always tricky to plan for the unknown! I think we should be aware this
may happen but not worry too much now (I used to put in designs for all
possibilities but looking back, they never end up right and do create
legacy baggage all too easily.)
== QueryExecution
(For SPARQLProtocol, not RDFConnection)
I'd like to refactor this and not create a new, separate interface that
that does the same thing. So at a minimum, a super interface for exec*
With more change, one option is to remove (via deprecation cycle)
get/set initial binding and require providing it at the factory step.
The getDataset and getQuery operations are more convenience - we could
remove or continue to document they may return null. As the query
carries prefixes information for presentation, retaining getQuery makes
sense to me. Remove getDataset?
Andy
