《關于信息系統組織方式的一個提案》的評論與反評
網友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