資料處理的完整性問題

莫非定律中，有一條是這麼說：凡是可能出錯的事，準會出錯。

在資料處理的流程中，有人力介入的地方，就可能會出錯 -- 而且通常都真的會出錯。例如說，用人力處理資料時，就很難維護資料的完整性（Data Integrity，或譯為資料的整合性）。

資料的完整性並不等同於資料的完備性（Completeness）。用 Google 可以在網路上找到許多不同的解釋，而我在此是想用這個詞彙來強調「資料物件之間的連結正確無誤」的特性。

例如說，網頁有個圖檔的連結，但是這個連結在點選後卻找不到正確的內容，這就是完整性出了問題。或者，應該以某種規則來指定檔案的名稱，但是卻發現了例外。又或者，資料庫的某特定欄位應該儲存「地理」資訊，事後卻發現它含有「年齡」的資料。

要檢驗資料物件之間，是否連結完整並正確，通常需要很高的人力成本。然而，如果系統從設計規劃時，就開始重視資料的完整性，我們就可以利用電腦工具來檢驗、防止錯誤，從而降低維護的成本。

沒有控管資料完整性，會增加後續處理的困難。例如，目前處理「淡新檔案」的詮釋資料，就有發現某個欄位填寫有誤（連結所提供的資訊不正確）。碰到這樣的狀況，自己是該假裝沒看見，放任它繼續出錯，還是自行將它更正？如果自己只知道它出錯，卻沒有能力更正，那又該怎麼辦呢？若要有效率地利用流程更正錯誤，或許該「彙整可疑的狀況」批次處理。只是，自己真有興趣、真有時間精力去做這件事情嗎？

資料間缺乏完整性，最終也會破壞系統所能提供的服務品質。

大量資料的呈現難題

自己一直都很關心「大量資料該如何呈現」的問題。

以文件檢索來說，就是將這些資料以「文件」作為單位，得到檢索結果後，該如何呈現文件、以及文件內容的問題。而「大量資料的呈現問題」在此就可以說是「大量文件的呈現問題」。

傳統的人機介面（Human-Computer Interface，HCI）對此似乎沒有多少著墨。不過，如何緩解超量資訊所造成的過載，似乎也是因為近幾年來 Web content 大量湧現，才顯得更為迫切。或許在幾年前，大量資料的呈現，也根本算不上是什麼重要的問題呢。

但我覺得這個問題並沒有乍看之下那麼容易。它牽涉到如何用較低的成本，來展示資料並提供互動，更關係到人類注意力有限的先天事實。

一個常見的處理方式，是將資訊分層別類地組織起來，然後提供一個瀏覽環境來讓使用者由上而下地找出想找的文件。例如，我們可以將 Windows 下的每個檔案視為一份文件，而「檔案總管」就是一個這樣的瀏覽環境。

接下來，就是提供「全文檢索」或類似的工具，讓使用者輸入關鍵字詞、指定檔案大小或最後存取的時間，然後系統將符合的文件「列表」出來。

那麼，還有沒有其他「或許更好」的方式？

合併分類瀏覽與查詢，提供「多維度」的檢索方式，曾經是我想探究的一個主題。不過，理論上說起來容易，在實作上，就經常碰到實際的問題：如何有效率地歸類或分群，如何快速地統計、過濾、彙整、計算出所需的資訊？此外，螢幕的解析度就這麼大，該怎麼把計算出的結果，有系統、有組織、易理解、易操作地呈現出來呢？

再談淡新檔案的文件檢索

約莫三個星期前，我提到了一個關於「淡新檔案」的檢索問題。

試著重述一下手頭有的東西。首先，台大圖書館有具歷史意義與價值的「淡新檔案」資料。希望利用電腦來處理這些資訊，前提是這些資訊必須數位化。於是，經過繁複的數位化處理後，我們將那些資料以「件」的方式來儲存（通常一個「件」就是一份公文，儲存為一個檔案）。

現在問題來了：歷史學者並非獨立地看待每個「件」。解讀歷史，必須鑑古識今，參考時代的脈絡與環境，才能得出有價值的解析。淡新檔案中，其實是以「案」來作為「有價值資訊」的單位，每個「案」是由多個「件」所組成，而時間則可能貫穿數十年之久。

套用流行的資訊檢索方式，是可以將「件」視為檢索的文件單位。使用者輸入查詢後，檢索結果是符合查詢條件的所有「件」的列表。

是可以用後處理（Post-Query Processing）的方式，將檢索結果分類（例如，利用阿尼說的「文件夾」概念，或者我從前論文所建議的 multi-dimensional spotlights），然後將「同個案之下的相關件」彙整在一起。但是，既然「案」才是有意義的解讀單位，而且每一個「件」其實都沒有多少（通常只有幾百）個字；那麼把「案」視為文件單位，是不是更為自然、而且便利呢？

於是，寫了一些程式，粗略地實作了將「案」視為文件單位的想法。除了因為淡新檔案裡只有一千多個「案」，彰顯不出系統的威力（從大量文件中，快速地搜尋出符合條件子集的能力）外，初步的感覺還不錯。

只是，如果真的把「案」視為文件單位，那麼如何組織與呈現一個「案」下的所有「件」，甚至整合每個「件」的「詮釋資料」(metadata)，就帶出更多有待探討與解決的問題了。或許，這也是一個值得關注、思考的研究主題呢。

從兒童繪畫，到美術欣賞

帶小朋友到「蘇荷」學畫畫。

最初是太太的朋友介紹，我只是想讓小傢伙在尚未接受正規教育之前，有段愉快的學畫經驗。然而，上過幾次課後，我發覺除了小朋友樂在其中（我們是上晚上的課程，小傢伙一早醒來就會很期待去學畫），自己其實也頗認同蘇荷的一些教育理念與實踐方式。

或許，是因為在自己的經驗裡，總覺得台灣的教育方式太過僵化死板。教給學生的內容相當充實豐富，但重點卻似乎是在強調快速地讓學生「學」到經過組織的資訊與技巧，而不是給學生充裕的時間去感覺、摸索、嘗試、乃至領悟。此外，對於學生或小孩，我們似乎也很少給予發自內心的讚賞與與鼓勵。

有意思的是，小朋友在教室裡玩耍、學著用各式各樣的材料和色彩發揮想像，蘇荷教室也為家長們安排了藝術欣賞的課程。在一系列的幻燈片講解中，我似乎漸漸明白繪畫美學的一些原理，也似乎漸漸能夠欣賞一些看不懂得現代藝術畫。

欣賞的課程中，有時我會對人類如何表達生的喜悅而感到驚喜與震撼。有些時候，我似乎也能感受到，藉著各種嘗試與創新，藝術家試圖超越人類極限的掙扎與努力。

我很喜歡這樣的課程。

告狀的時間

伴小朋友成長，每個階段都有不同的樂趣。

雖然我放在小傢伙的心思並不算太多，自己還是經常陶醉在陪伴小孩的甜蜜時光裡。我應該沒有什麼「炫耀」的用意（或許貓真人會說，我潛意識裡是這麼想 :p）；主要還是想趁著記憶猶新，把一些有趣、純真的日常瑣事記錄下來。

 告狀的時間 
前幾個月，小傢伙還不會自己上廁所尿尿，需要有大人抱著她到洗手間小解。我在家裡的時候，若她尿急，就會看到她以很著急的語氣說：「尿尿、尿尿、我要尿尿！」

然後，我就趕緊放下手邊的事情，衝過去帶她去小解。之後，我幫她穿好褲子，她會很高興地跑到太太那兒，說：「告狀的時間到了！」

原來，我幫她穿衣服褲子，經常穿得不甚整齊，需要她媽媽再幫她整理一次。看著她那麼興奮地跑去「告狀」，那麼天真的模樣，有時真會有一種難以形容的感動。

最近她漸漸學會自己去上廁所、自己穿褲子了。我想，這樣的有趣時光，或許很快地就會遠離，而被另一種成長喜悅所取代。

 我冷得發抖了啦～ 
前兩天的一個傍晚，我在家裡，小傢伙在不遠處的外婆家。

接到一通電話，是小傢伙撥來的。在電話裡，她說：「爸爸你快點拿外套來給我」。我問怎麼回事，她說：「你快點來啦，我冷得發抖了啦～」

聽到她這樣說，我趕忙拿了一件外套，小跑步到岳母家，卻發現她已經穿了好幾件衣服，不應該會覺得冷。我說，妳穿這麼多，還會冷得發抖？小傢伙說：「我是跟你開玩笑的啦。」

原來，她就是想要快點看見爸爸，所以就編織了這樣的一個理由。告訴她不可以騙人（雖然現今的政治處處可見自欺欺人的行為），告誡她「放羊的小孩」故事，卻也不禁為四歲小娃娃的聰明伶俐感到讚嘆。

推卻一個工作機會

經過一番內心交戰，傍晚打電話推卻一個「天上掉下來的工作機會」。

起因是這樣的。大約半年前，項老師說某家公司急缺技術人員的頭頭，要我到那家公司談談。我和對方約好見面，談得也算愉快，但回家後就一直沒有收到對方的通知。項老師後來問起，我說，對方可能並不是真的很急吧。

誰知道，上週四接到一通行動電話，約我週五過去吃頓午餐。席間，他們表示公司經過一番整頓，希望邀請我擔任產品研發主管。遊說的人是總經理特助，業務出身。緊迫盯人的言談，讓我不知該如何應對，就只好回答說，看看該公司能夠提供怎樣的薪資福利吧。

由於時間上，也差不多該找下一份工作了，因此我本來是有些心動的。然而，今天夜半醒來，竟然再也睡不著覺，腦袋裡盡是關於是否該到該公司工作的考量。最後，我決定推掉這份工作，原因是：

• 太太憑直覺，認為我接下那份工作會很辛苦、吃力不討好。
• 他們提供的薪資福利與配套，其實也不突出。
• 他們希望我馬上就可以去上班，如此倉促讓我覺得事有蹊蹺（更何況，半年前的經驗，讓我覺得不怎麼舒服）。
• 該公司將產品研發部門定位為利潤中心，但企畫及業務都是由其他部門負責 -- 這相當於產品的上下游都由其他部門負責，如此將很難訂定合適的績效評估方式。
• 若去那兒任職，短期內的狀況，恐怕就是在收拾一個爛攤子。該公司似乎是採用傳統的瀑布式流程開發，而 top managers 卻覺得這樣的開發模式非常好（但... 許多模組都只安排一個星期的 coding 時間耶。更何況，該部門的人員，看起來程式設計與寫作的能力都不夠呢。那麼，程式出 bugs 時怎麼辦？）。

決定推辭這個工作機會之後，心情突然輕鬆許多，有種如釋重負的感覺。

珍惜得之不易的悠閒

差不多一個月前，就很希望能夠痛快地悠閒一下。

說起來似乎不困難：就我目前的 post doctor 工作而言，自己能調控的時間相當有彈性，項老師（老闆）也沒有施加額外的壓力。不過那篇 post 寫後沒幾天，我就發覺要想痛快地睡午覺，其實也沒有想像中那麼容易。

怎麼會這樣呢？首先，需要的時間遠比想像來得多（要想舒服地睡個一小時，大概需要三個小時的空檔）。要想舒服地躺在牀上睡午覺，我最好趕在下午兩點半之前就回到家裡，簡單盥洗之後入睡才舒服。然而，若為了避開人潮，通常午餐後就已經一點半，回實驗室後處理一下雜務，通常就已經兩點多了。

接下來，就是個人的的生活習性不易調整。即使告訴自己，不要老是惦念著系統有那些地方該加強，不要一直在那邊斟酌各種模型的優缺點；但一旦有多餘的時間，自己就是會忍不住開始把玩起來。結果就是，雖然對系統與程式又多認識了一些，卻錯失了好好睡覺的機會。

最後，有了時間，通常自己還會想做些其他的事情：到書店晃晃、幫小朋友買買文具或讀物、到賣場添購家用品，或是待在家裡整理一下房間、把書籍分類整理一番。

結果，一個月下來，我沒有一天能夠睡到那麼痛快的午覺。於是自己也了解到：即使是時間有彈性，要真能享受悠閒時光，依舊是說來容易做來難。

然而，或許也正是因為如此，昨天早上有機會睡個回籠覺，醒來後的感覺竟也如此舒暢；下午找時間帶小朋友到大安森林公園，遊玩之間也更加感覺幸福。

「瞎子摸象」的故事

發覺自己的表達能力不佳之後，有時心裡會浮現一些小時候就聽過的成語。

「瞎子摸象」就是其中的一個。它的故事內容是什麼呢？

從前印度有六個瞎子。有一天，他們坐在路旁休息，正好有人牽著一隻象走過來。他們聽說是隻象，就都站起來，齊聲嚷著請求牽象的人停住，讓他們摸摸這隻象，好知道是什麼樣子。

第一個瞎子摸到象的身子，他說：「喔！象像一堵牆。」第二個瞎子摸到象的牙，他嚷著說：「你錯了！象又圓又尖的，像一支槍。」第三個瞎子摸到象的鼻子，他叫著說：「你們都錯了！象簡直像一條蛇。」第四個瞎子抱住了象腿，他說：「啊！象明明像一棵樹。」第五個瞎子個子高，剛巧摸到象的耳朵，他哼了一聲，說：「你們說的都不對！象的的確確像一把扇子。」第六個瞎子恰好摸到象的尾巴，他笑了一聲，喊著說；「你們這些笨瓜！象其實像是一根繩子。」

象牽走以後，他們仍舊在那兒爭論，每個人都覺得自己的意見是最正確的。

（文轉載自國語日報社出版「三百字故事」）

細細品味這個故事，總會讓我感覺若有所悟（主要是「若有」的感覺，其實離「悟」還差得遠啦）。瞎子們應該都是聰明人（因此能夠根據經驗推理、以具象的實物來類比，也有與他人辯論的能力），但從「明眼人」（這裡就是指看故事的讀者吧？）的角度來觀看，他們都有「以偏蓋全」的毛病啊。

據說，這個故事出自於《大般涅槃經．卷32》。我覺得這個故事另外還有個有趣的地方：「象牽走以後，他們仍舊在那兒爭論」。想出這個故事的人，好像隱隱還想告訴聽者許多人生智慧，只可惜我自己慧根與歷練都不夠，還無法感悟其中的奧妙。

人生中的許多事，都沒有標準答案、都可以有多種思考方向。每個人都可以有自己的觀點和角度，但很可能大家都沒有「對」的答案。

重新認識人生

即使可能只是一場夢，仍覺得自己似乎正在重新認識人生。

說「可能是場夢」，是懷疑它或許只是「自我催眠」的結果。不過，就好似某人說的，人生之所以有趣，部分也在於當你認為洞澈它時，一個全新的體驗，卻又讓你捉摸不透。因而，能夠放下從前的自我，學習從更開闊的角度觀看世界，總是有趣的人生成長歷程。

嗯，回想一下，是從什麼時候，開始感受到自己的心境，起了微妙的變化呢？

其實，工作了數年後，每隔一陣子，心裡就會有股強烈的「自我失落感」。一年多前，前任公司急速縮編，加上自己已年近四十，更讓這些問題浮上枱面：為什麼要工作得如此疲憊？我究竟想要什麼、想做些什麼？

於是，離職後，找了個壓力比較小的 post doctor 工作，希望能夠整理出曾經吸引我的一些有趣主題、希望能夠寫些文章。不過，這個工作做了一陣子，就發現有兩件「對自己算有趣、也頗有意義」的事情可做：開發 THDL prototype，以及完成一篇多年前起意的論文。只是，自己分身乏術、處理事情的能力也不怎麼樣，因此只好「頗有遺憾」地暫且擱下寫文章的想法。

轉眼間，這份 post doctor 工作也經歷一年了。這段期間閱讀了一些書籍，深深地感覺到自己這十年（或者，這二十年吧）來，除了追逐網路科技的新技術、除了工作經驗有所增加外，似乎沒有什麼長進。

那麼，這一年我得到了什麼呢？自己其實也說不清楚。大致上，應該都是些老生常談，都是些生活與實踐相關的感觸。或許比較強烈的一些字眼，是「藝術是個動詞」、「愛，是個動詞」、乃至「生活，也是個動詞」。動詞，指的就是必須在生活中去實踐，而不僅是表面的感覺、不僅是存於腦袋中的思考。

或許，人生本就是一場修行的歷程。誠摯地希望自己，能夠放開心胸，「活在當下」地觀看時空的深邃奧妙、感受生命的活潑躍動，進而深深地被感動、並逐漸地將感悟融入日常生活來實踐。

一個淡新檔案檢索問題

最近又回頭檢視古文書檢索的一些問題。

檢索的基本單位是「文件」。也就是說，檢索系統會將一份文件視為一個獨立的單位，而我們可將檢索的結果視為「多份文件的列表」。

那麼，到底什麼是「一份文件」呢？在 Web 上，通常是將一個網頁視為一份獨立的文件（來加以做索引處理）。例如，若把一本書的每一頁內容，都獨立地賦予一個 URL 來存取；那麼這本書如果有 100 頁，檢索系統就會將其視為 100 篇獨立的「小文件」。

但是這樣一來，檢索出來的前幾份文件，就有可能通通都是這本書的各個頁面。這時，如果使用者想要的，其實是另外一本書，他就很可能會覺得這樣的檢索結果「重覆太多」，認為檢索的效果不佳。

一種解決的方式，是把「具有某些共同索引特徵」（例如，同個網站的某個相同目錄）的頁面，整合起來視為一個群聚 (cluster)。檢索結果若含有多份屬於一個群聚的文件，系統可以只呈現出其中的一份。（我想，許多使用中的應用系統，都應該處理過類似的問題吧。）

最近處理古文書的檢索，也遇到 granularity 的問題。一篇很長的文章，或者一本厚厚的書，應該被切分到怎樣的程度，才算是「一份文件」？文章太長或太短，似乎都不好 -- 那麼，是不是有怎樣的準則，來判定文件合適的大小與段落？

一個例子是關於「淡新檔案」的檢索。淡新檔案的內容，是清代地方衙門裡的經年累積所成的公文卷宗，總共有1143「案」，19281「件」。因此，至少在理論上，合適的最小文件單位應該是「件」，而由多件來組成一個「案」。

問題是，歷史學者檢視淡新檔案的內容，需要看的通常不是「件」，而是一整個「案」-- 因為這樣子才有機會完整地了解分析事件的來龍去脈。想想看，當我們檢索到某本書的某一頁內容後，是不是也會想看到這本書的整體結構呢？於是，在檢索上，以「案」來做為文件單位，會不會反而比較合適呢？

不過，在基礎的資料的建構上，我覺得以「件」為單位應該是好事。或許，日後會有人嘗試運用自動的方法，尋找「件」與「件」之間的關連。例如說，以現在的「案」與「件」之間的階層關係作為標準答案，來探討把相關的「件」組合成「案」的演算法，那或許也會是一項有趣的研究呢。