Please Review: Dissemination of Earthquake / Tsunami data via Atom

Bob Wyman Sat, 08 Jan 2005 16:00:37 -0800

At PubSub, we’re beginning to put together a live feed of earthquake and tsunami information in the hope that by making this information more widely and rapidly disseminated, we’ll be able to prevent at least a tiny amount of the troubles such as recently happened in the Indian Ocean. In collecting this data, we’re not simply polling the USGS RSS feeds – doing that would introduce too much latency in the process and such high latency or delays would be unacceptable for this kind of data. What we’re doing is connecting to live “push” feeds of data and then executing on our servers the complex and messy “clean-up”, validation and reformatting processes that are required. The instant we have good data, we push it out to our subscribers using “Atom over XMPP/PubSub” and, as always, insert the latest messages into our subscriber’s personal Atom and/or RSS files. This service will be made available for at least experimental use in a few days after we’ve completed some testing. We currently expect to provide both traditional PubSub subscription service as well as a “telnet feed” of raw data that other service providers will be able to use to build their own systems.

We think it is appropriate to feed this kind of data over PubSub and in Atom files but before we get too far down this road, I’d like to get some input from the Atom community about the format we’re thinking about using. A sample Atom 0.3 entry from the current system is provided below. Please take a look at it, provide whatever comments you consider appropriate and also consider my questions below:

1. The first thing to note is that the content is xml, not text or XHTML. The thinking here is that we really want to be able to provide “data” to end users since it is likely that the best way to use this data is to have some kind of application (like a mapper, etc.) that would process the data. It is, I think, less interesting to provide text. However, some folk will want a machine generated textual version of this message… Since Atom only allows us one content element, there is no way to do both data and text – or, am I missing something? (Note: I do not want to convert this XML to XHTML…)

2. I’ve been thinking that I might include an atom:summary element that contained a textual version of the XML data carried in the content field. However, it appears that most aggregators today display either the summary or the content but don’t display both...

3. I’ve provided a ‘rel=”alternate”’ link that points to a USGS generated HTML page describing the event. Is it legitimate to point to an “alternate” that I haven’t created myself?

4. The title field provides some reasonably compact user data summarizing the key data for the event. Would that be sufficient as a “textual representation”?

5. What should a client do when presented with this data? Clearly, there are all sorts of interesting things that one can do if you know the format and build a custom app. However, it would be nice to allow “dumb” clients to do something useful without having to force the format to lowest-common-denominator (i.e. HTML or XHTML). I think what I’d like to do is provide a pointer to an XSL-template in some standard manner. Then, a client could fetch the style sheet and generate something for display. Is this reasonable? If so, where would I identify the style sheet?

6. This kind of data is really sensitive… I would very much like to be able to use a Digital signature to ensure that we can repudiate any fake messages that might get generated by spammers and other idiots as well as to repudiate mangled versions of the data that might get produced down-stream of us. The subject of signing Atom entries doesn’t seem to be getting much attention. Can we wake this one up again? I really do not think that signing should be considered something “outside the core” and subject to individual or proprietary extensions.

I look forward to your comments and assistance in getting this system working – hopefully, long before the next disaster in which it might be useful.

bob wyman

Note: The message below was published long after the original event. The reason for the delay is that this message adds to information previously published – much closer to the time of the event. (i.e. the “AddOn” element with the links to the waveforms was not available when the event was first published.) If a tsunami warning was issued, it would also appear as an “AddOn”.

<entry>

<id><id>tag:pubsub.com,2005:EQ:ci14117540</id></id>

<title>M 1.8 SOUTHERN CALIFORNIA 2005-01-08T21:00:21.000Z</title>

<topic>Earthquakes</topic>

<publisher>PubSub Earthquake Publisher</publisher>

<publication-date>2005-01-08T16:49:18-0500</publication-date>

<contentType>EQMessage</contentType>

</Event>

</DataMessage>

</Earthquake>

</content>

</Message>

</content>

</entry>

Please Review: Dissemination of Earthquake / Tsunami data via Atom

Reply via email to