Ontologies for corporate web applications

The corporate world is poised to adopt the use of ontologies in web applications. Languages that allow the semantic annotation of information are becoming widely available; examples include the increasingly mainstream XML as well as newer languages such as the RESOURCE DESCRIPTION FRAMEWORK (RDF), the Defense Advanced Research Projects Agency (DARPA) AGENT MARKUP LANGUAGE + ONTOLOGY INFERENCE LAYER (DAML + OIL), and WEB ONTOLOGY LANGUAGE (OWL) motivated by the notion of a semantic web (Berners-Lee, Hendler, and Lassila 2001).2,3,4,5,6 Commercial organizations are seeking to codify web services using such formalizations as the universal description, discovery, and integration (UDDI) specification.7 There are efforts to standardize intelligent agent technology, such as the Foundation for Intelligent Physical Agents (FIPA).8 These efforts at standardization must use ontologies if emerging internet applications are to be powered by semantics, the meaning behind advanced applications and their enterprise-level and community-level transactions.

In this article, we discuss some issues that arise when ontologies are used to support corporate application domains such as electronic commerce (e-commerce) and some technical problems in deploying ontologies for real-world use. In particular, we focus on issues of ontology integration and the related problem of semantic mapping, that is, the mapping of ontologies and taxonomies to reference ontologies to preserve semantics. Along the way, we discuss what typically constitutes an ontology architecture and provide a short summary of ontology development tools. We situate the discussion in the domain of business-to-business (B2B) e-commerce. By its very nature, B2B e-commerce must try to interlink buyers and sellers from multiple companies with disparate product-description terminologies and meanings, thus serving as a paradigmatic case for the use of ontologies to support corporate applications.

Levels of Representation

The "vocabularies" for ontologies, as discussed in the introduction to this special issue, are distinct at different levels. Table 1 shows that there are a number of meta-object-level distinctions we need to make with respect to the languages. At the highest metalevel is the knowledge representation language, that is, the language one uses to model the ontology content at the underlying object level (the ontology concept level). Examples of a knowledge representation language include languages that preceded the semantic web, such as KL-ONE (Brachmand and Schmolze 1985), CLASSIC (Borgida and Patel-Schneider 1994), LOOM (MacGregor 1991), and other description logics; PROLOG and other logic programming and constraint logic languages (based on Horn clauses); KNOWLEDGE INTERCHANGE FORMAT (KIF) and its International Organization for Standardization (ISO) standard variant COMMON LOGIC;9,10 OPEN KNOWLEDGE BASE CONNECTIVITY LANGUAGE (OKBC) (Chaudrik et al. 1998); CYCL (the language that the CYC ontology is expressed in) (Guha and Lenat 1990);11 and UNIFIED) MODELING LANGUAGE (UML).12 Semantic web languages include RDF/S,13 DAML + OIL,14 and OWL.15 At the second level, the ontology concept level, ontologies are defined using the constructs of the knowledge representation level. When you build an ontology, you define a specific concept (for example, the class (Person): KR:CLASS(OC:Person).16 You probably specify that this class is a subclass of another class you've already defined, (Animal): KR:SUBCLASS(OC:Person, OC:Animal); that is, person is a subclass of animal. At the lowest level, the ontology instance (OI) level, the constructs are instances of ontology concept-level constructs, for example, KR:INSTANCE ((KR:CLASS OC:Person), OI:Person243904). We also observe that many times, the distinction between a concept and an instance is fuzzier than we might initially believe. For example, Harriet Beecher Stowe or a KubotAM120... tractor might be considered a concept, with specific occurrences or references within texts or databases as instances-depending on your logical notion of an individual. A further complication, which is not described here, is to allow classes as instances (Welty 1998, 1995).

Obviously, the machine semantics is simple and inexpressive with respect to the complex, rich semantics of humans, but it's a beginning and very useful for our information systems. By designing and implementing a logical knowledge representation system and ontologies and getting the machine to make inferences that are extremely close to what humans would infer in comparable circumstances, we have imbued our systems with much more human-level semantic responses than they have at present, which is particularly true of B2B applications.

The Nature of the B2B Enterprise

B2B e-commerce is everything that land commerce is, and more: automated support for information and transaction flow and for vertical and horizontal commercial interoperability. B2B e-commerce includes the following: multiple marketplace platforms on the internet that support multiple trading models (auctions, reverse auctions, exchanges, request-for-proposal/request-for-quote (RFP/RFQ), bookstores, trading hubs, and so on) for and by commercial organizations, providing rich information content on products and services for both buyers and sellers (catalogs, product guides, market and domain editorial content, news, advertising) and support for buying and selling; financing; privacy-security; payment processing; order management; profiling-personalization; product configuration; planning-scheduling and forecasting; product life cycle and inventory management; business processes; work flow; and rules, logistics, distribution, and delivery.

Why Ontologies Are Needed for B2B

B2B e-commerce needs ontologies. There are two primary uses for ontologies in B2B e-commerce. First, there is an informational need: Because the ontology is a structured conceptual model of the e-commerce vertical domain (and sometimes, quasihorizontal domains too), it supports parametric search and navigation using product and service knowledge by prospective buyers to discover what to buy and, subsequently, to determine pricing and availability. In this case, the fairly constant knowledge embodied in the ontology maps to the quickly changing data of the vendors. Furthermore, an ontology can model not only product and service knowledge but also knowledge about buyers and sellers, that is, users. By using user role knowledge (sometimes called user profiling or personalization), for example, queries can be customized relative to the user's experience and interests.

Ssecond, e-commerce also needs ontologies for transactional purposes: Knowledge of a company's organizational structure, work flow, processes, and products and services can be used to actually assist in buying and selling directly. For example, figure 1 depicts one view of an architecture and flow of knowledge within a prospective ontology-driven B2B marketplace infrastructure, linking buyers to semantically mapped suppliers using software agents or web-based service-oriented applications for both informational and transactional purposes. In this framework, multiple heterogeneous databases map to a common ontology that thus enables a meaningful comparative view to be displayed to a prospective buyer.

In this figure, an individual business product search agent (this could be a simpler, client application) interacts with a given supplier; that is, it exists on the supplier's site and is responsible for obtaining the data from this site. Each supplier has a database of products (the darkgray cylinders) with its own format, structure, and semantics. The light-gray cylinders represent semantic mappings between the ontology and the specific supplier database.

These semantic mappings take the form of links between ontology concepts and their closest correlates in the supplier database, typically to specific tables, columns, and ranges of values represented by row entries in these columns, but potentially also include scripts to parse and extract specific values from coded values (attribute values are sometimes "packed" into product identifiers, for example, that then act as unique keys in the database) and then routines to transform the data representation into the canonical ontological form (example: meters to feet). The mappings are determined in advance of run-time querying and typically require interaction among ontologists and supplier business analysts and database administrators to establish the semantics on both sides and, thereby, the appropriate semantic mappings. The supplier's business agent uses the semantic mappings to send back relevant data about the supplier's products to the knowledge-commerce broker-server application (it is both a broker and a server, although the two functions could be separated). The broker application interacts with prospective buyers, and it in turn knows about the product and service ontology. A prospective buyer searches for products and services by using the broker, either by querying or navigating a catalog structure. The broker then interprets the buyer's query with respect to the ontology concepts and attributes and, using metadata about both the products and the companies, issues a distributed query to the appropriate business agents. These agents then use their local mappings files to obtain the specific supplier data, apply the necessary transformations, and send it back to the broker. The broker then aggregates the data results and displays them in a normalized form to the prospective buyer, along with desired cost, availability, and distribution and shipping factors.

If the prospective buyer wants to actually buy specific products, these products are added to the "shopping cart." At the end, the buyer can initiate a buying transaction, which triggers other ontological process transactions and inference that satisfy the constraints of the transaction and the individual buyer and supplier business-process requirements.

The use of ontologies in e-commerce thus goes a long way toward solving two problems: (1) the heterogeneous vendor database problem and (2) the standards and common vertical conceptual model problem. For the heterogenous vendor database problem, distributors, manufacturers, and service providers have radically different databases that differ significantly in format, structure, and meaning, as in figure 2. The database community itself has studied this problem for some time (Kashyap and Sheth 1997, 1996; Mena et al. 1998; Smith and Obrst 1999; Wiederhold and Genesereth 1997). For catalog integration using a Bayesian approach, see Agrawal and Srikant (2001); for integrating vocabularies using a Bayesian approach, see Omelayenko (2002). For the standards and common vertical conceptual model problem, what is the meaning of the terminology used in the product and service space and the relationships between terms? That is, what are the concepts underpinning common business terminology, and can this meaning be made sound, consistent, extensible, reusable, modular, and logical?

Ontologies need to be built to support the representation requirements of many applications, all of which presume some form of classification of products and services. Many business classification systems are ad hoc, inconsistent, and nonintegrated, with very little association between classification systems. The distinction must be made between representation and presentation for corporate customers. Representation is the underlying structure and codification of the product and service knowledge space to be supplied by the eventually developed ontologies. This representation should be semantically sound, consistent (although incomplete in the sense that additional refinement could always be made), controlled, modular, and reusable and provide some support for application presentation needs.

Presentation, however, is largely the responsibility of an application. Some applications could choose to use their own terminology and classification display, as long as the terminology and structure have linkages to the underlying representation. An application intended for a buyer, for example, might display different terminology that is differently structured than an application intended for a seller. Furthermore, even within a buyer application, the terminology and displayed structure could be different based on the role of the prospective buyer-user. For example, a technically savvy engineer using a catalog search application would typically use search terminology (or, equivalently, navigation through a classification system or taxonomy) based on technical specifications. Within the ontology, this terminology would be entity centric and use entitycentric concepts. An entity in this usage is typically a thing, that is, a product object. However, a nontechnical purchasing analyst would typically use search terminology based on his/her own company's environment or processes. Within the ontology, the terminology would thus use process- or function-centric representation. For example, although a chemist might search for a particular chemical by using terminology about chemical properties or formulas, a paint buyer for an automobile or aircraft manufacturer would search using notions of heat resistance, rust inhibition, and color. In either case, however, the navigational path used (by relational links or inference) should arrive at the identical, parameterized product or service. Ontologies would thus at least partially support multiple ways of presenting the product and service information. Typically, in an ontological approach, one could have separate "views" or "contexts" (we prefer the word contexts to distinguish it from the normal database view) that would explicitly be representable as a separate ontology or theory (we use these terms interchangeably) that just "uses" concepts represented in other ontologies, that is, in other portions of the entire ontological space. In fact, our discussion later on about the mapping problem is relevant to this notion, too, because it really is a semantic mapping established between the representation and the presentation. The presentation can be arbitrary application-specific terms, but they still need to be "represented" either internally in the underlying ontology or externally in some associational data structure that has a mapping to the ontology.

Figure 3 displays a prospective notional ontology architecture that displays the relationships among portions of the whole ontological space. The highlighted areas of the ontology are those usually deemed most appropriate for B2B e-commerce and include both products and processes. However, this architecture is only a simple educational device; the reality is much more complicated. Of course, it soon becomes evident when working as an ontologist in the product and service space that everything becomes relevant, from the upper-ontology notions (Guarino and Welty 2002) of part and whole (mereology),17 notions of necessity and sufficiency of properties, distinguishability, change of properties, task, and process concepts, to so-called middle-ontology notions of product and service, to domain-ontology levels. Nearly everything can be considered a domain ontology in the experience-induced general view practical ontologists end up with. Everything is a theory (ontology), and every theory (ontology) can possibly be related to every other.

The vision, of course, for using a common representation is to enable a consistent ontological or conceptual search across data and applications, so that semantically meaningful documents and data concerning products and services are returned to the user. This search, by definition, included the notion of parametric search, which is related to the notion of product configuration, that is, a search informed by ontological and other properties of the searched-for product or service. Correspondingly, a common representation supports ontological classification of products and services: search assisting primarily buyers, product classification assisting primarily sellers.

Ontologists, Domain Experts, and Ontology Architecture

Domain experts provide the knowledge for the ontologies. Ontologists determine how to represent this knowledge. Ontologists usually teach domain experts some of the fundamental concepts about ontologies and ontological engineering, along with how to use ontology editing tools. In an intensive, time-limited B2B development effort, ontologists and domain experts can begin working simultaneously, with all team members acting productively as quickly as possible, with minimal time for planning. Under these circumstances, as soon as domain experts begin creating domain ontologies unassisted, ontologists can shift their responsibilities to tasks optimally done in advance of ontology development: formulating designs for an overall ontology architecture, setting guidelines for building ontologies, integrating the ontologies with applications, and enhancing the ontology-building environment to make the ontologies more expressive and more maintainable. Ontology development can be considered a type of software development and thus should follow the general principles of the software project life cycle. Emerging ontological methodologies (Fernandez, Gomez-Perez, and Juristo 1997; Gruninger and Fox 1995); Uschold and King 1995) should be used.

Referring back to figure 3, we see the typical organization of an ontology architecture. This architecture applies not only to B2B e-commerce but also more generally to any ontology-supported application area needing rich semantics.

The upper ontology (or set of integrated ontologies) is the layer that tries to characterize very basic commonsense knowledge notions. This layer makes distinctions between tangible object and intangible object, real geophysical terrain and map, the different relations of part-of (mereology) and connected-to (topology), and notions of space and time (point or interval based, dense, branching, and so on). There is a current effort under the Institute of Electrical and Electronics Engineers (IEEE) to standardize an upper ontology(ies) that would then be freely available to any ontological engineer seeking to build domain ontologies.18 The middle ontology layer represents knowledge that spans domains but possibly not every domain. An example is information technology, which might not apply to a domain such as marsupials but might apply to the domain of ethology (animal behavior) or ecology. The lower ontology consists of domains and sub-domains, for example, medicine and pediatric medicine.

The Mapping Problem

In this section, we briefly discuss one crucial issue in developing ontologies to support B2B e-commerce: the problem of mapping reference ontologies with well-defined semantics to other ontologies, taxonomies, and standards-based classification systems that are less semantically sound and coherent. The semantic mapping problem has a long and growing history because it is a difficult problem across many communities: the database, the thesaurus, and the ontology communities (Doerr 2000; Falkenhainer, Forbus, and Centner 1990; Haas et al. 1999; Mitra, Wiederhold, and Kersten 2000; Musen and Noy 2002; Omelayenko 2002]; Rahm and Bernstein 2001). One IEEE standard upper ontology (SUO) candidate, the information flow framework,19 based on Barwise and Seligman's (2000) information flow theory, in fact is an elaborate metaontology to facilitate ontology integration in a very general way based on category theory.

Ideally, ontologies provide a semantic infrastructure that can be used for all applications. To provide this semantic framework across the applications and data of an e-commerce business (independently developed and without commitment to ontological infrastructure), existing and planned information resources must be connected to the ontology framework. We term this connection a mapping. A mapping is a many-to-many relationship between source data and an ontology. Sources for mapping could be another ontology, some standard taxonomy, or an application's data structures.

Figure 4 illustrates a mapping. Solid lines indicate a well-defined subclass relation in the ontology (right) and the taxonomy (left); the solid line represents a parent-child relation with ill-defined semantics. The heavy, dotted lines without arrows represent other ontological relations. The thin, double-arrowed lines depict a mapping between nodes in the ontology and data structures in the application taxonomy.

On the left, an e-commerce application uses a taxonomy with ill-defined semantics to represent some information. For example, node Z could represent some industrial process. Node Y could represent products resulting from this process, X the equipment used in the process, and W the employees involved in the process. The relation between nodes is an undefined parent-child relation with no inheritance; the information is used in the application to group these related concepts together. On the right, an ontology represents much of the same information but with a well-defined semantics for each relation. For example, nodes B and C could represent products resulting from the industrial process A. The relation between A and these nodes is not subclass; it might be "generated-from," assuming the semantics of this relation was defined. Because B and C are products, they are subclasses of a more general product node (M), perhaps in a middle or upper ontology. Unlike the application taxonomy, a different, well-defined relation relates A to D, and so on.

One criticism of this scenario is that the application taxonomy is deficient. In other words, what is needed is not a mapping but a clearly defined semantics in the application taxonomy. With such a definition, some automated merging process could (conceivably) merge the nodes. However, practically, such merging is not possible.

Mappings provide an intermediate solution to this problem. Once Z is mapped to the ontology, other applications can recognize that Z is similar to A. This example is only one of several different kinds of mappings typically encountered when attempting to use ontologies to support applications. The following sections explore three different kinds of mappings: (1) taxonomic standard to ontology, (2) application to ontology, and (3) ontology to ontology. We consider the different types of mapping separately because the more well defined the semantics of the source to be mapped to the ontology, the more straightforward the mapping process and the more semantically rich and powerful the resulting mapping.

Taxonomic Standard to Ontology Mapping

An e-commerce company will use open standards whenever possible simply to facilitate interaction with other companies. A case in point is the use of the Universal Standard Products and Services Classification (UNSPSC).20 The UNSPSC hierarchy includes some 11,000 codes representing a taxonomic structure given by segment, family, class, and commodity. For example, segment 32 is "Electronic Components and Supplies;" family 3210 is "Printed circuits and integrated circuits and microassemblies."

Because no attributes are currently (which is changing) associated with nodes in the UNSPSC, one has to develop attributes. Furthermore, e-commerce typically needs substructure below the lowest level of the UNSPSC (commodity level) to specify products and their properties in some detail. Because the UNSPSC was originally developed not to reflect a buyer or seller's perspective but to permit financial roll up for accounting purposes, the taxonomy is inadequately defined semantically for ontology purposes. Still, one wants to map to the standard to support companies that adhere to it. One solution is to use Nebenstruktur (shadow structure), which links the more semantically well-defined reference ontology (developed from an industry supplier and buyer perspective) to the UNSPSC (figure 5). These links can be provided by overloading subclass inheritance, thus allowing the inspection or extraction of a purely UNSPSC-based taxonomy with attached attributes and substructure. Attributes can be defined for classes in the reference ontology. By having classes (or subclasses defined below the bottom-most nodes) in the UNSPSC ontology be subclasses of the reference ontology classes, the reference attributes are inherited down to the UNSPSC nodes. One variation on this arrangement is to "type" the relations used in the entire ontological space with distinct, transitive subclass relations for every nonreference ontology supported and, thus, mapped to.

Application to Ontology Mapping

Any application data might need to be mapped to an ontology. Before considering how to approach such mappings, the goals for creating the mappings and their use should be identified.

Representational adequacy: A mapping solution should represent the mapping between the source and ontology completely and consistently. Completeness implies that any information in the application that could be queried by an external application has been mapped. Consistency implies that the most appropriate node in the ontology is mapped to the external structure. In some cases, this requirement means creating new ontology nodes. Thus, there is a tension between completeness and consistency that must be resolved by the methodology for mapping.

Heuristic adequacy: A mapping solution must be relatively easy to create and convenient to access. Because the mappings will be dynamic (application data and ontologies will be changing over time), an individual mapping should not require significant computation or user interaction.

One representation: A mapping solution should not introduce duplication in representation.

Knowledge engineering cost-automation support: A mapping solution should not increase the work load or day-to-day activities of ontologists and domain experts. Thus, the solution should provide support to automate mappings. Because not all mappings can be automated, an infrastructure for mapping should be developed that will allow nondomain or nonontology experts to create mappings that cannot be done automatically.

Given these goals, how should the mappings between an application and an ontology be implemented? We consider three possibilities: (1) the mapping table, (2) the model of application, and (3) the applications mapped within the ontology.

Mapping table: A simple way to establish a mapping would be to create a table (for example, in a database) in which each row of the table indicates an association between some application data structure and the ontology. The table could support many-to-many mappings by duplicating either an application structure or an ontology node in some rows. Completeness can easily be determined by ensuring that each application structure in the table is mapped to at least one ontology node.

Model of application: Figure 6 shows an example of building a model of the application in an ontology. All ontology-relevant application structures are included in the ontology model. A mapping relation is introduced that defines the association between an ontology node and nodes in the application model. In this approach, there is an ontological concept such as claw hammer, an application-specific concept hammer as used in carpenter's catalog XYZ, and a mapping relation that conveys the information that the "hammer as used in Catalog XYZ" corresponds to the claw hammer node in the ontology. The subclass relation can be used to represent the relations in the application ontology because the application concepts in the application taxonomy (rather than in the ontology proper) are subclasses in the context of the application. That is, hammer in the XZC Catalog might be a direct subclass of tool in the same catalog, even though in ontological space, there is much more distance between these concepts.

Application mapped within the ontology: Figure 7 illustrates another mapping solution. In this case, an application-specific mapping relation relates nodes in the ontology to their use in an application. The claw hammer node in the ontology is now not only related to other nodes in the domain ontology using domain relations (for example, claw hammer is a subclass of hammer) but also to nodes using application relations (claw hammer is a type of product in carpenter catalog XYC).

A complete analysis of these approaches is beyond the scope of this article and would include notions of ontology mapping and merging and context. The mapping table solution is simple to implement but lacks powerful connections to the ontology that could potentially help automate the maintenance of mappings as the ontologies and applications change. The increasing power of the other two approaches places demands on the representation of the mappings: Because the ontologies themselves are being changed, ontologists will need to be closely involved in the representation of the models and mappings, in addition to defining mapping relations.

Also, formal application requirements are required to determine how powerful the resulting mappings need to be. For simple interlingual (that is, as an intermediate language) use of the mappings, the mapping table appears to be a sufficient solution. The other approaches have higher initial costs but perhaps can be maintained more easily and certainly will provide a more powerful substrate for reasoning because both the structure of the application, as well as its data, is represented (explicitly in the model approach, implicitly in the internal approach).

Conclusion

We presented some issues in the development of ontologies for use by corporate web applications and in particular have focused on the example of B2B e-commerce, where the ontologies that are developed will typically be in the product and service space. We discussed the typical ontology architecture. We also looked at one problem in particular, the ontology or semantic mapping problem, and investigated some possible solutions. This problem will always need to be resolved by these developing ontologies to support corporate applications, given the disparate nature of these applications in the real world. Despite these problems, however, we remain convinced that the increased use of ontologies in the corporate world is inevitable. Given the increasingly complex requirements of applications, the need for rich, consistent, and reusable semantics, the growth of semantically interoperable enterprises into knowledge-based communities, and the evolution and adoption of semantic web technologies, ontologies represent the best answer to the demand for intelligent systems that operate closer to the human conceptual level.

Acknowledgments

We would like to express our appreciation for the encouragement and support we have received from many individuals, including our colleagues Pat Cassidy, Lisa Colvin, Don McKay, Mike Molloy, Jon Pastor, Eric Peterson, Lori Wilson, Yao Zhu, Craig Schlenoff, Ugo Boggio, Randy Clark, Frank Manshedi, Ashwin Parikh, Keith Thurston, Joe Whelan, and Christy Obrst as well as the anonymous reviewers. We also note that the views expressed in this article are those of the authors alone and do not reflect the official policy or position of The MITRE Corporation or any other company or individual.