- From: Andy Seaborne <andy.seaborne@epimorphics.com>
- Date: Mon, 03 Jan 2011 16:25:20 +0000
- To: Eric Prud'hommeaux <eric@w3.org>
- CC: SPARQL Working Group <public-rdf-dawg@w3.org>
On 03/01/11 16:04, Eric Prud'hommeaux wrote: > Per a new years resolution to minimize LC comments, I implemented > the latest grammar with some variations: > http://www.w3.org/mid/20110102043945.GA10306@w3.org > > Some of the changes were editorial (extra parens, factoring > RelationalExpresion and Aggregate for readability) but there > were several more substantial issues: > If "SELECT … { … } BINDINGS … { … }" works, shouldn't other > reporting forms also allow BINDINGS? I noticed that change - OK for CONSTRUCT and DESCRIBE. I couldn't think of a use case for sub-SELECT and in fact thought it was confusing. The original idea of BINDINGS was to support streaming variable bindings for the federated query. Sub-SELECT does not fit this. Do you have a use case in mind? > > If QuadData doesn't preclude variables, do we need it and > QuadPattern (they are currently identical)? See "@@Other notes" in rq25.xml: * QuadData and QuadPattern The notes in the grammar will say that QuadData must exclude variables but in the interests of not duplicating a substantial part of the grammar just to change the term rule to exclude variables, we just make QuadData. In implementation terms, it can be a flag to say whether variables are allowed or not. > > Why must e.g. "INSERT DATA" and "NOT EXISTS" have exactly one > space in them, instead of behaving like other tokens, separated > by [ \t\r\n]* ( "#" [^\r\n]* [ \t\r\n]* )* ? * INSERT DATA, DELETE DATA, DELETE WHERE, NOT IN as tokens Again, the grammar notes will say that while these are written in as single space, they should be WS*/comment separated. (I hope this this makes the implementers life easier for the operations INSERT-DELETE vs INSERT DATA case, and DELETE, DELETE WHERE, DELETE DATA). Done as it is in the gramamr, each operation has a token that identifies the operation so it matches the update language better.) > I sent this message to note these issues in the grammar completeness > thread. Specific replies to the proposed modifications would probably > best reference<http://www.w3.org/mid/20110102043945.GA10306@w3.org> . Here works better for me (mildly). Thanks for the comments, Andy > > > * Andy Seaborne<andy.seaborne@epimorphics.com> [2010-12-31 13:19+0000] >> >> >> On 23/12/10 12:09, Steve Harris wrote: >>> On 2010-12-23, at 11:58, Andy Seaborne wrote: >>>>> >>>>> I had an action to look at including CONSTRUCT WHERE { ... } for commonality with DELETE WHERE. I've not done anything about that, but it looks to me like it could be included as: >>>>> >>>>> 'CONSTRUCT WHERE' GroupGraphPattern SolutionModifier >>>> >>>> See discussion: >>>> http://lists.w3.org/Archives/Public/public-rdf-dawg/2010OctDec/0462.html >>> >>> I completely forgot that. >>> >>> In that case, modulo the stuff I've already mentioned, I think it's OK. >>> >>> - Steve >> >> In the spirit of facts, and not mere guesswork, I went back and >> checked on the implications of a "CONSTRUCT WHERE" short form. It's >> doable: my fears were unfounded. >> >> Based on the discussion around DELETE WHERE, I have only considered >> a BGP or construct template for the WHERE clause. No FILTER, no >> other graph patterns. >> >> It's not quite like DELETE WHERE because of FROM/FROM NAMED. >> >> It can be done by only changing the rule for CONSTRUCT: >> >> [9] ConstructQuery ::= >> 'CONSTRUCT' >> ( >> # The original rule >> ConstructTemplate DatasetClause* WhereClause SolutionModifier >> | >> # The short form. >> DatasetClause* 'WHERE' '{' TriplesTemplate? '}' SolutionModifier >> ) >> >> It may be possible to tidy this up. >> >> In the short form WHERE is mandatory - this enables the parser to >> know it's skipped the template in the full form. >> >> Therefore, I think we should put this in. The extra editing is >> quite small - adding a short para and example query to the CONSTRUCT >> section. >> >> Andy >> >
Received on Monday, 3 January 2011 16:25:58 UTC