Re: Update on Update

> On 07/01/2010 8:28 PM, Paul Gearon wrote:
> > 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?
> 
> A question for the chairs, surely?

I would certainly want at least resolutions recorded to close issues, in a TC or meeting.

Let me try to summarise the issues in question:

ISSUE-27: was resolved to close at F2F2 but there seems to be some later unhappiness about the wording of the resolution:
e.g. http://lists.w3.org/Archives/Public/public-rdf-dawg/2009OctDec/0385.html

Before I just mark it closed: Can we maybe just do a strawpoll to see whether we could agree to simply ALLOW sparql1.1 WHERE parts?
Is there anything concretely speaking against this?

Strawpoll: Can we allow full SPARQL1.1/Query WHERE clauses in SPARQL1.1/Update?

>> ISSUE-45: Can INSERTS, DELETES, and other 'subupdates' be nested
>> inside SELECT queries?

Let's do a strawpoll whether anybody would object against closing this with resolving to disallow it.
(given the resolution of ISSUE-46, I'd be surprised.)

PROPOSED: Close ISSUE-46 with the understanding that nesting of updates is not allowed.

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

PROPOSED: Close ISSUE-24 with the understanding moving is possible with the DELETE/INSERT construct in the 
current SPARQL1.1/Update WD.


Other issues, which I don't have concrete proposals yet, but which were mentioned in the email:


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

fine for now.

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

fine for now.


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

I'd like to keep that one in, until we have a clearer understanding and feedback on property paths, 
but indeed this looks similar enough to ISSUE-27


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

haven't had a chance to check whether there are further implications in detail 
again, maybe someone could give a summarty in the call again.


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

fine for now.

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

Sounds like: unresolved, leave it in for now?

>> ISSUE-26: How far do we go with transactions/atomicity?
>> ISSUE-18: Concurrency issues?

This are both left open for now, yes?

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

so... probably, we can simply close this:

PROPOSED: Close ISSUE-25 with the understanding that this is *allowed* by the definition of INSERT in the current SPARQL1.1/Update WD. 




best,
Axel

Received on Tuesday, 12 January 2010 14:48:46 UTC