JP4913360B2 - プロファイル管理装置およびコンピュータプログラム - Google Patents

Description

本発明は、ユーザが個別に取得するＲＤＦ（Resource Description Framework）によって記述されたプロファイル情報を管理する、プロファイル管理装置およびコンピュータプログラムに関する。

情報データを特定のアプリケーションや事前知識を前提とせずに、コンピュータが理解可能な形で情報を表現するためのフレームワークとしてＲＤＦがある。ＲＤＦは、Ｗ３Ｃによって標準化が進められている（例えば、非特許文献１、２参照）。

ＲＤＦは、表現すべき対象をリソース（Resource）と呼び、そのリソースに対する属性情報をプロパティ（Property）またその属性値をリテラル（Literal）として表現する。例えば、ｗｅｂ（World Wide Web）のＵＲＬ（Uniform Resource Locator）の“http://www.rdf.co.jp”という対象（Resource）に対し、作者が“山田太郎”であることをＲＤＦモデルによって図３２のように表現する。
この情報を読み取ることにより、コンピュータは人手を介さずにそのｗｅｂの作者が山田太郎であることを認識することができる。図３２中、楕円はリソースであり、その内部に書かれているのが識別情報としてのＵＲＩ（Uniform Resource Identifier：処理をする上で個別に認識するためのＩＤ)であり、この場合ではＵＲＬが指定されている。またdc:creatorは作者を意味するプロバティ情報であり、接頭辞のdc:はDublin Coreが定義した語彙であることを示す名前空間である（例えば、非特許文献３参照）。

この技術の応用分野は、例えば、ＲＳＳ(RDF Site Summary)といったｗｅｂのニュース記事にメタデータとして記述し、見出し情報を配信する手段として利用される（例えば、非特許文献４参照）。また、ＣＣ／ＰＰ（Composite Capabilities/Preferences Profile）という標準規格においても携帯端末の仕様を記述して配信コンテンツを最適化するための手段としても利用されている（例えば、非特許文献５参照）。
将来の情報化社会では、メタデータ化された各種情報があらゆるシチュエーション、あらゆるインタフェースを通して取得されることが想定される。例えば、ユーザが生活の中で、サービスプロバイダとの契約情報や、スーパーで手にした商品についたタグによって得た物品詳細情報、商品を購入したときに得られる電子決済情報、ショッピングモールなどで提供されるであろうエリアサービス一覧情報（これらをプロファイルと呼ぶ）などといったプロファイル情報が、赤外線通信やタグリーダ、インターネットを通じて取得できることが考えられる。

こうした膨大な情報を個別に管理していては、ユーザはその情報量で破綻してしまい、せっかくの有益な情報も埋もれてしまって有効活用できないと考えられる。ここでこれらのプロファイル情報に着目すると、個別に得た情報の中には互いにオーバーラップした情報も含まれる。
例えば、上記プロファイル情報の中には、人・本人に関する情報やサービスに関する情報、場所に関する情報、また物品に関する情報などが複数のプロファイル情報に跨って記述されている。例えば、物品詳細情報と電子決済情報には同じ物品に関する情報が含まれる。物品詳細情報にはその物品の製造日や生産国といった情報が記述されており、また電子決済情報にはその物品の購入価格などが記述される。

そこでＲＤＦモデルによってある物品ならある物品と情報を同一のリソースとして管理すれば、つまり同じＵＲＩを割り当てれば、ユーザはその物品についてそのＵＲＩを検索すればこれまでに得たことのある全ての情報を引き出すことが可能となる。これによってプロファイル情報を統合的に一元管理することが可能になる（例えば、非特許文献６、７参照）。例えば、同一物であると体系化して整理することで、情報に新たな価値を生成させることができる。
２００５年４月７日閲覧、インターネット＜URL：http://www.w3.org/RDF/＞ ２００５年４月７日閲覧、インターネット＜URL：http://www.w3.org/TR/rdf-concepts/＞ ２００５年４月７日閲覧、インターネット＜URL：http://dublincore.org/documents/dces/＞ Dan Brickley, et al., RDF Site Summary (RSS)1.0, 2000, RSS-DEV Working Group, http://purl.org/rss/1.0/spec/ F. Reynolds, J. Jjelm, S. Dawkins, S. Singhal, "Composite Capability/Preference Profiles (CC/PP): A user side framework for content negotiation", W3C Note, 27 July 1999. http://www.w3.org/TR/NOTE-CCPP 森川, 本庄, 小塚, 山口, 大橋, "ユーザ状況に基づいたプロファイル体系化およびその活用に関する一検討," 情処学UBI研報, no. 2, pp. 219-224, Nov. 2003. 本庄, 森川, 山口, 大橋, "プロファイル情報とその統合利用技術に関する一検討," 信学ソ大会, B-15-20, Sept. 2003.

本発明は、上記した背景技術に鑑みてなされたものであり、異なる情報源から得たＲＤＦデータに対し、記述された対象（リソース）で内容が同一と判断されるものに固有の識別情報を付与することで各種ＲＤＦデータの関連付けを行い、このことにより、ＲＤＦで記述されたプロファイル情報（ＲＤＦプロファイル）間に新たな価値を持たせ、ユーザに対し、プロファイル間の検索等を行う際に利便性を与えることのできるプロファイル管理装置およびそのプログラムを提供することを目的とする。

上記の課題を解決するために、本発明に係るプロファイル管理装置は、ユーザが個別に取得するＲＤＦによって記述されたプロファイル情報をデータベースに蓄積し管理するプロファイル管理装置であって、前記取得したプロファイル情報に含まれるリソースのクラスを推論し、推論結果のクラスの情報を当該プロファイル情報に付加する推論手段と、前記推論手段によるクラスの情報の付加後のプロファイル情報に含まれるクラス毎に、当該プロファイル情報に含まれるリソースを前記データベース内の既存のリソースと比較し、双方のリソースが同一であると判断した場合にはその既存のリソースの識別情報を当該プロファイル情報に含まれる当該リソースに付与し、同一ではないと判断した場合には新たな識別情報を当該プロファイル情報に含まれる当該リソースに付与する識別情報統合手段と、を備えたことを特徴とする。

本発明に係るプロファイル管理装置においては、前記推論手段は、クラス間の継承関係が定義された第１の定義データを有し、前記第１の定義データに基づき、あるリソースのクラスに対し、その上位概念であるクラスも当該リソースのクラスであると判断することを特徴とする。

本発明に係るプロファイル管理装置においては、前記推論手段は、プロパティの制約が定義された第２の定義データを有し、前記第２の定義データに基づき、リソースが保持するプロパティから当該リソースのクラスを判断することを特徴とする。

本発明に係るプロファイル管理装置においては、前記推論手段は、等価的なクラス又は等価的なプロパティの組み合わせが定義された第３の定義データを有し、前記第３の定義データに基づき、あるリソースのクラスに対し、等価とされるクラス又はプロパティを判断することを特徴とする。

本発明に係るプロファイル管理装置においては、前記識別情報統合手段は、比較対象の各リソースのプロパティを比較して同一のリソースであるか否かを判断することを特徴とする。

本発明に係るプロファイル管理装置においては、前記データベースに格納されているプロファイル情報に含まれるリソースのインデックス情報を記憶する記憶手段を有し、前記インデックス情報は、リソースの識別情報、該識別情報を有するリソースに共通のプロパティ及びそのリテラルの組み合わせから成り、前記識別情報統合手段は、前記インデックス情報に基づいて前記リソースの同一の判断を行うことを特徴とする。

本発明に係るコンピュータプログラムは、ユーザが個別に取得するＲＤＦによって記述されたプロファイル情報をデータベースに蓄積し管理するためのコンピュータプログラムであって、前記取得したプロファイル情報に含まれるリソースのクラスを推論し、推論結果のクラスの情報を当該プロファイル情報に付加する機能と、前記クラスの情報の付加後のプロファイル情報に含まれるクラス毎に、当該プロファイル情報に含まれるリソースを前記データベース内の既存のリソースと比較し、双方のリソースが同一であると判断した場合にはその既存のリソースの識別情報を当該プロファイル情報に含まれる当該リソースに付与し、同一ではないと判断した場合には新たな識別情報を当該プロファイル情報に含まれる当該リソースに付与する機能と、をコンピュータに実現させることを特徴とする。
これにより、前述のプロファイル管理装置がコンピュータを利用して実現できるようになる。

本発明によれば、新たに取得されたプロファイル情報に含まれるリソースが既にデータベースに格納されているリソースと意味的に等しい場合には、該データベース内のリソースと同じ識別情報が該取得されたプロファイル情報中のリソースに付与される。これにより、ユーザが収集したプロファイル情報をデータベースに蓄積する際、プロファイル情報間の関連付けを行うことができ、ＲＤＦで記述されたプロファイル情報（ＲＤＦプロファイル）間に新たな価値を持たせることができる。さらに、該蓄積されたプロファイル情報の検索時において、ＲＤＦプロファイル間をまたがるような検索なども容易に実現可能となるので、ユーザの利便性が向上する。また、新たに取得されたプロファイル情報に含まれるリソースのクラスの推論結果が当該プロファイル情報に反映されるので、該推論結果に基づいてリソースの同一の判断を容易に行うことが可能となる。

以下、図面を参照し、本発明の一実施形態について説明する。
図１は、本発明の一実施形態に係るプロファイル管理装置の構成を示すブロック図である。図１に示すＵＲＩ統合装置１０において、入力プロファイル１としてのＲＤＦプロファイル情報源は、ユーザに対して、ＲＤＦで記述されたプロファイル情報（ＲＤＦプロファイルと呼ぶ）を提供する。ＲＤＦプロファイルはユーザの個人情報を表すメタデータであり、取得された情報はＲＤＦプロファイルデータベース（ＲＤＦプロファイルＤＢ）３０に格納される。ＲＤＦプロファイルＤＢ）３０は個人で管理されてもよく、また個人情報を管理するサービスプロバイダであってもよい。

あるタイミングでユーザがＲＤＦプロファイルをＲＤＦプロファイル情報源から取得すると、ＯＷＬ／ＲＤＦＳ推論部１１にＲＤＦプロファイルが伝わる。ＯＷＬ／ＲＤＦＳ推論部１１は、ＲＤＦＳ推論を行うＲＤＦＳ推論部とＯＷＬ推論を行うＯＷＬ推論部を有する。

ＲＤＦＳ推論部は、取得したＲＤＦプロファイル（入力ＲＤＦプロファイルと呼ぶ）に含まれるリソースのクラスを推論する。この推論には、あるリソースのクラスに対し、その上位概念であるクラスも当該リソースのクラスであることを利用する。また、プロパティのdomain/rangeの制約からクラスを推論する。ＲＤＦＳ推論の規則を定めた情報はＯＷＬ／ＲＤＦＳ定義データベース（ＯＷＬ／ＲＤＦＳ定義ＤＢ）１２に予め格納されている。

ＯＷＬ推論部は、等価的推論機能によってリソースのクラスを推論する。ここでは、あるリソースのクラスに対し、等価とされるクラスを推論する。ＯＷＬ推論の規則を定めた情報はＯＷＬ／ＲＤＦＳ定義ＤＢ１２に予め格納されている。

ＯＷＬ／ＲＤＦＳ推論部１１は、入力ＲＤＦプロファイルに対して、推論結果のクラス情報を各リソースに対応付けて付加する。ＯＷＬ／ＲＤＦＳ推論部１１によって新たにクラス情報が付加された入力ＲＤＦプロファイル（推論後入力ＲＤＦプロファイルと呼ぶ）は、ＵＲＩ統合処理部１３に渡される。

ＵＲＩ統合処理部１３は、取得した推論後入力ＲＤＦプロファイル中に、既にＲＤＦプロファイルＤＢ３０に格納されているリソースと同一のものが含まれているか判断する。この結果、ＲＤＦプロファイルＤＢ３０内のいずれかのリソースと同一であると判断された推論後入力ＲＤＦプロファイル中のリソースには、既にＲＤＦプロファイルＤＢ３０に格納されている同一リソースに割り当てられているＵＲＩを付与する。一方、ＲＤＦプロファイルＤＢ３０内のいずれのリソースとも同一ではないと判断された推論後入力ＲＤＦプロファイル中のリソースには、新たなＵＲＩを割り当てる。ＵＲＩ統合処理部１３は、推論後入力ＲＤＦプロファイルに対して、割り当て結果のＵＲＩを各リソースに対応付けて付加する。

ここで、推論後入力ＲＤＦプロファイル中のリソースに対してＲＤＦプロファイルＤＢ３０内のリソースに割り当て済みの同一ＵＲＩを割り当てるときには、双方のリソースが同一であるかを判断している。リソースはプロパティによって、その特性を表現するが、同じリソースと判断されるものは同一のプロパティと同一のリテラルが記述の中に含まれていると考えられる。そこで各プロパティで比較をして、同一のリテラルを持っていれば、同じリソースであると判断する。このＵＲＩ統合の規則を定めた情報はＵＲＩ変換ルール定義データベース（ＵＲＩ変換ルール定義ＤＢ）１４に予め格納されている。

ＵＲＩ付加後の推論後入力ＲＤＦプロファイル（ＵＲＩ統合処理後入力ＲＤＦプロファイルと呼ぶ）はＲＤＦプロファイルＤＢ３０に格納される。

このように、入力ＲＤＦプロファイルに含まれるリソースが既にＲＤＦプロファイルＤＢ３０に格納されているリソースと意味的に等しい場合には、該ＲＤＦプロファイルＤＢ３０内のリソースと同じＵＲＩが入力ＲＤＦプロファイル中のリソースに割り当てられる。これにより、ユーザが収集したＲＤＦプロファイルをＲＤＦプロファイルＤＢ３０に蓄積する際、ＲＤＦプロファイル間の関連付けを行うことができる。この結果、ＲＤＦプロファイルＤＢ３０に蓄積されたＲＤＦプロファイルの検索時において、ＲＤＦプロファイル間をまたがるような検索なども容易に実現可能となる。

また、入力ＲＤＦプロファイルに含まれるリソースのクラスの推論結果が当該ＲＤＦプロファイルに反映されるので、該推論結果に基づいてリソースの同一の判断を容易に行うことが可能となる。

本発明の一実施例を図２に示す。
ＲＤＦプロファイル提供者はそれぞれＲＤＦプロファイル情報源＃１、＃２、＃３、・・・を所有し、ユーザの実生活におけるプロファイル情報をＲＤＦの形式で提供する。ユーザは所持する携帯端末の持つ赤外線通信や、パッシブＲＦＩＤタグリーダ、インターネットといった各種のインタフェースを通してＲＤＦプロファイルを取得することができる。ここで取得したＲＤＦプロファイルを説明の便宜上、入力ＲＤＦプロファイル１と呼ぶ。

プロファイル情報としては、例えば、ユーザ本人の名前や血液型、年齢等がかかれた個人プロフィール情報、インターネットサービス等で記入する契約情報、商品を購入したときにもらう電子レシート（電子決済情報）、バーコードのような商品についたタグから得られる物品情報、またショッピングモールや駅ビル等でそのエリア情報を提供するエリア情報などがあげられる。
入力ＲＤＦプロファイル１の取得に使用されるインタフェースは異なることも考えられる。例えば、電子決済情報は赤外線インタフェースで入力されることもあれば、物品情報などはＲＦＩＤタグを介してインターネット上から取得することも考えられる。ここでプロファイル提供者が複数のＲＤＦプロファイル情報源を所持していてもよい。

入力ＲＤＦプロファイル１は、個人で管理するプロファイルアグリゲータ４０（プロファイル管理装置）と称されるサーバの内部にあるＲＤＦプロファイルＤＢ３０に格納される。プロファイルアグリゲータ４０は、ＵＲＩ統合装置１０と、ＲＤＦプロファイルＤＢ３０とを備える。
入力ＲＤＦプロファイル１はユーザにとって生活の中で得た一種のログ情報であり、ユーザはＵＲＩ統合装置１０で情報を加工した上でＲＤＦプロファイルＤＢ３０に格納する。

ＵＲＩ統合装置１０は、ＯＷＬ／ＲＤＦＳ推論部１１、ＯＷＬ／ＲＤＦＳ定義ＤＢ１２、ＵＲＩ統合処理部１３およびＵＲＩ変換ルール定義ＤＢ１４を有する。
ＯＷＬ／ＲＤＦＳ推論部１１は、入力ＲＤＦプロファイル１に含まれるリソースに関する情報を推論し、その推論した情報を入力ＲＤＦプロファイル１付与して推論後入力ＲＤＦプロファイル２を出力する。その推論の際にはＯＷＬ／ＲＤＦＳ定義ＤＢ１２を参照する。
ＵＲＩ統合処理部１３は、推論後入力ＲＤＦプロファイル２に対してＵＲＩ統合の処理を行う。そのＵＲＩ統合処理の際にはＵＲＩ変換ルール定義ＤＢ１４を参照する。

なお、本実施例１では、入力ＲＤＦプロファイル１はＸＭＬ（eXtended Markup Language）で記述されたＲＤＦデータを想定するが、ＲＤＦを表現することが可能であれば、他の記述言語（例えばN-Triples等）であっても構わない。

本実施例１で扱う入力ＲＤＦプロファイル１をＲＤＦモデルで表現した例を、図３（物品情報の入力ＲＤＦプロファイル）、及び図５（電子決済情報の入力ＲＤＦプロファイル）に示す。図３、図５に対応したインスタンスをＸＭＬ形式で記述したものをそれぞれ図４、図６に示す。

図３に示される例では、その商品の名前（kpro:object_name）や管理コード（kpro:object_ID）、製造国（kpro:place_of_production）、製造日（kpro:date_of_production）等の情報がプロパティとして記述されており、商品そのものをリソースとして扱っている。図３中の“rdf:type”は、そのリソースのクラス（タイプ）が何であるのかを意味するプロパティである。図３の例の場合、リソースは商品（#Artifacts）であることを記述している。図５に示される電子決済情報の例も同様である。但し、図５に示されるように、電子決済情報の場合には、レシートそのもの（#PurchaseHistory）、購入した商品（#Artifacts）、購入した場所（クラスの指定なし）の三つのリソースとそれぞれのプロパティが記述されている。

上記したような入力ＲＤＦプロファイル１は、それぞれ独立のＲＤＦプロファイル情報源から得られるが、各入力ＲＤＦプロファイル１を比較すると、プロパティとそのリテラルが同一の内容である場合がある。
例えば、図３及び図５では、斜線で示した部分でプロパティとそのリテラルは同一の内容となっている。したがって、これらは互いに同じリソースの情報を示していると考えることができる。これらに同じＵＲＩを入力ＲＤＦプロファイル１のリソースの部分に記述することで情報の統合を図ることができる。両入力ＲＤＦプロファイル１を合わせてＲＤＦのパーサで処理すれば、情報を統合した情報を生成することができる。

図７には、図３及び図５の各入力ＲＤＦプロファイル１を統合した場合のＲＤＦモデルの例が示されている。商品のリソースには“object_1”というＵＲＩを割り当てている。この統合処理によって例えば、電子レシート（電子決済情報）の購入価格情報は物品情報の製造国や製造日に関連付けられるので、電子レシートの購入価格情報から物品情報の製造国や製造日を索引することができる。

本実施例１に係る入力ＲＤＦプロファイル１の種類とそれに含まれるリソースの一覧を図８に表として示す。この例では、“人”、“サービス”、“エリア”、“商品”などがＵＲＩの統合対象として示されている。

以下、本実施例１に係るＵＲＩ統合装置１０の動作を詳細に説明する。

ＯＷＬ／ＲＤＦＳ推論部１１は、ＲＤＦＳ推論を行うＲＤＦＳ推論部とＯＷＬ推論を行うＯＷＬ推論部を有し、それら推論によって入力ＲＤＦプロファイル１にメタデータを付与する。

ＲＤＦＳ推論部は以下の二つの機能（Ａ１、Ａ２）を有する。
ＲＤＦＳ推論部は、入力ＲＤＦプロファイル１とＯＷＬ／ＲＤＦＳ定義ＤＢ１２に格納されているＲＤＦＳ定義データとを照合し、各機能Ａ１、Ａ２の処理を実行する。
（Ａ１）ＲＤＦＳ定義データで定義されているクラス間の継承関係（subclassOf）を適用し、下位クラスのリソースは上位クラスのリソースでもあるという定義に基づいて上位クラスのメタデータを追加する。
（Ａ２）ＲＤＦＳ定義データで定義されているプロパティの制約の情報を利用し、リソースが保持するプロパティから当該リソースのクラスを判断し、そのメタデータを追加する。

（Ａ１）クラス間継承関係の推移的適用についての説明
入力ＲＤＦプロファイル１中のリソースに対して“rdf:type”プロパティによるクラス指定がなされている場合、当該リソースはＲＤＦスキーマ中に定義されたスーパークラスのインスタンスでもあると推論される。このため、当該リソースには、スーパークラスに対する“rdf:type”プロパティを追加する。この具体例を図９、図１０に示す。図１０は図９中のＲＤＦＳ定義データの一部に対応するＸＭＬ形式の記述例である。

図９の例では、ＲＤＦＳ定義データにより、“kpro:UserVcard”は“kpro:Person”のサブクラスであることが示されている。ＲＤＦＳ推論部は、入力ＲＤＦプロファイル１をＲＤＦＳ定義データと照合し、合致した部分（図９中の斜線部分１０１）に関するＲＤＦＳ定義データ中のメタデータである“kpro:Person”（図９中の斜線部分１０２）を“rdf:type”プロパティにより入力ＲＤＦプロファイル１に追加記述し（図９中の斜線部分１０３）、推論後入力ＲＤＦプロファイル２とする。

（Ａ２）プロパティのdomain・range定義の適用についての説明
入力ＲＤＦプロファイル１中のリソースに対してプロパティによるリソース−リソース間またはリソース−リテラル間の定義がなされている場合には、ＲＤＦＳ定義データのプロパティに係るdomain・range定義部分に基づいて、各リソースに“rdf:type”プロパティによるクラスの指定を追加する。該当プロパティを“Predicate”とする“Statement”の“Subject”であるリソースには、“domain”として定義されたクラスの指定を追加し、“Object”であるリソースには、“range”として定義されたクラスの指定を追加する。この具体例を図１１、図１２に示す。図１２は図１１中のＲＤＦＳ定義データの一部に対応するＸＭＬ形式の記述例である。

図１１の例では、ＲＤＦＳ定義データにより、“kpro:Subscriber”プロパティには、“rdfs:domain”及び“rdfs:range”プロパティが定義されている。ＲＤＦＳ推論部は、入力ＲＤＦプロファイル１をＲＤＦＳ定義データと照合し、合致した“kpro:Subscriber”プロパティ（図１１中の斜線部分１１１）に関するＲＤＦＳ定義データ中の“rdfs:domain”のクラス“kpro:Account”（図１１中の斜線部分１１２）及び“rdfs:range”のクラス“kpro:Person”（図１１中の斜線部分１１３）を“rdf:type”プロパティにより入力ＲＤＦプロファイル１に追加記述し（図１１中の斜線部分１１４、１１５）、推論後入力ＲＤＦプロファイル２とする。なお、“rdfs:domain”は基本プロパティの一つであり、あるプロパティがどんなクラスのリソースに適応できるのかを表している。また“rdfs:range”はそのプロパティがどんなクラスの値をとるのかを示している。

ＯＷＬ推論部は以下の機能（Ｂ１）を有する。
ＯＷＬ推論部は、入力ＲＤＦプロファイル１とＯＷＬ／ＲＤＦＳ定義ＤＢ１２に格納されているＯＷＬ定義データとを照合し、機能Ｂ１の処理を実行する。
（Ｂ１）クラス・プロパティの等価的推論によってプロパティ、クラス情報を入力ＲＤＦプロファイル１に追加する。ＯＷＬ定義データには、等価的なクラス又は等価的なプロパティの組み合わせが定義されている。ＯＷＬ定義データ中の“owl:equivalentClass”、“owl:equivalentProperty”で定義された情報に基づいて等価的なクラス、等価的なプロパティを判断し、入力ＲＤＦプロファイル１に記述を追加する。この具体例を図１３〜図１８に示す。図１３には入力ＲＤＦプロファイル１の例、図１５にはＯＷＬ定義データの例、図１７には等価的推論後の推論後入力ＲＤＦプロファイル２の例が示されている。図１４、図１６、図１８は、図１３、図１５、図１７に対応するＸＭＬ形式の記述例である。

この例では、図１５のＯＷＬ定義データによれば、図１３の入力ＲＤＦプロファイル１中の“kpro:email”は“foaf:mbox”と等価であることが示されている。ＯＷＬ推論部は、入力ＲＤＦプロファイル１をＯＷＬ定義データと照合し、合致した部分（“kpro:email”）に関するＲＤＦＳ定義データ中の“foaf:mbox”プロパティを入力ＲＤＦプロファイル１に追加記述し（図１７参照）、推論後入力ＲＤＦプロファイル２とする。これにより、後のＵＲＩ統合処理において統合の可能性を向上させることが可能となる。

次に、ＵＲＩ統合処理部１３の動作を説明する。
ＵＲＩ統合処理部１３は、推論後入力ＲＤＦプロファイル２に含まれるリソースとＲＤＦプロファイルＤＢ３０に格納されているＲＤＦプロファイルのリソースを比較して、リソースにＵＲＩを割り当てる機能を有する。

入力ＲＤＦプロファイル１におけるリソースの記述は次の書き出しで始まっている。
<rdf:description>
ＵＲＩをリソースに指定する場合には次のような書き出しで記述される。
<rdf:description about=”object_1”>

つまり、入力ＲＤＦプロファイル１のこの部分にＵＲＩ情報を追加することで、リソースにＵＲＩの付与は完了する。本実施例１では、具体的にはこの部分に、ＵＲＩを書き加えてデータを統合管理することになる。

ＵＲＩ統合処理部１３はＵＲＩの割り当てを決定する機能を有する。具体的には、推論後入力ＲＤＦプロファイル２に含まれるリソースとＲＤＦプロファイルＤＢ３０に格納されているＲＤＦプロファイルのリソースを比較して、両者が同一リソースと判断されると統一のＵＲＩを書き加える。異なると判断された場合には、異なるＵＲＩを付与する。

ＵＲＩ統合処理部１３は、ＵＲＩ変換ルール定義ＤＢ１４に格納されているＵＲＩ変換ルール定義データを参照し、ＵＲＩ変換ルール定義データに定義されているルールに従ってＵＲＩ統合処理を行う。以下、ＵＲＩ変換ルール定義データで定義するルール（Ｃ１、Ｃ２）を説明する。

（Ｃ１）マッチング（MatchingProperties）
ＵＲＩを統合する必要があるとされたクラスに属するリソースに関し、次に示す特徴を有する各リソースは同一であると判定する。
特徴；共通のプロパティを持ち、且つ、共通するすべてのプロパティが等価の値を持つ。
同一と判断した各リソースに対しては同一ＵＲＩを付与する。一方、同一ではないと判断したリソースに対しては、同一タイプのリソースに付与済みのＵＲＩの最大値に１加算した値のＵＲＩを付与する。

（Ｃ２）連番付与（IncrementURI）
既存リソースと混同しないように重複しないＵＲＩを付与される必要があるとされたクラスに属するリソースに対しては、常に異なるリソースと判断し、同一タイプのリソースに付与済みのＵＲＩの最大値に１加算した値のＵＲＩを付与する。

上記ルール（Ｃ１、Ｃ２）のいずれを適用するのかは、リソースのタイプごとに、定義ファイル（integrateRule.xml）に記述する。
定義ファイル（integrateRule.xml）の記述方法；タイプ名ごとに、以下のセットを記述する。
type：リソースのタイプ名を記述
name：“MatchingProperties”、“IncrementURI”のいずれかを記述
targetModelName：そのタイプのリソースが属するモデル名を記述
excludePredicate：ルール適用の際の比較対象としないプロパティ名を記述
（このプロパティの値が異なっていても、同一リソースか否かの判断に影響しない）

物品情報（type:Artifact）の定義ファイル（integrateRule.xml）の例を図１９に示す。この例では、マッチング（MatchingProperties）が適用されている。なお、基本的にはマッチング又は連番付与のいずれかのルールを適用するが、いずれのルールも適用したくない場合は、定義ファイル（integrateRule.xml）中に<defineRule>を記述しないようにする。

図２０を参照して、ＵＲＩ統合処理部１３の全体的な処理手順を説明する。
ＵＲＩ統合処理部１３は、推論後入力ＲＤＦプロファイル２に含まれるリソースに関し、各タイプのリソースごとに以下のステップＳ１〜Ｓ４の処理を繰り返す。
ステップＳ１では、推論後入力ＲＤＦプロファイル２（推論後モデル）からある一つタイプに属するリソースを抽出する。
ステップＳ２では、ＲＤＦプロファイルＤＢ３０に格納されているＲＤＦプロファイルから、ステップＳ１と同じタイプに属するリソースを抽出する。
ステップＳ３では、ステップＳ１で抽出したリソースをステップＳ２で抽出したリソースの１つずつと比較し、同一リソースであるか否かを判断する。
ステップＳ４では、ステップＳ３の判断結果に応じて、ＵＲＩの付与を行う。同一リソースであると判断した場合には、ステップＳ２で抽出した同一リソースと同じＵＲＩをステップＳ１で抽出したリソースに付与する。一方、同一リソースであると判断しなかった場合には、ステップＳ２で抽出したリソースのＵＲＩのうちの最大値に１加算した値をステップＳ１で抽出したリソースのＵＲＩとして付与する。

上記ステップＳ１、Ｓ２におけるリソースの抽出にはＲＤＱＬ等のクエリ言語を用いる。図２１にはＲＤＱＬの記述例が示されている。この例は、タイプが“#Artifact”であるリソースの検索を行うためのものである。

上記ステップＳ３におけるリソースの比較の際には、まず、推論後入力ＲＤＦプロファイル２から、ステップＳ１で抽出したリソースを主語とする“Statement”を抽出する（Ｓ３−１）。具体的には、図２２に示されるＲＤＱＬの記述例を用いて、ステップＳ１で抽出したリソース（RESOURCE）を主語とするStatementを抽出する。次いで、ＲＤＦプロファイルＤＢ３０から、同様にステップＳ２で抽出したリソースを主語とする“Statement”を抽出する（Ｓ３−２）。次いで、その抽出した双方の“Statement”から述語が同じ“Statement”の目的語を抽出し、比較する（Ｓ３−３）。具体的には、図２２に示されるＲＤＱＬの記述例を用いて、述語が同じ“Statement”の目的語を抽出する。但し、述語を“PREDICATE”とし、主語は“RESOURCE”とする。このＲＤＱＬの記述例は図２３に示されている。次いで、目的語が同一（リソースの場合はＵＲＩが等しい、リテラルの場合は値が等しい）であれば、上記ステップＳ３−１に戻り、次の述語の比較を行う。一方、目的語が異なっていれば、ステップＳ１で抽出したリソースとステップＳ２で抽出したリソースは同一ではないと判断する（Ｓ３−４）。上記ステップＳ３−３、Ｓ３−４を繰り返した結果、全ての“Statement”について、その目的語が同一であれば、ステップＳ１で抽出したリソースとステップＳ２で抽出したリソースは同一であると判断する（Ｓ３−５）。

上記ステップＳ４における、同一リソースであると判断しなかった場合のＵＲＩの連番付与の処理の手順が図２４に示されている。
各タイプのリソースごとに以下のステップＳ４−１〜Ｓ４−３の処理を繰り返す。
ステップＳ４−１では、推論後入力ＲＤＦプロファイル２（推論後モデル）からある一つタイプに属するリソースを抽出する。
ステップＳ４−２では、ＲＤＦプロファイルＤＢ３０に格納されているＲＤＦプロファイルから、ステップＳ４−１と同じタイプに属するリソースを抽出し、ＵＲＩの最大値を取得する。
ステップＳ４−３では、ステップＳ４−２で取得したＵＲＩの最大値に１加算して、ステップＳ４−１で抽出したリソースのＵＲＩとする。

図２５には、ＵＲＩ統合処理部１３の処理フローが示されている。図２５を参照して、ＵＲＩ統合処理部１３の動作を説明する。ここでは、図２６〜図２９に示される具体例を用いて説明する。図２６は推論後入力ＲＤＦプロファイル２（推論後モデル）の例である。図２８はＲＤＦプロファイルＤＢ３０に格納されているＲＤＦプロファイル３００の例である。図２７、図２９は、図２６、図２８に対応するＸＭＬ形式の記述例である。

図２５において、まず、ＵＲＩ統合処理部１３は、推論後入力ＲＤＦプロファイル２に含まれるリソースの“rdf:type”属性であるクラスの全種類を抽出する（ステップＳ１１）。“rdf:type”はリソースのクラスを示すプロパティである。図２６の例では、“class:I”及び“class:II”の２種類のクラスが抽出される。

次いで、ＵＲＩ統合処理部１３は、ステップＳ１１で抽出した全種類のクラスに関し、リソース毎のＵＲＩ統合処理を開始する（ステップＳ１２）。

ステップＳ１３では、一つのクラスを対象とし、推論後入力ＲＤＦプロファイル２から当該クラスのリソースを全て抽出する。図２６の例では、まず“class:I”を対象とし、該当するリソース２０１が抽出される。

ステップＳ１４では、ステップＳ１３と同じクラスを対象とし、ＲＤＦプロファイルＤＢ３０から当該クラスのリソースを全て抽出する。図２８の例では、“class:I”のリソース３０１が抽出される。

ステップＳ１５では、ステップＳ１３で抽出したリソースとステップＳ１４でで抽出したリソースの各組み合わせに対して、プロパティとそのリテラルを比較する。各組み合わせの比較結果に基づき、以降のＵＲＩ割り当て判断を行う。
まず、ステップＳ１６では、ある一つの組み合わせに関し、一つでも共通のプロパティを有しているか判断する。共通のプロパティを有する場合には、共通のプロパティの中で、それぞれ共通のリテラルを有しているか判断する（ステップＳ１７）。共通のプロパティの中で、それぞれ共通のリテラルを有しているならば、当該組み合わせのリソースは同一であると判断する（ステップＳ１８）。

図２６、図２８の例では、“class:I”のリソース２０１、３０１に関し、プロパティとそのリテラルの比較が行われる。リソース２０１は、３つのプロパティ“Ａ”、“Ｂ”、“Ｅ”を有し、そのリテラルは“あ”、“い”、“え”である。リソース３０１は、３つのプロパティ“Ａ”、“Ｂ”、“Ｃ”を有し、そのリテラルは“あ”、“い”、“う”である。従って、リソース２０１、３０１は共通のプロパティ“Ａ”、“Ｂ”を有している。それら共通のプロパティ“Ａ”、“Ｂ”の各リテラルは、リソース２０１では“あ”、“い”、リソース３０１も同じ“あ”、“い”である。つまり、リソース２０１、３０１に関して、共通のプロパティ“Ａ”、“Ｂ”の中で、それぞれ共通のリテラル“あ”、“い”を有している。これにより、リソース２０１、３０１は同一のリソースであると判断する。

次いで、ステップＳ１９では、当該組み合わせに関して、推論後入力ＲＤＦプロファイル２のリソースに対して、同一であると判断したＲＤＦプロファイルＤＢ３０内のリソースに割り当てているＵＲＩを割り当てる。図２６、図２８の例では、リソース３０１に割り当てられているＵＲＩ“resource:2”がリソース２０１にも割り当てられる。

上記ステップＳ１６の判断の結果、一つも共通のプロパティを有していない場合には、当該組み合わせのリソースは異なると判断する（ステップＳ２０）。次いで、現対象のクラスに関し、他にＲＤＦプロファイルＤＢ３０から抽出したリソースがあるか判断し（ステップＳ２１）、他のリソースがある場合にはステップＳ１５に戻り、現対象の推論後入力ＲＤＦプロファイル２のリソースが他のリソースと同一であるのか検査する処理を行う。一方、他のリソースがない場合には、現対象の推論後入力ＲＤＦプロファイル２のリソースに対して、新規のＵＲＩを割り当てる（ステップＳ２２）。

ステップＳ２３では、上記ステップＳ１９又はＳ２２で割り当てたＵＲＩを推論後入力ＲＤＦプロファイル２の該当リソースに付加する記述を追加する。図２６の例では、リソース２０１に対して“resource:2”の記述が追加される。また、図２７のＸＭＬ形式の記述例では、<rdf:description>タグ２１１に“resource:2”の記述が追加されて、<rdf:description about=”resource:2”>と記述される。

ステップＳ２４では、現対象のクラスに関し、推論後入力ＲＤＦプロファイル２のリソースであって、未だＵＲＩを割り当てていないリソースがあるか判断する。未だＵＲＩを割り当てていないリソースがある場合には、ステップＳ１５に戻り、ＵＲＩ未割り当てのリソースに対する上記した同一のリソースを調査する処理を行う。一方、現対象のクラスに関し、全リソースに対するＵＲＩの割り当てが完了した場合には、未だＵＲＩ統合処理を行っていないクラスがあるか判断する（ステップＳ２５）。未だＵＲＩ統合処理を行っていないクラスがある場合には、ステップＳ１３に戻り、ＵＲＩ統合処理の未実行のクラスに対する上記したＵＲＩ統合処理を行う。

図２６、図２８の例では、“class:II”のクラスに対するＵＲＩ統合処理が未実行であるので、“class:II”のクラスに対するＵＲＩ統合処理が行われる。この結果、図２８の例では、ＲＤＦプロファイルＤＢ３０内には“class:II”のリソースが存在しないので、図２６の推論後入力ＲＤＦプロファイル２の“class:II”のリソース２０２に対しては新規のＵＲＩが割り当てられる。

ＵＲＩ統合処理部１３は、推論後入力ＲＤＦプロファイル２の全リソースに対するＵＲＩの割り当てが完了すると、ＵＲＩの記述が追加された推論後入力ＲＤＦプロファイル２（ＵＲＩ統合処理後入力ＲＤＦプロファイル３）をＲＤＦプロファイルＤＢ３０に格納する（ステップＳ２６）。

図３０には、上記したＵＲＩ統合処理の概要が示されている。図３０に示されるように、ＵＲＩ統合処理部１３は、推論後入力ＲＤＦプロファイル２のリソースと同じリソースがＲＤＦプロファイルＤＢ３０内に格納されているかを逐一調査する。そして、ＲＤＦプロファイルＤＢ３０内に同じリソースが発見された場合には、該発見したリソースと同じＵＲＩを推論後入力ＲＤＦプロファイル２のリソースに付与する。一方、ＲＤＦプロファイルＤＢ３０内に同じリソースが発見されなかった場合には、推論後入力ＲＤＦプロファイル２のリソースに新規のＵＲＩを付与する。

本発明の実施例２を図３１に示す。図３１にはＵＲＩ統合処理部１３に係る構成のみを示している。ＵＲＩ統合処理部１３以外の構成は上記実施例１と同様であり、その説明省略する。
図３１において、ＵＲＩ統合処理部１３はＵＲＩ統合インデックス情報４０をメモリに記憶する。ＵＲＩ統合インデックス情報４０は、ＲＤＦプロファイルＤＢ３０に格納されているリソースの索引情報であり、リソースの“rdf:type”属性であるクラス毎に有される。ＵＲＩ統合インデックス情報４０は、リソースのＵＲＩ、該ＵＲＩを有するリソースに共通のプロパティ及びそのリテラルの組み合わせから成る。

図３１に示されるＵＲＩ統合インデックス情報４０の例は、クラス“Artifact”についてのＵＲＩ統合インデックス情報の例が示されており、クラス“Artifact”に属するリソースのＵＲＩと共通のプロパティ“object_ID”とリテラルの組み合わせから構成されている。この例では、ＲＤＦプロファイルＤＢ３０内のクラス“Artifact”のリソースに関し、共通のプロパティ“object_ID”を有するリソースのリテラルが一覧となっている。従って、推論後入力ＲＤＦプロファイル２のクラス“Artifact”のリソースであってプロパティ“object_ID”を有するリソースならば、そのリテラルをキーにして図３１のＵＲＩ統合インデックス情報を検索することにより、同じリソース（同じリテラルを有するリソース）を容易に探索することができる。これにより、ＵＲＩ統合処理の処理量は大幅に削減され、処理時間の短縮が可能となる。

図３１において、ＵＲＩ統合処理部１３は、推論後入力ＲＤＦプロファイル２に含まれるリソースが属する各クラスに関し、該当するＵＲＩ統合インデックス情報４０を検索して同一リソースの有無を判断する。この検索結果の情報（ＵＲＩ統合適応リソース情報）に基づき、ＵＲＩ統合処理部１３は、推論後入力ＲＤＦプロファイル２に含まれるリソースに対するＵＲＩの割り当てを行う。

図３１に示される例では、推論後入力ＲＤＦプロファイル２にはクラス“Artifact”のリソースが含まれており、当該リソースはプロパティ“object_ID”を有し、そのリテラルは“００３”である（符号４０１部分）。また、クラス“Artifact”のＵＲＩ統合インデックス情報４０には、共通のプロパティ“object_ID”を有し、そのリテラルは“００３”であるリソースのＵＲＩ“object_3”が含まれている（符号４０２部分）。これにより、ＵＲＩ統合処理部１３は、推論後入力ＲＤＦプロファイル２のクラス“Artifact”のリソース（プロパティ“object_ID”且つリテラル“００３”）に対して、リテラル“００３”を用いてＵＲＩ統合インデックス情報４０を検索することにより、同一リソースに割り当てられているＵＲＩ“object_3”を発見することができる。そして、その発見したＵＲＩ“object_3”を推論後入力ＲＤＦプロファイル２に含まれる当該リソースに対して付加する。

ＵＲＩ統合処理部１３は、ＵＲＩ統合インデックス情報４０内に該当する情報（同一リソースに割り当てられているＵＲＩ）を発見することができなかった場合には、新規のＵＲＩを推論後入力ＲＤＦプロファイル２に含まれる当該リソースに対して付加する。新規のＵＲＩを付加した場合には、ＵＲＩ統合インデックス情報４０に該新規ＵＲＩの情報を追加してＵＲＩ統合インデックス情報４０を更新する。

上述した実施例２によれば、ＵＲＩ統合インデックス情報４０を設けることによって、ＲＤＦプロファイルＤＢ３０へアクセスする際の負荷を低減することができる。これによってＲＤＦプロファイルＤＢ３０内のデータ量が増大した場合の処理負荷を軽減することができ、パフォーマンスの向上を図ることが可能となる。

なお、各クラスに対してＵＲＩ統合インデックス情報４０を利用可能なＲＤＦプロファイルＤＢ３０内のデータ件数を指定するようにしてもよい。これにより、ＲＤＦプロファイルＤＢ３０内のデータ量が少ない場合には、ＵＲＩ統合インデックス情報４０を検索する処理を省き、直接にＲＤＦプロファイルＤＢ３０を検索して処理効率を高めることが可能となる。

なお、図２、図３１に示す各実施例に係るＵＲＩ統合装置の機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより、プロファイル情報を管理する処理を行ってもよい。なお、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものであってもよい。
また、「コンピュータシステム」は、ＷＷＷシステムを利用している場合であれば、ホームページ提供環境（あるいは表示環境）も含むものとする。
また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、フラッシュメモリ等の書き込み可能な不揮発性メモリ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。

さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリ（例えばＤＲＡＭ（Dynamic Random Access Memory））のように、一定時間プログラムを保持しているものも含むものとする。
また、上記プログラムは、このプログラムを記憶装置等に格納したコンピュータシステムから、伝送媒体を介して、あるいは、伝送媒体中の伝送波により他のコンピュータシステムに伝送されてもよい。ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワーク（通信網）や電話回線等の通信回線（通信線）のように情報を伝送する機能を有する媒体のことをいう。
また、上記プログラムは、前述した機能の一部を実現するためのものであっても良い。さらに、前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であっても良い。

以上、本発明の実施形態を図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、本発明の要旨を逸脱しない範囲の設計変更等も含まれる。

本発明の一実施形態に係るプロファイル管理装置の構成を示すブロック図である。 本発明の実施例１の構成を示すブロック図である。 入力ＲＤＦプロファイル１の構成例を示す図である。 入力ＲＤＦプロファイル１のインスタンスの記述例を示した図である。 入力ＲＤＦプロファイル１の構成例を示す図である。 入力ＲＤＦプロファイル１のインスタンスの記述例を示した図である。 図３と図５を統合した例を示す図である。 入力ＲＤＦプロファイル１の種類とそれに含まれるリソースの一覧を示す図表である。 本発明の実施例１に係るＲＤＦＳ推論処理を説明するための図である。 図９に示すＲＤＦＳ定義データの一部に対応する記述例である。 本発明の実施例１に係るＲＤＦＳ推論処理を説明するための図である。 図１１に示すＲＤＦＳ定義データの一部に対応する記述例である。 本発明の実施例１に係るＯＷＬ推論処理を説明するための入力ＲＤＦプロファイル１の例である。 図１３に示す入力ＲＤＦプロファイル１に対応する記述例である。 本発明の実施例１に係るＯＷＬ推論処理を説明するためのＯＷＬ定義データの例である。 図１５に示すＯＷＬ定義データに対応する記述例である。 本発明の実施例１に係るＯＷＬ推論処理を説明するための推論後入力ＲＤＦプロファイル２の例である。 図１７に示す推論後入力ＲＤＦプロファイル２に対応する記述例である。 本発明の実施例１に係る定義ファイル（integrateRule.xml）の例である。 本発明の実施例１に係るＵＲＩ統合処理部１３の全体的な処理手順を説明するための処理フロー図である。 本発明の実施例１に係るＲＤＱＬの記述例である。 本発明の実施例１に係るＲＤＱＬの記述例である。 本発明の実施例１に係るＲＤＱＬの記述例である。 本発明の実施例１に係るＵＲＩの連番付与の処理フロー図である。 本発明の実施例１に係るＵＲＩ統合処理部１３の処理フロー図である。 本発明の実施例１に係るＵＲＩ統合処理を説明するための推論後入力ＲＤＦプロファイル２の例である。 図２６に示す推論後入力ＲＤＦプロファイル２に対応する記述例である。 本発明の実施例１に係るＵＲＩ統合処理を説明するためのＲＤＦプロファイルＤＢ３０に格納されているＲＤＦプロファイル３００の例である。 図２８に示すＲＤＦプロファイル３００に対応する記述例である。 本発明の実施例１に係るＵＲＩ統合処理部１３の概要を示す図である。 本発明の実施例２に係るＵＲＩ統合処理部１３の概要を示す図である。 ＲＤＦ記述のモデル化の例を示す図である。

符号の説明

１…入力プロファイル、１０…ＵＲＩ統合装置、１１…ＯＷＬ／ＲＤＦＳ推論部、１２…ＯＷＬ／ＲＤＦＳ定義ＤＢ、１３…ＵＲＩ統合処理部、１４…ＵＲＩ変換ルール定義ＤＢ、３０…ＲＤＦプロファイルＤＢ

Claims (7)

1. ユーザが個別に取得するＲＤＦによって記述されたプロファイル情報をデータベースに蓄積し管理するプロファイル管理装置であって、
   前記取得したプロファイル情報に含まれるリソースのクラスを推論し、推論結果のクラスの情報を当該プロファイル情報に付加する推論手段と、
   前記データベースに格納されているプロファイル情報に含まれるリソースの識別情報と該リソースの属性情報とが関連づけられて記憶されている記憶手段と、
   前記クラスの情報の付加後のプロファイル情報に含まれるリソースの属性情報に対応するリソースの識別情報を前記記憶手段から読み出し、該読み出されたリソースの識別情報を前記クラスの情報の付加後のプロファイル情報に含まれるリソースに付与する識別情報統合手段と、
   を備えたことを特徴とするプロファイル管理装置。
2. 前記識別情報統合手段は、前記記憶手段に前記クラスの情報の付加後のプロファイル情報に含まれるリソースの属性情報と同一の属性情報が記憶されているか否かを判定し、同一の属性情報が記憶されていると判定した場合、前記クラスの情報の付加後のプロファイル情報に含まれるリソースの属性情報に対応するリソースの識別情報を前記記憶手段から読み出し、該読み出されたリソースの識別情報を前記クラスの情報の付加後のプロファイル情報に含まれるリソースに付与し、同一の属性情報が記憶されていないと判定した場合、新たな識別情報を前記クラスの情報の付加後のプロファイル情報に含まれるリソースに付与することを特徴とする請求項１に記載のプロファイル管理装置。
3. 前記識別情報統合手段は、前記クラス毎に前記記憶手段に記憶された前記リソースの識別情報を利用可能となる前記データベース内のデータ件数を指定することを特徴とする請求項１または請求項２に記載のプロファイル管理装置。
4. 前記推論手段は、
   クラス間の継承関係が定義された第１の定義データを有し、
   前記第１の定義データに基づき、あるリソースのクラスに対し、その上位概念であるクラスも当該リソースのクラスであると判断することを特徴とする請求項１から請求項３のいずれか１項に記載のプロファイル管理装置。
5. 前記推論手段は、
   プロパティの制約が定義された第２の定義データを有し、
   前記第２の定義データに基づき、リソースが保持するプロパティから当該リソースのクラスを判断することを特徴とする請求項１から請求項３のいずれか１項に記載のプロファイル管理装置。
6. 前記推論手段は、
   等価的なクラス又は等価的なプロパティの組み合わせが定義された第３の定義データを有し、
   前記第３の定義データに基づき、あるリソースのクラスに対し、等価とされるクラス又はプロパティを判断することを特徴とする請求項１から請求項３のいずれか１項に記載のプロファイル管理装置。
7. ユーザが個別に取得するＲＤＦによって記述されたプロファイル情報をデータベースに蓄積し管理するためのコンピュータプログラムであって、前記データベースに格納されているプロファイル情報に含まれるリソースの識別情報と該リソースの属性情報とが関連づけられて記憶されている記憶手段を備えるプロファイル管理装置のコンピュータに、
   前記取得したプロファイル情報に含まれるリソースのクラスを推論し、推論結果のクラスの情報を当該プロファイル情報に付加する機能と、
   前記クラスの情報の付加後のプロファイル情報に含まれるリソースの属性情報に対応するリソースの識別情報を前記記憶手段から読み出し、該読み出されたリソースの識別情報を前記クラスの情報の付加後のプロファイル情報に含まれるリソースに付与する機能と、
   を実現させることを特徴とするコンピュータプログラム。

Images