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

Seaborne, Andy wrote:
> FilteredBasicGraphPattern is fine.  It was the original grammar
> structure that split the blocks of triples but didn't link them as BGPs.
> 
> 	Andy

Done.  Yacker updated as well.

	Andy

> 
> -------- Original Message --------
>> From: tessaris <mailto:tessaris@inf.unibz.it>
>> Date: 24 January 2006 15:14
>>
>> 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 20:06:51 UTC