使用UIMA和DB2数据库进行的文本挖掘 （6）

  来源：IBM developerWorks 中国网站    作者：知识管理技术主管

在处理完最后一个文档之后，EIDB 中的 MENTIONS 和 DOCENT 表保存着找到的所有人名提及的信息。但是，给定的人名可能在多个文档中被提及。使用实例（instance） 这个术语表示在一个或多个文档中提到的一个实体。EIDB 中的 INSTANCES 表记录关于实例的信息，DE_INST 表维护从每个文档实体到对应的实例的链接。需要判断来自不同文档的哪些实体实际上是同一实例，这种处理称为跨文档共同引用（cross-document co-reference）。在 Preston 中，跨文档共同引用的处理是在框架调用 EidbManager CAS 消费者的 collectionProcessComplete 方法时执行的。在 Preston 中，这个任务相当简单，因为在 IMDB 中总是以完全相同的方式提到人名，所以很容易判断不同文档中的哪些实体应该链接到同一实例。在其他生产应用程序中，跨文档共同引用可能非常复杂，实际上这个领域还有待研究。在 Preston 中，这种处理只需要两条 SQL 语句，它们在 INSTANCES 表中为 DOCENT 表中的每组独特人名创建一个条目，并在 DE_INST 表中创建对应的行。Extracted Information Database 已经完成了，可以用于数据挖掘了。

　　为关联进行数据挖掘

　　我们对 EIDB 中的数据进行数据挖掘，寻找高度相关的人。两个人之间有关联的证据是在同一个文档中提到了他们，也就是，他们被共同提及。还可以包含其他证据，这可以通过包含其他结构化数据（比如用数据库表记录哪些人为同一部电影工作过），或者通过进行更深入的文本分析。其他文本分析使我们能够根据文本中的语句寻找人们之间的其他关系。通过添加更多标注器来寻找这些关系，并在类型系统中添加更多可以存储在 CAS 中的类型，就能够创建包含 “实体-关系-实体” 三元组（也称为 “主体-谓词-对象” 三元组）的数据库表。为了便于以后提供这种功能，将 EIDB 中的共同提及数据转换为一个面向三元组的模式，实现的方法是在数据库上定义一个具有这种结构的视图。这个视图的模式称为 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	应用程序用来获得这个关系的证据的 URI， 例如文档的 URI。

　　这种模式称为垂直模式（vertical schema），它有两个主要优点。它非常灵活，因为通过在 predicate_type 列中使用不同的值，可以很轻松地插入新的关系。其次，它使关系和它们的语义变成显式的，而在标准的数据库模式中许多关系隐含在模式的设计中。垂直模式还更加接近于语义 Web 标准，比如 RDF。通过定义视图而不是显式的表，可以避免垂直模式的主要缺点，即许多查询要求它与本身进行联结，而这种操作是很昂贵的。