klarer-himmel13's diary

(旧)図書館の中では走らないでください!から

情報組織化研究グループ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とはメタデータ標準である
    • 「とても有名」である一方、「15項目」があまりに有名であるため、2000年代のものが十分理解されているとは言いがたい。
  • 本日の話はDublin Coreのコンセプトを中心に、1996年ごろから開発の過程を見てきた情報技術的背景を持つ研究者の視点でお話しする

1.メタデータとは

  • データに関する構造化されたデータ=Structered Data
  • 記述対象に関する「何か」を書いたもの
    • この「何か」=付加価値(図書館で言うと索引や目録など)
    • 例1:ペットボトルのラベル(ラベルをはがすと中身が分からない)
    • 例2:名刺(あるひとの所属、役職、名前、連絡先について書かれたデータ)…など
  • ネット上ではすべての実体はネット上で識別できる何らかの実体として表現できなければならない
    • この「実体」=「データ」
    • 電子文書のようなもともと実体としてあるものと、アバターなど「ある人」を表す仮想的な実体を区別しない
  • メタデータはいかにしてリソースを使えるものにしているか、にある
    • ネットワーク上のどこかにある資源探し、アクセスし、評価し、利用し、取引するため
    • 組み合わすことの大切さと基盤統一への要求
    • メタ・メタデータ=メタデータについてのデータ…と原理的には「メタ」はなんども繰り返すことができる
  • メタデータの基本
    • 1件のメタデータは属性(記述項目)と属性値(記述項目の値)のあつまり
      • 例:名刺の場合、属性は「所属」「役職」「名前」…であり、属性値はそれらに入る名称等
    • 記述項目(記述すべき属性)を決めること+属性値の記述の仕方を決める
    • メタデータは1対1原則(ひとつの記述対象に対してひとつのメタデータ)*2
      • この「1」はメタデータを作る人が決める
      • 複数の記述対象であってもそれをひとまとまりに書けばOK*3
    • 属性
      • 名前とその意味によって定義する
      • 記述上の構造的制約(必須、省略可、繰り返し等)
    • 属性値について
      • どのような形式、どのような種類の値を書くか
      • どのようにして記述対象から値を抽出するか

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
  • DCはメタデータ表現のための独自データモデルを決めていない⇔目録規則
  • 属性と属性の意味のみを決める
  • 90年代の議論には、部分構造を表すための記述子が含まれていたが、後に姿を消す
  • RDFは開発段階でDCの影響を受けている
  • RDFのデータモデルは、リソースとリソース、あるいはリソースとリテラル(文字列)の間を属性で関係付ける実体関係モデル(ERモデル)である
    • 基本ユニットは<リソース、属性、属性値>
  • RDFは、RDF Schema(メタデータを定義する辞書)を持つ。メタデータに用いる属性や属性値の種類を定義する
    • RDFでは属性をProperty, 属性値の種類をクラスと呼ぶ
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:構造的な制約の定義

→独自のものを作ることはせず、できるだけアリモノを使い、組み合わせてスキーマを決めよう!

  • Singapore Framework*6
    • DCMIが2008年1月に公表したアプリケーションプロファイル定義のためフレームワーク

3.メタデータスキーマについて

メタデータスキーマを以下に分解する

  • 対象をどのような属性について書くのか=属性の集合
    • タイトル、作成者、内容の紹介…等
  • 属性ごとの記述制約
    • 必須、推奨、省略可能、繰り返し…等
  • 属性ごとの値の書き方
    • 自由、長さに制約、語彙の制約、形式の制約、言語の制約、文字コードの制約
  • メタデータをどのようなかたちで実現するのか
    • コンピュータ上での表現とい人間が読み書きするための表現
    • 文字セット(UnicodeやUTF8)
    • データベース管理システムやデータ交換のための形式
  • 属性値の取り出し方、書き方

→ここまで、実現上の形式を決める

    • 対象に合わせて、かつ属性の意味とあった内容をいかに取り出すか

メタデータ作成時に記述対象から抽出すべき内容(とその取り出し方)を決める

  • メタデータスキーマの基盤
    • 意味の基盤(メタデータ語彙)
      • 記述項目の名前とその意味
      • 属性値の型の名前とその意味
    • 構造の基盤
    • メタデータの基本はことば(語つまり概念)である
    • 属性、属性値の型を表す語句の定義が必要
    • 統制語彙などをコンピュータで機械的に扱えるように形式に定義する
  • Simple Knowledge Organization System(SKOS)*7
    • 分類や件名標目表、シソーラスのようにシンプルな構造で作られた語彙を表すために、RDF上に定義された語彙の表現形式
  • メタデータスキーマの構成要素を階層的にとらえる
    • 意味定義層:メタデータボキャブラリの定義
    • 抽象構文層:構造的制約
    • 具象構文層:HTML, XMLなど

→このようにとらえることで、総合運用性のレベルが見やすくなる

4.おわりに

Dublin Core

  • メタデータスキーマの概念モデルをつくりあげてきた
    • 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:筑波大学・知的コミュニケーションセンターで組織されたメタデータ情報基盤研究会では、産学官民でのメタデータに関する情報共有を進めている