This paper presents a prototype of an ontology-based semantic annotation tool Saha. The tool eases the process of creating ontological descriptions of documents by providing a simple user interface that hides the complexity of ontologies from annotators. Saha is used with a web browser, and it supports collaborative distributed creation of metadata by centrally storing annotations, which can be viewed and edited by different annotators. Concepts defined in external ontologies can be imported and used in annotations by connecting Saha to ontology servers. The tool is being tested in practical semantic portal projects.
Provision of semantically rich, ontology-based metadata is one
of the major challenges in developing the Semantic Web. In
recent years, various annotation systems have been developed to
face this challenge [
In order to develop an annotation system that would be easy to use and that would support the creation of semantically rich metadata, we identified four basic requirements for our system. These were also features that we felt were not supported well enough in many of the current annotation platforms: 1) The system should, as a rule, hide technical concepts related to markup languages and ontologies from its user. Typically, this means e.g. hiding URIs and complex class hierarchies from the annotators. This should not, however, be done at the expense of expressiveness of the annotations. 2) Annotations should be based on annotation schemas, which are ontologies that define the structure of annotations and guide annotators in their task. The system should form its user-interface automatically according to the annotation schema loaded in it. 3) The system should support collaborative distributed annotation, where the annotation process can be shared among different annotators at different locations. 4) In order to make the system platform-independent from the annotator’s point of view, it should be implemented as a web application.
It has been widely argued that automation is needed in the
annotation for the Semantic Web [
annotations that cannot be produced automatically. Although requiring a lot of work, such annotation can be seen as a collaborative effort, comparable to the creation of different kinds of Wikis3.
The basic architecture of Saha is depicted in figure 1. It consists of the following functional parts: 1) Saha application, which is run on a web-server. It stores and distributes annotations and creates web-pages which form the user interface used in creating annotations. 2) PostgreSQL-database, which is used to store the Jena’s ontology model containing schema and annotations. 3) Annotators using web browsers to interact with the system.
concepts defined in external ontologies and to share instances created by the annotators.
Annotations can be retrieved in RDF/XML using HTTPGET Saha is a web application implemented using the Apache Cocoon4 and Jena5 frameworks. It is designed as a web application in order to impose as little requirements as possible to the end user’s computational environment. To use Saha, all an annotator needs is an appropriate web browser with an Internet connection. Saha uses extensively techniques such as Javascript and Ajax6 in order to provide annotator with simple and versatile user interface.
The user interface of Saha is comprised of two main pages. In the first page, depicted partly in figure 2, the annotator sees the 3 http://en.wikipedia.org/wiki/Wiki 4 http://cocoon.apache.org/ 5 http://jena.sourceforge.net/ 6 http://www.w3.org/2006/webapi/ annotation classes of an annotation schema and is able to search and open existing annotations or create a new one. The annotator can also create a new subclass for an annotation schema class in order to specify the class hierarchy. This is an optional feature and can be disabled. In order to keep the user interface as simple as possible, more elaborate ontology-editing features, such as creating new properties, are excluded. A new annotation is created by choosing a class and typing the URL of the document to be annotated. Existing annotations can be searched by their labels or by the documents they annotate. In the second page of Saha’s user interface, depicted in figure 3, an annotator can edit annotations and view the documents to be annotated. With Saha, any kind of a document (HTML-page, PDF-document etc.) that can be referenced by a URI can be annotated. However, the web browser being used sets the limits to the kinds of documents that can be viewed in Saha’s user interface7. The annotation page shows properties of the selected annotation class in a simple form, which can be used to supply values for the properties. In figure 3, an annotation belonging to the class “Article” and annotating the document with the URL “http://www.seco.tkk.fi” is shown. The annotation has one literal value defined for the property “Title”. The annotator can edit the value by clicking on it. Defining an object value, such as “Creator” shown in figure 3, is explained in detail in subsection 2.6.
Annotations created in Saha are based on different metadata
annotation schemas, which are defined in OWL. In typical use
scenario, a schema describes some specific area of interest and is
created by an administrator of annotation project. The purpose
of an annotation schema is to define a description template for
annotation construction [
In Saha, annotations are instantiated classes and properties of an
annotation schema, which are linked to the document being
described. The linking plays an essential role in annotations,
because 1) an annotation is separate from the document it
describes, and 2) the way linking is done affects the meaning of
the relation between the annotation and the document. There are
two ways to associate an annotation with a document in Saha.
The first one makes the assertion that the document is an
instance of one specific class defined in the schema. It can be
thus used efficiently to classify documents. An example of this
kind of an annotation is expressed in RDF/XML below:
<saha:article rdf:about=”http://www.seco.tkk.fi/”>
<dc:title>Semantic Computing Research Group</dc:title>
</saha:article>
The second method associates an annotation with the document
by using a named property, which is defined in the annotation
schema. This idea is similar, e.g., to the usage the property
“annotates” in Annotea [
Saha supports collaborative annotation and sharing of annotations through annotation projects. Each annotation schema loaded to Saha forms an annotation project, which can have multiple users as annotators. In practice, an annotation project is a Jena’s ontology model stored in a database. Each user of an annotation project sees all the annotations and KB instances of the project and can edit them, as well as create new ones. An annotation project can belong e.g. to an organization or some other group of people, that are producing annotations using a certain annotation schema. Even though the annotations and KB-instances created in one project cannot be directly edited and used in other projects, KB-instances can be exchanged between projects to allow semantic relations between them (see subsection 2.7).
In addition to describing annotations’ structure in an annotation
schema, we also need a way to define how the schema is actually
used during the annotation process. Although rules defining the
use of a schema could in most cases be expressed using the
schema itself, it is often useful to separate the schema design
from its use [
The classes of annotation schema, which are shown on the class selection page (see figure 2) and which can thus be used to create new annotations.
The property (or properties) of a class, whose value is used as rdfs:label of an instance of the class. These are typically literal properties, like the property “name” of the class “Person”.
The order of properties of a class, in which they are shown on the annotation page (see figure 3).
The classes of the annotation schema whose instances are exported to an ontology service. This feature will be explained later in subsection 2.7.
The meta-schema plays an important role in improving the usability of the system. For example, when an annotator creates a new annotation, the rdfs:label can be automatically constructed for the annotation instance according to the meta-schema, saving the annotator from defining it manually. The meta-schema improves the usability of the system, but it may also enable the use of a same annotation schema in different annotation projects by allowing the schema to be used differently in each project. For example, there may be a different set of annotation classes shown in the class-selection page of each project. The use of the same annotation-schema in different projects enhances the interoperability of annotations as it decreases the need to develop distinct annotation schemas for different projects. In other words, when the same schema is used in different annotation projects, there is no need to specify mappings between annotations created in them.
An annotation schema’s object properties may have two different kinds of values. They can be either concepts defined in an external ontology or, alternatively, KB instances. The rdfs:range can be used to define the types of instances that are allowed as values of a property. If rdfs:range is not defined, an annotator may choose any type of resource he or she wants to use. When a concept of an external ontology is to be used as a value of a certain property, the project’s meta-schema must contain a mapping between the property and the ontology-server hosting the external ontology. According to this mapping, Saha can send the query used to find a concept to the right ontologyserver.
When defining an instance value for a property, the annotator
must first check if the annotation project’s KB already contains
an applicable instance to be used as a value. This is to prevent
annotators from creating multiple KB instances that all refer to
the same resource. If an appropriate instance cannot be found,
the annotator can create a new one. Figure 4 illustrates the
inputfield of object property named “Creator”, which has a class
named “Person” in its range. An annotator has typed in “tom” in
the input-field. The system has searched the KB for the instances
of the class “Person” with an rdfs:label value that contains a
(sub)string “tom”. The search is done on the background using a
technique similar to semantic autocompletion [
An important feature of Saha is its ability to connect to the
ONKI10 ontology service framework developed in the
FinnONTO project [
In addition to providing a way to browse and use concepts defined in external ontologies such as YSO, ONKI-service can be used to share the instances created in different annotation projects. This is done by declaring an annotation schema’s class “public” in the project’s meta-schema. When the annotator creates an instance of public class, the instance’s data will be sent to the ONKI-service. After this, the instance’s URI can be used in other annotation projects using the same ONKI-service. The mechanism described here is practical, as it allows the creation and use of both public and private instances in projects.
Ontology-based semantic annotations are needed when building the Semantic Web. Although various annotation systems and methods have been developed, the question of how to effectively produce quality metadata still remains largely unanswered. Automated systems are of necessity when masses of documents are being annotated. On the other hand, when there is a need to express more complicated semantic structures and when the precision and quality of annotations are important factors, manual systems are still needed. This shows that different approaches to semantic annotation should not be seen as mutually exclusive, but rather completing each other. We have tried to tackle the problem of creating semantically rich annotations by developing an annotation system Saha that supports the distributed creation of metadata and that can be easily used by non-experts in the field of the Semantic Web.
A number of semantic annotation systems and tools exist today
[
Most of the current annotation systems, like the ones mentioned here, are applications that run locally on the annotator’s computer. Because of this, the systems may not necessarily be platform-independent and must always be installed on the user’s system, before the annotation can begin. In Saha, these problems are addressed by implementing the system as a web-application. By doing so, the system can be installed and maintained centrally and the requirements for the annotator’s computational environment are minimal. The way Saha is designed and implemented also strongly supports the collaboration in annotation, making the sharing of annotations easy.
Saha is currently a working prototype. It is in trial use for the
distributed content creation of the semantic health promotion
portal Tervesuomi.fi11 [
Initial feedback from end-users not involved in developing the software has been promising but further experimenting is still needed.
Future plans include using Saha to provide metadata for
additional semantic portals such as CultureSampo14, the next
generation version of the MuseumFinland15 portal [
This research is a part of the FinnONTO project funded mainly by the Finnish Funding Agency for Technology and Innovation (Tekes). 16 http://www.seco.tkk.fi/applications/poka/