Thursday, April 17, 2014

Federation of Internet Alerts advocating Pictographs in Alerting

High level technical diagram for mobile pictograph alerting
High level technical diagram for mobile pictograph alerting
Almost one year ago, I had presented a concept on the use of "pictographs in alerting" and shared the evidence for the growing need for such an initiative. This was at the 2013 CAP Implementation Workshop in Geneva. The real need was to aid the linguistically challenged: tourist in a foreign country and illiterate. Moreover, it would remove the need to for messaging in multiple languages; especially in countries that are home to a multitude of races and languages.
Although the design was prescribed for mobile phones, given it's worldwide penetration over PCs, it does not differentiate between internet (data) or voice (SMS, Cell-broadcast) channels, it is adaptive. The idea is to use predefined EDXL-CAP elements to trigger the appropriate message. The message would indicate the urgency, severity, certainty, and event. However, the entire message is based on a set of logic determined by a larger set of EDXL-CAP elements.
The Federation of Internet Alerts (FIA) is a newly formed consortium that is collectively addressing those risk information presentation issues.  They are namely a group of public and private partners with a strong business inclination towards adverting. While was one of the pioneers to work with alerts in the advertising space, others such as ValueClick are also contributing to the initiative. They all have good intentions, namely with opening up their resources to alerting authorities to disseminate warnings.

Realize how Ad Exchanges and Ad Networks can push Life-saving warnings

FIA is currently in the process of standardizing how an alert message should be presented to an audience. Although CAP is a content standard, it does not address how the information should be presented. As my colleague: Eliot Christian (Special Scientific Adviser to WMO), authoring the standardization guidelines, states: "the need for FIA messaging guidelines in the presentation of public warnings arises because different online media will be presenting warnings across overlapping audiences. That means people online could receive inconsistent presentations of warnings for the same event. Inconsistent presentation of warnings can be confusing, and confusion is dangerous in life-threatening situations." I am currently reviewing their first paper on the guidelines.

Monday, April 14, 2014

Spot-On building a CAP-enabled software for ITU-D

The International Telecommunication Union - Development Sector has procured Spot On Solutions to supply a customized software. It is specifically designed to foster the wider-scale adoption of the ITU-T X.1303 recommended CAP standard. The software, to be delivered and abbreviated as CAPITUS, would be utilized by ITU in their emergency communication capacity development activities. Thus, advancing Member States with the adoption of CAP for life-saving communication. Moreover, the CAPITUS resources would facilitate multi-agency all-hazards all-media warning, alerting, and situational-awareness capabilities to effectively coordinate crises.

The potential of the proposed CAP-enabled software was demonstrated by Spot-On Experts at an ITU Development sector organized workshop, in Thailand. The delegates, attending the workshop, perceived the CAP ease-of-use and utility through a series of hands-on exercises. Participants experienced the efficiency gains of the single entry of a message being simultaneously disseminated through multiple technologies to multiple recipients. They acknowledged that the CAP message was consistent removing ambiguity that may, otherwise, lead to false responses. Moreover, they realized the capabilities of brokering multi-agency publishers and subscribers for improved situational-awareness.

As part of a two phase implementation, we are proposing to deploy the CAP-enabled software along with self-guided operating procedures to be made available for Member States to utilize in their adoption. The software and on-line training aids would be offered through a web portal. Authorized members can access the ITU branded software, first to trial the software then download the software to implement in one's own organization. Self-learning aids (manuals and video), self-guided exercises with links to additional resources on best practices would be part of the self contained comprehensive module.

During the first phase, Spot-On will operationalize the CAP-enabled software. The second phase would involve providing the comprehensive on-line training regime for both ITU system administrators, ITU trainers, and Member States. We have begun working on the first phase objective of a customized ITU CAP-enabled software, namely CAPITUS.

Sunday, April 13, 2014

Practicalities of EDXL - the Sahana Case

Sahana EDXL Experience

"Was EDXL-DE ever used in any of the Sahana Disaster Management Software Products?” "Yes in  EDXL-RM” (Resource Message); see the code snippet that includes EDXL-DE. EDXL-RM is specifically designed as payloads of the EDXL-DE. The development was for a client wanting to interoperate with WebEOC. ”The WebEOC implementation was being handcrafted in raw JavaScript and Eden’s native S3XML was seen as a simpler solution by the Client's own Software Developers, who were handling that side of the interface”. Further work on the EDXL-RM with the EDXL-DE wrapper was stopped until any new use-cases emerged.

“At the National Library of Medicine (NLM), mainly at my behest, they do use EDXL-DE 1.0 as a wrapper.” It encases the triage data (text and photos) sent from the TriagePic applicationto the web site via web services.  This was somewhat as a foundation for and in anticipation of use cases emerging for data interchange with state and local agencies, as well as FEMA.  These use cases have been slow to emerge in practice.  For app communication to the mothership, the overhead of the wrapper, while small compared to photo payloads, is still hard to justify if there’s no pay off. The NLM Webmaster is suggesting that alternative lightweight (but non-standard) wrappers and payloads, using JSON/REST more than XM, is the way forward

“Sahana Eden haven’t updated the existing DE-1.0 wrapper to DE-2.0 and I’m not sure they will invest much more into EDXL because every time they offer EDXL, clients find it way too complex and too narrowing to build their applications upon, and use either our native S3XML format.”

S3XML, like OData, does not set any limits to the contents at all. Furthermore, there doesn’t seem to be a coherent resource “CAP message“. If there was, even the standard REST controller could export the full message. Nevertheless, it would be possible to define such a resource with some minor tweaks to the existing data model. As is, many Eden modules have the tendency to define incoherent data models, yet models can be changed to provide better interoperability.

Particular Problem

The idea with the one particular project was to use Eden as database for managing resource requests, and to have an already functioning WebEOC solution sending those requests to Eden. The desire was to use EDXL-RM for data exchange. The first software build provided an EDXL-RM interface for it.

“A noteworthy issue was that the base data, e.g. requester information (delivery sites, contact information etc) was stored on the Eden side. EDXL did not provide any elements whatsoever to look them up, let alone to maintain them. Nevertheless, that is not an uncommon situation at all: why should the references in EDXL-RM be decentralized? Isn’t it more common that the request management database holds both – request and requester information?”

Realizing the Scope of EDXL-RM

One should not confuse with messaging from information management, where latter is what the project intention were. One should realize the scope of EDXL-RM. As stated in Section 1.3 of the specifications document, it is merely defines 16 separate and specific message types supporting the major communication requirements for allocation of resources across the emergency incident life-cycle. It’s not one size fits all! Moreover, the Resource Messaging goes through three distinct phases of “discovery”, “ordering”, and “deployment”. The level of detail of the reference information would vary in each phase. Therefore, the message broker would need to manage those elements through out the life-cycle involving the resource messaging phases.

Is S3XML Versatile?

Relating to an experience, of my own, with an application involving EDXL-CAP and the use of Eden’s native S3XML for generating Common Alerting Protocol (CAP) compliant document outputs, what I realized in EDXL-CAP was it was only producing the set of data for the specific GUI and not the entire CAP message. For example, the segment of a CAP message had it’s own GUI to edit the specific values. Within the segment GUI, the S3XML output would only produce the XML for the Alert segment and not the rest. 

S3XML is not GUI-specific, not at all. By default a standard REST controller provides the same output for a non-interactive request as for an interactive one, which is a meaningful behavior, though. However, the Point-Of-Interest (POI) exporter in Eden’s OpenStreetMap (OSM), for example, combines multiple data resources into a single output document, and is still both RESTful and S3XML and “inline-transformable”.

OData provides a generic interface standard to query data repositories of all kinds, including schema introspection. Eden’s S3XML is very similar to OData, although it does not implement aggregation methods, yet. APIs with (semantic) schema introspection capabilities have a much higher potential to facilitate interoperability than emergency management specific data formats; especially with non-emergency-management specific applications. However, that may be an over statement, while such level of achievement is still a bit away. However, Humanitarian eXchange Language (HXL) is a big step into that direction.

EDXL-HAVE, Yet Another Experience

“One of the problems encountered with EDXL-HAVE, namely the standard data structure for Hospital Availability Exchange, is that it assumes the role of an “emergency manager”, a decision maker who controls the resources and is thus in need of the information – and that organisations are ready and open to provide it (i.e. a hub-spoke model).”

In the EDXL-HAVE standard, it is assumed that hospitals (or their operators) report to that decision maker(s) on their available capacity, and the decision maker responds to that information, though not by routing patients but by acquiring and deploying additional resources as needed. This doesn’t work where the response decision happens entirely decentralized. In multi-national scenarios, why would India even respond to Pakistan’s HAVE data needs, even if it was ready to assist in an event?

In such cases the information flow is more peer-to-peer and organisations are expected to self-organize. High-level decision making is based on aggregated information whereas details may not be shared at all. Of course, organisations can make pre-event agreements to share HAVE information – but not at an aggregation level of their choice! Using the protocol requires thus both organizational (to actually collect the data at the required level of detail) and political (to share the data) change upfront. It would be better if HAVE (as well as other EDXL standards) had an integrated aggregation pattern, so that you can easily choose the level of detail that fits for the particular case without having to adapt your application.

Does EDXL Require Organizational Change?

EDXL is perceived a domain model requiring organisational change upfront, instead of one that is easy to implement on existing models. The most common answer received from developers that Sahana has interacted with was “EDXL wasn’t designed for the cases I was talking about” To that end, we wonder what the common denominator for EDXL standards is? In most cases it is FEMA and the US way to deal with disasters. Although originating in US, EDXL-CAP is the only initiative that the US nor FEMA was the early adopter. Perhaps one reason to it gaining wider scale global adoption with several Nations and Alerting related Vendors implementing the EDXL-CAP standard.

A non-advocate of standards may see EDXL very much as a US-specific thing. In fact, he had no requests so far for any EDXL support outside the US, and especially not at the INGO level (e.g. United Nation Organizations). New, RDF-based (Resource Description Framework) approaches, like HXL seem more promising these days and may outperform all the use-case specific standards in the long run. It is hardly feasible (or even desirable) for most organisations to adapt their data flows to EDXL requirements. Hence, they prefer standards which adapt to their existing resources, like OData or S3XML, rather than the reverse practice. 

The philosophy of letting everybody do their own thing and yet be interoperable is simply more adequate than the idea of making everybody do the same in order to be interoperable. However, there is some level of consistency required with the emergency data exchanges. Relating the concept to disparate spoken languages – to foster a harmonized meaningful conversation requires an “interpreter” to manage the conversation between two people speaking in the two different languages. Human beings, to date, are far more intelligent than machines and are capable of processing with incomplete information to take on the role of an effective Interpreter. However, machines are relatively inept to allow them to do their own thing and yet expect them to interoperate without some level of coherence.


Interfaces can be semantically incompatible even when they implement the same syntactic EDXL standard. Still, there are cases of people interpreting EDXL elements differently in different contexts. Some argue that this is due to the lack of rigor in the standard. It may be a consequence of the top-down ontology approach in EDXL.

EDXL doesn’t force people to adopt them and say this is the bible you should practice the religion. However, what their intention is to provide a set of elements and a data structure that allows an implementer to think through to ensure their messaging is coherent to a certain extent. I think that’s why most of the elements are set as optional which allows the implementer to build their own policies around them; meaning work flows.