Re: SPARQL 1.1 Update

Richard has already accepted the responses to date.

He did suggest that I point out the changes made in the Update
document that address his concerns, to make it a matter of public
record. It is some time past, but we are cleaning up the outstanding
issues.

I apologize that it took so long for this formal response, but some of
the details have been updated after further discussion. Richard, if
anything here does not meet with your approval, then please respond.

On Fri, Jan 8, 2010 at 5:32 PM, Richard Newman <rnewman@twinql.com> wrote:
> Hi folks,
>
> A few questions/comments on the Update portion of the 1.1 draft:
>
> * DELETE/MODIFY/INSERT are described in terms of CONSTRUCT templates.
> CONSTRUCT templates allow blank nodes, which are generated as fresh blank
> nodes for each input row. This makes sense for INSERT, but it doesn't make
> sense for DELETE: the fresh blank node will never match a triple in the
> store, than thus
>
>  DELETE { ?s ?p [] } WHERE { ?s ?p ?o }

Blank nodes in a DELETE template have now been forbidden, after
detailed discussions on this issue and considering possible
alternatives.

> * INSERT et al permit multiple "INTO" URIs:
>
>  INSERT [ INTO <uri> ]* { template } [ WHERE { pattern } ]
>
> but the text discusses the graph in the singular ("The graph URI, if
> present, must be a valid named graph..."). Is it intended that '*' actually
> be '?'?

INTO is no longer used. Now, every portion of the template will be
inserted into the graph specified by WITH, unless this if overridden
by enclosing in a GRAPH <graphUri> { ... } pattern. The use of GRAPH
indeed allows to use a single INSERT to do insert into several graphs.

> * Re atomicity: it would seem that, for systems which will allow multiple
> SPARQL/Update requests within a single transaction, the requirement that
> "Each request should be treated atomically by a SPARQL-Update service" is
> onerous. I don't know of too many systems that support sub-transactions, and
> thus implementations will be forced to take one of two routes:
>
>  1. Violating the spec: "sorry pal, that doesn't apply: our transactions
> have multi-request scope"
>  2. Annoying users: "sorry pal, we aborted your transaction because SPARQL
> 1.1 says we have to, even though you wanted to handle it yourself".

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).

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.

> * There doesn't seem to be any mention at all of responses in the draft. Is
> that intentional?

This is now mentioned in Section 3.
"Operations all result either in success or failure.[...]"

The text here is left deliberately vague, so as not to be a burden by
forcing a particular protocol or API to encode constructs that are
inappropriate.

> * Re LOAD: if we can have CREATE SILENT, how about LOAD SILENT, which
> doesn't fail (and abort your transaction!) if the LOAD fails?

We have added LOAD SILENT.

> * I'd like to throw my 2¢ in for Issue 20.
>
> It strikes me as a little short-sighted to assume that every store operates
> with first-class graph objects, such that they can be created and deleted in
> a closed-world fashion: not only does this conflict with some
> implementations (e.g., those which use quad stores to efficiently implement
> named graphs, and those which dynamically load data from a graph on an ad
> hoc basis), but it also is dissonant with the "triple stores are caches of
> the semantic web" open-world view.
>
> I see in emails text like "We have agreed on the need to support a graph
> that exists and is empty"[1]. I would like to see strong supporting evidence
> for this in the spec (or some other persistent and accessible place) before
> resolving this issue. I personally don't see any need to distinguish an
> empty graph (after all, it's easy to add an all-bnodes triple to it to make
> it non-empty but without excess meaning).
>
> I note that there is no proposal for CREATE SUBJECT (or PREDICATE or
> OBJECT), nor CREATE LANGTAG. I see little point in unnecessarily
> special-casing one value space to reduce its dynamism.
>
> From interactions with users, I expect that "oh, you mean I have to CREATE a
> graph before I can use it in an INSERT query?" will be a common question,
> and "always preface your query with CREATE SILENT..." the pervasive
> response. Seems like a waste of time to me.
>
> (Regardless of the official outcome of the issue, my implementation is
> unlikely to strictly follow the CREATE/DROP behavior, because it would be
> inefficient to track graphs for the sole purpose of throwing errors in edge
> cases. CREATE will be a no-op, and DROP will be identical to CLEAR.)

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.

Regards,
Paul Gearon

Received on Wednesday, 4 May 2011 00:12:23 UTC