This project has retired. For details please refer to its Attic page.
Apache Stanbol - Ontology Network Manager (OntoNet)

Ontology Network Manager (OntoNet)

Terminology

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.

OntoNet ontology network structure
Figure 1: an example of OntoNet setup for multiple ontology networks, showing the orthogonal layering of sessions, scopes and spaces.

The following concepts have been introduced with OntoNet:

Usage

Given the entire knowledge base managed by your CMS, OntoNet allows the construction and management of ontology networks, programmatically via its Java API or RESTful Web Services (see next section for details on the latter). A criterion for choosing the appropriate API can be as follows:

Java API

First and foremost, the concept of ontology network is implicit in the OntoNet API. There is no such thing as an OntologyNetwork type. What you do is create OntologyScope and Session objects and link them together at creation time or when launching a process.

Accessing the managers.

First and foremost let us obtain references to the main OntoNet manager classes. In an OSGi environment they can be obtained by reference:

@Reference
ONManager onMgr;

@Reference
SessionManager sesMgr;

In a non-OSGi environment they must be instantiated as POJOs (Plain Old Java Objects):

TODO

Managing an ontology scope.

Let us now show an example of how to setup an ontology scope, which you should use for storing the models for a certain domain of your knowledge base. In this example we will refer to social networks and communities.

ScopeRegistry registry = onMgr.getScopeRegistry();
OntologyScopeFactory factory 
  = onMgr.getOntologyScopeFactory();

/*
 * Here we create a scope called "social" where we intend 
 * to place all the knowledge needed for modeling social 
 * networks and communities.
 *
 * Suppose the FOAF and SIOC ontologies are the only ones 
 * we are concerned with at scope creation time. We tell 
 * the scope factory method to fetch them from their 
 * original locations on the Web.
 */
try {

  /* 
   * You can include as many ontology input source as 
   * you want, even none at all.
   */
  OntologyScope scope = factory.createOntologyScope(
    "social", 
    new RootOntologyIRISource(
      IRI.create("http://xmlns.com/foaf/spec/index.rdf")),
    new RootOntologyIRISource(
      IRI.create("http://rdfs.org/sioc/ns")));

  /*
   * Setup the scope, so its ontologies will be available 
   * via the RESTful API
   */
  // Lock the ontology scope 
  scope.setUp(); 
  // Register the scope and activate it
  registry.registerScope(scope, true); 
} catch (OWLOntologyCreationException e1) {
  /* 
   * Thrown if there was an error creating one of the 
   * ontology sources (e.g. if some URL could not be 
   * resolved or it is not an ontology.
   */
  e1.printStackTrace();
} catch (DuplicateIDException e1) {
  /*
   * Thrown if there is already a scope called "social".
   * In this case we may decide to use the existing one, 
   * so we get it. Note that wen reusing a scope, you
   * lose the provilege of writing in its core space.
   * Only the custom space will be open for modification.
   */
  scope = registry.getScope("social");
}

If you have not changed any parameters in the OntoNet configuration and have the Ontology Manager Web Service endpoint up and running, you should be able to fetch an RDF file at http://localhost:8080/ontonet/ontology/social. Let us check it (in Turtle Syntax):

% curl -H "Accept: application/turtle" http://localhost:8080/ontonet/ontology/social

@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix : 
  <http://localhost:8080/ontonet/ontology/social#> .
@prefix xml: <http://www.w3.org/XML/1998/namespace> .
@prefix rdf: 
  <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@base <http://localhost:8080/ontonet/ontology/social> .

<http://localhost:8080/ontonet/ontology/social> 
  rdf:type owl:Ontology ;
  owl:imports 
    <http://localhost:8080/ontonet/ontology/social/core> .

Let us take a look at the imported ontology that represents the core space of the "social" scope.

% curl -H "Accept: application/turtle" http://localhost:8080/ontonet/ontology/social/core

@base 
  <http://localhost:8080/ontonet/ontology/social/core> .

<http://localhost:8080/ontonet/ontology/social/core> 
  rdf:type owl:Ontology ;
  owl:imports 
    <http://localhost:8080/ontonet/ontology/social/http://rdfs.org/sioc/ns> ,
    <http://localhost:8080/ontonet/ontology/social/http://xmlns.com/foaf/0.1/> .

Here are the owl:imports statements for the FOAF and SIOC ontologies, which are hijacked to "internal" versions managed by Stanbol. Of course if a domain namespace other than "http://localhost:8080/" was configured, you will see that one in each import statement.

Also note that the import statement for FOAF ends with http://xmlns.com/foaf/0.1/, which is different from the IRI we passed to Stanbol http://xmlns.com/foaf/spec/index.rdf. This happens because in the case of FOAF the physical IRI (which must be known a priori) differs from its logical IRI (which identifies the ontology and is discovered only when the ontology is read), and OntoNet tends to privilege the logical IRI when one is found, i.e. when the ontology is not anonymous.

The FOAF and SIOC ontologies are imported by the core space because they were indicated at creation time.

Of course it is possible to onbtain a Java object for the ontology using the Java API. Here is how to export an entire scope to an OWL API object of type OWLOntology:

/*
 * To obtain the OWLOntology, we must specify its class as
 * a return parameter.
 * We also set the second argument to true, to specifiy 
 * that we want it merged with its imports, so that the 
 * resulting object contains all axioms.
 */
OWLOntology scopeAsOWL 
  = scope.export(OWLOntology.class, true);

An scope can be exported either as an OWL API object or as a Clerezza object.

/*
 * In Clerezza, a Graph is a subclass of TripleCollection, 
 * so it is supported by OntoNet. We could also export a 
 * scope to a MGraph (modifiable Graph).
 */
Graph scopeAsClerezza = scope.export(Graph, false);

Ontology input sources.

Note that when you add an ontology to a space or session, you pass it an OntologyInputSource object, or more precisely, an OntologyInputSource<O,P>. 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 Ontology input source 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.

Service Endpoints

The OntoNet RESTful API is structured as follows:

(Please note, that the following links to the actual service endpoints link to a running instance of Apache Stanbol. If you use domains or ports other than "localhost:8080", then please change accordingly)

Scopes ("/ontonet/ontology")

Sessions ("/ontonet/session")

Managed Ontologies ("ontonet/{ontologyId}")

References:

Back to Ontology Manager