\chapter{Integration of new sources in the Momis system}
\label{c4:cap4}

\label{s4:intro} As we have seen before, the dynamics' issue is a
crucial aspect in several research areas such as Information
Integration, Knowledge Representation, Ontology Management,
Artificial Intelligence and Semantic Web.

In this chapter we will present the problems that arise when a new
source (or more than one) has to be integrated in the Momis
system. In fact, Momis is able to integrate sources but now it
cannot dynamically manage the insertion of new sources. We will
illustrate the current limits of the system,
the problems that arise when we want to manage the dynamics, and
possible approaches to solve them.

\section{The static aspect of Momis}
\label{s4:statica} In the previous chapters we have analyzed the
new scenarios that the Semantic Web is creating all over the
world. In particular we have seen how many research groups are
working on projects related to the ``new'' Web, to the ontologies
and their management, to the \emph{dynamics}. Specially this last
issue is becoming essential today.

Everything, in fact, evolves and changes rapidly: web pages, web
applications, data of any type, ontologies, languages, models,
methodology, etc. These elements are continuously modified to
accomplish new requirements or to keep them consistent. So if
someone wants to keep in contact with this new scenario, he has to
face and solve the dynamics problem.

\vspace{0.2cm} The Momis system is actually able to integrate
heterogeneous sources in a semi-automatic way (see sec.
\ref{s2bis:Momis} and \ref{s3:SI-Designer} for details) but Momis
was designed to solve the integration problem  in a \emph{static}
environment. The Momis integration process, in fact, aims at
building an integrated view on all the sources involved. This view
is also called \emph{\textbf{Global Virtual View}} (or short
\textbf{GVV}) because it allows the users to have a \emph{Global
View} on the integrated domain, but it is \emph{Virtual} because
it is not really created. In other words, the \emph{GVV} allows
the users to look at the domain as if it was a unique source,
leaving all the details for the management of the underlying
sources to the system.

\vspace{0.2cm} The present methodology of the Momis system is
optimized to achieve the best results in the case in which the
candidate sources to be integrated are all available at the
beginning of the integration process. Besides, if the sources come
from the same domain, that means they describe way the same
entities (such as persons, products, diseases, etc.) in different,
the results will be probably better. The skill and the experience
of the designer that follows and supervises the integration
process are a key aspect to obtain good results.

\vspace{0.2cm} The process is semi-automatic and therefore a
designer or a domain expert has to interact with the system. Even
if the SI-Designer (the integration tool of the Momis system)
helps the user during every phase, the integration process is not
banal and it heavily depends on the dimension of the candidate
sources. Similar observations are valid if we consider the
computational effort to build the final view.

\vspace{0.2cm} Before going on, it is better to explain what we
exactly mean with ``\textbf{\emph{dynamics management}}'' in
the MOMIS system. \emph{\textbf{We can define the management of
the dynamics as the capability to face the request of inserting
new sources and updating or deleting integrated sources}.}

\vspace{0.2cm} This definition raises several considerations and
comments. The requests are normal and obvious in the scenario we
have depicted before, but finding a solution to them is not easy
and the following issues are of fundamental importance during the
discussion of possible solutions.
\begin{enumerate}
    \item \emph{\textbf{Consistency}}. When the integration process is
    finished and the GVV has been generated, the system is in a
    \emph{consistent state}. Any modification can lead to an
    inconsistent state of the system. The system has to manage this
    situation and reconcile the schema to a consistent state
    after each intervention.
    \item \emph{\textbf{Dependency}}. Users and applications rely on the
    GVV, that is users pose queries on the schema, and
    applications use the schema to operate. If the schema changes,
    unpredictable \emph{side effects} on the queries' results and on the
    applications output may appear. Moreover some \emph{optimizations}
    may have been calculated relying on the present schema;
    recalculations are necessary if changes intervene.
\end{enumerate}

In the second chapter we presented two approaches to the dynamics
problem: Evolution approach (sec. \ref{sec2:evoluzione}) and
Versioning approach (sec. \ref{subsec2:versioning}).

The \emph{evolution approach} is the most interesting attempt to
formalize and to explain the whole complexity of the problem. This
approach considers every implication that each change can have on
the system. It can be useful in our context to help us to
understand the possible side effects that each change can induce.
But this study refers to an environment which is different from
ours; the Momis system, in fact, is a source integration system
and not an ontology management tool. So it is clear that we can
not follow all the requirements that the study proposes.

The \emph{versioning approach} is surely of less interest for us.
The proposal is to manage the changing scenario with versions of
ontologies. In the Momis system is impossible to follow such a
solution because it was designed for the creation of an integrated
view of the interested domain.

\vspace{0.3cm} As we have seen the problem is very complex. In
order to simplify it, \textbf{in the following we will study only
the case of the integration of new sources}. We will present the
problems related to the introduction of new sources, explaining
our choices and suggesting some possible solutions.

\section{The problems faced}
\label{s4:problems} In this section we try to give more details
about the problems related to the integration of new sources in
the integrated view.

\vspace{0.2cm} We start analyzing the request: new sources ask to
be integrated in the schema. As we have said before, the sources
integrated usually come from a common domain (university,
business, enterprise, etc.) and so they have some level of
similarity and affinity. If the sources to integrate belong to the
same domain of the previous sources, there are higher probability
to obtain a good result with few changes. Otherwise if the sources
are completely out of the domain, the final global schema will be
probably quite different.

\vspace{0.2cm} Now in order to draw some guidelines for the
discussion of the problem, we list a series of question we will
try to find an answer to.
\begin{itemize}
    \item Is the Global Virtual View a good representation and a good
    synthesis of the knowledge of the integrated local sources?
    \item How can we save the knowledge hidden behind the GVV?
    \item Is it useful to save that knowledge?
    \item How can we use the knowledge of the local sources during
    the integration of new sources?
\end{itemize}
The answer to the first question is fundamental, because, if we
consider the GVV as a good synthesis of the integrated sources, we
can imagine to compare the new sources with the GVV itself. On the
other side if we consider also the connections and the knowledge
related to the local sources as very important, the integration
process has to reflect it.

The GVV, as we have seen in the description of its construction,
represents an integrated view of the local sources, but it saves
also all the information that link each global entity to the
corresponding local one (by means of \emph{mapping tables}).
Moreover, the MOMIS system has an important source of knowledge:
the \emph{Common Thesaurus}. Therefore, the debate concerns the
possibility to exploit the ``local information'' we have in the
system to conduct the new integration process.

In case we decided to take advantage also of the information
related to the old local sources, we have to study the best way
to exploit them during the process.

\vspace{0.2cm} A further aspect of the problem is the complexity
of the present integration process followed by the Momis system.
In fact, the integration process is expensive for the designer,
who has to interact with the system, and for the system, which has
to support the designer during the process. These claims are
important in order to decide the strategy to follow to solve the
problem. \emph{One of the possible and probably one of most simple
solutions is to \textbf{restart the process from scratch}
involving old and new local sources}.\\

\textbf{We discarded this solution} because it did not exploit the
work of the previous integration process and in the following we
will not consider it anymore.

\vspace{0.2cm} In order to improve our study, we observe that in
the present integration process all the sources to be integrated
equally concur to the process. Therefore, if we suppose that the
world described by a Momis integrated view is quite static and
refers to the same specific context and the new source belongs to
that specific context, we may assume that a new source brings less
semantics than the GVV. Therefore, \emph{\textbf{we may assume an
integration process of the new source that starts from the GVV
obtained and tries to integrate this new source in the GVV}.}

\section{A first attempt}
\label{s4:tentativo} We are now going to present the heuristic
approach which was initially used, trying to
exploit the previous assumptions related to dynamics. This
solution has been then abandoned, but it has been useful to
understand some defects of the present Momis process.

\vspace{0.2cm} Following the annotations mentioned before, we
analyze the final results of the integration process. The Global
Virtual View is mainly composed of global classes, each one with
its mapping table. We observe that global classes represent a well
defined integrated view of the local sources, but they are not
related to each other. The relationships saved in the Common
Thesaurus are referred to local sources and they are used only to
determine clusters.

\emph{The idea was to better exploit better the knowledge
contained in the Common Thesaurus}. We thought that during the
integration of new sources against the GVV, it could be useful to
have relationships among global classes. In some ways it was an
attempt to preserve some of the knowledge saved in the Common
Thesaurus.

\vspace{0.2cm} With respect to these reasonings \emph{we had to
transform the Common Thesaurus in order to exploit it during the
integration of new sources} (see figure \ref{CTtransformation}).
\begin{figure}[ht]
  \begin{center}
    \epsfig{figure=CTtransformation.eps,totalheight=8cm,angle=0}
    \caption{The Common Thesaurus transformation.}\label{CTtransformation}
  \end{center}
\end{figure}
Before going on, we recall here the structure of a CT
(Common Thesaurus) relationships:\\
\hspace*{0.4cm} - Name path of the left side of the relationship;\\
\hspace*{0.4cm} - Type of relationship: SYN, NT, BT, RT;\\
\hspace*{0.4cm} - Name path of the right side of the relationship.
\vspace*{0.2cm} \\The name path is expressed in ``dot notation'': \\
\hspace*{0.4cm} - \texttt{NameLocalSource.NameLocalClass} or \\
\hspace*{0.4cm} - \texttt{NameLocalSource.NameLocalClass.NameLocalAttribute}\\
\vspace*{0.2cm} \\The relationships can involve different elements:\\
\hspace*{0.4cm} - Local Class $\leftrightarrow$ Local Class or \\
\hspace*{0.4cm} - Local Class $\leftrightarrow$ Local Attribute or\\
\hspace*{0.4cm} - Local Attribute $\leftrightarrow$ Local Class or\\
\hspace*{0.4cm} - Local Attribute $\leftrightarrow$ Local Attribute.\\
\vspace*{0.2cm} \\For example we can have:\\
\hspace*{0.4cm} - \texttt{UNI.Room RT UNI.Section} \\
\hspace*{0.4cm} - \texttt{CS.Location BT CS.Office.address} \\
\hspace*{0.4cm} - \texttt{UNI.School\_member.faculty RT CS.CS\_Person} \\
\hspace*{0.4cm} - \texttt{UNI.Section.room\_code SYN UNI.Room.room\_code} \\

At the end of the integration process each local entity is mapped
in a global one: local classes are mapped in clusters (or global
classes) and local attributes, by means of the mapping tables, are
mapped in global attributes. Relying on this knowledge, \emph{we
propose to update CT relationships in order to have a new set of
relationships among global entities (classes and attributes)}. The
rules to elaborate the CT relationships are listed below and are
divided into three groups:
\begin{enumerate}
    \item \textbf{Global Class $\leftrightarrow$ Global Class}\\
    The relationship involves two local classes that are mapped in
    two different global classes. The sources of the local classes
    are of no importance. The type of relation does not change.
    The path name changes with respect to the global class, that
    is, the source name becomes the name of the global schema
    defined by the designer at the beginning of the integration
    process, while the local class name becomes the name of the
    global class in which it is mapped.\\
    \\
    \hspace*{0.2cm} \texttt{UNI.Room RT UNI.Section} (before the transf.)\\
    \hspace*{0.2cm} \texttt{GVV\footnote{GVV is considered the name
    of the Global Schema chosen by the designer.}.Room RT GVV.Course}
    (after)\\ \\
    \hspace*{0.2cm} \texttt{UNI.Research\_Staff RT CS.Course} (before)\\
    \hspace*{0.2cm} \texttt{GVV.Person RT GVV.Course} (after)\\ \\
    The relationships are taken from the complete example presented
    in appendix \ref{A1:example}.
    \item \textbf{Global Class $\leftrightarrow$ Global Attribute}\\
    The relationship involves a local class and a local attribute
    that are mapped in two different global entities. The global
    entities can belong or not to the same global class.
    The source name becomes the name of the global schema, while
    the local class name becomes the name of the
    global class in which it is mapped, and the local attribute takes
    the name of the corresponding global attribute.\\
    \\
    \hspace*{0.2cm} \texttt{CS.CS\_Person BT UNI.Article.author} (before the transf.)\\
    \hspace*{0.2cm} \texttt{GVV.Person BT GVV.Publication.authors} (after)\\ \\
    The relationship involves two different global classes
    (\texttt{Location} and \texttt{Office}).\\ \\
    \hspace*{0.2cm} \texttt{CS.Professor RT UNI.School\_Member.faculty} (before)\\
    \hspace*{0.2cm} \texttt{GVV.Person RT GVV.Person.faculty} (after)\\ \\
    \\
    \hspace*{0.2cm} \texttt{UNI.Department SYN UNI.Department.dept\_name} (before)\\
    \hspace*{0.2cm} \texttt{GVV.Department SYN GVV.Department.dept\_name} (after)\\ \\
    The relationships involve the same global classes
    (\texttt{Person} and \texttt{Department}).
    \item \textbf{Global Attribute $\leftrightarrow$ Global Attribute}\\
    The relationship involves two local attributes
    that are mapped in two different global attributes.
    Like before, the source name becomes the name of the global schema, while
    the local class name becomes the name of the
    global class in which it is mapped and the local attribute takes
    the name of the corresponding global attribute.\\
    \\
    \hspace*{0.2cm} \texttt{UNI.Section.room\_code SYN UNI.Room.room\_code} (before the transf.)\\
    \hspace*{0.2cm} \texttt{GVV.Course.room\_code SYN GVV.Room.code} (after)\\ \\
    The relationship involves two different global classes
    (\texttt{Course} and \texttt{Room}) but it can also involve the same global class. \\
\end{enumerate}

The updated relationships are then saved in a data structure
similar to the one used with the CT relationships; they will be
exploited during the integration of new sources. This
transformation enriches the global schema, in fact, now we can
know the relationships among the global entities (classes and
attributes).

\vspace{0.3cm} At this point a further fundamental assumption is
necessary. In order to define the new integration process we
consider that: \emph{the global schema, which was previously
built, with the new relationships just created, is a good
synthesis of the integrated local sources}. \emph{This claim
allows us to compare the new candidate sources with this enriched
schema}.

\vspace{0.3cm} As a consequence, we suggest a new integration
process that exploits the present architecture of the Momis system
bringing only small changes. The idea is to transform the global
schema with the aims of simulating a new source. Since the global
schema does not have a ``\emph{real}'' structure from which we can
extract relationships, we take advantage of the relationships we
have prepared before. In this way we can use the normal
integration process of Momis but this time there are:
\begin{itemize}
    \item [-] the Global Virtual View;
    \item [-] the new soruces.
\end{itemize}

The phases of the previous process remain the same except the
extraction of intra and inter schema relationships that is not
performed on the Global Virtual View.

This solution exploits the feature of the Momis system to export
the Global Schema as a XML file and to load a schema from a XML
file. In this way we force the system to accept the GVV as a new
source; in addition we have to modify the process in order to load
also the updated CT relationships (referred to the GVV) from the
XML file, instead of calculating them.

\vspace{0.3cm} We write the code to accomplish these directions.
We create a new tab in the Momis system that guides the designer
in the creation of the XML file. This file has to simulate a new
source in the integration of further sources. Thanks to the tabs,
the user can:
\begin{itemize}
    \item [-] update the Common Thesaurus relationships following
    the rules described above;
    \item [-] create the XML file that simulates a source.
\end{itemize}

We tested this process and we obtained good results. Tests were
carried out on few examples and therefore we do not have
significant data to evaluate this process completely.

\vspace{0.3cm} This first heuristic attempt has been very useful
because we have understood some important defects of the present
process. In particular we have observed that the result of the
integration process, the Global Virtual View, has to be modified
to become a good synthesis of the local sources. We tried to solve
these problems with the solution we have just presented, but
during the study we understood that the problems were concentrated
around the GVV. We summarize here two main defects we found:
\begin{itemize}
    \item [-] global classes are separated, there are no relationships among them;
    \item [-] global terms (names of classes and attributes) are not lexically annotated.
\end{itemize}
Our first solution aimed at adjusting the first defect but the
study of the second it led us to refine a new approach that will
be presented in the next section.

\section{The proposed solution}
\label{s4:soluzione} Exploiting the previous study, we present
here the new solution we decided to use after the first attempt
and that we are trying to implement.

\vspace{0.2cm}\emph{\textbf{The solution we propose is based on
the conviction that the present integration process is effective
and gives good results}.}

This assumption is coherent with what we stated before about our
intention to save the present Momis approach and its results as
much as possible. Therefore, working with this in mind, we
identified two main problems to solve:
\begin{description}
    \item [Global Schema annotation.] The global schema has to be
    semantically enriched if we want to improve the expressive
    power of the schema. This phase is fundamental to prepare
    the schema for the integration with new sources. Moreover the
    annotation step allows us to save as much knowledge as possible
    in the schema that will be then exploited in the
    next integration sessions.
    \item [New integration process.] The present integration
    process must be changed in order to accept new
    sources and the previous GVV semantically enriched as input.
\end{description}
The following sections will explain the details of these two
important issues.

\subsection{Global Schema annotation}
\label{s4:gsannotation} The \emph{Global Schema annotation} was
not involved in the present version of the Momis framework. The
integration process builds global classes (see sec.
\ref{s3:global} for details) but it does not annotate them. As
said before, the annotation phase will enrich the global schema
and prepare it to be used for the new integration process.

Before going on we specify what we mean with annotation:
\emph{\textbf{the annotation process wants to assign a name and a
meaning (at least one) to global classes and attributes}}.\\

We point out that the local terms are annotated during the present
Momis process. Now we explain what is to be done to annotate the
global schema presenting all the possible cases.

\vspace{0.2cm} In the following we will use this notation:
\begin{itemize}
    \item [-] Global Class $gc_k=\{lc_1,\ldots,lc_n\}$ where
    $n\geq1$, is composed of a set of Local Classes, $lc_i$, belonging to the Cluster
    $Cl_k$ associated to $gc_k$
    \item [-] Local Class $lc_i=<lcName_i,
    \{lcM_{i1},\ldots,lcM_{im}\}>$ where $m\geq0$, is composed of a name,
    $lcName_i$, identifying unambiguously the local class and a
    set of meanings $lcM_{ij}$
\end{itemize}

\subsubsection{Global Classes' annotation}
\label{s4:gcannotation} \emph{The operation of semantically
annotating a Global Class consists of assigning a representative
name (unique in the schema) and a set of meanings to it}. We
recall that a cluster represents a set of local classes related to
each other by a high affinity level. The name of the cluster is
automatically set by the system and therefore it is not
significant; it has the structure $Global_i$ where $i$ is the
global class counter. Afterwards the designer has to set a
significant name to each cluster. What we want it is to eventually
have an annotated Global Class or with respect to the introduced
notation:
\begin{center}
$gc_k=<gcName_k,\{gcM_{k1},\ldots,gcM_{kp}\}>$ where $p\geq0$
\end{center}

Concerning \emph{the global class name} we consider it as a label;
it is principal role is, in fact, to help the designer to identify
the Global Class and its contents, so in some cases the selected
name could not match with a word form of WordNet (e.g.
\texttt{School\_Member}), or the chosen name may not be
represented by the meanings of the
global class.\\

Concerning \emph{the global class meaning}, we assume that each
meaning has a unique identifier within WordNet, let us say $M$. In
order to associate a word form $F$ to the right meaning $M$ we use
$F\#counter$, that is we use the element of the lexical matrix of
WordNet:\\

\small
\begin{center}
\begin{tabular}{|l|c|l|}
\hline
Word Form & $F$ & \ldots \\
Meaning & & \\
\hline $M$ & $F\#counter$ & \\
\hline
\ldots & & \\
\hline
\end{tabular}
\end{center}
\normalsize

In this way a meaning can be identified also with $F\#counter$;
furthermore each meaning can have more than one of these
identifiers. In our examples we will use this type of notation.\\

The annotation process can be achieved semi-automatically
following some rules; of course, the designer may always refine
what the system suggests. The possible cases are:
\begin{itemize}
    \item [a)] \textbf{Only one Local Class belongs to the Global
    Class ($n=1$)}. In this case, both the name and the meaning of
    the global class are the same of the Local Class. If no
    meaning was provided before by the designer for the Local
    Class, the designer is asked here to supply the missing
    information.

    The clustering result is:\\

    \hspace*{1cm} {\tt Global$_3$ = \{CS.Office\}}\\

    where\\

    \hspace*{1cm} {\tt CS.Office = <office,\{office\#1\}>}\\

    following the rules:\\

    \hspace*{1cm} {\tt Global$_3$ = <office,\{office\#1\}>}\\

    \hspace*{2cm} {\tt \small office\#1 = } \parbox [t]{9cm}{\small place of business where professional
    or clerical duties are performed} \\

%    \pagebreak

    \item [b)] \textbf{More than one Local Class belongs to the Global
    Class ($n>1$)}. We examine the following cases:
    \begin{enumerate}
        \item \emph{There is a synonymy relationships among all the
        Local Class names}.\\In this case, the system has to
        assign the union of the local concepts to the meaning of
        the Global Class, and with respect to the name, the
        designer has to choose the more significant term.\\Notice
        that, if a synonymy relationship $lcName_i$ \texttt{SYN}
        $lcName_j$ was generated by the lexical analysis, then the
        corresponding meanings are the same.

        The clustering result is:\\

        \hspace*{1cm} {\tt Global$_0$ = \{CS.Course, UNI.Section\}}\\

        where\\

        \hspace*{1cm} {\tt CS.Course = <course,\{course\#1\}>}\\
        \hspace*{1cm} {\tt UNI.Section = <section,\{course\#1\}>}\\

        and with the following relation:\\

        \hspace*{1cm} {\tt CS.Course SYN UNI.Section}\\

        following the rules, the global class is:\\

        \hspace*{1cm} {\tt Global$_0$ = <course,\{course\#1\}>}\\
        or\\
        \hspace*{1cm} {\tt Global$_0$ = <section,\{course\#1\}>}\\

        \hspace*{2cm} {\tt \small course\#1 = } \parbox [t]{9cm}{\small education imparted
        in a series of lessons or class meetings} \\

        \item \emph{All the class names are connected only by narrow
        (broader) term relationships}. The name and the meaning of
        the Global Class are derived from the broadest local class
        of the cluster.

        The clustering result is:\\

        \hspace*{0.5cm} {\tt Global$_5$ = \{CS.Essay, CS.Publication, UNI.Article\}}\\

        where\\

        \hspace*{0.5cm} {\tt CS.Essay = <essay,\{essay\#1\}>}\\
        \hspace*{0.5cm} {\tt CS.Publication = <publication,\{publication\#2\}>}\\
        \hspace*{0.5cm} {\tt UNI.Article = <article,\{article\#1\}>}\\

        and with the following relations:\\

        \hspace*{0.5cm} {\tt UNI.Article NT CS.Publication}\\
        \hspace*{0.5cm} {\tt CS.Essay NT CS.Publication}\\

        following the rules:\\

        \hspace*{0.5cm} {\tt Global$_5$ = <publication,\{essay\#1,publication\#2,article\#1\}>}\\

        \hspace*{0.5cm} {\tt \small essay\#1 = } \parbox [t]{9cm}{\small an analytic or interpretive
        literary composition} \\
        \hspace*{0.5cm} {\tt \small publication\#2 =} \parbox [t]{9cm}{\small a copy of a printed work
        offered for distribution} \\
        \hspace*{0.5cm} {\tt \small article\#1 =} \parbox [t] {9cm}{\small nonfictional prose
        forming an independent part of a publication} \\

        \item \emph{All the class names are connected by synonymy and
        narrow (broader) term relationships}. If it is possible to
        calculate the transitive closure of the meanings, then the
        system suggests the broadest meaning. Otherwise, see next
        case.

        The clustering result is:\\

        \hspace*{0.6cm} {\tt Global$_4$ = \{} \parbox[t] {10cm}{ {\tt CS.CS\_Person,
        CS.Professor, UNI.School\_Member, UNI.Research\_Staff, CS.Student\}}} \\

        where\\

        \hspace*{1cm} {\tt CS.CS\_Person = <person,\{person\#1\}>}\\
        \hspace*{1cm} {\tt CS.Professor = <professor,\{professor\#1\}>}\\
        \hspace*{1cm} {\tt UNI.School\_Member = <student,\{student\#1\}>}\\
        \hspace*{1cm} {\tt UNI.Research\_Staff = <researcher,\{professor\#1\}>}\\
        \hspace*{1cm} {\tt CS.Student = <student,\{student\#1\}>}\\

        and with the following relations:\\

        \hspace*{1cm} {\tt CS.Professor NT CS.CS\_Person}\\
        \hspace*{1cm} {\tt UNI.School\_Member NT CS.CS\_Person}\\
        \hspace*{1cm} {\tt UNI.Research\_Staff SYN CS.Professor}\\
        \hspace*{1cm} {\tt UNI.Research\_Staff NT CS.CS\_Person}\\
        \hspace*{1cm} {\tt UNI.School\_Member SYN CS.Student}\\
        \hspace*{1cm} {\tt CS.Student NT CS.CS\_Person}\\

        following the rules:\\

        \hspace*{1cm} {\tt Global$_4$ = <person,\{person\#1,professor\#1,student\#1\}>}\\

        \hspace*{2cm} \parbox {10cm}{\small {\tt person\#1 = } a human being} \\
        \hspace*{2cm} {\tt \small professor\#1 = } \parbox [t]{9cm}{\small someone who
        is a member of the faculty at a college or university} \\
        \hspace*{2cm} {\tt \small student\#1 = } \parbox [t]{9cm}{\small a learner who
        is enrolled in an educational institution} \\

        \item \emph{Other cases}. In every other case, the designer
        has to manually select the name and the meaning(s) of the
        Global Class.
    \end{enumerate}
\end{itemize}

Given a Global Class $gc$, a set of Local Classes belonging to
$gc$ ($lc_{1},\ldots,lc_{n}$), the next table summarizes the
described cases (Table \ref{suntotable}).

\begin{table}[ht]
\begin{center}
\footnotesize
\begin{tabular}[h]{|c|l|l|}
\hline
  \textbf{Case} & \textbf{Local Class} & \textbf{Global Class} \\
  \hline
  1 & $lcName_{i}$ \texttt{SYN} $lcName_{j}$ for each $i,j$ & $gcName=lcName_{1} or lcName_{2} or \ldots$ \\
    &   & $gcM=\cup_i\{lcM_{i1},\ldots,lcM_{im}\}$ \\
  \hline
  2 & $lcName_i$ \texttt{BT} $lcName_j$ for each $i\neq j$ & $gcName=lcName_i$ \\
    &   & $gcM=\{lcM_{i1},\ldots,lcM_{im}\}$ \\
  \hline
  3 & $lcName_1$ \texttt{BT} ($lcName_2$ \texttt{SYN/BT} $lcName_n$) &  $gcName=lcName_i$\\
    &   & $gcM=\{lcM_{11},\ldots,lcM_{1m}\}$ \\
  \hline
  4 &  &  $gcName=lcName_{1} or \ldots lcName_{n}$\\
    &   & $gcM\subseteq\cup_i\{lcM_{i1},\ldots,lcM_{im}\}$ \\
  \hline
\end{tabular}
\end{center}
\caption{Global Class annotation rules.} \label{suntotable}
\end{table}
\normalsize

When $gcM$ is different from the union of all the local classes
meanings, some semantics (lexical relationships) is lost. To avoid
this loss of semantics, we can consider all the meanings of the
local classes belonging to a Global Class, i.e. we could have
$gcM=\cup_i\{lcM_{i1},\ldots,lcM_{im}\}$.

%Further aspects of this problem will be investigated later (see
%page \pageref{p4:lexproblems}).

\pagebreak
\subsubsection{Global Attributes' annotation}
\label{s4:gaannotation} In order to semi-automatically associate
the name and the meanings to global attributes, we extended the
approach stated before. In this way, the designer must only
refine the suggestions he does not like.\\

\noindent With respect to the complete reference example presented
in Appendix ``\ref{A1:example}'' we can have the following situation:\\

\noindent Global Class \textbf{Global$_4$} (\textbf{Person})
\scriptsize
\begin{center}
\begin{ttfamily}
\begin{tabular}{|l|c|c|c|c|c|}
\hline
 & CS & CS & CS & UNI & UNI \\
\hline
 & CS\_Person & Professor & Student & Research\_Staff & School\_Member \\
\hline
belongs\_to & null & belongs\_to & null & null & null \\
\hline
dept\_code & null & null & null & dept\_code & null \\
\hline
e\_mail & null & null & null & e\_mail & null \\
\hline
faculty & null & null & null & null & faculty \\
\hline
name & first\_name and & first\_name and & first\_name and & name & name \\
  & last\_name & last\_name & last\_name & & \\
\hline
rank  & null & rank & rank & null & null \\
\hline
relation  & null & null & null & relation & null \\
\hline
section\_code  & null & null & null & section\_code & null \\
\hline
title  & null & title & null & null & null \\
\hline
year  & null & null & year & null & year \\
\hline
\end{tabular}
\end{ttfamily}
\end{center}
\normalsize


\noindent the local attributes have been annotated:\\

\noindent \hspace*{1cm} {\tt CS.Student.first\_name = <first\_name,\{first name\#1\}>}\\
\hspace*{1cm} {\tt CS.Student.last\_name = <last\_name,\{last name\#1\}>}\\
\hspace*{1cm} {\tt CS.Professor.name = <name,\{name\#1\}>}\\
\hspace*{1cm} {\tt CS.Professor.rank = <rank,\{rank\#2\}>}\\
\hspace*{1cm} {\tt CS.Student.rank = <rank,\{rank\#4\}>}\\
\hspace*{1cm} {\tt CS.Professor.title = <title,\{title\#6,tile\#9\}>}\\


\noindent \hspace*{1cm} {\tt \small first name\#1 = }
\parbox [t]{9cm}{\small the name that precedes the surname} \\
\hspace*{1cm} {\tt \small last name\#1 = }
\parbox [t]{9cm}{\small the name used to identify the members of a family} \\
\hspace*{1cm} {\tt \small name\#1 = }
\parbox [t]{9cm}{\small a language unit by which a person or thing is known} \\
\hspace*{1cm} {\tt \small rank\#2 = } \parbox [t]{9cm}{\small relative status} \\
\hspace*{1cm} {\tt \small rank\#4 = } \parbox [t]{9cm}{\small position in a social hierarchy} \\
\hspace*{1cm} {\tt \small title\#6 = }
\parbox [t]{9cm}{\small an identifying appellation signifying status or function} \\
\hspace*{1cm} {\tt \small title\#9 = }
\parbox [t]{9cm}{\small an appellation signifying nobility} \\

\noindent we also have these relations:\\

\noindent \hspace*{1cm} {\tt CS.CS\_Person.first\_name NT UNI.Research\_Staff.name}\\
\hspace*{1cm} {\tt CS.CS\_Person.last\_name NT CS.Research\_Staff.name}\\
\hspace*{1cm} {\tt CS.CS\_Person.first\_name NT UNI.School\_Member.name}\\
\hspace*{1cm} {\tt CS.CS\_Person.last\_name NT CS.School\_Member.name}\\
\hspace*{1cm} {\tt CS.Student.rank SYN CS.Professor.rank}\\

At this point, we may distinguish three possible cases:
\begin{enumerate}
    \item \emph{The Global Attribute maps only one Local Attribute}. In
    this case, the Global Attribute has the same name and the same
    meaning of the mapped Local Attribute.\\

    \hspace*{1cm} {\tt Global$_4$.title = <title,\{title\#6,tile\#9\}>}\\

    \item \emph{The Global Attribute maps more than one Local
    Attribute (only with simple correspondence)}. The name of the
    Global Attribute is chosen according with the rules defined in
    the present MOMIS framework. Regarding the meaning choice, we distinguish
    two possible solutions, similarly to the Global Class case. In fact,
    the Global Attribute may be assigned the meaning corresponding
    to the Local Attribute, to which the name refers. In this case,
    some further relationships between this attribute and a
    hypothetic new source can not be extracted (we lose some of
    the meanings mapped by the Global Attribute). The second
    approach assign the meanings as the union of the meanings of
    the mapped Local Attributes.\\

    \hspace*{1cm} {\tt Global$_4$.rank = <rank,\{rank\#2,rank\#4\}>}\\

    \item \emph{The Global Attribute maps more than one Local
    Attribute (correspondence defined by functional mappings)}.
    The rule is the same of point 2. In particular, according to
    the mapping function, we may develop some ways in order to
    ignore some meanings (transitive closure calculation, \ldots),
    or to prefer other ones.\\

    \hspace*{1cm} {\tt Global$_4$.name = <name,\{first name\#1,last name\#1,name\#1\}>}\\

\end{enumerate}
In all other cases we consider all the mappings, and the designer
will select a significant name.\\

%\label{p4:lexproblems}


\subsection{The new integration process}
\label{s4:newprocess} As we have just seen, the annotation phase
enriches the semantics of the Schema adding significant names and
meanings to global terms. The Global Schema is now a satisfactory
synthesis of the local sources and it is ready to be used  as a
component of the new integration process.

\vspace{0.3cm} \emph{\textbf{The new integration process involves:
the GVV, previously enriched, and the new source schemas
extracted by wrappers}}.\\

In other words, the global classes of the GVV are considered as
local classes and they are integrated with the local classes of
the new sources. As mentioned, this methodology aims at obtaining
a new GVV reducing relevant changes. This aspect guarantees a
minor impact for the applications based on the previous view. In
fact, other modules or applications could have been optimized for
the old GVV, therefore that view has to be saved from useless
changes. Figure \ref{newprocess} schematically represents
schematically the new integration process and in particular the
components that are involved.
\begin{figure}[ht]
  \begin{center}
    \epsfig{figure=newprocess.eps,totalheight=7cm,angle=0}
    \caption{The new integration process.}\label{newprocess}
  \end{center}
\end{figure}

Before going on, we define the meaning of some symbols we will use
later.
\begin{itemize}
    \item [] $gcOld$ is a Global Class of the old integrated
    schema. It is composed of a name ($gcOldName$) and a set of
    global attributes ($gcOldAtt_j$).
    \item [] $lcNew$ is a Local Class of the new source. It is
    composed of a name ($lcNewName$) and a set of local attributes
    ($lcNewAtt_k$).
    \item [] $gcNew$ is a Global Class of the new integrated
    schema. It is composed of a name ($gcNewName$) and a set of
    global attribute ($gcNewAtt_i$).
\end{itemize}

\vspace{0.3cm} In accordance with the usual integration
methodology (see sec. \ref{s3:SI-Designer}) we summarize the
steps to integrate the new sources strengthening the principal
differences:
\begin{enumerate}
    \item wrappers extract the schemata from the new candidate
    sources and translate it in the MOMIS common language, \lang;
    \item Common Thesaurus of the involved sources is built up and
    contains:
    \begin{itemize}
        \item schema-derived relationships extracted from the
        analysis of the new sources (\emph{old global classes do not
        add significant relationships});
        \item inter-schema lexicon-derived relationships (new
        sources will be annotated by the designer and old global
        classes have to be semantically enriched according to the
        rules shown in \ref{s4:gcannotation});
        \item user supplied relationships;
        \item inferred relationships;
    \end{itemize}
    \item Clusters generation using the usual methodology;
    \item Global Classes' and mapping tables' refinement;
    \item annotation of the Global Schema as described before.
\end{enumerate}

Before explaining some details we want to express important
considerations about this new approach.\\

\emph{\textbf{The integration process is based fundamentally on
lexical semantics}}. In fact, as we have seen also presenting the
first attempt, we can not exploit the relationships contained in
the Common Thesaurus because these relationships involve local
sources referring to the previous integration session. Moreover,
we cannot extract any relationship from the Global Schema because
Global Classes are flat, that is, they have any type of structure
from which relationships can be inferred. Therefore we have to
define new strategies to find out relationships among Global
Classes if we want to effectively integrate the GVV with new
sources. The solution is the presented annotation process of
global terms with respect to the lexical database WordNet.
Semantics information allows the system to generate lexical
relationships which are useful during the integration.

If we analyze this aspect more deeply, we can say that it is
possible that new sources have some lexical relationships with a
concept discarded and not annotated in a Global Class.

For example, let us consider the case in Figure \ref{error}; if
the annotated meaning within the cluster composed of $\{person,
professor\}$ is only the broadest (i.e. $person$), the
relationship with the new class $faculty$ will be lost. In fact,
the concept belonging to the new source is a holonym of a concept
associated to a local class, and this relationship is not
transitive.
\begin{figure}[h]
  \begin{center}
    \epsfig{figure=error.eps,angle=0}
    \caption{Lexical problems.}\label{error}
  \end{center}
\end{figure}
With respect to a previous hypothesis for considering the union of
the local classes' meanings in the annotation of a global class,
we can illustrate some possible side effects. In the preceding
example, if the global class is annotated with both the meanings
of $person$ and $professor$, the holonym relationship between
$faculty$ and $professor$ will be promoted to the global class.
The result is that all the elements belonging to this global class
will have a holonym relationship with $faculty$ and in this
specific case, will be part of a $faculty$. This partially wrong
result will be corrected within the Common Thesaurus, where
further relationships generated by other terms of involved sources
are present.

\vspace{0.2cm} If we consider the Global Class and mapping table
refinement, we can say that the objective of this phase is to
provide mapping rules among \emph{Global Classes} and, new or old
\emph{Local Classes}. In order to achieve this result, we
substitute \emph{old Global Glasses} with the respective
\emph{Local Classes} preserving all the previous mappings. In this
way, new Global Classes, representing old Local Classes and new
Local Classes, are built. Following this approach, if we can
generally (and temporally) represent a Global Class as a set of
old Global Glasses and new Local Classes:
\begin{center}
$gcNew=\{gcOld_1,\ldots,gcOld_p,lcNew_1,\ldots,lcNew_n\}$
\end{center}
the result of the rewriting step will be:
\begin{center}
\mbox{$gcNew =\{lcOld_{11},\ldots,lcOld_{1z},\ldots,lcOld_{p1},
\ldots,lcOld_{pn},lcNew_1,\ldots,lcNew_n\}$.}
\end{center}

\noindent For example:
\begin{center}
{\tt gcNew = \{GVV.Room, Math.ClassRoom\} }
\end{center}
that becomes:
\begin{center}
{\tt gcNew = \{CS.ClassRoom, UNI.Room, Math.ClassRoom\}}\\
\end{center}


\noindent The following are the possible cases that can arise in
the creation of global classes (see also Appendix
``\ref{A1:example}''):

\begin{description}
    \item[Case A.] A new global class $gcNew$ is composed of only one
    old global class ($gcOld$), and one or more than one new local
    classes ($lcNew_i$):\\

    \hspace*{1cm} $gcNew=\{gcOld, lcNew_1,\ldots,lcNew_i,\ldots,lcNew_n\}$\\
    \hspace*{1cm} \vspace{0.4cm} {\tt gcNew = } \parbox
    [t]{8cm}{\tt \{GVV.Person,Math.Person,Math.Researcher, Math.Student,Math.Teacher\}}\\

    Regarding this case we can observe that new sources' classes can be
    ``integrated'' by the way of the old GVV, thus, without
    effects on the applications based on that previous schema.

    \vspace{0.2cm} The new global class ($gcNew$) may have new
    global attributes generated from the semantic contribution of
    new local classes. In this case, the new global class has a
    name ($gcNewName$), a set of global attributes derived from
    the old global class ($gcOldAtt_i$) and a set of new global
    attributes ($gcNewAtt_j$).

    \vspace{0.2cm} New mapping rules define the connection
    between a global attribute and its corresponding local
    attribute(s). In this situation, global attributes belonging
    to the $gcOld$ ($gcOldAtt_i$) can map both local classes of
    the previous GVV and new local classes (see the column
    associated to $lcNew_1$, for example). New global attributes
    can only map new local classes (see the null cells in the
    table).
    \begin{table}[ht]
    \begin{center}
    \footnotesize
    \begin{tabular}[h]{|c|l|l|l|l|l|l|}
    \hline
      & $lcOld_1$ & \hspace{2em} \ldots \hspace{2em} & $lcOld_k$ & $lcNew_1$ & $lcNew_t$ & $lcNew_n$ \\
    \hline
    $gcOldAtt_1$ & \multicolumn{3}{|c|}{ } & \multicolumn{3}{|c|}{ }\\
    \cline{1-1}
    \ldots  & \multicolumn{3}{|c|}{the same mappings as in $gcOld$} & \multicolumn{3}{|c|}{ }\\
    \cline{1-1}
    $gcOldAtt_m$ & \multicolumn{3}{|c|}{ } & \multicolumn{3}{|c|}{new mappings} \\
    \cline{1-4}
    $gcNewAtt_1$ & \multicolumn{3}{|c|}{ } & \multicolumn{3}{|c|}{ } \\
    \cline{1-1}
    \ldots  & \multicolumn{3}{|c|}{null mappings} & \multicolumn{3}{|c|}{ } \\
    \cline{1-1}
    $gcNewAtt_p$ & \multicolumn{3}{|c|}{ } & \multicolumn{3}{|c|}{ } \\
    \hline
    \end{tabular}
    \normalsize
    \end{center}
    \caption{A new mapping table example.}\label{t:caseA}
    \end{table}

    With respect to the meanings associated to each global
    attribute we have that:
    \begin{itemize}
        \item the meaning(s) of old global attributes have to be
        enriched with the semantics of the new local classes
        possibly mapped by this attribute;
        \item the meanings(s) of new global attributes have to be
        set according to the rules defined before (sec.
        \ref{s4:gcannotation}).
    \end{itemize}

    \item[Case B.] A global class of the new integrated schema is
    composed of only new local classes:\\

    \hspace*{1cm} $gcNew=\{lcNew_1,\ldots,lcNew_i,\ldots,lcNew_n\}$\\
    \hspace*{1cm} \vspace{0.4cm} {\tt gcNew = } \parbox [t]{8cm}{\tt \{Math.Examination\}}\\

    This situation describes the case in which the schema is
    extended without interfering with the previous classes.\\The
    new global class ($gcNew$) has a name ($gcNewName$) and a set
    of new global attributes ($gcNewAtt_i$).\\The new global
    attributes map only new local classes.\\The names and meanings of
    the global attributes are defined following the rules stated
    before (sec \ref{s4:gcannotation}).

    \item[Case C.] A global class of the new integrated schema is
    composed of more than one global class of the GVV and at least
    one local class of the new sources that we are integrating:
    \begin{center}
    $gcNew=\{gcOld_1,\ldots,gcOld_p,lcNew_1,\ldots,lcNew_i,\ldots,lcNew_n\}$
    \end{center}
    In this case the previous GVV is modified; side effects can
    influence the applications based on the previous schema.\\The
    new global class ($gcNew$) has a name ($gcNewName$) and a set
    of new global attributes ($gcNewAtt_i$).\\If an old global
    attribute ($gcOldAtt_j$) is not ``fused'' with another global
    attribute belonging to a different old global class, no change
    to the previous mapping rules is necessary. In other words,
    for this global attribute all the previous mappings, w.r.t.
    the previous $lcOld$, are valid. Otherwise we have to define
    new mappings.
\end{description}

It can be demonstrated that these are the three only possible
cases that we can encounter. This claim remains true only if the
same clustering parameters are used during the new integration
process.


\section{Necessary changes}
\label{s4:changes} The present framework of the Momis system is
not able to accomplish the presented approach, so some changes are
necessary. Now we try to analyze the principal modifications that
have to be designed and realized in the future.

\vspace{0.3cm} According to the approach we have illustrated, two
main parts of intervention are: I) global schema annotation and
II) new sources integration. These phases are managed by
SI-Designer component, therefore changes will interest its modules
(see sec. \ref{s3:SI-Designer}).

\vspace{0.3cm} \noindent \textbf{I) Global Schema annotation.}

First of all, the global class building and refinement process
have to be changed in order to allow the designer to annotate
global classes and attributes. The SI-Designer modules involved
are:
\begin{itemize}
    \item ARTEMIS: at present this module computes global
    clusters exploiting affinity indexes. New features have to be
    added to guide the designer after the creation of the global
    classes. In particular we need features in order to:
    \begin{itemize}
        \item select a significant name for each global class,
        suggesting possible names to the designer according to the
        rules explained before in sec. \ref{s4:gcannotation};
        \item assign the correct meanings to each global class
        suggesting possible meanings to the designer according
        to rules in sec. \ref{s4:gcannotation}.
    \end{itemize}
    \item TUNIM: at present this module computes global
    attributes and helps the designer during the refinement phase.
    New features have to be added to accomplish the new rules
    defined in sec. \ref{s4:gaannotation}, that is to enrich
    global attributes with meanings derived from local attributes
    annotation. In particular we need features in order to:
    \begin{itemize}
        \item select a significant name for each global attribute;
        \item assign the correct meanings to each global attribute
        suggesting possible meanings to the designer according
        to rules in sec. \ref{s4:gaannotation}.
    \end{itemize}
\end{itemize}

\vspace{0.3cm} \noindent \textbf{II) New sources' integration.}

After the enrichment process we need to modify the integration
process to be able to integrate new sources according to the
proposal of sec. \ref{s4:newprocess}. Principally we have to
modify:
\begin{itemize}
    \item SAM: at present this module allows the designer to import
    sources to be integrated. New features have to be
    added to import the previous GVV and to treat it as candidate source.
    \item SIM: at present this module extracts Common Thesaurus
    relationships from the local schemata and infers new relationships
    using ODB-Tools. Changes are necessary
    to exclude that the module treats the previous GVV as a normal schema.
    \item SLIM: this module allows the designer to annotate the
    local terms. We have to modify the module in order to exploit
    the global schema annotation.
\end{itemize}


\section{Some considerations about the new process}
\label{s4:consnewprocess} We have introduced a new integration
process approach, now we present some considerations about
advantages and drawbacks we have noticed during the study.
\begin{description}
    \item[Benefits]:
    \begin{itemize}
        \item The process does not restart from scratch and therefore
        the designer's effort and the computational effort are reduced.
        \item The process exploits the knowledge acquired during
        the previous integration sessions (especially annotation);
        the time for integrating is remarkably reduced.
        \item The previous schema is preserved as much as possible
        from useless changes and therefore the possible side effects on
        the based applications are reduced.
        \item The present methodology of Momis is preserved, only
        some additions and modification are necessary.
    \end{itemize}
    \item[Drawbacks]:\begin{itemize}
        \item We must annotate the GVV, before integrating new
        sources.
        \item The mistakes of the previous integration session can
        propagate to the new schema.
        \item The new GVV is based on the previous one, and then
        it could not represent all the local sources in the best way.
        \item Repeated sessions of integration can reduce the
        expressive power of the integrated schema.
    \end{itemize}
\end{description}




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