iSURF -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

Part I: iSURF -An Interoperability Service Utility for Collaborative Supply Chain Planning across Multiple Domains and the Document Interoperability Requirements of iSURF Interoperability Service Utility Part II: Using SET Tools for translating iSURF Planning Documents Conforming to Different Standards

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

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

iSURF Overview

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

The Main Ideas of the SET Framework 1. If the document components of two different CCTS based standard share the same semantic properties:  Use this as an indication that they may be similar 2. Some explicitly defined semantic properties may imply further implicit semantic relationships:  Use a reasoner to obtain implicit relationships 3. 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 4. For discovering the similarities of structurally different but semantically similar document artifacts, we provide further heuristics  About possible ways of organizing core components into compound artifacts

Semantic Properties of UN/CEFACT CCTS based Standards The Core Components have the following semantic properties:  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 The current version of the harmonized ontology contains the ontological representations of:  All of the CCs and BIEs in CCL 07B  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 GS1 XML There are about 4758 Named OWL Classes and 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 How to transform  UBL 2.0 Forecast Instance, to  GS1 XML Forecast Instance?

The first step… 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 SET-TC/tools/OASISSET.zip

OWL Definition of UBL Forecast Document

OWL Definition of GS1 XML Forecast Document

Explicate semantics related with the different usages of document data types Different document standards use CCTS Data Types 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  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 The harmonized ontology is effective only to discover equivalence of both semantically and structurally similar document artifacts However Different document standards use core components in different structures A problem in finding the similar artifacts in two different document schemas is that the semantically similar artifacts may appear at structurally different positions SET proposes heuristic rules for this

Heuristics to Address Structural Differences in Semantically Equivalent Document Artifacts This heuristics is about possible ways of organizing core components into compound artifacts and are given in terms of predicate logic rules 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 The results involve declaring further class equivalences in the harmonized ontology

A Heuristic to Help Finding the Equivalent BBIEs at Different Structural Levels 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 A1" refers to a "BBIE B" in an "ABIE A2" through an "ASBIE AS" in one document schema, the Object Class Term of the "BBIE B" is made a subclass of "ABIE A1" 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 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” Heuristics to Discover Structurally Different BBIEs:  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 Heuristics to Discover Structurally Different ASBIEs:  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 Consider two semantically equivalent BBIEs, BBIE1 and BBIE2:  If BBIE1 is in ABIE1 and ASBIE1 is referring to ABIE1, there is a possibility that ASBIE1 is semantically equivalent to the BBIE2

Heuristics to Discover Structurally Different ABIEs When it comes to ABIEs, the structural differences 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 “ContainsSet" of an ABIE to be the set of all of its BIEs just to simplify the explanation The “ContainsSet" is in fact the set of BIEs in the range of the “contains" property of an ABIE The “ContainsSet"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 “ContainsSet"s are not disjoint, we provide heuristics to discover their similarity

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

The "ContainsSet"s of two ABIEs have a nonnul intersection The semantic properties of two ABIEs may be equivalent and their "ContainsSet" may have a nonnul intersection How to classify these ABIEs is for its user to decide What we provide is a "similarityConstant" 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 "similarityConstant" 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 "ContainsSet" sets are "similarityConstant" percent equivalent, we consider these ABIEs to be similar

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

Methodology

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

Back to our problem: Translating iSURF Planning Documents Conforming to Different CCTS based Standards

A Specific Instance of the Problem How to transform  UBL 2.0 Forecast Instance, to  GS1 XML Forecast Instance?

The Above equivalences are discovered through the SET Heuristic Rules Provided

Transforming UBL Forecast to GS1 XML Forecast UBL Forecast document is converted to GS1 XML Forecast (and vice versa) through OASIS SET TC methodology For the Example Planning Documents, SET TC Semantic Tools were able to find: The semantic equivalences of 15 BBIEs out of 22 BBIEs (68%) The semantic equivalences of 7 ABIEs out of 15 ABIEs (46%) The Information on this slide is WRONG!!! System behaves much, much better than this! We will provide detailed statistics later!

GS1.XMLUBL 2.0 Forecast.Indicator.IndicatorForecast.BasedOnConsensus_Indicator.Indicator PartyIdentification.Details PartyIdentification.Primary_Identification.GLN_IdentifierPartyIdentification.Identifier NonGLN_PartyIdentification.DetailsPartyIdentification.Details NonGLN_PartyIdentification.Identification.TextPartyIdentification.Identifier ElectronicDocument.Status.IdentifierForecast.DocumentStateCode.Code Abstract_Forecast.Purpose.ForecastPurposeCriteriaType_CodeForecast.PurposeCode.Code Multi_unitMeasure.Measure.MeasureDimension.Measure Abstract_Forecast_TimeStampedTradeItemQuantity.Association. Code Forecast.Identifier.Identifer Date_TimePeriod.EndDate.Date_DateTimePeriod.EndDate.Date, Period.EndTime.Time Date_TimePeriod.BeginDate.Date_DateTimePeriod.StartDate.Date, Period.StartTime.Time TimePeriod.DetailsPeriod.Details TimePeriod.Length.Duration_MeasurePeriod.Duration.Measure TimePeriod.Type.CodePeriod.DescriptionCode.Code TradeItemIdentification.DetailsItemIdentification.Details TradeItemIdentification.Primary_Identification.GTIN_IdentifierItemIdentification.Identifier NonGTIN_TradeItemIdentification.DetailsItemIdentification.Details NonGTIN_TradeItemIdentification.Identification.Type_CodeItemIdentification.Extended_Identifier.Identifier NonGTIN_TradeItemIdentification.AdditionalValue.TextItemIdentification.AdditionalInformation.Text Forecast.CreationDateTime.DateTimeForecast.IssueDate.Date, Forecast.IssueTime.Time Forecast.Details Date_TimePeriod.DetailsPeriod.Details

Generating XSLTs through Altova’s MapForce Tool

Thank you for your attention…