iSURF -An Interoperability Service Utility for Collaborative Supply Chain Planning across Multiple Domains

Prof. Dr. Asuman DogacMETU-SRDCTurkey

METU OASIS SET TC Use Case

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 similar2. 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 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

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

http://www.srdc.metu.edu.tr/iSURF/OASIS-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 XMLInstance

Source OWLInstance

DATA LEVELKNOWLEDGE LEVEL DATA LEVEL

Target XMLInstance

Target/SourceXSD

Document Schemas

Upper Ontologies

Knowledge Base Rule

Engine & Reasoner

RULES

XSLT Definition

Harmonized Ontology

EqualityRelations

SubsumptionRelations

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.XML UBL 2.0

Forecast.Indicator.Indicator Forecast.BasedOnConsensus_Indicator.Indicator

PartyIdentification.Details PartyIdentification.Details

PartyIdentification.Primary_Identification.GLN_Identifier PartyIdentification.Identifier

NonGLN_PartyIdentification.Details PartyIdentification.Details

NonGLN_PartyIdentification.Identification.Text PartyIdentification.Identifier

ElectronicDocument.Status.Identifier Forecast.DocumentStateCode.Code

Abstract_Forecast.Purpose.ForecastPurposeCriteriaType_Code Forecast.PurposeCode.Code

Multi_unitMeasure.Measure.Measure Dimension.Measure

Abstract_Forecast_TimeStampedTradeItemQuantity.Association.Code

Forecast.Identifier.Identifer

Date_TimePeriod.EndDate.Date_DateTime Period.EndDate.Date, Period.EndTime.Time

Date_TimePeriod.BeginDate.Date_DateTime Period.StartDate.Date, Period.StartTime.Time

TimePeriod.Details Period.Details

TimePeriod.Length.Duration_Measure Period.Duration.Measure

TimePeriod.Type.Code Period.DescriptionCode.Code

TradeItemIdentification.Details ItemIdentification.Details

TradeItemIdentification.Primary_Identification.GTIN_Identifier ItemIdentification.Identifier

NonGTIN_TradeItemIdentification.Details ItemIdentification.Details

NonGTIN_TradeItemIdentification.Identification.Type_Code ItemIdentification.Extended_Identifier.Identifier

NonGTIN_TradeItemIdentification.AdditionalValue.Text ItemIdentification.AdditionalInformation.Text

Forecast.CreationDateTime.DateTime Forecast.IssueDate.Date, Forecast.IssueTime.Time

Forecast.Details Forecast.Details

Date_TimePeriod.Details Period.Details

Generating XSLTs through Altova’s MapForce Tool

Thank you for your attention…