METU OASIS SET TC Use Case i SURF

METU OASIS SET TC Use Case i. SURF -An Interoperability Service Utility for Collaborative Supply Chain Planning across Multiple Domains Prof. Dr. Asuman Dogac METU-SRDC Turkey

METU OASIS SET TC Use Case n Part I: i. SURF -An Interoperability Service Utility for Collaborative Supply Chain Planning across Multiple Domains and the Document Interoperability Requirements of i. SURF Interoperability Service Utility n Part II: Using SET Tools for translating i. SURF Planning Documents Conforming to Different Standards

Part I: i. SURF -An Interoperability Service Utility for Collaborative Supply Chain Planning across Multiple Domains and the Document Interoperability Requirements of i. SURF Interoperability Service Utility

Research Objectives: Public Domain Tools Supporting SMEs for Collaborative Supply Chain Planning n i. SURF open Smart product Infrastructure for SMEs to collect realtime supply chain visibility data n i. SURF Service Oriented Collaborative Supply Chain Planning Process Definition and Execution Platform for the SMEs n i. SURF Semantic Interoperability Service Utility n i. SURF Global Data Synchronization and Transitory Collaboration Service Utility for dynamic transient supply chain relationships for the SMEs

i. SURF Overview

Part II: Using SET Tools for translating i. SURF Planning Documents Conforming to Different CCTS based Standards

The Main Ideas of the SET Framework If the document components of two different CCTS based 1. 2. 3. 4. standard share the same semantic properties: q Use this as an indication that they may be similar Some explicitly defined semantic properties may imply further implicit semantic relationships: q Use a reasoner to obtain implicit relationships Explicate semantics related with the different usages of document data types in different document schemas to obtain some desired interpretations by means of such informal semantics For discovering the similarities of structurally different but semantically similar document artifacts, we provide further heuristics q About possible ways of organizing core components into compound artifacts

Semantic Properties of UN/CEFACT CCTS based Standards n The Core Components have the following semantic properties: q q q Core Component Data Types Context Code Lists Object Class Term Representation Term The semantics that a BIE is based on a “Core Component”

The Upper Ontology for the Semantics Exposed by the CCTS Framework

Upper Ontologies of Some of the CCTS based Standards and their Relationships to CCTS Ontology

The current SET Harmonized Ontology n The current version of the harmonized ontology contains the ontological representations of: q q n All of the CCs and BIEs in CCL 07 B All of the BIEs in the common library of UBL 2. 0 All of the OAGIS 9. 1 Common Components and Fields All of the elements in the common library of GS 1 XML There about 4758 Named OWL Classes and 16122 Restriction Definitions in the current version of the harmonized ontology

Upper Ontologies and their Relationship to the Document Schema Ontologies

A Specific Instance of the Problem n How to transform q q UBL 2. 0 Forecast Instance, to GS 1 XML Forecast Instance?

The first step… n n n Convert the XSDs of these document instances to OWL conforming to SET specifications SET XSD-OWL Converter tool can be used to generate the OWL definitions of the XSDs conforming to SET Specifications http: //www. srdc. metu. edu. tr/i. SURF/OASISSET-TC/tools/OASISSET. zip

OWL Definition of UBL Forecast Document

OWL Definition of GS 1 XML Forecast Document

Explicate semantics related with the different usages of document data n Different document standards use CCTS Data Types types n n differently For example, “Code. Type" in one standard is represented by “Text. Type" in another standard and yet with “Identier. Type" in another standard This knowledge in real world is expressed through class equivalences so that not only the humans but also the reasoner knows about it q q q Code. Type ≡ Text. Type Name. Type ≡ Text. Type Identier. Type ≡ Text. Type

The Above equivalences are discovered through the SET Harmonized Ontology

The Above equivalences are discovered through the SET Harmonized Ontology

The Above equivalences are discovered through the SET Harmonized Ontology

Addressing Structural Differences in Document Schemas n The harmonized ontology is effective only to discover equivalence of both semantically and structurally similar document artifacts n However Different document standards use core components in different structures n A problem in finding the similar artifacts in two different document schemas is that the semantically similar artifacts may appear at structurally different positions n SET proposes heuristic rules for this

Heuristics to Address Structural Differences in Semantically Equivalent Document Artifacts n This heuristics is about possible ways of organizing core components into compound artifacts and are given in terms of predicate logic rules n Note that a DL reasoner by itself cannot process predicate logic rules and we resort to a well accepted practice of using a rule engine to execute the more generic rules and carry the results back to the DL reasoner through wrappers developed n The results involve declaring further class equivalences in the harmonized ontology

A Heuristic to Help Finding the Equivalent BBIEs at Different Structural Levels n n A BBIE, that directly appears under an ABIE in one schema, may be referred through an ASBIE (at any depth) in an another document schema To give a hint to the reasoner of such possibilities, we developed a piece of software that automatically asserts a subsumtion hierarchy among the “Object Class Terms” of such document artifacts More specifically, when an “ABIE A 1" refers to a "BBIE B" in an "ABIE A 2" through an "ASBIE AS" in one document schema, the Object Class Term of the "BBIE B" is made a subclass of "ABIE A 1" Note that once such an assertion is made, then the reasoner can recursively trace the ASBIEs at any depth

Heuristics to Discover Structurally Different BBIEs n A very common structural difference in semantically similar document artifacts is that although some of the semantic properties of a document artifact “A” is the subclass of the corresponding properties of the document artifact “B”, some other properties of “A” are the super classes of the corresponding attributes of “B” n Heuristics to Discover Structurally Different BBIEs: q If the semantic properties of two BBIEs are pair wise equivalent or subclasses of each other, these BBIEs are considered to be similar

Heuristics to Discover Structurally Different ASBIEs n Heuristics to Discover Structurally Different ASBIEs: q If the semantic properties of two ASBIEs are pair wise equivalent or subclasses of one another, we consider these ASBIEs to be equivalent

Heuristics to Discover Structurally Different ASBIE-BBIE Pairs n Consider two semantically equivalent BBIEs, BBIE 1 and BBIE 2: q If BBIE 1 is in ABIE 1 and ASBIE 1 is referring to ABIE 1, there is a possibility that ASBIE 1 is semantically equivalent to the BBIE 2

Heuristics to Discover Structurally Different ABIEs n n n When it comes to ABIEs, the structural dierences that can occur are more complex because each ABIE may contain different number of BBIEs some of which may be semantically equivalent, some may not Therefore while testing whether two ABIEs are semantically equivalent, the set of BIEs (the set of BBIEs and ASBIEs) they contain is considered We define the “Contains. Set" of an ABIE to be the set of all of its BIEs just to simplify the explanation The “Contains. Set" is in fact the set of BIEs in the range of the “contains" property of an ABIE The “Contains. Set"s of two ABIEs may be equal; may have a nonnul intersection; may be in subset relationships or may be disjoint of each other If the “Contains. Set"s are not disjoint, we provide heuristics to discover their similarity

The “Contains. Set”s of two ABIEs are equivalent or in subset relationship n Consider all the semantic properties of two ABIEs: q If each of them is pair wise equivalent or subclasses of one another, and their “Contains. Set"s are the same, for our purposes we consider these ABIEs to be equivalent

The "Contains. Set"s of two ABIEs have a nonnul intersection n n The semantic properties of two ABIEs may be equivalent and their "Contains. Set" may have a nonnul intersection How to classify these ABIEs is for its user to decide What we provide is a "similarity. Constant" that the user may set As an example, if the user considers that when 60% of the BIEs of two ABIEs are the same, they may be considered similar, then he can set the "similarity. Constant" to "0. 6" When all the semantic properties of two ABIEs are either pair wise equivalent or subclasses of one another, and the BIEs in their "Contains. Set" sets are "similarity. Constant" percent equivalent, we consider these ABIEs to be similar

Example & Heuristic Rules help to find the semantically equivalent but structurally different schemas

SET Framework Target/Source XSD Document Schemas Source OWL Instance R U L E S Upper Ontologies Harmonized Ontology Equality Relations Knowledge Base Source XML Instance DATA LEVEL Rule Engine & Reasoner Subsumption Relations XSLT Definition Target XML Instance KNOWLEDGE LEVEL DATA LEVEL

Back to our problem: Translating i. SURF Planning Documents Conforming to Different CCTS based Standards

A Specific Instance of the Problem n How to transform q q UBL 2. 0 Forecast Instance, to GS 1 XML Forecast Instance?

The Above equivalences are discovered through the SET Heuristic Rules Provided

GS 1. XML UBL 2. 0 Forecast. Indicator Forecast. Based. On. Consensus_Indicator Party. Identification. Details Party. Identification. Primary_Identification. GLN_Identifier Party. Identification. Identifier Non. GLN_Party. Identification. Details Non. GLN_Party. Identification. Text Party. Identification. Identifier Electronic. Document. Status. Identifier Forecast. Document. State. Code Abstract_Forecast. Purpose. Criteria. Type_Code Forecast. Purpose. Code Multi_unit. Measure Dimension. Measure Abstract_Forecast_Time. Stamped. Trade. Item. Quantity. Association. Code Forecast. Identifier. Identifer Date_Time. Period. End. Date_Date. Time Period. End. Date, Period. End. Time Date_Time. Period. Begin. Date_Date. Time Period. Start. Date, Period. Start. Time. Period. Details Time. Period. Length. Duration_Measure Period. Duration. Measure Time. Period. Type. Code Period. Description. Code Trade. Item. Identification. Details Trade. Item. Identification. Primary_Identification. GTIN_Identifier Item. Identification. Identifier Non. GTIN_Trade. Item. Identification. Details Non. GTIN_Trade. Item. Identification. Type_Code Item. Identification. Extended_Identifier Non. GTIN_Trade. Item. Identification. Additional. Value. Text Item. Identification. Additional. Information. Text Forecast. Creation. Date. Time Forecast. Issue. Date, Forecast. Issue. Time Forecast. Details Date_Time. Period. Details

Transforming UBL Forecast to GS 1 XML Forecast n n UBL Forecast document is converted to GS 1 XML Forecast (and vice versa) through OASIS SET TC methodology For the Example Planning Documents, SET TC Semantic Tools were able to find: n The semantic equivalences of 15 BBIEs out of 22 BBIEs (68%) n The semantic equivalences of 7 ABIEs out of 15 ABIEs (46%)

Generating XSLTs through Altova’s Map. Force Tool

Thank you for your attention…