从噪音中寻找信号
现在的Rss Reader们(如Bloglines)都做得很好，他们简化了我们的生活，但是当RSS已经或即将成为过量信息时，我们都会烦恼如何从噪音中找到信号。herock在《Attention.xml初探》也提到：
“Attention.XML试图解决的，就是尽量减轻RSS阅读过程中的信息过载给读者造成的压力，这种过载已经渐渐成为一个普遍性的问题，未完成（对付RSS信息过载的初步想法与实践）和keso（信息过载与市场机会）和其他很多人，都在被这个问题所困扰，我坚信，“RSS信息过载”一定是一个市场的“痛点”，因为至少我自己现在就很“痛”。”
虽然还有些人在争论RSS到底如何如何，也许你可以为了追求宁可错点击三千页面也决不放过一个精彩的blog，但是对于某一部分人，他们确实需要一个简单的解决方案，他们的生活不应该被RSS所充斥。就像google/douban所做到的那样，用户看到的是简约的操作，而背后隐藏着庞大的服务器端计算量，挑选和过滤RSS信息，不应该由用户自己或者keso来做，他们应该去做更有价值更能够体现人类智慧的事情。
首先，我们要来看看某一类人在面对RSS时的反应：
Alex Barnett 说，为了知道有什么“big news”或者“little news”，他会做以下5条：
1. 知道谁在写某一主题；
2. 遍读正在发生的讨论的每一篇blog post（通过两种方法：clustering / threading）；
3. 找到睿智的思想；
4. 定义我感兴趣的主题；
5. 通过我的A-list过滤。
Alex Barnett为此创建了一个“An Attention Gap Analysis”表格，列出了当下代表这前景的四个服务提供商，对照上面列出的5种功能看看还差什么：
服务
符合标准#1~#5
不符合标准#1~#5
解决 –
filling the gaps
1#满足；
深入地解决了2#；
4#不行，无法定义用户关心并追踪的话题；
5#不行，实际上是由Gabe定义的A-List；
增加搜索功能，针对整个blog生态系统进行搜索，而不仅仅是Gabe的一张A-List；
但问题是，现在的Memeorandum编辑过程需要人的主动干涉，所当前的模式无法扩展到来满足4#。
如果我能够Memeorandum向提交我的OPML，并基于此查看和过滤，那么就能够满足5#。
1#和4#满足了；
由于订阅的内容都是我定义的，所以5#也可以；
2#不行；
3#不行；
增加“see clustered / threaded view”来解决2#；
1#是他的核心功能；
通过“authority”部分地解决了3#；
由于拥有强大的搜索(如Technorati Mini)和Tags功能，满足了4#。
2#不行；
3#不行，用户只能看到“Total”权威，因为每一个账号不可能在所有话题上都是权威，所以这种权威算法比较地刚性，无法动态变化；
无法定义自己的A-list，所以5#不满足。
增加“see clustered / threaded view”来解决2#；
如果我能够Memeorandum向提交我的OPML，并基于此查看和过滤，那么就能够满足5#。
满足1#和4#，因为可以针对我的feeds进行搜索。
满足5#。
2#和3#不行。
增加“see clustered / threaded view”来解决2#。
目前3#的需求尚没有有效的算法来解决，所以如何从噪音中找出信息，还是一个问题。
