50 ways to make your models

author: Chris Dollin
version: 1.2, Jena 2.5+, January 2007

introduction

Jena has become a moderately complicated system, with several different kinds of Model and ways of constructing them. This note describes the Jena 2 ModelFactory, your one-stop shop for creating Jena models. ModelFactory lives in com.hp.hpl.jena.rdf.model, which you will import anyway to do anything with models.

Most of ModelFactory methods have been around for a while now, but Jena 2.5's ModelFactory contains methods that use the Assembler API which appeared in Jena 2.4, which allows models to be created according to RDF descriptions that can be programmatically constructed or read in from external resources such as configuration files. (This API replaces the old ModelSpec API, which had proved unsatisfactory.)

This note is an introduction, not an exhaustive description. As usual consult the Javadoc for details of the methods and classes to use.

simple model creation

The simplest way to create a model (if not the shortest) is to call ModelFactory.createDefaultModel(). This [by default] delivers a plain RDF model, stored in-memory, that does no inference and has no special ontology interface.

ModelMakers

Plain models can be given names which allows them to be "saved" and looked up by name later. This is handled by implementations of the interface ModelMaker; each ModelMaker produces Models of the same kind. The simplest kind of ModelMaker is a memory model maker, which you get by calling ModelFactory.createMemModelMaker(). The methods you'd want to use to start with on a ModelMaker are: There are other methods, for removing models, additional control over create vs open, closing the maker, and looking names up; for those consult the ModelMaker javadoc.

file-based models

The method ModelFactory.createFileModelMaker(String) returns a ModelMaker which attaches models to filing-system files. The String argument is the fileBase. When a file-ModelMaker opens a file, it reads it from a file in the directory named by the fileBase; when the model is closed (and only then, in the current implementation), the contents of the model are written back to the file.

Because the names of models in a modelMaker can be arbitrary character strings, in particular URIs, they are translated slightly to avoid confusion with significant characters of common filing systems. In the current implementation,

reification styles

Jena models have different reification styles, which are described in more detail in the reification howto. ModelFactory provides constants for those styles: And methods corresponding to those already discussed: Reification styles also appear in other Modelfactory methods, although they are not required. We shall not discuss them further in this document; consult the Javadoc for appropriate details.

database model creation

Jena allows models to be created within databases. For an extensive discussion of the available options and controls, see the database howto documents. The current ModelFactory interface only provides simple access to database model creation.

ModelFactory creation of models takes place through RDB ModelMakers:

delivers a ModelMaker that makes (or finds) models by name in the Jena model database attached to the connection c. Models from an RDB maker are "just like" memory-based models, except that they can be much larger, are likely to be significantly slower, and persist over application termination.

The connection can be created in two ways:

Details of these fields can be found in the database documentation, as well as direct ways to construct connections if required, and additional operations on RDB Models that may be useful.

legacy DAML models

The method createDAMLModel() creates a DAML Model using the legacy DAML interface. This method is only provided for backward compatability. New development should use the Ontology API and OWL instead of DAML. We strongly encourage users to switch from the legacy API.

inference model creation

An important feature of Jena 2 is support for different kinds of inference over RDF-based models (used for RDFS, OWL, and DAML). Inference models are constructed by applying reasoners to base models and optionally schema. The statements deduced by the reasoner from the base model then appear in the inferred model alongside the statements from the base model itself.

RDFS reasoning is directly available:

It's possible to use other reasoning systems than RDFS. For these a Reasoner is required: Ah, but from where do you fetch your reasoners? From the reasoner registry, the class ReasonerRegistry. This allows reasoners to be looked up by name, but also provides some predefined access methods for well-know reasoners:

ontology model creation

An ontology model is one that presents RDF as an ontology - classes, individuals, different kinds of properties, and so forth. Jena supports RDFS, OWL, and DAML ontologies through profiles. There is extensive documentation on Jena's ontology support, so all we'll do here is summarise the creation methods. And where do OntModelSpecs come from? There's a cluster of constants in the class which provide for common uses; to name but three:

creating models from Assembler descriptions

A new feature of Jena since Jena 2.4 is the use of assembler descriptions, documented in the assembler howto. Access to the assembler system for model creation is provided by three ModelFactory methods:

Assemblers can construct other things as well as models, and the Assembler system is user-extensible: see the howto for details.

Hodgepodge

Finally, ModelFactory contains a hodgepodge of methods for some special cases not conveniently dealt with elsewhere.

createModelForGraph(Graph g) is used when an advanced user with access to the Jena SPI has constructed or obtained a Graph and wishes to present it as a model. This method wraps the graph up as a plain model. Alterations to the graph are visible in the model, and vice versa.

withHiddenStatements(Model) returns a new Model in which any reification quadlets (see the reification howto) that may be hidden in the base model are exposed in the result. It may return the base model, if it does not hide quadlets. This is useful if you want to see all the statements of the model as they will appear in a serialisation.