Joint Doctrine Ontology

Slides:



Advertisements
Similar presentations
Introduction to Product Family Engineering. 11 Oct 2002 Ver 2.0 ©Copyright 2002 Vortex System Concepts 2 Product Family Engineering Overview Project Engineering.
Advertisements

DoDAF V2.0 Community Update Overview
C2 Integration Division Marine Corps Combat Development Command
VIRGINIA MILITARY INSTITUTE NCO ACADEMY
IS 700.a NIMS An Introduction. The NIMS Mandate HSPD-5 requires all Federal departments and agencies to: Adopt and use NIMS in incident management programs.
DoD Architecture Framework Overview
Session 6 Integrated Emergency Management. Objectives of the Session Students will be able to 6.1 Define the principle of integration. 6.2Discuss the.
Systems Engineering in a System of Systems Context
OASIS Reference Model for Service Oriented Architecture 1.0
Universal Core Semantic Layer (UCore SL) An Ontology-Based Supporting Layer for UCore 2.0 Presenter: Barry Smith National Center for Ontological Research.
Elements of Planning and Decision-Making
Copyright 2012 Delmar, a part of Cengage Learning. All Rights Reserved. Chapter 13 Health Information Systems and Strategy.
Systems Engineering Foundations of Software Systems Integration Peter Denno, Allison Barnard Feeney Manufacturing Engineering Laboratory National Institute.
Understanding Multiagency Coordination IS-701.A – February 2010 Visual 2.1 Unit 2: Understanding Multiagency Coordination.
KM enhances mission command, facilitates the exchange of knowledge, supports doctrine development, fosters leaders’ development, supports lessons learned,
SEABEE COMBAT WARFARE NCF OFFICER SPECIFIC
Army Doctrine Publication (ADP) 3-37; and Army
Enterprise Architecture
Incident Command System (ICS)
Civilian Human Resources Management  Military Health Systems  Military and Other Human Resources Management Department of Defense – Human Resources Management.
Tne Role of Ontologies in Military Collaboration Barry Smith 1.
Chapter 2 The process Process, Methods, and Tools
Engineering, Operations & Technology | Information TechnologyAPEX | 1 Copyright © 2009 Boeing. All rights reserved. Architecture Concept UG D- DOC UG D-
DoD Acquisition Domain (Sourcing) (DADS) Analysis of Alternatives (AoA) E-Business/SPS Joint Users’ Conference November 15-19, 2004 Houston, TX.
Michalis Adamantiadis Transport Policy Adviser, SSATP SSATP Capacity Development Strategy Annual Meeting, December 2012.
High Level Architecture Overview and Rules Thanks to: Dr. Judith Dahmann, and others from: Defense Modeling and Simulation Office phone: (703)
Army Net-Centric Data Strategy Center Of Excellence (ANCDS) Army Data Harmonization and Integration Working Group (ADHIWG) Sever Ciorlian ANCDS Team Lead.
IEEE SCC41 PARs Dr. Rashid A. Saeed. 2 SCC41 Standards Project Acceptance Criteria 1. Broad market application  Each SCC41 (P1900 series) standard shall.
CSC-532 Term Paper INTEROPERABILITY MODELS Hitesh Nagda.
Visual 7.1 Course Summary Unit 7: Course Summary.
Radar Open Systems Architectures
Lecture 7: Requirements Engineering
1 Introduction to Software Engineering Lecture 1.
Creating a European entity Management Architecture for eGovernment CUB - corvinus.hu Id Réka Vas
Center of Excellence PEACE OPERATIONS ROLE OF THE MILITARY IN UN OPERATIONS IN UN OPERATIONS Col (Ret) Peter Leentjes Center of Excellence in Disaster.
Defense Information Systems Agency A Combat Support Agency E3 Engineering Division 13 December 2011 Defense Information Systems Agency A Combat Support.
1 ECCF Training 2.0 Introduction ECCF Training Working Group January 2011.
1 Joint Doctrine: The Authoritative Vocabulary For and Explanation of Joint Warfare and Joint Operations October 16, 2015 Representing Reality\Big Data\Big.
Center of Excellence PEACE OPERATIONS ROLE OF THE MILITARY IN UN OPERATIONS IN UN OPERATIONS Col (Retd) Mike Morrison.
BEA Orientation November 13, 2007
© The ATHENA Consortium. CI3 - Practices of Interoperability in SMEs Proposed Solutions.
SE513 Software Quality Assurance Lecture12: Software Reliability and Quality Management Standards.
NATIONAL INCIDENT MANAGEMENT SYSTEM Department of Homeland Security Executive Office of Public Safety.
US European Command UNCLASSIFIED UNCLASSIFIED UNCLASSIFIED This briefing is UNCLASSIFIED Stronger Together JOINT STAFF J7 / WJTSC 10-1 Training to Integrated.
Joint Doctrine What it is. What it means.. Objectives Review the history and structure of DoD Review some elements of Joint Doctrine.
Models of the OASIS SOA Reference Architecture Foundation Ken Laskey Chair, SOA Reference Model Technical Committee 20 March 2013.
Ontology in MBSE How ontologies fit into MBSE The benefits and challenges.
Basic Concepts Key Learning Points : The objectives of this chapter are as follows:  To provide an introduction to the basic Concepts of enterprise architectures,
Enterprise Architectures Course Code : CPIS-352 King Abdul Aziz University, Jeddah Saudi Arabia.
Environment, Safety, and Occupational Health Opportunities in DoD Business Transformation May 4, 2006.
Coordinated Holistic Alignment of Manufacturing Processes (CHAMP) University at Buffalo National Center for Ontological Research Barry Smith (PI) Department.
Overview MRD Enterprise MRD Process
Current Event Brief!.
Discussion Topics for Exploring OMG UPDM Way-ahead
DoDAF 2 Was Designed to Support DoD’s 6 Core Processes
Why KM is Important KM enhances mission command, facilitates the exchange of knowledge, supports doctrine development, fosters leaders’ development, supports.
Defense Information Systems Agency A Combat Support Agency
DATA VERTICAL Technical Exchange
NDIA Architecture Analysis for System-of-System (SoS) Interoperability Assessment Karen L. Lauro, Ph.D Oct 21, 2003.
Architecture Tool Vendor’s Day
Department of the Army.
XMSF and Command & Control - GIG, XBML/C4I Testbed, XDV, XMSF Profiles
DoDAF 2.x Meta Model (DM2) Conceptual Level
Public Health Department Fakultas Kedokteran Universitas Padjadjaran
The Cadet Leader Development System
DoD Architecture Framework Overview
Systems Architecture & Design Lecture 3 Architecture Frameworks
The Geospatial Intelligence Standards Working Group -GWG-
Systems Architecture & Design Lecture 1 Introduction
Subject Name: SOFTWARE ENGINEERING Subject Code:10IS51
Presentation transcript:

Joint Doctrine Ontology Barry Smith National Center for Ontological Research with thanks to Peter Morosoff December 7, 2015

What is Joint Doctine for? To achieve joint action Initially joint action = action involving live forces from more than one Service Increasingly joint action = action involving not only life forces but also automatic systems

Joint action requires interoperability of people and information systems Interoperability = def. The ability of systems, units, or forces to provide data, information, materiel, and services to, and accept the same from, other systems, units, or forces, and to use the data, information, materiel, and services exchanged to enable them to operate effectively together. DoD Instruction 8330.01

How is interoperability to be achieved? DoD Instruction (DoDI) 8330.01: By adherence to standards listed in the DoD IT Standards Registry (DISR).

DISR: Sample Terms from https://acc.dau.mil/CommunityBrowser.aspx?id=220108&lang=en-US) – an example of one such standard Architecture  Integrated Architecture  Enterprise Architecture Naval Open Architecture Open Architecture (twice) Open System Architecture   Software Architecture  System Architecture  https://acc.dau.mil/CommunityBrowser.aspx?id=22108&lang=en-US

How does do it? Sample Terms Architecture  [Institute of Electrical and Electronics Engineers (IEEE) Std 1471-2000] Integrated Architecture [DoDAF] Enterprise Architecture [Virginia Information Technologies Agency] Naval Open Architecture [RhumbLines, December 12, 2006, Naval Office of Information] Open Architecture [ITtoolbox]. Open System Architecture [A Modular Open Systems Approach (MOSA) to Acquisition, OSJTF] Software Architecture [IEEE] System Architecture [IEEE 1220-1998] https://acc.dau.mil/CommunityBrowser.aspx?id=22108&lang=en-US

How does do it? Architecture = the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution. [Institute of Electrical and Electronics Engineers (IEEE) Std 1471-2000] Integrated Architecture = multiple views or perspectives (Operational View (OV), Systems View (SV), Technical Standards View (TV) and All View (AV)) that facilitate integration and promote interoperability across capabilities and among related integrated architectures. [DoDAF] “System Architecture” = the composite of the design architectures for products and their life cycle processes. [IEEE 1220-1998] Open System Architecture = a system that employs modular design, uses widely supported and consensus based standards for its key interfaces, and has been subjected to successful validation and verification tests to ensure the openness of its key interfaces. [A Modular Open Systems Approach (MOSA) to Acquisition, OSJTF] https://acc.dau.mil/CommunityBrowser.aspx?id=22108&lang=en-US

How to do it right Define Architecture Define Integrated Architecture as: An Architecture which [is integrated …] Define System Architecture as: An Architecture of a System Define Open Systems Architecture as: A Systems Architecture [which is open …] Thereby reaping the benefits of cumulativity

… yielding taxonomical part of an ontology Architecture Integrated Architecture … System Architecture Open Systems Architecture

What is the alternative? Where can we find an authoritative, coherently and diligently authored dictionary of terms and definitions covering all aspects of military endeavor, organization and (increasingly) IT system?

JP 1-02

How can we make the definitions of JP 1-02 serve as a benchmark of interoperability for military (IT) systems? DoD requires that joint doctrine addresses the need for IT interoperability. DoD does not require – and has no effective strategy to ensure – that the IT procedures themselves address the need for conformity with joint doctrine. But such conformity is indispensable for unified action involving human warfighters and IT systems and it would also bring benefits to military IT systems, including the Joint Doctrine Development System itself

Goal of Joint Doctrine Ontology to provide a computationally accessible counterpart (shadow, mirror) of the content of JP 1-02 in order to allow joint information systems to be not merely terminologically consistent but also interoperable with joint doctrine.

The role of general categories JP 1-02 defines the standard US military and associated terminology to encompass the joint activity of the Armed Forces of the United States. These military and associated terms, together with their definitions, constitute approved Department of Defense (DOD) terminology for general use by all DOD components. (JP 1-02, Preface signed by Vice Admiral William E. Gortney, Director of the Joint Staff)

Importance of categories (Peter Morosoff) The purpose of military doctrine is to facilitate commanders and other warfighters in understanding the realities of war and their specific situations and then in accomplishing their missions. It achieves these ends largely through the identification and explanation of important general categories rather than of specific instances (such as a particular aircraft or IT system). Doctrine is in this sense re-usable; it is applicable to many different instances and to many different subkinds of the same general categories. This approach is effective because the basic realities of war are not changed by the fielding of new commanders, equipment, specialties, or tactics.

Common Core and Domain Ontologies Basic Formal Ontology (BFO) Upper Ontology: Common Core Ontology: Extended Relation Ontology Domain Ontology: Event Ontology Agent Ontology Quality Ontology Artifact Ontology Geospatial Ontology Time Ontology Ethnicity Ontology Hydrographic Feature Ontology Information Entity Ontology Curriculum Ontology Occupation Ontology Physiographic Feature Ontology Currency Unit Ontology Citizenship Ontology Units of Measure Ontology Emotion Ontology Space Objects Ontology Sensor Ontology Watercraft Ontology Agent Information Ontology

Fragment Blue = BFO + Common Core Ontologies Green = JP 1-02

Joint Doctrine Ontology will use the language of joint doctrine JDO is in effect a shadow of JP 1-02, incrementally adding definitional enhancements and further elements of logical regimentation, but in such a way that the ontology and the dictionary which underlies it remain synchronized with each other through each successive revision of joint doctrine.

Joint Doctrine is authoritative if conflicts arise between it and Service doctrine, then the former – absent more current and specific guidance from the Chairman of the Joint Chiefs of Staff – will take precedence. that it is to be followed except when, in the judgment of the commander, exceptional circumstances dictate otherwise.

Joint Doctrine is logically authoritative 3. Terms used in Army doctrine to refer to Army- specific categories defined should be defined as subcategories of the corresponding Joint Doctrine category

Doctrine is authoritative during real warfighting Doctrine provides what we can think of as a common mental model – a shared frame of reference – which remains active through every phase of every military engagement. Doctrine provides the principles which determine how to understand the authorized command relationships and the authority that military commanders can use. It establishes common ways of accomplishing military tasks and facilitates readiness by promoting coordination in all aspects of training and planning.

Examples of gaps in JP 1-02 action agent authority commander geographical area geopolitical entity nation national organization order organization territory training

Official definition-writing Manual for JP 1-02 says that definitions for these terms should be derived from Webster’s Dictionary This sometimes leads to circularity Webster’s definitions are often inappropriate for DoD purposes Many of these terms are already contained within CCO with formal definitions. Remainder will be added

Terms like these will be added to the shadow and will be proposed for addition to JP 1-02 Not all terms in the shadow need be proposed for addition to JP 1-02 Some terms are available already in CCO Some terms will be added to CCO

Step 1 for creating JDO as JP 1-02 shadow Fill gaps with logically well-formed definitions tying JP 1-02 to Common Core Ontologies

Step 2 for creating JP 1-02 shadow Remove logical errors in existing definitions (for example in definitions which confuse the entity you are defining with the term used to represent that entity): operational area — An overarching term encompassing more descriptive terms (such as area of responsibility and joint operations area) for geographic areas in which military operations are conducted.

Step 3 for creating JP 1-02 shadow Ensure that each term has exactly one definition

Disambiguate those terms in JP 1-02 which have multiple definitions command — 1. The authority that a commander in the armed forces lawfully exercises over subordinates by virtue of rank or assignment. 2. An order given by a commander; that is, the will of the commander expressed for the purpose of bringing about a particular action. 3. A unit or units, an organization, or an area under the command of one individual.

by replacing one term with multiple terms making the distinctions explicit command authority commander’s order (expressing the will of the commander) command unit

Uses of JDO Better definitions Better Command and Control (C2) Netcentricity – discovery of data Outcomes research Facilitating DoD IT interoperability Facilitating unified action among IT developers. today, even the best-intentioned IT developers must make assumptions on whether a warfighting term in a specification that is not listed in joint doctrine is valid as it is or has been superseded by more a current term

http://ncor.buffalo.edu/2015/STIDS-JDO.pdf