Re: another problem with Proposal B

On 18/04/17 17:51, Peter F. Patel-Schneider wrote:
> 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?

"""
this alternative mechanism makes the whole of the current row available 
at any point in the evaluation of an EXISTS expression
"""

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

Actually, no, it doesn't. No entries means zero rows unlike the 
evaluation of

Throughout this, I am assuming you meant to say:

VALUES ?junk { UNDEF }

> The current Proposal B breaks this equivalence.   I guess that Proposal B
> could be modified to not break in this way.

Exactly.

If Proposal B joins in the current row onto the values is one row of 
zero variables (which "VALUES ?junk { UNDEF }" is)

Treatment of VALUEs becomes more systematic for all base of the 
zero-input algebra operations.

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

That's your opinion.

I see it as consistent to take the assignment-once nature of SPARQL as 
important in explaining to people what is going on.

If the current row is joined on, of course, they become quite similar 
(not the same).  I dislike the possibly unexpected effect of causing a 
VALUES to become zero rows; it has no use and will be confusing.

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

Simplification applies after syntax parsing, before evaluation.

Inner "SELECT * {}" is a project of no variables of the unit table which 
is left as-is.  So no simplification.

18.2.4.4
"The set PV is used later for projection."

18.2.5.2 Projection
"""
The set of projection variables, PV, was calculated in the processing of 
SELECT expressions.

     M := Project(M, PV)
"""

There is something to account for in SELECT * but it's not simplification.

     Andy

Received on Tuesday, 18 April 2017 17:26:08 UTC