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.
ModelFactory.createDefaultModel()
. This [by default] delivers a
plain RDF model, stored in-memory, that does no inference and has no special
ontology 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:
createModel(String)
: create a model with the given name in
the ModelMaker. If a model with that name already exists, then that model is
used instead.
openModel(String)
: open an existing model with the given
name. If no such model exists, create a new empty one and give it that name.
[createModel(String) and openModel(String) behave in the same way, but each
has a two-argument form for which the behaviour is different. Use whichever
one best fits your intention.]
createModel()
: create a fresh anonymous model.
getModel()
: each ModelMaker
has a default
model; this method returns that model.
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,
ModelFactory
provides constants for those styles:
ModelFactory.Standard
ModelFactory.Convenient
ModelFactory.Minimal
ModelFactory.createDefaultModel(style)
creates a default
model with the specified reification style.
ModelFactory.createMemModelMaker(style)
creates a ModelMaker
that creates memory models with the specified reification style.
ModelFactory.createFileModelMaker(root,style)
ModelFactory creation of models takes place through RDB ModelMakers:
createModelRDBMaker(IDBConnection c)
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:
ModelFactory.createSimpleRDBConnection(url,user,pass,type)
:
creates a connection to the database with the given JDBC url, the given user
and password, and the database type.
ModelFactory.createSimpleRDBConnection()
: creates
a connection to the database, taking the URL from the system property jena.db.url,
the user name from jena.db.user, the password from jena.db.password,
and the database type from jena.db.type.
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.
RDFS reasoning is directly available:
createRDFSModel(Model base)
creates an inference model over the
base model using the built-in RDFS inference rules and any RDFS statements
in the base model.
createRDFSModel(Model schema, Model base)
creates an RDFS
inference model from the base model and the supplied schema model. The advantage
of supplying the schema separately is that the reasoner may be able to compute
useful information in advance on the assumption that the schema won't change,
or at least not change as often as the base model.
createInfModel(Reasoner reasoner, Model base)
creates
an inference model using the rules of reasoner
over the
model base
.
createInfModel(Reasoner reasoner, Model schema, Model base)
Just as for the RDFS case, the schema may be supplied separately to allow the
reasoner to digest them before working on the model.
getOWLReasoner()
: the reasoner used for OWL inference
getRDFSReasoner()
: the reasoner used for RDFS inference
getTransitiveReasoner()
: a reasoner for doing subclass and
supproperty closure.
createOntologyModel()
Creates an ontology model
which is in-memory and presents OWL ontologies.
createOntologyModel(OntModelSpec spec, Model base)
Creates an
ontology model according the
OntModelSpec spec
which presents the ontology of base
.
createOntologyModel(OntModelSpec spec, ModelMaker maker, Model base)
Creates an OWL ontology model according to the spec
over the
base
model. If the ontology model needs to construct additional
models (for OWL imports), use the ModelMaker
to create them.
[The previous method will construct a MemModelMaker
for this.]
OntModelSpec
s come from? There's a cluster of constants
in the class which provide for common uses; to name but three:
OntModelSpec.OWL_MEM_RDFS_INF
OWL ontologies, model stored
in memory, using RDFS entailment only
OntModelSpec.RDFS_MEM
RDFS ontologies, in memory, but doing
no additional inferences
OntModelSpec.OWL_DL_MEM_RULE_INF
OWL ontologies, in memory,
with the full OWL Lite inference
assembleModelFrom( Model singleRoot )
: assemble
a Model from the single Model description in singleRoot
.
If there is no such description, or more than one, an exception
is thrown. If a description has to be selected from more than
one available candidates, consider using the methods below.
findAssemblerRoots( Model m )
: answer a Set
of all the Resources in m
which are of type
ja:Model
, ie descriptions of models to assemble.
(Note that this will include sub-descriptions of embedded
models if they are present.)
assembleModelFrom( Resource root )
: answer
a Model assembled according to the description hanging
from root
.
Assemblers can construct other things as well as models, and the Assembler system is user-extensible: see the howto for details.
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.