国立国会図書館東日本大震災アーカイブ（ひなぎく）の

メタデータ設計の経験から

サービスの利活用と運用と メタデータ

白石 啓 （しらいし けい） ke-shira@nii.ac.jp

@ke_shira

本日お話しする内容

1. 「ひなぎく」とは？

2. 「ひなぎく」におけるメタデータ設計 1) 前提条件

2) 設計の基本的な考え方

3) メタデータスキーマ

4) 場所の情報

5) 日時の情報

6) 主題の情報

7) メタデータ付与の難しさ

8) メタデータ連携

3. まとめに代えて

2 2013-08-23 TP&Dフォーラム2013 白石 啓

2006年4月 国立国会図書館（NDL）に入館

2006年4月〜 2008年3月

マンガ、実用書などの目録作成→和図書の分類、件名の付与を担当

2008年4月〜 2010年3月

Dublin Coreの年次会議（DC2008）へ出席（2008年9月） 国立国会図書館ダブリンコアメタデータ記述（DC-NDL）の改訂NDLサーチ（開発版）のメタデータスキーマ設計 Web NDL Authoritiesの企画

2010年4月〜2011年9月

館のPMO、情報セキュリティの事務 総務省メタデータ情報基盤構築事業への協力

2011年10月〜2013年3月

国立国会図書館東日本大震災アーカイブ「ひなぎく」開発 メタデータ設計、外部機関との調整・マッピング仕様策定などを担当

2013年4月〜 国立情報学研究所（NII）へ出向。CiNiiの中の人に

自己紹介

3 2013-08-23 TP&Dフォーラム2013 白石 啓

2006年4月 国立国会図書館（NDL）に入館

2006年4月〜 2008年3月

マンガ、実用書などの目録作成→和図書の分類、件名の付与を担当

2008年4月〜 2010年3月

Dublin Coreの年次会議（DC2008）へ出席（2008年9月） 国立国会図書館ダブリンコアメタデータ記述（DC-NDL）の改訂NDLサーチ（開発版）のメタデータスキーマ設計 Web NDL Authoritiesの企画

2010年4月〜2011年9月

館のPMO、情報セキュリティの事務 総務省メタデータ情報基盤構築事業への協力

2011年10月〜2013年3月

国立国会図書館東日本大震災アーカイブ「ひなぎく」開発 メタデータ設計、外部機関との調整・マッピング仕様策定などを担当

2013年4月〜 国立情報学研究所（NII）へ出向。CiNiiの中の人に

自己紹介

4

ふと気づけば 「メタデータの人」に…

2013-08-23 TP&Dフォーラム2013 白石 啓

自己紹介：課外活動

※参考：歴代のNDLからの委員長

5

2009年4月〜 『情報の科学と技術』編集委員

2012年4月〜 『情報の科学と技術』編集委員長を拝命

2013-08-23 TP&Dフォーラム2013 白石 啓

• 故田屋裕之元副館長

• 山地康志さん（関西館）

• 白石 啓

発表の前に

• この発表は、前所属のNDLおよび現所属のNIIの公式見解ではなく、一個人としての発表です。

• 「ひなぎく」にメタデータをご提供いただいている連携機関の方々、また「ひなぎく」の構築に向けさまざまな知恵やアイデアをご提供してくださった被災地の方々および関係の方々に対し改めて御礼を申し上げると共に、被災地の一日も早い復興と発展をお祈り申し上げます。

6 2013-08-23 TP&Dフォーラム2013 白石 啓

1. 「ひなぎく」とは？

7 2013-08-23 TP&Dフォーラム2013 白石 啓

「ひなぎく」とは？

• 東日本大震災およびその他震災に関する情報を一元的に検索・活用するためのポータルサイト • 福島第一原発事故に関する資料／過去の震災（例：阪神・淡路大震災）に関する資料も対象

• 国の復興に関する方針に基づき、総務省と国立国会図書館が連携して構築 • 「国の復興構想７原則（平成２３年５月１０日 東日本大震災復興構想会議決定）」

• 「東日本大震災からの復興の基本方針（東日本大震災復興対策本部 2011年7月策定、8月改定）」

• 2013年3月7日に正式公開

• 2013年4月以降、NDLでサービスを運用

8 2013-08-23 TP&Dフォーラム2013 白石 啓

9 2013-08-23 TP&Dフォーラム2013 白石 啓

「ひなぎく」とは？

• さまざまな機関が構築する震災関連アーカイブを統合的に検索 • 震災関連アーカイブというくくりで横串をさすことで、震災関連資料の所在を一元的に把握

• 乱立する震災関連アーカイブという課題の解決

• 動画、写真等のボーンデジタル情報と従来の紙資料等を豊富に収録 • 東日本大震災関連：約20万点

• その他震災・原子力関連を含むと200万点以上

• 地図上からの検索、タイムラインからの検索

• コンテンツそのものがWeb上で一般公開されている場合には、コンテンツの閲覧までナビゲート

10 2013-08-23 TP&Dフォーラム2013 白石 啓

2. 「ひなぎく」における メタデータ設計

11 2013-08-23 TP&Dフォーラム2013 白石 啓

前提条件：開発の流れと制約

• そもそもどんなメタデータが来るかわからない・・・

• 既存のシステム資産を流用して開発 • メタデータスキーマを大幅には変えられない

• ※開発の流れ

1. メタデータスキーマの定義を確定

2. 連携先のメタデータを、「ひなぎく」メタデータスキーマのマッピング

3. マッピング仕様に基づき、メタデータ変換・投入・表示機能を開発

4. メタデータ実データ投入し、テスト

12 2013-08-23

開発のかなり初期の段階で、 推測しながらメタデータスキーマを ほぼ完璧に決めなければならない

TP&Dフォーラム2013 白石 啓

前提条件：当時わかっていたこと

• 撮影日や、撮影場所（緯度経度情報）が付与され、ナビゲーションにおいても重要な役割を果たしうるだろう • GoogleやYahoo!による震災関連アーカイブの事例

• 日時と場所の情報が重要であるとの関係者からの指摘

• 被災地で構築中の震災関連アーカイブから、「NDLが実装するメタデータスキーマを参考にしたい」との声

13 2013-08-23 TP&Dフォーラム2013 白石 啓

「ひなぎく」のみならず 「被災地の震災関連アーカイブ」における メタデータ付与、ナビゲーションまでを

視野にいれつつ設計する必要

設計の基本的な考え方

• どこの機関・アーカイブが、どのコンテンツを所持しているか確実に示す • ポータルとしての役割を確実に果たす

• 「場所」や「日付」等の事実情報からコンテンツを絞り込めるようにする • まずは「場所」、「日付」といった事実情報から適切に絞り込みを行えるようにすることを重視

• 事実情報であれば、ある程度統制的に扱えるだろうとの仮説

• DC-NDLをベースとし、必要な拡張を行う • どんなメタデータが来るか不明であったため、まずは既存をベースに

• 拡張の際は、標準（国際標準／デファクト）のメタデータ語彙を採用

• Linked Open Dataによる流通を見据え、RDFでデータ提供

14 2013-08-23 TP&Dフォーラム2013 白石 啓

メタデータスキーマ：メタデータモデル

15 2013-08-23

ndlkn:Repository http://kn.ndl.go.jp/re

pository/**

ndlkn:Resource http://kn.ndl.go.jp/**

*#entity

ndlkn:MetaResource

http://kn.ndl.go.jp/***

ndlkn:isMemberOf

foaf:isPrimaryTopicOf

http://example.co.jp/***#entit

y

owl:sameAs

http://example.co.jp/

http://example.co.jp/***.jpg

http://example.co.jp/***

dcat:accessURL

rdfs:seeAlso

dc:source

dc:source

foaf:page

dc:source

http://example.co.jp/view/***

TP&Dフォーラム2013 白石 啓

メタデータスキーマ：メタデータモデル

16 2013-08-23

「ひなぎく」 提供元識別URI

「ひなぎく」 コンテンツ実体

URI

「ひなぎく」 メタデータURI

ndlkn:isMemberOf

foaf:isPrimaryTopicOf

提供元 アーカイブの コンテンツ実体

owl:sameAs

提供元 アーカイブの トップページ

提供元 アーカイブの コンテンツファ

イル

提供元 アーカイブの メタ詳細画面

dcat:accessURL

rdfs:seeAlso

dc:source

dc:source

foaf:page

dc:source

提供元 アーカイブの 閲覧画面

TP&Dフォーラム2013 白石 啓

メタデータスキーマ：メタデータモデル

• 三つのクラスを設定 • Repository／Resource／MetaResource

• DC-NDL、既存語彙で採用できそうなクラスが無かったため、やむなく独自定義

• FRBR、EDM（Europeana Data Model）等は複雑すぎたため採用見送り

• コンテンツの実体の考え方 • 実体≠コンテンツファイル（ファイルフォーマットは変化しうる）

• ボーンデジタルにもPhysical Objectにも#entityを採用

• Resourceから、提供元アーカイブへの主要なナビゲーションを整理・確保 • GUIでのナビゲーション／APIでの活用を考慮

• dc:sourceを用いる（便利すぎるdcterms:source）

17 2013-08-23 TP&Dフォーラム2013 白石 啓

メタデータスキーマ：課題

• メタデータ語彙の定義をどこまで厳密に守るのか • DomainやRangeといった定義を厳密に守りすぎると、結局多くを独自に定義せざるを得なくなる

• 一部、定義を拡大解釈して採用 • RDF Vcard

• 主に名刺等に用いる語彙

• 「ひなぎく」ではコンテンツをRDFの主語とし、の撮影場所の住所情報、コンテンツが対象とする場所の住所情報の表現に採用

• Ontology for Media Resources 1.0

• MediaResource（マルチメディアな情報）の記述に用いる語彙

• 写真など、それ以外のコンテンツの表現にも使っている

18 2013-08-23 TP&Dフォーラム2013 白石 啓

メタデータスキーマ：課題

• メタデータスキーマ改変の困難さ • 後工程すべてに響く（改修コストが高くなる）

• 何かをかえると、インデキシング全件やり直し

• 柔軟にメタデータ項目を追加できるような仕組み、運用が今後重要

• デジタル情報とアナログ情報が混在する場合に有効なコンテンツのデータモデルの指針が無い • メタデータ／コンテンツ／データの由来情報／Physical Objectとデジタル情報／権利情報等をどう整理し、モデリングしていくか

• 「ひなぎく」では整理しきれなかった⇒Bibframeへ期待

• 例：権利情報、技術メタデータ

• 言語の問題 • コンテンツは日本語なのにメタデータが英語の場合の問題

19 2013-08-23 TP&Dフォーラム2013 白石 啓

メタデータマッピング：基本的な考え方

• 提供元のメタデータを欠落させない • 提供元のアーカイブが閉鎖された場合に、情報が無くならないように

• 「ひなぎく」メタデータスキーマに対応する項目が無い場合 • 値がURI：dcterms:relationにdcterms:description付きで格納

• 値が文字列：dcterms:descriptionに「導入語句 : ●●」の形式で格納

• メタデータ項目の利用用途に応じたレベル分け • レベル1：詳細検索／ファセット（絞り込み）に採用する項目

• 値の形式を統一（正規化）する必要がある

• レベル2：画面に表示できれば良い項目

• 値の形式はそこまで気にしなくて良い

• 被災地のアーカイブとは、協議のうえ中間フォーマットを定義

20 2013-08-23 TP&Dフォーラム2013 白石 啓

メタデータマッピング：課題

• マッピング仕様の提示の方法 • Excelによる管理の煩雑さ

• ケアレスミスがそのまま実装…

• 大文字・小文字

• スペルミス

• 版管理の難しさ

• 業者さんと職員双方でマッピング仕様を更新

• ノウハウの継承 • 担当者を特定の個人に絞った方が一貫性は保てる

• しかし、過大な負担

• ナビゲーション設計／API設計を一手に引き受けることに

• サービスを理解し、かつノウハウを持った少数精鋭チームの必要性

21 2013-08-23 TP&Dフォーラム2013 白石 啓

場所の情報：緯度経度情報と住所情報の区別

• 利用用途による違いと入力方法による違い

• 緯度経度情報 • 特定の場所を指し示すことに適している

• 機械付与に向いている（人が入力するのには不向き）

• 機械処理に向いている

• 「世界測地系」に記述を統一することで、データの流通性／地図アプリケーション上の表示に対応

• 住所情報 • ある一定の範囲の場所を指し示すことに適している

• 人が入力することによって付与される

• 人が見て理解することに向いている

22 2013-08-23 TP&Dフォーラム2013 白石 啓

場所の情報：「作成場所」、「撮影場所」、 「対象の場所」

• 「撮影場所」と「対象の場所」が異なるケース • 概ね「撮影場所≒撮影対象の場所」と考えられるが…

• 例：福島第一原発を数km先から撮影した場合

• そこで、両者を区別できるように

• 撮影場所、作成場所 • Ontology for Media Resources 1.0のma:locationLatitude、

ma:locationLongitudeを使用

• Geoのgeo:latとgeo:longは使用できず

• 「その主語となるリソースが存在する場所」を指し示してしまうため

• 対象の場所 • dcterms:spatialを構造化し、その下でGeoのgeo:latとgeo:long、RDF

Vcardを採用

23 2013-08-23 TP&Dフォーラム2013 白石 啓

場所の情報：課題

• 「作成場所」と「対象の場所」の区別に対する考え方 • ユーザが場所の概念を明確に区別して検索するだろうか？

• メタデータ作成者が、概念の違いを正しく理解し付与できるか？

• ⇒検索では、区別せず行う実装に

• 住所情報を標準的に記述する最適な方法が無い • 現在はマニュアルレベルで標準化を図っている状況

• 「福島県」、「福島市」問題の解消

• JIS「全国地方公共団体コード」も存在するが…

• データ入力が直感的でない

• システム側で長期的にマスタデータを保持・維持管理することが必要

• 「平成の大合併」以前の自治体単位での絞り込みを求める声

• ⇒過去〜現在の自治体情報、変遷情報のデータセットの必要性

24 2013-08-23 TP&Dフォーラム2013 白石 啓

場所の情報：課題

• 場所の範囲を表す方法 • 「○○地方」、「○○県△△地域」という範囲をどうやって機械可読表現で表すか？

• 「点」だけでなく「線」としての場所情報

• 例：仙石線のルートに沿ってコンテンツを見ていきたいときにどうやって見ていけば良いのか？

• 例：ある人の避難経路を地図上で可視的に見るには？

• ⇒どのようなユーザインタフェースで提供するのが望ましいかを調査したうえで、どのような形式で場所情報を持っておけば実現可能かを検討する必要がある

25 2013-08-23 TP&Dフォーラム2013 白石 啓

日時の情報：表記の統一

• W3CDTF形式に基本的に統一

• 統一することにより、以下のような機能の実現が容易に • ファセットによる日時からの絞り込み

• 詳細検索

• タイムライン検索

• やむなく生じてしまう「未来の日付」問題

26 2013-08-23 TP&Dフォーラム2013 白石 啓

日時の情報：「作成年月日」、「公開年月日」、 「主題としての年月日」

• 「何に対する日時情報なのか」がわかるように

• 作成年月日 • 写真の撮影年月日等

• dcterms:createdで表現

• 公開年月日 • 震災関連図書の出版年月日

• 震災に関する番組の放映年月日

• dcterms:issuedで表現

• 主題としての年月日 • 例：2013年8月23日に放映された、2011年3月11日を主題とする映像

• dcterms:temporalを構造化することにより表現

27 2013-08-23 TP&Dフォーラム2013 白石 啓

日時の情報：課題

• 「作成年月日」、「公開年月日」、「主題としての年月日」への考え方 • ユーザが日時それぞれの概念を明確に区別して検索するだろうか？

• メタデータ作成者が、概念の違いを正しく理解し付与できるか？

• ⇒検索では、区別せず行う実装に

• 日時の範囲を標準的に記述する最適な方法が無い • dcterms:Period形式というものがあるけれど…

• いくら標準と言っても、普及していなければ意味が無い

• 実装に使用するライブラリ、ソフトウェア、ミドルウェアで対応しているなど

• ⇒今後の標準化、普及が待たれる

28 2013-08-23 TP&Dフォーラム2013 白石 啓

主題に関する情報

• 「統制語彙」、「メタデータ作成者が入力した主題キーワード」、「ソーシャルタグ」を区別 • 統制語彙

• dcterms:subjectを構造化することで表現

• NDLSHの場合、WebNDLAへURI参照

• メタデータ作成者が入力した主題キーワード

• dc:subjectあるいはdcterms:subjectによって表現

• 複数のキーワードがカンマ区切り等で連結して入るケースはdc:subjectへ入れることで区別

• ソーシャルタグ

• 何が付与されるかわからないため、他の主題の値と区別できるように

• ndlkn:freeKeywordという語彙を独自定義し表現

2013-08-23 29 TP&Dフォーラム2013 白石 啓

主題に関する情報：課題

• 特別な手当は何もしていません… • 提供元アーカイブでどのようなコンテンツを集め、どんな主題情報を付与するか想定できない

• 思想の異なるあらゆるアーカイブからメタデータを受け取り、ポータルとして機能する「ひなぎく」で、主題情報を統制することは困難

• メタデータの項目レベルのマッピングのみならず、分類／タグレベルのマッピング仕様が別途必要

• 既存のメタデータを、新しい分類体系に後から入れ込む困難さ

• ⇒当面は「メタデータに入っていれば検索で引っかかる」ことでやむを得ないと判断

2013-08-23 30 TP&Dフォーラム2013 白石 啓

主題に関する情報：課題

• 震災関連アーカイブ全体における分類の考え方 • 震災関連アーカイブにおける標準的な分類を求める声はある

• 震災関連アーカイブに求められる分類設計スキルとは？

• ライブラリアンは本当に分類の専門家？

• タクソノミーが成り立つ余地はあるのか？

• 震災関連アーカイブに求められる主題分析とは？

• 担当者が主題分析スキルを持っているとは限らない

• アーカイブによって、対象利用者、目指すべきものはさまざま＝分類もさまざま

• 対象ユーザ、利用ログ等利用状況をふまえた分類設計が求められる？

2013-08-23 31 TP&Dフォーラム2013 白石 啓

やや脱線： （参考）主題分類の威力を感じた瞬間

• 「ひなぎく」では、どうやって震災関連のコンテンツのみ検索できるようにしているのか？

• システム内部で、ある一定の検索条件に当てはまるもののみ「ひなぎく」に登録する仕組みを実装 • 震災関連コンテンツのみを収録したアーカイブ

• 震災関連コンテンツが部分集合であるアーカイブ

• 分類・件名の充実した和図書：非常に高い精度で震災関連のものを抽出可能

• 充実していないその他の資料：キーワードでの抽出となるため、ノイズが多くなってしまう…

2013-08-23 32 TP&Dフォーラム2013 白石 啓

メタデータの付与の難しさ

• どんなタイトル、分類を付けますか？

2013-08-23 33 TP&Dフォーラム2013 白石 啓

出典：未来へのキオク http://kn.ndl.go.jp/view/79bb5eed-7733-49e9-a1a3-b293b3fcb669

メタデータの付与の難しさ

• 歴史的価値の定まらない大量の情報にメタデータを記述することの難しさ • タイトルや主題分類をどうやって付与するのか？

• 主観の混入

• 信頼性をどう確保するのか

• あとで付与することの難しさ

• RDFを想定したメタデータ記述の難しさ • URIを記述することの意味を理解する必要性

• 事実記入+機械可読情報⇒入力項目、入力コストの増加

• ⇒入力の負担を軽減するような入力インタフェースの重要性

• メタデータ入力を促進するインセンティブ設計の必要性 • その地域の人にしか付けられないメタデータ

34 2013-08-23 TP&Dフォーラム2013 白石 啓

メタデータ連携：メタデータ連携は泥臭いお仕事

• OAI-PMHが、メタデータ連携の現時点でのベストプラクティスであることは間違いない • メタデータの差分更新ができるのはOAI-PMHだけ

• しかし、OAI-PMHを使えば自動的に連携できてめでたしめでたし、ではない • メタデータ全件更新問題

• システムメンテナンス対応

• バッチ処理時間（リアルタイム更新は難しい）

• 更新・削除フラグを出力できないケースも

• APIの変更に伴う対応

• 日頃から、提供元担当者と緊密に連絡を取り合うことが大事

35 2013-08-23 TP&Dフォーラム2013 白石 啓

メタデータ連携：課題

• RDFとOAI-PMHの相性の悪さ • マッピング無しにデータを授受できるのが理想だが…

• RDFはデータ同士の関係を定義しているため、提供元からメタデータを収集した時点で、関係の定義に問題が生じ、結局マッピングが必要になる

• dcterms:sourceのソースのソース？

• 主語URIがrdfs:seeAlsoに入る

• おそらく目的の違いが原因か

• OAI-PMH：データの交換

• RDF：データ間のリンク

36 2013-08-23 TP&Dフォーラム2013 白石 啓

3. まとめに代えて

37 2013-08-23 TP&Dフォーラム2013 白石 啓

おさらい：本日お話しする内容

1. 「ひなぎく」とは？

2. 「ひなぎく」におけるメタデータ設計 1) 前提条件

2) 設計の基本的な考え方

3) メタデータスキーマ

4) 場所の情報

5) 日時の情報

6) 主題の情報

7) メタデータ付与の難しさ

8) メタデータ連携

3. まとめに代えて

38 2013-08-23 TP&Dフォーラム2013 白石 啓

「ひなぎく」開発の経験からの所感

• 資料種別、メディアによって、求められるメタデータは異なる • 例：文書資料

• 全文テキストがあれば、シンプルなメタデータ記述で足りる可能性

• 作成日の特定は困難。公開日（出版年月日）が重要になる

• 例：写真

• 全文テキストが存在しない⇒メタデータが決定的に重要

• 作成日（撮影日）、作成場所（撮影場所）が重要

• 資料種別、メディアによる、推奨メタデータ項目の必要性

• 「ひなぎく」メタデータスキーマが最初の第一歩

• メタデータの標準化はどこまで必要か？ • 目的によってさまざまなメタデータがあるのは当然のこと

• 「事実情報」はある程度標準化可能

• 記述形式も解釈も共通理解となりやすい 39 2013-08-23 TP&Dフォーラム2013 白石 啓

「ひなぎく」開発の経験からの所感

• メタデータに対する3方向からの考え方 • ユーザエクスペリエンスを高めるためのメタデータ

• データを処理・活用するためのメタデータ

• 保存・管理のためのメタデータ

• メタデータ単体では語れない • メタデータ設計が、ナビゲーション、ユーザエクスペリエンスに直結

• アウトプットのイメージから逆算して設計することが理想

• 「厳密さ」と「一見したわかりやすさ」のバランス

40 2013-08-23 TP&Dフォーラム2013 白石 啓

メタデータ単体では語れない ユーザとの接点を意識したメタデータを

2013-08-23 41 TP&Dフォーラム2013 白石 啓

・・・

-------------------- --------------------

----------------

・・・

過去

現在

カード目録 or OPAC

ユーザとの多様な接点

自機関のメタデータ

さまざまなメタデータを集約

参考資料

• 国立国会図書館東日本大震災アーカイブメタデータスキーマ（2013年3月版） http://kn.ndl.go.jp/sites/default/dfsfiles/ndlkn_schema201303.pdf

• 総務省｜震災関連デジタルアーカイブ構築・運用のためのガイドライン（2013年3月） http://www.soumu.go.jp/menu_seisaku/ictseisaku/ictriyou/02ryutsu02_03000114.html

• 国立国会図書館における東日本大震災アーカイブの取組み情報知識学会誌 22(4), 291-297, 2012-11-04 http://ci.nii.ac.jp/naid/40019489926#article

2013-08-23 42 TP&Dフォーラム2013 白石 啓