DEIM Forum 2023 2a-6

SPARQL を対象としたクエリ書き換えによる異種データ統合
佐藤 祥吾†

天笠 俊之††† 筑波大学 情報理工学位プログラム 〒 305–8573 茨城県つくば市天王台 1–1–1†† 筑波大学 計算科学研究センター〒 305–8573 茨城県つくば市天王台 1–1–1
E-mail: †s.sato@kde.cs.tsukuba.ac.jp, ††amagasa@cs.tsukuba.ac.jp
あらまし

全ての人が望むように利用・再掲載できるような形で入手できるデータをはじめとして, 複数のデータを組み合わせ, 活用することで, データに新たな価値を見出すことができる. しかし, 活用するにはデータの統合が必要であり, その統合には導入のコスト以外にも, 必要なデータの組合せの変化, 情報源の更新といった, 柔軟性も求められる. また, 統合したデータに対して統一的なデータ表現と検索方法が必要である. そこで本研究では, 情報源ごとにURI を生成する方法をデータ管理者が指定することができ, 異種の情報源に対して SPARQL クエリで問合せることができるデータ統合システムを提案する. 本研究のデータ統合システムでは, 同じエンティティを含む複数の情報源を柔軟に扱うことができ, より実用的なデータ統合をおこなうことができる.
キーワード データ統合, SPARQL, RDF, クエリ書き換えへ分解する. 分解されたトリプルパターンと実際の情報源の1 はじめに
オープンデータとは, 全ての人が望むように利用・再掲載できるような形で入手できるデータのことである. 例として, 日本政府が公開しているオープンデータである DATA.GO.JP [1]は, 気象や人口など, 日本政府が関わる分野の多くの部分をデータとして公開している.
オープンデータをはじめとする複数のデータを組み合わせ,活用することで, データに新たな価値を見出すことができる.
オープンデータの活用事例が, オープンデータ 100 [2] にて公開されている.
ここで，複数のデータを活用するためには, データ統合 [3] が必要である. データ統合とは, 複数の情報源から得られるデータを統合することで統一的に扱えるようにする処理を指す．データ統合をおこなうことで, 複数の情報源に対し, 一括してデータの検索をおこなうことができる.
データ統合を実現する際に, RDF [4] 及び SPARQL [5] が注目されている. RDF とは, 主語-述語-目的語からなるトリプルとして構成され， RDF のデータはトリプルの集合として表現される. RDF は, 自身が持つデータ構造の柔軟性と, その他のデータ構造との互換性の高さから, データ統合を実現する際に有効なモデルとして注目される. また, SPARQL とは, RDFデータに対し基本グラフパターン (BGP) から問合せ条件を指定し, 照合するグラフパターンから RDF データを検索することができるクエリ言語である. SPARQL は, SQL クエリに比べ,ユーザが直感的によりクエリを直感的に書くことができ, RDFのクエリ言語でもあることから, データ統合を実現する際に有効なクエリ言語として注目される.
実際に, SPARQL を問合せ言語としたデータ統合システム

対応関係を用いることで, 入力された SPARQL クエリは, 実際の情報源の問合せクエリに書き換えられる. 書き換えられた問合せクエリから, 情報源の検索結果を得る. そして, あらかじめ定義されているマッピング言語をもとに, 情報源が持つ非 RDF データを, RDF データが持つ URI(Uniform Resource

Identiﬁer) に変換し, ユーザが求める検索結果を出力する.
非 RDF データから RDF データへ変換する際には, エンティティに対応する URI を適切に生成する必要がある．既存研究では, ID などをはじめとする, 非 RDF である情報源に含まれる識別子情報に, 適当な URI のプレフィックスを付加することで, URI が生成できることを前提としている. しかし, 適切なURI の生成方法は情報源ごとに異なる可能性があり, 同じエンティティを含む複数の情報源を扱う際には, 情報源ごとに URIを生成する方法をデータ管理者が指定することができなければ,多くの場合で実用的なデータ統合は困難である.
そこで本研究では, 情報源ごとに URI を生成する方法をデータ管理者が指定することができ, 異種の情報源に対してSPARQL クエリで問合せることができるデータ統合システムを提案する. 本研究のデータ統合システムでは, 同じエンティティを含む複数の情報源を柔軟に扱うことができ, より実用的なデータ統合をおこなうことができる.
本稿の構成は以下の通りである．まず， 2 節で本研究における前提知識について説明する．3 節では関連研究について説明する．4 節では提案手法の説明を行い， 最後に 5 節で本研究のまとめと今後の方針について記す．

2 前提知識2. 1 RDF (Resource Description Framework)の手法が提案されている [6] [7] [8]. これらの手法では, 入力を情報源が持つデータを統一的に表現するためのデータ形式としSPARQL クエリとし, 入力された BGP からトリプルパターンて, RDF(Resource Description Framework) [4] がある. RDF

とは, Web 上に存在する情報源を記述するために提案された,統一された枠組みのことである.

RDF データの最小単位は, 主語 (Subject)-述語 (Predicate)目的語 (Object) からなる RDF トリプルで構成され, RDF ト
リプル内の各要素は, 基本的に Web 上のデータの識別子である URI を用いて表現される.

URI 以外で RDF トリプル内の各要素を表現する方法は,RDF トリプル内の要素によって制約が異なる. 主語では URIまたは空白ノードで構成される. 述語は URI のみで構成される. 目的語は, URI, リテラルあるいは, 空白ノードで構成される. リテラルとは, URI のように形式化された識別子ではなく,文字列をそのまま記述したものことをいう.
この RDF トリプルを組み合わせることで RDF グラフが構成される． RDF グラフは， 主語と目的語がノード， 述語がエッジを示すラベル付き有向グラフとして表現される．

3 関連研究3. 1 情報源と RDF トリプルの対応付け
情報源を統一的に表現するデータモデルとして RDF を用いることは, RDF の持つデータ構造の柔軟性から有効である. ところが, RDF を用いて情報源を統合するには, 統合先の RDFデータを適切に表現する必要がある．特に，RDF では，表現対象の実体が URI として適切に表現されている必要がある．その一方で，情報源のレコードから適切な URI を導出することは単純には行えない．
そこで本研究では，情報源のレコードを対応する URI に変換する複数の手法を想定する．一つめは，情報源の特定の属性値を元に，単純な変換で URI を導出可能，あるいは URI が直接格納されているケースである．二つめは, 情報源のデータに含まれるキーワード等から, Wikidata や DBpedia 等の知識ベー

2. 2 オントロジ
統合した RDF データに用いられている URI が, どのような意味を持つか説明するものとして, オントロジがある. オントロジの代表的な例として, OWL(Web Ontology Language) [10]ス中の実体に対応付ける方法である．具体的には，実体リンキング（Entity Linking）等の既存の技術を利用して，対応するURI を特定する．
3. 1. 1 RDF マッピング言語がある. OWL では, ウェブに存在するものごとの分類体系（クRDF トリプルと RDF 形式でない情報源の対応関係を記述し,ラス）やその関係、さらにはそれを推論していくためのルール

それに基づき情報源のデータから RDF データを生成する手法を定義している.

が開発されている．RDF トリプルと情報源の対応関係を記述目

2. 3 SPARQL (SPARQL Protocol and RDF QueryLanguage)
RDF によって統一的に表現されたデータから, 目的のデータを取得するために問合せを行う言語が, SPARQL(SPARQL

Protocol and RDF Query Language) [5] である．ユーザは,SPARQL クエリで特定の基本グラフパターンを指定することで, 照合するグラフパターンを生成できる情報源のデータを検索することができる.

2. 4 GAV (Global-As-View)
GAV（Global-As-View）[11] は，ビューを用いた情報統合の手法の一つである．統合後のスキーマ（統合スキーマ）を，（統合スキーマとは異なる）情報源に対する問合せ結果で定義され的で開発された言語をマッピング言語と呼ぶ．R2RML（RDBto RDF Mapping Language）[9], RML（RDF Mapping Language）[12] がある. R2RML は, リレーショナルデータ形式となっている情報源を対象に, 対応関係を記述するためのマッピング言語である. また, RML は, R2RML よりも対応できるデー
タ形式を増やし, CSV や JSON, TSV, XML 等の情報源も対象にした, R2RML を拡張したマッピング言語である.
なお，RDF を生成する際に必要となる実体に対応する URIは，情報源の特定の属性値に対して定められた URI 接頭辞（プレフィックス）を付加することで生成することが想定されている．実用性を考えると，これ以外の URI 生成方法についても対応することが必要であると考えられる．

3. 1. 2 実体リンキング（Entity Linking）

るビューとして与える．その特徴として，情報源と統合スキー

R2RML や RML がサポートする，URI 接頭辞を付加する

マとの対応関係を直感的な問合せとして与えられる事に加えて，方法による URI 生成以外にも，テキストやデータベースの統合スキーマに対する問合せを，単純なアルゴリズムによって情報源に対する問合せに変換することができる点があげられる．

レコードに対して，それが対応する実体への参照を推定する手法が研究されている．このような，テキストやレコードが一方，情報源の追加や変更に対して，マッピングルールの更新指す実体を推定する手法を総称して実体リンキング（Entityコストが大きい点が欠点とされている．

Linking）と呼ぶ．具体的には，テキスト（あるいはレコード）

本研究では，統合後のデータは RDF データであるため，RDFデータをリレーションとして扱う．具体的には，RDF トリプルが与えられると，ターゲットとなる知識ベースに含まれる実体集合のうちマッチする実体が結果として返される．その例としをプロパティごとに分割し，同じプロパティを持つトリプルを，て, Wikiﬁcation [13], DBpediaSpotlight [14] があり, これらはプロパティをリレーション名，属性がサブジェクトおよびオブそれぞれ, キーワードから Wikipedia の URI, キーワードからジェクトとするリレーションとして扱う．これによって，任意DBpedia の URI の候補を算出している.の RDF トリプル集合を複数の固定された属性（サブジェクトおよびオブジェクト）からなるリレーションとして表現することができ，GAV での統合が可能となる．

本研究では，統合後の RDF データにおける URI 生成において，URI 接頭辞を付加する方法や実体リンキングを利用する方法を含め，管理者が自由に URI を生成する方法を規定することを許す．これにより，より実用的なデータ統合が可能となる．

3. 2 SPARQL を対象にしたデータ統合システム
リンクトオープンデータ（LOD）を代表として，RDF デー
タ形式でのデータ公開が期待される一方，既存のデータベースのほとんどはリレーショナルデータベースや CSV，XML 等の非 RDF データとして存在している．そこで，RDF 以外の情報源を対象として，仮想的な RDF データとして統合し SPARQLによる問合せを可能にするシステムが提案されている [6]?[8]．

3. 2. 1 Ultrawap
データ統合システムである Ultrawap [7], [8] では, 入力を図1

システムの全体像

SPARQL クエリとし, 入力された BGP からトリプルパターンへ分解する. 分解されたトリプルパターンと実際の情報源の対

4. 2. 1 情 報 源応関係を用いることで, 入力された SPARQL クエリは, 実際

本研究では，リレーショナルデータベースの情報源を想定すの情報源の問合せクエリに書き換えられる. 書き換えられたる．情報源の集合を S = {S1 , S2 , ..., S|S| } と定義する. また,問合せクエリから, 情報源の検索結果を得たのち, あらかじめ各情報源 Si は, リレーション s とその属性集合 u を用いて,定義されているマッピング言語をもとに, RDF データが持つSi = {Si .s1 (u1 ), ..., Si .s|Si | (u|Si | )} と表現する.

URI(Uniform Resource Identier) に変換し, ユーザが求める検4. 2. 2 ターゲットオントロジ

索結果を出力する.

統合したデータを RDF として統一的に表現する際には, ター

3. 2. 2 Ontop

ゲットオントロジを用いる. 本稿では, ターゲットオントロジをデータ統合システムである Ontop [6] は, Ultrawap と同様,O = {t1 , t2 , ..., t|O| } と定義する. また, ti = pi (si , oi ) は, ター

入力を SPARQL クエリとし, SPARQL クエリの検索結果を出ゲットオントロジの各要素であり, 統合したデータを表現する力する.SPARQL クエリかつ, マッピングルールが GAV である

ための RDF トリプルである. このとき, si , pi , oi はそれぞれ,データ統合システムのうち, Ontop は最新の手法となっている.

RDF トリプルの主語, 術語, 目的語である.
4. 2. 3 URI 関 数

4 提案手法4. 1 提案手法の方針
本研究では，リレーショナルデータベースを情報源としたデータ統合の結果を RDF データの仮想的なビューとしてユーザに提供し，SPARQL による問合せを可能にするシステムを提案する．データ統合は基本的には GAV（Global-as-View）による統合を基本とし，システム管理者は，情報源に対する問合せの結果として統合後の RDF データを記述する．その際，情報源の各レコードに対応する実体に対して適切な URI を生成する必要がある．上で述べたように，URI の生成方法は複数存在し，情報源ごとに適切に設定する必要があることから，本研
究ではユーザ定義関数 URI およびその逆関数である URI−1 をシステム管理者が適切に実装することを前提として，データ統合および問合せ処理を行うフレームワークを提案する．これにより，情報源ごとの事情に踏まえた実用的な統合が可能となる．

4. 2 システムの構成
本研究が提案するデータ統合システムは次の 4 つの要素から,情報源とターゲットオントロジとのマッピングを定義する際，レコードが指す実体に対応する URI を生成する必要がある．本
手法では，これをユーザ定義関数 URI 関数としてシステム管理者が定義する. URI 関数とは, 入力レコードに対して対応するURI を返す関数である. 最も単純な例としては，情報源の特定の属性に含まれる URI をそのまま返す，あるいは，ID 属性に特定の URI 接頭辞を加える場合などが考えられる．また，URI関数の中で Wikiﬁcation [13] や DBpediaSpotlight [14] のような実体リンキングを呼び出す事によって，レコードやテキストに対応する実体およびその URI を得ることも可能である．

4. 2. 4 マッピング
ターゲットオントロジと統合するデータの情報源の対応関係を問合せによって記述する．ここで，リレーションではないターゲットオントロジに対して問合せ記述を可能とするため，RDF トリプル (s, p, o) をリレーション p(s, o) とみなすことで，SQL での扱いを可能にする．すなわち，ターゲットトントロジに出現するプロパティに対応するマッピングルールを記述することで，情報源のリレーションとの対応を明示する．

図 1 のように構成される. 四つの要素は, 統合するデータの情

本稿では, マッピングの集合を M = {m1 , m2 , ..., m|M | } と報源, 統合したデータを RDF として表現するためのターゲッ定義する. 各マッピング mi に関しては, 以下の (1) 式と表現

トオントロジ, ターゲットオントロジと統合するデータの情報する.

源の対応関係を表現するマッピング, マッピングを定義する際に用いられる URI 関数である.

mi : p(U RI(s), f (o)) ⊇ q(f ∈ {U RI, R})(1)

ここで, q は統合する情報源で記述された datalog クエリである．p(U RI(s), f (o)) は, ターゲットオントロジの要素である

RDF トリプルであり，主語は URI，目的語は URI もしくはリテラルであることを示している．すなわち関数 f は，目的語がAlgorithm 1 クエリ処理

URI の場合 URI 関数，リテラルの場合文字列を返す関数 R でInput: SPARQL クエリ Q, データ統合システム I =< S, O, M >ある．

Output: SPARQL クエリの回答 AQ
1: Initialize Qsql
2: for (ps (ss , os )) ∈ Q do

mi： ∀s, o(∃y1 , ..., yn (Sk .sa (ua )), ..., Sl .sb (ub ))⇒ p(U RI(s), f (o)))(f ∈ {U RI, R})

(2)

3:

Initialize Qor

4:for ((pm (U RI(sm ), f (om )) ⊇ q(sm , om ))(f ∈ {U RI, S})) ∈M do

このとき, s, o はクエリの検索結果に用いられる変数であり,5:

属性集合 u 内で用いられる属性変数でもある. また, y1 , ..., yn

6:は, 属性集合 u 内で用いられる属性変数であり, s, o とは違い,7:

end if

検索結果に用いられない箇所である.

8:

end for9:

Qsql ← addAN DQuery(Qsql , Qor )4. 3 URI 関数の分類

10: end for

URI 関数は, 関数の定義域 (統合元の情報源のデータ) と その値域 (統合先の URI) の対応関係によって分類することができる.

if ps == pm thenQor ← addORQuery(Qor , q(sm , om ))11: A ← Query(Qsql , S)
12: AQ ← M apping(A, M )13: return AQ

4. 3. 1 1:1 関 数
統合元の情報源のデータと統合先の URI が全て 1:1 で対応しているとき, その URI 関数は 1:1 関数という. 図 2 は, 日本

4. 4 クエリ処理の山の情報源と, wikidata の URI を対応付ける URI 関数の例

本研究で提案したデータ統合システムでは, ユーザが統合したである. この図 2 では, 富士山という情報源内のデータが与えデータに問合せるときには SPARQL 言語を用いる. SPARQLられると, wd:Q39231 を返すような URI 関数である.

言語で記述されたクエリは, BGP と FILTER で構成される.

BGP は, トリプルパターンの集合であり, クエリの本体部分である. FILTER は, BGP が持つトリプルパターンで用いた変数が持つ条件を記述する部分である.
提案したデータ統合システムは, SPARQL クエリを入力として受け取ると, SPARQL クエリで指定した SELECT 句における, 変数の組の結果を１レコードとした表形式のデータを出力
図 2 1:1 対応をする URI 関数例する.
また, 提案したデータ統合システムは, 仮想の RDF データを4. 3. 2 n:1 関 数扱うため, SPARQL クエリを直接適用することはできない. そ統合元の情報源のデータと統合先の URI が n:1 で対応してこで, マッピング M を用いて, SPARQL クエリと同等の SQLいるとき, その URI 関数は n:1 関数という. 図 3 は, 日本の山クエリを作成し, SQL クエリのクエリ結果に URI 関数を適用の情報源と, wikidata の URI を対応付けるような URI 関数例する. よって, ユーザは, SPARQL クエリに問合せたときと同である. この図 3 では, 富士山という情報源内のデータが与えじ検索結果を得ることができる.

られると, wd:Q39231 を返すような URI 関数である.

4. 4. 1 クエリ処理の流れ前述した 1:1 関数と異なるのは, Mt.Fuji という情報源内のマッピング M を用いて, SPARQL クエリと同等の SQL ク

データが与えられても, 富士山と同じ wd:Q39231 を返す点でエリを作成することを考える. このとき, SQL クエリを作成にある.

は Query Unfolding アルゴリズムを用いる. Algorithm 1 に,クエリ処理のアルゴリズムを示す.
クエリ処理では, データ統合システム I =< S, O, M > に対して, SPARQL クエリ Q が与えられたとき, SPARQL クエリ

Q の回答を返す. まず, 実際に情報源へ問合せるクエリとなる
Qsql の初期化を行う (1 行目). 次に, 各トリプルパターンに対して, そのトリプルパターンに合うマッピング m を用いることで, トリプルパターンは, トリプルパターンが包含する SQL ク
図 3 n:1 対応をする URI 関数例

エリに置き換えることができる (2-10 行目). 各マッピング mは, RDF トリプルと情報源の対応関係を表現しており, トリプ
ルパターンと情報源のクエリの対応関係にもなる.

ここで, ある 1 つのトリプルパターンが複数の SQL クエリを包含している場合があるため, このときは, その複数のSQL クエリで論理和をとることで, 情報源に対するクエリの回答を最大限得ることができる. アルゴリズム内では, 4-8 行目に対応し, 関数 addORQuery(Qor , q(s, o)) を用いて上記のパターンを表現している. 具体例でこの関数を説明すると,addORQuery((q1 ∩ q2 ), q3 ) の返り値は, ((q1 ∩ q2 ) ∪ q3 ) である.
SPARQL クエリの BGP に含まれる各トリプルパターン間の関係は, 論理積となっているため, トリプルパターンからSQL クエリに置き換える際には, 異なるトリプルパターン間のSQL クエリは論理積で結合させる. アルゴリズム内では, 9 行目に対応し, 関数 addAN DQuery(Qsql , q(s, o)) を用いて上記のパターンを表現している. 具体例でこの関数を説明すると,addAN DQuery((q1 ∩ q2 ), q3 ) の返り値は, ((q1 ∩ q2 ) ∩ q3 ) である.
ここまでの動作で, 実際の情報源に対する問合せを実行するために, SPARQL クエリは SQL クエリに変換することができる. 得られた SQL クエリを実際に情報源に対して実行することで, SQL クエリの回答 A を得ることができる. このとき得られた SQL クエリの回答 A は, URI 関数などを適用していないため, SPARQL に対する回答 AQ ではない.
最後に, マッピング M を用いて, SQL クエリの回答 A を,

∀x1 , x2 (∃y1 , y2 ((q1 (y1 , x1 )∪q2 (y1 , x1 ))∩q2 (y1 , y2 )∩q3 (y2 , x2 )))情報源に対して上記の SQL クエリを実行し, そして, クエリ結果にマッピングを実行すれば, SPARQL クエリの回答が得られる.

4. 4. 2 FILTER に URI を含む条件がある場合の処理
前項で紹介したクエリ処理では, FILTER の探索条件に URIを含まなければ, 問題なく SPARQL クエリの回答を得ることができる.
しかし, FILTER の探索条件に URI を含む場合, SPARQLクエリ内のトリプルパターンから SQL クエリに置き換える場
合には, URI を含む探索条件をそのまま SQL クエリに引き継ぐことはできない. なぜならば, 実際の情報源のデータは全て,URI 関数を適用する前の文字列で表現されているからである.
そこで, 提案するデータ統合システムでは, URI 関数は, 情報源の規模に合わせてデータ管理者が決定できることとする. 本稿
では, SPARQL クエリに対応する, URI を含む探索条件から,SQL クエリに対応する探索条件の変換関数を, U RI −1 (・) と表記する. ただし, 前述した関数の入力は URI のみとする.
具体例として, 図 5 の FILTER を含む SPARQL クエリが得られ, マッピングが以下のときの場合, どのように SQL クエリに置き換えられるか説明する.

SPARQL クエリに対して適した回答にマッピングすることで,SPARQL クエリに対する回答 AQ を得ることができる.
具体例として, 図 4 の SPARQL クエリが得られ, マッピングが以下のときの場合, どのように SQL クエリに置き換えられるか説明する.

図 5 SPARQL クエリ例 2:

FILTER に URI を含む SPARQL クエリ•マッピング– p1 (U RI(s), R(o)) ⊇ q1 (s, o)
図 4 SPARQL クエリ例 1: FILTER を含まない SPARQL クエリ– p1 (U RI(s), R(o)) ⊇ q2 (s, o)– p2 (U RI(s), U RI(o)) ⊇ q3 (s, o)•マッピング– p1 (U RI(s), R(o)) ⊇ q1 (s, o)– p3 (U RI(s), R(o)) ⊇ q4 (s, o)– p4 (U RI(s), U RI(o)) ⊇ q5 (s, o)– p1 (U RI(s), R(o)) ⊇ q2 (s, o)

SPARQL クエリ内の FILTER に関して, ex:c は URI である.

– p2 (U RI(s), U RI(o)) ⊇ q3 (s, o)与えられた SPARQL クエリは, マッピングの左辺に合わせて– p3 (U RI(s), R(o)) ⊇ q4 (s, o)与えられた SPARQL クエリは, マッピングの左辺に合わせて表記すると, 以下のように表記できる. ただし, SPARQL クエ
リで変数を表す記号である？は省略している.

表記すると, 以下のように表記できる. ただし, SPARQL クエリで変数を表す記号である？は省略している.

∀x1 , x2 (∃y1 , y2 , y3 (p1 (y1 , x1 ),p2 (y1 , y2 ), p3 (y2 , x2 ), p3 (y2 , y3 ), (y3 = ex:c)))∀x1 , x2 (∃y1 , y2 (p1 (y1 , x1 ), p2 (y1 , y2 ), p3 (y2 , x2 )))与えられたマッピングをもとに, 上記の SPARQL クエリを SQLクエリに置き換えると以下のように表記できる.

与えられたマッピングをもとに, 上記の SPARQL クエリを SQLクエリに置き換えると以下のように表記できる.

∀x1 , x2 (∃y1 , y2 , y3 ((q1 (y1 , x1 ) ∪ q2 (y1 , x1 ))∩q3 (y1 , y2 ) ∩ q4 (y2 , x2 ) ∩ (q5 (y2 , y3 ), y3 θU RI −1 (ex:c))))SPARQL クエリ内の FILTER で記載されていた探索条件は,SQL クエリでは, y3 θU RI −1 (ex:c) と表記される. ただし, θは演算子である. = ではなく θ と表記するのは, URI 関数がデータの取り得る数値の範囲などによって URI が決定する場
合, SQL クエリで情報源に問合せる際は = ではなく, 別の演算子になる可能性があるためである.

5 評価実験
本実験では, 提案手法に基づいて実装したシステムのクエリ処理が、現実的な時間で処理できるか検証する.

5. 1 データセット
本研究では, wikidata から観光に関する抽出したデータセッ
トを用いる. データセットは合計 45000 タプルのデータがあり,ジャンルごとに 4 つの情報源に分割されている.

5. 2 実 験 環 境
提案手法の実装には， Python3.9.2およびsqlite3(3.39.4)を用いた．実行環境は， Intel® Core™ i5-1038NG7 CPU を搭載した Mac OS 13.0.1 である．
また, 既存手法のデータ統合システムとして, Ontop CLI4.2.2 を用いた.
5. 3 実 験 方 法
本研究では, 表現するマッピング技術を RDF トリプルと情報源の対応関係ごとに指定できるデータ統合システムを実現することを目的としている. 提案したデータ統合システムのクエリ処理が, 現実的な実行時間で処理できるか確認するために, マッピングルールが GAV であるデータ統合システムの Ontop と比較する.
実験方法は, 評価クエリに対して同じ問合せ結果が得られるように, 比較手法である Ontop と提案手法でマッピングを記述する. そして, それぞれのデータ統合システムに対して評価クエリを実行し, 問合せ結果が得られるまでの実行時間を比較する.

5. 4 評価クエリ
結果の規模が異なるクエリを 4 つ作成し, これを用いて評価を行う．クエリ結果の規模はそれぞれ, 約 800, 約 2000, 約4000, 約 20000 タプルとなっている.
5. 5 実 験 結 果
2 つの手法について, 評価クエリごとの実行時間の比較を行う．各手法についての， 評価クエリごとの実行時間の比較を図1 に示す．図 1 から, 全ての評価クエリに対して, 提案手法が既存手法である Ontop に比べ, 短い実行時間で問合せ結果を返せることが示された.

表1

評価クエリごとの実行時間 [単位：s]

クエリ 提案手法

比較手法 (Ontop)

Q1

0.468

Q20.529

3.135
9.700

Q30.60115.471

Q40.640

51.096

6 まとめと今後の課題
本研究では, ユーザ定義関数である URI 関数を導入することで, 表現するマッピング技術を RDF トリプルと情報源の対応関係ごとに指定でき, 異種の情報源に対して SPARQL クエリで問合せることができるデータ統合システムを提案した. 実験から, 提案手法はマッピングと URI 関数を適切に設定することで, 既存手法である Ontop と同じ問合せ結果を得ることができることが示され, 更に既存手法よりも短い実行時間で問合せ処理をすることが示された.
今後の課題として, ユーザ定義関数である URI 関数と, マッピングルールに LAV(Local As View) を用いたデータ統合システムの検討が考えられる. 提案手法のマッピングルールは GAVを用いているため, 提案手法の実装は容易であるものの, 情報源が持つリレーションが頻繁に追加, 削除される場合, 提案手法のデータ統合システムは, その都度マッピングや URI 関数を更新しなければならない. そこで, もう一つのマッピングルールである LAV を用いることで, 情報源が持つリレーションが頻繁に追加, 削除されても, GAV に比べて少ない頻度で, マッピングの更新が済むことが期待できる.

文

献[1] データカタログサイト: https://www.data.go.jp/
https://www.digital.go.jp/[2] オ ー プ ン デ ー タ 100:
resources/data_case_study/[3] Serge Abiteboul, et al. Web Data Management. http://webdam.inria.fr/Jorge/files/wdm.pdf[4] Graham Klyne. Resource description framework (rdf): Concepts and abstract syntax. http://www.w3.org/TR/2004/
RECrdf-concepts-20040210/,2004.
[5] Steve Harris, Andy Seaborne, EricPrud hommeaux. Sparql
1.1 query language. W3C recommendation, Vol. 21, No. 10,p. 778, 2013.
[6] Diego Calvanese, Benjamin Cogrel, Sarah Komla-Ebri, Roman Kontchakov, Davide Lanti, Martin Rezk, Mariano
Rodriguez-Muro, and Guohui Xiao. Ontop: Answering
SPARQL Queries over Relational Databases. Semantic Web
Journal. 2017.
[7] J. F. Sequeda, M. Arenas, and D. P. Miranker. OBDA:
query rewriting or materialization? in practice, both! In
ISWC, 2014.
[8] Juan F. Sequeda, Daniel P. Miranker. Web Semantics: Science, Services and Agents on the World Wide WebVolume
22October, 2013 pp 19–39[9] Souripriya Das,Seema Sundara, Richard Cyganiak,
https://www.w3.org/TR/r2rml/[10] OWL(Web Ontology Language): https://www.w3.org/TR/owl-features/[11] Katsis, Y., Papakonstantinou, Y. (2009). View-based Data
Integration. In: LIU, L., ÖZSU, M.T. (eds) Encyclopedia ofDatabase Systems.
[12] Anastasia Dimou, Miel Vander Sande, Pieter Colpaert,Ruben Verborgh, Erik Mannens, Rik Walle Proceedings ofthe 7th Workshop on Linked Data on the Web 2014[13] Rada Mihalcea, Andras Csomai. Wikify! Linking Documents to Encyclopedic Knowledge. CIKM ’07: Proceedingsof the sixteenth ACM conference on Conference on information and knowledge management[14] DBpediaSpotlight: https://www.dbpedia-spotlight.org/