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