- From: Andy Seaborne <andy.seaborne@talis.com>
- Date: Thu, 07 Jan 2010 23:05:15 +0000
- To: Paul Gearon <gearon@ieee.org>
- CC: SPARQL Working Group <public-rdf-dawg@w3.org>
On 07/01/2010 8:28 PM, Paul Gearon wrote: > Andy, > > You mention closing a couple of the issues below. I'm not really clear > on the procedure, but does that have to happen during a meeting? A question for the chairs, surely? > > On Wed, Dec 23, 2009 at 6:30 AM, Andy Seaborne<andy.seaborne@talis.com> wrote: >> On 19/12/2009 03:34, Paul Gearon wrote: >>> ISSUE-27: Can subqueries (ASK, SELECT etc.) be nested inside update >>> queries? >> >> Patterns should be the same as query 1.1 IMO so SELECT subqueries. >> >> But at F2F2: >> ---- >> RESOLVED: SPARQL Update WHERE clauses will be at least SPARQL 1.0 QUERY, >> with each feature 1.1 adds to SPARQL Query being AT RISK for this. This >> closes ISSUE-27. >> ---- > > So the issue gets closed, but the "AT RISK" indicates that these > features may or may not be included. I'd have thought that closing > this issue would figure out these features, but apparently not. > > While I understand that an implementation will be permitted to build > on SPARQL 1.1 Query for SPARQL 1.1 Update, this resolution makes it > appear that the spec won't be doing this. It puts any new features from SPARQL 1.1. query "at risk". That means it's a warning it might be taken out but for now, all 1.1 features in patterns are being done. See also end of http://lists.w3.org/Archives/Public/public-rdf-dawg/2009OctDec/0376.html > That means that we won't be > able to use a common grammar for the spec (which you - Andy - mention > below). I recall some of this conversation, but I do find it unusual > that SPARQL 1.1 Update would only require SPARQL 1.0 Query. Is it > likely that anyone will want to implement Update while not also > implementing the new query facilities? (who is that question to?) IMHO defining SPARQL 1.1 Update with SPARQL 1.0 WHERE patterns make no sense. If desperate, as SPARQL 1.1 is a superset of SPARQL 1.1 we can have a combined grammar and only test for compliance on SPARQL 1.0 patterns. But I think that SPARQL 1.1 Update should use SPARQL 1.1 Query and I don't know of any reason to the contrary. There was speculation that some systems might implement SPARQL 1.0 patterns but as far as I know it was just speculation. I'd just regard it as a partial implementation of SPARQL 1.1 Update anyway. I strongly prefer that "SPARQL 1.1 Update" is based on "SPARQL 1.1 Query". ... >>> >>> ISSUE-21: More complex operations, e.g. CHANGE objects? >>> Unresolved. Leaving issue in the document. But I think we're not going >>> to do anything, are we? >> >> I'd like to leave this open - get the design done then see if there are any >> addition syntactic short forms to put in. Changing a triples object is >> something that is a perma-thread on jena-dev so theer is a user/application >> writer expectation here. I thin it's just change object value - it may be >> better addressed with a clear and explicit example (or examples) in >> SPARQL/Update. > > I think this is necessary, but is it necessary in SPARQL? I figured > SPARQL to be a triple-level language. Now that's not adequate for most > people working with data, but I see object querying and manipulation > being implemented in a higher level language which may be built on > SPARQL. (I'm admin for a project that does just this: Topaz). Wrong kind of object. I meant object of a triple. S-P-Object. :book dc:title "Wrong" ==> :book dc:title "Right" Andy ... > > Regards, > Paul Gearon
Received on Thursday, 7 January 2010 23:05:43 UTC