The FAST gadget development environment allows users to graphically compose intelligent, i.e., semantically annotated gadgets from prede ned building blocks and deploy them on various mashup platforms, thus enabling the interconnection of di erent systems and services. In an environment where di erent parties use di erent ontologies to describe such building blocks, ontology matching is crucial. This paper discusses rst steps in our e ort to integrate ontology matching in an end-useroriented environment such as FAST. We evaluate a number of tools and approaches for solving di erent levels of complexity in ontology matching and de ne the direction of integrating ontology matching into FAST.
FAST (Fast and Advanced Storyboard Tools) [1] is a visual programming platform allowing business users to build enterprise-class mashups, employing various underlying services and generating new ones. Resources in FAST are described semantically using di erent ontologies and vocabularies, and can therefore be combined to what we can call \intelligent gadgets". These ontologies come from di erent parties, but will sometimes cover the same domain, making ontology matching necessary. The paper reports on early steps on how to integrate existing ontology matching approaches into an end-user-targeted tool such as the FAST platform. The focus of the paper is not on new methods and algorithms for ontology matching, but rather a survey and application of existing ones to our use case of ontology-matching for end-users. We will present automated solutions for simple cases as well as identify more problematic cases which require manual work, in which we want to support the ontology engineer.
In the remainder of this section we give an introduction to the FAST project, and a brief overview of ontology matching. In Section 2 we detail the requirements for ontology matching in the FAST environment. Section 3 describes the alignment tool used and the rationale behind our choice. In Section 4 we describe a problem scenario that we want to give a solution for in FAST, which is the basis of this work, and in Section 5 we present the ontologies used for the di erent web services involved in the scenario. Finally, in Section 6 we present the testing procedure and the results, based on which we draw the conclusions in Section 7 and de ne future directions. 1.1
The main goal of the FAST Project [1] is to develop a web-based visual programming environment allowing users to build enterprise-class mashups (see Fig. 1 for a screenshot exemplifying the composition of so-called screens to build such a gadget). The motivation behind FAST is to allow non-technical users to be involved in the development process of software applications based on their ad-hoc needs. The project employs the paradigm of Enterprise Mashups [2], in which it employs a user-centric approach.
The relevant components of the enterprise mashup paradigm are resources, gadgets and mashups. Resources, which are in the focus of this paper, represent all building-blocks of gadgets (such as the screens in Fig. 1). Gadgets provide a graphical interface and interaction mechanisms abstracting from the complexity of the underlying backend. Finally, though out of the scope of FAST, end-users combine and con gure the provided gadgets to create mashups. 1.2
FAST uses ontologies to conceptualise the underlying resources used by the di erent components. Ontologies embody the fundamental vehicle for conceptualising data on semantic systems; they describe the context and semantic background of data that should be known to all agents using it [3]. However, di erent ontologies are often used to describe the same domain or cover the same scenario. This is also true for FAST, where gadget building blocks can originate from di erent providers, who might use di erent ontologies to describe them. To ensure interoperability, the task of ontology matching is therefore critical in FAST.
Given two ontologies O and O0 that need to be mapped to each other, we adopt the de nition given in [4]: an ontology mapping element is a 5-tuple < id; e; e0; n; R >, where id is a unique identi er, identifying the mapping element, e and e0 are entities (formulas, terms, classes, individuals) of the rst and second ontology, respectively, n is a con dence measure holding the correspondence value between e and e0, R is the correspondence relation holding between e and e0 (e.g., equivalence (=), more general(w) or disjointness(?)). The alignment operation determines the mapping M 0 for a pair of ontologies O and O0. The alignment process can be extended by parameters, such as an input mapping, weights and thresholds and other external resources (dictionaries, thesauri, etc.). Di erent levels of mappings are de ned:
(a) A level 0 mapping [5] is a set of the above mapping elements, when the entities are discreet (de ned by URIs). E.g., consider the ontology O1 with a class Person, and another ontology O2 with a class Human. For this case a matching algorithm could return the mapping element < id11; P erson; Human; 0:67; =>, meaning that the Person class from the rst ontology is found to be equivalent to the Human class in the second one with a con dence measure of 0.67. (b) A level 1 mapping is a slight re nement of level 0, replacing pairs of elements with pairs of sets of elements. (c) A level 2 mapping can be more complex and de nes correspondences in rst order logic. It uses the ontology mapping language described in [6]. It can describe complex correspondences, such as the one detailed in Section 6.2. 2
The gadget life cycle in FAST has several phases and roles associated, as detailed in [1]. Here, we list the ones relevant for the ontology matching tasks, in decreasing order of the measure in which knowledge about ontologies is required. Note that several roles can be played by the same actor. (i) The ontology engineer creates the ontologies used to annotate services and data. This role also includes the process of ontology matching, either automated or manually, determining if the alignment is feasible and creating so-called matching operator building blocks, which are basic elements of the FAST screen building. The resource developer then uses these ontologies to annotate resources created in FAST. (ii) Ontology matching is needed by the screen developer at the design-time of a screen (a visual building block of a gadget). Screen developers have a dedicated UI component for building screens, in which they can use the matching operators to combine components annotated with di erent ontologies. No actual matching needs to be performed in this phase, but rather the possibility of matching needs to be determined (i.e., can two screens A and B be combined?). (iii) The gadget developer combines screens to screen- ows and gadgets, and only uses ontology matching implicitly. (iv) The end-user uses the nal deployed gadget at run-time, but is unaware of the underlying resources and ontologies or the matching process. Only at run-time the actual mapping of instance data has to be performed. In this paper, we mainly consider the rst two cases (i.e. ontology engineering and screen development). 3
An ontology mapping is a declarative speci cation of the semantic overlap
between two ontologies [7]. It is the result of the ontology alignment process. This
mapping is represented as a set of axioms in a mapping language. The mapping
process has three main phases: (
To accomplish this we need a tool to assist the ontology engineer in the ontology mapping process. Based on the description given in Sect. 2 we identify the following requirements for an alignment tool, that we will take as the basis for an ontology matching component in FAST: (i) All three phases of the process need to be accessible. (ii) Matching of OWL and RDFS ontologies must be supported in the FAST project. (iii) The tool should be as independent as possible, performing the alignment process with little or no user interference. This is an important requirement, since FAST is end-user oriented. (iv) The tool needs to be open source, allowing it to be integrated into the free and open FAST platform. (v) The code should be suitable for porting to other languages (in particular JavaScript), allowing it to be integrated into the FAST gadget run-time. (vi) It should be well documented.
Based on these requirements, we compared three di erent tools. MAFRA [8] supports an interactive and incremental process of ontology mapping. It provides an explicit notion of semantic bridges. This representation is serialisable, portable and independent from the mapped languages. The bridges, however, have been designed to be used within the MAFRA system, and the alignment process needs to be done through the provided GUI. RDFT [9] is a small language originally designed to map between XML and RDF. The results are mappings represented in DAML+OIL, that can be executed in a transformation process. No hints are given to add alignment methods or extending the format and the tool does not longer seem to be available. Alignment API [5] is the tool best matching our requirements, satisfying all the desired conditions. It is still under active development, provides an API and its implementation, is open source (GPLv2 or above) and written in Java, providing an easy way to embed it into other programs. Alignment API can be extended by other representations and matching algorithms, it can be invoked through the command line interface (thus working without user interference) or one of the two available GUI implementations, or it can be exposed as an HTTP server. The tool allows for testing di erent alignment methods and can generate evaluation results based on a reference alignment. Alignment API can generate the mapping results in XSLT, therefore providing an easy way to integrate them into other systems. 4
In our evaluation scenario, which is taken from the e-commerce domain, a user needs to build a gadget which combines data from major e-commerce services, allowing to aggregate item lists from all of them in a combined interface. As examples in our scenario, we consider the two most popular online shopping websites1, Amazon and eBay, along with the BestBuy site. The latter is an interesting case, because it exposes its data in RDF using the GoodRelations (GR) ontology [10], which has recently gained a lot of popularity. It is therefore one of the rst major e-commerce sites to provide semantic metadata. 1 http://alexa.com/topsites/category/Top/Shopping, checked 01/11/2009 the eBay ontologies were developed for simulation purposes as simpli ed versions of what would be used in the real-life scenarios. They were designed to showcase particular features of ontology mapping in our scenario.
GoodRelations: This ontology is aimed at annotating so-called \o erings" on the Web, which can be products or services. The ontology features support for ranges of units, measurements, currencies, shipping and payments, common business functions (sell, lease, repair, etc.) and international standards (ISO 4217 or UNSPSC) and codes (e.g., EAN or UPC) in the eld. The main class is Offering, which represents an announcement by a BusinessEntity to provide a ProductOrService with a given BusinessFunction. It may be constrained in terms of eligible business partner, countries, quantities, and other properties. It is also described by a given PriceSpecification. The super-class for all classes describing products or service types is ProductOrService. This top-level concept has sub-classes representing actual product instances, product models and dummy product placeholders. A product is described by its title and description, manufacturer, make and model, etc.
Amazon Ontology: We have created a small Amazon ontology based on a subset
of the datatypes supported by the web service exposed by Amazon to third-party
agents. The ontology describes Items based on the ItemAttributes description
given in the Amazon Product Advertising API documentation2. The ontology
features three classes for describing a product. Example instance data is given in
List. 1.1. (
amzn : hasLegalName "Canon" . : P r i c e 7 5 9 0 6 4 5 1 a amzn : L i s t P r i c e ; amzn : hasAmount " 575.55 " ; amzn : hasCurrencyCode "GBP" .
eBay Ontology: The eBay ontology was created based on the eBay Shopping
API3 and is supposed to annotate data retrieved through the web service
described by the API. The ontology features three basic classes, (
We present the approach an ontology engineer has to take to discover and represent ontology mappings, and a means to exploit them after the they have been discovered and appropriately represented.
There is a major paradigm di erence between the GoodRelations ontology and the other two ontologies (see Sect. 6.2 for details). After some initial testing, we concluded that automatic mapping from GR to A/E using the string-based methods employed by the Alignment API tool was not feasible. Therefore, the following sections report on automatic mapping for the A{E pair | which are similar enough to be suitable for level 0 mapping |, and manual mapping for the GR{A/E pairs. 6.1
For automatic mapping of level 0 mappings, we used a simple string
distancebased algorithm provided by Alignment API [5], which computes the string
distance between the names of the entities to nd correspondences between them.
Four methods have been used for computing the distance: (
The alignment description derived from these methods is given based on a simple vocabulary, containing a pair of ontologies and a set of correspondences, which express relations between entities of the two ontologies. We used the level 0 mapping representation for representing simple mappings, which map discrete entities of the two ontologies. Thus the representation of the correspondences is given with the ve elements described (with the id being optional), as shown in List. 1.2. Similar mappings were were also used for more complex, manuallycreated representations (level 2), as detailed in Sect. 6.2.
Testing Procedure For the Amazon{eBay pair we set up a reference alignment,
against which the results are evaluated. We then ran the matching process for all
for methods: (
Results The results of automatically aligning the Amazon and eBay ontologies
were quite favourable. As shown in Tab. 1, we captured the four main parameters
used in information retrieval, as described in [12]. These four parameters are
used for evaluating the performance of the alignment methods: (
The rst row (reference) shows the reference alignment, which, naturally, has both perfect precision and recall. We can observe what intuition has predicted, namely that pure string equality (equality) is far too simple and irrelevant, by only taking identical labels. By using string distances and giving certain thresholds (Levenshtein and SMOA), we can see that the results are much less precise, but have a better recall, since this allows for entities having similar names to be discovered, at the expense of having quite a few incorrect results (lower precision); the thresholds allow for low-scored cases to be eliminated, although this results in the exclusion of some correct correspondences. The last column (JWNL) contains the results of the Wordnet-enabled method, which shows quite an improvement (precision of 0.67 and a recall of 0.75), due to the lexical analysis, which performs a much more relevant comparison of strings, giving a high number of correct results. The precision of the JWNL alignment shows only a tiny drop below the recall value, meaning that the number of incorrect correspondences discovered is small, and the main source of error is from the number of correspondences not discovered.
We can deduce that the results provided are satisfactory, even though the methods used were simple, string-based ones, and the process was completely automated without any user input. We are therefore con dent that through some user assistance or an initial input alignment the tool can achieve 100% correct results. 6.2
The GoodRelations ontology employs a unique paradigm, di erent from the paradigms of Amazon and eBay. In GR everything is centred around an instance of Offering and a graph of other instances attached to it, whereas for Amazon (and similarly for eBay), the main class is Item, which holds all relevant properties. In principle, Item would correspond to ProductOrService in GoodRelations, but the properties of the Item class are re ected as properties of many di erent classes in GR.
Though the infeasibility of automating this alignment became obvious, we have represented the alignment in the mapping language supported by the tool, as a level 2 mapping (described in Sect. 1.2). This mapping description can later be used by the run-time gadget code. List. 1.3 shows an example mapping between two properties of the two ontologies, specifying that the relationship is Equivalence with a certainty degree of 1.0. This fragment does not show, but assumes the equivalence correspondence between the classes Item and Offering, which is a trivial level 0 mapping. This mapping speci es the relation 8v; z; hasEAN (v; z) =) 9x; y; includesObject(v; x)^
typeOf Good(x; y) ^ hasEAN U CC 13(y; z); meaning that the hasEAN property of v in the Amazon ontology corresponds to the hasEAN UCC 13 property of the typeOfGood of the includesObject of v in GoodRelations. The domains and ranges of the properties are inferred, thus it is deduced, that in Amazon v is of type Item and z is int, and in GoodRelations v, x, y and z are instances of the classes Offering, TypeAndQuantityNode, ProductOrService and int, respectively.
Using this representation, complex correspondences can be modelled, using rst order logic constructs. 7
The goal of this paper was to explore ontology matching in an environment such as the FAST platform, where building blocks described with di erent on<l e v e l 2 m a p p i n g > a a l i g n : C e l l ; a l i g n : e n t i t y 1 amzn : hasEAN ; a l i g n : e n t i t y 2 [ a a l i g n : P r o p e r t y ; a l i g n : f i r s t g r : i n c l u d e s O b j e c t ; a l i g n : n e x t g r : hasEAN UCC 13 ,
g r : typeOfGood ] ; a l i g n : measure " 1 . 0 "^^ xsd : f l o a t ; a l i g n : r e l a t i o n " E q u i v a l e n c e " . amzn : hasEAN a a l i g n : P r o p e r t y . g r : hasEAN UCC 13 a a l i g n : P r o p e r t y . g r : i n c l u d e s O b j e c t a a l i g n : R e l a t i o n . g r : typeOfGood a a l i g n : R e l a t i o n .
Listing 1.3. Fragment of the Amazon{GoodRelations mapping tologies need to be integrated by end users. To this end, we have identi ed which roles in the FAST gadget development lifecycle need to be considered, and which kinds of ontology matching problems they might face. Based on an example scenario from the e-commerce domain, which includes real-world ontologies such as GoodRelations, we have evaluated di erent existing algorithms for level 0 matching problems. A wordnet-based approach for string matching performed best, giving results suitable for semi-automatic level 0 matching, thus enabling non-expert end users to perform such tasks in FAST. For more complex level 2 matching problems, manual de nition of matching rules is still necessary. Additionally, we have evaluated three ontology matching tools based on the requirements given by the FAST platform, and established that the Alignment API tool suits our needs best. We use Alignment API both for the (semi-)automatic generation of level 0 matching rules, as well as for the syntactic representation of manually generated level 2 problems. Based on this format, ontology matching rules of all levels can be represented and executed in all relevant components of the FAST architecture.
As future work, we need to evaluate existing or develop new methods to aid users in complex ontology matching problems (level 2). Additionally, we will integrate ontology matching into the running FAST platform, and evaluate its performance and usability there.
The work presented in this paper has been funded in part by Science Foundation Ireland under Grant No. SFI/08/CE/I1380 (L on-2) and (in part) by the European project FAST No. FP7-ICT-2007-1.2 216048.