Re: Update on Update

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

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

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.

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

 > 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

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

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

	Andy

Received on Wednesday, 23 December 2009 11:30:47 UTC