HARTLEY CONSULTING Solving Complex Operational and Organizational Problems

---

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.

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.

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.

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:

• Coverage:  the ability to define a complete set of building blocks.  The high-level context diagram covers the entire domain.  Extensive work on the IW Ontology has led to assurance of nearly complete coverage at the element and metrics levels.

• Granularity:  the consistency and appropriate level of granularity.  The elements and metrics of the IW Ontology have fairly consistent granularity.  The elements and metrics are sufficiently detailed that their expansion to fit a particular model does not require domain research to ensure full coverage at a finer level of granularity

• Content:  the ability to create a useful building block.  The elements and metrics are sufficiently detailed so that there is content (properties) which can be built into objects.  The elements and metrics are classes that permit the creation of instances to fit the needs of a particular model.  The properties are sufficient to begin the process of data requirements definition.  The properties are also sufficient to identify classes of theories that are needed to implement the methods (the connection to what we do not know).

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.

• The first pass at defining the scenario or vignette requires defining the principal players – owners, defining the tasks and goals for each owner, and results in a set of Goal, Task, Owner (GTO) sets. 

• The second pass requires selecting the elements and metrics that correspond to the GTO sets.   Each GTO set consists of an owner, a set of Task/Goal pairs, and sets of SubTask/SubGoal pairs for each Task/Goal pair.   

  • Unwanted GTO sets are removed.   

  • Unwanted Task/Goal pairs are removed.   

  • Unwanted SubTask/SubGoal pairs are removed.

• The third pass requires defining the actor-action-result diagrams that will implement the GTO sets, defining resources, targets, times, places, and other affected elements, selecting the elements that correspond to these, defining the appropriate metrics, and defining the theoretical bases for evaluating the results.  In this pass, semantically related elements may also be added.  The Stocks and Flows relations are relationships that will be helpful in determining other elements that need to be included.  The Semantic Thesaurus relations may also be helpful.  This process is one of adding in additional ontology elements.

• The fourth pass requires creating instances from the building blocks: 

  • actor instances – specific examples to fit the scenario, with additional attributes and specific methods,

  • environment instances – specific examples to fit the scenario, with additional attributes, and

  • action instances – specific examples to fit the scenario, with additional attributes and specific methods based on the theories chosen. 

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.

 

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:

• Partitions the Operational Environment into manageable pieces;

• Untangles the possibilities into meaningful elements

  • (the elements are large enough so that there are not too many to handle but

  • the elements are small enough so that their implications are readily perceivable);

• Organizes the elements in logical ways

  • there are actors of various subtypes;

  • there are actions of various subtypes;

  • there are (passive) environmental elements of various subtypes; and

  • there are state variables (metrics) of various subtypes;

• Provides various semantic linkages among the elements;

• Separates what we do know from what we do not know;

• Identifies where what we do not know (theories) connects to what we do know (the elements and their structures); and

• Is very nearly complete and comprehensive.

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.