Ontology-Based Systems Federation


Published on

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

Published in: Technology, Education
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Ontology-Based Systems Federation

  1. 1. Ontology-based Systems Federation Ontology Summit 2-feb-2012
  2. 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. 3. Interoperability of autonomous cyborgs • Data • Execution flow • Energy people people • Mass software software hardware hardware Multi-level interoperability 3
  4. 4. Contemporary “corporate cyborg” information systemActions 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. 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. 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 tofederate/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. 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. 8. Main problems:Absence of reference data (domain ontologies)Most of needed reference data is locked in non-structured texts (likeindustrial standards) and propietary legacy systems (need to be extractedbefore federation can happens).Configuration management “federation style”Nobody knows how to manage/evolve/maintainfederated megaontology, megamodel(*), megaprogramExecution “federation style”What to do when you have multiple BPMN engines, adaptive case managementsystems, several different SOA frameworks, issue trackers and documentmanagement systems, project management systems and otherproject/process/issue/case-related “engines”.(*) Term suggested by INRIA AtlanMod 8
  9. 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-learntools. 9
  10. 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. 11. Product knowledge pyramid (ISO 15926) 201 type: ontological commitmentsEnterprise-related (shared reality) ISO 15926data excluded only typesto 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. 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. 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 data1 ISO 15926 Rule ISO 15926 2circle radius radius*2 diameter окружность 13
  14. 14. Knowledge warehouses view (ISO 15926) multiple levels of systems integration/federation POSC Caesar Association/FIATECH Enterprise 1 JORD Global RDLRDL PLM ERP CAD CAM Enterprise 2 RDL PLM ERP CAD CAM 14
  15. 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. 16. Questions?Anatoly Levenchuk,ailev@asmp.msk.suVictor Agroskin,vic5784@gmail.comTechInvestLab.ru+7 (495) 748-53-88 16