Upgrade the built-in Fuseki to version 2.4.0

[benjamingeer]

This upgrades the built-in Fuseki server to version 2.4.0.

I found that three of our SPARQL queries were too slow on Fuseki unless I replaced MINUS with FILTER NOT EXISTS. This issue suggests that previous versions of Fuseki were able to optimise MINUS better than more recent versions, and that FILTER NOT EXISTS can more efficiently replace MINUS in some cases. However, FILTER NOT EXISTS didn't produce the same results in these queries on GraphDB. This is probably related to this issue, which seems to suggest that these two triplestores don't interpret SPARQL scoping rules in quite the same way. As a workaround, I added some if statements to the SPARQL templates in these cases, to use MINUS on GraphDB and FILTER NOT EXISTS on Fuseki. I think this is OK for now. We can revisit it later when we have more time.

I also got a NullPointerException from Fuseki when running one of the search responder tests. It seems to be caused by this bug. The advice there is to add a workaround to the definition of :tdb_dataset_readwrite in the repository configuration:

                        # Fuseki 2.4.0 only - remove for later versions.
                        ja:context [ ja:cxtName "arq:optFilterPlacementBGP" ;
                                     ja:cxtValue "true" ] .

With these workarounds, the tests pass, and performance looks good.

Closes #29.

[tobiasschweizer]

I am pretty sure you already know this information. Nevertheless I bring it up here: https://www.w3.org/TR/sparql11-query/#neg-example-1

Could hat explain the different behaviour?

If I do these queries in Fuseki, I get either all the resources or none of them.

This returns all the resources:

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 xsd: <http://www.w3.org/2001/XMLSchema#>
PREFIX knora-base: <http://www.knora.org/ontology/knora-base#>

SELECT * WHERE {

  ?resClass rdfs:subClassOf+ knora-base:Resource .
  ?resource a ?resClass .

  MINUS {
    ?s ?p ?o .
  }

}

This returns no results:

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 xsd: <http://www.w3.org/2001/XMLSchema#>
PREFIX knora-base: <http://www.knora.org/ontology/knora-base#>

SELECT * WHERE {

  ?resClass rdfs:subClassOf+ knora-base:Resource .
  ?resource a ?resClass .

  FILTER NOT EXISTS {
    ?s ?p ?o .
  }

}

But if you share a variable in MINUS, you get no results as well:

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 xsd: <http://www.w3.org/2001/XMLSchema#>
PREFIX knora-base: <http://www.knora.org/ontology/knora-base#>

SELECT * WHERE {

  ?resClass rdfs:subClassOf+ knora-base:Resource .
  ?resource a ?resClass .

  MINUS {
    ?resource ?p ?o .
  }

}

So MINUS seems to try to remove matching statements from the results (according to the statements matched so far), but only if you share variables that you use it the statements above. Otherwise the MINUS takes no effect at all, whereas FILTER NOT EXISTS does not seem to care about the context.

If I run the queries above in graphdb, I get the same results but they it takes a long time. So there clearly seems to be a different behaviour which justifies the if in the query templates. If I understand correctly, the queries stay the same for graphdb.

[benjamingeer]

The best explanation that I was able to get is here, but I don't understand it:

https://issues.apache.org/jira/browse/JENA-1130

I think that at some point we should ask Ontotext about this.

[tobiasschweizer]

This implies that knora-base:hasFileValue is never used directly, but only by means of subproperties. Correct?

[benjamingeer]

Correct.

[benjamingeer]

Can I merge this now?