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