[
https://issues.apache.org/jira/browse/JENA-1526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16440037#comment-16440037
]
Andy Seaborne commented on JENA-1526:
-------------------------------------
OPTIONAL extends the solutions of the pattern before it. It mattes where it
appears in query.
The inner select is the same as a plain VALUES clause.
In the first query, it is OPTIONAL on "?s a ns1:type." joined with the VALUES
where ?id is set to "ns1:799fdfc". There is no match (no leftjoin) because "{
?s ns1:sb ?run . ?run ns1:run_id ?id . }" matches with ?id ns1:29. You can see
this because ?run is not bound hence the OPTIONAL{} didn't extend the solutions
.
{noformat}
PREFIX ns1: <http://example.com/ns1#>
SELECT ?s ?run ?id
WHERE
{ ?s a ns1:type
VALUES ?id { ns1:799fdfc }
OPTIONAL
{ ?s ns1:sb ?run .
?run ns1:run_id ?id
}
}
{noformat}
In the second query, the left hand side of the OPTIONAL is "?s a ns1:type." --
the results after applying the OPTIONAL are joined to the result of the inner
SELECT. Try the query:
{noformat}
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
}
}
{noformat}
?id is bound to ns1:29. Joining that with "values ?id { ns1:799fdfc }" (bottom
up evaluation) has ?Id different on the two sides hence no match. This is a
join of the inner SELECT and the results after OPTIONAL in evaluated.
Try the algebra forms of your queries at
[http://sparql.org/query-validator.html]
{noformat}
PREFIX ns1: <http://example.com/ns1#>
SELECT ?s ?run ?id
WHERE {
?s a ns1:type_ .
values ?id { ns1:799fdfc }
OPTIONAL { ?s ns1:sb ?run .
?run ns1:run_id ?id . }
}
{noformat}
The left join is the outer whereas in:
{noformat}
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 . }
values ?id \{ ns1:799fdfc }
}
{noformat}
the outer operation is a "join".
> 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)
