Update ISSUEs summary of how far we got today

Here's how far we got today, 

ISSUE-27: Already the strawpoll. No real agreement on We didn't pass a new resolution, but ISSUE-27 is closed now, considering this earlier resolution.
ISSUE-45: Closed with resolution http://www.w3.org/2009/sparql/meeting/2010-01-12#resolution_7
ISSUE-24: Closed with resolution http://www.w3.org/2009/sparql/meeting/2010-01-12#resolution_8

still two possibly "closable" issues from the list below are left:

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

Apart from that:

ISSUE-21: More complex operations, e.g. CHANGE objects?
 ... was closed at F2F2 noting that there are no proposals for additional operations at this time, but
http://www.w3.org/2009/sparql/meeting/2009-11-03#resolution_2 but the mails suggest there was some unease with that still.
I am not sure whether processwise we can/or want to reopen that. In the end, as concrete proposals are made, I think we still have room to add them?
essentially a process question?

ISSUE-20: is still open, since although agreement that we need to manage empty graphs, some questions are not spelled out clearly, what happens e.g. when data is inserted in a non-existent  graph, looking through the long trail of mails on that issue, it may be worthwhile to spend a TC just on that...

all others below: leave unresolved for the moment.


Axel

On 12 Jan 2010, at 14:48, Axel Polleres wrote:

>> 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 17:39:13 UTC