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

On 7/26/2010 1:02 PM, Andy Seaborne wrote:
>> =======================================================================
>> 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.

I thought that the optionality (?) of the whole thing was still up in 
the air? Though there was a leaning towards making SERVICE optional and 
BINDINGS required?

> The grammar includes SERVICE and BINDINGS anyway.

OK.

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

Yes, the consensus was that requests SHOULD be treated atomically.

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

Agreed. I'd be happy to close this issue unless someone has a specific 
concern about content negotiation w.r.t. SPARQL.

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

This would be good.

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

Yes, this was the consensus: the meaning comes naturally out of the 
query language, and we see it as a sufficiently weird case that we do 
not feel the need to specify special semantics for it.

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

Perhaps we can get an action on our team contacts to take responsibility 
for this?

Lee

> Andy
>
>

Received on Tuesday, 27 July 2010 13:24:40 UTC