Warning:
This wiki has been archived and is now read-only.

EMInfoStdsReview

From Emergency Information Interoperability Framework wiki
Jump to: navigation, search

Review of Emergency Management Information Standards

The following is a non-exhaustive list of EM languages used for system-2-system interoperability.

Common Alerting Protocol (CAP)

Summary CAP allows a consistent warning message format to be disseminated simultaneously over many different warning delivery systems for exchanging all-hazard emergency alerts and public warnings.
Type/Scope Warning Language, All-hazards
Responsible OASIS Emergency Management Technical Committee
Specification CAP 1.1 Standard
Representation XML Schema
Implementations

Sri Lanka

To learn about the Community-based Last-Mile Hazard Warning System (LM-HWS) research findings and all other knowledge pertaining to this implementation that uses CAP as a standard for communicating hazard information to local communities, please search using the key words: Disaster, CAP, Last-Mile, HazInfo, Hazards, Community-based Warning, and Emergency Communication, in the search field of the LIRNEasia website. As part of the standard operational procedures a set of guidelines including a CAP Profile for Sri Lanka was established to test interoperability issues in the LM-HWS.

Two HazInfo project solutions that used CAP v1.1 as a standard for issuing alerts to the last-mile --

1) Disaster and Emergency Warning Network (DEWN), a GSM based solution is described in Challenges of Optimizing CAP for SMS based GSM Devices in LM-HWS in Sri Lanka provides complete details of the implementation, engineering, and the shortcoming as well as recommendations for using CAP as a standard.

2) Addressable Radios for Emergency Alerts (AREA) is a satellite technology, discussed in LM-HWS in Sri Lanka: Performance of the WorldSpace AREA, which is capable of communicating all the elements of a CAP message.

Challenges of using CAP; especially the use of multiple <info> blocks to carry the multilingual messages and use of <urgency>, <severity>, and <certainty> tags to determine the priority of a message is describe in this paper. HazInfo research results show the need for a CAP broker to integrate the emergency communication entities and most importantly to reduce the messaging latencies.

For additional information or discussions you may contact the HazInfo Researcher/Project-Manager: Nuwan Waidyanatha.


Canada

CAP Canadian Profile (CAPCP) began as a proposal submitted by the Province of New Brunswick Emergency Measures Organization, working in collaboration with Doug Allport of the Allport Group. The Public Alert Message Protocol Requirements stresses -- The CAP Canadian Profile (CAPCP) limits the use of multiple <info> blocks to language translations of the original <info> block, and makes <language>, <geocode>, and <eventCode> required elements. These additional requirements ensure: 1. Sufficient content to translate key alert elements into at least both official Canadian languages; 2. There is at least a geopolitical reference in each alert which can be identified on most maps, 3. Alerts may be validated to recognized rights of alert originators, which is required to satisfy the demands of some private alert distributors. Ex. Only a few police officers in each Province have the authority to issue an Amber Alert.


Emergency Data Exchange Language - Distribution Element (EDXL-DE)

Summary EDXL-DE facilitates the routing of any properly formatted XML

emergency message to recipients. The Distribution Element may be thought of as a container. It provides the information to route "payload" message sets (such as Alerts or Resource Messages), by including key routing information such as distribution type, geography, incident, and sender/recipient IDs.

Type/Scope Messaging Infrastructure Language, All-hazards
Responsible OASIS Emergency Management Technical Committee
Specification EDXL-DE 1.1 Standard
Representation XML Schema
Implementations


Emergency Data Exchange Language - Resource Messaging (EDXL-RM)

Summary EDXL-RM provides a set of standard messages for managing resources during an incident, such as requesting, committing, returning, deploying resources. These Resource Messages are specifically designed as payloads EDXL-DE-routed messages.
Type/Scope Resource Management Language, All-hazards
Responsible OASIS Emergency Management Technical Committee
Specification EDXL-RM 1.0 Committee Draft
Representation XML Schema
Implementations


Emergency Data Exchange Language - Hospital Availability Exchange (EDXL-HAVE)

Summary EDXL-HAVE allows the communication of the status of a hospital, its

services, and its resources. These include bed capacity and availability, emergency department status, available service coverage, and the status of a hospital’s facility and operations.

Type/Scope Hospital Information Language
Responsible OASIS Emergency Management Technical Committee
Specification EDXL-HAVE 1.0 Committee Draft
Representation XML Schema
Implementations


Cyclone Warning Markup Language (CWML)

Summary CWML is a machine representation of common Cyclone/Hurricane/Typhoon warnings
Type/Scope Warning message, Cyclone
Responsible NICTA SAFE Information Project
Specification CWML
Representation XML Schema
Implementations


Tsunami Warning Markup Language (TWML)

Summary TWML is a machine representation of common Tsunami warnings
Type/Scope Warning message, Tsunami
Responsible NICTA SAFE Information Project
Specification TWML
Representation XML Schema
Implementations

People Finder Interchange Format PFIF

Summary PFIF is an XML format for locating missing people
Type/Scope Missing and Found People following a Disaster
Responsible Volunteer Development
Specification PFIF
Representation XML Schema
NOTE! The specification document fails the W3C validator but otherwise the specification document is valid XHTML 1.0 Strict.


Tactical Situation Object TSO

Summary The TSO provides the capability to exchange pieces of information which participate to the Common Operational Picture. The Tactical Situation Object shall contain at least the following information; Identification information, Description of the event, Description of the resources, and Description of the missions.
Type/Scope The definition of the TSO is inspired by the experience of the military. This is explained by the fact that interoperability has been a long standing issue in the military domain. Largely, this was due to the constraints of inter-service operations but also to the requirements in NATO to improve cooperation during multinational joint operations.
Responsible Open Advanced System for dISaster end emergency management Consortium
Specification Definition of the OASIS Tactical Situation Object
Representation XML Schema


Review of e-Commerce Interchange Standards

The following are a list of standards and frameworks that may be relevant to emergency management as they are being used for business-as-usual within organisations or government. A number of these are being promoted and adopted by government agencies as a consistent data model for inter-agency data interoperability.

Customer Information Quality (CIQ)

Summary Delivering royalty free, open, international, industry and application neutral XML specifications for representing, interoperating, and managing Party (Person/Organisation) Information (Name, Address, Party Profile and Relationships)
Type/Scope e-Commerce Interchange
Responsible OASIS Customer Information Quality Technical Committee
Specification CIQ V3.0 (Approved 2007-11)
Representation XML Schema
Implementations
  • eXtensible Name Language (CIQ-xNL) - OASIS CIQ specification that provides a standard format to represent the name of a party
  • eXtensible Address Language (CIQ-xAL) - OASIS CIQ specification that provides a standard format to represent an address/location
  • eXtensible Name and Address Language (CIQ-xNAL) - See xAL and xNAL.
  • eXtensible Party Information Language (CIQ-xPIL) - OASIS CIQ specification that provides a standard format to represent party centric data. A Party could be of two types namely, a Person or Organisation. An Organisation could be a company, association, club, not-for-profit, private firm, public firm, consortium, university, school, etc. Party centric data consists of many attributes (e.g. Name, Address, email address, telephone, qualifications, occupation, identification details, etc) that are unique to a party. A Customer is of type Party.
  • eXtensible Party Relationship Language (CIQ-xPRL) - OASIS CIQ specification that provides a standard format to represent relationships between two or more parties. Pairwise affiliation or association between two people, between two organisations, or between an organisation and a person. xPRL supports chains of interlocking pairwise party relationships, linked by common members.

Geospatial Standards

GeoRSS

GeoRSS describes a number of ways to encode location in RSS and Atom feeds. As RSS and Atom become more prevalent as a way to publish and share information, it becomes increasingly important that location is described in an interoperable manner so that applications can request, aggregate, share and map geographically tagged feeds.

Comments

  • GeoRSS(GML) is preferred over GeoRSS(simple) as it provides a greater range of data types that can be represented --Gavin Treadgold 18:17, 2 March 2008 (EST)
  • GeoRSS(GML) has the potential to provide a good means of adding geospatial elements to, say, a Situation Report that is distributed by RSS --Gavin Treadgold 18:17, 2 March 2008 (EST)

Geography Markup Language (GML)

The Geography Markup Language (GML) is the XML grammar defined by the Open Geospatial Consortium (OGC) to express geographical features. GML serves as a modeling language for geographic systems as well as an open interchange format for geographic transactions on the Internet. Note that the concept of feature in GML is a very general one and includes not only conventional "vector" or discrete objects, but also coverages (see also GMLJP2) and in limited cases for sensor data. GML is content model neutral and communications protocol agnostic.

  • Responsible - The Open Geospatial Consortium and ISO TC 211
  • Scope - XML grammar to express geographical features
  • Current Version - GML version 3.2.1 (OGC and ISO work identical as the OGC submitted GML to ISO)
  • Derivatives - Most information communities develop GML application schemas
  • Licence - Royalty free and non-discriminatory.
  • Cost - None
  • References - www.opengeospatial.org/standards/ and http://en.wikipedia.org/wiki/Geography_Markup_Language

Web Feature Service (WFS)

The Web Feature Service Interface Standard (WFS) provides an interface allowing requests for geographical features across the web using platform-independent calls. One can think of geographical features as the "source code" behind a map, whereas the WMS interface or online mapping portals like Google Maps return only an image, which end-users cannot edit or spatially analyze. The XML-based GML furnishes the default payload-encoding for transporting the geographic features, but other formats like shapefiles can also serve for transport. In early 2006, the OGC members approved the OpenGIS GML Simple Features Profile [1]. This profile is designed to both increase interoperability between WFS servers and to improve the ease of implementation of the WFS standard.

  • Responsible - The Open Geospatial Consortium and ISO TC 211 (see below)
  • Scope - http based web service interface for specifying query (filter) contraints and responding with a feature payload.
  • Current Version - WFS version 1.1 (OGC and ISO Joint Edit committee are currently working on WFS Version 1.2)
  • Derivatives - None.
  • Licence - Royalty free and non-discriminatory.
  • Cost - None
  • References - www.opengeospatial.org/standards/ and http://en.wikipedia.org/wiki/Web_Feature_Service

Web Mapping Service (WMS)

The Web Map Service (WMS) produces maps of spatially referenced data dynamically from geographic information. This international standard defines a "map" to be a portrayal of geographic information as a digital image file suitable for display on a computer screen. A map is not the data itself. WMS-produced maps are generally rendered in a pictorial format such as PNG, GIF or JPEG, or occasionally as vector-based graphical elements in Scalable Vector Graphics (SVG) or Web Computer Graphics Metafile (WebCGM) formats. This is in contrast to a Web Feature Service (WFS), which returns actual vector data, and a Web Coverage Service (WCS), which returns actual raster data.

  • Responsible - The Open Geospatial Consortium and ISO TC 211
  • Scope - http based web service interface for specifying simple spatial contraints and responding with a georegistered image.
  • Current Version - WMS version 1.3 (OGC and ISO work identical as the OGC submitted WMS to ISO TC 211)
  • Derivatives - None.
  • Licence - Royalty free and non-discriminatory.
  • Cost - None
  • References - www.opengeospatial.org/standards/ and http://en.wikipedia.org/wiki/Web_Map_Service

Sensor Observation Service (SOS)

A Sensor Observation Service (SOS) provides an API for managing deployed sensors and retrieving sensor data and specifically “observation” data. Whether from in-situ sensors (e.g., water monitoring) or dynamic sensors (e.g., satellite imaging), measurements made from sensor systems contribute most of the geospatial data by volume used in geospatial systems today.

  • Responsible - The Open Geospatial Consortium
  • Scope - http based web service interface for managing deployed sensors and retrieving sensor data and specifically “observation” data.
  • Current Version - SOS version 1.0
  • Derivatives - None.
  • Licence - Royalty free and non-discriminatory.
  • Cost - None
  • References - www.opengeospatial.org/standards/ and http://www.oostethys.org/

SensorML

SensorML is a standard markup language (using XML schema) for providing descriptions of sensor systems. By design it supports a wide range of sensors, including both dynamic and stationary platforms and both in-situ and remote sensors. SensorML provides standard models and an XML encoding for describing any process, including the process of measurement by sensors and instructions for deriving higher-level information from observations. Processes described in SensorML are discoverable and executable. All processes define their inputs, outputs, parameters, and method, as well as provide relevant metadata. SensorML models detectors and sensors as processes that convert real phenomena to data.

  • Responsible - The Open Geospatial Consortium
  • Scope - Standard markup language (using XML schema) for providing descriptions of sensor systems
  • Current Version - SensorML version 1.0
  • Derivatives - Like GML, information communities define application profiles and application schemas for describing one or more sensors used in their community. Go to http://vast.uah.edu/joomla/index.php?option=com_content&task=blogsection&id=10&Itemid=76 for several examples.
  • Licence - Royalty free and non-discriminatory.
  • Cost - None
  • References - www.opengeospatial.org/standards/ and http://vast.uah.edu/SensorML/

Sensor Planning Service (SPS)

The Sensor Planning Service (SPS) defines an interface to task any form of sensor or model. Using SPS, sensors can be reprogrammed or calibrated, sensor missions can be started or changed, simulation models executed and controlled. The feasibility of a tasking request can be checked and alternatives may be provided. SPS implementations cover a wide range of application scenarios. SPS is currently used to control assets such as simple web cams as well as satellite missions.

  • Responsible - The Open Geospatial Consortium
  • Scope - http based web service interface to task any form of sensor or model
  • Current Version - SPS version 1.0
  • Derivatives - None.
  • Licence - Royalty free and non-discriminatory.
  • Cost - None
  • References - www.opengeospatial.org/standards/


Miscellaneous

Date/Time

ISO 8601:2004 Representation of dates and times

ISO 8601:2004 is applicable whenever representation of dates in the Gregorian calendar, times in the 24-hour timekeeping system, time intervals and recurring time intervals or of the formats of these representations are included in information interchanges.

NIEM

The National Information Exchange Model (NIEM),

NIEM: A Framework for Nationwide Information Exchange The National Information Exchange Model (NIEM), a partnership of the U.S. Department of Justice and the U.S. Department of Homeland Security, is designed to develop, disseminate, and support enterprise-wide information exchange standards and processes that can enable jurisdictions to effectively share critical information in emergency situations. NIEM also supports the day-to-day operations of agencies throughout the nation.

NEIM is a set of standards surrounding information exchanges among and between governmental entities that allows disparate systems to share, exchange, accept, and translate information.

  • Scope - Framework for information exchange standards for US government agencies
  • Type -
  • Current Version - V2.0
  • Derivatives -
  • Licence -
  • Cost -
  • References - Downloads, Wikipedia, XML Specification

TO DO

  • Business Reporting Language (XBRL)
  • UBL Methodology for Code List and Value Validation (UMCLVV)
  • eXtensible Access Control Markup Language (XACML)
  • IEEE Std 1512.1, 2003. IEEE Standard for Traffic Incident Management Message Sets for Use by Emergency Management Centers. IEEE Standards Coordinating Committee 32, 9 May 2003.
  • IEEE Std 1512.2, 2004. IEEE Standard for Public Safety Incident Management Message Sets for Use by Emergency Management Centers. IEEE Standards Coordinating Committee 32, 29 November 2004.
Retrieved from "https://www.w3.org/2005/Incubator/eiif/wiki/index.php?title=EMInfoStdsReview&oldid=326"