+1 I like the idea.
I had modeled something similar in my August OWL model [1]. There I had made a feed a pair pointing to a head Entry and a set of entries.
Thinking about it a bit more now, and incorporating some of Mark's points, I would make the Feed a document (foaf:Document perhaps?) that can be classified [2] into two exclusive and complimentary groups: Dynamic Documents and Static documents
- Dynamic documents are document resources that do change their content a lot over time. These would have very short range http expires headers. Documents such as search results, what we usually think of as feeds, and newspaper front pages are usually such documents.
- Static documents are much more RESTful (so to speak): they never change and therefore can be cached much more easily: These resource usually have an HTTP expires header set way far out in the future. Examples of such documents would be archives of news stories. These documents try as best as they can to follow the motto "cool URI's don't change"
<<inline: Feed-model-2004-11-22.jpg>>
This distinction can then be applied to Feeds. A Feed is a Document that has a header
and a list (set, or whatever) of Entries. It also has a number of Link objects, represented as association classes [3] in the UML above:
- a Link that points to the the Dynamic Feed document which is the *start* of the
feed. This document is the one that is usually considered to be the feed.
- a Link that points to the *next* newest feed document, which contains the next entry states in increasing age. This is always a Static feed.
- a Link that points to the previous Feed document. This can either be a static feed or a dynamic feed document. If the previous document is a Static document then it points to the same document as the *start* link)
We can now understand some of the confusion. Usually when people speak of a Feed, they mean the Dynamic feed document. This is the one that has a URL that people drag into their feed reader. The Dynamic Feed usually points to a Static Feed document, which in
turn points to another Static Feed document. Each of these static feed documents represent the archives of the Feed.
Since static feed documents don't change, it follows that they will also represent a history both of the entries, but also of the changes to these entries.
Would you say Mark, that the above model is a good representation of your proposal?
Henry Story
[1] http://bblfish.net/work/atom-owl/2004-08-12/ blogexample.html#entry.2004-08-12-2035.n3
[2] Martin Fowler, "UML Distilled, Second Edition" chapter 6, "Multiple and Dynamic Classification" p. 82
[3] Martin Fowler, "UML Distilled, Second Edition", chapter 6, "Association Class" p. 98
On 21 Nov 2004, at 21:41, Mark Nottingham wrote:
I'm proposing that there be two kinds of resources that you work with to get the state of an abstract Atom feed;
* A "Feed Resource" whose semantic is "I contain the most recent N entries of this feed." This is the URI that is commonly thought of as being the Atom feed's URI today; its content changes over time (much as in the same way that a page about the current weather in Baltimore will change). E.g., http://www.example.com/myfeed.atom
* An "Atom Document Resource" whose semantic is "I contain the entries present in the feed at a particular time." This is a URI to allow people to get previous "snapshots" of the feed to reconstruct them; its content does NOT change over time (much as in the same way that a page about the weather in Baltimore on November 1st, 2004 doesn't change). E.g., http://www.example.com/2004/11/01/myfeed.atom
When you get a Feed Resource, it contains a [EMAIL PROTECTED]'this']/@href that points to the Atom Document Resource for this particular Feed Document; that allows aggregators to know where its "permanent" URI is. It also contains a [EMAIL PROTECTED]'prev']/@href that points to the last Atom Document Resource published.
So, a consumer can fetch a representation of the Feed Resource and compare the 'prev' URI in it to the last 'this' URI it saw. If they don't match, it can follow the 'prev' URI; if it hasn't seen *that* document's 'prev' URI, it can walk further backwards until it's covered all of the entries that have appeared in the feed since it last saw it.
