Superseded by Dates for Atom Entries, 14 Jul 2004.

Three Dates for Atom

Volume 7, Issue 44; 14 Mar 2004; last modified 08 Oct 2010

There have been several long threads on the Atom mailing list about which dates make sense for an entry and which should be required. I’ve posted once or twice to the effect that I need only two: created and modified. I’ve changed my mind, I need a third: issued.

Time sneaks up on you like a windshield on a bug.

John Lithgow

There have been several long threads on the Atom mailing list about which dates make sense for an entry and which should be required. I’ve posted once or twice to the effect that I need only two: created and modified. I’ve changed my mind, I need a third: issued.

I used to place entries in my primary Atom feed, “/atom/whatsnew.xml,” based upon their creation date. That works fine for new entries, but occasionally I update an existing entry in a significant way. Because the creation date hasn’t changed, there’s nothing to draw the readers attention to the modified essay. What I’d really like is to have it “republished” in my Atom feed.

My first solution was simply to adopt the modified date as the criteria for selection. That solves the problem, but it too often draws attention to essays that aren’t substantively changed. Fixing a typo or updating a URI counts as modification, but it doesn’t warrant the same level of attention.

Another possibility would be to update the creation date. The argument, if I wanted to make it, would be that a significantly modified essay isn’t really the same as the original and so a new creation date is justified. Perhaps. But that argument doesn’t move me. My essay about plotting spam from September, 2003, didn’t become a new essay just because I added another graph in February, 2004.

So what I’ve decided to do is add an “issued” date. For most essays, the issued date and the creation date will be the same. But if I update an essay in some significant way, I’ll also set a new issued date. That’s the date that will be (by the time you read this) used to build the Atom feed.

I’m not the first to reach this conclusion, the DCMI Metadata Terms already provide just these terms with just these semantics.

In the Atom specification, I’d be inclined to make “created” required and “issued” and “modified” optional with the explicit semantic that if issued isn’t provided, it defaults to the creation date and, if modified isn’t provided, it defaults to the issued date. In that way, all entries always have all three dates, irrespective of what blogging software provides for authors. That should simplify the lives of aggregators without making the implementors or authors struggle.

Comments

Atom dates are, in fact, defined in terms of Dublin Core. This was made clear in the 0.2 snapshot but doesn't seem to have made it into Mark Nottingham's drafts yet.

http://diveintomark.org/public/2003/08/atom02spec.txt

They were imported into the Atom namespace under the twisted logic that all the required elements should be in the Atom namespace, because that would be simpler. (Not everyone shares your prediliction for XML namespace porn.) I'm not defending the decision, but there it is.

—Posted by Mark Pilgrim on 17 Mar 2004 @ 02:32 UTC #

The DCMI Metadata Terms do account for your use case, but I'd say versionOf, replacedBy, etc. are what you should use. I can't find any examples of dcterms:issued being used the way you're suggesting.

Publication date and the significance of an edit seem orthogonal to me. Also, the more significant the edit, the more valuable a comparison between the two versions would be. If an aggregator subscribed to your feed between edits, the comparison would be lost. Why not keep both versions around and describe the relation?

—Posted by Robert Sayre on 18 Mar 2004 @ 03:34 UTC #