[
https://issues.apache.org/jira/browse/JENA-502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13733298#comment-13733298
]
Andy Seaborne commented on JENA-502:
------------------------------------
Barry - thank you for a complete and clear report. Much appreciated. It is a
bug in ARQ.
Here is a test case with a simpler query:
{noformat}
PREFIX : <http://example.com/>
SELECT ?s
WHERE
{ SELECT ?s
WHERE
{ ?s :p1 ?obj
VALUES ?obj { :o1 }
}
}
{noformat}
is being turned into the (mis-)optimized algebra
{noformat}
(prefix ((: <http://example.com/>))
(project (?s)
(project (?s)
(sequence
(table (vars ?obj)
(row [?obj :o1])
)
(bgp (triple ?s :p1 ?/obj))))))
{noformat}
which is wrong because there is an inconsistent rename of {{?obj}} to
{{?/obj}}. Either both {{?obj}} variables should be rename to {{?/obj}} or, in
this case, the rename is unnecessary, so not changed.
It's the nesting of projections - if the first query is changed so the outer
{{SELECT ?s}} is {{SELECT *}} (which is not a projection), the rename error
goes away.
When you had {{SELECT ?s ?obj}} the inner {{?obj}}'s don't get renamed.
Renaming happen to hide variables not exposed by the {{SELECT}}.
> VALUES keyword in subquery ignored in some cases.
> -------------------------------------------------
>
> Key: JENA-502
> URL: https://issues.apache.org/jira/browse/JENA-502
> Project: Apache Jena
> Issue Type: Bug
> Components: Fuseki
> Affects Versions: Fuseki 0.2.7, Fuseki 0.2.8
> Environment: Ubuntu 13.04 x64
> OpenJDK Runtime Environment (IcedTea 2.3.10) (7u25-2.3.10-1ubuntu0.13.04.2)
> Reporter: Barry Coughlan
>
> Given the following data set in the graph "http://test.com":
> {code:title=data.ttl}
> @prefix : <http://example.com/>
> :s1 :type :thing .
> :s1 :p1 :o1 .
> :s2 :type :thing .
> :s2 :p1 :o1, :o2 .
> :s3 :type :thing .
> :s3 :p1 :o2 .
> {code}
> {code}s-put http://localhost:3030/ds/data http://test.com data.ttl{code}
> Suppose, as part of a subquery, we want to find all subjects that have (:p1
> :o1):
> {code}
> PREFIX : <http://example.com/>
> SELECT *
> WHERE {
> SELECT DISTINCT ?s WHERE {
> GRAPH <http://test.com> {
> ?s :p1 ?obj .
> VALUES ?obj { :o1 }
> }
> }
> }
> {code}
> This returns the expected result (?s={:s1, :s2}). However when the GRAPH
> statement is outside the subquery:
> {code}
> PREFIX : <http://example.com/>
> SELECT *
> WHERE {
> GRAPH <http://test.com> {
> SELECT DISTINCT ?s WHERE {
> ?s :p1 ?obj .
> VALUES ?obj { :o1 }
> }
> }
> }
> {code}
> this returns ?s={:p1, :p2, :p3} - the VALUES block is ignored by the query,
> and removing the VALUES block gives the same result.
> Going back to the first query, let's try to select all triples with subjects
> restricted by the subquery:
> {code}
> PREFIX : <http://example.com/>
> SELECT ?s ?p ?o
> WHERE {
> {SELECT DISTINCT ?s WHERE {
> GRAPH <http://test.com> {
> ?s :p1 ?obj .
>
> VALUES ?obj { :o1 }
> }
> }}
> GRAPH <http://test.com> { ?s ?p ?o }
> }
> {code}
> I expected the subquery to restrict ?s to {:s1, :s2} and the triple at the
> bottom to select all triples with that subject. This behaviour works as
> expected in OpenRDF Sesame. However, once again the VALUES keyword is ignored
> and the following output is observed:
> {code}
> s p o
> :s1 :type :thing
> :s1 :p1 :o1
> :s2 :type :thing
> :s2 :p1 :o1
> :s2 :p1 :o2
> :s3 :type :thing
> :s3 :p1 :o2
> {code}
> I have tried this with other triples in the subquery, and the behaviour is as
> expected. It seems to be variables restricted with the VALUES keyword that
> misbehave.
> Another curiousity I found while trying to find a workaround. If I add the
> VALUES variable to the SELECT, changing the line {code}{SELECT DISTINCT ?s
> WHERE {{code} to {code}{SELECT DISTINCT ?s ?obj WHERE {{code} then I get the
> expected result of only :s1 and :s2 being selected. However, this is not
> suitable as a workaround because if there is more than one value in the
> VALUES block, there will be duplicate values for ?s.
> Sorry for the long bug report, I'm not exactly sure of what the problem is so
> thought I would give as much detail as possible. I discovered this first on
> 0.2.7 but ran most of these tests on the 0.2.8 build from
> jena-fuseki-0.2.8-20130804.075208-67-distribution.tar.gz.
> Regards,
> Barry
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
