Page Last Updated: Tuesday, 07 June 2016 11:27 EDT, © 2011, 2012, 2013, 2014, 2016

Complex Operational and Organizational Problems

PROJECT: IW Ontology 2

Dr. Dean S. Hartley III

Project Metadata Keywords
Label Name Other Year DurationYrs
Client TRAC US Army
Dates 2012 1
Employer Hartley Consulting
Partner BMA
Pubs "Engineering an Irregular Warfare (IW) Model," in Hawaii University International Conferences (HUIC) Proceedings, June 2014 author 2014
Pubs "Chapter 5: DIME/PMESII Models," in Conflict and Complexity, edited by Philip Vos Fellman, Yaneer Bar-Yam and Ali A. Minai, 2015 author 2015
Pubs Irregular Warfare (IW) Ontology Final Report lead author 2013
Pubs "Psychological Profiling of World Leaders," in OR/MS Today, Vol 41, No 6, December 2014 lead author 2014
Pubs "Ontologies Support M&S Analysis in the IW Domain," in Phalanx, Vol 47, No 2, June 2014 lead author 2014
Team Deborah Duong, Kenneth O. Jobson, Lee W. Lacy, Paul W. Works
Configuration management
Consequence Management
Data collection
Data Verification & Validation
Database design
Documentation standards
Geopolitical analysis
Global War on Terrorism (GWOT)
Human factors
Human, Social, Cultural Behavior (HSCB) Modeling
Impact analysis
Independent Verification & Validation (IV&V)
Information storage and retrieval
Irregular Warfare (IW)
Knowledge Management (KM)
Model/System integration
Modeling, Simulation & Gaming (MSG)
Network analyses
Operations Other Than War (OOTW)
Software issues
Software reuse
Stability Operations (SASO, SSTR)
Verification, Validation & Accreditation (VV&A)
Warfare modeling


Create a total ontology of the elements needed for modeling Irregular Warfare (IW) and create the connections between this ontology and an extension of the military's Lines of Effort (LOE) concept to all of the principal actors in an IW.


Many IW analysis tasks require tools to describe complex operational environments (OE). TRAC is developing ontologies to support consistent representations of the state of the OE and describe actors performing actions that affect the OE. Ontologies use controlled vocabularies to help formalize the relationships between concepts, simplify information interchange, provide a catalog of variables to use as a starting point, provide common terms to communicate about concepts, and guide efforts to acquire, develop and use data. The TRAC ontologies include Goal-Task-Owner (GTO) sets to describe the tasks performed by organizations to achieve goals and provide Use Cases for the factions that represent various perspectives in IW situations. The initiative is derived from the TRAC IW Metric Ontology project and the Total IW Ontology independent research and development project. The first project developed the conceptual model shown in the figure below.

The central organizational principle for the development of the IW Metric Ontology is provided by the high-level context diagram to the right. The Operational Environment that includes everything relevant to irregular warfare is divided into three parts: Actors, Actions, and the Environment.

Actors are human and natural entities that cause things to happen, thereby changing things.

Actions are the interventions, events, and ongoing processes that are performed by actors and which directly cause changes.

The Environment represents the rest of entities in the Operational Environment.

Actors perform Actions, which affect the Operational Environment (OE). The state of OE, including any changes, is described by State Variables. Actors perceive the OE by means of the State Variables.

State Variables include both numeric variables (true metrics) and categorical variables (e.g., type of government).  IW Metrics are defined to be these State Variables and provide the content of the IW Metric Ontology.

The initial effort (the IW Metric Ontology project) focused on creating a metric ontology, using the actor, action, and environment elements as reference data.  The second effort (the Total IW Ontology project) focused on completing the actor, action, and environment ontologies, with the possibility of creating additional metric classes in the process.  This effort checked the consistency of the four ontology structures and concentrated on creating additional semantic ontologies within them, principally the GTO sets.

The entire ontology consists of several ontologies, divided into three categories.  The first set of ontologies consists of those with structures defined by the Operational Environment.  The second set consists of ontologies with structures defined by the ontology contents.  These first two sets are situation-independent, that is the contents describe a generic irregular warfare situation.  The third set consists of ontologies with structures that are situation-independent, but which have situation-dependent contents.

Ontology Structures Defined by the Operational Environment:

The four main ontologies are the metric ontology, the actor ontology, the action ontology, and the environment ontology.  Each ontology has categories and subcategories.  There are eight metric categories, five actor categories, seven action categories, and four environment categories.  Each element in the actor, action and environment ontologies is connected to one or more metric classes, which describe the element.

1.  Metric Ontology

The figure to the right provides a list of the categories and subcategories of the metric ontology. There are 749 metric classes in the metric ontology. A full list of the metric classes can be downloaded here.

2.  Actor Ontology

The figure to the right provides a list of the categories and subcategories of the actor ontology. There are 102 actor classes in the actor ontology. A full list of the actor classes can be downloaded here.

3.  Action Ontology

The figure to the right provides a list of the categories and subcategories of the action ontology. There are 385 action classes in the action ontology. A full list of the action classes can be downloaded here.

4.  Environment Ontology

The figure to the right provides a list of the categories and subcategories of the environment ontology. There are 208 environment classes in the environment ontology. A full list of the environment classes can be downloaded here.

5.  Connecting the Elements to the Metrics

The figure to the right provides a list of the categories and subcategories of the environment ontology. There are 208 environment classes in the environment ontology. A full list of the environment classes can be downloaded here.

Social Ontology 

6.  Properties Ontology

Properties are the variables of a class. Each of the element classes has a property named entityIdentity.  Having this property in common is part of what defines this class.  Each instantiation (object) has a different  value of its entityIdentity attribute – its name.  Classes and objects also have behaviors or operations.  For example, some classes represent things that can move – change their location (another property).  For simplicity, operations will be lumped in with properties.

Subclasses of a class inherit the properties of a class and add additional properties that help define the subclass.   The figure to the right illustrates this inheritance process by showing the properties of all elements (including the existence of a link to one or more metrics) and showing additional properties of the subclasses down the chains.

The properties are best defined in terms of the elements.  For example, a vehicle class element clearly must have the property of being capable of movement.  However, the properties actually reside in the element’s metric.  Metrics are also classes and thus can have properties.  This fact permits complex metrics that convey information about multiple facets of the state of the situation.  What this says is that  the figure is useful in defining the properties, but is not quite correct in displaying the class definitions.  The element will have the identification property and the associated metric(s) will have that plus all of the other properties.  These properties convey the state information that makes the metrics the state variables.

A full list of the properties ontology can be downloaded here.

Properties Inheritance

Ontology Structures Defined by the Ontology Contents:

The relationships among meanings of  the contents of the ontology define two additional ontology structures:  Stocks and Flows and the Semantic Thesaurus.

1.  Stocks and Flows Ontology

The figure to the right illustrates a semantic relationship among the OE elements. A particular environmental element (with an associated quantity) is present along with actions that increase and decrease the quantity of the element.  The Environment-Oriented Stocks and Flows structure allows these relationships to be captured.


The figure to the right illustrates a more complex set of semantic relationships. An organization of a given type can be created. The number of these organizations can be increased or decreased.  There can be other actions that impact the organization or its members (People). The number of people in the organization can be increased (directly or by training other people) or decreased. Certain environmental elements may relate qualities of the organization or its people.  There may be one or more key people in the organization. There may be an environmental element that describes the decision making of the key person. The Organization-Oriented Stocks and Flows structure allows these relationships to be captured.

A full list of both types of stocks and flows structures can be downloaded here.


2.  The Semantic Thesaurus

The figure to the right illustrates the way that the intermediate "semantic terms" form bridges among the metrics. Each metric is connected to one or more semantic terms and each semantic term is connected to one or more metrics. Because the OE elements (actors, actions and environmental elements) are connected to metrics, the semantic terms also form interconnections among the OE elements. A full list of the semantic terms can be downloaded here.



Ontology Structures Defined by the Scenario or the Situation:

The figure to the right illustrates a typical scenario or situation.

The action takes place within a host nation, with its geography, resources and populace - and its culture, religions, laws, etc. This arena is represented by the elipse in the center.

This scenario or situation is an example of irregular warfare because there are competing actors, each with its own agenda. The nature of this competition is what causes the situation to be labeled IW, rather than conventional war or peace.

In this figure, our armed forces are represented as the Coalition. Our other governmental agencies are represented by the State Department. Ideally, the goals of these two, while differing in detail are in consonance. The tasks, however definitely differ because the capabilities of these actors differ.

The host nation (HN) is also represented by two actors, the HN government and the HN armed forces.  The goals and tasks of these two actors may differ significantly.

In the typical situation, there are non-governmental organizations that have significant impacts. Here an international NGO represents a fairly benign, apolitical actor and a political NGO represents an actor that sides with one or more of the opposition forces.

Also, typically, there are commercial interests in the arena. Here a construction company represents contractors hired to implement some of the tasks of the Coalition and State Department. The acquisition company represents external interests that wish to purchase HN resources.

The regional power represents some external country in an analogous position to the State Department, but with possibly opposing interests.

The three opposing forces that are represented here consist of groups with interests in opposition to the HN government. Their goals differ among themselves; however, many of their actions may be related so that they may form temporary alliances.

1.  The GTO Set Structure

The GTO set structure, illustrated to the right, formalizes the concept of these competing interests.  The situation or scenario is defined as a model, with a name and a date.

The model has a several GTOSetOwners (the competing actors).  Each GTOSetOwner is identified as an actor within the IW ontology and has a citation that includes the defining metadata for the GTO set.

The GTOSetOwner owns several GTOTaskGoalPairs, consisting of a Goal and a Task for accomplishing the goal.

Each GTOTaskGoalPair has several GTOSubTaskSubGoalPairs, consisting of SubGoals of the Goal and SubTasks of the Task. Each SubGoal has one or more Metrics within the IW ontology and each SubTask has several Actions within the IW ontology.

Together, the GTO Sets in a single model represent a scenario or situation.

2.  The Actor-Action-Result Set Structure

The Actor-Action-Result (AAR) sets represent a level of detail below that of the GTO Sets.  Where the GTO Sets represent a scenario, an AAR set represents a vignette within the scenario.  An Action from one GTO set (or perhaps two or three very closely related Actions) and the associated Metric (or Metrics) are instantiated and form the basis for an AAR set.  For example, if the Action is attack Bridges and Tunnels, the instantiated action would be to attack a particular bridge.

The action has several associated elements:  time, geo-location, target, and resources needed for the action.  These resources might be physical elements (vehicles, etc.) and might include other actors.

The action has a result, it affects:  the initiating actor, the resources, the target, and possibly other elements (bystanders, other infrastructure, etc.).

The rationale for computing the effects is not included.  Rather, the Result placeholder acts as a call for one or more social or physical theories that provide this rationale.


3.  The Actor Relation Sets Structure

The Actor Relation Sets provide the final piece of the description of the scenario or situation.  The Actor-Actor and Actor-Environment structures provide for the definition of the relationships (boss/employee, leader/follower, tribe/member, etc.) between actors and the relationships (owner, controller, occupier, etc.) between an actor and an environmental element.

New High-Level Context Diagram:

The original high-level context diagram generates the ontology structures defined by the OE. Icons for the ontology structures defined by the ontology contents are added as "internal relationships" in the new diagram.  Icons for the ontology structures defined by the scenario or the situation are added below the original diagram as "external (model-specific) relationships.  Together, the icons for these sets of ontologies generate the new high-level context diagram that serves as an illustration of the IW Ontology.

Using the Ontology:

Constructing the IW Ontology was not a "science project," with its creation the sole goal.  It was constructed to be used.  Several Use Cases were developed to illustrate possible uses, two of which have already occurred.

1.  Identifying Future Modeling Constructs

TRAC used the list of metrics in the IW Metrics Ontology, produced in the previous project, to plan for improvements to the IW TWG.  TRAC personnel reviewed each metric (and its definition) to determine whether the concept it represented was already included in the model.  Those metrics that were not already included were binned into three categories:  those that should be included in the next year’s model improvements, those that should be included in future improvements, and those that were not germane to the model’s intended uses.  The TRAC users passed these results to the IW TWG modelers.  Other model users can employ the new IW Ontology in the same manner for any existing model in the IW domain.

2.  Perform VV&A of Models

Hartley Consulting used the IW Ontology to improve the categories used in the DIME/PMESII VV&A Tool for evaluating the static validity of a system’s conceptual model and coded model.  It used this tool in evaluating the Deployable Exercise Support system (DEXES II) being built by Dr. Loren Cobb for USSOUTHCOM.  Hartley Consulting will continue to use the ontology in future VV&A work.

3.  Define Model Functionality through GTO Sets

Model users can use the GTO sets produced in this project, modify them or produce new GTO sets to aid in defining to modelers the functionality that is needed in a model.  The GTO sets identify a principal actor (in the ontology), the set of actions (in the ontology) needed to accomplish the desired tasks, and the major metrics (in the ontology) required to assess accomplishment of the desired goals.  The model users can flesh-out these high-level use cases with resources and other affected entities (in the ontology).  The resulting set of ontology elements provide the minimal functionality that the desired model must have.

4.  Define Data Needs Using OE Elements

Model users can define the attributes of each OE element (in the ontology) that is needed in a model.  These attributes in turn define most of the data needs of the model.

5.  Define Output Variables Using Metrics

The OE elements in a model are connected to metrics (in the ontology).  The model users can define the output variables for the model using these metrics. 

6.  Define Complete New Model

Model users can use the three use cases:   3. define model functionality through GTO sets,  4. define data needs using OE elements, and  5. define output variables using metrics, to perform a large part of the functional design work for a complete new model.

7.  Define Model Building Blocks Using OE Elements

The ontology provides the necessary structure for creating model building blocks.

7.1 Building blocks model concept

The concept derives from the Lego® blocks experience.  Each kit contains a number of generic block types.  There are several instances of each block type.  The user can combine the blocks to create many different things.

  • Similarities:  the IW building blocks model would contain a number of standardized, generic modeling objects.  The user could combine the objects to create many different things.

  • Differences:  the IW building blocks model would contain only one copy of each block type.  However, the user would customize each block type into one or more instances.  A modeling infrastructure would be required to run/use the resulting model.

An IW Building Blocks model would be a coded, but non-executable model, containing code files for each of the generic IW concepts and all of the supporting structures (simulation engine, GUIs, etc.) for an operational model.

7.2 Building blocks model implementation

First, we start with the high-level context diagram.  There are Actors (defined by nouns that represent active entities) who perform Actions (defined by verbs).  These Actions affect the Operational Environment (OE), which consists of Actors, Actions and Environment (defined by nouns that represent passive entities).  There are also State Variables (also called Metrics) that describe the OE elements.  Actors perceive the State Variables and renew the cycle.  The OE elements (elements for short) and metrics constitute the elements of discourse and theoretically comprise a sufficiently complete set of descriptions / characteristics for many types of IW modeling and analysis.

We use class inheritance to propagate similarities.  The Operational Environment is made up of Elements, which include the Actors, Actions, and Environment.  All Elements have certain properties in common.  All Actors have additional common properties.  All Environment elements have common properties in addition to their Element properties.  All Actions have common properties in addition to their Element properties.  Each of the Actor, Action, and Environment categories is divided into high-level categories and subdivided into subcategories.  Each Element is assigned to one or more subcategories (a difference between an ontology and a taxonomy).  Each Element inherits all of the properties of its parents.  The Metrics are similarly divided into categories and subcategories and inherit properties from their parents.

A building block modeling strategy requires the following:

8.  Design Building Blocks Model

Model users can use the three use cases:   7. define model building blocks using OE elements,  4. define data needs using OE elements, and  5. define output variables using metrics, to perform a large part of the functional design work for a building blocks model.

A building block modeling strategy also requires the following:

  • Data and input GUI - The ontology building blocks provide stubs for the data.  The instances refine these stubs.

  • A simulation engine - The ontology building blocks provide sufficient detail to define the simulation engine requirements.  The instances may entail some refinements.

  • An output GUI - The ontology building blocks provide sufficient detail to define the output GUI requirements.  The instances may entail some refinements.

  • An analysis engine - The ontology building blocks provide sufficient detail to define the analysis engine requirements.  The instances may entail some refinements.

 The figure to the right illustrates the structure of the Building Blocks Model.

9.  Design Quick-Turn Model

Model users can use the two use cases:   8. design building blocks model and  3. define model functionality through GTO sets, to design a quick-turn model.

The concept is to create new models quickly to answer new questions.  “Quickly” implies simple models; however, in the IW domain we do not know enough to do “simple.”  The solution is to start with something that can be customized to meet the new needs.  Thus, quick-turn modeling in the IW domain is the process of creating new simulations models quickly, with each new model fitting a particular analytic need, and each new model starting from the IW Building Blocks Model.

A building block modeling strategy supports quick-turn modeling.  Each quick-turn model is a variant of the building blocks model.  A quick-turn model involves a scenario or vignette.

After the scenario has been defined, the model can be created. The figure to the right illustrates the processes for creating a quick-turn model:

  • Code the building block model;

  • Create instance objects for the actors, actions, environment elements, and metrics;

  • Create the detailed methods, based on appropriately selected theories;

  • Select and edit the input data;

  • Refine the analysis code; and

  • Code the quick-turn model.

A building block modeling strategy supports quick-turn modeling.  Implementation requires coding the instances, creating the logic for executing the actor-action-result diagrams, modeling V&V during the creation phase, collecting data, and data V&V.  Execution requires executing the model, analyzing the results, and the supporting infrastructure to perform these actions.

The figure to the right illustrates the structure of a quick-turn model.  The figure parallels that of the building blocks model structure shown in  earlier.  The main differences are in the conversion of the building block model code to quick-turn model code and the refinement of the analysis code.  The quick-turn figure also shows that the databases are filled, indicating actual use of the simulation.


Expressing the Ontology:

An IW ontology can be stored (expressed) in a database and encoded (expressed) into a formal OWL ontology with some limitations.

We defined an ontology as an “explicit specification of a conceptualization.”  In the prior project, we used one OWL language to express the explicit specification.  We have done the same in this project.  However, we have found that the IW Ontology has a richer conceptualization than can be entirely expressed in the OWL-DL or OWL Lite languages.

We had a problem of relating the element classes (Actors, Actions and Environment) to the Metric classes.  We found a work-around in describing the Metric classes as Metric properties, which can be related to classes in OWL.  However, we also describe several other relations that exist in the conceptualization of the IW Ontology, which cannot be expressed in OWL-DL / OWL Lite.

The ontology schema, that is the definition of the relationships among the ontology elements, is encoded in the OWL files.  Because of OWL’s centrality in ontology expression, there are third party tools that permit viewing and manipulating the ontology, such as Protégé.  One of the purposes of OWL is to provide inferencing, which requires that any inference be “decidable” by reasoning software.  This restriction also restricts what can be expressed in the language.  The entire IW Ontology can be expressed in an Access database.  However, the schema in Access is implicit and is encoded in numerous queries contained in the database.   

Discerning the entire schema is not trivial and requires additional coding within the database.  There is no third party software that addresses the contents of an Access database as an ontology. Thus, viewing and manipulating the ontology must be done with user-defined queries within the database.  Decidability is not enforced.  Queries designed for inferencing must be created by the user and will yield results that depend on the user’s skill and knowledge of the schema.  The upper table to the right captures these differences.

The lower table to the right captures the major differences in what we know from the IW Ontology conceptualization and what we can express in the two candidate explicit specifications.  The differences lead to our recommendation for building an Access GUI tool.




The first two conclusions derive from this project’s process: building on prior efforts and using collaborative methods.  The third conclusion relates the general value of an ontology in understanding its domain to the value for this particular domain, the IW domain.  The fourth conclusion relates to technical issues that arose in the course of the project.  The fifth conclusion relates to the benefits that the ontology provides in creating applications for the ontology.  The sixth conclusion provides some caveats concerning the IW ontology.

Building on Prior Efforts

This project, like most other projects, rests on prior work.  In this case, the prior metrics ontology served as an excellent starting point for identifying environmental properties.  The prior project concentrated on building a metrics ontology for IW; however, it included the High-level Context Diagram.  This diagram was the key concept in expanding the IW ontology into a unified specification of the entire IW domain.

Employing Collaborative Efforts

Some parts of ontology creation are essentially solitary acts.  These parts require concentration on converting an initial concept into a set of consistent parts.  However, other parts of ontology creation require collaboration.  These parts require the inclusion of new ideas and the testing and checking the implementation for errors.  This project and the prior one have shown that an IW ontology can be built in a collaborative manner using a series of workshops.

Understanding the IW Ontology

The IW domain is such a large domain that understanding it as a whole is quite difficult.  Part of the value of an ontology is that it aids in understanding the domain.  The IW ontology can be viewed as Operational Environment concepts (including Actors, Actions, and the Environment) that are described by properties (metrics).  In addition, there are numerous semantic relations among the concepts that help in describing the IW ontology.  These structural specifications help in understanding the IW domain that the ontology specifies.

Explicit Specification

An IW ontology can be stored (expressed) in a database and encoded (expressed) into a formal OWL ontology with some limitations.

IW Ontology Benefits

An IW ontology can be used for a variety of applications.  Two of the use cases have already been implemented, with proven value.  However, the major benefit from the IW Ontology lies in the conceptual domain:  it defines – explicitly – our current understanding of the entities, processes and metrics of IW.  Because of this, it can support many applications.

The modeling process provides an example of this point.  A model is an abstraction of reality – that is, it includes salient parts of reality and leaves out the unimportant parts.  Naturally, what is salient and what is unimportant depends on the intended use of the model; however, to make this distinction, one must know what the parts are.  In some domains, we have a long history of modeling and confidence in our knowledge of the domain.  This is not the case in the IW domain. 

However, the IW Ontology:

We now have a list of the parts of the IW domain.  We have a description of the various types of relationships among the parts.  We have a structure for describing the human goals and tasks (the GTO sets) that drive the changes within the IW domain.  Moreover, we have the connections of this structure to the parts of the IW domain.  Perhaps most importantly, this structure points to where what we know interacts with what we do not know – the science behind calculating results.  The IW Ontology provides all of this.  A modeler can use the IW Ontology to begin the abstraction process.

IW Ontology Caveats

The IW ontology is “nearly” complete and comprehensive.  First, this means that there may be a few elements that still need to be identified that belong in the ontology and that are of comparable granularity to the existing elements.  Second, the phrase “at this level of granularity” is assumed, but not explicitly stated.  That means, for example, that the mental states of a decision maker are not included in this ontology.  That would require an ontology with a finer granularity.

The partitions of the IW ontology are rational and useful, but not “correct” in any absolute sense.  As an analogy, consider a chocolate bar.  One could divide it into 12 equal size pieces in several ways, each yielding the same amount of chocolate in each piece.  If the bar is rectangular, but not square, one could produce 12 long, skinny pieces by cutting parallel to a long side or 12 shorter, somewhat fatter pieces by cutting parallel to a short side.  One might also make three cuts parallel to the short side and two cuts parallel to the long side, producing 12 short, fat pieces.  If the chocolate bar were pre-marked in this last fashion, one would say this is a “rational” division because it fits some of the observed characteristics of the chocolate bar.  The shape of the pieces from each cutting choice might determine how “useful” the division process is.  Notice, the division into 12 pieces as opposed to 48 or 20 is a “granularity” choice, which has to do with usefulness.

The IW ontology “supports” modeling, data definition, data interchange, model interoperability, theory choices, VV&A, and other valuable applications.  However, it does not guarantee that these things will be done properly.



The recommendations fall into four groups:  a definition for the Option Period specified in the PWS [TRAC 2012], expansion of the Use Cases defined earlier, creation of a new type of IW model, identification of use cases, and additional ontology work.

Build an Access GUI Tool for the Ontology

We would use the following design:

Create a Building Blocks Model and a Sample Quick-Turn Model

Using the GUI that would be created, we could actually create these models.

Identify and Document Use Cases

Our third recommendation is to further amplify the use case descriptions and consider additional use cases.  A formal set of use cases would be useful to support implementation decisions.  The Use Cases described above represent some of the possible applications of the IW Ontology.  There may be others that are of interest to the U.S. Government.  Because the descriptions are only sketches of the applications, amplification of their descriptions would aid in decision-making. 

Additional Ontology Work

Our fourth recommendation is to consider potential additional ontology projects. 

    Refining the Ontology

During the process of creating an IW model, whether as part of the Building Blocks Model / Quick-Turn Model process or as part of some other model creation process, it is likely that the need for additional OE elements or metrics might be discerned.  These additional elements or metrics would be integrated into the ontology.

    Additional Ontologies

The IW Ontology describes the IW domain at a particular level of granularity.  Models that require a finer level of granularity would require additional ontologies.  For example, models of the decision making process might require an ontology that includes the mental states of the decision maker, with correspondingly finer actions and metrics.


If you arrived here using a keyword shortcut, you may use your browser's "back" key to return to the keyword distribution page.

Return to Hartley's Projects Page