Re: EXISTS : ways forward

Hi Peter,

> My summary of Andy's proposed solutions is that it ends up forbidding too
> many useful constructs.  I think that it is better to come up with a
> definition for EXISTS that keeps these useful constructs.

>> **** Problem 2: Substitution happens where definitions are only for
>> variables
>>
>> Suggestion: identify and forbid pattens that involve the substitution of
>> certain constructs.
>>
>> BIND(... AS ?VAR)
>> SELECT (... AS ?VAR)
> SELECT ... ?VAR ...   <<<<<<<<<<<<<<<<  This one too??

Yes.

>> VALUES ?VAR
>> VALUES(...?VAR...)
>
> Presumably these would only be illegal if they are within, roughly, the
> connected scope of ?VAR as the proposal here restricts substitution is being
> restricted to, roughly, the connected scope.

Yes.

>> This can be a static or dynamic test - I prefer a static check which is
>> done once after parsing (there are already such checks - e.g. "AS ?VAR"
>> the ?VAR must not be an in-scope variable from the expression or pattern).
>
> My view is that if there is a good way of retaining either a reasonable
> meaning or what is generally implemented then that should be the goal
> instead of forbidding constructs.  So the useful construction (well useful
> if there is an initial query instead of a VALUES)
> SELECT ?book WHERE {
>   VALUES ?book { :book1 :book2 }
>   FILTER EXISTS {
>     VALUES ?book { :book2 } } }
> should produce :book2 and not be illegal.

I'm not seeing a use case for this way of writing it when there is 
FILTER such as FILTER(?book IN ( .... ))?

VALUES can be a number of tuples, and include UNDEF as a possible 
setting.  These other forms make it more complicated so in the tradeoff 
of complexity for a few more possible forms, I think there is merit in a 
clear, simple solution.

>
> Similarly
>   SELECT ?a WHERE {
>     ?a :b :c .
>     FILTER EXISTS {
>       SELECT (?a1 AS ?a) WHERE {
>         ?a1 :b :d } } }
> should be legal, and produce those nodes that are linked via :b to both
> :c and :d, and so should
>   SELECT ?a WHERE {
>     ?a :b :c .
>     FILTER EXISTS {
>       SELECT ?a WHERE {
>         ?a :b :d } } }
>
> This meaning for EXISTS makes BIND illegal due to scope violation, but I
> don't see a way to save BIND and still keep the (silly) rule that BIND has
> to introduce a new variable.
>
>> With BOUND, the issue is more about syntax.  We can define
>> "BOUND(someValue)" to have a replacement of "true"^^xsd:boolean in the
>> algebra.
>
> This would be an improvment for BOUND, I guess.
>
>
>> **** Problem 3: Blank nodes substituted into BGPs act as variables
>>
>> The core issue is to treat bnodes from the data (pre-binds) differently
>> from bnodes from the surface syntax.
>>
>> The scoping graph includes all blank nodes passed in to pre-binding.
>>
>> { ?s ?p ?o } => { ?s ?p ?o' . FILTER (sameterm(?o', _:b))  }
>>
>> while it is written in syntax above, the process happens in the
>> algebra and in the algebra, blank nodes are concrete terms so it is
>> meaningful to talk about them in filters etc. They do not behave like
>> variables except in basic graph patterns.
>
>> We can explain that this is the same as (implementation, simple
>> entailment) treating only blank nodes in the original query, i.e. at he
>> time of parsing, as BGP variables and then treating substitution blank
>> nodes as constant terms.
>>
>> { ?s ?p _:b  } where _:b is matched concretely, not as a variable.
>
> This seems rather complex and is only for blank nodes.

The explanation as rewrite helps implementers - it is true for IRIs and 
literals too.

<snip/>

>
> Another way of proceeding, which I have advocated before, is to replace the
> substitution definition for EXISTS with one based on setting up initial
> solution sequences, i.e., the algebra equivalent of putting a generalized
> VALUES at the front of the EXISTS argument, So
>   VALUES ?book { :book1 :book2 }
>   FILTER EXISTS {
>     VALUES ?book { :book2 } }
> would evaluate the analogue of
>   VALUES ?book { :book1 :book2 }
>   VALUES ?book { :book2 }
> for the EXISTS.  Scoping would be augmented so that the  variables would be
> in-scope at the beginning of the
> EXISTS argument.
>
> This does what I consider to be the right thing in all cases that a right
> thing can be determined.  It also doesn't need any special cases nor does it
> need the extended definition for BOUND.  It also doesn't directly depend on
> scoping.

I'm not clear what the proposal is - is it to put a VALUES block next to 
every BGP?  That is quite similar to FILTER(sameTerm) at the each point 
of BGP evaluation.

 Andy

>
> This solution has the benefit that EXISTS subsitution doesn't cause
> flipping of MINUS.  It does, of course, change how EXISTS interacts with
> MINUS.
>
>
> peter
>

Received on Wednesday, 21 September 2016 15:07:40 UTC