Finding the Information

One of the benefits of leveraging ontologies is the fact that no matter where the information resides, we can understand and map information relevant to the application integration scenarios. Ontologies allow you to differentiate between resources, which is especially useful when those resources have redundant data (e.g., customer information in almost all enterprises). Thus, in order to make better sense of the data and represent the data in a meaningful way, terms defined in ontologies allow the application integration architects to fully understand the meaning and context of the information. Again, this is ontology's value within application integration.

When considering schemas, local to remote source or target systems, the application of ontologies is leveraged in order to define the meaning of the terms used in some domain. Although there is often some communication between a data model and the attributes, both schema and ontologies play key roles in application integration because of the importance of both semantics and data structures.

If you've ever seen an application or database schema, you know this to be true:

• The terms we leverage in schemas are often cryptic.

• If ontologies are not bound to the technology, they can better represent the meaning of the data.

• This makes application integration technology much more productive.

However, you must also take the time to define a relationship between the ontologies and the physical application or database schema: the purpose of mapping as we mentioned above. Remember, no matter how the information is structured physically, or how the schema is represented, the mapping must occur to leverage ontologies properly.

Another important notion of ontologies is entity correspondence. Ontologies that are leveraged in more of a B2B environment must leverage data that is scattered across very different information systems, and information that resides in many separate domains. Ontologies in this scenario provide a great deal of value because we can join information together, such as product information mapped to on-time delivery history, mapped to customer complaints and compliments (see Figure 19.1). This establishes entity correspondence.

Figure 19.1. Leveraging ontologies in a B2B domain using entity correspondence.

To gather information specific to an entity, we need to leverage different resources to identify individual entities, which vary widely from each physical information store. For example, when leveraging a relational database, entities are identified using keys (e.g., customer number). Within the various information systems, many different terms are used for attributes. The notion of ontologies, in this scenario, allows us to determine whether entities from different applications and databases are the same or noncrucial to fusing information.

Ontology and Mapping Servers

So, how do you implement ontologies in your application integration problem domain? In essence, some technology either an integration broker or applications server, for example needs to act as an ontology server and/or mapping server.

An ontology server houses the ontologies that are created to service the application integration problem domain.^[6] There are thee types of ontologies stored: shared, resource, and application ontologies. Shared ontologies are made up of definitions of general terms that are common across and between enterprises. Resource ontologies are made up of definitions of terms used by a specific resource. Application ontologies are native to particular applications, such as an inventory application.

Mapping servers store the mappings between ontologies (stored in the ontology server). The mapping server also stores conversion functions, which account for the differences between schemas native to remote source and target systems. Mappings are specified using a declarative syntax that provides reuse.

^[6] From the DOME Project.