Copyright © 2008 - 2009 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This document describes some critical requirements for an interoperability information framework for emergency management, and provides candidate components of an ontology that can support interoperability for some common use cases. The approach discussed outlines how one can achieve information interoperability across the stakeholder functions within the area of emergency management.
Discussion of this document is invited on the public mailing list public-xg-eiif@w3.org (public archives). Public comments should include "[EIIF-Framework]" as the subject prefix .
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of Final Incubator Group Reports is available. See also the W3C technical reports index at http://www.w3.org/TR/.
This document was developed by the W3C Emergency Information Interoperability Framework Incubator Group, part of the W3C Incubator Activity.
Publication of this document by W3C as part of the W3C Incubator Activity indicates no endorsement of its content by W3C, nor that W3C has, is, or will be allocating any resources to the issues addressed by it. Participation in Incubator Groups and publication of Incubator Group Reports at the W3C site are benefits of W3C Membership.
Incubator Groups have as a goal to produce work that can be implemented on a Royalty Free basis, as defined in the W3C Patent Policy. Participants in this Incubator Group have made no statements about whether they will offer licenses according to the licensing requirements of the W3C Patent Policy for portions of this Incubator Group Report that are subsequently incorporated in a W3C Recommendation.
The management of emergencies is an endeavor that is characterised by involvement from a multitude of stakeholders, including numerous government agencies, military groups, non-government and charitable organisations, private enterprise and community groups. Some jurisdictions have attempted to integrate government response under a single emergency response agency, but although this can help to manage the logistics of inter-agency communication, achieving seamless and productive cooperation remains a problem, particularly for non-governmental participants. Of the four commonly identified phases of emergency management -- mitigation, preparedness, response and recovery – the response phase poses the clearest immediate need for efficient communication between agencies. However, each phase offers opportunities for improved communications, and indeed, the languages used and the problems faced have significant commonalities across all phases.
The proliferation of participants poses challenges when trying to build information technology solutions to support the management of emergency operations. Without agreement on how stakeholders' information technology solutions can intercommunicate, the use of IT threatens to complicate rather than simplify the processes. The general consensus in IT is that the co-operation of disparate systems is best addressed through the use of standards, agreed-upon interfaces and protocols of communication that, when adhered to, should guarantee successful interaction with other systems. Although encouraging stakeholders to use standardised structures can make, and has made, great strides in garnering agreement on the structures of information being exchanged and the values for data that are being exchanged, the vocabularies being used by the different agencies present a much greater challenge. Yet there are numerous reasons that different stakeholders use different vocabularies. Different spoken languages, different universes of discourse, different concerns, can each lead to differing terminologies that make it very difficult for stakeholders to exchange information efficiently.
This report from the Emergency Information Interoperability Frameworks Incubator Group (EIIF XG) looks at the issues facing the wider emergency management community and outlines some potential paths forwards via a number of informal and formal information models, scenarios, use cases, and ontology directions.
Given the many stakeholders and contexts, there are numerous ways in which to view a framework for information interoperability in emergency management. The EIIF XG has not attempted to create an all-encompassing single framework. Rather, we looked at a number of different viewpoints to showcase both the expansive impact and complexity of information interoperability for emergency management.
The Conceptual Mind Map (as shown in Figure 1) was a result of the EIIF XG face-to-face meeting in Washington D.C. in May 2008 in which the participants brainstormed the various information entities that they deal with in their particular emergency management contexts. As a result, the Conceptual Mind Map contains many entities and relationships, many of which overlap in their semantics and behaviour.
Figure 1 - Conceptual Mind Map
The Conceptual Mind Map shows 21 primary entities (each with many properties) with some explicit relationships between them. This is far from complete but shows the intricate inter-relationships that exist in emergency management information. The Conceptual Mind Map shows common entities (such as People, Organisations, and Resources) as well as esoteric ones (such as Animals and Policy). All of these are important in different contexts to different stakeholders in emergency management.
We also are experiencing a new Web 2.0 world where mass user participation has resulted in the need for simpler shared vocabularies utilising tag clouds and Wordle, for example. The Web 2.0 user is becoming an integral part of the set of emergency management stakeholders with both their demand and supply of pertinent information during incidents. Figure 2 shows a Wordle output from the textual analysis from a large corpus of emergency management documentation (the Emergency Management Australia Manuals). These results can assist in determining common terms and phrases that can appear as parts of a common shared ontology.
Figure 2 – Emergency Management Australia Manuals in Wordle
The Phased Framework (see [Hackman, 2007], [Roper, 1998]) takes a different, more structured approach compared to the previous examples, in that it views the four key phases of emergency management as separate but related activities, and looks at how key entities (Organisations, People, Activities, Resources, Information) evolve through these phases over time. The phases of emergency management include:
Mitigation - involves the planning and risk analysis of potential threats, including activities to reduce the risk, and education/training on dealing with potential incidents.
Preparedness - involves the pre-deployment of organizational services, warnings to people, and provision of resources for the potential impact of an anticipated emergency threat.
Response - involves the deployment of rescue services, organizational coordinating services, and resources to handle immediate needs after the emergency incident.
Recovery - involves the longer-term deployment of organizational services to restore community, business, and environmentally impacted areas, including a review of the effectiveness of the Mitigation and Preparedness phases and feedback to improve the services for future incidents.
Figure 3 below shows an example of the Phased Framework (the figure is simplified and does not describe all the evolutions of the key entities).
Figure 3 - Phased Framework Model
The Phased Framework Model shows how the key entities evolve and undertake different roles at different stages. For example, the People entity has a number of different roles, such as:
Volunteers (Preparedness)
Evacuees and Victims (Response)
Returned & Resettled Evacuees (Recovery)
Similarly for the other key entities, their roles and tasks will be dictated by the incident phases and direct requirements. For example, the Information entity needs include:
Warnings (Preparedness)
Situational Awareness (Response)
Long Term Planning (Recovery)
The Phased Framework Model is also useful when several overlapping emergencies occur (e.g., a storm followed by a flood followed by a health epidemic). The phases allow you to calculate the changing demands and needs -- allowing resources to be better staged and managed with appropriate planning support. Overall, how resilient a community is can be directly attributed on how well it approaches the four phases and how well it can deal with the consequences.
More comprehensive frameworks have been developed that take a more systematic approach and consider multiple viewpoints. The EU-funded ORCHESTRA Project designed and implemented the specifications for a service-oriented spatial data infrastructure for improved interoperability among risk management authorities in Europe, which will enable the handling of more effective disaster risk reduction strategies and emergency management operations.
The ORCHESTRA architecture focusses on generic (i.e. application-neutral) specifications with possibilities for specialisations, and utilizes UML to define abstract models. It also extends the ISO/OGC General Feature Model to provide an additional conceptual schema for interfaces and services for emergency management functions.
Figure 4 shows an example of extending the core ORCHESTRA model to support defining earthquake features.
Figure 4 - Orchestra Framework Example
Disasters and emergencies involve serious disruption of the functioning of society, communities and people along with damage to resources. Coping with an emergency involves the coordination of information and services about what is happened and is expected to happen to whom, what can be done and Who can take action with What resources. Standards for data needed (e.g, medical services) is fragmentary although many bodies are working on vocabularies (e.g. ISDR vocabulary and UNISDR Terminology to "promote common understanding and common usage of disaster risk reduction concepts and to assist the disaster risk reduction efforts of authorities, practitioners and the public."). For example there seems to be no widely accepted standard for "damage". Instead there are different types of damage that have to be accumulated to provide an overall picture a "situations" and the parts that make up situations. Situations are particular patterns made of related enduring entities (people, events, places) and activities set in space and time. Roughly one might think of a situation pattern describable by the What of a situation, Who is involved, Where the What and Whos of the situation are located and When this is.
A situation concepts helps to bring together the various elements that must be understood in an emergency. Emergency situation is one type of situation but there are many others connecting events over time, for example rescue situation follows and is dependent on a disaster event. Broadly these make up an emergency life cycle. While standards exist to some extent for particular pieces of emergency events there is no overall standard model tying all the pieces together even at a high level of abstraction. Such a standard would allow us to state how certain high points of land may be targeted during a flood emergency to play the role of safe areas (a relief role).
A small start of such integration is shown below which was developed as part of the Open Advanced System for dISaster and emergency management effort to enable better message exchange between responders (fire, police, medical,) in order to to facilitate the cooperation between the information systems used by civil protection organisations, in a local or international environment.As part of this effort, some categories of Event have been developed, in the Tactical Situation Object (TSO), as shown in Figure 5.
Figure 5 - Tactical Situation Object Model
At still finer levels of granularity there need to be standard way of describing and capturing supporting ideas like resource vulnerability. This would include economic, social, physical or geographic factors or constraints that may weaken the ability of a community to prepare for and cope with various emergency hazards.
The subsections below provide more background on the information concepts involved in Emergency Situations.
One of key questions in emergency response is Who is doing What, and Where. The EIIF XG used this as a scenario framework in its brainstorming session to highlight some of data requirements and challenges in emergency response.
It is critical during an incident to keep track of all organizations and coordination centers involved. Information about the missions of the organizations -- overall and in the context of an incident, their capabilities, and their current responsibilities -- can support situational awareness and time-boxing required for emergency operations. In this context, we identified the following organizational contact information:
Unique identifier
Phone
Means of communication/contact/availability
Role
Service area - geographical
Established locations
Credentials
Functional/legal/other responsibilities
Status (active/inactive, available/unavailable)
Clearance/dependency
It should be noted that although the focus here is on organizational entities, this set of information could also apply to persons affected, local efforts of which are not often captured in existing data models.
Other issues relating to Who include:
Information inherited from organisational relationships
What is the means to identify, locate, contact the Who
Under what circumstances can contact occur?
Expectations
The activities that the organizations perform are mainly emergency support functions, transportation, and evacuation. Of key importance in such activities is an organisation's ability to assess the needs, and to address and integrate available resources versus capabilities. The activities can be characterized as following:
Service/Activity
Domain
Coverage
Number of people covered or required
Capabilities
Categories
The type of disaster/incident will also determine (or give a good indication of) the range of Whats that should be provided. These activities would be applied to respond to and recover from the incident.
Geospatial location is a fundamental property for understanding emergencies in a coherent and intuitive way. In emergencies, all parties can relate to where they are on a map, follow directions to or from a place, grasp the spatial context of their route etc. Handling the Where may mean using information from a map or an image, data encoded as an address, zip code, or phone number, or a landmark or events described in a text message. However, there is no single frame of reference to locate people, areas and/or resources. For example, some systems or organisations use identifiers such as place names. Others use coordinate reference system or CRS. Still others use jurisdiction for this purpose. Some humanitarian information centers use universal indicators such as p-code. The more general designation of areas involves different types of geospatial concepts and may involve basic geometric constructs.
The approach taken here is to leverage existing ISO and Open Geospatial Consortium (OGC) standards for spatial objects and relations in support of the Framework Concepts and to harmonize these as needed. The ISO 19100 series of geographic information standards is a set of interlocking object-based standards consistent with principles and methodology of ISO/TC211 that can be used to define, describe, and manage geographic information about objects, events or phenomena that are located relative to the Earth. For location, the most relevant are the ISO 19112 - "Spatial referencing by geographic identifiers,” and ISO 19111 - "Spatial referencing by coordinates." But the nature of spatial characteristics and geographic features is also important, since geographical objects can be defined in different ways by different people for different purposes. Thus, geospatial objects can be referenced by location, by name, by number or by description. The ISO 19107 - “Spatial schema” has a conceptual schema to describe the spatial characteristics of geographic features needed to support understanding and usage of geographic information. For example, the standard can support representing the geometry of a road or wall suited to communicate information about a supply or escape route and barriers to transport.
Also of interest is the ISO 19123 - "Geographic information schema for coverage geometry and functions," which includes digital orthoimages, gridded elevation data sets, and thematic classification maps such as soil maps.
The Geography Markup Language (GML) standard from OGC was originally based on the W3C's Resource Description Framework (RDF). Subsequently, the OGC introduced XML schemas into GML's structure to help connect the various existing geographic databases, as such relational structures are more easily defined by XML schemas. The resulting XML-schema-based GML retains many features of RDF, including the idea of child elements as properties of the parent object and the use of remote property references.
The OGC features model (see Figure 6) is a useful way to organize several aspects of geospatial information. More broadly, this is a start on a geospatial continuum. This starts with spatial things like arrangements of parts of a natural object which we might see in an image; then there are geospatial mixtures such as building designs, and more abstract, geographic rendering in maps and models.
Figure 6 - OGC Feature Model
As shown in the Figure 6, GML contains a rich set of related primitives which are used to build application specific schemas or application languages. These primitives include:
Feature: distinction from a geometry object. A feature is an object in our domain that represents a physical entity, e.g., a building, a river, a rescue area, or a person. We are primarily interested in these, but need the other primitive concepts to locate them or describe them, as in locating and describing a rescue area.
Geometry: things like Point, LineString, or Polygon, that may describe a Feature or area
Coordinate Reference System to provide coordinates of geometry objects (e.g., line coordinates)
Coverage (including geographic images) as discussed above for ISO 19123
Emergency-related information may come from data entry or from external sources. Validity of such information is an important issue. Some systems assign a degree of confidence to the data and often use different frames of reference to assign probabilities. Veracity of the information is sometimes questionable as well. Interoperability is another concern. As mentioned before, there are different geographical frameworks to locate things. Other factors affecting interoperability are:
Sensitivity
Privacy
Access control/rights
Security (e.g., data encryption)
Uniqueness (applies especially to missing persons, and potentially to other information)
Furthermore, other factors that influence the coordination of response are:
geographical governance constraints/requirements
jurisdictional boundaries
infrastructure access (roads, cities, facilities, addresses)
demographics
effort to deliver, protect, obtain, distribute services and resources
accountability to make resources/services available
Finally, while 'When' is not explicitly included in this scenario of emergency response coordination, it is a descriptor with the following properties:
Instance
Range and periods
State
Phase of an event
Calendar time
The scenario described above ("Who is doing What, and Where") gave a broad overview of one facet of emergency operations. Below are examinations of other use cases that the EIIF XG community felt lacked sufficient attention and posed significant interoperability issues for current emergency management stakeholders. These use cases relate to real-world operations systems. In this section, their information models and semantics are reviewed and analysed.
For this use case, the information model represents the concepts and relationships that define an overall context for sharing of coordination information in an emergency. The model uses the scenario "Who (organizations or people) does What (activity) Where" as a basis to derive high-level concepts and relationships, and it is developed based on data schemas from two existing emergency information systems, OCHA and Sahana. We have reviewed their operational information models/standards and provided a harmonized view of the overarching W3 constructs shown in Figure 7. Note that the textual description that follows covers more than is illustrated in the figure, with differences noted in the text.
Figure 7 - W3 Coordination Use Case Information Model
Organization
represents any local/national/international,
government/non-government organizations, and local agencies and offices such as local
churches. Organizations normally have a defined set of capabilities. In an emergency,
they provide services based on their capabilities and current emergency needs, and in
return they may need services from other organizations or people. They normally assign
a person as a point of contact for each service. The organizations have general contact
and location information as well.
Organization
properties: Type
,
Website
Relationship with: Organization
, Contact_Details
,
Affiliated_Person
, Party
Person
represents the individuals (Affiliated_Person
) who
are affiliated with the organizations involved in an emergency, volunteers
(Unaffiliated_Person
), or those affected by the emergency
(Affected_Person
) who are the primary beneficiaries of emergency services.
A person, similar to an organization, provides a set of capabilities or needs. An
Affected_Person
may need emergency services, and an
Unaffiliated_Person
may volunteer to provide such services or be available
as a resource to other organizations which provide services to
Affected_Person
or Affected_Group
.
Person
properties: Birth_Date
Relationship with: Contact_Details
, Party
,
Resource
Party
is a general concept representing Organization
and
Person
.
Party
properties: Name
, Status
(available/unavailable)
Relationship with: Organization
, Person
,
Capability
, Service
,
Location_Information
Contact_Details
may represent general contact information for an
organization or specific information for a contact person in that organization. It may
represent contact information for any person involved in or affected by an emergency.
Contact_Details
can be published or private, and may have different access
control strategies for various locations of the object.
Contact_Details
properties: Phone
,
Fax
, Email
, Radio
(in radio communication,
it could be information such as CallSign), Language
(an option of
different language), Status
(valid, invalid)
Relationship with: Location_Information
Unaffiliated_Person
represents any person that is not related to an
Organization.
Unaffiliated_Person
properties: Identification
(anything that uniquely identifies the person), Certification
(for
volunteers, for example, who provide medical services)
Capability
represents a set of activities that a person or an
organization can potentially undertake (represented by Working_Sector
) or
the resources they can provide (represented by Resource
). For example,
organization X may potentially be able to provide medical services plus three
ambulances and five shelters. Resources can be Equipment
(vehicles,
communication facilities, etc.), Person
(human force), Fund
(any financial support), or Supplies (not shown in the
model)
. Resources can have Location_Information
for tracing purpose in emergency operations.
Service
is a set of activities that is carried out by an organization
or a person. An example for a service could be a humanitarian project that is to
improve education facilities in a given jurisdiction, or medical care that a volunteer
physician provides to the victims of an earthquake. Services use the available
capabilities to respond to an emergency. Location_Information
represents
the location where the service takes place.
Service
properties: Title
,
Description
(objective), Date
(Start/End date of the
operation), Status
(active/operational/suspended)
Relationship with: Location_Information
, Capability
,
Emergency
Emergency
represents the actual incident that is being coordinated.
Emergencies can happen unexpectedly, such as an earthquake, or can be the result of
significant vulnerabilities in the society such as HIV/AIDS. The services address the
needs in different phases of an emergency. Location_Information
represents
the location where the emergency takes place. Related emergencies should also be linked
to enable shared resources and improved lessons-learned outcomes.
Emergency
properties: Name
,
Type
, Phase
(mitigation, preparedness, response,
recovery)
Relationship with: Organization
, Party
,
Location_Information
Location_Information
represents the geographical location of objects.
There are different frames of reference for locating things: Address
,
Position
, Place_Identifier
, and Place_Indicator
.
Route
represents a set of specific locations that the object is assigned
to traverse, where the route is known in advance.
Location_Information
properties: Timestamp
(the
date/time when the location is assigned to the object), Status
(valid,
out-of-date)
Address
represents a physical location identified using typical
address-like characteristics.
Address
properties: Number
, Street
,
Neighborhood
, City_District
, City
,
District
, Region
, Country
,
Postal_Code
(as described by [RFC4119])
Position
is normally used to identify the current location of moving
objects.
Position
properties: Lat
(latitude), Long
(longitude)
Place_Indicator
is a unique identifier which is assigned to a
settlement based on a hierarchical division of settlements from national to village
level.
Place_Indicator
properties: PCode
Place_Identifier
is the name used to identify places such as refugee
camps.
Place_Identifier
properties: Name
, Type
,
Code
(normally differs from PCode
)
Route
represents a set of locations and estimated arrival and departure
time to/from those locations.
The W3 use case is an example of common coordination issues during a disaster. However, there are many other use cases that need to be explored in the emergency and disaster management domain for the sake of effective interoperability of systems. Examples of such use cases are described in a simplified way below.
The estimation of damages is critical to deciding the amount of resources and aid that need to be requested and applied to a region. Assessments are made by field representatives of each relief agency (government, NGOs) and, in the case of government, often includes the registration of people. Effective assessments lead to a more balanced distribution of aid as it arrives. However, each agency often does its own assessment, and systems are isolated. This means that there is redundant work being performed and often victims are asked to complete similar forms for different agencies for one and the same need, before aid can be provided. This inefficiency and duplication of effort can also contribute to an imbalance of aid distribution.
Tracking families and displaced persons, and making sure they are accounted for, is also another requirement during disasters. The exchange of information about displaced people among relief agencies is a precondition for the coordination of relief efforts to rehabilitate families. Data captured on displaced people is slightly different from that of missing people. In the latter case, all data on the missing individual's appearance, including identification marks, need to be captured. On the other hand, displaced families are registered through the head of family or group, with a breakdown of the composition of the group (e.g., babies, children, adults, elders), along with the data needed for sustaining the family in the displaced location and information for rehabilitation.
Large numbers of volunteers (hundreds, even thousands) can descend into a disaster area to provide their labour, skills and goodwill to help those in need. Due to the nature of disaster and the lack of capacity of emergency response agencies, there is often no option but for agencies to accept even untrained resources as part of the response cadre. Tracking and checking spontaneous volunteers is a challenge as ome volunteers might not be deployable for a particular organization, but may be needed by another. A quick mechanism of exchanging volunteer information -- including skills, availability, credentials and references -- between agencies would be valuable to minimize the volunteer registration effort.
Donors provide pledges, and relief organizations request quantities of aid. However, matching the two effectively is not a straightforward process due to the lack of integration between systems. This results in waste and ineffective distribution of aid. Donations that were made to one organisation might not be of value for that organisation, but could be needed by another relief group. Standards are needed for the exchange of meta data around aid provided from donors, with a tracking to its final destination.
The above use cases have focused on the response phase of relief operations. There are other such use cases in the phases of mitigation, preparedness, and recovery that also need to be explored.
In a general dictionary sense, ontology refers to efforts to represent knowledge by categorizing and characterizing concepts, and by showing the relationships between them. From a more practical point of view, the term refers to the practice of identifying the concepts and relationships used in a domain, which then enables reasoning over the objects in the domain based on these concepts and relationships.
We have shown in this report that the need to move towards a common ontology methodology is a major goal to meet, in order to address the need for information interoperability in emergency management. Having stated this, it is also one of the hardest goals to meet, as the necessary consensus process across all the stakeholders will be a significant challenge. Moreover, having a single domain ontology shared by various applications may not be feasible in most cases. This is due to the fact that useful domain ontologies do rely on the particular task at hand and on the organization that develops them.
This distributed nature of ontology development has led to a large number of ontologies covering the same or overlapping domains. Various organizations develop their own ontologies without fully understanding each other's. Hence ontology heterogeneity becomes the first problem that needs to be solved when designing an ontology-based system. As such, ontology engineers face the problem of integrating different ontologies, either to support communication amongst existing and new domains, or to enable interoperability across heterogeneous systems. Ontology mapping is the process of identifying the correspondences (mappings) between the concepts of two ontologies. It aims to solve the syntactic and semantic heterogeneity problem, and can be done (semi-)automatically or manually with the help of ontology experts.
One of the key challenges in creating ontologies is where to begin the collection of the semantics. The U.S.-based National Information Exchange Model has collected all the current XML-based standards and collated them to provide a comprehensive set of of semantics, not only for emergency management, but also for immigration, infrastructure protection, intelligence, international trade, justice, and person screening. The disadvantage of this model is that it is simply a union of a large overlapping set of semantics, with no overarching model or abstract framework to guide interoperability.
Conceptual models available today are generally built bottom-up by analyzing domain specific notions. The conceptualization process consists in introducing classes, properties, individuals, as well as axioms expressing class inclusion, domain/range/cardinality restrictions on properties, and so on. From a formal standpoint, analysts use a variety of tools whose logical expressiveness ranges from simple taxonomic structures to rich description logics. Unified Modeling Language, or UML, specifically through class diagrams, is commonly used as a conceptual modeling language due to its wide acceptance within the area of software development, its high degree of standardization, and the availability of support tools.
In contrast with the high degree of standardization of conceptual modeling in its formal aspects, there are no widely accepted ontological standards or methods that can be readily used as a basis for analyzing common, cross-domain notions. Also, there's a general tendency at capturing commonsense concepts as they appear in natural languages, and to represent them with minimal analytic effort. Since natural language semantics is fuzzy, and varies among cultures, this situation leads to a great amount of heterogeneity in domain specific ontologies, especially when they are developed by independent and culturally different organizations.
To reduce such heterogeneity, thus relieving the effort of integrating information systems, a viable practice could be that of adopting foundational ontologies, i.e., conceptual models of common, cross-domain notions such as spatial-temporal ones. However, at the time being, this practice is not very widespread, and one of the reasons is the lack of proven/established reference foundational ontologies. In fact, the process of standardizing a set of basic and commonly accepted ontological distinctions is very far from trivial. Nevertheless, a number of proposals are available today that can be used to guide the development of domain models based on ontological foundations rather than linguistic intuitions. Moreover, existing domain models can be revised and enhanced by aligning their concepts to ontological categories coming from some selected foundational layer, with the aim of clarifying ontological commitments and better structuring hierarchies and relationships.
Below we describe the results of aligning the current draft version of the W3 Coordination use case information model (as shown in Figure 5) with the DOLCE ontology. DOLCE (Descriptive Ontology for Linguistic and Cognitive Engineering) is based on a fundamental distinction between events (called perdurants) which have temporal parts, objects (called endurants) which have spatial parts, and abstract things without spatial-temporal qualities. These distinctions are inspired by philosophical analytical approaches, and are generally accepted within ontology standardization initiatives. Also, DOLCE introduces qualities as concepts that inhere to entities in that they exist as long as their host entities exist, and treats regions as spatial, temporal, and conceptual dimensions. For the sake of simplicity, we have adopted a reduced version of the DOLCE core called DOLCE-Lite (See Figure 8), but we have included some notion of an additional module called DnS (Descriptions and Situations ).
Figure 8 – DOLCE-Lite Ontology
In particular, concepts related to social processes, such as "Social Role", are very important for modeling the domain of emergency management, but many aspects of these notions are currently under investigation by the scientific community.
What follows is a summary of what resulted by framing W3 concepts under DOLCE conceptualization. The results (see Figure 9) show that most of the concepts were smoothly positioned under DOLCE categories, but some concepts are not yet optimally located in the model and need further analysis.
Figure 9 – W3 Coordination concepts framed under DOLCE-Lite
Conceptualization
Service
, in a concrete sense, can be seen as a Process
,
i.e., a perdurant (event) whose temporal parts may have different qualities (e.g.,
agreement, delivery, and conclusion). By looking at the attributes of the W3 class,
however, it seems that the concept aims at modeling abstract and informative qualities
such as Title
and Description
. To represent both informative
properties and spatial-temporal ones under DOLCE's conceptualization,
Service
might be split in two different classes: "ServiceDescription"
(InformationObject
) and "ServiceProcess" representing the concrete
processes of service's execution.
Capability
is used in W3 for representing the kind of actions Persons
and Organization should be able to perform. This should be represented in DOLCE by an
AbstractQuality
(qualities inherent in non-physical endurants) whose value
should range over a suitable abstract region, to be introduced. According to DOLCE,
however, this would limit the ascription of (instances of) this class to non-physical
endurants.
Organization
can be collocated under the DOLCE's notion of
Collective
(collections with only agents as members).
In terms of DOLCE, Emergency
can be seen as a stative perdurant. The
presence of the attribute Phase
confirms that the concept is intended to
capture a temporal notion. However, like in the case of Service
, other
attributes (e.g., Type
) seem to be related to the description of classes
of emergency situations.
Person
can be straightforwardly collocated under DOLCE's
AgentivePhysicalEntity
.
Classes related to encoding and exchanging information can be grouped under DOLCE
InformationObject
, socially constructed objects which play the role of
"expressions" in communication processes.
It is not immediately clear what Resource
could be in terms of DOLCE
categories. The class looks like the union of three other classes
Equipment
, People
, and Fund
. Intuitively,
Resource
stands for any concrete thing that can be instrumental to the
process of delivering a Service
. It is questionable, however, whether a
specific class is really needed here.
The lack of shared vocabulary is acknowledged as one of the causes for knowledge disconnectedness on the web, and is a common, major problem in all sectors. The use of different terms, definitions and concepts is one of the central causes of lack of semantic integration and divergence, therefore one of major obstacles to leveraging synergy and allowing collective intelligence to be catalyzed. Lexical and semantic distance may arise from differences among:
Terms used by different agencies in the same operational field
Terms used by different agencies in different operational fields
Terms used by agencies in different jurisdictions, across the same and different operational fields
As an example, one of the documented terms in emergency information systems is victim. Victim is a widespread English language term in use in emergency management operations worldwide. There are indications that some people affected by adverse events actually resent being called 'victim', as this conveys an image of passivity, helplessness and impotence. While many would agree that people impacted by adversity and in need of emergency aid have higher priorities than disputing preferred naming conventions, it could be argued that the word 'victim' in itself is not necessarily a meaningful word, and that enhanced terminological correctness and sensitivity is desirable, where possible. Therefore the term victim can be semantically mapped to a preferred context-neutral term, such as 'Affected Person', which is the current naming convention for this entity in W3 Coordination Information Model in Section 4.1.
Therefore, a semantic cluster identifier for "person" may include:
Recipient of aid
Beneficiary of aid
Client/patient/user
Displaced Person
Victim
Similar processes apply for many terms used conventionally in the emergency management sector, for example, 'disaster'. During open community discussion, it emerged that the term 'disaster' is not necessarily representative of the range of adverse events that constitute an emergency, and it may have some undesired connotations. Therefore, a semantic cluster identifier for “event” may include:
Occurrence
Incident (used by OASIS)
Emergency
Disaster
For global interoperability we need some harmonized vocabularies and glossaries. One example is the Institute for Crisis, Disaster, and Risk Management Emergency Management Glossary of Terms [ICDRM, 2009]. We can see traces of the challenge discussed here in the set of defined ICDRM terms, as there is no entry for "victim". Instead there are some related terms such as "actor," which mentions the victim role in a simulation context:
Actor: Individual simulating a victim, victim family, media, perpetrator, or other person within the exercise scenario to prompt realistic action/reaction from the exercise players.
On the other hand the ICDRM Glossary has a number of informational items that we might add to our model, such as “alert,” which discusses related terms (e.g. "advisory"), and a supertype "notification":
Alert: A notification category between "advisory" and "activation" that provides urgent information and indicates that system action may be necessary. An alert can be used for initial notification that incident activation is likely, and for ongoing notification throughout an incident to convey incident information and directed or recommended actions (see "advisory" -- "alert" -- "activation" for contrast between the other notification categories).
Notification: Information distributed to relevant personnel that contains important information regarding an actual or potential hazard impact and the response status of the organization. There are generally four categories of notification: update, alert, advisory, and activation.
Such terms could be used to map to (or harmonize) the "warning" term used in the Phased Framework Model (see section 2.3). This will lead to greater interoperability in the longer term, with the proviso that the semantics of the ICDRM terms are consistent with the intended semantics of the Phased Framework Model.
In the National Incident Management System (NIMS) glossary [FEMA] in the U.S., we find a specific definition of “emergency”:
Any incident, whether natural or man-made, that requires responsive action to protect life or property. Under the Robert T. Stafford Disaster Relief and Emergency Assistance Act, an emergency means any occasion or instance for which, in the determination of the President, Federal assistance is needed to supplement State and local efforts and capabilities to save lives and to protect property and public health and safety, or to lessen or avert the threat of a catastrophe in any part of the United States.
Clearly, this definition will not work outside the U.S.
However, other useful terms found in NIMS include:
Recovery: The development, coordination, and execution of service- and site-restoration plans; the reconstitution of government operations and services; individual, private-sector, nongovernmental, and public assistance programs to provide housing and to promote restoration; long-term care and treatment of affected persons; additional measures for social, political, environmental, and economic restoration; evaluation of the incident to identify lessons learned; post incident reporting; and development of initiatives to mitigate the effects of future incidents.
Resources: Personnel and major items of equipment, supplies, and facilities available or potentially available for assignment to incident operations and for which status is maintained. Resources are described by kind and type and may be used in operational support or supervisory capacities at an incident or at an Emergency Operations Center.
Response: Activities that address the short-term, direct effects of an incident. Response includes immediate actions to save lives, protect property, and meet basic human needs. Response also includes the execution of emergency operations plans and of mitigation activities designed to limit the loss of life, personal injury, property damage, and other unfavorable outcomes. As indicated by the situation, response activities include applying intelligence and other information to lessen the effects or consequences of an incident; increased security operations; continuing investigations into nature and source of the threat; ongoing public health and agricultural surveillance and testing processes; immunizations, isolation, or quarantine; and specific law enforcement operations aimed at preempting, interdicting, or disrupting illegal activity, and apprehending actual perpetrators and bringing them to justice.
In a broad sense, it is envisaged that there is a top level universal interoperability requirement, which is to support the communication and mutual reinforcement of all potential agents able to provide capability to deliver aid and act as first responders during an emergency. Responders need the ability to easily and fluidly share information, voice-data and video. That is not possible with most deployed systems [ShipCom, 2008].
In such unconstrained scenarios, responders may be a mixed bag of organisations and individuals whose operations are regulated by different protocols, and who communicate in different languages and following different rules, each providing a contribution to overall emergency relief capability. The above is likely to be a chaotic “open world” scenario, where resources and decision making are distributed, and where coordination is the key strategic requirement. Detailed interoperability requirements can be more tightly defined by specifying scenarios, use cases and circumstances.
Loosely speaking, it can be said that the interoperability gap is generated by a discrepancy (difference) between interoperability requirements, interoperability standards and interoperability implementation. An interoperability gap can be envisaged as a factor resulting from the combinatorial disparity between the different logical representation layers: syntactic, semantic and pragmatic [Carlile, 2004] as shown in Figure 10.
Figure 10 - Interoperability Gaps (from Carlile, 2004)
The syntactic gap in communication is caused by different language schema notations, where the schemas are not compatible. This gap is generally bridged by 'mapping' elements of a schema to another syntactic representation.
The semantic gap characterizes the difference between two descriptions of an object by different linguistic representations, for instance languages or symbols. In computer science, the concept is relevant whenever ordinary human activities, observations, and tasks are transferred into a computational representation.
The pragmatic gap results from the difference in organisational and social context of the communication layer, which contributes to different operational and information models, and therefore can be viewed as the result of the combinatorial explosion of the context to knowledge on the web. Pragmatically, challenges to knowledge reuse and relevant contextual dependencies are considered not merely technical, but belong to the realm of social and organisational systems design and management, and extend well into the boundaries of what is designated as policy management.
Each aspect of the interoperability gap should be tackled with a targeted approach, leading to the development of an integrated approach. For example, in Figure 8, the syntactic, semantic and pragmatic gaps are identified at the boundary level (where they intersect), which is where change/transformation/innovation tends to take place, and where corresponding solutions are suggested.
A strategy for filling the pragmatic gap should focus on:
Defining the interoperability requirement
Defining different aspects of the interoperability gap
Analyzing and understanding its dimensions and boundaries
Pursuing targeted strategies toward addressing each aspect of the gap
Specific detailed instruments should be developed in more detail and are likely to include:
Developing a shared/common vocabulary in the EM sector (semantic gap)
A summary of existing standards and frameworks in use (syntactic and pragmatic gap)
Decision making during emergencies is characterized as mission-critical and time-critical. When a larger disaster occurs, no single organization has all the necessary resources to alleviate the damage. Collaborative efforts between various agencies is required, including sharing of information. In this report we have looked at various frameworks and use cases that showcase this issue. The future effort towards sharable semantics for ontologies will provide significant enhancements to the current emergency management information interoperability challenges.
The editor would like to thank all the members of the W3C EIIF Incubator Group for their valuable input into this document.