Re: competing goals for EXISTS solutoins

On 03/27/2017 02:05 PM, Andy Seaborne wrote:
>
> On 25/03/17 18:14, Peter F. Patel-Schneider wrote:
>> I see multiple goals for a solution for EXISTS.
>
> Interesting list. I think these are mostly ideals, not necessarily absolute
> requirements.

That's why I've labelled them goals, not requirements.

>> 1/ The solution should be well-defined, e.g., no operation should be
>> invoked outside of its defined domain.
>
> All evaluation should be well defined.

This one is perhaps the only absolute requirement of the entire bunch.  It
can't be the case any more that evaluating some syntactically legal query
ends up with an unplanned undefined result.

>> 2/ The solution should be defined on all SPARQL queries that are currently
>> syntactically legal.
>
> I'm not clear here - both A and B need to restrict syntactically legal current
> queries. The current spec places no syntactic restrictions so attempts at
> reassignment are possible.

It is not possible, I think, to make all the currently syntactically legal
queries remain syntactically legal.  However, I think that as many as
possible should remain legal.

For example
  SELECT ?a WHERE { VALUES ?a { ex:a ex:b }
    FILTER EXISTS { BIND ( ex:a AS ?a ) } }
can't remain legal.

However,
  SELECT ?a WHERE { VALUES ?a { ex:a ex:b }
    FILTER EXISTS { VALUES ?a { ex:a } } }
should remain legal, as should
  SELECT ?a WHERE { VALUES ?a { ex:a ex:b }
    FILTER EXISTS { SELECT ( ex:a AS ?a ) WHERE { } } }
and
  SELECT ?a WHERE { VALUES ?a { ex:a ex:b }
    FILTER EXISTS { SELECT ?b WHERE { BIND ( ex:a AS ?a ) } } }
and even
  SELECT ?a WHERE { VALUES ?a { ex:a ex:b }
    FILTER EXISTS { SELECT ?a WHERE { BIND ( ex:a AS ?a ) } } }

>> 3/ The solution should be simple, i.e., no complex extra machinery.
>
> I see this as a desirable attribute but not necessary. There are various
> possible related desirable aspects like no redundancy, minimising the areas of
> changes that
>
> "Simple as possible but no simpler"
>
> The machinery is used elsewhere, or maybe used - for example, SQL correlated
> subquery is in the EXISTS space but also does other FILTER cases.
>
> https://en.wikipedia.org/wiki/Correlated_subquery
>
> For me, a bad outcome is a simple solution here, and a different solution
> elsewhere that is similar but different if they did not need to be different.
> One mechanism, not point-wise solutions to each area.

>> 4/ The solution should conform to the notions defined for the SPARQL syntax and
>> the SPARQL algebra, e.g., variable scope should matter.
>
> Yes.  The question is what is "should matter" etc.!

Yes, what matters is to be determined.  I would say that variable scope
should be a SPARQL notion that matters, i.e., the evaluation of the subquery
in
  SELECT ?a WHERE { VALUES ?a { ex:a ex:b }
    FILTER EXISTS { SELECT ?b WHERE { ... } } }
should not depend on the values of the variables in scope at the FILTER.
This would also apply for
  SELECT ?a WHERE { VALUES ?a { ex:a ex:b }
    FILTER EXISTS { SELECT (... AS ?a) WHERE { ... } } }

>> 5/ The solution should conform to the non-normative desires epressed in the
>> SPARQL document, e.g., bottom-up evaultion of sub-queries should be
>> possible.
>
> I'm a bit unclear on the intent. A FILTER is an expression applied to the
> current row. Optimization may mean it does not need to be executed on each
> row, just like SQL correlated subquery.  There is lots of related work.
>
> For example, if the used variables don't change, from row to row, a previous
> result can be reused.
>
> Of course all evaluation should be as per normal SPARQL.

I think that bottom-up subquery evaluation is one notion that fits here.
>From this, the evaluation of the subquery in
  SELECT ?a WHERE { VALUES ?a { ex:a ex:b }
    FILTER EXISTS { SELECT ?a WHERE { ... } } }
would not depend on the values of the variables in scope at the FILTER.

>> 6/ The solution should conform to what SPARQL implementations do.
>
> I would express that as a desire to not unnecessarily change what current
> implements do. We know there is not complete uniformity so some change to some
> implementations is inevitable.
>
> The identified issues include things we do seem to agree are not right (e.g.
> Issue 2: Substitution happens where definitions are only for variables) so
> some change is inevitable if the execute now is well defined.

Yes, there is already divergence between implementations so it is not
possible to conform to all implementations.  I would say that it can be
acceptable to diverge from current implementations to achieve some other
goal.

>> All of the above goals are problematic except perhaps the first.  They can't
>> all be satisfied at the same time.  Some of them can't even be satisfied
>> individually.
>>
>> I don't see consensus on which of these goals are more important than the
>> others.
>>
>> Peter F. Patel-Schneider
>> Nuance Communications
>>
>
>     Andy

peter

Received on Tuesday, 28 March 2017 17:51:26 UTC