《关于信息系统组织方式的一个提案》的评论与反评
网友Plusy的评论
re: 关于信息系统组织方式的一个提案 2008-05-20 02:04 plusy
首先感谢你分享你的想法。
这里我想补充一些我个人对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，可以分别理解为标签和信息条的聚合，用户可点击展开或收拢。
参考链接
关于信息系统组织方式的一个提案
A Proposal on Organization of Information System