Presentation at Systems Federation and Integration 1st of March session of Ontology Summit 2012

1. Ontology-based Systems Federation
Ontology Summit
2-feb-2012

2. Terminology
• Systems Federation (bus) – kind of network with
interoperability
• Systems Integration (plug-ins)
• WIKIPEDIA: A Federation is multiple computing and/or
network providers agreeing upon standards of
operation in a collective fashion. … In networking
systems, to be federated means users are able to send
messages from one network to the other. This is not
the same as having a client that can operate with both
networks, but interacts with both independently.
2

3. Interoperability of autonomous cyborgs
• Data
• Execution flow
• Energy
people people
• Mass
software software
hardware hardware
Multi-level
interoperability
3

4. Contemporary “corporate cyborg”
information system
Actions Enabling system Actions Enabling system
(enterprise) (enterprise)
System/service-of- System/service-of-
interest interest
(structure & behavior) (structure & behavior)
Systems/services in Systems/services in
operation environment • Data operation environment
• Execution flow
Multi-model
interoperability

5. *-in-the-large (network)
• Ontologizing == modeling == programming
(stems from philosophy logic: formal semantics and pragmatics in relation to real world)
• Ontologizing-in-the-small vs. ontologizing-in-the-large ==
Programming-in-the-small vs programming-in-the-large ==
Modeling-in-the-small vs modeling-in-the-large
(problems and patterns/methods are different at “small” and “large” scales)
• Systems Integration and Federation == “*-in-the-large”
-------------------------------------------
Urgent Needs (work with programmers and engineers):
• Unification of ontologizing, modeling, programming (neutral
ontology for this on a base of philosophical logic)
• Cross-pollinate (developing of “approaches”) of methods *-
in-the-large when appropiate. Programming is leading now.
5

6. Systems or services?
ISO 15288: service of system-of-interest!
• Functional object (system component, slot) vs physical object
(structure, module)
• Service (behavior) vs function vs process (cyberphysics)
In “systems federation/integration” nobody know what to
federate/integrate and how to describe it!
----------------------------------------
Urgent Need (work with systems engineers):
• Ontology for Systems domain (with components, structures,
services, types of systems, life cycle, stakeholders, etc.).
• Architectural language for Systems domain (notation for Ontology
for Systems Domain). [think of ontology-enhanced ArchiMate for
not only Enable systems (enterpises)]
6

7. Beyond upper Systems ontology
(IMHO)
• Product life cycle models – ISO 15926 is a champion!
• Simulation (muli-physics) models – Simantics is a
champion!
• Enterprise models – BORO + ArchiMate + Adaptive Case
Management (ACM) + situational method engineering (SME) + SBVR
• Regulations, standards, past project reports – natural language
processing with diagrams/drawings parsing.
Urgent needs: give me all of them!
7

8. Main problems:
Absence of reference data (domain ontologies)
Most of needed reference data is locked in non-structured texts (like
industrial standards) and propietary legacy systems (need to be extracted
before federation can happens).
Configuration management “federation style”
Nobody knows how to manage/evolve/maintain
federated megaontology, megamodel(*), megaprogram
Execution “federation style”
What to do when you have multiple BPMN engines, adaptive case management
systems, several different SOA frameworks, issue trackers and document
management systems, project management systems and other
project/process/issue/case-related “engines”.
(*) Term suggested by INRIA AtlanMod
8

9. Federation Education
• We have bad experience of work with IT
people and capital project engineers: all they
expect 3 day courses should fit for ontology-
based data integration.
• How to teach people for mega-ontologizing in
3 days? Not mention of mega-execution.
Urgent needs: didactic aids and easy-to-learn
tools.
9

10. Case study: systems federation
with ISO 15926
• Goal: eco-system federation (beyond enterprise and
industry boundary)
• Reference federation architecture
• Prescribed counterintuitive ontological commitments (Part
2)
• Prescribed data modeling languages (low level semantic
network, mid level “temlates”, high level OIMs)
• Federated domain vocabulary/taxonomy/ontology to
choose that you trusted
• Usage of federated ontology for systems federation
(federated^2)
• Not a good choice (IMHO): semantic web file format for
data representation
10

11. Product knowledge pyramid (ISO 15926)
201 type: ontological commitments
Enterprise-related (shared reality)
ISO 15926
data excluded only types
to clarity of a slide. Huge! Needs
R
RDL D
federation of
multiple sources!
L
But: one format
Catalogue
(standard classes)
Product lines
P
and project r
o
Debug, change management
d
u
c Needs federation
t even more!
Product configuration
baselines d Multiple formats
a
Historic data (product operations time t
rows) a
11

12. Federated product knowledge pyramid (ISO 15926)
ISO/JORD
Global
RDL
National standard body
National
standards RDL
Industry standards
RDL
Standardization consortium
RDL of catalogue
Catalogue product data
Product RDL Catalogue vendor
Product data
Engineering enterprise 12

13. Conceptual mapping (ISO 15926)
mapping mapping
Product data
ISO 15926
Product data
model RDL model
(ontology) federation (ontology)
ISO 15926
Outside
Product data Product data
1 ISO 15926 Rule ISO 15926 2
circle radius radius*2 diameter окружность
13

14. Knowledge warehouses view (ISO 15926)
multiple levels of systems integration/federation
POSC Caesar Association/FIATECH
Enterprise 1
JORD Global RDL
RDL PLM ERP
CAD CAM
Enterprise 2
RDL PLM ERP
CAD CAM
14

15. JORD experience (ISO 15926)
• Namespaces: headache (“fast track” concept
promotion to higher level RDL – moving concepts)!
• OWL/RDF as a transport language: not enough!
• Granularity: domain units, configuration units!
• Multiple languages (network, templates, OIMs)
• Federation administration (Systems of Systems:
centralized development impossible, only
asynchronous systems evolution)
• Multiple partial compatible implementations
(“browser wars”)
• …
15

16. Questions?
Anatoly Levenchuk,
ailev@asmp.msk.su
Victor Agroskin,
vic5784@gmail.com
TechInvestLab.ru
+7 (495) 748-53-88
16