JP2005525630A

JP2005525630A - 推論サービスを提供するためのシステム及び方法

Info

Publication number: JP2005525630A
Application number: JP2003586834A
Authority: JP
Inventors: エレラ，ピーター，ジェー．; カス，ロナルド; ウィルソン，カーク，ディー．; タン，イット−ベング
Original assignee: コンピューターアソシエイツシンク，インク．
Priority date: 2002-04-19
Filing date: 2003-04-18
Publication date: 2005-08-25
Also published as: US20110047123A1; WO2003090164A2; EP1525556B1; IL164622A0; US7849045B2; WO2003090164A3; ZA200409017B; AU2003230984A1; CA2482956A1; US20040015463A1; US7937358B2; US20090089239A1; KR20050011745A; US7191163B2; BR0309333A; US20030229605A1; EP1525556A2; US7356522B2; CN1659589A

Abstract

推論サービスを提供する方法が、指定されたドメインのための複数の規則を受け取ることを含む。本方法はまた、規則に関連付けられた事前条件及び規則に関連付けられた事後条件を識別することを含む。事前条件とは、規則を実行する際に使用される入力であり、事後条件とは、規則の実行からの出力である。本方法は、さらに、事前条件に対応する入力値を受け取ることを含む。その上、本方法は、入力値を使用して規則の少なくとも一部分を実行し、出力値を生成することを含む。出力値は、事後条件に対応する。

Description

本発明は、一般に、エキスパートシステムの分野、より詳細には、推論サービスを提供するためのシステム及び方法に関する。

医学分野や法律分野などの特定分野における諸問題を解決するために、エキスパートシステムがしばしば使用されている。たとえば、エキスパートシステムは、患者の症状を識別する情報を受け取り、その症状を分析し、その患者にとって可能な診断を識別することができる。代表的なエキスパートシステムには、エキスパートシステムによって使用される論理を具現化したルールベース、即ち１組の規則が含まれている。代表的なエキスパートシステムには、推論エンジンも含まれている。推論エンジンは、一般に、ある患者が罹っている症状などの、１組の入力を分析するための規則を実行する。規則を実行する場合に、推論エンジンは、一般に、１組の出力値に値を割り当てようとする。出力値とは、推論エンジンの結論である。

概要
本発明は、推論サービスを提供するためのシステム及び方法を提供する。特に、推論エンジンは、アプリケーションプログラムインターフェース（ＡＰＩ）などの、柔軟性のあるインターフェースと合わせて使用されることがある。ユーザ又はアプリケーションは、推論エンジンを起動して、識別されたルールベースを使用し、推論演算を実施することがある。ルールベースは、拡張マーク付け言語（ＸＭＬ）を使用して定義されることがある。次いで、推論エンジンは、識別されたルールベース内の指定されたドメインのための規則を実行し、起動しているユーザ又はアプリケーションに、その推論結果を返す。

一実施形態においては、推論サービスを提供する方法は、指定されたドメインのための複数の規則を受け取ることを含む。この方法はまた、規則に関連付けられた少なくとも１つの事前条件と、規則に関連付けられた少なくとも１つの事後条件とを識別することを含む。それぞれの事前条件とは、規則を実行する際に使用される入力であり、それぞれの事後条件とは、規則の実行からの出力である。この方法は、事前条件に対応する入力値を受け取ることをさらに含む。その上、この方法は、入力値を使用して、規則の少なくとも一部分を実行し、出力値を生成することを含む。出力値は、事後条件に対応する。

別の実施形態においては、推論サービスを提供する方法は、指定されたドメインのための複数の第１の規則を受け取ることを含み、この規則は、第１のルールベースの少なくとも一部分を含む。この方法はまた、第１の規則をメモリ内にロードすることを含む。この方法は、第２のドメインを補足ルールベースからメモリ内にロードすることをさらに含む。その上、この方法は、第２のドメイン内の規則に対して第１の規則を部分推論することを含む。

さらに別の実施形態においては、推論サービスを提供する方法は、指定されたドメインのための複数の規則の少なくとも一部分を実行することを含む。規則の少なくとも１つが、式を含む。この方法はまた、規則内の式を解くのに必要なフィールドが未知の値を有している場合に規則の１つを保留するステップと、決定木規則を保留した式に関連付けられた２進ステートメントを識別するステップとを含む。この方法は、規則を保留したフィールドに既知の値を割り当てるステップと、規則をアンペンドするステップとをさらに含む。その上、この方法は、識別された２進ステートメントで規則の実行を再始動することを含む。

次に、本発明をより完全に理解するために、添付図面と合わせ、以下の記述を参照する。

実施形態の例の詳細な説明
図１は、本発明の一実施形態による推論サービスを提供するためのシステム１００の例を示す例示的ブロック図である。例示されている実施形態においては、システム１００は、サーバ１０２と、データベース１０４と、ネットワーク１０６と、１つ以上のクライアント１０８とを含む。

オペレーションの一態様においては、サーバ１０２は、ルールベースビルダ１１０と推論エンジン１１２とを含むことがある。ルールベースビルダ１１０は、１つ以上のルールベース１１４の作成及び修正をサポートする。ルールベース１１４は、推論演算を実施するために推論エンジン１１２によって使用される論理を具現化する規則１１６を含む。たとえば、ルールベース１１４は、如何に患者の症状を分析し、その患者にとって可能な診断を識別するかを定義することがある。推論エンジン１１２は、システム１００内で推論演算を実施することがある。たとえば、推論エンジン１１２は、１つ以上の入力値を受け取り、ルールベース１１４を使用してその入力値を分析し、１つ以上の出力値を生成することができる。次いで、この出力値を、ユーザが患者の診断を利用できるようにするなど、様々な目的に使用することができる。

例示されている実施形態においては、サーバ１０２は、ネットワーク１０６に結合される。本文書においては、「結合する」という用語は、２つ以上の構成要素が互いに物理的接触をしているかどうかに関わらず、それらの構成要素間の直接的又は間接的な通信を意味する。また、「通信」という用語は、物理的に別個の構成要素間、又は１つの物理ユニット内の構成要素間の通信を意味することがある。サーバ１０２は、システム１００内のルールベース１１４の作成及び使用に関連する１つ以上の機能を実施する。たとえば、サーバ１０２は、ルールベース１１４を作成し、修正し、消去することができる。サーバ１０２はまた、ルールベース１１４を使用して、推論演算を実施することができる。サーバ１０２は、ルールベースビルディング及び推論機能を実施するよう動作可能な、任意のハードウェア、ソフトウェア、ファームウェア、又はそれらの組み合わせを含むことがある。

データベース１０４は、サーバ１０２に結合される。データベース１０４は、サーバ１０２によって使用される情報を格納し、その検索を容易にする。たとえば、データベース１０４は、ルールベースビルダ１１０によって作成され、かつ推論エンジン１１２によって使用される１つ以上のルールベース１１４を格納することがある。データベース１０４は、情報を格納し、かつその検索を容易にするよう動作可能な、任意のハードウェア、ソフトウェア、ファームウェア、又はそれらの組み合わせを含むことができる。また、データベース１０４は、情報を格納し、かつその検索を容易にするための、様々なデータ構造、配置、及びコンパイルのうちのいずれかを使用することがある。

ネットワーク１０６は、サーバ１０２及びクライアント１０８に結合される。ネットワーク１０６は、システム１００の構成要素間の通信を容易にする。ネットワーク１０６は、たとえば、インターネットプロトコル（ＩＰ）パケット、フレームリレーフレーム、非同期的転送モード（ＡＴＭ）セル、又はネットワークアドレス間の他の好適な情報を通信することがある。ネットワーク１０６は、１つ以上のローカルエリアネットワーク（ＬＡＮ）、メトロポリタンエリアネットワーク（ＭＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、インターネットなどのグローバルネットワークのすべて又は一部分、又は１つ以上の場所における他の１つまたは複数の通信システムを含むことがある。

クライアント１０８は、ネットワーク１０６に結合される。クライアント１０８は、システム１００内の様々な機能のいずれかを実施することがある。たとえば、クライアント１０８は、サーバ１０２内のルールベースビルダ１１０及び推論エンジン１１２の機能を起動できるクライアントアプリケーション１２２を含むことができる。特定の例として、クライアントアプリケーション１２２により、推論エンジン１１２は、クライアントアプリケーション１２２によって識別されたルールベース１１４を使用して、推論演算を実施することができる。クライアント１０８とは、プログラマ又は他のユーザが、ルールベースビルダ１１０を使用して、様々なルールベース１１４を作成し、修正し、又は消去することがある端末でもあり得る。クライアント１０８は、サーバ１０２と通信するよう動作可能な、任意のハードウェア、ソフトウェア、ファームウェア、又はそれらの組み合わせを含むことがある。

例示されている例においては、サーバ１０２は、プロセッサ１２４とメモリ１２６とを含む。プロセッサ１２４は、命令を実行し、データを操作して、サーバ１０２のオペレーションを実施する。図１は、サーバ１０２内の１つのプロセッサ１２４を示しているが、特定のニーズにより、複数のプロセッサ１２４が使用されることがある。メモリ１２６は、サーバ１０２の機能を実施するためにプロセッサ１２４によって使用される情報を格納し、その検索を容易にする。メモリ１２６は、たとえば、プロセッサ１２４によって実施される命令、及びプロセッサ１２４によって使用されるデータを格納することがある。メモリ１２６は、情報を格納し、かつその検索を容易にするよう動作可能な、任意のハードウェア、ソフトウェア、ファームウェア、又はそれらの組み合わせを含むことがある。

例示されている実施形態においては、サーバ１０２は、ルールベースビルダ１１０と、推論エンジン１１２と、ツール１２８とを含む。特定の実施形態においては、ルールベースビルダ１１０又は推論エンジン１１２がクライアントアプリケーション１２２によって起動された場合には、サーバ１０２は、ルールベースビルダインスタンス又は推論エンジンインスタンスを作成する。次いで、サーバ１０２によって生成されたインスタンスを使用して、クライアントアプリケーション１２２にサービスを提供することがある。第２のクライアントアプリケーション１２２が、ルールベースビルダ１１０又は推論エンジン１１２を起動しようとすると、第２のクライアントアプリケーション１２２のために、別個のインスタンスが作成されることがある。同様に、第１のクライアントアプリケーション１２２が、複数のスレッドを使用し、それぞれのスレッドでルールベースビルダ１１０又は推論エンジン１１２を起動すると、それぞれのスレッドのために、別個のインスタンスが生成され得る。このことにより、サーバ１０２が、複数のクライアント１０８に、かつ複数のスレッド上に、ルールベースビルディング及び推論機能を同時に提供することが可能となる。他の実施形態においては、サーバ１０２は、それぞれのクライアントアプリケーション１２２又はスレッドのために、インスタンスを作成する必要がない。その上、以下の記述においては、ルールベースビルダ１１０及び推論エンジン１１２を、特定の機能を実施するものとして記述することがある。この記述には、特定の機能がルールベースビルダインスタンス又は推論エンジンインスタンスによって実施されるような状況が含まれる。

ルールベースビルダ１１０は、システム１００内のルールベース１１４の作成、修正、及び消去を容易にする。ルールベース１１４は、システム１００内の推論機能を実施するために、推論エンジン１１２によって使用される１つ以上の規則１１６を定義する。たとえば、ルールベース１１４は、情報を格納するデータオブジェクト、及びデータオブジェクト内の情報に作用する方法及び規則を指定する論理オブジェクトを定義することができる。特定の例として、データオブジェクトは、患者の症状を格納することができ、論理オブジェクトは、その症状を分析し、診断を計算しようとする。規則の例が図９Ａ及び図９Ｂに示されているが、これについて以下に記述する。

ルールベース１１４は、任意のフォーマットを使用して定義された任意の数の規則１１６を含むことがある。一実施形態においては、ルールベース１１４は、拡張マーク付け言語（ＸＭＬ）を使用して定義された規則１１６を包含する。特定の実施形態においては、ルールベース１１４は、規則定義言語（ＲＤＬ）を使用して定義された規則１１６を包含する。これについては、以下に記述する。また、ルールベース１１４が、複数のセクション又は部分に区分されることがある。たとえば、ルールベース１１４は異なるセクションに分割でき、１つのセクションは、データオブジェクトを定義し、別のセクションは、データオブジェクト上で動作する論理オブジェクトを定義する。別の例として、ルールベース１１４は、複数のルールセット１３０から形成され、それぞれのルールセット１３０が、共通の事柄に関連付けられた１つ以上の規則１１６を包含する。ルールベース１１４は、さらに、複数のルールセット１３０を含むことがある、複数のドメイン１３０から形成され得る。ルールベースアーキテクチャの例が図４に示されているが、これについて以下に記述する。

ルールベースビルダ１１０は、様々なルールベース構成要素を統合されたルールベース１１４にマージすることにより、システム１００内のルールベース１１４の作成をサポートする。たとえば、ルールベースビルダ１１０は、１組の規則１１６、ルールセット１３０、及びルールベース１１４を、１つのルールベース１１４に組み合わせることがある。ルールベースビルダ１１０はまた、その結果生じた、統合されたルールベース１１４を解析して、規則１１６間の完全性及び整合性を確実にする一助となることができる。特定の例として、異なる開発チームが、異なる規則１１６、ルールベース１１４、又はルールセット１３０を別個に作成し、ルールベースビルダ１１０が、様々な構成要素を１つのルールベース１１４にマージすることができる。別の例として、１つの開発チームは、１組のデータオブジェクトを作成し、別の開発チームは、そのデータオブジェクトを処理する１組の論理オブジェクトを作成することができる。次いで、ルールベースビルダ１１０が、データ及び論理オブジェクトをルールベース１１４にマージすることができる。

統合されたルールベース１１４にマージされた様々なルールベース構成要素は、いくつかの形式で存在することができる。たとえば、マージされたルールベース１１４は、コンパイルされていないソースルールベース１１４又はコンパイルされた２進ルールベース１１４として存在することができる。２進ルールベース１１４を使用することにより、サードパーティベンダは、市場に出して顧客に販売することのできる２進ルールベース１１４を作成することができる。ルールベース１１４が２進形式であるために、ルールベース１１４の実際のコンテンツは、より保護され得る。２進ルールベース１１４を取得した顧客は、それを他のルールベース１１４にマージするだけで良い。顧客は、２進ルールベース１１４を形成している実際の規則１１６にアクセスする必要がない。

ルールベースビルダ１１０はまた、様々なルールベース構成要素を標準フォーマットに変換する。たとえば、システム１００内のルールベース１１４は、ＸＭＬの規則定義言語などの、デフォルト又は標準フォーマットを有することができる。ルールベースビルダ１１０が、異なるフォーマットを有する構成要素を使用して、統合されたルールベース１１４を作成することを、クライアントアプリケーション１２２が要求すると、ルールベースビルダ１１０は、その構成要素を標準フォーマットに変換し、再フォーマットすることができる。次いで、ルールベースビルダ１１０は、再フォーマット化された構成要素を使用して、統合されたルールベース１１４を生成することができる。このことにより、ユーザは、ルールベースビルダ１１０及び推論エンジン１１２によって使用される標準フォーマット以外のフォーマットで、ルールベース１１４を書き込むことができる。

ルールベースビルダ１１０は、さらに、ソースルールベース１１４をコンパイルして、２進ルールベース１１４を作成する。一例として、ルールベースビルダ１１０は、規則定義言語に準拠しているＸＭＬ文書で定義されたソースルールベース１１４をコンパイルすることができる。コンパイルした結果、ルールベースビルダ１１０は、推論エンジン１１２が推論演算を実施するために使用する、２進バージョンのルールベース１１４を作成する。ルールベース１１４をコンパイルすることは、推論エンジン１１２の演算効率を向上させる一助となり、また、ルールベース１１４のプライバシーを保護し、かつそれに関わるセキュリティを向上させる一助ともなり得る。情報が如何に、規則定義言語によって定義される統合されたルールベース１１４にマージされるかについて、以下に記述する。

ルールベースビルダ１１０は、ルールベース１１４を作成し、かつ維持するよう動作可能な、任意のハードウェア、ソフトウェア、ファームウェア、又はそれらの組み合わせを含むことができる。たとえば、ルールベースビルダ１１０は、プロセッサ１２４によって実行される１つ以上のソフトウェアルーチンを含むことができる。ルールベースビルダの実施形態の例が図５Ａ及び図５Ｂに示されているが、これについて以下に記述する。

推論エンジン１１２は、サーバ１０２の推論機能を実施する。たとえば、推論エンジン１１２は、１つ以上のルールベース１１４にアクセスし、使用される規則１１６を識別する。推論エンジン１１２はまた、クライアントアプリケーション１２２から入力値を受け取り、この入力値を使用して規則１１６を実行することがある。本文書において、「実行する」という用語は、最低限、推論エンジン１１２が、規則１１６の少なくとも一部分を調べて、規則１１６のアクションを実施すべきかどうかを判断することを意味する。次いで、推論エンジン１１２は、推論演算の結果をクライアントアプリケーション１２２に返す。

一実施形態においては、推論エンジン１１２によって使用される規則１１６は、属性又はフィールドを包含するか、または参照する。既知の値又は定義された値を有するフィールドは、「既知の状態」で存在する「既知のフィールド」を意味し、未知の値又は未定義の値を有するフィールドは、「未知の状態」で存在する「未知のフィールド」を意味することがある。推論中に、推論エンジン１１２は、規則１１６を使用して、既知の値を未知のフィールドに割り当てようと試みる。

オペレーションの一態様においては、推論エンジン１１２は、ルールベース１１４内の規則１１６を調べて、規則１１６をファイアし、フェイルし、又は保留することがある。推論エンジン１１２は、規則１１６内の前提を調べ、この前提が真であることを発見し、規則１１６内で指定されているアクションを実施する場合には、規則１１６を「ファイアする」。推論エンジン１１２は、規則１１６内の前提を調べ、この前提が偽であることを発見し、規則１１６内で指定されているアクションを実施することを拒絶する場合には、規則１１６を「フェイルする」。推論エンジン１１２は、規則１１６内の前提を調べ、この前提が真であるとも偽であるとも決断できないと判断した場合には、規則１１６を「保留する」。このことは、その前提が未知の値を有するフィールドを伴う場合に生じることがある。推論エンジン１１２は、その後、フィールドに既知の値が割り当てられた後、保留中の規則１１６をファイア又はフェイルしようとすることがある。

推論エンジン１１２は、１つ又は複数の戦略を用いて、ルールベース１１４内の規則１１６を実行することがある。一実施形態においては、推論エンジン１１２は、ルールベース１１４内の規則１１６の前向き連鎖及び後ろ向き連鎖をサポートする。一般に、前向き連鎖においては、推論エンジン１１２は、既知の状態に置かれたルールベース１１４内の未知のフィールドの数を最大化しようとする。前向き連鎖においては、推論エンジン１１２は、規則１１６をファイアし、その結果、どのフィールドが既知の状態に解決されたかを判断する。次いで、推論エンジン１１２は、任意の保留中の規則１１６を再訪問し、これらの保留中の規則１１６をファイア又はフェイルできるかどうかを判断する。推論エンジン１１２は、規則１１６をこれ以上ファイア又はフェイルできなくなるか、又は任意の保留中の規則１１６を実行するまで、このプロセスを続行する。

後ろ向き連鎖においては、一般に、推論エンジン１１２は、ある事前条件が特定の成果を保証するかどうか、又は識別されたフィールドを解決するかどうかを判断するなどの、一次目標を解決しようとする。推論エンジン１１２は、最初に、識別された目標を恐らく解決することのできる規則１１６を訪問する。規則１１６が未知のフィールドのために保留すると、推論エンジン１１２は、未知のフィールドを二次目標のリストに追加する。次いで、推論エンジン１１２は、一次又は二次目標のいずれかを恐らく解決することのできる規則１１６を訪問する。推論エンジン１１２は、一次目標が解決されるか、又は実行できる規則１１６がもはやなくなるまで、このプロセスを続行する。

推論演算を実施する際に、推論エンジン１１２は、ルールベース１１４内の規則１１６を実行する。一実施形態においては、規則１１６が実行される順序は、少なくとも一部分は、規則１１６に関連付けられた優先順位に依存する。上述したように、規則１１６はルールセット１３０内に常駐し、ルールセット１３０はドメイン１３１内に常駐することがある。クライアントアプリケーション１２２が、推論中に使用されるドメイン１３１を識別した場合には、推論エンジン１１２は、そのドメイン１３１内に包含されている無条件ルールセット１３０をメモリ１２６にロードする。次いで、推論エンジン１１２により、ドメイン１３１内に包含されている規則１１６が、それらの優先順位に従って順序付けられることが確実となる。その後、推論エンジン１１２は、それらの優先順で、規則１１６を実行する。

一実施形態においては、推論エンジン１１２は、推論演算を実施する場合に、単調推論を強制実施する。単調推論においては、いったん推論エンジン１１２がフィールド値により規則をファイア又はフェイルした場合は、その後の推論中はこのフィールドの値を変えるべきではなく、もし変えた場合には、推論の整合性が損なわれることがあると想定している。何故なら、結果が、矛盾する規則のアクションを反映していることがあるからである。推論エンジン１１２は、いつフィールドの値が規則の前提によって試験されたかを検出することがある。後に、フィールドの値が変更すると、推論エンジンは、これを単調推論違反として取り扱い、この違反をユーザに警告することがある。

フィールドは、初期値が割り当てられた後、フィールドの値が変更しないことがあるので、「第１の値フィールド」と呼ばれることがある。他のフィールドは、何回も変更することのある値を有する「最終値フィールド」と呼ばれることがある。最終値フィールドを使用することは、たとえばルールベース１１４内でカウンタが必要な場合に有用であり得る。特定の例として、ルールベース１１４は、１群のルールセット１３０を含むことができ、それぞれのルールセット１３０は、納税者がある税の免除を請求できるかどうかを判断することができる。ルールベース１１４はまた、納税者が請求できる免除額を追跡するカウンタを含むことができる。推論エンジン１１２がそれぞれのルールセット１３０を実行する度に、その納税者に免除の資格がある場合に、カウンタが増分され得る。この例においては、ルールセット１３０のすべてが実行されるまで、カウンタの有用な値が分らず、推論エンジン１１２は、カウンタを何回も増分することができる。

第１の値フィールドと最終値フィールドとの間の違いが、推論中に規則１１６が実行される順序に影響を及ぼすことがある。たとえば、多数の規則１１６は、最終値フィールドの値を変更することができる。推論エンジン１１２は、最終値フィールドの値を変更することのできる規則１１６のすべてが実行されるまで、前提内で最終値フィールドを使用する規則１１６をファイア又はフェイルできないことがある。税の例に戻ると、推論エンジン１１２は、免除額を扱うルールセット１３０のすべてが実行されるまで、納税者が支払うべき税を計算する規則１１６を保留するよう強制され得る。

推論エンジン１１２はまた、補足規則１１６、ルールベース１１４、及びルールセット１３０の使用をサポートすることができる。補足ルールベース１１４とは、推論中に一次ルールベース１１４に加えて使用できるルールベースである。たとえば、保険会社は、その本社が設定した一次ルールベース１１４を持つことができ、それぞれの支店は、その支店の方針を定義する補足ルールベース１１４を持つことができる。補足ルールベース１１４を使用するために、推論エンジン１１２は、一次ルールベース１１４を受け取り、メモリ１２６内にロードすることができる。次いで、一次ルールベース１１４内の規則は、補足ルールベースからドメインをロードし、これらのドメイン内の規則を部分推論することができる。一実施形態においては、一次ルールベース１１４と補足ルールベース１１４との間の通信が、補足ルールベースの事前条件及び事後条件を介して生じることがある。特定の実施形態においては、補足ルールベース１１４は、一次ルールベース１１４内の任意のオブジェクトを直接参照せず、このことが、恐らく「不良な」補足ルールベース１１４から一次ルールベース１１４を引き離すための一助となり得る。補足ルールベース１１４はまた、一次ルールベース１１４とは異なる推論エンジンインスタンスに関連付けられ得る。この例においては、一次ルールベース１１４は、補足ルールベース１１４を運転する「アプリケーション」として作用することができる。補足ルールベース１１４から見て、一次ルールベース１１４は、アプリケーションと区別不可能なことがある。一次ルールベース１１４は、１つ又は複数の補足ルールベース１１４をロードすることができ、次いで、それぞれの補足ルールベース１１４は、１つ又は複数の追加補足ルールベース１１４をロードすることができる。

推論エンジン１１２はまた、一連の推論及び部分推論をサポートすることができる。一連の推論においては、推論エンジン１１２は、第１のドメイン１３１を使用して推論演算を実施し、１組の出力値を作成する。次いで、推論エンジン１１２は、これらの出力値を第２のドメイン１３１のための入力値として使用し、第２のドメイン１３１を使用して推論演算を実施する。このことは、たとえば、第１のドメイン１３１が、納税者が受け取る権利を有する免除額を計算し、第２のドメイン１３１が、その免除額に基づいて納税者が支払うべき税を計算する場合に有用であり得る。部分推論においては、推論エンジン１１２は、第１のドメイン１３１を使用して推論演算を実施し、第１のドメイン１３１内の規則１１６の１つが、第２のドメイン１３１を使用して推論を起動することがある。その規則１１６がファイアされた場合には、推論エンジン１１２は、第２のドメイン１３１をロードし、その第２のドメイン１３１を使用して推論演算を実施する。いったん推論エンジン１１２が第２のドメイン１３１を使用して推論を完了すると、推論エンジン１１２は、第１のドメイン１３１を使用するために戻ることがある。第２のドメイン１３１内の規則１１６を実行することにより、第１のドメイン内の規則１１６がアンペンドすることがあるが、推論エンジン１１２は、第１のドメイン１３１に戻ると直ぐにこれを実行する。

推論エンジン１１２は、１つ以上の推論演算を実施するよう動作可能な、任意のハードウェア、ソフトウェア、ファームウェア、又はそれらの組み合わせを含むことができる。推論エンジン１１２は、たとえば、プロセッサ１２４によって実行される１つ以上のソフトウェアルーチンを含むことができる。推論エンジン１１２の実施形態の例が図６Ａ〜図６Ｃに示されているが、これについて以下に記述する。

クライアントアプリケーション１２２とルールベースビルダ１１０との間の通信を容易にするために、ルールベースビルダ１１０は、アプリケーションプログラムインターフェース（ＡＰＩ）１１８を含むか、又はこれに関連付けられることがある。同様に、推論エンジン１１２は、ＡＰＩ１２０を含むか又はこれに関連付けられることがある。ＡＰＩ１１８、１２０により、クライアントアプリケーション１２２は、ルールベースビルダ１１０及び推論エンジン１１２の機能を起動することができる。たとえば、クライアントアプリケーション１２２は、ルールベース１１４の識別情報をＡＰＩ１１８を通じてルールベースビルダ１１０に供給することにより、２つのルールベース１１４をマージするよう、ルールベースビルダ１１０に指示することができる。同様の方法で、クライアントアプリケーション１２２は、ルールベース１１４の識別情報及び入力値をＡＰＩ１２０を通じて推論エンジン１１２に供給することにより、推論エンジン１１２の推論機能を起動することができる。

特定の実施形態においては、ルールベースビルダ１１０は、ステートレスＡＰＩ１１８、ステートフルＡＰＩ１１８、又はその両方に関連付けられ得る。同様に、推論エンジン１１２も、ステートレスＡＰＩ１２０、ステートフルＡＰＩ１２０、又はその両方に関連付けられ得る。ステートフルＡＰＩ１１８、１２０は、サーバ１０２と通信するクライアントアプリケーション１２２を必要とする、セッション指向の状態情報を保持することがある。状態情報とは、たとえば、サーバ１０２とクライアントアプリケーション１２２が動作しているクライアント１０８との間に生じているセッションの現在のステータスであり得る。ステートレスＡＰＩ１１８、１２０は、サーバ１０２と通信するクライアントアプリケーション１２２を必要とする、セッション指向の状態情報を保持しないことがある。

ステートレスＡＰＩ１１８、１２０は、ネットワーク１０６を介する遠隔サービスとして、ルールベースビルダ１１０又は推論エンジン１１２を起動するために使用され得る。ステートフルＡＰＩ１１８、１２０により、サーバ１０２は、サーバ１０２にアクセスしているクライアントアプリケーション１２２に追加機能を提供できる。たとえば、ステートフルＡＰＩ１１８、１２０を使用することにより、サーバ１０２は、「コールバック」を提供することができる。コールバック中に、ルールベースビルダ１１０又は推論エンジン１１２は、ルールベースビルディング又は推論中に、クライアントアプリケーション１２２に追加情報を要求するか又は情報を供給する。このことにより、たとえば、サーバ１０２は、フィールド値の変更がいつ生じるかをクライアントアプリケーション１２２に知らせることができる。

コールバックにより、サーバ１０２が、事前条件値又は他の値を初期設定するよう起動する方法を定義することもできる。たとえば、サーバ１０２は、クライアントアプリケーション１２２が、「最後のチャンスの処理」中に生じることのある、特定のフィールドのための既知の値を提供するよう要求することができる。推論中に、推論エンジン１１２は、フィールドが解決できない未知の値を有するために、推論を完了できないことがある。これが生じた場合には、推論エンジン１１２は、クライアントアプリケーション１２２に、未知のフィールドのための値を提供するよう頼むことができる。クライアントアプリケーション１２２がその値を提供すると、推論エンジン１１２は、推論演算を続行するか又は完了することができる。別の実施形態においては、ルールベース１１４は、最後のチャンスの処理中に使用する最後のチャンスの値を提供することができる。この実施形態においては、推論中に推論エンジン１１２がそのフィールドの値を解決できない場合に、推論エンジン１１２は、フィールドのための最後のチャンスの値を使用する。推論エンジン１１２がクライアントアプリケーション１２２に第１の値を要求したが、クライアントアプリケーション１２２が第１の値を提供できない場合に、ルールベース１１４からの第２の値を使用する場合などに、これらのアプローチを組み合わせて使用することもできる。

ツール１２８は、システム１００内のルールベース１１４の開発及び維持を支援する。たとえば、ルールエディタ１３２は、ユーザが規則１１６を作成するのを支援する。ルールエディタ１３２により、ユーザは、規則１１６を作成し、編集することができる。特定の例として、ルールエディタ１３２により、ユーザは、規則１１６を包含するＸＭＬ文書を作成し、規則１１６を包含する既存のＸＭＬ文書を編集し、規則１１６を包含するＸＭＬ文書を消去することができる。

ツール１２８はまた、１つ以上のトランスフォーマ１３３も含むことがある。トランスフォーマ１３３は、規則１１６を、あるフォーマットから異なるフォーマットに変換する。たとえば、トランスフォーマ１３３は、自然言語を用いて定義された規則１１６を受け取り、この規則１１６をＸＭＬフォーマットに変換することができる。このことにより、ユーザは、より簡単な表記法又は文法を用いて規則１１６を入力することができる。一実施形態においては、トランスフォーマ１３３は、インフィックスからＸＭＬにＪａｖａ符号化されたユーティリティアプリケーションを含むことができる。グラフィカルエディタ又はドロップダウンメカニズムなどの他のトランスフォーマ１３３も使用されることがある。

ツール１２８は、さらに、１つ以上のアナライザ１３４を含むことがある。アナライザ１３４は、２進又はソースルールベース１１４を調べ、データオブジェクトと規則１１６との間の関係を識別する。たとえば、ユーザは、特定のデータオブジェクトを識別し、アナライザ１３４は、データオブジェクトから値を読み取る又はデータオブジェクトに値を書き込む規則１１６を識別することがある。

ツール１２８はまた、１つ以上のデバッガ１３６を含むことがある。デバッガ１３６は、推論中に規則１１６の実行を監視する。たとえば、デバッガ１３６は、推論エンジン１１２に供給された入力値、推論中にファイアされた規則１１６、規則１１６がファイアされる順序、及びそれぞれの規則１１６がファイアされた理由を識別することができる。次いで、この情報を使用して、生じた推論演算を分析することがある。このことは、ルールベース１１４が適切な結果を提供しないので、ユーザが、何故ルールベース１１４が期待通りに動作しなかったのかを識別することを望む場合に有用であり得る。

その上、ツール１２８は、１つ以上のテスタ１３８を含むことがある。テスタ１３８は、ルールベース１１４、ルールセット１３０、又は１組の規則１１６が意図した通りに機能することを確実にすることにより、ユーザを支援する。たとえば、テスタ１３８は、ルールベース１１４、１組の入力値、及び１組の期待される出力値を識別する情報を受け取ることができる。次いで、テスタ１３８は、識別されたルールベース１１４及び入力値を用いて推論エンジン１１２を起動し、計算された出力値を推論エンジン１１２から受け取り、計算された出力値が期待される出力値に合致するかどうかを判断する。特定の実施形態においては、テスタ１３８は、複数の組の入力値及び対応する出力値を包含するライブラリにアクセスして、識別されたルールベース１１４を試験することができる。

それぞれのツール１２８は、システム１００内の１つ以上の機能を実施するよう動作可能な、任意のハードウェア、ソフトウェア、ファームウェア、又はそれらの組み合わせを含むことができる。また、それぞれのツール１２８は、ＡＰＩ１１８、１２０を使用して、ルールベースビルダ１１０又は推論エンジン１１２内の機能を起動することができる。

一実施形態においては、ルールベース１１４は、それ自体のデータオブジェクトを定義することができ、またルールベース１１４は、ルールベース１１４内に埋め込まれた論理に依拠するアプリケーションとは無関係に開発され、使用され得る。たとえば、専用クライアントアプリケーション１２２が１群のユーザによって開発され、別の１群のユーザが、クライアントアプリケーション１２２によって使用されるルールベース１１４を開発することができる。特定の例として、ルールベース１１４又はルールベース１１４内のドメイン１３１は、事前条件、又は入力値、及び事後条件、又は出力値を定義することができる。ルールベース１１４を開発しているユーザは、事前条件及び事後条件を識別することができ、次いで、クライアントアプリケーション１２２を開発しているユーザは、適切な事前条件を推論エンジン１１２に伝え、かつ推論エンジン１１２から適切な事後条件を受け取るように、クライアントアプリケーション１２２が設計されることを確実にすれば良い。また、ルールベース１１４は、ルールベース１１４を使用して推論を起動するクライアントアプリケーション１２２とは別に、それ自体のデータオブジェクトを定義することができるので、複数のクライアントアプリケーション１２２がルールベース１１４を共用することができる。これらのクライアントアプリケーション１２２は、たとえ１つのクライアントアプリケーション１２２のための推論が、別のクライアントアプリケーション１２２のための推論に、部分的に又は完全にオーバラップしていても、同じルールベース１１４を使用して推論を起動することができる。

図１は、推論サービスを提供するためのシステム１００の例を示しているが、システム１００に対しては様々な変更が行われ得る。たとえば、図１は、サーバ１０２の機能部分の一例を示している。サーバ１０２の様々な構成要素を組み合わせるか又は省略することがあり、特定のニーズにより、追加構成要素を追加することがある。特定の例として、ルールベースビルダ１１０又は推論エンジン１１２をサーバ１０２から省略することができ、又はルールベースビルダ１１０及び推論エンジン１１２が、別個のプラットフォーム上に常駐することができる。また、データベース１０４は、システム１００内に必要に応じて他の任意の情報を格納することができ、データベース１０４及びメモリ１２６は、サーバ１０２からアクセスできる１つ又は複数の場所に常駐することができる。さらに、サーバ１０２は、他の又は追加のツール１２８をサポートすることができ、ルールベース１１４は、データベース１０４以外の場所に常駐することができる。その上、推論エンジン１１２は、規則１１６の前向き連鎖又は後ろ向き連鎖のいずれかをサポートすることができ、ルールベースビルダ１１０及び推論エンジン１１２への他のインターフェースを、システム１００内で使用することもできる。

図２は、本発明の一実施形態による推論サービスを提供するためのシステム２００の別の例を示す例示的ブロック図である。例示されている実施形態においては、システム２００は、サーバ２０２と、データベース２０４と、ネットワーク２０６と、１つ以上のクライアント２０８とを含む。

サーバ２０２、データベース２０４、ネットワーク２０６、及びクライアント２０８は、図１のサーバ１０２、データベース１０４、ネットワーク１０６、及びクライアント１０８と同じか又は同様であり得る。この実施形態においては、ルールベースビルダ２１０及び推論エンジン２１２は、サーバアプリケーション２５０の一部分を形成する。サーバアプリケーション２５０とは、クライアントアプリケーション２２２がネットワーク２０６を介して起動することのできるアプリケーションである。サーバアプリケーション２５０は、たとえば、医学又は法律分野に関連付けられたアプリケーションなどの、エキスパートアプリケーションであり得る。

オペレーションの一態様においては、サーバアプリケーション２５０は、クライアントアプリケーション２２２から要求を受け取って、ルールベース２１４をビルドするか又は推論演算を実施することができる。サーバアプリケーション２５０は、ルールベースビルダ２１０又は推論エンジン２１２のインスタンスを作成し、そのインスタンスが好適なオペレーションを実施できるようにする。

例示されている実施形態においては、サーバアプリケーション２５０は、サーバＡＰＩ２５２を含む。サーバＡＰＩ２５２により、クライアントアプリケーション２２２は、サーバアプリケーション２５０の機能を起動することができる。たとえば、クライアントアプリケーション２２２は、ルールベースビルダインスタンスを作成するサーバアプリケーション２５０の機能を起動することができ、クライアントアプリケーション２２２は、複数のソースルールベース２１４を識別することができる。サーバアプリケーション２５０は、サーバＡＰＩ２５２を通じて受け取られた情報をルールベースビルダインスタンスに渡すことができ、これにより、ルールベースビルダインスタンスは、識別されたルールベース２１４をマージし、コンパイルすることができる。サーバＡＰＩ２５２とは、ステートフルインターフェース、ステートレスインターフェース、又は他のインターフェース、又はインターフェースの組み合わせであり得る。

特定の実施形態においては、サーバアプリケーション２５０とは、Ｊａｖａアプリケーション、Ｊ２ＥＥサーブレット、エンタプライズＪａｖａＢｅａｎｓ（ＥＪＢ）アプリケーション、ＪａｖａＳｅｒｖｅｒＰａｇｅｓ（ＪＳＰ）アプリケーション、又は他の好適なアプリケーションである。この実施形態においては、ＡＰＩ２１８、２２０は、サーバアプリケーション２５０がローカルサービスとして起動することのできるステートフルインターフェースを含むことがある。その上、サーバアプリケーション２５０は、クライアントアプリケーション２２２により、遠隔サービスとしてＡＰＩ２５２を通じて起動され得る。

図２は、推論サービスを提供するためのシステム２００の例を示しているが、システム２００に対しては様々な変更が行われ得る。たとえば、図２は、サーバ２０２の機能部分の一例を示しているが、サーバ２０２の様々な構成要素を組み合わせたり又は省略したりすることがあり、特定のニーズにより、追加構成要素を追加することがある。特定の例として、ルールベースエンジン２１０又は推論エンジン２１２を、サーバ２０２から省略することができる。

図３は、本発明の一実施形態による推論サービスを提供するためのシステム３００のさらに別の例を示す例示的ブロック図である。例示されている実施形態においては、システム３００は、アプリケーション３６２を実行するホストコンピュータ３６０を含む。

例示されている実施形態においては、ホスト３６０は、周知のＭＳ−ＤＯＳ、ＰＣ−ＤＯＳ、ＯＳ−２、ＭＡＣ−ＯＳ、ＷＩＮＤＯＷＳ、ＵＮＩＸ、ＬＩＮＵＸ、又は他の適切なオペレーティングシステムのいずれかと共に実行することがある。ホスト３６０とは、デスクトップコンピュータ、ラップトップコンピュータ、サーバコンピュータ、又は他の好適な計算又は通信デバイスであり得る。ホスト３６０は、入力デバイス３６４、出力デバイス３６６、ランダムアクセスメモリ（ＲＡＭ）３６８、読取り専用メモリ（ＲＯＭ）３７０、ＣＤ−ＲＯＭ、ハードドライブ、又は他の磁気又は光学記憶デバイス３７２、及び１つ以上のプロセッサ３７４を含むことがある。入力デバイス３６４は、たとえば、キーボード、マウス、グラフィックスタブレット、タッチスクリーン、感圧パッド、ジョイスティック、ライトペン、マイクロホン、又は他の好適な入力デバイスを含むことがある。出力デバイス３６６は、たとえば、ビデオディスプレイ、プリンタ、ディスクドライブ、プロッタ、スピーカ、又は他の好適な出力デバイスを含むことがある。

図３の破線内の項目は、システム３００の関連構成要素の例示的機能演算及びデータ編成を表している。例示されている実施形態においては、ホスト３６０は、アプリケーション３６２とデータベース３０４とを含む。データベース３０４は、図１及び図２のデータベース１０４及びデータベース２０４と同じか又は同様であり得る。

アプリケーション３６２とは、エキスパートアプリケーション、又はルールベースビルディング及び推論機能を使用する他のアプリケーションであり得る。示されている例においては、アプリケーション３６２は、ルールベースビルダ３１０と、推論エンジン３１２と、他のプログラミング論理３７４とを含む。ルールベースビルダ３１０は、図１のルールベースビルダ１１０及び図２のルールベースビルダ２１０と同じか又は同様であり得る。また、推論エンジン３１２は、図１の推論エンジン１１２及び図２の推論エンジン２１２と同じか又は同様であり得る。その上、ルールベースビルダ３１０及び推論エンジン３１２は、ＡＰＩ３１８及び３２０を含むことがあるが、必ずしも必要なものではない。

追加プログラミング論理３７４とは、ルールベースビルダ３１０及び推論エンジン３１２を起動するアプリケーション３６２内の論理であり得る。たとえば、論理３７４は、ユーザから患者の症状を受け取り、その症状を推論エンジン３１２に渡す医療エキスパートプログラムを実施することができる。推論エンジン３１２が推論を実施した後、論理３７４は、ユーザが利用可能な診断を行うことができる。他の任意の好適な機能が、アプリケーション３６２内の論理３７４によって実施されることがある。

特定の実施形態においては、アプリケーション３６２とは、Ｊａｖａアプリケーションであり得る。また、ＡＰＩ３１８、３２０は、アプリケーション３６２内でローカルサービスとして起動できるステートフルインターフェースを含むことがある。

図３は、推論サービスを提供するためのシステム３００の例を示しているが、システム３００に対しては様々な変更が行われ得る。たとえば、図３は、ホスト３６０の機能部分の一例を示しているが、ホスト３６０の様々な構成要素を組み合わせたり又は省略したりし、特定のニーズにより、追加構成要素を追加することがある。特定の例として、ルールベースビルダ３１０又は推論エンジン３１２を、ホスト３６０から省略することができる。また、図３は、ホスト３６０をデスクトップコンピュータとして例示しているが、他の計算又は通信デバイスを使用することもできる。その上、図１〜図３は、オペレーティング環境の様々な例を示しているが、他の任意の好適な環境において、ルールベースビルダ１１０、２１０、３１０及び推論エンジン１１２、２１２、３１２を使用することもできる。

図４は、本発明の一実施形態によるルールベースアーキテクチャ４００の例を示す例示的ブロック図である。この実施形態においては、ルールベースアーキテクチャ４００は、ルールベースレベルの要素４０２と、ドメインレベルの要素４０４と、ルールセットレベルの要素４０６とを含む。ルールベースアーキテクチャ４００が図１のシステム１００について記述されているが、ルールベースアーキテクチャ４００を他のシステムと共に使用し、システム１００が他のルールベースアーキテクチャを使用することもできる。

図４では、ルールベースレベルの要素４０２は、クラス４０８と、初期設定方法４１０と、関連付け４１２と、制約４１４と、ドメイン４１６とを含む。クラス４０８は、情報を格納するデータオブジェクト、及びデータオブジェクト内の情報を処理する方法オブジェクトを定義する。たとえば、クラス４０８は、ヒトの名前、そのヒトの年齢、及びそのヒトの配偶者（あれば）の名前のためのフィールドを含むＰｅｒｓｏｎオブジェクトを定義することができる。別の例として、クラス４０８は、Ｐｅｒｓｏｎのインスタンスを分析し、そのヒトの年齢を６５の値と比較し、この比較に基づいて、そのヒトが定年退職の年齢に達したかどうかを識別するフラグを設定するＲｅｔｉｒｅｍｅｎｔ方法を定義することができる。

初期設定方法４１０は、サーバ１０２が、様々なオブジェクト内のフィールドを如何に初期設定するかを定義する。たとえば、初期設定方法４１０は、１組のデータオブジェクト内の任意の整数フィールドをゼロの値に初期設定し、任意の文字列フィールドをナル値に初期設定することがある。初期設定方法４１０はまた、最高年齢フィールドを１２０の値に設定するなど、一定の値を設定することもできる。

関連付け４１２は、フィールド間の関係を定義する。たとえば、Ｐｅｒｓｏｎインスタンスが別のＰｅｒｓｏｎインスタンスの配偶者であり、関連付けが、Ｐｅｒｓｏｎインスタンス間の１対１の関係を表すことがある。別の例として、Ｐｅｒｓｏｎインスタンスが複数のＤｕｃｋインスタンスを所有し、関連付けが、ＰｅｒｓｏｎインスタンスとＤｕｃｋインスタンスとの間の１対多数の関係を表すことがある。一実施形態においては、関連フィールドは、２つのクラス４０８内などのアーキテクチャ４００と同じレベルである。特定の実施形態においては、関連付けは２つの役割によって定義される。それぞれの役割が、クラス、及びそのクラスが所有するインスタンス参照フィールドを指定する。１つのオブジェクト内のインスタンス参照フィールドが、別のオブジェクトを指す又は識別する。たとえば、所有権の関連付けが、ＰｅｒｓｏｎクラスのＯｗｎｓフィールドのための１つの役割、及びＤｕｃｋクラスのＩｓＯｗｎｅｄＢｙフィールドのための別の役割を定義することがある。

制約４１４は、フィールドに割り当てられた値に関して真であるべき条件を定義する。制約４１４はまた、条件に違反すると生じるアクションを定義する。たとえば、制約４１４は、ヒトの年齢を格納するフィールドが０〜１２０間の値を有するべきであることを指定することがある。Ｐｅｒｓｏｎのインスタンスに８００の年齢が割り当てられた場合は、年齢フィールドに関連付けられた制約４１４に違反することになり、その制約４１４によって定義されたアクションが実行されることがある。そのアクションは、推論エンジン１１２が、推論を一時停止するステップと、代入値を使用するステップと、又はステートフルインターフェース１２０を使用して、クライアントアプリケーション１２２から正しい値を要求するステップとを含むことがある。

ドメイン４１６は、規則をドメインと呼ばれる異なるグループに分類する。それぞれのドメイン４１６において、ルールベースは、初期設定方法４１８と、関連付け４２０と、制約４２２と、クラス４２４と、ルールセット４２６とを含むことができる。初期設定方法４１８、関連付け４２０、制約４２２、及びクラス４２４は、初期設定方法４１０、関連付け４１２、制約４１４、及びクラス４０８と同じか又は同様であり得る。これらのドメインレベルの要素４０４は、ルールベースレベルの要素４０２とは異なる範囲を有することがある。たとえば、関連付け４１２は、ルールベースレベルに常駐する２つのクラス間の関係を定義し、関連付け４２０は、ドメインレベルに常駐するクラス間の関係を定義することがある。ある実施形態においては、事前及び事後条件が、主要レベルで定義されることがある。

ルールセット４２６は、さらに、規則をルールセットと呼ばれる異なるグループに分類する。それぞれのルールセット４２６において、ルールベースは、初期設定方法４２８と、関連付け４３０と、制約４３２と、クラス４３４と、規則４３６とを含むことができる。これらのルールセットレベルの要素４０６は、対応するルールベースレベルの要素４０２及びドメインレベルの要素４０４とは異なる範囲を有することがある。たとえば、関連付け４３０は、ルールセットレベルに常駐するクラス間の関係を定義することがある。

規則４３６は、入力値を分析し、かつ出力値を生成するために使用される論理を定義する。規則４３６は、クラス４０８、４２４、４３４を使用して作成されるオブジェクトなどの、データオブジェクト内の情報を処理することができる。規則４３６はまた、方法オブジェクト内で定義された方法を使用して、値をデータオブジェクト内のフィールドに割り当てることができる。一実施形態においては、規則４３６は、決定木規則とパターン合致規則とを含む。パターン合致規則の例が図９Ａに示されているが、これについて以下に記述する。決定木規則の例が図９Ｂに示されているが、これについても以下に記述する。

図４は、ルールベースアーキテクチャ４００の一例を示しているが、ルールベースアーキテクチャ４００に対しては様々な変更が行われ得る。たとえば、追加要素を様々なレベルのアーキテクチャ４００に追加することができ、特定のニーズにより、現在の要素を省略することができる。

図５Ａ及び図５Ｂは、本発明の一実施形態によるルールベースビルダの例を示す例示的ブロック図である。具体的には、図５Ａはステートレスルールベースビルダ５００を示し、図５Ｂはステートフルルールベースビルダ５５０を示している。図５Ａ及び図５Ｂは、図１のシステム１００について記述しているが、ルールベースビルダ５００、５５０を、他のシステムと共に使用することもできる。

図５Ａでは、ステートレスルールベースビルダ５００により、アプリケーションは、様々な関数呼出し５０２を起動することができ、関数呼出し５０２は、様々なデータ構造５０４を入力及び出力として使用する。例示されている実施形態においては、関数呼出し５０２は、生成関数５０６とビルド関数５０８とを含む。生成関数５０６は、ルールベースビルディングサービスを要求するアプリケーションが使用するルールベースビルダ５００のインスタンスを作成する。たとえば、クライアントアプリケーション１２２は、ネットワーク１０６を介して生成関数５０６を起動することがある。サーバ１０２は、生成関数５０６を実行し、ルールベースビルダインスタンスを作成するルールベースビルダ５００のインスタンスを生成する。次いで、クライアントアプリケーション１２２からの追加関数呼出しが、そのルールベースビルダインスタンスに向けられる。複数のクライアントアプリケーション１２２がルールベースビルディングサービスを要求すると、サーバ１０２は、生成関数５０６を実行して、ルールベースビルダ５００の複数のインスタンスを作成することがある。

ビルド関数５０８により、ルールベースビルダインスタンスは、ルールベース、規則、及びルールセットなどの様々な入力を、統合されたルールベースにマージする。ビルド関数５０８は、２進ルールベース５１０、文字列５１２ａ〜５１２ｂ、及び制御オブジェクト５１３を、入力として受け入れることがある。入力文字列５１２ａとは、コンパイルされていない、即ちソースルール、ルールベース、及びルールセットを含むＸＭＬ文字列である。入力文字列５１２ｂとは、コンパイルされた又はコンパイルされていない規則、ルールベース、及びルールセットの遠隔場所を識別するユニフォームリソースロケータ（ＵＲＬ）である。統合されたルールベースをビルドする前に、ルールベースビルダインスタンスは、ＵＲＬによって識別された遠隔場所にアクセスし、その場所で、任意の規則、ルールベース、又はルールセットを検索することがある。

サーバ１０２は、制御オブジェクト５１３内に包含された値５２８を使用して、ビルド関数５０８を実行する場合に、ルールベースビルダインスタンスが実施すべき異なる関数を識別する。たとえば、値５２８ａは、ルールベースビルダインスタンスに、アプリケーションインターフェース文書５２２を生成すべきかどうかを指示する。値５２８ｂは、ルールベースビルダインスタンスに、２進ルールベース５１６を生成すべきかどうかを指示する。値５２８ｃは、ルールベースビルダインスタンスに、ロードマップ５２４を生成すべきかどうかを指示する。値５２８ｄ〜５２８ｆは、ルールベースビルダインスタンスに、メッセージ５２６内に記述されていることのある様々なタイプの事象を追跡すべきかどうかを指示する。この例においては、事象は、高レベル又はＬ１事象、低レベル又はＬ２事象、及びローダ事象に分割されることがある。事象の他の分割を使用することもできる。

ビルド関数５０８が起動された場合には、ルールベースビルダインスタンスは、入力規則、ルールベース、及びルールセットを組み合わせ、出力結果５１４を生成しようとすることがある。出力結果５１４は、統合された２進ルールベース５１６を含むことがある。ルールベース５１６とは、入力が統合されたルールベースにマージされ、コンパイルされた場合に形成されるルールベースである。出力結果５１４はまた、誤り件数５１８と警告件数５２０とを含むことがある。誤り件数５１８は、統合されたルールベース５１６を作成した場合に識別された誤りの数を識別し、警告件数５２０は、生成された警告の数を識別する。

出力結果５１４は、さらに、アプリケーションインターフェース文書５２２とロードマップ５２４とを含むことがある。アプリケーションインターフェース文書５２２は、ルールベース５１６によって使用される入力値、及びルールベース５１６によって作成される出力値を記述する。アプリケーションインターフェース文書５２２は、２進ルールベース５１６が開発中のアプリケーションと合わせて使用される場合に有用であり得る。アプリケーションインターフェース文書５２２は、ルールベース５１６に関連付けられた入力及び出力を記述することができ、アプリケーションを作成している開発者は、アプリケーションが適切な入力をルールベース５１６に送信し、かつルールベース５１６から適切な出力を期待することを確実にすることができる。

ロードマップ５２４は、ルールベース５１６内の様々なオブジェクトを識別する。ロードマップ５２４はまた、ルールベース５１６内のオブジェクトと、そのオブジェクトに影響を及ぼすルールベース５１６内の任意の規則との間の関係を識別する。たとえば、ロードマップ５２４は、所与のオブジェクトについて、オブジェクトからの値を読み取る又は値をオブジェクトに書き込む規則を識別することがある。システム１００内の別の構成要素などにより、ロードマップ５２４をさらに処理して、ルールベースレポートを生成することができる。ルールベースレポートは、ルールベース５１６内の規則、規則間の相互作用、又は他の好適な情報を識別することができる。

出力結果５１４はまた、１組のゼロ以上のメッセージ５２６を含むことができる。メッセージ５２６は、統合されたルールベース５１６の作成中に生成された誤り及び警告メッセージを含むことができる。メッセージ５２６はまた、統合されたルールベース５１６の作成又はコンパイル中に生じる異なる事象を識別するために使用されるメッセージなどの、トレースメッセージを含むことができる。

オペレーションの一態様においては、出力結果５１４のコンテンツは、値５２８により変わることができる。たとえば、値５２８ａが偽の値を有する場合は、出力結果５１４は、アプリケーションインターフェース文書５２２を含まない。同様に、値５２８ｃが真の値を有する場合は、出力結果５１４は、ロードマップ５２４を含む。値５２８ｂが偽の値を有する場合は、出力結果５１４は、２進ルールベースを含まない。このことは、たとえばアプリケーションインターフェース文書５２２又はロードマップ５２４が既存２進ルールベースに必要な場合に有用であり得る。

図５Ｂでは、ステートフルルールベースビルダ５５０により、アプリケーションは、データ構造５５４を入力及び出力として使用する様々な関数呼出し５５２を起動することができる。例示されている実施形態においては、関数呼出し５５２は、生成関数５５６を含む。生成関数５５６は、ルールベースビルディングサービスを要求するアプリケーションが使用するルールベースビルダ５５０のインスタンスを作成する。生成関数５５６は、２つの入力値、トレースマスク５６８とメッセージハンドラ５７０とを含む。トレースマスク５６８のために提供された値が、クライアントアプリケーション１２２に提供されたトレースメッセージの詳細レベルを判断する。詳細レベルは、トレースメッセージが提供されるかどうかを識別し、提供される場合には、どのような状況でトレースメッセージが提供されるべきであるかを識別することがある。以下に記述するように、メッセージハンドラ５７０は、クライアントアプリケーション１２２とルールベースビルダインスタンスとの間で情報を通信するために使用されるハンドラを識別する。メッセージハンドラ５７０により、たとえば、ルールベースビルダ５５０は、コールバックオペレーションを実施し、クライアントアプリケーション１２２から情報を要求することができる。

ルールベース追加機能５５８ａ〜５５８ｃは、統合されたルールベースにマージされる、異なるルールベース、規則、及びルールセットを識別する。ルールベース追加機能５５８ａは、統合されたルールベースを生成する場合に使用される、２進ルールベース、規則、又はルールセットを受け入れる。ルールベース追加機能５５８ｂは、統合されたルールベースを生成する場合に使用される、ソース即ちコンパイルされていないルールベース、規則、又はルールセットを受け入れる。ルールベース追加機能５５８ｃは、統合されたルールベースを生成する場合に使用される、ルールベース、規則、又はルールセットの遠隔場所を識別するＵＲＬを受け入れる。それぞれのルールベース、規則、又はルールセットは、ルールベース追加機能５５８ａ〜５５８ｃを使用して追加される時に、以前に追加されたルールベース、規則、及びルールセットと共にマージされる。コンパイル機能５６０は、マージされたルールベースをコンパイルして、２進ルールベースを作成する。

アプリケーションインターフェース文書生成機能５６２が、アプリケーションインターフェース文書を生成する。２進ルールベース生成機能５６４は、出力ストリームを通じてクライアントアプリケーション１２２に２進ルールベースを提供し、クライアントアプリケーション１２２は、出力ストリームをバッファ又は他のメモリ内に格納することができる。ロードマップ生成機能５６６が、ルールベースのためのロードマップを生成する。

ステートフルルールベースビルダ５５０がセッション情報を維持しているので、ルールベースビルダ５５０によってサポートされている様々な関数呼出し５５２は、クライアントアプリケーション１２２により個々に起動され得る。たとえば、クライアントアプリケーション１２２を使用しているユーザが、既存２進ルールベースのためのアプリケーションインターフェース文書を望むことがある。クライアントアプリケーション１２２は、ルールベース追加機能５５８ａの１つを使用して、２進ルールベースをビルダ５５０に供給することができる。次いで、クライアントアプリケーション１２２は、機能５６２を起動することにより、アプリケーションインターフェース文書を生成することができる。ユーザが、その後、ロードマップを生成することを決定すると、クライアントアプリケーション１２２は、機能５６６を起動し、同じルールベースビルダインスタンスを使用してロードマップを生成することができる。

図５Ａ及び図５Ｂは、ルールベースビルダ５００、５５０の例を示しているが、ルールベースビルダ５００、５５０に対しては様々な変更が行われ得る。たとえば、様々な関数呼出し５０２、５５２を、特定のニーズにより、ビルダ５００、５５０から省略することができる。また、追加関数呼出し５０２、５５２を、ビルダ５００、５５０に追加することができる。その上、図５Ａ及び５Ｂは、関数呼出し５０２、５５２と共に使用されるデータ構造５０４、５５４の例を示しているが、他の又は追加のデータ構造も使用することができる。

図６Ａ〜図６Ｃは、本発明の一実施形態による推論エンジンの例を示す例示的ブロック図である。具体的には、図６Ａは、ステートレス推論エンジン６００を示す図であり、図６Ｂ及び図６Ｃは、ステートフル推論エンジン６５０を示す図である。図６Ａ〜図６Ｃは、図１のシステム１００について記述しているが、推論エンジン６００、６５０を他のシステムと共に使用することもできる。

図６Ａでは、ステートレス推論エンジン６００により、アプリケーションは、データ構造６０４を入力及び出力として使用する関数呼出し６０２を起動することができる。例示されている実施形態においては、関数呼出し６０２は、アプリケーションが使用する推論エンジン６００のインスタンスを作成する生成関数６０６を含む。関数呼出し６０２はまた、２つの推論機能６０８、６１０を含む。

推論機能６０８は、入力としてエンジン６００に提供されるルールベース６１２及び制御オブジェクト６１３を使用してエンジン６００により、推論を起動する。ルールベース６１２は、図４のドメイン４１６で示されているような、複数のドメインを含むことがある。その結果、推論機能６０８はまた、ドメイン名６１４を入力として受け取り、このドメイン名６１４は、推論中にどのドメイン４１６を使用するかを識別する。推論機能６０８はさらに、推論中に作成され、かつ使用される任意の動的インスタンス６１６の識別情報を受け取る。推論機能６０８はまた、ドメイン名６１４によって識別されるドメインと共に使用される追加規則である条件付きルールセット６１８を受け取る。その上、推論機能６０８は、事前条件値６２０ａ〜６２０ｂを入力として受け取ることがある。事前条件値６２０は、識別されたルールベース６１２内の適切なフィールドに割り当てられ、推論中に使用される。事前条件値６２０は、事前条件値文書６２０ａ又は事前条件値アレイ６２０ｂの形式をとることがある。

制御オブジェクト６１３は、推論エンジンインスタンスによって実施されるオペレーションを制御するために、サーバ１０２が使用する値６３２ａ〜６３２ｆを定義する。値６３２ａは、推論エンジンインスタンスに、フィールド値アレイ６２６ｂを生成するよう指示し、値６３２ｂは、推論エンジンインスタンスに、フィールド値文書６２６ａを生成するよう指示する。値６３２ｃは、推論エンジンインスタンスに、規則スナップショット６３０を生成するよう指示する。値６３２ｄ〜６３２ｆは、推論エンジンインスタンスに、メッセージ６２８内に記述されることのある様々なタイプの事象を追跡するよう指示する。この例においては、事象は、Ｌ１事象、Ｌ２事象、及び推論事象に分割されることがある。事象の他の分割も使用することができる。

推論機能６１０は、同じ入力の多くを推論機能６０８として受け取る。推論機能６０８は、２進ルールベース６１２を受け取り、推論機能６１０は、推論中に使用されるルールベースの場所を識別するＵＲＬ入力６２２を受け取る。

両方の推論機能６０８、６１０は、出力結果６２４を返す。出力結果６２４は、１組のゼロ以上のフィールド値６２６ａ〜６２６ｂを含むことがある。フィールド値６２６とは、推論中に推論エンジン６００により、事後条件に割り当てられる値である。値６３２ａ及び６３２ｂにより、フィールド値６２６は、フィールド値文書６２６ａ又はフィールド値アレイ６２６ｂの形式をとることがある。出力結果６２４はまた、１組のゼロ以上のメッセージ６２８を含むことがある。メッセージ６２８は、推論演算中に作成された、誤りメッセージと、警告メッセージと、トレースメッセージとを含むことができる。

出力結果６２４は、さらに、規則スナップショット６３０を含むことがある。規則スナップショット６３０は、特定の時点での規則の現在のステータスについての情報を提供する。規則スナップショット６３０は、規則、規則に関連付けられたルールセット、規則の優先順位、規則に関連付けられた規則のタイプ、規則のステータス、及び規則を保留する規則内のフィールドを識別することができる。

図６Ｂ及び図６Ｃでは、ステートフル推論エンジン６５０により、アプリケーションは、データ構造６５４を入力及び出力として使用する様々な関数呼出し６５２を起動することができる。例示されている実施形態においては、生成関数６５４ａ〜６５４ｃは、推論エンジン６５０のインスタンスを作成する。具体的には、関数６５４ａは、入力ストリームを使用して定義された２進ルールベースを使用する推論エンジンインスタンスを作成し、関数６５４ｂは、ＵＲＬを使用して定義された２進ルールベースを使用する推論エンジンインスタンスを作成する。以下に説明するように、複数の推論エンジンインスタンスは同じルールベースを使用し、関数６５４ｃは、同じルールベースを使用している別の推論エンジンインスタンスに基づいて、１つの推論エンジンインスタンスを作成する。

ドメイン機能６５６ａ〜６５６ｂは、どのドメイン４１６が推論中に使用されるかを制御する。ドメイン機能６５６ａは、推論中に使用されるドメイン４１６を識別し、ドメイン機能６５６ｂは、ドメイン４１６を除去するので、推論中には使用されない。入力関数６５８ａ〜６５８ｂは、事前条件のための値を推論エンジン６５０に供給する。具体的には、関数６５８ａは、特定の事前条件のための値を提供し、関数６５８ｂは、現在のドメイン４１６に関連付けられた１組の事前条件のための値を提供する。条件付きルールセット機能６６０は、現在のドメイン４１６と共に使用される推論エンジン６５０に追加ルールセットを供給する。動的インスタンス機能６６２は、推論中に使用される動的インスタンスを作成する。推論機能６６４は、現在のドメイン４１６内に包含されている規則を使用して、推論プロセスを開始する。出力関数６６６は、推論エンジン６５０によって計算された事後条件のための値を供給する。具体的には、関数６６６ａは、１組の事後条件のための値を包含する出力値文書を作成し、関数６６６ｂは、指定された事後条件の値を提供し、関数６６６ｃは、すべての事前条件及び事後条件の値を提供する。スナップショット機能６６８は、現在のドメインのための規則スナップショットを生成し、出力する。

ステートフル推論エンジン６５０はセッション情報を維持しているので、推論エンジン６５０により、追加機能が提示されることがある。たとえば、推論エンジン６５０は、推論中に、如何にあるフィールドに値が割り当てられるかを判断するために使用される説明サービスを提供することがある。説明開始機能６７０は、フィールドの識別情報を入力として受け取り、そのフィールドに最終値を割り当てた規則を識別する。規則ファイアリング説明機能６７２は、説明開始機能６７０によって識別された規則を使用し、何が原因でその規則がファイアされるのかを判断する。このことには、規則をファイアしたフィールド及びこれらのフィールドの値を識別することが含まれることがある。フィールド解決説明機能６７４は、規則ファイアリング説明機能６７２によって識別されたフィールドを使用し、如何にそのフィールドに値が割り当てられたかを判断する。これらの機能６７０〜６７４により、クライアントアプリケーション１２２は、如何にかつ何故、推論中にフィールドに値が割り当てられたかを追跡する。これらの機能６７０〜６７４は、サーバ１０２が、推論中に実施された様々なステップを監視し、かつ保管することを必要とすることがある。この監視により、推論中に追加処理要件が課されることがあるので、追跡機能６７６ａ〜６７６ｂにより、クライアントアプリケーション１２２は、サーバ１０２が推論中に実施されるステップを、いつ監視すべきかを指定することができる。このことにより、クライアントアプリケーション１２２は、この追加処理が必要な時を制御することができる。

ステートフル推論エンジン６５０を使用することにより、また、サーバ１０２は、真理維持（「ＴＭ」）機能をクライアントアプリケーション１２２に提供できることがある。推論中に、既知の値をフィールドに割り当てることにより、帰結のカスケードをトリガすることができる。たとえば、フィールドが既知の値を有していないために、規則が以前に保留された場合は、そのフィールドに値を割り当てることにより、推論エンジン６５０が、その規則をアンペンドし、次いでファイアすることがある。ファイアされた規則は他のフィールドを解決し、これにより、推論エンジン６５０は追加規則をアンペンドし、ファイアする。真理維持とは、クライアントアプリケーション１２２が、フィールドへの値の割当てを撤回し、逆転させることのできる機構であり、これにより、その割当ての帰結を撤回する。つまり、真理維持機能は、「ｗｈａｔ−ｉｆ」タイプの論法に対して有用であり得る。特定の例として、貸付承認アプリケーションにおいて、借り手が、貸付額、貸付期間、及び金利などの、いくつかの異なる変数を試みることを望むことがある。このような状況においては、仮定のシナリオの集合に対する「回答」はなく、いくつかの代替シナリオを試みた後に初めて、回答が分かることがある。

真理維持をサポートするために、ＴＭ値設定機能６７８は、特定のフィールドに撤回可能な値が割り当てられることがあることを示す。撤回可能な値とは、否定できる割当て中に割り当てられる値である。クライアントアプリケーション１２２は、選択されたフィールドに複数の値を割り当てることがある。ＴＭ値確認機能６８０は、特定のフィールドの現在の値を、そのフィールドの撤回不可能な値として設定する。撤回不可能な値とは、否定できない割当て中に割り当てられる値である。ＴＭ値撤回機能６８２は、フィールドをそれの最後の撤回不可能な値にまで撤回する。オペレーション中に、クライアントアプリケーション１２２は、５つの撤回可能な値をフィールドに割り当てることができる。次いで、クライアントアプリケーション１２２は、撤回不可能な値を、続いてさらに７つの撤回可能な値を、フィールドに割り当てることができる。この例においては、フィールドに割り当てられた最後の７つの値は、撤回することができるが、最初の５つは、撤回することができない。撤回不可能な値が存在することにより、推論エンジン６５０が、撤回不可能な値が割り当てられる前に割り当てられた値を撤回することが防止される。貸付の例に戻ると、選択されたフィールドとは、借り手が受け取りたいと望む貸付額であり得る。実験中に、フィールドに複数の撤回可能な値が割り当てられることがある。最終的に、ユーザは、借り手が受け取ることのできる最高額を識別することがある。この最高額を撤回不可能な値として割り当てることができる。追加の撤回可能な値をフィールドに割り当てる追加実験をすることができる。これらの追加値のいずれも、貸付額として受け入れることができ、又はその値を、撤回不可能な値として識別された最後の最高貸付額に撤回することができる。

これらの機能に加えて、ハンドラ機能６８４ａ〜６８４ｂは、推論エンジンインスタンスと共に様々な通信ハンドラを登録する。以下に記述するように、ハンドラ機能により、推論エンジンインスタンスは、推論中にクライアントアプリケーション１２２と通信することができる。リセット機能６８６は、推論エンジンインスタンスを初期状態にリセットする。このことには、たとえば、推論エンジン６５０が、すべてのフィールド値を未知の状態にリセットするステップと、すべての動的インスタンスを消去するステップと、すべてのドメインをポップするステップと、任意のルールベースレベルの初期設定方法４１０を実行するステップとが含まれることがある。

図６Ａ〜図６Ｃは、推論エンジン６００、６５０の例を示しているが、推論エンジン６００、６５０に対しては様々な変更が行われ得る。たとえば、様々な関数呼出し６０２、６５２を、特定のニーズにより、推論エンジン６００、６５０から省略することができる。また、追加の関数呼出し６０２、６５２を、推論エンジン６００、６５０に追加することができる。その上、図６Ａ〜図６Ｃは、関数呼出し６０２、６５２と共に使用されるデータ構造６０４、６５４の例を示しているが、他の又は追加のデータ構造を使用することもできる。

図７は、本発明の一実施形態によるコアオブジェクト７００の例を示す例示的ブロック図である。コアオブジェクト７００とは、ルールベースビルダ５００、５５０と推論エンジン６００、６５０の両方によって共用されるオブジェクトである。図７は、図２のシステム２００について記述しているが、コアオブジェクト７００を他のシステムと共に使用することもできる。

図７では、コアオブジェクト７００は、様々なデータ構造７０２を使用して、ルールベースビルダ５００、５５０、及び推論エンジン６００、６５０と通信する。データ構造７０２は、メッセージハンドラ７０４を含む。メッセージハンドラ７０４とは、クライアントアプリケーション２２２と通信するために使用されるハンドラである。たとえば、メッセージハンドラ７０４は、ルールベースビルダ５００、５５０、又は推論エンジン６００、６５０からのメッセージ７０６を傍受するために使用され得る。このことにより、メッセージハンドラ７０４は、ルールベースビルダ５００、５５０又は推論エンジン６００、６５０によって生成された、誤り、警告、追跡、又は他のメッセージ７０６を捕捉できる。データ構造７０２はまた、例外７０８を含む。例外７０８は、ルールベースビルディング又は推論中に検出された誤りを識別する。

データ構造７０２は、さらに、トレースマスク７１０を含むことがある。トレースマスク７１０は、サーバ１０２による異なる機能の実行を如何に追跡すべきかを示す。トレースマスク７１０に提供された整数値は、クライアントアプリケーション２２２に提供されたトレースメッセージの詳細さのレベルを判断する。詳細さのレベルは、トレースメッセージが提供されるかどうか、そして提供される場合には、どのような状況でトレースメッセージが提供されるべきであるかを識別する。たとえば、値がゼロの時には、サーバ２０２はトレースメッセージを提供せず、値が１の時には、サーバ２０２はより広範囲なトレースメッセージを提供し、これより高い値の時には、サーバ２０２はより具体的なトレースメッセージを提供することができる。この例においては、事象は、推論事象、Ｌ１事象、Ｌ２事象、及びローダ事象に分割される。事象の他の分割も使用することができる。

図７は、コアオブジェクト７００の一例を示しているが、コアオブジェクト７００に対しては様々な変更が行われ得る。たとえば、他の任意の又は追加のデータ構造７０２を使用することもできる。

図８は、本発明の一実施形態によるインターフェース８００の例を示す例示的ブロック図である。この実施形態においては、インターフェース８００は、初期設定ハンドラ８０２と変更ハンドラ８０４とを含む。図８は、図１のシステム１００について記述しているが、インターフェース８００を他のシステムと共に使用することもできる。

初期設定ハンドラ８０２により、クライアントアプリケーション１２２は、フィールド値を初期設定することができる。たとえば、推論エンジン６５０が推論中に規則を実行しようとするが、この規則が未知のフィールドを伴っていることがある。推論エンジン６５０は、この規則を保留して、未知のフィールドが後に解決されるかどうかを見ることができる。この規則を保留する代わりに、又はこれに加えて、推論エンジン６５０は、初期設定ハンドラ８０２を起動し、クライアントアプリケーション１２２に、クライアントアプリケーション１２２が未知のフィールドのための値を提供することを望むかどうかを尋ねることができる。クライアントアプリケーション１２２が値を提供すると、推論エンジン６５０は、その値を使用し、推論を続行することができる。

初期設定ハンドラ８０２を使用することは、１つのルールベースに多数の事前条件が存在する場合に、有用であり得る。たとえば、ルールベースは、１，０００の事前条件を有することができる。初期設定ハンドラ８０２を使用しない場合は、クライアントアプリケーション１２２は、推論が開始される前に、すべての１，０００の事前条件のための入力値を提供する。初期設定ハンドラ８０２を使用する場合は、クライアントアプリケーション１２２は、いくつかの事前条件のための入力値を提供することができ、推論エンジン６５０は、これらの値を使用して、推論の完了を試行することができる。推論エンジン６５０が推論を完了できず、より多くの事前条件のための値を必要とする場合は、クライアントアプリケーション１２２は、初期設定ハンドラ８０２を使用して、必要な事前条件のための入力値を提供することができる。

変更ハンドラ８０４により、サーバ１０２は、クライアントアプリケーション１２２に、いつ推論エンジン６５０が様々なデータオブジェクトを修正するのかを通知することができる。たとえば、機能８０６は、クライアント１２２に、いつフィールド値が変更されるかを通知する。機能８０８は、クライアントアプリケーション１２２に、いつオブジェクトが作成されるのかを知らせ、機能８１０は、クライアントアプリケーション１２２に、いつオブジェクトが消去されるのかを知らせる。

変更ハンドラ８０４を使用することは、推論中に多数の事後条件が推論エンジン６５０によって計算される場合に、有用であり得る。たとえば、１つのルールベースは、１，０００の事後条件を有することができる。変更ハンドラ８０４を使用しない場合は、クライアントアプリケーション１２２は、推論エンジン６５０から１組の１，０００の出力値を受け取る前に、推論エンジン６５０が推論を完了するまで待つ必要があることがある。変更ハンドラ８０４を使用する場合は、事後条件の１つに値が割り当てられた場合には常に、クライアントアプリケーション１２２に知らされ得る。このようにして、クライアントアプリケーション１２２は、たとえ推論が完了していない場合にも、それぞれ個々の事後条件に値がいつ割り当てられたのかを知る。

図８は、インターフェース８００の例を示しているが、インターフェース８００に対しては様々な変更が行われ得る。たとえば、他の任意の又は追加の通信ハンドラを使用することもできる。また、それぞれのハンドラ８０２、８０４は、他の任意の又は追加の機能をサポートすることができる。

図９Ａ及び図９Ｂは、本発明の一実施形態による規則のタイプの例を示す例示的ブロック図である。具体的には、図９Ａは、パターン合致規則９００を示し、図９Ｂは、決定木規則９５０を示している。他の又は追加のタイプの規則も使用されることがある。その上、図９Ａ及び図９Ｂは、図１のシステム１００について記述しているが、規則９００、９５０を他のシステムと共に使用することもできる。

図９Ａでは、パターン合致規則９００は、前提９０２と、アクション９０４と、結合セクション９０６とを含む。前提９０２とは、アクション９０４を実行すべきかどうかを判断する条件である。前提９０２は、たとえば、１つ以上の式９０８を含む。サーバ１０２は、前提９０２内の式９０８を調べ、式９０８が真であるか又は偽であるかを判断することがある。次いで、その結果を用いて、サーバ１０２は、式９０８が真である場合には、アクション９０４を実行することにより規則９００をファイアし、式９０８が偽である場合には、規則９００をフェイルし、式９０８のための値が判断できない場合には、規則９００を保留することがある。

アクション９０４とは、規則９００の前提９０２が真である場合に、サーバ１０２によって実施されるべき１つ以上のアクションである。アクション９０４は、たとえば、サーバ１０２が特定の値をフィールドに割り当てるべきであることを示す。アクション９０４によりまた、サーバ１０２は、機能を実行するか、又は異なるルールベースドメインに部分推論を起動することができる。

結合セクション９０６は、サーバ１０２が監視すべきデータオブジェクトを識別する。規則９００はパターン合致規則であるので、前提９０２を満たすインスタンス又はオブジェクトの集合全体に適用することができる。結合セクション９０６は、１つ以上の結合変数９１０を含む。推論エンジン１１２は、結合変数９１０を、結合クラスの１つ以上の候補インスタンスに関連付ける。次いで、推論エンジン１１２は、結合変数９１０を前提９０４に適用して、候補インスタンスのいずれかが前提９０２を満たすかどうかを判断する。このようにして、推論エンジン１１２は、候補インスタンスがさらに注意を向けるのに値するものであるかどうかを判断する。候補インスタンスのいずれかが前提９０２を満たす場合は、サーバ１０２は、これらの候補インスタンスを使用してアクション９０４を実行する。

例示されている例においては、Ｐという結合変数９１０は、Ｐｅｒｓｏｎクラスに関連付けられ、Ｄという別の結合変数９１０は、Ｄｕｃｋクラスに関連付けられる。規則９００は、ヒトがカモより年上であり、そのヒトが他のカモを所有していない場合には、ヒトを表すＰｅｒｓｏｎオブジェクトをカモを表すＤｕｃｋオブジェクトに関連付けるよう動作する。サーバ１０２は、ＰｅｒｓｏｎオブジェクトをＰ変数９１０に、ＤｕｃｋオブジェクトをＤ変数９１０に結合する。結合変数９１０を使用して、サーバ１０２は、既存のＰｅｒｓｏｎオブジェクト及びＤｕｃｋオブジェクトを調べ、いずれかのオブジェクトが前提９０２を満たしているかどうかを判断する。いずれかのオブジェクトが前提９０２を満たしている場合は、サーバ１０２は、規則９００のアクション９０４を、これらのデータオブジェクトのそれぞれに適用する。アクション９０４は、そのヒトが所有しているカモの数を増分し、そのヒトをそのカモに関連付ける。

特定の実施形態においては、サーバ１０２は、パターン合致規則９００をレディ状態に保ち、パターン合致規則９００をフェイル又は保留しない。別の特定の実施形態においては、パターン合致規則９００は、１つのファイア規則として作用することがある。この実施形態においては、推論エンジン１１２は、閾値数のオブジェクトが結合変数９１０に結合されるまで待つ。いったん閾値数に合えば、推論エンジン１１２は、これらのオブジェクトを使用して、パターン合致規則９００を１回実行する。次いで、実行されたパターン合致規則９００は、推論エンジン１１２から無視されることがある。

ルールベースが多数のオブジェクトを含むことができるので、サーバ１０２は、１つ以上のアルゴリズムを使用して、パターン合致規則９００の処理効率を向上させることがある。たとえば、サーバ１０２は、Ｒｅｔｅアルゴリズムを使用することができる。Ｒｅｔｅアルゴリズムを使用して、サーバ１０２は、いつオブジェクトが作成されたか、修正されたか、又は消去されたかを検出する。次いで、サーバ１０２は、作成、修正、又は消去によって影響されるフィールドを使用する前提９０２を有するパターン合致規則９００を実行する。サーバ１０２は、突き止められたパターン合致規則９００の前提９０２を調べ、前提９０２が満たされる場合は、アクション９０４を実行することがある。

一実施形態においては、第１のパターン合致規則９００のアクション９０４が適用される場合には、サーバ１０２は、オブジェクトを作成し、修正し、又は消去することができる。これらのオブジェクトは、同じパターン合致規則９００又は別のパターン合致規則９００によって影響され得る。その結果、アクション９０４により、新しいオブジェクトを１つ以上の規則９００に結合することができる。

図９Ｂでは、決定木規則９５０は、評価ステートメント９５２、又は部分木、それに続いて２つ以上の木ノード９５４ａ〜９５４ｅを含む。それぞれの部分木に、容易に規則に関連付けられるような名前を付けることがある。評価ステートメント９５２は、式９５６の値を評価し、判断する。式９５６の計算された値に基づいて、木ノード９５４の１つが実行される。

それぞれの木ノード９５４は、場合分け文９５８又は別様のステートメント９６０のいずれか、それに続いて実施されるアクションを含む。場合分け文９５８は、式９５６のための１つの潜在値又はある範囲の潜在値を識別する。式９５６の値がその値に合致するか、又は場合分け文９５８の値の範囲内にあると、場合分け文９５８に関連付けられた木ノード９５４が実行される。他の木ノード９５４を実行できない場合は、別様のステートメント９６０が、実行される木ノード９５４を識別する。

木ノード９５４内で実施されるアクションは、さらに、追加の部分木を含むことができる。たとえば、木ノード９５４ａは、別の評価ステートメント９６２と２つの木ノード９６４ａ〜９６４ｂとを含む。このようにして、規則９５０を部分木の階層レイヤに分割することができ、サーバ１０２は、部分木を横に移動して、実施すべき適切なアクションに到達することがある。

例示されている例においては、式９５６が年齢を計算し、計算された年齢に基づいて、木ノード９５４の１つが選択される。計算された年齢が既知の値を有する場合は、その値により、木ノード９５４ａ、９５４ｂ、又は９５４ｃを選択することができる。その値が未知の値を有するフィールドに依存する場合など、計算された年齢が未知である場合は、木ノード９５４ｄが選択される。計算された年齢は既知であるが、木ノード９５４ａ〜９５４ｃ内の場合分け文の範囲外にある場合は、木ノード９６０が選択されることがある。

特定の実施形態においては、サーバ１０２は、決定木規則９５０のためのジャストインタイムメモリ割当てスキームを使用することがある。ジャストインタイム割当てスキームにおいては、サーバ１０２は、決定木規則９５０の一部分のみを、メモリ１２６などのメモリ内にロードする。ロードされた規則９５０の一部分により、サーバ１０２は、横移動される木ノード９５４を識別することができる。サーバ１０２が横移動される木ノード９５４を識別した後、サーバ１０２は、その木ノード９５４のコンテンツをメモリ内にロードする。ロードされた木ノード９５４が追加部分木９６４を含んでいる場合は、サーバ１０２は、サーバ１０２が横移動される次の部分木９６４を選択することを可能にする規則９５０の一部分のみをロードする。次の部分木９６４が選択された後、サーバ１０２は、その部分木９６４のコンテンツをメモリ内にロードする。このプロセスは、サーバ１０２が、規則９５０をファイア又はフェイルするまで続行し、その時点で、サーバ１０２は、規則９５０が使用するメモリを解放することがある。ジャストインタイム割当てスキームを使用することにより、決定木規則９５０が使用するメモリ量が減少することがある。決定木規則９５０は、何百又は何千もの埋め込み部分木を包含していることがあるので、ジャストインタイム割当てスキームを使用することは、決定木規則９５０を処理するためのメモリ要件を減少するための一助となり得る。

一実施形態においては、サーバ１０２は、決定木規則９５０を保留するよう強制されることがある。たとえば、サーバ１０２は、推論中に木ノード９５４ｂを選択することがあるが、フィールドＦａｃｔ３が未知の値を有することがある。この例においては、サーバ１０２が規則９５０の実行を完了できないために、サーバ１０２は、規則９５０を保留する。特定の実施形態においては、サーバ１０２は、ピンポイント再始動を実施して、規則９５０の実行をアンペンドし、完了する。規則９５０が保留した場合には、サーバ１０２は、規則９５０のスナップショットをとることがある。スナップショットは、規則９５０内で使用されるフィールドのための値や、規則９５０を保留したステートメントの正確な場所などの、規則９５０のコンテキストを識別する。上記の例においては、スナップショットは、それが規則９５０を保留したステートメントであるので、評価ステートメント９６６の場所を識別することができる。規則９５０を保留したフィールドに既知の値が割り当てられた場合には、サーバ１０２は、規則９５０をアンペンドし、スナップショット内に格納されている場所で規則９５０の実行を開始することがある。このことにより、サーバ１０２は、多数の部分木を包含することのある決定木規則９５０を、より効率的に保留し、アンペンドすることができる。

図９Ａ及び図９Ｂは、規則９００、９５０の例を示しているが、規則９００、９５０に対しては様々な変更が行われ得る。たとえば、規則９００は、任意の数の結合変数９１０を含み、規則９５０は、任意の数の部分木を含むことができる。また、他の又は追加のタイプの規則を使用することができる。

図１０は、本発明の一実施形態によるルールベースを共用するためのメモリ配置の例を示す例示的ブロック図である。具体的には、図１０は、図１のサーバ１０２内で使用されるメモリ１０２６を示しており、ここでは、複数のクライアントアプリケーション１２２が、推論中に同じルールベース１１４を使用する。この実施形態においては、メモリ１０２６は、ルールベース１１４の読取り専用画像１０５０と、１つ以上のクライアント特有の情報ブロック１０５２とを含む。図１０は、図１のシステム１００について記述しているが、メモリ１０２６を他のシステムと共に使用することもできる。

読取り専用画像１０５０とは、ルールベース１１４内の規則１１６のコピーである。サーバ１０２は、データベース１０４又は他の場所からメモリ１０２６内にルールベース１１４をロードすることにより、読取り専用画像１０５０を作成することがある。ルールベース１１４はサーバ１０２によって使用されるそれ自体のデータオブジェクトを定義することができるので、ルールベース１１４は、特定のアプリケーションに結び付けられることがない。その結果、複数のクライアントアプリケーション１２２が、ルールベース１１４を同時に使用することができる。特定の実施形態においては、読取り専用画像１０５０は、クライアント特有の情報を有さない、ルールベース１１４のコピーを包含する。

実際の事前条件値及び事後条件値などの、クライアント特有の情報は、クライアント特有の情報ブロック１０５２内に格納されることがある。クライアント特有の情報ブロック１０５２は、クライアント特有の情報１０５４とポインタ１０５６とを含む。クライアント特有の情報１０５４とは、事前条件値、事後条件値、保留中の規則１１６のスナップショット、及びクライアントアプリケーション１２２に特有の他の任意の情報である。ポインタ１０５６は、クライアント特有の情報１０５４に関連付けられた読取り専用画像１０５０を指す。

オペレーションの一態様においては、クライアントアプリケーション１２２が、ルールベース１１４を使用して推論を要求する場合には、サーバ１０２は、そのルールベース１１４の読取り専用画像１０５０がメモリ１０２６内に既に存在するかどうかを判断することがある。存在しない場合は、サーバ１０２は、ルールベース１１４を読取り専用画像１０５０としてメモリ１０２６内にロードすることがある。次いで、推論エンジン１１２は、読取り専用画像１０５０を使用して推論演算を実施することがある。クライアントアプリケーション１２２が、読取り専用画像１０５０としてメモリ１０２６内に既にロードされているルールベース１１４を使用して推論することを要求した場合は、推論エンジン１１２は、以前に作成された読取り専用画像１０５０を使用して推論演算を実施することがある。推論中に、特定のクライアントアプリケーション１２２のために格納されている値が、クライアント特有の情報ブロック１０５２のクライアント特有の情報１０５４内に置かれる。このようにして、サーバ１０２は、たとえ推論が異なる入力値を必要とし、規則１１６が異なる順序で実行される場合にも、同じルールベース１１４を使用して、複数のクライアントアプリケーション１２２のための推論演算を実施することができる。

一実施形態においては、上述したメモリ１０２６の使用が制限されることがある。たとえば、特定の実施形態においては、補足規則１１６、ルールベース１１４、及びルールセット１３０が、複数の推論エンジンインスタンス間で共用されないことがある。この実施形態においては、補足規則１１６、ルールベース１１４、及びルールセット１３０の画像が、複数の推論エンジンインスタンスによって使用されないことがある。

図１０は、複数のクライアントアプリケーション１２２間でルールベース１１４を共用するために配置されたメモリ１０２６の一例を示しているが、メモリ１０２６に対しては様々な変更が行われ得る。たとえば、それぞれのクライアント特有の情報ブロック１０５２を別個のメモリ構造内に格納することができる。また、クライアントアプリケーション１２２にルールベース１１４を共用させる場合もさせない場合もある他のメモリ配置が使用されることがある。

図１１Ａ〜１１Ｄは、本発明の一実施形態に従って、統合されたルールベースにルールベース構成要素がマージされる例を示す例示的ブロック図である。具体的には、図１１Ａ〜１１Ｃは、ルールベース構成要素１１５０ａ〜１１５０ｃを表し、図１１Ｄは、統合されたルールベース構成要素１１５０ｄを表す。図１１Ａ〜１１Ｄは、図１のシステム１００について記述しているが、ルールベース構成要素１１５０を他のシステムと共に使用することもできる。

図１１Ａにおいては、構成要素１１５０ａとは、規則１１５２である。規則１１５２は、ドメイン１１５６の一部を形成するルールセット１１５４内に包含される。規則１１５２は、Ｆａｔｈｅｒ及びＭｏｔｈｅｒと名づけられた、Ｐｅｒｓｏｎクラスの２つのインスタンス１１５８を参照する。

図１１Ｂにおいては、構成要素１１５０ｂとは、ドメイン１１５６内に包含されているＰｅｒｓｏｎクラス１１６０の部分宣言である。クラス１１６０は、Ｎａｍｅと呼ばれるフィールド１１６２の宣言を含む。構成要素１１５０ｂはまた、Ｆａｔｈｅｒインスタンス１１５８ａの宣言も含む。

図１１Ｃにおいては、構成要素１１５０ｃとは、ドメイン１１５６内に包含されているＰｅｒｓｏｎクラス１１６０の別の部分宣言である。クラス１１６０はまた、Ａｇｅと呼ばれるフィールド１１６４の宣言も含む。構成要素１１５０ｃもまた、Ｍｏｔｈｅｒインスタンス１１５８ｂの宣言を含む。

ルールベースビルダ１１０は、アクティビティを段階的に実施することにより、構成要素１１５０ａ〜１１５０ｃをマージすることがある。一実施形態においては、第１の段階中に、ルールベースビルダ１１０が、構成要素１１５０ａ〜１１５０ｃを調べて、データオブジェクト及び論理オブジェクトを定義するクラスを収集する。この段階中に、ルールベースビルダ１１０は、構成要素１１５０によって定義されたクラスのすべてを識別する、１つ以上の内部データ構造を作成することがある。第２の段階中に、ルールベースビルダ１１０は、段階１からの内部データ構造を解析して、クラス宣言間の完全性及び整合性を確実にする一助とする。たとえば、クラスが、Ｂｒｏｔｈｅｒと名づけられたインスタンス上で動作する規則を定義すると、ルールベースビルダ１１０により、Ｂｒｏｔｈｅｒと名づけられたインスタンスが構成要素１１５０によって作成されることが確実になることがある。第３の段階中に、ルールベースビルダ１１０は、解析されたデータ構造をコンパイルして、２進ルールベース１１４を生成することがある。

第１の段階中に、ルールベースビルダ１１０によって調べられた構成要素１１５０は、それぞれ、クラスの一部分を定義することができる。示されている例においては、構成要素１１５０ｂ及び１１５０ｃは、Ｐｅｒｓｏｎクラス１１６０の異なる部分を定義する。その結果、マージプロセスの第１の段階中に、ルールベースビルダ１１０は、それぞれの構成要素１１５０が分析される時に遭遇したクラス宣言を追跡する。２つの構成要素１１５０が１つのクラスの一部分を定義すると、ルールベースビルダ１１０は、これらの宣言を１つのクラス宣言に組み合わせる。このことは、図１１Ｄに見られ、ここでは、ルールベース１１５０ｄ内のＰｅｒｓｏｎクラス１１６０の完全な宣言を示している。

ルールベースビルダ１１０が構成要素１１５０ｂ、次いで構成要素１１５０ｃを調べると想定すると、ルールベースビルダ１１０は、構成要素１１５０ｂにアクセスし、構成要素１１５０ｂがクラス１１６０の宣言を包含すると判断する。ルールベースビルダ１１０は、すべての以前に遭遇した宣言を包含する内部データ構造を調べ、クラス１１６０は以前に調べられた構成要素１１５０によって宣言されなかったと判断し、クラス１１６０及びフィールド１１６２を内部データ構造に追加する。ルールベースビルダ１１０は、構成要素１１５０ｃへと続行し、クラス１１６０の別の宣言を突き止める。ルールベースビルダ１１０は、その内部データ構造を調べ、クラス１１６０は以前に調べられた構成要素１１５０内で宣言されたと判断し、フィールド１１６４をデータ構造内のクラス１１６０に追加することがある。このことにより、図１１Ｄに示されているクラス１１６０の全宣言が作成され、これには、フィールド１１６２、１１６４を有するクラス１１６０の１つの宣言が含まれる。同様の方法で、ルールベースビルダ１１０は、構成要素１１５０内で遭遇したインスタンス１１５８のそれぞれの宣言を突き止め、図１１Ｄに示されているような１つの宣言を形成することがある。

図４について上述したように、ルールベース１１４は、複数のレベル（ルールベースレベル、ドメインレベル、又はルールセットレベル）のルールベース１１４で、クラスを定義することがある。また、同じ名前を有するクラスが、ルールベース１１４の異なるレベルに存在することができる。このため、マージプロセスの段階１中に作成された内部データ構造が、そのクラスの範囲を指定する。たとえば、図１１Ｄでは、クラス１１６０が、ドメイン１１５６内に存在することが示されている。別のＰｅｒｓｏｎクラスがルールセット１１５４内で宣言されると、その結果生じたルールベース１１５０ｄは、ルールセット１１５４の一部として現れる別のクラス定義を包含する。さらに別のＰｅｒｓｏｎクラスがルールベースレベルで宣言されると、その結果生じたルールベース１１５０ｄは、ドメイン１１５６の外部に、ルールベース１１５０ｄの一部として現れるさらに別のクラス定義を包含する。

第１の段階中に、ルールベースビルダ１１０は、同じフィールドを必要とするクラス宣言を検出することがある。場合によっては、複数の構成要素１１５０が、Ｐｅｒｓｏｎクラス１１６０がＮａｍｅフィールド１１６２を含むことを宣言する場合など、宣言同士が互いに合致することがある。他の場合においては、宣言同士が互いに矛盾し、ルールベースビルダ１１０がその矛盾を解決できないことがある。たとえば、構成要素１１５０ｃは、Ａｇｅフィールド１１６４を数字として定義し、別の構成要素１１５０は、Ａｇｅフィールド１１６４を文字列として定義することができる。これらの宣言は、互いに矛盾し、ルールベースビルダ１１０は、誤りメッセージを生成することができる。さらに他の場合においては、宣言は、互いに矛盾するが、ルールベースビルダ１１０によって解決できることがある。一例として、構成要素１１５０ｃは、Ａｇｅフィールド１１６４を数字として定義し、別の構成要素１１５０は、Ａｇｅフィールド１１６４を、０〜１２０の間の値に制限された数字として定義することができる。ルールベースビルダ１１０は、より制限された宣言を使用することにより、このような矛盾を解決することができ、これは、この例においては、制約を有する宣言である。

一実施形態においては、ルールベースビルダ１１０は、マージプロセスの第１の段階中に構成要素１１５０を訪問する場合には、定義された順序を使用しない。その結果、ルールベースビルダ１１０は、そのクラス１１６０の構造が定義される前に、クラス１１６０のインスタンス１１５８を使用する規則１１５２を処理することができる。特定の実施形態においては、ルールベースビルダ１１０によって使用される内部データ構造は、ルールベースのマージプロセス中の先付け宣言の使用を減少する又は削除する一助となる。

統合されたルールベース１１５０ｄを作成した後、ルールベースビルダ１１０は、ルールベース１１５０ｄを解析する。たとえば、ルールベースビルダ１１０は、規則１１５２を分析して、Ｆａｔｈｅｒ及びＭｏｔｈｅｒが宣言されたインスタンスであるかどうかを判断する。ルールベースビルダ１１０はまた、Ｆａｔｈｅｒ及びＭｏｔｈｅｒインスタンスに関連付けられたクラスがＡｇｅフィールドを含むかどうかを判断する。ルールベースビルダ１１０は、さらに、Ａｇｅフィールドに関連付けられたデータ型が、規則１１５２で実施される演算に適切かどうかを判断する。この例においては、Ａｇｅの値が６５の値と比較され、従ってルールベースビルダ１１０は、Ａｇｅが数字データ型であると宣言されたかどうかを判断する。その上、ルールベースビルダ１１０は、マージ結果を調べ、宣言されたそれぞれの方法がまた、関連付けられた実施を有するかどうかを判断する。この例においては、ある方法が１つのルールベース構成要素１１５０内で宣言され、その構成要素１１５０の開発者は、別の構成要素１１５０の開発者が方法の実施を提供できると想定する。いずれの開発者も方法が如何に実施されるべきかを定義しなかった場合は、ルールベースビルダ１１０は、誤りメッセージを生成することがある。ルールベースビルダ１１０は、統合されたルールベース１１５０ｄを解析するために、他の又は追加のステップをとることがある。

第３の段階中に、ルールベースビルダ１１０は、解析されたルールベース１１５０ｄをコンパイルする。一実施形態においては、ルールベース１１５０ｄは、式が何らかの副作用を有することを許可しないフォーマットによって定義される。推論エンジン１１２が式を評価している時にフィールドの値が変更した場合に、「副作用」が生じる。たとえば、図９Ｂでは、推論エンジン１１２は、ＧｅｔＡｇｅと呼ばれる機能を呼び出すことにより、式９５６を評価する。この実施形態においては、推論エンジン１１２は、ＧｅｔＡｇｅ機能を実行している時に任意のフィールドの値を修正することは許可されない。ルールベース１１５０ｄ内の副作用の存在を減少又は削除するための一助として、ルールベースビルダ１１０は、方法が値を返すかどうかを識別する。方法が値を返した場合は、その方法は、フィールドの値を変更するステップを含んでいないことがある（その方法で使用される局所変数を除く）。また、値を返す方法は、フィールドの値を変更する第２の方法を起動しないことがある（第２の方法で使用される局所変数を除く）。別の実施形態においては、ルールベースビルダ１１０により、ルールベース内の式は副作用を有することができる。

ルールベースビルディングプロセス中に、ルールベースビルダ１１０はまた、最終値フィールドの使用に関連付けられたテーブルを生成することができる。上述したように、第１の値フィールドは、１回のみ値を割り当てるべきフィールドであり、最終値フィールドは、ある時間に渡って複数の値を割り当てられ得るフィールドである。推論中に、最終値フィールドの有用な値は、一般に、最終値フィールドの値を変更することのできる規則のすべてがファイア又はフェイルされるまで認識されない。ルールベースビルディングプロセス中に、ルールベースビルダ１１０は、最終値フィールドのためのテーブルを生成することができる。このテーブルは、最終値フィールドの値を変更する規則、及び最終値フィールドの最終値を使用する規則を識別することができる。このようにして、推論エンジン１１２は、そのテーブルを使用して、最終値フィールドの値を変更する規則のすべてをファイア又はフェイルすることができる。いったんこれらの規則のすべてが実行されると、推論エンジン１１２は、最終値フィールドの最終値を使用する規則をファイア又はフェイルすることができる。特定の実施形態においては、決定木規則は最終値フィールドを使用することができるが、パターン合致規則は使用することができない。この実施形態においては、ルールベースビルディング中に構成されたテーブルは、最終値フィールドに関連付けられた決定木規則のみを識別する。

図１２は、本発明の一実施形態による推論サービスを提供する方法１２００の例を示す例示的流れ図である。方法１２００は、図１のシステム１００について記述しているが、他のシステムを使用することもある。

サーバ１０２は、ステップ１２０２で、１つ以上の規則１１６を識別する情報を受け取る。このことは、たとえば、ＡＰＩ１２０が１つ以上のドメイン１３１を有する２進ルールベース１１４を受け取るステップと、ＡＰＩ１２０がドメイン１３１選択を受け取るステップとを含むことがある。このことはまた、ＡＰＩ１２０が２進ルールベース１１４の場所を受け取ることを含むことがある。情報は、推論エンジン１１２の推論サービスを起動しようとするクライアントアプリケーション１２２などの、任意の好適なソースから来ることがある。

サーバ１０２は、ステップ１２０４で、識別された規則１１６に関連付けられた任意の事前条件及び任意の事後条件を識別する。このことは、たとえば、推論エンジン１１２が、ドメイン１３１内に包含されている情報を使用して、そのドメイン１３１に関連付けられた任意の事前条件及び事後条件を識別することを含むことがある。

サーバ１０２は、ステップ１２０６で、識別された事前条件のための値を受け取る。このことは、たとえば、ＡＰＩ１２０が、推論エンジン１１２を起動しているクライアントアプリケーション１２２から事前条件のための値を受け取ることを含むことがある。推論エンジン１１２は、初期設定ハンドラを通じて又は他の適切な方法で、ＸＭＬ文書内の１グループとして、クライアントアプリケーション１２２から事前条件値を個々に受け取ることができる。

サーバ１０２は、ステップ１２０８で、事前条件値を使用して規則１１６を実行する。このことは、たとえば、推論エンジン１１２が、様々な規則１１６をファイアし、フェイルし、保留して、未知の状態から既知の状態に事後条件フィールドを解決することを試みることを含むことがある。このことはまた、推論エンジン１１２が、フィールド値が変更された後に、保留中の規則１１６を再訪問して、この変更により、推論エンジン１１２が保留中の規則１１６のいずれかをファイア又はフェイルすることができるかどうかを判断することを含むことがある。このことは、さらに、推論エンジン１１２が、規則１１６の前向き連鎖又は後ろ向き連鎖を実施することを含むことがある。

サーバ１０２は、ステップ１２１０で、任意の事後条件の値を返す。このことは、たとえば、推論エンジン１１２が、識別された事後条件のための値をクライアントアプリケーション１２２に伝えることを含むことがある。推論エンジン１１２は、変更ハンドラを通じて又は他の適切な方法で、ＸＭＬ文書の１グループとして、事後条件値をクライアントアプリケーション１２２に個々に伝えることができる。推論エンジン１１２は、すべての事後条件、又は事後条件のいくつかのための値の判断に成功することもあれば、事後条件のいずれの値の判断にも成功しないこともある。

図１２は、推論サービスを提供する方法１２００の一例を示しているが、方法１２００に対しては様々な変更が行われ得る。たとえば、推論エンジン１１２は、実際の規則１１６を受け取る前に、任意の事前条件及び事後条件のための値を受け取ることができる。また、推論エンジン１１２は、推論中に、規則スナップショットなどの追加情報を生成することができる。その上、図１２のステップのいくつかが、オーバラップすることがある。一例として、推論エンジン１１２は、変更ハンドラを使用して、事後条件値をクライアントアプリケーション１２２に伝えることがある。この場合には、事後条件値は、推論が完了する前に、クライアントアプリケーション１２２に送られることがある。

図１３は、本発明の一実施形態によるルールベースビルディングのための方法１３００の例を示す例示的流れ図である。方法１３００は、図１のシステム１００について記述しているが、他のシステムを使用することもある。

サーバ１０２は、ステップ１３０２で、１つ以上のルールベース構成要素を識別する情報を受け取る。このことは、たとえば、ルールベースビルダ１１０が、ソース又は２進規則１１６、ルールセット１３０、又はルールベース１１４を受け取ることを含むことがある。このことはまた、ルールベースビルダ１１０が、ソース又は２進規則１１６、ルールセット１３０、又はルールベース１１４の場所を受け取ることを含むことがある。この情報は、ルールベースビルダ１１０のルールベースビルディングサービスを起動しようとするクライアントアプリケーション１２２などの、任意の好適なソースから来ることがある。

サーバ１０２は、ステップ１３０４で、受け取られたルールベース構成要素が適切なフォーマットを有するかどうかを判断する。このことは、たとえば、サーバ１０２が、受け取られたルールベース構成要素がＸＭＬ文書内に包含されているかどうかを判断することを含むことがある。このことはまた、サーバ１０２が、受け取られたルールベース構成要素が規則定義言語で定義されたフォーマットに従っているかどうかを判断することを含むことがある。従っていない場合は、サーバ１０２は、ステップ１３０６で、受け取られたルールベース構成要素を適切なフォーマットに変換し、かつ再フォーマット化する。このことは、たとえば、サーバ１０２が、ルールベース構成要素をＸＭＬ文書に変換し、規則定義言語に従うよう、ルールベース構成要素を再フォーマット化することを含むことがある。

サーバ１０２は、ステップ１３０８で、ルールベース構成要素を統合されたルールベース１１４にマージする。このことは、たとえば、サーバ１０２が、ルールベース構成要素内のクラス又は他のデータオブジェクトの宣言を識別することを含むことがある。このことはまた、サーバ１０２が、内部データ構造を調べて、以前に調べたルールベース構成要素が同じクラス又は他のデータオブジェクトの別の宣言を含んでいたかどうかを判断することを含むことがある。含んでいない場合は、サーバ１０２は、その宣言を内部データ構造に追加する。そうでない場合は、サーバ１０２は、現在の宣言から内部データ構造内に包含されている以前の宣言内に要素を挿入する。サーバ１０２は、内部データ構造の生成を終了した時に、内部データ構造内に要素を包含する統合されたルールベース１１４を生成することがある。

サーバ１０２は、ステップ１３１０で、統合されたルールベース１１４をコンパイルする。このことは、たとえば、サーバ１０２が、統合されたルールベース１１４を様々な構造に解析することを含むことがあり、それぞれの構造は、規則定義言語で定義されたＸＭＬ要素に対応する。このことはまた、サーバ１０２が、構造の様々な要素間のリンクを識別して、構造間の相互接続を作成することを含むことがある。このことはまた、サーバ１０２が、２進バージョンの統合されたルールベース１１４を作成することをさらに含むことがある。

図１３は、ルールベースビルディングのための方法１３００の一例を示しているが、方法１３００に対しては様々な変更が行われ得る。たとえば、ルールベースビルダ１１０は、適切なフォーマットを有するルールベース構成要素のみを受け取ることができ、ルールベースビルダ１１０は、ルールベース構成要素を変換する必要がない。また、ルールベースビルダ１１０は、ロードマップ及びアプリケーションインターフェース文書などの追加情報を生成することができる。

図１４は、本発明の一実施形態に従って、ルールベース構成要素をマージする方法１４００の例を示す例示的流れ図である。方法１４００は、図１のシステム１００について記述しているが、他のシステムを使用することもある。

サーバ１０２は、ステップ１４０２で、ルールベース構成要素を選択する。このことは、たとえば、ルールベースビルダ１１０が、クライアントアプリケーション１２２によって供給される１つ以上のルールベース構成要素１１５０の１つを選択することを含むことがある。サーバ１０２は、ステップ１４０４で、選択されたルールベース構成要素を１つ以上のルールベース要素に解析する。このことは、たとえば、ルールベースビルダ１１０が、ルールベース構成要素１１５０を、クラス宣言などの様々な宣言に分割することを含むことがある。

サーバ１０２は、ステップ１４０６で、ルールベース要素を選択する。このことは、たとえば、ルールベースビルダ１１０が、選択されたルールベース構成要素１１５０内に最初に現れるルールベース要素を選択することを含むことがある。サーバ１０２は、ステップ１４０８で、選択されたルールベース要素に対応する標準要素を作成する。このことは、たとえば、ルールベースビルダ１１０が、ＸＭＬルールベース要素などのルールベース要素に対応する内部オブジェクトを作成することを含むことがある。

サーバ１０２は、対応する標準要素を作成した後、ステップ１４１０で、以前に遭遇した標準要素が同じ名前を有し、同じルールベースレベルに常駐するかどうかを判断する。このことは、たとえば、ルールベースビルダ１１０が、以前に遭遇した標準要素を包含する内部データ構造を分析することを含むことがある。このことはまた、ルールベースビルダ１１０が、以前に遭遇した標準要素が同じ名前を有し、同じ階層的ルールベースレベルに常駐し、選択された標準要素と同じタイプの要素であるかどうかを判断することを含むことがある。これらの条件のいずれも真でない場合は、サーバ１０２は、ステップ１４１８で、選択された標準要素を内部データ構造内に挿入する。このことは、たとえば、ルールベースビルダ１１０が、標準要素が常駐している階層レベルに基づいて、標準要素を内部データ構造内の適切な場所に挿入することを含むことがある。

ステップ１４１０で、３つの条件のすべてに合うと、２つの別個の標準要素が、同じルールベースレベルで同じルールベース構造を定義する。サーバ１０２は、ステップ１４１２で、２つの標準要素の１つのみがルールベース論理を定義するかどうかを判断する。ルールベース論理は、制約が満たされたかどうかを判断するために使用される式の定義と、宣言された方法の実施と、規則のための実施とを含むことがある。複数の標準要素が、同じルールベース構造のためのルールベース論理を定義すると、サーバ１０２は、ステップ１４１４で誤りを生成する。このことは、たとえば、ルールベースビルダ１１０が、メッセージハンドラによって捕捉され、かつクライアントアプリケーション１２２に伝えられた誤りメッセージを生成することを含むことがある。標準要素の１つのみが、同じルールベース構造のためのルールベース論理を定義すると、サーバ１０２は、ステップ１４１６で標準要素をマージする。このことは、たとえば、ルールベースビルダ１１０が、選択された標準要素から内部データ構造内に包含されている標準要素内に一部分を挿入することを含むことがある。

サーバ１０２は、ステップ１４２０で処理されるべき、選択されたルールベース構成要素の追加ルールベース要素があるかどうかを判断する。追加ルールベース要素があると、サーバ１０２は、ステップ１４０６に戻り、別のルールベース要素を選択する。追加ルールベース要素がない場合は、サーバ１０２は、ステップ１４２２で処理すべき、追加ルールベース構成要素があるかどうかを判断する。追加ルールベース構成要素があると、サーバ１０２は、ステップ１４０２に戻り、別のルールベース構成要素を選択する。

ルールベース構成要素が処理された後、サーバ１０２によって作成された内部データ構造は、これらのルールベース構成要素の様々な要素に対応する標準要素を包含する。次いで、サーバ１０２は、内部データ構造を使用して、他の任意の好適なアクションをとることがある。たとえば、サーバ１０２は、論理に対応する内部データ構造の文意を分析し、その論理のための２進命令を生成することができる。

図１４は、ルールベース構成要素をマージする方法１４００の一例を示しているが、方法１４００に対しては様々な変更が行われ得る。たとえば、ルールベースビルダ１１０は、一度に１つのルールベース構成要素を受け取ることができるので、ルールベースビルダ１１０は、ステップ１４０２で、ルールベース構成要素を選択する必要がない。また、ルールベースビルダ１１０は、標準要素のいずれかを内部データ構造内に挿入する前に、すべてのルールベース構成要素のための標準要素を作成することができる。その上、ルールベースビルダ１１０は、１つの内部データ構造を処理する形で記述されているが、他のタイプ又は数のデータ構造も使用され得る。さらに、ルールベースビルダ１１０は、ルールベースＸＭＬ要素を、既存の標準要素と直接比較することができ、これにより、重複する標準要素を作成することが回避される。

規則定義言語（ＲＤＬ）
一実施形態においては、ルールベースは、規則定義言語を使用して定義される。規則定義言語は、ルールベースを形成する１つ以上のＸＭＬ文書の構造及びコンテンツを定義する。具体的には、規則定義言語は、クラス、フィールド、方法、及び静的インスタンスの定義などのオブジェクト定義、及びドメイン内に編成される制約及び規則の定義をサポートする。

以下に、図１のシステム１００を参照しながら、規則定義言語について記述するが、他のシステムも規則定義言語を使用することがある。また、システムが、ルールベースを定義するための他の言語を使用することもある。

１概要
一般に、規則定義言語により、ユーザは、クラス、インスタンス、フィールド、ドメイン、及びルールセットなどの、ルールベース１１４内のどのオブジェクトが、パブリックオブジェクトとして、クライアントアプリケーション１２２と共用されるかを指定することができる。デフォルトにより、ルールベース１１４内で指定された他のオブジェクトが、そのルールベース１１４に対してプライベートのままであることがある。共用されているフィールドについて、ユーザは、事前条件として又は事後条件としてそれぞれのフィールドにアクセス可能かどうかを指定することがある。

規則定義言語は、２つのタイプの規則１１６、即ちパターン合致規則と決定木規則とをサポートする。両タイプの規則とも前向き連鎖中に使用され、決定木規則は後ろ向き連鎖中に使用される。

規則定義言語は、数字、ブール、文字列、関連付けインスタンス、セット、及びインスタンス参照を含む、いくつかの異なるデータ型をサポートする。数字とは、整数と浮動小数点値とを区別しない、一般的な数値データ型である。この値は、任意のサイズを有し、数字の精度は、精度フラグを使用して指定されることがある。値はまた、特定のニーズにより、最近隣値に丸められることがある。一実施形態においては、２つの近接値が等距離にある場合は、推論エンジン１１２は、常に、偶数の最近隣値に又は奇数の最近隣値に丸めることができる。ブールとは、真又は偽の値である。文字列とは、一連のユニコード文字であり、大文字と小文字とを区別しない。

関連付けインスタンスは、ルールベースインスタンス間の関係を定義する。たとえば、Ｐｅｒｓｏｎインスタンスが、別のＰｅｒｓｏｎインスタンスの配偶者であるか、又はＰｅｒｓｏｎインスタンスが、Ｄｕｃｋインスタンスを所有していることがある。規則定義言語は、１対１、１対多数、多数対１、及び多数対多数の関連付けなどの、任意の好適なタイプの関連付けをサポートすることができる。特定の例として、規則定義言語は、所有権（Ｏｗｎｓ及びＩｓＯｗｎｅｄＢｙ）関連付け、管理（Ｍａｎａｇｅｓ及びＩｓＭａｎａｇｅｄＢｙ）関連付け、配偶者（ＩｓＳｐｏｕｓｅＯｆ）関連付け、及び兄弟（ＩｓＳｉｂｌｉｎｇＯｆ）関連付けをサポートすることができる。たとえば、Ｄｕｃｋインスタンスのフィールドは、Ｄｕｃｋが識別されたＰｅｒｓｏｎによって所有されていることを示す、ＰｅｒｓｏｎインスタンスとのＩｓＯｗｎｅｄＢｙ関連付けを定義することがある。

１つのインスタンス内のインスタンス参照とは、別のインスタンスへの参照である。たとえば、Ｄｕｃｋクラスが、所与のＤｕｃｋインスタンスを所有するＰｅｒｓｏｎインスタンスを識別する、Ｐｅｒｓｏｎへのインスタンス参照を定義することがある。この例においては、インスタンス参照は、他のインスタンスに対するポインタとして作用する。他のデータ型と同様に、インスタンス参照は、既知の又は未知の状態のいずれかであり得る。既知の状態であれば、インスタンス参照値は、インスタンスを参照するか又はナルであり得る。未知の値は未知の関係を表し、ナル値は関係が欠如している既知の値を示すという点において、ナル値は、未知の値とは区別されることがある。

セットとは、一意の要素の無順序の集合である。要素は、上記のデータ型のいずれでも良い。特定の実施形態においては、すべての要素が同じデータ型を有するべきである。規則定義言語は、数組のセットをサポートする場合もしない場合もある。規則定義言語はまた、リスト、日付、及び時間などの、他のデータ型をサポートすることがある。

規則定義言語は、推論エンジン１１２によって行われる決定を、規則の前提又は制約式のいずれかに分類することがある。このことは、意思決定を、より少数のより良く定義されたコンテキストに限定するための一助となる。このことはまた、ルールベース１１４又はルールベース１１４の一部分を作成している開発者に、よりクリーンかつよりアトミックな規則を書き込むことを勧めるための一助となる。このことにより、ルールベース１１４内のＩＦ−ＴＨＥＮ規則の使用が、さらに減少又は削除されることがある。規則定義言語はまた、式がどのような副作用をも有することを認めないことがある。

規則定義言語は、さらに、ポインタ及び動的に割り当てられたオブジェクトの使用を制限することがある。たとえば、規則定義言語は、パターン合致規則内で使用される関連付けインスタンス内及び結合変数内のフィールドに対するポインタの使用を制限することがある。このことが、推論が開始され、ポインタが使用される前の、ルールベース１１４内の規則１１６の分析を容易にするための一助となる。特定の実施形態においては、推論が開始される前に、推論エンジン１１２によってではなく、ルールベースビルダ１１０がルールベース１１４をビルドする時に、ルールベース１１４の分析が行われることがある。別の実施形態においては、ポインタの使用が、他の方法で制限される場合も制限されない場合もある。

その上、サードパーティベンダが機能及び追加情報をルールベース１１４に追加できるようにするために、サードパーティベンダは、ルールベース１１４内で定義し、かつ使用する要素及びフィールドに、接頭部を追加することができる。ある実施形態においては、接頭部は、ＸＭＬ名前空間接頭部であり得る。推論エンジン１１２は、規則定義言語で定義された任意の要素及びフィールドを処理し、接頭部を有する要素及びフィールドなどの、他の任意の要素及びフィールドを無視することができる。

以下の規則定義言語についての記述においては、ルールベース１１４が１つ以上のＸＭＬ文書を含むことを想定している。以下の記述においては、ＸＭＬ文書のコンテンツは、Ｂａｃｋｕｓ−Ｎａｕｒ形式（ＢＮＦ）表記法を使用して記述されており、ルールベース論理の例は、インフィックス表記法を使用している。これは単に例示のためである。ＸＭＬ文書のコンテンツ及び例を記述するために使用される他の表記法も使用され得る。また、他の実施形態においては、ルールベース１１４は、他のタイプの情報を含むこともでき、ＸＭＬ文書に制限されるものではない。

２要素属性
規則定義言語は、以下の属性をサポートする。
AbortMsg_Attrib
::=abort_msg=“<StringVal>” //No default
AppShared_Attrib
::=appshared=“true”
::=appshared=“false” //Default
CaseSensitivity_Attrib
::=case_sens=“true”
::=case_sens=“false” //Default
Collection_Attrib
::=coll_type=“set”
::=coll_type=“none” //Default
DataType_Attrib //No default
::=type=“number”
::=type=“boolean”
::=type=“string”
::=type=“inst_ref”
Enabled_Attrib
::=enabled=“true” //Default
::=enabled=“false”
Intrinsic_Attrib
::=intrinsic=“true”
::=intrnsic=“false” //Default
LocTag_Attrib
::=loc_tag=“<StringVal>” //No default
Name_Attrib
::=name=“<Identifier>” //Nodefault
ParamIOType_Attrib
::=iotype=“in” //Default
::=iotype=“out”
PMOptions_Attrib
::=options=“<Options>”//Default(least-recent,multi-fire)
Post_Attrib
::=post_Type=“conditional”
::=post_type=“unconditional” //Default
Precision_Attrib
::=precision=“<IntegerVal>” //Default: “0”
Priority_Attrib
::=priority=“<IntegerVal>” //Default: “0”
ResolutionType_Attrib
::=res_type=“first_valued” //Default
::=res_type=“final_valued”
ResumeVal_Attrib
::=resume_val=“<Value>” //No default
Value Attrib
::=value=“<Value>” //No default

後のセクションでは、これらの属性を参照する。多くの場合には、このリストが、真及び偽などの、属性が有する実際の値を定義する。その他の場合には、このリストは記号値を反映し、この場合、記号値は括弧（＜＞）でくくられるが、このことについては、以下により詳細に説明する。

３ルート要素
この要素は、ＸＭＬ文書のルート要素であり、ルールベース１１４の構造全体を定義する。これは、以下のフォーマットを有する。
Rulebase_Element
::=(‘rulebase’RB_Attribs+)
RB_Section*
Rulebase_Attribs
::=Name_Attrib //Required
::=LocTag_Attrib //Optional
Rulebase_Section
::=InitMethodDef_Element
::=Assoc_Element
::=ConstraintSet_Element
::=ExternalLib_Element
::=Class_Element
::=Domain_Element

Ｎａｍｅ＿Ａｔｔｒｉｂは、文字数字の列などの、ルールベース１１４のための名前を指定する。推論エンジン１１２は、誤り及びトレースメッセージ内で、この名前を使用することがある。Ｒｕｌｅｂａｓｅ＿Ｓｅｃｔｉｏｎは、ゼロ以上の部分要素を含み、これらの部分要素は、ルールベース１１４内のグローバル範囲にさらされたオブジェクトを定義する。たとえば、ＩｎｉｔＭｅｔｈｏｄＤｅｆ＿Ｅｌｅｍｅｎｔｓは、ルールベースレベルの初期設定方法を定義し、Ａｓｓｏｃ＿Ｅｌｅｍｅｎｔｓは、ルールベースレベルのクラス間のルールベースレベルの関係を定義し、ＣｏｎｓｔｒａｉｎｔＳｅｔ＿Ｅｌｅｍｅｎｔｓは、値の割当てをルールベースレベルのフィールドに制約する方法のルールベースレベルのセットを定義する。ＥｘｔｅｒｎａｌＬｉｂ＿Ｅｌｅｍｅｎｔｓは、ルールベース１１４から起動され得る外部ライブラリを定義し、Ｃｌａｓｓ＿Ｅｌｅｍｅｎｔｓは、ルールベースレベルクラスのフィールド、方法、及び静的インスタンスを定義する。Ｄｏｍａｉｎ＿Ｅｌｅｍｅｎｔｓは、ルールベースレベルのドメインリソースを定義する。

上述したように、また以下により詳細に記述するように、規則定義言語は、不完全なルールベースのフラグメントのマージングをサポートして、完全なルールベース１１４を形成するので、これらの部分要素のすべてがオプションであり得る。また、以下に記述するように、それぞれの部分要素が、Ｎａｍｅ＿Ａｔｔｒｉｂを指定することがある。これらの名前は、ルールベースレベルでは一意であり得るが、これより低位のレベルではオーバーライドされることがある。ルールベース１１４が所与のレベルで同名のオブジェクトを定義すると、ルールベースビルダ１１０は、マージプロセス中に、これらのオブジェクトを１つのルールベースオブジェクトにマージすることがある。

４ＩｎｉｔＭｅｔｈｏｄＤｅｆ＿Ｅｌｅｍｅｎｔ
この要素は、ルールベース１１４内のオブジェクトを初期設定する方法を定義し、以下のフォーマットを有する。
InitMethodDef_Element
::=(‘init_method’InitMethodDef_Attribs+)
[InitMethodBody_Element]
InitMethodDef_Attribs
::=Name_Attrib //Required
::=LocTag_Attrib //Optional

ＩｎｉｔＭｅｔｈｏｄＤｅｆ＿Ｅｌｅｍｅｎｔは、レベル特有のフィールド及び外部ライブラリを初期設定する方法論理を定義する。たとえば、この要素は、後に規則及び制約によって参照される様々なフィールドを初期設定することがある。推論エンジン１１２は、最初にそのレベルのためのリソースをロードする時に、この方法を起動する。一実施形態においては、推論エンジン１１２は、この方法を一回起動することがある。所与のレベルに複数のＩｎｉｔＭｅｔｈｏｄＤｅｆ＿Ｅｌｅｍｅｎｔがある場合には、推論エンジン１１２は、任意の好適な順序で要素を起動することがある。この要素内で定義された初期設定方法は、引き数を受け付けず、値を返さないことがある。この方法は、自由に、他の方法を起動し、かつそれらの範囲レベル内のあらゆるオブジェクトにアクセスすることがある。一実施形態においては、この方法は、推論を起動したり、又は未知の状態のフィールドを読み取ろうとすることができないことがある。この実施形態においては、これらのオペレーションのいずれかを検出するとすぐに、推論エンジン１１２は、誤りメッセージと共に推論を直ちにアボートすることがある。

この要素は、ルールベース１１４内のいくつかの異なるレベルで指定されることがある。たとえば、ルールベースレベル、ドメインレベル、及びルールセットレベルで指定され得る。所与のレベルに、この要素の複数の指定があることがあるが、それぞれが異なる名前を有するべきである。また、複数のサブルールベースが、同じルールベースレベルで、ＩｎｉｔＭｅｔｈｏｄＤｅｆ＿Ｅｌｅｍｅｎｔに寄与することができる。

一実施形態においては、フィールドの初期設定は、フィールドの制約を受ける。この方法は、これらの制約に、及びこのような制約が依拠するフィールドにセンシティブであるべきである。たとえば、フィールドの制約はフィールドＭａｘｉｍｕｍＡｇｅに依拠することがあるので、初期設定の方法は、その制約に依存するフィールドを設定する前に、このフィールドが初期設定されていることを確実にするための一助となるべきである。

ルールベース１１４のサンプルは、以下に示すように、ルールベースレベルでＩｎｉｔＭｅｔｈｏｄＤｅｆ＿Ｅｌｅｍｅｎｔを定義することができる。
<init_methodname=“RulebaseConstantsInitializer”>
<method_body>
<![CDATA[
constants.max_age=120
constant.adult_age=21
constant.ValidSymptoms=set(“symptom1”, “symptom2”, “symptom3”)
]]>
</method_body>
</init_method>
この方法により、後に規則及び制約によって使用される、様々な定常場が初期設定される。

５Ａｓｓｏｃ＿Ｅｌｅｍｅｎｔ
この要素は、フィールド間の関係を定義し、以下のフォーマットを有する。
Assoc_Element
::=(‘assoc’Assoc_Attribs+)
FieldRef_Element //AssocRolel
FieldRef_Element //AssocRole2
Assoc_Attribs
::=Name_Attrib //Assocname-Required
::=LocTag_Attrib //Optional
FieldRef_Element
::=(‘field_ref’FieldRef_Attribs+)
IdentifierSpec //Class for Field
FieldRef_Attribs
::=Name_Attrib //Field name-Required
::=LocTag_Attrib //Optional

この要素は、ルールベース１１４内のいくつかの異なるレベルで指定されることがある。たとえば、ルールベースレベル、ドメインレベル、及びルールセットレベルで指定され得る。一実施形態においては、関連付けは、その重要性を反映する名前を有する。たとえば、所有権の関連付けは、如何にヒトがカモを所有しているかを定義し、管理の関連付けは、如何にヒトが他のヒトを管理しているかを定義し、配偶者の関連付けは、ヒトとヒトとの間の配偶者関係を定義することがある。

Ａｓｓｏｃ＿Ｅｌｅｍｅｎｔは、そのメンバーフィールドをＦｉｅｌｄＲｅｆ＿Ｅｌｅｍｅｎｔｓとして指定する。これらの部分要素のそれぞれが、フィールド名及びそのフィールドを所有又は継承するクラスを指定する。その各クラス内で、これらのフィールドのそれぞれが、インスタンス参照データ型と共に宣言されることがある（以下に記述するＤａｔａＴｙｐｅＩｎｓｔＲｅｆ＿Ｅｌｅｍｅｎｔを参照のこと）。指定されたフィールドは、同じクラスのためのフィールドであることも、異なるクラスのためのフィールドであることもある。たとえば、ユーザが、ＤｕｃｋクラスのＩｓＯｗｎｅｄＢｙフィールドとＰｅｒｓｏｎクラスのＯｗｎｓフィールドとの間の関連付けを定義することがある。別の例として、ユーザが、ＰｅｒｓｏｎクラスのＩｓＭａｎａｇｅｄＢｙフィールドとＰｅｒｓｏｎクラスのＭａｎａｇｅｓフィールドとの間の関連付けを定義することがある。ユーザは、さらに、ＰｅｒｓｏｎクラスのＩｓＳｐｏｕｓｅＯｆフィールドが両方の関連付けの役割を果たすなどの、両方の関連付けの役割のための同じフィールドを指定することができる。

一実施形態においては、関連付けの多様性（１対１、１対多数、多数対１、多数対多数）が、指定されたフィールドがセットであるかどうかによって変わることがある。たとえば、ＰｅｒｓｏｎクラスのＯｗｎｓフィールドはセットであるが、ＤｕｃｋクラスのＩｓＯｗｎｅｄＢｙフィールドはセットでない場合は、その関連付けは、ＰｅｒｓｏｎｓとＤｕｃｋsとの間の１対多数の関係である。

Ａｓｓｏｃ＿Ｅｌｅｍｅｎｔ要素は、オブジェクトのスーパークラスを関連付けることがある。たとえば、ＰｅｒｓｏｎｓをＢｉｒｄｓに関連付け、推論エンジン１１２が、Ｐｅｒｓｏｎと任意の種類のＢｉｒｄ（Ｄｕｃｋ、Ｖｕｌｔｕｒｅなど）との間の関係を多様な形で解釈することがある。

特定の実施形態においては、Ａｓｓｏｃ＿Ｅｌｅｍｅｎｔは、そのクラスが、それ自体、同じルールベースレベル（グローバル、ドメイン、ルールセット）にあるフィールドを指定する。この実施形態においては、ドメインレベルの関連付けは、ドメインレベルのクラスのためのフィールドのみを参照し、グローバルレベルのクラスのためのフィールドを参照しないことがある。

ルールベース１１４のサンプルは、以下に示すように、ルールベースレベルで、２つのＡｓｓｏｃ＿Ｅｌｅｍｅｎｔを定義することができる。
<assocname=“0wnership”>
<field_refname=“Owns”>
<identifiername=“Person”/>
</field_ref>
<field_refname=“IsOwnedBy”>
<identifiername=“Duck”/>
</field_ref>
</assoc>
<assoc name=“Siblingship”>
<field_refname=“IsSiblingOf”>
<identifiername=“Person”/>
</field_ref>
<field_refname=“IsSiblingOf”>
<identifiername=“Person”/>
</field_ref>
</assoc>

その上、ルールベース１１４は、関連付けフィールドを定義することができる。これらのフィールドは、その関連付けに特有なものではあるが、その関連付けの個々のメンバーには特有でない情報を維持するのに有用であり得る。たとえば、配偶者の関連付けが、ＤａｔｅＯｆＭａｒｒｉａｇｅフィールドを有することがある。関連付けフィールドを使用するために、推論エンジン１１２は、関連付けのインスタンスを維持し、他のインスタンスは、その関連付けインスタンスにアクセスすることができる。たとえば、Ｐｅｒｓｏｎインスタンスが、結婚した日を判断する必要があることがある。このことは、以下のような固有の方法で生じ得る。
marriage_date=@getAssocValue(Father.spouse,spousalship.marriage_date)
@setAssocValue(Father..spouse,Spousalship.marriage_date,20010708)
ここで、第１の引き数は、関連付け内で必要とされるインスタンスを指定し、第２の引き数は、関連する関連付けフィールドを示す。

別の実施形態においては、関連付けは、そのフィールドを参加しているインスタンスに「貸し出す」形で取り扱われ得る。たとえば、Ｐｅｒｓｏｎクラスは、Ｐｅｒｓｏｎが配偶者の関連付け内の役割クラスであるという事実により、ｍａｒｒｉａｇｅ＿ｄａｔｅフィールドを継承することができる。その場合、上記の例は、以下のように記録されることがある。
marriage_date=Father.marriage_date
Father.marriage_date=20010708

このアプローチにおいて、関連付けインスタンスのフィールド名が、Ｐｅｒｓｏｎクラス（及びその直系尊属クラス）のフィールド名にオーバラップすることがある。同様に、Ｐｅｒｓｏｎクラス（及びその直系尊属クラス）は、異なる関連付けインスタンスのために配偶者の役割を果たす２つのフィールドを定義できないことがある。さらに、Ｐｅｒｓｏｎが複数の異なる関連付け内でクラスの役割を果たす場合は、関連付けは、異なるフィールド名を用いることを必要とすることがある。
marriage_date=Father.Spousalship:marriage_date
Father.Spousalship:marriage_date=20010708
などにより、オプションである特別な接頭部を関連付けフィールドに使用して、これらの事柄のいくつかを無効化することができる。

６ＣｏｎｓｔｒａｉｎｔＳｅｔ＿Ｅｌｅｍｅｎｔ
この要素は、制約の定義の集合を指定し、以下のフォーマットを有する。
ConstraintSet_Element
::=(‘constraint_set’ConstraintSet_Attribs+)
Constraint_Element*
ConstraintSet_Attribs
::=Name_Attrib //Required
::=LocTag_Attrib //Optional
Constraint_Element
::=(‘constraint’Constraint_Attribs+)
GeneralExpr //Boolean expression
Constraint_Attribs
::=Name_Attrib //Required
::=LocTag_Attrib //Optional

ＣｏｎｓｔｒａｉｎｔＳｅｔ＿Ｅｌｅｍｅｎｔは、如何に値がフィールドに割り当てられるかを限定するための基準を指定する。推論エンジン１１２は、値をターゲットフィールドに割り当てる前に、制約を評価することがある。制約は、（ＦｉｅｌｄＤｃｌ＿Ｅｌｅｍｅｎｔを使用する）フィールドの宣言を用いるか、又は（ＳｔａｔｉｃＩｎｓｔＤｅｆ＿Ｅｌｅｍｅｎｔを使用する）静的インスタンスフィールド修飾子によるかのいずれかにより、フィールドに関連付けられることがある。それぞれの制約のＧｅｎｅｒａｌＥｘｐｒは、ブール式であり得る。この式は、固有の識別子（ｃａｎｄｉｄａｔｅ＿ｖａｌｕｅ）を、そのフィールドの提案する新しい値に対する記号参照として参照する。式を評価する場合には、推論エンジン１１２が、任意の記号参照に固有の識別子を代入することがある。その式の値は、候補値が制約を満たしているかどうかを示す。その式の値が真である場合は、推論エンジン１１２により、値の割当てを続行することが可能となる。真でない場合は、推論エンジン１１２は、フィールド宣言（又はフィールド修飾子）指定に依存するアクションをとることがある。

式は、方法を起動し、その範囲レベル内のあらゆるオブジェクトにアクセスすることがある。一実施形態においては、式は、未知の状態のフィールドを読み取ろうとしなかったり、又は副作用の原因となったりすることがある。この実施形態においては、これらのオペレーションのいずれかを検出するとすぐに、推論エンジン１１２は、誤りメッセージと共に推論を直ちにアボートする。

この要素は、複数の制約を定義することができ、これらの制約のそれぞれが、制約セット内に一意の名前を有することがある。この要素はまた、ルールベース１１４内のいくつかの異なるレベルで指定されることがある。たとえば、ルールベースレベル、ドメインレベル、及びルールセットレベルで指定され得る。推論エンジン１１２は、同じデータ型のフィールドなどの、いくつかの異なるフィールドの代わりに、同じ制約を評価することがある。

ルールベース１１４のサンプルは、以下に示すように、ルールベースレベルで、２つのＣｏｎｓｔｒａｉｎｔＳｅｔ＿Ｅｌｅｍｅｎｔを定義することができる。
<constraint_setname=“ThingConstraints”>
<constraint name=“CheckAgeConstraints”>
<![CDATA[
@candidate_value>=0 and @candidate_value<=max_age
]]>
</constraint>
</constraint_set>

<constraint_setname=“PersonConstraints”>
<constraint name=“CheckSympConstraints”>
<![CDATA[
@candidate_value<=ValidSymptoms
]]>
</constraint>
</constraint_set>

７ＥｘｔｅｒｎａｌＬｉｂ＿Ｅｌｅｍｅｎｔ
この要素により、ユーザは、Ｊａｖａ又はＣ＋＋で符号化されたライブラリなどの、１つ以上の「外部」ライブラリによって供給されるもので、規則定義言語機能を補足することができる。次いで、これらのユーザは、ルールベース１１４と共に外部ライブラリを分散することができる。ＥｘｔｅｒｎａｌＬｉｂ＿Ｅｌｅｍｅｎｔは、外部ライブラリにゲートウェイを提供する。ルールベース１１４の観点から見て、外部ライブラリは、入力パラメータ、出力パラメータ、及び戻り値を方法に提示する「ブラックボックス」のように見え得る。ルールベース１１４は、それ自体ルールベース１１４内で定義された方法であるので、外部ライブラリ内の方法を起動することができる。推論エンジン１１２は、起動をターゲット環境にマップすることを担当することができる。ＥｘｔｅｒｎａｌＬｉｂ＿Ｅｌｅｍｅｎｔの定義には、言語特有の、プラットフォーム特有の、又は環境特有の設定の指定が必要なことがある。その結果、推論エンジン１１２は、いくつかのターゲット特有のコードを含むことを必要とする場合も必要としない場合もある。

８Ｃｌａｓｓ＿Ｅｌｅｍｅｎｔ
この要素は、フィールド、方法、及び静的インスタンスのクラスを定義する。以下のフォーマットを有する。
Class_Element
::=(‘class’Class_Attribs+)
Class_Item*
Class_Attribs
::=Name_Attrib //Required
::=LocTag_Attrib //Optional
Class_Item
::=Parent_Element
::=FieldDcl_E1ement
::=ClassMethodDef_Element
::=StaticInstDef_Element
Parent_Element
::=(‘parent’[LocTag_Attrib])
IdentifierSpec //Parent Class

この要素は、ルールベース１１４内のいくつかの異なるレベルで指定されることがある。たとえば、ルールベースレベル、ドメインレベル、及びルールセットレベルで指定され得る。いくつかの又はすべての部分要素が、Ｎａｍｅ＿Ａｔｔｒｉｂを指定することがある。オーバーロードしている方法を除き、これらの名前は、クラスレベルでは一意であるが、これより高位のレベルでは名前をオーバーライドし、これより低位のレベルではオーバーライドされることがある。また、オーバーロードしている方法を除き、クラスが同名のオブジェクトを定義すると、ルールベースビルダ１１０は、マージプロセス中にこれらのオブジェクトを１つのルールベースオブジェクトにマージすることがある。Ｃｌａｓｓ＿Ｅｌｅｍｅｎｔは、親Ｃｌａｓｓ＿Ｅｌｅｍｅｎｔを任意に指定することができるので、クラスは１つの継承階層に編成され得る。一実施形態においては、クラスは、せいぜい１つの親クラスを有することがある。特定の実施形態においては、クラスが親を有する場合は、親クラス及び子クラスは、同じルールベースレベル（グローバル、ドメイン、ルールセット）に常駐する。この実施形態においては、ドメインレベルのクラスは、別のドメインレベルのクラスから導出され、グローバルレベルのクラスからは導出され得ない。

特定の実施形態においては、フィールド及び方法は、クラスレベルではなくインスタンスレベルであり、またフィールド及び方法は、プライベート又は保護されたアクセスレベルではなくパブリックレベルである。また、特定の実施形態においては、親クラスではなく末端クラスが生成され得る。クラスを包含するためのサポートがある場合もない場合もある。

ルールベース１１４のサンプルは、以下などの、ルールベースレベルで、いくつかのＣｌａｓｓ＿Ｅｌｅｍｅｎｔを定義することができる。
<classname=“Duck”>
<parent>
<identifiername=“Thing”/>
</parent>
<fieldname=“IsOwnedBy”>
<datatypecoll_type=“none”type=“inst-ref”>
<identifier name="Person”/>
</datatype>
</field>
</class>

８．１ＦｉｅｌｄＤｃｌ＿Ｅｌｅｍｅｎｔ
Ｃｌａｓｓ＿Ｅｌｅｍｅｎｔのこの要素は、クラスデータオブジェクトを定義し、以下のフォーマットを有する。
FieldDcl_Element
::=(‘field’FieldDcl_Attribs+)
DataType_Element
[ConstrainedBy_Element]
FieldDcl_Attribs
::=Name_Attrib //Required
::=ResolutionType_Attrib //Optional
::=LocTag_Attrib //Optional
ConstrainedBy_Element
::=(‘constrained_by’[LocTag_Attrib])
ConstrainerList_Element
[ConstraintViolation_Element]
ConstrainerList_Element
::=(‘constrainer_list’[LocTag_Attrib])
IdentifierSpec* //Applicable Constraints
ConstraintViolation_Element
::=(‘constraint_violation’[LocTag_Attrib])
ConstraintViolation_Option
ConstraintViolation_Option
::=ConstraintAbort_Element
::=ConstraintResume_Element
ConstraintAbort_Element
::=(‘constraint_abort’ConstraintAbort_Attribs*)
ConstraintAbort_Attribs
::=LocTag_Attrib //Optional
::=AbortMsg_Attrib //Optional
ConstraintResume_Element
::=(‘constraint_resume’ConstraintResume_Attribs*)
ConstraintResume_Atttibs
::=LocTag_Attrib //Optional
::=ResumeVal_Attrib //Optional

ＦｉｅｌｄＤｃｌ＿Ｅｌｅｍｅｎｔは、「解決タイプ」を任意に指定することができるフィールドである、フィールド解決タイプを含むことができる。解決タイプは、決定木規則を処理する場合に、推論エンジン１２２の挙動に適用され、「第１の値」（デフォルト）又は「最終値」のいずれかで指定され得る。この設定により、推論エンジン１１２はフィールドの第１の値がその解決値であると想定すべきか、又は推論エンジン１１２はその解決値に至る途中の中間値がフィールドに割り当てられると予想すべきかどうかが判断される。たとえば、Ａｇｅフィールドは、一般に、「第１の値」フィールドであり、ＳｅｔＯｆＲｅｓｕｌｔｓフィールドは、「最終値」フィールドである。

ＦｉｅｌｄＤｃｌ＿Ｅｌｅｍｅｎｔはまた、フィールド値の割当てに制約を課すべきであることを任意に指定することができる。フィールドに値を割り当てる前に、推論エンジン１１２は、ＣｏｎｓｔｒａｉｎｅｒＬｉｓｔ＿Ｅｌｅｍｅｎｔによって指定された順序で、ゼロ以上の制約を評価することがある。制約のいずれかがブール偽値を評価する場合は、推論エンジン１１２は、ＣｏｎｓｔｒａｉｎｔＶｉｏｌａｔｉｏｎ＿Ｅｌｅｍｅｎｔにより、違反アクションを実施することがある。ＣｏｎｓｔｒａｉｎｔＶｉｏｌａｔｉｏｎ＿ＥｌｅｍｅｎｔがＣｏｎｓｔｒａｉｎｔＡｂｏｒｔ＿Ｅｌｅｍｅｎｔを指定する場合は、推論エンジン１１２は、推論をアボートすることがある。その要素がＡｂｏｒｔＭｓｇ＿Ａｔｔｒｉｂを指定する場合は、その属性の値は、誤りメッセージテキストであり得る。そうでない場合は、誤りメッセージは、デフォルトテキストを反映することがある。ＣｏｎｓｔｒａｉｎｔＶｉｏｌａｔｉｏｎ＿ＥｌｅｍｅｎｔがＣｏｎｓｔｒａｉｎｔＲｅｓｕｍｅ＿Ｅｌｅｍｅｎｔを指定する場合は、推論エンジン１１２は、推論を再開することがある。その要素がＲｅｓｕｍｅＶａｌ＿Ｅｌｅｍｅｎｔを指定する場合は、推論エンジン１１２は、フィールドの現在の値を属性の値に置換することがある。そうでない場合は、フィールドは、その現在の値を保持することがある。ＣｏｎｓｔｒａｉｎｔＶｉｏｌａｔｉｏｎ＿Ｅｌｅｍｅｎｔがない場合は、推論エンジン１１２は、デフォルト誤りメッセージと共に推論をアボートすることがある。ＦｉｅｌｄＤｃｌ＿Ｅｌｅｍｅｎｔレベルで指定された制約が、そのフィールドのクラスのすべてのインスタンスに適用されることがある。ユーザが、インスタンス特有の制約を指定することもある。

ルールベース１１４のサンプルからのフィールド宣言のサンプルは、以下のようであり得る。
<fieldname=“Symptoms”>
<datatype coll_type=“set”type=“string”/>
<constrained_by>
<constrainer_list>
<identifier name=“CheckSympConstraints”/>
</constrainer_list>
<constraint_violation>
<constraint_abortabort_msg=“Invalid symptoms
specified”/>
</constraint_violation>
</constrained_by>
</field>

８．２ＣｌａｓｓＭｅｔｈｏｄＤｅｆ＿Ｅｌｅｍｅｎｔ
Ｃｌａｓｓ＿Ｅｌｅｍｅｎｔのこの要素は、クラス方法オブジェクトを定義し、以下のフォーマットを有する。
ClassMethodDef_Element
::=(‘method’ClassMethodDef_Attribs+)
[DataType_Element] //MethodReturnType
[ClassMethodParams]
[ClassMethodBody_Element]
ClassMethodDef_Attribs
::=Name_Attrib //Required
::=LocTag_Attrib //Optional
ClassMethodParams
::=ClassParam_Element
::=ClassParamList_E1ement
ClassParam_Element
::=(‘param’ClassParamAttribs+)
DataType_Element
ClassParamAttribs
::=Name_Attrib //Required
::=ParamIOType_Attrib //Optional
::=LocTag_Attrib //Optional
ClassParamList_Element
::=(‘method_params’[LocTag_Attrib])
ClassParam_Element*
ClassMethodBody_Element
::=(‘method_body’[LocTag_Attrib])
Statement*

方法は、任意のデータ型の任意の数の引き数を任意に受け入れることができ、そして、その方法は、それぞれのパラメータを入力（「イン」）パラメータ又は出力（「アウト」）パラメータのいずれかとして分類することがある。一実施形態においては、パラメータは、デフォルトにより、入力パラメータ又は出力パラメータのいずれかであり得る。特定の実施形態においては、パラメータは、入力パラメータと出力パラメータの両方ではないことがある。規則定義言語は、オーバーロードしている方法をサポートすることがあり、従って、それらのパラメータリストが区別できるものである限り、クラスは同じ名前の複数の方法を定義することがある。このような区別においては、ＣｌａｓｓＰａｒａｍＡｔｔｒｉｂｓ（ＰａｒａｍＩＯＴｙｐｅ＿Ａｔｔｒｉｂなど）又は数字の精度を斟酌しないことがある。方法は、任意のデータ型の１つ以上の値を任意に返すことができる。方法が値を返すと、サーバ１０２は、それを機能方法として分類することがある。そうでない場合は、サーバ１０２は、それを手順方法として分類することがある。サーバ１０２は、恐らく手順方法に課されない機能方法に制限を課す。これは、機能方法が式であり、式が副作用を有さないためである。したがって、サーバ１０２は、機能方法が、出力パラメータをサポートし、フィールドに値を割り当て、手順方法を起動し、又は動的インスタンスを作成又は消去することを認めないことがある。

ＣｌａｓｓＭｅｔｈｏｄＢｏｄｙ＿Ｅｌｅｍｅｎｔが指定されない場合は、サーバ１０２は、別のルールベース１１４が方法の実施を定義し、他のルールベース１１４が推論の前に現在のルールベース１１４とマージされると想定することがある。

ルールベース１１４のサンプルからの方法定義のサンプルは、以下のようであり得る。
<method name=“Has1stSymptomButNot2ndOne”>
<datatypecoll_type=“none”type=“boolean”/>
<method_params>
<paramname=“symp1”iotype=“in”>
<datatype coll_type=“none”type="string”/>
</param>
<paramname=“symp2”iotype=“in”>
<datatype coll_type=“none”type=“string”/>
</param>
</method_params>
<method_body>
<![CDATA[
return Symptoms.@Set_DoesIncludeVal(symp1)
and not Symptoms.@Set_DoesIncludeVal(symp2)
]]>
</method_body>
</method>

８．３ＳｔａｔｉｃＩｎｓｔＤｅｆ＿Ｅｌｅｍｅｎｔ
Ｃｌａｓｓ＿Ｅｌｅｍｅｎｔのこの要素は、クラス静的インスタンスオブジェクトを定義し、以下のフォーマットを有する。
StaticInstDef_Element
::=(‘instance’StaticInst_Attribs+)
[FieldModifiers_Element]
StaticInst_Attribs
::=Name_Attrib //Required
::=LocTag_Attrib //Optional
FieldModifiers_Element
::=(‘field_modifiers’[LocTag_Attrib])
FieldModifier_Element*
FieldModifier_Element
::=(‘field_modifier’FieldModifier_Attribs+)
[ConstrainedBy_Element]
[LastChanceValue_Element]
FieldModifier_Attribs
::=Name_Attrib //Required
::=LocTag_Attrib //Optional
LastChanceValue_Element
::=(‘lastchance_value’[LocTag_Attrib])
LastChanceValue
LastChanceValue
::=LiteralConstant_Element
::=UnaryExpr //with LiteralConstant_Element
::=SetConstant_Element
::=IdentifierSpec //Instance name

推論エンジン１１２は、インスタンスのクラスをロードする場合に静的インスタンスを作成し、インスタンスのクラスをアンロードする場合にそのインスタンスを消去することがある。一実施形態においては、ルールベース論理は、静的インスタンスを明示的に作成又は消去できないことがある。この要素は、最後のチャンス値及び制約などの、インスタンス特有のフィールド特性を指定するＦｉｅｌｄＭｏｄｉｆｉｅｒｓ＿Ｅｌｅｍｅｎｔを任意に指定することがある。ＦｉｅｌｄＭｏｄｉｆｉｅｒｓ＿ＥｌｅｍｅｎｔのためのＮａｍｅ＿Ａｔｔｒｉｂは、影響を受けたインスタンスフィールドを示す。この名前から、インスタンスのクラスによって宣言された又は継承されたフィールドが識別されることがある。

ＬａｓｔＣｈａｎｃｅＶａｌｕｅ＿Ｅｌｅｍｅｎｔは、フィールドのための最後のチャンス値を指定する。インスタンス参照データ型については、最後のチャンス値は、別の静的インスタンス又はこのようなインスタンスの１組のための識別子であり得る。別のデータ型のフィールドについては、値は、リテラル定数、セット定数、又はリテラル定数上の単項演算子であり得る。後者の場合には、リテラル定数は、数字又はブール定数であり得る。推論エンジン１１２は、決定木規則に関して良く定義された状況において、最後のチャンス値を適用でき、従って、最後のチャンス値の静的インスタンス定義は、推論エンジン１１２がそれらに適用されることを本質的に保証しないことがある。

制約部分要素は、フィールド値の割当てに制約を課すべきであることを指定する。制約についてのさらなる情報が、ＦｉｅｌｄＤｃｌ＿Ｅｌｅｍｅｎｔセクション内のＣｏｎｓｔｒａｉｎｅｄＢｙ＿Ｅｌｅｍｅｎｔについての上記の記述において見られることがある。ＳｔａｔｉｃＩｎｓｔＤｅｆ＿Ｅｌｅｍｅｎｔレベルで指定された制約は、そのインスタンスのみに適用されることがある。たとえば、ユーザは、Ｍｏｔｈｅｒ．ＡｇｅではなくＦａｔｈｅｒ．Ａｇｅのための異なる制約を指定することができる。ユーザはまた、あるクラスのすべてのインスタンスに適用されるクラスレベルの制約を指定することがある。所与のフィールドについて、ユーザが両方のレベルの制約を指定した場合は、推論エンジン１１２は、インスタンス特有の制約の前に、クラスレベルの制約を適用することがある。

ルールベース１１４のサンプルからのＳｔａｔｉｃＩｎｓｔＤｅｆ＿Ｅｌｅｍｅｎｔ定義のサンプルは、以下のようであり得る。
<instancename=“CurrentPatient”>
<field_modifiers>
<field_modifiername=“age”>
<lastchance_value>
<literal_constant value=“55”/>
</lastchance_value>
</field_modifier>
</field_modifiers>
</instance>

９Ｄｏｍａｉｎ＿Ｅｌｅｍｅｎｔ
この要素は、ルールベースレベルのドメインリソースを定義し、以下のフォーマットを有する。
Domain_Element
::=(‘domain’Domain_Attribs+)
Domain_Items*
Domain_Attribs
::=Name_Attrib //Required
::=AppShared_Attrib //Optional
::=LocTag_Attrib //Optional
Domain_Items
::=DomainGoal_Element
::=DomainAppSharedFlds_Element
::=InitMethodDef_Element
::=Assoc_Element
::=ConstraintSet_Element
::=Class_Element
::=Ruleset_Element

この要素は、ＡｐｐＳｈａｒｅｄ＿Ａｔｔｒｉｂフィールドを使用することにより、ドメインがクライアントアプリケーション１２２によってロードされることを任意に指定することがある。そうでない場合は、ドメインは、ｄｍｎ＿ｐｕｓｈ（）固有の方法を使用してルールベース論理からロードできる。ルールベース１１４は、少なくとも１つのドメインをクライアントアプリケーション１２２と共用することがあるが、複数のドメインをクライアントアプリケーション１２２と共用することもできる。

大部分の部分要素は、Ｎａｍｅ＿Ａｔｔｒｉｂを指定することがある。これらの名前は、ドメインレベルでは一意であるが、これより高位のレベルでは名前をオーバーライドし、これより低位のレベルではオーバーライドされることがある。ドメインが所与のレベルで同名のオブジェクトを定義すると、ルールベースビルダ１１０は、マージプロセス中に、これらのオブジェクトを１つのルールベースオブジェクトにマージすることがある。

ＩｎｉｔＭｅｔｈｏｄＤｅｆ＿Ｅｌｅｍｅｎｔ、Ａｓｓｏｃ＿Ｅｌｅｍｅｎｔ、ＣｏｎｓｔｒａｉｎｔＳｅｔ＿Ｅｌｅｍｅｎｔ、Ｃｌａｓｓ＿Ｅｌｅｍｅｎｔなどの、ドメイン部分要素のいくつかは、前に記述したルールベースレベルの部分要素と同じであり得る。ＤｏｍａｉｎＧｏａｌ＿Ｅｌｅｍｅｎｔ、ＤｏｍａｉｎＡｐｐＳｈａｒｅｄＦｌｄｓ＿Ｅｌｅｍｅｎｔ、Ｒｕｌｅｓｅｔ＿Ｅｌｅｍｅｎｔなどの他の部分要素は、ドメインに特有であり、これについては以下に記述する。

９．１ＤｏｍａｉｎＧｏａｌ＿Ｅｌｅｍｅｎｔ
Ｄｏｍａｉｎ＿Ｅｌｅｍｅｎｔのこの要素は、ドメインのための目標フィールドを指定し、以下のフォーマットを有する。
DomainGoal_Element
::=(‘domain_goal’[LocTag_Attrib])
IdentifierSpec //Backward-chaining goal(Field)

Ｄｏｍａｉｎ＿ＥｌｅｍｅｎｔがＤｏｍａｉｎＧｏａｌ＿Ｅｌｅｍｅｎｔを指定する場合は、推論エンジン１１２は、目標フィールドを解決するために、ドメインの規則を後ろ向き連鎖することがある。指定しない場合は、推論エンジン１１２は、ドメインの規則を前向き連鎖することがある。

ルールベース１１４のサンプルからのＤｏｍａｉｎＧｏａｌ＿Ｅｌｅｍｅｎｔのサンプルは、以下のようであり得る。
<domain name=“PerformConclusionAnalysis”appshared=“true”>
<domain_goal>
<identifiername=“OverallConclusion”/>
</domain_goal>
...
</domain>

９．２ＤｏｍａｉｎＡｐｐＳｈａｒｅｄＦｌｄｓ＿Ｅｌｅｍｅｎｔ
Ｄｏｍａｉｎ＿Ｅｌｅｍｅｎｔのこの要素は、クライアントアプリケーション１２２と共用されるフィールドを指定し、以下のフォーマットを有する。
DomainAppSharedFlds_Element
::=(‘appshared_fields’[LocTag_Attrib])
[DomainPreConditionList_Element]
[DomainPostConditionList_Element]
DomainPreConditionList_Element
::=(‘precondition_list’[LocTag_Attrib])
ConditionListItem*
DomainPostConditioniList_Element
::=(‘postcondition_list’[LocTag_Attrib])
ConditionListItem*
ConditionListItem //Restricted to globalfields
::=IdentifierSpec
::=FieldRef_Element

ドメインがＤｏｍａｉｎＡｐｐＳｈａｒｅｄＦｌｄｓ＿Ｅｌｅｍｅｎｔ部分要素を含む場合は、そのドメイン自体が、クライアントアプリケーション１２２と自動的に共用されることがある。ＤｏｍａｉｎＡｐｐＳｈａｒｅｄＦｌｄｓ＿Ｅｌｅｍｅｎｔは、２つの部分要素、即ち、事前条件を推論するための部分要素、及び事後条件を推論するための別の部分要素を指定する。それぞれの部分要素が、ゼロ以上のルールベースレベルのフィールドを指定する。一実施形態においては、リストは、ドメインレベルのフィールドではなくルールベースレベルのフィールドを指定することがある。両方のリストに同じフィールドが指定されると、そのフィールドは、事前条件フィールドであると想定されることがある。

ＤｏｍａｉｎＰｒｅＣｏｎｄｉｔｉｏｎＬｉｓｔ＿Ｅｌｅｍｅｎｔは、クライアントアプリケーション１２２によって読取り可能かつ書込み可能なフィールドを識別する。ＤｏｍａｉｎＰｏｓｔＣｏｎｄｉｔｉｏｎＬｉｓｔ＿Ｅｌｅｍｅｎｔは、クライアントアプリケーション１２２に対して読取り専用のフィールドを識別する。推論エンジン１１２は、クライアントアプリケーション１２２によるフィールドへの不正アクセスの試行を拒絶することがある。一実施形態においては、異なるルールベースドメインは、それらの入力及び出力フィールドが異なることがあるので、異なるＤｏｍａｉｎＡｐｐＳｈａｒｅｄＦｌｄｓ＿Ｅｌｅｍｅｎｔを指定することがある。

ルールベース１１４のサンプルからのＤｏｍａｉｎＡｐｐＳｈａｒｅｄＦｌｄｓ＿Ｅｌｅｍｅｎｔのサンプルは、以下のようであり得る。
<domain name=“PerformConclusionAnalysis”appshared=“true”>
...
<appshared_fields>
<precondition_list>
<identifier name=“Fact1”/>
<identifier name=“Fact2”/>
<identifier name=“Fact3”/>
<identifier name=“Fact4”/>
</precondition_list>
<postcondition_list>
<identifier name=“OverallConclusion”/>
<postcondition_list>
</appshared_fields>
...
</domain>

上記の例は、４つの事前条件フィールド及び１つの事後条件フィールドの定義を示している。それぞれのフィールドについて、これらのフィールドのために定義されたクラスインスタンスはただ１つしかない（従って参照曖昧性がない）ので、１つの識別子のみが指定されている。一般に、共用されるフィールドは１つの静的インスタンスに特有であるので、たとえば、ドメインが、Ｍｏｔｈｅｒ．ＡｇｅではなくＦａｔｈｅｒ．Ａｇｅを共用することがある。ドメインが複数のインスタンスのためのフィールドを共用する必要がある場合は、ＤｏｍａｉｎＡｐｐＳｈａｒｅｄＦｌｄｓ＿Ｅｌｅｍｅｎｔは、以下などにより、それぞれのインスタンスに１つずつ、複数のフィールドを指定することがある。
<precondition_list>
<identifier_path>
<identifiername=“Father”/>
<identifiername=“Age”/>
</identifier_path>
<identifier_path>
<identifiername=“Mother”/>
<identifiername=“Age”/>
<identifier_path>
</precondition_list>

ドメインはまた、クラスのすべてのインスタンスのためのフィールドを共用することを選択することができる。そのために、ＤｏｍａｉｎＡｐｐＳｈａｒｅｄＦｌｄｓ＿Ｅｌｅｍｅｎｔは、以下などにより、ＦｉｅｌｄＲｅｆ＿Ｅｌｅｍｅｎｔを使用してフィールドを指定する。
<precondition_list>
<field_ref name=“Age”>
<identifiername=“Person”/>
</field_ref>
</precondition_list>

この例は、ＡｇｅフィールドがＰｅｒｓｏｎのすべてのインスタンスに共用されるべきであることを指定する。このことは、動的インスタンスと共に使用される場合に有用であり得るが、この場合、所与のフィールドのためにすべてのインスタンスを項目別に掲げることは、実際的でもなければ可能でもない。

ＦｉｅｌｄＲｅｆ＿Ｅｌｅｍｅｎｔは、以下などの、親クラス及び末端クラスを指定することができる。
<precondition_list>
<field_refname=“Age”>
<identifiername=“Bird”/>
</field_ref>
</precondition_list>

この形式は、以下などの、その親クラスから導出されるすべての末端クラスのための省略表現である。
<precondition_list>
<field_refname=“Age”>
<identifiername=“Duck”>
</field_ref>
<field_refname=“Age”>
<identifiername=“Vulture”/>
</field_ref>
<field_refname=“Age”>
<identifiername=“Robin”/>
</field_ref>
</precondition_list>

９．３Ｒｕｌｅｓｅｔ＿Ｅｌｅｍｅｎｔ
Ｄｏｍａｉｎ＿Ｅｌｅｍｅｎｔのこの要素は、ルールセットレベルのリソースを定義し、以下のフォーマットを有する。
Ruleset_Element
::=(‘ruleset’Ruleset_Attribs+)
Ruleset_Item*
Ruleset_Attribs
::=Name_Attrib //Required
::=Post_Attrib //Optional
::=AppShared_Attrib //Optional
::=LocTag_Attrib //Optional
Ruleset_Item
::=InitMethodDef_Element
::=Assoc_Element
::=ConstraintSet_Element
::=Class_Element
::=Rule_Element

この要素は、Ｐｏｓｔ＿Ａｔｔｒｉｂフィールドを使用して、推論エンジン１１２が、ルールセットの規則を、クライアントアプリケーション１２２又はルールベース論理によって制御されるドメインの規則アジェンダに条件付きで記入すべきであることを任意に指定することがある。デフォルトにより、推論エンジン１１２は、ルールセットがロードされる場合に、規則をアジェンダに無条件で記入することがある。この要素はまた、ＡｐｐＳｈａｒｅｄ＿Ａｔｔｒｉｂフィールドを使用して、ルールセットがクライアントアプリケーション１２２からアクセス可能であることを任意に指定することがある。そうでない場合は、ルールセットは、ルールベース論理からのみアクセス可能である。

ドメインは、クライアントアプリケーション１２２と、複数のルールセットを共用することがある。ドメインがルールセットを共用する場合は、ドメイン自体もまた、クライアントアプリケーション１２２と自動的に共用されることがある。ルールセットがアプリケーションと共用される場合は、Ｐｏｓｔ＿Ａｔｔｒｉｂは、「条件付き」に設定されることがある。そうでない場合は、サーバ１０２は、シンタックス誤りと共に要素を拒絶することがある。ルールセットがクライアントアプリケーション１２２と共用されされない場合は、Ｐｏｓｔ＿Ａｔｔｒｉｂは、「条件付き」又は「無条件」のいずれかに設定されることがある。

すべての部分要素は、Ｎａｍｅ＿Ａｔｔｒｉｂを指定することがある。これらの名前は、ルールセットレベルでは一意であるが、これより高位のレベルではオーバーライドし、これより低位のレベルではオーバーライドされることがある。ルールセットが所与のレベルで同名のオブジェクトを定義すると、ルールベースビルダ１１０は、マージプロセス中に、これらのオブジェクトを１つのルールベースオブジェクトにマージすることがある。

ＩｎｉｔＭｅｔｈｏｄＤｅｆ＿Ｅｌｅｍｅｎｔ、Ａｓｓｏｃ＿Ｅｌｅｍｅｎｔ、ＣｏｎｓｔｒａｉｎｔＳｅｔ＿Ｅｌｅｍｅｎｔ、Ｃｌａｓｓ＿Ｅｌｅｍｅｎｔなどのルールセット部分要素のいくつかは、上述したルールベースレベルの部分要素と同じである。Ｒｕｌｅ＿Ｅｌｅｍｅｎｔは、ルールセットに特有なものであり、これについては以下に記述する。

ルールベース１１４のサンプル内のＲｕｌｅｓｅｔ＿Ｅｌｅｍｅｎｔのサンプルは、以下のようであり得る。
<domainname=“PerformConclusionAnalysis” appshared=“true”>
...
<rulesetname=“ConclusionAnalysis”>
...
</ruleset>
...
</domain>

１０Ｒｕｌｅ＿Ｅｌｅｍｅｎｔ
この要素は、規則を定義し、以下のフォーマットを有する。
Rule_Element
::=(‘rule’Rule_Attribs+)
RuleBody
Rule_Attribs
::=Name_Attrib //Required
::=Priority_Attrib //Optional
::=Enabled_Attrib //Optional
::=LocTag_Attrib //Optional
RuleBody
::=DecisionTree_Element
::=PatternMatching_Element

この要素は、Ｐｒｉｏｒｉｔｙ＿Ａｔｔｒｉｂフィールドを使用して、優先レベルを任意に指定することがある。推論エンジン１１２は、最高値から最低値へ又は最低値から最高値へなどの優先順位により、ドメインアジェンダ内の規則を順番付けることがある。要素が優先レベルを指定しない場合は、推論エンジン１１２は、ゼロ又は他の好適な値のデフォルト優先度を割り当てることがある。

この要素はまた、Ｅｎａｂｌｅｄ＿Ａｔｔｒｉｂ属性を介して推論するために、規則を動作可能にすべきかどうかを任意に指定することがある。動作可能にすると、その規則は推論に参加する。そうでない場合は、推論エンジン１１２はその規則を無視する。一実施形態においては、規則はデフォルトにより動作可能となっている。

規則定義言語は、本来、２つのタイプの規則、即ち決定木規則及びパターン合致規則をサポートする。同じルールセット内に異なるタイプが混合していることがある。ルールエディタ１３２及びトランスフォーマ１３３などの、ルールエディタ及びコンバータが、追加のタイプの規則をサポートするよう選択することがある。たとえば、Ｉｎｆｉｘ−ｔｏ−ＸＭＬツールもまた、ＩＦ−ＴＨＥＮ規則をサポートすることができる。ＩＦ−ＴＨＥＮ規則とは決定木規則の単純な特化であり得るので、Ｉｎｆｉｘ−ｔｏ−ＸＭＬツールは、ＩＦ−ＴＨＥＮ規則から決定木規則を生成することができる。ＩＦ−ＴＨＥＮ規則と同様に、デシジョンテーブル規則も決定木規則の特化であり得るので、デシジョンテーブル規則についても同じことが言える。

ルールベース１１４のサンプルからのいくつかのサンプルＲｕｌｅ＿Ｅｌｅｍｅｎｔは、以下のようであり得る。
<domainname=“PerformConclusionAnalysis”appshared=“true”>
...
<rulesetname=“ConclusionAnalysis”>
<rulename=“Overall_status">
...
</rule>
<rulename=“Conclusion1_status”>
...
</rule>
<rulename=“Conclusion2_status”>
...
</rule>
</ruleset>
</domain>

１０．１ＤｅｃｉｓｉｏｎＴｒｅｅ＿Ｅｌｅｍｅｎｔ
Ｒｕｌｅ＿Ｅｌｅｍｅｎｔのこの要素は、決定木規則の本体を定義する。

１０．１．１構造要素
決定木は、以下の形式を有する１つ以上の決定を含む。
DecisionTree_Element
::=(‘dec_tree_body’[LocTag_Attrib])
Decision_Element+

１０．１．１．１決定
それぞれの決定は、識別子（Ｎａｍｅ＿Ａｔｔｒｉｂ）によって名づけられ、以下の部分要素を含む。
Decision_Element
::=(‘decision’Decision_Attribs+)
GeneralExpr
DecTestGroup_Element*
[DecOtherwise_Element]
[DecUnknown_Element]
Decision_Attribs
::=Name_Attrib //Required
::=LocTag_Attrib //Optional

異なる規則内の決定が同じ決定名を有することがあるが、所与の規則内の決定は、一意の名前を有することがある。決定が、任意のデータ型の基本式（ＧｅｎｅｒａｌＥｘｐｒ）を定義することがある。この式は、フィールドを参照し、方法を起動することがある。決定はまた、１つ以上の試験グループ（ＤｅｃＴｅｓｔＧｒｏｕｐ＿Ｅｌｅｍｅｎｔ）を定義することがある。決定は、さらに、別様の文節（ＤｅｃＯｔｈｅｒｗｉｓｅ＿Ｅｌｅｍｅｎｔ）及び／又は未知の文節（ＤｅｃＵｎｋｎｏｗｎ＿Ｅｌｅｍｅｎｔ）を任意に定義することがある。

１０．１．１．２試験グループ決定
それぞれの試験グループは、１つ以上の場合式及び１つの動作句を指定し、以下の形式を有する。
DecTestGroup_Element
::=(‘dec_test_group’[LocTag_Attrib])
DecCaseExpr+
DecAction

推論エンジン１１２は、場合式（ＤｅｃＣａｓｅＥｘｐｒ）の値を、その決定の基本式の値と比較する。推論エンジン１１２が少なくとも１つの「等しい」比較を発見すると、推論エンジン１１２は、そのグループの動作句（ＤｅｃＡｃｔｉｏｎ）によって指定されたアクションを実施する。

１０．１．１．３別様の文節決定
別様の文節は、現在の決定のためのデフォルトの動作句を指定し、以下の形式を有する
DecOtherwise_Element
::=(‘dec_otherwise’[LocTag_Attrib])
DecAction

試験グループ決定がない場合、又はそれらのいずれも、結果として「真」の比較を生じない場合は、推論エンジン１１２は、この文節の動作句（ＤｅｃＡｃｔｉｏｎ）によって指定されたアクションを実施する。

１０．１．１．４未知の文節決定
未知の文節も、別様の文節と同様に、現在の決定のための、特別な場合の動作句であり、以下の形式を有する。
DecUnknown_Element
::=(‘dec_unknown’[LocTag_Attrib])
DecAction

推論エンジン１１２は、未知のフィールドの参照により、その決定の基本式を評価できない場合は、この文節の動作句（ＤｅｃＡｃｔｉｏｎ）によって指定されたアクションを実施する。

１０．１．１．５動作句決定
動作句は、２つのタイプのアクションの１つを指定することができ、以下の形式を有する。
DecAction
::=DecStatements_Element
::=DecRef_Element //Nested Decision
DecStatements_Element
::=(‘dec_statements’[LocTag_Attrib])
Statement*
DecRef_Element
::=(‘dec_ref’DecRef_Attribs+)
DecRef_Attribs
::=Name_Attrib //Decision name-Required
::=LocTag_Attrib //Optional

ステートメント動作句（ＤｅｃＳｔａｔｅｍｅｎｔｓ＿Ｅｌｅｍｅｎｔ）は、実施すべきゼロ以上のステートメントを指定する。これらのアクションを実施するとすぐに、推論エンジン１１２は、（文節がいくつかのステートメントを指定した場合は）「ファイアされた」又は「保留された」状態のいずれかで、あるいは（文節がステートメントを指定しなかった場合は）「フェイルされた」状態で、その規則を終了する。

決定動作句（ＤｅｃＲｅｆ＿Ｅｌｅｍｅｎｔ）は、現在の決定木規則内の別の決定に名前を付ける。推論エンジン１１２は、その名前が付けられた決定を、現在の決定の部分決定として追求する。所与の規則について、（同じ決定であろうとも又は異なる決定であろうとも）複数の決定動作句はすべて、部分決定として同じ決定を参照することがある。

１０．１．１．６試験グループの場合式
それぞれの試験グループの場合式は、部分比較を指定し、以下の形式を有する。
DecCaseExpr
::=PartComp_EQ_Element //=GeneralExpr
::=PartComp_NE_Element //<>GeaeraExpr
::=PartComp_LT_Element //<GeneralExpr
::=PartComp_LTEQ_Element //<=GeneralExpr
::=PartComp_GT_Element //>GeneralExpr
::=PartComp_GTEQ_Element //>=GeneralExpr
::=PartComp_Range_Element //in range:(GeneraIExpr1 GeneralExpr2)

部分比較（ＰａｒｔＣｏｍｐ＿ｘｘｘ＿Ｅｌｅｍｅｎｔｓ）については後に記述する。一実施形態においては、これらの式は定数式である必要はない。たとえば、これらの式は、自由にフィールドを参照し、方法を起動することがある。これらの式はまた、その決定の基本式とタイプ互換性を有することがある。

１０．１．２動的識別子経路内のナル
一実施形態においては、動的識別子経路は、ナル値を含むことができる。たとえば、ステートメント、
Duckl.OwnedBy.SpouseOf.Name=“fred”
において、ＳｐｏｕｓｅＯｆは、ナル値を有することがある。基本式の評価中にナル値が検出されると、推論エンジン１１２は、（ｏｔｈｅｒｗｉｓｅ文節を指定しない場合は）規則をフェイルすることがある。テストケースの評価中にナル値が検出されると、推論エンジン１１２は、そのテストケースをフェイルするが、他のテストケースで再開することがある。アクションの実施中にナル値が検出されると、推論エンジン１１２は、誤りと共に推論をアボートすることがある。

推論エンジン１１２はまた、単純実行文について考慮することがある。たとえば、これらのステートメント、
isTrue=Duckl.OwnedBy.SpouseOf.Name=“fred”
//SpouseOf is null
isTrue=Duckl.owner.age>5and Duckl.spouse.age<5
//Owner and/or Spouse are null
において、推論エンジン１１２は、アボートするのではなく、関係部分式を偽であると評価することがある。同様に、
evalDuckl.owner.age<5 or Duckl.spouse.age<5//Owner is null
などの基本式の前提について、
推論エンジン１１２は、個々の比較をフェイルすることがある。しかし、Ｏｗｎｅｒがナルであり、Ｓｐｏｕｓｅがナルではなく、Ｓｐｏｕｓｅが充分に若い場合に、推論エンジン１１２は、なおも基本式を真であると評価することがある。

１０．１．３規則及び挙動の例
決定木の決定が、Ｃ、Ｃ＋＋、及びＪａｖａで見られるスイッチステートメントと同様であることがある。決定の基本式はスイッチ式に対応し、試験グループの場合式はそのスイッチの場合分け文に対応し、決定の別様の文節はそのスイッチのデフォルトの場合に対応することがある。

ここに、１つの決定を反映する、非常に単純な決定木規則のインフィックスコードの例がある。
<rule name=“Fact1_is_true”>
<![CDATA[
decisionmain
evalFact2
then
case=false:
do Fact1=true end
end
]]>
</rule>

この例は、より従来型のＩＦ規則の均等物である。規則は、Ｆａｃｔ２が偽である場合は、Ｆａｃｔ１を真に設定する。

ここに、複数の決定を反映する別の例がある。
<rulename=“Determine_Fact4_status”>
<![CDATA[
decisionmain
evalage
then
case<21.5:
decision sub1
case>=30..<=32:
case>=41..<=55.5:
decision sub2
case>32..<41:
do end
otherwise:
do Fact4=false end
unknown:
do Fact4=true end
end
decisionsub1
evalFact2
then
case=true:
do Fact4=false end
otherwise:
do Fact4=true end
end

decisionsub2
evalFact3
then
case=false:
do Fact4=true end
otherwise:
do Fact4=false end
end
]]>
</rule>

この規則は、年齢を評価し、その結果に基づいて、アクションを条件付きで実施する。場合によっては（年齢が１５であるなどの）、アクションは、（規則にそれに特徴的な木状の挙動を与える）別の決定を処理する。他の場合には（年齢が３５であるなどの）、実施するアクションはない。

この例においては、決定試験グループは、（年齢が３５及び４５であるなどの）アクションを共用するために、場合を「スタックする」ことができる。未知の文節を使用すると、年齢が未知である状況を捕え、別様の文節を使用すると、決定試験グループによってカバーされていない状況を捕える。

１０．１．４追加挙動
１０．１．４．１ルールベースのコンパイル中
一実施形態においては、ルールベースビルダ１１０は、所与の決定木規則について、すべての決定が一意に名づけられることを確実にすることがある。この実施形態においては、ルールベースビルダ１１０はまた、規則の決定の正確に１つが、他の任意の決定により部分決定として参照されないことを確実にすることがある。ルールベースビルダ１１０は、この決定を規則のルート決定として区別することがある。規則は、決定が部分決定として互いを如何に参照するかに関わらず、任意の順序で決定を指定することがある。複数の決定動作句が、同じ決定を部分決定として指定することがある。ルールベースビルダ１１０は、自己参照決定及び決定間の「周期的」参照を認めないことがある。

１０．１．４．２推論中
一実施形態においては、推論エンジン１１２は、ルート決定における規則処理を開始する。次いで、この実施形態においては、推論エンジン１１２は、そこでの結果に従って、その決定のネストされた決定のせいぜい１つに進むことがある。決定は、任意の数のレベルにネストされることがあるが、それぞれのレベルでは、推論エンジン１１２の挙動は、同様であり得る。

所与の決定について、推論エンジン１１２は、決定の基本式をまず評価する。未知のフィールドの参照により、それがフェイルすると、推論エンジン１１２は、（指定されている場合は）未知の文節のためのアクションを実施する。このような文節がない場合は、推論エンジン１１２は、規則の処理を保留された状態で直ちに終了する。

推論エンジン１１２が決定の基本式を成功裏に評価すると、推論エンジン１１２は、次に、その式の値を任意の試験グループの場合式に適用する。推論エンジン１１２は、その決定によって指定された順序で試験グループを訪問する。それぞれの試験グループ内で、推論エンジン１１２は、その試験グループによって指定された順序で場合式を訪問する。

真の場合を検出するとすぐに、推論エンジン１１２は、その所有グループのアクションを実施する。試験グループのいずれの場合にも適用されない場合は、推論エンジン１１２は、（定義されている場合は）別様の文節のアクションを実施するか、又は規則の処理をフェイルされた状態で終了する。

ステートメント動作句は、空である場合も又は空でない場合もある。空である場合は、推論エンジン１１２は、規則の処理をフェイルされた状態で終了する。空でない場合は、推論エンジン１１２は、規則の処理をファイアされた又は保留された状態で終了する。

１０．１．４．３場合式のための規則の保留
推論エンジン１１２は、試験グループの場合式を共通のアクションのための代替資格とみなすことがある。場合式のいずれかが真の場合となると、推論エンジン１１２は、そのグループのアクションを実施する。

未知のフィールドの参照により、場合式の評価がフェイルすると、推論エンジン１１２は、真の場合のためのそのグループの場合式の他の場合式を評価する。場合式が見つからなかった場合は、推論エンジン１１２は、保留された状態でその規則を終了する。

このように取り扱った結果、複数のテストケースを有する試験グループは、それぞれ、１つのテストケースを有する複数の試験グループの文意的な均等物でないことがある。たとえば、以下の試験グループが与えられると、
case<minimum
case>maximum
case>dangerous_range_start..<dangerous_range_end
do
DoSomething()
end
推論エンジン１１２は、たとえ最小値及び最大値が未知であっても、基本式の値が危険範囲内にある場合は、その規則をファイアする。しかし、以下の一見均等物であるような試験グループが与えられると、
case<minimum
do
DoSomething()
end
case>maximum
do
DoSomething()
end
case>dangerous_range_start..<dangerous_range_end
do
DoSomething()
end
推論エンジン１１２は、たとえ最大値及び／又は範囲値が既知であっても、最小値が未知である場合は、保留された状態でその規則を直ちに終了する。

１０．１．４．４ステートメントアクションのための規則の保留
規則アクションを実施している間に、推論エンジン１１２が未知のフィールドに対する参照を検出すると、推論エンジン１１２は、保留された状態でその規則を直ちに終了する。規則を再始動するとすぐに、推論エンジン１１２は、前に規則を保留する原因となったアクションの実行を再開する。

１０．１．５その他の考慮事項
推論エンジン１１２は、決定木規則を前向き連鎖又は後ろ向き連鎖することができる。一実施形態においては、決定木規則は、（ｉｎｓｔ＿ｍａｋｅ固有の方法を介して）動的インスタンスを作成することができるが、動的インスタンスにアクセスしないこともある。この実施形態においては、静的インスタンスのためのフィールド及び方法のみを参照することができる。

１０．２ＰａｔｔｅｒｎＭａｔｃｈｉｎｇ＿Ｅｌｅｍｅｎｔ
Ｒｕｌｅ−Ｅｌｅｍｅｎｔのこの要素は、パターン合致規則を定義し、以下のフォーマットを有する。
PatternMatching_Element
::=(‘pm_rule’PM_Attribs*)
PMBindVars
PMPremise_Element
PMActions_Element
[PMOrderBy_Element]
PM_Attribs
::=PMOptions_Attrib //Optional(seevalues below)
::=LocTag_Attrib //Optional
//forPMOptions_Attrib:
PMOption
::=‘mostrecent’
::=‘singlefire’

この規則は、１つ以上の選択肢をフィールドとして指定することができる。これらの選択肢は、インスタンス結合の順序付け（ｍｏｓｔｒｅｃｅｎｔ）、及び推論エンジン１１２が、（第１の結合のために）１回のみ又は（すべての結合のために）複数回、規則をファイアするかどうかに影響を及ぼす。デフォルトにより、推論エンジン１１２は、結合を先入れ先出し方式で（ｌｅａｓｔ−ｒｅｃｅｎｔ）順序付けし、すべての結合について規則をファイアすることがある。

ＰＭ＿Ａｔｔｒｉｂが複数の選択肢を指定した場合には、その選択肢は、
options=“mostrecent,singlefire”
などにより、コンマ区切りされることがある。
その選択肢はまた、任意の順序で指定されることがある。

ＰａｔｔｅｒｎＭａｔｃｈｉｎｇ＿Ｅｌｅｍｅｎｔは、結合変数宣言（ＰＭＢｉｎｄＶａｒｓ）、規則論理（ＰＭＰｒｅｍｉｓｅ＿Ｅｌｅｍｅｎｔ、ＰＭＡｃｔｉｏｎｓ＿Ｅｌｅｍｅｎｔ）、及びオプションの分類指定（ＰＭＯｒｄｅｒＢｙ＿Ｅｌｅｍｅｎｔ）のための、３つの部分要素を含むことがある。

ルールベース１１４のサンプルからのパターン合致規則のインフィックスコードの例は、以下のようであり得る。
<rule name=“Itemize_persons_without_any_siblings”>
<![CDATA[
for
any person p
if
//person never had any siblings
p.IsSiblingOf.@fld_isunknown()
//person currently has no siblings
or p.IsSiblingOf=set()
then
var msg is string=“No sibling for:” & p.@inst_getname()
@engn_tracemsg(msg)
end
//Sortitems in ascending sequence by age;
//Forequal ages,sort by recency(most-recent first)
optionsmostrecent
orderbyp.getage()
]]>
</rule>

この規則は、Ｐｅｒｓｏｎのすべてのインスタンス全体に動作し、兄弟のいない者を項目別に掲げる。その結果は、年齢によって順序付けられる。年齢が同じ場合には、より最近の結合が、より古い結合に先行する。

パターン合致規則は、より動的であり、他の規則で実施されるインスタンス作成、修正、及び消去に自動的に反応することがある。たとえば、ひとりでにフィードオフし、これによりすべての兄弟関係を計算する１つの規則は、以下のようであり得る。
<rulename=“Make_sibling_if_there_are_shared_siblings”>
<![CDATA[
for
any person p1,
any person p2
if
//different persons
p1<>p2
//persons not already siblings
and not p1.IsSiblingOf@set_doesincludeval(p2)
//persons share siblings
and pl.IsSiblingOf.@set_doesintersect(p2.IsSiblingOf)
then
//make persons siblings
p1.IsSiblingOf.@set_addval(p2)
end
]]>
</rule>

動的識別子経路がナル値を含む場合は、推論エンジン１１２は、決定木規則について上述したアクションと同じアクションを実施することがある。

１０．２．１ＰＭＢｉｎｄＶａｒｓ構文
この構文は、パターン合致規則のための結合変数を宣言し、以下のフォーマットを有する。
PMBindVars
::=PMBindVarDcl_Element
::=PMBindVarList_Element
PMBindVarDcl_Element
::=(‘bindvar_dcl’PMBindVarDcl_Attribs+)
IdentifierSpec //bindvar class
PMBindVarDcl_Attribs
::=Name_Attrib //Required
::=LocTag_Attrib //Optional
PMBindVarList_Element
::=(‘bindlist’[LocTag_Attrib])
PMBindVarDcl_Element*

この構文は、１つ以上の結合変数を宣言することができる。それぞれの宣言が、（ＰＭＢｉｎｄＶａｒＤｃｌ＿ＡｔｔｒｉｂｓＮａｍｅ＿Ａｔｔｒｉｂとしての）変数名、及びクラス名を指定する。異なる結合変数が、同じ又は異なるクラスに関連付けられることがある。インフィックスコード宣言、
any person p,
any duck d
について、生成された規則定義言語コードは、以下のようであり得る。
<bindlist>
<bindvar_dclname=“p”loc_tag=“Line#2”>
<Identifiername=“person”/>
</bindvar_dcl>
<bindvar_dclname=“d”loc_tag=“Line#3”>
<identifiername=“duck”/>
</bindvar_dcl>
</bindlist>

上述したように、ｌｏｃ＿ｔａｇフィールドとは、推論エンジン１１２が誤り及びトレースメッセージを含むことがあるフィールドである。推論演算を実施する場合には、推論エンジン１１２により、ｌｏｃ＿ｔａｇフィールドを処理する必要はない。その上、低位要素がｌｏｃ＿ｔａｇ値をオーバーライドしない場合は、ｌｏｃ＿ｔａｇフィールドを規則定義言語内の階層上の低位要素に適用することができる。その結果、ｌｏｃ＿ｔａｇフィールドを使用して、原始入力行番号をＸＭＬ要素に付加することができる。

１０．２．２ＰＭＰｒｅｍｉｓｅ＿Ｅｌｅｍｅｎｔ
この要素は、以下のように、規則の前提を定義する。
PMPremise_Element
::=(‘pm-premise’[LocTag_Attrib])
GeneralExpr

ＧｅｎｅｒａｌＥｘｐｒは、この規則について宣言された結合変数のすべてを参照するブール式であり得る。そうでない場合は、サーバ１０２は、シンタックス誤りと共に規則を拒絶することがある。

１０．２．３ＰＭＡｃｔｉｏｎｓ＿Ｅｌｅｍｅｎｔ
この要素は、以下のように、規則のアクションを定義する。
PMActions_Element
::=(‘pm_actions’[LocTag_Attrib])
Statement*

規則のアクションは、結合変数を介していくつかのフィールド値を参照することがあるが、サーバ１０２は、このような参照を主張しないことがある。

１０．２．４ＰＭＯｒｄｅｒｅｄＢｙ＿Ｅｌｅｍｅｎｔ
この要素は、インスタンス結合を分類するための基準を指定し、以下のフォーマットを有する。
PMOrderBy_Element
::=(‘orderby’[LocTag_Attrib])
GeneralExpr* //Number or String

この要素は、ゼロ以上の数字又は文字列式を分類基準として指定する。推論エンジン１１２は、まず、第１の式により結合を分類し、次いで、第２の式により合致結合を分類し、以下同様に分類することがある。これらの比較結合がすべて合致する場合は、推論エンジン１１２は、ｍｏｓｔｒｅｃｅｎｔ選択肢により順序付けを解決することがある。分類は、昇順、降順、又は他の好適な順序で行われることがある。数字式について降順が望ましい場合は、ユーザは、
orderby-p.getage()
などにより、その式を否定することができる。

１０．２．５その他の考慮事項
一実施形態においては、推論エンジン１１２は、パターン合致規則を前向き連鎖することはできるが、後ろ向き連鎖することはできない。この実施形態においては、推論エンジン１１２は、後ろ向き連鎖中に、パターン合致規則を無視することができる。パターン合致規則はまた、静的及び動的インスタンスの両方又はこれら２つのタイプの混合を扱うことができる。規則は、静的インスタンスを自由に修正でき、動的インスタンスを自由に作成し、修正し、消去できる。パターン合致インスタンス結合を計算する場合には、推論エンジン１１２は、ｉｎｓｔ＿ｔｅｍｐｌａｔｅ固有のインスタンスを無視することができる。結合変数は、オブジェクトのスーパークラスに関連付けられ得る。たとえば、ユーザは、Ｂｉｒｄ結合変数を指定し、推論エンジン１１２は、Ｄｕｃｋ、Ｒｏｂｉｎ、及びＨａｗｋのインスタンスに対して、多様な形でパターン合致することができる。

１１ステートメント構文
この構文は、論理ステートメントのための規則定義言語の要素を定義し、以下のフォーマットを有する。
Statement
::=VarDclStmt_Element
::=AssignmentStmt_Element
::=MethodCall_Element
::=ReturnStmt_Element

１１．１ＶａｒＤｃｌＳｔｍｔ＿Ｅｌｅｍｅｎｔ
Ｓｔａｔｅｍｅｎｔのこの要素は、局所変数を宣言し、以下のフォーマットを有する。
VarDclStmt_Element
::=(‘var_dcl’VarDcl_Attribs+)
DataType_Element
GeneralExpr //initialization Value
VarDcl_Attribs
::=Name_Attrib //Required
::=LocTag_Attrib //Optional

このステートメントは、規則及び方法論理の両方によって指定され得る。このステートメントは、その論理内のどこにでも位置することができるが、その位置が、その範囲の可視性に影響を及ぼす場合がある。局所変数は、セット及び関連付けインスタンスを含む、任意のデータ型であり得る。ステートメントは、局所変数のための初期設定値を指定することがある。ＧｅｎｅｒａｌＥｘｐｒは、タイプ互換性を有する初期設定値を定義する。その式は、定数式である必要はない。

ルールベース１１４のサンプルからのインフィックスコードの例は、以下のようであり得る。
var result isboolean=true //be optimistic
かつ、対応する規則定義言語コードは、以下のようであり得る。
<var_dclname=“result”loc_tag=“Line#2”>
<datatypecoll_type=“none”type=“Boolean”/>
<literal_constantvalue=“true”/>
<var_dcl>

１１．２ＡｓｓｉｇｎｍｅｎｔＳｔｍｔ＿Ｅｌｅｍｅｎｔ
Ｓｔａｔｅｍｅｎｔのこの要素は、割当てステートメントを定義し、以下のフォーマットを有する。
AssignmentStmt_Element
::=(‘assign_stmt’[LocTag_Attrib])
IdentifierSpec //Destination(Field)
GeneraIExpr //Source

この要素は、規則及び方法論理の両方によって指定され得る。推論エンジン１１２は、ＧｅｎｅｒａｌＥｘｐｒを評価し、その値をタイプ互換性を有する指定された宛先オブジェクトに割り当てる。宛先オブジェクトは、フィールド又は局所変数であり得る。フィールドである場合は、推論エンジン１１２は、割当てを完了する前に、まず制約検査を起動することがある。

オペランドが数字のタイプである場合には、推論エンジン１１２は、オペランドの精度を比較する。ＧｅｎｅｒａｌＥｘｐｒの精度が宛先オブジェクトの精度より低いと、推論エンジン１１２は、宛先の精度に合致するよう、ＧｅｎｅｒａｌＥｘｐｒ値をゼロ展開し、次いで、割当てを実施することがある。そうでない場合は、推論エンジン１１２は、宛先の精度に合致するよう、必要に応じてＧｅｎｅｒａｌＥｘｐｒ値を丸める。

ルールベース１１４のサンプルからのインフィックスコードの例は、以下のようであり得る。
Fact1=true
かつ、対応する規則定義言語コードは、以下のようであり得る。
<assign_stmtloc_tag=“Line#3”>
<identifiername=“Fact1”/>
<literal_constantvalue=“true”/>
</assign_stmt>

１１．３ＭｅｔｈｏｄＣａｌｌ＿Ｅｌｅｍｅｎｔ
Ｓｔａｔｅｍｅｎｔのこの要素は、方法起動ステートメントを定義し、以下のフォーマットを有する。
MethodCall_Element
::=(‘method_call’[LocTag_Attrib])
IdentifierSpec //Method
[MethodArgList_Element]
MethodArgList_Element
::=(‘arg_list’[LocTag_Attrib])
GeneralExpr*

この要素は、規則及び方法論理の両方によって指定され得る。推論エンジン１１２は、任意の指定された引き数で、指定された方法を起動することができる。この要素は、独立ステートメントとして、かつ（起動された方法が値を返す場合は）式中の項として適用されることがある。起動には、ゼロ以上の引き数式を必要とすることがある。引き数の数は、ターゲット方法が期待するパラメータの数と同一であり、それぞれの引き数は、それに対応する方法パラメータとタイプ互換性を有することがある。方法パラメータが出力パラメータである場合は、引き数は、フィールド又は局所変数のいずれかのための識別子であり得る。

引き数及びパラメータが数字のタイプである場合には、推論エンジン１１２は、それらの精度を比較する。ソースオブジェクト（入力パラメータのための引き数、出力パラメータのためのパラメータ）の精度が、宛先オブジェクト（入力パラメータのためのパラメータ、出力パラメータのための引き数）の精度より低い場合は、推論エンジン１１２は、宛先の精度に合致するよう、ソース値をゼロ展開し、次いで、その値を渡す。そうでない場合は、推論エンジン１１２は、宛先の精度に合致するよう、必要に応じてソース値を丸める。同様の考慮事項が、数字のタイプの、方法の戻り値に適用されることがある。推論エンジン１１２は、宛先オブジェクトに割り当てる前に、戻り値を調整するか又は丸めることがある。

ルールベース１１４のサンプル内のパターン合致規則からのインフィックスコードの例は、以下のようであり得る。
//associateperson and duck
p.AssignDuck(d)
かつ、対応する規則定義言語コードは、以下のようであり得る。
<methood_callloc_tag=“Line#13”>
<identifier_path>
<identifiername=“p”/>
<identifiername=“AssignDuck”/>
</identifier_path>
<arg_list>
<identifiername=“d”/>
</arg_list>
</method_call>

１１．４ＲｅｔｕｒｎＳｔｍｔ＿Ｅｌｅｍｅｎｔ
この要素は、方法の引き取り命令を定義し、以下のフォーマットを有する。
ReturnStmt_Element
::=(‘return_stmt’[LocTag_Attrib])
[GeneralExpr]

一実施形態においては、この引き取り命令は、方法論理によってのみ指定することができ、規則論理によっては指定することができない。規則論理内で指定されると、サーバ１０２は、シンタックス誤りと共にその引き取り命令を拒絶することができる。この引き取り命令を実行する場合には、推論エンジン１１２は、方法の実行を終了し、その方法を起動したコードに制御を返すことができる。引き取り命令がＧｅｎｅｒａｌＥｘｐｒを指定した場合は、値を返す時に現在の方法を定義することができ、宣言された戻りデータ型は、その引き取り命令のＧｅｎｅｒａｌＥｘｐｒとタイプ互換性を有し得る。ＭｅｔｈｏｄＣａｌｌ＿Ｅｌｅｍｅｎｔについて記述したように、推論エンジン１１２は、数字のタイプの戻り値を調整するか又は丸めることがある。

ルールベース１１４のサンプルからのインフィックスコードの例は、以下のようであり得る。
returnSymptoms.@Set_DoesIncludeVal(sympl)
andnot Symptoms.@Set_DoesIncludeVal(symp2)
かつ、対応する規則定義言語コードは、以下のようであり得る。
return_stmtloc_tag=“Line#l”>
<and_oploc_tag=“Line#2”>
<method_call>
<identifier intrinsic=“true”name=“set_doesincludeval”/>
<arg_list>
<identifier name=“Symptoms”/>
<identifier name=“symp1”/>
</arg_list>
</method_call>
<not_op>
<method_call>
<identifier intrinsic=“true”name=“set_doesincludeval”/>
<arg_list>
<identifier name=“Symptoms”/>
<identifier name=“symp2”/>
</arg_list>
</method_call>
</not_op>
</and_op>
</return_stmt>

１２ＧｅｎｅｒａｌＥｘｐｒ構文
ＧｅｎｅｒａｌＥｘｐｒ構文は、規則定義言語論理から参照される時に、式を定義し、以下のフォーマット有する。
GeneralExpr
::=SimpleTerm
::=RelationalTerm
//UnaryOperators
::=UnaryPlusExpr_Element
::=UnaryMinusExpr_Element
::=UnaryNotExpr_Element
//BinaryOperators
::=ORed_Element
::=ANDed_Element
::=Addition_Element
::=Subtraction_Element
::=Concatenation_Element
::=Multiplication_Element
::=Division_Element

ＧｅｎｅｒａｌＥｘｐｒは、予想されるセットの項及び演算子をサポートする。前述したように、式の評価によって副作用が生成されることはない。したがって、式によって起動される方法は、副作用を生成しない。機能方法と呼ばれるこれらの方法は、さらに、上記のＣｌａｓｓＭｅｔｈｏｄＤｅｆ＿Ｅｌｅｍｅｎｔセクションにおいて記述されている。

一実施形態においては、文法は、データ型に互換性のある演算を互換性のない演算から区別しようとはしない。たとえば、文法は、文字列値からブール値を減算できることを提案することができる。この実施形態においては、タイプ互換性の強制実施がサーバ１０２によって実施され、これにより、タイプ検査及び定数の畳み込みの両方が実施される。

大部分のタイプの項及び演算子のサンプリンングを含むよう管理するインフィックスコードステートメントのサンプルは、以下のようであり得る。
var IsHappyis Boolean=
IsWealthy
or(
age>0..<=200
and notIsTooTall
and QualityIndex(
(income+savings-debts)/12,
firstname &““& lastname,
some_random_number)
>+l00
)
このステートメントについて対応する規則定義言語コードは、以下のようであり得る。
<var_dclloc_tag=“Line#l”name=“IsHappy”>
<datatypecoll_type=“none”type=“Boolean”/>
<or_oploc_tag=“Line#3”>
<identifiername=“IsWealthy”/>
<and_oploc_tag=“Line#6”>
<and_op loc_tag=“Line#5”>
<range_op>
<identifier name=“age”/>
<part_gt_op>
<literal_constant value=“0”/>
</part_gt_op>
<part_1teq_op>
<literal_constant value=“2OO”/>
</part_1teq_op>
</range_op>
<not_op>
<identifier name=“IsTooTall”/>
</not_op>
</and_op>
<gt_op>
<method_call>
<identifier name=“QualityIndex”/>
<arg_list>
<div_op>
<subt_op>
<add_op>
<identifier name=“income”/>
<identifier name=“savings”/>
</add_op>
<identifier name=“debts”/>
</subt_op>
<literal_constant value=“12”/>
</div_op>
<concat_op>
<concat_op>
<identifier name=“firstname”/>
<literal_constant value=“"" ”/>
</concat_op>
<identifier name=“lastname”/>
</concat_op>
<identifier name=“some_random_number”/>
</arg_list>
</method_call>
<uplus_op>
<literal_constant value=“lOO”/>
</uplus_op>
</gt_op>
</and_op>
</or_op>
</vardcl>

１２．１ＳｉｍｐｌｅＴｅｒｍ構文
ＧｅｎｅｒａｌＥｘｐｒのＳｉｍｐｌｅＴｅｒｍは、以下のフォーマットを有することができる。
SimpleTerm
::=LiteralConstant_Element
::=SetConstant_Element
::=IdentifierSpec //Object name
::=MethodCall_Element

ここでは、ＬｉｔｅｒａｌＣｏｎｓｔａｎｔ＿Ｅｌｅｍｅｎｔ及びＳｅｔＣｏｎｓｔａｎｔ＿Ｅｌｅｍｅｎｔについて記述する。ＩｄｅｎｄｆｉｅｒＳｐｅｃについては、本明細書の後に記述する。ＭｅｔｈｏｄＣａｌｌ＿Ｅｌｅｍｅｎｔについては、上述した。

１２．１．１ＬｉｔｅｒａｌＣｏｎｓｔａｎｔ＿Ｅｌｅｍｅｎｔ
ＬｉｔｅｒａｌＣｏｎｓｔａｎｔ＿Ｅｌｅｍｅｎｔは、以下のフォーマットを有する。
LiteralConstant_Element
::=(‘literal_constant’LiteralConstant_Attribs+)
LiteralConstant_Attribs
::=Value_Attrib //Required
::=LocTag_Attrib //Optional

Ｖａ１ｕｅ＿Ａｔｔｒｉｂは、文字列用文字としての定数値を示す。サーバ１０２は、その定数のデータ型を判断するために、（大文字と小文字とを区別せずに）この値を調べることがある。その値が「真」又は「偽」であれば、サーバ１０２は、その定数をブール定数と認識する。その値が「ナル」であれば、サーバ１０２は、その定数を（関連付けインスタンスの欠如を示す）関連付けインスタンス定数と認識する。その値の最初の文字が二重引用文字であれば、サーバ１０２は、その定数を文字列定数と認識し、その値の最後の文字も二重引用文字であることを検証する。そうでない場合は、サーバ１０２は、その定数が数字定数であると想定し、しかるべくそれを解析する。推論エンジン１１２は、小数点以下の桁数を調べることにより、その定数の精度を判断する。その定数が指数表現で表されている場合は、その精度に、その指数値も考慮に入れられる。

リテラル定数のインフィックスコードの例は、以下のようであり得る。
methodl(false,null,“abc”‘‘‘‘,123.456)
かつ、対応する規則定義言語コードは、以下のようであり得る。
<method_callloc_tag=“Line#l”>
<identifiername=“methodl”/>
<arg_list>
<literal_constantvalue=“false”/>
<literal_constantvalue=“null”/>
<literal_constantvalue=“"abc"”/>
<literal_constantvalue=“""”/>
<literal_constantvalue=“123.456”/>
</arg_list>
</methodcal1>

１２．１．２ＳｅｔＣｏｎｓｔａｎｔ＿Ｅｌｅｍｅｎｔ
ＳｅｔＣｏｎｓｔａｎｔ＿Ｅｌｅｍｅｎｔは、以下のフォーマットを有する。
SetConstant_Element
::=(‘set_constant’[LocTag_Atttib])
SetMember*
SetMember
::=LiteralConstant_Element
::=IdentifierSpec //Instance name
::=UnaryExpr //with LiteralConstant_Element only
１セットは、ゼロ以上のメンバーを包含する。一実施形態においては、１セットのすべてのメンバーは、同じデータ型であるべきである。そのメンバーのデータ型（あれば）は、セット定数のデータ型である。メンバーは、リテラル定数、（関連付けインスタンスのセットのための）ＩｄｅｎｔｉｆｉｅｒＳｐｅｃ、又はリテラル定数の単項演算子であり得る。リテラル定数の単項演算子の場合には、リテラル定数は、数字又はブール定数のいずれかであり得る。数字のセット定数については、セット自体は精度を有さないが、そのメンバーは精度を有する。同様に、インスタンスのセット定数は、どのような特定の関連付けにも拘束されないことがある。

セット定数のインフィックスコードの例は、以下のようであり得る。
setl=set(l23)
set2=set(“abc”,“def”)
set3=set(duckl,duck2)
set4=set(-123,0)
set5=set() //Empty set
かつ、対応する規則定義言語コードは、以下のようであり得る。
<assign_stmtloc_tag=“Line#1”>
<identifiername=“setl”/>
<set_constant>
<literal_constantvalue=“123”/>
</set_constant>
</assign_stmt>
<assign_stmtloc_tag=“Line#2”>
<identifiername=“set2”/>
<set_constant>
<literal_constantvalue=“"abc" ”/>
<literal_constantvalue=“"def" ”/>
<set_constant>
</assign_stmt>
<assign_stmtloc_tag=“Line#3”>
<identiifier name=“set3”/>
<set_constant>
<identifiername=“duckl”/>
<identifiername=“duck2”/>
</set_constant>
</assign_stmt>
<assign_stmtloc_tag=“Line#4”>
<identifiername=“set4”/>
<set_constant>
<uminus_op>
<literal_constant value=“123”/>
</uminus_op>
<literal_constantvalue=“0”/>
</set_constant>
</assign_stmt>
<assign_stmtloc_tag=“Line#5”>
<identifier name=“set5”/>
<set_constant/>
</assign_stmt>

１２．２ＲｅｌａｔｉｏｎａｌＴｅｒｍ構文
ＲｅｌａｔｉｏｎａｌＴｅｒｍは、値の比較を定義し、以下のフォーマットを有する。
RelationalTerm
::=FullComp_EQ_Element
::=FullComp_NE_Element
::=FullComp_LT_Element
::=FullComp_LTEQ_Element
::=FullComp_GT_Element
::=FullComp_GTEQ_Element
::=FullComp_Range_Element
値の比較は、上述した全比較及び部分比較を含むことができる。

１２．２．１全比較構文
全比較は、ある範囲の値を必要とする、２項演算子又は３項演算子を含むことがある。２項演算子の例は、以下のようであり得る。
IsLessThan=fldl<123
３項演算子の例は、以下のようであり得る。
IsInRange=fld1>=100..<200
//above statementis semantically equivalent to following statement
//(but ismore efficient):
IsInRange=fld1>=100and fld1<200
いずれの場合においても、式は、比較結果を示すブール値を返す。

上記の３つのインフィックスステートメントに対応する規則定義言語コードは、以下のようであり得る。
<assign_stmtloc_tag=“Line#1”>
<identifiername=“IsLessThan”/>
<It_op>
<identifiername=“fldl”/>
<literal_constantvalue=“l23”/>
</It_op>
</assign_stmt>
<assign_stmtloc_tag=“Line#2”>
<identifiername=“IsInRange”/>
<range_op>
<identifiername=“fldl”/>
<part_gteq_op>
<literal_constant value=“lOO”/>
</part_gteq_op>
<part_It_op>
<literal_constant value=“2OO”/>
</part_It_op>
</range_op>
</assign_stmt>
<assign_stmtloc_tag=“Line#5”>
<identifiername“IsInRange”/>
<and_oploc_tag=“Line#5">
<gteq_op>
<identifier name=“fld1”/>
<literal_constant value=“1OO”/>
</gteq_op>
<lt_op>
<identifier name=“fld1”/>
<literal_constant value=“2OO”/>
</lt_op>
</andop>
</assignstmt>
全比較要素は、以下のフォーマットを有することができる。
FullComp_EQ_Element //GeneralExpr=GeneralExpr
::=(‘eq_op’Comp_Attribs*)
GeneralExpr
GeneralExpr
FullComp_NE_Element //GeneralExpr<>GeneralExpr
::=(‘neq_op’Comp_Attribs*)
GeneralExpr
GeneralExpr
FullComp_LT_Element //GeneralExpr<GeneralExpr
::=(‘It_op’Comp_Attribs*)
GeneralExpr
GeneralExpr
FullComp_LTEQ_Element //GeneralExpr<=GeneralExpr
::=(‘lteq_op’Comp_Attribs*)
GeneralExpr
GeneralExpr
FullComp_GT_Element //GeneralExpr>GeneralExpr
::=(‘gt_op’Comp_Attribs*)
GeneralExpr
GeneralExpr
FullComp_GTEQ_Element //GeneralExpr>=GeneralExpr
::=(‘gteq_op’Comp_Attribs*)
GeneralExpr
GeneralExpr
FullComp_Range_Element
//GeneralExpr in range:(GeneralExpr1..GeneralExpr2)
::=(‘range_op’[LocTag_Attrib])
GeneralExpr
RangeStartComp
RangeStopComp
RangeStartComp
::=PartComp_GT_Element
::=PartComp_GTEQ_Element
RangeStopComp
::=PartComp_LT_Element
::=PartComp_LTEQ_Element

これらの要素のすべてについて、ＧｅｎｅｒａｌＥｘｐｒはすべて、同じデータ型であり得る。しかし、演算子の中には、あるデータ型のみをサポートするものがある。たとえば、相等性及び不等性の比較は、すべてのデータ型及び値のセットをサポートする。不等なセットは共通する場合もしない場合もある。絶対値の比較は、数字及び文字列式のみをサポートすることができるが、セットにも適用され得る。セットについては、その結果がサブセットの関係を示す。数字値を比較する場合には、推論エンジン１１２は、まず、精度の低いオペランドを他のオペランドの精度にゼロ展開し、次いで、比較を実施する。

要素のすべてについて、以下のフォーマットで、Ｃｏｍｐ＿Ａｔｔｒｉｂｓを指定することができる。
Comp_Attribs
::=CaseSensitivity_Attrib //Optional
::=LocTag_Attrib //Optional
ＣａｓｅＳｅｎｓｉｔｉｖｉｔｙ＿Ａｔｔｒｉｂを指定して、大文字と小文字とを区別する文字列比較を示すことができる。デフォルトにより、文字列の比較は、大文字と小文字とを区別する場合もしない場合もあり得る。他のデータ型の比較については、このような設定は無視され得る。

１２．２．２部分比較構文
範囲の比較は、部分比較構文、又は全比較の「右辺」のみを指定する構文に依拠する。部分比較構文は、以下のフォーマットを有する。
PartComp_EQ_Element //=GeneralExpr
::=(‘part_eq_op’Comp_Attribs*)
GeneralExpr
PartComp_NE_Element //<>GeneralExpr
::=(‘part_neq_op’Comp_Attribs*)
GeneralExpr
PartComp_LT_Element //<GeneralExpr
::=(‘part_It_op’Comp_Attribs*)
GeneralExpr
PartComp_LTEQ_Element //<=GeneralExpr
::=(‘part_lteq_op’Comp_Attribs*)
GeneralExpr
PartComp_GT_Element //>GeneralExpr
::=(‘part_gt_op’Comp_Attribs*)
GeneralExpr
PartComp_GTEQ_Element //>=GeneralExpr
::=(‘part_gteq_op’Comp_Attribs*)
GeneralExpr
PartComp_Range_Element
//inrange:(GeneralExprl..GeneralExpr2)
::=(‘part_range_op’[LocTag_Attrib])
RangeStartComp
RangeStopComp
決定木要素によっても使用され得るこれらの構文は、１つのＧｅｎｅｒａｌＥｘｐｒ（又は範囲については２つ）を指定する。全比較については、同じデータ型及び大文字と小文字の区別についての考慮事項がそれらに適用される。

１２．３単項演算子要素
ＧｅｎｅｒａｌＥｘｐｒの単項演算子は、ＵｎａｒｙＰｌｕｓＥｘｐｒ＿Ｅｌｅｍｅｎｔ、ＵｎａｒｙＭｉｎｕｓＥｘｐｒ＿Ｅｌｅｍｅｎｔ、及びＵｎａｒｙＮｏｔＥｘｐｒ＿Ｅｌｅｍｅｎｔを含む。

１２．３．１ＵｎａｒｙＰｌｕｓＥｘｐｒ＿Ｅｌｅｍｅｎｔ
ＧｅｎｅｒａｌＥｘｐｒのＵｎａｒｙＰｌｕｓＥｘｐｒ＿Ｅｌｅｍｅｎｔは、以下のフォーマットを有する。
UnaryPlusExpr_Element
::=(‘uplus_op’[LocTag_Attrib])
GenaralExpr
この演算は、基本的に、ＧｅｎｅｒａｌＥｘｐｒの値を返す。これは、
if this_value>=-100..<=+100then...end
などにより、「表記可能に」するために含まれるものである。
ＧｅｎｅｒａｌＥｘｐｒは、数字式であり得、この演算は数字値を返す。

１２．３．２ＵｎａｒｙＭｉｎｕｓＥｘｐｒ＿Ｅｌｅｍｅｎｔ
ＵｎａｒｙＭｉｎｕｓＥｘｐｒ＿Ｅｌｅｍｅｎｔは、以下のフォーマットを有する。
UnaryMinusExpr_Element
::=(‘uminus_op’[LocTag_Attrib])
GeneralExpr
この演算は、ＧｅｎｅｒａｌＥｘｐｒ値の算術符号を逆にする。正値は負値となり、負値は正値となる。ＧｅｎｅｒａｌＥｘｐｒは数字式であり得、この演算は数字値を返す。

１２．３．３ＵｎａｒｙＮｏｔＥｘｐｒ＿Ｅｌｅｍｅｎｔ
ＵｎａｒｙＮｏｔＥｘｐｒ＿Ｅｌｅｍｅｎｔは、以下のフォーマットを有する。
UnaryNotExpr_Element
::=(‘not_op’[LocTag_Attrib])
GeneralExpr

この演算は、ＧｅｎｅｒａｌＥｘｐｒのブールの値を逆にする。真値は偽となり、偽値は真となる。ＧｅｎｅｒａｌＥｘｐｒはブール式であり得、この演算はブール値を返す。

１２．４２項演算子要素
２項演算子は、ＯＲｅｄ＿Ｅｌｅｍｅｎｔ、ＡＮＤｅｄ＿Ｅｌｅｍｅｎｔ、Ａｄｄｉｔｉｏｎ＿Ｅｌｅｍｅｎｔ、Ｓｕｂｔｒａｃｔｉｏｎ＿Ｅｌｅｍｅｎｔ、Ｃｏｎｃａｔｅｎａｔｉｏｎ＿Ｅｌｅｍｅｎｔ、Ｍｕｌｔｉｐｌｉｃａｔｉｏｎ＿Ｅｌｅｍｅｎｔ、及びＤｉｖｉｓｉｏｎ＿Ｅｌｅｍｅｎｔを含む。

１２．４．１ＯＲｅｄ＿Ｅｌｅｍｅｎｔ
ＯＲｅｄ＿Ｅｌｅｍｅｎｔは、ＯＲ演算をサポートし、以下のフォーマットを有する。
ORed_Element
::=(‘or_op’[LocTag_Attrib])
GeneralExpr
GeneralExpr
この演算は、部分要素に論理ＯＲ演算を実施する。その結果は、いずれかの部分要素が真であれば真である。そうでない場合は、その結果は偽である。ＧｅｎｅｒａｌＥｘｐｒは両方ともブール式であり得、この演算はブール値を返す。

実行時間に、推論エンジン１１２が、ＧｅｎｅｒａｌＥｘｐｒの１つのみを評価することがある。たとえば、インフィックスコード式、
fldl<100 orfld2>=200
について、ｆｌｄ１が５０の値を有する場合は、推論エンジン１１２は、最終結果が真であることが分かっているので、ｆｌｄ２を試験する必要はない。しかし、ｆｌｄ１が分かっていない場合は、推論エンジン１１２はｆｌｄ２を試験することがあり、従って、推論エンジン１１２は、ｆｌｄ２が２５０などの十分に大きな値を有する場合は、規則を保留することを回避することができる。同様に、推論エンジン１１２はまた、中間インスタンス参照フィールドを有する識別子経路のいずれかが、ナル値を有するかどうかを判断することができる。たとえば、インフィックスコード式、
Father.pDog.age<5or Child.pFriend.age>10
について、Ｆａｔｈｅｒが、犬を飼っていないことがある（ｐＤｏｇ＝ナル）。しかし、推論エンジン１１２は、Ｃｈｉｌｄの友人が十分な年であれば、その式を真と評価することがある。

ＯＲｅｄ＿Ｅｌｅｍｅｎｔが２進演算子として記述されているが、任意の数のオペランドを収容することもできる。たとえば、ＯＲｅｄ＿Ｅｌｅｍｅｎｔは、１つ以上のオペランドの「リスト」を取り扱うことができる。ＯＲｅｄ＿Ｅｌｅｍｅｎｔ内の１つ以上のオペランドにより、規則が保留された場合は、推論エンジン１１２は、以前に保留されたオペランド（及びこれらのオペランドのみ）で推論を再始動することができる。

１２．４．２ＡＮＤｅｄ＿Ｅｌｅｍｅｎｔ
ＡＮＤｅｄ＿Ｅｌｅｍｅｎｔは、ＡＮＤ演算をサポートし、以下のフォーマットを有する。
ANDed_Element
::=(‘and_op’[LocTag_Attrib])
GeaeralExpr
GeneralExpr
この演算は、部分要素に論理ＡＮＤ演算を実施する。両方の部分要素が真であれば、その結果は真である。そうでない場合は、その結果は偽である。ＧｅｎｅｒａｌＥｘｐｒｓは、両方ともブール式であり得、この演算はブール値を返す。実行時間に、推論エンジン１１２は、ＧｅｎｅｒａｌＥｘｐｒの１つのみを評価することがある。たとえば、インフィックスコード式、
fld1>=100and fld2<200
について、ｆｌｄ１が５０の値を有する場合は、その最終結果が偽であることが分かっている場合は、推論エンジン１１２は、ｆｌｄ２を試験する必要はない。しかし、ｆｌｄ１が分かっていない場合は、推論エンジン１１２はｆｌｄ２を試験することがあり、従って、推論エンジン１１２は、ｆｌｄ２が２５０などの十分に大きな値を有する場合は、規則を保留することを回避することができる。同様に、推論エンジン１１２はまた、中間インスタンス参照フィールドを有する識別子経路のいずれかがナル値を有するかどうかを判断することができる。たとえば、インフィックスコード式、
Father.pDog.age<5and Child.pFriend.age>10
について、Ｆａｔｈｅｒが犬を飼っていないことがある（ｐＤｏｇ＝ナル）。しかし、推論エンジン１１２は、Ｃｈｉｌｄの友人が十分な年でない場合は、式を偽であると評価することがある。

ＡＮＤｅｄ＿Ｅｌｅｍｅｎｔが２進演算子として記述されているが、任意の数のオペランドを収容することもできる。たとえば、ＡＮＤｅｄ＿Ｅｌｅｍｅｎｔは、１つ以上のオペランドの「リスト」を取り扱うことができる。ＡＮＤｅｄ＿Ｅｌｅｍｅｎｔ内の１つ以上のオペランドにより、規則が保留された場合は、推論エンジン１１２は、以前に保留されたオペランド（及びこれらのオペランドのみ）で推論を再始動することができる。

１２．４．３Ａｄｄｉｔｉｏｎ＿Ｅｌｅｍｅｎｔ
Ａｄｄｉｔｉｏｎ＿Ｅｌｅｍｅｎｔは加算演算をサポートし、以下のフォーマットを有する。
Addition_Element
::=(‘add_op’[LocTag_Attrib])
GeneralExpr
GeaeralExpr
この演算は、部分要素の算術加算を実施する。その演算は、第２の部分要素を第１の部分要素に追加した結果を返す。ＧｅｎｅｒａｌＥｘｐｒｓは、両方とも数字式であり得、この演算は数字値を返す。オブジェクトを追加する場合には、算術演算の前に、精度の低いオブジェクトを他のオブジェクトの精度にゼロ展開することがある。その結果は、より高い精度を反映することがある。

１２．４．４Ｓｕｂｔｒａｃｔｉｏｎ＿Ｅｌｅｍｅｎｔ
Ｓｕｂｔｒａｃｔｉｏｎ＿Ｅｌｅｍｅｎｔは、加算演算をサポートし、以下のフォーマットを有する。
Subtraction_Element
::=(‘subt_op’[LocTag_Attrib])
GeneralExpr
GeneralExpr
この演算は、部分要素の算術減算を実施する。この演算は、第１の部分要素から第２の部分要素を減算した結果を返す。ＧｅｎｅｒａｌＥｘｐｒｓは、両方とも数字式であり得、この演算は数字値を返す。オブジェクトを減算する場合には、算術演算の前に、精度の低いオブジェクトを他のオブジェクトの精度にゼロ展開することがある。その結果は、より高い精度を反映することがある。

１２．４．５Ｃｏｎｃａｔｅｎａｔｉｏｎ＿Ｅｌｅｍｅｎｔ
Ｃｏｎｃａｔｅｎａｔｉｏｎ＿Ｅｌｅｍｅｎｔは、連結演算をサポートし、以下のフォーマットを有する。
Concatenation_Element
::=(‘concat_op’[LocTag_Attrib])
GeneralExpr
GeneralExpr
この演算は、ある文字列値を別の文字列値にアペンドする。この演算は、第２の部分要素を第１の部分要素にアペンドした結果を返す。ＧｅｎｅｒａｌＥｘｐｒｓは任意のデータ型であり得、いずれかの又は両方の式がセット式であり得る。推論エンジン１１２は、アペンド演算を実施する前に、非文字列式を文字列値に自動的に変換することがある。非文字列値のフォーマット化を制御する選択肢がない場合がある。この演算は文字列値を返す。

１２．４．６Ｍｕｌｔｉｐｌｉｃａｔｉｏｎ＿Ｅｌｅｍｅｎｔ
Ｍｕｌｔｉｐｌｉｃａｔｉｏｎ＿Ｅｌｅｍｅｎｔは、加算演算をサポートし、以下のフォーマットを有する。
Multiplication_Element
::=(‘mult_op’[LocTag_Attrib])
GeneralExpr
GeneralBxpr
この演算は、部分要素に算術乗算を実施する。この演算は、第２の部分要素で第１の部分要素を乗算した結果を返す。ＧｅｎｅｒａｌＥｘｐｒｓは、両方とも数字式であり得、この演算は数字値を返す。オブジェクトを乗算する場合に、精度調整がないことがあり、その積は、オペランド精度の合計である精度を反映することがある。

１２．４．７Ｄｉｖｉｓｉｏｎ＿Ｅｌｅｍｅｎｔ
Ｄｉｖｉｓｉｏｎ＿Ｅｌｅｍｅｎｔは、加算演算をサポートし、以下のフォーマットを有する。
Division_Element
::=(‘div_op’[LocTag_Attrib])
GeneralExpr
GeaeralExpr
この演算は、部分要素の算術除算を実施する。この演算は、第２の部分要素で第１の部分要素を除算した結果を返す。ゼロで除算することにより、誤りと共に推論を終了することができる。ＧｅｎｅｒａｌＥｘｐｒｓは、両方とも数字式であり得、この演算は数字値を返す。オブジェクトを除算する場合に、精度調整がないことがあり、その商は、除算された値の精度を反映し、必要に応じて丸められることがある。

１３Ｄａｔａｔｙｐｅ＿Ｅｌｅｍｅｎｔ
この指定では、Ｄａｔａｔｙｐｅ＿Ｅｌｅｍｅｎｔを頻繁に参照する。Ｄａｔａｔｙｐｅ＿Ｅｌｅｍｅｎｔは、以下のフォーマットを有する。
DataType_Element
::=DataTypeNumber_Element
::=DataTypeBoolean_Element
::=DataTypeString_Element
::=DataTypeInstRef_Element
//.................................................
DataTypeNumber_Element
::=(‘datatype’NumberType_Attribs+)
NumberType_Attribs
::=DataType_Attrib //“number”(Required)
::=Collection_Attrib //Optional
::=Precision_Attrib //Optional
::=LocTag_Attrib //Optional
//.................................................
DataTypeBoolean_Element
::=(‘datatype’BooleanType_Attribs+)
BooleanType_Attribs
::=DataType_Attrib //“boolean”(Required)
::=Collection_Attrib //Optional
::=LocTag_Attrib //Optional
//................................................
DataTypeString_E1ement
::=('datatype'StringType_Attribs+)
StringType_Attribs
::=DataType_Attrib //“string” (Required)
::=Collection_Attrib //Optional
::=LocTag_Attrib //Optional
//................................................
DataTypeInstRef_Element
::=(‘datatype’InstRefType_Attribs+)
IdentifierSpec //Class for instance
InstRefType_Attribs
::=DataType_Attrib //“inst_ref”(Required)
::=Collection_Attrib //Optional
::=LocTag_Attrib //Optional
規則定義言語は、上記に示した、４つの「原子的な」データ型をサポートする。それぞれの原子的なデータ型については、Ｄａｔａｔｙｐｅ＿Ｅｌｅｍｅｎｔの変形形態もあり得る。

ＤａｔａＴｙｐｅ＿Ａｔｔｒｉｂ及びＣｏｌｌｅｃｔｉｏｎ＿Ａｔｔｒｉｂは、すべてのデータ型に共通である。ＤａｔａＴｙｐｅ＿Ａｔｔｒｉｂは、関連データ型を示す。Ｃｏｌｌｅｃｔｉｏｎ＿Ａｔｔｒｉｂは、このデータ型が、セットなどの、値の集合のためのものであるか、又は単純な原子的な値のためのものであるかどうかを示す。

ＤａｔａＴｙｐｅＮｕｍｂｅｒ＿Ｅｌｅｍｅｎｔについて、ユーザは、１０進数の少数で表される「精度」を任意に指定することができる。指定されない場合は、サーバ１０２は、その値がゼロ精度の整数であると想定する。

ＤａｔａＴｙｐｅＡｓｓｏｃＩｎｓｔ＿Ｅｌｅｍｅｎｔについて、ユーザは、２つの部分要素を指定することができる。これらは、それぞれ、データ型の関連付け役割及び関連付け名を識別する。たとえば、Ｐｅｒｓｏｎ及びＤｕｃｋクラスを必要とする所有権関連付けについて、Ｄｕｃｋクラスは、
<fieldname=“IsOwnedBy”>
<datatypecoll_type=“none”type=“assoc_instance”>
<identifiername=“Person”/>
<identifiername=“Ownership”/>
</datatype>
</field>
などにより、Ｏｗｎｅｒｓｈｉｐ関連付け内の役割Ｐｅｒｓｏｎのための関連付けインスタンスとして宣言されるフィールド（ＩｓＯｗｎｅｄＢｙ）を定義することがある。

ＤａｔａＴｙｐｅＩｎｓｔＲｅｆ＿Ｅｌｅｍｅｎｔについて、ユーザは、インスタンス参照に関連付けられたクラスを識別する部分要素を指定する。たとえば、Ｄｕｃｋクラスは、
<fieldname=“IsOwnedBy”>
<datatypecoll_type=“none”type=“inst_ref”>
<identifiername=“Person”/>
</datatype>
</field>
により、Ｐｅｒｓｏｎクラスにインスタンスとして宣言されるＩｓＯｗｎｅｄＢｙフィールドを定義することがある。

１４識別子
一実施形態においては、識別子名は、大文字と小文字とを区別しない場合がある。特定の実施形態においては、規則定義言語は、識別子名が、二重引用文字、ピリオド、コンマ、コロン、（前の又は後ろの）括弧を含むことを認めない。サーバ１０２は、語を保留したり順序付け制限を課すなどの、追加制限を課すことができる。

１４．１ＩｄｅｎｔｉｆｉｅｒＳｐｅｃ−Ｉｄｅｎｔｉｆｉｅｒ＿Ｅｌｅｍｅｎｔ、ＩｄｅｎｔｉｆｉｅｒＰａｔｈ＿Ｅｌｅｍｅｎｔ
ＩｄｅｎｔｉｆｉｅｒＳｐｅｃ要素は、以下のフォーマットを有する。
IdentifierSpec
::=Identifier_Element
::=IdentifierPath_Element
Identifier_Element
::(‘identifier’Identifier_Attribs+)
IdentifierAttribs
::=Name_Attrib //Required
::=Intrinsic_Attrib //Optional
::=LocTag_Attrib //Optional
IdentifierPath_Element
::=(‘identifier_path’[LocTag_Attrib])
Identifier_Element+
識別子指定は、１つの識別子、又は複数の識別子の「経路」のいずれかを含むことができる。たとえば、インフィックス言語は、
Classl.Instance1.Fldl=3
などの「．」演算子を使用して経路をサポートする。

１４．２固有識別子
それぞれのＩｄｅｎｔｉｆｉｅｒ＿Ｅｌｅｍｅｎｔについて、ユーザは、識別子が固有識別子（Ｉｎｔｒｉｎｓｉｃ＿Ａｔｔｒｉｂ）、又は規則定義言語に組み込まれた識別子であることを任意に指定することができる。サーバ１０２は、これらの識別子を調べ、これらをその固有名のリストと比較することができる。大文字と小文字とを区別しない合致などの合致があり得る。そうでない場合は、サーバ１０２は、シンタックス誤りとしてその使用を拒絶することができる。

インフィックス言語は、それぞれの固有識別子が「＠」接頭部を用いて指定されることを必要とする場合がある。また、インフィックス言語は、固有の使用法の代替形態をサポートすることができる。たとえば、以下の対のステートメントは、文意的に均等物であり得、以下の同一の規則定義言語コードを生成することができる。
@inst_reset(duck.@inst_template)
duck.@inst_template.@inst_reset()

@dmn_push(DomainX)
DomainX.@dmn_push()

if@fld_isunknown(instance1.fldl)then...end
if instancel.fldl.@fld_isunknown()then...end

if@set_doesincludeval(setl,123)then...end
if setl.@set_doesincludeval(123)then...end
その上、サーバ１０２は、本文書によって定義された名前とは異なる名前を有する固有識別子を表すことを選択することがある。たとえば、サーバ１０２は、ｉｎｓｔ＿ｔｅｍｐｌａｔｅを、より単純に「ｔｅｍｐｌａｔｅ」として表し、「ｔｅｍｐｌａｔｅ」をその言語の保留語とすることを選択することがある。

１４．３識別子の解決
規則定義言語は、識別子を、クラス、ドメイン、インスタンス、及びフィールドなどのルールベースオブジェクトに関連付ける。次いで、サーバ１０２は、これらのオブジェクトに対する名前の参照を解決する。

１４．３．１識別子の有効範囲規則
ユーザは、以下のオブジェクトを階層的に定義することができる。
・ rulebase-global objects
・ class-specific objects
・ method-specific localvariables
・ domain-specific objects
・ class-specific objects
・ method-specific localvariables
・ ruleset-specific objects
・ class-specific objects
・ method-specific local variables
・ rule-specific localvariables
この階層内のオブジェクトの位置が、オブジェクト参照に対するその範囲（可視性）を判断する。ルールベースレベルのオブジェクトが、ルールベースレベル及び低位レベルの両方のオブジェクトから、ルールベース全体に認識できる。ドメインレベルのオブジェクトが、ドメインレベル及び低位レベルの両方のオブジェクトから、そのドメイン全体に認識できるが、これらのオブジェクトは、それらのドメインの外部では認識できないことがある。ルールセットレベルのオブジェクトが、ルールセットレベル及び低位レベルの両方のオブジェクトから、ルールセット全体に認識できるが、このようなオブジェクトは、ルールセットの外部では認識できないことがある。低位レベルのオブジェクトが、高位レベルの同名のオブジェクトを「隠す」。したがって、Ａｇｅと名づけられた局所変数が、Ａｇｅと名づけられたクラスフィールドを隠すことがある。

１４．３．２識別子資格
ユーザは、一般に、完全なオブジェクト参照を必要としない。ユーザは、参照を明確にするのに充分な修飾子を指定するだけで良い。したがって、識別子Ａｇｅが、クラスＰｅｒｓｏｎのインスタンスＦａｔｈｅｒ内のフィールドを一意に識別する場合は、ユーザは、単に、
ａｇｅ
を指定するだけで良い。
Ｐｅｒｓｏｎの静的インスタンスが複数ある場合は、ユーザは、さらに、識別子に、
ｆａｔｈｅｒ．ａｇｅ．
の資格を与えることができる。
複数の範囲内クラスがＦａｔｈｅｒオブジェクトを定義する場合は、ユーザは、識別子に、
ｐｅｒｓｏｎ．ｆａｔｈｅｒ．ａｇｅ
の資格をより完全に与えることができる。
Ａｇｅがコードブロックの範囲内の複数の場所で定義される場合は、コードブロックは、適切な修飾子を指定することにより、オブジェクトのそれぞれを参照することができる。

１４．４静的及び動的ＩｄｅｎｔｉｆｉｅｒＳｐｅｃ要素
１４．４、１静的指定
静的ＩｄｅｎｔｉｆｉｅｒＳｐｅｃは、
age
father.age
person.father.age
domain1.ruleset1.duck.donald.age.
などの、推論前に、その値を解決できるものである。
一実施形態においては、ＩｄｅｎｔｉｆｉｅｒＳｐｅｃは、ＩｄｅｎｔｉｆｉｅｒＳｐｅｃが許可されるルールベース内のどこにおいても、静的なものとして指定され得る。特定の実施形態においては、経路は５つを超える識別子から構成されないことがあり、その経路の長さがその解釈に影響を及ぼす。たとえば、５つの識別子を有するフィールド経路は、
<domain_name>.<ruleset_name>.<class_name>.<instance_name>.<field_name>
のフォーマット内にあると想定され、
それに対して、３つの識別子のフィールド経路は、
<class_name>.<instance_name>.<field_name>
のフォーマット内にあると想定される。

１４．４．２動的指定
動的ＩｄｅｎｔｉｆｉｅｒＳｐｅｃは、
//The age ofthe spouse for the Person instance named Father
person.father.spouse.age
//The age of theowner for the Duck instance named Donald
domain1.rulesetl.duck.donald.owner.age
などの、推論中に、その値が解決されるものである。
一実施形態においては、ＩｄｅｎｔｉｆｉｅｒＳｐｅｃは、規則または方法論理内で動的なものとして指定され得る。特定の実施形態においては、これらの指定は、
//The age ofthe spouse of the manager of Employee1's manager's spouse
employee1.manager.spouse.manager.spouse.age=32
などの、任意の長さであり得る。
経路の「末端」は、２つ以上のフィールド名を指定する。一実施形態においては、最後のフィールド名以外のすべてが、インスタンス参照フィールドとして宣言されたフィールドを識別する。上記の例においては、識別子Ｍａｎａｇｅｒ及びＳｐｏｕｓｅがインスタンス参照フィールドに名前を付ける。

１４．４．２．１挙動の推論
推論エンジン１１２は、動的指定において様々なフィールドを評価する時に、未知の値又はナルフィールド値に遭遇することがある。

１４．４．２．１．１未知のフィールド値の取り扱い
推論エンジン１１２は、未知の値を検出した場合は、現在実行中の規則を保留する。

１４．４．２．１．２ナルフィールド値の取り扱い
推論エンジン１１２がナル値を有する中間フィールドを検出した場合は、その結果は、現在のコンテキストに依存することがある。現在のコンテキストが、
employee1.manager.age<32//whereemployee1.manager=NULL(no manager)
などの比較である場合は、推論エンジン１１２は、その比較結果を偽であるとすることがある。推論エンジン１１２は、比較コンテキストの外部でナル値を検出した場合は、誤り例外と共に推論を終了する。この実施形態においては、Ｅｍｐｌｏｙｅｅ１が管理者を持たない（Ｅｍｐｌｏｙｅｅ１．Ｍａｎａｇｅｒ＝ナル）場合は、推論エンジン１１２は、以下の比較のすべてを偽と評価する。
employeel.manager.age<32
employee1.manager.age>=32
employeel.manager.age<>32
employee1.manager.age=32

１５ルールベースのマージング
ルールベースのマージングとは、参加しているルールベース１１４又はサブルールベースからの要素及びフィールドの混合である。場合によっては、マージングは、同じルールベース内の同名のオブジェクトを必要とする。ルールベースビルダ１１０は、ルールベースレベル、制約セットレベル、クラスレベル、ドメインレベル、及びルールセットレベルで、オブジェクト名を比較することにより、ルールベース要素をマージする。

所与のレベルでのオーバラップがない（同名の要素がない）場合は、その結果は、そのレベルのマージオブジェクトの単なる集合体である。したがって、１つのルールベース１１４がＣｌａｓｓ１と名づけられたルールベースレベルのクラスのみを定義し、別のルールベース１１４がＣｌａｓｓ２と名づけられたルールベースレベルのクラスのみを定義する場合は、そのマージ結果は、Ｃｌａｓｓ１及びＣｌａｓｓ２の両方を反映する。

オーバラップがある場合には、その結果は、マージされた要素及びフィールドに依存する。場合によっては、要素とフィールドとの混合がある。他の場合においては、ルールベース１１４間の整合性確認のみがある。いずれの場合においても、以下のガイドラインが適用され得る。まず第１に、マージ結果は、ルールベースビルダ１１０によって認識された要素及びフィールドのみを反映し、名前空間の接頭部のある又は認識されなかった要素／フィールドを含まないことがある。第２に、ルールベース論理をマージしようとしない場合がある。方法については、これは、ただ１つのルールベース要素が、その方法のための実施論理を定義できるということを意味する。規則については、これは、ただ１つのルールベース要素が、その規則のための実施論理を指定できるということを意味する。制約については、これは、ただ１つのルールベース要素が、制約ブール式を指定できるということを意味する。第３に、所与の要素については、マージは、発見された第１のＬｏｃＴａｇ＿Ａｔｔｒｉｂのみを反映する。したがって、第１のルールベース要素がＬｏｃＴａｇ＿Ａｔｔｒｉｂを指定した場合は、そのマージ結果はそのフィールドを反映する。そうでない場合は、その結果は、第２のルールベース要素のための（あれば）ＬｏｃＴａｇ＿Ａｔｔｒｉｂを反映する。以下のセクションにおいては、ルールベース要素が如何にマージされ得るかについて、さらに詳細に記載する。

１５．１ＩｄｅｎｔｉｆｉｅｒＳｐｅｃ＿Ｅｌｅｍｅｎｔのマージング
これらの要素をマージする場合には、１つの要素の指定は、他の要素と同一か又は右側のサブパスであるべきである。たとえば、１つの要素が、Ｐｅｒｓｏｎ．Ｆａｔｈｅｒ．Ｎａｍｅを指定し、他の要素が、Ｐｅｒｓｏｎ．Ｆａｔｈｅｒ．Ｎａｍｅ、Ｆａｔｈｅｒ．Ｎａｍｅ、又はＮａｍｅを指定することができる。指定が同一でない場合は、そのマージ結果は、最も多く指定された（最も長い）指定を反映することがある。

１５．２ＤａｔａＴｙｐｅ＿Ｅｌｅｍｅｎｔのマージング
これらの要素をマージする場合には、それぞれの要素の属性及び部分要素は、他の要素の属性及び部分要素と一貫性を有するべきである。ＤａｔａＴｙｐｅＮｕｍｂｅｒ＿Ｅｌｅｍｅｎｔについては、Ｐｒｅｃｉｓｉｏｎ＿Ａｔｔｒｉｂが異なる場合は、そのマージ結果は、その２つの精度の高い方を反映することがある。

１５．３Ｒｕｌｅｂａｓｅ＿Ｅｌｅｍｅｎｔのマージング
そのマージ結果は、第１の要素のＮａｍｅ＿Ａｔｔｒｉｂを反映する。

１５．４（任意のレベルの）ＩｎｉｔＭｅｔｈｏｄＤｅｆ＿Ｅｌｅｍｅｎｔのマージング
そのマージ結果は、複数のＩｎｉｔＭｅｔｈｏｄＤｅｆ＿Ｅｌｅｍｅｎｔを保持することができる。したがって、それぞれのルールベース要素が、所与のレベルで１つのＩｎｉｔＭｅｔｈｏｄＤｅｆ＿Ｅｌｅｍｅｎｔを定義する場合は、その結果は、そのレベルの２つのＩｎｉｔＭｅｔｈｏｄＤｅｆ＿Ｅｌｅｍｅｎｔとなる。それぞれの要素は、それ自体のフィールド及び部分要素を保持し、マージされた要素は、異なる名前を有するべきである。マージされた要素が同一の名前を有する場合は、それらの要素の最も大きいものが、ＩｎｉｔＭｅｔｈｏｄＢｏｄｙを指定することがある（方法の実施）。

１５．５（任意のレベルの）同名のＡｓｓｏｃ＿Ｅｌｅｍｅｎｔのマージング
ＩｄｅｎｔｉｆｉｅｒＳｐｅｃ要素は、互いに一貫性を有するべきである。

１５．６（任意のレベルの）同名のＣｏｎｓｔｒａｉｎｔＳｅｔ＿Ｅｌｅｍｅｎｔのマージング
ルールベースビルダ１１０は、Ｃｏｎｓｔｒａｉｎｔ＿Ｅｌｅｍｅｎｔを組み合わせることができる。同名のＣｏｎｓｔｒａｉｎｔ＿Ｅｌｅｍｅｎｔについては、ただ１つの要素が、ＧｅｎｅｒａｌＥｘｐｒを指定することがある。

１５．７（任意のレベルの）同名のＣｌａｓｓ＿Ｅｌｅｍｅｎｔのマージング
複数の要素がＰａｒｅｎｔ＿Ｅｌｅｍｅｎｔを指定する場合は、これらの指定は、互いに一貫性を有するべきである。いずれかの要素がＰａｒｅｎｔ＿Ｅｌｅｍｅｎｔを指定する場合は、そのマージ結果は親を反映する。

同名のＦｉｅｌｄＤｃｌ＿Ｅｌｅｍｅｎｔについては、ＲｅｓｏｌｕｔｉｏｎＴｙｐｅ＿Ａｔｔｒｉｂ及びＤａｔａＴｙｐｅ＿Ｅｌｅｍｅｎｔは、同一であるべきである。１つの要素が「最終値」を指定したが、他の要素が指定しなかった場合は、その要素は、「第１の値」となる。ルールベースビルダ１１０は、ＣｏｎｓｔｒａｉｎｅｒＬｉｓｔ＿Ｅｌｅｍｅｎｔのリストを組み合わせることができる。両方の要素がＣｏｎｓｔｒａｉｎｔＶｉｏｌａｔｉｏｎ＿Ｅｌｅｍｅｎｔを指定する場合は、ルールベースビルダ１１０は、最も限定的なもの（再開要素よりアボート要素）を選択することがある。

同名のＣｌａｓｓＭｅｔｈｏｄＤｅｆ＿Ｅｌｅｍｅｎｔについては、方法署名（パラメータ名を除く）は、一貫性を有するべきであり、せいぜい１つの要素が、ＣｌａｓｓＭｅｔｈｏｄＢｏｄｙ＿Ｅｌｅｍｅｎｔを指定することがある（方法の実施）。

同名のＳｔａｔｉｃＩｎｓｔＤｅｆ＿Ｅｌｅｍｅｎｔについては、ルールベースビルダ１１０は、ＬａｓｔＣｈａｎｃｅＶａｌｕｅ＿Ｅｌｅｍｅｎｔの任意のリストを組み合わせることがある。同名の識別子を有する要素については、ルールベースビルダ１１０は、発見された最初のＬａｓｔＣｈａｎｃｅＶａｌｕｅのみを保持することがある。ルールベースビルダ１１０は、ＦｉｅｌｄＤｃｌ＿Ｅｌｅｍｅｎｔに関する制約を取り扱う。

１５．８同名のＤｏｍａｉｎ＿Ｅｌｅｍｅｎｔのマージング
いずれかの要素がクライアントアプリケーション１２２と共用される場合は、その結果も共用される。そうでない場合は、その結果も共用されない。両方の要素がＤｏｍａｉｎＧｏａｌ＿Ｅｌｅｍｅｎｔを指定した場合は、その目標は、一貫性のある値を有するべきである。いずれかの要素が目標を指定した場合は、そのマージ結果は、目標を反映する。

いずれかの要素が、ＤｏｍａｉｎＡｐｐＳｈａｒｅｄＦｌｄｓ＿Ｅｌｅｍｅｎｔを指定した場合は、その結果は、ＤｏｍａｉｎＡｐｐＳｈａｒｅｄＦｌｄｓ＿Ｅｌｅｍｅｎｔを反映することがある。両方がＤｏｍａｉｎＡｐｐＳｈａｒｅｄＦｌｄｓ＿Ｅｌｅｍｅｎｔを指定した場合は、その部分要素がマージされることがあるが、同じ識別子が、ＤｏｍａｉｎＰｒｅＣｏｎｄｉｔｉｏｎＬｉｓｔ＿ＥｌｅｍｅｎｔとＤｏｍａｉｎＰｏｓｔＣｏｎｄｉｔｉｏｎＬｉｓｔ＿Ｅｌｅｍｅｎｔとの両方で終了すべきではない。

同名のＲｕｌｅｓｅｔ＿Ｅｌｅｍｅｎｔについては、１つの要素がＰｏｓｔ＿Ａｔｔｒｉｂを「条件付き」を指定し、他の要素が指定しなかった場合は、その要素は「無条件」となる。いずれかの要素がアプリケーションと共用される場合は、その結果も共用される。そうでない場合は、その結果は共用されない。ルールベースビルダ１１０は、Ｒｕｌｅ＿Ｅｌｅｍｅｎｔ部分要素を組み合わせるが、同名のＲｕｌｅ＿Ｅｌｅｍｅｎｔは認めないことがある。

１６固有識別子
規則定義言語は、固有識別子を参照する。以下に、インフィックス言語で用いられる固有識別子の例を示す。これらの例においては、インフィックス言語には、それぞれの固有識別子が「＠」接頭部を用いて指定されることが必要である。

１６．１記号参照
１６．１．１ｓｃｏｐｅ＿ｇｌｏｂａｌ
この識別子は、ルールベース範囲レベルに対する記号参照である。たとえば、これは、ルールベースレベルのＣｌａｓｓ１をドメインレベルのＣｌａｓｓ１と区別する際に有用であり得る。この識別子は、
@scope_global.classl.instancel.fld1=3
などにより、識別子経路内の第１の識別子として指定されることがある。

１６．１．２ｓｃｏｐｅ＿ｃｕｒｒｃｌａｓｓ
この識別子は、方法を実行するための現在のクラスに対する記号参照である。たとえば、これは、インスタンスｘｙｚを局所変数ｘｙｚと区別する際に有用であり得る。この識別子は、
@scope_currclass.xyz.fldl=3
などにより、識別子経路内の第１の識別子として、方法論理では指定されるが、規則論理では指定されないことがある。

１６．１．３ｓｃｏｐｅ＿ｃｕｒｒｉｎｓｔａｎｃｅ
この識別子は、方法を実行するための現在のインスタンスに対する記号参照である。たとえば、これは、フィールドｘｙｚを局所変数ｘｙｚと区別する際に有用であり得る。この識別子は、
@scope_currinstance.xyz=3
などにより、識別子経路内の第１の識別子として、方法論理では指定されるが、規則論理では指定されないことがある。

１６．１．４ｃａｎｄｉｄａｔｅ＿ｖａｌｕｅ
この識別子は、フィールドのために提案された新しい値に対する記号参照である。この識別子は、
@candidate_value>=0or @candidate_value<=max_age
などにより、制約ブール式内で指定されることがある。

１６．２固有オブジェクト
１６．２．１ｉｎｓｔ＿ｔｅｍｐｌａｔｅ
この識別子は、すべてのクラスに関連付けられた固有インスタンスに対する参照である。この識別子は、動的インスタンスを作成するためのモデルとして機能する。規則又は方法が、新しい動的インスタンスの所望のフィールドを反映するよう、テンプレートのフィールドを初期設定する。テンプレートインスタンスは、書込み専用インスタンスであるという点で、使用が限定されている特別な形式のインスタンスである。ルールベース論理は、テンプレートフィールドのための値のみを設定できるが、テンプレートインスタンスを介して、テンプレートフィールドを読み取ること、又は方法を起動することはできない。同様に、テンプレートインスタンスは、パターン合致のためなどの、推論の重みを有さないことがある。１つの使用例を以下に示す。
//Create aDuck
@inst_reset(duck.@inst_template)//Reset fields to UNKNOWN
// status
//Initializetemplate fields
duck.@inst_template.age=4
... //init additional fields
//Create newinstance
@inst_make(duck)

１６．３エンジンレベルの方法
１６．３．１ｅｎｇｎ＿ｓｔａｒｔｃｈａｉｎ
この識別子は、現在のドメインコンテキストのための推論を起動する（又は再始動する）固有の方法である。一例を以下に示す。
rcInfer=@engn_startchain()
推論エンジン１１２が既に現在のドメインに対して推論している場合は、推論エンジン１１２は、誤りと共にこの演算をアボートすることがある。方法戻りコードは、ｅｎｇｎ＿ｓｔｏｐｃｈａｉｎ（）戻りコード（あれば）を示す。推論が、（ｅｎｇｎ＿ｓｔｏｐｃｈａｉｎを実行せずに）通常に終了する場合は、戻りコードはゼロである。

１６．３．２ｅｎｇｎ＿ｓｔｏｐｃｈａｉｎ
この識別子は、現在のドメインコンテキストのための推論を直ちにアボートする固有の方法である。推論エンジン１１２が現在のドメインに対して、現在、推論していない場合は、推論エンジン１１２は、誤りと共にこの演算をアボートすることがある。この識別子はまた、推論戻りコードとして返される数値値を指定する。慣例として、推論が通常に終了した場合には、推論エンジン１１２がゼロを返すので、この値はゼロ以外であり得る。いずれの場合においても、推論は、現在の規則アクションを完了せずに、直ちに終了することがある。そのアクションが方法を起動し、その１つがｅｎｇｎ＿ｓｔｏｐｃｈａｉｎ（）を起動した場合は、その方法及びすべての動的に優勢な方法も直ちに終了する。１つの使用例を以下に示す。
@engn_stopchain(-123)

１６．３．３ｅｎｇｎ＿ｔｒａｃｅｍｓｇ
この識別子は、アプリケーションのＭｅｓｓａｇｅＨａｎｄｌｅｒ又はＭｅｓｓａｇｅＡｒｒａｙオブジェクト（あれば）に、テキストメッセージを送信する固有の方法である。クライアントアプリケーション１２２がこれらのオブジェクトのいずれをも定義していない場合は、推論エンジン１１２は、ｅｎｇｎ＿ｔｒａｃｅｍｓｇ（）の起動を無視することがある。１つの使用例を以下に示す。
@engn_tracemsg(“InRulel;father age=”&father.age)

１６．４ドメインレベルの方法
１６．４．１ｄｍｎ＿ｐｕｓｈ
この識別子は、指定された部分推論ドメインをロードする固有の方法である。指定されたドメインが既にロードされている（プッシュされている）場合は、推論エンジン１１２は、誤りと共にこの演算をアボートすることがある。１つの使用例を以下に示す。
@dmn_push(DomainX)

１６．４．２ｄｍｎ＿ｐｏｐ
この識別子は、現在の部分推論ドメインをアンロードする固有の方法である。現在ロードされているドメインがない場合は、推論エンジン１１２は、誤りと共にこの演算をアボートすることがある。１つの使用例を以下に示す。
@dmn_pop()

１６．５インスタンスレベルの方法
１６．５．１ｉｎｓｔ＿ｍａｋｅ
この識別子は、インスタンステンプレートから動的インスタンスを作成する固有の方法である。この識別子は、テンプレートインスタンスのための現在のフィールド値に基づいて、インスタンスを作成する。ルールベース論理は、すべてのインスタンスによって共用されるフィールド値と共に、テンプレートインスタンスを一回初期設定し、次いでｉｎｓｔ＿ｍａｋｅ（）を数回起動し、インスタンス特有の差異のためのテンプレートフィールド値を毎回修正することにより、複数の同様のインスタンスを作成することができる。

１６．５．２ｉｎｓｔ＿ｒｅｓｅｔ
この識別子は、指定されたインスタンスのフィールドのすべてを未知の状態にリセットする固有の方法である。１つの使用例を以下に示す。
@inst_reset(classl.instancel)

１６．５．３ｉｎｓｔ＿ｄｅｌｅｔｅ
この識別子は、指定された動的インスタンスを消去する固有の方法である。一実施形態においては、いかなる種類の規則も動的インスタンスを作成することができるが、パターン合致規則のみが、それらを消去することができる。１つの使用例を以下に示す。
for
anyduck d
if
//duckis an old duck
d.getage()>=100
then
@inst_delete(d)
end

１６．５．４ｉｎｓｔ＿ｇｅｔｎａｍｅ
この識別子は、指定されたインスタンスの名前を返す固有の方法である。静的インスタンスについては、返された名前は、
“Domain1.Rulesetl.Person.Fafher”
などの、「．」区切り記号の付いた、完全に資格を有する名前である。
動的インスタンスについては、インスタンス識別子は、
“Domain1.Rulesetl.Person(23)”
などの索引値を反映する。
１つの使用例を以下に示す。
strName=@inst_getname(person1.spouse)

１６．６フィールドレベルの方法（すべてのフィールド）
１６．６．１ｆｌｄ＿ｉｓｋｎｏｗｎ
この識別子は、指定されたフィールドの認識力のステータスを試験する固有の方法である。フィールドが現在、既知の状態である場合は、この方法はブール真値を返す。そうでない場合は、そのフィールドが既知の状態を得るまで、現在実行中の規則は保留する。１つの使用例を以下に示す。
if@fld_isknown(instance.fldl)then...end

１６．６．２ｆｌｄ＿ｉｓｕｎｋｎｏｗｎ
この識別子は、指定されたフィールドの認識力のステータスを試験する固有の方法である。フィールドが現在、既知の状態である場合は、この方法はブール偽値を返す。そうでない場合は、この方法はブール真値を返す。１つの使用例を以下に示す。
if@fld_isunknown(instancel.fldl)then...end

１６．６．３ｆｌｄ＿ｒｅｓｅｔ
この識別子は、指定されたフィールドを未知の状態にリセットする固有の方法である。１つの使用例を以下に示す。
@fld_reset(classl.instancel.fld1)

１６．７フィールドレベルの方法（セットに特有）
１６．７．１ｓｅｔ＿ａｄｄｖａｌ
この識別子は、指定された値をセットに追加する固有の方法である。セットが既に値を包含している場合は、この演算は効果を有さない。指定された値は、セットにタイプ互換性を有することがある。１つの使用例を以下に示す。
@set_addval(setl,123)

１６．７．２ｓｅｔ＿ｄｏｅｓｉｎｃｌｕｄｅｖａｌ
この識別子は、セットが既に指定された値を包含するかどうかを試験する固有の方法である。セットがその値を包含している場合は、この方法はブール真値を返す。そうでない場合は、ブール偽値を返す。指定された値は、セットにタイプ互換性を有することがある。１つの使用例を以下に示す。
if@set_doesincludeval(setl,123)then...end

１６．７．３ｓｅｔ＿ｒｅｍｏｖｅｖａｌ
この識別子は、セットから指定された値を除去する固有の方法である。その結果、セットは、変更されないままとなり、それ自体のサブセットとなるか、又は空のセットとなる。指定された値は、セットにタイプ互換性を有することがある。１つの使用例を以下に示す。
@set_romoveval(setl,123)

１６．７．４ｓｅｔ＿ｍｅｒｇｅｓｅｔ
この識別子は、指定されたセットをベースセットにマージする固有の方法である。指定されたセットが空である場合は、この演算は効果を有さない。指定されたセットは、ベースセットにタイプ互換性を有することがある。１つの使用例を以下に示す。
@set_mergeset(setl.set2) //merge set2 into setl

１６．７．５ｓｅｔ＿ｅｘｃｌｕｄｅｓｅｔ
この識別子は、指定されたセットの値をベースセットから除去する固有の方法である。その結果、ベースセットは、変更されないままとなり、それ自体のサブセットとなるか、又は空のセットとなる。指定されたセットは、ベースセットにタイプ互換性を有することがある。１つの使用例を以下に示す。
@set_excludeset(setl,set(123,456))//removevalues from setl

１６．７．６ｓｅｔ＿ｉｎｔｅｒｓｅｃｔ
この識別子は、指定されたセットをベースセットと交差させる固有の方法である。その結果、ベースセットは、変更されないままとなり、それ自体のサブセットとなるか、又は空のセットとなる。指定されたセットは、ベースセットにタイプ互換性を有することがある。１つの使用例を以下に示す。
@set_intersect(setl,set(123,456))//possiblymodifies setl

１６．７．７ｓｅｔ＿ｄｏｅｓｉｎｔｅｒｓｅｃｔ
この識別子は、指定されたセットがベースセットと交差するかどうかを試験する固有の方法である。セット同士が任意の値を共用している場合は、この方法はブール真値を返す。そうでない場合は、ブール偽値を返す。指定されたセットは、ベースセットにタイプ互換性を有することがある。１つの使用例を以下に示す。
if@set_doesintersect(setl,set2)then...end

１６．７．８ｓｅｔｇｅｔｓｉｚｅ
この識別子は、セット内の要素の数を示す数字値を返す固有の方法である。セットが空である場合は、この方法はゼロを返す。１つの使用例を以下に示す。
var cElementsis number=@set_getsize(setl)

１６．８フィールドレベルの方法（文字列に特有）
１６．８．１ｓｔｒｉｎｇ＿ｇｅｔｌｅｎｇｔｈ
この識別子は、文字列の長さを示す数字値を返す固有の方法である。文字列が空である場合は、この方法はゼロを返す。１つの使用例を以下に示す。
var cChars isnumber=@string_getlength(stringl)

１６．９ルールセットレベルの方法
１６．９．１ｒｕｌｅｓｅｔ＿ｐｏｓｔｒｕｌｅｓ
この識別子は、指定されたルールセットのための規則を、現在のドメインコンテキストのためのアジェンダにポストする固有の方法である。指定されたルールセットは、「条件付き」のＰｏｓｔ＿Ａｔｔｒｉｂ値を有することがある。１つの使用例を以下に示す。
@ruleset_postrules(domainl.rulesetl)

好ましい実施形態及び一般に関連する方法について、本発明を記述してきたが、当業者には、好ましい実施形態及び方法の修正形態及び置換形態が自明であろう。したがって、好ましい例示的実施形態についての上記の記述は、本発明を定義又は制約するものではない。頭記の特許請求の範囲に定義されている本発明の趣旨及び範囲から逸脱することなく、他の変更形態、代替形態、及び修正形態も可能である。

本発明の一実施形態による推論サービスを提供するためのシステムの例を示す例示的ブロック図である。本発明の一実施形態による推論サービスを提供するためのシステムの別の例を示す例示的ブロック図である。本発明の一実施形態による推論サービスを提供するためのシステムのさらに別の例を示す例示的ブロック図である。本発明の一実施形態によるルールベースアーキテクチャの例を示す例示的ブロック図である。本発明の一実施形態によるルールベースビルダの例を示す例示的ブロック図である。本発明の一実施形態によるルールベースビルダの例を示す例示的ブロック図である。本発明の一実施形態による推論エンジンの例を示す例示的ブロック図である。本発明の一実施形態による推論エンジンの例を示す例示的ブロック図である。本発明の一実施形態による推論エンジンの例を示す例示的ブロック図である。本発明の一実施形態による推論エンジンの例を示す例示的ブロック図である。本発明の一実施形態によるコアアプリケーションの例を示す例示的ブロック図である。本発明の一実施形態によるインターフェースの例を示す例示的ブロック図である。本発明の一実施形態による規則のタイプの例を示す例示的ブロック図である。本発明の一実施形態による規則のタイプの例を示す例示的ブロック図である。本発明の一実施形態によるルールベースを共用するためのメモリ配置の例を示す例示的ブロック図である。本発明の一実施形態に従って、ルールベース構成要素が統合されたルールベースにマージされる例を示す例示的ブロック図である。本発明の一実施形態に従って、ルールベース構成要素が統合されたルールベースにマージされる例を示す例示的ブロック図である。本発明の一実施形態に従って、ルールベース構成要素が統合されたルールベースにマージされる例を示す例示的ブロック図である。本発明の一実施形態に従って、ルールベース構成要素が統合されたルールベースにマージされる例を示す例示的ブロック図である。本発明の一実施形態による推論サービスを提供する方法の例を示す例示的流れ図である。本発明の一実施形態によるルールベースビルディングの方法の例を示す例示的流れ図である。本発明の一実施形態に従って、ルールベース構成要素をマージする方法の例を示す例示的流れ図である。

Claims

推論サービスを提供する方法であって、
指定されたドメインのための複数の規則を受け取るステップと、
前記規則に関連付けられた少なくとも１つの事前条件を識別するステップとを含み、それぞれの事前条件とは、前記規則を実行する際に使用される入力であり、
さらに、前記規則に関連付けられた少なくとも１つの事後条件を識別することを含み、それぞれの事後条件とは、前記規則の実行からの出力であり、
さらに、前記識別された事前条件に対応する入力値を受け取るステップと、
前記入力値を使用して前記規則の少なくとも一部分を実行し、出力値を生成するステップとを含み、前記出力値が前記識別された事後条件に対応する方法。
前記規則が第１の規則を含み、
前記第１の規則の１つが、補足ルールベースから第２のドメインをロードすることにより、部分推論を起動し、前記第１の規則の実行が再開される前に、前記第２のドメインの規則に対する推論が終了する請求項１に記載の方法。
前記規則が第１の規則を含み、
前記第１の規則の１つが、第１のルールベースから第２のドメインをロードすることにより、部分推論を起動し、前記第１の規則の実行が再開される前に、前記第２のドメインの規則に対する推論が終了する請求項１に記載の方法。
前記規則が第１の規則を含み、前記第１の規則の実行が終了した後に、複数の第２の規則を実行することをさらに含み、前記第２の規則の実行が、前記第１の規則からの前記出力値を前記第２の規則のための入力値として使用する請求項１に記載の方法。
フィールドを撤回可能なフィールドとして識別するステップと、
撤回不可能な値を前記撤回可能なフィールドに割り当てるステップと、
１つ以上の撤回可能な値を前記撤回可能なフィールドに割り当てるステップと、
前記撤回可能なフィールドを前記撤回不可能な値に撤回するステップとをさらに含む請求項１に記載の方法。
前記規則の実行が開始された後に、第１の通信ハンドラを使用して第２の入力値を受け取るステップと、
前記規則の実行が終了する前に、第２の通信ハンドラを使用して前記出力値を伝えるステップとをさらに含む請求項１に記載の方法。
第１のフィールドを識別する情報を受け取るステップと、
最終値を前記第１のフィールドに割り当てた第１の規則を識別するステップと、
前記第１の規則をファイアさせた第２のフィールドを識別するステップと、
最終値を前記第２のフィールドに割り当てた第２の規則を識別するステップとをさらに含む請求項１に記載の方法。
前記規則の少なくとも一部分を実行することが、決定木規則をファイアする、フェイルする、又は保留するかどうかを判断することを含む請求項１に記載の方法。
前記決定木規則を保留することが、前記決定木規則を保留させた２進ステートメントを識別することを含み、
前記決定木規則をアンペンドするステップと、前記決定木規則を保留させた前記２進ステートメントでの実行を再始動するステップとをさらに含む請求項８に記載の方法。
前記規則の少なくとも一部分を実行することが、前記規則が実行される時に、単調推論を強制実施することを含む請求項１に記載の方法。
前記規則が最終値フィールドに影響を及ぼし、複数の値が、前記最終値フィールドに割り当てられることがある請求項１に記載の方法。
前記規則を包含するルールベースの読取り専用画像をメモリ内に格納するステップと、
クライアント特有の情報ブロック内の前記入力及び出力値をメモリ内に格納するステップとをさらに含む請求項１に記載の方法。
前記規則の少なくとも一部分を実行することが、特定のフィールドのための第２の入力値なしでは前記実行を完了できないと判断することを含み、
初期設定ハンドラ及び前記規則を包含するルールベースの少なくとも１つを使用して、前記第２の入力値を受け取ることをさらに含み、前記初期設定ハンドラが、ユーザ又はアプリケーションから前記第２の入力値を受け取るよう動作可能であり、前記ルールベースが、前記特定のフィールドのための最後のチャンスの値を識別するよう動作可能である請求項１に記載の方法。
前記規則の少なくとも一部分を実行することが、フィールドに割り当てられた値が制約に違反するかどうかを判断することを含み、
前記フィールドに割り当てられた前記値が前記制約に違反する場合は、前記フィールドによって定義された違反アクションを実施することをさらに含む請求項１に記載の方法。
前記違反アクションが、前記規則の前記実行を中止するステップと、代入値を前記フィールドに割り当てるステップと、初期設定ハンドラを使用して置換値を要求するステップとのうちの少なくとも１つを含む請求項１４に記載の方法。
前記規則が、２進ルールベース内の前記指定されたドメインの少なくとも一部分を形成し、前記ドメインが、前記事前条件及び前記事後条件を識別する請求項１に記載の方法。
前記ルールベースが、前記規則を定義する、１つ以上のコンパイルされたＸＭＬ文書を含む請求項１６に記載の方法。
前記規則の少なくとも一部分を実行することが、前記規則を前向き連鎖すること又は後ろ向き連鎖することのいずれかを含む請求項１に記載の方法。
規則スナップショットを生成することをさらに含み、前記規則スナップショットが、前記規則、及び前記規則を保留する、前記規則に関連付けられた任意のフィールドのうちの１つの現在のステータスを識別する請求項１に記載の方法。
前記規則の少なくとも一部分を実行することが、推論エンジンオブジェクトを使用して前記規則の少なくとも一部分を実行することを含む請求項１に記載の方法。
前記推論エンジンオブジェクトが、ステートレス推論エンジンオブジェクト又はステートフル推論エンジンオブジェクトを含む請求項２０に記載の方法。
前記複数の規則を受け取ることが、
前記規則に関連付けられた場所を受け取るステップと、
前記場所にアクセスするステップと、
前記アクセスされた場所から前記規則を検索するステップとを含む請求項１に記載の方法。
推論サービスを提供するためのシステムであって、
指定されたドメインのために複数の規則を格納するよう動作可能なメモリと、
前記規則に関連付けられた、前記規則を実行する際に使用される入力である事前条件を識別し、
前記規則に関連付けられた、前記規則の前記実行からの出力である事後条件を識別し、
前記事前条件に対応する入力値を受け取り、
前記入力値を使用して前記規則の少なくとも一部分を実行し、前記事後条件に対応する出力値を生成するよう、一括して動作可能な１つ以上のプロセッサとを備えたシステム。
前記規則が、第１のルールベースの少なくとも一部分を形成する第１の規則を含み、
前記第１の規則の１つが、補足ルールベースから第２のドメインをロードすることにより、部分推論を起動し、前記第１の規則の実行が再開される前に、前記第２のドメインの規則に対する推論が終了する請求項２３に記載のシステム。
前記規則が第１の規則を含み、
前記第１の規則の１つが、前記第１のルールベースから第２のドメインをロードすることにより、部分推論を起動し、前記第１の規則の実行が再開される前に、前記第２のドメインの規則に対する推論が終了する請求項２３に記載のシステム。
前記規則が第１の規則を含み、
前記１つ以上のプロセッサが、前記第１の規則の実行が終了した後に複数の第２の規則を実行するよう、さらに一括して動作可能であり、前記第２の規則の実行が、前記第１の規則からの前記出力値を前記第２の規則のための入力値として使用する請求項２３に記載のシステム。
前記１つ以上のプロセッサが、
フィールドを撤回可能なフィールドとして識別し、
撤回不可能な値を前記撤回可能なフィールドに割り当て、
１つ以上の撤回可能な値を前記撤回可能なフィールドに割り当て、
前記撤回可能なフィールドを前記撤回不可能な値に撤回するよう、さらに一括して動作可能である請求項２３に記載のシステム。
前記１つ以上のプロセッサが、
第１のフィールドを識別する情報を受け取り、
最終値を前記第１のフィールドに割り当てた第１の規則を識別し、
前記第１の規則をファイアさせた第２のフィールドを識別し、
最終値を前記第２のフィールドに割り当てた第２の規則を識別するよう、さらに一括して動作可能である請求項２３に記載のシステム。
前記１つ以上のプロセッサが、
決定木規則をファイアする、フェイルする、又は保留するかどうかを判断するステップと、
前記決定木規則をアンペンドするステップと、前記決定木規則を保留した２進ステートメントで実行を再始動するステップとにより、
前記規則の少なくとも一部分を実行するよう一括して動作可能であり、
前記決定木規則を保留することが、前記決定木規則を保留した前記２進ステートメントを識別することを含む請求項２３に記載のシステム。
前記１つ以上のプロセッサが、特定のフィールドのための第２の入力値なしでは前記実行が完了できないと判断することにより、前記規則の少なくとも一部分を実行するよう一括して動作可能であり、
前記１つ以上のプロセッサが、初期設定ハンドラ及び前記規則を包含するルールベースのうちの少なくとも１つを使用して前記第２の入力値を受け取るよう、さらに一括して動作可能であり、前記初期設定ハンドラが、ユーザ又はアプリケーションから前記第２の入力値を受け取るよう動作可能であり、前記ルールベースが、前記特定のフィールドのための最後のチャンスの値を識別するよう動作可能である請求項２３に記載のシステム。
前記１つ以上のプロセッサが、フィールドに割り当てられた値が制約に違反するかどうかを判断することにより、前記規則の少なくとも一部分を実行するよう一括して動作可能であり、
前記１つ以上のプロセッサが、前記フィールドに割り当てられた前記値が前記制約に違反する場合は、前記フィールドによって定義された違反アクションを実行するよう、さらに一括して動作可能である請求項２３に記載のシステム。
前記１つ以上のプロセッサが、規則スナップショットを生成するよう、さらに一括して動作可能であり、前記規則スナップショットが、前記規則、及び前記規則を保留する、前記規則に関連付けられた任意のフィールドのうちの１つの現在のステータスを識別する請求項２３に記載のシステム。
少なくとも１つのコンピュータ読取り可能媒体上で具現化される論理であって、
指定されたドメインのための複数の規則に関連付けられた、前記規則を実行する際に使用される入力である事前条件を識別し、
前記規則に関連付けられた、前記規則の前記実行からの出力である事後条件を識別し、
前記事前条件に対応する入力値を受け取り、
前記入力値を使用して前記規則の少なくとも一部分を実行し、前記事後条件に対応する出力値を生成するよう実行される場合に動作可能である論理。
推論サービスを提供するためのシステムであって、
指定されたドメインのための複数の規則に関連付けられた事前条件を識別するための手段を備え、前記事前条件が、前記規則を実行する際に使用される入力であり、
さらに、前記規則に関連付けられた事後条件を識別するための手段を備え、前記事後条件が、前記規則の前記実行からの出力であり、
さらに、前記事前条件に対応する入力値を受け取るための手段と、
前記入力値を使用して前記規則の少なくとも一部分を実行し、前記事後条件に対応する出力値を生成するための手段とを備えたシステム。
推論サービスを提供する方法であって、
指定されたドメインのための複数の規則を推論エンジンに伝えることを含み、前記規則が事前条件及び事後条件に関連付けられ、前記事前条件が前記規則を実行する際に前記推論エンジンによって使用される入力であり、前記事後条件が前記規則の前記実行からの出力であり、
さらに、前記事前条件に対応する入力値を前記推論エンジンに伝えるステップと、
前記推論エンジンから、前記事後条件に対応する出力値を受け取るステップとを含む方法。
前記複数の規則を前記推論エンジンに伝えることが、２進ルールベース及びルールベースの場所のうちの少なくとも１つを前記推論エンジンに伝えることを含む請求項３５に記載の方法。
前記ルールベースの前記場所が、ユニフォームリソースロケータ（ＵＲＬ）を含む請求項３６に記載の方法。
前記出力値が、複数の出力値の１つを含み、
前記推論エンジンが、ステートレス推論エンジンを含み、
制御オブジェクトを前記推論エンジンに伝えることをさらに含み、前記制御オブジェクトが、前記推論エンジンが、それぞれが前記出力値の１つを識別する複数の出力メッセージの少なくとも１つを生成するかどうかを識別し、出力文書が、前記出力値のすべて及び規則スナップショットを識別し、前記規則スナップショットが、前記規則、及び前記規則を保留する、前記規則に関連付けられた任意のフィールドのうちの１つの現在のステータスを識別する請求項３５に記載の方法。
前記出力値が、複数の出力値の１つを含み、
前記推論エンジンが、ステートフル推論エンジンを含み、
前記推論エンジン内の少なくとも１つの機能を起動することをさらに含み、前記少なくとも１つの機能が、前記出力値の１つを識別するステップと、前記出力値のすべてを識別するステップと、前記規則、及び前記規則を保留する、前記規則に関連付けられた任意のフィールドのうちの１つの現在のステータスを識別する規則スナップショットを生成するステップと、前記出力値の１つを解像した前記規則を識別するステップと、撤回可能な値を前記規則によって使用されるフィールドに割り当てるステップと、撤回不可能な値を前記規則によって使用されるフィールドに割り当てるステップと、前記規則によって使用されるフィールドの値を撤回するステップとのうちの少なくとも１つを行うよう動作可能である請求項３５に記載の方法。
推論サービスを提供する方法であって、
第１のルールベースの少なくとも一部分を含む指定されたドメインのための複数の第１の規則を受け取るステップと、
前記第１の規則をメモリ内にロードするステップと、
第２の規則を含む補足ルールベースを受け取るステップと、
前記第２の規則を前記メモリ内の前記第１の規則に組み合わせるステップと、
前記第１の及び第２の規則の少なくとも一部分を実行して、出力値を生成するステップとを含む方法。
第３の規則を含む第２の補足ルールベースを受け取るステップと、
前記第３の規則を前記メモリ内の前記第１の規則に組み合わせるステップと、
前記第１の及び第３の規則の少なくとも一部分を実行して、第２の出力値を生成するステップとをさらに含む請求項４０に記載の方法。
前記第２の規則が、前記第１のルールベースによって定義されたデータオブジェクト上でのみ動作する請求項４０に記載の方法。
前記第１のルールベースが、前記第２の規則が前記第１の規則と矛盾する場合に、前記第２の規則が使用できるかどうかを識別する請求項４０に記載の方法。
前記第１のルールベース及び前記補足ルールベースが、２進ルールベースを含む請求項４０に記載の方法。
推論サービスを提供するためのシステムであって、
指定されたドメインのための複数の第１の規則を格納するよう動作可能なメモリを備え、前記複数の第１の規則が、第１のルールベースの少なくとも一部分を含み、
さらに、第２の規則を含む補足ルールベースを受け取り、
前記第２の規則を前記メモリ内の前記第１の規則に組み合わせ、
前記第１の及び第２の規則の少なくとも一部分を実行して、出力値を生成するよう、一括して動作可能な１つ以上のプロセッサを備えたシステム。
前記第２の規則が、前記第１のルールベースによって定義されたデータオブジェクト上でのみ動作する請求項４５に記載のシステム。
前記第１のルールベースが、前記第２の規則が前記第１の規則と矛盾する場合に、前記第２の規則が使用できるかどうかを識別する請求項４５に記載のシステム。
前記第１のルールベース及び前記補足ルールベースが、２進ルールベースを含む請求項４５に記載のシステム。
少なくとも１つのコンピュータ読取り可能媒体上で具現化される論理であって、
指定されたドメインのための、第１のルールベースの少なくとも一部分を含む複数の第１の規則を受け取り、
前記第１の規則をメモリ内にロードし、
第２の規則を含む補足ルールベースを受け取り、
前記第２の規則を前記メモリ内の前記第１の規則と組み合わせ、
前記第１の及び第２の規則の少なくとも一部分を実行して、出力値を生成するよう実行される場合に動作可能である論理。
推論サービスを提供する方法であって、
指定されたドメインのための、第１のルールベースの少なくとも一部分を含む複数の第１の規則を、推論エンジンに伝えるステップと、
第２の規則を含む補足ルールベースを前記推論エンジンに伝えるステップと、
前記推論エンジンが、前記第２の規則を前記メモリ内の前記第１の規則に組み合わせることができるようにするステップと、
前記推論エンジンから出力値を受け取るステップとを含み、前記推論エンジンが、前記第１の及び第２の規則の少なくとも一部分を実行して、前記出力値を生成するよう動作可能である方法。
前記複数の第１の規則を前記推論エンジンに伝えることが、前記第１の規則を包含する２進ルールベース及び前記第１の規則を包含するルールベースの場所のうちの少なくとも１つを前記推論エンジンに伝えることを含む請求項５０に記載の方法。
推論サービスを提供する方法であって、
指定されたドメインのための複数の規則の少なくとも一部分を実行することを含み、前記規則の少なくとも１つが式を含み、
さらに、前記規則内の前記式を解くのに必要なフィールドが未知の値を有する場合に、前記規則の１つを保留するステップと、
前記決定木規則を保留した前記式に関連付けられた２進ステートメントを識別するステップと、
既知の値を前記規則を保留したフィールドに割り当てるステップと、
前記規則をアンペンドするステップと、
前記識別された２進ステートメントで前記規則の実行を再始動するステップとを含む方法。
前記規則の少なくとも１つが、決定木規則を含み、前記決定木規則内の前記式が、前記決定木規則を少なくとも２つの部分木に分割する請求項５２に記載の方法。
推論サービスを提供するためのシステムであって、
指定されたドメインのための複数の規則を格納するよう動作可能なメモリを備え、前記規則の少なくとも１つが式を含み、
さらに、前記規則の少なくとも一部分を実行し、
前記規則内の前記式を解くのに必要なフィールドが未知の値を有する場合に、前記規則の１つを保留し、
前記決定木規則を保留した前記式に関連付けられた２進ステートメントを識別し、
前記規則を保留した前記フィールドに既知の値を割り当て、
前記規則をアンペンドし、
前記識別された２進ステートメントで前記規則の実行を再始動するよう、一括して動作可能な１つ以上のプロセッサを備えたシステム。
前記規則の少なくとも１つが決定木規則を含み、前記決定木規則内の前記式が、前記決定木規則を少なくとも２つの部分木に分割する請求項５４に記載のシステム。
少なくとも１つのコンピュータ読取り可能媒体上で具現化される論理であって、
指定されたドメインのための、式を含む複数の規則の少なくとも一部分を実行し、
前記規則内の前記式を解くのに必要なフィールドが未知の値を有する場合には、前記規則の１つを保留し、
前記決定木規則を保留した前記式に関連付けられた２進ステートメントを識別し、
前記規則を保留した前記フィールドに既知の値を割り当て、
前記規則をアンペンドし、
前記識別された２進ステートメントで前記規則の実行を再始動するよう実行される場合に動作可能である論理。