[
https://issues.apache.org/jira/browse/JENA-1130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15139325#comment-15139325
]
Benjamin Geer commented on JENA-1130:
-------------------------------------
bq. Due to scoping in SPARQL, the {{?class}} from the first part is actually a
different {{?class}} in the {{MINUS}}.
Scoping in SPARQL has been a source of a lot of confusion for us. Different
triplestores (and, as in this case, different versions of the same triplestore)
seem to have different scoping rules, and it's been difficult for us to figure
out what the correct scoping rules actually are. If I understand correctly, in
the SPARQL 1.1 spec, [Section 18.2.1 Variable
Scope|https://www.w3.org/TR/sparql11-query/#variableScope] deals only with the
projection of variables from an inner scope to an outer scope, not the reverse,
which is the issue here. Also, it says "Let P, P1, P2 be graph patterns and E,
E1,...En be expressions", but there is no "E, E1,...En" in the table underneath.
In this case, why isn't {{?class}} from the outer scope in scope in the
{{MINUS}}? Is there no way to get it to be in scope there?
Does this mean that {{?s}} (which is set by {{BIND}}) isn't in scope in the
{{MINUS}}, either? If so, why? If not, why not?
More generally, why aren't all bound variables from outer scopes always in
scope in inner scopes (up to any level of nesting), as in many programming
languages?
If I change {{MINUS}} to {{FILTER NOT EXISTS}} as you suggest, the query does
indeed produce correct results with Fuseki 2.3.1 (and with Fuseki 2.3.0).
However, the version with {{MINUS}} works in Ontotext GraphDB 6.6.2 exactly as
in Fuseki 2.3.0. With {{FILTER NOT EXISTS}}, GraphDB gives exactly the same
(unwanted) results that Fuseki 2.3.1 gives with {{MINUS}}. So here we have
three different implementations (two versions of Fuseki and one of GraphDB),
giving three different interpretations of the spec. We wonder if this means
that something needs clarification in the spec, and whether it would be a good
idea for the Jena and GraphDB developers to talk it over amongst themselves and
agree on a solution. Our application is supposed to work with different
triplestores, and we would really rather avoid having to produce different
SPARQL to match each triplestore's interpretation of the spec.
> Query returns correct results with Fuseki 2.3.0 but not with 2.3.1
> ------------------------------------------------------------------
>
> Key: JENA-1130
> URL: https://issues.apache.org/jira/browse/JENA-1130
> Project: Apache Jena
> Issue Type: Bug
> Components: ARQ
> Affects Versions: Fuseki 2.3.1
> Environment: Mac OS X 10.11.2
> Reporter: Benjamin Geer
> Labels: owl, sparql
>
> Here is a query that we think is returning correct results with Fuseki 2.3.0
> but not with Fuseki 2.3.1.
> Steps to reproduce:
> 1. Download and unpack this archive:
> https://dl.dropboxusercontent.com/u/99857297/fuseki-incorrect-query-results.tar.gz
> 2. Copy the contents of the resulting directory,
> {{fuseki-incorrect-query-results}}, into the {{apache-jena-fuseki-2.3.0}}
> directory created by unpacking the Fuseki 2.3.0 distribution.
> 3. Start Fuseki with {{./fuseki-server}}, then run the script
> {{./fuseki-load-test-data.sh}}.
> 4. Run this query in the Fuseki web app at
> http://localhost:3030/dataset.html?tab=query&ds=/knora-test :
> {noformat}
> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
> PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
> PREFIX owl: <http://www.w3.org/2002/07/owl#>
> PREFIX knora-base: <http://www.knora.org/ontology/knora-base#>
> SELECT ?s ?p ?o ?oProp ?oVal ?lang ?isCardinality ?isKnoraValueProp
> ?isLinkProp ?isLinkValueProp ?isFileValueProp
> WHERE {
> BIND(IRI("http://www.knora.org/ontology/incunabula#page";) as ?s)
> ?s rdfs:subClassOf* ?class .
> ?class ?p ?o .
> OPTIONAL {
> ?o rdf:type ?oType .
> }
> FILTER((?class = ?s) || (?p = rdfs:subClassOf && ?oType =
> owl:Restriction))
> BIND(lang(?o) as ?lang)
> OPTIONAL {
> ?o a owl:Restriction .
> ?o owl:onProperty ?cardinalityProp .
> ?o ?oProp ?oVal .
> BIND(true as ?isCardinality)
> OPTIONAL {
> ?cardinalityProp rdfs:subPropertyOf+ knora-base:hasValue .
> BIND(true as ?isKnoraValueProp)
> }
> OPTIONAL {
> ?cardinalityProp rdfs:subPropertyOf* knora-base:hasLinkTo .
> BIND(true as ?isLinkProp)
> }
> OPTIONAL {
> ?cardinalityProp rdfs:subPropertyOf* knora-base:hasLinkToValue .
> BIND(true as ?isLinkValueProp)
> }
> OPTIONAL {
> ?cardinalityProp rdfs:subPropertyOf* knora-base:hasFileValue .
> BIND(true as ?isFileValueProp)
> }
> MINUS {
> ?otherClass rdfs:subClassOf+ ?class .
> ?s rdfs:subClassOf* ?otherClass .
> ?otherClass rdfs:subClassOf ?otherRestriction .
> ?otherRestriction a owl:Restriction .
> ?otherRestriction owl:onProperty ?otherProperty .
> ?otherProperty rdfs:subPropertyOf* ?cardinalityProp .
> }
> }
> }
> {noformat}
> You should get 85 entries, including many containing {{true}} in one or more
> of the columns {{isCardinality}}, {{isKnoraValueProp}}, {{isLinkProp}}, and
> {{isLinkValueProp}}. The query should execute in about 500 ms.
> 5. Stop the Fuseki server, and repeat steps 2-4 using the Fuseki 2.3.1
> distribution. You should get only 41 entries, none of which contain {{true}}
> in any of the columns {{isCardinality}}, {{isKnoraValueProp}},
> {{isLinkProp}}, or {{isLinkValueProp}}. The query is also much slower with
> Fuseki 2.3.1 (4.5 seconds).
> What this query is intended to do:
> The query gets information about an OWL class, in this example
> {{incunabula:page}}. It returns all predicates and objects of that class, all
> its cardinalities, and all the cardinalities of its superclasses. The idea
> here is that we treat an OWL class as inheriting the cardinalities of its
> superclasses.
> The nested {{OPTIONAL}} clauses that {{BIND}} boolean values are intended to
> flag cardinalities on certain types of properties that the application needs
> to handle in different ways.
> The {{MINUS}} clause allows a subclass to override a cardinality in a
> superclass. For example:
> * {{knora-base:Representation}} has a cardinality for
> {{knora-base:hasFileValue}}.
> * {{knora-base:StillImageRepresentation}} is a subclass of
> {{knora-base:Representation}} and has a cardinality for
> {{knora-base:hasStillImageFileValue}}, which is a subproperty of
> {{knora-base:hasFileValue}}.
> * {{incunabula:page}} is a subclass of
> {{knora-base:StillImageRepresentation}}.
> * Therefore, the cardinalities returned for {{incunabula:page}} should
> include {{knora-base:hasStillImageFileValue}}, but not
> {{knora-base:hasFileValue}}.
> This is implemented in the {{MINUS}} clause as follows: we were given {{?s}}
> ({{incunabula:page}}), and we are looking at one of its superclasses
> {{?class}} ({{knora-base:Representation}}). We find that {{?class}} has some
> {{?cardinalityProp}} ({{knora-base:hasFileValue}}). We then find that there
> exists {{?otherClass}} ({{knora-base:StillImageRepresentation}}), located
> somewhere between {{?s}} and {{?class}} in the class hierarchy, and that it
> has a cardinality for {{?otherProperty}}
> ({{knora-base:hasStillImageFileValue}}), which is a subproperty of
> {{?cardinalityProp}}. Therefore we exclude the cardinality on
> {{?cardinalityProp}} from the results.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
