Ontological Engineering for Threat Evaluation and Weapon Assignment: a Goal-driven Approach

Anne-Claire Boury-Brisset

Defence R&D Canada Valcartier 2459 Pie-XI North

Quebec, QC, G3J 1X5 Anne-Claire.Boury-Brisset@drdc-rddc.gc.ca

Abstract - Providing commanders with advanced decision aids requires a good understanding of the processes involved, their information requirements, and the development of formal domain models upon which reasoning processes can be based. Ontologies, as formal domain models, constitute a key component to provide a shared understanding of a domain, and have received increasing interest for the building of advanced information systems and to facilitate knowledge level interoperability among heterogeneous information sources. Our objective is to contribute to the building of ontological models in support of information fusion and to exploit these models to provide enhanced knowledge management assistance to military commanders. In this paper, we describe the goal-driven ontological analysis carried out in support of decision aids for above water warfare threat evaluation and weapon assignment. Keywords: Ontologies, high-level information fusion, threat evaluation, methodology.

1 Introduction For a few years, a lot of research work has been dedicated to the advancement of high-level data fusion (situation and impact assessment, resource management), either by trying to better understand the underlying cognitive processes, by developing automated reasoning processes, or by designing appropriate architectures that support these processes. To help contribute to these advances, the JDL data fusion process model has been proposed by the Joint Directors of Laboratories to provide a common reference framework for the fusion community [1]. In their recent revision and extension of the JDL model, the authors highlighted the need for and exploitation of an ontologically-based approach to data fusion process design [2]. Among the related efforts, some aim at formalizing the concepts related to high-level information fusion with the objective to improve human understanding across the data fusion community, and ultimately to facilitate communication between distributed fusion systems. In particular, ontologies have been developed

with different perspectives, e.g. the development of a core ontology for situational awareness [3], the definition of a sensor pedigree ontology for level-one fusion [4], or a philosophical ontological analysis of threat and vulnerability [5]. Recently, research has been undertaken at Defence R&D Canada Valcartier to provide military operators with advanced decision support for above water warfare (AWW) command and control, in particular threat evaluation and weapon assignment (TEWA). The design of such decision aids requires a thorough understanding of the decision-making problem, the cognitive demands and information requirements. To this end, cognitive engineering methods have been used to capture the functional model (goals and processes) as well as the cognitive work and information requirements. Moreover, we proposed in [6] a preliminary work on ontologies for high-level information fusion together with a framework for information integration exploiting ontologies. In this paper, the focus is about the goal-directed ontological engineering approach that we propose to capture and specify the key concepts related to the TEWA domain. The remainder of the paper is organized as follows. In the next section, we describe our approach to the modeling problem in support of AWW TEWA decision aids. We first present the cognitive engineering method used to capture the cognitive and information requirements through a goal-driven process analysis. Then, we focus on the ontological engineering approach and describe the methodologies, languages and tools that we selected to support the building of ontologies for TEWA. Then, considering that there is a need to represent different perspectives of the domain (ontological, functional, and physical views) that are interrelated, we present an approach to map the different models through the domain object layer, and a tool to navigate within the models. The paper ends with conclusions and lessons learned from this effort.

2 Approach Our approach to the modeling of TEWA domain concepts attempts to benefit both from cognitive engineering methods and ontological engineering, the first providing a functional perspective of the domain, and the latter formally specifying the concepts of the domain and their relations from a general perspective. Consequently, this approach maximizes the exploitation of the artifacts produced from different perspectives. We called it a goal-driven approach as it aims to provide an ontological specification of the states of interest for a given task. Cognitive engineering methods provide a formal framework to capture cognitive demands and information requirements, and to model the decision-making problem. Among the proposed approaches, one particular cognitive engineering method that was used for the analysis and design of the envisioned AWW TEWA decision support system is known as the Applied Cognitive Work Analysis (ACWA) methodology [7]. Through this approach, the knowledge acquisition process is coupled to the modeling of work domain. The method occurs in several steps, each producing corresponding artifacts as illustrated in Figure 1. In particular, the Functional Abstraction Network (FAN) model captures the essential domain concepts and relationships that define the problem-space confronting the domain practitioners. The FAN model consists of a function-based goal-means decomposition of the domain, technique pioneered by Rasmussen and his colleagues as a formalism for representing cognitive work domains as an abstraction hierarchy. The goal-function nodes are associated to their cognitive work and information requirements. A work domain analysis is conducted to understand and document the goals to be achieved in the domain and the functional means available for achieving them. The objective of this functional analysis is a structured representation of the functional concepts and their relationships to serve as the context for the information system to be designed. The resulting FAN specifies the domain objectives and the functions that must be available and satisfied in order to achieve their goals. The ontological analysis method exploiting these artifacts is described hereafter.

3 Ontological engineering Domain or content ontologies aim at formally representing the concepts that are relevant to a domain of interest and the relations that exist between them. Ontologies can serve different purposes that have to be identified early in the ontological engineering process. Moreover, the scope of the ontology has to be determined to precisely define the universe of discourse.

Figure 1: ACWA artifacts

In our context, the purposes of a building an ontology for the TEWA domain are:

• To provide a shared understanding of key concepts of the domain, and to facilitate communication between knowledge workers (scientists, subject matter experts, software engineers) and the knowledge-based systems developed to support AWW TEWA (present and future);

• To provide the foundation for domain knowledge representation as an aid to developing next-generation knowledge-based command and control systems in the AWW TEWA domain;

• To serve as a means to integrate information from many heterogeneous information/knowledge sources (databases, doctrinal information, experimental data, etc.), as a key component to build support and fusion knowledge/data bases.

Several methodologies have been proposed to support the development of ontologies [8,9]. In general, the use of a mixed top-down and bottom-up approach to ontology development is recommended. The top-down approach extends the definition of concepts from an existing upper-level ontology, i.e. establish links to upper-level categories that have already been defined within large ontologies or relevant military models. The bottom-up approach adds more specific concepts from additional reference sources. Leveraging from methodologies proposed in the literature and the work domain analysis conducted for this project, we propose a goal-driven ontological development approach that takes advantage of existing methodologies, and consider as a basis the functional analyses/models performed in the domain of interest. Such analyses help derive and refine the concepts of the ontology, and better determine the scope of the ontology.

Workspace DesignWorkspace Design

User ContextUser Context

Decisions in ScopeDecisions in Scope

Deliver InD irect Fire Weapons Systems to Engagement Positions

Arti llary

Howitzer

Bombs

OrientWeaponsSystem

WeaponsSystem

Oriented onTa rget

MLRS

Deliver InD irect Fire Weapons Systems to Engagement Positions

Arti llary

Howitzer

Bombs

OrientWeaponsSystem

WeaponsSystem

Oriented onTa rget

MLRSProvide Sanita tion Services

Provide Transportation

Provide Shelter

Sus tain Military PowerSus tain Military Power

Comply with Local Law/CultureMinimize Collateral Damage Maximize Positive Public PerceptionC omply with Military LawExecute Mission

Protect Troops’ Morale Survivability

Provide Fortifications

>=1

Keep the Civilian Peace

Provide Medical Aid

Apply Military Power

Recoverable

MilitaryPower

Level of

Degradation

SpentMilitar

yPowe

r

Loss

Combined ArmsEffect on

Objecti ve(s)

ManageDirect EffectCapabi liti es

ManageIndirect EffectCapabi liti es

ManageJamming

Capabi liti es

ManageBattlefie ld Deception

Capabi liti es

ManageCounter-Mobi lity

Capabi liti es

Deli verDirect EffectCapabilities

Deli verIndi rect EffectCapabilities

De liverBattlefield Deception

C apabili tie s

De liverCounte r-Mobili ty

C apabili tie s

Di rect Effects

Indirect Effects

Jamming

Battlefield Deception

Counter-Mobi lity

Join Combined Arms

Effects

>=1

Protec t Freedom of Action

Provide CamouflageProvide Thermal Insulation

Provide Electronic Insulation

Engineering Terrain Weather

Protect Military Power

- Maximize Personne l Safety

Protect Military PowerProtect Military Power

- Maximize Personne l Safety

Deliver Direct Fire Projectiles/RoundsDeliver Direct Fire Projectiles/Rounds

Deliver D irect Fire Weapons Systems to Engagement Positions

Ma in Gun

Rifle

Phalanx

Sidewinder

MoveWeaponsSystem

WeaponsSystem

Located atEngagement

Position

Mainta in Projectile Inventory

Provide Platform/Prime Mover

Provide FuelProvide Maintenance

Maintain Water Supply

Prov ide Trained Personne l (Crew)

Move toDistributionCenter(s)

Located inDistributionCente r(s)

DistributeIn Hands ofthe Hungry and ThirstyWater

Supp ly

FoodSupply

Provide Food and Water

Move toDistributionCenter(s)

Located inDistributionCente r(s)

DistributeIn Hands ofthe Hungry and ThirstyWater

Supp ly

FoodSupply

Provide Food and Water

Maintain Food Supply

Deliver InDirect Fire Projec tiles/RoundsDeliver InDirect Fire Projec tiles/Rounds

Move InDirect Fire Weapons System Aim Weapon

Provide SensorsProvide Communications (Signals)

SoundGun

De liverJamming

C apabili tie s

Provide Transportation Ne twork

Decision Requirements

Abstracted Decision:D1 — “Choose combined combat power to achieve the objectives at a specific point in time and space.”

Secondary Decisions: D1a - “Monitor the enemy’s state after the enemy reaches the specific point in time and space. (Goal Satisfaction Monitoring)

D1b - “Choose among the combat resources that can bring their combat power to bear on the specific point in time and space.” (Planning - process availability)

D1c - “Estimate the Enemy’s state after the application of the chosen combat power at the specific point in space and time.” (Planning - choice among alternatives)

D1d - “Determine how the selected combat power is initiated and executed.” (Control - process control)

D1e - “After initiation of combat power, determine if it is currently achieving its objectives.” (Feedback Monitoring)

Side Effects (Other Impacted Goals): What will the impact be of moving combat power (a) to a specific point in space and time. (i.e., what else were they doing and what will happen if they change assignment?)

Decision Requirements

Abstracted Decision:D1 — “Choose combined combat power to achieve the objectives at a specific point in time and space.”

Secondary Decisions: D1a - “Monitor the enemy’s state after the enemy reaches the specific point in time and space. (Goal Satisfaction Monitoring)

D1b - “Choose among the combat resources that can bring their combat power to bear on the specific point in time and space.” (Planning - process availability)

D1c - “Estimate the Enemy’s state after the application of the chosen combat power at the specific point in space and time.” (Planning - choice among alternatives)

D1d - “Determine how the selected combat power is initiated and executed.” (Control - process control)

D1e - “After initiation of combat power, determine if it is currently achieving its objectives.” (Feedback Monitoring)

Side Effects (Other Impacted Goals): What will the impact be of moving combat power (a) to a specific point in space and time. (i.e., what else were they doing and what will happen if they change assignment?)

Functional Abstraction Network:Modeling Critical Domain Relationships

Cognitive Work Requirements:Identifying the Cognitive Demands of the Problem Space

Supporting Information Needs

D1b.1 Location of combat resources currently which have combat power ranges/effectiveness that include the specified point in time and space.D1b.2 Time required to re-aim such combat, if required.D1b.3 Measures of combat power of the combat resources currently within range of the specified point in time and space. (this one needs help)

Supporting Information Needs

D1b.1 Location of combat resources currently which have combat power ranges/effectiveness that include the specified point in time and space.D1b.2 Time required to re-aim such combat, if required.D1b.3 Measures of combat power of the combat resources currently within range of the specified point in time and space. (this one needs help)

0

Dynamics

Alerts

Salience Map

Display Elements

- Combat Power Ratio- Total combat Power

- Selected Combat Power- Push-buttons- Possible Combat Power

- Map (Thumbnail/Magnified Target)

- Labels (Unit Names, Time, etc.- Sub-Labels- Group Emblems

Background

- Deviations from Plan

100

0

Dynamics

Alerts

Salience Map

Display Elements

- Combat Power Ratio- Total combat Power

- Selected Combat Power- Push-buttons- Possible Combat Power

- Map (Thumbnail/Magnified Target)

- Labels (Unit Names, Time, etc.- Sub-Labels- Group Emblems

Background

- Deviations from Plan

100

Representation Design Requirements:Defining Relationship Between Requirements andVisualization Concept

Presentation Design Concepts:Making the Problem Transparent

Information / Relationship Requirements:Defining What Content is Neededfor Effective Decision-Making

The ontology development process occurs in several stages:

1. Define the ontology purpose and scope; 2. Informally specify key concepts in the domain

and their relationships; 3. Refine and formally specify the conceptualization

in a representation language (concepts properties, relations, axioms);

4. Validate and evaluate the ontology. The goal-driven approach ensures that the scope of the ontology is well defined. Moreover, the methodology exploits ACWA artifacts during the stages 2 and 3, as well as relevant military domain models (e.g. doctrine documents, data models) as complementary sources. The characterization of information requirements and information sources supporting the TEWA functions is another input to the ontology development process. The figure 2 illustrates this process exploiting multiple sources.

Figure 2: Ontological engineering exploiting multiple

sources

3.1 Knowledge reuse

Ontological engineering promotes the building of shared and common domain theories in order to facilitate knowledge sharing and reuse. Consequently, the analysis of ontological models or domain knowledge models should be the first and fundamental activity in any ontological engineering activity to benefit from prior modeling efforts. Such analysis can take place at several levels of abstraction: upper-level, mid-level, or specific domain/task-oriented ontologies. A top-down ontological analysis aims at leveraging from the high-level domain-independent concepts defined and structured in an upper-ontology as a result of a philosophical ontological analysis. From a bottom-up perspective, doctrine documents and NATO standards in the domain of interest provide an attempt of

standardization in the domain that should be taken into account during ontology construction. Examples and relevant domain elements are described below.

3.1.1 Military models Military ontological models whose specification includes elements of the TEWA domain are worth examining to leverage from substantial modeling efforts. Knowledge related to the battle-space and military operations have been modeled and standardized in different formats. In this perspective, detailed military data models are worth analyzing as they comprise domain knowledge that might assist in defining concepts related to the TEWA domain, e.g. Identity and Classification for Tracks and their associated Threat. Moreover, consideration of these efforts is important with the objective to be interoperable with next generation combat systems.

3.1.1.1 C2IEDM Data Model The Command and Control Information Exchange Data Model (C2IEDM), now moving to the Joint Consultation Command Control Information Exchange Data Model (JC3IEDM), is a NATO standard for exchanging military information among multi-national allies forces, developed and maintained by the Multilateral Interoperability Programme (MIP)[10]. It serves as the common interface specification for the exchange of essential battlespace information. Consequently, the model is built from operational information exchange requirements between national parties, but it is not intended to represent a comprehensive battlespace ontology. Concepts are organized hierarchically around high-level building blocks entities, in particular the object-type/object-item and action entities, in order to describe:

• The objects in the battlespace. This includes characteristics of the objects themselves, their status, their locations, their interrelationships, capabilities, addresses, and other properties;

• The activities on the battlefield. This encompasses operational plans and orders, reports of current activity, and predictions or anticipation of future activity.

Among the high-level concepts, some concepts in the model overlap with the TEWA domain. In particular, the specification of objects, actions, capabilities, target/target lists, rules of engagement have to be formally represented in our domain of interest. The C2IEDM is specified as a Entity-Relation type data model, and the related documentation provides definitions for all data elements, all relations, as well as explanations and background information. The semantics of concepts is provided in natural language but not formally specified, as the meaning is intended for humans and not for machines.

TEWA Function Model View of Information Sources

Extract Concepts

Extract Concepts

Characterize Information Sources

Information Sources

TEWA Ontology

Info. CharacterizationReport

NATO StandardsOther docs

Map to Information Sources

3.1.1.2 ANEP-33 The Allied Naval Engineering Publication (ANEP-33) [11] is a NATO publication that presents the Combat System Data Model for Interface Analysis (DMIA). The model describes the data required as inputs, the data provided as outputs, and controls of the functions of the combat system. Through the description of the functions, it provides detailed information about the data involved within the processes, e.g. how tracks are identified, classified and categorized, and the attributes that are used to characterize these concepts. Moreover, the concepts of threat, target and engageability/engagement are further defined. These elements are key concepts to be integrated in a TEWA ontology.

3.1.1.3 NATO STANAG 4420 The Display Symbology and Colours for NATO maritime Units (NATO STANAG 4420) [12] is a standard agreement whose purpose is to establish display coding standards for the presentation of spatially displayed tactical information. To this end, it defines the full range of tactical information required by the operational user at the command level (e.g. symbols to indicate a track’s composition and engagement status). This tactical information set is organized as a taxonomy of military entities with possible values specified for the objects. This structure is particularly relevant for consideration in a level-one fusion ontology in support of object identification. These different military models provide relevant information about the concepts involved within the processes they intend to support. Consequently, their analysis helps better characterize the concepts to be contained within a TEWA ontology, by confronting the contents of the model with the ontology being developed based on ACWA artifacts and subject matter experts (SMEs) complementary inputs.

3.1.2 Upper-ontologies It is argued in the literature that domain ontologies should be built on top of a high-level domain-independent ontology, or upper ontology, comprising the fundamental abstract concepts that exist in any universe of discourse, e.g. process, quantity, location, or spatial/temporal entities. In this way, the upper-ontology constitutes a theoretical framework on which to build more specialized domain models. Furthermore, by considering an upper-ontology in a first stage, the domain ontology designer takes advantage of the knowledge and experience already built into the upper-ontology. A study undertaken at MITRE [13] attempts to examine some of these upper-level ontologies and assess their potential applicability in the military domain. Candidate upper ontologies are mainly SUMO, Upper CYC, and DOLCE, each one making ontological choices. In [5], Little and Rogova in

their formal ontological analysis for the development of a threat ontology utilize the Basic Formal Ontology (BFO) upper-ontology to organize general categories of existence derived from philosophical reasoning, i.e. spatial and temporal features. Although upper-level ontologies describe domain-independent high-level concepts, there exist various proposals of such ontologies in the literature, and there is no unified consensual model. In particular, ontological choices made in the development of upper ontologies have implications for their use in domain ontologies, and the impact of using a particular upper ontology within a particular domain is not easy to assess. However, considering upper ontologies built by experts in formal ontology and formal semantics when developing a domain ontology is relevant to highlight general concepts of interest and leverage from upper level modeling efforts. Finally, efforts in the building of mid-level or utility ontologies that embody concepts common across domains (e.g. military) such as time, location, mission, could led to libraries of ontologies that would constitute valuable knowledge to be shared and reused. Our ontological engineering approach focuses on a mixed ontology development that leverages the analysis of functional models and related artifacts, as well as mid-level models (e.g. C2IEDM).

3.2 Conceptualization

In our AWW TEWA context, a functional abstraction network has been produced as a result of the cognitive work analysis of the domain, to capture the functional goals and processes and their interrelations [14]. A simplified version of the FAN is shown in Figure 3. The left side represents the threat evaluation region, and the right side is related to the application of combat power.

Figure 3: TEWA high-level functional model

Threat

Assessment

Manage

Combat Power

Objectives

Mission

Objectives

Intent

Inference

Capability

Inference

Identification

(Classification)

Inference

Object

Detection

Sensor Data

Acquisition

Own

Sensors

Combat Power

Application

Manage Hard

Kill

Manage Soft

Kill

Manage

Deterrence

Target

Acquisition

Localization

Orient Platform

Threat

Assessment

Manage

Combat Power

Objectives

Mission

Objectives

Intent

Inference

Capability

Inference

Identification

(Classification)

Inference

Object

Detection

Sensor Data

Acquisition

Own

Sensors

Combat Power

Application

Manage Hard

Kill

Manage Soft

Kill

Manage

Deterrence

Target

Acquisition

Localization

Orient Platform

The conceptualization aims first at specifying the key domain concepts and their relations. Concepts that are central to the processes are the Track, Identity Threat, Target, Intent, Capability concepts, to name a few. A graphical view of the concept taxonomy and relationships are provided at this stage, as well as a lexicon that defines each concept in natural language. Threat evaluation (or impact assessment) has been the subject of several research efforts (e.g. [15,16]). It corresponds to the ongoing process of determining if an entity intends to inflict evil, injury or damage to the ownship and its interests, by inferencing the identification of the observed objects, and their intent, in order to determine the level of threat. The threat level of a target is based on its intent and capabilities in addition to its relative location [14]. During the process, threats will be categorized as actual, potential, or beyond interest. The capability concept helps both to determine the actions open to enemy forces, and to assess the feasible actions open to friendly forces. In the first case, it is the ability of the target to inflict damage or injury to the friendly forces. It takes into account the characteristics of its weapon systems and surveillance systems, but also other elements such as its location. The intent refers to the will of the target to inflict injury or damage. The analysis of specific behaviors helps determine the intent. The application of combat power is related to actions taken to engage or counter the identified threats (e.g. assignment of weapon systems) based on the capabilities and limitations of the friendly forces. These actions include hard kill, soft kill, and deterrence. The last stage of the conceptualization is the formal specification of axioms, which consists in specifying concepts properties, constraints and rules to add more semantics to the concepts in the formalism provided by the ontology representation language. During the conceptualization stage, access to SMEs is required to adequately model domain knowledge. In particular, discussions occurred during knowledge acquisition to compare the ontology model under construction with artifacts from reference documents, and some differences appeared in the understanding and conceptualisation of the domain (e.g. meaning of a concept, difference in values of attributes).

4 Ontology language and tool The development of computational ontologies requires a representation language and a support tool to facilitate the construction and management of large ontologies.

4.1 Language and tool

To support our ontological development, we chose the Web Ontology Language (OWL), a standard formalism to represent ontologies for the Semantic Web that has been endorsed by the World Wide Web Consortium (W3C) as a recommendation [17]. OWL is rooted in artificial intelligence, knowledge representation and description logics. It is XML-based, and has a well-established formal semantics. The OWL-DL formalism, based on description logics, was chosen as it provides expressiveness while retaining computational completeness and decidability. It also provides the ability to classify the concepts being defined and to perform logical deductions according to the capabilities of description logics. Moreover, the Protégé ontology environment and its OWL plug-in [18] were selected to specify the conceptualization. Ontological models were first graphically developed using the Construct/Visio tool and completely implemented with Protégé, exploiting graphical facilities in both of Construct and Protégé environments. The Construct/Visio plug-in has interesting graphical representation capabilities for drawing the high-levels concepts. Protégé OWL has desired capabilities and support, is largely used and offers multiple interesting plug-ins, in particular to facilitate the representation of multiple models and their relationships. Figure 4 presents the Protégé interface for the TEWA ontology, with the concept hierarchy at the left, and the properties of the highlighted concept in the center.

Figure 4: Protégé interface

5 Multi-dimensional models To complement our approach, we proposed to provide a means to map and visualize the different artifacts built as part of our modeling activities for the TEWA domain, namely: 1) the functional model (FAN); 2) the ontological

model; and 3) an additional model characterizing the information sources supporting the TEWA processes (referred to as the physical model). Given this objective, the approach and support tool should facilitate the representation of each model, the mapping of the different layers, the navigation within the multi-dimensional model to look at the relationships between the concepts from each layer, and the extension of each model. The proposed approach exploits the Protégé environment used for ontological engineering, and the Jambalaya tool provided as a Protégé plug-in. The tool facilitates both the representation of each model, and the linkage of the models and navigation between layers. Figure 5 presents the Jambalaya interface showing the representation of the different models. Each of the three squares represents one model and the links between the models are illustrated. This tool proved to be useful for navigating between terms of the ontology and for visualizing the relationships between terms. Furthermore, it can handle large data sets. Within the proposed environment, the user can navigate within the multi-structure and look at relationships between concepts. For example, it is possible to look at a particular FAN node and visualize which information sources support the FAN processes, or to look at a particular domain concept and see which FAN nodes manipulate this concept. Figure 5 highlights the relationships linking a FAN node and some domain concepts. The Jambalaya user interface can be customized to provide different graphical views according to the user preferences.

Figure 5: Jambalaya interface visualizing

multi-dimensional models

6 Lessons learned and conclusions In this paper, we presented an ontological engineering approach for the modeling of the TEWA domain, the corresponding conceptualization, and the tools that were exploited in support of this task. Some lessons learned from our experiment are listed hereafter.

The goal-driven ontological analysis aimed at developing domain ontologies based on the products of cognitive work analysis methods. By doing so, the scope of the ontology is well defined, the modeling efforts are restricted to the essential concepts, but in counterpart the produced ontology is specific and application-oriented, and consequently less reusable. A next step would be to build a more generic ontology, i.e. to shift away from trying to adhere rather strictly to the FAN terminology. The developed ontological model represents only a part of a much larger development effort required to produce a complete AWW TEWA ontology. Extensions and iterations are required to capture concepts to support additional AWW TEWA functions. Our experiments confirmed that the development of ontologies should be an incremental process, validated by subject matter experts at each stage of the process. This effort helped clarify the domain and explicitly specify the definition of the concepts. Even if the study was based on cognitive engineering products, the ontological engineering activity required the participation of SMEs to help clarify important concepts and make them unambiguous. Knowledge reuse was considered not straightforward even if the considered models overlap. In particular, some difficulties were encountered in aligning the terminology in common use within NATO (i.e. the international TEWA community) with the terminology used within the FAN. Axiom specification is complex in the sense that it requires a thorough understanding of the domain as well as the expressiveness and limits of the formalism used to model the concepts properties. Collaboration with SMEs was also required as ACWA artifacts did not capture these aspects. Moreover, an ontology aims at specifying general domain knowledge, so we considered that axioms should be limited to express generic constraints or properties, and should not represent specific expert rules that should be part of a separate knowledge base. The study required to experiment with standards and advanced tools to manage and visualize ontologies. Graphical tools are interesting in a first stage of ontological engineering because they are intuitive and useful for communication with SMEs. In a second stage, the Protégé tool was appropriate to formally specify the concepts. Moreover, for future activities, different avenues are envisioned. The completeness of the ontology should be evaluated using various representative scenarios examples, or uses cases, to validate that the concepts are properly specified, and to assess if the ontology is rich enough to deal with complex situations. A OWL-based C2IEDM ontology has been developed as part of a parallel initiative [19]. It would be interesting to leverage this model to represent the high-

levels military objects, and to analyze TEWA related-concepts that the ontology already comprises. Finally, the ontology is intended to be exploited: 1) for the design of support/fusion data and knowledge bases, and, 2) as the foundation for the representation of domain knowledge in the building of TEWA decision aids.

References [1] A. Steinberg, C. L. Bowman, and F. E. White

(1998), Revision to the JDL data fusion model, Joint NATO/IRIS Conference, Quebec City, October.

[2] J. Llinas, C. Bowman, G. Rogova, A. Steinberg, E. Walz, F. White (2004), Revisiting the JDL data Fusion Model II, in Proceedings of the 7th International Conference on Information Fusion, Stockholm, Sweden.

[3] Matheus, C.J., Kokar, M.M., Baclawski, K., (2003), A Core Ontology for Situation Awareness, in Proceedings of Sixth International Conference on Information Fusion, Cairns, Australia, July.

[4] C. Matheus, D. Tribble, M. Kokar, M. Ceruti and S. McGirr, (2005), Towards a Formal Pedigree Ontology for Level-One Sensor Fusion, In Proceedings of the 10th International Command & Control Research and Technology Symposium, McLean, VA.

[5] Little, E., Rogova, G., (2006), An Ontological Analysis of Threat and Vulnerability, in Proceedings of the 9th International Conference on Information Fusion, Italy.

[6] A.-C. Boury-Brisset, (2003), Ontology-based approach for Information Fusion, in Proceedings of the 6th International Conference on Information Fusion, Cairns, 8-11 July, Australia, pp. 522-529.

[7] W.C. Elm, S.S. Potter, J.W. Gualtieri, E.M. Roth, and J.R. Easter (2003), Applied Cognitive Work Analysis: A Pragmatic Methodology for Designing Revolutionary Cognitive Affordances, in Hollnagel, E. (Ed.), Handbook of Cognitive Task Design, Mahwah, NJ: Erlbaum.

[8] D. Jones, T. Bench-Capon, P. Visser, (1998), Methodologies for Ontology Development, in Proceedings of IT&KNOWS (Information Technology and Knowledge Systems) of the 15th IFIP World Computer Congress, Budapest, Hungary.

[9] Gomez-Pérez, A., Fernandez-Lopez, M., Corcho, O., (2003), Ontological Engineering with examples from

the areas of knowledge Management, e-Commerce and the semantic Web, Springer.

[10] The Multilateral Interoperability Programme (MIP), C2 Information Exchange Data Model, available at http://www.mip-site.org.

[11] ANEP-33, (1993), Combat System Data Model for Interface Analysis, Allied Naval Engineering Publication (ANEP) – 33, Edition 1, July 1993.

[12] STANAG 4420, (1994), Display Symbology and Colours for NATO Maritime Units, Standardization Agreement (STANAG) 4420, Edition 2, 1994.

[13] Semy, S., M. Pulvermacher, L. Obrst. (2004), Toward the Use of an Upper Ontology for U.S. Government and Military Domains: An Evaluation. MITRE Technical Report 04B0000063, September.

[14] Paradis, S. Benaskeur, A. Oxenham, M. Cutler, P., (2005), Threat evaluation and weapons allocation in network-centric warfare, in Proceedings of the 8th International Conference on Information Fusion, July 25-28, Philadelphia.

[15] Steinberg, A. (2005), An approach to Threat Assessment, in Proceedings of the 8th International Conference on Information Fusion, July 25-29, Philadelphia.

[16] J. Roy, S. Paradis, M. Allouche, (2002), Threat Evaluation for Impact Assessment in Situation Analysis Systems, in Proceedings of the SPIE Conference, Vol. 4729, Signal Processing, Sensor Fusion, and Target Recognition XI, Orlando, 1-5 April 2002.

[17] Dean, M. and Schreiber, G. eds. (2004), OWL Web Ontology Language Reference, W3C Recommendation. http://www.w3.org/TR/owl-ref/, February, 2004.

[18] Protégé Ontology Editor and Knowledge Acquisition System, Protégé home page, http://protege.stanford.edu.

[19] E. Dorion, C. Matheus, M. Kokar, (2005), Towards a formal ontology for military coalitions operations, in Proceedings of the 10th International Command & Control Research and Technology Symposium, McLean, VA, June.