语义编程语言和语言对象模型的制作方法

专利名称：：语义编程语言和语言对象模型的制作方法
技术领域：
：本发明涉及用于对自然语言的语义进行建模的方法。更为具体地，本发明涉及适合于对自然语言的语义进行建模用于软件应用程序开发的一组类型。
背景技术：
：自然语言是由人类创造的语言(与计算机语言或其它人工语言不同)，它包括全部习惯用语、话语或文本的假设和暗示。在自然语言处理的环境中，命令和控制系统处理自然语言话语或文本，并试图识别和解释该话语或文本，以导出可使用的解释。传统上，用于提供自然语言命令和控制的一种技术涉及对预先编码的命令的静态识别。例如，商业上可获得的语音一文本程序允许用户使用简单的命令发起预先编码的操作，例如savefile(保存文件)。然而，除非使用了正确的命令，否则这种程序一般不能处理这些命令。换言之，编码成识别命令savefile(保存文件)的应用程序不能正确地理解storefile(存储文件)。类似地，问/答类型的应用程序一般包括预先编码的短语或术语，以便便于搜索和检索类型的功能。然而，为了成功，传统的实施方式要求在话语或文本中使用特殊的搜索项，因此不能充分地考虑人类语言的丰富性。对自然语言应用程序编程极其困难。一般地，编程者知道如何以计算机语言编码，但是几乎没有图解语句结构和/或进行语言分析的经验。而且，将为英语编码的自然语言软件应用程序扩展到对其它语言起作用不仅要求对软件应用程序重新编码，还要求对任何相关的语言分析引擎重新编码。这使得对自然语言应用程序进行编程变得极其困难，并可能代价非常高。
发明内容在一个方面中，提供一种用于对自然语言软件应用程序进行编程的软件开发工具。该软件开发工具包括编程语言和编译器。该编程语言具有用于便于自然语言编程的一组编程构造。该编译器适用于采用包含所述一组编程构造的实例的软件程序以及产生软件应用程序。在一个可选的方面中，提供一种创建允许自然语言的软件应用程序的方法。从用于便于自然语言编程的一组编程构造中创建程序。该程序描述了依赖于自然语言输入的软件应用程序中的特征。该程序被编译成软件应用程序。在另一方面中，语言对象模型适用于对自然语言的语义元素进行建模。语言对象模型包括语言表达式的一组类型和类，设计这些类型来对语言表达式建模。在一个实施例中，该组类型中的每个类型对应于话语的语言上有含义的元素。在另一个方面中，计算机可读介质存储用于对自然语言建模的计算机可读数据结构。一组类型适用于将类表示为抽象对象。类表示分类化的语言表达式，可对应于自然语言话语的语义上有意义的部分。在另一个方面中，一种用于产生自然语言输入的语义解释的框架包括解释器和一组类型。该解释器适用于作为客户端应用程序和一个或多个分析引擎之间的中介，用以产生对客户端应用程序有效的自然语言输入的解释。该组类型适用于定义解释器与所述一个或多个分析引擎之间的交互。在另一个方面中，提供了用于将自然语言输入的解释例示成客户端应用程序的自然语言特征的框架。用与客户端应用程序相关联的说明模式来初始化解释器。解释器适用于接收自然语言输入，并与一个或多个自然语言分析引擎通信，以产生自然语言输入的解释。解释器适用于在客户端应用程序中例示出一个或多个解释。在另一个方面中，提供一种用于对计算机上的自然语言输入的语义进行建模的词汇语义结构。选择一组词汇语义类别来对自然语言输入的内容建模。一种方法将自然语言输入的内容关联到该组词汇语义类别中的一个或多个类别。在不同的实施例中，词汇语义结构跨语言、跨语言类别、跨应用程序、以及跨适用于产生某种类型的语法类别的系统，将自然语言输入规格化。在另一个方面中，提供一种用于创建允许自然语言的软件应用程序的方法。从用于便于自然语言编程的一组编程构造中创建程序。该程序描述了依赖于自然语言输入的软件应用程序中的特征。该程序被编译成软件应用程序。在另一个方面中，提供一种用于开发允许自然语言的软件应用程序的系统。可解析的类型定义语言元素的抽象表示和自然语言输入的语言元素之间的相互关系。解析语义定义用于解析允许自然语言的软件应用程序中的可解析的类型的实例的有效性的程序规则。在另一个方面中，提供一种用于确定允许自然语言的软件程序中的可解析的类型的实例的有效性的方法。汇编了列出自然语言输入的推荐的解释的推荐解释列表。每个推荐的解释具有一个或多个命令，以及映射到可解析的类型的非命令元素。与每个推荐的解释相关联的实例的有效性在允许自然语言的软件应用程序中确定。图1是可实施本发明的实施例的计算系统环境的示意图。图2是根据本发明的实施例的自然语言系统的简化框图。图3是图2的分析引擎与虚框示出的语言对象模型的简化框图。图4是根据本发明的实施例的执行发送邮件命令的处理的简化流程图。图5是根据本发明的实施例的类型解析的简化流程图。图6是根据本发明的实施例的命令解析的简化流程图。图7是根据本发明的实施例的构架解析的简化流程图。图8是根据本发明的实施例的约束子句解析的简化流程图。图9是根据本发明的实施例的实体解析的简化流程图。图10是根据本发明的实施例的智能系统的简化框图。图11是根据本发明的实施例的词汇语义结构的简化概念框图。具体实施例方式A.综述本发明是用于产生自然语言应用程序的语言对象模型(LOM)、语义框架、以及语义编程语言(SPL)。LOM与所使用的自然语言或所涉及的应用程序域(domain)无关地对语义话语进行建模。语义框架包括作为自然语言分析引擎和客户端应用程序之间的中介的运行时间(runtime)组件(解释器)，以及定义了系统的所有组件之间的交互作用的性质的一组类型。SPL提供编程框架，用于与LOM和适用于对LOM起作用的自然语言分析引擎进行接口。SPL还可用于与其它语言对象模型接口。除了若干子过程和数据结构之外，本发明包括全过程和架构。为了更佳地理解本发明，介绍可用于本发明的一个示例性的环境。然而，应理解也可在各种其它系统和环境中使用本发明。B.示例性操作环境图1说明了可实施本发明的适用的计算系统环境100的例子。计算系统环境100仅仅是适用的计算环境的一个例子，不是对本发明的使用和功能范围的任何限制。不应把计算环境100解释成对示例性操作环境100中例示出的任一组件或其组合具有任何依赖性或要求。本发明可与各种其它的通用或专用计算系统环境或配置一起操作。可适用于与本发明一起使用的已知的计算系统、环境和/或配置的例子包括但不限于个人计算机、服务器计算机、手持或膝上型设备、多处理器系统、基于微处理器的系统、机顶盒、可编程消费电子产品、网络PC、小型机、大型机、电话系统、包括上述系统或设备中的任意设备的分布式计算环境等等。可在计算机执行的诸如程序模块之类的计算机可执行指令的上下文环境中描述本发明。一般地，程序模块包括例程、程序、对象、组件、数据结构等等，它们执行特定的任务或实现特定的抽象数据类型。本发明还可在分布式计算环境中实施，分布式计算环境中，由通过通信网络链接的远地处理设备执行任务。在分布式计算环境中，程序模块可位于包含存储器存储设备的本地和远地计算机存储介质中。参考图1，用于实施本发明的示例性系统包括采用计算机110形式的通用计算设备。计算机110的组件可包括但不限于处理单元120、系统存储器130、将包括系统存储器的各种系统组件耦合到处理单元120的系统总线121。系统总线121可以是若干类型的总线结构中的任何一种，包括存储器总线或存储器控制器、外围总线和使用各种总线体系结构中的任一种的局部总线。作为例子但非限制，这种体系结构包括工业标准结构(ISA)总线、微通道结构(MCA)总线、增强型ISA(EISA)总线、视频电子标准协会(VESA)局部总线、以及也称为夹层(Mezzanine)总线的外设部件互连(PCI)总线。计算机110一般包括各种计算机可读介质。计算机可读介质可以是可由计算机110存取访问的任何可获得的介质，包括易失性和非易失性介质、可移动的和不可移动的介质。作为例子但非限制，计算机可读介质可包括计算机存储介质和通信介质。短语“计算机存储介质”意图包括易失性和非易失性、可移动和不可移动的介质，以用于存储诸如计算机可读指令、数据结构、程序模块或其它数据之类的信息的任何方法或技术来实现。计算机存储介质包括但不限于RAM、ROM、EEPROM、闪存存储器或其它存储技术、CD-ROM、数字通用盘(DVD)或其它光盘存储器、磁带盒、磁带、磁盘存储器或其它磁存储设备、或可用于存储所需信息并可由计算机110存取访问的任何其它介质。通信介质一般将计算机可读指令、数据结构、程序模块或其它数据嵌入诸如载波或其它传输机制的调制数据信号中，并包括任何信息传递介质。术语“调制数据信号”是指以编码信号中的信息的方式设置或改变信号的一个或多个特征的信号。作为例子但非限制，通信介质包括诸如有线网络或直接线缆连接之类的有线介质，以及诸如声音、RF、红外线和其它无线介质之类的无线介质。上述的任何组合都应包含于计算机可读介质的范围之内。系统存储器130包括采用易失性和/或非易失性形式的计算机存储介质，例如只读存储器(ROM)131和随机存取存储器(RAM)132。包含在诸如起动期间帮助在计算机110内的元件之间传送信息的基本例程一般存储在ROM131中。RAM132一般包含可由处理单元120立即存取和/或当前操作的数据和/或程序模块。作为例子但非限制，图1例示出操作系统134、应用程序135、其它程序模块136和程序数据137。计算机110还可包括其它可移动/不可移动、易失性/非易失性计算机存储介质。仅作为例子，图1例示出对不可移动非易失性磁介质进行读写的硬盘驱动器141、对可移动的非易失性的磁盘152进行读写的磁盘驱动器151、对诸如CDROM或其它光学介质之类的可移动的非易失性的光盘156进行读写的光盘驱动器155。可用于示例性操作环境的其它可移动的/不可移动的、易失性/非易失性计算机存储介质包括但不限于磁带盒、闪存卡、数字通用盘、数字视频带、固态RAM、固态ROM等等。硬盘驱动器141一般通过诸如接口140之类的非易失性存储器接口连接至系统总线121，磁盘驱动器151和光盘驱动器155一般通过诸如接口150之类的可移动存储器接口连接至系统总线121。上述的以及图1中所例示的驱动器及其相关的计算机存储介质为计算机110提供了对计算机可读指令、数据结构、程序模块和其它数据的存储。例如，图1中，硬盘驱动器141例示为存储操作系统144、应用程序145、其它程序模块146以及程序数据147。注意，这些组件可以与操作系统134、应用程序135、其它程序模块136和程序数据137相同或不同。这里对操作系统144、应用程序145、其它程序模块146以及程序数据147给出不同的标号是为了说明它们至少是不同的副本。用户可通过诸如键盘162、话筒163和诸如鼠标、轨迹球或触摸板之类的定点设备之类的输入设备，将命令和信息输入到计算机110中。其它输入设备(未示出)可包括操纵杆、游戏盘、碟式卫星反射器、扫描器等。这些和其它输入设备通常通过耦合至系统总线的用户输入接口160连接至处理单元120，但也可通过诸如并行端口、游戏端口或通用串行总线(USB)之类的其它接口和总线结构来连接。监视器191或其它类型的显示器也可通过诸如视频接口190之类的接口连接至系统总线121。除了监视器之外，计算机还可包括诸如扬声器197和打印机196之类的其它外围输出设备，可通过输出外围接口190来连接。计算机110可在使用对诸如远地计算机180的一个或多个远地计算机的逻辑连接的联网环境中工作。远地计算机180可以是个人计算机、手持设备、服务器、路由器、网络PC、对等设备或其它公共网络节点，一般包括上述关于计算机110所述的许多元件或全部。图1中描绘的逻辑连接包括局域网(LAN)171和广域网(WAN)173，但还可包括其它网络。这种联网环境在办公室、企业范围的计算机网络、企业内部互联网络和因特网中是常见的。当用于LAN联网环境中时，计算机110通过网络接口或适配器170连接至LAN171。当用于WAN联网环境中时，计算机110一般包括调制解调器172或其它手段，用于在诸如因特网之类的WAN173上建立通信。可位于内部或外部的调制解调器172可通过用户接口160或其它适当机制连接至系统总线121。在联网环境中，关于计算机110描述的程序模块或其部分可存储于远地存储器存储设备中。作为例子但非限制，图1例示出远地应用程序185驻留于远地计算机180上。将理解到，所示的网络连接是示例性的，可使用用于在计算机之间建立通信链接的其它手段。C.SPL框架的综述SPL框架由运行时间组件(解释器(Interpreter))和一组类型构成。运行时间组件介于客户端应用程序和一个或多个自然语言分析引擎之间。所述一组类型定义了系统中的所有元素之间的交互。在利用该SPL框架的应用程序中，在运行时间创建解释器实例，并用描述依赖于自然语言输入的客户端应用程序中的特征的语义模型的说明模式(declarativeschema)。该说明模式是由开发者与应用程序代码一起创建的，它描述了由开发者创建的以及从LOM中的类型派生出的若干语义建模类型之间的关系。这些语义建模类型可包含所述说明模式中未提及的、以及在由解释器例示时对类型的实例设置运行时间上下文环境驱动(runtime-context-driven)约束的程序代码。图2是根据本发明的一个实施例的语义框架的框图。语义框架200包括SPL客户端应用程序202、SPL解释器应用程序204、以及多个分析引擎206。一般来说，SPL客户端应用程序202接受文本输入，可通过用户直接输入(诸如通过键盘或其它输入设备)或可从语音识别系统208或文本识别系统210接收。语音识别系统208是接收音频输入并产生表示所述音频输入的文本输出的系统。文本识别系统210是接收手写或扫描输入，并产生表示所述手写或扫描输入的文本输出的系统。在一个实施例中，语音识别系统208和手写识别系统210与客户端应用程序202相集成。在框架200中，文本输入212串输入到SPL客户端202。文本输入212A指的是从语音识别系统208输出的文本。文本输入212B指的是从手写识别系统210输出的文本。文本输入212C表示诸如来自键盘、存储器缓冲器或任何其它输入源的其它文本输入。下文中，参考标号212适用于接收到的文本输入而与源无关。SPL客户端应用程序202将文本输入212和SPL客户端应用程序的应用程序模式214传送给SPL解释器应用程序204。SPL解释器应用程序204将文本输入212和应用程序模式214传送到多个自然语言分析引擎206(诸如方框所示的分析引擎1至分析引擎N)，每个分析引擎设计成将话语映射到语言对象模型(LOM)216。可采用任何数量的分析引擎，每个引擎206可使用唯一的分析策略，用于将文本输入212映射到LOM216和应用程序模式214。一般来说，每个分析引擎206将其范例运用于文本输入212，将文本输入212映射到LOM216以产生多个可能的解释218，所述多个可能的解释218返回给SPL解释器应用程序204。SPL解释器应用程序识别一个或多个实际解释220，将那些实际解释220返回给SPL客户端应用程序202，SPL客户端应用程序随后对一个或多个实际解释220起作用。在一个实施例中，分析引擎206仅仅得出一个可能的解释218；然而，大多数语义话语允许不止一个可能的解释，可由解释器204或客户端应用程序202就话语的上下文来解析。在该情况下，上下文是SPL客户端应用程序202和它支持的对象的域。在从SPL客户端应用程序202接收了说明模式214之后，SPL解释器204试图相对于说明模式214来解析可能的解释218。SPL解释器应用程序204可以放弃那些相对于说明模式214不能被解析的解释218。剩下的解释(相对于说明模式214可被解析的那些)是实际的解释220。SPL解释器204通过在客户端应用程序202中调用实际解释对象220来根据SPL客户端应用程序202的说明方案例示出所述多个实际解释220中的每一个。根据框架200的实施和配置，控制222可从SPL客户端应用程序202转到SPL解释器应用程序204，指示SPL解释器应用程序204进行进一步的处理。类似地，解释器应用程序204可将控制224转到分析引擎，用于相对于LOM216进行对文本输入212的进一步处理。从而，语义框架200可反复地处理文本输入，以获得对应于SPL客户端应用程序202的域内定义的类型的实际解释。一般来说，SPL客户端应用程序202、解释器204以及分析引擎206可位于单个计算机中。在可选的实施例中，应用程序202、解释器204以及引擎206可位于不同的系统上，例如位于网络上的分离的服务器上。SPL解释器204用作为客户端应用程序202和分析引擎206之间的中介。SPL编程语言意图对于开发者来说是直观的。在一个实施例中，该语言是构建在C#上的，从而语法对于开发者来说是熟悉的。然而，SPL适合于表示LOM语义结构以及进行语言分析，并能够直接以C#或任何其它的基于对象的编程语言来实现。如先前所述，SPL框架包括运行时间组件(SPL解释器204)，它介于自然语言分析引擎206和一组类型之间，所述一组类型由开发者创建以及从LOM中定义的类型中导出。该组类型定义了框架的所有组件之间的交互的性质。SPL框架利用但不包含自然语言分析引擎。它被设计成如果需要的话则允许同时使用多个分析引擎。例如，某些引擎可能在某些类型的自然语言输入方面比其它引擎更佳，因此可能希望采用多个分析引擎。组合多个引擎的输出会导致更佳的总体性能和表现。对于任何给定的自然语言输入212，期望分析引擎206向解释器204提供以说明模式214中描述的类型体系表示的语言上可能的解释218。分析引擎206一般能够访问说明模式214中的语义类型的描述，但不能访问实际类型。它们不是产生实际的对象，而是产生可能的解释(218)，这是用于构建实际解释220的指令集。仅当解释器204成功地创建了解释的实例，其中这包括运行所涉及的类型的程序代码，由分析引擎206产生的可能的解释218才可能变成实际解释220。解释器204试图相对于说明模式214来解析可能的解释218，并且根据特定的实现，在客户端应用程序202中创建成功解析的解释用于进一步处理。客户端应用程序202、解释器204以及分析引擎206(包括文本输入212、说明模式214、可能的解释218、实际解释220以及控制流222和224)的前后隔离了冲突和/或模糊。框架和LOM协作以使编程者自由地去关心应用程序域，而不是语言分析。一般来说，说明方案可以是XML代码、Microsoft.NET属性、或者Microsoft.NET属性和可解析的类型本身。可选地，可解析的类型可以是代码化的，从而可使用“反射”(reflection)从类型中推导出模式信息。反射是一种确定对类或对象定义了什么方法、字段(field)、构造函数(constructor)等的能力。反射使得能够创建动态程序。既然已经介绍了框架，因此重要的是理解底层语言对象模型，开发者可从中得出其应用程序专用的类型组。语言对象模型除了有用于自然语言应用程序开发目的之外，还可用于与自然语言语义分析系统直接交互，用于任何目的。D.语言对象模型(LOM)D1.综述本发明的语言对象模型(LOM)由与应用程序域无关或甚至于与语言无关的一组类型组成。本发明包括该组类型和设计该组类型以进行建模的语言表达式的类。所述类型是LOM的说明元素。应理解，本发明的应用程序可以任何方式实现，具体的实施细节可与这里给出的实例不同。然而，下面给出的例子用于说明性的目的，不能被解释为任何限制。在合适的地方，可以调出替代的方法或框架变型，以进一步说明本发明的多样性和稳健性。一般来说，LOM以与域无关的方式对(口述的或手写的)话语的语义进行建模。这里所使用的术语“域”(domain)指的是发起自然语言处理请求的SPL客户端应用程序。这里所使用的术语“语义”指的是口语或手写单词的含义或说明。术语“话语”指的是语言引擎试图进行语义分析的由软件引擎检测到的任何有限的声音或声音串和/或任何手写的单词或短语。这里所使用的术语“语法”指的是定义了语言中的符号如何组合以构成单词、短语、表达式和其它可辨识的结构的语法或结构规则。LOM类型可由软件应用程序访问，以将话语的元素映射到语言表达式的类。出于澄清的目的，下面的讨论主要针对从LOM类型到语言表达式的类的映射。然而，应理解，映射是从LOM类型到语言表达式的类以及从语言表达式的类到LOM类型的全双工的(双向)映射。这种映射的两个方向对于不同的任务来说都是重要的。此外，应理解，LOM本身是与语言无关的，从而为了对不同的语言建模，无需对LOM进行代码改变。相反，这种语言专门代码改变是在分析引擎中作出的，而不是在客户端应用程序中作出的。一般来说，LOM按照一组构件块抽象地规定了语言。SPL应用程序利用构件块框架以与域有关的方式来访问词汇语义结构和分析引擎。最后，应理解，LOM不要求应用程序模式来操作。LOM可用于对话语建模，分析引擎可提供与应用程序模式无关的LOM映射。从而，LOM可被认为是位于分析引擎内，并且LOM是语义表示自然语言的方式。分析引擎作出关于对于给定的话语哪个是正确的LOM表达式的判决，有效地将话语映射到LOM。图3示出了根据本发明的实施例的图2的系统的分析组件300的简化框图。分析引擎302接收流控制304、应用程序模式306和文本输入308。使用LOM310，分析引擎302将文本输入308映射到应用程序模式306，以便产生一个或多个可能的解释312，所述可能的解释SPL可由解释器或应用程序模式306所来自的客户端应用程序来解析。一般来说，可能的解释312是表示为LOM对象的特定类型的简单对象。在将可能的解释返回到解释器或客户端应用程序之前，分析引擎302可额外地将LOM对象映射到应用程序模式的对应对象，这取决于实现方式。在详细讨论LOM的结构之前，开发至少粗略地理解语义编程语言所使用的基本类型是有用的。一般来说，语义编程语言可在任何数量的不同语义对象模型上工作，但专门对与LOM的结构有关的操作进行了优化。此时，LOM是在编程可理解性(从应用程序开发者的观点)和语言覆盖范围(即诸如指令控制(command-and-control)、询问-应答等之类的应用场合所要求的模型元素)之间提供最佳折中的特定语义对象模型。D2.语义编程语言对象语义编程语言(下文中称为“SPL”)意图帮助软件应用程序开发者实现自然语言程序。由于大多数开发者在语言分析或语言学上并非是专家，SPL提供了一种用于非语言学家开发者在很大程度上以直觉的方式处理自然语言的框架和编程语言。SPL和伴随的编译器使得对LOM的自然语言客户端应用程序的编程变得容易。设计SPL来隐藏语言框架的许多底层细节，以便使得开发者更容易编写能正确与框架交互的代码。虽然SPL可成为使用框架的开发者的标准前端，但是SPL并非必需。通过创建实现各种框架接口的类型、通过继承实现各种框架接口的类型、以及通过向解释器提供应用程序模式，开发者可直接以框架为目标。可选地，也可间接地进行，例如通过编写框架兼容的代码的其它手段，例如通过可视的基于表格的设计工具。一般来说，LOM实现为SPL的类库，这类似于C运行时间库(CRuntimeLibrary)和标准模板库(STL)构成例如MicrosoftVisualC++标准库之类的方式，其中MicrosoftVisualC++是由华盛顿州雷蒙德市的微软公司创建的、设计用于便于软件开发使用的应用程序。术语Microsoft和VisualC++是华盛顿州雷蒙德市的微软公司所拥有的商标。SPL中的语义上有含义的类型是那些参与对输入的话语的语义进行建模和参与那些输入的话语所对应的应用程序命令的建模的类型。语义上有含义的类型是SPL设计者能够从他们的应用程序域中得出的和专用于他们的应用程序域的类型。SPL中的语义上有含义的类型是实体(Entity)、构架(Frame)、约束(Restriction)、命令(Command)、以及标志牌对象(Denoterobject)。SPL中的功能类型是短语(Phrase)和槽(Slot)。这些类型中的每一个将在下面分开讨论。一般来说，SPL框架类型定义了客户端应用程序、SPL解释器以及一个或多个自然语言分析引擎之间的交互的所有方面。短语“交互的所有方面”指的是各种组件必需实现的接口、各种组件继承的基类、以及系统的组件之间传递的数据的类型。在一个实施例中，框架类型是以华盛顿州雷蒙德市的微软公司创建的.NET框架中的类型来实现的。可把SPL类型安排成若干名字空间。在一个实施例中，SPL类型被安排成若干名字空间，它们是例如System.NaturalLanguageServices或System.NaturalLanguage名字空间的所有子名字空间。这里所使用的“名字空间”指的是定义名字(标识符)的上下文环境。在一给定的名字空间内，所有的名字必须是唯一的。为了清楚起见，下面的讨论介绍SPL类型，详细介绍LOM，然后返回到详细介绍SPL。贯穿全文，在适当的地方使用例子来例示出本发明。对于大多数的部分，例子往往是得自于简单的自然语言话语“SendmailtoBob”(向Bob发邮件)。给出该话语，根据LOM编写的和使用SPL的应用程序能够根据该文本输入产生解释。然后，可相对于自然语言应用程序来解析所产生的解释，以识别和执行指令的实际解释。实体(Entity)是类型Entity的对象，意味着实体能够包含数据成员、性质和方法。SPL实体是那些类型从类Entity得出的并主要用于对名词短语和形容词短语的语义进行建模的对象。SPL实体可通过“with”语法来主控构架(frame)或约束(restriction)(下文描述)。此外，SPL实体可包括任选的“DenotedBy”(由……表示)子句，该子句引入了类型“Denoter”(下文描述)的有特权的数据成员。由“DenotedBy”子句引入的有特权的数据成员可由SPL解释器使用，将实体映射到实际自然语言单词。构架(Frame)是类，它对语义事件的语义建模，其中语义事件可被表示为动词或名词。SPL构架(frame)是从Frame中得出的类。一般来说，Frame可适用于实体，所以Frame可具有“DenotedBy”子句以及包含构架变量(argument)的“slot”(下文描述)列表。Frame可通过“with”语法来主控约束(restriction)。在一个实施例中，Frame的头单词可由开发者来定义，以创建新的Frame类型。在另一实施例中，开发者从现有的构架继承，通过继承得出所需的头单词。在另一实施例中，开发者以类似于如何规定标志牌(denoter)的方式来规定头单词。约束(Restriction)一般对间接变量、修饰语、以及其它语义元素进行建模。SPL约束是从类Restriction得出的类。类似于frame，restriction具有包含变量的slots列表。此外，SPL约束可通过“with”语法来主控其它约束。SPL命令(command)是从类Command得出的类。命令(Command)完全是域相关的，这是指它们依赖于它们所关联的特定自然语言应用程序。一般来说，域相关的命令在对输入的语义进行建模的过程中不起作用，从而命令在LOM中不起作用。相反，命令对应用程序中的动作进行建模。此外，命令具有任选的“uses”(使用)子句，该子句引入了类型Frame的有特权的数据成员。“uses”子句是与域无关的输入和所希望的与域有关的动作之间的重要链接。标志牌(Denoter)对象是类型Denoter的构造(structs)。实际上，创建词典，从用作为SPL程序中的标志牌的每个单词映射到对应的标志牌列表，从而Denoter对象不需要存储串列表。每个自然语言有一个Denoter对象(英语字段、日语字段等)。Denoter对象充当实体的位置表(localizationtable)。类似于命令，denoter对象完全是域相关的。然而，Entity不具有类型Denoter的字段，只有使得应用程序能够检查Denoter对象以判断分析引擎为什么建议Entity，该字段才存在。SPL中的功能类型是用于某些建模目的的类型，但不能被专门化。此外，其它类和类型不能从功能类型中导出。功能类型“Phrase”封装了关于作为某个语义对象的基础的文本串输入的一部分的信息。类型Phrase允许软件开发者从原始输入串的语义的内部结构化表示对原始输入串执行特定的操作和检查。在一个实施例中，功能类型“Slots”是类型Slot的对象，它保持实体(entities)、构架(frames)、约束(restrictions)或标志牌(denoter)对象，可能带有某些辅助信息。例如，对应于相关子句中的间隙的槽(slot)包含标记为“反向引用”(backreference)的实体。在另一实施例中，Entity、Frame或其它引用置于被预期的槽的位置处。在另一可选的实施例中，Slot对象及其辅助信息都被忽略，直接使用Entity、Frame或其它引用。D3.LOM类型已经评述了定义SPL语义模型结构的类型，就能够详细讨论LOM。一般来说，由类型建模的语言表达式的LOM类型和类包括实体(Entities)、构架(Frames)和约束(Restrictions)。a.LOM实体(Entity)虽然SPL编程者的很大一部分工作，也许是主要的工作，都围绕着设计域实体类型和为那些类型的每一个类型收集正确的位置信息，示出一种规范的表示。例如，术语walks、walked和walking共享词条walk。不管所使用的口语是什么，所有语言的一般规则是NP变成LOM实体。实体的头单词是NP的中心名词的词条。一般来说，通过类型“CoordinateEntity”来表示实体的协调。表1中示出了说明类型CoordinateEntity的示例的代码片段。从LOM的观点来看，实体是直接的。在许多情况下，短语的“头单词”是实体的头单词。该头单词通常对应于实体所建模的短语的语法头的词条。词条(lemma)对于单词的不同形式表表1CoordinatedEntityEntityCoordinatedEntity{Entityentities[]；CoordRelationrelBetweenEntities；}enumCoordRelation{And，Or，ExclusiveOr}关于协调的LOM的目标是将语义不相关的括号多义性最小化。从而，例如，文本输入XandYandZ被表示为平坦列表XandYandZ，而不会在右联Xand[YandZ]和左联[XandY]andZ之间产生歧义。然而，当存在确实的括号多义性时，LOM保持该多义性。例如，对于短语showcarswith4WDandABSorAWD，4WDand[ABSorAWD]和[4WDandABS]orAWD都是可能的。当然，在该特定情况下，仅第二种表示可能是有意义的，但是，这仅是用于应用程序来决定，而非由LOM决定。LOM中把代词建模成类型“PronounEntity”的对象。表2示出根据本发明的实施例的代词实体的示例。表2PronounEntity.entityPronounEntity{EntitypotentialAntecedents[]；}LOM通过PronounEntity内的“potentialAntecedents”字段提供用于首语重复解析(anaphoraresolution)。术语“首语重复”(anaphora)指的是涉及相同Entity的多个单词或短语之间的关系。可用作为语言上可能的先行词的预先解析的Entity对象列表来填充potentialAntecedents字段。该列表以似然性的降序排列。应用程序开发者可通过附于每个Entity的类型“AgreementInfo”的对象来访问作为首语重复解析中的最重要的因素的语言一致信息。表3提供了构造AgreementInfo的例子。表3STRUCTAgreementInfostructAgreementInfo{boolfirstPerson；//第一人称boolsecondPerson；//第二人称boolthirdPerson；//第三人称boolsingular；//单数boolplural；//复数boolfeminine；//女性boolmasculine；//男性boolneuter；//中性boolhonorific；//表示尊敬boolhumble；//表示谦逊}只有相对于给定实体明显为真的AgreementInfo字段才与该实体的AgreementInfo对象相关联。换言之，LOM不试图表示转折的一致特征。例如，术语cat将使得“thirdPerson”和“singular”与其一致对象相关联。在法语中，术语“vous”与“secondPerson”相关联。在西班牙语中，术语perro是“thirdPerson”、“singular”以及“masculine”，对于给定的实体perror来说，这三种属性中的每一个都毫无疑问的是真的，因此与实体的一致对象相关联。诸如可用作为独立NP的“this”和“that”之类的指示代词成为类型DemonstrativeEntity的对象。表4给出了实体DemonstrativeEntity的例示。表4DemonstrativeEntity.entityDemonstrativeEntity{DemonstrativeTypetype；}enumDemonstrativeType{Near，Middle，Far}由于类型DemonstrativeEntity的对象是从Entity导出的，因此，它们继承了AgreementInfo对象，允许区分类似于this和that之类的单词。一般来说，这种继承允许系统能够在英语、法语、德语、日语、西班牙语以及许多其它语言的这种元素之间正确地进行区别。另一相关的类型是NamedEntity类型。用于NamedEntity的语法如下。namedentityOlapNamedEntityusesExcelAddin.FuzzyOlapCubeRecognizer；一般来说，NamedEntity类型基于单独定义的一个类，该类是从NamedEntityRecognizer类继承来的。NamedEntityRecognizer类型连同模式一起传递，分析引擎能够使用它们来回调客户端代码，以动态地识别话语中的应用程序对象引用。b.LOM构架(Frame)在一个实现中，对于所有的语言，字句成为LOM构架；然而，对于所有的实现方式，这并不总是真的。在概念上，构架从字句得出，但是在输入中并不需要确实存在字句。构架的头单词是作为字句的头的动词的词条。例如，分析短语“SendmailtoBob”将导致“Sendmail”与LOM构架相关联，其中“Send”是作为字句的头的动词的词条，因此是该构架的头单词。应理解，可把约束(Restrictions)概念化成提供默认的行为。然而，未必强制这种行为。该功能是特定于实现方式的。槽(Slots)可通过实体或构架来填充，从而默认的slots可以是名词短语或字句。此外，NP可以由空代名词(PRO)作为头。如果PRO指向另一字句中的对象，该字句的头将被解释成NP实体的头。如果PRO没有对象，则它将被解释为某一实体(诸如someone或something)。在一个实施例中，假设字句中包含主语，该字句的主语满足“Doer”约束。如果没有主语，则没有“Doer”约束。“Doer”代表某一事件中的第一参与者，语义上宽松地表示为doer(做...的人)、agent(主动者)、actor(参与者)、instigator(煽动者)或动词命名的事件或状态的原因。在字句的一部分映射到构架的“doer”约束的情况下的动词字句的例子示于表5。表5.VerbClausewithaSubject(带有主语的动词字句).Instantmessageopens.Robinisonmybuddieslist.Amazonofferswishlistcapabilities.openthefileHavingaprogramassociatedwithafileensureseasyopening.划底划线的单词或短语是映射到Doer槽的单词或胆俞。在及物和不及物构架中，这都是真的，对应于及物和不及物动词。如果字句中存在宾语，宾语映射到表示事件中的第二语法上的参与者的称为“DoneTo”约束的构架的第二槽。可把语义宽松地理解为指代被事件或由动词命名的状态影响的对象。表6中下划线的短语映射到“DoneTo”约束。表6The″DoneTo″RestrictionOutlookhasmybuddieslist.Amazonofferswishlistcapabilities.openthefile.Preferencesincludehavingaprogramassociatedwithafile.在一个实现中，间接宾语可被理解为动作的受益人。在一个实施例中，间接宾语可被映射到Beneficiary约束。Beneficiary约束一般对表示某一事件是为谁的利益或在谁的地方进行的那个人的动词变量进行建模。表7中包含的下划线的代名词简要地例示出beneficiary槽。表7BeneficiarySlot.Openmeanewfile.PlayhersometunesBeneficiary约束(或在替代的实施例中是“slot”)可设置到对被解释为beneficiary的名词短语进行建模的实体。表8例示出beneficiary约束的代码块。表8BeneficiaryRetriction.restrictionBeneficiary<benef＝Entity>{}beneficiary约束有时被称为“施益体的”(benefactive)，与英语中的分配(allocation)相重叠，尤其是对于“for”介词短语的单数宾语更是如此。某些重叠也发生在其它语言中。当运用于构架时，通过下面的语句，beneficiary约束是显而易见的。Ibakedacakeformymother.PP[for]一般来说，beneficiary约束对大多数语言中的动词变量进行建模。表9例示出若干样本语言中的beneficiary约束。表9BeneficiaryRestriction.英语介词for适用于不作为目标的间接宾语(不能由″to″前置短语来解释)Ibakedheracake->Ibakedacakeforher.NOTIgaveherabook(cf.Igaveabooktoher，cf.目标)Ibakedacakeforher.Ibakedheracake.法语介词pour德语间接宾语IchschickeihreineNachricht.介词fürDasisteineNachrichtfürsie.日语NP-のためのNPNP-のために…VP固定分句(小字句)的主语结构，与英语bakeacake[forhertohave]比较。相反，取目的变量的动词用与格虚词来标记，例如giveher-DATbook-ACC西班牙语介词paraTrajimoslalistaderegalosparaFernando.一般来说，约束可以是主语、直接宾语、间接宾语、间接变量、修饰语等。在SPL中，构架可采用任何约束(除了下面描述的例外)。然而，LOM使用语法以两种方式来提出约束。第一种是间接变量可以是与词汇语义结构类相关联的约束类型，动词是该类的成员(这在下文中详细描述)。第二种是间接变量可以与独立动词相关联；也就是说，该变量不具有对其子句头的任何约束关系。变量被分配给默认约束(Defaultrestriction)(下文讨论)，并由它们的词汇头来识别。构架的协调是以两种不同的方式进行的，这取决于上下文环境。“顶级”(Top-level)协调构架(即从主语动词(matrixverb)得出的)被表示为类型CoordinateFrame的对象，与CoordinateEntity(上文所述)相平行。表10示出一个示例性的实例。表10CoordinatedFrame.frameCoordinatedFrame{Frameframes[]；CoordRelationrelBetweenFrames；}一般来说，(通过“with”语法)呈现于实体上的构架表现为约束。如下所述，这指的是通过触发多个约束来表示逻辑与(conjunction)，而通过在主实体外增加到CoordinateEntity来表示逻辑和(disjunction)。如先前所述，在一个实施例中，构架可充当实体上的约束，以对自然语言关系子句进行建模。当构架通过“with”关键字而依附于实体时，构架对实体强加了约束，这被称为是“基于构架的约束”。在大多数情况下，构架中的一个槽对应于被中心名词限制的自然语言间隙。在LOM中，这转化为基于构架的约束在其一个槽中接收对其主实体的引用。将对主实体的引用包含于基于构架的约束的一个槽中可被称为是“反向引用”。由于这种“反向引用”允许再进入别样的树形LOM表示，对应于间隙的槽使其isBackreference标志设置为真(该标志仅仅便于走过LOM表示的过程)。例如，在下面的表11中，相对于短语“filesthatBillyopenedyesterday”来解析基于构架的约束。表11基于构架的约束Entity1(file)|open<Entity2(Billy)，{isBackreference}Entityl(file)>Time([1dayback]OFFSETFROM[now])在表12中，相对于短语“peoplewhoworkatCompany”来解析基于构架的约束。表12基于构架的约束Entity1(people)|work<{isBackreference}Entity1(people)>|Location<Entity2(Company)>在表13中，相对于短语“peopleIhavesentmailto”来解析基于构架的约束。表13基于构架的约束Entity1(people)|send<PronounEntity2(1st_pers，sing)，Entity3(mail)>|Goal<{isBackreference}Entity1(people)>重要的是注意到由基于构架的约束引入的重进入为SPL解析处理造成困难。具体来说，在实体的所有约束都已被完全处理之后，实体才会被完全解析(从而SPL在技术上不“存在”)。然而，实体的约束之一可以是构架，该构架在其一个槽内采用实体本身。从而引起了这样一种情况，其中，需要由定义构架的代码来检查实体对象，然而实体仍然保持在未定义的状态中，直到对构架的解析结束之后的某一点为止。在下面的部分E.4中更详细地讨论该问题。在一可选的实施例中，构架不具有槽，但是如下所述使用“Doer”和“DoneTo”约束。在这样一种情况下，可根据该构架来定义新的约束，可把用于“Doer”和“DoneTo”的约束子句运用于该新的约束。从而，约束表现出另一种处理构架变量的方式。在下面的讨论中，为简洁起见，仅参考一种实施方式，但是任一种实施方式均可适用。c.LOM约束(Restrictions)不同于实体和构架，约束的协调并非通过使用诸如CoordinateEntity和CoordinateFrame之类的“混合”类型来表示。相反，采用SPL的语义来表示约束逻辑与(conjunction)，而约束逻辑或(disjunction)被缩小到实体或构架逻辑或(disjunction)。SPL向同一主体(host)上连续成功触发的两个约束子句分配逻辑与(conjunction)或逻辑乘(intersection)；因此，用约束建模的素材的语言逻辑与通过简单地顺序地触发两个或多个约束来处理。另一方面，用约束建模的素材的语言逻辑或在SPL语义中并没有便捷的类似处理方式。于是，这种逻辑或“冒泡”(bubbleup)到位于约束(通常为主体)上的下一实体或构架，在该级上产生CoordinateEntity或CoordinateFrame对象。例如，对于短语“mailfromKimortoRobbin”来说，存在一个实体主体即“Entity(mail)”和两个约束即“Source(Entity(Kim))”和“Goal(Entity(Robin))”。由于这两个约束与逻辑或“or”相协调，该逻辑或应当冒泡到该主体“Entity(mail)”，导致表14中所例示的映射。表14约束协调CoordinatedEntity([Entity(mail)，Entity(mail)]，||Source(Entity(Kim))Goal(Entity(Robin))Or)该代码产生Entity(mail)的两个副本。伴随物(Accompaniment)约束对某个组中的额外的成员进行建模。通常，可用逻辑与来解释伴随物。例如，短语customersalongwiththeirbirthdates可被解释为customersandtheirbirthdates。对于互补事件表示(reciprocal-event-denoting)实体，伴随物约束对事件中的额外的参与者进行建模。通常，这种名词具有对应的构架(例如correspond、meet、chat、等等)。伴随物约束还对名词短语中的介词短语进行建模，例如correspondencewithmymanager、anappointmentwithKim、meetingwithTim(添加强调)、achatwithSue等等。根据本发明的实施例的Accompaniment约束的语法的例子例示于表15中。表15ACCOMPANIMENT.restrictionAccompaniment<accomp＝Entity>{}Accompaniment约束还能够对Frame的上下文中的其它的who或what参与者进行建模。例如，短语“chatwithRobin”利用短语“withRobin”作为accompaniment约束来调用“Chat”构架。Accompaniment约束还可被分配给对被解释为伴随着主体的名词短语进行建模的实体中内的槽。可选地，accompaniment约束可被设置到“who”或“what”槽。在某些情况中，希望将“with”情况的列表编译成语义上相当于逻辑与的实体列表。就其它语言中也存在等价的accompaniment表达式来说，按需为那些表达式编译实体列表可能是有用的。就可被建模成伴随物的所有格来说，也希望将它们包含于实体列表中。例如，“emailwithattachments”(带有附件的电子邮件)是伴随物形式的所有格，而与作为所有人形式的所有格的“email’sattachments”(电子邮件的附件)相对。在某些情况下，诸如“anemailthathasattachments”之类的短语也可被建模成伴随物约束。主语互换也可调入伴随物约束中。主语互换的例子是“JohnchattedwithMary”，这与“JohnandMarychatted”相对照。在词汇上，这两种表达式都容易被识别。类似地，宾语互换，例如“MergeFileAandFileB”与“MergeFileAwithFileB”相对照，是可容易识别的。可能希望将这种主语和宾语互换结合于LOM中的伴随物规格化中。伴随物约束延伸及许多中语言中，特别是在诸如“alongwith”或“togetherwith”之类的介词短语方面。在法语、德语、日语、西班牙语和其它语言中，可采用类似的伴随物约束。表16例示出这种伴随物。表16AccompanimentRestrictions(along|together)PP[with](英语)((tout)ensemble)PP[avec](法语)PP[mit]+Dative(德语)″ErkommtmitdenKindern.″EntityHosts(日语)NP-とのNPNP-のあるNPFramehosts(日语)NP-と…VPNP-と…一緒に…VPPP[con](西班牙语)诸如表17中所例示的分配约束(allocationrestriction)一般对向其分配主体实体(hostentity)的实体进行建模，或者对代表主体实体而存在或创建的实体进行建模。表17AllocationRestriction.restrictionAllocation<alloc＝Entity>{}当分配约束对向其分配主体实体的实体进行建模时，这种约束的例子可以是“onlineprofileforeachfund”、“schoolsforlinguistics”或“applicationforajob”。下划线的部分说明了该分配约束。当分配约束对代表主体实体而存在或创建的实体进行建模时，语义话语可以是“acakeformymother”或“partyformymanager”。在两种情况中，分配约束都对实体添加了特征。表16例示出分配约束的一个例子的代码。分配约束可设置到对解释为分配给使用槽的主体的名词短语进行建模的实体。一般来说，分配约束可运用于向单数实体以及复数实体的分配。英语中，分配约束处于与受益人的互补分布中。仅实体主控分配。仅构架主控受益人，特别是对for介词短语的单数宾语。英语中，可以多种方式使用该介词。例如，在packetsforaspecificdestination中，它表示目的；而在applicationforwhichyouareenablingauthorizationchecking中，它是一种类型的分配。类似地，tabsfortaskpadviews、checkboxforthetypeofservice、以及areacodeforMadison，WI都表示分配约束。在德语中，für尤其表示分配。在西班牙语中，对应的介词是para短语“unaescobaparalacocina”例示出一分配约束。对Frame的“AsBeing”约束对分配给构架的对象槽的性质或能力进行建模。仅对形容词短语建模的修饰语约束映射到约束版本。表18提供了AsBeing约束的两个代码样本。表18AsBeingRestriction.restrictionAsBeing<asbeing＝Entity>{}restrictionAsBeing<asbeing＝Modifier>{}一般来说，LOM对话语的词条之间的语义关系进行建模。“AsBeing”约束试图对介词短语“as”进行建模。例如，短语“Savethefileasatextfile”类似于“Savethefiletoatextfile”。“Setmystatusasbusy”类似于“Setmystatustobusy”。AsBeing约束对分配给构架的对象槽的性质或能力进行建模。再次，AsBeing约束将约束“as”建模成作为分配给构架的对象槽的性质的“textfile”。可选地，可能将该功能运用于Denoter而不是运用于Entity。表19例示出英语、德语、日语和西班牙语中的AsBeing对象的例子。表19AsBeing例子英语PP[as]Savethefileastext.Makemeanadministrator.Markallmessagesunread.德语PP[als]SpeicherdieDateialsText.日语-tocomplementizers-tositeadverbials西班牙语PP[for]para基数(cardinal)约束是对由数字量词表示的基数进行建模的约束。槽和字段可设置到数字量词的浮点值。诸如“an”和“a”之类的不定冠词可在某些情况下被建模成“one”。表20例示出基数约束。表20CardinalRestriction.RestrictionCardinal{floatnumber；}此外，希望在某些情况下阻止时间单位的基数(诸如“in3hours”等等)。特别地就时间单位而言，阻止基数约束不应与时间类型的对象(至少在英语中)相冲突，因为引入时间量一般要求介词短语，例如“in3hours”或“for3minutes”等等。表21例示出可映射到基数约束的某些示例性表达式。表22例示出cardinal约束的示例性表达式英语3catsninetydollars2.5kilos法语3chatscinqfrancs2,5kilos德语3MailsfünfEuros2,5Kilos日语3匹の猫九十ドル2.5キロフアイル…3っ(浮点量词)西班牙语3gatos另一类型的约束“Comparison”(比较)对实体与另一个明确识别的实体之间的比较进行建模。Comparison约束的语法例示于表23中。表23ComparisonRestriction.RestrictionComparison<dimension＝Modifier，refpoint＝Entity>{}比较约束不用于隐含比较，例如要比较的实体之一不是明确被提及的。例如，“abiggerfile”暗示出一隐含比较，它不调用比较约束。比较约束可运用于量纲(dimension)约束，量纲设置到对形容词短语进行建模的修饰语约束。例如，该修饰语约束一般将具有“degree”约束，其degree字段设置成“more”、“less”或“same”。“refpoint”(参考点)字段设置到要与变量实体比较的实体。根据具体的实施方式，明确地命名比较类的最高级可能要求特殊的关注。例如，短语thetallestgirlintheclass可能导致调出class作为用于比较的参考点，或者可选地，可调出class作为girl的定位。各种其它的最高级表达式也可能要求特别的关注。例如，从LOM的观点来看，短语mydaughteristallforherage及其西班牙语等效语mihijaesaltaparasuedad呈现出类似的问题。表24提供了可由比较约束建模的某些示例性表达式。表24由比较约束建模的某些示例性表达式英语afilebiggerthanmydoc.txtdocumentsthatarelessrelevantthanmydoc.txtwatchesasexpensiveastheRolexX-55J法语deslivrespluschersquecelivre德语PP[als]EineDatei，diekleineristalsmydoc.txt.wie]DieDateiistgenausogrosswiemydoc.txt.日语mydoc.txtょり(もっと)大きぃフアィルロレックスX-55Jほど高ぃ腕時計西班牙语unarchivomásgrandequemydoc.txt条件(conditional)约束对话语中表达的条件进行建模。表25例示出条件约束语法。表25ConditionalRestriction.restrictionConditional<condition＝Frame>{ConditionTypetype；}类似于先前的例子，可在包括英语、法语、德语、日语、西班牙语(以及其它语言)的大多数语言中对条件约束进行建模。默认(default)约束不对任何特别的构造(construction)类进行建模，但是仅仅提供对其它LOM对象还未要求的底层语言分析部分的接口。表26提供了用于本发明的一个可能的实现方式的默认约束语法。表26DefaultRestrictionRestrictionDefault{LinguisticAnalysisanalysis；}Default约束的其它可能的变型将单个Entity作为它的槽。Default约束的这种变型使能该单个Entity和主控该约束的对象之间的任何关系成为可能。重要的是要注意，一般来说，约束可具有与之相关联的模式。这种模式关联可以使得LOM消费者能够与LOM制造者(分析引擎)关于要识别那些语言构造进行通信。简单的例子是基于串的模式。例如，源(Source)约束用法可具有[“dueto”+X]的模式，以确保分析引擎(LOM制造者)将该模式映射到Source约束。通过将模式关联运用于语言分析，编程者(创作者)可选择对用户输入进行较低级的推理。不同于其它LOM类型，没有用Default约束隐含的跨语言规格化。根据实现方式，可能需要定义能够将来自完全解析结果的任何东西暴露于简单的串的单个接口(例如ILinguisticAnalysis)。一般来说，模式可对应于可通过IlinguisticAnalysis暴露话语的一部分的不同的方式。在较佳实施例中，存在某一范围的默认约束，一个约束用于一种类型的分析引擎。Degree约束仅仅依附于对形容词短语进行建模的修饰语约束。表27例示出用于degree约束的语法和DegreeType枚举。表27DegreeRestriction.restrictionDegree{DegreeTypedegree；}enumDegreeType{More，Most，Less，Least，Same，High，Low}于是，DegreeType枚举的值表示对形容词短语的含义的各种可能的限定。该degree字段设置成适当的值。在某些情况下，希望通过同时检索子句否定和高级类型副词来识别DegreeType的低值。例如，表达式“notverybig”指的是通过否定词(not)和副词(very)来表示的DegreeType的低值。忽略否定词会导致对话语的不正确的解释。表28例示出可使用degree约束来建模的示例性短语。表28暗含Degree约束的示例性短语英语Morebigger，morerelevantMostbiggest，mostrelevantLesslessrelevant注意smaller并被建模成″lessbig″而是″moresmall″。LOM不对标量反义词的任何概念进行建模。LeastleastrelevantSameasbigHighverybig，extremelypopularLownotverybig德语MoregrBer，relevanter，mehrrelevantMostgrBte/n，amRelevantestenLesswenigerrelevant，wenigerwichtigLeastwenigBte/nSamegenauso/ebensorelevantHighsehrklein，extremdickLownichtsehrdick本领域的技术人员将理解到其它Degree约束类型存在于英语和德语中，这种约束类型也同样存在于大多数语言中。可使用几乎任何语言来访问Degree约束。方向(Direction)约束对运动的方向或空间位置的定向进行建模。表29提供了Direction约束及其相关枚举的例子。表29Direction约束和相关枚举restrictionDirection<landmark＝Entity>{DirTypemyDirType；OtherDirectionTypeother；}enumDirType{Up，Down，Backward，Forward，Around，In，Out，Other}槽的Direction类型(“DirType”)字段可被设置成适当的枚举值。在某些情况下，可能希望其它枚举的值。例如，命令“turn”具有未明确指定的方向；然而“turn”看上去似乎是期待某一方向作为变量。从而，可能希望为“Unspecified”提供枚举值，以便将这种表达式与其它相区分，这取决于实现方式。动词中合并的值可作为新的对象表示而存储在词汇条目上。同样重要的是要理解到Direction约束包括方向的对象(介词短语)和方向副词，与附着位置无关。表30提供了可由Direction约束建模的短语的某些例子。表30由Direction约束建模的示例性短语英语up(up，raise，elevate，increase)down(down，lower，decrease，plummet)forward(advance，proceed)backward(back，backward，retreat，recede，retract)around(rotate)in(insert)out(extract)other(diagonal，left，turn)德语up(hoch，anheben，erhhen)down(runter，senken)forward(vorwrts，nachvorn)backward(rückwrts，zurück)around(drehen.，rotieren)in(einfügen)out(extrahieren)本领域的技术人员将理解到其它Direction约束类型存在于英语和德语中，这些约束类型同样存在于大多数语言中。实例(Example)类型对实体类型、构架或约束的样本进行建模。表31例示出用于每种Example约束类型的语法。表31Example约束restrictionExample<example＝Entity>{}restrictionExample<example＝Frame>{}restrictionExample<example＝Restriction>{}在某些实现方式中，可能希望具有SimilarTo约束用于诸如下述的附属结构Iwanttofindvendors，forexampleVolt.Iwanttofindvendors，Volt，forexample.在另一实施例中，可能希望提供额外的槽用于宾语(thewhat)，对于该宾语，样本是一个实例。例如，短语Thisprogramexemplifiessolidcodingtechnique可能要求额外的槽用于对短语“solidcodingtechniques”进行建模。一般来说，Example约束可被理解为对直喻进行建模。表32提供了可由Example约束建模的某些短语。表32由Example约束建模的示例性短语英语″like″ShowmecarsliketheHondaWhichCEOdanceslikeamonkey？Whatdoesabutterflylooklike？″as″″suchas″德语wie西班牙语como本领域的技术人员将理解到其它Example约束类型存在于英语、德语和西班牙语中，并且这些约束类型同样存在于大多数其它语言中。可使用几乎任何语言来访问Example约束。程度(Extent)约束对实体进行建模，相对于该实体测量空间中某一程度概念。表33例示出Extent约束的语法。表33Extent约束restrictionExtent<extent＝Entity>{}一般地，槽的extent字段设置到对程度的测量进行建模的Entity。在一个实施例中，程度介词短语的宾语是独立于话语中的附属位置的。表34提供了可由Extent约束建模的英语和西班牙语术语的例子。表34Extent约束建模的示例性短语英语along西班牙语porMihermanavaporlacalleSanJuan.目标(Goal)约束对运动的目标(比喻的或实际的)或相对于Entity或Frame的状态改变的最终状态进行建模。表35例示出根据本发明的实施例的Goal约束的语法。表35Goal约束restrictionGoal<goal＝Entity>{}Goal约束可与一个或多个枚举值相关联。例如，字段“DirType”(上述的表29中定义)可以是Goal约束的枚举值，可被设置到适当的枚举值。表36提供了可由Goal约束建模的某些短语。表36由Goal约束建模的示例性短语英语to法语à德语für日语NP-に西班牙语paraHayvuelosparaLaPaztodaslassemanas.本领域的技术人员将理解到其它Goal约束存在于大多数语言中。可使用大多数语言来访问Goal约束。重复(Iteration)约束对动作的重复进行建模。表37例示出Iteration约束的语法。表37Iteration约束restrictionIteration{IterationTypetype；floattimes；}enumIterationType{Count，Never，Rarely，Sometimes，Often，Always}在一个实施例中，Iteration约束可结合于时间(time)约束的Recurrence字段中。一般来说，类型Count的字段表示动作被重复了某一次数(例如do[something]5times)。当该类型具有该值时，字段“times”保持了重复的次数。如果该类型具有其它值，该类型对不表达特定的重复次数的修饰语进行建模。从而，当类型设置为count时，它保持了重复的次数，否则，忽略类型。表38提供了可由Iteration约束建模的某些术语和短语。表38由Iteration约束建模的示例性短语英语5timesneversometimesfrequentlyseldom法语5foisjamaissouventrarement德语5Malnie，niemalsmanchmal，abundzuoftselten日语5回ょくめったに西班牙语5vecesnuncaalgunasveces，devezencuandoconfrecuencia，frecuantementeraramente本领域的技术人员将理解到其它Iteration约束类型存在于大多数语言中。可使用大多数语言来访问Iteration约束。位置(Location)约束对实际或比喻性位置进行建模。表39例示出Location约束的语法。表39Location约束restrictionLocation<loc＝Entity>{}表40例示出可由Location约束建模的术语和/或短语。表40由Location约束建模的示例性术语/短语英语at法语à德语in/bei+DativeEristinderStadt.EristbeiHamburg.日语NP-に本领域的技术人员将理解到其它Location约束类型存在于大多数语言中。可使用大多数语言来访问Location约束。手段(Means)约束对用于为某一Entity或Frame完成某些事的手段或设备。表41例示出Means约束的语法。表41Means约束restrictionMeans<means＝Entity>{}restrictionMeans<means＝Frame>{}本领域的技术人员将理解到其它Means约束类型存在于大多数语言中。可使用大多数语言来访问Means约束。表42中示出可使用Means约束来建模的示例性术语/短语。表42由Means约束建模的示例性术语/短语英语withaknifeemployingaknifeuseaspreadsheetprogrambyarrivingearly法语PP[avec]德语PP[mit]ErschneidetmitdemMesserbenutzen，gebrauchenSUBCL[indem]Ergewinnt，indemerschnellrennt日语NP-でNP-をつかってVP-て量度(Measure)约束对用于Frame或Entity的对象的权重或量度进行建模。表43例示出根据本发明的实施例的Measure约束的语法。表43Measure约束restrictionMeasure<measure＝Entity>{}restrictionMeasure<measure＝Frame>{}本领域的技术人员将理解到其它Mearure约束类型存在于各种语言中。可使用大多数语言来访问Measure约束。表44例示出可用Measure约束来建模的示例性术语/短语。表44由Measure约束建模的示例性术语/短语英语WeightthreepoundsMoney$4，fiftyyenDistance3yardsTimeallday法语WeightdeuxkilogrammesMoneyunfrancDistancecinqkilometresTimetoutelajournée德语WeightdreiKiloMoney4DM.Distance3MeterTimedenganzenTag修饰语(Modifier)约束可被认为是“垃圾箱”(“垃圾堆”)约束，因为它不对语言表达式的语义相干类进行建模。相反，它捕捉“附加语性质”的语义概念。一般来说，Modifier约束可相对于Entity、Frame或Restriction对形容词短语、名词短语、副词短语进行建模。在一个实施例中，modifier槽仅仅设置到从被建模的语义短语的头单词构造的标志牌对象。然而，为了利用LOM，不是必须要求这种实现方式。表45例示出根据本发明的实施例的Modifier约束的语法。表45Modifier约束restrictionModifier<mod＝Denoter>{}一般来说，Modifier约束对任何上下文环境中的语言修饰语的某些类进行建模。虽然任何语言上的修饰语可以成为修饰语，但是Modifier约束仅意指语言修饰语的子集的基本LOM表示。该子集包括多数或所有形容词短语、多数或所有名词短语修饰语和某些副词短语。许多副词短语(时间表达式是一个主要的例子)在其它的更具体的约束中可找到基本的LOM表示。Modifier约束的不通常之处在于它的槽包含denoter对象，而不是Entity、Frame或Restriction。Denoter对象串是修饰语的头单词。这种配置的原因在于虽然语言上的修饰语在语义上是它们的主体(它们所修饰的要素)的单位置的(one-place)起功能作用的东西，并因此类似于构架，但是实际上，它们几乎专门地用作约束。此外，语言上的修饰语几乎不存在于可能出现构架的其它上下文环境中。不是要求麻烦的基于构架的约束语法(按照withMyLargeFrame<this>的某些东西)以及用于每个所希望的修饰语类的构架类型的定义，为修饰语类仅规定Denoter对象并将隐含的约束变量作为语义变量(诸如约束所依附于的主体对象)就足够了。关系子句中的表语形容词以该同一形容词的对应的定语用法相同的方式来表示。因此，“alargefile”and“afilethatislarge”都成为Modifier<large>。对于形容词的这种处理对于诸如日语之类的某些语言来说可能不合适，日语中的形容词语义上不能与动词区别。虽然名词在跨语言方面是非常类似的，名词被映射到SPL实体。虽然动词也在跨语言方面是类似的，但是动词映射到SPL构架。于是，形容词介于名词和动词之间，形容词在跨语言方面不是类似的。语言可被认为是存在于连续体之上的。该连续体的一端上，例如在韩语中，形容词不是真正地与动词分开的词汇类别。在该例子中，形容词仅仅是状态、不及物动词。日语在这一点上类似于韩语，其中形容词语义上表现为类似于动词(虽然它们在形态上不同)。英语和源自拉丁语系的其它语言(例如欧洲语言)将形容词作为不同于动词的类别来对待。在谱的另一端，诸如阿拉伯语之类的语言将形容词作为某一类的名词对待。对于“red”，不是用一个单词，阿拉伯语使用意味着类似于“aredone”的意思的名词，使得短语“thebookisred”成为“thebookisa-red-one”。在某些实施例中，在主语子句中可能存在表语形容词的表现。例如，短语“thisfileispersonal”可以不同于“thisfileistext”的方式来被处理。此外，本领域的技术人员将理解到Modifier约束类型存在于各种语言中。可使用大多数语言来访问Modifier约束。有名(Named)约束提供对主体实体的denoter对象的访问。例如，这允许MyAlias和DL_MyAlias被规格化为单个DLEntity，不用要求创作者对两个不同的约束进行编码。表46例示出根据本发明的实施例的Named约束的语法。表46Named约束restrictionNamed<named＝Denoter>{}restrictionNamed<named＝NamedEntity>{}restrictionNamed<named＝String>{}一般地，Named约束设置到名词短语名或主体实体的denoter对象。在某些实施例中，Named约束可用于提供对有名实体属性的某种访问。在另一实施例中，Named约束合并到Modifier约束中。一般地，Named约束可按需表示已经存在的信息段(例如主体实体的denoter对象)。本领域的技术人员将理解到其它named约束类型存在于各种语言中。可使用大多数语言来访问Named约束。否定(Negation)约束对语义否定或逻辑NOT进行建模。表47例示出根据本发明的实施例的Negation约束的语法的例子。表47Negation约束restrictionNegation{}在某些实施例中，Negation约束可作为单独的约束而存在。在可选的实施例中，可通过“withNegation”子句或“！”(不是算子)来消耗Negation约束。序数(Ordinal)约束对序数词和表示序列中的某一位置概念的其它修饰语(诸如“在前的”)建模。表48例示出根据本发明的实施例的Ordinal约束及其枚举的语法。表48Ordinal约束和枚举restrictionOrdinal{intdistance；ReferencePointrefPoint；}enumReferencePoint{First，Last，Current}一般地，distance字段可设置成离开基准点的有符号的整数距离。可选地，成为First的基准点字段(refPoint)必须指示出非负的距离。0距离值对第一(first)进行建模，1距离值对第二(second)进行建模，依此类推。最后(Last)基准点字段必须具有非正的距离。0距离值对最后进行建模，-1的值对倒数第二进行建模，依此类推。Current基准点距离可保持任何整数值。0距离值对“当前”状态进行建模，1值对“下一个”进行建模，-1值对“前一个”进行建模，依此类推。表49提供了可由Ordinal约束建模的短语。表49由Ordinal约束建模的示例性短语英语first，4thlast，nexttolast，3rdfromtheendprevious，current，next，twoback，twoahead法语premier，4edernier德语erst，4teletzte/r/s，vorletzte/r/snchste/r/s，zwei＿，zweiweiter日语最初，4番目最後，最後から2番目前の，今の，次の，2つ前の，次の次の西班牙语primero，4olast，nexttolast，3rdfromtheendprevio，＿，proximo，dos＿，dosmas本领域的技术人员将理解到其它Ordinal约束类型可存在于各种语言中。可使用大多数语言来访问Ordinal约束。具有的(Possessed)约束对所有物、属性或所有权进行建模，并用作所有人(Possessor)约束(下文描述)的补充。表50例示出根据本发明的实施例的与Possessed约束相关的语法。表50Possessed约束RestrictionPossessed<possessed＝Entity>{}一般地，Possessed约束对所有物、属性或所有权进行建模。例如，短语emailwithheaders、schoolswithlinguisticsprograms等等可由Possessed约束来建模。在某些情况下，Possessed约束可被成为是“具有”属性、所有物或所有权。表51提供了可使用Possessed约束建模的某些示例性术语和短语。表51Possessed约束建模的示例性术语/短语英语withmailwith″conference″inthesubjectlinedocumentwithsizegreaterthanlkoffilesofgreatersize德语RELCLMail，die″Treffen″inderBetreffzeilehatmitMailmitAnhang本领域的技术人员将理解到其它Possessed约束类型可存在于各种语言中。可使用大多数语言来访问Possessed约束。所有人(Possessor)约束是Possessed约束的补语或补充。一般地，Possessor约束对实体的所有者进行建模，可由全名词短语或所有格代名词来表达。表52例示出根据本发明的实施例的Possessor约束的语法。表2Possessor约束restrictionPossessor<possessor＝Entity>{}表53提供了可由Possessor约束建模的示例性术语/短语。表53Possessor约束建模的示例性术语/短语英语my，your，her，his，its，theirofmine，ofyours，ofhers，ofhis，ofits，oftheirs(wheel)ofthecarKim′s，thecomputer′ssomeinstancesofPP[of]′s法语mon，son，ta，sa，leurdemoi，detoi，delui，d′euxsomeinstancesofPP[de]′s德语mein，dein，sein，ihr，IhrsomeinstancesofPP[von]someinstancesofgenitivecase日语私の，彼の，彼女の，あなたのsomeinstancesofNP-の本领域的技术人员将理解到其它Possessor约束类型可存在于各种语言中。可使用大多数语言来访问Possessor约束。LOM中建模的另一个约束是目的(Purpose)约束。Purpose约束对关联到Frame的预期的结果进行建模。表54例示出可由Purpose约束建模的某些示例性短语/术语。表54Purpose约束建模的术语/短语英语for，inorderto法语pour，afinde；desorteque；desorteà；defaconà德语um...zusodass西班牙语para，paraque，conobjetode，conelfinde原因(Reason)约束对与构架或实体相关联的信心或动作的合理动机进行建模。在一个实施例中，Reason约束和Purpose约束可在范围上重叠。表55例示出可由Reason约束建模的示例性术语/短语。表55由Reason约束建模的术语/短语英语because，inorderto法语parceque；àcausede；enraisonde德语fuerweilwegen西班牙语por，porque，acausade.Reason约束和Purpose约束都可在任何数量的语言中建模。上述列出的示例性术语/短语不应被解释成穷尽的列表，而是例示出可由这些约束建模的示例性术语。排序次序(SortOrder)约束对描述数据排序的形式和/或方法的修饰语进行建模。表56例示出SortOrder约束及其相关枚举OrderType的语法。表56SortOrder约束restrictionSortOrder{OrderTypetype；OrderCriteriacriteria；}enumOrderType{Default，Reverse，Increasing，Decreasing}enumOrderCriteria{DefaultAlphabetic，Numeric，GoJuuOn，Iroha}一般地，该字段类型可以是默认、反向、字母、数字、递增、递减等等。默认类型以默认顺序、任何顺序等进行建模。反向类型以反向顺序(后向)进行建模。字母类型按字母表顺序(字母表顺序)进行建模。数字类型按照数字顺序(数字顺序)进行建模。递增类型以递增顺序进行建模。递减类型以递减顺序进行建模。根据实施方式，对于类似于“alphabeticallist”(字母列表)之类的，可把SortOrder约束设置在实体上。此外，可通过SortOrder约束对诸如“alphabetize”(按字母表顺序排列)、“categorize”(归类)、“group”(分组)、“classify”(分类)以及“index”(索引)之类的动词进行建模。在某些情况中，可能希望包括两个字段，用于对类似于“reversealphabeticalorder”、“decreasingalphabeticalorder”等等之类的短语进行建模。而且，对于两种不同的语言，可能共同存在不同的排序顺序。虽然表56中列出的枚举对于英语语言来说是共有的，但是日语可具有为该语言所共有的其它排序顺序。表57例示出可由SortOrder约束建模的示例性短语/术语。表57由SortOrder约束建模的术语/短语英语indefaultorder，inanyorderinreverseorder，backwardsalphabetically，inalphabeticordernumerically，innumericorderinincreasingorderindecreasingorder法语dansl′ordrepardéfaut；dansn′importequelordreparordreinverse；enordreinverse；dansl′ordreinversealphabétiquement，parordrealphabétiquenumériquement，parordrenumériqueparordrecroissant；parordreascendant；parordredécroissant；parordredescendant德语[Babel]imRückstellungAuftrag，inirgendeinemAuftragimRückauftrag，rückwrtsinderalphabetischenReihenfolge，alphabetischimnumerischenAuftrag，numerischinzunehmendemAuftraginabnehmenderReihenfolge日语デフォルトの順序で，好きな順にdefault-no-order-de，favorite-order-ni逆の順序で，逆にor反对にreverse-no-order-dereverse-niopposite-niアルフアベツト順にorABC順にalphabet-order-niABC-order-ni数字順にnumber-order-ni小さい数字順にor低い数字順にsmall-number-order-nilow-number-order-ni大きい数字順にor高い数字順にlarge-number-order-nihigh-number-order-ni西班牙语ordenadospordefecto，enelordenpordefecto，encualquierordenenordeninverso，alrevésenordenalfabético，alfabéticamenteenordennumérico，numéricamenteenordenascend(i)ente，demenoramayorenordendescend(i)ente，demayoramenor源(Source)约束对对象的源或起源进行建模。表58中示出了Source约束的语法。表58Source约束restrictionSource<src＝Entity>{}一般地，本领域的技术人员将理解到对于多种语言来说，各种Source约束可存在。结构准则(StructureCriteria)约束相对于Frames对以结构化的方式对一组对象进行操作的概念进行建模。StructureCriteria约束对操作进行所依赖的标准或准则进行建模。表59示出用于StructureCriteria约束的语法。表59StructureCriteria约束restrictionStructureCriteria<criteria＝Entity>{}在LOM的某些实现方式中，可能希望包括用于对诸如“inpairs”、“5atatime”等之类的短语进行建模的称为“increment”(增量)的约束。这些类型的短语包含可精细地规范化的数字标准，根据该实现方式，这足够重要以便包括用于对它们进行建模的专门方式。表60例示出可由StructureCriteria约束建模的某些术语和短语。表60.由StructureCriteria约束建模的术语/短语英语sortbysubject，listbydatedisplayinrowstransmitin1KBblocksgetmyemailoneatatime德语sortierennachThemaanzeigensenden/schickan代替“Substitution”约束对一项替代另一项的语义环境中的参与者进行建模。在法语中，一个可能的例子是，用于pour的替代作为附属(adjunctive)。附属是一种类型的状语，表示出动作的环境。类似地，在西班牙语中，por用作附加语，para可与选定的动词一起使用。可把时间(Time)作为约束来对待。一般地，Time约束对涉及对可表达为实体的特定时间单位或时间点的引用的时间修饰语进行建模。例如，“afterJuly23rd”和“afterThanksgiving”可由Time约束来建模。然而，在某些实施例中，诸如“aftermycomputerbootsup”之类的短语不由Time约束来建模。类似地，诸如“from3:00to6:00”和“betweenmorningandevening”之类的时间范围可由Time约束来建模。然而，“whilethedefragutilityisrunning”可以不由Time约束来建模。在Conditional约束中处理包含嵌入的子句内容的时间表达式。表61例示出LOM中的作为约束的时间的语法和实现方式。表61Time约束restrictionTime{BaseTimestartTime；BaseTimeendTime；BaseTimepointorSpan；Durationduration；TimeLengthrecurrence；}abstractclassBaseTime{}abstractclassAbsoluteTimeBaseTime{}classNowAbsoluteTimeAbsoluteTime{}classAnalyzedAbsoluteTimeAbsoluteTime{intsecond；intminute；inthour；intdate；intweek；Weekdayweekday；Monthmonth；Intyear；Eraera；AmPmampm；}enumWeekday{Unspecified，Monday，Tuesday，Wednesday，Thursday，Friday，Saturday，Sunday}enumMonth{Unspecified，January，February，March，April，May，June，July，August，September，October，November，December}enumEra{Unspecified，BCE，CE，Heisei，Showa，Taisho，Meiji}enumAmPm{Unspecified，Am，Pm，TwentyFourHour}classUnanalyzedAbsoluteTimeAbsoluteTime{DenotertimeExpression；}abstractclassRelativeTimeBaseTime{BaseTimerelativeTo；}classoffsetRelativeTimeRelativeTime{Offsetoffset；}classOffset{Directiondirection；TimeLengthtimeLength；Granularitygranularity；}enumDirection{Unspecified，Forwards，Backwards，}enumGranularity{None，Seconds，Minutes，Hours，Days，Weeks，Months，Years，Decades，Centuries，Millenia}classTimeLength{floatamount；TimeUnitunit；DenoterotherUnit；}enumTimeUnit{Other，Minutes，Hours，Days，Weeks，Months，Years，Decades，Centuries，Millenia，Mondays，Tuesdays，Wednesdays，Thursdays，Fridays，Saturdays，Sundays，Januaries，Februaries，Marches，Aprils，Mays，Junes，Julys，Augusts，Septembers，Octobers，Novembers，Decembers}classSubsetRelativeTimeRelativeTime{AbsoluteTimesubset；}classDuration{TimeLengthtimeLength；TimeLengthQualifierqualifier；}enumTimeLengthQualifier{None，MoreThan，LessThan，AtLeast，AtMost，Precisely}Time约束可按需利用一个或多个字段和大量的辅助数据类型。字段可包括starttime(起始时间)、endtime(结束时间)、“pointorspan”(点或跨度)、duration(持续期)、以及recurrence(再现)。starttime字段设置成得自基本时间的对象，表示时间跨度的起始点，例如“from5:00”或“aftertomorrow”。如果starttime字段是空的，则建模的时间修饰语不包含起始点的明显表达式。endtime字段设置成得自基本时间的对象，表示时间跨度的结束点，例如“to6:00”或“untilFriday”。如果endtime字段是空的，则建模的时间修饰语不包括结束点的明显表达式。pointorspan字段设置成得自基本时间的对象，表示以单个短语表达的单个时间点或跨度，这与明显地给出起始点和结束点的时间跨度相反。例如，相对于“tomorrow”来说，概念是“tomorrow”是时间线上的单个时间点还是24小时的时间跨度这取决于上下文环境和观察者的角度。LOM不试图解疑该术语。如果pointorspan字段是空的，则建模的时间修饰语不包含单个时间点或跨度的明显表达式。duration字段可设置到表示时间跨度的长度而不是表示特定的起始和结束点的持续期对象。例如，短语“fortwohours”可由duration字段来建模。如果是空的，则建模的时间修饰语不包含明显的持续期表达式。在时间跨度内隐含的持续期，例如“from4pmto6pm”不被表达为duration对象。在该情况下，对于starttime和endtime将没有非空值，但是duration将为空。recurrence字段设置到表示再现事件的发生之间的事件间隔的事件长度对象。例如，诸如“daily”、“weekly”、“monthly”、“thefirstMondayofeverymonth”等等的可被表达为事件长度对象。如果为空，则事件修饰语不被解释为复现。一般地，Time约束利用大量的辅助数据类型。例如，BaseTime链是从BaseTime(基本时间)得出的对象，由RelativeTime(相对时间)得出的0个或多个对象以及从AbsoluteTime(绝对时间)得出的确切的一个“root”(根)对象组成。它们被称为是“链”，因为每个得自RelativeTime的对象保持着对链中下一对象的引用，得自AbsoluteTime的对象，根，不保持这种引用。得自AbsoluteTime的类型，例如NowAbsoluteTime(现在绝对时间)不保持对链中的其它对象的引用。NowAbsoluteTime得出的类型，例如表示话语的语音时间的不可分析的“now”(现在)。LOM不试图将“now”解析成例如2002年10月24日下午3点42分27秒。AnalyzedAbsoluteTime(分析绝对时间)是得自AbsoluteTime的类型，表示可按照秒、小时、日、年等进行分析的时间点或跨度。例如，可使用AnalyzedAbsoluteTime来将时间点“now”表示为3点45分、2003年5月10日、星期三上午9点30分。UnanalyzedAbsoluteTime(不分析绝对时间)是得自AbsoluteTime的类型，表示已知为时间点但不能按照原子时间单位来分析的表达式。例如，假期(holiday)、年中的季节、以及抽象的临时概念都趋向于落入该类别。例如，“Thanksgiving”、“ElectronDay”、“mybirthday”、“summer”、以及“thisevening”都是建模成UnanalyzedAbsoluteTime的短语。存在两种得自RelativeTime的类型OffsetRelativeTime(偏移相对时间)和SubsetRelativeTime(子集相对时间)。OffsetRelativeTime表示离开引用的得自BaseTime的对象的某一时间长度的正的或负的偏移。例如，短语“twodaysago”被建模成“[2daysback]OFFSETFROM[now]”。SubsetRelativeTime是得自RelativeTime的类型，表示被解释为由引用的得自BaseTime的对象表达的密封的时间跨度的子集的时间点或跨度。例如，诸如“at5:00onmybirthday”之类的时间量度的表达式可被建模成相当于“[hour5min0]SUBSETOF[“mybirthday”]”。重要的是要注意到诸如“5:00onWednesday”之类的时间基准可由单个AnalyzedAbsoluteTime对象来捕获，因为该短语可被解析成时间单元。在某些实施例中，可能希望具有不止一对StartTime和EndTime字段。例如，为了捕获诸如“fromMondaytoFridayfrom4:00to5:00”，可能希望两对起始和结束时间，以便捕获两个范围。实际上，对于上述的表达式，可能希望具有Time实体。此外，暗示出Time实体的下述表达式之间的对比关系可能是希望的。Movethemeeting[from4:00to5:00].Movethefile[fromFolder1]source[toFolder2]Goal.此外，EndTime应与原始的目标(Goal)相区分，因为并非所有采用Sources和Goals的结构都允许StartTime和EndTime如此发挥作用。例如，适用于对表达式“Runameeting[from4:00to5:00]”建模的结构可能不允许StartTime和EndTime适当地起作用。另一个约束是Topic(题目)约束。就Entity对象来说，Topic约束对表示实体是关于什么的或实体涉及或隶属于什么的变量进行建模。与Frame相关联的Topic约束对表示事件的主题或题目的动词变量进行建模。一般地，Topic约束具有设置到Entity或Frame的Slot，对题目或主题进行建模。可选地，Slot可采用串。表62例示出根据本发明的实施例的Topic约束的语法。表62TopicRestriction.restrictionTopic<topic＝Entity>{}restrictionTopic<topic＝Frame>{}在某些情况下，可能希望用不同的名字来标记Topic约束。具体来说，已知术语“topic”的严重负载(至少在语言范围内)，可能希望使用其它标记用于该约束。某些可选的标记可包括例如“Concerning”、“Regarding”、“About”、“Subject”、“Theme”等等。表63提供了根据本发明的实施例可由Topic约束建模的某些示例性术语/短语。表63由Topic约束建模的示例性术语/短语ENGLISHabout，onconcerning...，regarding...remindSandythatKiniscomingtomorrowGERMANüberZeigedieMailüberdenHausbau.+GenetivecaseZeigeMailbzgl.desHausbaus.JAPANESENP-につぃてのNPNP-につぃてVPQuantifier(数量词)约束对名词短语数量词和诸如two-thirdsof(三分之二)之类的表示部分的表达式进行建模。一般而言，Quantifier约束可包括类型(type)或百分比(percentage)字段。type字段可以是百分比，按照浮点数来存储，一般(但非必须)介于0和1之间。例如，百分比类型对onehalfof、75％of、200％increase等等进行建模。术语“all”(全部)和“none”(没有)作为不同“特权”值来枚举，它们不落在这个“other”类型中。如果类型具有Percentage值，则percentage字段保持着对应于数量词的含义的百分比。否则，忽略percentage字段。表64例示出Quantifier约束及其相关枚举的语法。表64Quantifier约束restrictionQuantifier{QuantifierTypetype；Floatpercentage；}enumQuantifierType{All，None，Some，Most，Many，Few，Percentage}在某些实现方式中，可能希望以不同的方式处理否定。不是对诸如“none”之类的术语进行枚举，而是可能希望将否定按照名词短语来处理。表65例示出可由Quantifier约束建模的某些示例性术语/短语。表65由Quantifier约束建模的术语/短语ENGLISHAllall((of)the)，every，each(ofthe)Noneno，none(ofthe)Somesome(ofthe)Mostmost(ofthe)，themajorityofManymany(ofthe)Fewfew(ofthe)，notmany(ofthe)Percentageahalfof，1/3of，40％ofGERMANAllalle(Gen)，jede/r/sNonekeine/r/s(Gen)Somemanche/r/s(Gen)Mostdiemeisten(Gen)，derGroBteil(Gen)Manyviele(Gen)Fewwenige(Gen)PercentagedieHlftevon(Gen)，1/3von/(Gen)，80％von/(Gen)本领域的技术人员将理解到上述关于示例性术语和短语的讨论仅仅是例示出域和语言独立性，而不是说明对语言建模的任何特定限制。一般来说，LOM可对任何数量的语言进行建模。D4.Frames类词汇语义结构下面的讨论涉及到LOM对象产生者(分析引擎)的可能实现的一个方面，称为词汇语义结构(LSS)。该特定方面连同LOM一起来详细说明，但是可利用许多其它的实现方式来产生LOM对象。LSS也还用于LOM的类型的设计处理。词汇语义结构(LSS)基于关于用于跨语言和跨语言类别的自然语言输入的规范化的跨语言行为和子语言捕获的一般化。该LSS提供了一种用于用于将自然语言的元素映射到词汇语义类的方法。一种此类应用可能包括将表示自然语言输入(语言话语)的词汇语义结构映射到语言对象模型(LOM)。LSS包括一组词汇语义类别，以及一种方法用于将自然语言输入分配给该组词汇语义类别中的一个或多个。该组词汇语义类别中的每个类别意味着自然语言输入的元素对语义类别和语义角色库存清单(inventory)的映射。更为具体地，每个类别意味着一个或多个语义类别对一个或多个语义角色的映射。如这里所使用的，术语“语义类别”指的是句子的结构化元素(例如主语、宾语、介词短语、子句补语、修饰语等等)。短语“语义角色”指的是某一话语内的某一语义类别的功能的标识——例如，注意—般分配有角色“who”(agent(主动者)、actor(参与者)、doer(做...的人)、或动作的原因等等)，直接宾语是“what”(patient(患者)、affected(受影响者)、done-to(对某人或某物做)、或动作的效果等等)，修饰语可具有各种角色(source(源)、goal(目标)、time(时间)等等)。应理解到，上面给出的例子用于示例性的目的，而非具有排他性。最后，如这里所使用的，术语“规范化(动词)”或“规范化(名词)”指的是从某一语义表示中抽出语义角色的过程。库存清单和语义得自于跨语言行为和子语言捕获，并且基于自然语言的词汇语义特征共享某些特性的一般化总结。按照语言锚定(anchoring)和语义细节，LSS位于根据通用知识从语言移动到语义推论的人工智能系统和对明显的同义词之间的区别进行建模的更为精细的词汇分析框架之间。换言之，所有的语言具有能够按照默认方式被映射的语言结构。此外，每种自然语言具有语法类别到语义角色的多种非默认的映射。这些具有比主语和宾语更多有原因地关系上远的语义角色的非默认的类更为少有。默认词汇语义结构对诸如Johnbroketheglass之类的及物句进行建模，如上通过将该句的主语分类为“Who”和将宾语分类为“What”来进行。修饰语以表示因果链的时间展开的顺序(或语形学上的情况标记(casemarking))来标识。换言之，修饰语得自于由额外的情况标记(间接宾语)和诸如介词短语之类的副词修饰语扮演的语义角色。在短语Johnbroketheglassforme中，John是主语；theglass是宾语；以及短语“forme”被标记为更接近于该句的宾语的间接宾语。默认的不及物语句通常包括主动者或“Who”。例如，短语Johnran包括主动者“John”。较不普遍的情况是，单个变量是患者(Patient)。例如，在短语Theglassbroke中，短语“theglass”受到影响，该语句可以按照原句为[Something]broketheglass的方式来建模。对于要被包括在LSS库存清单中的语义角色，它必须在某个语言中表现为语法类别，并且跨越某一范围的名词和动词类而作为变量或修饰语运用。因此，角色具有语言锚定和语义通用性。例如，短语“theoffice”是下面各个例子中的源(Source)1.Johnlefttheoffice.2.Theofficeemittedsmoke.3.Johnwentoutoftheoffice.4.Themanfromtheofficecalled.在每个情况中，根据动词类及其在语义/语法测试方面的行为来识别源。参考例子1，源是该类中的动词的宾语。动词“left”和及物动词“toleave”(以及尤其是“toexit”)不能采用其它源。例如，Johnleftthehouseoutoftheyard并不意味着“Johnwentoutofthehouseandoutoftheyard”。在例子2中，根据由“emit”例示出的动词类在类似的语义/语法测试发面的行为，“theoffice”是句子的主语。在上述的例子3和4中，介词“outof”和“from”的语义一般将源角色分配给它们的宾语。LSS是一组词汇语义类别和一种用于将自然语言输入关联到该组词汇语义类别中的一个或多个类别的方法。该方法包括用于将自然语言的内容关联到该组词汇语义类别的过程集合，以及用于将该过程集合运用于自然语言输入的规则。如这里所使用的，术语“方法”指的是用于将自然语言输入的内容关联到该组词汇语义类别的过程集合。每个词汇语义类别包括一个或多个语法类别、一个或多个角色、以及一个或多个语法类别和那些变量在话语中所扮演的相关的一个或多个角色之间的映射。此外，“方法”涉及用于将该组过程集合运用于自然语言输入的规则。在某些情况下，“方法”可包括用于确定自然语言输入的内容的映射的不同阶段何时完成的推断法。术语“方法”包括用于将自然语言输入的内容关联到和/或规格化成该组语言类别的一个或多个语言类别的技术、规则和过程的集合。作为规格化结构，LSS帮助跨语法类别来识别语义角色(动词的主语/宾语、修饰动词的介词短语的宾语等等)。而且，LSS使得跨语言将语法类别语语义角色相关联成为可能。该规格化是通过识别语法类别的类的变量以及它们的语义，并通过将所识别的变量关联到适当的词汇语义类别来实现的。于是可从某一语法表示中抽出词汇语义结构。与语言对象模型和语义编程语言(及其相关用户模式)相结合，降低了许多语言类别中的语义多义性。例如，介词“for”标识了动作的受益人(Beneficiaries)(Iboughtadressformydaughter)，目的(Purposes)(IgotoCaliforniaforthebeaches)，时间范围(TimeExtents)(Iwenttoschoolfor20years)，目标(Goals)(presentformydaughter)，等等。然而，在一给定应用中，仅有限的一组可能性与上下文有关。因此，通过上下文消除了许多语义岐义性。图11是根据本发明的实施例的说明词汇语义结构(LSS)1100的概念框图。LSS1100包括一组词汇语义类别1102和用于将自然语言输入1106的元素映射到词汇语义类别1102的方法(过程和规则)。在所示的实施例中，表示自然语言输入1106的映射的元素可随后被提供给分析引擎1108，用于映射到语言对象模型(LOM)1110以产生代表自然语言输入1106的LOM对象1112。本领域的技术人员应该理解到该方法不仅适用于运行时间，而且适用于设计时间如何开发LSS类的方法。更为具体地，虽然LSS适用于运行时间的自然语言处理，用于跨语言、跨语言类别、跨分析引擎等等对自然语言输入进行映射，但是词汇语义结构还传达了设计时间LSS类的程序代码。一般地，LSS识别共享语法和语义构架的构架和实体组，不同于所支持的语言之一中的默认模式。一般而言，词汇语义是语言的子域，它主要涉及单词含义。词汇语义结构(LSS)理论涉及单词含义到句子含义和语法的关系。此外，LSS理论着重解决不同语言之间的词汇语义结构中的差异和相似性。一般地，Frames具有两个默认模式及物默认模式和不及物默认模式。及物默认模式将Who槽链接到主语位置，以及将What槽链接到宾语位置。相反，不及物默认模式缺少What槽和宾语位置。通过下面的由动词type开头的例子来例示。Whotypes[emailaddress]What.Whotypes.Frames可在链接(构架的槽如何按语法来填充)和变量结构(槽数量)中与默认不同。例如，在一个非默认链接类型中，Unaccusative(非宾格)动词类具有用于不及物模式的不同链接模式，如下面的以动词increase为开头的构架中所见那样。Whogenerallyincrease[thefontsize]Whatofheaders.Whatgenerallyincreasesinheaders.在该情况下，不及物动词的主语与及物动词的宾语相同，并链接到What槽。在语言中，这些非宾格非默认链接类型有时被称为“主动格”动词，在某些语言中，位于它们的情况标记模式之后。这些动词除了默认链接模式之外，还产生不及物的额外的非默认链接模式。在另一个非默认链接类型中，ObliqueAsDefault动词类将Who或What变量表示为间接变量。例如，英语中的相互补足语(reciprocals)将另一个Who或What参与者表达为Accompaniment约束的对象。AdditionalWhoIchattedwithJohn～JohnandIchatted.AdditionalWhatImergedfileAwithFileB～ImergedFileAandB.其它语言将相互补足语表达为另一个代名词变量，意味着涉及代名词或标识或规定宾语而不描述宾语的变量。这些同样在Accompaniment约束下得到处理。许多动词具有语义上间接的变量(由特殊介词标记)，看上去语义上与What槽相关联。也就是说，如果动词是不及物的，且介词短语语义上不落于约束类别之一中，且该短语可以被解释(或翻译成另一语言)成直接宾语，则可按照链接到What槽来处理。表66中提供了例示出按照默认槽来触发Oblique的短语的若干例子。表66ObliqueasDefault.JuanconfíaenPedro->′JohntrustsPeter′I′mwaitingforMSN8->I′mawaitingMSN8.Lookforfilesontheinternet->Findfilesontheinternet.这些可与语义上相干的类(hopefor，watchfor，waitfor)相关联，或可在如此采用某一介词的一组动词上单独标记出它们，作为分类的格标(casemarker)(例如findandlookfor)。动词类可通过在构架中具有除了(或代替)Who和What的槽来与默认不同。而且，某些动词类将语法主语或宾语链接到LOM中的约束，而不是链接到Who或What槽。换言之，任一默认槽或两者都可被约束替代。SubjectAsRestriction模式将主语链接到约束，而不是链接到What槽。例如，动词“receive”将Goal作为主语。Goalreceivedthedata.swarmedwithbees.～Beesswarmedinthegarden.类似地，ObjectAsRestriction模式设计出这样一个构架，其中语法宾语是Goal而不是What。例如，动词“enter”映射到一构架，其中语法宾语是Goal或位置，而不是what。Enter[thechatroom]Goal(cf.Enterin(to)thechatroom，Gointhechatroom)构架(Frames)也可在语义上使一个或多个额外的约束成为间接的方法中不同于默认。除了默认槽之外，AdditionalRestriction模式将额外的约束链接为间接变量或子句补语。例如，改变情况动词可采用额外的Goal(例如用动词“reset”)，或能够同时采用Source和Goal(例如用动词“change”)，如下所示。Reset[thedefaultfont]What[toTimesNewRoman]Goal.Change[thefont]What[fromArial]source[toTimesNewRoman]Goal.此外，构架可以各种方式不同于默认，例如通过将上述非默认的链接类型(Unaccusative、SlotAsRestriction[主语或宾语]以及AdditionalRestriction)中的一个或多个相组合。而且，动词可提出多个构架，可被解释为采用不同的意义。默认构架适用于“enter”的一个意义，而SlotAsRestriction适用于另一个。动词“enter”可以是对上下文敏感的。Enter[thedata]What(intotheform).Enter[thechatroom]Goal关键字“Keep”采用默认和三种非默认构架，具有不同的意义。例如，DefaultKeep[thefile]WhatAdditionalRestriction(Location)Keep[thefile]What[onthedesktop]Location.AdditionalRestriction(Goal)Keep[BillGates]What[fromemailingme]sourceUnaccusativeThedatawon′tkeep.一般地，希望跨所有支持的语言，对于在至少一个语言中不同于默认的动词，都具有词汇语义结构构架。出于本揭示的目的，假设这对于及物动词和不及物动词都是真的。对于某些动词(例如“expand”、“increase”等等)，对于不及物来说仅unaccusative模式是有效的。对于其它动词，unaccusative模式链接是一额外的选项。表67例示出可由LSS构架利用额外的约束来建模的某些示例性短语/术语。在每个例子中，约束替代默认变量，或将变量添加到构架。原则上，每个约束可出现在主语位置、宾语位置或作为额外的间接变量。如下所示，一些约束将参与者添加到Who和What槽。还给出了相关的名词短语(NP)构架。表67LSS构架用额外的约束建模的AccompanimentAccompanimentInsubjectpositionMeetMydaughterandImetChatMyfriendandIchatted.InobjectpositionAccompanyMydaughteraccompaniedmetoMinneapolis.英语中，该额外的约束通常以代名词“with”或可能以“against”为开头。各种动词子类对相关的含义选择该代名词或代名词短语。表68中给出了一个样例。表68具有额外约束的LSS构架AbscondTheEnronexecutivesabscondedwiththemoney.()AccommodateindulgeAccreditaccredit，creditAcheache，burn，itchArrange英语中，Accompaniment约束还可将参与者添加到Who和What槽。虽然这对于该约束是修饰语的构架来说是真的，但是就“相互补足的”动词而言，它尤其是普遍的。表69提供了Oblique作为默认槽的某些例子。表69Oblique作为默认槽WhoSubjectreciprocalsChatIIMedwithMary～MaryandIIMed；chat，discuss，talk，visitAgreeAlternateUnaccusativesThefilemerged(together)withthedata～Thefileandthedatamerged(together).WhatObjectreciprocalsMergeImergedthefileswiththedata，ImergedthedataandthefilesAcquaintIfamiliarizedthemwiththetopic；acquaint英语中，该额外的约束以介词短语(PP)“for”相对于Allocation为开头。各种动词子类对相关含义采用该PP。下面给出样例。AdaptAdaptthemovieforthestage.AllocateAllocatefundsforlinguistics；allocate，appropriate，AppropriateAppropriatefundsforincreasedwagesAssignAssignadayfortheperformanceNominateNominatecandidatesforcongressTranscribeTranscribethemusicfortrumpetTrainTrainforamarathon可使用关于AsBeing约束的第二谓语作为额外的约束。表70中给出了某些示例性短语。表70AsBeing约束的第二谓语名词短语Makemeadministrator形容词短语markmessageslow-priorityjudgethedatacorrectmarkthatcompletedmarklowpriorityjudgethedatacorrect代名词短语(as)变量marktaskoneasdoneMarkmessagesasfollow-upmarkthatascompletedmarkaslowpriorityjudgethedataascorrectAdditionalrestrictionShowmystatusasbusyuseastextfilesaveasfile.docLoginasAdministratorputthismessageasmessagenumbertwo表71示出关于Beneficiary约束的额外的约束。表71具有额外的约束的Beneficiary宾语位置中BenefitRelaxedstockoptionlawsbenefitedEnron；benefit，gain，profitUnaccusativeEnronbenefitedfromrelaxedstockoptionlaws间接宾语位置中BenefitRelaxedstockoptionlawsbenefitedEnron；benefit，gain，profitUnaccusativeEnronbenefitedfromrelaxedstockoptionlaws额外约束PP-forandIndirectObjectBuildarrange，assemble，bakeCreatedesign，dig，mintPreparebake，blend，boil，clean，clear，cook，fix，fry...Performancedance，draw，ding，play，recite...Getbook，buy，call，cash，catch某些约束类型可不适用于动词构架。然而，仍可调用额外的约束，例如在介词短语引入比较组时。Direction约束可要求额外的约束，利用用短语“movethecursorup(thepage)”。此外，在方向元素合并于动词本身的情况下(例如“thestocksrose/fell/advanced/retreated”或“rotatethepicture”)，可要求额外的约束。可从下面的短语中理解具有额外的约束的LSS，示例性的约束包含于主语位置中。ThisdocumentexemplifiestableconstructionSamplecodeillustratespossibleapplications.Extent约束一般落于宾语位置或额外的约束位置内。可能的是所有方式的运动类型的动词可采用Extent对象(例如“walkthemall”、“crawltheweb”、“runthemarathon”等等)。表72中示出了可由Extent约束建模的示例性短语。表2由Extent约束建模的短语的例子宾语位置中Thecrawlertraversestheweb.Thedatainthisspreadsheetspansseveralbuilds.额外的约束Iwantaborderaroundthistext.Maintainauniformappearancethroughoutthewebsite.Runthroughthespecbeforethereview.Goal约束可要求额外的约束，特别是关于类或状态之间的改变方面。用某些动词特殊地表现为目标的介词短语的范围可按照实现方式而改变。特殊地表现为Goal的介词短语的例子是“saveasfile.txt”(“savetofile.txt”)和“reschedulefor5:00”(“rescheduleto5:00”)。在Bitrecs(如果Goal行为是由于单个动词)或LSS类(如果一类项目特殊地采用目标)中，某些动词可能需要采用特殊的目标。可简单地添加额外的目标，并且可从词典中将模式提入类中，以把它们称为它们被发现。如表73所例示的那样，可对与位置相关联的额外的约束进行建模。表73位置Keep，Stand，CausedGoalOfMotion主语位置Locativealternation(Levin2.3)Thegardenswarmedwithbees(cf.Beesswarmedinthegarden)宾语位置SearchCanvasstheneighborhood，Searchtheweb额外的约束TransitiveKeepKeepthefileonthedesktop(hold，keep，locate，store)GetFindabookonAmazon.comIntransitiveStayStandhere，StayhomeMeans约束也可用额外的约束来建模，如表74所示。表74Means工具主语Theknifecutthecake额外的约束Adornadorn，festoon，decorateAdulterateadulterate，alloy，polluteAnointAfflictAidaid，assist，helpAnalogizeAnointAnswerArmAssailattack，SortOrder约束可由额外的约束来建模，如表75所示。表75SortOrder.英语ArrangealphabeticallyAdditionalrestrictionArrangesortalphabetically，法语parordrealphabétiqueinversedupluspetitauplusgrand[literallyfromthesmallesttothebiggest]duplusgrandaupluspetit[literallyfromthebiggesttothesmallest]类似地，结构准则StructureCriteria约束可由额外的约束来建模，如表76所示。表76StructureCriteria英语Arrangebyname(cf.SortOrderabove)，indateorder法语{catégoriserclasserclassifierfiltrergrouperindexerordonnerregrouperréarrangerréindexertrier}Classelesmessages{parordrealphabétique，alphabétiquement}′Sortthemessages{inalphabeticalorder，alphabetically}′Regroupemoncourrierpardate′Group/clustermymailbydateTrielesfichiersenfonctiondelataille′Sortthefilesbysize/asafunctionofthesize′Indexelatablesurlenom′Indexthetableonthename′一般地，采用Time变量的类可作为采用类型Time的Measure约束的类来对待，虽然它们可实现完整时间表达式。例如，下面的短语可被建模成采用时间变量或类型Time的measure约束的类“Ispentatleastanhourfrom9to5everydayforweekslookingforapiano”。表77例示出可用额外的约束来建模的某些示例性Topic短语。表77TopicSpacttalkaboutX，talkX，remindXthatY，bookonMartinLuther主语位置Herfinancesdon′tconcernyou；concernInobjectpositionDiscussThearticleaddressesadolescentsinthe20thcentury；address，cover，discuss额外的约束PP[{about，concerning，on，regarding}]takeseitherNPobjects(aboutcats)orclausalobjects(aboutJohncomingtoSeattle)PRPRTCLTheobjectofaddresscouldalsobetheaddressee，ratherthanthetopic.D5.实体类该部分提供了在按照SPL库被支持的实体类型上收集数据的位置，例如Person实体、Place实体和LSS实体。此外，SPL库可包括对应于每个LSS构架类(特别是那些采用额外的约束)的名词短语类(LSS实体)。SPL库还可包括Restriction(约束)类。对于每个约束，存在一(小)组可用于命名约束的名词短语。在SPL中，可在一小组结构中将这些识别为表示约束槽填充物的存在。例如，当topic是主语或宾语或系动词时，Topic约束槽填充物(粗体表示)位于补足语位置。Finddiscussionswheretheeconomyisthetopic.Finddiscussionswherethetopicistheeconomy.类似地，当topic填充AsBeing槽时，它所依附的实体填充Topic槽。Finddiscussionsthathavetheeconomyasatopic.这些结构应连同那些被识别为Topic约束的结构一起被规格化。Finddiscussionsabout/on/concerning/regardingtheeconomy.例如theme、matter、subject、issue、focus以及area之类的同义词也可以是TopicEntity。而且，开发者可以将更为特定于其场景的topic词添加到实体类中，例如“subjectinanemailapplication”。E.语义编程语言(SPL)E1.架构SPL是专门化的编程语言，具有伴随的运行时间平台，允许应用程序开发者为它们的应用程序构建丰富的、允许自然语言(NL)的命令和控制(C&C)功能。(见附录I关于SPL能够允许的命令和控制方案以及能够被允许用于例如Outlook的命令的种类的讨论)SPL是一种创作解决方案，便于从话语中推导出含义，以及便于根据该含义的动作。SPL设计成依照复杂的话语而缩放，而编程者不必承受这种可扩缩性的负担。SPL的目标是便于语音和文本输入的著述，而不用为开发者添加许多额外的附带。具体来说，希望提供NL著述工具，允许几乎没有对语言/语义分析的知识的开发者能够开发NL应用程序。一般来说，SPL设计成使得语音输入的著述和文本输入的著述之间的差异最小化。然而，由于语音识别问题，某些差异可能会不得不呈现在开发者的面前。虽然NL应用程序可以被编写成根据LOM不用SPL而与分析引擎接口，但是这种编程是困难的，要求开发者具有更多的语言知识以及关于词汇结构的更多的内务操作。最后，SPL通过抽取特定的元素来便于开发，从而开发者能够关注于应用程序的功能，而不用关注于分析组成。这是专门化的编程语言所隐含的全部点，使得开发者不必进行内务操作和测深工作，从而他/她能够关注于手头的任务(在该情况下是NL使能应用程序)。SPL允许开发者以自然和直观的方式表达编程空间的基本因素。一般地，自然语言的语义是复杂的，且内在地是有多种含义的。人类采用大量的通用知识和上下文来理解和消除岐义。实际上，人们是如此自然地进行这种理解和消除岐义，以致于我们通常不会有意识地意识到其过程。对于能够对话语的含义作动作的应用程序来说，不但必须确定话语的语义对于应用程序来说表示什么含义，还必须有权根据其自己的知识和上下文来消除岐义。因此，SPL向开发者提供了以深度的有意义的方式推出应用程序域以及使得这种推理影响到语义分析的能力。这种与应用程序特定的推理的深度集成被内在地构建于SPL中。在高一级上，在一个实施例中，SPL的方法要使得开发者仅相对于话语的语义而非语法进行创作。在某些实施方式中可提供访问语法的后门方式。这是通过LOM来实现的(上面在D部分中讨论)。简而言之，LOM以域无关的方式对话语的语义(说了什么)进行建模。以许多方式，SPL编程模型使该语义模型具体化。通过相对于SPL程序对话语进行解析，SPL构建了关于说了什么的强类型的、依赖于域的模型，它束缚于应用程序中的实体。还值得注意的是，由于语义与语法分离，更容易实现多语言支持。SPL由两个主要的部分组成。第一部分是强类型的、程序上的、事件驱动的和面向对象的。在一个实施例中，SPL基于C#(一种用于构建企业规模的应用程序的面向对象的、类型安全的编程语言)，这对于当前的主流开发者来说是非常熟悉的。在一个替代实施例中，通过适用属性来完全以C#编写SPL。在设计SPL时，重要的是SPL不是新的编程方式。开发者的已有的知识和经验是有作用的，而非无效。第二个部分是根据SPL的语言语义构建关于说了什么的与域有关的模型的运行时间。SPL使得开发者能够将话语的语义含义与已有的应用程序接口或对象模型接口，而不用影响已有的应用程序。SPL确实允许开发者编写在适当位置推出域知识的代码，开发者还自由地以任何编程语言来编写该代码，包括任何Microsoft.NET编程语言，因为SPL编译到.Net公共语言运行时间(.NetCommonLanguageRuntime)。SPL的基本构造是实体(Entities)(名词)、构架(frames)(动词)、约束(restrictions)(实体间的关系)、命令(commands)(应用程序任务入口点)、NamedEntities和Denoters。这些是SPL的主要的第一类类型。语言是根据设计以命令为中心的，因为它是为应用程序中允许自然语言的命令和控制(C&C)功能而设计的。在详细讨论SPL框架之前，详细说明简单的SPL实例，以便给出用于理解上下文中的剩余揭示内容的概念上的设想。表78例示出处理“sendemailtoBob”命令场景的SPL代码。在本揭示的剩余部分中，将多次运用该命令场景。以最高级的“command”为开始，应理解到将SPL代码写到先前介绍的LOM模型(见D部分)。命令是相对于构架来创造的。构架是通常代表动词的对象。代表一个动词的基本构架由分析系统来提供。开发者还可定义其自己的动词构架，在详细描述Frames的部分中更详细的讨论了其特征。表78″SendMailToBob″SPL代码//粗体标记是关键字或预留的单词commandSendMailCommandusesMySendFrame<DoneTo.what＝MailEntity>{onresolve{//开始解析子句，//在解析开始之前调用begin{//进行应用程序特定的初始化，或者如果我们不想相对于该命令进一步进行解析，则失败(例如该应用程序不在正确的上下文/状态中)}//成功解析子句，当相对于该对象的话语的解析成功时调用success{//进行应用程序特定的任务执行(产生url或xml、运行命令、弹出对话框等等)}//失败解析子句，当相对于该对象的解析失败时调用failure{//进行任务特定的清除(释放资源、弹出对话框等等}}}SendMailCommand定义了使用MySendFrame的应用程序入口点，其中正北发送的对象(“DoneTo.what”槽)是MailEntity。命令封装该任务，允许开发者进行特定的初始化和清除，向平台提供进入应用程序的入口点。表79例示出用于的SPL代码。表79MySendFrameFrameMySendFramesend<DoneTo.what＝MailEntity>{onresolve{begin{//进行应用程序特定的初始化或失败}//在程序的某处定义RecipientEntitywithrestrictionGoal<goal＝RecipientEntity>{//如果在话语的MySendFrame和RecipientEntity之间存在有效的Goal关系则仅执行代码。////进行应用程序特定的推理，以绑定到应用程序对象、设置状态或拒绝解析。}success{}failure{}}}MySendFrame代码块定义了一个应用程序特定的构架，MySend，它从与域无关的基本“send”构架(由平台提供)中继承而来，并将“DoneTo.what”子类型划分为MailEntity。“DoneTo.what”是正被发送的对象。由Goal约束(由平台提供，例如基于LOM的SPL)捕获sending“toBob”的语义，它通过“withrestriction”子句来链接到“send”。除了这种链接之外，正被发送“toBob”的实体还被限制到RecipientEntity。如先前所讨论的那样，Restrictions是通常为实体之间的类型化的语义关系。SPL平台提供预定义的一组基本的关系。开发者可以对该组基本的约束进行子类型划分，以创建他们自己的关系。预定的约束的某些例子是Location(位置)(“mailinInbox”)、Time(时间)(“deleteafter3days”)、所有者(Possessor)(“Bob’sbook”)以及Topic(题目)(mailaboutcats)。关于约束的一个重要的事情是语法中的各种变化由语义平台来规格化。例如，可以多种语义方式来表达Topic“mailaboutcats”、“mailwithcatsasthesubject”、“mailregardingcats”、“mailwithsubjectcats”等等。不同的语言不同地表达Topic的语义。这些变化由语义平台来规格化，从而开发者仅需要相对于Topic约束来编程，而不用相对于每个可能的语义变化来编程。表80例示出根据本发明的一个实施例的MailEntity的语法。表80MailEntity.EntityMailEntitydenotedbyMailWords{onresolve{begin{}success{}failure{}}}denoterMailWords{Japanese＝noun(″メッセ一ジ″)，noun(″電子メ一ル″)；English＝noun(″mail″)，noun(″email″)，noun(″electronicmail″)；}在该例子中，MailEntity由一列单词来定义和表示。进行表示的单词通常单独定义，一般定义在它们自己的文件中(例如定域化文件)。类似于构架，实体也能具有运用于它们的约束。表81例示出具有约束的实体的语法。表81具有约束的实体entityMailEntitydenotedbyMailWords{withrestrictionLocation<loc＝MailFolder>{}}从开发者的观点来看，该语法声明了邮件(mail)项目可具有处于MailFolder(邮件夹)中的属性(约束)。从实体关系的观点来看，MailEntity和MailFolder通过Location关系而相关联。在运行时间，具有Location约束的MailEntity代表限制为处于某一MailFolder中的一组邮件项目。对于话语“sendmailtoBob”或“sendBobmail”来说，SPL运行时间平台相对于SendMailCommand命令来分析。图4例示出根据本发明的一个实施例的通过SendMailCommand代码来跟踪解析的流程图。本领域的技术人员应理解到命令的解析随实现方式而变化。例如，参考表78，Begin、Success和Failure子句中的每一个都是任选的。OnResolve子句可包含任一子句、子句的任何组合、或不包含子句，这取决于具体的实现方式。出于图4中的流程图的目的，应该理解到分析引擎已经将话语映射到说明模式中定义的和从LOM中导出的类型。例如，分析引擎已经考虑了Denoter对象。此外，假设该代码对于每个元素都包含Begin子句、Success子句和Failure子句。还有重要的是要注意到流程图中忽略了某些细节，特别是因为这些细节是实现方式所特定的，会不必要地使讨论变得复杂化。现在参考图4，一但接收到话语，调用SendMailCommand的开始解析子句(框400)。如果开始解析(beginresolution)子句不成功，可调用另一不同的命令或(任选地)解释器可简单地解析失败，这取决于特定的实现方式以及取决于应用程序中可用的其它命令(框402)。如果成功调用SendMailCommand的开始解析子句，则SPL解释器为SendMailCommand使用的MySendFrame调用开始解析子句(框404)。如果用于MySendFrame的解析子句失败，则调用MySendCommand失败(failure)子句(框406)，SPL解释器可任选地调用一不同的命令或解析失败(框402)。如果用于MySendFrame的开始解析子句成功，则调用MailEntityBeginResolution(MailEntity开始解析)子句(框408)。如果用于MailEntity的开始解析子句的调用失败，则随后发生的过程很大程度上取决于特定的实现方式。如所示，根据特定的实现方式，MailEntity开始解析子句的失败可意味着一般的失败(选项1)、可被忽略(选项2)、或可导致其它操作来消除话语的岐义(框410)。这些“其它操作”可包括试图使用不同的约束子句用于正被解析的部分输入。由于多义性，约束子句甚至可完全用于不同的约束。如果将失败理解成暗示着一般的失败(选项1)，则SPL解释器任选地调用一不同的命令或解析失败(框402)。如果忽略失败(选项2)，则SPL解释器可简单地调用MySendFrame的success子句(框420)、调用SendMailCommand的success子句、以及将SendMailCommand对象添加到“实际的解释”列表中(框424)。如果开发者代码要求其它操作，则SPL解释器可进行进一步的处理，包括语自然语言分析引擎通信和/或回调到客户端应用程序以试图消除话语的岐义。如果MailEntity的beginresolution子句的调用成功，则调用MailEntitysuccess子句(框412)。接着，调用Restrictionbeginresolution(约束开始解析)子句(框414)。如果Restrictionbeginresolution子句失败，则流程进行到框410(上述)。如果Restrictionbeginresolution子句成功，则调用Restrictionsuccess子句(框416)。然后在具有MailEntity槽的MySendFrame上调用Restriction(约束)子句(框418)。如果该调用失败，流程再次进行到框410(上述)。如果调用成功，则调用MySendFrame的success子句(框422)，并将SendMailCommand对象添加到“实际的解释”列表中(框424)。应理解到，代码块导致实际上无限的排列，这取决于应用程序和开发者。在一个实施例中，用于任何失败的解析的默认方式可调用failure子句，并停止执行。在另一个实施例中，开发者可能希望实例化部分对象，从而应用程序能够利用域上下文来分析多义性，并进行话语的部分执行。可以想像到许多可能情况，其中在每个子句中，开发者可自由地编写代码来进行应用程序特定的功能。在较佳实施例中，可用采用RecipientName作为槽的Named约束子句来创作RecipientEntity。RecipientName将是NamedEntity定义的，从而在进行语义处理之前，接受者的名字的实例将位于整个用户输入中。这允许对RecipientEntity实例的加强的识别。假设“Bob”是有效的RecipientEntity，如前所述，RecipientEntity定义在程序中的某处。在该实例中，“withrestriction”位于SendMailCommand使用的MySendFrame内。调用“withrestriction”子句中的代码。“withrestriction”内的代码向开发者提供了拒绝该约束的灵活性。如果该子句成功，则该约束被接受。否则，可连续地调用替代的“withrestriction”子句，直到它们中的一个成功为止，并且，如果没有一个成功，则忽略该约束。在一个替代的实施例中，如果约束子句失败，则调用失败分析。最后，按顺序调用MySendFrame和SendMailCommand的success子句(框420和422)。一般地，本领域的技术人员将理解到LOM中的以及由SPL实现的约束和其它对象可被配置成调用任何数量的功能或过程，而不管是成功或是失败。该流程图是示出示例性的流程可能如何进行的简单例示。然而，可预见到许多其它的变型，并且这些变型与本发明所适用的可能的客户端应用程序的数量一样众多。在该解析过程中，产生了一个连通图。每个实体是该连通图中的一个节点，实体之间的关系由LOM定义，并相对于应用程序域来进行验证。本领域的技术人员将理解到节点和关系是强类型的。该连通图代表了该域的语言中说了什么。重要的是要注意到SPL对象(命令、实体、构架和约束)的存在是由创作的代码连同语义分析一起确定的。一般而言，相对于构架、实体、命令或约束的解析涉及确定这些对象相对于应用程序域的存在/有效性。直到对象的限制被满足之前，对象不实际存在(是无效的)。可用C#对象结构来绘制它的模拟。在C#中，对象可具有构造函数，编程者可为构造函数编写代码，以抛出异常。如果某个限制不被满足，异常防止对象存在。当该“系统”试图创建对象时，它调用这些构造函数。从而，构造函数中创作的代码能够确定类的存在。概念上，其核心类型的SPL解析将此概念作为进一步的步骤，使其形式化，使其更丰富，并使其成为系统的原有部分。必须被满足的限制是话语的域创作的知识和语义分析的组合。D3.继承概念封装和组合性是通过传统的面向对象的技术(诸如对象重用、继承、多态性等等)来实现的。例如，为了对“sendmailtoBob”和“sendinstantmessagetoBob”进行建模，我们可以声明MySendFrame采用MailEntity和InstantMessage的超类型。表82例示出根据本发明的实施例的MySendFrame。表82MySendFrameEntityItemEntity{}entityMailEntityItemEntity{}entityInstantMessageItemEntity{}frameMySendFramesend<DoneTo.what＝ItemEntity>{onresolve{withrestrictionGoal<goal＝RecipientEntity>{}}}然后就可能如下为“sendmail”和“sendinstantmessage”定义单独的命令。commandSendIMCommandusesMySend<DoneTo.what＝InstantMessage>；commandSendMailCommandusesMySend<DoneTo.what＝MailEntity>；“sendingitemtoRecipient”的概念由MySendFrame来封装，并可由SendIMCommand和SendMailCommand来重用。还可能重用MySendFrame组合性。表83中给出了其例子。表83MySendFrameentityMailEntity{onresolve{withframeMySendFrame<DoneTo.what＝this>；}}从广义上来说，上述讨论捕捉了“mailsenttoBob”的语义。一般来说，SPL为开发者提供了推出应用程序域以及使得这种推理以深度的和有意义的方式影响分析的能力。SPL允许说明性地和程序性地进行这种推理。再次参考MailEntity语法，该语法建立了说明性限制，表示MailEntity是由MailWods中规定的一列单词表示的实体，并可限制到位于MailFolder位置中。表84例示出MailEntity。84MailEntityentityMailEntitydenotedbyMailWords{onresolve{withrestrictionLocation<loc＝MailFolder>；}}entityMailFolderdenotedbyFolderWords{onresolve{withrestrictionNamed<name＝string>；}}诸如“MailinFoo”、“maillocatedinfolderFoo”等之类的话语相对于MailEntity而成功，因为MailFolder上的Named约束子句接受所有串。在某些情况下，可能希望编写代码来判断“Foo”是否真的是当前用户的邮箱内的当前有效的文件夹。进行此的唯一方法是编写程序代码来检查运行时间的“Foo”的有效性。表85例示出检查运行时间文件夹名的有效性的用于MailFolder实体的语法。表85具有程序检查代码的MailFolderentityMailFolderdenotedbyFolderWords{onresolve{boolhaveName＝false；onsuccess{returnhaveName；}withrestrictionNamed<name＝string>{haveName＝IsValidFolderName(Named.name)；returnhaveName；}}}如果“Foo”不是当前有效的文件夹，则MailFolder的解析失败。根据特定的实现方式细节，失败可意味着一般的失败。可选地，约束的失败可导致约束被忽略。在一个实施例中，如果MailFoler解析失败，那么MailEntity也失败，并且在解析链上也是(例如意味着一般失败)。在较佳实施例中，如果MailFolder的解析失败，那么MailFolder约束被简单地忽略。本领域的技术人员将理解到这仅仅是一个简化的例子。可使用复杂得多的有效性检查，这取决于实现方式。实现此效果的另一种方式将会是创建NamedEntity类型FolderName，并使用它作为Named约束的槽。调用子句(begin、success、failure以及withrestriction)的一个好的副作用是，开发者能够编写代码将语义对象绑定到应用程序对象。例如，在Named约束子句中，如果名字有效，开发者可编写代码来获得对文件夹应用程序对象的引用。表86例示出用于这种引用的语法表86将语义对象绑定到应用程序对象的代码entityMailFolderdenotedbyFolderWords{MAPIFolderfolder；onresolve{withrestrictionNamed<name＝string>{folder＝GetFolder(name)；if(folder＝＝null)returnfalse；}}}该语法有效地将应用程序特定的对象，MAPIFolder，绑定到语义对象，MailFolder。一般地，开发者能够容易地编写代码推出分析的关键点处它们的应用程序的上下文和状态。这种推倒能够影响最终的解析分析。例如，为了确定“Bob”是否是有效的接收者，开发者可编写代码来转到系统的当前用户的数据库。如果不是，开发者可以编写代码来处理该失败。例如，开发者能够正好在失败点显示弹出窗口或对话框用于用户澄清，产生再声明等等。通过在失败点向用户提供即时反馈，系统促进了智能的、良好开发的应用程序的出现。可选地，如果应用程序不处于适当的状态，开发者可以在顶层的SendMailCommand处编写代码以防止解析域命令相逆。语义分析和推出域知识之间的这种深度集成对于理解和消除自然语言歧义来说是非常重要的。通过允许开发者在子句中编写代码来拒绝解析，SPL使得开发者能够早早作出对不正确的分析的拒绝。一般来说，作者可在成功的解释和失败的解释上插入许多控件。在某些情况下，作者可能希望在处理的早先阶段拒绝某些解释。一般来说，作者越早地能够消除歧义(去除歧义)，应用程序就越容易管理歧义。更少的歧义意味着更少的解释。为自然语言创作的任何应用程序必须具有某种机制，用于管理多个解释。作者或者编写代码在解释器进行判断时评估解释的健全性，或编写进行了语义分析以消除歧义和在一组解释中进行选择之后发生的代码(后处理)。不难看出前者将更容易管理和编写代码。此外，人们相信能够越早地拒绝解释，就能够越快和越精确地发现最佳的解释。在某些情况下，作者可能希望在处理中稍后拒绝解释。较早地拒绝解释常常涉及作出回调到客户端应用程序，以检查状态和/或上下文，以及推出应用程序的对象模型。如果回调需要跨越网络，那么作出经常的回调就会引起系统操作变慢。例如，传输延迟会致使系统不可用。SPL允许作者对何时作出回调和何种回调进行完全控制。从而，开发者能够为其自己判断回调和后分析消除歧义逻辑的正确平衡是什么，这取决于客户端应用程序的特性。可选地，在某些实现方式中，开发者可能希望在判断出是否要拒绝解析之前推出整个解析。可能存在这种情况，其中分离的片段不能确定成功或失败，并且要求对解析树的全局推理。SPL让开发者根据他们的需要和客户端应用程序的需要来选择如何平衡早决绝和晚拒绝。如先前所讨论的那样，SPL运行时间对构架、约束和实体的解析本质上构建了依赖于域的话语模型。这种声明保证了详细描述。在自然语言中，语法构造可用于表达多个含义。作为一个非常简单的例子，考虑介词“on”之后跟一名词。例如，考虑短语“onFoo”。短语“onFoo”可指代Location(如在“bookontable”中)或可意味着Topic(如在“bookonSeattle”)。为了判断哪个短语是正确的，必须消除该短语的歧义。这种歧义消除仅可由应用程序来进行。例如，表87例示出用于起动Amazon.com的语法。表87书籍销售者语法entityBookEntitydenotedby″book″{onresolve{withrestrictionTopic<topic＝string>；}}当解析“bookonFoo”时，语义分析将不会产生Location对象，因为BookEntity仅理解Topic。对于说了什么的解析出的模型将不包含Location。在对协调(和/或)、否定和子句的建模中，这种“指向”更为明显。对于协调，SPL代码定义了实体和它们的修饰语如何分布在逻辑与和逻辑或上。对于话语“findmailandnotescreatedyesterday”，可能的建模选择包括1.Find(mailcreatedyesterday)and(notescreatedyesterday).2.Find(mail)and(notescreatedyesterday).3.Find(mailcreatedyesterday)andfind(notescreatedyesterday).4.Find(mail)andfind(notescreatedyesterday).“createdyesterday”以及“find”是如何用其实体“mail”和“notes”进行分布的是由创作的代码来确定的。对于既包含逻辑与也包含逻辑或的话语来说，可能的读法更多。对于作者来说，没有必要理解所有的可能性。作者仅仅按照他们的应用程序的语义来考虑。例如，作为SPL作者，可能编写FindMailCommand，使得我的FindMailCommand仅理解类型MailEntity的实体，以及我的FindNotesCommand仅理解类型NotesEntity的实体。此外，MailEntity不具有创建时间的概念(这仅是出于例示目的)，但是NotesEntity具有。因此，对于上述话语“findmailandnotescreatedyesterday”来说，语义分析将仅从上述列表中产生读法4。对于否定，创作的代码确定否定范围歧义是如何被建模的。例如，采用话语“Don’tallowmailfromJoe”。该短语可被如下解释1.Don′tallowmailfromJoe(blockitinstead)否定作用于“allow”；2.Don′tallowmailfromJoe(butallowmessagesfromhim)否定作用于“mail”；或者3.Don′tallowmailfromJoe(butallowmailfromsomeoneelse)否定作用于“Joe”。创作的SPL程序确定否定如何确定范围和建模。语义分析引擎提供所有可能的读法。对于子句，创作的代码确定是将子句建模成基于构架的约束(以动词为开头的约束)还是预定约束之一。例如，“bookthatdiscussesFoo”中的子句“thatdiscussesFoo”可被构建为Topic约束，或可被建模成对“book”的基于构架的约束。表88给出了用于BookEntity的语法的例子。表88BookEntityEntityBookEntitydenotedby″book″{onresolve{withframediscuss<DoneTo.what＝string>；}}一般地，从SPL的观点来看，SPL程序的角色是定义应用程序的域的自然语言语义模型。语义分析的角色是根据分析引擎对语言的理解将话语映射到该SPL程序定义的模型。从平台的观点来看，语义平台的角色是定义关于说了什么的高度抽象的、域无关的对象模型。从该点来看，SPL代码的角色是从平台提供的可能性中挑选。一般地，SPL程序的解析可被理解成构建关于说了什么的与域有关的语义模型。在构建这种与域有关的模型的过程中，域无关的对象变成强类型的，且可被锚定(映射)到应用程序的对象。E2.类型系统一般地，核心SPL类型是commands(命令)、frames(构架)、entities(实体)、以及restrictions(约束)。这些被称为是可解析的类型，因为它们要求解析语义来确定它们的存在。{onresolve{begin{}success{}fail{}}}“onresolve”子句内的每一项都必须处理解析语义。begin、success和fail子句都是可选的。在“onresolve”中可以最多存在各子句中的一个。begin子句在可解析的类型的解析开始时被调用。按照默认方式，子句返回“true”(真)。开发者可返回“false”(假)，它向SPL解释器发信号以停止相对于该类型的解析。这意味着解析失败，并且fail子句被调用。begin子句是一种用于开发者进行初始化和检查应用程序是否出于合适的上下文环境/状态来处理类型的便捷场所。当相对于该类型的解析成功时，调用success子句。这是开发者能够编写代码来清除资源或包装解析结果的地方。开发者仍然能够通过返回false来决绝解析。当解析未能成功时，调用fail子句。类似于begin子句和success子句，fail子句可返回“false”，这将有效地使类型的失败的解析变为成功。在一个实施例中，除了command之外，所有可解析的类型都能具有任何数量的约束子句。这在Slots和“withrestriction/Frame子句”中有更为详细的讨论。在一个可选的实施例中，所有可解析的类型，包括command类型，都能够具有任何数量的约束子句。下面讨论每种可解析的类型(Commands、Frames、Entities、和Restrictions)Commands是由客户端应用程序支持的自然语言(NL)起动的任务。在客户端应用程序的开发过程中，作者创建命令来描述他们想处理的动作。Commands向语义分析提供了进入应用程序的任务入口点。SPL解析在command处开始，并树形向下递归。响应于用户命令来调用Commands。这类似于诸如响应于用户点击鼠标而调用了鼠标点击之类的Windowns事件。表89示出了根据本发明的实施例的命令声明的语法。TABLE89命令声明CommandCommandNameusesFrameObject<optionalslots>{}例如，“CommandSendMailCommandusesMySendFrame”定义了适用MySendFrame对象的SendMailCommand对象。Commands实质上包围着构架对象。在命令中仅可规定一个构架对象。命令中的begin子句有助于检查应用程序是否出于适当的上下文环境和/或状态来处理该命令。这允许根据应用程序的知识来非常早地决绝命令。在success子句中，开发者能够直接执行命令或包装为执行命令而需要的任何数据。包装的数据可以采用URL的形式、任务的XML描述、对能够执行该命令的功能的委托等等。作者仍然能够在success子句中进行其它推理，并通过返回“false”值来拒绝解释。这是有用的，因为它允许作者在全局上推出整个话语。换言之，作者能够查看完全解析的语义树，以查看解析整体上是否是相干的。片段可以独立地或在有限的上下文中相干，但是它们一起可能没有意义。“Unknown”(未知)命令处理不映射到创作的命令的华裔。在一个实施例中，SPL强制该命令的存在。Frames(构架)一般涉及动词。有两种类型的Frames基本构架和复合构架。基本构架涉及一个动词。例如，构架find涉及动词“find”。复合构架是多个动词的组合，这些动词一般具有相同的含义。复合构架及其多个动词可被看作是同义词列表。一般而言，语义平台提供预定义的一组基本构架，每种构架用于一个动词。出于一致性，约定基本构架的名字是小写字体，并且它们具有与它们的词汇单词相同的名字。相反，复合构架的名字以大写字母开头。语义平台提供了公共的一组复合构架。例如，平台能够提供Search复合构架，它将“find”、“search”、“look”和“rummage”组织在一起。表90例示出用于定义基本构架的语法。表90基本构架frameFrameNamedenotedby″word″behavesasVerbClass{}例如，表91示出用于find构架的语法。表91find构架framefinddenotedby″find″behavesasDefaultVerbClass{}该语法定义了基本构架find，它由词汇单词“find”来表示，并且它表现在DefaultVerbClass中。术语“find”被称为表示构架find的标志牌(denoter)。语义平台定义了覆盖所有动词的一组动词类行为。大多数的动词具有作为DefaultVerbClass的一部分的行为。词汇单词不必表现为内联的。实际上，为了支持多个语言，建议单词不表现为内联的。它们应该定义在它们自己的对象中。表92例示出用于定义的标志牌对象的语法。表92标志牌对象denoterFindWord{English＝″find″；French＝″chercher″；}通过以此方式分开地列出标志牌术语，而不是与构架定义内联，依赖于语言的元素就很好地与独立于语言的元素分离开。语义平台提供的所有基本构架都以此方式定义在SPL代码中。开发者还能够如此定义他们自己的动词。例如，在一个实施例中，开发者可以定义如下定义fop基本类framefopdenotedby“fop”behavesasDefaultVerbClass；可选地，在较佳实施例中，开发者可以如下定义fop基本类framefopdenotedby“fop；人们相信很大一部分动词(大约95％)的语言实现与它们的词汇单词相同。在大多数情况下，将存在相当直接的对其它语言的翻译。对于跨语言不能以此方式起作用的动词来说，denoter类中提供了一种机制来规定那些动词的语言实现。如上所述，复合构架是动词的分组。它们实质上是同义词列表。在创造复合构架时，仅分组中适用的构架的标志牌被复合构架“继承”。SPL向开发者提供了从基本构架和复合构架中创建他们自己的分组的能力。表94中给出了一个例子。表94复合构架frameCompositeNamegroupsframe1，...，framenexceptframex，...，framey{}实质上，该声明建立了groups子句中规定的构架的所有标志牌的逻辑联合(union)，去除了重复，并去除了except子句中规定的构架的标志牌。except子句是任选的。例如，表95例示出定义中包含except子句的复合构架。表95具有except子句的复合构架frameMySearchFramegroupsSearch，fopexceptfind{}这定义了除了find构架的标志牌之外将Search和fop的标志牌分组在一起的MySearchFrame。也可创造出从其它构架、基本构架或复合构架继承而衍生出的构架(derivedframe)。表96例示出用于衍生出的构架的语法。表96衍生出的构架FrameDerivedFrameBaseFrame<slot1，...，slotn>{}在下面的部分E3中更详细地讨论继承(Inheritance)的主题。实体是应用程序中可被称为名字或描述的对象。实体可以是具体的物，例如文件项目和email项目，但是它们也可表示抽象的概念，例如颜色、纹理等等。实体通常由词汇单词来表示。表97示出了用于声明实体的语法。表97实体声明entityEntityNamedenotedby″word1″，...，″wordn″{}例如entityMailEntitydenotedby″mail″，″electronicmail″，″email″{}类似于构架，建议不内联地规定标志牌，以便支持多个语言。表98提供了这种标志牌的例子。表98标志牌entityMailEntitydenotedbyMailWords{}denoterMailWords{Japanese＝noun(″メッセ一ジ″)，noun(″電子メ一ル″)；English＝noun(″mail″)，noun(″email″)，noun(″electronicmail″)；}denotedby子句允许作者规定表示实体的一列自然语言单词。denotedby子句是开发者可借助来将实体连接到词汇单词的手段。实体不需要由单词或一组单词来表示。实体可通过它们的约束来描述。开发者不需要规定单词的各种形式(例如“file”和“files”)，因为语言平台维护着这些形式。此外，标志牌不需要规定在话语中，以便实体成功。然而，如果标志牌包含在话语中，标志牌必须匹配实体列表中的一个标志牌。在某些实施例中，可能希望在声明时标志牌是任选的。此外，在某些实现方式中，可能希望添加强制性标志牌(必须包含在话语中用于实体成功的单词)。“强制性”标志牌的存在可通过包含在success子句中的代码来强制。表99示出了通过success子句强制的强制性标志牌的例子。表99通过success子句的强制性标志牌强制entityMailEntitydenotedbyMailWords{onresolve{success{if(this.Denoter＝＝null)returnfalse；}}}一般地，约束是类型化的语义关系。平台提供基本的一组预定义的关系。关于约束的最重要的方面之一是语言内和跨语言的语法中的偏差的规格化。约束是语义上的，而不是语法上的。从而，约束允许开发者相对于语言的语义而非语法来编写代码。约束很大地减少了创作负担，并允许其它语言成为可能。某些约束伴随着具有特定含义的系统定义的槽一起。上述部分D中给出的LOM的讨论提供了代码样例和槽的某些讨论。表100中列出了某些公共约束。表100公共约束列表存在一种特殊的约束，称为Default(默认)约束。Default约束由SPL运行时间在可解析的类型上存在未解析的或未识别的约束时被激发。开发者通过从预定的约束组中的一个进行继承、通过创建基于构架的约束、或通过规定模式来创建他们自己的约束。一般地，约束可运用于实体和构架，以及其它约束。作为一般规则，SPL不强制运用某一约束是否有语义意义。SPL作出某些例外，简化语义模型或者减少岐义性。表101中给出了例外(exception)。表101SPL例外1.对于约束仅允许Degree约束。2.对于构架仅允许Doer和DoneTo约束。3.对于实体不允许Negation。使用下面的语法将约束运用于类型withrestrictionRestrictionName<slot1＝type，...，slotn＝type>；角括号中的变量称为槽。“withrestriction”声明称为约束子句。选择标记“restricton”以避免某些问题。例如，可把约束标记为“properties”，但是properties不总是充当描述符。例如，某人可以将“mailinInbox”认为是“mailwiththepropertyofbeingintheInboxfolder”。然而，对于数量词来说，例如基数词和序数词，这种关系并不存在。短语“threefiles”不等同于“fileswiththepropertyofthree”。而且，单词“property”早就用于传统的编程范例中(例如“propertiesofalistbox”)。一般希望不使术语“properties”负担过重，对于单词“attribute”来说同样如此。相反，Entity意图覆盖集合的概念。SPL中的“entity”声明实际上规定了一组实体，运用约束是对该组的限制。例如，用于声明由Mail表示的MailEntity的语法entityMailEntitydenotedby“mail”是表示所有邮件项目的集合的对象的声明。表102例示出用于运用到实体的约束的语法。表102运用到实体的约束EntityMailEntitydenotedby″mail″{onresolve{withrestrictionLocation<loc＝MailFolder>；}}这里，邮件项目的集合被限制到MailFolder位置。将约束运用到构架应被看作是限制动作(Frames一般对动词或动作建模)。表103例示出具有约束的构架(Frame)。表103对构架的约束frameMyOpenopen<DoneTo.what＝FileEntity>{onresolve{withrestrictionMeans<instrument＝NotepadEntity>；}}这里，Means约束运用于MyOpen构架，从而将打开文件动作限制到使用Notepad(记事本)。同样的道理适用于对约束的约束。例如，Cardinal(基数词)约束表示实体的基数。短语“3files”表示任何的3个文件。然而，可由Ordinal(序数词)来限制基数，例如“first3files”。表104例示出运用于约束上的约束。表104约束上的约束restrictionOrdinalCardinalCardinal{onresolve{withrestrictionOrdinal；}}这里，约束子句通过运用序数来限制基数。一般地，除了命令之外，可解析的类型可具有运用于它们的任何数量的约束。可多次运用每个约束类型，只要特征(signature)是唯一的。表105示出了具有带有唯一特征的多个约束的Frame。表105具有多个约束的FrameframeMyOpenopen<DoneTo.what＝FileEntity>{onresolve{withrestrictionMeans<instrument＝NotepadEntity>；//有效的约束子句withrestrictionMeans<instrument＝MSWordEntity>；//无效的约束子句，因为特征不唯一withrestrictionMeans<instrument＝NotepadEntity>；}}约束子句激发的顺序取决于语义分析。一般地，该顺序基于语言证据、统计排列、以及依赖于域的学习的组合。在某些实现方式中，可添加机制来强制确定性的顺序。SPL运行时间根据SPL的语言语义和语义分析来激发约束子句。如上所述，槽是角括号(<>)中出现的变量。槽语法用于在使用时对槽子类型化。SPL具有多个预定义的约束的槽。例如，语义系统如下定义了Goal约束Goal<goal＝Entity>goal槽具有基本Entity类型，并可被称为与域无关的说明。当开发者将该与域无关的Goal运用于一可解析的类型时，该开发者能够在应用时将goal槽子类型化。表106示出了包含子类型化的goal槽的Frame的语法。表106具有子类型化的Goal槽的Frameframesenddenotedby″send″{onresolve{//对″sendtoContactItem″进行建模withrestrictionGoal<goal＝ContactItem>；}}这里，开发者已将goal槽子类型化成ContactItem(ContactItem必定是实体类型)。在约束子句的代码中，可按照对象来访问约束。表107示出了用于按照对象来访问约束的语法。表107按照对象访问约束withrestrictionGoal<goal＝ContactItem>{item＝Goal.goal；}一般地，可使用类似于C++模板之类的手段来将可解析的类型概念化。例如，可把Goal约束看作是具有一般类型的goal数据成员的templateGoalclass(模板Goal类)。于是，用于上述Goal约束子句的伪C++代码如下boolOnGoalClause(GoalTemplateClass<ContactItem>Goal)；SPL编译器强制进行goal槽的子类型化。可解析的类型的使用者可能希望对类型的约束子句子类型化。例如，上述send构架的使用者可能希望使用如下的槽语法对其Goal约束子句的goal槽子类型化commandMySendCommandusessend<Goal.goal＝MyContactItem>；由于可能存在许多运用于send构架的Goal约束子句，开发者必须能够规定哪个是所涉及的。另一种约束是AsProperty约束。asproperty属性允许可解析的类型的使用者使用槽语法对约束子句子类型化。该属性在约束子句处规定，如表108所示。表108AsProperty属性framesenddenotedby″send″{onresolve{withaspropertyrestrictionGoal<goal＝ContactItem>；}}这里，send构架的开发者声明使用者可使用如下的槽语法来对send构架的Goal约束子句子类型化commandMySendCommandusessend<Goal.goal＝MyContactItem>；该声明意思是，MySendCommand使用send构架，并将send构架的Goal约束子句子类型化成MyContactItem。一般地，asproperty属性还允许send构架中的代码使用property(特性)语法来访问该Goal对象。所有可解析的类型都具有RestrictionCollection特性，允许代码得到其当前解析出的约束的集合。利用asproperty属性，可使用特性语法来访问标记出的约束，如表109所示。例如表109使用特性语法来访问标记出的约束framesenddenotedby″send″{ContactItemitem；onresolve{withaspropertyrestrictionGoal<goal＝ContactItem>；success{//常规语法if(this.RestrictionCollection(″Goal″).count>0){item＝this.RestrictionCollection(″Goal″).goal；}//特性语法if(this.Goal.goal！＝null){item＝this.Goal.goal；}}}}此外，每个类型中仅有一个约束可用asproperty属性来标记，而不管约束槽的类型是什么，如表110所示。表110AsProperty约束限制framesenddenotedby″send″{onresolve{withaspropertyrestrictionGoal<goal＝ContactItem>；//非法的withaspropertyrestrictionGoal<goal＝UserItem>；}}然而，该语法可由开发者改变，以允许类型的不止一个约束用asproperty属性来标记，如下restrictionGoal2Goal<goal＝UserItem>；这消除了问题，并允许构架进行解析，如表112所示。表112约束语法framesenddenotedby″send″{onresolve{withaspropertyrestrictionGoal<goal＝ContactItem>；//在这里不必使用槽，但是对于文档记录来说是较佳的withaspropertyrestrictionGoal2<goal＝UserItem>；//该子句本该写成“withaspropertyrestrictionGoal2；”}}就约束子句中的槽的排序而言，重要的是要理解到某些约束是用系统槽来定义的。例如，Goal约束是用goal槽定义的。当在使用时(即在约束子句处)对Goal约束子类型化时，必须首先规定系统槽，如表113所示。表113槽的排序restrictionGoal2Goal<goal＝Item>{onresolve{withaspropertyrestrictionModifier<mod＝Denoter>；}}framesenddenotedby″send″{onresolve{//非法的withaspropertyrestrictionGoal2<Modifier.mod＝MyDenoters，goal＝ContactItem>；//台法的withaspropertyrestrictionGoal2<goal＝ContactItem，Modifier.mod＝MyDenoters>；}}约束子句用asproperty标记的实体能够在使用时使那些约束子句子类型化。例如，假设ContactItem使得Location约束子句用asproperty标记，如表114所示。表114标记AsProperty的Location约束framesenddenotedby″send″{onresolve{withaspropertyrestrictionGoal<goal＝ContactItem<Location.loc＝DerEntity>>；}}约束子句还可标记为obligatory，意思是该子句必须被执行并成功，否则该类型的解析失败。为了该子句成功，必须满足下面的准则1.该约束必须处于话语中；2.子句的说明性限制(槽的类型)必须被满足；以及3.子句中的程序性限制(代码)必须估计为真。表115中给出了一个例子。表115Obligatory约束framesenddenotedby″send″{onresolve{withobligatoryrestrictionGoal<goal＝ContactItem>；}}表115中的构架的语法声明了，为了send构架成功解析，话语中必须存在ContactItem作为“send”的目标。所以，“sendmail”将不会解析，但是“sendtoBob”将会，其条件为“Bob”是解析出的ContactItem。E3.SPL继承实体、构架和约束上都允许继承。当前，命令不支持继承。一般地，似乎(此时)无需在命令中支持继承。命令是不要求继承的任务入口点。所有的“可继承的”代码处于命令所使用的构架中。如先前所讨论的那样，除了onresolve子句中的解析语义之外，可解析的类型仅仅是常规的对象。onresolve子句之外，SPL采用C#继承语义，这是本领域已知的。为了本讨论的目的，本揭示聚焦于不遵循传统的(C#)继承语义的onresolve子句内的继承语义。然而，在某些实现方式中，可能希望不同于传统的C#继承语义，用于使用继承在真实的应用程序中起动特定的功能。出于简化的目的，该讨论不深入研究所有这些可能性，选择规定的做法试图使得讨论简单。首先，重要的是理解函数、约束子句和onresolve子句中的变量的范围。表116示出了用于MailEntity的语法，以便于范围的讨论。表116MailEntity.entityMail{intx；onresolve{inty；withrestrictionGoal<goal＝Entity>；voidfoo()；}voidbar()；}onresolve范围内定义的变量对于onresolve范围内的约束子句来说是可访问的，但对于onresolve子句外的来说是不可访问的。在上述的例子中，整型值y在Goal约束子句和函数foo()中是可访问的，而在函数bar()中是不可访问的。onresolve子句中定义的函数对于该子句来说是私有的，意思是在onresolve子句外不能访问这些函数。从而，在bar()中不能访问foo()。约束子句同样对于onresolve子句来说是私有的，因此在其外部不能访问。类型的范围中声明的变量是可由onresolve子句中的子句和函数通过使用outer关键字来访问的。例如，整型值x可按照outer.x而在Goal约束和函数foo()中访问。类型的范围中声明的函数对onresolve子句来说是可访问的。从而，在Goal约束和函数foo()中可按照outer.bar()访问函数bar()。可把onresolve子句概念化成扩展的构造函数，从而属于该构造函数的每一元素对于该构造函数来说都是私有的。这暗示出衍生出的类不能调用基本类中的任何约束子句。允许实体从另一个实体继承。不允许实体的多重继承。基本实体的标志牌合并于衍生出的实体的标志牌。如表117所示，合并的标志牌列表中没有层次(标志牌被平坦化)。表117合并的标志牌列表entityMailEntitydenotedby″mail″，″email″{}entityMyMailEntitydenotedby″electronicmail″MailEntity{}MyMailEntity的标志牌列表将由“mail”、“email”和“electronicmail”组成。在定义时，衍生出的实体也能对用asproperty标记的基本实体的约束子句进行子类型化。例如，如果MailEntity具有用asproperty标记的Location约束子句，则MyMailEntity定义可如下所示entityMyMailEntitydenotedby″electronicmail″MailEntity<Location.loc＝MyEntity>{}该代码块意思是MyMailEntity继承可MailEntity的Location理解，但对实际位置添加了更多特征。类似于实体，构架仅能从另一构架继承。不允许多重继承。在定义中，衍生出的继承不能规定构架的任何分组。复合构架和构架继承是分离的。可能按照与实体相同的方式来处理构架的继承。例如，在复合构架中，标志牌列表被分组在一起。在某些情况中，可能希望强加当构架被分组时所有构架都属于相同行为的类的要求。如果分组中的构架不需要属于相同的LSS类，那么，可以相同的方式处理构架和实体。类似于构架和实体，衍生出的约束仅可从另一约束继承。基本约束的约束子句的子类型化也可在衍生出的约束的定义处发生。某一约束类型的约束子句在转到基本类型之前以衍生出的类型被尝试。这同样适用于Default约束，如表118所示。表118Default约束entityMailEntitydenotedby″mail″，″email″{withrestrictionLocation<loc＝Entity>{}withrestrictionDefault{}}entityMyMailEntitydenotedby″electronicmail″MailEntity{withrestrictionLocation<loc＝MailFolder>{}withrestrictionDefault{}}当解析MyMailEntity上的Location约束时，激发约束子句的顺序如下1.MyMailEntity.Location2.MailEntity.Location3.MyMailEntity.Default4.MailEntity.Default当前不存在公共/私有约束子句的概念和最重要的约束子句(overridingrestrictionclause)的概念。在某种程度上，这是因为最重要的约束子句在约束子句用于解析类和子句对于onresolve子句来说是私有的情况下意义不大。然而，可能希望在某些实施方式中允许忽略约束子句。根据实现方式，可能有必要允许衍生出的类(在解析过程中)访问基本类中的成员(方法和变量)。由于基本类未被解析，这可能是有问题的。如果在基本类被解析之前不允许衍生出的类访问基本类的成员，则必须防止在解析过程中衍生出的类以多种组合形式设置到基本类(通过赋值、传递到函数等)。在任一种情况下，可允许衍生出的类在基本类被解析之前调用基本类上的约束子句。可利用继承添加对已有的实体的更多的理解。再次参考表118的MailEntity代码，重要的是要注意到MailEntity仅理解Location约束。可能创建一实体，它对MyMailEntity中的创作的Location逻辑起杠杆作用，并添加Topic理解。此外，可添加与base相同类型的约束子句，如表119所示。表119MyMailEntity.entityMyMailEntitydenotedby″electronicmail″MailEntity{withrestrictionLocation<loc＝MailFolder>；}entityMailEntityWithTopicMailEntity{withrestrictionTopic<topic＝string>{//处理topic}//处理MyMailFolder中的位置。所有其它位置都将转到基本类withrestrictionLocation<loc＝MyMailFolder>{}}当约束子句被调用并被子句中创作的代码拒绝时，解释器以当前类型或其多形联合等价超类型(polymorphic-allyequivalentsupertypes)调用约束子句。为了考虑为多形联合等价，约束类型及其槽的类型必须都为多形的，如表120所示。120多态性entitySlotEntity2SlotEntityl；entityMyEntity{withrestrictionLocation<loc＝SlotEntity2>{/*此失败后，解释器将自动地调用后续的Location子句，而不再次解析该槽，因为它们是多形等价的*/returnfalse；}withrestrictionLocation<loc＝SlotEntityl>{/*该代码可用多形地充当SlotEntityl的SlotEntity2来调用。如果该子句失败，解释器将不自动地调用下面的Topic约束，因为即使槽是相等的Topic也不相当于Location。*/}withrestrictionTopic<topic＝SlotEntity1>{}}虽然它们不是完全等价，但是可能在槽处使用继承而非子类型化，如表121所示。表121继承entityMailEntitydenotedby″mail″{withaspropertyrestrictionLocation<loc＝MailFolder>{}}entityMailEntity2MailEntity<Location.loc＝MyMailFolder>{}entityMailEntity3MailEntity{withrestrictionLocation<loc＝MyMailFolder>{}}当相对于MailEntity3来解析“mailinInbox”时，MailEntity3.Location子句将优先于MailEntity.Location子句。在该情况下，对于MailEntity3来说存在两个Location约束子句。然而，对于MailEntity2来说仅有一个Location子句。槽处的子类型化可被解释成意思是MailEntity2的Location应由MailEntity的Location约束子句来评估，但带有MyMailFolder类型。重要的是要注意到当用obligatory属性声明约束子句时，应当谨慎。Obligatory子句必须激发并成功，以便类型解析成功。如果基本类型按照obligatory声明了子句，则衍生出的类必须确保它不处理应当转到基本类的判断。衍生出的类不能调用它们的基本类型的约束子句。相反，衍生出的类型取决于常规的解析语义，以调用基本类中的obligatory约束语句。E4.解析语义SPL的解析语义由SPL运行时间来实现。根据SPL的语言语义，运行时间构建了话语的域相关模型。运行时间相对于创作的SPL类型解析自然语言命令，遵守着语言和SPL语言的规则。在一个实施例中，使用自顶向下的方法来进行类型的解析。图5例示出根据本发明的实施例的类型解析的自定向下的方法的简化流程图。首先，运行时间寻找相对于话语被解析的可能的命令(步骤500)。如果存在多个可能的命令，则选择一个命令来解析(步骤502)。如果没有发现命令，则调用Unknown命令(步骤504)。如果发现一个或多个命令，运行时间尝试解析发现的命令(步骤506)。如果命令解析失败，运行时间进行到列表中的下一个命令，并重复步骤502至510，直到没有更多的可能的命令为止。如果命令解析成功，则命令添加到解释列表(步骤510)。最后，运行时间重复步骤(步骤502至510)，直到话语中不包含更多的可能的命令为止，或直到达到规定数量的请求的解释为止(步骤512)。本领域的技术人员应该理解到解析过程的许多变型都是可能的。例如，在某些情况下，解析的失败可构成一般失败，引起程序退出解析。在其它情况下，失败可导致调用类型的failure(失败)子句，可能或可能不导致解析的失败。此外，在failure子句、success子句和begin子句内，程序开发者自由地插入应用程序特定的代码，允许框架适用于各种方式。例如，开发者可将代码插入于failure子句中，以返回“success”标志，使得解析的失败不会导致失败。失败的解析可能被忽略，或者其它程序代码可能致使过程回调到客户端应用程序以消除某一解析的岐义等等。应理解，附图仅提供示例，而非限制可能的实现方式。如图6所示，命令解析的一个可能的实施例如下进行。调用命令的begin子句(步骤600)。如果begin子句失败，运行时间退出命令(步骤601)。如果begin子句成功，运行时间试图解析构架(步骤604)。如果构架解析失败，调用构架failure子句，并且，根据实现方式，运行时间可退出命令或进行另一操作(步骤602)。否则，运行时间调用success子句(步骤606)。如先前所讨论的那样，本发明的语义编程语言允许程序开发者对各种元素的操作施加控制。从而，可以各种方式修改本发明的解析语义，以实现某一应用程序所希望的操作。从而，当解析失败时，在某些情况下，可能希望忽略失败并继续。在另一些情况中，可能希望采取步骤来消除解析的岐义，使得解析能够成功(例如通过回调到客户端应用程序)。在又一些情况中，可能希望在解析失败的情况下简单地退出解析。如图7所示，在一个实施例中，构架解析如下进行。调用构架的begin子句(框700)。如果构架解析失败，调用failure子句(框702)，并且运行时间选择性地解析另一命令(框704)。如果构架解析成功，运行时间试图调用Restriction子句(框706)(对应于图4中的框408和顺序)。如果Restriction子句解析失败，运行时间考虑任何衍生出的类型用于解析(框708)。例如，给定具有衍生出的类型Mail和Notes的实体类型Item，可由Mail或Notes的实例来解析采用Item的另一类型SendItem上的约束。如果运行时间不能成功地调用衍生出的类型，根据实现方式，可调用构架的failure子句(框709)，并且随后可调用命令的failure子句(框702)。可选地，可简单地忽略Restriction子句。如果忽略Restriction子句，则运行时间调用构架和命令的success子句(框712)。运行时间随后将命令对象添加到“实际的解释”列表(框714)，并试图解析另一命令(框704)。如果运行时间成功地调用Restriction子句(框706)或成功地发现用于解析的衍生出的类型(框708)，则运行时间调用Restriction的success子句(框710)。运行时间随后调用构架和命令的success子句(框712)，并将命令对象添加到“实际的解释”列表(框714)。运行时间随后试图解析另一个命令(框704)，直到对所有可能的命令的解析都完成为止。如先前所述，过程流程仅仅用于说明性的目的，而非对许多可能的实现方式的限制。实际上，解析过程即使不是大部分也至少是部分地由特定的实现方式来确定的。从而，如所指出的那样，约束解析的失败可引起一般的解析失败(如框709和702所指出的那样)，或者约束解析可简单地被忽略，命令解析继续进行。在另一个实施例中，失败的约束(例如，如果Restriction是obligatory(必须的))可能引起运行时间回调到客户端应用程序，或向分析引擎发送流控制信息，以试图消除命令的岐义。这些选择很大程度上是实现方式所特定的，因此，语义编程语言的编程构造可用于推动自然语言编程，以优化自然语言处理，以适应于特定的实现方式。如图8所示，约束子句解析的一个可能的实施例如下进行。对于每个提议的约束，如果存在用于该约束的任何约束槽，则运行时间通过调用ResolveSlot函数来解析每个槽(框800)。如果ResolveSlot函数失败，运行时间选择下一个提议的约束(框802)，并试图通过再次调用ResolveSlot函数(框800)来解析槽。如果ResolveSlot函数成功(第一次就成功或者在接着的提议的约束中的一个中成功)，运行时间调用约束子句(框804)。如果约束子句失败，运行时间查找当前类中的多形联合等价子句(框806)。如果在当前类中没有发现多形联合等价子句，则运行时间在其继承链中搜索(框808)。如果发现多形联合等价子句，运行时间调用equivalent(等价)子句(框810)。运行时间重复(框808)，直到没有发现更多的等价子句或直到等价子句成功为止。如有必要，运行时间调用Default约束(框812)。如果所有的约束子句成功解析，则运行时间调用success子句(框814)。否则，运行时间忽略Restriction(框816)并调用构架的success子句(框818)。在一可选的实施例中，如果默认约束子句失败，约束被简单地忽略。解析仍然成功，除非这是Named或Negation约束，如上所讨论的那样。重要的是要注意到约束子句可在同一可解析的类型上激发多次。例如，命令“showfilesincintempfolder”对“file”实体具有两个Location约束(“inc”和“intempfolder”)。当前，约束子句的解析的唯一强制的顺序是对构架的Doer和DoneTo约束首先被解析(按顺序)，最后解析Default约束。然而，可能希望对其它类型强制顺序，例如Negation和Named。如图9所示，在一个实施例中，NamedEntity解析如下进行。运行时间调用Entity的begin子句(框900)。如果这失败，运行时间退出Entity解析(框902)。如果Entity的begin解析子句成功，运行时间试图调用给定发现的且对应于Entity的NamgedEntity的namedrestriction(有名约束)(框904)。重要的是要注意到框904包含了多个解析步骤，但是这里为了简单而省略了。如果namedrestriction的调用失败，调用Entity的失败子句，并且运行时间退出(框906)。如果调用成功，运行时间调用Entity的success子句(框908)。应理解到，本发明的编程语言可用于以各种方式改变解析步骤。例如，可把success约束子句修改成在某些情况下返回“false”或“failure”。类似地，根据特定的实现方式，可把failure约束子句编程为返回“true”或“success”。从而，这里所给出的例子并非限制性的，而仅仅是说明解析语义的一个可能的实现方式。可预期许多变型，并且预期到编程者将使解析适应于满足特定的自然语言应用程序的需要。使用Default约束来解析创作的代码不处理的约束和/或运行时间不理解的约束。每个可解析的类型调用一次Default约束，并且总在最后调用。每个可解析的类型仅可最多存在一个Default约束。Default下的对象模型可根据实现方式而变化。在一个实施例中，Default对象模型提供带有提议的约束的文本的象征记号(token)(element、item或span)的组列(lattice)。例如，假设我们在话语中具有下列象征记号token1、token2和token3。在Default下，运行时间可产生表122所示的组列。表122Default下产生的组列SpanTokens＝{token1token2}HypothesisRestrictionType＝restrictioniSucceededResolution＝boolean…Hypothesis[n]RestrictionType＝restrictionjSucceededResolution＝boolean…Span[n]Tokens＝{token1token3}HypothesisRestrictionType＝restrictioniSucceededResolution＝boolean…Hypothesis[n]RestrictionType＝restrictionjSucceededResolution＝boolean原始文本总是可用的。SPL可向作者提供关于文本中的象征记号是否参与成功的解析的信息。统计语义建模和学习在SPL中能够起作用。调用约束子句的顺序可依赖于基于语言证据、统计排列(例如SGM)和自动学习的某些统计学。如图10所示，系统1000包括运行时间1002和数据库1004。一般地，运行时间1002能够管理数据库1004，数据库是话语和解析结果的储存库。该储存库中的数据可由分析工具1006(例如)在已经到达了某一解析阈值之后来开采和分析(离线)。数据库1004中的信息可由分析工具1006分析，结果可随后反馈到运行时间1002，以提高其要解析的命令的选择和排序以及调用约束子句的顺序。结果，随着更多的话语被解析，可以更好更快地进行解析，而不用改变创作的代码。从广义上讲，系统1000是一种智能系统，能够改善其性能而不用进行重新编码。在一个实施例中，高级作者能够对储存库进行管理和编程。在另一个实施例中，高级作者能够从子句返回表示置信度的概率，而不是简单的true/false值。虽然这可能使编程模型复杂化，但是获得置信度而非布尔值的能力允许作者在统计学上参与语义分析。一般地，歧义出现在作者面前，并且由作者在SPL客户端应用程序中处理。歧义不是由多个解释中的代码结果来处理的。运行时间对解释进行分级并返回给应用程序，直到应用程序规定的最大数量的解释。在一个实施例中，解释的列表被同步返回(作为API调用的一部分)。在另一个实施例中，使用事件来异步地返回解释。运行时间从列表中删除语义上等价的解释。此外，运行时间提供默认的实现方式用于确定两个解释的语义等价性。该默认实现方式可由作者推翻。在一个实施例中，通过比较重新开始语义解释而生成的串来确定语义等价性。然而，还可利用其它技术来确定等价性。一般地，开发者不必编写代码来处理话语中可能发生的所有可能的约束。作者仅仅对他们希望理解和希望处理的约束编写代码。非创建的/不处理的约束被丢弃。换言之，非创建的/不处理的约束被忽略，就好像它们未出现在话语中那样。唯一的例外是Negation和Named约束，它们必须被处理。使用继承来实现语义。可解析的类型都从基本类继承。从而，存在基本实体、基本构架以及基本约束类。基本的可解析的类型具有一个约束子句Default，如表123所示。表123基本的可解析的类型[resolvabletype]{withrestrictionDefault{//如果不处理的/不解析的约束是Negation或Named，则解析失败。否则，约束子句成功。if(Default.TopHypothesis.RestrictionType＝＝Negation||Default.TopHypothesis.RestrictionType＝＝Named){returnfalse；}else{returntrue；}}}基本的可解析的类型中的Default约束对于除了Negation和Named之外的所有约束都是成功的。表124示出了用于MailEntity的语法。表124entityMailEntitydenotedby″mail″{onresolve{withrestrictionLocation<loc＝MailFolder>；}}对于诸如“mailreceivedyesterday”之类的话语，SPL运行时间试图相对于创作的MailEntity的约束子句解析“receivedyesterday”。由于“receivedyesterday”不会映射到Location约束，并且由于在MailEntity中没有Default约束子句，SPL运行时间试图相对于MailEntity的基本类即Entity来解析“receivedyesterday”。Entity中的Default约束子句返回true；因此，MailEntity解析成功。解析成功，就好像话语“mailreceivedyesterday”中仅识别出“mail”一样。如果这不是所希望的行为，那么开发者能够容易地编写代码来拒绝不识别的/不处理的约束，如表125所示。表125带有处理不识别的约束的MailEntityEntityMailEntitydenotedby″mail″{onresolve{withrestrictionLocation<loc＝MailFolder>；//拒绝没有识别的任何东西withrestrictionDefault{returnfalse；}}}这里，在调用基本Entity之前测试MailEntity中的Default约束子句。因此，“mailreceivedyesterday”将不会相对于MailEntity进行成功解析。一般地，onresolve范围外的每个元素都是根据传统的C#规则来处理的。解析子句内的代码也是C#代码。从而，就可能把可解析的类型看作是具有用于确定其构造的专门代码的专门化的C#类。E5.对LOM编程对LOM编程涉及使用LOM提供的约束来实现计划的产出。通过研究一些例子就能够最佳地理解。从而，下面的讨论给出了若干例子，详细研究了更为复杂的语义建模约束和子句(诸如coordination(协调)、compairsons(比较)、negation(否定)等等)，并讨论了某些“最佳的”实践。在上面的部分D中已经讨论了关于何种话语产生何种约束以及约束所包含的信息的详细内容。并非LOM的所有约束类型都暴露于SPL。SPL关注于约束类型来命令和控制各种情况。相反，LOM具有更广泛的适用性。随着新的版本可用，将先前未发现的语义关系暴露为新的约束类型，这将比由于向后兼容的原因而在随后的版本中试图缩小或修改已暴露的约束类型更为容易。在下面的讨论中，我们主要关注于如何使用约束用于以SPL代码建模。一般地，约束向开发者表现为类库，类似于用于Microsoft.Net运行时间的Framework类库(FCL)。Accompaniment约束对伴随着主体的实体进行建模。在实体(Entities)和构架(Frames)上允许Accompaniment。一些例子包括meetingwithmymanager、chatwithBob、emailwithattachments、以及mergeFileAwithFileB。Accompaniment约束包含一个类型Entity的系统槽accomp，表示伴随主体的实体。作者能够抑制能够伴随主体的实体的类型，如表126所示。表126″emailwithattachments″entityMailEntitydenotedby″email″{onresolve{withrestrictionAccompaniment<accomp＝AttachmentEntity>；}}AsBeing约束挑选出动词所作用于的DoneTo.what实体的某一特性。构架(Frames)上允许AsBeing约束。一些例子包括“showstatusasbusy”、“saveastextfile”和“makethefontlarge”。AsBeing约束具有一个系统槽restr，它表示正被挑选出的约束。并非允许任何约束类型来填充该槽，约束的类型被限制到某些特定的约束类型。通过提供在其系统槽内采用各种支持的类型的过载的AsBeing约束，将约束限制到某些特定类型。下面的约束类型是得到支持的(例如)AsBeing<restr＝Modifier>“markmessageaslowpriority”AsBeing<restr＝Possessor>“makethisfilemine”AsBeing<restr＝Ordinal>“putthismessagefirst”在某些实施例中，诸如“loginasmymanager”之类的短语可能解析成功。然而，这将要求允许实体为槽类型。AsBeing约束定义了动词、它的DoneTo.what实体、以及对该实体的约束之间的三位关系。虽然SPL并不强制这种关系的强烈绑定，但是最佳的实践将是如表127所示那样强制该关系。表127″showmystatusasbusy″.denoterBusyWords{English＝″busy″；}entityStatusEntity{onresolve{//对″busystatus″、″statusisbusy″建模withrestrictionModifier<BusyWords>；}}/*下面的AsBeing约束用改变的绑定强度水平来对″showstatusasbusy″建模。*/frameShowStatusFrame<DoneTo.what＝StatusEntity>{onresolve{/*这里，我们既不对DoneTo.what也不对其修饰语作出强绑定*/withrestrictionAsBeing<BusyWords>；/*这里，我们声明与StatusEntity的修饰语更强烈绑定(二位的)，但是我们不对动词的DoneTo.what作出强绑定。*/withrestrictionAsBeing<typeof(StatusEntity.Modifier.mod)>；/*这里，我们声明与构架的DoneTo.what及其修饰语的非常强的绑定(三位的)。*/withrestrictionAsBeing<typeof(DoneTo.what.Modifier.mod)>；}}Cardinal约束对数字量词表示的基数进行建模(例如“3files”)。实体(Entities)上允许Cardinal约束。Cardinal对象上存在一个成员Cardinal.member，它给出了实际的基数值，如表128所示。128″3email″entityMailEntitydenotedby“email”{intCountOfEmail；onresolve{withrestrictionCardinal{CountOfEmail＝Cardinal.number；}}}Comparison约束对实体与另一个明确识别的实体之间的比较进行建模。它并不是用于诸如“abiggerfile”之类的表达式，在这种表达式中要比较的实体是左隐含的(leftimplicit)。为Comparison定义了两种系统槽dimension，它是正在进行的比较所处的量纲，以及compareTo，它是作为比较对象的实体。例如，对于“biggerfilethanmydoc.txt”来说，“bigger”是比较的量纲，“mydoc.txt”是compareTo实体。Dimension是一种约束类型。一般地，Comparison约束允许两个实体在实体的某个特性上进行比较。比较的一些例子包括“abookmoreaboutcatsthandogs”、“maillargerthan10KB”、以及“makefontsmallerthan12pts”。在某些实施例中，可能希望强加这样一种要求，即dimension约束具有依附于它的Degree修饰语。例如，短语“filebigthanmydoc.txt”不应被解析，因为dimension约束不是约束类型。Degree约束对约束的程度进行建模，并在约束(restrictions)上允许Degree约束。它将very、extremely、slightly、almost、more、less、most以及least之类的单词分组在一起。一些例子包括“almostinthebox”、“extremelyred”、“verylarge”和“moretotheleft”。分组的单词被分类成表示“degree-ness”的一组。程度类型如下Morebigger，morerelevantMostbiggest，mostrelevantLesslessrelevantLeastleastrelevantSameasbigHighverybig，extremelypopularLownotverybig应注意到“smaller”被建模成“moresmall”而不是“lessbig”。对于类似于“10KBlargerfile”之类的话语，它被建模成“10KB”(Modifier)修饰“more”(Degree)，以及组合的“10KBmore”概念修饰“large”。相反，话语“10KBlargefile”被建模成对“file”实体的两个Modifier约束“10KB”和“large”(相当于“large，10KBfile”)。表129示出了用于表示“large”的词汇单词的标志牌(denoter)列表的标志牌语法以及用于那些约束所运用于的FileEntity的语法。表129″LARGE″//表示“large”的词汇单词denoterLargeWords{English＝″large″，″big″}/*定义必须具有修饰它的MeasureEntity的Degree。这对类似于“10KBmore”之类的话语建模。*/restrictionExtentDegreeDegree{onresolve{withobligatoryrestrictionModifier<mod＝MeasureEntity>；}}/*定义修饰语必须是LargeWords的Modifier约束*/restrictionLargeModifierModifier<mod＝LargeWords>；/*定义必须具有Degree约束的LargeModifier约束。这对类似于“larger”、“lesslarge”以及“verylarge”之类的话语建模*/restrictionLargeDegreeModifierLargeModifier{onresolve{withobligatoryrestrictionDegree；}}/*定义必须具有ExtentDegree约束的LargeModifier。这对“10KBlarger”建模*/restrictionLargeExtentDegreeModifierLargeModifier{onresolve{withobligatoryrestrictionExtentDegree；}}//将那些约束运用于实体entityFileEntitydenotedby″file″{onresolve{//″largefile″withrestrictionLargeModifier；//″10KBfile″withrestrictionModifier<mod＝MeasureEntity>；//″largerfile″，″extremelylargefile″，″lesslargefile″，andthelikewithrestrictionLargeDegreeModifier；//″10KBlargerfile″withrestrictionLargeExtentDegreeModifier；//″largerfilethanmydoc.txt″withrestrictionComparison<dimension＝LargeDegreeModifier，compareTo＝FileEntity>；//″10KBlargerfilethanmydoc.txt″withrestrictionComparison<dimension＝LargeExtentDegreeModifier，compareTo＝FileEntity>；}}一般地，不必为“morelarge”和“10KBlarger”创建分开的约束类型。它们都能够被置于LargeModdifier下。然后，如果希望的话，如表130所示，对于话语中的“10KBmore”和“more”的存在，诸如FileEntity之类的使用者仅仅检查LargeModifier的RestrictionCollection特性。表130LargeModifierRestrictionLargeModifierModifier<mod＝LargeWords>{onresolve{withrestrictionDegree；withrestrictionExtentDegree；}}entityFileEntitydenotedby″file″{onresolve{/*″largefile″，″largerfile″，″10KBlargerfile″*/withrestrictionLargeModifier{if(LargeModifier.RestrictionCollection(″Degree″).count>0){…}…}}}Doer约束表示作动作的实体，在构架上允许该约束。例如，“Bobopenedthefile”或“thefilewasopenedbyBob”都触发Doer约束。Doer约束包含表示实际doer的类型Entity的一个系统槽“who”。通常，当命令使用构架时，Doer是计算机。但是，当构架被用作基于构架的约束时(例如“fileopenedbyBob”)，则doer的身份变得相关。作者可使用Doer约束来限制doer的类型。所有的基本构架都可具有用asproperty定义的Doer约束，以允许在使用者位置处简化子类型化，如表131所例示。表131基本构架(open)frameopendenotedby″open″behavesasDefaultVerbClass{onresolve{withaspropertyrestrictionDoer<who＝Entity>；}}//使用open构架但不限制Doer.who的类型commandOpenFileCommandusesopen{}entityFileEntitydenotedby″file″{onresolve{//将能够打开文件的实体限制到FileUserEntitywithframeopen<Doer.who＝FileUserEntity>{}}}DoneTo约束表示动作所针对的实体。例如，“openthefile”以及“thefilewasopened”调用DoneTo约束。它包含表示动作的对象的类型Entity的一个系统槽what。所有的基本构架都将具有用asproperty定义的DoneTo约束，以允许在使用者位置处简化子类型化，如表132所例示。表132基本构架Open//基本构架openframeopendenotedby″open″behavesasDefaultVerbClass{onresolve{withaspropertyrestrictionDoer<who＝Entity>；withaspropertyrestrictionDoneTo<who＝Entity>；}}//定义使用open构架的命令，并将DoneTo.what限制到//FileEntitycommandOpenFileCommandusesopen<DoneTo.what＝FileEntity>{}Goal约束对动作或改变的终点进行建模。Frames上允许Goal约束。一些例子包括“sendmailtoBob”、“changepasswordtoXXX”。它具有表示终点的类型Entity的一个系统槽goal，如表133所示。表133″sendmailtoBob″frameMySendFramesend<DoneTo.what＝MailEntity>{onresolve{withrestrictionGoal<goal＝RecipientEntity>；}}Iteration约束对动作的重复进行建模，在Frames上允许该约束。例如，“print3times”触发Iteration约束，如表134所示。表134Iteration约束//″print3times″framePrintFrameprint{intNumberOfIterations；onresolve{withrestrictionIteration{NumberOfIterations＝Iteration.Number；}}}Location约束对位于某处的语义进行建模。Frames和Entities上允许Location约束。例如，“mailinInbox”、“filelocatedonthedesktop”、“searchtheweb”都触发Location约束。它具有表示实际位置的类型Entity的一个系统槽loc，如表135所示。表135Location约束frameSearchFramesearch//″searchtheweb″{onresolve{withrestrictionLocation<loc＝WebEntity>；}}Frames上允许Means约束，并且该约束在部分D中的LOM中详细讨论。Modifier约束允许出现在Frames、Entities和Restrictions上。Modifier约束表示形容词修饰语，诸如“largefile”、“schoolbus”、“fontthatisred”以及“printslowly”。它具有表示形容词的类型Denoter的一个系统槽mod。对于名词-名词复合词，例如“MSNconsumerapplication”，可以把它建模成对Entity(“application”)的Modifier(“MSN”)和Modifier(“consumer”)；对Entity(“application”)的Modifier(“MSNconsumer”)；Modifier(“MSN”)和Entity(“consumerapplication”)；和/或实体(“MSNconsumerapplication”)Named约束表示实体的名字。一些例子包括“Inboxfolder”、“filenamedfoo.txt”、“filewiththenamefoo.txt”、“openfoo.txt”、以及“thefilefoo.txt”。系统槽name是实际名字，如表136所示。表136″filenamedfoo.txt″entityFileEntitydenotedby″file″{onresolve{withrestrictionNamed<name＝string>{//Named.name包含″foo.txt″}}}主体上的Negation约束意味着主体被否定，并非表示其约束子句被否定。一些例子包括“don’tallowmailfromJoe”以及“mailnotfromJoe”。表137示出具有negation的Frame的语法。表137具有Negation的Frame//″lookonthetable″frameLookFramelook{onresolve{withrestrictionNegation{//对″don′tlook″建模}}}restrictionNegatedLocationLocation<loc＝TableEntity>{withrestrictionNegation{//对″notonthetable″建模}}如果话语具有否定，但是SPL代码不具有Negation约束子句，则该话语将解析失败。这与其它约束不同，对于其它约束的情况是如果不被创作则简单地忽略。实体上不允许Negation约束。对于SPL，实体出现的“领域”(universe)取决于实体被如何使用，从而实体的否定没有必要。例如，在诸如“Displayeverythingbutthemail”之类的话语中，领域是应用程序能够显示的每样东西，并非必要地是应用程序所建模的任何实体。在话语“don′tallowmailfromBob”中，可允许或不允许的东西的领域可能仅限于mail，从而mail的否定在该上下文中不应有意义。出于该原因，实体否定将由实体的使用者使用“！”语法来处理。Negation范围消除岐义性是由SPL代码来确定的。例如，“don’tlookonthetable”能够具有下面的否定范围岐义Don’tlookonthetable(butsitonitinstead)否定作用于look构架；Don’tlookonthetable(butlookunderit)否定作用于Location约束；或Don’tlookonthetable(butlookonthechair)否定作用于Location.loc实体解析了哪个语义解释取决于代码如何被创建。实际上，根据创建的代码，所有这些读法都可成功解析，从而产生多个解释。运行时间通常优先考虑范围岐义，从而多个解析被分级。表138对否定建模。表138Negation范围//否定作用于″Look″//″don’tlookonthetable(butsitonit)″frameLookFramelook{onresolve{withrestrictionNegation；withrestrictionLocation<loc＝TableEntity>；}}//对作用于Location的否定建模//″don’tlookonthetable(butlookunderit)″frameLookFramelook{onresolve{withrestrictionNegatedLocation<loc＝TableEntity>；}}//对作用于Location.loc实体的否定建模--″don’tlookonthetable(butlookonthechair)″frameLookFramelook{onresolve{withrestrictionLocation<loc＝！TableEntity>；}}“！”(NOT)语法也能够运用于构架和约束，作为简写概念，如表139所示。表139//下面的对look的否定是等价的。第一个不允许作者插入强制性代码来处理否定，而第二个却可以(即在LookFrame的Negation子句)commandNegatedLookuses！look；frameLookFramelook{onresolve{withobligatoryrestrictionNegation；}}commandNegatedLook2usesLookFrame；restrictionNegatedLocationLocation<loc＝TableEntity>{onresolve{withobligatoryrestrictionNegation；}}//类似地，下面的否定的Location是等价的，除了在Negation子句中具有代码的能力之外frameLookFramelook{onresolve{withrestriction！Location<loc＝TableEntity>；withrestrictionNegatedLocation；}}Ordinal约束对序数数字和表示序列中的某一位置概念的诸如previous之类的其它修饰语进行建模。一些例子包括“firstfile”、“thirdbook”和“lastemail”。Ordinal约束也可运用于其它约束，例如“first3books”，它被建模成Ordinal(“first”)约束修饰Cardinal(“3”)约束，如表140所示。表140Ordinal约束//对″first3″建模restrictionOrdinalCardinalCardinal{intPosition；onresolve{withobligatoryrestrictionOrdinal{Position＝Ordinal.distance；}}}entityFileEntitydenotedby″file″{onresolve{//″firstfile″withrestrictionOrdinal；}}Possessor约束对实体的所有者进行建模，它运用于实体。一些例子包括“mybook”以及“Bob’sbook”。类型Entity的系统槽owner表示实体的所有者。如果清晰地表达出所有者，例如在“Bob’sbook”中，则将相对于owner槽来解析“Bob”。如果所有者是代名词，例如在“herfile”中，则运行时间将试图通过首语主重复(anaphora)解析来解析该代名词。如果该首语主重复解析不能找到所有者实体，则owner槽将为空。表141示出了Possessor约束的语法。表141Possessor约束entityFileEntitydenotedby″file″{onresolve{withrestrictionPossessor<owner＝Entity>；}}实体上允许Quantifier约束，该约束对数量表达式进行建模。一些例子包括“allfiles”、“afewbooks”以及“onethirdofthepage”。下面是quantifier类型Allall((of)the)，every，each(ofthe)Noneno，none(ofthe)Somesome(ofthe)Mostmost(ofthe)，themajorityofManymany(ofthe)Fewfew(ofthe)，notmany(ofthe)Percentageahalfof，1/3of，40％of在某些实施例中，在Quantifier和Cardinal之间可能存在层次关系。SortOrder约束对排序的形式进行建模。一些例子是“sortinalphabeticalorder”以及“displayinreverseorderbyname”。该约束已在上文中关于表56详细讨论过了。Time约束对实际时间表达式进行建模，也就是说能够被转换成时间点和/或时间跨度的时间表达式。例子包括“deleteafter3days”、“mailfromyesterday”和“schedulefortomorrowfrom1-3pm”。Time约束在先前的部分D中已经讨论过了。Topic约束对主题物进行建模。一些例子包括“bookaboutdogs”、“bookregardingdogs”和“bookwiththesubjectdogs”。它具有表示topic串的类型string的一个系统槽topic。该约束在先前的部分D中已经详细讨论过。表142示出了具有Topic的BookEntity代码块。表142BookEntity.//bookaboutdogsentityBookEntitydenotedby″book″{onresolve{withrestrictionTopic<topic＝string>{//topic将包含topic串″dogs″}}}Conjunction(“and”)和Disjunction(“or”)可发生于命令、实体和约束。Conjunction和Disjunction落于Coordination标题内。一般地，协调中的岐义来自于实体和修饰语如何分布在逻辑与和逻辑或上，以及来自于用多个“and”和“or”操作符来对话语中的岐义加括号。类似于Negation，这种岐义消除是由创作的代码来确定的。例如，就话语“findmailandnotescreatedyesterday”，SPL作者可将其建模成a.(Find(mailcreatedyesterday)AND(notescreatedyesterday)).b.(Find(mail)AND(notescreatedyesterday)).c.(Find(mailcreatedyesterday))AND(Find(notescreatedyesterday)).d.(Find(mail))AND(Find(notescreatedyesterday)).“createdyesterday”和“find”是如何与其实体“mail”和“notes”一起分布的，这是由创作的SPL代码来确定的。为了说明的目的，假设作者编写了仅理解类型MailEntity的实体的FindMailCommand和仅理解类型NoteEntity的实体的FindNotesEntity。此外，创作的代码指出MailEntity不具有创建时间的概念，但是NotesEntity却具有，如表143所示。表143Coordination.commandFindMailCommandusesfind<DoneTo.what＝MailEntity>；commandFindNotesCommandusesfind<DoneTo.what＝NotesEntity>；entityMailEntitydenotedby″mail″{}entityNotesEntitydenotedby″notes″{onresolve{withframeCreateNotesFrame；}}frameCreateNotesFramecreate<DoneTo.what＝NotesEntity>{onresolve{withrestrictionTime；}}利用该创作的代码，对于话语“findmailandnotescreatedyesterday”来说，语义分析仅从上面的列表中产生读法(d)(“Find(mail)andfind(notescreatedyesterday)”)。SPL作者不需要理解所有的可能性。作者能够只按照他们的应用程序的语义来考虑(例如，MailEntity不理解创建时间，而NotesEntity理解)。协调的实体被表示为利用“and”或“or”协调类型链接在一起的一列实体。列表中的所有实体必须用相同的协调类型链接在一起。此外，列表中的所有实体必须是相同的编程类型(例如全部为MailEntity元素)。作为一般的规则，运行时间不会产生多个解析来对相同类型的协调产生的岐义加括号进行建模。相反，用相同类型的协调(即全部用“and”或全部用“or”)协调在一起的实体被建模成平坦列表，留给应用程序来确定合适的加括号(如有必要)。例如，采用话语“findmailandbooksandfiles”。这可以意味着“findmailand(booksandfiles)”或“find(mailandbooks)andfiles”。假设所有的实体都是相同的SPL类型，这种加括号岐义不被建模，意味着仅将产生一个可能的读法。该话语被建模成平台列表，其中元素的顺序反映出话语中的顺序。然而，利用混合的“and”和“or”，运行时间产生多个读法来对加括号岐义进行建模。根据创作的代码，这些多个读法可能或可能不导致多个解析出的解释。就话语“findmailorbooksandfiles”而言，由于元素的列表必须用相同的协调类型来协调，下面的运行时间产生下面的可能的读法(假设“mail”、“books”和“files”被解析成相同的SPL类型，并且假设Find命令采用列表)(Find(mailORbooks))AND(Find(files))(Find(mail))OR(Find(booksANDfiles))“find”分布在“and”和“or”上。一般地，混合的“and”和“or”操作符在话语中不常见，从而产生多个解释来对加括号岐义进行建模不应太麻烦。在某些配置中，可能有必要实现Entity列表，可由实体的使用者使用[]语法来规定，如表144所示。表144Entity列表commandFindMailCommandusesfind<DoneTo.what＝[MailEntity]>；entityMailEntitydenotedby″mail″{onresolve{withrestrictionLocation<loc＝[MailFolder]>；}}解释表示话语相对于SPL程序的解析出的解释。每个解析出的解释包含至少一个解析出的命令。话语可导致多个命令用于解释。例如，“findfilefoo.txtandprintit，在该话语中存在两个命令。解释中的命令利用某种条件而链接在一起。当前，它们通过协调类型AND或OR来链接在一起的(其它建模条件也是可能的)。解释中的命令无需是相同的解析出的类型。下面的讨论检验了各种协调例子，以示出元素如何分布在逻辑与和逻辑或上，以及创作的代码如何对协调进行建模。该讨论还检验了用于命令、实体和约束的协调。对于一给定的话语，示出可能的读法来说明岐义和分布。为了重申，SPL作者考虑他们的应用程序的语义(例如myFindcommand可在一列MailEntity上操作)。运行时间试图根据其对元素在逻辑与和逻辑或上的分布的规则的语言理解来将话语映射到所创作的东西。表145中的代码样例用于下面给出的例子。表145示例代码commandOpenMailCommandusesopen<DoneTo.what＝MailEntity>；commandOpenFileCommandusesopen<DoneTo.what＝FileEntity>；commandReplyMailCommandusesreply<DoneTo.what＝MailEntity>；commandCreateMailCommandusescreate<DoneTo.what＝MailEntity>；entityMailEntitydenotedby″mail″ItemEntity{onresolve{withrestrictionSource<src＝SenderEntity>；withrestrictionLocation<loc＝MailFolder>；}}entityNotesEntitydenotedby″notes″ItemEntity；entityJournalEntitydenotedby″journalitems″ItemEntity；entityFileEntitydenotedby″file″；//该实体在这里用于CreatedItemsFrame上的多态性entityItemEntity{onresolve{withrestrictionCreatedItemsFrame<DoneTo.what＝this>；}}//对″createdyesterday″建模frameCreatedItemsFramecreate<DoneTo.what＝ItemEntity>{onresolve{withrestrictionTime；}}上述的代码如下解析命令“FindmailfromBobanddeletethem”FindMailCommand<MailEntity1(“mailfromBob”)>ANDDeleteMailCommand<MailEntity1>命令“Findand/ordeletemailfromBob”被解析成具有四个解释，如下解释1″mailfromBob″分布在“and”/“or”上。FindMailCommand<MailEntity1(″mailfromBob″)>AND/ORDeleteMailCommand<MailEntity1>解释2″mailfromBob″不分布在“and”/“or”上。FindMailCommand<MailEntity1(empty)>AND/ORDeleteMailCommand<MailEntity2(″mailfromBob″)>解释3″mailfromBob″不分布在“and”/“or”上。该解释得自创作的代码，而非得自协调岐义。由于存在3个“find”命令，并且“empty”实体是有效的实体，一个赤裸的“find”能够解析到这些命令中的任一个。FindNotesCommand<NotesEntity1(empty)>AND/ORDeleteMailCommand<MailEntity1(″mailfromBob″)>解释4与解释3相同FindJournalCommand<JournalEntity1(empty)>AND/ORDeleteMailCommand<MailEntity1(″mailfromBob″)>相对于上述创作的代码来说，上面列出的所有解释都是可能的。相对于上面创作的代码来解析命令“FindmailfromBoband/ordelete”，并且导致两个可能的解释，如下解释1″mailfromBob″分布在“and”/“or”上FindMailCommand<MailEntity1(″mailfromBob″)>AND/ORDeleteMailCommand<MailEntity1>解释2″mailfromBob″不分布在“and”/“or”上FindMailCommand<MailEntity1(″mailfromBob″)>AND/ORDeleteMailCommand<MailEntity2(empty)>该例子中的短语与前一例子中的短语之间的唯一差别在于命令“delete”，它具有空的MailEntity。对于上面创作的代码来说，两种解释都是可能的。相对于代码解析命令“Openfileandreplyorcreatemail”，导致下列可能的解释解释1″mail″分布在“or”上，以依附于“reply”OpenFileCommand<Entityl(″file″)>ANDReplyMailCommand<Entity2(″mail″)>ORCreateMailCommand<Entity2>Interpretation2实体无分布OpenFileCommand<FileEntity1(″file″)>ANDReplyMailCommand<MailEntity1(empty)>ORCreateMailCommand<MailEntity2(″mail″)>Interpretation3″file″分布在“and”上以依附于“reply”。相对于上述创作的代码，该读法将不被解析，因为不存在采用FileEntity的“reply”命令。OpenFileCommand<FileEntity1(″file″)>ANDReplyMailCommand<FileEntity1>ORCreateMailCommand<MailEntity1(″mail″)>命令“Openfileorreplyandcreatemail”导致三个可能的解释，如下解释1″file″分布在“or”上以依附于“reply”。相对于上述创作的代码，该读法将不被解析，因为不存在采用FileEntity的“reply”命令。OpenFileCommand<FileEntity1(″file″)>ORReplyMailCommand<FileEntity1>ANDCreateMailCommand<MailEntity1(″mail″)>解释2″mail″分布在“and”上以依附于“rely”OpenFileCommand<Entityl(″file″)>ORReplyMailCommand<Entity2(″mail″)>ANDCreateMailCommand<Entity2>解释3实体无分布OpenFileCommand<FileEntity1(″file″)>ORReplyMailCommand<MailEntity1(empty)>ANDCreateMailCommand<MailEntity2(″mail″)>一般地，由SPL的语义来暗示用于约束的“and”。例如，命令“findmailfromBobandinInbox”引起在MailEntity上激发两个约束，Source约束和Location约束。因此，下面的讨论检验用于约束的逻辑或(disjunction)。除了上面的代码之外，我们将使用下面的一行代码添加理解MailEntity列表的FindMailListCommand。commandFindMailListCommandusesfind<DoneTo.what＝[MailEntity]>；命令“findmailfromBoborcreatedyesterday”解析成下面的解释解释1″mail″分布在″or″上。这导致一列MailEntity。FindMailListCommand<[MailEntity1(″mailfromBob″)ORMailEntity2(″mailcreatedyesterday″)]>如果FindMailListCommand不存在或不成功解析，则“find”将分布在实体上以建立两个FindMailCommandsFindMailCommand<MailEntity1(″mailfromBob″)>ORFindMailCommand<MailEntity2(″mailcreatedyesterday″)>命令“findmailfromBoborcreatedyesterdayandinInbox”如下解释解释1对(mailfromBoborcreatedyesterday)加括号，“inInbox”分布于括号上，即分布于“or”上。FindMailListCommand<[MailEntity1(″mailfromBobandinInbox″)ORMailEntity2(″mailcreatedyesterdayandinInbox″)]>同样，如果FindMailListCommand不存在或不成功解析，则“find”将分布在实体上以建立两个FindMailCommands。解释2对(mailcreatedyesterdayandinInbox)加括号。因为″mailfromBob″与逻辑或连接，就不存在它在括号上的分布。FindMailListCommand<[MailEntity1(″mailfromBob″)ORMailEntity2(″mailcreatedyesterdayandinInbox″)]>同样，如果FindMailListCommand不存在或不成功解析，则“find”将分布在实体上以建立两个FindMailCommands。解释3修饰语不加括号，“mail”分布在所有的修饰语上。FindMailListCommand<[MailEntity1(″mailfromBob″)ORMailEntity2(″mailcreatedyesterday″)ANDMailEntity3(″inInbox″)]>同样，如果FindMailListCommand不存在或不成功解析，则“find”将分布在实体上以建立两个FindMailCommands。除了上面的命令之外，添加一般的FindCommand，能够发现邮件、笔记、日记项的列表。FindCommand示于表146。表146FindCommand.commandFindCommandusesfind<DoneTo.what＝[GeneralEntity]>；entityGeneralEntitydenotedby″mail″，″notes″，″journalitems″ItemEntity{onresolve{withrestrictionSource<src＝SenderEntity>；}}添加该命令确实增加了解释的数量，从下面的例子中可看出。命令“Findmailand/ornotescreatedyesterday”导致下面的解释。解释1″createdyesterday″分布在″and″/″or″上。FindCommand<[GeneralEntity1(″mailcreatedyesterday″)AND/ORGeneralEntity2(″notescreatedyesterday″)]>解释2″createdyesterday″无分布.FindCommand<[GeneralEntity1(″mail″)AND/ORGeneralEntity2(″notescreatedyesterday″)]>如果FindCommand不存在或不成功解析，则“find”将分布在逻辑与上，给出下面两个解释解释3与1相同，但是″find″分布在实体上FindMailCommand<MailEntity1(″mailcreatedyesterday″)>AND/ORFindNotesCommand<NotesEntity1(″notescreatedyesterday″)>解释4与2相同，但是但是″find″分布在实体上FindMailCommand<MailEntity1(″mail″)>AND/ORFindNotesCommand<NotesEntity1(″notescreatedyesterday″)>命令“FindmailfromBoband/ornotescreatedyesterday”导致下面的可能的解释。解释1不同于例子1，修饰语无分布。FindCommand<[GeneralEntity1(″mailfromBob″)AND/ORGeneralEntity2(″notescreatedyesterday″)]>解释2如果FindCommand不解析，则我们获得″find″在实体上的分布。FindMailCommand<MailEntity1(″mailfromBob″)>AND/ORFindNotesCommand<NotesEntity1(″notescreatedyesterday″)>命令“Findmail，notes，orjournalitemscreatedyesterday”导致下面的可能的解释。解释1″createdyesterday″分布在″mail″、″notes″、以及″journalitems″上。FindCommand<[GeneralEntity1(″mailcreatedyesterday″)ORGeneralEntity2(″notescreatedyesterday″)ORGeneralEntity3(″journalitemscreatedyesterday″)]>解释2修饰语无分布FindCommand<[GeneralEntity1(″mail″)ORGeneralEntity2(″notes″)ORGeneralEntity3(″journalitemscreatedyesterday″)]>如果FindCommand不存在或不成功解析，则“find”将分布在逻辑与上，导致下面两个额外的解释。解释3与1相同，但是″find″分布在实体上FindMailCommand<MailEntity1(″mailcreatedyesterday″)>ORFindNotesCommand<NotesEntity1(″notescreatedyesterday″)>ORFindJournalCommand<JournalEntity1(″journalitemscreatedyesterday″)>解释4与2相同，但是″find″分布在实体上FindMailCommand<MailEntity1(″mail″)>ORFindNotesCommand<NotesEntity1(″notes″)>ORFindJournalCommand<JournalEntity1(″journalitemscreatedyesterday″)>命令“Findmailandnotesorjournalitemscreatedyesterday”导致加括号的问题。由于混合的逻辑与类型(即话语中既存在“and”也存在“or”)以及既采用实体列表也采用单独实体的“find”命令的存在，就可能存在许多解释。因此，较佳的是不具有采用某一实体的列表的命令以及采用该单独实体的命令。创建代码以便生成尽可能多的解释。解释集1″createdyesterday″无分布对″mail″和″notes加括号FindCommand<[GeneralEntity1(″mail″)ANDGeneralEntity2(″notes″)]>ORFindJournalCommand<JournalEntity1(″journalitemscreatedyesterday″>在该情况中，还可能有必要产生FindCommand采用FindJournalCommand的位置中的任一元素的解释。对″notes″和″journalitems″加括号FindMailCommand<MailEntity(″mail″)>ANDFindCommand<[GeneralEntity1(″notes″)ORGeneralEntity2(″journalitemscreatedyesterday″)]>无加括号FindMailCommand<MailEntity(″mail″)>ANDFindNotesCommand<NotesEntity(″notes″)>ORFindJournalCommand<JournalEntity(″journalitemscreatedyesterday″)>解释集2″createdyesterday″分布在″or″上以依附于″notes″对″mail″和″notes加括号FindCommand<[GeneralEntity1(″mail″)ANDGeneralEntity2(″notescreatedyesterday″)]>ORFindJournalCommand<JournalEntity1(″journalitemscreatedyesterday″>对″notes″和″journalitems″加括号FindMailCommand<MailEntity(″mail″)>ANDFindCommand<[GeneralEntity1(″notescreatedyesterday″)ORGeneralEntity2(″journalitemscreatedyesterday″)]>无加括号FindMailCommand<MailEntity(″mail″)>ANDFindNotesCommand<NotesEntity(″notescreatedyesterday″)>ORFindJournalCommand<JournalEntity(″journalitemscreatedyesterday″)>解释集3″createdyesterday″分布在所有实体上对″mail″和″notes加括号FindCommand<[GeneralEntity1(″mailcreatedyesterday″)ANDGeneralEntity2(″notescreatedyesterday″)]>ORFindJournalCommand<JournalEntity1(″journalitemscreatedyesterday″>对″notes″和″journalitems″加括号FindMailCommand<MailEntity(″mailcreatedyesterday″)>ANDFindCommand<[GeneralEntity1(″notescreatedyesterday″)ORGeneralEntity2(″journalitemscreatedyesterday″)]>无加括号FindMailCommand<MailEntity(″mailcreatedyesterday″)>ANDFindNotesCommand<NotesEntity(″notescreatedyesterday″)>ORFindJournalCommand<JournalEntity(″journalitemscreatedyesterday″)>在某些情况下，可能希望允许开发者规定他自己的各种语言现象到约束的映射。还可能希望提供“预分析”编程，其中模式影响激发什么约束，这与Default中的“后处理”编程相对。一般地，希望允许某一范围的模式，从基于串的到基于语言的。在一个实施例中，提供一种一般的机制用于规定由LOM开发者内部使用和由SPL开发者外部使用的模式。应允许外部开发者使用一定范围的模式，从简单到复杂。在一个实施例中，如表147所示，运用模式将类似于使用C#属性。表147运用模式entityFlightEntity{[MyPattern(″departingfrom″)]withrestrictionSource<src＝City>{}}一般地，本发明意图尽可能的开放，允许开发者创建他们自己的模式，这可能与任何预定的集合无关。这允许开发者绕过形式化的语义关系(即约束类型)，并创建他们自己所需的。就对条件进行建模而言，在某些实施例中，对条件命令进行建模可能是非常有价值的。一些例子包括“ifBobsendsmemail，deleteit”、“pagemewhenmailcomesfromBob”、“movethefiletoc\docsaftercopyit”以及“warnmebeforepermanentlydeletingamessage”。一般地，对此进行建模的机制应该类似于协调的命令的机制。在可选的实施例中，可通过特殊的约束类型来呈现条件。在某些实施例中，作者可能希望推出约束子句中的多个约束，以便提供更窄范围的解释。作者可通过将数据存储于约束子句中并在success子句中推出它来模拟AND推理，虽然这并不好。作者可通过调出公共函数来模拟OR特性推理。在较佳实施例中，允许作用使用强制性代码(例如调用数据库)来规定一列指示(denotation)。可根据特定的实现方式和根据所涉及的数据库来改变这一概念。一般地，Named约束按照串向作者提供名字。在一个实施例中，作者可以创建名字类，运行时间可对它在给定的话语中识别出的名字列表询问该名字类。例如，考虑短语“findGonewithTheWindmovie”，作者能够创建能把“Gonewiththewind”识别为电影的名字的名字类。在一个实施例中，可向SPL提供Named约束的过载，它采用名字类类型，如表148所示。表148过载的Name约束nameMovieNames{//运行时间能够调用来获得给定的话语中识别出的名字的列表NameListFindRecognizedNames(stringUtterance)；}entityMovieEntitydenotedby″movie″{onresolve{withrestrictionNamed<name＝MovieNames>；}}在较佳实施例中，NamedEntity类型与NamedEntityRecognizer类相关联，如下NamedEntityMovieNameusesMoveNameRecognizer；classMovieNameRecognizerNamedEntityRecognizer{publicoverridevoidRecognize(stringinput，/*otherarguments*/){//识别“input”中的电影的题目的实例}}在较佳实施例中，允许开发者规定要如何处理未知的/未创作的命令(如名词短语)。作者可对应用程序编写代码来在适当的位置处理它们，或要求运行时间为特定的实体调用某一命令(或一组命令)，或提供默认的命令处理程序。在一个实施例中，允许衍生出的类调用基本类的约束子句，如表149所示。表149衍生出的类调用基本类的约束子句entityEntity1{withrestrictionLocation<loc＝SomeEntity>{}}entityEntity2Entity1{/*我们希望对Entity1不处理的所有位置类型提供处理，但对于SomeEntity的位置则转到Entity1。如果我们进行下面的，Entity1Location将不会获得调用，因为该子句将在Entity1的子句之前被尝试。*/withrestrictionLocation<loc＝Entity>{//进行处理}}直接启用(invocation)可能不是所希望的，因为子句的解析大部分是由运行时间控制的。引入public/private/protected/以及其它约束子句，以及试图计算出每个对于解析语义意味着什么，这将添加不必要的复杂性。相反，可添加某些限制(如更多的说明性限制)，告诉解释器如果基本子句成功，则在调用其自己的子句之前调用基本约束子句。编译器可强制具有基本类中的确切的槽类型的子句的存在，如表150所示。表150entityEntity2Entity1{withinvokebaserestrictionLocation<loc＝SomeEntity>{}withrestrictionLocation<loc＝Entity>{}}invokebase的语义是基本类的约束子句(说明性的和强制性的约束)必须在以invokebase修饰的子句被调用之前获得成功。如果希望改变语义(即在基本类之前调用衍生出的类)，则应使用其它语法。“with”子句语法意味着子句规定的限制必须在依附于该子句的代码被执行之前得到满足。某些动词使Goal和Location互换。例如，“printtomyprinter”的含义与“printonmyprinter”相同。根据位置在语法上是如何实现的(即“to”对“on”)，作者不应该必须对两种不同的约束编写代码。两种约束都可以呈现给这些动词，这取决于创作了什么。然而，在某些情况下，可能更容易的是向作者解释“to”将总被实现为Goal，而并不考虑试图为某些动词解释Goal可能是Location，而为另一些动词解释Goal不能是Location。重要的是要理解抽象类型不能被实例化(即不能被直接解析)，但是它们有助于多态性和保持公共功能。如果作者已经为“sendmailtoBob”编写了命令，那么即使在话语中没有“mail”，“sendtoBob”也应当相对于该命令而解析。在某些实施例中，这种功能是令人希望的。如果默认方式允许空实体并把空实体作为有效来对待，作者可在实体的success子句处编写代码来拒绝空实体。如果默认方式不允许空实体(即如果在话语中不存在有实体的证据，那么它将不被解析)，则可引入槽限定符(qualifier)(诸如“任选的”)，允许命令接受空实体。在较佳实施例中，可能不存在包含MailEntity的约束，如果作者注意检查这种情况，则构架或命令将明确地使解析失败。虽然已经参考特定的实施例描述了本发明，但是本领域的技术人员将认识到不用背离本发明的要旨和范围就可在形式上和细节上作出许多改变。附录I-场景MicrosoftOutlook原型在该实施例中，启用MicrosoftOutlook，使用SPL和LOM用于文本和语音输入。多数的启用都是由夏天的实习生进行的，他不具有语言知识或训练。SPL代码设计成编译于并运行于Microsoft.Net平台上，该代码通过Outlook2002对象模型和CDO(协作数据对象)MicrosoftOutlook交互，以进行绑定和执行命令。启用了一些高级搜索，这些高级搜索推出不同的数据源。一些例子包括下面的场景“searchformailthatwassentbypeopleonConferenceGroup”其中我们推出分布列表；“showmailfrommycontacts”其中我们推出联系人文件夹中的人；以及“findmailfrommydirectreports”其中我们推出组织机构图。此外，系统还进行首语重复法解析。例如，“showmeDavid′smanager”后跟“sendmailtohim”向开发者区分出“him”指代“David’smanager”。此外，系统进行如下的高级推理和建模“sendmailtoeveryoneonnlgcoreexceptDavidBradlee”其中我们推出否定；以及“scheduleameetingeveryTuesdaywithmymanagerat2:00for1hour”其中我们相对于复合时间表达式进行建模和编程。附录IIMicrosoftOutlook代码预演下面的讨论从开发者的观点来分析命令。该讨论模拟出开发者在他/她调试该代码时看到了什么。命令是“sendmailaboutpackagetoSeattlegroup”。该句子具有两个可能的含义1.“sendmailaboutpackagetoseattlegroup”其中mail的主语是“packagetoseattlegroup”。2.“sendmailaboutpackagetoseattlegroup”其中mail的主语是“package”，“send”的目的(即，向何处发送邮件)是“seattlegroup”。根据域知识，这些解释中的一个或全部将位于最终的解释列表中。下面是完整的代码。SPL关键字或保留的单词以粗体表示。当通过步骤分析进行时，代码片段将被省去。commandSendMailCommandusesSendMailFrame{onresolve{onbegin{returnOutlook.IsInSendMailContext()；}onsuccess{Outlook.SendMail(SendMailFrame.Mail，SendMailFrame.Targets)；}onfailure{//dowhatevercleanupisnecessary}}}frameSendMailFramesend{publicstring[]Targets；publicMailEntityMail；onresolve{withrestrictionDoneTo<what＝MailEntity>{Mail＝DoneTo.what.MailEntity；}withrestrictionGoal<goal＝DLEntity>{Targets＝Goal.goal.DLEntity.People；}}}entityMailEntitydenotedbyMailEntityWords{publicstringMailSubject；onresolve{withrestrictionTopic<topic＝string>{MailSubject＝Topic.topic.Phrase.topic；}}}entityDLEntitydenotedbyDLEntityWords{publicstring[]People；withrestrictionNamed<name＝Entity>{People＝Outlook.GetDLMembers(Named.name.Phrase.text)；if(People＝＝null){returnfalse；}}}denoteMailEntityWords{English＝noun(″mail″)，noun(″email″)，noun(″electronicmail″)，noun(″e-mail″)；French＝noun(″mail″)，noun(″email″)，noun(″courriel″)，noun(″messageélectronique″)；}denoteDLEntityWords{English＝noun(″distributionlist″)，noun(″list″)，noun(″group″)，noun(″disc″)，noun(″discussiongroup″)；French＝noun(″listededistribution″)，noun(″dl″)；}解释1再次参考该命令，第一个解释是mail的主语是“packagetoseattlegroup”，如下“sendmailaboutpackagetoseattlegroup”获得调用的第一个对象是SendMailCommand的“onresolve”子句的“onbegin”子句。“sendmailaboutpackagetoseattlegroup”commandSendMailCommandusesSendMailFrame{onresolve{onbegin{returnOutlook.IsInSendMailContext()；}onsuccess{Outlook.SendMail(SendMailFrame.Mail，SendMailFrame.Targets)；}onfailure{//dowhatevercleanupisnecessary}}}调用用于该命令的构造函数，执行子句中的代码。如果子句返回“false”，则对该命令的进一步分析停止。在该情况下，如果SendMailContext()返回false(即应用程序当前不处于用于发送邮件的上下文环境中)，则分析停止。假设应用程序能够发送邮件，SPL解释器继续其分析。获得调用的下一个对象是SendMailFrame，因为SendMailCommands说它使用SendMailFrame。解释器直到该短语中的单词“send”映射到SendMailFrame。“sendmailaboutpackagetoseattlegroup”frameSendMailFramesend{publicstring[]Targets；publicMailEntityMail；onresolve{withrestrictionDoneTo<what＝MailEntity>{Mail＝DoneTo.what.MailEntity；}withrestrictionGoal<goal＝DLEntity>{Targets＝Goal.goal.DLEntity.People；}}}对于SendMailFrame来说，没有构造函数，因此调用默认的构造函数。默认的构造函数总能成功。解释器继续解析对“send”的约束。要被调用的第一个约束是“DoneTo”约束，它表示“send”的对象，在该例中为“mail”。“sendmailaboutpackagetoseattlegroup”frameSendMailFramesend{publicstring[]Targets；publicMailEntityMail；onresolve{withrestrictionDoneTo<what＝MailEntity>{Mail＝DoneTo.what.MailEntity；}withrestrictionGoal<goal＝DLEntity>{Targets＝Goal.goal.DLEntity.People；}}}根据该代码，DoneTo的槽(指示出域特定的类型)是MailEntity。换言之，“send”的对象需要是MailEntity。解释器然后试图解析MailEntityentityMailEntitydenotedbyMailEntityWords{publicstringMailSubject；onresolve{withrestrictionTopic<topic＝string>{MailSubject＝Topic.topic.Phrase.topic；}}}如同其它对象一样，解释器调用构造函数。由于没有构造函数，则调用默认的构造函数，默认的构造函数将成功。实体具有的概念是由一列单词表示。在该情况下，解释器通过查看MailEntityWords的英语列表来检查“mail”是否是用于MailEntity的标志牌“sendmailaboutpackagetoseattlegroup”denoteMailEntityWords{English＝noun(″mail″)，noun(″email″)，noun(″electronicmail″)，noun(″e-mail″)；French＝noun(″mail″)，noun(″email″)，noun(″courriel″)，noun(″messageéíectronique″)；}这是语言特定的细节被编码的地方。解释器看到“mail”在列表中。接着，解释器试图相对于MailEntity中编码了什么来解析“mail”上的约束。在该情况下，“aboutpackagetoseattlegroup”是Topic约束，其中实际的topic是“packagetoseattlegroup”“sendmailaboutpackagetoseattlegroup”entityMailEntitydenotedbyMailEntityWords{publicstringMailSubject；onresolve{withrestrictionTopic<topic＝string>{MailSubject＝Topic.topic.Phrase.topic；}}}解释器试图相对于Topic约束的槽来解析实际的题目。“topic”槽是一个串，从而不需要解析。Topic子句中的代码被执行。“sendmailaboutpackagetoseattlegroup”entityMailEntitydenotedbyMailEntityWords{publicstringMailSubject；onresolve{withrestrictionTopic<topic＝string>{MailSubject＝Topic.topic.Phrase.topic；}}}代码将topic的文本存储于成员变量MailSubject中。通过语言对象模型(LOM)来检索topic的实际文本。解释器现在正在处理MailEntity对象。它为MailEntity调用默认的success析构函数，因为并未编码一个析构函数。控制流返回到SendMailFrame，其中代码在DoneTo子句中执行frameSendMailFramesend{publicstring[]Targets；publicMailEntityMail；onresolve{withrestrictionDoneTo<what＝MailEntity>{Mail＝DoneTo.what.MailEntity；}withrestrictionGoal<goal＝DLEntity>{Targets＝Goal.goal.DLEntity.People；}}}该代码仅仅将MailEntity对象存储于成员变量中。{注意这是第二个解释(下面讨论)开始的地方}。解释器进行解析SendMailFrame对象，并调用默认的success析构函数，因为未提供一个析构函数。控制流返回到SendMailCommand。此时，解释器进行解析完整的命令。调用SendMailCommand的success析构函数。commandSendMailCommandusesSendMailFrame{onresolve{onbegin{returnOutlook.IsInSendMailContext()；}onsuccess{Outlook.SendMail(SendMailFrame.Mail，SendMailFrame.Targets)；}onfailure{//dowhatevercleanupisnecessary}}}该代码被执行，并且SendMailCommand对象返回给应用程序。解释2现在参考第二个可能的解释“sendmailaboutpackagetoseattlegroup”用于“sendmailaboutpackage”的解析步骤直到标记点为止都与上述相同，除了topic是“package”而不是“packagetoseattlegroup”之外。解释器知道“toseattlegroup”是“send”上的Goal约束。“sendmailaboutpackagetoseattlegroup”frameSendMailFramesend{publicstring[]Targets；publicMailEntityMail；onresolve{withrestrictionDoneTo<what＝MailEntity>{Mail＝DoneTo.what.MailEntity；}withrestrictionGoal<goal＝DLEntity>{Targets＝Goal.goal.DLEntity.People；}}}该代表说了实际的目标需要是DLEntity，从而解释器试图相对于DLEntity来解析“seattlegroup”“sendmailaboutpackagetoseattlegroup”entityDLEntitydenotedbyDLEntityWords{pubilcstring[]People；withrestrictionNamed<name＝string>{People＝Outlook.GetDLMembers(Named.name)；if(People＝＝null){returnfalse；}}}解释器知道“group”应当是DLEntity的标志牌。它检查标志牌列表DLEntityWordsdenoteDLEntityWords{English＝noun(″distributionlist″)，noun(″list″)，noun(″group″)，noun(″disc″)，noun(″discussiongroup″)；French＝noun(″listededistribution″)，noun(″dl″)；}发现了匹配。解释器然后试图相对于Named约束子句来解析“seattle”。由于Named约束的槽是串，将对其解析“seattle”。Named约束成功，子句中的代码被执行entityDLEntitydenotedbyDLEntityWords{publicstring[]People；withrestrictionNamed<name＝string>{People＝Outlook.GetDLMembers(Named.name)；if(People＝＝null){returnfalse；}}}仅当“seattle”是有效的分布组时，代码才返回“true”。如果不是识别出的分布组，则子句返回“false”。这是域特定的知识如何影响SPL解释器返回的解释。如果“seattle”不是分布组，则该解释的解析将失败，仅将返回第一个解释。解释器进行对命令的解析。根据“seattle”是否是识别出的分布组，将调用succes或failed析构函数。控制流返回到SendMailFrame。如果DLEntity的解析失败，则Goal子句中的代码将不被执行，SendMailFrame解析失败。否则，代码运行，解析成功。frameSendMailFramesend{publicstring[]Targets；publicMailEntityMail；onresolve{withrestrictionDoneTo<what＝MailEntity>{Mail＝DoneTo.what.MailEntity；}withrestrictionGoal<goal＝DLEntity>{Targets＝Goal.goal.DLEntity.People；}}}控制流返回到SendMailCommand，根据SendMailFrame成功与否来调用success析构函数或failed析构函数。commandSendMailCommandusesSendMailFrame{onresolve{onbegin{returnOutlook.IsInSendMailContext()；}onsuccess{Outlook.SendMail(SendMailFrame.Mail，SendMailFrame.Targets)；}onfailure{//dowhatevercleanupisnecessary}}}权利要求1.一种适用于对自然语言的语义元素建模的语言对象模型，其特征在于，该语言对象模型包括用于对自然语言的语义进行建模的一组类型，该组类型与任一特定的自然语言无关。2.如权利要求1所述的语言对象模型，其特征在于，该组类型包括用于对名词短语的语义进行建模的实体类型，即Entity类型。3.如权利要求1所述的语言对象模型，其特征在于，该组类型包括用于对形容词短语的语义进行建模的Entity类型。4.如权利要求2所述的语言对象模型，其特征在于，还包括用于对语义元素的特性进行建模的约束类型，即Restriction类型，其中Entity是Restriction的主体。5.如权利要求1所述的语言对象模型，其特征在于，该组类型包括用于对可表示为动词或名词的事件的语义进行建模的构架类型，即Frame类型。6.如权利要求1所述的语言对象模型，其特征在于，该组类型包括用于对输入串的用户定义的类别进行建模的标志牌类型，即Denoter类型。7.如权利要求6所述的语言对象模型，其特征在于，描述标志牌的数据成员包括一记录，该记录记录了类型Denoter的Denoter对象中的输入串的用户定义的哪个类别在运行时间被分析引擎填充以完成该组类型中的一个类型与自然语言话语的一个元素之间的匹配。8.如权利要求5所述的语言对象模型，其特征在于，Frame类型包括对应于由Frame类型建模的短语的语法头的一个或多个头单词。9.如权利要求5所述的语言对象模型，其特征在于，还包括用于对语义元素的特性进行建模的约束类型，即Restriction类型，其中Entity类型是Restriction类型的主体。10.如权利要求1所述的语言对象模型，其特征在于，该组类型包括适用于对语义对象建模的实体，即Entities；适用于对与一个或多个对象之间的关系相关联的事件进行建模的构架，即Frames；适用于对其它实体、构架或约束的特性或其关系进行建模的约束，即Restrictions。11.如权利要求1所述的语言对象模型，其特征在于，该组类型包括适用于对有名的实体进行建模的有名实体类型，即NamedEntity类型，该NamedEntity类型得自于单独定义的类。12.一种存储有用于对自然语言进行建模的计算机可读数据结构的计算机可读介质，其特征在于，包括语言对象模型，该语言对象模型包括用于对自然语言的语义进行建模的一组类型，该组类型与任一特定的自然语言无关。13.如权利要求12所述的计算机可读介质，其特征在于，语言对象模型的该组类型包括适用于对语义实体进行建模的实体类型，即Entity类型；适用于对事件和相关关系进行建模的构架类型，即Frame类型；以及适用于对实体、构架或其它约束的特性及其关系进行建模的约束类型，即Restriction类型。14.如权利要求12所述的计算机可读介质，其特征在于，语言对象模型的该组类型包括用于对形容词和名词短语的语义进行建模的实体类型，即Entity类型。15.如权利要求14所述的计算机可读介质，其特征在于，语言对象模型的该组类型还包括用于对事件的语义进行建模的构架类型，即Frame类型，每个事件包括可表示为动词或名词的语义事件，其中，Entity类型是Frame类型的主体。16.如权利要求12所述的计算机可读介质，其特征在于，该组类型包括适用于对语义元素的特性进行建模的约束类型，即Restriction类型。17.如权利要求12所述的计算机可读介质，其特征在于，该组类型包括适用于对有名实体进行建模的有名实体类型，即NamedEntity类型，所述NamedEntity类型得自于单独定义的类。18.如权利要求12所述的计算机可读介质，其特征在于，该组类型包括用于对输入串的用户定义的类别进行建模的标志牌类型，即Denoter类型。19.一种用于对自然语言软件应用程序编程的软件开发工具，其特征在于，该软件开发工具包括编程语言，该编程语言包括用于便于自然语言编程的一组编程构造；以及编译器，该编译器包含所述一组编程构造的实例，并产生软件应用程序。20.如权利要求19所述的软件开发工具，其特征在于，所述编程语言还包括原语类型，至少一些原语类型对自然语言的语义进行建模。21.如权利要求19所述的软件开发工具，其特征在于，所述编译器根据软件程序产生说明模式。22.如权利要求19所述的软件开发工具，其特征在于，还包括包括表示原语约束Restriction类型的约束基本类的类库，所述原语约束类型用于对语义元素的特性建模。23.如权利要求19所述的软件开发工具，其特征在于，还包括包括表示原语构架Frame类型的Frame基本类的类库，所述原语Frame类型用于对事件的语义建模。24.如权利要求19所述的软件开发工具，其特征在于，还包括包括表示原语实体Entity类型的Entity基本类的类库，所述原语Entity类型用于对名词或形容词短语的语义建模。25.如权利要求19所述的软件开发工具，其特征在于，所述软件应用程序包括用于在语言上可能的类型之间进行选择的一组可解析的类型，根据解析语义处理每个可解析的类型根据，以判断该可解析的类型的实例是否存在。26.如权利要求25所述的软件开发工具，其特征在于，根据语义规则使可解析的类型的对相关，其中一对可解析的类型中的一个可解析的类型可以使得解析语义失败，而不影响另一可解析的类型的存在。27.如权利要求20所述的软件开发工具，其特征在于，所述一组编程构造包括用于协调非原语类型和原语类型之间的关系的语法框架。28.如权利要求19所述的软件开发工具，其特征在于，所述一组编程构造包括编程语言的关键字，至少一个关键字用于访问一个原语类型。29.如权利要求20所述的软件开发工具，其特征在于，还包括编程语言中定义的非原语类型，其中一个或多个非原语类型是从原语类型继承而来的。30.如权利要求19所述的软件开发工具，其特征在于，运行时间在工作期间对语义模型的话语的构造设置限制。31.一种用于产生自然语言输入的语义解释的框架，其特征在于，包括解释器，用于作为客户端应用程序和一个或多个分析引擎的中介，用以产生对于客户端应用程序有效的自然语言输入的解释；第一组类型，适用于定义解释器与所述一个或多个分析引擎之间的交互；以及第二组类型，适用于定义解释器与客户端应用程序之间的交互。32.如权利要求31所述的框架，其特征在于，还包括描述客户端应用程序的自然语言特征的语义模型的说明模式；其中所述解释器是用所述说明书模式来初始化的。33.如权利要求31所述的框架，其特征在于，还包括语言对象模型，所述语言对象模型包括适用于对自然语言的语义元素进行建模的一组建模类型，该组建模类型独立于任一特定的自然语言。34.如权利要求33所述的框架，其特征在于，所述建模类型包括程序规则，当被解释器调用时，将关于有效性的基于上下文的限制设置于多个语义建模类型中的一个或多个的实例上。35.如权利要求34所述的框架，其特征在于，所述基于上下文的限制造成在实例无效的情况下所述实例被丢弃。36.如权利要求33所述的框架，其特征在于，所述建模类型还包括描述第二组类型的类型之间的关系的约束子句；其中，所述第二组类型包括一部分由开发者创建的语义类型。37.如权利要求36所述的框架，其特征在于，所述约束子句适用于在运行时间允许程序规则确定对关系的接受。38.一种用于对计算机上的自然语言输入的语义建模的词汇语义结构，其特征在于，包括选择用以对自然语言输入的内容进行建模的一组词汇语义类别；以及一种用于将自然语言输入的内容关联到所述一组词汇语义类别中的一个或多个类别的方法。39.如权利要求38所述的结构，其特征在于，所述方法包括用于将自然语言输入的内容关联到所述一组词汇语义类别的语义规则的集合；以及用于将所述语义规则的集合运用于所述自然语言输入的过程。40.如权利要求38所述的结构，其特征在于，所述方法包括用于跨所述一组词汇语义类别将所述自然语言输入规格化的语义规则的集合，所述语义规则的集合适用于识别语法类的变量和修饰语以及它们的语义，并将识别出的变量关联到所述一组词汇语义类别中的一个或多个类别。41.如权利要求38所述的结构，其特征在于，所述方法适用于跨语法类别将自然语言输入规格化。42.如权利要求38所述的结构，其特征在于，所述一组词汇语义类别包括表示自然语言输入的一部分的一个或多个语法类别；表示自然语言输入内的该部分的功能的一个或多个语义角色；以及所述一个或多个语法类别和所述一个或多个语义角色之间的映射。43.用于自然语言编程的适用于对自然语言的语义进行建模的一组可解析的类型，其特征在于，该组可解析的类型包括命令类型，用于对自然语言中的命令建模；以及约束主体类型，用于表示自然语言输入中的非命令元素，所述约束主体类型适用于根据自然语言输入关联到所选择的命令类型或及物地与一所选择的命令类型相关联的其它约束主体类型，所述约束主体类型适用于在运行时间作为所选择的命令类型的限制的主体。44.如权利要求43所述的一组可解析的类型，其特征在于，映射到自然语言输入的类型的实例继承自命令类型或约束主体类型。45.如权利要求43所述的一组可解析的类型，其特征在于，非命令元素包括语言元素和自然语言的语言元素之间的相互关系。46.如权利要求43所述的一组可解析的类型，其特征在于，还包括部分由所述一组可解析的类型定义的解析语义，所述解析语义定义了用于在运行时间解析所述一组可解析的类型的所选择的类型的实例的有效性的程序规则。47.如权利要求43所述的一组可解析的类型，其特征在于，所述约束主体类型包括用于对可被表示为动词或名词的语义事件进行建模的构架Frame类型；用于对名词短语或形容词短语的语义进行建模的实体Entity类型；以及用于对语义元素的特性进行建模的约束Restriction类型。48.如权利要求43所述的一组可解析的类型，其特征在于，所述可解析的类型还包括与所述一组可解析的类型的选择的类型相关联的程序代码，用于影响对象的解析；以及适用于设置于那些选择的类型的对象上的限制。49.如权利要求54所述的一组可解析的类型，其特征在于，自然语言输入的可能的解释包括任选地与一个或多个约束主体类型相关联或与一个或多个非可解析的类型相关联的命令Command类型。50.如权利要求49所述的一组可解析的类型，其特征在于，可能的解释的解析包括以约束主体类型和解析语义之间的相互关系确定的顺序来启用Command类型和所述一个或多个约束主体类型。全文摘要提供一种用于对自然语言软件应用程序进行编程的软件开发工具。该软件开发工具包括编程语言和编译器。编程语言具有用于便于自然语言编程的一组编程构造。编译器适用于采用包含所述一组编程构造的实例的软件程序，并产生软件应用程序。文档编号G06F17/27GK1716192SQ200510066000公开日2006年1月4日申请日期2005年4月22日优先权日2004年4月23日发明者D·J·帕金森,D·J·希泊尔伦,M·J·B·欧尔森,M·V·加尔家格诺,R·C·沙哈尼,张素琴申请人:微软公司