You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@jena.apache.org by ij...@apache.org on 2011/09/08 01:36:07 UTC
svn commit: r1166468 - in /incubator/jena/site/trunk:
content/jena/documentation/assembler/ templates/
Author: ijd
Date: Wed Sep 7 23:36:07 2011
New Revision: 1166468
URL: http://svn.apache.org/viewvc?rev=1166468&view=rev
Log:
Initial import of Assembler documentation
Added:
incubator/jena/site/trunk/content/jena/documentation/assembler/
incubator/jena/site/trunk/content/jena/documentation/assembler/assembler-howto.mdtext
incubator/jena/site/trunk/content/jena/documentation/assembler/index.mdtext
incubator/jena/site/trunk/content/jena/documentation/assembler/inside-assemblers.mdtext
Modified:
incubator/jena/site/trunk/templates/sidenav.mdtext
Added: incubator/jena/site/trunk/content/jena/documentation/assembler/assembler-howto.mdtext
URL: http://svn.apache.org/viewvc/incubator/jena/site/trunk/content/jena/documentation/assembler/assembler-howto.mdtext?rev=1166468&view=auto
==============================================================================
--- incubator/jena/site/trunk/content/jena/documentation/assembler/assembler-howto.mdtext (added)
+++ incubator/jena/site/trunk/content/jena/documentation/assembler/assembler-howto.mdtext Wed Sep 7 23:36:07 2011
@@ -0,0 +1,851 @@
+Title: Jena Assembler howto
+
+## Introduction
+
+This document describes the vocabulary and effect of the built-in
+Jena assembler descriptions for constructing models (and other
+things). A [companion document](inside-assemblers.html) describes
+the built-in assembler classes and how to write and integrate your
+own assemblers. If you just need a quick guide to the common model
+specifications, see the [assembler quickstart](index.html).
+
+This document describes how to use the Assembler classes to
+construct models -- and other things -- from RDF descriptions that
+use the Jena Assembler vocabulary. That vocabulary is available in
+[ja-vocabulary.n3](../../vocabularies/assembler.n3) as an RDFS
+schema with conventional prefix `ja` for the URI
+`http://jena.hpl.hp.com/2005/11/Assembler#`; the class `JA` is its
+Java rendition.
+
+The examples used in this document are extracted from the examples
+file [examples.n3](examples.n3). The pieces of RDF/OWL schema are
+extracted from the `ja-vocabulary` file.
+
+The property names selected are those which are the "declared
+properties" (as per Jena's `listDeclaredProperties` method) of the
+class. Only the most specialised super-classes and range classes are
+shown, so (for example) `rdf:Resource` typically won't appear.
+
+### Overview
+
+An Assembler specification is a Resource in some RDF Model. The
+properties of that Resource describe what kind of object is to be
+assembled and what its components are: for example, an InfModel is
+constructed by specifying a base model and a reasoner. The
+specifications for the components are themselves Assembler
+specifications given by other Resources in the same Model.For
+example, to specify a memory model with data loaded from a file:
+
+ eg:opening-example a ja:MemoryModel
+ ; ja:content [ja:externalContent <file:////home/kers/projects/jena2/doc/assembler/Data/example.n3>]
+ .
+
+The `rdf:type` of `eg:model` specifies that the constructed Model is to
+be a Jena memory-based model. The `ja:content` property specifies
+that the model is to be loaded with the content of the resource
+`file:Data/example.n3`. The content handler guesses from the ".n3"
+suffix that this file is to be read using the Jena N3 reader.
+
+Unless otherwise specified by an application, Assembler
+specifications are interpreted after *completion* by
+
+1. including the JA schema,
+2. including (recursively) the objects of any owl:imports and
+ ja:imports statements, and
+3. doing [(limited) RDFS inference](#limited-rdfs-inference).
+
+(The supplied model is not modified.) In the example above,
+`eg:model` has to be given an explicit type, but the `ja:externalContent`
+bnode is implicitly typed by the domain of `ja:externalContent`. In
+this document, we will usually leave out inferrable types.
+
+We can construct our example model from the specification like this
+(you may need to tweak the filename to make this work in your
+environment):
+
+ Model spec = FileManager.get().loadModel( "examples.n3" );
+ Resource root = spec.createResource( spec.expandPrefix( "eg:opening-example" ) );
+ Model m = Assembler.general.openModel( root );
+
+The model is constructed from the "root resource",
+`eg:opening-example` in our example. `general` knows how to create
+all the kinds of objects - not just Models - that we describe in
+the next sections.
+
+## Specifications common to all models
+
+Assembler specifications can describe many kinds of models: memory,
+inference, database, ontology, and file-backed. All of these model
+specifications share a set of base properties for attaching
+content, prefix mappings, and reification modes.
+
+ ja:Loadable a rdfs:Class ;
+ rdfs:subClassOf ja:Object
+ .
+ ja:initialContent a rdf:Property ;
+ rdfs:domain ja:Loadable
+ rdfs:range ja:Content
+ .
+ ja:content a rdf:Property ;
+ rdfs:domain ja:Loadable ;
+ rdfs:range ja:Content
+ .
+
+ ja:Model a rdfs:Class ;
+ rdfs:subClassOf ja:ContentItem ;
+ rdfs:subClassOf ja:Loadable
+ .
+ ja:prefixMapping a rdf:Property ;
+ rdfs:domain ja:Model ;
+ rdfs:range ja:PrefixMapping
+ .
+ ja:reificationMode a rdf:Property ;
+ rdfs:domain ja:Model ;
+ rdfs:range ja:ReificationMode
+ .
+
+All of a model's `ja:content` property values are interpreted as
+specifying `Content` objects and a single composite `Content`
+object is constructed and used to initialise the model. See
+[Content](#spec-content) for the description of Content
+specifications. For example:
+
+ eg:sharedContent
+ ja:externalContent <http://somewhere/RDF/ont.owl>
+ .
+ eg:common-example a ja:MemoryModel ;
+ ja:content eg:sharedContent ;
+ ja:content [ja:externalContent <file:////home/kers/projects/jena2/doc/assembler/Data/A.rdf>] ;
+ ja:content [ja:externalContent <file:////home/kers/projects/jena2/doc/assembler/Data/B.rdf>]
+ .
+
+The model constructed for `eg:A` will be loaded with the contents
+of `Data/A.n3`, `Data/B.rdf`, and `http://somewhere/RDF/ont.owl`.
+If the model supports transactions, then the content is loaded
+inside a transaction; if the load fails, the transaction is
+aborted, and a `TransactionAbortedException` thrown. If the content
+has any prefix mappings, then they are also added to the model.
+
+All of a model's `ja:prefixMapping`, `ja:prefix`, and
+`ja:namespace` properties are interpreted as specifying a
+`PrefixMapping` object and a single composite `PrefixMapping` is
+constructed and used to set the prefixes of the model. See
+[PrefixMapping](#spec-prefix-mapping) for the description of
+Content specifications.
+
+A model may have a single `ja:reificationMode` property whose value
+must be one of the constants `ja:standard`, `ja:convenient`, or
+`ja:minimal`. The model's reification mode is set accordingly, if
+possible.
+
+### Content specification
+
+A Content specification describes content that can be used to fill
+models. Content can be external (files and URLs) or literal
+(strings in the specification) or quotations (referring to RDF
+which is part of the specification).
+
+ ja:Content a rdfs:Class ;
+ rdfs:subClassOf ja:HasFileManager
+ .
+
+ ja:HasFileManager a rdfs:Class ;
+ rdfs:subClassOf ja:Object
+ .
+ ja:fileManager a rdf:Property ;
+ rdfs:domain ja:HasFileManager ;
+ rdfs:range ja:FileManager
+ .
+
+A `ja:Content` specification may have zero or more
+`ja:externalContent` property values. These are URI resources
+naming an external (file or http etc) RDF object. The constructed
+Content object contains the union of the values of all such
+resources. For example:
+
+ eg:external-content-example
+ ja:externalContent <file:////home/kers/projects/jena2/doc/assembler/Data/C.owl>,
+ <http://jena.hpl.hp.com/some-jena-data.rdf>
+ .
+
+The external content is located using a `FileManager`. If the
+`Content` resource has a `ja:fileManager` property, then the
+`FileManager` described by that resource is used. Otherwise, if the
+`ContentAssembler` assembling this specification was constructed
+with a `FileManager` argument, that `FileManager` is used.
+Otherwise, the default `FileManager`, `FileManager.get()`, is
+used.
+
+The string literal value of the any `ja:literalContent` properties
+is interpreted as RDF in an appropriate language. The constructed
+Content object contains that RDF. The language is either specified
+by an explicit `ja:contentEncoding` property value, or guessed from
+the content of the string. The only encodings permitted are "N3"
+and "RDF/XML". For example:
+
+ eg:literal-content-example
+ ja:literalContent "\_:it dc:title 'Interesting Times'"
+ .
+
+The literal content is wrapped so that prefix declarations for
+**rdf**, **rdfs**, **owl**, **dc**, and **xsd** apply before
+interpretation.
+
+The property values of any `ja:quotedContent` properties should be
+resources. The subgraphs rooted at those resources (using the
+algorithm from `ResourceUtils.reachableClosure()`) are added to the
+content.
+
+### RDB models and Connections
+
+The description of an RDB model requires its name and a description
+of the JDBC connection for the database the model is in. For
+example:
+
+ eg:database-example
+ ja:connection eg:connection ;
+ ja:modelName "Thunderbird3"
+ .
+ eg:connection
+ ja:dbType "MySQL" ;
+ ja:dbURL <jdbc:mysql://localhost/test> ;
+ ja:dbUser "cjd"
+ .
+
+ ja:RDBModel a rdfs:Class ;
+ rdfs:subClassOf ja:Connectable ;
+ rdfs:subClassOf [owl:onProperty ja:connection; owl:cardinality 1] ;
+ rdfs:subClassOf ja:NamedModel
+ .
+
+ ja:Connectable a rdfs:Class ;
+ rdfs:subClassOf ja:Object
+ .
+ ja:connection a rdf:Property ;
+ rdfs:domain ja:Connectable ;
+ rdfs:range ja:Connection
+ .
+
+ ja:NamedModel a rdfs:Class ;
+ rdfs:subClassOf [owl:onProperty ja:modelName; owl:cardinality 1] ;
+ rdfs:subClassOf ja:Model
+ .
+ ja:modelName a rdf:Property ;
+ rdfs:domain ja:NamedModel
+ .
+
+`ja:RDBModel` is a subclass of `ja:NamedModel` and shares the
+`ja:ModelName` property value naming the model within the
+database.
+
+The mandatory unique property value of `ja:connection` specifies
+the connection to the database to be used.
+
+The description of a connection requires the database name and type
+and the user name and password. If the username and password are
+not specified, `Assembler.general` will default them, normally to
+the values of the system properties `jena.dbUser` and
+`jena.dbPassword`.
+
+ ja:Connection a rdfs:Class ;
+ rdfs:subClassOf [owl:onProperty ja:dbType; owl:maxCardinality 1] ;
+ rdfs:subClassOf [owl:onProperty ja:dbClass; owl:maxCardinality 1] ;
+ rdfs:subClassOf [owl:onProperty ja:dbTypeProperty; owl:maxCardinality 1] ;
+ rdfs:subClassOf [owl:onProperty ja:dbURL; owl:maxCardinality 1] ;
+ rdfs:subClassOf [owl:onProperty ja:dbClassProperty; owl:maxCardinality 1] ;
+ rdfs:subClassOf [owl:onProperty ja:dbUser; owl:maxCardinality 1] ;
+ rdfs:subClassOf [owl:onProperty ja:dbPassword; owl:maxCardinality 1] ;
+ rdfs:subClassOf [owl:onProperty ja:dbUserProperty; owl:maxCardinality 1] ;
+ rdfs:subClassOf [owl:onProperty ja:dbPasswordProperty; owl:maxCardinality 1] ;
+ rdfs:subClassOf [owl:onProperty ja:dbURLProperty; owl:maxCardinality 1] ;
+ rdfs:subClassOf ja:Object
+ .
+ ja:dbTypeProperty a rdf:Property ;
+ rdfs:domain ja:Connection
+ .
+ ja:dbPasswordProperty a rdf:Property ;
+ rdfs:domain ja:Connection
+ .
+ ja:dbType a rdf:Property ;
+ rdfs:domain ja:Connection
+ .
+ ja:dbURL a rdf:Property ;
+ rdfs:domain ja:Connection
+ .
+ ja:dbPassword a rdf:Property ;
+ rdfs:domain ja:Connection
+ .
+ ja:dbURLProperty a rdf:Property ;
+ rdfs:domain ja:Connection
+ .
+ ja:dbUserProperty a rdf:Property ;
+ rdfs:domain ja:Connection
+ .
+ ja:dbClass a rdf:Property ;
+ rdfs:domain ja:Connection
+ .
+ ja:dbClassProperty a rdf:Property ;
+ rdfs:domain ja:Connection
+ .
+ ja:dbUser a rdf:Property ;
+ rdfs:domain ja:Connection
+ .
+
+The `ja:dbURL` property value specifies the URL of the database to
+be connected to. If it is omitted, the `ja:dbURLProperty` value is
+the name of a Java system property whose value is the URL of the
+database.
+
+The `ja:dbType` property value specifies the type of the database
+as a string. If it is omitted, the `ja:dbTypeProperty` value is the
+name of a Java system property whose value is the database type.
+
+The unique `ja:dbUser` property value is a string literal whose
+value is the name of the user connecting to the database. If it is
+omitted, the value of the `ja:dbUserProperty` is the name of a Java
+system property containing the user name.
+
+The unique `ja:dbPassword` property value is the password of the
+user connecting to the database. If it is omitted, the value of the
+`ja:dbPasswordProperty` is the name of a Java system property whose
+value is the password.
+
+### File models
+
+A FileModel specification builds a memory model that is backed by a
+file. By "backed", we mean that the model is loaded from that file
+and written back to the file when (if) it is closed. Furthermore,
+the model (weakly) supports transactions.
+
+ eg:fileModel-example-1
+ ja:directory <file:///tmp> ;
+ ja:modelName "simple"
+ .
+
+Here, the model is read from (and written to) the file
+`/tmp/simple`. Directory names are given as resources (not
+literals) and of course file names are system dependent -- this is
+what one might see on a Unix system. If the directory name is to be
+shared by several different FileModels, it can be useful to give it
+a namespace prefix so that it can be changed in one place as
+necessary.
+
+ eg:fileModel-example-2
+ ja:directory <file:////home/kers/projects/jena2/doc/assembler/FileModels> ;
+ ja:mapName ja:true ;
+ ja:modelName "http://somewhere.org/stuff.n3"
+ .
+
+Model names can be *mapped* to allow them to be URIs without the /s
+in URIs being taken as directory separators. Here, the base file
+name will be `FileModels/http_C_S_Ssomewhere.org_Sstuff.n3`. The
+encoding is not pretty, but is sufficient for simple URIs.
+
+ ja:FileModel a rdfs:Class ;
+ rdfs:subClassOf [owl:onProperty ja:mapName; owl:maxCardinality 1] ;
+ rdfs:subClassOf [owl:onProperty ja:directory; owl:maxCardinality 1] ;
+ rdfs:subClassOf [owl:onProperty ja:fileEncoding; owl:maxCardinality 1] ;
+ rdfs:subClassOf ja:NamedModel
+ .
+ ja:fileEncoding a rdf:Property ;
+ rdfs:domain ja:FileModel
+ .
+ ja:directory a rdf:Property ;
+ rdfs:domain ja:FileModel
+ .
+ ja:mapName a rdf:Property ;
+ rdfs:domain ja:FileModel
+ .
+
+The `ja:directory` property specifies the directory in which the
+model file is located. The `ja:modelName` property specifies the
+name of the file within that directory.
+
+The optional unique property `ja:fileEncoding` has as its value a
+string which is the name of the encoding language of the model (ie
+one of RDF/XML or N3, etc). If it is omitted, the language is
+guessed from the suffix of the filename (as per
+`FileUtils.guessLang()`).
+
+If the optional unique property `ja:mapName` has the value
+`ja:true`, then the name of the model is *mapped* by replacing any
+\_, /, or : characters by the escape sequences \_\_, \_S, or \_C.
+This translation (which is the same one done by `FileGraphMaker`
+for `FileModelMaker`) allows URIs to be used as model names without
+conflicting with the filesystems use of / characters.
+
+### Inference models and reasoners
+
+Inference models are specified by supplying a description of the
+reasoner that is used by the model and (optionally) a base model to
+reason over. For example:
+
+ eg:inference-example
+ ja:baseModel [a ja:MemoryModel] ;
+ ja:reasoner [ja:reasonerURL <http://jena.hpl.hp.com/2003/RDFSExptRuleReasoner>]
+ .
+
+describes an inference model that uses RDFS reasoning. The
+*reasonerURL* property value is the URI used to identify the
+reasoner (it is the value of the Jena constant
+`RDFSRuleReasonerFactory.URI`). The base model is specified as a
+memory model; if it is left out, an empty memory model is used. Of
+course, you can specify a database model as a base model:
+
+ eg:database-example
+ ja:connection eg:connection ;
+ ja:modelName "Thunderbird3"
+ .
+ eg:connection
+ ja:dbType "MySQL" ;
+ ja:dbURL <jdbc:mysql://localhost/test> ;
+ ja:dbUser "cjd"
+ .
+ eg:db-inference-example
+ ja:baseModel eg:database-example ;
+ ja:reasoner [ja:reasonerURL <http://jena.hpl.hp.com/2003/RDFSExptRuleReasoner>]
+ .
+
+The same reasoner as used as in the previous example, but now the
+base model is a database specified in the same way as our earlier
+example.
+
+Because Jena's access to external reasoners goes through the same
+API as for its internal reasoners, you can access a DIG reasoner
+(such as Pellet running as a server) using an Assembler
+specification:
+ eg:external-inference-example
+ ja:reasoner [<http://jena.hpl.hp.com/2003/JenaReasoner#extReasonerURL>
+ <http://localhost:2004/> ;
+ ja:reasonerURL <http://jena.hpl.hp.com/2003/DIGReasoner>]
+ .
+
+If there's a DIG server running locally on port 2004, this
+specification will create a DIG inference model that uses it.
+
+The internal rule reasoner can be supplied with rules written
+inside the specification, or outside from some resource (file or
+http: URL):
+ eg:rule-inference-example
+ ja:reasoner [ja:rule "[r1: (?x my:P ?y) -> (?x rdf:type my:T)]"]
+ .
+
+This reasoner will infer a type declaration from a use of a
+property. (The prefix *my* will have to be known to the rule
+parser, of course.)
+
+ ja:InfModel a rdfs:Class ;
+ rdfs:subClassOf [owl:onProperty ja:reasoner; owl:maxCardinality 1] ;
+ rdfs:subClassOf [owl:onProperty ja:baseModel; owl:maxCardinality 1] ;
+ rdfs:subClassOf ja:Model
+ .
+ ja:reasoner a rdf:Property ;
+ rdfs:domain ja:InfModel ;
+ rdfs:range ja:ReasonerFactory
+ .
+ ja:baseModel a rdf:Property ;
+ rdfs:domain ja:InfModel ;
+ rdfs:range ja:Model
+ .
+
+ ja:HasRules a rdfs:Class ;
+ rdfs:subClassOf ja:Object
+ .
+ ja:rule a rdf:Property ;
+ rdfs:domain ja:HasRules
+ .
+ ja:rulesFrom a rdf:Property ;
+ rdfs:domain ja:HasRules
+ .
+ ja:rules a rdf:Property ;
+ rdfs:domain ja:HasRules ;
+ rdfs:range ja:RuleSet
+ .
+
+An InfModel's `ja:baseModel` property value specifies the base
+model for the inference model; if omitted, an empty memory model is
+used.
+
+An InfModel's `ja:ReasonerFactory` property value specifies the
+Reasoner for this inference model; if omitted, a
+GenericRuleReasoner is used.
+
+A Reasoner's optional `ja:schema` property specifies a Model which
+contains the schema for the reasoner to be bound to. If omitted, no
+schema is used.
+
+If the Reasoner is a GenericRuleReasoner, it may have any of the
+RuleSet properties `ja:rules`, `ja:rulesFrom`, or `ja:rule`. The
+rules of the implied `RuleSet` are added to the `Reasoner`.
+
+#### ReasonerFactory
+
+A ReasonerFactory can be specified by URL or by class name (but not
+both).
+
+ ja:ReasonerFactory a rdfs:Class ;
+ rdfs:subClassOf [owl:onProperty ja:ReasonerURL; owl:maxCardinality 1] ;
+ rdfs:subClassOf ja:HasRules
+ .
+ ja:reasonerClass a rdf:Property ;
+ rdfs:domain ja:ReasonerFactory
+ .
+ ja:reasonerURL a rdf:Property ;
+ rdfs:domain ja:ReasonerFactory
+ .
+ ja:schema a rdf:Property ;
+ rdfs:domain ja:ReasonerFactory ;
+ rdfs:range ja:Model
+ .
+
+If the optional unique property `ja:reasonerURL` is specified, then
+its resource value is the URI of a reasoner in the Jena reasoner
+registry; the reasoner is the one with the given URI.
+
+If the optional property `ja:schema` is specified, then the models
+specified by all the schema properties are unioned and any reasoner
+produced by the factory will have that union bound in as its schema
+(using the `Reasoner::bindSchema()` method).
+
+If the optional unique property `ja:reasonerClass` is specified,
+its value names a class which implements `ReasonerFactory`. That
+class is loaded and an instance of it used as the factory.
+
+The class may be named by the lexical form of a literal, or by a
+URI with the (fake) "java:" scheme.
+
+If the class has a method `theInstance`, that method is called to
+supply the `ReasonerFactory` instance to use. Otherwise, a new
+instance of that class is constructed. Jena's reasoner factories
+come equipped with this method; for other factories, see the
+documentation.
+
+#### Rulesets
+
+A `RuleSet` specification allows rules (for ReasonerFactories) to
+be specified inline, elsewhere in the specification model, or in an
+external resource.
+
+ ja:RuleSet a rdfs:Class ;
+ rdfs:subClassOf ja:HasRules
+ .
+
+The optional repeatable property `ja:rule` has as its value a
+literal string which is the text of a Jena rule or rules. All those
+rules are added to the `RuleSet`.
+
+The optional repeatable property `ja:rulesFrom` has as its value a
+resource whose URI identifies a file or other external entity that
+can be loaded as Jena rules. All those rules are added to the
+`RuleSet`.
+
+The optional repeatable property `ja:rules` has as its value a
+resource which identifies another `RuleSet` in the specification
+model. All those rules from that `RuleSet` are added to this
+`RuleSet`.
+
+### Ontology models
+
+Ontology models can be specified in several ways. The simplest is
+to use the name of an OntModelSpec from the Java OntModelSpec
+class:
+
+ eg:simple-ont-example
+ ja:ontModelSpec ja:OWL_DL_MEM_RULE_INF
+ .
+
+This constructs an `OntModel` with an empty base model and using
+the OWL\_DL language and the full rule reasoner. All of the
+OntModelSpec constants in the Jena implementation are available in
+this way. A base model can be specified:
+
+ eg:base-ont-example
+ ja:baseModel [a ja:MemoryModel ;
+ ja:content [ja:externalContent <http://jena.hpl.hp.com/some-jena-data.rdf>]]
+ .
+
+The OntModel has a base which is a memory model loaded with the
+contents of `http://jena.hpl.hp.com/some-jena-data.rdf`. Since the
+ontModelSpec was omitted, it defaults to `OWL_MEM_RDFS_INF` - the
+same default as `ModelFactory.createOntologyModel()`.
+
+ ja:OntModel a rdfs:Class ;
+ rdfs:subClassOf ja:UnionModel ;
+ rdfs:subClassOf ja:InfModel
+ .
+ ja:ontModelSpec a rdf:Property ;
+ rdfs:domain ja:OntModel ;
+ rdfs:range ja:OntModelSpec
+ .
+
+ ja:OntModelSpec a rdfs:Class ;
+ rdfs:subClassOf [owl:onProperty ja:like; owl:maxCardinality 1] ;
+ rdfs:subClassOf [owl:onProperty ja:reasonerFactory; owl:maxCardinality 1] ;
+ rdfs:subClassOf [owl:onProperty ja:importSource; owl:maxCardinality 1] ;
+ rdfs:subClassOf [owl:onProperty ja:documentManager; owl:maxCardinality 1] ;
+ rdfs:subClassOf [owl:onProperty ja:ontLanguage; owl:maxCardinality 1] ;
+ rdfs:subClassOf ja:Object
+ .
+ ja:importSource a rdf:Property ;
+ rdfs:domain ja:OntModelSpec
+ .
+ ja:reasonerFactory a rdf:Property ;
+ rdfs:domain ja:OntModelSpec ;
+ rdfs:range ja:ReasonerFactory
+ .
+ ja:documentManager a rdf:Property ;
+ rdfs:domain ja:OntModelSpec
+ .
+ ja:ontLanguage a rdf:Property ;
+ rdfs:domain ja:OntModelSpec
+ .
+ ja:likeBuiltinSpec a rdf:Property ;
+ rdfs:domain ja:OntModelSpec
+ .
+
+`OntModel` is a subclass of `InfModel`, and the `ja:baseModel`
+property means the same thing.
+
+The `OntModelSpec` property value is a resource, interpreted as an
+OntModelSpec description based on its name and the value of the
+appropriate properties:
+
+- `ja:likeBuiltinSpec`: The value of this optional unique
+ property must be a JA resource whose local name is the same as the
+ name of an OntModelSpec constant (as in the simple case above).
+ This is the basis for the OntModelSpec constructed from this
+ specification. If absent, then `OWL_MEM_RDFS_INF` is used. To build
+ an OntModelSpec with no inference, use eg
+ `ja:likeBuiltinSpec ja:OWL_MEM`.
+- `ja:importSource`: The value of this optional unique property
+ is a `ModelSource` description which describes where imports are
+ obtained from. A `ModelSource` my be of class `ja:ModelSource`, for
+ which memory models are constructed, or a `ja:RDBModelSource` with
+ a `ja:connection` property, for which models are constructed in the
+ specified database.
+- `ja:documentManager`: This value of this optional unique
+ property is a DocumentManager specification. If absent, the default
+ document manager is used.
+- `ja:reasonerFactory`: The value of this optional unique
+ property is the ReasonerFactory resource which will be used to
+ construct this OntModelSpec's reasoner. A `reasonerFactory`
+ specification is the same as an InfModel's `reasoner` specification
+ (the different properties are required for technical reasons).
+- `ja:reasonerURL`: as a special case of `reasonerFactory`, a
+ reasoner may be specified by giving its URL as the object of the
+ optional unique `reasonerURL` property. It is not permitted to
+ supply both a `reasonerURL` and `reasonerFactory` properties.
+- `ja:ontLanguage`: The value of this optional unique property is
+ one of the values in the `ProfileRegistry` class which identifies
+ the ontology language of this `OntModelSpec`:
+ - OWL: http://www.w3.org/2002/07/owl\#
+ - OWL DL: http://www.w3.org/TR/owl-features/\#term\_OWLDL
+ - OWL Lite: http://www.w3.org/TR/owl-features/\#term\_OWLLite
+ - RDFS: http://www.w3.org/2000/01/rdf-schema\#
+ - DAML: http://www.daml.org/2001/03/daml+oil\#
+
+
+Any unspecified properties have default values, normally taken from
+those of `OntModelSpec.OWL_MEM_RDFS_INF`. However, if the
+OntModelSpec resource is in the JA namespace, and its local name is
+the same as that of an OntModelSpec constant, then that constant is
+used as the default value.
+
+### Document managers
+
+An `OntDocumentManager` can be specified by a `ja:DocumentManager`
+specification which describes the `OntDocumentManager`'s file
+manager and policy settings.
+
+ eg:mapper
+ lm:mapping [lm:altName "file:etc/foo.n3" ;
+ lm:name "file:foo.n3"]
+ .
+ eg:document-manager-example
+ ja:fileManager [ja:locationMapper eg:mapper] ;
+ ja:meta [ dm:altURL <http://localhost/RDF/my-alt.rdf>]
+ .
+
+In this example, `eg:document-manager-example` is a
+`ja:DocumentManager` specification. It has its own
+`FileManager specification`, the object of the
+`ja:fileManager property`; that `FileManager` has a location
+mapper, `eg:mapper`, that maps a single filename.
+
+The document manager also has an additional property to link it to
+document manager meta-data: the sub-model of the assembler
+specification reachable from `eg:document-manager-example` is
+passed to the document manager when it is created. For the meanings
+of the `dm:` properties, see the Jena ontology documentation and
+the ontology.rdf ontology.
+
+ ja:DocumentManager a rdfs:Class ;
+ rdfs:subClassOf [owl:onProperty ja:policyPath; owl:maxCardinality 1] ;
+ rdfs:subClassOf [owl:onProperty ja:fileManager; owl:maxCardinality 1] ;
+ rdfs:subClassOf [owl:onProperty ja:fileManager; owl:maxCardinality 1] ;
+ rdfs:subClassOf ja:HasFileManager
+ .
+ ja:policyPath a rdf:Property ;
+ rdfs:domain ja:DocumentManager
+ .
+
+The `ja:fileManager` property value, if present, has as its object
+a `ja:FileManager` specification; the constructed document manager
+is given a new file manager constructed from that specification. If
+there is no `ja:fileManager` property, then the default
+`FileManager` is used.
+
+The `ja:policyPath` property value, if present, should be a string
+which is a path to policy files as described in the Jena ontology
+documentation. If absent, the usual default path is applied.
+
+If the sub-model of the assembler specification reachable from the
+DocumentManager resource contains any OntDocumentManager
+`DOC\_MGR\_POLICY` or `ONTOLOGY\_SPEC` objects, they will be
+interpreted by the constructed document manager object.
+
+ ja:FileManager a rdfs:Class ;
+ rdfs:subClassOf [owl:onProperty ja:locationMapper; owl:maxCardinality 1] ;
+ rdfs:subClassOf ja:Object
+ .
+ ja:locationMapper a rdf:Property ;
+ rdfs:domain ja:FileManager ;
+ rdfs:range ja:LocationMapper
+ .
+
+A `ja:FileManager` object may have a `ja:locationMapper` property
+value which identifies the specification of a `LocationMapper`
+object initialising that file manager.
+
+ ja:LocationMapper a rdfs:Class ;
+ rdfs:subClassOf [owl:onProperty lm:mapping; owl:maxCardinality 1] ;
+ rdfs:subClassOf ja:Object
+ .
+ lm:mapping a rdf:Property ;
+ rdfs:domain ja:LocationMapper
+ .
+
+A `ja:LocationMapper` object may have `lm:mapping` property values,
+describing the location mapping, as described in the FileManager
+documentation. (Note that the vocabulary for those items is in a
+different namespace than the JA properties and classes.)
+
+### Union models
+
+Union models can be constructed from any number of sub-models and a
+single *root* model. The root model is the one written to when the
+union model is updated; the sub-models are untouched.
+
+ ja:UnionModel a rdfs:Class ;
+ rdfs:subClassOf [owl:onProperty ja:rootModel; owl:maxCardinality 1] ;
+ rdfs:subClassOf ja:Model
+ .
+ ja:rootModel a rdf:Property ;
+ rdfs:domain ja:UnionModel ;
+ rdfs:range ja:Model
+ .
+ ja:subModel a rdf:Property ;
+ rdfs:domain ja:UnionModel ;
+ rdfs:range ja:Model
+ .
+
+If the single `ja:rootModel` property is present, its value
+describes a model to use as the root model of the union. All
+updates to the union are directed to this root model. If no root
+model is supplied, the union is given an *immutable*, *empty* model
+as its root.
+
+Any `ja:subModel` property values have objects describing the
+remaining sub-models of the union. The order of the sub-models in
+the union is *undefined* (which is why there's a special rootModel
+property).
+
+### Prefix mappings
+
+The PrefixMappings of a model may be set from PrefixMapping
+specifications.
+
+ ja:PrefixMapping a rdfs:Class ;
+ rdfs:subClassOf ja:Object
+ .
+ ja:includes a rdf:Property ;
+ rdfs:domain ja:PrefixMapping ;
+ rdfs:range ja:PrefixMapping
+ .
+
+ ja:SinglePrefixMapping a rdfs:Class ;
+ rdfs:subClassOf [owl:onProperty ja:namespace; owl:cardinality 1] ;
+ rdfs:subClassOf [owl:onProperty ja:prefix; owl:cardinality 1] ;
+ rdfs:subClassOf ja:PrefixMapping
+ .
+ ja:namespace a rdf:Property ;
+ rdfs:domain ja:SinglePrefixMapping
+ .
+ ja:prefix a rdf:Property ;
+ rdfs:domain ja:SinglePrefixMapping
+ .
+
+The `ja:includes` property allows a PrefixMapping to include the
+content of other specified PrefixMappings.
+
+The `ja:prefix` and `ja:namespace` properties allow the
+construction of a single element of a prefix mapping by specifying
+the prefix and namespace of the mapping.
+
+### Other Assembler directives
+
+There are two more `Assembler` directives that can be used in an
+Assembler specification: the *assembler* and *imports* directives.
+
+#### Assembler
+
+A specification may contain statements of the form:
+
+ someResource ja:assembler "some.Assembler.class.name"
+
+When `someResource` is used as the type of a root object, the
+AssemblerGroup that processes the description will use an instance
+of the Java class named by the object of the statement. That class
+must implement the `Assembler` interface. See
+[loading assembler classes](#loading-assembler-classes) for more
+details.
+
+Similarly, statements of the form:
+
+ someResource ja:loadClass "some.class.name"
+
+will cause the named class to be loaded (but not treated as
+assemblers).
+
+#### Imports
+
+If a specification contains statements of the form:
+
+ anyResource owl:imports someURL
+
+or, equivalently,
+
+ anyResource ja:imports someURL
+
+then the specification is regarded as also containing the contents
+of the RDF at `someURL`. That RDF may in turn contain `imports`
+referring to other RDF.
+
+## Limited RDFS inference
+
+The Assembler engine uses limited RDFS inference to complete the
+model it is given, so that the spec-writer does not need to write
+excessive and redundant RDF. (It does not use the usual Jena
+reasoners because this limited once-off reasoning has been faster.)
+The inference steps are:
+
+- add all the classes from the JA schema.
+- do subclass closure over all the classes.
+- do domain and range inference.
+- do simple intersection inference: if X is an instance of
+ *intersection A B C ...*, then X is an instance of A, B, C ... (and
+ their supertypes).
+
+This is sufficient for closed-world assembling. Other parts of the
+`JA` schema -- eg, cardinality constraints -- are hard-coded into the
+individual assemblers.
Added: incubator/jena/site/trunk/content/jena/documentation/assembler/index.mdtext
URL: http://svn.apache.org/viewvc/incubator/jena/site/trunk/content/jena/documentation/assembler/index.mdtext?rev=1166468&view=auto
==============================================================================
--- incubator/jena/site/trunk/content/jena/documentation/assembler/index.mdtext (added)
+++ incubator/jena/site/trunk/content/jena/documentation/assembler/index.mdtext Wed Sep 7 23:36:07 2011
@@ -0,0 +1,102 @@
+Title: Jena assembler quickstart
+
+Jena's assembler provides a means of constructing Jena models
+according to a recipe, where that recipe is itself stated in
+RDF. This is the Assembler quickstart page. For more detailed
+information, see the [Assembler howto](assembler-howto.html)
+or [Inside assemblers](inside-assemblers.html).
+
+## What is an Assembler specification?
+
+An Assembler *specification* is an RDF description of how to
+construct a model and its associated resources, such as reasoners,
+prefix mappings, and initial content. The Assembler vocabulary is
+given in the [Assembler schema](../../vocabularies/assembler.n3),
+and we'll use the prefix `ja` for its identifiers.
+
+## What is an Assembler?
+
+An *Assembler* is an object that implements the `Assembler`
+interface and can construct objects (typically models) from
+Assembler specifications. The constant `Assembler.general` is an
+Assembler that knows how to construct some general patterns
+of model specification.
+
+## How can I make a model according to a specification?
+
+Suppose the Model `M` contains an Assembler specification whose
+*root* - the Resource describing the whole Model to construct is
+`R` (so `R.getModel() == M)`. Invoke:
+
+ Assembler.general.openModel(R)
+
+The result is the desired Model. Further details about the
+`Assembler` interface, the special Assembler `general`, and the
+details of specific Assemblers, are deferred to the
+[Assembler howto](assembler-howto.html).
+
+## How can I specify ...
+
+In the remaining sections, the object we want to describe is given
+the root resource `my:root`.
+
+### ... a memory model?
+
+ my:root a ja:MemoryModel.
+
+### ... an inference model?
+
+ my:root
+ ja:reasoner [ja:reasonerURL theReasonerURL] ;
+ ja:baseModel theBaseModelResource
+ .
+
+*theReasonerURL* is one of the reasoner (factory) URLs given in the
+inference documentation and code; *theBaseModelResource* is another
+resource in the same document describing the base model.
+
+### ... a database model?
+
+ my:root
+ ja:connection aConnectionresource ;
+ ja:modelName "myModelName"
+ .
+
+ aConnectionResource ;
+ ja:dbURL theDatabaseURL ;
+ ja:dbUser "the user name" ;
+ ja:dbPassword "the user's password" ;
+ ja:dbType "the database type, eg MySQL" ;
+ ja:dbClass "some.jena.driver.class"
+ .
+
+*aConnectionResource* describes the connection to the desired
+database. If a particular Java driver class has to be loaded, it is
+specified by the `dbClass` property value. See the
+[Assembler howto](assembler-howto.html) for ways in which sensitive
+details such as passwords can be left out of the description.
+
+### ... some initialising content?
+
+ my:root
+ ja:content [ja:externalContent <someContentURL>]
+ ... rest of model specification ...
+ .
+
+The model will be pre-loaded with the contents of *someContentURL*.
+
+### ... an ontology model?
+
+ my:root
+ ja:ontModelSpec ja:OntModelSpecName ;
+ ja:baseModel somebaseModel
+ .
+
+The *OntModelSpecName* can be any of the predefined Jena
+OntModelSpec names, eg `OWL_DL_MEM_RULE_INF`. The baseModel is
+another model description - it can be left out, in which case you
+get an empty memory model. See
+[Assembler howto](assembler-howto.html) for construction of
+non-predefined OntModelSpecs.
+
+
Added: incubator/jena/site/trunk/content/jena/documentation/assembler/inside-assemblers.mdtext
URL: http://svn.apache.org/viewvc/incubator/jena/site/trunk/content/jena/documentation/assembler/inside-assemblers.mdtext?rev=1166468&view=auto
==============================================================================
--- incubator/jena/site/trunk/content/jena/documentation/assembler/inside-assemblers.mdtext (added)
+++ incubator/jena/site/trunk/content/jena/documentation/assembler/inside-assemblers.mdtext Wed Sep 7 23:36:07 2011
@@ -0,0 +1,257 @@
+Title: Inside assemblers
+
+This document describes Jena's built-in assembler classes and how
+to write and integrate your own assemblers. If you just need a
+quick guide to the common model specifications, see the
+[assembler quickstart](index.html); if you want mroe details on
+writing assembler descriptions, see the
+[assembler howto](assembler-howto.html).
+
+## The Assembler interface
+
+An `Assembler` is an object that builds objects (most importantly,
+`Model`s) from RDF descriptions.
+
+ public Object open( Assembler a, Resource root, Mode mode );
+
+ public Object open( Assembler a, Resource root );
+
+ public Object open( Resource root );
+
+ public Model openModel( Resource root );
+
+ public Model openModel( Resource root, Mode mode );
+
+The fundamental method is the first: all the others are shorthands
+for ways of calling it. The abstract class `AssemblerBase`
+implements `Assembler` leaving only that method abstract and
+defining the others in terms of it.
+
+The definition of `a.open(Assembler sub, Resource root, Mode mode)`
+is that `a` will construct the object described by the properties
+of `root`. If this requires the construction of sub-objects from
+descriptions hanging off `root`, `sub.open` is to be used to
+construct those. If the object is to be constructed in some
+persistent store, `mode` defines whether objects can be re-used or
+created: see [modes](#modes) for more details.
+
+## Builtin assemblers
+
+Jena comes with a collection of built-in assemblers: various
+*basic assemblers* and a composite *general assembler*. Each of
+these assemblers has a constant instance declared as a field of
+`Assembler`.
+
+Assembler | Result class | Type constant
+--------- | ------------ | --------------
+*Temporarily omitted as the source got scrambled by the Markdown import* **TODO**
+
+## Inside Assemblers
+
+`Assembler.general` is a particular implementation of the
+`Assembler` interface. An `Assembler` knows how to build the
+objects - not just models - described by an Assembler
+specification. The normal route into an Assembler is through the
+method:
+
+- open( Resource root ) ? Object
+
+The Assembler inspects the `root` resource properties and decides
+whether it can build an object with that description. If not, it
+throws an exception. Otherwise, it constructs and returns a
+suitable object.
+Since the creation of Models is the reason for the existence of
+Assemblers, there is a convenience wrapper method:
+
+- openModel( Resource root ) ? Model
+
+which constructs the object and checks that it's a Model before
+returning it.
+When an `Assembler` requires sub-objects (for example, when an
+InfModel Assembler requires a Reasoner object), it uses the
+method:
+
+- open( Assembler sub, Resource root ) ? Model
+
+passing in a suitable Assembler object. In fact the standard
+implementation of `open(root)` is just
+- open( this, root )
+
+passing in itself as the sub-assembler and having
+`open(Assembler,Resource)` be the place where all the work is done.
+(Amongst other things, this makes testing easier.)
+When working with named persistent objects (typically database
+models), sometimes you need to control whether new objects should
+be constructed or old models can be reused. There is an additional
+method
+
+- open( Assembler sub, Resource root, Mode mode )
+
+where the `Mode` argument controls the creation (or not) of
+persistent models. The mode is passed down to all sub-object
+creation. The standard implementation of `open(sub,root)` is just:
+- open( sub, root, Mode.DEFAULT )
+
+A `Mode` object has two methods:
+- permitCreateNew( Resource root, String name )
+- permitUseExisting( Resource root, String name )
+
+`root` is the root resource describing the object to be created or
+reused, and `name` is the name given to it. The result is `true`
+iff the permission is granted. `Mode.DEFAULT` permits the reuse of
+existing objects and denies the creation of new ones.
+There are four `Mode constants:`
+
+- Mode.DEFAULT - reuse existing objects
+- Mode.CREATE - create missing objects
+- Mode.REUSE - reuse existing objects
+- Mode.ANY - reuse existing objects, create missing ones
+
+Since the `Mode` methods are passed the resource root and name, the
+user can write specialised `Mode`s that look at the name or the
+other root properties to make their decision.
+Note that the Modes only apply to persistent objects, so *eg*
+MemoryModels or PrefixMappings ignore their Mode arguments.
+
+## Implementing your own assemblers
+
+(Temporary documentation pasted in from email; will be integrated
+and made nice RSN.)
+
+ You have to implement the Assembler interface, most straightforwardly
+ done by subclassing AssemblerBase and overriding
+
+ public Object open( Assembler a, Resource root, Mode mode );
+
+ because AssemblerBase both implements the boring methods that are
+ just specialisations of `open` and provides some utility methods
+ such as getting the values of unique properties. The arguments are
+
+ * a -- the assembler to use for any sub-assemblies
+ * root -- the resource in the assembler description for this object
+ * mode -- the persistent open vs create mode
+
+ The pattern is to look for the known properties of the root, use
+ those to define any sub-objects of the object you're assembling
+ (including using `a` for anything that's itself a structured
+ object) and then constructing a new result object from those
+ components.
+
+ Then you attach this new assembler object to its type in some
+ AssemblerGroup using that group's `implementWith` method. You
+ can attach it to the handy-but-public-and-shared group
+ `Assembler.general` or you can construct your own group. The
+ point about an AssemblerGroup is that it does the type-to-assembler
+ mapping for you -- and when an AssemblerGroup calls a component
+ assembler's `open` method, it passes /itself/ in as the `a` argument,
+ so that the invoked assembler has access to all of the component
+ assemblers of the Group.
+
+## basic assemblers
+
+There is a family of *basic assemblers*, each of which knows how to
+assemble a specific kind of object so long as they're given an
+Assembler that can construct their sub-objects. There are defined
+constants in `Assembler` for (an instance of) each of these basic
+assembler classes.
+
+produces | Class | Type | constant
+-------- | ----- | ---- | --------
+default models | DefaultModelAssembler | ja:DefaultModel | defaultModel
+memory models | MemoryModelAssembler | ja:MemoryModel | memoryModel
+inference models| InfModelAssembler | ja:InfModel | infModel
+RDB models | RDBModelAssembler | ja:RDBModel | rdbModel
+reasoners | ReasonerAssembler | ja:Reasoner | reasoner
+connection descriptions | ConnectionAssembler | ja:Connection | connection
+content | ContentAssembler | ja:Content | content
+ontology models | OntModelAssembler | ja:OntModel | ontModel
+rules | RuleSetAssembler | ja:RuleSet | rules
+union models | UnionModelAssembler | ja:UnionModel | unionModel
+prefix mappings | PrefixMappingAssembler | ja:PrefixMapping | prefixMapping
+file models | FileModelAssembler | ja:FileModel | fileModel
+
+`Assembler.general` is an *assembler group*, which ties together
+those basic assemblers. `general` can be extended by Jena coders if
+required. Jena components that use Assembler specifications to
+construct objects will use `general` unless documented otherwise.
+
+In the remaining sections we will discuss the `Assembler` classes
+that return non-Model objects and conclude with a description of
+`AssemblerGroup`.
+
+### Basic assembler ContentAssembler
+
+The ContentAssembler constructs Content objects (using the
+`ja:Content` vocabulary) used to supply content to models. A
+Content object has the method:
+
+- fill( Model m ) ? m
+
+Invoking the `fill` method adds the represented content to the
+model. The supplied ModelAssemblers automatically apply the
+`Content` objects corresponding to `ja:content` property values.
+
+### Basic assembler ConnectionAssembler
+
+A ConnectionAssembler constructs ConnectionDescriptions according
+to the specification. An ConnectionDescription retains the
+information required to make a database connection, can constructs
+that connection on demand.
+
+When a ConnectionAssembler is constructed, it may optionally be
+given a Resource describing (using the JA vocabulary) default
+values for any of the database properties. When that Assembler is
+used to create a Connection, missing values are filled in from the
+defaults. This allows sensitive information to be left out of the
+RDF description.
+
+The ConnectionAssembler embedded in Assembler.general has defaults
+taken from the system properties `jena.dbUser` and `jena.dbType`
+
+### Basic assembler RulesetAssembler
+
+A RulesetAssembler generates lists of Jena rules.
+
+### Basic assembler DefaultModelAssembler
+
+A "default model" is a model of unspecified type which is
+implemented as whatever kind the assembler for `ja:DefaultModel`
+generates. The default for a DefaultModel is to create a
+MemoryModel with no special properties.
+
+### AssemblerGroup
+
+The AssemblerGroup class allows a bunch of other Assemblers to be
+bundled together and selected by RDF type. AssemblerGroup
+implements Assembler and adds the methods:
+
+- implementWith( Resource type, Assembler a ) ? this
+- assemblerFor( Resource type ) ? Assembler
+
+AssemblerGroup's implementation of `open(sub,root)` finds the
+*most specific type* of `root` that is a subclass of `ja:Object`
+and looks for the Assembler that has been associated with that type
+by a call of `implementWith`. It then delegates construction to
+that Assembler, passing *itself* as the sub-assembler. Hence each
+component Assembler only needs to know how to assemble its own
+particular objects.
+
+The `assemblerFor` method returns the assembler associated with the
+argument type by a previous call of `implementWith`, or `null` if
+there is no associated assembler.
+
+### Loading assembler classes
+
+AssemblerGroups implement the `ja:assembler` functionality. The
+object of an `(type ja:assembler "ClassName")` statement is a
+string which is taken as the name of an `Assembler` implementation
+to load. An instance of that class is associated with `type` using
+`implementWith`.
+
+If the class has a constructor that takes a single `Resource`
+object, that constructor is used to initialise the class, passing
+in the `type` subject of the triple. Otherwise the no-argument
+constructor of the class is used.
+
+
+
Modified: incubator/jena/site/trunk/templates/sidenav.mdtext
URL: http://svn.apache.org/viewvc/incubator/jena/site/trunk/templates/sidenav.mdtext?rev=1166468&r1=1166467&r2=1166468&view=diff
==============================================================================
--- incubator/jena/site/trunk/templates/sidenav.mdtext (original)
+++ incubator/jena/site/trunk/templates/sidenav.mdtext Wed Sep 7 23:36:07 2011
@@ -32,7 +32,7 @@
# Tutorials
- [RDF tutorial](/jena/tutorials/index.html)
- [SPARQL queries](/jena/tutorials/sparql.html)
- - [Using Jena with Eclipse](/jena/tutorials/using_jena_with_eclipse.html)
+ - [Using Jena with Eclipse](/jena/tutorials/using\_jena\_with\_eclipse.html)
# Documentation
- [Overview](/jena/documentation/index.html)
@@ -45,6 +45,9 @@
- [Serving Data](/jena/documentation/serving_data/index.html)
- [Ontology](/jena/documentation/ontology/index.html)
- [Inference](/jena/documentation/inference/index.html)
+ - [Assembler](/jena/documentation/assembler/index.html)
+ - [Assembler how-to](/jena/documentation/assembler/assembler-howto.html)
+ - [Inside assemblers](/jena/documentation/assembler/inside-assemblers.html)
- [Tools](/jena/documentation/tools/index.html)
- [schemagen](/jena/documentation/tools/schemagen.html)