DEIM Forum 2014 D7-2

LINQ を用いた Linked Open Data に対する問合せ
井上

寛之†

天笠

俊之††

北川 博之††† 筑波大学大学院システム情報工学研究科コンピュータサイエンス専攻〒 305–8577 茨城県つくば市天王台 1-1-1†† 筑波大学システム情報系情報工学域 〒 305–8573 茨城県つくば市天王台 1–1–1
E-mail: †inohiro@kde.cs.tsukuba.ac.jp, ††{amagasa,kitagawa}@cs.tsukuba.ac.jp
あらましコンピュータによる処理に適したデータの公開，共有，および利用を Web 上で行う方法の一つとして，

Linked Open Data（LOD）が注目を集めている．近年，様々な種類のデータが LOD として公開され始めており，誰でも自由にアクセスすることができるため，LOD を利用するアプリケーションの開発が強く期待されている．一方，LOD の利用には，一般的に SPARQL と呼ばれる問合せ言語を用いるが，SPARQL の学習，記述にコストを要する．
また，LOD は巨大で複雑なグラフ構造を構成し，必要なデータへのアクセスは容易とは言えない．本研究では，アプ
リケーションやサービス等から目的の LOD へのアクセスを容易にするために，JSON 形式のビューを提供するシス
テムを提案する．具体的には，データベース設計者等が予め LOD に対して JSON 形式のビューを定義する，これに対して，利用者は C#言語などから利用可能な LINQ 構文を用いて問合せを行う事を可能にする．
キーワード

Linked Open Data，ビュー，LINQ，JSON

1. は じ め に
政府や行政などの公共機関が保有する様々なデータを，再利の知識を持ち得ないデータ利用者が，LOD として公開された
オープンデータを利用するのは容易ではない．
そこで，本稿ではビューを用いた LINQ による LOD に対す用可能な形式で外部へ公開する取り組みをオープンデータと呼る問合せを提案する．LOD に対するビュー定義に関する研究

び，近年先進国を中心に積極的に推進されている （注 1）．無償でについてもいくつか存在するが [1, 15]，本研究は LOD，RDFのアクセス，再頒布，再利用可能なデータをオープンデータとの知識を持たないユーザーによる LOD の利用を促進させる事

定義し

（注 2）

，多くの人が自由に計算機などから利用できるようを目的とする．そこで本手法は，予め LOD や RDF に知識のに，機械可読性を有する標準化された形式で公開されることがあるデータベース設計者らが定義した LOD に対する JSON推奨されている．このような構造化されたデータを Web 上でビューに問合せを行うことで，SPARQL を直接記述すること

公開，共有する一つの方法として LOD [5] が注目されている．

無く LOD への問合せを実現する．本論文では米マイクロソフ

LOD では，W3C によって標準化された Resource Descrip-

ト社が提供する.NET Framework の機能の一つである LINQ

tion Framework（RDF） [7] を用いて Web 上のリソース自身を用いて，C#等のプログラミング言語から LOD に対する問と，他のリソースとの関係を記述する．リソース間のリンクは，合せを実現する．

HTML 文書間におけるハイパーリンクと同様であり，LOD で本研究で提案する手法は，大きく二つに分けられる．１）

は異なる領域のデータが互いにリンクすることで，様々なデー（ 1 ） LOD や RDF に関する知識を有するデータベース設

タの活用を促進させる狙いがある．

計者等が，LOD の特定の箇所を便利に利用することができる

オープンデータのカタログサイト Datahub においては，2014

ビューを定義する

年 1 月の時点で 263 の団体から，およそ 8,900 件のデータセッ（ 2 ） LOD や RDF に関する知識の無いデータ利用者が，定トが LOD として公開されており，そのうち 882 個が LOD と義されたビューを利用して，目的のデータに対して問合せ等のされている （注 3）．これらのデータセットはだれでも無償で利操作を行う

用することができるが，RDF を用いて記述された LOD は，本研究では，ビューを用いた問合せを行うための Web API

SPARQL [14] と呼ばれる RDF 問合せ言語を利用して目的のを検討する．またコレクションへの問合せ，集約処理に長ける

データを得るのが一般的である．ただし SPARQL の記述に際

LINQ を用いてこの Web API へリクエストすることで，既存しては，問合せ言語の習得，LOD および RDF の関連技術にのプログラミング環境から LOD への問合せを，特別な知識をついての知識が必要になる．また，RDF は本質的にはグラフ必要とせずに実現する．

構造であり，LOD は複雑かつ冗長な構造になるため，これら

本稿の構成は以下のとおりである．2. 節では本論文に必要な基本的事項について解説する．3. 節では，ビューを用いた問合（注 1）：http://www.mofa.go.jp/mofaj/gaiko/page4_000099.html

せ書き換えの手法について述べる．4. 節では，本手法の評価の（注 2）：http://opendefinition.org/

ための実験計画について説明する．5. 節で，本手法の関連研究（注 3）：http://datahub.io/dataset

を説明し，6. 節でまとめと今後の課題について述べる．

表 1: SPARQL クエリの基本構造

2. 基本的事項
2. 1 RDF
RDF [7] は，Web 上のリソース自身と，他のリソースとの関節
接頭辞宣言
データセット定義
結果節

係を記述する枠組みである．RDF では，Universal Resource

Identifier（URI，統一資源識別子）によって識別されるものす

クエリパタン

べてをリソースとして扱い，文書や画像だけでなく，人や施設，
クエリ修飾子リソース間の意味までもリソースとして扱われる．あるリソー
スの一つのメタデータは，主語（Subject），述語（Predicate），

キーワード
PREFIXFROM
SELECT
CONSTRUCTASKDESCRIBE
WHERE
FILTERORDER BY (DESC)
LIMIT
OFFSETDISTINCT

説明
名前空間接頭辞宣言
探索対象のグラフ IRI（URI）
指定した変数の値を返す
指定した構造で RDF を作り，返す
指定したパタンの存在を有無を返す
指定したパタンを含む DB 内のグラフを返す
グラフパタンの指定
条件式
順序指定
取得件数指定オフセット指定
重複の除去

および目的語（Object）によって記述される．主語はメタデー
タを記述する対象のリソース，述語は主語に関する情報のプ１）存在（EXISTS，NOT EXIST），２）比較演算子（“=”，“>=”

ロパティもしくは特徴を定義し，目的語は述語の対象となる値など）が利用可能である．

を格納する，これはら三つ組でトリプルと呼ばれる．主語及び2. 3. 1 SPARQL エンドポイント

述語は URI で，目的語は URI もしくはリテラルで記述し，そLOD に対して HTTP リクエストによって直接 SPARQL をのデータ型や言語に関する情報を付与することも可能である．

実行するフロントエンドを SPARQL エンドポイントと呼ぶ．

RDF グラフを図示する場合は，リソースを楕円で，リテラル

SPARQL エンドポイントはトリプルストア（RDF ストア）がは句形で表す．

提供する機能であり，Virtuoso （注 5） や Fuseki （注 6） などが挙げ

2. 2 LOD

られる．Web 上のパブリックな SPARQL エンドポイントに

LOD は構造化されたデータを Web 上で公開，共有する一

ついて，その可用性をチェックしている “SPARQL Endpoints

つの方法であり，データ同士をリンクさせることで「データのStatus” （注 7） によれば，全世界に 457 の SPARQL エンドポイ

ウェブ」を構築する運動そのものを指す．また，LOD は標準

ントが存在する．

化された RDF や HTTP などから構成される，データセットの多くの SPARQL エンドポイントが，問合せの結果として様々集合である．LOD として公開されるデータは原則として，以な形式に対応している．主に，XML（XHTML），CSV，TSV，下の４原則が定義されている （注 4）．

JSON などが挙げられる．また問合せの種類によって利用可能（ 1 ） URI をあらゆるデータの識別子として利用するな形式が限られる場合がある．これは結果節でのキーワードの（ 2 ） 識別子には HTTP スキームの URI を利用し，アクセ

指定に依存し， SELECT 句は RDF グラフではなく指定されたス可能にする

変数の値について結果を返すが， CONSTRUCT 句を指定した場（ 3 ） URI にアクセスされた際には有用な情報を，RDF な

合は指定されたグラフ構造に結果を RDF として整形して返す

どの標準化された形式で提供するためである．

（ 4 ） データに他の情報源における URI を含め，より多く

統合言語クエリ（Language-Integrated Query, LINQ） （注 8）の情報発見を促進する．

はマイクロソフト社の.NET Framework が提供する，様々な情

2. 3 SPARQL

報源から得られる集合に対して統一的な方法で問合せ等の操作

RDF の 集 合 で あ る LOD に 対 す る 問 合 せ 言 語 と し て ，を行う，プログラミング言語に統合された機能である．LINQSPARQL [14] が W3C によって標準化されており，近年デファを用いた構文では，SQL や SPARQL のように宣言的に集合にクトスタンダードとして幅広く利用されている．SPARQL 処理

対して操作を記述することができる．

系はクエリからグラフパタン（Basic Graph Pattern，BGP）

LINQ の利点として，以下が挙げられている （注 9） ．

を構築し，そのパタンに一致するリソースを RDF 集合の中か（ 1 ） 簡潔で読みやすい（特に複数の条件をフィルター処理

ら探し出す．最新版である SPARQL 1.1 では，単純な選択にする場合）とどまらず，BGP に適合する問合せ結果から新たな RDF を生（ 2 ） 強力なフィルター処理，並び替え，およびグループ化

成する機能（CONSTRUCT 句）や，集約演算などがサポートされ機能を最小限のアプリケーションコードで実現できるている．

（ 3 ） ほとんど変更せずに，他のデータソースに移植できる

SPARQL クエリの基本的な構造を表 1 に示す．SPARQL ク

LINQ は主に C#，Visual Basic .NET などのプログラミン

エリにおいて，名前空間宣言が複数用いられる場合は PREFIX

グ言語で利用することができるが，Java，JavaScript，PHP，

句で複数宣言する．SPARQL において，変数は “?” 文字から始

Pytho などのプログラミング言語で LINQ の構文を実現する試めることで宣言できる．この変数を使って見つけ出すグラフパ

みは数多く存在する．.NET Framework 標準の機能では，文字タンを Turtle 形式で WHERE 節に記述し，選択条件を SELECT
句で記述する．WHERE 句ではそれぞれの変数について FILTER
句を用いて条件を記述することができる．条件の種類としては，（注 5）：http://virtuoso.openlinksw.com/（注 6）：http://jena.apache.org/documentation/serving_data/（注 7）：http://sparqles.okfn.org/（注 8）：http://msdn.microsoft.com/en-us/library/bb308959.aspx（注 4）：http://www.w3.org/DesignIssues/LinkedData.html（注 9）：http://msdn.microsoft.com/ja-jp/library/bb397919.aspx

列型や数値型のコレクション，RDB のレコードや XML 文書の要素集合などに対して SQL に似た構文で問合せ，集約などの操作を行うことができる．また，独自にプロバイダを実装すことで，任意の情報源に LINQ の構文でアクセスすることができる．

2. 4 JSON（JavaScript Object Notation）
JavaScript Object Notation（JSON）はデータ記述言語の一つであり，JavaScript 言語におけるオブジェクト表記方法として定義され，標準化された [10]．近年では，複数のフトウェ
アや他のプログラミング言語間でのデータのやり取りに，広く利用されている．JSON はデータ型として，数値，文字列，真偽値，配列，オブジェクト（連想配列），null を利用することができる．オブジェクトのキーの値は文字列である必要がある．

2. 4. 1 JSON スキーマ
JSON スキーマ （注 10） は JSON で任意のデータを記述するためのスキーマ定義を行うものである．要素の名称，データ型，お図 1: 提案モデル

よび中身の構造などについて JSON を用いて定義する．JSON
スキーマは，現在 IETF による標準化プロセスにある（注 11）．

3. ビューを用いた LINQ による LOD に対する問合せ
本節では，ビューを用いた LINQ による LOD への問合せについて説明する．

3. 1 概要本研究で提案するビューを用いた LINQ による LOD に対する問合せについて，概要図を図 1 に示す．本研究は，図中のク

図 2: RDF グラフ例

エリトランスレータを導入することで，アプリケーションから
表 2: ビュー定義クエリの構造

LOD に対して直接 SPARQL を発行する必要を無くす．代わりに，予め LOD や RDF に関する知識をもつデータベース設計者等によって定義されたビューを利用し，LINQ による LODへの問合せを可能にする．このため，予め JSON 形式のビューを与えておき，LINQ 問合せの変換に用いる．本手法を実現す節
接頭辞宣言
データセット定義
結果節
クエリパタンPREFIXFROM
SELECT
WHERE
FILTER

クエリ修飾子るために，以下の二つの項目について検討する必要がある．

ORDER BY (DESC)
LIMIT
OFFSET（ 1 ） LOD に対する JSON ビューの定義（ 2 ） 定義されたビューを用いた問合せ

キーワード

DISTINCT

JSON スキーマ

AS JSON

説明
名前空間接頭辞宣言
探索対象のグラフ IRI（URI）
指定した変数の値を返す
グラフパタンの指定
条件式
順序指定
取得件数指定オフセット指定
重複の除去
結果の JSON スキーマを指定

必須項目
いいえ
いいえ
はい
はい
いいえ
いいえ
いいえ
いいえ
いいえ
はい

これはそれぞれ，図 1 内の（1），（2）に対応する．
（1）LODに対する JSON ビュー定義は 3. 2 節で，（2）ビューを用いた

LOD への問合せについては 3. 3 節でそれぞれ述べる．また実際に LINQ を用いて問合せを行う例を 3. 4 節に示す．本手法の実装については 3. 5 節で説明する．

3. 2 LOD に対する JSON ビューの定義
LOD に対する JSON ビューは，LOD や RDF に関する知識を持つデータベース設計者等によって，特別な知識を持たない
アプリケーション開発者のために予め定義される．ビューの定義には，SPARQL クエリおよび JSON スキーマを基に行う．

SPARQL によるビュー定義の例を示す．図 2 は RDF グラ
フの例である．このグラフには，ある人（“Person_1”）の姓（“last”），名（“first”），身分（“rdf:type”），所属研究室（“be-long_to”），住んでいる街（“live_in_cit”）が含まれている．
このグラフから，実アプリケーションで利用するような文字列型，数値型の値を得るにはグラフを辿る必要がある．そこ
で，ここではこのグラフが持つ文字列型，数値型の値が RDBのタプルのように取得可能なビューを検討する．データベース
設計者が目的の値を選択する SPARQL クエリ，および結果のテンプレートとなる JSON スキーマを記述し，ビューとして登録する．本研究で提案する，ビュー定義に用いる拡張された

SPARQL クエリの構造を表 2 に示す．
3. 2. 1 JSON スキーマによる結果フォーマットの定義
ビュー定義にはデータ利用者が最終的に受け取る JSON の構造が指定される．具体的には選択を行う SPARQL クエリに続（注 10）：http://json-schema.org/（注 11）：http://json-schema.org/latest/json-schema-core.html

けて， AS JSON 句に JSON スキーマを記述する．SPARQL に

SELECT ?last ?first ?position ?labname ?cityname ?gpa

表 3: 本手法が対応する.NET Framework 標準クエリ演算子

WHERE {

キーワード 説明

?person aStudent ;foaf:name?name ;

live_in_city?city ;

belong_to?lab ;

gpa?gpa .

Student rdf:label?name?position .

foaf:firstName ?first ;foaf:lastName?last .

?city

rdf:label?cityname .

?labfoaf:name?labname . }Select

射影演算子

Where

選択演算子

GroupBy

グループ化演算子

OrderBy

順序付け演算子Min

最小値演算子Max

最大値演算子Sum

合計値演算子

Count

集計演算子

Average

平均値演算子AS JSON {{"type":"object", "properties":{"results": {用している．
得られた式木を元に，SPARQL エンドポイントに対する問合"type":"array", "items":{"type":"object", "properties":{?last:{ "type":"string" },?first:{ "type":"string" },せを生成する．基本的には，式木のリーフに当たるデータソースが対象とする JSON ビューである場合，対応する問合せをそのまま SPARQL エンドポイントで処理することで LINQ 問合せ?position: { "type":"string" },が必要とする情報が得られる．これを定義された JSON ビュー?labname:{ "type":"string" },に従わせ，LINQ 処理系に返すことで結果を得ることが可能で?cityname: { "type":"string" },ある．ただし以下のような場合，対応する処理を SPARQL エ?gpa:

ンドポイント上で実行することにより，処理の効率化が図れる{ "type":"number" }}}}}}}

場合がある．

リスト 1: ビュー定義クエリの例（PREFIX は省略）

データソースに対して，絞り込み（選択），射影，グルーピ
ング等の条件が存在する場合，これらをデータソースに対するSPARQL 問合せへプッシュダウンすることで，SPARQL エン{ [ { "last": "Inoue", "first": "Hiroyuki","position": "M2","labname": "北川データ工学研究室","cityname": "Tsukuba", "gpa": "3.14" },{ "last": "Tsukuba", "first": "Taro","position": "M1", ... }ドポイント上で処理が可能である．この場合，結果としてネットワーク上を転送されるデータ量が減るため，その分のコストも抑えることができる．一方，SPARQL エンドポイントの処
理性能やレスポンスが遅い場合もあり，そのときは多くの処理をなるべく LINQ 処理系の側で実行した方が効率的な場合も] }ある．この観点から，適切なコストモデルを設定して，コスト
リスト 2: リスト 1 から得られる JSON の例

ベースの問合せ最適化を行うことが考えられるが，これは今後の研究課題である.
具体的に，式木から SPARQL エンドポイントに対する問合

おいて変数は，“?position” といったような “?” 付き文字から始
まるが，SPARQL エンドポイントから得た値は JSON スキー
マにおける同一の変数名に展開される．JSON の特徴を活かした，任意の階層構造，多値を配列で表現するといった結果
フォーマットの定義が可能である．リスト 1 に図 2 の RDF グ

せの生成について説明する．LINQ 問合せにおける演算子について，本手法が対応する演算子を表 3 に示した．これらは式木においてそれぞれの式の演算子として利用されるため，式の解析が必要となる．式は種類ごとに異なるクラスで表現されるため，本手法では以下の４つのクラスに注目して情報を得る．

ラフに対するビュー定義の例を示す．また，リスト 2 にビュー
定義 1 から得られる JSON の例を示す．

MethodCallExpression クラス

3. 3 ビューを用いた問合せ

静的メソッド，もしくはインスタンスメソッドの呼び提案手法における LINQ 問合せの処理方法を説明する．

出しを行う式．クエリ演算子はこのクラスの式に含データベース設計者によって定義されたビューに対して，アまれる． Method プロパティが演算子（メソッド），

プリケーション開発者（データ利用者）が LINQ 問合せを行う．

Arguments がその式の被演算子（引数）である．

与えられた問合せを構文解析することで，ノードがクエリ演算

NewExpression クラス

子，エッジが演算子間の依存関係を表す式木を得ることができ

コンストラクタメソッドの呼び出しを行う式であるが，る．LINQ 問合せから式木への変換については，本研究の対象

LINQ においては射影の結果を格納する無名クラスをから外れるためここでは詳しく議論しないが，.NET の構文解作成するときに作成される．複数変数の射影として析木を利用することで式木を得ることができるため，これを利扱う．

var context = new Context( "http://example.com/view/1/" );Algorithm 1 式木の解析および問合せ書き換え
procedure ExtractExpression(expression)
if expression.type is MethodCallExpression || NewExpression thenmethod ← expression.method.namefor all ( doargument ∈ expression.arguments)
ExtractMethodCallExpression(argument)
end forend ifif expression.type is BinaryExpression thenExtractBinaryExpression(expression.arguments)
end ifif expression.type is ConstantExpression thenExtractConstantExpression(expression.arguments)
end ifend procedure
procedure ExtractMethodCallExpression(expression)
condition ← ∅if expression.method is ’Select’ thencondition.method ← ’Projection’condition.variable ← ExtractExpression(expression.argument)
ReWriteSelectStatement(condition)end ifif expression.method is ’Where’ thencondition.method ← ’Selection’condition.conditions ← ExtractBinaryExpression(expression.argument)
AddFilterCondition(condition)end ifif expression.method is ’Min’ || ’Max’ || ’Sum’ || ’Count’ || ’Average’
thencondition.method ← the method which was detectedcondition.variable ← argument.variable
Return condition
end ifif expression.method is ’GroupBy’ || ’OrderBy’ thencondition.method ← ’GroupBy’ || ’OrderBy’
condition.variable ← ExtractExpression(expression.argument)
AddGroupOrOrderCondition(condition)end ifreturn ∅end procedure
procedure ExtractBinaryExpression(expression)
conditions ← ∅condition.operator ← expression.operator
condition.lef t ← EcstractExpression(expression.lef t)
condition.right ← ExtractExpression(expression.right)
Return conditionend procedure
procedure ExtractConstantExpression(expression)
Return Cleansing(expression.value)
end procedurevar labnames = from person in context
where person["first"] == "Hiroyuki"
select person["labname"];

リスト 3: LINQ による問合せの例

図 3: リスト 3 の処理木

BinaryExpression クラス
二項演算子をもつ式．条件式として用いられる．演算子と，左右の被演算子を持つ．

ConstantExpression クラス
定数を表現する式．条件式で用いられる． Value プロ
パティが定数である．
式木の解析及び問合せ書き換えアルゴリズムを Algorithm 1に示す．問合せ対象のビューは LINQ 問合せ時にビューごとのURI にリクエストされるものとし，式木の解析時には既に書き換え対象のビューは認識されているとする．まず， ExtractEx-

pressions は入力された式から再帰的に演算子や条件を抽出す
る． ExtractMethodCallExpression は MethodCallExpression
クラスの式から演算の種類や対象となる変数，条件式等を探し出し，射影の場合は変数が揃い次第 SELECT 句の書き換えを行う．選択の場合は条件式を二項演算の演算子と変数を取得する ExtractBinaryExpression を用いて，揃い次第 FILTER
句を WHERE 句に書き加える．集合演算の場合は， SELECT 句，FILTER 句， ORDER BY 句で利用される可能性があるため，書き換えは行わず，演算子の種類と変数名を返す．グループ化演算子，もしくは順序演算子の場合は変数が揃い次第 WHERE 句の後

SELECT ?labname
WHERE {に書き加える． ExtractConstantExpression は与えられた式か<-- グラフパタン -->ら定数を見つけ出す． 3. 4 節で具体的な問合せの例を示す．

FILTER (str(?first) = "Hiroyuki")

3. 4 LINQ を用いた問合せの例
アプリケーション開発者（データ利用者）は LINQ クエ}

リスト 4: LINQ 問合せ 3 から生成された SPARQL

リを記述する際に利用するビュー URI を入力として，コン
テキストを作成する．作成されたコンテキストは指定された
ビュー URI に対して LINQ 問合せを行う．リスト 3 は ViewURI{ [ { "?labname": "北川データ工学研究室" } ] }（http://example.com/views/1/）で，リスト 1 で定義された

リスト 5: リスト 4 の結果（JSON）

ビューが利用可能であるとして，“first” 属性が “Hiroyuki” であるようなリソースの研究室名（“labname”）を取得する LINQ 問合せである．この問合せは，選択および射影を行うので，LINQ
コンテキストでは図 3 に示す式木が組み立てられる．これに基づいた SPARQL クエリ生成がクエリトランスレータによって行われ，最終的にリスト 4 に示すクエリを SPARQL エンドポ
イントに問合せる．また結果の JSON としてリスト 5 がアプ
リケーションに返される．

3. 5 実装本研究では提案手法である LOD に対するビュー定義とクエリ書き換えを行うクエリトランスレータ，及びアプリケーショ

ンからビューに対する条件を組み立て，クエリトランスレータ
へリクエストする LINQ プロバイダの実装を行った．それぞれ説明する．

3. 5. 1 クエリトランスレータ
クエリトランスレータの役割は，１）ビューの管理，２）
ビューと条件に基づいたクエリ書き換え，および LOD へのリクエストである．
（1）ビューの管理について．クエリトランスレータは，ビュー

URI，タイトル，概要，ビューを用いることで得られる属性とそのデータ型を保存する．
（2）クエリトランスレータの実装について．クエリトラン
スレータは Ruby 言語およびその Web フレームワークである

Sinatra （注 12） を用いて実装した．LINQ プロバイダからのアク
セスは HTTP で発行され，URL パラメータとしてパーセント
エンコーディング （注 13） された LINQ 問合せ条件を受け取る．
クエリトランスレータは “LodViewRewrite” （注 14） ．として，

LINQ 問合せを受け付ける Web アプリケーションは “Lod-

図 4: 実験環境

ViewWebApp” （注 15） ．として，それぞれオープンソースで開発されている

SELECT DISTINCT ?label ?value

3. 5. 2 LINQ プロバイダ

WHERE {

LINQ プ ロ バ イ ダ の 実 装 は 一 般 的 に 行 わ れ て い?product a bsbm-inst:ProductType105 ;る System.Linq.IQueryable<T>イ ン タ フェー ス お よ び ，rdfs:label ?label ;System.Linq.IQueryProvider プロバイダの実装を行うことで実現した．

bsbm:productPropertyNumeric1 ?value .
}AS JSON {実装した機能としては，射影，選択，集約演算の一部である．
複雑な GroupBy， Having（グループ化後の選択）や複数情報源にまたがった結合演算（JOIN）はサポートしていない．これ{"type":"object", "properties":{"results": {"type":"array", "items":{"type":"object", "properties":{

らのサポートは今後の課題である．

?label: { "type":"string" },実装においては，“LINQ: Building an IQueryable provider

series”（注 16）

や，“LINQ to Twitter”（注 17）?value: { "type":"number" }の実装を参考にした．

LINQ プロバイダは，“LodViewProvider” という名称で，オープンソースで開発されている （注 18）．

}}}}}}

リスト 6: ビュー定義（PREFIX は省略）

4. 評 価 実 験
提案手法性能を調査するための実験による評価を行ったので，実験環境を図 4 に示す．図中の（1）-（3）はそれぞれ，（1）

LINQ 問合せを行う Windows アプリケーション （注 20），（2）ク

その結果を報告する．
実験の目的は，提案手法が実際に実用可能な性能で動作する

エリトランスレータ （注 21），（3）Fuseki （注 22） である．Windows

ことを実環境で確認することと，ビューを扱うためのオーバー

アプリケーションとクエリトランスレータは同一のコンピューヘッドを実機で確認することにある．このため，提案手法に加タで，Fuseki は別のコンピュータにそれぞれ設置され，全てのえて，LINQ 問合せと等価な SPARQL 問合せを SPARQL エ

通信は HTTP で行われる．
本実験で利用したデータセットは，SPARQL エンドポイント

ンドポイントに投入し，両者の実行時間を比較する．
提案手法は，Windows 7 に実装され，ビューに対する LINQ

（およびトリプルストア）のベンチマークを行うプロジェクト

問合せを受け付ける．この問合せは，Mac OS X 上のクエリである Berlin SPARQL Benchmark [6] が開発する，“BSBM

トランスレータに Web API 経由で転送され，ビュー定義に基

Tools” （注 23）を利用して作成した．このツールは製品のメタデー

いて SPARQL クエリが生成される．生成された SPARQL 問

タや製造者に関するテストデータを生成する．生成するトリプ

合せは，SPARQL エンドポイントへのリクエストとして送信

ル数や出力形式を柔軟に指定することが可能である．この RDFされる．SPARQL エンドポイントには，Fuseki（注 19）を用いた．Fuseki は，Java で RDF を扱うライブラリである Apache

Jena の成果物の一つであり，既存の RDF ファイルを用いて
SPARQL エンドポイントを立ち上げることができる．

データに対して，リスト 6 に示す定義に従って JSON ビューを構築した．

LINQ による JSON ビューに対する問合せ，およびそれと等
価な SPARQL 問合せの実行時間を比較する．LINQ 問合せにおいては，それぞれ１）式木の分析（Analyze），２）SPARQL（注 12）： http://www.sinatrarb.com/

エンドポイントへのリクエストおよび結果の受取り（Request），（注 13）：http://tools.ietf.org/html/rfc3986\#section-2.1

３）受取った結果の整形（Format）について時間を計測した．

（注 14）： https://github.com/inohiro/LodViewRewrite/（注 15）： https://github.com/inohiro/LodViewWebApp/

一方，SPARQL 問合せの場合は，SPARQL エンドポイントへ（注 16）：http://blogs.msdn.com/b/mattwar/archive/2008/11/18/linq-links.
aspx（注 20）：Windows 7 (32bit, VM), 2GB RAM, .NET Framework 4.5（注 17）：http://linqtotwitter.codeplex.com/（注 21）：Mac OS X, Core i7 2.4 GHz, 8GB RAM, ruby 2.0.0（注 18）： https://github.com/inohiro/LodViewProvider/（注 22）：Ubuntu Server 12.04, Core i5 2.8GHz, 6GB RAM, java 1.7（注 19）：http://jena.apache.org/documentation/serving_data/（注 23）：http://sourceforge.net/projects/bsbmtools/表 4: 実験を行った問合せの種類と条件

var query = from resource in context
where Int32.Parse( resource["value"] ) < 400orderby resource["label"]select resource;

リスト 7: LINQ 問合せ

種類
射影
最大値
最小値
平均値
並び替え
選択と射影
選択と平均値条件
名称（“label”）だけ得る価格（“value”）の最大値を得る
価格（“value”）の最小値を得る
価格（“value”）の平均値を得る
価格（“value”）について昇順に並び替えた結果を得る
価格（“value”）が “400” 以下の製品の名称（“label”）だけ得る価格（“value”）が “400” 以上の製品の価格の平均値を得る

SELECT DISTINCT ?label ?value
WHERE {
?product a bsbm-inst:ProductType29 ;rdfs:label ?label ;bsbm:productPropertyNumeric1 ?value1 .
FILTER (?value < 400 )}ORDER BY ?label

リスト 8: SPARQL 問合せ（PREFIX は省略）

図 6: 問合せの種類に対する問合せ性能（それぞれ 5 回の平均値）

4. 2 問合せの種類に対する問合せ性能
問合せに含まれる関係演算や問合せの複雑度が問合せ性能に与える影響を調査した．
本実験では，SPARQL エンドポイントが持つトリプル数を“3,564,773” 個に固定して行った．具体的に実験を行った演算とその条件について表 4 に示す．
図 5: トリプル数に対する問合せ性能（それぞれ 5 回の平均）

図 6 に演算ごとに 5 回計測を行って得た結果の平均値を示
す．横軸，縦軸はそれぞれ演算の種類，実行時間（msec）を表
す．いずれの演算子においても，本研究が提案する LINQ 問合のリクエストを開始時点から結果を受け取るまでの時間を計測

せから SPARQL 問合せを生成する方法は，直接 SPARQL 問した．

合せを行う場合のおよそ 3 倍程度の実行時間になることが示

4. 1 トリプル数に対する問合せ性能された．具体的には平均して，式木の分析（Analyze）に 7.16使用した LINQ 問合せおよび対応する SPARQL 問合せはそ

msec，SPARQL エンドポイントへの問合せおよび結果の取れぞれリスト 7，リスト 8 の通りである．データセットはそれ得（Request）に 236.4 msec，結果の整形（Format）に 25.1

ぞれ “5,007”，“40,377”，“374,911”，“3,564,773”，“35,272,182”

msec，合計すると 268.66 msec かかっている．一方，SPARQL

個のトリプルを含むデータを前述の RDF ジェネレータで生成を直接リクエストした場合は，79.83 msec である．

した．
図 5 に，トリプル数ごとに計測を 5 回ずつ行って得た結果

5. 関 連 研 究の平均値を示す．横軸，縦軸はそれぞれ，トリプル数の変化，

5. 1 LOD，RDF に対するビューの導入

実行時間（msec）を表している．提案手法であるビューを用い

RDF の集合に対するビューの導入に関する研究は LOD のた LINQ による問合せは平均的に，SPARQL を直接実行した概念が登場する前から行われている [8, 11, 13, 15, 16]． [8] お場合のおよそ 3 倍程度の実行時間で問合せを行えることがわ

よび [11] は双方とも 2005 年の論文であり，現在の仕様とは異かった．具体的には平均して，式木の分析（Analyze）に 7.53

なる SPARLQL を対象に，前者はスキーマレベルのビュー定

msec，SPARQL エンドポイントへの問合せおよび結果の取得義を提案している．後者は RDB に格納された RDF に対して

（Request）に 244.4 msec，結果の整形（Format）に 24.1 msec

集約演算を独自に開発した． [16] はセンサ等から得た時系列

かかり，合計すると 276.03 msec である．一方，SPARQL を

RDF データに高速にアクセスするための一時的なビューの設

直接リクエストした場合は， 87.7 msec かかっている．トリプ計に関する研究である．本手法が LOD を利用しようとするア

ル数が変化しても，実行時間に大幅な変化は見られなかった．

プリケーションに対して，複雑性を除去して利用させる点で類似する．ただし SPARQL による問合せを想定している．

Le ら [15] や，Etcheverry ら [12] の研究は，LOD に対して

SPARQL エンドポイントの性能を考慮する

SPARQL クエリを用いてビュー定義を行う点で本研究と類似す（ 5 ） 複数情報源を跨いだ結合演算（JOIN 句）の実現

るが，彼らの定義するビューは CONSTRUCT 句を用いた，RDF を•

結合演算は，1）LINQ 側で行う場合，2）クエリトラン

生成するビューである．一方，本研究が提案するビューは LOD

スレータで行う場合，および 3）SPARQL 問合せとしてエンドへの問合せを簡単化する目的の JSON ビューであり，ビューのポイントで行う場合の三つの方法が考えられるため，3 に示し

定義と研究の目的が異なる．

たコストモデルに基づいて最適な処理系で演算を行う

RDB に格納されたデータに対して RDF としてアクセスするためのビュー定義については数多くの研究，およびソフトウェ謝

辞アとしての実装が存在する [2–4, 9]．これらの手法は仮想的な本研究の一部は，共同研究（富士通研究所 CPE25149），JSPS

RDF 集合をビューとして作り出し，SPARQL クエリを SQL

科研費（25240014），および文部科学省委託業務「ビッグデーに書き換えて問合せを行う．対象がリレーショナルデータであタ利活用のためのデータ連携技術に関するフィージビリティス

る点が，本研究とは異なる．

タディ及び予備研究」による．

5. 2 LINQ を用いた LOD へのアクセス[1] は.NET 言語向けのライブラリ “LINQ to RDF” （注 24） を用いて，Web 上の LOD に対して LINQ 問合せによる SPARQL
クエリの発行について説明している．この手法では，取得対象となるリソースがどのような属性を持つグラフ構造であるかを
アプリケーション開発者が把握して，これに合わせた問合せ結果を格納するクラスを実装することで LINQ を用いた問合せを実現している．一方，本研究ではビューを定義することで LODのリソース集合を抽象化し，アプリケーション開発者は特定のビューに対する LINQ 問合せを記述するだけで，LOD のグラ
フ構造を知ること無く，LOD に対する問合せを行うことができる点が異なる．

6. ま と め
本稿では，ビューを用いた LINQ による LOD に対する問合せ手法の提案を行った．本手法では，RDF，LOD および

SPARQL の知識を持たないアプリケーション開発者が，デー
タベース設計者等によって定義された JSON ビューを利用することで，直接 SPARQL を記述すること無く，LOD への問合せを行うことを実現した．
本手法が実用的な速度で動作することを確認する実験では，
直接 SPARQL 問合せを行うのと比べ，サポートする全ての演算でおよそ 3 倍前後の処理時間で問合せを行えることがわかった．また，トリプル数の変化に影響されない事を示した．
今後の課題としては以下が挙げられる．
（ 1 ） クエリトランスレータから SPARQL エンドポイント
に対する問合せ（Request）の高速化（ 2 ） 射影条件が変わった場合の，結果となる JSON のコン
パクション

•

例えば，LINQ 問合せの射影条件が一つの変数である場

合，JSON スキーマによって定義された結果テンプレートに従うのではなく，配列等を用いたより効率的な構造へのコンパクションなどが考えられる（ 3 ） 複雑な射影演算（HAVING 句）の実現（ 4 ） コストモデルに基づいた問合せ最適化•

具体的には，問合せの複雑性，選択率，および問合せ先（注 24）：http://code.google.com/p/linqtordf/

文献[1] Exploiting the RDF-based Linked Data Web using .NET
via LINQ. http://virtuoso.openlinksw.com/whitepapers/
rdf%20linked%20data%20dotNET%20LINQ.html.
[2] RDF Support in the Virtuoso DBMS. volume 113 of LNI,
pages 59–68. GI, 2007.
[3] Sören Auer, Sebastian Dietzold, Jens Lehmann, SebastianHellmann, and David Aumueller. Triplify: Light-weightlinked data publication from relational databases. WWW’09, pages 621–630, New York, NY, USA, 2009. ACM.
[4] Christian Bizer. D2rq - treating non-rdf databases as virtual RDF graphs. In In Proceedings of the 3rd International
Semantic Web Conference (ISWC2004, 2004.
[5] Christian Bizer, Tom Heath, and Tim Berners-Lee. Linked
data - the story so far. Int. J. Semantic Web Inf. Syst.,
5(3):1–22, 2009.
[6] Christian Bizer and Andreas Schultz. The Berlin SPARQL
Benchmark. International Journal On Semantic Web andInformation Systems, 2009.
[7] Jeremy J. Carroll and Graham Klyne. Resource Description Framework (RDF): Concepts and Abstract Syntax.
W3C recommendation, W3C, February 2004. http://www.
w3.org/TR/2004/REC-rdf-concepts-20040210/.
[8] Huajun Chen, Zhaohui Wu, and Yuxin Mao. Rdf-based
ontology view for relational schema mediation in semantic web. KES’05, pages 873–879, Berlin, Heidelberg, 2005.
Springer-Verlag.
[9] Richard Cyganiak, Souripriya Das, and Seema Sundara.
R2RML: RDB to RDF Mapping Language. W3C recommendation, W3C, September 2012. http://www.w3.org/TR/r2rml/.
[10] ECMA International. Standard ECMA-262 - ECMAScript
Language Specification. 5.1 edition, June 2011.
[11] Yu Deng Edward Hung and V.S. Subrahmanian. Rdf aggregate queries and views. ICDE’05, 2005.
[12] Lorena Etcheverry and Alejandro A. Vaisman. Views overrdf datasets: A state-of-the-art and open challenges. CoRR,
abs/1211.0224, 2012.
[13] François Goasdoué, Konstantinos Karanasos, Julien Leblay,
and Ioana Manolescu. View selection in semantic web
databases. Proc. VLDB Endow., 5(2):97–108, October
2011.
[14] Steven Harris and Andy Seaborne. SPARQL 1.1 Query
Language. W3C Recommendation, W3C, March 2013.
http://www.w3.org/TR/sparql11-query/.
[15] Wangchao Le, Songyun Duan, Anastasios Kementsietsidis,
Feifei Li, and Min Wang. Rewriting queries on sparql views.
WWW ’11, pages 655–664, New York, NY, USA, 2011.
ACM.
[16] Geetha Manjunath, R Badrinath, Craig Sayers, and Venugopal K. S. Temporal views over rdf data. WWW ’08, pages
1131–1132, New York, NY, USA, 2008. ACM.