W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > May 2011

Re: SPARQL 1.1 Update

From: Richard Newman <rnewman@twinql.com>
Date: Sun, 8 May 2011 20:31:03 -0700
Cc: public-rdf-dawg-comments@w3.org
Message-Id: <F09FE281-9AFC-4542-B026-E9CE67842340@twinql.com>
To: Paul Gearon <pgearon@revelytix.com>
Hi Paul,

Only two remarks:

> Given that many operations occur over HTTP, then sub-transactions are
> not going to be common, as they imply a transaction is already
> underway (and HTTP is stateless).

Addressing this comment for a moment, apart from any formal response. See below for that.

HTTP itself is stateless, but it's also a common access protocol for all kinds of systems, including those which support transactions. For example, one might

  POST /server/transaction/new
  => redirects to a custom port, or returns a transaction ID, etc.
  POST /server/tr1234/sparql...
  POST /server/tr1234/sparql...
  POST /server/transaction/commit?id=tr1234

which includes two SPARQL Update operations within the concept of a transaction. The transaction becomes an integral part of the space of resources upon which HTTP verbs act; state exists without forcing it to be part of the protocol itself.

If each operation must be treated atomically, then one cannot coalesce them, and implementations must support sub-transactions if they support global transactions. I know that AllegroGraph supports global transactions using just such a mechanism[1], termed "sessions", so this is not an academic curiosity.

AllegroGraph will not treat each request atomically unless sessions are not used, and thus the regular auto-commit logic applies.

[1] <http://www.franz.com/agraph/support/documentation/v4/http-protocol.html#header2-685>

> More significantly, the current text is: "Each request SHOULD be
> treated atomically by a SPARQL 1.1 Update service, i.e., the execution
> of all the operations in one request should be performed atomically. "
> That means that not supporting transactions does not violate the spec,
> since SHOULD only applies unless you have a good reason to do
> otherwise.

... that is satisfactory.

> The spec now *requires* (non-empty) INSERTs to create a graph, and
> *allows* DELETEs to remove any graphs that are emptied. CREATE and
> DROP are left to allow individual stores to perform administration on
> empty graphs, if they support such a feature.

If CREATE and DROP are effectively optional ("if they support such a feature"), and your parenthetical "non-empty" INSERT remark stands, then my point here is adequately addressed, thank you.


Received on Monday, 9 May 2011 17:07:53 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:11 UTC