Re: SPARQL 1.1 Update

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.

Regards,

-Richard

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