Re: Update on Update

Andy,

You mention closing a couple of the issues below. I'm not really clear
on the procedure, but does that have to happen during a meeting?

On Wed, Dec 23, 2009 at 6:30 AM, Andy Seaborne <andy.seaborne@talis.com> wrote:
> On 19/12/2009 03:34, Paul Gearon wrote:
>> ISSUE-27: Can subqueries (ASK, SELECT etc.) be nested inside update
>> queries?
>
> Patterns should be the same as query 1.1 IMO so SELECT subqueries.
>
> But at F2F2:
> ----
> RESOLVED: SPARQL Update WHERE clauses will be at least SPARQL 1.0 QUERY,
> with each feature 1.1 adds to SPARQL Query being AT RISK for this. This
> closes ISSUE-27.
> ----

So the issue gets closed, but the "AT RISK" indicates that these
features may or may not be included. I'd have thought that closing
this issue would figure out these features, but apparently not.

While I understand that an implementation will be permitted to build
on SPARQL 1.1 Query for SPARQL 1.1 Update, this resolution makes it
appear that the spec won't be doing this. That means that we won't be
able to use a common grammar for the spec (which you - Andy - mention
below). I recall some of this conversation, but I do find it unusual
that SPARQL 1.1 Update would only require SPARQL 1.0 Query. Is it
likely that anyone will want to implement Update while not also
implementing the new query facilities?

>> ISSUE-45: Can INSERTS, DELETES, and other 'subupdates' be nested
>> inside SELECT queries?
>
> (Reading this as update inside query requests ....)
> I am strongly opposed to this.
> Major security issues.

This is why I disallowed it. It seemed obvious to me.  :-)

> The converse, having SELECT in SPARQL/Update (which is the ability to
> perform a SELECT query, keep hold of the result table then us it several
> times for several updates) might be worth considering.

I don't mind this (meaning that I can see how I'd implement it
myself), but the fact that it's a new operation with a need for new
syntax makes me think it's out of scope for this version. OTOH, it
looks like a worthwhile conversation to have, and an extension I'd be
prepared to implement to get the ball rolling for SPARQL 1.2 Update.

> Also, it might be good to have preconditions for changes.  ASK is one way to
> do that.

This would alleviate some of the concerns about transactions. Again,
it seems to be out of scope, but something worthwhile looking at.

>> ISSUE-46: Can INSERTS, DELETES, and other 'subupdates' be nested
>> inside update language queries?
>> Disallowing each of these proposals
>
> F2F2:
> RESOLVED: Close ISSUE-46, no action required.
>
>>
>> ISSUE-24: Can data be SELECTed from one graph and INSERTed into another
>> (moved)?
>> This is allowed
>
> See separate email on short forms.
>
>> 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?
>
> I don't think so - it's just a pattern in a WHERE clause.
>
>> 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.
>
> Big issue - pulled out into separate email

I'll address it there.

>> 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?
>
> I'd like to leave this open - get the design done then see if there are any
> addition syntactic short forms to put in.  Changing a triples object is
> something that is a perma-thread on jena-dev so theer is a user/application
> writer expectation here.   I thin it's just change object value - it may be
> better addressed with a clear and explicit example (or examples) in
> SPARQL/Update.

I think this is necessary, but is it necessary in SPARQL? I figured
SPARQL to be a triple-level language. Now that's not adequate for most
people working with data, but I see object querying and manipulation
being implemented in a higher level language which may be built on
SPARQL. (I'm admin for a project that does just this: Topaz).

>> ISSUE-26: How far do we go with transactions/atomicity?
>> ISSUE-18: Concurrency issues?
>
>> 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.
>
> INTO is only for INSET DATA INTO so no variables anywhere.  Looks like we
> can close the issue to me.
>
> GRAPH ?G { ... } in a modify_template would be the way to do it.

I'll remove it from the document.

>> I haven't updated the grammar yet, partly because it's been in flux,
>> and partly because I'm no great expert at it.
>
> When the flux dies down, I'll produce a single grammar as before.  I'd like
> us to get to single grammar we work from - that may well change over time
> still but it's by evolution.
>
> It helps in building up the test case suite.

While this sounds good, I'm concerned due to the resolution of
ISSUE-27 only requiring SPARQL 1.0 Query.

Regards,
Paul Gearon

Received on Thursday, 7 January 2010 20:29:20 UTC