使用UIMA和DB2 Intelligent Miner进行文本挖掘

核心提示：当框架从 SQLReader 获得了 CAS 之后，将它传递给一个文本分析引擎（text analysis engine，使用UIMA和DB2 Intelligent Miner进行文本挖掘(3)，TAE） 以便进行实际的分析，TAE 可以很复杂，它忽略接收的 CAS，但是在每次运行开始时设置数据库，由几个组件组成，包

当框架从 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）的结构