Author: buildbot
Date: Tue Dec 13 17:32:20 2011
New Revision: 800212
Log:
Staging update by buildbot
Modified:
websites/staging/stanbol/trunk/content/stanbol/docs/trunk/ontologymanager.html
websites/staging/stanbol/trunk/content/stanbol/docs/trunk/ontologymanager/registry.html
Modified:
websites/staging/stanbol/trunk/content/stanbol/docs/trunk/ontologymanager.html
==============================================================================
---
websites/staging/stanbol/trunk/content/stanbol/docs/trunk/ontologymanager.html
(original)
+++
websites/staging/stanbol/trunk/content/stanbol/docs/trunk/ontologymanager.html
Tue Dec 13 17:32:20 2011
@@ -52,28 +52,24 @@
<div id="content">
<h1 class="title">Ontology Manager</h1>
<p>The Stanbol Ontology Manager provides a controlled environment for
managing ontologies, ontology networks and user sessions for semantic data
modeled after them. It provides full access to ontologies stored into the
Stanbol persistence layer.</p>
-<h2 id="restful_api">RESTful API</h2>
-<p>Stanbol OntoNet implements the API section for managing OWL and OWL2
ontologies, in order to prepare them for consumption by reasoning services,
refactorers, rule engines and the like. Ontology management in ONM is sparse
and not connected: once loaded internally from their remote locations,
ontologies live and are known within the realm they were loaded in. This allows
loose-coupling and (de-)activation of ontologies in order to scale the data
sets for reasoners to process and optimize them for efficiency. The following
concepts have been introduced with the ONM:</p>
+<h2 id="terminology">Terminology</h2>
+<p>Stanbol OntoNet implements the API section for managing OWL and OWL2
ontologies, in order to prepare them for consumption by reasoning services,
refactorers, rule engines and the like. Ontology management in OntoNet is
sparse and not connected: once loaded internally from their remote locations,
ontologies live and are known within the realm they were loaded in. This allows
loose-coupling and (de-)activation of ontologies in order to scale the data
sets for reasoners to process and optimize them for efficiency. The following
concepts have been introduced with OntoNet:</p>
<ul>
<li>
<p>Ontology scope: a "logical realm" for all the ontologies that encompass a
certain CMS-related set of concepts (such as "User", "ACL", "Event", "Content",
"Domain", "Reengineering", "Community", "Travelling" etc.). Scopes never
inherit from each other, though they can load the same ontologies if need
be.</p>
</li>
<li>
-<p>Ontology space: an access-restricted container for synchronized access to
ontologies within a scope. The ontologies in a scope are loaded within its set
of spaces. An ontology scope contains: (a) exactly one core space, which
contains the immutable set of essential ontologies that describe the scope; (b)
exactly one (possibly empty) custom space, which extends the core space
according to specific CMS needs (e.g. the core space for the User scope may
contains alignments to FOAF); (c) zero or more session spaces, which extend the
custom space with additional models provided by end-users (e.g. the set of
individuals that 'populate' a scope may be fed to OntoNet via a session space).
Session spaces are mapped one-to-one with KReS sessions (see below).</p>
+<p>Ontology space: an access-restricted container for synchronized access to
ontologies within a scope. The ontologies in a scope are loaded within its set
of spaces. An ontology scope contains: (a) one core space, which contains the
immutable set of essential ontologies that describe the scope; (b) one
(possibly empty) custom space, which extends the core space according to
specific CMS needs (e.g. the core space for the User scope may contains
alignments to FOAF).</p>
</li>
<li>
-<p>OntoNet session: a container of session spaces for all affected scopes, for
stateful management of ontology networks. It is not equivalent to an HTTP
session (since it can live persistently across multiple HTTP sessions),
although its behaviour can reflect the one of the HTTP session that created it,
if required by the implementation.</p>
+<p>Session: a container of (supposedly volatile) semantic data which need to
be intercrossed with one or more Scopes, for stateful management of ontology
networks. It can be used to load instances and reason on them using different
models (one per scope). An OntoNet Session is not equivalent to an HTTP session
(since it can live persistently across multiple HTTP sessions), although its
behaviour can reflect the one of the HTTP session that created it, if required
by the implementation.</p>
</li>
</ul>
<h3 id="sub-components">Sub-Components</h3>
<ul>
-<li>'ontonet' - allows to construct subsets of the knowledge base
- managed by Stanbol into OWL/OWL2 ontology networks</li>
-<li><a href="ontologymanager/registry.html">Registry</a> - manages ontology
libraries for bootstrapping the network
- using both external and internal ontologies</li>
-<li>'store' - create, read, update and modify operations on single
- ontologies stored in Stanbol</li>
-<li>'web' - the RESTful Web Service interface for OntoNet</li>
+<li>OntoNet - allows to construct subsets of the knowledge base managed by
Stanbol into OWL/OWL2 ontology networks</li>
+<li><a href="ontologymanager/registry.html">Registry</a> - manages ontology
libraries for bootstrapping the network using both external and internal
ontologies</li>
+<li>Store - create, read, update and delete operations on single
ontologies stored in Stanbol. These operations can be performed on entities,
axioms, and whole ontologies.</li>
</ul>
<h2 id="examples">Examples</h2>
<p>TODO</p>
Modified:
websites/staging/stanbol/trunk/content/stanbol/docs/trunk/ontologymanager/registry.html
==============================================================================
---
websites/staging/stanbol/trunk/content/stanbol/docs/trunk/ontologymanager/registry.html
(original)
+++
websites/staging/stanbol/trunk/content/stanbol/docs/trunk/ontologymanager/registry.html
Tue Dec 13 17:32:20 2011
@@ -52,7 +52,7 @@
<div id="content">
<h1 class="title">Ontology Registry Manager</h1>
<p>Registry management is a facility for Stanbol
<strong>administrators</strong> to pre-configure sets of ontologies that
Stanbol should load and store, or simply be aware of, <em>before</em> they are
included in a part of the ontology network (e.g. a scope or session). Via the
registry manager, it is possible to configure whether these ontologies should
be loaded immediately when Stanbol is initialized, or only when explicitly
requested. The Ontology Registry Manager is essentially an ontology bookmarker
with caching support. It is also possible to cache multiple versions of the
same ontology if needed.</p>
-<h2 id="glossary">Glossary</h2>
+<h2 id="terminology">Terminology</h2>
<ul>
<li>A <strong>Library</strong> is a collection of references to ontologies,
which can be located anywhere on the Web. CMS administrators and knowledge
managers can create a library by any criterion, e.g. a library of all <em>W3C
ontologies</em>, a library of all the ontologies that describe a <em>social
network</em> (which can include <a
href="http://sioc-project.org/ontology";>SIOC</a>, <a
href="http://xmlns.com/foaf/spec";>FOAF</a> etc.), a library of <em>ontology
alignments</em> (which includes ontologies that align DBPedia to Schema.org,
GeoNames to DBPedia, or a custom product ontology to GoodRelations).</li>
<li>A <strong>Registry</strong> is an RDF resource (i.e. an ontology itself)
that describes one or more libraries. It is the physical object that has to be
accessed to gain knowledge about libraries.</li>
