(57)【要約】【課題】  自然言語ソフトウェアアプリケーションをプログラミングする際にその作業が容易なソフトウェア開発ツールを提供する。【解決手段】  ソフトウェア開発ツールは、プログラミング言語およびコンパイラを含む。プログラミング言語は、自然言語プログラミングを手助けする一組のプログラミング構文を備える。コンパイラは、一組のプログラミング構文の複数のインスタンスを含むソフトウェアプログラムを受け取って、１つのソフトウェアアプリケーションを生成するように適合される。【選択図】  図４
2005332380.tif 000002
【特許請求の範囲】
【請求項１】
自然言語の意味論的要素をモデル化するように適合された言語オブジェクトモデルであって、
自然言語の意味論をモデル化するための、特定の自然言語に関係しない、型の集合を含むことを特徴とする言語オブジェクトモデル。
【請求項２】
型の前記集合は、
名詞句の意味論をモデル化するためのＥｎｔｉｔｙ型を含むことを特徴とする請求項１に記載の言語オブジェクトモデル。
【請求項３】
型の前記集合は、
形容詞句の意味論をモデル化するためのＥｎｔｉｔｙ型を含むことを特徴とする請求項１に記載の言語オブジェクトモデル。
【請求項４】
さらに、
意味論的要素のプロパティをモデル化するためのＲｅｓｔｒｉｃｔｉｏｎ型を含み、
前記Ｅｎｔｉｔｙは前記Ｒｅｓｔｒｉｃｔｉｏｎのホストとなることを特徴とする請求項２に記載の言語オブジェクトモデル。
【請求項５】
型の前記集合は、
動詞または名詞のいずれかとして表現することができるイベントの意味論をモデル化するためのＦｒａｍｅ型を含むことを特徴とする請求項１に記載の言語オブジェクトモデル。
【請求項６】
型の前記集合は、
入力文字列のユーザ定義カテゴリをモデル化するためのＤｅｎｏｔｅｒ型を含むことを特徴とする請求項１に記載の言語オブジェクトモデル。
【請求項７】
前記表記を記述するデータメンバは、型の前記集合のうちの１つの型と自然言語発話の１つの要素との照合を遂行するため、型ＤｅｎｏｔｅｒのＤｅｎｏｔｅｒオブジェクト内の入力文字列のどのユーザ定義カテゴリが実行時に解析エンジンによりランタイムに書き込まれるかの記録を含むことを特徴とする請求項６に記載の言語オブジェクトモデル。
【請求項８】
前記Ｆｒａｍｅ型は、前記Ｆｒａｍｅ型によりモデル化された語句の統語上の主要部に対応する１つまたは複数の見出し語を含むことを特徴とする請求項５に記載の言語オブジェクトモデル。
【請求項９】
さらに、
意味論的要素のプロパティをモデル化するためのＲｅｓｔｒｉｃｔｉｏｎ型を含み、
前記Ｆｒａｍｅ型は前記Ｒｅｓｔｒｉｃｔｉｏｎ型のホストとなることを特徴とする請求項５に記載の言語オブジェクトモデル。
【請求項１０】
型の前記集合は、
意味論的オブジェクトをモデル化するように適用されたＥｎｔｉｔｉｅｓと、
１つまたは複数のオブジェクト間のイベントおよび関連する関係をモデル化するように適合されたＦｒａｍｅｓと、
他のエンティティ、Ｆｒａｍｅｓ、または制約のプロパティおよび関係をモデル化するように適合されたＲｅｓｔｒｉｃｔｉｏｎｓとを含むことを特徴とする請求項１に記載の言語オブジェクトモデル。
【請求項１１】
型の前記集合は、
指定されたＥｎｔｉｔｉｅｓをモデル化するように適合され、別に定義されているクラスから派生された、Ｎａｍｅｄ  Ｅｎｔｉｔｙ型を含むことを特徴とする請求項１に記載の言語オブジェクトモデル。
【請求項１２】
自然言語をモデル化するために使用されるコンピュータ可読データ構造を格納するコンピュータ可読媒体であって、
自然言語の意味論をモデル化するための、特定のアプリケーションに関係しない、型の集合を含む言語オブジェクトモデルを含むことを特徴とするコンピュータ可読媒体。
【請求項１３】
前記言語オブジェクトモデルの型の前記集合は、
意味論的エンティティをモデル化するように適用されたＥｎｔｉｔｙ型と、
イベントおよび関連する関係をモデル化するように適合されたＦｒａｍｅ型と、
Ｅｎｔｉｔｉｅｓ、Ｆｒａｍｅｓ、または他の制約のプロパティおよび関係をモデル化するように適合されたＲｅｓｔｒｉｃｔｉｏｎ型とを含むことを特徴とする請求項１２に記載のコンピュータ可読媒体。
【請求項１４】
前記言語オブジェクトモデルの型の前記集合は、
形容詞句および名詞句の前記意味論をモデル化するためのＥｎｔｉｔｙ型を含むことを特徴とする請求項１２に記載のコンピュータ可読媒体。
【請求項１５】
前記言語オブジェクトモデルの型の前記集合は、さらに、
動詞または名詞のいずれかとして表現することができる意味論的イベントをそれぞれ含むイベントの意味論をモデル化するためのＦｒａｍｅ型を含み、
前記Ｅｎｔｉｔｙ型は前記Ｆｒａｍｅ型のホストとなることを特徴とする請求項１４に記載のコンピュータ可読媒体。
【請求項１６】
型の前記集合は、
意味論的要素のプロパティをモデル化するように適合されたＲｅｓｔｒｉｃｔｉｏｎを含むことを特徴とする請求項１２に記載のコンピュータ可読媒体。
【請求項１７】
型の前記集合は、
指定されたＥｎｔｉｔｉｅｓをモデル化するように適合され、別に定義されているクラスから派生された、Ｎａｍｅｄ  Ｅｎｔｉｔｙ型を含むことを特徴とする請求項１２に記載のコンピュータ可読媒体。
【請求項１８】
型の前記集合は、
入力文字列のユーザ定義カテゴリをモデル化するためのＤｅｎｏｔｅｒ型を含むことを特徴とする請求項１２に記載のコンピュータ可読媒体。
【請求項１９】
自然言語ソフトウェアアプリケーションをプログラムするためのソフトウェア開発ツールであって、
自然言語プログラミングを手助けする一組のプログラミング構文を備えるプログラミング言語と、
前記一組のプログラミング構文の複数のインスタンスを含むソフトウェアプログラムを受け取って、１つのソフトウェアアプリケーションを生成するように適合されたコンパイラとを備えることを特徴とするソフトウェア開発ツール。
【請求項２０】
前記プログラミング言語は、さらに、
プリミティブ型であって、その少なくとも一部が自然言語の意味論をモデル化する、プリミティブ型を含むことを特徴とする請求項１９に記載のソフトウェア開発ツール。
【請求項２１】
前記コンパイラは、前記ソフトウェアプログラムに基づいて宣言スキーマを生成することを特徴とする請求項１９に記載のソフトウェア開発ツール。
【請求項２２】
さらに、
意味論的要素のプロパティをモデル化するためのプリミティブＲｅｓｔｒｉｃｔｉｏｎ型を表す制約基本クラスを備えるクラスライブラリを含むことを特徴とする請求項１９に記載のソフトウェア開発ツール。
【請求項２３】
さらに、
イベントの意味論をモデル化するためのプリミティブＦｒａｍｅ型を表すＦｒａｍｅ基本クラスを備えるクラスライブラリを含むことを特徴とする請求項１９に記載のソフトウェア開発ツール。
【請求項２４】
さらに、
名詞句または形容詞句の意味論をモデル化するためのプリミティブＥｎｔｉｔｙ型を表すＥｎｔｉｔｙ基本クラスを備えるクラスライブラリを含むことを特徴とする請求項１９に記載のソフトウェア開発ツール。
【請求項２５】
前記ソフトウェアアプリケーションは、
言語的に可能な複数の型から選択するための解決可能型の集合であって、前記解決可能型のインスタンスが存在しているかどうかを判定するためそれぞれの解決可能型が解決意味論に従って処理される、解決可能型の集合を含むことを特徴とする請求項１９に記載のソフトウェア開発ツール。
【請求項２６】
解決可能型のペアは、意味論的規則により関係付けられ、解決可能型の前記ペアのうちの１つの解決可能型は、前記他の解決可能型の存在に影響を与えることなく解決意味論を失敗させることができることを特徴とする請求項２５に記載のソフトウェア開発ツール。
【請求項２７】
プログラミング構文の前記集合は、
非プリミティブ型とプリミティブ型との間の関係を調整する統語上のフレームワークを含むことを特徴とする請求項２０に記載のソフトウェア開発ツール。
【請求項２８】
プログラミング構文の前記集合は、
前記プログラミング言語のキーワードであって、前記キーワードのうちの少なくとも１つで、プリミティブ型にアクセスする、キーワードを含むことを特徴とする請求項１９に記載のソフトウェア開発ツール。
【請求項２９】
さらに、
前記プログラミング言語で定義されている非プリミティブ型を含み、前記非プリミティブ型の１つまたは複数は前記プリミティブ型から継承することを特徴とする請求項２０に記載のソフトウェア開発ツール。
【請求項３０】
ランタイムは、動作中意味論的モデルのインスタンスの構成に対し制約条件を課すことを特徴とする請求項１９に記載のソフトウェア開発ツール。
【請求項３１】
自然言語入力の意味論的解釈を生成するためのフレームワークであって、
クライアントアプリケーションと１つまたは複数の解析エンジンとの間に介在し、前記クライアントアプリケーションにとって有効な、前記自然言語入力の複数の解釈を出力するように適合されたインタプリタと、
前記インタプリタと前記１つまたは複数の解析エンジンとの間の相互作用を定義するように適合された型の第１の集合と、
前記インタプリタと前記クライアントアプリケーションとの間の相互作用を定義するように適合された型の第２の集合とを備えることを特徴とするフレームワーク。
【請求項３２】
さらに、
前記クライアントアプリケーションの自然言語特徴の意味論的モデルを記述する宣言スキーマを含み、
前記インタプリタは、前記宣言スキーマで初期化されることを特徴とする請求項３１に記載のフレームワーク。
【請求項３３】
さらに、
自然言語の意味論的要素をモデル化するように適合された、特定の自然言語に関係しない、モデル化型の集合を含む言語オブジェクトモデルを含むことを特徴とする請求項３１に記載のフレームワーク。
【請求項３４】
前記モデル化型は、
前記インタプリタに呼び出された場合に前記複数の意味論的モデル化型のうちの１つまたは複数の型のインスタンス上の有効性にコンテキストベースの制約条件を課すように適合された手続き規則を含むことを特徴とする請求項３３に記載のフレームワーク。
【請求項３５】
前記コンテキストベースの制約条件により、前記インスタンスはもし無効であれば破棄されることを特徴とする請求項３４に記載のフレームワーク。
【請求項３６】
前記モデル化型は、さらに、
型の前記第２の集合のうちの複数の型の間の関係を記述するように適合された制約節を含み、
型の前記第２の集合は、開発者により一部が作成される複数の意味論的型を含むことを特徴とする請求項３３に記載のフレームワーク。
【請求項３７】
前記制約節は、手続き規則で実行時に前記関係の受け入れを判定できるように適合されていることを特徴とする請求項３６に記載のフレームワーク。
【請求項３８】
コンピュータ上で自然言語入力の意味論をモデル化する語彙意味論構造であって、
前記自然言語入力の内容をモデル化するために選択された語彙意味論カテゴリの集合と、
前記自然言語入力の内容を語彙意味論カテゴリの前記集合のうちの１つまたは複数のカテゴリに関連付けるための方法とを含むことを特徴とする語彙意味論構造。
【請求項３９】
前記方法は、
前記自然言語入力の内容を語彙意味論カテゴリの前記集合に関連付けるための意味論的規則のコレクションと、
意味論的規則の前記コレクションを前記自然言語入力に適用するための手続きとを含むことを特徴とする請求項３８に記載の語彙意味論構造。
【請求項４０】
前記方法は、
語彙意味論カテゴリの前記集合において自然言語入力を正規化するための意味論的規則のコレクションであって、統語上のクラスの項および修飾語句およびその意味論を識別し、前記識別された項を語彙意味論カテゴリの前記集合のうちの１つまたは複数のカテゴリに関連付けるように適合された意味論的規則のコレクションを含むことを特徴とする請求項３８に記載の語彙意味論構造。
【請求項４１】
前記方法は、統語カテゴリにまたがって前記自然言語入力を正規化するように適合されていることを特徴とする請求項３８に記載の語彙意味論構造。
【請求項４２】
語彙意味論カテゴリの前記集合は、
前記自然言語入力の一部を表す１つまたは複数の統語カテゴリと、
前記自然言語入力内の前記一部分の関数を表す１つまたは複数の意味役割と、
前記１つまたは複数の統語カテゴリと前記１つまたは複数の意味役割との間のマッピングとを含むことを特徴とする請求項３８に記載の語彙意味論構造。
【請求項４３】
自然言語プログラミングのため自然言語の意味論をモデル化するように適合された解決可能型の集合であって、
自然言語入力内のコマンドをモデル化するように適合されたコマンド型と、
前記自然言語入力の非コマンド要素を表すように適合された制約ホスト型であって、選択されたコマンド型または前記自然言語入力に基づいて、選択されたコマンド型に他動詞的に関連付けられている他の制約ホスト型に、実行時に前記選択されたコマンド型の制約条件のホストとなるように適合された制約ホスト型を関連付けるように適合された、制約ホスト型とを含むことを特徴とする解決可能型の集合。
【請求項４４】
前記自然言語入力にマッピングされた型のインスタンス化は、前記コマンド型または前記制約ホスト型から継承することを特徴とする請求項４３に記載の解決可能型の集合。
【請求項４５】
前記非コマンド要素は、言語要素および前記自然言語入力の複数の言語要素間の複数の相互関係を含むことを特徴とする請求項４３に記載の解決可能型の集合。
【請求項４６】
さらに、
解決可能型の前記集合により一部定義された解決意味論であって、実行時に解決可能型の前記集合のうちの選択された型のインスタンスの有効性を解決するための手続き規則を定義する、解決意味論を含むことを特徴とする請求項４３に記載の解決可能型の集合。
【請求項４７】
前記制約ホスト型は、
動詞または名詞のいずれかとして表現することができる意味論イベントをモデル化するためのＦｒａｍｅ型と、
名詞句および形容詞句の意味論をモデル化するように適合されたＥｎｔｉｔｙ型と、
意味論的要素のプロパティをモデル化するように適合されたＲｅｓｔｒｉｃｔｉｏｎ型とを含むことを特徴とする請求項４３に記載の解決可能型の集合。
【請求項４８】
前記解決可能型は、さらに、
オブジェクトの解決に影響を及ぼすように適合された解決可能型の前記集合のうちの選択された型に関連付けられている手続きコードと、
前記選択された複数の型の前記オブジェクトに課されるように適合された制約条件とを含むことを特徴とする請求項４３に記載の解決可能型の集合。
【請求項４９】
自然言語入力の潜在的解釈は、
１つまたは複数のＲｅｓｔｒｉｃｔｉｏｎホスト型または１つまたは複数の解決不可能型に、オプションにより関連付けられるＣｏｍｍａｎｄ型を含むことを特徴とする請求項４３に記載の解決可能型の集合。
【請求項５０】
前記潜在的解釈の解決は、前記Ｒｅｓｔｒｉｃｔｉｏｎホスト型と解決意味論との間の相互関係により決定された順序で前記Ｃｏｍｍａｎｄ型および前記１つまたは複数のＲｅｓｔｒｉｃｔｉｏｎホスト型の呼び出しを含むことを特徴とする請求項４９に記載の解決可能型の集合。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、自然言語の意味論（意味）をモデル化するシステムおよび方法に関する。より具体的には、本発明は、自然言語入力の内容をモデル化するための語彙意味論構造に関する。
【背景技術】
【０００２】
自然言語とは、発話または文章の慣用句、仮定、および含意のすべてを含む、（コンピュータ言語または他の人工言語とは違い）人々により生み出されたような言語のことである。自然言語処理という状況では、コマンドおよび制御システムは、自然言語の発話または文章を処理し、さらにその発話または文章を認識して、解釈し、使用できる解釈を導き出そうとする。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
従来、自然言語コマンドおよび制御を実現する一手法は、事前符号化されたコマンドの静的認識を伴う。例えば、ユーザは、市販の音声テキスト変換プログラムを利用することで、「ｓａｖｅ  ｆｉｌｅ」などの単純なコマンドを使用して事前符号化されたオペレーションを起動することができる。しかし、このようなプログラムは、通常、正確なコマンドが使用されない限り、そのようなコマンドを処理することができない。言い換えると、「ｓｔｏｒｅ  ｆｉｌｅ（ファイルを保存する）」は、コマンド「ｓａｖｅ  ｆｉｌｅ」を認識するようにコーディングされたアプリケーションにより適切に理解されない場合があるということである。
【０００４】
同様に、質問／回答型のアプリケーションは、検索および取り出し型の機能を使いやすくするために事前符号化された語句または用語を含むのが普通である。しかし、従来の実装では、成功させるために発話または文章内で特定の検索語を使用する必要があり、その結果として、人間の話し言葉の豊富な内容を十分に扱い切れない。
【０００５】
自然言語アプリケーションのプログラミングは、極めて難しい。通常、プログラマは、コンピュータ言語でコーディングする方法を知っているが、文の構造を図式化すること、および／または言語解析を実行することについてはほとんど経験がない。このような経験不足が、自然言語アプリケーションのプログラミングを困難にしているのである。さらに、英語用にコーディングされている自然言語ソフトウェアアプリケーションを他の言語と連携するよう拡張するには、ソフトウェアアプリケーションのコーディングし直しだけでなく、関連する言語解析エンジンのコーディングし直しも必要である。このため、自然言語アプリケーションのプログラミングは極めて困難になり、また非常に費用のかかる作業となる。
【課題を解決するための手段】
【０００６】
一態様では、自然言語ソフトウェアアプリケーションをプログラミングするためのソフトウェア開発ツールが実現される。ソフトウェア開発ツールは、プログラミング言語およびコンパイラを含む。プログラミング言語は、自然言語プログラミングを手助けする一組のプログラミング構文を備える。コンパイラは、一組のプログラミング構文の複数のインスタンスを含むソフトウェアプログラムを受け取って、１つのソフトウェアアプリケーションを生成するように適合されている。
【０００７】
他の態様では、自然言語対応ソフトウェアアプリケーションを作成する方法が実現される。プログラムは、自然言語プログラミングを手助けする一組のプログラミング構文から作成される。このプログラムは、自然言語入力に依存する特徴をソフトウェアアプリケーション内に記述する。プログラムは、コンパイルされて１つのソフトウェアアプリケーションとなる。
【０００８】
他の態様では、言語オブジェクトモデルは、自然言語の意味論的要素をモデル化するように適合される。言語オブジェクトモデルは、言語表現の一組の型とクラスを含み、型はそれらの言語表現をモデル化するように設計されている。一実施形態では、その一組の型の中のそれぞれの型は、発話の意味論的に意味のある要素に対応する。
【０００９】
他の態様では、コンピュータ可読媒体に、自然言語をモデル化するために利用されるコンピュータ可読データ構造を格納する。一組の型は、クラスを抽象オブジェクトとして表現するように適合される。クラスは、自然言語発話の意味論的に意味のある部分に対応しうる、カテゴリ化された言語表現を表す。
【００１０】
他の態様では、自然言語入力の意味論的解釈を生成するためのフレームワークは、インタプリタと一組の型を含む。インタプリタは、クライアントアプリケーションと１つまたは複数の解析エンジンとの間に介在し、クライアントアプリケーションにとって有効な、自然言語入力の複数の解釈を出力するように適合されている。インタプリタと１つまたは複数の解析エンジンとの間の相互作用を定義するように一組の型が適合されている。
【００１１】
他の態様では、クライアントアプリケーションの自然言語機能への自然言語入力の解釈をインスタンス化するフレームワークが実現される。インタプリタは、クライアントアプリケーションに関連付けられた宣言スキーマ（ｄｅｃｌａｒａｔｉｖｅ  ｓｃｈｅｍａ）により初期化される。インタプリタは、自然言語入力を受け取り、１つまたは複数の自然言語解析エンジンと通信し、自然言語入力の解釈を出力するように適合されている。インタプリタは、クライアントアプリケーションにおいて解釈の１つまたは複数をインスタンス化するように適合されている。
【００１２】
他の態様では、コンピュータ上の自然言語入力の意味をモデル化する語彙意味論構造（ｌｅｘｉｃａｌ  ｓｅｍａｎｔｉｃ  ｓｔｒｕｃｔｕｒｅ、語彙意味構造）が実現される。自然言語入力の内容をモデル化するために、一組の語彙意味論カテゴリが選択される。方法論により、自然言語入力の内容を一組の語彙意味論カテゴリのうちの１つまたは複数のカテゴリに関連付ける。別の実施形態では、語彙意味論構造により、複数の言語にまたがって、複数の言語カテゴリにまたがって、複数のアプリケーションにまたがって、および何らかの型の統語的カテゴリを出力するように適合された複数のシステムにまたがって、自然言語入力を正規化する。
【００１３】
他の態様では、自然言語対応ソフトウェアアプリケーションを作成する方法が実現される。プログラムは、自然言語プログラミングを手助けする一組のプログラミング構文から作成される。このプログラムは、自然言語入力に依存する特徴をソフトウェアアプリケーション内に記述する。プログラムは、コンパイルされて１つのソフトウェアアプリケーションとなる。
【００１４】
他の態様では、自然言語対応ソフトウェアアプリケーションを開発するシステムが実現される。解決可能な型により、言語要素の抽象表現および自然言語入力の言語要素間の相互関係を定義する。解決意味論（Ｒｅｓｏｌｕｔｉｏｎ  ｓｅｍａｎｔｉｃｓ）では、自然言語対応ソフトウェアアプリケーションで解決可能な型のインスタンスが有効かどうかを決定する手続き規則を定義する。
【００１５】
他の態様では、自然言語対応ソフトウェアプログラムで解決可能な型のインスタンス化が有効化どうかを決定する方法が実現される。自然言語入力の提案解釈リスト提案解釈がまとめられる。それぞれの提案解釈は、解決可能な型にマッピングされた１つまたは複数のコマンドおよび任意選択による非コマンド要素を持つ。それぞれの提案解釈に関連付けられたインスタンス化が有効化どうかは、その自然言語対応ソフトウェアアプリケーションで決定される。
【発明を実施するための最良の形態】
【００１６】
Ａ．概要
本発明は、言語オブジェクトモデル（ＬＯＭ）、意味論的フレームワーク（ｓｅｍａｎｔｉｃ  ｆｒａｍｅｗｏｒｋ）、および自然言語アプリケーションを作成するための意味論的プログラミング言語（ｓｅｍａｎｔｉｃ  ｐｒｏｇｒａｍｍｉｎｇ  ｌａｎｇｕａｇｅ）（ＳＰＬ）である。ＬＯＭは、使用される自然言語または関係するアプリケーション領域とは無関係に意味論的発話（ｓｅｍａｎｔｉｃ  ｕｔｔｅｒａｎｃｅｓ）をモデル化する。意味論的フレームワークは、（複数の）自然言語解析エンジンとクライアントアプリケーションとの間に介在するランタイムコンポーネント（インタプリタ）、およびシステムのすべてのコンポーネント間の相互作用の性質を定義する一組の型を含む。ＳＰＬは、ＬＯＭおよびＬＯＭで動作するように適合されている自然言語解析エンジンとインターフェースするためのプログラミングフレームワークを提供する。ＳＰＬは、さらに、他の言語オブジェクトモデルとインターフェースする場合にも使用することができる。
【００１７】
本発明は、多数のサブプロセスおよびデータ構造体に加えて、プロセスおよびアーキテクチャ全体を含む。本発明をさらによく理解できるようにするために、本発明で使用することができる１つの環境例を導入する。しかし、本発明は、他の広範にわたるシステムおよび環境でも使用できることは理解されるであろう。
【００１８】
Ｂ．例示されている動作環境
図１は、本発明を実装できる好適なコンピューティングシステム環境１００の一実施例の図である。コンピューティングシステム環境１００は、適当なコンピューティング環境の一例にすぎず、本発明の用途または機能性の範囲に関する制限を示唆する意図はない。コンピューティング環境１００は、動作環境例１００に例示されている１つのコンポーネントまたはその組合せに関係する何らかの依存関係または要求条件がその環境にあるものと解釈すべきでない。
【００１９】
本発明は、他の数多くの汎用または専用コンピューティングシステム環境または構成で動作する。本発明とともに使用するのに適していると思われるよく知られているコンピューティングシステム、環境、および／または構成の例として、限定はしないが、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドまたはラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラム可能な家電製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、電話システム、上記システムまたはデバイスを含む分散コンピューティング環境などがある。
【００２０】
本発明は、コンピュータによって実行される、プログラムモジュールなどのコンピュータ実行可能命令の一般的背景状況において説明することができる。一般に、プログラムモジュールは、特定のタスクを実行する、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。また、本発明は、通信ネットワークを通じてリンクされているリモート処理デバイスによりタスクが実行される分散コンピューティング環境で実施することもできる。分散コンピューティング環境では、プログラムモジュールをメモリ記憶デバイスなどのローカルとリモートの両方のコンピュータ記憶媒体に配置できる。
【００２１】
図１を参照すると、本発明を実装するシステムの実施例は、汎用コンピューティングデバイスをコンピュータ１１０の形で備えている。コンピュータ１１０が備えるコンポーネントとしては、処理ユニット１２０、システムメモリ１３０、およびシステムメモリを備える様々なシステムコンポーネントを処理ユニット１２０に結合するシステムバス１２１などがある。システムバス１２１は、メモリバスまたはメモリコントローラ、周辺機器バス、および様々なバスアーキテクチャのいずれかを使用するローカルバスを含む数種類のバス構造のうちのいずれでもよい。例えば、このようなアーキテクチャとしては、限定はしないが、Ｉｎｄｕｓｔｒｙ  Ｓｔａｎｄａｒｄ  Ａｒｃｈｉｔｅｃｔｕｒｅ（ＩＳＡ）バス、Ｍｉｃｒｏ  Ｃｈａｎｎｅｌ  Ａｒｃｈｉｔｅｃｔｕｒｅ（ＭＣＡ）バス、Ｅｎｈａｎｃｅｄ  ＩＳＡ（ＥＩＳＡ）バス、Ｖｉｄｅｏ  Ｅｌｅｃｔｒｏｎｉｃｓ  Ｓｔａｎｄａｒｄｓ  Ａｓｓｏｃｉａｔｉｏｎ（ＶＥＳＡ）ローカルバス、およびＭｅｚｚａｎｉｎｅバスとも呼ばれるＰｅｒｉｐｈｅｒａｌ  Ｃｏｍｐｏｎｅｎｔ  Ｉｎｔｅｒｃｏｎｎｅｃｔ（ＰＣＩ）バスがある。
【００２２】
コンピュータ１１０は通常、様々なコンピュータ可読媒体を含む。コンピュータ可読媒体は、コンピュータ１１０によってアクセスされることができる媒体であればどのような媒体でも使用可能であり、揮発性および不揮発性媒体、取り外し可能および取り外し不可能媒体を含む。例えば、コンピュータ可読媒体は、限定はしないが、コンピュータ記憶媒体および通信媒体を含むことができる。「コンピュータ記憶媒体」という語句は、コンピュータ可読命令、データ構造体、プログラムモジュール、またはその他のデータなどの情報を格納する方法または技術で実装される揮発性および不揮発性、取り外し可能および取り外し不可能媒体を含むことを意図されている。コンピュータ記憶媒体としては、限定はしないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたはその他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多目的ディスク（ＤＶＤ）またはその他の光ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置またはその他の磁気記憶デバイス、または所望の情報を格納するために使用することができ、しかもコンピュータ１１０によりアクセスできるその他の媒体がある。通信媒体は、通常、コンピュータ可読命令、データ構造体、プログラムモジュール、または搬送波もしくはその他のトランスポートメカニズムなどの変調データ信号によるその他のデータを具現するものであり、任意の情報配信媒体を含む。「変調データ信号」という用語は、信号内の情報を符号化する方法によりその特性のうち１つまたは複数が設定または変更された信号を意味する。例えば（限定ではない）、通信媒体としては、有線ネットワークまたは直接配線接続などの有線媒体、ならびに、音響、ＲＦ、赤外線、およびその他の無線媒体などの無線媒体がある。上記のいずれの組合せもコンピュータ可読媒体の範囲に収まらなければならない。
【００２３】
システムメモリ１３０は、読み取り専用メモリ（ＲＯＭ）１３１およびランダムアクセスメモリ（ＲＡＭ）１３２などの揮発性および／または不揮発性メモリの形態のコンピュータ記憶媒体を備える。起動時などにコンピュータ１１０内の要素間の情報伝送を助ける基本ルーチンを含む基本入出力システム１３３（ＢＩＯＳ）は、通常、ＲＯＭ  １３１に格納される。通常、ＲＡＭ  １３２は、処理ユニット１２０に直接アクセス可能な、および／または処理ユニット１２０によって現在操作されているデータおよび／またはプログラムモジュールを格納する。例えば（限定ではない）、図１は、オペレーティングシステム１３４、アプリケーションプログラム１３５、その他のプログラムモジュール１３６、およびプログラムデータ１３７を例示している。
【００２４】
コンピュータ１１０はさらに、その他の取り外し可能／取り外し不可能な揮発性／不揮発性コンピュータ記憶媒体を備えることもできる。例えば、図１は、取り外し不可能な不揮発性磁気媒体の読み書きを行うハードディスクドライブ１４１、取り外し可能な不揮発性磁気ディスク１５２の読み書きを行う磁気ディスクドライブ１５１、およびＣＤ−ＲＯＭまたはその他の光媒体などの取り外し可能な不揮発性光ディスク１５６の読み書きを行う光ディスクドライブ１５５を例示している。動作環境の実施例で使用できる他の取り外し可能／取り外し不可能な揮発性／不揮発性コンピュータ記憶媒体としては、限定はしないが、磁気テープカセット、フラッシュメモリカード、デジタル多目的ディスク、デジタルビデオテープ、ソリッドステートＲＡＭ、ソリッドステートＲＯＭなどがある。ハードディスクドライブ１４１は、通常、インターフェース１４０などの取り外し不可能なメモリインターフェースを介してシステムバス１２１に接続され、磁気ディスクドライブ１５１および光ディスクドライブ１５５は、通常、インターフェース１５０などの取り外し可能なメモリインターフェースによりシステムバス１２１に接続される。
【００２５】
図１に例示されている上記のドライブおよび関連コンピュータ記憶媒体は、コンピュータ１１０用のコンピュータ可読命令、データ構造体、プログラムモジュール、およびその他のデータを格納する機能を備える。例えば、図１では、ハードディスクドライブ１４１は、オペレーティングシステム１４４、アプリケーションプログラム１４５、その他のプログラムモジュール１４６、およびプログラムデータ１４７を格納するとして例示されている。これらのコンポーネントは、オペレーティングシステム１３４、アプリケーションプログラム１３５、その他のプログラムモジュール１３６、およびプログラムデータ１３７と同じである場合もあれば異なる場合もあることに留意されたい。オペレーティングシステム１４４、アプリケーションプログラム１４５、その他のプログラムモジュール１４６、およびプログラムデータ１４７に対しては、ここで、異なる番号を割り当てて、最低でも、それらが異なるコピーであることを示している。
【００２６】
ユーザは、キーボード１６２、マイク１６３などの入力デバイス、およびマウス、トラックボール、またはタッチパッドなどのポインティングデバイス１６１を介してコンピュータ１１０にコマンドおよび情報を入力できる。他の入力デバイス（図に示されていない）としては、ジョイスティック、ゲームパッド、衛星放送受信アンテナ、スキャナなどがある。これらの入力デバイスやその他の入力デバイスは、システムバスに結合されているユーザ入力インターフェース１６０を介して処理ユニット１２０に接続されることが多いが、パラレルポート、ゲームポート、またはユニバーサルシリアルバス（ＵＳＢ）などの他のインターフェースおよびバス構造により接続することもできる。モニタ１９１またはその他の種類の表示デバイスも、ビデオインターフェース１９０などのインターフェースを介してシステムバス１２１に接続される。モニタのほかに、コンピュータはさらにスピーカ１９７およびプリンタ１９６などの他の周辺出力デバイスも備えることができ、これらは出力周辺インターフェース１９０を介して接続することができる。
【００２７】
コンピュータ１１０は、リモートコンピュータ１８０などの１つまたは複数のリモートコンピュータへの論理接続を使用してネットワーク接続環境で動作することができる。リモートコンピュータ１８０は、パーソナルコンピュータ、ハンドヘルドデバイス、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、またはその他の共通ネットワークノードとすることができ、通常は、コンピュータ１１０に関して説明されている要素の多くまたはすべてを含む。図１に示されている論理接続は、ローカルエリアネットワーク（ＬＡＮ）１７１およびワイドエリアネットワーク（ＷＡＮ）１７３を含むが、他のネットワークを含むこともできる。このようなネットワーキング環境は、オフィス、企業全体にわたるコンピュータネットワーク、イントラネット、およびインターネットでは一般的である。
【００２８】
ＬＡＮネットワーキング環境で使用される場合、コンピュータ１１０は、ネットワークインターフェースまたはアダプタ１７０を介してＬＡＮ  １７１に接続される。ＷＡＮネットワーキング環境で使用される場合、コンピュータ１１０は、通常、インターネットなどのＷＡＮ  １７３上で通信を確立するためモデム１７２またはその他の手段を備える。モデム１７２は、内蔵でも外付けでもよいが、ユーザ入力インターフェース１６０またはその他の適切なメカニズムを介してシステムバス１２１に接続されうる。ネットワーク接続環境では、コンピュータ１１０またはその一部に関して示されているプログラムモジュールは、リモートメモリ記憶デバイスに格納されうる。例えば（限定しない）、図１には、リモートアプリケーションプログラム１８５がリモートコンピュータ１８０上に常駐するように例示されている。図に示されているネットワーク接続は実施例であり、コンピュータ間の通信リンクを確立するのに他の手段が使用可能であることは理解されるであろう。
【００２９】
Ｃ．ＳＰＬフレームワークの概要
ＳＰＬフレームワークは、ランタイムコンポーネント（インタプリタ）および一組の型からなる。ランタイムコンポーネントは、クライアントアプリケーションと１つまたは複数の自然言語解析エンジンとの間に介在する。この一組の型により、システム内のすべての要素間の相互作用を定義する。ＳＰＬフレームワークを使用するアプリケーションでは、実行時にインタプリタインスタンスが作成され、自然言語入力に依存する、クライアントアプリケーション内の機能の意味論的モデルを記述する宣言スキーマにより初期化される。この宣言スキーマは、アプリケーションコードとともに開発者により作成され、開発者により作成され、ＬＯＭ内の型から派生した多数の意味論的モデリング型の間の関係を記述する。これらの意味論的モデリング型は、宣言スキーマ内では参照されておらず、インタプリタによりインスタンス化された場合に、実行時文脈駆動制約（ｒｕｎｔｉｍｅ−ｃｏｎｔｅｘｔ−ｄｒｉｖｅｎ  ｃｏｎｓｔｒａｉｎｔｓ）をそれらの型のインスタンス化に課す手続きコードを含むことができる。
【００３０】
図２は、本発明の一実施形態による意味論的フレームワークのブロック図である。意味論的フレームワーク２００は、ＳＰＬクライアントアプリケーション２０２、ＳＰＬインタプリタアプリケーション２０４、および複数の解析エンジン２０６を備える。一般に、ＳＰＬクライアントアプリケーション２０２はテキスト入力を受け付け、テキスト入力は、ユーザによって（キーボードまたはその他の入力デバイスなどを介して）直接入力することができるか、または音声認識システム２０８またはテキスト認識システム２１０から受け取ることができる。
【００３１】
音声認識システム２０８は、オーディオ入力を受け取り、オーディオ入力を表すテキスト出力を生成するシステムである。テキスト認識システム２１０は、手書きまたはスキャンされた入力を受け取り、その手書きまたはスキャンされた入力を表すテキスト出力を生成するシステムである。一実施形態では、音声認識システム２０８および手書き文字認識システム２１０は、クライアントアプリケーション２０２に組み込まれている。
【００３２】
フレームワーク２００では、テキスト入力２１２文字列は、ＳＰＬクライアントアプリケーション２０２に入力される。テキスト入力２１２Ａは、音声認識システム２０８から出力されたテキストを参照する。テキスト入力２１２Ｂは、手書き文字認識システム２１０から出力されたテキストを参照する。テキスト入力２１２Ｃは、キーボード、メモリバッファ、またはその他の入力ソースなどからのその他のテキスト入力を表す。これ以降、参照番号２１２は、ソースとは無関係に、受け取ったテキスト入力に適用される。
【００３３】
ＳＰＬクライアントアプリケーション２０２は、ＳＰＬクライアントアプリケーションのテキスト入力２１２およびアプリケーションスキーマ２１４をＳＰＬインタプリタアプリケーション２０４に受け渡す。ＳＰＬインタプリタアプリケーション２０４は、テキスト入力２１２およびアプリケーションスキーマ２１４を複数の自然言語解析エンジン２０６（ボックス「解析エンジン１」から「解析エンジンＮ」として示されている）に渡すが、それぞれ、発話を言語オブジェクトモデル（ＬＯＭ）２１６にマッピングするように設計されている。解析エンジン２０６はいくつでも採用でき、それぞれのエンジン２０６は、テキスト入力２１２をＬＯＭ  ２１６およびアプリケーションスキーマ２１４にマッピングするために独自の解析戦略を使用することができる。
【００３４】
一般に、それぞれの解析エンジン２０６はそのパラダイムをテキスト入力２１２に適用し、テキスト入力２１２をＬＯＭ  ２１６にマッピングして、ＳＰＬインタプリタアプリケーション２０４に返される、複数の潜在的解釈２１８を出力する。ＳＰＬインタプリタアプリケーション２０４は、１つまたは複数の実際の解釈２２０を識別して、それらの実際の解釈２２０を、その後１つまたは複数の実際の解釈２２０に基づいて動作することが可能なＳＰＬクライアントアプリケーション２０２に返す。
【００３５】
一実施形態では、解析エンジン２０６は、可能な解釈２１８を１つだけ導出するが、ほとんどの意味論的発話では、複数の解釈が可能であり、これは、発話の文脈に関してインタプリタ２０４またはクライアントアプリケーション２０２により解決可能である。この場合、文脈は、ＳＰＬクライアントアプリケーション２０２およびそれがサポートするオブジェクトの領域である。ＳＰＬインタプリタ２０４は、ＳＰＬクライアントアプリケーション２０２から宣言スキーマ２１４を受け取った後、宣言スキーマ２１４と突き合わせて潜在的解釈２１８を解決しようと試みる。ＳＰＬインタプリタアプリケーション２０４は、宣言スキーマ２１４と突き合わせて解決できない潜在的解釈２１８を破棄することができる。残りの解釈（宣言スキーマ２１４と突き合わせて解決できる解釈）が、実際の解釈２２０である。ＳＰＬインタプリタ２０４は、クライアントアプリケーション２０２で実際の解釈オブジェクト２２０を呼び出すことによりＳＰＬクライアントアプリケーション２０２の宣言スキーマ２１４に応じて複数の実際の解釈２２０のそれぞれをインスタンス化しようと試みる。
【００３６】
フレームワーク２００の実装および構成に応じて、ＳＰＬクライアントアプリケーション２０２からＳＰＬインタプリタアプリケーション２０４に制御２２２が渡され、ＳＰＬインタプリタアプリケーション２０４にさらに処理を実行させるよう命令することができる。同様に、インタプリタアプリケーション２０４は、制御２２４を解析エンジンに渡して、ＬＯＭ  ２１６に関してテキスト入力２１２の処理をさらに行うようにできる。したがって、意味論的フレームワーク２００は、テキスト入力を繰り返し処理し、ＳＰＬクライアントアプリケーション２０２の領域内で定義されているタイプに対応する実際の解釈に到達するようにできる。
【００３７】
一般に、ＳＰＬクライアントアプリケーション２０２、インタプリタ２０４、および解析エンジン２０６は、単一コンピュータ内に配置することができる。他の実施形態では、アプリケーション２０２、インタプリタ２０４、およびエンジン２０６は、ネットワーク上の別のサーバなどの異なるシステム上に配置することができる。
【００３８】
ＳＰＬインタプリタ２０４は、クライアントアプリケーション２０２と解析エンジン２０６との間に介在する機能として使用される。ＳＰＬプログラミング言語は、開発者にとって直観的に理解できることを意図されている。一実施形態では、言語はＣ＃の上に構築されているため、構文は開発者にとっては馴染みやすいであろう。しかし、ＳＰＬは、ＬＯＭ意味論的構造を表現し、言語解析を実行するように適合されており、Ｃ＃で直接、または他のオブジェクト指向プログラミング言語で、実装することが可能である。
【００３９】
すでに述べたように、ＳＰＬフレームワークは、（複数の）自然言語解析エンジン２０６と、開発者により作成され、ＬＯＭで定義されている型から派生された一組の型との間に介在するランタイムコンポーネント（ＳＰＬインタプリタ２０４）を含む。この一組の型により、フレームワークのすべてのコンポーネント間の相互作用の性質を定義する。
【００４０】
ＳＰＬフレームワークでは、自然言語解析エンジンを利用するが、自然言語解析エンジンを含んではいない。これは、複数の解析エンジンが必要ならば同時に使用できるように設計されているのである。例えば、特定の種類の自然言語入力では一方のいくつかのエンジンのほうが他方のエンジンよりも都合がよい場合があるため、複数の解析エンジンを採用したいこともありえる。複数のエンジンの複数の出力を組み合わせると、パフォーマンスおよび動作全体が改善されることがある。
【００４１】
所定の自然言語入力２１２に対し、解析エンジン２０６は、宣言スキーマ２１４で記述されている型のシステムで表現された言語的に可能な解釈２１８をインタプリタ２０４に供給することが予期される。解析エンジン２０６は、一般的に、実際の型ではなく、宣言スキーマ２１４による意味論的型の記述にアクセスする。実際のオブジェクトを出力するのではなく、実際の解釈２２０を構築する命令の集まりである潜在的解釈（２１８）を出力する。解析エンジン２０６により出力される潜在的解釈２１８は、インタプリタ２０４が解釈のインスタンスを作成するのに成功した場合のみ実際の解釈２２０となり、その場合、これは関連する型の手続きコードを実行することを含む。インタプリタ２０４は、宣言スキーマ２１４と突き合わせて可能な解釈２１８を解決しようと試み、特定の実装に応じて、クライアントアプリケーション２０２で解決に成功した解釈をインスタンス化し、さらに処理を行う。
【００４２】
クライアントアプリケーション２０２、インタプリタ２０４、および解析エンジン２０６（テキスト入力２１２、宣言スキーマ２１４、潜在的解釈２１８、実際の解釈２２０、および制御フロー２２２および２２４を含む）の間を行ったり来たりすることにより、コンフリクトおよび／または曖昧さが分離される。フレームワークおよびＬＯＭの連携により、プログラマは、言語解析ではなくアプリケーション領域に自由に関心を持つことができる。
【００４３】
一般に、宣言スキーマは、ＸＭＬコード、Ｍｉｃｒｏｓｏｆｔ  ．ＮＥＴ属性、またはＭｉｃｒｏｓｏｆｔ  ．ＮＥＴ属性および解決可能な型自体とすることができる。代替として、「リフレクション」を使用して型からスキーマ情報が推論されるように解決可能な型をコーディングすることもできる。リフレクションとは、クラスまたはオブジェクトに対し、どのようなメソッド、フィールド、コンストラクタなどが定義されているかを決定する機能のことである。リフレクションにより、動的プログラムを作成することが可能になる。
【００４４】
フレームワークが導入されているのだから、開発者が自分のアプリケーション特有の一組の型の派生元となりうる基礎の言語オブジェクトモデルを理解することが重要である。言語オブジェクトモデルは、自然言語アプリケーション開発目的に有用であるだけでなく、どのような目的であっても自然言語意味解析システムを直接対話形式で操作するために使用することができる。
【００４５】
Ｄ．言語オブジェクトモデル（ＬＯＭ）
Ｄ１．概要
本発明の言語オブジェクトモデル（ＬＯＭ）は、アプリケーション領域またはさらには言語と無関係な、一組の型で構成される。本発明は、言語表現の一組の型とクラスを含み、型はそれらの言語表現をモデル化するように設計されている。これらの型は、ＬＯＭの宣言要素である。
【００４６】
本発明のアプリケーションを実装できる方法はいくつもあり、また特定の実装の詳細は本明細書で取り上げている実施例と異なる場合があることは理解されるであろう。しかし、以下で述べる実施例は、説明を目的としており、制限することを意図していると決して解釈すべきではない。適宜、本発明の用途の広さと堅牢さをさらに説明するため、他の方法またはフレームワークの変更形態を示すこともある。
【００４７】
一般に、ＬＯＭでは、領域に依存しない方法で発話（話の内容または書いた内容）の意味論をモデル化する。「領域」という用語は、本明細書では、自然言語処理要求を発したＳＰＬクライアントアプリケーションを指す。本明細書で使用されているように、「意味（論）」という用語は、話されたまたは書かれた単語の意味または意義を指す。「発話」という用語は、言語エンジンが意味論的に解析しようと試みる、ソフトウェアエンジンにより検出された有限な音または音列および／または書かれた単語または語句を指す。本明細書で使用されているような「構文」という用語は、単語、語句、表現、およびその他の認識可能構文要素を形成するために言語内の記号を組み合わせる方法を定義する文法または構造物規則を指す。
【００４８】
ＬＯＭ型は、発話の要素を言語表現のクラスにマッピングするためにソフトウェアアプリケーションによりアクセス可能である。わかりやすくするため、以下の説明では、ＬＯＭ型から言語表現のクラスへのマッピングを主に取りあげる。しかし、マッピングはＬＯＭ型から言語表現のクラスへの、またその逆の方向への、全二重（双方向）マッピングであることは理解されるであろう。このマッピングの両方の方向が、様々なタスクについて重要である。さらに、ＬＯＭ自体は言語独立であり、異なる言語をモデル化する際にＬＯＭに対しコード変更を加える必要がないことも理解されるであろう。その代わりに、そのような言語特有のコード変更は、クライアントアプリケーションではなく、解析エンジンで行われる。
【００４９】
一般に、ＬＯＭでは、言語を一組の組み立てブロックとして抽象的に規定する。ＳＰＬアプリケーションは、この組み立てブロックフレームを使用して、領域依存の形で語彙意味論構造および解析エンジンにアクセスする。最後に、ＬＯＭは、動作にアプリケーションスキーマを必要としないことも理解されるであろう。ＬＯＭは、発話をモデル化するために使用することができ、解析エンジンは、アプリケーションスキーマに無関係のＬＯＭマッピングを実現できる。したがって、ＬＯＭは、解析エンジンの内側にあるとみなすことができ、ＬＯＭは、自然言語を意味論的に表現するための一手段である。解析エンジンでは、所定の発話に対して正しいＬＯＭ表現はどのようであるかを決定し、発話をＬＯＭに効果的にマッピングする。
【００５０】
図３は、本発明の一実施形態による図２のシステムの解析コンポーネント３００の簡略化されたブロック図である。解析エンジン３０２は、フロー制御３０４、アプリケーションスキーマ３０６、およびテキスト入力３０８を受け取る。ＬＯＭ  ３１０を使用することで、解析エンジン３０２は、テキスト入力３０８をアプリケーションスキーマ３０６にマッピングし、１つまたは複数の潜在的解釈３１２を出力するが、これは、ＳＰＬインタプリタまたは、アプリケーションスキーマ３０６の送り元のクライアントアプリケーションにより解決できる。
【００５１】
一般に、可能な解釈３１２は、ＬＯＭオブジェクトとして表される、特定の型の単なるオブジェクトにすぎない。解析エンジン３０２は、さらに、ＬＯＭオブジェクトをアプリケーションスキーマの対応するオブジェクトにマッピングしてから、可能な解釈を、実装に応じてインタプリタまたはクライアントアプリケーションに返す。
【００５２】
ＬＯＭの構造を詳細に説明する前に、ここで意味論的プログラミング言語により使用される基本型を少なくともおおざっぱに説明しておくと都合がよい。一般に、意味論的プログラミング言語は、様々な意味論的オブジェクトモデルに対し作用するが、ＬＯＭの構造で動作するように特に最適化されている。このときに、ＬＯＭは、プログラミングの理解しやすさ（アプリケーション開発者の観点から）と言語対象範囲（つまり、コマンドおよび制御、質問回答などのアプリケーションシナリオに必要なモデル要素）との間の最もよい妥協を実現する特定の意味論的オブジェクトモデルである。
【００５３】
Ｄ２．意味論的プログラミング言語の型
意味論的プログラミング言語（これ以降、「ＳＰＬ」と呼ぶ）は、ソフトウェアアプリケーション開発者が自然言語プログラムを実装することを支援することを意図されている。ほとんどの開発者は意味解析または言語学の専門家ではないため、ＳＰＬは、非言語学者開発者が非常に直観的な方法で自然言語意味論を取り扱えるようにフレームワークおよびプログラミング言語を備えている。
【００５４】
ＳＰＬおよび随伴するコンパイラは、ＬＯＭに対する自然言語クライアントアプリケーションのプログラミングを容易にする。ＳＰＬは、言語フレームワークの基礎的内容の多くを隠し、フレームワークを対話形式で適切に操作するコードを開発者が簡単に作成できるようにしている。
【００５５】
ＳＰＬはフレームワークを使用する開発者向けの標準フロントエンドとすることができるが、ＳＰＬは必要ない。開発者は、様々なフレームワークインターフェースを実装する型を作成すること、様々なフレームワークインターフェースを実装する型から継承すること、およびアプリケーションスキーマをインタプリタに供給することにより、直接フレームワークをターゲットとすることができる。その代わりに、これは、例えばビジュアルフォームベースのデザインツールであるかのように、フレームワーク互換コードをオーサリングする他の手段などにより間接的に行うこともできる。
【００５６】
一般に、ＬＯＭは、ＳＰＬのクラスライブラリとして実装される。これは、Ｃ  Ｒｕｎｔｉｍｅ  ＬｉｂｒａｒｙおよびＳｔａｎｄａｒｄ  Ｔｅｍｐｌａｔｅ  Ｌｉｂｒａｒｙ（ＳＴＬ）が、例えば、ソフトウェア開発を手助けする、ワシントン州レッドモンドのＭｉｃｒｏｓｏｆｔ  Ｃｏｒｐｏｒａｔｉｏｎにより作成された、Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｖｉｓｕａｌ  Ｃ＋＋（登録商標）の標準ライブラリを形成するのと類似の方法である。「Ｍｉｃｒｏｓｏｆｔ（登録商標）」および「Ｖｉｓｕａｌ  Ｃ＋＋（登録商標）」という用語は、ワシントン州レッドモンドのＭｉｃｒｏｓｏｆｔ  Ｃｏｒｐｏｒａｔｉｏｎが所有する商標である。
【００５７】
ＳＰＬで意味論的に意味のある型は、入ってくる発話の意味論のモデリングおよび入ってくる発話が対応するアプリケーションコマンドのモデリングに関与する型である。意味論的に意味のある型は、ＳＰＬ作成者が、そのアプリケーション領域から派生させ、そのアプリケーション領域に特化させることができる型である。ＳＰＬの意味論的に意味のある型は、Ｅｎｔｉｔｉｅｓ、Ｆｒａｍｅｓ、Ｒｅｓｔｒｉｃｔｉｏｎｓ、Ｃｏｍｍａｎｄｓ、およびＤｅｎｏｔｅｒ  Ｏｂｊｅｃｔｓである。ＳＰＬの関数型は、ＰｈｒａｓｅｓとＳｌｏｔｓである。これらの型のそれぞれについて、以下で個別に説明する。
【００５８】
一般に、ＳＰＬフレームワークの型は、クライアントアプリケーション、ＳＰＬインタプリタ、および１つまたは複数の自然言語解析エンジンの間の相互作用のすべての態様を定義する。「相互作用のすべての態様」という語句は、様々なコンポーネントが実装しなければならないインターフェース、様々なコンポーネントが継承する基本クラス、およびシステムのコンポーネント間で受け渡されるデータの型を指す。一実施形態では、フレームワークの型は、ワシントン州レッドモンドのＭｉｃｒｏｓｏｆｔ（登録商標）Ｃｏｒｐｏｒａｔｉｏｎにより作成されたフレームワークである、ＮＥＴ  Ｆｒａｍｅｗｏｒｋの型として実装される。ＳＰＬの型は、複数の名前空間内に配列されるようにできる。一実施形態では、ＳＰＬの型は、複数の名前空間内に配列され、これらはすべて、例えばＳｙｓｔｅｍ．ＮａｔｕｒａｌＬａｎｇｕａｇｅＳｅｒｖｉｃｅｓまたはＳｙｓｔｅｍ．ＮａｔｕｒａｌＬａｎｇｕａｇｅ名前空間の部分名前空間である。本明細書で使用されているように、「名前空間」とは、名前（識別子）が定義されている文脈のことである。所定の名前空間内では、すべての名前は一意でなければならない。
【００５９】
わかりやすくするため、以下の説明では、ＳＰＬの型を紹介し、ＬＯＭを詳細に紹介し、そしてＳＰＬの詳細説明に戻る。本文全体を通して、例を使用し、適宜発明をこれにより説明する。大部分、実施例は、単一の自然言語発話「Ｓｅｎｄ  ｍａｉｌ  ｔｏ  Ｂｏｂ」から派生している。この発話が与えられると、ＬＯＭに従って、ＳＰＬを使用して書かれたアプリケーションは、テキスト入力に基づいて解釈を生成することができる。その後、生成された解釈は、自然言語アプリケーションと突き合わせて解決され、それにより、命令の実際の解釈が識別され、実行されうる。
【００６０】
Ｅｎｔｉｔｙは、型Ｅｎｔｉｔｙのオブジェクトであり、エンティティがデータメンバ、プロパティ、およびメソッドを含むことができることを意味する。ＳＰＬ  Ｅｎｔｉｔｉｅｓは、クラスＥｎｔｉｔｙから派生した型を持つオブジェクトであり、主に、名詞句および形容詞句の意味論をモデル化するために使用される。ＳＰＬ  Ｅｎｔｉｔｙは、「ｗｉｔｈ」構文を使ってフレームまたは制約（両方とも後述）をホスティングすることができる。さらに、ＳＰＬ  Ｅｎｔｉｔｙは、型「Ｄｅｎｏｔｅｒ」（後述）の特権付きデータメンバを導入する、オプションの「Ｄｅｎｏｔｅｄ  Ｂｙ」句を含むことができる。「Ｄｅｎｏｔｅｄ  Ｂｙ」句により導入される、特権付きデータメンバは、ＳＰＬインタプリタにより、エンティティを実際の自然言語単語にマッピングするために使用されうる。
【００６１】
Ｆｒａｍｅは、クラスであり、意味論イベントの意味論をモデル化し、その際に、意味論イベントを動詞または名詞として表現することができる。ＳＰＬフレームは、Ｆｒａｍｅから派生するクラスである。一般に、Ｆｒａｍｅｓは、Ｅｎｔｉｔｉｅｓに適用することができるため、Ｆｒａｍｅは、「Ｄｅｎｏｔｅｄ  Ｂｙ」句を持つだけでなく、フレーム項を含む「スロット」のリスト（後述）も持つことができる。さらに、Ｆｒａｍｅｓは、「ｗｉｔｈ」構文を介して制約をホスティングすることができる。一実施形態では、新しいＦｒａｍｅ型を作成するために、開発者によりＦｒａｍｅに対する見出し語が定義されるようにできる。他の実施形態では、開発者は既存のフレームを継承し、所望の見出し語を継承から派生させる。他の実施形態では、開発者は、表記（ｄｅｎｏｔｅｒｓ）の規定方法に似た方法で見出し語を規定することができる。
【００６２】
Ｒｅｓｔｒｉｃｔｉｏｎｓは、一般に、斜格項（ｏｂｌｉｑｕｅ  ａｒｇｕｍｅｎｔｓ）、修飾語句、およびその他の意味論的要素をモデル化する。ＳＰＬ制約は、クラスＲｅｓｔｒｉｃｔｉｏｎから派生するクラスである。制約は、フレームのように、項を含むスロットのリストを持つ。さらに、ＳＰＬ  Ｒｅｓｔｒｉｃｔｉｏｎｓは、「ｗｉｔｈ」構文を介して他のＲｅｓｔｒｉｃｔｉｏｎｓをホスティングすることができる。
【００６３】
ＳＰＬコマンドは、クラスＣｏｍｍａｎｄから派生するクラスである。コマンドは、純粋に領域依存であり、それらが、関連付けられる特定の自然言語アプリケーションに依存することを意味する。一般に、領域依存コマンドは、入力の意味論をモデル化することに対し何も役割を果たさず、したがって、コマンドはＬＯＭにおいて何の役割も持たない。その代わりに、コマンドはアプリケーション内の作用をモデル化する。
【００６４】
さらに、コマンドは、オプションの「ｕｓｅｓ」句を持ち、これにより、型Ｆｒａｍｅの特権付きデータメンバを導入する。「ｕｓｅｓ」句は、領域独立入力と所望の領域依存作用との間の不可欠なリンクである。
【００６５】
Ｄｅｎｏｔｅｒオブジェクトは、型Ｄｅｎｏｔｅｒの構造体である。実際、ＳＰＬプログラム内の表記として使用される各単語からＤｅｎｏｔｅｒｓの対応するリストへマッピングする語彙が作成されるため、Ｄｅｎｏｔｅｒオブジェクトは、文字列リストを格納する必要はない。自然言語毎に１つのＤｅｎｏｔｅｒオブジェクト（ＥＮＧＬＩＳＨフィールド、ＪＡＰＡＮＥＳＥフィールドなど）がある。Ｄｅｎｏｔｅｒオブジェクトは、エンティティに対するローカライゼーションテーブルとして作用する。コマンドと同様、表記オブジェクトは純粋に領域依存である。しかし、Ｅｎｔｉｔｙは、型Ｄｅｎｏｔｅｒのフィールドを持ち、これは、Ｅｎｔｉｔｙが解析エンジンにより提案された理由を判別するためにＤｅｎｏｔｅｒオブジェクトを調べられるようにすることのみを目的として存在している。
【００６６】
ＳＰＬの関数型は、何らかのモデリング目的に使用される型であるが、特化させることはできない。さらに、他のクラスおよび型は、関数型から派生させることはできない。
【００６７】
関数型「Ｐｈｒａｓｅ」は、何らかの意味論的オブジェクトの基礎となるテキスト文字列入力の一部に関する情報をカプセル化する。型Ｐｈｒａｓｅを使用することで、ソフトウェア開発者は、元の入力文字列の意味論の内部構造化表現からその入力文字列に対しアドホックな操作および調査を実行することができる。
【００６８】
一実施形態では、関数型「Ｓｌｏｔｓ」は、エンティティ、フレーム、制約、または表記オブジェクトを、場合によっては何らかの補助情報とともに保持する型「Ｓｌｏｔ」のオブジェクトである。例えば、相対句内のギャップに対応するスロットは、「ｂａｃｋｒｅｆｅｒｅｎｃｅｓ」とマークされているエンティティを含む。他の実施形態では、Ｅｎｔｉｔｙ、Ｆｒａｍｅ、または他の参照が、スロットが予期される場所に置かれる。さらに他の実施形態では、Ｓｌｏｔオブジェクトは、補助情報とともに省略され、Ｅｎｔｉｔｙ、Ｆｒａｍｅ、または他の参照は、直接使用される。
【００６９】
Ｄ３．ＬＯＭ型
ＳＰＬ意味論モデル構造を定義する型を検討したので、ＬＯＭを詳細に説明することが可能になった。一般に、ＬＯＭ型およびそれらの型によりモデル化された言語表現のクラスは、Ｅｎｔｉｔｉｅｓ、Ｆｒａｍｅｓ、およびＲｅｓｔｒｉｃｔｉｏｎｓを含む。
【００７０】
ａ．ＬＯＭエンティティ
ＬＯＭの観点から、ＳＰＬプログラマの仕事の大部分、たぶん過半数は領域エンティティ型の配列の設計およびそれらの型のそれぞれについての正しいローカライゼーション情報の収集を中心とするが、エンティティは直接的である。多くの場合、「見出し語」という語句は、エンティティの見出し語である。見出し語は、通常、エンティティモデルという語句の統語上の主要部（ｓｙｎｔａｃｔｉｃ  ｈｅａｄ）の辞書見出し語に対応する。辞書見出し語は、単語の異なる形態に対する正準表現を表す。例えば、「ｗａｌｋｓ」、「ｗａｌｋｅｄ」、および「ｗａｌｋｉｎｇ」という用語は、「ｗａｌｋ」という辞書見出し語を共有する。
【００７１】
使用される話し言葉に関係なく、すべての言語の一般的規則は、ＮＰはＬＯＭエンティティになるという規則である。エンティティの見出し語は、ＮＰの主要部名詞の辞書見出し語である。
【００７２】
一般に、エンティティの調整は、「ＣｏｏｒｄｉｎａｔｅｄＥｎｔｉｔｙ」型を介してＬＯＭで表現される。型ＣｏｏｒｄｉｎａｔｅｄＥｎｔｉｔｙのインスタンス化を説明するコードスニペットが、表１に示されている。
【００７３】
表１：ＣｏｏｒｄｉｎａｔｅｄＥｎｔｉｔｙ
【００７４】
【表１】
2005332380.tif 000003
【００７５】
調整に関するＬＯＭのゴールは、意味論的に関係のない、括弧付けの曖昧さを最小限に抑えることである。したがって、例えば、「Ｘ  ａｎｄ  Ｙ  ａｎｄ  Ｚ」というテキスト入力は、「Ｘ  ＡＮＤ  Ｙ  ＡＮＤ  Ｚ」というフラットリストとして表され、右結合「Ｘ  ＡＮＤ［Ｙ  ＡＮＤ  Ｚ］」と左結合「［Ｘ  ＡＮＤ  Ｙ］ＡＮＤ  Ｚ」との間で曖昧さはない。しかし、真の括弧付けの曖昧さがある場合、ＬＯＭは曖昧さを保持する。例えば、「ｓｈｏｗ  ｃａｒｓ  ｗｉｔｈ  ４ＷＤ  ａｎｄ  ＡＢＳ  ｏｒ  ＡＷＤ」という語句の場合、「４ＷＤ  ＡＮＤ［ＡＢＳ  ＯＲ  ＡＮＤ］」と「［４ＷＤ  ＡＮＤ  ＡＢＳ］ＯＲ  ＡＷＤ」の両方の可能性がある。もちろん、この特定の場合に、第２の表現のみが、意味を持ちうるが、それは、ＬＯＭではなく、アプリケーションが決定する。
【００７６】
代名詞は、ＬＯＭでは、型「ＰｒｏｎｏｕｎＥｎｔｉｔｙ」のオブジェクトとしてモデル化される。本発明の一実施形態による代名詞のエンティティのインスタンス化の例を表２に示す。
【００７７】
表２：ＰｒｏｎｏｕｎＥｎｔｉｔｙ
【００７８】
【表２】
2005332380.tif 000004
【００７９】
ＬＯＭは、ＰｒｏｎｏｕｎＥｎｔｉｔｙ内の「ｐｏｔｅｎｔｉａｌＡｎｔｅｃｅｄｅｎｔｓ」フィールドを通じて前方照応解決のためのインターフェースを提供する。「前方照応」という用語は、同じＥｎｔｉｔｙを参照する複数の単語または語句の間の関係を指す。ｐｏｔｅｎｔｉａｌＡｎｔｅｃｅｄｅｎｔｓフィールドは、オプションにより、言語的に可能な先行詞であるすでに解決済みのＥｎｔｉｔｙオブジェクトのリストで埋められる。このリストは、可能性の降順で順位付けられている。言語的呼応情報は、前方照応解決で最も重要なファクタであり、すべてのＥｎｔｉｔｙに付属する型「ＡｇｒｅｅｍｅｎｔＩｎｆｏ」のオブジェクトを通じてアプリケーション開発者によりアクセス可能である。ｓｔｒｕｃｔ  ＡｇｒｅｅｍｅｎｔＩｎｆｏの例が表３に示されている。
【００８０】
表３：ＳＴＲＵＣＴ  ＡｇｒｅｅｍｅｎｔＩｎｆｏ
【００８１】
【表３】
2005332380.tif 000005
【００８２】
所定のエンティティに関して曖昧なところなく真であるＡｇｒｅｅｍｅｎｔＩｎｆｏフィールドのみが、そのエンティティのＡｇｒｅｅｍｅｎｔＩｎｆｏオブジェクトに関連付けられる。つまり、ＬＯＭでは、離接呼応特徴を表すことを試みない。例えば、用語「ｃａｔ」では、「ｔｈｉｒｄＰｅｒｓｏｎ」および「ｓｉｎｇｕｌａｒ」がそのＡｇｒｅｅｍｅｎｔＩｎｆｏオブジェクトに関連付けられるであろう。「ｓｈｅ  ｉｓ」という語句は、そのＡｇｒｅｅｍｅｎｔＩｎｆｏオブジェクトの中の「ｔｈｉｒｄＰｅｒｓｏｎ」、「ｓｉｎｇｕｌａｒ」、および「ｆｅｍｉｎｉｎｅ」に関連付けられる。フランス語では、用語「ｖｏｕｓ」は、「ｓｅｃｏｎｄＰｅｒｓｏｎ」という語に関連付けられる。スペイン語では、「ｐｅｒｒｏ」という用語は、「ｔｈｉｒｄｐｅｒｓｏｎ」、「ｓｉｎｇｕｌａｒ」、および「ｍａｓｃｕｌｉｎｅ」であり、それぞれ、与えられたエンティティｐｅｒｒｏに関して曖昧なところなく真であり、したがって、そのエンティティの呼応オブジェクトに関連付けられる。
【００８３】
独立のＮＰｓとして使用できる「ｔｈｉｓ」および「ｔｈａｔ」などの指示詞は、型ＤｅｍｏｎｓｔｒａｔｉｖｅＥｎｔｉｔｙのオブジェクトになる。エンティティＤｅｍｏｎｓｔｒａｔｉｖｅＥｎｔｉｔｙの例を表４に示す。
【００８４】
表４：ＤｅｍｏｎｓｔｒａｔｉｖｅＥｎｔｉｔｙ
【００８５】
【表４】
2005332380.tif 000006
【００８６】
型「ＤｅｍｏｎｓｔｒａｔｉｖｅＥｎｔｉｔｙ」のオブジェクトは、Ｅｎｔｉｔｙから派生するので、ＡｇｒｅｅｍｅｎｔＩｎｆｏオブジェクトを継承し、したがって「ｔｈｉｓ」および「ｔｈａｔ」のような単語を区別することができる。一般に、この継承により、システムは、英語、フランス語、ドイツ語、日本語、スペイン語、およびその他の多数の言語におけるそのような要素同士を正しく区別する能力を持ちうる。
【００８７】
他の関係する型はＮａｍｅｄＥｎｔｉｔｙ型である。ＮａｍｅｄＥｎｔｉｔｙに対する構文は以下のとおりである。
【００８８】
namedentity OlapNamedEntity uses ExcelAddin.FuzzyOlapCubeRecognizer;
一般に、ＮａｍｅｄＥｎｔｉｔｙ型は、ＮａｍｅｄＥｎｔｉｔｙＲｅｃｏｇｎｉｚｅｒクラスから継承する別々に定義されたクラスに基づく。ＮａｍｅｄＥｎｔｉｔｙＲｅｃｏｇｎｉｚｅｒ型は、スキーマとともに渡されるので、解析エンジンは、それらを使用して、クライアントコード内にコールバックし、発話内のアプリケーションオブジェクト参照を動的に識別することができる。
【００８９】
ｂ．ＬＯＭフレーム
一実装では、すべての言語について、句はＬＯＭ  Ｆｒａｍｅｓとなるが、これは、必ずしもすべての実装について正しいわけではない。概念上、Ｆｒａｍｅは句から出るが、実際には入力内に句が存在している必要はない。フレームの見出し語は、その句の先頭にある動詞の辞書見出し語である。例えば、語句「Ｓｅｎｄ  ｍａｉｌ  ｔｏ  Ｂｏｂ」を解析すると、「ｓｅｎｄ  ｍａｉｌ」はＬＯＭ  Ｆｒａｍｅに関連付けられるが、ただし、「Ｓｅｎｄ」は句の先頭の動詞の辞書見出しであり、したがってフレームの見出し語である。
【００９０】
Ｒｅｓｔｒｉｃｔｉｏｎｓは、既定の動作を定めるとして概念化することができることは理解されるであろう。しかし、このような動作は、必ずしも強制されない。機能は実装に依存する。
【００９１】
Ｓｌｏｔｓは、エンティティまたはフレームで埋めることができ、したがって既定のスロットは名詞句または節とすることができる。さらに、ＮＰｓは、空の代名詞（ＰＲＯ）を主要語とすることができる。ＰＲＯが他の節内の指示対象を指している場合、その節の主要語はＮＰエンティティの主要語と解釈される。ＰＲＯが指示対象を持たない場合、何らかのエンティティとして解釈される（誰かまた何かなど）。
【００９２】
一実施形態では、その節に含まれる主語があると仮定すると、その節の主題は「Ｄｏｅｒ」制約を埋める。主題がない場合、「Ｄｏｅｒ」制約はない。「Ｄｏｅｒ」は、事象への第１の関与部分を表し、意味論は行為者、動作主、主体、扇動者、または動詞によって指定された事象または状態の原因として大まかに記述される。節の一部がフレームの「Ｄｏｅｒ」制約にマッピングされる動詞節の例が以下の表５に示されている。
【００９３】
表５：主語を持つ動詞節
Instant message opens.
Robin is on my buddies list.
Amazon offers wish list capabilities.
[PRO] open the file
Having a program associated with a file ensures easy opening.
下線の引いてある単語または語句は、Ｄｏｅｒスロットにマッピングされる単語または語句である。これは、他動詞および自動詞の両方のフレームで真であり、他動詞および自動詞に対応する。
【００９４】
句内に目的語がある場合、その目的語はイベント内の第２の統語的関与部分を表す「ＤｏｎｅＴｏ」制約と呼ばれるフレームの第２のスロットにマッピングされる。その意味論は動詞によって指定された事象または状態の影響を受ける目的語を指すと、大まかに理解できる。表６の下線付きの語句は、「ＤｏｎｅＴｏ」制約にマッピングされる。
【００９５】
表６：「ＤｏｎｅＴｏ」制約
Outlook has my buddies list.
Amazon offers wish list capabilities.
[PRO] open the file.
Preferences include having a program associated with a file.
一実装では、間接目的語は、作用の受益者（ｂｅｎｅｆｉｃｉａｒｉｅｓ  ｏｆ  ｔｈｅ  ａｃｔｉｏｎ）であると考えることができる。一実施形態では、間接目的語は、Ｂｅｎｅｆｉｃｉａｒｙ制約にマッピングすることができる。Ｂｅｎｅｆｉｃｉａｒｙ制約は、一般に、事象が代理によって実行された人を表現する動詞項（ｖｅｒｂａｌ  ａｒｇｕｍｅｎｔｓ）をモデル化する。受益者スロットは、表７に含まれる下線付きの代名詞により簡単に説明される。
【００９６】
表７：受益者スロット
Open me a new file.
Play her some tunes
Ｂｅｎｅｆｉｃｉａｒｙ制約（または他の実施形態では、「スロット」）は、受益者として解釈される名詞句をモデル化するエンティティに設定することができる。表８は、受益者制約のコードブロックを例示している。
【００９７】
表８：Ｂｅｎｅｆｉｃｉａｒｙ制約
【００９８】
【表５】
2005332380.tif 000007
【００９９】
受益者制約は、「受益者格」と呼ばれることもあり、特に、「ｆｏｒ」前置詞句の単数目的語について英語での割り当てとオーバーラップする。一部のオーバーラップは、他の言語でも生じることがある。フレームに適用された場合、受益者制約は、以下の文から明白である。
【０１００】
I baked a cake for my mother.
PP [for]
一般に、受益者制約は、ほとんどの言語において動詞項をモデル化する。表９は、いくつかの言語例における受益者制約を例示している。
【０１０１】
表９：Ｂｅｎｅｆｉｃｉａｒｙ制約
【０１０２】
【表６】
2005332380.tif 000008
【０１０３】
一般に、制約は、主語、直接目的語、間接目的、斜格項、修飾語句などとすることができる。ＳＰＬでは、フレームは、任意の制約をとりうる（下記の例外がある）。しかし、ＬＯＭは、文法を使用して、２つの点で制約を優先する。まず第１に、斜格項は、動詞がメンバである語彙意味論構造クラスに関連付けられた制約型とすることができる（これについては、以下で詳述する）。第２に、斜格項は、個別動詞と変わった形で関連付けられることがある、つまり、項は、その節主要部との制約関係を持たない。これらの項は、既定の制約（後述）に割り当てられ、その語彙的主要部により識別される。
【０１０４】
フレームの調整は、文脈に応じて２通りの方法で実行される。「最高レベル」の調整フレーム（つまり、母型動詞に由来する）は、ＣｏｏｒｄｉｎａｔｅｄＥｎｔｉｔｙ（上述）と並列の、型ＣｏｏｒｄｉｎａｔｅｄＦｒａｍｅのオブジェクトとして表される。参考例を以下の表１０に示す。
【０１０５】
表１０：ＣｏｏｒｄｉｎａｔｅｄＦｒａｍｅ
【０１０６】
【表７】
2005332380.tif 000009
【０１０７】
一般に、エンティティ上に現れるフレーム（「ｗｉｔｈ」構文を介して）は制約として振る舞う。後述のように、これは、接続詞は複数の制約をトリガすることにより表現されるが、離接的接続詞は、ホストエンティティをＣｏｏｒｄｉｎａｔｅｄＥｎｔｉｔｙに展開することにより表現されることを意味する。
【０１０８】
すでに説明したように、一実施形態では、Ｆｒａｍｅｓは、自然言語の関係詞節をモデル化するためにエンティティに対する制約として使用されることができる。フレームが「ｗｉｔｈ」キーワードを介してエンティティに付けられた場合、このフレームは、エンティティに制約を課し、これを「フレームベースの制約」と呼ぶ。大半のケースで、フレーム内の１つのスロットは、主要部名詞により束縛された自然言語のギャップに対応する。ＬＯＭでは、これは、スロットの１つのホストエンティティへの参照を受け取るフレームベースの制約に翻訳される。フレームベースの制約のスロットにホストエンティティへの参照を含めることを、「後方照応」と呼ぶことができる。そのような「後方照応」では他の手段ではツリー状のＬＯＭ表現への再入が可能なので、ギャップに対応するスロットでは、そのｉｓＢａｃｋｒｅｆｅｒｅｎｃｅフラグが真に設定される。（このフラグは、ＬＯＭ表現を辿るプロセスのための単なる便宜として用意されている）。例えば、以下の表１１では、フレームベースの制約は、「ｆｉｌｅｓ  ｔｈａｔ  Ｂｉｌｌｙ  ｏｐｅｎｅｄ  ｙｅｓｔｅｒｄａｙ」という語句と突き合わせて解決される。
【０１０９】
表１１：フレームベースの制約
【０１１０】
【表８】
2005332380.tif 000010
【０１１１】
表１２では、フレームベースの制約は、「ｐｅｏｐｌｅ  ｗｈｏ  ｗｏｒｋ  ａｔ  Ｃｏｍｐａｎｙ」という語句と突き合わせて解決される。
【０１１２】
表１２：フレームベースの制約
【０１１３】
【表９】
2005332380.tif 000011
【０１１４】
表１３では、フレームベースの制約は、「ｐｅｏｐｌｅ  Ｉ  ｈａｖｅ  ｓｅｎｔ  ｍａｉｌ  ｔｏ」という語句と突き合わせて解決される。
【０１１５】
表１３：フレームベースの制約
【０１１６】
【表１０】
2005332380.tif 000012
【０１１７】
フレームベースの制約により導入される再入により、ＳＰＬの解決プロセスに困難が生じることに留意することが大切である。特に、エンティティは、すべての制約が完全に処理されるまで完全には解決されない（したがって、ＳＰＬでは、技術的には「存在」しない）。しかし、エンティティの制約の１つは、そのスロットの１つの中のエンティティ自体を受け取るフレームとすることができる。したがって、フレームを定義するコードによりエンティティオブジェクトを調査する必要があるという状況が発生するが、それでも、フレームの解決が終了した後のある時点までエンティティは未定義状態のままである。この問題については、以下のセクションＥ．４で詳述する。
【０１１８】
他の実施形態では、Ｆｒａｍｅｓは、スロットを持たないが、その代わりに、上述のように「Ｄｏｅｒ」および「ＤｏｎｅＴｏ」制約を使用する。このような場合、新しい制約は、フレームに基づいて定義されることができ、「Ｄｏｅｒ」および「ＤｏｎｅＴｏ」の制約節は、その新しい制約に適用可能である。したがって、制約は、フレーム項を取り扱う代替手段を提示する。以下の説明では、簡単のため、そのような１つの実装のみを参照するが、いずれの実装も適用可能である。
【０１１９】
ｃ．ＬＯＭ制約
エンティティおよびフレームとは異なり、制約の調整は、ＣｏｏｒｄｉｎａｔｅｄＥｎｔｉｔｙおよびＣｏｏｒｄｉｎａｔｅｄＦｒａｍｅなどの「複合」型を使用して表されるわけではない。その代わりに、ＳＰＬの意味論を利用して制約接続詞を表すが、制約離接的接続詞は、エンティティまたはフレーム離接的接続詞に帰着される。
【０１２０】
ＳＰＬは、接続詞または交差意味論（ｉｎｔｅｒｓｅｃｔｉｏｎ  ｓｅｍａｎｔｉｃｓ）を、同じホスト上で順次トリガすることに成功する２つの制約節に割り当て、したがって、制約でモデル化された資料の言語的接続詞は、単に２つ以上の制約を順次トリガすることにより取り扱われる。その一方で、制約によりモデル化された資料の言語的離接的接続詞は、ＳＰＬ意味論では都合のよい片割れを持たない。そこで、このような離接的接続詞は、制約（通常はホスト）の上の次のエンティティまたはフレームまで「バブルアップし」、そのレベルでＣｏｏｒｄｉｎａｔｅｄＥｎｔｉｔｙまたはＣｏｏｒｄｉｎａｔｅｄＦｒａｍｅオブジェクトを引き起こす。
【０１２１】
例えば、「ｍａｉｌ  ｆｒｏｍ  Ｋｉｍ  ｏｒ  ｔｏ  Ｒｏｂｉｎ」という語句の場合、１つのエンティティホスト「Ｅｎｔｉｔｙ（ｍａｉｌ）」と２つの制約「Ｓｏｕｒｃｅ（Ｅｎｔｉｔｙ（Ｋｉｍ））」および「Ｇｏａｌ（Ｅｎｔｉｔｙ（Ｒｏｂｉｎ））」がある。これら２つの制約は、離接的接続詞「ｏｒ」で調整されるため、離接的接続詞はホスト「Ｅｎｔｉｔｙ（ｍａｉｌ）」までバブルアップし、その結果、表１４に例示されているマッピングが得られる。
【０１２２】
表１４：制約調整
【０１２３】
【表１１】
2005332380.tif 000013
【０１２４】
このコードは、Ｅｎｔｉｔｙ（ｍａｉｌ）の２つのコピーを出力する。
【０１２５】
Ａｃｃｏｍｐａｎｉｍｅｎｔ制約は、何らかのグループ内の１つまたは複数の追加メンバをモデル化する。多くの場合、随伴（ａｃｃｏｍｐａｎｉｍｅｎｔ）は、接続詞により言い換えることができる。例えば、「ｃｕｓｔｏｍｅｒｓ  ａｌｏｎｇ  ｗｉｔｈ  ｔｈｅｉｒ  ｂｉｒｔｈｄａｔｅｓ」という語句は、「ｃｕｓｔｏｍｅｒｓ  ａｎｄ  ｔｈｅｉｒ  ｂｉｒｔｈｄａｔｅｓ」と言い換えることができる。ｒｅｃｉｐｒｏｃａｌ−ｅｖｅｎｔ−ｄｅｎｏｔｉｎｇエンティティの場合、随伴制約は、事象への追加関与部をモデル化する。このような名詞語句は、対応するフレームを持つことが多い（例えば、「ｃｏｒｒｅｓｐｏｎｄ」、「ｍｅｅｔ」、「ｃｈａｔ」など）。随伴制約は、さらに、「ｃｏｒｒｅｓｐｏｎｄｅｎｃｅ  ｗｉｔｈ  ｍｙ  ｍａｎａｇｅｒ」、「ａｎ  ａｐｐｏｉｎｔｍｅｎｔ  ｗｉｔｈ  Ｋｉｍ」、「ｍｅｅｔｉｎｇ  ｗｉｔｈ  Ｔｉｍ」（強調が追加される）、「ａ  ｃｈａｔ  ｗｉｔｈ  Ｓｕｅ」などの名詞句内の前置詞句もモデル化する。本発明の一実施形態によるＡｃｃｏｍｐａｎｉｍｅｎｔ制約の構文の例が表１５に例示されている。
【０１２６】
表１５：Ａｃｃｏｍｐａｎｉｍｅｎｔ
【０１２７】
【表１２】
2005332380.tif 000014
【０１２８】
Ａｃｃｏｍｐａｎｉｍｅｎｔ制約も、Ｆｒａｍｅの文脈で追加のｗｈｏまたはｗｈａｔ関与部（ａｄｄｉｔｉｏｎａｌ  ｗｈｏ  ｏｒ  ｗｈａｔ  ｐａｒｔｉｃｉｐａｎｔｓ）をモデル化することができる。例えば、「ｃｈａｔ  ｗｉｔｈ  Ｒｏｂｉｎ」という語句は、語句「ｗｉｔｈ  Ｒｏｂｉｎ」を随伴制約とする「Ｃｈａｔ」フレームを呼び出す。
【０１２９】
随伴制約は、さらに、ホストに随伴すると解釈される名詞句をモデル化するエンティティ内のスロットに割り当てられることができる。そうする代わりに、随伴制約を「ｗｈｏ」または「ｗｈａｔ」スロットに設定することができる。
【０１３０】
いくつかの場合において、意味論的に接続詞と同等である、「ｗｉｔｈ」のケースのリストをエンティティリストとしてコンパイルすることが望ましい場合がある。他の言語にも同等の随伴表現が存在する限り、必要に応じてそれらの表現に対するエンティティリストをコンパイルするのは有益と考えられる。
【０１３１】
随伴としてモデル化することができる所有格に関して、それらをエンティティリストに含めることも望ましい場合がある。例えば、「ｅｍａｉｌ  ｗｉｔｈ  ａｔｔａｃｈｍｅｎｔｓ」は随伴スタイルの所有であるが、それに対して「ｅｍａｉｌ’ｓ  ａｔｔａｃｈｍｅｎｔｓ」は所有者スタイルの所有である。いくつかの場合において、これらは言語的に補完し合う表現として処理することができる。さらに、「ａｎ  ｅｍａｉｌ  ｔｈａｔ  ｈａｓ  ａｔｔａｃｈｍｅｎｔｓ」などの語句も、随伴制約としてモデル化することができる。
【０１３２】
主語相互関係（Ｓｕｂｊｅｃｔ  ｒｅｃｉｐｒｏｃａｌｓ）も、随伴制約に畳み込むことができる。主語相互関係の例は、「Ｊｏｈｎ  ａｎｄ  Ｍａｒｙ  ｃｈａｔｔｅｄ」に対する「Ｊｏｈｎ  ｃｈａｔｔｅｄ  ｗｉｔｈ  Ｍａｒｙ」である。語彙的には、これら２つの表現は容易に識別できる。同様に、「Ｍｅｒｇｅ  Ｆｉｌｅ  Ａ  ｗｉｔｈ  Ｆｉｌｅ  Ｂ」に対する「Ｍｅｒｇｅ  Ｆｉｌｅ  Ａ  ａｎｄ  Ｆｉｌｅ  Ｂ」などの目的語相互関係（ｏｂｊｅｃｔ  ｒｅｃｉｐｒｏｃａｌｓ）も容易に識別可能である。このような主語および目的語相互関係をＬＯＭにおける随伴正規化に組み込むことが望ましいと思われる。
【０１３３】
随伴制約は、多くの言語に拡張され、特に「ａｌｏｎｇ  ｗｉｔｈ」または「ｔｏｇｅｔｈｅｒ  ｗｉｔｈ」などの前置詞句に関して、拡張される。フランス語、ドイツ語、日本語、スペイン語、およびその他の言語では、類似の随伴制約を採用することができる。表１６にこのような随伴を例示する。
【０１３４】
表１６：随伴制約
【０１３５】
【表１３】
2005332380.tif 000015
【０１３６】
表１７に例示されているような割り当て制約では、一般的に、ホストエンティティが分配されるエンティティをモデル化するか、またはホストエンティティの代わりに存在または作成されたエンティティをモデル化する。
【０１３７】
表１７：Ａｌｌｏｃａｔｉｏｎ制約
【０１３８】
【表１４】
2005332380.tif 000016
【０１３９】
割り当て制約（ａｌｌｏｃａｔｉｏｎ  ｒｅｓｔｒｉｃｔｉｏｎ）で、ホストエンティティが分配されるエンティティをモデル化する場合、そのような制約の一例は、「ｏｎｌｉｎｅ  ｐｒｏｆｉｌｅ  ｆｏｒ  ｅａｃｈ  ｆｕｎｄ」、「ｓｃｈｏｏｌｓ  ｆｏｒ  ｌｉｎｇｕｉｓｔｉｃｓ」、または「ａｐｐｌｉｃａｔｉｏｎ  ｆｏｒ  ａ  ｊｏｂ」となるであろう。下線付きの部分は、割り当て制約を示している。割り当て制約で、ホストエンティティの代わりに存在するか、または作成されたエンティティをモデル化する場合、意味論的発話は「ａ  ｃａｋｅ  ｆｏｒ  ｍｙ  ｍｏｔｈｅｒ」または「ｐａｒｔｙ  ｆｏｒ  ｍｙ  ｍａｎａｇｅｒ」としてよいであろう。両方の場合において、割り当て制約は、特異性をエンティティに加える。表１６は、割り当て制約の一実施形態を例示している。割り当て制約は、スロットを使用するホストに割り当てられるとして解釈される名詞句をモデル化するエンティティに設定することができる。
【０１４０】
一般に、割り当て制約は、単数形だけでなく複数形のエンティティへの割り当てにも適用できる。割り当て制約は、英語のＢｅｎｅｆｉｃｉａｒｙと相補分布をなす。ただ１つのエンティティが割り当てのホストとなる。フレームのみが、特に、「ｆｏｒ」前置詞句に対する単数形目的語で受益者のホストとなる。英語では、この前置詞は、様々な形で使用することができる。例えば、「ｐａｃｋｅｔｓ  ｆｏｒ  ａ  ｓｐｅｃｉｆｉｃ  ｄｅｓｔｉｎａｔｉｏｎ」では、これは目的を示すが、「application for which you are enabling authorization checking」では、割り当ての種類である。同様に「ｔａｂｓ  ｆｏｒ  ｔａｓｋｐａｄ  ｖｉｅｗｓ」、「ｃｈｅｃｋｂｏｘ  ｆｏｒ  ｔｈｅ  ｔｙｐｅ  ｏｆ  ｓｅｒｖｉｃｅ」、および「ａｒｅａ  ｃｏｄｅ  ｆｏｒ  Ｍａｄｉｓｏｎ，ＷＩ」はすべて、割り当て制約を表す。ドイツ語では、とりわけ、「ｆｕｒ」が割り当てを表す。スペイン語では、対応する前置詞は、ｐａｒａであり、「ｕｎａ  ｅｓｃｏｂａ  ｐａｒａ  ｌａ  ｃｏｃｉｎａ」という語句は、割り当て制約を示す。
【０１４１】
Ｆｒａｍｅ上の「ＡｓＢｅｉｎｇ」制約は、フレームの目的語スロットに割り当てられたプロパティまたはキャパシティをモデル化する。形容詞句をモデル化する修飾語句のみが制約バージョンにマッピングされる。表１８は、ＡｓＢｅｉｎｇ制約の２つのコードサンプルを示している。
【０１４２】
表１８：ＡｓＢｅｉｎｇ制約
【０１４３】
【表１５】
2005332380.tif 000017
【０１４４】
一般に、ＬＯＭは発話の辞書見出し語の間の意味論的関係をモデル化する。「ＡｓＢｅｉｎｇ」制約では、前置詞句「ａｓ」をモデル化しようと試みる。例えば、「Ｓａｖｅ  ｔｈｅ  ｆｉｌｅ  ａｓ  ａ  ｔｅｘｔ  ｆｉｌｅ」という語句は、「Ｓａｖｅ  ｔｈｅ  ｆｉｌｅ  ｔｏ  ａ  ｔｅｘｔ  ｆｉｌｅ」という語句に類似している。「Ｓｅｔ  ｍｙ  ｓｔａｔｕｓ  ａｓ  ｂｕｓｙ」は、「Ｓｅｔ  ｍｙ  ｓｔａｔｕｓ  ｔｏ  ｂｕｓｙ」に類似している。「ＡｓＢｅｉｎｇ」制約は、フレームの目的語スロットに割り当てられたプロパティまたはキャパシティをモデル化する。ここで、ＡｓＢｅｉｎｇ制約は、フレームの目的語スロットに割り当てられたプロパティである、「ｔｅｘｔ  ｆｉｌｅ」への制約「ａｓ」をモデル化する。そうする代わりに、この機能を、Ｅｎｔｉｔｙではなく、Ｄｅｎｏｔｅｒに適用することも可能であろう。表１９は、英語、ドイツ語、日本語、およびスペイン語でのＡｓＢｅｉｎｇ目的語の例を示している。
【０１４５】
表１９：ＡｓＢｅｉｎｇの例
【０１４６】
【表１６】
2005332380.tif 000018
【０１４７】
基数詞制約は、数量詞で表されるような基数をモデル化する制約である。スロットおよびフィールドは、数量詞の浮動小数点数値に設定することができる。「ａｎ」および「ａ」などの不定冠詞は、場合によっては、「１」としてモデル化されることもある。表２０は、基数制約を例示している。
【０１４８】
表２０：Ｃａｒｄｉｎａｌ制約
【０１４９】
【表１７】
2005332380.tif 000019
【０１５０】
さらに、いくつかの場合には、基数を時間単位（「３時間」など）でブロック化するのが望ましいことがある。特に時間単位に関して、時間量を導入するには、通常、「ｉｎ  ３  ｈｏｕｒｓ」、または「ｆｏｒ  ３  ｍｉｎｕｔｅｓ」などの前置詞句を必要とするため、基数制約をブロック化してもＴｉｍｅ型オブジェクトとコンフリクトすることはないであろう（少なくとも英語では）。表２１は、基数制約にマッピングできる表現の例をいくつか例示している。
【０１５１】
表２２：基数制約を示す表現例
【０１５２】
【表１８】
2005332380.tif 000020
【０１５３】
他の型の制約「Ｃｏｍｐａｒｉｓｏｎ」は、エンティティと他の明示的に示されるエンティティとの比較をモデル化する。Ｃｏｍｐａｒｉｓｏｎ制約の構文は表２３に例示されている。
【０１５４】
表２３：Ｃｏｍｐａｒｉｓｏｎ制約
【０１５５】
【表１９】
2005332380.tif 000021
【０１５６】
比較制約は、比較するエンティティの１つが明示的に参照されていない場合など、暗黙の比較には使用されない。例えば、「ａ  ｂｉｇｇｅｒ  ｆｉｌｅ」は、暗黙の比較を示唆しており、比較制約を呼び出さない。
【０１５７】
比較制約は、次元スロットに適用可能であり、その場合、次元は形容詞句をモデル化する修飾語句制約に設定される。この修飾語句制約は、通常、「程度」制約を持ち、程度フィールドは、例えば、「ｍｏｒｅ」、「ｌｅｓｓ」、または「ｓａｍｅ」に設定される。「ｒｅｆｐｏｉｎｔ」フィールドは、ホストエンティティと比較されるエンティティに設定される。
【０１５８】
特定の実装によっては、比較クラスを明示的に規定する最上級は特別な注意を要することがある。例えば、「ｔｈｅ  ｔａｌｌｅｓｔ  ｇｉｒｌ  ｉｎ  ｔｈｅ  ｃｌａｓｓ」という語句では、「ｃｌａｓｓ」は比較のｒｅｆｐｏｉｎｔとして呼ばれるか、またはその代わりに、「ｃｌａｓｓ」は「ｇｉｒｌ」に関する場所として呼ばれる可能性がある。様々他の最上級表現も、特別な注意を要することがある。例えば、「ｍｙ  ｄａｕｇｈｔｅｒ  ｉｓ  ｔａｌｌ  ｆｏｒ  ｈｅｒ  ａｇｅ」という語句とスペイン語の同等の語句「ｍｉ  ｈｉｊａ  ｅｓ  ａｌｔａ  ｐａｒａ  ｓｕ  ｅｄａｄ」も、ＬＯＭの観点から類似の問題を生じる。
【０１５９】
表２４は、比較制約によってモデル化できる表現の例をいくつか例示している。
【０１６０】
表２４：Ｃｏｍｐａｒｉｓｏｎ制約によりモデル化される表現例
【０１６１】
【表２０】
2005332380.tif 000022
【０１６２】
条件節制約では、発話内で表現された条件をモデル化する。表２５は、条件節制約構文を例示している。
【０１６３】
表２５：Ｃｏｎｄｉｔｉｏｎａｌ制約
【０１６４】
【表２１】
2005332380.tif 000023
【０１６５】
前の例のように、条件節制約は、（とりわけ）英語、フランス語、ドイツ語、日本語、およびスペイン語を含む、ほとんどの言語においてモデル化することができる。
【０１６６】
既定の制約は、特定のクラスの構文をモデル化せず、単に、他のＬＯＭオブジェクトによりまだ請求されたことのない基礎的言語解析の一部へのインターフェースを提供するだけである。表２６は、本発明の可能な１つの実装に対する既定の制約構文の例を示している。
【０１６７】
表２６：Ｄｅｆａｕｌｔ制約
【０１６８】
【表２２】
2005332380.tif 000024
【０１６９】
Ｄｅｆａｕｌｔ制約の他の可能な変更形態は、単一のＥｎｔｉｔｙをそのスロットとして受け取る。Ｄｅｆａｕｌｔ制約のこの変更形態では、この単一のＥｎｔｉｔｙと制約のホストとなるオブジェクトとの関係が可能になる。
【０１７０】
一般に、制約はそれに関連付けられたパターンを持ちうることに留意することが重要である。そのようなパターン関連付けにより、どの言語構文を識別すべきかについてＬＯＭコンシューマはＬＯＭプロデューサ（解析エンジン）と通信することが可能である。単純な例は、文字列ベースのパターンであろう。例えば、Ｓｏｕｒｃｅ制約の使用では、パターンは［“ｄｕｅ  ｔｏ”＋Ｘ］を持ち、これにより、解析エンジン（ＬＯＭプロデューサ）がそのパターンをＳｏｕｒｃｅ制約にマッピングするようにすることも可能である。パターン関連付けを言語解析に適用することにより、プログラマ（作者）は、ユーザ入力に対し低レベルの推論を実行することを選択できる。他のＬＯＭ型とは異なり、Ｄｅｆａｕｌｔ制約で暗示される言語共通正規化（ｃｒｏｓｓ−ｌｉｎｇｕｉｓｔｉｃ  ｎｏｒｍａｌｉｚａｔｉｏｎ）はない。
【０１７１】
実装によっては、完全構文解析結果から単純な文字列までの何でも公開できる単一インターフェース（例えば、「ＩＬｉｎｇｕｉｓｔｉｃＡｎａｌｙｓｉｓ」）を定義する必要がある場合がある。一般に、パターンは、発話の一部がＩＬｉｎｇｕｉｓｔｉｃＡｎａｌｙｓｉｓを通じて公開可能な異なる複数の方法に対応することがある。好ましい一実施形態では、解析エンジンの種類毎に１つずつ、ある範囲の既定の制約がある。
【０１７２】
Ｄｅｇｒｅｅ制約は、形容詞句をモデル化する修飾語句制約にのみ付く。表２７は、程度制約とＤｅｇｒｅｅＴｙｐｅ列挙型の構文を例示している。
【０１７３】
表２７：Ｄｅｇｒｅｅ制約
【０１７４】
【表２３】
2005332380.tif 000025
【０１７５】
次に、ＤｅｇｒｅｅＴｙｐｅ列挙型の値は、形容詞句の意味に対する可能な様々な修飾を表す。程度フィールドは、適切な値に設定される。
【０１７６】
場合によっては、節否定（ｃｌａｕｓａｌ  ｎｅｇａｔｉｏｎ）と高型副詞（ｈｉｇｈ−ｔｙｐｅ  ａｄｖｅｒｂ）の両方を同時に取り出すことによりＤｅｇｒｅｅＴｙｐｅの低い値を認識することが望ましいこともある。例えば、表現「ｎｏｔ  ｖｅｒｙ  ｂｉｇ」は、否定（ｎｏｔ）と副詞（ｖｅｒｙ）を介して表現されるＤｅｇｒｅｅＴｙｐｅの低い値を指す。否定を無視すると、発話の解釈を誤ることになるであろう。表２８は、程度制約を使用してモデル化できる表現の例をいくつか例示している。
【０１７７】
表２８：程度制約を含意する語句の例
【０１７８】
【表２４】
2005332380.tif 000026
【０１７９】
当業者であれば、他のＤｅｇｒｅｅ制約型が英語とドイツ語に存在し、そのような制約型は、さらに、ほとんどの言語にも存在することを理解するであろう。Ｄｅｇｒｅｅ制約には、ほとんどどのような言語でもアクセスできる。
【０１８０】
Ｄｉｒｅｃｔｉｏｎ制約では、運動の方向または空間位置の向きをモデル化する。表２９は、Ｄｉｒｅｃｔｉｏｎ制約およびその関連する列挙型の一例を示している。
【０１８１】
表２９：Ｄｉｒｅｃｔｉｏｎ制約および関連する列挙型
【０１８２】
【表２５】
2005332380.tif 000027
【０１８３】
スロットのＤｉｒｅｃｔｉｏｎ型（「ＤｉｒＴｙｐｅ」）フィールドは、適切な列挙値に設定することができる。場合によっては、他の列挙値が望ましいこともある。例えば、コマンド「ｔｕｒｎ」は明示されない方向を持つが、「ｔｕｒｎ」は方向を引数としてとることを予期しているように見える。したがって、実装に応じて、そのような表現を他の表現から区別できるように「Ｕｎｓｐｅｃｉｆｉｅｄ」に対する列挙値を指定することが望ましい場合がある。動詞で合成された値は、語彙エントリに新しいオブジェクト表現として格納することができる。Ｄｉｒｅｃｔｉｏｎ制約は、付く部位に関係なく、方向のオブジェクト（前置詞句）および方向副詞を含むことを理解することも重要である。表３０は、Ｄｉｒｅｃｔｉｏｎ制約によってモデル化できる表現の例をいくつか示している。
【０１８４】
表３０：Ｄｉｒｅｃｔｉｏｎ制約によりモデル化される語句の例
【０１８５】
【表２６】
2005332380.tif 000028
【０１８６】
当業者であれば、他のＤｉｒｅｃｔｉｏｎ制約型が英語とドイツ語に存在し、そのような制約型は、さらに、ほとんどの言語にも存在することを理解するであろう。
【０１８７】
Ｅｘａｍｐｌｅ制約では、エンティティ型、フレームまたは制約の見本をモデル化している。表３１は、そのようなそれぞれのＥｘａｐｍｌｅ制約型に対する構文を例示する。
【０１８８】
表３１：Ｅｘａｍｐｌｅ制約
【０１８９】
【表２７】
2005332380.tif 000029
【０１９０】
いくつかの実装では、以下のような構造を付けるためにＳｉｍｉｌａｒＴｏ制約を用意することが望ましい場合がある。
【０１９１】
I want to find vendors, for example Volt.
I want to find vendors, Volt, for example.
他の実施形態では、見本が一例である目的語（ｗｈａｔ）用に追加スロットを用意することが望ましい場合もある。例えば、「This program exemplifies solid coding techniques」という語句は、「ｓｏｌｉｄ  ｃｏｄｉｎｇ  ｔｅｃｈｎｉｑｕｅｓ」という語句をモデル化するための付加スロットを必要とすることがある。一般に、Ｅｘａｍｐｌｅ制約は直喩をモデル化するとして理解できる。表３２は、Ｅｘａｍｐｌｅ制約によってモデル化できる語句をいくつか示している。
【０１９２】
表３２：Ｅｘａｍｐｌｅ制約によりモデル化される語句の例
【０１９３】
【表２８】
2005332380.tif 000030
【０１９４】
当業者であれば、他のＥｘａｍｐｌｅ制約型が英語、ドイツ語、およびスペイン語に存在し、そのような制約型は、さらに、他の言語にも存在することを理解するであろう。Ｅｘａｍｐｌｅ制約には、ほとんどどのような言語でもアクセスできる。
【０１９５】
Ｅｘｔｅｎｔ制約は、空間内の範囲の何らかの概念の測定に関係するエンティティをモデル化する。表３３は、Ｅｘｔｅｎｔ制約の構文を例示している。
【０１９６】
表３３：Ｅｘｔｅｎｔ制約
【０１９７】
【表２９】
2005332380.tif 000031
【０１９８】
一般に、スロットの範囲フィールドは、範囲の測定をモデル化するＥｎｔｉｔｙに設定される。一実施形態では、範囲前置詞句の目的語は、発話内の付く部位と無関係である。表３４は、Ｅｘｔｅｎｔ制約によりモデル化することができる英語およびスペイン語の語の一例を示す。
【０１９９】
表３４：Ｅｘｔｅｎｔ制約によりモデル化される語句の例
【０２００】
【表３０】
2005332380.tif 000032
【０２０１】
Ｇｏａｌ制約は、ＥｎｔｉｔｙまたはＦｒａｍｅに関する（隠喩的のまたは物理的な）運動のゴールまたは状態変化の最終状態をモデル化する。表３５は、本発明の一実施形態によるＧｏａｌ制約の構文を例示している。
【０２０２】
表３５：Ｇｏａｌ制約
【０２０３】
【表３１】
2005332380.tif 000033
【０２０４】
Ｇｏａｌ制約は、１つまたは複数の列挙型値に関連付けることができる。フィールド「ＤｉｒＴｙｐｅ」（上の表２９で定義されている）は、例えば、適切な列挙型値に設定できる、Ｇｏａｌ制約の列挙型値とすることができる。表３６は、Ｇｏａｌ制約によってモデル化できる語句をいくつか示している。
【０２０５】
表３６：Ｇｏａｌ制約によりモデル化される語句の例
【０２０６】
【表３２】
2005332380.tif 000034
【０２０７】
当業者であれば、他のＧｏａｌ制約型がほとんどの言語に存在することを理解するであろう。Ｇｏａｌ制約には、ほとんどの言語でアクセスできる。
【０２０８】
Ｉｔｅｒａｔｉｏｎ制約は、作用の反復をモデル化する。表３７は、Ｉｔｅｒａｔｉｏｎ制約の構文を例示している。
【０２０９】
表３７：Ｉｔｅｒａｔｉｏｎ制約
【０２１０】
【表３３】
2005332380.tif 000035
【０２１１】
一実施形態では、Ｉｔｅｒａｔｉｏｎ制約は、時間制約のＲｅｃｕｒｒｅｎｃｅフィールドに組み込むことが可能である。一般に、型Ｃｏｕｎｔのフィールドは、作用が一定回数繰り返されることを示す（例えば、ｄｏ［ｓｏｍｅｔｈｉｎｇ］５  ｔｉｍｅｓ）。型がこの値を持つ場合、フィールド「ｔｉｍｅｓ」は反復回数を保持する。型が他の値を持つ場合、型は、特定の反復回数を表さない修飾語句をモデル化する。したがって、型がｃｏｕｎｔに設定されていない場合、これは、反復回数を保持し、そうでなければ、型は無視される。表３８は、Ｉｔｅｒａｔｉｏｎ制約によってモデル化できるいくつかの語および語句を示している。
【０２１２】
表３８：Ｉｔｅｒａｔｉｏｎ制約によりモデル化される語句の例
【０２１３】
【表３４】
2005332380.tif 000036
【０２１４】
当業者であれば、他のＩｔｅｒａｔｉｏｎ制約型がほとんどの言語に存在することを理解するであろう。Ｉｔｅｒａｔｉｏｎ制約には、ほとんどの言語でアクセスできる。
【０２１５】
Ｌｏｃａｔｉｏｎ制約は、物理的場所または隠喩的な場所をモデル化する。表３９は、Ｌｏｃａｔｉｏｎ制約の構文を例示している。
【０２１６】
表３９：Ｌｏｃａｔｉｏｎ制約
【０２１７】
【表３５】
2005332380.tif 000037
【０２１８】
表４０は、Ｌｏｃａｔｉｏｎ制約によってモデル化できるいくつかの語および／または語句を示している。
【０２１９】
表４０：Ｌｏｃａｔｉｏｎ制約によりモデル化される語／語句の例
【０２２０】
【表３６】
2005332380.tif 000038
【０２２１】
当業者であれば、他のＬｏｃａｔｉｏｎ制約型がほとんどの言語に存在することを理解するであろう。Ｌｏｃａｔｉｏｎ制約には、ほとんどの言語でアクセスできる。
【０２２２】
Ｍｅａｎｓ制約では、ＥｎｔｉｔｙまたはＦｒａｍｅについて何かを遂行するための手段またはデバイスをモデル化する。Ｍｅａｎｓ制約の構文は表４１に例示されている。
【０２２３】
表４１：Ｍｅａｎｓ制約
【０２２４】
【表３７】
2005332380.tif 000039
【０２２５】
当業者であれば、他のＭｅａｎｓ制約型がほとんどの言語に存在することを理解するであろう。Ｍｅａｎｓ制約には、ほとんどの言語でアクセスできる。Ｍｅａｎｓ制約を使用してモデル化できる語／語句の例が表４２に示されている。
【０２２６】
表４２：Ｍｅａｎｓ制約によりモデル化される語／語句の例
【０２２７】
【表３８】
2005332380.tif 000040
【０２２８】
Ｍｅａｓｕｒｅ制約では、ＦｒａｍｅまたはＥｎｔｉｔｙに対するオブジェクトの重みまたは尺度をモデル化する。表４３は、本発明の一実施形態によるＭｅａｓｕｒｅ制約の構文を例示している。
【０２２９】
表４３：Ｍｅａｓｕｒｅ制約
【０２３０】
【表３９】
2005332380.tif 000041
【０２３１】
当業者であれば、他のＭｅａｓｕｒｅ制約型が様々な言語に存在することを理解するであろう。Ｍｅａｓｕｒｅ制約には、ほとんどの言語でアクセスできる。表４４は、Ｍｅａｓｕｒｅ制約によってモデル化できるいくつかの語／語句を示している。
【０２３２】
表４４：Ｍｅａｓｕｒｅ制約によりモデル化される語／語句の例
【０２３３】
【表４０】
2005332380.tif 000042
【０２３４】
Ｍｏｄｉｆｉｅｒ制約は、言語表現の意味論的に首尾一貫しているクラスをモデル化しないという点で「ｃａｔｃｈａｌｌ」（「ゴミ捨て場」）制約と考えることができる。代わりに、これは、「付属（ａｄｊｕｎｃｔｈｏｏｄ）」の統合上の概念を捕捉する。一般に、Ｍｏｄｉｆｉｅｒ制約は、Ｅｎｔｉｔｙ、Ｆｒａｍｅ、またはＲｅｓｔｒｉｃｔｉｏｎに関して形容詞句、名詞句、または副詞句をモデル化することができる。一実施形態では、修飾語句スロットは、単に、モデル化される統合的語句の見出し語から構成される構文表記オブジェクトに設定されるだけである。しかし、この実施形態は、ＬＯＭを使用するために必ず必要であるというわけではない。表４５は、本発明の一実施形態によるＭｏｄｉｆｉｅｒ制約の構文を例示している。
【０２３５】
表４５：Ｍｏｄｉｆｉｅｒ制約
【０２３６】
【表４１】
2005332380.tif 000043
【０２３７】
一般に、Ｍｏｄｉｆｉｅｒ制約では、任意の文脈において言語修飾語句のあるクラスをモデル化する。どのような言語修飾語句も修飾語句になりえるが、Ｍｏｄｉｆｉｅｒ制約は、言語修飾語句の部分集合のみを示す主ＬＯＭ表現であることを意図している。その部分集合は、ほとんどまたはすべての形容詞句、ほとんどまたはすべての名詞句修飾語句、およびいくつかの副詞句を含む。多くの副詞句、例えば、１つの大きな例として、時間表現には、他のより固有性の高い制約において主ＬＯＭ表現が見つかる。
【０２３８】
Ｍｏｄｉｆｉｅｒ制約は、スロットはＥｎｔｉｔｙ、ＦｒａｍｅまたはＲｅｓｔｒｉｃｔｉｏｎではなく表記オブジェクトを含むという点でふつうと違う。Ｄｅｎｏｔｅｒオブジェクト文字列は、修飾語句の見出し語である。この配置をとる理由は、言語的修飾語句はそのホスト（修飾される構成要素）上で意味論的に１つの場所において機能し、したがってフレームと似ているが、実際には、ほとんどもっぱら制約として使用されることである。そのうえ、言語的修飾語句は、フレームが出現するかもしれない他の文脈内にほとんど現れることはない。面倒なフレームベースの制約構文（ｗｉｔｈ  ＭｙＬａｒｇｅＦｒａｍｅ＜ｔｈｉｓ＞のような何か）およびそれぞれの所望の修飾語句クラスに対するフレーム型の定義を必要とせずに、修飾語句クラスに対しＤｅｎｏｔｅｒオブジェクトのみを指定し、暗黙の制約文法項（ｒｅｓｔｒｉｃｔｉｏｎ  ａｒｇｕｍｅｎｔ）（制約が付くホストオブジェクトなど）を意味文法項（ｓｅｍａｎｔｉｃ  ａｒｇｕｍｅｎｔ）とみなすことで十分である。
【０２３９】
関係詞節内の叙述形容詞は、その同じ形容詞の対応する限定用法と同じ方法で表される。したがって「ａ  ｌａｒｇｅ  ｆｉｌｅ」と「ａ  ｆｉｌｅ  ｔｈａｔ  ｉｓ  ｌａｒｇｅ」は両方とも、Ｍｏｄｉｆｉｅｒ＜ｌａｒｇｅ＞となる。
【０２４０】
このような形容詞の取り扱いは、構文的に動詞と区別できない振る舞いをする形容詞を持つ日本語などの一部の言語については適切でない場合がある。名詞は言語共通で非常によく似ているが、名詞は、ＳＰＬエンティティにマッピングされる。動詞もまた言語共通で似ているが、動詞は、ＳＰＬフレームにマッピングされる。すると、形容詞は、名詞と動詞の中間にあり、形容詞は、言語共通で類似していない。
【０２４１】
言語は、連続体上に存在すると考えることができる。連続体の一端では、形容詞は、実際には、韓国語などでのように、動詞と別の語彙カテゴリではない。この場合、形容詞は、状態自動詞にすぎない。日本語は、この点に関して韓国語に類似しており、形容詞は構文上動詞のように振る舞う（形態論的に異なるが）。英語およびラテン語起源の言語（ヨーロッパの言語）では、形容詞を動詞と異なるカテゴリとして取り扱う。アラビア語など、その範囲のもう一方の言語では、形容詞をあるクラスの名詞として取り扱う。アラビア語では、「ｒｅｄ」に対する単語でなく、「ａ  ｒｅｄ  ｏｎｅ」のような何かを意味する名詞を使用し、「ｔｈｅ  ｂｏｏｋ  ｉｓ  ｒｅｄ」は「ｔｈｅ  ｂｏｏｋ  ｉｓ  ａ−ｒｅｄ−ｏｎｅ」となる。
【０２４２】
いくつかの実施形態では、母型節（ｍａｔｒｉｘ  ｃｌａｕｓｅｓ）内の叙述形容詞の表現がありうる。例えば、「ｔｈｉｓ  ｆｉｌｅ  ｉｓ  ｐｅｒｓｏｎａｌ」という語句は、「ｔｈｉｓ  ｆｉｌｅ  ｉｓ  ｔｅｘｔ」と異なる取り扱いになる可能性がある。
【０２４３】
さらに、当業者であれば、他のＭｏｄｉｆｉｅｒ制約型が様々な言語に存在することを理解するであろう。Ｍｏｄｉｆｉｅｒ制約には、ほとんどの言語でアクセスできる。
【０２４４】
Ｎａｍｅｄ制約を使用すると、ホストエンティティの表記オブジェクト（ｄｅｎｏｔｅｒ  ｏｂｊｅｃｔ）にアクセスできる。これにより、例えば、ＭｙＡｌｉａｓおよびＤＬ＿ＭｙＡｌｉａｓを単一のＤＬＥｎｔｉｔｙに正規化することができ、しかも著者が２つの異なる制約に対しコーディングしなくて済む。表４６は、本発明の一実施形態によるＮａｍｅｄ制約の構文を例示している。
【０２４５】
表４６：Ｎａｍｅｄ制約
【０２４６】
【表４２】
2005332380.tif 000044
【０２４７】
一般に、Ｎａｍｅｄ制約は、名詞句名またはホストエンティティの表記オブジェクトに設定される。いくつかの実施形態では、Ｎａｍｅｄ制約を使用して、名前付きエンティティ属性に何らかのアクセスを行える。他の実施形態では、Ｎａｍｅｄ制約は、Ｍｏｄｉｆｉｅｒ制約にマージされる。一般に、Ｎａｍｅｄ制約は、すでに存在している情報（ホストエンティティの表記オブジェクトなど）を必要に応じて提示することができる。
【０２４８】
当業者であれば、他のＮａｍｅｄ制約型が様々な言語に存在することを理解するであろう。Ｎａｍｅｄ制約には、ほとんどの言語でアクセスできる。
【０２４９】
Ｎｅｇａｔｉｏｎ制約では、意味論的否定または論理ＮＯＴをモデル化する。表４７は、本発明の一実施形態によるＮｅｇａｔｉｏｎ制約の構文の例を示している。
【０２５０】
表４７：Ｎｅｇａｔｉｏｎ制約
【０２５１】
【表４３】
2005332380.tif 000045
【０２５２】
いくつかの実施形態では、Ｎｅｇａｔｉｏｎ制約は、別の制約として提示されることができる。他の実施形態では、Ｎｅｇａｔｉｏｎ制約は、「ｗｉｔｈ  Ｎｅｇａｔｉｏｎ」節または「！」（Ｎｏｔ演算子）のいずれかにより消費できる。
【０２５３】
Ｏｒｄｉｎａｌ制約では、位置の何らかの概念を順に表現する序数詞およびその他の修飾語句（「ｐｒｅｖｉｏｕｓ」など）をモデル化する。表４８は、本発明の一実施形態によるＯｒｄｉｎａｌ制約およびその列挙型の構文を例示している。
【０２５４】
表４８：Ｏｒｄｉｎａｌ制約および列挙型
【０２５５】
【表４４】
2005332380.tif 000046
【０２５６】
一般に、距離フィールドは、参照点からの符号付き整数距離に設定することができる。その代わりに、ｆｉｒｓｔと呼ばれる参照点フィールド（ｒｅｆＰｏｉｎｔ）は、非負距離を示さなければならない。距離値０は、ｆｉｒｓｔをモデル化し、値１はｓｅｃｏｎｄをモデル化し、というように続く。ｌａｓｔの参照点フィールドは、非正距離でなければならない。距離値０は、ｌａｓｔをモデル化し、値−１はｎｅｘｔ−ｔｏ−ｌａｓｔをモデル化し、というように続く。現在の参照点距離は、整数値を保持することができる。距離値０は、「ｃｕｒｒｅｎｔ」ステータスをモデル化し、値１は「ｎｅｘｔ」をモデル化し、値−１は「ｐｒｅｖｉｏｕｓ」をモデル化し、というように続く。
【０２５７】
表４９は、Ｏｒｄｉｎａｌ制約によってモデル化できる語句をいくつか示している。
【０２５８】
表４９：Ｏｒｄｉｎａｌ制約によりモデル化された語句例
【０２５９】
【表４５】
2005332380.tif 000047
【０２６０】
当業者であれば、他のＯｒｄｉｎａｌ制約型が様々な言語に存在することを理解するであろう。Ｏｒｄｉｎａｌ制約には、ほとんどの言語でアクセスできる。
【０２６１】
Ｐｏｓｓｅｓｓｅｄ制約では、プロパティ、属性、または所有をモデル化し、Ｐｏｓｓｅｓｓｏｒ制約（後述）の補足として使用される。表５０は、本発明の一実施形態によるＰｏｓｓｅｓｓｅｄ制約に関連付けられた構文を例示している。
【０２６２】
表５０：Ｐｏｓｓｅｓｓｅｄ制約
【０２６３】
【表４６】
2005332380.tif 000048
【０２６４】
一般に、Ｐｏｓｓｅｓｓｅｄ制約では、プロパティ、属性、または所有をモデル化する。例えば、「email with headers, schools with linguistics programs」などの語句は、Ｐｏｓｓｅｓｓｅｄ制約によりモデル化することができる。いくつかの場合に、Ｐｏｓｓｅｓｓｅｄ制約は、属性、プロパティ、または所有を「持つ（ｈａｖｉｎｇ）」と呼ぶことができる。表５１は、Ｐｏｓｓｅｓｓｅｄ制約を使用してモデル化できるいくつかの語および語句を示している。
【０２６５】
表５１：Ｐｏｓｓｅｓｓｅｄ制約によりモデル化される語／語句の例
【０２６６】
【表４７】
2005332380.tif 000049
【０２６７】
当業者であれば、他のＰｏｓｓｅｓｓｅｄ制約型が様々な言語に存在することを理解するであろう。Ｐｏｓｓｅｓｓｅｄ制約には、ほとんどの言語でアクセスできる。
【０２６８】
Ｐｏｓｓｅｓｓｏｒ制約は、Ｐｏｓｓｅｓｓｅｄ制約を補完する。一般に、Ｐｏｓｓｅｓｓｏｒ制約では、語彙名詞句により表現されようと、所有代名詞により表現されようと関係なく、エンティティの所有者をモデル化する。表５２は、本発明の一実施形態によるＰｏｓｓｅｓｓｏｒ制約の構文を例示している。
【０２６９】
表５２：Ｐｏｓｓｅｓｓｏｒ制約
【０２７０】
【表４８】
2005332380.tif 000050
【０２７１】
表５３は、Ｐｏｓｓｅｓｓｏｒ制約によってモデル化できるいくつかの語／語句を示している。
【０２７２】
表５３：Ｐｏｓｓｅｓｓｏｒ制約によりモデル化される語／語句の例
【０２７３】
【表４９】
2005332380.tif 000051
【０２７４】
当業者であれば、他のＰｏｓｓｅｓｓｏｒ制約型が様々な言語に存在することを理解するであろう。Ｐｏｓｓｅｓｓｏｒ制約には、ほとんどの言語でアクセスできる。
【０２７５】
ＬＯＭでモデル化される他の制約は、Ｐｕｒｐｏｓｅ制約である。Ｐｕｒｐｏｓｅ制約では、Ｆｒａｍｅに関連付けられる予想される結果をモデル化する。表５４は、Ｐｕｒｐｏｓｅ制約によってモデル化できる語句／語の例をいくつか例示している。
【０２７６】
表５４：Ｐｕｒｐｏｓｅ制約によりモデル化される語／語句
【０２７７】
【表５０】
2005332380.tif 000052
【０２７８】
Ｒｅａｓｏｎ制約では、フレームまたはエンティティに関連付けられた信念または作用に対する合理的動機をモデル化する。一実施形態では、ＲｅａｓｏｎおよびＰｕｒｐｏｓｅ制約はスコープが重なり合うことがある。表５５は、Ｒｅａｓｏｎ制約によってモデル化できるいくつかの語／語句を示している。
【０２７９】
表５５：Ｒｅａｓｏｎ制約によりモデル化される語／語句
【０２８０】
【表５１】
2005332380.tif 000053
【０２８１】
Ｒｅａｓｏｎ制約およびＰｕｒｐｏｓｅ制約の両方をモデル化できる言語はいくつもある。上記の語／語句の例は、網羅的リストとして使用することを意図しているのではなく、むしろ、制約によりモデル化される可能性のある語を例示することを意図している。
【０２８２】
ＳｏｒｔＯｒｄｅｒ制約では、データの順序付けのスタイルおよび／または方法を記述する修飾語句をモデル化する。表５６は、ＳｏｒｔＯｒｄｅｒ制約および関連するＯｒｄｅｒＴｙｐｅ列挙型の構文を例示している。
【０２８３】
表５６：ＳｏｒｔＯｒｄｅｒ制約
【０２８４】
【表５２】
2005332380.tif 000054
【０２８５】
一般に、フィールド型は、Ｄｅｆａｕｌｔ、Ｒｅｖｅｒｓｅ、Ａｌｐｈａｂｅｔｉｃ、Ｎｕｍｅｒｉｃ、Ｉｎｃｒｅａｓｉｎｇ、Ｄｅｃｒｅａｓｉｎｇなどとすることができる。既定の型は、既定の順序、任意の順序などでモデル化する。Ｒｅｖｅｒｓｅ型は逆順に（後方に）モデル化する。Ａｌｐｈａｂｅｔｉｃ型はＡＢＣ順に（アルファベット順で）モデル化する。Ｎｕｍｅｒｉｃ型は数字で（数値順序で）モデル化する。Ｉｎｃｒｅａｓｉｎｇ型は、昇順でモデル化する。Ｄｅｃｒｅａｓｉｎｇ型は、降順でモデル化する。
【０２８６】
実施形態によっては、ＳｏｒｔＯｒｄｅｒ制約を「アルファベット順リスト」のような物のエンティティに課すこともできる。さらに、「ａｌｐｈａｂｅｔｉｚｅ」、「ｃａｔｅｇｏｒｉｚｅ」、「ｇｒｏｕｐ」、「ｃｌａｓｓｉｆｙ」、および「ｉｎｄｅｘ」などの動詞も、ＳｏｒｔＯｒｄｅｒ制約によりモデル化することができる。いくつかの場合において、「ｒｅｖｅｒｓｅ  ａｌｐｈａｂｅｔｉｃａｌ  ｏｒｄｅｒ」、「ｄｅｃｒｅａｓｉｎｇ  ａｌｐｈａｂｅｔｉｃａｌ  ｏｒｄｅｒ」などのような語句をモデル化するため２つのフィールドを備えることが望ましいこともある。さらに、２つの異なる言語に共通の異なる並べ替え順序もありうる。表５６に示されている列挙型は英語ではふつうであるが、日本語はその言語にふつうである追加並べ替え順を持つことができる。表５７は、ＳｏｒｔＯｒｄｅｒ制約によってモデル化できるいくつかの語句／語の例を示している。
【０２８７】
表５７：ＳｏｒｔＯｒｄｅｒ制約によりモデル化される語／語句
【０２８８】
【表５３−１】
2005332380.tif 000055
【０２８９】
【表５３−２】
2005332380.tif 000056
【０２９０】
Ｓｏｕｒｃｅ制約では、オブジェクトのソースまたは発生元をモデル化する。Ｓｏｕｒｃｅ制約の構文は表５８に示されている。
【０２９１】
表５８：Ｓｏｕｒｃｅ制約
【０２９２】
【表５４】
2005332380.tif 000057
【０２９３】
一般に、当業者であれば、様々なＳｏｕｒｃｅ制約型が複数の言語用に存在しうることを理解するであろう。
【０２９４】
ＳｔｒｕｃｔｕｒｅＣｒｉｔｅｒｉａ制約では、構造化された方法で１組のオブジェクト上で動作するという、Ｆｒａｍｅｓに関する、概念をモデル化する。ＳｔｒｕｃｔｕｒｅＣｒｉｔｅｒｉａ制約は、動作を進行させるための１つまたは複数の基準をモデル化する。ＳｔｒｕｃｔｕｒｅＣｒｉｔｅｒｉａ制約の構文は表５９に示されている。
【０２９５】
表５９：ＳｔｒｕｃｔｕｒｅＣｒｉｔｅｒｉａ制約
【０２９６】
【表５５】
2005332380.tif 000058
【０２９７】
ＬＯＭのいくつかの実装では、「ｉｎ  ｐａｉｒｓ」、「５  ａｔ  ａ  ｔｉｍｅ」などの語句をモデル化するため「増分」と呼ばれる制約を含めるのが望ましい場合がある。これらの種類の語句は、実装に応じて、モデル化する何らかの専用手段を備えるのに十分重要と思われるうまく正規化可能な数値基準を含む。表６０は、ＳｔｒｕｃｔｕｒｅＣｒｉｔｅｒｉａ制約によってモデル化できるいくつかの語および語句を例示している。
【０２９８】
表６０：構造基準制約によりモデル化される語／語句
【０２９９】
【表５６】
2005332380.tif 000059
【０３００】
「Ｓｕｂｓｔｉｔｕｔｉｏｎ」制約は、一方の語が他方の語の代替となる意味論的事象への関与部分をモデル化する。フランス語では、「ａ」が付加詞として「ｐｏｕｒ」の代わりになる例が考えられる。付加詞は、作用の状況を示すある種の副詞である。同様に、スペイン語では、「ｐｏｒ」が付加詞として使用され、「ｐａｒａ」は、選択された動詞とともに使用されうる。
【０３０１】
時間は、制約として取り扱うことができる。一般に、Ｔｉｍｅ制約では、エンティティとして表現できる特定の時間単位または時点への参照を伴う時間修飾語句をモデル化する。例えば、「ａｆｔｅｒ  Ｊｕｌｙ  ２３ｒｄ」および「ａｆｔｅｒ  Ｔｈａｎｋｓｇｉｖｉｎｇ」は、Ｔｉｍｅ制約によりモデル化することができる。しかし、いくつかの実施形態では、「ａｆｔｅｒ  ｍｙ  ｃｏｍｐｕｔｅｒ  ｂｏｏｔｓ  ｕｐ」などの語句は、Ｔｉｍｅ制約によりモデル化されない。同様に、「ｆｒｏｍ  ３：００  ｔｏ  ６：００」および「ｂｅｔｗｅｅｎ  ｍｏｒｎｉｎｇ  ａｎｄ  ｅｖｅｎｉｎｇ」などの時間の範囲は、Ｔｉｍｅ制約によりモデル化することができる。しかし、「ｗｈｉｌｅ  ｔｈｅ  ｄｅｆｒａｇ  ｕｔｉｌｉｔｙ  ｉｓ  ｒｕｎｎｉｎｇ」は、Ｔｉｍｅ制約によりモデル化されえない。埋め込まれた節内容を伴う時間表現は、Ｃｏｎｄｉｔｉｏｎａｌ制約で取り扱われる。表６１は、時間の構文および実装をＬＯＭ内の制約として例示している。
【０３０２】
表６１：Ｔｉｍｅ制約
【０３０３】
【表５７−１】
2005332380.tif 000060
【０３０４】
【表５７−２】
2005332380.tif 000061
【０３０５】
【表５７−３】
2005332380.tif 000062
【０３０６】
【表５７−４】
2005332380.tif 000063
【０３０７】
【表５７−５】
2005332380.tif 000064
【０３０８】
【表５７−６】
2005332380.tif 000065
【０３０９】
Ｔｉｍｅ制約では、必要に応じて１つまたは複数のフィールドおよび多数の補助データ型を使用する。フィールドは、開始時刻、終了時刻、「ｐｏｉｎｔ  ｏｒ  ｓｐａｎ」、持続時間、および反復を含むことができる。開始時刻フィールドは、「ｆｒｏｍ  ５：００」または「ａｆｔｅｒ  ｔｏｍｏｒｒｏｗ」などのタイムスパンの始点を表現する基準時間派生オブジェクトに設定される。開始時刻フィールドがヌルの場合、モデル化された時間修飾語句は、始点の明白な表現を含まない。
【０３１０】
終了時刻フィールドは、「ｔｏ  ６：００」または「ｕｎｔｉｌ  Ｆｒｉｄａｙ」などのタイムスパンの終点を表現する基準時間派生オブジェクトに設定される。終了時刻フィールドがヌルの場合、モデル化された時間修飾語句は、終点の明白な表現を含まない。
【０３１１】
点またはスパンフィールドは、始点および終点を明確に指定することにより表されるタイムスパンとは反対に、単一語句で表される単独の時点またはタイムスパンを表す基準時間派生オブジェクトに設定される。例えば、「ｔｏｍｏｒｒｏｗ」に関して、「ｔｏｍｏｒｒｏｗ」が同時線または２４時間タイムスパン上の単一点かどうかは文脈および見る側の視点によって異なるという考え方である。ＬＯＭでは、語の曖昧さをなくそうとは試みない。点またはスパンフィールドがヌルの場合、モデル化された時間修飾語句は、単独の時点またはスパンの明白な表現を含まない。
【０３１２】
持続時間フィールドは、特定の始点および終点を表すことなくタイムスパンの長さを表す持続時間オブジェクトに設定することができる。例えば、「ｆｏｒ  ｔｗｏ  ｈｏｕｒｓ」という語句は、持続時間フィールドによりモデル化することができる。ヌルの場合、モデル化された時間修飾語句は、持続時間の明白な表現を含まない。「ｆｒｏｍ  ４  ｐｍ  ｔｏ  ６  ｐｍ」などのタイムスパンに内在する持続時間は、持続時間オブジェクトとしては表現されない。この場合、開始時刻と終了時刻に対して非ヌル値はないだろうが、持続時間はヌルとなる。
【０３１３】
反復フィールドは、反復事象の出現から出現までの時間間隔を表す時間長オブジェクトに設定される。例えば、「ｄａｉｌｙ」、「ｗｅｅｋｌｙ」、「ｍｏｎｔｈｌｙ」、毎月の第１月曜日などの語句例の場合、時間長オブジェクトとして表すことができる。ヌルの場合、モデル化された時間修飾語句は、反復として解釈されない。
【０３１４】
一般に、Ｔｉｍｅ制約では、多数の補助データ型を使用する。例えば、ＢａｓｅＴｉｍｅ連鎖は、ＲｅｌａｔｉｖｅＴｉｍｅから派生した０個または複数のオブジェクトおよびＡｂｓｏｌｕｔｅＴｉｍｅから発生したちょうど１つの「ルート」オブジェクトからなる、ＢａｓｅＴｉｍｅから派生されたオブジェクトである。これらは、各ＲｅｌａｔｉｖｅＴｉｍｅ派生オブジェクトが連鎖内の次のオブジェクトへの参照を保持するため「連鎖」と呼ばれるが、ルートＡｂｓｏｌｕｔｅＴｉｍｅ派生オブジェクトはそのような参照を保持しない。
【０３１５】
ＮｏｗＡｂｓｏｌｕｔｅＴｉｍｅなどのＡｂｓｏｌｕｔｅＴｉｍｅ派生型は連鎖内の他のオブジェクトへの参照を保持しない。例えば、ＮｏｗＡｂｓｏｌｕｔｅＴｉｍｅ派生型は、発話時の解析不可能な「ｎｏｗ」を表す。ＬＯＭは、「ｎｏｗ」を、例えば、２００２年１０月２４日午後３時４２分２７秒に解決することを試みない。
【０３１６】
ＡｎａｌｙｚｅｄＡｂｓｏｌｕｔｅＴｉｍｅは、ＡｂｓｏｌｕｔｅＴｉｍｅ派生型であり、秒、時間、日、年などに関して解析できる時点またはタイムスパンを表す。例えば、ＡｎａｌｙｚｅｄＡｂｓｏｌｕｔｅＴｉｍｅは、時点「ｎｏｗ」を３時４５分、２００３年５月１０日、水曜午前９時３０分として表すために使用することができる。
【０３１７】
ＵｎａｎａｌｙｚｅｄＡｂｓｏｌｕｔｅＴｉｍｅは、時点であることは知られているが、原子時間単位で解析できない、表現を表すＡｂｓｏｌｕｔｅＴｉｍｅ派生型である。例えば、休日、春夏秋冬、および抽象的な時間概念は、このカテゴリに入る傾向がある。例えば、「Ｔｈａｎｋｓｇｉｖｉｎｇ」、「Ｅｌｅｃｔｉｏｎ  Ｄａｙ」、「ｍｙ  ｂｉｒｔｈｄａｙ」、「ｓｕｍｍｅｒ」、および「ｔｈｉｓ  ｅｖｅｎｉｎｇ」はすべて、ＵｎａｎａｌｙｚｅｄＡｂｓｏｌｕｔｅＴｉｍｅとしてモデル化される語句である。
【０３１８】
ＯｆｆｓｅｔＲｅｌａｔｉｖｅＴｉｍｅおよびＳｕｂｓｅｔＲｅｌａｔｉｖｅＴｉｍｅの２つのＲｅｌａｔｉｖｅＴｉｍｅ派生型が存在する。ＯｆｆｓｅｔＲｅｌａｔｉｖｅＴｉｍｅは、参照されているＢａｓｅＴｉｍｅ派生オブジェクトからの特定の時間の長さの正または負のオフセットを表す。例えば、「ｔｗｏ  ｄａｙｓ  ａｇｏ」という語句は、「［２  ｄａｙｓ  ｂａｃｋ］ＯＦＦＳＥＴ  ＦＲＯＭ［ｎｏｗ］」とモデル化される。
【０３１９】
ＳｕｂｓｅｔＲｅｌａｔｉｖｅＴｉｍｅは、参照ＢａｓｅＴｉｍｅ派生オブジェクトにより表現される囲むタイムスパンの部分集合であるとして解釈される時点またはタイムスパンを表すＲｅｌａｔｉｖｅＴｉｍｅ派生型である。例えば、「ａｔ  ５：００  ｏｎ  ｍｙ  ｂｉｒｔｈｄａｙ」などの時間次元の表現は、「［ｈｏｕｒ：５  ｍｉｎ：０］ＳＵＢＳＥＴ  ＯＦ［“ｍｙ  ｂｉｒｔｈｄａｙ”］」に相当する表現としてモデル化することができる。「５：００  ｏｎ  Ｗｅｄｎｅｓｄａｙ」などの時間参照は、その語句が時間単位に分解できるため、単一のＡｎａｌｙｚｅｄＡｂｓｏｌｕｔｅＴｉｍｅオブジェクトにより捕捉できることに留意されたい。
【０３２０】
いくつかの実施形態では、ＳｔａｒｔＴｉｍｅおよびＥｎｄＴｉｍｅフィールドの複数のペアを持つことが望ましい場合がある。例えば、「ｆｒｏｍ  Ｍｏｎｄａｙ  ｔｏ  Ｆｒｉｄａｙ  ｆｒｏｍ  ４：００  ｔｏ  ５：００」などの表現を捕捉するためには、両方の範囲を捕捉するのに開始および終了時刻フィールドの２つのペアがあるのが望ましい場合がある。実際、上記の表現については、Ｔｉｍｅエンティティを持つことが望ましいであろう。さらに、以下の表現の間の並行関係から、Ｔｉｍｅエンティティが望ましい場合のあることが示唆される。
【０３２１】
Move the meeting [from 4:00 to 5:00].
Move the file [from Folder1]Source [to Folder2]Goal.
さらに、ＳｏｕｒｃｅｓおよびＧｏａｌｓを取るすべての構造がＳｔａｒｔＴｉｍｅおよびＥｎｄＴｉｍｅがそのような機能を持つことを許すわけではないため、ＥｎｄＴｉｍｅは通常のＧｏａｌｓと区別されるべきである。例えば、「Ｒｕｎ  ａ  ｍｅｅｔｉｎｇ［ｆｒｏｍ  ４：００  ｔｏ  ５：００］」という表現をモデル化するように適合されている構造では、ＳｔａｒｔＴｉｍｅおよびＥｎｄＴｉｍｅが適切な機能を果たさない場合がある。
【０３２２】
他の制約として、Ｔｏｐｉｃ制約がある。Ｅｎｔｉｔｙオブジェクトに関して、Ｔｏｐｉｃ制約では、エンティティが何についてのエンティティであるか、またはエンティティが何に関わる、または関係しているのかを表現する項または修飾語句をモデル化する。Ｆｒａｍｅに関連付けられたＴｏｐｉｃ制約は、事象の主題また話題を表現する動詞項をモデル化する。一般に、Ｔｏｐｉｃ制約は、話題または主題をモデル化するＥｎｔｉｔｙまたはＦｒａｍｅに設定されたＳｌｏｔを持つ。その代わりに、Ｓｌｏｔは文字列を取ることもできる。表６２は、本発明の一実施形態によるＴｏｐｉｃ制約の構文を例示している。
【０３２３】
表６２：Ｔｏｐｉｃ制約
【０３２４】
【表５８】
2005332380.tif 000066
【０３２５】
場合によっては、異なる名前を持つＴｏｐｉｃ制約にラベルを付けることが望ましいことがある。特に、「ｔｏｐｉｃ」の厳しいオーバーロードが与えられている場合（少なくともＬｉｎｇｕｉｓｔｉｃｓのフィールド内で）、この制約に対し他のラベルを使用することが望ましい場合がある。例えば、他のいくつかのラベルは、「Ｃｏｎｃｅｒｎｉｎｇ」、「Ｒｅｇａｒｄｉｎｇ」、「Ａｂｏｕｔ」、「Ｓｕｂｊｅｃｔ」、「Ｔｈｅｍｅ」などを含むことも可能である。表６３は、本発明の一実施形態によるＴｏｐｉｃ制約によりモデル化することができる語／語句のいくつかの例を示す。
【０３２６】
表６３：Ｔｏｐｉｃ制約によりモデル化される語／語句の例
【０３２７】
【表５９】
2005332380.tif 000067
【０３２８】
Ｑｕａｎｔｉｆｉｅｒ制約では、「ｔｗｏ−ｔｈｉｒｄｓ  ｏｆ」などの名詞句数量詞および部分表現をモデル化する。一般に、Ｑｕａｎｔｉｆｉｅｒ制約は、型またはパーセンテージフィールドを含むことができる。型フィールドは、浮動小数点数として格納される、通常は（必ずしもそうではないが）０から１までの範囲の、パーセンテージとすることができる。例えば、パーセンテージ型では、「ｏｎｅ  ｈａｌｆ  ｏｆ」、「７５％  ｏｆ」、「２００％  ｉｎｃｒｅａｓｅ」などをモデル化する。型フィールドは、さらに、正確なパーセンテージに対応しない数量詞をモデル化することもできる。「ａｌｌ」および「ｎｏｎｅ」は、この「ｏｔｈｅｒ」型に分類されない異なる「ｐｒｉｖｉｌｅｇｅｄ」値として列挙される。パーセンテージフィールドは、型がＰｅｒｃｅｎｔａｇｅの値を持つ場合に数量詞の意味に対応するパーセンテージを保持する。そうでなければ、パーセンテージフィールドは無視される。表６４は、Ｑｕａｎｔｉｆｉｅｒ制約と関連する列挙型の構文を例示している。
【０３２９】
表６４：Ｑｕａｎｔｉｆｉｅｒ制約
【０３３０】
【表６０】
2005332380.tif 000068
【０３３１】
いくつかの実装では、否定の取り扱い方を変えるのが望ましい場合がある。「ｎｏｎｅ」などの語を列挙するのではなく、否定を名詞句として処理するのが望ましいかもしれない。表６５は、Ｑｕａｎｔｉｆｉｅｒ制約によってモデル化できる語／語句の例をいくつか例示している。
【０３３２】
表６５：Ｑｕａｎｔｉｆｉｅｒ制約によりモデル化される語／語句
【０３３３】
【表６１】
2005332380.tif 000069
【０３３４】
当業者であれば、語および語句の例に関する上記の説明は、言語的モデリングに関する特定の制限を説明するのではなく、領域および言語独立性を説明することを意図していることを理解するであろう。一般に、ＬＯＭは言語をいくつでもモデル化できる。
【０３３５】
Ｄ４.フレームのクラス：語彙意味論構造
以下の説明は、語彙意味論構造（ＬＳＳ）と呼ばれる、ＬＯＭオブジェクトプロデューサ（解析エンジン）の可能な実装の一態様に関係する。この特定の態様は、ＬＯＭと連動して開発されているが、ＬＯＭオブジェクトを出力するために他の数多くの実装を使用することもできる。ＬＳＳは、さらに、ＬＯＭの型に対する設計プロセスでも使用された。
【０３３６】
語彙意味論構造（ＬＳＳ）は、複数の言語にまたがり、複数の言語カテゴリにまたがる自然言語入力の正規化に関して、言語共通の振る舞いおよび子言語取得に関する一般化に基づいている。ＬＳＳは、自然言語の要素を語彙意味論クラスにマッピングするための方法を提供する。このような用途の１つは、言語オブジェクトモデル（ＬＯＭ）への自然言語入力（言語的発話）を表す語彙意味論構造をマッピングすることを含むことも可能である。
【０３３７】
ＬＳＳは、一組の語彙意味論カテゴリ、および自然言語入力をその一組の語彙意味論カテゴリのうちの１つまたは複数に割り当てる方法を含む。その一組の語彙意味論カテゴリのそれぞれのカテゴリは、自然言語入力の要素を統語的カテゴリおよび意味役割のインベントリにマッピングすることを暗示する。より具体的には、それぞれのカテゴリは、１つまたは複数の統語的カテゴリを１つまたは複数の意味役割にマッピングすることを暗示する。本明細書で使用されているように、「統語的カテゴリ」という用語は、文の構造要素を指す（例えば、主語、目的語、前置詞句、節補語、修飾語句など）。「意味役割」という語句は、特定の発話内の特定の統語的カテゴリの関数の識別を指す−例えば、主語は一般に役割「ｗｈｏ」（動作主、主体、行為者、または作用の原因など）を割り当てられ、直接目的語は「ｗｈａｔ」（患者、被影響者、完了先（ｄｏｎｅ−ｔｏ）、または作用の効果など）であり、修飾語句は様々な役割（ソース、ゴール、時間など）である。上に示した実施例は、説明のために用意されているのであって、網羅的であることを意図していないことは理解されるであろう。最後に、本明細書で使用されているように、「正規化する」または「正規化」という語は、特定の統語表示から意味役割を抽出するプロセスを指す。
【０３３８】
インベントリおよび意味論は、言語共通の振る舞いおよび子言語取得から派生し、自然言語の語彙意味論的特徴がいくつかのプロパティを共有しているという一般化に基づく。言語的係留（ｌｉｎｇｕｉｓｔｉｃ  ａｎｃｈｏｒｉｎｇ）および意味論的詳細に関して、ＬＳＳは、世界知識に基づいて言語から意味論的推論に移行する人工知能システムと、見かけの同義語間の区別をモデル化するよりキメの細かい語彙解析フレームワークとの間に置かれる。つまり、すべての言語は、既定のようにマッピングできる言語構造を持つということである。さらに、それぞれの自然言語は、統語的カテゴリから意味役割への非既定マッピングを多数持つ。主語および目的語よりも因果関係上遠い位置にある意味役割を持つ非既定クラスほど、まれである。
【０３３９】
既定の語彙意味論構造では、上述のように、文の主語を「Ｗｈｏ」として、目的語を「Ｗｈａｔ」として分類することにより、「Ｊｏｈｎ  ｂｒｏｋｅ  ｔｈｅ  ｇｌａｓｓ」などの他動詞文をモデル化する。修飾語句は、因果連鎖の時間的展開を表す順序（または形態格標示）で識別される。つまり、修飾語句は、付加格標示（間接目的語）および前置詞句などの副詞修飾語句が果たす意味役割から派生する。「Ｊｏｈｎ  ｂｒｏｋｅ  ｔｈｅ  ｇｌａｓｓ  ｆｏｒ  ｍｅ」という語句では、「Ｊｏｈｎ」は主語であり、「ｇｌａｓｓ」は目的語であり、「ｆｏｒ  ｍｅ」という語句は文の目的語により近い間接目的語として標示される。
【０３４０】
既定の自動詞文は、通常、代理人または「Ｗｈｏ」を含む。例えば、「Ｊｏｈｎ  ｒａｎ」という語句は、動作主「Ｊｏｈｎ」を含む。あまり一般的ではないが、単一の項は「Ｐａｔｉｅｎｔ」である。例えば、「Ｔｈｅ  ｇｌａｓｓ  ｂｒｏｋｅ」という語句では、「ｔｈｅ  ｇｌａｓｓ」という語句が影響を受け、文は、元の文が「［Ｓｏｍｅｔｈｉｎｇ］ｂｒｏｋｅ  ｔｈｅ  ｇｌａｓｓ」であるかのようにしてモデル化することができる。
【０３４１】
意味役割がＬＳＳインベントリに含まれる場合、これは、ある言語では統語的カテゴリとして現れなければならず、ある範囲の名詞および動詞クラスにまたがって項または修飾語句として適用される。したがって、これらの役割は、言語的係留および意味論的一般性の両方を持つ。例えば、「ｔｈｅ  ｏｆｆｉｃｅ」という語句は、以下の例のそれぞれにおいてＳｏｕｒｃｅである。
【０３４２】
１．John left the office.
２．The office emitted smoke.
３．John went out of the office.
４．The man from the office called.
それぞれの場合に、ソースは、動詞クラスおよび意味論的／統合的テストでのその振る舞いに基づいて識別される。例１を参照すると、ソースは、このクラスの中の動詞の目的語である。動詞「ｌｅｆｔ」および他動詞「ｔｏ  ｌｅａｖｅ」（および、とりわけ、「ｔｏ  ｅｘｉｔ」）は、付加的ソースを取ることができない。例えば、「Ｊｏｈｎ  ｌｅｆｔ  ｔｈｅ  ｈｏｕｓｅ  ｏｕｔ  ｏｆ  ｔｈｅ  ｙａｒｄ」は、「Ｊｏｈｎ  ｗｅｎｔ  ｏｕｔ  ｏｆ  ｔｈｅ  ｈｏｕｓｅ  ａｎｄ  ｏｕｔ  ｏｆ  ｔｈｅ  ｙａｒｄ」を意味しない。例２では、「ｔｈｅ  ｏｆｆｉｃｅ」は、類似の意味論的／統語的テストについて「ｅｍｉｔ」により例示されている動詞クラスの振る舞いに基づく文の主語である。上の例３および４では、前置詞「ｏｕｔ  ｏｆ」および「ｆｒｏｍ」の意味論は、一般に、ソース役割をその目的語に割り当てる。
【０３４３】
ＬＳＳは、一組の語彙意味論カテゴリ、および自然言語入力をその一組の語彙意味論カテゴリのうちの１つまたは複数のカテゴリに関連付ける方法である。この方法は、自然言語の内容を一組の語彙意味論カテゴリおよび規則に関連付け、その手順の集まりを自然言語入力に適用する手順の集まりを含む。本明細書で使用されているように、「方法」という用語は、自然言語入力の内容を一組の語彙意味論カテゴリに関連付ける手順の集まりを意味する。それぞれの語彙意味論カテゴリは、１つまたは複数の統語的カテゴリ、１つまたは複数の役割、および１つまたは複数の統語的カテゴリと関連付けられている、項が発話内で果たす１つまたは複数の役割との間のマッピングを含む。さらに、「方法」は、手順の集まりを自然言語入力に適用するための規則を指す。いくつかの場合において、「方法」は、自然言語入力の内容をマッピングする異なる段階が完全である場合にそのことを決定する発見的手法を含んでいてもよい。「方法」という用語は、自然言語入力の内容を一組の言語カテゴリのうちの１つまたは複数の言語カテゴリに関連付けおよび／または正規化するように適合されている手法、規則、および手順の集まりを含む。
【０３４４】
ＬＳＳは、正規化構造として、統語的カテゴリ（動詞の主語／目的語、動詞を修飾する前置詞句の目的語など）にまたがって意味役割を識別することを補助する。さらに、ＬＳＳでは、統語的カテゴリを複数の言語にまたがって意味役割と関連付けることが可能である。この正規化は、統語的カテゴリのクラスだけでなくその意味論のクラスの項も識別し、識別された項を適切な語彙意味論カテゴリに関連付けることにより、達成される。その後、特定の統語的表現から語彙意味論構造を抽出することができる。
【０３４５】
言語オブジェクトモデルおよび意味論プログラミング言語（および関連するユーザスキーマ）と併用することで、多くの言語的カテゴリにおける意味論的曖昧さが削減される。例えば、前置詞「ｆｏｒ」は、作用の受益者（Ｉ  ｂｏｕｇｈｔ  ａ  ｄｒｅｓｓ  ｆｏｒ  ｍｙ  ｄａｕｇｈｔｅｒ）、目的（Ｉ  ｇｏ  ｔｏ  Ｃａｌｉｆｏｒｎｉａ  ｆｏｒ  ｔｈｅ  ｂｅａｃｈｅｓ）、時間範囲（Ｉ  ｗｅｎｔ  ｔｏ  ｓｃｈｏｏｌ  ｆｏｒ  ２０  ｙｅａｒｓ）、ゴール（ｐｒｅｓｅｎｔ  ｆｏｒ  ｍｙ  ｄａｕｇｈｔｅｒ）などを識別する。しかし、与えられたアプリケーション内では、限られた可能性の集まりのみがその文脈に関連する。したがって、意味論的曖昧さの多くは文脈により排除される。
【０３４６】
図１１は、本発明の一実施形態による語彙意味論構造（ＬＳＳ）１１００を示す簡略化された概念ブロック図である。ＬＳＳ  １１００は、一組の語彙意味論カテゴリ１１０２、および自然言語入力１１０６の要素を語彙意味論カテゴリ１１０２にマッピングする方法（手順および規則）１１０４を含む。図に示されている実施形態では、この後、自然言語入力１１０６を表すマッピングされた要素を解析エンジン１１０８に供給して、言語オブジェクトモデル（ＬＯＭ）１１１０にマッピングし、自然言語入力１１０６を表すＬＯＭオブジェクト１１１２を出力することができる。当業者であれば、この方法は、実行時だけでなく、ＬＳＳクラスを設計時に開発した際のアプローチの両方に適用されることを理解するであろう。より具体的には、ＬＳＳは、様々な言語、様々な言語カテゴリ、様々な解析エンジンなどにおいて、自然言語入力をマッピングするため実行時に自然言語処理に適用可能であるが、語彙意味論構造は、さらに、設計時にプログラムコードにＬＳＳクラスを知らせる。
【０３４７】
一般に、ＬＳＳは、サポートされている言語のうちの１つで既定のパターンと異なる、統語的および意味論的フレームを共有するフレームおよびエンティティのグループを識別する。一般に、語彙意味論は、単語の意味を主に扱う言語の一分野である。語彙意味論構造（ＬＳＳ）理論は、単語の意味と文の意味および構文との関係に関する。さらに、ＬＳＳ理論では、異なる言語間の語彙意味論構造の違いおよび類似性を扱う。
【０３４８】
一般に、Ｆｒａｍｅｓは、他動詞既定パターンと自動詞既定パターンの２つの既定パターンを持つ。他動詞既定パターンは、Ｗｈｏスロットを主語位置にリンクし、Ｗｈａｔスロットを目的語位置にリンクする。対照的に、自動詞既定パターンには、Ｗｈａｔスロットと目的語位置が欠けている。以下の例では、両方とも先頭に動詞型が付いている。
【０３４９】
[User]Who types [email address]What.
[User]Who types.
Ｆｒａｍｅｓは、リンキング（フレームのスロットが文法により配置される方法）と項構造（スロット数）の両方で既定と異なることがある。例えば、非既定リンキング型では、動詞のクラスである非対格は、動詞「ｉｎｃｒｅａｓｅ」が先頭に付く、以下のフレームに見られるような自動詞パターンに対し異なるリンキングパターンを有する。
【０３５０】
[Users]Who generally increase [the font size]What.of headers.
[The font size]What generally increases in headers.
この場合、自動詞の主語は、他動詞の目的語と同じであり、Ｗｈａｔスロットにリンクされる。言語学では、これらの非対格非既定リンキング型は、ある種の言語の格標示パターンにちなんで「能格」動詞と呼ばれることもある。このような動詞は、既定リンキングパターンに加えて、自動詞の付加的非既定リンキングパターンを生成する。
【０３５１】
他の非既定リンキング型では、ＯｂｌｉｑｕｅＡｓＤｅｆａｕｌｔという動詞のクラスは、ＷｈｏまたはＷｈａｔ項を斜格項として表現する。例えば、英語における相互関係は、付加されたＷｈｏまたはＷｈａｔ関与部をＡｃｃｏｍｐａｎｉｍｅｎｔ制約の目的語として表現する。
【０３５２】
付加されたWho：I chatted with John〜John and I chatted.
付加されたWhat:I merged file A with File B〜I merged File A and B.
他の言語は、相互関係を付加代名詞項として表現し、代名詞に関係する、または目的語を記述せずに目的語を識別または規定する項を意味する。これらは、Ａｃｃｏｍｐａｎｉｍｅｎｔ制約の下でも取り扱われる。
【０３５３】
多くの動詞は、意味論的にＷｈａｔスロットに関連するように見える構文的斜格項（ｓｙｎｔａｃｔｉｃａｌｌｙ  ｏｂｌｉｑｕｅ  ａｒｇｕｍｅｎｔｓ）（個癖的前置詞（ｉｄｉｏｓｙｎｃｒａｔｉｃ  ｐｒｅｐｏｓｉｔｉｏｎｓ）により標示される）を持つ。つまり、動詞が自動詞であり、前置詞句が複数の制約カテゴリのうちの１つに意味論的に分類されず、語句を直接目的語で言い換える（または他の言語に翻訳する）ことができる場合、Ｗｈａｔスロットへのリンキングとして取り扱うことができる。表６６に、既定スロットとしてＯｂｌｉｑｕｅをトリガする語句を例示するいくつかの例が用意されている。
【０３５４】
表６６：ＯｂｌｉｑｕｅａｓＤｅｆａｕｌｔ
【０３５５】
【表６２】
2005332380.tif 000070
【０３５６】
これらは、意味論的に首尾一貫しているクラス（ｈｏｐｅ  ｆｏｒ、ｗａｔｃｈ  ｆｏｒ、ｗａｉｔ  ｆｏｒ）に関連付けられるか、または並べ替えの格標示としてこの方法で特定の前置詞を取る動詞の集まりに対し個別に標示されうる（例えば、ｆｉｎｄ  ａｎｄ  ｌｏｏｋ  ｆｏｒ）。
【０３５７】
動詞のクラスは、フレーム内のＷｈｏおよびＷｈａｔのほかに（またはそれの代わりに）スロットを持つことにより、既定と異なることがある。さらに、動詞のいくつかのクラスは、統語的主語または目的語をＷｈｏまたはＷｈａｔスロットにではなくＬＯＭの制約にリンクする。つまり、既定スロットのいずれかまたは両方が制約により置き換えられるということである。
【０３５８】
ＳｕｂｊｅｃｔＡｓＲｅｓｔｒｉｃｔｉｏｎパターンは、主語をＷｈａｔスロットにではなく、制約にリンクする。例えば、動詞「ｒｅｃｅｉｖｅ」は、「Ｇｏａｌ」を主語として取る。
【０３５９】
[The website]Goal received the data.
[The garden] swarmed with bees.〜Bees swarmed in the garden.
同様に、ＯｂｊｅｃｔＡｓＲｅｓｔｒｉｃｔｉｏｎパターンは、統語的目的語がＷｈａｔではなくＧｏａｌであるフレームを提示する。例えば、動詞「ｅｎｔｅｒ」は、統語的目的語が、ＷｈａｔではなくＧｏａｌまたは場所であるフレームにマッピングする。
【０３６０】
Enter [the chat room]Goal (「Enter in(to) the chat room」（チャットルームに入る）、「Go in the chat room」（チャットルームに入る）と比較)
フレームは、さらに、意味論的に斜格として１つまたは複数の付加的制約を伴う点で既定と異なる場合がある。ＡｄｄｉｔｉｏｎａｌＲｅｓｔｒｉｃｔｉｏｎパターンは、既定スロットに加えて、付加的制約を斜格項または節補語をリンクする。例えば、状態動詞の変化では、以下に示すように、付加的Ｇｏａｌを取るか（動詞「ｒｅｓｅｔ」の場合のように）、またはＳｏｕｒｃｅとＧｏａｌの両方を取る（動詞「ｃｈａｎｇｅ」の場合など）ことができる。
【０３６１】
Reset [the default font]what [to Times New Roman]Goal.
Change [the font]what [from Arial]Source [to Times New Roman]Goal.
さらに、Ｆｒａｍｅｓは、上記の非既定リンキング型（Ｕｎａｃｃｕｓａｔｉｖｅ、ＳｌｏｔＡｓＲｅｓｔｒｉｃｔｉｏｎ［ｓｕｂｊｅｃｔ  ｏｒ  ｏｂｊｅｃｔ］、およびＡｄｄｉｔｉｏｎａｌＲｅｓｔｒｉｃｔｉｏｎ）のうちの１つまたは複数を組み合わせることなど、様々な方法で既定と異なるようにできる。さらに、動詞は、異なる意味を取ると解釈できる、複数のフレームを提示することができる。既定のフレームは、「ｅｎｔｅｒ」の一方の意味で持続し、ＳｌｏｔＡｓＲｅｓｔｒｉｃｔｉｏｎは他の意味で持続する。動詞「ｅｎｔｅｒ」は、文脈依存の場合がある。
【０３６２】
Enter [the data]What (into the form).
Enter [the chat room]Goal
キーワード「ｋｅｅｐ」は、異なる意味を持つ既定のフレームと３つの非既定フレームを取る。例えば、以下のようになる。
【０３６３】
Default: Keep [the file]What
AdditionalRestriction (Location): Keep [the file]What [on the desktop]Location.
AdditionalRestriction (Goal): Keep [Bill Gates]What [from emailing me]Source
Unaccusative: The data won't keep.
一般に、少なくとも１つの言語で既定と異なる動詞について、サポートされているすべての言語にわたって語彙意味論構造フレームを備えることが望ましい。本開示の目的のために、他動詞と自動詞の両方についてこれが正しいと仮定する。
【０３６４】
いくつかの動詞（「ｅｘｐａｎｄ」、「ｉｎｃｒｅａｓｅ」など）では、自動詞に対しては非対格パターンのみが正当である。他の動詞については、非対格パターンリンキングは、付加オプションである。
【０３６５】
表６７は、付加的制約を持つＬＳＳ  Ｆｒａｍｅｓによってモデル化できる語句／語の例をいくつか例示している。それぞれの例では、制約は、既定の項を置き換えるか、または項をフレームに追加する。原理上、それぞれの制約は、主語位置に、目的語位置に、または付加的斜格項として、出現する可能性がある。少数の制約は、下記のように、関与部をＷｈｏおよびＷｈａｔスロットに付加する。関係のある名詞句（ＮＰ）フレームも与えられている。
【０３６６】
表６７：付加的制約を持つＬＳＳ  Ｆｒａｍｅｓによりモデル化される随伴
随伴
主語位置で
Meet: My daughter and I met
Chat: My friend and I chatted.
目的語位置で
Accompany: My daughter accompanied me to Minneapolis.
英語では、付加的制約は、通常、代名詞「ｗｉｔｈ」またはたぶん「ａｇａｉｎｓｔ」が先頭に付く。様々な動詞サブクラスで、関連する意味について代名詞または代名詞句を選択する。サンプルが以下の表６８に示される。
【０３６７】
表６８：付加的制約を持つＬＳＳ  Ｆｒａｍｅｓ
Abscond: The Enron executives absconded with the money. ()
Accommodate: indulge
Accredit: accredit, credit
Ache: ache, burn, itch
Arrange
英語では、Ａｃｃｏｍｐａｎｉｍｅｎｔ制約は、関与部をＷｈｏおよびＷｈａｔスロットに追加することもできる。これはこの制約が修飾語句であるフレームについては正しいが、「相互」動詞と特に共通である。表６９は、Ｏｂｌｉｑｕｅのいくつかの例を既定のスロットとして示す。
【０３６８】
表６９：既定のスロットとしての斜格
Who
主語相互関係
Chat: I IMed with Mary - Mary and I IMed; chat, discuss, talk, visit
Agree
Alternate
Unaccusatives: The file merged (together) with the data〜The file and the data merged (together).
What
目的語相互関係：
Merge: I merged the files with the data, I merged the data and the files
Acquaint: I familiarized them with the topic; acquaint
英語では、付加的制約は、「Ａｌｌｏｃａｔｉｏｎ」に関してＰＰ「ｆｏｒ」が先頭に付く。様々な動詞サブクラスは、関連する意味についてこのＰＰを取る。サンプルを以下に示す。
【０３６９】
Adapt: Adapt the movie for the stage.
Allocate: Allocate funds for linguistics; allocate, appropriate,
Appropriate: Appropriate funds for increased wages
Assign: Assign a day for the performance
Nominate: Nominate candidates for congress
Transcribe: Transcribe the music for trumpet
Train: Train for a marathon
ＡｓＢｅｉｎｇ制約に関する二次述語は、付加的制約として使用することができる。語句のいくつかの例を以下の表７０に示す。
【０３７０】
表７０：ＡｓＢｅｉｎｇ制約の二次述語
名詞句
Make me administrator
付加的語句
mark messages low-priority
judge the data correct
mark that completed
mark low priority
judge the data correct
代名詞句（ａｓ）異形
mark task one as done
Mark messages as follow-up
mark that as completed
mark as low priority
judge the data as correct
付加的制約
Show my status as busy
use as text file
save as file.doc
Log in as Administrator
put this message as message number two
Beneficiary制約に関する付加的制約を以下の表７１に示す。
【０３７１】
表７１：付加的制約を持つＢｅｎｅｆｉｃｉａｒｙ
目的語位置で
Benefit: Relaxed stock option laws benefited Enron; benefit, gain, profit
Unaccusative: Enron benefited from relaxed stock option laws
間接目的語位置で
Benefit: Relaxed stock option laws benefited Enron; benefit, gain, profit
Unaccusative: Enron benefited from relaxed stock option laws
付加的制約
ＰＰ−ｆｏｒおよび間接目的語
Build: arrange, assemble, bake Create: design, dig, mint
Prepare: bake, blend, boil, clean, clear, cook, fix, fry...
Performance: dance, draw, ding, play, recite...
Get: book, buy, call, cash, catch
制約型のいくつかは、動詞フレームについては適用不可能である場合がある。しかし、付加的制約は、それでも、前置詞句が比較集合を持ち込む場合などには、呼び出すことができる。
【０３７２】
Ｄｉｒｅｃｔｉｏｎ制約は、「ｍｏｖｅ  ｔｈｅ  ｃｕｒｓｏｒ  ｕｐ（ｔｈｅ  ｐａｇｅ）」という語句の場合のように付加的制約を必要とすることがある。さらに、方向要素が動詞自体の中に合成される場合（「ｔｈｅ  ｓｔｏｃｋｓ  ｒｏｓｅ／ｆｅｌｌ／ａｄｖａｎｃｅｄ／ｒｅｔｒｅａｔｅｄ」または「ｒｏｔａｔｅ  ｔｈｅ  ｐｉｃｔｕｒｅ」など）、付加的制約が必要になることがある。
【０３７３】
付加的制約を有するＬＳＳは、以下の語句から、主語位置に含まれる制約例とともに理解できる。
【０３７４】
This document exemplifies table construction
Sample code illustrates possible applications.
範囲制約は、通常、目的語位置または付加的制約位置内に収まる。運動型動詞のすべての様式はＥｘｔｅｎｔ目的語をとりうる（例えば、「ｗａｌｋ  ｔｈｅ  ｍａｌｌ」、「ｃｒａｗｌ  ｔｈｅ  ｗｅｂ」、「ｒｕｎ  ｔｈｅ  ｍａｒａｔｈｏｎ」など）。Ｅｘｔｅｎｔ制約を使用してモデル化できる語句の例が表７２に示されている。
【０３７５】
表７２：Ｅｘｔｅｎｔ制約によりモデル化される語句の例
目的語位置で
The crawler traverses the web.
The data in this spreadsheet spans several builds.
付加的制約
I want a border around this text.
Maintain a uniform appearance throughout the web site.
Run through the spec before the review.
Ｇｏａｌ制約は、特にクラスまたは状態の変化に関して、付加的制約を必要とする場合がある。いくつかの動詞とともに個癖的にＧｏａｌｓとして振る舞う前置詞句のスコープは、実装よって異なることがある。Ｇｏａｌとして個癖的に振る舞う前置詞句の例として、「ｓａｖｅ  ａｓ  ｆｉｌｅ．ｔｘｔ」（「ｓａｖｅ  ｔｏ  ｆｉｌｅ．ｔｘｔ」）および「ｒｅｓｃｈｅｄｕｌｅ  ｆｏｒ  ５：００」（「ｒｅｓｃｈｅｄｕｌｅ  ｔｏ  ５：００」）をあげる。
【０３７６】
いくつかの動詞は、Ｂｉｔｒｅｃｓ（Ｇｏａｌの振る舞いが単一動詞による場合）またはＬＳＳクラス（項目のクラスが個癖的にゴールを取る場合）のいずれかで個癖的ゴールを取る必要がある場合がある。付加的ゴールは、単に追加されるだけであり、パターンを語彙集からクラスの中に引き出して、発見されたとおりに処理することができる。
【０３７７】
場所に関連付けられている付加的制約は、以下の表７３に例示されているようにモデル化することができる。
【０３７８】
表７３：場所
Keep, Stand, CausedGoalOfMotion
主語位置で
場所格交替（Ｌｅｖｉｎ２.３）：The garden swarmed with bees (cf. Bees swarmed in the garden)
目的語位置で
Search: Canvass the neighborhood, Search the web
付加的制約
他動詞：
Keep: Keep the file on the desktop (hold, keep, locate, store)
Get: Find a book on Amazon.com
自動詞
Stay: Stand here, Stay home
Ｍｅａｎｓ制約も、表７４に示されているように付加的制約でモデル化することができる。
【０３７９】
表７４：手段
道具主語：The knife cut the cake
付加的制約
Adorn: adorn, festoon, decorate
Adulterate: adulterate, alloy, pollute
Anoint
Afflict
Aid: aid, assist, help
Analogize
Anoint
Answer
Arm
Assail: attack,
ＳｏｒｔＯｒｄｅｒ制約も、表７５に示されているように付加的制約でモデル化することができる。
【０３８０】
表７５：ＳｏｒｔＯｒｄｅｒ
【０３８１】
【表６３】
2005332380.tif 000071
【０３８２】
同様に、構造基準制約も、表７６に示されているように付加的制約でモデル化することができる。
【０３８３】
表７６：ＳｔｒｕｃｔｕｒｅＣｒｉｔｅｒｉａ
【０３８４】
【表６４】
2005332380.tif 000072
【０３８５】
一般に、Ｔｉｍｅ項を取るクラスは、型ＴｉｍｅのＭｅａｓｕｒｅ制約を取るクラスとして処理することが可能であるが、それらは完全な時間表現を実現できる。例えば、語句「I spent at least an hour from 9 to 5 every day for weeks looking for a piano.」は、時間項または型Ｔｉｍｅの測定制約を取るクラスとしてモデル化することができる。
【０３８６】
表７７は、付加的制約を使用してモデル化できるＴｏｐｉｃ語句例をいくつか例示している。
【０３８７】
表７７：Ｔｏｐｉｃ
Spact: talk about X, talk X, remind X that Y, book on Martin Luther
主語位置で
Her finances don't concern you; concern
目的語位置で
Discuss: The article addresses adolescents in the 20＊t＊h century; address, cover, discuss
付加的制約
PP[(about, concerning, on, regarding)] takes either NP objects (about cats) or clausal eobjects (about John coming to Seattle)
PRPRTCL
アドレスの目的語は、話題ではなく、受取人とすることも可能である。
【０３８８】
Ｄ５.エンティティのクラス
このセクションでは、Ｐｅｒｓｏｎ  Ｅｎｔｉｔｉｅｓ、Ｐｌａｃｅ  Ｅｎｔｉｔｉｅｓ、およびＬＳＳ  ＥｎｔｉｔｉｅｓなどのＳＰＬライブラリとしてサポートされているエンティティの型に基づいてデータを収集する場所を述べる。さらに、ＳＰＬライブラリは、各ＬＳＳフレームクラスに対応する名詞句（ＬＳＳエンティティ）のクラス、特に付加的制約を取るクラスを含むことができる。：
ＳＰＬライブラリは、さらに、Ｒｅｓｔｒｉｃｔｉｏｎクラスを含むこともできる。制約毎に、制約を指定するために使用することが可能な名詞句の（小さな）集合がある。ＳＰＬでは、これらは構造体の小さな集合内で識別され、制約スロットフィラーの存在を知らせることができる。例えば、「ｔｏｐｉｃ」が主語または目的語または連結詞である場合、Ｔｏｐｉｃ制約スロットフィラー（太字部分）は補完位置にある。
【０３８９】
Find discussions where the economy is the topic.
Find discussions where the topic is the economy.
同様に、「ｔｏｐｉｃ」がＡｓＢｅｉｎｇスロットを埋める場合、それが付くエンティティがＴｏｐｉｃスロットを埋める。
【０３９０】
Find discussions that have the economy as a topic.
これらの構造は、Ｔｏｐｉｃ制約として示される構造とともに正規化されるべきである。
【０３９１】
Find discussions about/on/concerning/regarding the economy.
「ｔｈｅｍｅ」、「ｍａｔｔｅｒ」、「ｓｕｂｊｅｃｔ」、「ｉｓｓｕｅ」、「ｆｏｃｕｓ」、および「ａｒｅａ」のような同義語は、ＴｏｐｉｃＥｎｔｉｔｙでもありうる。さらに、開発者は、「ｓｕｂｊｅｃｔ  ｉｎ  ａｎ  ｅｍａｉｌ  ａｐｐｌｉｃａｔｉｏｎ」など、開発者のシナリオにより強く限定された話題単語をエンティティクラスに付加することができる。
【０３９２】
Ｅ.意味論プログラミング言語（ＳＰＬ）
Ｅ１.アーキテクチャ
ＳＰＬは、専用プログラミング言語であり、随伴するランタイムプラットフォームを利用することにより、アプリケーション開発者はリッチな自然言語（ＮＬ）対応のコマンドおよび制御（Ｃ＆Ｃ）機能をアプリケーション用に構築することができる。（ＳＰＬで使用可能にできるコマンドおよび制御シナリオ、および例えばＯｕｔｌｏｏｋ対応のコマンドの種類の詳細については付録Ｉを参照のこと。）
ＳＰＬは、発話から意味を引き出す作業を容易にし、その意味に基づく作用を容易にするためのオーサリングソリューションである。ＳＰＬは、開発者側でそのスケーラビリティの負担を負わなくても複雑な発話に合わせてスケーリングできるように設計されている。ＳＰＬのゴールは、開発者に大きな負担を余分にかけることなく音声とテキストの両方に対するオーサーシップを容易にすることである。特に、言語／意味解析についてほとんどまたはまったく知らない開発者がＮＬアプリケーションを開発できるようにするＮＬオーサリングツールを提供することが望ましい。一般に、ＳＰＬは、音声入力用のオーサリングとテキスト入力用のオーサリングとの差を最小限に抑えるように設計されている。しかし、音声認識には問題があるため、いくつかの相違点を開発者に見せなければならない可能性がある。
【０３９３】
ＮＬアプリケーションはＳＰＬなしのＬＯＭにより解析エンジンとインターフェースするように作成することができるが、そのようなプログラミングは困難であり、開発者側で必要とする言語学に関する知識が多くなり、また語彙構造に関するハウスキーピングの手間も増える。結局、ＳＰＬは、特定の要素を抽出することにより、開発者が解析コンポーネントではなくアプリケーションの機能に集中できるように開発を容易にできる。
【０３９４】
これは、専用プログラミング言語の背後にある核心であり、これにより、開発者はハウスキーピングおよび配管接続作業を免れ、手元の作業に集中できる（この場合、そのＮＬ対応アプリケーション）。開発者は、ＳＰＬを使用することにより、プログラミング空間の基礎を自然で直観的な方法により表現することができる。
【０３９５】
一般に、自然言語の意味論は複雑であり、本質的に曖昧である。人間は、大量の世界知識および文脈を用いて、意味の理解および明確化を行う。実際、人間は、このような理解および明確化を自然に行っているため、このプロセスを意識することはあまり多くない。
【０３９６】
アプリケーションが発話の意味に基づいて動作できる場合、発話の意味論がアプリケーションにとってどのような意味があるかを決定しなければならないだけでなく、自分の知識および文脈に応じて意味を明確化する権限も有していなければならない。したがって、ＳＰＬは、アプリケーション領域に関して推論し、その推論が意味解析に深い、意味のある形で影響を及ぼすようにする能力を開発者に提供する。アプリケーション特有の推論との深い統合は、本質的に、ＳＰＬに組み込まれている。
【０３９７】
一実施形態において、高いレベルで、開発者が構文に対してではなく発話の意味論のみに対してオーサリングするようにするのがＳＰＬのアプローチである。いくつかの実施形態では、構文にアクセスする裏口的な手段が用意されている場合がある。これは、ＬＯＭを通じて実現される（上のセクションＤで説明した）。簡単にいうと、ＬＯＭでは、領域に依存しない方法で発話（話の内容）の意味論をモデル化する。ＳＰＬプログラミングモデルでは、様々な方法により、意味論モデルを具現化する。
【０３９８】
ＳＰＬプログラムに対する発話の解決を通じて、ＳＰＬは、アプリケーション内のエンティティに束縛される話の内容の強い型付けの領域依存モデルを構築する。また、意味論は構文から分離されるため、多言語サポートがかなり実現しやすいことも指摘するのに値する。
【０３９９】
ＳＰＬは、２つの主要な部分からなる。第１は、強い型付け、手続き型、イベント駆動、およびオブジェクト指向の言語である。一実施形態では、ＳＰＬは、今日主流派開発者に非常になじみのあるＣ＃（企業規模のアプリケーションを構築するためのオブジェクト指向タイプセーフプログラミング言語）に基づいている。他の実施形態では、ＳＰＬは、属性を使用してＣ＃で完全に書かれている。ＳＰＬを設計する際に、ＳＰＬが新しいプログラミングアプローチではないことが重要であった。開発者の既存の知識および経験を活かし、無駄にしないためである。第２の部分は、ＳＰＬの言語意味論により、話の内容の領域依存モデルを構築するランタイムである。
【０４００】
ＳＰＬにより、開発者は、既存のアプリケーションに影響を及ぼすことなく、発話の意味論的意味を既存のアプリケーションインターフェースまたはオブジェクトモデルにバインドすることができる。ＳＰＬを使用すると、開発者は適当な位置で領域に関する知識を推論するコードを書くことができるが、ＳＰＬは．Ｎｅｔ  Ｃｏｍｍｏｎ  Ｌａｎｇｕａｇｅ  Ｒｕｎｔｉｍｅにコンパイルするので、開発者は、Ｍｉｃｒｏｓｏｆｔ（登録商標）．ＮＥＴ（登録商標）プログラミング言語をはじめとする、任意のプログラム言語でそのコードを自由に書くこともできる。
【０４０１】
ＳＰＬの基本構文は、エンティティ（名詞）、フレーム（動詞）、制約（エンティティ間の関係）、コマンド（アプリケーションタスクのエントリポイント）、ＮａｍｅｄＥｎｔｉｔｉｅｓおよびＤｅｎｏｔｅｒｓである。これらは、ＳＰＬの主要な第１種の型である。言語は、設計上コマンド中心であるが、それは、アプリケーションの自然言語対応をコマンドおよび制御（Ｃ＆Ｃ）機能用に設計されているからである。
【０４０２】
ＳＰＬフレームワークについて詳述する前に、イメージを思い浮かべて本文中の開示の残り部分について理解できるようにＳＰＬの簡単な例について説明する。表７８は、「ｓｅｎｄ  ｅｍａｉｌ  ｔｏ  Ｂｏｂ」コマンドシナリオを処理するＳＰＬコードを例示している。このコマンドシナリオは、開示の残りの部分において何回も参照することになる。
【０４０３】
「ｃｏｍｍａｎｄ」で最高レベルから始めると、ＳＰＬコードがすでに導入されているＬＯＭモデルに書き込まれることが理解されるであろう（セクションＤを参照）。コマンドは、フレームと突き合わせてオーサリングされる。フレームは、通常、動詞を表すオブジェクトである。基本フレームは、１つの動詞を表すフレームであり、解析システムにより供給される。開発者は、さらに、Ｆｒａｍｅｓを説明しているセクションでさらに詳しく説明されている特徴である、自分の動詞フレームも定義することができる。
【０４０４】
表７８：「Ｓｅｎｄ  Ｍａｉｌ  Ｔｏ  Ｂｏｂ」ＳＰＬコード
【０４０５】
【表６５】
2005332380.tif 000073
【０４０６】
ＳｅｎｄＭａｉｌＣｏｍｍａｎｄは、送られるオブジェクト（「ＤｏｎｅＴｏ．ｗｈａｔ」スロット）がＭａｉｌＥｎｔｉｔｙである場合にＭｙＳｅｎｄＦｒａｍｅを使用するアプリケーションタスクのエントリポイントを定義する。このコマンドは、タスクをカプセル化し、開発者が特定の初期化およびクリーンアップを実行できるようにし、プラットフォームにアプリケーションへのエントリポイントを設定する。
【０４０７】
表７９は、ＭｙＳｅｎｄＦｒａｍｅのＳＰＬコードを例示している。
【０４０８】
表７９：ＭｙＳｅｎｄＦｒａｍｅ
【０４０９】
【表６６】
2005332380.tif 000074
【０４１０】
ＭｙＳｅｎｄＦｒａｍｅコードブロックでは、領域独立の基本的な「ｓｅｎｄ」フレーム（プラットフォームにより提供される）から継承し、「ＤｏｎｅＴｏ．ｗｈａｔ」をＭａｉｌＥｎｔｉｔｙへサブタイプ化するアプリケーション固有のフレームである、ＭｙＳｅｎｄを定義する。「ＤｏｎｅＴｏ．ｗｈａｔ」は、送られるオブジェクトである。
【０４１１】
「ｔｏ  Ｂｏｂ」に送ることの意味論は、Ｇｏａｌ制約（プラットフォーム、例えば、ＬＯＭに基づくＳＰＬにより供給される）により捕捉され、これは「ｗｉｔｈ  ｒｅｓｔｒｉｃｔｉｏｎ」節を介して「ｓｅｎｄ」にリンクされる。このリンキングに加えて、「Ｂｏｂ」に送られるエンティティは、さらに、ＲｅｃｉｐｉｅｎｔＥｎｔｉｔｙにも接地される。
【０４１２】
すでに説明したように、Ｒｅｓｔｒｉｃｔｉｏｎｓは、通常はエンティティ間の、型付き意味論的関係である。ＳＰＬプラットフォームは、あらかじめ定められた関係の基本集合を備える。開発者は、制約の基本集合をサブタイプ化して、自分の関係を作成することができる。定義済み制約のいくつかの例として、Ｌｏｃａｔｉｏｎ（「ｍａｉｌ  ｉｎ  Ｉｎｂｏｘ」）、Ｔｉｍｅ（「ｄｅｌｅｔｅ  ａｆｔｅｒ  ３  ｄａｙｓ」）、Ｐｏｓｓｅｓｓｏｒ（「Ｂｏｂ’ｓ  ｂｏｏｋ」）、Ｔｏｐｉｃ（「ｍａｉｌ  ａｂｏｕｔ  ｃａｔｓ」）がある。
【０４１３】
制約に関する重要事項の１つは、構文の異形は意味論的プラットフォームにより正規化されるということである。例えば、Ｔｏｐｉｃは、「ｍａｉｌ  ａｂｏｕｔ  ｃａｔｓ」、「ｍａｉｌ  ｗｉｔｈ  ｃａｔｓ  ａｓ  ｔｈｅ  ｓｕｂｊｅｃｔ」、「ｍａｉｌ  ｒｅｇａｒｄｉｎｇ  ｃａｔｓ」、「ｍａｉｌ  ｗｉｔｈ  ｓｕｂｊｅｃｔ  ｃａｔｓ」など様々な方法で意味論的に表現することができる。異なる言語は、Ｔｏｐｉｃの意味論を異なる形で表現する。これらの異形は、意味論的プラットフォームにより正規化されるため、開発者は、可能なそれぞれの意味論的異形と突き合わせるのではなく、Ｔｏｐｉｃ制約と突き合わせてプログラムするだけでよい。
【０４１４】
表８０は、本発明の一実施形態によるＭａｉｌＥｎｔｉｔｙ制約の構文を例示している。
【０４１５】
表８０：ＭａｉｌＥｎｔｉｔｙ
【０４１６】
【表６７】
2005332380.tif 000075
【０４１７】
この例では、ＭａｉｌＥｎｔｉｔｙは、単語のリストにより定義され、表される。表す単語は、通常、別々に定義され、通常は自ファイル（ローカライゼーションファイルなど）内に定義される。
【０４１８】
フレームのように、エンティティも、それらに適用される制約を持つことができる。表８１は、制約を持つエンティティの構文を例示している。
【０４１９】
表８１：制約を持つエンティティ
【０４２０】
【表６８】
2005332380.tif 000076
【０４２１】
開発者の観点からすると、この構文では、メールアイテムがＭａｉｌＦｏｌｄｅｒ内にあるというプロパティ（制約）を持ちうることを宣言する。エンティティ−関係の観点から、ＭａｉｌＥｎｔｉｔｙとＭａｉｌＦｏｌｄｅｒは、Ｌｏｃａｔｉｏｎ関係を介して関係がある。実行時に、Ｌｏｃａｔｉｏｎ制約を持つＭａｉｌＥｎｔｉｔｙのインスタンスは、特定のＭａｉｌＦｏｌｄｅｒ内にあることに制約されているメールアイテムの集合を表す。
【０４２２】
発話「ｓｅｎｄ  ｍａｉｌ  ｔｏ  Ｂｏｂ」または「ｓｅｎｄ  Ｂｏｂ  ｍａｉｌ」に対し、ＳＰＬランタイムプラットフォームは、ＳｅｎｄＭａｉｌＣｏｍｍａｎｄコマンドを突き合わせて解決する。図４は、本発明の一実施形態によるＳｅｎｄＭａｉｌＣｏｍｍａｎｄコードを通じて解決をトレースする流れ図である。当業者であれば、コマンドの解決は実装により異なることは理解するであろう。例えば、表７８を参照すると、Ｂｅｇｉｎ、Ｓｕｃｃｅｓｓ、およびＦａｉｌｕｒｅ節は、それぞれ、オプションである。ＯｎＲｅｓｏｌｖｅ節は、特定の実装に応じて、これらの節のうちのいずれか１つ、節の任意の組合せを含むか、または節のうちのどれも含まない。
【０４２３】
図４の流れ図の目的のために、解析エンジンは、すでに、発話を宣言スキーマで定義され、ＬＯＭから派生した型にマッピングしていることは理解されるであろう。例えば、Ｄｅｎｏｔｅｒオブジェクトは、解析エンジンにより、すでに考察されている。さらに、コードがそれぞれの要素に対するＢｅｇｉｎ節、Ｓｕｃｃｅｓｓ節、およびＦａｉｌｕｒｅ節を含むことが仮定される。また、流れ図からは一部の詳細が省かれていることが重要であるが、それは、部分的には、そのような詳細は実装に固有であり、いたずらに説明をややこしくすることになるからである。
【０４２４】
そこで図４を参照すると、発話を受け取った後、ＳｅｎｄＭａｉｌＣｏｍｍａｎｄのｂｅｇｉｎ  ｒｅｓｏｌｕｔｉｏｎ節が呼び出される（ブロック４００）。ｂｅｇｉｎ  ｒｅｓｏｌｕｔｉｏｎ節が成功しない場合、特定の実装に応じて、またアプリケーションで利用可能と思われる他のコマンドに応じて、異なるコマンドが呼び出されるか、または（オプションにより）インタプリタが単に解決に失敗するだけである（ブロック４０２）。
【０４２５】
ＳｅｎｄＭａｉｌ  Ｃｏｍｍａｎｄのｂｅｇｉｎ  ｒｅｓｏｌｕｔｉｏｎ節の呼び出しが成功すると、ＳＰＬインタプリタは、ＳｅｎｄＭａｉｌ  Ｃｏｍｍａｎｄが使用するＭｙＳｅｎｄ  Ｆｒａｍｅに対するｂｅｇｉｎ  ｒｅｓｏｌｕｔｉｏｎ節を呼び出す（ブロック４０４）。ＭｙＳｅｎｄ  Ｆｒａｍｅのｂｅｇｉｎ  ｒｅｓｏｌｕｔｉｏｎ節が失敗した場合、ＳｅｎｄＭａｉｌ  Ｃｏｍｍａｎｄ  ｆａｉｌｕｒｅ節が呼び出され（ブロック４０６）、ＳＰＬインタプリタは、オプションにより、異なるコマンドを呼び出すか、または解決に失敗する可能性がある（ブロック４０２）。
【０４２６】
ＭｙＳｅｎｄ  Ｆｒａｍｅのｂｅｇｉｎ  ｒｅｓｏｌｕｔｉｏｎ節が成功した場合、ＭａｉｌＥｎｔｉｔｙ  Ｂｅｇｉｎ  Ｒｅｓｏｌｕｔｉｏｎ節が呼び出される（ブロック４０８）。ＭａｉｌＥｎｔｉｔｙのｂｅｇｉｎ  ｒｅｓｏｌｕｔｉｏｎ節の呼び出しが失敗した場合、次に生じる事は、たいがい実装に依存する。図に示されているように、特定の実装に応じて、ＭａｉｌＥｎｔｉｔｙ  ｂｅｇｉｎ  ｒｅｓｏｌｕｔｉｏｎ節は、一般的な失敗（オプション１）を暗示するか、無視されるか（オプション２）、または他のオペレーションの実行を引き起こし、発話の明確化が行われる（ブロック４１０）。これらの「他のオペレーション」は、解決されようとする入力の部分に対し異なる制約節を使用する試みを含む場合がある。制約節は、曖昧さのため、まったく、異なる制約に対する節ですらありうる。
【０４２７】
失敗が一般的失敗を暗示していると理解される場合（オプション１）、ＳＰＬインタプリタは、オプションにより、異なるコマンドを呼び出すか、または解決に失敗する（ブロック４０２）。失敗が無視された場合（オプション２）、ＳＰＬインタプリタは、単純に、ＭｙＳｅｎｄフレームのｓｕｃｃｅｓｓ節を呼び出し（ブロック４２０）、ＳｅｎｄＭａｉｌ  Ｃｏｍｍａｎｄのｓｕｃｃｅｓｓ節を呼び出し（ブロック４２２）、ＳｅｎｄＭａｉｌ  Ｃｏｍｍａｎｄ  Ｏｂｊｅｃｔを「ａｃｔｕａｌ  ｉｎｔｅｒｐｒｅｔａｔｉｏｎ」リストに追加する（ブロック４２４）ことができるだけである。他のオペレーションが開発コードにより必要とされる場合、ＳＰＬインタプリタは、自然言語解析エンジンとの通信および／または発話を明確化することを試みるクライアントアプリケーションへのコールバックなどの処理をさらに実行することができる。
【０４２８】
ＭａｉｌＥｎｔｉｔｙのｂｅｇｉｎ  ｒｅｓｏｌｕｔｉｏｎ節の呼び出しが成功した場合、ＭａｉｌＥｎｔｉｔｙ  ｓｕｃｃｅｓｓ節が呼び出される（ブロック４１２）。次に、Ｒｅｓｔｒｉｃｔｉｏｎ  ｂｅｇｉｎ  ｒｅｓｏｌｕｔｉｏｎ節が呼び出される（ブロック４１４）。Ｒｅｓｔｒｉｃｔｉｏｎ  ｂｅｇｉｎ  ｒｅｓｏｌｕｔｉｏｎ節が失敗した場合、流れはブロック４１０に進む（上述）。Ｒｅｓｔｒｉｃｔｉｏｎのｂｅｇｉｎ  ｒｅｓｏｌｕｔｉｏｎ節が成功した場合、Ｒｅｓｔｒｉｃｔｉｏｎ  ｓｕｃｃｅｓｓ節が呼び出される（ブロック４１６）。Ｒｅｓｔｒｉｃｔｉｏｎ節は、ＭｙＳｅｎｄ  Ｆｒａｍｅで、ＭａｉｌＥｎｔｉｔｙスロットとともに呼び出される（ブロック４１８）。この呼び出しが失敗した場合、流れはブロック４１０に進む（上述）。呼び出しが成功した場合、ＭｙＳｅｎｄ  Ｆｒａｍｅのｓｕｃｃｅｓｓ節が呼び出され（ブロック４２０）、ＳｅｎｄＭａｉｌ  Ｃｏｍｍａｎｄのｓｕｃｃｅｓｓ節が呼び出され（ブロック４２２）、ＳｅｎｄＭａｉｌ  Ｃｏｍｍａｎｄオブジェクトが「ａｃｔｕａｌ  ｉｎｔｅｒｐｒｅｔａｔｉｏｎ」リストに追加される（ブロック４２４）。
【０４２９】
アプリケーションおよび開発者によっては、コードブロックは事実上無限大の順列を引き起こすことが理解されるであろう。一実施形態では、失敗した解決の既定では、ｆａｉｌｕｒｅ節を呼び出して、実行を停止するようにできる。他の実施形態では、開発者は、アプリケーションが領域文脈を利用して、曖昧さを解決し、発話の部分的実行を行うように部分的オブジェクトをインスタンス化することを望んでいる場合がある。それぞれの節において、開発者はアプリケーション固有の機能を実行するコードを自由に書くことができる様々な可能性が考えられる。
【０４３０】
好ましい一実施形態では、ＲｅｃｉｐｉｅｎｔＥｎｔｉｔｙは、ＲｅｃｉｐｉｅｎｔＮａｍｅをスロットとして取るＮａｍｅｄ制約節でオーサリングすることも可能である。ＲｅｃｉｐｉｅｎｔＮａｍｅは、意味論的処理が実行される前に受信者名のインスタンスがユーザ入力全体の中に置かれているように定義されたＮａｍｅｄＥｎｔｉｔｙであろう。これにより、ＲｅｃｉｐｉｅｎｔＥｎｔｉｔｙインスタンスの確実な認識が可能になる。
【０４３１】
「Ｂｏｂ」が有効なＲｅｃｉｐｉｅｎｔＥｎｔｉｔｙであると仮定すると、すでに述べたように、ＲｅｃｉｐｉｅｎｔＥｎｔｉｔｙはプログラム内のどこかで定義されている。このインスタンスでは、「ｗｉｔｈ  ｒｅｓｔｒｉｃｔｉｏｎ」は、ＳｅｎｄＭａｉｌＣｏｍｍａｎｄにより使用されるＭｙＳｅｎｄＦｒａｍｅ内にある。「ｗｉｔｈ  ｒｅｓｔｒｉｃｔｉｏｎ」節の内側にあるコードが呼び出される。「ｗｉｔｈ  ｒｅｓｔｒｉｃｔｉｏｎ」の内側のコードを使用すると、開発者は、この制約をある程度自由に拒絶できる。この節が成功した場合、制約は受理される。そうでない場合他の「ｗｉｔｈ  ｒｅｓｔｒｉｃｔｉｏｎ」節は、それらのうちの１つが成功するまで連続して呼び出されるか、またそれらのうちのいずれも実行しない場合には、制約は無視される。他の実施形態では、ｒｅｓｏｌｕｔｉｏｎ節が失敗した場合、失敗解決が呼び出される。最後に、ＭｙＳｅｎｄＦｒａｍｅおよびＳｅｎｄＭａｉｌＣｏｍｍａｎｄのｓｕｃｃｅｓｓ節が、その順序で、呼び出される（ブロック４２０および４２２）。
【０４３２】
一般に、当業者であれば、ＬＯＭ内の、ＳＰＬによって実装される、制約およびその他のオブジェクトは、成功または失敗のいずれかの際に、任意の個数の関数またはプロセスを呼び出すように構成することができることを理解するであろう。流れ図は、流れの例が進行する仕方を示す単純な図である。しかし、他の多数の変更形態が予想され、また本発明が適用可能なクライアントアプリケーション候補と同じくらい多数ある。
【０４３３】
この解決プロセスでは、連結グラフが生成される。それぞれのエンティティは、連結グラフの節点であり、エンティティ間の関係は、ＬＯＭにより定義され、アプリケーション領域と突き合わせて妥当性が確認される。当業者であれば、節点と関係は強く型付けされていることを理解するであろう。連結グラフは、領域の言語で言われた事を表す。
【０４３４】
ＳＰＬオブジェクト（コマンド、エンティティ、フレーム、および制約）の存在は意味解析と連携してオーサリングされたコードにより決定されることに留意されたい。一般に、フレーム、エンティティ、コマンド、または制約と突き合わせて行う解決では、アプリケーション領域に関してそれらのオブジェクトの存在／有効性を判定する必要がある。これらのオブジェクトは、実際には、制約条件が満たされるまで存在しない（有効でない）。これと似たことが、Ｃ＃オブジェクト構文にもいえる。Ｃ＃では、オブジェクトは、開発者が例外を投げるコードを書くためのコンストラクタを用意できる。例外は、何らかの制約条件が満たされない場合にオブジェクトが存在することを妨げる。
【０４３５】
「システム」は、オブジェクトを作成しようとした場合にこれらのコンストラクタを呼び出す。したがって、コンストラクタ内のオーサリングされたコードは、クラスの存在を判別することができる。概念上、そのコア型のＳＰＬ解決では、この概念をさらに一歩進めて、形式化し、よりリッチにし、システムの固有部分にする。満たされなければならない制約条件は、発話の領域オーサリングされた知識および意味解析の組合せである。
【０４３６】
Ｄ３.継承
概念カプセル化および合成は、従来のオブジェクト指向手法（オブジェクト再利用、継承、多態性など）により実現される。例えば、「ｓｅｎｄ  ｍａｉｌ  ｔｏ  Ｂｏｂ」および「ｓｅｎｄ  ｉｎｓｔａｎｔ  ｍｅｓｓａｇｅ  ｔｏ  Ｂｏｂ」をモデル化するには、ＭｙＳｅｎｄＦｒａｍｅをＭａｉｌＥｎｔｉｔｙおよびＩｎｓｔａｎｔＭｅｓｓａｇｅの上位型をとると宣言する。表８２は、本発明の一実施形態によるＭｙＳｅｎｄＦｒａｍｅを例示している。
【０４３７】
表８２：ＭｙＳｅｎｄＦｒａｍｅ
【０４３８】
【表６９】
2005332380.tif 000077
【０４３９】
そこで、「ｓｅｎｄ  ｍａｉｌ」および「ｓｅｎｄ  ｉｎｓｔａｎｔ  ｍｅｓｓａｇｅ」に対する個別のコマンドを以下のように定義することが可能である。
【０４４０】
command SendIMCommand uses MySend<DoneTo.what := InstantMessage>;
command SendMailCommand uses MySend<DoneTo.what : = MailEntity>;
「ｓｅｎｄｉｎｇ  ｉｔｅｍ  ｔｏ  Ｒｅｃｉｐｉｅｎｔ」という概念は、ＭｙＳｅｎｄＦｒａｍｅによりカプセル化され、ＳｅｎｄＩＭＣｏｍｍａｎｄおよびＳｅｎｄＭａｉｌＣｏｍｍａｎｄにより再利用されることが可能である。また、ＭｙＳｅｎｄＦｒａｍｅを合成的に再利用することも可能である。この例が表８３に示されている。
【０４４１】
表８３：ＭｙＳｅｎｄＦｒａｍｅ
【０４４２】
【表７０】
2005332380.tif 000078
【０４４３】
広い意味で、上記の説明は「ｍａｉｌ  ｓｅｎｔ  ｔｏ  Ｂｏｂ」の意味をとらえている。
【０４４４】
一般に、ＳＰＬを使用することで、開発者は、アプリケーション領域を推論し、その推論が意味解析に深い、意味のある形で影響を及ぼすようにすることができる。ＳＰＬでは、この推論を宣言的、手続き的に行うことができる。再びＭａｉｌＥｎｔｉｔｙ構文を参照すると、この構文では、例えばＭａｉｌＥｎｔｉｔｙがＭａｉｌＷｏｒｄｓで規定されている単語のリストにより表されるエンティティであるという宣言的制約条件を設定し、この構文は、ＭａｉｌＦｏｒｌｄｅｒのロケーションにあるということに制約することができる。表８４には、ＭａｉｌＥｎｔｉｔｙが示されている。
【０４４５】
表８４：ＭａｉｌＥｎｔｉｔｙ
【０４４６】
【表７１】
2005332380.tif 000079
【０４４７】
「ｍａｉｌ  ｉｎ  Ｆｏｏ」、「ｍａｉｌ  ｌｏｃａｔｅｄ  ｉｎ  ｆｏｌｄｅｒ  Ｆｏｏ」などの発話は、ＭａｉｌＥｎｔｉｔｙに対して成功するが、それは、ＭａｉｌＦｏｌｄｅｒ上のＮａｍｅｄ制約節がすべての文字列を受け付けるからである。
【０４４８】
場合によっては、「Ｆｏｏ」が本当に現在のユーザのメールボックス内の現在有効なフォルダであるかどうかを判別するコードを作成することが望ましいことがある。これを行う唯一の方法は、実行時に「Ｆｏｏ」の有効性をチェックする手続きコードを書くことである。表８５は、実行時にＦｏｌｄｅｒ名の有効性をチェックするＭａｉｌＦｏｌｄｅｒエンティティの構文を示している。
【０４４９】
表８５：手続きチェックコードを使用するＭａｉｌＦｏｌｄｅｒ
【０４５０】
【表７２】
2005332380.tif 000080
【０４５１】
「Ｆｏｏ」が現在有効なフォルダでなければ、ＭａｉｌＦｏｌｄｅｒの解決は失敗する。特定の実装の詳細に応じて、失敗は一般的な失敗を意味する場合がある。それとは別に、制約が失敗すると、制約が無視される場合がある。一実施形態では、ＭａｉｌＦｏｌｄｅｒの解決が失敗した場合、ＭａｉｌＥｎｔｉｔｙも失敗し、というように解決の連鎖を辿る（例えば、一般的失敗を暗示する）。好ましい一実施形態では、ＭａｉｌＦｏｌｄｅｒの解決が失敗した場合、ＭａｉｌＦｏｌｄｅｒ制約は単に無視されるだけである。当業者であれば、これは簡略化された例であることを理解するであろう。実装に応じて、かなり複雑な有効性チェックを使用することもできる。
【０４５２】
この効果を実現する他の方法では、ＮａｍｅｄＥｎｔｉｔｙ型ＦｏｌｄｅｒＮａｍｅを作成し、それをＮａｍｅｄ制約のスロットとして使用する。
【０４５３】
節を呼び出した場合のよい副作用（開始、成功、失敗、および制約付き）は、開発者が意味論的オブジェクトをアプリケーションオブジェクトにバインドするコードを書くことができることである。例えば、Ｎａｍｅｄ制約節では、開発者は、フォルダアプリケーションオブジェクトへの参照を、名前が有効な場合に取得するコードを作成できる。表８６は、そのような参照のための構文を例示している。
【０４５４】
表８６：意味論的オブジェクトをアプリケーションオブジェクトにバインドするコード
【０４５５】
【表７３】
2005332380.tif 000081
【０４５６】
この構文は、アプリケーション特有のオブジェクト、ＭＡＰＩＦｏｌｄｅｒを意味論的オブジェクト、ＭａｉｌＦｏｌｄｅｒに効果的にバインドする。
【０４５７】
一般に、開発者は、解析のキーポイントでそのアプリケーションのコンテキストおよび状態について推論するコードを容易に作成することができる。この推論は、最終的な解決解析に影響を及ぼすことがある。例えば、「Ｂｏｂ」が有効な受信者かどうかを判別する場合、開発者はシステムの現在のユーザのデータベースにアクセスするコードを作成することができる。それが有効な受信者でなければ、開発者は失敗を処理するコードを作成することが可能である。例えば、開発者は、失敗の時点で直ちに、ユーザを明らかにするためのポップアップウィンドウまたはダイアログを表示し、再表示を生成することなどができる。失敗の時点でユーザに対し即座にフィードバックを返すことにより、システムでは、きびきびとしたきちんと開発されているアプリケーションの出現を助長する。
【０４５８】
それとは別に、開発者は、アプリケーションが適切な状態にない場合に、最上位レベルのＳｅｎｄＭａｉｌＣｏｍｍａｎｄで、コマンドに対し解決を防止するコードを作成することができる。意味解析と領域知識についての推論との間のこの深い統合は、自然言語を理解し、明確化するうえで非常に重要である。
【０４５９】
ＳＰＬでは、開発者側で解決を拒絶するコードを節内に書けるようにすることにより、開発者が不正な解析を容易に拒絶できる。一般に、作成者は、成功する解釈と失敗する解釈に対する多くの制御を主張することができる。場合によっては、作成者がプロセスの早い段階でいくつかの解釈を拒絶するのが望ましいこともある。一般に、作成者が明確化する（曖昧さを除去する）のが早いほど、アプリケーションで曖昧さを管理しやすくなる。曖昧さが少ないほど、解釈は少なくなるということである。自然言語についてオーサリングされたアプリケーションは、複数の解釈を管理するための何らかのメカニズムを備えていなければならない。作成者は、インタプリタが決定している最中に解釈の健全さを評価するコードを作成するか、または意味解析を実行して明確化を行い、いくつかの解釈の集まりのうちから選択した後実行されるコードを作成する（後処理）。前者が管理およびコーディングを容易に行えることを見ることは難しくない。
【０４６０】
さらに、早い段階の解釈を拒絶するほど、最良の解釈を見つけるのが早くなり、また正確に見つけられると考えられる。
【０４６１】
場合によっては、作成者は、プロセスの後のほうで解釈を拒絶したいこともある。早い段階で解釈を拒絶すると、状態および／またはコンテキストを調べ、アプリケーションのオブジェクトモデルについて推論するためにクライアントアプリケーションにコールバックを行う頻度がかなり増える。コールバックがネットワーク全体にわたって行われる場合、コールバックが頻繁だと、システムのオペレーションが低速になることがある。例えば、伝送遅延で、システムは使用不可能に陥ることがありえる。ＳＰＬを使用すると、作成者は、どのようなコールバックをいつ実行するかを完全に制御することができる。したがって、開発者は、独力で、クライアントアプリケーションの性格に応じて、コールバックと後解析の明確化ロジックの正しいバランスを決定できる。
【０４６２】
代わりに、いくつかの実装では、開発者は、解決を拒絶するかどうかを決定する前に解決全体を推論したい場合がある。分離している断片により成功または失敗を判別できない場合もあり得、解決されたツリーに対する大域的推論が必要である。
【０４６３】
ＳＰＬでは、開発者側のニーズとクライアントアプリケーションのニーズとに応じて、早い段階の拒絶と後の段階の拒絶とのバランスの取り方の選択を開発者に任せる。
【０４６４】
すでに説明しているように、ＳＰＬランタイムによるフレーム、制約、およびエンティティの解決は、本質的に、発話の領域依存モデルを構築することである。このように述べたことで詳細が保証される。
【０４６５】
自然言語では、統語的構文を使用して、複数の意味を表現することができる。非常に単純な例として、名詞が後に続く前置詞「ｏｎ」を考察する。例えば、「ｏｎ  Ｆｏｏ」という語句を考える。語句「ｏｎ  Ｆｏｏ」は、Ｌｏｃａｔｉｏｎ（「ｂｏｏｋ  ｏｎ  ｔａｂｌｅ」のような）を参照するか、またはＴｏｐｉｃ（「ｂｏｏｋ  ｏｎ  Ｓｅａｔｔｌｅ」のような）を意味する可能性がある。どの語句が正しいかを判別するために、語句を明確化しなければならない。この明確化は、アプリケーションによってのみ行える。例えば、表８７は、Ａｍａｚｏｎ．ｃｏｍを有効にするための構文を示している。
【０４６６】
表８７：本屋構文
【０４６７】
【表７４】
2005332380.tif 000082
【０４６８】
「ｂｏｏｋ  ｏｎ  Ｆｏｏ」を解決する場合、ＢｏｏｋＥｎｔｉｔｙはＴｏｐｉｃを認識しないので、意味解析ではＬｏｃａｔｉｏｎオブジェクトを出力しない。言われた事の解決されたモデルはＬｏｃａｔｉｏｎを含まない。この「方向付け」は、調整（および／または）、否定、および節のモデル化ではなおいっそう明白である。
【０４６９】
調整のため、ＳＰＬコードで、接続詞および離接的接続詞へのエンティティおよびその修飾語句の分配方法を定義する。発話「ｆｉｎｄ  ｍａｉｌ  ａｎｄ  ｎｏｔｅｓ  ｃｒｅａｔｅｄ  ｙｅｓｔｅｒｄａｙ」については、可能なモデリング選択肢は以下のようになる。
【０４７０】
１．Find (mail created yesterday) and (notes created yesterday).
２．Find (mail) and (notes created yesterday).
３．Find (mail created yesterday) and find (notes created yesterday).
４．Find (mail) and find (notes created yesterday).
「ｃｒｅａｔｅｄ  ｙｅｓｔｅｒｄａｙ」および「ｆｉｎｄ」をそのエンティティ「ｍａｉｌ」および「ｎｏｔｅｓ」とともに分配する方法は、オーサリングされたコードにより決定される。可能な読み取り値は、接続詞と離接的接続詞の両方を含む発話に対してはなおいっそう大きい。作成者がすべての可能性をわかっている必要はない。作成者は、そのアプリケーションの意味論に関して考えるだけである。例えば、ＳＰＬ作成者として、自分のＦｉｎｄＭａｉｌＣｏｍｍａｎｄは型ＭａｉｌＥｎｔｉｔｙのエンティティを認識するだけ、自分のＦｉｎｄＮｏｔｅｓＣｏｍｍａｎｄは型ＮｏｔｅｓＥｎｔｉｔｙのエンティティを認識するだけとなるようにＦｉｎｄＭａｉｌＣｏｍｍａｎｄをコーディングすることが可能である。さらに、ＭａｉｌＥｎｔｉｔｙは、作成時刻という概念を持たないが（これは単に説明を目的としているだけである）、ＮｏｔｅｓＥｎｔｉｔｙは持つ。したがって、上記の発話「ｆｉｎｄ  ｍａｉｌ  ａｎｄ  ｎｏｔｅｓ  ｃｒｅａｔｅｄ  ｙｅｓｔｅｒｄａｙ」については、意味解析は上記のリストから読み取り値４を出力するだけである。
【０４７１】
否定については、オーサリングされたコードは、否定スコープの曖昧さをモデル化する方法を決定する。例えば、発話「Ｄｏｎ’ｔ  ａｌｌｏｗ  ｍａｉｌ  ｆｒｏｍ  Ｊｏｅ」を取る。この語句は以下のように解釈できる。
【０４７２】
１．Don't allow mail from Joe (block it instead)：否定は「ａｌｌｏｗ」に係る。
【０４７３】
２．Don't allow mail from Joe (but allow messages from him)：否定は「ｍａｉｌ」に係る。
【０４７４】
３．Don't allow mail from Joe (but allow mail from someone else)：否定は「Ｊｏｅ」に係る。
オーサリングされたＳＰＬプログラムは、否定が係る範囲およびモデル化の仕方を決定する。意味解析エンジンは、可能なすべての読み取り値を供給する。
【０４７５】
節については、オーサリングされたコードは、節がフレームベースの制約（動詞が先頭に付く制約）としてモデル化されるか、または定義済み制約のうちの１つとしてモデル化されるかを決定する。例えば、「ｂｏｏｋ  ｔｈａｔ  ｄｉｓｃｕｓｓｅｓ  Ｆｏｏ」では、「ｔｈａｔ  ｄｉｓｃｕｓｓｅｓ  Ｆｏｏ」という節は、Ｔｏｐｉｃ制約としてモデル化することができるか、または「ｂｏｏｋ」に対するフレームベースの制約としてモデル化することができる。表８８は、ＢｏｏｋＥｎｔｉｔｙの構文の一例を示している。
【０４７６】
表８８：ＢｏｏｋＥｎｔｉｔｙ
【０４７７】
【表７５】
2005332380.tif 000083
【０４７８】
一般に、ＳＰＬの観点からすると、ＳＰＬプログラムの役割は、アプリケーションの領域の自然言語意味論モデルを定義することである。意味解析の役割は、解析エンジンの言語理解に応じてそのＳＰＬプログラム定義モデルに発話をマッピングすることである。
【０４７９】
プラットフォームの視点では、意味論的プラットフォームの役割は、話の内容の高度に抽象的な領域独立のオブジェクトモデルを定義することである。この観点からは、ＳＰＬコードの役割は、プラットフォームが備える複数の可能性のうちから選ぶことである。
【０４８０】
一般に、ＳＰＬプログラムの解決は、話の内容の領域依存意味論モデルを構築することとして理解できる。この領域依存モデルを構築するプロセスでは、領域独立オブジェクトは強く型付けされ、アプリケーションのオブジェクトに係留（マッピング）できる。
【０４８１】
Ｅ２.型システム
一般に、コアＳＰＬ型は、コマンド、フレーム、エンティティ、および制約である。これらは、その存在を判別するために解決の意味論を必要とするため、解決可能型と呼ばれる。
【０４８２】
【表７６】
2005332380.tif 000084
【０４８３】
「ｏｎ  ｒｅｓｏｌｖｅ」節内にあるすべてが、解決の意味論との関連を持つ。ｂｅｇｉｎ、ｓｕｃｃｅｓｓ、およびｆａｉｌ節はすべてオプションである。「ｏｎ  ｒｅｓｏｌｖｅ」内の節毎に高々１つありうる。
【０４８４】
ｂｅｇｉｎ節は、解決可能型の解決の始めに呼び出される。既定では、節は「真」を返す。開発者は、「偽」を返すことで、この型に対する解決を停止することをＳＰＬインタプリタに指示する。これは、解決失敗を意味し、ｆａｉｌ節が呼び出される。ｂｅｇｉｎ節は、開発者が初期化を実行し、アプリケーションが型を処理する適切なコンテキスト／状態に入っているかどうかをチェックする都合のよい場所である。
【０４８５】
ｓｕｃｃｅｓｓ節は、型に対する解決が成功した場合に呼び出される。これは、開発者が、リソースをクリーンアップしたり、解決結果をまとめるコードを作成することができる場所である。開発者は、それでも、偽を返すことにより解決を拒絶することができる。
【０４８６】
ｆａｉｌ節は、型に対する解決が成功しなかった場合に呼び出される。ｂｅｇｉｎおよびｓｕｃｃｅｓｓ節のように、ｆａｉｌ節は「偽」を返し、実際には型の失敗した解決を成功させる。
【０４８７】
一実施形態では、コマンドを除く、すべての解決可能型は、制約節をいくつでも持つことができる。これについては、Ｓｌｏｔｓおよび「ｗｉｔｈ  ｒｅｓｔｒｉｃｔｉｏｎ／Ｆｒａｍｅ  ｃｌａｕｓｅｓ」に関してさらに詳しく説明される。他の実施形態では、コマンド型を含むすべての解決可能型は、制約節をいくつでも持つことができる。それぞれの解決可能型（Ｃｏｍｍａｎｄｓ、Ｆｒａｍｅｓ、Ｅｎｔｉｔｉｅｓ、およびＲｅｓｔｒｉｃｔｉｏｎｓ）について、以下で詳述する。
【０４８８】
Ｃｏｍｍａｎｄｓは、クライアントアプリケーションによりサポートされている自然言語（ＮＬ）対応タスクである。クライアントアプリケーションを開発時に、作成者は、処理したい作用を記述するコマンドを作成する。Ｃｏｍｍａｎｄｓは、意味解析に対しアプリケーションへのタスクエントリポイントを供給する。ＳＰＬ解決は、コマンドから開始し、ツリーを再帰的に下る。Ｃｏｍｍａｎｄｓは、ユーザコマンドに対する応答として呼び出される。これは、ユーザがマウスをクリックすることに対する応答として行われるマウスクリックなどのＷｉｎｄｏｗｓ（登録商標）イベントの呼び出され方と類似している。表８９は、本発明の一実施形態によるコマンド宣言の構文を示している。
【０４８９】
表８９：コマンド宣言
【０４９０】
【表７７】
2005332380.tif 000085
【０４９１】
例えば、「Ｃｏｍｍａｎｄ  ＳｅｎｄＭａｉｌＣｏｍｍａｎｄ  ｕｓｅｓ  ＭｙＳｅｎｄＦｒａｍｅ」では、ＭｙＳｅｎｄＦｒａｍｅオブジェクトを使用するＳｅｎｄＭａｉｌＣｏｍｍａｎｄオブジェクトを定義する。コマンドは本質的にフレームオブジェクトを包み込む。１つのコマンドでフレームオブジェクトを１つだけ規定できる。
【０４９２】
コマンド内のｂｅｇｉｎ節は、アプリケーションがコマンドを処理するのに適切なコンテキストおよび／または状態にあるかどうかをチェックするために使用する場所である。これにより、アプリケーションに関する知識に基づきコマンドを非常に早い段階で拒絶することができる。
【０４９３】
ｓｕｃｃｅｓｓ節では、開発者は、コマンドを直接実行するか、またはコマンドを実行するのに必要なデータをパッケージすることができる。このパッケージされたデータは、ＵＲＬ、タスクのＸＭＬ記述、コマンドを実行できる関数へのデリゲートなどの形態をとることができる。作成者は、そのまま、ｓｕｃｃｅｓｓ節で追加推論を実行し、値「ｆａｌｓｅ」を返すことにより解釈を拒絶することができる。これは、作成者が発話全体について大域的に推論することを加納にするため有用である。つまり、作成者は、全体として解決が首尾一貫しているかどうかを調べるため完全に解決された意味論的ツリーを観察することができるということである。断片は独立に、または限られたコンテキストにおいて首尾一貫しているが、一緒にすると意味をなさない場合もある。
【０４９４】
「Ｕｎｋｎｏｗｎ」コマンドは、オーサリングされたコマンドにマッピングされない発話を処理する。一実施形態では、ＳＰＬはこのコマンドが存在していることを強制する。
【０４９５】
フレームは一般に動詞を参照する。フレームには、基本フレームと複合フレームの２種類がある。基本フレームは１つの動詞を参照する。例えば、フレームｆｉｎｄは、動詞「ｆｉｎｄ」を参照する。複合フレームは、一般的に同じ意味を持つ複数の動詞からなるグループである。複合フレームおよびその複数の動詞は、同義語リストと考えることができる。一般に、意味論的プラットフォームは、動詞毎に１つずつ、基本フレームのあらかじめ定められた集合を提供する。整合性を保つため、基本フレームの名前は小文字とし、対応する語彙単語と同じ名前を持つという規約を設ける。対照的に、複合フレームの名前は、大文字で始まる。意味論的プラットフォームは、共通の複合フレームの集合を備える。例えば、プラットフォームは、「ｆｉｎｄ」、「ｓｅａｒｃｈ」、「ｌｏｏｋ」、および「ｒｕｍｍａｇｅ」をまとめるＳｅａｒｃｈ複合フレームを備えることができる。
【０４９６】
表９０は、基本フレームを定義するための構文を例示している。
【０４９７】
表９０：基本フレーム
【０４９８】
【表７８】
2005332380.tif 000086
【０４９９】
例えば、ｆｉｎｄフレームの構文は表９１に示されている。
【０５００】
表９１：Ｆｉｎｄフレーム
【０５０１】
【表７９】
2005332380.tif 000087
【０５０２】
この構文では、語彙単語「ｆｉｎｄ」で表され、ＤｅｆａｕｌｔＶｅｒｂＣｌａｓｓ内で動作する基本フレームであるｆｉｎｄを定義する。「ｆｉｎｄ」という語は、フレームｆｉｎｄを表す表記として参照される。意味論的プラットフォームでは、すべての動詞をカバーする動詞クラスの振る舞いの集合を定義する。動詞の大半は、ＤｅｆａｕｌｔＶｅｒｂＣｌａｓｓの一部である挙動を持つ。
【０５０３】
語彙単語は、インラインで現れなくてもよい。実際、複数の言語をサポートするために、複数の単語はインラインで出現しないことが推奨される。これらは、自オブジェクト内で定義されなければならない。表９２は、定義済み表記オブジェクトの構文を例示している。
【０５０４】
表９２：表記オブジェクト
【０５０５】
【表８０】
2005332380.tif 000088
【０５０６】
フレーム定義とともにインラインではなく、この方法で表記語を別にリストすることにより、言語依存要素は、言語独立要素からきちんと分けられる。
【０５０７】
意味論的プラットフォームにより提供されるすべての基本フレームは、この方法でＳＰＬコードにより定義される、開発者は、さらに、この方法で自分の動詞を定義することもできる。例えば、一実施形態では、開発者は次のようにして、ｆｏｐ基本クラスを定義することができる。
【０５０８】
frame fop denoted by "fop" behaves as DefaultVerbClass;
それとは別に、好ましい一実施形態では、開発者は次のようにして、ｆｏｐ基本クラスを定義することができる。
【０５０９】
frame fop denoted by "fop;
動詞の大半（９５％程度）は語彙単語自体としての言語的実現を持つことになると思われる。ほとんどの場合、他の言語に比較的に直訳される。言語間でこのようにして振る舞わない動詞については、表記クラスに、それらの動詞の言語的実現を指定するメカニズムを用意する。
【０５１０】
上述のように、複合フレームは動詞のグループである。それらは本質的に同義語リストである。複合フレームを作成する際に、複数のグループ内で使用されるフレームの表記のみ、複合フレームにより「継承」される。
【０５１１】
ＳＰＬを使用すると、開発者は基本フレームおよび複合フレームから自グループを作成することができる。例は、表９４に示されている。
【０５１２】
表９４：複合フレーム
【０５１３】
【表８１】
2005332380.tif 000089
【０５１４】
本質的に、この宣言は、ｇｒｏｕｐｓ節で規定されているフレームのすべての表記の論理和集合を確定し、重複を取り除き、その後、ｅｘｃｅｐｔ節で規定されているフレームの表記を取り除く。ｅｘｃｅｐｔ節は、オプションである。例えば、表９５は、定義内にｅｘｃｅｐｔ節を含む複合フレームを例示している。
【０５１５】
表９５：ｅｘｃｅｐｔ節を持つ複合フレーム
【０５１６】
【表８２】
2005332380.tif 000090
【０５１７】
これは、ｆｉｎｄフレームの表記を除いてＳｅａｒｃｈおよびｆｏｐの表記をグループ化するＭｙＳｅａｒｃｈＦｒａｍｅを定義する。
【０５１８】
他のフレームつまり基本フレームまたは複合フレームのいずれかから継承する派生フレームも作成できる。表９６は、派生フレームの構文を例示している。
【０５１９】
表９６：派生フレーム
【０５２０】
【表８３】
2005332380.tif 000091
【０５２１】
継承の問題については、以下のセクションＥ.３で詳述する。
【０５２２】
エンティティは、アプリケーションにおいて、名前で、または記述により参照できるオブジェクトである。エンティティは、ファイルアイテムおよび電子メールアイテムのような、具体的な物でよいが、色、テクスチャなどの抽象的概念を表すこともできる。エンティティは、通常、語彙単語で表される。表９７は、Ｅｎｔｉｔｙを宣言する構文を示している。
【０５２３】
表９７：Ｅｎｔｉｔｙ宣言
【０５２４】
【表８４】
2005332380.tif 000092
【０５２５】
フレームのように、複数の言語をサポートするために、表記はインラインで規定しないことが推奨される。表９８は、そのような表記の一例を示している。
【０５２６】
表９８：表記
【０５２７】
【表８５】
2005332380.tif 000093
【０５２８】
作成者は、ｄｅｎｏｔｅｄ  ｂｙ節を使って、エンティティを表す自然言語単語のリストを規定することができる。ｄｅｎｏｔｅｄ  ｂｙ節は、開発者がエンティティを語彙単語に基づくようにする手段である。エンティティは、１つの単語または複数の単語のグループによって表される必要はない。エンティティは、その制約により記述することができる。単語の形態の処理は意味論的プラットフォームが受け持つので、開発者は、単語の様々な形態（「ｆｉｌｅ」および「ｆｉｌｅｓ」など）を規定する必要はない。さらに、表記は、エンティティが成功するように発話内で規定される必要もない。しかし、表記が発話内に含まれる場合、その表記は、エンティティのリスト内の表記の１つと一致していなければならない。
【０５２９】
いくつかの実施形態では、表記は宣言時にオプションであることが望ましい場合がある。さらに、いくつかの実装では、義務的表記（エンティティが成功するために発話内に含まれなければならない単語）を追加することが望ましい場合がある。「義務的」表記の存在は、ｓｕｃｃｅｓｓ節に含まれるコードを通じて強制されるようにできる。表９９は、ｓｕｃｃｅｓｓ節を通じて強制される義務的表記の一例を示している。
【０５３０】
表９９：ｓｕｃｃｅｓｓ節を通じて強制する義務的表記
【０５３１】
【表８６】
2005332380.tif 000094
【０５３２】
一般に、制約は、型付けされた意味論的関係である。プラットフォームは、あらかじめ定められた関係の基本集合を備えている。制約に関する事で最も重要なのは、１つの言語内の、および複数の言語にまたがる、構文の変種の正規化である。制約は、意味論的であり、統語的ではない。したがって、制約を使用することで、開発者は、言語の構文ではなく、意味についてコーディングを行うことができる。制約により、オーサリングの負担が大幅に軽減され、他の言語への対応が可能になる。
【０５３３】
特定の意味を有するシステム定義スロットにはいくつかの制約が付く。上のセクションＤのＬＯＭの説明では、コード例を示し、またスロットについても一部説明した。いくつかの共通の制約を以下の表１００に示す。
【０５３４】
表１００：共通の制約のリスト
【０５３５】
【表８７】
2005332380.tif 000095
【０５３６】
Ｄｅｆａｕｌｔ制約と呼ばれる特別な制約がある。Ｄｅｆａｕｌｔ制約は、解決可能型に未解決または未認識の制約がある場合にＳＰＬランタイムにより発火される。
【０５３７】
開発者は、事前に定義された制約の集合のうちの１つから継承するか、フレームベースの制約を作成するか、またはパターンを規定することにより、独自の制約を作成する。
【０５３８】
一般に、制約は、エンティティおよびフレームだけでなく、他の制約にも適用することができる。概して、ＳＰＬでは、特定の制約を適用することで意味論的な意味を持たせるかどうかについて強制しない。ＳＰＬは、いくつかの例外を認めることで、意味論的モデリングを簡略化したり、曖昧さを減らしたりする。いくつかの例外が以下の表１０１に示されている。
【０５３９】
表１０１：ＳＰＬ例外
１.Ｄｅｇｒｅｅ制約は、制約にのみ許される。
【０５４０】
２.ＤｏｅｒおよびＤｏｎｅＴｏ制約は、フレームにのみ許される。
【０５４１】
３.否定はエンティティには許されない。
制約は、以下の構文を使用して型に適用される。
【０５４２】
with restriction RestrictionName<slot1 := type, ..., slotn := type>;
括弧内の項は、スロットと呼ばれる。「ｗｉｔｈ  ｒｅｓｔｒｉｃｔｉｏｎ」文は、制約節と呼ばれる。ラベル「ｒｅｓｔｒｉｃｔｉｏｎ」は、いくつかの問題点を避けるために選択された。例えば、制約には、「ｐｒｏｐｅｒｔｉｅｓ」というラベルを付けられるが、プロパティは、必ずしも、記述子として機能するわけではない。例えば、「ｍａｉｌ  ｉｎ  Ｉｎｂｏｘ」を「mail with the property of being in the Inbox folder」と考えることもできる。しかし、この同じ関係は、基数と序数などの数量詞とは共存しない。「ｔｈｒｅｅ  ｆｉｌｅｓ」という語句と「ｆｉｌｅｓ  ｗｉｔｈ  ｔｈｅ  ｐｒｏｐｅｒｔｙ  ｏｆ  ｔｈｒｅｅ」とは同等ではない。さらに、単語「ｐｒｏｐｅｒｔｙ」は、すでに、従来のプログラミングパラダイムの中で使用されている（例えば、「ｐｒｏｐｅｒｔｉｅｓ  ｏｆ  ａ  ｌｉｓｔ  ｂｏｘ」）。一般的に、語「ｐｒｏｐｅｒｔｉｅｓ」をオーバーロードしないことが望ましく、また同じことは、単語「ａｔｔｒｉｂｕｔｅ」についてもいえる。
【０５４３】
代わりに、Ｅｎｔｉｔｙは、集合の概念を伝達することを意図している。ＳＰＬの「ｅｎｔｉｔｙ」宣言では、実際には、エンティティの集合を規定し、制約を適用することがその集合を制約することになっている。例えば、Ｍａｉｌにより表されるＭａｉｌＥｎｔｉｔｙを宣言する構文
entity MailEntity denoted by "mail"
は、すべてのメールアイテムの集合を表すオブジェクトの宣言である。表１０２は、エンティティに適用される制約の構文を例示している。
【０５４４】
表１０２：エンティティに適用される制約
【０５４５】
【表８８】
2005332380.tif 000096
【０５４６】
ここで、メールアイテムの集合は、ＭａｉｌＦｏｌｄｅｒロケーションに制約される。
【０５４７】
制約をフレームに適用することは、その作用を制約することとみなすべきである（Ｆｒａｍｅｓは、通常、動詞または作用をモデル化する）。表１０３は、制約付きのフレームを例示している。
【０５４８】
表１０３：フレームに対する制約
【０５４９】
【表８９】
2005332380.tif 000097
【０５５０】
ここで、Ｍｅａｎｓ制約は、ＭｙＯｐｅｎフレームに適用され、それによってｏｐｅｎ  ｆｉｌｅの作用をＮｏｔｅｐａｄの使用に制約する。
【０５５１】
同じことが制約に対する制約にも適用される。例えば、Ｃａｒｄｉｎａｌ制約はエンティティの基数を表す。「３  ｆｉｌｅｓ」という語句は、任意の３ファイルを意味する。しかし、基数は、「ｆｉｒｓｔ  ３  ｆｉｌｅｓ」のように、Ｏｒｄｉｎａｌにより制約することができる。表１０４は、制約に適用される制約を例示している。
【０５５２】
表１０４：制約に対する制約
【０５５３】
【表９０】
2005332380.tif 000098
【０５５４】
ここで、ｒｅｓｔｒｉｃｔｉｏｎ節は、序数を適用することにより基数を制約する。
【０５５５】
一般に、解決可能型は、コマンドを除き、任意の数の制約をそれらに適用可能である。それぞれの制約型は、シグネチャが一意である限り、何回も適用できる。表１０５は、一意的なシグネチャとともに複数の制約を持つＦｒａｍｅを示している。
【０５５６】
表１０５：複数の制約を持つフレーム
【０５５７】
【表９１】
2005332380.tif 000099
【０５５８】
制約節が発火する順序は、意味解析に依存する。一般に、順序は、言語証拠、統計的順位付け、および領域依存学習の組合せに基づく。いくつかの実装では、決定論的順序を強制するメカニズムを加えることができる。ＳＰＬランタイムは、ＳＰＬの言語意味論および意味解析により、制約節を発火する。
【０５５９】
上述のように、スロットは、角括弧（＜＞）内に現れる項である。スロット構文は、使用時にスロットをサブタイプ化するために使用される。ＳＰＬは、制約の複数の定義済みスロットを持つ。例えば、意味論システムでは、Ｇｏａｌ制約を以下のように定義する。
【０５６０】
Goal<goal := Entity>
ｇｏａｌスロットは、基本Ｅｎｔｉｔｙ型を持ち、領域独立指定と呼ぶことができる。開発者がこの領域独立Ｇｏａｌを解決可能型に適用する場合、開発者は、適用時にｇｏａｌスロットをサブタイプ化できる。表１０６は、サブタイプ化されたｇｏａｌスロットを含むＦｒａｍｅの構文を示している。
【０５６１】
表１０６：サブタイプ化されたｇｏａｌスロットを持つフレーム
【０５６２】
【表９２】
2005332380.tif 000100
【０５６３】
ここで、開発者は、ｇｏａｌスロットをＣｏｎｔａｃｔＩｔｅｍ（ＣｏｎｔａｃｔＩｔｅｍはエンティティ型でなければならない）にサブタイプ化している。
【０５６４】
制約節のコード内では、制約はオブジェクトとしてアクセス可能である。表１０７は、制約をオブジェクトとしてアクセスするための構文を示している。
【０５６５】
表１０７：制約のオブジェクトとしてのアクセス
【０５６６】
【表９３】
2005332380.tif 000101
【０５６７】
一般に、解決可能型は、Ｃ＋＋テンプレートとのアナロジーを使用して概念化することができる。Ｇｏａｌ制約は、例えば、汎用型のｇｏａｌデータメンバを持つテンプレートＧｏａｌクラスと考えることができる。すると、上記Ｇｏａｌ制約節の擬似Ｃ＋＋コードは以下のようになる。
【０５６８】
bool OnGoalClause (GoalTemplateClass<ContactItem> Goal);
ＳＰＬコンパイラは、ｇｏａｌスロットの適切なサブタイプ化を強制する。
【０５６９】
解決可能型のコンシューマは、型の制約節をサブタイプ化したい場合がある。例えば、上記のｓｅｎｄフレームのコンシューマは、以下のようにスロット構文を使用してＧｏａｌ制約節のｇｏａｌスロットをサブタイプ化したい場合がある。
【０５７０】
command MySendCommand uses send<Goal.goal := MyCont act Item>;
ｓｅｎｄフレームに適用されるＧｏａｌ制約節が多数ありうるため、開発者側で参照される節を規定できなければならない。
【０５７１】
他の種類の制約として、ＡｓＰｒｏｐｅｒｔｙ制約がある。ａｓｐｒｏｐｅｒｔｙ属性を使用することにより、解決可能型のコンシューマは、スロット構文を使用して制約節のスロットをサブタイプ化することができる。この属性は、表１０８に示されているように制約節で規定される。
【０５７２】
表１０８：ＡｓＰｒｏｐｅｒｔｙ属性
【０５７３】
【表９４】
2005332380.tif 000102
【０５７４】
ここで、ｓｅｎｄフレームの開発者は、ｓｅｎｄフレームのＧｏａｌ制約節は、コンシューマにより以下のようにスロット構文を使用してサブタイプ化することができることを宣言している。
【０５７５】
command MySendCommand uses send<Goal.goal := MyContactItem>;
この宣言で、ＭｙＳｅｎｄＣｏｍｍａｎｄはｓｅｎｄフレームを使用し、ｓｅｎｄフレームのＧｏａｌ制約節をサブタイプ化し、ＭｙＣｏｎｔａｃｔＩｔｅｍとする。
【０５７６】
一般に、ａｓｐｒｏｐｅｒｔｙ属性を使用すると、ｓｅｎｄフレーム内のコードで、プロパティ構文を使用することによりこのＧｏａｌオブジェクトにアクセスすることもできる。すべての解決可能型は、コードで制約の現在解決されているコレクションにアクセスできるＲｅｓｔｒｉｃｔｉｏｎＣｏｌｌｅｃｔｉｏｎプロパティを持つ。ａｓｐｒｏｐｅｒｔｙ属性を使用すると、表１０９に示されているようにプロパティ構文を使用して標示されている制約にアクセスすることができる。例えば、次のようである。
【０５７７】
表１０９：プロパティ構文を使用して標示されている制約にアクセス
【０５７８】
【表９５】
2005332380.tif 000103
【０５７９】
さらに、それぞれの型の１つの制約のみが、以下の表１１０に示されているように制約スロットの型に関係なく、ａｓｐｒｏｐｅｒｔｙ属性を標示できる。
【０５８０】
表１１０：ＡｓＰｒｏｐｅｒｔｙ制約制限
【０５８１】
【表９６】
2005332380.tif 000104
【０５８２】
しかし、この構文は、以下のように開発者側で変更し、１つの型の複数の制約がａｓｐｒｏｐｅｒｔｙ属性を標示するようにできる。
【０５８３】
restriction Goal2 : Goal<goal := UserItem>;
これにより、問題がなくなり、フレームは以下の表１１２に示されているように解決できる。
【０５８４】
表１１２：制約構文
【０５８５】
【表９７】
2005332380.tif 000105
【０５８６】
制約節内のスロットの順序付けに関して、いくつかの制約がシステムスロットとともに定義されることを理解しておくことが重要である。例えば、Ｇｏａｌ制約は、ｇｏａｌスロットとともに定義される。使用時にＧｏａｌ制約をサブタイプ化する場合（つまり、制約節で）、システムスロットは、表１１３に示されているように最初に規定されなければならない。
【０５８７】
表１１３：スロットの順序付け
【０５８８】
【表９８】
2005332380.tif 000106
【０５８９】
ａｓｐｒｏｐｅｒｔｙを標示されている制約節を持つエンティティは、使用時にサブタイプ化された制約節を持つことができる。例えば、ＣｏｎｔａｃｔＩｔｅｍでは、表１１４に示されているようにＬｏｃａｔｉｏｎ制約節はａｓｐｒｏｐｅｒｔｙを標示されているとする。
【０５９０】
表１１４：ＡｓＰｒｏｐｅｒｔｙを標示されている場所制約
【０５９１】
【表９９】
2005332380.tif 000107
【０５９２】
制約節は、さらに、ｏｂｌｉｇａｔｏｒｙを標示することもでき、これは、節が実行されて成功しなければならないか、さもなければ、その型の解決が失敗することを意味する。節が成功するためには、以下の基準が満たされなければならない。
【０５９３】
１.制約は、発話内になければならない。
【０５９４】
２.節の宣言制約条件（スロットの型）が満たされていなければならない。
【０５９５】
３.節内の手続き制約条件（コード）は真に評価されなければならない。
【０５９６】
例は、以下の表１１５に示されている。
【０５９７】
表１１５：Ｏｂｌｉｇａｔｏｒｙ制約
【０５９８】
【表１００】
2005332380.tif 000108
【０５９９】
表１１５内のフレームの構文では、ｓｅｎｄフレームの解決が成功するために、発話内の「ｓｅｎｄ」のゴールとしてＣｏｎｔａｃｔＩｔｅｍがなければならない。したがって、「ｓｅｎｄ  ｍａｉｌ」は、解決しないが、「ｓｅｎｄ  ｔｏ  Ｂｏｂ」は、「Ｂｏｂ」が解決されたＣｏｎｔａｃｔＩｔｅｍであれば、解決する。
【０６００】
Ｅ３.ＳＰＬ継承
継承は、エンティティ、フレーム、および制約上で許される。現在、コマンドは継承をサポートしていない。一般的に、コマンドでの継承サポートの必要はなさそうである（この時点では）。コマンドは、継承を必要としないタスクエントリポイントである。
【０６０１】
すべて「継承可能」コードは、コマンドが使用するフレーム内にある。すでに説明したように、ｏｎ  ｒｅｓｏｌｖｅ節内の解決意味論を除き、解決可能型は、通常のオブジェクトにすぎない。ｏｎ  ｒｅｓｏｌｖｅ節の外部では、ＳＰＬは、当業ではよく知られている、Ｃ＃継承意味論を採用する。この説明の目的のために、本開示では、従来の（Ｃ＃）継承意味論に従わないｏｎ  ｒｅｓｏｌｖｅ節内の継承意味論に注目している。しかし、いくつかの実装では、継承を使用する実際のアプリケーションの特定の機能を使用可能にするために従来のＣ＃継承意味論から外れることが望ましい場合がある。簡単のため、説明では、そのようなすべての可能性には立ち入らず、規則によれば間違っているだろうが説明が簡単になるよう試みる。
【０６０２】
まず、ｏｎ  ｒｅｓｏｌｖｅ節の関数、制約節、および変数内のスコーピングを理解することが重要である。表１１６は、スコープの説明を簡単にするため、Ｍａｉｌ  Ｅｎｔｉｔｙの構文を示している。
【０６０３】
表１１６：メールエンティティ
【０６０４】
【表１０１】
2005332380.tif 000109
【０６０５】
ｏｎ  ｒｅｓｏｌｖｅスコープ内で定義されている変数は、ｏｎ  ｒｅｓｏｌｖｅスコープ内の制約節からアクセス可能であるが、ｏｎ  ｒｅｓｏｌｖｅ節の外部からはアクセス可能でない。上の例では、整数ｙは、Ｇｏａｌ制約節と関数ｆｏｏ（）内でアクセス可能であるが、関数ｂａｒ（）内ではアクセス可能でない。
【０６０６】
ｏｎ  ｒｅｓｏｌｖｅ節で宣言された関数は、その節に対してはプライベートである、つまり、そのような関数は、ｏｎ  ｒｅｓｏｌｖｅ節の外部からはアクセスできないということである。したがって、ｆｏｏ（）はｂａｒ（）内からアクセスできない。制約節も、ｏｎ  ｒｅｓｏｌｖｅ節に対してプライベートであり、したがって、その外部からはアクセスできない。
【０６０７】
型のスコープ内で宣言されている変数は、ｏｕｔｅｒキーワードを使用することによりｏｎ  ｒｅｓｏｌｖｅ節内の節および関数からアクセス可能である。例えば、整数ｘは、Ｇｏａｌ制約および関数ｆｏｏ（）内で、ｏｕｔｅｒ．ｘとしてアクセス可能である。型のスコープ内で宣言されている関数は、ｏｎ  ｒｅｓｏｌｖｅ節からアクセス可能である。したがって、関数ｂａｒ（）は、Ｇｏａｌ制約および関数ｆｏｏ（）内で、ｏｕｔｅｒ．ｂａｒ（）としてアクセス可能である。
【０６０８】
ｏｎ  ｒｅｓｏｌｖｅ節は、コンストラクタに関係するすべてがそのコンストラクタにプライベートとなるように、拡張コンストラクタとして概念化することができる。これは、派生クラスは、基本クラス内の制約節をどれも呼び出すことができないことを意味する。
【０６０９】
エンティティは、他の１つのエンティティから継承することができる。エンティティの複数の継承は許されない。基本エンティティの表記は、派生エンティティの表記にマージされる。表１１７に示されているように、マージされた表記リスト内に階層はない（表記はフラット化されている）。
【０６１０】
表１１７：マージされた表記リスト
【０６１１】
【表１０２】
2005332380.tif 000110
【０６１２】
ＭｙＭａｉｌＥｎｔｉｔｙの表記リストは、「ｍａｉｌ」、「ｅｍａｉｌ」、および「ｅｌｅｃｔｒｏｎｉｃ  ｍａｉｌ」からなる。
【０６１３】
定義時に、派生エンティティは、さらに、ａｓｐｒｏｐｅｒｔｙを標示されている基本エンティティの制約節をサブタイプ化することもできる。例えば、ＭａｉｌＥｎｔｉｔｙがａｓｐｒｏｐｅｒｔｙを標示されたＬｏｃａｔｉｏｎ制約節を持っていた場合、ＭｙＭａｉｌＥｎｔｉｔｙ定義は以下のようになりうる。
【０６１４】
【表１０３】
2005332380.tif 000111
【０６１５】
このコードブロックは、ＭｙＭａｉｌＥｎｔｉｔｙがＭａｉｌＥｎｔｉｔｙのＬｏｃａｔｉｏｎに対する認識を継承するが、実際の場所に対する特性をさらに加えることを指示する。
【０６１６】
エンティティのように、フレームは、他の１つのフレームからのみ継承することができる。複数の継承は許されない。定義により、派生フレームで、フレームのグループを規定することはできない。複合フレームおよびフレーム継承は分離される。エンティティの場合と同じようにしてＦｒａｍｅｓの継承を処理することが可能である。例えば、複合フレームでは、表記リストはグループにまとめられる。いくつかの場合において、すべてのフレームが、フレームのグループ化の際に同じビヘイビアクラスに属すという要求条件を強制することが望ましいことがある。グループ内のフレームが同じＬＳＳクラスに属している必要がない場合、複数のフレームおよびエンティティを同じ方法で処理することも可能である。
【０６１７】
フレームおよびエンティティのように、派生制約は、他の１つの制約からのみ継承することができる。基本制約の制約節のサブタイプ化も、派生制約の定義時に生じる可能性がある。
【０６１８】
特定の制約型の制約節は、基本型に進む前に派生型で試みられる。これは、さらに、以下の表１１８に示されているようにＤｅｆａｕｌｔ制約に適用される。
【０６１９】
表１１８：Ｄｅｆａｕｌｔ制約
【０６２０】
【表１０４】
2005332380.tif 000112
【０６２１】
ＭｙＭａｉｌＥｎｔｉｔｙ上のＬｏｃａｔｉｏｎ制約を解決する場合、制約節を発火する順序は以下のとおりである。
【０６２２】
１．MyMailEntity.Location
２．MailEntity.Location
３．MyMailEntity.Default
４．MailEntity.Default
今のところ、パブリック／プライベート制約節の概念も、制約節のオーバーライドの概念もない。部分的には、これは、クラスを解決するために制約節が使用され、それらの節がｏｎ  ｒｅｓｏｌｖｅ節に対しプライベートであるとした場合に、制約節をオーバーライドすることはほとんど意味がないからである。しかし、いくつかの実装では制約節をオーバーライドできるようにすることが望ましい場合がある。
【０６２３】
実装によっては、派生クラス（解決時に）が基本クラス内のメンバ（メソッドおよび変数）にアクセスできるようにする必要がある。基本クラスはまだ解決されていないため、これは問題になることがある。基本クラスが解決されるまで派生クラスが基本クラスのメンバにアクセスすることを許されない場合、派生クラスは、解決時に基本クラスに多態に設定できないようになっていなければならない。いずれの場合も、派生クラスは、基本クラスが解決される前に基本クラス上で制約節を直接呼び出すことを許されないことがある。
【０６２４】
継承は、既存のエンティティに対する認識を高めるために使用することができる。再び上述の表１１８のＭａｉｌＥｎｔｉｔｙコードを参照すると、ＭａｉｌＥｎｔｉｔｙはＬｏｃａｔｉｏｎ制約しか認識しないことに留意すべきであることがわかる。ＭｙＭａｉｌＥｎｔｉｔｙ内のオーサリングされたＬｏｃａｔｉｏｎロジックを利用し、Ｔｏｐｉｃの認識を加えるエンティティを作成することが可能である。さらに、基本クラスと同じ型の制約節は、以下の表１１９に示されているように追加することができる。
【０６２５】
表１１９：ＭｙＭａｉｌＥｎｔｉｔｙ
【０６２６】
【表１０５】
2005332380.tif 000113
【０６２７】
制約節が呼び出され、節内のオーサリングされたコードにより拒絶された場合、インタプリタは、現在の型または多態的に同等の上位型のどれかの制約節を呼び出す。多態的に同等であるとみなすために、制約型およびそのスロットの型は、両方とも、以下の表１２０に示されているように多態的でなければならない。
【０６２８】
表１２０：多態性
【０６２９】
【表１０６】
2005332380.tif 000114
【０６３０】
これらは、正確に同等ではないが、表１２１に示されているように、スロットでのサブタイプ化の代わりに継承を使用することが可能である。
【０６３１】
表１２１：継承
【０６３２】
【表１０７】
2005332380.tif 000115
【０６３３】
ＭａｉｌＥｎｔｉｔｙ３と突き合わせて「ｍａｉｌ  ｉｎ  Ｉｎｂｏｘ」を解決する場合、ＭａｉｌＥｎｔｉｔｙ３．Ｌｏｃａｔｉｏｎ節はＭａｉｌＥｎｔｉｔｙ．Ｌｏｃａｔｉｏｎ節に優先する。この場合、ＭａｉｌＥｎｔｉｔｙ３に対しては、２つのＬｏｃａｔｉｏｎ制約節がある。しかし、ＭａｉｌＥｎｔｉｔｙ２に対しては、Ｌｏｃａｔｉｏｎ節は１つしかない。スロットでのサブタイプ化は、ＭａｉｌＥｎｔｉｔｙ２に対するＬｏｃａｔｉｏｎはＭａｉｌＥｎｔｉｔｙのＬｏｃａｔｉｏｎ制約節により、ただしＭｙＭａｉｌＦｏｌｄｅｒ型を使用して、評価されなければならないことを示すと解釈することができる。
【０６３４】
ｏｂｌｉｇａｔｏｒｙ属性を持つ制約節を宣言する場合には、注意しなければならないことに留意されたい。義務的節は、型の解決が成功する順序で発火し、成功しなければならない。基本型で節をｏｂｌｉｇａｔｏｒｙと宣言した場合、派生クラスは、基本クラスに入るべき決定を処理しないようにしなければならない。派生型は、その基本型の制約節を呼び出すことはできない。その代わりに、派生型は、基本型のｏｂｌｉｇａｔｏｒｙ制約節を呼び出すのに通常の解決意味論に依存する。
【０６３５】
Ｅ４.解決意味論
ＳＰＬの解決意味論は、ＳＰＬランタイムにより実装される。ランタイムは、ＳＰＬの言語意味論により、発話の領域依存モデルを構築する。このランタイムは、言語およびＳＰＬ言語の規則に従って、オーサリングされたＳＰＬ型と突き合わせて自然言語コマンドを解決する。
【０６３６】
一実施形態では、型の解決は、トップダウン方式で実行される。図５は、本発明の一実施形態による型解決のトップダウン方式の簡略化された流れ図である。第１に、ランタイムは、発話に対して解決できる可能なコマンドを見つける（ステップ５００）。複数の可能なコマンドがある場合、解決に対し１つのコマンドが選択される（ステップ５０２）。コマンドが見つからない場合、Ｕｎｋｎｏｗｎコマンドが呼び出される（ステップ５０４）。１つまたは複数のコマンドが見つかった場合、ランタイムは、見つかったコマンドを解決しようと試みる（ステップ５０６）。コマンド解決が失敗した場合、ランタイムはリスト内の次のコマンドに進み、可能なコマンドがなくなるまでステップ５０２〜５１０を繰り返す。コマンド解決が成功した場合、コマンドは解釈リストに追加される（ステップ５１０）。最後に、発話に含まれる可能なコマンドがなくなるまで、または要求された解釈が規定された数に達するまで、ランタイムはステップ（ステップ５０２から５１０）を繰り返す（ステップ５１２）。
【０６３７】
当業者であれば、解決プロセスには多数の変更形態が可能であることを理解するであろう。例えば、いくつかの場合において、解決の失敗は一般的な失敗となることがあり、これにより、プログラムは解決を終了する。他の場合には、失敗により、型のｆａｉｌｕｒｅ節が呼び出されることがあるが、この結果、解決が失敗する場合もあれば失敗しない場合もある。さらに、ｆａｉｌｕｒｅ節、ｓｕｃｃｅｓｓ節、およびｂｅｇｉｎ節内では、プログラム開発者は、アプリケーション固有のコードを自由に挿入することができ、これにより、フレームワークを無数の方法で適合させることができる。例えば、開発者は、ｆａｉｌｕｒｅ節に、「ｓｕｃｃｅｓｓ」フラグを返すコードを挿入し、解決が失敗しても失敗を引き起こさないようにすることも可能である。失敗した解決は無視されるか、または他のプログラムコードによりプロセスがクライアントアプリケーションにコールバックし、特定の解決などを明確化することもある。図は一例を示すことを目的としているが、可能な実装を網羅することを意図してはいないことに留意されたい。
【０６３８】
図６に示されているように、コマンド解決の可能な一実施形態は以下のように進行する。コマンドのｂｅｇｉｎ節が呼び出される（ステップ６００）。ｂｅｇｉｎ節が失敗した場合、ランタイムがコマンドを終了させる（ステップ６０１）。ｂｅｇｉｎ節が成功した場合、ランタイムは、フレームを解決しようと試みる（ステップ６０４）。フレーム解決が失敗した場合、フレームのｆａｉｌｕｒｅ節が呼び出され、実装に応じて、ランタイムがコマンドを終了させるか、または他のオペレーションを実行することができる（ステップ６０２）。そうでない場合、ランタイムはｓｕｃｃｅｓｓ節を呼び出す（ステップ６０６）。
【０６３９】
すでに説明しているように、本発明の意味論的プログラミング言語では、プログラム開発者は様々な要素のオペレーションに対する制御を行うことができる。したがって、本発明の解決意味論は、特定のアプリケーションにとって望ましいオペレーションを実装するため無数の方法により修正することができる。そのため、解決が失敗した場合、場合によっては、失敗を無視して、進行することが望ましい。他の場合には、解決が成功するように（クライアントアプリケーションに対するコールバックを行うことなどにより）解決を数ステップで明確化するのが望ましいこともある。さらに他の場合には、解決が失敗した場合に解決を単に終了することが望ましいこともある。
【０６４０】
図７に示されているように、一実施形態では、フレーム解決が以下のように進行する。フレームのｂｅｇｉｎ節が呼び出される（ステップ７００）。フレーム解決が失敗した場合、ｆａｉｌｕｒｅ節が呼び出され（ブロック７０２）、ランタイムが、オプションにより、他のコマンドを解決する（ブロック７０４）。
【０６４１】
フレーム解決が成功した場合、ランタイムは、Ｒｅｓｔｒｉｃｔｉｏｎ節を呼び出す（ブロック７０６）（図４のブロック４０８および順序に対応する）。Ｒｅｓｔｒｉｃｔｉｏｎ節が解決に失敗した場合、ランタイムは、解決に対する派生型を考慮する（ブロック７０８）。例えば、派生型ＭａｉｌおよびＮｏｔｅｓのエンティティタイプＩｔｅｍが与えられたとすると、Ｉｔｅｍを取る他の型ＳｅｎｄＩｔｅｍ上の節は、ＭａｉｌまたはＮｏｔｅｓのインスタンスにより解決することが可能である。
【０６４２】
ランタイムが派生型の呼び出しに成功しなかった場合、実装に応じて、フレームのｆａｉｌｕｒｅ節が呼び出され（ブロック７０９）、その後コマンドのｆａｉｌｕｒｅ節が呼び出される（ブロック７０２）ようにできる。
【０６４３】
その代わりに、Ｒｅｓｔｒｉｃｔｉｏｎ節を単に無視することもできる。Ｒｅｓｔｒｉｃｔｉｏｎ節が無視された場合、ランタイムは、フレームおよびコマンドのｓｕｃｃｅｓｓ節を呼び出す（ブック７１２）。その後、ランタイムは、コマンドオブジェクトを「ａｃｔｕａｌ  ｉｎｔｅｒｐｒｅｔａｔｉｏｎｓ」リストに追加し（ブロック７１４）、他のコマンドを解決しようと試みる（ブロック７０４）。
【０６４４】
ランタイムがＲｅｓｔｒｉｃｔｉｏｎ節の呼び出しに成功するか（ブロック７０６）、または解決に対するＤｅｒｉｖｅｄ型の検出に成功した（ブロック７０８）場合、ランタイムは、Ｒｅｓｔｒｉｃｔｉｏｎのｓｕｃｃｅｓｓ節を呼び出す（ブロック７１０）。その後、ランタイムは、フレームおよびコマンドのｓｕｃｃｅｓｓ節を呼び出し（ブロック７１２）、コマンドオブジェクトを「ａｃｔｕａｌ  ｉｎｔｅｒｐｒｅｔａｔｉｏｎｓ」リストに追加する（ブロック７１４）。この後、ランタイムは、可能なすべてのコマンドに対する解決が試みられるまでコマンドを次々に解決しようと試みる（ブロック７０４）。
【０６４５】
すでに述べたように、プロセスの流れは、説明目的のみを意図しており、決して可能な多数の実装を網羅することはない。実際には、解決プロセスは、大部分でないとしても、少なくとも一部は、特定の実装により決定される。したがって、示されているように、制約解決の失敗は、一般的な解決の失敗を引き起こすか（ブロック７０９および７０２により示されているように）、または制約解決は、単に、無視され、コマンド解決が進行する。他の実施形態では、失敗した制約（例えば、Ｒｅｓｔｒｉｃｔｉｏｎが義務的である場合）により、ランタイムがクライアントアプリケーションにコールバックするか、またはフロー制御情報を解析エンジンに送信し、コマンドの明確化を行おうとする場合もありうる。このような決定は、たいてい実装固有であり、したがって、意味論的プログラミング言語のプログラミング構文を使用することで、自然言語プログラミングを行いやすくし、特定の実装に合わせて自然言語処理を最適化することができる。
【０６４６】
図８に示されているように、制約節解決の可能な一実施形態は以下のように進行する。提案された制約毎に、制約に対し制約スロットがある場合、ランタイムはＲｅｓｏｌｖｅＳｌｏｔ関数を呼び出すことによりそれぞれのスロットを解決する（ブロック８００）。ＲｅｓｏｌｖｅＳｌｏｔ関数が失敗した場合、ランタイムは次の提案された制約（ブロック８０２）を選択し、ＲｅｓｏｌｖｅＳｌｏｔ関数（ブロック８００）を再び呼び出すことによりスロットを解決しようと試みる。ＲｅｓｏｌｖｅＳｌｏｔ関数が成功した場合（初回に、または次の提案された制約のうちの１つで）、ランタイムは制約節を呼び出す（ブロック８０４）。
【０６４７】
制約節が失敗した場合、ランタイムは、現在のクラス内で多態的に同等な節を探す（ブロック８０６）。多態的に同等な節が現在のクラス内に見つからない場合、ランタイムは継承連鎖内の１つを探索する（ブロック８０８）。多態的に同等な節が見つかった場合、ランタイムは同等な節を呼び出す（ブロック８１０）。ランタイムは、同等な節が見つからなくなるまで、または同等な節が成功するまで、繰り返す（ブロック８０８）。
【０６４８】
必要ならば、ランタイムは、Ｄｅｆａｕｌｔ制約を呼び出す（ブロック８１２）。すべての制約節の解決が成功した場合、ランタイムは、ｓｕｃｃｅｓｓ制約を呼び出す（ブロック８１４）。成功しなかった場合、ランタイムは、Ｒｅｓｔｒｉｃｔｉｏｎを無視し（ブロック８１６）、フレームのｓｕｃｃｅｓｓ節を呼び出す（ブロック８１８）。
【０６４９】
他の実施形態では、ｄｅｆａｕｌｔ制約節が失敗した場合、制約は単に無視されるだけである。上述のように、これがＮａｍｅｄまたはＮｅｇａｔｉｏｎ制約でない限り、制約はそれでも成功する。
【０６５０】
制約節は同じ解決可能型について複数回発火できることに留意されたい。例えば、コマンド「ｓｈｏｗ  ｆｉｌｅｓ  ｉｎ  ｃ：  ｉｎ  ｔｅｍｐ  ｆｏｌｄｅｒ」は、「ｆｉｌｅ」エンティティに対し２つのＬｏｃａｔｉｏｎ制約を持つ（「ｉｎ  ｃ：」と「ｉｎ  ｔｅｍｐ  ｆｏｌｄｅｒ」）。今のところ、制約節の解決の唯一強制される順序として、フレームに対するＤｏｅｒおよびＤｏｎｅＴｏ制約が最初に解決され（その順序で）、Ｄｅｆａｕｌｔ制約が最後に解決される。しかし、ＮｅｇａｔｉｏｎおよびＮａｍｅｄなど、他の型に順序付けを強制することが望ましい場合もある。
【０６５１】
図９に示されているように、一実施形態では、ＮａｍｅｄＥｎｔｉｔｙ解決が以下のように進行する。ランタイムは、Ｅｎｔｉｔｙのｂｅｇｉｎ節を呼び出す（ブロック９００）。これが失敗すると、ランタイムはＥｎｔｉｔｙ解決を終了する（ブロック９０２）。Ｅｎｔｉｔｙのｂｅｇｉｎ  ｒｅｓｏｌｕｔｉｏｎ節が成功した場合、ＮａｍｅｄＥｎｔｉｔｙが見つかり、Ｅｎｔｉｔｙに対応しているならば、ランタイムは、指定されたＲｅｓｔｒｉｃｔｉｏｎを呼び出そうと試みる（ブロック９０４）。ブロック９０４は複数の解決ステップを包含することに留意することが重要であるが、それらは簡単のためここでは省略されている。
【０６５２】
指定された制約の呼び出しが失敗した場合、Ｅｎｔｉｔｙの障害節が呼び出され、ランタイムが終了する（ブロック９０６）。呼び出しが成功した場合、ランタイムは、Ｅｎｔｉｔｙのｓｕｃｃｅｓｓ節を呼び出す（ブロック９０８）。
【０６５３】
本発明のプログラミング言語を使用して解決ステップを変更する方法は無数にあることは理解されるであろう。例えば、ｓｕｃｃｅｓｓ  ｒｅｓｏｌｕｔｉｏｎ節を修正して、ある状況の下では「ｆａｌｓｅ」または「ｆａｉｌｕｒｅ」を返すようにすることができる。同様に、ｆａｉｌｕｒｅ  ｒｅｓｏｌｕｔｉｏｎ節は、特定の実装に応じて、「ｔｒｕｅ」または「ｓｕｃｃｅｓｓ」を返すようにプログラムすることができる。したがって、本明細書に提示されている例は、制限する意図はないが、むしろ、解決意味論の可能な実装の１つを例示するために用意されている。多数の変更形態が予想され、プログラマはその解決を、特定の自然言語アプリケーションのニーズに合わせて適用することが期待される。
【０６５４】
Ｄｅｆａｕｌｔ制約は、オーサリングされたコードにより処理されない制約および／またはランタイムにより認識されない制約を解決するために使用される。Ｄｅｆａｕｌｔ制約は、解決可能型毎に１回呼び出され、常に最後に呼び出される。解決可能型毎に高々１つのＤｅｆａｕｌｔ制約のみがありうる。
【０６５５】
Ｄｅｆａｕｌｔによるオブジェクトモデルは、実装により異なることがある。一実施形態では、Ｄｅｆａｕｌｔオブジェクトモデルは、提案された制約を持つテキストのトークンのラティス（要素、アイテム、またはスパン）を備える。トークンは、ラティス内で連続している必要はない。例えば、発話内に、ｔｏｋｅｎ１  ｔｏｋｅｎ２、およびｔｏｋｅｎ３があると仮定する。Ｄｅｆａｕｌｔの下で、ランタイムは表１２２に示されているラティスを出力することができる。
【０６５６】
表１２２：Ｄｅｆａｕｌｔの下で出力されるラティス
【０６５７】
【表１０８】
2005332380.tif 000116
【０６５８】
未加工テキストは常に使用可能である。ＳＰＬを使用すると、作成者は、テキスト内のトークンが成功した解決の中で予想されているかされないかに関する情報を得ることができる。
【０６５９】
統計的意味論的モデリングおよび学習は、ＳＰＬで一定の役割を果たしうる。制約節が呼び出される順序は、言語証拠、統計的順位付け（例えば、ＳＧＭ）、および自動学習に基づく何らかの統計量に依存することがある。図１０に示されているように、システム１０００は、ランタイム１００２およびデータベース１００４を含む。一般に、ランタイム１００２は、発話および解決の結果のリポジトリである、データベース１００４を管理することができる。このリポジトリ内のデータについて、解決のあるしきい値に到達した後、（例えば）解析ツール１００６によりマイニングまたは解析（オフラインで）を実行できる。データベース１００４内の情報は解析ツール１００６により解析することができ、その後、結果をランタイム１００２にフィードバックすることにより、解決するコマンドの選択および順序、および制約節を呼び出す順序を改善することができる。その結果、多くの発話が解決されるときに、オーサリングされたコードに対し変更を加えることなく、解決を行い改善と高速化を果たすことができる。広い意味で、システム１０００は、コーディングし直しをしなくても、パフォーマンスを改善することができるインテリジェント型システムである。
【０６６０】
一実施形態では、上級作成者は、リポジトリと突き合わせて管理しプログラムすることができる。他の実施形態では、上級作成者は、ただの真／偽の値ではなく節からの信頼度レベルを表す確率を返すことができる。これだとプログラミングモデルが複雑になる可能性があるが、論理値の代わりに信頼度レベルを導くことができると、作成者は意味解析に対し統計的に関与することができる。
【０６６１】
一般に、曖昧さは、作成者には見え、作成者は曖昧さをＳＰＬクライアントアプリケーションで処理する。コードにより扱われない曖昧さの場合、解釈は複数現れる。ランタイムは、それらの解釈を順位付けして、アプリケーションによって規定された最大数までの解釈をアプリケーションに返す。一実施形態では、解釈のリストが同期的に返される（ＡＰＩコールの一部として）。他の実施形態では、複数の解釈がイベントを使用して非同期に返される。
【０６６２】
ランタイムは、リストから意味論的に同等な解釈を刈り取る。さらに、ランタイムは、２つの解釈の意味論的同等性を判定する既定の実装も提供する。既定の実装は、作成者側でオーバーライドすることもできる。
【０６６３】
一実施形態では、意味論的同等性は、意味論的解釈を言い換えることにより生成された文字列と比較して決定される。しかし、同等性を判定するために他の手法を使用することもできる。
【０６６４】
一般に、開発者は、発話内に発生しうる可能なすべての制約を処理するコードを書く必要はない。作成者は、自分が理解し、処理したい制約のコードを作成するだけである。未オーサリング／未処理の制約は削除される。つまり、未オーサリング／未処理の制約は、それらが発話内に発生していなかったかのように無視されるということである。唯一の例外は、ＮｅｇａｔｉｏｎおよびＮａｍｅｄ制約であり、これらは処理されなければならない。
【０６６５】
意味論は、継承を使って実装される。解決可能型は、すべて基本クラスから継承する。そのため、基本Ｅｎｔｉｔｙクラス、基本Ｆｒａｍｅクラス、および基本Ｒｅｓｔｒｉｃｔｉｏｎクラスがある。基本解決可能型は、表１２３に示されているように、１つの制約節Ｄｅｆａｕｌｔを持つ。
【０６６６】
表１２３：基本解決可能型
【０６６７】
【表１０９】
2005332380.tif 000117
【０６６８】
基本解決可能型のＤｅｆａｕｌｔ制約は、ＮｅｇａｔｉｏｎおよびＮａｍｅｄを除くすべての制約について成功する。表１２４は、Ｍａｉｌ  Ｅｎｔｉｔｙの構文を示している。
【０６６９】
表１２４
【０６７０】
【表１１０】
2005332380.tif 000118
【０６７１】
「ｍａｉｌ  ｒｅｃｅｉｖｅｄ  ｙｅｓｔｅｒｄａｙ」などの発話では、ＳＰＬランタイムは、「ｒｅｃｅｉｖｅｄ  ｙｅｓｔｅｒｄａｙ」をＭａｉｌＥｎｔｉｔｙのオーサリングされた制約節と突き合わせて解決しようと試みる。「ｒｅｃｅｉｖｅｄ  ｙｅｓｔｅｒｄａｙ」はＬｏｃａｔｉｏｎ制約にマッピングされず、ＭａｉｌＥｎｔｉｔｙにはＤｅｆａｕｌｔ制約節がないため、ＳＰＬランタイムは、「ｒｅｃｅｉｖｅｄ  ｙｅｓｔｅｒｄａｙ」をＥｎｔｉｔｙであるＭａｉｌＥｎｔｉｔｙの基本型と突き合わせて解決しようと試みる。Ｅｎｔｉｔｙ内のＤｅｆａｕｌｔ制約節は、真を返し、したがって、ＭａｉｌＥｎｔｉｔｙ解決は成功する。解決は、「ｍａｉｌ」のみが発話「ｍａｉｌ  ｒｅｃｅｉｖｅｄ  ｙｅｓｔｅｒｄａｙ」内で認識されたかのように成功する。
【０６７２】
これが望む挙動でなければ、開発者は、表１２５に示されているように未認識／未処理の制約を拒絶するコードを簡単に作成することができる。
【０６７３】
表１２５：未認識制約を処理するコードを含むＭａｉｌＥｎｔｉｔｙ
【０６７４】
【表１１１】
2005332380.tif 000119
【０６７５】
ここで、ＭａｉｌＥｎｔｉｔｙ内のＤｅｆａｕｌｔ制約節は、基本Ｅｎｔｉｔｙが呼び出される前にテストされる。したがって、「ｍａｉｌ  ｒｅｃｅｉｖｅｄ  ｙｅｓｔｅｒｄａｙ」は、ＭａｉｌＥｎｔｉｔｙと突き合わせて解決しようとしても成功しない。
【０６７６】
一般に、ｏｎ  ｒｅｓｏｌｖｅのスコープの範囲外にあるすべてが、従来のＣ＃規則に従って処理される。解決節内のコードも、Ｃ＃コードである。そのため、解決可能型を、構成を決定するための特別なコードを含む専用Ｃ＃クラスとみなすことが可能である。
【０６７７】
Ｅ５.ＬＯＭのプログラミング
ＬＯＭをプログラムするには、意図した結果を得るためにＬＯＭに用意されている制約を使用する必要がある。これは、いくつかの例にあたってみると最もよく理解できる。そこで、以下の説明では、多数の例を取りあげ、制約および節をモデル化するより複雑な意味論（調整、比較、否定など）を調べ、いくつかの「最良の」実施方法について説明する。どのような種類の発話がどの制約および制約が含む情報を生成するかについての詳細が、セクションＤですでに説明されている。
【０６７８】
ＬＯＭのすべての制約型がＳＰＬに対し公開されるわけではない。ＳＰＬでは、コマンドおよび制御シナリオに対する制約型を重視している。ＬＯＭは、それと対照的に、かなり広い応用を持つ。新しいリリースが利用できるようになると、すでに暴露されている意味論関係を新しい制約型として公開することは、下位互換性のため後のリリースで公開される制約型を絞り込むか、または修正しようと試みるよりは容易である。以下の説明では、もっぱら、ＳＰＬコードでのモデル化に制約を使用する方法について重点的に取りあげる。一般に、制約は、開発者に対しては、Ｍｉｃｒｏｓｏｆｔ（登録商標）の．ＮｅｔランタイムのＦｒａｍｅｗｏｒｋ  Ｃｌａｓｓ  Ｌｉｂｒａｒｙ（ＦＣＬ）に似たクラスライブラリとして現れる。
【０６７９】
Ａｃｃｏｍｐａｎｉｍｅｎｔ制約は、ホストに随伴するエンティティをモデル化する。Ａｃｃｏｍｐａｎｉｍｅｎｔは、エンティティおよびフレーム上で使用できる。いくつかの例として、ｍｅｅｔｉｎｇ  ｗｉｔｈ  ｍｙ  ｍａｎａｇｅｒ、ｃｈａｔ  ｗｉｔｈ  Ｂｏｂ、ｅｍａｉｌ  ｗｉｔｈ  ａｔｔａｃｈｍｅｎｔｓ、およびｍｅｒｇｅ  Ｆｉｌｅ  Ａ  ｗｉｔｈ  Ｆｉｌｅ  Ｂがある。Ａｃｃｏｍｐａｎｉｍｅｎｔ制約は、ホストに随伴するエンティティを表す型Ｅｎｔｉｔｙの１つのシステムスロットａｃｃｏｍｐを含む。作成者は、表１２６に示されているようにホストに随伴可能なエンティティの型を制約することができる。
【０６８０】
表１２６：「ｅｍａｉｌ  ｗｉｔｈ  ａｔｔａｃｈｍｅｎｔｓ」
【０６８１】
【表１１２】
2005332380.tif 000120
【０６８２】
ＡｓＢｅｉｎｇ制約では、動詞が作用するＤｏｎｅＴｏ．ｗｈａｔエンティティの何らかのプロパティを選び出す。ＡｓＢｅｉｎｇ制約は、Ｆｒａｍｅｓ上で使用できる。いくつかの例として、「ｓｈｏｗ  ｓｔａｔｕｓ  ａｓ  ｂｕｓｙ」、「ｓａｖｅ  ａｓ  ｔｅｘｔ  ｆｉｌｅ」、および「ｍａｋｅ  ｔｈｅ  ｆｏｎｔ  ｌａｒｇｅ」がある。ＡｓＢｅｉｎｇ制約は、選び出される制約を表す１つのシステムスロットｒｅｓｔｒを持つ。制約型がスロットに入るようにするのではなく、制約の型を特定の制約型に制約する。制約は、システムスロット内で様々なサポートされている型を取るオーバーロードされたＡｓＢｅｉｎｇ制約を提供することにより特定の型に制限される。以下の制約がサポートされている（例）：
AsBeing<restr := Modifier> : "mark message as low priority"
AsBeing<restr := Possessor> : "make this file mine"
AsBeing<restr := Ordinal> : "put this message first"
いくつかの実施形態では、「ｌｏｇ  ｉｎ  ａｓ  ｍｙ  ｍａｎａｇｅｒ」などの語句は、正常に解決できる。しかし、これだと、Ｅｎｔｉｔｉｅｓをスロット型として許可する必要があるであろう。
【０６８３】
ＡｓＢｅｉｎｇ制約は、動詞、そのＤｏｎｅＴｏ．ｗｈａｔエンティティ、およびこのエンティティに対する制約の間の３場所関係を定義する。ＳＰＬはこの関係の強いバインディングを強制しないが、最良の方法は、表１２７に示されているように関係を強制することであろう。
【０６８４】
表１２７：「ｓｈｏｗ  ｍ  ｓｔａｔｕｓ  ａｓ  ｂｕｓｙ」
【０６８５】
【表１１３】
2005332380.tif 000121
【０６８６】
Ｃａｒｄｉｎａｌ制約は、数量詞により表現されるように基数をモデル化する（例えば、「３  ｆｉｌｅｓ」）。Ｃａｒｄｉｎａｌ制約は、エンティティ上で使用できる。Ｃａｒｄｉｎａｌオブジェクトには、Ｃａｒｄｉｎａｌ．ｎｕｍｂｅｒというメンバがあり、これは、表１２８に示されているような実際の基数値を与える。
【０６８７】
表１２８：「３  ｅｍａｉｌ」
【０６８８】
【表１１４】
2005332380.tif 000122
【０６８９】
Ｃｏｍｐａｒｉｓｏｎ制約は、エンティティと他の明示的に識別されたエンティティとの比較をモデル化する。これは、比較する１つまたは複数のエンティティは暗黙のままにされている「ａ  ｂｉｇｇｅｒ  ｆｉｌｅ」などの表現には使用されない。Ｃｏｍｐａｒｉｓｏｎに対して定義されているシステムスロットは、比較が実行される際の次元であるｄｉｍｅｎｓｉｏｎおよび比較先のエンティティであるｃｏｍｐａｒｅＴｏの２つがある。例えば、「ｂｉｇｇｅｒ  ｆｉｌｅ  ｔｈａｎ  ｍｙｄｏｃ．ｔｘｔ」では、「ｂｉｇｇｅｒ」は比較のｄｉｍｅｎｓｉｏｎであり、「ｍｙｄｏｃ．ｔｘｔ」はｃｏｍｐａｒｅＴｏエンティティである。ｄｉｍｅｎｓｉｏｎは、Ｒｅｓｔｒｉｃｔｉｏｎ型である。一般に、Ｃｏｍｐａｒｉｓｏｎ制約では、複数のエンティティの何らかのプロパティについて２つのエンティティの比較を行うことができる。
【０６９０】
比較のいくつかの例として、「ａ  ｂｏｏｋ  ｍｏｒｅ  ａｂｏｕｔ  ｃａｔｓ  ｔｈａｎ  ｄｏｇｓ」、「ｍａｉｌ  ｌａｒｇｅｒ  ｔｈａｎ  １０ＫＢ」、および「ｍａｋｅ  ｆｏｎｔ  ｓｍａｌｌｅｒ  ｔｈａｎ  １２  ｐｔｓ」をあげられる。いくつかの実施形態では、ｄｉｍｅｎｓｉｏｎ制約にはＤｅｇｒｅｅ修飾語が付くという要求条件を強制することが望ましい場合がある。例えば、「ｆｉｌｅ  ｂｉｇ  ｔｈａｎ  ｍｙｄｏｃ．ｔｘｔ」という語句は、ｄｉｍｅｎｓｉｏｎ制約が制約型でないため、解決すべきでない。
【０６９１】
Ｄｅｇｒｅｅ制約は、制約の程度をモデル化し、また制約上で使用できる。これは、ｖｅｒｙ、ｅｘｔｒｅｍｅｌｙ、ｓｌｉｇｈｔｌｙ、ａｌｍｏｓｔ、ｍｏｒｅ、ｌｅｓｓ、ｍｏｓｔ、およびｌｅａｓｔのような単語をグループにまとめる。いくつかの例として、「ａｌｍｏｓｔ  ｉｎ  ｔｈｅ  ｂｏｘ」、「ｅｘｔｒｅｍｅｌｙ  ｒｅｄ」、「ｖｅｒｙ  ｌａｒｇｅ」、および「ｍｏｒｅ  ｔｏ  ｔｈｅ  ｌｅｆｔ」などがある。グループ化された単語は、「程度」を表現する集合に分類される。程度の型は以下のとおりである。
【０６９２】
More: bigger, more relevant
Most: biggest, most relevant
Less: less relevant
Least: least relevant
Same: as big
High: very big, extremely popular
Low: not very big
「ｓｍａｌｌｅｒ」は「ｍｏｒｅ  ｓｍａｌｌ」としてモデル化され、「ｌｅｓｓ  ｂｉｇ」としてモデル化されないことに留意されたい。
【０６９３】
「１０ＫＢ  ｌａｒｇｅｒ  ｆｉｌｅ」のような発話では、これは、「ｍｏｒｅ」（Ｄｅｇｒｅｅ）を修飾する「１０ＫＢ」（Ｍｏｄｉｆｉｅｒ）および「ｌａｒｇｅ」を修飾する組み合わせた「１０ＫＢ  ｍｏｒｅ」概念としてモデル化される。対照的に、発話「１０ＫＢ  ｌａｒｇｅ  ｆｉｌｅ」は、「ｆｉｌｅ」エンティティ上の２つのＭｏｄｉｆｉｅｒ制約「１０ＫＢ」および「ｌａｒｇｅ」としてモデル化される（「ｌａｒｇｅ，１０ＫＢ  ｆｉｌｅ」と同等）。表１２９は、「ｌａｒｇｅ」を表す語彙単語の表記リストの表記構文およびそれらの制約が適用されるＦｉｌｅ  Ｅｎｔｉｔｙの構文を示している。
【０６９４】
表１２９：「ｌａｒｇｅ」を表す「ＬＡＲＧＥ」．／／語彙単語
【０６９５】
【表１１５−１】
2005332380.tif 000123
【０６９６】
【表１１５−２】
2005332380.tif 000124
【０６９７】
【表１１５−３】
2005332380.tif 000125
【０６９８】
一般に、「ｍｏｒｅ  ｌａｒｇｅ」および「１０ＫＢ  ｌａｒｇｅｒ」に対し別々の制約型を作成する必要はない。これらはすべて、ＬａｒｇｅＭｏｄｉｆｉｅｒの下に置かれている可能性がある。その後、ＦｉｌｅＥｎｔｉｔｙなどのコンシューマは、表１３０に示されているように、必要ならば、単に、ＬａｒｇｅＭｏｄｉｆｉｅｒのＲｅｓｔｒｉｃｔｉｏｎＣｏｌｌｅｃｔｉｏｎプロパティを調べ、「１０ＫＢ  ｍｏｒｅ」および「ｍｏｒｅ」が発話内に存在するかチェックするだけである。
【０６９９】
表１３０：Ｌａｒｇｅ修飾語句
【０７００】
【表１１６】
2005332380.tif 000126
【０７０１】
Ｄｏｅｒ制約は、作用を実行するエンティティを表し、Ｆｒａｍｅｓ上で使用できる。例えば、「Ｂｏｂ  ｏｐｅｎｅｄ  ｔｈｅ  ｆｉｌｅ」または「ｔｈｅ  ｆｉｌｅ  ｗａｓ  ｏｐｅｎｅｄ  ｂｙ  Ｂｏｂ」は、両方とも、Ｄｏｅｒ制約をトリガする。Ｄｏｅｒ制約は、実際の行為者を表す型Ｅｎｔｉｔｙの１つのシステムスロット「ｗｈｏ」を含む。
【０７０２】
通常、フレームがコマンドにより使用される場合に、Ｄｏｅｒはコンピュータである。しかし、フレームがフレームベースの制約として使用される場合（例えば、「ｆｉｌｅ  ｏｐｅｎｅｄ  ｂｙ  Ｂｏｂ」）、行為者の識別が関係することになる。作成者は、Ｄｏｅｒ制約を使用して、行為者の型を制約することができる。
【０７０３】
すべての基本フレームは、ａｓｐｒｏｐｅｒｔｙで定義されたＤｏｅｒ制約を持ち、そのため、表１３１で示されているようにコンシューマ側でのサブタイプ化が簡単である。
【０７０４】
表１３１：基本フレーム（ｏｐｅｎ）
【０７０５】
【表１１７】
2005332380.tif 000127
【０７０６】
ＤｏｎｅＴｏ制約は、作用の実行先のエンティティを表す。例えば、「ｏｐｅｎ  ｔｈｅ  ｆｉｌｅ」および「ｔｈｅ  ｆｉｌｅ  ｗａｓ  ｏｐｅｎｅｄ」は、ＤｏｎｅＴｏ制約を呼び出す。これは、作用の対象を表す型Ｅｎｔｉｔｙのシステムスロットｗｈａｔを含む。
【０７０７】
すべての基本フレームは、ａｓｐｒｏｐｅｒｔｙで定義されたＤｏｎｅＴｏ制約を持ち、そのため、表１３２で示されているようにコンシューマ側でのサブタイプ化が簡単である。
【０７０８】
表１３２：基本フレームＯｐｅｎ
【０７０９】
【表１１８】
2005332380.tif 000128
【０７１０】
Ｇｏａｌ制約は、作用または修飾の終点をモデル化する。Ｇｏａｌ制約は、Ｆｒａｍｅｓ上で使用できる。いくつかの例として、「ｓｅｎｄ  ｍａｉｌ  ｔｏ  Ｂｏｂ」、「ｃｈａｎｇｅ  ｐａｓｓｗｏｒｄ  ｔｏ  ＸＸＸ」などがある。これは、表１３３に示されているように終点を表す型Ｅｎｔｉｔｙのシステムスロットｇｏａｌを含む。
【０７１１】
表１３３：「ｓｅｎｄ  ｍａｉｌ  ｔｏ  Ｂｏｂ」
【０７１２】
【表１１９】
2005332380.tif 000129
【０７１３】
Ｉｔｅｒａｔｉｏｎ制約は、作用の繰り返しをモデル化し、また、Ｆｒａｍｅｓ上で使用できる。例えば、「ｐｒｉｎｔ  ３  ｔｉｍｅｓ」は、表１３４に示されているＩｔｅｒａｔｉｏｎ制約をトリガする。
【０７１４】
表１３４：Ｉｔｅｒａｔｉｏｎ制約
【０７１５】
【表１２０】
2005332380.tif 000130
【０７１６】
Ｌｏｃａｔｉｏｎ制約はどこかに配置されているという意味論をモデル化する。Ｌｏｃａｔｉｏｎ制約は、フレームおよびエンティティ上で使用できる。例えば、「ｍａｉｌ  ｉｎ  Ｉｎｂｏｘ」、「ｆｉｌｅ  ｌｏｃａｔｅｄ  ｏｎ  ｔｈｅ  ｄｅｓｋｔｏｐ」、および「ｓｅａｒｃｈ  ｔｈｅ  ｗｅｂ」は、すべて、Ｌｏｃａｔｉｏｎ制約をトリガする。これは、表１３５に示されているように実際の場所を表す型Ｅｎｔｉｔｙのシステムスロットｌｏｃを含む。
【０７１７】
表１３５：Ｌｏｃａｔｉｏｎ制約
【０７１８】
【表１２１】
2005332380.tif 000131
【０７１９】
Ｍｅａｎｓ制約は、フレーム上で使用することができるが、詳細については、セクションＤのＬＯＭで説明する。Ｍｏｄｉｆｉｅｒ制約は、Ｆｒａｍｅｓ、Ｅｎｔｉｔｉｅｓ、およびＲｅｓｔｒｉｃｔｉｏｎｓ上で使用できる。Ｍｏｄｉｆｉｅｒ制約は、「ｌａｒｇｅ  ｆｉｌｅ」、「ｓｃｈｏｏｌ  ｂｕｓ」、「ｆｏｎｔ  ｔｈａｔ  ｉｓ  ｒｅｄ」、および「ｐｒｉｎｔ  ｓｌｏｗｌｙ」などの形容詞的修飾語句を表す。これは、形容詞を表す型Ｄｅｎｏｔｅｒの１つのシステムスロットｍｏｄを持つ。「ＭＳＮ  ｃｏｎｓｕｍｅｒ  ａｐｐｌｉｃａｔｉｏｎ」などの名詞−名詞複合語については、以下のようにモデル化できる。
【０７２０】
Modifier("MSN") and Modifier("consumer") on Entity("application");
Modifier("MSN consumer") on Entity("application");
Modifier("MSN") and Entity("consumer application"); and/or
Entity("MSN consumer application")
Ｎａｍｅｄ制約は、エンティティの名前を表す。いくつかの例として、「Ｉｎｂｏｘ  ｆｏｌｄｅｒ」、「ｆｉｌｅ  ｎａｍｅｄ  ｆｏｏ．ｔｘｔ」、「ｆｉｌｅ  ｗｉｔｈ  ｔｈｅ  ｎａｍｅ  ｆｏｏ．ｔｘｔ」、「ｏｐｅｎ  ｆｏｏ．ｔｘｔ」、および「ｔｈｅ  ｆｉｌｅ  ｆｏｏ．ｔｘｔ」などがある。システムスロットｎａｍｅは、表１３６に示されているような実際の名前である。
【０７２１】
表１３６：「ｆｉｌｅ  ｎａｍｅｄ  ｆｏｏ．ｔｘｔ」
【０７２２】
【表１２２】
2005332380.tif 000132
【０７２３】
ホストに対するＮｅｇａｔｉｏｎ制約は、ホストが否定されることを意味し、その制約節が否定されることを意味しない。いくつかの例として、「ｄｏｎ’ｔ  ａｌｌｏｗ  ｍａｉｌ  ｆｒｏｍ  Ｊｏｅ」および「ｍａｉｌ  ｎｏｔ  ｆｒｏｍ  Ｊｏｅ」がある。表１３７は、否定付きのＦｒａｍｅの構文を例示している。
【０７２４】
表１３７：否定付きのフレーム
【０７２５】
【表１２３】
2005332380.tif 000133
【０７２６】
発話が否定を含むが、ＳＰＬコードはＮｅｇａｔｉｏｎ制約節を持たない場合、発話は解決に失敗する。これは、オーサリングされない場合に単に削除される他の制約とは異なる。
【０７２７】
Ｎｅｇａｔｉｏｎ制約は、エンティティでは使用できない。ＳＰＬについては、エンティティが出現する「ｕｎｉｖｅｒｓｅ」はエンティティがどのように使用されているかに左右され、したがって、エンティティの否定は必要ない。例えば、「Ｄｉｓｐｌａｙ  ｅｖｅｒｙｔｈｉｎｇ  ｂｕｔ  ｔｈｅ  ｍａｉｌ」などの発話では、ｕｎｉｖｅｒｓｅは、アプリケーションが表示可能なすべてであり、必ずしもアプリケーションがモデル化するすべてのエンティティではない。発話「ｄｏｎ’ｔ  ａｌｌｏｗ  ｍａｉｌ  ｆｒｏｍ  Ｂｏｂ」では、許可または禁止することができる内容のｕｎｉｖｅｒｓｅはメールにのみ非常にうまく制約することができ、したがって、メールの否定はこの文脈では意味を持たないであろう。このため、エンティティ否定は、「！」構文を使用してエンティティのコンシューマにより処理される。
【０７２８】
否定スコープ明確化は、ＳＰＬコードにより決定される。例えば、「ｄｏｎ’ｔ  ｌｏｏｋ  ｏｎ  ｔｈｅ  ｔａｂｌｅ」は、以下の否定スコープの曖昧さを持ちうる。
【０７２９】
Don't look on the table (but sit on it instead)：否定はｌｏｏｋフレームに係る
Don't look on the table (but look under it)：否定はＬｏｃａｔｉｏｎ制約に係る
Don't look on the table (but look on the chair)：否定はＬｏｃａｔｉｏｎ．ｌｏｃエンティティにかかる
どの意味論的解釈が解決されるかは、コードのオーサリング方法に依存する。実際、オーサリングされたコードに応じて、これらすべての読み取りの解決は成功し、したがって複数の解釈が得られることがある。ランタイムは、通常、スコープ曖昧さの優先傾向を持ち、複数の解釈が順位付けされる。表１３８は否定のモデル化を示している。
【０７３０】
表１３８：否定の係り
【０７３１】
【表１２４】
2005332380.tif 000134
【０７３２】
また、表１３９に示されているように、「！」（ＮＯＴ）構文は、簡便な表記法としてフレームおよび制約に適用することができる。
【０７３３】
表１３９
【０７３４】
【表１２５】
2005332380.tif 000135
【０７３５】
Ｏｒｄｉｎａｌ制約では、位置の何らかの概念を順に表現する序数詞およびｐｒｅｖｉｏｕｓなどのその他の修飾語句をモデル化する。いくつかの例として、「ｆｉｒｓｔ  ｆｉｌｅ」、「ｔｈｉｒｄ  ｂｏｏｋ」、および「ｌａｓｔ  ｅｍａｉｌ」がある。Ｏｒｄｉｎａｌ制約は、例えば、表１４０に示されているようなＣａｒｄｉｎａｌ（「３」）制約を修飾するＯｒｄｉｎａｌ（「ｆｉｒｓｔ」）制約としてモデル化される「ｆｉｒｓｔ  ３  ｂｏｏｋｓ」などの他の制約にも適用可能である。
【０７３６】
表１４０：Ｏｒｄｉｎａｌ制約
【０７３７】
【表１２６】
2005332380.tif 000136
【０７３８】
Ｐｏｓｓｅｓｓｏｒ制約は、エンティティの所有者をモデル化し、エンティティに適用される。いくつかの例として、「ｍｙ  ｂｏｏｋ」および「Ｂｏｂ’ｓ  ｂｏｏｋ」がある。型Ｅｎｔｉｔｙのシステムスロットｏｗｎｅｒは、エンティティの所有者を表す。「Ｂｏｂ’ｓ  ｂｏｏｋ」のように所有者が明示的に示された場合、「Ｂｏｂ」はｏｗｎｅｒスロットと突き合わせて解決される。「ｈｅｒ  ｆｉｌｅ」のように所有者が代名詞の場合、ランタイムは前方照応解決により代名詞を解決しようと試みる。この前方照応解決が所有者エンティティの発見に失敗した場合、ｏｗｎｅｒスロットはヌルになる。表１４１は、Ｐｏｓｓｅｓｓｏｒ制約の構文を示している。
【０７３９】
表１４１：Ｐｏｓｓｅｓｓｏｒ制約
【０７４０】
【表１２７】
2005332380.tif 000137
【０７４１】
Ｑｕａｎｔｉｆｉｅｒ制約はＥｎｔｉｔｉｅｓ上で使用を許され、数量表現をモデル化する。いくつかの例として、「ａｌｌ  ｆｉｌｅｓ」、「ａ  ｆｅｗ  ｂｏｏｋｓ」、および「ｏｎｅ  ｔｈｉｒｄ  ｏｆ  ｔｈｅ  ｐａｇｅ」がある。以下に数量詞型を示す。
【０７４２】
All: all ((of) the), every, each (of the)
None: no, none (of the)
Some: some (of the)
Most: most (of the), the majority of
Many: many (of the)
Few: few (of the), not many (of the)
Percentage: a half of, 1/3 of, 40% of
いくつかの実施形態では、ＱｕａｎｔｉｆｉｅｒとＣａｒｄｉｎａｌとの間に階層的関係が存在しうる。
【０７４３】
ＳｏｒｔＯｒｄｅｒ制約は並べ替えのスタイルをモデル化する。例えば、「ｓｏｒｔ  ｉｎ  ａｌｐｈａｂｅｔｉｃａｌ  ｏｒｄｅｒ」および「ｄｉｓｐｌａｙ  ｉｎ  ｒｅｖｅｒｓｅ  ｏｒｄｅｒ  ｂｙ  ｎａｍｅ」などである。この制約については、表５６に関して上で詳しく説明されている。
【０７４４】
Ｔｉｍｅ制約は、実際の時間表現、つまり時点および／またはタイムスパンに変換可能な時間表現をモデル化する。例として、「ｄｅｌｅｔｅ  ａｆｔｅｒ  ３  ｄａｙｓ」、「ｍａｉｌ  ｆｒｏｍ  ｙｅｓｔｅｒｄａｙ」、および「ｓｃｈｅｄｕｌｅ  ｆｏｒ  ｔｏｍｏｒｒｏｗ  ｆｒｏｍ  １  −  ３  ｐｍ」がある。Ｔｉｍｅ制約は、すでに上のセクションＤで詳細に説明されている。
【０７４５】
Ｔｏｐｉｃ制約は、主題をモデル化する。いくつかの例として、「ｂｏｏｋ  ａｂｏｕｔ  ｄｏｇｓ」、「ｂｏｏｋ  ｒｅｇａｒｄｉｎｇ  ｄｏｇｓ」、および「ｂｏｏｋ  ｗｉｔｈ  ｔｈｅ  ｓｕｂｊｅｃｔ  ｄｏｇｓ」がある。これは、話題文字列を表す型ｓｔｒｉｎｇの１つのシステムスロットｔｏｐｉｃを持つ。この制約は、すでに上のセクションＤで詳細に説明されている。表１４２は、Ｔｏｐｉｃを持つＢｏｏｋＥｎｔｉｔｙコードブロックを示している。
【０７４６】
表１４２：ＢｏｏｋＥｎｔｉｔｙ
【０７４７】
【表１２８】
2005332380.tif 000138
【０７４８】
接続詞（「ａｎｄ」）および離接的接続詞（「ｏｒ」）が、コマンド、エンティティ、および制約について出現しうる。接続詞および離接的接続詞は、Ｃｏｏｒｄｉｎａｔｉｏｎの見出しの下に入る。一般に、調整の曖昧さは、エンティティおよび修飾語句を接続詞および離接的接続詞にどのように分配するか、および複数の「ａｎｄ」および「ｏｒ」演算子を含む発話内の曖昧さを括弧で囲むことから生じる。Ｎｅｇａｔｉｏｎのように、この明確化はオーサリングされたコードにより決定される。例えば、発話「ｆｉｎｄ  ｍａｉｌ  ａｎｄ  ｎｏｔｅｓ  ｃｒｅａｔｅｄ  ｙｅｓｔｅｒｄａｙ」に関して、ＳＰＬ作成者は、これを以下のようにモデル化することができる。
【０７４９】
ａ．(Find (mail created yesterday) AND (notes created yesterday)).
ｂ．(Find (mail) AND (notes created yesterday)).
ｃ．(Find (mail created yesterday)) AND (Find (notes created yesterday)).
ｄ．(Find (mail)) AND (Find (notes created yesterday)).
「ｃｒｅａｔｅｄ  ｙｅｓｔｅｒｄａｙ」および「ｆｉｎｄ」をそのエンティティ「ｍａｉｌ」および「ｎｏｔｅｓ」とともに分配する方法は、オーサリングされたＳＰＬコードにより決定される。説明のため、作成者は、型ＭａｉｌＥｎｔｉｔｙのエンティティのみを認識するＦｉｎｄＭａｉｌＣｏｍｍａｎｄおよび型ＮｏｔｅｓＥｎｔｉｔｙのエンティティのみを認識するＦｉｎｄＮｏｔｅｓＣｏｍｍａｎｄをコーディングすると仮定しよう。さらに、オーサリングされたコードは、ＭａｉｌＥｎｔｉｔｙが作成時刻という概念を持たず、ＮｏｔｅｓＥｎｔｉｔｙは表１４３に示されているように持つと規定している。
【０７５０】
表１４３：調整
【０７５１】
【表１２９】
2005332380.tif 000139
【０７５２】
このオーサリングされたコードでは、発話「ｆｉｎｄ  ｍａｉｌ  ａｎｄ  ｎｏｔｅｓ  ｃｒｅａｔｅｄ  ｙｅｓｔｅｒｄａｙ」について、意味解析は上記リスト（「Find (mail) and find (notes created yesterday)」）から読み取り（ｄ）のみを出力する。ＳＰＬ作成者は、すべての可能性を理解しておく必要はない。作成者は、そのアプリケーションの意味論に関して考えるだけでよい（例えば、ＭａｉｌＥｎｔｉｔｙは作成時刻を認識しないが、ＮｏｔｅｓＥｎｔｉｔｙは認識する）。
【０７５３】
調整されたエンティティは、「ａｎｄ」または「ｏｒ」のいずれかの調整型とともにリンクされるエンティティのリストとして表される。このリスト内のエンティティはすべて、同じ調整型といっしょにリンクされなければならない。さらに、このリスト内のすべてのエンティティは、同じプログラミング型でなければならない（例えば、すべてのＭａｉｌＥｎｔｉｔｙ要素）。
【０７５４】
概して、ランタイムは、複数の解釈を出力して同じ型の調整から生じる曖昧さを括弧で囲むことをモデル化することをしない。むしろ、同じ型の調整とともに調整されるエンティティ（つまり、すべて「ａｎｄ」を含む、またはすべて「ｏｒ」を含む）は、フラットリストとしてモデル化され、問題があるとしても適切括弧付けの決定はアプリケーションに任される。例えば、発話「ｆｉｎｄ  ｍａｉｌ  ａｎｄ  ｂｏｏｋｓ  ａｎｄ  ｆｉｌｅｓ」を取る。これは、「ｆｉｎｄ  ｍａｉｌ  ａｎｄ（ｂｏｏｋｓ  ａｎｄ  ｆｉｌｅｓ）」または「ｆｉｎｄ（ｍａｉｌ  ａｎｄ  ｂｏｏｋｓ）ａｎｄ  ｆｉｌｅｓ」を意味する可能性がある。この曖昧さの括弧付けはモデル化されない、つまり、すべてのエンティティが同じＳＰＬ型であると仮定して、可能なただ１つの読み取りのみが出力されるということである。この発話は、要素の順序が発話内の順序を反映するフラットリストとしてモデル化される。
【０７５５】
しかし、「ａｎｄ」および「ｏｒ」が入り交じっている場合、ランタイムは、複数の読み取りを出力して曖昧さの括弧付けをモデル化する。オーサリングされたコードによっては、これら複数の読み取りから、解決された解釈が複数生じる場合も生じない場合もある。発話「ｆｉｎｄ  ｍａｉｌ  ｏｒ  ｂｏｏｋｓ  ａｎｄ  ｆｉｌｅｓ」に関して、要素のリストは同じ調整型で調整されなければならないため、以下のランタイムは、以下の可能な読み取りを出力する（「ｍａｉｌ」、「ｂｏｏｋｓ」、および「ｆｉｌｅｓ」は同じＳＰＬ型に解決され、Ｆｉｎｄコマンドはエンティティのリストを受け取ると仮定する）。
【０７５６】
(Find (mail OR books)) AND (Find (files))
(Find (mail)) OR (Find (books AND files))
「ｆｉｎｄ」は、「ａｎｄ」と「ｏｒ」に分配される。
【０７５７】
一般に、「ａｎｄ」および「ｏｒ」演算子が混合しているのは、発話内ではふつうのことではなく、したがって、複数の解釈を出力して曖昧さの括弧付けをモデル化することはそれほど煩わしいことではないであろう。
【０７５８】
いくつかの構成では、表１４４に示されているように［］構文を使用してエンティティのコンシューマにより規定できる、Ｅｎｔｉｔｙリストを実装することが使用になる場合がある。
【０７５９】
表１４４：エンティティリスト
【０７６０】
【表１３０】
2005332380.tif 000140
【０７６１】
解釈は、ＳＰＬプログラムと突き合わせて解決された発話の解釈を表す。それぞれの解決された解釈は、少なくとも１つの解決されたコマンドを含む。発話があると、解釈に対し複数のコマンドが生じうる。例えば、「ｆｉｎｄ  ｆｉｌｅ  ｆｏｏ．ｔｘｔ  ａｎｄ  ｐｒｉｎｔ  ｉｔ」では、この発話に２つのコマンドが含まれる。１つの解釈の中のコマンドは、何らかの条件といっしょにリンクされる。現在、これらは、ＡＮＤまたはＯＲのいずれかの調整型によりいっしょにリンクされる（他のモデル化条件節も可能である）。解釈内のコマンドは、同じ解決された型である必要はない。
【０７６２】
以下の説明では、様々な調整例を調べて、要素が接続詞および離接的接続詞にどのように分配されるか、またオーサリングされたコードが調整をどのようにモデル化するかを確認する。この説明では、さらに、コマンド、エンティティ、および制約の調整も調べる。与えられた発話について、曖昧さと分配を例示するため可能な読み取りが示されている。
【０７６３】
繰り返すと、ＳＰＬ作成者は、そのアプリケーションの意味論について考えるということである（例えば、自分のＦｉｎｄコマンドはＭａｉｌＥｎｔｉｔｙのリストに作用することができる）。ランタイムは、接続詞および離接的接続詞への要素の分配の規則に関する言語理解に応じて発話をオーサリングされた内容にマッピングしようとする。表１４５のコードサンプルは、以下に示されている例に使用される。
【０７６４】
表１４５：コード例
【０７６５】
【表１３１】
2005332380.tif 000141
【０７６６】
上記のコードは、コマンド「Ｆｉｎｄ  ｍａｉｌ  ｆｒｏｍ  Ｂｏｂ  ａｎｄ  ｄｅｌｅｔｅ  ｔｈｅｍ」を以下のように解決する。
【０７６７】
【表１３２】
2005332380.tif 000142
【０７６８】
コマンド「Ｆｉｎｄ  ａｎｄ／ｏｒ  ｄｅｌｅｔｅ  ｍａｉｌ  ｆｒｏｍ  Ｂｏｂ」は、以下のように、４つの解釈を持つように解決される。
【０７６９】
解釈１：「ｍａｉｌ  ｆｒｏｍ  Ｂｏｂ」は「ａｎｄ」／「ｏｒ」に分配される。
【０７７０】
【表１３３】
2005332380.tif 000143
【０７７１】
解釈２：「ｍａｉｌ  ｆｒｏｍ  Ｂｏｂ」は「ａｎｄ」／「ｏｒ」に分配されない。
【０７７２】
【表１３４】
2005332380.tif 000144
【０７７３】
解釈３：「ｍａｉｌ  ｆｒｏｍ  Ｂｏｂ」は「ａｎｄ」／「ｏｒ」に分配されない。この解釈は、調整の曖昧さからではなく、オーサリングされたコードから生じる。３つの「ｆｉｎｄ」コマンドがあり、「ｅｍｐｔｙ」エンティティが有効なエンティティであるため、裸の「ｆｉｎｄ」はこれらのコマンドのうちのどれかに解決できる。
【０７７４】
【表１３５】
2005332380.tif 000145
【０７７５】
解釈４：解釈３と同じ。
【０７７６】
【表１３６】
2005332380.tif 000146
【０７７７】
リストに入っている解釈のすべてが、上記のオーサリングされたコードに対して可能である。
【０７７８】
コマンド「Ｆｉｎｄ  ｍａｉｌ  ｆｒｏｍ  Ｂｏｂ  ａｎｄ／ｏｒ  ｄｅｌｅｔｅ」は、上記のオーサリングされたコードと突き合わせて解決され、以下のように、２つの可能な解釈が生じる。
【０７７９】
解釈１：「ｍａｉｌ  ｆｒｏｍ  Ｂｏｂ」は「ａｎｄ」／「ｏｒ」に分配される。
【０７８０】
【表１３７】
2005332380.tif 000147
【０７８１】
解釈２：「ｍａｉｌ  ｆｒｏｍ  Ｂｏｂ」は「ａｎｄ」／「ｏｒ」に分配されない。
【０７８２】
【表１３８】
2005332380.tif 000148
【０７８３】
この例の中の語句と前の例の語句との唯一の違いは、空のＭａｉｌＥｎｔｉｔｙを持つコマンド「ｄｅｌｅｔｅ」である。上記のオーサリングされたコードでは両方の解釈が可能である。
【０７８４】
コマンド「Ｏｐｅｎ  ｆｉｌｅ  ａｎｄ  ｒｅｐｌｙ  ｏｒ  ｃｒｅａｔｅ  ｍａｉｌ」は、このコードに対して解決され、以下の可能な解釈が得られる。
【０７８５】
解釈１：「ｍａｉｌ」は、「ｏｒ」に分配され、「ｒｅｐｌｙ」に付く。
【０７８６】
【表１３９】
2005332380.tif 000149
【０７８７】
解釈２：エンティティの分配はない
【０７８８】
【表１４０】
2005332380.tif 000150
【０７８９】
解釈３：「ｆｉｌｅ」は、「ａｎｄ」に分配され、「ｒｅｐｌｙ」に付く。この読み取りは、ＦｉｌｅＥｎｔｉｔｙを受け取る「ｒｅｐｌｙ」コマンドがないため、上記のオーサリングされたコードに対して解決されない。
【０７９０】
【表１４１】
2005332380.tif 000151
【０７９１】
コマンド「Ｏｐｅｎ  ｆｉｌｅ  ｏｒ  ｒｅｐｌｙ  ａｎｄ  ｃｒｅａｔｅ  ｍａｉｌ」により、以下のように３つの可能な解釈が得られる。
【０７９２】
解釈１：「ｆｉｌｅ」は、「ｏｒ」に分配され、「ｒｅｐｌｙ」に付く。この読み取りは、「ＦｉｌｅＥｎｔｉｔｙ」を受け取る「ｒｅｐｌｙ」コマンドがないため、上記のオーサリングされたコードに対して解決しない。
【０７９３】
【表１４２】
2005332380.tif 000152
【０７９４】
解釈２：「ｍａｉｌ」は、「ａｎｄ」に分配され、「ｒｅｐｌｙ」に付く。
【０７９５】
【表１４３】
2005332380.tif 000153
【０７９６】
解釈３：エンティティの分配はない
【０７９７】
【表１４４】
2005332380.tif 000154
【０７９８】
一般に、制約に対する「ａｎｄ」はＳＰＬの意味論により暗示される。例えば、コマンド「ｆｉｎｄ  ｍａｉｌ  ｆｒｏｍ  Ｂｏｂ  ａｎｄ  ｉｎ  Ｉｎｂｏｘ」により、２つの制約、つまりＳｏｕｒｃｅ制約およびＬｏｃａｔｉｏｎ制約がＭａｉｌＥｎｔｉｔｙ上で発火する。そこで、以下の説明では、制約の離接的接続詞を調べる。
【０７９９】
上記のコードに加えて、以下のコード行を使用し、ＭａｉｌＥｎｔｉｔｙのリストを認識するＦｉｎｄＭａｉｌＬｉｓｔＣｏｍｍａｎｄを追加することにする。
【０８００】
【表１４５】
2005332380.tif 000155
【０８０１】
コマンド「ｆｉｎｄ  ｍａｉｌ  ｆｒｏｍ  Ｂｏｂ  ｏｒ  ｃｒｅａｔｅｄ  ｙｅｓｔｅｒｄａｙ」は、以下の解釈に解決する。
【０８０２】
解釈１：「ｍａｉｌ」は「ｏｒ」上に分配される。この結果、ＭａｉｌＥｎｔｉｔｙのリストが得られる。
【０８０３】
【表１４６】
2005332380.tif 000156
【０８０４】
ＦｉｎｄＭａｉｌＬｉｓｔＣｏｍｍａｎｄが存在しなかった場合、または解決に成功しなかった場合、「ｆｉｎｄ」はエンティティに分配され、２つのＦｉｎｄＭａｉｌＣｏｍｍａｎｄｓを生成する。
【０８０５】
【表１４７】
2005332380.tif 000157
【０８０６】
コマンド「find mail from Bob or created yesterday and in Inbox」は、以下のように解釈される。
【０８０７】
解釈１：「ｉｎ  Ｉｎｂｏｘ」が括弧付けに、つまり「ｏｒ」に分配される（ｍａｉｌ  ｆｒｏｍ  Ｂｏｂ  ｏｒ  ｃｒｅａｔｅｄ  ｙｅｓｔｅｒｄａｙ）の括弧付け。
【０８０８】
【表１４８】
2005332380.tif 000158
【０８０９】
再び、ＦｉｎｄＭａｉｌＬｉｓｔＣｏｍｍａｎｄが存在しなかった場合、または解決に成功しなかった場合、「ｆｉｎｄ」はエンティティに分配され、２つのＦｉｎｄＭａｉｌＣｏｍｍａｎｄｓを生成する。
【０８１０】
解釈２：（ｍａｉｌ  ｃｒｅａｔｅｄ  ｙｅｓｔｅｒｄａｙ  ａｎｄ  ｉｎ  Ｉｎｂｏｘ）の括弧付け。「ｍａｉｌ  ｆｒｏｍ  Ｂｏｂ」は、離接的接続詞で結合されているため、括弧付けへの分配はない。
【０８１１】
【表１４９】
2005332380.tif 000159
【０８１２】
再び、ＦｉｎｄＭａｉｌＬｉｓｔＣｏｍｍａｎｄが存在しなかった場合、または解決に成功しなかった場合、「ｆｉｎｄ」はエンティティに分配され、２つのＦｉｎｄＭａｉｌＣｏｍｍａｎｄｓを生成する。
【０８１３】
解釈３：修飾語句および「ｍａｉｌ」の括弧付けは、すべての修飾語句に分配されるわけではない。
【０８１４】
【表１５０】
2005332380.tif 000160
【０８１５】
再び、ＦｉｎｄＭａｉｌＬｉｓｔＣｏｍｍａｎｄが存在しなかった場合、または解決に成功しなかった場合、「ｆｉｎｄ」はエンティティに分配され、２つのＦｉｎｄＭａｉｌＣｏｍｍａｎｄｓを生成する。
【０８１６】
上記コマンドに加えて、一般的なＦｉｎｄＣｏｍｍａｎｄが追加され、これにより、メール、ノート、およびジャーナルアイテムのリストの検索を行うことができる。ＦｉｎｄＣｏｍｍａｎｄは表１４６に示されている。
【０８１７】
表１４６：Ｆｉｎｄコマンド
【０８１８】
【表１５１】
2005332380.tif 000161
【０８１９】
このコマンドが追加されると、以下の例からわかるように、解釈の数が増える。
【０８２０】
コマンド「Ｆｉｎｄ  ｍａｉｌ  ａｎｄ／ｏｒ  ｎｏｔｅｓ  ｃｒｅａｔｅｄ  ｙｅｓｔｅｒｄａｙ」の結果、以下の解釈が得られる。
【０８２１】
解釈１：「ｃｒｅａｔｅｄ  ｙｅｓｔｅｒｄａｙ」は「ａｎｄ」／「ｏｒ」上に分配される。
【０８２２】
【表１５２】
2005332380.tif 000162
【０８２３】
解釈２：「ｃｒｅａｔｅｄ  ｙｅｓｔｅｒｄａｙ」の分配はない。
【０８２４】
【表１５３】
2005332380.tif 000163
【０８２５】
ＦｉｎｄＣｏｍｍａｎｄが存在しなかった場合、または解決に成功しなかった場合、「ｆｉｎｄ」は接続詞に分配され、以下のさらに２つの解釈が生じる。
【０８２６】
解釈３：「ｆｉｎｄ」がエンティティに分配されることを除き１と同じ。
【０８２７】
【表１５４】
2005332380.tif 000164
【０８２８】
解釈４：「ｆｉｎｄ」がエンティティに分配されることを除き２と同じ。
【０８２９】
【表１５５】
2005332380.tif 000165
【０８３０】
コマンド「Find mail from Bob and/or notes created yesterday」の結果、以下の潜在的解釈が得られる。
【０８３１】
解釈１：例１とは異なり、修飾語句の分配はない。
【０８３２】
【表１５６】
2005332380.tif 000166
【０８３３】
解釈２：ＦｉｎｄＣｏｍｍａｎｄが解決しなかった場合、「ｆｉｎｄ」のエンティティへの分配が得られる。
【０８３４】
【表１５７】
2005332380.tif 000167
【０８３５】
コマンド「Find mail, notes, or journal items created yesterday」の結果、以下の潜在的解釈が得られる。
【０８３６】
解釈１：「ｃｒｅａｔｅｄ  ｙｅｓｔｅｒｄａｙ」は「ｍａｉｌ」、「ｎｏｔｅｓ」、および「ｊｏｕｒｎａｌ  ｉｔｅｍｓ」に分配される。
【０８３７】
【表１５８】
2005332380.tif 000168
【０８３８】
解釈２：修飾語句の分配はない
【０８３９】
【表１５９】
2005332380.tif 000169
【０８４０】
ＦｉｎｄＣｏｍｍａｎｄが存在しなかった場合、または解決に成功しなかった場合、「ｆｉｎｄ」は接続詞に分配され、以下のさらに２つの解釈が生じる。
【０８４１】
解釈３：「ｆｉｎｄ」がエンティティに分配されることを除き１と同じ。
【０８４２】
【表１６０】
2005332380.tif 000170
【０８４３】
解釈４：「ｆｉｎｄ」がエンティティに分配されることを除き２と同じ。
【０８４４】
【表１６１】
2005332380.tif 000171
【０８４５】
コマンド「Find mail and notes or journal items created yesterday」の結果、括弧付けの問題が生じる。接続詞の型が入り交じっているため（つまり、「ａｎｄ」と「ｏｒ」の両方が発話内に出現している）、またエンティティのリストとシングルトンエンティティ（ｓｉｎｇｌｅｔｏｎ  ｅｎｔｉｔｉｅｓ）の両方を受け取る「ｆｉｎｄ」コマンドが存在しているため、多数の解釈が生じる可能性がある。したがって、何らかのエンティティのリストを受け取るコマンドだけでなくそのシングルトンエンティティを受け取るコマンドをも持たないことがよい考えである。コードは、できる限り多くの解釈が得られるようにオーサリングされる。
【０８４６】
解釈セット１：「ｃｒｅａｔｅｄ  ｙｅｓｔｅｒｄａｙ」の分配はない。
【０８４７】
【表１６２】
2005332380.tif 000172
【０８４８】
この場合、ＦｉｎｄＪｏｕｒｎａｌＣｏｍｍａｎｄの代わりにただ１つの要素を受け取るＦｉｎｄＣｏｍｍａｎｄで解釈を出力することが必要になることもある。
【０８４９】
【表１６３】
2005332380.tif 000173
【０８５０】
解釈セット２：「ｃｒｅａｔｅｄ  ｙｅｓｔｅｒｄａｙ」は、「ｏｒ」に分配され、「ｎｏｔｅｓ」に付く。
【０８５１】
【表１６４】
2005332380.tif 000174
【０８５２】
解釈セット３：「ｃｒｅａｔｅｄ  ｙｅｓｔｅｒｄａｙ」はすべてのエンティティに分配される。
【０８５３】
【表１６５】
2005332380.tif 000175
【０８５４】
場合によっては、開発者側で制約への様々な言語現象の自分用のマッピングを規定できるようにすることが望ましいことがある。既定の「事後解析」プログラミングとは反対に、発火される制約に対しパターンが影響を及ぼす「事前解析」プログラミングを用意することが望ましい場合もある。一般に、文字列ベースのパターンから言語ベースのパターンまでの一定範囲のパターンを許容することが望ましい。
【０８５５】
一実施形態では、ＬＯＭ開発者が内部的に使用し、ＳＰＬ開発者が外部から使用するパターンを規定する一般的なメカニズムが用意される。外部開発者は、単純なパターンから複雑なパターンまで、様々なパターンを使用できるようになっているべきである。
【０８５６】
一実施形態では、パターンの適用は、表１４７に示されているようにＣ＃属性を使用することに似ている。
【０８５７】
表１４７：パターンの適用
【０８５８】
【表１６６】
2005332380.tif 000176
【０８５９】
一般に、本発明は、できる限りオープンであることを意図しており、これにより、開発者は、定義済みセットからたぶん独立している、自分用のパターンを作成することができる。したがって、開発者は、形式化された意味論的関係（つまり、制約型）をバイパスし、必要に応じて独自の関係を形成することができる。
【０８６０】
モデル化条件節に関して、いくつかの実施形態では、モデル化条件節コマンドは、とても役に立つことがある。単純な例として、「ｉｆ  Ｂｏｂ  ｓｅｎｄｓ  ｍｅ  ｍａｉｌ，ｄｅｌｅｔｅ  ｉｔ」、「ｐａｇｅ  ｍｅ  ｗｈｅｎ  ｍａｉｌ  ｃｏｍｅｓ  ｆｒｏｍ  Ｂｏｂ」、「ｍｏｖｅ  ｔｈｅ  ｆｉｌｅ  ｔｏ  ｃ：＼ｄｏｃｓ  ａｆｔｅｒ  ｃｏｐｙ  ｉｔ」、および「ｗａｒｎ  ｍｅ  ｂｅｆｏｒｅ  ｐｅｒｍａｎｅｎｔｌｙ  ｄｅｌｅｔｉｎｇ  ａ  ｍｅｓｓａｇｅ」などがある。一般に、これをモデル化するメカニズムは、調整されたコマンドのメカニズムに類似していなければならない。他の実施形態では、条件節は、特別な制約型を通じて明らかにできる。
【０８６１】
いくつかの実施形態では、作成者は、解釈を絞り込むために制約節内の複数の制約を推論したい場合がある。作成者は、制約節にデータを格納し、ｓｕｃｃｅｓｓ節においてそれを推論することにより、エレガントではないが、ＡＮＤ推論を模倣することができる。作成者は、共通関数へのコールアウトによりＯＲプロパティの推論を模倣することができる。
【０８６２】
好ましい一実施形態では、作成者は、命令コードを使用して（例えば、データベースを呼び出して）、表記のリストを規定することが許されている。これに対する表記は、特定の実装および関連するデータベースによって、異なることがある。
【０８６３】
一般に、Ｎａｍｅｄ制約から、作成者は名前を文字列として得ることができる。一実施形態では、作成者は、与えられた発話内で認識した名前のリストについてランタイムによる問い合わせが可能な名前クラスを作成できる。例えば、語句「ｆｉｎｄ  Ｇｏｎｅ  ｗｉｔｈ  Ｔｈｅ  Ｗｉｎｄ  ｍｏｖｉｅ」を考えると、作成者は、「Ｇｏｎｅ  ｗｉｔｈ  ｔｈｅ  ｗｉｎｄを映画の名前として認識できる名前クラスを作成することができる。一実施形態では、ＳＰＬは、表１４８に示されているように、名前クラス型を受け取るＮａｍｅｄ制約のオーバーロードを用意できる。
【０８６４】
表１４８：オーバーロードされたＮａｍｅ制約
【０８６５】
【表１６７】
2005332380.tif 000177
【０８６６】
好ましい一実施形態では、ＮａｍｅｄＥｎｔｉｔｙ型は、以下のように、ＮａｍｅｄＥｎｔｉｔｙＲｅｃｏｇｎｉｚｅｒクラスと関連付けられている。
【０８６７】
NamedEntity MovieName uses MoveNameRecognizer;
【０８６８】
【表１６８】
2005332380.tif 000178
【０８６９】
好ましい一実施形態では、開発者は、未知／未オーサリングコマンド（例えば、名詞句）の取り扱い方を規定できる。作成者は、適切に処理するようにアプリケーションをコーディングするか、または特定のエンティティに対して特定のコマンド（または一組のコマンド）を呼び出すようにランタイムに要求するか、または既定のコマンドハンドラを用意することができる。
【０８７０】
一実施形態では、派生クラスは、表１４９に示されているように、基本クラスの制約節を呼び出すことができる。
【０８７１】
表１４９：派生クラスは基本クラスの制約節を呼び出す
【０８７２】
【表１６９】
2005332380.tif 000179
【０８７３】
直接呼び出しは、望ましくないことがある、というのも、節の解決は大部分がランタイムにより制御されているからである。ｐｕｂｌｉｃ／ｐｒｉｖａｔｅ／ｐｒｏｔｅｃｔｅｄ／およびその他の制約節を導入し、それぞれが解決意味論に対しどのような意味を持つのかを調べるのは、無駄な複雑さを加えることになる。その代わりに、基本節が成功した場合に自節を呼び出す前に基本制約節を呼び出すようにインタプリタに知らせる制約条件をさらに加えることができる（例えば、宣言的制約条件）。コンパイラは、表１５０に示されているように、基本クラス内に正確なスロット型を持つ節の存在を強制することができる。
【０８７４】
表１５０
【０８７５】
【表１７０】
2005332380.tif 000180
【０８７６】
ｉｎｖｏｋｅｂａｓｅの意味論は、基本の制約節（宣言的制約条件と命令的制約条件の両方）が、ｉｎｖｏｋｅｂａｓｅで装飾された節が呼び出される前に成功していなければならないということである。意味論を変更する（つまり、基本の節の前に派生節を呼び出す）ことが望ましかった場合、他の構文を使用しなければならない。「ｗｉｔｈ」節の構文は、その節に付いているコードが実行される前に、その節により規定された制約条件が満たされていなければならないということを意味する。
【０８７７】
いくつかの動詞では、ＧｏａｌとＬｏｃａｔｉｏｎを入れ替える。例えば、「ｐｒｉｎｔ  ｔｏ  ｍｙ  ｐｒｉｎｔｅｒ」は、「ｐｒｉｎｔ  ｏｎ  ｍｙ  ｐｒｉｎｔｅｒ」と同じことを意味する。作成者は、場所が構文的にどのように理解されるかによっては（つまり、「ｔｏ」対「ｏｎ」）、２つの異なる制約と突き合わせてコーディングしなくてもよい。制約は両方とも、オーサリングの内容に応じて、それらの動詞について明らかにできる。しかし、場合によっては、「ｔｏ」が常にＧｏａｌとして理解されることを作成者に説明し、ＧｏａｌｓとＬｏｃａｔｉｏｎとすることができる動詞もあれば、そうでない動詞もあることを説明しようとすることについて忘れるほうが容易なこともある。
【０８７８】
抽象型はインスタンス化できない（つまり、直接解決できない）ことを理解しておくことは重要であるが、多態性および共通機能の保持には有用である。作成者が「ｓｅｎｄ  ｍａｉｌ  ｔｏ  Ｂｏｂ」に対するコマンドを作成した場合、「ｓｅｎｄ  ｔｏ  Ｂｏｂ」は、発話内に「ｍａｉｌ」がなくても、そのコマンドと突き合わせて解決すべきである。しかし、これを既定にすると、解釈が多数生じる可能性がある。いくつかの実施形態では、そのような機能が望ましいこともある。既定で、空のエンティティが許容され、有効として取り扱われる場合、作成者は、空のエンティティを拒絶するコードをエンティティのｓｕｃｃｅｓｓ節で作成することができる。既定で空のエンティティが許容されない場合（つまり、発話内にエンティティの証拠がない場合は、解決しない）、コマンドがヌルエンティティを受け付けられるようにするスロット修飾語句を導入することが可能である（「ｏｐｔｉｏｎａｌ」など）。好ましい一実施形態では、ＭａｉｌＥｎｔｉｔｙを含む制約がないことがあり、作成者がこのケースをチェックしたい場合、フレームまたはコマンドは明示的に解決を失敗させる。
【０８７９】
本発明は、特定の実施形態を参照しつつ説明されているが、当業者であれば、本発明の精神および範囲を逸脱することなく、形態および詳細に変更を加えることができることを理解するであろう。
【０８８０】
付録Ｉシナリオ：Ｍｉｃｒｏｓｏｆｔ  Ｏｕｔｌｏｏｋ（登録商標）のプロトタイプ
この実施形態では、Ｍｉｃｒｏｓｏｆｔ  Ｏｕｔｌｏｏｋ（登録商標）は、ＳＰＬおよびＬＯＭを使用したテキスト音声入力に対応している。この対応のほとんどは、言語学に関する知識を有しない、または言語学に関する訓練を受けていない夏季研修生によって実行された。ＳＰＬコードは、Ｍｉｃｒｏｓｏｆｔ  ．Ｎｅｔプラットフォーム上でコンパイルおよび実行されるように設計されており、コードはＯｕｔｌｏｏｋ  ２００２オブジェクトモデルおよびＣＤＯ（Ｃｏｌｌａｂｏｒａｔｉｏｎ  Ｄａｔａ  Ｏｂｊｅｃｔｓ）を通じてＭｉｃｒｏｓｏｆｔ  Ｏｕｔｌｏｏｋと相互作用し、バインディングおよびコマンドを実行する。
【０８８１】
いくつかの高度な検索機能が有効になっており、これにより、異なるデータソースを推論する。いくつかの例として以下のシナリオがある。
【０８８２】
「search for mail that was sent by people on Conference Group」−分配リストを推論する
「show mail from my contacts」−ｃｏｎｔａｃｔｓフォルダ内の人々を推論する
「find mail from my direct reports」−組織図を推論する
さらに、システムは前方照応解決も行う。例えば、「ｓｈｏｗ  ｍｅ  Ｄａｖｉｄ’ｓ  ｍａｎａｇｅｒ」の後に「ｓｅｎｄ  ｍａｉｌ  ｔｏ  ｈｉｍ」が続くと、これは、「ｈｉｍ」が「Ｄａｖｉｄ’ｓ  ｍａｎａｇｅｒ」を指しており開発者にとっては明確になっている。
【０８８３】
さらに、システムは、以下のように、高度な推論およびモデル化を実行する。
【０８８４】
「send mail to everyone on nlgcore except David Bradlee」−否定を推論する
「schedule a meeting every Tuesday with my manager at 2:00 for 1 hour」−複雑な時刻表現と突き合わせてモデル化し、プログラムする。
【０８８５】
付録ＩＩ：Ｍｉｃｒｏｓｏｆｔ  Ｏｕｔｌｏｏｋ（登録商標）コードウォークスルー
以下の説明では、開発者の視点からコマンドを解析する。この説明では、コードのデバッグ時の開発者による調査を模倣する。コマンドは、「ｓｅｎｄ  ｍａｉｌ  ａｂｏｕｔ  ｐａｃｋａｇｅ  ｔｏ  Ｓｅａｔｔｌｅ  ｇｒｏｕｐ」である。この文は、以下のように２つの可能な意味を持つ。
【０８８６】
１．「send mail about package to seattle group」−メールの主題が「ｐａｃｋａｇｅ  ｔｏ  ｓｅａｔｔｌｅ  ｇｒｏｕｐ」である。
【０８８７】
２．「send mail about package to seattle group」−メールの主題が「ｐａｃｋａｇｅ」であり、「ｓｅｎｄ」のターゲット（つまり、メールの送信先）が「ｓｅａｔｔｌｅ  ｇｒｏｕｐ」である。
【０８８８】
領域の知識に応じて、これらの解釈のうちの一方または両方が最終的な解釈リスト内に残る。
【０８８９】
以下にコード全体を示す。ＳＰＬキーワードまたは予約語は太字で示されている。コードスニペットは、解析のステップが進むにつれ省略されてゆく。
【０８９０】
【表１７１】
2005332380.tif 000181
【０８９１】
解釈１
再びコマンドを参照すると、メールの主題が以下のように「ｐａｃｋａｇｅ  ｔｏ  ｓｅａｔｔｌｅ  ｇｒｏｕｐ」であるというのが第１の解釈である。
【０８９２】
"send mail about package to seattle group"
呼び出される第１のオブジェクトは、ＳｅｎｄＭａｉｌＣｏｍｍａｎｄの「ｏｎ  ｒｅｓｏｌｖｅ」節の「ｏｎ  ｂｅｇｉｎ」節である。
【０８９３】
【表１７２】
2005332380.tif 000182
【０８９４】
コマンドのコンストラクタが呼び出され、節内のコードが実行される。節が「ｆａｌｓｅ」を返した場合、このコマンドに対するそれ以上の解析は停止する。この場合、ＳｅｎｄＭａｉｌＣｏｎｔｅｘｔ（）がｆａｌｓｅを返せば（つまり、アプリケーションが現在メール送信のコンテキストに入っていない）、解析は停止する。
【０８９５】
アプリケーションがメールを送信できると仮定すると、ＳＰＬインタプリタはその解析を続ける。ＳｅｎｄＭａｉｌＣｏｍｍａｎｄｓがＳｅｎｄＭａｉｌＦｒａｍｅを使用することを知らせるので、呼び出される次のオブジェクトは、ＳｅｎｄＭａｉｌＦｒａｍｅである。インタプリタは、その語句内の単語「ｓｅｎｄ」がＳｅｎｄＭａｉｌＦｒａｍｅにマッピングされることを認識している。
【０８９６】
【表１７３】
2005332380.tif 000183
【０８９７】
ＳｅｎｄＭａｉｌＦｒａｍｅに対するコンストラクタはないため、既定のコンストラクタが呼び出される。既定のコンストラクタは常に成功する。インタプリタは、「ｓｅｎｄ」に対する制約の解決を続ける。解決すべき第１の制約は、「ｓｅｎｄ」の目的語、この場合は「ｍａｉｌ」、を表す「ＤｏｎｅＴｏ」制約である。
【０８９８】
【表１７４】
2005332380.tif 000184
【０８９９】
コードに従って、ＤｏｎｅＴｏのスロット（領域特有の型を指示する）はＭａｉｌＥｎｔｉｔｙである。つまり、「ｓｅｎｄ」の目的語は、ＭａｉｌＥｎｔｉｔｙである必要があるということである。そこで、インタプリタは、ＭａｉｌＥｎｔｉｔｙを解決しようとする。
【０９００】
【表１７５】
2005332380.tif 000185
【０９０１】
他のオブジェクトと同様、インタプリタはコンストラクタを呼び出す。コンストラクタはないため、既定のコンストラクタが呼び出され、そして成功する。
【０９０２】
エンティティは、単語のリストで表されるという概念を持つ。この場合、インタプリタは、英語リストの中にＭａｉｌＥｎｔｉｔｙＷｏｒｄｓがないか見て、「ｍａｉｌ」がＭａｉｌＥｎｔｉｔｙの表記かどうかをチェックする。
【０９０３】
【表１７６】
2005332380.tif 000186
【０９０４】
これは、言語特有の詳細がコーディングされている場所である。インタプリタは、「ｍａｉｌ」がリスト内にあることを確認する。
【０９０５】
次に、インタプリタは、ＭａｉｌＥｎｔｉｔｙにおいてコーディングされている内容と突き合わせて「ｍａｉｌ」に対する制約を解決しようとする。この場合、「ａｂｏｕｔ  ｐａｃｋａｇｅ  ｔｏ  ｓｅａｔｔｌｅ  ｇｒｏｕｐ」は、実際の話題が「ｐａｃｋａｇｅ  ｔｏ  ｓｅａｔｔｌｅ  ｇｒｏｕｐ」であるＴｏｐｉｃ制約である。
【０９０６】
【表１７７】
2005332380.tif 000187
【０９０７】
インタプリタは、Ｔｏｐｉｃ制約のスロットと突き合わせて実際の話題を解決しようとする。「ｔｏｐｉｃ」スロットは、文字列であり、したがって、解決は必要ない。Ｔｏｐｉｃ節内のコードが実行される。
【０９０８】
【表１７８】
2005332380.tif 000188
【０９０９】
コードは、話題のテキストをメンバ変数ＭａｉｌＳｕｂｊｅｃｔに格納する。話題の実際のテキストは、言語オブジェクトモデル（ＬＯＭ）を介して取り出される。インタプリタは、現在、ＭａｉｌＥｎｔｉｔｙオブジェクトにより実行される。これは、コーディングされていないため、ＭａｉｌＥｎｔｉｔｙに対する既定のｓｕｃｃｅｓｓデストラクタを呼び出す。
【０９１０】
制御フローは、ＳｅｎｄＭａｉｌＦｒａｍｅに返され、そこで、コードがＤｏｎｅＴｏ節内で実行される。
【０９１１】
【表１７９】
2005332380.tif 000189
【０９１２】
このコードは、ＭａｉｌＥｎｔｉｔｙオブジェクトをメンバ変数に格納するだけである。｛注意：これは第２の解釈（後述）が始まる場所である｝インタプリタは、ＳｅｎｄＭａｉｌＦｒａｍｅオブジェクトの解決を終了しており、ｓｕｃｃｅｓｓデストラクタが提供されていないため既定のｓｕｃｃｅｓｓデストラクタを呼び出す。
【０９１３】
制御フローはＳｅｎｄＭａｉｌＣｏｍｍａｎｄに戻る。この時点で、インタプリタはｃｏｍｐｌｅｔｅコマンドの解決を完了している。ＳｅｎｄＭａｉｌＣｏｍｍａｎｄのｓｕｃｃｅｓｓデストラクタが呼び出される。
【０９１４】
【表１８０】
2005332380.tif 000190
【０９１５】
コードが実行され、ＳｅｎｄＭａｉｌＣｏｍｍａｎｄオブジェクトがアプリケーションに返される。
【０９１６】
解釈２
次に第２の可能な解釈を参照することにする。
【０９１７】
"send mail about package to seattle group"
「ｓｅｎｄ  ｍａｉｌ  ａｂｏｕｔ  ｐａｃｋａｇｅ」に対する解決ステップは、話題が「ｐａｃｋａｇｅ  ｔｏ  ｓｅａｔｔｌｅ  ｇｒｏｕｐ」ではなく「ｐａｃｋａｇｅ」であることを除き、上の標示部位までのとまったく同じである。
【０９１８】
インタプリタは、「ｔｏ  ｓｅａｔｔｌｅ  ｇｒｏｕｐ」が「ｓｅｎｄ」に対するＧｏａｌ制約であることを認識している。
【０９１９】
【表１８１】
2005332380.tif 000191
【０９２０】
このコードは、インタプリタが「ｓｅａｔｔｌｅ  ｇｒｏｕｐ」をＤＬＥｎｔｉｔｙと突き合わせて解決を試みるように、実際のゴールをＤＬＥｎｔｉｔｙとする必要があることを指示している。
【０９２１】
【表１８２】
2005332380.tif 000192
【０９２２】
インタプリタは、「ｇｒｏｕｐ」がＤＬＥｎｔｉｔｙの表記でなければならないことを認識している。これは表記リストＤＬＥｎｔｉｔｙＷｏｒｄｓをチェックする。
【０９２３】
【表１８３】
2005332380.tif 000193
【０９２４】
一致が見つかる。次に、インタプリタは、「ｓｅａｔｔｌｅ」をＮａｍｅｄ制約節と突き合わせて解決しようとする。Ｎａｍｅｄ制約のスロットは文字列なので、「ｓｅａｔｔｌｅ」はそれと突き合わせて解決する。Ｎａｍｅｄ制約節は成功し、その節内のコードが実行される。
【０９２５】
【表１８４】
2005332380.tif 000194
【０９２６】
コードは、「ｓｅａｔｔｌｅ」が有効な分配グループである場合のみ「ｔｒｕｅ」を返す。認識された分配グループでない場合、この節は「ｆａｌｓｅ」を返す。これは、領域特有の知識がＳＰＬインタプリタが返す解釈にどのような影響を及ぼすかを示す。「ｓｅａｔｔｌｅ」が分配グループでない場合、この解釈の解決は失敗し、最初の解釈のみが返される。
【０９２７】
インタプリタはコマンドの解決を完了する。「ｓｅａｔｔｌｅ」が認識された分配グループかどうかに応じて、ｓｕｃｃｅｓｓデストラクタまたはｆａｉｌｅｄデストラクタのいずれかが呼び出される。
【０９２８】
制御フローはＳｅｎｄＭａｉｌＦｒａｍｅに戻る。ＤＬＥｎｔｉｔｙの解決が失敗した場合、Ｇｏａｌ節内のコードは実行されず、ＳｅｎｄＭａｉｌＦｒａｍｅが解決に失敗する。そうでない場合、コードは実行され、解決は成功する。
【０９２９】
【表１８５】
2005332380.tif 000195
【０９３０】
制御フローは、ＳｅｎｄＭａｉｌＣｏｍｍａｎｄに戻り、ＳｅｎｄＭａｉｌＦｒａｍｅが成功したかどうかに応じて、ｓｕｃｃｅｓｓデストラクタが呼び出されるか、またはｆａｉｌｅｄデストラクタが呼び出される。
【０９３１】
【表１８６】
2005332380.tif 000196
【図面の簡単な説明】
【０９３２】
【図１】本発明の一実施形態が実装可能なコンピューティングシステム環境の概略図である。
【図２】本発明の一実施形態による自然言語システムの簡略化されたブロック図である。
【図３】言語オブジェクトモデルが点線で示されている図２の解析エンジンの簡略化されたブロック図である。
【図４】本発明の一実施形態によりメール送信コマンドを実行するプロセスの簡略化された流れ図である。
【図５】本発明の一実施形態による型解決の簡略化された流れ図である。
【図６】本発明の一実施形態によるコマンド解決の簡略化された流れ図である。
【図７】本発明の一実施形態によるフレーム解決の簡略化された流れ図である。
【図８】本発明の一実施形態による制約句解決の簡略化された流れ図である。
【図９】本発明の一実施形態によるエンティティ解決プロセスの簡略化された流れ図である。
【図１０】本発明の一実施形態による知能システムの簡略化されたブロック図である。
【図１１】本発明の一実施形態による語彙意味論構造の簡略化された概念ブロック図である。
【符号の説明】
【０９３３】
１３０  システムメモリ
１３４  オペレーティングシステム
１３５  アプリケーションプログラム
１３６  その他のプログラムモジュール
１３７  プログラムデータ
１４４  オペレーティングシステム
１４５  アプリケーションプログラム
１４６  その他のプログラムモジュール
１４７  プログラムデータ
１２０  処理ユニット
１９０  ビデオインターフェース
１９５  出力周辺機器インターフェース
１４０  取り外し不可能不揮発性メモリインターフェース
１５０  取り外し可能不揮発性メモリインターフェース
１６０  ユーザ入力インターフェース
１７０  ネットワークインターフェース
１９１  モニタ
１９６  プリンタ
１９７  スピーカ
１７１  ローカルエリアネットワーク
１７３  ワイドエリアネットワーク
１７２  モデム
１６２  キーボード
１６１  ポインティングデバイス
１６３  マイク
１８０  リモートコンピュータ
１８５  リモートアプリケーションプログラム
【図１】
2005332380.tif 000197
【図２】
2005332380.tif 000198
【図３】
2005332380.tif 000199
【図４】
2005332380.tif 000200
【図５】
2005332380.tif 000201
【図６】
2005332380.tif 000202
【図７】
2005332380.tif 000203
【図８】
2005332380.tif 000204
【図９】
2005332380.tif 000205
【図１０】
2005332380.tif 000206
【図１１】
2005332380.tif 000207
【外国語明細書】
2005332380000001.pdf