Ontology Server research
On this page you can find all available information
related to the ontology server being developed at STAR Lab.
The base model
The ontology server architecture
The ontology server
The development of the ontology server falls within the
DOGMA research framework,
for further information please click the link. This page will provide all
information about the work that is done here at STAR Lab, which goes from
theoretical issues to implementation details. At the moment, we are still
experimenting with the base model, and an early (and incomplete) version of
ontology server is being implemented. Once this first version of the
ontology server is established, we will be able to validate the theoretical
model and experiment with the ontology server and ontologies in general.
The basic idea behind the model that is used for the
ontology server is the fact that semantics, just like in database, should
be kept outside the ontology (e.g. in a layer around it). Consequently, we
should come to a representation which is as simple as possible, and a (possibly
different for different applications within the domain) semantics interpretation
function to interpret the data in the ontology. Constraints and derivation
rules are intentionally left outside of the ontology.
Essentially, our ontology model consists of 5 basic
elements: context, terms, concepts, roles and lexons, as can be seen in the ORM scheme
In the full model there
are some extra entities, such as user and version, mainly for administrative
reasons. The first prototype we are building now will not include version
control nor user control, but, in a later version, these (and especially version
control) might become a crucial issue.
Element by element, the
model is explained below:
ontology is the topmost entity, necessary because it is the intention of the
ontology server to contain several ontologies, likely to be contributed by
different persons. The ontology contains a set of contexts (see
further), which form the ontology itself. As attributes, the ontology
has a name (mandatory and unique in the ontology server), a contributor, an
owner, a status ("under development", "finished",
...) and a documentation (an arbitrary string in which the contributor or
the owner can specify relevant information).
context is actually a grouping entity, it is used to group terms and lexons
(see further) in the ontology. Within one ontology, every context
should have a unique name. It is annotated with a term within the meta
context for this ontology. The existence of a meta context also makes
it possible to define inter-context relations in a very similar way to
relations between ordinary terms (see further, lexons).
a concept is an entity representing some "thing", the actual
entity in the real world. We use id's to identify the concept: every
concept has a unique id. A concept also has a triple
"source-key-value", which is the description(s) for that
concept. The source identifies the source from which the description
originates, the key is a string which gives a hint to the user on how he
should interpret the value, and finally the value is the description of the
concept. One concept can have more than one source-key-value triple,
and thus have it's meaning described in different ways. As an example,
let's consider Wordnet. In Wordnet synsets denote a set of terms (with
their "senses") which are equivallent. Every term also has a
glossary, which is an informal description of the meaning for that
(particular sense of the) term. In this respect, we could extract from
Wordnet 2 different descriptions for a concept, 2 different source-key-value
triples, namely the glossary (Source: Wordnet - Key: Glossary - Value:
"<informal description denoted as a glossary in wordnet>")
and the synset (Source: Wordnet - Key: Glossary - Value: <enumeration of
synonyms forming the synset>)
Term: a term
is an entity representing a lexical representation of a concept.
Within one context, a term is unambiguous and, consequently, it can only be
associated with one concept. Off course, several different terms
within one context can refer to the same concept, implicitly defining these
terms as synonyms for this context. Terms in different context
can also refer to the same concept, and in this way implicitly establish a
connection between these two context. The terms can be the same
(meaning that the two terms have the same meaning within the different
contexts) or they can be different (meaning that some other term in some
other context has the same meaning). Note that the implicit definition
of synonyms is indeed dependent on the context (for example, wield and
handle are synonyms for the context "weaponry", but they are
clearly not when we consider handle to be in the context "tools").
a lexon is a grouping element, it is a triple consisting of a starting term
(also called the "headword" of the lexon), a role (relation) and a
second term (also called the "tail" of the lexon). A lexon
always appears in a context, and describes certain relations which are valid
in this context (but not necessarily in another context). Because the
lexons appear in a context, and terms are unambiguous in a context, the
lexons can also be considered as relations between concepts.
ontology server architecture
In the figure below you
can find the general ontology server architecture.
As we can see in the
figure, the general architecture components are:
the storage system is the place where the data is stored. Ideally,
storage would be an elementary system that operates on disk level (rather
than build upon the existing file system) and thus implement an efficient
storage which allows fast access to the different elements of the ontology
base model as described above (similar to the way DBMS's manage data).
provides a unified access to the basic structures of the ontology
server. The API should be accessible from any high level programming
ontology objects: the ontology object are expressed in a data
description language format, or as objects in any high level programming
language. They are obtained from the storage API, and can also be
stored by the storage api.
applications can use the ontology server by integrating the ontology objects
returned from the storage API in their program code.
ontology server implementation
As can be observer the
general architecture from the
previous section is implemented by the following components:
we use a Database Management System to implement the Storage.
Currently we are using MSQL Server 7.0, but this DBMS can be easily replaced
by any other database product (see also Database API). The ontology server database schema was
obtained by transforming the ORM model using Visio 2000 into a relational
database schema, which can be seen here.
The SQL DDL statements which construct a this database schema are giving in this
SQL script file.
Access to the storage is provided by a database API, which we wrote in Java
(JDK 1.3). The connection to the DBMS is made using JDBC 2.0 and
the jdbc-odbc driver of sun delivered with the JDK 1.3. The API itself
is specified as three different java interfaces IDatabaseInsertionAPI
, IDatabaseRetrievalAPI and IDatabaseModificationAPI, all inheriting
from the general super class IDatabaseAPI. (Note that all database
interfaces start with an I)
as a common super class for all other interfaces listed below, the
IDatabaseAPI contains the methods to establish and close the connection
to the database. Every use of the Database API should be initiated
by calling the establishConnection method. Whenever the Database
API is not longer required, the closeConnection method should be called.
the insertion API provided all basic functionality to add information to
the ontology server. Specific methods for adding ontology,
context, terms, concept, lexons, users and versions are included.
Remember that methods for establishing and closing a connection to the
database are provided through inheritance from the IDatabaseAPI.
the retrieval interface provides all basic functionality to retrieve
information from the ontology server. The specific methods can be
divided in two groups, those for retrieving detailed information about
ontologies, contexts, terms, concepts, lexons, users and versions , and
those for retrieving grouped information, such as retrieving all
ontologies from the ontology server, all contexts from an ontology, all
terms from a context, all lexons from a context and all users from the
ontology server. For more information
on how ontology elements are returned, please see the
Java Persistent Objects. Remember that methods for
establishing and closing a connection to the database are provided
through inheritance from the IDatabaseAPI.
the modification interface provides all basic functionality to modify
information already present in the ontology server. This interface
is not yet implemented. It will include
specific methods for modifying ontologies, contexts, terms, concepts,
lexons, users and version. As every specific database interface,
the modification interface should inherit from IDatabaseAPI.
are, unless stated otherwise, implemented by the concrete class DatabaseAPI.
implementation is available here: OntologyServer.zip.
Documentation on the java implementation is also available.
There are three
notes to be made. First off all, we want to note that currently, only
the basic interfaces are implemented, but other specific interfaces may
easily be added. The IDatabaseModificationAPI is under development,
and more advanced retrieval and insertion interfaces are also under
consideration. The creation of these advanced interfaces will happen
in close correlation with the development of a specific ontology query
language (similar to SQL for databases). Secondly, we also want to
note that the combination of the jdbc-odbc driver and potential poor garbage
collection of JDBC objects, can lead to increasing delays when using the
database API. This can be avoided by re-establishing the connection to
the database when access slows down. And finally, we want to mention
that although the interface API is expressed and implemented as java
interfaces and objects, it can be accessed from any programming language
using Corba or similar technology.
Persistent Objects: the higher level ontology objects are
implemented as java object (see package ontologyobjects), implementing the
specific Java interfaces. The specific interfaces are IOntology,
IContext, ITerm, IConcept, ILexon, IUser and IVersion. All these
interface inherit from the general ontology object interface IOntologyObject,
currently only containing one method for pretty printing, but intended to
contain all methods related to persistency (not yet implemented in the
current version). All concrete implementation of these interfaces are
also provided. When the ontology server needs to return chains of
objects (when retrieved from the retrieval API), our implementation uses
OntologyCollections (see package util). Ontology collections work
similar to java collections, in addition they do delayed retrieval from the
ontology database storage.
expressed in XML format: ontology objects can also be expressed in
XML format, using this DTD. This
representation in the popular XML data description language enables us to
use the whole variety of tools available for XML (see also Ontology
any kind of application can make use of an ontology stored in the ontology
server, simply by using the Database API and the ontology objects described
above. We ourselves provide 2 applications which are invaluable to the
manager: at this point, the ontology manager only provides
support for storing ontologies expressed in XML. We use the Xerces
Java Parser for parsing the XML documents containing ontologies.
This XML parser uses the Database API to access to ontology
server. We added WordNet to the ontology server using the ontology
manager (see later).
browser: Currently, there is an experimental ontology browser
developed, but we feel it is not yet mature enought to make it
public. Once the ontology browser matured, it will become
How to store
ontologies described in XML (already implemented, still to be added on the
Wordnet in our
ontology server (already implemented, still to be added on the site)
Persistence in the
real sense of the word for the java ontology objects