(57)【要約】【課題】ＲＤＦプロファイル情報間に新たな価値を持たせ、ユーザに対し、検索等を行う際に利便性を与える。【解決手段】ＵＲＩ統合装置１０が、取得したプロファイル情報に含まれる対象と分類を抽出して既存の対象との比較を行い、既存の対象と同一であると判断されたときその対象の識別情報を付与し、新規に取得した対象であると判断されたときに新たな認識情報を付与する。このことにより、これまで独立に管理されてきたプロファイル提供者からのプロファイル情報を互いに関連付け、ＲＤＦプロファイル情報間に新たな価値を持たせることができる。【選択図】      図１
2005242934.tif 000002
【特許請求の範囲】
【請求項１】
ユーザが個別に取得するＲＤＦによって記述されたプロファイル情報を管理するプロファイル管理装置であって、
前記取得したプロファイル情報に含まれる対象と語彙を抽出して既存の対象との比較を行い、既存の対象と同一であると判断されたときにその対象の識別情報を付与し、新規に取得した対象であると判断されたときに新たな識別情報を付与する識別情報統合装置を備えたことを特徴とするプロファイル管理装置。
【請求項２】
前記識別情報統合装置は、
ＲＤＦプロファイル情報源から取得したプロファイル情報に含まれる対象と語彙を抽出して既存の対象との比較を行うリソース比較部と、
ＲＤＦプロファイル蓄積部に蓄積される前記既存の対象を管理するＲＤＦスキーマ管理部と、
前記リソース比較部で比較の結果判断され付与される識別情報を追記もしくは編集するＲＤＦプロファイル更新部と、
前記取得したＲＤＦプロファイルを蓄積する前記ＲＤＦプロファイル蓄積部と、
を備えたことを特徴とする請求項１に記載のプロファイル管理装置。
【請求項３】
前記リソース比較部は、
前記対象が持つプロパティ情報を比較し、その適合度によって類似性を判定し、前記識別情報の付与を決定することを特徴とする請求項２に記載のプロファイル管理装置。
【請求項４】
前記ＲＤＦスキーマ管理部は、
前記対象をその語彙毎に管理することを特徴とする請求項２に記載のプロファイル管理装置。
【請求項５】
ユーザが個別に取得するＲＤＦによって記述されたプロファイル情報を管理するプロファイル管理装置に用いられるプログラムであって、
前記取得したプロファイル情報に含まれる対象と語彙を抽出して既存の対象との比較を行う処理と、
前記比較の結果、既存の対象と同一であると判断されたときにその対象の識別情報を付与し、新規に取得した対象であると判断されたときに新たな識別情報を付与し、当該付与された識別情報を追記もしくは編集する処理と、
をコンピュータに実行させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ユーザが個別に取得するＲＤＦ（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.
【発明の開示】
【発明が解決しようとする課題】
【０００７】
本発明は、上記した背景技術に鑑みてなされたものであり、異なる情報源から得たＲＤＦデータに対し、記述された対象（リソース）で内容が同一と判断されるものに固有の識別情報を付与することで各種ＲＤＦデータを意味的に統合し、このことにより、ＲＤＦプロファイル情報間に新たな価値を持たせ、ユーザに対し、検索等を行う際に利便性を与えることのできるプロファイル管理装置およびそのプログラムを提供することを目的とする。
【課題を解決するための手段】
【０００８】
上記した課題を解決するために本発明は、ユーザが個別に取得するＲＤＦによって記述されたプロファイル情報を管理するプロファイル管理装置であって、前記取得したプロファイル情報に含まれる対象と語彙を抽出して既存の対象との比較を行い、既存の対象と同一であると判断されたときにその対象の識別情報を付与し、新規に取得した対象であると判断されたときに新たな識別情報を付与する識別情報統合装置を備えたことを特徴とする。
【０００９】
また、本発明において、前記識別情報統合装置は、ＲＤＦプロファイル情報源から取得したプロファイル情報に含まれる対象と語彙を抽出して既存の対象との比較を行うリソース比較部と、ＲＤＦプロファイル蓄積部に蓄積される前記既存の対象を管理するＲＤＦスキーマ管理部と、前記リソース比較部で比較の結果判断され付与される識別情報を追記もしくは編集するＲＤＦプロファイル更新部と、前記取得したＲＤＦプロファイルを蓄積する前記ＲＤＦプロファイル蓄積部と、を備えたことを特徴とする。
【００１０】
また、本発明において、前記リソース比較部は、前記対象が持つプロパティ情報を比較し、その適合度によって類似性を判定し、前記識別情報の付与を決定することを特徴とする。
【００１１】
また、本発明において、前記ＲＤＦスキーマ管理部は、前記対象をその語彙毎に管理することを特徴とする。
【００１２】
上記した本発明のプロファイル管理装置の作用について図１を用いて説明すれば以下のようになる。すなわち、図１に示すＵＲＩ統合装置１０において、入力ファイル１としてのＲＤＦプロファイル情報源は、ユーザに対してＲＤＦで記述されたプロファイル情報を提供する。ＲＤＦプロファイルはユーザにとっての一種の行動ログであり、取得された情報はＲＤＦプロファイルＤＢ３０に蓄積される。ＲＤＦプロファイルＤＢ３０は個人で管理されてもよく、また個人情報を管理するサービスプロバイダであってもよい。
【００１３】
あるタイミングでユーザがＲＤＦプロファイルをＲＤＦプロファイル情報源から取得すると、ＲＤＦプロファイル更新部１２にＲＤＦプロファイルが伝わる。その情報はリソース比較部１１にも伝わり、リソース比較部１１ではＲＤＦプロファイルに含まれるリソースとそのクラス情報が抽出される。リソース比較部１１はＲＤＦスキーマ管理部３にアクセスし、同一であるクラスのリソースを検索する。そこで得た既に存在しているリソースと新しく得たリソースとのマッチングを行う。既に存在するものと同一と判断されると新規に得たリソースに対してマッチングしたリソースのＵＲＩとする。また新規に得たリソースであると判断された場合には新たなＵＲＩを割り当てる。そしてＲＤＦスキーマ管理部１３にそのリソース情報を登録する。
【００１４】
同一のＵＲＩを割り当てるためには、その判断が必要である。リソースはプロパティによって、その特性を表現するが、同じリソースと判断されるものは同一のプロパティと同一のリテラルが記述の中に含まれていると考えられる。そこで各プロパティで比較をして、同一のリテラルを持っていれば、同じリソースと判断する。更新されたＲＤＦプロファイルはＲＤＦプロファイルＤＢ３０に蓄積され、一通りのＵＲＩ統合処理が完了する。
このように、取得したＲＤＦプロファイルに含まれるリソースが既にある情報と意味的に等しい場合には、同じＵＲＩが割り当てられることにより、ＲＤＦプロファイル間で情報の統合化がなされるため、ＲＤＦプロファイル情報の間に新たな価値を生成させることを可能になる。
【００１５】
上記した課題を解決するために本発明は、ユーザが個別に取得するＲＤＦによって記述されたプロファイル情報を管理するプロファイル管理装置に用いられるプログラムであって、前記取得したプロファイル情報に含まれる対象と語彙を抽出して既存の対象との比較を行う処理と、前記比較の結果、既存の対象と同一であると判断されたときにその対象の識別情報を付与し、新規に取得した対象であると判断されたときに新たな識別情報を付与し、当該付与された識別情報を追記もしくは編集する処理と、をコンピュータに実行させることを特徴とする。
【発明の効果】
【００１６】
本発明によれば、識別情報統合装置が、取得したプロファイル情報に含まれる対象と語彙を抽出して既存の対象との比較を行い、既存の対象と同一であると判断されたときにその対象の識別情報を付与し、新規に取得した対象であると判断されたときに新たな識別情報を付与することで、これまで独立に管理されてきたプロファイル提供者からのプロファイル情報を互いに関連付けることが可能になる。このことにより、情報間に新たな価値を生成することができ、このため、ユーザにとっては個人目的のユーザ管理や蓄積されたＲＤＦプロファイルの検索など、利便性を向上させることができる。
【発明を実施するための最良の形態】
【００１７】
以下、図２以降を参照して本発明の実施の形態を詳細に説明する。図２は、本発明のプロファイル管理装置の実施形態を示すブロック図である。
ＲＤＦプロファイル提供者はそれぞれＲＤＦプロファイル情報源＃０〜＃２を所有し、ユーザの実生活におけるプロファイル情報をＲＤＦの形式で情報を提供する。ユーザは所持する携帯端末の持つ赤外線通信や、パッシブＲＦＩＤタグリーダ、インターネットといった各種のインタフェースを通してＲＤＦプロファイルを取得することができる。ここで取得したＲＤＦプロファイルを説明の便宜上、入力ＲＤＦプロファイル１と呼ぶ。
【００１８】
プロファイル情報としては、例えば、ユーザ本人の名前や血液型、年齢等がかかれた個人プロフィール情報、インタネットサービス等で記入する契約情報、商品を購入したときにもらう電子レシート(電子決済情報）、バーコードのような商品についたタグから得られる物品詳細情報、またショッピングモールや駅ビル等でそのエリア情報を提供するエリア情報などがあげられる。
取得できるインタフェースは異なることも考えられる。例えば、電子決済情報は赤外線インタフェースで入力されることもあれば、物品情報などはＲＦＩＤタグを介してインターネット上から取得することも考えられる。ここでプロファイル提供者が複数のＲＤＦプロファイル情報源を所持していてもよい。
【００１９】
入力ＲＤＦプロファイル１は、個人で管理するプロファイルアグリゲータ（プロファイル管理装置）と称される、サーバ内部にあるＲＤＦプロファイルＤＢ３０に最終的に蓄積される。本発明のプロファイル管理装置は、ＵＲＩ統合装置１０と、ＲＤＦプロファイルＤＢ３０とを備える。
取得されたＲＤＦプロファイル情報はユーザにとって生活の中で得た一種のログ情報であり、ユーザはＵＲＩ統合装置１０で情報を加工した上でＲＤＦプロファイルＤＢ３０に蓄積する。
【００２０】
ＵＲＩ統合装置１０には、ＲＤＦに含まれるリソースの比較を行うリソース比較部及びスキーマを管理するＲＤＦスキーマ管理部１３及び、ＲＤＦプロファイルの記述を修正するＲＤＦプロファイル更新部１２を備える。
本発明実施形態において、入力ＲＤＦプロファイルはＸＭＬ（eXtended Markup Language）で記述されているものを想定するが、ＲＤＦを表現することが可能であれば、他の記述言語であっても構わない。各クラスやプロパティの情報はＲＤＦスキーマ管理部１３によって管理されている。
【００２１】
ここで扱う入力ＲＤＦプロファイル１をＲＤＦモデルで表現した例を、図３（物品情報のＲＤＦプロファイル）、及び図４(電子決済情報のＲＤＦプロファイル)に示す。図３に示す例では、その商品の名前(kprof:name)や管理コード(kprof:epc)、製造国(kprof:madein)、製造日(kprof:dateofmanufacture)といった情報がプロパティとして記述されており、商品そのものをリソースとして扱っている。図３でrdf:typeはそのリソースのクラス（タイプ）が何であるかを意味するプロパティである。この場合、リソースは商品(kprof:goods)であることを記述している。図４も同様である。ただ電子レシートの場合ではレシートそのもの、購入した商品、購入した場所の三つのリソースとそれぞれのプロパティ情報が記述されている。図３及び図４に対応したインスタンスをＸＭＬ形式で記述したものをそれぞれ図６、図７に示す。
これら独立の情報源から得られたＲＤＦプロファイルに対して比較すると、斜線で示した部分でプロパティとそのリテラル値は同一の内容となっている。それゆえ、これらは互いに同じリソースの情報を示していると考えることができる。これらに同じＵＲＩをＲＤＦプロファイルのリソースの部分に記述することで情報の統合を図ることができる。両ＲＤＦプロファイルを合わせてＲＤＦのパーサで処理すれば、情報を統合したＲＤＦプロファイル情報を生成することができる。
【００２２】
図５は、図３と図４を統合した例である。商品のリソースにはkprof:goods_1というＵＲＩを割り当てている。この統合処理によって例えば、電子レシートの購入価格情報から物品情報の製造国や製造日を索引することができる。
我々が対象にしているプロファイル情報に対し、含まれるリソースの一覧を図８に表として示す。ここでは、“人”、“サービス”、“エリア”、“商品”などがURI統合対象として考えられる。
実際のインスタンスは、例えば、図７であるが、入力ＲＤＦプロファイル１におけるリソースの記述は以下の書き出しで始まっている（図７アンダーライン箇所）。
<rdf:description>
URIをリソースに指定する場合には次のような書き出しで記述される（図６アンダーライン箇所）。
<rdf:description about="kprof:goods_1">
【００２３】
つまり、入力ＲＤＦプロファイル１のこの部分にＵＲＩ情報を追加することで、リソースにＵＲＩの付与は完了する。本発明では、具体的にはこの部分に、複数のプロファイル間で共通のＵＲＩを書き加えることになる。
上記した手法によれば、リソースのプロパティの比較を行って両者が同一リソースと判断されると統一のＵＲＩを書き加える。異なると判断された場合には、異なるＵＲＩを付与する。ここでは、ＲＤＦの形式を変えてしまうことはせず、description のタグ部分のみを書き換える。このＵＲＩ統合の更新手順については後述する。
【００２４】
なお、図６、図７のリストで現れている各種プロパティやクラス(語彙)については、我々が定義したものである。kprofというのは我々が定義した語彙であることを表す接頭辞である。
商品に関わるスキーマの例を図９に示す。この例では８種のプロパティが定義されており、rdfs:domainは基本プロパティの一つで、あるプロパティがどんなクラスのリソースに適応できるかを表している。また rdfs:rangeはそのプロパティがどんなクラスの値をとるかを示しており、この場合全てのプロパティがリテラル値をもつことを示している。ただ、本発明では、独自の語彙で無ければならない必要は全くない。独自の語彙であると逆に汎用性がなくなるので、プロパティの整合性は低い。ＵＲＩの統合では、むしろ標準的に利用されているDublin Core[dc]やvCard[vcard]のような語彙で表現されている方が統合する可能性は高いと見ることができる。
【００２５】
続いてＵＲＩを統合するアルゴリズムを図１２、図１３に示すフローチャートに沿って説明する。
なお、図３と図４に示す例はリソースのＵＲＩが決まっていないものであったが、図１、図２のリソース比較部１１で入力ＲＤＦプロファイルと比較するのは、既にＵＲＩが割り振られているリソースである。それはＲＤＦスキーマ管理部１３のリソース情報に格納されている。格納されている情報をここでは蓄積リソースと呼ぶ。ここでは例として、図１０と図１１に示すそれぞれを、入力プロファイル１、蓄積リソースとして利用するものとする。実際の処理については、ＸＭＬ文書によって記述されているものであれば、具体的にはＲＤＱＬ等のクエリ言語等を用いる。
【００２６】
まずＲＤＦプロファイル更新部１２に入力プロファイル１が伝達されると同時にリソース比較部１１にも同一の情報が伝達される。リソース比較部１１では、入力ＲＤＦプロファイル１に含まれる全てのリソースとそのrdf:type属性であるクラスを抽出する（Ｓ１２１）。rdf:typeとはそのリソースのクラスは何であるかを示すプロパティである。これはリソースがどのタイプかを判断するためである。例えば、図１０に示す例では、２つのリソースが含まれている。それぞれのクラスはClass:IおよびClass:IIである。具体的にはインスタンスから次の４行の記述を抜き出す。
<rdf:Descrioption>
<rdf:type rdf:resource="class:II" />
...
<rdf:Description>
<rdf:type rdf:resource="class:I" />
【００２７】
次に、リソース比較部１１は、これまでに同じリソースが既に存在してないかを調べるために、それぞれのリソース毎にＲＤＦスキーマ管理部１３に問合せる（Ｓ１２２、Ｓ１２３）。ＲＤＦスキーマ管理部１３にはこれまでＲＤＦプロファイルＤＢ３０に蓄積された全てのリソースを管理しており、リソース情報として保持している。
図１４にリソース情報の一例を示す。クラス毎に管理することで、検索効率を上げている。例えば、Class:Iの検索だと４つのリソースが返り値として得られる。ここで図１４ではＲＤＦモデルで表現しているが、実体はＸＭＬベースで記述される。しかし、この表現形式は特に問わない。
【００２８】
次に、検索で得た各蓄積リソースとの比較を行う（Ｓ１２４）。互いにリソースの持つプロパティを比較し（Ｓ１２５）、その中で一つでも同じリテラルがあった場合（Ｓ１２６）、同一のリソースであると判断する（Ｓ１２７）。この場合には蓄積リソースのＵＲＩをリソースに割り当てる（Ｓ１２８）。なお、リソース比較部１１におけるリソースの類似性判断は、それぞれのリソースの持つプロパティ情報を比較し、その適合度によって判定することとする。
図１０と図１１に示す例では、Class:Iのリソースに対してＡ，Ｂのプロパティが同一のリテラル（それぞれ“あ”と“い”）であるため、同一のリソースと判断される。この場合、resource:2が入力ＲＤＦプロファイルの所望のリソースのＵＲＩとして割り当てられる。
【００２９】
リテラルの比較で全て異なっていた場合は異なるリソースと判断される（Ｓ１２９）。また共通のプロパティがそもそも無かった場合も異なるリソースと判断される。異なるリソースと判断された場合、他に蓄積リソースがあれば同じ処理を繰り返す（Ｓ１３０）。そしてどの蓄積リソースとも当てはまらなかった場合には、新規のリソースとして判断し、新規のＵＲＩを付与する（Ｓ１３１）。その場合は、その新規のリソース情報をＲＤＦスキーマ管理部１３のリソース情報にその情報を追加する（Ｓ１３２）。
ＵＲＩが確定したリソースには、ＲＤＦプロファイル更新部１２にてＵＲＩ情報を書き加える（Ｓ１３３）。そして、未だＵＲＩを割り当てていないリソースがある場合は、以上の処理を繰り返す（Ｓ１３４）。最終的に入力プロファイルの全てのリソースにＵＲＩを割り当てるとＲＤＦプロファイルＤＢ３０に蓄積する（Ｓ１３５）。
【００３０】
以上説明のように本発明は、取得したプロファイル情報に含まれる対象と分類を抽出して既存の対象との比較を行い、既存の対象と同一であると判断されたときその対象（リソース）のＵＲＩを付与し、新規に取得した対象であると判断されたときに新たな認識情報を付与するものである。このことにより、これまで独立に管理されてきたプロファイル提供者からのプロファイル情報を互いに関連付けることが可能となり、情報間に新たな価値を生成することができる。このため、ユーザにとっては個人目的のユーザ管理や蓄積されたＲＤＦプロファイルの検索など、利便性を向上させることができる。
【００３１】
なお、図１、図２に示す、リソース比較部１１、ＲＤＦプロファイル更新部１２、ＲＤＦスキーマ管理部１３のそれぞれで実行される手順をコンピュータ読み取り可能な記録媒体に記録し、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することによって本発明のプロファイル管理装置を実現することができる。ここでいうコンピュータシステムとは、ＯＳや周辺機器等のハードウェアを含む。
【００３２】
また、「コンピュータシステム」は、ＷＷＷシステムを利用している場合であれば、ホームページ提供環境（あるいは表示環境）も含むものとする。
また、上記プログラムは、このプログラムを記憶装置等に格納したコンピュータシステムから、伝送媒体を介して、あるいは、伝送媒体中の伝送波により他のコンピュータシステムに伝送されてもよい。ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワーク（通信網）や電話回線等の通信回線（通信線）のように情報を伝送する機能を有する媒体のことをいう。
また、上記プログラムは、前述した機能の一部を実現するためのものであっても良い。さらに、前述した機能をコンピュータシステムにすでに記録されているプログラムとの組合せで実現できるもの、いわゆる差分ファイル（差分プログラム）であっても良い。
【００３３】
以上、この発明の実施形態につき、図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。
【図面の簡単な説明】
【００３４】
【図１】本発明に係るシステムの全体構成図である。
【図２】本実施形態の構成図である。
【図３】本実施形態に係るＲＤＦプロファイルの構成例を示す図である。
【図４】本実施形態に係るＲＤＦプロファイルの構成例を示す図である。
【図５】図３と図４を統合した例を示す図である。
【図６】本実施形態に係るＲＤＦプロファイルインスタンスの記述例を示した図である。
【図７】本実施形態に係るＲＤＦプロファイルインスタンスの記述例を示した図である。
【図８】本実施形態に係るプロファイル情報と含まれるリソースの例を表形式で示した図である。
【図９】商品に関するスキーマの例を示す図である。
【図１０】本実施形態に係る入力ＲＤＦプロファイルの例を示す図である。
【図１１】本実施形態に係る蓄積リソースの例を示す図である。
【図１２】本実施形態による処理の流れを示す図である。
【図１３】本実施形態による処理の流れを示す図である。
【図１４】ＲＤＦスキーマ管理部のリソース情報の一例である。
【図１５】ＲＤＦ記述のモデル化の例を示す図である。
【符号の説明】
【００３５】
１…入力プロファイル、３…蓄積ＲＤＦプロファイル、１０…ＵＲＩ統合装置、１１…リソース比較部、１２…ＲＤＦプロファイル更新部、１３…ＲＤＦスキーマ管理部、３０…ＲＤＦプロファイルＤＢ
【図１】
2005242934.tif 000003
【図２】
2005242934.tif 000004
【図３】
2005242934.tif 000005
【図４】
2005242934.tif 000006
【図５】
2005242934.tif 000007
【図６】
2005242934.tif 000008
【図７】
2005242934.tif 000009
【図８】
2005242934.tif 000010
【図９】
2005242934.tif 000011
【図１０】
2005242934.tif 000012
【図１１】
2005242934.tif 000013
【図１２】
2005242934.tif 000014
【図１３】
2005242934.tif 000015
【図１４】
2005242934.tif 000016
【図１５】
2005242934.tif 000017