日历

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

《关于信息系统组织方式的一个提案》的评论与反评

《关于信息系统组织方式的一个提案》的评论与反评

网友Plusy的评论 re: 关于信息系统组织方式的一个提案 2008-05-20 02:04 plusy

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

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

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

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

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

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

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

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

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

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

我的反评

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

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

说得对极了!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

系统界面设想

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

参考链接

关于信息系统组织方式的一个提案 A Proposal on Organization of Information System
Share
 请您评分1星(很差)2星(不行)3星(一般)4星(不错)5星(很棒)

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.