Re: Related comments

On 02/06/2017 02:21 AM, Andy Seaborne wrote:
> Peter has some comments on the SHACL comments list that relate to EXISTS. [1]
> 
>> There is no demonstration that the choice of fresh variables in the
>> definition of PrjMap(P,PV) is insignificant.
> 
> I hope we can explain in the document to clarify this, but I'm not clear what
> you are looking for.

That the result of the evaluation doesn't depend on the choice of free variables.

> What would constitute such a demonstration?

That's a good question.  When I first noticed this problem I was thinking that
this was just a t that hadn't been dotted, but I'm really not sure how to go
about showing that the choice doesn't matter.

> Do you have a example where it is significant?

No, at least not yet?  Do you have a demonstration that there are none?

>> The result of PrjMap(X) depends on the order in which the projections
>> in X are chosen, but this order is not specified.
> 
> Yes - it would be better to define the order and the outcome is order
> dependent with respect to replaced variables but does it make a difference? It
> is only variables restricted by scope that are changed.

The mappings reach down into sub-expressions and change disconnected variables
there so they violate the scoping of SPARQL.

> Do you have a case where it makes an observable difference?

NO, at least not yet.  Do you have a demonstration that there are none?

> Would a bottom-up replacement be suitable?

I think so.  If you fixed the free variables for all the mappings then I think
that a bottom-up replacement schedule would produce a unique result.  This
remains to be demonstrated but shouldn't be too hard. As well, none of the
mappings would affect disconnected variables, I think.

Of course, doing only this part doesn't solve the major problem.

>     Andy
> 
> [1] https://lists.w3.org/Archives/Public/public-rdf-shapes/2017Jan/0010.html

It seems so obvious that the choice of variables does not matter, but thinking
about how to demonstrate that this is so leads to lots of tricky bits.

peter

Received on Monday, 6 February 2017 11:49:34 UTC