人工知能学会研究会資料
SIG-SWO-A1103-01

コレクション型ウェブサイトから Linked Data を構築するプラットフォームの開発
Platform for creating Linked Data from web sites
including collections
加藤 文彦 1∗ 嘉村哲郎 3,4Fumihiro Kato,1 Tetsuro Kamura,3,4
1
1

大向一輝 2,4 武田英明 2,4
Ikki Ohmukai,2,4 Hideaki Takeda2,4

情報・システム研究機構 新領域融合研究センター
Research Organization of Information and Systems
2
国立情報学研究所
2
National Institute of Informatics
3
総合研究大学院大学
3
The Graduate University for Advanced Studies
4
東京藝術大学4
Tokyo University of the Arts

Abstract: LODAC Distiller is a platform to transform HTML files of web sites into RDF files
to be able to provide Linked Data. LODAC Distiller extracts pairs of a key and a value such as acollection’s title or an author’s name from HTML files, then it maps the pairs to appropriate RDF
properties and objects by using original mapping rules. LODAC Museum uses LODAC Distiller
for generating museum collection datasets from various museum web sites.

1

はじめにウェブ上で様々な情報源のデータを型付リンクによって結びつける，Linked Data [1, 2] というコミュニティ活動が注目されている．Linked Data は DBpedia [3]と呼ばれる Wikipedia から変換した情報を中心として，地理情報，政府情報，学術情報，音楽情報，写真情報など，2011 年 9 月の時点で 295 のデータセットによるネットワークが形成されている．セマンティックウェブが普及しない原因の一つとして基盤となるデータの欠如があったが，Linked Data はその問題を解決する有望な手段の一つであると考えられている．
しかしながら，現在広く利用されているウェブサイ
トの大半は Linked Data として扱えない現状がある．
そのため，ウェブサイト上にあるデータをどのようにLinked Data として取り扱えるようにするかを検討する必要がある．最初のきっかけとなった DBpedia 自体∗ 連絡先：国立情報学研究所〒 101-8430 東京都千代田区一ツ橋 2-1-2
E-mail: fumi@nii.ac.jp

も Wikipedia というウェブサイトからデータを抽出して Linked Data にしたものである．しかし，ウェブサ
イト毎に独自の変換プログラムを書いて Linked Dataを作成するのではスケールしないので，汎用的な方法が必要である．
そこで博物館の収蔵品データベースやメーカーの商品カタログのように，ある ‘モノ’ に対する説明がキーとバリューの対として記述されているウェブサイトに注目することにした．本稿では，この類のウェブサイトをコレクション型ウェブサイトと呼ぶことにする．コレクション型ウェブサイトで扱っているデータは，‘モノ’-キー-バリューで表現できるため，主語-述語-目的語の 3 つ組で表現する RDF モデルに適用することが，他のウェブサイトを対象とするよりも容易であると考えられる．
著者らは上記の考えを基に，コレクション型ウェブサイトから Linked Data を作成するためのシステム
LODAC Distiller を構築している．本稿では LODAC
Distiller の概要について説明を行う．現在 LODAC Dis-tiller は，主に LODAC Museum [4] で博物館の収蔵品データ作成のために使用している．
Crawl
Web sites

関連研究

2

ScrapeOutputSolr

HTML ﬁles

JSON ﬁles

git

git

RDFizegit

ウェブ上のデータを Linked Data として扱えるようにするためのツールやシステムは多数存在する．CSV,Excel といったデータを RDF に変換することを目的としているツールから，Linked Data として公開を視野にいれているツールなど様々である．
CSV や Excel のようなデータを変換するツールはRDF Extension for Google Refine 1 や irON 2 などがある．これらについての調査は以前 [5] にて行ったので参照されたい．
データ格納用のソフトウェアが変換ツールを提供している場合もある．例えば Virtuoso Universal Server 3 は最も人気のある RDF Store の一つだが，一部のウェブサイトを RDF に変換して Virtuoso に取り込む XSLT群を Virtuoso Sponger [6] として提供している．
その他に，ウェブ上で公開されている RDF データを統合するためのフレームワーク例としては，LDIF(Linked Data Integration Framework) [7] がある．LDIFは Linked Data となっているサイトや RDFa が埋め込まれているウェブサイトのように，元々RDF を提供し 1ているウェブサイトのみを対象としている．それらか 23
ら集めてきたデータを共通のボキャブラリにマッピン 45グしたり，同定作業をしてデータ統合を自動化するこ 678とを主な目的としている．
910113

LODAC Distiller

本節では，コレクション型ウェブサイトから Linked
Data を作成するためのシステムである LODAC Distiller について述べる．

3.1

処理の流れ

コレクション型ウェブサイトから Linked Data を作成するまでの一連の流れを図 1 に示す．
ウェブサイトからの HTML 収集と HTML からのキー・バリューの抽出には，現在 Apache Nutch 4 とRuby を併用している．抽出されたキー・バリューはApache Solr 5 に ‘モノ’ 単位で保存されるようになっている．Nutch は Solr との相性が良いため，段階的に1 http://lab.linkeddata.deri.ie/2010/grefine-rdf-extension/
2 http://openstructs.org/iron
3 http://virtuoso.openlinksw.com
4 http://nutch.apache.org/
5 http://lucene.apache.org/solr/

121314

ImportGit Repository

RDFStore

RDF ﬁles

図 1: 処理の流れ

Ruby から Nutch に移行している．Solr に保存されているデータには，ウェブサイトから取得されたデータ以外に対象ウェブサイトの情報や取得時刻，サイト内での ‘モノ’ の ID など，直接抽出したキー・バリューデータ以外のデータも含んでいる．
Solr に蓄積されているデータは単純な JSON 形式で出力されるようになっている．出力される JSON の例をソースコード 1 に示す．Solr 上のデータを API 経由で直接扱うことも可能であるが，3.2 節で述べる通り，データから RDF へのマッピング作業を Solr から切り離して行う必要があった．
{" institution " : " akita_museum " ," segment " : " 201105 121424 50 " ," digest " : " 30 d 5 a a f 4 3 9 6 4 c 6 4 3 1 5 f 8 3 2 f 6 1 7 a 2 e 2 d 1 " ," tstamp " : " 2 0 1 1 0 5 1 2 0 5 2 5 0 0 6 6 0 " ," 作品名 " : " 秋田萬古緑釉蓮湯ざまし " ," anchor " : " 0. html " ," title " : " 秋田市立千秋美術館‐収蔵品検索 " ," i ns ti t ut io n al I d " : " 0 " ," 寄贈・購入年 " : " 昭 63 年 度 寄 贈 " ," 作者名と生没年 " : " 鈴木緑園
1856( 安 政 0 3 ) - 1 9 1 0 ( 明 治 4 3 ) " ," 作者名（かな） " : " すずき りょくえん " ," imgURL " : " http: // www . city . akita . akita . jp / city /ed / ss / senshu - art / data / jpeg /1465. jpg " ,.......

ソースコード 1: 抽出データ例
出力された JSON に含まれているキー・バリューのデータから必要な項目を RDF の 3 つ組に対応付けるために，独自のマッピングルールを定義している．マッピ
ングルールは対象のウェブサイト毎に記述する．RDF 変換プロセッサにマッピングルールを渡すことで，JSONファイルから RDF ファイルへと変換を行う．マッピン
グルールについては 3.3 節で解説する．
最後に，上記の手順で生成された RDF ファイルをRDF Store に格納する．これにより，RDF Store が提供する SPARQL Endpoint を通して，生成されたデータを扱えるようになる．LODAC Museum では RDFStore として OWLIM6 を用いており，Linked Data の提供は内部で OWLIM に SPARQL で問い合わせることで実現している．
6 http://www.ontotext.com/owlim

3.2

データ抽出と RDF マッピングの分離

Virtuoso Sponger のように HTML から直接 RDF へ
1
マッピングする方法とは異なり，LODAC Distiller で 2
は HTML からのキー・バリュー抽出と RDF へのマッ 34
ピングのプロセスを分けて，独立して行えるようにし 5ている．理由は，各々の準備作業を異なる人が行うこ 678とを想定しているためである．
9HTML からのデータ抽出の準備は，HTML からキー・1011バリューとなるようなデータを探しだして，その場所 1213に対応する xpath を nutch の設定に書くという手順に 14なる．この作業はウェブ開発者が行うことを想定して 1516おり，キーやバリューに含まれている言葉や文章自体 1718に深い知識を必要としない．また将来的には機械処理 192021でデータ抽出を行うことも視野にいれている
22
一方，抽出したキー・バリューのペアから RDF への 23
24
マッピングについては，単語や文章がそのドメインの 25
26
専門家にしか正確な意味がわからないような，難しい 27
ものの場合がある．更にそれがキーである場合，対応 28
29
する RDF 述語が何であるかの判断もしなければなら 30
31
ないが，それは専門家のほうが正しく行えると考えら 32
33
れる．そのため，対象のドメインを良く知る専門家が 34
35
マッピング作業だけを担当できるようにすべきである．36
37
データ抽出と RDF へのマッピングを同時に行うには 38
39
ウェブ開発と専門領域双方に精通している必要があり，実際に作業を行える人が限られていた．しかしこの処理を分離した結果，LODAC Museum においてはキー・バリュー抽出をウェブ開発者，RDF へのマッピングを博物館メタデータの専門家にまかせることで，並行して作業を進めることができるようになった．

3.3

RDF マッピングルール

1234キー・バリュー形式で格納されているデータを RDF 56に変換するために，独自のマッピングルールを定義し 78ている．秋田市立千秋美術館の収蔵品データに対する
9マッピングルール例をソースコード 2 に示す．
10マッピングルールは，JSON 形式で RDF 述語とキー 1112の対応関係を記述する．それにより，JSON に含まれ 1314ているキー・バリューのペアを RDF 述語と目的語の関15係に変換する．複数のキーを単一のプロパティに対応 1617付けることも可能である．また，正規表現によってバ 18リューの一部分だけを目的語として割り当てることも可能となっている．
RDF で用いる主語の URI は，マッピングルールのプロセッサが，元データに含まれているユニークな IDと対象ウェブサイト名の組み合わせで自動的に生成される．これにより，元データの ID が変わらない限りはURI の一意性を保証することができる．もし元データの ID が全部入れ替わるということが発生した場合は現在は対応できず，新規の URI を発行することになる．
{" meta " : {" i n s t i t u t i o n a l U R I " : " http: // lod . ac / id /3193 " ," i n s t i t u t i o n a l N a m e " : " 秋田市立千秋美術館 " ," dc:source " : " http: // www . city . akita . akita . jp /city / ed / ss / senshu - art / " ," dc:rights " : " 秋田市立千秋美術館 "}," rules " : {" dc:title " : [{" name " : " 作品名 " ," lang " : " ja "}]," sk os:pr efLabe l " : [{" name " : " 作品名 " ," lang " : " ja "}]," rdfs:label " : [{" name " : " 作品名 " ," lang " : " ja "}]," dc:created " : [{" name " : " 制作年 " ," regexp " : " (\\ d +)\\( "}]," dc:medium " : [{" name " : " 材質・技法 " ," lang " : " ja "}],......

ソースコード 2: マッピングルール例
以上の手順で，Solr から出力された JSON ファイルから主語-述語-目的語の 3 つ組の関係を作成し，それを RDF として保存する．RDF の例をソースコード 3に示す．
< http: // lod . ac / ref /811510 >r d a 2 : d a t e O f B i r t h " 1856 " ;r d a 2 : d a t e O f D e a t h " 1910 " ;c r m : P 1 0 0 I _ d i e d _ i n " 1910 " ;c r m : P 3 2 _ u s e d _ g e n e r a l _ t e c h n i q u e " 陶器 " @ja ;c r m : P 4 5 _ c o n s i s t s _ o f " 陶器 " @ja ;c r m : P 9 8 I _ w a s _ b o r n " 1856 " ;dc11:creator " すずきりょくえん " @ja - hrkt , " 鈴木緑園
" @ja ;
dc: d at eA c ce p te d " 昭 63 年 度 寄 贈 " @ja ;dc:extent " 高 4.0 長 径 1 1 . 0 短 径 7 . 0 " ;d c : i s R e f e r e n c e d B y < http: // lod . ac / id /811510 > ;dc:medium " 陶器 " @ja ;dc:rights " 秋田市立千秋美術館 " ;dc:source < http: // www . city . akita . akita . jp / city /ed / ss / senshu - art / > ;dc:title " 秋田萬古緑釉蓮湯ざまし " @ja ;rdfs:label " 秋田萬古緑釉蓮湯ざまし " @ja ;sko s:pre fLabel " 秋田萬古緑釉蓮湯ざまし " @ja ;foa f:dep iction < http: // www . city . akita . akita . jp /city / ed / ss / senshu - art / data / jpeg /1465. jpg > .

ソースコード 3: RDF の例

3.4

データの履歴各段階で取得・生成されているファイルは git レポジ
トリでバージョン管理を行なっている．具体的にはウェ

ブサイトからクロールしてきた HTML ファイル，Solrから出力された JSON ファイル，マッピングルールを通して生成された RDF ファイルがそれに該当する．これによって，変換前のページや変換後の RDF ファイルの変遷が記録されるようになっている．突然ページのフォーマットが変更になってデータがうまく抽出できなくなったりすることがよくあるため，原因を追求するためにも過去の履歴を持っておくほうが都合が良い．
一方，RDF でデータの履歴を記述しておくという考え方もある．例えばある ‘モノ’ について 1 年前のデータと半年前のデータを取得して比較したいという要求がある．しかし，RDF でデータ自体の時系列を表現しようとすると煩雑になってしまう場合が多いため，現在は採用していない．将来的には git の履歴データをRDF として出力することができれば良いかもしれない．

4

今後の課題

現在のデータ抽出やマッピングルールなどは，各ウェブサイトがデータの管理者であるという前提で行なっている．しかし，SAGA デジタルミュージアムのように複数組織からデータを収集して統合データベースとして提供しているサイトにはまだ完全には処理できないため，対応したい．

5

おわりに

本稿では博物館の収蔵品データベースや家電メーカーの商品カタログサイトのような，キー・バリューの対で表現できるウェブサイトから RDF を生成して，SPARQLEndpoint として公開できるようにしている LODAC
Distiller システムについて紹介した．現在は博物館の収蔵品データに対してのみ適用しているが，他のコレクション型ウェブサイトにも適用することで，その有用性を確かめていく予定である．

今後の課題は以下の通りである．

• 処理手順の見直し• 同定作業謝辞
本システムの開発にご協力頂いた株式会社アットウェ
アに感謝する．

• マッピングルール用 UI• 統合データベースへの対応
現在の処理手順では Solr に取り込んだキー・バリューの対を JSON の形で一旦出力してからルールを適用して RDF を生成している．これはルールを作成するユー
ザがデータをシステムから切り離して，まとめて見ながらルール作成を行えるという点で有効であった．しかし，このプロセスは Solr の API を使って直接 Solrのデータを使うようにすれば，本来は必要がないはずである．そのため，この部分を省略して Solr から直接ルールを通して RDF を出力できるようにしたいと考えている．また，もう少し進めて RDF の出力と同時にRDF Store に UPDATE を発行して差分更新するようにもしたいと考えている．
同定作業については LODAC Distiller の中に組み込
まれておらず，RDF Store に追加された後に独立した作業として行われている．しかし，マッピングルールを通して RDF を生成する際に著者の名寄せを行うな
ど，いくつかの同定作業は LODAC Distiller の中に組み込んで，半自動的に処理が行えるほうが望ましい．
マッピングルールは現在手作業で作成をしているが，専門家の方々に行なってもらうことを考えると不十分であり，マッピングルールを簡単に生成できる UI を用意すべきである．

参考文献[1] Berners-Lee, T.: Design Issues: Linked Data,
http://www.w3.org/DesignIssues/LinkedData.
html, (2006)[2] Linked Data - Connect Distributed Data across theWeb, http://linkeddata.org/[3] Auer, S., Bizer, C., Lehmann, J., Kobilarov, G., Cyganiak, R., Ives, Z.: DBpedia: A Nucleus for a Webof Open Data, In Proceedings of the 6th International
Semantic Web Conference, 2nd Asian Semantic Web
Conference, (2007)[4] Kamura, T., Takeda, H., Ohmukai, I., Kato, F.,
Takahashi, T., and Ueda, H.: Study Support andIntegration of Cultural Information Resources withLinked Data, In Proceedings of the 2nd International
Conference on Culture and Computing, pp. 177–178(2011)[5] 加藤文彦: Linked Data 作成支援ツールの現状と課題,
第 24 回セマンティックウェブとオントロジー研究会, 人
工知能学会, (2011)[6] OpenLink
Software:
VirtuosoSponger,
http://virtuoso.openlinksw.com/dataspace/
dav/wiki/Main/VirtSponger[7] Schultz, A., Matteini, A., Isele, R., Bizer C., Becker,C.: LDIF - Linked Data Integration Framework, 2ndInternational Workshop on Consuming Linked Data,(2011)