Table 5.1 gives an overview of the matchers we have implemented and tested so far. We characterize the kinds of schema and auxiliary information they exploit. In the following we first describe the hybrid matchers followed by the combined matchers.5 The more complex hybrid matcher, Reuse, based on the reuse of previous match results is dis- cussed in Chapter 6.
Hybrid Matchers
Element names represent an important source for assessing similarity between schema elements. This can be done syntactically by comparing the name strings or semantically by comparing their meanings. Approximate string matching techniques [59] have already been employed in other fields, such as record linkage [138] and data cleaning [118], to detect duplicate database records concerning the same real-word entity, i.e., matching at the instance level. In COMA/COMA++, we implemented four hybrid matchers based on approximate string matching techniques:
• Affix: This matcher looks for common affixes, i.e., both prefixes and suffixes, between two name strings.
• N-Gram: Strings are compared according to their set of n-grams, i.e., sequences of n characters, leading to different variants of this matcher, e.g., Digram (2-grams), Trigram (3-grams).
• EditDistance: String similarity is computed from the number of edit operations neces- sary to transform one string to another one (the Levenshtein metric [59]).
• SoundEx: This matcher computes the phonetic similarity between names from their corresponding soundex codes.
Further hybrid matchers are the simple reuse-oriented matchers Synonym, Taxonomy, and Type, exploiting an auxiliary source for similarity:
5. We use the more accurate terms hybrid and combined matchers instead of simple and hybrid matchers, respectively, introduced in the first publication of COMA [29]. In particular, we want to emphasize, first, the flexibility to integrate new match algorithms into our Matcher Library, which may already consider multiple criteria and properties, i.e., hybrid, and second, the flexibility to specify and change the default matchers of a combined matcher as opposed to traditional hybrid matchers.
• Synonym: This matcher estimates the similarity between element names by looking up the terminological relationships in an external dictionary. Currently, it simply uses relationship-specific similarity values, e.g., 1.0 for a synonymy and 0.8 for a hypern- ymy relationship.
• Taxonomy: This matcher extends the reuse approach of Synonym and exploits a domain-specific taxonomy as auxiliary source. To estimate the similarity between ele- ment names, their matching concepts are first looked up in the taxonomy. The similar- ity of the concepts is computed using some distance metrics applied to the path connecting the concepts in the taxonomy and returned as the similarity between the element names.6
• Type: This matcher uses a synonym table specifying the degree of compatibility between a set of predefined generic data types, to which data types of schema ele- ments are mapped in order to determine their similarity.
Finally, we provide a hybrid matcher exploiting structural statistics of graph nodes: • Statistics: This matcher uses the Euclidean distance function to compute the similarity
between structural statistics, which are determined for single schema elements using a feature vector uniformly capturing the number of children, parents, leaves, etc.
Table 5.1 Implemented matchers in the Matcher Library
Technique Matcher Name Schema Info Auxiliary Info Default Matchers
Hybrid Matchers
String match-
ing AffixNGram Element namesElement names -- -- SoundEx Element names - - EditDistance Element names - - Reuse-ori-
ented SynonymTaxonomy Element namesElement names External dictionariesDomain taxonomy -- Type Data types Compatibility table - Reuse - Previous match results - Structure Statistics Structural statistics - -
Combined Matchers
Element-level Name Element names - Synonym, Trigram Comment Element comment Synonym, Trigram NameType Names + Data types - Name, Type Structure-
level NameStatNamePath Name + StatisticsNames + Paths -- Name, StatisticsName Children Child elements - NameType Leaves Leaf elements - NameType Parents Parent elements - Leaves Siblings Sibling elements - Leaves
6. This matcher is under development as we are still experimenting with different distance metrics and methods to combine the schema-to-taxonomy and intra-taxonomy similarities. Therefore, we omit it in the rest of the thesis.
5.4.MA T C H E R LI B R A R Y 4 9 Combined Matchers
The combined matchers utilizes multiple other matchers, which can be both hybrid or combined matchers, to obtain more accurate element similarity. The approach for com- bining the results of constituent matchers in a combined matcher follows the same prin- ciples used for combining the matcher results in the final phase of the match iteration. The combined matchers are in turn used to construct more complex match strategies (see Chapter 8).
We currently support three element-level combined matchers, Name, Comment, and NameType, and six structural combined matchers, NameStat, NamePath, Children, Leaves, Parents, and Siblings. All approaches rely to different degrees on similarities derived from element names for which combinations of the hybrid matchers discussed above can be utilized (e.g., Synonym and Trigram). We describe the main idea of the single combined matchers in the following, while the details of how matchers are combined within a com- bined matcher are explained in Section 7.3.
• Name: This matcher only considers element names but is a combined approach because it combines different hybrid matchers. It performs some pre-processing steps, in particular a tokenization to derive a set of components (tokens) of a name, e.g.,
POShipTo → {PO, Ship, To}. Moreover, it expands abbreviations and acronyms, e.g.,
PO → {Purchase, Order}. Name then applies multiple string matchers, such as Syn- onym and Trigram, on the token sets of the names and combines the obtained similarity values for tokens to derive similarity values between element names (see Section 7.3). • Comment: This matcher is identical to the Name matcher, except that it compares ele- ment comments. Like names, comments are tokenized and known abbreviations are expanded to their full form. The token sets are compared using multiple string match- ers, e.g., Synonym and Trigram. The token similarities are then combined to obtain the similarity between element comments. As this kind of schema information is not always available in schemas, the applicability of Comment is limited.
• NameType: This element matcher combines the Name and Type matcher, i.e., it matches elements based on a combination of their name and data type similarity. It works best for elements at the finest level of granularity, such as attributes in XML and columns in relational schemas, as they typically offer both name and data type information. • NameStat: This matcher determines the similarity between elements based on their
name and structural similarity, which are computed by the Name and Statistics matcher, respectively. It aims at differentiating inner elements, which lack data type but provide rich structural information.
• NamePath: Given paths as inputs, this matcher uses Name to compute name similarities between the nodes on the paths and derives a combined value to indicate the path sim- ilarity. In particular, considering the complete name path of an element provides addi- tional tokens for name matching which may improve match accuracy. For instance, this can be helpful to find match candidates at different schema levels, e.g.,
ShipTo.street and ShipTo.Address.street. On the other hand, it is possible to distin-
guish between different contexts of the same element, such as ShipTo.Street and
BillTo.Street.
• Children: This structural matcher is used in combination with a leaf-level matcher. In particular, it follow a bottom-up approach to propagate element similarity. In particu- lar, the similarity between elements is derived from the similarities between their chil- dren, i.e., direct descendants, which can be both inner and leaf elements. The
similarity between the inner elements is recursively computed from the similarity between their respective children. The similarity between the leaf elements is obtained from the leaf-level matcher, for which NameType is used as the default.
• Leaves: This matcher also performs bottom-up similarity propagation and is used in combination with a leaf-level matcher, for which NameType is set as the default. Unlike Children, Leaves only considers the leaf elements to estimate the similarity between two inner elements. This strategy aims at more stable similarity in cases of structural conflicts if similar elements are modeled at different detail levels. In Figure 5.2, for example, elements shipToStreet, shipToCity, etc., are children of ShipTo in S1, while in S2, their matching elements are not children of DeliverTo, but of Address. Children will therefore only find a correspondence between ShipTo and Address, while Leaves can also identify a correspondence between ShipTo and DeliverTo.
• Parents: This structural matcher propagates element similarity in a top-down manner and derives the similarity between elements from the similarities between their par- ents, which are computed by default by the Leaves matcher. This allows the similarity between two inner elements to influence that of their descendants.
• Siblings: This matcher complements the bottom-up and top-down approaches of Chil- dren, Leaves, and Parents, by allowing the similarity to be propagated from the neigh- bor elements at the same level. Similar to Parents, it employs by default the Leaves matcher to compute the similarity between the sibling elements determined for the input elements.