Re: another problem with Proposal B

good evening;

> On 2017-04-18, at 17:11, Andy Seaborne <andy@apache.org> wrote:
> 
> 
> On 13/04/17 20:50, Peter F. Patel-Schneider wrote:
> > Proposal B has another problem related to simplification.
> >
> >
> > The simplification examples in section 18.2.3 of the SPARQL document > show that
> > simplification is to be performed on join(Z,X) for any X.  This
> > removes the
> > initial empty BGP in many group graph patterns, including
> >   { VALUES ?junk { } BIND ( ?this AS ?that ) ?that a ex:bad . }
> 
> A systematic treatment for VALUES would be to add it to the "Values Insertion" step so that the variables of the current row are included.
> 
> Proposal B is "make the current row available everywhere inside EXISTS" so that seems (to me) like a natural step.
> 
> That makes a VALUES with no entries behave like an empty BGP in the algebra; there is already a restriction on using the a potential current row variables.

is "a VALUES with no entries” intended to mean a values clause with variables and no solutions - as above, a values clause with no variables, but one solution, or a clause with neither?

> 
> 
> > resulting in
> >   Join( Extend( empty multiset, ?that, ?this ), BGP( ?that a ex:bad ) )
> > so in
> >   SELECT ?this WHERE {
> >     ?this a ex:good .
> >     FILTER EXISTS { BIND ( ?this AS ?that ) ?that a ex:bad }
> >     }
> > solutions will be returned for every direct instance of ex:good if
> > there is
> > any direct instance of ex:bad, counter to expectations.
> 
> This second case is not VALUES.
> 
> SELECT * {
>   BIND ( ?this AS ?that ) ?that a ex:bad
> }
> 
> is the algebra:
> 
>  (join
>    (extend ((?that ?this))
>      (Z - empty BGP))
>    (bgp (triple ?that rdf:type ex:bad))
>    )
> 
> Simplification does not occur - the empty BGP is inside the (extend) so there is not a "form join(Z,X)".
> 
>    Andy
> 
> 
> 
> 
> 
> 
> 
> 
> >
> > peter
> >
> 
>

Received on Tuesday, 18 April 2017 16:28:26 UTC