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

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