Me-meme feed

On a lark, I wrote a small script to convert planet Intertwingly’s memes.json file to Atom format.  At the present time, this file contains no information not present in the JSON file (though to make this work, I did have to add a date field to the JSON file), but at this point it is just intended as a proof of concept, and realistically both artifacts could evolve separately.

Along the way, I made a number of design decisions that I’d appreciate feedback on.

For starters, the feed will always contain 10 entries, but the order of the entries is not fixed.  The title and alternate link for each entry will reflect the article that people are pointing to; but each entry will be assigned a separate and stable id.  Question: would rel=related be more accurate?

Additions of new references will be treated as a significant update, any other change (including dropping off of old references) will not.

The content of each meme entry will reflect the title and links of all the recent weblog entries which contain links to this URI.  Suggestions on how to make this information more semantic and more useful would be welcome.

The feed itself is valid, though from time to time the most recent link to a given entry may be from one of the homogeneous daily links entries, meaning that there may be multiple entries with the same value for atom:updated.

Sam Ruby: Me-meme feed

[link]...

Excerpt from del.icio.us/wearehugh at

Sam Ruby: Me-meme feed

wearehugh : Sam Ruby: Me-meme feed Tags : atom blogging feeds meta syndication...

Excerpt from HotLinks - Level 1 at
How about having all reference links as atom:link[@related]? Assuming the resource being represented by the entry is original url, all references to the url are “related” to that resource. I do, however, see that we have no clean way of mapping the author information of the reference link but it is no more bad than having xhtml content.

Posted by Jimy at

No, don’t put the spotters into “related” links. Put them in “via” links.

Semantically, the meme link should be a “related” link, not the entry’s “alternate”. Since aggregators don’t support that very well, I’d include the meme link in the entry content.

In summary; what you did:

<entry>
<id>tag:planet.intertwingly.net,2007:meme/40d7b8f4846fb76e736a836d8efd5cd7</id>
<link href="http://blog.whatfettle.com/2007/01/11/good-web-apis-are-just-web-sites/"/>
<title>Web APIs Are Just Web Sites</title>
<updated>2007-01-16T17:41:29Z</updated>
<content type="xhtml">
<div xmlns="http://www.w3.org/1999/xhtml">Spotted by:
<ul>
<li>Jeremy Smith: <a href="http://blog.case.edu/jms18/2007/01/16/web_apis_are_just_web_sites">Web APIs Are Just Web Sites</a></li>
<li>Josh Staiger: <a href="http://joshstaiger.org/archives/2007/01/links_for_20070_1.html">links for 2007-01-16</a></li>
<li>Mark Pilgrim: <a href="http://diveintomark.org/archives/2007/01/15/links-for-2007-01-15">links for 2007-01-15</a></li>
<li>Pete Lacey: <a href="http://wanderingbarque.com/nonintersecting/2007/01/14/link-love/">Link Love</a></li>
<li>Stefan Tilkov: <a href="http://innoq.com/blog/st/2007/01/14/web_apis_are_just_web_sites.html">Web APIs are just Web Sites</a></li>
<li>Paul Downey: <a href="http://blog.whatfettle.com/2007/01/11/good-web-apis-are-just-web-sites/">Web APIs Are Just Web Sites</a></li>
<li>Mark Baker: <a href="http://markbaker.ca/blog/2007/01/12/links-for-2007-01-12/">links for 2007-01-12</a></li>
</ul>
</div>
</content>
</entry>

How I’d do it:

<entry>
<id>tag:planet.intertwingly.net,2007:meme/40d7b8f4846fb76e736a836d8efd5cd7</id>
<link rel="related" href="http://blog.whatfettle.com/2007/01/11/good-web-apis-are-just-web-sites/"/>
<link rel="via" title="Josh Staiger: links for 2007-01-16" href="http://joshstaiger.org/archives/2007/01/links_for_20070_1.html"/>
<link rel="via" title="Mark Pilgrim: links for 2007-01-15" href="http://diveintomark.org/archives/2007/01/15/links-for-2007-01-15"/>
<link rel="via" title="Pete Lacey: Link Love" href="http://wanderingbarque.com/nonintersecting/2007/01/14/link-love/"/>
<link rel="via" title="Stefan Tilkov: Web APIs are just Web Sites" href="http://innoq.com/blog/st/2007/01/14/web_apis_are_just_web_sites.html"/>
<link rel="via" title="Paul Downey: Web APIs Are Just Web Sites" href="http://blog.whatfettle.com/2007/01/11/good-web-apis-are-just-web-sites/"/>
<link rel="via" title="Mark Baker: links for 2007-01-12" href="http://markbaker.ca/blog/2007/01/12/links-for-2007-01-12/"/>
<title>Web APIs Are Just Web Sites</title>
<updated>2007-01-16T17:41:29Z</updated>
<content type="xhtml">
<div xmlns="http://www.w3.org/1999/xhtml">
<a href="http://blog.whatfettle.com/2007/01/11/good-web-apis-are-just-web-sites/">Web APIs Are Just Web Sites</a>, spotted by:
<ul>
<li>Jeremy Smith: <a href="http://blog.case.edu/jms18/2007/01/16/web_apis_are_just_web_sites">Web APIs Are Just Web Sites</a></li>
<li>Josh Staiger: <a href="http://joshstaiger.org/archives/2007/01/links_for_20070_1.html">links for 2007-01-16</a></li>
<li>Mark Pilgrim: <a href="http://diveintomark.org/archives/2007/01/15/links-for-2007-01-15">links for 2007-01-15</a></li>
<li>Pete Lacey: <a href="http://wanderingbarque.com/nonintersecting/2007/01/14/link-love/">Link Love</a></li>
<li>Stefan Tilkov: <a href="http://innoq.com/blog/st/2007/01/14/web_apis_are_just_web_sites.html">Web APIs are just Web Sites</a></li>
<li>Paul Downey: <a href="http://blog.whatfettle.com/2007/01/11/good-web-apis-are-just-web-sites/">Web APIs Are Just Web Sites</a></li>
<li>Mark Baker: <a href="http://markbaker.ca/blog/2007/01/12/links-for-2007-01-12/">links for 2007-01-12</a></li>
</ul>
</div>
</content>
</entry>


Posted by Aristotle Pagaltzis at

links for 2007-01-17

philwilson.org: Breaking copy protection for entertainment (tags: dvd video drm) Sam Hocevar’s .plan: Exposing file parsing vulnerabilities (tags: security mplayer vlc) Isaac Jones Blog: Open, Linux-based Phones not there yet (tags: linux) Creating...

Excerpt from dive into mark at

Have you thought about marking this up with Microsoft’s Simple List Extensions? It seems like a good use of the technology, as this isn’t really a chronological feed, but more of a list based on some other factor.

Of course that would then mean including that factor into the ATOM output.

Posted by Daniel E. Renfer at
Daniel, as near as I can tell, that specification is abandonware; but I would be glad to be proven wrong.  Can anybody point me to any application which would be enhanced if I were to include SLE elements into this particular feed?

Posted by Sam Ruby at

If you think this feed is best viewed as a static list (i.e. not keeping a history of past items - only displaying the current contents of the feed), then Snarfer is one application that would benefit from the feed including cf:treatAs="list". That’s the only aspect of SLE that we currently support though.

Obviously IE7’s aggregator would benefit too.

SLE may be abandoned, and there’s no doubt it’s a hideous specification, but there are a couple of feeds that use it beneficially. That’s my justification for supporting it - not saying you should.

Posted by James Holderness at

If you think this feed is best viewed as a static list

That’s actually not my intent

Obviously IE7’s aggregator would benefit too

Forgive my ignorance, but that’s not obvious to me.  Can you expand on this (or point out a FM for me to RT)?

Additionally, I would like an answer to some of my unanswered questions.

Posted by Sam Ruby at

That’s actually not my intent

Fair enough. I’ve only just subscribed so I wasn’t really sure what to expect. I thought maybe it would be a static list of what’s currently hot. With a feed, older items tend to disappear down the list even if they’re still being actively discussed. At least in my aggregator. I suspect others might bring items back to the top if atom:updated changes (something I’ve been considering doing myself).

Forgive my ignorance, but that’s not obvious to me.  Can you expand on this (or point out a FM for me to RT)?

To be honest I haven’t tested this, but I assumed that IE did something similar to what we do when a feed was marked with cf:treatAs="list". Since that’s not what you intended, it doesn’t matter either way. They definitely support other aspects of SLE though - for example you could sort on metadata other than the title and date - but I don’t see how that would be of much benefit to you either.

Posted by James Holderness at

older items tend to disappear down the list

That’s OK with me, but is a quite different matter than not keeping a history of past items.  “iPhone was a hot topic in January 2007” is not something I actively want to erase.  If, however, a given feed consumer wishes to implement a time horizon, that’s fine with me.

I don’t know if this distinction makes any sense to you, but it does to me.

you could sort on metadata

The crucial question I never got an answer to: is this before or after normalization?

I can also point to other questions as to what the spec itself means.

Posted by Sam Ruby at

That’s OK with me, but is a quite different matter than not keeping a history of past items.  “iPhone was a hot topic in January 2007” is not something I actively want to erase.

True. I’m convinced. I’m not really a big fan of “feeds as lists” anyway (auction listings being one of the few exceptions).

you could sort on metadata

The crucial question I never got an answer to: is this before or after normalization? I can also point to other questions as to what the spec itself means.

I have no idea. I have plenty of questions I’d liked answered myself. Perhaps one day when I’m bored I’ll reverse engineer IE and see how they interpret the spec. I think by now, though, it’s fairly clear that Microsoft have no intention of ever actually documenting this stuff. SLE is hardly more open than the Word DOC format.

Posted by James Holderness at

links for 2007-01-17

From the blogroll… Inside MySpace.com 6174 time for content: there?s a train crash a-coming Me-meme feed Pray for My Friend Gmail Atom feeds 10.4: Access localhost via name from Parallels Desktop How to prevent long URL wrapping in most email...

Excerpt from The Robinson House at

Add your comment












Nav Bar