(57)【要約】【課題】  データの変更が容易であり、かつ、高速検索が可能なデータベースを構築するための情報処理技術を提供する。【解決手段】  属性データベース（１０４〜１０８）及び関係性データベース（１０３）と接続される情報処理装置（１２０）であって、スキーマを解析し、第１のノードのラベルと第２のノードのラベルとの関係性を保持するためのテーブルを生成する手段と、第１のノードの識別子と第２のノードの識別子との接続が定義されたデータを解析し、前記生成されたテーブルにおいて、該識別子をエントリする手段と、を備え、属性データベース（１０４〜１０８）または関係性データベース（１０３）に対して、指定されたラベルについて所定の処理を実行するよう指示があった場合、前記識別子がエントリされたテーブルを用いて、該所定の処理を実行することを特徴とする。【選択図】  図１
2013142983.tif 000002
【特許請求の範囲】
【請求項１】
ノードの属性情報を保存する属性データベース、及び、ノード間の関係性に関する情報を保存する関係性データベースと接続される情報処理装置であって、
第１のノードのラベルと、第２のノードのラベルと、該第１のノードと該第２のノードとを接続する辺のラベルと、が複数定義されたスキーマを解析し、該第１のノードのラベルと該第２のノードのラベルとの関係性を保持するためのテーブルを生成するスキーマ解析手段と、
前記第１のノードの識別子と前記第２のノードの識別子との接続が定義されたデータを解析し、前記生成されたテーブルにおいて、前記第１のノードのラベルと前記第２のノードのラベルとに対応づけて、該識別子をエントリするラベル解析手段と、を備え、
前記属性データベースまたは前記関係性データベースに対して、指定されたラベルについて所定の処理を実行するよう指示があった場合、前記識別子がエントリされたテーブルを用いて、該所定の処理を実行することを特徴とする情報処理装置。
【請求項２】
前記ノードのラベルと、複数の前記属性データベースのうち、該ノードの属性情報を保存する属性データベースを示す情報と、を対応づける接続情報を保持する保持手段を更に備え、
前記属性データベースに対して所定の処理を実行するよう指示があった場合、前記接続情報を用いることにより、前記複数の属性データベースのうちの、前記所定の処理を実行する属性データベースに対してアクセスすることを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記関係性データベースに対して追加の処理を実行するよう指示があった場合、該指示に含まれる前記第１のノードのラベル及び識別子と、前記第２のノードのラベル及び識別子とを取得し、該取得したラベルに対応する前記テーブルに、該取得した識別子をエントリすることを特徴とする請求項１に記載の情報処理装置。
【請求項４】
前記属性データベースに対して検索の処理を実行するよう指示があった場合、該指示に含まれるノードのラベルを取得し、前記テーブルに基づいて特定された、該取得したラベルに対応する識別子の属性情報について、前記検索の処理を実行することを特徴とする請求項１に記載の情報処理装置。
【請求項５】
前記保持手段に保持された接続情報に対して、前記第１のノードのラベルをキーとして、アクセスすべき属性データベースを検索することを特徴とする請求項２に記載の情報処理装置。
【請求項６】
請求項１乃至５のいずれか１項に記載の情報処理装置と接続される情報検索装置であって、
前記情報処理装置に対して前記所定の処理を実行するよう指示を行うためのメッセージを作成する作成手段と、
前記作成したメッセージを送信するとともに、前記指示に基づいて前記情報処理装置において実行された前記所定の処理の結果を受信する送受信手段と
を備えることを特徴とする情報検索装置。
【請求項７】
コンピュータを、請求項１乃至５のいずれか１項に記載の情報処理装置の各手段として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データベースを管理する情報処理装置及びそのプログラム、ならびに、該データベースに対する処理を該情報処理装置に実行させる際のユーザインタフェースとして機能する情報検索装置に関する。
【背景技術】
【０００２】
現実世界の情報を仮想世界にマッピングするためには、デバイスの所有情報、人間関係情報など、各種情報を管理する必要がある。このような情報の多くは、グラフ形式のデータで簡単に表現することができる。
【０００３】
一方で、データを管理する技術として、従来よりリレーショナルデータベースが知られている。リレーショナルデータベースによれば、形式が固定されたデータの検索、追加、削除、更新（以下では、これらをまとめて“所定の処理”ともいう）を行うことができる。しかしながら、リレーショナルデータベースの場合、新たな対象物との間の関係性を示すデータを追加するにあたり、正規化処理などの処理を含むデータベースの再構築を行うことが必要となってくる。
【０００４】
一方、このような問題を解決する技術として、例えば、ノード間の関係性（ラベル付き有向グラフ）をディレクトリツリー構造として保存する技術が知られている（例えば、特許文献１参照）。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００８−１０２７３６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、上記特許文献１に開示された技術の場合、ノードの識別子という概念がないため、ラベルの型のノードであっても、ノードに付与された識別子であっても、全てラベルとして認識し、保存していた。
【０００７】
一般に、ディレクトリツリー構造にて保存されたデータを検索する場合、ツリー構造に沿って所定の処理が行われるため、ラベルの数の増加に伴い、処理時間も増加する。このため、上記特許文献１の場合、高速な処理が困難であるという問題を内在している。更に、上記特許文献１の場合、そもそも、ディレクトリツリー構造として表現できない関係性については、保存することができないといった問題も有する。
【０００８】
本発明は、上記課題に鑑みてなされたものであり、任意の関係性を有するデータを保存することができ、かつ、所定の処理を高速に実行可能なデータベースを構築するための情報処理技術を提供することを目的とする。
【課題を解決するための手段】
【０００９】
上記の目的を達成するために、本発明に係る情報処理装置は、例えば、以下のような構成を備える。即ち、
ノードの属性情報を保存する属性データベース、及び、ノード間の関係性に関する情報を保存する関係性データベースと接続される情報処理装置であって、
第１のノードのラベルと、第２のノードのラベルと、該第１のノードと該第２のノードとを接続する辺のラベルと、が複数定義されたスキーマを解析し、該第１のノードのラベルと該第２のノードのラベルとの関係性を保持するためのテーブルを生成するスキーマ解析手段と、
前記第１のノードの識別子と前記第２のノードの識別子との接続が定義されたデータを解析し、前記生成されたテーブルにおいて、前記第１のノードのラベルと前記第２のノードのラベルとに対応づけて、該識別子をエントリするラベル解析手段と、を備え、
前記属性データベースまたは前記関係性データベースに対して、指定されたラベルについて所定の処理を実行するよう指示があった場合、前記識別子がエントリされたテーブルに基づいてノードを特定し、該所定の処理を実行することを特徴とする。
【発明の効果】
【００１０】
本発明によれば、任意の関係性を有するデータを保存することができ、かつ、所定の処理を高速に実行可能なデータベースを構築することが可能となる。
【図面の簡単な説明】
【００１１】
【図１】第１の実施形態に係る情報処理システム１００の構成を示す図である。
【図２】第１の実施形態に係る情報処理装置１２０のモジュール構成を示す図である。
【図３】第１の実施形態に係る情報検索装置１３０のモジュール構成を示す図である。
【図４】スキーマ解析部において解析されるスキーマの一部を、ＸＭＬ及びラベル付き有向グラフで示した図である。
【図５】スキーマ解析部において解析されるスキーマの全体を、ＸＭＬ及びラベル付き有向グラフで示した図である。
【図６】スキーマの解析結果を用いて生成されたテーブルであって、関係性データベース（関係性ＤＢ）に格納されるテーブルの一例を示す図である。
【図７】ラベル解析部において解析されるノード間の関係性を、ＸＭＬで示した図である。
【図８】ラベル解析部において解析されるノード間の関係性を、ラベル付き有向グラフで示した図である。
【図９】ラベルの解析結果を用いて生成されたテーブルであって、関係性ＤＢに格納されるテーブルの一例を示す図である。
【図１０】属性データベース（属性ＤＢ）の接続情報を示すテーブルである。
【図１１】情報処理システム１００におけるＤＢ検索処理の流れを示すシーケンス図である。
【図１２】情報処理装置１２０におけるＤＢ検索処理の流れを示すフローチャートである。
【図１３】情報処理システム１００におけるＤＢ追加処理の流れを示すシーケンス図である。
【図１４】情報処理装置１２０におけるＤＢ追加処理の流れを示すフローチャートである。
【図１５】ノード間の関係性が追加された、関係性ＤＢに格納されるテーブルを示した図である。
【図１６】第２の実施形態に係る情報処理システム１６００の構成を示す図である。
【図１７】関係性ＤＢと属性ＤＢとの関連を表した図である。
【図１８】第３の実施形態に係る情報処理システム１８００の構成を示す図である。
【図１９】関係性ＤＢａにおいて管理される第一のノード間の関係性、及び、関係性ＤＢｂにおいて管理される第二のノード間の関係性を示す図である。
【図２０】情報処理システム１８００におけるＤＢ追加処理の流れを示すシーケンス図である。
【図２１】スキーマ解析部において解析されるスキーマの一部を、ＸＭＬおよびラベル付きグラフで示した図である。
【図２２】スキーマ解析部において解析されるスキーマの全体を、ＸＭＬで示した図である。
【図２３】スキーマ解析部において解析されるスキーマの全体を、ラベル付きグラフで示した図である。
【図２４】スキーマの解析結果を用いて生成されたテーブルであって、関係性ＤＢに格納されるテーブルについて、図６との差異を示した図である。
【図２５】ラベル解析部において解析されるノード間の関係性を、ＸＭＬで示した図である。
【図２６】ラベル解析部において解析されるノード間の関係性を、ラベル付きグラフで示した図である。
【発明を実施するための形態】
【００１２】
以下、本発明の各実施形態について、図面を参照しながら詳細に説明する。
【００１３】
［第１の実施形態］
＜１．情報処理システムの構成＞
図１は、第１の実施形態に係る情報処理システム１００の構成を示す図である。図１において、１１０は、多様なネットワークの集合体のインターネットである。なお、１１０は、インターネットに限られず、ＷＡＮ（Ｗｉｄｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）、ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）、あるいは、それらの複合体であってもよい。また、１１０はネットワークである必要はなく、バスであってもよい。
【００１４】
１２０は、ノード間の関係性を示す情報およびノードの属性情報の検索・追加・削除・更新（これらをまとめて“所定の処理”ともいう）を行う情報処理装置である。情報処理装置１２０は、情報検索装置１３０から送信される、ノード間の関係性を示す情報およびノードの属性情報の検索・追加・削除・更新の要求を受理し、関係性ＤＢおよび属性ＤＢの制御を行い、情報検索装置１３０に対して、所定の処理結果の返答を行う。
【００１５】
なお、情報検索装置１３０からの要求は、検索・追加・削除・更新に限られず、これらのうちの複数を組み合わせたものであってもよい。また、検索・追加・削除・更新以外の処理の要求であってもよい。
【００１６】
１３０は、情報処理装置１２０に対して、ノード間の関係性を示す情報およびノードの属性情報の検索・追加・削除・更新の要求を行うとともに、情報処理装置１２０からの返答内容を処理する情報検索装置である。
【００１７】
１０３は、ノード間の関係性を示す情報を管理する関係性データベース（関係性ＤＢ）である。本実施形態において関係性ＤＢは、リレーショナルデータベースを用いて実現するものとするが、本発明はこれに限られず、ＸＭＬデータベースやその他の構造化されたデータを取り扱うことができるデータベースを用いて実現してもよい。関係性ＤＢ１０３は、情報処理装置１２０と、ネットワークを介して接続される。なお、関係性ＤＢ１０３と情報処理装置１２０との接続方法は、これに限られず、バスを介して接続されてもよい。
【００１８】
１０４〜１０８は、ノードの属性情報を管理する属性データベース（属性ＤＢ）である。属性ＤＢは、識別子（ＩＤ）に対して属性情報を取得できるデータベースであればよい。本実施形態では、ｋｅｙ−ｖａｌｕｅ型データベース、ＤＨＴ（Ｄｉｓｔｒｉｂｕｔｅｄ  Ｈａｓｈ  Ｔａｂｌｅ）、ＬＤＡＰ（Ｌｉｇｈｔｗｅｉｇｈｔ  Ｄｉｒｅｃｔｏｒｙ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ）によるディレクトリサービスを用いるものとする。ただし、本発明はこれに限られず、ＩＤから属性情報を取得できる他のデータベースや当該データベースに類似する技術であってもよい。
【００１９】
属性ＤＢａ１０４は、グループの属性情報を管理する。属性ＤＢｂ１０５は、ユーザの属性情報を管理する。属性ＤＢｃ１０６は、デバイスの属性情報を管理する。属性ＤＢｄ１０７は、サービスの属性情報を管理する。属性Ｄｂｅ１０８は、コンテンツの属性情報を管理する。なお、属性ＤＢ（１０４〜１０８）は、情報処理装置１２０と、ネットワークを介して接続される。ただし、属性ＤＢ（１０４〜１０８）と情報処理装置１２０との接続方法は、これに限られず、バスを介して接続されてもよい。
【００２０】
＜２．情報処理装置のモジュール構成＞
図２は、第１の実施形態に係る情報処理装置１２０のモジュール構成を示す図である。図２において、２００は、各モジュール間を接続するバスである。２０１は、情報検索装置１３０との間でメッセージの送受信を行ったり、関係性ＤＢ１０３や属性ＤＢ（１０４〜１０８）との間でメッセージの送受信を行ったりするためのメッセージ送受信部である。
【００２１】
２０２は、インターネット１１０を介して、情報検索装置１３０と通信を行う通信制御部である。なお、本実施形態において、通信制御部２０２ではＴＣＰ／ＩＰ処理を行うものとするが、これに限られるものではない。また、情報処理装置１２０が関係性ＤＢ１０３および属性ＤＢ（１０４〜１０８）とネットワークを介して接続されている場合にあっては、通信制御部２０２は、更に、各ＤＢとの通信も行う。
【００２２】
２０３は、メッセージ送受信部２０１で受信したメッセージの解析を行うメッセージ解析部である。２０４は、関係性ＤＢ１０３に対してノード間の関係性を示す情報の検索・追加・削除・更新といった制御を行う関係性ＤＢ制御部である。
【００２３】
２０５は、ラベル付き有向グラフのノードのラベルおよび辺のラベルを処理するラベル解析部である。２０６は、属性ＤＢ（１０４〜１０８）に対して、ノードの属性情報の検索・追加・削除・更新といった制御を行う属性ＤＢ制御部である。
【００２４】
２０７は、ラベル付き有向グラフで示されるスキーマを理解し、関係性ＤＢと結びつける処理を行うスキーマ解析部である。なお、本実施形態では、以下、ラベル付き有向グラフをＸＭＬやグラフを用いて表現するが、本発明はこれに限られず、グラフ記述言語（ＧｒａｐｈＭＬ、ＤＯＴ）等により表現してもよい。
【００２５】
２０８は、属性ＤＢ（１０４〜１０８）へアクセスするためのアクセス方法を、ノードのラベルに含まれる名前に基づいて取得する属性データベース情報取得部である。
【００２６】
２０９は、スキーマ解析部２０７における解析結果をテーブルとして保存する関係解決部である。関係解決部２０９では、当該テーブルを用いて、メッセージ解析部２０３における解析結果に対応するエントリの有無を判断する。
【００２７】
＜３．情報検索装置のモジュール構成＞
図３は、第１の実施形態に係る情報検索装置１３０のモジュール構成を示す図である。３０１は、情報処理装置１２０との間で、メッセージの送受信を行うメッセージ送受信部である。３０２は、インターネット１１０を介して、情報処理装置１２０と通信を行う通信制御部である。なお、本実施形態において、通信制御部３０２では、ＴＣＰ／ＩＰ処理を行うものとする。
【００２８】
３０３は、メッセージ送受信部３０１より送信すべきメッセージを作成するメッセージ作成部である。３０４は、ラベル付き有向グラフのノードのラベルおよび辺のラベルを処理するラベル処理部である。３０５は、情報処理装置１２０に送信する属性情報の処理、および、情報処理装置１２０から受信した属性情報の処理を行う属性情報処理部である。
【００２９】
＜４．情報処理装置の主なモジュールの詳細機能＞
次に、情報処理装置１２０を構成する各モジュールのうちの、主なモジュール（スキーマ解析部、ラベル解析部、属性データベース情報取得部、属性ＤＢ制御部）の詳細機能について説明する。
【００３０】
＜４．１  スキーマ解析部＞
（１）スキーマ解析部において解析されるスキーマについて
はじめに、スキーマ解析部２０７において解析されるスキーマについて説明する。図４は、スキーマ解析部２０７において解析されるスキーマの一部を、ＸＭＬおよびラベル付き有向グラフで示した図である。
【００３１】
図４において、４０１は、ラベル付き有向グラフにおける、ノード間の接続を示す。４０１は、ＸＭＬの場合、＜ＬａｂｅｌｅｄＧｒａｐｈ＞のタグで示される。
【００３２】
４０２は、ノードのラベルに“ユーザ”という名前が付与された開始ノード（第１のノード）である。開始ノード４０２は、ＸＭＬの場合、＜Ｓｎｏｄｅ＞のタグで示される。４０３は、辺のラベルに“保持”という関係が付与された開始ノード４０２と終了ノード（第２のノード）４０４との関係性を示している。関係性４０３は、ＸＭＬの場合、＜Ｒｅｌａｔｅ＞で示される。
【００３３】
４０４は、ノードのラベルに“デバイス”という名前が付与された終了ノードである。終了ノード４０４は、ＸＭＬの場合、＜Ｅｎｏｄｅ＞で示される。
【００３４】
図５（Ａ）は、スキーマ解析部２０７において解析されるスキーマの全体を、ＸＭＬで示した図である。図５（Ａ）において、５０１はスキーマ全体を示す。５０２は、図４の参照番号４０１で示したスキーマの一部である。
【００３５】
このように、ノード間の関係性を連続して複数定義することで、スキーマ全体をＸＭＬで示すことができる。また、＜Ｒｅｌａｔｉｏｎ＞の開始タグと終了タグで囲うことで、一つのラベル付き有向グラフであることを表現することができる。
【００３６】
図５（Ｂ）は、スキーマ解析部２０７において解析されるスキーマの全体を、ラベル付き有向グラフで示した図である。図５（Ｂ）において、５１１はスキーマ全体を示している。５１２は、図４の参照番号４０１で示したスキーマの一部である。ノードのラベルに同じ名前が付与されている場合は、同じノードであるとして扱うことで、連続した有向を表現することができる。
【００３７】
なお、本実施形態では、スキーマを、ＸＭＬ及びラベル付き有向グラフで示したが、本発明はこれに限らず、グラフを表現可能な他の言語や他の記述方法によって示してもよい。
（２）スキーマ解析部２０７における解析内容
次に、スキーマ解析部２０７における解析内容について説明する。スキーマ解析部２０７では、図５（Ａ）および（Ｂ）で示したスキーマの解析を行う。また、解析結果に応じて、関係性ＤＢ制御部２０４に対して、テーブルの作成依頼を行う。
【００３８】
図６は、スキーマの解析結果を用いて生成され、関係性ＤＢに格納されるテーブルの一例を示す図である。
【００３９】
スキーマ解析部２０７では、開始ノード（＜Ｓｎｏｄｅ＞タグで囲まれた情報）と、終了ノード（＜Ｅｎｏｄｅ＞タグで囲まれた情報）と、開始ノードと終了ノードとの関係性（＜Ｒｅｌａｔｅ＞タグで囲まれた情報）とに基づいて、テーブル６０１を作成する。
【００４０】
６０２は、スキーマ５０２に基づいてテーブル６０１内に生成されたエントリである。
【００４１】
６０３〜６０６は、開始ノードと終了ノードの対ごとに作成されたテーブルである。６０３は、開始ノードが“グループ”、終了ノードが“ユーザ”である場合の開始ノードと終了ノードとの関係性を保持するためのテーブルである。６０４は、開始ノードが“ユーザ”、終了ノードが“デバイス”である場合の開始ノードと終了ノードとの関係性を保持するためのテーブルである。
【００４２】
６０５は、開始ノードが“デバイス”、終了ノードが“サービス”である場合の開始ノードと終了ノードとの関係性を保持するためのテーブルである。６０６は、開始ノードが“デバイス”、終了ノードが“コンテンツ”である場合の開始ノードと終了ノードとの関係性を保持するためのテーブルである。テーブル６０３〜６０６に、それぞれのノード間の関係性が保持される。なお、スキーマ解析部２０７では、解析結果を用いて生成されたテーブル６０１のキャッシュを関係解決部２０９に保存する。
【００４３】
＜４．２  ラベル解析部＞
次に、ラベル解析部２０５の詳細機能について説明する。
（１）ラベル解析部において解析されるノード間の関係性を示すデータ
はじめにラベル解析部２０５において解析されるノード間の関係性を示すデータについて説明する。図７は、ラベル解析部において解析されるノード間の関係性を、ＸＭＬで示した図である。
【００４４】
図７において、７０１はノード間の関係性を示すデータの全体を示す。図７に示すように、ノード間の関係性を示すデータは、＜Ｒｅｌａｔｉｏｎ＞のタグで囲われている。
【００４５】
７０２は、スキーマ５０２に対応したノード間の関係性を示すデータである。＜Ｓｃｈｅｍａ＞のタグで囲われた部分は、５０２で表現されたスキーマと同等である。＜Ｌａｂｅｌｓ＞のタグで囲われた部分は、ラベル付き有向グラフの識別子を含むラベルを示している。＜Ｌａｂｅｌ＞のタグで囲われたそれぞれの部分は、ノードの識別子間の接続を定義している。＜Ｓｎｏｄｅ＞のタグに囲われた開始ノードの識別子は“１”であり、＜Ｅｎｏｄｅ＞のタグに囲われた終了ノードの識別子は“１”であり、これらの識別子が関係していることを示している。開始ノードと終了ノードとがそれぞれどのような関係性であるかは、ノード間の関係性を示すデータ７０２の上部にある＜Ｓｃｈｅｍａ＞のタグに記述されている。
【００４６】
ここでは、ノード間の関係性を示すデータ７０２で表現されたノード間の関係性の意味を説明する。開始ノードの名前は、“グループ”であって、終了ノードの名前は、“ユーザ”である。“グループ”の識別子“１”は、“ユーザ”の識別子“１”で、“所属”という関係がある。更に、“グループ”の識別子“１”は、“ユーザ”の識別子“２”と“所属”という関係がある。
【００４７】
これによって、図７に示すように、複雑なノード間の関係性を示すデータ７０１をＸＭＬで表現することができる。
【００４８】
図８は、ノード間の関係性をラベル付き有向グラフで示した図である。図８において８０１は、ノード間の関係性全体を示し、ノード間の関係性を示すデータ７０１と同じ意味を持つ。ノードのラベルとして、ノードの識別子が含まれる。例えば、ラベル付き有向グラフ８０１の最上部に位置するノードは、ノードの名前が“グループ”であって、識別子が“１”である。
【００４９】
８０２は、スキーマ５０２に対応したノード間の関係性を示すラベル付き有向グラフであって、ノード間の関係性を示すデータ７０２と同じ意味を持つ。“グループ”の識別子“１”は、“ユーザ”の識別子“１”と“所属”という関係がある。さらに、“グループ”の識別子“１”は、“ユーザ”の識別子“２”と“所属”という関係がある。
【００５０】
これによって、図８に示すように、複雑なノード間の関係性をラベル付き有向グラフで表現することができる。
【００５１】
なお、本実施形態では、ノード間の関係性を、ＸＭＬとラベル付き有向グラフで示したが、本発明はこれに限られず、グラフを表現可能な他の言語や他の記述方法によって表現してもよい。
（２）ラベル解析部における解析内容
ラベル解析部２０５では、図７で示したＸＭＬによるノード間の関係性を示すデータ７０１、または、図８で示したラベル付き有向グラフ８０１に含まれるラベルの解析を行う。ここでは、図７で示したＸＭＬによるノード間の関係性を示すデータ７０１に含まれるラベルの解析について詳細に説明する。
【００５２】
ラベル解析部２０５では、＜Ｓｃｈｅｍａ＞のタグの内容から、どの関係性を示すのかを判断した後、＜Ｌａｂｅｌｓ＞のタグの内容から、ノード間の関係性を取得する。図７のノード間の関係性を示すデータ７０２の部分を用いて説明すると、ラベル解析部２０５では、開始ノードの名前が“グループ”、終了ノードの名前が“ユーザ”、関係性が“所属”であるテーブルを検索する。具体的には、関係解決部２０９のテーブル６０１のキャッシュ内に、該当するエントリがあるか否かの判断を行う。
【００５３】
ラベル解析部２０５では、図６のエントリ６０２の部分が該当するエントリであると判断し、エントリ６０２に対応する関係性ＤＢ１０３のテーブル６０３に対して、関係性の追加を決定する。関係性の追加が決定されると、関係性ＤＢ制御部２０４を介して、関係性ＤＢ１０３のテーブル６０３にエントリを追加する。
【００５４】
具体的には、ラベル解析部２０５では、“グループ”の識別子“１”と“ユーザ”の識別子“１”との関係性、および、“グループ”の識別子“１”とユーザの識別子“２”との関係性を追加する。
【００５５】
図９のテーブル９０１は、ラベル解析部２０５によって、“グループ”と“ユーザ”との関係性が追加された後のテーブルである。以下、ラベル解析部２０５では、それぞれの関係性に対して、上記と同様の処理を行う。
【００５６】
具体的には、“ユーザ”と“デバイス”のテーブル６０４への追加を行う。図９のテーブル９０２は、ラベル解析部２０５によって、“ユーザ”と“デバイス”との関係性が追加された後のテーブルを示している。
【００５７】
更に、“デバイス”と“サービス”のテーブル６０５への追加を行う。図９のテーブル９０３は、ラベル解析部２０５によって、“デバイス”と“サービス”の関係性が追加された後のテーブルを示している。
【００５８】
更に、“デバイス”と“コンテンツ“のテーブル６０６への追加を行う。図９のテーブル９０４は、ラベル解析部２０５によって、“デバイス”と“コンテンツ”の関係性が追加された後のテーブルを示している。
【００５９】
＜４．３  属性データベース情報取得部＞
次に属性データベース情報取得部２０８の詳細機能について説明する。
【００６０】
本実施形態において、各ノードはＩＰアドレス、ポート番号、種別、型番といった様々な属性情報を有しており、これらの属性情報は、属性ＤＢ（１０４〜１０８）で管理されている。
【００６１】
ここで、属性情報の検索・追加・削除・更新などの所定の処理は、属性ＤＢ制御部２０６を介して行われるが、属性ＤＢ（１０４〜１０８）は、多様な接続方法や場所で管理されている。このため、属性ＤＢ制御部２０６では、属性ＤＢ毎の接続方法や場所を取得する必要がある。
【００６２】
属性データベース情報取得部２０８では、属性ＤＢ制御部２０６が属性情報の検索・追加・削除・更新などの所定の処理を行うために必要な、属性ＤＢ毎の接続方法や場所を取得する。このため、属性データベース情報取得部２０８は、図１０に示すような属性ＤＢの接続情報を保持しており、ノードの名前をキーとして属性ＤＢの接続情報を返すよう構成されている。
【００６３】
一例として、属性データベース情報取得部２０８が、“デバイス”の接続情報を取得する方法について説明する。属性データベース情報取得部２０８は、“デバイス”というノードの名前をキーに図１０のテーブル１００１を検索し、属性ＤＢの接続情報である接続方法、属性情報先、トランスポート、ポート番号のそれぞれを取得する。
【００６４】
テーブル１００１によれば、“デバイス”の接続方法は“ＤＨＴ”であり、属性情報先は“ｄｅｖｉｃｅ．ｃａｎｏｎ．ｃｏ．ｊｐ”であり、トランスポートは“ｕｄｐ”、ポート番号は“４０００”である。なお、本実施形態では、属性ＤＢの接続情報の管理は、情報処理装置１２０にて行うこととしているが、本発明はこれに限られず、ネットワークを介して接続されたＤＢにて行われてもよい。
【００６５】
このように、属性ＤＢの接続情報を管理することで、多様な属性ＤＢを統合することが可能になるといった効果がある。
【００６６】
＜４．４  属性ＤＢ制御部＞
次に属性ＤＢ制御部２０６の詳細機能について説明する。属性ＤＢ制御部２０６では、図１０に示すような属性データベースの接続情報を用いて、それぞれのノードに対応する属性ＤＢにアクセスする。なお、本実施形態では、すべてのノードが属性情報を持つこととしているが、必ずしもすべてのノードが属性情報を持っている必要はない。ノードが属性情報を持たない場合、テーブル１００１にも対応するエントリがない状態となる。
【００６７】
属性情報には、ノードに関連した情報（例えば、ネットワークプロトコル、ネットワークアドレス、ポート番号、製品番号、認証情報など）が含まれる。属性情報の形式は、ＸＭＬやＣＳＶなどで表現できる。なお、上述した属性情報は一例にすぎず、本発明の場合、属性情報の内容や形式に制限はない。
【００６８】
＜５．情報処理システムにおける所定の処理（検索処理）＞
次に、情報処理システム１００における所定の処理について説明する。
【００６９】
＜５．１  全体シーケンス＞
情報処理システム１００において、情報処理装置１２０では、情報検索装置１３０から、ノード間の関係性を示す情報およびノードの属性情報の検索・追加・削除・更新の実行指示を含むメッセージを受信する。そして、受信したメッセージに含まれる実行指示の内容に応じて、関係性ＤＢ１０３および属性ＤＢ（１０４〜１０８）の検索・追加・削除・更新を行い、処理結果を情報検索装置１３０に送信する。これら所定の処理のうち、以下では、属性情報の検索処理について説明する。
【００７０】
図１１は、情報処理装置１２０が情報検索装置１３０から属性情報の検索の実行指示を含むメッセージを受信し、検索処理を実行し、検索結果を返信するシーケンス図である。
【００７１】
検索処理に際して、情報検索装置１３０のメッセージ作成部３０３では、ノードの名前が“ユーザ”でノードの識別子が“１”に対応する属性情報の検索を行う旨のメッセージ（Ｍ１１０１）を作成する。
【００７２】
次に、メッセージ送受信部３０１では、通信制御部３０２を介して、情報処理装置１２０に対して、作成したメッセージ（Ｍ１１０１）を送信する。情報処理装置１２０のメッセージ送受信部２０１では、通信制御部２０２を介して、情報検索装置１３０からメッセージ（Ｍ１１０１）を受信する。
【００７３】
情報処理装置１２０のメッセージ解析部２０３では、受信したメッセージ（Ｍ１１０１）に含まれるノードの名前を取得し、関係解決部２０９に送信する。関係解決部２０９では、ノードの名前がテーブル６０１およびテーブル１００１に含まれるか否かを判断する。テーブル６０１および１００１に含まれると判断した場合、関係解決部２０９では、属性データベース情報取得部２０８から属性ＤＢの接続情報を取得し、属性ＤＢ制御部２０６に対して検索依頼（Ｍ１１０２）を送信する。
【００７４】
属性ＤＢ制御部２０６では、属性ＤＢの接続情報に基づいて、属性ＤＢｂ１０５にアクセスする。具体的には、属性ＤＢｂ１０５に対して、テーブル６０１に基づいて特定された識別子“１”の属性情報の検索依頼のメッセージ（Ｍ１１０３）を送信する。
【００７５】
属性ＤＢｂ１０５では、識別子“１”の属性情報の検索を行い、検索結果（Ｍ１１０４）を情報処理装置１２０に送信する。
【００７６】
属性ＤＢ制御部２０６では、受信した検索結果（Ｍ１１０４）をメッセージ送受信部２０１に送信する。メッセージ送受信部２０１では、通信制御部２０２を介して、情報検索装置１３０に検索結果を送信する（Ｍ１１０５）。メッセージ送受信部３０１では、通信制御部３０２を介して検索結果を受け取り、属性情報処理部３０５に送信する。属性情報処理部３０５では、属性情報のパースを行い、情報検索装置１３０が必要とする情報を取り出す。このように、テーブル６０１を用いることにより、本実施形態によれば、属性情報の検索を容易に行うことができる。
【００７７】
＜５．２  情報処理装置における検索処理の流れ＞
次に、情報処理システム１００において属性情報の検索処理が実行された場合の、情報処理装置１２０における処理の流れについて詳細に説明する。
【００７８】
図１２は、情報処理装置１２０が情報検索装置１３０から属性情報の検索の実行指示を含むメッセージ（Ｍ１１０１）を受信した際の、処理の流れを示すフローチャートである。
【００７９】
ステップＳ１２０１では、メッセージ送受信部２０１が、通信制御部２０２を介して、情報検索装置１３０から送信された属性情報の検索の実行指示を含むメッセージを受信する。
【００８０】
ステップＳ１２０２では、メッセージ送受信部２０１が、メッセージ解析部２０３に対して、メッセージの解析処理を依頼する。メッセージ解析部２０３では、属性情報の検索の実行指示を含むと判断し、メッセージからノードの名前を取得する。
【００８１】
続いて、メッセージ解析部２０３では、関係解決部２０９にノードの名前を送信する。関係解決部２０９では、ノードの名前がテーブル６０１およびテーブル１００１に含まれるか否かを判断する。関係解決部２０９においてテーブル６０１およびテーブル１００１に含まれると判断した場合には、ステップＳ１２０３に進む。一方、関係解決部２０９において、テーブル６０１およびテーブル１００１に含まれていないと判断した場合には、ステップＳ１２０７に進む。
【００８２】
ステップＳ１２０３では、関係解決部２０９が、属性データベース情報取得部２０８から属性ＤＢの接続情報を取得し、属性ＤＢ制御部２０６に属性情報の検索を依頼する。
【００８３】
ステップＳ１２０４では、属性ＤＢ制御部２０６が、属性ＤＢの接続情報に基づいて、属性ＤＢｂ１０５にアクセスする。具体的には、属性ＤＢｂ１０５に対して、テーブル６０１に基づいて特定された識別子“１”の属性情報の検索依頼のメッセージ（Ｍ１１０３）を送信する。
【００８４】
送信後、属性ＤＢ制御部２０６では、属性ＤＢｂ１０５にて属性情報の検索が行われたか否かを判断し、行われたと判断した場合には、ステップＳ１２０５に進む。一方、属性ＤＢｂ１０５にて属性情報の検索が行われなかったと判断した場合には、ステップＳ１２０７に進む。
【００８５】
ステップＳ１２０５では、属性ＤＢ制御部２０６が属性情報を取得し、メッセージ送受信部２０１に送信する。
【００８６】
ステップＳ１２０６では、メッセージ送受信部２０１が、通信制御部２０２を介して、情報検索装置１３０に対して属性情報を送信し、処理を終了する。
【００８７】
一方、ステップＳ１２０７では、メッセージ送受信部２０１が、通信制御部２０２を介して、情報検索装置１３０に対して、属性情報が取得できなかった旨のエラーメッセージを送信し、処理を終了する。
【００８８】
＜６．情報処理システムにおける所定の処理（追加処理）＞
次に、情報処理システム１００における所定の処理として追加処理について説明する。
【００８９】
＜６．１  全体シーケンス＞
上述したように、情報処理システム１００において、情報処理装置１２０では、情報検索装置１３０から、ノード間の関係性を示す情報およびノードの属性情報の検索・追加・削除・更新のメッセージを受信する。また、受信したメッセージの内容に応じて、関係性ＤＢ１０３および属性ＤＢ（１０４〜１０８）の検索・追加・削除・更新を行い、処理結果を情報検索装置１３０に送信する。このうち、以下では、ノード間の関係性を示す情報の追加処理について説明する。
【００９０】
図１３は、情報処理装置１２０が、情報検索装置１３０からノードの関係性を示す情報の追加の実行指示を含むメッセージを受信し、追加処理を実行した後、実行結果を返信するシーケンス図である。
【００９１】
追加処理に際して、情報検索装置１３０のメッセージ作成部３０３では、名前が“ユーザ”で識別子が“２”の開始ノードと、名前が“デバイス”で識別子が“３”の終了ノードとの関係性を追加する旨のメッセージを作成する。更に、通信制御部３０２を介して、情報処理装置１２０に対して、作成したメッセージ（Ｍ１３０１）を送信する。情報処理装置１２０のメッセージ送受信部２０１では、通信制御部２０２を介して、情報検索装置１３０からメッセージ（Ｍ１３０１）を受信する。
【００９２】
情報処理装置１２０のメッセージ解析部２０３では、受信したメッセージ（Ｍ１３０１）から、名前が“ユーザ”で識別子が“２”の開始ノードと、名前が“デバイス”で識別子が“３”の終了ノードとの関係性を取得し、関係解決部２０９に送信する。
【００９３】
関係解決部２０９では、当該送信された関係性がテーブル６０１に含まれているか否かを判断する。テーブル６０１に含まれていると判断した場合、関係解決部２０９では、関係性ＤＢ制御部２０４に追加処理を依頼する（Ｍ１３０２）。
【００９４】
関係性ＤＢ制御部２０４では、関係性ＤＢ１０３に、名前が“ユーザ”で識別子が“２”の開始ノードと、名前が“デバイス”で識別子が“３”の終了ノードとの関係性の追加依頼を送信する（Ｍ１３０３）。なお、本実施形態では、関係性ＤＢ１０３は固定であるが、属性ＤＢの接続情報のように接続方法を記述した情報を取得した後、アクセスするようにしてもよい。
【００９５】
関係性ＤＢ１０３では、名前が“ユーザ”で識別子が“２”の開始ノードと、名前が“デバイス”で識別子が“３”の終了ノードとの関係性について追加する。関係性ＤＢ１０３では、関係性の追加が成功したか否かを含むメッセージ（本実施形態では成功したとする）（Ｍ１３０４）を情報処理装置１２０に送信する。
【００９６】
関係性ＤＢ制御部２０４では、受信した関係性の追加が成功したことを示すメッセージ（Ｍ１３０４）をメッセージ送受信部２０１に送信する。メッセージ送受信部２０１では、通信制御部２０２を介して、情報検索装置１３０にノード間の関係性を示す情報の追加が成功したことを示すメッセージ（Ｍ１３０５）を送信する。メッセージ送受信部３０１では、通信制御部３０２を介して、ノード間の関係性を示す情報の追加が成功したことを示すメッセージ（Ｍ１３０５）を受信する。
【００９７】
このように、本実施形態によれば、ノード間の関係性を示す情報を柔軟に追加することができる。
【００９８】
＜６．２  情報処理装置における追加処理の流れ＞
次に、情報処理システム１００においてノードの関係性を示す情報の追加処理が実行された場合の、情報処理装置１２０における処理の流れについて詳細に説明する。
【００９９】
図１４は、情報処理装置１２０が情報検索装置１３０からノード間の関係性を示す情報の追加の実行指示を含むメッセージ（Ｍ１３０１）を受信した際の、処理の流れを示すフローチャートである。
【０１００】
ステップＳ１４０１では、メッセージ送受信部２０１が、通信制御部２０２を介して、情報検索装置１３０から送信されたノード間の関係性を示す情報を追加する旨のメッセージを受信する。
【０１０１】
ステップＳ１４０２では、メッセージ送受信部２０１が、メッセージ解析部２０３にメッセージ解析処理を依頼する。メッセージ解析部２０３では、受信したメッセージ（Ｍ１３０１）が、ノード間の関係性を示す情報を追加する旨のメッセージであると判断する。メッセージ解析部２０３では、ラベル解析部２０５を用いて、開始ノードの名前“ユーザ”と“識別子“２”、及び、終了ノードの名前“デバイス”と識別子“３”を取得する。
【０１０２】
ステップＳ１４０３では、メッセージ解析部２０３が、関係解決部２０９にノード間の関係性を示す情報（開始ノードの名前“ユーザ”と識別子“２”、および、終了ノードの名前“デバイス”と識別子“３”）を送信する。関係解決部２０９では、開始ノードの名前および終了ノードの名前がテーブル６０１に含まれているか否かを判断する。
【０１０３】
関係解決部２０９において、テーブル６０１に含まれていると判断した場合には、関係性ＤＢ制御部２０４に対して、ノード間の関係性を示すデータ（開始ノードの名前“ユーザ”と識別子“２”、終了ノードの名前“デバイス”と識別子“３”）を送信する。その後、ステップＳ１４０４に進む。一方、関係解決部２０９において、テーブル６０１に含まれていないと判断した場合は、ステップＳ１４０６に進む。
【０１０４】
ステップＳ１４０４では、関係性ＤＢ制御部２０４が、関係性ＤＢ１０３に、名前が“ユーザ”で識別子が“２”の開始ノードと、名前が“デバイス”で識別子が“３”の終了ノードとの関係性を追加する。関係性ＤＢ制御部２０４にて、ノード間の関係性を示す情報の追加ができたと判断すると、ステップＳ１４０５に進む。一方、関係性ＤＢ制御部２０４にて、ノード間の関係性を示す情報の追加ができなかったと判断すると、ステップＳ１４０６に進む。
【０１０５】
ステップＳ１４０５では、メッセージ送受信部２０１が、通信制御部２０２を介して、ノード間の関係性を示す情報の追加が成功したことを示すメッセージ（Ｍ１３０５）を情報検索装置１３０に送信し、処理を終了する。
【０１０６】
ステップＳ１４０６では、メッセージ送受信部２０１が、通信制御部２０２を介して、情報検索装置１３０に対して、ノード間の関係性を示す情報の追加が失敗したことを示すメッセージ（Ｍ１３０５）を送信し、処理を終了する。
【０１０７】
図１５は、ノード間の関係性を示す情報を追加した後の関係性ＤＢのテーブルを示した図である。テーブル１００１に対して、上記ノード間の関係性を示す情報の追加処理が行われることで、“ユーザ”の識別子“２”の開始ノードと“デバイス”の識別子“３”の終了ノードとの関係性が追加されていることがわかる。このように、本実施形態によれば、ノード間の関係性を示す情報を容易に追加することができる。
【０１０８】
以上の説明から明らかなように、本実施形態によれば、ノード間の関係性を示す情報及びノードの属性情報を管理することが可能となる。また、ノード間の関係性を示す情報を柔軟に追加・削除・更新することが可能となる。さらに、ノードの属性情報の内部構成を柔軟に追加・削除・更新することが可能となる。更に、識別子によって表現されたノード間の関係性を高速に検索することが可能となる。
【０１０９】
なお、本実施形態では、検索と追加について図面を用いて詳しく説明したが、本発明は、削除・更新やそれ以外の操作についても同様に実施可能であることは言うまでもない。
【０１１０】
また、ノードとノードの属性情報とは密な固定の関係であり、ノード間は疎な半固定の関係であるといえる。本実施形態では、“グループ”、“ユーザ”、“デバイス”、“コンテンツ”を用いて説明したが、これに限らず、ネットワーク上のノードの表現や言葉の関係性の表現などにも適用できることは言うまでもない。
【０１１１】
［第２の実施形態］
上記第１の実施形態では、関係性ＤＢと情報処理装置とがそれぞれ１つずつ配された情報処理システムについて説明したが、本発明はこれに限定されず、関係性ＤＢと情報処理装置とをそれぞれ２つずつ配するように構成してもよい。以下、本実施形態の詳細について、上記第１の実施形態との差異点を中心に説明する。
【０１１２】
＜１．情報処理システムの構成＞
はじめに、本実施形態に係る情報処理システム１６００の構成について説明する。図１６は、本実施形態に係る情報処理システム１６００の構成を示す図である。
【０１１３】
図１６において、１６２１は、関係性ＤＢａ１６０１を利用する情報処理装置ａである。１６２２は、関係性ＤＢｂ１６０２を利用する情報処理装置ｂである。
【０１１４】
図１７は、関係性ＤＢａ１６０１、関係性ＤＢｂ１６０２と属性ＤＢｂ１０５、属性ＤＢｃ１０６、属性ＤＢｅ１０８との関連を表した図である。関係性ＤＢａ１６０１は、“グループ”、“ユーザ”、“デバイス”、“コンテンツ”のノード間の関係性を管理する関係性ＤＢである。関係性ＤＢｂ１６０２は、“デバイス”、“ユーザ”、“サービス”、“コンテンツ”のノード間の関係性を管理する関係性ＤＢである。
【０１１５】
＜２．情報処理装置におけるＤＢ追加処理の流れ＞
次に、本実施形態に係る情報処理システム１６００におけるＤＢ追加処理について説明する。情報検索装置１３０では、追加したいノード間の関係性によって、関係性ＤＢａ１６０１または関係性ＤＢｂ１６０２のいずれかを選択する。その後、上記第１の実施形態と同様に、情報検索装置１３０にて、ノード間の関係性を示す情報の追加の要求を送信する。
【０１１６】
情報処理装置ａ１６２１では、情報検索装置１３０の要求に応じて、上記第１の実施形態と同様に、関係性ＤＢａ１６０１の追加処理を行う。情報処理装置ｂ１６２２においても、同様に、情報検索装置１３０の要求に応じて、関係性ＤＢｂ１６０２の追加処理を行う。
【０１１７】
属性ＤＢ（１０４〜１０８）は、情報処理装置ａ１６２１および情報処理装置ｂ１６２２から、操作を受け付ける。このように、情報処理装置ａ１６２１および情報処理装置ｂ１６２２は、異なる関係性を保持しながら、属性ＤＢ（１０４〜１０８）を共用することができる。
【０１１８】
本実施形態における各ノードは、複数の関係性に属する場合においても、１つの属性ＤＢのエントリを更新するだけで良くなるため、属性ＤＢのメンテナンス処理のコストを低減させることが可能となる。また、属性ＤＢ群の上に複数の関係性ＤＢを配置することで、複数のシステムで共通に利用することができるようになるため、システム構築およびメンテナンスなどのコストを低減させることが可能となる。
【０１１９】
［第３の実施形態］
上記第２の実施形態では、関係性ＤＢと情報処理装置とをそれぞれ２つずつ配する構成としたが、本発明はこれに限定されず、関係性ＤＢのみを２つ配する構成としてもよい。以下、本実施形態の詳細について、上記第１及び第２の実施形態との差異点を中心に説明する。
【０１２０】
＜１．情報処理システムの構成＞
図１８は、本実施形態に係る情報処理システム１８００の構成を示す図である。図１８において、１８２０は、関係性ＤＢａ１６０１および関係性ＤＢｂ１６０２を利用する情報処理装置である。情報処理装置１８２０は、関係性ＤＢａ１６０１の第一のノード間の関係性を管理する。さらに、関係性ＤＢｂ１６０２の第二のノード間の関係性を管理する。
【０１２１】
情報処理装置１８２０では、情報検索装置１３０から、第一のノード間の関係性を示す情報及び第二のノード間の関係性を示す情報についての検索・追加・削除・更新の要求を受信する。情報処理装置１８２０では、受信した要求が第一のノード間の関係性に対する要求であるのか、第二のノード間の関係性を示す情報に対する要求であるのかを区別する必要がある。そこで、第一のノードの関係性を示す情報および第二のノードの関係性を示す情報にネームスペースを追加する。
【０１２２】
ここで、属性ＤＢａ１０４および属性ＤＢｂ１０５はインターネット１１０を介して、情報処理装置１８２０に接続されている。つまり、本実施形態の情報処理システム１８００では、トポロジーの制限を受けずにデータベースを管理することができる。
【０１２３】
図１９（Ａ）は、関係性ＤＢａ１６０１が管理する第一のノード間の関係性を示すデータを表した図である。１９０１の例では、第一のノード間の関係性をＸＭＬによって示している。また、第一のノード間の関係性を示すネームスペースとして、“ｈｔｔｐ：／／ｃａｎｏｎ．ｃｏ．ｊｐ／ｎｓ１”が利用されている。
【０１２４】
図１９（Ｂ）は、関係性ＤＢｂ１６０２が管理する第二のノード間の関係性を示す図である。１９０２の例では、第二のノード間の関係性をＸＭＬによって示している。また、第二のノード間の関係性を示すネームスペースとして、“ｈｔｔｐ：／／ｃａｎｏｎ．ｃｏ．ｊｐ／ｎｓ２”が利用されている。
【０１２５】
なお、本実施形態では、関係性ＤＢａ１６０１と関係性ＤＢｂ１６０２とは別のデータベースとして実現されているが、本発明はこれに限られず、ネームスペースにより区切られているため、同一のデータベースとして実現することもできる。
【０１２６】
＜２．情報処理システムにおける所定の処理＞
次に、本実施形態に係る情報処理システム１８００における所定の処理について説明する。本実施形態において、情報検索装置１３０では、情報処理装置１８２０に対して、検索・追加・削除・更新の要求を行う。このとき、情報検索装置１３０では、ネームスペースを利用して、第一のノード間の関係性を示す情報に対する要求であるのか、第二のノード間の関係性を示す情報に対する要求であるのかを区別する。なお、以下では、図２０を用いて、情報検索装置１３０が、第一のノード間の関係性を示す情報に対して追加の要求を行う場合の処理について説明する。
【０１２７】
メッセージ作成部３０３では、ネームスペースが“ｈｔｔｐ：／／ｃａｎｏｎ．ｃｏ．ｊｐ／ｎｓ１”である以下の開始ノードと終了ノードとの関係性を示す情報を追加するメッセージを作成する。
・開始ノード：名前が“ユーザ”、識別子が“２”
・終了ノード：名前が“デバイス”、識別子が“３”
メッセージ送受信部３０１では、通信制御部３０２を介して、情報処理装置１８２０に対して、作成したメッセージ（Ｍ２００１）を送信する。情報処理装置１８２０のメッセージ送受信部２０１では、通信制御部２０２を介して、情報検索装置１３０からメッセージ（Ｍ２００１）を受信する。
【０１２８】
メッセージ解析部２０３では、該メッセージから、ネームスペースが“ｈｔｔｐ：／／ｃａｎｏｎ．ｃｏ．ｊｐ／ｎｓ１”であって、以下の開始ノードと終了ノードとの関係性を示すデータを取得する。
・開始ノード：名前が“ユーザ”、識別子が“２”
・終了ノード：名前が“デバイス”、識別子が“３”
そして、取得したノード間の関係性を示すデータを関係解決部２０９に送る。
【０１２９】
関係解決部２０９では、ノード間の関係性を示すデータがテーブル６０１に含まれているか否かを判断する。テーブル６０１に含まれていると判断した場合には、関係解決部２０９が、関係性ＤＢ制御部２０４に対して追加を依頼する（Ｍ２００２）。
【０１３０】
そして、関係性ＤＢ制御部２０４では、関係性ＤＢａ１６０１に追加依頼を送信する。具体的には、ネームスペースが“ｈｔｔｐ：／／ｃａｎｏｎ．ｃｏ．ｊｐ／ｎｓ１”であって、名前が“ユーザ”、識別子“２”の開始ノードと名前が“デバイス”、識別子が“３”の終了ノードとの関係性を示すデータの追加依頼を送信する。なお、本実施形態では、関係性ＤＢａ１６０１は固定であるが、属性ＤＢの接続情報のように接続方法を記述した情報を取得した後、アクセスするようにしてもよい。
【０１３１】
関係性ＤＢａ１６０１では、ネームスペースが“ｈｔｔｐ：／／ｃａｎｏｎ．ｃｏ．ｊｐ／ｎｓ１”であって、名前が“ユーザ”、識別子“２”の開始ノードと名前が“デバイス”、識別子が“３”の終了ノードとの関係性を示すデータの追加を行う。関係性ＤＢａ１６０１では、更に、ノード間の関係性を示すデータの追加が成功したか否かを含むメッセージ（本実施形態では成功したとする）（Ｍ２００４）を情報処理装置１８２０に送信する。
【０１３２】
関係性ＤＢ制御部２０４では、ノード間の関係性を示すデータの追加が成功したことを示すメッセージ（Ｍ２００４）をメッセージ送受信部２０１に送信する。メッセージ送受信部２０１では、通信制御部２０２を介して、情報検索装置１３０に対してノード間の関係性を示すデータの追加が成功したことを示すメッセージ（Ｍ２００５）を送信する。メッセージ送受信部３０１では、通信制御部３０２を介して、ノード間の関係性を示すデータの追加が成功したことを示すメッセージ（Ｍ２００５）を受信する。
【０１３３】
このように、本実施形態によれば、ＤＢの物理的構成によらず、複数のノード間の関係性を示す情報を管理することが可能となる。
【０１３４】
［第４の実施形態］
次に、本発明の第４の実施形態について、上記第１の実施形態との差異点を中心に説明する。
【０１３５】
＜１．スキーマ解析部＞
（１）スキーマ解析部において解析されるスキーマの例
本実施形態のラベル解析部２０５では、ラベル付きグラフ（ラベル付き有向グラフおよびラベル付き無向グラフ）のノードのラベルおよび辺のラベルを処理する。このため、本実施形態のスキーマ解析部２０７では、ラベル付きグラフで示されるスキーマを理解し、関係性ＤＢ１０３と結びつける処理を行う。
【０１３６】
図２１は、本実施形態においてスキーマ解析部２０７において解析される、スキーマの一部をＸＭＬおよびラベル付きグラフで示した図である。ここでは、ノード間の関係性が同等であることを意味する、ラベル付き無向グラフの例を示している。
【０１３７】
図２１において、２１０１は、ラベル付きグラフにおける、ノード間の接続を示すスキーマである。ノード間の接続は、ＸＭＬの場合、＜ＬａｂｅｌｅｄＧｒａｐｈ＞のタグで示される。
【０１３８】
２１０２は、ノードのラベルに“ユーザ”という名前が付与されたノードである。２１０２は、ＸＭＬの場合、＜Ｎｏｄｅ＞のタグで示される。
【０１３９】
２１０３は、辺のラベルに同等という関係が付与されたノード２１０２とノード２１０４との関係性を示している。ノード間の関係性が同等である場合、ノード間はラベル付き無向グラフで接続される。なお、本実施形態においては、“同等”というラベルを用いたが、ラベルはこれに限られるものでない。さらに、ラベルを用いないことで、無向を表現するようにしてもよい。
【０１４０】
２１０４は、ノードのラベルに“カスタマ”という名前が付与されたノードである。２１０４は、ＸＭＬの場合、＜Ｎｏｄｅ＞のタグで示される。
【０１４１】
ノード２１０２およびノード２１０４のノードの名前が入れ替わったとしても、ラベル付き無向グラフで示すことができるので、同じ意味を持つ。
【０１４２】
図２２は、本実施形態においてスキーマ解析部２０７において解析される、スキーマ全体をＸＭＬで示した図である。図２２において、２２０１は、スキーマ全体を示している。２２０２は、参照番号２１０１で示したスキーマの一部である。このように、有向と無向とを、同一のＸＭＬ内で表現することができる。
【０１４３】
図２３は、本実施形態においてスキーマ解析部２０７において解析される、スキーマ全体をラベル付きグラフで示した図である。図２３において、２３０１は、スキーマ全体を示している。２３０２は、図２１の参照番号２１０１で示したスキーマの一部である。
【０１４４】
なお、本実施形態では、スキーマ解析部２０７において解析されるスキーマを、ＸＭＬとラベル付きグラフで示したが、本発明はこれに限られず、グラフを表現可能な他の言語や他の記述方法によって表現してもよい。
（２）スキーマ解析部における解析内容
次に、本実施形態におけるスキーマ解析部２０７での解析内容について説明する。本実施形態に係るスキーマ解析部２０７では、図２２および図２３で示されたスキーマの解析を行う。そして、解析結果に応じて、関係性ＤＢ制御部２０４にテーブルの作成依頼を行う。
【０１４５】
図２４は、本実施形態に係るスキーマ解析部２０７によるスキーマ解析結果を用いて作成され、関係性ＤＢ１０３に格納されたテーブルについて、図６との差異点のみを示した図である。
【０１４６】
スキーマ解析部２０７は、ノード（＜Ｎｏｄｅ＞タグで囲まれた情報）と、ノード間の関係（＜Ｒｅｌａｔｅ＞タグで囲まれた情報）とに基づいて、テーブル２４０１を作成する。
【０１４７】
２４０２は、図２２の参照番号２２０２及び図２３の参照番号２３０２で表現されたスキーマから生成されたエントリである。
【０１４８】
テーブル２４０１は、ノード間の同等の関係（２４０２で示される無向の関係）ごとに作成される。テーブル２４０１には、“ユーザ”および“カスタマ”のノードの関係性が保持される。また、テーブル２４０３には、それぞれのノード間の関係性が保持される。スキーマ解析部２０７では、関係解決部２０９にテーブル２４０１のキャッシュを保存する。
【０１４９】
＜２．ラベル解析部＞
（１）ラベル解析部において解析されるノード間の関係性を示すデータ
図２５は、本実施形態においてラベル解析部２０５にて解析されるノード間の関係性をＸＭＬで示した図である。
【０１５０】
２５０１は、ノード間の関係性を示すデータの全体を示す。ノード間の関係性を示すデータ全体は、＜Ｒｅｌａｔｉｏｎ＞のタグで囲われている。
【０１５１】
２５０２は、図２２の参照番号２２０２および図２３の参照番号２３０２で表現されたスキーマに対応したノード間の関係性を示すデータである。＜Ｓｃｈｅｍａ＞のタグで囲われた部分は、図２２の参照番号２２０２および図２３の参照番号２３０２で表現されたスキーマと同等である。
【０１５２】
＜Ｌａｂｅｌｓ＞のタグで囲われた部分は、ラベル付き無向グラフの識別子を含むラベルを示す。＜Ｌａｂｅｌ＞のタグで囲われたそれぞれの部分は、ノードの識別子間の接続である。＜Ｎｏｄｅ＞のタグで囲われたノードの識別子は、“１”と“４”であり、これらの識別子が関係していることを示す。ノード間の関係性がどのようなものであるかは、図２５の参照番号２５０２上部にある＜Ｓｃｈｅｍａ＞のタグに記述されている。
【０１５３】
ここでは、参照番号２５０２で表現されたノード間の関係性の意味を説明する。ノードは、“ユーザ”と“カスタマ”である。“ユーザ”の識別子“１”は、“カスタマ”の識別子“４”と同等という関係がある。本実施形態では、同等は、無向を示すので（ノード間は同じ立場であって、ノード間の関係の方向性はない）、“ユーザ”と“カスタマ”が逆転して記述されていても同じ意味を持つ。
【０１５４】
これによって、図２５に示すように、複雑なノード間の関係性をＸＭＬで表現することができる。
【０１５５】
図２６は、ノード間の関係性をラベル付きグラフで示した図である。２６０１は、ノード間の関係性の全体を示し、ノードの関係性を示すデータ２５０１と同じ意味を持つ。
【０１５６】
２６０２は、図２２の参照番号２２０２および図２３の参照番号２３０２で表現されたスキーマに対応したノード間の関係性を示すグラフであって、図２５の参照番号２５０２と同じ意味を持つ。“ユーザ”の識別子“１”は、“カスタマ”の識別子“４”と同等という関係がある。
【０１５７】
これによって、図２６に示すように、複雑なノード間の関係性をラベル付きグラフで表現することができる。
【０１５８】
なお、本実施形態では、ノード間の関係性をＸＭＬとラベル付きグラフで示したが、本発明はこれに限られず、グラフを表現可能な他の言語や他の記述方法によって表現してもよい。
（２）ラベル解析部における解析内容
ラベル解析部２０５では、ＸＭＬによるノード間の関係性を示すデータ２５０１、または、ラベル付きグラフ２６０１に含まれるラベルの解析を行う。ここでは、ＸＭＬによるノード間の関係性を示すデータ２５０１に含まれるラベルの解析について詳細に説明する。
【０１５９】
ラベル解析部２０５では、＜Ｓｃｈｅｍａ＞のタグの内容から、どの関係性を示すのかの判断を行った後、＜Ｌａｂｅｌｓ＞のタグの内容から、ノード間の関係性を取得する。図２５の参照番号２５０２の部分を用いて説明すると、ラベル解析部２０５では、ノードは名前が“ユーザ”と“カスタマ”であって、関係が“同等”であるテーブルを検索する。ラベル解析部２０５では、関係解決部２０９のテーブル２４０１のキャッシュから、該当するエントリがあるか否かの判断を行う。ラベル解析部２０５において、エントリ２４０２が該当するエントリであると判断すると、エントリ２４０２に対応する関係性ＤＢ１０３のテーブル２４０３に関係性を追加することを決定する。
【０１６０】
ラベル解析部２０５では、関係性ＤＢ制御部２０４を介して、関係性ＤＢ１０３のテーブル２４０３にエントリ２４０２を追加する。具体的には、“ユーザ”の識別子“１”と“カスタマ”の識別子“４”との関係性を追加する。
【０１６１】
以上のように、本実施形態によれば、ノードのラベルに付与された名前が異なっていても、同じノードとして扱うことができる。これにより、ノードの名前と識別子とを指定することで、他のノードの名前と識別子を類義語のように取得することが可能となる。
【０１６２】
なお、本実施形態は、有向と無向が入り混じった複雑なネットワーク上のノードの表現や言葉の関係性の表現などにも適用することができる。
【０１６３】
［他の実施形態］
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【図１】
2013142983.tif 000003
【図２】
2013142983.tif 000004
【図３】
2013142983.tif 000005
【図４】
2013142983.tif 000006
【図５】
2013142983.tif 000007
【図６】
2013142983.tif 000008
【図７】
2013142983.tif 000009
【図８】
2013142983.tif 000010
【図９】
2013142983.tif 000011
【図１０】
2013142983.tif 000012
【図１１】
2013142983.tif 000013
【図１２】
2013142983.tif 000014
【図１３】
2013142983.tif 000015
【図１４】
2013142983.tif 000016
【図１５】
2013142983.tif 000017
【図１６】
2013142983.tif 000018
【図１７】
2013142983.tif 000019
【図１８】
2013142983.tif 000020
【図１９】
2013142983.tif 000021
【図２０】
2013142983.tif 000022
【図２１】
2013142983.tif 000023
【図２２】
2013142983.tif 000024
【図２３】
2013142983.tif 000025
【図２４】
2013142983.tif 000026
【図２５】
2013142983.tif 000027
【図２６】
2013142983.tif 000028