Dear Joachim,
> As I understand it, the feeds only give
> the information that something re. an URI has changed. The consuming
> party has to look up the URI to figure out if it is new (by the
> according dates), or what particularly has changed (by comparison with
> a prior version).
-- This is correct.
> However, how is the deletion of a resource
> communicated?
-- Let's take page 1 of the Names update feed.
http://id.loc.gov/authorities/names/feed/1
There is at least one delete note in the ATOM file at the above address. However, in a browser (well, Firefox at least), you cannot see the deleted entry in the regular view, but you can see it if you view the page source. Search for the word "deleted" in the "view page source" view and you'll find one. The deleted-entry item is not visible, I presume, because Firefox ignores the at:deleted-entry element's namespace [1], which is not the standard Atom namespace but some kind of AtomPub tombstone namespace employed at the time the ATOM feed was originally implemented (I hope the creators of a namespace designed to indicate something deleted in an ATOM feed have a profound sense of irony since trying to resolve the namespace URI returns a 404 - unless, of course, the very fact that a tombstone namespace is "not found" is the basis of some kind of elaborate joke, but I digress).
> Do you (or somebody else on the list) have information how this is used,
> and how it works in practice?
-- I know of only one person/application that uses the Atom feed: Ethan Gruber built it into his EAD Editor [2]. That said, there may be others who are using the ATOM update feed that we're ot aware of, in which case - to the list - do please let us know!
> Any hints, if we try to set up something
> similar?
-- Not really. I wish I had, but we've never heard one way or another the good or bad about the ATOM update feed. So, if this is a case of "no news is good news," then it might be that people are content with the ATOM update feed implementation, or perhaps they have a little problem with it but they've managed to work around it. Of course, there is always the possibility that someone took a look at it and said "no way," and moved on. Again - to the list - this would be a good time to air a grievance about the ATOM update feed or lavish it with glorious praise.
Yours,
Kevin
[1] http://purl.org/atompub/tombstones/1.0
[2] http://code.google.com/p/eaditor/
--
Kevin Ford
Network Development and MARC Standards Office
Library of Congress
Washington, DC
> From: Neubert Joachim [mailto:[log in to unmask]]
> Sent: Friday, April 20, 2012 1:51 PM
> To: Ford, Kevin
> Cc: [log in to unmask]
> Subject: Atom feeds and deleted records
>
> Hi Kevin,
>
> At a meeting in Germany, we recently discussed how to trace and
> communicate changes in large authority files. I remembered that LoC is
> providing atom feeds for this. As I understand it, the feeds only give
> the information that something re. an URI has changed. The consuming
> party has to look up the URI to figure out if it is new (by the
> according dates), or what particularly has changed (by comparison with
> a prior version). However, how is the deletion of a resource
> communicated?
>
> Do you (or somebody else on the list) have information how this is used,
> and how it works in practice? Any hints, if we try to set up something
> similar?
>
> Cheers, Joachim
|