This Blog is Dead. Long Live This Blog.
In September of 2005 I started blogging. It was a reaction, a response, to the events of Katrina hitting New Orleans. And the Houston response. We now know a city of 400k was reduced to 200k with many of those who left living in Houston. But I digress.
My first blog post on Emergency RSS is pasted below in its entirety. Two years later I must say that we haven't made much progress towards this particular goal. More after the jump.
September 13, 2005
Emergency RSS Proposal
This blog, written by an amateur, will hopefully evolve to be interesting to
others as well as affect change on a global basis. And the best way to
affect change globally is to start locally. To pick up the cigarette
butt on the corner. Cliché? Sure, but damnit it works.The biggest screamingly loud demand, need, I see in the world of social software is a distributed method of responding to a crisis. We just had Katrina hit and she was a bitch by any measure. Lives were lost. Pause on that sentence, lives were lost. The most sacred thing we are capable of creating or destroying, lives, were lost as a result of poor human organizational skills. I don’t want to know who accepts responsibility, I want to know that disaster is prevented before it occurs.
To that end I want to state that we need a simplified RSS type system to track data in an emergency. No one site can handle all emergency response. Even if it could it would create a single point of failure. We need something as simple as RSS, call it emergency RSS or ERSS, to handle the needs that arise in an emergency.
Let me step back and repeat the basis for the need. With Katrina, which hit in 2005, what I observed were numerous sites heroically put up, only to go down once they were picked up by the blogosphere and the media. Go here for help … everyone does globally including the curious from other countries …. Server dies. Nobody gets help. Next site is suggested. Repeat the process.
Yet when it comes to blogs and news we can easily replicate with RSS our posts. Even if one server went down, the outline of the content would still be cached at feedburner or similar. So if in time of crisis 10 sites had relevant content of who is looking for what, who needs what, who needs to be dispatched where, then if one goes down you still have 9 sites up and replication of 100% of the content on each node. This is just like DNS. I am not inventing anything here. I am just screaming that we should have this in place for times of crisis already.
So where are we? Um... no where. We have no greater adoption of the CAPS standard or any real world standard for finding people. We have some ideas, but not vendor adoption. As I see it, here are a few that have potential:
- Common Alerting Protocol (something bad happened. this is how you express it!)
- People Finder Information Format
- OASIS as a driver
Me saying vendors have not adopted these standards is a self effacing comment. We *are* a vendor. With over 300 clients, many of them large associations using Tendenci CMS and Association functionality we have an impact on over 400k people. Yet, and I am accountable here, we do not even fully support these standards. RSS? Heck ya. Microformats? All over that.
So why is emergency response the red-headed-step-child (with forgiveness from my Irish and Scottish ancestors)? Because in this competitive world there is so little room for error. There is so little extra margin. And we need to trade headlines about Paris Hilton, but there is no day to day need for crisis response.
Which means that, to date, this blog has not achieved the original objective. Hopefully I can make some progress in 2008. So maybe, just maybe, long live this blog.

Actually, there is some progress being made in this area. The feds are currently testing an "Integrated Public Alert and Warning System" (IPAWS) in the states hit by Katrina.
Here is California, we are enhancing a system called EDIS (Emergency Digital Information Service) that makes many--but not all--emergency messages available via email (http://www.edis-by-email.net) and as an Atom feed (http://edis.oes.ca.gov/atom.index).
It's not nearly perfect, but an emergency manager sitting will soon be able to use EDIS to create a variety of warnings (NOAA Weather Radio, email, sirens, indoor PA, Emergency Alert System, tc.) using a single message.
This is based on the Common Alerting Protocol (http://www.capcookbook.com) and it's actually kind of slick.
David
Posted by: David Coursey | September 11, 2007 at 09:46 AM
David,
You are correct. There ARE isolated cases of adoption of the CAP standard. I did find the ATOM link:
http://edis.oes.ca.gov/index.atom
This is actually very helpful to me as our CAP implementation is just an XML schema of CAP.
http://www.tendenci.com/mms/emergency_response/CAP.asp
It makes more sense to use ATOM now that I look at it. Yes I should keep up on the CAP Cookbook a bit more.
What I'd love to see is every application, every CMS system, have a built in CAP system. Have Yahoo pipes of regular people, not trained emergency responders, but everyday people like the ones who responded on 9-11 be ready.
This is complicated.
I greatly appreciate your comment!
Thanks,
Ed
Posted by: eschipul | September 11, 2007 at 10:11 AM