Meme是什么呢
meme这个词起源于英国科学家理查德·道金斯(Richard Dawkins)所著的《自私的基因》(The Selfish Gene)一书,其含义是指“在诸如语言、观念、信仰、行为方式等的传递过程中与基因在生物进化过程中所起的作用相类似的那个东西。” 根据《牛津英语词典》,meme被定义为:“文化的基本单位,通过非遗传的方式,特别是模仿而得到传递。”
伴随着2005年9月memeOrandum的诞生,一个被暂时命名为Meme Engine的模式引起了blogger界很大的震动。随即跟进的几个玩家,blogniscient、tailrank更是进一步拓展了这一模式。
他们都有三个特点:
l 分析weblog来寻找其中内在模式;
l 根据某种算法寻找用户可能最感兴趣的内容;
l 将这些内容以某种合理的组织形式放在网站上。
:
由Gabe Rivera主导的这一款相关性搜索引擎,对有他们自己定义的blog列表进行实时监测,通过追寻blog的url链接来挖掘blogger之间的对话线索,并以对话的形式展现在memeOrandum的首页上。但是具体的排名算法,Gabe Rivera始终不愿意透露。所以,到现在为止,大家还只是停留在猜测上。
在某种程度上,大家愿意把它和slashdot、digg这些成名站点相提并论,并提出了slashdot效应类似的memeOrandum效应。
slashdot效应:当slashdot在网站上刊出一个新的指向另一家网站上某篇文章的链接的时候,那家网站的服务器会立刻遭到slashdot fans暴风骤雨般的点击,甚至经常引起网站服务器宕机。
:
tailrank和memeOrandum的最大不同,就是tailrank更针对个人。memeOrandum靠Gabe Rivera自己整理的一份blog监视列表,所以个人绝对无法定制Top News的排列方式。而tailrank作为后起之秀,Kevin Burton(Rojo Networks的Co-Founder以及NewsMonster的作者)注意到了这一点,从而给Web2.0 fans了一个分析他们关注的bloggers们的机会。
比如用户可以从自己的Bloglines站点导出一份OPML文件,交给tailrank。tailrank将负责针对这个列表中的blog站点进行分析,找到最新的热点或者有趣的话题,显示在tailrank首页上。
blogniscient是Ben Ruedlinger创建的blog news organizer,对blogs以及blogw文章进行分类和评级,就像memeOrandum一样,他们也拥有自己独特的算法来决定某天blog世界中热门话题是哪些。
实际上,每一个独立的国内BSP(Blog Service Provider)的首页也常会是一个由编辑人工挑选的热门文章的大杂烩。但那是一个个作为个体出现的blogger的舞台。首先,他们无法横跨众多BSP。其次,很多热门话题实际上是群体努力的结果,但是从BSP首页上你是看不出来这一点的。你甚至不知道,有多少人在谈论什么话题。你只有跟随着每一话题的blog文章中的链接一点点爬过去,才能够在大脑中整理出一个大致的对话场景。
即使是在以对话方式组织的BBS论坛中,也常常见到冠以“大杂烩整理贴”名义的就某一热点话题的所有讨论帖子的链接,充分说明了人们对这种方式喜闻乐见。
这三个玩家都是抓取blog以及Reading Listsà分析整理à找到热点话题。他们的概念有点和百度新闻搜索、Google新闻搜索和Yahoo!新闻搜索一样,把报道了相同新闻的不同站点的文章排列在一起,如下图所示:
,不同的是,这些搜索引擎是根据新闻内容的相关性。
而Meme Engine是通过监视的无数个Blog之间的文章中链接,归纳出话题的,并将这些讨论参与者列在一起。新闻搜索列出的链接之间并没有互动关系,而Meme Engine列出的链接之间则形成并且进一步加剧互动关系。
我们下面来分析memeOrandum的典型做法:
这里列出一张2006年1月20日memeOrandum的Top News“Google不向美政府 提供搜索请求名单与网址”:
很明显,由于Boing Boing的blog排名肯定在Gabe的算法中很高,所以Gabe将来自于Boing Boing的文章设置为本次meme的起源。另外两篇blog可能在文章中引用到了“DoJ search requests: Google said no; Yahoo, AOL, MSN yes.”的URL,所以他们三个形成了讨论关系。
随后,其他讨论相同内容的Blog也以同样的方式被组合在一起,列在下面。
所以,同样是这一个热点话题,却被分成了五拨人讨论,依次为:
Boing Boing :推荐优先;
两个均来自于Search Engine Watch Blog :其中和Bush Administration Demands Search Data; Google Says No, Yahoo Said Yes, MSN May Have Said Yes 的相关讨论多达十五个之多,远远多于Boing Boing的那个讨论群,但却只能居于第三位,看来Gabe并不是简单靠讨论群人数的多少来排名的。
Gabe在《Who's included?》也提到了自己的“选题”哲学:“I want writers to be selected by their peers”。他称之为“source-picking”算法:他从要涵盖的话题领域中抽选一些有代表意义的典型Blog。然后实时对这些feeds进行文本扫描,并随着文章中的url链接区找到更多的相关领域的书写者。
Kevin则可以针对用户提交进来的那些Feeds,进行相关性搜索。所以Michael Arrington评论说“personalized search/recommendation/ranking engine for the long tail of blog content”。他和memeOrandum区别就在于此,所以Alex Barnett 更愿意称之为“Attention Engine”。Alex甚至绘制了一幅图:
来说明用户提交的OPML文件仅仅只是Attention Data的一小部分,所以Kevin专门提供了一个隐秘的地方:http://tailrank.com/posts/depth/local。
实际上,Social就是对Local的扩展,即你的阅读列表中那些用户的Attention也将被你看到。比如,我的OPML列表实际很少,就是keso、只说、未完成、横戈等feeds。我在http://tailrank.com/posts/depth/local看完自己的Attention的讨论聚合之后,想看看我的Reading Lists们的Attention的讨论聚合,这样当我看到keso的TailRank个性化首页后,就会发现keso所关注的领域更多更杂,也许有更多未知的但很有趣的话题讨论blog群。
从噪音中寻找信号
“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#的需求尚没有有效的算法来解决,所以如何从噪音中找出信息,还是一个问题。
