A system and method providing cross-ontology multi-master replication is described. In a first embodiment a method for cross-ontology multi-master replication comprising the steps of: obtaining, at an importing site, an exporting site ontology and a set of one or more database changes; wherein the exporting site ontology defines a set of one or more data types; and after mapping the exporting site ontology to an importing site ontology, incorporating the set of one or more database changes into a database including mapping each of one or more data types of the set of data types to a data type defined by the importing site ontology using an ontology map.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application is related to the following commonly-owned, presently pending applications: application Ser. No. 12/836,801, filed Jul. 15, 2010, entitled “Sharing and Deconflicting Data Changes in a Multimaster Database System” and application Ser. No. 11/602,626, filed Nov. 20, 2006, entitled “Creating Data in a Data Store Using a Dynamic Ontology”. The disclosure of each of the foregoing applications is hereby incorporated by reference in its entirety, for all purposes.

TECHNICAL FIELD

The present disclosure generally relates to distributed computing systems and, in particular, to cross-ontology data replication in a multi-master database system.

BACKGROUND

Multi-Master Database Systems

In a typical computer-based multi-master database system, data is stored in a group of databases, data changes may be made to any member of the group, and data changes made to one member are propagated to the rest of the group. Multi-master database systems typically employ either a “synchronous” or an “asynchronous” replication scheme for propagating a change made to one database to the rest of the databases in the group.

In typical synchronous multi-master replication, each change is applied to all databases in the group immediately or to none of the databases if one or more of the databases in the group cannot accept the change. For example, one of the databases may be offline or unavailable. Synchronous multi-master replication is typically achieved using a two-phase commit protocol.

In contrast, in typical asynchronous multi-master replication, a change made to a database is immediately accepted by the database but propagation of the change to other databases in the group may be deferred. Because propagation of changes may be deferred, if one or more of the databases in the group are unavailable, the available databases can still accept changes, queuing the changes locally until they can be propagated. For this reason, multi-master database systems employing an asynchronous replication strategy are generally considered to be more highly available than multi-master database systems employing a synchronous replication strategy. However, asynchronous replication often raises the possibility of conflicts that occur as a result of concurrent database changes. In some circumstances, resolution of these conflicts requires human intervention.

Database Ontologies in Multi-Master Database Systems

Each database system participating in a multi-master database system typically organizes data in the database it manages according to a fixed structure and a well-defined set of data types. For example, a relational database management system typically organizes data according to a fixed structure of tables and columnar data types. The structure and data type definitions may be described using an ontology, embodied in a database schema, comprising a data model that is used to represent the structure, define the data types, and reason about data objects in the structure.

All database systems participating in a multi-master database system normally adhere to the same ontology. The ontology at each database system is normally fixed at the time that the topology of the multi-master database system is established. Any change to an ontology used by one database system that causes the ontology to diverge from the ontologies used by the other database systems is typically extremely disruptive to the multi-master database system and requires a database administrator or a software programmer to create customized software to facilitate data replication between the database system using the diverging ontology and the other database systems in the multi-master database system.

The rigidity of the typical fixed ontology multi-master database system is a serious drawback for organizations that require flexible and dynamic data processing techniques according to changes in the data that is collected. For example, intelligence analysis is poorly suited to conventional fixed ontology multi-master database systems.

SUMMARY

A system and method providing cross-ontology multi-master replication is described. In a first embodiment a method for cross-ontology multi-master replication comprising the steps of: obtaining, at an importing site, an exporting site ontology and a set of one or more database changes; wherein the exporting site ontology defines a set of one or more data types; and after mapping the exporting site ontology to an importing site ontology, incorporating the set of one or more database changes into a database including mapping each of one or more data types of the set of data types to a data type defined by the importing site ontology using an ontology map.

In an aspect of the first embodiment, at least one database change of the set of one or more database changes comprises (a) a data item representing a change to a database copy at the exporting site and (b) data representing a data type of the data item according to the exporting site ontology.

In another aspect of the first embodiment, obtaining, at the importing site, the exporting site ontology and the set of one or more database changes comprises obtaining, at the importing site, a database update comprising the exporting site ontology and the set of one or more database changes.

In yet another aspect of the first embodiment, obtaining, at the importing site, a digest of an ontology map at the exporting site; computing a digest of an ontology map at the importing site; and comparing the obtained digest of the ontology map at the exporting site with the computed digest of the ontology map at the importing site.

In still yet another aspect of the first embodiment, at least one data type of the set of one or more data types is not defined by the importing site ontology.

In still yet another aspect of the first embodiment, the ontology map comprises a one-to-one mapping between a first particular data type defined by the exporting site ontology and a second particular data type defined by the importing site ontology; and wherein mapping each of the one or more data types of the set of data types to a data type defined by the importing site ontology using an ontology map comprises mapping the first particular data type to the second particular data type using the ontology map.

In still yet another aspect of the first embodiment, the ontology map comprises a one-to-many mapping between a first particular data type defined by the exporting site ontology and a plurality of data types defined by the importing site ontology; and wherein mapping each of the one or more data types of the set of data types to a data type defined by the importing site ontology using an ontology map comprises mapping the first particular data type to one of the plurality of data types defined by the importing site ontology using the ontology map.

In still yet another aspect of the first embodiment, the ontology map specifies a list of data types to be dropped when exporting database changes from the exporting site.

In still yet another aspect of the first embodiment, the ontology map comprises a one-to-one mapping between a first particular link data type defined by the exporting site ontology and a second particular link data type defined by the importing site ontology; wherein the mapping further specifies that a link represented by data of the first particular link data type should be reversed before data representing the link is incorporated into the database; and wherein incorporating the set of one or more database changes into the database comprises reversing a link represented by a particular database change of the set of database changes before incorporating the particular database change into the database.

In a second embodiment, a method for cross-ontology multi-master replication comprising the steps of: obtaining, at an exporting site, an importing site ontology; obtaining a database change comprising a property value, the property value having a exporting site property type as defined in an exporting site ontology; using an ontology map to map the exporting site property type to an importing site property type defined in the importing site ontology; transforming the property value to an intermediate property value based on the importing site property type; transforming the intermediate property value to a first round-trip value based on the exporting site property type; determining whether to export the database change to the importing site based on a comparison between the property value and the first round-trip value.

In an aspect of the second embodiment, determining to export the database change to the importing site in response to determining that the property value and the first round-trip value are the same.

In another aspect of the second embodiment, determining that the property value and the first round-trip value are different; transforming the first round-trip value to a second intermediate value based on the importing site property type; transforming the second intermediate value to a second round-trip value based on the exporting site property type; and determining whether to export the database change to the importing site based on a comparison between first round-trip value and the second round-trip value.

Other embodiments include, without limitation, a non-transitory computer-readable medium that includes processor-executable instructions that enable a processing unit to implement one or more aspects of the disclosed methods as well as a system configured to implement one or more aspects of the disclosed methods.

DETAILED DESCRIPTION

Introduction

Referring to the figures, example embodiments will now be described. The example embodiments are primarily described with reference to block diagrams or flowcharts. As to the flowcharts, each block within the flowcharts represents both a method step and an apparatus element for performing the method step. Depending upon the implementation, the corresponding apparatus element may be configured in hardware, software, firmware, or combinations thereof. For example, in an embodiment comprising a special-purpose computer, an apparatus element may comprise a functional block of circuit logic.

Further, in the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, that the present invention may be practiced without these specific details. In other instances, block diagrams include well-known structures and devices in order to avoid unnecessarily obscuring the present invention.

Multi-Master Database System with Ontology Mapping

FIG. 1illustrates a multi-master database system100for use in cross-ontology multi-master replication between two replication sites101and102. In one embodiment, sites101and102are coupled through one or more data networks such as the Internet, one or more wide area networks (WANs), one or more local area networks (LANs), one or more network communication buses, or some combination thereof. It is not necessary that a highly or continuously available data network exist between replication sites101and102and the data network(s) connecting any two sites may only be periodically available. In another embodiment, sites101and102are not connected to each other via a data network and data is transported between these sites manually using portable media or a portable media device as such as a Compact Disc (CD), a Digital Versatile Disc (DVD), Universal Serial Bus (USB) flash memory device, etc.

Each site101and102may comprise one or more computing devices such as one or more workstation computers, server computers, laptop computers, mobile computing devices, or combinations thereof connected to each other via one or more data networks. Further, while only two sites are shown inFIG. 1, multi-master database system100may comprise many hundreds or even many thousands of sites.

According to one embodiment, each site (101,102) has a copy (103,104) of a body of data. The body of data may be, for example, one or more tables in a relational database. However, embodiments are not limited to relational databases and any type of database capable of supporting the conceptual data model described herein may be used. Non-limiting examples of types of databases capable of supporting the conceptual data model described herein include relational databases, hierarchical databases, and object-oriented databases.

With respect to a particular body of data, site101may be configured to asynchronously propagate to site102changes made to database copy103. Similarly, site102may be configured to asynchronously propagate to site101changes made to database copy104. With regard to multi-master replication, sites101and102may be considered to be replication “peers” because they share database changes directly with each other without sharing changes through an intermediary site. It is not necessary that each site (101,102, etc.) in the system100is configured to propagate to every other site changes made to its copy. In other words, a full-meshed multi-master site topology is not required to implement embodiments and partially-meshed or cascading multi-master topologies may be used.

As system100employs an asynchronous replication scheme, database copies in the system100are eventually consistent with each other. That is, each database copy may diverge from other copies from time to time such that at any given moment one database copy is inconsistent with another database copy. Two database copies are inconsistent when one database copy has incorporated a change and the other database copy has not yet been notified of the change. In the absence of new changes to either database copy, the database copies are expected to eventually become consistent with one another. Note that consistent database copies do not necessarily mean identical database copies. Indeed, since two database copies might use different ontologies, it is expected that two database copies can be consistent but not identical. For example, both database copies103and104might separately contain a data object representing the same real world entity such as, for example, the same person; however, under the ontology105of database copy103the data object may have the data type “Person” while under the ontology106of database copy104the data object may have the data type “Human”.

Each site in the system100has import/export logic120that includes a cross-ontology multi-master replication feature. In an embodiment, the cross-ontology multi-master replication feature can function to map data types defined by a peer site's ontology (e.g., ontology106) to data types defined by the local site's ontology (e.g., ontology105) where the two peer ontologies do not define identical data types (i.e., where the two peer ontologies differ) using an ontology map110. In an embodiment, the ontology map110fills the gaps between the two peer ontologies105and106such that sites101and102are still able to share database changes with each other despite using different ontologies. Specific techniques for cross-ontology multi-master replication using an ontology map are described in greater detail below.

The import/export logic120may be implemented as one or more computer software programs, one or more field programmable logics, hard-wired logic, or a combination thereof. In one embodiment, import/export logic120is a software component of a database management system such as an open source database system such as Cassandra, or those commercially available from the Oracle Corporation of Redwood Shores, Calif. and the Microsoft Corporation of Redmond, Wash. In another embodiment, import/export logic120is software component of a web-based, server-based or desktop application that uses a database management system for performing the cross-ontology multi-master replication techniques described herein. In yet another embodiment, import/export logic120is implemented in part by a web-based, server-based or desktop application and in part by a database management system.

As used herein, the term “database change”, unless otherwise apparent from the surrounding text, refers to an addition, edit, or deletion to the body of data stored in a database copy (e.g., copy103) at a site. A database change can be made at the site by a user or a computing process. In addition, a database change can also be made by import/export logic120in response to receiving notification of a database change made to a database copy at a peer site.

As used herein, the term “database update”, unless otherwise apparent from the surrounding text, refers to information about a database change that is sent (exported) from the site that made the change to a peer site. Each database change to a database copy at a site may result in a database update being received at every other site in the multi-master topology so that the other sites can incorporate the change into their respective database copies. The site sending a database update is referred to herein as the “exporting” peer and the site incorporating the sent database update is referred to herein as the “importing” peer. For example, if site101sends a database update to site102, then site101is the exporting peer and site102is the importing peer.

In one embodiment, a database update is sent from the exporting peer according to the exporting site's ontology. When the database update is received at the importing peer, the importing peer maps any of the exporting peer's data types that are not defined by the importing peer's ontology using an ontology map configured at the importing peer. After this cross-ontology data-type mapping is complete, the importing peer incorporates the database update into its database copy, mapping data types between the exporting peer's ontology and the importing peer's ontology using the ontology map as necessary. Notably, the data of the database update as incorporated into the incorporating peer's database copy is data typed according to the importing peer's ontology even though the data as exported by the exporting peer was data typed according to the exporting peer's ontology.

Example Database Data Model and Example Database System Using an Ontology to Make Database Changes

To provide a framework for the following discussion of specific techniques for cross-ontology multi-master replication, an example database data model and an example database system using an ontology to make database changes to the system's database copy will now be described. This description is provided for the purpose of providing a clear example and is not intended to limit the techniques to the example data model, the example database system, or the example database system's use of an ontology to make database changes.

Example Object-Centric Data Model

In one embodiment, a body of data, of which each site (101,102, etc.) maintains a copy (103,104, etc.), is conceptually structured according to an object-centric data model. The conceptual data model is independent of any particular database data model that may be used for durably storing a database copy at a site. For example, each object of the conceptual data model may correspond to one or more rows in a relational database or an entry in Lightweight Directory Access Protocol (LDAP) database.

FIG. 2illustrates an object-centric conceptual data model200according to an embodiment. Model200is centered on a data object201. At the highest level of abstraction, data object201is a container for information representing things in the world. For example, data object201can represent an entity such as a person, a place, an organization, or other noun. Data object201can represent an event that happens at a point in time or for a duration. Data object201can represent a document or other unstructured data source such as an e-mail message, a news report, or a written paper or article. Each data object201is associated with a unique identifier that uniquely identifies the data object within system100.

Each data object201as represented by data in a database copy (103,104, etc.) at a site (101,102, etc.) may have an object type (e.g., Person, Event, or Document) defined by the database ontology (105,106, etc.) used by the database copy (103,104, etc.). The same data object represented in two different database copies (e.g.,103,104) may have two different object types as separately defined by the two different database ontologies (e.g.,105,106). For example, the same data object in one database copy (e.g.,103) may be defined as a “Business” object type while defined in another database copy (e.g.,104) as an “Organization” object type. Further, when hierarchical object types are supported, two ontologies may separately define super-object types and sub-object types of the super-object types. For example, one ontology may define a “Person” super-object type an additionally define an “Employee” sub-object type of the “Person” super-object type. On the other hand, the other ontology may define only the “Person” object type but not define the “Employee” object type. In this case, the same data object in one database copy may be defined as object type “Employee” while defined in the other database copy as object type “Person”.

Each data object201may have one or more properties203. Properties203are attributes of the data object201that represent individual data items. At a minimum, each property203of a data object201has a property type and a value. Different types of data objects may have different property types. For example, a “Person” data object might have an “Eye Color” property type and an “Event” data object might have a “Date” property type.

Each property203as represented by data in a database copy (e.g.,104) at a site (e.g.,102) may have a property type defined by the database ontology (e.g.,106) used by the database copy. The same property represented in two different database copies may have two different property types as separately defined by the two different database ontologies. For example, the same property in one database copy may be defined by that copy's ontology as a “Phone Number” property type in which the value of the property is treated as a string data type while defined by the other ontology also as a “Phone Number” property type but where the value of the property is treated as a numerical data type.

In addition, data model200may support property multiplicity. In particular, a data object201may be allowed to have more than one property203of the same property type. For example, a “Person” data object might have multiple “Address” properties or multiple “Name” properties.

Each link202represents a connection between two data objects201. In one embodiment, the connection is either through a relationship, an event, or through matching properties. A relationship connection may be asymmetrical or symmetrical. For example, “Person” data object A may be connected to “Person” data object B by a “Child Of” relationship (where “Person” data object B has an asymmetric “Parent Of” relationship to “Person” data object A), a “Kin Of” symmetric relationship to “Person” data object C, and an asymmetric “Member Of” relationship to “Organization” data object X. The type of relationship between two data objects may vary depending on the types of the data objects. For example, “Person” data object A may have an “Appears In” relationship with “Document” data object Y or have a “Participate In” relationship with “Event” data object E. As an example of an event connection, two “Person” data objects may be connected by an “Airline Flight” data object representing a particular airline flight if they traveled together on that flight, or by a “Meeting” data object representing a particular meeting if they both attended that meeting. In one embodiment, when two data objects are connected by an event, they are also connected by relationships, in which each object has a specific relationship to the event, such as, for example, an “Appears In” relationship. As an example of a matching properties connection, two “Person” data objects representing a brother and a sister, may both have an “Address” property that indicates where they live. If the brother and the sister live in the same home, then their “Address” properties likely contain similar, if not identical information. In one embodiment, a link between two data objects may be established based on similar or matching properties of the data objects. These are just some examples of the types of connections that may be represented by a link and other types of connections may be represented; embodiments are not limited to any particular types of connections between data objects. For example, a document might contain two different tagged entities. A link between two data objects may represent a connection between these two entities through their co-occurrence within the same document.

Each data object201can have multiple links with another data object201to form a link set204. For example, two “Person” data objects representing a husband and a wife could be linked through a “Spouse Of” relationship, a matching property (“Address”), and an event (“Wedding”).

Each link202as represented by data in a database copy (e.g.,104) at a site (e.g.,102) may have a link type defined by the database ontology (e.g.,106) used by the database copy. The same link represented in two different database copies may have two different property types as separately defined by the two different database ontologies. For example, the same link in one database copy may be defined by that copy's ontology as a “Related To” link type while defined by the other ontology as a “Parent Of” link type. Further, two ontologies may separately define opposite asymmetric link types. For example, one ontology may define a “Parent Of” link type but not define a “Child Of” link type while the other ontology may define a “Child Of” link type but not define a “Parent Of” link type. In this case, the directions of links linking the same two data objects may be different in different database copies. For example, in one database copy, a “Parent Of” link may “point” from data object A to data object B while in another database copy a “Child Of” link may “point” from data object B to data object A.

Example Database System Using an Ontology to Make Database Changes to the System's Database Copy

FIG. 3illustrates example components of a database system at a site for creating data in a database copy (i.e., making database changes to the copy) at the site using the database copy's ontology. In the example depicted inFIG. 3, the components are of the database system at site101of multi-master replication system100. Similar components may be part of the database system at site102and at other sites of the system100. The ontology105at site101may be different than the ontology106at site102; thus one or more of object types310, property types316, and link types330may be defined in one ontology (e.g.,105) that are not defined in the other ontology (e.g.,106), and the converse also could be implemented.

In an embodiment, a parser302is coupled to the ontology105, which is coupled to the database copy103. In an embodiment, ontology105comprises stored information providing the data model200of data stored in database copy103, and the ontology is defined by one or more object types310, one or more property types316, and one or more link types330. One or more data objects201in the database copy103may be instantiated based on the object types310, and each of the objects201has one or more properties203that are instantiated based on property types316. Two data objects201may be connected by one or more links202that may be instantiated based on link types330. The property types316each may comprise one or more components318, such as a string, number, etc. Property types316may be instantiated based on a base property type320. For example, a base property type320may be “Locations” and a property type316may be “Home.”

In an embodiment, a user of the system uses an object type editor324to create the object types310and define attributes of the object types. In an embodiment, a user of the system uses a property type editor326to create the property types316and define attributes of the property types. In an embodiment, a user of the system uses link type editor328to create the link types330. Alternatively, other programs, processes, or programmatic controls may be used to create link types and property types and define attributes, and using editors is not required.

In an embodiment, creating a property type316using the property type editor326involves defining at least one parser definition using a parser editor322. A parser definition comprises metadata that informs parser302how to parse input data300to determine whether values in the input data can be assigned to the property type316that is associated with the parser definition. In an embodiment, each parser definition may comprise a regular expression parser304A or a code module parser304B. In other embodiments, other kinds of parser definitions may be provided using scripts or other programmatic elements. The elements of a regular expression parser304A and a code module parser304B are described further in subsequent sections. Once defined, both a regular expression parser304A and a code module parser304B can provide input to parser302to control parsing of input data300.

In one embodiment of using the system ofFIG. 3, input data300is provided to parser302. An object-property mapping for the input data300enables the parser to determine which object type310should receive data from a record of the input data, and which property types316should receive data from individual field values in the input data. Based on the object-property mapping301, the parser302selects one of the parser definitions that is associated with a property type in the input data. The parser parses an input data field using the selected parser definition, resulting in creating modified data303. The modified data303is added to the database copy103according to ontology105by storing values of the modified data in a property of the specified property type. As a result, input data300having varying format or syntax can be created in database copy103. The ontology105may be modified at any time using object type editor324, property type editor326, and link type editor328, or under program control without human use of an editor. Parser editor322enables creating multiple parser definitions that can successfully parse input data300having varying format or syntax and determine which property types should be used to transform input data300into modified input data303.

Cross-Ontology Exporting and Importing of Database Changes

FIG. 4illustrates steps of a method400for exporting database changes from one database copy at one site in a multi-master replication topology to a peer site in the multi-master replication topology.FIG. 5illustrates steps of a method500for importing the database changes at the peer site. For the purpose of providing a clear example, reference will be made to the multi-master system100ofFIG. 1in which site101is considered to be the exporting peer and site102is considered to be the importing peer. Alternatively, site102could be the exporting peer and site101the importing peer.

Ontology105of the exporting peer101may be different than the ontology106of the importing peer102. That is, the ontology105of the exporting peer101may define one or more data types that are not defined by the ontology106of the importing peer106and the ontology106of the importing peer102may define one or more data types that are not defined by the ontology105of the exporting peer101. In this context, the exporting peer101may wish to share database changes it made to its database copy103with the importing peer102and the importing peer102may wish to incorporate the shared database changes into its database copy104even though the peers use different ontologies.

In one embodiment, to accomplish cross-ontology sharing of database changes, both the exporting peer101and the importing peer102are configured with the semantically same ontology map110. In one aspect, the ontology map110declares rules for mapping data types defined in one site's ontology to data types defined in another site's ontology and vice versa to facilitate sharing of data between the sites yet at the same time facilitating maintenance and development of separate ontologies at the sites. Separate and differing ontologies at the sites may be desirous, for example, if the sites are controlled by different entities such as different companies or different organizations or different divisions within an organization. With the ontology map, two sites that wish to share data with each other do not need to agree on a common ontology. They need only agree on how to map data types between the ontologies. As a result, if one site changes the type of an object, link, or property to one that it is not known to the peer site's ontology, the type change can still be shared with the peer site so long as the ontology map provides a rule for mapping the type to one that is known to the peer site's ontology.

In one embodiment, the data format of the ontology map110and the cross-ontology data type mapping rules contained therein is based on the eXtensible Markup Language (XML). Specific examples of mapping rules are provided below. The examples are provided in XML format. However, it will be apparent to one skilled in the art that other data formats for expressing the ontology map110in a form understandable by a computer are possible and that the invention is not limited to only XML-based formats. In one embodiment, the ontology map110is created by a database administrator by using, for example, a text editor or computer application configured to generate ontology maps according to a user's commands.

Exporting

Referring now toFIG. 4, in one embodiment, process400is performed by the import/export logic120of the exporting peer101after the exporting peer101has been configured with the ontology map110. At step401, the exporting peer101determines a set of database changes made to the exporting peer's database copy103to share with the importing peer102. The specifics of how the exporting peer101determines the set of database changes to be shared are beyond the scope of this disclosure and not essential to the invention disclosed herein. In general, it is expected, but not required, that the set of database changes will include data representing changes made to the body of data in the exporting peer's database copy103that are not yet known to the importing peer102. Any number of a variety of techniques for tracking the ordering of events in a distributed system may be used to determine whether the importing peer already knows about changes made to the exporting peer's copy103including, for example, use of vector clocks. Significantly, the set of database changes to be shared by the exporting peer101is data typed according to the exporting peer's ontology105. For example, the set of database changes may include data representing one or more data objects201, properties203, and links202typed according object types310, property types316, and link types330defined in the exporting peer's ontology105.

At step402, one or more database changes in the set of database changes to be shared that may not be importable at the importing site102are dropped from the set by the exporting peer101before the set is shared with the importing peer102. A database change may not be importable at the importing peer102if the database change has a data type according to the exporting peer's ontology105that is not defined by the importing peer's ontology106and for which the ontology map110does not provide a rule for mapping that data type to a data type in the importing peer's106ontology. For example, an administrator at the exporting peer101may define a new data type in the ontology105for which the administrator has yet to decide how the new data type should be mapped to the importing peer's ontology106.

In one embodiment, the ontology map110specifies the list of data types to be dropped by the exporting peer101when exporting a set of database changes. This list can be added to or amended as needed by an administrator at the exporting peer101. Before the import/export logic120of the exporting peer101shares a set of database changes with the importing peer102, the logic120removes all database changes from the set that have a data type on the list of data types to be dropped. As a result, sharing of database changes for which no corresponding data type is defined in the importing peer's ontology106is prevented. This prevents errors and failures at the importing peer when importing the set of database changes. Further, this allows the ontology105of the exporting peer101to be extended (i.e., new types added) before it has been determined how the new types will map to data types in the ontology106of the importing peer102. Meanwhile, sharing of database changes between the peers with respect to other data types can continue.

In accordance with an embodiment, the list of data types to be dropped by the exporting peer101when exporting a set of database changes is specified in the ontology map110using the following XML syntax:

The <droppedUri> element contains a data type to drop on export. The <systemId> element contains a value SYSTEM_ID that identifies the site that is to drop the listed data type when exporting. An ontology map110can specify multiple drop data types lists for multiple sites. For example, ontology map110may specify a drop data types list for site101and another drop data types list for site102. Each site separately consults its list in the map110when exporting a set of database changes. Each data type to be dropped is identified as a value of a <uri> element. In one embodiment, the value of a <uri> element is a Uniform Resource Indicator (URI) that uniquely identifies the data type within the exporting site's ontology. Dropped types can include object types, property types, and link types, for example.

At step403, the set of database changes minus the database changes dropped in step402are sent from the exporting site101as a database update to the importing site102.FIG. 6is a block diagram and schematic illustration of a database update601sent from the exporting site101to the importing site102according to an embodiment. In one embodiment, database update601is XML formatted and sent between exporting site101and importing site102over a data network as one or more network data packets.

In accordance with one embodiment, database update601comprises a set of database changes620and database update metadata610. In one embodiment, the database update metadata610includes an ontology611, an ontology map612, and a digest613of the ontology map612. The ontology611includes the ontology105of the exporting peer101or a portion thereof. The ontology map612includes the ontology map110as configured at the exporting peer101. In one embodiment, the update601includes one or the other of the ontology map612and the digest613but not both.

The set of database changes620includes one or more update items621A,621B, etc. Each update item621includes data631representing a database change to the exporting site's database copy103, type information632specifying the data type of data631according to the exporting site's ontology105, and version information633indicating the version of data631in the exporting site's database copy103. For example, data631may represent a database change to a data object201, a property203, or a link202; type information632may specify a object type310, a property type316, or a link type330; and the version information633may be, for example, a vector clock representing the version of the data object201, the property203, or the link202in the exporting peer's database copy103.

In one embodiment, as described in greater detail below with respect toFIG. 5, the database update metadata610is used by the import/export logic120of the importing peer102when importing the set of database changes620into the importing peer's database copy104. Briefly, the importing peer102, before importing any of the database changes620into its database copy104, verifies that every data type in the exporting peer's ontology611as sent in the update601has a corresponding data type in the importing peer's ontology106. This verification includes, in one embodiment, the importing peer102computing a digest of its copy of the ontology map110and comparing the computed digest to the digest613in the update metadata610to verify that the exporting peer101and the importing peer102are configured with compatible ontology maps. Once the ontology maps110at peers101and102are verified to be compatible, the importing peer101attempts to map every data type defined in the exporting peer's ontology611to a type defined in the importing peer's ontology106. If there is no direct mapping available for a type defined in the ontology611(i.e., the type is defined by the exporting peer's ontology611but not defined the importing peer's ontology106), then the importing peer102attempts to map the type using a rule or rules in the ontology map110. Assuming each and every type in the exporting peer's ontology611can be successfully mapped to a type in the importing peer's ontology106, the importing peer102proceeds to import the database changes620in the update601into the importing peer's database copy104, mapping data types632using the ontology map110as necessary.

In some embodiments, in the context of configuring the exporting peer101with a new ontology map that is semantically different than the ontology map that the exporting peer101is concurrently configured with, the import/export logic120performs a validation process with respect to the new ontology map and the current ontology map. This process involves identifying mapping differences between the current ontology map and the new ontology map and notifying a user of potential inconsistencies that could result from the mapping differences. The mapping differences of concern of those in which the new ontology map changes a mapping for data that may have already been exported or imported under the current ontology map. In this case, when an administrator configures the exporting peer101with the new ontology map, the administrator is notified about data that may have been exported or imported under the current ontology map having a data type that is now inconsistent with the new ontology map.

For example, suppose the current ontology map used by two peers has a mapping in which object type A is mapped to object type B (A→B) and object type C is mapped to object type D (C→D). Under this mapping, when an object of type A is exported from a first of the two peers to a second of the two peers, object type A is mapped to object type B at the second peer. And when an object of object type B is exported from the second peer to the first peer, object type B is mapped to object type A at the first peer. Similarly, under this mapping when an object of type C is exported from the first peer to the second peer, object type C is mapped to object type D at the second peer. And when an object of object type D is exported from the second peer to the first peer, object type D is mapped to object type C at the first peer.

Continuing the example, now assume an administrator wishes to replace the current ontology map at the two peers with a new ontology map in which object type A is mapped to object type D (A→D) and object type C is mapped to object type B (C→B). The administrator may wish to do this, for example, after realizing that the current ontology map incorrectly mapped A to B and C to D. Under this new mapping, when an object of type A is exported from the first peer to the second peer, object type A is mapped to object type D at the second peer. And when an object of object type D is exported from the second peer to the first peer, object type D is mapped to object type A at the first peer. Similarly, for object types C and B. If database changes had been exported and imported between the two peers under the current ontology map, then there may be objects of type A in the first peer's database that should of type C under the new ontology map and there may be objects of type B in the second peer's database that should be of type D under the new ontology map. In this case, in the context of an administrator configuring the first peer with the new ontology map, the import/export logic102at the first peer detects that object type A is remapped from B to D and object type C is remapped from D to B and notifies the administrator through a screen or console message of the potential data type inconsistencies that may exist for objects of type A in the first peer's database and objects of type B in the second peer's database.

Importing

Referring now toFIG. 5, in one embodiment, process500is performed by the import/export logic120of the importing peer102. At step501, the importing peer102obtains the exporting peer ontology611and a set of database changes620. For example, the importing peer102may obtain the exporting peer ontology611and the set of database changes620in a database update601sent from the exporting peer. In one embodiment, the importing peer102obtains the exporting peer ontology611and the set of database changes620in a plurality of database updates601. For example, the exporting peer ontology611may be sent by the exporting peer in an initial database update601and the set of database changes620sent in a subsequent database update601. Thus, it is not requirement that every database update601include both the exporting peer ontology611along with a set of database changes620and some database updates601may include one but not the other.

The portion of the exporting peer ontology611sent in an update601may or may not comprise the entire ontology105used by the exporting peer. In one embodiment, the exporting peer ontology611comprises at least the data types632involved in an associated set of database changes620.

At step502, the importing peer102verifies that the ontology map110at the exporting peer101is compatible with the ontology map110at the importing peer102. In one embodiment, this verification involves the import/export logic120of the importing peer102computing a digest of the ontology map110at the importing peer102to compare with the digest613in the database update601containing the set of database changes620. In one embodiment, if the digests match, then the importing peer102concludes that the ontology maps110at the exporting peer101and the importing peer102are compatible. If the digests do not match, then, in one embodiment, the importing peer102assumes that the exporting peer101and the importing peer102are configured with incompatible ontology maps110. Accordingly, the importing peer102in this case may not import the set of database changes620into the importing peer's database copy104. In one embodiment, the digest computed by the importing peer102and the digest613computed by the exporting peer are computed using a collision resistant cryptographic hash function (e.g., MD5). The ontology map may be normalized prior to being provided to the hash function so that trivial differences between ontology maps do not produce differing digests.

In an embodiment in which the exporting peer's ontology map110is sent in the update601in lieu of a digest613, the importing peer102compares the exporting peer's ontology map110with its copy of the ontology map110to determine if the two copies are compatible. Such comparison may involve a byte level comparison or comparisons at a semantically higher-level.

At step503, the importing peer102attempts to map each and every type defined in the exporting peer's ontology611sent in the update601to a data type defined in the importing peer's ontology106. In one embodiment, the importing peer102performs this mapping before importing the set of database changes120into the importing peer's database copy104. By successfully mapping each and every type defined in the exporting peer's ontology611sent in the update601to a data type defined in the importing peer's ontology106, the importing peer102can import the set of database changes620with no risk of an import error caused by a data type632of the set602that has no mapping to a data type in the importing peer's ontology106.

A data type defined in the exporting peer's ontology611is or is not also defined in the importing peer's ontology106. If the data type is also defined in the importing peer's ontology106, then the ontology map110is not needed to map the data type when importing data631of that data type. On the other hand, if the data type is not defined in the importing peer's ontology106, then the importing peer102uses a rule or rules in the ontology map110in an attempt to map the data type to one defined in the importing peer's ontology106. Example mapping rules are described in greater detail below.

At step504, after verifying that each data type defined in the exporting peer's ontology611can be mapped to a data type in the importing peer's ontology106, the importing peer102imports the set of database changes620into the importing peer's database copy104. This importing includes mapping data types632of data631in the set of database changes620to data types in the importing peer's ontology106. Recall that the data types632specified in the update601are defined according to the exporting peer's ontology105, some of which may not also be defined in the importing peer's ontology106. For these data types that are not defined in both the exporting peer's ontology105and the importing peer's ontology106, the ontology map110is used by the importing peer during import of the update601to map these data types from the exporting peer's ontology105to the importing peer's ontology106. As a result, all data631of the update601imported into the importing peer's database copy104is typed according to the importing peer's ontology106even though that data631, when sent in the update601, was typed according to the exporting peer's ontology106. Both the exporting peer101and the importing peer102can separately maintain differing ontologies yet still share data with each other as part of a replication scheme through the ontology map.

Ontology Map Examples

As described above with respect to an embodiment, the exporting peer101, when exporting a set of database changes, exports the data types of data included in the set of database changes (e.g., objects, properties, and links) as the data is typed in the exporting peer's database copy103(i.e., according to the exporting peer's ontology105). The ontology map110can specify certain data types in the exporting peer's ontology105that are to be dropped during export (i.e., no data of those types is included in the exported data). This drop feature can be used to prevent the exporting peer101from sharing database changes that cannot be representing according to the importing peer's ontology106.

The importing peer102, when importing a set of database changes, begins with the data types of the data in the set of database changes as they are defined by the exporting peer101according to the exporting peer's ontology105. One or more of these data types may not be defined in the importing peer's ontology106. The ontology map110is used by the importing peer to map these data types to ones defined in the importing peer's ontology106. In one embodiment, an ontology map1110can specify pairs of data types that map to each other (one-to-one mapping), parent-child relationships (one-to-many mappings), and a list of data types to drop on export.

Peer Information Section

In one embodiment, an ontology map110includes a peer information section. The peer information section comprises two system identifiers identifying two sites (e.g.,101and102) configured in a peering relationship (i.e., two sites configured to share database changes with each other as part of a multi-master replication topology). When a site (e.g.,101,102, etc.) is configured with an ontology map110, the peer information section is read to verify that the ontology map110applies to the site being configured. During configuration of a site (Site A) with an ontology map110, if one of the system identifiers in the peer information section identifies the site being configured with the ontology map110(i.e., identifies Site A), then the site (Site A) verifies that the other system identifier in the peer information section identifies a site (Site B) that the configuring site (Site A) is configured to share database changes with. If both these conditions are met, then the ontology map110applies to the configuring site (Site A). The other site (Site B) performs a similar process to determine if an ontology map110it is being configured with applies to it.

In accordance with an embodiment, the peer information section is specified in the ontology map as follows:

Dropped Types

In one embodiment, the ontology map110specifies the list of data types to be dropped by the exporting peer101when exporting a set of database changes. This list can be added to or amended as needed by an administrator at the exporting peer101. Before the import/export logic120of the exporting peer101shares a set of database changes with the importing peer102, the logic120removes all database changes from the set that have a data type on the list of data types to be dropped. As a result, sharing of database changes for which no corresponding data type is defined in the importing peer's ontology106is prevented. This prevents errors and failures at the importing peer when importing the set of database changes. Further, this allows the ontology105of the exporting peer101to be extended (i.e., new types added) before it has been determined how the new types will map to data types in the ontology106of the importing peer102. Meanwhile, sharing of database changes between the peers with respect to other data types can continue.

In accordance with an embodiment, the list of data types to be dropped by the exporting peer101when exporting a set of database changes is specified in the ontology map110using the following XML syntax:

The <droppedUri> element contains a data type to drop on export. The <systemId> element contains a value SYSTEM_ID that identifies the site that is to drop the listed data type when exporting. An ontology map110can specify multiple drop data types lists for multiple sites. For example, ontology map110may specify a drop data types list for site101and another drop data types list for site102. Each site separately consults its list in the map110when exporting a set of database changes. Each data type to be dropped is identified as a value of a <uri> element. In one embodiment, the value of a <uri> element is a Uniform Resource Indicator (URI) that uniquely identifies the data type within the exporting site's ontology. Dropped types can include object types, property types, and link types, for example.

In one embodiment, the ontology map110specifies a one-to-one data type mapping. In a one-to-one data type mapping, a single data type from the exporting peer's ontology105is mapped to a single data type in the importing peer's ontology106. In an embodiment, a one-to-one mapping is specified using the following syntax:

In the above example mapping specification, the mappingType attribute of the <oneToOneMapping> element specifies whether the mapping applies to a link type, an object type, or a property type. The order of the <uri> child elements of the <oneToOneMapping> element corresponds to the order of the <systemId> child elements of the <peerinformation> element. Thus, URI1 is a data type defined in SYSTEM_ID1's ontology and URI2 is a data type defined in SYSTEM_ID2's ontology. Further, URI1 and URI2 should be for the same mappingType (i.e., link, object, or property). For example, if the mappingType specifies that the one-to-mapping applies to a “property”, then both URI1 and URI2 should be a property data type. As used herein, URI refers to Uniform Resource Indicator. In one embodiment, a URI is a string that uniquely identifies a data type within an ontology. In one embodiment, a oneToOneMapping is bi-directional. For example, URI1 will be mapped to URI2 when SYSTEM_ID2 is the importing peer and URI2 will be mapped to URI1 when SYSTEM_ID1 is the importing peer.

One-to-One Mapping With Reverse Link Feature

In one embodiment in which a one-to-one mapping is specified for a link mapping type, the importing peer102reverses a link connecting two data objects represented by link data631in the database update601before importing the link data631into the importing peer's database copy104. Such a mapping may be useful if opposite asymmetrical link types are defined in two peering ontologies. For example, the exporting peer's ontology105may define a “Parent Of” link type but not define a “Child Of” link type while the importing peer's ontology106may define a “Child Of” link type but not define a “Parent Of” link type. If the importing peer102mapped the “Parent Of” link to the “Child Of” link without reversing the link represented by the link data631before importing the link data631into the importing peer's database copy104, then, after the import, “Child Of” links202connecting data objects201in the importing peer's database copy104would incorrectly reflect the direction of the child of relationship between the data objects.

In accordance with one embodiment, the following syntax is used in the ontology map110to specify a one-to-one mapping with reversed links:

In some ontologies, there is a hierarchy of object types available for classifying (typing) data objects. For example, an ontology may define a super-object type “Person” with sub-object types “Employee” and “Contractor”. The “Person” object type is referred to as a “super” object type and “Employee” and “Contractor” object types are referred to as “sub” object types because a data object of type “Employee” or type “Contractor” is also of type “Person” but a data object of type “Person” may not be of type “Employee” or type “Contractor”. Assume this hierarchy is defined in site A's ontology but that site B's ontology only defines the object type “Person” and does not define the object types “Employee” and “Contractor”. Given these ontologies, after exporting a data object O of object type “Employee” from the database copy at site A to site B, it may be desirable for site B, on import to map object type “Employee” to object type “Person”. Further, when site B exports data object O back to site A, it would desirable for site A on import to map object type “Person” back to object type “Employee”, if appropriate to do so (i.e., if the data type of object O has not changed in the meantime).

In an embodiment, the type of object O in site A's database copy is retained when site B exports object O back to site A if the type of object O in site A's database copy is, according to the ontology map, a child type of the type of object O as exported by site B. For example, if site B exports object O as type “Person” and in site A's database copy object O has type “Employee”, then site A will retain type “Employee” for object O in its database copy provided the ontology map specifies that the “Employee” type is a child type of the “Person” type. Note that the specification of a parent and child types in a one-to-many mapping in the ontology map is independent of whether those types are super and sub-types according to the parent site ontology or the child site ontology. For example, the “Employee” type may be specified as a child type of type “Person” in a one-to-many mapping yet the “Employee” type may not be defined as a sub-type of type “Person” in either site A's ontology or site B's ontology.

In accordance with an embodiment, a one-to-many mapping is specified in an ontology map using the following syntax:

In this example, SYSTEM_ID is one of the two system identifiers specified in the peer information section of the ontology map. The SYSTEM_ID site (parent site) defines the PARENT_URI type in its ontology (e.g., site B defines type “Person”). The other site specified in the peer information section defines at least all of the CHILD_URI types (e.g., site A defines types “Employee” and “Contractor”).

Before importing an object (e.g., object O) exported from the parent site (e.g., Site B) into the child site's (e.g., Site A) database copy, a check is performed by the child site. In particular, the child site checks that the type of the object as stored in the child site's database copy is, according to the one to many mapping in the ontology map, a child type of the type exported from the parent site. For example, if object O as stored in the Site A's database copy is of type “Employee” and Site B exports object O as type “Person”, then, before importing object O as exported by Site B into Site A's database copy, Site A will check that type “Employee” is, according to the one to many mapping, a child type of type “Person”. If it is, then the “Employee” type for object O in Site A's database copy will be retained during the import even though object O was exported from Site B as type “Person”. Otherwise, Site A will set the type of object O in Site A's database copy to be type exported by Site B (e.g., “Person”).

The PARENT_URI type need not be defined by the child site's ontology. For example, type “Person” may be, defined by Site A's ontology. On import, the child site can compare (e.g., by a string comparison) the data type632specified in the update item621to the PARENT_URI type of the one-to-many mapping to determine if the mapping applies to the update item621. In this case where the PARENT_URI type is not defined in the child site's ontology, the ontology map may specify a one to one mapping for the PARENT_URI type as a fallback mapping in the event a data type632of type PARENT_URI cannot be mapped under the one to many mapping to a CHILD_URI type. For example, if the type of object O in Site A's database copy before import is neither “Employee” nor “Contractor” and object O is exported from Site B as type “Person”, then Site A, on import, may fallback to a one to one mapping in order to map type “Person” to another type defined in Site A's ontology.

A one-to-many mapping can be applied to links and objects independent of whether hierarchical types are supported by the ontology. In particular, a one-to-many mapping may be used to retain the type of an object, property, or link in the child site's database copy when the object is exported back to the child site from the parent site irrespective of whether the parent site's ontology or the child site's ontology defines the retained type as a sub-type of the exported type.

Further, a one-to-many mapping can be applied to any type hierarchy. As an example, suppose a V→W→X1→X2→Y→Z (parent child) object type hierarchy exists in site A's ontology. Further assume the following one-to-many mapping in which site A is the child system and a site B is the parent system:

Under this mapping, there are many possible type relationships between an object O's original type T at site A and object O's type T′ as exported back to site A from site B. If T′ is type W and T is type Y, then in accordance with one embodiment, site A should retain the more specific type on import (i.e., type Y). However, if type T′ is a sub-type of W (e.g., T′ is type X1) or a super-type of W (e.g., T′ is type V), then in accordance with one embodiment site A assumes that the type for object O was changed at site B and thus does not retain the existing type for object O in site A's database copy on import.

Pre-Export Peer Ontology Validation

In one embodiment as shown inFIG. 3, a property type316of an ontology specifies a base or primitive type320(e.g., string, number, etc.) and one or more components318that accept an input property value300and transforms it in different ways to produce a final property value that is stored in the database copy as the property value. For example, a component318of a “Phone Number” property type could employ a parser302(e.g., a regular expression parser304A or a code module parser304B) that attempts to format the raw input property value into a string of the form “(XXX) XXX-XXXX”. Thus, the base type320and the components318can be considered to be part of the ontology.

Two property types that are mapped to each other in an ontology map may have different base types320in different ontologies or employ different components318in different ontologies. For example, property type “com.siteA.PhoneNumber” as defined in site A's ontology may be mapped to property type “com.siteB.PhoneNumber” as defined in site B's ontology in an ontology map. Property type “com.siteA.PhoneNumber” as defined in site A's ontology may have a number base type320while property type “com.siteB.PhoneNumber” as defined in site B's ontology may have a string base type320. Even where mapped property types have the same base type320, the respective types may have differing components318in different ontologies. For example, in site A's ontology, property type “com.siteA.PhoneNumber” may have a component318that attempts to format (parse) raw input values into a string of the form “(XXX) XXX-XXXX” while, in site B′ ontology, property type “com.siteB.PhoneNumber” may have a component318that attempts to format (parse) raw input values into a string of the form “XXXXXXXXXX”.

Differences in base types320and differences in components318between ontologies, even where the ontology map specifies a mapping between property types, can cause import errors at the importing peer. As one example, two mapped property types can have incompatible base types. For example, if property type “com.siteA.PhoneNumber” in site A's ontology has a string base type and property type “com.siteB.PhoneNumber” in site B's ontology, to which property type “com.siteA.PhoneNumber” is mapped in the ontology map, has a number base type, then site B may not be able to import data exported by site A of type “com.siteA.PhoneNumber” if the exported data cannot be converted at site B from a string to a number.

In accordance with one embodiment, the exporting peer performs pre-export validation on properties to be exported using the importing peer's ontology. By doing so, importing errors at the importing peer resulting from mapped property types having differing base types302or differing components318can be avoided.

Referring now toFIG. 7, a method700provides pre-export peer ontology validation according to an embodiment. Method700is performed by the import/export logic120of the exporting peer101prior to exporting a set of database changes620in which one or more of the set of database changes620to be exported are for properties203. For example, steps of method700might be performed after the exporting peer101has updated the value of a phone number property203in the exporting peer's database copy103and is now about to export the updated phone number property to the importing peer102. The basic approach of method700is to simulate, prior to exporting a database update621for a property203, how a given property value of the property203would change according to the exporting peer ontology105and the importing peer ontology106when the given property value is exported to the importing peer102and back to the exporting peer101. In other words, the basic approach of method700is to simulate how the given property value would change when making a replication round-trip from the original exporting peer101to the importing peer102and back to the original exporting peer101. If the given property would not change after one round-trip or if the given property value would stabilize after two round trips, then the given property value can be safely exported from the exporting peer101to the importing peer102even if the respective property type definitions in the respective ontologies105and106differ in base type320or components316.

At step701, the exporting peer101obtains the importing peer's ontology106. In one embodiment, the exporting peer101is configured with the importing peer's ontology106at the same time it is configured with the ontology map110.

At step702, the exporting peer101obtains a property value to be exported to the importing peer102. For example, the exporting peer101may obtain the property value as part of step401ofFIG. 4in which the exporting peer101determines a set of database changes620to share with the importing peer102.

At step703, the exporting peer101maps the property value according to the importing peer's ontology106to an intermediate value and maps the intermediate value according to exporting peer's ontology105to obtain a first round-trip value. The first-round trip value represents how the property value to be exported would change if exported to the importing peer, incorporated into the importing peer's database copy104according to the importing peer's ontology106, and the incorporated value exported back to the exporting peer101and incorporated back into the exporting peer's database copy103according to the exporting peer's ontology105. This mapping includes mapping the property type316of the property value according to the exporting peer's ontology105to a property type316in the importing peer's ontology106, using the ontology map110if necessary. The original property value to be exported is then transformed according to the base type320and any components318defined by the property type316of the property in the importing peer's ontology106to produce the intermediate value. For example, if the base type320defined by the property type316of the value in the importing peer's ontology106is a number, then the exporting peer101will attempt to convert (cast) the original property value to a number. The intermediate value is then transformed according to the base type320and any components318defined by the property type316of the property in the exporting peer's ontology105to produce the first round-trip value. For example, if the base type320defined by the property type316of the property in the exporting peer's ontology105is a string, then the exporting peer101will attempt to convert (cast) the intermediate value to a string.

At step704, the original property value to be exported is compared to the first round-trip value. If they are the same, then the property can be safely exported to the importing peer and the exporting peer101does so at step705. If they are not the same or an error occurred in simulating the first round-trip, then the mapping in the ontology map110for the property may be incompatible. If an error did not occur in producing the first round-trip value but the original property value and the first round-trip value are not the same, the property may still be safely exported provided the property value will eventually stabilize over multiple round trips. For example, consider a “Name” property type316defined in the importing peer's ontology106of a string base type320that has a component318that prepends the string “Mr.” if the value of the property is determined to be a male name and prepends the string “Ms.” if the value of the property is determined to be a female name. Further assume that the component318will not prepend “Mr.” or “Ms.” if one of those honorifics is already prepended. In this example, a property value that is originally exported as “John Smith” will eventually stabilize to “Mr. John Smith” after two round trips. Accordingly, in one embodiment, the exporting peer101, when the first round trip value does not match the original property value, simulates a second round-trip at step706. If, at step707, the second round-trip value matches the first round-trip value, then the database change can be safely exported to the importing peer102and at step708the exporting peer101exports the database change. Otherwise, the exporting peer101at step709determines that there is an incompatible type mapping for the property in the ontology map110.

Implementing Mechanisms—Hardware Overview

For example,FIG. 8is a block diagram that illustrates a computer system800upon which an embodiment may be implemented. Computer system800includes a bus802or other communication mechanism for communicating information, and a hardware processor804coupled with bus802for processing information. Hardware processor804may be, for example, a general purpose microprocessor.

Computer system800also includes a main memory806, such as a random access memory (RAM) or other dynamic storage device, coupled to bus802for storing information and instructions to be executed by processor804. Main memory806also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor804. Such instructions, when stored in storage media accessible to processor804, render computer system800into a special-purpose machine that is customized to perform the operations specified in the instructions.

Computer system800further includes a read only memory (ROM)808or other static storage device coupled to bus802for storing static information and instructions for processor804. A storage device810, such as a magnetic disk or optical disk, is provided and coupled to bus802for storing information and instructions.