semantic data integration in hierarchical domainsifc/papers/ieee-is-066-073.pdf · ata integration...

66 1094-7167/03/$17.00 © 2003 IEEE IEEE INTELLIGENT SYSTEMSPublished by the IEEE Computer Society

T h e S e m a n t i c W e b

Semantic DataIntegration inHierarchical DomainsIsabel F. Cruz and Afsheen Rajendran, University of Illinois at Chicago

D ata integration is a central issue within Semantic Web research, especially when

it comes to developing standards and techniques that facilitate data integration

without user intervention.1 This sort of integration could have wide-ranging applicabil-

ity in data-intensive applications such as search engines, data mining systems,

and data warehousing. A chief requirement of dataintegration systems is that the differences in the syn-tax and semantics of the underlying data sourcesshould be hidden from the user.2–5 However, datasources are often independently created and do noteasily interoperate with other sources.

The rise of XML as a data interchange standardhas led to a new era in which research has focusedon semistructured data.6 Although XML has pro-vided a single interchange format, different userscan model the same data in different ways, whichcan lead to heterogeneities at various levels, includ-ing the semantic level. Semantic heterogeneitiescan arise from entities being perceived differently.For example, an agricultural expert perceives water-ways to be a source of irrigation, while a trans-portation expert perceives them as a mode of trans-portation. Such perceptual differences manifestthemselves as heterogeneities in the data modelsthese experts develop. These differences cannot beresolved without knowledge of the models of theunderlying disciplines.

Statewide geographic information applicationsprovide for an application domain whose need fordata integration is compelling, especially if the datamaintained by hundreds of autonomous governmentagencies is to be accessed uniformly. Geographicdata is usually hierarchically organized. For example,counties contain municipalities, and wards containprecincts. However, different agencies use differenthierarchies for representing data. So, the problem ishow to handle the different classification schemesand the different types of relations between entities,

within the constraints imposed by the semantics ofthe data usage.7

This article describes one approach for handlingsemantic data integration problems in hierarchicaldomains. It also describes a declarative approach forspecifying pairwise mappings between a centrallymaintained ontology and each local data repositorymaintained by an autonomous agency. In this con-text, we outline a method for specifying the map-pings’ semantics and encoding them to resolve het-erogeneities. We focus on XML-based applicationsin which entities in the centrally maintained ontologyare hierarchically related to those in the local datarepositories. We have implemented and successfullytested our approach in two different real-world appli-cations: one involves querying the results of the USpresidential election and the other involves queryinga state’s land use patterns.

Data integration systemsData integration systems must have components

for handling the mappings between entities in aglobal schema (called the ontology) and the localdata sources. These systems must also have compo-nents for processing user queries expressed on theglobal schema.8 Typically, data integration systemsconvert the queries into subqueries expressed interms of the entities in the local data sources usingthe mappings defined between the entities. After han-dling the differences in representation, the systemmerges the results of the subqueries and then dis-plays those results to the user.

Generally, there are two approaches for specifying

A major challenge in

building the Semantic

Web is resolving

differences among

heterogeneous

databases. This article

outlines an XML-

oriented approach to

resolve semantic

heterogeneities.

the mappings between the global schema andthe local data sources. The global-as-view(GAV) approach associates every entity inthe global schema with a view of the datasources. This approach ties the meaningassociated with the entity to the local data.The local-as-view (LAV) approach definesthe sources as views over the global schema.This approach specifies the global schemaindependently from the sources.

In the LAV approach, you can easily main-tain and extend the system. When you needto add a new source, you need only to pro-vide its definition without changing theglobal schema. In the GAV approach, systemmaintenance is more difficult. Adding a newsource might require changing the definitionof the entities in the global schema, but thequery-processing techniques in the LAVapproach are more sophisticated than in theGAV approach.8

We prefer a local-as-view approach becauseit gives us the ability to add or update newlocal data sources with minimal effort. In par-ticular, we do not need to combine answersfrom different data repositories to produceresults for a particular region. For example, inour election results application (described inmore detail later), each local data repositoryis queried on the votes for a particular candi-date, and each repository will return its ownvotes for that candidate, as associated with thatparticular geographic region.

In our case, the complexity of answeringthe queries is related to the semantic con-nections that must be established betweenthe different classification hierarchies, whichwill drive the querying process between theontology and the local schemas. An expertteam, which develops the ontology, knowsthe application domain but is unaware of thelocal data sources’organization. Local expertsdevelop the mappings between the ontologyand the local data repositories.

The data collected by an agency might addlevels of classification to those already in theglobal schema, reflecting the agency’s pri-mary area of interest. For example, a countywhose main occupation is agriculture willhave more categories of agricultural land usethan the global schema drawn up for thestate. Such differences in data resolution canbe handled by storing that information in theontology. Such an approach departs from apure LAV approach because the team ofexperts integrates information from the localrepositories into the ontology to improve thequery answers.

Ontologies and agreementdocuments

Because an ontology serves as the com-mon source of understanding and as the basisfor providing interoperability, it is indepen-dent from its representation in the domain.Our approach employs hierarchical ontolo-gies, which it represents as XML documents.Information about the differences in hierar-chies and types of relationships between twohierarchies are stored in XML documentscalled agreement documents. Each local datarepository has a corresponding agreementdocument that acts as a wrapper.

We represent the relationships betweenequivalent hierarchy entities as mappings.One key responsibility of the local experts isto identify the types of mappings needed tomap the entities in the ontology to those inthe local data repository. To maintain a uni-form query interface, the ontology’s entitiesmust be mapped to equivalent entities in thelocal data repository. The mappings fallbroadly into these types:

• One-to-one. The entity in the ontologyhas an equivalent entity in the local datarepository.

• One-to-null. The entity in the ontology hasno equivalent entity in the local data repos-itory. User queries for this entity cannotbe supported.

• Parent–children. The entity in the ontol-ogy is equivalent to a collection of entitiesfollowing a parent–children relationship.In this case, only the parent entity must bemapped to the corresponding entity. Thismapping type uses the information aboutthe hierarchy to simplify mappings byallowing just one entity to be mappedinstead of a collection of entities.

• One-to-many. The entity in the ontologyis equivalent to a collection of entities inthe local data repository. The entities inthe collection do not follow a parent–children relationship.

• Many-to-one. The entity in the local datarepository is equivalent to a collection ofentities in the ontology. The entities in thecollection do not follow a parent–childrenrelationship.

In our election results application, we iden-tified the one-to-null and parent–childrenmappings. In the hierarchy for the state of Illi-nois election results, the municipality entity doesnot exist, which means that no equivalentexists for that ontological entity. The map-ping type chosen for that match is one-to-null(see Figure 1).

While Illinois does not have municipalities,the municipality entity exists in the state of Wis-consin hierarchy. In addition, each munici-pality can have multiple ward group entitiesbelow it in the hierarchy. We mapped the onto-logical entities state, county, and municipality totheir equivalent one-to-one entities in the Wis-consin hierarchy. A municipality and its con-stituent ward groups follow a parent–childrenrelationship, so we chose the parent–childrentype (see Figure 2).

Representing information about a local datarepository’s hierarchy in XML is relativelystraightforward. However, representing themappings between equivalent entities in theontology and the local data repository is morecomplicated. We use XPath expression tem-plates (described later) for this purpose.

Query processingWhen we want to access and manipulate

the data in an XML document, we use the

MARCH/APRIL 2003 computer.org/intelligent 67

One-to-null mapping

One-to-one mapping

State

County County

Illinois hierarchy

State

County County

Municipality Municipality

Ontology

Figure 1. The one-to-null mapping type.

Document Object Model. When we load anXML document using a DOM-compliantparser, the system returns a DOM tree (seeFigure 3). You can create, access, or modifyDOM trees within an application using func-tionality provided by open-source classlibraries. A separate document, called the

Document Type Definition (DTD), specifiesinformation about the hierarchy and the typesof entities in the XML document.

A DOM tree represents the entire XMLdocument. Each node in the tree represents acorresponding element in the document. Forquerying an XML document, we need a mech-anism to select only the nodes of interest fromthe DOM tree. XPath is a W3C specificationdeveloped for this purpose. It provides a wayto express a path through a document tree toselect a set of nodes (see Figure 4).

XPath’s addressing mechanism is similarto that used by file systems. For example, theXPath expression “state/county” selects thecounty nodes under a state. The XPath

expression state[@name=‘Illinois’]/county selectsthe county nodes under Illinois—that is, thecounties of Adams and Cook in the XMLfragment in Figure 5.

The system expresses the user query interms of the entities in the ontology. It thensplits the user query into a subquery for eachlocal data repository, which it expresses interms of local entities. The system uses theagreement document information about themappings between equivalent entities for thequery-rewriting process.

Each entity in the ontology has a corre-sponding XPath expression template. Thetemplate encodes the mapping between theontological entity and the equivalent entitiesin the local data repository. We classifiedthese mappings into five different types andencoded each type using a different type ofXPath expression template. An XPath ex-pression template contains the XPath expres-sion with placeholders for the arguments.The user supplies the arguments when sub-mitting a query. The system substitutes thesearguments in the template to obtain theappropriate XPath expression (see Figure 6).

The system then executes the XPathexpression against the XML documents inthe local data repository. The system returnsthe DOM nodes, which are equivalent to theontological entities of interest specified inthe user query. When the system executes anXPath expression, it returns the result in theform of textual data. Using information aboutthe data type, the system can perform addi-tional processing on this textual data. Forexample, in the case of integers, the usercould perform integer-specific operations.

XPath expression templates anduser interface

The Apache Xalan XPath API provides aset of classes for handling XML documentsas DOM objects and for executing XPathexpressions on those objects. We developeda framework of Java classes using the XalanXPath API classes. The XPath expressiontemplates can be either specified statically inthe agreement document or constructeddynamically using knowledge about the dif-ferent schemas and the entity of interest inthe user query.

Executing an XPath expression involvestraversing the levels in the local hierarchy.When only a fixed number of levels are to betraversed for finding the equivalent entitiesof any ontological entity, you can specify theXPath expression template statically.

68 computer.org/intelligent IEEE INTELLIGENT SYSTEMS


Figure 4. XML data fragment used toillustrate XPath expressions.

<state name=“Illinois”><county name=“Adams”><county name=“Cook”></state>

XPath expression

DOM tree

Apache XalanXPath API Selected DOM nodes

Figure 5. The querying process.

XML documenttype definition

XML document

Document Object Model-compliant parser

DOM tree

Figure 3. The parsing process.

Municipality MunicipalityOne-to-onemapping

One-to-one mapping

State

County County

Wisconsin hierarchy

Parent–children mapping

State

County County

Municipality Municipality

Ontology

Wardgroup WardgroupWardgroup

Figure 2. The parent–children mapping type.

In our election query application, we spec-ified the XPath expression templates staticallyin the agreement document. A state containscounties, each containing municipalities. Thishierarchy results in a fixed number of levelsto traverse for finding the equivalent entities.If the number of levels to be traversed is notfixed—as in our land-use-query applica-tion—the XPath expression template must beconstructed dynamically when the query issubmitted.

In either case, the system displays theresults that the query-processing componentcollected from the local data repositories.Given the data’s geographic nature and theneed for its remote access, we designed theuser interface using interactive maps in aWeb browser. To implement the user inter-face, we used Axiomap9 for publishing inter-active maps on the Web.

Application one: Election resultqueries

We designed our first application to helpusers browse the 2000 US presidential elec-tion results collected from different states andcategorized according to various counties,municipalities, and other units. To analyzethe election results at the national level, thesystem must retrieve data from differentstates and present it to the user in a commonformat. However, each state stores its elec-tion results using different levels of resolu-tion. For example, Wisconsin stores its datafor state, county, municipality, and wardgroup, while Illinois stores its data for onlystate and county. We downloaded results forthe US presidential elections from the offi-cial Web sites maintained by the differentagencies. Figure 7 shows a fragment of theIllinois election results.

The entities of interest in the ontologyinclude state, county, municipality, and candidate.Each of these entities has a name attribute. Thecandidate entity has the additional attributevotes, which indicates the votes that each can-didate secured. A state consists of severalcounties, each of which can have severalmunicipalities. Each municipality has a setof candidates. The XML DTD in Figure 8represents the ontology.

The local data repositories of all states havethe state and county entities in their hierarchy.The differences arise in the organization ofsmaller geographic entities such as munici-palities, precincts, ward groups, and wards.When the system calculates the total numberof a candidate’s votes, it specifies the XPath

expression template in the agreement docu-ment. As we mentioned before, this specifi-cation is static because it is the same for allcounties. It depends only on the general rela-tion between the county entities in bothschemas and does not change with the spe-

cific value of the county of interest. The sys-tem passes the entities’ names as argumentsto the XPath expression template. For exam-ple, the system uses the XPath expressiontemplate of Figure 9 to query all the candi-dates within a given municipality in a given


Figure 9. The XPath expression template to query all the candidates in a given municipality in a given county in Wisconsin.

<xpath-expr>/child::state[attribute::name=’Wisconsin’] \

/child::county[attribute::name=’$county_name’] \/child::municipality[attribute::name=’$municipality_name’] \/child::*

</xpath-expr>

Figure 8. The XML DTD representation of the election ontology.

<!ELEMENT state (county+)><!ELEMENT county (municipality+)><!ELEMENT municipality (candidate+)><!ELEMENT candidate EMPTY>

<!ATTLIST state name CDATA #REQUIRED><!ATTLIST county name CDATA #REQUIRED><!ATTLIST municipality name CDATA #REQUIRED><!ATTLIST candidate name CDATA #REQUIRED

votes CDATA #REQUIRED>

Figure 7. A fragment of the XML document containing the election results for Illinois.

<state name=“Illinois”><county name=“Adams”>

<candidate name=“Gore” votes=“12197”/><candidate name=“Bush” votes=“17331”/><candidate name=“Nader” votes=“371”/><candidate name=“Buchanan” votes=“140”/><candidate name=“Browne” votes=“63”/><candidate name=“Hagelin” votes=“7”/><candidate name=“Phillips” votes=“0”/><candidate name=“McReynolds” votes=“0”/><candidate name=“Total” votes=“30109”/>

</county>…</state>

Figure 6. Substituting arguments in the XPath expression template.

XPath expressiontemplate

Agreementdocument

User query XPath expressionArguments

Provides

county in Wisconsin. The arguments to bepassed from the user query are the names ofthe county (county_name) and municipality(municipality_name).

We identified some common user queries,including “List the candidates who competedin a given state or county or municipality”and “How many votes did a given candidate

get in a given state or county or municipal-ity?” The system uses the getCandidateNames andgetVotesByCandidate operations (see Figure 10)to answer these queries. Candidate namesand votes are of types string and integer, respec-tively. Aggregation operations for strings andintegers are different and are specified usingthe sset and isum operations.

As we mentioned earlier, interactive mapsin a Web browser serve as the user interface.Initially, the system shows the user a pagewith selectable state areas. When the userselects a state, the browser directs the user toan analysis of its election results. In the mapof Illinois in Figure 11, the system displaysthe number of votes that George W. Bushreceived relative to the total number of votes.

Application two: Land usequeries

The Wisconsin Land Information Systemis a proposed distributed Web-based systemwith heterogeneous data on local and stateservers. WLIS has to integrate data acrossjurisdictions by overcoming the syntactic andsemantic heterogeneities that result fromusing different coding conventions in differ-ent data repositories. Table 1 shows two landuse classification schemes.

A typical query—such as “Where are allthe crop and pasture lands in Dane Coun-ty?”—would be relatively straightforwardwhen using one data set but more difficultwhen posed over a larger geographic area.Table 2 illustrates the heterogeneity of at-tribute names and values that would satisfythe criteria of the query over selected multi-ple data sets. Lucode, Tag, Lu1, and Lu_4_4 mustbe resolved as synonyms for the attribute thatrepresents the land use code in the ontology.Also, the Racine County data repository usestwo land use codes for denoting croplands,while other counties use only one.

In land use data, the entities of interest areland and owner. Figure 12 shows sample XMLdata about a land parcel and its owner. Landparcel data for Dane County in Wisconsin is stored digitally and can be accessed on the Web (http://wisclinc.state.wi.us/datadisc/orgmetabl1.html). Our land parcel data con-tains an identification number for the parcel(lid), the category of land use under which itis classified (lucode), the file containing the per-tinent shape information (shape_file), and infor-mation about the parcel’s owner (owner_id).Owner data usually contains the owner’sname (name), date of birth (dob), social securitynumber (ssn), and gender (gender).



Figure 11. A map displaying election results for Illinois.

Table 1. Two land use classification schemes.

Exhaustive model Hierarchical model

009 Shopping center 1 Urban and developed land

010 Open water 1.01 Residential

111 Single family 1.01.01 Single-family detached or duplex

113 Two family 1.01.02 Mobile homes not in parks

116 Farm unit 1.01.03 Multifamily dwellings

140 Mobile home 1.01.03.01 Three-unit multifamily

1.01.03.02 Four-unit multifamily

Figure 10. Aggregation operations.

<operation name=’getCandidateNames’ aggregation=’sset’>

<body>child::candidate/attribute::name

</body></operation>

<operation name=’getVotesByCandidate’ aggregation=’isum’>

<parameter><name>$candidate_name</name>

</parameter>

<body>child::candidate[attribute::name=’$candidate_name’] \/attribute::votes

</body></operation>

The election ontology’s entities of interestinclude database, table, tuple, attrname (attributename), and attrvalue (attribute value). Each ofthese entities has an id attribute. The attrvalueentity has the additional attribute expansion,which indicates the meaning associated withthe predefined attribute value.

A database consists of tables, which con-sist of tuples. A tuple consists of a series ofattrname entities, each of which might havepredefined values. Our chosen organizationof the entities in the ontology is similar to theframe-based notation that XOL uses.10 Werepresent the ontology as an XML DTD (seeFigure 13). A typical land tax database sys-tem will have tables for land and for person.

As Figures 8 and 13 illustrate, the repre-sentation of the ontology for the land useapplication differs from that for the electionresults application. DTD elements that rep-resent entities in the ontology for the presi-dential results correspond to the real-worldentities of state and county in the problemdomain. However, DTD elements for theland use application do not correspond toentities in the problem domain but to entitiesin a database schema, which we use to orga-nize the problem domain. We made this deci-sion to maintain the application’s extensibil-ity and to keep the hierarchy simple.

A simple land tax system contains infor-mation about land and people. But a morecomplicated system will have additional lev-els of information. Adding a separate entity,say tax, into an application in which the DTDrepresents database entities is simple. It sim-ply involves adding an instance of table. If theDTD represents real-world entities, we willhave to change the DTD each time we wantto add a new entity.

In the land_use_information table, the land_use_code attribute has a set of predefined values.

Representing each of these values as a sepa-rate entity clutters up the DTD without addingmeaningful information. To keep the hierar-chy simple, we represented the ontologicalland use codes in a separate document (see Fig-ure 14). We used this document to resolve thedifferences in the land use coding conventions.

Each data repository might have a dif-ferent organization of the attribute valuesdepending on the primary function of theagency maintaining it. For example, a countywhere agriculture is the main occupation willhave more categories of agricultural landthan are in the state’s ontology. When wemap entities in the local data repository tothose in the ontology, we might sacrifice dataresolution to ensure conformance with amore general concept in the ontology. Ourapproach includes a facility for storing thedifferent types of classification in the ontol-ogy to let us map local data repositories with-out losing data resolution.

For example, based on its function, we canclassify commercial land use as commercial salesand commercial service in one local data reposi-tory and as commercial intensive and commercial non-intensive in another data repository. If theontology supports only one type of classifi-cation, data in the other data repository mustbe aggregated into a single category. Our

approach makes it possible to preserve theresolution of data available in the local datarepositories.

The local data repositories of all stateshave tables corresponding to land and personentities in their hierarchy. The differencesarise in the syntax and the land use codingconventions. For example, in Dane County’shierarchy, the land use codes 35 and 36 rep-resent Scientific instruments and Miscellaneous indus-trial, respectively. But the ontology does nothave a separate land use code for Scientific instru-ments, so our system maps the collection of 35and 36 to the ontological entity OIO, whichrepresents Industrial - Others (see Figure 15).

The simplest mapping between entitiessuch as database, table, tuple, and attribute in theontology and those in the local data reposi-tory is one-to-one. Each entity’s local equiv-alent is specified in the equiv attribute of thetag representing the entity. For example, theequivalences of the land_use_information tableto the tbl_land table and the land_id attributename to the lid attribute name are specified inthe agreement document as

<table id=“land_use_information” mapping=“one-to-one” equiv=“tbl_land”><attrname id=“land_id” mapping=“one-to-one”equiv=“lid” />


Figure 13. The XML DTD representation of the land use ontology.

<!ELEMENT database (table+)><!ELEMENT table (tuple+)><!ELEMENT tuple (attrname+)><!ELEMENT attrname (attrvalue*)><!ELEMENT attrvalue (attrvalue*)>

<!ATTLIST database id CDATA #REQUIRED><!ATTLIST table id CDATA #REQUIRED><!ATTLIST tuple id CDATA #REQUIRED><!ATTLIST attrname id CDATA #REQUIRED><!ATTLIST attrvalue id CDATA #REQUIRED

expansion CDATA #REQUIRED>

Table 2. Heterogeneity of attribute names and values.

Planning authority Attribute Land use code Description

Dane County Regional Lucode 91 Cropland pasturePlanning Commission

Racine County (Southeastern Tag 811 Cropland pastureWisconsin Regional Planning 815 Other agricultureCommission)

Eau Claire County Lu1 AA General agriculture

City of Madison Lu_4_4 8110 Farms

Figure 12. Sample land use data.

<farm><lid> lid21 </lid><lucode> OA </lucode><shape_file> 100 </shape_file><owner_id> 124-45-5678 </owner_id>

</farm><owner>

<name> John Doe </name><dob> 12-30-1977 </dob><ssn> 124-45-5678 </ssn><gender> M </gender>

</owner>

On the other hand, an ontology attributevalue can map to a single value or a collec-tion of attribute values in the local data repos-

itory. In some cases, multiple attribute val-ues in the ontology can map to the same localattribute value. The specification of the rela-

tion between the entities in both schemas interms of XPath expression templates was suf-ficient for querying the local data reposito-ries in the election results application. But inthis application, we had to construct theXPath expression templates on the fly ac-cording to information not specified in theagreement document.

The relation between entities such as data-base, table, tuple, and attrname is simple becausethey always occur at the same level in theclassification scheme. But the relation be-tween the attrvalue entity in both schemas iscomplex because the attribute values in alocal data repository are grouped into differ-ent levels in the classification scheme. Thenumber of levels to traverse for executing theuser query on a land use code of interestdepends on the level of nesting where thatland use code occurs in the classificationscheme. Therefore, we had to construct XPathexpression templates dynamically.

This application’s query interface differsfrom that of the election results applicationbecause there are no predefined queries. Theuser must be able to select some attributes fromthe tables in the database and specify con-straining values for those attributes. Initially,the system shows the list of available localdatabases. The user selects the databases to bequeried and then specifies the query in terms ofthe attribute names and values in the ontology.The system collects the results from all theselected databases and then displays them tothe user in the form of interactive maps.

In Figure 16, the browser interface showsa small region of Dane county and the differ-ent land use codes. When the user selects aland use code in the left frame, the systemhighlights all land parcels in that region thatfall under that classification. For example, inFigure 16 the user wants to find all parcelswhose land use code is Agriculture: Croplandand Pasture. The system has highlightedParcels P1 and P7, which fall under that clas-sification. The user can learn more about a par-ticular parcel by selecting it to open a pop-upwindow that displays additional information.

There are several areas for future work.XPath lets users traverse a linear path

while collecting data from an XML docu-ment. But XPath does not support morecomplex mapping types, such as many-to-many. In addition, the data collected after theexecution of an XPath expression is in the



One-to-manymapping

One-to-one mapping

Land Use Code

Agriculture(91–99)

Dane County hierarchy

Land Use Code

Agriculture (OA) Industrial (OI)

Manufacturing (OIM) Others (OIO)

Ontology

Code Explanations:35—Scientific instruments36—Miscellaneous industrial21—Food and kindred22—Textile and mill

Industrial (21–39)

3635 21 22

Figure 15. The one-to-many mapping type.

Figure 14. Predefined values of the land use code attribute.

<database id=“ontology”>...<table id=“land_use_information”><tuple id=“land”>

<attrname id=“land_id”/><attrname id=“land_use_code”>

<attrvalue id=“OC” expansion=“Commercial”><attrvalue id=“OCS” expansion=“Commercial - Scale”>

<attrvalue id=“OCSI” expansion=“Commercial - Scale - Intensive”/><attrvalue id=“OCSN” expansion=“Commercial - Scale - Non-intensive”/>

</attrvalue><attrvalue id=“OCF” expansion=“Commercial - Function”>

<attrvalue id=“OCFL” expansion=“Commercial - Function - Sales”><attrvalue id=“OCFR” expansion=“Commercial - Function - Service”>

</attrvalue><attrvalue id=“OCE” expansion=“Commercial - Eateries”>

<attrvalue id=“OCER” expansion=“Commercial - Eateries - Restaurants”><attrvalue id=“OCEB” expansion=“Commercial - Eateries - Bars and Taverns”>

</attrvalue>...<attrvalue id=“OCO” expansion=“Commercial - Others”/>

</attrvalue></attrname><attrname id=“shape_file”/><attrname id=“owner_id”/>

</tuple>...< /table>...</database>

form of text nodes. We had to provide anadditional access layer to ensure type-safeaccess. Extensible stylesheet language trans-formations (XSLT) overcome some of theselimitations by supporting many-to-manymappings and type-safe access.

To facilitate the creation of the agreementdocuments, we anticipate the need for a visualuser interface for the local expert. With thisinterface, the expert would select an entity ora collection of entities in the ontology, theequivalent entity or collection of entities inthe local data repository, and one of the fourmapping options (one-to-one, one-to-many,many-to-one, or one-to-null). The expertwould then ask the system to update the map-pings until all the mappings are defined. Thisinterface would hide the syntactic details, let-ting the expert concentrate on establishing thesemantic connections.

To achieve complete generality and reapthe full benefits of the emerging SemanticWeb technologies, we intend to develop theconnection between data and ontology at ahigher layer of the interoperability hierar-chy.11 XPath expressions capture mappingsemantics well, but an interesting possibilitywould be to capture the semantics using otherkinds of expressions mapping ontologies rep-resented using the resource descriptionframework (RDF).

AcknowledgmentsWe thank Nancy Wiegand and Steve Ventura for

discussions on land use problems, and ChaitanBaru and Ilya Zaslavsky for letting us useAxiomap. We also thank William Sunna, Paul Cal-nan, and Sathish Kumar Murugesan for help withthe implementation. This research was supportedpartly by the National Science Foundation underDigital Government Award EIA-0091489, and bythe Advanced Research and Development Activityand the National Imagery and Mapping Agencyunder award number NMA201-01-1-2001. Theviews and conclusions in this article are theauthors’ and do not necessarily represent the offi-cial policies or endorsements, either expressed orimplied, of the National Imagery and MappingAgency or the US Government.

References

1. I.F. Cruz et al., The Emerging Semantic Web,IOS Press, 2002.

2. Y. Bishr, “Overcoming the Semantic andOther Barriers to GIS Interoperability,” Int’lJ. Geographical Information Science, vol. 12,no. 4, 1998, pp. 299–314.

3. F. Fonseca and M. Egenhofer, “Ontology-Dri-ven Geographic Information Systems,” Proc.

7th ACM Symp. Advances in Geographic Infor-mation Systems, ACM Press, 1999, pp. 14–19.

4. M. Gahegan, “Characterizing the SemanticContent of Geographic Data, Models and Sys-tems,” Interoperating Geographic InformationSystems, M.F. Goodchild et al., eds., KluwerAcademic Publishers,1999, pp. 71–84.

5. V. Kashyap and A. Sheth, “Semantic Hetero-geneity in Global Information System:The Roleof Metadata, Context and Ontologies,” Coop-erative Information Systems: Current Trendsand Directions, M.P. Papazaglou and G.Schlageter, eds.,Academic Press, pp. 139–178.

6. S. Abiteboul, D. Suciu, and P. Buneman, Dataon the Web: From Relations to Semistructuredand XML, Morgan Kaufmann, 1999.

7. V. Kashyap and A. Sheth, “So Far (Schemat-ically) yet So Near (Semantically),” IFIPTransaction A-25: Proc. IFIP WG 2.6 Data-base Semantics Conf. Interoperable Database

Systems (DS-5), North-Holland, 1993, pp.283–312.

8. C.A. Cali et al., “Data Integration underIntegrity Constraints,” Proc. 14th Int’l Conf.CAiSE, LNCS, vol. 2348, Springer Verlag,2002, pp. 262–279.

9. Axiomap: Application of XML for InteractiveOnline Mapping, Elza Research, 2001, www.elzaresearch.com/landv/axiomap_ie5.html.

10. R.E. Kent, “XOL,” 1999, www.ontologos.org/Ontology/XOL.htm.

11. S. Melnik and S. Decker, “A Layered Approachto Information Modeling and Interoperabilityon the Web,” Proc. ECDL 2000 WorkshopSemantic Web, 2000, www.ics.forth.gr/isl/SemWeb/proceedings/session1-2/paper.pdf.

For more information on this or any other com-puting topic, please visit our Digital Library athttp://computer.org/publications/dlib.


Figure 16. The query user interface, with interactive maps.

T h e A u t h o r sIsabel F. Cruz is an associate professor in the Department of Computer Sci-ence at the University of Illinois at Chicago. Her research interests includedatabases and information systems, data integration, and the Semantic Web.She received a PhD in computer science from the University of Toronto. Con-tact her at the Department of Computer Science, Univ. of Illinois at Chicago,851 S. Morgan St (M/C 152), Chicago, IL 60607-7053; [email protected]; www.cs.uic.edu/~ifc.

Afsheen Rajendran is a graduate student in the Department of ComputerScience at the University of Illinois at Chicago. His research interests includedata integration for geographic information systems. He received a BEng inelectrical and electronics engineering from the Birla Institute of Technology& Science. Contact him at the Department of Computer Science, Univ. of Illi-nois at Chicago, 851 S. Morgan St. (M/C 152), Chicago, IL 60607-7053; [email protected]; http://cs.uic.edu/~advis/afsheen.

semantic data integration in hierarchical domainsifc/papers/ieee-is-066-073.pdf · ata integration...

Documents