Re: Related comments

On 22/02/17 20:27, Peter F. Patel-Schneider wrote:
> All I am asking for is a real demonstration that inserting fresh variables is
> a benign operation and that the choice of which fresh variable to use is not
> significant.  I view this demonstration as necessary for this proposal.

I have said I will add text to explain the process - I haven't had time 
to do that yet.  I don't know what proof would satisfy you, particularly 
what can be assumed to be already known, and I don't want to write one 
only to have it rejected completely.

> As
> the results of a SPARQL query do depend on the variable names in it, the
> demonstration is going to be different from the standard demonstration that
> renaming variables in a regular programming language does not change the
> result of a program.

In this thread we have that:

* The text for replacement needs to say that fresh variables are unique 
through later replacements as well

* The replacement process should be done bottom-up

* The name of a variable is not accessible to expressions. [1]

* Replacing a variable happens in only 4 places [2].
   The name makes the name in the solutions change.

So a name change of a variable affects the solutions as a rename (c.f. 
relational algebra rename operation).

When applied to a projection, renaming unprojected variables is not 
observable.

> This is not my proposal.  I view it as inferior partly because it does depend
> on this demonstration.  I also view it as inferior as it does not meet the
> goal of not changing the meaning of SPARQL queries that are completely
> unproblematic with the current definition of EXISTS.  For example, it
> introduces a shared variable to both sides of MINUS constructs, potentially
> changing their meaning.

Both proposals make changes around MINUS from what the SPARQL 1.1 spec 
defines - this is issue 4.

Proposal-A changes GRAPH, UNION (and MINUS) queries [3] so that existing 
EXISTS uses are changed. This is addressed by proposal-B by making the 
current row available throughout the EXISTS pattern evaluation.

     Andy


>
> I am not willing to further help with this proposal.
>
> Peter F. Patel-Schneider
> Nuance Communications

Received on Sunday, 26 February 2017 16:30:10 UTC