CN1716192A - 语义编程语言和语言对象模型 - Google Patents

语义编程语言和语言对象模型 Download PDF

Info

Publication number
CN1716192A
CN1716192A CNA2005100660002A CN200510066000A CN1716192A CN 1716192 A CN1716192 A CN 1716192A CN A2005100660002 A CNA2005100660002 A CN A2005100660002A CN 200510066000 A CN200510066000 A CN 200510066000A CN 1716192 A CN1716192 A CN 1716192A
Authority
CN
China
Prior art keywords
type
constraint
language
entity
semantic
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CNA2005100660002A
Other languages
English (en)
Other versions
CN100501668C (zh
Inventor
D·J·帕金森
D·J·希泊尔伦
M·J·B·欧尔森
M·V·加尔家格诺
R·C·沙哈尼
张素琴
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Microsoft Technology Licensing LLC
Original Assignee
Microsoft Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Microsoft Corp filed Critical Microsoft Corp
Publication of CN1716192A publication Critical patent/CN1716192A/zh
Application granted granted Critical
Publication of CN100501668C publication Critical patent/CN100501668C/zh
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00—Handling natural language data
    • G06F40/30—Semantic analysis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/20—Software design
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/31—Programming languages or programming paradigms
    • G06F8/315—Object-oriented languages
    • G—PHYSICS
    • G10—MUSICAL INSTRUMENTS; ACOUSTICS
    • G10L—SPEECH ANALYSIS OR SYNTHESIS; SPEECH RECOGNITION; SPEECH OR VOICE PROCESSING; SPEECH OR AUDIO CODING OR DECODING
    • G10L15/00—Speech recognition
    • G10L15/08—Speech classification or search
    • G10L15/18—Speech classification or search using natural language modelling
    • G—PHYSICS
    • G10—MUSICAL INSTRUMENTS; ACOUSTICS
    • G10L—SPEECH ANALYSIS OR SYNTHESIS; SPEECH RECOGNITION; SPEECH OR VOICE PROCESSING; SPEECH OR AUDIO CODING OR DECODING
    • G10L15/00—Speech recognition
    • G10L15/08—Speech classification or search
    • G10L15/18—Speech classification or search using natural language modelling
    • G10L15/1815—Semantic context, e.g. disambiguation of the recognition hypotheses based on word meaning
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99941—Database schema or data structure
    • Y10S707/99944—Object-oriented database structure

Abstract

提供一种用于对自然语言软件应用程序进行编程的软件开发工具。该软件开发工具包括编程语言和编译器。编程语言具有用于便于自然语言编程的一组编程构造。编译器适用于采用包含所述一组编程构造的实例的软件程序，并产生软件应用程序。

Description

语义编程语言和语言对象模型
技术领域
本发明涉及用于对自然语言的语义进行建模的方法。更为具体地，本发明涉及适合于对自然语言的语义进行建模用于软件应用程序开发的一组类型。
背景技术
自然语言是由人类创造的语言(与计算机语言或其它人工语言不同)，它包括全部习惯用语、话语或文本的假设和暗示。在自然语言处理的环境中，命令和控制系统处理自然语言话语或文本，并试图识别和解释该话语或文本，以导出可使用的解释。
传统上，用于提供自然语言命令和控制的一种技术涉及对预先编码的命令的静态识别。例如，商业上可获得的语音一文本程序允许用户使用简单的命令发起预先编码的操作，例如save file(保存文件)。然而，除非使用了正确的命令，否则这种程序一般不能处理这些命令。换言之，编码成识别命令save file(保存文件)的应用程序不能正确地理解store file(存储文件)。
类似地，问/答类型的应用程序一般包括预先编码的短语或术语，以便便于搜索和检索类型的功能。然而，为了成功，传统的实施方式要求在话语或文本中使用特殊的搜索项，因此不能充分地考虑人类语言的丰富性。
对自然语言应用程序编程极其困难。一般地，编程者知道如何以计算机语言编码，但是几乎没有图解语句结构和/或进行语言分析的经验。而且，将为英语编码的自然语言软件应用程序扩展到对其它语言起作用不仅要求对软件应用程序重新编码，还要求对任何相关的语言分析引擎重新编码。这使得对自然语言应用程序进行编程变得极其困难，并可能代价非常高。
发明内容
在一个方面中，提供一种用于对自然语言软件应用程序进行编程的软件开发工具。该软件开发工具包括编程语言和编译器。该编程语言具有用于便于自然语言编程的一组编程构造。该编译器适用于采用包含所述一组编程构造的实例的软件程序以及产生软件应用程序。
在一个可选的方面中，提供一种创建允许自然语言的软件应用程序的方法。从用于便于自然语言编程的一组编程构造中创建程序。该程序描述了依赖于自然语言输入的软件应用程序中的特征。该程序被编译成软件应用程序。
在另一方面中，语言对象模型适用于对自然语言的语义元素进行建模。语言对象模型包括语言表达式的一组类型和类，设计这些类型来对语言表达式建模。在一个实施例中，该组类型中的每个类型对应于话语的语言上有含义的元素。
在另一个方面中，计算机可读介质存储用于对自然语言建模的计算机可读数据结构。一组类型适用于将类表示为抽象对象。类表示分类化的语言表达式，可对应于自然语言话语的语义上有意义的部分。
在另一个方面中，一种用于产生自然语言输入的语义解释的框架包括解释器和一组类型。该解释器适用于作为客户端应用程序和一个或多个分析引擎之间的中介，用以产生对客户端应用程序有效的自然语言输入的解释。该组类型适用于定义解释器与所述一个或多个分析引擎之间的交互。
在另一个方面中，提供了用于将自然语言输入的解释例示成客户端应用程序的自然语言特征的框架。用与客户端应用程序相关联的说明模式来初始化解释器。解释器适用于接收自然语言输入，并与一个或多个自然语言分析引擎通信，以产生自然语言输入的解释。解释器适用于在客户端应用程序中例示出一个或多个解释。
在另一个方面中，提供一种用于对计算机上的自然语言输入的语义进行建模的词汇语义结构。选择一组词汇语义类别来对自然语言输入的内容建模。一种方法将自然语言输入的内容关联到该组词汇语义类别中的一个或多个类别。在不同的实施例中，词汇语义结构跨语言、跨语言类别、跨应用程序、以及跨适用于产生某种类型的语法类别的系统，将自然语言输入规格化。
在另一个方面中，提供一种用于创建允许自然语言的软件应用程序的方法。从用于便于自然语言编程的一组编程构造中创建程序。该程序描述了依赖于自然语言输入的软件应用程序中的特征。该程序被编译成软件应用程序。
在另一个方面中，提供一种用于开发允许自然语言的软件应用程序的系统。可解析的类型定义语言元素的抽象表示和自然语言输入的语言元素之间的相互关系。解析语义定义用于解析允许自然语言的软件应用程序中的可解析的类型的实例的有效性的程序规则。
在另一个方面中，提供一种用于确定允许自然语言的软件程序中的可解析的类型的实例的有效性的方法。汇编了列出自然语言输入的推荐的解释的推荐解释列表。每个推荐的解释具有一个或多个命令，以及映射到可解析的类型的非命令元素。与每个推荐的解释相关联的实例的有效性在允许自然语言的软件应用程序中确定。
附图说明
图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框架的应用程序中，在运行时间创建解释器实例，并用描述依赖于自然语言输入的客户端应用程序中的特征的语义模型的说明模式(declarative schema)。该说明模式是由开发者与应用程序代码一起创建的，它描述了由开发者创建的以及从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转到分析引擎，用于相对于LOM 216进行对文本输入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运行时间库(C RuntimeLibrary)和标准模板库(STL)构成例如Microsoft Visual C++标准库之类的方式，其中Microsoft Visual C++是由华盛顿州雷蒙德市的微软公司创建的、设计用于便于软件开发使用的应用程序。术语Microsoft和Visual C++是华盛顿州雷蒙德市的微软公司所拥有的商标。
SPL中的语义上有含义的类型是那些参与对输入的话语的语义进行建模和参与那些输入的话语所对应的应用程序命令的建模的类型。语义上有含义的类型是SPL设计者能够从他们的应用程序域中得出的和专用于他们的应用程序域的类型。SPL中的语义上有含义的类型是实体(Entity)、构架(Frame)、约束(Restriction)、命令(Command)、以及标志牌对象(Denoter object)。SPL中的功能类型是短语(Phrase)和槽(Slot)。这些类型中的每一个将在下面分开讨论。
一般来说，SPL框架类型定义了客户端应用程序、SPL解释器以及一个或多个自然语言分析引擎之间的交互的所有方面。短语“交互的所有方面”指的是各种组件必需实现的接口、各种组件继承的基类、以及系统的组件之间传递的数据的类型。在一个实施例中，框架类型是以华盛顿州雷蒙德市的微软公司创建的.NET框架中的类型来实现的。可把SPL类型安排成若干名字空间。在一个实施例中，SPL类型被安排成若干名字空间，它们是例如System.NaturalLanguageServices或System.NaturalLanguage名字空间的所有子名字空间。这里所使用的“名字空间”指的是定义名字(标识符)的上下文环境。在一给定的名字空间内，所有的名字必须是唯一的。
为了清楚起见，下面的讨论介绍SPL类型，详细介绍LOM，然后返回到详细介绍SPL。贯穿全文，在适当的地方使用例子来例示出本发明。对于大多数的部分，例子往往是得自于简单的自然语言话语“Send mail to Bob”(向Bob发邮件)。给出该话语，根据LOM编写的和使用SPL的应用程序能够根据该文本输入产生解释。然后，可相对于自然语言应用程序来解析所产生的解释，以识别和执行指令的实际解释。
实体(Entity)是类型Entity的对象，意味着实体能够包含数据成员、性质和方法。SPL实体是那些类型从类Entity得出的并主要用于对名词短语和形容词短语的语义进行建模的对象。SPL实体可通过“with”语法来主控构架(frame)或约束(restriction)(下文描述)。此外，SPL实体可包括任选的“Denoted By”(由……表示)子句，该子句引入了类型“Denoter”(下文描述)的有特权的数据成员。由“Denoted By”子句引入的有特权的数据成员可由SPL解释器使用，将实体映射到实际自然语言单词。
构架(Frame)是类，它对语义事件的语义建模，其中语义事件可被表示为动词或名词。SPL构架(frame)是从Frame中得出的类。一般来说，Frame可适用于实体，所以Frame可具有“Denoted By”子句以及包含构架变量(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对象充当实体的位置表(localization table)。类似于命令，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)对于单词的不同形式表
                       表1：CoordinatedEntity
       Entity CoordinatedEntity
       {
         Entity entities[]；
         CoordRelation relBetweenEntities；
       }
       enum CoordRelation
       {
         And，
         Or，
         ExclusiveOr
       }
关于协调的LOM的目标是将语义不相关的括号多义性最小化。从而，例如，文本输入X and Y and Z被表示为平坦列表X and Y and Z，而不会在右联X and[Y and Z]和左联[X and Y]and Z之间产生歧义。然而，当存在确实的括号多义性时，LOM保持该多义性。例如，对于短语show cars with 4WD and ABS or AWD，4WD and[ABSor AWD]和[4WD and ABS]or AWD都是可能的。当然，在该特定情况下，仅第二种表示可能是有意义的，但是，这仅是用于应用程序来决定，而非由LOM决定。
LOM中把代词建模成类型“PronounEntity”的对象。表2示出根据本发明的实施例的代词实体的示例。
                      表2：PronounEntity.
       entity PronounEntity
    {
       Entity potentialAntecedents[]；
    }
LOM通过PronounEntity内的“potentialAntecedents”字段提供用于首语重复解析(anaphora resolution)。术语“首语重复”(anaphora)指的是涉及相同Entity的多个单词或短语之间的关系。可用作为语言上可能的先行词的预先解析的Entity对象列表来填充potentialAntecedents字段。该列表以似然性的降序排列。应用程序开发者可通过附于每个Entity的类型“AgreementInfo”的对象来访问作为首语重复解析中的最重要的因素的语言一致信息。表3提供了构造AgreementInfo的例子。
                  表3：STRUCT AgreementInfo
       struct AgreementInfo
       {
         bool firstPerson；//第一人称
         bool secondPerson；//第二人称
         bool thirdPerson；//第三人称
         bool singular；//单数
         bool plural；//复数
         bool feminine；//女性
         bool masculine；//男性
         bool neuter；//中性
         bool honorific；//表示尊敬
         bool humble；//表示谦逊
       }
只有相对于给定实体明显为真的AgreementInfo字段才与该实体的AgreementInfo对象相关联。换言之，LOM不试图表示转折的一致特征。例如，术语cat将使得“thirdPerson”和“singular”与其一致对象相关联。在法语中，术语“vous”与“secondPerson”相关联。在西班牙语中，术语perro是“thirdPerson”、“singular”以及“masculine”，对于给定的实体perror来说，这三种属性中的每一个都毫无疑问的是真的，因此与实体的一致对象相关联。
诸如可用作为独立NP的“this”和“that”之类的指示代词成为类型DemonstrativeEntity的对象。表4给出了实体DemonstrativeEntity的例示。
                   表4： DemonstrativeEntity.
        entity DemonstrativeEntity
        {
          DemonstrativeType type；
        }
        enum DemonstrativeType
        {
          Near，
       Middle，
       Far
     }
由于类型DemonstrativeEntity的对象是从Entity导出的，因此，它们继承了AgreementInfo对象，允许区分类似于this和that之类的单词。一般来说，这种继承允许系统能够在英语、法语、德语、日语、西班牙语以及许多其它语言的这种元素之间正确地进行区别。
另一相关的类型是NamedEntity类型。用于NamedEntity的语法如下。
namedentity                OlapNamedEntity                 uses
ExcelAddin.FuzzyOlapCubeRecognizer；
一般来说，NamedEntity类型基于单独定义的一个类，该类是从NamedEntityRecognizer类继承来的。NamedEntityRecognizer类型连同模式一起传递，分析引擎能够使用它们来回调客户端代码，以动态地识别话语中的应用程序对象引用。
b.LOM构架(Frame)
在一个实现中，对于所有的语言，字句成为LOM构架；然而，对于所有的实现方式，这并不总是真的。在概念上，构架从字句得出，但是在输入中并不需要确实存在字句。构架的头单词是作为字句的头的动词的词条。例如，分析短语“Sendmail to Bob”将导致“Send mail”与LOM构架相关联，其中“Send”是作为字句的头的动词的词条，因此是该构架的头单词。
应理解，可把约束(Restrictions)概念化成提供默认的行为。然而，未必强制这种行为。该功能是特定于实现方式的。
槽(Slots)可通过实体或构架来填充，从而默认的slots可以是名词短语或字句。此外，NP可以由空代名词(PRO)作为头。如果PRO指向另一字句中的对象，该字句的头将被解释成NP实体的头。如果PRO没有对象，则它将被解释为某一实体(诸如someone或something)。
在一个实施例中，假设字句中包含主语，该字句的主语满足“Doer”约束。如果没有主语，则没有“Doer”约束。“Doer”代表某一事件中的第一参与者，语义上宽松地表示为doer(做...的人)、agent(主动者)、actor(参与者)、instigator(煽动者)或动词命名的事件或状态的原因。在字句的一部分映射到构架的“doer”约束的情况下的动词字句的例子示于表5。
       表5.Verb Clause with a Subject(带有主语的动词字句).
Instant message opens.
Robin is on my buddies list.
Amazon offers wish list capabilities.
[PRO] open the file
Having a program associated with a file ensures easy opening.
划底划线的单词或短语是映射到Doer槽的单词或胆俞。在及物和不及物构架中，这都是真的，对应于及物和不及物动词。
如果字句中存在宾语，宾语映射到表示事件中的第二语法上的参与者的称为“DoneTo”约束的构架的第二槽。可把语义宽松地理解为指代被事件或由动词命名的状态影响的对象。表6中下划线的短语映射到“DoneTo”约束。
               表6：The″DoneTo″Restriction
Outlook has my  buddies list.
Amazon offers  wish list capabilities.
[PRO] open  the file.
Preferences include  having a program associated with a file.
在一个实现中，间接宾语可被理解为动作的受益人。在一个实施例中，间接宾语可被映射到Beneficiary约束。Beneficiary约束一般对表示某一事件是为谁的利益或在谁的地方进行的那个人的动词变量进行建模。表7中包含的下划线的代名词简要地例示出beneficiary槽。
                  表7：Beneficiary Slot.
                   Open  me a new file.
                   Play  her some tunes
Beneficiary约束(或在替代的实施例中是“slot”)可设置到对被解释为beneficiary的名词短语进行建模的实体。表8例示出beneficiary约束的代码块。
                  表8：Beneficiary Retriction.
restriction Beneficiary<benef：＝Entity>
     {
     }
beneficiary约束有时被称为“施益体的”(benefactive)，与英语中的分配(allocation)相重叠，尤其是对于“for”介词短语的单数宾语更是如此。某些重叠也发生在其它语言中。当运用于构架时，通过下面的语句，beneficiary约束是显而易见的。
I baked a cake for my mother.
PP[for]
一般来说，beneficiary约束对大多数语言中的动词变量进行建模。表9例示出若干样本语言中的beneficiary约束。
            表9：Beneficiary Restriction.
英语：
      介词for
      适用于不作为目标的间接宾语(不能由″to″前置短语来解释)
      I baked  her a cake->I baked a cake  for her.
NOT：I gave her a book(cf.I gave a book to her，cf.目标)
      I baked a cake for her.
      I baked her a cake.
法语：
      介词pour
德语：
      间接宾语：
          Ich schicke ihr eine Nachricht.
      介词für
          Das ist eine Nachricht für sie.
日语：
      NP-のためのNP
      NP-のために…VP
      固定分句(小字句)的主语结构，与英语bake a cake[for her to have]
      比较。相反，取目的变量的动词用与格虚词来标记，例如give her-DAT
      book-ACC
西班牙语：
      介词para
      Trajimos la lista de regalos para Fernando.
一般来说，约束可以是主语、直接宾语、间接宾语、间接变量、修饰语等。在SPL中，构架可采用任何约束(除了下面描述的例外)。然而，LOM使用语法以两种方式来提出约束。第一种是：间接变量可以是与词汇语义结构类相关联的约束类型，动词是该类的成员(这在下文中详细描述)。第二种是：间接变量可以与独立动词相关联；也就是说，该变量不具有对其子句头的任何约束关系。变量被分配给默认约束(Default restriction)(下文讨论)，并由它们的词汇头来识别。
构架的协调是以两种不同的方式进行的，这取决于上下文环境。“顶级”(Top-level)协调构架(即从主语动词(matrix verb)得出的)被表示为类型CoordinateFrame的对象，与CoordinateEntity(上文所述)相平行。表10示出一个示例性的实例。
                表10：CoordinatedFrame.
        frame CoordinatedFrame
        {
            Frame frames[]；
            CoordRelation relBetweenFrames；
        }
一般来说，(通过“with”语法)呈现于实体上的构架表现为约束。如下所述，这指的是通过触发多个约束来表示逻辑与(conjunction)，而通过在主实体外增加到CoordinateEntity来表示逻辑和(disjunction)。
如先前所述，在一个实施例中，构架可充当实体上的约束，以对自然语言关系子句进行建模。当构架通过“with”关键字而依附于实体时，构架对实体强加了约束，这被称为是“基于构架的约束”。在大多数情况下，构架中的一个槽对应于被中心名词限制的自然语言间隙。在LOM中，这转化为基于构架的约束在其一个槽中接收对其主实体的引用。将对主实体的引用包含于基于构架的约束的一个槽中可被称为是“反向引用”。由于这种“反向引用”允许再进入别样的树形LOM表示，对应于间隙的槽使其isBackreference标志设置为真(该标志仅仅便于走过LOM表示的过程)。例如，在下面的表11中，相对于短语“files that Billy opened yesterday”来解析基于构架的约束。
       表11：基于构架的约束
       Entity1(file)
          |
          open<Entity2(Billy)，{isBackreference}
            Entityl(file)>
              Time([1 day back] OFFSET FROM [now])
在表12中，相对于短语“people who work at Company”来解析基于构架的约束。
      表12：基于构架的约束
      Entity1(people)
        |
        work<{isBackreference}Entity1(people)>
           |
           Location<Entity2(Company)>
在表13中，相对于短语“people I have sent mail to”来解析基于构架的约束。
      表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语义中并没有便捷的类似处理方式。于是，这种逻辑或“冒泡”(bubble up)到位于约束(通常为主体)上的下一实体或构架，在该级上产生CoordinateEntity或CoordinateFrame对象。
例如，对于短语“mail from Kim or to Robbin”来说，存在一个实体主体即“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)约束对某个组中的额外的成员进行建模。通常，可用逻辑与来解释伴随物。例如，短语customers along with their birthdates可被解释为customers and their birthdates。对于互补事件表示(reciprocal-event-denoting)实体，伴随物约束对事件中的额外的参与者进行建模。通常，这种名词具有对应的构架(例如correspond、meet、chat、等等)。伴随物约束还对名词短语中的介词短语进行建模，例如correspondence  with my manager、an appointment  with Kim、meetingwith Tim(添加强调)、a chat  with Sue等等。根据本发明的实施例的Accompaniment约束的语法的例子例示于表15中。
                    表15：ACCOMPANIMENT.
restriction Accompaniment<accomp：＝Entity>
     {
     }
Accompaniment约束还能够对Frame的上下文中的其它的who或what参与者进行建模。例如，短语“chat with Robin”利用短语“with Robin”作为accompaniment约束来调用“Chat”构架。
Accompaniment约束还可被分配给对被解释为伴随着主体的名词短语进行建模的实体中内的槽。可选地，accompaniment约束可被设置到“who”或“what”槽。
在某些情况中，希望将“with”情况的列表编译成语义上相当于逻辑与的实体列表。就其它语言中也存在等价的accompaniment表达式来说，按需为那些表达式编译实体列表可能是有用的。
就可被建模成伴随物的所有格来说，也希望将它们包含于实体列表中。例如，“email with attachments”(带有附件的电子邮件)是伴随物形式的所有格，而与作为所有人形式的所有格的“email’s attachments”(电子邮件的附件)相对。在某些情况下，诸如“an email that has attachments”之类的短语也可被建模成伴随物约束。主语互换也可调入伴随物约束中。主语互换的例子是“John chatted with Mary”，这与“John and Mary chatted”相对照。在词汇上，这两种表达式都容易被识别。类似地，宾语互换，例如“Merge File A and File B”与“Merge File A with File B”相对照，是可容易识别的。可能希望将这种主语和宾语互换结合于LOM中的伴随物规格化中。
伴随物约束延伸及许多中语言中，特别是在诸如“along with”或“together with”之类的介词短语方面。在法语、德语、日语、西班牙语和其它语言中，可采用类似的伴随物约束。表16例示出这种伴随物。
  表16：Accompaniment Restrictions
       (along|together)PP[with](英语)
       ((tout)ensemble)PP[avec](法语)
       PP[mit]+Dative(德语)
         ″Er kommt mit den Kindern.″
       Entity Hosts：(日语)
         NP-とのNP
         NP-のあるNP
       Frame hosts：(日语)
         NP-と…VP
         NP-と…一緒に…VP
       PP[con](西班牙语)
诸如表17中所例示的分配约束(allocation restriction)一般对向其分配主体实体(host entity)的实体进行建模，或者对代表主体实体而存在或创建的实体进行建模。
 表17：Allocation Restriction.
 restriction Allocation<alloc：＝Entity>
 {
 }
当分配约束对向其分配主体实体的实体进行建模时，这种约束的例子可以是“onlineprofile  for each fund”、“schools  for linguistics”或“application  for a job”。下划线的部分说明了该分配约束。当分配约束对代表主体实体而存在或创建的实体进行建模时，语义话语可以是“a cake  for my mother”或“party  for my manager”。在两种情况中，分配约束都对实体添加了特征。表16例示出分配约束的一个例子的代码。分配约束可设置到对解释为分配给使用槽的主体的名词短语进行建模的实体。
一般来说，分配约束可运用于向单数实体以及复数实体的分配。英语中，分配约束处于与受益人的互补分布中。仅实体主控分配。仅构架主控受益人，特别是对for介词短语的单数宾语。英语中，可以多种方式使用该介词。例如，在packetsfor a specific destination中，它表示目的；而在application  for which you are enabling authorization checking中，它是一种类型的分配。类似地，tabs  for taskpad views、checkbox  for the type of service、以及area code  for Madison，WI都表示分配约束。在德语中，für尤其表示分配。在西班牙语中，对应的介词是para：短语“una escobapara la cocina”例示出一分配约束。
对Frame的“AsBeing”约束对分配给构架的对象槽的性质或能力进行建模。仅对形容词短语建模的修饰语约束映射到约束版本。表18提供了AsBeing约束的两个代码样本。
  表18：AsBeing Restriction.
  restriction AsBeing<asbeing：＝Entity>
  {
  }
  restriction AsBeing<asbeing：＝Modifier>
  {
  }
一般来说，LOM对话语的词条之间的语义关系进行建模。“AsBeing”约束试图对介词短语“as”进行建模。例如，短语“Save the file as a text file”类似于“Savethe file to a text file”。“Set my status as busy”类似于“Set my status to busy”。AsBeing约束对分配给构架的对象槽的性质或能力进行建模。再次，AsBeing约束将约束“as”建模成作为分配给构架的对象槽的性质的“text file”。可选地，可能将该功能运用于Denoter而不是运用于Entity。表19例示出英语、德语、日语和西班牙语中的AsBeing对象的例子。
  表19：AsBeing例子
  英语
       PP[as]：Save the file as text.
       Make me an administrator.
       Mark all messages unread.
  德语
       PP[als]：Speicher die Datei als Text.
  日语
       -to complementizers
       -to site adverbials
  西班牙语
       PP[for]：para
基数(cardinal)约束是对由数字量词表示的基数进行建模的约束。槽和字段可设置到数字量词的浮点值。诸如“an”和“a”之类的不定冠词可在某些情况下被建模成“one”。表20例示出基数约束。
  表20：Cardinal Restriction.
  Restriction Cardinal
  {
       float number；
  }
此外，希望在某些情况下阻止时间单位的基数(诸如“in 3hours”等等)。特别地就时间单位而言，阻止基数约束不应与时间类型的对象(至少在英语中)相冲突，因为引入时间量一般要求介词短语，例如“in 3hours”或“for 3minutes”等等。表21例示出可映射到基数约束的某些示例性表达式。
  表22：例示出cardinal约束的示例性表达式
  英语
        3cats
        ninety dollars
        2.5kilos
  法语
        3chats
        cinq francs
        2,5kilos
  德语
        3Mails
        fünf Euros
        2,5Kilos
  日语
        3匹の猫
        九十ドル
        2.5キロ
       フアイル… 3っ(浮点量词)
  西班牙语
        3gatos
另一类型的约束“Comparison”(比较)对实体与另一个明确识别的实体之间的比较进行建模。Comparison约束的语法例示于表23中。
  表23：Comparison Restriction.
  Restriction Comparison<dimension：＝Modifier，
               refpoint：＝Entity>
  {
  }
比较约束不用于隐含比较，例如要比较的实体之一不是明确被提及的。例如，“a bigger file”暗示出一隐含比较，它不调用比较约束。
比较约束可运用于量纲(dimension)约束，量纲设置到对形容词短语进行建模的修饰语约束。例如，该修饰语约束一般将具有“degree”约束，其degree字段设置成“more”、“less”或“same”。“refpoint”(参考点)字段设置到要与变量实体比较的实体。
根据具体的实施方式，明确地命名比较类的最高级可能要求特殊的关注。例如，短语the tallest girl in the class可能导致调出class作为用于比较的参考点，或者可选地，可调出class作为girl的定位。各种其它的最高级表达式也可能要求特别的关注。例如，从LOM的观点来看，短语my daughter is tall forher age及其西班牙语等效语mi hija es alta para su edad呈现出类似的问题。
表24提供了可由比较约束建模的某些示例性表达式。
  表24：由比较约束建模的某些示例性表达式
  英语
       a file bigger than mydoc.txt
       documents that are less relevant than mydoc.txt
       watches as expensive as the Rolex X-55J
  法语
       des livres plus chers que ce livre
  德语
       PP[als]
              Eine Datei，die kleiner ist als mydoc.txt.
       [ebenso/genauso/so/[AJP]wie]
              Die Datei ist genauso gross wie mydoc.txt.
  日语
       mydoc.txtょり(もっと)大きぃフアィル
       ロレックスX-55Jほど高ぃ腕時計
  西班牙语
       un archivo más grande que mydoc.txt
条件(conditional)约束对话语中表达的条件进行建模。表25例示出条件约束语法。
  表25：Conditional Restriction.
  restriction Conditional<condition：＝Frame>
  {
       ConditionType type；
  }
类似于先前的例子，可在包括英语、法语、德语、日语、西班牙语(以及其它语言)的大多数语言中对条件约束进行建模。
默认(default)约束不对任何特别的构造(construction)类进行建模，但是仅仅提供对其它LOM对象还未要求的底层语言分析部分的接口。表26提供了用于本发明的一个可能的实现方式的默认约束语法。
  表26：Default Restriction
  Restriction Default
  {
       LinguisticAnalysis analysis；
  }
Default约束的其它可能的变型将单个Entity作为它的槽。Default约束的这种变型使能该单个Entity和主控该约束的对象之间的任何关系成为可能。
重要的是要注意，一般来说，约束可具有与之相关联的模式。这种模式关联可以使得LOM消费者能够与LOM制造者(分析引擎)关于要识别那些语言构造进行通信。简单的例子是基于串的模式。例如，源(Source)约束用法可具有[“due to”+X]的模式，以确保分析引擎(LOM制造者)将该模式映射到Source约束。通过将模式关联运用于语言分析，编程者(创作者)可选择对用户输入进行较低级的推理。不同于其它LOM类型，没有用Default约束隐含的跨语言规格化。
根据实现方式，可能需要定义能够将来自完全解析结果的任何东西暴露于简单的串的单个接口(例如ILinguisticAnalysis)。一般来说，模式可对应于可通过IlinguisticAnalysis暴露话语的一部分的不同的方式。在较佳实施例中，存在某一范围的默认约束，一个约束用于一种类型的分析引擎。
Degree约束仅仅依附于对形容词短语进行建模的修饰语约束。表27例示出用于degree约束的语法和DegreeType枚举。
  表27：Degree Restriction.
  restriction Degree
  {
       DegreeType degree；
  }
  enum DegreeType
  {
       More，
       Most，
       Less，
       Least，
       Same，
       High，
       Low
       }
于是，DegreeType枚举的值表示对形容词短语的含义的各种可能的限定。该degree字段设置成适当的值。
在某些情况下，希望通过同时检索子句否定和高级类型副词来识别DegreeType的低值。例如，表达式“not very big”指的是通过否定词(not)和副词(very)来表示的DegreeType的低值。忽略否定词会导致对话语的不正确的解释。表28例示出可使用degree约束来建模的示例性短语。
              表28：暗含Degree约束的示例性短语
英语
      More：bigg er， more relevant
      Most：bigg est， most relevant
      Less： less relevant
      注意smaller并被建模成″less big″而是″more small″。
      LOM不对标量反义词的任何概念进行建模。
      Least： least relevant
      Same： as big
      High： very big， extremely popular
      Low： not very big
德语
      More：grBer，relevanter，mehr relevant
      Most：grBte/n，am Relevantesten
      Less：weniger relevant，weniger wichtig
      Least：wenigBte/n
      Same：genauso/ebenso relevant
      High：sehr klein，extrem dick
      Low：nicht sehr dick
本领域的技术人员将理解到其它Degree约束类型存在于英语和德语中，这种约束类型也同样存在于大多数语言中。可使用几乎任何语言来访问Degree约束。
方向(Direction)约束对运动的方向或空间位置的定向进行建模。表29提供了Direction约束及其相关枚举的例子。
           表29：Direction约束和相关枚举
          restriction Direction<landmark：＝Entity>
          {
            DirType myDirType；
            OtherDirectionType other；
          }
          enum DirType
          {
            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，nach vorn)
        backward(rückwrts，zurück)
        around(drehen.，rotieren)
        in(einfügen)
        out(extrahieren)
本领域的技术人员将理解到其它Direction约束类型存在于英语和德语中，这些约束类型同样存在于大多数语言中。
实例(Example)类型对实体类型、构架或约束的样本进行建模。表31例示出用于每种Example约束类型的语法。
            表31：Example约束
        restriction Example<example：＝Entity>
        {
        }
        restriction Example<example：＝Frame>
        {
        }
        restriction Example<example：＝Restriction>
        {
        }
在某些实现方式中，可能希望具有SimilarTo约束用于诸如下述的附属结构：
      I want to find vendors， for example Volt.
      I want to find vendors， Volt，for example.
在另一实施例中，可能希望提供额外的槽用于宾语(the what)，对于该宾语，样本是一个实例。例如，短语 This program exemplifies  solid coding technique可能要求额外的槽用于对短语“solid coding techniques”进行建模。一般来说，Example约束可被理解为对直喻进行建模。表32提供了可由Example约束建模的某些短语。
             表32：由Example约束建模的示例性短语
    英语
          ″like″
          Show me cars  like the Honda
          Which CEO dances  like a monkey？
           What does a butterfly look  like？
          ″as″
          ″such as″
    德语
          wie
    西班牙语
          como
本领域的技术人员将理解到其它Example约束类型存在于英语、德语和西班牙语中，并且这些约束类型同样存在于大多数其它语言中。可使用几乎任何语言来访问Example约束。
程度(Extent)约束对实体进行建模，相对于该实体测量空间中某一程度概念。表33例示出Extent约束的语法。
                     表33：Extent约束
    restriction Extent<extent：＝Entity>
    {
    }
一般地，槽的extent字段设置到对程度的测量进行建模的Entity。在一个实施例中，程度介词短语的宾语是独立于话语中的附属位置的。表34提供了可由Extent约束建模的英语和西班牙语术语的例子。
               表34：Extent约束建模的示例性短语
    英语
         along
    西班牙语
         por
         Mi hermana va por la calle San Juan.
目标(Goal)约束对运动的目标(比喻的或实际的)或相对于Entity或Frame的状态改变的最终状态进行建模。表35例示出根据本发明的实施例的Goal约束的语法。
                       表35：Goal约束
restriction Goal<goal：＝Entity>
   {
   }
Goal约束可与一个或多个枚举值相关联。例如，字段“DirType”(上述的表29中定义)可以是Goal约束的枚举值，可被设置到适当的枚举值。表36提供了可由Goal约束建模的某些短语。
             表36：由Goal约束建模的示例性短语
英语
  to
法语
  à
德语
  für
日语
  NP-に
西班牙语
  para
  Hay vuelos para La Paz todas las semanas.
本领域的技术人员将理解到其它Goal约束存在于大多数语言中。可使用大多数语言来访问Goal约束。
重复(Iteration)约束对动作的重复进行建模。表37例示出Iteration约束的语法。
                    表37：Iteration约束
    restriction Iteration
    {
        IterationType type；
        float times；
    }
   enum IterationType
    {
       Count，
       Never，
       Rarely，
       Sometimes，
       Often，
       Always
    }
在一个实施例中，Iteration约束可结合于时间(time)约束的Recurrence字段中。一般来说，类型Count的字段表示动作被重复了某一次数(例如do[something] 5times)。当该类型具有该值时，字段“times”保持了重复的次数。如果该类型具有其它值，该类型对不表达特定的重复次数的修饰语进行建模。从而，当类型设置为count时，它保持了重复的次数，否则，忽略类型。表38提供了可由Iteration约束建模的某些术语和短语。
              表38：由Iteration约束建模的示例性短语
    英语
         5times
         never
         sometimes
         frequently
         seldom
    法语
         5fois
         jamais
         souvent
         rarement
    德语
         5Mal
         nie，niemals
         manchmal，ab und zu
         oft
         selten
    日语
         5回
         ょく
         めったに
    西班牙语
         5veces
         nunca
         algunas veces，de vez en cuando
         con frecuencia，frecuantemente
         raramente
本领域的技术人员将理解到其它Iteration约束类型存在于大多数语言中。可使用大多数语言来访问Iteration约束。
位置(Location)约束对实际或比喻性位置进行建模。表39例示出Location约束的语法。
                     表39：Location约束
    restriction Location<loc：＝Entity>
    {
    }
表40例示出可由Location约束建模的术语和/或短语。
         表40：由Location约束建模的示例性术语/短语
    英语
      at
    法语
      à
    德语
      in/bei+Dative
      Er ist in der Stadt.
      Er ist bei Hamburg.
    日语
      NP-に
本领域的技术人员将理解到其它Location约束类型存在于大多数语言中。可使用大多数语言来访问Location约束。
手段(Means)约束对用于为某一Entity或Frame完成某些事的手段或设备。表41例示出Means约束的语法。
                    表41：Means约束
    restriction Means<means：＝Entity>
      {
      }
    restriction Means<means：＝Frame>
     {
     }
本领域的技术人员将理解到其它Means约束类型存在于大多数语言中。可使用大多数语言来访问Means约束。表42中示出可使用Means约束来建模的示例性术语/短语。
             表42：由Means约束建模的示例性术语/短语
    英语
          with a knife
          employing a knife
          use a spreadsheet program
          by arriving early
    法语
          PP[avec]
    德语
          PP[mit]
          Er schneidet mit dem Messer
          benutzen，gebrauchen
          SUBCL[indem]
          Er gewinnt，indem er schnell rennt
    日语
          NP-で
          NP-をつかって
          VP-て
量度(Measure)约束对用于Frame或Entity的对象的权重或量度进行建模。表43例示出根据本发明的实施例的Measure约束的语法。
                    表43：Measure约束
    restriction Measure<measure：＝Entity>
    {
    }
    restriction Measure<measure：＝Frame>
    {
    }
本领域的技术人员将理解到其它Mearure约束类型存在于各种语言中。可使用大多数语言来访问Measure约束。表44例示出可用Measure约束来建模的示例性术语/短语。
             表44：由Measure约束建模的示例性术语/短语
    英语
          Weight：three pounds
          Money：$4，fifty yen
          Distance：3yards
          Time：all day
    法语
          Weight：deux kilogrammes
          Money：un franc
          Distance：cinq kilometres
          Time：toute la journée
    德语
          Weight：drei Kilo
          Money：4DM.
          Distance：3Meter
          Time：den ganzen Tag
修饰语(Modifier)约束可被认为是“垃圾箱”(“垃圾堆”)约束，因为它不对语言表达式的语义相干类进行建模。相反，它捕捉“附加语性质”的语义概念。一般来说，Modifier约束可相对于Entity、Frame或Restriction对形容词短语、名词短语、副词短语进行建模。在一个实施例中，modifier槽仅仅设置到从被建模的语义短语的头单词构造的标志牌对象。然而，为了利用LOM，不是必须要求这种实现方式。表45例示出根据本发明的实施例的Modifier约束的语法。
                    表45：Modifier约束
     restriction Modifier<mod：＝Denoter>
     {
     }
一般来说，Modifier约束对任何上下文环境中的语言修饰语的某些类进行建模。虽然任何语言上的修饰语可以成为修饰语，但是Modifier约束仅意指语言修饰语的子集的基本LOM表示。该子集包括多数或所有形容词短语、多数或所有名词短语修饰语和某些副词短语。许多副词短语(时间表达式是一个主要的例子)在其它的更具体的约束中可找到基本的LOM表示。
Modifier约束的不通常之处在于它的槽包含denoter对象，而不是Entity、Frame或Restriction。Denoter对象串是修饰语的头单词。这种配置的原因在于：虽然语言上的修饰语在语义上是它们的主体(它们所修饰的要素)的单位置的(one-place)起功能作用的东西，并因此类似于构架，但是实际上，它们几乎专门地用作约束。此外，语言上的修饰语几乎不存在于可能出现构架的其它上下文环境中。不是要求麻烦的基于构架的约束语法(按照withMyLargeFrame<this>的某些东西)以及用于每个所希望的修饰语类的构架类型的定义，为修饰语类仅规定Denoter对象并将隐含的约束变量作为语义变量(诸如约束所依附于的主体对象)就足够了。
关系子句中的表语形容词以该同一形容词的对应的定语用法相同的方式来表示。因此，“a  large file”and“a file  that is large”都成为Modifier<large>。
对于形容词的这种处理对于诸如日语之类的某些语言来说可能不合适，日语中的形容词语义上不能与动词区别。虽然名词在跨语言方面是非常类似的，名词被映射到SPL实体。虽然动词也在跨语言方面是类似的，但是动词映射到SPL构架。于是，形容词介于名词和动词之间，形容词在跨语言方面不是类似的。
语言可被认为是存在于连续体之上的。该连续体的一端上，例如在韩语中，形容词不是真正地与动词分开的词汇类别。在该例子中，形容词仅仅是状态、不及物动词。日语在这一点上类似于韩语，其中形容词语义上表现为类似于动词(虽然它们在形态上不同)。英语和源自拉丁语系的其它语言(例如欧洲语言)将形容词作为不同于动词的类别来对待。在谱的另一端，诸如阿拉伯语之类的语言将形容词作为某一类的名词对待。对于“red”，不是用一个单词，阿拉伯语使用意味着类似于“a red one”的意思的名词，使得短语“the book is red”成为“the book is a-red-one”。
在某些实施例中，在主语子句中可能存在表语形容词的表现。例如，短语“this file is personal”可以不同于“this file is text”的方式来被处理。
此外，本领域的技术人员将理解到Modifier约束类型存在于各种语言中。可使用大多数语言来访问Modifier约束。
有名(Named)约束提供对主体实体的denoter对象的访问。例如，这允许MyAlias和DL_MyAlias被规格化为单个DLEntity，不用要求创作者对两个不同的约束进行编码。表46例示出根据本发明的实施例的Named约束的语法。
                     表46：Named约束
    restriction Named<named：＝Denoter>
    {
  }
    restriction Named<named：＝NamedEntity>
    {
  }
    restriction Named<named：＝String>
    {
  }
一般地，Named约束设置到名词短语名或主体实体的denoter对象。在某些实施例中，Named约束可用于提供对有名实体属性的某种访问。在另一实施例中，Named约束合并到Modifier约束中。一般地，Named约束可按需表示已经存在的信息段(例如主体实体的denoter对象)。
本领域的技术人员将理解到其它named约束类型存在于各种语言中。可使用大多数语言来访问Named约束。
否定(Negation)约束对语义否定或逻辑NOT进行建模。表47例示出根据本发明的实施例的Negation约束的语法的例子。
                    表47：Negation约束
    restriction Negation
    {
    }
在某些实施例中，Negation约束可作为单独的约束而存在。在可选的实施例中，可通过“with Negation”子句或“！”(不是算子)来消耗Negation约束。
序数(Ordinal)约束对序数词和表示序列中的某一位置概念的其它修饰语(诸如“在前的”)建模。表48例示出根据本发明的实施例的Ordinal约束及其枚举的语法。
                  表48：Ordinal约束和枚举
    restriction Ordinal
    {
     int        distance；
     ReferencePoint refPoint；
    }
    enum ReferencePoint
    {
      First，
      Last，
      Current
    }
一般地，distance字段可设置成离开基准点的有符号的整数距离。可选地，成为First的基准点字段(refPoint)必须指示出非负的距离。0距离值对第一(first)进行建模，1距离值对第二(second)进行建模，依此类推。最后(Last)基准点字段必须具有非正的距离。0距离值对最后进行建模，-1的值对倒数第二进行建模，依此类推。Current基准点距离可保持任何整数值。0距离值对“当前”状态进行建模，1值对“下一个”进行建模，-1值对“前一个”进行建模，依此类推。表49提供了可由Ordinal约束建模的短语。
             表49：由Ordinal约束建模的示例性短语
    英语
         first，4th
         last，next to last，3rd from the end
         previous，current，next，two back，two ahead
    法语
         premier，4e
         dernier
    德语
         erst，4te
         letzte/r/s，vorletzte/r/s
         nchste/r/s，zwei＿，zwei weiter
    日语
         最初，4番目
         最後，最後から2番目
         前の，今の，次の，2つ前の，次の次の
    西班牙语
         primero，4o
         last，next to last，3rd from the end
         previo，＿，proximo，dos＿，dos mas
本领域的技术人员将理解到其它Ordinal约束类型可存在于各种语言中。可使用大多数语言来访问Ordinal约束。
具有的(Possessed)约束对所有物、属性或所有权进行建模，并用作所有人(Possessor)约束(下文描述)的补充。表50例示出根据本发明的实施例的与Possessed约束相关的语法。
                    表50：Possessed约束
    Restriction Possessed<possessed：＝Entity>
    {
    }
一般地，Possessed约束对所有物、属性或所有权进行建模。例如，短语email  with headers、schools  with linguistics programs等等可由Possessed约束来建模。在某些情况下，Possessed约束可被成为是“具有”属性、所有物或所有权。表51提供了可使用Possessed约束建模的某些示例性术语和短语。
          表51：Possessed约束建模的示例性术语/短语
   英语
         with
              mail  with″conference″in the subject line
              document  with size greater than lk
         of
              files  of greater size
   德语
     RELCL
         Mail，die″Treffen″in der Betreffzeile hat
     mit
         Mail mit Anhang
本领域的技术人员将理解到其它Possessed约束类型可存在于各种语言中。可使用大多数语言来访问Possessed约束。
所有人(Possessor)约束是Possessed约束的补语或补充。一般地，Possessor约束对实体的所有者进行建模，可由全名词短语或所有格代名词来表达。表52例示出根据本发明的实施例的Possessor约束的语法。
                     表2：Possessor约束
     restriction Possessor<possessor：＝Entity>
     {
     }
表53提供了可由Possessor约束建模的示例性术语/短语。
           表53：Possessor约束建模的示例性术语/短语
英语
     my，your，her，his，its，their
     of mine，of yours，of hers，of his，of its，of
     theirs
     (wheel)of the car
     Kim′s，the computer′s
     some instances of PP[of]′s
法语
      mon，son，ta，sa，leur
      de moi，de toi，de lui，d′eux
      some instances of PP[de]′s
德语
      mein，dein，sein，ihr，Ihr
      some instances of PP[von]
      some instances of genitive case
日语
      私の，彼の，彼女の，あなたの
      some instances of NP-の
本领域的技术人员将理解到其它Possessor约束类型可存在于各种语言中。可使用大多数语言来访问Possessor约束。
LOM中建模的另一个约束是目的(Purpose)约束。Purpose约束对关联到Frame的预期的结果进行建模。表54例示出可由Purpose约束建模的某些示例性短语/术语。
              表54：Purpose约束建模的术语/短语
     英语
           for，in order to
     法语
           pour，afin de；de sorte que；de sorte à；de facon
           à
     德语
           um...zu
           so dass
     西班牙语
           para，para que，con objeto de，con el fin de
原因(Reason)约束对与构架或实体相关联的信心或动作的合理动机进行建模。在一个实施例中，Reason约束和Purpose约束可在范围上重叠。表55例示出可由Reason约束建模的示例性术语/短语。
             表55：由Reason约束建模的术语/短语
    英语
        because，in order to
法语
        parce que；àcause de；en raison de
德语
        fuer
        weil
        wegen
西班牙语
        por，porque，a causa de.
Reason约束和Purpose约束都可在任何数量的语言中建模。上述列出的示例性术语/短语不应被解释成穷尽的列表，而是例示出可由这些约束建模的示例性术语。
排序次序(SortOrder)约束对描述数据排序的形式和/或方法的修饰语进行建模。表56例示出SortOrder约束及其相关枚举OrderType的语法。
                   表56：SortOrder约束
    restriction SortOrder
    {
     OrderType type；
     OrderCriteria criteria；
    }
    enum OrderType
    {
     Default，
     Reverse，
     Increasing，
     Decreasing
    }
    enum OrderCriteria
    {
     Default
     Alphabetic，
     Numeric，
     GoJuuOn，
     Iroha
    }
一般地，该字段类型可以是默认、反向、字母、数字、递增、递减等等。默认类型以默认顺序、任何顺序等进行建模。反向类型以反向顺序(后向)进行建模。字母类型按字母表顺序(字母表顺序)进行建模。数字类型按照数字顺序(数字顺序)进行建模。递增类型以递增顺序进行建模。递减类型以递减顺序进行建模。
根据实施方式，对于类似于“alphabetical list”(字母列表)之类的，可把SortOrder约束设置在实体上。此外，可通过SortOrder约束对诸如“alphabetize”(按字母表顺序排列)、“categorize”(归类)、“group”(分组)、“classify”(分类)以及“index”(索引)之类的动词进行建模。在某些情况中，可能希望包括两个字段，用于对类似于“reverse alphabetical order”、“decreasing alphabetical order”等等之类的短语进行建模。而且，对于两种不同的语言，可能共同存在不同的排序顺序。虽然表56中列出的枚举对于英语语言来说是共有的，但是日语可具有为该语言所共有的其它排序顺序。表57例示出可由SortOrder约束建模的示例性短语/术语。
               表57：由SortOrder约束建模的术语/短语
英语
          in default order，in any order
          in reverse order，backwards
          alphabetically，in alphabetic order
          numerically，in numeric order
          in increasing order
          in decreasing order
法语
          dans l′ordre par défaut；dans n′importe quel ordre
          par ordre inverse；en ordre inverse；dans l′ordre
          inverse
          alphabétiquement，par ordre alphabétique
          numériquement，par ordre numérique
          par ordre croissant；par ordre ascendant；
          par ordre décroissant；par ordre descendant
德语        [Babel]
          im Rückstellung Auftrag，in irgendeinem Auftrag
          im Rückauftrag，rückwrts
          in der alphabetischen Reihenfolge，alphabetisch
          im numerischen Auftrag，numerisch
          in zunehmendem Auftrag
          in abnehmender Reihenfolge
日语
          デフォルトの順序で，好きな順に
          default-no-order-de，favorite-order-
          ni
          逆の順序で，逆に    or    反对に
          reverse-no-order-de reverse-
          ni opposite-ni
          アルフアベツト順に    or    ABC順に
          alphabet-order-ni             ABC-order-ni
          数字順に
          number-order-ni
          小さい数字順に        or    低い数字順に
          small-number-order-ni       low-number-order-
          ni
          大きい数字順に        or    高い数字順に
          large-number-order-ni       high-number-
          order-ni
西班牙语
          ordenados por defecto，en el orden por
          defecto，en cualquier orden
          en orden inverso，al revés
          en orden alfabético，alfabéticamente
          en orden numérico，numéricamente
          en orden ascend(i)ente，de menor a mayor
          en orden descend(i)ente，de mayor a menor
源(Source)约束对对象的源或起源进行建模。表58中示出了Source约束的语法。
                     表58：Source约束
      restriction Source<src：＝Entity>
      {
      }
一般地，本领域的技术人员将理解到对于多种语言来说，各种Source约束可存在。
结构准则(StructureCriteria)约束相对于Frames对以结构化的方式对一组对象进行操作的概念进行建模。StructureCriteria约束对操作进行所依赖的标准或准则进行建模。表59示出用于StructureCriteria约束的语法。
                表59：StructureCriteria约束
    restriction StructureCriteria<criteria：＝Entity>
    {
    }
在LOM的某些实现方式中，可能希望包括用于对诸如“in pairs”、“5at a time”等之类的短语进行建模的称为“increment”(增量)的约束。这些类型的短语包含可精细地规范化的数字标准，根据该实现方式，这足够重要以便包括用于对它们进行建模的专门方式。表60例示出可由StructureCriteria约束建模的某些术语和短语。
    表60.由StructureCriteria约束建模的术语/短语
英语
   sort  by subject，list  by date
   display  in rows
   transmit  in 1KB blocks
   get my email  one at a time
德语
   sortieren nach Thema
   anzeigen
   senden/schickan
代替“Substitution”约束对一项替代另一项的语义环境中的参与者进行建模。在法语中，一个可能的例子是，用于pour的替代作为附属(adjunctive)。附属是一种类型的状语，表示出动作的环境。类似地，在西班牙语中，por用作附加语，para可与选定的动词一起使用。
可把时间(Time)作为约束来对待。一般地，Time约束对涉及对可表达为实体的特定时间单位或时间点的引用的时间修饰语进行建模。例如，“afterJuly 23rd”和“after Thanksgiving”可由Time约束来建模。然而，在某些实施例中，诸如“after my computer boots up”之类的短语不由Time约束来建模。类似地，诸如“from 3:00 to 6:00”和“between morning and evening”之类的时间范围可由Time约束来建模。然而，“while the defrag utility is running”可以不由Time约束来建模。在Conditional约束中处理包含嵌入的子句内容的时间表达式。表61例示出LOM中的作为约束的时间的语法和实现方式。
                    表61：Time约束
     restriction Time
     {
      BaseTime startTime；
      BaseTime endTime；
      BaseTime pointorSpan；
      Duration duration；
      TimeLength recurrence；
     }
      abstract class BaseTime
     {
     }
     abstract class AbsoluteTime：BaseTime
     {
     }
     class NowAbsoluteTime：AbsoluteTime
     {
     }
     class Analyzed AbsoluteTime：AbsoluteTime
     {
      int     second；
      int     minute；
      int     hour；
      int     date；
      int     week；
      Weekday weekday；
      Month   month；
      Int     year；
      Era     era；
      AmPm    ampm；
     }
     enum Weekday
     {
     Unspecified，
     Monday，
     Tuesday，
     Wednesday，
     Thursday，
     Friday，
     Saturday，
     Sunday
    }
    enum Month
    {
    Unspecified，
    January，
    February，
    March，
    April，
    May，
    June，
    July，
    August，
    September，
    October，
    November，
    December
    }
    enum Era
     {
      Unspecified，
      BCE，
      CE，
      Heisei，
      Showa，
      Taisho，
      Meiji
     }
     enum AmPm
     {
      Unspecified，
      Am，
      Pm，
      TwentyFourHour
     }
     class UnanalyzedAbsoluteTime：AbsoluteTime
     {
      Denoter timeExpress ion；
     }
      abstract class RelativeTime：BaseTime
       {
         BaseTime relativeTo；
       }
      class offsetRelativeTime：RelativeTime
       {
         Offset offset；
       }
      class Offset
      {
         Direction direction；
         TimeLength timeLength；
         Granularity granularity；
      }
      enum Direction
      {
         Unspecified，
         Forwards，
         Backwards，
      }
       enum Granularity
       {
          None，
        Seconds，
          Minutes，
          Hours，
          Days，
          Weeks，
          Months，
          Years，
          Decades，
          Centuries，
          Millenia
       }
      class TimeLength
      {
         float    amount；
         TimeUnit unit；
         Denoter  otherUnit；
      }
      enum TimeUnit
      {
         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
       }
       class SubsetRelativeTime：RelativeTime
        {
          AbsoluteTime subset；
       }
       class Duration
       {
          TimeLength timeLength；
          TimeLengthQualifier qualifier；
       }
       enum TimeLengthQualifier
       {
          None，
          MoreThan，
          LessThan，
          AtLeast，
          AtMost，
          Precisely
       }
Time约束可按需利用一个或多个字段和大量的辅助数据类型。字段可包括start time(起始时间)、end time(结束时间)、“point or span”(点或跨度)、duration(持续期)、以及recurrence(再现)。start time字段设置成得自基本时间的对象，表示时间跨度的起始点，例如“from 5:00”或“after tomorrow”。如果start time字段是空的，则建模的时间修饰语不包含起始点的明显表达式。
end time字段设置成得自基本时间的对象，表示时间跨度的结束点，例如“to 6:00”或“until Friday”。如果end time字段是空的，则建模的时间修饰语不包括结束点的明显表达式。
point or span字段设置成得自基本时间的对象，表示以单个短语表达的单个时间点或跨度，这与明显地给出起始点和结束点的时间跨度相反。例如，相对于“tomorrow”来说，概念是“tomorrow”是时间线上的单个时间点还是24小时的时间跨度这取决于上下文环境和观察者的角度。LOM不试图解疑该术语。如果point or span字段是空的，则建模的时间修饰语不包含单个时间点或跨度的明显表达式。
duration字段可设置到表示时间跨度的长度而不是表示特定的起始和结束点的持续期对象。例如，短语“for two hours”可由duration字段来建模。如果是空的，则建模的时间修饰语不包含明显的持续期表达式。在时间跨度内隐含的持续期，例如“from 4pm to 6pm”不被表达为duration对象。在该情况下，对于start time和end time将没有非空值，但是duration将为空。
recurrence字段设置到表示再现事件的发生之间的事件间隔的事件长度对象。例如，诸如“daily”、“weekly”、“monthly”、“the first Monday of everymonth”等等的可被表达为事件长度对象。如果为空，则事件修饰语不被解释为复现。
一般地，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”、“Electron Day”、“my birthday”、“summer”、以及“thisevening”都是建模成UnanalyzedAbsoluteTime的短语。
存在两种得自RelativeTime的类型：OffsetRelativeTime(偏移相对时间)和SubsetRelativeTime(子集相对时间)。OffsetRelativeTime表示离开引用的得自BaseTime的对象的某一时间长度的正的或负的偏移。例如，短语“two daysago”被建模成“[2days back]OFFSET FROM[now]”。
SubsetRelativeTime是得自RelativeTime的类型，表示被解释为由引用的得自BaseTime的对象表达的密封的时间跨度的子集的时间点或跨度。例如，诸如“at 5:00 on my birthday”之类的时间量度的表达式可被建模成相当于“[hour：5min：0]SUBSET OF[“my birthday”]”。重要的是要注意到诸如“5:00 onWednesday”之类的时间基准可由单个AnalyzedAbsoluteTime对象来捕获，因为该短语可被解析成时间单元。
在某些实施例中，可能希望具有不止一对StartTime和EndTime字段。例如，为了捕获诸如“from Monday to Friday from 4:00 to 5:00”，可能希望两对起始和结束时间，以便捕获两个范围。实际上，对于上述的表达式，可能希望具有Time实体。此外，暗示出Time实体的下述表达式之间的对比关系可能是希望的。
    Move the meeting[from 4:00 to 5:00].
    Move the file[from Folder1]source[to Folder2]Goal.
此外，EndTime应与原始的目标(Goal)相区分，因为并非所有采用Sources和Goals的结构都允许StartTime和EndTime如此发挥作用。例如，适用于对表达式“Run a meeting[from 4:00 to 5:00]”建模的结构可能不允许StartTime和EndTime适当地起作用。
另一个约束是Topic(题目)约束。就Entity对象来说，Topic约束对表示实体是关于什么的或实体涉及或隶属于什么的变量进行建模。与Frame相关联的Topic约束对表示事件的主题或题目的动词变量进行建模。一般地，Topic约束具有设置到Entity或Frame的Slot，对题目或主题进行建模。可选地，Slot可采用串。表62例示出根据本发明的实施例的Topic约束的语法。
           表62：Topic Restriction.
     restriction Topic<topic：＝Entity>
     {
     }
     restriction Topic<topic：＝Frame>
     {
     }
在某些情况下，可能希望用不同的名字来标记Topic约束。具体来说，已知术语“topic”的严重负载(至少在语言范围内)，可能希望使用其它标记用于该约束。某些可选的标记可包括例如“Concerning”、“Regarding”、“About”、“Subject”、“Theme”等等。表63提供了根据本发明的实施例可由Topic约束建模的某些示例性术语/短语。
            表63：由Topic约束建模的示例性术语/短语
    ENGLISH
        about，on
        concerning...，regarding...
        remind Sandy  that Kin is coming tomorrow
    GERMAN
        über
        Zeige die Mailüber den Hausbau.
        [bezüglich/bezgl.]+Genetive case
        Zeige Mail bzgl.des Hausbaus.
    JAPANESE
         NP-につぃてのNP
         NP-につぃてVP
Quantifier(数量词)约束对名词短语数量词和诸如two-thirds of(三分之二)之类的表示部分的表达式进行建模。一般而言，Quantifier约束可包括类型(type)或百分比(percentage)字段。type字段可以是百分比，按照浮点数来存储，一般(但非必须)介于0和1之间。例如，百分比类型对one half of、75％of、200％increase等等进行建模。术语“all”(全部)和“none”(没有)作为不同“特权”值来枚举，它们不落在这个“other”类型中。如果类型具有Percentage值，则percentage字段保持着对应于数量词的含义的百分比。否则，忽略percentage字段。表64例示出Quantifier约束及其相关枚举的语法。
                     表64：Quantifier约束
      restriction Quantifier
      {
       QuantifierType type；
       Float percentage；
      }
      enum QuantifierType
      {
       All，
       None，
       Some，
       Most，
       Many，
       Few，
       Percentage
      }
在某些实现方式中，可能希望以不同的方式处理否定。不是对诸如“none”之类的术语进行枚举，而是可能希望将否定按照名词短语来处理。表65例示出可由Quantifier约束建模的某些示例性术语/短语。
            表65：由Quantifier约束建模的术语/短语
ENGLISH
    All：all((of)the)，every，each(of the)
    None：no，none(of the)
    Some：some(of the)
    Most：most(of the)，the majority of
    Many：many(of the)
    Few：few(of the)，not many(of the)
    Percentage：a half of，1/3 of，40％ of
GERMAN
    All：alle(Gen)，jede/r/s
    None：keine/r/s(Gen)
    Some：manche/r/s(Gen)
    Most：die meisten(Gen)，der GroBteil(Gen)
    Many：viele(Gen)
    Few：wenige(Gen)
    Percentage：die Hlfte von(Gen)，1/3 von/(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位于根据通用知识从语言移动到语义推论的人工智能系统和对明显的同义词之间的区别进行建模的更为精细的词汇分析框架之间。换言之，所有的语言具有能够按照默认方式被映射的语言结构。此外，每种自然语言具有语法类别到语义角色的多种非默认的映射。这些具有比主语和宾语更多有原因地关系上远的语义角色的非默认的类更为少有。
默认词汇语义结构对诸如John broke the glass之类的及物句进行建模，如上：通过将该句的主语分类为“Who”和将宾语分类为“What”来进行。修饰语以表示因果链的时间展开的顺序(或语形学上的情况标记(case marking))来标识。换言之，修饰语得自于由额外的情况标记(间接宾语)和诸如介词短语之类的副词修饰语扮演的语义角色。在短语John broke the glass for me中，John是主语；the glass是宾语；以及短语“for me”被标记为更接近于该句的宾语的间接宾语。
默认的不及物语句通常包括主动者或“Who”。例如，短语John ran包括主动者“John”。较不普遍的情况是，单个变量是患者(Patient)。例如，在短语The glass broke中，短语“the glass”受到影响，该语句可以按照原句为[Something]broke the glass的方式来建模。
对于要被包括在LSS库存清单中的语义角色，它必须在某个语言中表现为语法类别，并且跨越某一范围的名词和动词类而作为变量或修饰语运用。因此，角色具有语言锚定和语义通用性。例如，短语“the office”是下面各个例子中的源(Source)：
1.John left  the office.
2. The office emitted smoke.
3.John went  out of the office.
4.The man  from the office called.
在每个情况中，根据动词类及其在语义/语法测试方面的行为来识别源。参考例子1，源是该类中的动词的宾语。动词“left”和及物动词“to leave”(以及尤其是“to exit”)不能采用其它源。例如，John left the house out of the yard并不意味着“John went out of the house and out of the yard”。在例子2中，根据由“emit”例示出的动词类在类似的语义/语法测试发面的行为，“the office”是句子的主语。在上述的例子3和4中，介词“out of”和“from”的语义一般将源角色分配给它们的宾语。
LSS是一组词汇语义类别和一种用于将自然语言输入关联到该组词汇语义类别中的一个或多个类别的方法。该方法包括用于将自然语言的内容关联到该组词汇语义类别的过程集合，以及用于将该过程集合运用于自然语言输入的规则。如这里所使用的，术语“方法”指的是用于将自然语言输入的内容关联到该组词汇语义类别的过程集合。每个词汇语义类别包括一个或多个语法类别、一个或多个角色、以及一个或多个语法类别和那些变量在话语中所扮演的相关的一个或多个角色之间的映射。此外，“方法”涉及用于将该组过程集合运用于自然语言输入的规则。在某些情况下，“方法”可包括用于确定自然语言输入的内容的映射的不同阶段何时完成的推断法。术语“方法”包括用于将自然语言输入的内容关联到和/或规格化成该组语言类别的一个或多个语言类别的技术、规则和过程的集合。
作为规格化结构，LSS帮助跨语法类别来识别语义角色(动词的主语/宾语、修饰动词的介词短语的宾语等等)。而且，LSS使得跨语言将语法类别语语义角色相关联成为可能。该规格化是通过识别语法类别的类的变量以及它们的语义，并通过将所识别的变量关联到适当的词汇语义类别来实现的。于是可从某一语法表示中抽出词汇语义结构。
与语言对象模型和语义编程语言(及其相关用户模式)相结合，降低了许多语言类别中的语义多义性。例如，介词“for”标识了动作的受益人(Beneficiaries)(I bought a dress for my daughter)，目的(Purposes)(I go toCalifornia for the beaches)，时间范围(Time Extents)(I went to school for 20years)，目标(Goals)(present for my daughter)，等等。然而，在一给定应用中，仅有限的一组可能性与上下文有关。因此，通过上下文消除了许多语义岐义性。
图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开头的例子来例示。
     [User]Who types[email address]What.
     [User]Who types.
Frames可在链接(构架的槽如何按语法来填充)和变量结构(槽数量)中与默认不同。例如，在一个非默认链接类型中，Unaccusative(非宾格)动词类具有用于不及物模式的不同链接模式，如下面的以动词increase为开头的构架中所见那样。
    [Users]Who generally increase[the font size]What of
 headers.
    [The font size]What generally increases in headers.
在该情况下，不及物动词的主语与及物动词的宾语相同，并链接到What槽。在语言中，这些非宾格非默认链接类型有时被称为“主动格”动词，在某些语言中，位于它们的情况标记模式之后。这些动词除了默认链接模式之外，还产生不及物的额外的非默认链接模式。
在另一个非默认链接类型中，ObliqueAsDefault动词类将Who或What变量表示为间接变量。例如，英语中的相互补足语(reciprocals)将另一个Who或What参与者表达为Accompaniment约束的对象。
Additional Who：I chatted  with John～John and I chatted.
Additional What：I merged file A  with File B～I mergedFile A and B.
其它语言将相互补足语表达为另一个代名词变量，意味着涉及代名词或标识或规定宾语而不描述宾语的变量。这些同样在Accompaniment约束下得到处理。
许多动词具有语义上间接的变量(由特殊介词标记)，看上去语义上与What槽相关联。也就是说，如果动词是不及物的，且介词短语语义上不落于约束类别之一中，且该短语可以被解释(或翻译成另一语言)成直接宾语，则可按照链接到What槽来处理。表66中提供了例示出按照默认槽来触发Oblique的短语的若干例子。
               表66：ObliqueasDefault.
     Juan confía en Pedro->′John trusts Peter′
     I′m waiting for MSN8->I′m awaiting MSN8.
     Look  for files on the internet->Find  files on the
  internet.
这些可与语义上相干的类(hope for，watch for，wait for)相关联，或可在如此采用某一介词的一组动词上单独标记出它们，作为分类的格标(case marker)(例如find and look  for)。
动词类可通过在构架中具有除了(或代替)Who和What的槽来与默认不同。而且，某些动词类将语法主语或宾语链接到LOM中的约束，而不是链接到Who或What槽。换言之，任一默认槽或两者都可被约束替代。
SubjectAsRestriction模式将主语链接到约束，而不是链接到What槽。例如，动词“receive”将Goal作为主语。
    [The website]Goal received the data.
    [The garden]swarmed with bees.～Bees swarmed in the
 garden.
类似地，ObjectAsRestriction模式设计出这样一个构架，其中语法宾语是Goal而不是What。例如，动词“enter”映射到一构架，其中语法宾语是Goal或位置，而不是what。
    Enter[the chat room]Goal(cf.Enter in(to)the chat
 room，Go in the chat room)
构架(Frames)也可在语义上使一个或多个额外的约束成为间接的方法中不同于默认。除了默认槽之外，AdditionalRestriction模式将额外的约束链接为间接变量或子句补语。例如，改变情况动词可采用额外的Goal(例如用动词“reset”)，或能够同时采用Source和Goal(例如用动词“change”)，如下所示。
    Reset[the default font]What[to Times New Roman]Goal.
    Change[the font]What[from Arial]source[to Times New
 Roman]Goal.
此外，构架可以各种方式不同于默认，例如通过将上述非默认的链接类型(Unaccusative、SlotAsRestriction[主语或宾语]以及AdditionalRestriction)中的一个或多个相组合。而且，动词可提出多个构架，可被解释为采用不同的意义。默认构架适用于“enter”的一个意义，而SlotAsRestriction适用于另一个。动词“enter”可以是对上下文敏感的。
    Enter[the data]What(into the form).
    Enter[the chat room]Goal
关键字“Keep”采用默认和三种非默认构架，具有不同的意义。例如，
     Default：Keep[the file]What
     AdditionalRestriction(Location)：Keep[the file]What
 [on the desktop]Location.
     AdditionalRestriction(Goal)：Keep[Bill Gates]What
 [from emailing me]source
     Unaccusative：The data won′t keep.
一般地，希望跨所有支持的语言，对于在至少一个语言中不同于默认的动词，都具有词汇语义结构构架。出于本揭示的目的，假设这对于及物动词和不及物动词都是真的。
对于某些动词(例如“expand”、“increase”等等)，对于不及物来说仅unaccusative模式是有效的。对于其它动词，unaccusative模式链接是一额外的选项。
表67例示出可由LSS构架利用额外的约束来建模的某些示例性短语/术语。在每个例子中，约束替代默认变量，或将变量添加到构架。原则上，每个约束可出现在主语位置、宾语位置或作为额外的间接变量。如下所示，一些约束将参与者添加到Who和What槽。还给出了相关的名词短语(NP)构架。
         表67：LSS构架用额外的约束建模的Accompaniment
     Accompaniment
       In subject position
              Meet：My daughter and I met
              Chat：My friend and I chatted.
       In object position
             Accompany：My daughter accompanied  me to
           Minneapolis.
英语中，该额外的约束通常以代名词“with”或可能以“against”为开头。各种动词子类对相关的含义选择该代名词或代名词短语。表68中给出了一个样例。
                 表68：具有额外约束的LSS构架
    Abscond：The Enron executives absconded  with the
     money.()
    Accommodate：indulge
    Accredit：accredit，credit
    Ache：ache，burn，itch
    Arrange
英语中，Accompaniment约束还可将参与者添加到Who和What槽。虽然这对于该约束是修饰语的构架来说是真的，但是就“相互补足的”动词而言，它尤其是普遍的。表69提供了Oblique作为默认槽的某些例子。
   表69：Oblique作为默认槽
  Who
        Subject reciprocals
        Chat：I IMed with Mary～Mary and I IMed；chat，
        discuss，talk，visit
        Agree
        Alternate
        Unaccusatives：The file merged(together)with
        the data～The file and the data merged(together).
  What
        Object reciprocals：
        Merge：I merged the files with the data，I merged
        the data and the files
        Acquaint：I familiarized them with the topic；
        acquaint
英语中，该额外的约束以介词短语(PP)“for”相对于Allocation为开头。各种动词子类对相关含义采用该PP。下面给出样例。
    Adapt：Adapt the movie for the stage.
    Allocate：Allocate funds for linguistics；
    allocate，appropriate，
    Appropriate：Appropriate funds for increased wages
    Assign：Assign a day for the performance
    Nominate：Nominate candidates for congress
    Transcribe：Transcribe the music for trumpet
    Train：Train for a marathon
可使用关于AsBeing约束的第二谓语作为额外的约束。表70中给出了某些示例性短语。
                  表70：AsBeing约束的第二谓语
  名词短语
        Make me  administrator
  形容词短语
        mark messages  low-priority
        judge the data  correct
        mark that completed
        mark low priority
        judge the data correct
代名词短语(as)变量
        mark task one  as done
        Mark messages  as follow-up
        mark that  as completed
        mark  as low priority
        judge the data  as correct
        Additional restriction
        Show my status  as busy
        use  as text file
        save  as file.doc
        Log in  as Administrator
        put this message  as message number two
表71示出关于Beneficiary约束的额外的约束。
             表71：具有额外的约束的Beneficiary
宾语位置中
        Benefit：Relaxed stock option laws benefited Enron；
        benefit，gain，profit
        Unaccusative：Enron benefited from relaxed stock
        option laws
间接宾语位置中
        Benefit：Relaxed stock option laws benefited Enron；
        benefit，gain，profit
        Unaccusative：Enron benefited from relaxed stock
        option laws
额外约束
        PP-for and Indirect Object
        Build：arrange，assemble，bake
        Create：design，dig，mint
        Prepare：bake，blend，boil，clean，clear，cook，
        fix，fry...
        Performance：dance，draw，ding，play，recite...
        Get：book，buy，call，cash，catch
某些约束类型可不适用于动词构架。然而，仍可调用额外的约束，例如在介词短语引入比较组时。
Direction约束可要求额外的约束，利用用短语“move the cursor  up(thepage)”。此外，在方向元素合并于动词本身的情况下(例如“the stocksrose/fell/advanced/retreated”或“ rotate the picture”)，可要求额外的约束。
可从下面的短语中理解具有额外的约束的LSS，示例性的约束包含于主语位置中。
     This document exemplifies table construction
     Sample code illustrates possible applications.
Extent约束一般落于宾语位置或额外的约束位置内。可能的是所有方式的运动类型的动词可采用Extent对象(例如“walk the mall”、“crawl the web”、“run the marathon”等等)。表72中示出了可由Extent约束建模的示例性短语。
                 表2：由Extent约束建模的短语的例子
宾语位置中
        The crawl ertraverses  the web.
        The data in this spreadsheet spans  several builds.
额外的约束
        I want a border  around this text.
        Maintain a uniform appearance  throughout the web
       site.
        Run  through the spec before the review.
Goal约束可要求额外的约束，特别是关于类或状态之间的改变方面。用某些动词特殊地表现为目标的介词短语的范围可按照实现方式而改变。特殊地表现为Goal的介词短语的例子是“save as file.txt”(“save to file.txt”)和“reschedule for 5:00”(“reschedule to 5:00”)。
在Bitrecs(如果Goal行为是由于单个动词)或LSS类(如果一类项目特殊地采用目标)中，某些动词可能需要采用特殊的目标。可简单地添加额外的目标，并且可从词典中将模式提入类中，以把它们称为它们被发现。
如表73所例示的那样，可对与位置相关联的额外的约束进行建模。
表73：位置
  Keep，Stand，CausedGoalOfMotion
主语位置
        Locative alternation(Levin 2.3)：The garden
        swarmed with bees(cf.Bees swarmed in the garden)
宾语位置
        Search：Canvass  the neighborhood，Search  the web
额外的约束
        Transitive：
            Keep：Keep the file  on the desktop(hold，keep，
            loca te，store)
            Get：Find a book  on Amazon.com
        Intransitive
            Stay：Stand here，Stay home
Means约束也可用额外的约束来建模，如表74所示。
                    表74：Means
工具主语：The knife cut the cake
额外的约束
        Adorn：adorn，festoon，decorate
        Adulterate：adulterate，alloy，pollute
        Anoint
        Afflict
        Aid：aid，assist，help
        Analogize
        Anoint
        Answer
        Arm
        Assail：attack，
SortOrder约束可由额外的约束来建模，如表75所示。
                  表75：SortOrder.
英语
      Arrange alphabetically
      Additional restriction
           Arrange：sort alphabetically，
法语
       par ordre alphabétique inverse
       du plus petit au plus grand[literally：from the
       smallest to the biggest]
       du plus grand au plus petit[literally：from the
       biggest to the smallest]
类似地，结构准则StructureCriteria约束可由额外的约束来建模，如表76所示。
表76：StructureCriteria
  英语
         Arrange by name(cf.SortOrder above)，in date
         order
法语
         {catégoriser classer classifier filtrer grouper
         indexer ordonner regrouper réarranger réindexer
         trier}
         Classeles messages{ par ordre alphabétique，
          alphabétiquement}
         ′Sort the messages{in alphabetical order，
         alphabetically}′
         Regroupe mon courrier  par date
         ′Group/cluster my mail by date
         Trie les fichiers  en fonction de la taille
         ′Sort the files by size/as a function of the size′
         Indexe la table  sur le nom
         ′Index the table on the name′
一般地，采用Time变量的类可作为采用类型Time的Measure约束的类来对待，虽然它们可实现完整时间表达式。例如，下面的短语可被建模成采用时间变量或类型Time的measure约束的类：“I spent at least an hour from 9 to 5every day for weeks looking for a piano”。
表77例示出可用额外的约束来建模的某些示例性Topic短语。
                       表77：Topic
        Spact：talk about X，talk X，remind X that Y，book
        on Martin Luther
主语位置
         Her finances don′t concernyou；concern
        In object position
        Discuss：The article addresses  adolescents in the
         20 th  century；address，cover，discuss
额外的约束
     PP[{about，concerning，on，regarding}]takes
     either NP objects(about cats)or clausal objects
     (about John coming to Seattle)
     PRPRTCL
     The object of address could also be the addressee，
     rather than the topic.
D5.实体类
该部分提供了在按照SPL库被支持的实体类型上收集数据的位置，例如Person实体、Place实体和LSS实体。此外，SPL库可包括对应于每个LSS构架类(特别是那些采用额外的约束)的名词短语类(LSS实体)。
SPL库还可包括Restriction(约束)类。对于每个约束，存在一(小)组可用于命名约束的名词短语。在SPL中，可在一小组结构中将这些识别为表示约束槽填充物的存在。例如，当topic是主语或宾语或系动词时，Topic约束槽填充物(粗体表示)位于补足语位置。
   Find discussions where the economy is the topic.
   Find discussions where the topic is the economy.
类似地，当topic填充AsBeing槽时，它所依附的实体填充Topic槽。
Find discussions that have the economy as a topic.
这些结构应连同那些被识别为Topic约束的结构一起被规格化。
Find discussions about/on/concerning/regarding the economy.
例如theme、matter、subject、issue、focus以及area之类的同义词也可以是TopicEntity。而且，开发者可以将更为特定于其场景的topic词添加到实体类中，例如“subject in an email application”。
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公共语言运行时间(.NetCommon Language Runtime)。
SPL的基本构造是实体(Entities)(名词)、构架(frames)(动词)、约束(restrictions)(实体间的关系)、命令(commands)(应用程序任务入口点)、NamedEntities和Denoters。这些是SPL的主要的第一类类型。语言是根据设计以命令为中心的，因为它是为应用程序中允许自然语言的命令和控制(C&C)功能而设计的。
在详细讨论SPL框架之前，详细说明简单的SPL实例，以便给出用于理解上下文中的剩余揭示内容的概念上的设想。表78例示出处理“send email toBob”命令场景的SPL代码。在本揭示的剩余部分中，将多次运用该命令场景。
以最高级的“command”为开始，应理解到将SPL代码写到先前介绍的LOM模型(见D部分)。命令是相对于构架来创造的。构架是通常代表动词的对象。代表一个动词的基本构架由分析系统来提供。开发者还可定义其自己的动词构架，在详细描述Frames的部分中更详细的讨论了其特征。
             表78：″Send Mail To Bob″SPL代码
        //粗体标记是关键字或预留的单词
      command SendMail Command uses
      MySendFrame<DoneTo.what：＝MailEntity>
      {
        on resolve
        {
      //开始解析子句，
      //在解析开始之前调用
      begin
    {
    //进行应用程序特定的初始化，或者如果我们不想相对于该命令
进一步进行解析，则失败(例如该应用程序不在正确的上下文/状态中)
    }
    //成功解析子句，当相对于该对象的话语的解析成功时调用
    success
    {
    //进行应用程序特定的任务执行(产生url或xml、运行命令、弹
出对话框等等)
    }
    //失败解析子句，当相对于该对象的解析失败时调用
    failure
    {
    //进行任务特定的清除(释放资源、弹出对话框等等
    }
    }
    }
SendMailCommand定义了使用MySendFrame的应用程序入口点，其中正北发送的对象(“DoneTo.what”槽)是MailEntity。命令封装该任务，允许开发者进行特定的初始化和清除，向平台提供进入应用程序的入口点。
表79例示出用于的SPL代码。
                    表79：MySendFrame
    Frame MySendFrame：send<DoneTo.what：＝MailEntity>
    {
    on resolve
    {
    begin
    {
    //进行应用程序特定的初始化或失败
    }
    //在程序的某处定义RecipientEntity
    with restriction Goal<goal：＝RecipientEntity>
    {
    //如果在话语的MySendFrame和RecipientEntity之间存在有效的Goal关系则仅执行代码。
    //
    //进行应用程序特定的推理，以绑定到应用程序对象、设置状态或拒绝解析。
    }
    success
        {
        }
        failure
        {
        }
        }
    }
MySendFrame代码块定义了一个应用程序特定的构架，MySend，它从与域无关的基本“send”构架(由平台提供)中继承而来，并将“DoneTo.what”子类型划分为MailEntity。“DoneTo.what”是正被发送的对象。
由Goal约束(由平台提供，例如基于LOM的SPL)捕获sending“to Bob”的语义，它通过“with restriction”子句来链接到“send”。除了这种链接之外，正被发送“to Bob”的实体还被限制到RecipientEntity。
如先前所讨论的那样，Restrictions是通常为实体之间的类型化的语义关系。SPL平台提供预定义的一组基本的关系。开发者可以对该组基本的约束进行子类型划分，以创建他们自己的关系。预定的约束的某些例子是Location(位置)(“mail  in Inbox”)、Time(时间)(“delete  after 3days”)、所有者(Possessor)(“ Bob’s book”)以及Topic(题目)(mail  about cats)。
关于约束的一个重要的事情是语法中的各种变化由语义平台来规格化。例如，可以多种语义方式来表达Topic：“mail about cats”、“mail with cats as thesubject”、“mail regarding cats”、“mail with subject cats”等等。不同的语言不同地表达Topic的语义。这些变化由语义平台来规格化，从而开发者仅需要相对于Topic约束来编程，而不用相对于每个可能的语义变化来编程。
表80例示出根据本发明的一个实施例的MailEntity的语法。
                    表80：MailEntity.
    Entity MailEntity denoted by MailWords
    {
      on resolve
      {
        begin
        {
        }
        success
        {
        }
        failure
             {
             }
       }
    }
    denoter MailWords
    {
      Japanese：＝noun(″メッセ一ジ″)，noun(″電子メ一ル″)；
         English＝noun(″mail″)，noun(″email″)，
      noun(″electronic mail″)；
    }
在该例子中，MailEntity由一列单词来定义和表示。进行表示的单词通常单独定义，一般定义在它们自己的文件中(例如定域化文件)。
类似于构架，实体也能具有运用于它们的约束。表81例示出具有约束的实体的语法。
                     表81：具有约束的实体
    entity MailEntity denoted by MailWords
    {
         with restriction Location<loc：＝MailFolder>
         {
         }
    }
从开发者的观点来看，该语法声明了邮件(mail)项目可具有处于MailFolder(邮件夹)中的属性(约束)。从实体关系的观点来看，MailEntity和MailFolder通过Location关系而相关联。在运行时间，具有Location约束的MailEntity代表限制为处于某一MailFolder中的一组邮件项目。
对于话语“send mail to Bob”或“send Bob mail”来说，SPL运行时间平台相对于SendMailCommand命令来分析。图4例示出根据本发明的一个实施例的通过SendMailCommand代码来跟踪解析的流程图。本领域的技术人员应理解到命令的解析随实现方式而变化。例如，参考表78，Begin、Success和Failure子句中的每一个都是任选的。OnResolve子句可包含任一子句、子句的任何组合、或不包含子句，这取决于具体的实现方式。
出于图4中的流程图的目的，应该理解到分析引擎已经将话语映射到说明模式中定义的和从LOM中导出的类型。例如，分析引擎已经考虑了Denoter对象。此外，假设该代码对于每个元素都包含Begin子句、Success子句和Failure子句。还有重要的是要注意到流程图中忽略了某些细节，特别是因为这些细节是实现方式所特定的，会不必要地使讨论变得复杂化。
现在参考图4，一但接收到话语，调用SendMailCommand的开始解析子句(框400)。如果开始解析(begin resolution)子句不成功，可调用另一不同的命令或(任选地)解释器可简单地解析失败，这取决于特定的实现方式以及取决于应用程序中可用的其它命令(框402)。
如果成功调用SendMailCommand的开始解析子句，则SPL解释器为SendMailCommand使用的MySend Frame调用开始解析子句(框404)。如果用于MySend Frame的解析子句失败，则调用MySendCommand失败(failure)子句(框406)，SPL解释器可任选地调用一不同的命令或解析失败(框402)。
如果用于MySend Frame的开始解析子句成功，则调用MailEntity BeginResolution(MailEntity开始解析)子句(框408)。如果用于MailEntity的开始解析子句的调用失败，则随后发生的过程很大程度上取决于特定的实现方式。如所示，根据特定的实现方式，MailEntity开始解析子句的失败可意味着一般的失败(选项1)、可被忽略(选项2)、或可导致其它操作来消除话语的岐义(框410)。这些“其它操作”可包括试图使用不同的约束子句用于正被解析的部分输入。由于多义性，约束子句甚至可完全用于不同的约束。
如果将失败理解成暗示着一般的失败(选项1)，则SPL解释器任选地调用一不同的命令或解析失败(框402)。如果忽略失败(选项2)，则SPL解释器可简单地调用MySend Frame的success子句(框420)、调用SendMailCommand的success子句、以及将SendMailCommand对象添加到“实际的解释”列表中(框424)。如果开发者代码要求其它操作，则SPL解释器可进行进一步的处理，包括语自然语言分析引擎通信和/或回调到客户端应用程序以试图消除话语的岐义。
如果MailEntity的begin resolution子句的调用成功，则调用MailEntitysuccess子句(框412)。接着，调用Restriction begin resolution(约束开始解析)子句(框414)。如果Restriction begin resolution子句失败，则流程进行到框410(上述)。如果Restriction begin resolution子句成功，则调用Restrictionsuccess子句(框416)。然后在具有MailEntity槽的MySend Frame上调用Restriction(约束)子句(框418)。如果该调用失败，流程再次进行到框410(上述)。如果调用成功，则调用MySend Frame的success子句(框422)，并将SendMailCommand对象添加到“实际的解释”列表中(框424)。
应理解到，代码块导致实际上无限的排列，这取决于应用程序和开发者。在一个实施例中，用于任何失败的解析的默认方式可调用failure子句，并停止执行。在另一个实施例中，开发者可能希望实例化部分对象，从而应用程序能够利用域上下文来分析多义性，并进行话语的部分执行。可以想像到许多可能情况，其中在每个子句中，开发者可自由地编写代码来进行应用程序特定的功能。
在较佳实施例中，可用采用RecipientName作为槽的Named约束子句来创作RecipientEntity。RecipientName将是NamedEntity定义的，从而在进行语义处理之前，接受者的名字的实例将位于整个用户输入中。这允许对RecipientEntity实例的加强的识别。
假设“Bob”是有效的RecipientEntity，如前所述，RecipientEntity定义在程序中的某处。在该实例中，“with restriction”位于SendMailCommand使用的MySendFrame内。调用“with restriction”子句中的代码。“with restriction”内的代码向开发者提供了拒绝该约束的灵活性。如果该子句成功，则该约束被接受。否则，可连续地调用替代的“with restriction”子句，直到它们中的一个成功为止，并且，如果没有一个成功，则忽略该约束。在一个替代的实施例中，如果约束子句失败，则调用失败分析。最后，按顺序调用MySendFrame和SendMailCommand的success子句(框420和422)。
一般地，本领域的技术人员将理解到LOM中的以及由SPL实现的约束和其它对象可被配置成调用任何数量的功能或过程，而不管是成功或是失败。该流程图是示出示例性的流程可能如何进行的简单例示。然而，可预见到许多其它的变型，并且这些变型与本发明所适用的可能的客户端应用程序的数量一样众多。
在该解析过程中，产生了一个连通图。每个实体是该连通图中的一个节点，实体之间的关系由LOM定义，并相对于应用程序域来进行验证。本领域的技术人员将理解到节点和关系是强类型的。该连通图代表了该域的语言中说了什么。
重要的是要注意到SPL对象(命令、实体、构架和约束)的存在是由创作的代码连同语义分析一起确定的。一般而言，相对于构架、实体、命令或约束的解析涉及确定这些对象相对于应用程序域的存在/有效性。直到对象的限制被满足之前，对象不实际存在(是无效的)。可用C#对象结构来绘制它的模拟。在C#中，对象可具有构造函数，编程者可为构造函数编写代码，以抛出异常。如果某个限制不被满足，异常防止对象存在。
当该“系统”试图创建对象时，它调用这些构造函数。从而，构造函数中创作的代码能够确定类的存在。概念上，其核心类型的SPL解析将此概念作为进一步的步骤，使其形式化，使其更丰富，并使其成为系统的原有部分。必须被满足的限制是话语的域创作的知识和语义分析的组合。
D3.继承
概念封装和组合性是通过传统的面向对象的技术(诸如对象重用、继承、多态性等等)来实现的。例如，为了对“send mail to Bob”和“send instant messageto Bob”进行建模，我们可以声明MySendFrame采用MailEntity和InstantMessage的超类型。表82例示出根据本发明的实施例的MySendFrame。
                       表82：MySendFrame
     Entity ItemEntity
     {
     }
     entity MailEntity：ItemEntity
     {
     }
     entity InstantMessage：ItemEntity
     {
     }
     frame MySendFrame：send<DoneTo.what：＝ItemEntity>
     {
         on resolve
         {
             with restriction Goal<goal：＝
           RecipientEntity>
             {
             }
         }
     }
然后就可能如下为“send mail”和“send instant message”定义单独的命令。
    command SendIMCommand uses MySend<DoneTo.what：＝
  InstantMessage>；
     command SendMailCommand uses MySend<DoneTo.what：＝
 MailEntity>；
“sending item to Recipient”的概念由MySendFrame来封装，并可由SendIMCommand和SendMailCommand来重用。还可能重用MySendFrame组合性。表83中给出了其例子。
                      表83：MySendFrame
    entity MailEntity
    {
        on resolve
        {
             with frame MySendFrame<DoneTo.what：＝
          this>；
        }
    }
从广义上来说，上述讨论捕捉了“mail sent to Bob”的语义。
一般来说，SPL为开发者提供了推出应用程序域以及使得这种推理以深度的和有意义的方式影响分析的能力。SPL允许说明性地和程序性地进行这种推理。再次参考MailEntity语法，该语法建立了说明性限制，表示MailEntity是由MailWods中规定的一列单词表示的实体，并可限制到位于MailFolder位置中。表84例示出MailEntity。
                      84：MailEntity
    entity MailEntity denoted by MailWords
    {
       on resolve
         {
              with restriction Location<loc：＝
          MailFolder>；
         }
    }
    entity MailFolder denoted by FolderWords
    {
         on resolve
         {
              with restriction Named<name：＝string>；
         }
    }
诸如“Mail in Foo”、“mail located in folder Foo”等之类的话语相对于MailEntity而成功，因为MailFolder上的Named约束子句接受所有串。
在某些情况下，可能希望编写代码来判断“Foo”是否真的是当前用户的邮箱内的当前有效的文件夹。进行此的唯一方法是编写程序代码来检查运行时间的“Foo”的有效性。表85例示出检查运行时间文件夹名的有效性的用于MailFolder实体的语法。
               表85：具有程序检查代码的MailFolder
     entity MailFolder denoted by FolderWords
     {
       on resolve
       {
              bool haveName＝false；
              on success
              {
                 return haveName；
              }
              with restriction Named<name：＝string>
              {
                   haveName＝
                IsValidFolderName(Named.name)；
                  return haveName；
              }
          }
    }
如果“Foo”不是当前有效的文件夹，则MailFolder的解析失败。根据特定的实现方式细节，失败可意味着一般的失败。可选地，约束的失败可导致约束被忽略。在一个实施例中，如果MailFoler解析失败，那么MailEntity也失败，并且在解析链上也是(例如意味着一般失败)。在较佳实施例中，如果MailFolder的解析失败，那么MailFolder约束被简单地忽略。本领域的技术人员将理解到这仅仅是一个简化的例子。可使用复杂得多的有效性检查，这取决于实现方式。
实现此效果的另一种方式将会是创建NamedEntity类型FolderName，并使用它作为Named约束的槽。
调用子句(begin、success、failure以及with restriction)的一个好的副作用是，开发者能够编写代码将语义对象绑定到应用程序对象。例如，在Named约束子句中，如果名字有效，开发者可编写代码来获得对文件夹应用程序对象的引用。表86例示出用于这种引用的语法
           表86：将语义对象绑定到应用程序对象的代码
      entity MailFolder denoted by FolderWords
      {
        MAPIFolder folder；
        on resolve
        {
        with restriction Named<name：＝string>
        {
           folder＝GetFolder(name)；
                   if(folder＝＝null)return false；
        }
        }
      }
该语法有效地将应用程序特定的对象，MAPIFolder，绑定到语义对象，MailFolder。
一般地，开发者能够容易地编写代码推出分析的关键点处它们的应用程序的上下文和状态。这种推倒能够影响最终的解析分析。例如，为了确定“Bob”是否是有效的接收者，开发者可编写代码来转到系统的当前用户的数据库。如果不是，开发者可以编写代码来处理该失败。例如，开发者能够正好在失败点显示弹出窗口或对话框用于用户澄清，产生再声明等等。通过在失败点向用户提供即时反馈，系统促进了智能的、良好开发的应用程序的出现。
可选地，如果应用程序不处于适当的状态，开发者可以在顶层的SendMailCommand处编写代码以防止解析域命令相逆。语义分析和推出域知识之间的这种深度集成对于理解和消除自然语言歧义来说是非常重要的。
通过允许开发者在子句中编写代码来拒绝解析，SPL使得开发者能够早早作出对不正确的分析的拒绝。一般来说，作者可在成功的解释和失败的解释上插入许多控件。在某些情况下，作者可能希望在处理的早先阶段拒绝某些解释。一般来说，作者越早地能够消除歧义(去除歧义)，应用程序就越容易管理歧义。更少的歧义意味着更少的解释。为自然语言创作的任何应用程序必须具有某种机制，用于管理多个解释。作者或者编写代码在解释器进行判断时评估解释的健全性，或编写进行了语义分析以消除歧义和在一组解释中进行选择之后发生的代码(后处理)。不难看出前者将更容易管理和编写代码。
此外，人们相信能够越早地拒绝解释，就能够越快和越精确地发现最佳的解释。
在某些情况下，作者可能希望在处理中稍后拒绝解释。较早地拒绝解释常常涉及作出回调到客户端应用程序，以检查状态和/或上下文，以及推出应用程序的对象模型。如果回调需要跨越网络，那么作出经常的回调就会引起系统操作变慢。例如，传输延迟会致使系统不可用。SPL允许作者对何时作出回调和何种回调进行完全控制。从而，开发者能够为其自己判断回调和后分析消除歧义逻辑的正确平衡是什么，这取决于客户端应用程序的特性。
可选地，在某些实现方式中，开发者可能希望在判断出是否要拒绝解析之前推出整个解析。可能存在这种情况，其中分离的片段不能确定成功或失败，并且要求对解析树的全局推理。
SPL让开发者根据他们的需要和客户端应用程序的需要来选择如何平衡早决绝和晚拒绝。
如先前所讨论的那样，SPL运行时间对构架、约束和实体的解析本质上构建了依赖于域的话语模型。这种声明保证了详细描述。
在自然语言中，语法构造可用于表达多个含义。作为一个非常简单的例子，考虑介词“on”之后跟一名词。例如，考虑短语“on Foo”。短语“on Foo”可指代Location(如在“book on table”中)或可意味着Topic(如在“book onSeattle”)。为了判断哪个短语是正确的，必须消除该短语的歧义。这种歧义消除仅可由应用程序来进行。例如，表87例示出用于起动Amazon.com的语法。
                      表87：书籍销售者语法
entity BookEntity denoted by″book″
{
      on resolve
         {
         with restriction Topic<topic：＝string>；
         }
}
当解析“book on Foo”时，语义分析将不会产生Location对象，因为BookEntity仅理解Topic。对于说了什么的解析出的模型将不包含Location。在对协调(和/或)、否定和子句的建模中，这种“指向”更为明显。
对于协调，SPL代码定义了实体和它们的修饰语如何分布在逻辑与和逻辑或上。对于话语“find mail and notes created yesterday”，可能的建模选择包括：
    1.Find(mail created yesterday)and(notes created yesterday).
    2.Find(mail)and(notes created yesterday).
    3.Find(mail created yesterday)and find(notes created yesterday).
    4.Find(mail)and find(notes created yesterday).
“created yesterday”以及“find”是如何用其实体“mail”和“notes”进行分布的是由创作的代码来确定的。对于既包含逻辑与也包含逻辑或的话语来说，可能的读法更多。对于作者来说，没有必要理解所有的可能性。作者仅仅按照他们的应用程序的语义来考虑。例如，作为SPL作者，可能编写FindMailCommand，使得我的FindMailCommand仅理解类型MailEntity的实体，以及我的FindNotesCommand仅理解类型NotesEntity的实体。此外，MailEntity不具有创建时间的概念(这仅是出于例示目的)，但是NotesEntity具有。因此，对于上述话语“find mail and notes created yesterday”来说，语义分析将仅从上述列表中产生读法4。
对于否定，创作的代码确定否定范围歧义是如何被建模的。例如，采用话语“Don’t allow mail from Joe”。该短语可被如下解释：
1.Don′t allow mail from Joe(block it instead)：否定作用于“allow”；
2.Don′t allow mail from Joe(but allow messages from him)：否定作用于“mail”；或者
3.Don′t allow mail from Joe(but allow mail from someone else)：否定作用于“Joe”。
创作的SPL程序确定否定如何确定范围和建模。语义分析引擎提供所有可能的读法。
对于子句，创作的代码确定是将子句建模成基于构架的约束(以动词为开头的约束)还是预定约束之一。例如，“book that discusses Foo”中的子句“thatdiscusses Foo”可被构建为Topic约束，或可被建模成对“book”的基于构架的约束。表88给出了用于BookEntity的语法的例子。
                    表88：BookEntity
    Entity BookEntity denoted by″book″
    {
         on resolve
         {
         with frame discuss<DoneTo.what：＝string>；
         }
    }
一般地，从SPL的观点来看，SPL程序的角色是定义应用程序的域的自然语言语义模型。语义分析的角色是根据分析引擎对语言的理解将话语映射到该SPL程序定义的模型。
从平台的观点来看，语义平台的角色是定义关于说了什么的高度抽象的、域无关的对象模型。从该点来看，SPL代码的角色是从平台提供的可能性中挑选。
一般地，SPL程序的解析可被理解成构建关于说了什么的与域有关的语义模型。在构建这种与域有关的模型的过程中，域无关的对象变成强类型的，且可被锚定(映射)到应用程序的对象。
E2.类型系统
一般地，核心SPL类型是commands(命令)、frames(构架)、entities(实体)、以及restrictions(约束)。这些被称为是可解析的类型，因为它们要求解析语义来确定它们的存在。
      [resolvable type]
      {
           on resolve
           {
                begin
                {
                }
                success
                {
                }
                fail
                {
                }
            }
        }
“on resolve”子句内的每一项都必须处理解析语义。begin、success和fail子句都是可选的。在“on resolve”中可以最多存在各子句中的一个。
begin子句在可解析的类型的解析开始时被调用。按照默认方式，子句返回“true”(真)。开发者可返回“false”(假)，它向SPL解释器发信号以停止相对于该类型的解析。这意味着解析失败，并且fail子句被调用。begin子句是一种用于开发者进行初始化和检查应用程序是否出于合适的上下文环境/状态来处理类型的便捷场所。
当相对于该类型的解析成功时，调用success子句。这是开发者能够编写代码来清除资源或包装解析结果的地方。开发者仍然能够通过返回false来决绝解析。
当解析未能成功时，调用fail子句。类似于begin子句和success子句，fail子句可返回“false”，这将有效地使类型的失败的解析变为成功。
在一个实施例中，除了command之外，所有可解析的类型都能具有任何数量的约束子句。这在Slots和“with restriction/Frame子句”中有更为详细的讨论。在一个可选的实施例中，所有可解析的类型，包括command类型，都能够具有任何数量的约束子句。下面讨论每种可解析的类型(Commands、Frames、Entities、和Restrictions)
Commands是由客户端应用程序支持的自然语言(NL)起动的任务。在客户端应用程序的开发过程中，作者创建命令来描述他们想处理的动作。Commands向语义分析提供了进入应用程序的任务入口点。SPL解析在command处开始，并树形向下递归。响应于用户命令来调用Commands。这类似于诸如响应于用户点击鼠标而调用了鼠标点击之类的Windowns事件。表89示出了根据本发明的实施例的命令声明的语法。
                       TABLE 89：命令声明
Command CommandName uses FrameObject<optional slots>
{
}
例如，“Command SendMailCommand uses MySendFrame”定义了适用MySendFrame对象的SendMailCommand对象。Commands实质上包围着构架对象。在命令中仅可规定一个构架对象。
命令中的begin子句有助于检查应用程序是否出于适当的上下文环境和/或状态来处理该命令。这允许根据应用程序的知识来非常早地决绝命令。
在success子句中，开发者能够直接执行命令或包装为执行命令而需要的任何数据。包装的数据可以采用URL的形式、任务的XML描述、对能够执行该命令的功能的委托等等。作者仍然能够在success子句中进行其它推理，并通过返回“false”值来拒绝解释。这是有用的，因为它允许作者在全局上推出整个话语。换言之，作者能够查看完全解析的语义树，以查看解析整体上是否是相干的。片段可以独立地或在有限的上下文中相干，但是它们一起可能没有意义。
“Unknown”(未知)命令处理不映射到创作的命令的华裔。在一个实施例中，SPL强制该命令的存在。
Frames(构架)一般涉及动词。有两种类型的Frames：基本构架和复合构架。基本构架涉及一个动词。例如，构架find涉及动词“find”。复合构架是多个动词的组合，这些动词一般具有相同的含义。复合构架及其多个动词可被看作是同义词列表。一般而言，语义平台提供预定义的一组基本构架，每种构架用于一个动词。出于一致性，约定基本构架的名字是小写字体，并且它们具有与它们的词汇单词相同的名字。相反，复合构架的名字以大写字母开头。语义平台提供了公共的一组复合构架。例如，平台能够提供Search复合构架，它将“find”、“search”、“look”和“rummage”组织在一起。
表90例示出用于定义基本构架的语法。
                       表90：基本构架
    frame FrameName denoted by″word″behaves as VerbClass
    {
    }
例如，表91示出用于find构架的语法。
                       表91：find构架
     frame find denoted by ″find″behaves as
DefaultVerbClass
     {
     }
该语法定义了基本构架find，它由词汇单词“find”来表示，并且它表现在DefaultVerbClass中。术语“find”被称为表示构架find的标志牌(denoter)。语义平台定义了覆盖所有动词的一组动词类行为。大多数的动词具有作为DefaultVerbClass的一部分的行为。
词汇单词不必表现为内联的。实际上，为了支持多个语言，建议单词不表现为内联的。它们应该定义在它们自己的对象中。表92例示出用于定义的标志牌对象的语法。
                       表92：标志牌对象
    denoter FindWord
    {
        English：＝″find″；
        French：＝″chercher″；
    }
通过以此方式分开地列出标志牌术语，而不是与构架定义内联，依赖于语言的元素就很好地与独立于语言的元素分离开。
语义平台提供的所有基本构架都以此方式定义在SPL代码中。开发者还能够如此定义他们自己的动词。例如，在一个实施例中，开发者可以定义如下定义fop基本类：
    frame fop denoted by“fop”behaves as DefaultVerbClass；
可选地，在较佳实施例中，开发者可以如下定义fop基本类：
    frame fop denoted by“fop；
人们相信很大一部分动词(大约95％)的语言实现与它们的词汇单词相同。在大多数情况下，将存在相当直接的对其它语言的翻译。对于跨语言不能以此方式起作用的动词来说，denoter类中提供了一种机制来规定那些动词的语言实现。
如上所述，复合构架是动词的分组。它们实质上是同义词列表。在创造复合构架时，仅分组中适用的构架的标志牌被复合构架“继承”。
SPL向开发者提供了从基本构架和复合构架中创建他们自己的分组的能力。表94中给出了一个例子。
                        表94：复合构架
    frame CompositeName groups frame1，...，framen except
  framex，...，framey
    {
    }
实质上，该声明建立了groups子句中规定的构架的所有标志牌的逻辑联合(union)，去除了重复，并去除了except子句中规定的构架的标志牌。except子句是任选的。
例如，表95例示出定义中包含except子句的复合构架。
                表95：具有except子句的复合构架
frame MySearchFrame groups Search，fop except find
{
}
这定义了除了find构架的标志牌之外将Search和fop的标志牌分组在一起的MySearchFrame。
也可创造出从其它构架、基本构架或复合构架继承而衍生出的构架(derived frame)。表96例示出用于衍生出的构架的语法。
                      表96：衍生出的构架
Frame DerivedFrame：BaseFrame<slot1，...，slotn>
{
}
在下面的部分E3中更详细地讨论继承(Inheritance)的主题。
实体是应用程序中可被称为名字或描述的对象。实体可以是具体的物，例如文件项目和email项目，但是它们也可表示抽象的概念，例如颜色、纹理等等。实体通常由词汇单词来表示。表97示出了用于声明实体的语法。
                        表97：实体声明
    entity EntityName denoted by″word1″，...，″wordn″
    {
    }
例如：
    entity MailEntity denoted by″mail″，″electronic mail″，
″email″
    {
    }
类似于构架，建议不内联地规定标志牌，以便支持多个语言。表98提供了这种标志牌的例子。
                         表98：标志牌
     entity MailEntity denoted by MailWords
     {
     }
     denoter MailWords
     {
       Japanese：＝noun(″メッセ一ジ″)，noun(″電子メ一ル″)；
         English：＝noun(″mail″)，noun(″email″)，
       noun(″electronic mail″)；
     }
denoted by子句允许作者规定表示实体的一列自然语言单词。denoted by子句是开发者可借助来将实体连接到词汇单词的手段。实体不需要由单词或一组单词来表示。实体可通过它们的约束来描述。开发者不需要规定单词的各种形式(例如“file”和“files”)，因为语言平台维护着这些形式。此外，标志牌不需要规定在话语中，以便实体成功。然而，如果标志牌包含在话语中，标志牌必须匹配实体列表中的一个标志牌。
在某些实施例中，可能希望在声明时标志牌是任选的。此外，在某些实现方式中，可能希望添加强制性标志牌(必须包含在话语中用于实体成功的单词)。“强制性”标志牌的存在可通过包含在success子句中的代码来强制。
表99示出了通过success子句强制的强制性标志牌的例子。
          表99：通过success子句的强制性标志牌强制
      entity MailEntity denoted by MailWords
      {
        on resolve
        {
            success
            {
                        if(this.Denoter＝＝null)return
                      false；
            }
        }
      }
一般地，约束是类型化的语义关系。平台提供基本的一组预定义的关系。关于约束的最重要的方面之一是语言内和跨语言的语法中的偏差的规格化。约束是语义上的，而不是语法上的。从而，约束允许开发者相对于语言的语义而非语法来编写代码。约束很大地减少了创作负担，并允许其它语言成为可能。
某些约束伴随着具有特定含义的系统定义的槽一起。上述部分D中给出的LOM的讨论提供了代码样例和槽的某些讨论。表100中列出了某些公共约束。
                   表100：公共约束列表
  约束语法   应用
  Doer<who：＝Entity>DoneTo<what：＝Entity>Location<loc：＝Entity>TimeTopic<topic：＝Entity>，Topic<topic：＝string>Source<src：＝Entity>   运用到构架。它表示作动作的实体。例子：“Bob opened the file”、“thefile was opened by Bob”。运用到构架。它表示动作所针对的实体。例子：“open the file”、“the filewas opened”。对位于某处的语义进行建模。例子：“mail in Inbox”、“file located on thedesktop”。对实际事件表达式进行建模，即能够转换成时间点和/或时间跨度的表达式。例子：“delete after 3days”、“mail from yesterday”、“schedulefor tomorrow from 1-3pm”。对主题物进行建模。例子：“bookabout dogs”、“book regarding dogs”、“book with the subject dogs”。对对象或源进行建模。例子：“mailfrom Bob”。
 OrderCardinalOrdinalMeans<instrument：＝Entity>Possessor<owner：＝Entity>AccompanimentDegreeNegationNamed<name：＝string>Modifier<mod：＝Denoter>   例子：“sort in alphabetical order”、“display in reverse order by name”。例子：“3files”例子：“first file”例子：“search using Google”、“openwith Word”例子：“my book”、“Bob’s book”例子：“meeting with Bob”例子：“almost in the box”、“extremely red”、“very large”、“more to the left”例子：“not from Bob”、“don’t sendmail”、“except for Bob”这表示实体的名字。例子：“Inboxfolder”、“file named foo.txt”这表示形容词修饰语。例子：“largefile”、“school bus”
存在一种特殊的约束，称为Default(默认)约束。Default约束由SPL运行时间在可解析的类型上存在未解析的或未识别的约束时被激发。
开发者通过从预定的约束组中的一个进行继承、通过创建基于构架的约束、或通过规定模式来创建他们自己的约束。
一般地，约束可运用于实体和构架，以及其它约束。作为一般规则，SPL不强制运用某一约束是否有语义意义。SPL作出某些例外，简化语义模型或者减少岐义性。表101中给出了例外(exception)。
                      表101：SPL例外
 1.对于约束仅允许Degree约束。
 2.对于构架仅允许Doer和DoneTo约束。
 3.对于实体不允许Negation。
使用下面的语法将约束运用于类型：
    with restriction RestrictionName<slot1：＝type，...，slotn：＝type>；角括号中的变量称为槽。“with restriction”声明称为约束子句。选择标记“restricton”以避免某些问题。例如，可把约束标记为“properties”，但是properties不总是充当描述符。例如，某人可以将“mail in Inbox”认为是“mailwith the property of being in the Inbox folder”。然而，对于数量词来说，例如基数词和序数词，这种关系并不存在。短语“three files”不等同于“files with theproperty of three”。而且，单词“property”早就用于传统的编程范例中(例如“properties of a list box”)。一般希望不使术语“properties”负担过重，对于单词“attribute”来说同样如此。
相反，Entity意图覆盖集合的概念。SPL中的“entity”声明实际上规定了一组实体，运用约束是对该组的限制。例如，用于声明由Mail表示的MailEntity的语法entity MailEntity denoted by“mail”是表示所有邮件项目的集合的对象的声明。表102例示出用于运用到实体的约束的语法。
                  表102：运用到实体的约束
    Entity MailEntity denoted by″mail″
    {
         on resolve
         {
              with restriction Location<loc：＝
            MailFolder>；
          }
    }
这里，邮件项目的集合被限制到MailFolder位置。
将约束运用到构架应被看作是限制动作(Frames一般对动词或动作建模)。表103例示出具有约束的构架(Frame)。
                    表103：对构架的约束
frame MyOpen：open<DoneTo.what：＝FileEntity>
{
     on resolve
     {
          with restriction Means<instrument：＝
        NotepadEntity>；
     }
}
这里，Means约束运用于MyOpen构架，从而将打开文件动作限制到使用Notepad(记事本)。
同样的道理适用于对约束的约束。例如，Cardinal(基数词)约束表示实体的基数。短语“3files”表示任何的3个文件。然而，可由Ordinal(序数词)来限制基数，例如“first 3files”。表104例示出运用于约束上的约束。
                       表104：约束上的约束
   restriction OrdinalCardinal：Cardinal
   {
         on resolve
         {
              with restriction Ordinal；
         }
     }
这里，约束子句通过运用序数来限制基数。
一般地，除了命令之外，可解析的类型可具有运用于它们的任何数量的约束。可多次运用每个约束类型，只要特征(signature)是唯一的。表105示出了具有带有唯一特征的多个约束的Frame。
                 表105：具有多个约束的Frame
frame MyOpen：open<DoneTo.what：＝FileEntity>
{
     on resolve
     {
          with restriction Means<instrument：＝
        NotepadEntity>；
     //有效的约束子句
     with restriction Means<instrument：＝MSWordEntity>；
     //无效的约束子句，因为特征不唯一
     with restriction Means<instrument：＝NotepadEntity>；
     }
}
约束子句激发的顺序取决于语义分析。一般地，该顺序基于语言证据、统计排列、以及依赖于域的学习的组合。在某些实现方式中，可添加机制来强制确定性的顺序。SPL运行时间根据SPL的语言语义和语义分析来激发约束子句。
如上所述，槽是角括号(<>)中出现的变量。槽语法用于在使用时对槽子类型化。SPL具有多个预定义的约束的槽。例如，语义系统如下定义了Goal约束：
      Goal<goal：＝Entity>
goal槽具有基本Entity类型，并可被称为与域无关的说明。当开发者将该与域无关的Goal运用于一可解析的类型时，该开发者能够在应用时将goal槽子类型化。表106示出了包含子类型化的goal槽的Frame的语法。
              表106：具有子类型化的Goal槽的Frame
frame send denoted by″send″
{
     on resolve
     {
          //对″send to ContactItem″进行建模
          with restriction Goal<goal：＝ContactItem>；
     }
}
这里，开发者已将goal槽子类型化成ContactItem(ContactItem必定是实体类型)。
在约束子句的代码中，可按照对象来访问约束。表107示出了用于按照对象来访问约束的语法。
                   表107：按照对象访问约束
    with restriction Goal<goal：＝ContactItem>
    {
         item＝Goal.goal；
    }
一般地，可使用类似于C++模板之类的手段来将可解析的类型概念化。例如，可把Goal约束看作是具有一般类型的goal数据成员的template Goal class(模板Goal类)。于是，用于上述Goal约束子句的伪C++代码如下：
bool OnGoalClause(GoalTemplateClass<ContactItem>Goal)；
SPL编译器强制进行goal槽的子类型化。
可解析的类型的使用者可能希望对类型的约束子句子类型化。例如，上述send构架的使用者可能希望使用如下的槽语法对其Goal约束子句的goal槽子类型化：
     command MySendCommand uses send<Goal.goal：＝MyContactItem>；
由于可能存在许多运用于send构架的Goal约束子句，开发者必须能够规定哪个是所涉及的。
另一种约束是AsProperty约束。asproperty属性允许可解析的类型的使用者使用槽语法对约束子句子类型化。该属性在约束子句处规定，如表108所示。
                   表108：AsProperty属性
    frame send denoted by″send″
    {
          on resolve
          {
               with asproperty restriction Goal<goal：＝
            ContactItem>；
          }
     }
这里，send构架的开发者声明使用者可使用如下的槽语法来对send构架的Goal约束子句子类型化：
    command MySendCommand uses send<Goal.goal：＝MyContactItem>；
该声明意思是，MySendCommand使用send构架，并将send构架的Goal约束子句子类型化成MyContactItem。
一般地，asproperty属性还允许send构架中的代码使用property(特性)语法来访问该Goal对象。所有可解析的类型都具有RestrictionCollection特性，允许代码得到其当前解析出的约束的集合。利用asproperty属性，可使用特性语法来访问标记出的约束，如表109所示。例如：
             表109：使用特性语法来访问标记出的约束
     frame send denoted by″send″
     {
          ContactItem item；
          on resolve
          {
              with asproperty restriction Goal<goal：＝
            ContactItem>；
              success
              {
              //常规语法
                  if
                (this.RestrictionCollection(″Goal″).cou
                nt>0)
                  {
                       item＝
                    this.RestrictionCollection(″Goal″)
                    [0].goal；
                  }
             //特性语法
                 if(this.Goal.goal！＝null)
                 {
                 item＝this.Goal.goal；
                 }
              }
         }
    }
此外，每个类型中仅有一个约束可用asproperty属性来标记，而不管约束槽的类型是什么，如表110所示。
                 表110：AsProperty约束限制
    frame send denoted by″send″
    {
         on resolve
         {
              with asproperty restriction Goal<goal：＝
            ContactItem>；
              //非法的
              with asproperty restriction Goal<goal：＝
            UserItem>；
            }
     }
然而，该语法可由开发者改变，以允许类型的不止一个约束用asproperty属性来标记，如下：
restriction Goal2：Goal<goal：＝UserItem>；
这消除了问题，并允许构架进行解析，如表112所示。
                       表112：约束语法
frame send denoted by″send″
    {
          on resolve
          {
              with asproperty restriction Goal<goal：＝
            ContactItem>；
              //在这里不必使用槽，但是对于文档记录来说是较佳的
              with asproperty restriction Goal2<goal：＝
            UserItem>；
              //该子句本该写成：“with asproperty
            restriction Goal2；”
          }
    }
就约束子句中的槽的排序而言，重要的是要理解到某些约束是用系统槽来定义的。例如，Goal约束是用goal槽定义的。当在使用时(即在约束子句处)对Goal约束子类型化时，必须首先规定系统槽，如表113所示。
                      表113：槽的排序
    restriction Goal2：Goal<goal：＝Item>
    {
         on resolve
         {
              with asproperty restriction Modifier<mod：＝
            Denoter>；
         }
    }
    frame send denoted by″send″
    {
          on resolve
          {
               //非法的
               with asproperty restriction Goal2<
               Modifier.mod：＝MyDenoters，
               goal：＝ContactItem>；
               //台法的
               with asproperty restriction Goal2<
               goal：＝ContactItem，
               Modifier.mod：＝MyDenoters>；
          }
    }
约束子句用asproperty标记的实体能够在使用时使那些约束子句子类型化。例如，假设ContactItem使得Location约束子句用asproperty标记，如表114所示。
            表114：标记AsProperty的Location约束
     frame send denoted by″send″
     {
          on resolve
          {
               with asproperty restriction Goal<
               goal：＝ContactItem<Location.loc：＝
            DerEntity>>；
         }
    }
约束子句还可标记为obligatory，意思是该子句必须被执行并成功，否则该类型的解析失败。为了该子句成功，必须满足下面的准则：
1.该约束必须处于话语中；
2.子句的说明性限制(槽的类型)必须被满足；以及
3.子句中的程序性限制(代码)必须估计为真。
表115中给出了一个例子。
                   表115：Obligatory约束
frame send denoted by″send″
{
     on resolve
     {
          with obligatory restriction Goal<goal：＝
        ContactItem>；
     }
 }
表115中的构架的语法声明了，为了send构架成功解析，话语中必须存在ContactItem作为“send”的目标。所以，“send mail”将不会解析，但是“sendto Bob”将会，其条件为“Bob”是解析出的ContactItem。
E3.SPL继承
实体、构架和约束上都允许继承。当前，命令不支持继承。一般地，似乎(此时)无需在命令中支持继承。命令是不要求继承的任务入口点。
所有的“可继承的”代码处于命令所使用的构架中。如先前所讨论的那样，除了on resolve子句中的解析语义之外，可解析的类型仅仅是常规的对象。onresolve子句之外，SPL采用C#继承语义，这是本领域已知的。为了本讨论的目的，本揭示聚焦于不遵循传统的(C#)继承语义的on resolve子句内的继承语义。然而，在某些实现方式中，可能希望不同于传统的C#继承语义，用于使用继承在真实的应用程序中起动特定的功能。出于简化的目的，该讨论不深入研究所有这些可能性，选择规定的做法试图使得讨论简单。
首先，重要的是理解函数、约束子句和on resolve子句中的变量的范围。表116示出了用于Mail Entity的语法，以便于范围的讨论。
                       表116：Mail Entity.
   entity Mail
   {
        int x；
        on resolve
        {
             int y；
             with restriction Goal<goal：＝Entity>；
             void foo()；
        }
        void bar()；
   }
on resolve范围内定义的变量对于on resolve范围内的约束子句来说是可访问的，但对于on resolve子句外的来说是不可访问的。在上述的例子中，整型值y在Goal约束子句和函数foo()中是可访问的，而在函数bar()中是不可访问的。
on resolve子句中定义的函数对于该子句来说是私有的，意思是在onresolve子句外不能访问这些函数。从而，在bar()中不能访问foo()。约束子句同样对于on resolve子句来说是私有的，因此在其外部不能访问。
类型的范围中声明的变量是可由on resolve子句中的子句和函数通过使用outer关键字来访问的。例如，整型值x可按照outer.x而在Goal约束和函数foo()中访问。类型的范围中声明的函数对on resolve子句来说是可访问的。从而，在Goal约束和函数foo()中可按照outer.bar()访问函数bar()。
可把on resolve子句概念化成扩展的构造函数，从而属于该构造函数的每一元素对于该构造函数来说都是私有的。这暗示出衍生出的类不能调用基本类中的任何约束子句。
允许实体从另一个实体继承。不允许实体的多重继承。基本实体的标志牌合并于衍生出的实体的标志牌。如表117所示，合并的标志牌列表中没有层次(标志牌被平坦化)。
                   表117：合并的标志牌列表
    entity MailEntity denoted by″mail″，″email″
    {
    }
    entity MyMailEntity denoted by″electronic mail″：
  MailEntity
    {
    }
MyMailEntity的标志牌列表将由“mail”、“email”和“electronic mail”组成。
在定义时，衍生出的实体也能对用asproperty标记的基本实体的约束子句进行子类型化。例如，如果MailEntity具有用asproperty标记的Location约束子句，则MyMailEntity定义可如下所示：
    entity MyMailEntity denoted by″electronic mail″：
          MailEntity<Location.loc：＝MyEntity>
    {
    }
该代码块意思是MyMailEntity继承可MailEntity的Location理解，但对实际位置添加了更多特征。
类似于实体，构架仅能从另一构架继承。不允许多重继承。在定义中，衍生出的继承不能规定构架的任何分组。复合构架和构架继承是分离的。可能按照与实体相同的方式来处理构架的继承。例如，在复合构架中，标志牌列表被分组在一起。在某些情况中，可能希望强加当构架被分组时所有构架都属于相同行为的类的要求。如果分组中的构架不需要属于相同的LSS类，那么，可以相同的方式处理构架和实体。
类似于构架和实体，衍生出的约束仅可从另一约束继承。基本约束的约束子句的子类型化也可在衍生出的约束的定义处发生。
某一约束类型的约束子句在转到基本类型之前以衍生出的类型被尝试。这同样适用于Default约束，如表118所示。
                     表118：Default约束
    entity MailEntity denoted by″mail″，″email″
    {
        with restriction Location<loc：＝Entity>
        {
        }
        with restriction Default
        {
        }
    }
    entity MyMailEntity denoted by″electronic mail″：
 MailEntity
    {
        with restriction Location<loc：＝MailFolder>
        {
        }
        with restriction Default
        {
        }
    }
当解析MyMailEntity上的Location约束时，激发约束子句的顺序如下：
    1.MyMailEntity.Location
    2.MailEntity.Location
    3.MyMailEntity.Default
    4.MailEntity.Default
当前不存在公共/私有约束子句的概念和最重要的约束子句(overridingrestriction clause)的概念。在某种程度上，这是因为最重要的约束子句在约束子句用于解析类和子句对于on resolve子句来说是私有的情况下意义不大。然而，可能希望在某些实施方式中允许忽略约束子句。
根据实现方式，可能有必要允许衍生出的类(在解析过程中)访问基本类中的成员(方法和变量)。由于基本类未被解析，这可能是有问题的。如果在基本类被解析之前不允许衍生出的类访问基本类的成员，则必须防止在解析过程中衍生出的类以多种组合形式设置到基本类(通过赋值、传递到函数等)。在任一种情况下，可允许衍生出的类在基本类被解析之前调用基本类上的约束子句。
可利用继承添加对已有的实体的更多的理解。再次参考表118的MailEntity代码，重要的是要注意到MailEntity仅理解Location约束。可能创建一实体，它对MyMailEntity中的创作的Location逻辑起杠杆作用，并添加Topic理解。此外，可添加与base相同类型的约束子句，如表119所示。
                   表119：MyMailEntity.
    entity MyMailEntity denoted by ″electronic mail″：
  MailEntity
    {
         with restriction Location<loc：＝MailFolder>；
    }
    entity MailEntityWithTopic：MailEntity
    {
         with restriction Topic<topic：＝string>
         {
         //处理topic
         }
         //处理MyMailFolder中的位置。所有其它位置都将转到基
       本类
         with restriction Location<loc：＝MyMailFolder>
         {
         }
    }
当约束子句被调用并被子句中创作的代码拒绝时，解释器以当前类型或其多形联合等价超类型(polymorphic-ally equivalent super types)调用约束子句。为了考虑为多形联合等价，约束类型及其槽的类型必须都为多形的，如表120所示。
                         120：多态性
     entity SlotEntity2：SlotEntityl；
     entity MyEntity
     {
          with restriction Location<loc：＝SlotEntity2>
          {
          /*此失败后，解释器将自动地调用后续的Location子句，而
        不再次解析该槽，因为它们是多形等价的*/
          return false；
          }
          with restriction Location<loc：＝SlotEntityl>
          {
          /*该代码可用多形地充当SlotEntityl的SlotEntity2
        来调用。如果该子句失败，解释器将不自动地调用下面的Topic
        约束，因为即使槽是相等的Topic也不相当于Location。*/
          }
         with restriction Topic<topic：＝SlotEntity1>
         {
         }
    }
虽然它们不是完全等价，但是可能在槽处使用继承而非子类型化，如表121所示。
                          表121：继承
      entity MailEntity denoted by″mail″
      {
           with asproperty restriction Location<loc：＝
        MailFolder>
           {
           }
      }
      entity MailEntity2：MailEntity<Location.loc：＝
    MyMailFolder>
      {
      }
      entity MailEntity3：MailEntity
      {
        with restriction Location<loc：＝MyMailFolder>
          {
          }
      }
当相对于MailEntity3来解析“mail in Inbox”时，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约束，如上所讨论的那样。
重要的是要注意到约束子句可在同一可解析的类型上激发多次。例如，命令“show files in c：in temp folder”对“file”实体具有两个Location约束(“inc：”和“in temp folder”)。当前，约束子句的解析的唯一强制的顺序是对构架的Doer和DoneTo约束首先被解析(按顺序)，最后解析Default约束。然而，可能希望对其它类型强制顺序，例如Negation和Named。
如图9所示，在一个实施例中，NamedEntity解析如下进行。运行时间调用Entity的begin子句(框900)。如果这失败，运行时间退出Entity解析(框902)。如果Entity的begin解析子句成功，运行时间试图调用给定发现的且对应于Entity的NamgedEntity的named restriction(有名约束)(框904)。重要的是要注意到框904包含了多个解析步骤，但是这里为了简单而省略了。
如果named restriction的调用失败，调用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所示的组列。
                   表122：Default下产生的组列
     Span[0]
         Tokens＝{token1 token2}
         Hypothesis[0]
             RestrictionType＝restrictioni
             SucceededResolution＝boolean
 …
         Hypothesis[n]
             RestrictionType＝restrictionj
             SucceededResolution＝boolean
 …
 Span[n]
     Tokens＝{token1 token3}
     Hypothesis[0]
         RestrictionType＝restrictioni
         SucceededResolution＝boolean
 …
     Hypothesis[n]
         RestrictionType＝restrictionj
         SucceededResolution＝boolean
原始文本总是可用的。SPL可向作者提供关于文本中的象征记号是否参与成功的解析的信息。
统计语义建模和学习在SPL中能够起作用。调用约束子句的顺序可依赖于基于语言证据、统计排列(例如SGM)和自动学习的某些统计学。如图10所示，系统1000包括运行时间1002和数据库1004。一般地，运行时间1002能够管理数据库1004，数据库是话语和解析结果的储存库。该储存库中的数据可由分析工具1006(例如)在已经到达了某一解析阈值之后来开采和分析(离线)。数据库1004中的信息可由分析工具1006分析，结果可随后反馈到运行时间1002，以提高其要解析的命令的选择和排序以及调用约束子句的顺序。结果，随着更多的话语被解析，可以更好更快地进行解析，而不用改变创作的代码。从广义上讲，系统1000是一种智能系统，能够改善其性能而不用进行重新编码。
在一个实施例中，高级作者能够对储存库进行管理和编程。在另一个实施例中，高级作者能够从子句返回表示置信度的概率，而不是简单的true/false值。虽然这可能使编程模型复杂化，但是获得置信度而非布尔值的能力允许作者在统计学上参与语义分析。
一般地，歧义出现在作者面前，并且由作者在SPL客户端应用程序中处理。歧义不是由多个解释中的代码结果来处理的。运行时间对解释进行分级并返回给应用程序，直到应用程序规定的最大数量的解释。在一个实施例中，解释的列表被同步返回(作为API调用的一部分)。在另一个实施例中，使用事件来异步地返回解释。
运行时间从列表中删除语义上等价的解释。此外，运行时间提供默认的实现方式用于确定两个解释的语义等价性。该默认实现方式可由作者推翻。
在一个实施例中，通过比较重新开始语义解释而生成的串来确定语义等价性。然而，还可利用其它技术来确定等价性。
一般地，开发者不必编写代码来处理话语中可能发生的所有可能的约束。作者仅仅对他们希望理解和希望处理的约束编写代码。非创建的/不处理的约束被丢弃。换言之，非创建的/不处理的约束被忽略，就好像它们未出现在话语中那样。唯一的例外是Negation和Named约束，它们必须被处理。
使用继承来实现语义。可解析的类型都从基本类继承。从而，存在基本实体、基本构架以及基本约束类。基本的可解析的类型具有一个约束子句Default，如表123所示。
                   表123：基本的可解析的类型
   [resolvable type]
   {
       with restriction Default
            {
            //如果不处理的/不解析的约束是Negation或Named，则
          解析失败。否则，约束子句成功。
                  if(Default.TopHypothesis.RestrictionType
               ＝＝Negation||
               Default.TopHypothesis.RestrictionType＝＝
               Named)
                  {
                  return false；
                  }
                  else
                  {
                  return true；
                  }
            }
       }
基本的可解析的类型中的Default约束对于除了Negation和Named之外的所有约束都是成功的。表124示出了用于MailEntity的语法。
                            表124
    entity MailEntity denoted by″mail″
    {
         on resolve
         {
              with restriction Location<loc：＝
            MailFolder>；
         }
    }
对于诸如“mail received yesterday”之类的话语，SPL运行时间试图相对于创作的MailEntity的约束子句解析“received yesterday”。由于“received yesterday”不会映射到Location约束，并且由于在MailEntity中没有Default约束子句，SPL运行时间试图相对于MailEntity的基本类即Entity来解析“receivedyesterday”。Entity中的Default约束子句返回true；因此，MailEntity解析成功。解析成功，就好像话语“mail received yesterday”中仅识别出“mail”一样。
如果这不是所希望的行为，那么开发者能够容易地编写代码来拒绝不识别的/不处理的约束，如表125所示。
           表125：带有处理不识别的约束的MailEntity
    Entity MailEntity denoted by″mail″
    {
        on resolve
        {
             with restriction Location<loc：＝
             MailFolder>；
                //拒绝没有识别的任何东西
              with restriction Default
                {
                     return false；
                }
          }
    }
这里，在调用基本Entity之前测试MailEntity中的Default约束子句。因此，“mail received yesterday”将不会相对于MailEntity进行成功解析。
一般地，on resolve范围外的每个元素都是根据传统的C#规则来处理的。解析子句内的代码也是C#代码。从而，就可能把可解析的类型看作是具有用于确定其构造的专门代码的专门化的C#类。
E5.对LOM编程
对LOM编程涉及使用LOM提供的约束来实现计划的产出。通过研究一些例子就能够最佳地理解。从而，下面的讨论给出了若干例子，详细研究了更为复杂的语义建模约束和子句(诸如coordination(协调)、compairsons(比较)、negation(否定)等等)，并讨论了某些“最佳的”实践。在上面的部分D中已经讨论了关于何种话语产生何种约束以及约束所包含的信息的详细内容。
并非LOM的所有约束类型都暴露于SPL。SPL关注于约束类型来命令和控制各种情况。相反，LOM具有更广泛的适用性。随着新的版本可用，将先前未发现的语义关系暴露为新的约束类型，这将比由于向后兼容的原因而在随后的版本中试图缩小或修改已暴露的约束类型更为容易。在下面的讨论中，我们主要关注于如何使用约束用于以SPL代码建模。一般地，约束向开发者表现为类库，类似于用于Microsoft.Net运行时间的Framework类库(FCL)。
Accompaniment约束对伴随着主体的实体进行建模。在实体(Entities)和构架(Frames)上允许Accompaniment。一些例子包括meeting  with my manager、chat  with Bob、email  with attachments、以及merge  File A with File B。Accompaniment约束包含一个类型Entity的系统槽accomp，表示伴随主体的实体。作者能够抑制能够伴随主体的实体的类型，如表126所示。
             表126：″email with attachments″
     entity MailEntity denoted by″email″
     {
        on resolve
        {
             with restriction Accompaniment<
             accomp：＝AttachmentEntity>；
         }
    }
AsBeing约束挑选出动词所作用于的DoneTo.what实体的某一特性。构架(Frames)上允许AsBeing约束。一些例子包括“show status as busy”、“saveas text file”和“make the font large”。AsBeing约束具有一个系统槽restr，它表示正被挑选出的约束。并非允许任何约束类型来填充该槽，约束的类型被限制到某些特定的约束类型。通过提供在其系统槽内采用各种支持的类型的过载的AsBeing约束，将约束限制到某些特定类型。下面的约束类型是得到支持的(例如)：
   AsBeing<restr：＝Modifier>：“mark message as low priority”
   AsBeing<restr：＝Possessor>：“make this file mine”
   AsBeing<restr：＝Ordinal>：“put this message first”
在某些实施例中，诸如“log in as my manager”之类的短语可能解析成功。然而，这将要求允许实体为槽类型。
AsBeing约束定义了动词、它的DoneTo.what实体、以及对该实体的约束之间的三位关系。虽然SPL并不强制这种关系的强烈绑定，但是最佳的实践将是如表127所示那样强制该关系。
            表127：″show my status as busy″.
   deno ter BusyWords
   {
     English：＝″busy″；
   }
   entity StatusEntity
   {
     on resolve
        {
        //对″busy status″、″status is busy″建模
          with restriction Modifier<BusyWords>；
        }
   }
   /*下面的AsBeing约束用改变的绑定强度水平来对″show status
as busy″建模。*/
frame ShowStatusFrame<DoneTo.what：＝StatusEntity>
    {
         on resolve
         {
         /*这里，我们既不对DoneTo.what也不对其修饰语作出强
      绑定*/
         with restriction AsBeing<BusyWords>；
         /*这里，我们声明与StatusEntity的修饰语更强烈绑定(二
      位的)，但是我们不对动词的DoneTo.what作出强绑定。*/
             with                          restriction
           AsBeing<typeof(StatusEntity.Modifier.mod)>；
         /*这里，我们声明与构架的DoneTo.what及其修饰语的非
      常强的绑定(三位的)。*/
             with restriction AsBeing<
             typeof(DoneTo.what.Modifier.mod)>；
          }
    }
Cardinal约束对数字量词表示的基数进行建模(例如“3files”)。实体(Entities)上允许Cardinal约束。Cardinal对象上存在一个成员Cardinal.member，它给出了实际的基数值，如表128所示。
                       128：″3email″
   entity MailEntity denoted by“email”
   {
         int CountOfEmail；
         on resolve
         {
                with restriction Cardinal
                {
                     CountOfEmail＝Cardinal.number；
                }
          }
   }
Comparison约束对实体与另一个明确识别的实体之间的比较进行建模。它并不是用于诸如“a bigger file”之类的表达式，在这种表达式中要比较的实体是左隐含的(left implicit)。为Comparison定义了两种系统槽：dimension，它是正在进行的比较所处的量纲，以及compareTo，它是作为比较对象的实体。例如，对于“bigger file than mydoc.txt”来说，“bigger”是比较的量纲，“mydoc.txt”是compareTo实体。Dimension是一种约束类型。一般地，Comparison约束允许两个实体在实体的某个特性上进行比较。
比较的一些例子包括：“a book more about cats than dogs”、“mail largerthan 10KB”、以及“make font smaller than 12pts”。在某些实施例中，可能希望强加这样一种要求，即dimension约束具有依附于它的Degree修饰语。例如，短语“file big than mydoc.txt”不应被解析，因为dimension约束不是约束类型。
Degree约束对约束的程度进行建模，并在约束(restrictions)上允许Degree约束。它将very、extremely、slightly、almost、more、less、most以及least之类的单词分组在一起。一些例子包括：“almost in the box”、“extremely red”、“very large”和“more to the left”。分组的单词被分类成表示“degree-ness”的一组。程度类型如下：
    More：bigg er， more relevant
    Most：bigg est， most relevant
    Less： less relevant
    Least： least relevant
    Same： as big
    High： very big， extremely popular
    Low： not very big
应注意到“smaller”被建模成“more small”而不是“less big”。
对于类似于“10KB larger file”之类的话语，它被建模成“10KB”(Modifier)修饰“more”(Degree)，以及组合的“10KB more”概念修饰“large”。相反，话语“10KB large file”被建模成对“file”实体的两个Modifier约束“10KB”和“large”(相当于“large，10KB file”)。表129示出了用于表示“large”的词汇单词的标志牌(denoter)列表的标志牌语法以及用于那些约束所运用于的FileEntity的语法。
            表129：″LARGE″//表示“large”的词汇单词
    denoter LargeWords
    {
      English：＝″large″，″big″
    }
    /*定义必须具有修饰它的MeasureEntity的Degree。这对类似
  于“10KB more”之类的话语建模。*/
    restriction ExtentDegree：Degree
    {
        on resolve
        {
            with obligatory restriction Modifier<mod：＝
          MeasureEntity>；
        }
    }
        /*定义修饰语必须是LargeWords的Modifier约束*/
        restriction LargeModifier：Modifier<mod：＝
      LargeWords>；
        /*定义必须具有Degree约束的LargeModifier约束。这对类似
      于“larger”、“less large”以及“very large”之类的话语建
      模*/
        restriction LargeDegreeModifier：LargeModifier
        {
             on resolve
             {
                  with obligatory restriction Degree；
             }
        }
        /*定义必须具有ExtentDegree约束的LargeModifier。这对
      “10KB larger”建模*/
        restriction LargeExtentDegreeModifier：
      LargeModifier
        {
             on resolve
             {
                 with obligatory restriction ExtentDegree；
             }
        }
        //将那些约束运用于实体：
        entity FileEntity denoted by″file″
        {
             on resolve
             {
                 //″large file″
                 with restriction LargeModifier；
                 //″10KB file″
                 with restriction Modifier<mod：＝
               MeasureEntity>；
              //″larger file″，″extremely large file″，
           ″less large file″，and the like
              with restriction LargeDegreeModifier；
              //″10KB larger file″
              with                         restriction
            LargeExtentDegreeModifier；
              //″larger file than mydoc.txt″
              with restriction Comparison<
              dimension：＝LargeDegreeModifier，
              compareTo：＝FileEntity>；
              //″10KB larger file than mydoc.txt″
              with restriction Comparison<dimension：＝
              LargeExtentDegreeModifier，
              compareTo：＝FileEntity>；
          }
    }
一般地，不必为“more large”和“10KB larger”创建分开的约束类型。它们都能够被置于LargeModdifier下。然后，如果希望的话，如表130所示，对于话语中的“10KB more”和“more”的存在，诸如FileEntity之类的使用者仅仅检查LargeModifier的RestrictionCollection特性。
                   表130：LargeModifier
   Restriction LargeModifier：Modifier<mod：＝
 LargeWords>
    {
         on resolve
         {
         with restriction Degree；
         with restriction ExtentDegree；
         }
    }
    entity FileEntity denoted by″file″
    {
         on resolve
         {
         /*″large file″，″larger file″，″10KB larger
       file″*/
         with restriction LargeModifier
         {
         if
       (LargeModifier.RestrictionCollection(″Degree″).c
       ount>0)
            {
            …
            }
            …
            }
        }
    }
Doer约束表示作动作的实体，在构架上允许该约束。例如，“Bob openedthe file”或“the file was opened by Bob”都触发Doer约束。Doer约束包含表示实际doer的类型Entity的一个系统槽“who”。
通常，当命令使用构架时，Doer是计算机。但是，当构架被用作基于构架的约束时(例如“file opened by Bob”)，则doer的身份变得相关。作者可使用Doer约束来限制doer的类型。
所有的基本构架都可具有用asproperty定义的Doer约束，以允许在使用者位置处简化子类型化，如表131所例示。
                    表131：基本构架(open)
    frame open denoted by″open″behaves as
DefaultVerbClass
       {
       on resolve
       {
            with asproperty restriction Doer<who：＝
          Entity>；
       }
       }
//使用open构架但不限制Doer.who的类型
command OpenFileCommand uses open
{
}
entity FileEntity denoted by″file″
{
     on resolve
     {
          //将能够打开文件的实体限制到FileUserEntity
          with frame open<Doer.who：＝FileUserEntity>
          {
          }
     }
}
DoneTo约束表示动作所针对的实体。例如，“open the file”以及“the filewas opened”调用DoneTo约束。它包含表示动作的对象的类型Entity的一个系统槽what。
所有的基本构架都将具有用asproperty定义的DoneTo约束，以允许在使用者位置处简化子类型化，如表132所例示。
                       表132：基本构架Open
    //基本构架open
    frame open denoted by″open″behaves as
  DefaultVerbClass
    {
            on resolve
            {
                 with asproperty restriction Doer<who：＝
              Entity>；
                 with asproperty restriction DoneTo<who：＝
              Entity>；
            }
      }
      //定义使用open构架的命令，并将DoneTo.what限制到
      //FileEntity
      command OpenFileCommand uses open<DoneTo.what：＝
  FileEntity>
     {
     }
Goal约束对动作或改变的终点进行建模。Frames上允许Goal约束。一些例子包括“send mail to Bob”、“change password to XXX”。它具有表示终点的类型Entity的一个系统槽goal，如表133所示。
                  表133：″send mail to Bob″
frame MySendFrame：send<DoneTo.what：＝MailEntity>
{
     on resolve
     {
          with restriction Goal<goal：＝RecipientEntity>；
     }
}
Iteration约束对动作的重复进行建模，在Frames上允许该约束。例如，“print 3times”触发Iteration约束，如表134所示。
                      表134：Iteration约束
     //″print 3times″
     frame PrintFrame：print
     {
          int NumberOfIterations；
          on resolve
          {
               with restriction Iteration
               {
               NumberOfIterations＝Iteration.Number；
               }
          }
    }
Location约束对位于某处的语义进行建模。Frames和Entities上允许Location约束。例如，“mail in Inbox”、“file located on the desktop”、“searchthe web”都触发Location约束。它具有表示实际位置的类型Entity的一个系统槽loc，如表135所示。
                     表135：Location约束
frame SearchFrame：search//″search the web″
{
    on resolve
    {
    with restriction Location<loc：＝WebEntity>；
    }
}
Frames上允许Means约束，并且该约束在部分D中的LOM中详细讨论。Modifier约束允许出现在Frames、Entities和Restrictions上。Modifier约束表示形容词修饰语，诸如“large file”、“school bus”、“font that is red”以及“print slowly”。它具有表示形容词的类型Denoter的一个系统槽mod。对于名词-名词复合词，例如“MSN consumer application”，可以把它建模成：
对Entity(“application”)的Modifier(“MSN”)和Modifier(“consumer”)；
对Entity(“application”)的Modifier(“MSN consumer”)；
Modifier(“MSN”)和Entity(“consumer application”)；和/或
实体(“MSN consumer application”)
Named约束表示实体的名字。一些例子包括“Inbox folder”、“file namedfoo.txt”、“file with the name foo.txt”、“open foo.txt”、以及“the file foo.txt”。系统槽name是实际名字，如表136所示。
             表136：″file named foo.txt″
    entity FileEntity denoted by″file″
    {
         on resolve
         {
           with restriction Named<name：＝string>
         {
         //Named.name包含″foo.txt″
         }
         }
    }
主体上的Negation约束意味着主体被否定，并非表示其约束子句被否定。一些例子包括“don’t allow mail from Joe”以及“mail not from Joe”。表137示出具有negation的Frame的语法。
                表137：具有Negation的Frame
     //″look on the table″
     frame LookFrame：look
     {
          on resolve
          {
              with restriction Negation
              {
              //对″don′t look″建模
              }
          }
     }
     restriction NegatedLocation：Location<loc：＝
   TableEntity>
     {
          with restriction Negation
          {
          //对″not on the table″建模
          }
     }
如果话语具有否定，但是SPL代码不具有Negation约束子句，则该话语将解析失败。这与其它约束不同，对于其它约束的情况是如果不被创作则简单地忽略。
实体上不允许Negation约束。对于SPL，实体出现的“领域”(universe)取决于实体被如何使用，从而实体的否定没有必要。例如，在诸如“Displayeverything but the mail”之类的话语中，领域是应用程序能够显示的每样东西，并非必要地是应用程序所建模的任何实体。在话语“don′t allow mail from Bob”中，可允许或不允许的东西的领域可能仅限于mail，从而mail的否定在该上下文中不应有意义。出于该原因，实体否定将由实体的使用者使用“！”语法来处理。
Negation范围消除岐义性是由SPL代码来确定的。例如，“don’t look on thetable”能够具有下面的否定范围岐义：
Don’t look on the table(but sit on it instead)：否定作用于look构架；
Don’t look on the table(but look under it)：否定作用于Location约束；或
Don’t look on the table(but look on the chair)：否定作用于Location.loc实体
解析了哪个语义解释取决于代码如何被创建。实际上，根据创建的代码，所有这些读法都可成功解析，从而产生多个解释。运行时间通常优先考虑范围岐义，从而多个解析被分级。表138对否定建模。
                     表138：Negation范围
        //否定作用于″Look″
        //″don’t look on the table(but sit on it)″
        frame LookFrame：look
        {
             on resolve
             {
                   with restriction Negation；
                   with restriction Location<loc：＝
                 TableEntity>；
             }
        }
       //对作用于Location的否定建模
       //″don’t look on the table(but look under it)″
       frame LookFrame：look
       {
            on resolve
            {
                 with restriction NegatedLocation<loc：＝
              TableEntity>；
            }
       }
       //对作用于Location.loc实体的否定建模--″don’t look on
     the table(but look on the chair)″
       frame LookFrame：look
       {
            on resolve
            {
                with                      restriction
            Location<loc：＝！TableEntity>；
         }
    }
“！”(NOT)语法也能够运用于构架和约束，作为简写概念，如表139所示。
                        表139
    //下面的对look的否定是等价的。第一个不允许作者插入强制性
  代码来处理否定，而第二个却可以(即在LookFrame的Negation子
  句)
    command NegatedLook uses！look；
    frame LookFrame：look
    {
         on resolve
         {
              with obligatory restriction Negation；
         }
    }
    command NegatedLook2 uses LookFrame；
    restriction NegatedLocation ：Location<loc：＝
  TableEntity>
    {
        on resolve
        {
            with obligatory restriction Negation；
        }
    }
    //类似地，下面的否定的Location是等价的，除了在Negation
  子句中具有代码的能力之外
    frame LookFrame：look
    {
         on resolve
         {
               with restriction！Location<loc：＝
            TableEntity>；
               with restriction NegatedLocation；
         }
    }
Ordinal约束对序数数字和表示序列中的某一位置概念的诸如previous之类的其它修饰语进行建模。一些例子包括“first file”、“third book”和“lastemail”。Ordinal约束也可运用于其它约束，例如“first 3 books”，它被建模成Ordinal(“first”)约束修饰Cardinal(“3”)约束，如表140所示。
                         表140：Ordinal约束
        //对″first 3″建模
        restriction OrdinalCardinal：Cardinal
        {
             int Position；
             on resolve
             {
                 with obligatory restriction Ordinal
                 {
                      Position＝Ordinal.distance；
                 }
             }
        }
        entity FileEntity denoted by″file″
        {
             on resolve
             {
                 //″first file″
                 with restriction Ordinal；
             }
        }
Possessor约束对实体的所有者进行建模，它运用于实体。一些例子包括“mybook”以及“Bob’s book”。类型Entity的系统槽owner表示实体的所有者。如果清晰地表达出所有者，例如在“Bob’s book”中，则将相对于owner槽来解析“Bob”。如果所有者是代名词，例如在“her file”中，则运行时间将试图通过首语主重复(anaphora)解析来解析该代名词。如果该首语主重复解析不能找到所有者实体，则owner槽将为空。表141示出了Possessor约束的语法。
                      表141：Possessor约束
     entity FileEntity denoted by″file″
     {
          on resolve
          {
               withrestriction Possessor<owner：＝Entity>；
          }
     }
实体上允许Quantifier约束，该约束对数量表达式进行建模。一些例子包括“all files”、“a few books”以及“one third of the page”。下面是quantifier类型：
      All：all((of)the)，every，each(of the)
      None：no，none(of the)
      Some：some(of the)
      Most：most(of the)，the majority of
      Many：many(of the)
      Few：few(of the)，not many(of the)
      Percentage：a hal f of，1/3 of，40％ of
在某些实施例中，在Quantifier和Cardinal之间可能存在层次关系。
      SortOrder约束对排序的形式进行建模。一些例子是“sort in
      alphabetical order”以及“display in reverse order
      by name”。该约束已在上文中关于表56详细讨论过了。
Time约束对实际时间表达式进行建模，也就是说能够被转换成时间点和/或时间跨度的时间表达式。例子包括“delete after 3 days”、“mail fromyesterday”和“schedule for tomorrow from 1-3pm”。Time约束在先前的部分D中已经讨论过了。
Topic约束对主题物进行建模。一些例子包括“book about dogs”、“bookregarding dogs”和“book with the subject dogs”。它具有表示topic串的类型string的一个系统槽topic。该约束在先前的部分D中已经详细讨论过。表142示出了具有Topic的BookEntity代码块。
                  表142：BookEntity.
     //book about dogs
     entity BookEntity denoted by″book″
     {
         on resolve
         {
              with restriction Topic<topic：＝string>
              {
              //topic将包含topic串″dogs″
              }
         }
     }
Conjunction(“and”)和Disjunction(“or”)可发生于命令、实体和约束。Conjunction和Disjunction落于Coordination标题内。一般地，协调中的岐义来自于实体和修饰语如何分布在逻辑与和逻辑或上，以及来自于用多个“and”和“or”操作符来对话语中的岐义加括号。类似于Negation，这种岐义消除是由创作的代码来确定的。例如，就话语“find mail and notes created yesterday”，SPL作者可将其建模成：
       a.(Find(mail created yesterday)AND(notes created yesterday)).
       b.(Find(mail)AND(notes created yesterday)).
       c.(Find(mail created yesterday))AND(Find(notes created
         yesterday)).
       d.(Find(mail))AND(Find(notes created yesterday)).
“created yesterday”和“find”是如何与其实体“mail”和“notes”一起分布的，这是由创作的SPL代码来确定的。为了说明的目的，假设作者编写了仅理解类型MailEntity的实体的FindMailCommand和仅理解类型NoteEntity的实体的FindNotesEntity。此外，创作的代码指出MailEntity不具有创建时间的概念，但是NotesEntity却具有，如表143所示。
                      表143：Coordination.
command FindMail Command uses find<DoneTo.what：＝MailEntity>；
command FindNotesCommand uses find<DoneTo.what：＝NotesEntity>；
entity MailEntity denoted by″mail″
{
}
entity NotesEntity denoted by″notes″
{
     on resolve
     {
          with  frame  CreateNotesFrame；
     }
}
frame CreateNotesFrame：create<DoneTo.what：＝NotesEntity>
{
          on resolve
          {
              with restriction Time；
          }
    }
利用该创作的代码，对于话语“find mail and notes created yesterday”来说，语义分析仅从上面的列表中产生读法(d)(“Find(mail)and find(notes createdyesterday)”)。SPL作者不需要理解所有的可能性。作者能够只按照他们的应用程序的语义来考虑(例如，MailEntity不理解创建时间，而NotesEntity理解)。
协调的实体被表示为利用“and”或“or”协调类型链接在一起的一列实体。列表中的所有实体必须用相同的协调类型链接在一起。此外，列表中的所有实体必须是相同的编程类型(例如全部为MailEntity元素)。
作为一般的规则，运行时间不会产生多个解析来对相同类型的协调产生的岐义加括号进行建模。相反，用相同类型的协调(即全部用“and”或全部用“or”)协调在一起的实体被建模成平坦列表，留给应用程序来确定合适的加括号(如有必要)。例如，采用话语“find mail and books and files”。这可以意味着“findmail and(books and files)”或“find(mail and books)and files”。假设所有的实体都是相同的SPL类型，这种加括号岐义不被建模，意味着仅将产生一个可能的读法。该话语被建模成平台列表，其中元素的顺序反映出话语中的顺序。
然而，利用混合的“and”和“or”，运行时间产生多个读法来对加括号岐义进行建模。根据创作的代码，这些多个读法可能或可能不导致多个解析出的解释。就话语“find mail or books and files”而言，由于元素的列表必须用相同的协调类型来协调，下面的运行时间产生下面的可能的读法(假设“mail”、“books”和“files”被解析成相同的SPL类型，并且假设Find命令采用列表)：
(Find(mail OR books))AND(Find(files))
(Find(mail))OR(Find(books AND files))
“find”分布在“and”和“or”上。
一般地，混合的“and”和“or”操作符在话语中不常见，从而产生多个解释来对加括号岐义进行建模不应太麻烦。
在某些配置中，可能有必要实现Entity列表，可由实体的使用者使用[]语法来规定，如表144所示。
                     表144：Entity列表
     command FindMailCommand uses find<DoneTo.what：＝
  [MailEntity]>；
    entity MailEntity denoted by″mail″
    {
          on resolve
          {
               with restriction Location<loc：＝
            [MailFolder]>；
          }
    }
解释表示话语相对于SPL程序的解析出的解释。每个解析出的解释包含至少一个解析出的命令。话语可导致多个命令用于解释。例如，“find file foo.txtand print it，在该话语中存在两个命令。解释中的命令利用某种条件而链接在一起。当前，它们通过协调类型AND或OR来链接在一起的(其它建模条件也是可能的)。解释中的命令无需是相同的解析出的类型。
下面的讨论检验了各种协调例子，以示出元素如何分布在逻辑与和逻辑或上，以及创作的代码如何对协调进行建模。该讨论还检验了用于命令、实体和约束的协调。对于一给定的话语，示出可能的读法来说明岐义和分布。
为了重申，SPL作者考虑他们的应用程序的语义(例如my Find command可在一列MailEntity上操作)。运行时间试图根据其对元素在逻辑与和逻辑或上的分布的规则的语言理解来将话语映射到所创作的东西。表145中的代码样例用于下面给出的例子。
                         表145：示例代码
     command OpenMail Command uses open<DoneTo.what：＝
  MailEntity>；
     command OpenFileCommand uses open<DoneTo.what：＝
  FileEntity>；
     command ReplyMailCommand uses reply<DoneTo.what：＝
  MailEntity>；
     command CreateMailCommand uses create<DoneTo.what：＝
  MailEntity>；
     entity MailEntity denoted by″mail″：ItemEntity
     {
          on resolve
     {
     with restriction Source<src：＝SenderEntity>；
     with restriction Location<loc：＝MailFolder>；
     }
}
entity NotesEntity denoted by″notes″：ItemEntity；
entity JournalEntity denoted by″journal items″：ItemEntity；
entity FileEntity denoted by″file″；
//该实体在这里用于CreatedItemsFrame上的多态性
entity ItemEntity
{
     on resolve
     {
          with                          restriction
       CreatedItemsFrame<DoneTo.what：＝this>；
     }
}
//对″created yesterday″建模
frame CreatedItemsFrame：create<DoneTo.what：＝ItemEntity>
{
    on resolve
    {
          with restriction Time；
    }}
上述的代码如下解析命令“Find mail from Bob and delete them”：
FindMailCommand<MailEntity1(“mail from Bob”)>AND
DeleteMailCommand<MailEntity1>
命令“Find and/or delete mail from Bob”被解析成具有四个解释，如下：
解释1：″mail from Bob″分布在“and”/“or”上。
      FindMailCommand<MailEntity1(″mail from Bob″)>
  AND/OR
      DeleteMailCommand<MailEntity1>
解释2：″mail from Bob″不分布在“and”/“or”上。
         FindMailCommand<MailEntity1(empty)>AND/OR
         DeleteMailCommand<MailEntity2(″mail from Bob″)>
    解释3：″mail from Bob″不分布在“and”/“or”上。该解释
  得自创作的代码，而非得自协调岐义。由于存在3个“find”命令，并
  且“empty”实体是有效的实体，一个赤裸的“find”能够解析到这些
  命令中的任一个。
         FindNotesCommand<NotesEntity1(empty)>AND/OR
         DeleteMailCommand<MailEntity1(″mail from Bob″)>
    解释4：与解释3相同
         FindJournalCommand<JournalEntity1(empty)>
      AND/OR
         DeleteMailCommand<MailEntity1(″mail from Bob″)>
相对于上述创作的代码来说，上面列出的所有解释都是可能的。
相对于上面创作的代码来解析命令“Find mail from Bob and/or delete”，并且导致两个可能的解释，如下：
    解释1：″mail from Bob″分布在“and”/“or”上
         FindMailCommand<MailEntity1(″mail from Bob″)>
      AND/OR
         DeleteMailCommand<MailEntity1>
    解释2：″mail from Bob″不分布在“and”/“or”上
         FindMailCommand<MailEntity1(″mail from Bob″)>
      AND/OR
         DeleteMailCommand<MailEntity2(empty)>
该例子中的短语与前一例子中的短语之间的唯一差别在于命令“delete”，它具有空的MailEntity。对于上面创作的代码来说，两种解释都是可能的。
相对于代码解析命令“Open file and reply or create mail”，导致下列可能的解释
    解释1：″mail″分布在“or”上，以依附于“reply”
          OpenFileCommand<Entityl(″file″)>AND
          ReplyMailCommand<Entity2(″mail″)>OR
          CreateMailCommand<Entity2>
    Interpretation 2：实体无分布
          OpenFileCommand<FileEntity1(″file″)>AND
          ReplyMailCommand<MailEntity1(empty)>OR
          CreateMailCommand<MailEntity2(″mail″)>
    Interpretation 3：″file″分布在“and”上以依附于“reply”。
相对于上述创作的代码，该读法将不被解析，因为不存在采用
          FileEntity的“reply”命令。
          OpenFileCommand<FileEntity1(″file″)>AND
          ReplyMailCommand<FileEntity1>OR
          CreateMailCommand<MailEntity1(″mail″)>
命令“Open file or reply and create mail”导致三个可能的解释，如下：
    解释1：″file″分布在“or”上以依附于“reply”。相对于上述
创作的代码，该读法将不被解析，因为不存在采用FileEntity的
“reply”命令。
          OpenFileCommand<FileEntity1(″file″)>OR
          ReplyMailCommand<FileEntity1>AND
          CreateMailCommand<MailEntity1(″mail″)>
    解释2：″mail″分布在“and”上以依附于“rely”
          OpenFileCommand<Entityl(″file″)>OR
          ReplyMailCommand<Entity2(″mail″)>AND
          CreateMailCommand<Entity2>
    解释3：实体无分布
          OpenFileCommand<FileEntity1(″file″)>OR
          ReplyMailCommand<MailEntity1(empty)>AND
          CreateMailCommand<MailEntity2(″mail″)>
一般地，由SPL的语义来暗示用于约束的“and”。例如，命令“find mailfrom Bob and in Inbox”引起在MailEntity上激发两个约束，Source约束和Location约束。因此，下面的讨论检验用于约束的逻辑或(disjunction)。
除了上面的代码之外，我们将使用下面的一行代码添加理解MailEntity列表的FindMailListCommand。
    command FindMailListCommand uses find<DoneTo.what：＝
 [MailEntity]>；
命令“find mail from Bob or created yesterday”解析成下面的解释：
    解释1：″mail″分布在″or″上。这导致一列MailEntity。
          FindMailListCommand<[
          MailEntity1(″mail from Bob″)ORMailEntity2(″mail created yesterday″)]>
如果FindMailListCommand不存在或不成功解析，则“find”将分布在实体上以建立两个FindMailCommands：
     FindMailCommand<MailEntity1(″mail from Bob″)>OR
     FindMailCommand<MailEntity2(″mail created
   yesterday″)>
命令“find mail from Bob or created yesterday and in Inbox”如下解释：
解释1：对(mail from Bob or created yesterday)加括号，
“in Inbox”分布于括号上，即分布于“or”上。
        FindMailListCommand<[
        MailEntity1(″mail from Bob and in Inbox″)OR
        MailEntity2(″mail created yesterday and in
      Inbox″)]>
同样，如果FindMailListCommand不存在或不成功解析，
则“find”将分布在实体上以建立两个FindMailCommands。
解释2：对(mail created yesterday and in Inbox)加括号。因为″mail from Bob″与逻辑或连接，就不存在它在括号上的分布。
      FindMailListCommand<[
      MailEntity1(″mail from Bob″)OR
      MailEntity2(″mail created yesterday and in
    Inbox″)]>
      同样，如果FindMailListCommand不存在或不成功解析，
    则“find”将分布在实体上以建立两个FindMailCommands。
解释3：修饰语不加括号，“mail”分布在所有的修饰语上。
      FindMailListCommand<[
      MailEntity1(″mail from Bob″)OR
      MailEntity2(″mail created yesterday″)AND
      MailEntity3(″in Inbox″)]>
      同样，如果FindMailListCommand不存在或不成功解析，
    则“find”将分布在实体上以建立两个FindMailCommands。
除了上面的命令之外，添加一般的FindCommand，能够发现邮件、笔记、日记项的列表。FindCommand示于表146。
                   表146：FindCommand.
    command FindCommand uses find<DoneTo.what：＝
  [GeneralEntity]>；
    entity GeneralEntity denoted by″mail″，″notes″，
  ″journal items″：ItemEntity
    {
         on resolve
         {
              with restriction Source<src：＝
            SenderEntity>；
         }
    }
添加该命令确实增加了解释的数量，从下面的例子中可看出。
命令“Find mail and/or notes created yesterday”导致下面的解释。
    解释1：″created yesterday″分布在″and″/″or″上。
          FindCommand<[
          GeneralEntity1(″mail created yesterday″)AND/OR
          GeneralEntity2(″notes created yesterday″)]>
    解释2：″created yesterday″无分布.
          FindCommand<[
          GeneralEntity1(″mail″)AND/OR
          GeneralEntity2(″notes created yesterday″)]>
          如果FindCommand不存在或不成功解析，则“find”将分布
        在逻辑与上，给出下面两个解释：
    解释3：与1相同，但是″find″分布在实体上
          FindMailCommand<MailEntity1(″mail created
        yesterday″)>AND/OR
          FindNotesCommand<NotesEntity1(″notes created
        yesterday″)>
    解释4：与2相同，但是但是″find″分布在实体上
          FindMailCommand<MailEntity1(″mail″)>AND/OR
          FindNotesCommand<NotesEntity1(″notes created
        yesterday″)>
命令“Find mail from Bob and/or notes created yesterday”导致下面的可能的解释。
    解释1：不同于例子1，修饰语无分布。
         FindCommand<[
         GeneralEntity1(″mail from Bob″)AND/OR
         GeneralEntity2(″notes created yesterday″)]>
    解释2：如果FindCommand不解析，则我们获得″find″在实体上的
  分布。
         FindMailCommand<MailEntity1(″mail from Bob″)>
       AND/OR
         FindNotesCommand<NotesEntity1(″notes created
       yesterday″)>
命令“Find mail，notes，or journal items created yesterday”导致下面的可能的解释。
    解释1：″created yesterday″分布在″mail″、″notes″、以及
  ″journal items″上。
          FindCommand<[
          GeneralEntity1(″mail created yesterday″)OR
          GeneralEntity2(″notes created yesterday″)OR
          GeneralEntity3(″journal items created
        yesterday″)]>
    解释2：修饰语无分布
          FindCommand<[
          GeneralEntity1(″mail″)OR
          GeneralEntity2(″notes″)OR
          GeneralEntity3(″journal items created
        yesterday″)]>
如果FindCommand不存在或不成功解析，则“find”将分布在逻辑与上，导致下面两个额外的解释。
    解释3：与1相同，但是″find″分布在实体上
          FindMailCommand<MailEntity1(″mail created
        yesterday″)>OR
          FindNotesCommand<NotesEntity1(″notes created
        yesterday″)>OR
          FindJournalCommand<JournalEntity1(″j ournal
        items created yesterday″)>
    解释4：与2相同，但是″find″分布在实体上
          FindMailCommand<MailEntity1(″mail″)>OR
          FindNotesCommand<NotesEntity1(″notes″)>OR
          FindJournalCommand<JournalEntity1(″journal
        items created yesterday″)>
命令“Find mail and notes orjournal items created yesterday”导致加括号的问题。由于混合的逻辑与类型(即话语中既存在“and”也存在“or”)以及既采用实体列表也采用单独实体的“find”命令的存在，就可能存在许多解释。因此，较佳的是不具有采用某一实体的列表的命令以及采用该单独实体的命令。创建代码以便生成尽可能多的解释。
    解释集1：″created yesterday″无分布
          对″mail″和″notes加括号
            FindCommand<[GeneralEntity1(″mail″)AND
            GeneralEntity2(″notes″)]>OR
            FindJournalCommand<JournalEntity1(″journal
            items created yesterday″>
在该情况中，还可能有必要产生FindCommand采用FindJournalCommand的位置中的任一元素的解释。
            对″notes″和″journal items″加括号
               FindMailCommand<MailEntity(″mail″)>AND
               FindCommand<[
               GeneralEntity1(″notes″)OR
               GeneralEntity2(″journal items created
               yesterday″)]>
             无加括号
               FindMailCommand<MailEntity(″mail″)>AND
               FindNotesCommand<NotesEntity(″notes″)>
               ORFindJournalCommand<JournalEntity(″journal
               items created yesterday″)>
    解释集2：″created yesterday″分布在″or″上以依附于
  ″notes″
        对″mail″和″notes加括号
          FindCommand<[
          GeneralEntity1(″mail″)AND
          GeneralEntity2(″notes created yesterday″)]>OR
          FindJournalCommand<JournalEntity1(″journal
          items created yesterday″>
        对″notes″和″journal items″加括号
          FindMailCommand<MailEntity(″mail″)>AND
          FindCommand<[
          GeneralEntity1(″notes created yesterday″)OR
          GeneralEntity2(″journal items created
          yesterday″)]>
        无加括号
          FindMailCommand<MailEntity(″mail″)>AND
          FindNotesCommand<NotesEntity(″notes created
          yesterday″)>OR
          FindJournalCommand<JournalEntity(″journal
          items created yesterday″)>
    解释集3：″created yesterday″分布在所有实体上
        对″mail″和″notes加括号
          FindCommand<[
          GeneralEntity1(″mail created yesterday″)AND
          GeneralEntity2(″notes created yesterday″)]>OR
          FindJournalCommand<JournalEntity1(″journal
          items created yesterday″>
        对″notes″和″journal items″加括号
          FindMailCommand<MailEntity(″mail created
          yesterday″)>AND
          FindCommand<[
          GeneralEntity1(″notes created yesterday″)OR
          GeneralEntity2(″journal items created
          yesterday″)]>
        无加括号
          FindMailCommand<MailEntity(″mail created
            yesterday″)>AND
            FindNotesCommand<NotesEnt ity(″notes created
            yesterday″)>OR
            FindJournalCommand<JournalEntity(″journal
            items created yesterday″)>
在某些情况下，可能希望允许开发者规定他自己的各种语言现象到约束的映射。还可能希望提供“预分析”编程，其中模式影响激发什么约束，这与Default中的“后处理”编程相对。一般地，希望允许某一范围的模式，从基于串的到基于语言的。
在一个实施例中，提供一种一般的机制用于规定由LOM开发者内部使用和由SPL开发者外部使用的模式。应允许外部开发者使用一定范围的模式，从简单到复杂。
在一个实施例中，如表147所示，运用模式将类似于使用C#属性。
                     表147：运用模式
     entity FlightEntity
     {
         [MyPattern(″departing from″)]
         with restriction Source<src：＝City>
         {
         }
     }
一般地，本发明意图尽可能的开放，允许开发者创建他们自己的模式，这可能与任何预定的集合无关。这允许开发者绕过形式化的语义关系(即约束类型)，并创建他们自己所需的。
就对条件进行建模而言，在某些实施例中，对条件命令进行建模可能是非常有价值的。一些例子包括“ifBob sends me mail，delete it”、“page me whenmail comes from Bob”、“move the file to c：\docs after copy it”以及“warn mebefore permanently deleting a message”。一般地，对此进行建模的机制应该类似于协调的命令的机制。在可选的实施例中，可通过特殊的约束类型来呈现条件。
在某些实施例中，作者可能希望推出约束子句中的多个约束，以便提供更窄范围的解释。作者可通过将数据存储于约束子句中并在success子句中推出它来模拟AND推理，虽然这并不好。作者可通过调出公共函数来模拟OR特性推理。
在较佳实施例中，允许作用使用强制性代码(例如调用数据库)来规定一列指示(denotation)。可根据特定的实现方式和根据所涉及的数据库来改变这一概念。
一般地，Named约束按照串向作者提供名字。在一个实施例中，作者可以创建名字类，运行时间可对它在给定的话语中识别出的名字列表询问该名字类。例如，考虑短语“find Gone with The Wind movie”，作者能够创建能把“Gonewith the wind”识别为电影的名字的名字类。在一个实施例中，可向SPL提供Named约束的过载，它采用名字类类型，如表148所示。
                表148：过载的Name约束
   name MovieNames
   {
       //运行时间能够调用来获得给定的话语中识别出的名字的列表
       NameList FindRecognizedNames(string Utterance)；
   }
   entity MovieEntity denoted by″movie″
   {
       on resolve
       {
       with restriction Named<name：＝MovieNames>；
       }
   }
在较佳实施例中，NamedEntity类型与NamedEntityRecognizer类相关联，如下：
NamedEntity MovieName uses MoveNameRecognizer；
class MovieNameRecognizer：NamedEntityRecognizer
{
     public override void Recognize(string input，/*other
     arguments*/)
     {
         //识别“input”中的电影的题目的实例
     }
   }
在较佳实施例中，允许开发者规定要如何处理未知的/未创作的命令(如名词短语)。作者可对应用程序编写代码来在适当的位置处理它们，或要求运行时间为特定的实体调用某一命令(或一组命令)，或提供默认的命令处理程序。
在一个实施例中，允许衍生出的类调用基本类的约束子句，如表149所示。
           表149：衍生出的类调用基本类的约束子句
    entity Entity1
    {
         with restriction Location<loc：＝SomeEntity>
         {
         }
     }
     entity Entity2：Entity1
     {
         /*我们希望对Entity1不处理的所有位置类型提供处理，但
       对于SomeEntity的位置则转到Entity1。如果我们进行下面的，
       Entity1：：Location将不会获得调用，因为该子句将在
       Entity1的子句之前被尝试。*/
         with restriction Location<loc：＝Entity>
         {
           //进行处理
         }
     }
直接启用(invocation)可能不是所希望的，因为子句的解析大部分是由运行时间控制的。引入public/private/protected/以及其它约束子句，以及试图计算出每个对于解析语义意味着什么，这将添加不必要的复杂性。相反，可添加某些限制(如更多的说明性限制)，告诉解释器如果基本子句成功，则在调用其自己的子句之前调用基本约束子句。编译器可强制具有基本类中的确切的槽类型的子句的存在，如表150所示。
                           表150
     entity Entity2：Entity1
     {
          with invokebase restriction Location<loc：＝
       SomeEntity>
          {
          }
          with restriction Location<loc：＝Entity>
          {
          }
     }
invokebase的语义是基本类的约束子句(说明性的和强制性的约束)必须在以invokebase修饰的子句被调用之前获得成功。如果希望改变语义(即在基本类之前调用衍生出的类)，则应使用其它语法。“with”子句语法意味着子句规定的限制必须在依附于该子句的代码被执行之前得到满足。
某些动词使Goal和Location互换。例如，“print to my printer”的含义与“print on my printer”相同。根据位置在语法上是如何实现的(即“to”对“on”)，作者不应该必须对两种不同的约束编写代码。两种约束都可以呈现给这些动词，这取决于创作了什么。然而，在某些情况下，可能更容易的是向作者解释“to”将总被实现为Goal，而并不考虑试图为某些动词解释Goal可能是Location，而为另一些动词解释Goal不能是Location。
重要的是要理解抽象类型不能被实例化(即不能被直接解析)，但是它们有助于多态性和保持公共功能。
如果作者已经为“send mail to Bob”编写了命令，那么即使在话语中没有“mail”，“send to Bob”也应当相对于该命令而解析。在某些实施例中，这种功能是令人希望的。如果默认方式允许空实体并把空实体作为有效来对待，作者可在实体的success子句处编写代码来拒绝空实体。如果默认方式不允许空实体(即如果在话语中不存在有实体的证据，那么它将不被解析)，则可引入槽限定符(qualifier)(诸如“任选的”)，允许命令接受空实体。在较佳实施例中，可能不存在包含MailEntity的约束，如果作者注意检查这种情况，则构架或命令将明确地使解析失败。
虽然已经参考特定的实施例描述了本发明，但是本领域的技术人员将认识到不用背离本发明的要旨和范围就可在形式上和细节上作出许多改变。
附录I-场景：Microsoft Outlook原型
在该实施例中，启用Microsoft Outlook，使用SPL和LOM用于文本和语音输入。多数的启用都是由夏天的实习生进行的，他不具有语言知识或训练。SPL代码设计成编译于并运行于Microsoft.Net平台上，该代码通过Outlook2002对象模型和CDO(协作数据对象)Microsoft Outlook交互，以进行绑定和执行命令。
启用了一些高级搜索，这些高级搜索推出不同的数据源。一些例子包括下面的场景：
  “search for mail that was sent by people on Conference Group”其中我
们推出分布列表；
  “show mail from my contacts”其中我们推出联系人文件夹中的人；以及
  “find mail from my direct reports”其中我们推出组织机构图。
此外，系统还进行首语重复法解析。例如，“show me David′s manager”后跟“send mail to him”向开发者区分出“him”指代“David’s manager”。
此外，系统进行如下的高级推理和建模：
  “send mail to everyone on nlgcore except David Bradlee”其中我们推出
否定；以及
  “schedule a meeting every Tuesday with my manager at 2:00 for 1hour”
其中我们相对于复合时间表达式进行建模和编程。
附录II：Microsoft Outlook代码预演
下面的讨论从开发者的观点来分析命令。该讨论模拟出开发者在他/她调试该代码时看到了什么。命令是“send mail about package to Seattle group”。该句子具有两个可能的含义：
1.“send mail about package to seattle group”其中mail的主语是“package to seattle group”。
2.“ send mail about package  to seattle group”其中mail的主语是“package”，“send”的目的(即，向何处发送邮件)是“seattle group”。
根据域知识，这些解释中的一个或全部将位于最终的解释列表中。
下面是完整的代码。SPL关键字或保留的单词以粗体表示。当通过步骤分析进行时，代码片段将被省去。
    command SendMailCommand uses SendMailFrame
    {
        on resolve
        {
            on begin
            {
                return Outlook.IsInSendMailContext()；
            }
            on success
            {
                Outlook.SendMail(SendMailFrame.Mail，SendMailFrame.Targets)；
            }
            on failure
            {
                 //do whatever cleanup is necessary
            }
        }
    }
    frame SendMailFrame：send
    {
        public string[] Targets；
        public MailEntity Mail；
        on resolve
        {
            with restriction DoneTo<what：＝MailEntity>
            {
                  Mail＝DoneTo.what.MailEntity；
            }
            with restriction Goal<goal：＝DLEntity>
            {
                 Targets＝Goal.goal.DLEntity.People；
            }
        }
    }
    entity MailEntity denoted by MailEntityWords
    {
          public string MailSubject；
          on resolve
          {
               with restriction Topic<topic：＝string>
               {
                     MailSubject＝Topic.topic.Phrase.topic；
               }
        }
    }
    entity DLEntity denoted by DLEntityWords
    {
         public string[] People；
         with restriction Named<name：＝Entity>
         {
               People＝Outlook.GetDLMembers(Named.name.Phrase.text)；
               if(People＝＝null)
               {
                    return false；
               }
        }
    }
    denote MailEntityWords
    {
        English：＝noun(″mail″)，noun(″email″)，noun(″electronic mail″)，noun(″e-mail″)；
        French：＝noun(″mail″)，noun(″email″)，noun(″courriel″)，noun(″message électronique″)；
}
denote DLEntityWords
{
    English：＝noun(″distribution list″)，noun(″list″)，noun(″group″)，noun(″disc″)，noun(″discussiongroup″)；
    French：＝noun(″liste de distribution″)，noun(″dl″)；
}
解释1
再次参考该命令，第一个解释是mail的主语是“package to seattle group”，如下：
“send mail about package to seattle group”
获得调用的第一个对象是SendMailCommand的“on resolve”子句的“on begin”子句。
    “send mail about package to seattle group”
    command SendMailCommand uses SendMailFrame
    {
        on resolve
        {
            on begin
            {
                 return Outlook.IsInSendMailContext()；
            }
            on success
            {
                Outlook.SendMail(SendMailFrame.Mail，SendMailFrame.Targets)；
            }
            on failure
            {
                //do whatever cleanup is necessary
            }
        }
    }
调用用于该命令的构造函数，执行子句中的代码。如果子句返回“false”，则对该命令的进一步分析停止。在该情况下，如果SendMailContext()返回false(即应用程序当前不处于用于发送邮件的上下文环境中)，则分析停止。
假设应用程序能够发送邮件，SPL解释器继续其分析。获得调用的下一个对象是SendMailFrame，因为SendMailCommands说它使用SendMailFrame。解释器直到该短语中的单词“send”映射到SendMailFrame。
     “send mail about package to seattle group”
     frame SendMailFrame：send
     {
         public string[] Targets；
         public MailEntity Mail；
         on resolve
   {
        with restriction DoneTo<what：＝MailEntity>
        {
        Mail＝DoneTo.what.MailEntity；
        }
        with restriction Goal<goal：＝DLEntity>
        {
               Targets＝Goal.goal.DLEntity.People；
        }
     }
  }
对于SendMailFrame来说，没有构造函数，因此调用默认的构造函数。默认的构造函数总能成功。解释器继续解析对“send”的约束。要被调用的第一个约束是“DoneTo”约束，它表示“send”的对象，在该例中为“mail”。
      “send mail about package to seattle group”
      frame SendMailFrame：send
      {
          public string[] Targets；
          public MailEntity Mail；
          on resolve
          {
              with restriction DoneTo<what：＝MailEntity>
              {
                    Mail＝DoneTo.what.MailEntity；
              }
              with restriction Goal<goal：＝DLEntity>
              {
                    Targets＝Goal.goal.DLEntity.People；
              }
         }
   }
根据该代码，DoneTo的槽(指示出域特定的类型)是MailEntity。换言之，“send”的对象需要是MailEntity。解释器然后试图解析MailEntity：
     entity MailEntity denoted by MailEntityWords
     {
          public string MailSubject；
          on resolve
          {
              with restriction Topic<topic：＝string>
              {
                   MailSubject＝Topic.topic.Phrase.topic；
              }
          }
     }
如同其它对象一样，解释器调用构造函数。由于没有构造函数，则调用默认的构造函数，默认的构造函数将成功。
实体具有的概念是由一列单词表示。在该情况下，解释器通过查看MailEntityWords的英语列表来检查“mail”是否是用于MailEntity的标志牌：
     “send mail about package to seattle group”
    denote MailEntityWords
    {
        English：＝noun(″mail″)，noun(″email″)，noun(″electronic mail″)，noun(″e-mail″)；
        French：＝noun(″mail″)，noun(″email″)，noun(″courriel″)，noun(″message éíectronique″)；
    }
这是语言特定的细节被编码的地方。解释器看到“mail”在列表中。
接着，解释器试图相对于MailEntity中编码了什么来解析“mail”上的约束。在该情况下，“about package to seattle group”是Topic约束，其中实际的topic是“package to seattle group”：
    “send mail about package to seattle group”
    entity MailEntity denoted by MailEntityWords
    {
        public string MailSubject；
        on resolve
        {
            with restriction Topic<topic：＝string>
            {
                MailSubject＝Topic.topic.Phrase.topic；
            }
        }
    }
解释器试图相对于Topic约束的槽来解析实际的题目。“topic”槽是一个串，从而不需要解析。Topic子句中的代码被执行。
    “send mail about package to seattle group”
    entity MailEntity denoted by MailEntityWords
    {
         public string MailSubject；
         on resolve
         {
              with restriction Topic<topic：＝string>
              {
                   MailSubject＝Topic.topic.Phrase.topic；
              }
         }
     }
代码将topic的文本存储于成员变量MailSubject中。通过语言对象模型(LOM)来检索topic的实际文本。解释器现在正在处理MailEntity对象。它为MailEntity调用默认的success析构函数，因为并未编码一个析构函数。
控制流返回到SendMailFrame，其中代码在DoneTo子句中执行：
      frame SendMailFrame：send
      {
          public string[] Targets；
          public MailEntity Mail；
          on resolve
          {
               with restriction DoneTo<what：＝MailEntity>
               {
                   Mail＝DoneTo.what.MailEntity；
                }
                with restriction Goal<goal：＝DLEntity>
                {
                     Targets＝Goal.goal.DLEntity.People；
                }
         }
    }
该代码仅仅将MailEntity对象存储于成员变量中。{注意：这是第二个解释(下面讨论)开始的地方}。解释器进行解析SendMailFrame对象，并调用默认的success析构函数，因为未提供一个析构函数。
控制流返回到SendMailCommand。此时，解释器进行解析完整的命令。调用SendMailCommand的success析构函数。
     command SendMailCommand uses SendMailFrame
     {
          on resolve
          {
               on begin
               {
                   return Outlook.IsInSendMail Context()；
               }
               on success
               {
                   Outlook.SendMail(SendMailFrame.Mail，SendMailFrame.Targets)；
               }
               on failure
               {
                  //do whatever cleanup is necessary
               }
           }
      }
该代码被执行，并且SendMailCommand对象返回给应用程序。
解释2
现在参考第二个可能的解释：
“ send mail about package  to seattle group”
用于“send mail about package”的解析步骤直到标记点为止都与上述相同，除了topic是“package”而不是“package to seattle group”之外。
解释器知道“to seattle group”是“send”上的Goal约束。
     “send mail about package to seattle group”
     frame SendMailFrame：send
     {
          public string[] Targets；
          public MailEntity Mail；
          on resolve
          {
              with restriction DoneTo<what：＝MailEntity>
              {
                   Mail＝DoneTo.what.MailEntity；
              }
              with restriction Goal<goal：＝DLEntity>
              {
                    Targets＝Goal.goal.DLEntity.People；
              }
          }
     }
该代表说了实际的目标需要是DLEntity，从而解释器试图相对于DLEntity来解析“seattle group”
   “send mail about package to seattle group”
   entity DLEntity denoted by DLEntityWords
   {
        pubilc string[] People；
        with restriction Named<name：＝string>
        {
             People＝Outlook.GetDLMembers(Named.name)；
             if(People＝＝null)
             {
                   return false；
             }
        }
   }
解释器知道“group”应当是DLEntity的标志牌。它检查标志牌列表DLEntityWords：
    denote DLEntityWords
    {
         English：＝noun(″distribution list″)，noun(″list″)，noun(″group″)，noun(″disc″)，noun(″discussion
group″)；
         French：＝noun(″liste de distribution″)，noun(″dl″)；
    }
发现了匹配。解释器然后试图相对于Named约束子句来解析“seattle”。由于Named约束的槽是串，将对其解析“seattle”。Named约束成功，子句中的代码被执行：
     entity DLEntity denoted by DLEntityWords
     {
          public string[] People；
          with restriction Named<name：＝string>
          {
               People＝Outlook.GetDLMembers(Named.name)；
               if(People＝＝null)
               {
                     return false；
               }
          }
    }
仅当“seattle”是有效的分布组时，代码才返回“true”。如果不是识别出的分布组，则子句返回“false”。这是域特定的知识如何影响SPL解释器返回的解释。如果“seattle”不是分布组，则该解释的解析将失败，仅将返回第一个解释。
解释器进行对命令的解析。根据“seattle”是否是识别出的分布组，将调用succes或failed析构函数。
控制流返回到SendMailFrame。如果DLEntity的解析失败，则Goal子句中的代码将不被执行，SendMailFrame解析失败。否则，代码运行，解析成功。
     frame SendMailFrame：send
   {
         public string[] Targets；
         public MailEntity Mail；
         on resolve
         {
             with restriction DoneTo<what：＝MailEntity>
             {
                  Mail＝DoneTo.what.MailEntity；
             }
             with restriction Goal<goal：＝DLEntity>
             {
                  Targets＝Goal.goal.DLEntity.People；
             }
        }
   }
控制流返回到SendMailCommand，根据SendMailFrame成功与否来调用success析构函数或failed析构函数。
    command SendMailCommand uses SendMailFrame
    {
        on resolve
        {
             on begin
             {
                 return Outlook.IsInSendMailContext()；
             }
             on success
             {
                 Outlook.SendMail(SendMailFrame.Mail，SendMailFrame.Targets)；
             }
             on failure
             {
                 //do whatever cleanup is necessary
             }
        }
  }

Claims (50)

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类型和所述一个或多个约束主体类型。
CNB2005100660002A 2004-04-23 2005-04-22 语义编程语言和语言对象模型 Expired - Fee Related CN100501668C (zh)

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US10/830,988 2004-04-23
US10/830,988 US7761858B2 (en) 2004-04-23 2004-04-23 Semantic programming language
US10/940,483 2004-09-14
US10/942,646 2004-09-15
US10/943,046 2004-09-15
US10/943,091 2004-09-15

Publications (2)

Publication Number Publication Date
CN1716192A true CN1716192A (zh) 2006-01-04
CN100501668C CN100501668C (zh) 2009-06-17

Family

ID=35507599

Family Applications (1)

Application Number Title Priority Date Filing Date
CNB2005100660002A Expired - Fee Related CN100501668C (zh) 2004-04-23 2005-04-22 语义编程语言和语言对象模型

Country Status (2)

Country Link
US (4) US7761858B2 (zh)
CN (1) CN100501668C (zh)

Cited By (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102227712A (zh) * 2008-11-26 2011-10-26 奥普塔姆软件股份有限公司 基于约束的语言中过程的高效自动翻译
CN103294470A (zh) * 2013-05-27 2013-09-11 上海华兴数字科技有限公司 内嵌自然语言的编程语言系统
CN103309846A (zh) * 2013-06-26 2013-09-18 北京云知声信息技术有限公司 一种自然语言信息的处理方法及装置
CN103543997A (zh) * 2012-07-17 2014-01-29 于丙超 三字编程法
CN104871150A (zh) * 2012-07-20 2015-08-26 韦韦欧股份有限公司 在对话交互系统中推断搜索输入中的用户意图的方法和系统
CN107111503A (zh) * 2014-12-22 2017-08-29 华为技术有限公司 用于将呈第一编程语言的源代码编译为呈第二编程语言的程序代码的方法
CN107210033A (zh) * 2015-01-30 2017-09-26 微软技术许可有限责任公司 基于众包来更新用于数字个人助理的语言理解分类器模型
CN107408054A (zh) * 2015-03-05 2017-11-28 I·乔索帕特 用于通用计算图形处理单元中的语言嵌入式编程的流控制
CN108141450A (zh) * 2015-08-05 2018-06-08 脸谱公司 控制装置云
CN108733359A (zh) * 2018-06-14 2018-11-02 北京航空航天大学 一种软件程序的自动生成方法
CN109491671A (zh) * 2018-10-19 2019-03-19 深圳市轱辘汽车维修技术有限公司 诊断软件下载方法、装置、终端设备及存储介质
WO2020015190A1 (zh) * 2018-07-18 2020-01-23 平安科技（深圳）有限公司 业务规则的生成方法、电子装置及可读存储介质
CN111194401A (zh) * 2017-10-10 2020-05-22 国际商业机器公司 意图识别的抽象和可移植性
CN106293725B (zh) * 2016-08-04 2021-03-02 深圳市微我科技有限公司 一种基于后实现的自然语言混合编程方法
CN112487790A (zh) * 2019-09-11 2021-03-12 甲骨文国际公司 包括粗略语义解析器和精细语义解析器的改进语义解析器
CN112966513A (zh) * 2021-03-05 2021-06-15 北京百度网讯科技有限公司 用于实体链接的方法和装置

Families Citing this family (131)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6138126A (en) * 1995-05-31 2000-10-24 Network Appliance, Inc. Method for allocating files in a file system integrated with a raid disk sub-system
US7013308B1 (en) 2000-11-28 2006-03-14 Semscript Ltd. Knowledge storage and retrieval system and method
US7502730B2 (en) * 2002-06-14 2009-03-10 Microsoft Corporation Method and apparatus for federated understanding
US7519948B1 (en) * 2002-12-26 2009-04-14 Judson Ames Cornish Platform for processing semi-structured self-describing data
US7890938B2 (en) * 2003-02-26 2011-02-15 Novell, Inc. Heterogeneous normalization of data characteristics
US7823139B2 (en) * 2003-07-19 2010-10-26 Bea Systems, Inc. Method and system for translating programming languages
US8037102B2 (en) 2004-02-09 2011-10-11 Robert T. and Virginia T. Jenkins Manipulating sets of hierarchical data
EP1585031A1 (en) * 2004-03-29 2005-10-12 Sap Ag Generating data base queries based on data dictionary.
US7409337B1 (en) * 2004-03-30 2008-08-05 Microsoft Corporation Natural language processing interface
US20080040315A1 (en) * 2004-03-31 2008-02-14 Auerbach David B Systems and methods for generating a user interface
US9009153B2 (en) 2004-03-31 2015-04-14 Google Inc. Systems and methods for identifying a named entity
US7664734B2 (en) * 2004-03-31 2010-02-16 Google Inc. Systems and methods for generating multiple implicit search queries
US8631001B2 (en) * 2004-03-31 2014-01-14 Google Inc. Systems and methods for weighting a search query result
US7707142B1 (en) 2004-03-31 2010-04-27 Google Inc. Methods and systems for performing an offline search
US8041713B2 (en) 2004-03-31 2011-10-18 Google Inc. Systems and methods for analyzing boilerplate
US7272601B1 (en) * 2004-03-31 2007-09-18 Google Inc. Systems and methods for associating a keyword with a user interface area
US7693825B2 (en) * 2004-03-31 2010-04-06 Google Inc. Systems and methods for ranking implicit search results
US7761858B2 (en) * 2004-04-23 2010-07-20 Microsoft Corporation Semantic programming language
US9646107B2 (en) 2004-05-28 2017-05-09 Robert T. and Virginia T. Jenkins as Trustee of the Jenkins Family Trust Method and/or system for simplifying tree expressions such as for query reduction
US8131754B1 (en) 2004-06-30 2012-03-06 Google Inc. Systems and methods for determining an article association measure
US7788274B1 (en) * 2004-06-30 2010-08-31 Google Inc. Systems and methods for category-based search
US7620632B2 (en) * 2004-06-30 2009-11-17 Skyler Technology, Inc. Method and/or system for performing tree matching
US20130304453A9 (en) * 2004-08-20 2013-11-14 Juergen Fritsch Automated Extraction of Semantic Content and Generation of a Structured Document from Speech
US7627591B2 (en) 2004-10-29 2009-12-01 Skyler Technology, Inc. Method and/or system for manipulating tree expressions
US7801923B2 (en) 2004-10-29 2010-09-21 Robert T. and Virginia T. Jenkins as Trustees of the Jenkins Family Trust Method and/or system for tagging trees
US7636727B2 (en) 2004-12-06 2009-12-22 Skyler Technology, Inc. Enumeration of trees from finite number of nodes
US7630995B2 (en) 2004-11-30 2009-12-08 Skyler Technology, Inc. Method and/or system for transmitting and/or receiving data
US20060143216A1 (en) * 2004-12-23 2006-06-29 Gupta Anurag K Method and system for integrating multimodal interpretations
US8316059B1 (en) 2004-12-30 2012-11-20 Robert T. and Virginia T. Jenkins Enumeration of rooted partial subtrees
US8615530B1 (en) 2005-01-31 2013-12-24 Robert T. and Virginia T. Jenkins as Trustees for the Jenkins Family Trust Method and/or system for tree transformation
US7681177B2 (en) 2005-02-28 2010-03-16 Skyler Technology, Inc. Method and/or system for transforming between trees and strings
US8356040B2 (en) * 2005-03-31 2013-01-15 Robert T. and Virginia T. Jenkins Method and/or system for transforming between trees and arrays
US7548849B2 (en) * 2005-04-29 2009-06-16 Research In Motion Limited Method for generating text that meets specified characteristics in a handheld electronic device and a handheld electronic device incorporating the same
US7899821B1 (en) 2005-04-29 2011-03-01 Karl Schiffmann Manipulation and/or analysis of hierarchical data
US20060277525A1 (en) * 2005-06-06 2006-12-07 Microsoft Corporation Lexical, grammatical, and semantic inference mechanisms
FR2887349B1 (fr) * 2005-06-21 2008-04-04 Alcatel Sa Procede de traitement de donnees compatible avec un formalisme de modelisation d'objets
US7460996B2 (en) * 2005-06-23 2008-12-02 Microsoft Corporation Using strong data types to express speech recognition grammars in software programs
US8126702B2 (en) * 2005-08-01 2012-02-28 Sap Ag Translating data objects
US8666928B2 (en) * 2005-08-01 2014-03-04 Evi Technologies Limited Knowledge repository
US7552053B2 (en) * 2005-08-22 2009-06-23 International Business Machines Corporation Techniques for aiding speech-to-speech translation
DE102005050579A1 (de) * 2005-10-21 2007-05-10 Boris Kaplan Ein Computersystem und das Arbeitsverfahren von diesem Computersystem von Künstlicher Intelligenz von einem Cyborg oder einem Android.
US8015236B2 (en) * 2005-10-25 2011-09-06 Waratek Pty. Ltd. Replication of objects having non-primitive fields, especially addresses
US8082496B1 (en) * 2006-01-26 2011-12-20 Adobe Systems Incorporated Producing a set of operations from an output description
US7599861B2 (en) 2006-03-02 2009-10-06 Convergys Customer Management Group, Inc. System and method for closed loop decisionmaking in an automated care system
US7971182B1 (en) * 2006-05-09 2011-06-28 Vmware, Inc. Application environment specifications for provisioning application specific runtime environments using undefined symbols
US8379830B1 (en) 2006-05-22 2013-02-19 Convergys Customer Management Delaware Llc System and method for automated customer service with contingent live interaction
US7809663B1 (en) 2006-05-22 2010-10-05 Convergys Cmg Utah, Inc. System and method for supporting the utilization of machine language
US7966182B2 (en) * 2006-06-20 2011-06-21 Lunis Orcutt Voiced programming system and method
US20080148284A1 (en) * 2006-12-15 2008-06-19 Maui Media Lab Llc Apparatus and method for developing and executing applications with declarative objects
US8321429B2 (en) * 2006-12-28 2012-11-27 Sybase, Inc. Accelerating queries using secondary semantic column enumeration
US7822750B2 (en) * 2007-01-17 2010-10-26 Aptima, Inc Method and system to compare data entities
US8429626B2 (en) 2007-02-15 2013-04-23 Microsoft Corporation Packaging content updates
US8577937B1 (en) 2007-05-09 2013-11-05 Vmware, Inc. Repository including exclusion list
US8001083B1 (en) 2007-05-09 2011-08-16 Vmware, Inc. Repository including version management
US8219987B1 (en) 2007-08-24 2012-07-10 Vmware, Inc. Optimized virtual machine specification for provisioning application specific runtime environment
US9015180B1 (en) 2007-05-09 2015-04-21 Vmware, Inc. Repository including file identification
US8347263B1 (en) 2007-05-09 2013-01-01 Vmware, Inc. Repository including installation metadata for executable applications
US11262996B2 (en) 2007-05-09 2022-03-01 Vmware, Inc. Repository including exclusion list
US8522195B2 (en) * 2007-09-14 2013-08-27 Exigen Properties, Inc. Systems and methods to generate a software framework based on semantic modeling and business rules
US8838659B2 (en) 2007-10-04 2014-09-16 Amazon Technologies, Inc. Enhanced knowledge repository
EP2071452A1 (en) * 2007-12-07 2009-06-17 Alcatel Lucent Device and method for automatically building applications from specifications and from off-the-shelf components selected by semantic analysis
US8392511B2 (en) * 2008-01-17 2013-03-05 International Business Machines Corporation Embedding a unique serial number into the content of an email for tracking information dispersion
US9201870B2 (en) * 2008-01-25 2015-12-01 First Data Corporation Method and system for providing translated dynamic web page content
US20090252163A1 (en) * 2008-04-03 2009-10-08 Telcordia Technologies, Inc. Grammar and Ontology for Multicast Communication
US8700385B2 (en) * 2008-04-04 2014-04-15 Microsoft Corporation Providing a task description name space map for the information worker
JP5150341B2 (ja) * 2008-04-10 2013-02-20 株式会社東芝 データ作成装置及び方法
US8689195B2 (en) * 2008-06-03 2014-04-01 International Business Machines Corporation Identifying structured data types as requiring designated initializers
US20090326925A1 (en) * 2008-06-27 2009-12-31 Microsoft Corporation Projecting syntactic information using a bottom-up pattern matching algorithm
US20090326924A1 (en) * 2008-06-27 2009-12-31 Microsoft Corporation Projecting Semantic Information from a Language Independent Syntactic Model
US20100088674A1 (en) * 2008-10-06 2010-04-08 Microsoft Corporation System and method for recognizing structure in text
JP2010128583A (ja) * 2008-11-25 2010-06-10 Toshiba Corp テスト容易化設計装置ならびにその方法およびプログラム
US9805089B2 (en) 2009-02-10 2017-10-31 Amazon Technologies, Inc. Local business and product search system and method
US8799877B2 (en) * 2009-03-27 2014-08-05 Optumsoft, Inc. Interpreter-based program language translator using embedded interpreter types and variables
US9075667B2 (en) * 2009-05-21 2015-07-07 Microsoft Technology Licensing, Llc Dynamic binding directed by static types
US8572589B2 (en) * 2009-06-30 2013-10-29 Agilent Technologies, Inc. Programming language translator and enabling translation of machine-centric commands for controlling instrument
US8464224B2 (en) * 2009-06-30 2013-06-11 Sap Ag Integrated performance and load testing tool for application servers
US8548798B2 (en) * 2010-02-26 2013-10-01 International Business Machines Corporation Representations for graphical user interfaces of operators, data types, and data values in a plurality of natural languages
US9378202B2 (en) * 2010-03-26 2016-06-28 Virtuoz Sa Semantic clustering
US8694304B2 (en) * 2010-03-26 2014-04-08 Virtuoz Sa Semantic clustering and user interfaces
US8676565B2 (en) 2010-03-26 2014-03-18 Virtuoz Sa Semantic clustering and conversational agents
US9110882B2 (en) 2010-05-14 2015-08-18 Amazon Technologies, Inc. Extracting structured knowledge from unstructured text
US8499290B2 (en) * 2010-06-15 2013-07-30 Microsoft Corporation Creating text functions from a spreadsheet
US8554796B2 (en) * 2010-07-16 2013-10-08 Tt Government Solutions, Inc. Query-based semantic analysis of ad hoc configuration languages for networks
US9524291B2 (en) * 2010-10-06 2016-12-20 Virtuoz Sa Visual display of semantic information
CN102467497B (zh) * 2010-10-29 2014-11-05 国际商业机器公司 校对程序中的文本翻译的方法和系统
US8731902B2 (en) * 2010-12-23 2014-05-20 Sap Ag Systems and methods for accessing applications based on user intent modeling
US8700638B2 (en) * 2011-03-08 2014-04-15 Libera, Inc. Computer-implemented weighted tree search to resolve variable name ambiguity
US9015661B1 (en) * 2011-06-23 2015-04-21 The Mathworks, Inc. Restricting class inheritance relationships
US20130042235A1 (en) * 2011-08-10 2013-02-14 International Business Machines Corporation Dynamic bootstrap literal processing within a managed runtime environment
CA2759516C (en) 2011-11-24 2019-12-31 Ibm Canada Limited - Ibm Canada Limitee Serialization of pre-initialized objects
US9195653B2 (en) * 2011-10-24 2015-11-24 Google Inc. Identification of in-context resources that are not fully localized
US9009183B2 (en) * 2011-11-03 2015-04-14 Microsoft Technology Licensing, Llc Transformation of a system change set from machine-consumable form to a form that is readily consumable by a human
KR101875820B1 (ko) * 2011-11-25 2018-07-06 구글 엘엘씨 어플리케이션 로컬화에 있어서의 번역 지원 제공
US20130290926A1 (en) * 2012-04-30 2013-10-31 Rheti Inc. Semantic code binding to enable non-developers to build apps
US9269273B1 (en) 2012-07-30 2016-02-23 Weongozi Inc. Systems, methods and computer program products for building a database associating n-grams with cognitive motivation orientations
US9442909B2 (en) 2012-10-11 2016-09-13 International Business Machines Corporation Real time term suggestion using text analytics
US20140136184A1 (en) * 2012-11-13 2014-05-15 Treato Ltd. Textual ambiguity resolver
US8893098B2 (en) * 2012-12-14 2014-11-18 Oracle International Corporation Deferred type inference of generic type parameters in function calls to overloaded functions
US9432278B2 (en) * 2013-03-07 2016-08-30 Microsoft Technology Licensing, Llc Simulation of interactions between network endpoints
US10606569B2 (en) * 2013-06-02 2020-03-31 Microsoft Technology Licensing, Llc Declarative configuration elements
US10363486B2 (en) 2013-06-10 2019-07-30 Pixel Press Technology, LLC Smart video game board system and methods
US9579573B2 (en) 2013-06-10 2017-02-28 Pixel Press Technology, LLC Systems and methods for creating a playable video game from a three-dimensional model
US9370721B2 (en) * 2013-06-10 2016-06-21 Pixel Press Technology, LLC Systems and methods for creating a playable video game from a static model
US9715382B2 (en) * 2013-06-25 2017-07-25 Microsoft Technology Licensing, Llc Class and namespace discovery in prototype based language
US9741343B1 (en) * 2013-12-19 2017-08-22 Amazon Technologies, Inc. Voice interaction application selection
US9038037B1 (en) * 2014-07-22 2015-05-19 Ted J. Biggerstaff Automatically solving simultaneous type equations for type difference transformations that redesign code
EP3757928A1 (en) * 2014-07-31 2020-12-30 Samsung Electronics Co., Ltd. Message service providing device and method of providing content via the same
US11003426B1 (en) 2014-09-10 2021-05-11 Soundhound, Inc. Identification of code for parsing given expressions
US9361075B2 (en) * 2014-11-12 2016-06-07 International Business Machines Corporation Contraction aware parsing system for domain-specific languages
US10333696B2 (en) 2015-01-12 2019-06-25 X-Prime, Inc. Systems and methods for implementing an efficient, scalable homomorphic transformation of encrypted data with minimal data expansion and improved processing efficiency
US10467228B2 (en) 2015-08-11 2019-11-05 Sybase, Inc. Accelerating database queries using equivalence union enumeration
US10642833B2 (en) 2015-08-11 2020-05-05 Sybase, Inc. Accelerating database queries using composite union enumeration
CN106250159B (zh) * 2016-08-04 2020-12-22 深圳市微我科技有限公司 一种利用自然语言的混合编程方法
US10732965B2 (en) * 2016-10-13 2020-08-04 Tata Consultancy Services Limited Systems and methods for dynamic generation of questionnaires on programming concepts
US10652592B2 (en) 2017-07-02 2020-05-12 Comigo Ltd. Named entity disambiguation for providing TV content enrichment
US9946514B1 (en) * 2017-07-27 2018-04-17 Huma.Ai Systems and methods for generating functional application designs
CN107507273A (zh) * 2017-08-11 2017-12-22 施侃乐 通过计算机程序控制游标空间运动构造三维模型的方法
US10671355B2 (en) 2018-01-21 2020-06-02 Microsoft Technology Licensing, Llc. Code completion with machine learning
US10628130B2 (en) * 2018-03-29 2020-04-21 Microsoft Technology Licensing, Llc. Code completion of custom classes with machine learning
US10990358B2 (en) 2018-03-29 2021-04-27 Microsoft Technology Licensing, Llc. Code completion for overloaded methods
US11645576B2 (en) 2018-04-29 2023-05-09 Microsoft Technology Licensing, Llc. Code completion for languages with hierarchical structures
US10725748B2 (en) * 2018-11-19 2020-07-28 Microsoft Technology Licensing, Llc Extracting program features for assisting software development
US10860295B1 (en) * 2019-01-03 2020-12-08 Amazon Technologies, Inc. Automated detection of ambiguities in software design diagrams
US10831456B1 (en) * 2019-05-31 2020-11-10 The Mathworks, Inc. External code integrations within a computing environment
US11379577B2 (en) 2019-09-26 2022-07-05 Microsoft Technology Licensing, Llc Uniform resource locator security analysis using malice patterns
US11509667B2 (en) 2019-10-19 2022-11-22 Microsoft Technology Licensing, Llc Predictive internet resource reputation assessment
CN111325035B (zh) * 2020-02-15 2023-10-20 周哲 泛化和泛在的语义交互方法、设备及存储介质
US11431751B2 (en) 2020-03-31 2022-08-30 Microsoft Technology Licensing, Llc Live forensic browsing of URLs
CN111506368B (zh) * 2020-04-21 2023-09-22 北京同邦卓益科技有限公司 对异步调用转同步调用的方法、装置、设备及存储介质
CN112669821B (zh) * 2020-12-17 2024-04-30 中国科学技术大学 一种语音意图识别方法、装置、设备及存储介质
US20230359789A1 (en) * 2022-05-04 2023-11-09 X Development Llc Varying embedding(s) and/or action model(s) utilized in automatic generation of action set responsive to natural language request

Family Cites Families (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
SE466029B (sv) 1989-03-06 1991-12-02 Ibm Svenska Ab Anordning och foerfarande foer analys av naturligt spraak i ett datorbaserat informationsbehandlingssystem
JP2801459B2 (ja) * 1992-02-21 1998-09-21 富士通株式会社 オブジェクトネットワークによる言語処理システム
US5548749A (en) 1993-10-29 1996-08-20 Wall Data Incorporated Semantic orbject modeling system for creating relational database schemas
US5794080A (en) * 1994-08-31 1998-08-11 Nikon Corporation Piezoelectric vibration angular velocity meter and camera using the same
US5794050A (en) 1995-01-04 1998-08-11 Intelligent Text Processing, Inc. Natural language understanding system
US6292767B1 (en) 1995-07-18 2001-09-18 Nuance Communications Method and system for building and running natural language understanding systems
JPH09212507A (ja) 1996-02-07 1997-08-15 Canon Inc 文字処理装置と文字列の解析方法
US5966686A (en) 1996-06-28 1999-10-12 Microsoft Corporation Method and system for computing semantic logical forms from syntax trees
US6425119B1 (en) * 1996-10-09 2002-07-23 At&T Corp Method to produce application oriented languages
US6041312A (en) * 1997-03-28 2000-03-21 International Business Machines Corporation Object oriented technology framework for accounts receivable and accounts payable
US5936860A (en) * 1997-03-28 1999-08-10 International Business Machines Corporation Object oriented technology framework for warehouse control
US5987423A (en) * 1997-03-28 1999-11-16 International Business Machines Corporation Object oriented technology framework for order processing
EP1116134A1 (en) 1998-08-24 2001-07-18 BCL Computers, Inc. Adaptive natural language interface
US6173441B1 (en) * 1998-10-16 2001-01-09 Peter A. Klein Method and system for compiling source code containing natural language instructions
DE59901575D1 (de) * 1998-10-27 2002-07-04 Siemens Ag Verfahren und anordnung zur klassenbildung für ein sprachmodell basierend auf linguistischen klassen
US6757718B1 (en) 1999-01-05 2004-06-29 Sri International Mobile navigation of network-based electronic information using spoken input
US6223150B1 (en) * 1999-01-29 2001-04-24 Sony Corporation Method and apparatus for parsing in a spoken language translation system
US6374224B1 (en) 1999-03-10 2002-04-16 Sony Corporation Method and apparatus for style control in natural language generation
US6829603B1 (en) 2000-02-02 2004-12-07 International Business Machines Corp. System, method and program product for interactive natural dialog
US20020046019A1 (en) 2000-08-18 2002-04-18 Lingomotors, Inc. Method and system for acquiring and maintaining natural language information
US7085708B2 (en) 2000-09-23 2006-08-01 Ravenflow, Inc. Computer system with natural language to machine language translator
SE0101127D0 (sv) 2001-03-30 2001-03-30 Hapax Information Systems Ab Method of finding answers to questions
AUPR464601A0 (en) 2001-04-30 2001-05-24 Commonwealth Of Australia, The Shapes vector
US20030055625A1 (en) * 2001-05-31 2003-03-20 Tatiana Korelsky Linguistic assistant for domain analysis methodology
US7003445B2 (en) 2001-07-20 2006-02-21 Microsoft Corporation Statistically driven sentence realizing method and apparatus
US6857118B2 (en) * 2001-07-25 2005-02-15 The Mathworks, Inc. Function values in computer programming languages having dynamic types and overloading
CN102681878A (zh) * 2001-08-17 2012-09-19 梁扶汉 无需修改现有代码即可增加新软件特征的方法
US6829606B2 (en) * 2002-02-14 2004-12-07 Infoglide Software Corporation Similarity search engine for use with relational databases
US7149746B2 (en) 2002-05-10 2006-12-12 International Business Machines Corporation Method for schema mapping and data transformation
US7299180B2 (en) * 2002-12-10 2007-11-20 International Business Machines Corporation Name entity extraction using language models
US7761858B2 (en) * 2004-04-23 2010-07-20 Microsoft Corporation Semantic programming language
US7689410B2 (en) * 2004-04-23 2010-03-30 Microsoft Corporation Lexical semantic structure

Cited By (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102227712A (zh) * 2008-11-26 2011-10-26 奥普塔姆软件股份有限公司 基于约束的语言中过程的高效自动翻译
CN102227712B (zh) * 2008-11-26 2014-09-03 奥普塔姆软件股份有限公司 基于约束的语言中过程的高效自动翻译
CN103543997A (zh) * 2012-07-17 2014-01-29 于丙超 三字编程法
CN104871150B (zh) * 2012-07-20 2017-10-13 韦韦欧股份有限公司 在对话交互系统中推断搜索输入中的用户意图的方法和系统
CN104871150A (zh) * 2012-07-20 2015-08-26 韦韦欧股份有限公司 在对话交互系统中推断搜索输入中的用户意图的方法和系统
CN103294470A (zh) * 2013-05-27 2013-09-11 上海华兴数字科技有限公司 内嵌自然语言的编程语言系统
CN103309846A (zh) * 2013-06-26 2013-09-18 北京云知声信息技术有限公司 一种自然语言信息的处理方法及装置
CN103309846B (zh) * 2013-06-26 2016-05-25 北京云知声信息技术有限公司 一种自然语言信息的处理方法及装置
CN107111503A (zh) * 2014-12-22 2017-08-29 华为技术有限公司 用于将呈第一编程语言的源代码编译为呈第二编程语言的程序代码的方法
CN107111503B (zh) * 2014-12-22 2020-06-16 华为技术有限公司 将呈第一编程语言的源代码编译为呈第二编程语言的程序代码的方法
CN107210033A (zh) * 2015-01-30 2017-09-26 微软技术许可有限责任公司 基于众包来更新用于数字个人助理的语言理解分类器模型
CN107210033B (zh) * 2015-01-30 2020-10-16 微软技术许可有限责任公司 基于众包来更新用于数字个人助理的语言理解分类器模型
CN107408054A (zh) * 2015-03-05 2017-11-28 I·乔索帕特 用于通用计算图形处理单元中的语言嵌入式编程的流控制
CN108141450A (zh) * 2015-08-05 2018-06-08 脸谱公司 控制装置云
CN108141450B (zh) * 2015-08-05 2021-04-02 脸谱公司 控制装置云
CN106293725B (zh) * 2016-08-04 2021-03-02 深圳市微我科技有限公司 一种基于后实现的自然语言混合编程方法
CN111194401A (zh) * 2017-10-10 2020-05-22 国际商业机器公司 意图识别的抽象和可移植性
CN111194401B (zh) * 2017-10-10 2021-09-28 国际商业机器公司 意图识别的抽象和可移植性
US11138506B2 (en) 2017-10-10 2021-10-05 International Business Machines Corporation Abstraction and portability to intent recognition
CN108733359A (zh) * 2018-06-14 2018-11-02 北京航空航天大学 一种软件程序的自动生成方法
WO2020015190A1 (zh) * 2018-07-18 2020-01-23 平安科技（深圳）有限公司 业务规则的生成方法、电子装置及可读存储介质
CN109491671A (zh) * 2018-10-19 2019-03-19 深圳市轱辘汽车维修技术有限公司 诊断软件下载方法、装置、终端设备及存储介质
CN112487790A (zh) * 2019-09-11 2021-03-12 甲骨文国际公司 包括粗略语义解析器和精细语义解析器的改进语义解析器
CN112487790B (zh) * 2019-09-11 2023-04-28 甲骨文国际公司 包括粗略语义解析器和精细语义解析器的改进语义解析器
CN112966513A (zh) * 2021-03-05 2021-06-15 北京百度网讯科技有限公司 用于实体链接的方法和装置
CN112966513B (zh) * 2021-03-05 2023-08-01 北京百度网讯科技有限公司 用于实体链接的方法和装置

Also Published As

Publication number Publication date
US20050289522A1 (en) 2005-12-29
US7761858B2 (en) 2010-07-20
US8201139B2 (en) 2012-06-12
US20050273771A1 (en) 2005-12-08
CN100501668C (zh) 2009-06-17
US20050251382A1 (en) 2005-11-10
US7171352B2 (en) 2007-01-30
US20050273335A1 (en) 2005-12-08
US7681186B2 (en) 2010-03-16

Similar Documents

Publication Publication Date Title
CN1716192A (zh) 语义编程语言和语言对象模型
CN1297935C (zh) 进行非结构化信息管理和自动文本分析的系统和方法
US7689410B2 (en) Lexical semantic structure
CN1659589A (zh) 用于提供推理服务的系统和方法
CN1739107A (zh) 为可由硬件/软件接口系统管理的信息单元提供同步服务的系统和方法
CN1609792A (zh) 计算机程序的编程接口
CN1961294A (zh) 为可由硬件/软件接口系统管理的信息单元提供关系和分层同步服务的系统和方法
CN1182467C (zh) 可扩充的分布企业应用集成系统
CN100342691C (zh) 多模式对话处理方法
CN1791853A (zh) 个人化文件夹
CN1609795A (zh) 用于计算机平台的编程接口
CN1073276A (zh) 语言的中性对象
CN1609794A (zh) 用于计算机平台的编程接口
CN1073540A (zh) 管理类方法名
CN1820266A (zh) 用于将应用程序与基于项的存储平台接口的系统和方法
CN1838165A (zh) 工作项跟踪系统的工作项规则
CN1820245A (zh) 用于基于项目的存储平台中的数据建模的系统和方法
CN1619490A (zh) 系统的集成设计，部署和管理阶段
CN1315020A (zh) 自由格式数据处理的方法和设备
CN1797399A (zh) 用于文本挖掘和搜索的应用程序编程接口
CN1869989A (zh) 用于从非结构化描述生成结构化表示的系统和方法
CN1547709A (zh) 产生具有多个同时贡献信息的作者的有序编译的方法和系统
CN1755721A (zh) 组件化和可扩展的工作流模型
CN1719410A (zh) 面向对象语言中并发程序的实现
CN1669018A (zh) 手持终端框架系统

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C14 Grant of patent or utility model
GR01 Patent grant
ASS Succession or assignment of patent right

Owner name: MICROSOFT TECHNOLOGY LICENSING LLC

Free format text: FORMER OWNER: MICROSOFT CORP.

Effective date: 20150505

C41 Transfer of patent application or patent right or utility model
TR01 Transfer of patent right

Effective date of registration: 20150505

Address after: Washington State

Patentee after: Micro soft technique license Co., Ltd

Address before: Washington State

Patentee before: Microsoft Corp.

CF01 Termination of patent right due to non-payment of annual fee
CF01 Termination of patent right due to non-payment of annual fee

Granted publication date: 20090617

Termination date: 20200422