tomorrow's agenda (and initial open ISSUES summary.. )

rough agenda:
- shortcuts in update 
- review of open ACTIONs and ISSUEs
- do we need a dedicated TC on protocol?

Didn't get all through the issues list yet yet (see below), but still wanted to send it out, since I want to use some time tomorrow to go through the issues.
I will sort them and prioritise those I think we could possibly close and put a full agenda up later in the afternoon.
Anyone who can shed more light to one or the other issue, reply and (for ease of tracking), put the resp ISSUE number in the mail subject...

 Apart from this, I want to discuss shortcuts in update (as per http://lists.w3.org/Archives/Public/public-rdf-dawg/2010JulSep/0053.html)
tomorrow, which we postponed last week.

 Lastly, wheb looking through the issues, I reaslised that it seems we have some things open on protocol... just to check whether a dedicated TC on those issues might help to get forward.


Axel




=======================================================================
ISSUE-1

How to specify BasicFederatedQuery in a way that acknowledges optional
nature of feature & security issues

Anybody has a proposal on this?
My proposal would be to just keep it in a separate document and mark 
it as "SHOULD" or "MAY be implemented" plus tie it to a feature in sd:

=======================================================================
ISSUE-16
Dealing with aggregates over mixed datatypes 

I had the impression that all of these issues were discussed and
resolved in the last F2F. The open question is mainly when and how to
close this... it seems that it depends on the query editors
acknowledging that all F2F resolutions were clear and have been
implemented, whereupon we can vote to close this... yes?

=======================================================================
ISSUE-18
Concurrency in SPARQL/update
+
ISSUE-26
Conjunction of operation vs atomocity, transactions

I understood there was agreement that we require that any compliant
implementation treats every request atomically, and that we don't want
to go any further in specifying transacionality. How this is achieved
and how concorrency is handles is up to the implementation. 
Where do we say that in the specs?
Protocol seems to be the place?

If we can agree on that, is it possible to close this ISSUE or anyone 
speaking for keeping it open? Otherwise:

PROPOSED: to close ISSUE-18 and ISSUE-26 with the insight that we require that any compliant
implementation treats every request atomically, and that we don't want
to go any further in specifying transacionality. 

=======================================================================

ISSUE-19
Security issues on SPARQL/UPdate

The current section in the draft
http://www.w3.org/2009/sparql/docs/update-1.1/Overview.xml#sec_security
is still fairly empty. 
Do the editors think they have sufficient information to draft this section?
Did we collect relevant issues already in one place?
I would like to keep this OPEN until we have a reasonable draft for this section.

=======================================================================
ISSUE-22
Support of SOAP/WSDL in protocol for SPARQL/Update

We removed the section on SOAP bindings from http://www.w3.org/2009/sparql/docs/protocol-1.1/
(though the doc still has some refs to SOAP), may need to be checked.

PROPOSED: to close this issue with the understanding that SPARQL1.1 only standardizes HTTP bindings, and will specify these in WSDL2.0.

FWIW, the SOAP namespaces are still defined in 
http://www.w3.org/TR/sparql11-protocol/protocol-query.wsdl
should we drop them?
=======================================================================
ISSUE-23
Content negotiation/switch for mediatype

It seems that even in related mails, this ISSUE has become unclear.
It appeared first in the discussion of protocol issue in F2F1.
What I could vaguely get our of the notes from F2F1 and mail is that it is, 
if anything concerning service description and/or protocol:
http://lists.w3.org/Archives/Public/public-rdf-dawg/2009AprJun/0344.html

At the moment, protocol mentions content negotiation only in connection with CONSTRUCT.
Do we need more? What about requesting JSON for SELECT? Does that need to be mentioned?
http://www.w3.org/TR/rdf-sparql-json-res/
Was there any idea to take this further?
If not, do we just leave that? 
In general, What do we do about the result format docs?
=======================================================================
ISSUE-26
Conjunction of operation vs atomocity, transactions

see ISSUE-18 above

Apart from what was said in connection to ISSUE-18 before, syntactic issues around this seem to be settled:
http://www.w3.org/2009/sparql/meeting/2010-03-25#resolution_4

=======================================================================
ISSUE-30
What RESTful update operations should be defined?

Simplest proposal would be:

PROPOSED: close ISSUE-30 with the agreement that we will restrict ourselves to the
operations mentioned in  the current draft http://www.w3.org/2009/sparql/docs/http-rdf-update/#graph-management

=======================================================================
ISSUE-33
Can we use the correct meaning of the full slate of HTTP errors when specifying the update protocol via WSDL?

The only thing I realize at the moment is that this ISSUE is not even mentioned in the protocol draft.

=======================================================================
ISSUE-35 
Can aggregate functions take DISTINCT as an argument a la SELECT COUNT(DISTINCT ?X)?

Editors? Is ther any problem with allowing DISTINCT in the general definition of 
aggregate semantics, i.e. have it for all updates?
Does that make sense?
Note: it seems that the same could be achievable with a DISTINCT subquery, i.e.

 SELECT COUNT(DISTINCT ?X) {…}
  -->
 SELECT COUNT(?X)
  { SELECT DISTINCT ?X {…} } 

?
=======================================================================
ISSUE-37
How does basic federated query interact with SPARQL/Update?

Was discussed last in May
http://lists.w3.org/Archives/Public/public-rdf-dawg/2010AprJun/0248.html

"
>> On 16 May 2010, at 03:53, Lee Feigenbaum wrote:
>>> * We haven't closed ISSUE-37, but I would propose that:
>>>  PROPOSED: Close ISSUE-37 noting that SPARQL 1.1 will not address basic federated update in any way, no change needed.
>> 
>> I agree with the proposal but I haven't seen such proposal in minutes of previous TC.
>> Could it be addressed in tomorrow's t-con ?
> 
> While I don't want to see updates applied in a federated way, it would
> be awkward to prevent federation in the WHERE clause. After all, it
> might be handy to remove data based on data found in another store.
> 
> Can we get opinions from people about this please?

I haven't think of that, but that would make sense to allow SERVICE in the WHERE clause from an update, indeed.
Could we propose a vote in that direction "SPARQL/Update allows the use of SERVICE in the WHERE clause"
"

Appears to me a Fed-issue (in connection to what was said above on ISSUE-1 above:

PROPOSED: federated query document needs to specify what SERVICE keyword in the WHERE clause means

(anyways I'd leave the issue open until at least there is a respective section "Federated queries and SPARQL/Update drafted in 
http://www.w3.org/2009/sparql/docs/fed/service, or can we close it with the earlier resolution in mind that SPARQL1.1/Update WHERE clauses are just as in SPARQL1.1/Query?)
=======================================================================
ISSUE-39
Can variable used as aliases for expressions be themselves used in other expressions?

It seems that the current draft handles that case in a clearly defined manner.
http://lists.w3.org/Archives/Public/public-rdf-dawg/2010JanMar/0274.html

> ISSUE-39
 > Can variable used as aliases for expressions be themselves used in other
 > expressions?
 > DONE
 > Scope starts at point of definition - can use to the right and outer 
scope.

PROPOSED: Close ISSUE-39 with the insight that the current draft 
handles that case in a clearly defined manner.

=======================================================================
ISSUE-43
should entailment-regimes be declared over the whole dataset or individual graphs?

was on the agenda of in http://www.w3.org/2009/sparql/meeting/2010-02-24
but seems it wasn't discussed.

I have the impression that we're still not clear about this, but essentially 
we don't say anything about it, except in SD, where I think we don't prevent different
entailment regimes for different graphs (Andy's use case). Is that enough?

If so, can we close this?

=======================================================================
ISSUE-44
Suitability of term "networked RDF knowledge"

This was discussed  in the dedicated TC on http-rdf-update:
http://www.w3.org/2009/sparql/meeting/2010-06-07#__22_Networked_RDF_Knowledge__22_
and was resolved to change networked RDF knowledge to RDF knowledge

PROPOSED: Close ISSUE-44 with the conclusion reached at http://www.w3.org/2009/sparql/meeting/2010-06-07#__22_Networked_RDF_Knowledge__22_

See also: ACTION-253 http://www.w3.org/2009/sparql/track/actions/253
Chime, indications when will this be tackled?
=======================================================================
ISSUE-47
Is MODIFY syntax required?

-TBD-
=======================================================================
ISSUE-48
Is DELETE too verbose?

-TBD-

=======================================================================
ISSUE-49
Is a graph an information resource?

-TBD-
=======================================================================
ISSUE-51
Shall dataset clauses be allowed in SPARQL/update?

-TBD-
=======================================================================
ISSUE-52
Do we need the availability of an unnamed graph in SD?

-TBD-
=======================================================================
ISSUE-56
Does HTTP PATCH affect either the SPARQL Protocol or the SPARQL Uniform etc. HTTP etc. Protocol?

-TBD-
=======================================================================
ISSUE-57
Assignment/LET

-TBD-
=======================================================================

ISSUE-58
Register a MIME type for SPARQL Update requests?

-TBD-
=======================================================================

More new ISSUEs?

 Protocol seems to have some unnamed open issues, e.g. OUT format of update.
Where do we (need to) say something about transactionality?
Needs to be fixed, shall we raise this?

Apart from other unclear issues mentioned around protocol above (ISSUE-33, ISSUE-23) it seems the next 
dedicated TC should be on protocol issues.
=======================================================================

Received on Monday, 26 July 2010 13:12:57 UTC