DEIM Forum 2013 B2-3

LOD の OLAP 分析を可能にする ETL フレームワークの提案
井上 寛之†

天笠 俊之††,†††

北川 博之††† 筑波大学大学院システム情報工学研究科コンピュータサイエンス専攻 〒 305–8577 茨城県つくば市天王台
1-1-1†† 筑波大学システム情報系情報工学域 〒 305–8573 茨城県つくば市天王台 1–1–1††† 宇宙航空研究開発機構宇宙科学研究所宇宙科学情報解析研究系 〒 252–5210 神奈川県相模原市中央区由野台 3-1-1
E-mail: †inohiro@kde.cs.tsukuba.ac.jp, ††{amagasa,kitagawa}@cs.tsukuba.ac.jp
あらましコンピュータ処理に適した形式によるデータの公開は年々増加しており，その一つの方法として Linked

Open Data (LOD) が挙げられる．LOD には，数値およびテキストが含まれているデータも多く存在し，これらのデー
タに対する既存の OLAP システムを用いた分析処理が強く求められている．本稿では，LOD を OLAP 分析のための多次元モデルに変換する ETL フレームワークを提案する．我々が提案するフレームワークは他の関連する手法と異なり，変換の為の特定の RDF 語彙の利用を必要としない．この代わりに，分析対象とするデータセット内のリソース間の関係，内存する階層構造，および外部のリソースを用いて多次元モデルとその概念階層を導き出す．本手法は OLAP 分
析のための特定の RDF 語彙を用いた LOD のみならず，より多くの一般的な LOD に対する分析処理を可能にするものである．実験として既存のデータセットに対して本手法を適用した例を示し，その有効性について述べる．
キーワード

Linked Open Data, ETL, OLAP

Hiroyuki INOUE† , Toshiyuki AMAGASA††,††† , and Hiroyuki KITAGAWA††† Graduate School of Systems and Information Engineering, University of Tsukuba
1-1-1 Tennodai, Tsukuba, Ibaraki, 305–8577 Japan†† Faculty of Engineering, Information and Systems, University of Tsukuba
1–1–1 Tennodai, Tsukuba, Ibaraki, 305–8573, Japan††† Institute of Space and Astronautical Science, Japan Aerospace Exploration Agency.
3-1-1 Yoshinodai, Chuo-ku, Sagamihara, Kanagawa 252-5210, Japan
E-mail: †inohiro@kde.cs.tsukuba.ac.jp, ††{amagasa,kitagawa}@cs.tsukuba.ac.jp

1. は じ め に
近年，セマンティックウェブから発展した Linked Data [3] とLinked Data は，構造化されたデータの公開方法の一つであり，他の Linked Data として公開されたデータとリンクすることで，「データの Web」を構築し，新たな価値を創りだすのが呼ばれる取り組みが注目されている．そもそもセマンティック狙いである．この取り組みは米国や EU 諸国を先駆けとした

ウェブとは，Web 上のリソース（文書，画像）などに対してメOpen Data（注 1）と呼ばれる取り組みによって，更に加速されていタデータを付与することで，コンピュータがリソースの意味をる．Open Data は，政府や研究機関などがデータを積極的に公理解し，データの取得や分析などに活用する取り組みである．

開することで始まったが，それらのデータを RDF で記述し，相セマンティックウェブにおいてメタデータを記述する枠組みと互にリンクすることで Linked Open Data (LOD) として広まりつ

して，Resource Description Framework（RDF） [4] が規格化さつある．

れている．RDF はリソース自身，及びリソースと他のリソース

LOD として公開されているデータセットの多くは，テキスの関係を記述することができる．RDF において，リソースは

トおよび数値で構成される．[12] は，EU における統計情報を

URI（Uniform Resource Identifirer，統一資源識別子）で一意に識別される．このセマンティックウェブの対象を生データ（RawData）まで拡張した取り組みが，Linked Data である．

（注 1）：Open Definition. http://opendefinition.org/

公開している Eurostat（注 2）のデータを LOD として公開したもの

結果に対する考察を述べる．5. 節で関連研究について説明し，である．また，Linked Sensor Data [14] は，米国における約一

最後に 6. 節でまとめと今後の課題について述べる．

千箇所の気象観測所のメタデータ，およびそれらのセンサで観測された気温，湿度，気圧などの気象観測データをハリケーン2. 前 提 知 識毎にまとめ，LOD として公開されているものである．これら

2. 1 RDF と LODの統計情報や，センサから取得された大量の数値データなどがRDF [4] は，Web 上のリソース自身と，他のリソースとの関LOD として公開され始めている．従って，それらのデータの分係を記述する枠組み（データモデル）である．あるリソースの析が必要とされていると考えられる．

一つのメタデータを，主語（Subject），述語（Predicate），目的

ところで，ビジネスにおける商品の売上など，数値，統計デー

語（Object）を用いて記述する．主語はメタデータを記述する対タの分析には以前から On-Line Analytical Processing（OLAP）

象のリソース，述語は主語に関する情報のプロパティもしくはシステムが広く利用されてきた．OLAP はデータウェアハウス

特徴を定義し，目的語は述語の対象となる値を格納する．これ（DWH）などに大量に蓄積されたデータに対して，統計的な分らは三つ組でトリプルと呼ばれる．主語および述語は Universal

析処理を行う手法の一つであり，分析対象の数値データ（事実）Resource Identifier（URI，統一資源識別子）で，目的語は URIと，それに関連付けられた階層をもつ属性（次元）を利用して，

もしくはリテラルで記述しその値のデータ型を付与することも目的の分析を行う．

可能である．

LOD データセットに OLAP 分析を適用する研究はいくつか

LOD [2] は，構造化されたデータを Web 上で公開，共有する存在する [7, 8, 13]．一つの手法は，LOD データセットを関係表

一つの方法である．またセマンティック・ウェブの領域で，「デーに格納し，既存の OLAP システムによる分析を実現した [13]．

タの Web」を構築する運動そのものを指す．LOD は標準化され他の手法では，LOD データセットの RDF リソース集合に対した技術を基に構築されたデータセットの集合である．データとて，直接 OLAP 的な分析を実現している [7]．両者を比較する

メタデータの記述には RDF や URI を，他のデータとのリンクと，前者のアプローチは既存の OLAP システムが存在しているには HTTP を，データセットに対する問合せには SPARQL [16]点や性能の面から優位であると言える．

などの RDF 問合せ言語を用いて行う．

LOD データセットに対して，データの抽出（Extract），変2. 2 OLAP

換（Transform），OLAP シ ス テ ム へ の ロ ー ド（Load）処 理

OLAP [5, 10] とは，DWH などに大量に蓄積されたデータに（ETL [10]）を適用する場合，いくつかの技術的な問題点が対して多次元分析を行う手法である．分析対象となる数値デー考えられる: １）事実表および次元表を考慮して，分析のためタが格納された事実表と，事実表に関連付けられた階層を持つのスター（もしくはスノーフレーク）スキーマを設計する必要

属性を次元表としてキューブと呼ばれるデータモデルを構成すがある．２）次元表と関連付けられた概念階層を抽出する必要る．このキューブに対して，ロールアップ，ドリルダウン，スがある．また，３）データセットから URL を用いて参照可能

ライシングなどの操作を適用することによって，主に集約分析

な外部リソースをどのように扱うか，である．

を行う．製品の売上げデータなど，場所や時刻といった様々な

これらは容易に解決可能な問題では無い．例えば，Kampgen
ら [13] は，OLAP で用いられるデータキューブを RDF で記述すの属性を持つデータの分析に適しているため，主にビジネスイ
ンテリジェンスの分野で利用されている．

るための RDF 語彙 [9] である RDF Data Cube Vocabulary（QB）

2. 2. 1 ETL[6] を用いて記述された LOD データセットに対して，既存のOLAP 分析のためのデータを DWH に格納するために，一つOLAP システムによる OLAP 分析を可能にした．しかし QB をまたは複数の情報源からデータを抽出（Extract）する必要があ

用いて記述されていない LOD データセットに対してこの手法る．またスターもしくはスノーフレークスキーマを構成するたを適用するのは困難である．

めにデータの変換，加工（Transform）が必要である．最終的に本稿では，我々は LOD データセットに対する一般的な ETL

変換したデータを DWH に読み込む（Load）．これらの一連の処理を提案する．基本的な特徴として，１）QB 等の特定の過程は一般的に ETL（Extract, Transform, and Load） [10] と呼RDF 語彙の利用に関わらず適用可能であり，２）データセッ

ばれている．ETL では OLAP 分析のために幾つかの操作が行トに内存する概念階層，およびリンクする GeoNames [17] やわれる [15]．例えばデータの欠損値の補完やノイズ等の除去なDBpedia [1] 等の外部リソースを利用して，分析に必要な次元どが挙げられる．

を導出する．

本研究で提案するフレームワークは，対象のデータが関係

本稿の構成は以下のとおりである．2. 節では本論文に必要なデータではない点で一般的な ETL 処理と異なる．我々の目的

前提知識について解説する．3. 節では，提案フレームワークでは対象の LOD データセットから OLAP 分析に用いるスタース

ある LOD データセットの OLAP 分析を可能にする ETL フレー

キーマを導出する系統的な方法を提案することである．分析対

ムワークについて説明する．4. 節では，本フレームワークをい

象のスキーマを固定することで，データ展開処理を自動化する．

くつかの既存の LOD データセットに適用した例を挙げ，そのさらに，多次元分析に必要な概念階層をデータセットから導出
する．

（注 2）
：Eurostat. http://ec.europa.eu/eurostat/表 1: Triple Store 形式．

図 1: 提案フレームワーク

3. 提案フレームワーク
本節では提案フレームワークについて説明する．

3. 1 処理の流れ

Subject
SR 1
SR 1
SR 1
SR 1

Predicate
rdf:type
store
category
price

SR 1
Cat 1
Cat 1
Cat 1
Cat 2
Cat 2
Store 1
Store 1
Store 1
Store 1
SR 2
SR 2
SR 2

time
rdf:type
namecategory
rdf:type
name
rdf:type
located atbranchtel
rdf:type
store
price

Store 2
Store 2
Store 2Time 1Time 1

rdf:type
located atbranchrdf:type
inXSDDateTime

図 1 は提案フレームワークにおける処理の流れを示している．

ObjectSalesResult
Store 1Cat 1"150000"ˆˆxsd:integer
Time 1Category
“Mac”
Cat 2
Category“Computer”
Store
gn:7452809“Tsukuba”“029-800-000”
SalesResult
Store 2"4000"
ˆˆxsd:integerStore
gn:2111901“Mito”
Instant"2012-12-01T13:15:00"
ˆˆxsd:dateTime

まずユーザーは分析対象の LOD を指定し，１）フレームワー
クは分析に必要なデータを抽出し（3. 2 節），２）関係データ

係表のスキーマを決定することが出来ない．そこで，rdf:type

ベースに格納する（3. 3 節）．次に，フレームワークはユーザーごとに主語，述語，目的語の組みと目的語のデータ型をタプルに対して分析対象の数値が含まれているレコードの指定を求め，とした Type-partitioned Triple Store（TPTS）アプローチで，一３）指定されたレコードを含む表を事実表としたときの次元表

度すべての RDF トリプルを RDB へ格納する．すべてのリソーを周辺の表から導出する（3. 4 節）．事実表および次元表が揃っスを参照し RDB に格納し終えると，各表の属性を把握するこたところで，４）OLAP 分析に利用するスタースキーマを生成とができるため，rdf:type 毎の関係表を述語表として作りなする（3. 5 節）．また，3. 6 節では，本フレームワークのプロト

おす．

タイプ実装について述べる．

手法の説明に利用する RDF リソース集合を表 1 に示す．この3. 2 RDF データの抽出

例では，製品の売上について考え，一つの売上実績（SalesRe-

フレームワークは，ユーザーにより示された分析対象の数値sult）は売上店舗（Store），売上時刻（Instant），製品カテゴリが含まれる LOD データセットを URI をもとに取得する．この（Category）で記述される．表 1 の RDF リソースを rdf:type

とき，データセットの取得方法としては，おおまかに二つの方毎に分割して格納した結果が表 2 である．TPTS で格納し終え法が考えられる: １）ローカルもしくはリモートに存在するダ

ると，それぞれの rdf:type がどのような述語（属性）を持つ

ンプされたデータセットを用いる，もしくは２）RDF ストア

か把握することができる．具体的には，Predicate 列に対して，の SPARQL エンドポイントを用いてデータを取得する．１に

DISTINCT クエリを実行することで得ることができる．この情

ついては容易に実行することができると考えられるが，２につ報を基にそれぞれのリソースを一行で格納する述語表に格納しいては取得する RDF トリプルの終端条件を設定する必要があ

直す（表 3）．

る．本研究では，主語が分析対象のデータセットと同一ホスト
名の URI で記述される RDF トリプルに限って取得する．

それぞれの表におけるリソースの関係を調べることで，他の表と関係が存在するか判定することができる．このようにし

3. 3 RDF データの格納て用意された表のうち，数値を含む表を事実表の候補とする．

抽出された RDF データは，一つの主語に結びつく述語が関ユーザーによる分析対象の数値（メジャー）の選択を受け，数係表の属性に対応する，述語表（Property Table） [18, 19] アプ

値を含む選択された表を事実表とする．

ローチで関係データベース（RDB）に格納される．述語表を利3. 3. 1 外部キーの濃度推定用する理由として: １）述語表と関係スキーマが直接対応する，

スタースキーマを生成するために，外部キーの濃度（1:1，２）表同士の関係が簡単に把握することができる，等が挙げら

1:N，N:1，もしくは M:N）を保持する必要がある．しかし濃度れる．

は明示的に与えられるものではないため，我々は関係表におけ

述 語 表 は ，あ る リ ソ ー ス に つ い て ，リ ソ ー ス の タ イ プ

るレコード（RDF インスタンス）から濃度の推定を行う．それ（rdf:type（注 3） ）ごとに，リソースの述語を属性とした関係

ぞれの外部キーについて，他の表からの参照を調べることで，表を作成し格納する RDF 格納手法で，ある同一の主語を持つ濃度を推定することができる．この情報もフレームワークの中RDF トリプルを一行で表現する方法である．ただし，データをで保持される（表 3(d))．

辿る段階では，全ての属性を列挙することが出来ないため，関3. 4 次元の導出
OLAP 分析を行うためには，分析の軸に対応する次元表が必（注 3）：http://www.w3.org/1999/02/22-rdf-syntax-ns#type

Algorithm 1 内在する階層構造の利用

表 2: Type-Ppartitioned Triple Store 形式．

procedure ExtractConceptHierarchy(PT, re f ) ▷ PT : property table, re f : foreign key attribute inPTR←∅r ← the root resource where the re f attribute is null.
P ← GetRootToLeafPaths(PT, re f, ∅, r)n ← max path length in P.
Create table T table_name(Subject, layer_1, ..., layer_n)▷ “table name” isretrieved from the rdf:type
Insert each path in P in T .
end procedure
procedure GetRootToLeafPaths(PT, re f, P, r) ▷ PT : property table, re f : foreign key attribute, P:
current paths, r: currentresource URI
if P is empty thenP ← {p/r}▷ / is the separator.
else
for all p ∈ P do
P ← P − {p} + {p/r}▷ / is the separator.
end forend ifR←∅▷ Set of root to leaf paths.
C ← resources where re f is r.
▷ Child nodes.
for all c ∈ C do
R ← R+ GetRootToLeafPaths(PT, re f, P, c)
end for
Return R
end procedure(a) rdf:type: SalesResult
Subject
SR 1
SR 1
SR 1
SR 1
SR 2
SR 2

Predicatestore
category
price
time
store
price

ObjectStore 1Cat 1“150000”
Time 1
Store 2“4000”

DataType
Resource
Resource
Integer
Resource
Resource
Integer(b) rdf:type: Store
Subject
Store 1
Store 1
Store 1
Store 2
Store 2

Predicatelocated atbranchtellocated atbranchObjectgn:7452809“Tsukuba”“029-800-000”
gn:2111901“Mito”

DataType
GeoNames
StringString
GeoNames
String(c) rdf:type: InstantSubject
Time 1

Predicate
inXSDDateTime

Object“2012-12-01T13:15:00”

DataType
DateTime(d) rdf:type: Category
Subject
Cat 1
Cat 1
Cat 2

Predicatenamecategory
name

Object“Mac”
Cat 2“Computer”

DataType
StringResource
String関係は多くの場合，rdfs:subClassOf，rdfs:subPropertyOfなどのリソースの間の参照関係によって記述される為，関係表
表 3: Property Table 形式.

同士の関係がリソース間の関係を表している場合がある．特に，(a) rdf:type: SalesResult
Subject
SR 1
SR 2

store
Store 1
Store 2

category
Cat 1
null

(b) rdf:type: Store
Subject
Store 1
Store 2located at
gn:7452809
gn:2111901

branch“Tsukuba”“Mito”

述語表における同一タイプのインスタンスへの参照は自己参照

price“15000”“4000”

time
Time 1
nullとみなし，そのタイプにおける階層構造を組み立てることが可能である．アルゴリズム 1 は自己参照から概念階層を組み立て(c) rdf:type: Categorytel“029-800-000”
null

Subject
Cat 1
Cat 2

name
“Mac”
“Computer”

category
Cat 2
null

(d) Relationships in each Property Tables.
table
SalesResult
SalesResult
Store
Categorycolumnstore
time
located at
categoryf tableStore
Instant
GeoNames
Categoryf column
Subject
Subject
Subject
Subject

is one2one
false
false
false
false

る例である．また，表 4(b) は自己参照を持つ商品カテゴリの例
を階層構造に分解した例である．

3. 4. 3 外部情報の利用
LOD はその特徴として他の LOD へのリンクを含んでおり，いくつかのよく知られた LOD データセットは多くの LOD から参照される傾向にある．例えば，地理情報の LOD として GeoN-

ames [17]，百科事典の LOD としては DBpedia [1] などが挙げられる．さらに，“Time Ontology” [11]，“Timeline Ontology”（注 4），

要である．また，それぞれの次元は概念階層をもつ．本研究では，RDF および LOD の特徴を活かした次元表を導出する手法
を三つ提案する．

3. 4. 1 リテラル値の利用
このケースでは，事実表における一つの属性は，他の一つ以上の表と 1:1 もしくは N:1 の関係を持ち，それらが直接概念階層を構成している場合である．例としては時刻や位置情報などが挙げられる．時刻は，年，月，日，時，分，秒などの階層構
造を，位置情報は，国，州，街（町）などの階層構造をそれぞれ構成することができる．
ある表の一つの属性として格納されている時刻値を例とす
ると，決められたルールに従って階層構造として属性を組み立て直す．表 4(a) は"2012-12-01T13:15:00"ˆˆxsd:dateTimeと記述された時刻情報を，次元表として利用するために階層構造に分解した例である．

3. 4. 2 内在する階層構造の利用
RDF はそもそも概念体系を記述ことができるため，データセッ
ト自身が概念階層を記述している場合がある．このような階層“WG84 Geo Position Ontology” （注 5）など，時刻や地理情報など
様々な分野でよく用いられるオントロジが存在する．これらのLOD やオントロジはよく知られており，しばしば参照される．
アルゴリズム 1 を使うことでこれらの概念階層を抽出し，次元表として保持することで多次元分析に利用することができる．
表 4(c) は GeoNames におけるつくば市の URI（注 6）から階層構造を抽出した例である．

3. 5 スキーマ生成分析に用いる OLAP システムに用いるスタースキーマを生成する．フレームワークは導出された次元表の候補をユーザーに示し，ユーザーは OLAP 分析に利用する次元表を選択する．
ユーザーの選択を基に OLAP システムで利用するスキーマを出力する．このとき，スキーマをシンプルに保つため，表同士の関係が 1:1 であるものはてーブル同士を結合する．

3. 6 プロトタイプ実装
我々は Ruby 言語を用いて提案フレームワークのプロトタイ（注 4）：The Timeline Ontology http://motools.sourceforge.net/timeline/（注 5）：WG84 Geo Position Ontology. http://www.w3.org/2003/01/geo/（注 6）：http://sws.geonames.org/7452809/about.rdf

表 4: それぞれの次元導出手法を適用した例．
(a) リテラル値の利用．
Subject
Time 1

year
2012

month
12

date
1

hour
13

(b) 内在する階層構造の利用．
min.
15

sec.
0

Subject
Cat 1

layer 1Cat 2(“Computer”)

layer 2
Cat 1(“Mac”)(c) 外部リソースの利用．
Subject
gn:7452809

layer 1
gn:6295630(“地球”)

layer 2
gn:6255147(“アジア”)

layer 3
gn:1861060(“日本”)

layer 4
gn:2112669(“茨城”)

layer 5
gn:7452809(“つくば”)

プを実装した．この実装では，RDBMS と組み合わせて利用す
る OLAP システムとして Mondrian OLAP（注 7）を利用することを想定している．RDBMS に MySQL を利用し，Mondrian 用のス
キーマ定義ファイル（XML 形式）を出力する．この実装をライブラリ化したものを “LDETL” と名付け，オープンソースプロ
ジェクトとして開発している（注 8）．また，“LDETL” は，“Linked

Open Data Challenge Japan 2012” のアプリケーション部門に応(a) 空間放射線量観測データ．

募されている（注 9） ．

4. 適 用 例
提案フレームワークの有効性を確認するために，LOD として公開されている数値・統計データに対してプロトタイプ実装
を用いて，OLAP 分析に利用可能なスキーマの出力が可能か検証を行った．

4. 1 日本における空間放射線量観測データへの適用
日本における都道府県別の環境放射線水準調査（注 10）を試験的に RDF 化しているサービス（注 11）から，RDF を取得した．この
データセットには，2011 年 3 月 16 日から 2012 年 3 月 15 日ま(b) ハリケーン Bill．

での，47 都道府県別の 1 時間ごとの空間放射線量観測結果が含

図 2: 結果として得たスキーマ．

まれている．
データセットは，複数の観測インスタンスとそれを記述する
リテラル値で記述された観測値と観測時刻，リソースとして
観測地がまとめられている．それぞれの観測インスタンスは“Event Ontology”（注 12），観測時刻は “The Timeline Ontology” をそれぞれ用いて記述され，観測地は GeoNames 上のリソースへリンクしている．

4. 1. 1 結サで観測された気象観測データをハリケーン毎にまとめ，LODとして公開されているものである．Linked Sensor Data は観測所メタデータとして，観測所 ID，座標，および GeoNames 上のリソースのうち最も観測所から近いリソースを含んでいる．

Linked Observation Data は観測インスタンス，観測値，観測時
刻，観測の種類（気温，湿度，降雨，など），および観測地と果

図 2(a) は，数値型の属性 value を含む観測インスタンステー
ブルを事実表とした時にプロトタイプが出力したスキーマである．選択された観測時刻と観測地は次元表として関係をもつ．
観測時刻はリテラル値から概念階層として，観測地は外部リ
ソースである GeoNames 上のリソースを取得して概念階層に展開された．

4. 2 Linked Sensor/Observation Data への適用
Linked Sensor/Observation Data [14] と呼ばれる，米国における約一千箇所の気象観測所のメタデータ，およびそれらのセン

して Linked Sensor Data に含まれる観測所インスタンスへのリンクを含んでいる．

Linked Observation Data はハリケーン毎にまとめられている
ため，今回は “Bill” と呼ばれるハリケーンに関する観測データをまとめたデータセットを検証に用いた．このデータセットには 231,023,108 個の RDF トリプルで記述された 21,272,790 回の観測インスタンスが含まれている．

4. 2. 1 結果

図 2(b) は，float 型の属性 floatValue を含む観測インスタン
ステーブルを事実表とし，関係を持つ観測時刻，観測所を次元表とした時のスキーマである．時刻情報はリテラル値から概念（注 7）：Pentaho Mondrian Project. http://mondrian.pentaho.com/（注 8）：LDETL. http://inohiro.github.com/ldetl/（注 9）：LDETL. http://lod.sfc.keio.ac.jp/challenge2012/show_status.

php?id=a044（注 10）：文部科学省 放射線モニタリング情報． http://radioactivity.mext.

go.jp/ja/monitoring_by_prefecture/

階層として，観測地は座標情報と GeoNames 上の外部リソースが概念階層として展開された．

4. 3 他のデータセットへの適用
生物情報学の分野で，マウスの遺伝子情報 （注 13）や，シロイ（注 11）：National Radioactivity Stat as Linked Data. http://www.kanzaki.com/

works/2011/stat/ra/（注 13）：Mouse MGI Gene. http://biolod.org/database/rib185i/Mouse_（注 12）：The Event Ontology. http://motools.sourceforge.net/event/

MGI_Geneヌナズナの遺伝子情報 （注 14）に対して本手法の適用を実験的に行った．

5. 関 連 研 究
RDF や LOD を OLAP により分析しようとする試みはこれまでにいくつか行なわれている. 手法は大きく分けて二つの方向性で分類できる．一つは，RDF データセットを関係データベースに格納し，ROLAP（Relational-OLAP）と呼ばれるタイプのOLAP システムを使うことで実現する手法，もう一方は RDF
データセットに対して RDF 問合せ言語である SPARQL を使って，OLAP 的な操作を適用する手法である．それぞれ代表的な研究を挙げる．
まず，Linked Data として公開されたデータセットを関係デー
タベースに格納する手法として，Kampgen ら [13] の手法がある．彼らは，RDF で統計データを記述するための RDF 語彙
である，RDF Data Cube Vocabulary（QB） [6] を利用している

Linked Data に対して，関係モデルとのマッピングルールを定義
し，関係データベースへ格納することで一般的な OLAP システ
ムによる分析の実現可能性を示した．
関係データベースに格納を行わない手法としては，Etcheverryら [7] の手法が挙げられる．彼らはまず，RDF データモデルに対する OLAP 処理を定義し，その処理が適用可能な RDF データ
セットを作るための RDF 語彙である Open Cube Vocabulary を定義した．この語彙に準拠したデータセットに対して，SPARQL
による OLAP 的な多次元分析処理の一部を実現した．また，分析処理を行う SPARQL クエリを生成するアルゴリズムを示した．さらに，彼らは QB4OLAP と呼ばれる RDF 語彙を提案した [8]．QB4OLAP は QB に OLAP モデルと操作を拡張した

RDF 語彙で，既に QB に基づいて公開されている RDF データ
を QB4OLAP に準拠させることで，SPARQL を用いた OLAP
的な分析処理を可能にした．
これらに対して本研究では，前者の RDF データセットを関係データベースへ格納するアプローチを取り，OLAP 分析向けの特別な RDF 語彙の利用に関係なく，LOD として公開された任意の数値，統計データを対象に，既存の OLAP システムによる分析処理を可能にする一般的な変換手法について議論している点が異なる．

6. まとめと今後の課題
本稿では，LOD として公開されている数値，統計データに対して既存の OLAP システムを用いた多次元分析を可能にする一連の変換手法を ETL フレームワークとして提案した．本手法はこれまでの先行研究と異なり，RDF や LOD の特徴を利用することで，OLAP データモデル用の特定の RDF 語彙を必要とせず，より幅広い分野の LOD に対して適用可能であると言える．また，提案フレームワークのプロトタイプ実装に LOD として公開されているデータセットを適用し，OLAP 分析に必要なスキーマの生成に成功することを示した．

（注 14）：TAIR10 Locus. http://biolod.org/class/crib102u0i/TAIR10_Locus

今後の課題として，１）rdf:type が記述されていない，もしくは複数記述されているリソース，２）LOD データセットが更新された場合に DWH 側へ更新を反映する仕組みなどについて検討する必要がある．

謝

辞本研究の一部は，科学研究費補助金・若手研究 B(23700102)
による．
文

献

[1] Sören Auer, Christian Bizer, Georgi Kobilarov, Jens Lehmann,
Richard Cyganiak, and Zachary G. Ives. DBpedia: A Nucleus fora Web of Open Data. In ISWC/ASWC, volume 4825 of Lecture Notes
in Computer Science, pages 722–735. Springer, 2007.
[2] Tim Berners-Lee. Linked Data - Design Issues. http://www.w3.
org/DesignIssues/LinkedData.html.
[3] Christian Bizer, Tom Heath, and Tim Berners-Lee. Linked data - thestory so far. Int. J. Semantic Web Inf. Syst., 5(3):1–22, 2009.
[4] 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/.
[5] E.F. Codd, S.B. Codd, C.T. Salley, and Inc Codd & Date. Providing OLAP (On-line Analytical Processing) to User-analysts: An IT
Mandate. Codd amp; Associates, 1993.
[6] Richard Cyganiak and Dave Reynolds. The RDF Data Cube Vocabulary. W3C working draft, W3C, April 2012. http://www.w3.org/
TR/vocab-data-cube/.
[7] Lorena Etcheverry and Alejandro A. Vaisman. Enhancing OLAP
Analysis with Web Cubes. In ESWC, volume 7295 of Lecture Notes
in Computer Science, pages 469–483. Springer, 2012.
[8] Lorena Etcheverry and Alejandro A. Vaisman. QB4OLAP: A Vocabulary for OLAP Cubes on the Semantic Web. In COLD, volume 905
of CEUR Workshop Proceedings. CEUR-WS.org, 2012.
[9] Ramanathan V. Guha and Dan Brickley. RDF Vocabulary Description Language 1.0: RDF Schema.
W3C recommendation, W3C, February 2004.
http://www.w3.org/TR/2004/
REC-rdf-schema-20040210/.
[10] Jiawei Han and Micheline Kamber. Data Warehouse and OLAP
Technology: An Overview. In Data Mining: Concepts and Techniques, pages 105–156. Morgan Kaufmann, second edition, 2006.
[11] Jerry R. Hobbs and Feng Pan. Time Ontology in OWL. W3C
working draft, W3C, September 2006. http://www.w3.org/TR/
owl-time/.
[12] Aftab Iqbal, Sarven Capadisli, Richard Cyganiak, and Michael
Hausenblas.
Eurostat - Linked Data.
http://eurostat.
linked-statistics.org/.
[13] Benedikt Kämpgen and Andreas Harth. Transforming statisticallinked data for use in OLAP systems. In I-SEMANTICS, ACM International Conference Proceeding Series, pages 33–40. ACM, 2011.
[14] Harshal Patni, Cory A. Henson, and Amit P. Sheth. Linked Sensor
Data. In CTS, pages 362–370, 2010.
[15] Erhard Rahm and Hong Hai Do. Data Cleaning: Problems and Current Approaches. IEEE Data Eng. Bull., 23(4):3–13, 2000.
[16] Andy Seaborne and Steve Harris. SPARQL 1.1 Query Language.
W3C working draft, W3C, October 2009. http://www.w3.org/
TR/2009/WD-sparql11-query-20091022/.
[17] Bernard Vatant and Marc Wick. GeoNames Ontology. http://www.geonames.org/ontology/.
[18] Kevin Wilkinson, Craig Sayers, Harumi A. Kuno, and Dave
Reynolds. Eﬃcient RDF Storage and Retrieval in Jena2. In SWDB,
pages 131–150, 2003.
[19] Kevin Wilkinson and Kevin Wilkinson. Jena Property Table Implementation. In In SSWS, 2006.