A Semantic Matching Approach for Mediating Heterogeneous Sources

A Semantic Matching Approach for MediatingHeterogeneous SourcesMichel Schneider 1,2, Lotfi Bejaoui1, Guillaume Bertin21 Cemagref, 24 Avenue des Landais, 63172 Aubière Cedex, France2 LIMOS, Complexe des Cézeaux, 63173 Aubière Cedex, France{michel.schneider, lotfi.bejaoui}@cemagref.fr, bertin.guillaume2@Abstract.Approaches to make multiple sources interoperable were essentiallyinvestigated when one are able to resolve a priori the heterogeneity problems.This requires that a global schema must be elaborated or that mappings betweenlocal schemas must be established before any query can be posed. The object ofthis paper is to study to what extend a mediation approach can be envisagedwhen none of these features are a priori available. Our solution consists inmatching a query with each of the local schema. We designed a first prototypewhich showed that the approach could be efficient. We propose in this paper anew more sophisticated prototype. A friendlier query language is available. Thedetection of matching is more successful. This kind of system can be installedon super-nodes in P2P networks in order to facilitate accesses to data by theirsemantics. It can thus contribute to the pervasive computing paradigm.Keywords: Semantic Matching, Heterogeneous Sources, Mediation, XMLSources, OWL Representation1 IntroductionThe interoperability of multiple heterogeneous sources represents an important challenge considering the proliferation of numerous information sources both in private networks (intranet) and in public networks (internet). Heterogeneity is the consequence of the autonomy: sources are designed, implemented and used independently. Heterogeneity can appear for different reasons: different types of data, different representations of data, different management software packages.One interoperability approach which has been studied for several years is based on mediation [23], [5]. A mediator analyzes the query of a user, breaks it down into sub-queries for the various sources and re-assembles the results of sub-queries to present them in a homogeneous way. The majority of mediation systems operate in a closed world where one knows a priori the sources to make interoperable. There are several advantages to this. First it is possible to build an integrated schema which constitutes a reference frame for the users to formulate their queries. Then it is possible to supply the mediator with various informations which are necessary for the interoperability and particularly to resolve heterogeneity problems. The different kinds of heterogeneity to be resolved are now clearly identified: heterogeneity of concepts orintentional semantic heterogeneity; heterogeneity of data structures or structural semantic heterogeneity; heterogeneity of values or extensional semantic heterogeneity. Different solutions have been studied and experimented on to solve these problems. For example we can cite the work of [7] and [9]. From these initial investigations, very numerous works intervened to propose automatic approaches of integration of schemas. An approach was particularly investigated: the mapping of schemas. It led to the elaboration of several systems such as SEMINT [12], DIKE [18], COMA [3], CUPID [13]. One will find analyses and comparisons of such systems in [19] or [6] or [16]. The practical aspects of the application of such systems are discussed in [1]. The role of ontologies was also investigated. In [2] and [15], the interest of ontologies for the semantic interoperability is underlined. Several approaches of integration of information based on ontologies were suggested. One will find a synthesis of it in [22]. It is necessary also to quote the work of [10] suggesting a logical frame for the integration of data. In all these works, the objective is to build a global schema which integrates all the local schemas.When one operates in an evolutionary world where sources can evolve all the time, the elaboration of a global schema is a difficult task. It would be necessary to be able to reconstruct the integrated schema each time a new source is considered or each time an actual source makes a number of changes. To overcome these drawbacks an another approach has also been investigated: the query based approach. In this approach no global schema is required. The integration problems are solved during querying. Three main systems can be classified in this category: Information Manifold system, InfoSleuth system and Singapore system. Information Manifold [11] uses sources capabilities to determine how a query can be solved. InfoSleuth [17] is an agent-based system using ontologies for performing information gathering and analysis tasks. Singapore system 4] proposes an object language to formulate exact or fuzzy queries.Our approach can also be considered as query-oriented. It is based on a semantic matching between the user query and each source schema. The user formulates its query by using its knowledge of the domain. Only the sources whose schemas match with the query are considered. The user query is rewritten for each of these sources according to its information capacity. These sources are then interrogated. Results are formatted and integrated. This approach offers several advantages. The rewriting process is simpler. A new source can be inserted at any time; the only obligation is to provide an adequate representation of this source. We have implemented a first prototype [21] to validate this approach.The second prototype which we present in this paper possesses various advantages on the first. The query language is more intuitive and so is more convenient for a non specialized user. The matching between a query and a source is more successful. The system is capable of identifying itself the potential sources available on the Web.We will consider in this paper only XML sources, but our approach can be adapted to deal with any kind of sources.The paper is organised as follows. In section 2 we explain the principle of our approach. Section 3 describes the architecture and the working of the system. Section 4 is devoted to the OWL representation of sources. In section 5 we explain the main features of our matching algorithm. Section 6 is devoted to some experiments with thesecond version of our prototype. Section 7 presents some others features and section 8 presents a number of conclusions and perspectives.2 Principle of the ApproachOur approach does not use a global schema or some predefined mappings. The user thus formulates his query by using his implicit knowledge of the domain or by making an explicit reference to an ontology of the domain.The syntax of our query language is inspired by that of SQL. The query is cut in three clauses with the reserved words Select, From and Where. The "Select" clause defines the searched elements and the "Where" clause specifies the properties which have to verify these elements. The "From" clause is not indispensable because the user does not know the structures in which elements must be looked for. It is the system which has the task to localize these structures. Nevertheless it is necessary in certain situations for introducing alias of elements. The "Where" clause contains the conditions. We need two types of conditions: "link conditions" allowing to specify the existence of links between elements of the query, and "valuation conditions" allowing to impose values on certain elements of the query. For example suppose that a user looks for the name of the customers living in the same region as a supplier having a name “easymarket”. He has to specify in the query that name is linked to customer, that name is linked to supplier, that region is linked to customer, that region is linked to supplier. In our query language this query is specified as:Q1 : Select a()namefrom customer a, supplier bwhere a()region=b()region and b()name=”easymarket”We use the double symbol () to specify a link condition between two elements.The alias in the "From" clause have a precise signification. For example using the alias a for customer imposes that it is the same instance of a that is connected with name in a()name and with region in a()region. So query Q1 can be paraphrased as follows : search for an instance ain of customer and an instance bin of supplier such that ain is connected to an instance of name and an instance rin1 of region, bin is connected to an instance of name whose value is "easymarket" and an instance rin2 of region, the values of rin1 and rin2 are equal.Fig. 1. : XML trees of two sourcesA correspondence (matching) is established with a source if each term of the query has a correspondent in the source and if each link is present in the source. A term has a correspondent if it exists in the source the same term or a synonym or a hyponym. Synonym and hyponym are determined by scanning a domain ontology. A link a()b is present in the source if it exists a semantic connection between the correspondents of a and b. We will explain further how this connection is detected.We will illustrate how the matching can work with the two XML sources of figure 1. It is straightforward to infer that the query Q1 matches with the first source since the supplier element and the customer element are both connected to an element the name of which is region. A matching for the second source cannot be inferred so immediately. First the matcher must discover that buyer is a hyponym of customer. Then it must found the connection of buyer and supplier with the shared element region. Supplier is not connected to a name element but since supplier is a leaf element it can suppose that its value represents its name. So this second source matches also with the query since it respects the semantics of the query.The rewritings of the query in the user language for the two sources are respectively:Select a()namefrom customer a, supplier bwhere a()region=b()region and b()name=”easymarket”(same as the initial specification)Select a()namefrom buyer a, supplier bwhere a()region=b()region and b=”easymarket”The system proposes all the rewritings to the user. The user can then ask the execution of some of them. The system has to rewrite each one in the source language.Two other points must be mentioned about our query language.- Since the user does not know the structure of the data sources, it is not possible for him to indicate that a term corresponds to an element or to an attribute. So the system will have to look both for elements and for attributes when searching a correspondence.- No difference is made in the query user between lower case and upper case letters. The system will make sure the exact writing of a term is retrieved for the rewriting of the query.Presently we do not handle the problem of the semantics of a link condition. For example in a source it can exist a link between employee and department which means that the employee works in the department and in another source a link which means that the employee manages the department. The specification employee()department in our query language does not make distinction between the two situations. We plan to handle this problem by allowing the user to introduce a verb to specify the semantics of the link. So the specification employee(manage)department allows to look for only the links of which meaning is manage. Note that the matching can be solved only if the sources are suitably annotated.3 Architecture and Working of the SystemThe matcher is the central element of the system (Figure 2). It receives the user query, and has the task to determine if this query can be applied to a data source. To achieve this processing, it possesses a representation of each data source in a common formalism (we propose OWL to support this formalism, cf. section 4). It must search for a correspondence between the query and each source by taking into account the terms and the structure of the query. A source can answer a query, if the terms of the query correspond to those of the source and if the linksof the query corresponds to that of the source. Correspondences between terms of the query and terms of sources descriptions are established by using a domain ontology.Fig. 2. : The architecture of the systemThe working of our system comprises three phases.In the first phase the system initializes the connection with the ontology and the OWL descriptions of the sources. The system is then ready to handle queries.In the second phase, when the system receives a query, it first interrogates the ontology to retrieve the synonyms and the hyponyms of the terms of the query. It then initiates the operation of matching for each of the sources. Several rewriting possibilities can be proposed on one or several sources.The third phase triggers the execution of one or several of these rewritings on the corresponding sources. Execution can be triggered automatically or by the user. The user can choice a rewriting to be executed on the basis of the terms and the links included in this rewriting. An execution necessitates a new step of rewriting in the language of the source (XML, relational, …).4 OWL Representation of the SourcesPresently we are working only with XML sources. To make the matching, the system could directly work on the DTD or on the XML schema of the sources. We preferred to describe every source in OWL for various reasons. At first, as we want to operate with several types of sources, the matching will be implemented with a single kind of description and will be so independent from the types of the sources. Then it is possible to take advantage of OWL features to implement the matching. Finally we foresee improved versions of the matcher, in particular by placing semantic annotations in the description of sources. The management of these annotations will be made more rationally with an OWL representation.We elaborated an algorithm with which a DTD can be mapped into an OWL representation. This mapping is bijective: from the OWL representation, it is possible to regenerate the DTD. In the following we give the principles of the mapping.The main idea is to represent every element of the DTD by an OWL class. Every father-son link between two elements is then represented by an OWL property. An attribute is also represented by a property. When a father element has only a single son element, the cardinality of this son is represented by creating a restriction on the property connecting the two elements. When the father element is a complex element, we add an intermediate class to be able to express correctly all the cardinalities.Agreements for the names of classes and properties are as following. The class representing an element will be named with the name of the element. For an intermediate class (associated to a complex element), the name of the class willcontain the names of elements with their separator, all in brackets. When this name is long, an entity can be used. A property between two classes will carry the two names separated by a point. For attributes, the symbol '@' is used to separate the name of the class and the name of the attribute.As an example let us consider the element ORDER defined as follows:<!ELEMENT ORDER(CUSTOMER, STATUS, PRODUCT+)>In order to obtain its OWL representation, a class ORDER is created and also an intermediate class the name of which is (CUSTOMER, STATUS, PRODUCT+). For clearer under-standing, the entity &complexe1 is introduced to replace this name in the OWL file. Then a property connecting ORDER with the complex class is created, and the cardinality in the class ORDER is restricted. In the definition of the complex class the limitations of cardinalities are introduced for each of the elements. For CUSTOMER and STATUS, the cardinality is forced to be 1. Then properties are created to connect the complex class with each of the classes CUSTOMER, STATUS, and PRODUCT (figure 3).Using the same principles, it is possible to design an algorithm which maps a relational schema into an OWL representation. So our approach can be extended to deal also with relational sources.5 Matching AlgorithmThe first step of the matching consists in extracting from the ontology synonyms and hyponyms (by possibly limiting the level of these last ones) for each of the terms of the query. A source is a candidate if it contains for every term of the request a synonym or a hyponym. Sources which are not candidates are definitively discarded. This step does not put particular difficulty.The second step of the matching consists in determining if every link condition of the query is verified in each of the candidate sources. We then say that such a source matches with the query.Let a()b be a link condition of the query and let a' and b ' be correspondents (synonyms or hyponyms) for a and b existing in the source S.First matching rule: If in source S, a' and b ' are directly connected (i.e. they are linked by a property in the OWL file in the direct direction or in the inverse direction), then S satisfies the link condition.Example: Let us consider again the query Q1 of section 2 which looks for the name of the customers living in the same region as a supplier having a name “easymarket”.Q1 : Select a()namefrom customer a, supplier bwhere a()region=b()region and b()name=”easymarket”Each of the link conditions is verified for each of the two sources of figure 2. So, these two sources match with the query.But this first rule does not cover all the situations where one can find a matching for a link condition. Let us consider for example the query Q2 and the source of figure 4.Q2 : Select a()name from customer awhere a()city="Aubière"The link condition a()city is verified because buyer is a correspondent of customer, urban-center is a correspondent of city and these two correspondents are not directly connected but by an intermediate node which does not change the meaning of the connection (address being a hypernym of urban-center). One can make the same analysis with the link a()name. So this source matches with query Q2.Fig. 4. : Example of a source which matches with query Q2This induces us to propose another matching rule for a link condition.Second matching rule : If in source S, a' and b' are indirectly connected (i.e. they are linked by several sequential properties in the OWL file in the direct direction or in the inverse direction), then S satisfies the link condition of the query if each intermediate class is a synonym or a hypernym or a hyponym of the previous class or the next class.We give below a description of the matching algorithm.AlgorithmResources : OWL descriptions of a set T of sources; an ontology of the domain Input : a query QOuput : the set of matching queries for Q1- For each term of Q create the list of correspondents with the term, its synonyms and its hyponyms at level < k; let L be the set of lists so obtained.2- S:= set of sources of T which have in their OWL description at least one member of each list of L.3- For each source of S3.1 - Generate the different combinations C for associating a correspondent to each term of the source;3.2 - For each combination of CIf it exists a link in the source for each link in Q (test by using the matching rules) Then generate a new matching query by replacing each term in Q by its correspondent and by prefixing each attribute by the symbol @.The overall complexity of this algorithm is linear with the number of sources. For a given source the complexity is linear with the number of combinations generated instage 3.1. This number depends of the parameter k (exploration depth in the ontology for hyponyms). For our experiments (section 6), we have chosen k=3.Note that a matching query for a source must be rewritten in the language of this source. In our case, each matching query is rewritten in XQUERY. We do not detail this rewriting process. To construct the various paths of the FOR WHERE RETURN clauses, one starts from the matching query and one organizes its terms into a hierarchy. The FOR clause contains the definition of the paths which allow to reach from the root of the XML document the highest terms previously defined. The paths of the WHERE clause integrate the link conditions and the valuation conditions. The RETURN clause contains the searched elements, i.e. those associated to the SELECT clause of the matching query.6 Prototype and ExperimentsThe prototype which we built implements the architecture presented in figure 2. We incorporated the tool SAXON-B [20] to access the OWL representations. We used WORDNET [14] as the domain ontology. Since WORDNET is in fact a general ontology, we shall use sources for our experiments which do not contain highly specialized terms. WORDNET is thus used only to provide synonyms and hyponyms of terms and to control that a succession of terms along a link is acceptable. Access to WORDNET is made through the JAVA API Java WordNet Library [8]. The body of the matcher is written in JAVA.Our experiments were conducted on six sources A, B, C, D, E, F containing data on sales of products. Sources contained from 8 to 14 elements. Every element had on average two attributes. They were built manually. OWL files were generated automatically by our transformation algorithm. We submitted ten different queries to the matcher. To save space we give only the results obtained on sources A and B for the first two queries. Extracts of the schemas of sources A and B are given in figures 5 and 6.Fig. 5. : Partial XML tree of source AFig. 6. : Partial XML tree of source BQuery 1 : Names of the customers which live in "Aubière" and which have "Castorama" among their suppliers.User query:SELECT a()name FROM customer a, supplier bWHERE a()b AND a()city="Aubière" ANDb()name="Castorama"Matching query n° 1 for source A provided by the matcher:SELECT a()@name FROM client a, supplier bWHERE a()b AND a()address()@city="Aubière" ANDb()name="Castorama"Rewriting n° 1 for source A provided by the matcher:FOR $a IN sales/clientWHERE $a/address/@city="Aubière" AND$a/supplier/name="Castorama"RETURN {$a/@name}For this query the matcher proposes a unique matching for source A. It uses the term customer as synonym of client. We observed that attributes are well detected and are marked with symbol @ in the matching query. No matching is proposed for source B.Query 2 : Names of the products of the brand "Siemens".User query:SELECT a()name FROM product a, manufacturer bWHERE a()b AND b="Siemens"Matching query n°1 for source A provided by the matcher:SELECT a()@name FROM product a, producer bWHERE a()b AND b="Siemens"Matching query n°2 for source B provided by the matcher:SELECT a()@name FROM product a, manufacturer bWHERE a()b AND b="Siemens"Rewriting n°1 for source A provided by the matcher:FOR $a IN sales/client/productWHERE $a/producer="Siemens"RETURN {$a/@name}Rewriting n°2 for source B provided by the matcher:FOR $a IN sales/productWHERE $a/manufacturer/@name="Siemens"RETURN {$a/@name}In source A, the term producer acts as a synonym of manufacturer. It is a leaf element and is used for the valuation condition. In source B, manufacturer has an attribute name which is used to specify the condition. In both cases, the matcher provides the correct rewriting.For the studied queries the performances of the matcher are good or very good. Lacks in the matching occur when ambiguous words are used in the queries or in the sources. Our matcher does not consider in the immediate the sense of words. Improvements in this direction are so envisaged.7 Other FeaturesTo increase the efficiency of the system it is interesting to be able to equip it with the possibility of automatically incorporating new data sources. We have implemented a module in our prototype to try this possibility. The administrator of the system can describe a domain of application by keywords and ask the system, by using a search engine, to look for XML sources (and their DTD) compatible with the keywords. These sources after validation by the administrator are then incorporated automatically into the system (by translation of the DTD into OWL and by insertion in the directory of sources to be used for the matching). This feature appears very efficient.By leading these experiments we noticed that numerous tags, in XML documents coming from the Web, contained abbreviations which were unknowns from the ontology (WORDNET). For example one often sees terms such as "lastdate" or "pubdate". It is possible with WORDNET to declare these abbreviations as synonyms of existing terms and to make them so accessible by the matcher. We tested this possibility and it appears efficient.8 Conclusion and PerspectivesThrough the results obtained, it appears that our system is able to find data from an intuition of the user, intuition expressed through an implicit vision of the domain compatible with the ontology.The main advantage of our approach is its robustness with regard to the evolution of sources. When a new source is inserted, it is sufficient to elaborate its OWL representation so that it can be exploited by the system. When a source evolves, it is sufficient to reshape its OWL representation.The main limitations come from the fact that our system does not actually handle sense of terms and sense of link conditions. These two points are strictly connected. To determine the most adequate sense of a term during a matching it is necessary toknow the context in which the user takes place and this context could be be determine through the links.Our system was designed to handle this problem. By allowing the user in his query to supply the semantics of a link condition, the matcher will get back useful information to characterize the user context. To improve the matching, the OWL representation of sources can be fitted out to memorize annotations on the sense of terms (at the level of the corresponding classes) and on the sense of links (at the level of properties). The main problem is that of the installation of these annotations in sources.These annotations can be installed manually by the administrator of each source. This solution is now recommended by many experts. We investigate another solution which consists to permit the system to provide some of these annotations during its working. It appears possible to seek the opinion of the user when the results of a query are displayed and to infer so some semantic features of the corresponding source.We think that these improvements could result in an efficient system.The system can be extended to deal with other types of sources (relational, object).We are also engaged in another improvement of our prototype in order to allow the join of results coming from different sources. In that case a query is rewritten in several sub-queries, each sub-queries being relative to a different source. Our matching algorithm can be adapted for this more general situation. It is necessary to verify a link condition by using information coming from different sources.Another important point concerns the performances of our matching algorithm. Without join between sources (as in this version of our prototype), the complexity of the matching is linear with N, the number of sources, and does not induce any problem to scale up. By implementing the join, we will increase the complexity of the matching (it becomes exponential). We investigate different solutions in order to permit the system to scale up. A possible way would be to explore only the most realistic matching cases, by using for example a learning approach, or by introducing constraints.Such a system can be very useful for different applications. Incorporated into an intranet system, it would allow a user to reach the data sources without knowing their schemas, by being based only on the domain ontology. In a P2P system, it could be installed on some peers or on the super-peers to facilitate access to data by their semantics. The only obligation for a peer would be to publish its data by using the OWL representation.References1. Bernstein P. A., Melnik S., Petropoulos M., and Quix C.: Industrial-strength schema matching. SIGMOD Record, Vol. 33, No 4, pp 38-43, 2004.2. Cui Z., Jones D., O’Brien P.: Issues in Ontology-based Information Integration. IJCAI, Seattle, 2001.3. Do H. H., Rahm E.: COMA - A System for Flexible Combination of Schema Matching Approaches. VLDB 2002, pp. 610-621.。