JP2014021869A - Ｒｄｆ表現の生成方法、プログラム、及びシステム - Google Patents

Abstract

【課題】仕様変更に影響されないように、RDF生成のためのコードの開発を進めることを可能とする技法を提供すること。
【解決手段】 この発明のシステムは、Linked Data使用ツールなどからURIを受け取り、URIからシードとなるオブジェクトを特定する。次に、そのオブジェクトの型から適切なマッピング・ファイルを特定し、そこから（部分）型情報を生成する。そして、生成した型情報を参照して、シードから再帰的にたどってオブジェクトを収集する。次にシステムは、収集したオブジェクトのグラフをRDF変換器に渡す。RDF変換器は、マッピング・ファイルを参照して、オブジェクトのグラフをRDFに変換して出力する。
【選択図】 図９

Description

この発明は、コンピュータの処理により、所定のデータからRDF表現を生成するための方法、プログラム、及びシステムに関するものである。

近年、特開２００５−２４２９３４号公報、あるいは特開２００６−３０２０８５号公報に記載されているように、ウェブ上にあるリソースを記述する仕組みとして、RDF(Resource Description Framework)形式が採用されている。また、Christian Bizer, Tom Heath, Tim Berners-Lee, Linked Data-The Story So Far, International Journal on Semantic Web and Information Systems, 5(3), 2009には、RDF形式のデータをウェブの仕組みの上で連携させて使用するLinked Dataが、グローバルな情報公開の仕組みとして記述されている。さらに、Open Services for Lifecycle Collaboration (OSLC), http://open-services.net/には、企業内の情報連携としてLinked Dataを活用することが記述されている。

Linked Dataを提供するツールには、RDFデータを格納しておいて提供するツールと、既存ツールが管理する、RDFになっていないデータをRDFに変換して提供するツールがある。

また、Linked Dataを使用するツールには、ユーザ要求に従ってリンクを辿ってデータを得るツールと、データ・アクセスの効率化のために、予めLinked Data提供ツールをクロールしてインデックスを作成しておくツールとがある。

図１は、このようなツールを利用するための、複数のコンピュータをネットワーク接続した構成の例を示す図である。すなわち、典型的にはＬＡＮまたはＷＡＮであるネットワーク１０２には、コンピュータ１０４、１０６、１０８、１１０、１１２、１１４、１１６、及び１１８が接続されている。コンピュータ１０４とコンピュータ１１０にはRDFデータを格納しておいて提供するツールが格納されている。

コンピュータ１０６とコンピュータ１１２には、既存ツールが格納されている。ここでいう既存ツールが扱うデータとは、リレーショナル・データベースに格納されているレコード、既存ツールのＡＰＩでアクセスされるアプリケーション記述言語のオブジェクト、XML、HTML、CSVなどの構造化されたデータである。

コンピュータ１０８とコンピュータ１１４には、それぞれコンピュータ１０６とコンピュータ１１２上の既存ツールが管理する、RDFになっていないデータをRDFに変換して提供するツール、すなわち、Linked Data変換／提供ツールが格納されている。

コンピュータ１１６には、ユーザ要求に従ってリンクを辿ってデータを得るツールが格納されている。コンピュータ１１８には、データ・アクセスの効率化のために、予めLinked Data提供ツールをクロールしてインデックスを作成しておくツールが格納されている。

さて、図１に示すように、多数のアプリケーションをLinked Dataに対応させるためには、各アプリケーションのオブジェクトを、RDFとして変換する必要がある。

このため知られている従来技術の１つとして、図２に概要を示す構成がある。このような構成では、オブジェクト・レポジトリ２０２の全体が一括して静的にRDF２０４に変換され、Linked Data使用ツール２０６からのURI２０８による問い合わせに応答して、この構成は、対応するRDF２１０を返す。しかし、このような構成では、オブジェクト・レポジトリ２０２の一部でも更新があると、オブジェクト・レポジトリ２０２の全体のRDF２０４への変換をやり直す必要があるので、非効率であった。

そこで、これを改良する従来技術として、図３に示す構成が知られている。このような構成では、Linked Data使用ツール３０２からURI３０４を受け取って、API呼び出し３０６を行い、オブジェクト・レポジトリ３０８にアクセスするコード３１０が存在する。そして、このようなコード３１０の働きにより、オブジェクト・レポジトリ３０８からオブジェクト３１２が抽出され、RDF変換器３１４はマッピング・ファイル３１６を参照して、RDF３１８を生成し、Linked Data使用ツール３０２に渡す。なお、このようなAPI呼び出し３０６は例えば、http://jena.sourceforge.net/tutorial/RDF_API/に記述がある。また、マッピング・ファイルとは、RDF変換の依存関係や階層などのルールを規定するファイルである。しかし、このような構成では、RDFの仕様が変わって、必要なオブジェクトが変更になると、必然的にレポジトリにアクセスするためのコード３１０を変更する必要がある。このとき、オブジェクトのプロパティの数が多いなど、オブジェクトが複雑であると、コード３１０の変更にバグが入り込みやすいなどの問題がある。

特開２００５−２４２９３４号公報 特開２００６−３０２０８５号公報

Christian Bizer, Tom Heath, Tim Berners-Lee, Lined Data-The Story So Far, International Journal on Semantic Web and Information Systems, 5(3), 2009 Open Services for Lifecycle Collaboration (OSLC), http://open-services.net/ http://jena.sourceforge.net/tutorial/RDF_API/

従って、この発明の目的は、仕様変更に影響されないように、RDF生成のためのコードの開発を進めることを可能とする技法を提供することにある。

この発明は、上記従来の問題点を解決するために、従来はRDF変換のためだけに作成されていたマッピング・ファイルから型情報を生成することに着想したものである。そして、生成した型情報を参照し、シードのオブジェクトから再帰的にオブジェクトを収集する処理が行なわれる。

より詳しくは、この発明に従うシステムは、次のような処理を行なう。
(1) システムが、Linked Data使用ツールなどからURIを受け取る。
(2) システムは、URIからシードとなるオブジェクトを特定する。次に、そのオブジェクトの型から適切なマッピング・ファイルを特定し、そこから（部分）型情報を生成する。マッピング・ファイルには、RDF生成に必要なオブジェクトの型の名前とプロパティ名、型同士の関係などが分かる情報が埋め込まれているので、このような処理が可能である。
(3) 次にシステムは、生成した型情報を参照して、シードから再帰的にたどってオブジェクトを収集する。
(4) 次にシステムは、収集したオブジェクトのグラフをRDF変換器に渡す。
(5) RDF変換器は、マッピング・ファイルを参照して、オブジェクトのグラフをRDFに変換して出力する。

この発明によれば、マッピング・ファイルから型情報を生成し、その型情報を使用してオブジェクトを収集し、収集したオブジェクトのグラフをRDF変換するようにすることによって、オブジェクト・リポジトリ等の仕様変更に、最小の手間で対応可能となる。

Linked Data変換／提供ツールと、Linked Data使用ツールを含む、ネットワーク接続された複数のコンピュータからなるシステム構成の概要図である。 URIに対応してRDFを提供するための従来技術を示す図である。 URIに対応してRDFを提供するための別の従来技術を示す図である。 本発明を実施するためのハードウェア構成のブロック図である。 本発明を実施するための機能要素のブロック図である。 本発明を実施するための処理のフローチャートを示す図である。 本発明を実施するための処理のフローチャートを示す図である。 マッピング・ファイルから型情報を生成する例を示す図である。 本発明に係る全体の処理の概要を示す図である。

以下、図面に従って、本発明の実施例を説明する。これらの実施例は、本発明の好適な態様を説明するためのものであり、発明の範囲をここで示すものに限定する意図はないことを理解されたい。また、以下の図を通して、特に断わらない限り、同一符号は、同一の対象を指すものとする。

本発明に係る機能は、図１における、Linked Data使用ツールからアクセスされて、非RDFのデータをRDFに変換して提供する、Linked Data格納／提供ツールなどに対応する。

図４は、本発明を実施するためのコンピュータのハードウェアの一例を示すブロック図である。

図４において、システム・バス４０２には、ＣＰＵ４０４と、主記憶（ＲＡＭ）４０６と、ハードディスク・ドライブ（ＨＤＤ）４０８と、キーボード４１０と、マウス４１２と、ディスプレイ４１４が接続されている。ＣＰＵ４０４は、好適には、３２ビットまたは６４ビットのアーキテクチャに基づくものであり、例えば、インテル社のPentium(商標)4、インテル社のCore(商標) 2 DUO、AMD社のAthlon(商標)などを使用することができる。主記憶４０６は、好適には、４ＧＢ以上の容量、より好ましくは、８ＧＢ以上の容量をもつものである。

ハードディスク・ドライブ４０８には、オペレーティング・システムが、格納されている。オペレーティング・システムは、Linux（商標）、マイクロソフト社のWindows(商標) 7、Windows XP(商標)、Windows(商標)2003サーバ、アップルコンピュータのMac OS(商標)などの、ＣＰＵ４０４に適合する任意のものでよい。

ハードディスク・ドライブ４０８にはさらに、図５に関して後で説明する、メイン・プログラム５０２、オブジェクト・リポジトリ５０４、マッピング・ファイル５０６、オブジェクト収集モジュール５０８、RDF変換器５１４、通信モジュール５１６などが保存されている。また、RDF変換のためのAPIを提供するプログラム群もハードディスク・ドライブ４０８に保存されている。

メイン・プログラム５０２及びオブジェクト収集モジュール５０８は、Ｃ、Ｃ＋＋、Java(R)などの既存のプログラミング言語処理系により、ＣＰＵ４０４に適合する実行可能形式のコードを生成し得るコンパイラによって作成することができる。RDF変換器５１４は既存のプログラムでよい。

オブジェクト・リポジトリ５０４及びマッピング・ファイル５０６は、ハードディスク・ドライブ４０８にローカルに保存されているのでなく、遠隔のコンピュータ上のネットワークドライブ上に保存されていてもよい。

キーボード４１０及びマウス４１２は、オペレーティング・システムが提供するグラフィック・ユーザ・インターフェースに従い、ディスプレイ４１４に表示されたアイコン、タスクバー、テキストボックスなどのグラフィック・オブジェクトを操作するために使用される。

ディスプレイ４１４は、これには限定されないが、好適には、１０２４×７６８以上の解像度をもち、３２ビットtrue colorのＬＣＤモニタである。ディスプレイ４１４は例えば、RDF変換処理を操作する画面等を表示するために使用される。

通信インターフェース４１６は、好適には、イーサネット(R)プロトコルにより、ネットワークと接続されている。通信インターフェース４１６は、Linked Data使用ツールを格納するコンピュータ１１６からのリクエストを受け取ったり、Linked Data使用ツールを格納するコンピュータ１１６にRDF変換されたデータを送ったりする等のために使用される。

次に、図５を参照して、本発明の処理を実行するための機能要素につて説明する。図５において、メイン・プログラム５０２は、通信モジュール５１６を介してLinked Data使用ツールを格納するコンピュータ１１６からURIを受け取って処理を開始したり、処理結果を通信モジュール５１６を介してLinked Data使用ツールを格納するコンピュータ１１６に送り返したり、その他全体の処理を統合する機能を有する。

オブジェクト・リポジトリ５０４は、ローカルまたはリモートのディスクに保存され、RDF変換すべきデータを、所定の構造でもっている。

マッピング・ファイル５０６は、基本的にはオブジェクト・リポジトリ５０４におけるオブジェクトとRDFとの対応を示す情報を含む。例えば、オブジェクトがXMLで表現されていて、それを、RDFのXML表現であるRDF/XMLに変換するなら、XSLTによる変換が想定され、するとXSLTファイルがマッピング・ファイルとなる。あるいは、本出願人に係る特願２０１１−１１３４５６号明細書に記載されている技術の場合なら、オブジェクトのメタ情報であるクラス図と、RDFの形状との対応関係を示した情報を含むのがマッピング・ファイルとなる。

オブジェクト収集モジュール５０８は、メイン・プログラム５０２がLinked Data使用ツールからURIを受け取ることに応答して処理を開始する。そのURIを以って、オブジェクト収集モジュール５０８は、直接オブジェクト・リポジトリ５０４にアクセスするのでなく、一旦マッピング・ファイル５０６にアクセスして、（部分）型情報５１０を取り出して、主記憶４０６またはハードディスク・ドライブ４０８に保存する。次にオブジェクト収集モジュール５０８は、型情報５１０を以ってオブジェクト・リポジトリ５０４にアクセスし、型情報５１０に対応するオブジェクトを抽出し、オブジェクトのグラフ５１２として、主記憶４０６またはハードディスク・ドライブ４０８に保存する。オブジェクト収集モジュール５０８の機能は、図６と図７のフローチャートを参照して、後でより詳細に説明する。

RDF変換器５１４は、特にこの発明にとって特徴的なものである必要はなく、既存のRDF変換器でよい。RDF変換器５１４は、マッピング・ファイル５０６とオブジェクトのグラフ５１２の情報を使用してRDFファイルを生成し、メイン・プログラム５０２はそのRDFファイルを、URIを送ってきたLinked Data使用ツールに送り返す。

次に、図６と図７のフローチャートを参照して、オブジェクト収集モジュール５０８の処理について説明する。オブジェクト収集モジュール５０８は、src(シードとなるオブジェクト)と、tmap(マッピング・ファイル)を入力とし、tgt(要求されたRDFの生成に必要なオブジェクト群)を出力とする。ここで、シードとなるオブジェクトとは、URIから特定された、シードとなるオブジェクトのIDに対応するオブジェクトの型のことである。例えば、URIがhttp://www.sample1.com/AXZWとすると、このURIから、オブジェクトのIDとしてAXZWが特定され、そのIDをもつオブジェクトがシードのオブジェクトとなる。

図６は、オブジェクト収集モジュール５０８として呼び出されるメイン・ルーチンであるload(src,tmap)を示すフローチャートである。

ステップ６０２で呼び出されると、load(src,tmap)は、ステップ６０４でtgt := 空のオブジェクト集合とセットし、ステップ６０６でloadrec(src,tgt,tmap)を呼び出し、loadrec(src,tgt,tmap)の完了後、ステップ６０８でtgtを返す。

図７は、load(src,tmap)で呼び出されるloadrec(src,tgt,tmap)の処理を示すフローチャートである。

ステップ７０２でloadrec(src,tgt,tmap)が呼び出されると、loadrec(src,tgt,tmap)はステップ７０４で、src - tgtが空かどうか判断し、もしそうなら単にリターンする。ここの判断ステップは特に、後述するステップ７２２で再起呼び出しされるとき、意味をもつ。

src - tgtが空でないならloadrec(src,tgt,tmap)は、ステップ７０６で、src - tgtを型ごとにグループ化したオブジェクト配列の集合を用意し、それをSとする。

ステップ７０８では、loadrec(src,tgt,tmap)は、Sにおけるオブジェクト(型Ta)の１つの配列Aを選ぶ。すなわち、A ∈ Sである。なお、図７のフローチャートにおけるオブジェクトとは、ＲＡＭ４０６上に読み込まれた、オブジェクト・リポジトリ５０４のオブジェクトであることに留意されたい。

ステップ７１０では、loadrec(src,tgt,tmap)は、tmapが参照している型情報から、Taの上位型のリストを取得し、それをLとおく。

ステップ７１２では、loadrec(src,tgt,tmap)は、tmapから、Lにある型のオブジェクトについてたどるべきプロパティ名リストを取得し、それをPとおく。

ステップ７１４では、loadrec(src,tgt,tmap)は、Aの一つの要素aを選び、それをtgtに追加する。

ステップ７１６では、loadrec(src,tgt,tmap)は、aについてプロパティp ∈ Pの値を取得し、それをBとおく。このとき、例えば、loadProperties(Object[], String[])及びgetProperty(String)が呼び出される。loadProperties(Object[], String[]) は、Object[]内のオブジェクトについてString[]にリストされたプロパティをレポジトリからロードするAPI関数であり、getProperty(String) は、オブジェクトのプロパティ名を通してプロパティの値をとるAPI関数である。

ステップ７１８では、loadrec(src,tgt,tmap)は、Bがオブジェクト（配列）かどうか判断し、もしオブジェクトまたはその配列であるなら、ステップ７２０に進む。そして、配列ならそのまま、また配列でないならBを配列として扱う、すなわち長さ１の配列B'とみなし、ステップ７２２でloadrec(B',tgt,tmap)を再起呼び出しする。

Bがオブジェクトでもその配列でもないなら、loadrec(src,tgt,tmap)はステップ７２４で、すべてのp ∈ Pを処理したかどうか判断し、もしそうならステップ７２６に進み、そうでないなら、ステップ７１６に戻る。戻ったステップ７１６では、Pのうち、まだ処理されていないp ∈ Pを選んで、処理を行なう。

ステップ７２６で、loadrec(src,tgt,tmap)は、すべてのa ∈ Aを処理したかどうか判断し、もしそうならステップ７２８に進み、そうでないなら、ステップ７１４に戻る。戻ったステップ７１４では、Aのうち、まだ処理されていないa ∈ Aを選んで、処理を行なう。

ステップ７２８で、loadrec(src,tgt,tmap)は、すべてのA ∈ Sを処理したかどうか判断し、もしそうなら処理を終わり、そうでないなら、ステップ７０８に戻る。戻ったステップ７０８では、Sのうち、まだ処理されていないA ∈ Sを選んで、処理を行なう。

次に、図８を参照して、図７のフローチャートの処理をより具体的に説明する。
まず記法を改めて定義する。
- E,F,…は型名
- f,g,…はプロパティ名
- オブジェクトEn、Fn,…の型はE,F,..
- SFはFのスーパークラス
- {A,B..}は集合を、[A,B..]は配列を表す。

このような定義の下で、図８(a)のマッピング・ファイルの構造の例を使って説明する。シードがE1だとすると、オブジェクト収集モジュール５０８は、まずload([E1],tmap)がloadrec([E1],{},tmap)を呼ぶ（tmapは生成した型情報）。
すると、図７におけるステップ７０６とステップ７０８は実質何もせず、S={[E1]}となる。

ステップ７１０でL=[E]となる（上位型は無い）。ステップ７１２が、型Eについてtmapを参照して[f]をPとしてとる。

次に、ステップ７１４がtgtにE1を入れる（tgt={E1})。ステップ７１６がE1についてfをたどって、[F1,F2]をB’としてとり、loadrec([F1,F2], {E1}, tmap)を呼ぶ。

以上のような処理を続けると、F1についてはgをたどってG1,G2,H1がとれる。loadrec([G1,G2,H1],{E1,F1},tmap)がよばれ、ここでは違う型（GとH）があるので、ステップ1.で{[G1,G2],[H1]}がSとしてとられる。

さらにG2からM1をたどってそこからG2をたどるが、これはすでにtgtにあるので、loadrecを呼ぶとステップ1．でsrc-tgt={}となってすぐリターンする。

F2についてはJ1,K1がとれる。というのは、Fについてたどるべきなのはg,jに加えてSFにあるkもあるからである。

ここで、ステップ７２０の「配列でないときに配列にする」はM1,J1,K1など帰ってきた値がひとつのオブジェクトのとき、つぎのloadrecの引数にするため[M1], [J1], [K1]という配列にするということを意味する。

最終的にtgt(=たどったオブジェクト)には{E1,F1,F2,G1,G2,H1,M1,J1,K1}が入り、それをloadが返す。なお、tgtは、単にオブジェクトの集合であるだけでなく、あるオブジェクトがあるオブジェクトを参照している、という関係をそのまま維持している。ゆえに、オブジェクトのグラフでもある、といえる。

こうして生成した型情報を図示すると、図８(b)のとおりである。

次に図９を参照して、処理の流れの例を説明する。まず図９のステップ９０２で、メイン・プログラム５０２が、通信モジュール５１６を介して、Linked Data使用ツールからURI = http://www.sample1.com/AXZWを受け取る。

メイン・プログラム５０２は、このURIを以って、オブジェクト収集モジュール５０８を呼び出す。すると、ステップ９０４で、オブジェクト収集モジュール５０８が、URIからシードとなるオブジェクトのIDであるAXZWを特定する。

ステップ９０６で、オブジェクト収集モジュール５０８が、シードのオブジェクトの型をみて、適切なマッピング・ファイル５０６を選択し、必要なオブジェクトの型情報を生成する。コメント枠９０８で示すように、オブジェクトAXZWに対して型を問い合わせて、それがRequirementなら、Requirementに対するマッピング・ファイルを対象とする。

こうして、図６及び図７のフローチャートで説明した処理によりマッピング・ファイル５０６から抽出した型情報を図式的に示すと参照番号９１２で示すとおりである。型情報９１２は、実際の型９１４の部分型になっている。ここでは簡略的に表示しているが、実際にはRequirementがもつプロパティは、一般的には数百ある。

ステップ９１６では、オブジェクト収集モジュール５０８が、APIを呼び出し、オブジェクト・リポジトリ５０４から、参照番号９１８で示すようなオブジェクト群を取得する。APIを呼び出す際に、マッピング・ファイルから抽出した型情報９１２を参照して、該当するものだけアクセスする。すなわち、部分型情報である型情報９１２を利用することで、参照番号９２０で示す、関係のないオブジェクトの部分にアクセスしないで済む。

次にステップ９２２では、RDF変換器５１６がオブジェクト群９１８をRDFに変換する。より具体的には、コメント枠９２４に示すように、RDF変換器５１６は、マッピング・ファイルをもとに、RDFに変換する。

そのようにして変換されたRDFの一部を示すと、下記のとおりである。
<AXXW> :name "Requirements3";
:owner "Mike";
<AXZW> :name "Requirements3";
:owner "Mike";
:dependsOn <AXXW3>
... ...

ここにある記法以外にも、RDFは、RDF/XMLなどその他の記法で表現してもよい。何れにしても、RDF変換器は、読み込んだオブジェクト群９１８を、そのグラフ表現に従ってマッピング・ファイルに適用し、結果のRDFを生成する処理を行なう。

以上のように、特定の実施例に従い、本発明を説明してきたが、本発明は、特定のオペレーティング・システムやプラットフォームに限定されず、任意のコンピュータ・システム上で実現可能であることを、この分野の当業者なら理解するであろう。

また、RDF変換に使用するマッピング・ファイルは、XSLTのみならず、オブジェクトとRDFの間のマッピングをする任意のものを使用可能である。

４０４・・・ＣＰＵ
４０６・・・主記憶
４０８・・・ハードディスク・ドライブ
４１６・・・通信インターフェース
５０４・・・オブジェクト・リポジトリ
５０６・・・マッピング・ファイル
５０８・・・オブジェクト収集モジュール
５１４・・・ＲＤＦ変換器

Claims (11)

1. コンピュータの処理によりURIをRDFに変換する方法であって、
   URIを受け取るステップと、
   前記URIから、シードとなるオブジェクトを特定するステップと、
   前記オブジェクトの型から、マッピング・ファイルから型情報を生成するステップと、
   前記生成した型情報を参照することにより、オブジェクト・リポジトリから必要なオブジェクトを収集するステップと、
   前記収集したオブジェクトを、RDF変換器に渡すステップと、
   前記RDF変換器において、前記マッピング・ファイルの情報を参照して、前記収集したオブジェクトを、RDFに変換する処理を行なうステップとを有する、
   方法。
2. 前記マッピング・ファイルは、生成すべきRDFのパターンと、RDF生成に必要なオブジェクトの型と名前とプロパティ名を含む、請求項１に記載の方法。
3. 前記型情報を生成するステップが、
   前記マッピング・ファイルが参照している型情報から、注目する型の上位型のリストを取得するステップと、
   前記注目する型の上位型のリストにある、前記マッピング・ファイルのオブジェクトについてたどるべきプロパティ名リストを取得するステップとを有する、
   請求項１に記載の方法。
4. 前記オブジェクト・リポジトリがXMLのファイルであり、前記マッピング・ファイルがXSLTである、請求項１に記載の方法。
5. コンピュータの処理によりURIをRDFに変換するプログラムであって、
   前記コンピュータに、
   URIを受け取るステップと、
   前記URIから、シードとなるオブジェクトを特定するステップと、
   前記オブジェクトの型から、マッピング・ファイルから型情報を生成するステップと、
   前記生成した型情報を参照することにより、オブジェクト・リポジトリから必要なオブジェクトを収集するステップと、
   前記収集したオブジェクトを、RDF変換器に渡すステップと、
   前記RDF変換器において、前記マッピング・ファイルの情報を参照して、前記収集したオブジェクトを、RDFに変換する処理を行なうステップを実行させる、
   プログラム。
6. 前記マッピング・ファイルは、生成すべきRDFのパターンと、RDF生成に必要なオブジェクトの型と名前とプロパティ名を含む、請求項５に記載のプログラム。
7. 前記型情報を生成するステップが、
   前記マッピング・ファイルが参照している型情報から、注目する型の上位型のリストを取得するステップと、
   前記注目する型の上位型のリストにある、前記マッピング・ファイルのオブジェクトについてたどるべきプロパティ名リストを取得するステップとを有する、
   請求項５に記載のプログラム。
8. 前記オブジェクト・リポジトリがXMLのファイルであり、前記マッピング・ファイルがXSLTである、請求項５に記載のプログラム。
9. コンピュータの処理によりURIをRDFに変換するシステムであって、
   記憶手段と、
   前記記憶手段に保存されたオブジェクト・リポジトリと、
   前記記憶手段に保存された、生成すべきRDFのパターンと、RDF生成に必要なオブジェクトの型と名前とプロパティ名を含む、マッピング・ファイルと、
   前記記憶手段に保存されたRDF変換器と、
   URIを受け取り、前記URIから、シードとなるオブジェクトを特定する手段と、
   前記オブジェクトの型から、マッピング・ファイルから型情報を生成する手段と、
   前記生成した型情報を参照することにより、オブジェクト・リポジトリから必要なオブジェクトを収集する手段と、
   前記RDF変換器において、前記マッピング・ファイルの情報を参照して、前記収集したオブジェクトを、RDFに変換する処理を行なう手段を有する、
   システム。
10. 前記型情報を生成する手段が、
    前記マッピング・ファイルが参照している型情報から、注目する型の上位型のリストを取得する手段と、
    前記注目する型の上位型のリストにある、前記マッピング・ファイルのオブジェクトについてたどるべきプロパティ名リストを取得する手段を含む、
    請求項９に記載のシステム。
11. 前記オブジェクト・リポジトリがXMLのファイルであり、前記マッピング・ファイルがXSLTである、請求項９に記載のシステム。

Images