=Paper=
{{Paper
|id=Vol-494/paper-6
|storemode=property
|title=Exploiting Agents and Ontologies for Type- and Meaning-Safe Adaptation of Java Programs
|pdfUrl=https://ceur-ws.org/Vol-494/mallowawesomepaper6.pdf
|volume=Vol-494
|dblpUrl=https://dblp.org/rec/conf/mallow/MascardiA09
}}
==Exploiting Agents and Ontologies for Type- and Meaning-Safe Adaptation of Java Programs==
https://ceur-ws.org/Vol-494/mallowawesomepaper6.pdf
Exploiting Agents and Ontologies for Type- and
Meaning-Safe Adaptation of Java Programs
Davide Ancona and Viviana Mascardi
DISI, University of Genova,
Via Dodecaneso 35, 16146, Genova, Italy
{davide,mascardi}@disi.unige.it
Abstract—This paper discusses an application of intelligent The limitation of their work, that we want to overcome
software agents and ontologies to solve the problem of semi- by exploiting intelligent agents and ontologies in our system,
automatic porting of Java programs. is that they abstract from the names of classes, methods
We have designed a system for aiding users to adapt Java
code in a type- and meaning-safe way, when an application has and attributes and just consider safe matching between types.
to migrate to new libraries which are not fully compatible with Since there may be a large number of type correspondences
the legacy ones. < τ , τ 0 > that preserve type-safety, re-introducing names
To achieve this, we propose an approach based on an inte- of classes, methods and attributes into the algorithm that
gration of the two type-theoretic notions of subtyping and type matches libraries’ elements may help in removing those cor-
isomorphism with ontology matching. While the former notions
are needed to ensure flexible adaptation in the presence of type-
respondences that, even if type safe, are not “meaning-safe”.
safety, the latter supports the user to preserve the meaning of Correspondences between names of methods and attributes
names that appear in the program to be adapted. are also needed during the translation process where type
Intelligent agents control the different components of the correspondences are not enough.
system and interact with other agents in order to provide the final Assume that we would like to port p from l to l0 . For
user with the semi-automatic porting service he/she required.
simplicity, the problem can be reduced to the following
example scenario: p is the program
I. I NTRODUCTION AttributeList atts;
Migrating a Java program p that uses library l into a String name = atts.getName(0);
corresponding program p0 that uses library l0 in a semi-
and l is defined as follows:
automatic way is an open problem for which no satisfying
solution has been found yet. c l a s s AttributeList e x t e n d s Object {
One aspect that must be considered while facing this prob- String getName( i n t i){...}
lem, and that makes it hard to solve, is that migration must }
be type-safe. Replacing method m defined by l and used in
program p by m0 defined in l0 , thus leading to a new program where Object and String are the usual predefined classes
p0 , is a legitimate operation only if no type inconsistencies are defined in the standard package java.lang.
raised by this replacement. If the functionality of m and m0 The library l0 to which p has to be ported contains the
is the same no type problems will arise. But what should it following class declarations:
happen in case of a difference in the type returned by m and c l a s s Attributes e x t e n d s Object {
m0 , or in the type of some of their parameters, or in their int getLength(){...}
number and order? The most conservative approach would String getLocalName( i n t index){...}
be to give up, and to consider the migration possible only String getAttributeType( i n t index){...}
if elements of l used by p have corresponding elements in l0 }
whose type is identical or isomorphic.
However, this is a very restrictive choice with little motiva- The approach discussed in [1] would tell us that the
tion: type identity or isomorphism between elements of l and structural types of AttributeList and Attributes are
the corresponding elements of l0 may be relaxed by requiring compliant because of a combination of isomorphism and
that the type τ 0 of e0 in l0 is a subtype of the type τ of e in l, for subtyping. Or, in other words, would tell us that the cor-
a suitable definition of the subtype relation. This requirement respondence is type
allows a type-safe replacement of e in p with e0 in p0 . safe. This is a useful information, but it does not help us in
For example, R. Di Cosmo, F. Pottier and D. Rémy propose automatically translating p into p0 in order to use l0 .
an efficient decision algorithm for subtyping recursive types What we would like to have, instead, is the set of correspon-
modulo associative commutative products that demonstrates dences {, }. This set cannot be obtained by just
when translating a program into another [1]. checking the type compliance of String getName(int)
with int getLength(), String getLocalName(int), to it1 . If the user (agent, software application) wants the
and String getAttributeType(int). additional service of performing the translation of a Java
In fact, while getLength is not type compliant program p that uses library l into a Java program p0 that uses
with getName, both getLocalName and l0 , the match function can in turn be given in input to the
getAttributeType are. However, we expect that Translation Agent which computes a translation p0 of p driven
the right correspondence is that between getName and by match.
getLocalName, due to the intended meaning of their The match function is obtained in the following way:
names. ontologies o and o0 are extracted from libraries l and l0
It is here that ontologies come into play: assuming that respectively. In a similar way, collections of types t and t0
an “ontology matching algorithm” can devise the corre- are extracted from l and l0 .
spondences between ontology elements (classes, properties, The Ontology Matching Agent interacts with a set of Simple
relationships, individuals) that better respect their intended Ontology Matching agents (SOMi in Figure 1), each in charge
meaning, and assuming that from a Java library, an ontology of running one specific ontology matching algorithm chosen
carrying the intended meaning of the library elements can be from a pool of existing ones (see Section IV, last paragraphs).
extracted, we propose to extract ontologies o and o0 from l The Ontology Matching Agent may decide to demand the
and l0 , and to run a matching algorithm on them. ontology matching service to the SOM agent that has the
And it is here that agents come into play: the system that lowest workload, to the one that seems more suitable to
we have designed consists of complex components that must correctly match ontologies o and o0 according to quality of
provide different kinds of services (type and ontology extrac- service criteria or efficiency needs, or to any other SOM
tion, type and ontology matching, filtering of the matching agent according to some policy including running all the
results, assisted extraction of the translation function, actual available ontology matching algorithms and either merging
translation) either to the final user or to other system’s com- the obtained results or selecting one of them based on ex-post
ponents. In order to make our system as flexible as possible, analysis2 . At the end, the Ontology Matching Agent obtains
we associate an intelligent agent with each component. The from one or more SOMs the alignments (namely, the sets of
agent controls the component and interacts both with other correspondences) a1 , a2 , ..., an between o and o0 and merges
agents and with the user. them or selects the most preferred alignment among them if
The output of the type and ontology matching algorithms, it is the case. The Type Matching Agents behaves in the same
controlled by a Type Matching Agent and by an Ontology way, controlling a set of Simple Type Matching agents (STMj
Matching Agent respectively, will be combined by a Filtering in Figure 1) each in charge of running a specific type matching
Agent in order to produce a type- and meaning- safe matching algorithm on t and t0 to get tm. The type match tm is used for
relation. A human user assisted by a Function Extraction selecting only those correspondences in a that are type safe.
Assistant Agent will disambiguate multiple possible matchings We name this activity “filtering”.
in order to identify a match function which will finally be Filtering, whose responsibility is given to the Filtering
used by a Translation Agent to translate p into p0 . Agent, still does not ensure that we obtain a set of correspon-
Continuing the example above, p0 would be dences that is a function: it might still be a relation, because
more than one correspondence involving e ∈ l is both type-
Attributes atts; and meaning-safe.
String name = atts.getLocalName(0);
The user is involved in the loop for making the relation
where Attributes = match(AttributeList) and output by the Filtering Agent turn out into a match func-
getLocalName = match(getName). Thanks to the tion: if many correspondences are possible for an element
match function, the translation from p to p0 can be fully e ∈ l, the user will be asked to make his/her choice among
automatized. them. Another information must be integrated into the match
The aim of this paper is to discuss a multiagent system function, namely, for any method m ∈ l, which injection
that exploits type and ontology matching techniques to make must be applied on its parameters p1 , ..., pn in order to obtain
automatic migration of Java programs possible. The paper
1 Currently, some agents belonging to the MAS such as type matching
is organized in the following way: Section II describes the and filtering agents have little decisional power and autonomy, so they could
architecture of our multiagent system and Sections III and be collected into a single sequential process, simplifying the system design.
IV describe the Ontology Extraction and Ontology Matching However, we expect that these agents may be equipped with a higher degree
of intelligence in a future version of the system. Hence, we model them as
agents in detail. Section V concludes and highlights future agents even if, in the current version, they are just service providers.
directions of work. 2 Alignments can be compared according to their precision and recall.
Unfortunately, computing precision and recall of an alignment between o
and o0 is only possible if a reference alignment for o and o0 has already
II. A RCHITECTURE been developed by hand. In fact, precision is defined as the number of
correctly found correspondences with respect to a reference alignment divided
The purpose of our multiagent system, depicted in Figure by the total number of found correspondences and recall is defined as the
1, is to provide the service of computing a match function number of correctly found correspondences divided by the total number of
between the elements of two Java libraries l, l0 given in input expected correspondences. The higher the precision and recall, the better. If
no reference alignment exists, only quantitative features of the alignment such
either by a human user or by any other software application, by as dimension, number of correspondences with the same first element, etc, can
exploiting interactions among the different agents belonging be considered to decide whether one alignment is “better” than another one.
Fig. 1. The architecture of our multiagent system.
the tuple p1 , ..., pk , k ≤ n whose ordered elements can be Type Extraction Agent
used as parameters for m0 ∈ l0 , where m0 = match(m). The Type Extraction Agent takes one Java library as input
Also in this case, the user may be required to make a and returns a collection of types following S. Jha, J. Palsberg
choice if more injections are possible. For example method and T. Zhao’s proposal [2], [3]. Since Java classes belonging
m1(c1, int, String) in l might be type- and meaning- to a library may mutually refer to one another, types in the
safely replaced by m2(int, String, c1) in l, but a per- collection may be mutually recursive. In our system, the Type
mutation of its parameters is required when actually translating Extraction Agent must operate on both l and l0 in order
p that uses m into p0 that uses m0 . to extract the corresponding collections of types, t and t0
The match function (which is indeed a family of functions respectively.
working either on elements of l, or on tuples of elements of
l) is needed by the Translation Agent.
Of course, it might also happen that the Filtering Agent Ontology Matching Agent
cannot achieve its goal because there are some elements in l The service offered by the Ontology Matching Agents is
for which no corresponding element in l0 has been found and returning an alignment of the two ontologies taken in input.
thus no match function from l to l0 can be computed. The This agent is responsible for the “meaning-safety” of the
user will be involved in this case too: the Filtering Agent will matching between elements of l and elements of l0 ; it will take
inform him/her that no type and meaning-safe matching was the ontologies o and o0 extracted from l and l0 respectively
possible for some elements, and the result of the filtering stage as input and will return an ontology alignment a between
will be shown to him/her. Even if no automatic translation of p them. As we will discuss in Section IV, many ontology
will be possible due to the impossibility to generate a match matching algorithms and tools exists: we will integrate the
function, the user might find the result of the Filtering Agent most relevant ones into our system by implementing, for each
useful for driving his/her hand-made translation. of them, a SOM agent that provides an interface towards the
If, thanks to the human intervention, a match function has algorithm/tool. The Ontology Matching Agent will coordinate
been defined, the automatic translation of p into p0 can be the activity of SOM agents
performed by the Translation Agent, leading to the desired
output, namely program p0 . Type Matching Agent
In the sequel of this section, each agent is shortly presented.
Once the collections of types induced by l and l0 have
Agents that deal with ontologies are discussed in more detail
been extracted, a type-safe matching between them must be
in the next sections.
computed. The algorithm we will use for this activity is
Ontology Extraction Agent inspired by that proposed by R. Di Cosmo, F. Pottier and
D. Rémy in [1] and is briefly described in [4]. It ensures the
The Ontology Extraction Agent takes one Java library as type-safety of the matching.
input and returns an ontology that models the structure of the
library in term of its classes, their subclass relationships, their
methods and attributes. This agent, described in Section III, Filtering Agent
must operate on both l and l0 in order to obtain o and o0 In order to find a matching between the elements of l and
respectively. those of l0 that is both type-safe and that takes the meaning
of names of methods, attributes and classes into account, as Ontology Extraction Agent. In case more ontology extraction
well as their structural relationships, we need to filter elements algorithms should be implemented, the Ontology Extraction
of a by taking the type-safe correspondences contained in tm Agent might coordinate interface agents towards all or some
into account. A Filtering Agent that implements the algorithms of them, in the same way as the Ontology Matching and Type
described in [4] has been designed to this aim. Matching agents do.
In order to explain how the extraction algorithm works,
Function Extraction Assistant Agent we need to provide some details on the subset of OWL that
In the general case the output of the Filtering Agent, tsa we will use for representing ontologies corresponding to Java
(for type safe alignment), will not be deterministic enough libraries. We have designed the extraction in order to make
to be used for translating a program p that uses l into this subset as small as possible. In particular, it is a proper
the corresponding program p0 that uses l0 . There might be subset of OWL Lite.
elements of l that can be matched to more than one element a) Data Types: Data Types used in OWL ontologies are
in l0 taking both types and meaning into account, and no those defined by the XML Schema specification, http://www.
algorithm could automatically determine the right choice. w3.org/TR/xmlschema-2/:
Once most of the work has been done and the subset tsa of • decimal represents the subset of the real numbers, which
elements(l) × elements(l0 ) has been generated, the Function can be represented by decimal numerals; integer is de-
Extraction Assistant Agent comes into play and interacts with rived from decimal by fixing the number of decimal
the user in order to complete the definition of the match digits to 0, and disallowing the trailing decimal point.
function that will drive the translation from p to p0 . The This results in the standard mathematical concept of the
task of the user mainly consists in making choices among integer numbers. Neither decimal nor integer have a direct
a set of possibilities provided by the Filtering Agent, in order counterpart in Java primitive data types.
to constrain a relation to become a function. The user is • long is derived from integer by setting the maximum
also asked to define the right operations to be performed value to be 9,223,372,036, 854,775,807 and the minimum
on parameters of m ∈ elements(l) in order to obtain a one to be -9,223,372,036,854,775,808 (both included); it
tuple of parameters suitable for the corresponding method corresponds to the long Java primitive data type.
m0 ∈ elements(l0 ). • int is derived from long by setting the maximum value
Of course there might be elements of l for which no type to be 2,147,483,647 and the minimum value to be -
safe matching into a corresponding element of l0 exist, and 2,147,483,648 (both included); it corresponds to the int
this would mean that tsa could never become a function, and Java primitive data type.
that the system has nothing left to do. The user can benefit • short is derived from int by setting the minimum admis-
from knowing tsa, but he/she has to perform the translation sible value to -32,768 and the maximum admissible value
from p to p0 by hand. to 32,767 (both included); it corresponds to the short Java
primitive data type.
Translation Agent • byte is a short ranging between -128 and 127 (both
In case a the match function has successfully been ex- included); it corresponds to the byte Java primitive data
tracted, the Translator Agent can provide its translation service type.
by taking a function match and a program p and returning a • float is patterned after the IEEE single-precision 32-
program p0 following the rules defined in Section 7 of [4]. The bit floating point type; it corresponds to the float Java
program p to migrate is given in input only to the Translation primitive data type.
Agent. The matching function match only depends on l and l0 : • double is patterned after the IEEE double-precision 64-
it can be reused for any p developed for using l which must be bit floating point type ; it corresponds to the double Java
updated for using l0 . The alternative of considering p from the primitive data type.
earliest phases of the process has been taken into consideration • boolean has the value space required to support the math-
because of some advantages it would give. In fact, knowing p ematical concept of binary-valued logic: {true, false}; it
since the beginning would allow the multiagent system to limit corresponds to the boolean Java primitive data type.
the extraction and matching activities only to those elements OWL primitive data types do not include char, which is the
of the library that are actually used by p, as well as those that only Java primitive data type with no direct correspondence.
have some dependency relation with them. This would restrict However, since char is a finite-valued type type, it may be
the search space, but would also cause a loss of generality of easily represented as an OWL class with a finite number of
the function match, which should become a matchp function instances, as a set of integers with a maximum cardinality
depending on p and might be used only for translating p and (the owl:maxCardinality built-in OWL property may be used
programs that use less elements of l than p. A program p2 to this aim), or in other straightforward ways. Instead, OWL
that uses only one more element from l w.r.t p would require primitive data types include for example string, date, time
the generation of a new matchp2 function. that correspond to some extent to the String, Date, Time
classes provided by java.lang and java.sql packages,
III. O NTOLOGY E XTRACTION AGENT respectively.
This section describes the algorithm for automatically ex- Since OWL provides no data type corresponding to void, we
tracting an OWL ontology from a Java library exploited by the assume that an OWL class named Void is defined in a names-
pace that we abbreviate with myns, and that it corresponds to • If the Java class sc extends c, then the OWL class corre-
the void type specifier in Java. sponding to c (that we name owl(c) for our convenience)
b) Namespace: Namespaces are inherited by OWL from is defined as a subclass of the OWL class corresponding
XML. XML namespaces provide a simple method for qual- to sc.
ifying element and attribute names used in XML documents • Since properties of an OWL class are inherited by its
by associating them with namespaces identified by URI refer- subclasses, the Java methods and attributes of class c are
ences. A standard initial component of an ontology includes translated into OWL properties with identifier identical
a set of XML namespace declarations that provide a means to to their name and domain owl(c). This allows them to
unambiguously interpret identifiers and make the rest of the be inherited by owl(c)’ subclasses for free. The range of
ontology presentation much more readable. a property corresponding to a Java attribute is defined
c) Class: A class defines a group of individuals that as the attribute’s type; that of a property correspond-
belong together because they share some common properties. ing to a method is a pre-defined OWL class named
The OWL class element, identified by owl:Class, is a myns:MethodF.
subclass of the RDFS class element, rdfs:Class. The
Our assumption of absence of clash names is very strong,
rationale for having a separate OWL class construct lies in
but it allows us to describe the basic ideas underlying the
the restrictions on OWL DL (and thus also on OWL Lite),
algorithm in a clear and understandable way, discarding the
which imply that not all RDFS classes are legal OWL DL
technical details raised by name clashes. The reason for this
classes.
assumption is that we translate all the elements (classes,
d) Subclass: Class hierarchies may be created by making
attributes, methods) of the class library into corresponding
one or more statements that a class is a subclass of another
elements of a unique OWL ontology. Unfortunately, an OWL
class. This can be achieved by using the rdfs:subClassOf
ontology cannot include properties with the same name, even
element defined by RDFS.
if their domain and range are different as it should happen
e) Property: Properties have originally being defined
with methods, parameters and attributes with the same name
in RDF and can be used to state relationships between
but different functionality.
individuals (object properties, owl:ObjectProperty)
In the real case, where name clashes between methods,
or from individuals to data values (data type proper-
parameters, and attributes may occur, two solutions have been
ties, owl:DatatypeProperty). Both object and data
devised.
type OWL properties are subclasses of the RDF class
rdf:Property. 1) Instead of translating the entire Java library into an
OWL ontology, each Java class c should be translated
A. From a Java library to an OWL ontology into an OWL ontology o defined within a namespace
ns created starting from c in a way that ensures its
The algorithm that we describe in this section has been
uniqueness. Methods and attributes of class c, as well
designed for working under the assumption that names of
as the methods’ parameters, should be translated into
methods and attributes of the classes in a class library are
properties of the ontology o within the namespace ns.
all different. The absence of name clashes between classes
The usage of different ontologies defined in different
is given for granted, since a class library cannot include two
namespaces should allow us to identify each element
classes with the same name. Even under the assumption that
of a Java class in a unique way, and thus to overcome
different classes with no inheritance relation among them
the problem of name clashes (using the same identifier
define different methods, a preprocessing stage must be per-
in different namespaces is, of course, admitted). The
formed on the library in order to deal with method overriding.
ontology corresponding to the Java class c should import
In fact, we cannot prevent subclasses from overriding methods
all the ontologies corresponding to translations of Java
defined in superclasses, but this leads to a violation of our
classes referenced in c, and thus a pre-processing phase
assumption on disjoint names of methods. We deal with this
should be added to the extraction algorithm. The Java
situation by just removing the overridden method from all the
library l should be translated into an ontology that just
subclasses that override it. This gives us two advantages:
imports all the ontologies corresponding to the Java
1) the assumption under which the algorithm works is classes belonging to l.
respected; The main drawback of this approach, besides a much
2) we avoid that a method m defined by class c may be more complex extraction algorithm, is that few imple-
matched to m0 , and the same method m overridden by mented matching algorithms that the Simple Ontology
a subclass of c is matched to m00 6= m0 . Matching Agents, SOMs, should interface take names-
The basic ideas underlying the extraction algorithm are: paces correctly into account.
• The Java library l corresponds to a single OWL ontol- 2) The Java library should still be translated into a single
ogy lo named after the library name and defined in a OWL ontology, but clashing names should be modified
namespace lns. during their translation in order to obtain an ontology
• Java classes belonging to l correspond to OWL classes “clash-free”.
belonging to lo; the identifier of the OWL class coincides Here, the drawback is that the modification of names
with the name of the Java class it corresponds to. would result into poorer performances of the ontology
matching algorithms. If, for example, method m in the The Ontology Matching Agent will take the user’s preferences
library l has been translated into m14 in ontology o into account for delivering the best service to each user.
because of a name clash, and method m in library l0 has In this section, we shortly review the state of the art of
been translated into m37 in ontology o0 , again because ontology matching systems and algorithms towards which
of a name clash, the confidence in the correspondence Simple Ontology Matching Agent will interface. We draw
< m ∈ o, m ∈ o0 > would turn out to be lower inspiration from [8]. Following the terminology proposed
than the confidence in the correspondence < m14 ∈ there, a correspondence between an entity e belonging to
o, m37 ∈ o0 > for most matching algorithms, because ontology o and an entity e0 belonging to ontology o0 is a 5-
of the syntactic difference between the two names. tuple < id, e, e0 , R, conf > where:
The following paragraphs describe the extraction of the • id is a unique identifier of the correspondence;
OWL elements starting from the Java library elements and • e and e0 are the entities (e.g. properties, classes, individ-
provide examples. uals) of o and o0 respectively;
• R is a relation such as “equivalence”, “more general”,
OWL elements corresponding to Java classes “disjointness”, “overlapping”, holding between the enti-
ties e and e0 .
A Java class c that extends no class corresponds to an OWL • conf is a confidence measure (typically in the [0, 1]
class c (Table I). range) holding for the correspondence between the en-
A Java class sc that extends a class c different from Object tities e and e0 ;
corresponds to an OWL class sc defined as a subclass of c
(Table II). An alignment of ontologies o and o0 is a set of correspon-
dences between entities of o and o0 , and a matching process
is a function f which takes two ontologies o and o0 , a set of
OWL elements corresponding to attributes of Java classes parameters p and a set of oracles and resources r, and returns
An attribute a of class c whose type is a basic type t with an alignment A between o and o0 .
a corresponding data type in XML corresponds to an OWL Two of the dimensions according to which matching tech-
datatype property whose ID is a, whose domain is c, and niques can be classified are the level (element vs structure) and
whose range is the XML data type that corresponds to t (Table the way input information is interpreted (syntactic vs external
III). vs semantic).
An attribute a of class c whose type is the class c0 defined in
the Java library corresponds to an OWL object property whose
ID is a, whose domain is c, and whose range is c0 (Table IV). Level: element vs structure
Element-level matching techniques compute alignments by
OWL elements corresponding to methods of Java classes analyzing entities in isolation, ignoring their relations with
other entities. Structure-level techniques compute alignments
Since we are not interested in representing the functionality
by analyzing how entities appear together in a structure.
of a method m in the ontology, we treat methods in the same
Element-level techniques include, among others:
way as attributes with the only difference that their range is
always an OWL class defined in our namespace, and named • String-based techniques, that measure the similarity of
"myns:MethodF". The domain of a method is the OWL two entities just looking at the strings (seen as mere
class representing the Java class it belongs to (Table V). sequences of characters) that label them. They include
substring distance, Jaro measure [9], n-gram distance
IV. O NTOLOGY M ATCHING AGENT [10], Levenshtein distance [11], SMOA measure [12].
• Language-based techniques, that consider entity names
The Ontology Matching Agent will coordinate Simple as words in some natural language and exploit Natural
Ontology Matching Agents, each interfacing towards some Language Processing techniques to measure their simi-
existing algorithm and/or tool (for example those mentioned larity.
at the end of this section, but others might be considered). • Constraint-based techniques, that deal with the internal
In the recent past, the second author of this paper together constraints being applied to the definitions of entities,
with other colleagues from the University of Genova designed, such as types, cardinality of attributes, and keys.
implemented and tested a FIPA compliant Ontology Agent for
Structure-level techniques include:
JADE [5] that provides Ontology Matching services to a MAS
[6]. We plan to extend such an agent by adding intelligence • Graph-based techniques that the input ontology as a
to it in the choice of the right matching algorithm (among labeled graph.
existing ones) to use, based either on work-balance issues or • Taxonomy-based techniques, that are also graph algo-
on quality of service provided, or on both. The experiments rithms which consider only the specialization relation.
described in [7] demonstrate that better results are achieved • Model-based techniques that handle the input based on
by more time-consuming algorithms. According to the user’s its semantic interpretation (e.g., model-theoretic seman-
needs, a faster algorithm might be preferred to a slower one, tics). Examples are propositional satisfiability (SAT) and
even if this might cause a degradation of the results’ quality. description logics (DL) reasoning techniques.
public class Bike
TABLE I
JAVA CLASS c THAT EXTENDS NO CLASS .
public class MountainBike
extends Bike
TABLE II
JAVA CLASS sc THAT EXTENDS CLASS c.
Attribute cadence of the class Bike:
public int cadence;
TABLE III
ATTRIBUTE WITH A BASIC TYPE .
Attribute ft of the class Bike:
public BikeFeatr ft;
TABLE IV
ATTRIBUTE WITH TYPE c.
Interpretation of input information: syntactic vs external vs ontologies specified in OWL. Given two concepts, HMatch
semantic calculates a semantic affinity value as the linear combination
Syntactic techniques interpret the input in function of its of a linguistic affinity value and a contextual affinity value.
sole structure following some clearly stated algorithm. For the linguistic affinity evaluation, HMatch relies on a the-
External techniques exploit auxiliary (external) resources of saurus of terms and terminological relationships automatically
a domain and common knowledge in order to interpret the extracted from the WordNet lexical system. The contextual
input. affinity function of HMatch provides a measure of similarity
Semantic techniques use some formal semantics (e.g., by taking into account the contextual features of the ontology
model-theoretic semantics) to interpret the input and justify concepts.
their results. In case of a semantic based matching system, a CtxMatch [18], [19] is a sequential system that translates the
further distinction between exact algorithms (that guarantee a ontology matching problem into the logical validity problem
discovery of all the possible correspondences) and approxi- and computes logical relations, such as equivalence, subsump-
mate algorithms (that tend to be incomplete) may be done. tion between concepts and properties.
The Alignment API [20] is an API and implementation
Implemented matching systems and infrastructures for expressing and sharing ontology alignments. It operates
Many implemented matching systems and algorithms exist. on ontologies implemented in OWL and uses an RDF-based
If we just consider those listed in the “Project” section of the format for expressing alignments in a uniform way. The
Ontology Matching portal, http://www.ontologymatching.org/ Alignment API offers services for storing, finding, and shar-
projects.html, we may count about thirty of them. These sys- ing alignments; piping alignment algorithms; manipulating
tems and infrastructures are very different one from another. (thresholding and hardening); generating processing output
Many of them have been carefully analyzed and compared in (transformations, axioms, rules); comparing alignments. The
[8], as well as in previous works by the same authors [13], last release, Version 3.5, dates back to October, 21th, 2008.
[14] and by other researchers [15]. AUTOMS-F [21] is a framework implemented as a Java
Just to cite some very recent systems, HMatch [16], [17] API which aims to facilitate the rapid development of tools
is an automated ontology matching system able to handle for automatic mapping of ontologies by synthesizing several
Methods setFeatr and getFeatr of the
class Bike:
public void setFeatr
(BikeFeatr newFeatr,
String newOwnerName,
int newOwnersNum)
{
...
}
public BikeFeatr getFeatr()
{
...
}
TABLE V
M ETHODS .
individual ontology mapping methods. Towards this goal, algorithms, the choice of the most suitable algorithms and
AUTOMS-F provides a highly extensible and customizable tools to be accessed by Simple Ontology Matching Agents
application programming interface. AUTOMS [22] is a case will be made.
study ontology mapping tool that has been implemented using Once all these components will be available and tests will be
the AUTOMS-F framework. performed over them, a prototype demonstrating the feasibility
Finally, automatic matching techniques that exploit “Upper of our approach will be created in JADE.
Ontologies”, namely general ontologies that deal with con-
cepts that are the same across different domains, have been
ACKNOWLEDGEMENTS
implemented and analyzed in [7].
The authors acknowledge the anonymous reviewers for their
V. C ONCLUSION AND FUTURE WORK thoughtful and constructive suggestions.
This work has been partially supported by MIUR EOS DUE
In this paper we have described a multiagent system that, - Extensible Object Systems for Dynamic and Unpredictable
once implemented, should allow a user to semi-automatically Environments, and by the CINI-FINMECCANICA Iniziativa
porting a Java program p that uses library l to a program p0 that Software project.
uses l0 in a type-safe and “meaning-safe” way. To the best of
our knowledge, no previous attempts of exploiting agents and
ontologies for facing porting and migration problems exist. R EFERENCES
We devise some similarity between our proposal and the Nat- [1] R. D. Cosmo, F. Pottier, and D. Rémy, “Subtyping recursive types
ural Programming Project, http://www.cs.cmu.edu/∼NatProg/, modulo associative commutative products,” in TLCA 2005, Proceedings,
ser. LNCS, P. Urzyczyn, Ed., vol. 3461. Springer, 2005, pp. 179–193.
working on making programming languages and environments [2] J. Palsberg and T. Zhao, “Efficient and flexible matching of recursive
easier to learn, more effective, and less error prone. The types,” in LICS 2000, Proceedings. IEEE Computer Society, 2000, pp.
report [23] suggests that AI tools such as agents, advice, and 388–398.
[3] S. Jha, J. Palsberg, and T. Zhao, “Efficient type matching,” in FOSSACS
reversible debuggers may help users convert their intentions 2002, co-located with ETAPS 2002, Proceedings, ser. LNCS, M. Nielsen
into precise programs. In this paper we do not face the and U. Engberg, Eds., vol. 2303. Springer, 2002, pp. 187–204.
general problem of supporting the user in his/her programming [4] D. Ancona and V. Mascardi, “Ontology matching for semi-automatic and
type-safe adaptation of Java programs,” DISI - University of Genova,
activities: we face the more specific problem of helping the Tech. Rep., 2008, ftp://ftp.disi.unige.it/person/AnconaD/AM1208.pdf.
user in a migration problem with respect to the Java language. [5] F. L. Bellifemine, G. Caire, and D. Greenwood, Developing Multi-Agent
Nevertheless, our exploitation of intelligent agents for sup- Systems with JADE. Wiley, 2007.
porting the user in activities related to smart programming is [6] D. Briola, A. Locoro, and V. Mascardi, “Ontology agents in FIPA-
compliant platforms: a survey and a new proposal,” in WOA’08, Pro-
coherent with the purpose of the Natural Programming Project. ceedings, M. Baldoni, M. Cossentino, F. D. Paoli, and V. Seidita, Eds.
The contribution of this paper is twofold. On the one hand, Seneca Edizioni, 2008.
we have designed the multiagent system’s architecture; on the [7] V. Mascardi, A. Locoro, and P. Rosso, “Automatic ontology matching via
upper ontologies: A systematic evaluation,” 2009, IEEE Trans. Knowl.
other hand, we have either identified existing algorithms to in- Data Eng., to appear.
tegrate in the agents when possible, or designed new ones (the [8] J. Euzenat and P. Shvaiko, Ontology Matching. Springer, 2007.
ontology extraction algorithm described in this paper and the [9] M. Jaro, “UNIMATCH: A record linkage system: User’s manual,” U.S.
Bureau of the Census, Washington (DC US), Tech. Rep., 1976.
algorithms implemented by the Filtering and the Translation [10] E. Brill, S. Dumais, and M. Banko, “An analysis of the askmsr question-
agents described in [4] are all original contributions). answering system,” in EMNLP 2002, Proceedings, 2002.
The first activity we will carry out in the very near future [11] V. I. Levenshtein, “Binary codes capable of correcting deletions, in-
sertions, and reversals,” Doklady akademii nauk SSSR, vol. 163, no. 4,
is the implementation of the algorithms that, at this stage, pp. 845–848, 1965, in Russian. English Translation in Soviet Physics
are only designed. In parallel to the implementation of these Doklady 10(8), 707-710, 1966.
[12] G. Stoilos, G. B. Stamou, and S. D. Kollias, “A string metric for ontology
alignment,” in ISWC 2005, Proceedings, ser. LNCS, Y. Gil, E. Motta,
V. R. Benjamins, and M. A. Musen, Eds., vol. 3729. Springer, 2005,
pp. 624–637.
[13] P. Shvaiko and J. Euzenat, “A survey of schema-based matching ap-
proaches,” J. Data Semantics IV, vol. 3730, pp. 146–171, 2005.
[14] P. Shvaiko, “Iterative schema-based semantic matching,” DIT - Univer-
sity of Trento, Tech. Rep. DIT-06-102, 2006, ph.D. Thesis.
[15] N. Choi, I.-Y. Song, and H. Han, “A survey on ontology mapping,”
SIGMOD Record, vol. 35, no. 3, pp. 34–41, 2006.
[16] S. Castano, A. Ferrara, and S. Montanelli, “Matching ontologies in open
networked systems: Techniques and applications,” J. Data Semantics V,
pp. 25–63, 2006.
[17] S. Castano, A. Ferrara, and G. Messa, “ISLab HMatch Results for OAEI
2006,” in OM-2006, co-located with ISWC-2006, Proceedings, 2006.
[18] P. Bouquet, B. Magnini, L. Serafini, and S. Zanobini, “A SAT-based
algorithm for context matching,” in CONTEXT 2003, Proceedings, ser.
LNCS, P. Blackburn, C. Ghidini, R. M. Turner, and F. Giunchiglia, Eds.,
vol. 2680. Springer, 2003, pp. 66–79.
[19] P. Bouquet, L. Serafini, S. Zanobini, and S. Sceffer, “Bootstrapping
semantics on the web: meaning elicitation from schemas,” in WWW
2006, Proceedings, L. Carr, D. D. Roure, A. Iyengar, C. A. Goble, and
M. Dahlin, Eds. ACM, 2006, pp. 505–512.
[20] J. Euzenat and et al., “Alignment API and Alignment Server,” 2008.
[Online]. Available: http://alignapi.gforge.inria.fr/
[21] A. Valarakos, V. Spiliopoulos, K. Kotis, and G. Vouros, “AUTOMS-F: A
java framework for synthesizing ontology mapping methods,” in KOST
’07, Proceedings, 2007.
[22] K. Kotis, A. G. Valarakos, and G. A. Vouros, “AUTOMS: Automated
ontology mapping through synthesis of methods,” in OM-2006, co-
located with ISWC-2006, Proceedings, ser. CEUR Workshop Proceed-
ings, P. Shvaiko, J. Euzenat, N. F. Noy, H. Stuckenschmidt, V. R.
Benjamins, and M. Uschold, Eds., vol. 225. CEUR-WS.org, 2006.
[23] H. Goodell, S. Kuhn, D. Maulsby, and C. Traynor, “End user
programming/informal programming,” SIGCHI Bull., vol. 31, no. 4, pp.
17–21, 1999. [Online]. Available: http://www.cs.uml.edu/∼hgoodell/
EndUser/blend/report.html