Ontology-Based Systems Federation
Download as PPTX, PDF2 likes4,128 views
The document discusses ontology-based systems federation. It describes how systems integration involves agreeing on standards for networks and interoperability. The challenges of federation at both small and large scales are discussed. There is a need for unifying ontologizing, modeling and programming approaches. The main problems are the absence of reference domain ontologies and how to manage evolving federated models and programs. ISO 15926 is presented as a case study for a federated product knowledge pyramid and conceptual mapping between systems.
![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](https://image.slidesharecdn.com/ontologysummit31march12-120301034540-phpapp01/85/Ontology-Based-Systems-Federation-6-320.jpg)
Ontology-Based Systems Federation
- 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