I’ve received a number of off-list comments pointing to CAP (Common Alerting Protocol) defined by the OASIS Emergency Management WG. (see: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=emergency) It is suggested that CAP would be a more appropriate format for disseminating Earthquake reports. I am very familiar with CAP but am quite sure that it isn’t appropriate as a format for us to use in this case.

 

I’d like to point out that it is not our intention at PubSub to defining an “Alerting” protocol – in the sense that CAP is an “alerting” protocol. What we are doing with earthquake data, and what we’ve been doing for some time with Airport Closing/Delay information, is distributing raw data. The issuance of an “alert” of the type that CAP defines requires a subjective and authoritative decision typically made by a governmental or other authoritative organization – or by some machine process sponsored by such an organization. It is one thing to report that an earthquake has occurred. It is quite another to alert people that some action in response to the event is appropriate. We do the former, not the later.

 

I paid the OASIS fees and joined the CAP WG last year, commented extensively on the specification before it was adopted and we’ve had CAP support built into PubSub since last spring. However, the fact that we couldn’t find a good feed of CAP messages combined with our obvious reluctance to generate them ourselves has prevented us from making the topic public. If we could get a stream of CAP messages, we would publish them. However, publishing CAP messages would not replace our publishing of raw Airport, Earthquake, Tsunami or other reports that we might publish in the future such as weather reports, “terror level” reports, flood warnings, automobile traffic reports, etc. All of these messages may be appropriate for inclusion in a stream of CAP Alerts – however, a raw feed such as we’re publishing would contain many more messages then one would expect to see issued by a CAP system. Also, by providing specialized formats and service for each of these types, we are able to support them in ways that a generalized system cannot.

 

The CAP protocol is, of course, very general and is not really designed for carrying the sort of detail that is appropriate for a domain specific message such as one focused on earthquakes. Typically, one would expect that a domain specific message would contain much data which is of concern to those who have a specific interest in the domain (academics, hobbyists, etc.) but much of that detail would be irrelevant to the local emergency managers, governmental agencies, and even members of the general public who might be the recipients of CAP messages. It should also be noted that CAP has not, to date, managed to get much input from non-US domain experts or agencies. Thus, it really can’t be considered an “international” standard at this point – however, the market for PubSub data is decidedly international.

 

For those who are interested in learning more about CAP, I highly recommend that you check out the OASIS group pointed to above. Also, I’ve included a sample CAP message (from the draft CAP 1.1 specification) below to show you the CAP approach to alerting. I think even a quick review of the CAP message will show why it might not be appropriate for our immediate purposes. For instance, I would be very concerned about PubSub.com making statements concerning things like “scope”, “urgency”, “severity”, etc. Also, we provide structure (AddOns) in our messages that can’t be easily mapped to the name/value “parameter” mechanism which is all that CAP provides for communicating event-type-specific data.

 

It may be that in the future, we may be convinced that it would be appropriate to publish some subset of our event notifications as CAP messages. However, I’m quite sure that even if we did so, we would still find it appropriate to publish the full detail as domain specific messages. If we get demand to publish CAP messages, or a high-quality source of such messages published by others, we will certainly consider publishing the stuff.

 

            bob wyman

 

 

<?xml version = "1.0" encoding = "UTF-8"?>

<alert xmlns = "http://www.incident.com/cap/1.1">

   <identifier>TRI13970876.1</identifier> 

   <sender>[EMAIL PROTECTED]</sender> 

   <sent>2003-06-11T20:56:00-07:00</sent>

   <status>Actual</status> 

   <msgType>Alert</msgType>

   <scope>Public</scope>

   <incidents>13970876</incidents>

   <info>

          <category>Geo</category>   

          <event>Earthquake</event>   

          <urgency>Past</urgency>   

          <severity>Minor</severity>   

          <certainty>Observed</certainty>

          <senderName>Southern California Seismic Network (TriNet) operated by Caltech and USGS</senderName>

          <headline>EQ 3.4 Imperial County CA - PRELIMINARY REPORT</headline>

          <description>A minor earthquake measuring 3.4 on the Richter scale occurred near Brawley, California at 8:53 PM Pacific Daylight Time on Wednesday, June 11, 2003. (This is a computer-generated solution and has not yet been reviewed by a human.)</description>

          <web>http://www.trinet.org/scsn/scsn.html</web>

          <parameter>EventID=13970876</parameter>

          <parameter>Version=1</parameter>

          <parameter>Magnitude=3.4 Ml</parameter>

          <parameter>Depth=11.8 mi.</parameter>

          <parameter>Quality=Excellent</parameter>

          <area>       

                <areaDesc>1 mi. WSW of Brawley, CA; 11 mi. N of El Centro, CA; 30 mi. E of OCOTILLO (quarry); 1 mi. N of the Imperial Fault</areaDesc>

                <circle>32.9525,-115.5527 0</circle>  

          </area>

   </info>

</alert>

 

 

Reply via email to