Semantic Support for Electronic Business Document Interoperability Asuman

Semantic Support for Electronic Business Document Interoperability Asuman Dogac, Yalin Yarimagan, Yildiray Kabak Middle East Technical University and Software Research, Development and Consultancy Ltd. Ankara, Turkey This work is supported by the European Commission through the ICT 213031 i. SURF Project: http: //www. i. SURFProject. eu March 6, 2008 Ontolog Forum Presentation A. Dogac, Y. Yarimagan, Y. Kabak 1

The Motivation of this work… n The European Commission’s “Enterprise Interoperability Research Roadmap” foresees a “Interoperability Service Utility (ISU)” q “Interoperability as a utility-like capability needs to be supported by an enabling system of services for delivering basic interoperability to enterprises, independent of particular IT deployment” q http: //cordis. europa. eu/ist/ict-ent-net/ei-roadmap_en. htm n A very important component of “Interoperability Service Utility” is the interoperability of the business document instances exchanged through the service utility This work is being realized within the scope of the ICT 213031 i. SURF Project q http: //www. i. SURFProject. eu n March 6, 2008 Ontolog Forum Presentation A. Dogac, Y. Yarimagan, Y. Kabak 2

Talk Outline n n n A Brief Overview of Electronic Business Document Standards UN/CEFACT Core Component Technical Specification Semantic Tools for Interoperability Support q q q n March 6, 2008 Use of Ontologies for Semantic Annotation and Ontology Alignment Document Translation System Architecture and Operation Conclusions Ontolog Forum Presentation A. Dogac, Y. Yarimagan, Y. Kabak 3

Development of Electronic Business Document Interoperability Standards n The development of electronic business document standards has been evolutionary based on: q q q n The traditional EDI technology Affected by the technological developments such as the Internet and XML Affected by the interoperability needs of the current more dynamic e. Business applications No document standard is sufficient for all purposes because the requirements significantly differ q Amongst businesses, industries and geo-political regions March 6, 2008 Ontolog Forum Presentation A. Dogac, Y. Yarimagan, Y. Kabak 4

Some Example Business Document Standards n n Vertical Standards q Rosetta. Net, CIDX, PIDX, OTA, HL 7, … Horizontal Standards q OAGIS, GS 1 e. Com, x. CBL, c. XML, UN/CEFACT CCL, UBL, … A survey and analysis of electronic business document standards investigating: q The document design principles q The use of code lists q The use of XML namespaces q How the standards handle extensibility and customization is available at: q Kabak Y. , Dogac A. , “A Survey and Analysis of Electronic Business Document Standards”, Submitted to ACM Computing Surveys n http: //www. srdc. metu. edu. tr/webpage/publications March 6, 2008 Ontolog Forum Presentation A. Dogac, Y. Yarimagan, Y. Kabak 5

UN/CEFACT Core Component Technical Specification (CCTS) n The ultimate aim of business document interoperability is to q q Exchange business data among partners without any prior agreements related to the document syntax and semantics Hence support “Interoperability Service Utility (ISU)” at the content level n Therefore, document standard need to adapt to different contexts, be extensible and customizable n UN/CEFACT Core Component Technical Specification (CCTS) is an important landmark in this direction March 6, 2008 Ontolog Forum Presentation A. Dogac, Y. Yarimagan, Y. Kabak 6

Talk Outline n n n A Brief Overview of Electronic Business Document Standards UN/CEFACT Core Component Technical Specification Semantic Tools for Interoperability Support q q q n March 6, 2008 Use of Ontologies for Semantic Annotation and Ontology Alignment Document Translation System Architecture and Operation Conclusions Ontolog Forum Presentation A. Dogac, Y. Yarimagan, Y. Kabak 7

UN/CEFACT Core Component Technical Specification (CCTS) n UN/CEFACT CCTS provides a methodology to identify a set of reusable building blocks, called Core Components to create electronic documents n Core Components represent the common data elements of everyday business documents such as “Address”, “Amount”, or “Line Item” n These reusable building blocks are then assembled into business documents such as “Order” or “Invoice” by using the CCTS methodology n UN/CEFACT CCTS Core Components are syntax independent March 6, 2008 Ontolog Forum Presentation A. Dogac, Y. Yarimagan, Y. Kabak 8

UN/CEFACT Core Component Technical Specification (CCTS) n Core components are defined to be contextindependent so that they can later be restricted to different contexts: q q q q Business Process Context Product Classication Context Industry Classication Context Geopolitical Context Business Process Role Context Supporting Role Context System Capabilities Context Official Constraints Context March 6, 2008 Ontolog Forum Presentation A. Dogac, Y. Yarimagan, Y. Kabak 9

Main Features of CCTS Approach n Business document schemas are composed of several basic and aggregate components n Aggregate components themselves are collections of other basic and aggregate components in a recursive manner n Standard components are modified in response to contexual needs n When a document schema needs to be customized for a context, users need to discover or provide component versions applicable to that particular context March 6, 2008 Ontolog Forum Presentation A. Dogac, Y. Yarimagan, Y. Kabak 10

Why CCTS is important? n This concept of defining context-free reusable building blocks, which are available from a single common repository, is an important innovation: q The incompatibility in electronic documents is incremental rather than wholesale q The users are expected to model their business documents by using the existing core components and by restricting them to their context with well defined rules q Dynamic creation of interoperable documents becomes possible because if users cannot find proper components to model their documents, they can create and publish new core components q The horizontal interoperability among different industries is greatly facilitated by using a single common repository and by customizing the components to different industry contexts March 6, 2008 Ontolog Forum Presentation A. Dogac, Y. Yarimagan, Y. Kabak 11

Some of the UN/CEFACT CCTS based Business Document Standards n UN/CEFACT Core Components Library (CCL) 07 A q q q 96 ACC, 212 ASCC, 636 BCC 184 ABIE, 337 ASBIE, 1011 BBIE 35 Datatypes n Universal Business Language (UBL) 2. 0 n Open Applications Group Integration Specification (OAGIS) 9. 0 n Global Standards One (GS 1) XML n All standards implement CCTS differently! March 6, 2008 Ontolog Forum Presentation A. Dogac, Y. Yarimagan, Y. Kabak 12

UN/CEFACT Core Components Library (CCL) 07 A March 6, 2008 Ontolog Forum Presentation A. Dogac, Y. Yarimagan, Y. Kabak 13

OASIS Universal Business Language (UBL) 2. 0 n The first implementation of UN/CEFACT CCTS in XML n 31 Horizontal Business Document Schemas q n Invoice, Order, Dispatch Advice, … Schemas for common reusable entities q Amount, Payment, Item, … March 6, 2008 Ontolog Forum Presentation A. Dogac, Y. Yarimagan, Y. Kabak 14

The Problem continues: All CCTS based standards use CCTS differently March 6, 2008 Ontolog Forum Presentation A. Dogac, Y. Yarimagan, Y. Kabak 15

How to provide interoperability among electronic business document Harmonization: standards? The International Electrotechnical Commission (IEC), n q q The International Organization for Standardization (ISO), The International Telecommunication Union (ITU) and, The United Nations Economic Commission for Europe (UNECE) signed a “Memorandum of Understanding” to specify a framework of cooperation n Up to now, OAGIS 9. 0 and UBL 2. 0 have achieved a level of harmonization: they are based on the same UN/CEFACT Unqualified Datatypes and Core Component Types n However, the harmonization needs to be extended to the upper level artifacts n An alternative: Providing semantic tool support for the interoperability of electronic business documents March 6, 2008 Ontolog Forum Presentation A. Dogac, Y. Yarimagan, Y. Kabak 16

Providing semantic support for the interoperability of CCTS based electronic business documents n Within the scope of the i. SURF Project, we developed tools: q q q To provide machine processable semantic representations of context domains To utilize these semantics for automating tasks for the discovery, reuse and customization of components and document schemas To provide a semantics based translation mechanism for the interoperability of schemas customized by independent parties March 6, 2008 Ontolog Forum Presentation A. Dogac, Y. Yarimagan, Y. Kabak 17

Talk Outline n n n A Brief Overview of Electronic Business Document Standards UN/CEFACT Core Component Technical Specification Semantic Tools for Interoperability Support q q q n March 6, 2008 Use of Ontologies for Semantic Annotation and Ontology Alignment Document Translation System Architecture and Operation Conclusions Ontolog Forum Presentation A. Dogac, Y. Yarimagan, Y. Kabak 18

The Motivation: Context Categories n n n Eight categories has been defined for the business context Specific code lists and classification schemas are suggested for each category: q Code lists and classification taxonomies provide context values q There are other relevant classifications in use today and there may be others in future Quoting from an email in the Ontolog Forum by Duane Nickull: q “Even when the CCTS group decided to limit their context qualifier set to only 8 context aspects, they still had an almost infinite explosion of context. If you took 8 singular contexts and had only 300 enumerated values for each one, the number is so large no one group could ever possibly list all the combinations in a lifetime without computers” March 6, 2008 Ontolog Forum Presentation A. Dogac, Y. Yarimagan, Y. Kabak 19

Context Ontologies n We developed Web Ontology Language (OWL) ontologies to represent taxonomy of these classifications: q q q They become machine processable It becomes possible to formally specify relationships between different classifications Specified relationships are interpreted by reasoners to compute additional relationships March 6, 2008 Ontolog Forum Presentation A. Dogac, Y. Yarimagan, Y. Kabak 20

Context Ontologies North American Indusrty Classification System (NAICS) 23 Construction 236 Construction of Buildings <? xml version="1. 0"? > <rdf: RDF 2361 Residential Building Construction <owl: Ontology rdf: about="NAICS Ontology"/> 2362 Nonresidential Building Construction 238 Specialty Trade Contractors <owl: Class rdf: ID="_23_Construction" /> 2381 Foundation, Structure, and Building Exterior Contractors 2382 Building Equipment Contractors <owl: Class rdf: ID="_236_Construction_of_Buildings"> 2383 Building Finishing Contractors <rdfs: sub. Class. Of rdf: resource="#_23_Construction" /> </owl: Class> naics: 23_ <owl: Class rdf: ID="_2361_Residential_Building_Construction"> Construction <rdfs: sub. Class. Of rdf: resource="#_236_Construction_of_Buildings"/> </owl: Class> naics: 238_ <owl: Class rdf: ID="_2362_Nonresidential_Building_Construction"> naics: 236_ Specialty_Trade_ <rdfs: sub. Class. Of rdf: resource="#_236_Construction_of_Buildings"/> Construction_ Contractors </owl: Class> of_Buildings </rdf: RDF> naics: 2361_ Residential_Building _Construction March 6, 2008 naics: 2362_ Nonresidential_ Building_Construction naics: 2381_Foundation _Structure_Exterior_ Contractors Ontolog Forum Presentation A. Dogac, Y. Yarimagan, Y. Kabak naics: 2382_ Building_Equipment _Contractors naics: 2383_ Building_Finishing Contractors 21

Context Based Customization A Core Component geo=“US” geo=“Japan” US Japan Core Component geo=“US-CA” geo=“Japan”, product=“shoe” California Japan Shoe Core Component geo=“US-CA”, product=“shoe” California Shoe Core Component March 6, 2008 Ontolog Forum Presentation A. Dogac, Y. Yarimagan, Y. Kabak 22

Influence of Custom Components n Custom components are applicable for the context hierarchy they are defined for Item Product Classification Defense, Law Enforcement & Security Equipment Computer Equipment & Peripherals Telecommunication Equipment Item Software Database Software March 6, 2008 Multimedia Software Networking Software Ontolog Forum Presentation A. Dogac, Y. Yarimagan, Y. Kabak Hardware Computers Storage Devices Display Devices 23

Context Ontologies n We developed a tool to convert classifications to context ontologies in OWL representation: q Geopolitical context n M 49, ISO-3166 q Industrial Classification context n NAICS, NACE, ISIC q Product Classification context n CPC, UNSPSC n These context ontology classes are then used to annotate customized document components n Note: This is in addition to defining element values through code lists March 6, 2008 Ontolog Forum Presentation A. Dogac, Y. Yarimagan, Y. Kabak 24

Talk Outline n n n A Brief Overview of Electronic Business Document Standards UN/CEFACT Core Component Technical Specification Semantic Tools for Interoperability Support q q q n March 6, 2008 Use of Ontologies for Semantic Annotation and Ontology Alignment Document Translation System Architecture and Operation Conclusions Ontolog Forum Presentation A. Dogac, Y. Yarimagan, Y. Kabak 25

Annotating Components with Context Ontologies Item NAICS 33 - Manufacturing 336 - Transportation Equipment Manufacturing 3364 - Aerospace Product and Parts Manufacturing When a component “item” is defined for the “Manufacturing” context, it becomes applicable to all subclasses in the context ontology 336411 – Aircraft Manufacturing March 6, 2008 Ontolog Forum Presentation A. Dogac, Y. Yarimagan, Y. Kabak 26

Influence of Aligned Ontologies on Component Discovery and Reuse Item NAICS 33 - Manufacturing Item ISIC C - Manufacturing 336 - Transportation Equipment Manufacturing 3364 - Aerospace Product and Parts Manufacturing C-30 - Manufacture of other transport equipment C-303 - Manufacture of air and spacecraft and related machinery 336411 – Aircraft Manufacturing March 6, 2008 Ontolog Forum Presentation A. Dogac, Y. Yarimagan, Y. Kabak 27

Generating Context Ontologies ISIC Classification owl ISIC ontology NAICS Classification owl NAICS ontology NACE Classification owl NACE ontology March 6, 2008 alignment Industrial Classification Context Ontology Ontolog Forum Presentation A. Dogac, Y. Yarimagan, Y. Kabak reasoning Inferred Industrial Classification Context Ontology 28

Aligning Context Ontologies n n n A joint ontology is generated for each context category q Imports all ontologies relevant to that particular category q Allows additional ontologies to be added without effecting existing ones q Allows specification of correspondences between different ontologies Ontology alignment is to be assumed by domain experts and standard issuing bodies Our work focuses on how such correspondences can be exploited once they are specified March 6, 2008 Ontolog Forum Presentation A. Dogac, Y. Yarimagan, Y. Kabak 29

Aligning Context Ontologies n Any OWL construct can be utilized including but not limited to: q Equivalence (A B) n q Composition (A B C) n q NACE: 45 -Construction, NAICS: 23 -Construction NAICS: 11 -Agriculture, Forestry, Fishing and Hunting, ISIC: A-Agriculture, Hunting and Forestry, ISIC: B-Fishing Subsumption (A B) n March 6, 2008 NACE: CA-Mining and Quarrying of Energy Producing Materials, NAICS: 211 -Oil and Gas Extraction Ontolog Forum Presentation A. Dogac, Y. Yarimagan, Y. Kabak 30

Ontology Alignment Operations A B X C Y A A C Y B Z X C, Y A X Z X (B C) Y Y B C Y Z B A B March 6, 2008 X C Y Z A C Y Z Ontolog Forum Presentation A. Dogac, Y. Yarimagan, Y. Kabak C X B Y C Z 31

How to Annotate Components with Context Ontology: Component When a component is customized for a context, its metadata is Metadata created: n q q To express the standard component it is derived from, and The context it is applicable to by specifying references to classes from ontologies n When a custom version of a component is required for a specific context: q Component metadata is queried to gather applicable versions with the help of inferred context ontologies n When a document schema needs to be customized for a specific context, component metadata is queried q To gather custom versions of components included in that schema and q Those versions are used to replace the original components in the customized document Ontolog Forum schema Presentation March 6, 2008 A. Dogac, Y. Yarimagan, Y. Kabak 32

Component Metadata owl: Thing Datatype. Property: element xsd: String Datatype. Property: type. Def Datatype. Property: component. URI UBL Component Metadata Object. Property: sub. Class. Of Object. Property: applicable. Context xsd: boolean Object. Property: original. Component Custom Component Metadata Datatype. Property: is. Extension. Component <UBLComponent. Metadata rdf: ID="cac_Item"> <element rdf: datatype=”string”>urn: oasis: names: specification: ubl: schema: xsd: Common. Aggregate. Components-2: Item</> <type. Def rdf: datatype=”string”>urn: oasis: names: specification: ubl: schema: xsd: Common. Aggregate. Components-2: Item. Type</> <component. URI rdf: datatype="string">http: //www. srdc. metu. edu. tr/ublschema/common/UBL-Common. Aggregate. Components-2. 0. xsd</> </UBLComponent. Metadata> <Custom. Component. Metadata rdf: ID="Item-industry_naics_23_cnstrctn"> <element rdf: datatype="string">srdc: industry: naics: _23_cnstrctn: ubl: Item</> <type. Def rdf: datatype="string">srdc: industry: naics: _23_cnstrctn: ubl: Item. Type</> <component. URI rdf: datatype="string">http: //srdc. metu. edu. tr/custom. Schema. Repository/industry_naics__23_cnstrctn. xsd</> <applicable. Context rdf: resource="string">http: //srdc. metu. edu. tr/context. Ontology/naics. owl#_23_Construction</> <is. Extension. Component rdf: datatype="boolean">false</> <original. Component rdf: resource=http: //srdc. metu. edu. tr/component. Repository/ubl. Instances. owl#cac_Item</> </Custom. Component. Metadata> March 6, 2008 Ontolog Forum Presentation A. Dogac, Y. Yarimagan, Y. Kabak 33

Component Discovery Service Product Classification Context owl: Thing unspsc: 51 Drugs and Pharmaceutical Products Industrial Classification Context Validity Period. D owl: Thing Item. M naics: 32 Manufacturing unspsc: 5110 Antiinfective drugs unspsc: 511015 Antibiotics unspsc: 5112 Cardiovascular Drugs naics: 322 Paper Manufacturing Item. A Item for Antibiotics context? naics: 325 Chemical Manufacturing Item. A Item for Cardiovascular drugs context? Item. UBL Validity Period for Antibiotics context? Validity. Period. D Item for Antibiotics Manufacturing context? Item. A+M March 6, 2008 Ontolog Forum Presentation A. Dogac, Y. Yarimagan, Y. Kabak 34

Component Discovery and Merging C 1 A B C A B D (1) 2. 3. C C 3 A D C 1 UBL 1. C 2 B C D C 2 + C 3 (2) (3) If there are no customized components in the parent classes, the original standard component is used If there is a customized component applicable to a parent context, for example, for class B, say “C 1”, this version is applicable to context class D If there are customized components applicable to multiple parent context classes, for example, “C 2” for class “A” and “C 3” for class “C”, the context applicable to class “D”, is generated by merging the components “C 2” and “C 3” March 6, 2008 Ontolog Forum Presentation A. Dogac, Y. Yarimagan, Y. Kabak 35

Component Discovery and Merging n Similarly, for the context class J, the components "C 1", "C 2", and "C 3" must be merged C 2 C 1 A B G C D H C 1 C 3 E F I C 2+C 3 J C 1+C 2+C 3 March 6, 2008 Ontolog Forum Presentation A. Dogac, Y. Yarimagan, Y. Kabak 36

Document Schema Customization Service n n n Assume we wish to customize a “catalogue” to “Antibiotic Manufacturing” Assume the customized components “Validity. Period. D”, “item. A” and “item. M” are annotated using respective context ontology classes The Customized “catalogue” contains the components “Validity. Period. D”, and a merged version of “item. A” and “item. M” Antibiotic Manufacturing catalogue name issue. Date validity. Period quantity name catalogue. Line base. Price catalogue issue. Date validity. Period. D quantity item base. Price catalogue. Line item. A + item. M owl: Thing unspsc: 51_Drugs_and_ Pharmaceutical_Products owl: Thing Validity Period. D Item. M naics: Manufacturing unspsc: 5110_ Antiinfective_drugs unspsc: 5112_ Cardiovascular_drugs naics: Transportation_ Equipment_Manufacturing unspsc: 511015_ Antibiotics March 6, 2008 isic: Manufacturing Item. A Ontolog Forum Presentation A. Dogac, Y. Yarimagan, Y. Kabak isic: Manufacture_ of_Other_Transport_ Equipment 37

Component Merge Service n Given multiple custom versions of a component, generates a combined version q q n Derivation operations (extensions and restrictions) are extracted from individual versions Extracted derivations are successively added to the base version Resulting component is a valid specialization of all versions in terms of UBL validation March 6, 2008 Ontolog Forum Presentation A. Dogac, Y. Yarimagan, Y. Kabak 38

Component Merge Service Original Component Custom Component 1 Description [0. . 1] Item Custom Component 2 Description [0. . 1] Item Brand. Name [0. . ] Brand. Name [1. . ] Brand. Name [0. . 5] Origin. Country [0. . 1] Origin. Country [0. . 0] Origin. Country [0. . 1] ID [0. . 1] Brand. Name [1. . ] Origin. Country [0. . 0] Brand. Name [0. . 5] ID [0. . 1] Merged Component Description [0. . 1] Item Brand. Name [1. . ] Brand. Name[0. . ] [1. . 5] Brand. Name [1. . ] Origin. Country [0. . 0] Brand. Name [0. . 5] ID [0. . 1] Origin. Country [0. . 1] [0. . 0] ID [0. . 1] March 6, 2008 Ontolog Forum Presentation A. Dogac, Y. Yarimagan, Y. Kabak 39

Eliminating Redundancy n Merging extension operations may cause redundancy in merged component q q n Custom versions may contain the same extension Custom versions may contain structurally different yet semantically similar extensions UBL Component Ontology is (to be described later in the talk) utilized to discover semantic redundancy q q In case of equivalent extensions, only one extension is added to the merged component In case of subsuming extensions, only the extension corresponding to the child class is added March 6, 2008 Ontolog Forum Presentation A. Dogac, Y. Yarimagan, Y. Kabak 40

Eliminating Redundancy n Assume (2) and (3) are merged to yield (4): there is redundancy Contact ID Tel Contact Address ID Tel First. Name Contact Address ID Person Age Last. Name Tel Middle. Name First. Name (2) n Address Last. Name Individual Age Gender (3) This redundancy is automatically eliminated Contact Person First. Name ID Last. Name Tel Address Age First. Name Individual Middle. Name Last. Name Age Gender (4) March 6, 2008 Ontolog Forum Presentation A. Dogac, Y. Yarimagan, Y. Kabak 41

Talk Outline n n n A Brief Overview of Electronic Business Document Standards UN/CEFACT Core Component Technical Specification Semantic Tools for Interoperability Support q q q n March 6, 2008 Use of Ontologies for Semantic Annotation and Ontology Alignment Document Translation System Architecture and Operation Conclusions Ontolog Forum Presentation A. Dogac, Y. Yarimagan, Y. Kabak 42

Motivation: Need for Semantic Interoperability n n Businesses operate in different contexts mandating different rules and regulations for their operations Improved customization mechanisms have the potential to encourage more users for tailoring schemas for their needs As more users adopt customized schemas, it becomes harder to maintain interoperability among the UBL Community A mechanism is required to support interoperability: q q Individual communities should be free to adopt schemas that best suit their specific needs Members of different communities should not need to know each others’ schemas in order to make business March 6, 2008 Ontolog Forum Presentation A. Dogac, Y. Yarimagan, Y. Kabak 43

UBL Communities Retailers Context Manufacturing Context Manufacturer 1 Translatio n Manufacturer 2 Retailer 1 Retailer 2 Tr a io lat s an Tr n ns n latio Gov. Agency 1 Government Context March 6, 2008 Gov. Agency 2 Ontolog Forum Presentation A. Dogac, Y. Yarimagan, Y. Kabak 44

Semantic Translation Mechanism n n A semantic translation mechanism is developed This mechanism is based on a UBL Component Ontology which represents structure and semantics of components Component Ontology is processed by reasoners to compute further relationships between components These relationships are interpreted to adapt document content between different schemas March 6, 2008 Ontolog Forum Presentation A. Dogac, Y. Yarimagan, Y. Kabak 45

UBL Components <xsd: element name="Order" type="Order. Type" /> <xsd: complex. Type name="Order. Type"> <xsd: sequence> <xsd: element ref="Issue. Date" /> <xsd: element ref="Buyer" /> <xsd: element ref="Seller. Party" /> <xsd: element ref=“Order. Line" /> </xsd: sequence> </xsd: complex. Type> Order Issue. Date Buyer First. Name Seller. Party Family. Name Order. Line <xsd: element name=“Family. Name" type=“Family. Name. Type" /> <xsd: complex. Type name="Family. Name. Type"> <xsd: simple. Content> <xsd: extension base="udt: Name. Type"/> </xsd: simple. Content> </xsd: complex. Type> March 6, 2008 Ontolog Forum Presentation A. Dogac, Y. Yarimagan, Y. Kabak 46

UBL Component Ontology Simple data. Aggregate types such. Type as Text. Type and Name. Type Basic and Definitions such as Delivery. Address, Family. Name. Type, Element Declarations such as Postal. Address, Business concepts such as Postal. Address. Concept, Delivery. Address. Concept, Address. Type, Catalogue. Type defining the structure of UBL Components Registration. Address specifying actual UBL components specifying concepts represented by UBL components Aggregate Type refer. Element Concept is. A Data Type is. A extend. Basic. Type March 6, 2008 Basic Type Definition Element Declaration represent. Concept is. Of. Type Ontolog Forum Presentation A. Dogac, Y. Yarimagan, Y. Kabak 47

UBL Component Ontology n n Classes are defined in terms of relations with other classes Existential restriction construct of OWL is used to specify those relations q a. Basic. Type ≡ (Basic. Type ( extend. Basic. Type. a. Data. Type)) q an. Aggregate. Type ≡ (Aggregate. Type ( refer. Element. (an. Element 1 . . an. Elementn))) an. Element ≡ (Element. Declaration represent. Concept. a. Concept is. Of. Type. a. Type) q March 6, 2008 Ontolog Forum Presentation A. Dogac, Y. Yarimagan, Y. Kabak 48

UBL Component Ontology Order. Type ≡ (Aggregate. Type ( refer. Element. (Issue. Date Buyer Seller. Party Order. Line))) Any Aggregate. Type that has refer. Element relationship with Issue. Date and Buyer and Seller. Party and Order. Line is an Order. Type Order ≡ (Element. Declaration represent. Concept. Order. Concept is. Of. Type. Order. Type) Any Element. Declaration that has a represent. Concept relationship with Order. Concept and is. Of. Type relationship with Order. Type is an Order Issue. Date Buyer First. Name Seller. Party Order. Line Family. Name. Type ≡ (Basic. Type ( extend. Basic. Type. udt: Name. Type)) Any Basic. Type that has an extend. Basic. Type relationship with udt: Name. Type is a Family. Name. Type March 6, 2008 Ontolog Forum Presentation A. Dogac, Y. Yarimagan, Y. Kabak 49

Computing Translations Order Issue. Date First. Name n n Buyer Custom. Order Seller. Party Family. Name Order. Line Issue. Date Name Customer Seller. Party Order. Line Surname For a human being, the similarity between Order and Custom. Order is obvious Component Ontology expressions describe components in a machine processable manner so that automated processes can compute the relationship between Order and Custom. Order March 6, 2008 Ontolog Forum Presentation A. Dogac, Y. Yarimagan, Y. Kabak 50

Computing Translations Custom. Order Issue. Date Buyer Seller. Party Customer Name First. Name Seller. Party Order. Line Surname Family. Name 1. Order ≡ (Element. Declaration ( represent. Concept. Order. Concept) ( is. Of. Type. Order. Type)) 2. Order. Type ≡ (Aggregate. Type ( refer. Element. (Issue. Date Buyer Seller. Party Order. Line))) 3. Buyer ≡ (Element. Declaration ( represent. Concept. Buyer. Concept) ( is. Of. Type. Person. Type)) 4. Person. Type ≡ (Aggregate. Type ( refer. Element. (First. Name Family. Name))) 5. First. Name ≡ (Element. Declaration ( represent. Concept. First. Name. Concept) ( is. Of. Type. First. Name. Type)) 6. First. Name. Type ≡ (Basic. Type ( extend. Text. Type)) 7. Family. Name ≡ (Element. Declaration ( represent. Concept. Family. Name. Concept) ( is. Of. Type. Family. Name. Type)) 8. Family. Name. Type ≡ (Basic. Type ( extend. Text. Type)) 9. Custom. Order ≡ (Element. Declaration ( represent. Concept. Order. Concept) ( is. Of. Type. Custom. Order. Type)) 10. Custom. Order. Type ≡ (Aggregate. Type ( refer. Element. (Issue. Date Customer Seller. Party Order. Line))) 11. Customer ≡ (Element. Declaration ( represent. Concept. Buyer. Concept) ( is. Of. Type. Custom. Person. Type)) 12. Custom. Person. Type ≡ (Aggregate. Type ( refer. Element. (Name Surname))) 13. Name ≡ (Element. Declaration ( represent. Concept. First. Name. Concept) ( is. Of. Type. Name. Type)) 14. Name. Type ≡ (Basic. Type ( extend. Text. Type)) 15. Surname ≡ (Element. Declaration ( represent. Concept. Family. Name. Concept) ( is. Of. Type. Surname. Type)) 16. Surname. Type ≡ (Basic. Type ( extend. Text. Type)) 17. First. Name. Type ≡ Name. Type (6 and 14) 18. First. Name ≡ Name (5, 13 and 17) 19. Family. Name. Type ≡ Surname. Type (8 and 16) 20. Family. Name ≡ Surname (7, 15 and 19) 21. Person. Type ≡ Custom. Person. Type (4, 12, 18 and 20) 22. Buyer ≡ Customer (3, 11 and 21) 23. Order. Type ≡ Custom. Order. Type (2, 10 and 22) 24. Order ≡ Custom. Order (1, 9 and 23) March 6, 2008 Ontolog Forum Presentation A. Dogac, Y. Yarimagan, Y. Kabak 51

Translatability n Equivalence relationship between Component Ontology classes is an indication of structural and semantic similarity between corresponding components q It is possible to translate content between such components n Class-subclass relationship between Component Ontology classes is an indication that corresponding components are semantically similar and structurally subsuming q It is possible to translate all content from subsuming component to the other, but some of the content cannot be translated back March 6, 2008 Ontolog Forum Presentation A. Dogac, Y. Yarimagan, Y. Kabak 52

Talk Outline n n n A Brief Overview of Electronic Business Document Standards UN/CEFACT Core Component Technical Specification Semantic Tools for Interoperability Support q q q n March 6, 2008 Use of Ontologies for Semantic Annotation and Ontology Alignment Document Translation System Architecture and Operation Conclusions Ontolog Forum Presentation A. Dogac, Y. Yarimagan, Y. Kabak 53

System Architecture User Tools Context Ontology Registration Tool Extension Component Definition Tool Component Customization Tool Document Schema Customization Tool Document Translation Tool Document Schema Customization Service Component Merge Service Document Translation Service Layer Component Registry Service Component Discovery Service Reasoning Layer Knowledge Base Context Ontology Metadata March 6, 2008 Component Metadata UBL Component Ontology Ontolog Forum Presentation A. Dogac, Y. Yarimagan, Y. Kabak Component Repository 54

Component Registry Service n Component Registry Service maintains knowledge base constructs: q q q Component Repository: XSD definitions for standard, custom and extension components Component Metadata: Metadata definitions in OWL to facilitate component discovery Component Ontology: DL definitions in OWL that support translatability computations March 6, 2008 Ontolog Forum Presentation A. Dogac, Y. Yarimagan, Y. Kabak 55

Component Merge Service n Given multiple custom versions of a component, generates a combined version q q n Derivation operations (extensions and restrictions) are extracted from individual versions Extracted derivations are successively applied to the original component version Resulting component is a valid specialization of merged versions in terms of UBL validation March 6, 2008 Ontolog Forum Presentation A. Dogac, Y. Yarimagan, Y. Kabak 56

Document Translation Service n Translation is accomplished by traversing the original document in a top -down manner. For every element: q First the corresponding UBL Component is gathered q Then the Component Ontology class representing that component is located q Then the corresponding Component Ontology class applicable for the target context is computed: n n n q q First equivalent classes are checked Then sub-classes are checked Finally super-classes are checked If an applicable component can be computed, a corresponding element is added to the target document If an applicable component cannot be computed, original element is added to the UBLExtension hierarchy of the target document March 6, 2008 Ontolog Forum Presentation A. Dogac, Y. Yarimagan, Y. Kabak 57

Catalogue Issue Date Postal Address Street Name Building Number Catalogue Line Provider Party City Name Contact Postal Zone First Name Region Telephone Electronic Mail Minimum Order Person Famliy Name Job Middle Name Other Comm Telefax Channel Item Name Suffix Name Brand Name Model Name Origin Country Name Value Catalogue Supplier Issue Date Supplier Address Street Building City Product Info Contact Information Zip Code Contact Person First Name State Telephone Electronic Mail Facsimile Alternate Contact March 6, 2008 Last Name Manufactured Product Title Name Contact Ontolog Forum Presentation Medium Info A. Dogac, Y. Yarimagan, Y. Kabak Make Model Manufacturing Country Name 58

<Catalogue> <Issue. Date>2007 -12 -15+03: 00</> <Provider. Party> <Postal. Address> <Street. Name>62 nd Avenue South</> <Building. Number>CC-206</> <City. Name>Kent</> <Postal. Zone>98032</> <Region>WA</> </Postal. Address> <Contact> <Telephone>+1 253 854 3237</> <Electronic. Mail>Tire. Collection@Good. Tires. com</> <Telefax>+1 253 854 3239</> <Other. Communication> <Channel>Mobile Phone</> <Value>+1 253 324 5654</> </Other. Communication> </Contact> <Person> <First. Name>Ben</> <Family. Name>Clark</> <Job>Sales Officer</> <Middle. Name>Johnson</> <Name. Suffix>Mr. </> </Person> </Provider. Party> <Catalogue. Line> <Item> <Name>Winter Tire</> <Brand. Name>PR-854</> <Model. Name>Pirelli</> <Origin. Country> <Name>Turkey</> </Origin. Country> </Item> </Catalogue. Line> </Catalogue> March 6, 2008 <Catalogue> <UBLExtension> <Provider. Party> <Person> <Middle. Name>Johnson</> <Name. Suffix>Mr. </> </Person> </Provider. Party> </UBLExtension> <Issue. Date>2007 -12 -15+03: 00</> <Catalogue. Supplier> <Supplier. Address> <Street>62 nd Avenue South</> <Building>CC-206</> <City>Kent</> <Zip. Code>98032</> <State>WA</> </Supplier. Address> <Contact. Information> <Telephone>+1 253 854 3237</> <Electronic. Mail>Tire. Collection@Good. Tires. com</> <Facsimile>+1 253 854 3239</> <Alternate. Contact. Info> <Contact. Medium>Mobile Phone</> <Contact. Info>+1 253 324 5654</> </Alternate. Contact. Info> </Contact. Information> <Contact. Person> <First. Name>Ben</> <Last. Name>Clark</> <Title>Sales Officer</> </Contact. Person> </Catalogue. Supplier> <Product. Info> <Manufactured. Product> <Name>Winter Tire</> <Make>PR-854</> <Model>Pirelli</> <Manufacturing. Country> <Name>Turkey</> </Manufacturing. Country > </Manufactured. Product> </Product. Info> </Catalogue> Ontolog Forum Presentation A. Dogac, Y. Yarimagan, Y. Kabak 59

Talk Outline n n n A Brief Overview of Electronic Business Document Standards UN/CEFACT Core Component Technical Specification Semantic Tools for Interoperability Support q q q n March 6, 2008 Use of Ontologies for Semantic Annotation and Ontology Alignment Document Translation System Architecture and Operation Conclusions Ontolog Forum Presentation A. Dogac, Y. Yarimagan, Y. Kabak 60

Conclusion n Specific contributions of our work: q q q Annotation of components using classes from context ontologies Development of context ontologies for the formal representation of business context domains Facilitating the discovery, reuse and customization of components Development of a component ontology to represent structure and semantics of components Utilization of the ontology for the computation of similarities between components Providing a prototype implementation for the realization of our approach March 6, 2008 Ontolog Forum Presentation A. Dogac, Y. Yarimagan, Y. Kabak 61

Thank you very much for your attention! Questions? March 6, 2008 Ontolog Forum Presentation A. Dogac, Y. Yarimagan, Y. Kabak 62

Extra Slides: Improving the Performance of the Translation Process March 6, 2008 Ontolog Forum Presentation A. Dogac, Y. Yarimagan, Y. Kabak 63

UBL Component Ontology n n UBL aggregate types are composed of numerous elements Not all elements are significant for determining translatability q q All mandatory elements are considered significant and automatically defined in component ontology expressions It is expected from users to specify which optional elements are to be considered as significant for translatability computations March 6, 2008 Ontolog Forum Presentation A. Dogac, Y. Yarimagan, Y. Kabak 64

UBL Component Ontology <xsd: complex. Type name="Endorsement. Type"> <xsd: sequence> <xsd: element ref="Document. ID" min. Occurs="1" max. Occurs="1"/> <xsd: element ref="Approval. Status" min. Occurs="1" max. Occurs="1"/> <xsd: element ref="Remarks" min. Occurs="0" max. Occurs="unbounded"/> <xsd: element ref="Endorser. Party" min. Occurs="1" max. Occurs="1"/> <xsd: element ref="Signature" min. Occurs="0" max. Occurs="unbounded"/> </xsd: sequence> </xsd: complex. Type> Endorsement. Type ≡ (Aggregate. Type refer. Element. (Document. ID Approval. Status Endorser. Party)) n This allows translatability computations to consider only significant elements q Improves outcome and performance of translatability computations March 6, 2008 Ontolog Forum Presentation A. Dogac, Y. Yarimagan, Y. Kabak 65