-When the U.S. conducts warfare, elements of a force are drawn from different Services and work together as a single team to accomplish an assigned mission on the basis of joint doctrine. To achieve such unified action, it is necessary that specific Service doctrines be both consistent with and subservient to joint doctrine. But there are two further requirements that flow from the ways in which unified action increasingly involves not only live forces but also automated systems. First, the information technology that is used in joint warfare must be aligned with joint doctrine. Second, the separate information systems used by the different elements of a joint force must be interoperable, in the sense that data and information that is generated by each element must be usable (understandable, processable) by all the other elements that need them. Currently, such interoperability is impeded by multiple inconsistencies among the different data and software standards used by warfighters. We describe here the on-going project of creating a Joint Doctrine Ontology (JDO), which uses joint doctrine to provide shared computer-accessible content valid for any field of military endeavor, organization, and information system. JDO addresses the two previouslymentioned requirements of unified action by providing a widely applicable benchmark for use by developers of information systems that will both guarantee alignment with joint doctrine and support interoperability.
The publications of joint doctrine document fundamental
principles and overarching guidance for the employment of
the Armed Forces of the United States [
Joint doctrine provides the benchmark for interoperability of the separate Service doctrines. And because all Service-level terminology is dependent on joint doctrine it is critical, if we are to prevent higher-level flaws cascading to domain-level doctrinal errors, that the terms of joint doctrine be defined correctly.
It is commonly supposed that doctrine provides not hard and fast rules but rather merely a loose and always revisable guide to action that is typically abandoned on first contact with the enemy. Doctrine is however authoritative also in the sense that it is to be followed in all cases except when, in the judgment of the commander, exceptional circumstances dictate otherwise. Moreover, there are many doctrinally acknowledged features of military action that survive through every engagement. Doctrine defines the shared frame of reference that remains active through every phase of every military engagement. This is because doctrine provides the principles that 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 of training and planning. Most importantly for our purposes here, doctrine provides a common lexicon – a set of precise terms and precise definitions – expressed in a language that is designed to enable consistent understanding by military leaders, planners and educators. Doctrine thereby enables the sort of effective communication among warfighters that is needed for unified action.
While doctrine has been developed and used thus far to satisfy the needs of human beings, it is increasingly understood that it must also satisfy requirements that come into play when information systems are brought to bear in military action. The language used by warfighters and codified in field manuals and doctrinal lexica still involves some of the ambiguities characteristic of all languages used by human beings. But such ambiguities can be tolerated where human beings are involved because humans can easily disambiguate the meanings of ambiguous terms in everyday contexts of use.
The very human-friendliness of the language used by
warfighters brings an equal and opposite weakness,
however, when information systems are involved.
Computers have difficulties in interpreting the common
language of human beings and in using contextual cues to
resolve ambiguities. Attempts to overcome these difficulties
led in around 2000 to the conception of the Battle
Management Language (BML) [
III. INTEROPERABILITY
BML continues as an active project [
Interoperability is defined in the Glossary of DoD
Instruction (DoDI) 8330.01 [
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. IT interoperability includes both the technical exchange of information and the end-to-end operational effectiveness of that exchange of information as required for mission accomplishment.
Our hypothesis is that the creation of a Joint Doctrine Ontology (JDO) can provide a widely applicable benchmark for use by developers of information systems that will support rather than impede unified action by breaking down existing terminological silos of different Services and communities of interest.
In contrast to the BML, our alternative approach
begins, not with defining a new language, but rather with
the existing authoritative controlled vocabulary that is
defined in Joint Publication 1-02, the Department of
Defense Dictionary of Military and Associated Terms [
The JP 1-02 dictionary consists in its current version of some 2,803 terms drawn from some 81 approved doctrinal publications forming the Joint Doctrine Hierarchy (at http://www.dtic.mil/doctrine/doctrine/status.pdf). In effect, we are constructing JDO as 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 that underlies it, remain synchronized with each other through future revisions of joint doctrine. In effect, JDO will provide a semantic enhancement of JP 1-02, and therefore also of the terminological content of the separate Joint Publications from which the terms and definitions of JP 1-02 are derived.
The Dictionary defines the standard U.S. military and
associated terminology needed to enable the joint activity of
the Armed Forces of the United States. As stated in the
Preface signed by Vice Admiral William E. Gortney,
Director of the Joint Staff, these military and associated
terms, together with their definitions, constitute approved
Department of Defense (DOD) terminology for general use
by all DOD components. [
In multiple other joint publications, as well as in a series
of DoD and Chairman of the Joint Chiefs of Staff
instructions, it is required that all DoD initiatives, as well as
all warfighters and warfighting organizations, should use a
common terminology. In addition, instructions state that all
IT intended for use in military operations should be
designed from the beginning to be interoperable (paragraph
9b of Chapter 2, “Doctrine Governing Unified Direction of
Armed Forces,” JP 1 [
The need for interoperability of DoD information systems and for alignment of the data and information that enables military action has been recognized repeatedly and at the highest levels, and given today’s and tomorrow’s flood of digital data across networks this need is becoming ever more apparent.
For example, DoDI 8320.02, “Sharing Data,
Information, and Information Technology (IT) Services in
the Department of Defense” [
The DoDI directs further that ‘Data, information, and IT services will be made … interoperable throughout their lifecycles for all authorized users’. However, the instruction to achieve such interoperability – namely through ‘enforcement of policy for DoD metadata that uses Government and industry metadata standards’ – repeatedly fails in its goal. This is not only because the policy is formulated in a way that falls short of the required specificity, but also because, even where relevant standards exist, they have in almost all cases been created ad hoc, to address specific local needs. Thus they have not been built in the sort of coordinated, rule-governed way that would be needed to achieve interoperability.
The problem of overly weak requirements is illustrated
also in the already mentioned DoDI 8330.01 on
“Interoperability” [
Because everything is by definition interoperable to ‘the maximum extent practicable,’ this instruction is without teeth.
DoDI 8320.02 suggests a further route to the
achievement of interoperability through adherence to
standards listed in the DoD IT Standards Registry (DISR).
Unfortunately, it is difficult to determine the degree of
interoperability of DISR standards, in part because the
needed assessment must be applied simultaneously to the
different portions of the DISR, and these often require
different sorts of permissions (and thus, we assume, are
accessible only to different sorts of people). Some of the
resources contributed to the DISR that we were able to
access, however, do not manifest – even when taken singly
– the sort of minimal terminological consistency or formal
regimentation that would be needed to meet the demands of
interoperability. The terminology defined in [
Achieving interoperability – both terminological and
structural [
DoDI 8330.01 [
While DoD thus requires that joint doctrine addresses the need for IT interoperability, it crucially does not require – and has no effective strategy to ensure – that the IT systems and procedures themselves address the need for conformity with joint doctrine. We believe, however, that such conformity is not only indispensable if unified action between human warfighters and IT systems is to be achieved, but further that it would bring multiple significant benefits to military IT systems themselves, and thus also to the developers of such systems, because it would provide a benchmark for interoperability.
INFORMATION SYSTEMS
JP 1, the Capstone Publication of Joint Doctrine [
The forces, units, and systems of all Services must operate together effectively, in part through interoperability. This includes joint force development; use of joint doctrine; the development and use of joint plans and orders; and the development and use of joint and/or interoperable communications and information systems (italics added). Because a military organization includes its information systems, we believe that building the common language provided by doctrine into the information systems that will be used by warfighters is a vital need.
The DoD Manual (DoDM) 5120.01, “Joint Doctrine
Development Process” [
VII. RULES FOR DEFINITIONS IN INSTRUCTION 5705.01D
To see how JDO will be constructed, we need first to
understand some of the features of the Dictionary from
which it will be derived. The idea for such a dictionary is
expressed in DoDI 5025.12 of August 2009 [
This position is restated in the Chairman of the Joint Chiefs of Staff Instruction (CJCSI) 5705.01D of November
Enclosure C of this instruction provides a “Definition Writing Guide,” which includes a specification of the scope of JP 1-02 and also simple rules for writing definitions. Such rules are of obvious importance for our needs here, since an ontological counterpart of JP 1-02 can be created only if the definitions contained in the latter are in good order from the point of view of logical consistency.
As concerns scope, the Guide specifies that the Dictionary will include terms of general military or associated significance. Technical or highly specialized terms may be included if they can be defined in easily understood language and if their inclusion is of general military or associated significance. The Guide requires further that the dictionary be non-redundant: thus, a term will be added to the dictionary only if ‘[an] approved joint term with similar definition does not exist.’
The Guide defines a definition as ‘a formal statement of the exact meaning of a term that enables it to be distinguished from any other.’ A definition is distinguished from a description by the fact that the latter ‘is a narrative containing information about the term that is not constrained in format or content.’
Principles for the development of a definition require that it should be:
Clear – Address the meaning of the term only. A definition should not contain doctrinal or procedural information; i.e., it should focus on describing “what” a term is and not “how” or “why” it is used.
Concise – Be as brief as possible, including only information that makes the term unique. Limit the definition to one sentence whenever possible.
Complete – Include all information required to distinguish the term from those that are related or similar.
The Guide includes also a list of types of errors that are to be avoided when writing definitions. For example, a definition should not be over-restrictive; it should not be circular; it should be positive (state what is covered by a term rather than what is not covered); and it should contain no hidden definitions (where the definition of one term is embedded inside another).
The rules codified in the Guide conform very well to the
best practices identified by terminologists who have studied
the authoring of definitions [
Avoiding these and other types of errors would not only
make JP 1-02 more valuable to human users; it would also
enable the construction of the formal representations of its
content of the sort that are needed for use in computational
systems. We have already proposed a series of
supplementary rules for the formulation of definitions (summarized in
[
U N C H x x
x x x x VIII. PROPOSED SUPPLEMENTARY RULES FOR DEFINITIONS
We provide five examples of such rules, and illustrate their application to creating the JDO.
Rule 1: Do not confuse the entity you are defining with the term used to represent that entity. (Failure to heed this rule is illustrated in the definition of operational area in Table 1 – an operational area is not a ‘kind of overarching term’.)
Rule 2: Distinguish between general terms and proper names.
Almost every JP 1-02 term is a general term, which is to say, it is a term that refers to something general – a kind or type (as in all the cases listed in Table 1) – having multiple specific instances. A small number of JP 1-02 terms are proper names, which is to say, they refer to exactly one specific instance. Examples include the Universal Joint Task List and Joint Doctrine Development System. Such terms are standardly marked by use of initial capitals, but their treatment in JP 1-02 is sometimes uncertain. The definition of Army air-ground system, for instance, suggests that there is exactly one Army air-ground system, so that ‘Army air-ground system’ would be a proper name. However, there may be a plurality of such systems used by the Army at any given time.
Rules 3–5 apply only to general terms, and are satisfied already by the definitions of many such terms in JP 1-02: Rule 3: All general terms should be singular in number. Rule 4: Each general term should have at most one single parent term.
Rule 5: The definition of each general term A should specify the associated parent term B and state what it is about the As that marks them out from all other instances of B as instances of A.
Thus a definition of a general term A should have the twopart form:
An A =def. a B which Cs.
artillery vehicle =def. A vehicle which is designed for the transport of one or more artillery weapons. artillery weapon = def. A device which is designed for projection of munitions beyond the effective range of personal weapons.
Returning to JP 1-02 we can now, following rule 5, define: operational area =def. A geographic area in which military operations are conducted. (Contrast the first row of Table 1.) Here ‘geographic area’ is the parent term; the specific difference is ‘in which military operations are conducted.’ The overwhelming majority of JP 1-02 definitions are already of this form. Consider for example: theater of operations =def. An operational area defined by the geographic combatant commander for the conduct or support of specific military operations. Many of the remaining cases are easily converted to be of this form without any change of meaning. Starting, for example, from the definition: cyberspace operations = def. The employment of cyberspace capabilities where the primary purpose is to achieve objectives in or through cyberspace.
Here two conversion steps are needed. The first replaces the term to be defined with a singular noun following rule 2. The second, in accordance with rule 5, adds a representation of the appropriate parent term (here, trivially, operation) to yield: cyberspace operation =def. An operation that employs cyberspace capabilities and has primary purpose: to achieve objectives in or through cyberspace.
Such rules may seem trivial, and the effect of their application may be very slight when measured against the understandability and utility from the point of view of human beings of the definitions to which they give rise. But they bring two immediate benefits when IT systems are brought into play. First, because IT developers lack warfighters’ experience and therefore context, they need definitions with as little ambiguity as possible. And second, the changes proposed bring aid not only to the formalization of joint doctrine terminology in the JDO – where adherence to rule 5 allows immediate generation of the backbone taxonomy of the ontology – but also to the quality assurance of joint doctrine definitions themselves, by allowing easier checking of logical consistency.
A. The OBO Foundry
Our strategy for building the JDO follows an approach to
coordinated ontology development as a means to advancing
interoperability across multiple domains that was first
successfully applied in the life sciences in the context of the
Open Biomedical Ontologies (OBO) Foundry initiative
([
The predominance of general terms in JP 1-02 reflects the purpose of military doctrine, which is to help warfighters understand the realities of war and their specific situations. It achieves these ends largely through the identification and explanation not of specific instances (such as a particular aircraft or IT system) but rather of important general categories. Doctrine is re-usable because it is applicable to many different instances and to many different sub-kinds of the same general categories that re-appear in ever new situations. This approach is effective because the basic realities of war are not changed by the fielding of new commanders, equipment, specialties, or tactics. A new IT system may provide a commander with more information in easier-to-understand formats; but the basic role of IT in supporting unified action remains unchanged. Because the developers of doctrine were so successful in identifying the high-level categories of C2, commanders and others continue to use these same categories when understanding how to employ each new IT system to create better operational capabilities.
(1) thing (people, equipment, organizations), (2) attribute (capabilities, functions, roles, including relational attributes of command or support), and (3) process (for example, the joint planning process). Nowhere is it stated explicitly in military doctrine that these are the basic categories of the reality of war. Rather, the doctrinal publications are divided by area of warfare and by process (C2, intelligence, fire support, logistics, planning, and so forth). One of the virtues of joint doctrine is its consistent use of the same general terms representing subcategories 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 facilitated 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 procedures for categorization and for the writing of definitions. B. BFO and the Common Core Ontologies
In our view, BFO provides the documented theory
needed to fill this gap [
The CCO and other domain-ontology modules are (1)
defined in BFO terms and then (2) they are themselves
extended through the addition of domain-specific
subontologies along the lines illustrated in Figure 2. The BFO
community has refined and tested the needed theory and
procedures for generating such sub-ontologies in agile
fashion and for preserving their usability and mutual
consistency across successive versions. [
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
102 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
definition writing in section VII, as supplemented by the
further rules set forth in [
We are developing the JDO to support efforts to extend the applicability of doctrine in those areas where commanders, planners, and other warfighters need to call upon information and information support in order to be effective. JDO will provide a computationally accessible counterpart of the content of JP 1-02 designed to support unified action by advancing terminological consistency and interoperability.
The major benefit of JDO should take the form of better C2 through improved communication, self-synchronization, and projection into the future, and in each stage of development of the JDO we will be testing its utility in supporting improvements along all of these dimensions.
As stated in JP 6-0 (“Joint Communications System”)
[
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 specification, course of action development, and operations and Blue Force Status assessment, particularly within highly contested environments.
We anticipate that the JDO will allow further enhancements of JP 1-02, for example, by providing for each term in the dictionary its own web page that can serve as a repository of usage and of revision history. This last benefit is part of our more general strategy to assist developers of the hundreds of IT systems that are developed for U.S. military operations to achieve the benefits of interoperability and to keep track of needed information.
Access to detailed information on the usage and revision history of the vocabularies of the intended users of these hundreds of systems would facilitate unified action among IT developers, for example, by helping to rectify the current situation in which even the best-intentioned and conscientious IT developers must make assumptions on whether a warfighting term in a specification that is listed in joint doctrine is intended to be defined by the current or by 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 process of revision, that the effects of these changes cascade appropriately through all dependent definitions.
For example, imagine that revisions need to be made to the definition of a term such as base defense illustrated in Figure 4. The Figure tells us which definitions then need to be checked for continued validity, by showing the terms in JP 1-02 that are defined using base defense either directly or indirectly (by inheritance from a definition lower down the corresponding chain).
We believe that terminological interoperability can be achieved only where the terminologies involved are developed as part of, or are defined in terms derived from, a common benchmark ontology framework. Only such a framework can provide a basis for clearly formulated logical relations between terms, and only this will allow the sort of automated checking for consistency that is needed when the terminological content of multiple information systems is aggregated together in larger (actual or virtual) systems. This requirement for automated consistency checking becomes all the more urgent as terminological artifacts are revised over time. We believe that the value of the JDO will reveal itself not least in supporting consistent revision of JP 1-02 in tandem not merely with Service and coalition doctrines but also with information artifacts such as the Universal Joint Task List (UJTL), the Joint Lessons Learned Information System (JLLIS), and their Service counterparts.
Finally, JDO can also help the many teams of ontologists working on different military and intelligence community initiatives to advance information discovery and processing. The JDO will enable doctrine to serve as a new source of ground truth for ontologists across DoD and IC that can help to ensure mutual consistency and identify wasteful redundancies as well as gaps and errors in existing ontologies. It will contribute to consistent and yet agile development of IT technology while also counteracting current tendencies toward silo formation and failures of interoperation.
APPENDIX: EXAMPLES OF PRIOR WORK
The practical value of an ontology-based approach to
supporting operational military IT has been demonstrated
most conspicuously in the ICODES (Integrated
Computerized Deployment System) load-planning system, a
program of record employed by the DoD since 1997 [
A more recent example is the AFRL (Air Force
Research Lab)/USTRANSCOM Mission Data and
Transport Ontology project described in [
Another AFRL effort used analogous rules in
transforming a portion of the Joint Capability Areas (JCA)
taxonomy into an ontology-based model that was then
processed by a machine-learning algorithm to train an
application. Formalizations of the JCA descriptions were used to
allow comparisons of unstructured text against each of the
formalized descriptions in order to determine matches.
Initial attempts to disambiguate each of the JCA
descripttions failed because of redundancy and ambiguity. Instead, a
hybrid was created consisting of formalizations of JCA
descriptions along with word bags of their respective contents.
A machine learning algorithm was then used to compare
historical user input against both to train the algorithm.
Here, too, the implementation (described in [
ACKNOWLEDGEMENTS
Our thanks go to Lieutenant Colonel James McArthur (USMC JS J7), Lieutenant Colonel William D. Betts (USAF JS J7), Tatiana Malyuta (CUNY), Tony Stirtzinger (Securboration), Andreas Tolk (MITRE/Old Dominion University), and Erik Thomsen (Charles River Analytics).