日历

August 2009
M T W T F S S
    Sep »
 12
3456789
10111213141516
17181920212223
24252627282930
31  

关于信息系统组织方式的一个提案

关于信息系统组织方式的一个提案

序言

昨日整理Gmail信箱之时,觉有不便之处,于是进入“Suggest a feature for Gmail”的页面,准备提些建议。不意一只灵感的小虫悄悄爬上脑梢,急欲捕之而后快。遂作“A Proposal on Organization of Information System”一文,以备Gmail参考之用。甘冒不谦之嫌,窃以为该提案是对包括文件系统、邮件系统等在内的信息系统的组织方式的一种创新。为让更多的国内同仁了解,现将此文译成中文。仓促成文,还望诸位方家不吝赐教。

郑晖于2008519

1. 引言

我们生活在一个信息 时代,但有时信息带来的负担甚至超过收益。从用户的角度看,大多数信息系统包括文件系统、邮件系统和各类基于菜单的系统本质上都是层级 (hierarchical)结构的。随着信息量的递增,系统的可用性却在递减。这种结构的主要缺陷是它仅提供了通往目标信息的单一通道。用户在任何一个转角处走错都可能导致最终迷路。如果一个信息系统能支持多路通道,情况就会得到改善。有鉴于此,本文借助Gmail系统的一些思想提出了一个切实可行的方案。

2.信息检索之困

信息是个好东西,可储存和重新获取却令人头痛。日复一日地,一个典型的计算机用户浏览并保存网页,收集心仪的书签和RSS,从BTemule上 下载文件,收发电子邮件,编写文档或程序。他愉悦地享受着这一切,直到有一天他发现自己逐渐为信息超载所困扰。一个明显的迹象是他时不时感到有点头晕—— 他的桌面凌乱不堪,各种图标如沙丁鱼般“济济一堂”;他的书签菜单展开来如巨毯般一直拖到地上;他的信箱塞满邮件,鼓鼓囊囊、几欲暴裂。他开始意识到如果 这种状况不改变,他的脑袋一定比硬盘或邮箱更早爆炸。此后,他养成了将文件、书签和邮件整理到层级文件夹中的习惯。情况果然大为改观。惜乎好景不长,文档 数量增长迅猛,文件夹越来越多、越来越深。将一个文档保存到合适的地方需要花费时间,而找回当初下载或创建的文档则更花时间。整日在树状结构中穿梭,他有 些倦恼和迷失了。他知道自己拥有一棵遮天蔽日的圣诞树,上面挂满了琳琅满目的礼物,可是没有多少是触手可及的。每每在掘地三尺仍一无所获之后,他不得不怀 疑自己的记忆,偶尔也忍不住怀疑机器的记忆。明知那些失踪之物从来不会自动跳出来,他还是情不自禁地冲着电脑歇斯底里:那些该死的文档到底躲到哪里去了? 时不时地,他又滑回老习惯:将所有最新的文件保存到桌面,不为别的,只是那里似乎更方便更令人放心。我们不禁要问:这种困境的根源是什么?

3. Gmail解决方案

问题出在传统的信息组织方式上,即树(或森林)型结构。这种层级结构应付大量信息尚胜任有余,但对于海量信息则有些不堪重负。随着信息量的膨胀,树型结构越来越力不从心。许多文件夹中的列表不可避免地变长,一些文件夹被深层嵌套。在文件系统中,通过在Windows中创建捷径或在Unix类的操作系统中创建符号链接(symbolic link)能一定程度上缓解一些症状,但显然不能根治。作为一种有趣的替代方案,GoogleGmail提供了他们称作“标签”(label) 的工具。一个标签是一种文字标记,它能与其他的标签同时应用到一条信息上。开始许多用户抱怨它,因为他们习惯了文件夹风格。但这种抱怨慢慢减少,用户发现 他们的信息不再是藏于密密丛林的游击队,而是一字排开等待检阅的正规军。所有最近的信息都在顶部,而这在精心组织的文件夹系统中是不可能的。用户不再为如 何分类信息而犯难,他们可以在每条信息上贴上任意多的标签。找一个特定的信息也很容易,既可用自定义标签来过滤,也可用系统标签如inbox, sent, star, chat, trash等来过滤。他们还能通过收信人、发信人、主题和信息内容来搜索。更好的是,用户可定义过滤器自动为来信贴标签。这种解决方案,今后我们称为标签结构,不必囿于邮件管理系统,它能有效地用于文件系统和其他诸如知识管理系统之类的信息系统。

4. 改进方案

标签结构并非尽善尽美。尽管与信息数量比,标签要少得多,但依然会泛滥。在Gmail的 标签结构中,所有用户定义的标签是独立而平等的,但事实上——不同的标签在重要性、紧急性和常用性上可能大相径庭;一些标签有着内在联系;同一信息上的不 同标签在相关度上也有所不同。比如,“工作”或“家庭”的标签更重要,“待做”或“考试”的标签更紧急,“体育”或“电影”的标签对一个体育迷或电影迷来 说更常用。当一个程序员将一些资料标记为“Java”或“C++”后,他很希望它们能自动加上“程序语言”和“OOP”的标签,以便今后它们能出现在一个列表中。最后,一些标签可能比另外的标签更能描述一条信息。综合以上考虑,我们提出如下可行方案。

  • 在标签结构中引入层级结构。我们将标签视作信息的元数据,并将它们以传统的树型结构来组织。这样我们将两个世界最好的部分结合起来,取长补短。实际上我们可以走得更远。我们知道,层级树型结构在图论中是有向树,只要有意义,我们可以把标签结构推广为有向图digraph)。这意味着一个标签可以有多个上级,有点类似一些OOP语言中的多继承。显然当所有的标签都是树根(即无子标签)时,就退化为Gmail的标签结构
  • 为标签引入重要性、紧急性和常用性权重,标签可按权重排序。Gmail的星号标签可作此用,但粒度过粗。常用性权重可在每次访问后自动增值,这样最常用的标签总在前面。标签还能按最近访问时间来排序。如是,用户最关心的信息抬眼即是、垂手可得。
  • 引入主标签。一项信息的某个标签可设为主标签。从这种意义上讲,传统的树型结构是我们这种结构的特例:每个文件夹名正是一个标签名。(但有一个细微差别:同样的文件夹名在不同的路径下不会象标签名那样发生冲突)如果主标签的相关度是1,那么其他标签的相关度应在01之间,这为搜索和排序提供了新的准则。
  • 引入别名标签。标签允许有多个名字,这些名字可以是同义词、缩写甚至是不同的语种。别名还能更强大:用户可一个标签定义为其他标签的逻辑组合。例如,“我的程序”可定义为“我的文档and程序”,“娱乐”可定义为“体育or小说or电影”等等。
  • 引入线信(thread)。用户能建立thread将相关信息连接起来。Gmail中有会话(conversation),但用户无法自己合并相关邮件。thread 对信息跟踪和保留不同版本的信息非常有用,这种聚合使得信息系统更加紧凑连贯。

5. 结论

要定位一项信息,用户在层级系统中需要点击文件夹在展开,在标签系统中需要点击标签来过滤。我们没有提及搜索是因为搜索较慢且有些信息不以文本形式存在。标签系统是更好的解决方案,但仍有不足之处。为了进一步方便信息检索,我们设计了含权有向图标签结构weighted digraph tag structure),这是一种结合树型结构的优点的标签结构。一个具此结构的信息系统应该更加平易近人且令人愉快,它的用户可以象悠闲的养鱼人,不管往池塘里投入多少条鱼,只要一声口哨,他想要的那条就会摇头摆尾地游过来。

Be Sociable, Share!
分享/保存
 请您评分1星(很差)2星(不行)3星(一般)4星(不错)5星(很棒)

8 comments to 关于信息系统组织方式的一个提案

  • Todd

    这个模型很像集合论。标签描述的是一个对象集合,集合间有各种关系,还可以通过运算定义新的集合。

  • Henry

    很荣幸看到博主的文章。
    我也有类似这样的想法,和博主有几点不同的见解。

    1. 别名还是不要有了,数不清的信息在个人的身上应该收敛,应该有自己的命名空间,简单是美,少即是多。
    2. 一条信息可以有多个标签,一个标签可以有多个属性,在Gmail中,可以在和label, filter等同级的category选项卡中设置,根据需要,可以设置好多不同分类标准的view。不同的分类标准,就像是不同的哨音,引来不同的鱼。
    3. 除此之外,我现在的方法是这样的:标签Google Group的vim论坛的邮件为:comp.software.vim.group.google,如果还有linkedin的vim爱好者的group,标签为comp.software.vim.group.linkedin,或者其实就合并为comp.software.vim也是可以的。这种方法,好像是flat的,又好像是hierarchical的。

    补充一点,filter的功能挺强大的,可以当成create view来用。
    比如下面这个filter:
    (label:rec.arts.movies OR label:rec.arts.music)
    Do this: Skip Inbox, Apply label “label:rec.arts”
    这样,就对movies和music建立了一个view,好像很笨的方法~

    个人愚见,还请博主不要笑话,呵呵。

    • 非常高兴看到您的见解,下面是我的个人意见:

      >>别名还是不要有了,数不清的信息在个人的身上应该收敛,应该有自己的命名空间,简单是美,少即是多。

      文中没有提到命名空间,虽然我的确有引入它的想法。不过即使引入命名空间,别名也是有意义的。在社会化标签(如delicious)中尤其重要,有不少的同义词、全称与简写(如object-oriented programming与OOP)、单复数(如book与books)、不同语种(如programming与编程)、拼写错误等等。没有别名机制便很难将本该聚合的信息归并。

      >>一条信息可以有多个标签,一个标签可以有多个属性

      不错,这是非常关键的。文中提到标签的重要性、紧急性和常用性等都是标签的属性(当然还可引入其他属性)。

      >>标签Google Group的vim论坛的邮件为:comp.software.vim.group.google,如果还有linkedin的vim爱好者的 group,标签为comp.software.vim.group.linkedin,或者其实就合并为comp.software.vim也是可以的。这种方法,好像是flat的,又好像是hierarchical的。

      这是一种思路,有点命名空间的味道。不过相应的系统最好具有对标签模糊匹配的功能(一般的标签系统是精确匹配)

      >>filter的功能挺强大的,可以当成create view来用

      filter对邮件系统特别有意义,对其他信息系统也有借鉴作用。

      该博文是一篇老文章了。时隔一年多,本人对此又有许多新的想法,有机会系统整理一下。欢迎交流讨论!

  • 我认为这样虽然有利于查找
    但可能降低了效率
    计算机不可能真的对所有文件进行标签式的处理
    最多模拟成标签化
    实际上每一个标签都集合了一簇文件的实际地址

    也许
    树状结构也只是一种模拟
    只是不知道哪一种更快

    没有专门研究
    仅表示个人见解
    请博主不要笑话

    • >>我认为这样虽然有利于查找,但可能降低了效率

      我想你提到的效率是指运行效率吧?本文的目的正是关心用户的信息查找的效率,而不是关心软件的运行效率。软件从来是以用户为中心的,假如一个软件无法很好地满足用户需求,运行效率再高也无济于事。

  • Crazymumu

    哈哈,博主真是有很多奇思妙想的人,其实你所说的我觉得有点语义网的感觉,常规的标签是死的,如果确定了他们的层次和关系是不是更智能呢?有些标签与其它标签是继承关系,有些标签是属于关系。还有标签的频繁度也要考虑,哪些标签会重复出现,需要进行关联规则分析(毕业设计做的关联规则数据挖掘,这里小小卖弄一下)

    标签与标签之间像网一样,他们之间都有复杂的关系,网上的每个节点也有自己的频繁度。有的节点是冲突的,有的节点之间是相同意义的,有的节点是另外两个节点的和。

    其实你的建议还可以更多的推广,推广到购物网上,当你搜索nike的时候,如果nike卖光了,网站还会向你推荐adidas。等等总之是要更智能,提高用户的满意

  • liugod

    多级标签其实很多网站都需要,我们网站也正在考虑这种方式

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

  

  

  

This blog is kept spam free by WP-SpamFree.