jena-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r793967 [2/3] - in /websites/staging/jena/trunk/content/jena: ./ about_jena/ documentation/ontology/ getting_involved/ images/
Date Sun, 07 Aug 2011 22:55:42 GMT
Modified: websites/staging/jena/trunk/content/jena/documentation/ontology/index.html
==============================================================================
--- websites/staging/jena/trunk/content/jena/documentation/ontology/index.html (original)
+++ websites/staging/jena/trunk/content/jena/documentation/ontology/index.html Sun Aug  7 22:55:41 2011
@@ -20,7 +20,7 @@
 -->
 
   <link href="/jena/css/jena.css" rel="stylesheet" type="text/css">
-  <title>Apache Jena - </title>
+  <title>Apache Jena - Jena Ontology API</title>
   <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
   <script src="/jena/js/jquery-1.6.1.min.js" type="text/javascript"></script>
   <script src="/jena/js/jena-navigation.js" type="text/javascript"></script>
@@ -122,8 +122,2174 @@
   </div>
 
   <div id="content">
-    <h1 class="title"></h1>
-    <p>Ontology index page</p>
+    <h1 class="title">Jena Ontology API</h1>
+    <p>This section is a general introduction to the the Jena2
+ontology API, including some of the common tasks you may need
+to perform. We
+won't go into all of the many details of the API here: you should
+expect to refer to the <a href="/java/documentation/javadoc/">Javadoc</a> to
+get full details of the capabilities of the API.</p>
+<h2 id="prerequisites">Prerequisites</h2>
+<p>We'll assume that you have a basic familiarity with RDF and with
+Jena. If not, there are other
+<a href="/jena/getting_started">Jena help documents</a> you can read for background
+on these topics, and a <a href="/jena/tutorials">collection of tutorials</a>.</p>
+<p>Jena is a programming toolkit, using the Java programming language.
+While there are a few command-line tools to help you perform some
+key tasks using Jena, mostly you use Jena by writing Java programs.
+The examples in this document will be primarily code samples.</p>
+<p>We also won't be explaining the OWL or RDFS ontology languages in
+much detail in this document. You should expect to refer to
+supporting documentation for details on those languages, for
+example the <a href="http://www.w3.org/2004/OWL/">W3C OWL document index</a>.</p>
+<p><strong>Note:</strong> Although OWL version 1.1 is now a W3C recommendation,
+Jena's support for OWL 1.1 features is limited. We will be addressing
+this in future versions Jena.</p>
+<h2 id="overview">Overview</h2>
+<p>The section of the manual is broken into a number of sections. You
+do not need to read them in sequence, though later sections may
+refer to concepts and techniques introduced in earlier sections.
+The sections are:</p>
+<ol>
+<li>Overview</li>
+<li><a href="#generalConcepts">General concepts</a></li>
+<li><a href="#eswcExample">Running example: the ESWC ontology</a></li>
+<li><a href="#creatingModels">Creating ontology models</a></li>
+<li><a href="#documentHandling">Compound ontology documents and imports processing</a></li>
+<li><a href="#ontResource">The generic ontology type: OntResource</a></li>
+<li><a href="#classesBasic">Ontology classes and basic class expressions</a></li>
+<li><a href="#properties">Ontology properties</a></li>
+<li><a href="#classesComplex">More complex class expressions</a></li>
+<li><a href="#instances">Instances or individuals</a></li>
+<li><a href="#metadata">Ontology meta-data</a></li>
+<li><a href="#inferenceIntro">Ontology inference: overview</a></li>
+<li><a href="#legacyDAML">Working with DAML+OIL ontologies</a></li>
+<li><a href="#persistence">Working with persistent ontologies</a></li>
+<li><a href="#ontTools">Experimental ontology tools</a></li>
+<li><a href="common-problems.html">Common ontology application problems and sample programs</a></li>
+</ol>
+<h3 id="further_assistance">Further assistance</h3>
+<p>Hopefully, this document will be sufficient to help most readers
+to get started using the Jena ontology API. For further support,
+please post questions to the <a href="/jena/help_and_support">Jena support list</a>,
+or <a href="/jena/help_and_support/bugs_and_suggestions.html">file a bug report</a>.</p>
+<p><em>Please note that we ask that you use the support list or the bug-tracker
+to communicate with the Jena team, rather than send email to the team
+members directly. This helps us manage Jena support more effectively,
+and facilitates contributions from other Jena community members.</em></p>
+<h2 id="general_concepts">General concepts</h2>
+<p>In a widely-quoted definition, an ontology is</p>
+<blockquote>
+<p>"a specification of a conceptualization"
+[<a href="http://www-ksl.stanford.edu/kst/what-is-an-ontology.html">Gruber, T.</a> 1993]</p>
+</blockquote>
+<p>Let's unpack that brief characterisation a bit. An
+ontology allows a programmer to specify, in an open, meaningful,
+way, the concepts and relationships that collectively characterise
+some domain of interest. Examples might be the concepts of red and white wine,
+grape varieties, vintage years, wineries and so forth that
+characterise the domain of 'wine', and relationships such as
+'wineries produce wines', 'wines have a year of production'. This
+<em>wine ontology</em> might be developed initially for a particular
+application, such as a stock-control system at a wine warehouse. As
+such, it may be considered similar to a well-defined database
+schema. The advantage to an ontology is that it is an explicit,
+first-class description. So having been developed for one purpose,
+it can be published and reused for other purposes. For example, a
+given winery may use the wine ontology to link its production
+schedule to the stock system at the wine warehouse. Alternatively,
+a wine recommendation program may use the wine ontology, and a
+description (ontology) of different dishes to recommend wines for a
+given menu.</p>
+<p>There are many ways of writing down an ontology, and a variety of
+opinions as to what kinds of definition should go in one. In
+practice, the contents of an ontology are largely driven by the
+kinds of application it will be used to support. In Jena, we do not
+take a particular view on the minimal or necessary components of an
+ontology. Rather, we try to support a variety of common techniques.
+In this section, we try to explain what is &ndash; and to some extent what
+isn't &ndash; possible using Jena's ontology support.</p>
+<p>Since Jena is fundamentally an RDF platform, Jena's ontology
+support is limited to ontology formalisms built on top of RDF.
+Specifically this means <a href="http://en.wikipedia.org/wiki/RDFS">RDFS</a>,
+the varieties of
+<a href="http://en.wikipedia.org/wiki/Web_Ontology_Language">OWL</a>, and the
+now-obsolete <a href="http://en.wikipedia.org/wiki/DAML+OIL">DAML+OIL</a>. We
+will provide a very brief introduction to these languages here,
+but please refer to the extensive on-line documentation for these
+formalisms for complete and authoritative details.</p>
+<h3 id="rdfs">RDFS</h3>
+<p>RDFS is the weakest ontology language supported by Jena. RDFS
+allows the ontologist to build a simple hierarchy of concepts, and
+a hierarchy of properties. Consider the following trivial
+characterisation (with apologies to biology-trained readers!):</p>
+<p><img alt="image of simple class hierarchy" src="simple-hierarchy.png" title="Table 1: A simple concept hierarchy" />
+<br />Table 1: A simple concept hierarchy</p>
+<p>Using RDFS, we can say that my ontology has five <em>classes</em>, and that
+<code>Plant</code> is a <em>sub-class of</em> <code>Organism</code> and so on. So every animal
+is also an organism. A good way to think of these classes is as
+describing sets of <em>individuals</em>: organism is intended to describe
+a set of living things, some of which are animals (i.e. a sub-set
+of the set of organisms is the set of animals), and some animals
+are fish (a subset of the set of all animals is the set of all
+fish).</p>
+<p>To describe the attributes of these classes, we can associate
+<em>properties</em> with the classes. For example, animals have sensory
+organs (noses, eyes, etc.). A general property of an animal might
+be <code>senseOrgan</code>, to denote any given sensory organs a particular
+animal has. In general, fish have eyes, so a fish might have a
+<code>eyes</code> property to refer to a description of the particular eye
+structure of some species. Since eyes are a type of sensory organ,
+we can capture this relationship between these properties by saying
+that <code>eye</code> is a sub-property-of <code>senseOrgan</code>. Thus if a given fish
+has two eyes, it also has two sense organs. (It may have more, but
+we know that it must have two).</p>
+<p>We can describe this simple hierarchy with RDFS. In general, the
+class hierarchy is a graph rather than a tree (i.e. not like Java
+class inheritance). The
+<a href="http://en.wikipedia.org/wiki/Slime_mold">slime mold</a> is popularly,
+though perhaps not accurately, thought of as an organism that has
+characteristics of both plants and animals. We might model a slime
+mold in our ontology as a class that has both plant and animal
+classes among its super-classes. RDFS is too weak a language to
+express the constraint that a thing cannot be both a plant and an animal (which is
+perhaps lucky for the slime molds). In RDFS, we can only name the
+classes, we cannot construct expressions to describe interesting
+classes. However, for many applications it is sufficient to state
+the basic vocabulary, and RDFS is perfectly well suited to this.</p>
+<p>Note also that we can both describe classes, in general terms, and I
+can describe particular <em>instances</em> of those classes. So there may
+be a particular individual Fred who is a Fish (i.e. has
+<code>rdf:type Fish</code>), and who has two eyes. His companion Freda, a
+<a href="http://en.wikipedia.org/wiki/Mexican_tetra">Mexican Tetra</a>, or
+blind cave fish, has no eyes. One use of an ontology is to allow us
+to fill-in missing information about individuals. Thus, though it
+is not stated directly, we can deduce that Fred is also an Animal
+and an Organism. Assume that there was no <code>rdf:type</code> asserting that
+Freda is a Fish. We may still infer Freda's <code>rdf:type</code> since Freda
+has <a href="http://en.wikipedia.org/wiki/Lateral_line">lateral lines</a> as
+sense organs, and these only occur in fish. In RDFS, we state that
+the <em>domain</em> of the <code>lateralLines</code> property is the <code>Fish</code> class, so
+an RDFS reasoner can infer that Freda must be a fish.</p>
+<h3 id="owl">OWL</h3>
+<p>In general, OWL allows us to say everything that RDFS allows, and
+much more besides. A key part of OWL is the ability to describe
+classes in more interesting and complex ways. For example, in OWL
+we can say that Plant and Animal are <em>disjoint classes</em>: no
+individual can be both a plant and an animal (which would have the
+unfortunate consequence of making <code>SlimeMold</code> an empty class).
+<code>SaltwaterFish</code> might be the <em>intersection</em> of <code>Fish</code> and the class
+<code>SeaDwellers</code> (which also includes, for example, cetaceans and sea
+plants).</p>
+<p>Suppose we have a property <code>covering</code>, intended to represent the
+scales of a fish or the fur of a mammal. We can now refine the
+mammal class to be 'animals that have a covering that is hair',
+using a <em>property restriction</em> to express the condition that
+property <code>covering</code> has a value from the class <code>Hair</code>. Similarly
+<code>TropicalFish</code> might be the intersection of the class of <code>Fish</code> and
+the class of things that have <code>TropicalOcean</code> as their habitat.</p>
+<p>Finally (for this brief overview), we can say more about properties
+in OWL. In RDFS, properties can be related via a property
+hierarchy. OWL extends this by allowing properties to be denoted as
+<em>transitive</em>, <em>symmetric</em> or <em>functional</em>, and allow one property
+to be declared to be the <em>inverse</em> of another. OWL also makes a
+distinction between properties that have individuals (RDF resources)
+as their range and properties that have data-values (known as
+<em>literals</em> in RDF terminology) as their range.
+Respectively these are <em>object properties</em> and <em>datatype properties</em>.
+One consequence of the RDF lineage of OWL is
+that OWL ontologies cannot make statements about literal values. We
+cannot say in RDF that <code>seven</code> has the property of being a prime number.
+We can, of course, say that the class of primes includes seven, doing so
+doesn't require a number to be the subject of an RDF statement. In
+OWL, this distinction is important: only object properties can
+be transitive or symmetric.</p>
+<p>The OWL language is sub-divided into three syntax classes:
+<em>OWL Lite</em>, <em>OWL DL</em> and <em>OWL Full</em>. OWL DL does not permit some
+constructions allowed in OWL Full, and OWL Lite has all the
+constraints of OWL DL plus some more. The intent for OWL Lite and
+OWL DL is to make the task of reasoning with expressions in that
+subset more tractable. Specifically, OWL DL is intended to be able
+to be processed efficiently by a
+<a href="http://en.wikipedia.org/wiki/Description_logic"><em>description logic</em></a>
+reasoner. OWL Lite is intended to be amenable to processing by a
+variety of reasonably simple inference algorithms, though experts
+in the field have challenged how successfully this has been
+achieved.</p>
+<p>While the OWL standards documents note that OWL builds on top of
+the (revised) RDF specifications, it is possible to treat OWL as a
+separate language in its own right, and not something that is built
+on an RDF foundation. This view uses RDF as a serialisation syntax;
+the RDF-centric view treats RDF triples as the core of the OWL
+formalism. While both views are valid, in Jena we take the
+RDF-centric view.</p>
+<h3 id="damloil">DAML+OIL</h3>
+<p>DAML+OIL is very similar to OWL Full. This is not surprising, since
+the W3C's Web Ontology Working Group, who designed OWL, took
+DAML+OIL as their starting point. Some constructions in OWL have
+been added to the capabilities of DAML+OIL, and one or two have
+been removed. For the purposes of this brief overview, however, the
+expressiveness of DAML+OIL is comparable to that of OWL.</p>
+<p><strong>Note:</strong> DAML+OIL is effectively now obsolete. While you can still
+find some DAML ontologies on the web, you should work with OWL or
+RDFS to maximise the longevity of your models.</p>
+<h3 id="ontology_languages_and_the_jena_ontology_api">Ontology languages and the Jena Ontology API</h3>
+<p>As we outlined above, there are various different ontology languages
+available for representing ontology information on the semantic
+web. They range from the most expressive, OWL Full, through to the
+weakest, RDFS. Through the Ontology API, Jena aims to provide a
+consistent programming interface for ontology application
+development, independent of which ontology language you are using
+in your programs.</p>
+<p>The Jena Ontology API is language-neutral: the Java class names do
+not mention the underlying language. For example, the <code>OntClass</code>
+Java class can represent an OWL class, RDFS class, or DAML class.
+To represent the differences between the various representations,
+each of the ontology languages has a <em>profile</em>, which lists the
+permitted constructs and the names of the classes and properties.
+Thus in the DAML profile, the URI for object property is
+<code>daml:ObjectProperty</code> (short for
+<code>http://www.daml.org/2001/03/daml+oil#ObjectProperty</code>), in the OWL
+profile is it <code>owl:ObjectProperty</code> (short for
+<code>http://www.w3.org/2002/07/owl#ObjectProperty</code>) and in the RDFS
+profile it is <code>null</code> since RDFS does not define object properties.</p>
+<p>The profile is bound to an <em>ontology model</em>, which is an extended
+version of Jena's
+<a href="/jena/documentation/javadoc/com/hp/hpl/jena/rdf/model/Model.html"><code>Model</code></a> class.
+The base <code>Model</code> allows access to the statements in a collection of
+RDF data.
+<a href="/jena/documentation/javadoc/com/hp/hpl/jena/ontology/OntModel.html"><code>OntModel</code></a>
+extends this by adding support for the kinds of objects expected to
+be in an ontology: classes (in a class hierarchy), properties (in a
+property hierarchy) and individuals.</p>
+<p>When you're working with an
+ontology in Jena, all of the state information remains encoded as
+RDF triples (accessed as Jena
+<a href="/jena/documentation/javadoc/com/hp/hpl/jena/rdf/model/Statement.html"><code>Statement</code>s</a>) stored in the RDF
+model. The ontology API
+doesn't change the RDF representation of ontologies. What it does
+do is add a set of convenience classes and methods that make it
+easier for you to write programs that manipulate the underlying RDF
+triples.</p>
+<p>The predicate names defined in the ontology language correspond to
+the accessor methods on the Java classes in the API. For example,
+an <code>OntClass</code> has a method to list its super-classes, which
+corresponds to the values of the <code>subClassOf</code> property in the RDF
+representation. This point is worth re-emphasising: no information
+is stored in the <code>OntClass</code> object itself. When you call the
+OntClass <code>listSuperClasses()</code> method, Jena will retrieve the
+information from the underlying RDF statements. Similarly adding a
+subclass to an <code>OntClass</code> asserts an additional RDF statement into
+the model.</p>
+<h3 id="ontologies_and_reasoning">Ontologies and reasoning</h3>
+<p>One of the key benefits of building an ontology-based application
+is using a reasoner to derive additional truths about the concepts
+you are modelling. We saw a simple instance of this above: the
+assertion "Fred is a Fish" <em>entails</em> the deduction "Fred is an
+Animal". There are many different styles of automated reasoner, and
+very many different reasoning algorithms. Jena includes support for
+a variety of reasoners through the
+<a href="../inference">inference API</a>.</p>
+<p>A common feature of Jena
+reasoners is that they create a new RDF model, which appears to
+contain the triples that are derived from reasoning, as well as the
+triples that were asserted in the base model. This extended model
+nevertheless still conforms to the contract for Jena models.
+It can be used wherever a non-inference model can be used. The ontology
+API exploits this feature: the convenience methods the ontology API
+provides can query an extended inference model in just the same way
+as a plain RDF model. In fact, this is such a common pattern that
+we provide simple recipes for constructing ontology models whose
+language, storage model and reasoning engine can all be simply
+specified when an <code>OntModel</code> is created. We'll show examples shortly.</p>
+<p>Figure 2 shows one way of visualising this:</p>
+<p><img alt="image of layering of graphs in model" src="ont-model-layers.png" title="Figure 2: the statements seen by the OntModel" /></p>
+<p><code>Graph</code> is an internal Jena interface that supports the composition
+of sets of RDF triples. The asserted statements, which may have
+been read in from an ontology document, are held in the base graph.
+The reasoner, or inference engine, can use the contents of the base
+graph and the semantic rules of the language to show a more
+complete set of statements. This is also presented via a <code>Graph</code>
+interface, so the model works only with the outermost interface.
+This regularity allows us to very easily build ontology models with
+or without a reasoner. It also means that the base graph can be an
+in-memory store, a database-backed persistent store, or some other
+storage structure altogether (e.g. an LDAP directory) again without
+affecting the operation of the ontology model.</p>
+<h3 id="rdf-level_polymorphism_and_java">RDF-level polymorphism and Java</h3>
+<p>Deciding which Java abstract class to use to represent a given RDF
+resource can be surprisingly subtle. Consider the following RDF
+sample:</p>
+<div class="codehilite"><pre><span class="nt">&lt;owl:Class</span> <span class="na">rdf:ID=</span><span class="s">&quot;DigitalCamera&quot;</span><span class="nt">&gt;</span>
+<span class="nt">&lt;/owl:Class&gt;</span>
+</pre></div>
+
+
+<p>This declares that the resource with the relative URI
+<code>#DigitalCamera</code> is an OWL ontology class. It suggests that it
+would be appropriate to model that declaration in Java with an
+instance of an <code>OntClass</code>. Now suppose we add a triple to the RDF
+model to augment the class declaration with some more information:</p>
+<div class="codehilite"><pre><span class="nt">&lt;owl:Class</span> <span class="na">rdf:ID=</span><span class="s">&quot;DigitalCamera&quot;</span><span class="nt">&gt;</span>
+  <span class="nt">&lt;rdf:type</span> <span class="err">owl:Restriction</span> <span class="nt">/&gt;</span>
+<span class="nt">&lt;/owl:Class&gt;</span>
+</pre></div>
+
+
+<p>Now we are stating that <code>#DigitalCamera</code> is an OWL Restriction.
+Restriction is a subclass of <code>owl:Class</code>, so this is a perfectly
+consistent operation. The problem we then have is that Java does not
+allow us to dynamically change the Java class of the object
+representing this resource. The resource has not changed: it still
+has URI <code>#DigitalCamera</code>. But the appropriate Java class Jena might
+choose to model it has changed from <code>OntClass</code> to <code>Restriction</code>.
+Conversely, if we subsequently remove the <code>rdf:type owl:Restriction</code>
+from the model, using the <code>Restriction</code> Java class is no longer
+appropriate.</p>
+<p>Even worse, OWL Full allows us to state the following (rather
+counter-intuitive) construction:</p>
+<div class="codehilite"><pre><span class="nt">&lt;owl:Class</span> <span class="na">rdf:ID=</span><span class="s">&quot;DigitalCamera&quot;</span><span class="nt">&gt;</span>
+  <span class="nt">&lt;rdf:type</span> <span class="err">owl:ObjectProperty</span> <span class="nt">/&gt;</span>
+<span class="nt">&lt;/owl:Class&gt;</span>
+</pre></div>
+
+
+<p>That is, <code>#DigitalCamera</code> is both a class <em>and</em> a property. While
+this may not be a very useful operation, it illustrates a basic
+point: we cannot rely on a consistent or unique mapping between an
+RDF resource and the appropriate Java abstraction.</p>
+<p>Jena accepts this basic characteristic of polymorphism at the RDF
+level by considering that the Java abstraction (<code>OntClass</code>,
+<code>Restriction</code>, <code>DatatypeProperty</code>, etc.) is just a view or <em>facet</em>
+of the resource. That is, there is a one-to-many mapping from a
+resource to the facets that the resource can present. If the
+resource is typed as an <code>owl:Class</code>, it can present the <code>OntClass</code>
+facet; given other types, it can present other facets. Jena
+provides the <code>.as()</code> method to efficiently map from an RDF object
+to one of its allowable facets. Given a RDF object (i.e. an
+instance of <code>com.hp.hpl.jena.rdf.model.RDFNode</code> or one of its
+sub-types), you can get a facet by invoking <code>as()</code> with an argument
+that denotes the facet required. Specifically, the facet is
+identified by the Java class object of the desired facet. For
+example, to get the <code>OntClass</code> facet of a resource, we can write:</p>
+<div class="codehilite"><pre><span class="n">Resource</span> <span class="n">r</span> <span class="o">=</span> <span class="n">myModel</span><span class="o">.</span><span class="n">getResource</span><span class="p">(</span> <span class="n">myNS</span> <span class="o">+</span> <span class="s">&quot;DigitalCamera&quot;</span> <span class="p">);</span>
+<span class="n">OntClass</span> <span class="n">cls</span> <span class="o">=</span> <span class="p">(</span><span class="n">OntClass</span><span class="p">)</span> <span class="n">r</span><span class="o">.</span><span class="n">as</span><span class="p">(</span> <span class="n">OntClass</span><span class="o">.</span><span class="n">class</span> <span class="p">);</span>
+</pre></div>
+
+
+<p>This pattern allows us to defer decisions about the correct Java
+abstraction to use until run-time. The choice can depend on the
+properties of the resource itself. If a given <code>RDFNode</code> will not
+support the conversion to a given facet, it will raise a
+<code>ConversionException</code>. We can test whether <code>.as()</code> will succeed for a
+given facet with <code>canAs()</code>. This RDF-level polymorphism is used
+extensively in the Jena ontology API to allow maximum flexibility
+in handling ontology data.</p>
+<h2 id="running_example_the_eswc_ontology">Running example: the ESWC ontology</h2>
+<p>To illustrate the principles of using the ontology API, we will use
+examples drawn from Tom Heath's
+<a href="http://www.schemaweb.info/schema/SchemaDetails.aspx?id=282">ESWC ontology</a>.
+This ontology presents a simple model for describing the concepts
+and activities associated with a typical academic conference. A
+copy of the ontology serialized in RDF/XML is included with the
+Jena download, see:
+[<a href="TODO"><code>eswc-2006-09-21.rdf</code></a>]
+(note that you may need to view the page source in some browsers to
+see the XML code).</p>
+<p>A subset of the classes and properties from the ontology are shown
+in Figure 3:</p>
+<p><img alt="Image of the example class hierarchy" src="eswc-classes.png" title="Figure 3: Classes and properties from ESWC ontology" />
+<br />Figure 3: Classes and properties from ESWC ontology</p>
+<p>We will use elements from this ontology to illustrate the ontology
+API throughout the rest of this document.</p>
+<h2 id="creating_ontology_models">Creating ontology models</h2>
+<p>An ontology model is an extension of the Jena RDF model,
+providing extra capabilities for handling ontologies. Ontology
+models are created through the Jena
+<a href="/jena/documentation/javadoc/com/hp/hpl/jena/rdf/model/ModelFactory.html"><code>ModelFactory</code></a>.
+The simplest way to create an ontology model is as follows:</p>
+<div class="codehilite"><pre><span class="n">OntModel</span> <span class="n">m</span> <span class="o">=</span> <span class="n">ModelFactory</span><span class="o">.</span><span class="n">createOntologyModel</span><span class="p">();</span>
+</pre></div>
+
+
+<p>This will create an ontology model with the <em>default</em> settings,
+which are set for maximum compatibility with the previous version
+of Jena. These defaults are:</p>
+<ul>
+<li>OWL-Full language</li>
+<li>in-memory storage</li>
+<li>RDFS inference, which principally produces entailments from the
+    sub-class and sub-property hierarchies.</li>
+</ul>
+<p><strong>Important note</strong>: this means that the <em>default ontology model</em> <strong>does</strong>
+include some inferencing, with both consequences for the peformance of the
+model, and for the triples which appear in the model.</p>
+<p>In many applications, such as driving a GUI, RDFS inference is too
+strong (for example, every class is inferred to be an immediate sub-class of
+<code>owl:Thing</code>). In other applications, stronger reasoning is needed.
+In general, to create an <code>OntModel</code> with a particular reasoner or
+language profile, you should pass a model specification to the
+<code>createOntologyModel</code> call. For example, an OWL model that performs
+no reasoning at all can be created with:</p>
+<div class="codehilite"><pre><span class="n">OntModel</span> <span class="n">m</span> <span class="o">=</span> <span class="n">ModelFactory</span><span class="o">.</span><span class="n">createOntologyModel</span><span class="p">(</span> <span class="n">OntModelSpec</span><span class="o">.</span><span class="n">OWL_MEM</span> <span class="p">);</span>
+</pre></div>
+
+
+<p>To create an ontology model for a particular language, but leaving
+all of the other values as defaults, you should pass the URI of the
+ontology language to the model factory. The URI strings for the
+various language profiles are:</p>
+<table>
+<thead>
+<tr>
+<th>Ontology language</th>
+<th>URI</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td>RDFS</td>
+<td><code>http://www.w3.org/2000/01/rdf-schema#</code></td>
+</tr>
+<tr>
+<td>DAML+OIL</td>
+<td><code>http://www.daml.org/2001/03/daml+oil#</code></td>
+</tr>
+<tr>
+<td>OWL Full</td>
+<td><code>http://www.w3.org/2002/07/owl#</code></td>
+</tr>
+<tr>
+<td>OWL DL</td>
+<td><code>http://www.w3.org/TR/owl-features/#term_OWLDL</code></td>
+</tr>
+<tr>
+<td>OWL Lite</td>
+<td><code>http://www.w3.org/TR/owl-features/#term_OWLLite</code></td>
+</tr>
+</tbody>
+</table>
+<p>These URI's are used to look-up the language profile from the
+<a href="/jena/documentation/javadoc/com/hp/hpl/jena/ontology/ProfileRegistry.html"><code>ProfileRegistry</code></a>.
+The profile registry contains public constant declarationss so
+that you do not have to remember these URI's. Please note that the
+URI's denoting OWL Lite and OWL DL are not officially sanctioned by
+the OWL standard.</p>
+<p>To create an ontology model for handling DAML ontologies, use
+either of:</p>
+<div class="codehilite"><pre><span class="n">OntModel</span> <span class="n">m</span> <span class="o">=</span> <span class="n">ModelFactory</span><span class="o">.</span><span class="n">createOntologyModel</span><span class="p">(</span> <span class="n">OntModelSpec</span><span class="o">.</span><span class="n">DAML_MEM</span> <span class="p">);</span>
+<span class="n">OntModel</span> <span class="n">m</span> <span class="o">=</span> <span class="n">ModelFactory</span><span class="o">.</span><span class="n">createOntologyModel</span><span class="p">(</span> <span class="n">ProfileRegistry</span><span class="o">.</span><span class="n">DAML_LANG</span> <span class="p">);</span>
+</pre></div>
+
+
+<p>Beyond these basic choices, the complexities of configuring an
+ontology model are wrapped up in a recipe object called
+<code>&lt;a href="/jena/documentation/javadoc/com/hp/hpl/jena/ontology/OntModelSpec.html"&gt;OntModelSpec&lt;/a&gt;</code>.
+This specification allows complete control over the configuration
+choices for the ontology model, including the language profile in
+use, the reasoner, and the means of handling compound documents. A
+number of common recipes are pre-declared as constants in
+<code>OntModelSpec</code>, and listed below.</p>
+<table>
+<thead>
+<tr>
+<th>OntModelSpec</th>
+<th>Language profile</th>
+<th>Storage model</th>
+<th>Reasoner</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td>OWL_MEM</td>
+<td>OWL full</td>
+<td>in-memory</td>
+<td>none</td>
+</tr>
+<tr>
+<td>OWL_MEM_TRANS_INF</td>
+<td>OWL full</td>
+<td>in-memory</td>
+<td>transitive class-hierarchy inference</td>
+</tr>
+<tr>
+<td>OWL_MEM_RULE_INF</td>
+<td>OWL full</td>
+<td>in-memory</td>
+<td>rule-based reasoner with OWL rules</td>
+</tr>
+<tr>
+<td>OWL_MEM_MICRO_RULE_INF</td>
+<td>OWL full</td>
+<td>in-memory</td>
+<td>optimised rule-based reasoner with OWL rules</td>
+</tr>
+<tr>
+<td>OWL_MEM_MINI_RULE_INF</td>
+<td>OWL full</td>
+<td>in-memory</td>
+<td>rule-based reasoner with subset of OWL rules</td>
+</tr>
+<tr>
+<td>OWL_DL_MEM</td>
+<td>OWL DL</td>
+<td>in-memory</td>
+<td>none</td>
+</tr>
+<tr>
+<td>OWL_DL_MEM_RDFS_INF</td>
+<td>OWL DL</td>
+<td>in-memory</td>
+<td>rule reasoner with RDFS-level entailment-rules</td>
+</tr>
+<tr>
+<td>OWL_DL_MEM_TRANS_INF</td>
+<td>OWL DL</td>
+<td>in-memory</td>
+<td>transitive class-hierarchy inference</td>
+</tr>
+<tr>
+<td>OWL_DL_MEM_RULE_INF</td>
+<td>OWL DL</td>
+<td>in-memory</td>
+<td>rule-based reasoner with OWL rules</td>
+</tr>
+<tr>
+<td>OWL_LITE_MEM</td>
+<td>OWL Lite</td>
+<td>in-memory</td>
+<td>none</td>
+</tr>
+<tr>
+<td>OWL_LITE_MEM_TRANS_INF</td>
+<td>OWL Lite</td>
+<td>in-memory</td>
+<td>transitive class-hierarchy inference</td>
+</tr>
+<tr>
+<td>OWL_LITE_MEM_RDFS_INF</td>
+<td>OWL Lite</td>
+<td>in-memory</td>
+<td>rule reasoner with RDFS-level entailment-rules</td>
+</tr>
+<tr>
+<td>OWL_LITE_MEM_RULES_INF</td>
+<td>OWL Lite</td>
+<td>in-memory</td>
+<td>rule-based reasoner with OWL rules</td>
+</tr>
+<tr>
+<td>DAML_MEM</td>
+<td>DAML+OIL</td>
+<td>in-memory</td>
+<td>none</td>
+</tr>
+<tr>
+<td>DAML_MEM_TRANS_INF</td>
+<td>DAML+OIL</td>
+<td>in-memory</td>
+<td>transitive class-hierarchy inference</td>
+</tr>
+<tr>
+<td>DAML_MEM_RDFS_INF</td>
+<td>DAML+OIL</td>
+<td>in-memory</td>
+<td>rule reasoner with RDFS-level entailment-rules</td>
+</tr>
+<tr>
+<td>DAML_MEM_RULE_INF</td>
+<td>DAML+OIL</td>
+<td>in-memory</td>
+<td>rule-based reasoner with DAML rules</td>
+</tr>
+<tr>
+<td>RDFS_MEM</td>
+<td>RDFS</td>
+<td>in-memory</td>
+<td>none</td>
+</tr>
+<tr>
+<td>RDFS_MEM_TRANS_INF</td>
+<td>RDFS</td>
+<td>in-memory</td>
+<td>transitive class-hierarchy inference</td>
+</tr>
+<tr>
+<td>RDFS_MEM_RDFS_INF</td>
+<td>RDFS</td>
+<td>in-memory</td>
+<td>rule reasoner with RDFS-level entailment-rules</td>
+</tr>
+</tbody>
+</table>
+<p><strong><em> &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; TODO watermark </em></strong></p>
+<p>For details of reasoner capabilities, please see the
+<a href="../inference/index.html">inference documentation</a> and the Javadoc
+for
+<a href="/jena/documentation/javadoc/com/hp/hpl/jena/ontology/OntModelSpec.html">OntModelSpec</a>.
+See also further discussion <a href="#inferenceIntro">below</a>.</p>
+<p><strong>Note:</strong> it is primarily the choice of reasoner, rather than the
+choice of language profile, that determines which entailments are
+seen by the ontology model. However, using an OWL reasoner with
+DAML source data will result in few additional entailments being
+seen by the ontology model.</p>
+<p>To create a model with a given specification, you should invoke the
+<code>ModelFactory</code> as follows:</p>
+<div class="codehilite"><pre><span class="n">OntModel</span> <span class="n">m</span> <span class="o">=</span> <span class="n">ModelFactory</span><span class="o">.</span><span class="n">createOntologyModel</span><span class="p">(</span> <span class="o">&lt;</span><span class="n">model</span> <span class="n">spec</span><span class="o">&gt;</span> <span class="p">);</span>
+</pre></div>
+
+
+<p>for example:</p>
+<div class="codehilite"><pre><span class="n">OntModel</span> <span class="n">m</span> <span class="o">=</span> <span class="n">ModelFactory</span><span class="o">.</span><span class="n">createOntologyModel</span><span class="p">(</span> <span class="n">OntModelSpec</span><span class="o">.</span><span class="n">OWL_MEM_MICRO_RULE_INF</span> <span class="p">);</span>
+</pre></div>
+
+
+<p>To create a custom model specification, you can create a new one
+from its constructor, and call the various setter methods to set
+the appropriate values. More often, you want a variation on an
+existing recipe. In this case, you copy an existing specification
+and then update the copy as necessary:</p>
+<div class="codehilite"><pre><span class="n">OntModelSpec</span> <span class="n">s</span> <span class="o">=</span> <span class="k">new</span> <span class="n">OntModelSpec</span><span class="p">(</span> <span class="n">OntModelSpec</span><span class="o">.</span><span class="n">OWL_MEM</span> <span class="p">);</span>
+<span class="n">s</span><span class="o">.</span><span class="n">setDocumentManager</span><span class="p">(</span> <span class="n">myDocMgr</span> <span class="p">);</span>
+<span class="n">OntModel</span> <span class="n">m</span> <span class="o">=</span> <span class="n">ModelFactory</span><span class="o">.</span><span class="n">createOntologyModel</span><span class="p">(</span> <span class="n">s</span> <span class="p">);</span>
+</pre></div>
+
+
+<h2 id="compound_ontology_documents_and_imports_processing">Compound ontology documents and imports processing</h2>
+<p>The OWL and DAML ontology languages include some facilities for
+creating modular ontologies that can be re-used in a similar manner
+to software modules. In particular, one ontology can <em>import</em>
+another. Jena helps ontology developers to work with modular
+ontologies by automatically handling the imports statements in
+ontology models.</p>
+<p>The key idea is that the base model of an ontology model is
+actually a collection of models, one per imported model. That means
+we have to modify figure 2 a bit. Figure 4 shows how the ontology
+model builds a collection of import models:</p>
+<p><img alt="Diagram of compound document for imports" src="../images/Ont-model-layers-import.png" /></p>
+<p>Figure 4: ontology model compound document structure for imports</p>
+<p>I will use the term <em>document</em> to describe an ontology serialized
+in some transport syntax, such as RDF/XML or N3. This terminology
+isn't used by the OWL or RDFS standards, but it is a convenient way
+to refer to the written artifacts. However, from a broad view of
+the interlinked semantic web, a document view imposes artificial
+boundaries between regions of the global web of data.</p>
+<p>We will load an ontology document into an ontology model in the
+same way as a normal Jena model, using the <code>read</code> method. There are
+several variants on read, that handle differences in the source of
+the document (to be read from a resolvable URL or directly from an
+input stream or reader), the base URI that will resolve any
+relative URI's in the source document, and the serialisation
+language. In summary, these variants are:</p>
+<div class="codehilite"><pre><span class="nb">read</span><span class="p">(</span> <span class="n">String</span> <span class="n">url</span> <span class="p">)</span>
+<span class="nb">read</span><span class="p">(</span> <span class="n">Reader</span> <span class="n">reader</span><span class="p">,</span> <span class="n">String</span> <span class="n">base</span> <span class="p">)</span>
+<span class="nb">read</span><span class="p">(</span> <span class="n">InputStream</span> <span class="n">reader</span><span class="p">,</span> <span class="n">String</span> <span class="n">base</span> <span class="p">)</span>
+<span class="nb">read</span><span class="p">(</span> <span class="n">String</span> <span class="n">url</span><span class="p">,</span> <span class="n">String</span> <span class="n">lang</span> <span class="p">)</span>
+<span class="nb">read</span><span class="p">(</span> <span class="n">Reader</span> <span class="n">reader</span><span class="p">,</span> <span class="n">String</span> <span class="n">base</span><span class="p">,</span> <span class="n">String</span> <span class="n">Lang</span> <span class="p">)</span>
+<span class="nb">read</span><span class="p">(</span> <span class="n">InputStream</span> <span class="n">reader</span><span class="p">,</span> <span class="n">String</span> <span class="n">base</span><span class="p">,</span> <span class="n">String</span> <span class="n">Lang</span> <span class="p">)</span>
+</pre></div>
+
+
+<p>You can use any of these methods to load an ontology document. Note
+that we advise that you avoid the the <code>read()</code> variants that accept
+a <code>java.io.Reader</code> argument when loading XML documents containing
+internationalised character sets, since the handling of character
+encoding by the Reader and by XML parsers is not compatible.</p>
+<p>By default, when an ontology model reads an ontology document, it
+will also locate and load the document's imports. An OWL or DAML
+document may contain an individual of class <code>Ontology</code>, which
+contains meta-data about that document itself. For example:</p>
+<div class="codehilite"><pre><span class="nt">&lt;owl:Ontology</span> <span class="na">rdf:about=</span><span class="s">&quot;&quot;</span><span class="nt">&gt;</span>
+  <span class="nt">&lt;dc:creator</span> <span class="na">rdf:value=</span><span class="s">&quot;Ian Dickinson&quot;</span> <span class="nt">/&gt;</span>
+  <span class="nt">&lt;owl:imports</span> <span class="na">rdf:resource=</span><span class="s">&quot;http://jena.hpl.hp.com/example-ont&quot;</span> <span class="nt">/&gt;</span>
+<span class="nt">&lt;/owl:Ontology&gt;</span>
+</pre></div>
+
+
+<p>The construct <code>rdf:about=""</code> is a relative URI that will resolve to
+the document's base URI: in other words it's a shorthand way of
+referring to the document itself. The <code>owl:imports</code> line states
+that this ontology is constructed using classes, properties and
+individuals from the referenced ontology. When <code>OntModel</code> reads
+this document, it will notice the <code>owl:imports</code> line and attempt to
+load the imported ontology into a sub-model of the ontology model
+being built. The definitions from both the base ontology and all of
+the imports will be visible to the reasoner.</p>
+<p>Each imported ontology document is held in a separate graph
+structure. This is important: I want to keep the original source
+ontology separate from the imports. When I write the model out
+again, normally only the base model is written (the alternative is
+that all you see is a confusing union of everything). And when I
+update the model, only the base model changes.</p>
+<p>Imports are processed recursively, so if my base document imports
+ontology A, and A imports B, I will end up with the structure shown
+in Figure 4. Note that the imports have been flattened out. A cycle
+check is used to prevent the document handler getting stuck if, for
+example, A imports B which imports A!</p>
+<h3 id="the_ontology_document_manager">The ontology document manager</h3>
+<p>Each ontology model has an associated <em>document manager</em> that
+assists with the processing and handling of documents-related
+concerns. For convenience, there is one global document manager
+that is used by default by ontology models. You can get a reference
+to this shared instance through <code>OntDocumentManager.getInstance()</code>.
+In many cases, it will be sufficient to simply change the settings
+on the global document manager to suit your application's needs.
+However, for more fine-grain control, you can create separate
+document managers, and pass them to the ontology model when it is
+created through the model factory. To do this, create an ontology
+specification object (see above), and set the document manager. For
+example:</p>
+<div class="codehilite"><pre><span class="n">OntDocumentManager</span> <span class="n">mgr</span> <span class="o">=</span> <span class="k">new</span> <span class="n">OntDocumentManager</span><span class="p">();</span>
+<span class="sr">//</span> <span class="n">set</span> <span class="n">the</span> <span class="n">mgr</span><span class="err">&#39;</span><span class="n">s</span> <span class="n">properties</span> <span class="n">now</span>
+ <span class="err">…</span> <span class="n">some</span> <span class="n">code</span> <span class="err">…</span>
+<span class="sr">//</span> <span class="n">now</span> <span class="k">use</span> <span class="n">it</span>
+<span class="n">OntModelSpec</span> <span class="n">s</span> <span class="o">=</span> <span class="k">new</span> <span class="n">OntModelSpec</span><span class="p">(</span> <span class="n">OntModelSpec</span><span class="o">.</span><span class="n">RDFS_MEM</span> <span class="p">);</span>
+<span class="n">s</span><span class="o">.</span><span class="n">setDocumentManager</span><span class="p">(</span> <span class="n">mgr</span> <span class="p">);</span>
+<span class="n">OntModel</span> <span class="n">m</span> <span class="o">=</span> <span class="n">ModelFactory</span><span class="o">.</span><span class="n">createOntologyModel</span><span class="p">(</span> <span class="n">s</span> <span class="p">);</span>
+</pre></div>
+
+
+<p>Note that the model retains a reference to the document manager it
+was created with. Thus if you change a document manager's
+properties, it will affect models that have previously been
+constructed with that document manager.</p>
+<h3 id="document_manager_policy">Document manager policy</h3>
+<p>Since the document manager has a large number of configurable
+options, there are two ways in which you can customise it to your
+application requirements. Firstly, you can set the individual
+parameters of the document manager by Java code. Alternatively,
+when a given document manager is created it can load values for the
+various parameters from a policy file, expressed in RDF. The
+document manager has a list of URL's which it will search for a
+policy document. It will stop at the first entry on the list that
+resolves to a retrievable document. The default search path for the
+policy is: <code>file:./etc/ont-policy.rdf;file:ont-policy.rdf</code>. You can
+find the default policy, which can serve as a template for defining
+your own policies, in the <code>etc/</code> directory under the Jena download
+directory.</p>
+<p>You can set the general properties of the document manager in the
+policy as follows:</p>
+<div class="codehilite"><pre><span class="nt">&lt;DocumentManagerPolicy&gt;</span>
+  <span class="c">&lt;!-- policy for controlling the document manager&#39;s behaviour --&gt;</span>
+  <span class="nt">&lt;processImports</span> <span class="na">rdf:datatype=</span><span class="s">&quot;&amp;xsd;boolean&quot;</span><span class="nt">&gt;</span>true<span class="nt">&lt;/processImports&gt;</span>
+  <span class="nt">&lt;cacheModels</span> <span class="na">rdf:datatype=</span><span class="s">&quot;&amp;xsd;boolean&quot;</span><span class="nt">&gt;</span>true<span class="nt">&lt;/cacheModels&gt;</span>
+<span class="nt">&lt;/DocumentManagerPolicy&gt;</span>
+</pre></div>
+
+
+<p>You can find the simple schema that declares the various properties
+that you can use in such an ontology document policy in the
+vocabularies directory of the Jena download. It's called
+<code>ont-manager.rdf</code>. To change the search path that the document
+manager will use to initialise itself, you can either pass the new
+search path as a string when creating a new document manager
+object, or call the method <code>setMetadataSearchPath()</code>.</p>
+<h3 id="the_modelmaker_creating_storage_on_demand">The ModelMaker: creating storage on demand</h3>
+<p>In order for the document manager to build the union of the
+imported documents (which we may refer to as the
+<em>imports closure</em>), there must be some means of creating new graphs
+to store the imported ontologies. Loading a new import means that
+there needs to be a new graph added Jena defines a <em>model maker</em> as
+a simple interface that allows different kinds of model storage (in
+memory, file-backed, in a persistent database, etc.) to be created
+on demand. For the database case, this may include passing the
+database user-name and password and other connection parameters.
+New model makers can be created with the
+<code>&lt;a href="../javadoc/com/hp/hpl/jena/rdf/model/ModelFactory.html"&gt;ModelFactory&lt;/a&gt;</code>.</p>
+<p>There are two cases in which we may want to create storage for
+models on-demand. The first is when creating the <code>OntModel</code> for the
+first time, some variants of <code>createOntologyModel</code> will allocate
+space for the <em>base model</em> (instead of, for example, being handed a
+base model to use as one of the method arguments). The second case
+when storage must be allocated is when adding an imported document
+to the union of imports. These cases often require different
+policies, so the <code>OntModelSpec</code> contains two model maker
+parameters: the <em>base model maker</em> and <em>imports model maker</em>,
+available via <code>getBaseModelMaker()</code> and <code>getImportsModelMaker()</code>
+methods respectively.</p>
+<p>The default specifications in OntModelSpec that begin MEM_ use an
+in-memory model maker for the both the base model and the imported
+documents.</p>
+<p><strong>Implementation note</strong>: internally to Jena, we use <code>Graph</code> as a
+primary data structure. However, your code will almost always refer
+to models, not graphs. What's happening is that a <code>Model</code> is a
+wrapper around the <code>Graph</code>, which balances a rich, convenient
+programming interface (<code>Model</code>) with a simple, manageable internal
+data structure (<code>Graph</code>). Hence some potential confusion in that
+Figure 4, above, refers to a structure containing graphs, but we
+use a
+<code>&lt;a       href="../javadoc/com/hp/hpl/jena/rdf/model/ModelMaker.html"     &gt;ModelMaker&lt;/a&gt;</code>
+to generate new stores. The document manager extracts the
+appropriate graph from the containing model. Except in cases where
+you are extending Jena's internal structures, you should think of
+<code>Model</code> as the container of RDF and ontology data.</p>
+<h3 id="controlling_imports_processing">Controlling imports processing</h3>
+<p>Normally, loading imports during the <code>read()</code> call automatic. To
+<code>read()</code> an ontology without building the imports closure, call the
+method <code>setProcessImports( false )</code> on the document manager object
+before calling <code>read()</code>. Alternatively, you can set the
+<code>processImports</code> property in the policy file. You can also be more
+selective, and ignore only certain URI's when loading the imported
+documents. To selectively skip certain named imports, call the
+method <code>addIgnoreImport( String uri )</code> on the document manager
+object, or set the <code>ignoreImport</code> property in the policy.</p>
+<h3 id="managing_file_references">Managing file references</h3>
+<p>An advantage of working with ontologies is that we can reuse work
+done by other ontologists, by importing their published ontologies
+into our own. Sometimes, however, this means that there is an
+Internet firewall between the ontology-based application and the
+source of an imported ontology. Even if it's possible to traverse
+the firewall through an HTTP proxy, retrieving files from an HTTP
+connection may impose unacceptable delays when starting an
+application. In the worst case, we may find that ontology on which
+our application depends is temporarily or permanently unavailable
+from the original published URL. To alleviate these commonly
+experienced problems, you can use the ontology document manager to
+set up a a local indirection, so that an attempt to import a
+document from a given published URL means that a local copy of the
+document is retrieved instead. This may be a file copy, or simply a
+pointer to a local mirror web site.</p>
+<p>To specify this local redirection in the policy file, use the
+following declarations:</p>
+<div class="codehilite"><pre><span class="nt">&lt;OntologySpec&gt;</span>
+  <span class="nt">&lt;publicURI</span> <span class="na">rdf:resource=</span><span class="s">&quot;… the public URI to map from…&quot;</span>    <span class="nt">/&gt;</span>
+  <span class="nt">&lt;altURL</span> <span class="na">rdf:resource=</span><span class="s">&quot;… the local URL to map to …&quot;</span> <span class="nt">/&gt;</span>
+  <span class="c">&lt;!-- optional ontology language term --&gt;</span>
+  <span class="nt">&lt;language</span> <span class="na">rdf:resource=</span><span class="s">&quot;… encoding used …&quot;</span> <span class="nt">/&gt;</span>
+  <span class="c">&lt;!-- optional prefix to associate with the public URL --&gt;</span>
+  <span class="nt">&lt;prefix</span> <span class="na">rdf:datatype=</span><span class="s">&quot;&amp;xsd;string&quot;</span><span class="nt">&gt;</span>a prefix<span class="nt">&lt;/prefix&gt;</span>
+<span class="nt">&lt;/OntologySpec&gt;</span>
+</pre></div>
+
+
+<p>For example:</p>
+<div class="codehilite"><pre><span class="nt">&lt;OntologySpec&gt;</span>
+  <span class="c">&lt;!-- local version of the RDFS vocabulary --&gt;</span>
+  <span class="nt">&lt;publicURI</span> <span class="na">rdf:resource=</span><span class="s">&quot;http://www.w3.org/2000/01/rdf-schema&quot;</span>    <span class="nt">/&gt;</span>
+  <span class="nt">&lt;altURL</span> <span class="na">rdf:resource=</span><span class="s">&quot;file:vocabularies/rdf-schema.rdf&quot;</span> <span class="nt">/&gt;</span>
+<span class="nt">&lt;/OntologySpec&gt;</span>
+</pre></div>
+
+
+<p>This specifies that an attempt to load the RDFS vocabulary from
+<code>http://www.w3.org/2000/01/rdf-schema</code> will transparently cause
+<code>file:vocabularies/rdf-schema.rdf</code> to be fetched instead. You can
+specify any number of such re-directions in the policy file, or you
+can add them to the document manager object directly by calling the
+various setter methods (see the Javadoc for details). As a
+side-effect, this mechanism also means that ontologies may be named
+with any legal URI (not necessarily resolvable) - so long as the
+<code>altURL</code> is itself resolvable.</p>
+<p>Note that the <code>OntDocumentManager</code> is an application of Jena's
+<a href="../how-to/filemanager.html">File Manager</a>. See the notes on
+FileManager for details of additional options.</p>
+<p>In the following example, I programmatically declare that the ESWC
+ontology is replicated locally on disk, and then I load it using
+the public URL. Assume that the constant <code>JENA</code> has been
+initialised to the directory in which Jena was installed.</p>
+<div class="codehilite"><pre><span class="n">OntModel</span> <span class="n">m</span> <span class="o">=</span> <span class="n">ModelFactory</span><span class="o">.</span><span class="n">createOntologyModel</span><span class="p">();</span>
+  <span class="n">OntDocumentManager</span> <span class="n">dm</span> <span class="o">=</span> <span class="n">m</span><span class="o">.</span><span class="n">getDocumentManager</span><span class="p">();</span>
+  <span class="n">dm</span><span class="o">.</span><span class="n">addAltEntry</span><span class="p">(</span> <span class="s">&quot;http://www.eswc2006.org/technologies/ontology&quot;</span><span class="p">,</span>
+                  <span class="s">&quot;file:&quot;</span> <span class="o">+</span> <span class="n">JENA</span> <span class="o">+</span> <span class="s">&quot;src-examples/data/eswc-2006-09-21.rdf&quot;</span>    <span class="p">);</span>
+  <span class="n">m</span><span class="o">.</span><span class="nb">read</span><span class="p">(</span> <span class="s">&quot;http://www.eswc2006.org/technologies/ontology&quot;</span> <span class="p">);</span>
+</pre></div>
+
+
+<h3 id="specifying_prefixes">Specifying prefixes</h3>
+<p>A model keeps a table of URI prefixes that can be used to render
+URI's in the shortened prefix:name form, which is useful in
+displaying URI's in a readable way in user interfaces, and is
+essential in producing legal XML names that denote arbitrary URI's.
+The ontology model's table of prefixes can be initialized from a
+table kept by the document manager, which contains the standard
+prefixes plus any that are declared by in the policy file (or added
+to subsequently by method calls). To prevent the model's prefix
+table from being initialized in this way, use the property
+<code>useDeclaredNsPrefixes</code> in the policy file (with value <code>false</code>), or
+call the method <code>setUseDeclaredPrefixes</code> on the ontology object.</p>
+<h3 id="caching_of_imported_models">Caching of imported models</h3>
+<p>You can use the document manager to assist with loading ontology
+documents through its cache. Suppose two ontologies, A and B both
+import ontology C. We would like not to have to read C twice when
+loading A and then B. The document manager supports this use case
+by optionally caching C's model, indexed by URI. When A tries to
+import C, there is no cached copy, so a new model is created for C,
+the contents of C's URL read in to the model, then the C model is
+used in the compound document for A. Subsequently, when ontology B
+is loading imports, the document manager checks in its cache and
+finds an existing copy of C. This will be used in preference to
+reading a fresh copy of C from C's source URL, saving both time and
+storage space.</p>
+<p>Caching of import models is switched on by default. To turn it off,
+use the policy property <code>cacheModels</code>, or call the method
+<code>setCacheModels( boolean caching )</code> with <code>caching = false</code>. The
+document manager's current model cache can be cleared at any time
+by calling <code>clearCache()</code>.</p>
+<h2 id="the_generic_ontology_type_ontresource">The generic ontology type: OntResource</h2>
+<p>All of the classes in the ontology API that represent ontology
+values have
+<code>&lt;a href="../javadoc/com/hp/hpl/jena/ontology/OntResource.html"&gt;OntResource&lt;/a&gt;</code>
+as a common super-class. This makes <code>OntResource</code> a good place to
+put shared functionality for all such classes, and makes a handy
+common return value for general methods. The Java interface
+<code>OntResource</code> extends Jena's RDF
+<code>&lt;a href="../javadoc/com/hp/hpl/jena/rdf/model/Resource.html"&gt;Resource&lt;/a&gt;</code>
+interface, so any general method that accepts a resource or an
+<code>&lt;a href="../javadoc/com/hp/hpl/jena/rdf/model/RDFNode.html"&gt;RDFNode&lt;/a&gt;</code>
+will also accept an <code>OntResource</code>, and consequently, any other
+ontology value.</p>
+<p>Some of the common attributes of ontology resources that are
+expressed through methods on OntResource are shown below:</p>
+<p>Attribute
+Meaning
+versionInfo
+A string documenting the version or history of this resource
+comment
+A general comment associated with this value
+label
+A human-readable label
+seeAlso
+Another web location to consult for more information about this
+resource
+isDefinedBy
+A specialisation of seeAlso that is intended to supply a definition
+of this resource
+sameAs
+Denotes another resource that this resource is equivalent to
+differentFrom
+Denotes another resource that is distinct from this resource (by
+definition)
+For each of these properties, there is a standard pattern of
+available methods:</p>
+<p>Method
+Effect
+add&lt;property&gt;
+Add an additional value for the given property
+set&lt;property&gt;
+Remove any existing values for the property, then add the given
+value
+list&lt;property&gt;
+Return an iterator ranging over the values of the property
+get&lt;property&gt;
+Return the value for the given property, if the resource has one.
+If not, return null. If it has more than one value, an arbitrary
+selection is made.
+has&lt;property&gt;
+Return true if there is at least one value for the given property.
+Depending on the name of the property, this is sometimes
+is&lt;property&gt;
+remove&lt;property&gt;
+Removes a given value from the values of the property on this
+resource. Has no effect if the resource does not have that value.
+For example: <code>addSameAs( Resource r )</code>, or
+<code>isSameAs( Resource r )</code>. For full details of the individual
+methods, please consult the Javadoc.</p>
+<p><code>OntResource</code> defines some other general utility methods. For
+example, to find out how many values a resource has for a given
+property, you can call <code>getCardinality( Property p )</code>. To delete
+the resource from the ontology altogether, you can call <code>remove()</code>.
+The effect of this is to remove every statement that mentions this
+resource as a subject or object of a statement.</p>
+<p>To get or set the value of a given property, use
+<code>getPropertyValue( Property p )</code> or
+<code>setPropertyValue( Property p, RDFNode value )</code>. Continuing the
+naming pattern, the values of a named property can be listed (with
+<code>listPropertyValues</code>), removed (with <code>removeProperty</code>) or added
+(with <code>addProperty</code>).</p>
+<p>Finally, <code>OntResource</code> provides methods for listing, getting and
+setting the <code>rdf:type</code> of a resource, which denotes a class to
+which the resource belongs (remember that in RDF and OWL, a
+resource can belong to many classes at once). The <code>rdf:type</code>
+property is one for which many entailment rules are defined in the
+semantic models of the various ontology languages. Therefore, the
+values that <code>listRDFTypes()</code> returns is more than usually dependent
+on the actual reasoner bound to the ontology model. For example,
+suppose I have class A, class B which is a subclass of A, and
+resource x whose asserted <code>rdf:type</code> is B. With no reasoner,
+listing x's RDF types will return only B. If the reasoner is able
+to calculate the closure of the subclass hierarchy (and most can),
+X's RDF types would also include A. A complete OWL reasoner would
+also infer that x has <code>rdf:type</code> <code>owl:Thing</code> and <code>rdf:Resource</code>.</p>
+<p>For some tasks, getting a complete list of the RDF types of a
+resource is exactly what is needed. For other tasks, this is not
+the case. If you are developing an ontology editor, for example,
+you may want to distinguish in its display between inferred and
+asserted types. In the above example, only <code>x rdf:type B</code> is
+asserted, everything else is inferred. One way to make this
+distinction is to make use of the base model (see Figure 4).
+Getting the resource from the base model and listing the type
+properties there would return only the asserted values. For
+example:</p>
+<div class="codehilite"><pre><span class="sr">//</span> <span class="n">create</span> <span class="n">the</span> <span class="n">base</span> <span class="n">model</span>
+<span class="n">String</span> <span class="n">SOURCE</span> <span class="o">=</span> <span class="s">&quot;http://www.eswc2006.org/technologies/ontology&quot;</span><span class="p">;</span>
+<span class="n">String</span> <span class="n">NS</span> <span class="o">=</span> <span class="n">SOURCE</span> <span class="o">+</span> <span class="s">&quot;#&quot;</span><span class="p">;</span>
+<span class="n">OntModel</span> <span class="n">base</span> <span class="o">=</span> <span class="n">ModelFactory</span><span class="o">.</span><span class="n">createOntologyModel</span><span class="p">(</span> <span class="n">OWL_MEM</span> <span class="p">);</span>
+<span class="n">base</span><span class="o">.</span><span class="nb">read</span><span class="p">(</span> <span class="n">SOURCE</span><span class="p">,</span> <span class="s">&quot;RDF/XML&quot;</span> <span class="p">);</span>
+
+<span class="sr">//</span> <span class="n">create</span> <span class="n">the</span> <span class="n">reasoning</span> <span class="n">model</span> <span class="n">using</span> <span class="n">the</span> <span class="n">base</span>
+<span class="n">OntModel</span> <span class="n">inf</span> <span class="o">=</span> <span class="n">ModelFactory</span><span class="o">.</span><span class="n">createOntologyModel</span><span class="p">(</span> <span class="n">OWL_MEM_MICRO_RULE_INF</span><span class="p">,</span> <span class="n">base</span> <span class="p">);</span>
+
+<span class="sr">//</span> <span class="n">create</span> <span class="n">a</span> <span class="n">dummy</span> <span class="n">paper</span> <span class="k">for</span> <span class="n">this</span> <span class="n">example</span>
+<span class="n">OntClass</span> <span class="n">paper</span> <span class="o">=</span> <span class="n">base</span><span class="o">.</span><span class="n">getOntClass</span><span class="p">(</span> <span class="n">NS</span> <span class="o">+</span> <span class="s">&quot;Paper&quot;</span> <span class="p">);</span>
+<span class="n">Individual</span> <span class="n">p1</span> <span class="o">=</span> <span class="n">base</span><span class="o">.</span><span class="n">createIndividual</span><span class="p">(</span> <span class="n">NS</span> <span class="o">+</span> <span class="s">&quot;paper1&quot;</span><span class="p">,</span> <span class="n">paper</span> <span class="p">);</span>
+
+<span class="sr">//</span> <span class="n">list</span> <span class="n">the</span> <span class="n">asserted</span> <span class="n">types</span>
+<span class="k">for</span> <span class="p">(</span><span class="n">Iterator</span> <span class="n">i</span> <span class="o">=</span> <span class="n">p1</span><span class="o">.</span><span class="n">listRDFTypes</span><span class="p">();</span> <span class="n">i</span><span class="o">.</span><span class="n">hasNext</span><span class="p">();</span> <span class="p">)</span> <span class="p">{</span>
+    <span class="n">System</span><span class="o">.</span><span class="n">out</span><span class="o">.</span><span class="n">println</span><span class="p">(</span> <span class="n">p1</span><span class="o">.</span><span class="n">getURI</span><span class="p">()</span> <span class="o">+</span> <span class="s">&quot; is asserted in class &quot;</span> <span class="o">+</span> <span class="n">i</span><span class="o">.</span><span class="k">next</span><span class="p">()</span> <span class="p">);</span>
+<span class="p">}</span>
+
+<span class="sr">//</span> <span class="n">list</span> <span class="n">the</span> <span class="n">inferred</span> <span class="n">types</span>
+<span class="n">p1</span> <span class="o">=</span> <span class="n">inf</span><span class="o">.</span><span class="n">getIndividual</span><span class="p">(</span> <span class="n">NS</span> <span class="o">+</span> <span class="s">&quot;paper1&quot;</span> <span class="p">);</span>
+<span class="k">for</span> <span class="p">(</span><span class="n">Iterator</span> <span class="n">i</span> <span class="o">=</span> <span class="n">p1</span><span class="o">.</span><span class="n">listRDFTypes</span><span class="p">();</span> <span class="n">i</span><span class="o">.</span><span class="n">hasNext</span><span class="p">();</span> <span class="p">)</span> <span class="p">{</span>
+    <span class="n">System</span><span class="o">.</span><span class="n">out</span><span class="o">.</span><span class="n">println</span><span class="p">(</span> <span class="n">p1</span><span class="o">.</span><span class="n">getURI</span><span class="p">()</span> <span class="o">+</span> <span class="s">&quot; is inferred to be in class &quot;</span> <span class="o">+</span> <span class="n">i</span><span class="o">.</span><span class="k">next</span><span class="p">()</span> <span class="p">);</span>
+<span class="p">}</span>
+</pre></div>
+
+
+<p>For other user interface or presentation tasks, we may want
+something between the complete list of types and the base list of
+only the asserted values. Consider the class hierarchy in figure 5
+(i):</p>
+<p><img alt="Diagram showing direct relationships" src="../images/Direct-hierarchy.png" /></p>
+<p>Figure 5: asserted and inferred relationships</p>
+<p>Figure 5 (i) shows a base model, containing a class hierarchy and
+an instance x. Figure 5 (ii) shows the full set of relationships
+that might be inferred from this base model. In Figure 5 (iii), we
+see only the <em>direct</em> or maximally specific relationships. For
+example, in 5 (iii) x does not have <code>rdf:type A</code>, since this is an
+relationship that is covered by the facts that x has <code>rdf:type D</code>,
+and D is a subclass of A. Notice also that the <code>rdf:type B</code> link is
+also removed from the direct graph, for a similar reason. Thus the
+direct graph hides relationships from both the inferred and
+asserted graphs. When displaying instance x in a GUI, particularly
+in a tree view of some kind, the direct graph is often the most
+useful as it contains the useful information in the most compact
+form.</p>
+<p>To list the RDF types of a resource, use:</p>
+<div class="codehilite"><pre><span class="n">listRDFTypes</span><span class="p">()</span>                 <span class="sr">//</span> <span class="n">assumes</span> <span class="ow">not</span><span class="o">-</span><span class="n">direct</span>
+<span class="n">listRDFTypes</span><span class="p">(</span> <span class="n">boolean</span> <span class="n">direct</span> <span class="p">)</span> <span class="sr">//</span> <span class="k">if</span> <span class="n">direct</span><span class="o">=</span><span class="n">true</span><span class="p">,</span> <span class="n">show</span> <span class="n">only</span> <span class="n">direct</span> <span class="n">relationships</span>
+</pre></div>
+
+
+<p>Related methods allow the <code>rdf:type</code> to be tested, set and
+returned.</p>
+<h2 id="ontology_classes_and_basic_class_expressions">Ontology classes and basic class expressions</h2>
+<p>Classes are the basic building blocks of an ontology. A simple
+class is represented in Jena by an
+<a href="/jena/documentation/javadoc/com/hp/hpl/jena/ontology/OntClass.html">OntClass</a>
+object. As I <a href="#rdfPolymorphism">mentioned above</a>, an ontology class
+is a facet of an RDF resource. One way, therefore, to get an
+ontology class is to convert an RDF resource. Assume that <code>m</code> is a
+suitable defined <code>OntModel</code>, into which the ESWC ontology has
+already been read, and that <code>NS</code> is a variable denoting the
+ontology namespace:</p>
+<div class="codehilite"><pre><span class="n">Resource</span> <span class="n">r</span> <span class="o">=</span> <span class="n">m</span><span class="o">.</span><span class="n">getResource</span><span class="p">(</span> <span class="n">NS</span> <span class="o">+</span> <span class="s">&quot;Paper&quot;</span> <span class="p">);</span>
+<span class="n">OntClass</span> <span class="n">paper</span> <span class="o">=</span> <span class="p">(</span><span class="n">OntClass</span><span class="p">)</span> <span class="n">r</span><span class="o">.</span><span class="n">as</span><span class="p">(</span> <span class="n">OntClass</span><span class="o">.</span><span class="n">class</span> <span class="p">);</span>
+</pre></div>
+
+
+<p>This can be shortened by calling <code>getOntClass()</code> on the ontology
+model:</p>
+<div class="codehilite"><pre><span class="n">OntClass</span> <span class="n">paper</span> <span class="o">=</span> <span class="n">m</span><span class="o">.</span><span class="n">getOntClass</span><span class="p">(</span> <span class="n">NS</span> <span class="o">+</span> <span class="s">&quot;Paper&quot;</span> <span class="p">);</span>
+</pre></div>
+
+
+<p>The <code>getOntClass</code> method will retrieve the resource with the given
+URI, and attempt to obtain the <code>OntClass</code> facet. If either of these
+operations fail, <code>getOntClass()</code> will return null. Compare this
+with the <code>createClass</code> method, which will reuse an existing
+resource if possible, or create a new class resource if not:</p>
+<div class="codehilite"><pre><span class="n">OntClass</span> <span class="n">paper</span>     <span class="o">=</span> <span class="n">m</span><span class="o">.</span><span class="n">createClass</span><span class="p">(</span> <span class="n">NS</span> <span class="o">+</span> <span class="s">&quot;Paper&quot;</span> <span class="p">);</span>
+<span class="n">OntClass</span> <span class="n">bestPaper</span> <span class="o">=</span> <span class="n">m</span><span class="o">.</span><span class="n">createClass</span><span class="p">(</span> <span class="n">NS</span> <span class="o">+</span> <span class="s">&quot;BestPaper&quot;</span> <span class="p">);</span>
+</pre></div>
+
+
+<p>You can use the create class method to create an anonymous class &ndash;
+a class description with no associated URI. Anonymous classes are
+often used when building more complex ontologies in OWL or DAML.
+They are less useful in RDFS.</p>
+<div class="codehilite"><pre><span class="n">OntClass</span> <span class="n">anonClass</span> <span class="o">=</span> <span class="n">m</span><span class="o">.</span><span class="n">createClass</span><span class="p">();</span>
+</pre></div>
+
+
+<p>Once you have the ontology class object, you can begin processing
+it through the methods defined on <code>OntClass</code>. The attributes of a
+class are handled in a similar way to the attributes of
+OntResource, above, with a collection of methods to set, add, get,
+test, list and remove values. Properties of classes that are
+handled in this way are:</p>
+<p>Attribute
+Meaning
+subClass
+A subclass of this class, i.e. those classes that are declared
+<code>subClassOf</code> this class.
+superClass
+A super-class of this class, i.e. a class that this class is a
+<code>subClassOf</code>.
+equivalentClass
+A class that represents the same concept as this class. This is not
+just having the same class extension: the class 'British Prime
+Minister in 2003' contains the same individual as the class 'the
+husband of Cherie Blair', but they represent different concepts.
+disjointWith
+Denotes a class with which this class has no instances in common.
+Thus, in our example ontology, we can print a list the subclasses
+of an Artefact as follows:</p>
+<div class="codehilite"><pre><span class="n">OntClass</span> <span class="n">artefact</span> <span class="o">=</span> <span class="n">m</span><span class="o">.</span><span class="n">getOntClass</span><span class="p">(</span> <span class="n">NS</span> <span class="o">+</span> <span class="s">&quot;Artefact&quot;</span> <span class="p">);</span>
+<span class="k">for</span> <span class="p">(</span><span class="n">Iterator</span> <span class="n">i</span> <span class="o">=</span> <span class="n">artefact</span><span class="o">.</span><span class="n">listSubClasses</span><span class="p">();</span> <span class="n">i</span><span class="o">.</span><span class="n">hasNext</span><span class="p">();</span> <span class="p">)</span> <span class="p">{</span>
+  <span class="n">OntClass</span> <span class="n">c</span> <span class="o">=</span> <span class="p">(</span><span class="n">OntClass</span><span class="p">)</span> <span class="n">i</span><span class="o">.</span><span class="k">next</span><span class="p">();</span>
+  <span class="n">System</span><span class="o">.</span><span class="n">out</span><span class="o">.</span><span class="n">println</span><span class="p">(</span> <span class="n">c</span><span class="o">.</span><span class="n">getURI</span><span class="p">()</span> <span class="p">);</span>
+<span class="p">}</span>
+</pre></div>
+
+
+<p>Note that, under RDFS and OWL semantics, each class is a sub-class
+of itself (in other words, <code>rdfs:subClassOf</code> is reflexive). While
+this is true, under the semantics, Jena users have reported finding
+it unhelpful. Therefore, the <code>listSubClasses</code> and
+<code>listSuperClasses</code> methods remove the reflexive from the list of
+results returned by the iterator. However, if you use the plain
+<code>Model</code> API to query for <code>rdfs:subClassOf</code> triples, assuming that a
+reasoner is in use, the reflexive triple will appear in the
+deductions model.</p>
+<p>Given an <code>OntClass</code> object, you can create or remove members of the
+class extension &ndash; individuals that are instances of the class &ndash;
+using the following methods:</p>
+<p>Method
+Meaning
+listInstances()
+listInstances( boolean direct )
+Returns an iterator over those instances that include this class
+among their <code>rdf:type</code> values. The <code>direct</code> flag can be used to
+select individuals that are direct members of the class, rather
+than indirectly through the class hierarchy. Thus if <code>p1</code> has
+<code>rdf:type :Paper</code>, it will appear in the iterator returned by
+<code>listInstances</code> on <code>:Artefact</code>, but not in the iterator returned by
+<code>listInstances(false)</code> on <code>:Artefact</code>.
+createIndividual()
+createIndividual( String uri )
+Adds a resource to the model, whose asserted <code>rdf:type</code> is this
+ontology class. If no URI is given, the individual is an anonymous
+resource.
+dropIndividual( Resource individual )
+Removes the association between the given individual and this
+ontology class. Effectively, this removes the <code>rdf:type</code> link
+between this class and the resource. Note that this is not the same
+as removing the individual altogether, unless the only thing that
+is known about the resource is that it is a member of the class. To
+delete an <code>OntResource</code>, including classes and individuals, use the
+<code>remove()</code> method.
+To test whether a class is a root of the class hierarchy in this
+model (i.e. it has no known super-classes), call
+<code>isHierarchyRoot()</code>.</p>
+<p>The domain of a property is intended to allow entailments about the
+class of an individual, given that it appears as a statement
+subject. It is not a constraint that can be used to validate a
+document, in the way that XML schema can do. Nevertheless, many
+developers find it convenient to use the domain of a property to
+document the design intent that the property only applies to known
+instances of the domain class. Given this observation, it can be a
+useful debugging or display aide to show the properties that have
+this class among their domain classes. The method
+<code>listDeclaredProperties()</code> attempts to identify the properties that
+are intended to apply to instances of this class. Using
+<code>listDeclaredProperties</code> is explained in detail in the
+<a href="../how-to/rdf-frames.html">RDF frames how-to</a>.</p>
+<h2 id="ontology_properties">Ontology properties</h2>
+<p>In an ontology, a <em>property</em> denotes the name of a relationship
+between resources, or between a resource and a data value. It
+corresponds to a predicate in logic representations. One
+interesting aspect of languages like RDFS and OWL is that
+properties are not defined as aspects of some enclosing class, but
+are first-class objects in their own right. This means that
+ontologies and ontology-applications can store, retrieve and make
+assertions about properties directly. Consequently, Jena has a set
+of Java classes that allow you to conveniently manipulate the
+properties represented in an ontology model.</p>
+<p>A property in an ontology model is an extension of the core Jena
+API class
+<code>&lt;a href="../javadoc/com/hp/hpl/jena/rdf/model/Property.html"&gt;Property&lt;/a&gt;</code>,
+and allows access to the additional information that can be
+asserted about properties in an ontology language. The common API
+super-class for representing ontology properties in Java is
+<code>&lt;a href="../javadoc/com/hp/hpl/jena/ontology/OntProperty.html"&gt;OntProperty&lt;/a&gt;</code>.
+Again, using the pattern of add, set, get, list, has, and remove
+methods, we can access the following attributes of an
+<code>OntProperty</code>:</p>
+<p>Attribute
+Meaning
+subProperty
+A sub property of this property; i.e. a property which is declared
+to be a <code>subPropertyOf</code> this property. If p is a sub property of q,
+and we know that <code>A p B</code> is true, we can infer that <code>A q B</code> is also
+true.
+superProperty
+A super property of this property, i.e. a property that this
+property is a <code>subPropertyOf</code>
+domain
+Denotes the class or classes that form the domain of this property.
+Multiple domain values are interpreted as a conjunction. The domain
+denotes the class of value the property maps from.
+range
+Denotes the class or classes that form the range of this property.
+Multiple range values are interpreted as a conjunction. The range
+denotes the class of values the property maps to.
+equivalentProperty
+Denotes a property that is the same as this property.
+inverse
+Denotes a property that is the inverse of this property. Thus if q
+is the inverse of p, and we know that <code>A q B</code>, then we can infer
+that <code>B p A</code>.
+In the example ontology, the property <code>hasProgramme</code> has a domain
+of <code>OrganizedEvent</code>, a range of <code>Programme</code> and the human-readable
+label "has programme". I can reconstruct this definition in an
+empty ontology model as follows:</p>
+<div class="codehilite"><pre><span class="n">OntModel</span> <span class="n">m</span> <span class="o">=</span> <span class="n">ModelFactory</span><span class="o">.</span><span class="n">createOntologyModel</span><span class="p">(</span> <span class="n">OntModelSpec</span><span class="o">.</span><span class="n">OWL_MEM</span> <span class="p">);</span>
+<span class="n">OntClass</span> <span class="n">programme</span> <span class="o">=</span> <span class="n">m</span><span class="o">.</span><span class="n">createClass</span><span class="p">(</span> <span class="n">NS</span> <span class="o">+</span> <span class="s">&quot;Programme&quot;</span> <span class="p">);</span>
+<span class="n">OntClass</span> <span class="n">orgEvent</span> <span class="o">=</span> <span class="n">m</span><span class="o">.</span><span class="n">createClass</span><span class="p">(</span> <span class="n">NS</span> <span class="o">+</span> <span class="s">&quot;OrganizedEvent&quot;</span> <span class="p">);</span>
+
+<span class="n">ObjectProperty</span> <span class="n">hasProgramme</span> <span class="o">=</span> <span class="n">m</span><span class="o">.</span><span class="n">createObjectProperty</span><span class="p">(</span> <span class="n">NS</span> <span class="o">+</span> <span class="s">&quot;hasProgramme&quot;</span> <span class="p">);</span>
+
+<span class="n">hasProgramme</span><span class="o">.</span><span class="n">addDomain</span><span class="p">(</span> <span class="n">orgEvent</span> <span class="p">);</span>
+<span class="n">body</span><span class="o">.</span><span class="n">addRange</span><span class="p">(</span> <span class="n">programme</span> <span class="p">);</span>
+<span class="n">body</span><span class="o">.</span><span class="n">addLabel</span><span class="p">(</span> <span class="s">&quot;has programme&quot;</span><span class="p">,</span> <span class="s">&quot;en&quot;</span> <span class="p">);</span>
+</pre></div>
+
+
+<p>As a further example, I can alternatively add information to an
+existing ontology. Let's add a super-property <code>hasDeadline</code> to
+generalise the separate properties denoting the submission
+deadline, notification deadline and camera-ready deadline:</p>
+<div class="codehilite"><pre><span class="n">OntModel</span> <span class="n">m</span> <span class="o">=</span> <span class="n">ModelFactory</span><span class="o">.</span><span class="n">createOntologyModel</span><span class="p">(</span> <span class="n">OntModelSpec</span><span class="o">.</span><span class="n">OWL_MEM</span> <span class="p">);</span>
+<span class="n">m</span><span class="o">.</span><span class="nb">read</span><span class="p">(</span> <span class="s">&quot;http://www.eswc2006.org/technologies/ontology&quot;</span> <span class="p">);</span>
+
+<span class="n">DatatypeProperty</span> <span class="n">subDeadline</span> <span class="o">=</span> <span class="n">m</span><span class="o">.</span><span class="n">getDatatypeProperty</span><span class="p">(</span> <span class="n">NS</span> <span class="o">+</span> <span class="s">&quot;hasSubmissionDeadline&quot;</span> <span class="p">);</span>
+<span class="n">DatatypeProperty</span> <span class="n">notifyDeadline</span> <span class="o">=</span> <span class="n">m</span><span class="o">.</span><span class="n">getDatatypeProperty</span><span class="p">(</span> <span class="n">NS</span> <span class="o">+</span> <span class="s">&quot;hasNotificationDeadline&quot;</span> <span class="p">);</span>
+<span class="n">DatatypeProperty</span> <span class="n">cameraDeadline</span> <span class="o">=</span> <span class="n">m</span><span class="o">.</span><span class="n">getDatatypeProperty</span><span class="p">(</span> <span class="n">NS</span> <span class="o">+</span> <span class="s">&quot;hasCameraReadyDeadline&quot;</span> <span class="p">);</span>
+
+<span class="n">DatatypeProperty</span> <span class="n">deadline</span> <span class="o">=</span> <span class="n">m</span><span class="o">.</span><span class="n">createDatatypeProperty</span><span class="p">(</span> <span class="n">NS</span> <span class="o">+</span> <span class="s">&quot;deadline&quot;</span> <span class="p">);</span>
+<span class="n">deadline</span><span class="o">.</span><span class="n">addDomain</span><span class="p">(</span> <span class="n">m</span><span class="o">.</span><span class="n">getOntClass</span><span class="p">(</span> <span class="n">NS</span> <span class="o">+</span> <span class="s">&quot;Call&quot;</span> <span class="p">)</span> <span class="p">);</span>
+<span class="n">deadline</span><span class="o">.</span><span class="n">addRange</span><span class="p">(</span> <span class="n">XSD</span><span class="o">.</span><span class="n">dateTime</span> <span class="p">);</span>
+
+<span class="n">deadline</span><span class="o">.</span><span class="n">addSubProperty</span><span class="p">(</span> <span class="n">subDeadline</span> <span class="p">);</span>
+<span class="n">deadline</span><span class="o">.</span><span class="n">addSubProperty</span><span class="p">(</span> <span class="n">notifyDeadline</span> <span class="p">);</span>
+<span class="n">deadline</span><span class="o">.</span><span class="n">addSubProperty</span><span class="p">(</span> <span class="n">cameraDeadline</span> <span class="p">);</span>
+</pre></div>
+
+
+<p>Note that, although I called the <code>addSubProperty</code> method on the
+object representing the new super-property, the serialized form of
+the ontology will contain <code>rdfs:subPropertyOf</code> axioms on each of
+the sub-property resources, since this is what the language
+defines. Jena will, in general, try to allow symmetric access to
+sub-properties and sub-classes from either direction.</p>
+<h3 id="object_and_datatype_properties">Object and Datatype properties</h3>
+<p>OWL and DAML+OIL refine the basic property type from RDF into two
+sub-types: <em>object properties</em> and <em>datatype properties</em> (for more
+details see
+[<a href="http://www.w3.org/TR/owl-ref/#Property">OWL Reference</a>]). The
+difference between them is that an object property can have only
+individuals in its range, while a datatype property has concrete
+data literals (only) in its range. Some OWL reasoners are able to
+exploit the differences between object and datatype properties to
+perform more efficient reasoning over ontologies. OWL also adds an
+<em>annotation property</em>, which is defined to have no semantic
+entailments, and so is useful when annotating ontology documents,
+for example.</p>
+<p>In Jena, the Java interfaces
+<code>&lt;a href="../javadoc/com/hp/hpl/jena/ontology/ObjectProperty.html"&gt;ObjectProperty&lt;/a&gt;</code>,
+<code>&lt;a href="../javadoc/com/hp/hpl/jena/ontology/DatatypeProperty.html"&gt;DatatypeProperty&lt;/a&gt;</code>
+and
+<code>&lt;a href="../javadoc/com/hp/hpl/jena/ontology/AnnotationProperty.html"&gt;AnnotationProperty&lt;/a&gt;</code>
+are sub-types of <code>OntProperty</code>. However, they do not have any
+behaviours (methods) particular to themselves. Their existence
+allows the more complex sub-types of ObjectProperty &ndash; transitive
+properties and so forth &ndash; to be kept separate in the class
+hierarchy. However, when you create an object property or datatype
+property in a model, it will have the effect of asserting different
+<code>rdf:type</code> statements into the underlying triple store.</p>
+<h3 id="functional_properties">Functional properties</h3>
+<p>OWL permits object and datatype properties to be <em>functional</em> &ndash;
+that is, for a given individual in the domain, the range value will
+always be the same. In particular, if <code>father</code> is a functional
+property, and individual <code>:bryn</code> has <code>father :ijd</code> and
+<code>father :ian</code>, a reasoner is entitled to conclude that <code>:ijd</code> and
+<code>:ian</code> denote the same individual. A functional property is
+equivalent to stating that the property has a maximum cardinality
+of one.</p>
+<p>Being a functional property is represented through the
+<code>&lt;a href="../javadoc/com/hp/hpl/jena/ontology/FunctionalProperty.html"&gt;FunctionalProperty&lt;/a&gt;</code>
+facet of an ontology property object. If a property is declared
+functional (test using the <code>isFunctional()</code> method), then the
+method <code>asFunctionalProperty()</code> conveniently returns the functional
+facet. A non-functional property can be made functional through the
+<code>convertToFunctionalProperty()</code> method. When you are creating a
+property object, you also have the option of passing a Boolean
+parameter to the <code>createObjectProperty()</code> method on <code>OntModel</code>.</p>
+<h3 id="other_property_types">Other property types</h3>
+<p>There are several additional sub-types of ObjectProperty that
+represent additional capabilities of ontology properties. A
+<code>&lt;a href="../javadoc/com/hp/hpl/jena/ontology/TransitiveProperty.html"&gt;TransitiveProperty&lt;/a&gt;</code>
+means that if p is transitive, and we know <code>:a p :b</code> and also
+<code>b p :c</code>, we can infer that <code>:a p :c</code>. A
+<code>&lt;a href="../javadoc/com/hp/hpl/jena/ontology/SymmetricProperty.html"&gt;SymmetricProperty&lt;/a&gt;</code>
+means that if p is symmetric, and we know <code>:a p :b</code>, we can infer
+<code>:b p :a</code>. An
+<code>&lt;a href="../javadoc/com/hp/hpl/jena/ontology/InverseFunctionalProperty.html"&gt;InverseFunctionalProperty&lt;/a&gt;</code>
+means that for any given range element, the domain value is unique.
+(Note that in DAML+OIL, the terminology for inverse functional
+property is <em>unambiguous property</em>).</p>

[... 855 lines stripped ...]


Mime
View raw message