0

I have installed a Jena Fuseki server on OpenShift.

The --config services.ttl configuration file is as shown below.

What I observe is the following:

If I perform a SPARQL update from the Control Panel I get Update Succeeded and some TDB files do change on the server (in ./app-root/data/DB/).

However when I perform a SPARQL query such as SELECT ?s ?p ?o WHERE { ?s ?p ?o. } again in the Control Panel I get zero statements back. This same is true for this GET request:

http://<obfuscated>.rhcloud.com/ds/query?query=SELECT+%3Fs+%3Fp+%3Fo+WHERE+{+%3Fs+%3Fp+%3Fo.+}&output=text&stylesheet=

The log file on OpenShift contains these entries:

INFO  [24] GET http://<obfuscated>.rhcloud.com/ds/query?query=SELECT+%3Fs+%3Fp+%3Fo+WHERE+{+%3Fs+%3Fp+%3Fo.+}+&output=text&stylesheet=
INFO  [24] Query = SELECT ?s ?p ?o WHERE { ?s ?p ?o. } 
INFO  [24] exec/select
INFO  [24] 200 OK (2 ms) 

So it appears as if RDF statements can be written to TDB but not retrieved. If I try the same on a local installation of Fuseki the problem does not manifest.

What else can I do to diagnose and resolve this problem with Fuseki on OpenShift?

UPDATE Apparently the problem does not manifest if I INSERT statements into a named GRAPH (not the default graph).

@prefix : <#> .
@prefix fuseki: <http://jena.apache.org/fuseki#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix tdb: <http://jena.hpl.hp.com/2008/tdb#> .
@prefix ja: <http://jena.hpl.hp.com/2005/11/Assembler#> .

[] rdf:type fuseki:Server ;
  fuseki:services (
  <#service>
 ) .

[] ja:loadClass "com.hp.hpl.jena.tdb.TDB" .
tdb:DatasetTDB rdfs:subClassOf ja:RDFDataset .
tdb:GraphTDB rdfs:subClassOf ja:Model .

<#service> a fuseki:Service ;
  fuseki:name "ds" ;
  fuseki:serviceQuery "sparql" ;
  fuseki:serviceQuery "query" ;
  fuseki:serviceUpdate "update" ;
  fuseki:serviceUpload "upload" ;
  fuseki:serviceReadWriteGraphStore "data" ;
  fuseki:dataset <#dataset> ;
.

<#dataset> a tdb:DatasetTDB ;
  tdb:location "../data/DB" ;
  tdb:unionDefaultGraph true ;
.
Drux
  • 11,992
  • 13
  • 66
  • 116

1 Answers1

0

tdb:unionDefaultGraph true turned out to be the culprit. From the documentation:

An assembler can specify that the default graph for query is the union of the named graphs. This is done by adding tdb:unionDefaultGraph.

Since this does not mention the default graph as part of the union I guess with this configuration there is no default graph other than the union of the named graph and hence updates that do not name a graph are ignored.

The described problem disappears with the alternative configuration tdb:unionDefaultGraph false.

Drux
  • 11,992
  • 13
  • 66
  • 116