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 .
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 endeavour 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 interagency communication, the problem remains, particularly for non-governmental participants.
Of the four commonly identified phases of emergency management – prevention/mitigation, preparation, response and recovery – response 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, the values for data that are being exchanged, the vocabularies being used by the different agencies, present a much greater challenge. 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 on Emergency Information Interoperability Frameworks 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 view points 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-2-Face meeting in Washington DC (May 2008) 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 Mind Map contains many entities and relationships, and 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 Mind Map 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.
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 on determing common terms and phrases that will form part of a common shared ontology.
Figure 2 - EMA Manuals in Wordle
The Phased Framework takes a different more formal approach from 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 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 anticipated 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 Mitigation and Preparedness phases and feedback to improve the services for future incidents.
Figure 3 below shows an example of the Phased Framework (as the figure is not complete in showing all the evolutions of the key entities).
Figure 3 - 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)
The Phased Framework is also useful when several overlapping emergencies occur (eg. 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 approachs the four phases and how well it can deal with the consequences.
One of key questions in emergency response is Who is doing What, Where, and When. We use this as a framework in our brainstorm session to highlight some of data requirements and challenges in emergency response.
We need to keep track of all organizations and coordination centers involved in an incident. Information about the mission 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
- Email (create virtual domains)
- Means of communication/contact/availability
- Role (same as mission)
- Service Area - geographical
- Established Locations
- Credentials (forms part of Governance)
- Functional/Legal/other responsibilities
- Status (Active/Inactive, Available/Unavailable)
- Clearance/Dependency
Of note, although the focus here is on organizational entities, local efforts by persons affected are not often captured in existing data models.
Other issues include:
- Information inherited from organisational relationships
- What is the means to identify, locate, contact the Who
- Under what circumstances?
- Expectations
The activities that the organizations perform are mainly emergency support functions, transportation, and evacuation. The key point in such activities is the ability to assess the needs, and to address and integrate available resources versus capabilities. The activities can be characterized as following:
- Service/Activity
- Coverage
- No 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 and recover from the incident.
Geospatial location is a fundamental property for understanding emergences in a coherent and intuitive way. In emergecies all parties can relate to where they are on a map, follow directions to or from a place, grasping 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 landmark or events described in a text message, Howerver, there is no single frame of reference to locate people, areas and/or resources. For example, some use identifiers (such as place names e.g. ISO 19112 - Spatial referencing by geographic identifiers), coordinate reference system (CRS e.g. ISO 19111 - Spatial referencing by coordinates), or jurisdiction for this purpose. Some humanitarian information centers use universal indicators such as p-code instead. Areas involve different types of geospatial concepts and may involve basic geometric constructs. The approach taken here is to leverage existing ISO and Open GeospatialConsortium (OGC) standards for spatial objects and relations in support of the Framework Concepts and harmonize these as needed.
Existing Geospatial Standards
We start with 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) previously mentioned. 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. This geospatial objects can be referenced like location, by name, number or description. The ISO 19107 standard for Spatial schema has a conceptual schemas 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 needed 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 coverages include digital orthoimages, gridded elevation data sets, and thematic classification maps such as soils maps.
The Geography Markup Language standard original GML of OGC model was based on the World Wide Web Consortium's Resource Description Framework (RDF). Subsequently, the OGC introduced XML schemas into GML's structure to help connect the various existing geographic databases, whose relational structure XML schemas more easily define. The resulting XML-schema-based GML retains many features of RDF, including the idea of child elements as properties of the parent object (RDFS) and the use of remote property references.
The OGC features model (see Figure 4) is a useful way to organize several aspects of geospatial information. More broadly this is a start on a geo-spatial continuum. This starts with spatial things like arrangements of parts of a natural object which we might see in an image, them there are geo-spatial mixtures such as building designs and more abstract, geographic rendering in maps and models.
Figure 4 - OGC Feature Model
As shown in the Figure 4, 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 domin that represents a physical entity, e.g. a building, a river, 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
These issues include:
- 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
When
The incident can be described by the following properties:
- Instance
- Range and periods
- State
- Phase of an event
- calendar time
On validity and interoperability issues
The information comes from data inputting and external sources. Validity of such information is an important issue. Some 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. The other factors affecting interoperability are as following:
- Sensitivity
- Privacy
- Access control/rights
- Validity
- Security (e.g., data encryption)
- Uniqueness (applies especially to missing persons, perhaps not to other data?)
The previous scenario gave a broad overview of one facet of emergency operations. We now look at two Use Cases that the EIIF XG community felt lacked sufficient attention and posed significant interoperabilty issues facing current emergency management stakeholders. These use cases look at real-world operations systems and review and analyse their information models and semantics.
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 [OCHA and Sahana]. We have reviewed their operational information models/standards and provided a harmonized view of the overarching W3 constructs shown in Figure 5.
Figure 5 - W3 Use Case Information Model
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 or needs. 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, or affected by, 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)
WHAT
Capabilities represent the type of activities or need 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), Supplies
- 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. The services address the needs in different phases of an emergency. locationInformation represents the location where the emergency takes place. Related Emergencies should also be linked to enable shared resources and improved lessons-learnt outcomes
- Emergency Properties: Name, Type, phase (mitigation, preparedness, response, recovery)
- Relationship with: Organization, Person, locationInformation
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)
TODO - Hillman
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 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.
We have shown in this report that the need to move towards a common ontology methodology 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 first 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 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, 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 such as 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. UML (Class Diagrams) is commonly used as conceptual modelling language due to the wide acceptance within software developers, the high degree of standardization, and the availability of tools. In contrast with the high standardization of conceptual modelling in its formal aspects, there are not widely accepted ontological standards to 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 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 diffuse, and one of the reasons is the lack of a well assessed 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 basing on ontological foundations rather than linguistic intuitions. Moreover, existing domain models can be revised and enhanced by aligning their concepts to ontological categories coming form some selected foundational layer, with the aim of clarifying ontological commitments and better structuring hierarchies and relationships.
What follows shows the results of aligning the current draft version of the W3 Coordination model (as shown in Figure 5) with respect to 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 to philosophical literature 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 regions as spatial, temporal, and conceptual dimensions. For the sake of simplicity, we’ve adopted a reduced version of the DOLCE core called DOLCE-Lite (See Figure 6), but we’ve included some notion of an additional module called DnS (Descriptions and Situations ).
Figure 6 - DOLCE-Lite
In particular, concepts related to social processes, such as “Social Role”, are very important for modelling 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 7) show that most of the concepts where smoothly positioned under DOLCE categories, but some concepts are not clearly placed and requires further analysis.
Figure 7 - DOLCE Conceptualization
Service
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 modelling 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
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
Organizations can be collocated under the DOLCE’s notion of Collective (collections with only agents as members).
Emergency
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 emergencies situations.
Person
Person can be straightforwardly collocated under DOLCE’s AgentivePhysicalEntity.
LocationInformation and ContactInformation
Classes related to encoding and exchanging information can be famed under DOLCE InformationObject, socially constructed objects which play the role of “expressions” in communication processes.
Resource
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.
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.
The editor would like to thank all the members of the W3C EIIF Incubator Group for their valuable input into this document with special thanks to Rebecca Curzon, Paola DiMaio ad Craig Hubley for detailed reviews and comments.
