CN105308558A - 基于规则的数据处理系统和方法 - Google Patents

Abstract

描述了用于处理由应用程序生成的规则和关联事实包的系统、方法和介质，该应用程序与处理引擎、数据库和规则引擎进行通信，处理引擎、数据库和规则引擎根据规则处理事实包并且生成至应用程序的一个或更多个依赖于规则的响应，该应用程序基于响应执行一个或更多个工作流。规则引擎可以应用前向链接、后向链接或者前向链接与后向链接的组合来处理规则和事实。还描述了与处理引擎、数据库和规则引擎一起工作的许多新颖应用程序。

Description

基于规则的数据处理系统和方法

相关申请的交叉引用

本申请要求于2012年12月10日提交的美国临时专利申请第61/735,501号的权益。

技术领域

本公开涉及基于规则的数据处理系统以及使用该基于规则的数据处理系统的方法。

背景技术

在基于云的系统中的数据采集、存储、访问以及组织得到了新近的发展，其使得在世界范围内附接至个人和团体的数据量可以激增。当数据集增长过大以使其在使用传统数据库管理工具的情况下变得难以应对时，该数据集被称为“大数据”。大数据目前为宏集，但是增大的问题影响大量公布连续的交易数据的较大的团体以及试图处理来自不同的源的大量数据的其他组织，诸如试图处理来自车辆、传感器、摄像装置和许多其他源的数据以管理城市公路上的交通量的大城市政府。随着社交网络、云服务和媒体服务扩展，每人的数据量级已经开始增大至由数据直接地或松散地耦接至的计算机系统和个体二者难于管理的程度。

当前一直在努力的是，关注使得个体能够容易地查询围绕其的这些大量数据集，其已知为个人搜索引擎。个人搜索引擎在使得个体能够更好地搜索和组织其自身非常大的集体(collective)数据集方面是重要的，然而，仍然存在的要点是，集体数据集的量级变得对于个体的能力以及对查询处理投入时间和精力的意愿难以管理。

类似地，诸如电子邮件和文本的现有通信技术已经由于营销消息、个人信件和工作信件的混合以及其他闲杂事物而变得超负荷。不能适应当代个人通信风格的本质，其从少量接收者之间的短的单个消息发展成在不同的地理位置中的期望共享以语境高度相关的格式的过多的内容类型的许多参与者之间的更流畅的通信风格。接收的电子邮件通信例如缺少向用户提供消息的语境相关性的能力，即，接收的每条通信基本上以具有小的滤除(filtering)能力的相同的方式被处理。增大围绕个体和不充足通信的采集数据集的量级的结果是，组织软件工具变得大量无效。此外，曾经为出于个人和商业原因而采用其进行通信的清晰整洁的信道的电子邮件已经变得闲杂和无效。

许多年之前，日本国际贸易和工业部发动了开发“第五代计算机”的10年项目，其被认为通过使用对大数据库(诸如大数据)进行操作的大量并行处理器来提高(boost)性能。软件要基于逻辑编程(语言的逻辑语言集)的两个原因在于：在知识呈现层次(level)，自动推理将基于逻辑；以及在硬件层次，逻辑的说明本质将使得可以自动调度机器中的大量处理单元之间的计算。

第五代计算机项目由于许多原因而在1992年终止，包括下述事实：传统的“现货供应”计算机得到显著地改进，它们很快胜过并行机器；以及逻辑编程语言中的提交选择特征破坏了其说明语义。从硬件方面而言，该项目是简单地超前的。从2012年4月起，8核处理器为标准“现货供应”产品，并且移动电话配备有4核处理器。具有16或32处理器核心的计算机在几年内将变为新常态。从软件方面而言，说明语义问题现今仍为问题，其仅当在多个核心上并发地运行说明编程时被放大。

发明内容

描述了用于处理由应用程序生成的规则和关联事实包的系统和方法，该应用程序与处理引擎、数据库和规则引擎进行通信，该处理引擎、数据库和规则引擎根据规则处理事实包并且生成至应用程序的一个或更多个基于规则的响应，该应用程序基于响应执行一个或更多个工作流。规则引擎可以应用前向链、后向链或前向链与后向链的组合以处理规则和事实。规则引擎中的后向链规则与前向链规则的组合的实施例可以包括将根据前向链规则所推断的事实用作针对后向链规则的目标的步骤，除非前向链规则包含依赖于另一前向链推断的否定的条件，在前向链规则包含依赖于另一前向链推断的否定的条件的情况下，前向链规则的执行被中止(suspend)，规则判定中的针对问题事实的相关性(dependency)被记录在表中，并且前向链规则的执行跳转至下一个未被试验的事实以选择要执行的新规则。还描述了与处理引擎、数据库和规则引擎一起工作的许多新颖的应用程序。

附图说明

图1是示出了依照实施例的组合的后向链规则和具有否定的前链规则的流程图。

图2示出了依照实施例的高可用性架构。

图3示出了依照实施例通过分片进行的缩放(scaling)。

图4示出了依照实施例通过碎片(fragmentation)进行的缩放。

图5A示出了依照实施例的并行前向链。

图5B示出了依照实施例的后向链中的OR并行性(OR-parallelism)。

图5C示出后向链中的AND并行性(AND-parallelism)。

图6是包含规则引擎的实施例的应用程序开发平台的实施例的框图。

图7是针对图6的应用程序开发平台的数据输入的实施例的框图。

图8是与图6的规则引擎一起使用的数据库和处理引擎的实施例的框图。

图9是图6的规则引擎的实施例的框图。

图10是图6的与应用程序一起工作的处理部的实施例的框图。

图11是示出了应用程序如何与图10的处理部一起工作的高层描述的流程图。

图12是示出了依照实施例的文档管理系统的流程图。

图13是示出计算装置的框图。

具体实施方式

规则引擎的实施例可以包含下述各种应用程序实施例的基础：其能够以与数据集的大小或复杂性无关地实现数据的语境和相关性的方式，通过处理和工作流使得能够进行数据的智能处理。因此，将以对规则引擎的实施例的描述开始该描述，然后描述涉及作为中央元件的规则引擎的各种可能的应用程序实施例。

本规则引擎的实施例可以包括具有存储在其上的指令的计算机可读介质，当在处理器上被执行时，该指令使得处理器执行各种功能、步骤、算法、处理等。另外，规则引擎可以存储在非易失性、非暂态或计算机可读存储介质上。如本文中所使用地，计算机可读存储介质可以包括被配置用于机器可读信息存储的任何盘或驱动器，并且可以包括现有技术中已知的软盘、CD、DVD、光存储、磁驱动器、固态驱动器、硬驱动器或任何其他存储器装置。

实施例可以提供下述若干新的可能性：将数据的智能处理带入到至对系统中的每个参与者唯一并且高度语境相关的包块的工作流中。在一个实施例中，处理引擎可以使用规则引擎的规则来控制处理和规则事实以表示处理状态。在该配置中，编程可以成为纯逻辑的并且在数学上看来几乎没有(littletono)不期望的副作用或死端(deadend)处理状态。处理状态转变可以基于使得系统非常擅长处理高复杂数据集的条件而非静态流。系统处理可以使用将容错能力添加至系统并且非常适于扩展(scalability)的异步消息传递。考虑到在多核心CPU上的并行执行，可以独立于执行顺序来作出规则语义。

与现有规则引擎相比，依照实施例的规则引擎的示例如下。将本实施例与现有规则引擎的进行比较的要点在于强调本实施例的纯逻辑、说明方面。现有规则引擎被称为DROOLS；其为以Java书写的、由JBOSS(REDHAT的一个部门，起源于2006年)发起的流行的开源规则引擎。其不为纯说明性的，并且其不与本规则引擎一样简明，如以下示例所示：为了对下述规则进行编码：“如果X的父母为Z，并且Z的父母为Y，则X的祖父母为Y”。对应的DROOL代码可以如下书写：

针对规则引擎的本实施例的对应的代码可以如下书写：

parent(X,Z)andparent(Z,Y)＝>grandparent(X,Y)；

二者的这些代码示例仅为说明性的，但是DROOLS允许使用不同的、非说明性规则来书写，诸如以下：

在随后的DROOLS代码中，当条件被触发时，代码首先从知识库(knowledgebase)撤回第一父母关系事实$p1(从而在使其逻辑支持无效的同时使知识库中的祖父母推断保持完整)，然后，规则引擎关闭计算机、停止虚拟服务器(如果规则引擎正操作于云服务器环境下)，或使得发生一些其他故障；所有的上述问题对于采用这样的规则引擎的应用程序而言可能是有问题的，原因在于任何这样的故障可能使得应用程序中止并且未完成所请求的操作。

以上相同的问题对于本规则引擎实施例的对应的代码而言则不会如此，因为说明语义不可能被破坏。另外，通过简化代码，规则引擎的速度可以提高。使用两种规则引擎书写的规则之间的简单的基准测试(benchmark)示出这样的性能的增大。基准测试规则测量仅一个特定功能、两组事实之间的交互(已知为“内连接(innerjoin)”)，以便防止不同类事物的比较。DROOLS代码可以如下书写：

使用本规则引擎的前向链接代码表示的相同的规则可以如下书写：

p(X),q(X)＝>r(X)；

DROOLS为纯前向链接规则引擎，但在本规则引擎的实施例中，该规则也可以使用后向链接功能书写，如下：

r(X):＝p(X),q(X)；

在基准测试中，在所有的其他条件相同的情况下在相同的计算机上操作时，前向链接版本针对200,000事实快41％，并且针对400,000事实快2.8％。后向链接版本针对200,000事实快61％，并且针对400,000事实快16.9％。针对前向链接和后向链接，本规则引擎的核心操作：事实的匹配而言可以相同；不同之处仅为推断的布置。

规则引擎的基本结构可以包括驱动引擎的一个或更多个算法。再次参照DROOLS示例，DROOLS基于由CharlesForgy开发的RETE、匹配算法。RETE通过根据由用户建立的规则构建树来操作。事实在顶层节点作为规则的参数进入树，并且沿树向下工作直到其到达叶节点即规则结果为止。更具体地，树包括节点的网络，其中，每个节点(除根之外)与在规则的左手侧(条件部分)中发生的模式(pattern)对应。从根节点至叶节点的路径限定完整的规则左手侧。每个节点具有满足模式的事实的存储器。由于新的事实生效或被修改，所以其沿着网络传播，使得节点在事实与该模式匹配时被注释(annotated)。当事实或事实的组合使得满足针对给定规则的所有的模式时，到达叶节点并且对应的规则被触发。

本规则引擎具有许多特征，其中的一些为可以良好地适于开发可以利用其纯逻辑编程的应用程序的算法。这些特性(以下进一步描述)包括：

A.没有副作用的纯数学逻辑；

B.否定的鲁棒处理；

C.组合的前向链接和后向链接；

D.简明的规则语法；

E.规则引擎可以嵌入在应用程序中或者被提供为网络上的服务器；

F.处理引擎表示作为事实包的针对当前状态为真的每个处理状态；

G.处理状态变换基于条件，而非具有“流”或“线程”的静态图形；以及

H.处理使用异步消息传递。

针对特征A而言，“副作用”是指非逻辑元素，诸如读取文件、写入文件等，其中，规则引擎可以被搁置(hungup)。为了使规则引擎为纯数学，需要移除这样的副作用。如果规则引擎没有副作用，则其仅具有逻辑元素，这意味着当给定输入本规则引擎的实施例产生输出时，结果与逻辑规则的说明语义(数学逻辑解释)一致。

反之，例如，在PROLOG中，在规则引擎自身中处理副作用，这对于并行处理规则引擎而言通常也如此。在这样的规则引擎中，所有的处理状态变化被完成为数据库交易。还存在诸如由特定保险公司所使用的那些的规则引擎，其中，所有的数据以处理状态的形式构建，使得所有的数据在没有数据库交易的情况下对规则引擎可用。然而，这样的规则引擎不允许数据被分段和隔离，所以使用相同的数据的许多不同的处理可以并行运行，这影响规则引擎和对应的应用程序的效率。

针对具有数据库交易的规则引擎而言，总是可能存在冲突，因为不同的处理可能同时试图请求交易，即读/写所有的相同数据或者相同数据的一部分。数据库交易具有以下属性：在任何时间点处，从不直接涉及交易的任何代理的视角而言，发生了与交易关联的所有的变化或者没有发生与交易关联的变化。该属性确保存储处理状态的一个或多个系统总是处于一致状态。所有的非普通数据库应用程序极大地依赖于交易的该属性。

为了确保该交易属性，在多个代理以引起源争用的方式同时请求交易时，数据库使用用于并发控制的两个方案中之一：悲观并发控制(pessimisticconcurrencycontrol)；或者乐观并发控制(optimisticconcurrencycontrol)。悲观并发控制获取对将要涉及交易中的所有的源的排他的锁定，而乐观并发控制不受锁定控制，但是在所有的处理已经完成之后，仅在最终提交操作处检测更新冲突。当检测到冲突时，当前交易返回(rollback)并被重试，直到其可以被完成为止。

乐观并发控制为针对可扩展网络应用程序的标准方案，因为其针对具有低水平的源争用的可扩展应用程序而言更有效，即其针对大多数常用情况而言是优化的，这是将不存在源争用的假设。使用乐观并发控制的任何应用程序需要能够重试由于更新冲突而失败的任何交易。在非常简单的应用程序中，这是容易的——仅对重复的循环中的数据库更新逻辑进行编码，直到交易可以成功提交为止。然而，这需要数据库更新逻辑操作为幂等(idempotent)操作(即，在与其自身相乘时保持不变的操作)，否则交易的语义将依赖于冲突是否发生，即依赖于物理随机因数。

在数据库交易可以被移动至与规则引擎一起工作的处理引擎以避免冲突影响规则引擎自身的情况下，在这种情况下，规则引擎可以不再能够返回到在由导致如上所述的中止的冲突而导致的交易。

通过不具有副作用，根据定义，本规则引擎的实施例的计算为幂等——不存在副作用并且不存在除由嵌入应用程序明确控制的那些之外的外部输入。这对于其他编程语言而言不适用，并且在可以以任何编程语言书写幂等程序的情况下，不确保任何给定的应用程序将会为幂等。因此，使用作为本规则引擎的实施例的幂等编程语言来计算处理状态变换可以使得更易于产生由完全通用(即，图灵完全(Turing-complete))交易功能管理的交易状态变换。

特征A还使得能够使用代数工具来证明规则集的正确性，并且提高/导出该规则集中隐含的属性。例如，可以隔离地、在“清洁的”实验室环境中测试规则。也可以在隔离测试中模拟(不需要过多努力)生产环境中可以发生的任何情形。特征A还具有内部一致的安全权益并且不需要外部输入来解决问题。因此，规则为自身授权。该特征使得安全的允许未信任的外部团体提供其自身规则并且允许运行其想要的无论什么代码以便产生结果，例如应用程序中的个性化配置。

特征B允许以说明的方式使用否定条件。例如，本规则引擎的实施例可以使用该特征来提供后向链接中的if-then-else规则。其他后向链接语言(例如，PROLOG)具有if-then-else，但缺少说明语义。前向链接语言(即，大多数规则引擎，诸如上述保险公司的规则引擎)由于前向链接算法的性质而不具有if-then-else规则。本规则引擎也可以使用前向链接中的明确的否定条件，这依赖于如下进一步描述的本规则引擎中的前向链接和后向链接组合的独特的方式。

前向链接与后向链接的组合的特征C提供比单独前向链接或后向链接更多的表达力。不仅在具有两个选项的平常意义中，而且还通过使得前向链接规则产生由后向链接过滤器/搜索规则减少的推断组将其进行组合，以提供单个回答，或者通过使用后向链接查询作为前向链接规则条件的一部分。

特征D使得本规则引擎与较不简明的替选方式相比更有能力。

特征E为使得能够在不损坏依赖于网络实现的应用程序的性能的情况下，控制规则引擎的分布的有用的实现特征。

特征F允许以平常方式实现传统的有限状态机，允许在相同的处理中以等同的平常方式实现若干并发有限状态机，以及允许处理状态变换规则使用的任何语境数据与处理状态一起被存储在相同的包中。特征F还将简洁性添加至所存储的处理专用数据。作为在规则条件中要使用的事实，数据立即可用。不需要另外的代码来进行数据库检索。特征F确保处理状态的任何形式分析需要仅考虑该特定事实包。

特征G简化了复杂的并发处理的建模并且特征H对扩展性和故障容忍性是有用的。

特征F的特别重要之处可以在于，通过处理作为“事实包”而非作为有限状态机的处理状态，程序执行可以与逻辑执行分离。在没有逻辑隔离的情况下，不存在逻辑规则驱动状态变换的概念。并且在没有独特状态变换的情况下，处理状态仅为(或者也可以为)随机更新的数据库记录的群集。因此，组或

上述特征使得本规则引擎的实施例相较于现有规则引擎具有许多优点。例如，隔离地测试规则的能力使得书写的应用程序更易于使用本规则引擎来测试、调试和保持规则。安全性权益、否定的鲁棒处理、组合的前向链接和后向链接以及简明的规则语法使得规则编程器比现有规则引擎更具有表达力。处理引擎表示作为事实包的每个处理状态、处理状态变换基于条件以及处理使用异步消息传递的事实使得更易于对复杂并发处理进行建模，从而使得使用规则引擎的应用程序较便宜产生和保持。使用代数工具来证明规则集的正确性的能力以及处理状态的任何形式分析仅需要说明事实包针对当前状态为真的事实的事实，使得应用程序能够使用关于规则的自动推理和证明来优化处理和避免错误。并且，虽然其他编程语言使用纯数学逻辑，简明以及可以在网络配置中实现，但是其不为规则引擎。

如关于特征C所指示地，前向链接与后向链接的组合以及在前向链接规则中如何处理否定可以是非常有效的。前向链接为“提供驱动”。前向链接以单独的给定事实开始，并且指出经由规则可以从其推断出什么。基于本规则引擎的实施例的航班选择应用程序可以包括用于实现前向链接的基础算法。例如：

ifrequest(From,To)andnonstop(Flight,From,To)thencandidate(Flight)；

该规则需要一些事实进行工作，所以假设以下事实：

request(“Stockholm”,“London”)；

nonstop(“BA-0777”,“Stockholm”,”London”)；

应当注意，在本文中提供的规则的示例中，已经添加空间以使得规则更易于读取。在以下另外提供用于书写这样的规则的合适的语法的扩展。

现在，上述前向链接规则可以推断新的事实候选(“BA-0777”)(candidate(“BA-0777”))。该推断的意在的意思为，由于其满足请求的条件，航班号BA-0777为针对请求的可能的航班候选。

被包含在航班选择应用程序中的本规则引擎的简化的实施例可以如下处理该前向链接规则：针对给定事实集中的每个事实即request(“Stockholm”，“London”)，规则引擎可以查看包含规则的条件部分(前项)中的request(X，Y)的一些变化的每个规则，然后可以将此与事实匹配并且可以通过约束变量中的两个变量From＝“Stockhom”和To＝“London”来创建规则的示例。规则示例可以类似于：

ifrequest(“Stockholm”,”London”)andnonstop(Flight,”Stockholm”,”London”)

thencandidate(Flight)；

规则引擎然后可以检查条件(在这种情况下为nonstop(“BA-0777”,“Stockholm”，“London”))的任何剩余的部分，以用于与事实集进行匹配。在这种情况下，由于给定事实nonstop(“BA-0777”，“Stockholm”，“London”)匹配，所以找到一个匹配。该匹配使得规则条件为真，并且推断的事实candidate(“BA-0777”)可以被添加至事实集。所有的推断事实也可以以与给定事实集相同的方式与规则进行试验，所以推断和推断的组合可以产生另外的推断等等，并且算法可以继续，直到不存在提供给其的更多的未试验的事实为止。

现在，调用规则引擎的航班选择应用程序可以检查最后的事实集并且查找任何感兴趣的推断，或者可以使得规则引擎通过运行后向链接查询来进行查找。后向链接为“请求驱动”。后向链接以假设声明开始并且指出声明是否为规则的结果。声明可以包括逻辑变量，并且在这种情况下，声明可以仅针对那些变量中的一些特定值为真。然后，后向链接算法可以计算那些值。这使得后向链接适于查询知识库。

根据本规则引擎的实施例，后向链接规则可以比前向链接规则具有更复杂的结构。代替许多单独的“if-then”从句，后向链接中的“if-then”从句可以经由“else”运算符彼此连接。这提供具有纯说明语义的提交选择特征的后向链接，这可以与利用非逻辑提交和修整运算符的现有逻辑编程语言相区分。

继续上述航班选择示例，如果不存在使用户到达期望目的地的非停止航班；仍然可以经由连接航班到达。后向链接可以使得查询关于可能的连接的规则引擎，诸如以下：

此外，可以针对示例假设特定事实，诸如：

Nonstop(“BA-0777”,”Stockholm”,”London”)；

Nonstop(“SK-0903”,”Stockholm”,”NewYork”)；

Nonstop(“BA-0273”,”London”,”SanDiego”)；

Nonstop(“UA-1726”,”NewYork”,”SanDiego”)；

如果后向链接引擎为给定查询possible_flight(“Stockholm”,”SanDiego”,X)，则可以试验找到该声明的逻辑证明，并且针对X提供的一个或更多个值。后向链接算法可以通过使用约束规则中的变量的目标参数来例示合适的规则而优先进行，这可以导致：

下一个步骤可以为对第一“if-then”从句的条件进行评估，这可以通过使用作为目标的条件(在这种情况下为nonstop(Code,”Stockholm”,“SanDiego”))来调用后向链接算法实现。由于nonstop为基本事实断定，所以目标可以与事实存储直接匹配。由于从斯德哥尔摩到圣地亚哥不存在直飞航班，所以不可能找到匹配，因此条件失败。然后可以试验下一个可替选的从句(紧接else之后的从句)。该条件为两个基础事实断定的结合。首先，nonstop(Code1,”Stockholm”,Stop)以与第一从句相同的方式匹配，并且在这种情况下，找到两种匹配，假设以下对应的变量约束：

Code1＝“BA-0777”,Stop＝“London”

Code1＝“SK-0903”,Stop＝“NewYork”

然后，由于存在针对从第一非停止目标停止的两个值，所以nonstop(Code2,Stop,“SanDiego”)非确定地匹配。针对停止值中的每个停止值找到一个匹配，并且针对结合的总体解决方案集为：

Code1＝“BA-0777”,Stop＝“London”,Code2＝“BA-0273”

Code1＝“SK-0903”,Stop＝“NewYork”,Code2＝“UA-1726”

在此，由于其条件为真，所以“if-then”从句被提交。这意味着针对目标没有更多的可替选“if-then”从句可以考虑。在这种情况下，不存在任何可替选方式，除非可以存在调整。现在，原始目标被“then”从句中的子目标替换，并且可以再次开始后向链接算法。该处理可以保持直到不存在要解决的更多的目标为止，或者直到目标中之一失败(使得整个证明失败)为止。还存在第三种可能性；由于若干可能原因中的一个而引起的中止的证明、关于从不约束的变量的值的最显著的条件。

在以上提供的后向链接的示例中，后向链接快速地完成，这是由于替换原始目标的子目标包括单个目标X＝[Code1,Code2]。该目标未被进一步分成子目标，由于“＝”为由规则引擎中的程序进行评估的内部断定。后向链接算法以针对原始查询的两个解决方案集成功终止：

X＝[“BA-0777”,“BA-0273”]

X＝[“SK-0903”,“UA-1726”]

X值中的每个值与从斯德哥尔摩到圣地亚哥的不同的可接受可能路线对应。

忽略非确定，纯顺序后向链接(例如，PROLOG)与用于实现传统程序语言的常见基于堆叠的执行模型非常相似。

根据本规则引擎的实施例，在以上前向链接示例中，规则可以由不仅允许直飞航班还允许连接航班的规则替换，诸如：

ifrequest(From,To)andpossible_flight(From,To,Flight)

thencandidate(Flight)；

现在，前向链接规则包括包含后向链接查询的条件。本实施例使得该情况的处理简单，即使possible_flight(From,To,Flight)为通用查询而非基础事实的查询。根据实施例，输入事实request(“Stockholm”,“SanDiego”)将使得目标possible_flight(“Stockholm”,“SanDiego”,Flight)在作为前向链接规则的条件的评估的一部分的后向链接引擎中被试验。因此，前向链接算法将两个新的推断事实添加至事实集：

Candidate([“BA-0777”,“BA-0273”])；

Candidate([“SK-0903”,“UA-1726”])；

将前向链接推断包括在后向链接规则内几乎与上述一样简单。后向链接目标可以包括具有根据前向链接推断的任何事实的任何基础事实，因此参考前向链接规则的结果与后向链接规则看起来没有特殊，但这并非如此。当前向链接规则包含依赖于另一前向链接推断的否定的条件时，可能出现问题。为了理解这些问题，采用先前的示例规则，但是添加未被取消的航班的另外的条件，诸如：

ifrequest(From,To)andpossible_flight(From,To,Flight)

andnotcancelled(Flight)

thencandidate(Flight)；

然后，如下那样针对cancelled(Flight)添加另外的规则：

Ifnonstop(Flight,From,To)andunsafe(Flight)thencancelled(Flight)；

此处的构思为，由航空当局认定为不安全的任何航班被自动取消以用于航班选择目的，即使航班实际上未被取消。

本实施例的语境中的问题为如何和何时评估cancelled(Flight)，以使其可以确定candidate(Flight)是真还是假。这将如何出现问题的示例如下：假设航班BA-0777不安全。逻辑上，这意味着cancelled(“BA-0777”)将会为假，由于没有规则暗含其为真并且规则引擎在封闭世界假设下工作。因此，cancelled(“BA-0777”)不为真，这暗含事实candidate(“BA-0777”)。具有暗含的事实的问题在于，cancelled(“BA-0777”)的真值不能被计算，直到前向链接规则的具有cancelled(Flight)作为结果的所有的可能应用被用尽为止。然而，直到已经完成前向链接算法以前，不可能知道所有这样的规则应用何时被用尽。

以上示例中的问题的起因为notcancelled(Flight)的否定条件。如果所有的条件仅依赖于肯定事实，而没有否定，则规则的执行顺序不重要。然而，否定使得前向链接算法对顺序敏感。因此，看起来简单的前向链接算法必须被修改，以按照正确的相关性顺序处理问题规则。

本规则引擎的实施例在运行时间时检测使用否定中的推断事实的尝试，以及事实上在后向链接规则内任何地方使用否定中的推断事实的任何尝试，这是由于否定问题也可以在提及推断的事实被动态地嵌套在无效目标内部某些地方的情况下出现。当检测到该情形时，当前的前向链接规则执行被中止，对问题事实的规则断定的相关性被记录在表中，并且前向链接算法跳至下一个未被试验的事实，以选择要执行的新规则。顺序相关性表的示例可以如下：

PredicateDependencies

candidate/1cancelled/1

针对单个断定可以存在多于一个的相关性，但是在这种情况下，candidate/1仅具有单个相关性candidate/1。使用项“/1”意味着单个论据断定。具有两个、三个或更多个论据的使用相同名称的断定被认为是单个断定。

当已经完成所有的非中止前向链接时，扫描顺序相关性表并且随相关性发生所有的断定——但自身不具有任何相关性——针对封闭被标记，这在本语境中意味着现在闭合世界假设针对这些断定为有效的，并且其可以安全地用于否定。然后，前向链接恢复先前中止的规则执行。然后，可以重复整个程序，直到以下两个情形中之一出现为止：

1.在没有中止任何规则执行的情况下已经完成了前向链接；或者

2.在顺序相关性表中不存在无相关性的相关性。在这种情况下，顺序相关性表中的所有的断定被封闭。这实质上相当于在不知道是否有效的情况下做出封闭世界假设，但是这由于在其无效的情况下而起作用，当首次作出在一些否定条件中更早地被假设为假的推断时，其将立刻被检测到，并且然后整个规则引擎调用被异常中止。

例如，由于其不具有其自身的顺序相关性，cancelled/1将会被封闭，并且在前向链接的下一循环中将结束可疑的规则。

更复杂的示例涉及以下述替换的针对取消的规则：

ifnonstop(Flight,From,To)andnotapproved(Flight)thencancelled(Flight)；

在这种情况下，假设批准的还是前向链接推断，所以在第一前向链接运行之后，相关性表将会如下：

PredicateDependencies

candidate/1cancelled/1

cancelled/1approved/1

在该表中，在其自身不具有任何相关性的情况下，在表中仅发生approved/1。当表被理解为图形(数学上的有向图形)时，approved/1仅为叶节点。因此，当在新的前向链接运行中恢复中止的规则执行之前，仅approved/1被封闭。反之，直到已知任何新的cancelled/1事实可能由包含approved/1的条件的否定推断出为止，cancelled/1不能被封闭。因此，第二运行将会再次中止candidate/1，但是这次candidate/1没有相关性并且可以被封闭。第三运行将在没有中止的情况下结束并且前向链接算法将会完成。

只要在相关性图形中没有发生循环，则该前向链接算法将会总成功地处理否定，即，其在以上情形2中将不会结束。并且，如果循环相关性确实发生，则情形2将仍然导致成功，但是也可以导致失败(异常中止证明)，原因在于仍然可能做出与对应的判定可以被较早的封闭的推理假设冲突的推理。

在图1中示出了下述流程图，该流程图示出了如由与规则引擎一起工作的处理引擎处理的、具有否定的前向链接规则或者后向链接规则和具有否定的前向链接规则的组合。在步骤100中，在执行规则的运行时间期间，检查在否定内部遇到的每个判定，以确定每个判定是否如推断的那样被标记，而且仍未关闭(在规则引擎的符号表中存在指示这样的标记)。如果为否，在步骤102中，则规则继续被正常执行。否则，在步骤104中，规则执行由于被试验的事实(针对当前的规则执行的触发事实)和规则的判定而中止，并且其相关性被添加至顺序相关性表。在步骤106中，如果存在更多的未被试验的事实，则在步骤108中并且根据步骤100，针对所有的规则试验下一个未被试验的事实。在步骤104中，如果所有的事实被处理成根据规则完成或者中止，则在步骤110中，扫描顺序相关性表。在步骤112中，如果判定在表中被列出，但是不具有相关性，则在步骤114中，判定针对封闭被标记。在步骤116中，如果表中存在另外的判定，则处理返回至步骤112。在步骤119中，如果不存在另外的判定，则执行检查以确定是否针对封闭标记任何(即，至少一个)判定(即，在该循环中步骤114被执行了零次)，以及在步骤120中如果针对封闭没有标记判定，则关闭顺序相关性表中的所有剩余的判定。在步骤119中，如果至少一个判定针对封闭被标记，则在步骤118中恢复中止的规则的执行。

虽然组合的前向链接和后向链接规则(具有否定)可能看起来相对简单，但是该特定组合不显著。如上所述，保险公司解决方案仅使用前向链接，而第五代计算机项目仅使用后向链接。在具有目标并且需要解决方案时，前向链接为数据或事件驱动而后向链接适于计算。前向链接预处理事实以产生推断，而后向链接寻求找到给定事实的最佳的解决方案。组合规则使得利用两种规则的能力。例如，在组合的规则的情况下，事实可以在不使用后向链接规则或前向链接规则自身的情况下应用于后向链接规则或前向链接规则。通过处理上述否定问题的处理引擎以这种方式组合规则尚未实现，并且结果极其有用，产生上述许多期望的特征。

为了利用上述规则引擎的实施例，现在需要理解关于规则的语法细节以及可以如何使用规则引擎的内容。在创建规则和事实时，事实形式化被表示为与零或更多的论据一起的判定符号。示例包括：

holiday

amount(170)

service(takeout)

location("Sundbyberg")

depends(margherita,basil)

这样的形式化的事实的意思依赖于预期的人为解释。该解释涉及关于以下的确定：针对如何将相关表述抽象成判定符号的正式或非正式词典以及局域或全局惯例。使用以上示例：

“holiday”可以指：今天是假期

“amount(170)”可以指：订单量为170货币单位

“service(takeout)”可以指：顾客拾取所准备的进餐以在其他地方进行消费

“location(“Sundbyberg”)”可以指：Sundbyberg为顾客想要预定的物品被传送到的位置

“depends(margherita,basil)”可以指：依赖于新鲜罗勒叶的可用性的玛格丽特披萨。

判定符号未被限制为字母字符串。可以通过使用分离词语的下划线字符或者通过将整个串放入单引号或双引号中来使用描述性字符串：

delivery_location_is("Sundbyberg")

"todayisaholiday"

'pizzatypedependsonfreshavailabilityof'(margherita,basil)

这有时候可以致力于增大清晰性，但另外的代码膨胀和抽象化的损失可以容易地否定所有的积极效果。在最后，这为程序员最终负责的判断。

判定的论据表示对应的事实为“正在讨论”的对象。例如，事实amount(170)表示关于数目170的内容，即，其为订单的量。并且，事实depends(margherita，Basil)表示关于披萨类型为玛格丽特并且香草为罗勒叶的内容。形式逻辑不真正关心符号玛格丽特或罗勒叶的意思，并且其最纯的形式逻辑自身甚至不关心170的意思。170为普通数字的想法仅为许多可能的解释中之一。纯形式逻辑自身关注的唯一事件为真理的各种表示如何与真理的其他表示相关，其中，基本真理认为是描述经验观察的公理或条件真理。因此，所有的对象被简单地表示为抽象符号或者表示为符号常量(原项)或者其他对象表示的函数。在法国数学家雅克·埃尔布朗(JacquesHerbrand)在1920年代发现对象的该抽象表示之后，该对象的该抽象表示已知为“埃尔布朗项”。

以递归的形式定义一组埃尔布朗项：

1.任何常量符号为埃尔布朗项。示例：foo，x，42，-3.14，“Iamthewalrus”。

2.应用于一组埃尔布朗项列表的函数符号也为埃尔布朗项。示例：foo(bar)，f(a,b,c)，f(g(a,f(b),c))。

函数符号和常量符号与判定符号(如在先前的部分中描述)具有相同的语法。请注意，以大写字母或下划线开始的符号被理解为逻辑变量，所以这样的名称不能用于常量符号、函数符号或判断符号，除非其被引用。

从编程方面而言，具有论据的混合埃尔布朗项可以被看做针对通用数据结构的构造器、在其他类型的语言中共用的类型的同构。还应当注意，零论据判断仅为从逻辑视角的原命题。即使这样的命题通常讨论一些语义解释中的对象，但是该情形在形式语境中完全不可见，并且在本语境中，该命题用于所有的不透明的意图和目的。仅涉及零论据判定而不涉及其他的判定逻辑完全等同于命题运算。

可以使用运算符记号代替正常的函数记号来书写一些事实、规则和项，例如，xopy代替op(x,y)，或者opx代替op(x)。这是纯语法修饰(sugar)而与其是什么无关，只要语法相关即可。例如，埃尔布朗项sqrt(3**2+4**2)除表面语法之外完全等同于埃尔布朗项sqrt('+'('**'(3,2),'**'(4,2)))。

所有的运算符符号被预定义，并且其名称和优先关系可以在以下找到。内部运算符符号使得易于以正常表达的方式书写算术公式。然而，在纯判定逻辑中，不存在这样的公式的自动解释。对算术公式的评估仅在判定中内部的特定组的“arithmeticaware”中发生：eval，<，等等。并且，合一判定‘＝’仅与埃尔布朗项的结构有关，由于‘+’(2,2)和4为两个明显不同的埃尔布朗项，所以例如2+2＝4实际为假。然而，由于eval将算术表达式映射至数字值，所以eval(2+2,4)为真。

使用纯判定逻辑来表示规则。技术上说，由称为超过埃尔布朗项的域的第一阶霍恩从句的逻辑语句的形式来表示规则。这意味着每个规则具有良好地定义的且独立于任何特定规则引擎实现或任何特定编码的逻辑解释。还意味着规则引擎的调用可以永远不具有副作用，并且规则中的所有的表达式具有参照透明性。

使用第一阶逻辑和霍恩从句的原因在于，该组合使得规则解析度在数学上和计算上易处理。针对第一阶霍恩从句存在有效的证明算法，并且已知的是，存命题的霍恩从句可以在多项式时间中证明。纯霍恩从句模型随着否定-为-失败以及if-else-logic扩展，并且还存在其第一阶解释仅可以理解为无穷公理方案的许多内部判定。然而，这些扩展均不具有以任何形式从纯逻辑导出的语义。

如上所述，存在由本规则引擎的实施例使用的两种通用推理方法：前向链接和后向链接。在前向链接中，规则引擎以基本事实集开始，然后查找具有匹配那些事实的条件的规则，以及根据规则进行推断。然后，将这些推断用作新事实，并且重复处理，直到没有新的推断产生为止，或者直到一些规则推断为假为止，这表示逻辑冲突。在后向链接中，规则引擎以查询开始，被表示为可以包含变量的判定。该判定被假设为基本事实或者根据规则的推断，并且然后规则引擎查找在什么条件下该判定为真。如果判定与一个或更多个事实匹配，则这些事实继续对查询进行回答。如果判定与根据规则的推断匹配，则针对该规则的每个条件被认为是后向链接查询，并且调用规则的对查询的回答将为所有的条件共用的解决方案集。本文中所描述的语言通过使用针对特定判定指定使用哪种方法的记号来提供对前向链接和后向链接的支持。每个判定由前向链接规则或后向链接规则指定，并且这些在语法上不同。还存在第三种类型的判定：由基础事实集指定的事实判定。

以要定义的判定在右侧并且条件在左侧的形式书写前向链接规则，如下：

ifaquatic(X)andhasGills(X)thenfish(X)；

ifmudskipper(X)thenfish(X)；

或者，替选地，可以如以下那样使用隐含符号(“＝>”)：

aquatic(X),hasGills(X)＝>fish(X)；

mudskipper(X)＝>fish(X)；

如果以上定义fish/1(即，以fish命名的具有一个论据的判定)处于基础事实aquatic(nemo)和hasGills(nemo)为真的语境里，则前向链接将推断事实fish(nemo)并且将其添加至证明事实集。然后，将该新事实当做为其为基本事实，从而在如果出现任何这样的规则的条件下触发包含fish(X)的所有前向链接规则。

前向链接非常适用于可以由相对小的事实集描述的分类法(分类)。以上示例示出仅两个推断规则，但在更复杂的情形中，可以存在数千种分类规则。在这种情况下，前向链接确保执行次数正比于其条件仅包含小的事实出现的判定的规则的数目，而非规则的总数目。这与以下要描述的后向链接完全不同。

以要定义的判定在左侧并且条件在右侧的形式书写前向链接规则，如下：

connected(A):＝ifA＝romathentrue

elselink(A,B)andconnected(B)；

替选地，可以使用两个长箭头(“→”)从句来书写相同的判定定义，如下：

connected(roma)-->true；

connected(A)-->link(A,B),connected(B)；

判定connected/1针对网络中的连接至名称为roma的所有的节点为真。节点之间的直接联接被假设为基本事实，如下：

link(napoli,roma)；

link(firenze,roma)；

link(bologna,firenze)；

link(genova,firenze)；

link(milano,genova)；

link(milano,torino)；

link(venezia,bologna)；

为了回答查询connected(milano)，返回参照上述从句，后向链接将通过查询与connected/1的定义匹配开始。第一从句不匹配，因为roma和milano为两个不同的常量符号。但是，第二从句与A＝milano匹配，产生两个新的查询link(milano,B)和connected(B)。这些查询中的第一查询确定B的可能值，在这种情况下，B＝genova且B＝torino。这导致针对剩余的查询的两个替选：connected(genova)和connected(torino)。后向链接应用于这些替选查询中的两者，并且第一替选查询产生反之产生在connected/1的定义中与第一从句匹配的connected(roma)的connected(Firenze)，从而产生查询真，这结束证明的链接。

后向链接非常适于搜索和决策制定，并且在规则具有相对少的情况并且事实数目较大时特别有效。在以上示例中，添加数百万另外的link/2事实将完全不会影响针对原始查询的执行时间，只要查询的证明不需要这些另外的事实即可。这与前向链接完全不同，在前向链接中，所有的事实与规则匹配，而不管是否需要。

对于后向链接规则而言，定义的从句总是互相排斥。这是由于：对于每个从句而言，针对所有的先前的从句的所有的选择条件暗含被否定。与针对后向链接使用任意的霍恩从句的语言相比，这限制了语义。该设计的益处在以下相对于“确定-选择逻辑”的描述来进行阐述。

后向链接定义还用于计算值。例如，如果以上列出的联接事实被扩展成包括所联接的节点之间的距离，例如：

link(firenze,roma,300)；

link(genova,firenze,270)；

link(milano,genova,150)；

然后可以由以下判定来计算从另一节点至roma的距离：

distance(roma,X)-->X＝0；

distance(A,X)-->link(A,B,Y),distance(B,Z),X＝Y+Z；

将经由后向链接将查询distance(milano,X)的回答计算为distance(milano,150+270+300+0)。如上所述，X＝Y+Z不执行任何运算，其仅将埃尔布朗项合一。因此，所解决的针对X的值为混合项150+270+300+0而非符号常量720。为了计算下述，定义必须使用eval/2来对总和进行评估：

distance(roma,X)-->X＝0；

distance(A,X)-->link(A,B,Y),distance(B,Z),eval(Y+Z,X)；

可以针对相同的判定混合不同类型的定义。例如，如果foo/3具有后向链接规则，不可能也存在具有foo/3作为其结果的前向链接规则。

然而，可以使用后向链接查询中的前向链接判定，并且也可以将后向链接判定用作前向链接规则中的条件。第一情况为相对直接地：当做出所有的前向链接推断时，前向链接判定看起来像后向链接语境中的基本事实，并且可以以与使用基本事实相同的方式使用。

第二情况稍微更复杂。后向链接查询可以在前向链接规则的条件之间进行混合，例如以下：

departure(X),distance(X,Y)＝>travel(Y)；

假设基本事实为departure(milano)并且后向链接定义为distance/2，则该规则将经由后向链接计算Y，假设例如720，并且然后，使得如上所述的前向链接推断travel(720)与前向链接和后向链接的组合有关。

非确定为当规则的单个调用可以产生多于一个可能的回答时。例如，假设以下基本事实：

depends(margherita,basil)；

depends(margherita,tomatoes)；

depends(capricciosa,artichokes)；

查询depends(X,Y)将产生针对X和Y的值的三种组合：

X＝margherita,Y＝basil

X＝margherita,Y＝tomatoes

X＝capricciosa,Y＝artichokes

相似地，查询depends(margherita,X)产生针对X的两个值：

X＝basil

X＝tomatoes

另一方面，查询depends(capricciosa,X)具有单个独特的回答：X＝artichokes。并且查询depends(X,anchovies)没有回答。这样的情况称为确定性，原因在于不需要考虑替选结果。

进行非确定查询的能力是既有效又危险的。其有效是因为其使得易于表达依赖于两个或更多个事实之间的匹配的条件。例如规则：

supplies(Seller,Goods),demands(Buyer,Goods),licensed(Seller)＝>trade(Goods,Seller,Buyer)

根据规则的条件部分中的事实判定，该规则将商品的所有的授权卖家与被提供给商品的所有的买家匹配。针对找到的所有的匹配，产生trade/3事实集作为推断。所有这些由单行代码完成。危险部分在于，由于不期望的非确定所以非常易于误解地书写需要解决的难以控制的工作量的简单的规则——得到各自与更多个回答匹配的多个子查询回答，从而引起组合激增。该非确定的纠正为确定选择逻辑，以下进一步描述。

否定根据假从句做出真从句，并且假语句来自真语句。由于潜在的解决过程中的限制，所以在本文中仅以受限的格式支持否定。最明显的是，基本事实和推断可能永远不能被否定。其必须总为正。例如，下述书写为不合法的语法：

notmudskipper(nemo)；

hasGills(X)＝>notmammal(X)；

其他限制为：否定的证明可以从不对变量分配值，这有较好的理由。例如，假设一些条件包含作为其部分“notdepends(margherita,X)”中之一。这可以使用针对X的无穷数目的解在理论上被证明为真：

X＝anchovies

X＝3.14

X＝f(a,b)X＝f(a,f(a,b))

X＝"Iamthewalrus"

X＝f(a,f(a,f(a,b)))

...

但是这样做明显不实际，所以其中可以解决不为depends(margherita,X)的否定的唯一情形如下：

1.由条件的一些其他部分的证明对X分配值anchovies。由于不存在事实详述depends(margherita,anchovies)，所以否定被证明为真。

2.由条件的一些其他部分的证明对X分配值basil。由于存在事实详述depends(margherita,basil)，所以否定被证明为假。

3.不存在匹配depends(margherita,X)的事实。因此，否定针对所有X被证明为真，所以不需要分配值。

4.替代为事实，depends/2被定义为针对所有X为真的判定例如depends(margherita,X)-->true；因此，否定针对所有的X被证明为假，所以不需要分配值。

在所有其他情况下，将中止否定的证明。由于条件的一些其他部分为假，所以仍然可以证明包含否定的条件为假，但是依赖于为真的条件的任何证明也将被中止，可能导致针对顶级查询的中止的证明。

应当注意，否定事实有时候可以通过导入少量的另外的判定和规则来“仿真”。例如，如果规则使用事实判定accepted(X)，则另一判定not_accepted(X)可以被导入来表示否定情况。由于这在形式上为正事实，其可以在不受限制的情况下用于规则。为了避免解释中的不一致，可以添加以下形式的规则：

accepted(X)andnot_accepted(X)＝>false；

当推断为“假”时，证明异常中止并且冲突的检测被发送至嵌入应用程序。

可以将相同的技术扩展至处理集中排他的任何事实集，例如：

lights(red)andlights(yellow)andlights(green)＝>false；

如果左手条件为真，则会发送冲突错误。

确定选择逻辑为当由若干从句以条件中的至多一个条件可以同时为真的方式定义判定。例如，如果某物被归类成类别standard、gold或platinum中之一，依赖于事实good、better和best的真值。可以试验以下方式：

good＝>category(standard)；

better＝>category(gold)；

best＝>category(platinum)；

然而，如果例如good和better二者同时为真，则这将不能如期望的那样工作，原因在于将推断两个事实：category(standard)和category(gold)。由于仅期望这些中的第二个，所以需要更精确地确定条件，如下：

best＝>category(platinum)；

better,notbest＝>category(gold)；

good,notbetter,notbest＝>category(standard)；

现在，每个从句否定前述从句的条件。这可以比使用if-then-else语法的后向链接判定更易懂的方式来表示：

category(X):＝ifbestthenX＝platinum

elseifbetterthenX＝gold

elseifgoodthenX＝standard；

这示出"else"的逻辑意思：其为暗含地否定前述条件的连接。本文中所述的所有的后向链接判定经由"else"使用确定选择逻辑定义。这也适用于由"-->"语法定义的判定。以上示例看起来像以下箭头语法：

category(X):best-->X＝platinum；

category(X):better-->X＝gold；

category(X):good-->X＝standard；

在每个从句与下一个从句之间存在隐含"else"。冒号(":")与箭头("-->")之间的条件称为防护器。不试图解决从句中的剩余的部分(至箭头的右侧)，直到防护器被证明为真为止。

如果判定论据包含模式匹配项，则该模式匹配技术上也为防护器的一部分。如果不存在冒号限定的条件，则防护器仅包括论据模式匹配。

防护器的证明可以从不对防护器外部的变量分配值。例如，假设以下从句和基本事实：

security(X,Y):trusted(X)-->Y＝high；

security(X,Y)-->Y＝low；

trusted(alice)；

trusted(bob)；

逻辑上，security(P,low)针对与alice和bob不同的P的所有的值为真，但是这样的值不能以实际方式由证明产生，准确地说，与上述相对于否定的描述具有相同的原因。因此，保护器的证明被中止，并且作为结果，查询的回答为中止的证明，除非查询为其中由证明的一些其他部分对P分配值的一些较大的查询的一部分。

在一些情况下，防护器不能对外部变量分配值的限制可以通过引入在第一从句的防护器中自由的另外的变量来解决：

security(X,Y):trusted(Z)-->X＝ZandY＝high；

security(X,Y)-->Y＝low；

此处，在不对查询中的P分配任何值的情况下做出第一从句与第二从句之间的选择。如果选择第一从句，则可以经由X＝Z对P分配值，或者若干值非确定(例如，alice和bob)。但是语义改变：security(P,low)现在为真，只要trusted(Z)针对所有的Z为假，即，当不存在trusted/1事实时。当在这种情况下时，由于security(P,low)针对所有的P为真，所以不对P分配值。

总是使用后向链接中的确定选择逻辑的益处在于，确保通过在后向链接期间试验从句从不会引入非确定。非确定可以仍然经由事实查询发生，但是那些情况更易于预测和识别。使用事实查询还为书写其中不明确期望非确定的后向链接规则的推荐方式。前向链接不使用确定选择逻辑。由于在前向链接期间不以任何预测顺序测试从句条件，所以其将没有意义。

理论上，if-then-else不是实现确定选择的唯一的可能方式。另一可能性为N-wayexclusive-or，并且存在许多其他情况。然而，if-then-else对每个人而言是熟悉的，并且其优点在于，可以非常有效地实现证明算法。

“封闭世界假设”为未知或未证明的任何事情均为假的假设。该假设在规则和数据针对当前目的被定义为“完全”的形式语境中是合理的。例如，公司可以具有欠有公司的钱的债务人的记录。将每个人形式上处理为在公司债务人记录中未发现的非债务人是合理的，即使存在可能存在欠钱但是未被记录为债务人的人的可能性。在本实施例中，封闭世界假设需要用于证明否定真，以及(等同地)用于证明防护器假。不同的是，封闭世界假设没有不同。

由于否定和确定选择逻辑为有效的工具，所以针对所有的判定隐含地做出封闭世界假设，指定相反的假设。相反的假设称为“开放世界假设”并且本实施例给出特定说明，这可以用于免于封闭世界假设的判定。例如：

meta{open_world_assumptiona/1,b/0；}；

meta{open_world_assumptionc/2；}；

a(foo)；

c(foo,bar)；

e(foo)；

给定以上说明和事实，查询a(bar)和c(foo,baz)将会出现中止的证明，查询b由于不存在事实b也会出现类似情况，但是不会产生b为假的结论，这是因为事实为开放世界事实。另一方面，查询d将证明为假，如查询e(bar)一样。

仅事实和前向链接判定可以被声明为开放世界。后向链接判定总是封闭世界，原因在于其使用确定选择逻辑，其中，判定定义总是完全的。依照语法，开放世界声明由元语句标记，如示例中所示。元语句的完全列表可以在以下找到。

为了使得易于根据简单的部件构建复杂的系统，本规则引擎的规则语法具有针对名称空间的内部支持。每个符号实际上包括两个部件：名称空间前缀和本地名称。例如：

foo::bar

在以上示例中，名称空间前缀为foo并且本地名称为bar。当不给定名称空间时，提供隐含的名称空间。默认的隐含的名称空间为main，所以在以下情况下：

bar

符号bar将理解为main::bar。

可以通过将名称空间声明添加至以下代码来改变该隐含的名称空间：

meta{namespacefoo；}；

在该声明之后的任意提及的bar将理解为foo::bar。并且这同样适用于在名称空间声明之后提及的其他符号，例如baz。

但是也可以针对仅一个特定符号来改变隐含的名称空间。这通过“导入”以下说明完成：

meta{importfoo::bar；}；

在这种情况下，任何提及的bar将理解为foo::bar，但是除非一些其他名称空间已经由名称空间声明指定，所有其他符号将获得名称空间main。导入新的名称空间不需要特殊的声明。例如，如果书写asdfghj::some_symbol，则该符号将具有名称空间asdfghj，而不考虑是否在任何地方提及过“asdfghj”。但是存在在本文中以不同的方式处理的四种名称空间，如下：

当对私有名称空间进行命名时应当避免这四种名称空间标记。应当注意，导入仅为至应当对特定符号进行重命名的解析器的指令。如果用户想要使用针对判定定义的符号诸如eval，则不管eval被从core名称空间正常预先导入的事实，用户可以简要地书写：

meta{importmain::eval；}；

并且然后根据期望使用eval，因为这不会中断使用core::eval的任何代码。

基于逻辑的所有的软件具有其自身的特质限制，这由于设计构思以及实现相关的成本/益处折衷。但是还存在其他限制，这是逻辑本身固有的。这些限制从工程师视角来看是不可协商的，原因在于任何使用逻辑的工具会受这些限制的影响，由于其遵循数学逻辑的理论，包括：

1.第一阶判定逻辑为递归地不可判定，即，没有算法可以确定给定公式是真还是假。例外情况为当所有的判定被限制成讨论单个论据而非通用关系的属性。零论据情况(也称为命题逻辑)也为例外情况。

2.命题逻辑是可判定的，但是针对真值的解决方案为NP完全问题。

3.仅包括霍恩从句的命题逻辑为在多项式时间内可解决。

然而，霍恩从句仅可以表示所有可能的逻辑语句的子集。

在以上阐述中，第一限制简要地指第一阶判定逻辑太能够表达，使得其可以用于陈述不可能解决的问题。著名的示例为艾伦图灵停机问题(AlanTuring'shaltingproblem)：如果计算机在执行程序之后停机，则可以书写为真的逻辑公式，而如果程序一直循环，则可以书写为假的逻辑公式。但是不存在可以确定公式是真还是假的算法。第二限制意味着确定命题为真还是假的自由变化的公式组在理论上总是可以的，但是已知成本为的问题的尺寸(即，涉及事实和规则的总尺寸)的指数。第三限制为即使实际上可以使用合理的效率解决自由变化的霍恩从句；其也不如全部第一阶判定逻辑那样富于表达。

判定逻辑为关于要求“所有”或“一些”的命题例如“一些猫为黑色”或者“所有克里特岛人为说谎者”。后面的短语归因于大约公元前600年的克里特哲学家艾皮曼尼蒂斯。由于艾皮曼尼蒂斯自身为克里特岛人，这可以认为是逻辑矛盾的最早的示例中之一。形式上，判定为n个对象(判定论据)之间的关系，其中，n可以为0,1,2…并且判定在存在相关时为真，否则为假。判定逻辑中的命题通常包含量化变量，这意味着通过表明"forallX..."或者"thereexistsanXsuchthat..."并且然后以下命题中使用变量X来引入的变量。

第一阶判定逻辑(FOL)为其中量化变量仅可以用作判定论据并且从不用作自身判定的判定逻辑。所以，在第一阶逻辑中，可以表示“所有猫为黑色”，但是不可以表示“所以逻辑关系为真”。判定逻辑极其富有表达性，但是判定逻辑语句通常很难解决。已经证明，不可能存在能够证明FOL中的每个真(套套逻辑)命题的任何算法，除非所有的判定被约束为仅一个论据，即，其中不允许多边关系。

本规则引擎的实施例使用具有有效证明程序的FOL的子集。该子集已知为“霍恩从句”并且证明程序已知为“鲁滨孙决议”。针对本规则引擎书写的返回回答的每个程序确保具有逻辑语义，即，其可以根据来自任何这样的程序的任何回答或结论总是逻辑上正确的第一原理来证明。然而，存在其中不返回任何回答的情形。

本规则引擎的实施例中所使用的运算符按照程序的下降顺序在以下表中列出。右关联运算符示出为X·Y，而左关联运算符示出为Y·X。前缀运算符示出为·X或·Y；由于没有调用相关性，二者均是指同一事物。

右关联运算符如以下那样嵌套：

X·Y·Z＝X·(Y·Z)

并且左关联运算符如以下那样嵌套：

Z·Y·X＝(Z·Y)·X

运算符表：

？X

X^YX**Y\

X.YY*X

Y/XY//X

Y-X-XY+X+X

X＝YX<YX＝<YX<>YX＝＝YX>＝YX>Y

notX

Y&X

Y|X

XisY

X,Y

YandX

YorX

X->YY<-X

X＝>YY<＝X

X:＝Y:＝Y

X:-Y:-Y

X-->Y-->Y

本规则引擎的实施例还包括少量内部判定。这样的判定由规则引擎自身而不是由通过将决议算法应用于事实和规则来证明以进行评估。多数内部事物使用一个或更多个论据作为输入数据，并且可选地使用与一些计算输出数据合一的另一论据。如果输入数据为非绑定变量，则内部中止直到其获得确定值为止。这对于哪个论据被输入并且哪个被输出的大多数判定而言是非常明显的，所以此处不明确表述哪一个是哪个。

运算判定可以依赖于应用程序使用不同的鉴定机。默认的为基于"java.math.BigDecimal"的鉴定机。这意味着所有的数字值被表示为有限长度的任意精确地的十进制数。除非另外指出，根据"java.math.BigDecimal"的规则来完成计算期间的精确度的四舍五入。

这些判定对运算表达式进行求值：

算术表达式仅为具有特殊解释的埃尔布朗项。数值常量被解释为对应的数字值。其他项被根据以下表来理解。

符号常量：

Pi3.141592653589793,其为#至16数字准确性的值。

E2.718281828459045,其为e至16数字准确性的值。

一元函数：

二元函数：

本规则引擎的实施例具有用于书写包含外部参数的项的语法修饰。如果变量以$符号开始，则可以解释为经由内部判定访问的外部参数sys::param。例如：

ifexpiration_time(T)andT<$TIMEthenexpired；

以上等同于：

ifexpiration_time(T)andsys::param("TIME",X)andT<Xthenexpired；

其中，X为任何地方不发生的变量。

sys::param(X,Y)使Y与外部参数X的值合一。

sys::param的准确语义依赖于应用程序而变化。在处理引擎中，例如，当开始处理语句变换时的时间点处，存在由具有java.lang.System.getCurrentTimeMillis()的值的名称为TIMER的定时器产生的外部参数。另一方面，在单独的规则引擎中，sys::param被简单地定义为：

sys::param(X,Y):＝parameter(X,Y)；

其中，parameter(X,Y)由用户规则定义。

以下为测试或提取关于项的符号信息并且根据这样的信息创建新项的内部指令的列表。

简单的反射“调用”原始被添加至本规则引擎的实施例以用于实践目的。理论上，这为第一阶逻辑的第二阶扩展，但在实践中，其仅为用于反射编程的受限工具。仅为了方便目的——不提供使用规则的第一阶创建以直接但更详细的方式不能获得的任何功能。主要目的是提供表达否定的简单的方式。另一用途为允许从其他地方定义的规则回调至运行时间符号表。

两论据call(X,Y)为单个论据call(X)的“反柯里化”版本的种类。例如，call(p(A,B,C),[X,Y,Z])等同于call(p(A,B,C,X,Y,Z))。

如可以从其定义看出，判定不在其防护器内进行反射调用。这意味着例如not(hasFeathers(X))可以从不产生如X＝garfield或X＝fido的解。反之，其将被中止直到X获得可以测试的值为止。

如先前所注意，使用封闭世界假设来理解否定。该假设意味着如果所有的从句不能解决则该判定被认为为假。在可能解决判定的当前的规则设置外部可能不存在另外的从句。

作为德·摩根(DeMorgan)定理的应用的内部定义或者仅为摩根定理的应用的内部定义使用not的内部受限版本。这用于简单测试的语境，但是不处理引入成熟非确定的分离。处理通用情况的分离判定可以如以下那样定义：

然而，推荐的是，针对需要表示分离的所有的情况按常规使用这样的定义。原因在于，非确定既昂贵又不可预测，所以应当在其被使用的所有的环境中进行确认。

针对存在量化的语法修饰仅为方便目的，即，在需要存在的量化时通过引入另外的“helper”从句完全在没有语法修饰的情况下进行。注意，不存在针对通用量化的语法。通用量化为霍恩从句的针对包含在内部的所有的变量而言的最外级的隐含。由于霍恩从句的前项部分形式上包含在否定公式内，该通用量化完全等同于针对仅在前项中出现的变量的存在的量化。

Y^p(X,Y,Z)与p(X,Y,Z)相似但是Y存在被量化。技术上，p(X,Y,Z)经由反射调用被处理，除不允许书写例如T为约束至项的变量的Y^T之外。这没有意义，因为存在量化的变量Y的范围为词汇性的。

该从句的典型用途为当需要表示例如以下：“ifthereisadancerwhodoesnothaveapartner,then…”时，将会简单地排除诸如此类的事物以针对条件部分进行工作：

ifdancer(X)andnotpartners(X,Y)then...；

然而，本规则引擎将这解释为指“ifthereisadancerXandathingYsuchthatXandYarepartners,then…”，这在总体上完全不同。并且即使这有期望的意思，规则引擎从不证明该条件为真，原因在于需要其决议(resolution)算法来产生针对其条件为真的一些“thing”Y的至少一个示例，并且这是不可能的。

通过使用存在量化来固定问题：

ifdancer(X)andnotY^partners(X,Y)then...；

此处，意思是改变至“ifthereisadancerX,anditisnotthecasethatthereisathingYsuchthatXandYarepartners,then…”

这在语义上等同于其中引入另外的“helper”判定的以下解决方案：

has_a_partner(X):＝partners(X,Y)；

ifdancer(X)andnothas_a_partner(X)then...；

在该特定示例中，helper判定具有直观语义，但不总是如此。

在实施例中，基础时间坐标为Java的"timeMillis"，这大约为从1970年1月1日的00:00:00UTC起的毫秒的数目。大致有两个原因：计算机的时钟可能与UTC不完全一致，并且UTC使用未在时间坐标中计数的闰秒。截至2009年，从1970年起准确地增加了24闰秒，所以经过的毫秒的数目为高于标定时间坐标的24000。原子时间(TAI)可以通过使用另外的闰秒对UTC日期进行偏置并且然后在UTC与TAI之间的初始偏置的计数中添加10来导出。

sys::date混合项的论据与以下Java领域具有相同的值：

java.util.Calendar.YEAR

java.util.Calendar.MONTH

java.util.Calendar.DAY_OF_MONTH

java.util.Calendar.HOUR_OF_DAY

java.util.Calendar.MINUTE

java.util.Calendar.SECOND

java.util.Calendar.MILLISECOND

java.util.Calendar.ZONE_OFFSET

java.util.Calendar.DST_OFFSET

注意，Zone_offset和DST_offset以毫秒为单位，并且Year为4数字年。论据中剩余的与其POSIX等同方式准确地相似。Timezone论据应用于java.util.TimeZoneclass的时区ID中之一例如"Europe/Zurich"准确匹配。

Day_of_week在1至7的范围内，其中1为星期日。

Day_of_year针对1月1日为1。

ISO_8601_week_number为由ISO8601定义的星期数，其中，周1为包括1月4日的星期，并且星期日与星期一之间变化星期数发生改变。

这可以在语言内定义，但仅用于方便目的。

针对元语句的通用语法为：

meta{D1；D2；...；Dn；}；

其中，D_i为影响遵循文件中后者的规则和事实的解释的声明。以下说明可用，给出作为示例：

用于操作本规则引擎的系统的实施例的实现可以以不同数目的方式来实现。用于实现这样的系统的主要功能部件包括JAVAEE服务器，JAVAEE服务器包含规则引擎、用于规则定义和配置文件的文件库、SQL数据库、可选SSL反向代理以及负载平衡器。在开发环境中，不使用负载平衡器并且系统的所有的剩余部件在同一服务器上运行，但是不同的部件被移动至单独的机器并且被成功操作。要注意，文件库不需要为同质服务。不同类型的文件可以从例如安装文件系统、SQL数据库、网络服务(WebDAV或平面HTTP)、DROPBOX等不同的提供。然而，针对本公开的目的，文件服务器将被假定是基于SQL的网络服务器。

图2、图3、图4、图5A、图5B和图5C示出这些功能部件的不同的配置。图2示出基本高可用性架构200即可用区A202和可用区B204。区A202包括SQL主数据库206、文件库服务器208和JAVAEE服务器216，而区B204包括SQL副数据库212、文件库214和JAVAEE服务器216。负载平衡器218根据需要在两个区之间分配客户端和服务器需求220。

图3示出通过分片的扩展，其中，逻辑分片302中的每个逻辑分片与总处理集的子集对应。例如，逻辑分片k可以为PID＝k模式n的所有的处理，其中，PID为处理ID号。每个逻辑分片以相似的方式映射至物理分片304，虽然必须使用不同的算法来确保物理分片304的m可以在不改变较早的逻辑物理映射的情况下增大。从给定PID至物理分片的路线必须通过一些共享资源例如负载平衡器218来完成。

图4示出被称作通过碎片进行所谓的扩展，其中，“碎片”意在指由万维网(worldwideweb)实现的扩展的类型。在该实现中，仅共享的资源为与Web一样的根名称服务器DNS基础架构。每个域名服务客户端402诸如域名A404、域名B406、域名C408等与图3所示的分片的集群、图2所示的单个高可用性集群、一些其他种类的集群或者单个服务器对应。每个域名完全自主并且不存在除潜在网络路由和DNS决议系统中不可避免的一个之外的争论点。根据图4的架构调节利用本规则引擎的实施例的应用简要地需要将处理ID号概括为域名加上本地PID。

图5A、图5B和图5C示出三种不同的配置中的计算扩展。图5A示出并行前向链接，其中，输入事实502由事实聚合器504聚合并且组合的事实506被分配至并行CPU核508，这使得根据事实组合506推断并且基于这些推断采取行动。在本规则引擎的实施例中，这些动作是幂等并且独立于进行推断的顺序，这为规则引擎的规则的逻辑语义的结果。由于推断的顺序与最终结果无关，所有并行执行具有可能性。当然，针对应用的任何并行加速因子取决于该应用中的规则逻辑的结构。

图5B示出后向链接中的OR并行，后向链接采用通常为一个包括变量的声明510并且鉴于满足声明510的变量组来查找一个或更多个解。将语句分配至CPU核508的非确定管理器512概括PROLOG和其他顺序编程语言中找到的回溯的概念。在本规则引擎的实施例中，这样的解决方案与声明514的逻辑证明总是一致，这是规则引擎的规则的逻辑语义的结果。当后向链接探索多个可替选解决方案时，执行这些替选方案的顺序是无关的，原因在于满足“OR”语句的一个运算数的解完全独立于其他运算数的任何证明。这使得后向链接替选方案的并行计算成为可能。当然，针对应用的任何并行加速因数依赖于应用中的规则逻辑的结构。

图5C示出后向链接中的AND并行。当后向链接目标(证明的语句)包括具有两个子目标520的结合时，这两个子目标的证明可以同时执行，只要关于针对每个子目标的变量组的部分解彼此一致即可。当子目标彼此独立时，可以实现真并行执行。当子目标不独立时，通过共享逻辑变量来显示相关性。这些共享的逻辑变量可以用于同步子目标证明的同时执行(例如，通过同步管理器522)，同时根据需要改变并行执行。通常，针对应用的任何加速因子依赖于规则逻辑的结构。

虽然极其有效，但本规则引擎的实施例的逻辑编程语言和语法以及处理引擎——通常不考虑所使用的引擎的类型——的逻辑创建对于许多人而言复杂并且难以被容易地理解。虽然一些人可以学习如何使用规则引擎和处理引擎来书写将规则引擎和处理引擎有效地用于创建有用且可调节的应用程序的代码行，但是这样做需要大量时间并且趋于生成大变化结果。不同于试验教导大多数用户规则引擎的语言和语法以及图6所示的利用处理引擎的实施例的最有效的方式，利用规则书写器来将用户的特定期望写入至连同规则引擎和处理引擎一起操作的应用程序中。

规则书写器可以使得使用与特定端用途应用有关的预定义处理语句、动作、输入类型和输出类型来改变由规则书写器生成的标准规则模板，从而增强有用性和数据的处理。应用的类型可以包括针对同事合作的商务工作流、个人移动辅助应用以及如以下详细描述的其他应用。

为了进一步理解本实施例的总体逻辑应用系统，参照图6。总体系统600可以包括至少三个主要部，即输入部602、应用部604和处理部606，每个部可以包括以下将详细描述的许多元件。输入部602可以至少包括配置部608、规则书写器610和测试器612。参照图7进一步描述的配置部608可以至少包括配置器614、表单库616和数据提取器618。应用部604可以至少包括应用622、应用数据提取器624以及输出传递和呈现接口626。处理部606可以至少包括处理引擎630、规则引擎632和数据库634。

如图7所示，配置器614可以以各种不同的方式接收来自用户的输入数据。配置器614然后使用输入数据来指示规则书写器610产生至可以实现用户期望的应用的代码核。指示规则书写器610的方式和方法可以大大变化。在图7中示出可以对数据和方向格式化以指示规则书写器610的五个不同的选项，但是这些选项仅为示例，并且实施例不应当仅限于所示的示例。

包括用于以输入702、语句704、输出706和动作708的形式书写一个或更多个规则的指令的选项1意在用于想要使用规则引擎和处理引擎书写的应用进行什么动作的具有非常清晰的想法的用户。在选项1中，可能需要用户能够识别可以参与在操作期间进入的应用的不同的处理状态704、可以在那些状态704中的每个状态处接收的一个或更多个输入702、每个状态702的一个或更多个期望的输出706以及在每个状态702处进行的一个或更多个动作708的数目。选项1也可以需要用户能够识别动作708中的每个动作的一些逻辑方面例如上述前向连接或后向链接或者二者的组合。

例如，如果应用与关于新雇佣的雇佣者的信息的处理有关，则第一状态可以涉及作为输入接收的数据的评估例如确定是否接收到关于名称的所有请求的数据的雇佣者名称和动作，例如姓氏、名字以及中间名或指示雇佣者没有中间名的空输入。如果第一状态已经接收到所有请求的数据，则然后要进行的动作可能涉及批准名称或将名称转发至进行另外的动作——例如创建针对人力资源系统中的雇佣者的记录——的一个或更多个其他状态，只要还接收到一个或更多个其他需要的输入即可。相似地，如果没有批准名称，则采取的动作可能涉及将名称返回至针对校正的输入源。

应当注意，单个状态可以具有与该状态关联的多个输入、多个输出和多个动作。在选项1中，用户可以能够以下述方式至少一定程度的限制要进行的动作的性质：使得规则书写器针对指定状态易于起草一个或多个合适的规则。例如，如果用户能够识别出输入为在前向链接处理中可以使用的事实，则用户可以以这种方式识别动作。同样，如果用户能够识别输入为可以在后向链接处理中使用的查询，则用户可以以该方式识别动作。一些动作将其自身添加至用户不可以识别的前向链接处理和后向链接处理二者，所以规则书写器110包括访问用户输入指令并且基于这样输入指令开发适当的有效规则的能力。

选项2针对以下用户设计：不想识别所有需要的指令或者能够这样做并且期望做出与用户偏好的可以进行大多数用户期望的事情的标准指令710有关的一些妥协。标准指令可以结合至与数据一起存在的表单中，其中，每个输入与可以基于该数据采取的标准动作对应。返回至上述新的雇佣者处理示例，鉴于选项1，表单可以已经存在于表单库712中，表单库712包括在用户想要用来处理其拥有的雇佣者的大多数而不是所有的指令。如果用户完全期望对用户从表单想要的进行妥协，则用户可以准确地接收标准表单。另一方面，如果存在用户想要删除的一些指令，因为这些指令不再需要，或者用户想要改变表单上的特定位置处的数据的名称或类型，则用户可以使用基本编辑元件714来进行至标准表单的适度修改，例如上述那些变化。

如图6和图7二者所示，除要利用的表单为由用户放入至图6所示的表单库616中的用户生成的表单的情况下，选项3被设计成与选项2相似，其中，其可以由数据提取器618处理。为了处理用户生成的表单中的数据，数据提取器61可以将用户表单720上的每个对象或领域包括图形对象例如单选按钮、线、文本框灯的位置以及可以与这些图形对象例如号码、文本、颜色等关联的其他信息确定和映射至由系统合适的生成针对规则书写器610的指令的系统所需要的表单中。然后，可以需要用户识别722在格式化表单上存在的数据，即表单表示上的不同的图形对象和文本以及基于这样的数据要进行的动作。

虽然用于接收针对系统的指令而产生第一格式中的一些可以限于由系统600的运算符随时间产生的表单，用户将开发可以重新使用或者期望与其他团体共享、在开放源类型环境724中免费或者在共享类型环境中收取少量费用的特定形式(选项4)。所设计的表单也可以以与针对移动装置的应用相同的方式购买，其中，开发者被鼓励开发单独的自定义格式726(选项5)，其以合适的价格出售并且通过购买量来奖励。

用于将数据输入至规则书写器的其他实施例也是可能的，所以本文中所描述的少量实施例不意在成为用于使没有规则书写能力的人书写规则的所有可能实施例的限制。例如，可以以普通的英语书写规则，并且规则代码可以将普通英语自动翻译成规则代码。在实施例中，使用针对规则执行的对话说明语言的翻译器。DSL包括用于控制计算机的任何类型的编码方案，其中，该编码方案不是通用编程语言。为了从规则授权系统(使用其他语言例如英语文本)生成针对规则引擎的规则代码，DSL可以由具有以下通用格式的自定义XML文件来定义：

以上格式包括由<macro>元素的序列跟随的<symbol>的序列。每个符号元素包括与指定符号分类的属性一起的词语或短语。例如：

<symbolclass＝”color”>green</symbol>

<symbolclass＝”color”>red</symbol>

<symbolclass＝”device”>light</symbol>

<symbolclass＝”vehicle”>car</symbol>

<symbolclass＝”state”>moving</symbol>

<symbolclass＝”state”>still</symbol>

每个宏指令元素包括<template>元素和<rules>元素。这些模板与规则之间的关系通过以下示例得到最好的解释：

为了示出上述宏指令翻译器如何对以普通英语表示的几个规则进行工作，考虑以下语句：

Ifthelightisgreen,thenthecarmustbemoving.

Ifthelightisred,thenthecarmustbestill.

所翻译的结果将会遵循以下两个规则：

light(green),car(Index,X),notX＝moving＝>fail(Index,car,moving)；

light(red),care(Index,X),notX＝still＝>fail(Index,car,still)；

由于英语文本(宏指令模板)中的词语“mustbe”逻辑上为道义运算符，其不能以标准第一阶逻辑的形式直接表示。反之，宏指令将词语翻译成隐含“fail”结果的规则前项中的否定条件。这样的推断“fail”的存在意味着对应的服从规则被违反。还应当注意，规则引擎代码包括在宏指令模板中没有直接的副本的两个逻辑变量即Index和X。Index处于将索引分配至每个车辆的隐藏数据模型的实际部分的情况。这使得规则引擎规则同时处理多个车辆。该索引在“fail”结果中重复，所以可能准确地识别哪些车违反规则。X仅为车辆状态的占位符(例如，“moving”或“still”)，这需要其自身变量以用于使否定起作用。如果不存在索引变量，则可以将

car(X),notX＝moving

简化成

notcar(moving)

然而，如果规则被书写为“notcar(Index,moving)”，除非Index被限制在否定之外或者在内部存在量词化，则其不起作用。然而，后者会将意思改变成如果绿灯亮则至少一个车辆移动。

特殊语法允许在相同的宏指令模板中存在一个或更多个符号的实例。例如：

将该宏指令应用于：

IfOprahisrichandfamous,sheisacelebrity.

将产生该规则：

rich(“Oprah”),famous(“Oprah”)＝>celebrity(“Oprah”)；

替代包括可应用于任何之处的变量，该规则由于其为针对Oprah的硬连线，但是其传递翻译的基本思想。如下那样生成逻辑变量：

根据惯例，以大写字母开始的模板参数将用作规则生成中的逻辑变量。在本示例中，将“X1”至“X6”用作变量。

如以下那样将以上宏指令应用于一些英语文本：

Ifthefirstpersonistheparentofthesecondperson,

andthefirstpersonistheparentofthethirdperson,

thenthesecondpersonisthesiblingofthethirdperson.

将产生以下规则：

parent(A,B),parent(A,C)＝>sibling(B,C)；

在这种情况下，宏指令中的“X1”和“X3”二者被映射至“thefirstperson”，但是在生成的规则中，“X1”和“X3”二者被所生成的变量名称“A”替代。以相同的方式处理剩余的变量。由于存在对规则引擎中的语法的限制，所以针对逻辑变量生成新的名称，所以可以将“thefirstperson”直接用作变量名称。由于逻辑变量的语法限于单个规则从句，不需要使所生成的变量的名称保持唯一，除非在每个规则中。

可以针对不同的规则使用相同的宏指令，例如：

Ifthefirstpersonisthechildofthesecondperson,

andthesecondpersonisthechildofthethirdperson,

thenthethirdpersonisthegrandparentofthefirstperson.

宏指令现在将产生：

child(A,B),child(B,C)＝>grandparent(C,A)；

列表或简单的列举在各种类型的妥协规则中不共用。这样的列表可以被映射至规则引擎事实或规则的表中，例如：

将该宏指令应用于两个输入：

WhenthecolorspaceisRGB,theprimarycolorsarered,green,andblue.

WhenthecolorspaceisCMYK,theprimarycolorsarecyan,magenta,yellow,orblack.

将产生以下规则引擎代码：

space(“RGB”),“RGB”(C)＝>primary(C)；

“RGB”(red)；

“RGB”(green)；

“RGB”(blue)；

space(“CMYK”),“CMYK”(C)＝>primary(C)；

“CMYK”(cyan)；

“CMYK”(magenta)；

“CMYK”(yellow)；

“CMYK”(black)；

注意，模板中的列举可以在最后的元素之前可选地使用“and”或“or”。这仅为大致风格；由规则生成器以相同的方式准确地处理列表。

从实现方面而言，至少是现在，包括符号和宏指令定义的XML文件可能需要程序员手动编码。然后，这些XML文件可以组合成一起定义域名说明语言的“构建框”。这可以在不同的构建框使得能够包括的GUI中完成。然后，相同的GUI可以使得规则作者通过选择和引入来自各种菜单和文本输入领域的模板和符号以域名说明语言的方式构成规则。然后，产生的DSL规则被处理为规则生成器的输入以产生作为输出的可执行规则引擎。

处理进行一次仅处理一个输入DSL并且将其与每个宏指令的模板匹配。所匹配的模板参数然后根据上述原理在宏指令的规则部中被取代。如果发现至少一个成功的匹配，与所发现的最后的匹配对应的规则被添加至输出。可选地，如果发现多于一个成功的匹配，则还给出警告。如果没有发现成功的匹配，则针对DSL规则给出错误的消息并且翻译中断。匹配处理使用查找作为输入中的图案的模板的传统的回溯算法，同时保持所产生的模板参数的约束的轨迹。

图8还示出图6的数据库634和处理引擎630。控制器802调节应用622与处理部606之间以及数据库634与规则引擎632之间的交互。控制器还处理经由消息消费者804和消息产生者806发送至处理部606或从处理表606发送的消息的处理以及通过定时器808的处理部606中的操作的定时。数据库634包括许多单独的数据部，包括用于由规则引擎实现的规则的规则存储810、时间调度消息812、处理状态存储814以及处理注册表816。

图9示出规则引擎632的实现实施例的细节，其中，由绕所述功能的实线示出功能部并且由虚线示出存储区域(存储在数据库634中)。规则和事实被输入至规则引擎632并且被路由至针对规则的解析器902，和针对事实的事实加载器904。然后，解析的规则被存储在事实项存储706中以用于前向链接执行器708或后向链接执行器710，或者组合时用于二者。解析的规则还相似地存储在解析的规则存储712中以用于输入至前向链接执行器708或后向链接执行器710。由符号表714提供符号。由于由后向链接执行器710执行规则和事实，证明或中止的证明存储在证明树716或证明树分离器720中，并且由于分离的规则被证明，所以项被项合一器722重新组合。规则引擎的逻辑分析的结果被从后向链接执行器710输出。

虽然以上参照应用的一些示例，理论上不限于其中在应用环境中实现规则引擎的方式。如图10所示，可以在实施例中配置具有输入1004(可以为一个或更多个任何已知数据输入形式，例如键盘、图形用户接口等)、存储1006(非易失)和输出1008(也为任何形式)的任何应用1002以与图6以及参考中所描述的处理部606进行通信。如先前所描述，应用1002、输入1004、存储1006、输出1008以及处理部606中的各种元件可以在物理上共同放置，每个元件可以物理上位于不同的位置，或者可以做出各种组合。例如，应用1002可以在通过移动装置以及其他源例如通过蜂窝、WIFI和其他网络、红外扫描等接收来自用户的输入的移动装置上操作，将信息存储在移动装置上或云存储上，通过云与处理部606通信，其中，这些逻辑元件在相同的远程定位服务器上操作，并且通过网络将数据输出至移动装置或一些其他装置。

图11示出应用1002和处理部606之间的基础通信的实施例。在步骤1102中，应用1002接收来自用户和/或其他源的输入，这可以以要由应用1002实现的事实或规则的形式。在步骤1104中，应用1002可以将消息或多于一个的消息发送至具有规则的处理部606，如果可以，事实包可以应用于由处理部606的规则引擎632实现的规则。在步骤1006中，处理部606鉴于事实包对一个或更多个规则进行求值并且将基于规则的响应发送至应用以用于进一步处理。如先前所述，由处理部处理的规则可以涉及前向链接、后向链接或者其组合。在步骤1108中，应用1002处理响应并且根据响应将另外的消息或者消息发送至处理部606，或者将数据发送至输出以用于用户和/或其他源使用。

与处理部606一起使用的应用的一个示例涉及值班时间控制。许多不同的占用对可以一次值班或者许多天值班或每星期或每月等值班的时间特定类型的人的数量进行调节。医院可以使用值班时间控制应用来调节医生、护士及其他患者护理提供者的小时数，政府实体可以使用值班时间控制来调节——例如在军队中、空中交通控制等或其他企业例如其中需要控制不同的工作人员一段时间可以进行的飞行时间量(或者其他占用)的航空公司中的——特定雇佣者一次可以工作的时间量。当仅存在经受这样的调节的少量个体时，针对工作人员的确定方案可以相对简单，但是当数千工作人员存在于许多不同的时区中每天二十四小时在不同的飞机中飞经世界时，规划并且适当地控制工作人员的值班时间会变得非常复杂；这完全可以由根据本实施例的规则引擎的能力来实现。

以下将描述用于示出本规则引擎的实施例怎样用于数据输入、屏幕配置、认证和其他目的的针对航空公司的值班时间控制应用。例如，与图形用户接口(GUI)一起使用并且取决于数据模型的简单的数据输入确认规则可以如以下那样书写：

data(crew_person,I,P)anddata(crew_person,J,P)andnotI＝J＝>output(default,invalid(crew_person,"Thiscrewmemberisalreadyspecified"))；

在已经输入所有的数据之后，停止语句中使用的另一数据输入确定规则如下：

data(crew_function,_,"CMDR")＝>commander_assigned；

data(crew_function,_,"COPI")andnotcommander_assigned

＝>output(default,invalid("FS2","Aco-pilotmaynotbeassignedwithoutalsoassigningacommander"))；

确定错误与任何单个输入字段不关联，由于可以以任何顺序输入工作人员数目，例如，允许在输入指挥官之前输入副驾驶员。但是具有副驾驶员的签字而没有指挥官会产生确认错误。

接着描述屏幕配置示例。在该示例中，在相同的GUI数据输入屏幕中的复制按钮针对返回航班的离开机场和到达机场填入默认值，使用以下这些值：

copy(X)anddata(X,Y)＝>default(data(X,Y))；

data(arrival,X)＝>default(data(departure,X))；

data(departure,X)＝>default(data(arrival,X))；

认证规则示例可以如以下那样书写：

view(movements)＝>allow(all)；

view(nonflight_activities)＝>allow(all)；

view(aeroplanes)＝>allow(read)；

role(postholder)＝>allow(all)；

allow(all)＝>allow(read),allow(write),allow(signoff)；

allow(X)＝>output(default,allow(X))；

这些规则为由具有作为输入的用户角色和页面视图标识符的GUI代码(JAVA网络应用)调用的规则引擎的非持续处理的一部分，并且规则引擎输出消息针对该页面上的用户返回一组认证操作。虽然在一些情形中存在可能使得更期望避免该技术并且使用简单的能力标记来替代的性能关系，但是当需要对认证进行这种灵活控制时，本规则引擎可以容易地提供。由于规则引擎的说明语义，规则引擎甚至允许未信任的用户上传用于处理个人数据的规则，因为没有可以妥协剩余的系统的安全性的运行这样的规则的方式。

使用本规则引擎的实施例可以实现的更精密的GUI应用包括对单个用户点击起作用的处理并且重新配置基于规则的GUI屏幕、当前的处理状态以及来自其他处理的可选消息。

以下示出集成/配置工具的另外的示例。例示的示例描述了其中输入消息"generate_draft"使得配置草案生成器服务(借款同意应用的插件)的规则引擎处理创建所请求的文档的借款同意应用。通过将消息发送至非规则引擎处理“application”来进行配置，在这种情况下，这为插件的一部分。规则代码如以下：

除其关于配置或集成之外，证明来自规则引擎证明的能力的另一示例与系统编程示例更相似。在本示例中，规则引擎规则实现时间调度器，在上述值班时间应用中使用该时间调度器来针对每个工作人员周期地更新当前累积的值班时间和航班值班小时数：

以上规则代码线实现由UNIX“corn”服务所使用的Franta-Maly离散事件的版本，这用于时间调度批量工作。由“corn”使用的工作表由此处未示出的另外的线25实现。反之，UNIXcron由约5,000个C代码线来实现。因此，规则引擎减少由100的因数进行相同的任务所需要的代码量。

现在将描述利用规则引擎的文档分析应用的实施例。该应用运行针对规则引擎的代码并且使得用户能够设置其中文档可以放置在云环境中的DROPBOX类型计数，并且然后分析确定应当怎样基于规则代码处理每个文档。文档可以为具有与其关联的信息的任何类型，例如文字处理文档、相片、电子邮件、文本消息、花费报告等，但是没有应当如何处理该信息的指令。

当文档位于将工作流与文档关联的位置中时，将会建立用于处理包括在文档中的信息的逻辑规则的工作流。也可以添加学习功能，使得用户动作随时间被学习并且工作流被修改，或者用户被给出有用于修改工作流的选项，以便调节用户动作。该类型的文档分析应用可以由移动应用、商业应用或者每天简单的自动活动例如与朋友用餐、旅行计划等来实现。应用将办公室和/或家庭中的替代电子邮件的无效用途的收信/发信的概念有效地调节成“getthingsdone”。不同于描述实现应用所需要的规则代码，将描述应用的工作流，要理解，该领域普通技术人员能够基于本文中所描述的工作流的逻辑创建使用以上提供的语法来实现规则代码。

现在参照图12，在步骤1202中，当用户将文档的副本投入至用户桌面上的应用文件夹中时，在步骤1204中，文档被自定复制到被分配至应用服务器上的用户的对应的文件夹。在步骤1206中，当文档到达服务器时，动作被自动触发以运行文档及其内容中可见的一些JAVA代码，并且调用对对文档进行分类的规则代码中的规则集。在步骤1208中，基于来自分类规则的输出，然后，JAVA代码将文档从用户的桌面上的应用文件夹移动至另一文件夹并且删除副本。在步骤1210中，然后，JAVA代码将消息发送至处理引擎的“handler”处理，以识别处理机处理或者针对所识别的文档的分类控制要实现的流处理。理想地，针对每个不同类型的处理存在处理文档所需要识别的单个处理机处理。当文档已经被处理部606至少初始地处理时，基于规则的响应被从开始一些工作流的规则引擎/处理部输出。例如，在商用应用中，除非具有相同名称的文档已经与有效工作流处理关联，可以存在针对所接收的文档开始新的工作流处理的费用报告。当已经调用处理机时，处理文档中的信息的下一个步骤取决于特定处理机、所识别的工作流处理以及这样的处理的可能性输出。

例如，来自朋友的建议在特定日期和时间用餐的电子邮件可以被用户放入特定桌面文件夹以用于根据由用于在用户的日历上创建在该日期的该时刻用餐的日历事件的规则集生成的各种规则集和工作流进行处理，而单独的工作流访问针对喜爱的餐馆的网站并且试图计划该日期该时间针对两个人的预定。当做出预定时，由不同的规则集处理确认并且可以生成工作流，所以副本被发送至朋友并且副本存储在用户针对使用合适的标识符创建的文件夹中，所以用户随后可以根据需要找到该确认。取决于规则集，可以生成其他工作流，例如针对该夜晚的车辆或轿车的预定，消息会被发送至用户以确认该夜晚是否具有其他特殊请求例如预定鲜花、需要从干洗店取回外套等。建立的规则和工作流的数目和类型是无穷的，但是可能针对大多数人具有一些实际限制，并且如果用户不想要遵循相同的处理，则用户开始不将电子邮件投至桌面文件夹或者可能将其投至自动应用不同的规则集的不同的文件夹。

在许多其他语境例如上述飞行调度应用、值班时间控制应用(具有或不具有时间调度)和借款处理示例中可以使用图12所示的个人或商业生产用途的相同类型的处理。鉴于后者，在借款处理中，例如针对房屋购买，通常存在从贷款申请接收、由资产出借人生成并且从其他源获得的受限制的文档集。贷款申请、申请者财政报告、关于房屋的信息、县记录、信用卡利率报告等可以全部被投放至用于处理的一个或更多个文件夹并且经受与上述相似的处理。例如，将分析借出应用以确保提供所有请求的信息，并且如果否，则生成工作流以获得任何缺少的信息。当采集所有的信息时，将分析所有的内容以确定申请者的信息是否在借款的大小、类型和期限、财产值、购买价格、下限支付等的指定范围内。同时，以相似的方式分析其他文档，以确保满足一切规则，并且将基于是否满足这样的规则产生合适的工作流。最后，将会生成指示申请者是否满足借款、是否存在允许申请者符合标准要解决的问题或者申请者是否被拒绝并不符合标准的响应。

进行处理机处理之后的实施例的示例为其中JAVA程序调用针对接收处理通道指示器P和输入数据项(事实)集的规则引擎库的包装器。P被解析成包括提及的一些规则代码(规则和事实)和表示当前处理状态的项的集的数据库输入。并且以下将进一步描述使用以下动作进行随后的项与第一输入数据项以及顶层控制流的混合：针对其output(C,X)为真的每个C，X，消息input(P,X)被发送至由C指定的处理引擎处理。针对其occlude(Y)为真的每个Y，项Y从处理状态中删除。然后，针对persist(Z)为真的每个Z，项Z被添加至处理状态。消息发送和数据库更新(ifany)被实现为单个JAVAEE事务。

在另一实例中，除通道指示器和输入数据项(事实)以消息的形式被发送至处理调用的异步JAVAEE夹之外，可以以与上述针对同步控制流相同的方式实现异步控制流，并且以与消息接收相同的事务进行产生的事务。来自output(default,X)的任何结果在这种情况下被丢弃。

顶层控制流处理涉及使得调用规则引擎库的JAVA程序，提供包括规则代码(规则和事实)和输入数据项(事实)作为论据。输出为包括X的项集使得output(default,X)为真的项的集。如果没发生意外，则该集确保包括有给定规则和事实以及输入项事实需要的最大的这样的集。规则代码文本字符串可以包括具有其他规则代码模块的指令，存储该指令以增大效率。规则代码包括以不同的方式处理的三种语句：

1.前向链接规则

2.后向链接规则

3.事实

如以下进一步描述，通过第一次应用前向链接规则进行顶层调用，并且然后，对所产生的程序状态应用后向链接规则。

通过作出所有的给定事实(包括在代码中的那些以及被提供为作为输入的那些)的列表来应用前向链接规则。每个事实被从列表移除并且应用于包括匹配该事实的条件的每个前向链接规则。然后，执行该规则。如果规则产生已经不包括在事实集中的推断，则该推断被添加至事实集以及列表的端部。如上针对图1所述，前向链接规则也可以与后向链接规则的执行组合。

后向链接控制流涉及被提供为输入的目标项、包括逻辑变量的可能性。如果存在匹配该目标项的后向链接规则，则应用后向链接确定控制流。如果后向链接确定控制流算法在不将任何选择留在证明树中的情况下终止，则返回针对目标项的单个解决方案。否则，进行后向链接非确定控制流。

作为初始步骤，后向链接确定控制流涉及针对在规则中出现的每个逻辑变量创建具有位置的环境记录。将规则头中的所有的变量与目标中的对应的项合一。如果任何合一导致新创建的环境记录外部的任何变量的捆绑，则中止该目标的执行并且替代在目标堆叠上试验下一个目标。如果联合成功没有中止，则将规则保护器(ifany)中的所有条件投放至目标堆叠上并且对其应用初始步骤。

如果事实而非后向链接规则匹配，则如果仅一个可能事实匹配则解决目标。否则，目标被标记为证明树中未解决的非确定选择，并且目标如在初始步骤中那样被中止。

如果内部判定匹配，则调用对应的JAVA代码。

如果联合失败，则投放当前的环境记录并且从if-then-else查找下一个候选者(ifany)并且重复初始步骤。

当已经解决规则保护器(空保护器总是被解决)，规则本体被下述提交：

1.从候选者除去“else”规则；

2.将当前的环境记录与起源环境混合；以及

3.将规则本体的目标投放至目标堆上。

在归属于中止的目标的逻辑变量被再次合一(由于出现在多个地方)的任何时刻，中止的目标被放置在证明树中的“wakelist”上，所以其可以在初始步骤中被重新处理。

后向链接非确定控制流涉及查找证明树(第一深度)中的未解决的选择，并且将整个证明树分离成该选择的包括第一替选的T以及表示剩余替选的包括连续选择对象的T’。然后，处理继续T中的确定控制流程的初始步骤，并且然后T’中的确定控制流程的初始步骤(也可以并行完成)。

鉴于上述，词语“matching”具有埃尔布朗项的鲁滨孙联合(可能包括变量)的特定意思。鲁滨逊联合的“occurcheck”由于性能原因而未完成。反之，对嵌套的埃尔布朗项的深度强加限制，使得合一过度地嵌套的项的试验引起例外情况。由于发生检查而涉及联合失败的任何情形将反之产生例外情况。

可以结合本文中所描述的处理部(即，处理引擎、数据库和规则引擎)操作的另一类型的应用可以涉及与核心射频管理、开发、测试、性能分析和产品确认关联的各个阶段。例如，在特定类型的电子产品的开发期间，存在必须遵循的特定已知步骤，而不考虑与产品关联的设计或者甚至特性。已知规则可以具有与其关联建立的规则集以及基于规则引擎的基于规则的输出所遵循的工作流。然后，这些规则集和工作流可以被编程为企业的内部产品开发系统或者系统可以被编程为使得调用或请求接收用于处理部的处理的文档或数据的单独的系统。例如，在产品的设计或概念化期间，工程师可以上传与正在开发的产品的一些方面关联的模拟数据，并且在处理部接收该数据时，可以生成使得基于发送至用于审批的管理者的包括的模拟数据和副本来生成报告的工作流。如果在处理模拟数据时，确定模型数据与指定数据或测量的数据不十分相关，则然后可能生成警告管理者、查询设计项的可用方案以及在W时刻自动设置会议室Z中的会议的不同的工作流。

当完成设计/概念阶段并且产品移动至产品开发时，可以应用不同的规则集和工作流。例如，被编程为与处理部关联的应用的规则集可以用于较早地检测潜在问题。如果产品为新类型的便携式电话，则可以需要将处于开发中的电话号码发送至第三方实验室以用于特定测试。这样的测试可以需要许多星期并且花费大量的金钱来完成。在测试期间生成的测量数据可以被发送至应用使得可以根据规则实时或接近实时的分析数据，并且可以生成作为结果的特定工作流。如果一些600个测试中的测试号10根据工作流生成奇怪的指定之外的、指示失败或者甚至指示一些事物将可能导致其他测试的其他的失败的测量数据，则测试可以被停止，或者请求测试的顾客可能被发送警告该问题的信息和/或报告并且使其通知测试或者采取一些其他动作。

当已经完成了在美国以及许多其他国家出售电子产品时，在可以向公众出售之前仍然需要经过特定标准请求和调整规则例如与射频(RF)传输关联的FCC调整。这些调整规则可以被编程至应用程序使得当接收到原始测量数据时，该数据被解析、打包和发送至在处理部之前运行的网络服务，这然后检测根据调整规则产生的违反其规则的打包数据并且回复要遵循的合适的工作流。在事实方式的示例中，基于规则的响应可以“通过”“失败”或“缺少”，其中，“通过”意味着所有打包的解析数据经过FCC调整。“失败”或“缺少”的响应可能更复杂，其中，“失败”响应还指示一个或更多个部件中失败的为哪一个，或者“缺少”相应指示缺少哪个数据。这些响应中的每个响应也可以具有关联的工作流，使得“经过”响应生成适于服从FCC的报告，而同时“失败”或“缺少”响应通过对本文或者部件的图纸的部分着色或者以特定颜色绘制绕失败或缺少的部分的框等来生成包括失败或缺少部分的列表、某部分失败的程度、指示失败的部分的位置或者缺少的部分的位置的计算机生成信息的不同的报告。

在实施例中，用于创建规则引擎中使用的规则代码的系统包括被配置成在不需要用户书写规则代码集的情况下接收来自用户的输入数据并且格式化输入数据以创建格式化的数据的配置器，输入数据包括应用的一个或更多个处理状态、在一个或更多个处理状态中的每个处理状态下接收的一个或更多个输入、一个或更多个处理状态中的每个处理状态下的一个或更多个期望的输出以及要在一个或更多个处理状态中的每个处理状态下进行的一个或更多个动作；并且规则书写器被配置成接收格式化数据并且生成可以由与应用一起操作的规则引擎执行的规则代码集。

在实施例中，系统还包括测试器，该测试器被配置成接收来自规则书写器的规则代码集并且对规则集进行一系列测试以验证规则集能够被规则引擎执行，并且测试器被配置成将规则集中的需要校正的任何错误指示给规则书写器。

在实施例中，系统还包括表单库，该表单库被配置成接收来自用户的表单并且将该表单输出至被配置成从表单提取信息的数据提取器以生成针对配置器的输入数据。

在实施例中，其中，从表单提取的信息包括一个或更多个图形对象以及与一个或更多个图形对象关联的识别一个或更多个处理状态、一个或更多个输入、一个或更多个输出以及一个或更多个动作的其他信息。

在实施例中，用于进行应用的功能的方法包括步骤：接收至应用的与来自用户、一个或更多个其他源或者用户和一个或更多个其他源的组合的功能有关的输入；基于输入确定应用于与一个或更多个规则关联的功能和事实包的一个或更多个规则；将消息发送至包括一个或更多个规则和事实包的规则引擎；处理规则引擎中的一个或更多个规则和事实包以研究与功能关联的基于规则的响应，其中，这样的处理包括通过创建前向链接规则的包括后向链接查询的条件来将前向链接规则与后向链接规则进行组合；将基于规则的响应发送至应用；并且基于产生功能的性能的基于规则的响应来执行应用中的一个或更多个工作流。

在实施例中，用于将规则引擎中的前向链接规则与后向链接进行组合的方法包括步骤：将根据前向链接规则推断的事实用作针对后向链接引擎的目标，除非前向链接规则包括取决于另一前向链接推断的否定，在这种情况下，前向链接规则的执行被中止，针对问题事实的规则判定的相关性被记录在表格中，并且前向链接规则的执行跳至下一个未被试验的事实以选择要执行的新规则。

在实施例中，用于进行应用的功能的方法包括步骤：接收至应用的与来自用户、一个或更多个其他源或者用户和一个或更多个其他源的组合的功能有关的输入；基于输入确定应用于与一个或更多个规则关联的功能和事实包的一个或更多个规则；将消息发送至包括一个或更多个规则和事实包的规则引擎；处理规则引擎中的一个或更多个规则和事实包以生成与功能关联的基于规则的响应，其中，这样的处理包括：通过将根据前向链接规则推断的事实用作针对后向链接规则的目标来组合后向链接规则和前向链接规则，除非前向链接规则包括取决于另一前向链接推断的否定的条件，在这种情况下，前向链接规则的执行被中止，规则判定的针对问题事实的相关性被记录在表格中，并且前向链接规则的执行跳至下一个未被试验的事实以选择要执行的新规则；将基于规则的响应发送至应用；并且基于产生功能的性能的基于规则的响应来进行应用中的一个或更多个工作流。

在实施例中，用于处理针对用户的文档的方法包括步骤：接收文档处理应用中来自用户的文档；将包括数据的消息从文档发送至规则引擎以开始针对文档的识别处理；基于在规则引擎中操作的第一规则集分析文档以产生识别针对文档的文档类型和文档内容的第一基于规则的响应；基于第一基于规则的响应，将消息发送至规则引擎以基于文档类型开始针对文档的处理机处理；基于与处理机处理对应的第二规则集分析文档内容以产生第二基于规则的响应；并且基于第二基于规则的响应，进行文档处理应用中的用于处理文档的一个或更多个工作流。

在实施例中，其中，分析文档的步骤和分析文档内容的步骤包括通过创建前向链接规则中的包括后向链接查询的条件将前向链接规则与后向链接规则进行组合。

在实施例中，其中，分析文档的步骤和分析文档内容的步骤包括通过将根据前向链接规则推断的事实用作针对后向链接规则的目标以将后向链接规则与前向链接规则进行组合，除非前向链接规则包括取决于另一前向链接推断的否定的条件，在这种情况下，前向链接规则的执行被中止，规则判定的针对问题事实的相关性被记录在表格中，并且前向链接规则的执行跳至下一个未被试验的事实以选择要执行的新规则。

在实施例中，其中，一个或更多个工作流提供用户的生产效率。

在实施例中，其中，文档与贷款申请有关，并且其中，第二基于规则的响应批准贷款申请，拒绝贷款申请或者指示需要另外的文档或者信息来访问贷款申请。

在实施例中，用于开发、测试和分析产品的方法包括步骤：接收与应用中的产品有关的数据；将包括数据的消息发送至规则引擎以开始用于分析数据的处理；基于在规则引擎中操作的规则集分析数据以基于数据产生基于规则的响应；并且基于该基于规则的响应，进行与产品的开发、测试或分析有关的应用中的一个或更多个工作流。

在实施例中，其中，分析数据的步骤包括通过创建前向链接规则中的包括后向链接查询的条件来将前向链接规则与后向链接规则进行组合。

在实施例中，其中，分析数据的步骤包括通过将根据前向链接规则推断的事实用作针对后向链接规则的目标来将后向链接规则与前向链接规则进行组合，除非前向链接规则包括取决于另一前向链接推断的否定的条件，在这种情况下，前向链接规则的执行被中止，规则判定的针对问题事实的相关性被记录在表格中，并且前向链接规则的执行跳至下一个未被试验的事实以选择要执行的新规则。

在实施例中，其中，数据为与被开发的产品的方面关联的模拟数据，其中，基于规则的响应指示模拟数据的问题，并且其中，一个或更多个工作流包括将该问题警告给一个或更多个人。

在实施例中，其中，数据为与被开发的产品的原型有关的测试数据，其中，基于规则的响应指示测试数据的问题，并且其中，一个或更多个工作流包括将该问题警告给一个或更多个人。

在实施例中，其中，数据为与已经被开发的产品关联的分析数据，其中，基于规则的响应指示通过认证、未通过认证的产品或者缺少根据标准或管理授权认证产品所需要的部分，并且其中，一个或更多个工作流包括将与通过认证、未通过认证的产品或缺少的部分警告给一个或更多个人。

在实施例中，其中，一个或更多个工作流包括生成适于服从标准体或管理授权的报告。

在实施例中，其中，一个或更多个工作流包括生成指示产品未通过认证的原因的报告。

在实施例中，其中，一个或更多个工作流生成指示产品缺少至少一部分的报告以及该部分在产品内的位置的指示。

在实施例中，用于辅助用户选择飞机航班的方法包括步骤：在应用中接收来自用户的与用户对飞行航班的偏好有关的数据；将包括数据的消息发送至规则引擎以开始用于分析数据的处理；基于在规则引擎中操作的规则集分析数据以基于数据产生基于规则的响应；并且基于该基于规则的响应，进行应用中的与标识满足用户的偏好的一个或更多个飞机航班有关的一个或更多个工作流。

在实施例中，其中，分析数据的步骤包括通过创建前向链接规则的包括后向链接查询的条件来将前向链接规则与后向链接规则进行组合。

在实施例中，其中，分析数据的步骤包括通过将根据前向链接规则推断的事实用作针对后向链接规则的目标来将后向链接规则与前向链接规则进行组合，除非前向链接规则包括取决于另一前向链接推断的否定的条件，在这种情况下，前向链接规则的执行被中止，规则判定的针对问题事实的相关性被记录在表格中，并且前向链接规则的执行跳至下一个未被试验的事实以选择要执行的新规则。

在实施例中，用于监测与航线关联的工作人员的方法包括步骤：在应用中接收与每个工作人员有关的数据；将包括数据的消息发送至规则引擎以开始用于分析数据的处理；基于在规则引擎内操作的规则集分析数据以基于数据产生基于规则的响应；并且基于该基于规则的响应，进行应用中的与标识满足针对工作人员的值班时间请求的一个或更多个飞机航班有关的一个或更多个工作流。

在实施例中，其中，分析数据的步骤包括通过创建前向链接规则的包括后向链接查询的条件来将前向链接规则与后向链接规则进行组合。

在实施例中，其中，分析数据的步骤包括通过将根据前向链接规则推断的事实用作针对后向链接规则的目标来将后向链接规则与前向链接规则进行组合，除非前向链接规则包括取决于另一前向链接推断的否定的条件，在这种情况下，前向链接规则的执行被中止，规则判定的针对问题事实的相关性被记录在表格中，并且前向链接规则的执行跳至下一个未被试验的事实以选择要执行的新规则。

在实施例中，其中，一个或更多个工作流识别针对工作人员的工作时间表。

贯穿本公开内容描述了计算系统的数目。这些系统的描述不意在限制本公开内容的教导或应用性。另外，所示出的系统的各个部件的处理可以跨多个机器、网络或其他计算源分布。例如，规则引擎、处理引擎、数据库和对应的应用的部件可以被实现为单独的装置或者被实现在单独的计算系统上，或者可替选地被实现为一个装置或者一个计算系统。另外，系统的两个或更多个部件可以被组合成较少的部件。另外，所示的系统的各个部件可以被实现在一个或更多个虚拟机中，而非实现在专用计算机硬件系统中。相似地，所示的数据库或其他存储位置可以表示物理和/或逻辑存储，包括例如存储区网络或其他分布式存储系统。此外，在一些实施例中，所示的部件之间的连接表示数据流的可能路径，而非硬件之间的实际连接。虽然示出了可能连接的一些示例，所示的部件的任何子集可以与各种实现中的部件的任何其他子集连接。

取决于实施例，本文中所描述的特定动作、事件或者算法中的任何算法的功能可以以不同的顺序进行、可以添加、混合或者分离(例如，算法的实践不需要所有的描述的动作或事件)。此外，在特定实施例中，可以例如通过多线程处理、中断处理或多处理机或处理机芯获得其他并行架构而非按顺序同时进行动作或事件。

随着以下参照图13的进一步描述，各种所示的系统中的每个系统可以被实现为被编程或被配置成进行本文中所描述的各种功能的计算系统。计算系统可以包括经过网络通信和交互操作以进行所述功能的多个独特计算机或计算装置(例如，物理服务器、工作站、存储阵列等)。每个这样的计算装置通常包括执行存储在存储器或其他非易失性计算机可读存储介质中的程序指令或模块的处理器(或者多个处理器)。本文中所公开的各种功能可以嵌入在这样的程序指令中，虽然所公开的功能中的一些功能或所有功能可以可替选地在计算机系统的专用电路中被实现。其中，计算系统包括多个计算装置，这些装置可以但不需要位于同一处。所公开的方法和任务的结果可以通过将物理存储装置例如固态存储芯片和/或磁盘变换至不同的状态而被持续地存储。本文中所描述的每个应用可以由一个或更多个计算装置例如使用关联服务器代码被编程的一个或更多个服务器或者在客户端服务器布置中被实现。

图13描述了适于实践本公开内容的方面的计算装置1800的示例性实现的实施例。计算装置1800可以被配置成通过执行存储在存储器1808和/或存储装置1816中的指令来进行各种功能。计算装置的各种示例包括个人计算机、便携式电话、智能手机、表、工作站、服务器等。实施例还可以在包括经由通信网络通信地耦接的多个计算装置的分布式计算系统上实践。

一个或更多个处理器1806包括任何合适的可编程电路，可编程电路包括一个或更多个系统和微型控制器、微型处理器、减少指令设置电路(RISC)、专用集成电路(PLC)、现场可编程门阵列(FPGA)以及能够执行本文中所描述的功能的任何其他电路。以上示例实施例不意在以任何方式限制项“处理器”的定义和/或意思。

存储器1808和存储装置1816包括非易失性计算机可读存储介质例如不限于但不排除信号perse、随机存取存储器(RAM)、闪存存储器、硬盘驱动、固态驱动、磁碟、闪存驱动、软盘、数字视频盘和/或任何合适的存储器。在任何示例性实现中，存储器1808和存储装置1816可以包括实施本公开内容的由处理器1806(例如，处理器1806可以由指令执行)可执行的方面以使得处理器1806进行本文中所描述的功能的数据和/或指令。另外，存储器1808和存储装置1816可以包括操作系统1802、基础输入输出系统(“BIOS”)1804和各种应用。

显示1810包括用于将信息呈现给计算装置的用户的至少一个部件并且可以结合用于通过显示1810提供交互的用户接口1811。显示1810可以为能够将信息传递给计算装置的用户的任何部件。在一些实现中，显示1810包括输出适配器例如视频适配器和/或音频适配器等。输出适配器工作上耦接至处理器1806并且被配置成工作上耦接至输出装置例如显示装置(例如，液晶显示(LCD))、有机发光二极管(OLED)显示、阴极射线管(CRT)、“电子墨”显示等)或者音频输出装置(例如，扬声器、头戴听筒等)。

输入装置1812包括用于接收来自用户的输入的至少一个输入部件。输入部件1812可以包括例如键盘、点击装置、鼠标、手写笔、触控面板(例如，结合在显示1810中的触摸板或触摸屏)、陀螺仪、加速器、位置检测器、音频输入装置等。单个部件例如触摸屏可以用作输入装置1812和显示1810二者。

网络接口1814可以包括被配置成经过有线或无线网络发送和接收控制信号和数据信号的一个或更多个装置。在各种实施例中，一个或更多个网络接口1814可以以射频谱的形式发射并且使用时分多址(“TDMA”)通信协议、宽带码分多址(“W-CDMA”)等操作。在各种实施例中，网络接口1814使用因特网802.11、因特网协议(“IP”)传输等发送和接收数据和控制信号。有线或无线网络可以包括各种网络部件例如网关、开关、集线器、路由器、防火墙、代理等。

本文中所使用的条件语言例如其他之间、“可以(may)”、“可以(might)”、“可以(may)”、“例如”等通常意在传递特定实施例包括而其他实施例不包括特定特征、元件和/或状态，除非特别指明或者在上下文中有其他理解。因此，传统的语言通常不意在表明一个或更多个实施例在任何方式下均需要该特征、元件和/或状态或者一个或更多个实施例需要包括用于在或者不在作者输入或提示的情况下确定这些特征、元件和/或状态包括在或者在任何特定实施例中进行的逻辑。

虽然以上详细描述随着应用于各种实施例示出、描述并指出新颖特征，要理解，在不背离本公开内容的精神的情况下，可以做出所示的装置或算法的形式或细节的省略、代替和变化。如将要识别，本文中所描述的处理可以在不提供本文中所描述的所有的特征的形式中实施，原因在于一些特征可以彼此单独地使用或实践。保护的范围由所附权利要求而非通过前述来限定。落入权利要求的等同方式的意义和范围内的所有的变化将包括在其范围内。

Claims (28)

1.一种用于构造在规则引擎中使用的规则集代码的系统，包括：

配置器，被配置成在不需要用户书写所述规则集代码的情况下接收来自所述用户的输入数据，并且使所述输入数据格式化以创建经格式化的数据，所述输入数据包括：应用程序的一个或更多个处理状态；在所述一个或更多个处理状态中的每个处理状态下能够接收的一个或更多个输入；所述一个或更多个处理状态中的每个处理状态的一个或更多个预期输出以及在所述一个或更多个处理状态中的每个处理状态下执行的一个或更多个动作；以及

规则书写器，被配置成接收所述经格式化的数据，以及生成能够由与所述应用程序一起操作的所述规则引擎执行的所述规则集代码。

2.根据权利要求1所述的系统，还包括测试器，所述测试器被配置成接收来自所述规则书写器的所述规则集代码，并且对所述规则集执行一系列逻辑测试以验证所述规则集将能够由所述规则引擎执行，以及所述测试器被配置成将所述规则集中的需要校正的任何错误指示给所述规则书写器。

3.根据权利要求1所述的系统，还包括：

表单库，被配置成接收来自所述用户的表单并且将所述表单输出至数据提取器，所述数据提取器被配置成从所述表单提取信息以开发针对所述配置器的输入数据。

4.根据权利要求3所述的系统，其中，从所述表单提取的所述信息包括一个或更多个图形对象以及与所述一个或更多个图形对象相关联的其他信息，所述其他信息识别所述一个或更多个处理状态、所述一个或更多个输入、所述一个或更多个预期输出以及所述一个或更多个动作。

5.一种非易失性计算机可读存储介质，包括用于执行应用程序的功能的指令，所述指令当在计算装置上被执行时使得所述计算装置至少：

接收来自用户、一个或更多个其他源或者所述用户与所述一个或更多个其他源的组合的与所述功能有关的至所述应用程序的输入；

基于所述输入确定应用于所述功能的一个或更多个规则以及与所述一个或更多个规则相关联的事实包；

将消息发送至包含所述一个或更多个规则和所述事实包的规则引擎；

处理所述规则引擎内的所述一个或更多个规则和所述事实包，以生成与所述功能关联的依赖于规则的响应，其中，这样的处理包括：通过创建在前向链接规则内包含后向链接查询的条件来将所述前向链接规则与后向链接规则进行组合；

将所述依赖于规则的响应发送至所述应用程序；以及

基于产生所述功能的性能的所述依赖于规则的响应来执行所述应用程序内的一个或更多个工作流。

6.一种非易失性计算机可读存储介质，包括用于将规则引擎内的后向链接规则与前向链接规则进行组合的指令，所述指令当在计算装置上被执行时使得所述计算装置至少：

将根据所述前向链接规则推断的事实用作针对所述后向链接规则的目标，除非所述前向链接规则包含依赖于其他前向链接推断的否定的条件，在所述前向链接规则包含依赖于其他前向链接推断的否定的条件的情况下，所述前向链接规则的执行被中止；

将针对问题事实的规则判定的相关性记录在表中；以及

在所述前向链接规则的执行期间，跳转至下一个未被试验的事实以选择要执行的新规则。

7.一种非易失性计算机可读存储介质，包括用于执行应用程序的功能的指令，所述指令当在计算装置上被执行时使得所述计算装置至少：

接收来自用户、一个或更多个其他源或者所述用户与所述一个或更多个其他源的组合的与所述功能有关的至所述应用程序的输入；

基于所述输入确定应用于所述功能的一个或更多个规则以及与所述一个或更多个规则相关联的事实包；

将消息发送至包含所述一个或更多个规则和所述事实包的规则引擎；

处理所述规则引擎内的所述一个或更多个规则和所述事实包以生成与所述功能关联的依赖于规则的响应，其中，这样的处理包括：通过将根据前向链接规则推断的事实用作针对后向链接规则的目标来将所述前向链接规则与所述后向链接规则进行组合，除非所述前向链接规则包含依赖于其他前向链接推断的否定的条件，在所述前向链接规则包含依赖于其他前向链接推断的否定的条件的情况下，所述前向链接规则的执行被中止，针对问题事实的规则判定的相关性被记录在表中，以及所述前向链接规则的执行跳转至下一个未被试验的事实以选择要执行的新规则；

将所述依赖于规则的响应发送至所述应用程序；以及

基于产生所述功能的性能的所述依赖于规则的响应来执行所述应用程序内的一个或更多个工作流。

8.一种非易失性计算机可读存储介质，包括用于处理针对用户的文档的指令，所述指令当在计算装置上被执行时使得所述计算装置至少：

在文档处理应用程序中接收来自用户的文档；

将包含来自所述文档的数据的消息发送至规则引擎以开始针对所述文档的识别处理；

基于在所述规则引擎内操作的第一规则集分析所述文档，以产生识别所述文档的文档类型和文档内容的第一依赖于规则的响应；

基于所述第一依赖于规则的响应，将消息发送至所述规则引擎以基于所述文档类型开始针对所述文档的处理机处理；

基于与所述处理机处理对应的第二规则集分析所述文档内容以产生第二依赖于规则的响应；以及

基于所述第二依赖于规则的响应，在所述文档处理应用程序内执行一个或更多个工作流以处理所述文档。

9.根据权利要求8所述的非易失性计算机可读存储介质，其中，用于分析所述文档和用于分析所述文档内容的所述指令包括下述指令：所述指令用于通过创建在前向链接规则内包含后向链接查询的条件来将所述前向链接规则与后向链接规则进行组合。

10.根据权利要求8所述的非易失性计算机可读存储介质，其中，用于分析所述文档的指令和用于分析所述文档内容的指令包括下述指令：所述指令用于通过将根据前向链接规则推断的事实用作针对后向链接规则的目标来将所述后向链接规则与所述前向链接规则进行组合，除非所述前向链接规则包含依赖于其他前向链接推断的否定的条件，在所述前向链接规则包含依赖于其他前向链接推断的否定的条件的情况下，所述前向链接规则的执行被中止，针对问题事实的规则判定的相关性被记录在表中，以及所述前向链接规则的执行跳转至下一个未被试验的事实以选择要执行的新规则。

11.根据权利要求8所述的非易失性计算机可读存储介质，其中，所述一个或更多个工作流提高所述用户的生产效率。

12.根据权利要求8所述的非易失性计算机可读存储介质，其中，所述文档与贷款申请有关，以及其中，所述第二依赖于规则的响应批准所述贷款申请、拒绝所述贷款申请或者指示需要另外的文档或信息来评估所述贷款申请。

13.一种非易失性计算机可读存储介质，包括用于开发、测试和分析产品的指令，所述指令当在计算装置上被执行时使得所述计算装置至少：

在应用程序中接收与所述产品有关的数据；

将包含所述数据的消息发送至规则引擎以开始用于分析所述数据的处理；

基于在所述规则引擎内操作的规则集分析所述数据，以基于所述数据产生依赖于规则的响应；以及

基于所述依赖于规则的响应，在所述应用程序内执行与所述产品的开发、测试或分析有关的一个或更多个工作流。

14.根据权利要求13所述的非易失性计算机可读存储介质，其中，用于分析所述数据的指令包括下述指令：所述指令用于通过创建前向链接规则内包含后向链接查询的条件来将所述前向链接规则与后向链接规则进行组合。

15.根据权利要求13所述的非易失性计算机可读存储介质，其中，用于分析所述数据的指令包括下述指令：所述指令用于通过将根据前向链接规则推断的事实用作针对后向链接规则的目标来将所述后向链接规则与所述前向链接规则进行组合，除非所述前向链接规则包含依赖于其他前向链接推断的否定的条件，在所述前向链接规则包含依赖于其他前向链接推断的否定的条件的情况下，所述前向链接规则的执行被中止，针对问题事实的规则判定的相关性被记录在表中，以及所述前向链接规则的执行跳转至下一个未被试验的事实以选择要执行的新规则。

16.根据权利要求13所述的非易失性计算机可读存储介质，其中，所述数据为与正在被开发的所述产品的一方面相关联的模拟数据，其中，所述依赖于规则的响应指示所述模拟数据的问题，以及其中，所述一个或更多个工作流包括将所述问题警告给一个或更多个人。

17.根据权利要求13所述的非易失性计算机可读存储介质，其中，所述数据为与正在被开发的所述产品的原型相关联的测试数据，其中，所述依赖于规则的响应指示所述测试数据的问题，以及其中，所述一个或更多个工作流包括将所述问题警告给一个或更多个人。

18.根据权利要求13所述的非易失性计算机可读存储介质，其中，所述数据为与已经被开发的所述产品相关联的分析数据，其中，所述依赖于规则的响应指示所述产品通过认证、未通过认证或者缺少根据标准或规定认证所述产品所需要的部分，以及其中，所述一个或更多个工作流包括将所述产品通过认证、未通过认证或者缺少所述部分警告给一个或更多个人。

19.根据权利要求18所述的非易失性计算机可读存储介质，其中，一个或更多个工作流包括生成适于提交给标准体或管理授权的报告。

20.根据权利要求18所述的非易失性计算机可读存储介质，其中，一个或更多个工作流包括生成指示所述产品未通过所述认证的原因的报告。

21.根据权利要求18所述的非易失性计算机可读存储介质，其中，一个或更多个工作流包括生成指示所述产品的至少一部分缺失的报告以及所述部分在所述产品内的可能位置的指示。

22.一种非易失性计算机可读存储介质，包括用于辅助用户选择飞机航班的指令，所述指令当在计算装置上被执行时使得所述计算装置至少：

在应用程序内接收来自所述用户的与所述用户对所述飞机航班的偏好有关的数据；

将包含所述数据的消息发送至规则引擎以开始用于分析所述数据的处理；

基于在所述规则引擎内操作的规则集分析所述数据，以基于所述数据产生依赖于规则的响应；以及

基于所述依赖于规则的响应，在所述应用程序内执行与识别满足所述用户的偏好的一个或更多个飞机航班有关的一个或更多个工作流。

23.根据权利要求22所述的非易失性计算机可读存储介质，其中，用于分析所述数据的所述指令包括下述指令：所述指令用于通过创建前向链接规则内包含后向链接查询的条件来将所述前向链接规则与后向链接规则进行组合。

24.根据权利要求22所述的非易失性计算机可读存储介质，其中，用于分析所述数据的所述指令包括下述指令：所述指令用于通过将根据前向链接规则推断的事实用作针对后向链接规则的目标来将所述后向链接规则与所述前向链接规则进行组合，除非所述前向链接规则包含依赖于其他前向链接推断的否定的条件，在所述前向链接规则包含依赖于其他前向链接推断的否定的条件的情况下，所述前向链接规则的执行被中止，针对问题事实的规则判定的相关性被记录在表中，以及所述前向链接规则的执行跳转至下一个未被试验的事实以选择要执行的新规则。

25.一种非易失性计算机可读存储介质，包括用于监测与航线关联的机组人员的指令，所述指令当在计算装置上被执行时使得所述计算装置至少：

在应用程序内接收与每个机组人员有关的数据；

将包含所述数据的消息发送至规则引擎以开始用于分析所述数据的处理；

基于在所述规则引擎内操作的规则集分析所述数据，以基于所述数据产生依赖于规则的响应；以及

基于依赖于规则的响应，在所述应用程序内执行与识别满足针对所述机组人员的值班时间请求的一个或更多个飞机航班有关的一个或更多个工作流。

26.根据权利要求25所述的非易失性计算机可读存储介质，其中，用于分析所述数据的所述指令包括下述指令：所述指令用于通过创建前向链接规则内包含后向链接查询的条件来将所述前向链接规则与后向链接规则进行组合。

27.根据权利要求25所述的非易失性计算机可读存储介质，其中，用于分析所述数据的所述指令包括下述指令：所述指令用于通过将根据前向链接规则推断的事实用作针对后向链接规则的目标来将所述后向链接规则与所述前向链接规则进行组合，除非所述前向链接规则包含依赖于其他前向链接推断的否定的条件，在所述前向链接规则包含依赖于其他前向链接推断的否定的条件的情况下，所述前向链接规则的执行被中止，针对问题事实的规则判定的相关性被记录在表中，以及所述前向链接规则的执行跳转至下一个未被试验的事实以选择要执行的新规则。

28.根据权利要求25所述的非易失性计算机可读存储介质，其中，所述一个或更多个工作流识别针对所述机组人员的工作时间表。