Re: Proposed: SPARQL grammar is complete as-is

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

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 

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


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

Here works better for me (mildly).

 Thanks for the comments,

> * Andy Seaborne<>  [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:
>>> 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    ::=
>>   (
>>     # 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