compared with
This line was removed.
This word was removed. This word was added.
This line was added.

Changes (8)

View Page History
Another approach is to download the full version of Sesame and configure GraphDB-SE as a plug-in. This method uses the Sesame HTTP server hosted in Tomcat (or similar) and in this way you can use Sesame together with GraphDB as a server application, accessed via the standard Sesame APIs.

Sesame version 2.2 onwards includes the Sesame Workbench - a convenient Web Application for managing repositories, importing/exporting RDF data, executing queries, etc.

For more information please check the "doc" folder of the GraphDB-SE archive.
h5. How can I retrieve my repository configurations from the Sesame SYSTEM repository?

When using a LocalRepositoryManager, Sesame will store the configuration data for repositories in its own 'SYSTEM' repository. A tomcat instance will do the same and you will see 'SYSTEM' under the list of repositories that the instance is managing. To see what configuration data is stored in a GraphDB-SE repository, connect to the SYSTEM repository and execute the following query:


For GraphDB-Enterprise worker repositories the query is slightly different:

PREFIX sys: <>
PREFIX sail: <>

select ?id ?type ?param ?value
where {
?rep sys:repositoryID ?id .
?rep sys:repositoryImpl ?delegate .
?delegate sys:delegate ?impl .
?impl sys:repositoryType ?type .
optional {
?impl sail:sailImpl ?sail .
?sail ?param ?value .
# FILTER( ?id = "specific_repository_id" ) .
ORDER BY ?id ?param

This will return the repository ID and type, followed by name-value pairs of configuration data for SAIL repositories, including the SAIL type - "owlim:Sail" for GraphDB-SE and "swiftowlim:Sail" for GraphDB-Lite. GraphDB-Enterprise master nodes are not SAIL repositories and have the type "owlim:ReplicationCluster".

There is no easy generic way of changing the configuration - it is stored in the SYSTEM repository created and maintained by Sesame. However, GraphDB allows overriding of these parameters by specifying the parameter values as JVM options. For instance, by passing \-Dcache-memory=1g option to the JVM, GraphDB-SE will read it and use its value to override whatever was configured by the .ttl file. This is convenient for temporary set-ups that require easy and fast configuration change, e.g. for experimental purposes.

Changing the configuration in the SYSTEM repository is trickier, because the configurations are usually structured using blank node identifiers, which are always unique, so attempting to modify a statement with a blank node by using the same blank node identifier will fail. However, this can be achieved with SPARQL UPDATE using a DELETE-INSERT-WHERE command as follows (please note that this is valid for GraphDB-SE repositories):


For GraphDB-Enterprise worker repositories, the Sparql update is slightly different:

PREFIX sys: <>
PREFIX sail: <>
PREFIX onto: <>
DELETE { GRAPH ?g {?sail ?param ?old_value } }
INSERT { GRAPH ?g {?sail ?param ?new_value } }
GRAPH ?g { ?rep sys:repositoryID ?id . }
GRAPH ?g { ?rep sys:repositoryImpl ?delegate . }
GRAPH ?g { ?delegate sys:repositoryType ?type . }
GRAPH ?g { ?delegate sys:delegate ?impl . }
GRAPH ?g { ?impl sail:sailImpl ?sail . }
GRAPH ?g { ?sail ?param ?old_value . }
FILTER( ?id = "repo_id" ) .
FILTER( ?param = onto:enable-context-index ) .
BIND( "true" AS ?new_value ) .

Modify the last three lines of the update command to specify the repository ID, the parameter, and the new value. Then execute against the SYSTEM repository. In this example, the enable-context-index is changed, but there are other parameters that can not be changed once the repository is created, e.g. the rule-set (in the case of GraphDB-SE).

If you receive a stack trace containing the following:

bq. Invocation of init method failed; nested exception is Unable to create logging directory /usr/share/tomcat6/.aduna/openrdf-sesame/logs
then this indicates that Tomcat does not have write permission to its data directory (where it stores configuration, logs, and actual repository data). To fix this, log in as root to the server machine and do the following:
The basic procedure is to export the RDF data from the old version of GraphDB-SE and then reload it into a new repository instance that uses the new version of GraphDB-SE. Exporting is straightforward when using the Sesame workbench - simply click the 'Export' button, choose the format, and click 'download'. To import into a new repository, click 'add', select a format, specify the file and base URI, then click 'Upload'.

If not using the Sesame workbench, the export must be done programmatically using the {{RepositoryConnection.getStatements()}} API, because the Sesame console does not have an export function.
NOTE: It should be possible to export only the explicit statements, as the inferred statements will be recomputed at load time. Fortunately, the Sesame console application does have a 'load' function and this can be used to reload the exported statements.

The XML parser will generate an error similar to the following:

bq. Parser has reached the entity expansion limit "64,000" set by the Application.
when it generates more than a specified number of 'entities'. The default limit for the built-in Java XML parser is 64,000, however it can be configured by using a Java system property. To increase the limit, pass the following to the JVM in which GraphDB/Sesame is running. Note that the actual value can be increased as necessary. Don't forget that if running in Tomcat then this must be passed to the Tomcat instance using the CATALINA_OPTS environment variable.