\chapter{Ontologies}
\label{c2:cap2}

\par Many articles in the literature have been devoted to presenting
different definitions and features of ontologies; in this chapter
we have followed the overview written by Valentina Tamma in her
Ph.D. Final Thesis \cite{Tamma2001}.

\par The need to share knowledge and information with other
applications already built, has given rise to a growing interest
in research on ontology. This term has been originally used in
Philosophy where it indicated the systematic explanation of
Existence. More recently, the term has been used in various areas
in Artificial Intelligence (AI) and more widely in Computer
Science, such as knowledge engineering, knowledge representation,
qualitative modelling, database design, language engineering,
information integration, information retrieval and extraction,
knowledge management and organisation, agent-based system design
and e-commerce \cite{Guarino1998}. Ontologies play also a key role
in one of the newest area of interest, the Semantic Web, as
confirmed by efforts such as OntoWeb (http://www.ontoweb.org) and
DAML (http://www.daml.org).

\section{Definitions}
\label{sec2:definizione}

\par In each area mentioned before, the term ``ontology'' can take a
different meaning. In some cases this term denotes a set of
activities performed following a standardised methodology, such as
conceptual analysis and domain modelling, while in some other
cases it just indicates a warehouse of vocabulary to solve
lexical, semantic and synonym problems. It is thus clear that
there is no unique definition of the term ``ontology''. The
meaning of the term ontology changes moving from philosophy to AI.
The philosophical account for the term ontology is the branch of
metaphysics that deals with the nature of Being, and it can be
considered as a particular system of categories accounting for a
certain vision of the world \cite{Guarino1998}. In the remainder
of the thesis the word ontology is used as an uncountable noun
(which does not have a plural form) when it refers to the
philosophical notion of ontology, whereas we will use it as a
countable noun when referring to the engineering artifacts defined
in AI.

One of the most widely quoted definition of ``ontology'' was given
by Tom Gruber in 1993, who states \cite[p. 199]{Gruber1993}:
\begin{quote}
\emph{an ontology is an explicit specification of a
conceptualization.}
\end{quote}
A useful link to find additional information is
\\\mbox{\emph{http://www-ksl.stanford.edu/kst/what-is-an-ontology.html}}
\\maintained by Gruber. According to Gruber an ontology is a quintuple
composed of classes, instances, functions, relationships, axioms.
Classes correspond to entities of the domain, instances are the
actual objects which are in the domain, functions and
relationships relate entities of the domain, and finally axioms
constrain the meaning and the use of classes and instances,
functions and relationships.

\par Another definition of ontology, often used in literature, has
been given by Nicola Guarino in \cite{Guarino1998}:
\begin{quote}
\emph{an ontology is a set of logical axioms designed to account
for the intended meaning of a vocabulary.}
\end{quote}
From this definition arises the relationship between a
conceptualization and the ontology which specifies and formalize
it.

\par Now I present a list of interesting definitions that other
researcher groups have studied. In fact, each research group
involved in the ontological field has tried to clarify their view
on ontologies and have developed their own definition of ontology.
These definitions depends on the purposes for which they have been
developed, but, despite some minor differences, they refer to the
ontology as a common understanding of a domain, and that implies
that it is a repository of vocabulary for the knowledge of a
domain. The vocabulary contains both formal and informal
definitions. Borst has extended Gruber's definition \cite[p.
12]{Borst1997}:

\begin{quote}
\emph{an ontology is a formal specification of a shared
conceptualization.}
\end{quote}

Studer and collegues have merged Gruber's and Borst's definition,
and have provided an explanation for the terms used \cite[p.
185]{Studer1998}:

\begin{quote}
\emph{An ontology is a formal, explicit specification of a shared
conceptualisation. A 'conceptualisation' refers to an abstract
model of some phenomenon in the world by having identified the
relevant concepts of that phenomenon. 'Explicit' means that the
type of concepts used, and the constraints on their use are
explicitly defined. ... 'Formal' refers to the fact that the
ontology should be machine-readable. 'Shared' reflects the notion
that an ontology captures consensual knowledge, that is it is not
private to some individual, but accepted by a group.}
\end{quote}

Neches and colleagues developed the following definition about
what is defined by an ontology \cite[p. 40]{Neches1991}:

\begin{quote}
\emph{An ontology defines the basic terms and relations comprising
the vocabulary of a topic area, as well as the rules for combining
terms and relations to define extensions to the vocabulary.}
\end{quote}
This definition states clearly that an ontology is not only
describing the explicit knowledge about a domain, but also the
knowledge that can be inferred. \\The relationship between
ontologies and knowledge bases has been included in the definition
of Bernaras and colleagues \cite{Bernaras1996}; they have defined
what a knowledge base provides while designing an ontology:

\begin{quote}
\emph{The ontology provides the means for describing explicitly
the conceptualisation behind the knowledge represented in a
knowledge base.}
\end{quote}
Swartout and colleagues \cite{Swartout1996}, on the other hand,
have defined the contribution given by an ontology to the design
of a knowledge base:

\begin{quote}
\emph{An ontology is a hierarchically structured set of terms
describing a domain that can be used as a skeletal foundation for
a knowledge base.}
\end{quote}

\par Each definition presented above highlights a specific
aspect of the role played by ontologies. All definitions share the
idea that an ontology provides a description of a particular
viewpoint about a domain and that such a description must be
explicit, because it states a vocabulary for the domain, which is
expressed by a certain degree of formality, and that a group
commits to use the vocabulary according to the intended meaning
associated with it in order to communicate.
\par Ontologies, then, can be classified into lightweight and
heavyweight ontologies, depending on the degree of formality used
to express them. Heavyweight ontologies are those which are
provided with axioms, inference mechanisms aimed to equip
ontologies with deductive power (e.g., inheritance), and that are
characterised by a high degree of formality (e.g., underlying
formal semantics). Lightweight ontologies, on the other hand, are
those ontologies that define a vocabulary of terms with some
specifications of their meaning \cite{Uschold1998}.

\section{Modelling primitives}

Before proceeding by illustrating the different types of
ontologies we introduce here the conceptual primitives that can be
used when knowledge about a domain is formalised in an ontology.
In \cite{Gruber1993} ontology is defined as the quintuple:

\begin{displaymath}
(\mathcal{C},\mathcal{I},\mathcal{R},\mathcal{F},\mathcal{A})
\end{displaymath}
where:

\begin{itemize}
    \item $\mathcal{C}$ is the set of the \emph{concepts}, that is
    the set of the abstractions used to describe the objects of
    the world;

    \item $\mathcal{I}$ is the set of individuals, that is,
    the actual objects of the world. The individuals are also called
    \emph{instances} of the concepts;

    \item $\mathcal{R}$ is the set of relationships defined on the set $\mathcal{C}$,
    that is, each $R \in \mathcal{R}$ is an ordered n-ple
    R$=(\emph{C}_{1} \times \emph{C}_{2} \times \ldots \times \emph{C}_{n})$.
    For example \texttt{subconcept-of} is the pair
    $(\emph{C}_{p}˜,
    \emph{C}_{c})$ where $\emph{C}_{p}$ is the parent concept and $\emph{C}_{c}$ is
    the child concept;

    \item $\mathcal{F}$ is the set of functions defined on the set of concepts
    and that return a concept. That is, each element F is the set of functions defined
    on the set of concepts and that return a concept. That is, each element F is a
    function F:
    $(\emph{C}_{1} \times \emph{C}_{2} \times \ldots \times \emph{C}_{n-1} \mapsto \emph{C}_{n})$.
    For example, the function \texttt{Price-of-flat} is function of the concepts \texttt{Year},
    \texttt{Location} and \texttt{Number-of-square-metres}, and returns a concept \texttt{Price},
    that is \texttt{Price-of-flat}: \texttt{Year} $\times$ \texttt{Location} $\times$
    \texttt{Number-of-square-metres} $\mapsto$ \texttt{Price};

    \item $\mathcal{A}$: set of axioms, that is first order logic predicates that constrain
    the meaning of concepts, relationships and functions.
\end{itemize}
Some of these components have necessarily to be in an ontology.
For example, few ontologies include also instances. The simplest
type of ontology is composed by the set of concepts $\mathcal{C}$
and the relationships $\mathcal{R}$ (lightweight ontologies),
although this limits the knowledge that can be expressed about a
domain. Concepts are also called \emph{classes}. Concepts and
instances are usually organised in an \emph{Is-a} hierarchy, which
permits, when it is a strict relationship (in the mathematical
sense), \emph{inheritance} to be exploited in the structure, that
is if A is an ancestor of B (denoted by A $\mapsto$ B) and B
$\mapsto$ C then, A $\mapsto$ C. When ontologies include also the
content concerning ground individuals and their relationships with
the concepts they instantiate, then the notion of inheritance is
extended to instances and it is called the \emph{instance
relation}. The \emph{Is-a} relationship, also called the
\emph{subclass relationship}, is not the only one that can be
defined on concepts.

Concepts can be defined in terms of characteristic features
describing them, that are called \emph{attributes}. If the
concepts are organised in an \emph{Is-a} hierarchy, then the
inheritance is extended also to attributes. Attributes are shared
by concepts either in their original form or modified in order to
give the inheriting class, known also as \emph{subclass}, a more
restrictive definition than the one provided by the parent
concept. Furthermore other properties can be added to form more
specialised concepts.



\section{Ontologies classification}
\label{sec2:tipi} The ontologies presented in the literature can
be classified according to different dimensions, which range from
the level of generality of the concepts they describe, to the type
of knowledge they model. In this section I present the most
commonly used classifications of ontologies. The first dimension
that can be used to classify ontology is the level of generality
that is used in the description of a domain. It is possible to
distinguish the following types of ontologies \cite{Guarino1998}:
\begin{itemize}
    \item \emph{Top-level ontologies}: this kind of ontology describes
    very general concepts or common-sense knowledge such as space,
    time, matter, object, event, action, etc., which are independent
    of a particular problem or domain.
    \item \emph{Domain ontologies}: this kind of ontology describes the
    vocabulary related to a generic domain such as medicine or physics.
    \item \emph{Task ontologies}: this kind of ontology describes the vocabulary
    related to a generic task or activity such as diagnosis or selling.
    \item \emph{Application ontologies}: this kind of ontology describes concepts
    depending both on a particular domain and on a particular task.
    They are often a specialisation of both domain and task ontologies and correspond
    to the roles played by domain entities when they perform certain activities.
\end{itemize}
Van Heijst and colleagues propose to classify ontologies according
to two dimensions, which are the amount and the type of structure
of the conceptualisation and the subject of the conceptualisation
\cite{Heijst1997}.
\begin{itemize}
    \item Amount and type of structure of the conceptualisation: this
    dimension is mainly concerned with the level of granularity of the
    conceptualisation and thus can be subdivided into:
    \begin{description}
        \item[-] Terminological Ontologies: these are not strictly speaking
        ontologies but just lexicons that specify the terminology that is used
        to represent knowledge in the domain of discourse. They do not represent
        the semantics of the terms;
        \item[-] Information Ontologies: they specify the record structure of
        databases (for example, database schemata). They provide means to
        record the basic observations concerning instances of the database,
        but they do not define the concepts that are instantiated by these instances;
        \item[-] Knowledge Modelling Ontologies: they specify conceptualisations of
        knowledge. They are structurally richer than knowledge modelling ontologies
        and are often specified according to a particular use of the knowledge they describe.
    \end{description}
    \item Subject of the conceptualisation: this dimension concerns the type of knowledge that
    is modelled in the ontologies. Four categories are distinguished along this dimension:
    \begin{description}
        \item[-] Application Ontologies: specify those concepts that are necessary in order
        to model the knowledge required for a specific applications. Usually, application
        ontologies specialise terms taken from more general ontologies such as the domain
        and the generic ontologies described below and may extend generic and domain knowledge
        by representing method and task-specific components. Application ontologies are not
        reusable, they reuse knowledge which may be modelled in ontology libraries by tuning
        it for the specific application at hand;
        \item[-] Domain Ontologies: specify those concepts that are specific of a particular
        domain. Knowledge engineers draw a line between domain ontologies and domain knowledge,
        where the former has ontological nature and the latter epistemic. Domain knowledge
        describes factual situations in certain domains whereas domain ontologies specify
        the constraints to apply on the structure and the content of the domain knowledge.
        But the distinction between what is ontological and what is epistemological is quite
        subtle, and therefore such a line often cannot be drawn too neatly.
        \item[-] Generic Ontologies: specify concepts that are generic across many fields.
        Concepts in the domain ontologies may specialise those in the generic ontologies in
        order to tune them to a particular domain. Generic ontologies correspond to the
        top-level ontologies in Guarino's classification presented above; they typically
        define concepts like state, event, process, action, etc.
        \item[-] Representation Ontologies: explicate conceptualisations underlying knowledge
        representation formalisms. They provide a representational framework without making
        claims about the world, because they are meant to be neutral with respect to the world.
        Domain and generic ontologies are described by means of the primitives given in the
        representation ontologies. A typical example of representation ontologies is the Frame
        Ontology of Ontolingua \cite{Farquhar1997}, which provides the primitives to use
        for building domain ontologies.
    \end{description}
\end{itemize}
Ontologies differ also in the degree of formality by which the
terms and their meaning are expressed in the ontology, as in
\cite{UscholdGruninger1996}. Here, the knowledge expressed in the
ontology might be the same, but they differ in the way in which it
is expressed.
\\In discussing how formally ontologies are described, it makes little
sense to talk about categories, because the degree of formality is
better thought of as a continuum rather than a set of classes.
\\Nevertheless, we can set four points in this continuum:
\begin{itemize}
    \item Highly informal: are those ontologies expressed in natural language.
    Term definitions might be ambiguous due to the inherent ambiguity of natural language;
    \item Semi-informal: these ontologies are expressed in a restricted and structured
    form of natural language. Restricting and structuring natural language achieves
    improvement in clarity and reduction in ambiguity;
    \item Semi-formal: these are ontologies expressed in artificial languages which
    are formally defined, such as Ontolingua \cite{Farquhar1997};
    \item Rigorously formal: these are ontologies whose terms are precisely defined
    with formal semantics, theorems and proofs of desired properties such as \emph{soundness}
    and \emph{completeness}.
\end{itemize}
Along the same line, McGuinness in \cite{LassilaMcGuinness2001}
``classifies'' ontologies on the ground of their expressiveness,
that is, on the grounds of the information that the ontology needs
to express. In fact, depending on the different types of
interpretation which are associated with the word \emph{ontology},
we can distinguish between less or more complex notions of
ontologies, which may range from a \emph{controlled vocabulary},
to a \emph{glossary}, to reach, at the other end of this spectrum,
ontologies which also provide general logical constraints such as
disjointness, inverse, part of, etc. The points they distinguish
in the spectrum are:
\begin{itemize}
    \item Controlled vocabularies: a vocabulary is the simplest possible notion of
    ontology, that is a finite list of terms. A typical example of this category is
    catalogues. Indeed, catalogues provide terms with an unambiguous interpretation,
    but nothing more;
    \item Glossaries: they are a list of terms and their meanings. The meanings are
    usually expressed in natural language statements that are chiefly aimed at humans.
    These statements, however, are ambiguous and cannot be used by computer agents;
    \item Thesauri: add to glossaries the semantics emerging from the definition of
    the relations between terms, such as the synonym relationship. Typically, they do
    not provide an explicit hierarchical structure, although this can often be deduced
    by broader or narrower term specifications. A computer agent can often interpret
    the relationships defined in a thesaurus univocally;
    \item Informal \emph{Is-a} hierarchies: this category includes many of the ontologies on
    the web. These are ontologies where a general notion of generalisation and
    specialisation is provided although it is not strict subclass hierarchy. A typical
    example is \mbox{\emph{Yahoo!}}, which provides a small number of top-level categories,
    but does not provide an explicit hierarchical structure, and its hierarchy is not a strict
    subclass of the \emph{Is-a} hierarchy. In hierarchies that are not strict \emph{Is-a}
    hierarchies it is not always the case that an instance of a more specific class is
    necessarily an instance of a more general class, therefore inheritance (with or
    without exceptions) cannot be assumed here;
    \item Formal Is-a hierarchies: these are ontologies where concepts are organised
    according to a strict subclass hierarchy. Thus, for these ontologies inheritance
    is always applicable because it is always the case that if a concept $C$ is a superclass
    of the concept $C'$, then any subclass of $C$ must necessarily be a subclass of $C'$.
    These ontologies may include only class names;
    \item Formal instances: ontologies including formal instance relations are a natural
    extension of ontologies enforcing a strict hierarchical structure. Indeed, some
    classification schemes include only class names, as we have pointed out when
    discussing strict subclass hierarchies. When formal instance relations hold, the
    ontologies include also the content concerning ground individuals and their relationships
    with the concepts they instantiate;
    \item Frames (description of concept properties): these are ontologies whose concepts
    are described in terms of their characteristic properties. For example, a concept
    \texttt{Book} might be described in terms of features like title, author, publisher,
    etc. The inclusion of properties in the concept description becomes more interesting
    when inheritance can be applied to these properties, and thus properties can be specified
    for a more general concept and be inherited down the hierarchy by more specific concepts;
    \item Value restriction: these ontologies permit to apply restrictions on the
    values associated with properties. For example, in describing the concept
    \texttt{Book} we might restrict the value to associate with the property \texttt{Author}
    to be composed of maximum two names. These restrictions are usually to be inherited
    by the sub-concepts of the concept where they are stated for the first time,
    which clearly poses a problem when the type of hierarchical relation supported by
    the ontology is not a strict subclass relation;
    \item General logical constraints: these ontologies are those with the richest
    expressiveness. For example, properties might be based on mathematical equations,
    which use values from other properties, or properties might be expressed as logical
    statements. This type of ontology is usually written in very expressive ontology
    languages, such as Ontolingua \cite{Farquhar1997}, which permit the specification
    of first order logic constraints on concepts and their properties.
\end{itemize}

As a final consideration, it may be important to make clear the
difference between an application ontology and a knowledge base.
The answer is related to the purpose of an ontology, which is a
\emph{particular} knowledge base, describing facts assumed to be
always true by a community of users, in virtue of the agreed-upon
meaning of the vocabulary used. A generic knowledge base, instead,
may also describe facts and assertions related to a particular
state of affairs or a particular epistemic state. Within a generic
knowledge base, we can distinguish therefore two components: the
ontology (containing state-independent information) and the
``core'' knowledge base (containing state-dependent information).


\section{Ontology dynamics -- different approaches}
\label{sec2:dinamica}

With rising importance of knowledge interchange, many industrial
and academic applications have adopted ontologies as their
conceptual backbone. However, business dynamics and changes in the
operating environment often give rise to continuous changes to
application requirements that may be fulfilled only by changing
the underlying ontologies. This is especially true for WWW and
Semantic Web applications, that are based on heterogeneous and
highly distributed information resources and therefore need
efficient mechanisms to cope with changes in the environment. So
over a period of time an ontology needs to be modified to reflect
changes in the real world, changes in user's requirements,
drawbacks in the initial design, to incorporate additional
functionality or to allow for incremental improvement. In fact
very seldom an ontology is perfect the first time it is made, and
then continues, without change, to be as useful over time as when
it was first deployed. The reasons for changes are inherent in the
complexity of reality and in the limited ability of humans to cope
with this complexity. Thus a small list of possible causes of
change may be the following:
\begin{itemize}
    \item Ontologies often contain ``design error'' and sometimes do not
    immediately meet the requirements of its users;
    \item The environment in which the ontology operates can change
    unpredictably, thereby invalidating the assumptions that were made when
    the ontology was built;
    \item Users' requirements can change after the ontology is initially
    built, requiring that the existing ontology evolves to meet the new requirements.
\end{itemize}

%
% Parte presa da Fensel e Klein
%
Another way to comprehend the causes of change is to refer to the
Gruber definition of ontology \cite{Gruber1993} (\emph{it is a
specification of a shared conceptualization of a domain}).
Analyzing this definition we can enlighten these causes of change:
\begin{enumerate}
    \item changes in the domain;
    \item changes in the shared conceptualization;
    \item changes in the specification.
\end{enumerate}

The first type of change is often occurring and is well known in
the database schema versioning area. In this case changes in the
domain require changes in the database model. An example of this
type of change is the merge of two university departments. As the
ontology describes the real world, a change in it requires a
modification in the ontology itself.

About the second case, it is important to notice that the shared
conceptualization of a domain is not a static specification
produced only once in the history, but has to be reached over
time. Fensel \cite{Fensel2001} describes ontologies as dynamic
networks of meaning, in which consensus is achieved in a social
process of exchanging information and meaning. This view gives a
dual role to ontologies in information exchange; they provide
consensus that is both a pre-requisite for information exchange
and a result of this exchange process.\\Often the
conceptualization can change because of the usage perspective. In
fact different tasks may need different views on the domain and
consequently a different conceptualization. For example when an
ontology is adapted for a new task or domain, the modifications
represent changes to the conceptualization. When an ontology about
a traffic connections with concepts like roads, bridges, is
adapted for a bicycle perspective new concepts have to be added
and other have to be modified or removed.

Eventually the specification change is a kind of translation, i.e.
a change in the way in which a conceptualization is formally
recorded. Therefore this type of change is less interesting
because it has a simple solution. In fact translation should
retain the semantics, as the specification variants should be
equivalent and they only cause syntactic change.

%Therefore, in the following we will concentrate on understand the
%consequences of changes in the domain and in the
%conceptualization.

\vspace{0.5cm} At the end of this overview of the causes of
changes, it is simple to understand the fundamental necessity to
have methods, tools, framework, environment to face the dynamics
aspect of ontologies. Many research groups are involved in the
solving of this crucial issue. In the following two approach are
presented.

The first is the \emph{Evolution approach}. It is proposed by
\cite{Stojanovic2002} and \cite{StojanovicEtAl2002} and it is
developed at the University of Karlsruhe (Germany). This approach
intend to face the dynamics problem in all its complexity and to
manage all the consequences that changes require.

The second is the \emph{Versioning approach}. It is proposed by
\cite{Fensel2001} and it is developed at the Free University of
Amsterdam (The Netherlands). This approach, differently from the
previous one, try to cope with the complexity of the problem
suggesting a system based on versions (or better, on ontology
versions).

\subsection{Evolution approach}
\label{sec2:evoluzione} The \emph{ontology evolution}
\cite{Fensel2001} is the timely adaptation of the ontology as well
as the consistent propagation of changes, because a modification
in one part of the ontology may generate subtle inconsistencies in
other parts of the same ontology, in the instances, depending
ontologies and applications. The ontology evolution is becoming
more important nowadays. The major reason for this is the
increasing number of ontologies in use and the increasing costs
associated with adapting them to changing requirements. Developing
ontologies and their applications is expensive, but evolving them
is even more expensive. However, even though evolution over time
is an essential requirement for useful ontologies, appropriate
tools and strategies for enabling and managing evolution are still
missing. This level of ontology management is necessary not only
for the initial development and maintenance of ontologies, but it
is essential during deployment, when scalability, availability,
reliability and performance are absolutely critical.

Ontology development is now clear, it is a dynamic process
starting with an initial rough ontology, which is later revised,
refined and filled in the details \cite{Noy2000}. Consequently, an
ontology almost certainly should be evolved in order:
\begin{itemize}
    \item to fix ``bugs'' in the initial design (corrective maintenance);
    \item to adapt itself to the changes in the environment (adaptative maintenance);
    \item to improve itself after it has become operational (perfective maintenance);
    \item to avoid future changes and to alleviate maintenance (preventive maintenance).
\end{itemize}
Moreover, ontology evolution has to be supported through the
entire lifecycle \cite{Sure2002}.

\vspace{0.5cm} The most important problem to face when a change to
an ontology occurs, is to ensure the \textbf{consistency of the
ontology} and all the dependent artifacts. When a change to a
consistent ontology is identified, we have to understand how to
carry out it in order to maintain its consistent state. The
importance of this problem became more clear if we consider the
instances that relies on the ontology and all the applications
that depend on it. This issue can be faced diving it in four
phases as shown in Figure \ref{fasicambia}.
\begin{figure}[h]
  \begin{center}
    \epsfig{figure=fasicambiamento.eps,width=\textwidth,angle=0}
    \caption{Four elementary phases of ontology evolution process}\label{fasicambia}
  \end{center}
\end{figure}

%\\\textbf{Change Representation.}
\subsubsection{Change Representation}
Approaching this problem, the first thing to do is trying to
represent the changes, that means to identify and to represent
them in the correct format. In the course of ontology evolution
different type of changes can be requested. Some of them are
simple and interest a defined component of the ontology. Sometimes
the changes are complex and involve several components of the
ontology, in addition the intent of these changes can be expressed
on a higher level. For example, they may need to generate a common
superconcept $sc$ of two concepts $c_1$ and $c_2$. To take the
ontology into the desired state, a list of changes have to be
applied:
\begin{itemize}
    \item[-] Add\_Concept $sc$;
    \item[-] Delete\_SubConceptOf relation from $c_1$ to its current parent;
    \item[-] Add\_SubConceptOf relation from $c_1$ to $sc$;
    \item[-] Delete\_SubConceptOf relation from $c_2$ to its current parent;
    \item[-] Add\_SubConceptOf relation from $c_2$ to $sc$.
\end{itemize}

This case presents significant drawbacks: (I) five steps are
needed to perform the intent change, the process is error prone;
(II) a lot of unnecessary changes may be performed if each change
is applied alone. For example, removing sub-concept-of relation
from $c_1$ may introduce changes to property instantiations that
should be reversed when assign sub-concept-of relation from $c_1$
to $sc$. \\To avoid these drawbacks, changes should be express on
a more coarse level, with the intent of change directly visible.
In this way it become simpler to understand the meaning and the
objective of the requested changes. Some example of composite
changes are presented in the table \ref{cambcompositi}.
\begin{table}[h]
  \centering
  \footnotesize
%  \scriptsize
  \begin{tabular}{|l|l|}
    \hline
    \textbf{Composite change} & \textbf{Description}\\
    \hline
    Merge concepts & Replace several concepts with one and aggregate all instances. \\
    \hline
    Extract subconcepts & Split a concept into a several subconcepts and distribute\\
                        & properties among them. \\
    \hline
    Extract superconcepts & Create a common superconcepts for a set of unrelated \\
                          & concepts and transfer common properties to it. \\
    \hline
    Pull up properties & Move properties from a subconcept to superconcept. \\
    \hline
    Move properties & Move properties from one concept to another concept. \\
    \hline
    Move instance & Moves an instances from one concept to another. \\
    \hline
  \end{tabular}
  \normalsize
  \caption{Composite changes in the ontology}
  \label{cambcompositi}

\end{table}

%\textbf{Semantics of Change.}
\subsubsection{Semantics of Change}
Application of an elementary change in the ontology can induce
inconsistencies in other parts of the ontology. We can distinguish
\emph{syntax} and \emph{semantic} inconsistency. \emph{Syntax}
inconsistency arises when undefined entities at the ontology or
instance level are used or ontology model constraints are
invalidated. \emph{Semantic} inconsistency arises when the meaning
of an entity is changed due to changes performed in the
ontology.\\ For example, removal of a concept which is the only
element of domain set for some property results in syntax
inconsistency. Resolving that problem is treated as a request for
a new change in the ontology, which can induce new problems that
cause new changes and so on. Therefore, one change can potentially
trigger other changes and cause an unpredictable chain of
alterations. If an ontology is large, it may be difficult to fully
comprehend the extent and the meaning of each induced change. The
task of `semantics of change' phase is to enable resolution of
induced changes in a systematic manner, ensuring consistency of
the whole ontology. To help in better understanding the effects of
each change, this phase should contribute maximum transparency
providing detailed insight into each change being
performed.%
\vspace{0.3cm}\\In the course of evolution, actual meanings of
concepts often shifts to better represent the structure of the
real world. While some shifts of concept meaning are performed
explicitly, a meaning of a concept can sometimes shift implicitly
through changes in other parts of the ontology. For example,
consider an ontology describing a relationship between jaguars and
persons. In this ontology the meaning of the concept \emph{Jaguar}
is clear through the existence of the property \emph{eats} that
links \emph{Jaguars} and \emph{Persons} -- it is clear that
concept \emph{Jaguar} stands for an animal. For any reason one may
delete the concept \emph{Person}, which may result in the removal
of the property \emph{eats} as well. After this change, the
semantics of concept \emph{Jaguar} is not clear any more -- is it
a Jaguar cat or a Jaguar car? This example highlights the
importance of the semantics of change and the problems that arise
if we do not treat it properly. For this reason is important to
use a rich description of each ontology entity. One way may be
attaching meta-information about e.g. essential properties of a
concept.

%\vspace{0.5cm}\textbf{Change Implementation.}
\subsubsection{Change Implementation}
This phase has the principal aim to prevent undesired changes.
Before applying a change to the ontology, a list of all
implications to the ontology is generated and presented to the
user. He should be able to comprehend the list and approve or
cancel the change. When the changes are approved, they are
performed by successively resolving changes from the list. At this
stage, no action is already done, in fact if changes are
cancelled, the ontology remains intact.

%\vspace{0.5cm}\textbf{Change Propagation.}
\subsubsection{Change Propagation}
When the ontology is modified, ontology instances need to be
changed to preserve consistency with the ontology. This can be
performed in three steps. In the first step, the instances are
collected in the knowledge base (often they are widespread on the
Web). In the second step, modification of instances is performed
according to the changes list prepared in the previous phases. In
the last step ``out-of-date'' instances are replaced with
corresponding ``up-to-date'' instances.\\Despite this simple
process the change propagation arises some important problems. As
ontologies often reuse and extend other ontologies, an ontology
update might also corrupt ontologies that depend on the modified
ontology and also all artifacts that are based on these
ontologies. One possible solution to this problem is the recursive
application of the ontology evolution process on all the
interested ontologies. Nowadays many applications are based on
ontologies so when an ontology is modified the application may not
work correctly. The ontology evolution system has to recognize
which change in the ontology can affect the functionality of the
dependent applications and react with the right operations.

\vspace{0.3cm}Eventually, to explain the complexity of the
ontology evolution process can be useful the Figure \ref{OEP}.
\begin{figure}[h]
  \begin{center}
    \epsfig{figure=ontologyevolutionprocess.eps,totalheight=8cm,angle=0}
    \caption{Ontology Evolution Process}\label{OEP}
  \end{center}
\end{figure}
It shows how the process has a cyclic structure, since validation
of realized changes may (automatically) induce new changes in
order to obtain a consistent state or to satisfy users'
expectations. The phases 2 to 5 correspond to the evolution
process explain before; the phase 6 gives the user the opportunity
to control the process and to supervise it, while the phase number
1 is fundamental to continuously identify changes to propose with
the user for preventing changes or improving the quality of the
ontology.

% Parte presa da SWWW01.pdf Ontology versioning on the Semantic Web
\subsection{Versioning approach}
\label{subsec2:versioning} In the previous section we have seen
one of the most interesting approach to the dynamics of
ontologies, but it is not the only one. In literature several
studies start assuming that the complexity of the dynamic
involving ontologies, applications and instances, is too high to
maintain everything aligned. As we have already seen, a request
for changing an ontology can start a long process to keep
consistent the ontology and all the entities that depend on it. A
versioning methodology can handle this complexity providing the
user with such a system that manages ontology revisions over
time.\\Before going deeper in this argument it is better to
explain what actually means \emph{versioning}. In a general sense,
ontology versioning means that there are multiple variants of an
ontology around. In practice, those variants often originate from
changes to an existing variant of the ontology and thus form a
derivation tree. It is also possible that different ``versions''
of ontologies of the same domain are independently developed and
do not have a derivation relation. In this case, however, we will
not use the word ``version'', but we will see the variants as
separate ontologies that describe the domain from a specific
viewpoint or perspective. In this view, ontology versioning is
closely related to changes in ontologies \cite{Fensel2001}.

\vspace{0.3cm}\textbf{Ontology versioning} can be defined as
\emph{the ability to handle changes in ontologies by creating and
managing different variants of it}. In order to achieve this
ability a methodology has been studied. In particular methods to
distinguish and recognize versions, and procedures to update and
change ontologies are provided.

%
% Tolta parte di descrizione dei cambiamenti e spostata in alto
%

\subsubsection{Analysis of compatibility} The consequences of the
change are very important, as we have already said before (see
section \ref{sec2:evoluzione}). Now we discuss the problems that a
versioning system has to solve related to the compatibility of
changed ontologies and data sources.\\A typical scenario presents
various versions of many ontologies around. A lot of web pages or
applications use (or are intended to use) a specific version of
the ontology. At this point incompatibility problems arise. In
fact it is not clear which version of an ontology is related to a
certain data source. Basically there are tree ways to relate
ontology versions with data sources: 1) using the intended version
of the ontology; 2) using a newer version of the ontology; 3)
using an older version of the ontology. The first type of
combination is clearly compatible, so we focus our attention on
two directions, which are illustrated in figure \ref{versions}.
The terms used in the following are well known in the schema
versioning literature; they describe the two directions of
investigation.
\begin{figure}[t]
  \begin{center}
    \epsfig{figure=versions.eps,width=\textwidth,angle=0}
    \caption{Two examples of prospective and retrospective use of ontologies}\label{versions}
  \end{center}
\end{figure}
\begin{itemize}
    \item \textbf{Prospective use}: the use of data sources that conform to
    a previous version of the ontology via a newer version of the
    ontology (\emph{i.e. view the data from a newer perspective}).
    \item \textbf{Retrospective use}: the use of data sources that conform
    to a newer version of the ontology via a previous version of
    the ontology (\emph{i.e. view the data from an older perspective}).
\end{itemize}
Based on these directions of use we can now categorize the
compatibility revisions into different types. In this
categorization, we examine whether it is valid to use a revision
of an ontology on the set of all possible instances of an other
revision of the ontology. In other words, we assume that the data
sources that conforms to a specific version of the ontology uses
the whole ontology, i.e., all concepts and relations. This is the
worst scenario. Table \ref{categories} shows the types of
compatibility.
\begin{table}[h]
  \centering
  \footnotesize
%  \scriptsize
  \begin{tabular}{lc|c|c|}
    %\hline
    & \multicolumn{3}{c}{\textbf{prospective use valid}}\\
     & \multicolumn{1}{c}{ } & \multicolumn{1}{c}{yes} & \multicolumn{1}{|c}{no} \\
    \cline{3-4}
    \textbf{retrospective} & yes & full compatible & upward compatible \\
    \cline{2-4}
    \textbf{use valid} & no & backward compatible  & incompatible \\
    \cline{3-4}
  \end{tabular}
  \normalsize
  \caption{Categorization of compatibility}
  \label{categories}
\end{table}\\
The types of revisions can be described as follow:
\begin{itemize}
    \item \textbf{full compatible revisions} (upward and backward): the
    semantics of the ontology is not changed, e.g. syntactic
    changes or updates of natural language descriptions; this type
    of change is compatible in both \emph{prospective} use and
    \emph{retrospective} use;
    \item \textbf{backward compatible revisions}: the semantics of the
    ontology is changed in such a way that the interpretation of
    data via the new ontology is the same as when using the
    previous version of the ontology, e.g. the addition of an
    independent class; this type of change is compatible in
    \emph{prospective} use;
    \item \textbf{upward compatible revisions}: the semantics of the
    ontology is changed in such a way that an older version can be
    used to interpret newer data sources correctly, e.g. the
    removal of an independent class; this revision is compatible
    in \emph{retrospective} use;
    \item \textbf{incompatible revisions}: the semantics of the ontology is
    changed in such a way that the interpretation of old data
    sources is invalid, e.g. changing the place in the hierarchy
    of a class; this type of change is incompatible in both
    \emph{prospective} use and \emph{retrospective} use.
\end{itemize}
Note that both backward compatibility and upward compatibility are
transitive: when the changes from $v1$ to $v2$ as well as the
changes from $v2$ to $v3$ are backward compatible, then the
changes from $v1$ to $v3$ are also backward compatible. So, if all
subsequent revisions to an ontology up to a certain version are
backward compatible, it is also possible to name the resulting
version of the \emph{ontology itself} backward compatible.
However, it is never allowed to call a version of an ontology
\emph{upward} or \emph{full compatible}, because the semantics of
future versions are not known beforehand. It is always possible
that new versions of ontologies will introduce new things that
cannot correctly be interpreted via older versions. Thus,
\emph{backward compatibility} can be a characteristic of an
ontology, but \emph{upward} or \emph{full compatibility} can not.

\subsubsection{Requirements for versioning framework} As we have
seen there are various scenarios for ontology changing. Now we
presents some requirements and goals for a versioning
system.\\Principally a versioning methodology should provide
mechanisms and techniques to manage changes to ontologies, while
achieving maximal interoperability with existing data and
applications. This means that it should retains as much
information and knowledge as possible, without deriving incorrect
information. This general achievement can be translate in a more
detailed list of requirements:
\begin{itemize}
    \item [-] for every use of a concept or a relation, a
    versioning framework should provide an unambiguous reference to
    the intended definition (\textbf{identification});
    \item [-] a versioning framework should make the relation of
    one version of a concept or relation to other versions of that
    construct explicit (\textbf{change specification});
    \item [-] a versioning framework should -- as far as possible
    -- automatically translate and relate the versions and data
    sources, to enable transparent access (\textbf{transparent evolution}).
\end{itemize}
Fensel et al. \cite{Fensel2001} are working on this framework and
till now they have studied in particular the \emph{identification}
and \emph{change specification} problems. %

\subsubsection{Identification} In order to manage
various versions of ontologies is fundamental to identify each
version unequivocally. About this issue there are different
opinions on how to treat changes. In fact one can see an ontology
as a specification of a conceptualization, so every modification
to the specification can be considered a new conceptualization of
the domain. In that case, the descriptions specify different
concepts, which are \emph{per definition} not equal. Another
perspective can see an ontology primarily as a conceptualization,
which is represented as complete as possible in a specification,
which is represented as complete as possible in a specification.
In this case one could argue that an update to a natural language
description of a concept is not a semantic change, but just a
refined description of the same conceptualization. To solve this
debate an ontology is represented as a file on the Web. Every
change that results in a different character representation of an
ontology constitutes a revision. When the logical definitions are
not changed, the author of the revision has to decide whether the
revision is a semantic change and thus forms a new
conceptualization with its own identity, or just a change in the
representation of the same conceptualization.\\The concrete
translation of this debate is that an ontology is considered as a
resource on the Web, thus it can be identified with a URI (Uniform
Resource Identifier). Fensel et al. in this way propose to
separate the identity of ontologies completely from the identity
of files on the web that specifies the ontology. In other words,
the class of ontology resources should be distinguished from the
class of file resources. A revision  -- normally specified in a
new file -- may constitute a new ontology, but this is not
automatic. Every revision is a new file resources and gets a new
file identifier, but does not automatically get a new ontology
identifier.\\The method can be summarized with the following
points:
\begin{itemize}
    \item a distinction between three classes of resources:
    \begin{enumerate}
        \item files;
        \item ontologies;
        \item lines of backward compatible ontologies.
    \end{enumerate}
    \item a change in a file results in a new file identifier;
    \item the use of a URL for the file identification;
    \item only a change in the conceptualization results in a new
    ontology identifier;
    \item a new type of URI for ontology identification with a two
    level numbering scheme:
    \begin{itemize}
        \item [-] minor numbers for backward compatible
        modifications (an ontology-URI ending with a minor number
        identifies a specific ontology);
        \item [-] major numbers for incompatible changes (an
        ontology-URI ending with a major number identifies a line
        of backward compatible ontologies);
    \end{itemize}
    \item individual concepts or relations, whose identifier only
    differs in minor number, are assumed to be equivalent;
    \item ontologies are referred to by an ontology URI with the
    according major revision number and the minimal extra
    commitment, i.e., the lowest necessary minor revision number.
\end{itemize}

\subsubsection{Change specification and transparent evolution} For
change specification and transparent evolution, there are two
important requirements.\\
First, in consequences of the suggested practice of referring to
the minimal extra addition, the changes in a line of backward
compatible ontologies should be easily recognizable and
identifiable. A proposal in this direction is to add a class
\texttt{Addition<Major>.<Minor>}, e.g., \texttt{Addition1.2}, of
which the new descriptions are an instance. This makes that class
a unique identifier for the set of additions in a certain
revision. Then, the additions can be retrieved by asking for all
instances of a specific ``Addition'' class.\\Second, the relation
to a previous version should explicitly be specified. One aspect
of this specification is a pointer to the ontology from which it
is derived. These pointers form a lattice of versions that can be
used to deduce the derivation relation from one version to an
arbitrary other version of the ontology. A second aspect of this
specification is the relation between concepts and relations in
the previous and current version of the ontology. As concepts and
relations that do not have the same major number in their
identifier are assumed to be different, this specification should
both specify equivalence relations as subsumption relations.




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