Milan Zdravković, PhD Defense, 9.10.2012, Faculty of Mechanical Engineering in Niš, University of Niš

1. Formal framework for
semantic interoperability in
Supply Chain networks
Milan Zdravković
PhD Defense
9.10.2012
Faculty of Mechanical Engineering in Niš,
University of Niš

3. Puzzle #1
Why is
interoperability
important for
networked
enterprises?

4. 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?

5. Why is Supply Chain Management
important for suppliers
What is expensive in SCM?

6. What is expensive in Supply Chain
Management
Virtual organizations

7. Virtual organizations – Supply chains of
the future ?
Opportunity 1 Opportunity n
Configuration
Configuration
*Virtual Breeding
Selection
Selection
**Virtual Enterprise 1 **Virtual Enterprise n
Environment
Ent21 Ent2 Ent1 Ent2n
Ent11 Ent5n
Ent61 Ent3 Ent4
Ent4n
Ent41 Ent3n
Ent31
Dissolution
Dissolution
Ent6
Ent5
**Temporary network * Pool of organizations and related
of independent supporting institutions that have both
enterprises, who join the potential and the will to cooperate
together quickly to with each other through the
exploit fast-changing establishment of a “base” long-term
opportunities and then cooperation agreement and
dissolve (Browne and interoperable infrastructure.
Zhang, 1999) (Sánchez et al, 2005)
Many new forms for the VOs

8. Collaborative organization forms
How the costs of SCM are reduced?

9. How the costs of Supply Chain
Management are reduced
What is interoperability?

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

11. Supply Chain Operations Reference Model
(SCOR) : Basic Management Processes
Plan-Source-Make-Deliver-Return
Plan
Deliver Source Make Deliver Source Make Deliver Source Make Deliver Source
Return Return Return Return
Supplier’s Return Return
Customer’s
Supplier Customer
Supplier Customer
(Internal or (Internal or
Your Company External)
External)
..plus

12. ..plus:
Plan
Deliver Source Make Deliver Source Make Deliver Source Make Deliver Source
Return Return Return Return
Return Return
• 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
Why is interoperability important for SCM?

13. Why is interoperability important for
Supply Chain Management?
Plan
Deliver Source Make Deliver Source Make Deliver Source Make Deliver Source
Return Return Return Return
Supplier’s Return Return
Customer’s
Supplier Customer
Supplier Customer
(Internal or (Internal or
Your Company External)
External)
Interoperability issues
Asset flows between two SCOR processes

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

15. Systems do not “speak” SCOR

17. Puzzle #2
Why is ontology
important for
interoperability?

18. “Lost in translation”

19. 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?

20. So, 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

21. This is ontology

22. This is also an ontology (more formal
and explicit)
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))
Representational languages

23. Representation languages for
ontology
• Less formal
– UML (Unified Modeling Language),
– E/R (Entity/Relationship) Syntax
• More formal
– OWL, SWRL

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

26. Why systems are good in
communication

27. Why systems are bad in
communication
Human communication as a raw model for interoperability

28. Human communication as a raw model for
interoperability
Providing meaning to Selection of Stimulus
sensory energy
various sensations sensations
In contexts of
expectations,
experience, Perception Sensation
culture, etc.
Perception Sensation
Gaining
ps
knowledge and
ys
ps
Cognition Articulation
iol
comprehension Cognition Articulation
yc
og
ho
ica
from the
log
l
ica
sensations
l
Articulating
Storage, reasoning, response
Receipients,
problem solving, imagining, language, means
conceptualizing

29. Requirements for semantic interoperability
∃S(system(S))
Semantic Query
Reasoner Mappings
matching processing
Web
Ontologies services
Articulation Cognition
Ontologies
Perception Sensation
Sensation Perception
Cognition Articulation
∀p (
(transmitted-from(p,S) ∧ transmitted-to(p,R)) ∧
∃R(system(R)) ∀q(statement-of(q,S) ∧ p⇒q)
∃q’(statement-of(q’,R) ∧ p⇒q’ ∧ q’⇔q)
• Sensation • Cognition ) ⇒ semantically-interoperable(S,R)
– “Ask” & “Tell” interface – Triple store
– No need for selective sensation – Formalized business rules
• Perception – Rules-enabled reasoning
– Semantic matching and – Assertion of new
reasoning knowledge
– Explicit enterprise knowledge – Formalized interoperability
(ontologies) protocols
Implementation of semantically interoperable systems

30. Implementation of semantically
interoperable systems
C1 MO1Oi≡f(ML1D1 , MD1D2, MLiD2)
Si
S1
OL1 ML1D1 OLi
MO1O2≡f(ML1D1 , ML2D1) MLiD2
OD1 OD2
ML2D1
OL2 MD1D2
S2
MLnD1
• S1-Sn – Enterprise Information
C2 MO1On≡f(ML1D1 , MLnD1) Systems
• OL1-OL2 – Local ontologies
OLn
Sn • OD1,2 – Domain ontologies
Cn • MLiDi – Mappings between local
and domain ontologies
Adding contexts

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

33. Puzzle #4
Which semantics for
interoperability?

35. Framework for semantic enrichment
of reference models
Domain Domain
ontology 1 ontology 2
Mapping Mapping Mapping Application
rules rules rules ontology 1
Unifying model
Semantically Mapping Mapping Mapping Application
enriched model rules rules rules ontology 2
Reference models Impor Sync Reference models
(formats) t tools OWL model tools (native formats)
SCOR-KOS OWL model

36. SCOR-KOS OWL Model
• 418 metrics
elements,
• 166 process
elements,
• 25 process
categories,
• 164 best
practices,
• 282
Input/Output
elements and
• 108 system
elements

37. SCOR-KOS OWL Model
Web app for browsing SCOR-KOS OWL model

38. Web application for browsing the
SCOR model
SCOR-Full ontology

39. SCOR-Full Ontology
• Explication of SCOR-KOS OWL
• Developed by semantic analysis of SCOR-Full
Input/Output elements
SCOR-Full concepts

40. Agent concept
• ∀a (agent(a)) ∃c (course(c)∧ performs(a,c))
• Not functional

41. 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))

42. Setting concept
• provides the
description of
circumstances of a
course
• ∀s (setting(s)) ∃ci
(configured-item(ci)∧
has-realization(s,ci))

43. 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))

44. Function concept
• entails
elements of
the
horizontal
business
organization

45. Resource item
concepts
• Inf-Item defines
the semantics of
the relevant
resource (atomic
concept)
• Conf-Item
describes its
dynamics

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

47. Logical correspondences between
implicit and explicit model
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)
SCOR-Full validated

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

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

50. Formal framework for supply chain
operations
Implicit Explicit Semantic Formal models
semantics semantics enrichment of design goals
Domain
Ontologies
SCOR-KOS OWL
SCOR-FULL OWL SCOR-CFG OWL
SCOR- MAP SCOR-GOAL OWL
PRODUCT OWL
SCOR Native formats,
Exchange formats
Sem interoperability of systems in SC network

51. Semantic interoperability of systems in
supply chain network
Enterprise Implicit Explicit Semantic Formal models Semantic
Information semantics semantics enrichment of design goals applications
Systems
Domain SCOR-SYS OWL
Ontologies
SCOR-KOS OWL
SCOR-FULL OWL SCOR-CFG OWL
SCOR-based
SCOR- MAP
systems SCOR-GOAL OWL
PRODUCT OWL
SCOR Native
formats, Exchange
formats
EIS
LOCAL ONTOLOGY
database
EIS
LOCAL ONTOLOGY
database
EIS
LOCAL ONTOLOGY
database

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

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

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

56. Component view of S-ISU architecture
ONTOLOGY
DomOnt1 Mapping ProbOnt1
}
Local Local Local Ontology
Ontology Ontology Ontology DomOntn ProbOntm
SemApp 1
EIS
Database
Native
formats
Exchange
formats } SemApp n
SQS
ReaS
Listener
Semantic Apps Main Services
EIS
RegSApp
RegS SRS
AuthApp
UTILITY
ReaS SRSApp TrS
Supportive Apps VE formation Services
LOCAL CENTRAL
S-ISU for semantically interoperable systems

57. S-ISU for Semantically interoperable
systems
Enterprise Semantic
Information Implicit Explicit applications
Systems semantics semantics and services
DOMAIN ONT
DOMAIN ONT
DOMAIN ONT
Reconciliation
service
PROB ONT
MAPPING
ONTOLOGY PROB ONT Registration
service Reasoning
service
Native formats,
Exchange
Semantic
formats Query service
EIS
LOCAL ONTOLOGY Listener
database
Transformation
service
EIS LOCAL ONTOLOGY Listener
database

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

60. Database-to-ontology er.owl entity
mapping
hasAttribute
hasConstraint
attribute
Database hasType constraint
hasSourceAttribute
er:entity(x) ∧ not (er:hasAttribute only hasDestinationAttribute
type
(er:attribute ∧ (er:isSourceAttributeOf hasSourceMultiplicity
some er:relation))) ⇒ s-er:concept(x) output
Data import and relatio
er:entity(x) ∧ er:entity(y) ∧ er:relation(r) ∧ classification of ER entities n multiplicity
er:hasAttribute(x, a1) ∧ er:hasAttribute(y,
a2) ∧ er:isDestinationAttributeOf(a2, r) ∧ hasDestinationMultiplicity
er:isSourceAttributeOf(a1, r) ⇒
s-er:hasObjectProperty(x, y) imports
Classification (inference) of output
s-er:hasObjectProperty(x, y) ∧ OWL types and properties
er:hasConstraint(a1,'not-null') ⇒ s-er.owl data-type
s-er:hasDefiningProperty(x, y) hasDataType
er:attribute and not hasDataProperty
Lexical data-concept
(er:isSourceAttributeOf some er:relation) hasFunctionalProperty
⇒ s-er:data-concept Refinement hasDefiningDataProperty
concep
er:type(x) ⇒ s-er:data-type(x) t
hasObjectProperty
s-er:concept(c) ∧ er:attribute(a) ∧ hasDefiningProperty
er:type(t) ∧ er:hasAttribute(c, a) ∧
er:hasType(a, t) ⇒ Local ontology
s-er:hasDataProperty(c, t) generation
s-er:hasDataProperty(c, t) ∧
output
er:hasConstraint(a,'not-null') ∧
er:hasConstraint(a,'unique') ⇒
s-er:hasDefiningDataProperty(c, t)
Query-driven vs massive dump population

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

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

63. Semantic query
hasResCompany some
execution (hasResCurrency some
(hasName value "EUR")
Input Query
)
subject predicate some|only|min n|max m|exactly o bNode
Decomposition subject predicate value {type}
X bNode1 bNode2
hasResCompany hasResCurrency hasName
some bNode1 some bNode2 value "EUR"
SQL construct
and execute
bNode2 nothing ?
Yes
No
SQL construct Assert to
and execute temporary mdl
bNode1 nothing ?
No Yes
SQL construct Assert to
and execute temporary mdl
X nothing ?
No Yes
Assert to End result
temporary mdl graph

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

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

67. Semantic interoperability framework
revisited
Enterprise Implicit Explicit Semantic Formal models Semantic
Information semantics semantics enrichment of design goals applications
Systems
SCOR-FULL OWL
SCOR- MAP
SCOR-CFG OWL
OpenERP OpenERP
database LOCAL ONTOLOGY
Web application for SCOR process configuration

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

69. SCOR – CFG OWL, Example of
application ontology
• Design goal –
Generation of
SCOR thread
diagrams
SCOR thread diagram for manufacturing of custom implants

70. SCOR thread diagram for
manufacturing custom implants
Interoperability requirements (inferred)

71. Interoperability requirements
(inferred from SCOR-KOS OWL)
OpenERP ontology

72. OpenERP ontology
• 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

73. Fragment of UML
representation of OpenERP
local ontology
Querying OpenERP

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

75. Result of query execution

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

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

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

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

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

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

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

84. 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;

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

86. Thank you for your attention
Q&A
Milan Zdravković
PhD Defense