首先感谢你分享你的想法。

这里我想补充一些我个人对gmail标签系统的理解。

gmail 的标签系统，个人感觉像一个列表（List)，如果不考虑thread和时间排序的因素，更像一个字典，标签是key,而邮件是values. 如果引入权重，则更像队列(Queue), 如果引入树状层级，则相当于重新构建了一个文件系统结构，如果引入图结构，则可以构成复杂连接。从思维的角度来说，标签是给原始的信息标上了索引，即加上了语义，标签链接关系是另一层的语义。权重、父子和多维关联是队列、树和图所表达的基本语义。这里的关键是要让语义来组织信息。

访问频率作为权重、“主标签”作为“相关度”和线信作为聚合引擎，这三种方法都是基于对用户行为的跟踪得来的，可以自动执行，例如gmail的filter。但标签之间的有向关联，别名和文件夹命名则需要用户的干预，机器无法精确理解。比较好的可能是集成人工干预，例如标签的导航系统，内容分析系统，甚至搜索系统，这些都需持续的行为观察和记忆。以上是我对楼主proposal从语义和语法角度的理解。

另外，如果单纯使用语法层面的标签系统，对邮件系统而言，可能有一些困难，以下是我自己遇到的一些问题，供你在设计的时候参考：

（1）标签可能会出现错别字，会导致基于文本比较的关联失败。例如会出现多个别名，”经管“，”尽管“等其实都是想表达“经济与管理”，但用户的疏忽会导致需要一个容错机制，或一个异常的解决方式

（2）维护大量的标签所带来的麻烦是否会抵消它所带来的好处。我们使用文件系统屏蔽了直接维护inode的不便，现在我们用标签来屏蔽文件树的不便。标签所带来的扁平化的好处，可能会图、树的复杂性所消耗，从而带来新的维护负担。例如我自己在gmail中使用了有前缀的标签（使用字母顺表达优先级，共同前缀表达树状关联），但如果标签太多，标签列表就会太长而没办法在一屏显示。

（3）别名机制的冲突问题。这个你在proposal中已经提到了，如果关注度是通过文本方式(搜索和排序）来提取的，则可能会导致自递归循环，实现上比较麻烦。我猜想gmail的filter中无法使用另一个filter大概是为了避免这个问题。

不管我的理解是否贴切，以及几个特例是否有价值，都希望能早日用到你所设想的标签系统。

最后感谢你的proposal再次激发了我自己对gmail标签系统的思考。

我的反评

非常高兴能得到您极为专业的评论！由于成文匆忙，有些细节未能充分展开，旨在抛砖引玉。这不，您这块玉就给引出来了。下面请允许我对您的评论作一个反评论:－）

>>标签是给原始的信息标上了索引，即加上了语义，标签链接关系是另一层的语义。权重、父子和多维关联是队列、树和图所表达的基本语义。这里的关键是要让语义来组织信息。

说得对极了！

>>访问频率作为权重、“主标签”作为“相关度”和线信作为聚合引擎，这三种方法都是基于对用户行为的跟踪得来的，可以自动执行。

1.访问频率基于用户行为，但用户可预先赋予不同的标签以不同的初始值；

2.相关度大多需用户定义，机器难以识别，基于内容并不可靠，何况有些是binary；

3.gmail提供的thread是基于subject的，如果邮件改换subject，则属于不同的conversation。我们需要用户有自定义thread的权力。此外，对非邮件的信息系统（如文件系统），thread是难以由机器生成的。

>>比较好的可能是集成人工干预，例如标签的导航系统，内容分析系统，甚至搜索系统，这些都需持续的行为观察和记忆。

非常正确！一个智能的系统应该对用户行为有一定的预判力，这离不开平时对用户行为的观察和记忆。

>>标签可能会出现错别字，会导致基于文本比较的关联失败。用户的疏忽会导致需要一个容错机制，或一个异常的解决方式

说得没错。不妨与传统的树型结构比较：若用户通过鼠标点击，二者均无错别字问题；若通过文本，二者都可能出错。标签查询可类似文件路径支持通配符，此外若用户输入不存在的标签，可由机器生成一些可能的标签供用户选择。正如用户在google中搜索时键入错别字，google系统会提供一些可能的选择。

>>维护大量的标签所带来的麻烦是否会抵消它所带来的好处。标签所带来的扁平化的好处，可能会被图、树的复杂性所消耗，从而带来新的维护负担。

这正是我想解决的问题。随着文档增多，标签不可避免地增加。如果只是控制标签数量，每个标签下的文档过多也达不到快速检索的目的。请注意该提案主要针对海量文档，如果引入少量的麻烦能解决大量的麻烦，那么这个努力是值得的。此外，该提案是向下兼容的，如果用户的文档不足够多，大可不必引入标签之间的有向关联以及标签的权重等，这就退化为Gmail的标签系统了。就我个人经验而言，虽然Gmail邮件并不太多，仍常常借助搜索内容而不是标签来检索。这是顾忌到Gmail的标签只是一维列表，不愿引入过多标签致使列表过长。搜索内容并没有什么不好，但即使不考虑非文本内容的问题，仍有效率问题。比如，在文件系统中搜索含有某关键词的文件通常费时超过用户的容忍度。

>>例如我自己在gmail中使用了有前缀的标签（使用字母顺表达优先级，共同前缀表达树状关联），但如果标签太多，标签列表就会太长而没办法在一屏显示。

如果标签不以列表而是层级结构来排列的话，正好可解决您的问题——具有相同前缀的标签可以有共同的父标签，可以同时展开或收拢从而节省标签结构的整体高度。

>>别名机制的冲突问题。这个你在proposal中已经提到了，如果关注度是通过文本方式(搜索和排序)来提取的，则可能会导致自递归循环，实现上比较麻烦。我猜想gmail的filter中无法使用另一个filter大概是为了避免这个问题。

没有很明白您的意思。您指的是标签名（而不是别名）的冲突问题吧？其实标签名冲突不是真正的问题，如果冲突正说明它们应该合并，而这在传统的层级结构中是不可能的。如果想进一步区分，再贴另外的标签就是。

关于自递归循环的问题，我不能肯定您的意思。不过防止标签图出现单向回环是必要的。正如前述，本提案中关注度除访问频率外均由用户定义。另外，Gmail的filter虽不能组合使用，但标签可组合过滤。

系统界面设想

最后，简单设想一下提案中的系统界面。它类似windows文件浏览器（explorer），左边（只要靠边即可）是树状标签结构，点击任何标签右边将显示所有包含该标签的信息条。这与explorer有些不同：点击explorer的文件夹右边只显示子文件夹和一级子文件。右边的信息条可进一步按各种准则排序、过滤和搜索。这里暂时没有考虑一个标签有多个父标签的情形。此外，左边的标签除了tree view外，还有list view，正如Gmail的标签列表，但可按重要性、紧急性、常用性等排序。至于别名和thread，可以分别理解为标签和信息条的聚合，用户可点击展开或收拢。

参考链接

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

郑晖于2008年5月19日

1. 引言

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

2.信息检索之困

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

3. Gmail解决方案

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

4. 改进方案

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

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

5. 结论

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

Authored by Hui Zheng on May 18, 2008

1. Introduction

We are living in an age of information, but sometimes information imposes more burden than benefit. From a user’s view, most information systems including file systems, mail systems and various menu-based systems are essentially organized in hierarchical structure. As information increases, yet the usability of the sytems decreases. The major flaw of this kind of structure is that it only provides a single path to the target information. If a user misses one corner, he will possibly lose his way. This situation could be improved if an information system supports multipath routing. Aiming at this, this article proposes a practical solution by borrowing some ideas from Gmail system.

2. Information retrieval problem

Information itself is great, but storing and retrieving information sucks. Day by day, a typical computer user browses and saves web pages, collects favorite bookmarks and RSS, downloads files from BT or emule, composes and receives email, writes documents or programs etc. He enjoys all of these until someday, he finds himself gradually suffering information overload. As an evidence, he now and then feels a little bit dizzy: his desktop is terribly messy with miscellaneous icons packed like sardines, his bookmark menu pulls all the way down like a huge blanket and his inbox is cluttered with mails like a bulging bag. He comes to realize that if this situation cannot be changed, his brains must explode before his hard disk or mailbox does. Thereafter, He cultivates the habit of organizing files, bookmarks and mails into hierarchical folders. As a result, things improve a lot. Unfortunately, good times don’t last long. He finds that as his documents grow rapidly, his folders become more and more, deeper and deeper. It takes some time for him to save a document to appropriate position, and it does even more time to find a document he downloads or composes. He tends to get tired, vexed and somewhat lost when he navigates the hierarchical trees. He knows he possesses a gigantic Christmas tree with tremendous gifts hanging on, but few of them are handy. Time and time again, he fails to find an important document after exhaustive search. He doubts his memory, and occasionally, he doubts machine’s memory. Although he knows those missing stuffs will never automatically jump upon to him, he still cannot help yelling at the machine: where the hell are the damn documents hiding? From time to time, he slips back to the old habit: saving all recent files to desktop, just for better convenience and confidence. So, what is the root of the plague?

3. Gmail’s solution

It turns out that the evil root is the traditional manner of information organization, namely, tree (or forest) structure. This hierarchical structure is reasonable for large but not huge quantities of information items. As the information volume swells, the tree structure becomes unmanageable little by little. The item lists in many folders are inevitably long and some folders are deeply nested. In file systems, this symptom can be alleviated to some degree by creating shortcuts in Windows or symbolic links in Unix-family OS. But that is not a final cure. As an interesting alternative, Google’s Gmail presents what they call “label”. A label is basically a tag which could be applied to a message together with other ones. Many users complain about it at the beginning because they are used to old folder fashion. But the complaints are waning as the time passes by. The users find that their messages are no longer like guerilla hiding in deep forest, instead, they are like regular army in one-line arrangement waiting for inspection. The most recent messages are on the top to access, which is impossible in the well-organized folder system; they won’t be bewildered where to sort the messages since they can apply as many labels as they’d like to the messages; finding a specific message is easy too: users can filter by user-defined labels, or system-defined labels like inbox, sent, star, chat, trash etc. They can also search by sender, receiver, subject and message content. Even better, users can define filters that automatically apply labels to the incoming mails. This solution, henceforth we call tag structure, is not necessarily limited to mail management system, it should apply well to file system and other information systems such as knowledge management system.

4. Our solution

However, tag structure doesn’t always suffice for our needs. Even though tags are much fewer than information items, they still can overflow. In Gmail’s tag structure, all user-defined labels are independent and equal, but as a matter of fact, they are very likely different in their importance, urgency, popularity; some labels have inherent relation; the labels for a given information item vary in correlation. For example, labels like “work” or “family” are more important; labels like “todo” or “exam” are more urgent; labels like “sports” or “film” are more popular if the user is a sports or film fan. It’s also desirable that after a programmer user labels some materials as “Java” or “C++”, those materials can be automatically labeled as “programming language” and “OOP” such that he can later get all programming language-related items or OOP items in one list. Lastly, among all labels for a given information item, one may be more correlative than the others. Taking all of these into consideration, we propose a feasible solution as follows.

• Introduce hierarchical structure into tag structure. That is, we treat tags/labels as metadata of information, and organize them in the traditional tree structure. This way we combine two worlds’ best parts together. Actually, we can go further. As we know, hierarchical tree structure is a directed tree in graph theory, but we may generalize the tag structure to digraph as long as it makes sense. This will allow a tag have more than one parents, something like multiple inheritance in some OOP languages. Obviously the gmail’s tag structure is a special case of our structure when all labels are the roots(i.e. those having no sublabels).
• Introduce weight of importance, emergency and popularity for each tag so that tags are sortable by any of these respects. Gmail’s star label can serve as this purpose, but it’s too coarse-grained. The popularity weight of a tag can be chosen to be auto-incremented by each visit of the tag, which ensures the most frequently used tags are always on the top. Besides, tags can be sorted by most recent visited time. Consequently, users will have more confidence that documents they really care are available to fetch, and accessing any interesting, active and important items in the system is just a piece of cake.
• Introduce main label, i.e. one of an item’s labels can be specified as the main label. In this sense, the traditional tree structure can be viewed as a special case of our structure: any folder name is exactly a label name (There is one subtle difference, though: unlike label names, same folder names in different path wouldn’t clash). If the main label’s correlativity is 1, other labels’ should be between 0 and 1. This provides extra search and sort criteria.
• Introduce alias tag. Tags are allowed to have more than one names, these names can be abbreviations, synonyms, or even in different languages. Furthermore, alias can be more powerful: users may define a label as the logical combination of existing labels. For example, one can define “myPrograms” as “‘my documents’ and ‘programs’”, define “entertainment” as “sports or novel or movie” etc.
• Introduce thread. Users can create thread that link related message items. Gmail has conversation, but it doesn’t allow users to union mails by themselves. The thread is good for follow-ups and different document revisions. This aggregation makes information system more compact and coherent.

5. Conclusion

To locate an information item, users need click folders to expand in a hierarchical system, while they need click labels to filter in a tag system. We don’t mention search because search is slow and information content may be in binary form. The tag structure is conceivably a better solution, but it still has shortcomings. To further facilitate information retrieval, we’ve proposed a weighted diagraph tag structure, which is an improved tag structure integrating advantages of tree structure. An information system featuring this structure should be more accessible and enjoyable, and its users could be like pisciculturists, no matter how many fishes they have thrown into the ponds, any fish they desire will swim to them with waggly tail upon a single whistle.