进行非结构化信息管理和自动文本分析的系统和方法

摘要

本发明涉及进行非结构化信息管理和自动文本分析的系统和方法。具体地，本发明公开了一种用于非结构化信息管理系统(UIMS)的系统架构、部件和搜索技术。UIMS可以作为中间件提供，用于在信息源的广泛阵列上有效地管理和交换非结构化信息。所述架构通常包括一个搜索引擎、数据存储器以及包含流水线化文档标注器和各种适配器的分析引擎。该搜索技术利用二级搜索技术。一个搜索查询包括一个搜索操作符，该操作符包括多个搜索子表达式，每一个子表达式具有相关的权重值。搜索引擎将权重值和大于权重值和阈值的文档返回。所述搜索操作符被实现为按照加权与(WAND)工作的布尔判定。

说明书

技术领域

本发明总体上涉及信息管理系统，更具体地涉及用于实现包括自动文本分析和信息搜索的非结构化信息管理系统的系统、方法和计算机程序。

背景技术

在现代社会中，文本数据的量越来越大。其原因是多方面的，但其中一个重要的驱动力是个人计算机系统和数据库的广泛使用，以及电子邮件的不断增加。结果是广泛地产生和散布了各种格式和表现形式的文本数据并需要对其存储。

尽管总体趋势是正面的，因为知识在社会上的传播一般都被视为是一个有益的目标。但是，也产生了问题，这是因为，文档数据的量远远超过了感兴趣的人或者组织对文档数据进行阅读、消化和归类的能力。

尽管在目前文本数据代表了大多数的文档数据，并且在本专利申请的上下文中也主要讨论文本数据，但是，越来越多的文档是以多媒体的形式被创建和分发，比如是这样的形式：文档既包含文本，又包含图像(静态的或者动态的，比如视频剪辑)，或者既包含文本，又包含音频。

作为对不断增加的基于文本的文档数据的回应，显然，必须开发一些有效的手段来管理不断增加的文档数据。这个研究领域可以称为非结构化信息管理(unstructured information management)，并可以视为包括存储、访问、检索、导航和发现(主要)基于文本的信息中的知识的工具和方法。

例如，随着业务方法的持续发展，以有效而彻底的方式处理非结构化信息的需求不断增长。这种信息的例子包括记录的自然语言对话、多语言对话、文本翻译、科学出版物等等。

共同受让的美国专利US6553385B2，″Architecture of aFramework for Information Extraction from Natural LanguageDocuments”，by David E.Johnson andThomas Hampp-Bahnmueller，描述了一种从15种自然语言文档中提取信息的架构，该架构与应用无关，并提供高度的可重复使用性。该架构集成了不同的自然语言/及其学习技术，比如句法分析和分类。该架构的结构被集成在一个易于使用的访问层中。该架构执行一般信息提取、自然语言文档的分类/归类、自动电子数据传送(例如电子邮件和传真)处理和路由，以及句法分析。在该架构内，对信息提取的请求被传送给信息提取器。该架构能够包括应用数据的预处理和后处理和对提取器的控制。该架构还能够提供关于应用应该对数据采取的必要动作的建议。为了达到容易集成和扩展的目标，该架构提供了一种集成(外部)应用程序接口(API)和提取器(内部)API。

在不与本发明的教导相冲突的方面，美国专利No.6553385B2的公开在此全部引为参考。

所需要的是这样的能力：对来自各种来源和各种格式的文档数据进行有效的、综合性的处理，以从文档数据提取出所需的信息，以用于但不限于下述目的：搜索、索引(index)、分类以及数据和文本挖掘(data and textual mining)。

发明内容

根据本发明的优选实施例，克服了上述以及其它一些问题，实现了一些优点。

这里所公开的是一种非结构化信息管理(UIM)系统。该UIM的重要方面包括UIM架构(UIMA)、其部件以及由UIMA实现的方法。UIMA提供一种有效、及时地处理来自各种来源的文档信息的机制。UIMA的一个重要优点在于吸收(消化)和处理非结构化信息的能力。

UIMA的一个方面在于其是模块化的，使得其能够被部署在一台计算机上或者分布在多台计算机上，并且能够复制和/或优化其组件以便适应当前的非结构化信息管理任务。

该UIMA能够与其它加强信息的应用有效地集成。一个非限制性的例子是，将UIMA与用于发现新药的生命科学应用相集成。

UIMA的各方面还包括但不限于语义搜索引擎、文档库、文本分析引擎(TAE)、结构化知识源适配器、集合处理管理器和集合分析引擎。在优选实施例中，UIMA既接收结构化信息也接收非结构化信息以产生相关的知识。包括在TAE中的有公共分析系统(CAS)、标注器(Annotator)和控制器。

公开的UIMA的一部分还包括使用二级检索处理的有效的查询评估处理器。

还公开了一种数据处理系统，用来处理存储的数据，该系统包括用于存储数据单元的集合的数据存储器以及连接到该数据存储器的搜索引擎，该搜索引擎对从所述数据存储器中检索至少一个数据单元的查询作出响应。该查询包括一个搜索操作符，该搜索操作符由多个搜索子表达式构成，每一个子表达式具有相关的权重，所述搜索引擎将权重和大于权重和阈值的数据单元返回。在一个优选实施例中，数据单元包括文档。

更具体地，该查询包括一个作为加权与(WeightedAND(WAND))工作的布尔判定(Boolean predicate)。WAND将一系列布尔变量X₁、X₂、......X_k、一系列相关正权重w₁、w₂、......w_k和阈值θ作为参数，其中，如果

$>>>\Sigma >>1>\le >i>\le >k>\; >>>x>i>>>w>i>>>\ge >\theta >,>>>$

则(WAND)(X₁，w₁，...X_k，w_k，θ)为真。

其中，xi是Xi的指示变量(indicator variable)，其中如果Xi为真则x_i＝1，否则x_i＝0。

WAND可以被用于通过下述方式实现AND函数和OR函数中的一个：

AND(X₁，X₂，...X_k)≡WAND(X₁，1，X₂，1，...X_k，1，k)，

以及

OR(X₁，X₂，...X_k)≡WAND(X₁，1，X₂，1，...X_k，1，1)。

本发明还公开了一种处理文档数据的方法，以及实现在计算机可读介质中的计算机程序产品，其中包含程序代码，用于指令与至少一个应用合作的文本情报系统的操作。该计算机程序产品包括一个用于存储数据单元的集合的计算机程度段，以及实现一个搜索引擎的计算机程序段，该搜索引擎对检索至少一个存储的数据单元的查询作出响应。该查询包括一个搜索操作符，该搜索操作符由多个搜索子表达式构成，每一个子表达式具有相关的权重，所述搜索引擎将权重和大于权重和阈值的数据单元返回。

附图说明

在下面结合附图对优选实施例的详细说明中，本发明的前述及其它方面会更加清楚。附图中：

图1的框图表示本发明的非结构化信息管理系统的总体架构；

图2的框图表示简单分析引擎；

图3的框图表示聚集分析引擎；

图4A的流程图用于说明公共分析系统(CAS)中的工作流的一个例子，该流程图还可以视为构成文本分析引擎的一部分的多个串联标注器的一个例子；

图4B图示了相互连接的标注器的另一个实施方式的例子，其中，有至少两个并行的标注器路径；

图5是一个举例的类型定义的图表；

图6是一个举例的特征定义的图表；

图7是图示举例的部件列表的图表；

图8是描述工作流的生成的流程图；

图9是描述工作流验证的流程图；

图10A描述了单个继承树中的关系的一个例子；

图10B描述了使用多个继承的数据建模的例子；

图11的框图提供了公共分析系统的总览；

图12的框图用于描述文本分析引擎的另外的关系；

图13是举例的标注结构的图形描述；

图14的框图用于描述标注器的操作；

图15的框图用于指出标记(token)和跨度(span)之间的关系，并且是倒排文件系统的一个例子；

图16的框图提供了跨度分布(跨度的出现，span occurrence)的替代表达；

图17的示意图用于举例说明在预处理阶段与跨度(span)之间的关系；

图18的流程图用于描述用于发现文本中的关系的预处理；

图19是表示标注索引、关系索引、跨度(span)和参数之间的关系的框图；

图20的框图表示一个文档的各种表达的视图的例子，及其对应的标记化(tokenization)；

图20A表示通过对文档进行各种标记化衍生出来的多种视图；

图21是描述使用视图的搜索的各个方面的关系图；

图22是描述数据模型的各个方面的关系图；

图23的框图用于描述部件之间的接口的各个方面；

图24的框图表示预处理和运行时环境(run-time)的各个方面；

图25的流程图表示模式(pattern)和权重阈值之间的关系；

图26是用于WAND迭代器的init()方法的伪码的例子；

图27是用于WAND迭代器的next()方法的伪码的例子；

图28的流程图是对WAND过程的流的概括；

图29的曲线图表示WAND过程的效率结果；

图30的曲线图表示WAND过程的效率结果；

图31的曲线图表示WAND过程的效率结果；

图32的框图用于描述与生命科学应用相结合的非结构化信息管理系统；

图33A和33B描述了用于创建对解释公共分析系统(CAS)的操作有用的数据的伪码的例子，图33C是用于基于CAS的数据访问的伪码的例子，图示了在标记(token)上使用迭代；

图34描述了文档文本的n个字符列(三字符列)标记化的一个例子。

具体实施方式

本发明公开的是非结构化信息管理架构(UnstructuredInformation Management Architecture(ULMA))。下面的说明的总体结构如下：

I.引言

II.架构功能概览

文档级分析

集合级分析

语义搜索访问

结构化知识访问

III.架构部件概览

搜索引擎

文档库

分析引擎

IV.系统接口

V.二级搜索

VI.举例的实施方式和思考

I.引言

这里所公开的UIMA最好实现为用于开发应用程序的软件和硬件的结合，将对结构化和非结构化信息的组合的搜索和分析集成起来。“结构化信息”在这里是指这样的信息：其要表达的含义没有模糊性，并且明确地表示在数据的结构或者格式中。结构化信息的一个合适的例子是数据库表。“非结构化信息”在这里是指这样的信息：其要表达的含义只是隐含在其形式中。非结构化信息的一个合适的例子是自然语言文档。

应用UIMA部件向最终用户赋予某种能力的软件程序通常通称为，比如，应用、应用程序或者软件程序。应用的一个例子是下面将参照图32描述的生命科学应用程序。

图1图示了UIMA高级架构的一个实施例。UIMA高级架构定义相互协作以实现UIM应用的大尺度部件的角色、接口和通信。这些部件包括能够分析非结构化人工产物源比如包含文本数据和/或图像数据的文档、集成和访问结构化源、基于发现的语义内容存储、索引和搜索人工产物的部件。

图1图示了UIMA100的非限制性的实施例，其包括一个语义搜索引擎110、文档库120、至少一个文本分析引擎(TAE)130、至少一个结构化知识源适配器140、集合处理管理器150、至少一个集合分析引擎160和应用逻辑170。在优选实施例中，UIMA100既接收结构化信息180又接收非结构化信息以产生相关知识195。非结构化信息可以视为文档190的集合，可以是文本、图形、静止或者动态图像、音频以及它们的各种组合。被UIMA100吸收的文档中的给定文档称为文档190A。

示于图1的UIMA100的各个方面进一步图示于图2中，其中，图示了各简单分析引擎(PAE)200，它可以是文本分析引擎130的部件。在PAE200中还包括一个公共分析系统(CAS)210、一个标注器220和一个控制器230。在图3中图示了TAE130的第二实施例，其中，聚集分析引擎(AAE，Aggregate Analysis Engine)300由两个或者更多个部件分析引擎221、222、223以及CAS210构成，并实现与PAE200相同的外部接口。在聚集分析引擎300中还包括控制器230、分析定序器310和分析结构代理320。下面将对这些特征作进一步的说明，因此在这里只是一个简介。

II.架构功能概览

应当注意，前述仅仅是一个实施例和引言而已。因此，图示于图1、2和3中的UIMA100的部件的各个方面都是可以改变的。例如，TAE130可以包括适当的引擎用于分析除文本外的数据，比如语音或者视频。

尽管UIMA100的实施例延伸到多种非结构化人工产物(包括但不限于语音、音频、视频等)，但是这里的说明基本上只涉及这样的UIMA100实现：涉及文本数据形式的人类语言技术。另外，如这里所公开的，用于处理的作为文档190A的非结构化信息的元素可以包括整个文本文档、一个文本文档片断或者多个文档。因此，这里的教导只应视为对UIMA100的各个方面的举例说明。

也就是，UIMA100可以实现为具有各种结构的各种实施例。例如，可以认为，将UIMA100实现为一个大的系统，或者实现为几个小的分布式系统是有利的。决定具体的实现方式的因素比如有实现的规模以及其它一些因素等。

现在说明UIMA100的功能的各个方面的概览。这些方面包括分析和访问功能。分析功能被分为两类：即文档级分析和集合级分析。访问功能被分为语义搜索访问和结构化知识访问。下面介绍这些功能中的每一个。

II.A文档级分析

由称为文本分析引擎(TAE)130的成分处理部件来执行文档级分析。它们是一般分析引擎的扩展，专用于文本。TAE130的各个方面可以认为与Cunningham等人在2000年在GATE架构中公开的处理资源类似。在UIMA200中，TAE130最好是递归结构，可以由子部件或者部件引擎构成，每一个子部件或者部件引擎执行不同级阶段(stage)的应用分析。

文本分析引擎130的例子包括语言翻译器、文档摘要器、文档分类器和有名实体探测器。每一个TAE130用来发现文档文本190A中原本不能识别的或者说隐含的特定概念(或者说“语义实体”)。

TAE130输入文档190A并产生分析。然后在一个称为公共分析系统(CAS)210的公共结构中表示所述原始文档190A和相应的分析。一般，CAS210是一个便于针对至少一个文档190A进行信息的建模、创建和检索的数据结构(例如见图11)。CAS210可以是定域的(localized)或者分布式的。另外，UIMA100支持多个CAS系统的协调。

一般而言(在UIMA100中使用的情形也是如此)，标注将一些元数据与原始文档190A中的区域相关联。在文档190A是文本文档的情况下，例如，标注将元数据(例如标签)与文档190A中的一个跨度的(span)文本相关联：直接或间接给出该跨度的起始和终止位置。

CAS210中的标注是独立的(standoff)，意思是，标注的维护与文本本身是相分离的。通常认为独立标注比内联文档标记(inlinedocument markup)更为灵活。但是，在UIMA100中，对于给定文档190A，标注不必是存储在CAS210中的信息的唯一类型。CAS210可以用来表示与文档190A的分析相关联的任何类别的元数据元素，而不管其是否明确地链接到原始文档190A的某个子部分。CAS210还允许对该链接进行多个定义，这对于图像、视频或者其它非文本形态的分析是有用的。一般，有一个CAS210与每一个文档190A相关联。

在图4A中提供了文档级分析的一个例子。在举例的工作流400中，标注途径包括多个相互连接的标注器，包括一个语言识别器410、一个标记器(tokenizer)420、一个语句分离标注器430、一个语音片断(POS，part-of-speech)标志器(tagger)440、一个有名实体(named entity)识别标注器、一个语法分析器(parser)460和一个模板填充标注器470。除了图4A所示的举例的标注器和步骤之外，或者代替它们，可以使用其它的非限制性的关系，这些关系图示于图5-7中。图8和图9提供了表示工作流生成(图8)和工作流验证(Workflow Verification)(图9)的各个方面的流程图。应当注意到，各种标注器410-470中，至少某些标注器的顺序可以与图4中所示的顺序不同。例如，在某些情况下，标记器420可以在语言识别器410之前。

但是，并不要求所有的标注器410-470都象图4A所示那样串行连接。例如，图4B图示了一个例子，其中，与语言识别器和其它标注器并行地设置有一个日期标注器415，其中，日期标注器215的输出直接送回CAS210。当系统吸收一个包括用拉丁字符写的日期的用某种语言例如汉字写的文档190A时，这种实施例是有用的。可以设置任何数量的并行标注器路径，每一条路径上可以有任何数量的标注器(例如，日期标注器415后面可以接串行连接的时间标注器)。另外，给定并行标注器路径的输出不一定直接送回CAS210，而可以返回给另一个标注器路径。

应当注意，与一个给定文档190A相关的可以有不止一个的CAS210，也就是，不同的TAE130可以使用不同的CAS210。作为一个例子，一个TAE130可以使用一个CAS210将一个文档190A翻译为不同的语言，同时另一个TAE130可以使用不同的CAS210提供同一文档190的摘要。或者，多个TAE130可以对同一个文档190A使用同一个CAS210。

在CAS210中表示的分析可以被视为元数据10的集合，当其通过相继的各分析级时，其得到丰富和/或精简(例如废弃不相关的数据)。在特定的分析级(分析阶段)，例如，CAS210可以包括一个深度语法分析(deep parse)。接收CAS210的有名实体探测器(450)可以考虑该深度语法分析来识别有名实体。有名实体可以被输入一个分析引擎130，后者基于多个文档190A(例如提及美国总统的文档190A，或者提及一个或者多个商业区的商业领导人的文档190A)产生摘要或者分类。

在目前的优选实施例中，CAS210用支持单一继承的等级类型系统提供通用的基于对象的文档表达。集成结构1000的一个例子示于图10A中。在图10A中，类型系统(Type System)1010包括各种子类型，比如在所提供的非限制性例子中，有标注1020、语音片断(POS)1030、语言标识1040和旅行计划1050。这些类型(或者子类型)1020、1030、1040和1050可以在适当的情况下进一步分解(例如，子类型语言标识1040的变种包括英语子类型1040A，英语子类型进一步包括US、UK和澳大利亚等)。一般，类型系统1010提供利用CAS210对文本文档进行分析的数据模型。

但是，CAS210不限于使用单一继承，图10B图示了一个用多个继承进行数据建模的例子。在这种情况下，结构不是一个继承树，而是一个有向非循环图。标准的技术，例如C++或者人工智能中使用的技术，可以用来对多重继承指定操作和说明语义(operational anddeclarative semantics)。

在无论哪种情况下(单一继承或者多重继承)，可能仅在寻找语句边界和类型时，才对举例的标注器感兴趣，例如，调用另一组标注器来对一个对话中的实际效果进行分类。

利用支持单一继承的等级类型系统的基于对象的表达包括数据创建、访问和系列化方法，它们用来进行有效的表达、访问，以及在TAE130之间、在TAE130和其它UIMA部件或者应用之间传输分析结果。可以对CAS210中的元素进行索引以便于快速访问。在C++和JAVA中已经用用于二进制的系列化方法，以及用XML格式(用于对付效率和互操作性之间的折衷)，实现了CAS210。CAS210与UIMA100的部件的关系的一个例子示于图11中。在图11中，除了CAS210之外，还示出了类型系统1110和索引库1120，还有迭代器(iterator)1125。一般，类型系统1110规定对工作流的限制，而不是标注器顺序本身，例如在图4A中，语言标识标注器410应当在语音片段(POS)标注器440之前。索引库1120提供指针库用于使得能够在文档190A中定位特定信息，比如通过规定当前文档190A中的日期或者专有名称的位置。另外还图示了UIMA部件1130、1140和1150，以及下面要讨论的分析结构代理(ASB)320。

II.B.集合级分析

最好，由应用170将文档聚集起来并组织为集合，比如图1所示的集合190。最好，UIMA100包括一个集合阅读器界面，它形成CPM150的一部分。集合阅读器的实现提供对集合元素190、集合元数据和元素元数据的访问。UIMA100的实现包括文档、集合和元数据库120，其与集合阅读器界面配合，管理多个集合及其元素。但是，那些希望管理自己的集合的应用170可以为那些需要访问集合数据的UIMA100部件提供集合阅读器的实现。

可以分析集合190以产生集合级分析结果。这些结果表示在集合190的所有或者部分文档190A子集上计算的聚集结论(aggregateinference)。应用170的分析整个集合190的部件是集合分析引擎(CAE)160。CAE160一般对集合的元素比如单个文档190A应用元素级，更具体地是文档级分析，然后在执行聚集计算(aggregate computation)时考虑所述元素分析。

集合级分析结果的例子包括这样的子集合：其中，元素包含特定的特征、带术语的变形和频率的术语表、分类、用于统计分类器的特征矢量、被提取的关系的数据库、标记的主索引以及其它探测到的实体。

作为对集合分析引擎160的支持，UIMA100包括集合处理管理器(CPM)部件150。该CPM150主要的任务是管理指定TAE130在库中可通过集合阅读器访问的每一个文档190A上的应用。作为到CPM150的输入，集合分析引擎160可以提供一个TAE130和一个集合阅读器(图中未示出)。CPM150应用TAE130，并对集合中每一个元素190返回由CAS210代表的分析。为了控制该过程，CPM150提供管理功能，包括失败报告、暂停和重新开始。

应应用的集合分析引擎160的请求，CPM150可以(可选地)配置为执行UIM应用方案的典型功能。UIM应用功能的非限制性的例子包括：过滤：基于元数据约束，确保只有特定的元素被处理；暂留：保存元素级分析；索引(index)：基于从分析抽取的元数据用指定的搜索引擎索引界面对文档进行索引；并行化：利用可用的计算资源，管理TAE130的多个实例的创建和执行，以同时处理多个文档。

II.C.语义搜索访问

这里所用的“语义搜索”的意思是基于文档级或者集合级分析发现的用标注表示的语义内容而定位文档的能力。为了支持语义搜索，UIMA100包括搜索引擎索引和查询界面。

索引界面的一个方面是支持标记的索引，以及标注尤其是交叉标注(cross-over annotation)。如果两个或者多个标注被链到文档的交叉区域，则它们被认为是相互交叉的。

查询界面的另一个方面支持：除了标记和标注的布尔组合之外，还建立在嵌套结构的标注和标记的基础上的查询。

II.D.结构化知识访问

当分析引擎执行其功能时，它们可以咨询广泛的机构化信息源180。为了增加可重复使用性和便于集成，UIMA100包括知识源适配器(KSA)接口140。

KSA140提供到根本不同的知识源180的统一访问层。它们以统一的方式管理在数据库、词典、知识库和其它结构化源180中编码的知识的发送所需的技术通信、表达语言和本体映射(ontology mapping)。在优选实施例中，到KSA的主接口使用以XML编码的知识交换格式(Knowledge Interchange Format(KIF))(这是一个非限制性的格式举例)提供作为实例化判定的结构化知识180。

KSA140架构的一个方面涉及支持KSA登记和搜索的KSA元数据和相关服务。这些服务包括有名本体(named ontology)的描述和登记。通常用它们所包括的概念和判定来描述本体。KSA140最好是自描述的，可以包括那些KSA能够实例化的登记本体相关的判定特征(predicate signature)，以及任何被咨询的知识源的指示，作为元数据。

最好，应用或者分析引擎开发者能够查阅人能够浏览的KSA目录服务，以搜索和查找将登记的本体的判定实例化的KSA140。该服务可以将一个句柄(handle)传送给网络服务或者可嵌入的KSA部件140。

III.架构部件概览

III.A.搜索引擎110

搜索引擎110负责索引和查询处理。搜索引擎110与搜索应用不同，搜索应用使用搜索引擎，会例如添加页排序和表达功能，以提供基本搜索应用。

UIMA100支持平衡文本分析的集成和搜索的应用的开发。除了执行基本布尔搜索能力外，这些应用可能要求搜索引擎提供两个高级功能，分别称为“跨度(Span)”和“视图(View)”。

跨度：语义实体比如事件、地点、人、化学品、部件等，可以用一系列标记在文本中表示，其中，每一个标记可以是一个或者多个字母数字字符的串。一般，一个标记(token)可以是一个数字、一个字母、一个音节、一个单词或者一个单词序列。TAE130在标记的跨度上产生标注。例如，“地点”类型的标注可以用来标注标记跨度″1313Mocking Bird Lane″，而“人”类型的标注可以用来标注标记跨度″BobSmith″。

图13提供了一个标注结构的例子，图示了具有不同标注类型的标记跨度的嵌套。在图13中，例如，图中每一个标记是一个单词。标注可以具有特征(即属性，TOKEN-PROPERTIES)。例如，“地点”类型的标注可以具有一个特征“所有者”，其值是该地点的财产的所有者。特征的值可以是有自己的特征的复杂型，例如，一个地点的所有者可以是具有特征“name＝John Doe”和“age＝50”的“人”类型的对象。

服从UIMA的搜索引擎110支持在标记跨度(“spans”)上对标注进行索引。目前有两种优选的方式可以完成这种索引，这将在下面加以说明。简要地说，可以在CAS210中以索引器110可以理解的某种格式(例如XML)插入内联标注(inline annotation)，或者所述索引器110能够理解在CAS210中找到的独立标注。

转换为内联标注：在这种方法中，应用170适应搜索引擎110的输入要求。例如，搜索引擎比如Juru能够索引XML文档，然后处理引用XML元素的查询。在下面的例子中，认为文档能够被索引：

<Event><Person>John</Person> went to<City>Paris</City>.</Event>

那么，如果输入一个针对包含城市(city)Paris的事件(Event)的查询，则该文档能够匹配该查询。

为了在UIMA100中使用XML认识的搜索引擎110，应用170采用TAE130产生的独立标注，将其编码为内联的，作为XML。CAS210最好定义一个方法来生成该XML表达。这种方法的好处是，能够用任何XML认识的搜索引擎110工作。

认识独立标注的搜索引擎：在这种方法中，搜索引擎的界面支持文档上的独立(非内联)标注的概念。

因此，TAE130的输出可以直接(或者几乎直接)馈送到搜索引擎110中，消除对中间表达比如SML的需要。作为例子，考虑文档片断及其标记的位置：

Washington  D. C. is the Capital of the United States

1           2  3  4  5   6       7  8   9      10

可以看到，在前述例子中，标记的位置定义(例如标记“Washington”，“D.″，“C.”)不同于图13所示。UIMA100的该优选实施例支持两种类型的标记位置定义。

假设搜索引擎110和TAE130在该文档的相同位置空间方面完全一致，则TAE130可以把信息表示为如下所示：

$City       1  3

$Country    9  10

但是，如果TAE130和搜索引擎110在如何计数白空间和如何对标点符号寻址等方面不一致，或者只是没有对齐，则不能正确地对标注$City和$Country进行索引。

因此，提供了一种等效的XML表达，其中：

<$City>Washington D.C.</City>is the capital of the<$Country>United States</$Country>。

XML语法分析比前述替代方案通常更耗费计算资源。最好，通过使用非确认语法分析器(non-validating parser)来缓解这种情况，所述非确认语法分析器考虑到这可能不是预处理功能的最有限制性的步骤。

进一步，考虑到XML，在某些实施例中，XML表达的一个缺点是TAE130可能产生重叠的标注。换句话说，标注没有正确地嵌套。但是，XML不会自然地表示重叠标注，可以利用另外的机制来提供解决方案。

同样，考虑字符串“airbag”。这是一个复合名词，对于该词，一个应用可能希望对来自区分“air”与“bag”的TAE130的标注进行索引。如果搜索引擎110只支持文档的一种标记化，其中“airbag″被解释为单个标记，但是TAE130使用不同的区别对待“air”和“bag″的标记化，则应用170不能分别索引对“air”的标注和对“bag”的标注，因为搜索引擎110的最小索引单位在这种情况下是“airbag”。

对于上述的文档片断例子，发送给搜索引擎110的标注将是：

$Token  0   9   $Token   11  12  $Token  13   14  $Token    16  17

$Token  19  21  $Token   23  29  $Token  31   32  $Token    34  36

$Token  38  43  $Token   45  50  $City   0    14  $Country  38  50

用字符偏移指出了″city″(城市)和″country″(国家)标注(这是它们在CAS210中的内部表达)。如果搜索引擎110最终选择用标记号来指定它们，应用或者搜索引擎110都能够执行这种转换。

应当注意到，一般，标记可以是单个字符，或者可以是字符的组合。

这种方法的部分好处在于没有必要进行从独立标注模型到内联标注模型的昂贵转换，然后再转换回来。同样，重叠标注也不会成为问题。

搜索引擎110、TAE130和一系列标注器1220、1221、1222之间的关系的一个实施例示于图12中。图中还示出了ASB320、用于应用170的用户接口(UT)170A和从TAS130接收输出的文本分析(TA)资源库130A。

图14描述了图12的在文档级和单词级工作的举例的标注器1220、1221和1222的操作。在此例子中，文档级语言识别器410后面跟着一个用于识别HTML标志的去标志器415，后接标记器420，后接POS标注器440，后接位置识别标志器445。

关系

图15描述了用于标记1510、1520、1530和跨度1550、1560和1570的倒排文件，图6的示意图提供了跨度的存在(跨度的分布，跨度的出现，span occurrence)的另一种表达。在图16中，一个存在(occurrence)1610被定义为具有一个起始位置和一个终止位置，或者一个起始位置和一个长度1630。一个跨度1650被定义为具有一个起始标记1660和一个终止标记1670，然后就位置对它们进一步进行说明。

图17、18和19提供了在TAE130执行的用以发现文档中的关系的预处理步骤中表示与跨度之间的关系的例子。在图17提供的例子中，标注了包含关系名为“抑制”的关系参数的跨度。在这个例子中，第一化合物被标识为“抑制者”，第二化合物被标识为“被抑制”，关系就是一种“抑制”。所述跨度的标注对应于具有参数角色(argument roles)“抑制者”和“被抑制”的项目，从而对跨度上的标注进行了索引。

在图18中提供了描述该过程的一个流程图。在图18中，第一步1810涉及发现关系文本，也就是，发现文档中表达了某种关系的文本范围。第二步1820发现参数文本，也就是发现文档中表达了每一个参数的文本范围。在步骤1830，对于每一个关系和参数确定跨度，在步骤1840对参数跨度进行排序，在步骤1850对关系跨度及其每一个参数跨度创建标注。在步骤1855为索引分配和添加标签，并且在步骤1860通过将参数标注按照指定顺序链接到关系标注从而建立关系。

图19提供了具有跨度索引的关系的图形表达。在图19中，一个标注索引1910包括一个关系索引1920，该关系索引1920与关系参数1930有关，关系参数1930包括文档标识1940，其中每一个文档190A包括由开始和结束位置描述的跨度1950。

定位和搜索

一般，一组标记位置是单调的。但是，基于前面的讨论，一组标记位置可以是毗邻的或者非毗邻的，一个标记或者一组标记可以由至少两个标注跨越。

标注类型可以是任何语义类型或者元值。这样，搜索引擎110可以响应包括标注、标记和与标注有关的标记中的至少一个的查询。

关系数据结构可以包含至少一个由按照参数顺序排序的参数构成的关系，其中，一个关系表示为相应的标注，其中，搜索引擎110可以还响应包括特定关系的查询，以搜索数据库120而返回具有该特定关系的至少一个文档。搜索引擎110还可以返回特定关系中的至少一个参数。搜索引擎110还可以返回多个有序的参数。至少一个参数可以包括链接到所述标注的参数标注。搜索引擎110还可以响应于查询返回至少一个该查询没有明确规定的参数。一个标注可以包括一个关系标识符，该关系标识符可以由至少一个参数构成。包括该关系标识符的一个参数可以，例如，包括至少一个其它的标注、一个标记、一个串、一个记录、一个元值、一个类别、一个关系、至少两个标记之间的关系、至少两个标注之间的关系。所述关系标识符还可以包括一个逻辑谓词(logic predicate，逻辑判定)。

类似地，由相应标注表达的关系数据结构(包括关系名和按照参数顺序排序的参数)可以出现在搜索引擎110查询中。这样的查询指定一个关系结构(或者其一部分)来搜索数据库120以返回至少一个具有该指定的关系的文档。搜索引擎110还能够返回该指定关系中的一个或者多个参数。当搜索引擎110返回一个或者多个有序的参数时，每一个参数可以包括一个链接到该标注的参数标注。注意，作为对查询的响应，搜索引擎110也可以返回至少一个该查询没有明确指定的参数。

一个关系的标注可以包括一个关系标识符，例如一个逻辑谓词(logic predicate，逻辑判定)。这样的标注还可以包括一个或者多个参数。一个参数可以，例如，包括至少一个其它的标注、一个标记、一个串、一个记录、一个元值、一个类别、一个关系、至少两个标记之间的关系、至少两个标注之间的关系。

视图

认识到不同的TAE130可以对同一文档产生不同的标记化，一个适应UIMA的搜索引擎110最好支持对相同文档进行不同的标记化，或者说不同的索引单元集合。这些不同的标记化可以导致不同的文档“视图(view)”。在图20中提供了基于或者说源自一个文档190A的不同标记化的视图的举例，其中，第一可选表达2010和第二可选表达2020能够导致多个视图，图中示为2050、2060、2070和2080。

一般，一个视图是一个文档190A与一个标记化的关联。这样，一个视图可以表示为文档190A标识符与标记化结果的配对。这样，就可以看出，不同的视图代表文档190A的不同的标记化。看图20A，如果TAE3扩展标记集合2的标记化，例如将单词分解为词干和词缀，则产生一个新的视图(视图3)。

图21用于说明利用布尔操作符210，用针对从单个源文档的不同标记化产生的不同文档视图的搜索表达式2110、2120、2130进行视图搜索的各个方面。

TAE130的操作最好不依据预先存在的视图或者应用170关于TAE130产生的内容的关联性作出的判断。UIMA100确保TAE130的开发可以独立于其要布置到其中的应用170。因此，最好应用170的任务就是创建视图。最好，如果两个TAE130在同一个文档190A上运行，并基于不同的标记化产生结果，这些结果不会合并到单个文档视图中。因此，应用170向搜索引擎110提供每一个TAE130的结果作为单独的视图。

在目前的优选实施例中，搜索引擎110被配置为吸收至少两个层次之一的视图。第一个层次是“浅理解”层次。在这个层次，搜索引擎110将一个文档190A的多个视图当作完全独立的实体，它们之间的关联之处只在于它们最终指向同一个文档文本。理想情况下，即使在该文档的多个视图与一个查询匹配的情况下，这样的搜索引擎在其结果列表中也只报告该文档190A一次。第二个层次是“深度理解”层次。在这个层次，搜索引擎110知晓多个视图，因此查询可以覆盖该文档190A的多个视图。例如，如果在查询“X AND Y”中，项目X出现在文档的视图1中，项目Y出现在同一文档的视图2中，则该文档190A会被该搜索引擎110返回。注意，在搜索引擎110的“浅理解”实施例中，同一个查询不会返回该文档。

UIMA100的一个特征是提供重叠标注的能力，这在传统的XML表达上是重大的改进。作为重叠标注(也可以称为交叉跨度(cross-overspans))的一个例子，短语″IBM data warehousing products″中，“双名词”(″double noun″)标注可以附加到所有相继的词对上：″IBMdata″，″data warehousing″和″warehousing products″。附加这种类型的标签例如在区分″storing data created by IBM″和″IBM productfor storing data″时很有用。

如上所述，最好有至少一个倒排文件系统用于存储标记(见图15)，以及至少一个倒排文件系统用于存储针对每一个视图的标注、包括各标注的出现(存在，occurrence)的列表以及针对各标注的每一个列出的出现(存在，occurrence)存储一个由多个标记位置构成的集合，其中，给定标记位置可以由至少一个标注跨越(见图13)。

显然，倒排文件系统与传统文件系统至少在单个文件如何被索引和访问方面不同。在传统的文件系统中，可能只是有每一个文件个体的列表，而在倒排文件系统中，存在一些内容或者元数据，比如标记，它们以某种方式与包含所述内容或者元数据的文件相关联。例如，在传统文件系统中，作为检索一个文件的索引，可能要从文件名开始。而在倒排文件系统中，可以从某些内容或者元数据开始，然后检索包含该内容或者元数据的文件(用内容而不是用文件名对文件进行索引)。

语义搜索引擎110可以响应包括至少两个谓词(判定，predicate)的逻辑组合的查询(其中，第一谓词属于第一视图，第二谓词属于第二视图)，并返回至少一个满足该谓词(判定)的逻辑组合的文档。

在本发明的该优选实施例中，标记化对应于并且源自例如至少一个纯文本文档、文档的语言翻译、文档的摘要、标记文档的纯文本变体、HTML文档和/或多媒体文档的纯文本变体，多媒体文档比如包含各种多媒体对象比如文本和图像，或者文本和图案，或者文本和音频，或者文本、图像和音频，或者图像和音频，等等。标记化可以基于具有不同数据类型的对象。标记化也可以源自文档的n字符列标记化。例如，图34描述了一个对文档文本进行三字符列标记化的例子。

应当注意，UIMA100不要求TAE130的多个实例产生文档的多个视图。相反，一个TAE130可以用来产生一个视图，然后通过选择一个或者多个不同的标注器(见图2、3和4)和/或重新安排标注器来对TAE进行重新配置，然后对文档再次进行处理以产生该文档的另一个视图。

III.B.文档库

库(store，存储器)120，或者文档库120，是文档和文档元数据的主要存储机制。最好(但不是限制)，库120利用网络喷泉(WebFountain，WF)模型，采用简单的允许将文档元数据作为与文档相关联的关键值对来存储和访问的API。

对于数据库120中文档的具体排序，数据库120中的文档190A最好被表示为倒排文件。

在一个应用要求保存文本分析引擎130(一种分析结构)的最终或者中间结果的情况下，该分析结构最好被存储在与文档190A相关联的关键值结构中，作为库120中的元数据。尽管也可以采用其它形式，该分析结构可以用二进制形式表示为BLOB，其可以被公共分析系统(CAS)210解释为部件。在某些实施例中，用于搜索引擎的索引的存储机制是文档库120。

III.C.分析引擎

这部分提供TAE130的各方面的一个概览，然后考虑用于TAE130的进一步的操作原则。

如前所述，图2图示了一个TAE130作为分析引擎200，其中提供了分析引擎200的主体结构(framework)的示意图。UIMA100规定了用于分析引擎200的接口。粗略地说就是“CAS输入”(″CAS in″)和“CAS输出”(″CAS out″)。还有其它用于过滤、管理和自描述功能的操作，但是主要接口将CAS210作为输入，并提供CAS210作为输出。

前面讨论过的图3图示了一个TAE130作为聚集分析引擎300，其中，提供了聚集分析引擎300的主体结构的一个示意图。在运行时，给聚集分析引擎300一个执行作为构成部分的文本分析引擎221、222和223的顺序。分析结构代理320确保每一个文本分析引擎221、222和223按照规定的顺序访问CAS210。

最好，实现图2所示接口的任何程序都可以用作UIMA100的实现中的分析引擎部件。但是作为UIMA100的一部分，分析引擎200可以包括支持简单分析引擎200和聚集分析引擎300在各种不同的系统中间件(middleware，中间设备)平台上的创建、编辑和灵活部署。下面更详细地讨论TAE130的各个方面。

文本分析引擎(TAE)130是负责发现和表达文本中的语义内容的部件。TAE130的任务可以是下述作为举例的活动：发现文档中的文本片断表示的语法和语义实体(例如语句、标题、段落、人物、地点、事件、时间、生物实体、管理、化学实体等)、发现文本中的关系；产生文本的摘要；将文本翻译成不同的语言；将文本按分类学分类。

最好，TAE130将一个文档190A作为输入，产生一个分析结构，该分析结构表示从文档的文本得来的语义信息。TAE130还可以从一个文档和一个初始分析结构开始，作为操作的结果，它对该初始分析结构进行修改。

TAE130一般是通过协调标注器220(可以可互换地称为“开采器”(挖掘器，miner))的集合来实现的。标注器220是具有各种不同职责的部件，利用原始文档190A和/或在先分析结果来发现和记录新的语义内容。标注器220最好但不必须是按照流水线结构组织的(例如见图4A、12和14)，每一个标注器对文档190A进行操作，以及对流水线中在前标注器220的结果进行操作。这种方案在图12中进行了说明。在图14中图示了用来识别文档中的位置的一系列标注器220的例子。但是，如前所述，也可以实现标注器220的并行安排，如图4B所示。

在高的层次，认为TAE130是负责发现新文本中的语义内容的部件。TAE130可以用在应用的预处理阶段，以例如发现文集中的语义实体(表示地点、事件、任务以及/或其它类似信息类型)。在查询时，应用170可以分析该查询以判断该查询是在寻找特定时间在特定地点发生的某些事件的相关信息。最好，应用170然后查询搜索引擎110以发送包含事件加上给定地点和时间的文档。为了有效地执行这个查询，应用170在搜索引擎110中对预处理阶段发现的语义实体(在本例子中尤其是事件)进行索引。

最好，标注器220被开发为没有控制和通信依赖性，否则，就难以为多个应用170所理解和重复使用。

TAE130使得标注器逻辑的隔离成为可能。因此，TAE130可以被视为在其中配置和部署标注器220的容器。最好，TAE130的作用是：协调标注器220之间的控制和通信流；为标注器220提供到文本分析资源(例如词典)的统一接口；以及，公布用于应用170的访问标注器220集合的组合功能的单一接口。

TAE130规定一个功能接口。也就是，TAE130接受一个文档190A(可选地，接受一个初始分析结构)作为输入，并产生一个分析结构，该分析结构表示从该文档推出的语义内容。TAE130本身不规定到该功能的技术接口。可以通过各种手段提供到TAE130的访问。

尽管在一个应用170中可以直接包括TAE130(位于同一地点)，但是TAE130也可以被部署为分布式服务(例如网络服务)。TAE服务将一个TAE130包起来，公开一个到TAE130的技术接口。部署的TAE服务听取处理文档的请求，将那些文档送到TAE130，获取TAE130产生的分析结构，然后将该分析结构返回给调用者。

最好，UIMA100为若干公共分布式对象技术和协议(例如SOAP，MQSeries，WebSphere，Mail(邮件))提供TAE服务的实现。

UIMA100最好还提供名片业务(naming service)，利用它登记TAE服务，从而客户能够定位所需的服务。

通常，有两种类型的TAE130：简单的200和聚集的300。简单TAE200是一个标注器220的容器，它将标注器与控制和通信细节隔离开，并为标注器220提供到文本分析资源的统一接口。聚集TAE300将其工作委派给一个或者多个其它的TAE，这些其它的TAE可以是简单TAE200或者是聚集TAE300。聚集TAE300使用分析结构代理(ASB)320来管理各组成TAE221、222和223之间的通信。

公共分析系统210

公共分析系统210用作所有标注器220用来访问和修改分析结构的公共设施。这样，CAS210使得能够在标注器220之间进行协调，并有助于在不同的应用170和不同类型的架构(例如松散耦接以及紧密耦接的架构)中重复使用标注器220。再看图14，CAS210可以被视为通过图11所示的类型系统1110来约束标注器410-415也就是工作流的操作。

CAS210主要提供数据建模、数据创建和数据检索功能。数据建模最好定义一个类型的树等级结构，如图10A所示(还可见图5)。所述类型具有称为特征的属性和特性(图6)。在优选实施例中，有少量的内置(预定义)类型，比如整型(Int)、浮点型(float)和串。数据模型是用与其它标注器共用的标注器描述词定义的。在图22中图示了一个数据建模的例子。该举例的数据模型2200包括一组类型，包括：顶2210、标注2220、INT2230、POS2240、标记2250、语句2260、介词2270、名词2280以及其它更多的类型2290。该数据模型2200可以被视为是继承结构(比如图10A所示的举例的单一继承结构)和部件列表(比如图7所示的举例的部件列表)的组合。

CAS210数据结构可以被称为“特征结构(Feature Structure)”。为了创建一个特征结构，必须规定类型(见图5)。标注(以及其它特征结构)被存储在索引中。可以通过迭代器1125通过索引访问特征结构(可再次参见图11)。

图33A和33B图示了可用于说明CAS210的操作的举例的伪码。该伪码表示在创建动词型(verb-type)特征结构(feature structure)时类型系统和特征结构的使用，以及它们向CAS210索引中的插入。

CAS210可被视为将基于表达对象的数据结构实现为摘要数据类型的方法(例如以Java或者C++实现为一个类程(类，Class))的集合。最好，CAS210的设计主要基于TAE130的特征-特性结构，该结构提供用户定义的对象、实现灵活性的特性和值、实现效率的静态型等级结构，以及通过使用一个或者多个迭代器1125访问存储的数据的方法(见图11)。

通过CAS210实现的摘要数据模型为UIMA100提供但不限于以下特征：平台独立性(即，独立于编程语言说明性地定义类型系统)；性能优势(例如，当通过公共数据模型耦接用不同编程语言写的标注器210时)；用标注器210的输入/输出说明(包括允许类型检查和错误探测并支持作为服务模型的标注器(TAE)的说明性规范)进行流编辑；通过语义索引、搜索和检索(即语义类型是说明性的，不是基于关键字的)支持第三代搜索方法。

CAS210为标注器220提供有效建立和搜索分析结构的工具。分析结构是主要由描述原始文档190A的文本的子序列的元数据构成的数据结构。分析结构中元数据的类型的一个例子是标注。标注是一个具有自己的特性的对象，用来标注一个文本序列。

标注的类型有任意多。例如，标注可以标记文本序列在文档结构中的角色(例如单词、语句、段落等)，或者描述它们的语法角色(例如名词、名词短语、动词、形容词等)。标注的数量或者应用基本上没有限制。其它的例子包括对文本的片断进行标注，以将它们标识为专有名称、地点、军事目标、时间、事件、设备、条件、时间条件、管理、生物关系、家庭关系或者其它重要的或者感兴趣的项目。

一般，标注器220的功能是分析文本以及现存的分析结构，以发现被设计为用来识别标注的标注集合的新实例，从而把这些标注添加到分析结构中，分析结构用于输入以由其它标注器220进一步处理。例如，上面结合图17讨论过的特定“抑制”关系可以由一个标注器220发现，该标注器被特别地设计为发现这种类型的关系，在这个例子中，是通过识别出短语″may reduce the effectiveness of”(该短语意味着处于该短语前后的两个化合物名称之间的抑制关系)来进行这种发现。这个特定标注器220可以识别为“抑制”关系的类似性质的其它短语可以是″reduces the effects of”(见图24)和″suppresses the operationof”。

除了标注之外，CAS210可以存储原始文档文本以及可以由标注器220产生的相关文档(例如原始文档的翻译和/或摘要)。最好，CAS210包括便于按照建立的格式比如XML输出分析结构的不同方面(例如一组标注)的扩展。

简言之，“TAE描述”是一个描述TAE130的对象。在优选实施例中，TAE描述词是一个标识TAE描述的XML文档。TAE描述包含启动和使用TAE所需的全部信息。但是，TAE描述本身不规定如何部署TAE130(例如是紧密耦接还是松散耦接)。

TAE描述可以存在不同的完成度状态。例如，TAE130的开发者可以提供定义配置参数但是未对任何参数设值的TAE描述。应用开发者可以将该TAE描述拿来为所述参数编程性地赋值。

公共分析系统210(CAS)细节。CAS210是TAE130的定义和存储文本标注的部分。CAS API既由应用使用又由标注器220使用，以创建和访问标注。CAS API最好包括至少三个不同的接口。一个类型系统控制新类型的创建并提供有关类型(继承)之间和类型与特征之间的关系的信息。在图5中提供了类型定义的一个非限制性的例子。一个结构访问接口处理新结构的创建以及值的访问和设置。一个结构查询接口处理已有结构的检索。下面提供有关CAS210的子部件的更多的细节。

类型系统提供对系统已知的实体的分类，类似于基于对象的编程中的类别等级结构。对应于类别、特征的类型对应于成员变量。最好，类型系统接口提供如下功能：通过提供一个用于新类型的名称并规定该新类型在等级结构中应该占据的位置来添加一个新类型；通过提供一个新特征名称并给出该特征应该具备的类型以及值类型来添加一个新特征；查询已有类型和特征以及它们之间的关系，比如“哪个(哪些)类型继承这个类型”。

最好，类型系统提供少量的内置类型。如上所述，基本类型是整型(INT)、浮点型和串型。在Java实现中，它们分别对应于Java整型、浮点型和串型。还支持标注和基本数据类型的阵列。内置类型在结构访问接口中具有专用的API支持。

结构访问接口允许创建新结构，以及访问和设置已有结构的值。最好，其提供以下功能：创建给定类型的新结构、获取和设置给定结构的特征的值；以及针对内置类型的访问方法。可以参看图6，其中对域给出了举例的特征定义，每一个特征具有一个范围。

在某些实施例中，对特征结构的分类索引的创建和维护可能要求对特征结构的更新操作(commit operation)。在更新中，系统将对特征结构的改变传播给适当的索引。

结构查询接口允许列出满足特定条件的结构(迭代)。该接口可以由标注器220以及应用170使用，以访问TAE130产生的结果。最好，该接口是直观的，便于TAE130在不同的应用170中重复使用。

在CAS210的结构上建构迭代存在不同的技术。首先，在过滤迭代(filtered iteration)中，构建对特征结构的约束或者过滤器。最好，它们用不等式约束条件来约束整型和浮点型值，用等式约束串型值，约束结构的类型，在路径下嵌入基本约束，用布尔运算符AND、OR和NOT组合约束条件。

当迭代中的所有元素满足约束条件时，可以部署新的迭代器1125。对于标注器可以存在迭代器1125的特例，其中，最好在某些类型的标注(例如语句)上迭代，并且，对于迭代中的每一元素，列出在嵌入标注的跨度中包含的另一类型的所有标注(例如标记)。嵌入结构迭代器可以通过过滤迭代器构建。为此目的提供专用的API既方便又可以实现优化的实现。

图33C是基于CAS210的数据访问的一个伪码例子，示出了在标记上使用迭代。

一般，TAE130的底层设计认可三个基本原则：鼓励并实现部件重复使用；支持将算法开发者和系统与部署细节隔离开的不同开发角色；通过隔离低层系统中间件API支持部署选项的灵活变化。下面讨论这三个原则的实现的各方面。

鼓励和实现部件的重复使用

通过鼓励和实现部件的重复使用，实现所需的效率，并提供组间协作。TAE130的主体结构有三个特性针对这个目标。这些特性是：递归结构；数据驱动；以及自描述。下面分别说明。

递归结构：

如图2所示的基本分析引擎200由一个标注器220和一个CAS210构成。标注器220是实现分析逻辑(例如标记化、语法分析、实体探测)的对象。标注器220从CAS210读取原始文档内容和元数据。该标注器220然后计算并将新的元数据写入CAS210。类似于嵌套编程模型，聚集分析引擎300是一个递归结构的例子，确保部件能够相互组合而得到重复使用，同时隔离它们的内部结构。

数据驱动：

最好，分析引擎200的处理模型是严格数据驱动的。在优选实施例中，这意味着标注器220的分析逻辑可以只基于输入的内容，而不基于可能与其组合的特定分析引擎200或者标注器220可能嵌在其中的控制序列。这确保了：只要满足标注器的输入要求，分析引擎可以在不同的聚集结构和不同的控制环境中成功地得到重复使用。

图3的分析定序器310是负责动态确定接收对CAS210的访问的下一个分析引擎221、222和223的主体结构中的一个部件。分析定序器310不同于分析结构代理320，后者的职责是将CAS210送到文本分析引擎221、222和223中的合适的一个，无论它是哪一个，也无论其位于何处。分析定序器310的控制逻辑最好与嵌在标注器220中的分析逻辑是分离的，与分析结构代理320关于确保和/或优化CAS210传输的关切也无关。这种功能的分离允许实现不同分析定序器310的即插即用。分析定序器310能够实现到复杂的规划算法的说明性指定静态流上的简单迭代。分析定序器310的实施例可以限于分析引擎221、222和223之间的线性流，但是在更高级的应用中，可以实现动态的、自适应的定序。因此，将多少控制说明置入说明性表达中，对于这些高级要求在分析定序器310中实现多少，是与应用相关的(也与其它因素相关)。

自描述：

为了确保技术上的可重复使用性，最好确保分析引擎221、222和223可以容易地组合而构成聚集并在不同的控制序列中重复使用。但是，对于在广泛的开发者当中提供重复使用的能力并使这种重复使用有效来说，这可能并不足够。为了增进可重复使用性，分析引擎220的开发者能够发现在功能方面哪些分析引擎221、222和223可用。

最好，用XML说明每一个分析引擎200的数据模型，然后在运行时在CAS210中动态地实现。在UIMA100中，分析引擎221、222和223将它们的输入要求和相对于该说明的数据模型的输出规范公开，所述信息用于在分析引擎目录服务中登记所述分析引擎221、222和223。该服务最好包括面向人的接口，允许应用开发者浏览和/或搜索满足其需要的分析引擎。

支持不同的开发角色

在UIMA100中标识并考虑了不同的开发角色。其中包括了支持不同的开发者技巧集合的独立接口集。

例如，语言技术研究人员，例如专攻多语言机器翻译的人员，可能不是经过充分训练的软件工程师，也不是灵活和无缝部署所需的系统技术的精通者。UIMA100的一个方面提供了在鲁棒的和可缩放的系统架构中有效地部署他们的工作。

又例如，具有关于如何组合和协调各种部件的想法的研究人员自己可能不是算法开发者或者系统工程师，然而仍然需要通过组合现有的部件来迅速地创建和验证他的想法。

另外，在聚集系统中将分析引擎221、222和223部署为分布式的、高度可用的服务或者部署为在同一地的对象，也需要另外的技巧。

因此，确定了特定的开发角色。UIMA100因此可以利用支持不同技巧集(skill set)比如前述技巧集的独立的接口集合。下面对此作一详述。

标注器开发者：

标注器开发者角色致力于开发核心算法：从统计语言识别器到基于规则的有名实体探测器，到文档分类器。

主体结构设计确保标注器开发者不需要针对聚集系统行为或者系统问题(比如互操作性、恢复、远程通信、分布式部署等)来开发代码。相反，该主体结构提供的目标是致力于算法逻辑和结果的逻辑表达。

该目标是这样达到的：利用分析引擎200的主体结构，并要求标注器开发者只需要理解三个接口，即：标注器接口，标注器上下文接口，以及CAS接口。最好，标注器开发者执行下述步骤：实现标注器接口；对分析算法编码，用CAS接口读取输入并将结果和标注器上下文接口写入访问资源；写分析引擎描述词；以及，调用分析引擎工厂(Analysis Engine Factory)。

为了将分析算法嵌入到主体结构中，标注器开发者实现所述标注器接口。最好，该接口是简单的并且只要求实现两个方法：一个用于初始化，一个用于分析文档。

标注器开发者只通过CAS210访问输入数据和登记分析结果。如前所述，CAS210可以包含原始文档(分析对象)，加上以前运行过的任何分析引擎221、222、223贡献的元数据。元数据可以包括对原始文档的元素的标注。输入到分析引擎220的CAS210可以驻留在内存中，被远程管理或者由其它部件共享。

最好，通过标注器上下文接口访问标注器需要咨询的所有外部资源，比如词典。因此数据的确切物理表现形式由开发者确定，就象关于是否和如何缓存资源数据的决定也由开发者作出一样。

在一个优选实施例中，标注器开发者完成表示输入要求、输出规范和外部资源依赖性的XML描述词。在给出标注器对象和描述词的条件下，主体结构的分析引擎工厂返回一个完整的分析引擎220。

分析引擎组装器：

分析引擎组装器通过对部件分析引擎进行说明性协调来创建聚集分析引擎。设计目标是：允许组装器不用写代码就能够建立聚集引擎(aggregate engine)。

分析引擎组装器考虑在功能方面可用的引擎，并说明性地(declaratively)描述流的约束条件。这些约束条件是与被选中的部件引擎的标识符一道从聚集引擎的XML描述词中获取的。组装器将所述描述词输入主体结构的分析引擎工厂，从而建立和返回聚集分析引擎。

分析引擎部署器：

分析引擎部署器决定分析引擎及其所需的资源如何在特定硬件和系统中间件(middleware，中间设备)上部署。

UIMA100最好不提供其自己的关于如何部署部件的说明，也不托管特定类型的中间件或者中间件产品的使用。相反，UIMA100为部署器提供了选择满足其需要的中间件的灵活性。

隔离低层次系统中间件

人类语言技术(HLT，Human Language Technologies)应用可以与其它类型的应用共享各种要求。例如，它们可能需要可缩放能力、安全性和事务处理。现有的中间件比如应用服务器能够满足这些需要中的许多。另一方面，HLT应用可能需要具有小的占用区(footprint)以便能够部署到台式计算机或者PDA中，或者它们可能需要能够嵌入到使用自己的中间件的其它应用中。

UIMA100的一个设计目标是支持分析引擎221、222、223在任何类型的中间件上的部署，并从这些考虑出发隔离标注器开发者和分析引擎组装器。这是通过使用服务包装器(Service Wrapper)和分析结构代理(Analysis Structgure Broker)320实现的。分析引擎接口规定输入和输出要通过CAS210完成，但是它不规定如何在部件分析引擎之间传输CAS210。服务包装器实现特定部署所需的CAS串行化(serialization)和解串行化(de-serialization)。在一个聚集分析引擎300内，可以使用不同的服务包装器来部署部件。分析结构代理320是在这些部件之间传输CAS210而不管它们如何部署的部件。

CAS210可以被视为是松散地耦接或者紧密地耦接的。松散耦接的CAS210代表分布在多个存储器上的类型系统，这种情况可以例如在UIMA100的网络化应用中碰到。在这种情况下，标注器，比如标注器410到470，在多个存储器中工作。紧密耦接的CAS210代表位于一个存储器(或者一台机器)中的被定义的类型系统，其中，标注器，比如标注器410-470，共享同一个存储器。

为了支持新类型的中间件，最好开发新的服务包装器和对分析结构代理320的扩展并插入到主体结构中。分析引擎200本身不需要作任何形式的修改。

例如，已经实现了在网络服务和报文排队(message queuing)基础结构(infrastructure)顶部的服务包装器和分析结构代理320。每一种实现涉及具体部署场景的不同方面和特征。一般，网络服务包括那些通过交换XML消息(message)进行通信的应用。

一般，UIMA100将用户接口(UI)当作应用专用部件。应用如何接受输入、如何传送结果或者与用户对话都由应用170确定。

IV.系统接口

下面描述UIMA100的顶层部件之间的各种接口。图23提供了类似于图1的视图。图23还包括UIMA100接口的各个方面，它们在图中被一起图示为文本情报系统108(text intelligence system)。

在图24中提供了应用170和搜索引擎110之间的接口115的更详细的视图。图中还示出了其它的接口以及接口所承载的数据流。例如，在应用170和文档库120之间有一个接口125，在应用170和TAE130之间有一个接口135，在应用170和知识访问(结构化信息)180之间有一个接口185，在应用170和目录服务105(包括知识目录服务106和文本分析目录服务107)之间有一个接口175。

提供了特定的条件来帮助描述接口115。例如，视图支持多重标记化，而跨度(spans)被用来在视图内标注范围。基于跨度的例子包括寻找“标题”(title)域包含“抑制”关系的文档的查询。一个作为举例的结果是包含″Ibuprofen reduces the effects of aspirin on vasculardilation.″的文档190A。在优选实施例中，可以使用各种查询语言来定义基于跨度的查询。最好，应用170可以在预处理过程中或者运行时(查询时)使用搜索引擎110。

在预处理时，应用170可以通过接口125利用文本情报系统108从文档源120中检索文档，然后将它们通过接口135传送给一个或者多个TAE130。TAE130将结果返回到分析结构中，该分析结构是这样的形式：对原始文本中标记的跨度的标注，以及/或其它聚集结构(例如，候选词汇表项目，总结，分类)。使用这些结果，应用170可以选择将所发现的实体的全部或者部分加入到搜索引擎110的索引中，从而在查询时这些实体容易被访问。

搜索引擎110通过接口115向应用170提供识别视图的手段，并且应用170通过接口115将实体以规定的格式传送给搜索引擎110用于索引。为了支持文本分析和检索的强大集成，UIMA100期望搜索引擎110提供对跨度上的标注进行索引的能力。例如，考虑一个语义实体″$SUSPresident″，搜索引擎110的索引接口允许应用170在一个标记跨度比如″John Quincy Adams″上索引语义实体″$US President″。

查询时，应用170使用搜索引擎110的查询接口115来规定布尔查询。为了支持文本分析和搜索的强大集成，UIMA100期望搜索引擎110提供跨度上的查询语言，所述接口使得应用170能够执行查询。例如，一个查询可以寻找标题(一个被标注的跨度)包含美国总统(USPresident)(一个被标注的跨度)的所有文档，或者寻找这样的所有文档：文档的摘要(一个被标注的跨度)包含“抑制”关系(一个被标注的跨度)，并且该“抑制”关系包含一个包括文本“in vitro”(在实验室中的试验)的限定词(一个被标注的跨度)。

现在看TAE130和搜索引擎110之间的接口135。最好，应用170向TAE130提供一个或者多个文档。最好，TAE130不使用搜索引擎110来定位文档。TAE130产生应用170要索引的标注，但是TAE130不决定索引什么，也不直接与应用170的索引功能通信。

最好，应用170和TAE130之间的关系是这样的：无论哪一个都不影响另一个的状态。应用170最好包括一个编程模型和管理调用TAE130的结果之间的状态的控制器(operator)。

任何共享/可更新状态最好由UIM基础结构管理，而不是由TAE130直接管理。例如，一条合适的规则可以是“在TAE和应用之间不存在共享的全局变量”。

V.二级搜索

最好，由利用二级评估过程或者模型的搜索技术来辅助UIMA100。下面以举例的方式描述该过程，但不应视为对本发明的限制。

在某些实施例中，评估模型采用传统的倒排索引，其中，每一个索引项目与一个记录列表(posting list)相关联。该列表包含包含该索引项目的集合中每一个文档的入口。所述入口包含文档的独有的积极标识符(positive identifier)DID以及可应用的记分模型所要求的任何其它信息，比如项目在文档中出现的次数、各次出现之间的偏移等。最好，记录列表按照文档标识符的升序排列。

从编程的角度，为了支持对这样的倒排索引的复杂查询，认为最好使用面向对象的方法。利用这种方法，每一个索引项目与一个能够在其记录列表上顺序迭代的基本迭代器1125对象(一个“流阅读器(stream reader)”对象)相关。该迭代器1125另外能够跳到记录列表中的给定入口。具体地，提供了一种方法next(id)，它返回第一个DID＞id(标识)的记录元素(posting element)。如果没有这样的文档，则项目迭代器(term iterator)1125返回一个特殊的记录元素，该记录元素具有大于索引中所有现有DID的标识符LastID。

布尔和其它操作符(或者谓词)与基本迭代器1125构成的复合迭代器相关联。例如，由下述关系定义用于操作符A(OR)B的方法：

(A OR B).next(id)＝min(A.next(id)，B.next(id))。

WAND操作符

这里所公开的二级方法利用为方便起见称为WAND的布尔判定(Boolean predicate)。WAND表示弱AND(Weak(AND))或者加权与(Weighted(AND))。WAND将一系列布尔变量X₁、X₂、......X_k、一系列相关正权重w₁、w₂、......w_k和阈值θ作为参数。作为定义，如果

$>>>\Sigma >>l>\le >i>\le >k>\; >>x>i>>>w>i>>\ge >\theta >,>->->>(>1>)>>>>$

则(WAND)(X₁，w₁，...X_k，w_k，θ)为真，

其中，xi是Xi的指示变量，也就是，如果X_i为真则x_i＝1，否则xi＝0。

可以看到，WAND可被用于通过下述方式实现AND和OR：

AND(X₁，X₂，...X_k)≡WAND(X₁，1，X₂，1，...X_k，1，k)，

以及

OR(X₁，X₂，...X_k)≡WAND(X₁，1，X₂，1，...X_k，1，1)。

注意，可用其它约定来表达WAND，例如，阈值可以作为第一参数。

这样，通过改变阈值，WAND可以从基本上为OR函数变为基本上为AND函数。注意，通过将条件(1)替换为要求所述xi的任意一个单调递增函数大于所述阈值，或者，特别地，要求任意单调布尔公式为真，可以将所述WAND普遍化。

图25描述了模式(pattern)与WAND阈值之间的关系，其中，特定模式被分配给一个权重2510，第二模式被分配给一个所需权重2520，直到最后一个模式被分配给一个权重2530。赋值2510、2520和2530一起被用来产生一个权重阈值2550。图28中图示了使用WAND技术2800的总结。在图28中，第一步涉及初始化2810，然后评估模式的加权和2820，然后确定该和是否大于所述阈值2830。如果和低于该阈值，则在步骤2850指针前进，在步骤2820再次评估模式的加权和。如果该和大于所述阈值，则该方法在步骤2840进行一个详细的评估，并在步骤2850判断该值是否大于堆中的最小值(如下所述，一个大小为n的堆跟踪最前的n个结果)。若否，则控制返回到步骤2880，否则将结果在步骤2860插入所述堆，在步骤2870修改所述阈值和/或权重，控制返回步骤2880。

一般，WAND在文档上迭代。在某些方面，WAND可以被视为一个过程调用，尽管它还应被视为WF迭代器的具有合适的方法和状态的子集(subclass)。因此，WAND具有一个表示当前文档的“游标(Cursor)”，以及其它属性。

如图25所示，WAND的参数是模式(pattern)和权重。模式pat1，pat2，......是实现为迭代器1125的WF支持的典型模式。最好，每一个模式具有相关的正权重w，该权重在迭代过程中不一定相同。还有一个权重阈值w0。

在操作时，WAND(w0，pat1，w1，pat2，w2，...)返回这样的下一文档(相对于当前游标)：其匹配足够多的pat1，pat2，......，从而匹配的模式的权重和大于w0。

基于前述讨论，可以知道，在pati代表文档190A的内容的任意布尔函数的条件下，返回的文档满足足够多的pat1，pat2，...，从而被满足的函数pat1，pat2，...上的权重和大于w0。

权重和不一定是文档的分数(score)。最好，权重和只是用作一个修剪机制(pruning mechanism)。实际的文档分数由排序例程(ranking routine)计算，计算时将所有归一化因素以及其它类似的属性考虑在内。最好，和的使用是任意的，可以用任何增函数代替。

假设修剪权重(pruning weights)和分数是一样的，考虑下述例子：

假设一个查询是：<cat dog fight>

            Cat pays $3

        Dog pays $2

        Fights pays $4

        Cat near dog pays $10

        Cat near fights pays $14

        Dog near fights pays $12

需要最顶100个文档。如果在某些点存在100个文档的分数＞＝30，则在WAND(30，<cat>，3，<dog>，2，<fights>，4，LA(<cat>，<dog>)，10，LA(<cat>，<fights>)，14，LA(<dog>，<fights>)，12)时进行一个调用，其中，LA(X，Y)实现X NEAR Y(NEAR：接近)。

在实现方面，WAND的使用有点儿类似于AND的实现。在某些实施例中，“加速”(zipping)的规则是这样的：

整个WAND迭代器1125具有一个游标CUR_DOC表示当前匹配。希望使CUR_DOC前进。

每一个模式板(pattern pad)具有一个相关的next_doc_i，表示其在一个＞CUR_DOC的位置匹配的地方。

对所有next_doc_i排序，使得next_doc_i_1＜＝next_doc_i_2＜＝next_doc_i_3＜＝...。

令k为使得w_i_1+w_i_2+...+w_i_k＞w_0的最小下标。则认为可以将CUR_DOC前进到next_doc_i_k，并将所有其它游标前进到＞＝CUR_DOC的位置。现在，如果在CUR_DOC可以获得足够大的权重，则返回CUR_DOC，否则对位置进行重新排序。

为了理解此操作，假设模式pat_i在next_doc_i之后匹配每一个单个的文档。即使在这种乐观假设下，在next_doc_i_k之前也没有文档具有足够的权重。

可以观察到以下结论：

1.常规的AND(X，Y，Z)与WAND(3，X，1，Y，1，Z，I)完全相同。两个迭代器1125将通过完全相同的位置列表进行内部加速(zip)，进行完全相同的跳跃(jump)；

2.常规的OR(X，Y，Z)与WAND(l，X，1，Y，I，Z，1)完全相同，两个迭代器将通过完全相同的位置列表进行内部加速(zip)，进行完全相同的跳跃(jump)；

3.如果使用过滤器表达式F(它是每一个文档必须匹配的表达式)，则可以实现为WAND(大数+阈值，F，大数，pat1，w1，...)。

可以用各种技术来设置修剪表达式，因为实际的分数不只是一个和。这些技术最好将TF加上归一化考虑进去。

打分

一个文档的最终分数涉及基于文档与查询的文本的相似性的文本分数(textual score)，以及其它与查询无关的因素，比如网页的连通性，科学论文的引用次数，电子商务项目的存货清单等等。为了简化说明，假设不存在这样的与查询无关的因素。还假设存在加法打分模型(additive scoring model)。也就是，每一个文档的文本分数是通过将属于该文档的所有查询项目的贡献相加得到的。这样，一个文档d对于查询q的文本分数为：，

$>>Score>>(>d>,>q>)>>=>>\Sigma >>t>\in >q>\cap >d>\; >>\alpha >t>>w>>(>t>,>d>)>>>>$

例如，对于tf×idf打分模型，a_t是t在查询中出现的次数乘以t在索引中的文档频率倒数(inverse document frequency，idf)的函数，w(t，d)是t在d中的项目频率(term frequency，tf)除以文档长度|d|的函数。另外，假设每一个项目与其对任何文档分数的最大贡献的上限UB_t相关：

UB_t≥α_t max(w(t，d1)，(w(t，d2)，...)，

这样，通过将出现在一个文档中的所有查询项目的上限加起来，该文档的与查询相关的分数的上限可以被确定为：

$>>UB>>(>d>,>q>)>>=>>\Sigma >>t>\in >q>\cap >d>\; >>UB>t>>\ge >Score>>(>d>,>q>)>>.>>>$

注意，查询项目可以是简单项目(也就是，在索引中存储有静态记录列表的项目)或者复杂项目比如短语(在查询评估过程中对其动态建立记录列表)。所述模型不区分简单或者复杂项目，每一个项目提供一个上限，并且为了实现的目的，每一个项目提供一个记录迭代器(posting iterator)1125。在这些条件下，初步评分包括对于每一文档d评估：

WAND(X₁，UB₁，X₂，UB₂，...，X_k，UB_k，θ)

其中，X_i是在文档d中存在查询项目i的指示变量，在算法中，阈值θ按照如下所述变化。如果WAND评估为真，则文档d进行一个完全评估。阈值θ最好由所述算法基于到当前为止找到的最前n个结果中最小的分数m而动态设置，其中，n是被请求的文档的数量。

所述阈值越大，跳过的文档越多，从而对于越少的文档计算完全分数(full score)。很容易看到，如果所述贡献上限是精确的，则一个文档的最终分数不大于其初步上限。因此，θ＝m的WAND跳过的所有文档不会被使用同样的加法打分模型(additive scoring model)的其它方案放在最上的打分文档集合中。

但是，如后所述，(a)在某些情况下，每一个项目的贡献只有近似的上限，(b)分数可能涉及与查询无关的因素，(c)为了执行更少的完全评估，可能优选更高的阈值。因此，在实践中，最好设置为θ＝F*m，其中F是一个阈值因子，选择该因子以平衡集合的正负误差。为了有效地实现这一点，最好将一个WAND迭代器置于与查询项目相关联的多个迭代器的顶部。下面对此进行详细说明。

一般，前述方法不限于加法打分，WAND定义中的任意单调函数都可以使用。也就是，唯一的限制是，最好，一个查询项目的存在不降低一个文档的总分数。这对于所有的典型信息检索(InformationRetrieval，IR)系统都是真的。

实现WAND迭代器

WAND判定可以用来迭代地寻找用于完全评估的候选文档。WAND迭代器提供一种迅速地查找满足该判定的文档的方法。

最好，通过调用在图26中用伪码描述的init()函数来对WAND迭代器进行初始化。该方法接收查询项目的阵列作为输入，然后将要考虑的当前文档(curDoc)置为零。该方法还将当前记录posting[t]初始化为记录列表中的第一记录元素。在调用图26中的init()函数后，算法反复调用WAND的next()方法来获取下一个候选文档进行完全评估。所述next()函数将阈值θ作为输入，返回近似分数大于θ的下一个文档。近似分数低于该阈值的文档被跳过。图27图示了用于实现next()函数的非限制性的伪码。

在执行过程中，WAND迭代器保持两个不变量：

1.所有DID≤curDoe的文档已经被当作候选文档；

2.对于任意项目t，任何包含t且DID＜posting[t].DID的文档已经被当作候选文档。

注意，init()函数建立了这些不变量。WAND迭代器反复地使单个项目迭代器前进，直到找到要返回的候选文档。这可以以自然的方式进行：使所有的迭代器一起前进到各自的下一个文档，按照DID顺序近似取得候选文档的分数，并与阈值相比较。但是，这种方法会非常没有效率，会需要若干盘进行输入输出和相关的计算。这里所公开的算法得到了优化以使next()操作和近似计算的次数最少。

这是这样完成的：首先，将查询项目按照它们当前记录的DID的升序排列。然后，该方法计算一个“枢纽项目(pivot term)，也就是在所述排序中，在其之前(包括其本身)的所有项目的上限的累加和大于给定阈值的第一个项目(见图27中第5行及其以下)。枢纽DID(pivot DID)是可以成为候选文档的最小DID。如果没有这样的项目(意味着所有项目的上限的和小于该阈值)，则迭代器停止运算，返回常数NoMoreDocs(已没有文档)。

为了理解枢纽位置的重要性，可以考虑init()之后next()的第一次调用。即使在当前记录之后的所有文档中存在所有项目，在枢纽文档之前也没有文档具有足够的总贡献而使其高于所述阈值。枢纽变量被设置为对应于枢纽项目的当前记录(posting)的DID。如果所述枢纽小于或等于所考虑的最后一个文档(curDoc)的DID，则WAND拾起枢纽项目之前的项目，将使迭代器前进而越过curDoc，原因是curDoc之前的所有文档已经被考虑了(通过不变量1)，因此系统应当接下来考虑具有更大的DID的文档。注意，这保留了不变量2。如果枢纽大于curDoc，则判断对枢纽文档的贡献的和是否大于所述阈值。有两种情况：如果枢纽项目之前的所有项目的当前记录DID等于枢纽文档，则该枢纽文档包含一组查询项目(该组查询项目的累加上限大于所述阈值)，这样，next()将curDoc设置为该枢纽，并将该文档作为候选文档返回以进行完全评估。另外，该枢纽文档可以也可以不包含所有在前项目。也就是，它可以也可以不具有足够的贡献，WAND选择这些项目中的一个并使其迭代器前进到一个大于或等于所述枢纽的位置。

注意，next()函数保持不变量1：所有DID小于或等于curDoc的文档已经被当作候选文档。对于DID小于枢纽文档的DID的另一个文档来说，不可能成为有效的候选文档，因为按照定义，枢纽文档是DID序列中累加上限超过所述阈值的第一个项目。这样，所有DID小于枢纽文档的DID的文档只包含在枢纽项目之前的项目，因此它们的分数的上限严格小于所述阈值。由此得出结论：next()保持了该不变量，因为curDoc只在成功的情况下(也就是找到在该序列中处于第一的新的有效的候选文档)才前进到枢纽文档。

最好，next()函数调用三个相关函数，sort()，findPivotTerm()和pickTerm()。Sort()函数按照当前DID的非降序顺序对项目进行排序。注意，没有必要在任何阶段都对项目进行完全排序，因为在对sort()的相继调用之间，只有一个项目使其迭代器前进。因此，通过使用适当的数据结构，通过修改仅仅一个项目的位置来维护排序的序列。第二个函数，findPivotTerm()，将排序的序列中满足下述条件的第一个项目返回：该项目之前(包括其本身)的所有项目的累加上限超过给定阈值。第三个函数pickTerm()接收一组项目，并选择要使其迭代器前进的项目。一种优选的选择战略是选择会产生最大的预期跳跃的项目。使项目迭代器尽可能多地前进会减少要考虑的文档的数量，从而减少要检索的记录的数量。可以注意到，这种策略对于被完全评估的文档的集合没有影响。分数上限大于所述阈值的任何文档在任何战略下都会被评估。因此，尽管一个好的pickTerm()策略会提高性能，但是不会影响精度。在一个实施例中，pickTerm()选择具有最大文档频率倒数的项目(假定了最少见的项目会产生最大的跳跃)。也可以使用其它pickTerm()策略。

在这方面，可以进一步参考共同受让的美国临时专利申请No.60/＿＿＿，该申请在本申请的优先权日递交，题为″Pivot Join：Aruntime operator for text search″，发明人为K.Beyer，R.Lyle，S.Rajagopalan和E.Shekita，该文献在此全部引为参考。例如，如上所述，单调布尔公式可以不是显式的，而可以由一个单调黑箱评估给出。

设置WAND阈值

假设对于给定查询用户希望检索最前n个打分文档。该算法保持一个大小为n的堆，来跟踪最前n个结果。在调用WAND迭代器的init()函数后，该算法调用next()函数以接收一个新的候选文档。当WAND迭代器返回一个新的候选文档时，用系统的打分模型对该文档进行完全评估，结果得到该文档的精确评分。如果所述堆不是满的，则该候选文档被插入所述堆。如果该堆是满的，并且新的分数大于该堆中的最小分数，则新文档被插入该堆，取代具有所述最小分数的文档。

被传递给WAND迭代器的阈值是基于当前堆中所有文档的最低分数设置的。请回顾前文所述，该阈值确定对于一个被当作候选文档、要被送到完全评估步骤的文档来说必须被超过的一个下限。

基于查询类型来设置初始阈值。例如，对于一个OR查询，或者对于一个自由文本查询(free-text query)，将初始阈值设为零。包含至少一个查询项目的任何文档的近似分数都会超过这个阈值从而被返回作为候选文档。一旦堆被填满就会设置更实际的阈值，只有那些具有充分多的项目以产生高分数的文档才会被完全评估。对于AND查询，初始阈值可以设为所有项目上限的和。只有包含所有查询项目的文档才会具有足够高的近似分数从而被当作候选文档。

初始阈值也可以用来适应强制项目(这些项目以“+”为先导)。这样的项目的上限可以被设置为某个极大的值H，其比所有其它项目上限的和大很多。通过将初始阈值设置为H，则只有那些包含该强制项目的文档才会被返回而作为候选文档。如果查询包含k个强制项目，则初始阈值被设置为kH。

该阈值另外还能够被用来加速评估过程：使该阈值在选择用于进行完全评估的候选文档方面更加“机会主义”。在这种情况下，最好将该阈值设置为一个大于堆中的最小分数的值。通过增加该阈值，算法能够在近似步骤中动态地修剪文档，从而对更少的(但是具有更高的可能性的)完全候选文档进行完全评估。动态修剪的代价是有错过某些高分数文档的风险，从而不能保证精确性。但是，在许多情况下，这是一种非常有效的技术。例如，管理花费在给定查询上的最多时间的系统能够在时限就要被超过时增加阈值，从而实施更大的跳跃，从而只对非常有可能进入最后结果列表的文档进行完全评估。试验的结果表明了动态修剪如何影响效率，以及如何影响用这种技术进行查询评估的有效性。

计算项目上限

WAND迭代器要求每一个查询项目t与一个其对任何文档分数的贡献的上限UB_t相关联。在前面说过，文档分数的上限是通过将该文档包含的所有项目的上限相加而计算出来的。因此，很清楚，如果项目上限是精确的，也就是，t，UB_t≥α_tmax_d w(t，d)，则一个文档的分数的上限也是精确的，也就是大于其最终分数。在这种情况下，可以保证：假设该算法在任何阶段都把该阈值设置为到当前位置最小的文档分数，则二级处理会返回正确的排序和精确的文档分数。

对于简单项目找出真实的上限是直截了当的。这样的项目与显式存储在索引中的记录列表直接关联。为了找出一个上限，首先遍历该项目的记录列表，对于每一条目，计算该项目对对应于该条目的文档的分数的贡献。然后将该上限设置为所有记录元素上最大的贡献。这个上限被存储到所述索引中，作为所述项目的属性之一。

但是，为了避免假正误差(false positive error)，即使对于简单项目，也必须特别注意上限的估计。另外，对于复杂查询项目，比如短语或者相邻对(proximity pair)，最好评估项目上限，因为它们的记录列表是在查询评估过程中动态产生的。

在下面，描述用于简单项目的上限估计的一种替代的方法，以及用于估计复杂项目的上限的方案。对于简单项目，项目t的上限被近似为UB_t＝Ca_t。前面说过，a_t是由该查询中的项目idf和项目频率确定的。C＞1是一个对所有项目统一使用的常数。该评估忽略了通常影响一个特定项目对文档的分数的贡献的其它因素。这些因素包括项目在文档中的频率、出现处的上下文(例如在文档标题中)、文档长度等等。

这种评估的好处是其简单性。代价是计算出的候选文档的上限可能低于文档的真实分数，从而导致假负误差(false negative error)。这样的误差可能导致不正确的最终排序，因为最前的打分文档可能通不过初步评估步骤，从而不被完全评估。但是，注意，这种假负误差只会在堆满之后出现，并且是在阈值被设置为大值的情况下。

可以针对给定的文档集合对参数C进行微调，以在假正误差和假负误差之间实现平衡。C越大，预期会有更多的假正误差，系统效率会降低。C越小，会有更多的假负误差产生，从而降低系统的有效性。试验数据表明，在不削弱系统的有效性的前提下，可以将C设置为相对较小的值。

评估复杂项目的上限

如前所述，基于文档频率倒数(idf)评估一个查询项目的上限。简单项目的kdf容易从其记录列表的长度来确定。复杂项目的idf没有明确存储在索引中而最好要进行评估，因为它们的记录列表是在查询评估过程中动态建立的。下面描述一种评估两种复杂项目类型的idf的方法。这些方法可以扩展到其它类型的复杂项目。

短语

短语是通常被放在引号中的一个查询项目序列，例如″JohnQuincy Adams″。仅当一个文档包含该短语中的所有项目并且这些项目的顺序与它们在短语查询中出现的顺序相同时，该文档才满足该查询。注意，为了支持动态短语评估，单个项目的记录也包括项目在文档中的偏移量。另外，短语评估需要在索引中存储结束字(stop-word)。

对于每一个短语，在WAND之外建立一个迭代器。在WAND内部，由于短语通常少见，将短语当作“必须出现”的项目。也就是，仅检索包含所述查询短语的文档。前面说过，该方法通过将上限设置为一个极大的值H来处理强制项目，而不管它们的idf。另外，该阈值还被初始化到H。这样，仅包含该短语的候选文档会通过详细评估步骤。

词汇亲密度(Lexical affinities)

词汇亲密度(LA)是指找到的项目在小尺寸的窗口中相互紧密靠近。LA项目的记录迭代器(posting iterator)将两个LA项目作为输入，仅仅返回包含紧密靠近的两个项目的文档。为了评估LA(t₁，t₂)的文档频率，利用这样的事实：LA的记录列表是其中的单个项目的记录列表的子序列。对其项目的目前已经被遍历的部分记录列表中LA的出现次数进行计数，并外推到整个记录列表。

更具体地，将LA的文档频率初始化到df₀(LA)＝min(df(t₁)，df(t₂))，并在遍历另外的k个文档后反复更新。令p(t_i)为项目t_i的记录列表，并令p′(t_i)为其当前已被遍历的部分记录列表。令#(LA|p′(t_i))为在p′(t_i)中包含LA的文档的数量。则可以用外推法估计t_i的整个记录列表中包含LA的文档的数量：

$>>\#>>(>LA>|>P>>(>>t>i>>)>>)>>=>>>\#>>(>LA>|>>p>\prime >>>(>>t>i>>)>>)>>>>|>>p>\prime >>>(>>t>i>>)>>|>>>>(>|>>p>\prime >>>(>>t>i>>)>>|>)>>>>$

可以得出，在阶段n，LA的文档频率的更新规则为：

$>>d>>f>n>>>(>LA>)>>=>min>[>>df>>n>->1>>>>(>LA>)>>,>>>\#>>(>LA>|>p>>(>>t>1>>)>>+>\#>>(>LA>|>p>>(>>t>2>>)>>)>>)>>>2>>]>>>$

收敛速度取决于项目记录列表的长度。已经发现，仅仅在几次迭代之后，LA的文档频率估计就迅速收敛。

结果

下面是为评估当前优选的二级查询评估过程而进行的试验的结果的描述。对于这些试验，使用了一个Java搜索引擎。对一个文档集合进行了索引，该文档集合包含10GB的数据，169万个HTML页面。既进行了短查询(short query)又进行了长查询(long query)。查询是从集合中的主题构建的。对于短查询的构建使用了主题标题(平均每个查询2.46个单词)，对于长查询的构建，将标题与主题的描述结合起来(平均每个查询7.0个单词)。另外，结果集的大小(堆的大小)被用作一个变量。堆越大，就需要越多的评估来获得结果集。

也使独立参数C变化，该参数就是乘以查询项目的上限和以得到文档分数上限的常数。前面说过，将被传递到WAND迭代器的阈值参数与文档的分数上限进行比较。仅当上限大于给定阈值时，文档才被完全评估。因此，C支配了性能和精度之间的折衷。C越小，被完全评估的文档数量越小，代价是精度降低。反之，精度越高，则文档数量越大。出于现实的原因，不改变C而将C固定为一个特定的值，可以改变乘以真实阈值的阈值因数F并将其传递到WAND迭代器。因数C与F是倒数关系，因此改变F等效于改变C但是效果相反。也就是，F值越大，完全评估的量越小，但是精度有损失。当将F设置为零时，传递到WAND的阈值就总是零，从而包含至少一个查询项目的所有文档都被当作候选文档并被完全评估。当将F设为无穷大时，直到堆满之后(当θ＝0时)算法才会对文档进行完全评估。其余的文档就不会通过该阈值，因为θ×F会大于所有查询项目上限的和。

当改变所述阈值因数的值时，可以测量下述参数：(a)平均每次查询的完全评估次数。这是影响搜索性能的主要参数。显然，进行的完全评估越多，系统就越慢。(b)用10(P@10)精度和中值平均精度(MAP，mean average precision)测量的搜索精度。(c)下述两个结果集之间的差：从无假负误差的运行(基本运行)得到的搜索结果集，以及从有负误差的运行(修剪运行)得到的结果集。可以注意到，在两个运行中，文档得到相同的分数，因为完全评估器(full evaluator)是共同的并且由它赋予最终分数。这样，在基本集合B和修剪集合P中，公共文档的相对顺序得到保持。因此，如果每一个运行返回k个文档，则对于某些小于或等于k的j来说，修剪运行返回的最前j个文档将在基本集合中并且是相同的相对顺序。

用两种方法测量两个结果集合中的差别。首先，使用下述公式给出的相对差测量：

$>>>>|>B>/>P>|>>>|>B>|>>>=>>>k>->j>>k>>.>>>$

其次，由于不是所有的文档都同等重要，使用MRR(平均倒数排序，Mean Reciprocal Rank)加权。任何在基本集合B中并且在排序中的位置i、但是不是修剪集合P的成员的文档对MRR距离的贡献为1/i。这里的思想是修剪集合中没有的文档对所述距离的贡献与它们在排序中的位置成反比关系。用整个集合的MRR权重对MRR距离进行归一化：

$>>MRR>>(>B>,>P>)>>=>>sup>>\Sigma >>i>=>1>,>>d>i>>\in >B>->P>>ksup>>1>/>i>>sup>>\Sigma >>i>=>1>>ksup>>1>/>i>>>.>>>$

有效性和效率

在第一个试验中，作为阈值参数F的函数，测量完全评估的次数。将F设置为零时返回包含至少一个查询项目的所有文档。然后将返回的候选文档的集合全部进行完全评估。这个技术用来建立一个基本运行，得到的结果是，平均而言，每一个长查询评估335500个文档，每一个短查询评估135000个文档。图29分别对于长查询和短查询图示了作为阈值因数F的函数的完全评估的数量。图29表明，对于长查询，当F增加时，评估数量迅速地收敛到所需的文档数量(堆的大小)。另外，测量了作为F的函数的平均查询时间，并且图中表明与完全评估的数量高度相关(对于所有的运行，相关度高于0.98)。例如，对于长查询、100的堆大小以及F＝0，基本运行的每个查询的平均时间为8.41秒。

对于大的F值，这个时间降为0.4秒。注意，基本运行是一个极端情况，其中没有进行修剪。在不发生负误差的情况下，事实上可以将阈值设置为更大的值。基于这些试验，可以看到，约为0.8的阈值大大削减了完全评估的数量而对结果列表没有影响。

图30图示了对于用MRR距离量度测量的相同的运行，修剪结果和基本结果之间的差异。对于F的小值，距离是零，因为没有假负误差。增加F会增加假负误差的数量，从而增加所述距离。

图31图示了对于堆大小为1000的短查询和长查询，用P@10和MAP测量的相同的运行的精度。可以看到，尽管随着修剪的增加MAP下降(正如预计的)，只有在进行非常显著的修剪后，对于短查询才有适度的下降。对于长查询，P@10中的变化可以忽略。例如，当F＝6.0时，对于长查询和短查询，P@10根本不受影响，此时完全评估的数量小于1700(相对于初始填充所述堆所需的1000只多出700个评估)，MPP约为0.5。

即使在激进修剪的情况下，最前的结果仍具有高精度的原因可以由下述事实加以解释：高的阈值使得WAND本质上就如AND一样起作用，只返回包含全部查询项目的文档。然后对这些文档进行完全评估，这些文档很有可能获得高分数。由于分数不受二级方法的影响，并且由于这些文档实际上是相关的并且在任何情况下都得到高分数，所以P@10不受影响。另一方面，将查全率(recall)也考虑在内，由于有许多遗漏，MAP受到不利的影响。

这样，可以假定，通过仅明确地评估包含所有查询项目的文档，系统能够实现最前结果集的高精度。通过向WAND传递一个等于所有查询项目上限的和的阈值(为了方便起见，称为AllTerms方法)，能够容易地指令WAND仅返回这样的文档。但这种方法本身证明了对于P@10，由于对于许多查询只考虑了太少的文档，查全率从而MAP下降。在第一次“激进”的过程没有返回足够多的结果的情况下，可以采用一个修改的战略(以下称为TwoPass方法)，允许对项目记录(term posting)进行第二次过程。特别地，将阈值首先设置为所有项目上限的和，然后，如果累积的文档数量小于所需的结果数量，则减小该阈值，将其设置为在文档集合中至少出现一次的所有查询项目的最大上限，重新调用评估过程。

表1图示了使用不同阈值因数的WAND的结果，并与AllTerms和TwoPass运行进行比较。对于F＝0，WAND返回包含至少一个查询项目的所有文档。对于这个运行，由于没有假负误差，精度是最大的。对于F＝1.0，完全评估的数量对于长查询降低了20倍，对于短查询降低了10倍，仍然没有假负误差，因此精度没有降低。对于F＝2.0，评估数量进一步降低4倍，代价是精度降低。

可以看到，对于短查询和长查询，与WAND相比，AllTerms大大改进了P@10，但MAP大大降低。对于只对最前的结果的精度感兴趣而忽略查全率的系统，AllTerms是合理的和有效的选择。对于P@10和MAP，TwoPass运行都获得非凡的结果，对于第二次过程，在执行时间方面稍有代价，但在大多数情况下这是可以忽略的，因为从第一次过程开始，项目记录多数情况下仍然被缓存在主存储器中。在任何情况下，这些结果都表明，总体上，本发明的方法，具体地，所述WAND迭代器，是通用的、有弹性的。通过改变阈值，所述操作符的“强度”可以被控制为从OR变到AND。

            ShortQ             LongQWANDP@10MAP#EvalP@10MAP#Eval(F＝0)0.3680.24136,2250.4020.241335,500(F＝1.0)0.3680.2410,1200.4020.24115,992(F＝2.0)0.3620.232,3830.4040.2343,599AllTerms0.4780.187443.60.5370.142147TwoPass0.3680.24922,2470.4040.24629,932

表1：与基本WAND相比，AllTerms和TwoPass的P@10和MAP(其中，ShortQ：短查询；LongQ：长查询)

前述讨论表明，使用一次一文档的方法(a document-at-a-time)和利用对于第一级修剪使用WAND操作符的二级查询评估方法，可以产生显著的效率增益，而在精度和查全率方面没有损失。另外，如果可以容忍产生某种程度的精度损失，则可以进一步提高所述增益。

如前所述，对于文档中项目的出现最好提供至少一个迭代器，并且最好至少有一个迭代器用于指出哪些文档满足特定特性。WAND应用至少一个用于分别满足布尔判定X_1 X_2，...，的文档的迭代器，并且所述WAND操作符建立一个迭代器用于指出哪些文档满足所述WAND判定。

所述WAND操作符保持一个当前文档变量，该变量表示还不知道不满足该WAND判定的第一可能文档，如果WAND判定在一个当前文档变量处不被满足，可以应用一个过程来指出多个迭代器中哪一个迭代器要前进。

VI.举例的实施方式及思考

图32图示了UIMA100的一个举例的实施方式。其中，图示了其应用在一个用于发现药物的生命科学应用170环境中。这个非限制性的例子描述了许多部件和接口中UIMA100凭借来进行工作的一部分。

在图示的实施例中，有一个语言资源3200部件，包含该应用170专用的资源(例如MEDLINE、UMLS、生物医学数据/试验台)。还提供了各种相关的载入器工具3210，以及多个应用支持部件3220。

UIMA100的配备包括了核心文本分析标注器和后处理分析器标注器220，它们当中的某些是举例的生命科学应用170专用的，比如MEDTAKMI语义分析器以及生物关系分析器。核心文本分析功能与Jtalent文本分析器TAE130一起工作，文本数据库120可以用DB2^TM、一个DB2^TM载入器和访问模块实现。文本搜索引擎110可以基于JURU(一个用Java写的全文本搜索库)。

考虑图32时可以理解，如何协调各个部件以解决问题(或者建立应用)是UIMA100的一个重要方面。除了定义一组部件之外，UIMA100最好包括一组约束条件，所述约束条件确定这些部件的可能的协调关系以建立有效的应用。

文档库120可以被视为一个具有接口的部件，该接口使得文档和文档元数据可以在盘上被存储和管理。例如，在一个实施例中，一个约束条件规定主应用逻辑负责确定TAE130是否应该将文档元数据写到库120中以用于恢复或者对TAE结果的后处理访问的目的，这是一个架构控制约束条件。除了其它约束之外，这个约束条件用来确保TAE130不会在应用不知道的情况下任意地决定将数据写到库中，因为那样对应用的总体性能的影响很大。UIMA100建议应用开发者要尽可能知晓应用的总体运行要求(例如性能和可恢复性之间的折衷)从而应当控制它。这接下来要求扩展TAE的接口以允许应用170传递其要求：要求TAE130将中间结果写到库120中。

在其它的实施例中，可以对软件部件和用户要求进行建模，以自动地产生标注(标注器或者TAE)序列。这种方法使得用户不必具有部件的接口级细节的知识，只需关注应用的功能要求。另外，自动定序可以帮助用户作出关于如何节约成本地从已有部件建立新应用的决定，还能帮助维护已经建立的应用。

自动定序在执行过程中标注流的恢复和控制中也起作用。具体地，流执行器可以用关于失败的细节调用定序器，请求仍然能够在新的未预见到的情况下完成该流的替代的序列。重新定序允许应用对运行时错误(这是UIM的分布式部署的特殊倾向)是透明的。

部件间通信方法的选择要考虑的问题包括灵活性、性能、可缩放性以及对标准的顺从性。

因此，作为其技术接口说明的一部分，UIMA100最好列出用于部件相互作用的通信方法。意图使UIMA100按照该架构的各种部件的要求使用现有分布计算技术的应用。

一般，UIMA100支持松散耦接(也就是分布式)架构，其中，部件可以存在于不同的地址空间中，在多个单独的机器上，在不同的操作环境中，通过面向服务的方法通信。考虑到灵活性和可缩放性，这种方法是优选的。但是，紧密耦接架构也在本发明的范围内，UIMA100也支持紧密耦接系统架构模型。

例如，各种部件可能要求进行紧密耦接通信以确保高级别的性能。一个例子是TAE130，其中，当处理文档流时，标注器220一般串联工作。

通过TAE130的操作，分析结构被频繁地访问和更新。尤其对于嵌入式文本分析应用(需要快速的响应)而言，或者由于用户等待结果而在查询时进行分析的情况下，更新和到下一个标注器的传输就很关键。在这些情况下，标注器220之间在存储器内分析结构上的紧密耦接通信就可以用来实现高级别的、可以预见的性能。

松散耦接系统的另一个考虑是开发范例。同样，考虑TAE130，它可以包括许多标注器220，每一个标注器各自为阵地发展，各具有自己针对分析结构的先决条件。理想情况下，UIMA100支持标注器220的开发，以便开发者的工作能够独立于部件通信方法，然后将标注器置入不同的容器中，这些容器在理想情况下适应必要的开发或者部署环境。

无论UIMA100的部件是以松散耦接还是以紧密耦接的方式通信，它们的控制独立性是一个明显的和重要的问题。理想情况下，UIMA接口应当限制部件逻辑以外部控制模式为基础。这个原则的意思是，一个部件应当被写成能够在非对称控制环境中毫无问题地运行。其运行不管其要嵌入的应用170的特定流是什么样的。

换句话说，UIMA100最好是数据驱动的。部件可能会由于输入的数据不满足特定的前置条件而不能处理该输入，因为部件不能依赖于特定的处理流。以数据驱动为中心通常还使得能够对UIMA100实现高度分布式的基于代理(agent-based)的方法。

基于前述，可以知道，UIMA100提供了一种模块化的文本信息系统，其包括应用接口，应用接口中至少包括一个文档库接口125链接到至少一个文档库120。该文档库接口125接收至少一个数据库说明和至少一个数据源，并提供至少一个数据库查询命令。UIMA100还提供所述至少一个分析引擎接口135连接到所述至少一个文本分析引擎130。该分析引擎接口135接收至少一个文档集合的至少一个文档集合说明，并提供文本分析引擎分析结果。通过应用接口，应用170规定如何填充所述至少一个文档库120，并指定一个应用逻辑用于选择至少一个文档集合并指定用所述至少一个文本分析引擎130处理所选择的文档集合。还规定对分析结果进行处理，以及至少一个用户接口。所述应用说明是通过设置至少一个参数进行的，所述至少一个参数包括所述至少一个文本分析引擎所使用的公共摘要数据格式的说明。还包括至少一个搜索引擎接口115，用于接收至少一个搜索引擎110的至少一个搜索引擎标识以及至少一个搜索引擎说明。所述搜索引擎接口115还接收至少一个搜索引擎查询结果。

本领域的普通技术人员知道，这里的教导只是说明性的，因此不能视为限制本发明。也就是，如上所述，UIMA100可以与各种信息源一起使用，这里并没有讨论这些信息源中的许多信息源。例如，一个文档可以既包括文本又包括静态或者动态的图像，既可以为文本又可以为图像数据提供标注器。

这样，可以理解，前述说明只是举例和非限制性的，只是本发明目前想到的用于实施本发明的最佳的方法和设备的一个完整的提供信息的说明。但是，对于本领域的普通技术人员来说，在阅读了前述说明以及附图和权利要求之后，可以显而易见地得到各种各样的修改和适应性变化。但是，对本发明的教导的所有这样的修改都仍然在本发明的范围之内。另外，尽管这里所描述的方法和设备具有一定的特异性，但本发明的实现的特异性可大可小，这取决于用户所需。另外，本发明的某些特征可以单独使用而获得有益效果，不需要对应地使用其它特征。因此，前述说明只应视为对本发明的原理的说明，而不是对本发明的限制，因为本发明的范围是由权利要求限定的。