Hi Andy! Thanks for confirming my suspicion.
I tried --engine=ref. With 3.0.1 the result doesn't change, i.e. ex:TypeA will still be used. With 3.0.0 the result changes into that as well. So the behavior is indeed caused by a perhaps inappropriate optimization in <3.0.1.
I will move the VALUES block inside GRAPH in all my queries for now. -Osma 03.02.2016, 18:09, Andy Seaborne kirjoitti:
Osma, Please try the reference query engine (add "--engine=ref" to the command line). It naively executes queries bottom up, with no optimization. At first look, ?type inside GRAPH is out of scope of the VALUES clause. So at: COALESCE(?type, ?defaulttype) ?type in undef The VALUE and GRAPH are joined after GRAPH is evaluated. (a reason I want to do JENA-1111 to do the expected ?var replaced by value everywhere regardless of scoping) Andy On 03/02/16 15:23, Osma Suominen wrote:Hi, I've run into a problem involving a SPARQL query that takes parameters as a VALUES block (from the skos-history project [1]). The query works differently in Jena 3.0.1+ than it used to. I believe this may be related to variable scoping fixes made as part of JENA-1018. The original query is quite complicated but I've made a minimal example which demonstrates the same issue. Use this data loaded into the graph <data.ttl>: @prefix ex: <http://example.org/>. ex:itemA a ex:TypeA . ex:itemB a ex:TypeB . And this query: PREFIX ex: <http://example.org/> SELECT * { VALUES (?graph ?type) { (<data.ttl> ex:TypeB) } GRAPH ?graph { BIND(ex:TypeA AS ?defaulttype) BIND(COALESCE(?type, ?defaulttype) AS ?realtype) ?item a ?realtype . } } The idea of the VALUES block is to specify parameters for the remaining query. In particular, the ?type parameter can be set to an explicit value (here ex:TypeB) or left undefined (using undef). If it is left undefined, then the default type (ex:TypeA) will be used instead. Here is the result using Jena 3.0.0: $ ~/sw/apache-jena-3.0.0/bin/sparql --namedGraph data.ttl --query test.rq ------------------------------------------------------------- | graph | type | defaulttype | realtype | item | ============================================================= | <data.ttl> | ex:TypeB | ex:TypeA | ex:TypeB | ex:itemB | ------------------------------------------------------------- But with Jena 3.0.1 (also current 3.1.0-SNAPSHOT): $ ~/sw/apache-jena-3.0.1/bin/sparql --namedGraph data.ttl --query test.rq ------------------------------------------------------------- | graph | type | defaulttype | realtype | item | ============================================================= | <data.ttl> | ex:TypeB | ex:TypeA | ex:TypeA | ex:itemA | ------------------------------------------------------------- So with 3.0.0 the query worked as intended, ex:TypeB was used to query the data. But with 3.0.1 the default type (ex:TypeA) will always be used. If I move the VALUES clause inside the GRAPH block then also Jena 3.0.1 will give the expected result, i.e. use ex:TypeB as ?realtype and return ex:itemB as ?item. Am I right that the original query relies on unspecified/wrong behavior (the variables defined in VALUES outside the GRAPH block should not be in scope inside the GRAPH block) and that the right solution is to move the VALUES block inside GRAPH? I want to double-check before making changes to a large number of queries that rely on this. Thanks, Osma [1] https://github.com/jneubert/skos-history
-- Osma Suominen D.Sc. (Tech), Information Systems Specialist National Library of Finland P.O. Box 26 (Kaikukatu 4) 00014 HELSINGIN YLIOPISTO Tel. +358 50 3199529 [email protected] http://www.nationallibrary.fi
