Emergency Information Interoperability Conceptual Framework

W3C W3C Incubator Report

Emergency Information Interoperability Conceptual Framework

W3C Incubator Group Report 06 Nov 2008

This version:
http://www.w3.org/2005/Incubator/eiif/XGR-framework-20081106/
Latest version:
http://www.w3.org/2005/Incubator/eiif/XGR-framework/
Previous version:
This is the EDITOR DRAFT version - DO NOT REFERENCE
Editor:
Renato Iannella, NICTA
Contributors:
Mandana Sotoodeh, University of British Columbia
 
Also see Acknowledgements.

Abstract

This document presents an interoperability information framework for emergency management. This provides a reference model for information interoperability across the stakeholder functions in 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 .

Status of This Document

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.


1. Introduction

The information needs for emergency management interoperability are very broad and pervasive. Current work on information interoperability for this area have defined many underlying factors that need to be supported, such as information sharing, resource allocation, secure and reliable communications, coordination with national resources, integrating information, and privacy issues...

2. Framework Models

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 view points to showcase both the expansive impact and complexity of information interoperability for emergency management.

2.1 Conceptual Framework Model

The Conceptual Model Framework (as shown in Figure 1) was a result of the EIIF XG Face-2-Face meeting in Washington DC [F2F2008] in which the participants brain-stormed the various information entities that they deal with in their particular emergency management context. As a result, the Conceptual Model contains many entities and relationships, and many of which overlap in their semantics and behaviour.

Conceptiual Model
Figure 1 - Conceptual Framework Model

The Conceptual Framework Model shows 21 primary entities (each with many properties) with some explicit relationships between them. This is far from a complete model but shows the intricate inter-relationships that exist in emergency management information. The model shows common entities (such as People, Organisations, and Resources) as well as the more esoteric (such as Animals and Policy). All of these are important in different contexts to different stakeholders in emergency management.

2.2 Phased Framework Model

The Phased Framework takes a different approach to the Conceptual Framework Model 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 include:

  • Mitigation - involves the pre-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 actual emergency threat.
  • Response - involves the deployment of rescue services, organizational coordinating services, and resources to help immediate needs after the impact of the emergency incident.
  • Recovery - involves the longer-term deployment of organizational services to restore the community, business, and environmental impacted areas, including a review of the effectiveness of the pre-planning phases and feedback to improve the services for future incidents.

Figure 2 below shows an example of the Phased Framework (as the figure is not complete in showing all the evolutions of the key entities.

Phased Model
Figure 2 - Phased Framework Model

The Phased Framework 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 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)

3. Use Cases

We have investigated two Use Cases that the EIIF EG community felt lacked sufficient attention at the interoperability level and were significant issues currently facing emergency management stakeholders.

3.1 Who What Where (W3) Coordination

This use case information model represents the concepts and relationships that define an overall context for sharing of coordination information in an emergency. The model uses "Who (organizations or people) does What (activity) Where" scenario as a basis to derive high-level concepts and relationships and it is developed based on data schemas from two existing Emergency Information Systems [**name and ref them both**] A brief description of the model’s constructs and their properties is provided shown in Figure 3.

W3 Use Case
Figure 3 - W3 Use Case Model

3.3.1 WHO

Organizations represent any local/national/international, government/non-government organizations or local agencies and offices such as local churches. Organizations normally present a 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 to each service. The organizations have general contact and location information as well.

  • Organization Properties: Name, Type, Website, and Status (active/inactive)
  • Relationship with : Organization, Capability, Service, contactDetails, contactPerson, locationInformation

Persons represents the individuals (contactPerson) who are affiliated with the organizations involved in an emergency, volunteers (unaffiliatedPerson), or the ones affected by the emergency (affectedPerson) who are the primary beneficiaries of emergency services. Person, similar to an organization, provides a set of capabilities. An affectedPerson may need emergency services and an unaffiliatedPerson may be the one who volunteers to provide such services or to be available as a resource to other organizations which provide services to affectedPerson or affectedGroup.

  • Person Properties: Name, BirthDate, Status (available/assigned)
  • Relationship with: Capability, Service, locationInformation

ContactDetails 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 an emergency as well. ContactDetails can be published or private and each may have different access strategies for various locations of the object.

  • ContactDetails 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: locationInformation

UnaffiliatedPerson represents any person that is not related to an Organization.

  • unaffiliatedPerson Properties: Identification (anything that uniquely identifies the person), Certification (for volunteers, for example, who provide medical services)

3.3.2 WHAT

Capabilities represent the type of activities that a person or an organization can potentially undertake or the resources they can provide. The details of available resources are represented by Resource.

  • Capability Properties: WorkingSector (to specify the nature of services that can be provided), resource
  • Relationship with: Resource

Resource represents tangible items and people that are used to respond to an incident.

  • Resource Properties: Equipment (vehicles, communication facilities, etc.), People (human force), Fund (any financial support)
  • Relationship with: locationInformation (to trace the resources 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 volunteered physician provides to the victims of an earthquake. Services use the available capabilities to respond to an emergency. locationInformation 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: locationInformation, 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 or lack of education facilities. The services address the needs in different phases of an emergency. locationInformation represents the location where the emergency takes place.

  • Emergency Properties: Name, Type, phase (mitigation, preparedness, response, recovery)
  • Relationship with: Organization, Person, locationInformation

3.3.3 WHERE

LocationInformation represents the geographical location of the objects. There are different frames of reference for locating things: Address, Position, placeIdentifier, and placeIndicator. locationTrajectory represents a set of specific locations that the object is assigned to traverse, where the route is known in advance.

  • LocationInformation 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, CityDistrict, City, District, Region, Country, PostalCode (as described by [RFC4119])

Position is normally used to identify the current location of moving objects.

  • Position Properties: Lat (latitude), long (longitude)

PlaceIndicator is a unique identifier which is assigned to a settlement based on a hierarchal division of settlements from national to village level.

  • PlaceIndicator Properties: PCode

PlaceIdentifier is the name used to identify places such as refugee camps.

  • PlaceIdentifier Properties: Name, Type, Code (normally different than PCode)

LocationTrajectory represents location and timespan coordinates.

  • LocationTrajectory Properties: Location, TimeSpan (estimated arrival and departure time to/from that location)

3.2 Missing People

4. Standards Mapping Matrix

5. Towards Common Ontologies

In a very general dictionary sense, ontology refers to efforts to represent knowledge by categorizing and characterizing concepts, and the relationships between them. From a more practical, software, sense, the term is used for the practice of setting down the concepts and relationships used in a domain, which is then used to allow reasoning over the objects in the domain based on these concepts and relationships.

Clearly, we have shown in this report, that the need to move towards a common ontology is the 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 consensus process across all the stakeholders will be a significant challenge.

However, having a single domain ontology shared by various applications may not be feasible in most cases. This is due to the fact that 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. Hence ontology heterogeneity becomes the fist problem that needs to be solved while designing an ontology-based system. As such, ontology engineers face the problem of integrating different ontologies, either to support communication amongst the 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 US-based National Information Exchange Modelhas 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, 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.

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 4 shows a Wordle output from Emergency Management Australia Manuals. These results can assist on determing common terms and phrases that will form part of a common shared ontology.

EMA Manual
Figure 4 - EMA Manuals in Wordle

6. Summary

Decision making during emergencies is characterized as mission-critical and time-critical. When a catastrophe occurs, no single organization has all the necessary resources to alleviate the damage. Collaborative efforts between various agencies is required in sharing 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 interoperabilty challenges.

Acknowledgments

The editor would like to thank all the members of the W3C EIIF Incubator Group for their valuable input into this document.