情報組織化研究グループ4月月例会「Dulbin Coreのこころ」
日時:2011年4月16日 14:30-17:00
タイトル:Dublin Coreのこころ
講演者:杉本重雄氏*1(筑波大学・図書館情報メディア研究科)
URL:http://www.tezuka-gu.ac.jp/public/seiken/meeting/2011/201104.html
目次:
- はじめに
- メタデータとは
- Dublin Coreについて
- Simple Dublin Core
- Resource Description Frameworkと Dublin Core
- Application Profile
- メタデータスキーマについて
- おわりに
もともと工学部でソフトウェアに関わったこられた杉本先生は、図書館情報学に関わるようになり、「コンテンツを扱うことの強み」をその時感じたそうです。
はじめに
- Dublin Coreとはメタデータ標準である
- 「とても有名」である一方、「15項目」があまりに有名であるため、2000年代のものが十分理解されているとは言いがたい。
- 本日の話はDublin Coreのコンセプトを中心に、1996年ごろから開発の過程を見てきた情報技術的背景を持つ研究者の視点でお話しする
1.メタデータとは
- データに関する構造化されたデータ=Structered Data
- 記述対象に関する「何か」を書いたもの
- この「何か」=付加価値(図書館で言うと索引や目録など)
- 例1:ペットボトルのラベル(ラベルをはがすと中身が分からない)
- 例2:名刺(あるひとの所属、役職、名前、連絡先について書かれたデータ)…など
- ネット上ではすべての実体はネット上で識別できる何らかの実体として表現できなければならない
- この「実体」=「データ」
- 電子文書のようなもともと実体としてあるものと、アバターなど「ある人」を表す仮想的な実体を区別しない
- メタデータはいかにしてリソースを使えるものにしているか、にある
- メタデータの基本
Googleを例に、「ぐぐる」をフラット化していく世界に、その反対に特化した世界として従来の図書館等を例にあげ、ネットワーク上での資源活用とメタデータについて、図書館はどちらにも対応していかなければならない
- インターネット上ではいろいろな情報資源に関する情報=メタデータをひとつの入り口から得ることが普通になっている(フラット化)一方、メタデータは情報資源によって異なるという矛盾した要求を満たさねばならない
- Dublin Core(以下DC)は上記の要件を満たすために、異なる領域で使える属性を決め、メタデータの構造の定義と記述項目(属性の定義)を明確に分離した
2.Dublin Coreについて
Simple Dublin Core
- DC Metadata Element Set
- 1995年ころから多様な資源に共通な記述要素=15項目
- Description Metadata
- Dublin Core Metadata Initiative(DCMI)
- 開発と維持管理のための組織(日本ではインフォコム株式会社が企業として出資しているらしい)
- DCの基本エレメント
- すべての15項目が繰り返し可能
- ISO 15836, JIS X 0836
- 記述項目のみを決めている
- 構造的制約や具体的な表現形式は決めてない
- 現在のエレメント定義
- 55エレメント*4(DCMI Termsと呼んでいる)
- Application Profile*5
Resource Description Framework(RDF)とDublin Core
1998年の合意でできたSimple Dublin Coreに含まれる15の記述項目(DCMES)から、現在の記述項目(dcterms, 55項目)へ
- DCMESの15項目(Legacy)はdctermsの55項目とは分離して定義される
- DCMESで定義された要素をそのまま残す一方で、新たなdctermsで定義された要素との間を関係付けることで相互運用性を確保
- DCをめぐる歴史的変遷—項目のまとめ
- Qualifier(限定子)をめぐる諸問題
- 1998年、Qualified DCとQualifierを導入(後に使わなくなる)
- 2000年、DC Qualifierが定義される
- 属性の意味を詳細化する限定子と、属性値の型を表す限定子の定義
- 属性の下部構造を表すための限定子は除外
- 属性の意味が詳細化される
- 日付(date)→作成日付(Date created)
- 内容記述(Description)→目次(Table of Contents)と抄録(abstract)
- ここで「作成日付」は「作成」が意味を限定するので、形容詞としてcreatedが定義される
- ところが、RDFではcreatedもabstractもproperty
- createdという名前のpropertyはネーミングミスで、本来はDatecreatedとすべき。(Qualifierの議論とRDF開発はほぼ同時期で、RDFをベースにすることが十分に理解されていなかったためか)
- 2000年、15項目とは別のQualifierのセットを定義
- 構造を表す限定子は導入されなかった(=記述項目の定義と構造定義を切り離す)
- データ構造はRDFのデータモデルにもとづくことで表現
- 2002年のフィレンツェ会議で、Agentをcreator, contributor, publisherの上位属性として導入する提案が1998年にひき続いてあったが、認められず。現在のかたいになったのは2008年の文書から
- やがて、Qualified DCやQualifierは使われなくなった
Application ProfileとMetadata Vocabulary
- メタデータ規則における記述項目の定義と構造定義の切り離し
- つまり、「何を使うのか」と「どう使うのか」を分ける
- このことによって、異なるコミュニティ間でも使う属性を共有し、そこから各コミュニティが取りに行くかたちで使うことで、摩擦を少なくし、意味的にコミュニケーションすることができる=これがDCのこころ!
- 記述項目の定義:個々の項目の名前や意味を定義する
- 構造定義:記述項目ごとの記述条件(省略可能性、繰り返し等)
- DCMESやdctermsはあくまでメタデータ語彙(属性として用いる語と属性値の型を表す語の集合)であり、これだけ与えられても、メタデータは書けない
- 応用のためには応用用のメタデータ語彙集を作り、それの上に応用のための構造制約や記述形式等を定義する。この応用用のスキーマをApplication Profileと呼ぶ
- メタデータスキーマは以下のふたつから成る
- (Metadata Vocabulary(Element Set):属性を表すための集まり、属性値の形式や統制語彙を表す語の集まり
- Application Profile:構造的な制約の定義
→独自のものを作ることはせず、できるだけアリモノを使い、組み合わせてスキーマを決めよう!
3.メタデータスキーマについて
- 対象をどのような属性について書くのか=属性の集合
- タイトル、作成者、内容の紹介…等
- 属性ごとの記述制約
- 必須、推奨、省略可能、繰り返し…等
- 属性ごとの値の書き方
- 自由、長さに制約、語彙の制約、形式の制約、言語の制約、文字コードの制約
- メタデータをどのようなかたちで実現するのか
- コンピュータ上での表現とい人間が読み書きするための表現
- 文字セット(UnicodeやUTF8)
- データベース管理システムやデータ交換のための形式
- 属性値の取り出し方、書き方
→ここまで、実現上の形式を決める
-
- 対象に合わせて、かつ属性の意味とあった内容をいかに取り出すか
→メタデータ作成時に記述対象から抽出すべき内容(とその取り出し方)を決める
→このようにとらえることで、総合運用性のレベルが見やすくなる
4.おわりに
- メタデータスキーマの概念モデルをつくりあげてきた
- Application Profileの概念
- Mixing and Matching, アリモノを使おう
- リソースの発見と記述のために分野にまたがって使うことのできる記述項目(属性)の語彙を創り上げてきた
- メタデータはことば(=概念)の定義が基本
- 将来にむけてメタデータはインターネット上での情報流通の要になる
- メタデータの総合運用性の向上のためのインフラが必要*8
- メタデータスキーマの共有*9
- 最後に図書館目録について
- 組織だって作られた長い歴史を持つメタデータであり、それぞれのコミュニティの中でニーズにあった発展を遂げてきた
- その一方、ネットワーク情報環境の発展による利用者の行動パターンや、出版・情報発信メディアの進化、情報獲得の変化についていかなくてはならない
- こうした目録などは情報の組織化のための知識を具現化してきたものであり、そいした知識をより広い範囲で利用できるようにしなければならない
*1:http://www.trios.tsukuba.ac.jp/Profiles/0007/0001645/profile.html
*2:ただし、これは概念のレベルでの話であり、現実の目録が作成日付がはいっているように運用のレベルでは1対1ではない
*3:太字は筆者による
*4:参照:DCMI Metadata Terms>http://dublincore.org/documents/dcmi-terms/ accessed 2011/5/1
*5:参照:The Singapore Framework for Dublin Core Application Profiles http://dublincore.org/documents/singapore-framework/ accessed 2011/5/1
*6:参照:http://dublincore.org/documents/singapore-framework/ accessed 2011/5/1
*7:参照:http://www.w3.org/2004/02/skos/ accessed 2011/5/1
*8:参照:メタデータ情報基盤構築事業>http://www.meta-proj.jp/ accessed 2011/5/1
*9:筑波大学・知的コミュニケーションセンターで組織されたメタデータ情報基盤研究会では、産学官民でのメタデータに関する情報共有を進めている