Formal framework for semantic interoperability in

Supply Chain networksMilan Zdravković

PhD Defense9.10.2012

Faculty of Mechanical Engineering in Niš, University of Niš

Puzzle #1Why is interoperability important for networked enterprises?

Problems of “traditional” supply chains

• High-speed, low-cost– Focal partner can’t respond effectively to structural

changes in demand• Cost reduction is a key aspect of collaboration

– Supplier Relationship Management becomes key aspect of SCM

– Number of suppliers is reduced– Only dyadic relationships are managed– High level of integration

• Both suppliers and focal partner are having high costs• Supplier suffers from reduced flexibility

Why is SCM important for suppliers?

Why is Supply Chain Management important for suppliers

What is expensive in SCM?

What is expensive in Supply Chain Management

Virtual organizations

*Virtual BreedingEnvironment

Virtual organizations – Supply chains of the future ?

Ent2

Ent4

Ent1

Ent3

Ent5Ent6

**Virtual Enterprise 1

Ent21

Ent41

Ent11

Ent31

Ent61

**Virtual Enterprise n

Ent2n

Ent4n

Ent5n

Ent3n

Opportunity 1 Opportunity n

Sel

ect

ion

Con

figur

atio

n

Sel

ect

ion

Con

figur

atio

n

Dis

solu

tion

Dis

solu

tion

**Temporary network of independent enterprises, who join together quickly to exploit fast-changing opportunities and then dissolve (Browne and Zhang, 1999)

* Pool of organizations and related supporting institutions that have both the potential and the will to cooperate with each other through the establishment of a “base” long-term cooperation agreement and interoperable infrastructure. (Sánchez et al, 2005)

Many new forms for the VOs

Collaborative organization forms

How the costs of SCM are reduced?

How the costs of Supply Chain Management are reduced

What is interoperability?

What is interoperability ?

• ISO/IEC 2382– 01.01.47 interoperability: The capability to communicate,

execute programs, or transfer data among various functional units in a manner that requires the user to have little or no knowledge of the unique characteristics of those units.

• The main prerequisite for achievement of interoperability of the loosely coupled systems is to maximize the amount of semantics which can be utilized and make it increasingly explicit (Obrst, 2003)

SCOR basic management processes

Supply Chain Operations Reference Model (SCOR) : Basic Management Processes

Plan-Source-Make-Deliver-Return

Supplier’sSupplier

Make DeliverSource Make DeliverMakeSourceDeliver SourceDeliverSource

Customer’s Customer

Plan

Supplier (Internal or External)

Your Company

Customer (Internal or External)

ReturnReturn ReturnReturn

ReturnReturn

..plus

..plus:

• Each of the processes has its own activities, metrics and best practices

• Each of the activities has inputs&outputs, metrics and best practices

• Each of the metrics has performance attributes• Each of the best practices is implemented by the

system

Make DeliverSource Make DeliverMakeSourceDeliver SourceDeliverSource

Plan

ReturnReturn ReturnReturn

ReturnReturn

Why is interoperability important for SCM?

Why is interoperability important for Supply Chain Management?

Supplier’sSupplier

Make DeliverSource Make DeliverMakeSourceDeliver SourceDeliverSource

Customer’s Customer

Plan

Supplier (Internal or External)

Your Company

Customer (Internal or External)

ReturnReturn ReturnReturn

ReturnReturn

Interoperability issues

Asset flows between two SCOR processes

Assets flows between process elements for engineered-to-order production type

Systems do not “speak” SCOR

Puzzle #2Why is ontology important for interoperability?

“Lost in translation”

Issues source: “Lost in translation”

• There is NO lingua franca for enterprises, they all “speak” different languages

• However, some are “less different” than the others:– Enterprise models (loose alphabets)– Reference models (strict alphabets)– Ontologies (formal alphabets)

What is ontology?

• Concepts can be related to other concepts– e.g. with parent and child relations

• Concepts can be combined into propositions• Propositions can be clustered into mental models• When all this is specified, what we get is..

– ONTOLOGY

So, what is ontology?

This is ontology

Concepts∃p (information(p)), e (enterprise(e)), t (task(t)), g (goal(g)), r ∃ ∃ ∃ ∃

(resource(r)),...Propositions (statements)

∃e n (enterprise(e) ∃ ∧ enterprise(n) ∧ network-with(e,n))∃e n (enterprise(e) ∃ ∧ enterprise(n) ∧ coordinate-with(e,n))∃e n (enterprise(e) ∃ ∧ enterprise(n) ∧ cooperate-with(e,n))

Mental models (rules)network-with(A,B) p(information(p) (send(A,p) receive(B,p)) ⇒ ∃ ∧ ∧ ∨

(send(B,p) receive(A,p)))∧coordinate-with(A,B) network-with(A,B) m n(task(m) task(n) ⇒ ∧ ∃ ∃ ∧ ∧

responsible-for(A,m) responsible-for(B,n) has-precondition (n, ∧ ∧status(m,’completed’)))

cooperate-with(A,B) coordinate-with(A,B) m n(task(m) task(n) ⇒ ∧ ∃ ∃ ∧ ∧responsible-for(A,m) responsible-for(B,n) r(resource(r) consumed-∧ ∧ ∃ ∧by(r,m) consumed-by(r,n)) g f(goal(g) goal(f) has-goal(A,g) has-∧ ∧ ∃ ∃ ∧ ∧ ∧goal(B,f) is-compatible-with(g,f))∧

collaborate-with(A,B) cooperate-with(A,B) m(task(m) responsible-⇒ ∧ ∃ ∧for(A,m) responsible-for(B,m)) g(goal(g) has-goal(A,g) has-∧ ∧∃ ∧ ∧goal(B,g))

This is also an ontology (more formal and explicit)

Representational languages

Representation languages for ontology

• Less formal– UML (Unified Modeling Language), – E/R (Entity/Relationship) Syntax

• More formal– OWL, SWRL

Puzzle #3What is semantic interoperability (of systems)?

Why systems are good in communication

Why systems are bad in communication

Human communication as a raw model for interoperability

Human communication as a raw model for interoperability

SensationSensationPerceptionPerception

CognitionCognition ArticulationArticulation

Providing meaning to various sensations

In contexts of expectations,

experience, culture, etc.

Gaining knowledge and comprehension from the sensations

Storage, reasoning, problem solving, imagining,

conceptualizing

Stimulus sensory energy

psysiological

psychological

Selection of sensations

Articulating response

Receipients, language, means

SensationPerception

Cognition Articulation

∃R(system(R))

Requirements for semantic interoperability

Sensation Perception

CognitionArticulation

• Sensation– “Ask” & “Tell” interface– No need for selective sensation

• Perception– Semantic matching and

reasoning– Explicit enterprise knowledge

(ontologies)

WebservicesOntologies

Queryprocessing

SemanticmatchingReasoner

• Cognition– Triple store– Formalized business rules– Rules-enabled reasoning– Assertion of new

knowledge– Formalized interoperability

protocols

Ontologies

Mappings ∃S(system(S))

∀p (

(transmitted-from(p,S) transmitted-to(p,R)) ∧ ∧

∀q(statement-of(q,S) p q) ∧ ⇒

∃q’(statement-of(q’,R) p q’ q’⇔q)∧ ⇒ ∧

) ⇒ semantically-interoperable(S,R)

Implementation of semantically interoperable systems

Cn

C1

C2

Implementation of semantically interoperable systems

OL1

OD1

OL2

ML1D1

ML2D1

MO1O2≡f(ML1D1 , ML2D1)

S1

S2

MLnD1

Sn

OLn

MO1On≡f(ML1D1 , MLnD1)

OD2

Si

OLi

MLiD2

MD1D2

MO1Oi≡f(ML1D1 , MD1D2, MLiD2)

• S1-Sn – Enterprise Information Systems

• OL1-OL2 – Local ontologies

• OD1,2 – Domain ontologies

• MLiDi – Mappings between local and domain ontologies

Adding contexts

Adding contexts improves expressiveness of a framework

• if there exist systems S1 and S2, driven by the ontologies O1 and O2,

• and if there exist alignment between these ontologies O1≡O2,

• the competence of O1 will be improved and S1 will be enabled to make more qualified conclusions about its domain of interest

Puzzle #4Which semantics for interoperability?

Framework for semantic enrichment of reference models

Unifying modelSemantically

enriched model

Domain ontology 1

Domain ontology 2

OWL modelReference models

(formats)Reference models (native formats)

Application ontology 1

Application ontology 2

Mappingrules

Mappingrules

Mappingrules

Mappingrules

Import tools

Sync tools

Mappingrules

Mappingrules

SCOR-KOS OWL model

SCOR-KOS OWL Model• 418 metrics

elements, • 166 process

elements, • 25 process

categories, • 164 best

practices, • 282

Input/Output elements and

• 108 system elements

SCOR-KOS OWL Model

Web app for browsing SCOR-KOS OWL model

Web application for browsing the SCOR model

SCOR-Full ontology

SCOR-Full Ontology• Explication of SCOR-KOS OWL• Developed by semantic analysis of SCOR-Full

Input/Output elements

SCOR-Full concepts

Agent concept

• ∀a (agent(a)) c (course(c) performs(a,c))∃ ∧• Not functional

Course concept• Generalizes “doable” or

“done” things with common properties of environment, quality and organization

• ∀c (course(c)) f ∃(function(f) has-∧function(c,f))

• ∀c (course(c)) s ∃(setting(s) has-∧setting(c,s))

Setting concept

• provides the description of circumstances of a course

• ∀s (setting(s)) ci ∃(configured-item(ci) ∧has-realization(s,ci))

• provides the description of circumstances of a course

• ∀s (setting(s)) ci ∃(configured-item(ci) ∧has-realization(s,ci))

Quality concept

• general attribute of a course, agent or function which can be perceived or measured

• ∀q (quality(q)) ci ∃(configured-item(c) ∧has-attribute(q,ci))

Function concept

• entails elements of the horizontal business organization

Resource item concepts

• Inf-Item defines the semantics of the relevant resource (atomic concept)

• Conf-Item describes its dynamics

• Inf-Item defines the semantics of the relevant resource (atomic concept)

• Conf-Item describes its dynamics

Configured items• (Inf-Item(?x) (has-numerical-value(?x, decimal) has-text-∧ ∨

value(?x, string) has-date-value(?x, dateTime) (Inf-Item(?∨ ∨i) has-realization(?x, ?i)))) ((Phy-Item(?x) Inf-Item(?x)) ∧ ∨ ∨

has-state(?x,state(?y))) Conf-Item(?x)∧ ⇒ • Examples

– customer-credit(?x) in-state(?x, Adjusted) SameAs (?x, ∧ ⇒Adjust_Customer_Credit)

– return-to-service(?x) in-state(?x, Authorized) SameAs (?x, ∧ ⇒Authorization_to_Return_to_Service)

– product(?x) in-state(?x, Consolidated) SameAs (?x, ∧ ⇒Consolidated_Product)

Logical correspondences

business-rule(?x) return-process(?y) has-rule(?y, ?x) SameAs(?x, ∧ ∧ ⇒Business_Rules_For_Return_Processes)available-to-promise(?x) time-range(?y) has-quality(?x, ?y) SameAs (?∧ ∧ ⇒y, Available_to_Promise_Date)capability(?x) return-process(?y) has-quality(?y, ?x) SameAs (?x, ∧ ∧ ⇒Capabilities_of_the_Return_Processes)production-schedule(?x) SameAs (?x, ⇒ Production_Schedule)

Logical correspondences between implicit and explicit model

SCOR-Full validated

SCOR-Full Validated

• All 282 SCOR Input/Output elements (with implicit meaning) are mapped to SCOR-Full concepts– All implicit meanings are now explained

(explicated)

Adding new contexts: TOVE

Adding new contexts: Logical correspondences between SCOR-Full

and TOVE• Facilitates the improvement of

the structural and behavioural competence of the SCOR-Full model. Competency: – Whose permission (if any) is needed

in order to perform the specific task of selected process element (activity)?

– Who has authority to verify the receipt of the sourced part?

– Which communication link can be used to acquire specific information?, etc.

Formal framework for SC operations

Formal framework for supply chain operations

SCOR-FULL OWL

SCOR-KOS OWL

SCOR Native formats, Exchange formats

DomainOntologies

Implicit semantics

Explicit semantics

Semantic enrichment

Formal models of design goals

SCOR-CFG OWL

SCOR-GOAL OWL

PRODUCT OWL

SC

OR

- M

AP

Sem interoperability of systems in SC network

Semantic interoperability of systems in supply chain network

SCOR-FULL OWL

SCOR-SYS OWL

SCOR-KOS OWL

SCOR Native formats, Exchange

formats

DomainOntologies

Implicit semantics

Explicit semantics

Semantic enrichment

Formal models of design goals

Semantic applications

Enterprise Information

Systems

SCOR-based systems

SCOR-CFG OWL

SCOR-GOAL OWL

PRODUCT OWL

EIS database

LOCAL ONTOLOGY

EIS database

LOCAL ONTOLOGY

EIS database

LOCAL ONTOLOGY

SC

OR

- M

AP

Puzzle #5How this semantics can be used for interoperability?

Interoperability Service Utilities (ISU)

• available at low cost, • accessible in principle by all enterprises

(universal or near-universal access), • guaranteed to a certain extent and at certain

level in accordance with a set of common rules,

• not controlled or owned by any single private entity.

S-ISU

Semantic Interoperability Service Utilities (S-ISU)

• Take into account the restrictions of the functional approach and it assumes that enterprises should take their own decision on which part of their semantics should be made interoperable;

• This semantics is described by the local ontologies. The main objective of the framework is to make those ontologies interoperable;

• Minimum technical pre-requirements are foreseen;• The formal framework is not associated with some storage

facility; • The formal framework facilitates delivery of the information

by combining their sources (namely, local ontologies). – Only meta-information (other than a formal framework - common

ontologies) about the interoperable systems is kept centrally;

S-ISU: Component view

ON

TO

LO

GY

Main ServicesEIS

LOCAL CENTRAL

UT

ILIT

Y

EISDatabase

Listener

LocalOntology

Nativeformats

Exchangeformats

LocalOntology

LocalOntology

MappingOntology

DomOnt1

DomOntn

ProbOnt1

ProbOntm

Supportive Apps

Semantic Apps

VE formation Services

SQS

ReaS

RegS SRS

TrS

RegSApp

SRSApp

SemApp 1

SemApp n}

}

AuthAppReaS

Component view of S-ISU architecture

S-ISU for semantically interoperable systems

MAPPINGONTOLOGY

Implicit semantics

Explicit semantics

Semantic applicationsand services

Enterprise Information

Systems

PROB ONT

PROB ONT

Transformationservice

LOCAL ONTOLOGY

LOCAL ONTOLOGY

DO

MA

IN O

NT

DO

MA

IN O

NT

DO

MA

IN O

NT

Native formats, Exchange formats

EIS database

EIS database

SemanticQuery service

Listener

Listener

Reasoningservice

Registrationservice

Reconciliationservice

S-ISU for Semantically interoperable systems

Puzzle #6How the systems are explicated and queried by using the semantics?

Database

er.owl

attribute

constraint

entity

multiplicityrelatio

n

type

hasAttribute

hasType

hasConstraint

hasSourceAttribute

hasDestinationAttribute

hasSourceMultiplicity

hasDestinationMultiplicity

output

imports

s-er.owl

concept hasObjectProperty

data-type

hasDataProperty data-concept

hasDataType

hasDefiningProperty

hasDefiningDataPropertyhasFunctionalProperty

output

er:entity(x) not (er:hasAttribute only ∧(er:attribute (er:isSourceAttributeOf ∧some er:relation))) ⇒ s-er:concept(x)

er:entity(x) er:entity(y) er:relation(r) ∧ ∧ er:hasAttribute(x, a1) ∧ ∧

er:hasAttribute(y, a2) ∧er:isDestinationAttributeOf(a2, r) ∧er:isSourceAttributeOf(a1, r) ⇒s-er:hasObjectProperty(x, y)

s-er:hasObjectProperty(x, y) ∧er:hasConstraint(a1,'not-null') ⇒s-er:hasDefiningProperty(x, y)

er:attribute and not (er:isSourceAttributeOf some er:relation)

⇒ s-er:data-concept

er:type(x) ⇒ s-er:data-type(x)s-er:concept(c) er:attribute(a) ∧ ∧er:type(t) er:hasAttribute(c, a) ∧ ∧er:hasType(a, t) ⇒s-er:hasDataProperty(c, t)

s-er:hasDataProperty(c, t) ∧er:hasConstraint(a,'not-null') ∧er:hasConstraint(a,'unique') ⇒s-er:hasDefiningDataProperty(c, t)

Database-to-ontology mapping

Data import andclassification of ER entities

Classification (inference) of OWL types and properties

LexicalRefinement

Local ontologygeneration

output

Query-driven vs massive dump population

Query-driven vs. massive dump population

• Massive dump population– Local ontology is pre-populated with database

instances– Querying local ontology at a runtime– Performance and synchronization issues

Query-driven population

Query-driven population• Querying database at a

runtime, real-time access to information

• Issues– Centralized inference –

all ontologies need to be in the reasoner’s memory space (static imports)

– Data security / access authorization

Semantic query execution

Semantic query execution

Input Query

hasResCompany some(hasResCurrency some

(hasName value "EUR"))

Decompositionsubject predicate some|only|min n|max m|exactly o bNodesubject predicate value {type}

XhasResCompany

some bNode1

bNode1hasResCurrency

some bNode2

bNode2hasName

value "EUR"

SQL constructand execute

bNode2 nothing ?

Assert totemporary mdl

SQL constructand execute

bNode1 nothing ?

Assert totemporary mdl

SQL constructand execute

X nothing ?

End resultgraph

Assert totemporary mdl

Yes

Yes

Yes

No

No

No

Manufacturing of custom orthopedic implants

• Using custom implants over standard ones– Duration of operation decreased– Reliability of operation increased– Period of patient’s recovery reduced– Overal cost of treatment reduced– Risk of complications reduced

Case implementation

Case implementation

• Proposed models, knowledge and systems infrastructure

• Interoperability and semantic interoperability issues analyzed

• Infrastructure for collaborative supply chain planning implemented– Supply chain processes configuration problem

resolved– Semantic querying of the production schedules

for a given part enabled

Semantic interoperability framework for this case

Semantic interoperability framework revisited

SCOR-FULL OWL

Implicit semantics

Explicit semantics

Semantic enrichment

Formal models of design goals

Semantic applications

Enterprise Information

Systems

SCOR-CFG OWL

OpenERP database

OpenERPLOCAL ONTOLOGY

SC

OR

- M

AP

Web application for SCOR process configuration

Web application for SCOR process configuration

• Features– Development of

complex thread diagrams (multiple tiers, additional participants)

– Generation of process models and workflows (including PLAN activities)

– Generation of implementation roadmap

SCOR-CFG OWL ontology

SCOR – CFG OWL, Example of application ontology

• Design goal – Generation of SCOR thread diagrams

SCOR thread diagram for manufacturing of custom implants

SCOR thread diagram for manufacturing custom implants

Interoperability requirements (inferred)

Interoperability requirements (inferred from SCOR-KOS OWL)

OpenERP ontology

OpenERP ontology

• OpenERP PostgreSQL database with 238 tables is transformed to a local ontology, with 193 concepts, 493 data concepts and 2779 properties

• OpenERP PostgreSQL database with 238 tables is transformed to a local ontology, with 193 concepts, 493 data concepts and 2779 properties

Fragment of UML representation

Fragment of UML representation of OpenERP

local ontology

Querying OpenERP

Querying OpenERP local ontology

• Production schedule for the product (part) with name "Custom fixture F12"

• By using SCOR-Full– has-realization some (production-schedule-item and has-

product-information some (has-name value "Custom inner fixture F12"))

• By using the local ontology of OpenERP system:– mrp_production and hasProductProduct some

(hasProductTemplate some (hasName value "Custom inner fixture F12"))

Result of query execution

Result of query execution

Conclusions (1/5)• Enterprises will continue to have mixed ICT

environments for the foreseeable future– increase of the data complexity– further ICT developments

• rate of the heterogeneity in the systems architecture will increase

• interoperability is expected to become more critical feature of the EISs

Conditional vs. unconditional interoperability

Conditional vs. unconditional (and universal) interoperability

• The main pre-determined asset, which is needed so two system can interoperate is a common semantics

• Traditional approaches structures interoperability problem into levels– This is not convinient, because individual level cannot be

semantically analyzed (by implementing a full ontological commitment) in isolation from the others

• Enterprise systems should not be exposed to the interoperable environment by the levels or any other conceptual categories, but by ontologies

Possible restrictions

Possible restrictions

• incompleteness and lack of validity of logical correspondences between two ontologies

• expressiveness of the implicit models, namely local ontologies

• expressiveness of the languages, used to formalize those models

• restricted access to some of the information, modelled by the parts of local ontology

Formalizing domains and systems semantics

Formalizing domains and systems semantics

• NOT from the scratch. Issues:– Time and effort– Misbalance of the needed ontological commitment and

epistemological dimension– Detachment from the common language of the domain

• Task of the EIS conceptualization is not really to conceptualize the EIS models, but: – to make the assumptions on the mental models of the information

systems’ designers– to make those models fully or partially equivalent to the real world

semantics (ontological commitment)• This task is NOT yet achieved !

– Example 1: lack of logical implications of the cardinality of relationships and existential constraints (mandatory elements)

– Example 2: semantics of the populated data rows remain hidden

Human communication by logical positivists

Why considering a human communication ? Logical positivists:

• The meaning is formally defined because it is intended to be computable or inferred by the different agents for the different purposes– This formal definition aims at bringing closer the symbols,

used to formally describe a particular object, to its typical mental representation

• The meaning is nothing more or less than the truth conditions it involves. – Here, the meaning is explained by using the references to

the actual existing (possibly also logically explained) things in the world.

Human communication by linguists

Why considering a human communication ? Linguists:

• The meaning is what the sender expresses, communicates or conveys in its message to the receiver (or observer) and what the receiver infers from the current context

• The pragmatic meaning considers the contexts that affect the meaning and it distinguishes two of their primary forms– The linguistic context refers to how meaning is

understood, without relying on intent and assumptions• Expressivity, levels of abstraction

– The situational context refers to non-linguistic factors which affect the meaning of the message

• Descriptions of problems - intent

Key contributions

Key contributions

• 1) Common vocabulary, layered in different levels of abstraction for supply chain relevant systems interoperation

• 2) Method for systems explication (conceptualization) and associated method for semantic querying of those systems

Further research directions

Further research directions 1/2• General Semantic interoperability

– Implementing method for evaluating semantic interoperability of two systems;

– Further development of theoretical background for semantic interoperability, by following the principles of human communication;

• Formal model for supply chain operations– Further explication of the SCOR-Full domain model by mapping with

relevant and/or complementary domain models, such as RosettaNet , UNSPSC , AIAG and STAR , EDI , etc;

– Development of new application models and ontologies which directly exploits SCOR-Full domain model;

– Top-down validation of SCOR-Full domain model by semantic analysis of the logical correspondences with relevant upper ontologies, such as DOLCE;

Further research directions 2/2• S-ISU Transformation and Semantic Querying Service

– Analysis of data patterns with goal to discover the semantics of the ambiguous notions of the local ontologies (e.g. type or status);

– Semi-automatic classification of the concepts of local ontologies by analysis of necessary conditions for different concepts;

– Developing universal method for semantic query rewriting, where source and destination queries are using the concepts of two ontologies, logically interrelated by using SWRL rules;

– Developing method and tools for execution of “Tell” semantic queries;• General Semantic web tools

– Implementing distributed reasoning capabilities for modular ontologies with dynamic imports;

– Implementing security and access control levels to the parts of ontologies in distributed ontological frameworks;

– Advance in performance and quality of ontology matching tools.

Thank you for your attentionQ&A

Milan ZdravkovićPhD Defense