In an ontological model, classes describe sets of real-world entities with common properties. For example, PowerPlant is the set of power plants and Energy represents the concept of energy as described in physics. Moreover, a class can inherit from another class: For example, a State inherits from Region. Properties describe the links within these entities. For example, a PowerPlant has an output linking it to a unit of Energy. It is also possible to have properties with values that are simple strings and numbers, such as the name property of PowerPlant and the wattHours property of Energy. The properties are constrained and linked together by business rules. Examples of business rules include:

Note that ontological concepts describe the real-life business environment: unlike schemas, which describe how strings must be arranged in an XML document, an ontological model is targeted at expressing a common business view of the concepts important to the organization or the industry which uses the model.

Ontological models as described above are now appearing more and more frequently in various industries. The theoretical basis for the science of ontology has been building in the academic world for decades; and in the last ten years, the practical applications of ontology have been emerging in the business world. Recently, ontological modeling received the imprimatur of the World Wide Web Consortium, which standardized the XML encoding of ontology in Web Ontology Language (OWL), formerly known as DARPA Agent Markup Language/ Ontology Inference Language (DAML+OIL), (See [OWL03]).

The model expresses the business domain, and the schemas express the data formats used for data transmission or storage. To assign meaning to the schemas, the analyst maps them to the model. This is done by mapping XSD complex types or simple types to classes, and XSD elements and attributes to properties.

The mappings themselves adds significant value to the semantic architecture. In fact, every integration project involves the discovery of the meaning of each schema element, but this is generally done informally and written up in a word processor document, if at all. The formal method which the semantic architecture demands is simply a reusable way of capturing this information, so that semantic values become reusable in all future projects both by humans and by automated processes.

The XML encoding of mappings is not as standardized as OWL for Ontology. However, the Resource Definition Framework (RDF) is a standard format generally applicable to expressing relationships between concepts, and so can be used for linking schema concepts to ontological concepts.

The model, the schemas, and the mappings between them together form a system for automated discovery of the schemas that meet the needs of a given project, whether for messaging, application interfaces, or storage. The automated search begins with the real-world classes and properties that must be included in the schemas. The algorithm traces the mappings in reverse, finding schemas holding the relevant types, elements, and attributes that express these meanings. Accidental similarities in terminology will not show unwanted schemas, nor will differences in terminology cause relevant schemas to be lost in the search.

In some cases, no schema can be found with all the needed elements. However, there may be a schema which does include functionally equivalent elements, when business rules are taken into account. When two properties have been declared equivalent, or one property can be converted to another with a mathematical business rule, then a schema can be reused, as long as a simple transformation is done.

An example will illustrate the process of building a semantic architecture and using it for semantic discovery of schemas (see Figure 1 and Section 2.5, “Example Schemas ”). For illustrative purposes, this example is much simpler than a typical enterprise deployment, but it does illustrate the principles involved.

In this example, there are three schemas, called Alpha, Beta, and Gamma.Their identifiers do not convey their meaning, but we need to find schemas suitable for EAI messages in a specific application for the energy industry. Alpha and Beta both describe power plants, although they arrange the information in different ways. The structure is different, as are the units used for power and energy. Gamma has a root element plant, but this is misleading, as it is meant to describe trees -- but nothing in the schema makes this clear.

The schemas are mapped to the model. For example, schema Alpha's power-plant, with attributes location, output, and capacity, are mapped to class PowerPlant with properties location, annualOutput, and capacity. This mapping has express, for example, the simple fact that the XML attribute output has the meaning of "output", but also that this is the annual output of the plant.

Further, by mapping to ontological properties of class Energy and Power, the units that are intended in the XML attributes are described and converted where necessary. In our case, if the capacity is to be expressed in in watts, the necessary arithmetic conversion, which is encoded in the model, allows the utilization of a schema whose capacity uses kilowatts instead.

Figure 1. Semantic Discovery of Schemas

This architecture is ideal for locating the schema which answers the need of a specific project. Since a typical large organization has hundreds of schemas related to any problem domain, it is quite likely that a suitable one will be found. When no such schema is found, the semantic architecture can generate a schema, structuring complex and simple types according to the relevant classes, and structuring elements and attributes according to the properties. For example, if the schema must represent a power plant with name and capacity, then the starting point is the class PowerPlant and the properties capacity and kilowatts; using the semantic mappings, a schema is constructed appropriately.

As mentioned above, when a schema does not exactly meet the requirements, it can sometimes nonetheless be repurposed though transformations derived from business rules in the model. The semantic architecture can also be leveraged for transforming between two schemas, as in an EAI scenario where the output of one application must be transformed to the input of another. This usage of the architecture was the subject of my talk at XML Conference 2002 and is described in detail in my recent EAI/Business Intelligence Journal article (see [JF02] and [JF03]).

This technique can be applied to all enterprise data which is described by schemas, including data other than XML. For relational data, tables take the role of complex types, and columns take the role of elements or attributes. Likewise, for UML diagrams describing application interfaces, classes take the role of complex types and attributes or associations take the role of elements and attributes. The semantic discovery technique can be constrained to search out a specific type of schema, or to find all schemas of any language that express the required meaning.

Another application of the semantic schema discovery architecture is Web Service discovery for B2B or internal integration. Web Services are meant to be loosely integrated, which should mean that developers can create their Services independently and integrate with each. However, Web Services are often developed in isolation in separate departments or organizations, and must later be used together. Just as the semantic architecture can be used for locating schemas, so too can it be used for locating Web Services that use the schemas as the input or output of their operations. In this way, a UDDI search can go beyond taxonomies or the syntax of WSDL to a full search on the meaning of the desired Service. (For more detail, see Borenstein and Fox, "Semantic Discovery for Web Services" [JBJF03].)