Semantic Interoperability Between Relational Database Systems

Quang Trinh, Ken Barker, Reda AlhajjComputer Science Department

University of CalgaryCalgary, Alberta, Canada

qtrinh, barker, alhajj@cpsc.ucalgary.ca

Abstract

Relational DataBase Systems (RDBSs) are well-knownand widely used in many organizations, however, semanticconflicts between the participating RDBSs must be resolvedbefore data can be exchanged between them. Semantic res-olution between the RDBSs is extremely difficult to addressmainly because participating RDBSs are designed and builtindependently. Furthermore, individual RDBSs are likelyto evolve over time and the changes must be reconciled dy-namically. In this paper, we describe an approach to re-solve the semantic conflicts between RDBSs automaticallywhile allowing the individual RDBSs to evolve. RelationalDataBase Ontology (RDBO) is created and used to ensurethe semantic descriptions of the individual RDBSs are con-formed to a set of vocabularies, structures, and restrictions.We show how a modified reasoning engine is used to val-idate and infer additional semantic relationships from theexisting relationships. We also show how terms defined indifferent database ontologies are compared to each othersemantically using semantic weights and our modified rea-soning engine. As a result, RDBSs can interoperate witheach other seamlessly and at the correct level of semanticsdefined in their ontologies.

1 Introduction

In general, each RDBS is designed to store a particulardata set and is described by the terms commonly used andunderstood by its local users. Since the individual RDBSsare designed and built independently, many challenges arisewhen two or more RDBSs must interoperate with eachother. One of the main challenges is semantic conflict,which include [12]: (i) naming conflict, such as homonymsand synonyms; (ii) generalization and specialization con-flicts; (iii) atomic and composite conflicts; etc. Over thepast two decades, many different approaches have been pro-posed in the literature for resolving the semantic conflicts

between RDBSs. These different approaches, ranging fromresolving the semantic conflict at the data level, schemalevel, and application level, all have two things in com-mon: (i) no deduction of additional semantic relationshipsfrom existing ones; (ii) no mention of semantic comparisonsbetween terms defined in different RDBSs. For example,(a) given “Term A is semantically equivalent to Term B”(denotes by TA ≡ TB) and TB ≡ TC . Previously we can-not derive TA ≡ TC from TA ≡ TB and TB ≡ TC ; or(b) given TA and TB from two different systems, what canwe say about TA and TB? Is TA more general, more spe-cific, or equivalent to TB? Without some semantic refer-ence, no such comparisons can be done.

Other approaches such as the unified global schema andmultidatabase language approaches also have limitations.The unified global schema approach brought with it manychallenges since the individual RDBSs are designed andbuilt independently so it is difficult for them to agree ona single schema. The multidatabase language approachgives users the ability to perform queries across multipledatabases but semantic reconcilations are left to the users toresolve manually.

Recently, motivated by the Semantic Web [1], some ap-proaches make use of ontologies to resolve semantic con-flicts between participating systems [9, 10, 16]. Weihua andShixian [19] presented a layered model approach that com-bined agents and ontologies to address the semantic interop-erability problem in large-scale environments. The modelhas three layers: (i) a syntax layer that deals with syntacticinteroperability; (ii) a semantic layer that deals with seman-tic interoperability; and (iii) an agent layer that deals withinformation interoperability. Suwanmanee et al. [13] pro-pose a mediator-wrapper approach with OWL ontologies toenable semantic interoperability between relational or ob-ject data sources. Each data source is described by an OWLontology and it is assumed that these ontologies are createdmanually. Mappings between ontologies are defined manu-ally and only atomic mappings are mentioned. The media-tor uses the Racer reasoner engine [5] to check for consis-

11th International Database Engineering and Applications Symposium (IDEAS 2007)0-7695-2947-X/07 $25.00 © 2007

tency of the “integrated” ontology and RICE (Racer Interac-tive Client Environment) to allow users to pose queries overthe “integrated” ontology. These approaches can be appliedto RDBSs but no standardization on how RDBS semanticsare described and no semantic comparisons between termsare mentioned.

Similar to the web, semantic conflicts between RDBSsshould be validated and resolved dynamically while allow-ing participating RDBSs to have full control to their data. Inthis paper, we describe an approach to resolve the semanticconflicts between RDBSs using database ontologies and amodified reasoning engine. Database ontologies provide thesemantic information of the participating RDBSs and map-pings between them indicate how data in different RDBSsare related to each other. The modified reasoning engineis used to: (i) compare and rank terms defined in differentdatabase ontologies; (ii) validate relationships or mappingsbetween the related terms defined in different database on-tologies to ensure that they are semantically and correctlystated; (iii) deduct additional semantic relationships fromexisting relationships. The modified reasoning engine car-ries out these operations automatically based on the seman-tic information provided. This enables RDBSs to interop-erate with each other semantically and at the correct levelsof granularity regardless of their structures and how theirsemantic information is stated.

The rest of the paper is organized as follows: Section 2describes the general requirements for enabling semanticinteroperability between RDBSs. Section 3 describes howRDBS semantics are presented while conforming to a stan-dardized structure that supports reasoning. Section 4 de-scribes how semantic mappings are defined between theindividual RDBSs, shared domain ontologies, and sharedglobal ontologies. This section also describes a mappingscheme that supports transformations/translations. Map-pings with translations are necessary for data instances ofconcepts that are semantically the same but defined in dif-ferent formats. Section 5 describes how mappings betweenontologies are validated and compared using a modified rea-soning engine called Pellet. Finally, Section 6 concludes thepaper and provides a brief discussion of the future work.

2 Semantic Interoperability Between RDBSs

In general, semantic interoperability between RDBSs re-quires: (i) a common set of vocabularies and their seman-tic relationships and constraints for describing the RDBSs;(ii) standardized database ontologies that describe the se-mantics of the individual RDBSs; (iii) a set of mappingsstate the semantic relationships between the database on-tologies (hence RDBSs); and (iv) a reasoning engine thatvalidates, compares, and deduce semantic relationships be-tween database ontologies. T-Box and A-Box reasoning

(reasoning about concept definitions and their instances re-spectively) ensure inferences between input ontologies canbe made automatically. Figure 1 shows our framework forenabling semantic interoperability between RDBSs. Thefollowing sections describe our framework in details.

3 Representing RDBS Semantics

Since there are many different types of DataBase Man-agement Systems (DBMSs), a common language for rep-resenting the RDBS semantics is necessary. It is also im-portant that the common language chosen is rich and ex-pressive enough to accommodate the dynamic and hetero-geneous nature of the individual RDBSs. OWL, Web On-tology Language [18], is designed for such purposes so wechoose OWL as the common language for representing theRDBS semantics. Furthermore, a common way of describ-ing the RDBSs in OWL is also needed because without it,different RDBSs are likely to describe themselves differ-ently so it would be difficult to relate, validate, and comparethe semantic definitions of terms defined and used in differ-ent RDBSs. Trinh et al. [14] have described such a com-mon model in OWL called the Relational DataBase Ontol-ogy (OWL-RDBO). OWL-RDBO is a set of common vo-cabularies and their semantic relationships and constraintsfor describing RDBSs. OWL-RDBO preserves the under-lying structural constraints of the RDBSs and guaranteesuser applications work with data instances that conformedto a set of vocabularies and structures. Using the com-mon vocabularies defined in OWL-RDBO, database on-tologies are created for the individual participating RDBSs(see Figure 1). Database ontologies can be created man-ually, however, even for the domain experts, this task canbe error-prone and time-consuming. To ease the burden onusers, we have developed a tool for generating and pub-lishing database ontologies automatically from the meta-data of the RDBSs while maintaining their structural con-straints [15]. The generated database ontologies are in-stances of the OWL-RDBO and are independent of the un-derlying RDBSs they described. Database ontologies arenecessary for a number of reasons: (i) they provide an ex-plicit and common semantic description of the underlyingRDBSs that both human and computers can understand;(ii) there are many existing domain ontologies available thatdatabase ontologies can map to and facilitate the data ex-change with other existing systems; and (iii) there are manyexisting reasoning engines available that can be used tovalidate the semantic mappings between the database on-tologies and to infer additional semantic relationships fromexisting ones. For example, the following OWL mappingstates that the term Employee, a rdbo:Table object,is semantically equivalent to the term Staff in anotherdatabase ontology with the namespace URI of cs:

11th International Database Engineering and Applications Symposium (IDEAS 2007)0-7695-2947-X/07 $25.00 © 2007

Figure 1. A framework for semantic interoperability between the RDBSs.

<rdbo:Table rdf:ID="Employee"><owl:equivalentClass rdf:resource="cs:Staff"/>

</rdbo:Table>

If cs:Staff is not of type rdbo:Table1 thenEmployee and cs:Staff are not equivalent becausethey are not the same type. A database schema can beconsidered as an ontology for a mini-world but it lacksformal semantics and reasoning supports. For exam-ple, umcs:Employee ≡ cs:Staff and cs:Staff ≡cs:Employee then by transitivity, umcs:Employee ≡cs:Employee. Using the database ontologies and a rea-soning engine, such conclusions can be extracted automati-cally from the knowledgebase of the reasoning engine. Wewill describe how this is done in Section 5.

4 Semantic Mappings Between RDBSs

Database ontologies and semantic mappings betweenthem are the key to success for semantic interoperabilitybetween RDBSs. Semantic mappings between the databaseontologies are stated independent of the underlying RDBS’slogical and physical structures so changes can be made tothe underlying RDBS’s structures without effecting the se-mantic relationships between the database ontologies. Se-mantic mappings between the database ontologies can bedefined in three ways [17]:

• between the individual database ontologies.

• between the individual database ontologies and shareddomain ontologies.

• between the individual database ontologies, shared do-main ontologies, and shared global ontology.

1In OWL, owl:Thing is the parent class of all classes, however, wehave explicitly excluded this case when we validate mappings between theontologies.

The first approach is flexible but the main drawbackis there will be a large number of mappings between thedatabase ontologies (i.e., each term in one database ontol-ogy must explicitly map to all other equivalent terms inother database ontologies) [6, 8]. Compared to the firstapproach, the second approach is better in the sense thatshared domain ontologies are used so the number of map-pings between the database ontologies is reduced. A shareddomain ontology is an ontology that describes a set of com-mon terms, properties, and their relationships used in a do-main. Shared ontologies are created by their domain ex-perts. The third approach reduces the number of map-pings between the database ontologies even more since bothshared domain ontologies and a global ontology are used.Similar to a shared domain ontology, a shared global ontol-ogy contains a set of common terms, properties, and theirrelationships agreed and shared by all participants. In ourapproach, mappings can be stated between the database on-tologies, shared domain ontologies, and shared global on-tologies (see Figure 1). Shared global ontology is createdand agreed by experts in the community.

Semantic mappings between the ontologies can be cre-ated manually or semi-automatically as described by Doanet al. [3]. Given any two terms Ti and Tj in any twodatabase ontologies, there are four types of semantic rela-tionships between Ti and Tj :

i. Ti is equivalent to Tj (denoted by Ti ≡ Tj)

ii. Ti is not equivalent to Tj (denoted by Ti 6= Tj)

iii. Ti is a generalization of Tj (denoted by Ti w Tj)

iv. Ti is a specialization of Tj (denoted by Ti v Tj)

The first two relationships are obvious. Generaliza-tion and specialization describe the hierarchy structures inRDBSs. For example, if Employee IS A Person then

11th International Database Engineering and Applications Symposium (IDEAS 2007)0-7695-2947-X/07 $25.00 © 2007

Figure 2. Three approaches of how ontologies can be used for enabling semantic interoperabilitybetween RDBSs (adopted from [17]): (a) mappings between the individual ontologies; (b) mappingsbetween the individual ontologies and shared domain ontologies; (c) mappings between the individ-ual ontologies, shared domain ontologies, and shared global ontologies.

Person is more general than Employee (denoted byPerson w Employee).

Semantic mappings must be defined at both the concep-tual and data levels and OWL supports mappings at bothlevels. Semantic mapping at the conceptual level maps oneconcept to another. A concept is a term or a phrase that isused to represent an object that exists in the real world, thathas certain properties, and that is distinguishable from otherobjects. Similarly, semantic mapping at the data level mapsan instance of one concept to an instance of another con-cept. The following describes how semantic mappings aredefined at both levels.

4.1 Semantic Mappings At The Concep-tual Level

Semantic mappings at the conceptual level state thesemantic relationships between terms defined in differentdatabase ontologies. For example, the mapping:

umcs:last ≡ cs:lastName

states that umcs:last is semantically equivalent tocs:lastName (where umcs and cs are namespace URIsfor two database ontologies). Since they are equivalent, wecan now compare and combine instances of these two termstogether. In this mapping, we assume that both terms aredefined with the same data format (e.g., string) so no ad-ditional work is needed. However, if one of the terms isdefined in a different data format, then in addition to themapping, a translation is also needed before the data in-stances of the two terms can be compared to each other. Forexample, the mapping:

umcs:hiredDate ≡ cs:startDate

states the semantic equivalent betweenumcs:hiredDate and cs:startDate, yet, ifthe formats of umcs:hiredDate and cs:startDateare in short date format (i.e., MM/DD/YYYY) and longdate format (i.e., MM DD,YYYY), then we either need toconvert them to a common format or convert one format tothe other before comparing their instances. This leads usto semantic mappings with translations, which is describednext.

4.2 Semantic Mappings With Transla-tions

Semantic mappings with translations state the semanticrelationships at the conceptual level with one or more trans-lational operations on the data instances of the participatingterm(s). Similar to mappings at the conceptual level, map-pings with translations are defined in the form:

<uri:termi> ≡ uri:=(<uri:termj>)

where uri:= is an aggregate function that applies to the in-stances of its argument and can be provided as a Web Ser-vice. For example, to address the previous date mappingproblem, we can define a mapping with translation as fol-lows:umcs:hiredDate ≡

ws:=Long2ShortFormat(cs:startDate)

where =Long2ShortFormat is an aggregate function pro-vided by the namespace ws: that takes a long date formatand converts it to a short date format. With the translationprovided, instances of the two dates are now in the same for-mat and can be compared to each other. Semantic mappings

11th International Database Engineering and Applications Symposium (IDEAS 2007)0-7695-2947-X/07 $25.00 © 2007

with translations do not state the equivalent relationshipsbetween the data instances. Instead, they state the equiv-alent formats of data instances that belongs to equivalentconcepts. This ensures the same format is used when com-paring data instances of equivalent concepts. Alternatively,if mappings are stated directly between the data instances,they may also include relationships that are not used inthe same context. For example, short format instances forcs:birthdate and cs:startDate are both dates butthey are not used in the same context so they should not becompared to each other.

Semantic mappings with translations can also be usedto address composite/atomic mapping problems. Forexample, we can now define a mapping that mergesfirstName and lastName together and maps the resultto fullName:

fullName ≡ws:=merge(name,“,”,firstName,lastName)

where ws:=merge merges instances of firstNameand lastName together with the token “,” separation.Likewise, we can also define a translational mapping thatsplits a term into multiple terms and maps one of the termsto another. For example, we can define a mapping thatsplits fullName into the two terms first and lastand maps the term last to the term cs:lastName:

ws:=project(last,ws:=split(fullName,“,”, first,last)) ≡lastName

where ws:=split takes fullName and splits it into twoterms based on the “,” token and ws:=project projects outonly instances of the term last.

5 Semantic Mapping Validation and Rank-ing

Semantic mappings between the database ontologiesstate the semantic relationships between the RDBSs theydescribed. However, before they are used, it is necessaryto validate the mappings to ensure they are semanticallycorrect. For example, if the terms cs:Employee andcs:Staff are disjoint from each other, then we cannothave another term that have both of these terms as general-ization. It is also necessary to deduct additional semantic re-lationships from existing relationships between the databaseontologies. This reduces the number of redundant and un-necessary mappings users need to define. For example,given the following mappings:

umcs:Employee ≡ cs:Staffcs:Staff ≡ cs:Faculty

then, by the transitivity property, it is true that:

umcs:Employee ≡ cs:Faculty

Previously, we could not deduct such relationships andthey all have to be defined explicitly. Using a reason-ing engine, we can derive such relationships automaticallyfrom the knowledgebase and there is no need for usersto define such mappings. Alternatively, without using areasoning engine, such mappings must be stated explic-itly. Similarly, other properties such as functional prop-erty, inverse functional property, symmetric property, etc.are all supported and can be used to derive additional re-lationships from existing ones. It is also necessary to beable to compare the semantics of terms defined in differentdatabase ontologies. For example, given the three ontologyhierarchies in Figure 3 and the mappings defined betweenumcs:Faculty and Professor and Employee andcs:Staff, can we define an equivalent mapping betweenumcs:TeachingStaff and cs:Lecturer? Beforewe can do so we first need to compare the semantics of thesetwo terms based on the semantics provided. We will showhow this is addressed later using semantic weights.

Manual validation, deduction, and comparison of map-pings between the database ontologies is extremely difficultif not impossible. We have modified a reasoning enginecalled Pellet (version 1.3) to automate the validations, de-ductions, and comparisons of semantic mappings betweenontologies. Pellet supports both reasoning over the termi-nologies (TBox) and their instances (ABox) (see Figure 1).TBox and ABox reasoning ensure concept definitions andtheir instances are consistent. Pellet generates a semanticknowledgebase automatically from the input ontologies andtheir semantic mappings. We then query the knowledgebasefor relationships that are stated explicitly and those derivedfrom the existing relationships. If Pellet produces “clashes”for a relationship, then the relationship does not entail orfollow from the semantic information in the knowledge-base. Alternatively, if Pellet does not produce “clashes”,then the relationship is consistent with the semantic infor-mation provided.

Comparing between terms defined in different databaseontologies requires a quantitative measurement of the se-mantic relationships between terms. This measurement in-dicates how far or close two terms are to each other seman-tically. We refer to this the quantitative measurement assemantic weight. Table 1 shows the semantic relationshiptypes and their corresponding semantic weights. A weightof 1.0 means the two terms are semantically the same (i.e.,they have the same intensional meaning). Alternatively, aweight of 0 means the two terms are not equivalent to eachother. Finally, a weight of 1-0.1dlog(h)e means one termis more generalized than the other (where h is the height ofthe ontology tree).

11th International Database Engineering and Applications Symposium (IDEAS 2007)0-7695-2947-X/07 $25.00 © 2007

Figure 3. Three sample database ontology trees.

In general, the semantic weight of any two terms termi

and termj is calculated as follows:

weight(termi, termj) = (1− 0.1dlog(h)e)k

where k is the height differences in the same gener-alization/specialization hierarchy path between termi

and termj . If the two terms do not share the samegeneralization/specialization path, then their seman-tic weight is 0.0 since they do not participate in ageneralization/specialization relationship. The value1-0.1dlog(h)e is chosen for the generalization relationshipbecause (1-0.1dlog(h)e)k shows a slow linear decreaseas k increases. This implies the more specialized aterm is, the further away it is from its generalization.Castano et al. [2] used 0.8 as the weight for general-ization/specialization relationships but this value is nota good value because as k increases, (0.8)k convergesvery quickly to 0. For example, since the height of themiddle ontology tree in Figure 3 is 4, the generalizationweight of any two terms is 0.9 (i.e., 1-0.1dlog(4)e). Thus,weight(Person,Employee) is 0.9 since Personis a direct generalization of Employee. Similarly,weight(Person,FullProfessor) is 0.729 be-cause:

weight(Person,Employee) = 0.9weight(Employee,Professor) = 0.9weight(Professor,FullProfessor) = 0.9

and

weight(Person,FullProfessor)=0.9*0.9*0.9=0.729

To evaluate whether or not we can define a mappingbetween umcs:TeachingStaff and cs:Lecturermentioned in the previous example, we first evaluate and as-sign semantic weights to the existing semantic relationshipsthat relate umcs:TeachingStaff and cs:Lecturer.From Figure 3, starting with umcs:TeachingStaff,we derive the following semantic weights:

Relationships Semantic Weightsequivalent 1.0

not equivalent 0.0generalization 1-0.1dlog(h)e

Table 1. Semantic relationships and their se-mantic weights (where h is the height of theontology tree).

weight(umcs:Faculty,umcs:TeachingStaff) = 0.9weight(umcs:Faculty,Professor) = 1.0weight(Employee,Professor) = 0.9

andweight(Employee,umcs:TeachingStaff)=0.9*1.0*0.9

Similarly, starting with cs:Lecturer, we derive thefollowing semantic weights:

weight(cs:Staff,cs:Lecturer) = 0.9weight(cs:Staff,Employee) = 1.0

and

weight(Employee,cs:Lecturer) = 0.9*1.0 = 0.9

Since Employee is the common general-ization in the same hierarchy path for bothumcs:TeachingStaff and cs:Lecturer,we compare their semantic weights with respect toEmployee. According to the semantic weights calcu-lated, weight(Employee,umcs:TeachingStaff)is 0.81 and weight(Employee,cs:Lecturer)is 0.9 thus we can conclude thatumcs:TeachingStaff and cs:Lecturer donot have the same semantic granularity so an equivalentmapping should not be defined between them. The se-mantic weight function added to Pellet is described inAlgorithm 5.1.

The weights calculated by the three update functions areaccumulative. Initially, weights are set to a value of 1 andwhen the conditions are satisfied, Pellet updates the weights

11th International Database Engineering and Applications Symposium (IDEAS 2007)0-7695-2947-X/07 $25.00 © 2007

Algorithm 5.1 (Semantic Weight Calculation)Input:

domain ontology DOontology O1ontology O2a list of mapping statements stmts between O1, O2, and DO

Output: a list of semantic weights added the input stmts

1 build knowledgebase KB from DO, O1, and O22 check KB for consistency3 if not consistent, exit4 for each statement st in stmts do5 check satisfiability of st6 unfold Ti and Ts to use only primitive T’s7 if Ti is a subclass of Tj then8 update_subclass_weight(Ti, Tj)9 if Ti is equivalent to Tj then10 update_equivalent_weight(Ti, Tj)11 if Ti is disjoint from Tj then12 update_disjoint_weight (Ti, Tj)13 end for

according to their semantic weights.

6 Conclusion and Future Work

RDBSs are designed and built independently. Databaseontologies provide standardized and semantic descriptionsof the underlying RDBSs. Semantic mappings between thedatabase ontologies and/or shared ontologies enable seman-tic interoperability between the RDBSs described by thedatabase ontologies. Mappings between ontologies can bedefined manually or semi-automatically and validation isnecessary to ensure their correctness. Semantic comparisonof concepts defined in different ontologies is also necessarybecause mappings with different granularity are possibleand we want to be able to detect such such mappings. Man-ually validate and compare mappings is not the solution.In this paper, we modified the Pellet reasoning engine andshowed how it can be used to validate and compare map-ping between ontologies automatically. The result ensuresRDBSs interoperate with each other at the correct level ofsemantics regardless of how the individual RDBSs are con-structed. Using a reasoning engine, such as Pellet, also hasother advantages such as: (i) additional mappings can be de-duced from existing mappings thus reducing the number ofunnecessary and redundant mappings users need to define;(ii) when new mappings are added, the new knowledge isadded automatically to the knowledgebase by the reasoning

engine there is no additional work required.In the future, we would like to investigate the following:

(i) apply the semantic weight concept to the three reasoningengines RACER [4], KAON2 [7], and OWLJessKB [11]and compare their results with that produced by Pellet.Regardless of their implementation, the results producedshould be based on the semantics; (ii) semantic mappingsbetween ontologies are the key to enable semantic interop-erability between systems. Mapping management betweenontologies must be managed dynamically since evolutionsof the individual RDBSs must be supported. We plan to as-sociate contracts with mappings and use a shared memorymodel to manage semantic mappings between ontologies.This allows mappings to be added or removed dynamically.

References

[1] T. Berners-Lee, J. Hendler, and O. Lassila. The SemanticWeb: A New Form of Web Content that is Meaningful toComputers Will Unleash a Revolution of New Possibilities.Scientific American, (51), May 2001.

[2] S. Castano, A. Ferrara, S. Montanelli, and G. Racca. Seman-tic Information Interoperability in Open Networked Sys-tems. In Proceedings of Int. Conference on Semantics of aNetworked World (ICSNW), in cooperation with ACM SIG-MOD, pages 215–230, Paris, France, June 2004.

[3] A. Doan, J. Madhavan, P. Domingos, and A. Halevy. Learn-ing to Map Between Ontologies on the Semantic Web. In

11th International Database Engineering and Applications Symposium (IDEAS 2007)0-7695-2947-X/07 $25.00 © 2007

WWW ’02: Proceedings of the eleventh international con-ference on World Wide Web, pages 662–673, New York, NY,USA, 2002. ACM Press.

[4] V. Haarslev and R. Moller. Racer: A Core Inference Enginefor the Semantic Web. In EON, 2003.

[5] V. Haarslev and R. Moller. Racer: An OWL Reason-ing Agent for the Semantic Web. Proc. of the Interna-tional Workshop on Applications, Products and Servicesof Web-based Support Systems, in conjunction with 2003IEEE/WIC International Conference on Web Intelligence,Halifax Canada, pages 91–95, October 2003.

[6] A. Y. Halevy, Z. G. Ives, D. Suciu, and I. Tatarinov. SchemaMediation in Peer Data Management Systems. In Pro-ceedings of International Conference on Data Engineering,March 2003.

[7] KAON2. http://kaon2.semanticweb.org. December 2006.[8] N. F. Noy. What Do We Need for Ontology Integration

on the Semantic Web (Position Statement). In Proceedingsof the Semantic Integration Workshop, Collocated with theSecond International Semantic Web Conference (ISWC-03),volume 82, October 2003.

[9] N. F. Noy. Semantic Integration: A Survey of Ontology-Based Approaches. SIGMOD Record, 33(4):65–70, 2004.

[10] N. F. Noy and D. L. McGuinness. Ontology Development101: A Guide to Creating Your First Ontology. TechnicalReport Stanford Knowledge Systems Laboratory TechnicalReport KSL-01-05 and Stanford Medical Informatics Tech-nical Report SMI-2001-0880, Stanford University, March2001.

[11] OWLJessKB. http://edge.cs.drexel.edu/assemblies/software/-owljesskb. December 2006.

[12] E. Pitoura, O. Bukhres, and A. Elmagarmid. Object Orien-tation in Multidatabase Systems. ACM Computing Surveys,27(2):141–195, 1995.

[13] S. Suwanmanee, D. Benslimane, and P. Thiran. OWL-BasedApproach for Semantic Interoperability. In AINA, pages145–150. IEEE Computer Society, 2005.

[14] Q. Trinh, K. Barker, and R. Alhajj. RelationalDatabase Definition in Web Ontology Language. Avail-able at http://white.cpsc.ucalgary.ca/ontologies/rdbo/, Au-gust 2005.

[15] Q. Trinh, K. Barker, and R. Alhajj. RDB2ONT: A Tool forGenerating OWL Ontologies From Relational Database Sys-tems. Advanced International Conference on Telecommuni-cations (AICT 2006), February 2006.

[16] M. Uschold and M. Gruninger. Ontologies and Semanticsfor Seamless Connectivity. SIGMOD Record, 33(4):58–64,2004.

[17] H. Wache, T. Vogele, U. Visser, H. Stuckenschmidt,G. Schuster, H. Neumann, and S. Hubner. Ontology-Based Integration of Information - A Survey of ExistingApproaches. In H. Stuckenschmidt, editor, IJCAI-01 Work-shop: Ontologies and Information Sharing, pages 108–117,2001.

[18] Web Ontology Language (OWL).http://www.w3.org/2004/owl. December 2006.

[19] L. Weihua and L. Shixian. Improve the Semantic Interoper-ability of Information. 2nd IEEE International Conferenceon Intelligent Systems, 2:591–594, June 2004.

11th International Database Engineering and Applications Symposium (IDEAS 2007)0-7695-2947-X/07 $25.00 © 2007