(57)【要約】【課題】システムの自然言語仕様から当該システム用のシステム・モデル化メタモデル言語モデルを自動的に抽出するための方法、装置及びソフトウェアを提供する。【解決手段】システムの自然言語仕様から、１セットの１つ以上の構文主語を表す、構文構造を抽出し、予定の１セットの構文主語とシステム・モデル化メタモデル言語用のそれぞれのメタモデル要素との間の、第１のマッピングを生成し、識別された各構文主語用のマッピングに従って、１つ以上のメタモデル要素を生成し、前記システムのモデルへの変換のために、生成されたメタモデル構造要素を提供する。【選択図】  図９
2010257452.tif 000002
【特許請求の範囲】
【請求項１】
システムの自然言語仕様から当該システム用のシステム・モデル化メタモデル言語モデルを自動的に抽出するための方法であって、
（ａ）前記自然言語仕様から、１セットの１つ以上の構文主語を表す、構文構造を抽出するステップと、
（ｂ）予定の１セットの前記構文主語とシステム・モデル化メタモデル言語用のそれぞれのメタモデル要素との間の、第１のマッピングを生成するステップと、
（ｃ）識別された各構文主語用の前記マッピングに従って、１つ以上の前記メタモデル要素を生成するステップと、
（ｄ）前記システムのモデルへの変換のために、前記生成されたメタモデル構造要素を提供するステップとを含む、方法。
【請求項２】
前記構文主語が名詞句を含み、前記第１のマッピングが、それぞれの前記名詞句をそれぞれの前記メタモデル構造要素にマップすることを含む、請求項１記載の方法。
【請求項３】
（ｅ）前記各構文主語に対応する１セットの１つ以上の構文述語を表す、他の構文構造を抽出するステップと、
（ｆ）予定の１セットの前記構文述語と前記メタモデル要素用のそれぞれのメタモデル関連との間の、第２のマッピングを生成するステップと、
（ｇ）前記抽出された構文構造内で識別される対応する任意の述語に従って、前記対応する各メタモデル構造要素用の１つ以上のメタモデル関係をそれぞれ生成するステップとをさらに含む、請求項１又は請求項２記載の方法。
【請求項４】
前記述語が名詞句を含む場合、当該名詞句が、前記第１のマッピングに従って、他のメタモデル構造要素にそれぞれマップされる、請求項３記載の方法。
【請求項５】
前記メタモデル構造要素がメタモデル・クラスである、請求項１ないし請求項４の何れか１項記載の方法。
【請求項６】
（ｈ）前記自然言語仕様から１つ以上の意味要素を抽出するステップをさらに含み、
所与の述語に関連する意味要素が、当該述語が受動態であることを表示する場合、当該述語からの動詞句が、前記対応する主語用の前記メタモデル構造要素と前記動詞句の対応する目的語用の前記メタモデル構造要素との間の、メタモデル指示としてマップされる、請求項３記載の方法。
【請求項７】
前記述語が能動態である場合、能動態である当該述語用の前記動詞句が、前記主語に対応する前記メタモデル構造要素用のメタモデル操作にマップされる、請求項６記載の方法。
【請求項８】
前記１つ以上の意味要素が、１つ以上の前記主語又は目的語に関連する１セットのオプショナル意味要素を含み、当該オプショナル意味要素が、前記対応するメタモデル構造要素の１つ以上の属性としてマップされる、請求項６又は請求項７記載の方法。
【請求項９】
共通の意味主題を識別するように配列された主題クラスタ・データが、前記オプショナル意味要素から決定され、前記システムの前記モデル内で前記共通の意味主題の識別を可能にするように、前記対応するメタモデル要素に変換される、請求項８記載の方法。
【請求項１０】
前記各構文構造要素又は関係に関連する表層構造要素が、前記対応するメタモデル要素又は関係用のラベルとして変換される、請求項１ないし請求項９の何れか１項記載の方法。
【請求項１１】
前記ステップ（ｈ）が、意味同義性を解決するための変動性レベリング・プロセスを含む、請求項６ないし請求項１０の何れか１項記載の方法。
【請求項１２】
前記モデルが統一モデル化言語（ＵＭＬ）を使用して生成される、請求項１ないし請求項１１の何れか１項記載の方法。
【請求項１３】
前記メタモデル言語がEcore である、請求項１ないし請求項１２の何れか１項記載の方法。
【請求項１４】
前記自然言語仕様が高水準機能仕様（ＨＬＦＳ）である、請求項１ないし請求項１３の何れか１項記載の方法。
【請求項１５】
システムの自然言語仕様から当該システム用のシステム・モデル化メタモデル言語モデルを自動的に抽出するための装置であって、
前記自然言語仕様から、１セットの１つ以上の構文主語を表す、構文構造を抽出し、
予定の１セットの前記構文主語とシステム・モデル化メタモデル言語用のそれぞれのメタモデル要素との間の、第１のマッピングを生成し、
識別された各構文主語用の前記マッピングに従って、１つ以上の前記メタモデル要素を生成し、
前記システムのモデルへの変換のために、前記生成されたメタモデル構造要素を提供するように動作する、装置。
【請求項１６】
前記構文主語が名詞句を含み、前記第１のマッピングが、それぞれの前記名詞句をそれぞれの前記メタモデル構造要素にマップすることを含む、請求項１５記載の装置。
【請求項１７】
前記各構文主語に対応する１つ以上の構文述語を表す、他の構文構造を抽出し、
予定の１セットの前記構文述語と前記メタモデル要素用のそれぞれのメタモデル関連との間の、第２のマッピングを生成し、
前記抽出された構文構造内で識別される対応する任意の述語に従って、前記対応する各メタモデル構造要素用の１つ以上のメタモデル関係をそれぞれ生成するようにさらに動作する、請求項１５又は請求項１６記載の装置。
【請求項１８】
前記述語が名詞句を含む場合、当該名詞句が、前記第１のマッピングに従って、他のメタモデル構造要素にそれぞれマップされる、請求項１７記載の装置。
【請求項１９】
前記メタモデル構造要素がメタモデル・クラスである、請求項１５ないし請求項１８の何れか１項記載の装置。
【請求項２０】
前記自然言語仕様から１つ以上の意味要素を抽出するようにさらに動作し、
所与の述語に関連する意味要素が、当該述語が受動態であることを表示する場合、当該述語からの動詞句が、前記対応する主語用の前記メタモデル構造要素と前記動詞句の対応する目的語用の前記メタモデル構造要素との間の、メタモデル指示としてマップされる、請求項１７記載の装置。
【請求項２１】
前記述語が能動態である場合、能動態である当該述語用の前記動詞句が、前記主語に対応する前記メタモデル構造要素用のメタモデル操作にマップされる、請求項２０記載の装置。
【請求項２２】
前記１つ以上の意味要素が、１つ以上の前記主語又は目的語に関連する１セットのオプショナル意味要素を含み、当該オプショナル意味要素が、前記対応するメタモデル構造要素の１つ以上の属性としてマップされる、請求項２０又は請求項２１記載の装置。
【請求項２３】
共通の意味主題を識別するように配列された主題クラスタ・データが、前記オプショナル意味要素から決定され、前記システムの前記モデル内で前記共通の意味主題の識別を可能にするように、前記対応するメタモデル要素に変換される、請求項２２記載の装置。
【請求項２４】
前記各構文構造要素又は関係に関連する表層構造要素が、前記対応するメタモデル要素又は関係用のラベルとして変換される、請求項１５ないし請求項２３の何れか１項記載の装置。
【請求項２５】
前記意味要素を抽出する動作が、意味同義性を解決するための変動性レベリング・プロセスを含む、請求項２０ないし請求項２４の何れか１項記載の装置。
【請求項２６】
前記モデルが統一モデル化言語（ＵＭＬ）を使用して生成される、請求項１５ないし請求項２５の何れか１項記載の装置。
【請求項２７】
前記メタモデル言語がEcore である、請求項１５ないし請求項２６の何れか１項記載の装置。
【請求項２８】
前記自然言語仕様が高水準機能仕様（ＨＬＦＳ）である、請求項１５ないし請求項２７の何れか１項記載の装置。
【請求項２９】
請求項１ないし請求項１４の何れか１項記載の方法の各ステップをコンピュータに実行させるためのコンピュータ・プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、システムの自然言語仕様から当該システム用のシステム・モデル化メタモデル言語モデル（system modelling meta-modellanguage model）を自動的に抽出するための方法、装置及びコンピュータ・プログラムに係る。
【背景技術】
【０００２】
ソフトウェア・システムのような複雑なシステムを設計する場合、当該システムは、自然言語機能仕様で定義されるのが普通である。かかる機能仕様に従ってシステムを生成する場合の重要な準備段階は、当該システムのモデルを生成することである。かかるモデルを生成するためには、所与のモデル化仕様言語又はメタモデル言語における当該システムのモデルに変換する前に、最初に、機能仕様をドメイン・エキスパートによって解釈及び要約しなければならない。一旦メタモデル言語モデルが生成されると、これを、前記機能仕様によって定義された概念及び振る舞いをカプセル化する、他のモデルにさらに変換することができる。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
機能仕様からモデルを生成するために、半自動システムが提供される。しかし、かかるシステムは、当該機能仕様を特定のマークアップ言語で生成することを必要とするのが普通である。言いかえれば、当該機能仕様は、目標とするモデル要素又は振る舞いを表示するために、明示的なマーキングを含んでいなければならない。
【０００４】
多くの場合、各段階において、それぞれ適切で且つ異なるスキル・セットを有するヒューマン・エージェントが使用される。さらに、機能仕様は、本来、熟練したシステム開発者による直接の解釈のために書かれており、当該仕様自体からモデルを生成するための機構を提供しない。
【課題を解決するための手段】
【０００５】
本発明の第１の側面は、システムの自然言語仕様から当該システム用のシステム・モデル化メタモデル言語モデルを自動的に抽出するための方法に向けられている。この方法は、
（ａ）前記自然言語仕様から、１セットの１つ以上の構文主語（syntactic subject）を表す、構文構造（syntactic structure）を抽出するステップと、
（ｂ）予定の１セットの前記構文主語とシステム・モデル化メタモデル言語用のそれぞれのメタモデル要素との間の、第１のマッピングを生成するステップと、
（ｃ）識別された各構文主語用の前記マッピングに従って、１つ以上の前記メタモデル要素を生成するステップと、
（ｄ）前記システムのモデルへの変換のために、前記生成されたメタモデル構造要素を提供するステップとを含む。
【０００６】
前記構文主語は名詞句（noun phrase）を含み、前記第１のマッピングは、それぞれの前記名詞句をそれぞれの前記メタモデル構造要素にマップすることを含む。この方法は、
（ｅ）各構文主語に対応する１セットの１つ以上の構文述語（syntactic predicate）を表す、他の構文構造を抽出するステップと、
（ｆ）予定の１セットの前記構文述語と前記メタモデル要素用のそれぞれのメタモデル関連（meta-model association）との間の、第２のマッピングを生成するステップと、
（ｇ）前記抽出された構文構造内で識別される対応する任意の述語に従って、対応する各メタモデル構造要素用の１つ以上のメタモデル関係（meta-model relation）をそれぞれ生成するステップとをさらに含む。
前記述語が名詞句を含む場合、当該名詞句は、前記第１のマッピングに従って、他のメタモデル構造要素にそれぞれマップされる。前記メタモデル構造要素は、メタモデル・クラスである。
【０００７】
この方法は、
（ｈ）前記自然言語仕様から１つ以上の意味要素（semantic element）を抽出するステップをさらに含む。
所与の述語に関連する意味要素が、当該述語が受動態（passive）であることを表示する場合、当該述語からの動詞句（verb phrase）は、前記対応する主語用の前記メタモデル構造要素と前記動詞句の対応する目的語（object）用の前記メタモデル構造要素との間の、メタモデル指示（meta-model reference）としてマップされる。前記述語が能動態（active）である場合、能動態である当該述語用の前記動詞句は、前記主語に対応する前記メタモデル構造要素用のメタモデル操作（meta-model operation）にマップされる。前記１つ以上の意味要素は、１つ以上の前記主語又は目的語に関連する１セットのオプショナル意味要素を含み、当該オプショナル意味要素は、前記対応するメタモデル構造要素の１つ以上の属性としてマップされる。
【０００８】
共通の意味主題（semantic theme）を識別するように配列された主題クラスタ・データは、前記オプショナル意味要素から決定され、前記システムの前記モデル内で前記共通の意味主題の識別を可能にするように、前記対応するメタモデル要素に変換される。各構文構造要素又は関係に関連する表層構造（surface structure）要素は、前記対応するメタモデル要素又は関係用のラベルとして変換される。前記ステップ（ｈ）は、意味同義性（semantic synonymy）を解決するための変動性レベリング（variability levelling）・プロセスを含む。前記モデルは、統一モデル化言語（ＵＭＬ）を使用して生成される。前記メタモデル言語は、Ecore（商標）である。前記自然言語仕様は、高水準機能仕様（ＨＬＦＳ）である。
【０００９】
本発明の第２の側面は、システムの自然言語仕様から当該システム用のシステム・モデル化メタモデル言語モデルを自動的に抽出するための装置に向けられている。この装置は、
前記自然言語仕様から、１セットの１つ以上の構文主語を表す、構文構造を抽出し、
予定の１セットの前記構文主語とシステム・モデル化メタモデル言語用のそれぞれのメタモデル要素との間の、第１のマッピングを生成し、
識別された各構文主語用の前記マッピングに従って、１つ以上の前記メタモデル要素を生成し、
前記システムのモデルへの変換のために、前記生成されたメタモデル構造要素を提供するように動作する。
【００１０】
本発明の第３の側面は、前記第1の側面に従った方法の各ステップをコンピュータに実行させるためのコンピュータ・プログラムに向けられている。
【発明の効果】
【００１１】
本発明は、システムの自然言語仕様から当該システム用のシステム・モデル化メタモデル言語モデルを自動的に抽出することができるという効果を奏する。
【図面の簡単な説明】
【００１２】
【図１】モデル化アプリケーション・プログラムによって提供される、モデル化システムを提供するコンピュータ・システムを示す概略図である。
【図２】図１のモデル化アプリケーション・プログラムのコンポーネントを示す概略図である。
【図３】図２のモデル化アプリケーション・プログラムの自然言語処理モジュールを示す概略図である。
【図４】図２のモデル化アプリケーション・プログラムによって処理するための自然言語機能仕様のサンプルである。
【図５】図４の自然言語機能仕様の第１文について、図３の自然言語処理モジュールによって図４の自然言語機能仕様から抽出されるオントロジ（ontology）である。
【図６】図２のモデル化アプリケーション・プログラム内で使用されるマッピング・テーブルである。
【図７】図４のマッピング・テーブルに従って、図５のオントロジから生成されるメタモデル言語モデルである。
【図８】図７のメタモデル言語モデルから生成されるＵＭＬモデルである。
【図９】図５のオントロジを抽出するときに、図３の自然言語処理モジュールによって行われる処理を示すフローチャートである。
【図１０】図５のオントロジからメタモデル言語モデルを生成するときに、図２のモデル化アプリケーション・プログラムによって行われる処理を示すフローチャートである。
【発明を実施するための形態】
【００１３】
図１を参照して説明する。コンピュータ・システム１０１は、オペレーティング・システム１０３を搭載したコンピュータ１０２を含む。オペレーティング・システム１０３は、アプリケーション・プログラム用のプラットフォームを、モデル化アプリケーション・プログラム１０４の形式で提供する。モデル化アプリケーション・プログラム１０４は、システム用の機能仕様（ＦＳ）１０５のような自然言語仕様を入力し且つＦＳ １０５内で統一モデル化言語（ＵＭＬ）モデル１０６の形式で記述される当該システムの概念モデルを生成するように編成される。
【００１４】
図２を参照して説明する。モデル化アプリケーション・プログラムは、３つの主要コンポーネントとして、自然言語処理（ＮＬＰ）モジュール２０１、マッピング・モジュール２０２及びモデル生成モジュール２０３を含む。ＮＬＰモジュール２０１は、自然言語のＦＳ １０５を入力し、ＦＳ １０５から構文及び意味データを抽出し、当該抽出されたデータをＦＳ １０５用のオントロジ２０４の形式で出力するように編成される。ＮＬＰモジュール２０１が行う処理については、以下で詳述する。オントロジ２０４は、マッピング・モジュール２０２に入力される。マッピング・モジュール２０２は、オントロジ２０４の諸要素を出力ＵＭＬモデル１０６用のメタモデル言語にマップする。実施形態では、メタモデル言語は、Ecore（商標）（Eclipse Foundation, Inc.によって提供される Eclipse（商標）プラットフォームの一部）である。
【００１５】
マッピング・モジュール２０２によるマッピングは、マッピング・テーブル２０５に従って行われる。マッピング・テーブル２０５は、オントロジ２０４の予定の１セットの構文及び意味要素と、メタモデル言語における構造要素及び関係との間のマッピングを提供する。マッピング・モジュール２０２の出力は、メタモデル言語（ＭＭＬ）で定義されたＦＳ １０５からの概念のＭＭＬモデル２０６である。ＭＭＬモデル２０６は、モデル生成モジュール２０３に入力され、そこでＦＳ １０５からの機能的概念のＵＭＬモデルに変換される。次に、ＵＭＬモデル１０６は、ＦＳ １０５によって定義されたシステムの手動又は自動生成のために使用することができる。例えば、ＦＳ １０５がソフトウェア・システムを記述すれば、ＵＭＬモデルは、当該定義されたソフトウェア・システムの自動生成のために使用することができる。
【００１６】
図３を参照して説明する。実施形態では、ＮＬＰモジュール２０１は、テキスト標準化（normalisation）モジュール３０１、１次意味パーサ３０２、構造パーサ３０３、２次意味パーサ３０４及び主題クラスタリング・モジュール３０５を含む。これらのモジュール３０１〜３０５は、連携して動作することにより、ＦＳ １０５からオントロジ２０４のそれぞれのアスペクトを抽出する。テキスト標準化モジュール３０１は、ＦＳ １０５からテキスト効果（大文字、強調又はイタリック体等）を除去し、略語及び頭字語を拡張することにより、ＦＳ １０５をプレーン・テキスト３０６に変換するように編成される。テキスト標準化モジュール３０１は、１セットの規則３０７に従ってこの変換を行う。これらの規則３０７は、識別する必要のあるテキスト効果を定義し且つかかる素性（feature）をプレーン・テキストに変換するためのプロセスを定義する。
【００１７】
次に、プレーン・テキスト形式のＦＳ １０５が、１次意味パーサ３０２に入力される。これに応答して、１次意味パーサ３０２は、辞書（lexicon）３０８を使用することにより、意味修飾語句（semantic qualifier）又は属性の形式を有する各単語用の関連性のある（relevant）意味を識別する。プレーン・テキスト形式のＦＳ １０５内の各単語は、関連性のある前記識別済みの意味修飾語句及び属性を含む、１つ以上のタグで増補される。辞書３０８は、全ての単語タイプ（名詞、動詞、形容詞及び副詞等）の意味解釈に関連性のある情報を保持する。例えば、辞書３０８は、行為（action）及び結果の形式を有する或る活動（activity）を暗示する動詞と、状態又は所有を表示する動詞とを区別するように編成される。従って、１次意味パーサ３０２は、動態動詞（結果（effective）動詞ともいう）を識別し且つこれらの動態動詞を状態動詞から区別するように編成される。言いかえれば、それぞれの名詞に関連する属性として扱われる修飾動詞（「to be」、「contain」、「involve」、「imply」等）は、他の概念に影響することがある他の動詞（「to send」、「to receive」、「to modify」等）から区別される。例えば、次の２つの句が与えられるものとする。
「The first componentcomprises four features.」
「The first componentwill contact the database.」
【００１８】
動詞「comprise」が包含関係を示唆するのに対し、「contact」は操作又は活動を示唆する。従って、１次意味パーサ３０２の出力３０９は、辞書３０８に従ってその意味がタグ付けされた各単語を有する、プレーン・テキスト形式のＦＳ １０５である。次に、意味論的にタグ付けされたプレーン・テキスト形式のＦＳ ３０９は、構造パーサ３０３に入力される。
【００１９】
構造パーサ３０３は、１セットの文法規則として定義された文法３１０に関して、その入力の構文構造及び関係を解析するように編成される。従って、構造パーサ３０３は、各単語の構文機能を識別することに加えて、所与の単語と句との間に存在することがある構文関係及び関連を識別する。例えば、文法３１０は、或る行為の開始者（initiator）及び受容者（recipient）を識別し且つ当該行為の意図される任意の目標又は結果を識別するように、諸行為を解析するための諸規則を提供する。ＦＳ １０５内に次の句が与えられるものとする。
「The process involves three components.」
【００２０】
前記文法規則は、次の中括弧内に示される、構文構造を識別するように編成される。
{DEFINITE ARTICLE} the
{NOUN} {SUBJECT} process
{VERB} {3rd PERSON SINGULAR} involves
{NUMERICAL QUALIFIER} {CARDINAL}three
{NOUN} {OBJECT} components
【００２１】
例えば、前記文法規則は、構文構造（名詞句、動詞句等）を識別するとともに、諸コンポーネント及び他の構文要素（名詞、動詞、主語、動詞の目的語、修飾語（qualifier）等）を識別する。また、実施形態では、構文解析は、所与の文の構文要素を一のトピック（topic）及び関係するコメント（comment）に分割する。前述の例の場合がそうであるように、トピックは、文又は構文主語と同じであり、コメントは、文又は構文述語と同じであるのが普通である（以下を参照）。
Topic:
{DEFINITE ARTICLE} the
{NOUN} {SUBJECT} process
Comment:
{VERB} {3rd PERSON SINGULAR} involves
{NUMERICAL QUALIFIER} {CARDINAL}three
{NOUN} {OBJECT} components
【００２２】
他の例では、トピックは、文の述語と同じであり、コメントは、その主語と同じであることがある。
【００２３】
また、前記文法規則は、諸要素間の種々のタイプの関連（包含（containment）、一般化（generalisation）又は要件（requirement）関係等）を識別する。包含関係は、１つのエンティティが、他の１つ以上のエンティティを含むことを表示する。一般化関係は、所与のエンティティが、共通の属性を有する１エンティティ・グループの１例であることを表示する。要件関係は、一のエンティティが、他のエンティティの必要とされる１部分であることを表示する。前述の例から、前記文法規則は、「three components」が「process」と包含関係を有し、それとは逆に、「components」が「process」と要件関係を有することを識別するであろう。これらの関係は、次のように表すことができる。
component {CONTAINMENT} process;
process {REQUIREMENT} component
【００２４】
前述のように、前記文法規則は、所与の行為の開始者及び受容者を識別し且つ当該行為の任意の目的を識別するように編成される。ＦＳ １０５内に次の句が与えられるものとする。
「The first componentmust send requests to the second for
monitoring data.」
【００２５】
前記文法規則は、「firstcomponent」（component1）が、パラメータ（monitoring data）を以て、「second component」（component２）に対する行為（send request）を開始することを識別するように編成される。その結果、２つの「component」と「monitoring data」との間の関係が識別され且つ「monitoring data」という目的語を含む２つの「component」の間の行為が識別される。この文法の関係は、次のように表すことができる。
Send request {INITIATOR} component1;
Send request {OBJECTIVE} monitoring data;
Send request {RECIPIENT} component2
【００２６】
従って、構造パーサ３０３の出力３１１は、適切なタグによって識別された構文構造、諸要素及び諸関係を有する、ＦＳ １０５の内容の表現を含む。
【００２７】
構造パーサ３０３からの出力３１１は、２次意味パーサ３０４に入力される。２次意味パーサ３０４は、１セットの規則３１２に従って、前方照応的指示（anaphoric reference）を識別した後、直示的拡張（deictic expansion）を行うことにより、斜格型の非自明的指示（oblique, non self-explanatory reference）を解決するように編成される。例えば、記述型及び宣言型テキストは、次の例に示すように、代名詞又は修飾語のような構文機構を使用することにより、反復を回避するのが普通である。
「The process involves three components. It uses these to check
integrity. Each of them in turn comprisesfour sub-components.」
【００２８】
２次意味パーサ３０４は、代名詞「it」、「these」及び「them」の使用を識別し且つこれらの代名詞をそれぞれの適切な名詞句に変更又は拡張するように編成される。前述の例では、適切な規則３１２に従って、「it」は「the process」に変更され、「these」及び「them」は「the three components」に変更される。
【００２９】
さらに、２次意味パーサ３０４は、言語処理中に通常行われる以上の、追加のサブプロセスを行うように編成される。一般に、自然言語は、完全又は部分的な同義性を使用する。その場合、文体の理由で、共通の又は部分的に共通する一の目的語を指すために、多数の異なる名詞句が使用されることがある。言いかえれば、異なる語彙（lexical）項目が使用されているために、意味の部分的又は完全なオーバーラップが生じることになる。変動性レベリングは、かかる同義性を解決するためのプロセスである。次の例を参照されたい。
「There are three components for software, hardware and interface
management. These modules fulfil the following functions.」
【００３０】
前記の用語「component」、「software (management)」、「interface (management)」及び「modules」は、同じ概念を指す。さらに、「component」と、「software」、「hardware」及び「interface management」との間の関係は、明らかである。
【００３１】
しかし、最初に明らかでないことは、これらの要素がコンポーネントのサブタイプであるか又はシステム自体のコンポーネントであるか、ということである。２次意味パーサ３０４によって行われる変動性レベリング・プロセスは、ＦＳ １０５の全体を参照して、この曖昧さを解決するように編成される。最初に、２次意味パーサ３０４は、全ての名詞句（component、software management、hardware management 及び interface management）を保存する。もし、文書の終わりまでに、「component」が他の概念に関連しなければ、「component」は可能な削除のためにフラグ付けされる。次に、残りの名詞句（software management、hardware management 及び interface management）は、これらの名詞句が関連する任意の用語（例えば、これらの名詞句が保持する素性、又はこれらの名詞句が行う操作）を共有するか否かを確立するように処理される。もし、これらの名詞句がかかる任意の素性又は操作を共有すれば、これらの名詞句は、総称用語「component」に関連し、当該総称用語のサブタイプとしてマークされる。そうでなければ、抑制のために既にフラグ付けされていた総称用語「component」が除去される。従って、２次意味パーサ３０４の出力３１３は、拡張された前方照応的指示及び直示的指示を含み、変動性レベリングで同義性を解決している。
【００３２】
ＮＬＰモジュール２０１の最終段階である主題クラスタリング・モジュール３０５は、先行する段階の累積的な出力を取るように編成される。１次意味パーサ３０２によって追加された意味タグを使用して、共通の意味主題がオントロジ２０４の用語で識別され、かかる識別された各グループを識別するように主題識別子でタグ付けされる。主題クラスタリングは、１セットの規則３１４に従って行われる。主題クラスタリング・モジュール３０５の出力３１５は、識別された各主題に共通する用語を一意的に識別するオントロジの用語に関連する、１セットのタグである。
【００３３】
図４は、ＮＬＰモジュール２０１に入力するのに適した、コンピュータ化された予約システム用のＦＳ １０５のうち最初の３パラグラフを例示する。図５は、図４に太字で示されているＦＳ １０５の第１文について抽出されたオントロジ２０４を示す。オントロジ２０４は、階層的に配列された１セットの構文要素を含む。各構文要素は、角括弧（＜構文ラベル＞）内に囲まれた構文ラベルの形式を有する構文開始及び終了ラベルと、当該構文ラベルに先行するスラッシュを囲む角括弧（＜／構文ラベル＞）との間にそれぞれ囲まれている。階層は、１次的に、トピック及びコメント・セクションに分割される。例えば、これらのセクションは、文の主語及び述語と同じである。各１次区分内では、他の構文要素（例えば、名詞句、動詞句、前置詞句（prepositional phrase）及びそれらの構文コンポーネント）が、文法３１０に従って階層的に配列され、ラベル付けされる。表層構造、すなわち、ＦＳ １０５からの単語それ自体は、それぞれの構文ラベルに隣接する太字によって表される。適用可能な場合、辞書３０８に従って１次意味パーサ３０２によって挿入された意味タグは、それぞれの表層構造に続き、中括弧（｛｝）で表される。図５では、名詞コンポーネントは、属性（すなわち、関係する用語又は特性）に関連する。プログラミング用語では、これらは、関数又はメソッド呼び出しのパラメータと同じである。テキスト解析では、これらは、機能仕様の他のセクション又は辞書３０８に提供された意味定義における、主要部名詞（head noun）それ自体を記述するか又は拡張するために一般に使用される名詞である。図５のオントロジについては、マークアップ言語用の通常のプラクティスに従って、属性が名詞タグ内にリストされる。
【００３４】
前述のように、マッピング・モジュール２０２は、マッピング・テーブル２０５に従って、抽出されたオントロジ２０４からの要素をＭＭＬモデル２０６にマップするように編成される。図６は、マッピング・テーブル２０５を例示する。実施形態では、マッピング・テーブル２０５は、オントロジ２０４からの英語の自然言語要素を、Ecore（商標）概念の形式を有するメタモデル言語（ＭＭＬ）にマップするように編成される。識別された各名詞又は各名詞句は、（ＵＭＬクラスと等価の）EClass にマップされる。所与の名詞又は名詞句用の任意の意味修飾語句、素性、補語（complement）は、（ＵＭＬ属性と等価の）EAttribute として適切な EClass に追加される。識別された各動詞又は各動詞句（その関連する意味において受動態として定義される）は、構文において定義されるような当該動詞の主語及び目的語用に生成された、関連性のあるクラスの間の EReference としてマップされる。同様に、意味タグによって識別された包含、要件及び一般化（{Is_Type}）関係は、関連性のある EClass の間の EReference として追加される。前述の例における包含／要件についてさらに説明すると、関連性のある両方の名詞は、次のように EClass にマップされる。
EClass: process
EClass: component
【００３５】
次に、この包含／要件関係は、これらの２つの EClass の間の EReference として、次のようにマップされるであろう。
EClass: process
EReference: type: componentiscontainment = yes
EClass: component
EReference:type: process iscontainment = no
【００３６】
動詞又は動詞句がその関連する意味において  能動態で且つ結果であるとして定義されている場合、当該動詞又は動詞句は、関連性のある EClass 用の EOperation にマップされる。表層構造、すなわち、実際のＦＳ １０５の単語は、関連性のある Ecore（商標）構造用の EName として使用される。要約すると、実施形態では、名詞句は、EClass にマップされ、自動詞／受動態動詞句は、EReference にマップされ、結果を生成する他動詞は、当該行為の開始者であると意味的に識別される EClass 用の EOperation にマップされる。包含、要件及び一般化関係は、適切な方向性の EReference にマップされる。この方向性（directionality）は、関連する意味から決定される。
【００３７】
図７のＭＭＬモデル２０６は、図４のＦＳ １０５のサンプル全体について生成され且つ生成済みの Ecore（商標）構造を記述する。このＭＭＬモデルは、ＵＭＬモデル図を生成するように手動的に処理することができる。実施形態では、ＭＭＬモデル２０６は、ＵＭＬモデル１０６への自動変換のために、モデル生成モジュール２０３に渡される。図８は、図７のＭＭＬモデル２０６からＦＳ １０５用に生成されたＵＭＬモデル１０６を示す。このＵＭＬモデルは、名詞句「booking (system)」から生成された第１クラス８０１と、名詞句「order entry」から生成された第２クラス８０２とを含む。クラス８０１及び８０２の間の関係８０３は、動詞句「is accessed」から生じる関連を含む。クラス８０１及び８０２の各々は、オントロジ２０４内のそれぞれの名詞句からの関連性のある属性を追加される。従って、最初の２クラス８０１、８０２及びそれらの関係は、ＦＳ １０５の第１文から導出され、図５の抽出されたオントロジ２０４に対応する。ＦＳ １０５の残りの文を解析すると、「Passenger」クラス８０４、「Individual」クラス８０５及び「Party」クラス８０６の形式を有する、３クラスがさらに生成される。「Passenger」クラス８０４は、「Booking」クラス８０１に関連する。「Individual」クラス８０５及び「Party」クラス８０６は、「Passenger」クラス８０４への一般化として識別される。クラス８０１、８０２、８０４、８０５及び８０６の各々は、多数の属性８０７を含む。さらに、「Booking」クラス８０１及び「Passenger」クラス８０４の各々は、それぞれの操作８０８及び８０９を含む。例えば、「cancel」及び「confirm」操作８０８は、図４に示されたＦＳ１０５の第２パラグラフの第２文における対応する他動詞から導出される。
【００３８】
図９のフローチャートを参照して、ＮＬＰモジュール２０１によって行われる処理を説明する。ステップ９０１で、モデル化アプリケーション・プログラム１０４の始動に応答して処理が開始され、ステップ９０２に移る。ステップ９０２で、ＦＳ １０５が入力され、処理がステップ９０３に移る。ステップ９０３で、前述のように、ＦＳ １０５のテキストが標準化され、処理がステップ９０４に移る。ステップ９０４で、辞書３０８に従って、ＦＳ １０５の１次意味解析を行うことにより、関連性のある意味タグが追加される。ＦＳ １０５の第１文に関するこの処理ステップの結果は、次の通りである。
The // +{DEFINITE}+{UNKNOWN ANTECEDENT}
booking system // +{ADMIN}+{AUTOMATION}+{SALES}
is // +{TO BE}+{PASSIVE}
accessed // +{ENTRY}+{RECIPIENT}
via // +{MEANS}+{OBJECT}
the // +{DEFINITE}+{UNKNOWN ANTECEDENT}
order // +{SALES}+{RECORD}
entry // +{ENTRY}+{RECIPIENT}
application // +{MEANS}+{AGENT}
【００３９】
処理はステップ９０４からステップ９０５に移り、そこで文法３１０に従って、構造解析が行われる。その結果、ＦＳ １０５の語彙項目にタグが付けられ、そして次のように任意の内部関連が識別される。
TOPIC ( NP ({DEF ARTICLE} (the) {COMPOUNDNOUN} (booking system) )
COMMENT ( VP ( V {PASSIVE} (is accessed PP ({PREPOSITION} via
{DEFINITE ARTICLE} (the) {COMPOUND NOUN} (order entry application) ) )
ASSOCIATION: “booking system” <> “order entry application”
“booking system” {RECIPIENT} “order entry application”
“order entry application” {AGENT} “booking system”
【００４０】
次に、処理はステップ９０６に移り、そこで規則３１２に従って、２次意味パーサ３０４によって２次意味解析が行われる。その結果、前方照応的指示及び直示的指示が拡張され、変動性レベリングのために同義性が解決される。ＦＳ １０５の第１パラグラフにおける直示的指示、並びにＦＳ １０５の第１及び第２パラグラフにおける同義性の解決の例は、次の通りである。
the -> 指示対象“booking system”
this -> 指示対象“order entry application”
information -> 指示対象“the destination”+“the price”+
“special conditions”
【００４１】
次に、処理はステップ９０７に移り、そこで１次意味パーサ３０２によって挿入された意味タグが解析され、その結果、新たなオントロジ２０４における用語の間の共通する任意の意味主題が識別され、そしてかかる識別された主題が、次に示すように、関連又は意味包含関係としてラベル付けされる。
<[booking system] associatedwith [order entry application]>
<[booking system] details contained [{date, number of passengers, whether paid}]>
【００４２】
前述の例において、「details contained」関連が識別する素性は、それぞれの主要部名詞，すなわち「booking system」の属性、又は当該主要部名詞からの包含関係を有する別個のクラスの何れかとして解釈することができる。後述するように、マッピング・モジュール２０２は、この意味クラスタリング・データを使用することにより、任意の「details contained」エントリがオントロジ内の他の任意の目的語に関連するか否かを決定するように編成される。そうであれば、これらは、それ自体でクラスとしてモデル化される。もし、或るエントリが他の関連を全く有していなければ、当該エントリは、それぞれの主要部名詞クラスの属性になるであろう。次に、処理はステップ９０８に移り、そこで抽出されたオントロジが、さらなる処理のためにマッピング・モジュール２０２に渡される。その後、処理はステップ９０９で終了する。
【００４３】
図１０のフローチャートを参照して、受け取られたオントロジ２０４をＭＭＬモデル２０６にマップするときに、マッピング・モジュール２０２によって行われる処理を説明する。ステップ１００１で、モデル化アプリケーション・プログラム１０４の始動に応答して処理が開始され、ステップ１００２に移る。ステップ１００２で、オントロジ２０４が入力され、処理はステップ１００３に移る。ステップ１００３で、オントロジ内の各名詞句が識別され、処理はステップ１００４に移る。ステップ１００４で、識別された名詞句ごとに対応する EClass が生成され、処理はステップ１００５に移る。ステップ１００５で、マッピング・テーブル２０５に従って、オントロジから新しい各 EClass 用の関連性のある素性が識別される。さらに、マッピング・モジュール２０２は、意味クラスタリング・データを使用することにより、「details contained」エントリのうちの任意のエントリがオントロジ内の他の任意の目的語に関連するか否かを決定するように編成される。そうであれば、関連性のある詳細エントリ用の新しいクラスがその関連するクラスとの包含関係と共に生成される。もし、或る詳細エントリが他の関連を全く有していなければ、当該エントリは、その関連するクラス用の属性として提供される。次に、処理はステップ１００６に移り、そこで新しい各 EClass が識別された素性を追加され、処理はステップ１００７に移る。
【００４４】
ステップ１００７で、マッピング・テーブル２０５に従って、生成された EClass に関連性のあるオントロジ２０４内の他の任意の関係（例えば、動詞句）が識別される。マッピング・テーブル２０５に従って識別され且つ所与の各関係の指定された意味によって決定されるような関係用の関連性のある EClass について、EReference 又は EOperation が生成される。次に、処理はステップ１００８に移り、そこでオントロジ２０４内の任意の意味主題クラスタが識別され、処理はステップ１００９に移る。ステップ１００９で、識別された意味クラスタは、関連性のある EClass を適切な識別子でタグ付けすることにより、ＭＭＬモデル２０６に変換される。図７は、図５の抽出されたオントロジ２０４について生成された、ＭＭＬモデル２０６を示す。次に、処理はステップ１０１０に移り、そこでＭＭＬモデル２０６は、関連性のあるＵＭＬモデル１０６への変換のために、モデル生成モジュール２０３に渡される。図８は、図５の抽出されたオントロジ２０４について生成された、ＵＭＬモデル１０５の一部を示す。その後、処理はステップ１０１１で終了する。
【００４５】
当業者には明らかなように、自然言語テキストから抽出されたオントロジ・データは、ＮＬＰモジュールによって使用される辞書、文法及び他の規則によって決定される。かかるオントロジ・データは、特定のアプリケーションに適するように、これを修正することができる。自然言語から異なるデータのセットを抽出し、これをモデル化アプリケーション・プログラムによって使用するためのオントロジ内に提供することができる。所与のオントロジ内で識別される全ての素性が、ＭＭＬモデルにマップされるとは限らない。
【００４６】
当業者には明らかなように、本発明の一部又は全てを具体化する装置は、本発明の実施形態の一部又は全てを提供するように編成されたソフトウェアを有する、汎用装置とすることができる。この装置は、単一の装置又は１グループの装置とすることができ、ソフトウェアは、単一のプログラム又は１セットのプログラムとすることができる。さらに、本発明を実装するために使用されるソフトウェアの一部又は全ては、当該ソフトウェアを１つ以上の装置にロードすることができるように、適切な任意の伝送又はストレージ手段によって通信することができる。
【００４７】
本発明は、その実施形態の詳細な説明によって開示されているが、そのことは、如何なる意味においても請求項に係る発明の範囲をかかる詳細事項に限定することを意図するものではない。追加の利点及び修正が、当業者には明らかであろう。従って、本発明は、そのより広い側面において、添付図面に示し且つ以上で説明した特定の詳細事項、代表的な装置及び方法、並びに説明上の具体例に限定されない。従って、本発明の一般的な発明概念の精神又は範囲から逸脱することなく、かかる詳細事項から逸脱することができる。
【符号の説明】
【００４８】
１０１・・・コンピュータ・システム
１０２・・・コンピュータ
１０３・・・オペレーティング・システム
１０４・・・モデル化アプリケーション・プログラム
１０５・・・機能仕様（ＦＳ）
１０６・・・統一モデル化言語（ＵＭＬ）モデル
２０１・・・自然言語処理（ＮＬＰ）モジュール
２０２・・・マッピング・モジュール
２０３・・・モデル生成モジュール
２０４・・・オントロジ
２０５・・・マッピング・テーブル
２０６・・・メタモデル言語（ＭＭＬ）モデル
３０１・・・テキスト標準化モジュール
３０２・・・１次意味パーサ
３０３・・・構造パーサ
３０４・・・２次意味パーサ
３０５・・・主題クラスタリング・モジュール
３０６・・・拡張されたプレーン・テキスト
３０７・・・規則
３０８・・・辞書
３０９・・・１次意味パーサの出力（意味でタグ付けされたテキスト項目）
３１０・・・文法
３１１・・・構造パーサの出力（機能及び内部関連でタグ付けされたテキスト項目）
３１２・・・規則
３１３・・・２次意味パーサの出力（拡張された直示的指示、解決された同義性及び変動性レベリング）
３１４・・・規則
３１５・・・主題クラスタリング・モジュールの出力（主題的にタグ付けされた用語）
【図１】
2010257452.tif 000003
【図２】
2010257452.tif 000004
【図３】
2010257452.tif 000005
【図４】
2010257452.tif 000006
【図５】
2010257452.tif 000007
【図６】
2010257452.tif 000008
【図７】
2010257452.tif 000009
【図８】
2010257452.tif 000010
【図９】
2010257452.tif 000011
【図１０】
2010257452.tif 000012