[
https://issues.apache.org/jira/browse/JENA-1130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15139127#comment-15139127
]
Andy Seaborne commented on JENA-1130:
-------------------------------------
Thank you for the details - that's a long and complicated query and I'm not
familiar enough with the details of the data model.
What is happening is that a bug fix around {{MINUS}} is causing the change.
The previous, wrong, execution executed in a similar fashion to {{FILTER NOT
EXISTS}}. Due to scoping in SPARQL, the {{?class}} from the first part is
actually a different {{?class}} in the {{MINUS}}.
In {{FILTER NOT EXISTS}}, it is the same {{?class}}.
Please could try {{FILTER NOT EXISTS}} and see if some of the results you want
appear. I get the same number of results with Jena 3.1.0 (dev) as with 3.0.0.
To experiment, a simple set up is to use in-memory execution and the command
line tools.
I made a combined dump of all the data in "D.nt" and ran:
{{sparql --data D.nt --query=<FILE>}}
There is also the "reference query engine" which is a very simple and very slow
execution of SPARQL queries. It is good for working with small sets of data to
check functionality. It is impractical for the data here but on a smaller set
may be useful. Add {{--engine=ref}} to the command line.
Let's separating out the performance issues (JENA-1121) from changes in results
(this JIRA) but one note: there are some costly operations like
{noformat}
?otherClass rdfs:subClassOf+ ?class .
?s rdfs:subClassOf* ?otherClass .
{noformat}
which generates a lot of possibilities. Reordering may help. There is an
optimization around {{+}} in the development version. {{*}} is expensive still
at the moment if both ends are unbound at the time of execution.
> 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)
