[jira] [Commented] (JENA-1526) OPTIONAL clause filters out results when defined before inner SELECT

[Andy Seaborne (JIRA)]

    [ 
https://issues.apache.org/jira/browse/JENA-1526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16440055#comment-16440055
 ] 

Andy Seaborne commented on JENA-1526:
-------------------------------------

Try this simplification of the issue: the UNION is there to put in both cases:

{noformat}
SELECT * {
    {
      VALUES ?X { 1 }
      OPTIONAL { VALUES ?X { 2 } }
    }
    UNION
    {
      OPTIONAL { VALUES ?Y { 2 } }
      VALUES ?Y { 1 }
    }
}
{noformat}

Part 1:
{noformat}
    (leftjoin
      (table (vars ?X) (row [?X 1]))
      (table (vars ?X) (row [?X 2]))
{noformat}
and part 2:
{noformat}
    (join
      (leftjoin
        (table unit)   ## << because there was nothing written before the 
OPTIONAL
        (table (vars ?Y) (row [?Y 2]))
      )
      (table (vars ?Y)  (row [?Y 1]))
      ))
{noformat}

> 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: Question
>         Environment: apache-jena-fuseki-3.7.0
>            Reporter: Kevin Smyth
>            Priority: Major
>
> 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)