Re: FW: Grammar updated to reflect BGP/Constraint interpretation

Seaborne, Andy wrote:
> 
> -------- Original Message --------
> 
>>From: tessaris <mailto:tessaris@inf.unibz.it>
>>Date: 24 January 2006 14:03
>>
>>Seaborne, Andy wrote:
>>
>>>Should have been send to the WG list.
>>>
>>>	Andy
>>>
>>>-------- Original Message --------
>>>
>>>
>>>>From: Seaborne, Andy <>
>>>>Date: 23 January 2006 13:27
>>>>
>>>>I have chnaged the grammar to reflect the clarification of BGPs
> 
> and
> 
>>>>constraints by putting a rule in that is called BasicGraphPattern.
>>>>
>>>>The case of:
>>>>{ _:a :p ?v . FILTER(?v <3) . _:a : ?w }
>>>>
>>>>I have changed:
>>>> Moved constraint into a BasicGraphPattern rule
>>>> Created BlockOfTriples for a sequnece of triple patterns (this
> 
> was
> 
>>>> "Triples") Moved BlockOfTriples and BasicGraphPattern to be with
>>>> the other pattern rules Renamed Triples1 to TriplesSameSubject
>>>> Removed recursion in TriplesSameSubject
>>>>
>>>>	Andy
>>
>>Andy, I understand the reasons for the changes but I'm not sure
> 
> whether
> 
>>they match everybody's intuition.
>>
>>I think that we agree on the fact that SPARQL operators transform
> 
> answer
> 
>>sets (set of pattern solutions) rather than single pattern solutions.
>>
>>Under this assumption I see FILTER as the relational (not SQL) SELECT
>>operator. So I don't see any reason for restricting its usage to Basic
>>Graph Pattern only. E.g. I think that a query like
>>
>>   { BGP1 UNION BGP2 } FILTER (E1)
>>
>>should be fine; but it seems to me that the new grammar is preventing
>>this. 
> 
> 
> This query passes my parser:
> 
> PREFIX : <http://example/>
> 
> SELECT *
>  WHERE
>  { { :a :b ?v } UNION { :d :e ?v } FILTER(?v<3) }
> 
> And it passes the perl-based parser at Yacker  (Eric - the C parser
> crashed with a 500)
> 
> http://www.w3.org/2005/01/yacker/uploads/SPARQL
> 
> It works because the outer {} forms a group.

Yep, I see that. Although I think that the grammar should help the
reader to understand the structure of the language, it's not just a
matter of syntax.

>>When during the telecon I said that 'FILTERS' can be pushed at the end
> 
> I
> 
>>meant that
>>
>>{ _:a :p ?v . FILTER(?v <3) . _:a : ?w }
>>
>>should be understood as
>>
>>{ _:a :p ?v . _:a : ?w } FILTER(?v <3)
>>
>>I'm not sure how to reflect this on the actual grammar, though.
> 
> 
> The grammar is about the syntax - without altering the language to
> require FILTERs at the end (which in poractical terms is quite
> inconvenient), I made the BGP rule capture that the scope of the BGP was
> no broken by a filter.
> 
> 
>>Then I think that having the definition
>>
>>""""
>>Definition:  Basic Graph Pattern
>>
>>A Basic Graph Pattern is a set of Triple Patterns.
>>"""
>>
>>together with the grammar rule
>>
>>[21] BasicGraphPattern ::= BlockOfTriples? ( Constraint '.'?
>>BasicGraphPattern )?
>>
>>looks confusing; since we have Constraints as well as triple patterns.
> 
> 
> As a BGP is not a pure syntactic element of the grammar (it can be
> split) something has to give.  I choose to use a BlockOfTriples for the
> concept of adjacet triples so as not to use the term BasicGraphPattern
> here.  I reserve BGP for the thing closest to the sequence between a
> pair of {} - the {} forming scope markers (implementation dependent as
> to how this is handled so it is only indicative)
> 
> 
>>I'd rather prefer something closer to the old grammar, to be sure that
> 
> a
> 
>>Basic Graph Pattern is always a leaf in the parse tree:
>>
>>[20] GraphPattern ::= FilteredBasicGraphPattern? (
>>GraphPatternNotTriples '.'? GraphPattern )?
>>[21] GraphPatternNotTriples ::=  OptionalGraphPattern |
>>GroupOrUnionGraphPattern | GraphGraphPattern | Constraint
>>
>>with the rule
>>
>>FilteredBasicGraphPattern ::= BlockOfTriples? ( Constraint '.'?
>>FilteredBasicGraphPattern  )?
>>
>>and a comment on the fact that 'BoT1 constraint BoT2' should be
>>considered equivalent to '{ BoT1 . BoT2 } constraint'.
> 
> 
> The implication of the old grammer was that 
> 
> { _:a :p ?v . FILTER(?v <3) . _:a : ?w }
> 
> Is a group of a  { BGP1 FILTER BGP2 } and so implies that the two BGPs
> undergo enatilment separately.
> 
> 	Andy

Yes, in fact my proposal was to use the term 'FilteredBasicGraphPattern'
instead of just 'BasicGraphPattern', and have 'Constraint' *also* in the
'GraphPatternNotTriples' rule.

But if you think that the current formulation is clearer, then it's fine
for me.

--sergio

Received on Tuesday, 24 January 2006 15:14:33 UTC