- From: Andy Seaborne <andy.seaborne@epimorphics.com>
- Date: Wed, 25 Apr 2012 09:38:56 +0100
- To: public-rdf-dawg@w3.org
On 25/04/12 09:11, Polleres, Axel wrote:
> I have a question on the discussion for BINDINGS:
>
> Was the proposal of SA-3 to allow BINDINGS also within subselects
> considered?
>
> If I understand it correctly, this would be implementable by
> changing one grammar rule
> [8] SubSelect ::= SelectClause WhereClause SolutionModifier
> to
> [8] SubSelect ::= SelectClause WhereClause SolutionModifier BindingsClause
Downside - you need to add a subquery in order to put BINDINGS inside a
query i.e. overhead.
> I actually like this, since it seems to be quite a clean and simple
> way to address the issue:
>
> (i) it makes BINDINGS available essentially anywhere
> (ii) it still keeping BINDINGS "in spirit" at query level
BINDINGS don't really have any logical connection with query level as
they are defined to be a join of they data table to the results of the
graph pattern before select expressions and solution modifiers.
> (iii) it would allow to address the comments
> (iv) it wouldn't cause any algebra changes, would it?
BINDINGS don't exist in the algebra :-) in the sense there is no
"bindings" algebra operator. They are become a data table that is
joined in the usual way. So just make the data table allowed at more
places ...
>
> Thoughts?
>
> Best,
> Axel
>
>
Better: add BindingsClause to
[58] GraphPatternNotTriples
::= GroupOrUnionGraphPattern | OptionalGraphPattern |
MinusGraphPattern | GraphGraphPattern | ServiceGraphPattern | Filter |
Bind | BindingsClause
{ ?s ?p ?o BINDINGS ?p ?o { (:p 157) (:q 34.7) }
execution wise - happens after 'extend' (BIND) and before 'filter' (FILTER)
then its in subqueries and everywhere else.
Andy
Received on Wednesday, 25 April 2012 08:39:37 UTC