Re: EXISTS : ways forward

On 09/23/2016 03:58 AM, Andy Seaborne wrote:
> 
> 
> On 22/09/16 17:12, Peter F. Patel-Schneider wrote:
>> On 09/22/2016 04:46 AM, Andy Seaborne wrote:
> 
> 
>>> That is quite serious for SHACL usage.
>>
>> This is not correct. Some current SPARQL implementations of SHACL
>> mayhave to
>> change.
> 
> It affects SHACL core constraints because they have SPARQL definitions.

So maybe some SPARQL queries and some text may have to change in a working
draft.  That's insignificant.

>> If pre-binding in SHACL uses this method, then the meaning
>> of pre-binding will change. Neither of these are serious at all.
> 
> SHACL uses UNION, OPTIONAL and others to build up SPARQL queries. If the
> restriction on values for the current row (FILTER EXISTS) is applied only at
> the top, this composition will not work. It is not necessary to break that.

Not correct.  Most of these will still work with no changes.  For example,

SELECT $this
WHERE {
 OPTIONAL {
  $this $PATH ?value .
 }
}
GROUP BY $this
HAVING (COUNT(?value) < $minCount)

works without change.  Well, it really works without change because there is
no EXISTS in it, but it works without change even if pre-binding is done via
top-level binding injection.

The SPARQL query for sh:uniqueLang does need to change if pre-binding is done
via top-level binding injection.  But the EXISTS doesn't need to change.

As far as I can tell, no specification of a core SHACL constraint component
needs to change if EXISTS is defined via top-level binding injection.


>>> What substitution (and where it differs from correlated subquery) does is
>>> replace, so loosing the binding, which is one of its problems.
>>
>> I don't understand this.  Could you expand it?
> 
> Binding: ?x = <x>
> { ?x :p ?o }
> 
> By substitution:
> { <x> :p ?o }
> which has no ?x binding in the solution mappings and FILTERS needs substitution.
> 
> By VALUES at the point of use:
> { <x> :p ?o }
> =>
> { ?x :p ?o . VALUES ?x { <x> } }
> 
> which does have ?x binding in the solution mappings and FILTERS don't need
> substitution and "AS ?x" cases work out naturally in a way that can be
> statically checked.
> 
> In terms of implementation effort, the logical injection of VALUES at these
> points is a bit simpler than substitution (of in-scope) variables because
> expressions do not need to be rewritten.
> 
> It is amenable to optimization.

Yes, agreed.  Binding injection is better than substitution.  The question is
whether to do it just at top-level or throughout for some definition of
throughout.

[..]

peter

Received on Friday, 23 September 2016 18:50:37 UTC