An Ontological Approach to Evaluating Standards in E ... - CiteSeerX

846

IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICS—PART C: APPLICATIONS AND REVIEWS, VOL. 37, NO. 5, SEPTEMBER 2007

An Ontological Approach to Evaluating Standards in E-Commerce Platforms Conan C. Albrecht, Douglas L. Dean, and James V. Hansen

Abstract—This paper identifies and defines standards required for successful e-commerce (EC) platforms. It presents an ontology of standards and applications that can be used to evaluate any EC platform. Current platforms are limited in usefulness and development economy by lack of standards. We describe how the development and use of such standards could help improve EC platforms. We examine the current and emerging platforms and technologies in relation to the proposed ontology including electronic data interchange, e-procurement systems, business-tobusiness hubs, company Web sites, Electronic Business eXtensible Markup Language, Web Services, the semantic Web, and Universal Business Language. We conclude that no individual platform or technology provides complete support for every level of the ontology, and we suggest that combinations of features from various platforms and technologies may be of most value. We conclude that research is needed in three areas: the discovery phase of EC, participant incentives for standardization, and methods of combining useful aspects from different standards bodies. Index Terms—Business-to-business (B2B) e-commerce (EC), electronic data interchange (EDI), electronic markets, information infrastructure, procurement, standards, strategic IS, Web services (WS).

I. INTRODUCTION OR MORE than three decades, businesses have been using electronic mechanisms to exchange transaction data. Standards have played an integral role in the success of most, if not all, e-commerce (EC) models. In this paper, we present a background on standards in EC as the basis for constructing an ontology for assessing the standards required for a global, ubiquitous EC network. This ontology is then applied to the evaluation of current and emerging EC platforms and technologies and to framing areas of promising research. This paper focuses on business-to-business (B2B) EC, which accounts for the largest dollar volume of EC, with about $700 billion in transactions in 2001. The Gartner Group estimated that all types of EC transactions would exceed $8.5 trillion by 2005, 90% of which will be B2B transactions [1]. In a similar vein, Jupiter Research estimated that the combination of B2B, and business-to-consumer (B2C) EC transactions would surpass $7 trillion by 2005 [2]. Recent statistics from the U.S. Census Bureau [3] for the first quarter of 2005 show total EC transactions worth $19.798 trillion. The Census Bureau does not break

F

Manuscript received March 14, 2005; revised September 22, 2005. This work was supported in part by the Rollins eBusiness Center at Brigham Young University. This paper was recommended by Associate Editor B. Chaib-draa. The authors are with Marriott School of Management and Rollins eBusiness Center, Brigham Young University, Provo, UT 84602 USA (e-mail: [email protected]; [email protected]; [email protected]). Digital Object Identifier 10.1109/TSMCC.2007.900664

out the portion due to B2B, but if the 90% B2B estimate of the Gartner Group holds, the corresponding value for the first quarter of 2005 is about $18 trillion. Viewed another way, the actual B2B proportion would only have to be in the range of 10% to achieve the forecasts made by Jupiter and Gartner. The statistics further show that the growth in EC transactions has averaged 6% annual growth since 2001. Evidence of significant growth is undeniable. Standards are essential to EC because adherence to them enables heterogeneous computers to exchange information reliably and rapidly across networks. Standards are the key to interoperability between EC systems [4]. When this occurs, human operators can focus their efforts where they provide real value: specifying search parameters, evaluating options, using judgment to make decisions, and approving transactions. Useful standards, if adhered to by participants, allow computers to better accomplish their supporting role of finding possible suppliers, gathering comparative product and service data, and executing transactions. Two mechanisms achieve compatibility between automated systems: standardization and conversion [5], [6]. Standardization may be achieved through independent actions of market participants, through formal coordination of participants in voluntary industry standards committees, or through government action. In contrast with standardization, converters change a format from one form to another [6]. Farrell and Saloner [5] note that standardization and conversion have different costs. Standardization requires time and coordination expense during the creation and refinement of standards. Standardization also imposes costs on entities that have sunk investment in legacy technology that is incompatible with an emergent standard [7]. Thus, standards require high upfront costs, but subsequently, reduce costs because only one standard needs to be adhered to. Conversely, the development of converters requires low upfront costs but high subsequent costs, especially when many converters are required because of the existence of many incompatible formats and systems. Each conversion between each pair of incompatible formats requires a converter. And when a system’s format changes for any node (system), multiple converters must be updated. For example, conversion among five formats requires ten two-directional converters. When any system’s format changes, each related link must be updated accordingly. The cost to develop and maintain converters quickly becomes prohibitive. Importantly, the existence of standards dramatically reduces the costs of developing and buying converters. In contrast, only one two-way conversion is necessary for each system when all systems translate to a shared standard.

0090-6778/$25.00 © 2007 IEEE Authorized licensed use limited to: Reza Mohammad Hashemi. Downloaded on September 25, 2009 at 17:18 from IEEE Xplore. Restrictions apply.

ALBRECHT et al.: ONTOLOGICAL APPROACH TO EVALUATING STANDARDS IN E-COMMERCE PLATFORMS

Well-defined standards also allow for economy of tool development. For example, because of the existence of electronic data interchange (EDI) standards, software firms had an incentive to develop converter software that complied with standards. Organizations wishing to adopt EDI benefited from competition among the developers of EDI converters whose products compete on the basis of ease of use, ease of implementation, and cost. Another benefit of standards is that they reduce reliance on specific development environments and application programming interfaces (APIs). Standards allow client and server systems to be loosely coupled. Loose coupling means that an implementation change in one EC participant’s software does not affect other participants’ implementations. Clients are still able to access server resources in predictable ways. Previous distributed client–server applications called for a distributed object model such as Microsoft’s DCOM or the Object Management Group’s CORBA. Distributed object models did not scale well to the Internet because they tightly coupled the consumer of a service to the service itself. That is, clients called implementationspecific APIs to access the server’s capabilities. This tight coupling made connections brittle in the sense that a change to an implementation in one part of the network required other network participants to recode their software. For example, assume that a software company produces a software development environment that an EC participant used to develop a server application. If the software company goes out of business, the EC participant is forced to move to a new development environment for the server application. Since client applications were previously programmed to interact with the server through APIs that were specific to the old server environment, client applications would require reprogramming to connect to the new server interface. The connection would be brittle because a change to the implementation method on the server side or client side makes the connection inoperable. Ideal services are loosely coupled. That is, local changes in a system component should not easily ripple to required changes by other participants. The key to making loosely coupled systems work across the heterogeneous infrastructures on the Internet is to agree to a set of standards that support communication without impeding innovation. For example, the contents and format of an automated product inquiry and the response to that inquiry should be standardized and shared. In this way, the product inquiry could be produced by a variety of implementations. The same would be true for the inquiry response. The remainder of this paper is organized as follows. First, we present the components and capabilities of a theoretical ideal EC platform. Second, we describe the standards and applications that make up the ontology. Third, we give examples of how standards-supported EC applications would operate. Next, we examine current and emerging platforms and technologies in light of the ontology. We conclude with suggestions for future research. II. IMPROVED EC PLATFORM In this paper, we recommend an improved approach to EC where any platform consisting of a client, server, registry, and

847

index is made more useful by a set of supporting standards. We develop these recommendations into an ontology, and then, evaluate existing platforms against the ontology. We define EC platforms as a set of technologies capable of supporting high volumes of EC transactions. The existing EC platforms discussed in this paper include EDI, e-procurement systems, B2B hubs, and company Web sites. For illustration purposes, consider a product search example that demonstrates the important role of standards across a platform. An electronics retail store desires to find all wholesalers and manufacturers that sell color televisions (TVs). The retailer also wants to determine the features, prices, and availability of these TVs. After finding and evaluating available sources to identify the specific TVs to be purchased, the retailer wants to execute a purchase order for the TVs across the EC platform. This process can be generalized into three steps: discovery, negotiation, and execution. First, the retail store must discover potential sellers. To accomplish this, the buyer needs to be able to search a registry that contains a list of businesses that sell TVs to retailers. Computer applications require the following explicit standards to reliably perform discovery. These standards include the following. 1) A shared semantic meaning of the terms TV, manufacturer, and wholesaler. 2) A business categorization scheme to differentiate manufacturers of TVs from manufacturers of other products (e.g., bicycle tires, candy bars, etc.). This supports one method of finding TV sellers: searching by business type. 3) A product representation scheme to define the data fields of TV products, such as screen size and type, resolution, weight, number of channels, stereo/mono, warranty, etc. The buyer could then use these fields to specify specific search criteria in a client application when searching for specific types of TVs. Product information in standard fields with understood semantic meanings would provide search capabilities that are not possible in today’s EC platforms where a variety of names are given to similar or equivalent information. With standard semantic meanings, it would be possible to find all 32-in plasma stereo color TVs with three-year warrantees in a single search. This supports a second method of finding TV sellers: searching by product or service type. 4) A standard method of coordinating interactions among the buyer’s applications, the seller’s applications, and the registry across the network, including how the client contacts and submits search requests to the registry and how the registry responds with answers. 5) A common language within which to express and represent the semantic meanings of information items described in items 1, 3, and 4. 6) A repository to store information about participants in terms of business type and the product types offered by each participant. A registry should provide access to this information. Even in true peer-to-peer networks, a logical registry exists across distributed participants. 7) An index that queries the registry to identify and make available for efficient search the types of TVs sold by each

Authorized licensed use limited to: Reza Mohammad Hashemi. Downloaded on September 25, 2009 at 17:18 from IEEE Xplore. Restrictions apply.

848


vendor, including specific product features associated with each TV. Such an index provides a rapid way for a buyer to find sellers that sell a specific type of TV. Assuming the computer application successfully queries the registry for sellers of TVs, it must negotiate technical and business protocols with the partner. This stage answers questions regarding the technical standards used to communicate between computers on each side as well as questions about the business processes involved, such as the order and format of request for quotes, purchase orders, etc. The negotiation stage requires the following standards. 8) A set of shared transaction templates. These templates represent standard method calls, message formats, field names, data types, and the organization of these fields into meaningful transactions such as request for quote, purchase order, and invoice. 9) Standard business protocols. These include the choreography of standard business transactions, including approved sequences of messages and responses. These would also include protocols for legally binding transactions. 10) The ability to use the common language, semantic terms, transfer technology, and other standards already required in the discovery stage. Finally, after discovery of potential business partners and negotiation of protocols, the buyer and seller execute transactions with one another (e.g., requests, purchases, etc.). This requires execution technologies that can understand and adhere to the aforementioned standards, make network connections, and transfer transaction documents.1 The standards and features described earlier are not fully realized in current EC platforms. This deficit imposes costs in three fundamental ways. First, it limits search precision, scope, and reach. Sellers and specific products cannot be reliably found by automated means on these platforms. Second, it limits transaction support because computers lack a standard way of sharing specific types of information and transactions (Albrecht, 2005 #124).And finally, it results in extremely high software development efforts because the lack of standards in any area on the entire EC process causes coupling. For example, if no standard representation of a purchase order exists, a retailer must program its client software to understand each supplier’s specific electronic purchase order. Changes in supplier representations require costly reprogramming of the retailer’s (as well as all other TV retailers’) software. We appreciate the difficulties of standardizing some areas of the EC process across industries, cultures, and technologies. Indeed, the government, private, and academic communities have been working on EC platforms for many decades. Despite the difficulties involved, it is important that an improved ontology supported by standards be developed as a benchmark that can be used as a guide when evaluating current and future EC platforms.

Fig. 1.

Standards ontology for generalized EC.

III. ONTOLOGY FOR EC STANDARDS EVALUATION Obrst et al. [8] present a compelling case that the use of ontologies in EC are essential to resolving the standards problems of B2B. The word ontology dates back to its philosophical roots in the seventeenth century when it was defined as the “kinds and structures of objects, properties, events, processes, and relations in every sphere of reality” [9]. More recently, the term ontology has been adopted by the information systems and business communities, where it has been defined as the formal specification of concepts and relationships that enable a shared and common understanding of a domain [10]. In particular, sharing a common understanding of the structure of information among people or software is one of the principle goals in developing ontologies [11]. We note that there are both coarse-grained and fine-grained ontologies [12]. A coarse-grained ontology, such as we use here, consists of a limited set of concepts to support a specified type of knowledge intended to be shared among users who are familiar with the underlying conceptualization. A fine-grained ontology is often used where the objective is specific software implementation. Items such as government regulations, dysfunctional competition related to standards, and other real-world impacts are not part of this ontology. Basing an ontology on such items would bias it toward certain conditions that change over time and place, and would limit its general usefulness.We expect that designers of EC implementations will adapt the ontology presented here to their specific circumstances, limitations, and regulations. Our approach is similar in spirit to that of Omelayenko [13], who developed an ontology for supporting the evaluation of product and catalog standards for B2B products. In a similar vein, we propose a general EC standards ontology comprising two groups of standards, marketplace standards and foundation standards, and two applications that depend on those standards (Fig. 1). While there are other possibilities, we suggested this particular ontology in a recent paper [14], and explore it and its implications in more detail in this paper. A. Foundation Standards

1 While

the example describes the scenario of a retailer buying from wholesalers and manufacturers, other types of commerce such as B2C also require the standards for efficient search and application support.

Foundation standards are essential enablers for marketplace standards and services and applications shown in Fig. 2. The



Fig. 2.

Efficient EC platform supported by standards: aggregator example.

following three foundation standards are essential for reliable, predictable EC communication. 1) Data type standards define the possible data types in a system. Participants must share a common definition of string, date, integer and real numbers, and other simple and complex data types. Data type standards do not provide semantic meanings for terms such as product or unit price, but rather specify the basic data types that can be used for such fields. 2) Expression languages (ELs) define rules for data representation. For example, in the eXtensible Markup Language (XML), data are delimited within hierarchical relationships [15]. Conversely, in the CSV [16] EL, fields and records are delimited with commas and hard returns. ELs may be used by designers and standards bodies to define data patterns in forms that enable computers to communicate in predictable and robust ways [17]. 3) Communication methods define how data are physically transferred from one machine to another across a network. Examples of common methods include hypertext transfer protocol, file transfer protocol, and Internet Inter-Orb Protocol. Communication standards should include methods of encryption and authentication for secure transfer of information. Most communication methods have a secure version of the standard method, e.g., HTTP and HTTPS. Because systems like paired-key encryption and authentication are in wide use today, we include security in communication methods rather than make security a standard of its own. B. Marketplace Standards Marketplace standards include product and service representation schemas, transaction templates, and business categories. The creation and widespread adoption of useful standards for these three areas would have a powerful effect on improving EC efficiency. However, these standards are difficult to define and adopt. Powerful organizations sometimes compete to con-

849

trol the definition of standards, leading to competition among multiple existing standards as to which will be most widely adopted [18], [19]. In addition, the diverse needs of participants complicate the adoption of standards. Despite these complexities, definition of the following three standards would significantly benefit EC systems. 1) Business categorization schemes allow discovery technologies to index participants by type and name. Example business categorizations include the North American Industry Classification System (NAICS) [20] and the United Nations Standard Products and Services Code (UNSPSC) [21]. While a ubiquitous business categorization system is difficult to create because of diverse industries, discovery services must rely upon some type of categorization scheme. Moreover, because organizations are sometimes involved in multiple business lines, an organization must be able to be listed in multiple categories. 2) Product and service representation methods allow businesses to describe attributes of the services they offer and of the products they sell. Known schemas are the basis for discovery of specific products and services. Inconsistencies in representation make it very difficult for computer applications to find and evaluate sellers of specific products and services [22]. EC systems become increasingly searchable when organizations within industries describe their services using common schemas. Schemas include field names, field definitions, and data types. For example, fish suppliers need useful schemas to describe the types of fish they sell, whereas accounting firms needs schemas to describe the different accounting services they provide. Many industries buy and sell commodities and quasi-commodities that are well suited for standardized product description formats [23], [24]. 3) Transaction templates are meaningful combinations of data fields to represent common transactions. In terms of automated support for EC, three categories of transaction templates are important. First, method calls and message formats initiate conversations between systems and acknowledge that messages have been received. Second, informational transactions help buyers and sellers evaluate organizations and products. These include transactions that access product features, cost, and availability. Information transactions improve overall market efficiency by providing useful market information. Third, consummation transactions relate to the actual consummation of purchase. These include transactions that buy, coordinate delivery, and remit payments. As discussed in Section I, the existence of standard transaction templates enables developers of heterogeneous systems to create software to translate data to and from each standard transaction format. The existence of these standards eliminates the need for system-specific or development-environment-specific implementations because once the formats for calls and messages have been defined, they can be produced and received by many different implementations. Because of this, buyers can exchange transactions with many sellers rather than having to write translation routines unique to


850


each seller. Thus, at the transaction level, specific buyers can be decoupled from specific sellers. C. Discovery and Transaction Applications Discovery service applications and transaction execution applications (TEAs) are necessary to complete a highly efficient EC architecture. In an ideal EC platform, discovery services would index businesses by type and product offerings. Transaction execution programs on the seller and buyer sides would allow sellers and buyers to execute transactions. 1) Discovery applications include applications that index products available in the marketplace and provide search capabilities based on these indexes. Discovery applications are required for overall market search in a ubiquitous EC network. Discovery technologies are especially important when buyers and sellers are not known, when offerings from different suppliers need to be found and evaluated, and when markets are fragmented [25], [26]. The usefulness of a discovery technology fundamentally depends on two factors: first, whether network participants use standard means to make market-related information available, and second, whether a large proportion of participants in the overall market choose to participate [19]. 2) TEAs execute transactions among organizations. It is important to integrate TEA with an organization’s internal systems. For instance, research on EDI systems suggests that a high degree of integration between EDI systems and the organization’s internal information systems significantly increases EDI performance benefits [27]–[32]. These benefits will be fully realized only by EC platforms that are robust enough to support tight integration. TEA should support connections of two types: arms-length, ad hoc connections with new trading partners, and privately negotiated agreements between established trading partners [33]. An implication of this is that sellers should be able to make different prices and terms available to different parties, which requires such information to be stored in the seller’s database. Thus, data representation and storage are required for flexible, automated TEA capability. A benefit of the existence of both foundation standards and marketplace standards is that they make it possible for discovery applications and TEAs to be implemented through a variety of means, in effect creating a market for efficient and useful implementations of these applications. Fig. 2 represents an example of an implementation of an efficient EC platform supported by the aforementioned standards and applications. In this example, the registry transacts with both the buyer and seller, each of which is supported by TEAs. The operation of the platform is now described. Numbered arrows in the diagram are marked in parentheses in the following text. (1) The seller registers products and services with the registry along with the (2) business categories for the seller’s business. The index facilitates the sales transaction by soliciting (3) up-

Fig. 3.

Efficient EC platform supported by standards. Auction example.

dated price and availability information from the seller.2 The buyer performs a lookup (4) on the desired product category and receives the (5) list of available categories. Each category has its associated set of search parameters that are specific to that category’s product and service representation. The buyer uses these parameters to (6) search for the desired products and receives (7) matching products. When the buyer decides to make a purchase, the buyer issues a (8) purchase confirmation request to the seller. The seller then (9) confirms the sale. This system is similar to an aggregator system like PriceGrabber.com or Froogle where the registry entity never owns the products being sold.3 Instead, the registry collects product information from competing vendors and helps the consumer by providing updated, searchable information through an index. The standards in Fig. 1 make this approach more efficient than do legacy EC platforms in a number of ways. Marketplace standards are defined in terms of foundation-level data type and EL standards. Each product type has an associated product or service data representation. Transaction templates are defined for all messages and method calls being passed between the entities. Thus, loose coupling is possible. Finally, the existence of business categories allows organizations to be identified by business type. For example, a buyer could identify all registered paint manufacturers. Given these standards, a variety of different discovery and TEAs can support this platform. For instance, Fig. 3 represents an auction example. This platform is similar to the platform in Fig. 2 in many respects. However, an auction engine has been substituted for the fixed-price index in Fig. 2. In Fig. 3, the seller states the (3) selling terms, including minimum acceptable prices. The buyer 2 If desired, sellers could designate which buyers have authorization to access the seller’s information and to buy seller products. Special pricing schedules could also be included for certain types of buyers. 3 Only minimal changes would be required to change this example to a marketplace, where the seller authorizes the index to consummate sales. In that case, the customer would commit to a sale through the registry. The registry would return a confirmation of the purchase to the customer.



states a (8) purchase offer that includes a maximum bid price. After the sale, a (9) purchase confirmation is provided to the buyer and a (10) sale confirmation is forwarded to the seller. The examples in Figs. 2 and 3 would work for both small and large enterprises. For simplicity, we have excluded the following from the diagrams in Figs. 2 and 3: product rating services, buyer and seller rating services, and financial transaction gateways, though these would function much like they do in existing EC platforms. IV. EVALUATION OF EXISTING PLATFORMS In this section, we use the ontology described earlier to examine and evaluate the strengths and weaknesses of current, prominent EC platforms, including EDI, e-procurement systems, B2B hubs, and company Web sites. The platforms included here are currently used by many organizations to conduct large volumes of transactions. For the interested reader, we have included a history and description of the EC platforms in the Appendix. A. Electronic Data Interchange The strength of EDI stems from its well-defined data and transaction standards. With these standards, EDI software has been able to provide transaction services so that it is possible to execute viable commercial transactions between two firms. EDI has had major industry support, and consortiums have defined data types and transaction templates for many industries. EDI has been successful with some large organizations in achieving its goals of creating electronic business documents and transfer mechanisms. However, as its name implies, it was never designed to solve the larger issues of semantic definition of terms or broad market reach. EDI does not scale easily to include new participants, nor it is well suited for operating in efficient electronic markets where buyers would like to be able to search for products, prices, and related information from all sellers in a dynamic broader market. EDI was never widely adopted in the general business space. B. E-Procurement Systems In terms of standards, e-procurement systems lack the marketwide acceptance of transaction templates that have been adopted by EDI. They also use proprietary product definitions and transaction definitions, which means that these vary across vendors. Finally, they are limited in their market reach because they are subscription-based systems. Their main benefit is to make the purchasing process more efficient between buyers and known suppliers that both use the system.

851

lack of standards. Non-standards-related problems were related to limited market reach and concerns about poor control over market information availability. First, hubs are not built on common, ubiquitous standards. Diverse data definitions and transaction definitions hamper the adoption of hubs. Moreover, hubs typically do not connect to other hubs. As reflected in Table I, data and transaction standards are specific to a hub, but are not universal across hubs. To connect to multiple hubs, companies have to incur the cost of implementing multiple translation pathways between their purchasing and sales databases and the hubs. Thus, the n-way problem still exists. It is costly to connect each business to multiple hubs. Second, because hubs are proprietary, they have limited market reach. When a company connects to the hub, it has automated access only to other companies connected to the hub. Competition among hubs for subscribers results in market fragmentation [34]. In addition, many suppliers and buyers are not convinced that hubs will reach critical mass, causing self-fulfilling expectations. Because of these limitations, the promise of broad market reach and the ability to easily compare offerings from many vendors typically failed to materialize. Third, some suppliers are reluctant to subject themselves to the price comparison that is possible in a hub [33], and others already benefit from a lack of broad market reach. Some hubs support public pricing, but do not support closed, secret price negotiations between specific buyers and sellers. This is unattractive to sellers who charge lower prices for large centralized buyers and higher prices for small decentralized buyers [33], [35]. This can be remedied by the inclusion of public and party-specific, closed pricing provisions in hubs. Some buyers like Wal-Mart have strategic sourcing and coordinated replenishment agreements with suppliers [36], [37]. These types of buyers have already invested in automated EDI links to suppliers, and therefore, are more efficient than most competitors. This benefit could be somewhat lessened by more broadly available automation. Also, Clemons et al. [38]note that while some hubs focus on liquidity, many lack channel coordination ability. That is, they lack the ability to coordinate the production schedules of suppliers with the production schedules of buyers [38]. These combined factors put pressure on the hub industry. For example, Ariba and CommerceOne, companies that were the focus of high expectations, have failed to achieve profitability and large market reach. Such firms have subsequently refocused their efforts toward creating purchasing management tools rather than trying to become hubs in their own right. D. Company Web Sites

C. B2B Hubs During the late 1990s, B2B hubs were considered by some as possible solutions to EC problems because they provided a single point for standardization on foundation technologies, marketplace standards, and applications. However, over the last few years, many hubs have failed, and those that survived have struggled to achieve critical mass. A number of factors have hampered hubs—only some of which are directly related to the

Although an increasing number of companies have invested in Web sites, their sites lack standard product and service representations. They also lack standard transaction templates. Web pages lack standards for field names and field definitions used to provide information for specific products and services. This means a computer cannot reliably search multiple vendor sites for the same or similar products, nor can searchers use predictably specified product attributes to narrow their searches. For


852


TABLE I MAPPING OF EACH TECHNOLOGY TO THE STANDARDS ONTOLOGY DESCRIBED IN THE TEXT

a system to compare information programmatically across multiple company sites, it must overcome this problem. Although improvements have been made in automation that can “scrape” Web pages for information in limited domains [39], page scraping is not practical for application to the many diverse product types on the Web [40]. Consequently, humans must still conduct inefficient and, often, ineffective searches instead of using computers that could query and compile results from all possible sellers. Search engines, such as Google and Inktomi, which provide discovery services for Web sites, are significantly limited by

the lack of commonly adopted product and service schemas. Thus, search engines use algorithms based upon co-occurrence of words to index information rather than consistently presented product attributes. Spiders, deployed by search engines, “crawl” and index diverse and incomplete HTML representations, and therefore, return incomplete and unreliable results. The lack of reach is another problem for search engines; not all potential suppliers and Web pages are indexed [41]. The inability to execute standardized transaction templates is another problem for today’s commerce Web sites. If a potential buyer finds a company’s Web site, human operators must search



the site to find the desired product. Then, they purchase products through the shopping carts at the site or call the seller to arrange terms of the sale. Standardized data and transactions, common to EDI, such as requests for bids and purchase orders, are not commonly supported by company Web sites. Table I shows that since Web sites represent data in a free-text format, they lack the needed standardization, representation, discovery, or categorization that is required for computer-tocomputer interaction in general EC applications. V. EMERGING PLATFORMS AND STANDARDS Emerging platforms, technologies, and standards are considered here because they have potential implications for future use and because they are now being discussed by various authors as potential EC solutions. This section discusses Electronic Business XML (ebXML), Web services (WS), the semantic Web (SW), and Universal Business Language (UBL). A. ebXML Of all the emerging technologies, ebXML is slated to be a full EC platform. The intent of the creators is to have ebXML eventually support large volumes of EC transactions and provide an improved version of EDI. EbXML inherits much of the standards development effort invested in EDI [42], [43]. In particular, the United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT) group has extensive history in defining and managing EDI standards for business processes. Some existing EDI infrastructure is supported within the current ebXML standard. EbXML provides significant infrastructure for most parts of the ontology presented in this paper; its only limitations are in the marketplace standard level. These weaknesses are discussed in this section. EbXML specifies a set of core components, aggregations of core components, and business processes that can be used as the building blocks of transaction documents [44]. These core components provide standardization when used, but they are optional—participants are allowed to use outside components, such as industry-specific data types and processes or backwardcompatible EDI types. This provides the potential to use general standards when appropriate, but also to provide specialization specific to industries. The primary limitation of ebXML is that it was defined as an infrastructure rather than a solution to EC. We recognize that this scope is consistent with the developer’s goals. However, it is important to note that ebXML only defines the infrastructure. The semantic details still need to be defined by partners or by industry consortiums. In short, ebXML provides the building blocks and execution technology, but it does not include many needed semantic details. This limitation can be seen in several areas of the platform. First, ebXML does not contain a “standard set of XML business documents or a standard choreography for exchanging those documents” [45]. In other words, it does not define standard business process models—these models are left to individual participants to define. Once these models are defined and agreed upon by partners, ebXML provides support through legally

853

enforceable contracts, network protocols, and execution technologies. ebXML is a partner-oriented infrastructure. Because ebXML does not define specific process models, product and service representations, and transaction templates for specific industries, business partners must couple their applications, including clients and servers, to one another. The goal of a generalized client that connects to new services at run time is not realized. Second, the specific definition of collaboration protocol profiles and agreements of those protocols must be negotiated between partners before transactions can be executed. While boilerplate documents can be retrieved from a central registry, client applications must be programmed to work with each instance rather than with a generalized set of rules and roles. Third, although the methods of searching for information in ebXML registries is standardized, the data contained in them are not. Unless industry consortiums define shared protocol documents and core component extensions, ebXML registries will have limited capabilities when searching for products and services across the broad market. Rather, participants will be limited to retrieving information about known business partners. B. Web Services WS is a set of three technologies that can be used to conduct the logical equivalent of function calls for information and transactions. WS is not a full EC platform, but rather was designed to support method calls on networked objects. We include WS in this paper because its three parts can be used to execute EC transactions. While the WS architecture represents a step forward in that it allows organizations to describe how to access their automated services, it still has significant limitations if used as an EC platform. We realize that WS is not meant to be a full EC platform, but we include it so that readers can place it within the overall ontology. Although Web Services Description Language (WSDL) provides a standard mechanism for business and product description, organizations within industries have not yet created coalitions to create common descriptions of products, automated interfaces, and transactions for similar businesses. Standards do not exist for field names, data types, and method names and definitions of automated program interfaces that partners can use to make calls to automated services. Field names to be used in these exchanges have not been standardized, such as “product code” or “product description.” Moreover, standards have not been defined in terms of which of the WSDL data types will correspond to each field. For example, one service might use a string to represent product codes while another might use an integer. Method call names, the number and types of method call parameters, and return values have not been agreed upon by industries. This lack of standardization means that buyers must explicitly couple themselves to each seller in order to conduct transactions. As a specific example, suppose Amazon and Barnes & Noble do not use the same method names, parameter types, and return values. Thus, common access methods cannot be used by client applications such as indexing applications and TEAs.


854


Because of different interfaces and methods, agents will not be able to communicate with new services without reprogramming. Amazon’s hypothetical getBookInformation(. . .) method may or may not be synonymous with Barnes & Noble’s hypothetical queryBook(. . .) method. These kinds of decisions and inferences require human knowledge and experience, resulting in the reprogramming or training of agents and client applications for each new service found. While some participants within industries may standardize their WSDL signatures or use existing WSDL from the existing “pool” of signatures, formal involvement with the Universal Description, Discovery, and Integration registry (UDDI) system does not directly encourage participants to standardize or adopt standards that are being defined by other organizations (such as RosettaNet). This lack of standardization significantly impedes the usefulness of WS [46]. The UDDI registry lacks effective standardization. Since organizations can register with a variety of categorization schemes, such as the NAICS code [20] or the Universal Standard Products and Services Classification [21] code, the UDDI registry does not support economical and reliable searching for all businesses of a given type. Searchers must query according to the multiple different possible business categorization schemes to find businesses of a specific business type. Jewell and Chappell [47] have written the following about the anticipated limited market reach of the UDDI system. It’s probably not realistic to expect software to dynamically discover and use new businesses on the fly in the near future. Realistically, human analysts need to browse a UDDI portal that allows customized searches and queries to discover the businesses they are interested in working with. It’s more likely that software will contain the logic necessary to locate and integrate with Web services for companies that have been predetermined. It’s also likely that businesses will set up private UDDI registries that they can share with their approved partners to facilitate B2B integration.

Because of the UDDI yellow pages, the UDDI system can help searchers find businesses that offer a certain class of products or services, but UDDI does not support automated searches for specific products and comparisons of products and prices across vendors. For example, with UDDI it is possible to find registered companies that manufacture TVs, but it is not possible to find all vendors who currently sell high-definition, stereo, 27-in color TVs, and obtain the price and availability of those TVs.

and namespaces to define standards for transactions, products and services, and discovery. Namespaces provide uniqueness for terms and allow shared meaning across sites. Since the SW uses common WWW components, including pages, sites, and Web servers, it uses existing communication methods. RDF and namespaces provide a rich EL that can be used to represent EC-related content [48]. However, the SW project has a scope much larger than EC or B2B. Indeed, the SW designers are trying to create a language that can describe anything and everything. The SW does not define standard data types, transaction documents, product and service representation, or business categorization standards. Related projects such as the DARPA Agent Markup Language with Ontology Inference Layer (DAML+OIL) and Web Ontology Language (OWL) provide additional terms and constructs that can be used for EC transactions, making the SW a potential standard that would be more useful in an EC implementation [49]. However, even with additional ontology languages, the SW is missing several important EC standards. First, the system does not define a standard set of terms or building blocks for commerce. For example, participants and industry consortiums will have to define Uniform Request Identifiers (URIs) for constructs they use in transactions.Additionally, the SW does not define business processes, agreement protocols, or legally binding documents to be used in EC transactions. The SW development team acknowledges this limitation, but notes that it is a natural consequence of the large scope of their initial effort. Second, the SW does not define standard mechanisms for discovery of business partners. As more pages with RDF information appear on the Web, search engines will likely index this information and allow searching based upon exact terms (URIs). Thus, the actual searching in the system will be significantly more powerful than existing systems. However, while RDF allows expressions of fact (such as “Denny’s sells pancakes”), EC clients will require more exact standards for how this information is organized on Web pages. Third, the SW does not define standards that can be used by execution technologies. Suppose a client successfully discovered a Web page selling products it was interested in. The SW architecture provides little advice on how to successfully execute a transaction with the page. As described in Section IV-D, the existing Web applications use nonstandardized CGI forms to conduct transactions. D. Universal Business Language

C. Semantic Web The SW is a framework that allows data to be used and understood by different parties. While the primary intent of the SW is not to be an EC platform, it is an approach that could be used to provide some support for the middle level of the ontology presented in this paper. The primary benefit of SW is its use of Resource Description Framework (RDF) to associate meaning to terms that computers can share and understand—an important feature for efficient automation. RDF provides a system whereby businesses can use existing terms

UBL is a library for business document representation. The goal of UBL standardization efforts is to tackle one of the most difficult problems for EC platforms: semantic meaning. As such, it focuses on only one piece of the ontology and provides no infrastructure, messaging, searching, or execution technologies. UBL’s greatest strength—if the project realizes its goals—is its potential to be used within existing architectures like ebXML. Most EC platforms sidestep the difficult issue of semantic meaning, leaving specific definition of terms and documents to participants. UBL may provide a shared meaning that allows clients



TABLE II REVIEW OF EACH PLATFORM AND TECHNOLOGY AGAINST THE ONTOLOGY DESCRIBED IN TEXT

and servers to conduct EC at a level of decoupling that has not been possible in previous platforms. UBL may provide the solution to the chaotic world of XML business document definition. However, much work is required before it covers the vast ground already defined in EDI—a good deal of translation remains to be done [50]. Most importantly, the developers of UBL have set an ambitious goal of defining universal documents. This may be unrealistic since some businesses have different specific needs. For example, while invoices have many similarities across industries (purchaser and seller information, line items, products, quantities), some specializations occur from industry to industry. An invoice for retail music sales has some different characteristics than an invoice used to sell fresh fish in bulk to supermarkets. Businesses may decide not to adopt UBL because they lose specificity in their documents. This problem can be overcome by allowing reasonable document variants appropriate for specific industries. We applaud the UBL team’s effort, but we recognize that they are working on a difficult problem. A second problem for UBL is the lack of incentives to ensure that industries adopt the generalized business semantics. Established, dominant businesses may use “standard” documents in ways that couple its suppliers and buyers to them rather than providing loose coupling that supports accessibility to players in the broader marketplace. Since larger businesses with current tightly coupled connections benefit from current connections, they are understandably wary of supporting efforts that would create a more level playing field. VI. DISCUSSION AND RECOMMENDATIONS The aforementioned evaluation provides evidence that no single EC platform fully decouples participants at all three phases

855

of the EC process. As explored in Section I, an ideal platform would enable clients to discover potential partners with detailed parameters and reliable results, negotiate technical and business protocols without reprogramming or input from human operators, and execute transactions with precision. Table II reviews each platform and technology against the ontology described in this paper. An approximate score is given to each cell and calculated across cells to summarize strengths and weaknesses of each platform or technology. We provide the score as a guideline for summary and not for direct comparability. This table gives a sense of how closely the existing technologies meet the required parts of the proposed ontology. While no individual platform provides support for every level of the ontology presented in this paper, we believe the most promising solutions involve combinations of the discussed architectures. For example, the combination of ebXML and UBL is one possible direction, providing comprehensive infrastructure as well as standard transaction documents. Another potential combination is the SW architecture (enabling powerful commercial search engines), a commerce-oriented RDF ontology shared by all participants, and the WS platform for the execution of transactions. Since OASIS is involved in both the ebXML and UBL efforts, and since the World Wide Web Consortium (W3C) is involved in the SW and WS, these groups may facilitate these combinations. The ideal platform discussed earlier in the paper is, by definition, a lofty goal. Full decoupling of services may never be fully possible. However, we believe that the trend toward a lesser but worthy goal, loosely coupled EC participants, will become increasingly supported. One limitation of the proposed ontology is that it does not discuss human issues such as the psychology of standards adoption, government regulations and laws, operational issues, and management desires. These issues are beyond the scope of this paper. Further research should examine these topics. EC standards must provide semantically meaningful sets of terms that enable loosely coupled, run-time connections among disparate clients and servers. The aforementioned evaluation provides the evidence of the need for marketplace and technology standards to enable EC to achieve its considerable potential. Evaluation using the ontology demonstrates that no single platform provides a complete solution for all components of a standardized, loosely coupled marketplace. The preceding evaluation reveals that each EC platform and technology not only have strengths, but also significant weaknesses. Based on these findings, research and development is essential in at least three fundamental areas. First, as shown in Table II, the discovery phase is not well supported by most platforms. Without discovery, the process of searching for potential EC partners is time-consuming, and will require significant human involvement. The limiting factor in discovery is the lack of standard semantic meanings for products, services, and business categorization. This is arguably the most difficult area to standardize, but research into this area is imperative if computer applications are to successfully and reliably find products and services with an EC platform. This research could include progress with the SW and advancement of the UBL effort.


856


Second, many of the platform limitations discussed in this paper occur because of the lack of incentives for participants to standardize. Different individual businesses and industries have varied incentives. Market reach is more important to some suppliers and buyers than to others. The power of buyers and sellers also varies. Researchers should investigate the conditions under which specific participants gain benefits from development and agreement upon a standard, as well as those conditions that promote incentives and disincentives. Issues such as business compatibility, competition, and specialization complicate the solution. For example, one author recently spoke with the CEO of one of the largest technology manufacturers in the world about an ideal platform. The executive was unenthusiastic about a truly efficient platform because it provided the means to partially level the playing field for both smaller and new competitors. This executive’s business has already set up efficient EDI connections with preferred buyers and sellers, justin-time agreements, and preferred pricing. Because of this, the company recognizes that its private EC network is a significant competitive advantage. Third, research should investigate efficient processes for developing standards and for combining work from different standards bodies. As observed earlier, a combination of platforms may provide solutions that better approximate ideal EC. Consideration should be given to how to best involve principal players in efficient ways. Lessons learned from research in the field of collaborative systems requirements definition [51], [52] could be fruitfully applied to the area of standards development. There exists substantial research and application opportunities concerning standards for loosely coupled EC architectures. Progress in this area has significant potential to improve the way EC is conducted in the future. VII. CONCLUSION This paper has attempted to illuminate specific standards that are important and how these standards can interact to make more efficient EC possible. Our ontology and the evaluation of current and emerging platforms and technologies included in this paper should help guide future research and development in this area. While progress has been made in standards and applications, our analysis has shown that significant progress is still required in this important area. APPENDIX HISTORY OF EC PLATFORMS The history of the development of EC standards and the standards themselves is complex, which makes it challenging to have a systematic way to evaluate EC platforms. For example, it is rare to find an individual who understands the developmental history of EDI and the details of its application and who also understands newer emerging EC enablers like the SW or ebXML. Even after studying these standards, it is still possible to lack a common framework that can be used to evaluate their strengths and weaknesses. The purpose of this Appendix is to provide an abridged history of prominent EC standards. This background

provides the foundation for the ontology and analyses in the paper. The first widespread EC platform was EDI. EDI dates back to 1960s, and it was motivated by the need for electronic data standards between trading partners. This effort was largely driven by large entities, such as General Motors, Sears, and Kodak in order to facilitate transactions with their many suppliers when buying direct materials to assemble into products. EDI standards for data interchange evolved from early proprietary agreements between pairs of trading partners, to industrywide standards, to the more comprehensive and flexible ANSI X12 standards started in 1978, which can support both intraindustry and interindustry transactions. X12 Standards were flexible enough to accommodate the specialized information requirements of automotive, petroleum, transportation, and many other industries. Templates were designed for all the major transaction documents, such as purchase orders, and remittance advices, etc. A data dictionary was created that defines the field names and data definitions comprising each transaction. Trading partnerships between two firms using EDI are well defined and generally stable. This stability means that EDI is sometimes used for automated replenishment and for the maintenance of efficient supply chains [36], [38]. Since EDI predated the Internet, transport historically occurs over value-added networks (VANs), which serve as the common communication method. VANs provide reliability, translation capability, security, and electronic mailboxes for trading partners. VANs can be very costly, however, with a fixed cost in the range of $250 000 for a mainframe installation and variable usage fees as high as $0.70 per transaction. Today, the EDI telecommunications vehicle is changing from the VAN to the Internet. Indeed, some of the larger VANs now offer Internet services as well as their traditional connectivity methods. In addition, some industry groups are adopting XML as the communication language for EDI transactions via the Internet. Actual implementations of XML are few in number today, but substantial growth is expected in the future [17]. E-procurement systems have recently been adopted by a number of organizations to purchase indirect goods not typically purchased through EDI systems. A direct good is an item that becomes part of an end product, such as a motor used to assemble a washing machine. An indirect good is an item that does not become part of the end product but rather is used in other processes, such as operations, selling, maintenance, and administration [53], [54]. Examples of indirect goods include office supplies, computer equipment, cleaning solvents, and office furniture. E-procurement systems provide online product catalogs or links to vendors’ catalogs. E-procurement systems enable organizations to distribute purchasing decisions to specific people across the organization. Moreover, automated linkages to suppliers allow buyers to reduce paperwork and overhead associated with the buying process and to shorten the time required to complete the purchasing cycle [53], [54]. E-procurement systems can result in reduced inventory and consolidated buying that may give buyers more power to negotiate lower prices [54]. Like hubs, e-procurement systems are subscription-based proprietary systems that lack a ubiquitous standard and wide market reach.



Several years ago, B2B hubs became a much-discussed alternative to EDI and e-procurement systems. Some EC analysts and developers of B2B software expected that B2B hubs would radically reduce purchasing costs and provide comparability across vendors. As shown in Fig. 2, B2B hubs bring buyers and sellers together and automate business transactions [55]. B2B hubs are electronic marketplaces that play the role of digital intermediaries [25], [56]. Ideally, B2B hubs facilitate product and information exchange and support product search, initial contact, negotiation, and settlement [25], [26]. B2B hubs were expected to dramatically change commerce because they would be good for both buyer and seller. Hubs were expected to aggregate supplier’s product offerings, and help buyers search for desired products across multiple sellers. Hubs offer their own catalogs or link to the product catalog of sellers, thereby providing indexing services [57]. The ability to easily compare offerings from many vendors was expected to put downward pressure on prices [33], [55]. Sellers could achieve greater market reach and aggregate fragmented demand, thereby allowing sellers to achieve greater sales and economies of scale. Hubs also represented the promise of reduced automation costs. Ideally, each buyer and seller would only need to incur the cost of connecting to one or a few hubs rather than sustaining the cost of developing links between individual market participants. Hubs also automated a set of EC transactions. With the introduction of the WWW in 1991, some companies began to market and sell products over their corporate Web site. HTML version 2.0 introduced the concept of forms, parameters, and Web engines in 1995. Web portals are now commonplace for sales transactions between businesses and consumers (B2C) and consumer-to-consumer (C2C) sites like eBay. They are also commonly used for transactions between business partners (B2B), with vertical and horizontal ordering and shipping being done over the Web. The appeal of the WWW for EC is its simplicity and ubiquity. This string-based HTTP protocol allows simple communications between any browser and Web server. While it lacks the standard transaction templates of EDI, it is easy to set up and implement due to the many development platforms and tools available. The Web requires little investment in hardware, and it rarely has firewall issues on either side of the connection. The addition of HTTPS encrypts existing Web transactions with robust security and little to no additional coding. The XML is a useful development that is used in the remaining technologies to be discussed in this Appendix. XML was proposed in November 1996 by the W3C. XML is a simplified version of earlier markup languages, and is specifically designed to support definition of structured data. Once a definition has been defined in an XML format, it is structured, machine readable, generally human readable, and text based. This makes XML an excellent data transfer mechanism. It is used in most recent EC developments, including those described later. It is important to note, however, that XML is only a structured language that can be used to define and organize structured data and method definitions; while XML can be used to define records and fields, someone must create the schema. Because of this, XML alone does not define data types or documents.

857

WS attempt to solve some of the problems associated with traditional eBusiness technologies. Largely developed early in this decade, it is now a sponsored project of the W3C. It is mostly a transaction execution platform with only limited search capabilities. The platform takes advantage of the ubiquity of the WWW primarily by using the HTTP protocol for transport, XML for data and service description, and UDDI for service discovery. WS use open standards and have undergone submission to the W3C [58], the primary organization that maintains WWW standards. The WS architecture is composed of three technologies: the WSDL, the Simple Object Access Protocol (SOAP), and the UDDI [59]. WSDL provides a description language that can be used to describe services available on the Internet. It is loosely analogous to an interface or header file used to describe the interface and behavior supported by a module in a computer program. Client software can query services for their WSDL definition. If the client software is prepared to make use of the methods and fields described in the WSDL, it can interact with the services accordingly through specific predefined calls to those services. In particular, WSDL’s use of tModels to represent common services may provide a method of searching for businesses that use specific tModels. With WS, the SOAP is responsible for transferring XMLencoded information from one computer to another. Because SOAP uses standard HTTP, Web servers allow it to pass through firewalls with relative ease, though companies are currently exploring ways to support SOAP, and at the same time, maintain adequate security [60]. SOAP also supports standard data types that can be used for requests made to services, and it provides for asynchronous messaging and event notification to help the host and client programs communicate efficiently. Many different programming languages offer XML support. Thus, since both WSDL and SOAP use XML for data representation, WSDL and SOAP can be supported by a variety of languages. UDDI provides a central point for registering and finding services within the WS architecture. Currently, public UDDI services run by IBM, Microsoft, SAP, and HP replicate registrations, and provide redundant lookup services for businesses using WS. Because of registration replication, participants only need register with one registry to be included in all UDDI servers. UDDI provides several methods for searching, including by business name, business categorization scheme, and limited product categories. The SW is a project by the W3C to realize some of the goals of Web creator Tim Berners-Lee. While the focus of the SW is broader than EC, it has the potential to be a useful component in future EC platforms. The foundation of the SW [49] is RDF, a language for making machine-readable statements of fact. Using RDF, a company could make statements about what it sells, and a partner could make statements about what it wants to buy (and at what price). An RDF fact includes a subject, predicate, and object, such as “Apple.com sells 4GB iPod Mini.” Several schemas and ontologies have been written for the SW. Most notable is the DAML+OIL effort. DAML+OIL provides defined terms, data types, enumerations, and other specifics that work within the SW’s RDF. With plain RDF, the term Widget


858


may have many meanings on different Web sites. DAML+OIL provides a richer language for definition of an exact term, though communities still need to agree on a common definition of such a term for it to be used consistently by automated agents, indexing services, and other software clients. RosettaNet is a set of EC standards that defines Internet-based business standards, including a common business language for transactions and open processes for EC. RosettaNet is limited to technology spaces such as the semiconductor industry, technology solutions providers, and hardware and software firms. In 1999, RosettaNet released its definitions of key processes, called Partner Interface Processes [61]. Because RosettaNet is targeted specifically at technology firms and not at general EC, a detailed analysis is not included in this paper. The ebXML effort was started in 1999 and is sponsored by UN/CEFACT and OASIS. Much like the EDI effort, ebXML provides infrastructure for the execution of EC transactions. It is a suite of specifications that includes business processes, core data components, collaboration protocol agreements, messaging, and registries and repositories. These specifications are described in the following paragraphs. The business process specification schema defines a language that businesses and industry consortiums can use to express their business processes, party roles, and sequences. The core data components specification defines a foundation set of reusable, semantic building blocks that represent general types of business data. These components are neutral to specific industries; they include concepts that exist in all business documents. Several types of core components exist, including basic components, association components, type (definitional) components, and aggregations of components. ebXML’s collaboration protocol agreements define the interactions between two parties, including the business processes to be used and the technical details such as transport, messaging, and security constraints. They are made up of two or more collaboration protocol profiles. Partners using ebXML create these documents as their agreement on how they will conduct EC with one another. The messaging module of ebXML specifies how XML messages are transferred from one location to another (such as a buyer to a seller). Recent implementations of ebXML have adopted a version of SOAP (described earlier with WS) for transport. Finally, ebXML’s repositories store information, such as collaboration protocol profiles, about participants. Registries provide search capabilities and access to these documents. Uniform Business Language was originally developed by Veo Systems in 1997 (then called Common Business Language) and is now pursued by an OASIS Technical Committee. –> Unlike Ariba’s proprietary CXML, UBL is open and interoperable with existing EDI infrastructure. UBL is an ambitious project because it proposes to develop a universal definition for documents used in EC transactions, such as orders, invoices, etc. UBL is not meant to be a full EC platform, but instead, tackles arguably the most difficult problem in EC infrastructure: semantic meaning and document representation. It steps in where ebXML leaves off. While ebXML’s core components define only general concepts that business documents can be

described in, UBL actually defines the form and structure of the documents themselves.

REFERENCES [1] T. McCall, “Worldwide business-to-business Internet commerce to reach $8.5 trillion in 2005,” Gartner Group, Stamford, CT, 2001. [2] V. Grover and J. T. C. Teng, “E-commerce and the information market,” Commun. ACM, vol. 44, pp. 79–86, 2001. [3] U.S. Census Bureau, 2005. [4] A. Pincus, “Hearing on the role of standards in the growth of global electronic commerce,” presented at the Senate Committee Commerce, Sci., Transport. Subcommittee Sci., Technol., Space, Washington, DC, 1999. [5] J. Farrell and G. Saloner, “Converters, compatibility, and the control of interfaces,” J. Ind. Econ., vol. 40, pp. 9–35, 1992. [6] M. L. Katz and C. Shapiro, “Systems competition and network effects,” J. Econ. Perspect., vol. 8, pp. 93–115, 1994. [7] A. M. Chircu, R. J. Kauffman, and D. Keskey, “Maximizing the value of Internet-based corporate travel reservation systems,” Commun. ACM, vol. 44, pp. 57–63, 2001. [8] L. Obrst, R. Wray, and H. Liu, “Ontological engineering for B2B Ecommerce,” presented at the 2nd Int. Conf. Formal Ontol. Inf. Syst., Ogunquit, ME, 2001. [9] C. Welty, “Ontology research,” AI Mag., vol. 24, pp. 11–12, 2003. [10] Y. Ding, M. Korotkiy, B. Omelayenko, V. Zykov, M. Klein, E. Schulten, and D. Fensel, “GoldenBullett in a nutshell,” presented at the 15th Int. FLAIRS Conf., Pensacola, FL, 2002. [11] T. Gruber, “A translation approach to portable ontology,” Knowl. Acquisition, vol. 5, pp. 199–220, 1993. [12] N. Guarino, “Formal ontology and information systems,” presented at the FOIS 1998, Trento, Italy. [13] B. Omelayenko, “Preliminary ontology modeling for B2B content integration,” presented at the 1st Int. Workshop Electron. Business Hubs 12th Int. Conf. Database Expert Syst. Appl. (DEXA 2001), Munich, Germany. [14] C. C. Albrecht, D. L. Dean, and J. V. Hansen, “Marketplace and technology standards for B2B e-commerce: Progress, challenges, and the state of the art,” Inf. Manage., vol. 42, pp. 865–875, 2005. [15] P. Walmsley, Definitive XML Schema. Englewoods Cliffs, NJ: PrenticeHall, 2001. [16] J. Repici, “Understanding the CSV file format,” Creativyst Docs, Riverside, NJ, 2002. [17] F. Coyle, XML, Web Services, and the Data Revolution. Boston, MA: Addison-Wesley, 2002. [18] C. Shapiro and H. Varian, “The art of standard wars,” Calif. Manage. Rev., vol. 41, pp. 8–32, 1999. [19] C. Shapiro and H. R. Varian, Information Rules. Boston, MA: Harvard Business School Press, 1999. [20] NAICS, “Complete source of NAICS and SIC information and products,” NAICS Assoc., Rockaway, NJ, 2002. [21] United Nations Standard Products and Services Code (UNSPSC), 2002. [22] A. McAfee, “The Napsterization of B2B,” Harvard Bus. Rev., vol. 78, pp. 2–3, 2000. [23] Q. Dai and R. Kauffman, “B2B E-commerce revisited: Leading perspectives on the key issues and research directions,” Electron. Markets, vol. 12, pp. 67–83, 2002. [24] J. M. de Figueiredo, “Finding sustainable profitability in electronic commerce,” Sloan Manage. Rev., vol. 41, pp. 41–52, 2000. [25] J. Y. Bakos, “Reducing buyer search costs: Implications for electronic marketplaces,” Manage. Sci., vol. 43, pp. 1676–1692, 1997. [26] J. Y. Bakos, “The emerging role of electronic marketplaces on the Internet,” Commun. ACM, vol. 41, pp. 35–42, 1998. [27] V. Choudhury, “Strategic choices in the development of interorganizational information systems,” Inf. Syst. Res., vol. 8, pp. 1–24, 1997. [28] D. L. Iacovou, I. Benbasat, and A. S. Dexter, “Electronic data interchange and small organizations: Adoption and impact of technology,” Manage. Inf. Syst. Q., vol. 19, pp. 465–485, 1995. [29] T. Mukhopadhyay and S. Kekre, “Strategic and operational benefits of electronic integration in B2B procurement processes,” Manage. Sci., vol. 48, pp. 1301–1313, 2002. [30] F. J. Riggins and T. Mukhopadhyay, “Interdependent benefits from interorganizational systems,” J. Manage. Inf. Syst., vol. 11, pp. 37–57, 1994.



[31] K. Srinivasan, S. Kekre, and T. Mukhopadhyay, “Impact of electronic data interchange technology on JIT shipments,” Manage. Sci., vol. 40, pp. 1291–1304, 1994. [32] G. E. Truman, “Integration in electronic exchange environments,” J. Manage. Inf. Syst., vol. 17, pp. 209–244, 2000. [33] S. D. Jap and J. J. Mohr, “Leveraging Internet technologies in B2B relationships,” Calif. Manage. Rev., vol. 44, pp. 24–38, 2002. [34] R. Wise and D. Morrison, “Beyond the exchange: The future of B2B,” Harvard Bus. Rev., vol. 78, pp. 86–96, 2000. [35] K. Zhu, “Information transparency in electronic marketplaces: Why data transparency may hinder the adoption of B2B exchanges,” Electron. Markets, vol. 12, pp. 92–99, 2002. [36] T. H. K. Clark and D. B. Stoddard, “Interorganizational business process redesign: Merging technological and process innovation,” J. Manage. Inf. Syst., vol. 13, pp. 9–28, 1996. [37] Kurt Salmon Associates, Efficient Consumer Response: Enhancing Consumer Value in the Grocery Industry. Washington, DC. [38] E. Clemons, S. Reddi, and M. Row, “The impact of ‘information technology’ on the organization of economic activity: The ‘move to the middle’ hypothesis,” J. Manage. Inf. Syst., vol. 10, pp. 9–35, 1993. [39] D. W. Embley, D. M. Campbell, Y. S. Jiang, S. W. Liddle, Y. Ng, D. Quass, and R. D. Smith, “Conceptual-model-based data extraction from multiple-record web pages,” Data Knowl. Eng., vol. 31, pp. 227– 251, 1999. [40] D. Bergmark, P. Phempoonpanich, and S. Zhao, “Scraping the ACM digital library,” Forum, vol. 35, p. 7, 2001. [41] E. Glossbrenner and A. Glossbrenner, Search Engines for the World Wide Web: Visual QuickStart Guide, 3rd ed. Berkeley, CA: Peachpit, 2001. [42] UNECE, “EbXML Technical Architecture Specification v1.0.4,” UNECE, Geneva, Switzerland, 2001. [43] UNECE, “Electronic Business eXtensible Mark-up Language, “UNECE, Geneva, Switzerland,” 2004. [44] S. Schlegel, “EbXML: Postgraduate report,” Revision 1.4 ed., Curtin Univ., Technol., Bentley, Australia, 2004. [45] E. Dumbill, “High hopes for the Universal Business Language,” O’Reilly XML.com, Cambridge, MA, 2001. [46] O’Reilly, Web Services Center. Cambridge, MA: O’Reilly, 2002. [47] T. Jewell and D. Chappell, Java Web Services. Cambridge, MA: O’Reilly Press, 2002. [48] J. V. Hansen, J. B. McDonald, C. C. Albrecht, D. L. Dean, and B. B. Anderson, “A semantic Web data retrieval implementation with an adaptive model for supporting agent decision structures,” Electron. Commerce Res., to be published. [49] A. Swartz, “The semantic Web in breadth,” May 2002. [50] U. Ogbuji, “Examining one of the foremost XML business formats,” 2003. [51] D. L. Dean, J. D. Lee, M. O. Pendergast, A. M. Hickey, and J. F. Nunamaker, Jr., “Enabling the effective involvement of multiple users: Methods and tools for collaborative software engineering,” J. Manage. Inf. Syst., vol. 14, pp. 179–222, 1998. [52] A. M. Hickey, D. L. Dean, and J. F. Nunamaker, Jr., “Establishing a foundation for collaborative scenario elicitation,” DATA BASE Adv. Inf. Syst., vol. 30, pp. 92–110, 1999. [53] B. Eichler, K. Evans, N. Parks, S. Alaniz, R. Roberts, and B. McCarver, “E-procurement: A guide to buy-side applications,” in Stephens Inc. Internet Research Industry Report. Little Rock, AR: Stephens, Inc., 1999. [54] C. Subramaniam and M. J. Shaw, “A study of the value and impact of B2B E-commerce: The case of web-based procurement,” Int. J. Electron. Commerce, vol. 6, pp. 19–40, 2002. [55] S. Kaplan and M. Sawhney, “E-hubs: The new B2B marketplaces,” Harvard Bus. Rev., vol. 78, pp. 97–103, 2000. [56] J. P. Bailey and J. Y. Bakos, “An exploratory study of the emerging role of electronic intermediaries,” Int. J. Electron. Commerce, vol. 1, pp. 7–20, 1997. [57] J. P. Baron, M. J. Shaw, and A. D. Bailey, Jr., “Web-based E-catalog systems in B2B procurement,” Commun. ACM, vol. 43, pp. 93–100, 2000. [58] W3C, Web Services Architecture Working Group, 2002. [59] T. Bellwood, L. Cl´ement, D. Ehnebuske, A. Hately, M. Hondo, Y. L. Husband, K. Januszewski, S. Lee, B. McKee, J. Munter, and C. V. Riegen, UDDI Version 3 Specifications Document. Billerica, MA: UDDI Working Group, 2002. [60] C. C. Albrecht, “How clean is the future of SOAP?,” Commun. ACM, vol. 47, pp. 66–68, 2004.

859

[61] I. Graham, N. Pollock, A. Smart, and R. Williams, “Institutionalisation of E-business standards,” presented at the Standard Making: Crit. Res. Frontier Inf. Syst., MISQ Special Issue Workshop ICIS, Seattle, WA, 2003.

Conan C. Albrecht is currently an Associate Professor and a Rollins Fellow at the Marriott School of Management, Brigham Young University, Provo, UT . His current research interests include computerrelated fraud detection, collaborative computing, peer-to-peer architectures, and network programming. He has developed three groupware systems to research group dynamics, and is currently creating an open-source software to make fraud detection within corporate systems more available to auditors and fraud detectives. His work has been published in Decision Support Systems, the Journal of Forensic Accounting, the Communications of the ACM, and Expert Systems with Applications.

Douglas L. Dean received the Ph.D. degree in management information systems from the University of Arizona, Tucson, in 1995. He is currently an Associate Professor and a David and Knight Fellow at the Marriott School of Management, Brigham Young University, Provo, UT, where he is also the Research Coordinator at the Rollins eBusiness Center. His current research interests include electronic commerce technology and strategy, software project management, requirements analysis, and collaborative tools and methods. His work has been published in Management Science, the Journal of Management Information Systems, the journals Data Base and Group Decision and Negotiation, and Expert Systems with Applications. Dr. Dean has also published in the IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICS.

James V. Hansen received the Ph.D. degree from the University of Washington, Seattle. He is currently a Glen Ardis Professor in the Information Systems Group, Marriott School of Management, Brigham Young University, Provo, UT. He is on the Editorial Boards of Information Systems Frontiers and Intelligent Systems in Accounting, Finance and Management. He is listed in Who’s Who in Science and Engineering. His current research interests include machine learning and agent-based systems, with recent publications appearing in the Computers and Operations Research, the journal Genetic Programming and Evolvable Machines, and the Journal of Experimental and Theoretical Artificial Intelligence. Dr. Hansen is a member of the editorial board of the IEEE INTELLIGENT SYSTEMS and has published in the IEEE TRANSACTIONS ON NEURAL NETWORKS.
