從非結構化信息中獲得更多的價值。研究一個簡單的文本挖掘應用程序如何使用 UIMA SDK 構建的文本分析引擎在文檔中尋找人名。然后，另一個 UIMA 組件將結果寫入 DB2® 數(shù)據(jù)庫中的表。然后利用這些數(shù)據(jù)，使用 DB2 Intelligent Miner 尋找在文檔中經(jīng)常同時提到的人之間的強關聯(lián)。簡介人們越來越希望使用信息技術從組織中的非結構化信息中獲得更大的價值。IBM 最近引入了新的 Unstructured Information Management Architecture（UIMA）框架（參見 參考資料），這個框架簡化了分析非結構化媒體對象（比如文檔）的系統(tǒng)的開發(fā)和部署，可以用來提供語義搜索和文本挖掘等功能。文本挖掘就是用于從文本中提取信息的數(shù)據(jù)挖掘技術。接下來，具體描述一個非常簡單的文本挖掘應用程序。概述本文中描述的文本挖掘應用程序稱為 Preston，它對文檔進行分析，尋找提到的人名，并使用文本挖掘尋找經(jīng)常同時提到的人。盡管這種技術只是眾多有用的文本挖掘技術之一，但是它演示了這類應用程序的主要特性，并為介紹 UIMA 的使用提供了一個具體示例。它還演示了如何組合結構化數(shù)據(jù)庫和文本挖掘。本文面對的讀者是希望了解如何使用新的 UIMA 技術將非結構化和結構化信息聯(lián)系在一起的人。圖 1 給出了 Preston 的概況。這個程序對存儲為 DB2 數(shù)據(jù)庫表中的文本字段的文檔進行分析。UIMA 框架中的組件從數(shù)據(jù)庫讀取并分析文檔，尋找以某種格式提到的名稱，然后將結果寫到另一個數(shù)據(jù)庫 Extracted Information Database（EIDB） 中。這些組件是使用 UIMA SDK 中的工具開發(fā)和部署的，UIMA SDK 可以從 developerWorks 獲得（參見 參考資料）。對 EIDB 中的信息要進行分析后處理，以便預備進行文本挖掘，這是使用 DB2 Intelligent Miner 完成的。整個應用程序可以很輕易地在筆記本計算機上運行。圖 1. 本文中描述的 Preston 文本挖掘應用程序的概況在本文中作為示例使用的文檔是來自 Internet Movie Database（IMDB）的演員和其他人員的傳記信息（參見 參考資料）。為了進行說明，我使用 IMDB 內(nèi)容的子集構建了一個 DB2 結構化數(shù)據(jù)庫，將這些傳記信息作為文本字段保存在數(shù)據(jù)庫中。用 UIMA 進行文本分析UIMA 組件從源數(shù)據(jù)中的非結構化數(shù)據(jù)字段中提取出結構化的數(shù)據(jù)。不同的組件從源數(shù)據(jù)庫中讀取文檔、分析文檔來尋找提到的人名以及將結果保存到一個新數(shù)據(jù)庫（Extracted Information Database，EIDB）中。文檔是由 SQLReader 從源數(shù)據(jù)庫中讀取的，這個組件實現(xiàn)了 UIMA 的 CollectionReader 接口，是使用 SDK 開發(fā)的。當 UIMA 框架調(diào)用 SQLReader 的初始化方法時，它使用 JDBC™ 連接到數(shù)據(jù)庫并發(fā)出一個 SQL SELECT 語句，這個語句在 SQLReader 存儲的 ResultSet 對象中返回需要的數(shù)據(jù)，比如文本字符串。然后，這個框架使用 CollectionReader 接口的迭代器類方法（比如 getNext()）實際地獲取每個文檔的文本和元數(shù)據(jù)。這些數(shù)據(jù)在一個 UIMA 定義的數(shù)據(jù)對象中返回給框架，這個對象稱為 Common Analysis Structure（CAS）。實際上，因為正在分析文本文檔，所以這個數(shù)據(jù)對象是文本 CAS（TCAS），但是為了簡單，本文忽略這一區(qū)別，只討論 CAS。當框架調(diào)用 getNext 時，它提供一個空的 CAS。SQLReader 用來自 ResultSet 中當前行的數(shù)據(jù)填充 CAS。所需代碼的結構見 清單 1。它顯示了如何將來自輸入表的 TRIVIA 列的文檔文本和一些元數(shù)據(jù)（比如文檔的 URI）放進 CAS 中。SQLReader 還必須實現(xiàn) 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 databasepublic 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 中的工具或手工創(chuàng)建這種文件。描述符指向組件的實現(xiàn)，在這種情況下是一個類文件，還包含組件需要的任何配置信息。對于 SQLReader，描述符包含源數(shù)據(jù)庫的 URL 和登錄所需的用戶 id/密碼等信息。在進行初始化時，使用 UIMA 提供的方法讀取這些信息。描述符中另一個非常重要的信息是組件使用的類型系統(tǒng)的引用。CAS 將數(shù)據(jù)存儲為有類型的結構，類型系統(tǒng)定義了類型以及類型之間的關系。圖 2 顯示 Preston 中使用的類型系統(tǒng)。類型系統(tǒng)是使用 SDK 工具定義的，這些工具還創(chuàng)建與類型系統(tǒng)中的類型對應的 Java ™ 類。清單 1 中的 SourceDocumentInfo 就是這樣的類。它的 URI 屬性用于保存 SQLReader 創(chuàng)建的文檔 URI。（在 UIMA 處理結束時，這個 URI 將從 CAS 復制到 EIDB 中。）圖 2. Preston 使用的 UIMA 類型系統(tǒng)。內(nèi)置的 UIMA 類型名顯示為斜體。箭頭指出繼續(xù)關系。當框架從 SQLReader 獲得了 CAS 之后，將它傳遞給一個文本分析引擎（text analysis engine，TAE） 以便進行實際的分析。TAE 可以很復雜，由幾個組件組成，包括其他 TAE。但是，在 Preston 中，TAE 只包含一個組件 NameReferenceAnnotator，這個組件實現(xiàn)了 UIMA 定義的 Annotator 接口。標注器是基本的文本分析組件。它的工作是使用提供給它的 CAS 中的信息（也就是文檔文本），尋找一些新數(shù)據(jù)，然后將這些數(shù)據(jù)添加到 CAS 中。NameReferenceAnnotator 使用一個正則表達式尋找特定格式的人名，IMDB 文檔中在提到人名時采用這種格式。（見 圖 3。）人名放在單引號中，后面是 “(qv)；很輕易用正則表達式尋找這種格式。人名中惟一的復雜情況是人名本身可能包含一個或多個撇號。這個圖還說明了 IMDB 如何消除人名的二義性，比如這里的 John Barrymore，在數(shù)據(jù)庫中可能有多個人都叫這個名字。這對于后面一個步驟是有意義的。圖 3. 來自 IMDB 的文檔示例，說明了源數(shù)據(jù)中人名使用的非凡格式。Son of actor 'John Barrymore (I)' (qv) and actress 'Dolores Costello' (qv).Annotator 接口中最重要的方法是 initialize 和 process。當框架調(diào)用 initialize 時，NameReferenceAnnotator 從描述符以字符串形式讀取正則表達式并編譯它。然后，當調(diào)用 process 時，它在從 CAS 收到的文檔文本中尋找與正則表達式匹配的地方。每當找到匹配時，就將它作為圖 2 所示的類型系統(tǒng)中的類型實例存儲在 CAS 中。每個名字存儲為一個 NameReference 對象，這個對象包含正則表達式找到的名字字符串，它的開頭和結尾字符位置設置為 NameReference 從 Annotation 內(nèi)置類型繼續(xù)來 begin 和 end 整數(shù)特性。NameReference 還包含一個 DocumentEntity 引用。這個結構的功能是存儲關于文檔中提到的每個實體（人）的信息。假如多次提到一個實體，那么每次提到時都引用同一個文檔實體。使 Preston 比較簡單的一個因素是：在 IMDB 數(shù)據(jù)中，提到同一個人的所有地方都采用完全相同的形式。所以，很輕易識別適當?shù)?DocumentEntity。假如必須對 Preston 進行擴展來處理其他類型的輸入數(shù)據(jù)，那么必須能夠處理同一名字的不同形式。例如，假如在 圖 3 所示文檔的較長版本中提到 “Mr Barrymore，那么必須意識到這引用了與 “John Barrymore (I) 一樣的實體。進行這種連接所需的處理稱為文檔內(nèi)共同引用（in-document co-reference）。在 Preston 中，不需要這種處理，因為 IMDB 數(shù)據(jù)非常一致。創(chuàng)建 Extracted Information Database為了在 NameReferenceAnnotator 從文檔集合中發(fā)現(xiàn)的信息上進行文本挖掘，所有 CAS 中的提及信息和文檔實體信息必須寫入一個結構化數(shù)據(jù)庫。這是在文檔處理流程結束時進行的（參見 圖 1）。在處理結束時接收每個 CAS 的組件稱為 CAS 消費者，UIMA 為這個組件提供了 CasConsumer 接口。一個 UIMA 處理管道可以有多個 CAS 消費者，在從 Text Analysis Engine 退出時，這些 CAS 消費者依次接收每個 CAS。Preston 使用兩個 CAS 消費者。一個稱為 cas2jdbc，它將來自每個 CAS 的數(shù)據(jù)寫到一個關系數(shù)據(jù)庫（DB2）的表中；另一個稱為 EidbManager，它忽略接收的 CAS，但是在每次運行開始時設置數(shù)據(jù)庫，并在分析完所有文檔之后對所有信息進行后期處理。圖 4. Extracted Information Database（EIDB）的結構EIDB 使用的數(shù)據(jù)模型見 圖 4。MENTIONS 表保存 NameReferenceAnnotator 探測到的對名字的各次提及， DOCENT 表保存文檔實體。來自這些表的示例數(shù)據(jù)見 圖 5。EIDB 中的其他表在后面討論。盡管這個簡單的模式對于我們現(xiàn)在的意圖來說已經(jīng)很好了，但是還可以讓它更高效。例如，文檔 URI 是長字符串，由一個不變的部分和一個與文檔相關的部分組成。可以將不變的部分轉移到一個單獨的表中。在調(diào)用 EidbManager 的初始化方法時，它進行的數(shù)據(jù)庫設置包括以 圖 4 所示的模式創(chuàng)建四個表，所使用的 SQL 語句是從它的描述符文件中讀取的。CAS 消費者 cas2jdbc 是 WebSphere® Information Integrator OmniFind Edition V8.3 的一部分，Preston 使用它填充 MENTIONS 和 DOCENT 表。它是一個通用組件，用于在 XML 配置文件的控制下將來自文本 CAS 的數(shù)據(jù)寫入關系數(shù)據(jù)庫表中。從 UIMA 類型系統(tǒng)到關系模式的映射由配置文件控制。Preston 中 cas2jdbc 的部分配置見 清單 2，這顯示如何用 CAS 中的 NameReference 實例信息填充 MENTIONS 表的兩列。關于如何構造映射文件的完整細節(jié)，請參考 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 中產(chǎn)生的。注重，這里兩次提到了 Bill Cosby，但是只有一個文檔實體。為了簡單，已經(jīng)將鍵縮短了。圖 5. MENTIONS 和 DOCENT 表中的行清單 2 中的代碼段顯示如何用 NameReference 標注的 name 特性填充 MENTIONS 表的 span 列，以及如何用 entity 特性填充 docent_id 列，這使用了 cas2jdbc 為 CAS 中的每個特性結構創(chuàng)建的惟一 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 中，跨文檔共同引用的處理是在框架調(diào)用 EidbManager CAS 消費者的 collectionProcessComplete 方法時執(zhí)行的。在 Preston 中，這個任務相當簡單，因為在 IMDB 中總是以完全相同的方式提到人名，所以很輕易判定不同文檔中的哪些實體應該鏈接到同一實例。在其他生產(chǎn)應用程序中，跨文檔共同引用可能非常復雜，實際上這個領域還有待研究。在 Preston 中，這種處理只需要兩條 SQL 語句，它們在 INSTANCES 表中為 DOCENT 表中的每組獨特人名創(chuàng)建一個條目，并在 DE_INST 表中創(chuàng)建對應的行。Extracted Information Database 已經(jīng)完成了，可以用于數(shù)據(jù)挖掘了。為關聯(lián)進行數(shù)據(jù)挖掘我們對 EIDB 中的數(shù)據(jù)進行數(shù)據(jù)挖掘，尋找高度相關的人。兩個人之間有關聯(lián)的證據(jù)是在同一個文檔中提到了他們，也就是，他們被共同提及。還可以包含其他證據(jù)，這可以通過包含其他結構化數(shù)據(jù)（比如用數(shù)據(jù)庫表記錄哪些人為同一部電影工作過），或者通過進行更深入的文本分析。其他文本分析使我們能夠根據(jù)文本中的語句尋找人們之間的其他關系。通過添加更多標注器來尋找這些關系，并在類型系統(tǒng)中添加更多可以存儲在 CAS 中的類型，就能夠創(chuàng)建包含 “實體-關系-實體 三元組（也稱為 “主體-謂詞-對象 三元組）的數(shù)據(jù)庫表。為了便于以后提供這種功能，將 EIDB 中的共同提及數(shù)據(jù)轉換為一個面向三元組的模式，實現(xiàn)的方法是在數(shù)據(jù)庫上定義一個具有這種結構的視圖。這個視圖的模式稱為 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應用程序用來獲得這個關系的證據(jù)的 URI，例如文檔的 URI。這種模式稱為垂直模式（vertical schema），它有兩個主要優(yōu)點。它非常靈活，因為通過在 predicate_type 列中使用不同的值，可以很輕松地插入新的關系。其次，它使關系和它們的語義變成顯式的，而在標準的數(shù)據(jù)庫模式中許多關系隱含在模式的設計中。垂直模式還更加接近于語義 Web 標準，比如 RDF。通過定義視圖而不是顯式的表，可以避免垂直模式的主要缺點，即許多查詢要求它與本身進行聯(lián)結，而這種操作是很昂貴的。將 UIMA_RELATIONS 視圖創(chuàng)建為兩個 SQL 選擇語句的聯(lián)合。一個選擇語句為 “Mentioned_in 謂詞創(chuàng)建行，另一個為 “Has_name 謂詞創(chuàng)建行。第一個選擇語句將人和文檔聯(lián)系起來。它從 EIDB 中的 INSTANCES 表中取出人實例，并通過與其他表進行聯(lián)結，尋找提到這個人實例的文檔。證據(jù) URI 是文檔 URI。第二個 SQL 選擇語句為 “Has_name 謂詞創(chuàng)建行，它將人實例與他們的名字字符串聯(lián)系起來。因為這個謂詞所需的所有信息都在 INSTANCES 表中，因此構造一個證據(jù) URI 指向這個表中的相關行。Preston 中的數(shù)據(jù)挖掘要尋找關聯(lián)，它需要定義另一個視圖 MINING_VIEW，這個視圖的格式根據(jù)下面描述的 DB2 Intelligent Miner 工具的需求進行定義。它是通過對 UIMA_RELATIONS 視圖進行自我聯(lián)結建立的。挖掘視圖只包含兩列，見 表 2。第一個列是人可讀的實體標識符，在這個例子中是人名。第二個列是出現(xiàn)此人的 “事務 的惟一 ID。在這個例子中是提到此人的文檔的 URI。表 2. MINING_VIEW 視圖的模式。兩個列的類型都是 VARCHAR。列名說明name一個描述實體的字符串，例如一個人實例的名字。transaction_id出現(xiàn)此實體的事務的惟一標識符，例如文檔的 URI。假如我們考慮到關聯(lián)挖掘最初的動機 —— Market Basket Analysis，那么事務 ID 的重要性就很明顯了。假如把購物籃（Market Basket，例如超級市場中的購物車）看作 “事務，把它的標識符看作事務 ID，那么關聯(lián)挖掘就可以用來尋找購物車中兩個或多個商品之間的關聯(lián)。在 Preston 中，文檔相當于購物車，文檔中提到的人相當于購物車中的商品。假如還有其他關系，尤其是采用 “人-關系-人 形式的二元關系，那么關系實例相當于購物車，關系中的主體和對象是購物車中的商品，事務標識符是關系實例的標識符。關聯(lián)挖掘的輸出是一組采用以下形式的規(guī)則entity1, entity2 => entity 3這表示，在一個事務中假如同時存在 entity1 和 entity2，那么 entity3 可能以一定的概率存在。這個例子是一個長度為 3 的規(guī)則。在 Preston 中，我們尋找的規(guī)則只是將兩個人聯(lián)系起來，比如：personA => personB,這種規(guī)則的長度是 2。這個規(guī)則的強度表示 personA 和 personB 在同一個文檔中一起出現(xiàn)的可能性。強度的幾種度量由關聯(lián)的挖掘算法進行計算。我們使用 DB2 Intelligent Miner 進行關聯(lián)挖掘。安裝了 DB2 之后，可以通過在 SQL 語句中調(diào)用存儲過程來調(diào)用這個產(chǎn)品。清單 3 所示的調(diào)用使用了 Intelligent Miner 提供的一個 “簡單挖掘過程。在這個調(diào)用中，PRESTON 是創(chuàng)建的模型名，MINING_VIEW 是要挖掘的視圖，下面兩個數(shù)字參數(shù)為生成的規(guī)則的強度設置閾值，即最低支持度為 0.01%，最低可靠度是 1%。最后一個參數(shù)指定最大規(guī)則長度是 2。支持度 和可靠度 是關聯(lián)規(guī)則強度的度量。支持度就是符合這一規(guī)則的事務的比例，可靠度度量包含 personA 的文檔也提到 personB 的可能性。考慮共同提及的一種辦法是定義一個網(wǎng)絡或圖，假如兩個人在至少一個文檔中被同時提到，那么在網(wǎng)絡中就在他們之間建立鏈接。這個網(wǎng)絡隱含在挖掘視圖中。DB2 Intelligent Miner 的有用功能之一是能夠在這個網(wǎng)絡中尋找強連接的子圖。這些子圖中的人頻繁地被同時提到。一個例子見 圖 6，這是由 DB2 Intelligent Miner Visualization 繪制的。可以看到，通過對 IMDB 傳記文檔中的共同提及數(shù)據(jù)進行數(shù)據(jù)挖掘，找到了現(xiàn)實生活中一些聞名的關聯(lián)。這里采用不同的顏色表示關聯(lián)的強度，橙色比白色強，白色比藍色強。這個子圖指出了披頭士樂隊和與他們高度相關的人。清單 3. 這個 SQL 語句調(diào)用 “簡單挖掘過程 來進行關聯(lián)挖掘。BuildRuleModel 是 DB2 Intelligent Miner 提供的一個用戶定義函數(shù)。 CALL IDMMX.BuildRuleModel( 'PRESTON', 'MINING_VIEW','TRANSACTION_ID', 0.01, 1, 2)圖 6. DB2 Intelligent Miner 在文本分析找到的共同提及關系網(wǎng)絡中發(fā)現(xiàn)的強連接子圖。未來的方向本文描述了一個簡單的應用程序 Preston，它使用 UIMA 中的文本分析在文檔中尋找提到的人名，用找到的數(shù)據(jù)建立一個數(shù)據(jù)庫，并調(diào)用針對關聯(lián)的數(shù)據(jù)挖掘來在共同提及關系網(wǎng)絡中尋找強連接子圖。盡管這個應用程序非常簡單，但是它說明了使用 UIMA 在非結構化數(shù)據(jù)和結構化數(shù)據(jù)之間建立聯(lián)系的主要特性。對這個應用程序可能進行的一種擴展是，通過進行更復雜的文本分析，識別更多類型的實體以及實體之間的關系。來自不同來源的標注器或文本分析引擎可以輕松地插入 UIMA 框架。IBM 已經(jīng)聲明有幾家業(yè)務合作伙伴正在開發(fā)與 UIMA 兼容的文本分析組件。與 UIMA 兼容的開放源碼組件也可以從 University of Sheffield 的 GATE 項目獲得（參見 參考資料）。另一個擴展是，不是將這個應用程序部署在 SDK 上的 UIMA 框架實現(xiàn)中，而是部署在支持的 IBM 產(chǎn)品上：WebSphere Information Integrator OmniFind Edition。OmniFind 支持 UIMA 并添加了其他支持，比如從許多不同類型的數(shù)據(jù)庫中收集文檔，以及集成文本分析和文本搜索來提供語義文本搜索。在這種情況下，一定要使用從 developerWorks 獲得的兼容 OmniFind 的 SDK 版本。在 IBM Research 的推動下，UIMA 框架還在繼續(xù)發(fā)展。盡管本文主要關注文本分析，但是 UIMA 還可以用于分析其他類型的非結構化信息，比如音頻和圖像。致謝作者希望感謝 IBM Hursley Laboratory 的 Graham Bent 將 DB2 Intelligent Miner 與文本分析組合起來，還要感謝 Internet Movie Database 答應使用其中的內(nèi)容。