W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > January to March 2011

Re: Proposed: SPARQL grammar is complete as-is

From: Eric Prud'hommeaux <eric@w3.org>
Date: Mon, 3 Jan 2011 11:04:16 -0500
To: Andy Seaborne <andy.seaborne@epimorphics.com>
Cc: Steve Harris <steve.harris@garlik.com>, Lee Feigenbaum <lee@thefigtrees.net>, SPARQL Working Group <public-rdf-dawg@w3.org>
Message-ID: <20110103160415.GA23618@w3.org>
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?

  If QuadData doesn't preclude variables, do we need it and
  QuadPattern (they are currently identical)?

  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]* )*   ?

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


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

-- 
-ericP
Received on Monday, 3 January 2011 16:04:55 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:45 GMT