- From: Seaborne, Andy <andy.seaborne@hp.com>
- Date: Tue, 24 Jan 2006 14:24:47 -0000
- To: "tessaris" <tessaris@inf.unibz.it>
- Cc: "RDF Data Access Working Group" <public-rdf-dawg@w3.org>
-------- 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. > > 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 > > > Cheers, > --sergio
Received on Tuesday, 24 January 2006 14:24:59 UTC