- From: Seaborne, Andy <andy.seaborne@hp.com>
- Date: Tue, 24 Jan 2006 15:22:22 -0000
- To: "tessaris" <tessaris@inf.unibz.it>
- Cc: "RDF Data Access Working Group" <public-rdf-dawg@w3.org>
FilteredBasicGraphPattern is fine. It was the original grammar structure that split the blocks of triples but didn't link them as BGPs. 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 15:22:35 UTC