Emergency Information Interoperability Frameworks

Abstract

This document presents describes some critical requirements for an interoperability information framework for emergency management. This management, and provides a reference model 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 in 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 .

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 management of emergencies is an endeavour 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 interagency inter-agency communication, the problem remains, achieving seamless and productive cooperation remains a problem, 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’ 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 make, and has made made, great strides in garnering agreement on the structures of information being exchanged, exchanged and the values for data that are being exchanged, the vocabularies being used by the different agencies, 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 forwards, via a number of informal and formal information models, scenarios, use cases, and ontology directions.

2. Information Frameworks

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

2.1 Conceptual Mind map

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.

2.2 Web 2.0 Tags

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 in determining common terms and phrases that will form part can appear as parts of a common shared ontology.

Figure 2 - EMA Manuals in Wordle

2.3 Phased Framework Model

The Phased Framework (see <1434: a href="#bibliography_Hackman_2007" shape="rect"> [Hackman, 2007] <1434: /a> , <1434: a href="#bibliography_Roper_1998" shape="rect"> [Roper, 1998] <1434: /a> ) takes a different different, more formal structured approach from compared to the previous examples 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 handle 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 environment 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 (the figure is simplified and does not complete in showing describe 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. (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.

3. Scenario: Emergency Response Coordination

One of key questions in emergency response is Who is doing What, Where, and When. We use used this as a scenario framework in our brainstorm brainstorming session to highlight some of data requirements and challenges in emergency response.

3.1 Who

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 Functional/legal/other responsibilities
• Status (Active/Inactive, Available/Unavailable)
• Clearance/Dependency

Of note, It should be noted that 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

3.2 What

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
  • Domain
• Coverage
  • No 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 and recover from the incident.

3.3 Where

Geospatial location is a fundamental property for understanding emergences emergencies in a coherent and intuitive way. In emergencies emergencies, 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 "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, However, 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. e.g., ISO 19112 - Spatial referencing by geographic identifiers), identifiers"), coordinate reference system (CRS e.g. (CRS, e.g., ISO 19111 - Spatial "Spatial referencing by coordinates), 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 Geospatial Consortium (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 ("Spatial referencing by geographic identifiers), identifiers"), and ISO 19111 – (Spatial ("Spatial referencing by coordinates) coordinates") previously mentioned. But the nature of spatial characteristics and geographic features is also important important, since geographical objects can be defined in different ways by different people for different purposes. This Thus, geospatial objects can be referenced like by location, by name, by number or by description. The ISO 19107 standard for Spatial schema has a conceptual schemas 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 needed suited to communicate information about a supply or escape route and barriers to transport.

Also of interest is the ISO 19123 Geographic "Geographic information schema for coverage geometry and functions coverages include functions", which includes digital orthoimages, gridded elevation data sets, and thematic classification maps such as soils soil maps.

The Geography Markup Language (GML) standard original GML of from OGC model was originally 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 as such relational structure XML schemas structures are more easily define. 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 (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 broadly, this is a start on a geo-spatial geospatial continuum. This starts with spatial things like arrangements of parts of a natural object which we might see in an image, them then there are geo-spatial geospatial mixtures such as building designs 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 – Feature: distinction from a geometry object. A feature is an object in our domain that represents a physical entity, e.g. 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 – Geometry: things like Point. LineString Point, LineString, or Polygon Polygon, that may describe a Feature or area
• Coordinate Reference System to provide coordinates of geometry objects (e.g. (e.g., line coordinates)
• Coverage (including geographic images) as discussed above for ISO 19123

3.4 Other Response Coordination Issues

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 Calendar time

On validity and interoperability issues

The Emergency-related information comes may come from data inputting and 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. The other Other factors affecting interoperability are as following: are:

• Sensitivity
• Privacy
• Access control/rights
• Validity <3033: /li> <3034: li> Security (e.g., data encryption)
• Uniqueness (applies especially to missing persons, perhaps not and potentially to other data?) information)

4. Use Cases

The previous scenario described above ("Who/What/Where") 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 interoperability issues facing for current emergency management stakeholders. stakeholders -- "Who What Where Coordination" and "Missing Person". These use cases look at relate to real-world operations systems systems, and we review and analyse their information models and semantics.

4.1 Who What Where (W3) Coordination

This 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" scenario as a basis to derive high-level concepts and relationships 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. Note that the textual description that follows cover more than is illustrated in the figure.

Figure 5 - W3 Use Case Information Model

WHO

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

• <3319: code> Organization <3320: /code> properties: Type, <3322: code> Type <3322: /code> , <3322: code> Website <3323: /code>
• Relationship with: Organization, Contact_Details, Affliated_Person, <3330: code> Organization <3330: /code> , <3330: code> Contact_Details <3330: /code> , <3330: code> Affiliated_Person <3330: /code> , <3330: code> Party <3331: /code>

Persons <3335: code> Person <3335: /code> represents the individuals (Affliated_Person) ( <3339: code> Affiliated_Person <3339: /code> ) who are affiliated with the organizations involved in an emergency, volunteers (Unaffiliated_Person), ( <3351: code> Unaffiliated_Person <3351: /code> ), or the ones affected by the emergency (Affected_Person) ( <3359: code> Affected_Person <3359: /code> ) who are the primary beneficiaries of emergency services. Person, A person, similar to an organization, provides a set of capabilities or needs. An <3380: code> Affected_Person <3381: /code> may need emergency services and an <3387: code> Unaffiliated_Person <3388: /code> may be the one who volunteers to provide such services or to be available as a resource to other organizations which provide services to <3412: code> Affected_Person <3413: /code> or Affected_Group. <3415: code> Affected_Group <3415: /code> .

• <3419: code> Person <3420: /code> properties: <3421: code> Birth_Date <3422: /code>
• Relationship with: Contact_Details, Party, <3428: code> Contact_Details <3428: /code> , <3428: code> Party <3428: /code> , <3428: code> Resource <3429: /code>

<3432: code> Party <3433: /code> is a general concept representing <3438: code> Organization <3439: /code> and Person. <3441: code> Person <3441: /code> .

• <3444: code> Party <3445: /code> properties: Name, <3447: code> Name <3447: /code> , <3447: code> Status <3448: /code> (available/unavailable)
• Relationship with: Organization, Person, Capability, Service, <3457: code> Organization <3457: /code> , <3457: code> Person <3457: /code> , <3457: code> Capability <3457: /code> , <3457: code> Service <3457: /code> , <3457: code> Location_Information <3458: /code>

<3461: code> Contact_Details <3462: /code> 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. <3497: code> Contact_Details <3498: /code> can be published or private and each may have different access strategies for various locations of the object.

• <3519: code> Contact_Details <3520: /code> properties: Phone, Fax, Email, <3524: code> Phone <3524: /code> , <3524: code> Fax <3524: /code> , <3524: code> Email <3524: /code> , <3524: code> Radio <3525: /code> (in radio communication, it could be information such as CallSign), <3535: code> Language <3536: /code> (an option of different language), <3541: code> Status <3542: /code> (valid, invalid)
• Relationship with: <3548: code> Location_Information <3549: /code>

<3552: code> Unaffiliated_Person <3553: /code> represents any person that is not related to an Organization.

• <3566: code> Unaffiliated_Person <3567: /code> properties: <3568: code> Identification <3569: /code> (anything that uniquely identifies the person), <3575: code> Certification <3576: /code> (for volunteers, for example, who provide medical services)

WHAT

<3590: code> Capability <3591: /code> represents a set of activities that a person or an organization can potentially undertake (represented by Working_Sector) <3608: code> Working_Sector <3608: /code> ) or the resources they can provide (represented by Resource). <3617: code> Resource <3617: /code> ). For example, organization X may potentially be able to provide medical services plus 3 ambulances and 5 shelters. Resources can be <3638: code> Equipment <3639: /code> (vehicles, communication facilities, etc.), <3643: code> People <3644: /code> (human force), <3646: code> Fund <3647: /code> (any financial support), or Supplies. <3652: code> Supplies <3652: /code> . Resources can have Location_Information for tracing purpose in emergency operations.

<3664: code> Service <3665: /code> 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. <3724: code> Location_Information <3725: /code> represents the location where the service takes place.

• <3736: code> Service <3737: /code> properties: Title, <3739: code> Title <3739: /code> , <3739: code> Description <3740: /code> (objective), <3741: code> Date <3742: /code> (Start/End date of the operation), <3747: code> Status <3748: /code> (active/operational/suspended)
• Relationship with: Location_Information, Capability, <3755: code> Location_Information <3755: /code> , <3755: code> Capability <3755: /code> , <3755: code> Emergency <3756: /code>

<3759: code> Emergency <3760: /code> 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. <3801: code> Location_Information <3802: /code> represents the location where the emergency takes place. Related Emergencies should also be linked to enable shared resources and improved lessons-learnt lessons-learned outcomes

• <3827: code> Emergency <3828: /code> properties: Name, Type, phase <3832: code> Name <3832: /code> , <3832: code> Type <3832: /code> , <3832: code> Phase <3832: /code> (mitigation, preparedness, response, recovery)
• Relationship with: Organization, Person, <3842: code> Organization <3842: /code> , <3842: code> Person <3842: /code> , <3842: code> Location_Information <3843: /code>

WHERE

<3849: code> Location_Information <3850: /code> represents the geographical location of the objects. There are different frames of reference for locating things: Address, Position, Place_Identifier, <3869: code> Address <3869: /code> , <3869: code> Position <3869: /code> , <3869: code> Place_Identifier <3869: /code> , and Place_Indicator. <3871: code> Place_Indicator <3871: /code> . <3871: code> Route <3872: /code> represents a set of specific locations that the object is assigned to traverse, where the route is known in advance.

• <3895: code> Location_Information <3896: /code> properties: <3897: code> Timestamp <3898: /code> (the date/time when the location is assigned to the object), status <3909: code> Status <3909: /code> (valid, out-of-date)

<3914: code> Address <3915: /code> represents a physical location identified using typical address-like characteristics.

• <3927: code> Address <3928: /code> properties: Number, Street, Neighborhood, City_District, City, District, Region, Country, <3937: code> Number <3937: /code> , <3937: code> Street <3937: /code> , <3937: code> Neighborhood <3937: /code> , <3937: code> City_District <3937: /code> , <3937: code> City <3937: /code> , <3937: code> District <3937: /code> , <3937: code> Region <3937: /code> , <3937: code> Country <3937: /code> , <3937: code> Postal_Code <3938: /code> (as described by [RFC4119] )

<3948: code> Position <3949: /code> is normally used to identify the current location of moving objects.

• Position properties: <3965: code> Lat <3966: /code> (latitude), long <3968: code> Long <3968: /code> (longitude)

<3972: code> Place_Indicator <3973: /code> is a unique identifier which is assigned to a settlement based on a hierarchical division of settlements from national to village level.

• <3998: code> Place_Indicator <3999: /code> properties: <4000: code> PCode <4001: /code>

<4004: code> Place_Identifier <4005: /code> is the name used to identify places such as refugee camps.

• <4019: code> Place_Identifier <4020: /code> properties: Name, Type, <4023: code> Name <4023: /code> , <4023: code> Type <4023: /code> , <4023: code> Code <4024: /code> (normally different than PCode) differs from <4028: code> PCode <4028: /code> )

<4031: code> Route <4032: /code> represents a set of locations and estimated arrival and departure time to/from those locations.

4.2 Missing People Person

TODO - Hillman

4.3 Other Use Cases

The W3 and Missing Person Use Cases are two examples of two very prevalent 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.

Damage/Needs Assessment

The estimation of damages is critical to deciding the amount of resources and aid that needs to be requested and applied to a region. The assessments are made by field representatives of each relief agency (Gov, NGOs) and often with Government includes the registration of people. Effective assessments provide a balanced distribution of aid as it arrives. However However, each agency often does their own assessment assessment, and each system is systems are isolated from each other. This means that there is redundant work being done and often victims are found entering multiple often happen to fill-in similar forms from different agencies for one and the same need, before aid can be provided. This can also result in an imbalance of aid distribution.

Tracking Displaced People

Tracking families and displaced persons, and making sure they are accounted for for, is also another requirement during disasters. Exchanging information of people displaced with between relief agencies about displaced people is needed to coordinate a precondition for the coordination of relief effort efforts to rehabilitate families. Data captured on displaced people is slightly different from that of missing people, where in the latter case all data on the individual appearance and identification marks need to be captured. Often with displaced families they are registered with the head of family or group with a break down break-down of the composition of the group (e.g. (e.g., babies, children, adults, elders) with the data needed for sustaining the family in the displaced location and information for rehabilitation.

Volunteer Coordination and registration

Volunteers in their hundred thousands Large numbers of volunteers (hundreds, or even thousands) can descend into a disaster response effort in apply area to provide their labour, skills and goodwill to help those in need. By definition of a disaster and the lack of capacity of emergency response agencies, often there is often no option but to accept even the untrained resources as part of the carder cadre to respond to the relief effort. Tracking and checking especially spontaneous volunteers is a challenge challenge, and fine balance needs to be made. Some volunteers might not be utilized useful for by a particular organization, but needed for an activity in another. A quick mechanism of exchanging volunteer information -- including skills, availability, credentials and references -- between agencies would be valuable between agencies to minimize the volunteer registration effort.

Aid distribution

Donors provide pledges and relief organizations make damage estimates and requests for aid quantities. However However, matching the two effectively is not a straightforward process due to the lack of integration between systems. Donations that were made to one org organisation might not be utilized, of value for that organisation, but required could be needed by another relief grouping. This results in wastage waste and the ineffective distribution of aid. Standards are needed for the exchange of meta data around aid provided from the donor, donors, with a tracking of it's final destination. The effective exchange of aid meta data can improve efficiencies in this regard.

The above Use Cases has focused on the use-cases in the disaster response phase of Relief. Relief operations. There are other such use cases in the phases of disaster preparedness, recovery and rehabilitation that also need to be looked into.

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 sense, point of view, the term is used for the practice of setting down identifying the concepts and relationships used in a domain, which is then used to allow 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 the a major goal to meet 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 meet, as the necessary 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 practically 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. Hence ontology heterogeneity becomes the first problem that needs to be solved while when 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 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 semantics, not only for emergency management, but also, 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 semantics, with no overarching model or abstract framework to guide interoperability.

5.1 Aligning Models to Foundational Ontologies

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 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. UML (Class Diagrams) is commonly used as a conceptual modeling language due to the its wide acceptance within software developers, 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 not no widely accepted ontological standards to or methods that can be readily used as a basis for analyzing common, cross domain cross-domain notions. Also, there’s there's a general tendency at capturing commonsense concepts as they appear in natural languages 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 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. 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, widespread, and one of the reasons is the lack of a well assessed 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 basing 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 form from some selected foundational layer, with the aim of clarifying ontological commitments and better structuring hierarchies and relationships.

What follows shows Below we describe the results of aligning the current draft version of the W3 Coordination model (as shown in Figure 5) with respect to 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 to by philosophical literature 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 regions as spatial, temporal, and conceptual dimensions. For the sake of simplicity, we’ve we have adopted a reduced version of the DOLCE core called DOLCE-Lite (See Figure 6), but we’ve we have 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�, "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 7) show that most of the concepts where smoothly positioned under DOLCE categories, but some concepts are not clearly placed yet optimally located in the model and requires need further analysis.

Figure 7 - DOLCE Conceptualization

Service

Service, <5585: code> Service <5585: /code> , in a concrete sense, can be seen as a Process, i.e. <5596: code> Process <5596: /code> , i.e., a perdurant (event) whose temporal parts may have different qualities (e.g. (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 <5635: code> Title <5636: /code> and Description. <5638: code> Description <5638: /code> . To represent both informative properties and spatial-temporal ones under DOLCE’s DOLCE's conceptualization, <5649: code> Service <5650: /code> might be split in two different classes: “ServiceDescriptionâ€� (InformationObject) "ServiceDescription" ( <5659: code> InformationObject <5659: /code> ) and “ServiceProcessâ€� "ServiceProcess" representing the concrete processes of service’s service's execution.

Capability

<5673: code> Capability <5674: /code> 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 <5700: code> AbstractQuality <5701: /code> (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 <5741: code> Organization <5741: /code> can be collocated under the DOLCE’s DOLCE's notion of <5749: code> Collective <5750: /code> (collections with only agents as members).

Emergency

In terms of DOLCE, <5765: code> Emergency <5766: /code> can be seen as a stative perdurant. The presence of the attribute “phaseâ€� <5779: code> Phase <5779: /code> confirms that the concept is intended to capture a temporal notion. However, like in the case of Service, <5797: code> Service <5797: /code> , other attributes (e.g. “typeâ€�) (e.g., <5801: code> Type <5801: /code> ) seem to be related to the description of classes of emergencies emergency situations.

Person

<5818: code> Person <5819: /code> can be straightforwardly collocated under DOLCE’s AgentivePhysicalEntity. DOLCE's <5826: code> AgentivePhysicalEntity <5826: /code> .

LocationInformation and ContactInformation

Classes related to encoding and exchanging information can be famed grouped under DOLCE InformationObject, <5846: code> InformationObject <5846: /code> , socially constructed objects which play the role of “expressionsâ€� "expressions" in communication processes.

Resource

It is not immediately clear what <5869: code> Resource <5870: /code> could be in terms of DOLCE categories. The class looks like the union of three other classes Equipment, People, <5889: code> Equipment <5889: /code> , <5889: code> People <5889: /code> , and Fund. <5891: code> Fund <5891: /code> . Intuitively, <5892: code> Resource <5893: /code> stands for any concrete thing that can be instrumental to the process of delivering a Service. <5909: code> Service <5909: /code> . It is questionable, however, whether a specific class is really needed here.

5.2 Shared Vocabularies

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. Using 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 is also evidence 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 ‘victim’ the word 'victim' in itself does is not necessarily a meaningful word, and that enhanced terminological correctness and sensitivity is desirable desirable, where possible. Therefore the term victim can be semantically mapped to a preferred context neutral context-neutral term, such as ‘Affected Person’, 'Affected Person', which is the current naming convention for this entity in W3 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 by in the emergency management sector, for example, ‘disaster’. 'disaster'. During open community discussion, it emerged that the term ‘disaster’ '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 part traces of the challenge by looking at discussed here in the set of defined ICDRM terms terms, as there is no entry for "victim". Instead we have there are some related terms such as "actor" which mentions the victim role in a simulation context. It's defined as:

• 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 any a number of informational items that we might add to our model, such as Alert, which discusses related terms (e.g. “advisory�) "advisory") and a supertype "notification" :

• Alert: A notification category between “advisoryâ€� "advisory" and “activationâ€� "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â€� "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.

Looking at In the USA National Incident Management System glossary [FEMA] , they also have we find a specific definition for of Emergency:

• Any incident, whether natural or manmade, 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 USA.

However, other useful terms 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.

5.3 Addressing the Interoperability Gap

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 to interoperate. emergency. Responders need the ability to easily and fluidly share information, voice data voice-data and video. That is not possible with most deployed systems [ShipCom, 2008].

In such unconstrained scenario scenarios, responders may be a mixed bag of organisations and individuals whose operations are regulated by different protocols, 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 coordination is the key strategic requirement. More detailed 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 disparity 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 8.

<7194: img src="assets/gap.png" alt="Gaps" width="800"></img> <7194: img src="assets/gap.png" alt="Gaps" width="600"></img>

Figure 8 - Interoperability Gaps (from Carlile, 2004)

The syntactic gap in communication is caused by different language schema notation, 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, 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 corresponding solutions suggested.

A strategy for filling the pragmatic gap should focus on:

• Define Interoperability Requirement interoperability requirement
• Define different aspects of the interoperability gap
• Analyze and understanding its dimensions and boundaries
• Pursue 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 shared/common vocabulary in the EM sector (semantic gap)
• A summary of existing standards and frameworks in use (syntactic and pragmatic gap)

6. Summary

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

Acknowledgments

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 and Craig Hubley for detailed reviews and comments.

<7657: a id="bibliography" name="bibliography" shape="rect"> Bibliography <7657: /a> <7657: /h2>

<7657: dt>

<7657: a id="bibliography_Hackman_2007" name="bibliography_Hackman_2007" shape="rect"> [Hackman, 2007] <7657: /a> <7657: /dt>

<7657: dd>

Hackman, C.: "Better Safe Than Sorry", Canadian HR Reporter; v20 no2 pp 19-20 Jan 29, 2007 <7657: /dd>

<7657: dt>

<7657: a id="bibliography_Roper_1998" name="bibliography_Roper_1998" shape="rect"> [Roper, 1998] <7657: /a> <7657: /dt>

<7657: dd>

Roper, W.E.: "Geospatial Analysis Support to Natural Disasters", in Wind and Seismic Effects, proc of The 30th Joint Meeting of the U.S.-Japan Cooperative Program in Natural Resources - Panel on Wind and Seismic Effects, NIST SP 931, August 1998. <7657: /dd>

<7657: /dl>