Uploaded image for project: 'Apache Jena'
  1. Apache Jena
  2. JENA-1130

Query returns different results with Fuseki 2.3.0 than with 2.3.1

    XMLWordPrintableJSON

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Not A Problem
    • Affects Version/s: Fuseki 2.3.1
    • Fix Version/s: None
    • Component/s: ARQ
    • Labels:
    • Environment:

      Mac OS X 10.11.2

      Description

      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 :

      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 .
              }
          }
      }
      

      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.

        Attachments

          Activity

            People

            • Assignee:
              andy Andy Seaborne
              Reporter:
              benjamingeer Benjamin Geer
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: