Re: another problem with Proposal B

On 04/18/2017 08:11 AM, Andy Seaborne 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.

Is this the intent of Proposal B?  Is this stated somewhere?

Currently Proposal B doesn't live up to this intent.  Is Proposal B going to
be modified?  If so, are these modifications going to also be made to
pre-binding in SHAC?  It appears that at least one implementation of SHACL
implements pre-binding, and implements it in a way that doesn't live up to
this intent.

> That makes a VALUES with no entries behave like an empty BGP in the algebra;

Well, VALUES With no entries already behaved like an empty BGP in SPARQL.
The current Proposal B breaks this equivalence.   I guess that Proposal B
could be modified to not break in this way.

> there is already a restriction on using the a potential current row variables.

The restriction was recently added.  I don't see any reason for the
restriction.  There is no techical reason to add the restriction, which
really only serves to make Proposal B less useful that it might otherwise
be.

>> 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.

Sure, but the problem here is that simplification in SPARQL can remove the
empty BGP that is needed for Proposal B to have effect in some places.  (See
below for a fixed example, though.)

> 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

Yeah, I messed up on this one when I tried to simplify it.  To get a problem
with BIND there has to be a construct in front of it, such as a VALUES or a
sub-select.  I put one example in the data shapes tests, which for EXISTS
looks like

SELECT ?this WHERE {
  ?this a ex:good .
  FILTER EXISTS { { SELECT * WHERE { } }
                  BIND ( ?this AS ?that )
    ?that a ex:bad } }

peter

Received on Tuesday, 18 April 2017 16:52:14 UTC