You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jena.apache.org by Osma Suominen <os...@helsinki.fi> on 2016/02/03 16:23:10 UTC
VALUES block scope in Jena 3.0.1+
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
osma.suominen@helsinki.fi
http://www.nationallibrary.fi
Re: VALUES block scope in Jena 3.0.1+
Posted by Osma Suominen <os...@helsinki.fi>.
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
osma.suominen@helsinki.fi
http://www.nationallibrary.fi
Re: VALUES block scope in Jena 3.0.1+
Posted by Andy Seaborne <an...@apache.org>.
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
>
>