SCALABLE DOCUMENT INTEGRATION FOR B2B
ELECTRONIC COMMERCE
Borys Omelayenko* and Dieter Fensel
Division of Mathematics and Computer Science, Vrije Universiteit, De Boelelaan 1081a, 1081 HV,
Amsterdam, The Netherlands
Email: borys@cs.vu.nl, dieter@cs.vu.nl
URL: www.cs.vu.nl/~borys, www.cs.vu.nl/~dieter
Electronic marketplaces for B2B electronic commerce serve a great mission of bringing together lots of suppliers and buyers including small and medium enterprises into a world-wide global trade. These companies use different document formats and document sequences in their procurement chain and the marketplaces need to be able to easily plug these schemes in and to translate business information between them. Existing document transformation technologies require creation and maintenance of numerous complicated document transformation rules, which grow exponentially in number related to the number of marketplace customers. Rule complexity and their number hampers further development of the B2B mediation area. We seek the solution of the complexity problem in multi-layered information modelling, where the documents are translated between original XML serialization, RDF data model, and ontology instance. Complex transformations are reached thought concatenation of a number of simple transformation rules, which reduces required rule development and maintenance effort. We provide the solution of the scalability problem with an ontology-mediated document integration approach. Individual terminologies are aligned to the terminology from the correspondent document ontology maintained by the marketplace, and the transformation between document standards require linear number of links, instead of exponential in the non-mediated scenario. We validate the approach with practical experiences taken from integrating two leading document formats for B2B mediation area: cXML and xCBL. We consider the document integration task as a motivating application for Semantic Web technologies, focusing on further re-use of the proposed techniques.
Keywords: Document transformation, B2B mediation, RDF transformation, Semantic Web
1. INTRODUCTION..............................................................................................................................................2 2. MAPPING PROBLEMS OF A B2B ELECTRONIC MARKETPLACE.......................................................................4 3. LAYERED DOCUMENT INTEGRATION.............................................................................................................9 4. INFORMATION TRANSFORMATION................................................................................................................14 5. IMPLEMENTATION AND PRACTICAL EXPERIENCE.........................................................................................19 6. RELATED WORK..........................................................................................................................................23 7. CONCLUSIONS AND FUTURE WORK..............................................................................................................27 ACKNOWLEDGEMENT..........................................................................................................................................29 REFERENCES........................................................................................................................................................29
*
Correspondence author
9/13/2001 4:07 PM 2
1. INTRODUCTION
Nowadays e-business includes thousands of companies, which provide a tremendous number of products for electronic markets. Forecasts for the dollar value of Business-to-Business (B2B) e-commerce in US range between $634 billion and $3.9 trillion. Already approximately 3 in 5 companies are using e-commerce to some extent and a further 20 percent say they intend to do so in the future. By 2003 some 80 percent of all business-to-business transactions could occur online [US Department of Commerce, 2001]. Unlike traditional markets, the electronic markets allow the participants to easily compare the offers and perform business negotiations faster due to electronic information interchange provided to market participants by B2B marketplaces. B2B marketplaces bring together thousands online suppliers and buyers each, and mediate their negotiation and purchase transactions. Different studies estimate up to 10,000 B2B marketplaces to appear in the very near future.
These marketplaces provide Web interfaces to offer a tremendous amount of products to potential customers. However, the view on their role as simple Web-enabled catalog storage leaded to recent frequent bankrupts, and general disappointment in the B2B mediation itself. This creates the new challenge for the marketplaces: to bring small and medium enterprises (SME’s) from diverse areas into global world-wide trade, and provide much more sophisticated services to attract them.
SME’s normally use their own and very often ad-hoc document systems with quite specific document formats, semantics of document elements and document sequence. Due to small size and limited resources they are not able to invest into redesign of the document support system but need to easily plug it in into a marketplace to send and receive the documents in their usual formats, different from company to company. In turn, the marketplaces need to transform business information between those systems.
The second key of success for B2B mediation is in diversification of the marketplaces and covering many areas. Different document sequences and standards are used in different areas, and the marketplace needs to perform document transformation between different used in different areas. The number of schemes is mostly the same as the number of big players for each market sector, and it will become quite significant for a diversified marketplace. Again, a plug-in technology for document systems is required.
The third new functionality required from the marketplaces is automated support in product cataloguing and classification [Fensel et al, 2001] to enable content-based product search and retrieval, which lays beyond the focus of the present paper.
9/13/2001 4:07 PM 3
A number of B2B interaction frameworks have been proposed and standardized in recent years. These frameworks provide industry-specific architectures for business information interchange with communication protocols, messaging and document formats, semantics, and protocols, common dictionaries, catalog support, and other issues (see [Shim et al, 2000] for an overview).
Many integration aspects go together in the frameworks, which creates a certain mixture in terminology. Throughout the paper we will use the following terms:
Document standard is the set of document formats with the explanation of the documents, their elements, and data encoding conventions, which is approved by a large group of market players. Most of them are represented with a set of document DTD’s and corresponding documentation.
Document sequence is the sequence which specifies which document and at which moments and conditions might appear. It may have a formal definition or be presented with free text and diagrams.
Introducing a framework into a company requires significant investment and reengineering, which is not always affordable for SME’s. Larger companies may use any of the frameworks, however, different industries or competing companies may use different frameworks and a marketplace need to be able to perform document transformation between the frameworks (which becomes a simplified tasks versus SME’s case because the frameworks posed as standards are normally well-defined and documented, which is not always the case with ad-hoc solutions used by SME’s).
Most of the B2B participants encode their documents in XML, which provides a unified way to serialize document structures and becomes a standard information exchange language for the Web. However, a large number of XML serializations for conceptually equivalent documents have been developed until now, which differ in the document structures and information decomposition, complexity, and usage scenarios (see [Li, 2000] for a comparison).1
Traditional and ad-hoc transformation technologies are not sufficient to perform necessary transformations in an efficient and scalable way (cf. [Fensel et al, 2001], [Omelayenko & Fensel, 2001b] and [Omelayenko & Fensel, 2001a] for discussion). The solution can be sought in the emerging ontology technology, one of the most promising technologies for electronic commerce [Fensel, 2001]. Ontology- 1
Non-XML standards, such as EDIFACT or ISO STEP [ISO Standard, 2000], are still in use. However, the corresponding XML encoding for them has been already developed and is now in the process of standardization. Hence, non-XML integration is unlikely to draw major interest in the future.
9/13/2001 4:07 PM 4
mediated information integration provides an elegant framework for document integration, bringing conceptual structure of the documents, and allowing further integration with knowledge-based document search and retrieval.
This makes the B2B area a prominent and motivating application of the Semantic Web technologies. The vision of the next generation of the Web, called the Semantic Web [Berners-Lee & Fischetti, 1999] envisages the Web full of data enriched with machine-processable semantic annotations and reasoning services processing this information. This requires resolving several crucial tasks:
• Building semantic annotations for documents on the Web and an appropriate annotation technology. • Performing ontology-based transformation of annotated documents.
• Inference over the ontologies and documents to make conclusions and resolve inconsistencies. • Aligning large-scale ontologies, which are updated in real time.
These tasks are quite similar to the subtasks of the document integration framework discussed in the present paper.
We sketch a simplistic marketplace using direct document integration in Section 2, and come up to a more realistic scheme able to resolve the problems arising in the simplistic case. The realistic scheme assumes a multi-layered document integration approach as presented in Section 3, which includes creation of a document data model and aligning it to the document ontology maintained by a marketplace (which is essentially the task of document annotation required by the Semantic Web). The information transformation steps required by this scheme are discussed in Section 4. Implementation problems and practical experience are discussed in Section 5 considering integration of two product catalogs and two purchase orders, followed by the overview of related work in Section 6. We end up with conclusions and related work in Section 7.
2. MAPPING PROBLEMS OF A B2B ELECTRONIC MARKETPLACE
In this section we discuss a running example of the address transformation problem, and analyze the drawbacks of applying existing technology for the document transformation task.
9/13/2001 4:07 PM 5
2.1 Document Standards: the Running Example
There exist many document encoding standards (see [Li, 2000] for an overview), however, we will focus only at two leading document standards for the B2B area. The first standard analyzed in the paper is xCBL2 3.0 developed by Commerce One, Inc. It provides a comprehensive set of standardized XML document formats, allowing buyers, suppliers, and service providers to integrate their existing systems into electronic marketplaces [Commerce One Inc., 2000]. The second standard is cXML3 1.0 developed by a large consortium of companies including Ariba and Microsoft. cXML has been proposed for a similar purpose as xCBL, and it also targets document integration for the B2B mediation task. It specifies a protocol for B2B transactions, providing a set of documents to be exchanged between the enterprises, namely cataloguing, shipping processes, status updates, acknowledgements and payment procedures.
Let us consider this scenario in details to figure out possible problems. For the discussion we take the problem of address integration as a running example. An address is a simple business concept, however, it occurs in every purchase order generated by a marketplace and in many delivery documents. Hence, a marketplace must be able to handle address descriptions.4 The Document Type Definition (DTDs) for the address representation according to xCBL and cXML are presented in Figure 1 (a)-(b) correspondingly.
(HouseNumber)?, (StreetSupplement1)?, (StreetSupplement2)?, (PostalCode)?, (City), (Country), (Region)?, (District)?, (County)?, (TradingPartnerTimezone)?)>
(a) xCBL
(b) cXML
Figure 1. The DTDs for an address
www.xcbl.org www.cxml.org 4
Unlike most of the documents, the structure of an address and the meaning of its components are understandable to everybody, which makes the explanation clear. At the same time, the alignment of various representations of an address provides all major types of problems, which can appear in the document integration task.
32
9/13/2001 4:07 PM 6
(a) xCBL (b) cXML
Figure 2. Two fragments of purchase orders in xCBL and cXML
Two fragments of XML encoding of the same address, presented according to these DTDs are shown in Figure 2. It is evident from the figure that the representations of the same address differ in each standard. The descriptions contain some elements with not evident semantics (e.g., AddressID in xCBL and PostalAddress Name in cXML). The granularity level of the descriptions differs even in this simple case: xCBL provides additional StreetSupplements for the address, while cXML provides a slot to encode the name of an addressee, absent in the other standard. In addition, address information is splitted between XML elements in different ways in both standards: xCBL allocates two tags to encode a street name and a house number separately, while cXML allocates only one tag for both. Finally, the semantics of an address is not clear from the tag names, e.g. whether we are talking about a postal address, courier delivery address, or billing address?
2.2 Single-Layered Integration
Currently dominating simplistic view on a marketplace sees it as product catalog storage. The two basic functions were: uploading product catalogs in several different catalog formats and performing keyword-based product search among the catalogs. Hence, a marketplace needs to perform transformation between several document formats as depicted in Figure 3, which does not require any special document representations or sophisticated technology. XSL-T seems to be an evident and sufficient technology to perform these transformations. The XML transformation language XSL-T [Clark, 1999], together with the correspondent expression language XPath [Clark & DeRose, 1999], provide low-level means to translate various XML documents. XSL-T specifies how a source XML document tree must be translated into the target XML document tree. XPath is a language to
9/13/2001 4:07 PM 7
encode XML element transformations, included into XSL-T stylesheets. Both languages implement a procedural waterfall approach: they provide no way to represent the source and the target document structures. The programmer needs to keep them in mind and specify the transformations needed. In consequence, the low level of XSL-T hampers it direct application for B2B document integration due to high complexity of the stylesheets needed to be developed. Existent attempts to improve XSL-T help in resolving this problem. For example [Eder & Strametz, 2001] provides an improvement to XSL-T with stronger modular system, than originally proposed XSL-T templates. Those modules might be developed independently and easily reused.
Microsoft BizTalk™5 is leading tool targeted at resolving the document integration task. BizTalk provides an elaborated toolkit facilitating document management for B2B marketplaces. The document mapping tool included in the toolkit helps in direct integration of XML documents.
transform Source XML document, e.g. product catalog Target XML document, e.g. product catalog Figure 3. Ordinary marketplace performing direct document transformation
It focuses on the current document integration bottleneck: transformation of different EDI documents, and provides two tools for that: BizTalk Editor and BizTalk Mapper. BizTalk Editor helps the user to create a parser and a serializer to make a two-way translation between a certain EDI document and its XML representation. XML tag names, extracted at this stage are considered as self-explanatory, and ready for further document transformation. For this BizTalk Mapper helps the user in defining the mappings between two XML documents, focusing on one-to-one mappings, which are then translated into an XSL-T stylesheet capable at transformation of actual documents.
During the direct integration the rules directly translate each XML element or attribute of the first catalog into an appropriate XML element of the second catalog (e.g., the set of XSL-T rules, which directly map a cXML address to an appropriate xCBL format, presented in Figure 4, cf. [Omelayenko & Fensel, 2001b]). This approach mixes several independent tasks in a single XSL-T rule as shown in Figure 4:
5
www.biztalk.org
9/13/2001 4:07 PM 8
• Aligning different XML syntaxes used for the documents, i.e. different ways to make XML serializations of the same information. • Aligning different terminologies, e.g. mapping the xCBL element OrganizationAddress
to the cXML element PostalAddress. • Aligning granularity level of the representations and performing necessary attribute splits with XPath expressions. For example, the Street cXML element, which actually refers to an address line with the street name and house number information, must be split into two separate Street and HouseNumber elements. Very often, this splitting is guided by ad-hoc rules, which make the splits based on the element values. • Aligning different document decomposition enforced by different document interchange schemes, e.g. xCBL assumes that actual prices are listed in purchase order, while cXML assumes that the prices are taken from product catalog. Theoretically speaking, the problem of direct translation of the trees encoded with XML is quite complicated and requires a number of significant restrictions to be solvable [Abiteboul et al, 2001]. In addition to high document complexity, a marketplace faces the problem of complex (and exponential in their number) mappings between the objects.
In consequence, the rules, which try to carry out the complete transformation process in one shot, have proven to be very complex. This causes serious problems in implementing and maintaining them: rule reuse is practically impossible and defining these rules from the scratch requires a great deal of manual effort. This leads to the first problem of high complexity of the transformation rules inspired by different complex XML serializations used for the documents (see Figure 4). The documents have complicated structures: the number of elements and attributes per document varies from tens to hundreds. Very often they contain repeating an optional elements, which makes the rules even more complicated. The marketplaces need to be able to translate between thousands of different document interoperation schemes. If a marketplace mediates between n suppliers and m buyers, then it needs to maintain up to nxm rules, which define terminology correspondence. This leads to the problem of exponential number of required terminology mappings.
An attempt to resolve two difficult problems in one shot naturally fails. We search for a solution to them in a layered approach for B2B information modeling described in the following sections.
9/13/2001 4:07 PM 9
PostalAddress to OrganizationAddress values
Mapping terminology: Figure 4. Direct translation of the cXML address to the xCBL format. The elements, which form the resulting document, are presented in a bold font
3. LAYERED DOCUMENT INTEGRATION
As shown earlier, simultaneous execution of different integration tasks causes the difficulties of the single-layered integration model. For this reason, we have used a ‘divide-and-conquer’ approach to decompose these tasks into several sub-tasks. The subtasks require the information on a certain level of abstraction, and this leads to a multi-layer approach for information modeling for integration purposes.
3.1 Three Layers of Information
We use the layered approach for information representation on the Web [Melnik & Decker, 2000], where three layers, a syntax layer, an object layer, and a semantic layer are proposed for information modeling on the Web. The syntax layer provides a way of serializing information content into a sequence of characters according to some standard, e.g. XML. The object layer offers an object-oriented view of the information with the normalized
9/13/2001 4:07 PM 10
data models of standardized triples. Finally, the semantic layer specifies a conceptual model for the information, needed to align different document standards.
Hence, we separate three layers for the catalog integration task: the Syntax layer, the Data Model layer, and the Ontology layer.
The Syntax layer corresponds to the instance documents represented with their XML serialization. The serialization specifies used XML elements, attributes, their names, ordering, and value encoding assumptions. The structure of the documents is specified with document DTD’s according to specific document standards (see Figure 1 for an example, and Figure 2 for document samples).
The Data model layer specifies the objects encoded in the documents. The mission of this layer is to provide some reasonable data model for a document, which eliminates all syntactical peculiarities introduced be the XML format used in the instance documents. We use RDF [Lassila & Swick, 1999] at this layer as the language to encode the objects. RDF is a W3C6 standard for describing machine-processable semantics of data represented by the subject-property-object triples. RDF provides three basic building blocks to represent data models. They are: resources to represent the objects (rdf:Resource tag in RDF), object properties (rdf:Property), and property values, which can be either literals or other objects. The example of RDF data models for the addresses presented in Figure 2 is shown in Figure 5.
The structure of the data models is represented with the corresponding RDF Schemas7. RDF Schema [Brickley & Guha, 2000] provides a means to define the vocabulary of for RDF properties and specify the kinds of objects to which these properties may be applied. In other words, RDF Schema provides a basic type system for RDF data models. Hence, the structure of a data model of a document specified according to some certain document standard has a corresponding conceptual model (see Figure 6 for two fragments of xCBL and cXML RDF Schemas). The terminology specified by this Schema must be aligned to the terminology used at the Ontology layer.
67
www.w3c.org
www.w3.org/TR/rdf-schema/
9/13/2001 4:07 PM 11
ShipToOrganizationAddressCity=\"Amsterdam\" ShipToOrganizationAddressCountry=\"Netherlands\" ShipToOrganizationAddressHouseNumber=\"1081\" ShipToOrganizationAddressPostalCode=\"1081hv\" ShipToOrganizationAddressRegion=\"North Holland\" ShipToOrganizationAddressStreet=\"De Boelelaan\"/> ShipToPostalAddressStreet=\"De Boelelaan 1081a\" ShipToPostalAddressisoCountryCode=\"NL\"/> (a) xCBL (b) cXML Figure 5. The fragments of data models for xCBL and cXML address (a) xCBL (b) cXML Figure 6. The fragment of a schema for xCBL and cXML address data models The Ontology layer contains a generic document ontology for each document type: product catalog ontology, ontology for a purchase order, etc. These ontologies provide the terminology used by the marketplace with formal semantics of the terms. For example the term address may refer either to delivery address, which appears in delivery documents, or to billing address, which appears in financial documents. These two kinds of an address must 9/13/2001 4:07 PM 12 be clearly separated at the ontology layer. In addition, ontologies may contain the elements, which are optional or even skipped in some document standards, helping in aligning them. A marketplace maintains a single ontology for each document, for example a purchase order ontology in RDF Schema and in Protégé-20008 is presented in Figure 7. In the figure application-specific namespaces are omitted for presentation purposes and the URI of the RDF Schema namespace is replaced with the sign rdfs:. In addition to the document ontologies, this layer contains document sequence ontologies, which specify the order in which the documents must be created, filled-in and distributed. Individual document sequences need to be aligned to these ontologies to allow the marketplace to generate specific document sequences for each customer. (a) RDFS look (b) Protégé look Figure 7. A fragment of the unified purchase order ontology (address part) 3.2 The Operation Scheme of a Marketplace The introduction of different layers allows performing more sophisticated transformations as required from the marketplaces. According to a new functioning scheme presented in Figure 8, a marketplace itself operates only with the instances of generic document ontologies, 8 See Section 6.1 for further discussion on Protégé-2000 tool. 9/13/2001 4:07 PM 13 enabling high-performance product search and retrieval, coupled with generation of supporting documents. Marketplace the unified document ontology (in RDF Schema) RDF ontology instances transform RDF data model of a source document transform RDF data model of a target document Exponential number of links is reduced by mapping via a single ontology abstract Source XML document, e.g. product catalog serialize Target XML document, e.g. product catalog Complexity of transformation rules is reduced by mapping via document data models Figure 8. Realistic marketplace performing layered document integration The document integration scenario operates in four major steps: • First, a document is abstracted from its XML serialization and translated into its RDF data model. This resolves the problem of high complexity of transformation rules inspired by complex and varying XML syntactical serializations. • Then the data model of a document is translated into the terminology used by the marketplace and specified in the corresponding document ontology stored there. At this step the granularity level of a data model is aligned to the granularity level of the representations used by a marketplace. It is intended that a marketplace will use the most detailed information decomposition, and translation to the generic ontology will require one-to-many transformations of RDF triples encoding document data models. • To generate a document in a certain (different) standard, a marketplace needs to translate the document to the terminology of the target document standard. The granularity level of the atomic concepts of the target standard may differ from the one used at the marketplace, which may require many-to-one transformations of RDF triples. 9/13/2001 4:07 PM 14 • Then the target data model is serialized according to the target XML format. At this step all syntactical peculiarities of the target standard are fully restored. The two problems, which hamper direct document integration, discussed in Section 2.2 are resolved at two different layers: the high complexity of the rules inspired by the XML serializations is resolved at the abstract/serialize steps, and the problem of exponential number of terminologies is resolved at the marketplace by mapping through a document ontology at the transformation steps. The latter reduces the number of required mapping from nxm to n+m (see Figure 9). Supplier Catalog 1 Supplier Catalog 2 Supplier Catalog n Unified Catalog at the marketplace Buyer Catalog 1 Buyer Catalog 2 Buyer Catalog m Figure 9. Exponential number of mappings is reduced to linear 4. INFORMATION TRANSFORMATION Information presented in the documents need to pass several stages to be imported by a marketplace or exported into a specific document format, as depicted in Figure 8. At these stages it passes through several transformations illustrated in Figure 10. The figure contains two levels: the schema level and the instance level. At the schema level the transformations are semi-automatically specified and approved by the user at the level of document structures and document conceptual models. At the instance level the transformations are actually executed on the instance documents. The transformations are performed at two consequent steps: the abstraction (and the corresponding refinement) step and the RDF transformation step, as described in the two following subsections. 9/13/2001 4:07 PM 15 Tool support in removing XML-specific peculiarities. Includes XPath editor Document structure in DTD Document conceptual model in RDFS Tool support in aligning specific document data model to the model enforced by the ontology Unified document ontology in RDFS Instance of document ontology in RDF Instance document in XML The mappings are executed with the rules in XSLT Documents’ data model in RDF The mappings are executed with the rules in some RDF Transformation language Figure 10. The information transformation scheme 4.1 Abstraction and Serialization Rules At the abstraction and the opposite refinement steps depicted in Figure 8 actual XML documents are translated into their data models of RDF triples and vise versa. Because the user is potentially inexperienced in XSL-T programming (i) he needs a sufficient tool support and (ii) he might be required to create only simple mappings, which use the same terminology as used in the DTD’s of the to be transformed. The tool might provide the following functionality: • To allow the user to observe the DTD’s of the documents and RDF Schemas of the data models and specifies the mappings (including one-to-many and many-to-many) between DTD and RDF Schema elements, needed to perform the transformation (cf. Figure 10). Necessary parsers might be created visually using templates. • Automatically generate both abstraction and serialization XSL-T stylesheets from the mappings, using XPath to encode necessary element parsers. These automatically generated abstraction rules perform the following transformations: • Translation of each XML element or XML attribute, which refers to a product feature into the corresponding RDF property. • Inclusion optional XML elements in the RDF triples. • Splitting a single element or attribute into two or more, if necessary. 9/13/2001 4:07 PM 16 During the serialization step, all syntactical restrictions required by the target format are restored: • Each RDF triple is serialized with a corresponding XML element or attribute. • Target XML elements are created in proper order. • The elements with missing values must be created in proper places and filled-in with default values. The terminology is intended to be the same in both catalogs and data models. However, the rules may contain splitting and/or merging of the elements. Hence, both types of rules one-to-many (including one-to-one) and many-to-one (again, including one-to-one) may occur at this stage. However, no many-to-many rules are necessary: the architecture is designed in a way when they are executed via multi-layer transformations, and not via complicated mappings, difficult to be edited and maintained. 4.2 RDF Transformations The data models of the documents must be transformed to the data models of the ontology instances maintained by a marketplace (as depicted with the transformation step in Figure 8) and vice versa. All inter-standard mappings are performed via mapping each individual standard to a generic document ontology stored at the marketplace. For this the user needs a tool support in aligning the terminologies used in the standards. The tool must provide the following functionality: • The user is presented with documents’ conceptual model in RDF Schema and the ontology maintained by a marketplace (again, in RDF Schema), and specifies the equivalence mappings between the terminologies, as shown in Figure 10. • The tool must export the mappings in a special RDF Schema mappings language (RDFS-m) required to store the mappings and having necessary validation tools. • The mappings must be automatically translated into a special RDF transformation language (RDF-t) to be then executed and translate RDF documents. Unfortunately, no standard supported RDF transformation language or tool is available now and we need to develop two RDF transformation languages: RDF Schema mapping language RDFS-m and RDF Transformation language RDF-t. RDF-t rules might be automatically derivable form RDFS-m expressions. Both languages need certain tool support and may be independently reused in many Semantic Web applications. 9/13/2001 4:07 PM 17 From the technical perspective mapping execution requires aligning and transformation one RDF data model to another RDF data model. RDF data models [Lassila & Swick, 1999] contain three types of objects: • Resources, marked with the rdf:Resource tags, and identifying objects stored in the documents (e.g., and Address) with their URI’s. • Properties, marked with the rdf:Property tags, and identifying properties of the objects (e.g., Street property of an Address) with property names. • Statements, or RDF triples of the form subject-property-object, where subjects are represented with resources, and objects are either resources or literals. The structure of the statements is specified by the means of RDF Schema. Basically, each property is defined by its property name, property domain (i.e. the list of classes to which the property is applicable), property range (i.e. the list of types for allowable property values). For example, the definition of the ShipToCity property of a unified purchase order, represented in Figure 11 (b), specifies that this property has string values (rdfs:Literal range) and is applicable to uPurchaseOrder class. 4.2.1 RDF Schema Mapping Language RDFS-m The RDF Schema mapping language RDFS-m is needed to encode the mappings between classes and their properties, represented in two RDF Schemas. The language provides the following basic structures: • Class bridges specify mappings between RDF Schema classes. Each bridge implements a one-to-many or many-to-one mapping, coupled with bi-directional parsers for class names. • Property bridges specify mappings between RDF properties. Each bridge implements a bi-directional mapping for property names, domains, and range (value type). Document ontologies are not very complicated; they have shallow inheritance hierarchy and no real hierarchy of properties. Property assignments to classes are also straightforward. However, expanding RDFS-m to the needs of the Semantic Web will require handling multiple inheritance, property hierarchies, non-trivial ways of attaching properties to classes, constraint and axiom mapping and validation. 9/13/2001 4:07 PM 18 4.2.2 RDF Transformation Language RDF-t RDF transformation language RDF-t is needed to encode the transformations of RDF documents represented with sets of triples. Because RDF documents can be treated as labelled graphs, we adopt the ideas used in graph transformation languages [Taentzer, 2001]. Each RDF document is partitioned by the user in small subdocuments (subgraphs) which can be transformed independently by a single bridge. Normally, each subdocument represents description of a single RDF object (e.g. object price with two properties: amount and currency). Each bridge consists of: • Source and target triples, where each triple is identified by object type, property name, and value type (or value template for rdfs:Literal). • Mapping of resources, which occurred in these triples. Each mapping specifies a one-to-many or many-to-one relation between resources, coupled with bi-directional resource name parsers. • Mapping of properties, which occurred in the triples, which has the same structure as mapping of resources. RDF-t expressions may be programmed manually. However, we assume that they will be automatically derived from RDFS-m expressions. Application of RDF-t to the document integration task requires the following: • Object names must be aligned with one-to-one mappings (e.g., cXMLPurchaseOrder must be aligned to uPurchaseOrder in the example in Figure 11). • Property values are assumed to be equal to rdfs:Literal and require no aligning. • Property names must be aligned (e.g. cXML element ShipToPostalAddressCity must be aligned to the unified element ShipToStreetCity). This requires only one-to-one mappings assuming that granularity level of the representations have been aligned at the previous abstraction stage. (a) cXML purchase order (b) unified purchase order Figure 11. Aligning an cXML purchase order and the unified purchase order These requirements are relaxed from the needs of the Semantic Web, where full-fledge RDF transformation is needed. We are now developing both RDFS-m and RDF-t languages, collecting practical experiences, and elaborating necessary tools. In addition to the document 9/13/2001 4:07 PM 19 integration tasks, they will be capable of handling more complex Semantic Web transformation tasks. 4.3 Ontology Alignment The marketplace needs to maintain and utilize a number of ontologies, which might be aligned together. The alignment involves the following issues: • The number of ontologies can be high (up to one hundred), according to the high number of business document normally involved in a procurement chain. • The documents described by the ontologies have different non-primitive roles and complicated interactions, described by a certain e-business document sequence ontology. Hence, all ontologies must be aligned to the latter. • The ontologies might reuse some of their parts (e.g. address descriptions, product descriptions, etc.) • The decomposition of the information among the documents differs between the standards (e.g., cXML assumes that detailed product descriptions must be present in purchase orders, while xCBL does not). In a sense, each document can be treated as a view on the whole set of ontologies maintained by a marketplace and require information from several ontologies. The alignments are then used to perform the transformations of the documents, executed on the basis of the mappings. 5. IMPLEMENTATION AND PRACTICAL EXPERIENCE In this section we discuss how the proposed methodology can be applied to integrate cXML and xCBL product catalogs, purchase order requests and purchase orders themselves. Additional information about the application is available from the project homepage.9 5.1 Document Decomposition The documents consist of several main building blocks: partner encoding, price, and product description, which are interconnected in different ways. In both standards the creation order of these documents remains the same: after a buyer have observed the product catalog, he generates a purchase order request for certain items from the catalog, and then the marketplace provides a complete purchase order to be processed by the customer. 9 www.cs.vu.nl/~borys/cat_int/ 9/13/2001 4:07 PM 20 cXML partner encoding scheme used to encode product manufacturers, suppliers and buyers relies on a certain partner coding service like DUNS10. Hence, it assumes that all knowledge about the partner (partners’ profile) is stored outside the marketplace. The documents use partner codes to identify the partners. Integration of the documents which use several different partner coding scheme requires mapping of partner codes. Most likely this will require only one-to-one mappings, due to the fact that each partner may have at most one unique partner code in each standard. xCBL does not rely on any partner coding service, and explicitly stores partner names and addresses in the documents, which need to be translated. Both standards use similar ways to represent pricing information. However, they posses different views in which documents the price may appear. cXML assumes that product price may appear in a product catalog only, and may not be changed during the product ordering process. xCBL, however, assumes price negotiation and includes price information in all the documents: product catalogs, purchase order requests, and purchase orders themselves. The ontology for detailed product descriptions listed in product catalogs is quite similar in both standards. However, due to different implementation strategies, the cXML standard assumes that some of product details will reappear in purchase orders. 5.2 Information Processing Information processing is preformed according to the scheme presented in Figure 8, and consists of two similar information flows: uploading a document to the marketplace with abstraction and RDF transformation steps, and getting a document from the marketplace with RDF transformation and refinement steps. During the abstraction/serialization stage an XSL-T stylesheet is used to generate an RDF data model of the documents. The stylesheet is customized with user-defined XPath rules, which perform necessary element transformations. Normally, just a few (two or three) XPath parsers are required per document, related to date, timestamps, and address fields. This observation is quite similar to the statistics made for restricted examples in [Omelayenko & Fensel, 2001b]. RDF transformation stage requires creation of 20-30 one-to-one RDF-m mappings per document to align it to the ontology. This requires deep understanding of semantic of each document element, achieving by analyzing documentation coming with a certain document standard and the ontology. Besides tool support in editing and encoding the mappings, the 10 www.dnb.com/english/duns/default.asp 9/13/2001 4:07 PM 21 user need automated advising services, which will check consistency and completeness of the mappings. And RDF Scheme storage and querying engine may be used to actually store the mappings, access ontologies referenced from the mappings, and retrieve correspondent ontology instances in RDF. For example, we can use the Sesame RDF(S) storage and querying engine, which seems to be the only working tool in this area (see Section 6.3 for more information on Sesame). We stored the ontologies and their instances at Sesame, querying it for mappings and actual pieces of information, paths to which were discovered by analyzing the mappings. A fragment of the query response is presented in Figure 12. The response specifies that the value of the value property of the cxmlProductCatalog_PunchoutDetailClassification object must be renamed to the ClassificationCode property of the uProductCatalog object. Figure 12. A fragment of a renaming table responded by Sesame These mappings are then processed by the RDF transformation engine to perform actual data document transformation, an illustration of which is presented in Figure 13. (cxmlProductCatalog, Classification, cxmlProductCatalog_PunchoutDetailClassification) (cxmlProductCatalog_Classification, value, 43171801) (a) source triple from a cXML catalog (uProductCatalog, ClassificationCode, 43171801) (b) target triple (unified ontology instance) Figure 13. A fragment of RDF transformation A fragment of the information transformation scheme is presented in Figure 14. It illustrated three threads of information flow required to generate an cXML purchase order given a product catalog in xCBL: • Some of the document elements need to pass through other documents maintained by the marketplace. For example, the marketplace maintains the list of partner profiles (as represented with the uPartnerDirectory ontology in Figure 14). xCBL catalog references the directory with the ProductVendorDataPartnerRef element, which is aligned to the SupplierCode ontology element, present in the product catalog ontology. A query to the marketplace ontologies links it to the ShipToPostalAddressCountry element required to generate a purchase order in cXML, and then the RDF transformation engine performs corresponding renamings on the instance document. 9/13/2001 4:07 PM 22 • Some of the elements are not transformed into target documents, but only used for transformation. For example, the ValidUntil xCBL catalog element is translated into OfferValidUntil ontology element, and used to generate a proper purchase order. Another example is DefaultLanguage xCBL catalog element, which may be used to expand product descriptions, if no language of them is specified explicitly. • Finally, the marketplace enforces a specific document infrastructure, which is necessary for it to function, but differs from the structures assumed by document standards. For example, very often product descriptions are assumed as a part of product catalogs (like in the cXML and xCBL case). However, the marketplace needs to search and retrieve these descriptions and needs to treat them separately from other documents, as instances of the uProductDescription ontology. Hence, the catalog element ProductSchemaCategoryRef is mapped to the uProductDescription ontology and not to the uProductCatalog ontology. Accordingly, document generation requires collecting necessary document elements from instances of different ontologies. ShipToCountry, ShipToStreetName, ShipToHouseNumber, … OfferValidUntil ClassificationCode Terminology of the marketplace ontologiesuParnterDirectory SupplierCode uPurchaseOrder uProductDescription RDF-based terminology transformationuProductCatalog RDF-T RDF-T ProductSchemaCategoryRef ShipToPostalAddressCountryTerminology of a document standardProductClassification cXML Purchase Order ValidUntil ProductVendorDataPartnerRef xCBL Product Catalog Figure 14. A fragment of an ontology-based information transformation scheme In our prototype we used web-accessible Sesame query interface, an RDF parser implemented in Perl, a stand-alone XSL-T parser and a stand-alone mapping tool prototype. Let us continue with a closer look on some of specific tools needed to develop complete and functional document integration system. 9/13/2001 4:07 PM 23 6. RELATED WORK Despite the fact that there exist no tools capable of solving the problems of B2B document integration, there exist a number of related projects and tools able to help in solving these problems. In the rest of this section we survey several ultimately relevant approaches, which may be used in the B2B document integration tasks. 6.1 Protégé-2000 Ontology Editor Protégé-200011 [Grosso et al, 1999] is an integrated knowledge-base editing environment and an extensible architecture for the creation of customized knowledge-based tools. The tool supports the OKBC knowledge model and maintains ontologies consisting of classes, slots, facets, and class instances. The tool has a decade-long usage history and a wide community of users worldwide and may be used to create and maintain the ontologies used by a marketplace (see Figure 15 for an example). Protégé-2000 is able to export the ontologies in RDF Schema, and ontology instances in RDF. These formats may be used by a marketplace to store and query document instances. Starting from version 1.5, Protégé-2000 provides an API, which allows development of different plug-ins for various possible applications requiring creation and edition of ontologies and ontology instances. A prototype plug-in targeted at the needs of B2B document integration may be developed to assist in navigating document ontologies and their instances. Another important feature of Protégé-2000 is its ability to generate knowledge acquisition tools given an ontology as a template. These tools provide a friendly interface for a user entering his business documents. However, Protégé-2000 is mainly targeted at the knowledge engineering community and might be seriously adapted and even reimplemented to be used for real-life document edition by the users of a marketplace. 11 http://protege.stanford.edu/ 9/13/2001 4:07 PM 24 Figure 15. Editing a purchase order ontology in Protégé-2000 6.2 RDF Parsers, Advanced Programmers Interfaces, and Libraries The SiRPAC12 RDF parser SiRPAC is a set of Java classes that can parse RDF/XML documents into the three-tuples of the corresponding RDF data model. The parser has evolved in several versions, which have been published, and is now a de-facto standard in Java-based RDF development. Profium13 tool targets at the same objective as SiRPAC and provides similar functionality. It is available as a Perl script in addition to its Java implementation. The ICS-FORTH14 Validating RDF Parser is a tool for parsing RDF Statements and validating them against an RDF Schema. The parser analyses syntactically the statements of a given RDF/XML document according to the RDF Model and Syntax specification. The tool checks whether both the RDF Schemata and related Metadata instances satisfy the semantic constraints implied by the RDF Schema Specification. There exists a number of other RDF-supporting tools and libraries, as well as a number of lists of those tools. For example, the Dave Beckett's RDF page15, the W3C RDF page16, and so on. These tools need to be used in development of the tools required for the integration. www.w3.org/RDF/Implementations/SiRPAC/ www.profium.com 14 http://www.ics.forth.gr/proj/isst/RDF/ 15 www.ilrt.bris.ac.uk/discovery/rdf/resources/ 1312 9/13/2001 4:07 PM 25 6.3 Sesame: an RDF Querying Tool Sesame17 is an RDF schema-based repository and querying facility, being developed by Aidministrator18 in the frame of the On-To-Knowledge19 project [Fensel et al, 2000]. Sesame provides substantial functionality in querying RDF instances and RDF Schemas, using an object oriented query language RQL (see [Broekstra et al, 2000] for the state-of-art survey). The ontologies are stored in RDF Schema at the server. The ontologies and their instances are accessible in a uniform way be means of RQL queries. The RQL language implemented in Sesame allows querying class definitions and class instances by their properties, supporting an extensive set of querying expressions. The uploaded RDF descriptions are parsed using the SiRPAC parser, and stored in the Object-Relational DBMS PostgreSQL20. The service is available either through http requests, or via a Web interface. An example of a query formulated to the Sesame service is presented in Figure 16. Sesame can be efficiently used to query ontologies and getting explicit representation of the transformations and renamings required. In addition, it is a good candidate query engine for storage and querying instance documents themselves. 16 www.w3.org/RDF/ http://sesame.aidministrator.nl/ 18 www.aidministrator.nl 19 www.ontoknowledge.org 20 www.postgresql.org/ 17 9/13/2001 4:07 PM 26 Figure 16. Querying Sesame 6.4 Triple: an RDF Rule Language Triple21 is a recent initiative targeted development of an Open-Source Query and Inference Language and Engine for Semi-Structured Data (RDF and DAML/OIL). The language is a successor of SiLRI [Decker et al, 1998], a simple logic-based RDF interpreter. Triple is proposed as a new RDF query and inference language, providing full support for resources and their namespaces, models represented with sets of RDF triples, reification, RDF data transformation, and an expressive rule language for RDF. The language is intended to be used with any Horn-based inference engine. At the present time, Triple is still an emerging initiative. No syntax or semantics specification has been developed yet, and no tools support is available. After getting its mature status Triple will become an important language for B2B document integration, with a huge potential. 21 http://www-db.stanford.edu/~stefan/2001/02/rdfinterest/ 9/13/2001 4:07 PM 27 6.5 PROMPT: an Ontology Integration Tool The PROMPT22 tool [Noy & Musen, 2000] is available as a plug-in for Protégé-2000 targeted to help the user in ontology merging. PROMPT takes two ontologies as input and guides the user in the creation of a single merged ontology as output. First PROMPT creates an initial list of matches based on class names. Then it guides the user through the following integration cycle: (1) the user triggers an operation by either selecting one of PROMPT’s suggestions from the list or by using an ontology-editing environment to specify the desired operation directly; and (2) PROMPT performs the operation, automatically executes additional changes based on the type of the operation, generates a list of suggestions for the user based on the structure of the ontology around the arguments to the last operation, and determines conflicts that the last operation introduced in the ontology and finds possible solutions for those conflicts. The tool can be used to merge various ontologies to create the general ontology (e.g., a product catalog ontology out of standard-specific cXML, xCBL, etc. catalog formats), which is stored at the marketplace and serves as a mediator between different document formats. However, for the B2B document integration task ontology mapping (i.e. making bridges between different non-changeable ontologies) seems to be more important than ontology merging (i.e. creating a single ontology out of several other ontologies), and PROMPT provides no support in this task. 7. CONCLUSIONS AND FUTURE WORK In the present paper we discussed the framework for document integration targeted at the needs of B2B document integration. The framework decomposes the whole integration process into several independent transformation steps, which transform the information among several levels with different degree of abstraction. The approach possesses the following features: • Helps in maintaining large sets of transformation rules by providing their decomposition into smaller and more understandable pieces and facilitating rule reuse. • Reduces the problem of exponential number of terminology mappings between different document representations to linear related to the number of standards to be aligned. • Automates the process of creation of transformation rules providing decomposition of it into simpler sub-tasks, understandable to a non-programming professional. 22 http://protege.stanford.edu/plugins/prompt/prompt.html 9/13/2001 4:07 PM 28 • Focuses at extraction and manipulation with conceptual document models, facilitating their further integration into non-trivial procurement and trade mediation scenarios. As a whole, the architecture provides a possible solution for several technical problems, which hamper involvement of SME’s and diversification of B2B marketplaces, and slow development of the B2B mediation industry. However, in addition to document integration, the marketplaces need to resolve several other problems, which are not addressed in the paper. These are: integration of document sequences (also known as business process ontologies) and integration of product ontologies (mostly represented by content standards and their extensions). Besides some preliminary work already done (cf. [Navathe et al, 2001], [Fensel et al, 2001], [Omelayenko, 2001]), these issues still require lots of research in the upcoming future. Most of the tools mentioned within this paper are research prototypes; they contain bugs, are affected by changes and modifications, and are still making their difficult way to ready products. At present time building a complete and reusable document integration package out of them is not possible, and was not in the focus of the paper. Instead, we focused on development of the architecture, which will allow resolving emerging integration tasks with new emerging technology, when the task will become crucial and technology mature. The B2B information integration tasks are quite similar to the tasks to be solved while building the Semantic Web. They are: • Constructing RDF conceptual models from XML documents, which is called ontology-based data annotation in the Semantic Web community. • Aligning different document ontologies and large-scale product ontologies. • Performing ontology-based information querying and retrieval, which we used to find out the mappings between document elements, and which will be the kernel function of the Semantic Web. • Performing complicated and knowledge-intensive information transformation, including generation of conceptually different views on the same knowledge. From one side, the B2B document integration scenario needs Semantic Web technologies as a pre-requisite. From another side, it serves as a killing application for the Semantic Web, providing a perfect test ground for technology development and getting industrial experience. From this perspective, future research directions for the B2B document integration task are similar to those for the Semantic Web: 9/13/2001 4:07 PM 29 • Development the RDFS-m RDF Schema mapping language and RDF-t RDF transformation language and transformation engines, as it has been done with the XSL-T language for XML. • Development a full-fledge RDF (Schema) querying engine. RDF querying service must become as mature as SQL querying service for databases to be widely accepted and used. • Improving of RDF (Schema) inference tools to be able to inference over schema and instance documents with reasonable performance and acceptable application restrictions. All these technologies need to be developed to bring the vision of the Semantic Web into reality and bring to reality new ways of doing business powered with the new Web. ACKNOWLEDGEMENT We would like to thank Guy Botquin, Jeen Broekstra, Stefan Decker, Michel Klein, Maksym Korotky, Haifei Li, Ellen Schulten, and Volodymyr Zykov for their helpful discussions and comments. REFERENCES [Abiteboul, Cluet, and Milo, 2001] Abiteboul, S., Cluet, S., and Milo, T., \"Correspondence and Translation for Heterogeneous Data\[Berners-Lee and Fischetti, 1999] Berners-Lee, T. and Fischetti, M., Weaving the Web, Herper, San Francisco, 1999. [Brickley and Guha, 2000] Brickley, D. and Guha, R., \"Resource Description Framework (RDF) Schema Specification 1.0\W3C Candidate Recommendation, 2000. [http://www.w3.org/TR/rdf-schema] [Broekstra, Fluit, and van Harmelen, 2000] Broekstra, J., Fluit, C., and van Harmelen, F., \"The State of the Art on Representation and Query Languages for Semistructured Data\IST-1999-10132 On-To-Knowledge Project, Deliverable 8, 2000. [http://www.ontoknowledge.org/del.shtml] [Clark, 1999] Clark, J., \"XSL Transformations (XSL-T)\ W3C Recommendation, 1999. [http://www.w3.org/TR/xslt/] [Clark and DeRose, 1999] Clark, J. and DeRose, S., \"XML Path Language (XPath), version 1.0\W3C Recommendation, 1999. [http://www.w3.org/TR/xpath] 9/13/2001 4:07 PM 30 [Commerce One, 2000] Commerce One Inc., \"Commerce One XML Common Business Library (xCBL) 3.0\ In: Press release made at the eLink Conference, Hong Kong, November 29, 2000. [http://www.commerceone.com/news/us/xcbl30.html] [Decker et al., 1998] Decker, S., Brickley, D., Saarela, J., and Angele, J., \"A Query and Inference Service for RDF\Proceedings of the W3C Query Languages Workshop (QL-1998), December 5, 1998. [http://www.w3.org/TandS/QL/QL98/pp/queryservice.html] [Eder and Strametz, 2001] Eder, J. and Strametz, W., \"Composition of XML-Transformations\ Proceedings of the Second International Conference on Electronic Commerce and Web Technologies (EC-WEB 2001), LNCS 2115, Munich, Germany, September 4-6, 2001 , pp. 71-80. [Fensel, 2001] Fensel, D., Ontologies: Silver Bullet for Knowledge Management and Electronic Commerce, Berlin, Springer-Verlag, 2001. [Fensel at al., 2001] Fensel, D., Ding, Y., Omelayenko, B., Schulten, E., Botquin, G., Brown, M., and Flett, A., \"Product Data Integration for B2B E-Commerce\IEEE Intelligent Systems, vol. 16, no. 4, 2001, pp. 54-59. [Fensel et al., 2000] Fensel, D., van Harmelen, F., Akkermans, H., Klein, M., Broekstra, J., Fluit, C., van der Meer, J., Schnurr, H.-P., Studer, R., Davies, J., Hughes, J., Krohn, U., Engels, R., Bremdahl, B., Ygge, F., Reimer, U., and Horroks, I., \"OnToKnowledge: Ontology-based Tools for Knowledge Management\Proceedings of the eBusiness and eWork 2000 Conference (EMMSEC-2000), Madrid, Spain, October 18-20, 2000. [Grosso et al., 1999] Grosso, W., Eriksson, H., Fergerson, R., Gennari, J., Tu, S., and Musen, M., \"Knowledge modeling at the millennium (the design and evolution of Protege-2000)\Proceedings of the Twelfth Banff Workshop on Knowledge Acquisition, Modeling, and Management, Voyager Inn, Banff, Alberta, Canada, October 16-21, 1999. [ISO, 2000] ISO Standard, \"Integrated generic resource: Fundamentals of product description and support\ International Standard ISO 10303-41, Second Edition, 2000. [Lassila and Swick, 1999] Lassila, O. and Swick, R., \"Resource Description Framework (RDF) Model and Syntax Specification\W3C Recommendation, 1999. [http://www.w3.org/TR/REC-rdf-syntax/] [Li, 2000] Li, H., \"XML and Industrial Standards for Electronic Commerce\Knowledge and Information Systems, vol. 2, no. 4, 2000, pp. 487-497. [Melnik and Decker, 2000] Melnik, S. and Decker, S., \"A Layered Approach to Information Modeling and Interoperability on the Web\Proceedings of the Workshop on the Semantic Web at the Fourth European Conference on Research and Advanced Technology for Digital Libraries (ECDL-2000), Lisbon, Portugal, September 21, 2000. 9/13/2001 4:07 PM 31 [Navathe et al., 2001] Navathe, S., Thomas, H., Amitpong, M. S., and Datta, A., \"A Model to Support E-Catalog Integration\Proceedings of the Ninth IFIP 2.6 Working Conference on Database Semantics, Hong-Kong, April 25-28, 2001, pp. 247-261. [Noy and Musen, 2000] Noy, N. and Musen, M., \"PROMPT: Algorithm and Tool for Automated Ontology Merging and Alignment\Proceedings of the Seventeenth National Conference on Artificial Intelligence (AAAI-2000), Austin, Texas, July 30 - August 3, 2000. [Omelayenko, 2001] Omelayenko, B., \"Preliminary Ontology Modeling for B2B Content Integration\ Proceedings of the First International Workshop on Electronic Business Hubs at the Twelfth International Conference on Database and Expert Systems Applications (DEXA-2001), IEEE CS Press, Munich, Germany, September 3, 2001, pp. 7-13. [Omelayenko and Fensel, 2001a] Omelayenko, B. and Fensel, D., \"A Two-Layered Integration Approach for Product Information in B2B E-commerce\Proceedings of the Second International Conference on Electronic Commerce and Web Technologies (EC WEB-2001), LNCS 2115, Munich, Germany, September 4-6, 2001, pp. 226-239. [http://www.cs.vu.nl/~borys/papers/] [Omelayenko and Fensel, 2001b] Omelayenko, B. and Fensel, D., \"An Analysis of Integration Problems of XML-Based Catalogs for B2B Electronic Commerce\Proceedings of the Ninth IFIP 2.6 Working Conference on Database Semantics, Hong Kong, April 25-28, 2001, pp. 232-246. [http://www.cs.vu.nl/~borys/papers/] [Shim et al., 2000] Shim, S., Pendyala, V., and Gao, J., \"Business-to-Business E-Commerce Frameworks\ IEEE Computer, vol. 33, no. 10, 2000, pp. 40-47. [Taentzer, 2001] Taentzer, G., \"Towards Common Exchange Formats for Graphs and Graph Transformation Systems\Electronic Notes in Theoretical Computer Science, vol. 44, no. 4, 2001. [US Department of Commerce, 2001] US Department of Commerce, \"Leadership for the New Millennium, Delivering on Digital Progress and Prosperity\Working Group at the US Department of Commerce, 16 January, 2001. 因篇幅问题不能全部显示，请点此查看更多更全内容