最近又回頭檢視古文書檢索的一些問題。
檢索的基本單位是「文件」。也就是說，檢索系統會將一份文件視為一個獨立的單位，而我們可將檢索的結果視為「多份文件的列表」。
那麼，到底什麼是「一份文件」呢？在 Web 上，通常是將一個網頁視為一份獨立的文件（來加以做索引處理）。例如，若把一本書的每一頁內容，都獨立地賦予一個 URL 來存取；那麼這本書如果有 100 頁，檢索系統就會將其視為 100 篇獨立的「小文件」。
但是這樣一來，檢索出來的前幾份文件，就有可能通通都是這本書的各個頁面。這時，如果使用者想要的，其實是另外一本書，他就很可能會覺得這樣的檢索結果「重覆太多」，認為檢索的效果不佳。
一種解決的方式，是把「具有某些共同索引特徵」（例如，同個網站的某個相同目錄）的頁面，整合起來視為一個群聚 (cluster)。檢索結果若含有多份屬於一個群聚的文件，系統可以只呈現出其中的一份。（我想，許多使用中的應用系統，都應該處理過類似的問題吧。）
最近處理古文書的檢索，也遇到 granularity 的問題。一篇很長的文章，或者一本厚厚的書，應該被切分到怎樣的程度，才算是「一份文件」？文章太長或太短，似乎都不好 -- 那麼，是不是有怎樣的準則，來判定文件合適的大小與段落？
一個例子是關於「淡新檔案」的檢索。淡新檔案的內容，是清代地方衙門裡的經年累積所成的公文卷宗，總共有1143「案」，19281「件」。因此，至少在理論上，合適的最小文件單位應該是「件」，而由多件來組成一個「案」。
問題是，歷史學者檢視淡新檔案的內容，需要看的通常不是「件」，而是一整個「案」-- 因為這樣子才有機會完整地了解分析事件的來龍去脈。想想看，當我們檢索到某本書的某一頁內容後，是不是也會想看到這本書的整體結構呢？於是，在檢索上，以「案」來做為文件單位，會不會反而比較合適呢？
不過，在基礎的資料的建構上，我覺得以「件」為單位應該是好事。或許，日後會有人嘗試運用自動的方法，尋找「件」與「件」之間的關連。例如說，以現在的「案」與「件」之間的階層關係作為標準答案，來探討把相關的「件」組合成「案」的演算法，那或許也會是一項有趣的研究呢。
4 則留言:
這些都不是新問題
我的國科會計畫"元件型文件資料庫"系列(已經拿過不連續的三年了), 很早就提出 "文件夾" 的概念, 只是在這個層次上, 有很多事情還需要慢慢定義
阿尼是資料處理的老鳥啦，所以或許對這類問題「看多了」，習以為常吧。
但有趣的，或許就是在於：概念不新，但「定義」卻很難拿捏啊。（換個角度看，定義很難拿捏，或許正是問題的困難處呢。）
在檢索上，以「案」來做為文件單位，會不會反而比較合適呢？
不太懂是什意思呢？
我不知道怎樣形容比較合適，不過或許可以這樣說：意思是，「文件」的單位該如何制訂，會不會有「比較合適」的文件「大小、樣貌」？
例如說，我們可以（極端些）這樣看待一份文件：它不過就是是一個頗長的字串，構成的基本單位（類比於原子）是 byte（如果要更細分，或許最基本的單位是 bit）。因此，從這個角度來看，整個文件是由多個子文件的序列所構成，其中每一個 byte 就算是一個子文件。
另一個看法是這樣：把文件切分為許多段落，每個段落是一份子文件。（把「段落」視為「原子」：構成文件的基本單位）。
但是，我們通常希望「原子」彼此之間有相當的獨立性，因此，或許「將章節視為（獨立的）子文件」比「將段落視為子文件」、比「將每個字元視為子文件」、比「將 byte 或 bit 視為子文件」來得好。
我覺得，「淡新檔案」可分割的最小獨立單位應該是「件」。但是，歷史學者通常不會只關心「件」，而是關心「案」（或可將「案」視為特定的件與件之間的關連）。於是，用「案」來作為文件單位，「件」來作為「子文件單位」或許比「直接用件來作為文件單位、沒有子文件的概念」來得好。
張貼留言