Update on Update

Hi,

I've updated the Update-1.1 document to reflect some of the recent
decisions on syntax. I've mostly stayed close to the original text,
but since things have changed since this was written, then it's
entirely possible that there are portions that I should re-write
completely, so please don't feel shy in telling me so.

I've also looked at the outstanding issues in the document, and I want
to comment on a few of them since none are marked as "resolved" even
though I believe that many have been. I've recorded below what I've
gone with.

SubQueries:
ISSUE-27: Can subqueries (ASK, SELECT etc.) be nested inside update queries?
ISSUE-45: Can INSERTS, DELETES, and other 'subupdates' be nested
inside SELECT queries?
ISSUE-46: Can INSERTS, DELETES, and other 'subupdates' be nested
inside update language queries?
Disallowing each of these proposals

ISSUE-24: Can data be SELECTed from one graph and INSERTed into another (moved)?
This is allowed

ISSUE-28: Entailment regimes vs. update?
Unresolved. Leaving issue in the document.

ISSUE-37: How does basic federated query interact with SPARQL/Update?
Unresolved. Leaving issue in the document.

ISSUE-38: How do property paths interact with SPARQL/Update?
Unresolved. Leaving issue in the document.
This is probably one that can be resolved easily enough. As far as I
can tell, it's just a new pattern that may appear in a WHERE clause,
and need not be explicitly mentioned. Is there any other effect we may
need to consider?

ISSUE-20: Difference between an empty graph and a non-existent graph?
We have agreed on the need to support a graph that exists and is
empty. Is there anything else to consider for this issue? Does it have
an impact on the Update document? By coming to this agreement, then I
think we *don't* need to worry about it in Update. We'd only have to
consider it if we disallowed empty graphs.

I've left ISSUE-20 in, but if people agree that it's resolved, then
I'll take it out.

ISSUE-19: Security issues on SPARQL/Update
Unresolved. Leaving issue in the document.

ISSUE-21: More complex operations, e.g. CHANGE objects?
Unresolved. Leaving issue in the document. But I think we're not going
to do anything, are we?

ISSUE-26: How far do we go with transactions/atomicity?
ISSUE-18: Concurrency issues?
Unresolved. Leaving issues in the document.
However, this is one that's been discussed a little. While it wasn't
accepted by everyone, I'd like to say that update operations SHOULD be
atomic, where possible. It's not possible for some stores, which is
why I suggest watering it down to SHOULD, rather than MUST.
If this happens, then concurrency gets simpler as well. What other
concurrency issues are there to consider?

ISSUE-25: Dynamic graph (variable) for INTO graph to update/modify
I believe we have decided not to allow this, at least for Update-1.1.
Can someone please confirm for me please? Left in for the moment.

I haven't updated the grammar yet, partly because it's been in flux,
and partly because I'm no great expert at it.

Regards,
Paul Gearon

P.S. When I'm viewing this document locally I'm seeing pretty bounding
boxes, etc (for instance, around ISSUES and examples) but from the
server all of this is missing. Any suggestions what I need to do?

Received on Saturday, 19 December 2009 03:35:31 UTC