An Ontological Approach to Enhancing Information Sharing in Disaster Response

Abstract

Managing complex disaster situations is a challenging task because of the large number of actors involved and the critical nature of the events themselves. In particular, the different terminologies and technical vocabularies that are being exchanged among Emergency Responders (ERs) may lead to misunderstandings. Maintaining a shared semantics for exchanged data is a major challenge. To help to overcome these issues, we elaborate a modular suite of ontologies called POLARISCO that formalizes the complex knowledge of the ERs. Such a shared vocabulary resolves inconsistent terminologies and promotes semantic interoperability among ERs. In this work, we discuss developing POLARISCO as an extension of Basic Formal Ontology (BFO) and the Common Core Ontologies (CCO). We conclude by presenting a real use-case to check the efficiency and applicability of the proposed ontology.

1. Introduction

When a disaster occurs, a streamlined operational response is crucial to handling the disaster effectively. To respond within seconds, an appropriate and effective response demands a detailed plan with clearly articulated roles and responsibilities. It involves a complex network of diverse Emergency Responders (ERs) from different Emergency Response Organizations (ERO) such as fire departments, police, and healthcare services. In fact, many after-action reports from major disasters (for example 11 September 2001, 13 November 2015, Hurricane Katrina) have pointed to communication difficulties among EROs as a major failing, and have expressed concerns regarding the abilities of EROs to collaborate successfully [1].

Disaster management research frequently cites a problem encountered by ERs: the use of radio communication as a factor that makes inter-organization communication extremely difficult. In a recent survey of EROs (In-Building Public Safety Communication Survey, 2018), over 65% of respondents said they had experienced some sort of communication failure within the past twenty-four months while responding to an emergency via radio. But there are other ways in which the absence of adequate communication and information sharing among the actors involved may lead to a breakdown in the operational response. Not having an operational picture of what is happening in the field will consequently extend the time required to bring a full resolution of the disaster. ERs require timely information sharing and data exchange to get a real-time operational picture of the situation. Yet each ER has its own technical vocabulary, and as a result ERs encounter misunderstandings, a deficiency of semantic interoperability, and a lack of information sharing among the different actors. Consequently, the operational response process can be slow, inefficient, and subject to failure.

To overcome these issues, we here aim to formalize the complex knowledge of the different French ERs (e.g., firefighters, police, gendarmerie, healthcare services) in order to provide a common, shared vocabulary to facilitate information exchange and enable collaboration. To do so, we discuss an ontological approach that aims to enhance information sharing among ERs by proposing a modular suite of ontologies, named POLARISCO, in order to provide a common semantic framework. In particular, POLARISCO considers different kinds of disasters, needed resources, and corresponding actions, taking into account

• that each ER has its own process of intervention, means, roles, and so on. This may have consequences for collaboration among the actors involved;
• that each type of ER has its own unique vocabulary, including firefighters, police, gendarmerie, healthcare units, and public authorities;
• that there are different types of victim states;
• that disasters are events that occur in specific spatial-temporal regions. Hence, POLARISCO also represents the times and places where disasters occur.

POLARISCO captures semantically the knowledge of ERs involved in a disaster response. In the Disaster Management literature there is no ontology that covers all such processes and defines the vocabulary in a way that captures the perspectives of all involved actors. Because the diversity of ER vocabularies was bound, naturally, to complicate the design of the ontology, we adopted the principle of modularization. Since the proposed ontology modules must be mutually interoperable, it is advantageous if they share a common top-level ontology [2] thoroughly tested in use. For this reason, we chose the most widely adopted upper-level ontology in use: Basic Formal Ontology (BFO), as well as the Common Core Ontologies (CCO) ontology ecosystem, which provides a suite of mid-level ontologies which could be reused in developing our ontology modules.

POLARISCO is proposed in the context of the project POLARISC (Plateforme Opérationnelle d’Actualisation du Renseignement Interservices pour la Sécurité Civile) [3,4]. POLARISC is a French national project initiated in 2017. It addresses all ER requirements by proposing an interoperable inter-services software solution for reliable and timely information sharing for operational management of large-scale disaster situations. The focus is on offering to all ERs a picture of the situation as it evolves in real time in order to enable multi-stakeholder and multi-level coordination within the EROs, including firefighters, police, gendarmerie, healthcare units, and public authorities.

POLARISCO facilitates the bringing together of available information in consolidated form in a way that improves information accessibility for ERs. Figure 1 shows the architecture of the POLARISC platform, which is composed of three layers [5]:

• a user interface layer that offers a real-time operational picture by respecting the graphical charter and color code of each stakeholder,
• the POLARISC mediator, which plays the role of gateway between end-user and the core system to provide a suitable representation of the requested information according to ERs’ specificities, and
• the core system, which is composed of a knowledge base based on a suite of ontologies named POLARISCO (POLARISC Ontology) [6].

These are extended by interactions with domain experts and by a set of integrated services such as the messaging service [7], victim evacuation service [8], and geospatial resources database.

The remainder of this paper is organized as follows. We start with a description of the operational level of disaster response and of the different ER requirements, which illustrates the motivation of this paper. We also structure our proposed solution according to the Framework of Enterprise Interoperability (FEI) [9]. Section 3, provides an overview of existing ontologies proposed in the field of disaster response. Section 4 details the POLARISCO development methodology and outlines the proposed ontology modules. In Section 5, we discuss how POLARISCO is evaluated and validated with a use-case regarding a messaging service that enables semantically interoperable information exchange among ERs. In Section 6, we discuss the proposed ontological approach and the resulting ontology according to our design principles and requirements. We conclude with a brief discussion of planned future work.

2. Background and Motivations

In this section, we describe the process of disaster response in order to highlight its main challenges and the requirements of ERs that motivate us in proposing the modular suite of ontologies, POLARISCO. We then discuss the advantage of using ontologies to promote semantic interoperability among ERs when responding to a disaster.

(1)

Disaster management can be defined as “the process of planning and taking actions to minimize the social and physical impact of disasters and reduce the community’s vulnerability to the consequences of disasters” [10]. It is a multifaceted process that comprises the following four main phases: Prevention, Preparation, Response, and Recovery (PPRR). Each of these phases may be identified by the approach they take to lessening disaster impact: Prevention involves taking appropriate strategies to prevent a potential hazard or a natural phenomenon from causing harm to either people or the environment.

(2)

Preparation is a state of readiness and is brought about by taking suitable measures to respond in advance of any disaster.

(3)

Response is an aggregate of processes that seeks to counter the harmful effects of a disaster as rapidly and effectively as possible by mobilizing the appropriate organizations and resources in a coordinated manner. Examples include search and rescue, firefighting, mass evacuation, and restoring public order.

(4)

Recovery refers to the process of returning the affected area back to normalcy.

Our focus here is on the response phase of disaster management. In fact, when a disaster occurs, a streamlined response is crucial to effective handling. It is conducted mainly on three different levels based on the command level at which decisions are being made. First is strategic management, the highest level of decision making, which consists of an organization’s process of defining its plans and making decisions allocating the appropriate resources. Second, the tactical level, concerns translating strategic objectives into actions. Third, the operational level, consists of designing and orchestrating operations according to the tactical plan in order to accomplish strategic goals within the areas of operation. It involves a complex network of diverse ERs such as firefighters, police, and healthcare personnel from different EROs. The involved ERs must interact and coordinate their activities in order to effectively respond to the disaster.

Because this is a hierarchical command-and-control system, initial orders are issued from the strategic to the tactical level and then on to the operational level, with information subsequently passed back up through the chain of command. In fact, there is no direct communication among ERs from different EROs on the disaster site and also among ERs and the strategic level.

Almost without exception, reports and reflections after disasters express concerns over the EROs’ abilities to collaborate. The last few decades demonstrate that inadequate communication and information sharing among the involved actors in disaster response may lead to a breakdown in the operational response. An example can be found in the concluding report on the terror attack in Norway on June 22, 2011, stating that the various EROs could not effectively communicate and coordinate their efforts. Furthermore, these challenges were highlighted by the September 11, 2001, and November 13, 2015 terrorist attacks, where lack of coordination led to a disorganized multi-agency response [11]. Almost fourteen years separate these two terrorist attacks and yet the challenges are still the same. Thus, the need for all actors to be able to intercommunicate when responding to a disaster is paramount.

However, each ER has its own information system and its own technical vocabulary. There is a lack of a common language among stakeholders [12], as they use different names for the same things or different definitions for the same terms. The resultant semantic heterogeneity of data leads to very serious issues since there can be several possible interpretations of any given expression. This issue leads to a misunderstanding and a lack of coordination and data sharing among the ERs.

With the increasing amount of data coming from different sources, there is a strong need to determine the meaning of the information to be exchanged with sufficient precision to enable interpretation by software applications [13]. Therefore, enabling semantic interoperability is a key component that can empower data sharing and orchestration of the collaborative process in order to build a coherent disaster response.

To promote semantic interoperability among ERs, we start by structuring our proposed solution according to the Framework of Enterprise Interoperability (FEI), which was introduced by the European Virtual Laboratory for Enterprise Interoperability (I-VLab) and is now published as an international standard (ISO 11354-1) [11]. FEI defines a classification scheme for knowledge interoperability according to three major dimensions, as illustrated in Figure 2. First, solutions to interoperability problems can be characterized according to interoperability approaches. Interoperability problems can then, second, be localized into interoperability barriers, and third, characterized under different interoperability concerns [14].

Three types of interoperability barriers that can get in the way of information sharing and exchange are defined: First, conceptual barriers, which concern syntactic and semantic heterogeneity of information. Second, technological barriers, which refer to the incompatibility of information technologies such as middleware platforms, protocols, and so on. And third, organizational barriers, which concern the collaboration of several organizations that wish to exchange information but which have organizational structures which themselves create barriers to communication. When the channels of communications are not the same, and stakeholders do not know where to go for the information they need, communication issues can arise. Accordingly, in this work, we intend to resolve conceptual and organizational barriers by developing and exploiting a common semantic terminology among and across ERs.

Enabling interoperability among systems is not only a matter of removing barriers; it also matters how these barriers are removed [15]. There are three ways in which this can happen. First, the integrated approach refers to the use of a common format, resulting in integration of systems rather than interoperability between them. Second, the unified approach signifies that there is a common format but only at a meta-level. This establishes semantic equivalence among information in a way that enables mapping between models used at lower levels, though in a way that may engender some loss of semantics. Third, the federated approach involves no imposed format at all but rather a shared ontology. Considering that each ER has its own vocabulary, processes of intervention, types of actions and so on, we used the federated approach to establish interoperability on the fly. This means that we take the view that interoperability accommodation should not be imposed upon existing data models, languages, and methods of work. Rather, each ER community should maintain control over its own data but with a capability to work with other stakeholders through a set of collaborative processes through which they become linked together virtually.

Ontologies have been identified as an effective means to implement semantic integration and achieve information interoperability along these lines. They offer the richest representations of machine-interpretable semantics for systems and databases [16]. They serve as both knowledge representation and as mediation to enable heterogeneous systems interoperability [17]. Thus, to overcome semantic heterogeneity and to foster a consistent shared understanding of information, the use of ontologies is crucial [18].

The principal classes of the POLARISCO ontology are data, service, process, and business. In this context, data (different semantics, in different formats and stored in different databases of ERs) is employed by services (different functions and roles of each stakeholder) and services are used by processes (coordination of ER interventions) to perform business (multi-organization response to a disaster).

3. Ontologies in the Disaster Response Domain

Different types of ontologies and meta-models have been proposed in the literature to define terms related to disaster response. The existing ontologies and meta-models are reviewed in what follows on the basis of their respective coverage domains in the field of disaster response, including disasters, stakeholders, victims, roles, processes, resources, and so on.

The EMERGEL ontology, proposed in the context of the DISASTER project [19], focuses mainly on the mapping of different pre-defined information artifacts, taking account of how information represented in the different languages used in Europe. It reuses the class event from the DOLCE top-level ontology and draws also on other vocabularies such as FOAF (Friend Of A Friend) [20] that are used to model people in an emergency situation. It is composed of vertical modules that represent the various stakeholders (fire domain, health domain, etc.) and two horizontal modules that represent time and space. The ontology mapping is used to support specific translations between stakeholders from different countries. However, this ontology lacks treatment of operational information (such as the technical vocabulary of each ER community). It may be more useful in decision making at the strategic level rather than the operational level.

OntoEmergePlan is a domain ontology that aims to support models and systems that focus on the systematic generation of emergency plans. It is developed through analysis of emergency management processes in England, Australia, and the USA. It defines mainly emergency processes and activities, resources, roles, and environments [21]. However, it does not cover all the operational vocabularies of ERs.

The EDXL-RESCUER ontology [22] is the conceptual model of the RESCUER project. It uses EDXL (for: Emergency Data Exchange Language) standards to model the coordination and exchange of information with legacy systems. In fact, EDXL standards are developed by OASIS (Organization for the Advancement of Structured Information Standards). The focus of EDXL-RESCUER is mainly on providing alerts. It is composed of four ontologies, one for each EDXL package, namely: EDXL-DE (distribution element), EDXL-RM (resource messaging), EDXL-CAP (common alerting protocol), and EDXL-SitRep (situation reporting).

Another ontology using EDXL standards as basis is the PS/EM Communication ontology (Public Safety and Emergency Management) [23], which is proposed in the context of the IDA project (Institute for Defense Analyses). To develop the ontology, authors used three EDXL standards for messaging distribution elements hospital availability exchange, and common alerting protocol, respectively. The ontology is constructed by adding specializations to the upper-level ontology BFO and the mid-level ontologies CCO classes. However, this ontology does not cover all types of communication among ERs; it is focused only on alert messages.

ResOnt, described in [24], represents situations that arise during rescue operations in order to support situation awareness. It aims to support French first responders in data interpretation during rescue operations. ResOnt is based on the upper-level ontology SUMO and reuses classes from existing ontologies such as EMERGEL. Mainly, it defines events, resources, and tasks. However, the proposed ontology is not as yet evaluated for implemented. In addition, it is dedicated only to firefighters and healthcare staff and only to be used in day-to-day emergencies. ResOnt does not cover the operational vocabulary of the French stakeholders.

In the same context, authors in [25] provide the BFER (Building Fire Emergency Response) domain-model. This describes the knowledge that can be used by firefighters inside a building during rescue operations. The domain model consists of four components; an event component that contains elements that describe the building fire emergency characteristics (for example date, time, area), an actor component that defines properties and tasks of responders, an objective component that contains the goals to fulfill, and a buildings component that depicts the characteristics of the building (for example building type, mode of access, and so on). The BFER domain-model does not consider the operational processes of stakeholders.

In [26], authors focus on knowledge related to firefighters and propose an Emergency Fire (EF) ontology, which defines fire incidents, building features, resources and response actions. It formalizes protocols used in tactical and strategic planning.

Haghighi et al. [27] propose DO4MG (Domain Ontology for Mass Gatherings), which describes the domain knowledge required for planning and managing medical services in mass gatherings. It also covers medical resource allocation in emergency management. The main classes of DO4MG are mass gathering, gathering type, mass gathering plan, event venue, crowd feature, and environmental factors.

Santos et al. [28] suggest a meta-model for handling infrastructure-related adverse events called BFiaO (Basic Formal infrastructure incident assessment Ontology). But, it did not provide models for a catalog of adverse events or of the means needed for an adequate response.

The authors in [29] aim to solve the problem of spatial data heterogeneity in emergency situations and their transmission to stakeholders. To do so, they propose an emergency management ontology (EMO) by using a dynamic data model and various existing data sets. The ontology is composed of two parts; a static and a dynamic data ontology (for example hydrology ontology and meteorology ontology, respectively). The authors also propose separate domain ontologies that define stakeholders’ knowledge in a way that is linked to the emergency management ontology.

The SoKNOS ontology [30] includes in its coverage domain resource planning, damages, and geo-sensor information. It is a core domain ontology on emergency management aligned to the top-level ontology DOLCE. It imports a set of ontologies including resource, damage, and geo-sensor discovery ontologies. The aim is to categorize types of damage, resources, and the relations between them.

The authors of [31] put forward a meta-model and its corresponding Ontology Web Language (OWL) formulation in the context of the project ISyCri (Interoperability of Systems in Crisis Situations) in order to define the generic dimensions of crisis characterization.

Xiang et al. [32] documents an emergency response ontology (ERO) based on a generic emergency response workflow. It defines knowledge of four major phases; response preparation, emergency response, emergency rescue, and aftermath handling. The aim is to standardize a set of generic semantic concepts related to the four mentioned phases. But, concerning the emergency response and rescue phases, it includes only stakeholders dispatch on the emergency scenes and their roles (e.g. evacuation, medical aid, scene control, monitor and alert). The proposed ontology is too general to be used in operational disaster response.

In the same context, a generic and domain-independent disaster management metamodel is presented in [33]. It divides common concepts that exist in many other disaster management models into four different classes of mitigation, preparedness, response, and recovery.

Gaur et al. [34] propose the Empathi ontology for emergency managing and planning relating to hazard crisis. This ontology is based on the automatic recognition of disaster-related terms mentioned in social media conversations. It defines hazard situational awareness and events and their impacts on the affected population and infrastructure. It is linked to different vocabularies including FOAF (which describes people and associated events), LODE (Linked Open Descriptions of Events) that defines events, and so on.

Other ontologies like MOAC (Management of Crisis vocabulary) [35] and HXL (Humanitarian eXchange Language) [36] define crisis and damage types, response activities, and resources. HXL is proposed by the united nations office for the coordination of humanitarian affairs. It aims to contribute to the automatization of data exchange process for disaster response, focusing specifically on improving information flow among decision-makers during resource allocation.

Bannour et al. [37] present a Crisis Response Ontology (CROnto) that defines crisis features, crisis effects, and crisis responses. It formalizes mainly disasters, the damage they cause, resources, and organizations. It is expected that the proposed ontology will be exploited by an intelligent decision support system in order to improve crisis management and to suggest real-time strategic response plans. Moreover, the focus is on contributing to strategic planning more than on operational response.

Table 1. Comparative study of existing disaster management ontologies.

Ontology	Disasters	People	Organization	Roles	Processes	Resources	Time & Space	Communication	Literature
EMERGEL	✔	×	✔	×	×	✔	✔	×	[19]
OntoEmergePlan	×	×	✔	✔	✔	✔	×	×	[21]
SoKNOS	×	×	×	×	×	✔	×	×	[30]
EDXL-RESCUER	×	×	×	×	×	×	×	✔	[22]
ResOnt	×	×	✔	✔	×	✔	×	×	[24]
EMO	×	×	✔	×	×	✔	✔	×	[29]
ISyCri	✔	×	×	×	✔	×	×	×	[31]
PS/EM	×	×	×	×	×	×	×	✔	[23]
BFER	×	×	✔	✔	×	✔	✔	×	[25]
EF	×	×	✔	×	✔	✔	×	×	[26]
DO4MG	×	×	×	×	×	✔	×	×	[27]
BFiaO	✔	×	×	×	×	✔	×	×	[28]
ERO	×	×	✔	×	×	×	×	×	[32]
Empathi	✔	✔	×	×	×	×	×	×	[34]
MOAC	✔	×	×	×	✔	✔	×	×	[35]
HXL	✔	×	✔	×	×	×	×	×	[36]
FOAF	×	✔	✔	×	×	×	×	×	[20]
CROnto	✔	×	×	×	✔	✔	×	×	[37]

summarizes our comparison of the studied ontologies and meta-models in terms of their coverage of the disaster response process. The reviewed ontologies and meta-models are restricted either to one ERO, to a specific type of case, or to a specific purpose [38]. They define knowledge about organizations, resources, processes, or disasters, but not about all of these. Furthermore, none of the mentioned contributions cover the operational vocabularies of the different ERs in detail in a way that the ontology could be used to promote semantic interoperability between the different stakeholders. According to the FEI, these ontologies focus only on data and services while process and business are two major concerns that should be considered when addressing interoperability requirements. Once they are taken into account, they represent the orchestration of stakeholders’ actions. This motivates us to develop a shared vocabulary between the operational ERs (firefighters, healthcare services, public order forces, and public authorities) in order to enhance collaboration and communication during multi-agencies disaster response. In this work, we aim to define disasters and their different types, when and where they occur, the involved stakeholders; their roles and chain of command, victims, resources, and so on.

4. POLARISCO: POLARISC Ontology

This section describes the methodology we use to build the proposed modular suite of ontologies. POLARISCO aims to capture the knowledge of the various stakeholders in a formalism in a language that expresses logical relationships among the different terms and to provide a foundation for semantic interoperability among diverse ERs. The aim is to ensure that all parties share such derived information to the same extent. That is, it aims to establish a common understanding of information that needs to be shared.

To design the proposed ontology, a methodology that guides and manages the development process is key. In fact, the utility of an ontology depends entirely on its development methodology. An ontology development methodology comprises a set of established principles, processes, practices, methods, and activities used to design, construct, evaluate, and deploy ontologies [39]. In [40], the authors discussed the various methodologies proposed in the literature including OntoClean, METHONTOLOGY, and NEON. In this work, we adopted METHONTOLOGY [41] as a development methodology. It is the most mature approach [42], and one of the most comprehensive methodologies [39] to build an ontology. This methodology consists of five main steps of development activities: specification, conceptualization, formalization, implementation, evaluation, and maintenance.

The ontology development process starts with the specification phase, where the purpose of the ontology is defined (including its intended uses, scenarios of use, end-users) and its domain and scope, and defining the Competency Questions (CQs) following the set of objectives. CQs consist of a set of questions that the ontology must be able to answer [43]. It includes also knowledge acquisition and elucidation from relevant literature, conducting interviews with experts, and even drawing from other ontologies. Second, the conceptualization phase concerns organizing and structuring the acquired knowledge in a complete Glossary of Terms (GT) and the construction of a taxonomy of classes. Taxonomy is often referred to as the backbone of an ontology built using the relation “is_a” [44]. Third, in the formalization phase, in which the conceptual model is transformed into a formal model by establishing semantic relations among classes. Then, the implementation phase requires the use of an ontology development environment to implement the ontology. Afterward, the evaluation phase is to carry out a technical evaluation of the ontologies [41]. The final phase is maintenance. We adjusted METHONTOLOGY to meet our needs relating specifically to the fact that we see ontology development as a necessarily iterative process [39]. Thus, we added a review and revision step to enable the iterative development of our proposed ontological modules. Furthermore, we added to the evaluation step a phase of testing the ontology in relation to a concrete use case.

4.1. Specification

In this section we provide details concerning objectives, requirements and competency questions for the proposed ontology.

4.1.1. POLARISCO Objectives

POLARISCO is a domain ontology built with the principal goal of making the best possible definition of the terms in the technical vocabularies of the various stakeholders. It was developed in order to establish a commonly shared conceptualization that defines classes and their relationships to support semantically interoperable information exchange among the ERs involved in the process of disaster response. It will be used to provide a common understanding of the exchanged data for improving communication and interaction among the involved stakeholders.

4.1.2. POLARISCO Requirements

There have been many attempts to define clear principles for consistent and useful ontologies [45,46,47]. Among these principles is one that concerns the need for shared alignment. This principle states that it is advantageous if the ontologies that will be shared among multiple actors share a common upper layer of well-defined classes. Any class of the ontology should be defined in a consistent manner according to a top-level ontology. The use of such an ontology provides a common ontological foundation for the domain ontologies at lower levels by defining the most general domain-independent categories of reality, such as time and space, objects, events, processes, and so on [48]. It allows more effective quality assurance of ontology development.

The use of upper-level ontologies facilitates the alignment among several domain ontologies and promotes data interoperability. In other words, if the ontologies one wishes to use are aligned to a standard upper-level ontology, this will make the task of aligning each ontology to one another easier.

Upper-level ontologies play much the same role as libraries in software programming. Once they are used, one could reuse the defined classes and relationships and inherit the inferencing capabilities furnished by them. Reusing well-established ontologies in the development of a domain ontology allows one to take advantage of the semantic richness of the relevant classes and logic already built into the reused ontology. In this way, developing a domain ontology becomes an easier that requires less time. Moreover, the aim is to avoid having several incompatible domain ontologies. The use of upper-level ontologies for integrating information and sharing knowledge among heterogeneous sources has been motivated in various related works [49,50]. Here, the use of upper-level ontologies is fundamental to ensuring interoperability among the different proposed modules.

To address the diversity of ER vocabularies we adopted the strategy of ontology modularization. This means that the construction of our ontology framework is based on a combination of self-contained, independent and reusable modules [51]. This reduces the complexity of ontology development and enables each module to be developed and tested independently. The idea is that the separate ontological modules will be able to stand alone. Therefore, the key requirements of POLARISCO framework are listed as follows:

• Each ontology module is aligned with a top-level ontology and reuses classes from mid-level and domain ontologies.
• The framework as a whole applies the principle of modularization.
• The ontologies within it together represent the domain of disaster response.

4.1.3. Competency Questions

CQs consist of sets of questions stated in natural language that the ontology must be able to answer [43]. To do so, the knowledge domain that the ontology should cover is explored by referring to domain experts (Figure 3). For each disaster, we should know the time and space in which the disaster occurred, the involved stakeholders with their roles and chain of command, the engaged means and organizational structure, action centers, victims and their states. CQs should cover all needed information mentioned in the knowledge domain. We defined the CQs for POLARISCO in coordination with domain experts (firefighters, healthcare units, police, etc.) and using their domain knowledge. Any scenario that will be used to validate the proposed ontology framework should be able to provide answers to the defined CQs.

Some examples of CQs that POLARISCO should be able to answer are:

CQ1.

What is the nature of the disaster <X>?

CQ2.

When did the disaster <X> take place?

CQ3.

Where did the disaster <X> take place?

CQ4.

What is the criticality level of the disaster <X>?

CQ5.

Which ERs are involved in the operation <X>?

CQ6.

Where was the advanced medical post of <X>’s healthcare units located?

CQ7.

Who was the operational commander of the <X> operation?

CQ8.

Who was the public authority that commanded the <X> operation?

CQ9.

What were the actions of the ER [Y] in the operation <X>?

CQ10.

What is the definition of the term absolute emergency?

CQ11.

Who is competent to search and rescue persons drowning as a result of <X>?

CQ12.

How many people were affected by <X>?

CQ13.

What was the state of the victim [W] of <X>?

CQ14.

What means of transport were used in the operation <X>?

CQ15.

What types of means are needed to respond to a forest fire?

CQ16.

What are the available means in case <X>?

CQ17.

How many beds are available in the hospital [V]?

CQ18.

Where was the action center for <X> located for ER <Y>?

CQ19.

Who sent and who received messages pertaining to <X> and at what times?

CQ20.

What is the type of message [T]?

4.1.4. Knowledge Acquisition

To discover, elicit, and extract knowledge about the field of disaster response, we conducted interviews with stakeholders of each ERO (including firefighters, healthcare units, police, gendarmerie, and public authorities) and we studied their technical resources and feedback documents to get specific and detailed knowledge about the classes of entities involved, their properties, and their relationships [52]. In addition, we studied many ontologies proposed in the field of disaster response to identify the needed terms, including RESCUER-EDXL, EDXL-RM (Resources Messaging), and many others.

4.2. Conceptualization

In this phase, the domain knowledge is organized in a GT and then structured in a taxonomy. That is, it consists of defining a hierarchy of classes linked by subclass or ‘is a’ relations by starting with a single top-most class connected to all other classes through unique branches [45]. In fact, the hierarchy of terms is defined following the philosophy of the widely used top-level ontology Basic Formal Ontology (BFO). In what follows, we present this ontology, the mid-level ontologies which fall beneath it, and then the proposed modules that represent the domain of disaster response.

4.2.1. Basic Formal Ontology (BFO)

A top-level ontology is used as a foundation that provides a representation of that portion of reality that is common across all domains. In [50], several upper-level ontologies were discussed, and we argued for the choice BFO with the twofold justification, that it is realist and that is reused by over 400 domain ontologies. A realist ontology represents the world as it is, — we might say that the ontology encapsulates the knowledge of the world that is associated with the general terms used by scientists in the corresponding domains [45]. BFO is a formal and domain-neutral top-level ontology that is realized in this sense. It is designed to represent at a very high level of generality the types of entities that exist in the world and the relations that hold among them. It is utilized as a starting point for the categorization of entities and relationships by many domain ontologies especially in the biomedical, military, and intelligence domains, and it is the first ISO standard top-level ontology (ISO/IEC 21838-2).

As a starting point, BFO uses the class entity as a common representation of anything that exists, including objects, processes, and qualities. There are then two main subdivisions of continuants and occurrents. The former are entities that endure through time; the latter entities that happen or develop in time, such as processes. Figure 4 and

Table 2. BFO classes and their characterizations.

Class	Characterizations
entity	Anything that exists or has existed or will exist.
continuant	An entity that continues or persists through time while maintaining their identity and have no temporal parts. It is a dependent or independent object.
occurrent	An entity that occurs happens or develops in time: events or processes or happenings.
independent continuant	A continuant entity that is the bearer of some qualities, it can maintain their identity and existence through gain and loss of parts, dispositions or roles, and changes in their qualities.
generically dependent continuant	An entity that is dependent on one or more other independent continuants. This latter can serve as its bearer. It is similar to complex continuant patterns of the sort created by authors or through the process of evolution.
specifically dependent continuant	An entity that depends on one or more specific independent continuants for its existence. It exhibits existential dependence and has two subcategories: quality and realizable entity.
process	An occurrent entity that exists in time by occurring or happening has temporal parts and always depends on at least one material entity. It can be partitioned into temporal parts in different ways and at different levels of granularity.
quality	A specifically dependent continuant that depends or inheres in an entity at all and is fully exhibited or manifested or realized in that entity.
disposition	A realizable entity whose bearer is some material entity.
role	A realizable entity which exists because the bearer is in some special physical, social, or institutional set of circumstances in which the bearer does not have to be, and is not such that, if it ceases to exist, then the physical make-up of the bearer is thereby changed.

illustrate the structure of BFO using some of its main classes and their characterizations.

4.2.2. The Common Core Ontologies (CCO)

-

The Common Core Ontologies (CCO) are an ecosystem of mid-level ontologies which meet most of the requirements of POLARISCO since it defines a modular set of extensible classes and relations that can be connected to our domain ontology content at lower levels. CCO descends from BFO and consists of ten modular ontologies as illustrated in Figure 5 [53]: Information Entity Ontology represents generic types of information and their relationships.

-

Agent Ontology defines individual agents (Persons) and coordinated groups of individuals (Organizations) as well as their roles.

-

Quality Ontology represents the attributes of agents, artifacts, and events.

-

Event Ontology represents processes in which agents are participants.

-

Artifact Ontology provides the designed qualities and functions of material entities.

-

Time Ontology defines temporal intervals and the relations that hold among them.

-

Geospatial Ontology defines the basic vocabulary for describing the locations of agents and occurrences of events including spatial regions.

-

Units of Measure Ontology represents standard units of measurement.

-

Currency Unit Ontology represents standard monetary currency.

-

Extended Relation Ontology defines approximately seventy-five relations that link together the content of the Common Core Ontologies.

A simplified explanation of the diverse modules is presented in [53]: “In CCO, agents (People and Organizations) use artifacts to perform actions that occur in both time and space, and are differentiated from other agents and artifacts via attributes”. The development of CCO started in 2010 in IARPA’s Knowledge, Discovery, and Dissemination programs. The purpose of CCO is to provide a structured base vocabulary that serves as the unified semantics over a number of very broad areas. It is then extended in multiple data sources to content at even more detailed levels.

4.2.3. POLARISCO Modules

First, a module is defined for each stakeholder. Thus, we proposed five modules to represent the knowledge of the different types of ERs involved, namely firefighters module, healthcare units module, police module, gendarmerie module, and public authorities module. We then defined a message module to represent the required knowledge to formalize information exchange among ERs and to improve communication capabilities. After that, we built a Glossary of Terms (GT) for each module by referring to the knowledge elucidated during the acquisition step. This includes expressions representing classes, properties, and relations, and certain instances. We found that there are several terms common to all modules, which led us to define a core module named PCC (POLARISC Common Core), which includes terms such as disaster, mean of transmission, victim used by all stakeholders. To summarize, to aid ERs in overcoming the problem of data heterogeneity, POLARISCO is an extension of BFO and CCO that integrates seven modules. Figure 6 illustrates the proposed modules and their import structure. Specifically, CCO modules (except units of measure ontology and currency unit ontology) import BFO, and POLARISCO modules import CCO. These modules include:

-

Polarisc Common Core module

-

Firefighters module

-

Healthcare units module

-

Police module

-

Gendarmerie module

-

Public authorities module

-

Messages module

4.3. Formalization

After defining the modules and the related Glossaries in this phase, the proposed taxonomy is transformed into a formal model by establishing relations among classes to ensure a complete taxonomical hierarchy for the POLARISCO as a whole. To connect the different classes, we use a hybrid approach, based on a top-down alignment to BFO and CCO, and a bottom-up alignment to define classes that are gathered during the knowledge acquisition step. That is, we approach in two ways by generalizing high-level classes to lower levels and by abstracting the low-level data to the higher-level class.

In virtue of extending BFO and CCO to define POLARISCO modules, we reused generic relations imported from other external ontologies. In particular, CCO reuses the Relations Ontology (RO) [54] which is a collection of OWL2 relations intended to be shared among various ontologies. Another ontology called RO-Bridge has been developed by adding domain and range constraints to the relations defined in RO used to relate BFO classes. The RO-Bridge relations that are reused in POLARISCO are presented in

Table 3. The reused RO-Bridge relations.

Relation	Domain	Range
has_role	Independent continuant	Role
agent_in	Person or Organization	Process
has_input	Process	Continuant
has_quality	Independent continuant	Quality
supervises	Person or organization	Person or organization
has_participant	Process	Continuant
located_in	Material entity	Spatial region or site
occurs_on	Process	Temporal region
is_part_of	Independent continuant	Independent continuant
realized by	Realizable entity	Process
occurs_at	Process	Spatial region or site
has_starting_instant	Temporal region	Temporal region
caused_by	Process	Process
has_function	Independent continuant	Function
has_sender	Act	Agent
has_recipient	Act	Agent
sends	Agent	Act
is_designated_by	Entity	Designative Information Content Entity

. Furthermore, we identified the need to define other relations specific to POLARISCO to relate the classes of the different modules (

Table 4. POLARISCO relations.

Relation	Domain	Range
respond_to	Agent	Process
installed_by	Site	Agent
take_place_in	Process	Environmental feature
has_day	Temporal region	Temporal region
has_month	Temporal region	Temporal region
has_year	Temporal region	Temporal region

).

4.3.1. POLARISC Common Core Module

In this section we present the various classes and relationships of the PCC module.

According to the US Department of Homeland Security National Response Framework, a disaster is defined as any event, natural or manmade, that results in extraordinary levels of mass casualties, damage, or disruption severely affecting the population, infrastructure, environment, economy, national morale, and/or government functions [55]. That is, a disaster is an event characterized by boundaries in time (it has a beginning and an ending). BFO defines a process as an occurrent entity that exists in time by occurring, happening or developing in time. Thus, we defined a disaster as a subcategory of the class bfo: process.

Next, we classified natural disaster and human-made disaster as subclasses of disaster as shown in Figure 7. We defined kinds of natural disasters and classified them under climatological, geophysical, meteorological, and hydrological categories. Under each category, we defined subclasses such as earthquake disaster, tsunamis disaster, tornado disaster, cyclone disaster. Then, we defined kinds of human-made disasters and classified them under accident disaster, explosion disaster, terrorist attack disaster and fire disaster categories. Furthermore, we defined four types of accident disaster including transport accident disaster, domestic accident disaster, radiologic accident disaster, chemical accident disaster and nuclear accident disaster. A transport accident disaster can be either air crash disaster, road accident disaster, railway accident disaster or maritime accident disaster. Note that a disaster is amenable to cause another disaster. For this purpose, we defined the relationship caused_by to show the connection that exists among the different disasters. For instance, an explosion disaster is caused by a road accident disaster.

To know when and where a disaster occurred, spatial and temporal contexts need to be specified. To do so, we defined the following three relationships (Figure 8); First, occurs_at relates a disaster to cco: geopolitical entity (e.g. city, country, town, village). Takes_place_in is used to relate a disaster to some cco: environmental feature, defined as an “a material entity that is a natural or man-made feature of the environment”. Third, occurs_on relates a disaster to a date. We reused the time ontology of CCO that provides the basic vocabulary for describing when events occur. Thus, we defined the date as a subclass of bfo: one-dimensional temporal region and a date has a cco: day, a cco: month and a cco: year.

Multiple ERs from different EROs are engaged in the process of disaster management. We reused the agent ontology from CCO as a starting point for defining the different ERs and other stakeholders. This ontology represents agents, their qualities, and the roles they occupy. The notion of Agent comprehends both an individual agent as a person and a coordinated group of individuals as an Organization (including for example a team). That is, a cco: organization member is affiliated with some cco: organization and has a role some cco: organization Member Role.

Stakeholders perform acts to respond to a disaster. We reused cco: act from the event ontology of CCO for this purpose. Stakeholders carry out acts both in real distaster interventions and in training programs. Thus, we defined simulated act and real rescue act as subclasses of response act. The response act is performed by stakeholders. Therefore, we relate cco: organization member to response act using the relation agent_in. Furthermore, acts are performed in a specific localization. We reused the geospatial ontology of CCO and we defined an action center as a subclass of cco: spatial region.

Aside from stakeholders and their acts, there are material entities involved in the process of disaster response. BFO defines a material entity as an “independent continuant that is made of matter”. Three types of material entities are recognized by BFO [2]: object, object aggregate, and fiat object part. CCO defines the term artifact in its artifact module as a subtype of object. We defined the resources involved in the operational disaster response under artifact. The latter term comprehends infrastructure, equipment and mean, we defined mean of transmission as a subclass of mean and it includes for example radio and telephone. We defined also hospital as an infrastructure object that contains beds. We defined bed as a subclass of equipment. Furthermore, we defined a digital radio network used by the involved stakeholders as a subclass of infrastructure. Figure 9 illustrates a partial view of the PCC module.

Both an organization member and an individual person can be harmed, injured, or killed as a result of a disaster. Persons, specifically, can be victims. BFO defines a role as a realizable entity that is possessed by its bearer because of some external circumstances and it is always optional. Therefore, we defined victim role as a subclass of the realizable entity bfo: role (Figure 10). A victim is a person characterized by a specific status. We defined victim state under cco: state which is defined as a subtype of process. Thus, we relate victim to victim state using the relation has_state. For each ER, victim state is designated by specific codes or acronyms. For this purpose, we defined victim state code identifier as a subclass of cco: code identifier. A code identifier is defined by CCO as “a non-name identifier that consists of a string of characters that was created and assigned according to an encoding system such that metadata can be derived from the identifier”.

4.3.2. Stakeholders Modules

Concerning the stakeholder modules, we used the PCC module as a starting point, and then we added appropriate classes related to each stakeholder type. For each such module (firefighters, healthcare services, police, gendarmerie, and public authorities), we defined the following classes. CCO defines an organization as a group of agents, and we defined each ERO as a subcategory of the class cco: organization. We also defined stakeholders as members of an instance of the subclass of cco: organization member. We then defined each stakeholder role as a subclass of cco: organization member role in such a way that very instance of cco: organization member is equivalent to an instance of cco: person that has role some instance of cco: organization member role. The latter usage can be defined in first-order logic (FOL) as follows:

∀ x,y [Organization member (x) ≡ (Person (x) ∧ y (Organization_member_role (y) ∧ x has_role y))]

For instance, in the firefighters module, we added a class firefighters member defined as equivalent to a bfo: person and has role firefighter rol (Figure 11).

Next, each organization member has either a command role or an operational role. For this purpose, we defined command role and operational role as subclasses of cco: occupation role. In fact, CCO defines occupation role as a role that an agent is expected to fulfill. For example, in the police module, we modeled the general director of the police forces as a command member and the police officer as an operational member. Furthermore, we used the relation supervised_by to represent the hierarchical levels of command among the different roles; thus the police officer is supervised by the general director of the police forces (Figure 12).

We next defined specific acts of each stakeholder under cco: act, as for example in: act of gathering, act of rescue, and act of evacuation for healthcare units. Each act is realized by a specific agents and necessitates use of a particular mean. Indeed, we define relations among acts, means and roles in order to figure out what is needed for a specific act to be such as to respond to a certain disaster (Who does what? And using what?) (Figure 13).

In addition, for each mean, we defined its function and its state (whether it is active or planned). An act of evacuation needs an ambulance and/or helicopter to transport the victims and an ambulance needs an ambulance driver. Thus, we defined healthcare units transport mean under two categories vehicle and mean of air transport, both subclasses of pcc: mean. In addition, the act of gathering is realized by a gathering officer.

Once the victims are gathered and then sorted, either they receive first-aid according to their state or they will be transferred to the appropriate hospital. In fact, victims receive instant medical care in a specific medical site called medical advance post, known by its French initials PMA, installed by the gathering officer and managed by a doctor. The PMA is installed in a safe zone near the disaster location in each case of mass casualty management. We define medical advanced post as a subclass of zone, which is a bfo: site. That is, medical advance post is equivalent to functional zone and is located in bfo: site. The latter usage can be defined as follows:

∀x,y,z [Medical advanced post (x) ≡ (Functional zone (x) ∧ y (Site (y) ∧ x located_in y) ∧ z (Rescue (z) ∧ z needs x))]

Concerning the designation of the victim’s state, it is different from one agent to the next. For this purpose, we added for each stakeholder the appropriate class that describes the victim state as subclasses of pcc: victim state.

Indeed, one of the principles we need to respect in building a useful ontology is that classes of the ontology should be defined in a consistent manner [2]. Thus, once we designed the stakeholder modules, we created for each class a definition, the spelling out of abbreviations, labels, and so forther. Then, we defined relations that exist among the various modules.

Figure 14 shows a partial view of the stakeholder modules. For example, the public authorities module is linked to the rest of the stakeholders modules with the relationship supervises. That is, (in the French case) the interior minister supervises the command member of each ER.

4.3.3. Messages Module

The message module is related to the PCC module and subsequently to the separate stakeholder modules. To define the message module, we reused classes from the PS/EM Communication Ontology [23], whose authors employed the EDXL-RM (Emergency Data Exchange Language-Resource Messaging) standards in their work. Figure 15 shows a partial view of the proposed module. The reused classes are marked with the prefix EDXL. We defined an edxl: message as a cco: information bearing artifact. We defined three different types of message that could be exchanged among ERs: informative message (which includes information message, alert message, report message, and so on); request message and response message. In addition, a message is characterized by a state (treated, untreated or ongoing), a confidentiality (public, private or limited), and a degree of criticality of the information to be exchanged (extreme, moderate or secondary). Moreover, a message is identified by an ID and the same goes for sender and receiver, which are defined under cco: agent.

4.4. Implementation

The proposed formalization models are encoded in the ontology implementation language OWL and implemented using Protégé. To implement the proposed ontology, we, first, imported BFO and CCO to build the PCC and message modules by using the “owl: import” feature of OWL2. Second, we imported PCC to construct the stakeholder modules. The different modules were then merged together and integrated into one POLARISCO ontology.

Table 5. Classes and relations of POLARISCO.

Ontology	Number of Classes	Number of Relations
Developed ontology
POLARISCO	447	25
Imported ontology
BFO	27	-
CCO	195	152
Total	669	177

presents the classes and relations of this global ontology.

4.5. Evaluation

The process of ontology evaluation is designed to ensure that an ontology is built correctly. In other words, it answers the question “are we producing the ontology in the right way?” [56]. To do so, the consistency of POLARISCO modules was checked using the OWL 2 HermiT reasoner. The aim is to ensure that the constructed ontology is consistent, that its classes are satisfiable, and thus that the inferred model can in principle reflect the intended semantics desired by the ontologist. To check if the ontology responds to our specifications, we translate the CQs into SPARQL (Simple Protocol and RDF Query Language) in order to query the ontology. Figure 16 and Figure 17 present the results obtained.

CQ1: “What types of means are needed to respond to a forest fire?”

CQ2: “Who is competent to search and rescue the drowned Person?”

5. Ontology Validation

To validate an ontology, it should be tested by comparing the meaning of the ontology definitions against the intended model of the world [56]. To validate the proposed ontology and to show its usability, POLARISCO is instantiated in a real-world use-case and then used by a messaging service in order to test its ability to promote semantic interoperability among stakeholders and show how a communication act can be semantically improved across different ER groups.

5.1. Use-Case Study

We identified the 13 November 2015 terrorist attacks in Paris as a good scenario, since it provides several interoperability challenges that need to be resolved. The data used in this use-case comes from ER reports and resulting feedback.

In fact, this multi-site terrorist attack was the first of this magnitude in France [57]. It involved six coordinated attacks that were carried out by three groups of gunmen. At least 130 deaths have been confirmed and 413 injured, who were taken care of in Paris Region hospitals. The first attack took place at the concert hall “Le Bataclan”, four attackers entered the building and started shooting randomly with automatic weapons. Hundreds of people were held hostage in a theatre. At the same time, three explosions occurred just outside the “Stade de France”, a stadium in “Saint-Denis” just outside Paris; during an international football match. Other locations were hit, four bars and restaurants were successively targeted by attackers armed with automatic weapons. Figure 18 illustrates the timeline of events.

To respond to these multiple terrorist attacks, the prime minister activated the inter-ministerial crisis center (ICC) to coordinate actions and mobilization of the different actors. He started by launching the emergency plan by alerting the needed ERs to intervene. Calling the plan into action means activating five operational cells: fire brigade, healthcare units, police and public order, transportation, and transmission [59]. He then drew up the operational framework response including chain of command, alert systems, and so forth. There were four principal commanders of the operational acts of the different stakeholders in the field: Director of Operations (DO), Commander of Rescue Operations (COS), Director of the Medical Response (DSM), and Commander of Police Operations (COP). For each site, there was one COS and one DSM.

Once stakeholders were on the scene, the first task was the recognition of the zone. The first unit that stepped in is the specialized anti-terrorism unit, the Search and Intervention Brigade, known by its French initials, BRI. It focused on finding and neutralizing the assailants and releasing the hostages. Another team of police forces took charge of setting up the security perimeter by dividing it into three zones (Figure 19): the exclusion zone, which only the police units were allowed to enter for reasons of safety; the controlled zone, where rescue units (healthcare teams and firefighters) gather and sort the victims; and the support zone, where the PMA, the tactical command posts, and so forth, are located. Once the victims were extracted from the exclusion zone and transported to the Casualties Grouping Point (PRV) of the controlled zone, they were sorted; extremely urgent cases were transferred directly to the hospital via intensive care ambulances, and less urgent cases were transferred to the PMA to receive instant medical care. Once the threat was over, the exclusion zone was removed.

To summarize: many operating forces were involved and a large number of means were mobilized to respond to these attacks [60].

Table 6. Outline of stakeholders’ mobilization and resources allocation on Friday, 13 November 2015.

Stakeholders’ Mobilization and Resources Allocation		Number
Units	Fire units	- 450 firefighters deployed on sites - 250 firefighters in support - 1000 firefighters in stand by
	Reinforcements by Civilian Firefighters	260 including 60 deployed for evacuations only
	Healthcare units	40 medical teams on sites
	Police forces	3000 police officers
Means of transport		125 firefighters’ vehicles deployed 21 Intensive Care Ambulances
Hospitals		- Activation of the “White Plan” in 17 hospitals of assistance (“Assistance Publique—Hôpitaux de Paris”) and 25 other hospitals - Activation of 2 Military Hospitals (HIA Percy and Begin)
Casualties Grouping Point (PRV)		Seven PRV

outlines stakeholder mobilization and resource allocation to respond to the terrorist attack:

5.2. Ontology Querying

All the presented data about the November 13, 2015 terrorist attacks in Paris were translated into ontology instances to allow query POLARISCO. To this end, we used the SPARQL Query editor that is integrated into Protégé. Examples of queries made include:

• When and where did the terrorist attacks occur?
• Who were the command members of each involved unit?
• What were the used means of transport used by firefighters and healthcare units in the Paris terrorist attacks?
• How many vehicles and operational firefighters were engaged in the Paris terrorist attacks?

Query 1: When and where occurred the terrorist attacks?

As shown in Figure 20, the temporal and the spatial region of the multi-site terrorist attacks are identified. Concretely, we extracted the date of the attacks, the structures where the attacks took place (theatre, stadium, bars, restaurants), and their geopolitical location (city or town).

Query 2: Who were the command members of each involved unit?

When responding to a disaster, it is fundamental to distinguish the exact role of each involved stakeholder. Accordingly, as can be seen in Figure 21, the identities of the command members that were responsible for managing the operational acts on the field are extracted with their specific roles and affiliation. The result of this query illustrates how we can navigate between the different stakeholder modules.

Query 3: What were the means of transport used by firefighters and healthcare units in the Paris terrorist attacks?

There are various types of transport used by firefighters and healthcare units to evacuate the victims in case of a disaster. The type of mean of transport employed depends mainly on the state of the victim. As demonstrated in Figure 22, we extracted the utilized means of transport by firefighters and healthcare units. Firefighters used what in French are called vehicles of succor and assistance to victims (VSAV). In the most urgent cases he healthcare units used helicopters to transfer victims to the appropriate hospital in a minimum of time, and Intensive Care Ambulances (ICA) were used for victims in less urgent cases.

Query 4: How many vehicles and operational firefighters were engaged in the Paris terrorist attacks?

As showing in Figure 23, we extracted the number of firefighters deployed on sites and, the number of firefighters’ vehicles engaged in the action center of people rescue.

5.3. Ontology Use: Messaging Service

-

Almost without exception, reports and reflections from the different stakeholders following the Paris attacks highlight several issues that need to be further explored including the absence of adequate communication and information sharing among the involved actors. Police forces recalled that “by the time the information gets out and reaches up, mobilizing the specialized units takes a relatively long time.”

-

“our police are not organized along local lines. Everything has to filter up to the central organization at the prefecture.”

-

“We have a police force that is disconnected from the field.” [61]

Furthermore, firefighters and healthcare units pointed out that the use of radio communication mean such as ANTARES network was unsatisfactory during the different interventions. Indeed, in the night of the terrorist attacks, there were two sites where victims did not receive medical care due to a lack of communication between firefighters and healthcare units [62].

As part of ontology validation, we illustrate the application of POLARISCO for implementing a messaging service, named PROMES (POLARISC Ontology-based Operational Messaging Service), that is responsible for ensuring semantically enhanced information exchange among ERs. Such a service demonstrates the potential of using the proposed ontology in order to resolve terminology inconsistencies and thereby supporting more effective communication among the involved stakeholders when responding to a disaster. The main purpose of the messaging service is that each stakeholder will receive information according to its own knowledge and with its own semantics. The processes used by the service are divided into three steps; the message input, textual transformation, and semantic transformation of the message (Figure 24).

The semantic transformation step is based on the semantic relationships among the stakeholder modules defined in POLARISCO. More accurately, we propose an algorithm that analyzes each class and interprets it using the equivalent class relation, its properties or its subclasses. The messaging service and its algorithms are beyond the scope of this paper, but Figure 25 provides an example of information exchange between firefighters and healthcare units. Once the firefighters’ unit of the VSAV (Vehicle of Succor and Assistane to Victims) is in the field, they figure out that backup they need from healthcare units to handle a large number of victims in a critical situation.

We start with an example of the resource-request type message sent by the firefighters in order to demonstrate how a communication act can be improved across ERs using PROMES. The term TA75 is an instance of pcc: terrorist_attack, which belongs to the PCC module. Hence, PROMES keeps the same term. Similarly, VSAV is a subclass of firefighters’ vehicle and there is no equivalent class in the healthcare units module, so PROMES adds the annotation of VSAV to explain the meaning of the acronym. Third, victim rescue is a subclass of act and belongs to the PCC module, so it remains unchanged. Then, AE (Absolute Emergency) is a subclass of firefighters’ victim status code identifier which is equivalent to the P0 subclass of SAMU victim status code identifier. AE therefore substituted with P0. The action center of the ongoing operation is called AC_PS_75 by firefighters while it is called P_75 by the healthcare units. Thus, AC_PS_75 is replaced by P_75. We can notice that the semantically transformed message is extended and improved so it becomes less ambiguous to the healthcare units.

6. Discussion

In this work, we proposed POLARISCO, a modular set of ontologies that define disaster response processed. We presented a description of the development process of POLARISCO. The proposed process is complete, starting from stakeholders’ requirements to arrive at an operational ontology. We adopted METHONTOLOGY to build the ontology due to its transparent logical structure, maturity, and clarity when compared to other methods. But, we adjusted it by adding a review and revision step to enable the iterative development of our proposed ontological modules. Furthermore, validation is added in the evaluation step in the form of a test of the ontology against a concrete use case.

Figure 26 shows the sequences of steps leading to the formation of the proposed ontology.

We started by identifying the ontology purpose, requirements and competency questions. It was important to be clear from the beginning why the ontology was built and what its intended uses were. Then, the most important terms of the operational disaster response were determined. The specification step was performed using knowledge from domain experts. Afterward, in the conceptualization step, we first defined the modules to be developed (stakeholder modules and message module) and we structured the knowledge by proposing a Glossary of Terms (GT) for each module (classes, properties, instances, and relations). The definition of the different GTs made us realize that there are many terms used in common across all stakeholder modules, and this led us to define the PCC core module. Once the modules were defined the use of BFO and CCO was crucial in enabling their integration in a way that allowed semantic interoperation among them. In the formalization step, the conceptual model was transformed into a formal model by defining the relationships, axioms and equivalent classes. In the implementation step, the different modules were implemented in OWL and integrated to yield POLARISCO as end result. Concerning the evaluation and validation step, POLARISCO was queried to check if it responds to the defined CQs.

The Paris terrorist attacks use case was a good example to show the utility of the proposed ontology since it highlighted the communication challenges among ERs during the multi-site response. Finally, POLARISCO is published, and it will be updated in reflection of changes that occur the disaster response domain to ensure its continued reliability.

The resulted ontology respects all the stated requirements. First, it shares a common upper layer of well-defined classes by reusing BFO and CCO. This facilitates the alignment of POLARISCO with other ontologies. Second, the advantage of adopting the principle of modularization to build the ontology is twofold; on the one hand, it reduces the complexity of ontology development; and on the other hand, it enables reuse of the modules as separate and independent units. Third, POLARISCO captures the specific vocabulary of each stakeholder. In fact, one of the unique aspects of this work is that the process of development of the ontology has involved emergency experts all the way from specification to validation. Indeed, the development of POLARISCO was difficult and very delicate especially during the mapping among the modules to establish the equivalent classes and relationships which serve as the core of the proposed messaging service and will influence the precision and utility of the information exchange process.

POLARISCO can be used in English or in French (each class is labeled in both languages). Every class of the ontology is defined in a consistent manner. The modular suite of ontologies described in this paper is available in OWL on GitHub (https://github.com/LindaElmhadhbi/POLARISC-Ontology, accessed on 7 October 2021).

7. Conclusions and Future Work

Managing disasters is a challenging task mainly because of the heterogeneity of the involved stakeholders and the critical nature of such events. Various ERs from different EROs must work together to achieve a successful resolution of the disaster. However, communication is still ineffective since each ER uses his or her own technical vocabulary with its own semantics and typically limited to its core activity. As a result, different interpretations of data may arise in a way that handicaps the response process and causes slower decision making. Accordingly, we proposed POLARISCO, a modular suite of ontologies, that reuses BFO as top-level and CCO as mid-level ontology to define the knowledge of French stakeholders including firefighters, healthcare units, police, gendarmerie, and public authorities. The POLARISCO-based messaging service is able to ensure semantically interoperable information exchange among heterogeneous stakeholders during the operational response of disasters. The proposed ontology could be extended further to involve more specificities and more stakeholders from other countries so that it can be used for example in cross-border scenarios. Moreover, one strong point of the adopted ontological approach is that POLARISCO is tested by means of real data and validated by stakeholders and emergency experts. Further studies will be performed on the use of the ontology by the different integrated services. Afterward, the implementation of POLARISC as a whole system will be published.