Warning:
This wiki has been archived and is now read-only.
EMInfoStdsReview
Contents
- 1 Review of Emergency Management Information Standards
- 1.1 Common Alerting Protocol (CAP)
- 1.2 Emergency Data Exchange Language - Distribution Element (EDXL-DE)
- 1.3 Emergency Data Exchange Language - Resource Messaging (EDXL-RM)
- 1.4 Emergency Data Exchange Language - Hospital Availability Exchange (EDXL-HAVE)
- 1.5 Cyclone Warning Markup Language (CWML)
- 1.6 Tsunami Warning Markup Language (TWML)
- 1.7 People Finder Interchange Format PFIF
- 1.8 Tactical Situation Object TSO
- 2 Review of e-Commerce Interchange Standards
- 3 Geospatial Standards
- 4 Miscellaneous
- 5 TO DO
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.
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.
- Responsible - Open Geospatial Consortium Geography Markup Language Working Group
- Scope - Representation of geospatial features (points, lines, polygons) in RSS feeds
- Type - Abstract, serialised to XML/RDF
- Current Version - GeoRSS V1
- Variants - Simple, GML
- Licence - Creative Commons Attribution-ShareAlike 2.5 License
- Cost - Nil
- References - Home page, Wikipedia
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.
- Responsible - International Standards Organisation Technical Committee - Processes, data elements and documents in commerce, industry and administration
- Scope - Textual formatting of dates and times
- Type - Text
- Current Version - V2.20 2005-09-14
- Derivatives -
- Licence - Copyright
- Cost - CHF126.00
- References - Home page, Wikipedia
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.