On 01/11/16 22:40, james anderson wrote:
good evening;
On 2016-11-01, at 20:12, Andy Seaborne <[email protected]> wrote:
On 01/11/16 12:38, Osma Suominen wrote:
Hi,
[about a query which exercises the interaction between a values clause and
statement pattern at locations relatively remote in the query. ]
[ the question leads to a point about the scope of the respective ?uri
variables, ]
The issue is [*], using the variable ?uri again inside an OPTIONAL.
It is possible that ?uri will range over more than the VALUES setting and
affect the OPTIONAL yet the inner EXISTS usage does not set ?uri and it is not
propagated to be joined with the set value.
[…]
[ … and to one about algebraic equivalence among expressions and the consequent
latitude to relocate the values clause.]
It can be pushed in because:
join(A, union(B,C)) == union(join(A,B), join(A,C))
now if A is an complex expression, that is a bad idea (probably).
If A is a small VALUES block then it makes sense. It isn't done though.
both of which are significant, but remain side matters to the principal issue,
which concerns a reasonable expectation - despite that it may be subject to
revision, that the values clause introduces bindings with indefinite scope.[1]
The performance issue is that
{ P1 OPTIONAL{P2} VALUES } != { VALUES P1 OPTIONAL{P2} }
but is instead:
{ P1 OPTIONAL{P2} VALUES } == { VALUES...{} { P1 OPTIONAL{P2} } }
but in this data it gets the same answers (presumably) and rather faster.
This is not really about EXISTS at all. Other {P} will have the same
effect.
The programming notion of scope is only an analogy for query languages.
In a query language, same scope means same reference - ie. equivalence.
"Same scope" in a query language means equality-inner-join at some later
point to test they are the same value. Equating variables from
sub-pattern evaluation is like SQL "natural join".
The optimizer is finding situations when equality can be executed as
equivalence (c.f. index join).
In ARQ execution, variables are transformed by renaming apart early in
optimization making static scoping a non-issue for the rule based
optimizations.
Andy
as sparql plays in increasingly significant role in service implementations,
library-level support for query parameters[2] needs to give way to
protocol-level mechanisms,[3] whereby the language semantics needs more
attention than it has yet received.
both immediately federated request combinations and request chains which are
mediated by a third service need to propagate intermediate solution sets
across requests.
the use case behind this question is one example.
the implementations for elementary variables[3] do not provide sufficient
capacity - not to mention the deficiencies of their substitution models.
the sparql federated query recommendation suggests a role which the values
clause might play,[4] but does not provide an exact interpretation.
has jena’s community given this topic any thought?
best regards, from berlin,
- - -
[1] :
http://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node43.html#SECTION00700000000000000000
[2] :
https://jena.apache.org/documentation/query/parameterized-sparql-strings.html
[3] : http://docs.rdf4j.org/rest-api/#_repository_queries
[4] : http://www.w3.org/TR/sparql11-federated-query/#values
---
james anderson | [email protected] | http://dydra.com
