Martin Atkins wrote:
The work on using Atom to encode activity streams has raised what seems
to be a more general issue with Atom that I thought I'd bring up over
here to see what insight this group can bring.
In the "normal" case of a feed of entries a user has published,
"published" quiet sensibly represents both the time the entry was
published and the time it appeared in the feed, by definition.
We can't (and don't) specify it as the time it appears into a feed. It's
the time the author published it, not the time it showed up in the feed
(or downstream).
However, when the feed is of something else, these two times are no
longer necessarily the same.
That's true of all feeds. CDNs, caches, and aggregators break that idea
it's the time it shows.
Consider for example the feed that YouTube publishes of a user's
"Favorite Videos". In this feed, the entry-level atom:published tells us
when the entry was added as a favorite, *not* when the entry (i.e. the
video) was posted to YouTube by its author.
That's down to how Youtube models a "favorite".
If they create a new Entry for the favorite (you can tell by the IDs) it
makes sense relative to their domain. Although that will be annoying for
people following other people's favourites if people are tagging the
same vid. If not, it's a data bug.
However, Digg's equivalent "Favorite Articles" feed (which is actually
RSS 2.0, but let's pretend it's Atom for the sake of this discussion)
has the published time set to the time the article was originally
submitted to Digg, *not* when it was added as a favorite.
That's down to how Digg models a "favorite".
Again this depends on the site's internal domain model. In their case,
it looks like they don't exposed favorites as distinct entities.
My question, then, is which of these approaches is correct.
They both are.
The Atom
specification is (intentionally?) very vague about what this time
represents, but it does refer to "the entry". It's open to
interpretation whether "the entry" means "the actual atom:entry element
in this feed" or "the item that this atom:entry element describes".
It's to do (imo) with whether a favorite is an identifiable object, as
pointed out above. That is, it's about what the resource identifies as
indicated in this case by atom:id, not the representation of the
resource as indicated by the atom:feed's XML.
Do you think it would be vaulable to have an optional extra element that
indicates when the entry appeared in the current feed/collection? (This
would effectively make YouTube wrong and Digg right.)
It would be more helpful (again imo),
for Youtube: if when a favourite is modeled as an Entry in its own
right, atom:link or other metadata was used to reference what was
favourited (Atom's thread extension is good food for thought on that).
for Digg: if the favourite is modelled as an echo of the what was
favourited, they used atom:source.
(I'm told that Digg couldn't actually implement this element even if it
was specified, because they don't retain a timestamp on their "favorite"
relationships, but at least it would reduce the ambiguity about what
atom:published represents.)
That's what I mean by this being specific to internal domain models.
There's no correct way to represent a favourite atm.
Bill
