Persistent storage of models

The models in a Quaestor knowledgebase are by default transient – if the Quaestor server is stopped, then the contents of the knowledgebase disappear. It is possible, however, to create a persistent model (or, in Quaestor’s terms, a persistent submodel within a ‘knowledgebase’), backed by a database, which will persist between Quaestor invocations.

Jena TDB

The preferred persistence mechanism – certainly the simpler to set up – uses the Jena TDB library.

To configure a persistent submodel, you must create the submodel by PUTting appropriate metadata to a submodel's metadata URL. You must do this when creating the submodel – you cannot convert an existing model to a persistent one by altering its metadata. You declare that the submodel, named by its URI, is of type quaestor:PersistentModel, by PUTting RDF like the following:

@prefix quaestor: <http://ns.eurovotech.org/quaestor#>.
<> a quaestor:PersistentModel.

Note that, since this RDF is parsed with the submodel's URI as its base URI, you can most conveniently refer to the submodel as just <> (or rdf:about="" when using RDF/XML).

This will only work if the Quaestor server has been configured to permit persistent models.

Jena SDB

The other persistence mechanism currently implemented in Quaestor is one which uses the Jena SDB interface. This is more fully developed than TDB, and is probably currently preferable for storing large volumes of data, although with increasing maturity, TDB should take over this role, too.

To use this persistence mechanism, you must set up and initialise your SDB database, as discussed at the Jena SDB support pages. This is unfortunately a rather fiddly process.

Having done that, you create a new submodel for the knowledgebase, by uploading RDF as described elsewhere. In this case, however, rather than the RDF being the content of the submodel, it is a specification of the connection to the SDB database, as described in the SDB documentation. For example, if you had set up SDB using a PostgreSQL database named sdb1, with a username of postgres, then this configuration file might look as follows:

@prefix rdf:      <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix sdb:      <http://jena.hpl.hp.com/2007/sdb#> .

[] rdf:type sdb:Store;
        sdb:layout      "layout2/index";
        sdb:connection  _:c.

_:c rdf:type sdb:SDBConnection;
        sdb:sdbType     "postgresql";
        sdb:sdbHost     "localhost";
        sdb:sdbName     "sdb1";
        sdb:sdbUser     "postgres";
        sdb:driver      "org.postgresql.Driver".

After that, the contents of the SDB store will appear as part of the knowledgebase containing this submodel.