メタデータの機能と設計
- メタデータの役割
- 目録の記述
- 現代のメタデータの種別
- 記述メタデータと利用者タスク
- メタデータ項目とタスク：図書館の場合
- メタデータ項目とタスク：美術館の場合
- 記述メタデータと語彙とモデル
- メタデータの項目とモデル、そして実体
- 図書館のメタデータと実体
- 異なる実体レベル
- 博物館資料の記述
- 博物館資料メタデータのモデル
- さらに様々な分野のメタデータ
- メタデータ共有と相互運用
- メタデータ共有の観点
- 共有のための語彙
- 共有のための識別とモデル
- 分野横断統合プラットフォーム
- 統合プラットフォームのメタデータ
- 情報の来歴とソースの区別
- ジャパンサーチのモデル（案）
- ジャパンサーチの共通情報
- ジャパンサーチの構造的プロパティ
- ジャパンサーチの役割と課題
- 参照先
目録の記述
- シュメール語古文書の贈答品目録
- 贈答品目録の役割は？
- 贈答品を全て目の前に並べなくても何があるか分かる
- 壺の中身、珍しい品物の使い方などを記す
- ある品物が、いつ誰から贈られたものか（後で）調べる
メタデータ項目とタスク：図書館の場合
- 一覧表示の例（「歌麿」の検索結果）
- 一覧でのタスクと求められる機能は？ 概要、資料アクセスボタンがあるものも
- 詳細表示の例
- それぞれの項目はどのタスクに？
- 検索対象項目は？ 「北斎」でも「北斉」でも検索できる？ 漢字が分からない時は？
メタデータ項目とタスク：美術館の場合
- 一覧表示の例
- この一覧で得られる情報は？ 書籍の一覧との違いは？
- 詳細表示の例
- 各項目のタスクは？ 図書館との違いは？ この場合のアクセスとは？
メタデータの項目とモデル、そして実体
- メタデータとモデル
- ある領域の対象を何らかの形で表現する方法。そのためのメタデータ項目の組合せと構造
- 実体・属性と関係（ERモデル）
- 実体：それ自身が独立した記述対象になる→著者、出版者など
- 属性：実体を説明する性質で、独立性はない→タイトル、紹介文、サイズ
- 関係：実体同士のつながりのタイプ→書籍と人物は「作者」関係でつながる
- 年や住所は属性？実体？ → モデルの考え方によってどちらにもなり得る項目がある
- 実体の識別と集約
- 著者などを実体として扱うことで、その詳細情報をまとめ、関連資料を集約できる
- 同一であることを確実に識別する名前（識別子＝ID）が重要
- 「シェイクスピア」と「シェークスピア」で違っては困る
- 人物、団体などの主要実体の統一名（識別子）を集めた典拠を整備する
- 何を実体として扱うかによって、モデルの考え方が違ってくる
異なる実体レベル
- FRBRの4階層の考え方
- 作品→その翻訳（表現形）→その文庫版（体現形）→その1冊（アイテム）
- 作者、出版者、所有者は、それぞれどのレベルを対象にしたメタデータ？
- 博物館収蔵品のように、こうした階層が直接あてはまらないものもある
- 作品とデジタル複製物
- 歌麿の版画→その一刷り→そのデジタル画像
- 「デジタルアーカイブ」を考える場合、作品メタデータに加えて、デジタルオブジェクトに関する記述及び技術メタデータが必要
博物館資料の記述
- 利用者向けの記述メタデータ（黒田清輝「瓶花」）
- さまざまな実体が同じレベルで列挙されているが、それぞれの関係は？
博物館資料メタデータのモデル
- CIDOCの概念参照モデル（CRM）
- 作品の制作や移転（寄贈、購入など）に行為者（Actor）がかかわるモデル
- 黒田清輝が「瓶花」を制作し、東京国立博物館が取得した（寄贈された）
（博物館におけるコレクション情報の組織化から引用）- このモデルはどんな場合に有用？ アーカイブの利用者タスクから考えると？
- 博物館資料文書化の4つの目的（CIDOCの情報カテゴリ指針から）
- 資料のアカウンタビリティ（所有、所在、識別）の明確化
- 資料のセキュリティの補助（現在の状態、万一盗難された場合のための記述）
- 資料に関する履歴の記録（制作、所有権の移転、展示など）
- 資料への物理的，知的アクセスの支援
共有のための識別とモデル
- RDFのグラフ表現
- ERモデルでの実体の関係/属性を主語―述語―目的語の三要素（トリプル）として考える
- 実体（主語、目的語）、関係/属性（述語）を単語ではなくURIで表す
- 述語のURIをプロパティと呼ぶ
- 実体をグループ化するURI（クラス）とあわせてRDF語彙を構成する
- DC、FOAF、Schema.orgもRDF語彙としてURIで定義される
- さまざまなモデルを表現・記述するための共通基盤として機能
- 同じURIの実体がつながってRDFグラフを構成する。機関を越えたデータ共有
- Linked Data（リンクするデータ）
- 実体を識別するURIを、リンク（データ取得）にも用いる
- Tim Berners-LeeのLinked Data4原則に基づくデータ記述が広く受け入れられる
- 実体のつながりをアプリケーションが辿って新しいデータを得られる
- 文書のウェブと同じネットワーク効果によって広がるデータのウェブ
- WikipediaのデータをRDF（Linked Data）化したDBpediaなど、共有可能な名前によって、同じ作者の作品、同じ作品についての研究など世界のデータがつながる
- 実体を識別するURIを、リンク（データ取得）にも用いる
情報の来歴とソースの区別
- 複数情報源で来歴を区別しないと
- データを併合した時に区別がつかず混乱する
- 情報源を区別する間接的な記述
- メタデータを情報源ごとに分けて間接記述する。EuropeanaのEDMが近いかたち
ジャパンサーチのモデル（案）
- 共通情報とソースデータ/情報
- 多様な情報源をすべて単一のモデルにマッピングするのは困難
- 利用者タスクに基づき共通利用するための情報のみをマッピング
- 共通情報項目の1つとして「ソース情報」を持ち、ソースデータをそのまま保持
- 共通情報のモデル
- いつ、どこで、だれが、何を（→特に発見タスク）を基本にシンプルな項目設定
- 単純プロパティと構造的プロパティの併置
- 単純プロパティに標準語彙（Schema.org）の利用
- 提供情報（アクセスのための情報）の充実
ジャパンサーチの構造的プロパティ
- 単純プロパティと構造化プロパティの併用
- 監督、脚本＝太田隆文；撮影＝三本木久城というメタデータがある時
- 単純プロパティ：作者は共通のプロパティ
creatorで調べたい。関与した人は一括してcontributorで調べたい - 構造化プロパティ：監督、照明といった元データの項目情報も生かしたい
