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)

Reply via email to