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)系。 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) <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)連接子圖。
|
新聞熱點(diǎn)
疑難解答
圖片精選