(57)【要約】【課題】  データベース内のデータに問い合わせするための方法、装置、及びコンピュータ・プログラムを提供すること。【解決手段】  データベース内のデータにオントロジが関連付けられる。クエリ述語を含むクエリが受け取られる。クエリ述語はオントロジからの含意を用いて拡張され、修正済みクエリが形成される。修正済みクエリは、包摂チェックを含むように書き直される。【選択図】      図１
2010517137.tif 000002
【特許請求の範囲】
【請求項１】
データベース内のデータに問い合わせするための、コンピュータで実行される方法であって、
前記データベース内の前記データにオントロジを関連付けるステップと、
前記オントロジから含意を抽出するステップと、
クエリ述語を含むクエリを受け取るステップと、
前記オントロジからの前記含意を用いて、修正済みクエリを形成するように前記クエリ述語を拡張するステップと、
包摂チェックを含むように前記修正済みクエリを書き直すステップと、
を含む、コンピュータで実行される方法。
【請求項２】
前記データベース内の前記修正済みクエリを処理するステップをさらに含み、前記修正済みクエリの処理は、前記データ及び前記オントロジから知識を推論する、
請求項１に記載のコンピュータで実行される方法。
【請求項３】
前記オントロジからの前記含意は含意グラフ内に格納される、請求項１に記載のコンピュータで実行される方法。
【請求項４】
含意を用いてクエリ述語を拡張する前記ステップは、
前記クエリ述語が前記含意グラフ内のある含意に合致するとの判断に基づいて、前記含意を前記クエリに付加することによって前記クエリ述語を拡張するステップ
を含む、請求項１に記載のコンピュータで実行される方法。
【請求項５】
前記修正済みクエリは１つ又は複数の文節を含み、包摂チェックを含むように前記修正済みクエリを書き直す前記ステップは、
前記１つ又は複数の文節が関連付けられた包摂階層を前記オントロジ内に有するか否かを判定するために前記１つ又は複数の文節を検査するステップと、
前記１つ又は複数の文節の中のある文節が関連付けられた包摂階層を有するという判断に基づいて、修正済み文節を形成するように前記文節を書き直すステップであって、前記修正済み文節が包摂チェックを実行するための包摂述語を含む、ステップと
を含む、請求項１に記載のコンピュータで実行される方法。
【請求項６】
前記包摂述語は、拡張マークアップ言語の値を用いて、拡張マークアップ言語パス表現を評価する、請求項５に記載のコンピュータで実行される方法。
【請求項７】
前記データベースは、関係表を用いて前記データを格納し、拡張マークアップ言語を用いて前記オントロジを格納する、請求項１に記載のコンピュータで実行される方法。
【請求項８】
データベース内のデータに問い合わせするためのコンピュータ使用可能プログラム・コードを含むコンピュータ使用可能媒体を含むコンピュータ・プログラムであって、
前記データベース内の前記データにオントロジを関連付けるためのコンピュータ使用可能コードと、
クエリ述語を含むクエリを受け取るためのコンピュータ使用可能コードと、
前記オントロジからの含意を用いて、修正済みクエリを形成するように前記クエリ述語を拡張するためのコンピュータ使用可能コードと、
包摂チェックを含むように前記修正済みクエリを書き直すためのコンピュータ使用可能コードと
を含むコンピュータ・プログラム。
【請求項９】
前記データベース内の前記修正済みクエリを処理するためのコンピュータ使用可能コードをさらに含み、前記修正済みクエリの処理は、前記データ及び前記オントロジから知識を推論する、請求項８に記載のコンピュータ・プログラム。
【請求項１０】
前記オントロジからの前記含意は含意グラフ内に格納される、請求項８に記載のコンピュータ・プログラム。
【請求項１１】
含意を用いてクエリ述語を拡張するための前記コンピュータ使用可能コードは、
前記クエリ述語が前記含意グラフ内のある含意に合致するとの判断に基づいて、前記含意を前記クエリに付加することによって前記クエリ述語を拡張するためのコンピュータ使用可能コードを含む、請求項８に記載のコンピュータ・プログラム。
【請求項１２】
前記修正済みクエリは１つ又は複数の文節を含み、包摂チェックを含むように前記修正済みクエリを書き直すための前記コンピュータ使用可能コードは、
前記１つ又は複数の文節が関連付けられた包摂階層を前記オントロジ内に有するか否かを判定するために前記１つ又は複数の文節を検査するコンピュータ使用可能コードと、
前記１つ又は複数の文節の中のある文節が関連付けられた包摂階層を有するという判断に基づいて、修正済み文節を形成するように前記文節を書き直すためのコンピュータ使用可能コードであって、前記修正済み文節が包摂チェックを実行するための包摂述語を含む、コンピュータ使用可能コードと
を含む、請求項８に記載のコンピュータ・プログラム。
【請求項１３】
前記包摂述語は、拡張マークアップ言語の値を用いて、拡張マークアップ言語パス表現を評価する、請求項１２に記載のコンピュータ・プログラム。
【請求項１４】
前記データベースは、関係表を用いて前記データを格納し、拡張マークアップ言語を用いて前記オントロジを格納する、請求項８に記載のコンピュータ・プログラム。
【請求項１５】
データベース内のデータに問い合わせするためのデータベース管理システムであって、
バスと、
前記バスに接続されたストレージ装置であって、コンピュータ使用可能コード及び前記データを収容するストレージ装置と、
前記バスに接続された通信ユニットと、
前記バスに接続された、前記コンピュータ使用可能コードを実行するための処理ユニットと
を備え、前記処理ユニットは、前記データベース内の前記データにオントロジを関連付け、クエリ述語を含むクエリを受け取り、前記オントロジからの含意を用いて修正済みクエリを形成するように前記クエリ述語を拡張し、包摂チェックを含むように前記修正済みクエリを書き直す、データベース管理システム。
【請求項１６】
前記処理ユニットは、前記データベース内の前記修正済みクエリを処理し、前記データ及び前記オントロジから知識を推論する、請求項１５に記載のデータベース管理システム。
【請求項１７】
前記処理ユニットは、前記オントロジから含意を抽出し、前記含意を含意グラフ内に格納する、請求項１５に記載のデータベース管理システム。
【請求項１８】
前記処理ユニットは、前記クエリ述語が前記含意グラフ内の含意に合致することを判断することにより前記クエリ述語を拡張し、前記含意を前記クエリに付加することにより前記クエリ述語を拡張する、請求項１５に記載のデータベース管理システム。
【請求項１９】
前記修正済みクエリは１つ又は複数の文節を含み、前記処理ユニットは、前記１つ又は複数の文節が関連付けられた包摂階層を前記オントロジ内に有するか否かを判定するために前記１つ又は複数の文節を検査することにより、包摂チェックを含むように前記修正済みクエリを書き直し、前記１つ又は複数の文節の中の文節が関連付けられた包摂階層を有するという判断に基づいて、修正済み文節を形成するように前記文節を書き直し、前記修正済み文節は、包摂チェックを実行するための包摂述語を含む、請求項１５に記載のデータベース管理システム。
【請求項２０】
前記包摂述語は、拡張マークアップ言語の値を用いて、拡張マークアップ言語パス表現を評価する、請求項１９に記載のデータベース管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、データ処理システムに関し、具体的にはデータベースの問い合わせ（querying）に関する。さらにより具体的には、本発明は、データベース内のデータ及び関連付けられたオントロジを問い合わせするための方法、装置、及びコンピュータ・プログラム製品に関する。
【背景技術】
【０００２】
「データ」という用語は、一般に、高度に構造化され、データ要素と呼ばれる異なる情報の断片間で固定された関係を有する情報を指す。論理的に関係があるデータ要素の集合は、データベースと呼ばれる記録の集積として、系統的な方式でコンピュータ内に格納することができる。データ要素間の論理関係は、データベースに問い合わせをすること可能にし、データベースから情報を抽出することを可能にする。データベースに問い合わせすることにより、ユーザは、データ要素に関する意味のある情報を抽出することができる。データベースの管理及び問い合わせのために用いられるコンピュータ・プログラムは、データベース管理システム（ＤＢＭＳ）として知られる。
【０００３】
データベース管理システムは、データ要素間の関係に基づいてデータを管理する。データベース管理システムは、データ要素に対して種々の操作を実行する方法を提供することによりデータを管理する。データベース内のデータ要素に対して実行することができる操作は、データ要素の追加、データ要素の消去、データ要素の修正、データ要素のソート、及びデータ要素への問い合わせを含む。データベース・クエリは、典型的には、１つ又は複数の論理規則を含む。クエリの処理中に、データベース管理システムは、データベースから、クエリ内の論理規則に合致する全てのデータ要素を抽出する。
【０００４】
「オントロジ」という用語は、一般に、データ要素に関する知識を指す。所与のデータ要素の集合は、１つ又は複数の関連付けられたオントロジを有することができる。オントロジは、データベースへの格納に適さない特徴を有する。例えば、オントロジ内の知識は、典型的には、データ要素よりも構造化されていない。従って、オントロジは、典型的には、データベース管理システムによって格納されず、管理もされない。
【０００５】
現在のところ、ユーザは、データベース管理システムを用いてデータベース内のデータ要素に問い合わせすることができる。しかしながら、オントロジはデータベース内に格納されることに適していないので、ユーザは、同じような方式でデータ要素に関連付けられたオントロジに問い合わせすることができない。また、ユーザが新たな知識を推論するためにデータ要素とオントロジにまとめて問い合わせすることもできない。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
オントロジはデータ要素に関する貴重な情報を含んでいるので、データ要素とオントロジとを互いにリンクさせて一緒に管理することができれば、ユーザは、データ及びオントロジに基づき新たな知識を推論するためのクエリを策定することができる。
【課題を解決するための手段】
【０００７】
様々な実施形態が、データベース内のデータに問い合わせするための方法、装置、及びコンピュータ・プログラム製品を提供する。データベース内のデータにオントロジが関連付けられる。クエリ述語を含むクエリが受け取られる。クエリ述語はオントロジからの含意を用いて拡張され、修正済みクエリが形成される。修正済みクエリは、包摂チェックを含むように書き直される。
【０００８】
本発明の特性と考えられる新規な特徴は、添付の特許請求の範囲に記載されている。しかしながら、本発明自体、並びにその好ましい使用様式、更なる目的及び利点は、以下の例示的な実施形態の詳細な説明を添付図面と併せて読む場合に参照することによって最も良く理解される。
【図面の簡単な説明】
【０００９】
【図１】例示的な実施形態を実施することができるデータ処理システムのネットワークの図形表示である。
【図２】例示的な実施形態を実施することができるデータ処理システムのブロック図である。
【図３】例示的な実施形態による、ユーザとデータベース管理システム（ＤＢＭＳ）との対話のブロック図である。
【図４】例示的な実施形態による、ワインのオントロジにおけるクラス階層のブロック図である。
【図５】例示的な実施形態による、ワインのオントロジにおける規則を示す。
【図６】例示的な実施形態による、「ｌｏｃａｔｅｄＩｎ（に存在する）」プロパティに関するクラス階層を示す。
【図７】例示的な実施形態によるデータベース・コマンドを示す図である。
【図８】例示的な実施形態による仮想ビュー・コマンドを示す図である。
【図９】例示的な実施形態によるハイブリッド型関係−ＸＭＬデータベースのコマンドを示す。
【図１０】例示的な実施形態による、ユーザとオントロジ・リポジトリとの対話を示すブロック図である。
【図１１】例示的な実施形態による、抽出された情報を示すブロック図である。
【図１２】例示的な実施形態による、「Ｗｉｎｅ（ワイン）」クラス階層を構築するためのコードの例である。
【図１３】例示的な実施形態による、クラスのブロック図及びサンプル・コードを示す。
【図１４】例示的な実施形態による、「Ｗｉｎｅ（ワイン）」オントロジの推移プロパティを指定するためのコードの例である。
【図１５】例示的な実施形態による連言的含意の例である。
【図１６】例示的な実施形態による選言的含意の例である。
【図１７】例示的な実施形態による含意グラフのブロック図である。
【図１８】例示的な実施形態によるクラス階層の例である。
【図１９】例示的な実施形態によるオントロジ・プロセッサの流れ図である。
【図２０】例示的な実施形態による、クラス階層を抽出するための流れ図である。
【図２１】例示的な実施形態による、推移プロパティを抽出するための流れ図である。
【図２２】例示的な実施形態による、含意グラフを構築するための流れ図である。
【図２３】例示的な実施形態による、ワイン製品及び関連付けられた「ワイン」オントロジの基底表である。
【図２４】例示的な実施形態によるプロセッサの流れ図である。
【図２５】例示的な実施形態によるクエリの例である。
【図２６】例示的な実施形態を実施することができるクエリの例である。
【図２７】例示的な実施形態を実施することができるクエリの例である。
【発明を実施するための形態】
【００１０】
ここで図面を参照し、特に図１−図２を参照すると、例示的な実施形態を実施することができるデータ処理環境の例証となる図が提示される。図１−図２は例証に過ぎず、様々な実施形態を実施することができる環境に関していかなる限定を主張するものでもなく、意味するものでもないことを認識されたい。図示された環境に対して、多くの変更を行うことができる。
【００１１】
ここで図面を参照すると、図１は、例示的な実施形態を実施することができるデータ処理システムのネットワークの図形的表現を示す。ネットワーク型データ処理システム１００は、実施形態を実施することができるコンピュータのネットワークである。ネットワーク型データ処理システム１００はネットワーク１０２を含み、このネットワーク１０２は、ネットワーク型データ処理システム１００内で互いに接続されている種々の装置及びコンピュータの間に通信リンクを提供するために用いられる媒体である。ネットワーク１０２は、有線、無線通信リンク、又は光ファイバ・ケーブルといった接続を含むことができる。
【００１２】
図示された例において、サーバ１０４及びサーバ１０６が、ストレージ・ユニット１０８と共にネットワーク１０２に接続している。さらに、クライアント１１０、１１２、及び１１４がネットワーク１０２に接続している。これらのクライアント１１０、１１２、及び１１４は、例えば、パーソナルコンピュータであってもよく、又はネットワークコンピュータであってもよい。図示された例において、サーバ１０４は、ブート・ファイル、オペレーティング・システム・イメージ、及びアプリケーションのようなデータをクライアント１１０、１１２、及び１１４に提供する。クライアント１１０、１１２、及び１１４は、この例においては、サーバ１０４のクライアントである。ネットワーク型データ処理システムは、図示されない付加的なサーバ、クライアント、及び他の装置を含むことができる。
【００１３】
図示された例において、ネットワーク型データ処理システム１００はインターネットであり、ネットワーク１０２は、互いに通信するためにトランスミッション・コントロール・プロトコル／インターネット・プロトコル（Transmission Control Protocol/Internet Protocol）（ＴＣＰ／ＩＰ）のプロトコル・スートを用いるネットワーク及びゲートウェイのワールドワイドな集積を表す。インターネットの核心部には、データ及びメッセージをルーティングする幾千もの商業関係、行政関係、教育関係、及びその他のコンピュータ・システムからなる主要ノード又はホスト・コンピュータの間の高速データ通信線のバックボーンが存在する。もちろん、ネットワーク型データ処理システム１００は、例えば、イントラネット、ローカル・エリア・ネットワーク（ＬＡＮ）、又は広域ネットワーク（ＷＡＮ）といった多数の異なるタイプのネットワークとして実装することもできる。図１は例示として意図されており、様々な実施形態に対するアーキテクチャ上の限定を意図するものではない。
【００１４】
ここで図２を参照すると、例示的な実施形態を実施することができるデータ処理システムのブロック図が示される。データ処理システム２００は、図１のサーバ１０４又はクライアント１１０のようなコンピュータの例であり、この中に、例示的な実施形態のために、処理を実施するコンピュータ使用可能なコード又は命令を配置することができる。
【００１５】
図示された例において、データ処理システム２００は、ノースブリッジ及びメモリ・コントローラ・ハブ（ＭＣＨ）２０２と、サウスブリッジ及び入出力（Ｉ／Ｏ）コントローラ・ハブ（ＩＣＨ）２０４とを含む、ハブ・アーキテクチャを用いる。処理ユニット２０６、メイン・メモリ２０８、及びグラフィックス・プロセッサ２１０は、ノースブリッジ及びメモリ・コントローラ・ハブ２０２に接続される。処理ユニット２０６は、１つ又は複数のプロセッサを含むことができ、１つ又は複数の異種のプロセッサ・システムを用いて実装することさえできる。グラフィックス・プロセッサ２１０は、例えばアクセラレーテッド・グラフィック・ポート（ＡＧＰ）を経由してＭＣＨに接続することができる。
【００１６】
図示された例において、ローカル・エリア・ネットワーク（ＬＡＮ）アダプタ２１２は、サウスブリッジ及びＩ／Ｏコントローラ・ハブ２０４に接続され、オーディオ・アダプタ２１６と、キーボード及びマウス・アダプタ２２０と、モデム２２２と、読取り専用メモリ（ＲＯＭ）２２４と、ユニバーサル・シリアル・バス（ＵＳＢ）ポート及び他の通信ポート２３２と、ＰＣＩ／ＰＣＩｅデバイス２３４は、バス２３８を経由してサウスブリッジ及びＩ／Ｏコントローラ・ハブ２０４に接続され、ハードディスク・ドライブ（ＨＤＤ）２２６とＣＤ−ＲＯＭドライブ２３０は、バス２４０を経由してサウスブリッジ及びＩ／Ｏコントローラ・ハブ２０４に接続される。ＰＣＩ／ＰＣＩｅデバイスは、例えば、イーサネット・アダプタ、アドイン・カード、及びノートブック・コンピュータ用ＰＣカードを含むことができる。ＰＣＩはカードバス・コントローラを用いるが、ＰＣＩｅはこれを用いない。ＲＯＭ２２４は、例えば、フラッシュ・バイナリ入出力システム（ＢＩＯＳ）とすることができる。ハードディスク・ドライブ２２６及びＣＤ−ＲＯＭドライブ２３０は、例えば、インテグレーテッド・ドライブ・エレクトロニクス（integrated drive electronics）（ＩＤＥ）又はシリアル・アドバンスト・テクノロジ・アタッチメント（serial advanced technology attachment）（ＳＡＴＡ）インターフェースを用いることができる。スーパーＩ／Ｏ（ＳＩＯ）デバイス２３６をサウスブリッジ及びＩ／Ｏコントローラ・ハブ２０４に接続してもよい。
【００１７】
オペレーティング・システムは、処理ユニット２０６上で動作し、図２のデータ処理システム２００内の種々の構成要素を連係させ、制御を与える。オペレーティング・システムは、マイクロソフト（登録商標）ウィンドウズ（登録商標）ＸＰ（マイクロソフト及びウィンドウズは、米国、その他の国々、又はその両方においてMicrosoft Corporationの商標である）のような市販のオペレーティング・システムとすることができる。Ｊａｖａ（商標）プログラミング・システムのようなオブジェクト指向プログラミング・システムは、オペレーティング・システムと共に動作することができ、データ処理システム２００上で実行されるＪａｖａプログラム又はアプリケーションからオペレーティング・システムに対して呼出しを与える。Ｊａｖａ及び全てのＪａｖａベースの商標は、米国、その他の国々、又はその両方においてSun Microsystems, Inc.の商標である。
【００１８】
オペレーティング・システム、オブジェクト指向プログラミング・システム、及びアプリケーション又はプログラムに対する命令は、ハードディスク・ドライブ２２６のようなストレージ装置上に置かれ、処理ユニット２０６による実行ためにメイン・メモリ２０８内にロードすることができる。例示的な実施形態のプロセスは、例えばメイン・メモリ２０８、読み出し専用メモリ２２４、又は１つ若しくは複数の周辺装置のようなメモリ内に配置することができるコンピュータによって実行される命令を用いて、処理ユニット２０６により行われることができる。
【００１９】
図１−図２におけるハードウェアは実装に応じて変わることができる。図１−図２に図示されたハードウェアに加えて、又はこれらの代わりに、フラッシュメモリ、同等の不揮発性メモリ、又は光ディスクドライブなどのような他の内部ハードウェア又は周辺装置を用いることができる。さらに、例示的な実施形態のプロセスは、マルチプロセッサ型データ処理システムに適用することもできる。
【００２０】
幾つかの説明的例示において、データ処理システム２００は、携帯型情報端末（ＰＤＡ）とすることができ、これは、一般に、オペレーティング・システム・ファイル及び／又はユーザが生成したデータを格納するための不揮発性メモリを提供するフラッシュメモリを用いて構成される。バス・システムは、システム・バス、Ｉ／Ｏバス、及びＰＣＩバスのような１つ又は複数のバスで構成することができる。もちろん、バス・システムは、その構造（fabric）又はアーキテクチャに取り付けられた異なる構成要素間又は装置間でのデータ転送を提供する任意のタイプの通信構造又はアーキテクチャを用いて実装することができる。通信ユニットは、モデム又はネットワーク・アダプタのような、データの送信及び受信に用いられる１つ又は複数のデバイスを含むことができる。メモリは、例えば、メイン・メモリ２０８であってもよく、又はノースブリッジ及びメモリ・コントローラ・ハブ２０２内で見出されるようなキャッシュであってもよい。処理ユニットは、１つ又は複数のプロセッサ又はＣＰＵを含むことができる。図１−図２において図示された例及び上記の例は、アーキテクチャ上の限定を意味するものではない。例えば、データ処理システム２００は、ＰＤＡの形態を取ることに加えて、タブレット・コンピュータ、ラップトップ・コンピュータ、又は電話装置とすることもできる。
【００２１】
序論
様々な実施形態が、データベース内のデータに問い合わせするための方法、装置、及びコンピュータ・プログラム製品を提供する。データにオントロジが関連付けられる。要求側からのクエリの受け取りに応答して、クエリを用いてデータベース内の関係データが識別され、識別済み関係データが形成される。識別済み関係データ及びオントロジを用いて、オントロジ内のオントロジ的知識が識別される。結果は要求側に戻される。
【００２２】
今日、殆どの会社は関係データベースに格納された大容量のデータを有する。典型的には、このデータは長年にわたって収集されたものである。会社はまた、容易に関係形式で格納されることに向かない半構造化形式（semi-structured form）の知識を有することもある。データと、データに関する知識（オントロジ）の両方を格納し、これに問い合わせを行うことにより新情報を推論することができれば、会社にとって有用である。
【００２３】
もちろん、データ及びオントロジを格納し、これに問い合わせを行う１つの方法は、オントロジを実体化し、その結果として得られる関係を格納することである。しかしながら、オントロジを実体化することはオントロジを関係データへと降格することであり、オントロジを半構造化形式で保持することの利点を失うことになる。
【００２４】
実施形態は、上述のフレームワークを用いることによりこの問題を解決する。クラス階層、含意規則、及び推移プロパティが、オントロジから抽出され、拡張マークアップ言語の形で格納され、データ及びオントロジに対して問い合わせを行うことを可能にする。クラス階層、含意規則、及び推移プロパティは、関係表に含まれていないデータに関する知識をクエリが推論できるようにする一方で、オントロジは半構造化形式のままにしておく。
【００２５】
さらに、このフレームワークを用いて、ユーザは、ユーザが関係データについて通常のクエリを作成するのと同様の仕方で、知識を推論するクエリを作成することができる。このことにより、どの学習曲線も軽減され、ユーザは、知識を推論するためのクエリを比較的迅速に作成できるようになる。
【００２６】
オントロジとは、特定の知識の領域内のエンティティ及び関係のモデルである。あるデータ要素の集合に関連付けられたオントロジは、そのデータについての知識であり、これは、領域知識（domain knowledge）としても知られる。領域知識とは、典型的には、特定の分野の専門家である人物から取得され、次いで知識技術者によりエンティティ及び関係の集合に変換された知識である。
【００２７】
データ要素の集合は、１つ又は複数のデータ要素を含む。現行のデータベース管理システム（ＤＢＭＳ）は、データ要素及び関連付けられたオントロジの両方を容易且つシームレスに操作することができない。関連付けられたオントロジをデータと同様に管理することができるようになり、その結果、ユーザが、関係データに対して問い合わせを行うのと同様の仕方で、データに対して問い合わせを行うことができ、オントロジに対して問い合わせを行うことができ、かつデータとオントロジとから導かれる推論に対して問い合わせを行うことができれば、有用である。
【００２８】
データ、領域知識、及びデータと領域知識とから導かれる推論に対して問い合わせを行う能力は、意味論的データ管理と呼ばれる。データベース管理システムにおいて意味論的データ管理をサポートするために、実施形態は、データ表現と知識表現と推論との間のギャップを橋渡しする、関係データ及び関連付けられたオントロジを管理するためのフレームワークを提供する。
【００２９】
様々な実施形態が、データベース内のデータに問い合わせするための方法、装置、及びコンピュータ・プログラム製品を提供する。オントロジがデータに関連付けられる。要求側からのクエリの受け取りに応答して、クエリを用いてデータベース内の関係データが識別され、識別済み関係データが形成される。識別済み関係データ及びオントロジを用いて、オントロジ内のオントロジ的知識が識別される。結果は要求側に戻される。
【００３０】
各オントロジ要素は、関連付けられたクラスを有する。オントロジ内のクラスは、クラス階層として組織化することができ、その中でクラスはツリー構造として組織化される。クラス階層において、下位のクラスは、上位のクラス（単数又は複数）から１つ又は複数のプロパティを継承する。例えば、ワインのオントロジにおいて、ワインが生産される地域をクラスとすることができる。従って、カリフォルニア州メンドシノで生産されるワインは、メンドシノをカリフォルニアの下位に示し、カリフォルニアを米国の下位に示すことにより、クラス階層で表現することができる。
【００３１】
含意規則は、オントロジ要素間の論理関係を示す論理規則である。例えば、ワインの種類がバーガンディであれば、そのワインはフランス地域で生産されたものである。この論理関係は、以下の含意規則
（種類＝バーガンディ）＝＞（地域＝フランス）
として記述することができる。
【００３２】
推移関係において、ＡがＢに関係し、ＢがＣに関係するならば、論理的に、ＡはＣに関係していることになる。例えば、メンドシノがカリフォルニアにあり、カリフォルニアが米国にあるならば、メンドシノは米国にあることになる。
【００３３】
概要
ここで図３を参照すると、例示的な実施形態によるユーザとデータベース管理システム（ＤＢＭＳ）との対話３００のブロック図が示される。ユーザとデータベース管理システムとの対話３００において、ユーザ３０２は、データベース管理システムＤＢＭＳ３０４と対話する。ユーザ３０２は、ＤＢＭＳ３０４に対して、ＤＢＭＳ３０４から情報を抽出するためにクエリを作成し、送出すること、及びクエリの結果をＤＢＭＳ３０４から受け取ることを含む、種々の操作を行うことができる。
【００３４】
ＤＢＭＳ３０４は、従来の関係データ表である基底表（base table）３０８とオントロジ・リポジトリ３１０との仮想ビュー３０６を提供する。オントロジ・リポジトリ３１０は、基底表３０８内のデータに関連付けられた１つ又は複数のオントロジを含む。「オントロジ」という用語は、関係データ表内のデータ要素に関する知識を指す。オントロジにおける知識は、典型的にはデータ要素よりも構造化されていない。例えば、ワインのデータベースは、ワインの各種類、１本当りの値段、及び生産者に関する情報を含むことができる。オントロジは、ブドウが栽培された場所及びブドウの色といった情報を含むことができる。
【００３５】
仮想ビュー３０６は、ユーザに、基底表３０８内のデータとオントロジ・リポジトリ３１０内のオントロジの集合の両方のシームレスで統合されたビューを提供する。オントロジの集合は、１つ又は複数のオントロジを含む。仮想ビュー３０６は、ユーザに対して従来のデータベース管理システムとして表示されることができるので、そのため、ユーザは、自分がデータとオントロジの両方を仮想ビューの中で一緒に閲覧していることに気づかないこともある。
【００３６】
仮想ビューは、ユーザが関係データ表内のデータ要素の部分集合をオントロジ・リポジトリ３１０内のオントロジの部分集合に関連付ける場合に作成される。部分集合とは、仮想ビュー内のデータ要素が関係ビュー内の全データ要素に等しいか又はそれより少なく、仮想ビュー内のオントロジがオントロジ・リポジトリ３１０内のオントロジに等しいか又はそれより少ないことを意味する。
【００３７】
ユーザ３０２は、仮想ビュー３０６を用いてＤＢＭＳ３０４に問い合わせを行う。仮想ビュー・クエリ・プロセッサ３１２は、ユーザのクエリを受け取りし、クエリを書き直し、書き直したクエリを処理のためにクエリ・エンジン３１４へと送り出す。クエリ・エンジン３１４は、ハイブリッド型関係−ＸＭＬクエリ・エンジンとすることができる。
【００３８】
クエリ・エンジン３１４は、書き直されたクエリを受け取り、クエリを実行し、情報を取得し、次いでその情報をユーザに戻す。取得された情報は、基底表３０８からのデータであってもよく、オントロジ・リポジトリ３１０からの知識であってもよく、又は基底表３０８内のデータをオントロジ・リポジトリ３１０内のオントロジにリンクさせた結果として得られる推論であってもよい。
【００３９】
従来のデータベース管理システムにおいては、ユーザ３０２はクエリ・エンジン３１４にクエリを送出し、クエリ・エンジン３１４はクエリに合致する情報を基底表３０８から抽出し、次いでそのクエリの結果をユーザ３０２に送り返す。例示的な実施形態において、データ及び関連付けられたオントロジの集合の両方に対して一緒に問い合わせを行うことができるように、従来型のデータベース管理システムにオントロジ・リポジトリ３１０が追加される。例示的な実施形態において、クエリ・エンジン３１４は、関係データベース及びＸＭＬファイルとして格納されたオントロジの集合の両方を扱うように改変される。
【００４０】
例示的な実施形態において、ユーザ３０２が、基底表３０８からのデータ要素及びオントロジ・リポジトリ３１０からのオントロジ要素の両方を閲覧することができるように、従来型のデータベース管理システムに仮想ビュー３０６が追加される。ユーザ３０２が、仮想ビューを用いて基底表３０８及びオントロジ・リポジトリ３１０内の関連付けられたオントロジに問い合わせを行うことができるように、従来型のデータベース管理システムに仮想ビュー・クエリ・プロセッサ３１２が追加される。
【００４１】
図３における様々なブロックは説明を目的としており、例示的な実施形態の様々な特徴を実装することができる方式を限定することを意味するものではない。図３に示されるデータベース管理システムのフレームワークは、データのみならず領域知識をも操作するようにデータベース管理システムを拡張するので、領域知識及びデータからの推論を行うことができるようになる。領域知識の表現の詳細からユーザを遮断するために、ユーザには仮想ビューが提示され、この仮想ビューを通じて、領域知識はデータと変わりなく表示される。このような方法で、データベース管理システム内に完全に組み入れられてサポートされている関係演算子を用いて、領域知識を操作することができる。その上、関係演算子を用いて、データ及び領域知識に基づく推論を行うことができる。
【００４２】
【表１】
2010517137.tif 000003
【００４３】
表１は、３種のワインについての関係データを含む、図３の基底表３０８のような基底表である。表１の各行は、ワインの特定のインスタンスに関連付けられる。各ワインは、４つの属性、即ち種類、原産地、製造者、及び価格を有する。従来の関係データベース管理システムは、ユーザがこれらの属性を用いてワインについてのデータを問い合わせすることを可能にする。しかしながら、ユーザは、表１に含まれるデータに対して問い合わせ及び検索を行うことができるのみであり得る。
【００４４】
その一方で、人間はデータを知識と組み合わせて推論を作り出す能力を有する。例えば、ワイン通がどのワインが米国（Ｕ．Ｓ．）原産であるかと訊ねられれば、そのワイン通はジンファンデルと答えるであろうが、それはその原産地のエドナ・ヴァレーがカリフォルニアに位置するからである。エドナ・ヴァレーがカリフォルニアにあり、カリフォルニアは米国にあるという情報は、表１のデータ内に明示的に含まれていないが、その代わり、地理分野の領域知識に属している。
【００４５】
同様に、どのワインが赤ワインであるかと訊ねられれば、ワイン通はジンファンデルとバーガンディであると答えるであろうが、それはそのワイン通が、ジンファンデルは赤ワインであり、コート・ドール産のバーガンディも赤ワインであると知っているからである。ワイン通は、バーガンディには赤も白もあるが、コート・ドール原産のバーガンディ・ワインは常に赤ワインであることを知っている。しかしながら、推論を伴うクエリに答えるために必要な領域知識は、関係表には提示されていない。
【００４６】
様々な実施形態は、推論を行うことを伴うクエリに答えるための第１のステップは、オントロジのクラス階層といったオントロジに関する情報を抽出することにより、領域知識をコンピュータでアクセス可能なものとすることであることを認識する。例えば、ワインのオントロジは、オブジェクトのクラス階層、各オブジェクト・クラスに関連付けられたプロパティ、並びに（ａ）オブジェクト、（ｂ）オブジェクトのプロパティ、及び（ｃ）プロパティが取り得る値を支配する規則から構成されることができる。
【００４７】
クラス階層
ここで図４を参照すると、例示的な実施形態を実施することができる、ワインのオントロジにおけるクラス階層のブロック図が示される。クラス階層は、ワインのオントロジから抽出され、図３のオントロジ・リポジトリ３１０のようなオントロジ・リポジトリ内に格納される。
【００４８】
ワインのオントロジにおけるクラス階層４００は、ワインのオントロジにおける様々なタイプの関係を示す。サブクラス及びスーパークラスという用語が、２つのクラス間の階層関係についての情報を伝えるために用いられる。例えば、１つのクラス階層内で、他のクラスの下位のクラスはサブクラスと呼ばれることがあり、他のクラスの上位のクラスはスーパークラスと呼ばれることがある。
【００４９】
図４において、「事物（Ｔｈｉｎｇ）」４０２は、サブクラス「飲用液体（ＰｏｔａｂｌｅＬｉｑｕｉｄ）」４０４を有する。「飲用液体」４０４は、サブクラス「ワイン（Ｗｉｎｅ）」４０６を有する。「ワイン」４０６は、「バーガンディ（Ｂｕｒｇｕｎｄｙ）」４０８及び「リースリング（Ｒｉｅｓｌｉｎｇ）」４１０を含む複数のサブクラスを有する。「リースリング」４１０は、２つのサブクラス「辛口リースリング（ｄｒｙＲｉｅｓｌｉｎｇ）」４１２及び「甘口リースリング（ｓｗｅｅｔＲｉｅｓｌｉｎｇ）」４１４を有する。
【００５０】
クラス「ワイン」４０６は、スーパークラス「事物」４０２から、プロパティ「位置する（ＬｏｃａｔｅｄＩｎ）」４１６を継承する。プロパティ「位置する」４１６は、クラス「地域（Ｒｅｇｉｏｎ）」４１８からの値を取る。クラス「ワイン」４０６は、５つのプロパティ、即ち「糖分を有する（ｈａｓＳｕｇａｒ）」４２０、「ボディを有する（ｈａｓＢｏｄｙ）」４２２、「色を有する（ｈａｓＣｏｌｏｒ）」４２４、「製造者を有する（ｈａｓＭａｋｅｒ）」４２６、及び「ブドウから作られる（ｍａｄｅＦｒｏｍＧｒａｐｅ）」４２８に関連付けられる。
【００５１】
各プロパティはある範囲クラス（range class）に関連付けられるので、そのため、プロパティの値はその範囲クラスのインスタンスに限定される。例えば、プロパティ「糖分を有する」４２０は、クラス「ワインの糖分（ｗｉｎｅＳｕｇａｒ）」４３０のインスタンスである値を取る。同様に、プロパティ「ボディを有する」４２２、「色を有する」４２４、「製造者を有する」４２６、及び「ブドウから作られる」４２８は、それぞれ、クラス「ワインのボディ（ｗｉｎＢｏｄｙ）」４３２、「ワインの色（ｗｉｎｅＣｏｌｏｒ）」４３４、「ワイン醸造所（Ｗｉｎｅｒｙ）」４３６、及び「ワイン用ブドウ（ｗｉｎｅＧｒａｐｅ）」４３８のインスタンスである値を取る。
【００５２】
クラスは、他のクラスを包摂するか、又は他のクラスに包摂されることができる。例えば、クラス「ワイン」４０６は、クラス「バーガンディ」４０８及びクラス「リースリング」４１０を包摂する。同様に、「辛口リースリング」４１２及び「甘口リースリング」４１４は、「リースリング」４１０に包摂される。包摂関係はクラスの階層を生じさせ、典型的には、「事物」４０２のような全般的なスーパークラスが上になり、「辛口リースリング」４１２のような非常に特定的なサブクラスが下になる。
【００５３】
含意規則
ここで図５を参照すると、例示的な実施形態を実施することかできるワインのオントロジにおける規則が示される。図５は、ワインのオントロジから抽出された含意規則の例を提供する。本実施形態において、含意規則は、図３のオントロジ・リポジトリ３１０のようなオントロジ・リポジトリ内に含意グラフとして格納される。
【００５４】
ワインのオントロジにおける規則５００において、規則５０２は、「コート・ドール（ＣｏｔｅｓＤＯｒ）」クラス内のワインの全てのインスタンスは穏やかなフレーバーを有することを規定する。規則５０４は、「コート・ドール」クラス内のワインの全てのインスタンスは種類「バーガンディ赤（ＲｅｄＢｕｒｇｕｎｄｙ）」であり、且つその原産地は「コート・ドール地域（ＣｏｔｅｓＤＯｒＲｅｇｉｏｎ）」であることを規定する。規則５０６は、種類「バーガンディ赤」のワインの全てのインスタンスは種類「バーガンディ（Ｂｕｒｇｕｎｄｙ）」及び種類「赤ワイン（ＲｅｄＷｉｎｅ）」を有することを規定する。規則５０８は、種類「バーガンディ赤」のワインの全てのインスタンスは「ブドウから作られる（ｍａｄｅＦｒｏｍＧｒａｐｅ）」として「ピノ・ノワール種ブドウ（ＰｉｎｏｔＮｏｉｒＧｒａｐｅ）」を有することを規定する。
【００５５】
推移プロパティ
ここで図６を参照すると、例示的な実施形態を実施することができる「位置する（ｌｏｃａｔｅｄＩｎ）」プロパティに関するクラス階層が示される。図６は、ワインのオントロジから抽出されたクラス階層の例である。クラス階層は、推移プロパティを含み、図３のオントロジ・リポジトリ３１０のようなオントロジ・リポジトリ内に格納される。「位置する」プロパティに関するクラス階層６００は、「地域」オブジェクト・インスタンスに関するプロパティを示す。
【００５６】
「フランス」６０４、「米国」６０６、「イタリア」６０８、及び「ドイツ」６１０は、スーパークラス「世界」内に位置する国々である。「ブルゴーニュ」６１２及び「ボルドー」６１４は、「フランス」６０４内に位置する地域である。「カリフォルニア」６１６及び「テキサス」６１８は「米国」６０６内に位置する地域である。「コート・ドール」６２０及び「ムルソー」６２２は、地域「ブルゴーニュ」６１２内に位置する都市である。「エドナ・ヴァレー」６２４及び「メンドシノ」６２６は、地域「カリフォルニア」６１６内に位置する都市である。「グレープヴァイン」６２８は、地域「テキサス」６１８内に位置する都市である。
【００５７】
推移プロパティをたどることで、新たな推論を行うことができる。例えば、「コート・ドール」６２０は「ブルゴーニュ」６１２にあり、「ブルゴーニュ」６１２は「フランス」６０４にあるので、「コート・ドール」６２０は「フランス」６０４にあることが推論できる。同様にして、「エドナ・ヴァレー」６２４は「米国」６０６にあることが推論できる。
【００５８】
「位置する」プロパティは、図４における「事物」４０２クラスのプロパティであり、図４における「地域」４１８クラスのインスタンスである値を取る。ワインのオントロジは、「位置する」プロパティが推移的であることを指定することができるので、その結果、「地域」インスタンスに対する全ての「位置する」関係はツリー（又は有向非巡回グラフ）を形成する。
【００５９】
図４、図５、及び図６に示された領域知識は、ワインのオントロジから抽出された知識であり、この抽出された知識は、表１における関係データを補足する情報を提供する。しかしながら、図４、図５、及び図６における領域知識は関係型形式になっていないので、従って、従来の関係データベース管理システムはオントロジから抽出された知識を管理することができない。
【００６０】
本実施形態は、データを管理することに加えて、領域知識を管理するためにデータベース管理システムを用いることができることが望ましいことを認識する。第１に、多くの場合、データは既にデータベース管理システム内に存在しており、そのため、データベース管理システムはユーザに広範囲なトランザクション能力及び分析能力を提供することができる。第２に、構造化クエリ言語（structured query language）（ＳＱＬ）のような宣言型クエリ言語は、データ表現の詳細からユーザを遮断することができる。
【００６１】
データと領域知識とを含むデータベース管理システムに対してユーザが問い合わせを行うことができるようにするために、本実施形態は２つの問題に対処する。第１の問題は、オントロジの格納及びアクセスである。第２の問題は、データ及びオントロジを用いて知識を推論することができるように、知識の推論を実施することである。本実施形態は、データベース管理システムがデータ及び領域知識の両方に問い合わせを行うことができるようなフレームワークを提供することにより、これらの両方の問題を解決する。
【００６２】
オントロジはデータとは異なった様式で構造化されているので、オントロジは、典型的には、リソース記述フレームワーク（Resource Description Framework）（ＲＤＦ）又はウェブ・オントロジ言語（Web Ontology Language）（ＯＷＬ）のようなＸＭＬベース言語を用いて半構造化データとして表現され、コード化される。関係データモデルは、構造化された関係を含むデータには適しているが、半構造化データを効率的に格納又は処理することには適さない。
【００６３】
対照的に、ＸＭＬデータモデルは、半構造化データを表現することに、より適している。しかしながら、半構造化データのモデル化におけるＸＭＬの自由度は、ストレージのオーバーヘッド及びクエリ処理のオーバーヘッドと引き換えであり、それが、通常は純粋なＸＭＬデータベースをオントロジの処理用に導入しない理由である。従って、データの半構造化形式を保つと共に、半構造化データが効率的に格納されること、及び効率的に問い合わせが行われることを可能にするような方式で、半構造化データをモデル化することが必要とされる。知識の推論、即ち、データ及び関連付けられたオントロジから推論を導き出すことは、データとオントロジとの間の関係といったオントロジの多数の詳細を用いるので、非常に複雑である。例えば、オントロジの関係は推移的であり得、実際、多くの有用なクエリにはしばしば推移関係が伴う。しかしながら、推移的クエリは表現することが難しく、また処理のオーバーヘッドの観点から、実行するのにコストがかかることがしばしばである。
【００６４】
例えば、関係データベース管理システム（ＲＤＢＭＳ）において、推移関係は、再帰的ＳＱＬクエリの集合を実行することを必要とし得る。再帰的とは、与えられたＳＱＬクエリが繰り返し分解されて付加的なＳＱＬクエリになることを意味し、典型的には、各々の逐次的クエリはより小さなエンティティの集合の上で動作する。
【００６５】
オントロジ・ベースのクエリをデータベース管理システム内で効率的に処理するための１つのアプローチは、オントロジを前処理し、オントロジ内の全ての推移関係について推移閉包（transitive closure）を実体化することである。実体化するとは、全ての推移関係が見出され、格納されることを意味する。推移関係とは、Ａ＝Ｂであり、かつＢ＝Ｃであるならば、Ａ＝Ｃであることを意味する。例えば、「エドナ・ヴァレー」６２４が「米国」６０６に存在するという知識を実体化するために用いられる推移関係は、（１）「エドナ・ヴァレー」６２４が「カリフォルニア」６１６に存在すること、及び（２）「カリフォルニア」６１６が「米国」６０６に存在すること、である。
【００６６】
このアプローチの問題点は、オントロジ内の全ての推移関係を前処理するには、全ての推移関係をたどり、次いでそれを格納しなければならないので、時間とストレージの両方に関してコストがかかる点である。さらに、一旦全ての推移閉包が実体化されると、オントロジ関係に対するどのような変更でも、実体化された推移関係には含まれていない大幅な変更を導入し得るので、オントロジの更新により多くのコストがかかることになる。
【００６７】
データベース管理者は、全ての推移関係を再処理するコストを負担すべきか、あるいは、まだ実体化されていないので問い合わせできない知識をオントロジ内に有することになるというジレンマに直面する。このように、オントロジの実体化は、動的な情報を含むオントロジを有するという目的を無効にし、オントロジを固定した関係のデータに降格する。
【００６８】
データ及びオントロジに問い合わせを行うためのフレームワークの作成
このように、純粋な関係データベース管理システムも、純粋なＸＭＬベース・アプローチも、いずれもデータ及びオントロジに問い合わせを行うことができるようにするためのフレームワークを容易に実装することはできない。データ及びオントロジを管理するためにデータベース管理システムを用いることの問題を解決するために、実施形態は、特定の情報をオントロジから抽出し、図３のＤＢＭＳ３０４のようなハイブリッド型関係−ＸＭＬデータベース管理システムを用いて、データ、オントロジ、及び抽出された情報を格納する。本フレームワークは、ユーザがオントロジ・ベースの意味論的クエリを表現し、処理することを可能にする。
【００６９】
オントロジ・ベースの意味論的クエリをサポートするために、関係データ管理システムは、関係フレームワーク内に知識表現を組み入れることができるように補強される。関係データベース管理システムを補強することで、データに問い合わせを行うのと同様の仕方で知識に問い合わせを行うことが可能になる。別の言い方をすれば、ユーザは従来の関係型クエリと同様のクエリを作成することができ、その結果、オントロジに基づく推論が得られる。
【００７０】
本フレームワークは、ユーザにデータ及び領域知識の両方の関係仮想ビューを提供し、ユーザがデータ及び領域知識に問い合わせを行うことを可能にする。関係仮想ビューは、図３の仮想ビュー３０６のような仮想ビューである。関係仮想ビューは、図３の基底表３０８のような関係表内にコード化されたデータが、図３のオントロジ・リポジトリ３１０のようなオントロジ・リポジトリ内に１つ又は複数のオントロジとしてコード化された領域知識とどのように関係するのかを指定することにより作成される。一旦このような方法でデータが領域知識と統合されると、データとオントロジとの間の関係に基づく推論のような、新たな知識を導出することができる。
【００７１】
仮想ビューは、ユーザがそれを通して、データ、領域知識、又は導出された知識に対してシームレス且つ統一された方式で問い合わせを行うことができるインターフェースである。仮想ビューを提供するために、実施形態は、オントロジ的情報を管理するためにオントロジ・リポジトリで補強された、ネイティブなＸＭＬのサポートが可能なデータベース管理システムを用いる。
【００７２】
データベース管理システムの中でオントロジが使えるようになる前に、オントロジのファイルは最初にオントロジ・リポジトリに登録される。次いで、オントロジ・ファイルは前処理されて、クエリ処理により適した表現にされる。クラス階層及び推移プロパティが抽出されてツリーにされ、含意は抽出されて含意グラフにされる。これらのツリー及び含意グラフはＸＭＬデータとしてコード化され、格納されて、仮想ビューを作成するために用いられる。一旦仮想ビューが作成されると、あたかもその仮想ビューが別の関係表であるかのように、ＳＱＬクエリを書き込み、実行することができる。
【００７３】
【表２】
2010517137.tif 000004
【００７４】
表２は、図３の仮想ビュー３０６のような仮想ビューを示し、この中で、表１は２つの仮想列、即ち「位置する（ｌｏｃａｔｅｄＩｎ）」及び「色を有する（ｈａｓＣｏｌｏｒ）」によって補強されている。仮想ビューは、基底表からの情報をオントロジから抽出された関連情報と並べて表示する。表２の初めの５つの列、即ち「ＩＤ」、「種類」、「原産地」、「製造者」、及び「価格」は、図３の基底表３０８のような基底表から取られる。２つの仮想列、即ち「位置する」及び「色を有する」は、図３のオントロジ・リポジトリ３１０のようなオントロジ・リポジトリに格納されている抽出されたオントロジ情報から取られる。
【００７５】
「位置する（ｌｏｃａｔｅｄＩｎ）」は、場所の集合｛ｙ１，ｙ２，．．．ｙｎ｝から成り、ここで原産地ｘの全てのワインについて、ｘはｙｉの下位地域（sub-region）である。例えば、ワイン「バーガンディ」はコート・ドール原産であり、コート・ドールはブルゴーニュの下位地域（サブクラス）であり、ブルゴーニュはフランスの下位地域である。このように、地域階層における推移関係をたどることにより、「バーガンディ」ワインについての「位置する」の値は、フランス国ブルゴーニュであることが見出される。
【００７６】
同様に、仮想列「色を有する（ｈａｓＣｏｌｏｒ）」が、ワインのオントロジから導かれる。オントロジは、例えば、
（種類＝ジンファンデル）＝＞（色を有する＝赤）
（種類＝リースリング）＝＞（色を有する＝白）
のような、含意規則の集合を含む。
【００７７】
記号「＝＞」は、「種類がジンファンデルのワインは、そのワインが赤色を有することを含意する」のように、記号「＝＞」の左辺（ＬＨＳ）が右辺（ＲＨＳ）を含意することを示す。記号「＝＞」は、「もしもあるワインの種類がジンファンデルであれば、そのワインは赤色を有する」のように、「もしも…ならば、…である」型の文として読むこともできる。従って、種類「ジンファンデル」のワインについて、「色を有する」の値は「赤」であることを導出することができる。
【００７８】
元の表である表１には、仮想列を幾つ追加してもよい。仮想ビューは、データ及びデータに関連付けられた領域知識の両方を組み入れる。しかしながら、これは仮想ビューであるので、仮想の列内の値はどれも実際には実体化されていない。その代わりに、仮想列内の値は、その値を導出する必要がある問い合わせが行われた場合にのみ、導出される（推論される）。
【００７９】
仮想ビューの目的は、（ａ）ユーザに、どの情報に問い合わせを行うことができるのかを示すこと、及び（ｂ）システムに、データと値を導出するのに必要なオントロジとの間の関係を提供することである。システムは、必要なときに、仮想列を用いて、生データとオントロジとからリアルタイムで値を導出することができる。データ及びオントロジの統一されたビューは、データ及びオントロジの両方を操作するクエリをユーザが作成することを比較的容易にする。
【００８０】
ここで図７を参照すると、例示的な実施形態を実施することができるデータベース・コマンドを示す図が示される。クエリ７０２は、図３の仮想ビュー３０６のような仮想ビューに対するクエリである。クエリ７０２は、データベース内の米国が原産である全てのワインを見出す。同様に、クエリ７０４は、仮想ビューに対するクエリであり、データベース内の全て赤ワインを見出す。
【００８１】
純粋な関係データベース的見地からすると、例えば、１つの場所が他の多くの場所の下位地域となり得るので、表２に示されたスキーマは関係型の通常の形式に違反しているように見える。例えば、所与のワインについて、「位置する（ｌｏｃａｔｅｄＩｎ）」の値の集合はワインの原産地に依存するので、「原産地」及び「位置する」という名称の２つの列を分離してそれら自身の表を作成することができるはずである。
【００８２】
しかしながら、表２は単なる仮想ビューなので、表２のスキーマは関係型の通常の形式に違反していてもよい。仮想ビューは、データベースのユーザが、データ及び領域知識に対してそれらがあたかも関係表に格納されているかのように問い合わせを行うことを可能にする。
【００８３】
例えば、各地域について全ての上位地域を集合として格納する「地域知識（地域、上位地域）」（ＲｅｇｉｏｎＫｎｏｗｌｅｄｇｅ（ｒｅｇｉｏｎ，ｓｕｐｅｒＲｅｇｉｏｓ））と呼ばれる「知識」表が存在すると仮定する。従って、（コート・ドール、｛ブルゴーニュ、フランス｝）はこの知識表のエントリの一例である。ユーザの視点からは、仮想ビューは、コマンド７０６に示されるようにワイン表を「知識」表と結合した結果のように見える。
【００８４】
コマンド７０６は実際には決してワイン表を知識表と結合するように実行されるわけではなく、仮想ビューがユーザに何を示すかを表していることに留意することが重要である。クエリが作成された時点でさえ、データとオントロジは決して互いに「結合」されるわけではないので、仮想ビューは実際にはシステム内に実体化された表として存在していない。ビューを作成するために用いられる「知識」表は実際には存在しないので、仮想ビューはこのように従来型のビューとは著しく異なる。
【００８５】
その代わりに、システムは、例えば、オントロジに対して推論を行うことにより、仮想列の値を基底表内の値からどのように導出するのかを理解する。オントロジに対して推論を行うとは、仮想ビューに対してクエリが発行されたときに仮想列の値が自動的に埋められることを意味する。仮想ビューを作成するプロセスは、システムに、仮想列のための値がどのように導出されるかについての情報を伝える。このことは、以下でより詳細に論じられる。
【００８６】
関係表とオントロジとを統合する
仮想ビューの根底にあるのは、データ及び関連付けられたオントロジである。データは関係表に格納されており、一方、オントロジはＸＭＬに格納されている。データとオントロジとは、互いに適切に関連付けられた場合、仮想ビューを通じて問い合わせることができ、推論の形で新たな知識を生成する。データとオントロジとは、データベース管理システムにおいて意味論的クエリをサポートするために用いられる、例示的な実施形態における言語拡張の１つである「ＣＲＥＡＴＥ  ＶＩＲＴＵＡＬ  ＶＩＥＷ」（仮想ビューを作成する）文を用いて関連付けられる。
【００８７】
ここで図８を参照すると、例示的な実施形態を実施することができる仮想ビュー・コマンドを示す図が示される。仮想ビュー・コマンド８００は、図３の基底表３０８のような基底表を図３のオントロジ・リポジトリ３１０のようなオントロジ・リポジトリ内のオントロジと統合した図３の仮想ビュー３０６のような仮想ビューを作成する。図８は、表２における仮想ビューが、表１及び関連付けられたオントロジからどのようにして作成されるのかを示す。
【００８８】
仮想ビュー３０６のような仮想ビューは、図３のＤＢＭＳ３０４のようなデータベース管理システムに登録される。ここで、行８０２において、「ＣＲＥＡＴＥ  ＶＩＲＴＵＡＬ  ＶＩＥＷ」は、仮想ビューである「ＷｉｎｅＶｉｅｗ」（ワイン・ビュー）をデータベース管理システムに登録するために用いられる。「ＣＲＥＡＴＥ  ＶＩＲＴＵＡＬ  ＶＩＥＷ」は、ワイン表をオントロジに関連付ける。仮想ビューが登録された後は、図３のユーザ３０２のようなユーザは、仮想ビューに対して、あたかもデータ及びオントロジが関係表の中に存在するかのように、クエリを発行することができる。
【００８９】
「ＣＲＥＡＴＥ  ＶＩＲＴＵＡＬ  ＶＩＥＷ」文は、ワイン表とオントロジとの間の結合演算の１つのタイプである。結合演算を理解する１つの方法は、オントロジ階層をオブジェクト指向プログラミング言語におけるクラス階層と見なし、結合演算を、新たなオブジェクトをインスタンス化するために関係表からのデータを用いることと見なすことである。
【００９０】
仮想ビュー「ＷｉｎｅＶｉｅｗ」（ワイン・ビュー）のソースは「Ｗｉｎｅ」（ワイン）表及び「ＷｉｎｅＯｎｔｏｌｏｇｙ」（ワイン・オントロジ）であり、それは行８０４の「ＦＲＯＭ」文節で指定される。行８０６の「ＷＨＥＲＥ」文節における制約条件が、ワイン表とワイン・オントロジとをどのように統合するかを指定する。行８０６における制約条件「Ｏ．ｏｂｊｅｃｔ＝Ｗ．ｔｙｐｅ」（Ｏ．オブジェクト＝Ｗ．種類）は、Ｗ．ｔｙｐｅの値を用いてオントロジ・オブジェクトをインスタンス化する。
【００９１】
例えば、表１の第１行は、種類がバーガンディのワインに関する。制約条件はＯ．ｏｂｊｅｃｔ＝’Ｂｕｒｇｕｎｄｙ’（Ｏ．オブジェクト＝「バーガンディ」）となる。行８０８において、Ｏ．ｏｂｊｅｃｔ．ｉｓＡ（’Ｗｉｎｅ’）（Ｏ．オブジェクトは（「ワイン」）である）は真であり、従って、行８０８は、新たにインスタンス化されたオブジェクトが「ワイン」クラスのインスタンスであることを必要とする。このことは、ワイン表の各行を、ワイン・オントロジ内のワイン（Ｗｉｎｅ）の１つのインスタンスにマッピングする。
【００９２】
行８１０は、ワイン表の「原産地（ｏｒｉｇｉｎ）」列が「バーガンディ」の「位置する（ｌｏｃａｔｅｄＩｎ）」属性（これは、クラス「事物（Ｔｈｉｎｇ）」から継承される）に対応することを指定する。行８１２は、「製造者（ｍａｋｅｒ）」列がそのワインの「製造者を有する（ｈａｓＭａｋｅｒ）」属性に対応することを指定する。「Ｏ．ｏｂｊｅｃｔ．ｈａｓＭａｋｅｒ」（Ｏ．オブジェクト．製造者を有する）は、「Ｏ．オブジェクト」が「ワイン」クラスのインスタンスである場合にのみ有意味であることに留意されたい。従って、「ＣＲＥＡＴＥ  ＶＩＲＴＵＡＬ  ＶＩＥＷ」文の結果は、関連付けられたオントロジから作成された２つの仮想列である「位置する（ＬｏｃａｔｅｄＩｎ）」及び「色を有する（ｈａｓＣｏｌｏｒ）」を含むスキーマである。
【００９３】
行８０２の中の「ＳＥＬＥＣＴ」（選択する）は３つのパラメータを有する。項目「Ｗ．＊」は、仮想ビューのスキーマが元のワイン表（表１）の全ての列（Ｉｄ、種類（Ｔｙｐｅ）、原産地（Ｏｒｉｇｉｎ）、製造者（Ｍａｋｅｒ）、価格（Ｐｒｉｃｅ））を含むことを示す。行８０２内の「ＴＣ（Ｏ．ｏｂｊｅｃｔ．ｌｏｃａｔｅｄＩｎ，’ｓｕｂＲｅｇｉｏｎ’」（ＴＣ（Ｏ．オブジェクト．位置する、「下位地域」））は、推移閉包（transitive closure）関数ＴＣによってその値が計算される別の仮想列を指定する。推移閉包関数は、場所のオントロジ内の「下位地域（ｓｕｂＲｅｇｉｏｎ）」関係に沿って地域を上方に拡張し、その結果、行８０２内の「Ｏ．ｏｂｊｅｃｔ．ｌｏｃａｔｅｄＩｎ」（Ｏ．オブジェクト．位置する）によって指定される地域を含む場所の集合を与える。
【００９４】
行８０２内の項目「Ｏ．ｏｂｊｅｃｔ．ｈａｓＣｏｌｏｒ」（Ｏ．オブジェクト．色を有する）は、オントロジ内のワイン・オブジェクトの属性又はプロパティに基づく仮想列を指定する。属性値は、クエリが作成された時点でのオントロジ規則を用いて導出される。仮想ビューの登録は、関係表の値とオントロジの値との間のマッピングを作成し、システムが仮想ビューに対するクエリについての知識推論を実行できるようにする。
【００９５】
オントロジは、図３のオントロジ・リポジトリ３１０のようなオントロジ・リポジトリ内に半構造化データとして格納される。上述のように、従来型の関係データベース管理システムは半構造化データを直接扱うことができない。本フレームワークは、図３のＤＢＭＳ３０４のようなハイブリッド型関係−ＸＭＬデータベース管理システムを用いて、オントロジの物理レベルでのサポートを提供する。ＸＭＬは現在、データの検索及び交換の標準規格なので、幾つかの関係データベース管理システムは、現在では、ネイティブな形式のＸＭＬデータをサポートする。例えば、International Business Machines（ＩＢＭ）のＤＢ２（商標）ユニバーサル・データベース（Universal Database）は、ＸＭＬデータのためのネイティブなサポートを提供する。
【００９６】
本フレームワークは、既存の関係データベース管理システムが以下の４つのコンポーネントを用いて拡張された、ＩＢＭのＤＢ２（商標）のようなハイブリッド型関係−ＸＭＬデータベース管理システムを用いる。第１に、ＸＭＬドキュメントをＸクエリ・データ・モデル（XQuery Data Model）（ＱＤＭ）のインスタンスとして、即ち、構造化された型あり(typed)の二分木として格納することできるように、ネイティブなＸＭＬのストレージを提供するために、図３のオントロジ・リポジトリ３１０のようなオントロジ・リポジトリが追加される。第２に、構造的索引、値索引、及び全文索引を含む、ＸＭＬデータのための新たな索引タイプが作成される。第３に、ＸＱｕｅｒｙ及びＳＱＬを用いて構築されるクエリを処理するために、図３の仮想ビュー・クエリ・プロセッサ３１２のようなハイブリッド型クエリ・プロセッサが追加される。第４に、ＸＱｕｅｒｙ及びＳＱＬ／Ｘ演算子をサポートするために、図３のクエリ・エンジン３１４のような補強されたクエリ・エンジンが追加される。
【００９７】
ハイブリッド型関係−ＸＭＬデータベース管理システムにおいては、ＸＭＬが基本データ型としてサポートされる。ユーザは、１つ又は複数のＸＭＬ型の列を有する表を作成することができる。ＸＭＬドキュメントの集積は、従って、表における列として定義することができる。
【００９８】
ここで図９を参照すると、例示的な実施形態を実施することができるハイブリッド型関係−ＸＭＬデータベースに対するコマンドが示される。行９０２はユーザがハイブリッド型関係−ＸＭＬデータベースと共に用いることが可能な表「ＣｌａｓｓＨｉｅｒａｒｃｈｙ」（クラス階層）を作成するためのコマンドを示す。行９０４は、ユーザが用いることが可能なＸＭＬドキュメントを表に挿入するためのサンプル・コードを示す。ＸＭＬドキュメントは構文解析され、ネイティブなＸＭＬストレージ内に配置され、索引付けされる。ＳＱＬ／Ｘ関数である「ＸＭＬＰａｒｓｅ」を用いて、ＸＭＬドキュメントを表に挿入する。
【００９９】
ユーザはＳＱＬ／Ｘクエリを発行することにより、関係列とＸＭＬ列とにまとめて問い合わせすることができる。行９０６は、「ＸＰａｔｈ／Ｗｉｎｅ／ＤｅｓｓｅｒｔＷｉｎｅ／ＳｗｅｅｔＲｉｅｓｌｉｎｇ」（Ｘパス／ワイン／デザートワイン／甘口リースリング）を含む全てのクラス階層のクラスＩｄ及びクラス名を戻すクエリの一例である。
【０１００】
「ＸＭＬＥｘｉｓｔｓ」は、ＸＭＬ値に対してＸパス表現を評価するＳＱＬ／Ｘブール関数である。Ｘパスが「空でない」ノードのシーケンスを戻す場合には「ＸＭＬＥｘｉｓｔｓ」は真であり、そうでない場合には偽である。
【０１０１】
オントロジ・リポジトリ
データベース管理システムにおいてオントロジをサポートするために、ＤＢＭＳ３０４のようなデータベース管理システムは、図３のオントロジ・リポジトリ３１０のようなオントロジ・リポジトリで補強される。オントロジ・リポジトリは、１つ又は複数のオントロジに関連付けられた情報の集積から構成され、このオントロジは、ユーザがオントロジ・リポジトリに登録したものである。
【０１０２】
ユーザの視点からすると、オントロジ・リポジトリは、１つ又は複数のオントロジ・ファイルと、それに対応する識別子（ｏｎｔＩＤ）とを含む。オントロジ・リポジトリはまた、オントロジ・ファイルのためのストレージ・システムであることのほかに、オントロジ関係の処理の複雑さの大部分をユーザの目から見えないようにする。
【０１０３】
ここで図１０を参照すると、例示的な実施形態を実施することができるユーザとオントロジ・リポジトリとの対話を示すブロック図が示される。ユーザとオントロジ・リポジトリとの対話１０００において、ユーザ１００２は、１つ又は複数のオントロジ・ファイル１００４及び１つのオントロジ識別子１００６をオントロジ・リポジトリ１００８に提供する。オントロジ・リポジトリ１００８は、図３のオントロジ・リポジトリ３１０の一例である。
【０１０４】
オントロジ・プロセッサ１０１０は、ユーザが後でその特定のオントロジを参照できるように、オントロジ・ファイル１００４をオントロジ識別子１００６に対して登録する。１つの特定のオントロジ識別子に対して１つより多くのオントロジ・ファイルを登録することができる。各オントロジが一意のオントロジ識別子を有するようにして、オントロジの複数の集合を登録することができる。オントロジ・プロセッサ１０１０は、オントロジ・ファイル１００４に対して、クエリ処理を容易にするためにオントロジから種々の情報を抽出することを含む種々の操作を実行する。
【０１０５】
例えば、オントロジ・プロセッサ１０１０は、オントロジ・ファイル１００４から、オントロジのクラス階層１０１２、推移プロパティ１０１４、及び含意グラフ１０１６を抽出することができる。クラス階層１０１２、推移プロパティ１０１４、及び含意グラフ１０１６は、オントロジ・リポジトリ１００８内に格納される。オントロジ・プロセッサ１０１０は、例えば特定のクエリ型をサポートするために、又はクエリ処理を最適化するために、付加的な情報を抽出することができる。オントロジ・プロセッサ１０１０は、抽出した情報をオントロジ・リポジトリ１００８内に格納する。オントロジ・プロセッサ１０１０は、元のファイルであるオントロジ・ファイル１００４をオントロジ・リポジトリ１００８内に格納することもできる。
【０１０６】
ここで図１１を参照すると、例示的な実施形態を実施することができる、抽出された情報を示すブロック図が示される。抽出された情報１１００は、抽出され、図１０のオントロジ・リポジトリ１００８のようなオントロジ・リポジトリに格納されることができる、３種類のオントロジ情報の一例を示す。
【０１０７】
ここでは、３種類の抽出された情報は、オントロジ・リポジトリ内の３つの表、即ち「オントロジ・ドキュメント（ＯｎｔｏｌｏｇｙＤｏｃｓ）」１１０２、「オントロジ情報（ＯｎｔｏｌｏｇｙＩｎｆｏ）」１１０４、「推移プロパティ（ＴｒａｎｓｉｔｉｖｅＰｒｏｐｅｒｔｙ）」１１０６に格納される。「オントロジ・ドキュメント」１１０２の表は、ユーザが登録した元のオントロジ・ファイルのコピーを格納する。「オントロジ情報」１１０４及び「推移プロパティ」１１０６の表は、オントロジ・ファイルから抽出された付加的情報を格納する。各表のフィールドのうちの幾つかは、ドキュメント又は抽出された情報のＸＭＬ表現へのポインタを収容することができる。
【０１０８】
ここでは、抽出されたオントロジ情報は、説明の目的で表に格納された状態で示されている。当業者であれば、抽出されたオントロジ情報を格納するために、表と同じ目的を果たす任意の型式のデータ構造を用いることができることが理解される。
【０１０９】
表「オントロジ情報（ＯｎｔｏｌｏｇｙＩｎｆｏ）」１１０４は、オントロジ識別子「ｏｎｄＩＤ」１１０８、クラス１１０８、及び含意１１１２といった種々のフィールドを含むことができる。ここで、クラス１１１０はオントロジ内の各クラスに対する情報を含み、一方、含意１１１２は、各クラスに関連付けられた含意についての情報を含むフィールドを有する。
【０１１０】
同様に、「推移プロパティ（ＴｒａｎｓｉｔｉｖｅＰｒｏｐｅｒｔｙ）」１１０６は、オントロジ識別子「ｏｎｔＩＤ」１１１４、プロパティ識別子「ｐｒｏｐＩＤ」１１１６、及びツリー１１１８を含む種々のフィールドを有する。「ｐｒｏｐＩＤ」１１１６は、各プロパティについての情報を含み、一方、ツリー１１１８は、オントロジ内の推移プロパティのうちの１つのＸＭＬツリー表現へのポインタを収容するフィールドである。
【０１１１】
次のセクションは、どのようにユーザが図１０のオントロジ・リポジトリ１００８のようなオントロジ・リポジトリにオントロジを登録し、又はそこからオントロジを除去する（取り下げる）ことができるか、及びどのように図１０のオントロジ・プロセッサ１０１０がオントロジ・ファイルからクラス階層、推移プロパティ、及び含意グラフなどの種々の情報を抽出するかを説明する。実施例は、ウェブ・オントロジ言語（web ontology language）（ＯＷＬ）ファイルとしてコード化されたオントロジを用いるが、様々な実施形態は、いずれかの特定のオントロジ言語を用いてコード化されたオントロジに限定されるものではないことを理解されたい。
【０１１２】
オントロジ・リポジトリは、ユーザに、オントロジ・ファイルを管理するためのユーザ・インターフェースを提供する。ユーザは、各々の一意のオントロジを識別するために一意のオントロジ識別子（ｏｎｔＩＤ）を供給する。各オントロジはコード化されて、１つ又は複数のオントロジ・ファイルにされることができる。オントロジ・リポジトリのインターフェースは、ユーザが、１つ又は複数のオントロジ・ファイルを１つのオントロジの一部として登録すること、及び１つのオントロジに関連付けられた１つ又は複数のファイルを消去することを可能にするができるようにする。
【０１１３】
例えば、オントロジ・リポジトリのためのユーザ・インターフェースは、ユーザが一意の識別子を用いてオントロジ・ファイルを登録できるようにする手順である「ｒｅｇｉｓｔｅｒＯｎｔｏｌｏｇｙ（ｏｎｔｉｄ，ｏｎｔｏｌｏｇｙ＿Ｆｉｌｅ）」を提供することができる。論理オントロジが幾つかのオントロジ・ファイルから構成される場合、ユーザは、そのオントロジ内の各ファイルについて、同一のｏｎｔＩＤで登録手順を呼び出すことができる。同一のｏｎｔＩＤで登録された全てのオントロジ・ファイルは、クラス階層、推移プロパティ、及び含意グラフの抽出のために内部で互いにグループ化される。リポジトリ内の登録済みオントロジを除去するには、オントロジ取り下げ手順である「ｄｒｏｐＯｎｔｏｌｏｇｙ（ｏｎｔｉｄ）」を用いて、指定されたオントロジＩＤに関連付けられたオントロジ・ファイル及び抽出情報ファイルを削除することができる。
【０１１４】
一旦ユーザが１つのオントロジに関連付けられた全てのファイルを登録し終わったら、オントロジ・ファイルは構文解析され、クラス階層、推移プロパティ、及び含意グラフのような種々の情報の断片が抽出される。抽出された情報の断片は、クエリの書き直し及び処理を容易にするために用いられる。
【０１１５】
クラス階層
以下、オントロジからどのようにクラス階層を抽出することができるかを説明する。クラス階層を指定するサブクラス関係は、ウェブ・オントロジ言語（ＯＷＬ）を用いて幾つかの異なった方式で表現することができる。その上、捕捉されたサブクラス階層は、必ずしも互いに素である必要はない。クラス階層は、図１０のオントロジ・プロセッサ１０１０のようなオントロジ・プロセッサによってオントロジ・ファイルから抽出され、図１０のオントロジ・リポジトリ１００８のようなオントロジ・リポジトリ内に格納される。
【０１１６】
ここで図１２を参照すると、「ワイン（Ｗｉｎｅ）」クラス階層を構築するためのコードの例が示される。行１２０２は、ウェブ・オントロジ言語を用いた「ｓｕｂＣｌａｓｓＯｆ」構文でサブクラスを明示的に指定することにより、どのように「ワイン」クラス階層を構築することができるかの例を提示する。
【０１１７】
ここで図１３を参照すると、クラス及びサンプル・コードのブロック図が示される。第１に、「ワイン」クラス階層が抽出され、これは、最初は図において１３０２で示されるように「デザートワイン（ＤｅｓｓｅｒｔＷｉｎｅ）」１３０４を「ワイン（Ｗｉｎｅ）」１３０６のサブクラスとして表現される。
【０１１８】
第２に、サブクラス関係は、制限を用いて暗黙的に指定される。例えば、行１３０８のウェブ・オントロジ言語のフラグメントを考察すると、ここで、「白ワイン（ＷｈｉｔｅＷｉｎｅ）」クラスは、その「色を有する（ｈａｓＣｏｌｏｒ）」属性が値「白（ｗｈｉｔｅ）」を有する全てのワインであることが定義されている。
【０１１９】
行１３０８における定義は、「ワイン」と「白ワイン」との間のサブクラス関係を含意しているので、ここで、図１３の１３１０に示されるように、対応するエッジをクラス階層に追加することができ、「デザートワイン」１３１２及び「白ワイン」１３１４が「ワイン」１３１６のサブクラスとされる。
【０１２０】
第３に、サブクラス関係は、例えば共通集合（intersection）演算子又は和集合（union)演算子といった二項集合（binary set）関係を用いて表現される。行１３１８は、「バーガンディ白（ＷｈｉｔｅＢｕｒｇｕｎｄｙ）」が「バーガンディ（Ｂｕｒｇｕｎｄｙ）」と「白ワイン（ＷｈｉｔｅＷｉｎｅ）」との共通集合として定義されるウェブ・オントロジ言語の一例を示す。従って、「バーガンディ白」は「バーガンディ」及び「白ワイン」の両方のサブクラスであり、ここで、クラス階層は、クラス階層１３２０で示されるように表示される。クラス階層１３２０において、「バーガンディ白」１３２２は「バーガンディ」１３２４のサブクラスであり、「バーガンディ白」１３２６は「白ワイン」１３２８のサブクラスであり、「バーガンディ」１３２４及び「白ワイン」１３２８は両方とも「ワイン」１３３０のサブクラスである。
【０１２１】
クラス階層１３２０のような階層図において、「ワイン」１３３０のような各クラスはノードと呼ばれ、一方、クラスとサブクラスとの間の線はエッジと呼ばれる。例えば、「バーガンディ」１３２４と「バーガンディ白」１３２２の間の線はエッジである。
【０１２２】
この表現において、各ノードはクラスを表し、一方、各エッジは「サブクラスである（ｓｕｂｃｌａｓｓ−ｏｆ）」関係を表す。「サブクラスである」関係は推移的であるので、従って、クラス階層においてＡ→Ｂ→Ｃが存在するならば、所与のインスタンスｘについて、以下の包摂文、即ち（ｘ∈Ａ）＝＞（ｘ∈Ｂ）＝＞（ｘ∈Ｃ）が成立する。
【０１２３】
例えば、ここで「バーガンディ白」１３２２は「バーガンディ」１３２４のサブクラスであり、「バーガンディ」１３２４は「ワイン」１３３０のサブクラスであるので、従って、「バーガンディ白」１３２２は、推移的に「ワイン」１３３０のサブクラスである。さらに、「バーガンディ白」１３２２のいずれのサブクラスも常に「ワイン」１３３０のサブクラスとなる。
【０１２４】
推移プロパティ
クラス階層の他に、図１０のオントロジ・プロセッサ１０１０のようなオントロジ・プロセッサはまた、クエリの書き直し及び処理を容易にするために、オントロジから推移関係を抽出し、その推移関係をツリーの形式で格納する。推移プロパティは、典型的にはＸＭＬ形式で図１０のオントロジ・リポジトリ１００８のようなオントロジ・リポジトリ内に格納される。
【０１２５】
ここで図１４を参照すると、「ワイン」オントロジの推移プロパティを指定するためのコードの一例が示される。コード・セグメント１４０２は、二項関係（ｏｗｌ：ＯｂｊｅｃｔＰｒｏｐｅｒｔｙ）が推移的であることを指定するためのウェブ・オントロジ言語（ＯＷＬ）コードの一例である。この例において、「位置する（ｌｏｃａｔｅｄＩｎ）」プロパティは「事物（Ｔｈｉｎｇ）」クラスを「地域（Ｒｅｇｉｏｎ）」クラスに関連付けるものであり、推移的であると定義される。
推移的であるとは、
ｌｏｃａｔｅｄＩｎ（ａ，ｂ）∧ｌｏｃａｔｅｄＩｎ（ｂ，ｃ）＝＞ｌｏｃａｔｅｄＩｎ（ａ，ｃ）
を意味する。
【０１２６】
抽出中に、一旦オントロジ・プロセッサが「位置する（ｌｏｃａｔｅｄＩｎ）」プロパティが推移的であることを発見すると、そのプロパティの全てのインスタンスがスキャンされ、抽出された情報からツリー又はフォレストが構築される。例えば、コード・セグメント１４０４は、「位置する（ｌｏｃａｔｅｄＩｎ）」プロパティの抽出されたインスタンスを示す。コード・セグメント１４０４のプロパティに基づき、推移ツリー１４０６を構築することができる。ここで、全ての内部ノードは「地域（Ｒｅｇｉｏｎ）」クラスのインスタンスでなければならない。リーフ・ノードは単に「事物（Ｔｈｉｎｇ）」クラスのインスタンスであればよい。全てのエッジは、「位置する（ｌｏｃａｔｅｄＩｎ）」プロパティの推移性による包摂を表す。
【０１２７】
含意
図１０のオントロジ・プロセッサ１０１０のようなオントロジ・プロセッサはまた、オントロジから、Ａ＝＞Ｂといった規則の形で含意も抽出する。含意規則は、含意グラフの形で格納される。含意グラフは、図１０のオントロジ・リポジトリ１００８のようなオントロジ・リポジトリ内に格納される。含意グラフは、データ及びオントロジから知識を推論することを可能にする。
【０１２８】
重要な含意のタイプは、クラス包摂である。推移ツリーを用いて、クラス包摂に関係する含意を捕捉することができる。クラス包摂以外の含意は、クラスの帰属関係又は推移関係による包摂を伴わない一般的含意（general implication）である。
【０１２９】
一般的含意には３種類がある。即ち、複合的（complex）含意、連言的（論理積）（conjunctive)含意、及び選言的（論理和）（disjunctive)含意である。オントロジ・リポジトリは、オントロジ内の全ての一般的含意について、含意グラフを構築し、格納する。含意グラフは、クエリの処理中に、クエリを書き直すために用いられる。
【０１３０】
複合的含意
複合的含意は、左辺（ＬＨＳ）が文節の連言又は選言となる含意である。例として以下のウェブ・オントロジ言語・フラグメント取り上げるが、ここで、記号＜＝＞は等価性を示す。
（ｘ∈ＷｈｉｔｅＷｉｎｅ）＜＝＞（ｘ∈Ｗｉｎｅ）∧（ｘ．ｈａｓＣｏｌｏｒ＝Ｗｈｉｔｅ）
この例において、左辺が２つの文節（ｘ∈Ｗｉｎｅ）及び（ｘ．ｈａｓＣｏｌｏｒ＝Ｗｈｉｔｅ）の連言なので、最終的な含意は複合的含意である。
【０１３１】
連言的含意
ここで図１５を参照すると、連言的含意の一例が示される。連言的含意は、右辺（ＲＨＳ）が文節の連言となる含意である。連言的含意は、図１０のオントロジ・プロセッサ１０１０のようなオントロジ・プロセッサによって抽出され、図１０のオントロジ・リポジトリ１００８のようなオントロジ・リポジトリ内に格納される、含意グラフの一部とすることができる。
【０１３２】
コード・セグメント１５０２において、「ジンファンデル（Ｚｉｎｆａｎｄｅｌ）」クラスの全てのインスタンスは、「色を有する（ｈａｓＣｏｌｏｒ）」プロパティが値「赤（ｒｅｄ）」を取る全てのワインのサブクラスにも属し、「糖分を有する（ｈａｓＳｕｇａｒ）」プロパティが値「辛口（ｄｒｙ）」を取る全てのワインのサブクラスにも属し、即ち
（ｘ∈Ｚｉｎｆａｎｄｅｌ）＝＞［（ｘ．ｈａｓＣｏｌｏｒ＝Ｒｅｄ）∧（ｘ．ｈａｓＳｕｇａｒ＝Ｄｒｙ）］
「ワインｘがジンファンデルであれば、ワインｘは赤であり、且つワインｘは辛口である」である。連言的含意の１つの重要な性質は、それが単純な含意の連言に分解できることである。
【０１３３】
例えば、上記の連言的含意は、以下のように分解できる。
［（ｘ∈Ｚｉｎｆａｎｄｅｌ）＝＞（ｘ．ｈａｓＣｏｌｏｒ＝Ｒｅｄ）］
∧［（ｘ∈Ｚｉｎｆａｎｄｅｌ）＝＞（ｘ．ｈａｓＳｕｇａｒ＝Ｄｒｙ）］、
即ち、「ワインｘがジンファンデルであれば、ワインｘは赤であり、且つ、ワインｘがジンファンデルであれば、ワインｘは辛口である」。連言的含意を単純な含意の連言に分解することにより、連言的含意を、全てが連言によって結合された単純な含意の集積として処理することができる。
【０１３４】
選言的含意
選言的含意は、図１０のオントロジ・プロセッサ１０１０のようなオントロジ・プロセッサによって抽出され、図１０のオントロジ・リポジトリ１００８のようなオントロジ・リポジトリ内に格納される、含意グラフの一部とすることができる。選言的含意は、右辺（ＲＨＳ）が文節の選言となる含意規則である。
【０１３５】
ここで図１６を参照すると、選言的含意の一例が示される。コード・セグメント１６０２は、含意規則、
（ｘ∈Ｚｉｎｆａｎｄｅｌ）＝＞（ｘ．ｈａｓＢｏｄｙ＝Ｆｕｌｌ）∨（ｘ．ｈａｓＢｏｄｙ＝Ｍｅｄｉｕｍ）
「ワインｘがジンファンデルであれば、ワインｘはフルボディであるか、又はワインｘはミディアムボディである」
をウェブ・オントロジ言語（ＯＷＬ）でどのようにコード化することができるかを示す。
【０１３６】
含意グラフ
含意グラフは、図１０のオントロジ・プロセッサ１０１０のようなオントロジ・プロセッサによって抽出され、図１０のオントロジ・リポジトリ１００８のようなオントロジ・リポジトリ内に格納される。含意グラフは、２種類の頂点、即ち文節及び演算子、並びに２種類のエッジ、即ち含意及びオペランドから成る有向グラフである。文節頂点は、「ｘ．ｈａｓＢｏｄｙ＝Ｍｅｄｉｕｍ」のような、真の値を有する文節を表す。演算子頂点は、連言演算子又は選言演算子を表す。
【０１３７】
演算子頂点はまた、その演算子頂点が連言又は選言を介して互いに結合させる文節頂点に依存する真の値にも関連付けられる。含意エッジは頂点間の含意関係を表す。オペランド・エッジは文節頂点を演算子頂点に関連付ける。
【０１３８】
ここで図１７を参照すると、例示的な実施形態の含意グラフのブロック図が示される。オントロジに関する含意グラフは、空の含意グラフで開始され、次いで全ての含意についてオントロジ・ファイルをスキャンすることによって構築される。図１７において、含意グラフ１７０２は、含意の集合１７０４のグラフ表現である。
【０１３９】
オントロジから含意規則を抽出する際に、オントロジ・プロセッサは、クラス階層及び推移プロパティに関連付けられる含意をフィルタリングで除外し、一般的含意のみを残す。次に、オントロジ・プロセッサは、一般的含意の各々を通して反復し、含意を複合的、連言的、又は選言的のいずれかとして分類する。含意が連言的であれば、連言的含意は単純な含意の集合へとさらに分解される。最後に、含意グラフに、現行の含意に対応する頂点及びエッジが挿入される。
【０１４０】
クラス階層、推移プロパティ、及び含意グラフは、オントロジから抽出され、次いで、拡張マークアップ言語（eXtended Markup Language）（ＸＭＬ）へとシリアル化され、図１０のオントロジ・リポジトリ１０１０のようなオントロジ・リポジトリ内に格納される。シリアル化とは、オブジェクトをストレージ媒体上に保存するプロセスである。クラス階層及び推移プロパティは全て、包摂関係をツリー・データ構造の形で含む。クエリ処理コンポーネントは包摂チェックに関してＸパスに依拠するので、ツリー・データは、ツリー構造をＸＭＬ内で保持するような方式でシリアル化される。
【０１４１】
ここで図１８を参照すると、クラス階層の一例が示される。ツリー１８０２をコード化してＸＭＬコード１８０４にすることができる。含意グラフをシリアル化する場合には、包摂テストは必要とはされないので、グラフをコード化してＸＭＬにするための任意の標準的方法を用いることができる。
【０１４２】
ここで図１９を参照すると、例示的な実施形態を実施することができるオントロジ・プロセッサの流れ図が示される。図１０のオントロジ・プロセッサ１０１０のようなオントロジ・プロセッサは、最初に１つ又は複数のオントロジ・ファイル及び１つのオントロジ識別子を受け取る（ステップ１９０２）。
【０１４３】
オントロジ・プロセッサは、オントロジ・ファイルをオントロジ識別子と共に登録する（ステップ１９０４）。オントロジ・プロセッサは、オントロジ・ファイルからクラス階層構造（単数又は複数）を抽出し、格納する（ステップ１９０６）。オントロジ・プロセッサは、オントロジ・ファイルから推移プロパティを抽出し、格納する（ステップ１９０８）。オントロジ・プロセッサは、オントロジ・ファイルから含意グラフを抽出し、格納する（ステップ１９１０）。
【０１４４】
典型的には、オントロジ・プロセッサは、ステップ１９０６、ステップ１９０８、及びステップ１９１０で抽出したクラス階層構造、推移プロパティ、及び含意グラフを、それぞれ、図１１における「オントロジ・ドキュメント（ＯｎｔｏｌｏｇｙＤｏｃｓ）」１１０２、「オントロジ情報（ＯｎｔｏｌｏｇｙＩｎｆｏ）」１１０４、及び「含意プロパティ（ＴｒａｎｓｉｔｉｖｅＰｒｏｐｅｒｔｙ）」１１０６のような、表とＸＭＬデータとの組み合わせとして格納する。
【０１４５】
ここで図２０を参照すると、例示的な実施形態を実施することができる、クラス階層を抽出するための流れ図が示される。図４において示されるクラス階層のようなクラス階層がオントロジから抽出される（ステップ２００２）。サブクラス関係は、制限を用いて指定される（ステップ２００４）。サブクラス関係は、共通集合演算子及び和集合演算子のような二項集合関係を用いて指定される（ステップ２００６）。
【０１４６】
ここで図２１を参照すると、例示的な実施形態を実施することができる、推移プロパティを抽出するための流れ図が示される。図６において示された推移プロパティのような推移プロパティがオントロジから抽出される（ステップ２１０２）。その推移プロパティの全てのインスタンスを求めて、オントロジがスキャンされる（ステップ２１０４）。オントロジの推移プロパティを示すために、推移ツリーが構築される（ステップ２１０６）。
【０１４７】
ここで図２２を参照すると、例示的な実施形態を実施することができる、含意グラフを構築するための流れ図が示される。開始点として空の含意グラフが用いられる（ステップ２２０２）。
【０１４８】
含意について、オントロジがスキャンされる（ステップ２２０４）。クラス階層及び推移プロパティに関連付けられる含意はフィルタリングで除外され、その結果、一般的含意のみが残される（ステップ２２０６）。一般的含意のうちの１つが選択される（ステップ２２０８）。その含意は、複合的、連言的、又は選言的として分類される（ステップ２２１０）。
【０１４９】
「はい、含意は連言的である」と判断された場合には（ステップ２２１２）、その含意は単純な含意の集合に分解される（ステップ２２１４）。「いいえ、含意は連言的ではない」と判断された場合（ステップ２２１２）、又は含意が単純な含意の集合に分解された後で（２２１４）、含意グラフに、現行の含意に対応する頂点及びエッジが挿入される（ステップ２２１６）。さらなる含意が存在する場合には（ステップ２２１８）、別の一般的含意が選択される（ステップ２２０８）。それ以上の含意が存在しない場合には（ステップ２２１８）、操作は終了する。
【０１５０】
ここで図２３を参照すると、例示的な実施形態を実施することができる、ワイン製品の基底表及び関連付けられたワインのオントロジが示される。ワイン製品の基底表及び関連付けられたワイン・オントロジ２３００において、ワイン表２３０２はワイン・オントロジ２３０４に関連付けられる。
【０１５１】
ワイン表２３０２をワイン・オントロジ２３０４に関連付ける１つの方法は、ワイン表２３０２の列の名称がワイン・オントロジ２３０４において用いられるプロパティの名称と一致するように保証することである。列の名称はまた、関係属性としても知られる。
【０１５２】
ワイン表２３０２をワイン・オントロジ２３０４に関連付ける別の方法は、ユーザが、ワイン・オントロジ２３０４内の関連付けられるプロパティに対する関係属性のマッピングを提供することである。ワイン表２３０２からの各行がオントロジ内の１つのエンティティに関連付けられる。
【０１５３】
上記の２つの技法を組み合わせることもできる。例えば、ワイン表２３０２の幾つかの列の名称をワイン・オントロジ２３０４内で用いられるプロパティの名称と同じ名称にし、一方、ワイン表２３０２の残りの列は、オントロジ内の関連付けられるプロパティに対する関係属性のマッピングを提供することにより、ワイン・オントロジ２３０４に関連付けることができる。
【０１５４】
図２３において、ワイン表２３０２の各行２３０６、２３０８、及び２３１０は、エンティティ「ワイン」クラスの１つのインスタンスに関連付けられる。例えば、矢印２３１２は、行２３０６内の種類「バーガンディ（Ｂｕｒｇｕｎｄｙ）」がクラス階層における「ワイン」のクラス「バーガンディ（Ｂｕｒｇｕｎｄｙ）」に関連付けられることを示す。
【０１５５】
同様に、ワイン表２３０２の列２３１６、２３１８、及び２３２２を、ワイン・オントロジ２３０４内のプロパティに関連付けることができる。例えば、列２３１８の「原産地（ｏｒｉｇｉｎ）」属性は、ワイン・オントロジ２３０４のプロパティ「位置する（ｌｏｃａｔｅｄＩｎ）」２３２６に関連付けられる。列２３２０の「製造者（ｍａｋｅｒ）」属性は、ワイン・オントロジ２３０４のプロパティ「製造者を有する（ｈａｓＭａｋｅｒ）」２３２８プロパティに関連付けられる。
【０１５６】
クエリの処理
クエリ・プロセッサは基底表の全ての列についてクエリの述語を評価し、その述語を満たす行（単数又は複数）を戻す。各述語は、１つ又は複数の行を基底表から排除する。ある行がある述語を満たしていないとクエリ・プロセッサが判断した場合には、クエリ・プロセッサは、基底表内の次の行に移る。典型的には、述語評価は直進的である。着目する値を基底表内の各行から逐次的に抽出し、述語に対して評価して、その述語が満たされるか否かが判断される。
【０１５７】
ここで図２４を参照すると、例示的な実施形態を実施することができる、プロセッサの流れ図が示される。図３の仮想ビュー・クエリ・プロセッサ３１２のようなクエリ・プロセッサが、ユーザからクエリを受け取る。クエリ・プロセッサは、図３のクエリ・エンジン３１４のような関係−ｘｍｌハイブリッド型データベースによってクエリが処理できるように、そのクエリを書き直す。
【０１５８】
図３の基底表３０８のような基底表に含まれるデータを用いてクエリに回答することができる場合には、クエリは従来通りに処理され、即ち、クエリは関係データベースに対するクエリとして処理される。しかしながら、クエリがオントロジを用いた推論を必要とする場合には、クエリ・プロセッサはクエリを書き直す。図２４は、クエリ・プロセッサがクエリを書き直す場合に行うステップを示す。
【０１５９】
基底表に存在しない属性に関与する述語を含むクエリが与えられると、そのクエリは２段階で書き直される。第１に、クエリ述語が、含意グラフを用いて拡張される（ステップ２４０２−ステップ２４０８）。第２に、各文節が、包摂チェックを含むように書き直される（ステップ２４１０−ステップ２４１４）。
【０１６０】
クエリを書き直すプロセスは、合致するサブグラフ（matching sub-graph）を求めて含意グラフを探索することから開始する（ステップ２４０２）。図１７の含意グラフ１７０２は、含意グラフの一例である。クエリ述語は単一の文節で構成されてもよく、又は複数の文節で構成されてもよい。
【０１６１】
ステップ２４０２におけるクエリ述語が単一の文節ｑで構成される場合には、含意グラフはｑについての頂点を求めて探索される。次いで、クエリ述語は以下のように書き直される。ｑについての頂点から、全ての従属節、即ち全ての頂点がグラフから数え上げられ、クエリ述語は、元の述語とその従属節の全てとの選言として書き直される（ステップ２４０４）。
【０１６２】
ステップ２４０２におけるクエリ述語が選言又は連言によって結合された複数の文節で構成される場合には、合致するサブグラフの集積を求めて含意グラフを探索する。各々の合致するサブグラフごとに、そのサブグラフから開始して含意グラフを探査し、全ての従属節が検索される（ステップ２４０４）。
【０１６３】
一旦合致するサブグラフの全ての従属節を数え上げたら、どの頂点を以前に探査したかを把握しておき、重複する探査を削除することにより、重複する従属節はいずれも排除される（ステップ２４０６）。
【０１６４】
一旦サブグラフが処理されると、クエリ・プロセッサは別のマッチング・サブグラフが存在するかどうかをチェックする（ステップ２４０８）。答えが「はい」であり、別のサブグラフが存在する場合には、クエリ・プロセッサは元に戻り、全てのサブグラフが処理されるまで、その前のステップ（ステップ２４０４及びステップ２４０６）を繰り返す。答えが「いいえ」であり、それ以上のサブグラフが存在しない場合には、述語は、その述語自身と全ての従属節との選言として書き直される（ステップ２４１０）。
【０１６５】
次に、拡張された述語内の各従属節は、包摂述語を用いて書き直される。クエリの拡張の後では、クエリ述語は複数の文節のブール表現である。各文節は、その文節が包摂関係を含むか否かを判定するために検査される。文節が包摂関係を有する場合には、その文節は包摂述語を含むように書き直される（ステップ２４１２）。
【０１６６】
拡張されたクエリ内に別の文節が存在する場合には、その前のステップ（ステップ２４１４）が繰り返される。それ以上の文節が存在しない場合には、プロセスは終了する。
【０１６７】
ここで図２５を参照すると、例示的な実施形態を実施することができるクエリの一例が示される。クエリ２５０２に関して、オントロジからの２つの関連した含意が含意２５０４である。含意２５０４を用いてクエリ２５０２を拡張して、拡張されたクエリ２５０６とすることができる。
【０１６８】
拡張の後で、各文節は関連付けられた包摂が存在するか否かを判定するために検査され、包摂が存在する場合には、その文節は書き直される。包摂チェックを実行するための１つの方法は、「Ｘｐａｔｈ」とＳＱＬ／ＸＭＬ関数「ＸＭＬＥｘｉｓｔｓ」を用いることによるものである。
【０１６９】
ここで図２６を参照すると、例示的な実施形態を実施することができるクエリの一例が示される。クエリ２６０２は、「ｌｏｃａｔｅｄＩｎ（位置する）」が「Ｗ．ｏｒｉｇｉｎ（Ｗ．原産地）」の推移閉包から作成される仮想列である表２に対するクエリである。クエリ２６０２は、クエリ２６０４として書き直すことができる。
【０１７０】
クエリ２６０４において、「ＸＭＬＥｘｉｓｔｓ（Ｔ．ｔｒｅｅ／／ＵＳＲｅｇｉｏｎ／／Ｗ．ｏｒｉｇｉｎ）」（ＸＭＬＥｘｉｓｔｓ（Ｔ．ツリー／／米国地域／／Ｗ．原産地））は、「Ｘｐａｔｈ」及びＳＱＬ／ＸＭＬ関数「ＸＭＬＥｘｉｓｔｓ」を用いて包摂チェックを実行する。言うまでもないが、当業者であれば、ＳＱＬ／ＸＭＬ関数「ＸＭＬＥｘｉｓｔｓ」の代わりに、包摂チェックを実行する他の同様の方法を用いることができることを理解する。
【０１７１】
ここで図２７を参照すると、例示的な実施形態を実施することができるクエリの一例が示される。再び表２を参照すると、クエリ２７０２は、表２に対するクエリである。オントロジの含意グラフが「ｈａｓＣｏｌｏｒ＝ｒｅｄ」（色を有する＝赤）に関連した含意２７０４を含むと仮定する。また、クラス階層２７０６がオントロジのクラス階層の一部であることも仮定する。
【０１７２】
クエリ述語は「ｈａｓＣｏｌｏｒ（色を有する）」に対する拘束条件を含み、「ｈａｓＣｏｌｏｒ（色を有する）」は基底表に存在しない仮想列であり、従って、クエリは含意２７０４を用いて拡張され、拡張されたクエリ２７０８が作成される。種類の属性「Ｂ．ｔｙｐｅ（Ｂ．種類）」はオントロジ内の再帰型階層に関連付けられるので、包摂チェックが適用され、書き直されたクエリ２７１０が作成される。
【０１７３】
関係−ＸＭＬ混成データベースを用いて、書き直されたクエリ２７１０を表２上で処理すると、「コート・ドール（ＣｏｒｔｓＤＯｒ）」に関する行は、それが「赤ワイン（ＲｅｄＷｉｎｅ）」なのでクエリを満たし、「ジンファンデル（Ｚｉｎｆａｎｄｅｌ）」に関する行もまたクエリを満たすことになる。クラス階層はＸＭＬツリーとしてコード化されているので、「ｉｓＳｕｂｓｕｍｅｄ（）」関数は、ＳＱＬ／ＸＭＬ関数「ＸＭＬＥｘｉｓｔｓ」を用いて実行される。
【０１７４】
このようにして、ユーザは、従来型の関係クエリと同様のオントロジ・ベースのクエリを構築し、これに回答させることができる。上述のような方式でユーザのクエリを書き直すことにより、そして、オントロジから抽出される含意、推移プロパティ、及びクラス階層構造といった情報を用いることにより、ユーザのクエリを用いて、関係基底表に存在しない知識を推論することが可能である。
【０１７５】
様々な実施形態は、データベース内のデータに問い合わせするための方法、装置、及びコンピュータ・プログラム製品を提供する。データにオントロジが関連付けられる。リクエスタからのクエリの受け取りに応答して、クエリを用いてデータベース内の関係データが識別され、識別済み関係データが形成される。識別済み関係データ及びオントロジを用いて、オントロジ内のオントロジ的知識が識別される。結果はリクエスタに戻される。
【０１７６】
図面内のフローチャート及びブロック図は、種々の実施形態による幾つかの可能なシステム、方法、及びコンピュータ・プログラム製品の実装のアーキテクチャ、機能、及び操作を例示する。この点に関して、フローチャート又はブロック図における各ブロックは、指定された論理関数（単数又は複数）を実施するための１つ又は複数の実行可能な命令を含むモジュール、セグメント、又はコードの一部を表し得る。また、幾つかの代替的な実施形態において、ブロック内に表記された関数は、図面に表記された順序と異なる順序で行われ得ることに留意されたい。例えば、連続して示された２つのブロックは、それに伴う機能応じて、実際には、実質的に同時に実行されてもよく、又はブロックが逆の順序で実行されることもある。
【０１７７】
本発明は、全体がハードウェアである実施形態、全体がソフトウェアである実施形態、又はハードウェア要素とソフトウェア要素の両方を含む実施形態の形態を取ることができる。好ましい実施形態において、本発明は、ファームウェア、常駐ソフトウェア、マイクロコードなどを含むがこれらに限定されないソフトウェアに実装される。
【０１７８】
さらに、本発明は、コンピュータ又は何らかの命令実行システムによって又はそれらに接続して使用されるためのプログラム・コードを提供するコンピュータ使用可能媒体又はコンピュータ可読媒体からアクセス可能なコンピュータ・プログラム製品の形態を取ることができる。この説明の目的上、コンピュータ使用可能媒体又はコンピュータ可読媒体は、命令実行システム、装置若しくはデバイスによって使用されるための、又はそれらに接続して使用されるためのプログラムを収容し、格納し、伝達し、伝播し、又は輸送することができる、任意の有形の装置であり得る。
【０１７９】
媒体は、電子的、磁気的、光学的、電磁気的、赤外線的若しくは半導体的システム（又は装置若しくはデバイス）、又は伝搬媒体とすることができる。コンピュータ可読媒体の例として、半導体又は固体メモリ、磁気テープ、取り外し可能なコンピュータ・ディスケット、ランダム・アクセス・メモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、硬質磁気ディスク、及び光ディスクが挙げられる。光ディスクの現在の例として、コンパクトディスク−読み取り専用メモリ（ＣＤ−ＲＯＭ）、コンパクトディスク−読み取り／書き込み（ＣＤ−Ｒ／Ｗ）、及びＤＶＤが挙げられる。
【０１８０】
プログラム・コードを格納及び／又は実行するのに適したデータ処理システムは、システム・バスを経由してメモリ要素に直接的又は間接的に連結された少なくとも１つのプロセッサを含む。メモリ要素は、プログラム・コードの実際の実行中に用いられるローカル・メモリ、大容量記憶装置、及び実行中に大容量記憶装置からコードを取得しなければならない回数を減らすために少なくとも一部のプログラム・コードを一時的に格納するキャッシュ・メモリを含むことができる。
【０１８１】
入力／出力デバイス即ちＩ／Ｏデバイス（キーボード、ディスプレイ、ポインティング・デバイスなどを含むがこれらに限定されない）は、システムに、直接的に又は介在するＩ／Ｏコントローラを通じて結合することができる。
【０１８２】
データ処理システムが介在する私設ネットワーク又は公衆ネットワークを通じて他のデータ処理システム又は遠隔プリンタ若しくは記憶装置と連結できるようにするために、ネットワーク・アダプタをシステムに連結することもできる。モデム、ケーブル・モデム及びイーサネット・カードは、現在利用可能なネットワーク・アダプタのタイプのうちのごく一部である。
【０１８３】
本発明の説明は例示及び説明の目的で提示されており、網羅的であることも、開示された形態の発明に限定されることも、意図していない。当業者であれば、多くの変更及び変形は明らかである。これらの実施形態は、本発明の原理及び実際的な用途を最も良く説明するため、また他の当業者が、意図される特定の用途に適した種々の変更を伴う種々の実施形態について本発明を理解することを可能にするために、選択され、説明された。
【符号の説明】
【０１８４】
１００：ネットワーク型データ処理システム
１０２：ネットワーク
１０４、１０６：サーバ
１０８：ストレージ・ユニット
１１０、１１２、１１４：クライアント
２００：データ処理システム
３００：ユーザとデータベース管理システム（ＤＢＭＳ）との対話
３０４：データベース管理システム（ＤＢＭＳ）
３１０、１００８：オントロジ・リポジトリ
４００、１３０２、１３１０、１３２０：ワイン・オントロジにおけるクラス階層
５００：ワイン・オントロジにおける規則
６００：「位置する（ｌｏｃａｔｅｄＩｎ）」プロパティに関するクラス階層
８００：仮想ビュー・コマンド
１０００：ユーザとオントロジ・リポジトリとの対話
１１００：抽出された情報
１７０２：含意グラフ
１７０４：含意の集合
２３０２：ワイン表
２３０４：ワイン・オントロジ
【図１】
2010517137.tif 000005
【図２】
2010517137.tif 000006
【図３】
2010517137.tif 000007
2010517137.tif 000008
【図４】
2010517137.tif 000009
【図５】
2010517137.tif 000010
【図６】
2010517137.tif 000011
【図７】
2010517137.tif 000012
【図８】
2010517137.tif 000013
【図９】
2010517137.tif 000014
【図１０】
2010517137.tif 000015
【図１１】
2010517137.tif 000016
【図１２】
2010517137.tif 000017
【図１３】
2010517137.tif 000018
【図１４】
2010517137.tif 000019
【図１５】
2010517137.tif 000020
【図１６】
2010517137.tif 000021
【図１７】
2010517137.tif 000022
【図１８】
2010517137.tif 000023
【図１９】
2010517137.tif 000024
【図２０】
2010517137.tif 000025
【図２１】
2010517137.tif 000026
【図２２】
2010517137.tif 000027
【図２３】
2010517137.tif 000028
【図２４】
2010517137.tif 000029
【図２５】
2010517137.tif 000030
【図２６】
2010517137.tif 000031
【図２７】
2010517137.tif 000032
【手続補正書】
【提出日】平成21年12月25日(2009.12.25)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
データベース内のデータに問い合わせするための、コンピュータで実行される方法であって、
前記データベース内の前記データにオントロジを関連付けるステップと、
前記オントロジから含意を抽出して含意グラフを作成するステップと、
前記データベース内の前記データのクエリを受け取るステップであって、前記クエリがクエリ述語を含むステップと、
前記データベース内の前記データの前記クエリを受け取る前記ステップに応答して、前記含意グラフを用いて、修正済みクエリを形成するように前記クエリ述語を拡張するステップであって、前記修正済みクエリが、前記含意グラフに従って前記クエリ述語の１つ又は複数の従属節を含むステップと、
包摂チェックを含むように前記修正済みクエリを書き直すステップと、
を含む、コンピュータで実行される方法。
【請求項２】
前記データベース内の前記修正済みクエリを処理するステップをさらに含み、前記修正済みクエリの処理は、前記データ及び前記オントロジから知識を推論する、
請求項１に記載のコンピュータで実行される方法。
【請求項３】
含意を用いてクエリ述語を拡張する前記ステップは、
前記クエリ述語が前記含意グラフ内のある含意に合致するとの判断に基づいて、前記含意を前記クエリに付加することによって前記クエリ述語を拡張するステップ
を含む、請求項１に記載のコンピュータで実行される方法。
【請求項４】
包摂チェックを含むように前記修正済みクエリを書き直す前記ステップは、
前記１つ又は複数の文節が関連付けられた包摂階層を前記オントロジ内に有するか否かを判定するために前記１つ又は複数の文節を検査するステップと、
前記１つ又は複数の文節の中のある文節が関連付けられた包摂階層を有するという判断に基づいて、修正済み文節を形成するように前記文節を書き直すステップであって、前記修正済み文節が包摂チェックを実行するための包摂述語を含む、ステップと
を含む、請求項１に記載のコンピュータで実行される方法。
【請求項５】
前記包摂述語は、拡張マークアップ言語の値を用いて、拡張マークアップ言語パス表現を評価する、請求項４に記載のコンピュータで実行される方法。
【請求項６】
前記データベースは、関係表を用いて前記データを格納し、拡張マークアップ言語を用いて前記オントロジを格納する、請求項１に記載のコンピュータで実行される方法。
【請求項７】
データベース内のデータに問い合わせするためのコンピュータ・プログラムであって、該プログラムが、コンピュータに、
前記データベース内の前記データにオントロジを関連付けるための機能と、
前記オントロジから含意を抽出して含意グラフを作成するための機能と、
前記データベース内の前記データのクエリを受け取るための機能であって、前記クエリがクエリ述語を含む、機能と、
前記データベース内の前記データの前記クエリの受け取りに応答して、前記含意グラフを用いて、修正済みクエリを形成するように前記クエリ述語を拡張するための機能であって、前記修正済みクエリが、前記含意グラフに従って前記クエリ述語の１つ又は複数の従属節を含む、機能と、
包摂チェックを含むように前記修正済みクエリを書き直すための機能と
を実現させる、コンピュータ・プログラム。
【請求項８】
前記データベース内の前記修正済みクエリを処理するための機能をさらに含み、前記修正済みクエリの処理は、前記データ及び前記オントロジから知識を推論する、請求項７に記載のコンピュータ・プログラム。
【請求項９】
含意を用いてクエリ述語を拡張するための前記機能は、
前記クエリ述語が前記含意グラフ内のある含意に合致するとの判断に基づいて、前記含意を前記クエリに付加することによって前記クエリ述語を拡張するための機能を含む、請求項７に記載のコンピュータ・プログラム。
【請求項１０】
包摂チェックを含むように前記修正済みクエリを書き直すための前記機能は、
前記１つ又は複数の文節が関連付けられた包摂階層を前記オントロジ内に有するか否かを判定するために前記１つ又は複数の文節を検査する機能と、
前記１つ又は複数の文節の中のある文節が関連付けられた包摂階層を有するという判断に基づいて、修正済み文節を形成するように前記文節を書き直すための機能であって、前記修正済み文節が包摂チェックを実行するための包摂述語を含む、機能と
を含む、請求項７に記載のコンピュータ・プログラム。
【請求項１１】
前記包摂述語は、拡張マークアップ言語の値を用いて、拡張マークアップ言語パス表現を評価する、請求項１０に記載のコンピュータ・プログラム。
【請求項１２】
前記データベースは、関係表を用いて前記データを格納し、拡張マークアップ言語を用いて前記オントロジを格納する、請求項７に記載のコンピュータ・プログラム。
【請求項１３】
データベース内のデータに問い合わせするためのデータベース管理システムであって、
バスと、
前記バスに接続されたストレージ装置であって、コンピュータ使用可能コード及び前記データを収容するストレージ装置と、
前記バスに接続された通信ユニットと、
前記バスに接続された、前記コンピュータ使用可能コードを実行するための処理ユニットと
を備え、前記処理ユニットは、前記データベース内の前記データにオントロジを関連付け、前記オントロジから含意を抽出して含意グラフを形成し、前記データベース内の前記データのクエリを受け取り、前記クエリはクエリ述語を含み、前記処理ユニットは、前記データベース内の前記データの前記クエリの受け取りに応答して、前記含意グラフを用いて修正済みクエリを形成するように前記クエリ述語を拡張し、前記修正済みクエリは前記含意グラフに従って前記クエリ述語の１つ又は複数の従属節を含み、前記処理ユニットは、包摂チェックを含むように前記修正済みクエリを書き直す、データベース管理システム。
【請求項１４】
前記処理ユニットは、前記データベース内の前記修正済みクエリを処理し、前記データ及び前記オントロジから知識を推論する、請求項１３に記載のデータベース管理システム。
【請求項１５】
前記処理ユニットは、前記クエリ述語が前記含意グラフ内の含意に合致することを判断することにより前記クエリ述語を拡張し、前記含意を前記クエリに付加することにより前記クエリ述語を拡張する、請求項１３に記載のデータベース管理システム。
【請求項１６】
前記処理ユニットは、前記１つ又は複数の文節が関連付けられた包摂階層を前記オントロジ内に有するか否かを判定するために前記１つ又は複数の文節を検査することにより、包摂チェックを含むように前記修正済みクエリを書き直し、前記１つ又は複数の文節の中の文節が関連付けられた包摂階層を有するという判断に基づいて、修正済み文節を形成するように前記文節を書き直し、前記修正済み文節は、包摂チェックを実行するための包摂述語を含む、請求項１３に記載のデータベース管理システム。
【請求項１７】
前記包摂述語は、拡張マークアップ言語の値を用いて、拡張マークアップ言語パス表現を評価する、請求項１６に記載のデータベース管理システム。
【国際調査報告】
2010517137.tif 000033