- 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