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

On 27 Jul 2010, at 14:24, Lee Feigenbaum wrote:

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

Right, now also remeber that we discussed it at some point, coming to the conclusion that 
essentially any SPARQL endpoint could refuse any query/features, so it would from that point 
of view be ok to add it to query, but I can't remember whether that was really the final 
conclusion :-| need to dig out minutes...

>> The grammar includes SERVICE and BINDINGS anyway.
> 
> OK.

That alone does not seem to prevent SERVICE and BINDINGS being explained in a separate document, does it?

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

So:

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

?

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

That's mean answering "no" to my question "Do we need more?" 

i.e.

PROPOSED: Close ISSUE-23 with the insight that the current content HTTP negotiation 
mechanism (as discussed in sparql11-protocol) is sufficient.

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

you mean about whether we keep fed separate or not?
True, if we merge them, we don't run into this issue.

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

PROPOSED: Close ISSUE-37 noting that SPARQL 1.1 Update is implicitly defined 
for any query feature (including fed query, if included) that we will include into SPARQL 1.1 Query  

would that do?
> 
>> 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?

Goof point!


> Lee
> 
>> Andy
>> 
>> 
>

Received on Tuesday, 27 July 2010 13:43:47 UTC