Elysa Jones forwarded this comment from
David E. Ellis:
> 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.
There
is no such “assumption of human assessment” in the CAP messages we
publish at PubSub. These messages are completely machine generated without
human intervention. I see no “architectural issue.”
> Does
the atom format have mandatory elements?
Yes
it does. Things like atom:id, atom:title, etc. are required. It is undoubtedly
the case that some sensor based systems won’t be able to generate interesting
“titles” etc. However, all of the mandatory elements are things
that can be constructed via deterministic procedures.
bob
wyman
From: Elysa Jones
[mailto:ejones@warningsystems.com]
Sent: Monday, February 07, 2005
4:36 PM
To: bob@wyman.us;
emergency@lists.oasis-open.org
Subject: Re: [emergency] CAP over
Atom (Please review)
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>earthquakes@pubsub.com</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