- From: Lee Feigenbaum <lee@thefigtrees.net>
- Date: Tue, 27 Jul 2010 09:24:01 -0400
- To: Andy Seaborne <andy.seaborne@epimorphics.com>
- CC: Axel Polleres <axel.polleres@deri.org>, SPARQL Working Group <public-rdf-dawg@w3.org>
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