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

-------- 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