Re: competing goals for EXISTS solutoins

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.

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

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

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

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

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

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

Received on Monday, 27 March 2017 21:05:48 UTC