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

Abstract

【課題】 既存ツールにアクセスしてRDFに変換する際の、既存ツールへのアクセスを減らす。
【解決手段】 既存ツールのデータのIDの集合をパラメータとして具体化され、複数のデータを１回（あるいは高々数回）で取得するバルクアクセス・テンプレートを用意し、バルクアクセス・テンプレートを介して既存ツールにアクセスするようにする。バルクアクセス・テンプレートは、取得するデータのタイプ毎に用意される。次に、要求されたURIに基づきテンプレートが具体化され、当該具体化されたテンプレートを実行することで、作業テーブルの対応するエントリを充填する。既にアクセスしたのと同一のテンプレートのURIに関してRDF表現が要求されたときは、既にエントリが作業テーブルにあるので、既存ツールへのアクセスを発生させることなくRDF表現を生成することができる。
【選択図】 図９

Description

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

近年、特開２００５−２４２９３４号公報、あるいは特開２００６−３０２０８５号公報に記載されているように、ウェブ上にあるリソースを記述する仕組みとして、RDF(Resource Description Framework)形式が採用されている。また、Christian Bizer, Tom Heath, Tim Berners-Lee, Lined 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データを格納しておいて提供するツールが格納されている。

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

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

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

このような構成においては、コンピュータ１１６やコンピュータ１１８から、コンピュータ１０８やコンピュータ１１４上のLinked Data変換／提供ツールにアクセスがある度に、応答を返すために、コンピュータ１０６またはコンピュータ１１２上の既存ツールにアクセスが行われる。

特に、コンピュータ１１８上の、予めLinked Data提供ツールをクロールしてインデックスを作成しておくツールがコンピュータ１０８やコンピュータ１１４上のLinked Data変換／提供ツールをクロールするとき、リクエストの返答を生成するために多数回のアクセスが集中する。このため、クローラからの要求に対応するための、既存ツールへのアクセスがボトルネックとなって、システム全体としてのスループットが低くなるという問題があった。

Soeren Auer, Sebastian Dietzold, Jens Lehmann, Sebastian Hellmann, David Aumueller, Universitaet Leipzig, Postfach Leipzig, Triplify - Light-Weight Linked Data Publication from Relational Databases, WWW 2009には、マッピング指定に従って既存データベースのデータを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/ Soeren Auer, Sebastian Dietzold, Jens Lehmann, Sebastian Hellmann, David Aumueller, Universitaet Leipzig, Postfach Leipzig, Triplify - Light-Weight Linked Data Publication from Relational Databases, WWW 2009

この発明の目的は、既存ツールにアクセスしてRDFに変換する際の、既存ツールへのアクセスを減らし、以って処理速度を向上することにある。

この発明は、既存ツールのデータのIDの集合をパラメータとして具体化され、複数のデータを１回（あるいは高々数回）で取得するバルクアクセス・テンプレートを用意し、バルクアクセス・テンプレートを介して既存ツールにアクセスするようにすることによって上記目的を解決するものである。バルクアクセス・テンプレートは、SQLのWHERE句をパラメータ化したものでもよいし、APIの組み合わせで実現してもよい。バルクアクセス・テンプレートは、取得するデータのタイプ毎に用意される。

本発明の別の側面によれば、テンプレートに与えるデータの作成と制御が、コンピュータの主記憶中に確保される作業テーブルを使って行われる。すなわち、本発明によれば、生成したRDF表現に含まれるURIは以降にアクセスされる可能性が高いとみなし、これらの個々のURIを、対応するRDF生成のためのデータを取得するテンプレート名とともに作業テーブルに登録するようにする。

本発明によれば次に、要求されたURIに基づきテンプレートが具体化され、当該具体化されたテンプレートを実行することで、作業テーブルの対応するエントリを充填する。これによって対応するRDF表現が得られる。

その後、既にアクセスしたのと同一のテンプレートのURIに関してRDF表現が要求されたときは、既にエントリが作業テーブルにあるので、既存ツールへのアクセスを発生させることなくRDF表現を生成することができる。

以上のように、この発明によれば、バルクアクセス・テンプレートを介して既存ツールにアクセスするようにすることによって、あるURIのテンプレートをもつデータのエントリを一挙に作業テーブルに登録するので、同一テンプレートに関するURIに関してRDF表現が要求されたときに改めて既存ツールへのアクセスを発生させることなく、アクセス頻度を減らすことができる。

Linked Data変換／提供ツールと、Linked Data使用ツールを含む、ネットワーク接続された複数のコンピュータからなるシステム構成の概要図である。 Linked Data変換／提供ツールを格納したコンピュータのハードウェアのブロック図を示す図である。 本発明に係るLinked Data変換／提供ツールの機能ブロック図を示す図である。 対応表を示す図である。 作業テーブルを示す図である。 RDF表現出力の処理のフローチャートを示す図である。 サブルーチンGetTemplatesの処理のフローチャートを示す図である。 サブルーチンFillEntriesの処理のフローチャートを示す図である。 RDF表現出力の処理に従う、作業テーブルに格納されるデータの例を示す図である。 作業テーブルを構成する記憶域１と記憶域２の処理を示す図である。

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

本発明は、図１に示す構成における、Linked Data変換／提供ツールに対する改良に関するものである。そこで、図２に、図１においてLinked Data変換／提供ツールが格納されるコンピュータ１０８及び１１４の例示的なハードウェアのブロック図を示す。なお、コンピュータ１０８及び１１４だけでなく、コンピュータ１０４、１０６、１１０、１１２、１１６、及び１１８も、図２に示すハードウェア構成であってもよい。

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

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

ハードディスク・ドライブ２０８にはさらに、図３に関して後で説明するLinked Data変換／提供ツール３００の要素である、メイン・プログラム３０２、RDF表現出力ルーチン３０８、GetTemplateルーチン３１０、FillEntriesルーチン３１２などが保存されている。これらのルーチンやプログラムは、Ｃ、Ｃ＋＋、Java(R)などの既存のプログラミング言語処理系により、ＣＰＵ２０４に適合する実行可能形式のコードを生成し得るコンパイラによって作成することができる。

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

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

通信インターフェース２１６は、好適には、イーサネット(R)プロトコルにより、ネットワークと接続されている。通信インターフェース２１６は、Linked Data使用ツールを格納するコンピュータ１１６やLinked Data使用ツール（クローラ付き）を格納するコンピュータ１１８からのリクエストを受け取ったり、既存ツールを格納するコンピュータ１１２にアクセスする等のために使用される。

Linked Data使用ツールは、RDF表現をLinked Data提供ツールから取得し、取得したデータを解析してユーザ（または第三者のツール）に提示し、提示したデータに含まれるURIのうちでユーザ（または第三者のツール）が指定したものについてLinked Data 提供ツールに要求する、という一連の動作を繰り返すことで、ユーザ（または第三者のツール）に情報をアクセスさせるものである。例えば、新聞記事を人名・地名・カテゴリなどで検索する仕組み、ソフトウエア開発における工程・設計・コード・テスト・変更の管理、創薬における医療情報・実験データ・市場情報の管理、などに使われる。

Linked Data使用ツール（クローラ付き）は、検索用のインデックス作成、統計調査、一覧表作成などを目的として、RDF表現に含まれるURIをたどって別のRDFを収集する動作を自動的に繰り返す。この結果、1) 一定の時間に多量のアクセスが発生する、2) 一度アクセスしたデータは次にアクセスしにくい特徴がある、という点が単なるLinked Data使用ツールと異なる。

次に、図３の機能ブロック図を参照して、Linked Data変換／提供ツール３００の各機能要素について説明する。

図３において、メイン・プログラム３０２は、キーボード２１０あるいはマウス２１２などの操作によってLinked Data変換／提供ツール３００を起動したり、終了したりする機能をもつ。

対応表３０４は、図４に示すように、タイプ、パス要素名、属性名集合、及びテンプレートからなる表のデータであり、予めLinked Data変換／提供ツール３００のオペレータによってハードティスク・ドライブ２０８に保存され、好適には、動作時に主記憶２０６にロードされる。

ここでテンプレートとは、あらかじめ作っておいたサブルーチンの名前であり、そのサブルーチンの中では既存ツールに対するSQLやAPIの呼び出しが行われる。

作業テーブル３０６は、図５に示すように、(URI，アクセステンプレート）と取得済みデータのフィールドをもつ。作業テーブル３０６は好適には、主記憶２０６に獲得されたメモリの領域にエントリを配置したものであり、詳しい処理は後述するが、エントリを追加し、あるいはエントリを削除し、獲得しているメモリ領域を開放することにより、サイズを調整される。

RDF表現出力ルーチン３０８は、通信モジュール３１４を介してLinked Data使用ツール、あるいはLinked Data使用ツール（クローラ付き）から受け取ったURIに応答して、通信モジュール３１４を介して既存ツールにアクセスし、RDF表現に変換して、通信モジュール３１４を介してLinked Data使用ツール、あるいはLinked Data使用ツール（クローラ付き）にRDF表現のデータを送信する処理を行う。RDF表現出力ルーチン３０８のより詳しい処理は、図６のフローチャートを参照して後で説明する。

GetTemplatesルーチン３１０は、RDF表現出力ルーチン３０８から呼ばれて、テンプレート集合を用意する処理を行うものである。GetTemplatesルーチン３１０のより詳しい処理は、図７のフローチャートを参照して後で説明する。

FillEntriesルーチン３１２は、RDF表現出力ルーチン３０８から呼ばれて、作業テーブル３０６のフィールドを埋める処理を行うものである。FillEntriesルーチン３１２のより詳しい処理は、図８のフローチャートを参照して後で説明する。

通信モジュール３１４は、RDF表現出力ルーチン３０８が、通信インターフェース２１６を利用して、Linked Data使用ツールを格納するコンピュータ１１６やLinked Data使用ツール（クローラ付き）を格納するコンピュータ１１８などと通信するために使用される。通信モジュール３１４は、オペレーティング・システムに標準装備される通信機能を利用することができる。

次に、図６のフローチャートを参照して、RDF表現出力ルーチン３０８の処理を説明する。RDF表現出力ルーチン３０８は、URI uを入力とする。

図６において、RDF表現出力ルーチン３０８は、ステップ６０２で、uのRDF表現生成に必要なデータがすべて作業テーブル３０６に取得済みかどうか判断し、もしそうなら、ステップ６０４で、作業テーブル３０６の取得済みデータを使って、uのRDF表現rを生成する。図５の例では、行１の取得済みデータにおける、http://example.com/RedRev/4がuのRDF表現である。

RDF表現出力ルーチン３０８は、ステップ６０６で、使ったデータのエントリを記憶域２の先頭に移す。ここで、図１０を参照して、未取得データを管理するための記憶域１と、取得済みデータを管理するための記憶域２について説明する。記憶域１も記憶域２も、例えば、オペレーティング・システムの所定のAPI関数を呼び出して、主記憶２０６にメモリ割り当てした領域である。作業テーブル３０６は、記憶域１と記憶域２を合わせた領域からなる。

作業テーブル３０６を、このような記憶域１と記憶域２を合わせた領域とする理由は、作業テーブル３０６が一定の大きさに収まるようにデータを管理する必要があるからである。取得するデータには次の性質がある。

・先ず、クロールされたデータに対して、データ使用アプリケーションがアクセスを行う。
・クローラは、一度取得したデータを再取得する可能性は低い。作業テーブル３０６に追加された未取得データのエントリは、時間とともに取得の可能性が低下すると考えられる。
・クロール済みでインデックスされたデータをアプリケーションが参照するとき、アクセスに局所性がある。

このため、記憶域１と記憶域２という２つの記憶域をつかってデータを管理するようにした。記憶域１はキューで、未取得のデータエントリを管理する。エントリ追加はキューの先頭に対して行われる。図１０に示されているように、エントリのデータが取得されると記憶域２に移される。登録済みのURIが再出現すると、キューの先頭に戻される。キューがあふれるとき、最後尾のエントリは除去される。記憶域２もキューで、取得済みデータエントリを管理する。データ取得によるエントリ追加はキューの先頭に対して行われる。エントリのデータが要求されると、キューの先頭に戻される。キューには、利用可能な主記憶２０６の容量に依存する、あるサイズの限界が設定され、キューがあふれるとき、最後尾のエントリは除去される。このような処理を、RDF表現出力ルーチン３０８が行う。

図６のフローチャートに戻って、ステップ６０６の次のステップ６０８では、RDF表現出力ルーチン３０８は、U := (rに含まれて、uとドメイン名が同じURIの集合) - {u}とする。

RDF表現出力ルーチン３０８は、ステップ６１０で、u_i ∈ Uに対して、T_i = GetTemplates(u_i)を実行して、u_iに対するテンプレート集合T_iを得る。GetTemplates()の処理については、図７のフローチャートを参照して、後で説明する。

RDF表現出力ルーチン３０８は、ステップ６１２で、u_iとt_j ∈ T_iの組が作業テーブル３６０にあるかどうか判断し、もしそうなら、ステップ６１４で、当該データのエントリを記憶域１の先頭に移動して、ステップ６２０に至る。

ステップ６１２で、u_iとt_j ∈ T_iの組が作業テーブル３６０にないと判断すると、RDF表現出力ルーチン３０８は、ステップ６１６でu_iとt_j ∈ T_iの組を作業テーブル３０６に登録し、ステップ６１８で、エントリを記憶域１の先頭に追加する。このとき、記憶域１があふれる場合、最後尾のエントリを除去して、ステップ６２０に至る。

RDF表現出力ルーチン３０８は、ステップ６２０ですべてのt_j ∈ T_iを処理したかどうか判断し、そうでなければ、処理済みのt_jを除外してステップ６１２に戻る。

ステップ６２０ですべてのt_j ∈ T_iを処理したと判断すると、RDF表現出力ルーチン３０８は、ステップ６２２ですべてのu_i ∈ Uを処理したかどうか判断し、もしそうなら処理を終わる。そうでなければ、処理済みのu_iを除外してステップ６１０に戻る。

ステップ６０２に戻って、uのRDF表現生成に必要なデータが作業テーブル３０６に取得済みでないと判断すると、RDF表現出力ルーチン３０８はステップ６２４で、S := {t_i|組(u,t_i)が作業テーブルにあって、データ未取得}という集合Sを作成する。

次にステップ６２６で、RDF表現出力ルーチン３０８は、V_i = {u_j|組(u_j,t_i) where t_i ∈ Sが作業テーブルにあって、データ未取得}という集合V_iを作成する。

次にステップ６２８で、RDF表現出力ルーチン３０８は、アクセステンプレートt_iをV_iで具体化して実行する。ここでアクセステンプレートの具体化とは、例えば、次のようなアクセステンプレートがあったとする。
SELECT id,title,assembly
FROM part
WHERE [PARAMETERS]
とあるのを、
例えば、[PARAMETERS]を、id in V_iで置き換えることである。あるいは、V_i = {n₁,n₂}なら、、[PARAMETERS]を、id = n₁ or id = n₂としてもよい。そして、このような問い合わせの結果返ってきた結果集合Oに対して、FillEntries(O)を実行する。FillEntries()の処理については、図７のフローチャートを参照して、後で説明する。

RDF表現出力ルーチン３０８は次に、ステップ６３０で、取得したデータのエントリを記憶域１から記憶域２の先頭に移す。記憶域２があふれる場合、最後のエントリを除去する。

RDF表現出力ルーチン３０８はステップ６３２で、すべてのt_i ∈ Sを処理したかどうかを判断し、もしそうならステップ６０４に移動し、そうでないなら、t_iを処理済として、ステップ６２６に戻る。

次に図７のフローチャートを参照して、サブルーチンGetTemplates(u)の処理について説明する。サブルーチンGetTemplatesは、URI uを入力とする。

ステップ７０２で、GetTemplatesは、T = {}により、テンプレート集合Tを初期化する。

ステップ７０４で、GetTemplatesは、対応表３０４から、uを分解した構成要素をパス要素名として含む行の集合Rを検索する。

ステップ７０６で、GetTemplatesは、r_i ∈ Rに対して、T := T ∪ (行r_iのテンプレート集合)を実行する。

ステップ７０８で、GetTemplatesは、すべてのr_i ∈ Rを処理したかどうか判断し、もしそうなら処理を終わり、そうでないなら、r_iを処理済みとして、ステップ７０６に戻る。

次に図８のフローチャートを参照して、サブルーチンFillEntries(O)の処理について説明する。サブルーチンFillEntriesは、オブジェクト集合Oを入力とする。

ステップ８０２で、FillEntriesは、o_i ∈ Oに対して、o_iのタイプ名を、動的検査または静的検査で得る。ここで動的検査とは、オブジェクトoに対してo.getType()などのメソッドを呼び出すことによって、実行時にタイプ名を得ることである。また、静的検査では、アクセステンプレートが返すオブジェクト集合のタイプ名を予めAPIを解析するなどによって求めておいて、FillEntries(O)を呼び出すときにはすでにOのタイプ名が分かっているので、それを使うようにする。FillEntriesO)の中でタイプ名にアクセスする方法は、アクセステンプレートを使ったときにタイプ名を大域変数に代入しておいてそれを参照する、タイプ名をFillEnties(O)に引数をひとつとして追加して渡す、などがある。

ステップ８０４で、FillEntriesは、P_i := (o_iの属性集合)を求める。

ステップ８０６で、FillEntriesは、p_j ∈ P_iに対して、t_i,p_jを属性名として含む行rを対応表３０４から検索する。

ステップ８０８で、FillEntriesは、rが見つかったかどうか判断する。そして、もし見つかったなら、ステップ８１０で、対応表３０４の行rのパス要素名と、p_jの属性値を組み合わせて、URI u_jを作り、ステップ８１２でp_jとu_jの組を、作業テーブル３０６のエントリに追加し、ステップ８１６に至る。

ステップ８０８で、rが見つからなかったと判断されると、FillEntriesは、ステップ８１４で、p_jと、p_jの属性値の組を作業テーブル３０６のエントリに追加し、ステップ８１６に至る。

ステップ８１６で、FillEntriesは、すべてのp_j ∈ P_iを処理したかどうか判断し、もしそうなら、ステップ８１８に進み、そうでないならp_jを処理済みとして、ステップ８０６に戻る。

ステップ８１８で、FillEntriesは、すべてのo_i ∈ Oを処理したかどうか判断し、もしそうなら処理を終わり、そうでないならo_iを処理済みとして、ステップ８０２に戻る。

次に図９を参照して、RDF表現出力ルーチン３０８の動作の例を説明する。RDF表現出力ルーチン３０８は、テンプレートに与えるデータの作成と実行の制御を、作業テーブル３０６を使って行う。これは、生成したRDF表現に含まれるURIは、以降にアクセスされる可能性が高いという着想に基づく。そこで、RDF表現出力ルーチン３０８は、これらの個々のURIを、対応するRDF生成のためのデータを取得するためのテンプレート名とともに作業テーブル３０６に登録する。URIに対応するテンプレートは、上述のGetTemplatesで求める。

図９(a)に示すように、生成されたRDF表現に対応して、作業テーブル３０６の(URI,テンプレート)フィールドにエントリが格納される。

ここで、http://example.com/Req/3が要求されたと仮定する。このURIのRDF表現のためにはデータが未取得である。このとき作業テーブル３０６において、http://example.com/Req/3を含む行１と同じテンプレートを含む行として行３がある。そこで、行１と行３のURIから得られる値{3,6}をパラメータとしてテンプレートを具体化して実行すると、以下のとおりとなる。
SELECT id,title,assembly
FROM part
WHERE [PARAMETERS]
とあるのを、
[PARAMETERS] → id = {3,6}と具体化し、
SELECT id,title,assembly
FROM part
WHERE id = 3 or id = 6
とする。
このようにして、一回の実行で行１と行３(id=3とid=6)のデータが同時に得られる。得られたデータに対してFillEntriesを実行することで、図９(b)に示すように、結果を行１と行３に記録する。

行１のデータが得られたので、RDF表現出力ルーチン３０８は、これを使ってhttp://example.com/Req/3のRDF表現を生成する。そして、生成されたRDF表現に含まれるURIを作業テーブルに登録する。このあとhttp://example.com/Req/6が要求されたときは、必要なデータが作業テーブル３０６に取得されているので、既存ツールへのアクセスを発生させずにRDF表現を生成することができる。

このときの、GetTemplatesとFillEntriesの処理内容は次のとおりである。

サブルーチンGetTemplates：URIuからテンプレート集合Tを求める、すなわち
1. uを受け取る （例：http://example.com/Req/3）
2. uを分解して、構成要素としてパス要素名を得る(例：Req)
3. 対応表から、パス要素名を含む行を検索する(例：{行2}）
4. 各行のテンプレート名集合の和を求めて、返す (例：{getReqs}）

サブルーチンFillEntries：オブジェクト集合Oを作業テーブルに記録する、すなわち
1. オブジェクト集合Oのうちの１要素をoとする。
2. oのタイプ名を求める (例：Requirement)
3. oの属性集合を求める （例：｛id=3,title=shaft,rev=4})
4. 対応表から、oのタイプ名と各属性を組み合わせた属性名を含む行を検索する (例：Requirement.revを含む行3）
5. 行が見つかった場合、行のパス要素名と属性値からURIを生成して、作業テーブルに属性名と生成したURIの組を登録する(例：行３のパス要素名ReqRevと属性値4から、URIhttp://example.com/ReqRev/4を生成して、rev=http://example.com/ReqRev/4を登録)。
6. 行が見つからなかった場合、作業テーブルに属性名と属性値の組を登録する（例：title=shaftを登録）
7. 4から6を、oの全ての属性に対して繰り返す。
8. 1から7を、Oの全ての要素oに対して繰り返す。

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

また、Linked Data変換／提供ツールがアクセスする既存ツールは、リレーショナル・データベースのレコードに限らず、RDFへの変換に対応する任意のデータであってよい。リレーショナル・データベースのレコードでない場合は、SQLでなく、所定のAPIによりデータにアクセスすることになる。

１０６、１１２・・・既存ツール
１１４ ・・・Linked Data変換／提供ツールを格納するコンピュータ
１１６ ・・・Linked Data使用ツールを格納するコンピュータ
１１８ ・・・Linked Data使用ツール（クローラ付き）を格納するコンピュータ
２０４ ・・・ＣＰＵ
２０６ ・・・主記憶
２０８ ・・・ハードディスク・ドライブ
３０４ ・・・対応表
３０６ ・・・作業テーブル
３０８ ・・・RDF表現出力ルーチン
３１０ ・・・GetTemplatesルーチン
３１２ ・・・FillEntriesルーチン

Claims (14)

1. コンピュータの処理により、問い合わせのレコードに対するRDF表現を作成する方法であって、
   RDF表現のURIを生成するためのテンプレートの、少なくともパス要素名と、それに対応するテンプレート名を含む対応表を参照するステップと、
   対応するRDF表現を作成するためのURIを受け取るステップと、
   受け取った前記URIを解析して、パス要素名を得るステップと、
   前記受け取った前記URIと、パス要素名と、前記対応表を参照して得られた該パス要素名に対応するテンプレート名の組み合わせを作業テーブルに保存するステップと、
   前記作業テーブルに複数のエントリが蓄積された段階で、さらに対応するRDF表現を作成するためのURIを受け取ったことに応答して、該受け取ったURIを解析しパス要素名を得て、前記作業テーブルから、同じテンプレート名を持つエントリをまとめて具体化したテンプレートを実行し、実行結果から当該パス要素名をもつ複数のエントリを順次取得して、各エントリにおけるURIとテンプレート名の組に基づき、URIを生成するステップを有する、
   方法。
2. 前記テンプレートの実行が、非RDFの既存データにアクセスすることを含む、請求項１に記載の方法。
3. 前記非RDFの既存データがリレーショナル・データベースを含み、前記テンプレートの実行が、SQL式による照会を含む、請求項２に記載の方法。
4. 前記作業テーブルが、主記憶に確保された領域である、請求項１に記載の方法。
5. 前記作業テーブルが、未取得データを管理するためのキューを構成する第１の記憶域と、取得済みデータを管理するためのキューを構成する第２の記憶域からなり、取得された前記作業テーブルのエントリを、前記第１の記憶域から前記第２の記憶域の先頭に移動するステップと、前記第１の記憶域と前記第２の記憶域において、エントリの数が所定の限界を超えたことに応答して、キューの末尾のエントリを削除するステップをさらに含む、請求項４に記載の方法。
6. コンピュータの処理により、問い合わせのレコードに対するRDF表現を作成するプログラムであって、前記コンピュータに、
   RDF表現のURIを生成するためのテンプレートの、少なくともパス要素名と、それに対応するテンプレート名を含む対応表を参照するステップと、
   対応するRDF表現を作成するためのURIを受け取るステップと、
   受け取った前記URIを解析して、パス要素名を得るステップと、
   前記受け取った前記URIと、パス要素名と、前記対応表を参照して得られた該パス要素名に対応するテンプレート名の組み合わせを作業テーブルに保存するステップと、
   前記作業テーブルに複数のエントリが蓄積された段階で、さらに対応するRDF表現を作成するためのURIを受け取ったことに応答して、該受け取ったURIを解析しパス要素名を得て、前記作業テーブルから、同じテンプレート名を持つエントリをまとめて具体化したテンプレートを実行し、実行結果から当該パス要素名をもつ複数のエントリを順次取得して、各エントリにおけるURIとテンプレート名の組に基づき、URIを生成するステップを実行させる、
   プログラム。
7. 前記テンプレートの実行が、非RDFの既存データにアクセスすることを含む、請求項６に記載のプログラム。
8. 前記非RDFの既存データがリレーショナル・データベースを含み、前記テンプレートの実行が、SQL式による照会を含む、請求項７に記載のプログラム。
9. 前記作業テーブルが、主記憶に確保された領域である、請求項６に記載のプログラム。
10. 前記作業テーブルが、未取得データを管理するためのキューを構成する第１の記憶域と、取得済みデータを管理するためのキューを構成する第２の記憶域からなり、取得された前記作業テーブルのエントリを、前記第１の記憶域から前記第２の記憶域の先頭に移動するステップと、前記第１の記憶域と前記第２の記憶域において、エントリの数が所定の限界を超えたことに応答して、キューの末尾のエントリを削除するステップをさらに含む、請求項９に記載のプログラム。
11. コンピュータの処理により、問い合わせのレコードに対するRDF表現を作成するシステムであって、
    主記憶と、
    記憶手段と、
    前記記憶手段に保存された、
    RDF表現のURIを生成するためのテンプレートの、少なくともパス要素名と、それに対応するテンプレート名を含む対応表と、
    対応するRDF表現を作成するためのURIを受け取る手段と、
    受け取った前記URIを解析して、パス要素名を得る手段と、
    前記受け取った前記URIと、パス要素名と、前記対応表を参照して得られた該パス要素名に対応するテンプレート名の組み合わせを、前記主記憶中の作業テーブルに保存する手段と、
    前記作業テーブルに複数のエントリが蓄積された段階で、さらに対応するRDF表現を作成するためのURIを受け取ったことに応答して、該受け取ったURIを解析しパス要素名を得て、前記作業テーブルから、同じテンプレート名を持つエントリをまとめて具体化したテンプレートを実行し、実行結果から当該パス要素名をもつ複数のエントリを順次取得して、各エントリにおけるURIとテンプレート名の組に基づき、URIを生成する手段を有する、
    システム。
12. 前記テンプレートの実行が、非RDFの既存データにアクセスすることを含む、請求項１１に記載のシステム。
13. 前記非RDFの既存データがリレーショナル・データベースを含み、前記テンプレートの実行が、SQL式による照会を含む、請求項１２に記載のシステム。
14. 前記作業テーブルが、未取得データを管理するためのキューを構成する第１の記憶域と、取得済みデータを管理するためのキューを構成する第２の記憶域からなり、取得された前記作業テーブルのエントリを、前記第１の記憶域から前記第２の記憶域の先頭に移動する手段と、前記第１の記憶域と前記第２の記憶域において、エントリの数が所定の限界を超えたことに応答して、キューの末尾のエントリを削除する手段をさらに含む、請求項１１に記載のシステム。

Images