[
https://issues.apache.org/jira/browse/JENA-1021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14733965#comment-14733965
]
Andy Seaborne edited comment on JENA-1021 at 9/7/15 6:14 PM:
-------------------------------------------------------------
Analysis:
The root cause is that the join classifier is choosing to use the unscoped
index joins (the preferred strategy). But this at odds with {{MINUS}} which
has an implicit negation in it. Normally, when the {{MINUS}} is a the top level
of a {}-group, this is detected and handled appropriately (hence JENA-266). The
join classifier has a special case for one side of a join being an {{OpMinus}}.
But in this case, the {{OpMinus}} is inside a {{union}} and is missed. The
union executes by substitution and the {{OpMinus}} does not work correctly.
You can't do unthinking substitution execution in the presence of a pattern
negation.
One solution is to do a non-substitution execution. See JENA-1023 for
improvements in that area but JENA-1023 (performance improement) should not
block a fix for this JIRA.
was (Author: andy.seaborne):
Analysis:
The root cause is that the join classifier is choosing to use the unscoped
index joins (the preferred strategy). But this at odds with {{MINUS}} which
has an implicit negation in it. Normally, when the {{MINUS}} is a the top level
of a {}-group, this is detected and handled appropriately (hence JENA-266). The
join classifier has a special case for one side of a join being an {{OpMinus}}.
But in this case, the {{OpMinus}} is inside a {{union}} and is missed. The
union executes by substitution and the {{OpMinus}} does not work correctly.
You can't do unthinking substitution execution in the presence of a pattern
negation.
> Odd MINUS behavior in a UNION
> -----------------------------
>
> Key: JENA-1021
> URL: https://issues.apache.org/jira/browse/JENA-1021
> Project: Apache Jena
> Issue Type: Bug
> Components: Jena
> Affects Versions: Jena 3.0.0
> Reporter: William Tritchler
>
> Given the sample data:
> {code}
> @prefix owl: <http://www.w3.org/2002/07/owl#>
> @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
> @prefix : <http://no.such.org/test#> .
> <urn:test:node1>
> a :TestNode ;
> rdfs:label "Node 1" .
> <urn:test:node2>
> a :TestNode ;
> rdfs:label "Node 2" .
> :TestNode
> a owl:Class ;
> rdfs:label "Test Node" .
> {code}
> When I run the union query:
> {code}
> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
> PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
> PREFIX app: <http://no.such.org/test#>
>
> select distinct ?id where {
> ?id a app:TestNode .
> {
> ?id rdfs:label "Node 1" .
> minus { ?id a app:TestNode }
> } union {
> ?id rdfs:label "Node 1" .
> minus { ?id a app:TestNode }
> }
> }
> {code}
> *Observed:*
> The query unexpectedly returns a single value: <urn:test:node1>
> *Expected:*
> The query should return no results.
> Unless, of course, I'm totally off-base here. I suspect an issue, since
> removing the union and having a single:
> {code}
> {
> ?id rdfs:label "Node 1" .
> minus { ?id a app:TestNode }
> }
> {code} returns the expected empty result set.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
