- From: Andy Seaborne <andy@apache.org>
- Date: Tue, 18 Apr 2017 16:11:36 +0100
- To: public-sparql-exists@w3.org
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. > 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 15:12:12 UTC