- From: Seaborne, Andy <andy.seaborne@hp.com>
- Date: Tue, 24 Jan 2006 20:06:35 +0000
- To: "Seaborne, Andy" <andy.seaborne@hp.com>
- Cc: tessaris <tessaris@inf.unibz.it>, RDF Data Access Working Group <public-rdf-dawg@w3.org>
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