I am sending the following comment from David Ellis:
Thank you for the e-mail.
The method described below has one major architectural issue. This
method assumes there will be information in optional tags which in the
case of many Sensors including CBRNE sensors may not be present.
The very nature of headlines and descriptions implies a human assessment
of the event. None of the mappings proposed are guaranteed from
perfectly valid CAP 1.0/1.1 messages. The initial CAP 1.1 CBRNE
messages I am working on must be transform to CAP 1.0 and even then may
not have all the required metadata for delivery by atom. I really
want to get on the list so I can interact directly. Does the
atom format have mandatory elements? When using CAP for
interoperability, there should be no assumptions about message
content.
David E.
Ellis
Information
Management Architect
(505) 844-6697
At 09:25 PM 2/3/2005, Bob Wyman wrote:
At
PubSub.com, we’ve started generating “CAP over Atom” files. By this I
mean CAP messages which are encapsulated in Atom Feed Files as defined
in:
http://www.mnot.net/drafts/draft-nottingham-atom-format-02.html
. We’ve started with CAP encodings of the Earthquake data that we’ve been
working with recently.
The Atom format, which is currently being updated and redefined in the
Atom-Pub IETF Working Group, is widely understood and processed by “RSS
news aggregator” software. We’re using this format as a “packaging”
format for streams of CAP messages since no other widely implemented
formats really seem appropriate for the task and since CAP itself defines
no such “stream” format. In any case, providing CAP data wrapped in the
Atom format means that the millions of people who have news aggregators
will be able to view CAP messages with no requirement to update or obtain
new software. (Although better display and information will be provided
by news aggregators that actually understand the CAP format…)
In order to provide the minimum elements required by Atom and to ensure
that news aggregators have useful information to display even if they
don’t understand the CAP format, we are forced to copy a number of the
CAP elements into Atom elements. I believe any application of “CAP over
Atom” will be required to do much the same. The duplication of data is
unfortunate, but necessary. If “CAP over Atom” is accepted as something
which is useful, it might be a good idea to generate a set of general
guidelines for packaging CAP in Atom feeds.
What we’ve done is:
1.
Copied alert:info:headline to
atom:title.
2.
Copied alert:info:description to
atom:summary
3.
Copied alert:info:web to atom:link
4.
Generated an atom:id based on the CAP
incident id using the tagUri scheme. See:
http://www.taguri.org/
For a sample Atom feed containing CAP messages which describe recent
earthquakes, please see:
http://atom.pubsub.com/c0/b8/bd62e8e48058c0425193b37ea6.xml
Note: If you view the Atom feed above in a web browser, the result may
not be terribly pleasing… We’re still working on the style sheet. –
Please pay attention only to the source of the feed… (i.e. do “View
Source”).
I would appreciate any comments you might have on our use of Atom as a
packaging mechanism for streams of CAP messages.
A
sample atom:entry from the Atom Feed above appears below:
<entry>
<ps:nodeID>/pubsub/topics/301</ps:nodeID>
<title><![CDATA[ Earthquake: M 1.6 (D) NORTHERN CALIFORNIA
2005-02-04T02:00:43.100Z ]]></title>
<issued>2005-02-03T21:04:42-05:00</issued>
<modified>2005-02-03T21:04:42-05:00</modified>
<id>tag:pubsub.com,2005:CAP:nc51156375</id>
<link rel='alternate' type='text/html'
href='http://earthquake.usgs.gov/recenteqsUS/Quakes/nc51156375.htm'/>
<summary>An earthquake occurred at 2005-02-04T02:00:43.100Z. The
magnitude 1.6 event has been located in NORTHERN CALIFORNIA. (This is a
computer-generated message and should not be considered authoritative.)
</summary>
<content type='text/xml'>
<alert xmlns="http://www.incident.com/cap/1.0">
<identifier>nc51156375</identifier>
<sender></sender>
<sent>2005-02-03T21:04:42-05:00</sent>
<status>Test</status>
<msgType>Alert</msgType>
<scope>Public</scope>
<incidents>nc51156375</incidents>
<info>
<category>Geo</category>
<event>Earthquake</event>
<urgency>Unknown</urgency>
<severity>Unknown</severity>
<certainty>Unknown</certainty>
<senderName>Pubsub
Earthquake Service</senderName>
<headline>Earthquake: M
1.6 (D) NORTHERN CALIFORNIA
2005-02-04T02:00:43.100Z</headline>
<description>An
earthquake occurred at 2005-02-04T02:00:43.100Z. The magnitude 1.6 event
has been located in NORTHERN CALIFORNIA. (This is a computer-generated
message and should not be considered authoritative.)
</description>
<web>http://earthquake.usgs.gov/recenteqsUS/Quakes/nc51156375.htm</web>
<parameter>EventID=nc51156375</parameter>
<parameter>Version=1</parameter>
<parameter>Magnitude=1.6
MD</parameter>
<parameter>Depth=2
km</parameter>
<parameter>Verified=N</parameter>
<area>
<areaDesc>2
km depth at latitude 38.8168, longitude -122.7915 at location: NORTHERN
CALIFORNIA</areaDesc>
<circle>38.8168,-122.7915 0</circle>
</area>
</info>
</alert>
</content>
</entry>
Note:
1.
We’ve set the status of all messages to
“Test”…
2.
We’re uncertain how to determine the
values for urgency, severity, and certainty. Thus, we’ve set them all to
“Unknown.”
3.
We are using the same value for
identifier and incident. This appears to be reasonable… Is it?
This service compliments the Earthquake service that I recently mentioned
on this list. We will be publishing both raw Earthquake messages/feeds as
well as CAP messages/feed in the future. These two formats are targeted
at different audiences.
Once
we’ve done a bit more testing, we’ll announce how to access the user
interface to create custom subscriptions to these feeds.
Your comments and/or suggestions would be appreciated.
bob wyman
