在本文中作為示例使用的文檔是來(lái)自 Internet Movie Database（IMDB）的演員和其他人員的傳記信息（參見(jiàn) 參考資料）。為了進(jìn)行說(shuō)明，我使用 IMDB 內(nèi)容的子集構(gòu)建了一個(gè) DB2 結(jié)構(gòu)化數(shù)據(jù)庫(kù)，將這些傳記信息作為文本字段保存在數(shù)據(jù)庫(kù)中。 用 UIMA 進(jìn)行文本分析 UIMA 組件從源數(shù)據(jù)中的非結(jié)構(gòu)化數(shù)據(jù)字段中提取出結(jié)構(gòu)化的數(shù)據(jù)。不同的組件從源數(shù)據(jù)庫(kù)中讀取文檔、分析文檔來(lái)尋找提到的人名以及將結(jié)果保存到一個(gè)新數(shù)據(jù)庫(kù)（Extracted Information Database，EIDB）中。 文檔是由 SQLReader 從源數(shù)據(jù)庫(kù)中讀取的，這個(gè)組件實(shí)現(xiàn)了 UIMA 的 CollectionReader 接口，是使用 SDK 開(kāi)發(fā)的。當(dāng) UIMA 框架調(diào)用 SQLReader 的初始化方法時(shí)，它使用 JDBC™ 連接到數(shù)據(jù)庫(kù)并發(fā)出一個(gè) SQL SELECT 語(yǔ)句，這個(gè)語(yǔ)句在 SQLReader 存儲(chǔ)的 ResultSet 對(duì)象中返回需要的數(shù)據(jù)，比如文本字符串。然后，這個(gè)框架使用 CollectionReader 接口的迭代器類(lèi)方法（比如 getNext()）實(shí)際地獲取每個(gè)文檔的文本和元數(shù)據(jù)。這些數(shù)據(jù)在一個(gè) UIMA 定義的數(shù)據(jù)對(duì)象中返回給框架，這個(gè)對(duì)象稱(chēng)為 Common Analysis Structure（CAS）。實(shí)際上，因?yàn)檎诜治鑫谋疚臋n，所以這個(gè)數(shù)據(jù)對(duì)象是文本 CAS（TCAS），但是為了簡(jiǎn)單，本文忽略這一區(qū)別，只討論 CAS。當(dāng)框架調(diào)用 getNext 時(shí)，它提供一個(gè)空的 CAS。SQLReader 用來(lái)自 ResultSet 中當(dāng)前行的數(shù)據(jù)填充 CAS。所需代碼的結(jié)構(gòu)見(jiàn) 清單 1。它顯示了如何將來(lái)自輸入表的 TRIVIA 列的文檔文本和一些元數(shù)據(jù)（比如文檔的 URI）放進(jìn) CAS 中。SQLReader 還必須實(shí)現(xiàn) hasNext() 方法（這里未顯示）以便完成迭代器接口。 清單 1. 在 SQLReader 的 getNext 方法中對(duì) CAS 進(jìn)行初始化。為了簡(jiǎn)單，省略了錯(cuò)誤檢查。 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();
} 使用一個(gè) xml 描述符文件讓 UIMA 框架了解 SQLReader。每個(gè) UIMA 組件都有這樣的文件，可以使用 SDK 中的工具或手工創(chuàng)建這種文件。描述符指向組件的實(shí)現(xiàn)，在這種情況下是一個(gè)類(lèi)文件，還包含組件需要的任何配置信息。對(duì)于 SQLReader，描述符包含源數(shù)據(jù)庫(kù)的 URL 和登錄所需的用戶(hù) id/密碼等信息。在進(jìn)行初始化時(shí)，使用 UIMA 提供的方法讀取這些信息。 描述符中另一個(gè)非常重要的信息是組件使用的類(lèi)型系統(tǒng)的引用。CAS 將數(shù)據(jù)存儲(chǔ)為有類(lèi)型的結(jié)構(gòu)，類(lèi)型系統(tǒng)定義了類(lèi)型以及類(lèi)型之間的關(guān)系。圖 2 顯示 Preston 中使用的類(lèi)型系統(tǒng)。類(lèi)型系統(tǒng)是使用 SDK 工具定義的，這些工具還創(chuàng)建與類(lèi)型系統(tǒng)中的類(lèi)型對(duì)應(yīng)的 java ™ 類(lèi)。清單 1 中的 SourceDocumentInfo 就是這樣的類(lèi)。它的 URI 屬性用于保存 SQLReader 創(chuàng)建的文檔 URI。（在 UIMA 處理結(jié)束時(shí)，這個(gè) URI 將從 CAS 復(fù)制到 EIDB 中。） 圖 2. Preston 使用的 UIMA 類(lèi)型系統(tǒng)。內(nèi)置的 UIMA 類(lèi)型名顯示為斜體。箭頭指出繼續(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í)采用這種格式。（見(jiàn) 圖 3。）人名放在單引號(hào)中，后面是 “(qv)”；很輕易用正則表達(dá)式尋找這種格式。人名中惟一的復(fù)雜情況是人名本身可能包含一個(gè)或多個(gè)撇號(hào)。這個(gè)圖還說(shuō)明了 IMDB 如何消除人名的二義性，比如這里的 John Barrymore，在數(shù)據(jù)庫(kù)中可能有多個(gè)人都叫這個(gè)名字。這對(duì)于后面一個(gè)步驟是有意義的。 圖 3. 來(lái)自 IMDB 的文檔示例，說(shuō)明了源數(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 所示的類(lèi)型系統(tǒng)中的類(lèi)型實(shí)例存儲(chǔ)在 CAS 中。每個(gè)名字存儲(chǔ)為一個(gè) NameReference 對(duì)象，這個(gè)對(duì)象包含正則表達(dá)式找到的名字字符串，它的開(kāi)頭和結(jié)尾字符位置設(shè)置為 NameReference 從 Annotation 內(nèi)置類(lèi)型繼續(xù)來(lái) begin 和 end 整數(shù)特性。NameReference 還包含一個(gè) DocumentEntity 引用。這個(gè)結(jié)構(gòu)的功能是存儲(chǔ)關(guān)于文檔中提到的每個(gè)實(shí)體（人）的信息。假如多次提到一個(gè)實(shí)體，那么每次提到時(shí)都引用同一個(gè)文檔實(shí)體。使 Preston 比較簡(jiǎn)單的一個(gè)因素是：在 IMDB 數(shù)據(jù)中，提到同一個(gè)人的所有地方都采用完全相同的形式。所以，很輕易識(shí)別適當(dāng)?shù)?DocumentEntity。假如必須對(duì) Preston 進(jìn)行擴(kuò)展來(lái)處理其他類(lèi)型的輸入數(shù)據(jù)，那么必須能夠處理同一名字的不同形式。例如，假如在 圖 3 所示文檔的較長(zhǎng)版本中提到 “Mr Barrymore”，那么必須意識(shí)到這引用了與 “John Barrymore (I)” 一樣的實(shí)體。進(jìn)行這種連接所需的處理稱(chēng)為文檔內(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í)體信息必須寫(xiě)入一個(gè)結(jié)構(gòu)化數(shù)據(jù)庫(kù)。這是在文檔處理流程結(jié)束時(shí)進(jìn)行的（參見(jiàn) 圖 1）。在處理結(jié)束時(shí)接收每個(gè) CAS 的組件稱(chēng)為 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è)稱(chēng)為 cas2jdbc，它將來(lái)自每個(gè) CAS 的數(shù)據(jù)寫(xiě)到一個(gè)關(guān)系數(shù)據(jù)庫(kù)（DB2）的表中；另一個(gè)稱(chēng)為 EidbManager，它忽略接收的 CAS，但是在每次運(yùn)行開(kāi)始時(shí)設(shè)置數(shù)據(jù)庫(kù)，并在分析完所有文檔之后對(duì)所有信息進(jìn)行后期處理。 圖 4. Extracted Information Database（EIDB）的結(jié)構(gòu) 
EIDB 使用的數(shù)據(jù)模型見(jiàn) 圖 4。MENTIONS 表保存 NameReferenceAnnotator 探測(cè)到的對(duì)名字的各次提及， DOCENT 表保存文檔實(shí)體。來(lái)自這些表的示例數(shù)據(jù)見(jiàn) 圖 5。EIDB 中的其他表在后面討論。盡管這個(gè)簡(jiǎn)單的模式對(duì)于我們現(xiàn)在的意圖來(lái)說(shuō)已經(jīng)很好了，但是還可以讓它更高效。例如，文檔 URI 是長(zhǎng)字符串，由一個(gè)不變的部分和一個(gè)與文檔相關(guān)的部分組成。可以將不變的部分轉(zhuǎn)移到一個(gè)單獨(dú)的表中。在調(diào)用 EidbManager 的初始化方法時(shí)，它進(jìn)行的數(shù)據(jù)庫(kù)設(shè)置包括以 圖 4 所示的模式創(chuàng)建四個(gè)表，所使用的 SQL 語(yǔ)句是從它的描述符文件中讀取的。CAS 消費(fèi)者 cas2jdbc 是 WebSphere® Information Integrator OmniFind Edition V8.3 的一部分，Preston 使用它填充 MENTIONS 和 DOCENT 表。它是一個(gè)通用組件，用于在 XML 配置文件的控制下將來(lái)自文本 CAS 的數(shù)據(jù)寫(xiě)入關(guān)系數(shù)據(jù)庫(kù)表中。從 UIMA 類(lèi)型系統(tǒng)到關(guān)系模式的映射由配置文件控制。Preston 中 cas2jdbc 的部分配置見(jiàn) 清單 2，這顯示如何用 CAS 中的 NameReference 實(shí)例信息填充 MENTIONS 表的兩列。關(guān)于如何構(gòu)造映射文件的完整細(xì)節(jié)，請(qǐng)參考 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í)體。為了簡(jiǎn)單，已經(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ù)語(yǔ)表示在一個(gè)或多個(gè)文檔中提到的一個(gè)實(shí)體。EIDB 中的 INSTANCES 表記錄關(guān)于實(shí)例的信息，DE_INST 表維護(hù)從每個(gè)文檔實(shí)體到對(duì)應(yīng)的實(shí)例的鏈接。需要判定來(lái)自不同文檔的哪些實(shí)體實(shí)際上是同一實(shí)例，這種處理稱(chēng)為跨文檔共同引用（cross-document co-reference）。在 Preston 中，跨文檔共同引用的處理是在框架調(diào)用 EidbManager CAS 消費(fèi)者的 collectionProcessComplete 方法時(shí)執(zhí)行的。在 Preston 中，這個(gè)任務(wù)相當(dāng)簡(jiǎn)單，因?yàn)樵?IMDB 中總是以完全相同的方式提到人名，所以很輕易判定不同文檔中的哪些實(shí)體應(yīng)該鏈接到同一實(shí)例。在其他生產(chǎn)應(yīng)用程序中，跨文檔共同引用可能非常復(fù)雜，實(shí)際上這個(gè)領(lǐng)域還有待研究。在 Preston 中，這種處理只需要兩條 SQL 語(yǔ)句，它們?cè)?INSTANCES 表中為 DOCENT 表中的每組獨(dú)特人名創(chuàng)建一個(gè)條目，并在 DE_INST 表中創(chuàng)建對(duì)應(yīng)的行。Extracted Information Database 已經(jīng)完成了，可以用于數(shù)據(jù)挖掘了。 為關(guān)聯(lián)進(jìn)行數(shù)據(jù)挖掘 我們對(duì) EIDB 中的數(shù)據(jù)進(jìn)行數(shù)據(jù)挖掘，尋找高度相關(guān)的人。兩個(gè)人之間有關(guān)聯(lián)的證據(jù)是在同一個(gè)文檔中提到了他們，也就是，他們被共同提及。還可以包含其他證據(jù)，這可以通過(guò)包含其他結(jié)構(gòu)化數(shù)據(jù)（比如用數(shù)據(jù)庫(kù)表記錄哪些人為同一部電影工作過(guò)），或者通過(guò)進(jìn)行更深入的文本分析。其他文本分析使我們能夠根據(jù)文本中的語(yǔ)句尋找人們之間的其他關(guān)系。通過(guò)添加更多標(biāo)注器來(lái)尋找這些關(guān)系，并在類(lèi)型系統(tǒng)中添加更多可以存儲(chǔ)在 CAS 中的類(lèi)型，就能夠創(chuàng)建包含 “實(shí)體-關(guān)系-實(shí)體” 三元組（也稱(chēng)為 “主體-謂詞-對(duì)象” 三元組）的數(shù)據(jù)庫(kù)表。為了便于以后提供這種功能，將 EIDB 中的共同提及數(shù)據(jù)轉(zhuǎn)換為一個(gè)面向三元組的模式，實(shí)現(xiàn)的方法是在數(shù)據(jù)庫(kù)上定義一個(gè)具有這種結(jié)構(gòu)的視圖。這個(gè)視圖的模式稱(chēng)為 UIMA_RELATIONS，見(jiàn) 表 1。 表 1. UIMA_RELATIONS 視圖的模式。所有列的類(lèi)型都是 VARCHAR。| 列名 | 說(shuō)明 |
| subject_type | 主體實(shí)體的類(lèi)型，例如 NameReference。 |
| subject_uri | 主體實(shí)體的惟一標(biāo)識(shí)符，采用 URI 形式。 |
| predicate_type | 謂詞的類(lèi)型，例如 Has_name。 |
| object_type | 對(duì)象的類(lèi)型，比如 Document 或 String。 |
| object_name | 對(duì)象實(shí)體的 URI（假如它的類(lèi)型是 Document）， 或者對(duì)象的字符串值（假如它的類(lèi)型是 String）。 |
| evidence_uri | 應(yīng)用程序用來(lái)獲得這個(gè)關(guān)系的證據(jù)的 URI， 例如文檔的 URI。 |
| 列名 | 說(shuō)明 |
| name | 一個(gè)描述實(shí)體的字符串，例如一個(gè) 人實(shí)例的名字。 |
| transaction_id | 出現(xiàn)此實(shí)體的事務(wù)的惟一標(biāo)識(shí)符， 例如文檔的 URI。 |
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)連接子圖。 
未來(lái)的方向 本文描述了一個(gè)簡(jiǎn)單的應(yīng)用程序 Preston，它使用 UIMA 中的文本分析在文檔中尋找提到的人名，用找到的數(shù)據(jù)建立一個(gè)數(shù)據(jù)庫(kù)，并調(diào)用針對(duì)關(guān)聯(lián)的數(shù)據(jù)挖掘來(lái)在共同提及關(guān)系網(wǎng)絡(luò)中尋找強(qiáng)連接子圖。盡管這個(gè)應(yīng)用程序非常簡(jiǎn)單，但是它說(shuō)明了使用 UIMA 在非結(jié)構(gòu)化數(shù)據(jù)和結(jié)構(gòu)化數(shù)據(jù)之間建立聯(lián)系的主要特性。對(duì)這個(gè)應(yīng)用程序可能進(jìn)行的一種擴(kuò)展是，通過(guò)進(jìn)行更復(fù)雜的文本分析，識(shí)別更多類(lèi)型的實(shí)體以及實(shí)體之間的關(guān)系。來(lái)自不同來(lái)源的標(biāo)注器或文本分析引擎可以輕松地插入 UIMA 框架。IBM 已經(jīng)聲明有幾家業(yè)務(wù)合作伙伴正在開(kāi)發(fā)與 UIMA 兼容的文本分析組件。與 UIMA 兼容的開(kāi)放源碼組件也可以從 University of Sheffield 的 GATE 項(xiàng)目獲得（參見(jiàn) 參考資料）。 另一個(gè)擴(kuò)展是，不是將這個(gè)應(yīng)用程序部署在 SDK 上的 UIMA 框架實(shí)現(xiàn)中，而是部署在支持的 IBM 產(chǎn)品上：WebSphere Information Integrator OmniFind Edition。OmniFind 支持 UIMA 并添加了其他支持，比如從許多不同類(lèi)型的數(shù)據(jù)庫(kù)中收集文檔，以及集成文本分析和文本搜索來(lái)提供語(yǔ)義文本搜索。在這種情況下，一定要使用從 developerWorks 獲得的兼容 OmniFind 的 SDK 版本。 在 IBM Research 的推動(dòng)下，UIMA 框架還在繼續(xù)發(fā)展。盡管本文主要關(guān)注文本分析，但是 UIMA 還可以用于分析其他類(lèi)型的非結(jié)構(gòu)化信息，比如音頻和圖像。 致謝 作者希望感謝 IBM Hursley Laboratory 的 Graham Bent 將 DB2 Intelligent Miner 與文本分析組合起來(lái)，還要感謝 Internet Movie Database 答應(yīng)使用其中的內(nèi)容。 新聞熱點(diǎn)
疑難解答
圖片精選
