Author: buildbot
Date: Wed Jan 18 14:01:22 2012
New Revision: 802872
Log:
Staging update by buildbot for stanbol
Modified:
websites/staging/stanbol/trunk/content/stanbol/docs/trunk/ontologymanager/ontonet.html
Modified:
websites/staging/stanbol/trunk/content/stanbol/docs/trunk/ontologymanager/ontonet.html
==============================================================================
---
websites/staging/stanbol/trunk/content/stanbol/docs/trunk/ontologymanager/ontonet.html
(original)
+++
websites/staging/stanbol/trunk/content/stanbol/docs/trunk/ontologymanager/ontonet.html
Wed Jan 18 14:01:22 2012
@@ -106,18 +106,22 @@
<p>Note that when you add an ontology to a space or session, you pass it an
<code>OntologyInputSource</code> object, or more precisely, an
<code>OntologyInputSource<O,P></code>. This is because there can be
several ways to obtain an ontology, and those most common are supported in
Stanbol. For example, it can be obtained by defererencing a IRI and parsing its
source code (in RDF/XML, Turtle, etc.), or by reading an input stream, or
taking an already stored RDF graph in the Stanbol store; or it could be an
ontology Java object created from scratch. An <strong>Ontology input
source</strong> is an object that incorporates (1) the "method" by which an
ontology should be accessed; (2) the type of Java object it should create to
represent an ontology; (3) where it should store the ontology.</p>
<ul>
<li>
-<p><strong><code>OWLOntology</code> input sources</strong> comply with the OWL
API specification <a href="#ref1">[1]</a> and creates objects of type
<code>OWLOntology</code> stored in an <em>in-memory</em>
<code>OWLOntologyManager</code>. It will be stored persistently once added to
an ontology network.
-<strong> <code>RootOntologySource</code>. Wraps an already existing
<code>OWLOntology</code>, therefore it does not provide a physical IRI.
-</strong> <code>RootOntologyIRISource</code>. Tries to locate and load an
ontology, and its imports, from a given IRI. It can use a custom
<code>OWLOntologyManager</code> as a store, and can even override any mappers,
in order to force-dereference the IRI.
-<strong> <code>ParentPathInputSource</code>. Tries to load an ontology from a
root <code>File</code>, and will seek its imports among the files in the same
directory as the root <code>File</code>. It also allows a custom
<code>OWLOntologyManager</code> as a store.
-Loads the ontology source codeWraps an already existing
<code>OWLOntology</code>, therefore it does not provide a physical IRI.
-</strong> <code>BlankOntologySource</code>. Creates an
<code>OWLOntology</code> with no ID and no axioms. It can be useful for
supplying dummy ontologies to methods that will not admit a null ontology. Note
that the blank ontology is not shared: each <code>BlankOntologySource</code>
has a distinct blank ontology object, and they are <em>not</em> equal! This
means that the following statement is false:</p>
+<ul>
+<li><code>RootOntologySource</code>. Wraps an already existing
<code>OWLOntology</code>, therefore it does not provide a physical IRI.</li>
+<li><code>RootOntologyIRISource</code>. Tries to locate and load an ontology,
and its imports, from a given IRI. It can use a custom
<code>OWLOntologyManager</code> as a store, and can even override any mappers,
in order to force-dereference the IRI.</li>
+<li><code>ParentPathInputSource</code>. Tries to load an ontology from a root
<code>File</code>, and will seek its imports among the files in the same
directory as the root <code>File</code>. It also allows a custom
<code>OWLOntologyManager</code> as a store.
+Loads the ontology source codeWraps an already existing
<code>OWLOntology</code>, therefore it does not provide a physical IRI.</li>
+<li><code>BlankOntologySource</code>. Creates an <code>OWLOntology</code> with
no ID and no axioms. It can be useful for supplying dummy ontologies to methods
that will not admit a null ontology. Note that the blank ontology is not
shared: each <code>BlankOntologySource</code> has a distinct blank ontology
object, and they are <em>not</em> equal! This means that the following
statement is false:</li>
+</ul>
+<p><strong><code>OWLOntology</code> input sources</strong> comply with the OWL
API specification <a href="#ref1">[1]</a> and creates objects of type
<code>OWLOntology</code> stored in an <em>in-memory</em>
<code>OWLOntologyManager</code>. It will be stored persistently once added to
an ontology network.</p>
<p>new BlankOntologySource().getRootOntology().equals(new
BlankOntologySource().getRootOntology());</p>
</li>
<li>
-<p><strong><code>TripleCollection</code> input sources</strong> comply with
the Apache Clerezza API specification, which is also the default native
implementation of OntoNet. The resulting ontology is a subtype of
<code>TripleCollection</code> (<code>Graph</code> or <code>MGraph</code>) and
uses a <code>TcProvider</code> as a store. Depending on the chosen Stanbol
storage, it can be pesistent or in-memory. Generally, these input sources take
less memory that OWL API counterparts, but do not allow RDF graphs to be
managed using the OWL language constructs. Note that any
<code>TripleCollection</code> can be exported as an <code>OWLOntology</code>
afterwards, once stored.
-<strong> <code>GraphContentInputSource</code>. Creates a
<code>TripleCollection</code> by reading an input stream, which can be obtained
from a file, URL etc. It can use any <code>TcProvider</code> as a store,
otherwise it will create an in-memory triple collection, which will be copied
to the Stanbol store when adding the ontology to a network. If this
<code>TcProvider</code> is the <code>TcManager</code> used by Stanbol, its
triples are not copied across.
-</strong> <code>GraphSource</code>. Wraps an existing
<code>TripleCollection</code> object. In general, it does not 'know' where the
ontology was stored.</p>
+<p><strong><code>TripleCollection</code> input sources</strong> comply with
the Apache Clerezza API specification, which is also the default native
implementation of OntoNet. The resulting ontology is a subtype of
<code>TripleCollection</code> (<code>Graph</code> or <code>MGraph</code>) and
uses a <code>TcProvider</code> as a store. Depending on the chosen Stanbol
storage, it can be pesistent or in-memory. Generally, these input sources take
less memory that OWL API counterparts, but do not allow RDF graphs to be
managed using the OWL language constructs. Note that any
<code>TripleCollection</code> can be exported as an <code>OWLOntology</code>
afterwards, once stored.</p>
+<ul>
+<li><code>GraphContentInputSource</code>. Creates a
<code>TripleCollection</code> by reading an input stream, which can be obtained
from a file, URL etc. It can use any <code>TcProvider</code> as a store,
otherwise it will create an in-memory triple collection, which will be copied
to the Stanbol store when adding the ontology to a network. If this
<code>TcProvider</code> is the <code>TcManager</code> used by Stanbol, its
triples are not copied across.</li>
+<li><code>GraphSource</code>. Wraps an existing <code>TripleCollection</code>
object. In general, it does not 'know' where the ontology was stored.</li>
+</ul>
</li>
</ul>
<h3 id="service_endpoints">Service Endpoints</h3>
