Hi Jeen,
Thinking about things from an OO perspective, if you make
UpdateOperation a sub-type of Query, then you are saying "an
UpdateOperation is a Query", which sounds a bit odd. Looking at the
interface of Query, it has some methods relevant to update operations
and some that are not, i.e.
* binding methods - these are relevant to updates (I assume), because
you might want to invoke an insert operation many times with different
bindings (like in CLI)
* query methods - get/set of 'include inferred', 'max query time',
'dataset' don't seem to have any relevance to update operations (at
least I don't want my updates to time out)
So, would it be better to have an interface hierarchy like this:
Operation (or RepositoryOperation) - bindings methods
Query - as current, but bindings methods moved down to Operation
BooleanQuery, GraphQuery, TupleQuery (no change here)
Update (or UpdateOperation) - with execute method (call this 'update'?)
Sub-types for INSERT, DELETE, CLEAR, etc if necessary/appropriate?
In other words, rather than make Update a sub-interface of Query,
instead factor out a super-interface of them both (Operation). This
would make no difference to existing code that uses these APIs, but
would seem to be better structured (to me).
Thanks for all your hard work,
barry
On 23/05/11 03:01, Jeen Broekstra wrote:
> Dear all,
>
> I am currently getting ready to start on support for SPARQL 1.1
> Update[0] in Sesame. Before I start coding, however, there are a number
> of design issues affecting public interfaces that need to be solved.
> It's all fairly straightforward, really, but it's always a good idea to
> get some feedback first, and see if I haven't forgotten anything.
>
> Repository API
> --------------
>
> The Repository API[1] will need to be extended to cope with SPARQL
> Update: how do we supply a SPARQL update statement to the repository,
> execute it, and receive the result (success or failure).
>
> My proposal: we add an interface org.openrdf.query.UpdateOperation,
> which encapsulates a SPARQL 1.1 update operation. This interface would
> directly inherit from org.openrdf.query.Query, and would look roughly
> like this:
>
> public interface UpdateOperation extends Query {
>
> /** returns 'true' iff successfully executed, 'false' otherwise */
> public boolean execute();
>
> }
>
> We then extend RepositoryConnection with a prepare method to generate
> UpdateOperation objects:
>
> public UpdateOperation prepareUpdateOperation(QueryLanguage ql, string
> query);
>
> Anything I overlooked?
>
> SAIL API
> --------
>
> My current thinking is that SPARQL Update will not be explicitly
> supported at the SAIL level, but instead, a processor will translate any
> incoming SPARQL update request into a set of basic (currently existing)
> API operations on the SAIL. The WHERE-clause of any update statement can
> be supplied to the SAIL as a TupleExpr, enabling the SAIL implementation
> to do store-specific optimizations on it.
>
> REST Protocol
> -------------
>
> In order to support SPARQL Update over the Web, Sesame's REST
> protocol[2] will need to be extended.
>
> The current protocol in fact already supports update operations,
> although these operations are formulated as PUT/POST/DELETE requests
> with either serialized RDF or an XML transaction document as content.
>
> There are a few important requirements here:
>
> 1. we need to guarantee the RESTful nature of the protocol;
>
> 2. we need to make sure that query and update can be distinguished at
> the HTTP level (that is, no inspection of request content necessary), so
> that load balancers and/or access restriction modules can handle updates
> seperately from 'normal' queries.
>
> My proposal: SPARQL update operations are supported as POST requests on
> /repositories/<REP_ID>/statements. The sparql update query is supplied
> as a form-urlencoded variable named 'update' (this is consistent with
> the current SPARQL 1.1. Protocol WD, as far as I can tell):
>
> POST /openrdf-sesame/repository/mem-rdf/statements HTTP/1.1
> Content-Type: application/x-www-form-urlencoded
>
> update=insert%20data%20where...
>
> The response would be an empty HTTP 204 NO CONTENT if succesfully
> executed (as an aside, we really should document Sesame's response HTTP
> error codes...).
>
> The advantage of this approach is that it is very easy to distinguish
> update operations from query operations, even though both are (or can
> be) POST requests.
>
> A possible downside in this setup: there is no _single_ SPARQL endpoint
> URL for a given Sesame store. I am not sure if that will have negative
> consequences in practice though.
>
> Again: comments? Things I overlooked? Let me know.
>
> Regards,
>
> Jeen
>
> [0] http://www.w3.org/TR/sparql11-update/
> [1]
> http://www.openrdf.org/doc/sesame2/api/index.html?org/openrdf/repository/package-summary.html
> [2] http://www.openrdf.org/doc/sesame2/system/ch08.html
>
>
>
>
> ------------------------------------------------------------------------------
> What Every C/C++ and Fortran developer Should Know!
> Read this article and learn how Intel has extended the reach of its
> next-generation tools to help Windows* and Linux* C/C++ and Fortran
> developers boost performance applications - including clusters.
> http://p.sf.net/sfu/intel-dev2devmay
> _______________________________________________
> Sesame-general mailing list
> Sesame-general@...
> https://lists.sourceforge.net/lists/listinfo/sesame-general
|