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 ontol-ogy 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-to-business hubs, company Web sites, Electronic Business eXtensible Markup Language, Web Services, the semantic Web, and Univer-sal Business Language. We conclude that no individual platform or technology provides complete support for every level of the on-tology, 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, par-ticipant 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
F
OR MORE than three decades, businesses have been us-ing 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 technolo-gies 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 transac-tions worth $19.798 trillion. The Census Bureau does not break
Manuscript received March 14, 2005; revised September 22, 2005. This work was supported in part by the Rollins eBusiness Center at Brigham Young Uni-versity. This paper was recommended by Associate Editor B. Chaib-draa.
The authors are with Marriott School of Management and Rollins eBusi-ness 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 re-liably and rapidly across networks. Standards are the key to interoperability between EC systems [4]. When this occurs, hu-man operators can focus their efforts where they provide real value: specifying search parameters, evaluating options, using judgment to make decisions, and approving transactions. Use-ful 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]. Standardiza-tion may be achieved through independent acStandardiza-tions of market participants, through formal coordination of participants in vol-untary 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 con-version have different costs. Standardization requires time and coordination expense during the creation and refinement of stan-dards. 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 con-verters 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 con-version 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 con-verters. 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 exis-tence of standards dramatically reduces the costs of developing and buying converters. In contrast, only one two-way conver-sion is necessary for each system when all systems translate to a shared standard.
Well-defined standards also allow for economy of tool de-velopment. For example, because of the existence of electronic data interchange (EDI) standards, software firms had an incen-tive to develop converter software that complied with standards. Organizations wishing to adopt EDI benefited from competition among the developers of EDI converters whose products com-pete 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 program-ming interfaces (APIs). Standards allow client and server sys-tems to be loosely coupled. Loose coupling means that an im-plementation 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 dis-tributed client–server applications called for a disdis-tributed 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 ser-vice to the serser-vice itself. That is, clients called implementation-specific APIs to access the server’s capabilities. This tight cou-pling 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, as-sume that a software company produces a software development environment that an EC participant used to develop a server ap-plication. 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 previ-ously 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 in-terface. 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 sys-tems work across the heterogeneous infrastructures on the Inter-net 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 prod-uct 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. IMPROVEDEC PLATFORM
In this paper, we recommend an improved approach to EC where any platform consisting of a client, server, registry, and
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 plat-form. 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, ne-gotiation, and execution.
First, the retail store must discover potential sellers. To ac-complish 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 manu-facturers of TVs from manumanu-facturers 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 reg-istry 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 repre-sent 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
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 negoti-ate 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, pur-chase orders, etc. The negotiation stage requires the fol-lowing 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 choreogra-phy 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 transac-tions 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 real-ized 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 transac-tion 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 devel-opment 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 pro-gram 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. In-deed, 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 ontol-ogy supported by standards be developed as a benchmark that can be used as a guide when evaluating current and future EC platforms.
1While the example describes the scenario of a retailer buying from
whole-salers and manufacturers, other types of commerce such as B2C also require the standards for efficient search and application support.
Fig. 1. Standards ontology for generalized EC.
III. ONTOLOGY FOREC STANDARDSEVALUATION
Obrst et al. [8] present a compelling case that the use of on-tologies 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 ontol-ogy has been adopted by the information systems and business communities, where it has been defined as the formal specifi-cation 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 imple-mentation. 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
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 represen-tation. For example, in the eXtensible Markup Language (XML), data are delimited within hierarchical relation-ships [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 communi-cate 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 Pro-tocol. Communication standards should include methods of encryption and authentication for secure transfer of in-formation. Most communication methods have a secure version of the standard method, e.g., HTTP and HTTPS. Because systems like paired-key encryption and authenti-cation are in wide use today, we include security in com-munication methods rather than make security a standard of its own.
B. Marketplace Standards
Marketplace standards include product and service represen-tation 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-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 complex-ities, definition of the following three standards would signifi-cantly benefit EC systems.
1) Business categorization schemes allow discovery tech-nologies to index participants by type and name. Example business categorizations include the North American In-dustry 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, discov-ery 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 busi-nesses 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. Inconsisten-cies in representation make it very difficult for computer applications to find and evaluate sellers of specific prod-ucts 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 exam-ple, 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 transac-tion templates are important. First, method calls and mes-sage formats initiate conversations between systems and acknowledge that messages have been received. Second, informational transactions help buyers and sellers evalu-ate organizations and products. These include transactions that access product features, cost, and availability. Infor-mation transactions improve overall market efficiency by providing useful market information. Third, consumma-tion transacconsumma-tions relate to the actual consummaconsumma-tion of purchase. These include transactions that buy, coordinate delivery, and remit payments. As discussed in Section I, the existence of standard transaction templates enables de-velopers of heterogeneous systems to create software to translate data to and from each standard transaction for-mat. 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
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 ap-plications (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. Trans-action 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 applica-tions are required for overall market search in a ubiqui-tous 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 partici-pants use standard means to make market-related infor-mation 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 im-portant 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 sig-nificantly 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 pri-vately negotiated agreements between established trad-ing partners [33]. An implication of this is that sellers should be able to make different prices and terms avail-able to different parties, which requires such information to be stored in the seller’s database. Thus, data representa-tion 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 ef-ficient 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 ar-rows 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 Price-Grabber.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
2If 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.
3Only minimal changes would be required to change this example to a
mar-ketplace, 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 dia-grams 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 OFEXISTINGPLATFORMS
In this section, we use the ontology described earlier to exam-ine and evaluate the strengths and weaknesses of current, promi-nent 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 mar-ketwide 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.
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
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 mar-ket reach. When a company connects to the hub, it has automated access only to other companies connected to the hub. Compe-tition among hubs for subscribers results in market fragmenta-tion [34]. In addifragmenta-tion, many suppliers and buyers are not con-vinced 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 oth-ers 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 cen-tralized buyers and higher prices for small decencen-tralized buy-ers [33], [35]. This can be remedied by the inclusion of pub-lic 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 sup-pliers, and therefore, are more efficient than most competitors. This benefit could be somewhat lessened by more broadly avail-able 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 sched-ules of suppliers with the production schedsched-ules 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 profitabil-ity and large market reach. Such firms have subsequently re-focused their efforts toward creating purchasing management tools rather than trying to become hubs in their own right.
D. Company Web Sites
Although an increasing number of companies have invested in Web sites, their sites lack standard product and service rep-resentations. 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 pre-dictably specified product attributes to narrow their searches. For
TABLE I
MAPPING OFEACHTECHNOLOGY TO THESTANDARDSONTOLOGYDESCRIBED IN THETEXT
a system to compare information programmatically across mul-tiple 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 scrap-ing 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 com-puters 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-to-computer interaction in general EC applications.
V. EMERGINGPLATFORMS ANDSTANDARDS
Emerging platforms, technologies, and standards are consid-ered 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 Busi-ness 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 pro-vide 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 limi-tations 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 backward-compatible 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
enforceable contracts, network protocols, and execution tech-nologies. 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, in-cluding clients and servers, to one another. The goal of a gen-eralized client that connects to new services at run time is not realized.
Second, the specific definition of collaboration protocol pro-files and agreements of those protocols must be negotiated be-tween partners before transactions can be executed. While boil-erplate 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 docu-ments and core component extensions, ebXML registries will have limited capabilities when searching for products and ser-vices across the broad market. Rather, participants will be lim-ited 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 trans-actions. 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 auto-mated 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 Lan-guage (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 part-ners 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 explic-itly couple themselves to each seller in order to conduct trans-actions. 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.
Because of different interfaces and methods, agents will not be able to communicate with new services without reprogram-ming. Amazon’s hypothetical getBookInformation(. . .) method may or may not be synonymous with Barnes & Noble’s hypo-thetical queryBook(. . .) method. These kinds of decisions and inferences require human knowledge and experience, resulting in the reprogramming or training of agents and client applica-tions 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 Stan-dard 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 por-tal 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 lo-cate 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 prod-ucts 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 possi-ble to find all vendors who currently sell high-definition, stereo, 27-in color TVs, and obtain the price and availability of those TVs.
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
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, transac-tion documents, product and service representatransac-tion, or busi-ness categorization standards. Related projects such as the DARPA Agent Markup Language with Ontology Inference Layer (DAML+OIL) and Web Ontology Language (OWL) pro-vide 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 con-structs they use in transactions.Additionally, the SW does not define business processes, agreement protocols, or legally bind-ing documents to be used in EC transactions. The SW devel-opment 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 in-formation 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 signif-icantly more powerful than existing systems. However, while RDF allows expressions of fact (such as “Denny’s sells pan-cakes”), 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 discov-ered a Web page selling products it was interested in. The SW architecture provides little advice on how to successfully exe-cute 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
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 mean-ing, leaving specific definition of terms and documents to partic-ipants. UBL may provide a shared meaning that allows clients
TABLE II
REVIEW OFEACHPLATFORM ANDTECHNOLOGYAGAINST THEONTOLOGYDESCRIBED INTEXT
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 ambi-tious goal of defining universal documents. This may be unre-alistic since some businesses have different specific needs. For example, while invoices have many similarities across industries (purchaser and seller information, line items, products, quanti-ties), 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 supermar-kets. Businesses may decide not to adopt UBL because they lose specificity in their documents. This problem can be over-come 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. Estab-lished, 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 ANDRECOMMENDATIONS
The aforementioned evaluation provides evidence that no sin-gle EC platform fully decouples participants at all three phases
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 opera-tors, 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 cal-culated 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 ar-chitectures. For example, the combination of ebXML and UBL is one possible direction, providing comprehensive infrastruc-ture as well as standard transaction documents. Another po-tential combination is the SW architecture (enabling powerful commercial search engines), a commerce-oriented RDF ontol-ogy 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 Con-sortium (W3C) is involved in the SW and WS, these groups may facilitate these combinations.
The ideal platform discussed earlier in the paper is, by defini-tion, 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 adop-tion, 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 tech-nology standards to enable EC to achieve its considerable potential. Evaluation using the ontology demonstrates that no single platform provides a complete solution for all compo-nents of a standardized, loosely coupled marketplace. The preceding evaluation reveals that each EC platform and tech-nology not only have strengths, but also significant weaknesses. Based on these findings, research and development is es-sential in at least three fundamental areas. First, as shown in Table II, the discovery phase is not well supported by most plat-forms. Without discovery, the process of searching for potential EC partners is time-consuming, and will require significant hu-man involvement. The limiting factor in discovery is the lack of standard semantic meanings for products, services, and busi-ness categorization. This is arguably the most difficult area to standardize, but research into this area is imperative if com-puter 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.
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 develop-ment and agreedevelop-ment upon a standard, as well as those condi-tions that promote incentives and disincentives. Issues such as business compatibility, competition, and specialization compli-cate 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 unenthusi-astic 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, just-in-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 de-veloping standards and for combining work from different stan-dards bodies. As observed earlier, a combination of platforms may provide solutions that better approximate ideal EC. Consid-eration 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 opportuni-ties 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 OFEC PLATFORMS
The history of the development of EC standards and the stan-dards 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 un-derstands 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 stan-dards 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 propri-etary agreements between pairs of trading partners, to industry-wide standards, to the more comprehensive and flexible ANSI X12 standards started in 1978, which can support both intrain-dustry and interinintrain-dustry transactions. X12 Standards were flexi-ble enough to accommodate the specialized information require-ments 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 main-tenance of efficient supply chains [36], [38]. Since EDI predated the Internet, transport historically occurs over value-added net-works (VANs), which serve as the common communication method. VANs provide reliability, translation capability, secu-rity, 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 num-ber 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 assem-ble 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 admin-istration [53], [54]. Examples of indirect goods include office supplies, computer equipment, cleaning solvents, and office fur-niture. E-procurement systems provide online product catalogs or links to vendors’ catalogs. E-procurement systems enable or-ganizations to distribute purchasing decisions to specific people across the organization. Moreover, automated linkages to sup-pliers allow buyers to reduce paperwork and overhead associated with the buying process and to shorten the time required to com-plete 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 al-ternative 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, parame-ters, and Web engines in 1995. Web portals are now common-place 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 part-ners (B2B), with vertical and horizontal ordering and shipping being done over the Web.
The appeal of the WWW for EC is its simplicity and ubiq-uity. This string-based HTTP protocol allows simple commu-nications 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 remain-ing 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 read-able, generally human readread-able, 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 lan-guage 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.
WS attempt to solve some of the problems associated with tra-ditional 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 ca-pabilities. 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 dis-covery. 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 rep-resent common services may provide a method of searching for businesses that use specific tModels.
With WS, the SOAP is responsible for transferring XML-encoded 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 ex-ploring 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 regis-trations, 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, includ-ing by business name, business categorization scheme, and lim-ited 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
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, tech-nology 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, mes-saging, 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, includ-ing 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. Part-ners 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 mes-sages 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 interop-erable 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 infrastruc-ture: 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 E-commerce,” 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.
Acqui-sition, 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 inte-gration,” 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: Prentice-Hall, 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 perspec-tives 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 com-merce,” 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 Inter-net,” Commun. ACM, vol. 41, pp. 35–42, 1998.
[27] V. Choudhury, “Strategic choices in the development of interorganiza-tional 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 in-terorganizational systems,” J. Manage. Inf. Syst., vol. 11, pp. 37–57, 1994.
