=Paper=
{{Paper
|id=Vol-1523/STIDS_2015_T01_Morosoff_etal
|storemode=property
|title=Joint Doctrine Ontology: A Benchmark for Military Information Systems Interoperability
|pdfUrl=https://ceur-ws.org/Vol-1523/STIDS_2015_T01_Morosoff_etal.pdf
|volume=Vol-1523
|dblpUrl=https://dblp.org/rec/conf/stids/MorosoffRBFS15
}}
==Joint Doctrine Ontology: A Benchmark for Military Information Systems Interoperability==
https://ceur-ws.org/Vol-1523/STIDS_2015_T01_Morosoff_etal.pdf
Approved for Public Release; Distribution Unlimited: 88ABW-2015-2881, 08 Jun 2015
Joint Doctrine Ontology: A Benchmark for Military
Information Systems Interoperability
Peter Morosoff Ron Rudnicki Jason Bryant Robert Farrell Barry Smith
E-Maps, Inc., CUBRC Air Force Research Lab Air Force Research Lab University at Buffalo
Fairfax, VA Buffalo, NY Rome, NY Rome, NY Buffalo, NY
peter.morosoff@e-mapsys.com rudnicki@cubrc.org jason.bryant.8@us.af.mil robert.farrell.10@us.af.mil phismith@buffalo.edu
Abstract—When the U.S. conducts warfare, elements of a critical, if we are to prevent higher-level flaws cascading to
force are drawn from different Services and work together as domain-level doctrinal errors, that the terms of joint doctrine
a single team to accomplish an assigned mission on the basis of be defined correctly.
joint doctrine. To achieve such unified action, it is necessary
that specific Service doctrines be both consistent with and It is commonly supposed that doctrine provides not hard
subservient to joint doctrine. But there are two further and fast rules but rather merely a loose and always revisable
requirements that flow from the ways in which unified action guide to action that is typically abandoned on first contact
increasingly involves not only live forces but also automated with the enemy. Doctrine is however authoritative also in
systems. First, the information technology that is used in joint the sense that it is to be followed in all cases except when, in
warfare must be aligned with joint doctrine. Second, the the judgment of the commander, exceptional circumstances
separate information systems used by the different elements of dictate otherwise. Moreover, there are many doctrinally
a joint force must be interoperable, in the sense that data and acknowledged features of military action that survive
information that is generated by each element must be usable through every engagement. Doctrine defines the shared
(understandable, processable) by all the other elements that frame of reference that remains active through every phase
need them. Currently, such interoperability is impeded by of every military engagement. This is because doctrine
multiple inconsistencies among the different data and software provides the principles that determine how to understand the
standards used by warfighters. We describe here the on-going
authorized command relationships and the authority that
project of creating a Joint Doctrine Ontology (JDO), which
military commanders can use. It establishes common ways
uses joint doctrine to provide shared computer-accessible
content valid for any field of military endeavor, organization,
of accomplishing military tasks and facilitates readiness by
and information system. JDO addresses the two previously- promoting coordination of training and planning. Most
mentioned requirements of unified action by providing a importantly for our purposes here, doctrine provides a
widely applicable benchmark for use by developers of common lexicon – a set of precise terms and precise
information systems that will both guarantee alignment with definitions – expressed in a language that is designed to
joint doctrine and support interoperability. enable consistent understanding by military leaders,
planners and educators. Doctrine thereby enables the sort of
Keywords—joint doctrine, military doctrine, ontology, Basic effective communication among warfighters that is needed
Formal Ontology (BFO), Common Core Ontologies (CCO), joint for unified action.
warfare, unified operations, interoperability, terminology,
definition II. BATTLE MANAGEMENT LANGUAGE (BML)
While doctrine has been developed and used thus far to
I. JOINT DOCTRINE satisfy the needs of human beings, it is increasingly
The publications of joint doctrine document fundamental understood that it must also satisfy requirements that come
principles and overarching guidance for the employment of into play when information systems are brought to bear in
the Armed Forces of the United States [1]. Joint doctrine military action. The language used by warfighters and
applies to all military, from the joint staff to commanders of codified in field manuals and doctrinal lexica still involves
combatant commands, their supporting commands, and to some of the ambiguities characteristic of all languages used
the individual Services, each of which has its own Service- by human beings. But such ambiguities can be tolerated
specific doctrinal publications. Joint doctrine is authoritative where human beings are involved because humans can
in the sense that, if conflicts arise between it and Service easily disambiguate the meanings of ambiguous terms in
doctrine, then the former – absent more current and specific everyday contexts of use.
guidance from the Chairman of the Joint Chiefs of Staff – The very human-friendliness of the language used by
will take precedence. warfighters brings an equal and opposite weakness,
Joint doctrine provides the benchmark for interoper- however, when information systems are involved.
ability of the separate Service doctrines. And because all Computers have difficulties in interpreting the common
Service-level terminology is dependent on joint doctrine it is language of human beings and in using contextual cues to
resolve ambiguities. Attempts to overcome these difficulties
STIDS 2015 Proceedings Page 2
led in around 2000 to the conception of the Battle logical content of the separate Joint Publications from
Management Language (BML) [2] that was designed to which the terms and definitions of JP 1-02 are derived.
allow the description of a commander’s intent in the sort of
context-free way that would support processing by The Dictionary defines the standard U.S. military and
automated systems. The initial goal of BML was to create a associated terminology needed to enable the joint activity of
unified and unambiguous representation of command and the Armed Forces of the United States. As stated in the
control (C2) doctrine as a ‘systematic data model’ [2]. BML Preface signed by Vice Admiral William E. Gortney,
was seen as thereby providing a unified framework that Director of the Joint Staff, these military and associated
would not only remove ambiguities but also rectify the terms, together with their definitions, constitute approved
terminological disunities created through the continued Department of Defense (DOD) terminology for general use
dominance of disparate Service cultures and of the by all DOD components. [7]
numerous communities of interest within those cultures [3]. In multiple other joint publications, as well as in a series
of DoD and Chairman of the Joint Chiefs of Staff
III. INTEROPERABILITY instructions, it is required that all DoD initiatives, as well as
BML continues as an active project [4]-[5], especially in all warfighters and warfighting organizations, should use a
the modeling and simulation community. The promised common terminology. In addition, instructions state that all
unambiguous representation of the content of C2 doctrine IT intended for use in military operations should be
using BML has, however, not been achieved. Here, we take designed from the beginning to be interoperable (paragraph
up once again the idea of formalizing joint doctrine by 9b of Chapter 2, “Doctrine Governing Unified Direction of
drawing on more recent developments in the field of Armed Forces,” JP 1 [1]). We believe that it follows from
ontology. Our target, however, is more modest. It is not to these instructions that all DoD IT efforts, insofar as they are
provide the resources to capture formally a commander’s intended for use in military operations, should be developed
intent. Rather, we seek to capture in a computer-usable in such a way as to be interoperable with joint doctrine.
form the terminological content of joint doctrine in a way
that will support the sort of interoperability that is needed IV. FAILURES OF INTEROPERABILITY AND REQUIREMENT FOR
where live forces need to engage in unified action with EFFECTIVE GUIDANCE TO IT DEVELOPERS IN THE FUTURE
information systems.
The need for interoperability of DoD information
Interoperability is defined in the Glossary of DoD systems and for alignment of the data and information that
Instruction (DoDI) 8330.01 [6] as: enables military action has been recognized repeatedly and
The ability of systems, units, or forces to provide data, information, at the highest levels, and given today’s and tomorrow’s
materiel, and services to, and accept the same from, other systems, flood of digital data across networks this need is becoming
units, or forces, and to use the data, information, materiel, and ever more apparent.
services exchanged to enable them to operate effectively together. IT
interoperability includes both the technical exchange of information For example, DoDI 8320.02, “Sharing Data,
and the end-to-end operational effectiveness of that exchange of
Information, and Information Technology (IT) Services in
information as required for mission accomplishment.
the Department of Defense” [8] requires that authoritative
Our hypothesis is that the creation of a Joint Doctrine data sources (ADSs) be ‘registered in the DoD Data
Ontology (JDO) can provide a widely applicable Services Environment (DSE).’
benchmark for use by developers of information systems
The DoDI directs further that ‘Data, information, and IT
that will support rather than impede unified action by
services will be made … interoperable throughout their
breaking down existing terminological silos of different
lifecycles for all authorized users’. However, the instruction
Services and communities of interest. to achieve such interoperability – namely through
In contrast to the BML, our alternative approach ‘enforcement of policy for DoD metadata that uses
begins, not with defining a new language, but rather with Government and industry metadata standards’ – repeatedly
the existing authoritative controlled vocabulary that is fails in its goal. This is not only because the policy is
defined in Joint Publication 1-02, the Department of formulated in a way that falls short of the required
Defense Dictionary of Military and Associated Terms [7]. specificity, but also because, even where relevant standards
exist, they have in almost all cases been created ad hoc, to
The JP 1-02 dictionary consists in its current version of address specific local needs. Thus they have not been built
some 2,803 terms drawn from some 81 approved doctrinal in the sort of coordinated, rule-governed way that would be
publications forming the Joint Doctrine Hierarchy (at needed to achieve interoperability.
http://www.dtic.mil/doctrine/doctrine/status.pdf). In effect,
The problem of overly weak requirements is illustrated
we are constructing JDO as a shadow of JP 1-02,
also in the already mentioned DoDI 8330.01 on
incrementally adding definitional enhancements and fur-
“Interoperability” [6], where it is stated that the information
ther elements of logical regimentation, but in such a way systems that DoD components use
that the ontology, and the dictionary that underlies it, re-
main synchronized with each other through future revisions must interoperate, to the maximum extent practicable, with
of joint doctrine. In effect, JDO will provide a semantic existing and planned systems (including applications) and
equipment of joint, combined, and coalition forces, other
enhancement of JP 1-02, and therefore also of the termino- U.S. Government departments and agencies, and non-
STIDS 2015 Proceedings Page 3
governmental organizations, as required based on the conformity with joint doctrine. We believe, however, that
operational context (italics added). such conformity is not only indispensable if unified action
Because everything is by definition interoperable to ‘the between human warfighters and IT systems is to be
maximum extent practicable,’ this instruction is without achieved, but further that it would bring multiple significant
teeth. benefits to military IT systems themselves, and thus also to
the developers of such systems, because it would provide a
DoDI 8320.02 suggests a further route to the benchmark for interoperability.
achievement of interoperability through adherence to
standards listed in the DoD IT Standards Registry (DISR). VI. UNIFIED ACTION OF HUMAN WARFIGHTERS AND
Unfortunately, it is difficult to determine the degree of INFORMATION SYSTEMS
interoperability of DISR standards, in part because the JP 1, the Capstone Publication of Joint Doctrine [1],
needed assessment must be applied simultaneously to the states that unified action demands ‘maximum
different portions of the DISR, and these often require interoperability’:
different sorts of permissions (and thus, we assume, are
accessible only to different sorts of people). Some of the The forces, units, and systems of all Services must operate
resources contributed to the DISR that we were able to together effectively, in part through interoperability. This
access, however, do not manifest – even when taken singly includes joint force development; use of joint doctrine; the
– the sort of minimal terminological consistency or formal development and use of joint plans and orders; and the
regimentation that would be needed to meet the demands of development and use of joint and/or interoperable
communications and information systems (italics added).
interoperability. The terminology defined in [9], for examp-
le, was created by selecting terms and definitions from a Because a military organization includes its information
wide range of sources. No common rules for definitions systems, we believe that building the common language
were employed, and so there is no way of checking even for provided by doctrine into the information systems that will
simple logical consistency of the resulting artifact. be used by warfighters is a vital need.
Achieving interoperability – both terminological and The DoD Manual (DoDM) 5120.01, “Joint Doctrine
structural [10] – is of course difficult for a large organization Development Process” [17], provides the guidance that
like the DoD with a cumbrous history of information system steers DoD to consistent terminology across the joint
development. However, in recent years a number of best publications governing different types of operational
practices for meeting the demands of inoperability have domains. Developers of doctrine are required to ‘use, to the
been established, some of them very simple to implement. greatest extent possible, previously approved terminology
Thus a first task would be to establish corresponding simple contained in the text of other JPs or in … JP 1-02.’ An
rules that must be satisfied by IT systems developed by the information system needs more than well-trained and
DoD in the future. We are concerned here only with issues qualified people and high-quality equipment to provide
of terminological interoperability, which we propose should effective support to unified action. It must be supported also
be addressed through the creation of a benchmark ontology by effective guiding principles and procedures rooted in an
framework centered around the JDO. We envisage that the understanding of the requirements of unified action. Our
complementary structural interoperability might be tackled proposal is that such support can be achieved in today’s
in part through the deployment of W3C standard resources networked environment by extending the same guidance that
such as RDF and the Web Ontology Language (OWL) [11]. is provided to doctrine developers also to IT developers.
The formulation of ontologies using OWL, in particular, Those engaged in developing IT systems for military
would allow computational reasoners to be used in a way operations should be required to take the terminology and
that provides automatic checking for consistency of definitions of joint doctrine as their starting point.
definitions with each new revision of a terminological Increasingly, if this proposal is adopted, doctrine developers
artifact such as JP 1-02. The ontology approach can thereby will come to be seen as constituting the first rank of
support agile development and coordinated maintenance of information technologists, providing the core terminological
information systems in a way that does not sacrifice content on which all DoD IT content will rest.
terminological interoperability [12]–[16].
VII. RULES FOR DEFINITIONS IN INSTRUCTION 5705.01D
V. THE SOLUTION
To see how JDO will be constructed, we need first to
DoDI 8330.01 [6] already requires that the content of understand some of the features of the Dictionary from
joint operational concepts, and associated doctrine and which it will be derived. The idea for such a dictionary is
operational procedures, address interoperability of the IT expressed in DoDI 5025.12 of August 2009 [18], which
used by the separate Services and also, where required, by states that it is DoD policy to improve communications and
joint and multinational forces and other U.S. government mutual understanding within the DoD, with other Federal
departments and agencies. Agencies, and between the United States and its
While DoD thus requires that joint doctrine addresses international partners through the standardization of military
the need for IT interoperability, it crucially does not require and associated terminology.
– and has no effective strategy to ensure – that the IT This position is restated in the Chairman of the Joint
systems and procedures themselves address the need for Chiefs of Staff Instruction (CJCSI) 5705.01D of November
STIDS 2015 Proceedings Page 4
10, 2010 on the creation of a “Standardization of Military Avoiding these and other types of errors would not only
and Associated Terminology.” [19] Specifically, the Chief make JP 1-02 more valuable to human users; it would also
of the Joint Education and Doctrine Division (JEDD), J-7, enable the construction of the formal representations of its
shall oversee the DoD Terminology Program and U.S. content of the sort that are needed for use in computational
participation in the NATO Terminology Programme; serve systems. We have already proposed a series of supplement-
as Joint Staff planner for terminology issues; and appoint ary rules for the formulation of definitions (summarized in
and supervise the Joint Staff terminologist. [12]), rules which have been tested in some 150 ontology
initiatives over a wide variety of domains (see under ‘Users’
Enclosure C of this instruction provides a “Definition at [14]). We are applying these rules in building the JDO,
Writing Guide,” which includes a specification of the scope thereby providing a vehicle that can support the usage of
of JP 1-02 and also simple rules for writing definitions. Such joint terminology by computers without sacrificing
rules are of obvious importance for our needs here, since an understandability by humans. These definitions can also be
ontological counterpart of JP 1-02 can be created only if the of help in the process of revising joint publications in the
definitions contained in the latter are in good order from the future, allowing the content of JP 1-02 to be used as part of a
point of view of logical consistency. computational process of quality assurance for the use of
As concerns scope, the Guide specifies that the terminology in joint publications when successive revisions
Dictionary will include terms of general military or are made.
associated significance. Technical or highly specialized
terms may be included if they can be defined in easily UN C H
understood language and if their inclusion is of general operational area =def. An overarching term
military or associated significance. The Guide requires encompassing more descriptive terms (such as area of
responsibility and joint operations area) for geographic x x x
further that the dictionary be non-redundant: thus, a term
areas in which military operations are conducted.
will be added to the dictionary only if ‘[an] approved joint
term with similar definition does not exist.’ contingency operation =def. A military operation that
is either designated by the Secretary of Defense as a
The Guide defines a definition as ‘a formal statement of contingency operation or becomes a contingency x
the exact meaning of a term that enables it to be operation as a matter of law (Title 10, United States
distinguished from any other.’ A definition is distinguished Code, Section 101[a][13])
from a description by the fact that the latter ‘is a narrative subordinate command =def. A command consisting
containing information about the term that is not constrained of the commander and all those individuals, units,
in format or content.’ detachments, organizations, or installations that have x x
been placed under the command by the authority
Principles for the development of a definition require establishing the subordinate command.
that it should be:
Table 1: Examples of errors in JP 1-02 (from June 15, 2015)
Clear – Address the meaning of the term only. A U = unclear, N = not concise, C = circular, H = hidden definitions
definition should not contain doctrinal or procedural
information; i.e., it should focus on describing “what” a VIII. PROPOSED SUPPLEMENTARY RULES FOR DEFINITIONS
term is and not “how” or “why” it is used. We provide five examples of such rules, and illustrate
Concise – Be as brief as possible, including only their application to creating the JDO.
information that makes the term unique. Limit the Rule 1: Do not confuse the entity you are defining with
definition to one sentence whenever possible. the term used to represent that entity.
Complete – Include all information required to
(Failure to heed this rule is illustrated in the definition of
distinguish the term from those that are related or
operational area in Table 1 – an operational area is not a
similar.
‘kind of overarching term’.)
The Guide includes also a list of types of errors that are
Rule 2: Distinguish between general terms and proper
to be avoided when writing definitions. For example, a
definition should not be over-restrictive; it should not be names.
circular; it should be positive (state what is covered by a Almost every JP 1-02 term is a general term, which is to
term rather than what is not covered); and it should contain say, it is a term that refers to something general – a kind or
no hidden definitions (where the definition of one term is type (as in all the cases listed in Table 1) – having multiple
embedded inside another). specific instances. A small number of JP 1-02 terms are
proper names, which is to say, they refer to exactly one
The rules codified in the Guide conform very well to the specific instance. Examples include the Universal Joint
best practices identified by terminologists who have studied Task List and Joint Doctrine Development System. Such
the authoring of definitions [20]. That violations of these terms are standardly marked by use of initial capitals, but
rules have slipped though the coordination process, their treatment in JP 1-02 is sometimes uncertain. The
however, is seen in the fact that errors of each of the definition of Army air-ground system, for instance,
mentioned kinds can still be found (see Table 1). suggests that there is exactly one Army air-ground system,
so that ‘Army air-ground system’ would be a proper name.
STIDS 2015 Proceedings Page 5
However, there may be a plurality of such systems used by warfighters’ experience and therefore context, they need
the Army at any given time. definitions with as little ambiguity as possible. And second,
the changes proposed bring aid not only to the formalization
Rules 3–5 apply only to general terms, and are satisfied of joint doctrine terminology in the JDO – where adherence
already by the definitions of many such terms in JP 1-02: to rule 5 allows immediate generation of the backbone
Rule 3: All general terms should be singular in number. taxonomy of the ontology – but also to the quality assurance
of joint doctrine definitions themselves, by allowing easier
Rule 4: Each general term should have at most one checking of logical consistency.
single parent term.
Rule 5: The definition of each general term A should IX. BUILDING THE JDO
specify the associated parent term B and state what it is A. The OBO Foundry
about the As that marks them out from all other
Our strategy for building the JDO follows an approach to
instances of B as instances of A.
coordinated ontology development as a means to advancing
Thus a definition of a general term A should have the two- interoperability across multiple domains that was first
part form: successfully applied in the life sciences in the context of the
An A =def. a B which Cs. Open Biomedical Ontologies (OBO) Foundry initiative
([21]). The strategy rests on dividing the domain of
For example (from [16]): biomedicine into a number of sub-domains (for genes,
artillery vehicle =def. A vehicle which is designed for proteins, cells, and so forth) and creating ontology modules
the transport of one or more artillery weapons. representing the corresponding general types of entities.
Each ontology module consists of general terms organized
artillery weapon = def. A device which is designed for hierarchically through the parent-child relation between
projection of munitions beyond the effective range of types and subtypes. This relation then serves as the starting
personal weapons. point for the formulation of the definitions of the terms in
Returning to JP 1-02 we can now, following rule 5, define: the hierarchy in accordance with Rule 5 above. This strategy
is currently being applied in a series of DoD and intelligence
operational area =def. A geographic area in which community projects, in each case drawing on the Basic
military operations are conducted. (Contrast the first Formal Ontology (BFO) [12], which serves as a common
row of Table 1.) upper level starting point for the creation of definitions of
Here ‘geographic area’ is the parent term; the specific the terms used in the domain ontologies at lower levels.
difference is ‘in which military operations are conducted.’ The predominance of general terms in JP 1-02 reflects
The overwhelming majority of JP 1-02 definitions are the purpose of military doctrine, which is to help warfighters
already of this form. Consider for example: understand the realities of war and their specific situations.
theater of operations =def. An operational area It achieves these ends largely through the identification and
defined by the geographic combatant commander for explanation not of specific instances (such as a particular
the conduct or support of specific military operations. aircraft or IT system) but rather of important general
categories. Doctrine is re-usable because it is applicable to
Many of the remaining cases are easily converted to be of many different instances and to many different sub-kinds of
this form without any change of meaning. Starting, for the same general categories that re-appear in ever new
example, from the definition: situations. This approach is effective because the basic
cyberspace operations = def. The employment of realities of war are not changed by the fielding of new
commanders, equipment, specialties, or tactics. A new IT
cyberspace capabilities where the primary purpose is to
system may provide a commander with more information in
achieve objectives in or through cyberspace.
easier-to-understand formats; but the basic role of IT in
Here two conversion steps are needed. The first replaces the supporting unified action remains unchanged. Because the
term to be defined with a singular noun following rule 2. developers of doctrine were so successful in identifying the
The second, in accordance with rule 5, adds a representation high-level categories of C2, commanders and others
of the appropriate parent term (here, trivially, operation) to continue to use these same categories when understanding
yield: how to employ each new IT system to create better
operational capabilities.
cyberspace operation =def. An operation that employs
cyberspace capabilities and has primary purpose: to The most general categories in military doctrine are:
achieve objectives in or through cyberspace. (1) thing (people, equipment, organizations),
Such rules may seem trivial, and the effect of their (2) attribute (capabilities, functions, roles, including
application may be very slight when measured against the relational attributes of command or support), and
understandability and utility from the point of view of
human beings of the definitions to which they give rise. But (3) process (for example, the joint planning process).
they bring two immediate benefits when IT systems are
brought into play. First, because IT developers lack
STIDS 2015 Proceedings Page 6
C. Building the JDO as Shadow JP 1-02
Our strategy for building JDO is incremental. We
proceed through the successive joint publications (JP n-m),
moving from general to specific, for instance from JP 3-0
(Joint Operations) to JP 3-14 and JP 3-17 (Space
Operations and Air Mobility Operations). The creation of an
ontology for each JP n-m then follows three steps:
i. ENRICHMENT: create JP n-mE, a shadow version of
those portions of JP 1-02 whose terms are defined in JP
n-m but enriched (E) through the addition of new terms –
for example, commander – that are not defined in JP 1-
02 but used in JP n-m definitions;
ii. LOGICAL REGIMENTATION: create JP n-mLR, a
logically regimented (LR) version of JP n-mE, in which
definitions are formulated in humanly understandable
English but with the logical regimentation sketched in
our summary treatment of supplementary rules for
Figure 1: OBO Foundry strategy for modular coordination
definition writing in section VII, as supplemented by the
further rules set forth in [12]);
Nowhere is it stated explicitly in military doctrine that these iii. FORMALIZATION: create JP n-mF, in which the
are the basic categories of the reality of war. Rather, the human-readable definitions in JP n-mLR are formalized
doctrinal publications are divided by area of warfare and by (F) using the Web Ontology Language (OWL);
process (C2, intelligence, fire support, logistics, planning,
Content from CCO is incorporated in each stage as needed.
and so forth). One of the virtues of joint doctrine is its
Examples are provided at http://ncor.buffalo.edu/JDO-Oct-
consistent use of the same general terms representing sub-
2015.
categories of thing, attribute, and process across all the joint
publications. For example, every joint publication uses the
term commander (thing) for the officer appointed to
command (process) an organization (thing) and to
exercise authority (attribute) over subordinates. It is
impossible to understate the value of this achievement,
which has not only diminished communications barriers
among the warfighters of different specialties but also faci-
litated the application of IT in planning, training, and real
world operations. What is remarkable is that the authors,
managers, and terminologists of joint doctrine achieved this
consistency with minimal documented theory and pro-
cedures for categorization and for the writing of definitions.
B. BFO and the Common Core Ontologies
In our view, BFO provides the documented theory Figure 2: Common Core and associated domain ontologies
needed to fill this gap [12]. BFO is architected around the
same upper-level categories (of thing, attribute, and X. POTENTIAL BENEFITS OF THE JDO TO THE WARFIGHTER
process) used by joint doctrine. More importantly, BFO We are developing the JDO to support efforts to extend
serves as the starting point for a suite of associated resources the applicability of doctrine in those areas where
– based on the Common Core Ontologies (CCO) (see [11] commanders, planners, and other warfighters need to call
and Figure 2) – that have been purpose built to support IT upon information and information support in order to be
applications in the military and intelligence domains. effective. JDO will provide a computationally accessible
The CCO and other domain-ontology modules are (1) counterpart of the content of JP 1-02 designed to support
defined in BFO terms and then (2) they are themselves unified action by advancing terminological consistency and
extended through the addition of domain-specific sub- interoperability.
ontologies along the lines illustrated in Figure 2. The BFO The major benefit of JDO should take the form of better
community has refined and tested the needed theory and C2 through improved communication, self-synchronization,
procedures for generating such sub-ontologies in agile and projection into the future, and in each stage of
fashion and for preserving their usability and mutual development of the JDO we will be testing its utility in
consistency across successive versions. [14]-[16]. supporting improvements along all of these dimensions.
STIDS 2015 Proceedings Page 7
some previous definition in JP 1-02. Integration of the JDO
within the larger BFO–CCO framework would also help to
resolve some of the problems that arise when expressions
are used in JP 1-02 definitions but are themselves not
defined in JP 1-02.
XI. POTENTIAL BENEFITS OF JDO TO THE DOCTRINE STAFF
Anticipated benefits of JDO to doctrine authors include
the ability to apply standard ontology editing and visualizing
software, for example, to create visualizations of how
different parts of doctrine interact, of the doctrinal content
relevant to particular types of operations or capabilities, or
of the ways doctrine is used (and not used) in specific plans
and operations. These benefits include opportunities for
logical tracking of dependences among terms and definitions
to identify (direct and indirect) circularities and thereby to
help to ensure, when changes in definitions are made in the
Figure 3: Examples of CCO and JP 1 terms descending from BFO process of revision, that the effects of these changes cascade
in the JDO appropriately through all dependent definitions.
As stated in JP 6-0 (“Joint Communications System”) For example, imagine that revisions need to be made to
[13], a C2 system has two elements: (1) the people, who the definition of a term such as base defense illustrated in
make decisions and accomplish missions, and (2) the Figure 4. The Figure tells us which definitions then need to
facilities, equipment, communications, staff functions, and be checked for continued validity, by showing the terms in
procedures essential to the commander for C2. People can JP 1-02 that are defined using base defense either directly or
conduct C2 without facilities, equipment and so forth, but indirectly (by inheritance from a definition lower down the
the latter cannot perform C2 without people. Since unified corresponding chain).
action occurs not only between people and organizations,
but also between IT systems and people, by advancing
interoperability in the ways described above, a successfully
developed JDO can facilitate moving past the low level of
unity of action among people, organizations, and IT systems
that has been achieved until now.
A subsidiary benefit takes the form of providing ways to
extend the range of IT-supported uses of the content of
doctrine, for example, by allowing the DoD Dictionary to
serve as an entry point for web-based searches across
multiple repositories of authoritative data; by facilitating
greater coordination of training and operations; and by
increasing automation of processes such as plan specifi-
cation, course of action development, and operations and
Blue Force Status assessment, particularly within highly Figure 4: Fragment of the JP 1-02 network generated by the
contested environments. relation is used to define.
We anticipate that the JDO will allow further We believe that terminological interoperability can be
enhancements of JP 1-02, for example, by providing for achieved only where the terminologies involved are
each term in the dictionary its own web page that can serve developed as part of, or are defined in terms derived from, a
as a repository of usage and of revision history. This last common benchmark ontology framework. Only such a
benefit is part of our more general strategy to assist framework can provide a basis for clearly formulated logical
developers of the hundreds of IT systems that are developed relations between terms, and only this will allow the sort of
for U.S. military operations to achieve the benefits of automated checking for consistency that is needed when the
interoperability and to keep track of needed information. terminological content of multiple information systems is
aggregated together in larger (actual or virtual) systems.
Access to detailed information on the usage and revision This requirement for automated consistency checking
history of the vocabularies of the intended users of these becomes all the more urgent as terminological artifacts are
hundreds of systems would facilitate unified action among revised over time. We believe that the value of the JDO will
IT developers, for example, by helping to rectify the current reveal itself not least in supporting consistent revision of JP
situation in which even the best-intentioned and 1-02 in tandem not merely with Service and coalition
conscientious IT developers must make assumptions on doctrines but also with information artifacts such as the
whether a warfighting term in a specification that is listed in Universal Joint Task List (UJTL), the Joint Lessons Learned
joint doctrine is intended to be defined by the current or by Information System (JLLIS), and their Service counterparts.
STIDS 2015 Proceedings Page 8
Finally, JDO can also help the many teams of ontologists REFERENCES
working on different military and intelligence community [1] Joint Publication (JP) 1, Doctrine for the Armed Forces of the United
initiatives to advance information discovery and processing. States, 25 March 2013.
The JDO will enable doctrine to serve as a new source of [2] M. R. Hieb, S. Carey, M. Kleiner, M. Hieb, R. Brown, “Standardizing
ground truth for ontologists across DoD and IC that can help Battle Management Language – A Vital Move Towards the Army
to ensure mutual consistency and identify wasteful redun- Transformation”, IEEE Fall Simulation Interoperability Workshop, 2001.
dancies as well as gaps and errors in existing ontologies. It [3] S. Lambert, M. R. Hieb, “Improving Unity of Effort in Command and
will contribute to consistent and yet agile development of IT Control Processes: An Operational Analysis of a Joint Doctrinal
Language”, Spring Simulation Interoperability Workshop, 2006, 743-752.
technology while also counteracting current tendencies
toward silo formation and failures of interoperation. [4] Tolk, Andreas, and Curtis Blais. “Taxonomies, Ontologies, Battle
Management Languages – Recommendations for the Coalition BML Study
Group”, Spring Simulation Interoperability Workshop 2005.
APPENDIX: EXAMPLES OF PRIOR WORK
[5] Simulation Interoperability Standards Organization (SISO), Standard
The practical value of an ontology-based approach to for: Coalition Battle Management Language (C-BML), Phase 1 SISO-STD-
supporting operational military IT has been demonstrated 011-2012-DRAFT 4 April 2012.
most conspicuously in the ICODES (Integrated Com- [6] Department of Defense Instruction 8330.01, “Interoperability of
puterized Deployment System) load-planning system, a Information Technology (IT), Including National Security Systems (NSS)”,
program of record employed by the DoD since 1997 [22]. May 21, 2014.
[7] Joint Publication (JP) 1-02, Department of Defense Dictionary of
A more recent example is the AFRL (Air Force Military and Associated Terms, as amended through 15 June 2015.
Research Lab)/USTRANSCOM Mission Data and [8] Department of Defense Instruction Number 8320.02, “Sharing Data,
Transport Ontology project described in [23]. Here, the goal Information, and Information Technology (IT) Services in the Department
was to create a domain model of U.S. Transportation of Defense”, August 5, 2013.
Command’s operations, including operational processes, [9] Acquisition Community Connection (ACC) Practice Center, Terms
organizations, and Commander’s Critical Information and Definitions, Open Systems Architecture, https://acc.dau.mil/
Community Browser.aspx?id=220108&lang=en-US, October 14, 2015.
Requirements (CCIR), to be used to support the monitoring
of information relevant to USTRANSCOM missions. [10] J.-F. Ethier, O. Dameron, V. Curcin et al., “A unified structural/term-
inological interoperability framework based on LexEVS”, Journal of the
Specifically, rules were used to modify terms and definitions American Medical Informatics Association, 2013, 20, 986-994.
of the Joint Mission Essential Task List (JMETL) in ways [11] J. R. Schoening, et al., “PED fusion via enterprise ontology,"
similar to those described in section VIII in relation to the Proceedings of SPIE 9464, Ground/Air Multisensor Interoperability,
definitions of operational area and cyberspace operations. Integration, and Networking for Persistent ISR VI.
When the resulting domain model was used with the [12] R. Arp, B. Smith, A. D. Spear, Building Ontologies with Basic
Securboration MetaTagger application, there was a Formal Ontology, Cambridge, MA: The MIT Press, 2015.
reduction 20% in the numbers of people required for [13] Joint Publication (JP) 6-0, Joint Communications System, June 2015.
monitoring for critical information and a reduction of 1–3 [14] Basic Formal Ontology, http://ifomis.org/bfo, September 2015.
days in discovering such information. [15] D. Salmen, T. Malyuta, A. Hansen, S. Cronen, B. Smith, “Integration
of Intelligence Data through Semantic Enhancement”, Semantic Technology
Another AFRL effort used analogous rules in in Intelligence, Defense and Security (STIDS), 2011, CEUR 808, 6-13.
transforming a portion of the Joint Capability Areas (JCA)
[16] B. Smith, T. Malyuta, W. S. Mandrick, C. Fu, K. Parent, M. Patel
taxonomy into an ontology-based model that was then “Horizontal Integration of Warfighter Intelligence Data. A Shared
processed by a machine-learning algorithm to train an appli- Semantic Resource for the Intelligence Community”, Semantic Technology
cation. Formalizations of the JCA descriptions were used to in Intelligence, Defense and Security (STIDS), 2012, CEUR 996, 112-119.
allow comparisons of unstructured text against each of the [17] Chairman of the Joint Chiefs of Staff Manual (CJCSM) 5120.01,
formalized descriptions in order to determine matches. “Joint Doctrine Development Process,” December 29, 2014
Initial attempts to disambiguate each of the JCA descript- [18] Department of Defense Instruction 5025.12, “Standardization of
tions failed because of redundancy and ambiguity. Instead, a Military and Associated Terminology,” August 14, 2009.
hybrid was created consisting of formalizations of JCA de- [19] Chairman of the Joint Chiefs of Staff Instruction 5705.01D
scriptions along with word bags of their respective contents. “Standardization of Military and Associated Terminology,” Nov. 10, 2010.
A machine learning algorithm was then used to compare [20] S. Seppälä. “An ontological framework for modeling the contents of
historical user input against both to train the algorithm. definitions”, Terminology, 21(1):23–50, 2015.
Here, too, the implementation (described in [24]) shows a [21] B. Smith, et al., “OBO Foundry: Coordinated Evolution of
Ontologies to Support Biomedical Data Integration”, Nature
reduction in 1–3 days for discovering critical information Biotechnology, 25 (11), 1251-1255.
that could affect USTRANSCOM operations, for example,
[22] K. Pohl and P. Morosoff, “ICODES: A Load-Planning System that
in case of earthquake or other disaster and a 20% reduction Demonstrates the Value of Ontologies in the Realm of Logistical
in manpower required for monitoring the information. Command and Control (C2)”, InterSymp-2011, 2011.
[23] J. M. Powers, Keith D. Shapiro, and David S. Monk, “Information
ACKNOWLEDGEMENTS Exchange and Fusion in a Collaborative Environment using Semantic
Our thanks go to Lieutenant Colonel James McArthur Information Requirements”, International Conference on Collaboration
Technologies and Systems (CTS 2014). 597-601.
(USMC JS J7), Lieutenant Colonel William D. Betts (USAF
JS J7), Tatiana Malyuta (CUNY), Tony Stirtzinger [24] Securboration, “Human assisted analysis for change alignment to an
Enterprise Architecture”, Requirements Analysis Portlet (RAP). May 2012.
(Securboration), Andreas Tolk (MITRE/Old Dominion
University), and Erik Thomsen (Charles River Analytics).
STIDS 2015 Proceedings Page 9