W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > August 2012

Re: BIND semantics (2)

From: Jeremy Carroll <jeremy@topquadrant.com>
Date: Tue, 14 Aug 2012 11:19:33 -0700
Message-ID: <502A96B5.2040005@topquadrant.com>
To: public-rdf-dawg-comments@w3.org
CC: Holger Knublauch <holger@topquadrant.com>

To assist with my previous comments, here are some suggested textual 
changes.
These are not intended as a further formal comment, and if they are 
unhelpful, please ignore them.


Current draft:
"Use of |BIND| ends the preceding basic graph pattern"

Earlier drafts:
http://www.w3.org/TR/2012/WD-sparql11-query-20120105/#bind
"Use of |BIND| is a separate element of a group graph pattern and it 
ends any basic graph pattern."

I suggest that BIND should apply to the preceding part of the group 
graph pattern, making the whole paragraph:

"The |BIND| form allows a value to be assigned to a variable from a 
group graph pattern. Use of |BIND| ends the preceding group graph 
pattern in which the variable introduced by the |BIND| clause must not 
have been used. "

To clarify this I suggest the following changes to the syntax - these do 
not change the accepted sequences, simply the parse trees - to clarify 
the scope of BIND as above.

OLD
[53]      GroupGraphPattern      ::=      '{' ( SubSelect | 
GroupGraphPatternSub ) '}'
[54]      GroupGraphPatternSub      ::=      TriplesBlock? ( 
GraphPatternNotTriples '.'? TriplesBlock? )*
[56]      GraphPatternNotTriples      ::= GroupOrUnionGraphPattern | 
OptionalGraphPattern | MinusGraphPattern | GraphGraphPattern | 
ServiceGraphPattern | Filter | Bind | InlineData

NEW
  GroupGraphPattern      ::=      '{' ( SubSelect | GroupGraphPatternSub 
) '}'
  GroupGraphPatternSub ::=     ( GroupGraphPatternSub Bind ) ? 
GroupGraphPatternSubNoBind
  GroupGraphPatternSubNoBind      ::=      TriplesBlock? ( 
GraphPatternNotTriples '.'? TriplesBlock? )*
  GraphPatternNotTriples      ::=      GroupOrUnionGraphPattern | 
OptionalGraphPattern | MinusGraphPattern | GraphGraphPattern | 
ServiceGraphPattern | Filter | InlineData

The idea, which perhaps could be formalized in the semantics, is that 
each Bind element as a left-sibling in the parse tree being the 
GroupGraphPaternSub to which it applies.

I believe with these changes that some consequential changes would then 
be needed in the semantics - also it may be clearer to introduce a new 
term (better than GroupGraphPatternSub) to clarify issues like moving 
FILTERs is legal within a GroupGraphPatternSubNoBind but not before or 
after a BIND (obviously if the FILTER does not refer to the variable 
introduced by the BIND this point is moot).

Jeremy
Received on Tuesday, 14 August 2012 18:20:03 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 14 August 2012 18:20:03 GMT