W3C home > Mailing lists > Public > www-rdf-interest@w3.org > January 2005

Fwd: Please Review: Dissemination of Earthquake / Tsunami data via Atom

From: Danny Ayers <danny.ayers@gmail.com>
Date: Sun, 9 Jan 2005 02:28:04 +0100
Message-ID: <1f2ed5cd0501081728252486cb@mail.gmail.com>
To: www-rdf-interest@w3.org

[Ok, I promise this will be the last Atom-related message I'll post
for a while.]

---------- Forwarded message ----------
From: Bob Wyman <bob@wyman.us>
Date: Sat, 8 Jan 2005 18:49:48 -0500
Subject: Please Review: Dissemination of Earthquake / Tsunami data via Atom
To: Atom Syntax <atom-syntax@imc.org>

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


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".






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

<link rel="alternate">http://earthquake.usgs.gov/recenteqs/Quakes/ci14117540.htm</link>

<content type='text/xml' xmlns='http://pubsub.com/xmlns'> 



<publisher>PubSub Earthquake Publisher</publisher> 






<Earthquake MsgNumber="1411754002" MsgVersion="1.0" > 

<DataMessage Action="Add" TimeReceived="2005-01-08T16:49:18-0500"> 

<Identifier EventIDKey="ci14117540" DataSource="CI" Version="1"/> 

<Event Type="Earthquake" Version="1" MsgTypeCode="E "
Latitude="34.6391" Longitude="-118.573" Depth="8.3" NumPhases="27"
MinDistance="5" AzimuthalGap="57.6" RMSTimeError="0.28"
HorizontalError="0.5" VerticalError="1.8"
Time="2005-01-08T21:00:21.000Z" LocationMethod="H" Verified="N">

<Magnitude Value="1.8" Type="L" NumStations="16" MagError="0.3"/> 


<AddOn Type="Waveform_CI" Version="1"









Received on Sunday, 9 January 2005 01:28:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:44:54 UTC