Re: another problem with Proposal B

On 04/18/2017 10:25 AM, Andy Seaborne wrote:
> 
> 
> 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
> """

This appeared to be me to be mechanism not intent.   This should be stated as
the intent if that is what it is.

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

Yes. Silly me.

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

There is no technical problem in Proposal B with VALUES for a current-row
variable that aren't shared with other uses of VALUES.  The syntactic
restriction removes marginally useful constructs like
SELECT * WHERE {
  VALUES ?a { ex:a ex:b }
  FILTER EXISTS { VALUES ?a { ex:a } } }
So no technical reason for the exclusion of some useful queries.

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

But VALUES isn't assignment.  SPARQL queries like
SELECT * WHERE {
  BIND ( ex:a AS ?a )
  VALUES ?a { ex:a ex:b } }
are allowed so I see the limitation on VALUES as harder to explain than not
having it.

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

This would be no different than any join that ends up with zero rows, such as
SELECT * WHERE {
 ?a ex:a ex:a .
 VALUES ?a { ex:b } }
against the graph ex:a ex:a ex:a .

[ second half split off]

peter

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

Received on Tuesday, 18 April 2017 17:56:54 UTC