View
383
Download
1
Category
Tags:
Preview:
DESCRIPTION
Milan Zdravković, PhD Defense, 9.10.2012, Faculty of Mechanical Engineering in Niš, University of Niš
Citation preview
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?
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
Recommended