Databases Reference
In-Depth Information
Like the model management work, they assume that they are given a set of input
mappings that relate the two schemas. Unlike previous work on graph-based mod-
els, such as the ontology merging work in Sect.
5
, the authors assume that if two
elements are marked as being a match, that this is a
possible
place that they should
be merged in the result. The goal of their system is to help users understand the
space of possibilities that arise when a pair of elements are combined - what is the
impact on the rest of the schema?
Radwan et al.
[
2009
] build upon
Chiticariu et al.
[
2008
] by helping to automate
the process of choosing how the schemas should be merged and presenting this
result to the user. They use some of the schema matcher's internal information to
help chose which possible elements to merge. A key feature of their system is that
like
Pottinger and Bernstein
[
2003
] they create more complex edges than simple
equalities. In particular, if two concepts are deemed similar, then they are either (1)
merged, or (2) related through a “has” edge - they make this choice if the similarity
between two elements is quite high in one direction but low in the other.
Both works provide a valuable complement to the more theory-based papers that
make up the bulk of the papers cited here, and also dovetail nicely with some of the
work on user preference in ontology merging systems, e.g., SMART (see Sect.
5.1
).
7
Three-Way Merge
A final version of the merge problem is when the user is trying to merge two objects
that are derivatives of a common ancestor. This problem occurs in both computer
supported collaborative work (CSCW) [
Munson and Dewan 1994
;
Berlage and
Genau
1993
;
Berger et al. 1998
] and file merging [
Balasubramaniam and Pierce
1998
]. In these contexts, there is a common ancestor and the two later models
must be merged together based on the relationship between them and their com-
mon ancestor. With the added information from the common ancestor, the initial
matching is much simpler, but the merging can be much more difficult.
For example, if there is a change that occurs only in one model, then the system
will probably want to give preference to the changed model. This would seem to
make the problem easier, but there are likely to be other constraints (e.g., the other
model is preferred because it was modeled by an expert), which actually make the
problem more difficult. Another example of this is that if both models diverge from
the original, then it may be impossible to guess what the user wants. The presence
of this information means that there are additional semantic constraints that must
be satisfied, but the incompleteness of the information and the possibility of contra-
dicting other information means that these additional constraints must be satisfied
with no guarantee of a clear resolution to any of the constraints.
The work in this area that is the most flexible and automatic is that by Munson
and Dewan [
Munson and Dewan 1994
]. They propose a system that, depending
on the parameters that are specified, can be either manual, semiautomatic, or fully
automatic. Users who choose a more automatic system are likely to receive a merged
