Content area
The prospect of combining information from diverse sources for superior decision making is plagued by the challenge of semantic heterogeneity, as data sources often adopt different conventions and interpretations when there is no coordination. An emerging solution in information integration is to develop an ontology as a standard data model for a domain of interest, and then to define the correspondences between the data sources and this common model to eliminate their semantic heterogeneity and produce a single integrated view of the data sources. We first claim that this single integrated view approach is unnecessarily restrictive, and instead offer the view that ontologies can simultaneously accommodate multiple integrated views provided the accompaniment of contexts , a set of axioms on the interpretation of data allowing local variations in representation and nuances in meaning, and a conversion function network between contexts to reconcile contextual differences. Then, we illustrate how to achieve semantic interoperability between multiple ontology-based applications. During this process, application ontologies are aligned through the reconciliation of their context models, and a new application with a virtual merged ontology is created. We illustrate this alternative approach with the alignment of air travel and car rental domains, an actual example from our prototype implementation. [PUBLICATION ABSTRACT]
Inf Technol Manage (2007) 8:4763 DOI 10.1007/s10799-006-0007-1
Contextual alignment of ontologies in the eCOIN semantic interoperability framework
Aykut Firat Stuart Madnick Benjamin Grosof
Published online: 23 February 2007 Springer Science+Business Media, LLC 2007
Abstract The prospect of combining information from diverse sources for superior decision making is plagued by the challenge of semantic heterogeneity, as data sources often adopt different conventions and interpretations when there is no coordination. An emerging solution in information integration is to develop an ontology as a standard data model for a domain of interest, and then to dene the correspondences between the data sources and this common model to eliminate their semantic heterogeneity and produce a single integrated view of the data sources. We rst claim that this single integrated view approach is unnecessarily restrictive, and instead offer the view that ontologies can simultaneously accommodate multiple integrated views provided the accompaniment of contexts, a set of axioms on the interpretation of data allowing local variations in representation and nuances in meaning, and a conversion function network
between contexts to reconcile contextual differences. Then, we illustrate how to achieve semantic interoperability between multiple ontology-based applications. During this process, application ontologies are aligned through the reconciliation of their context models, and a new application with a virtual merged ontology is created. We illustrate this alternative approach with the alignment of air travel and car rental domains, an actual example from our prototype implementation.
Keywords Intelligent information integration Query rewriting Ontology merging
1 Introduction
The globalization of information on the Internet presents signicant opportunities and challenges at the same time. The prospect of combining information from diverse sources for superior decision making is plagued by the challenge of semantic heterogeneity, as data sources often adopt different conventions and interpretations when there is no coordination. For example, on the web, a European site lists airfare in Euros, while a USA-based one lists them in Dollars; the airfare in one contains all the taxes and fees, while in another it does not. Furthermore, users of these web sites have their own assumptions about what the data means, which sometimes do not correspond to the reality of the actual web sites.
There are several efforts focused on addressing this semantic interoperability problem. Probably the largest of these efforts is the Semantic Web [3]. An emerging solution in these efforts is to develop an
Editor-in-Chiefs Note: An earlier version of this paper was accepted for WITS2004. The authors were subsequently invited to submit an expanded paper for publication consideration in Information Technology and Management. The conference co-chairs, Professors Amit Dutta and Paulo Goes were the guest editors for this paper.
A. Firat (&)
Northeastern University, Boston, MA, USA e-mail: [email protected]
S. Madnick B. Grosof Massachusetts Institute of Technology, Cambridge, MA, USA
S. Madnicke-mail: [email protected]
B. Grosofe-mail: [email protected]
123
48 Inf Technol Manage (2007) 8:4763
ontology as a standard data model for a domain of interest, and then to dene the correspondences between the data sources and this common model to eliminate their semantic heterogeneity [14, 22]. Furthermore, mappings between similar or complementary ontologies are envisioned to achieve semantic interoperability between multiple domains of interest; thereby indenitely extending the web of semantically connected data sources [15].
There are, however, a number of problems with the above approach. First, ontology developers need to standardize the exact meaning and representation of ontological terms. This requirement turns ontology development and adoption into a standardization process which is notoriously arduous and resource greedy. As a consequence, projects involving ontology development are often long; very often longer than initially planned; and too often delayed ad eternam.
Second, developing a standard ontology eliminates the semantic heterogeneity and locks the receivers into a single integrated view of the data sources. A more exible approach would preserve the semantic heterogeneity while reconciling the semantic conicts between sources and receivers, and offer multiple integrated views of the data sources based on receiver choices.
Third, mappings in these approaches are dened between sources and ontologies, or between ontologies and ontologies. This kind of a mapping architecture does not allow a clean modularization and reuse of mappings, thus requires unnecessary large amounts of extra work for dening and managing the evolution of mappings to achieve large scale semantic interoperability.
In this paper, we propose an abstraction to handle semantic reconciliation, in which a context is dened, independent of any data source, and semantic reconciliation is performed at the context level by dening conversion functions between contexts as a network. This alternative approach is realized through the extended COntext INterchange (eCOIN) framework, a logic based knowledge representation framework formally dened in Sect. 2.2. eCOIN assumes the existence of an ontology to tie the sources, but this ontology does not act like the global schema of the database integration era [2, 17]. The ontology acknowledges the minimal agreements between the data sources, and is coupled with a well-dened (yet extensible) context model to allow variations in representation and nuances in meaning, thus effectively maintaining multiple integrated views of the data sources. The ontological agreements are minimal in the sense that representational and semantic differences can be deferred to contextual axioms and need not be
xed. For example, the ontological term airfare should be acknowledged to refer to the price of an airplane ticket in the most general sense, but the specics of the reference (e.g. round trip vs. one-way, Dollar vs. Euros, including taxes or not) need not be spelled out in the ontology. The ontology denes the dimensions of the possible specializations (e.g. currency) but leaves the particular choices (e.g. US dollars vs. Euros) to the contexts. This approach dramatically shortens the ontology development process by shifting the focus from the specics to the generics, and allows gradual incorporation of the specics into the data model. Furthermore, this abstraction allows us to construct a conversion function network independent of any local data models, thus facilitates modularization and reuse of semantic and representational mappings.
In the following sections, we describe the details of the eCOIN approach with simplied yet illustrative examples. First we discuss the case where a single ontology with an associated context model is used to tie multiple air travel web sites. Then, we consider multiple systems modeled this way (with the addition of an example from the car rental domain) and discuss an approach to achieve interoperability between them without locking users into a single predened view. The exibility of our approach and methodology is illustrated with the alignment of the air travel and car rental domains, an actual example from our prototype implementation.
2 Single ontology, multiple views
We start this section with a simplied scenario to illustrate the semantic interoperability problem involving a number of heterogeneous airfare data sources and the solution offered by eCOIN. In this scenario and others, eCOIN acts as a middleware accepting nave user queries and rewriting them into mediated queries using the shared ontology or ontologies, contexts of the data sources and receivers (users), and the conversion function networks as shown in Fig. 1. When the mediated queries are run against the data sources, the results are in the form the users1
1 There are typically two types of users: A developer user that writes the actual software that issues SQL requests to the databases and provides a user friendly interface (usually via a web browser) so that end users can make their requests using simple pull-down menus and other such means. In both cases, these users need not know the actual semantics of the sources. Although the examples in this paper show the use of SQL, the key issue of mapping source contexts to receiver contents applies to both types of users.
123
Inf Technol Manage (2007) 8:4763 49
Fig. 1 Context mediation eCOIN mediates user queries by using the ontology of data sources, contexts of users and data sources, and the conversion function network between contexts
expect, because semantic conicts are addressed with appropriate embedded conversions.
The airfare data sources in our rst scenario are semi-structured web sites, but they can be treated as structured data sources by using the Cameleon web wrapper engine [8]. Throughout this paper, we limit the scope of the semantic interoperability problem to querying multiple semantically heterogeneous data sources. We use the relational model in describing the data sources, and the widespread query language SQL for formulating the user queries. Our approach, however, offers a general logic-based framework and has wider applicability.
Furthermore, we assume that the queries are not expressed against a mediated ontology, but directly against the data source schemas. When this assumption becomes impractical, the queries may be seen as the outcome of a pre-processing step, in which a query against a mediated ontology has been rewritten against the underlying data sources by using one of the standard techniques such as answering queries using views[13]. This pre-processing step, in our case, need not be concerned with the semantic conicts between the data sources (and users), thus it must be clear that our approach complements rather than competes with such approaches.
2.1 Motivational example
Under the air travel scenario, shown in Fig. 2, the user wants to query the cheaptickets and eurotickets web sites through a relational wrapper interface, but she does not have the time, energy, and resources to understand what the data actually means in these data
sources. The assumptions (i.e., context) of the user are shown at the top left of Fig. 22. For example, the user is expecting the answer to be in Turkish Liras. Naively, the user formulates the following query hoping to obtain the bottom-line prices of ights from Boston to Istanbul departing on June 1st and returning on July 1st from both sources sorted in ascending order.
Q1 :(SELECT Airline, Price FROM cheaptickets WHERE DepDate = 06/01/05 and ArrDate = 07/01/05 and DepCity = Boston and ArrCity = Istanbul
UNIONSELECT Airline, Price FROM eurotickets WHERE DepDate = 06/01/05 and ArrDate = 07/01/05 and DepCity = Boston and ArrCity = Istanbul)ORDER BY Price ASC;
Because the data sources use airport codes to identify the destination and departure locations, this query returns empty results. Suppose that the user, somehow, gures out this conict and reformulates the query Q1 by replacing the city names with airport codes (call this new query Q1). This time the following data are returned from the data sources (Table 1):
These results, however, confuse the user even more, because the user is not aware of the semantic conicts summarized in Table 2 below, thus cannot make an informed decision. Table 2 shows that the user has conicts on currency and airport identier format with both sources, and on what is included and covered
2 Similarly, the contexts of the two sources are shown in the center of Fig. 2.
123
50 Inf Technol Manage (2007) 8:4763
Fig. 2 Airfare example scenario
AIRFAREUser A in Context C_UA Q1: (SELECT Airline, Price FROM CheapTickets * Fares are expected to be bottom-line price(round trip, includes taxes and fees)
WHERE DepDate = 06/01/05 and ArrDate= 07/01/05 and
DepCity= Bostonand ArrCity= Istanbul * Departure and Destination locations areexpressed as city names UNION
SELECT Airline, Price FROM EuroTickets * Currency is Turkish Liras (TLR)
WHERE DepDate = 06/01/05 * Todays date: 05/01/05 and ArrDate= 07/01/05 and
DepCity= Bostonand ArrCity= Istanbul) ORDER BY ASC;
CheapTickets in Context C_CT
* All fares are for each way of travel and do not include fees and taxes. * Service fee of $5 is charged* Departure and Destination locations are expressed as three letter airport codes * Currency is USD* Lufthansa offers 10% discount if the airfare is bundled with National car rental
cheaptickets
ID Airline Price Tax DepDate ArrDate DepCity ArrCity
(I) (A) (P) (Tx) (DD) (AD) (DC) (AC) 1 British Airways 495 75 06/01/05 08/01/05 BOS IST2 Lufthansa 510 77 06/01/05 08/01/05 BOS IST
EuroTickets in Context C_ET
* All fares are round trip and include all fees (service fee of $5) and taxes.
* Departure and Destination locations are expressed as three letter airport codes * Currency is USD
ID Airline Price Tax DepDate ArrDate DepCity ArrCity (I) (A) (P) (Tx) (DD) (AD) (DC) (AC)
1200 160 06/01/05Delta Airlines1 08/01/05 BOS IST
135United Airlines2 1145 06/01/05 08/01/05 BOS IST
Ancillary Sources
cityairport
currencyrates
FromCur ToCur eRate Date City Airport
TLR USD 0.75 05/10/05 Boston BOS USD TLR 1.33 05/10/05 Istanbul IST USD EUR 0.80 05/10/05
Table 1 Result of query Q1 Airline Price
British Airways 495 Lufthansa 510 United Airlines 1145 Delta Airlines 1200
(one-way or round trip) in the price with the cheap-tickets source.
If the original query Q1 were submitted to the eCOIN system, Q1 would be rewritten into the following mediated query MQ1, which, when executed, translates the source data into the form and meaning the user expects. As seen below, the translation is accomplished with the help of arithmetic expressions, and the use of external sources embedded in conver-
Table 2 Semantic conict table for the user and the data sources
Money amounts Price Airport identier
Conict dimension Currency Inclusion Coverage Format
User TLR Taxes + fees Round-trip City name Cheaptickets USD Nominal One-way Airport Code Eurotickets USD Taxes + fees Round-trip Airport Code
123
Inf Technol Manage (2007) 8:4763 51
to mappings (in the form of a conversion function network) dened between contexts.
In this framework, sources (S) and contexts (C) are described with respect to the ontology (O). Mappings (M) are structured according to the context model to enable translation between different contexts. Below each component is described in detail.
2.2.1 Ontology
Ontology in eCOIN includes both the domain and context model. As in other data integration frameworks, an eCOIN domain model is used to dene a common type system for the application domain (e.g., nancial analysis, travel information) corresponding to the data sources that are to be integrated. Because the scope of the problem has been limited to querying semantically heterogeneous data sources, the current conceptualization of an ontology is kept as simple as possible. Like many other conceptual models, an eCOIN domain model consists of a collection of (object) types, which may be related in a subtype hierarchy. Types have attributes to represent both the individual properties of objects and relationships between objects (both things and their properties are uniformly represented as objects) [27].
The types in an eCOIN domain model are semantic types, in that they represent the generic semantics of the concepts used in the various data sources. A semantic type is impartial to the exact representation or meaning of its instances in specic contexts and encapsulates all. The various specializations of these concepts used by different sources or receivers are described using a special kind of property called a modier. The modiers in an ontology are chosen to explicitly describe the contextual specializations of the generic types used by the sources and receivers. For example, as shown in Fig. 3, the generic ontological term airfare represented by the large cube can be specialized along three modication dimensions of {Coverage, Currency, Inclusion} (refer to Table 2). Different values of these modiers identify the different component cubes of the overall airfare cube that may be adopted by different sources and receivers.
The modiers in an ontology collectively dene its context model; and the collection of modier objects that describe the specializations that can be made by a given source or receiver denes its context. Context declarations are source independent, thus multiple sources or receivers may use the same context (use the
sion functions (shown as ancillary sources in Fig. 2) that perform the currency and airport identier conversions.
MQ1: (SELECT Airline, (2* (Price + Tax) + 5) * eRate
FROM cheaptickets, currencyrates, (select Airport from cityairport where city = Boston) cityairport1,
(select Airport from cityairport where city = Istanbul) cityairport2
WHERE DepDate = 06/01/05 and ArrDate = 07/01/05 and
DepCity = cityairport1.Airport and ArrCity = cityairport2.Airport and fromCur = USD and toCur = TLR and Date = 05/10/05
UNIONSELECT Airline, Price * eRateFROM eurotickets, currencyrates, (select Airport from cityairport where city = Boston) cityairport1, (select Airport from cityairport where city = Istanbul) cityairport2 WHERE DepDate = 06/01/05 and ArrDate = 07/01/05 and
DepCity = cityairport1.Airport and ArrCity = cityairport2.Airport and fromCur = USD and toCur = TLR and Date = 05/10/05) ORDER BY Price ASC
When query MQ1 is executed, the following results, which reect the bottom-line prices in Turkish Liras, would be obtained and the user can now make a better decision.
2.2 Representation of the motivational example in eCOIN
The semantic interoperability described in the previous section is accomplished with a number of declarative statements using the eCOIN semantic interoperability framework, which is a generic logic-based data model that provides a template for the integration of heterogeneous data sources and built on top of and signicantly extends the earlier works of [10, 24, 25]. This template is dened as follows:
Denition (eCOIN Framework) An eCOIN framework is a quadruple (O, S, C, M) where each component is a set of logical predicates. O corresponds to ontology that includes both the domain and context model; S corresponds to source declarations; C corresponds to context (instances); and M corresponds
Table 3 Result of MQ1 Airline Price
United Airlines 1527 British Airways 1527 Lufthansa 1572 Delta Airlines 1600
123
52 Inf Technol Manage (2007) 8:4763
2.2.1.1 Domain Model
Types :semanticType ticket : semanticType airport: ... semanticType coverageType:Type hierarchy :isa airfare; moneyAmt : isa tax; moneyAmt: Attributes=Relationships :serviceFee ticket; moneyAmt : ... : hasTax ticket; tax:
2.2.1.2 Context Model
Modifiers :lformat airport; Context; airportFormat: inclusion airfare; Context; inclusionType: coverage airfare; Context; coverageType: currency moneyAmt; Context; currencyType: The variable Context in the Context Model signies that a modier is dened with respect to a given context, thus may acquire different values in different contexts.
2.2.2 Sources
Sources in the eCOIN framework are uniformly treated as relational sources (i.e., as having relational schemas). Many non-relational sources, such as HTML and XML web sites and web services, can be transformed into relational sources via wrappers [8]. A wrapped web source, for example, can be represented in logical predicates as:
cheapticketsI; A; P; Tx; DD; AD; DC; AC3
In the eCOIN framework, these are called primitive relations, because these sources are not yet tied to an ontology. These primitive relations are elevated into semantic relations by annotating the semantic type and context of each primitive relation.
The semantic relation cheaptickets can then be expressed as follows4:
cheaptickets0I0; A0; P0; Tx0; DD0; AD0; DC0; AC0 I0 objectticket; I; c ct; cheaptickets I; A; P; Tx; DD; AD; DC; AC; ... ; AC0 object...: With this elevation each column of the cheaptickets relation is tied to the air travel ontology. For the Id
Modifiers
E i in n
CCoonntteexxtt C
Cnn
A AI
IR
RF
FA AR
RE
Fig. 3 Multi-dimensional modication of the ontological term airfare
same specializations for various values), but often different sources use different contexts.
Modiers themselves are semantic types, thus can be subject to specialization (e.g. There are multiple ways to represent a currency, such as USD vs. $.) This can be handled via dening modiers of modiers. In Fig. 4, this situation is illustrated by a CurrencyFormat modier for the Currency modier. For objects without modiers, the context model implies a current existence of a common representation and meaning across the sources and receivers. If this assumption changes at a later time, new modiers can be introduced, further slicing and dicing the generic concepts.
In Fig. 5, we illustrate the ontology, context instances and the conversion function network that corresponds to our motivational airfare example. To make our description more concrete, we also provide below the logical predicates used in eCOIN to represent the domain and context model: (The omit-tedtrivially predictablepredicates are indicated with three dots.)
Fig. 4 Modiers can have modiers
3 The abbreviations, such as I and A, correspond to the attributes shown in Fig. 2.
4 Notation: We add a single quote to semantic objects/relations to distinguish them from primitive ones.
Currency Format
123
Inf Technol Manage (2007) 8:4763 53
Fig. 5 Illustration of the ontology, sources, contexts, and the conversion function network for the air travel example
Attribute Modifier
IS-A
Air Travel Ontology
origin
destination lformat coverage
lformat = Airport
Context: C_CT
inclusion = nominal
currency = USD
coverage = one-way
Contexts cheaptickets user A eurotickets
lformat = City
Context: C_UA
inclusion = taxes + fees
currency = TLR
coverage = round trip
lformat = Airport
Context: C_ET
inclusion = taxes + fees
currency = USD
coverage = round trip
Conversion Function Network
currency
inclusion
column, for instance, this is accomplished by associating the value I (a generic value) with the ticket semantic type in the cheaptickets context c_ct. I in the above declaration is the semantic object corresponding to the primitive object (value) Id from the cheaptickets relation.
In addition, the attribute relationships dened by the ontology are instantiated as part of source declarations. For example, the hasTax relationship would be declared for this source as follows:
hasTax I0; Tx0 cheaptickets0 I0; ; ; Tx0; ; ; ; :5
This declaration means that the tax of a semantic object I is another semantic object Tx, both of which can be obtained from the semantic relation cheaptickets.
2.2.3 Contexts
For sources, contexts dene the specializations used for the underlying data values; and for receivers
contexts describe the specializations assumed in viewing the data values. These specializations may be about the representation of data (e.g. European vs. American style date formats) or nuances in meaning (e.g. nominal vs. bottom-line prices). To dene a source or receiver context, modier assignments need to be made. For example, the context labeled as c_ct can be described with the following predicates:
currency(MoneyAmt,c_ct,Currency)
Currency = object(currencyType, USD, c_ct,constant(USD)). inclusion(Airfare, c_ct, Inclusion)
Inclusion = object(inclusionType, nominal, c_ct, constant(nominal)). coverage(Airfare, c_ct, Coverage)
Coverage = object(coverageType, oneway, c_ ct, constant(oneway)). lformat(Airport, c_ct, LFormat)
LFormat = object(airportFormat, airport, c_ct, constant(airport)).
5 Underscores, as in Prolog, are used to designate any value.
123
54 Inf Technol Manage (2007) 8:4763
These modier declarations, which can include attribute relationships, semantic relations, and some other constructs, explicitly specify which view of the ontology is adopted by the cheaptickets source. Accordingly, the ontology corresponding to the cheaptickets source treats airfare as the one-way nominal price of a ticket in US dollars. The arrival and departure locations are expressed as airport codes, and money amounts (moneyAmt) in general are in US dollars. These declarations need to be made for all contexts in a similar fashion.
2.2.4 Mappings (Conversion function network)
Mappings in eCOIN ensure that a view of the ontology adopted in a context is appropriately mapped to a corresponding ontological view in another context. This is accomplished by dening a conversion function network for each ontological term. Conversion functions are atomically dened for each modier dimension as illustrated in Fig. 6. As an example, the conversion function for the currency modier dimension is encoded declaratively in terms of logical predicates as follows:
f currencyX; VS; SC; VCurS; VCurT; TC; VT value Today; SC; VToday; systemDate VToday; value CurS; SC; VCurS; value CurT; SC; VCurT; currencyrates0CurS; CurT; Today; Rate; value Rate; SC; VRate; mul VS; VRate; VT: For semantic airfare objects, this function uses the modier value VCurS in source context SC, and modier value VCurT in target context TC to translate the source value VS of semantic object X to value VT in target context. The value(A,C,B) predicate used above is read as the value of semantic object A in context C is B. The function is also using another semantic relation currencyrates; a system function system-Date(VToday) and an arithmetic predicate mul to express multiplication.
As in the currency conversion function example above, conversion functions can sometimes be dened parametrically, thus may cover all of the modier value pairs with a single function. Within eCOIN conversion functions can be dened as a network to minimize the number of declarations, leaving the tasks of combining, inverting, and simplifying to the mediator. Furthermore, most conversion functions are orthogonal, i.e. they can be applied in any order. When they are not orthogonal, priorities can be assigned to determine the order they are to be executed. The details of conversion function network organization and mediation techniques used in eCOIN can be found in [7].
3 Interoperability between multiple eCOIN applications
In the previous section, we have described how a single ontology can be used to achieve interoperability between multiple semantically heterogeneous sources and receivers not by locking them into a single integrated view, but by allowing them to operate within their own context. Many applications using such ontologies describing similar or complementary domains are likely to exist, and achieving semantic interoperability between sources and receivers tied to different ontologies becomes an issue to be addressed. In this section, we rst introduce a second application in a related domain, car rental, and then proceed to describe how we achieve interoperability between airfare and car rental applications through contextual alignment of their ontologies.
3.1 Airfare with car rental scenario
Consider now the European car rental application, illustrated in Fig. 7. User B in context C_UB poses a query Q2, to nd the companies and their prices for car rental to be picked up and dropped off in Istanbul between the dates June 2nd and July 1st. Similar to the airfare scenario, the user and the source have semantic conicts concerning what is included in the price, and the period of the rental rate (daily vs. total). Unlike the airfare application, however, there is a shared understanding that the currency is Euros, the dates are expressed in European styles, and rental locations are expressed as airport codes; therefore modiers were not used during the ontology design for date, airport, and the monetary amounts (like price, tax, and fees). Although some of these shared understandings could have been relaxed (through the declaration of appropriate modiers) with the expectation of future heter-
Currency
Coverage
Fig. 6 Organization of conversion functions for the ontological term airfare
123
Inf Technol Manage (2007) 8:4763 55
CAR RENTAL
User B in Context C_UB Q2: SELECT Company, Price * Rentals are expected to be bottom-line price FROM cheaprentals (includes taxes, and fees) WHERE Class= Economy and * Rates are for the rental duration PickDate = 02/06/05 and * Currency is Euros DropDate= 01/07/05 and
Pickup= IST and DropOff= IST;
cheaprentals in Context C_CR* Rentals do not include fees and taxes.* Rates are daily * National offers 10% discount if the car rental is bundled with a Lufthansa airfare * Airport concession recovery fee %10* Sales tax is 5%* Currency is Euroscheaprentals
Company PickUp
Price Class Rate
Period (RP)
ID (I)
Drop ff
O (DO)
PickDate Drop ate D (DD)
(A) (PU) (PD) (P) (C)
Hertz IST IST 02/06/05 01/07/05 Economy Daily
1 23.99
2 National IST IST 02/06/05 01/07/05 Economy Daily
28.79
Fig. 7 Car rental example scenario
ogeneities, some of them would likely not be noticed until a heterogeneous source or receiver joins the system. We will see such a situation when we try to use the airfare and car rental applications together, when some of the shared understandings within individual domains will fail to persist in the combined domain.
Under this scenario, the user query Q2, is submitted to the eCOIN system built with the ontology, context instances, and the mappings shown in Fig. 8. This nave user query, expressed in the context of user B (C_UB), is rewritten into the following mediated query
In MQ2, the daily rates given by the sources are converted into the bottom line price requested by the user by multiplying the price by total rental days, the airport concession fee and sales tax ratios (30*1.1*1.05 = 34.65). When this query is executed the results shown in Table 4 are returned.
Consider now a third user as shown in Fig. 9 who wants to query both the airfare and car rental sources together. The user customarily expresses dates in American style, and locations as city names. With
query Q3, she wants to see bottom line prices in Euros including any bundling discounts (refer to Figs. 2 and 7 to see the bundling discounts).
Because the airfare and car rental applications have been built independently, a query involving sources from both domains can not be mediated before aligning the individual eCOIN applications. For this purpose a virtual merger application from two child applications needs to be built as shown in Fig. 10. This application is called virtual, because it doesnt physically contain the merged applications. Instead, the merged applications are aligned to facilitate a combined functionality in the new merger application. Yet, the virtual merger application can be treated just like any other eCOIN application, and extended with new set of sources, ontology elements, context instances, mappings, and can be merged with other applications. Next we illustrate how the creation of a virtual merger application is accomplished by using the airfare and car rental applications.
3.2 Merging procedure and representation in eCOIN
The virtual merging process in eCOIN is driven by the need to reconcile context models and the conversion functions of the individual applications. In addition, the new context model may be enhanced beyond the union of the individual models because shared
MQ2: SELECT Company, Price*34.65 FROM cheaprentals WHERE Class=Economy and PickDate = 02/06/04 and DropDate = 01/07/04 and Pickup = IST and DropOff = IST
123
56 Inf Technol Manage (2007) 8:4763
Car Rental Ontology
Attribute Modifier
IS-A
dropoffLoc
ratePeriod rateInclusion
rateInclusion = nominal
Context: C_CR
rateperiod= dynamically determined
Contexts cheaprentals user B
rateInclusion = taxes + fees
Context: C_UB
rateperiod= rental duration
Conversion Function Network
rateInclusion
ratePeriod
Fig. 8 Ontology, contexts, and the conversion function network for the car rental example
Table 4 Result of MQ2 Company Price
Hertz 831 National 998
understandings in individual domains may clash when combined. We also want to utilize the existing conversion function networks of individual applications, thus these networks need to be bridged to achieve full reuse of the existing mappings.
The merging process in eCOIN roughly corresponds to the owchart shown in Fig. 11, which refers to the following declarations:
Denition (Merger Declarations) Let A be the application that merges applications A1 to An6
A merging relationship that species the merger and the merged applications: merges A; A1; A2
This is read as: Application A is the merger root of applications A1 and A2.
An isoSemantic Type relationship that species the semantic type mappings between the merger
and the merged applications: isoSemantic Type
A; Ai; s; si
This is read as: Semantic type s in application A and semantic type si in application Ai has compatible modiers. Note that this declaration does not mean that s and si are synonyms.
It means that these two concepts have the same set of modiers. Related but different concepts (e.g. revenues vs. prots), and more specialized or general versions of the same concept (e.g. nancials vs. prots) can all qualify to have the same set of modiers.
An isoModier relationship that species the modier name mappings between the merger and the merged applications: isoModifier A; Ai; m; mi)
This is read as: Modier m in application A and modier mi in application Ai are equivalent modiers.
An isoContext relationship that species the context identier mappings between the merger and the merged applications: isoContext A; Ai; c; ci
This is read as: Context label c in application A and context label ci in application Ai are equivalent.
6 For simplicity reasons we are going to take n = 2 in the rest of the discussion.
123
Inf Technol Manage (2007) 8:4763 57
Fig. 9 Combined airfare & car rental example scenario
Q3: AIRFARE & CAR RENTAL
User Merger in Context C_UM (SELECT cheaptickets as fareprovider, Airline, Company, t.Price + r.Price as TotalFROM cheaptickets t, cheaprentals r * Both Rentals and Fares are expected tobe bottom-line price (including bundlingdiscounts)
WHERE DepDate=06/01/05 and ArrDate=07/01/05 and DepCity= Boston and ArrCity= Istanbul and* Date is expressed in American style Pickup="Istanbul" and Dropoff="Istanbul" and * Both Rental and flight locations areexpressed as city names
PickDate="06/02/05" and DropDate="07/01/05"
UNION* Currency is Euros SELECT eurotickets as fareprovider, Airline, Company, t.Price + r.Price as TotalFROM eurotickets t, cheaprentals rWHERE DepDate=06/01/05 and ArrDate=07/01/05 and DepCity= Boston and ArrCity= Istanbul and Pickup="Istanbul" and Dropoff="Istanbul" and PickDate="06/02/05" and DropDate="07/01/05")
ORDER BY Total DESC
Airfare Application
Car Rental Application
Fig. 10 Virtual application merging
An isoAttribute relationship that species the attribute name mappings between the merger and the merged applications: isoAttribute A; Ai; a; ai This is read as: Attribute a in application A and
attribute ai in application Ai are equivalent attributes.
The above mappings are always specied between the merger and the merged applications, never between merged applications directly. In Fig. 12, the result of the merging for the car rental and airfare applications is shown. Below, we discuss some of the important points of this merging process.
3.2.1 Upward inheritance
By default all of the elements of the applications to be merged are included in the merger application. When there are equivalent elements, the merger declarations designate which one of those elements is chosen to be upward inherited. In Fig. 12, elements that are upward inherited are shown with bold borders. For the car
rental and airfare applications these are accomplished with the following declarations.
Merger Axiomsmerges travel; airFare; carRental : isoSemanticType travel; carRental; date; date: isoSemanticType travel; airFare; tax; tax: isoSemanticType travel; carRental; airport; airport:
3.2.2 Ontology extensions
Because the merger application is just like any eCOIN application, it can be extended with additional elements to facilitate the merging process or simply enhance the ontology. As shown in Fig. 12, the virtual merger ontology has a new semantic type price, which acts as a super type of airfare and rate semantic types, and a sub type of the moneyAmt semantic type. In addition to the modiers it inherits from the moneyAmt, price also has a new modier of its own called bundling. This new modier is used to represent the previously inapplicable assumption of including the bundling discount or not when rental and airfare is purchased together.
Furthermore, the ontology is extended by introducing a modier for the date type, because the interpretation of the date type is no longer a shared one after the merger: airfare uses American style dates, whereas the car rental uses European style.
Another interesting extension is seen in the case of dening a modier of the currency modier. In this case, we assumed for illustration purposes that the sources and receivers in the car rental application
123
58 Inf Technol Manage (2007) 8:4763
Fig. 11 Flow chart of the merging process
1
Declare Apps A and B merged
2
Pick semanticType S1 from App A or B that has not been examined
Yes
No
Go to step 10
3
No
Yes
Create an explicit modifier for S1 and declare its values in all of the contexts of that app.
Create new conversion functions if needed.
Yes
4
Declare S1 & S2 isoSemanticTypes , and designate one of them ( S) for the merger application
Declare M1 & M2 isoModifiers and designate one of them ( M) for the merger application
Yes
Go to step 5
No
- Create a modifier MM for M
- Create a conversion function for the new modifier MM to convert from one app's representation to the other.
5
Yes
6
Yes
No
Declare the emergent modifiers
7
- For each modifier of S1 & S2, assign values for all the contexts that did not previously know about those modifiers.
- Create new conversion functions if needed
8
Yes
Declare A1 & A2 isoAttributes and designate one of them for the merger application
9
Yes
Define the equivalent attribute, or define alternative conversion functions
Go to step 2
10
Yes
Declare C1 & C2 isoContexts and designate one of them for the merger application
No
11
Extend the merged app by adding to the ontology, source and context info as needed.
END
would like to express currencies using the currency symbols (e.g. $, , etc.). This necessitates the declaration of the cFormat modier for the currency type to allow variations in the way currencies are expressed. All of these extensions are expressed with the following logical predicates:
semanticType price:isa airfare; price : isa rate; price :isa price; moneyAmt : isafees; moneyAmt: bundling price; Context; bundlingType: dformat date; Context; dateFormatType: cFormat currencyType; Context; currencyFormat:
123
Inf Technol Manage (2007) 8:4763 59
Fig. 12 Illustration of the merged ontology, contexts, and conversion function networks (virtual)
3.2.3 Cross fertilization of contexts
During merging it is highly likely that new modiers are introduced for the individual applications. Because the individual applications were previously unaware of these modiers, their values need to be introduced in the merger application. For example, the values for the data modier dformat need to be introduced for all existing contexts, because date format had a shared representation and meaning before the merging. The number of context declarations, however, can be reduced by dening umbrella contexts as the super-types of the application contexts. Below, this is exemplied by rst dening c_usa as the umbrella context for the airfare application, and c_europe for the car rental. The context labels of each application are then organized in a sub type hierarchy with the umbrella contexts. Subsequently the modifer values for the umbrella contexts are declared.
3.2.3.1 Context Hierarchy
isac ct; c usa:isac ua; c usa:isac et; c usa: isac ub; c europe:isac cr; c europe:
3.2.3.2 Context Values
dformat(Date,c_usa,Format)
Format = object(dateFormatType,American,c_usa,constant(American)). dformat(Date,c_europe,Format)
Format = object(dateFormatType,European, c_europe,constant(European)).
Similarly, the rest of the missing modier values can be declared for the cFormat, bundling, lformat, inclusion, coverage, rateInclusion, and the ratePeriod modiers.
3.2.4 Linking the conversion function networks
With the introduction of new modier values, the conversion function networks of the individual applications need to be aligned, and if need be, extended. For example, the emergence of dformat, bundling, and cformat modiers necessitates the declaration of three new conversion functions. Some conversion functions, however, can be used without any modication. For example, the carRental application can readily use the currency conversion function of the airfare application without any modications. The differences in the way
123
60 Inf Technol Manage (2007) 8:4763
currencies are represented in both applications are taken care of by the conversion function dened for the cformat modier, thus do not create any problems.
In some other cases, the conversion function may not be parameterized like the currency conversion function, thus new nodes may need to be introduced. For example, if a new receiver wants to express the dropoff and pickup locations of cars with zipcodes, the conversion function network for the lformat modier can be extended with a new node called zipcode and appropriate conversion functions connecting this new node to the network (e.g. to the city node).
Furthermore, if the conversion functions use any constructs peculiar to the individual applications, these constructs need to be dened for the objects of the other application. If this cannot be done, the conversion function has to be redened in the worst case.
3.3 Mediation of the query over the merger application
The query Q3, shown in Fig. 9, can now be mediated by the eCOIN engine into the following mediated query MQ3:
MQ3: SELECT cheaptickets as fareprovider, Lufthansa, National, ((2 * (t.Price + Tax) + 5) * eRate + r.Price *34.65) * 0.9 as total
FROM cheaptickets t, currencyrates, cheaprentals r,
(select Airport from cityairport where city = Boston) cityairport1, (select Airport from cityairport where city = Istanbul) cityairport2 WHERE DepDate = 06/01/05 and ArrDate = 07/01/05 and
DepCity = cityairport1.Airport and ArrCity = cityairport2.Airport and fromCur = USD and toCur = EUR and Date = 05/10/05 and Airline = Lufthansa and Company = National and Class = Economy and PickDate = 02/06/05 and DropDate = 01/07/05 and Pickup = cityairport2.Airport andDropOff = cityairport2.AirportUNIONSELECT cheaptickets as fareprovider, Airline, Company, ((2
* (t.Price + Tax) + 5) * eRate + r.Price * 34.65) as total FROM cheaptickets t, currencyrates, cheaprentals r,
(select Airport from cityairport where city = Boston) cityairport1, (select Airport from cityairport where city = Istanbul) cityairport2 WHERE DepDate = 06/01/05 and ArrDate = 07/01/05 and
DepCity = cityairport1.Airport and ArrCity = cityairport2.Airport and fromCur = USD and toCur = EUR and Date = 05/10/05 and (Airline<>Lufthansa or Company<>National) and Class = Economy and PickDate = 02/06/05 and DropDate = 01/07/05 and Pickup = cityairport2.Airport and DropOff = cityairport2.Airport
UNION
SELECT eurotickets as fareprovider , Airline, Company,(t.Price * eRate + r.Price * 34.65) as total FROM eurotickets t, currencyrates, cheaprentals r,
(select Airport from cityairport where city = Boston) cityairport1, (select Airport from cityairport where city = Istanbul) cityairport2 WHERE DepDate = 06/01/05 and ArrDate = 07/01/05 and
DepCity = cityairport1.Airport and ArrCity = cityairport2.Airport and fromCur = USD and toCur = EUR and Date = 05/10/05 and Class = Economy and PickDate = 02/06/05 and DropDate = 01/07/05 andPickup = cityairport2.Airport and DropOff = cityairport2.Airport
This mediated query reconciles all the conicts between the sources and the user context c_um. The prices are adjusted to include all taxes and fees; discounted when applicable (note the multiplication by0.9 in the rst subquery to take care of the bundling situation). Car rental prices are adjusted to cover the rental duration; and airfare reects round-trip prices. Furthermore, all the prices are reported in Euros. When this mediated query is executed, it produces the non-obvious results, shown in Table 5, which reveal a three way tie between British Airways & Hertz, Lufthansa & National and United Airlines and Hertz.
4 Related work
This paper describes a novel approach to achieving semantic interoperability between ontology based applications, thus relates to the broad ontology integration techniques literature. The origins of ontology integration can be traced back to schema integration, which has been studied extensively since 1980s [2]. Schema integration research produced some guidelines to be used in integrating disparate schemas and semi-automatic tools, but the process could not be fully
Table 5 Results of MQ3
Fareprovider Airline Company Total
Cheaptickets Lufthansa National 1747 Cheaptickets British Airways Hertz 1747 Eurotickets United Airlines Hertz 1747 Cheaptickets Lufthansa Hertz 1775 Eurotickets Delta Hertz 1791 Cheaptickets British Airways National 1914 eurotickets United Airlines National 1914 eurotickets Delta National 1958
123
Inf Technol Manage (2007) 8:4763 61
automated because schema semantics could not be made explicit without human intervention.
Ontology integration is a difcult and multi-dimensional problem, which involves both syntactic and semantic heterogeneities. Syntactically, ontologies may be expressed using different languages (e.g. KL-ONE vs. KIF) that may have different level of expressiveness (e.g. one supports default values the other does not). Ontolingua project [12] aims to overcome this problem by providing an ontology language that can be translated to a variety of other ontology languages through the use of special purpose translators. It also provides a centralized repository to encourage reuse of ontologies developed in a variety of languages. In our study, we assumed that ontologies were represented using the same ontology language thus avoided the syntactical issues.
Semantic differences such as the ones outlined by[23] and shown in Fig. 13, however, offer more difcult challenges as they require human intervention to understand and reconcile the meaning of ontological terms and relationships.
Efforts such as the standard upper ontology (SUO)[20] and Cyc upper ontology [23] aim to reduce this need and provide general ontologies that can be used as the foundation of more specic ontologies. In these efforts, mappings that translate concepts of one ontology into the standard upper ontology are dened. The Carnot project for instance maps domain specic schemas to the Cyc knowledge base through the use of articulation axioms.
These articulation axioms may relate synonymous concepts with each other as shown below:
(synonymousExternalConcept Waikohu-County NewZealand FIPS10-4Information1995 NZ86)
where Waikohu-CountyNewZealand is the Cyc term synonymous with NZ86 in source FIPS10-4Information1995.
Or they may specify an overlapping relation as in the following example:
(overlappingExternalConcept InferiorMesentericVein MeSH-Information1997 Mesenteric Veins | A7.231.908.670.385)
Approaches that integrate ontologies by dening mappings (e.g. articulation axioms in Carnot) between them are known as ontology alignment approaches. On the other hand, approaches that aim to produce a new ontology out of a set of ontologies is known as ontology merging [21]. We consider integrating ontologies in eCOIN as a hybrid of these approaches: like ontology alignment we use articulation axioms to align ontologies, and like ontology merging we produce a new (but virtual) ontology out of two ontologies.
The state of the art in ontology merging today is dominated by semi-automatic tools that can analyze ontologies, and guide the user during merging by making suggestions. Examples of well known such tools are Prompt [9], Ontomorph [4] and Chiemera [18]. Recently, there are also approaches extending these techniques to Semantic Web [6].
In these types of semi-automatic matching approaches, which is surveyed in [22], the rst step is the syntactic match phase in which ontological terms referring to similar objects are identied based on a linguistic similarity measurement. In the simplest case synonyms from a thesaurus can be used. In more sophisticated approaches, a lexical reference system like Wordnet [19] can be used to identify similar terms through the use of richer semantics that involves relationships linking different synonyms sets.
In Ontomorph [4], which is based on the Power-Loom knowledge representation system, the user is offered a number of transformative operators to apply to the initial list of matches from the syntactic match phase. A human expert has to do the rest of merging manually. Chimaera [18] is like Ontomorph but considers subclasssuperclass relations when making suggestions. PROMPT, previously known as SMART, is built on top of an ontology editor tool Protg 2000. Based on a linguistic similarity among concept names it suggests actions, which may be applied by the user. It also allows users to dene new actions by using the Protg 2000 tool.
These tools are useful in cutting some amount work during ontology merging, but because the semantics of different ontologies cannot automatically be made explicit, the user still has the burden of understanding each ontology before doing the merging, and fully automatic approaches remain as a dream.
Terminological Differenceso Different names for the same concepto Related but different conceptso More specialized or general versions of the same concept o Attributes vs. functions vs. predicates representation Simple Structural Differenceso Two ontologies are similar yet disjointo One ontology is a subset of the othero One ontology is a reorganization of the otherComplex Structural DifferencesE.g., having action predicates vs. reified events Fundamentally different representationsE.g., Bayesian probabilistic vs. truth-logic
Fig. 13 List of differences between ontologies [23])
123
62 Inf Technol Manage (2007) 8:4763
Fig. 14 CLAMP tool for application merging in eCOIN
5 Limitations and future work
Our eCOIN approach described in this paper dramatically reduces the amount of work needed in creating ontologies by shifting the focus from agreeing on the exact meaning of the terms to identifying possible dimensions of conicts. There is still, however, some amount of coordination needed in determining what these dimensions will be and what values can be used for those dimensions. If eCOIN is to be used in a completely open environment like the Semantic Web, there needs to be further research in determining how some of the underlying restrictions of coordination can be overcome or reduced.
Furthermore, in the current conceptualizations of the Semantic Web, eCOIN constructs such as contexts, and conversion function networks are not explicitly accounted for. In order to translate the conceptual framework of eCOIN to that of the Semantic Web, further work is needed to nd out how to represent contexts, conversion function networks using the available Semantic Web constructs such as ontologies, and rules [11]. Preliminary results of such an effort can be found in [26].
There are also limitations in the ontology merging tools we developed so far, and further work is needed. In eCOIN, we use a semi-automatic tool called CLAMP [1, 16] (a screen shot is shown in Fig. 14), to guide the user during the application merging process. This tool, however, does not currently use any of the match techniques described in the literature, but facilitates the merging process by generating the underlying logical predicates through visual interfaces.
Incorporating the existing match techniques into this tool would further help the users in dealing with large scale applications.
6 Conclusion
We believe that achieving semantic interoperability between diverse information sources and receivers should have the dual purpose of: (1) reconciling semantic heterogeneity across information sources; and (2) supporting semantic heterogeneity across information receivers. In this paper, we offer a novel approach that satises this dual purpose by representing the semantic heterogeneity explicitly based on a context model. This context model, associated with an ontology, allows a mediation engine to detect and reconcile semantic conicts between the sources and receivers on the y and present the data to the users in the way they want.
Our approach has also a number of system level benets. First, ontology developers do not have to standardize the exact meaning and representation of ontological terms; but only need to agree on generic identities without exposing the specic details. A major advantage of this approach is that ontology developers frequently nd it straightforward (if not necessarily easy) to agree on the generic concepts; it is getting all the precise details worked out that creates a lot of the work. Moreover, its often the case that differences in these precise details are only discovered later (sometimes even after the system is in operation). The
123
Inf Technol Manage (2007) 8:4763 63
eCOIN approach enables these details to be factored out, reducing the amount of work needed to introduce these details all at once.
Second, because the ontology is impartial to the precise semantics dened in the various contexts, mappings are not dened between the sources and the ontology as it is done in most current approaches to information integration. Instead, mappings are structured with respect to a context model and dened for each modication dimension as a conversion function network. This modularization of mappings allows a mediator to create custom point-to-point translations between contexts by selecting or composing appropriate mappings from the conversion function network.
The utility of our approach, however, would be much more limited if we did not have a methodology to achieve interoperability between applications based on the eCOIN framework. With this study, we described a distinct approach to enabling large scale interoperability through the virtual merging of multiple eCOIN applications. The virtually merged application creates the illusion of a single system that can access sources across domains; accomplishes cross fertilization of contexts and conversion functions; and offers value added benets beyond what the underlying applications can provide.
We have implemented these ideas in a prototype implementation [7] using the Eclipse Prolog engine [5] and procedural programming languages. This prototype provides mediated access to traditional databases, as well as semi-structured web sites, and web services; creates and maintains metadata that are used in eCOIN through graphical interfaces, and supports merging multiple applications. With a working prototype implementation and sound theoretical basis, we claim that eCOIN provides an elegant and effective solution for reconciliation of semantic conicts.
References
1. F. Anwar, Virtual Merging of Ecoin Applications and Guidelines for Building Ontologies, Masters of Engineering Thesis (Massachusetts Institute of Technology, 2004).
2. C. Batini, M. Lenzerini and S.B. Navathe, A comparative analysis of methodologies for database schema integration, ACM Computing Surveys 18(4) (1986) 323364.
3. T. Berners-Lee, J. Hendler and O. Lassila, The semantic web, Scientic American (2001).
4. H. Chalupsky, OntoMorph: a translation system for symbolic knowledge, In Proceedings of Seventh International Conference on Knowledge Representation and Reasoning (Morgan Kaufmann, San Francisco, California, 2000) 471482.
5. A.M. Cheadle, W. Harvey, A.J. Sadler, J. Schimpf, K. Shen and M.G. Wallace, ECLiPSe: An Introduction, Technical Report, IC-Parc Imperial College London (2003).
6. A. Doan, J. Madhavan, R. Dhamankar, P. Domingos and A. Halevy, Learning to match ontologies on the SemanticWeb, The VLDB Journal 12 (2004) 303319.
7. A. Firat, Information Integration Using Contextual Knowledge and Ontology Merging, Ph.D. Thesis, Massachusetts Institute of Technology (2003).
8. A. Firat, S. Madnick and M. Siegel, The Camlon web wrapper engine, In: Proceedings of the VLDB2000 Workshop on Technologies for E-Services (2000) 19.
9. N. Fridman Noy and M.A. Musen, PROMPT: algorithm and tool for automated ontology merging and alignment, AAAI/ IAAI (2000) 450455.
10. C.H. Goh, Representing and Reasoning about Semantic Conicts in Heterogeneous Information Systems, Ph.D. Thesis, Massachusetts Institute of Technology (1997).
11. B. Grosof, Representing E-business rules for the semantic web: situated courteous logic programs in RuleML. In: Proceedings of the Workshop on Information Technologies and Systems, WITS 01 (2001).
12. T.R. Gruber, A translation approach to portable ontology specications, Knowledge Acquisition 5 (1993) 199220.13. A. Halevy, Theory of answering queries using views, ACM SIGMOD Record 29(4) (2000) 4047.
14. A.Y. Halevy, J. Madhavan and P.A. Bernstein, Discovering structure in a corpus of schemas, Data Engineering Bulletin 1 (2003) 2633.
15. Z. Ives, A. Halevy, P. Mork and I. Tatarinov, Piazza: mediation and integration infrastructure for semantic web data, Journal of Web Semantics 1(2) (2004) 155175.
16. M. Kaleem, CLAMP: Application Merging in the Ecoin Context Mediation System Using the Context Linking Approach, Masters of Engineering Thesis, Massachusetts Institute of Technology (2003).
17. M. Lenzerini, Data integration: a theoretical perspective, PODS (2002) 233246.
18. D.L. McGuinness, R. Fikes, J. Rice and S. Wilder, An environment for merging and testing large ontologies, In: Proceedings of the Seventh International Conference on Principles of Knowledge Representation and Reasoning (KR2000) (Breckenridge, Colorado, 2000).
19. G. Miller, WordNet: a lexical database for English, Communications of the ACM 38(11) (1995) 3941.
20. I. Niles and A. Pease, Towards a standard upper ontology, In: Proceedings of FOIS 2001 (Ogunquit, Maine, USA, 2001).
21. R. Pottinger and P.A. Bernstein, Merging models based on given correspondences. In: VLDB Conference (2003).
22. E. Rahm and P.A. Bernstein, A survey of approaches to automatic schema matching, VLDB Journal 10(4) (2001) 334350.
23. S. Reed and D. Lenat, Mapping ontologies into Cyc, AAAI-2002 Workshop on Ontologies and the Semantic Web (2002) http://www.reliant.teknowledge.com/AAAI-2002/Reed.pdf
24. E. Sciore, M. Siegel and A. Rosenthal, Using semantic values to facilitate interoperability among heterogeneous information systems, ACM Transactions on Database Systems (TODS) 19(2) (1994).
25. M. Siegel and S. Madnick, A metadata approach to resolving semantic conicts, In: Proceedings of the Seventeenth International Conference on Very Large Databases (1991) 133145.
26. P. Tan, S. Madnick and K. Tan, Context mediation in the semantic web: handling OWL ontology and data disparity through context interchange, Lecture Notes in Computer Science 3372 (2005) 140.
27. Y. Wand, V. Storey and R. Weber, An ontological analysis of the relationship construct in conceptual modeling, ACM Transactions on Database Systems 24 (1999) 494528.
123
Springer Science+Business Media, LLC 2007