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

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

I thought we had decided that, on balance, it would go in the query doc. 
  It would be edited separately for now but merged in when stable.

The grammar includes SERVICE and BINDINGS anyway.

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

My recollection is that we would use "SHOULD" language - implementations 
SHOULD apply SPARQL Update requests atomically.  The proposal uses 
"MUST" language and is, I believe, too restrictive in practice.

Whether a request can be achieved atomically can be influenced by the 
deployment context.  It's hard enough on individual operations. For 
example,

LOAD <http://remote/veryLargeFile>

might not be suitable for an atomic action.

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

... which is an example ...

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

Content negotiation always applies when using HTTP. It's a feature of 
HTTP, not the SPARQL protocol.

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

This is the opposite of what we discussed last time although I can't 
find a record of the discussion.

I though the proposal was to say nothing.  If it loops back to the 
service during the update, then what happens is whatever you get.  The 
loop back need not be direct.

If update requests SHOULD be atomic, then this is a bit of a non-issue.

>
> (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-49
> Is a graph an information resource?

An RDF document might be.

http://www.w3.org/TR/cooluris/ has a necessary condition but does not 
claim it is not sufficient.

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

Yes please.

	Andy

Received on Monday, 26 July 2010 17:03:19 UTC