Preliminary Ontology Modeling for B2B Content Integration

Transcription

1 In: Proceedings of the First International Workshop on Electronic Business Hubs at the Twelfth International Conference on Database and Expert Systems Applications (DEXA-2001), Munich, Germany, September 3, Preliminary Ontology Modeling for B2B Content Integration Borys Omelayenko Division of Mathematics and Computer Science Vrije Universiteit, Amsterdam, The Netherlands URL: Abstract Content Management becomes a cornerstone issue of successful B2B electronic commerce. B2B marketplaces bring together many online suppliers and buyers, which use different to describe their products. Particularly, they use different content to specify the products with product classification hierarchies and product attributes, and different catalog representation to represent product catalogs. Content need to be linked to product catalog documents. In the paper we discuss how a multi-layered B2B information integration framework must be extended with these links. In addition, content must be integrated to enable content-based product search. Further content integration techniques depend on a number of issues inspired by the nature of content and the purpose of integration, also discussed in the paper. 1. Introduction Electronic marketplaces for Business-to-Business (B2B) electronic commerce bring together many online suppliers and buyers, which participate in business interactions. Internet and web-based electronic commerce provide a much higher level of flexibility and openness, which helps to optimize business relationships (cf. [1] for an overview of the field). According to the U.S. Department of Commerce [2] estimates, there were around 800 B2B marketplaces in early Other studies estimate around 10,000 B2B marketplaces in the very near future. These marketplaces provide completely new opportunities for their clients: A supplier, linked to a marketplace is automatically linked to a large number of potential customers, instead of implementing one-to-one links to each supplier. A supplier or a customer can choose between a large number of potential business partners and can optimise his business relationships. Hence, a buyer being connected to a marketplace immediately gets access to millions of products. Having resolved the problem of establishing many business connections, he arrives at the problem of finding the required product in a mess of offers. To help the customers in searching for offers, B2B marketplaces have to integrate multiple content and link them to catalog representation, which specify the structure of product catalogs. Hence, they need to solve several mapping problems (cf. [3] for an overview): Aligning different for describing products, or content (e.g., UN/SPSC 1 versus ecl@ss 2 ). Linking different catalog representation, which specify the way to represent product information in product catalogs (e.g., Ariba 3 versus CommerceOne 4 ), to content. Aligning different for describing exchanged business documents, such as purchase orders (e.g., XML Common Business Library xcbl 5 versus Commerce XML cxml 6 ). The research community has just started to discuss these tasks. EE-Cat content management system [4] targets some of the content management problems without linking them to the XML document or content used in the B2B area. However, it provides an attempt to formalize the catalog integration and querying problem and a first sketch of a catalog querying language. An attempt to handle B2B integration problems with knowledge engineering techniques is presented in [5]. It discusses construction of a B2B ontology taking existing content as a starting point. Content are treated as very simple ontologies, which are not interesting from the knowledge engineering perspective. However, they provide standard classification schemes and standard terminologies, and must be used as is in

2 more elaborated ontologies, and not as a changeable basis. Knowledge engineering techniques cannot be easily applied to the content integration task due to huge size of content (more than 12,000 classes). B2B content integration is strongly connected to a document integration task. BizTalk 1 initiative provides an elaborated toolkit facilitating document management for B2B marketplaces. Besides its current focus at document interchange, it provides a backbone architecture able to plug-in content integration services. B 3 project [6] aims at development the tool support for catalog management. At present time, it does not conform to any of document or content, but provides a significant insight into technical aspect of the B2B information integration problems. In present paper we discuss a possible way to link content to product catalogs and the problems arising in aligning content. The discussion contributes to the multi-layer framework for B2B information integration [7]. Content are briefly discussed in Section 2, and the multi-layered approach for the catalog integration problem is sketched in Section 3 of the paper. This approach introduces an Ontology layer, which includes content as discussed in Section 4. Content must be linked to document data models as discussed in Section 5. Their alignment depends on business requirements listed in Section 6. Available integration techniques together with future research directions and general discussions are presented in Conclusions. 2. Content Standards Content provide hierarchies of product descriptions and define the subclass-of relationship between product categories. Each product from a product catalog has an attached link to a certain product category, which actually describes the product. The content may be classified into horizontal and vertical (cf. [3]). As shown in Figure 1, horizontal provide a high-level classification of all possible products and cover many domains. Each of the vertical provides a deep and narrow classification of a certain limited domain, e.g. the domain of IT devices. Normally, a vertical standard expands several bottom-level categories of a horizontal standard. The most well-known horizontal standard UN/SPSC has a 5-level classification scheme with more than 12,000 categories. It is not descriptive, that is, it contains no attributes for products but only the hierarchy of product names. Consequently, the next initiative, UCEC 2 provides an extension to the UN/SPSC standard with attributes. It uses only four top levels of the UN/SPSC hierarchy and provides a couple of attributes for each category, for example, the category [ ] Specialty envelopes has six attributes: type, length, width, weight, colour, and composition. Another horizontal standard, ecl@ss, supports the flow of products and information along the supply chain of an industrial enterprise and it is mainly used in Germany. It provides more than 12,700 categories with attributes tailored to the needs of industrial customers and their suppliers. Vertical for Domain 1 Figure 1. The relationship between horizontal and vertical There exist a number of vertical. For example, ISO 3 provides many product coding specific for certain branches of industry. Another standard, RosettaNet 4, contains a catalog of IT products with a categorization, product attributes, and mapping each category to UN/SPSC. Large manufacturers tend to develop special product cataloguing schemes, and usually these schemes are reflected in the product coding system used by the company. Finally, a company may have its own focus and therefore require specific product classification scheme. Hence, the products may be classified in the suppliers catalog according to some certain content standard, which may differ from the content standard used by the buyer to specify its needs. In consequence, a B2B mediation system must be able to reclassify a product, being already classified once, according to another classification schemas. 3. Multi-Layer View on Catalog Integration An attempt to integrate XML-based product catalogs directly with XSL-T rules [8] has shown a number of problems. These problems originated from the fact that direct catalog integration mixes two different aspects in one set of XSL-T rules: syntactical differences inspired by different ways of using XML syntax and semantic Horizontal Vertical for Domain 2 Vertical for Domain n

3 diversity of the terminologies (with different granularity levels). To resolve these problems, three layers for the catalog integration task were distinguished in [7]. These include a Syntax layer, a Data Models layer, and an Ontology layer. The Syntax layer corresponds to the instance documents represented with their XML serialization. The serializations specify necessary XML elements and attributes, and their order. At the Data models layer the representations are abstracted from the differences imposed by the Syntax layer and the products are represented by object-property-value triples, where the properties stand for document elements. RDF [9] is used at this layer as a language to encode the triples. RDF is a W3C 1 standard for describing machine-processable semantics of data that is also represented by the objectproperty-value triples. The Ontology layer defines a terminology used to represent the information provided by various product and document. Actual transformation between different catalogs is performed at the Data Models layer; however, the Ontology layer is a pre-requisite for the integration as it specifies the terminology in detail, sufficient to define complicated inter-catalog transformations with simple one-to-one mapping rules. Ontology layer (RDF Schema) Document interchange ontology Generalized catalog ontology Ontology of a catalog as exchangeable business document Data model layer (RDF) Data model of a catalog document Business part price, vendor, etc. Syntax layer (XML) Product meta-ontology Product ontology or Content standard Ontology of a catalog as a product category instance Product description part category, attributes Catalog document instance 4. Ontology Layer for Content Integration Figure 2. The multi-layered model for content integration The Ontology layer introduced in [7] serves to represent two types of ontologies: business document ontologies and product ontologies. Document ontologies specify the models for the documents including their role in the document interchange scheme used by a company or a marketplace. Technically speaking, product catalogs are a special kind business documents. However, they are the only documents that link to content, and this differentiates them from other documents. Product ontologies specify the models and hierarchies of products and product attributes, according to certain content. Usually, content provide no XML or RDF serialization of product descriptions. To separate these two disjoint pieces of information we have to extend the Ontology layer as presented in Figure 2. Prior to integration, an XML catalog document depicted in the bottom of the figure, is first translated into its data model represented in RDF as discussed in [7]. This data model contains two parts: a business document 1 Meta-Ontology or Content Representation Scheme Product Ontology or Content Standards Figure 3. A sample of two product ontologies linked to a meta-ontology

4 <rdf:description about="armadam700"> <SupplierPartID> </SupplierPartID> <SupplierPartAuxiliaryID>AUX00ID</SupplierPartAuxiliaryID> <currency>usd</currency> <Money>1000</Money> <Description>Armada M700 PIII GB</Description> <Description-lang>en</Description-lang> <UnitOfMeasure>EA</UnitOfMeasure> <Classification>C </Classification> <ClassificationScheme>SPSC</ClassificationScheme> <ManufacturerPartID>12345</ManufacturerPartID> <ManufacturerName>Compaq</ManufacturerName> <SearchDataElement_name>Processor Speed</SearchDataElement_name> <SearchDataElement_value>500MHZ</SearchDataElement_value> <Memory>128Mb</Memory> </rdf:description> <rdf:rdf> <unspsc_ rdf:about="armadam700" product_description="this light..." product_short_description="armada M700 PIII GB"> </unspsc_ > <Processor_Speed rdf:about="armadam700" product_attribute_name="processor Speed" product_attribute_value="500mhz"/> <Random_Access_Memory rdf:about="armadam700" product_attribute_name="ram" product_attribute_value="128mb"/> </rdf:rdf> (a) business document part and a product description part mixed in one RDF document. The business part contains document elements, which describe the role of the catalog (i.e., catalog number, validity term, catalog creator) and business description of an offer (i.e., product price, delivery terms, product manufacturer, product supplier). The product description part specifies content description of a product: the name of a content standard, product category, product attributes and their values. Accordingly, at the ontology layer, the document must be described with two separate ontologies: an ontology for a catalog as a business document and a product ontology derived from a content standard. RDF Schemas provide a language to specify the structure of RDF triples, which we use at the Data Model layer. RDF Schema [10] is a W3C standard aimed at specifying the structure of RDF data models. Hence, it is natural to use it to model the ontologies constituting the Ontology layer. A sample of two product ontologies (UN/SPSC and ecl@ss) is presented in Figure 3. A product is specified with the class product, which captures the properties of a product description present in all content. Content specify the products with product categories modeled with the classes eclass_category and unspsc_category, defined as subclasses of the class product. These two classes are abstract, i.e. a product may not be just classified according to UN/SPSC but must be assigned to a certain category, which is modeled as a subclass of the class unspsc_category. Each category may provide a set of attributes to specify the products. We model product attributes with the class product_attribute. Different types of product attributes used in different content are modeled with subclasses of the class product_attribute. The instances of (b) product description Figure 4. An RDF data model of a catalog document and correspondent product description this class are attached to the instances of a product category. This way of modeling is inspired by the use of Protégé 1 ontology editor, which does not allow definition of sub-properties. This style of modeling allows easy definition of attribute properties (human-readable attribute names with multi-lingual support, attribute values, and value restrictions). However, RDFS Schema provides more clear way to model this. It provides the rdf:property construct to model product attributes, the rdfs:subpropertyof construct to model the hierarchy of properties, the rdfs:domain construct to encode the classes (products) to which the attribute is applicable, and the rdfs:range construct to encode the type of attribute values. However, it is not clear how to encode human-readable attribute names and other attribute properties, because RDF Schema does not provide any means to define properties of rdf:properties. The ontologies must be modeled in a way suitable for reasoning services, which will be applied to perform the integration. We can either use classification engines, e.g. FACT 2, or, alternatively, rule-based inference engines, e.g. CLIPS 3. The knowledge model assumed by the engine must be taken into account while developing product ontologies. The choice of the model used to specify product ontologies is influenced by two other issues: establishing the links between catalog documents and product ontology instances, and aligning content. These two issues are discussed in the following sections. Meta-ontologies need to be introduced to facilitate further inter-standard mappings. The roles of the documents are defined in the document meta-ontology (named as the document interchange ontology in Figure

5 2). The scope and modeling primitives of the content are defined in the product meta-ontology, as also presented in the figure. It specifies whether a content standard provides product attributes, attribute types, etc. 5. Linking Documents and Content Standards Let us consider an example of content mapping. Assume that we have a fragment of an cxml product catalog represented with its RDF data model as shown in Figure 4 (a). The document contains both business part (elements SupplierPartID, Money, currency, etc.) and product description part (a link to a content standard with the elements Classification and ClassificationScheme and the values for two product attributes Processor_Speed and Memory). From the business document point of view, the model is an instance of the class cxml_catalog, which describes a business document product catalog, its roles and relation to other documents. Hence, a marketplace has to treat the catalog as an instance of a business document while performing document interchange tasks (e.g., linking it to a purchase order defined on the basis of the catalog). In this paper we do not further discuss the document integration task. From the content point of view, the catalog describes an offer of a notebook computer. Hence, its RDF model includes an instance of the class unspsc_ , which stands for notebook computers in the UN/SPSC ontology. Accordingly, a marketplace must treat the document as an instance of a product category to perform content-based product search and retrieval. However, the RDF serialization for an instance of the class unspsc_ (presented in Figure 4 (a)) may differ from the serialization recommended for the product description by the catalog standard (presented in Figure 4 (b), an instance of the rdf:resource ArmadaM700, the namespaces for class and attribute names are omitted). Hence, the RDF representation of a catalog must be translated into to the RDF representation of an ontology instance. The transformation requires mapping RDF documents (and their RDF Schemas). RDF data models are created with the most detailed granularity level possible, which is one of the main guidelines discussed in [7]. Hence, data models for catalogs can be converted to content ontology instances with simple one-to-one mappings. In the example from Figure 4 the catalog element SearchDataElement_name must be mapped to the product_attribute_name element of the ontology instance, and similarly the SearchDataElement_value element must be mapped to the product_attribute_value element. 6. Aligning Content Standards To reclassify the products a B2B marketplace must align horizontal, link horizontal to vertical, and align vertical. These mappings depend on the business roles of the and certain organizational requirements. Horizontal provide general hierarchies of products, and we can expect many equivalence mappings to appear between them. Sometimes a content standard providers publish these mappings as a part of the standard. For example, UN/SPSC provides direct one-to-one mapping between UN/SPSC and other horizontal : CPV, NAICS, and SIC 1. Despite these published mappings, a number of problems arise in aligning horizontal : Only few horizontal have officially published mappings, and most of the are not related one to each other. The significantly differ in their classifications because of the absence of a consensus scheme for classifying all products. The differ in the granularity level in the classifications of each particular group of products. Hence, very often the published mappings mark as equivalent pairs of concepts with different generality level. Equivalence of the categories is not evident from their descriptions, e.g. NAICS 2 code [39] Miscellaneous Manufacturing Industries is mapped to the UN/SPSC code [73] Industrial Production and Manufacturing Services. An example of aligning two horizontal is shown in Figure 5. Linking vertical and horizontal differs from the previous case. A vertical standard provides a deep and narrow classification opposite to wide and shallow horizontal. Normally a vertical standard expands one or few nodes of a horizontal standard. For example, consider mapping the RosettaNet standard to UN/SPSC 3. The mapping includes only 136 UN/SPSC categories out of more than 12,000, most of which belong to the bottom level in the UN/SPSC hierarchy. These 136 categories are mapped to 445 categories and 2660 attributes of RosettaNet. Vertical are very precise in describing the items they are focused. The same time they are even shallower than horizontal in describing the things, which lay beyond their focus Available at in the section Standards/Product & Partner Codes/UNSPSC Mapping Documents.

6 Rollerball pens are subclassed in UN/SPSC in the following way: [44] Office Equipment and Accessories and Supplies [4412] Office supplies [441217] Writing instruments [ ] Rollerball pens [ ] Pen or pencil sets [ ] Felt pen classifies rollerball pens as Writing material follows: [24] Communication technology [24-11] Office Supplies [ ] Writing and drawing materials [ ] Writing material [ ] Drawing material Figure 5. An example of aligning two horizontal Aligning vertical and horizontal requires: Mapping a relatively small number of top-level vertical concepts with more general concepts of a horizontal standard. Mapping the concepts, which are outside the focus of a vertical standard to the correspondent concepts in a horizontal standard. In this case, the vertical concepts may have the same granularity level as the horizontal concepts. This linking is simpler than horizontal aligning and it has an evident top-down structure. Hence, it can be technologically treated as a light version of the horizontal mapping and it can be performed with the same technologies. Aligning vertical requires linking their categories in a similar way as it is done for horizontal. In addition, vertical have an extensive set of attributes, which can be even larger than the set of classes (e.g., the RosettaNet case). Each attribute can be represented with: Attribute name, e.g. Screen size. Name abbreviation, e.g. ScreenSize, which is a valid identifier produced from the attribute name. Attribute value type (e.g. string, integer, float, etc.). The type may be an enumerated type represented with a list of possible attribute values, e.g. the currency type actually contains a list of possible currencies. Attribute value format, which defines the way to interpret the attribute value. For example, YYYY- MM-DD denotes that the date is represented in a year-month-day format, e.g The scale for the values, e.g. m stands for meters as a length measure. Attribute domain(s), or the set of categories to which the attribute can be applied. Hence, aligning vertical requires: Mapping attribute names and attribute abbreviations. Transforming attribute types, e.g. transforming an integer value into a corresponding string representation. Mapping lists of possible attribute values for enumerated types. Mapping different value display formats. Transforming unit scales, e.g. translation of the length in meters into the length in feet. Mapping attribute domains: the list of the categories from the source standard, to which the attribute applies, must be translated into the list of the categories from the target standard. This translation exploits previously defined mappings of the categories. These requirements need to be satisfied by means of ontology mapping techniques (cf. [11] for an overview of the field). 7. Conclusions The B2B content integration task requires intensive use of RDF techniques, especially for information storage and querying. However, the only RDF(S) query tool known to the authors, Sesame 1, is capable in providing an interface between a B2B content integration tool and RDF(S) knowledge base. Still, the expressive power of the query language RQL [12] used in the tool, is not sufficient to perform all necessary content integration operations. Some of them must be implemented with additional RDFbased tools, which still have to be developed. Further B2B ontology integration framework must be based on current achievements in the ontology integration area [11]. Similar problems have been existed in the databases community [13] and a number of schema transformation techniques applicable to the ontology integration problem have been proposed (cf. [14], [15]). Acknowledgement The author would like to thank Dieter Fensel and Michel Klein for their helpful discussions and comments. 1

7 References [1] Fensel, D., Ontologies: Silver Bullet for Knowledge Management and Electronic Commerce, Berlin, Springer-Verlag, [2] U.S.Department of Commerce, "Digital Economy 2000" White Paper, [3] Omelayenko, B. and Fensel, D., "An Analysis of B2B Catalogue Integration problems: Content and Document Integration", In: Proceedings of the International Conference on Enterprise Information Systems (ICEIS-2001), Setúbal, Portugal, July 7-10, [ [4] Jung, J., Kim, D., Lee, S., Wu, C., and Kim, K., "EE-Cat: Extended Electronic Catalog for Dynamic and Flexible Electronic Commerce", In: Khosrowpour, M. (ed.), Proceedings of the IRMA International Conference, IDEA Group Publishing, Anchorage, Alaska, May 21-24, 2000, pp [5] Corcho, O. and Gomez-Perez, A., "Solving Integration Problems of E-commerce Standards and Initiatives through Ontological Mappings", In: Proceedings of the Workshop on E-Business and Intelligent Web at the Seventeenth International Joint Conference on Artificial Intelligence (IJCAI- 2001), Seattle, USA, August 5, [6] Angele, J. and Erdmann, M., "B 3 Semantic B2B Broker", White paper by Ontoprise GmbH, [ [7] Omelayenko, B. and Fensel, D., "A Two-Layered Integration Approach for Product Information in B2B E-commerce", In: Proceedings of the Second International Conference on Electronic Commerce and Web Technologies (EC WEB-2001), Munich, Germany, September 4-6, [ [8] Omelayenko, B. and Fensel, D., "An Analysis of Integration Problems of XML-Based Catalogs for B2B Electronic Commerce", In: Proceedings of the Ninth IFIP 2.6 Working Conference on Database Semantics, Kluwer Academic, Hong Kong, April 25-28, 2001, pp [ [9] Lassila, O. and Swick, R., "Resource Description Framework (RDF) Model and Syntax Specification", W3C Recommendation, [ [10] Brickley, D. and Guha, R., "Resource Description Framework (RDF) Schema Specification 1.0", W3C Candidate Recommendation, [ [11] Klein, M., "Combining and relating ontologies: an analysis of problems and solutions", In: Gomez- Perez, A., Gruninger, M., Stuckenschmidt, H., and Uschold, M. (eds.), Proceedings of the Workshop on Ontologies and Information Sharing at the Seventeenth International Joint Conference on Artificial Intelligence (IJCAI-2001), Seattle, USA, August 5, [ [12] Broekstra, J., Fluit, C., and van Harmelen, F., "The State of the Art on Representation and Query Languages for Semistructured Data", IST On-To-Knowledge Project Deliverable 8, [ [13] Hull, R., "Managing Semantic Heterogeneity in Databases: A Theoretical Perspective", In: Proceedings of the Sixteenth ACM SIGACT- SIGMOD-SIGART Symposium on Principles of Database Systems (ACM PODS-1997), ACM Press, Tucson, Arizona, May 12-14, 1997, pp [14] Chang, C. K. and Garcia-Molina, H., "Approximate Query Translation Across Heterogeneous Information Sources", In: Proceedings of 26th International Conference on Very Large Data Bases (VLDB-2000), Morgan Kaufmann, Cairo, Egypt, September 10-14, 2000, pp [15] Abiteboul, S., Cluet, S., and Milo, T., "Correspondence and Translation for Heterogeneous Data", Verso report 191, 2001.