結構化文件索引的建立 (Indexing for Structured Documents)

對文件的檢索可分為針對文件內容的檢索(Content Query)與針對結構檢索 (Structure Query)。Content Query 只能檢索文件包含的文字內容，無法檢索任何 與文件結構有關的資訊。而 Structure Query 則可利用文件本身的結構資訊，提供 使用者較深層的檢索，例如說可以檢索文件中第二段的內容是否含有「知識擷取」

1995 1996 1997 1998

1994 1999 2000

語意索引 結構化文件 索引

Wilkinson94 Han99

Bourret00 Wolff00 Chow99

Kasukawa99

Chung99 Laforest99 Shin98

Myaeng98 Poullet97 Dao98

Lee96

的文字、第三章是否含有「數位圖書館」等等。這種可以檢索至文件結構資訊的 檢索就稱為結構檢索。

要達到結構檢索的要求，首先必須針對結構化文件的特性作索引。在結構化 文件索引的建立中，主要是提出新的索引結構以適用於結構化文件。在索引結構 的設計方面，基本上是以[Lee96]所提出的 K-ary Tree 為典範，K-ary Tree 乃是一 個完整的樹狀結構(Complete Tree Structure)，而 K 所代表的即為在文件樹狀結構 中的最大分支數。[Lee96]賦予每個節點一個「單一元素識別號(Unique Element Identifier, UID)」，代表該節點在階層式架構中的絕對位址，透過 UID 只需用簡單 的運算便可快速地找到該節點的父節點或子節點並擷取所需資料。繼[Lee96]後 發表的 [Shin98]則是將 UID 的概念擴充為整體元素識別號 (General Element Identifier, GID)以適用於多份文件中，並提出一個由下而上的檢索機制(Button Up Scheme, BUS)來檢索建置好索引後的文件。以下茲針對[Lee96]及[Shin98]作進一 步說明。

圖 2：3-ary tree 與結構化文件的對應圖

為了提供結構檢索，[Lee96]這篇論文中，首先設計了 UID 來代表各個節點 在文件樹狀結構中的位置。由於每一個結構化文件都能夠展開成為一個階層式的 樹狀結構，故作者將一份結構化文件對應到一個完整的樹狀架構(Complete K-ary

a b

e d i j

c

f g

實體節點 虛擬節點

a

b c

d e f g

h i j

Tree)上，並以該文件最大的分支數作為此樹狀結構的分支數。由此樹狀結構對 應到原始結構化文件來看，若節點存在於原始結構化文件則稱為實體節點(Real Node)，反之則稱為虛擬節點(Virtual Node)。將結構化文件對應到完整的樹狀結 構後，再根據此樹狀結構上的節點依序將 UID 配置給每一個實體節點。如 圖 2 所

進而得以快速存取節點，這便是[Lee96]中利用 K-ary Tree 來儲存結構化文件資訊 的主要目的。方程式 1 為父節點 UID 的計算公式，方程式 2 為子節點 UID 的

以表格 1 的範例來看，節點 d 為節點 h 之父節點，又節點 h 的 UID 為 14，

代入方程式 1 可知其父節點 UID 應為 1 5 3

2 ) 14

14

( =



 − +

=

parent ，的確符合節

點 d 之 UID；反之由於節點 h 為節點 d 之第一個子節點，代入方程式 2 可知其 UID 為child(5,1)=3(5−1)+1+1=14，同樣亦可驗證了此公式的正確性。

除了提出 UID 的概念來快速存取之外，[Lee96]並提出了下列五種不同的索 引結構：

1. ANWR (All Nodes With Replication)：詳細記錄包含每一個關鍵字詞出 的所有節點，相當浪費儲存空間。

2. ALWR (All Levels With Replication)：和 ANWR 相同，也記錄包含每一 個關鍵字詞的所有節點，但在樹狀結構中會根據不同的深度將其切成不 同的群組，與 ANWR 類似均會重複記錄節點資訊。

3. LNON (Leaf Nodes Only)：只記錄包含關鍵字詞的最底層節點。

4. ANOR (All Nodes Without Replication)：由 LNON 進化而來的索引結 構，若發現關鍵字詞包含在同一層的所有節點，則將此關鍵字詞提升 (Promote)到父節點上，如果提升的關鍵字詞夠多的話，將會省下可觀的 儲存空間，也會提供更有效率的檢索，故此索引結構被該論文評定為最 佳的索引結構。

5. RNON (Root Node Only)：僅儲存關鍵字詞出現的父節點，此方法雖然 非常節省空間，但無法表現出結構化文件應有的結構特性，故不是一個 好的索引架構。

舉例說明，若原本的結構化文件結構如圖 3 中的樹狀結構所示，則節點 A 儲存的索引資訊應為{personal, female, girl, woman}。Index(X)則為節點 X 中所存 的索引，每一個節點都有必須儲存的資訊，但有些資訊會重複出現在不同的節點 中，若我們直接將其記錄下來，勢必會浪費大量的儲存空間，故[Lee96]利用

ANOR 的架構(見圖 3 (b))以刪除重複儲存的資訊，大量地減少儲存所需空間。

在經過詳細的評估與分析後，也證實了該方法的效率與可行性。

圖 3：結構化文件索引範例

由於 UID 的設計主要是針對單一文件的索引，無法處理大量文件，故繼 [Lee96]發表後，[Shin98]提出了由下至上的的檢索機制(Bottom Up Scheme, BUS) 以處理大量結構化文件，其中的關鍵技術便是在 UID 的設計中多了一個文件識 別 號 (Document Identifier, DID) ， 將 UID 擴 展 成 為 GID (General Element Identifier)，加入了 DID 之後，就能夠快速地找到關鍵字詞所在的文件，再配合 原有的 UID 更可找到直接抓到文件內關鍵字詞的位置。

圖 4：由下而上的檢索機制

browsing(4) index precision

term

browsing(2) hypertext

java HTML

<5,4,2,2>

<5,32,4,7> <5,35,4,7>

. .

4 2

<1,1>

<5,11>

<5,12>

<5,11,3,6> <5,12,3,6>

6 . .

<5,4>

文件樹中的部分分支 累加器

(a) (b)

person female girl

person female woman

girl woman

person

如圖 4 所示，每一個節點都有一組四個數值組成的 GID，其含意為<DID, UID, Level, Element >，Level 為該節點在樹狀結構中的深度，而 Element 則代表 該節點的元素屬性代碼，元素屬性代碼係將結構化文件中的每一種元素都賦予一 個數值編碼而成。以<5, 32, 4, 7>而言，表示此節點是在第五篇文件中 UID 為 32 的位置，且在樹狀結構中是位於第四層，其元素屬性代碼為 7。

有了 GID 的輔助，BUS 系統在執行檢索命令時，會從樹狀結構的底部往上 搜尋。以圖 4 來看，首先系統會產生出一個累加器(Accumulators)來記錄檢索結 果，假設欲檢索的關鍵字為 browsing，則系統一旦在節點中找到 browsing 這個 字，便會將 browsing 出現的頻率累加到父節點的累加器中，以本例子即是<5,4>

的累加器。系統按照此方法由下往上把整個樹狀結構尋找完後，所有關鍵字出現 的頻率會記錄在累加器之中，系統再去尋找出現頻率最高的節點即表示是關聯性 最高的節點。

綜合以上的說明，我們知道結構化文件索引的建置將會幫助檢索的進行，系 統只需藉由索引即可快速地擷取到文件內的資料。然而在上述的相關研究工作 中，只是純粹將結構化文件的結構資訊建置成索引，所能提供的僅僅是關鍵詞檢 索，無法根據關鍵詞的語意來執行檢索動作，故本章第二節將介紹語意索引，一 種可將詞鍵彼此間的語意作相互連結的索引方法。