\chapter{Ontology management -- tools and projects}
\label{c3:cap3}

% da controllare
\label{s3:intro} Ontology management is a crucial problem within
the Semantic Web. As we have already seen before, ontology evolves
at a high frequency rate, so the ontology management is a key
challenge to exploit the enormous possibilities of the Semantic
Web.

\par We start by describing SI-Designer, the GUI of the Momis project
that supports the designer during the source integration phase. We
insert its description here because it can be seen as an ontology
management tool. In fact, beside its fundamental role during the
integration process, it is also used to construct the Momis
ontology (see sec. \ref{sec3:MomisOntology}).

\par Secondly we will explain the requirements that an ontology
editor should have to be able to handle ontologies during all
their life cycle. Doing this we will better understand the
problems related to changes and the possible solution to keep the
ontology consistent.

\par Afterwards we will present an overview of the existing
tools and projects that aim at helping the user during the
ontologies' development and integration process.


%Mobile Agents for Information Integration S. Bergamaschi G. Cabri

%cia2001.pdf
\section{Sources integration with SI-Designer}
\label{s3:SI-Designer} \emph{\textbf{SI-Designer}} (\textbf{Source
Integrator Designer}) \emph{is a designer support tool for
semi-automatic integration of heterogeneous sources schemata}
(relational, object and semi-structured sources). It has been
implemented within the MOMIS project and it carries out
integration following a semantic approach which uses intelligent
Description Logics-based techniques, clustering techniques and an
extended ODMG-ODL language, \lang{}, to represent schemata
extracted information. Starting from the sources’ \lang{}
descriptions (local schemata), SI-Designer supports the designer
in the creation of an integrated view of all the sources (global
schema) which is expressed in the same \lang{} language.

As described in section \ref{s2bis:Momis}, the integration process
is composed of various steps implemented in separate module. All
the modules involved are available as CORBA Object and interact
using established \texttt{idl} interfaces. In particular the
SI-Designer provides (Fig \ref{sidesigner}) the designer with a
graphical interface to interact with Momis modules showing the
extracted relationships and helping him in the \emph{Common
Thesaurus} construction. Once the \emph{Common Thesaurus} has been
built, SI-Designer uses the \mbox{ARTEMIS} \cite{er97} module to
evaluate a disjoint set of structural similar classes
(\emph{clusters}). Each cluster has a corresponding \emph{global
class} (a view over all similar classes belonging to the cluster)
characterized by a set of global attributes and a
\emph{mapping-table}. SI-Designer automatically generates a set of
global attributes for each global class and a \emph{mapping table}
which maps each global attribute into the local attributes of the
classes in the cluster. \\Then, a semi-automatic interaction with
the designer starts: he may revise the set of global attributes
and the mapping table, to assign a name to each global class, so
as to achieve a global schema.
\begin{figure}[ht]
  \begin{center}
    \epsfig{figure=sidesigner.eps,width=\textwidth,angle=0}
    \caption{SI-Designer Architecture.}\label{sidesigner}
  \end{center}
\end{figure}

The integration process can be divided into two phases:
\begin{enumerate}
    \item Generation of the Common Thesaurus;
    \item Generation of the Global Schema.
\end{enumerate}

At the end of the integration process the Global Virtual View
generated can be exported into a XML DTD, by adding the
appropriate XML TAGs to represent the mapping table relationships.
The use of XML in the definition of the Global Virtual View makes
it possible to use MOMIS infrastructure with other open
integration information system by the interchange of XML data
files. In addition, also the Common Thesaurus is translated into
an XML file, so that MOMIS may provides a shared ontology that can
be used by different semantic ontology languages.


\subsection{Generation of the Common Thesaurus} \label{c3:Cthes}
\par The \emph{\textbf{Common Thesaurus}} \emph{is a set of terminological
intensional and extensional relationships, describing intra and
inter-schema knowledge about classes and attributes of sources
schemas}; it provides a reference to define the identification of
classes candidate to integration and subsequent derivation of
their global representation. In the Common Thesaurus, we express
knowledge in form of \emph{intensional relationships}
(\textmd{SYN}, \textmd{BT}, \textmd{NT}, and \textmd{RT}) and
extensional relationships (\textmd{SYN$_{ext}$},
\textmd{BT$_{ext}$}, and \textmd{NT$_{ext}$}) between classes
and/or attribute names. The Common Thesaurus is constructed
through an \emph{incremental process} during which relationships
are added in the following order:
\begin{enumerate}
    \item \emph{\textbf{Schema-derived relationships}.}\\Intensional and
extensional relationships holding at intra-schema level. These
relationships are extracted analyzing each \lang{} schema
separately. In particular, intra-schema \textmd{RT} relationships
are extracted from the specification of foreign keys in relational
source schemas or complex attributes (relationships) in object
oriented database. When a foreign key is also a primary key both
in the original and in the referenced relation, a \textmd{BT/NT}
relationship is extracted.
    \item \emph{\textbf{Lexical-derived relationships}.}\\Terminological
relationships holding at inter-schema level are extracted by the
SLIM module by analyzing different sources \lang{} schemas
together according to the Wordnet supplied ontology.
    \item \emph{\textbf{Designer-supplied relationships}.}\\Intensional
and extensional relationships supplied directly by the designer,
to capture specific domain knowledge about the source schemata.
This is a crucial operation, because the new relationships are
forced to belong to the Common Thesaurus and thus used to generate
the global integrated schema. This means that, if a nonsense or
wrong relationship is inserted, the subsequent integration process
can produce a wrong global schema. Our system helps the designer
in detecting wrong relationships by performing a
\emph{Relationships validation} step with ODB-Tools. Validation is
based on the compatibility of domains associated with attributes.
For a complete description see \cite{dke99}.
    \item \emph{\textbf{Inferred relationships}.} \\Intensional and extensional new
relationships, holding at intra-schema level, inferred by
exploiting inference capabilities of \mbox{ODB-Tools}.
\end{enumerate}

All these relationships are added to the Common Thesaurus and thus
considered in the subsequent phase of construction of Global
Schema. \\Relationships defined in each step hold at the
intensional level by definition. Furthermore, in each of the above
steps the designer may ``strengthen'' a terminological
relationships SYN, BT and NT between two classes C1 and C2, by
establishing that they hold also at the extensional level, thus
defining also an extensional relationship.


\subsubsection{The WordNet lexical system} We use WordNet \cite{wordnet2}
 lexical system as
\emph{lexicon reference ontology}; this choice is due most to
these reasons: WordNet is a well-known and widespread lexical
database, it seems to be a complete and professional instrument,
is mentioned in many scientific papers and it is continuously
reviewed (for more details see \cite{dke99}). \\Having different
sources, it is however necessary to translate all their attributes
and classes' names in a common language, thus resulting in a
mapping process of all those terms in a well defined set of
concepts (assumed as the WordNet ontology). This mapping process
is often referred to in literature as the \emph{sources annotation
phase}.

%\subsubsection{Sources annotation phase}
\vspace{0.2cm} \noindent \textbf{Sources annotation phase}\\What
exactly the designer is requested for annotating the schema is to
manually choose a WordNet's meaning for each schema element.
Starting from the schema to be integrated, the designer must
declare a relation between each term (class or attribute name) and
the WordNet meaning appropriated for the particular context. Then
the designer must choose one or more meanings for each name. This
is a two-step process.
\begin{description}
    \item [Word form choice] In this step, the WordNet morphologic
processor should aid the designer. A \emph{word form} is the word
without any suffixes due to declination or conjugation. If such
\emph{word form} is not found or there is ambiguity (E.g.
\texttt{axes} has 3 word forms: \texttt{ax} (1 sense),
\texttt{axis} (5 senses), \texttt{axe} (2 senses)), or it is not
satisfactory, the designer can set a custom \emph{word form}.
Notice that this operation, however, does not allow the designer
to physically extend WordNet ontology with his particular
annotation concept. \\About this issue a recent study to extend
WordNet has been conducted by V. Guidetti in her thesis
\cite{tesi:VGuidetti}.
    \item [Meaning choice] The designer can choose to map an element on zero,
one or more senses. For example WordNet has 15 meanings for the
\emph{word form} \texttt{address} from which the most appropriate
ones to the particular context are chosen. Notice that the user
can choose a sense only among the existing ones, that is he is not
able to extend WordNet with his new meanings which could be more
appropriate to the particular domain of interest than the
pre-existing ones.
\end{description}
The relations coming from WordNet are proposed as semantic
relations to be added to the \emph{Common Thesaurus} according to
the following mapping:

\vspace{0,3cm}

 \begin{table}[ht]
     \begin{center}
       \begin{tabular}[h]{l c c c}
       \textbf{Synonymy}: & corresponds to a & \textsc{SYN} & relation\\
       \textbf{Hypernymy}: & corresponds to a & \textsc{BT} & relation\\
       \textbf{Hyponymy}: & corresponds to a & \textsc{NT} & relation\\
       \textbf{Holonomy}: & corresponds to a & \textsc{RT} & relation\\
       \textbf{Meronymy}: & corresponds to a & \textsc{RT} & relation\\
       \textbf{Correlation}: & corresponds to a & \textsc{RT} & relation\\
       \end{tabular}
     \end{center}
   \end{table}

\subsection{Generation of the Global Schema}
\label{s3:global} Here we describe the process to construct the
global ontology, that is, the construction of the global virtual
integrated view (GVV) of the managed sources, its annotation and
the mapping description between the GVV itself and the integrated
sources.

\vspace{0,3cm} Once the Common Thesaurus has been built,
SI-Designer can generate the global class. Such activity is
carried out in the following way:
\begin{enumerate}
    \item \emph{Cluster generation};
    \item \emph{Global class generation}.
\end{enumerate}

%\vspace{0,3cm}\par \textbf{Cluster generation.}
\subsubsection{Cluster generation}
To integrate the \lang~ classes of the different sources into a
global \lang~ \\class, MOMIS employs \emph{\textbf{hierarchical
clustering techniques}} based on the concept of
\textbf{\emph{affinity}}. In this way, MOMIS identifies \lang
classes that describe the same or semantically related information
in different source schemas and give a measure of the level of
matching of their structure. This activity is performed by
\textbf{ARTEMIS} \cite{artemis}, evaluating a set of
\emph{\textbf{affinity coefficients}} for all possible pairs of
\lang~ classes on the basis of the relationships of the common
thesaurus. Affinity coefficients determine the degree of semantic
relationship between two classes based on their names
(\emph{\textbf{name affinity coefficient}}) and on their attribute
refined by the data type validation (\emph{\textbf{structural
affinity coefficient}}). A comprehensive affinity value, called
\emph{\textbf{global affinity coefficient}}, is the linear
combination of the name and structural affinity coefficients.
\emph{The output of the clustering procedure is an}
\emph{\textbf{affinity tree}}. \emph{The leaves represent all the
local classes}: adjacent leaves represent classes with high
affinity, while leaves far apart from each other represent classes
with low affinity; \emph{each node represents a clustering level
and is associated to the affinity coefficient between the
sub-trees (clusters) it joins}. Within SI-Designer, the designer,
at any iteration, can insert a \emph{\textbf{threshold value}}
which is used by ARTEMIS to build \emph{clusters}: \emph{each
cluster is made of all the classes belonging to a sub-tree having
a coefficient at the root node which is higher than the threshold
value}.

%\vspace{0,3cm}\par \textbf{Global class generation.}
\subsubsection{Global class generation} Starting from the output of
the cluster generation, we define, for each cluster, a
\emph{\textbf{Global Class}} that represents the mediated view of
all the classes of the cluster.

For each global class, SI-Designer creates a set of
\emph{\textbf{global attributes}} and, for each of them, it
determines the correspondence with the local attributes (i.e.
those of the classes belonging to the cluster to which the global
class corresponds). In some cases, the correspondence is unique
while in other cases the tool identifies different kinds of
correspondences but can’t solve their ambiguity: in this case the
tool asks the designer to choose the right one. The tool builds
the global attributes set to be associated to a cluster in two
phases: (1) \emph{Union} of the attributes of all the classes
belonging to the cluster; (2) \emph{Fusion} of the ``similar''
attributes. In this phase SI-Designer tries to eliminate
redundancies considering the relationships of the Common
Thesaurus. The fusion process is automatic for the attributes
which are associated by validated relationships while it is not
always automatic when their relationships are not validated.

The attributes having a \emph{valid terminological relationship}
are unified into a unique global attribute. The attribute
unification process is performed automatically for what concerns
names according to the following rules: for attributes that have a
SYN relationship, only one term is selected as the name for the
corresponding global attribute; for attributes that have a BT/NT
relationship, a name which is a broader term for all of them is
selected and assigned to the corresponding global attribute.

\vspace{0.15cm}For each global class a persistent
\emph{\textbf{mapping-table}} storing all the intensional mappings
is generated. The mapping-table is a table whose columns represent
the set of the local classes which belong to the cluster and whose
rows represent the global attributes.

An element \texttt{MT[ag][L]} represents how the global attribute
\texttt{ag} is mapped into the local class \texttt{L}. Each
element \texttt{MT[ag][L]} of the table has to assume one of the
following values:
\begin{itemize}
    \item \texttt{MT[ag][L] = al}: the global attribute \texttt{ag} maps into the al
local attribute.
    \item \texttt{MT[ag][L] = al$_1$ and al$_2$ and \ldots and al$_n$}: this correspondence
is used when the value of the \texttt{ag} attribute is the
concatenation of the value assumed by a set of attributes
\texttt{al$_i$} belonging to the same local class.
    \item \texttt{MT[ag][L] = case of al const$_1$ : al$_1$, \ldots constn : al$_n$}:
this situation occurs when the \texttt{ag} global attribute can
assume one value in a set of \texttt{al$_i$} belonging to the same
local class \texttt{L} and the chosen value depends on a third
attribute, \texttt{al}, which acts as a selector.
     \item \texttt{MT[ag][L] = const}: in this case a global
attribute value does not refer to any local attribute and a
constant value is set by the designer.
     \item \texttt{MT[ag][L] = null}: in this case no attribute
of the class \texttt{L} corresponds to the global attribute
\texttt{ag}.
\end{itemize}


\subsection{The Momis ontology} \label{sec3:MomisOntology} At
this point we can precisely define MOMIS ontology constructed
at the end of the presented process. We can identify the following
components:
\begin{itemize}
    \item \emph{\textbf{local ontologies of the sources}}: a local ontology is a formal
    explicit description of concepts in an information source
    (\emph{classes}), properties of each concept describing various features
    of the concept (\emph{attributes}), and restrictions on instances of
    classes (\emph{integrity constraints}). \\Since this description is
    expressed by a formal language, the local ontology is called also
    \emph{\textbf{local schema}}.
    \item \emph{\textbf{annotation of the local sources}}: having different
    sources, it is necessary to analyze the meaning of the terms in different
    local ontologies with respect to a common \emph{lexicon ontology} as
    Wordnet, that resulting in a mapping of all those terms in a well
    defined set of concepts of the adopted lexicon ontology.
    \item \emph{\textbf{Common Thesaurus}}: correlations among the terms coming
    from different local ontologies; in particular it is a set of terminological
    intensional and extensional relationships, describing intra and
    inter-schema knowledge about classes and attributes of
    sources' schemas;
    \item \emph{\textbf{global ontology}}: it is a \emph{global integrated view} of
    the managed local ontologies and a mapping between the global
    integrated view itself and the integrated local ontologies.
    \\Since the global integrated view  is expressed by a
    formal language (the same language used to express a local
    ontology), the global ontology is called also \textbf{\emph{global schema}}.
    \item \emph{\textbf{annotation of the integrated view}}: meaning of the terms (classes and
    attributes) of the global ontology  with respect to a common
    lexicon.
\end{itemize}

\emph{It is important to note that the last component is new with
respect to the present MOMIS system; it has been conceived during
the study of this thesis}. We will explain how to annotate the
integrated
view in the next chapter.\\

The building of the MOMIS ontology, as we have just seen, is an
incremental process that starts with the acquisition of the
sources' schema, it continues with the extraction of the integrity
constraint rules and of the inter/intra schema relationships
terminating with the building of the Global Virtual View and the
definitions of the mapping rules among the global classes and the
local interfaces. Furthermore we add the annotation of the
integrated view in order to enrich its semantics and expressive
power and preparing the schema to the integration with new
sources. We will describe this issue in details in the next
chapter.

We recall here the fundamental role of ontology to elaborate the
global view, in fact, the cluster generation (that is the core
phase of the process) relies mainly on the exploitation of the
knowledge represented by the ontology.

\vspace{0.5cm} Eventually the Momis ontology can be considered as
an \emph{Application Ontology}, with respect to the classification
given in  section \ref{sec2:tipi}, because it describes concepts
strictly related to a particular domain and dependent on the
specific task they are used for.



% da controllare
% fa riferimento al file EON2002.pdf
\section{Requirements for ontologies editors}
\label{sec2:requisiti} Since an ontology is usually developed
using an ontology editor, many requirements for the ontology
evolution have to be part of the ontology editors. An ontology
editor must provide an interface that allows the knowledge
engineer to modify the underlying ontology. The interface is based
on the set of available ontology changes. Moreover, there are many
features which can significantly improve the usability of an
ontology editor and enhance its functionality regarding the
ontology evolution.

Following \cite{Stojanovic2002} we can divide these requirements
in several groups:
\begin{itemize}
    \item \emph{Functional requirement} specifies all evolution changes that must be supported;
    \item \emph{User's supervision requirement} enables the user-driven process of change resolving;
    \item \emph{Transparency requirement} deals with providing control of the evolution process
    through an insight into the scope of an evolution operation before the operation is applied;
    \item \emph{Reversibility requirement} states how the effect of evolution changes can be undone;
    \item \emph{Auditing requirement} is related to the management of the ontology change history;
    \item \emph{Ontology refinement requirement} provides support for continual ontology improvement;
    \item \emph{Usability requirement} allows the user to manage changes more easily by finding
    ontology inconsistencies and providing the explanation to solve them.
\end{itemize}

Now a more detailed explanation of these requirements will be
presented. In this way we can improve the comprehension of the
complexity that an ontology editor have to face.

It is important to note that it is very difficult to find an
editor that accomplish to all these requirements, because of the
high level of complexity and completeness of such an editor, but
it can be useful to understand the ``ideal'' characteristics of an
editor if we want to evaluate easily the ``real'' tools we will
present later in section \ref{s3:tools}.


\subsubsection{Functional requirement} The functional requirement
specifies which functionality must be provided for the
\emph{ontology development and evolution}. This functionality
heavily depends on the underlying \emph{ontology model}. The more
powerful and expressive model requires a richer set of modelling
primitives. Thus, before speaking about functional requirements,
the notion of an ontology itself has to be clarified. As we have
already seen there is not a standard ontology model, but there are
several attempts to achieve this objective. \\Due to differences
in ontology models, we concentrate on the ``common'' features of
ontology models, namely \emph{concepts}, \emph{properties},
\emph{instances}, as well as \emph{concept inheritance}. Each of
these ontology entities can be updated by one of the meta-change
transformations: \emph{add}, \emph{remove}, \emph{modify}. \\The
existence of the ``modify'' change causes the set of primitives
not to be minimal with respect to completeness. However, this
change adds some important semantic variants to the set of
changes, since a modify change is not equivalent to a removal
followed by an addition. The difference is that the modification
of an entity (i.e. renaming a concept) maintains its identity,
while removing and adding loses its identity.\\The previous
changes are called \emph{elementary} changes since they cannot be
decomposed into simpler changes. Elementary changes in the
ontology specify fine-grained changes that can be performed in the
course of ontology evolution. However, this granularity is not
always appropriate. Often, the \emph{intent} of the changes may be
expressed on a higher level. \emph{Composite} changes specify
coarse-grained changes that can be performed to improve the
ontology structure according to some criteria. They are more
powerful, since the designer does not need to go through every
step of the sequence of basic changes to achieve the desired
effect. Moreover, composite changes often have more meaningful
semantics. For example, the semantics of moving the concept from
one parent concept to another is clearly different from the
semantics of removal and addition of a \texttt{subConceptOf}
relation. While ``move'' as a composite change maintains the
identifiers of a \texttt{subConceptOf} relation and preserves all
properties and instances, the removal and subsequent addition
create a new identifier for a \texttt{subConceptOf} relation and
cause the loss of much information (e.g. at the instance level).
Changes are applied to an ontology in a valid state, and after all
changes are performed, the ontology and dependent artifacts must
evolve to another valid state.

\subsubsection{User's supervision requirement} The ontology evolution
is a process of changing an ontology while \emph{maintaining its
consistency}. However, there are many ways to achieve consistency
after a change request. For example, when a concept from the
middle of the hierarchy has been deleted, all subconcepts may
either be deleted or reconnected to other concepts. If subconcepts
are preserved, then properties of the deleted concept may be
propagated, its instances distributed, etc. Thus, \emph{for each
change in the ontology, it is possible to generate different sets
of additional changes, leading to different final consistent
states}.
\\Hence, a mechanism is required for users to manage changes
resulting not in an arbitrary consistent state, but in a
consistent state fulfilling the user’s preferences. In order to
enable the user to obtain the ontology most suitable to her needs,
an ontology editor should allow the customization of the ontology
evolution process. One mean is to enable the user to set up one of
\emph{evolution strategies} that are used for resolving the
changes. \\\emph{An evolution strategy} unambiguously defines the
way how elementary and composite changes will be resolved.
Typically, a particular evolution strategy is chosen by the user
at the start of the ontology evolution process. Thus, an evolution
strategy defining a common policy must be chosen to specify how to
handle each of the following situations:
\begin{itemize}
    \item [-] how to handle orphaned concepts - those concepts that don't have
    parents any more;
    \item [-] how to handle orphaned properties - those properties
    that don't have parents any more;
    \item [-] how to propagate properties to the concept whose parent changes;
    \item [-] what constitutes a valid domain of a property;
    \item [-] what constitutes a valid range of a property;
    \item [-] whether a domain (range) of a property can contain a concept that
    is at the same time a subconcept of some other domain (range) concept;
    \item [-] the allowed shape of the concept hierarchy;
    \item [-] the allowed shape of the property hierarchy;
\end{itemize}
For each of these situations, there is a set of possible options,
e.g. in case of the first issue, orphaned subconcepts of a concept
may be connected to the parent concept(s) of that concept,
connected to the root concept of the hierarchy or deleted as well.

\subsubsection{Transparency requirement} A change in one part of an
ontology may have far reaching \emph{consequences} on other parts
of the ontology and associated instances. If an ontology is large,
it may be difficult to fully comprehend the extent and meaning of
each change. To improve understanding of effects of each change,
the ontology evolution should provide maximum transparency into
details of each change being performed. Transparency should
provide a human-computer interaction for evolution by presenting
change information in an orderly way, allowing easy spotting of
potential problems and alleviating the understanding of the scope
of the change. \\Before any change is applied to the ontology, a
list of all implications must be generated and reported to the
user. The ontology engineer should approve or cancel the changes.
If the changes are cancelled, the ontology should remain intact.

\subsubsection{Reversibility requirement} There are numerous
circumstances where it may be desired to reverse the effects of
changes. The reversibility requirement states that an ontology
editor has to allow \emph{undoing changes} at the user’s request.
Consequently, the user can control changes and make appropriate
decisions. \\It is important to note that reversibility means
undoing all effects of a change, which may not be the same as
simply requesting an inverse change manually. For example, if a
concept is removed from a concept hierarchy, its subconcepts will
be modified (e.g. attached to the root). Reversing such change is
not equal to recreating the deleted concept – one also needs to
revert the concept hierarchy into an original state.

\subsubsection{Auditing requirement} Often business applications use
ontologies, so the need for auditing ontology evolution become
more important and changes to business information are accompanied
with responsibility for their effects on the business. Auditing is
therefore a typical component of business systems, and must be
reflected in the ontology evolution as well. \\The ontology
evolution auditing involves the following aspects:
\begin{itemize}
    \item Keeping a detailed log of all performed changes allowing later
    reconstruction of the events that led to the current state of the
    ontology;
    \item Associating meta-information with each log change,
    such as textual change description, cost of change, time of change
    etc.;
    \item Tracking the identity of the change author.
\end{itemize}
The auditing requirement is also related to the reversibility
requirement, since the auditing log is typically used to provide
reversibility. The auditing log can also serve as a source for
information mining about change trends.

\subsubsection{Ontology refinement requirement} This requirement states
that potential changes improving the ontology may be discovered
semi-automatically from the ontology-based data and through the
analysis of the user’s behaviour. We distinguish (i)
\emph{structure-driven}, (ii) \emph{data-driven} and (iii)
\emph{usage-driven} change discovery.

(i) The \emph{structure-driven change discovery} identifies some
heuristics to improve an ontology, based on the analysis of the
structure of the ontology: for example, if all subconcepts have
the same property, the property may be moved to the parent concept
or if a concept has a single subconcept it should be merged with
its subconcept. A concept without properties is a candidate for
deletion

(ii) The \emph{data-driven change discovery} states that some
changes are implicit changes in the domain, reflected in its
instances and can be discovered only through their analysis. A set
of heuristics is necessary, for example: a concept with no
instances may probably be deleted; a concept with many instances
is a candidate for being split into subconcepts and its instances
distributed among newly generated concepts.

(iii) The \emph{usage–driven ontology evolution} takes into
account the usage of the ontology in the knowledge management
system. It is based on the analysis of the users’ behaviour in two
phases of a knowledge management cycle: in providing knowledge by
analysing the quality of annotations, and in searching for
knowledge by analysing the users’ queries and the responses from
the knowledge repository. For example, by tracking when the
concept was last retrieved by a query, it may be possible to
discover that some concepts are out of date and should be deleted
or updated.


\subsubsection{Usability requirement} An ontology editor has to
have an \emph{interface} that enables the user to create and
maintain ontologies, one that is easily understood and allows the
user to work efficiently with all the complexities inherent in an
ontology editor. An ontology editor has to guide the user through
the ontology development process by providing additional
information, such as why the user’s activity did not succeed, or
what else he/she has to do in order to finish the current
activity. Moreover, a good ontology editor must provide
capabilities for identifying inconsistencies. When such conflicts
arise, an editor must assist the user in identifying the source of
the problem and resolving it.


%
% prendere da D1.3 di OntoWeb, Klein e Motik
%
\section{Comparison of ontologies tools}
\label{s3:tools} In the last years, a high number of environments
for ontology construction and ontology use have been conceived.
Tool support is really important both for the ontology development
process (ontology building, annotation, merge, etc.) and for the
ontology usage in applications, such as electronic commerce,
knowledge management, the Semantic Web, etc.

Tools can be divided into two big categories according to
\cite{Del1.3}:

\vspace{0.3cm} \textbf{Ontology development tools}. This group
include tools, environments and suites that can be used for
building a new ontology from scratch or reusing existing
ontologies. Apart from the common edition and browsing
functionality, these tools usually include ontology documentation,
ontology exportation and importation from different formats,
graphical views of the ontologies built, ontology libraries,
attached inference engines, etc.

\vspace{0.3cm}\textbf{Ontology merge and integration tools}. These
tools have been conceived to solve the problem of merging or
integrating different ontologies on the same domain. This need
becomes apparent when two companies or organizations are merged
together, or when it is necessary to obtain a better ontology from
other existing ontologies in the same domain.

\vspace{0.3cm} Now we present some of the most important tools
following the work done by the members of the
Ontology-environments SIG in the OntoWeb project \cite{Del1.3}.
Afterwards some critical comments are reported (page
\pageref{s3:comments1} and \pageref{s3:comments2}).

\subsection{Ontology development tools}
\label{s3:ODT} In this section we will present the most important
tools that can be used to build an ontology from scratch or to
reuse other existing ontologies. A brief description of each tool
will be provided. Information about its main features and
functionalities and its relationship with KR (knowledge
representation) formalisms will be illustrated.

\subsubsection{OILEd}
OILEd is a graphical ontology editor developed by the University
of Manchester that allows the user to build ontologies using
DAML+OIL.\\

The knowledge model of OILEd is based on that of DAML+OIL,
although this is extended by the use of a frame-like presentation
for modelling. Thus OILEd offers a familiar frame-like paradigm
for modelling while still supporting the rich expressiveness of
DAML+OIL where required. Classes are defined in terms of their
superclasses and property restrictions, with additional axioms
capturing further relationships such as disjointness. The
expressive knowledge model allows the use of complex composite
descriptions as role fillers.

The main task that OILEd is targeted at is that of editing
ontologies or schemas, as opposed to knowledge acquisition or the
construction of large knowledge bases of instances. Although
functionality is provided that allows the definition of
individuals, this is primarily intended for the definition of
nomimals, which are used in the DAML+OIL one-of construction.

A key aspect of OILEd’s behaviour is the use of the FaCT reasoner
to classify ontologies and check consistency via a translation
from DAML+OIL to the SHIQ description logic. This allows the user
to describe their ontology classes and have the reasoner determine
the appropriate place in the hierarchy for the definition.

The DAML+OIL RDF Schema is used for loading and storing
ontologies. In addition, the tool will read and write concept
hierarchies in pure RDF and will render ontology definitions as
HTML for browsing and as SHIQ for later classification by the FaCT
reasoner.

OILEd version 3.4 is implemented in Java and is freely available
from the OILEd web site. Further information and relevant
publications are also available at the web site.\\

URL: http://oiled.man.ac.uk/

\subsubsection{OntoEdit} \label{s3:ontoedit}
OntoEdit is an Ontology Engineering Environment supporting the
development and maintenance of ontologies by using graphical
means. OntoEdit has been developed by OntoPrise GmBH
\footnote{http://www.ontoprise.de/}.\\

OntoEdit is built on top of a powerful internal ontology model.
This paradigm supports representation-language neutral modelling
as much as possible for concepts, relations and axioms. Several
graphical views onto the structures contained in the ontology
support modelling the different phases of the ontology engineering
cycle.

The tool allows the user to edit a hierarchy of concepts or
classes. These concepts may be abstract or concrete, which
indicates whether or not it is allowed to make direct instances of
the concept. A concept may have several names, which essentially
is a way to define synonyms for that concept. As it happens in the
well-known ``copy-and-paste'' functionality, the tool permits the
reorganizing of concepts within the hierarchy.

The tool is based on a flexible plugin framework. Firstly this
easily makes it possible to extend functionality in a modularized
way. The plugin interface is open to third parties which enables
users to extend OntoEdit easily by additionally needed
functionalities. Secondly, having a set of plugins available like
e.g. a domain lexicon, an inferencing plugin and several export
and import plugins, this allows for user-friendly customization to
adapt the tool to different usage scenarios.

Currently the version 2.6 is available. The Professional Version
of OntoEdit contains many more plugins than the free version.
Beside others the functionality is extended by (i) an inferencing
plugin for consistency checking, classification and execution of
rules, (ii) collaborative engineering of ontologies and (iii) an
ontology server for administration of ontology libraries,
collaborative sharing of ontologies and a persistent storage for ontologies.\\

OntoEdit web portal contains tutorials, technical documents,
version details, plug-ins and there is the possibility to download
a free version and have information and costs of professional
version.\\

URL: http://www.ontoprise.de/ontoedit\_en.htm

\subsubsection{Prot\'eg\'e-2000} \label{l3:protege}
Prot\'eg\'e-2000 is the latest tool in an established line of
tools developed at Stanford University for knowledge acquisition.
Prot\'eg\'e- 2000 is freely available for download under the
Mozilla open-source license from the web site.\\

Prot\'eg\'e-2000 provides a graphical and interactive
ontology-design and knowledge-base development environment. It
helps knowledge engineers and domain experts to perform
knowledge-management tasks. Ontology developers can have quik
access to relevant information whenever they need it, and can use
direct manipulation to navigate and manage an ontology. Tree
controls permits quick and simple navigation through a class
hierarchy. Prot\'eg\'e uses forms as the interface for filling in
slot values.

The \emph{knowledge model} of Prot\'eg\'e-2000 is OKBC-compatible.
It includes support for classes and the class hierarchy with
multiple inheritance; template and own slots; specification of
pre-defined and arbitrary facets for slots, which include allowed
values, cardinality restrictions, default values, and inverse
slots; metaclasses and metaclass hierarchy.

One of the major advantages of the Prot\'eg\'e-2000 architecture
is that the system is constructed in an open, modular fashion. Its
component-based architecture enables system builders to add new
functionality by creating appropriate plugins. The Prot\'eg\'e
Plugin Library \\ (http://protege.stanford.edu/plugins.html)
contains contributions from developers all over the world.

Most plugins fall into one of the three categories: (1)
\emph{backends} that enable users to store and import knowledge
bases in various formats; (2) \emph{slot widgets}, which are used
to display and edit slot values or their combination in a
domain-specific and task-specific ways, and (3) \emph{tab
plugins}, which are knowledge-based applications usually tightly
linked with Prot\'eg\'e knowledge bases.

Current \emph{backend plugins} (and standard backends) include
support for storing and importing ontologies in RDF Schema, XML
files with a DTD, and XML Schema files. The development of
DAML+OIL support is in its final stages. Available \emph{slot
widgets} include user-interface components to display GIF images,
as well as video and audio. A diagram widget allows developers to
build elements of a knowledge base by drawing a diagram in which
nodes and edges are themselves frames of particular types
(distinguished by shape and color).

Currently available \emph{tab plugins} provide capabilities for
advanced visualization, ontology merging and version management,
inferencing, and so on.

The OntoViz and Jambalaya tabs, for example, present different
graphical views of a knowledge base, with the Jambalaya tab
allowing interactive navigation, zooming in on particular elements
in the structure, and different layouts of nodes in a graph to
highlight connections between clusters of data.

Some tabs provide support to express constraints on the data.
Other tabs (for instance PAL) provide inference engine capable to
analyze data and to tell the users which constraints the instances
in the knowledge base violate and how.

The PROMPT tab provides an environment for managing multiple
ontologies (see also next section). Its components include tools
for ontology merging that help the user to find similarities
between source ontologies and to merge the ontologies; for
ontology versioning, which automatically finds a structural
``diff'' between versions of an ontology; and for extracting
semantically complete subparts of an ontology and rearranging
frames in different linked ontologies.

The UMLS and WordNet tabs enable users to import and integrate
elements of the large on-line knowledge sources into their
ontologies.\\

The project portal is useful to find documentations, ontologies,
tutorials and to download the tool and the plug-ins.\\

URL: http://protege.stanford.edu/


\subsubsection{WebODE} \label{l3:webode}
WebODE is an ontological engineering workbench that provides
varied ontology related services and covers and gives support to
most of the activities involved in the ontology development
process and in the ontology usage. It is built on an application
server basis, which provides high extensibility and usability by
allowing the easy addition of new services and the use of existing
services. It has been developed by the Ontology \& Knowledge Reuse
Group (AI Lab), from the Artificial Intelligence Department of the
Computer Science Faculty (FI) from the Technical University of
Madrid (UPM).\\

WebODE ontologies are represented using a very expressive
\emph{knowledge model}, based on the reference set of intermediate
representations of the \emph{METHONTOLOGY} methodology, which
includes ontology components such as concepts (with instance and
class attributes), partitions, adhoc binary relations, predefined
relations (taxonomic and part-of ones), instances, axioms, rules,
constants and bibliographic references. It also allows the
importation of terms from other ontologies, through the use of
imported terms.\\

Ontologies in WebODE are stored in a relational database.
Moreover, WebODE provides a well-defined service-oriented API for
ontology access that makes easy the integration with other
systems. Ontologies built with WebODE can be easily integrated
with other systems by using its automatic \emph{exportation} and
importation services from and into XML, its translation services
into and from varied ontology specification languages (currently,
RDF(S), OIL, DAML+OIL, CARIN and FLogic), and its translation
services to other languages and systems, such as Java.\\

Ontology edition in the WebODE ontology editor is aided both by
form based and graphical user interfaces, a user-defined views
manager, a \emph{consistency checker}, an \emph{inference engine},
an \emph{axiom builder} and the \emph{documentation service}. Two
interesting and novel features of WebODE with respect to other
ontology engineering tools are: instance sets, which allow to
instantiate the same conceptual model for different scenarios, and
conceptual views from the same conceptual model, which make it
possible to create and store different parts of the ontology,
highlighting and/or customizing the visualization of the ontology
for each
user.\\

The graphical user interface make it possible to browse all the
relationships defined on the ontology as well as graphical-pruning
these views with respect to selected types of relationships.
Mathematical properties such as reflexive, symmetric, etc. and
other user-defined properties can also be attached to the ``ad
hoc'' relationships.\\

The collaborative edition of ontologies is ensured by a mechanism
that allows users to establish the type of access of the
ontologies developed, through the notion of groups of users.
\emph{Synchronization mechanisms} also exist that allow several
users to edit the same ontology without errors.

Constraint checking capabilities are also provided for type
constraints, numerical values constraints, cardinality constraints
and taxonomic consistency verification (i.e., common instances of
disjoint classes, loops, etc.).

Finally, WebODE’s inference service has been developed in Ciao
Prolog. A subset of the OKBC primitives has been defined in prolog
for their use in this inference engine. Additionally, the WebODE
Axiom Builder transforms first-order logic axioms and rules into
Prolog, if possible, so that they can be used in it as well.

On the web site is possible to find documents related to the
project.\\

URL: http://delicias.dia.fi.upm.es/webODE/


\subsubsection{Comments}
\label{s3:comments1} Now some comments and observations related to
the previous tools will be presented.

All editors permit elementary changes, but only OntoEdit provides
support for some composite changes with its functionality
``copy-and-paste''.

Most of the existing systems provide only one possibility for
realizing a change, and this is usually the simplest one. It means
that users are not able to control the way changes are performed
(supervision). Moreover, users hardly obtain explanations why a
particular change is necessary (transparency). Furthermore, there
is no possiblity to undo effects of changes (reversibility).  None
of the existing development systems offer support for
semi-automatic ontology improvement.

About software architecture and platform, most of the tools are
moving towards Java platforms, and most of them already have an
extensible architecture. Some of them are available open source
and can be extended by the users (OILEd, Prot\'eg\'e2000,
OntoEdit). In certain cases functionalities can be added with
plugins (Prot\'eg\'e2000, OntoEdit). Only OntoEdit prof.,
Prot\'eg\'e2000 and WebODE store ontologies in databases, while
other store ontologies in files.

Almost all tools have a good capability to import and to export
ontologies from and to many different languages: XML, OIL, RDF(S),
DAML+OIL are the most important.

Otherwise there are two families of tools from the KR paradigm:
description-logic based tools, such as OILEd; and the rest of
tools, which permit to represente knowledge following a hybrid
approach based on frames and first order logic.

An important aspect to observe is the inference service provided
by each tool. In particular we mean built-in inference engines,
constraint and consistency checking mechanisms, automatic
classification and exception handling. OntoEdit prof. uses
OntoBroker, OILEd performs inference using the FACT inference
engine, Prot\'eg\'e2000 and WebODE use internal inference engine,
PAL and Prolog respectively.

WebODE has interesting functionality to permit the collaborative
edition of ontologies and a synchronization mechanism to avoid
errors.

As regards usability, each tool tries to provide special
functionality to help the user with the visualization of the
ontologies or the navigation, or some zooming options, or
customization.

%
% Potrei riportare le tabelle comparative del deliverable
%

\subsection{Ontology merge and integration tools}
\label{s3:OMIT} In this section we will present the most important
tools that can be used to merge or to integrate two or more
ontologies. A brief description of each tool will be provided.
Information about its main features and functionalities will be
illustrated.

\subsubsection{Chimaera} \label{s3:Chimaera} Chimaera is a
merging and diagnostic web-based browser ontology environment
developed by the Knowledge Systems Laboratory at Stanford
University.\\

Chimaera is built on a platform that handles any OKBC compliant
representation system. Chimaera accepts over 15 designated input
format choices (such as ANSI KIF, Ontolingua, Prot\'eg\'e,
CLASSIC, XOL, etc.) as well as any other OKBC compliant form. It
will soon be compliant with other emerging standards such as RDF
and DAML.

Chimaera contains a simple editing environment in the tool and
also allows the user to use the full Ontolingua editor/browser
environment for more extensive editing. Ontolingua is not a
requirement however; other editors could be used in its place. It
facilitates \emph{merging} by allowing users to upload existing
ontologies into a new workspace (or into an existing ontology).
Chimaera will suggest \emph{potential merging candidates} based on
a number of properties. It generates a name resolution list that
may be used as a guide through the merging task. The user sees a
display of the places where the two terms appear in the hierarchy
(with only the connected portions of the hierarchy displayed). The
user may browse the hierarchy in more details by doing things like
expanding subclasses. The user may also view the definitions of
the terms and, within Ontolingua, also obtain the results of
similar and different structural comparisons of the definitions.
The user may then choose to merge the terms with a simple menu
choice from the class menu. Chimaera allows the user to choose the
level of vigor with which it suggests merging candidates. Higher
settings, for example will look for things like possible acronym
expansion (which was extremely valuable in the use of Chimaera on
some government knowledge bases).

Chimaera also supports a taxonomy resolution mode. It looks for a
number of syntactic term relationships (such as $<X-Y>$ and $<Y>$
since the two are usually subclass related). When attached to a
classifier, it can look for semantic subsumption relationships as
well.

Chimaera includes an analysis capability that allows users to run
a diagnostic suite of tests selectively or in their entirety. The
output is displayed as an interactive log that allows users to see
the results of the tests and also to explore the results. The
tests include incompleteness tests, syntactic checks, taxonomic
analysis, and semantic checks. This is essentially a ``to-do''
list containing updates that would likely need to be done before
the ontologies would be of the most use. The list contains things
such as terms that are used but that are not defined, terms
that have contradictory ranges, cycles detected in the ontology
definitions.

On Chimaera web site it is possible to find documents and
tutorials. Moreover you can demo Chimaera on line and find fully
functional
version at http://www-ksl-svc.stanford.edu/ after the login.\\

URL: http://www.ksl.stanford.edu/software/chimaera/


\subsubsection{PROMPT} \label{s3:Prompt} PROMPT is a tool for
semi-automatic guided ontology merging. It is a plugin for
Prot\'eg\'e-2000 (see page \ref{l3:protege}).\\

PROMPT leads the user through the ontology-merging process,
identifying possible \emph{points of integration}, and
\emph{making suggestions} regarding what operations should be done
next, what \emph{conflicts} need to be resolved, and how those
conflicts can be resolved. PROMPT's ontology-merging process is
interactive. A user makes many of the decisions, and PROMPT either
performs additional actions automatically based on the user's
choices or creates a new set of suggestions and identifies
additional conflicts among the input ontologies.

The tool takes into account different features in the source
ontologies to make \emph{suggestions} and to look for
\emph{conflicts}. These features include:
\begin{itemize}
    \item names of classes and slots (e.g., if frames have
    similar names and the same type, then they are good candidates for merging)
    \item class hierarchy (e.g., if the user merges two classes and PROMPT
    has already thought that their superclasses were similar, it will
    have more confidence in that suggestion, since these superclasses
    play the same role of the classes that the user declared as the same)
    \item slot attachment to classes (e.g., if two slots from different
    ontologies are attached to a merged class and their names, facets,
    and facet values are similar, these slots are candidates for merging)
    \item facets and facet values (e.g., if a user merges two slots, then
    their range restrictions are good candidates for merging)
\end{itemize}
In addition to providing suggestions to the user, PROMPT
identifies conflicts. Some of the \emph{conflicts} identified by
PROMPT are:
\begin{itemize}
    \item name conflicts (more than one frame with the same name),
    \item dangling references (a frame refers to another frame that does
    not exist),
    \item redundancy in the class hierarchy (more than one path from a
    class to a parent other than root),
    \item slot-value restrictions that violate class inheritance.
\end{itemize}
The features in the list above employ the graph structure of the
ontologies to a limited extent: we traverse the nodes that are
only one or two steps away. Anchor-PROMPT is an extension of
PROMPT that compares the graph structure on a larger scale. It
takes as input a set of anchors{-}pairs of related terms defined
by the user or automatically identified by lexical matching.
Anchor-PROMPT treats an ontology as a graph with classes as nodes
and slots as links. The algorithm analyzes the paths in the
subgraph limited by the anchors and determines which classes
frequently appear in similar positions on similar paths. These
classes are likely to represent semantically similar concepts.

In terms of \emph{user support}, the PROMPT tool has the following
features:
\begin{itemize}
    \item Setting the preferred ontology. It often happens, that the
source ontologies are not equally important or stable, and that
the user would like to resolve all the conflicts in favor of one
of the source ontologies. We allow the user to designate one of
the ontologies as preferred. When there is a conflict between
values, instead of presenting the conflict to the user for
resolution, the system resolves the conflict automatically.
    \item Maintaining the user's focus. Assuming a user is merging two large
ontologies and is currently working in one content area of the
ontology, PROMPT maintains the user’s focus by rearranging its
lists of suggestions and conflicts and presenting first the items
that include frames related to the topics of the latest
operations.
    \item Providing feedback to the user. For each of its
suggestions, PROMPT presents a series of explanations, starting
with the reason why it suggested the operation in the first place.
If PROMPT then changes the operation placement in the suggestions
list, it also explains why it moved the operation.
\end{itemize}

URL: http://protege.stanford.edu/

\subsubsection{ODEMerge} \label{s3:ODEMerge} ODEMerge is a tool
to merge ontologies that is integrated in WebODE, the software
platform to build ontologies developed by the
Ontology Group at Technical Universitiy of Madrid (see page
\ref{l3:webode}). Therefore it is a \emph{client-server tool} that
works in the Web. This tool is a partial software support for the
methodology for merging ontologies elaborated by de Diego (de
Diego, R. \emph{M\'etodo de mezcla de cat\'alogos electr\'onicos}.
Final Year Project. Facultad de Inform\'atica de la Universidad
Politécnica de Madrid. Spain. 2001). This \emph{methodology}
proposes the following steps: 1) transformation of formats of the
ontologies to be merged; 2) evaluation of the ontologies; 3)
merging of the ontologies; 4) evaluation of the result; and 5)
transformation of the format of the resulting ontology to be
adapted to the application where it will be used.

The methodology establishes in a very detailed way: what tasks we
need to carry out when we have to merge two ontologies, when we
have to do these tasks, who must perform each task, how he must
carry it out, and what the products of each tasks are. For the
evaluation and merging of ontologies, very detailed rules are
proposed. The methodology is based on the experience merging
e-commerce ontologies.

WebODE helps in steps (1), (2), (4) and (5) of the merging
methodology, and ODEMerge carries out the merge of taxonomies of
concepts in step (3). Besides, ODEMerge helps in the merging of
attributes and relations, and it incorporates many of the rules
identified in the methodology. ODEMerge uses the following
\emph{inputs}: the source ontology 1 to be merged; the source
ontology 2 to be merged; the \emph{table of synonyms}, which
contains the synonymy relationships of the terms of the ontology 1
with the terms of the ontology 2; the \emph{table of hyperonyms},
which contains the hyperonymy relationships of the terms of the
ontology 1 with the terms of the ontology 2.

ODEMerge processes the ontologies together with the information of
the tables of synonymy and hyperonymy, and it generates a new
ontology, which is the merge of the ontology 1 and the ontology 2.
That is, the tool compares the ontology 1 with the ontology 2
considering the tables of synonymy and hyperonymy, and it merges
these ontologies. An important characteristic of ODEMerge is that
it can be used to merge ontologies in so many ontology
implementation languages as the ones that WebODE processes, since
WebODE is the host platform of ODEMerge. The WebODE import module
allows importing ontologies written in XML, RDF(S) or CARIN, and
allows exporting into XML, RDF(S), OIL, DAML+OIL, CARIN, FLogic,
Prolog, Java and HTML.\\

URL: http://delicias.dia.fi.upm.es/webODE/

\subsubsection{FCA-Merge} \label{s3:FCA-Merge}
FCA-Merge is a \emph{method} for merging ontologies, which follows
a bottom-up approach offering a global structural description of
the merging process. For the source ontologies, it extracts
instances from a given set of domain-specific text documents by
applying natural language processing techniques. Based on the
extracted instances mathematically founded techniques are applied
to derive a lattice of concepts as a structural result of
FCA-Merge. The result obtained is explored and transformed into
the merged ontology by the ontology engineer.

This method is based on application-specific instances of the two
given ontologies $O_1$ and $O_2$ that are to be merged. The
overall process of merging two ontologies consists of three steps,
namely (i) instance extraction and computing of two formal
contexts $K1$ and $K2$, (ii) the FCAMerge core algorithm that
derives a common context and computes a concept lattice, and (iii)
the interactive generation of the final merged ontology based on
the concept lattice.

The extraction of instances from text documents avoids the problem
that in most applications there are no objects which are
simultaneously instances of the source ontologies, and which could
be used as a basis for identifying similar concepts.

This method takes the two ontologies and a set $D$ of natural
language documents as input data. The documents have to be
relevant to both ontologies, so that the documents are described
by the concepts contained in the ontology. The documents may be
taken from the target application, which requires the final merged
ontology. From the documents in $D$, instances are extracted. This
automatic knowledge acquisition step returns a formal context for
each ontology indicating which ontology concepts appear in which
documents.

The extraction of the instances from documents is necessary
because there are usually no instances which are already
classified by both ontologies. However, if this situation is
given, one can skip the first step and use the classification of
the instances directly as input for the two formal contexts.

The second step of the ontology merging approach comprises the
FCA-Merge core algorithm. The core algorithm merges the two
contexts and computes a concept lattice from the merged context
using FCA techniques. More precisely, it computes a pruned concept
lattice which has the same degree of detail as the two source
ontologies.

Instance extraction and the FCA-Merge core algorithm are fully
automatic. The final step of deriving the merged ontology from the
concept lattice requires human interaction. Based on the pruned
concept lattice and the sets of relation names $R1$ and $R2$, the
ontology engineer creates the concepts and relations of the target
ontology.

For obtaining good results, a few assumptions have to be met by
the input data: firstly, the documents have to be relevant to each
of the source ontologies. A document from which no instance is
extracted for each source ontology can be neglected for the task.
Secondly, the documents have to cover all concepts from the source
ontologies. Concepts that are not covered have to be treated
manually after the merging procedure (or the set of documents has
to be expanded). And last but not least, the documents must
separate the concepts well enough. If two concepts that are
considered as different always appear in the same documents,
FCA-Merge will map them to the same concept in the target ontology
(unless this decision is overruled by the knowledge engineer).
When this situation appears too often, the knowledge engineer
might want to add more documents that further separate the
concepts.

Reference: B. Ganter, R. Wille: \emph{Formal Concept Analysis:
Mathematical foundations}. Springer, Berlin-Heidelberg 1999


\subsubsection{Comments}
\label{s3:comments2} The first thing we can notice is the higher
level of \emph{heterogeneity} of these tools with respect to the
development tools. In fact the differences among the tools
presented are more apparent than in the previous case.

Merging tools are different in the \emph{output} they can provide,
in the \emph{input} they need, in the \emph{capabilities} they
have during the merging process, in the \emph{intervention} of the
designer, besides the normal difference related to architecture
and methodology.

Now we try to present some comments and observations to better
understand better the characteristic of each tool.

We can start observing that PROMPT and ODEMerge are integrated in
Prot\'eg\'e2000 and WebODE, respectively (see the previous sec.).
Chimaera, instead, is based on a web-browser environment.

All the tools are able to integrate ontologies expressed in
different \emph{languages} (XML, RDF(S), OIL, etc.).

An important issue for merging tools is the \emph{input} they need
to work. Some tools deal only with class hierarchies of the
sources and are agnostic in their merging algorithms about slots
or instances (e.g. Chimaera). Other tools use not only classes but
also slots and value restrictions in their analysis (e.g. PROMPT).
Another set of tools require not only that instances are present,
but also that source ontologies share a set of instances (e.g.
FCA-Merge). Besides the two ontologies to merge, ODEMerge
eventually requires the table of synonyms and the table of
hyperonyms in order to conduct the process.

Also regarding the \emph{interactivity} with the designer there
are different approaches. FCA-Merge works independently and
produce suggestions to the user at the end, allowing the user to
analyze the suggestions. PROMPT and Chimaera rely heavily on
interaction with the designer and base their analysis not only on
the source ontologies themselves but also on the merging or
alignment steps that the user performs. ODEMerge performs a
completely automatic process. During the integration process
Chimaera and PROMPT present the user with possible alternatives
with a graphical interface which allows the user to visually
compare the source ontologies visually and accept or reject the
results of the tools.

All the tools presented support the \emph{conflict detection} and
in particular they are able to detect name and structure
conflicts. Furthermore all tools permit merging concepts,
taxonomies, relations and instances.

With respect to the tool experience, PROMPT, Chimaera and ODEMerge
have been used with many different ontologies and different
domains. Besides PROMT is one of the most frequently quoted tools
in international papers. Studies to evaluate tools are frequent,
one of them is \cite{NoyMusen} where PROMPT is tested following a
defined framework for evaluating the quality of its suggestions.

\subsection{Conclusion} \label{s3:conclusion}

After the presentation of this survey of development and
integration tools, we can write some conclusions.\\

A first conclusion concerns \emph{development tools}: they are
partially out of our interest because their main objective is to
help users in building ontologies, providing useful features for
reducing the time necessary to build large ontologies.\\

\emph{Integration and merging tools}, on the other side, are
limited because they do not face all the problems related to
dynamics. In particular it is important to notice that the main
objective of integration tools is not to solve the dynamics issue
but simply to help the designer during the integration process.
For example none of the presented tools exploits the presence of
previous versions to perform integration but they execute a
process from scratch. With these observations we do not mean to
doubt of the effectiveness and efficiency of the tools features,
but we want to insert these tools' in the right context with
respect to our study.\\

In section \ref{sec2:dinamica} we described the complex operations
that the designer has to do to keep the ontology updated, aligned
and consistent after the creation. Moreover we have presented two
of the main approaches to dynamics' problem: \emph{evolution and
versioning}. We can say that integration tools can not be
discussed with respect to those approaches because the purpose of
the tools is not to provide an environment for managing the
dynamics' aspects of ontologies. In other words the tools are not
able to support the complex modifications that
ontologies need in order to remain consistent, and they are not
able to exploit or manage multiple versions of ontologies or the
previous results for preventing new integration process
from scratch.\\

We can also argue that, with respect to ontology editor
requirements (see sec. \ref{sec2:requisiti}), \emph{integration
tools cannot be classified as ontology editors}. The main reason
for this assumption is that ontology editors are inserted in a
scenario where there are consistent ontologies, different changes
are applied to ontologies and we want to keep them consistent. The
integration tools, as we have seen, do not have the
characteristics to face such a situation; none of the tool has the
capability to manage changes, and in particular they do not have
the notions of applying changes to a consistent ontology.\\

The study of development and integration tools has been useful for
us to understand the state-of-the-art proposals and to evaluate
the MOMIS system against the most important tools available. In
particular, we can consider \mbox{SI-Designer}, the module of
MOMIS for the integration process, as an integration tool. In this
case we can say that SI-Designer is a good ``integration tool''
because, as we have shown before, it has similar characteristics
to the other tools: software platform (Java), architecture (three
layer architecture), import and export features (by means of
wrappers from virtually any format and to XML and \lang),
annotation of terms (with the WordNet lexical system), an internal
inference engine (ODB-Tools), affinity and
clustering technics and source navigation features.\\


Concerning the ontology editor and the possible approaches to
dynamics, we can say that it is difficult to insert MOMIS in this
context because the principal objective of MOMIS is to integrate
sources in order to query the created global view using ontologies
to execute the integration process. The study performed was
motivated by the serious intention to face the dynamics aspects
with the MOMIS system. In fact, the current version of MOMIS does
not absolutely deal at all with the insertion of new sources and
the modification or the deletion of the previously integrated
ones. Studying the state-of-the-art approaches we have understood
the present limits and weak points of the MOMIS system and
moreover we have acquired important knowledge in order to face the
dynamics' issue. In the following chapter we will thoroughly
explain the problems related to the management of
dynamics aspects and we will propose a possible solution to the
problem.




%%% Local Variables:
%%% mode: latex
%%% TeX-master: "tesi"
%%% End:
