Kevin Smyth created JENA-1526:
---------------------------------
Summary: OPTIONAL clause filters out results when defined before
inner SELECT
Key: JENA-1526
URL: https://issues.apache.org/jira/browse/JENA-1526
Project: Apache Jena
Issue Type: Bug
Environment: apache-jena-fuseki-3.7.0
Reporter: Kevin Smyth
Given this dataset
{code:java}
@prefix ns1: <http://example.com/ns1#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
<ns1://Example#R1>
a ns1:type_ ;
ns1:sb <http://example.com/#Mass_29> .
<http://example.com/#Mass_29>
ns1:satisfies <ns1://Example#R1> ;
ns1:run_id ns1:29 .
ns1:29 a ns1:run ;
ns1:time "2018-04-12T19:43:14.702"^^xsd:dateTime .
ns1:799fdfc a ns1:run ;
ns1:time "2018-04-13T16:55:47-05:00"^^xsd:dateTime .
{code}
This query:
{code:java}
PREFIX ns1: <http://example.com/ns1#>
SELECT ?s ?run ?id
WHERE {
?s a ns1:type_ .
{
SELECT ?id
WHERE {
values ?id { ns1:799fdfc }
} LIMIT 1
}
OPTIONAL {
?s ns1:sb ?run .
?run ns1:run_id ?id .
}
}
{code}
produces 1 result, whereas switching the inner SELECT and OPTIONAL:
{code:java}
PREFIX ns1: <http://example.com/ns1#>
SELECT ?s ?run ?id
WHERE {
?s a ns1:type_ .
OPTIONAL { ?s ns1:sb ?run .
?run ns1:run_id ?id . }
{
SELECT ?id
WHERE {
values ?id { ns1:799fdfc }
} LIMIT 1
}
}{code}
produces no results.
The spec specifies "In an optional match, either the optional graph pattern
matches a graph, thereby defining and adding bindings to one or more solutions,
or it leaves a solution unchanged without adding any additional bindings." and
"Due to the bottom-up nature of SPARQL query evaluation, the subqueries are
evaluated logically first, and the results are projected up to the outer
query.", so I don't see how this is the correct behavior.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
