On 29/7/05 11:39 PM, "Henry Story" <[EMAIL PROTECTED]> wrote:
> Below I think I have worked out how one can in fact have a top20 feed, and I > show how this can be combined without trouble with the <history:next ...> > link... > > > On 29 Jul 2005, at 13:12, Eric Scheid wrote: > >> On 29/7/05 7:57 PM, "Henry Story" <[EMAIL PROTECTED]> wrote: >> >> >>> 1- The top 20 list: here one wants to move to the previous top 20 list and >>> think of them as one thing. The link to the next feed is not meant to be >>> additive. Each feed is to be seen as a whole. I have a little trouble still >>> thinking of these as feeds, but ... >>> >> >> What happens if the publisher realises they have a typo and need to emit an >> update to an entry? Would the set of 20 entries (with one entry updated) be >> seen as a complete replacement set? >> > Well if it is a typo and this is considered to be an insignificant change > then they can change the typo in the feed document and not need to change any > updated time stamps. Misspelling the name of the artist for the top 20 songs list is not insignificant. Even worse fubars are possible too -- such as attributing the wrong artist/author to the #1 song/book (and even worse: leaving off a co-author). >> The way I see it, maybe a better way would be to have a sliding window feed >> where each entry points to another Atom Feed Document with it's own URI, and >> it is that second Feed Document which contains the individual items (the top >> 20 list). >> > This is certainly closer to my intuitions too. A top 20 something is *not* a > feed. Feed entries are not ordered, and are not meant to be thought of as a > closed collection. At least this is my initial intuition. BUT.... Not all Atom Feed Documents are feeds, some are static collections of entries. We keep tripping over this :-( > I can think of a solution like the following: Let us imagine a top 20 feed > where the resources being described by the entries are the position in the > top list. So we have entries with ids such as > > http://TopOfThePops.co.uk/top20/Number1 > http://TopOfThePops.co.uk/top20/Number2 > http://TopOfThePops.co.uk/top20/Number3 ... > will contain a new entry such as > > <entry> > <title>Top of the pops entry number 1</title> > <link href="http://TopOfThePops.co.uk/top20/Number1/"/> > <id>http://TopOfThePops.co.uk/top20/Number1</id> > <updated>2005-07-05T18:30:00Z</updated> > <summary>Top of the pops winner for the week starting 5 July > 2005</summary> > </entry> The problem here is that this doesn't describe the referent, it only describes the reference. I want to see top 20 feeds where each entry links to the referent in question. For example, the Amazon Top 10 Selling Books feed would link to the book specific page at Amazon, not to some page saying "the #3 selling book is at the other end of this link". >> The idea of feeds linked to feeds has lots of utility -- feeds of comments >> for one, and even a feed of feeds available on the site. >> > I completely agree. And remember for any two things there is at least one way > they are related. And there are many different ways feeds can be related to > each other. A feed may be an archival continuation of one - which is what the > <history:next ...> link in my opinion addresses, but there are many other ways > one can relate feeds. I did a grep of an archive of atom-syntax messages .. lots of interesting possibilities in there. James has set a nice example to copy from, so expect a few I-D from me. >> Of the above, the mechanism of a single URI which redirects to the current >> issue is a situation which would still need a flag indicating that the >> appropriate thing to do is to not persist older entries. >> > I am starting to wonder whether this is really needed now that I have looked > at the top20 example I gave above. Consider the Nature case study. They have separate feed documents for each issue, but just one public URI published. The things which are entries are not Top N things but entries in a Table of Contents, and it's useful to be able to aggregate that list of articles over time. >> The other structure of feeds linking to feeds would require the aggregator >> be able to do something useful with such links, but this can be generalised >> and thus be useful for many purposes. As it is, right now with NNW I can do >> something useful with such a feed: drag & drop the item headline link to my >> subscriptions pane to subscribe to that feed and view the entries therein. >> > I myself have no problem with feeds being entries, feeds pointing to other > feeds, or anything like that. A feed is a resource. It can change. A feed is > simply a set of state changes to resources. It is that general. What's needed is a sea change in the concept model aggregators have regarding feed URIs. Right now it's exactly as if you have to Bookmark a web page before you can view it -- whereas I'd like to see feed browser where I can clickity click to wherever without having to first clutter my subscriptions list, but if I happen to like the look of a feed I can click one button to s/subscribe/bookmark/ it. A related interface design concept involves nesting - right now all my subscriptions lie flat in my subscriptions pane. I can organise them into folders, and those folders inside more folders, but the subscriptions lie flat inside there. I'd love to see my subscription list look like this; - Fave Feeds Fred's Blog (12) + Jim's Blog (23) - Mike's Blog (7) - Categories Food Cat Pix - Archives Jan 2000 Feb 2000 etc + Tom's Blog (234) I'm not aware of any feed readers that do that just yet, probably because not many feeds actually contain links to other feeds as a matter of course. Those would be feeds related to feeds there ... haven't quite thought through how I'd like to see sub-feeds of entries as yet. e.
