從非結構化信息中獲得更多的價值。研究一個簡單的文本挖掘應用程序如何使用 UIMA SDK 構建的文本分析引擎在文檔中尋找人名。然後，另一個 UIMA 組件將結果寫入 DB2® 數據庫中的表。然後利用這些數據，使用 DB2 Intelligent Miner 尋找在文檔中經常同時提到的人之間的強關聯。
簡介
人們越來越希望使用信息技術從組織中的非結構化信息中獲得更大的價值。IBM 最近引入了新的 Unstructured Information Management Architecture（UIMA）框架（參見 參考資料），這個框架簡化了分析非結構化媒體對象（比如文檔）的系統的開發和部署，可以用來提供語義搜索和文本挖掘等功能。文本挖掘就是用於從文本中提取信息的數據挖掘技術。接下來，詳細描述一個非常簡單的文本挖掘應用程序。
概述
本文中描述的文本挖掘應用程序稱為 Preston，它對文檔進行分析，尋找提到的人名，並使用文本挖掘尋找常常同時提到的人。盡管這種技術只是眾多有用的文本挖掘技術之一，但是它演示了這類應用程序的主要特性，並為介紹 UIMA 的使用提供了一個具體示例。它還演示了如何組合結構化數據庫和文本挖掘。本文面對的讀者是希望了解如何使用新的 UIMA 技術將非結構化和結構化信息聯系在一起的人。
圖 1 給出了 Preston 的概況。這個程序對存儲為 DB2 數據庫表中的文本字段的文檔進行分析。UIMA 框架中的組件從數據庫讀取並分析文檔，尋找以某種格式提到的名稱，然後將結果寫到另一個數據庫 Extracted Information Database（EIDB） 中。這些組件是使用 UIMA SDK 中的工具開發和部署的，UIMA SDK 可以從 developerWorks 獲得（參見 參考資料）。對 EIDB 中的信息要進行分析後處理，以便准備進行文本挖掘，這是使用 DB2 Intelligent Miner 完成的。整個應用程序可以很容易地在筆記本計算機上運行。
圖 1. 本文中描述的 Preston 文本挖掘應用程序的概況
在本文中作為示例使用的文檔是來自 Internet MovIE Database（IMDB）的演員和其他人員的傳記信息（參見 參考資料）。為了進行說明，我使用 IMDB 內容的子集構建了一個 DB2 結構化數據庫，將這些傳記信息作為文本字段保存在數據庫中。
用 UIMA 進行文本分析
UIMA 組件從源數據中的非結構化數據字段中提取出結構化的數據。不同的組件從源數據庫中讀取文檔、分析文檔來尋找提到的人名以及將結果保存到一個新數據庫（Extracted Information Database，EIDB）中。
文檔是由 SQLReader 從源數據庫中讀取的，這個組件實現了 UIMA 的 CollectionReader 接口，是使用 SDK 開發的。當 UIMA 框架調用 SQLReader 的初始化方法時，它使用 JDBC™ 連接到數據庫並發出一個 SQL SELECT 語句，這個語句在 SQLReader 存儲的 ResultSet 對象中返回需要的數據，比如文本字符串。然後，這個框架使用 CollectionReader 接口的迭代器類方法（比如 getNext()）實際地獲取每個文檔的文本和元數據。這些數據在一個 UIMA 定義的數據對象中返回給框架，這個對象稱為 Common Analysis Structure（CAS）。實際上，因為正在分析文本文檔，所以這個數據對象是文本 CAS（TCAS），但是為了簡單，本文忽略這一區別，只討論 CAS。當框架調用 getNext 時，它提供一個空的 CAS。SQLReader 用來自 ResultSet 中當前行的數據填充 CAS。所需代碼的結構見 清單 1。它顯示了如何將來自輸入表的 TRIVIA 列的文檔文本和一些元數據（比如文檔的 URI）放進 CAS 中。SQLReader 還必須實現 hasNext() 方法（這裡未顯示）以便完成迭代器接口。
清單 1. 在 SQLReader 的 getNext 方法中對 CAS 進行初始化。為了簡單，省略了錯誤檢查。
Connection conn;
ResultSet rs;
// Not shown: code to set up the Connection and to
// populate the ResultSet from the input database
public void getNext( CAS cas) {
// Not shown: code to check that the ResultSet contains more data
// Get the document text and put it into the CAS
String content = resultSet.getString( "TRIVIA"); //get document text
JCas jcas = cas.getJCas();
jcas.setDocumentText( content); // set document text
// Construct a URI for this document
String id = rs.getString( idColName); // get primary key
String url = conn.getMetaData().getURL(); // database URL
String uri = url + "/" + tableName + "/" + idColName + "#" + id;
// set URI into a SourceDocumentInfo
SourceDocumentInfo docInfo = new SourceDocumentInfo( jcas);
docInfo.setURI( uri); // set uri feature value
docInfo.addToIndexes();
// Advance to next row in the ResultSet
nextRow();
}
使用一個 XML 描述符文件讓 UIMA 框架了解 SQLReader。每個 UIMA 組件都有這樣的文件，可以使用 SDK 中的工具或手工創建這種文件。描述符指向組件的實現，在這種情況下是一個類文件，還包含組件需要的任何配置信息。對於 SQLReader，描述符包含源數據庫的 URL 和登錄所需的用戶 id/密碼等信息。在進行初始化時，使用 UIMA 提供的方法讀取這些信息。
描述符中另一個非常重要的信息是組件使用的類型系統的引用。CAS 將數據存儲為有類型的結構，類型系統定義了類型以及類型之間的關系。圖 2 顯示 Preston 中使用的類型系統。類型系統是使用 SDK 工具定義的，這些工具還創建與類型系統中的類型對應的 Java ™ 類。清單 1 中的 SourceDocumentInfo 就是這樣的類。它的 URI 屬性用於保存 SQLReader 創建的文檔 URI。（在 UIMA 處理結束時，這個 URI 將從 CAS 復制到 EIDB 中。）
圖 2. Preston 使用的 UIMA 類型系統。內置的 UIMA 類型名顯示為斜體。箭頭指出繼承關系。
當框架從 SQLReader 獲得了 CAS 之後，將它傳遞給一個文本分析引擎（text analysis engine，TAE） 以便進行實際的分析。TAE 可以很復雜，由幾個組件組成，包括其他 TAE。但是，在 Preston 中，TAE 只包含一個組件 NameReferenceAnnotator，這個組件實現了 UIMA 定義的 Annotator 接口。標注器是基本的文本分析組件。它的工作是使用提供給它的 CAS 中的信息（也就是文檔文本），尋找一些新數據，然後將這些數據添加到 CAS 中。NameReferenceAnnotator 使用一個正則表達式尋找特定格式的人名，IMDB 文檔中在提到人名時采用這種格式。（見 圖 3。）人名放在單引號中，後面是 “(qv)”；很容易用正則表達式尋找這種格式。人名中惟一的復雜情況是人名本身可能包含一個或多個撇號。這個圖還說明了 IMDB 如何消除人名的二義性，比如這裡的 John Barrymore，在數據庫中可能有多個人都叫這個名字。這對於後面一個步驟是有意義的。
圖 3. 來自 IMDB 的文檔示例，說明了源數據中人名使用的特殊格式。
Son of actor 'John Barrymore (I)' (qv) and actress 'Dolores Costello' (qv).
Annotator 接口中最重要的方法是 initialize 和 process。當框架調用 initialize 時，NameReferenceAnnotator 從描述符以字符串形式讀取正則表達式並編譯它。然後，當調用 process 時，它在從 CAS 收到的文檔文本中尋找與正則表達式匹配的地方。每當找到匹配時，就將它作為圖 2 所示的類型系統中的類型實例存儲在 CAS 中。每個名字存儲為一個 NameReference 對象，這個對象包含正則表達式找到的名字字符串，它的開頭和結尾字符位置設置為 NameReference 從 Annotation 內置類型繼承來 begin 和 end 整數特性。NameReference 還包含一個 DocumentEntity 引用。這個結構的功能是存儲關於文檔中提到的每個實體（人）的信息。如果多次提到一個實體，那麼每次提到時都引用同一個文檔實體。使 Preston 比較簡單的一個因素是：在 IMDB 數據中，提到同一個人的所有地方都采用完全相同的形式。所以，很容易識別適當的 DocumentEntity。如果必須對 Preston 進行擴展來處理其他類型的輸入數據，那麼必須能夠處理同一名字的不同形式。例如，如果在 圖 3 所示文檔的較長版本中提到 “Mr Barrymore”，那麼必須意識到這引用了與 “John Barrymore (I)” 一樣的實體。進行這種連接所需的處理稱為文檔內共同引用（in-document co-reference）。在 Preston 中，不需要這種處理，因為 IMDB 數據非常一致。
創建 Extracted Information Database
為了在 NameReferenceAnnotator 從文檔集合中發現的信息上進行文本挖掘，所有 CAS 中的提及信息和文檔實體信息必須寫入一個結構化數據庫。這是在文檔處理流程結束時進行的（參見 圖 1）。在處理結束時接收每個 CAS 的組件稱為 CAS 消費者，UIMA 為這個組件提供了 CasConsumer 接口。一個 UIMA 處理管道可以有多個 CAS 消費者，在從 Text Analysis Engine 退出時，這些 CAS 消費者依次接收每個 CAS。Preston 使用兩個 CAS 消費者。一個稱為 cas2jdbc，它將來自每個 CAS 的數據寫到一個關系數據庫（DB2）的表中；另一個稱為 EidbManager，它忽略接收的 CAS，但是在每次運行開始時設置數據庫，並在分析完所有文檔之後對所有信息進行後期處理。
圖 4. Extracted Information Database（EIDB）的結構
EIDB 使用的數據模型見 圖 4。MENTIONS 表保存 NameReferenceAnnotator 探測到的對名字的各次提及， DOCENT 表保存文檔實體。來自這些表的示例數據見 圖 5。EIDB 中的其他表在後面討論。盡管這個簡單的模式對於我們現在的意圖來說已經很好了，但是還可以讓它更高效。例如，文檔 URI 是長字符串，由一個不變的部分和一個與文檔相關的部分組成。可以將不變的部分轉移到一個單獨的表中。在調用 EidbManager 的初始化方法時，它進行的數據庫設置包括以 圖 4 所示的模式創建四個表，所使用的 SQL 語句是從它的描述符文件中讀取的。CAS 消費者 cas2jdbc 是 WebSphere® Information Integrator OmniFind Edition V8.3 的一部分，Preston 使用它填充 MENTIONS 和 DOCENT 表。它是一個通用組件，用於在 XML 配置文件的控制下將來自文本 CAS 的數據寫入關系數據庫表中。從 UIMA 類型系統到關系模式的映射由配置文件控制。Preston 中 cas2jdbc 的部分配置見 清單 2，這顯示如何用 CAS 中的 NameReference 實例信息填充 MENTIONS 表的兩列。關於如何構造映射文件的完整細節，請參考 cas2jdbc 的文檔。
如圖 5 所示，EIDB 的 MENTIONS 和 DOCENT 表中的行是從文檔 “He was marrIEd to 'Cicely Tyson' (qv) by 'Andrew Young (IV)' (qv) in the home of 'Bill Cosby' (qv). 'Bill Cosby' (qv) was the best man, and gave away the bride” 中產生的。注意，這裡兩次提到了 Bill Cosby，但是只有一個文檔實體。為了簡單，已經將鍵縮短了。
圖 5. MENTIONS 和 DOCENT 表中的行
清單 2 中的代碼段顯示如何用 NameReference 標注的 name 特性填充 MENTIONS 表的 span 列，以及如何用 entity 特性填充 docent_id 列，這使用了 cas2jdbc 為 CAS 中的每個特性結構創建的惟一 ID。
清單 2. Preston 中 CasConsumer cas2jdbc 的部分配置文件
<explicitMappingRule applyToSubtypes="false">
<type>com.ibm.fisc.preston.NameReference</type>
<table>MENTIONS</table>
<featureMappings>
<featureMapping>
<feature>name</feature>
<length>1024</length>
<column>SPAN</column>
</featureMapping>
<featureMapping>
<feature>
entity/com.ibm.fisc.preston.DocumentEntity:uniqueId()
</feature>
<column>DOCENT_ID</column>
</featureMapping>
</featureMappings>
</explicitMappingRule>
在處理完最後一個文檔之後，EIDB 中的 MENTIONS 和 DOCENT 表保存著找到的所有人名提及的信息。但是，給定的人名可能在多個文檔中被提及。使用實例（instance） 這個術語表示在一個或多個文檔中提到的一個實體。EIDB 中的 INSTANCES 表記錄關於實例的信息，DE_INST 表維護從每個文檔實體到對應的實例的鏈接。需要判斷來自不同文檔的哪些實體實際上是同一實例，這種處理稱為跨文檔共同引用（cross-document co-reference）。在 Preston 中，跨文檔共同引用的處理是在框架調用 EidbManager CAS 消費者的 collectionProcessComplete 方法時執行的。在 Preston 中，這個任務相當簡單，因為在 IMDB 中總是以完全相同的方式提到人名，所以很容易判斷不同文檔中的哪些實體應該鏈接到同一實例。在其他生產應用程序中，跨文檔共同引用可能非常復雜，實際上這個領域還有待研究。在 Preston 中，這種處理只需要兩條 SQL 語句，它們在 INSTANCES 表中為 DOCENT 表中的每組獨特人名創建一個條目，並在 DE_INST 表中創建對應的行。Extracted Information Database 已經完成了，可以用於數據挖掘了。
為關聯進行數據挖掘
我們對 EIDB 中的數據進行數據挖掘，尋找高度相關的人。兩個人之間有關聯的證據是在同一個文檔中提到了他們，也就是，他們被共同提及。還可以包含其他證據，這可以通過包含其他結構化數據（比如用數據庫表記錄哪些人為同一部電影工作過），或者通過進行更深入的文本分析。其他文本分析使我們能夠根據文本中的語句尋找人們之間的其他關系。通過添加更多標注器來尋找這些關系，並在類型系統中添加更多可以存儲在 CAS 中的類型，就能夠創建包含 “實體-關系-實體” 三元組（也稱為 “主體-謂詞-對象” 三元組）的數據庫表。為了便於以後提供這種功能，將 EIDB 中的共同提及數據轉換為一個面向三元組的模式，實現的方法是在數據庫上定義一個具有這種結構的視圖。這個視圖的模式稱為 UIMA_RELATIONS，見 表 1。
表 1. UIMA_RELATIONS 視圖的模式。所有列的類型都是 VARCHAR。
列名 說明 subject_type 主體實體的類型，例如 NameReference。 subject_uri 主體實體的惟一標識符，采用 URI 形式。 predicate_type 謂詞的類型，例如 Has_name。 object_type 對象的類型，比如 Document 或 String。 object_name 對象實體的 URI（如果它的類型是 Document），
或者對象的字符串值（如果它的類型是 String）。
evidence_uri 應用程序用來獲得這個關系的證據的 URI，例如文檔的 URI。
這種模式稱為垂直模式（vertical schema），它有兩個主要優點。它非常靈活，因為通過在 predicate_type 列中使用不同的值，可以很輕松地插入新的關系。其次，它使關系和它們的語義變成顯式的，而在標准的數據庫模式中許多關系隱含在模式的設計中。垂直模式還更加接近於語義 Web 標准，比如 RDF。通過定義視圖而不是顯式的表，可以避免垂直模式的主要缺點，即許多查詢要求它與本身進行聯結，而這種操作是很昂貴的。
將 UIMA_RELATIONS 視圖創建為兩個 SQL 選擇語句的聯合。一個選擇語句為 “Mentioned_in” 謂詞創建行，另一個為 “Has_name” 謂詞創建行。第一個選擇語句將人和文檔聯系起來。它從 EIDB 中的 INSTANCES 表中取出人實例，並通過與其他表進行聯結，尋找提到這個人實例的文檔。證據 URI 是文檔 URI。第二個 SQL 選擇語句為 “Has_name” 謂詞創建行，它將人實例與他們的名字字符串聯系起來。因為這個謂詞所需的所有信息都在 INSTANCES 表中，因此構造一個證據 URI 指向這個表中的相關行。
Preston 中的數據挖掘要尋找關聯，它需要定義另一個視圖 MINING_VIEW，這個視圖的格式根據下面描述的 DB2 Intelligent Miner 工具的需求進行定義。它是通過對 UIMA_RELATIONS 視圖進行自我聯結建立的。挖掘視圖只包含兩列，見 表 2。第一個列是人可讀的實體標識符，在這個例子中是人名。第二個列是出現此人的 “事務” 的惟一 ID。在這個例子中是提到此人的文檔的 URI。
表 2. MINING_VIEW 視圖的模式。兩個列的類型都是 VARCHAR。
列名 說明 name 一個描述實體的字符串，例如一個
人實例的名字。
transaction_id 出現此實體的事務的惟一標識符，例如文檔的 URI。
如果我們考慮到關聯挖掘最初的動機 —— Market Basket Analysis，那麼事務 ID 的重要性就很明顯了。如果把購物籃（Market Basket，例如超級市場中的購物車）看作 “事務”，把它的標識符看作事務 ID，那麼關聯挖掘就可以用來尋找購物車中兩個或多個商品之間的關聯。在 Preston 中，文檔相當於購物車，文檔中提到的人相當於購物車中的商品。如果還有其他關系，尤其是采用 “人-關系-人” 形式的二元關系，那麼關系實例相當於購物車，關系中的主體和對象是購物車中的商品，事務標識符是關系實例的標識符。
關聯挖掘的輸出是一組采用以下形式的規則
entity1, entity2 => entity 3
這表示，在一個事務中如果同時存在 entity1 和 entity2，那麼 entity3 可能以一定的概率存在。這個例子是一個長度為 3 的規則。在 Preston 中，我們尋找的規則只是將兩個人聯系起來，比如：
personA => personB,
這種規則的長度是 2。這個規則的強度表示 personA 和 personB 在同一個文檔中一起出現的可能性。強度的幾種度量由關聯的挖掘算法進行計算。
我們使用 DB2 Intelligent Miner 進行關聯挖掘。安裝了 DB2 之後，可以通過在 SQL 語句中調用存儲過程來調用這個產品。清單 3 所示的調用使用了 Intelligent Miner 提供的一個 “簡單挖掘過程”。在這個調用中，PRESTON 是創建的模型名，MINING_VIEW 是要挖掘的視圖，下面兩個數字參數為生成的規則的強度設置阈值，即最低支持度為 0.01%，最低可靠度是 1%。最後一個參數指定最大規則長度是 2。支持度 和可靠度 是關聯規則強度的度量。支持度就是符合這一規則的事務的比例，可靠度度量包含 personA 的文檔也提到 personB 的可能性。
考慮共同提及的一種辦法是定義一個網絡或圖，如果兩個人在至少一個文檔中被同時提到，那麼在網絡中就在他們之間建立鏈接。這個網絡隱含在挖掘視圖中。DB2 Intelligent Miner 的有用功能之一是能夠在這個網絡中尋找強連接的子圖。這些子圖中的人頻繁地被同時提到。一個例子見 圖 6，這是由 DB2 Intelligent Miner Visualization 繪制的。可以看到，通過對 IMDB 傳記文檔中的共同提及數據進行數據挖掘，找到了現實生活中一些著名的關聯。這裡采用不同的顏色表示關聯的強度，橙色比白色強，白色比藍色強。這個子圖指出了披頭士樂隊和與他們高度相關的人。
清單 3. 這個 SQL 語句調用 “簡單挖掘過程” 來進行關聯挖掘。BuildRuleModel 是 DB2 Intelligent Miner 提供的一個用戶定義函數。
CALL IDMMX.BuildRuleModel( 'PRESTON', 'MINING_VIEW',
'TRANSACTION_ID', 0.01, 1, 2)
圖 6. DB2 Intelligent Miner 在文本分析找到的共同提及關系網絡中發現的強連接子圖。
未來的方向
本文描述了一個簡單的應用程序 Preston，它使用 UIMA 中的文本分析在文檔中尋找提到的人名，用找到的數據建立一個數據庫，並調用針對關聯的數據挖掘來在共同提及關系網絡中尋找強連接子圖。盡管這個應用程序非常簡單，但是它說明了使用 UIMA 在非結構化數據和結構化數據之間建立聯系的主要特性。對這個應用程序可能進行的一種擴展是，通過進行更復雜的文本分析，識別更多類型的實體以及實體之間的關系。來自不同來源的標注器或文本分析引擎可以輕松地插入 UIMA 框架。IBM 已經聲明有幾家業務合作伙伴正在開發與 UIMA 兼容的文本分析組件。與 UIMA 兼容的開放源碼組件也可以從 University of SheffIEld 的 GATE 項目獲得（參見 參考資料）。
另一個擴展是，不是將這個應用程序部署在 SDK 上的 UIMA 框架實現中，而是部署在支持的 IBM 產品上：WebSphere Information Integrator OmniFind Edition。OmniFind 支持 UIMA 並添加了其他支持，比如從許多不同類型的數據庫中收集文檔，以及集成文本分析和文本搜索來提供語義文本搜索。在這種情況下，一定要使用從 developerWorks 獲得的兼容 OmniFind 的 SDK 版本。
在 IBM Research 的推動下，UIMA 框架還在繼續發展。盡管本文主要關注文本分析，但是 UIMA 還可以用於分析其他類型的非結構化信息，比如音頻和圖像。
致謝
作者希望感謝 IBM Hursley Laboratory 的 Graham Bent 將 DB2 Intelligent Miner 與文本分析組合起來，還要感謝 Internet MovIE Database 允許使用其中的內容。
