Dublin Core: メタデータを記述するボキャブラリ

メタデータをコンピュータが理解して有益な情報とするには、その意味が共通の認識となっている語彙が必要です。Dublin Coreは、ウェブや文書の作者、タイトル、作成日といった書誌的な情報をメタデータとして記述するためのボキャブラリを定めています。15の基本要素と、そのRDFによる表現方法、またより精度の高い情報を提供するための拡張語彙について説明します。

DCMES:基本となる15のプロパティ

DCMI (Dublin Core Metadata Initiative)は、1994年のWWWC2での議論に端を発し、ウェブ上のリソースを記述する共通のメタデータ標準などを開発、促進する組織です。Dublin Core(ダブリン・コア)の名前は、1995年3月に米国オハイオ州のダブリン(Dublin)で開催されたOCLC/NCSA Metadata Workshopでの討議結果を"Dublin Core metadata"と呼んだところに由来しています。

Dublin Coreの中核となるのは、基本となる15の要素(プロパティ)を定義したDublin Core Metadata Element Set[DCMES]で、現在バージョン1.1が公開されています(2003年2月には[ISO15836]として国際標準になりました)。この要素を、Reference Descriptionの定義とコメントに基づいて見てみましょう(次の表で単に「リソース」という場合は、主語となっているリソースを表します)。

Dublin Coreのプロパティ
要素名定義とコメント
title リソースに与えられた名前。
creator リソースの内容に主たる責任を持つ人や組織などのエンティティ。(DCタームズではcontributorのサブプロパティ)
subject リソースのトピック。通常、主題を示すキーワードやキーになるフレーズ、分類コードを使う。統制語彙を用いるのが望ましい。
description リソースの内容の説明。要約、目次、文書の内容を表現した画像への参照、あるいは自由形式の説明文など、記述の方法は自由。
publisher このリソースを利用可能にしているエンティティの責任表記。個人の場合もあれば、組織やサービスの場合もある(「通常その名前」という古いコメントが残っているが、名前=エンティティではないので注意)。
contributor リソースの内容に寄与している(人や組織、サービスなどの)エンティティの責任表記。
date リソースのライフサイクルにおける出来事に関連する時もしくは期間。ISO-8601/W3C-DTF形式が推奨される(時間の粒度については制約を設けない)。
type リソースの性質もしくはジャンル。一般的なカテゴリ、機能、分野、内容の集約度などを示す用語を用いる。DCタイプ要素などの統制語彙から選択することが推奨される。リソースの物理的あるいはデジタル化の形式を示すには、Format要素を用いること。
format リソースの物理的あるいはデジタル化の形態。主として、メディアタイプや量(サイズ)を示す。リソースを表示したり処理したりするために必要なソフト、ハードを知るために利用できる。量の例としては、サイズや時間がある。MIMEなどの統制語彙を用いることが推奨される。
identifier あるコンテクストにおける、リソースへの曖昧さのない参照。
source リソースの派生元リソースへの参照。全体的な派生関係でも、部分的なものでもよい。形式的識別システムに従った文字列によるリソースの識別が推奨される。拡張プロパティでは、relationのサブプロパティ。
language リソースの(を記述している)言語。言語コードを使うことが推奨される。
relation 関連するリソースへの参照。拡張語彙の詳細なプロパティを使うことが多い。
coverage リソースの範囲もしくは対象。場所(地名、緯度経度)、時間区分(時代、日付、期間)、管轄区分(管理責任者名)などの分類を記述する。地名総覧のような統制語彙から選択する(適切な場所では、地名、時代区分名を緯度経度、期間などの数値表現より優先して用いることが推奨される)。
rights リソーの権利に関する情報。通常、リソースの知的所有権、著作権、財産権などについての言明を含む。

それぞれの要素がかなり広い概念をカバーしており、詳細な記述には次に述べる拡張プロパティを使う方が便利です。拡張プロパティは15要素と同じ名前も含む上に、定義域、値域も示されており、今後はこちらが基本になっていくと思われます。

DCMIメタデータ語彙

DCの基本要素(シンプルDC)で定めているデータの定義は、かなりおおざっぱなものです。これは扱いが簡単で普及させ易いというメリットがある一方、精度の高い情報を記述するにはどうしても力不足です。たとえば、dc:dateとして記述した日付は、リソースの作成日なのか、更新日なのかを区別することができません。

より厳密なメタデータ記述のために、DCMIはより精密なDCMIメタデータ語彙を定義しました。この語彙には(1)基本15要素を拡張するプロパティ(以前Element Refinementと呼ばれていたもの)と(2)統制語彙や記述ルールを明示するための符号化スキーム(Encoding Scheme)があります。

プロパティの拡張

シンプルDCをより詳細に記述するためのプロパティとして、次の32要素が定義され(2000年7月に24の要素が勧告されましたが、その後2001〜2003年に追加されています)、2008年1月にはこれらに基本15要素ほかを加えて55のプロパティとし、さらに定義域、値域を与えた新DCMI Metadata Terms(DCタームズ)が公開されました。これらについては「DCプロパティ一覧と定義域、値域」を参照してください。

次の表はDCタームズの拡張関係(上位プロパティ)を示しています。リンクが設定されているプロパティはシンプルDCプロパティと同じ名前を引き継いでいるものです(名前空間は異なります)。また単に「リソース」という場合は、主語リソースを表します。

拡張されたプロパティ
上位プロパティ DCタームズ 意味と役割
title alternative 正式タイトルの代替
description tableOfContents リソースの目次を提供
abstract リソースの要約を提供
contributor creator 寄与者/作者
publisher - 出版者
date created 作成日
valid 有効期日もしくは期間
available 利用可能日もしくは期間
issued 正式発行日
modified 更新日
dateAccepted* (論文やジャーナル記事などの)受理日
dateCopyrighted* 著作権日
dateSubmitted* (論文やジャーナル記事などの)提出日
type - リソースのタイプ
format extent サイズもしくは時間
medium リソースの搬送媒体
relation isVersionOf リソースは目的語リソースの1バージョン
hasVersion リソースは目的語リソースをバージョンとして持つ
isReplacedBy リソースは目的語リソースで置き換えられる
replaces リソースは目的語リソースを置き換える
isRequiredBy リソースは目的語リソースで必要とされる
requires リソースは目的語リソースを必要とする
isPartOf リソースは目的語リソースの一部
hasPart リソースは目的語リソースをその一部として持つ
isReferencedBy リソースは目的語リソースから参照、引用されている
references リソースは目的語リソースを参照、引用する
isFormatOf リソースは目的語リソースと同じだが、異なるフォーマットによる
hasFormat リソースは同じ内容だが異なるフォーマットの目的語リソースを持つ
conformsTo リソースが準拠している確たる標準を示す
identifier bibliographicCitation* リソースの書誌的な参照記述。できればリソースを曖昧さなく特的できるだけの詳細な書誌を記述する
source - リソースのソース
language - リソースの言語
subject - リソースの主題
coverage spatial 空間的・地理的な対象
temporal 時間的な対象
rights license リソースのライセンス
accessRights* 主語リソースにアクセスできる人、もしくはセキュリティ要件
audience (audience) 主語リソースが対象とする受講者/利用者(audience要素はシンプルDCではなく拡張要素)
educationLevel* 主語リソースが対象とする受講者/利用者を表す、教育/訓練レベルによって定義される実体。たとえば大学院生、図書館司書など(値域はAgentClass)
mediator 主語リソースが対象とする受講者/利用者にアクセスを媒介する実体。たとえば学生向け教材を(授業などで)採用する教師など。
- provenance リソースの来歴(所有者、保管地の変更や、形態など同一性に関わる大きな変化など)
- rightsHolder リソースの権利保有者
- instructionalMethod 主語リソース(たとえば授業)が、狙いとする知識や技術などの獲得のために用いる指導方法
- accrualMethod* コレクション=主語リソースへのアイテム追加の方法(Purchase, Donationなど)
- accrualPeriodicity* コレクション=主語リソースへのアイテム追加の頻度(Weekly, Monthlyなど)
- accrualPolicy* コレクション=主語リソースへのアイテム追加の方針(Closed, Active, Partialなど)

*印はconformingステータスで、which conform to the grammar of Elements and Element Refinements, though without necessarily meeting the stricter criteria of usefulness across domains or usefulness for resource discover とされています。

コレクション関連プロパティは2005-06-13付けでUsage Boardから採用が告知されました。

符号化スキーム

スキームの明確化のための拡張語彙としては、次の17要素が定義されました。2008年の改訂でこれらのスキームは「語彙符号化スキーム」と「構文符号化スキーム」に分けられ、数も20に増えています。またこの時点で、修飾対象という概念も削除されました(改訂内容については、後日追加)。

Dublin Coreの符号化スキーム
符号化スキーム 意味と役割 修飾対象
LCSH 米国議会図書館の主題分類(Library of Congress Subject Headings) subject
MESH 医学関連の主題分類(Medical Subject Headings) subject
DDC デューイ十進分類(Dewey Decimal Classification) subject
LCC 米国議会図書館分類(Library of Congress Classification) subject
UDC ユニバーサル十進分類(Universal Decimal Classification) subject
DCMIType リソース内容の性質、ジャンルを分類するDCタイプ要素 type
IMT MIMEタイプ format
ISO639-2 ISO 639-2による言語コード language
RFC1766 RFC 1766で定められた、 ISO 639の2文字言語コード(とISO 3166の2文字国コードの組み合わせ)による言語コード表記 language
URI Uniform Resource Identifier identifier, source, relation
Point 地理座標上の一点を示す spatial
ISO3166 ISO 3166による国コード spatial
Box 地理的な指標に基づくエリアを示す spatial
TGN ゲッティ地名シソーラス spatial
Period 時間的な期間 date, temporal
W3CDTF W3Cノートで示されている、ISO 8601に基づく日時表記法 date, temporal
RFC3066 RFC 1766を置き換えるRFC 3066による言語コード(ISO 3166-2による3文字言語コードも認める) language

タイプ要素

拡張されたプロパティのほかに、リソースのタイプを示す「クラス」に相当する語彙として、次の12要素が定義されています[DCTYPE]。DCMESのtype要素の値として利用することができます。

Dublin Coreのタイプ要素
タイプ要素 意味と役割
Collection アイテムが集積したもの。リソースはグループで構成されることを意味し、その部分は独自に記述、移動できる。
Dataset 定義された構造に基づいて、機械処理可能にエンコードされた情報。例えば、リスト、テーブル、データベースなど。
Event 時間に基づいた、非永続的な事象。イベントのメタデータは、その目的、場所、期間、主催者、関連リンクなどを検索しやすいように提供される。このタイプのリソースは、期間終了後、あるいは実施前には取得できないことがある。例えば展覧会、ウェブキャスト、会議、ワークショップ、結婚式など。
Image Imageは文字以外の象徴的な視覚表現。写真、絵画、印刷物、映画、地図、音楽記号(musical notation)など。ここで言うImageは、電子的なものと物理的なもの(絵画の実物など)の両方を含む。
InteractiveResource ユーザーが使い方を理解し、実行したり体験したりするインタラクションを必要とするリソース。ウェブのフォーム、アプレット、マルチメディア学習ツール、チャット、仮想体験など。
Service 1つ以上の有益な機能をエンドユーザーに提供するシステム。コピーサービス、銀行サービス、認証サービス、図書館の相互貸し出し、ウェブサーバーなど。
Software コンピュータのプログラムで、ソースコードもしくはコンパイルされた形で、一時的ではなくインストール可能なもの。インタラクティブな環境を作ることだけが目的のソフトウェアには、InteractiveResourceタイプを使う。
Sound 主たる内容が音声として提供(レダリング)されるリソース。音楽ファイル、CD、スピーチや音の録音など。
Text 内容が主として読むための語(words)で構成されるリソース。書籍、手紙、論文、詩、新聞、記事、メーリングリストのアーカイブなど。(textフォーマットではなくtextタイプであるということは)文字情報のファクシミリや画像もこのジャンルに含まれることに注意。
PhysicalObject 無生物、三次元のオブジェクトもしくは実体。例えば、コンピュータ、巨大遺跡、彫刻など。これらのデジタル表現や代替物は、Image、Textその他のタイプを使う。
StillImage 絵画、グラフィックデザイン、地図、図案などの静止画像。Imageのサブクラスに相当(StillImageのインスタンスはすべてImageのインスタンス)
MovingImage アニメーション、映画、テレビ番組、ビデオなど、一連の画像を連続的に表示して動きを表現するもの。Imageのサブクラスに相当(MovingImageのインスタンスはすべてImageのインスタンス)

ウェブ文書でのDublin Coreプロパティの利用

DCMESは、語彙を定めるだけでその記述法や構文は定義していませんが、これをRDF、HTMLなどのウェブ文書で利用するための推奨方法が、別途提案されています。

RDFでDublin Coreを使う

Dublin Coreの語彙は、メタデータの普遍的な記述を目指すRDFのプロパティとしてうってつけですから、RFD Primer[RDFP]などのRDF関連仕様書にもDCが紹介されています。RDFの場合は、DCの名前空間をdc:などの適当な接頭辞に結びつける宣言を行った上で、プロパティ名としてDCの要素を用います。HTMLの場合と同じ例をRDFのXML構文で表現すると次のようになります。

[例1]

<rdf:RDF
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns:dc="http://purl.org/dc/elements/1.1/"
  xml:lang="ja">
 <rdf:Description rdf:about="http://www.kanzaki.com/docs/sw/">
  <dc:creator>神崎正英</dc:creator>
  <dc:date>2001-09-04</dc:date>
 </rdf:Description>
</rdf:RDF>

DCの要素名が全て小文字で記述されていることに注意してください。RDFプロパティとしてのダブリンコアは小文字で書き始めるよう定義されています。

〔補足〕

従来、dc:creatorなどの目的語として「神崎正英」といった文字列が広く使われてきましたが、DCの抽象モデル[DCABSTMODEL]に則り、DCプロパティの目的語に値域が与えられました。DCMIメタデータ語彙を参照してください。

〔以上補足〕

RDFでDC拡張語彙を用いる

[例6]

<rdf:Description rdf:about="http://www.kanzaki.com/docs/sw/">
 <dc:creator>神崎正英</dc:creator>
 <dcterms:created>2001-09-04</dcterms:created>
</rdf:Description>

スキーム修飾要素の使い方は曖昧さが残りますが、プロパティ値をスキーム修飾要素の型を持つ型付きリテラルで記述する方向になっています。

[例7]

<dcterms:created rdf:datatype="&dcterms;W3CDTF">2001-09-04</dcterms:created>

(ここでは、dctermsの名前空間を&dcterms;と実体参照によって表記しています。)

スキーム修飾要素の場合は、プロパティ要素の目的語ノードとして記述し、その内容にrdf:value要素として値を記述します。

[例7-1]

<dcterms:created>
 <dcterms:W3CDTF>
  <rdf:value>2001-09-04</rdf:value>
 </dcterms:W3CDTF>
</dcterms:created>

この例では、日付記述のスキーマにW3CのDTFを用いていることを示すために、dcterms:W3CDTF要素で修飾しています(dcterms:createdプロパティの目的語はdcterms:W3CDTFクラスの匿名リソースで、そのrdf:valueの値が2001-09-04となる)。

HTMLにDublin Coreを埋め込む

Dublin Coreの語彙をHTML文書に埋め込んでメタデータを記述する方法は、[RFC2731]で提案されています。この概要を紹介しましょう。

DCの個々の語彙は、meta要素を用いて示します。name属性に、DCの語彙をDC.という接頭辞付きで記述し、その値をcontent属性で記述します。たとえば、文書の作者と作成日付をこの方法で記述すると

[例2-1]

<meta name="DC.creator" content="神崎正英" />
<meta name="DC.date" content="2001-09-04" />

という具合になります。また、プロパティの値がURIの場合は、meta要素ではなくlink要素を用いて次のように記述します。

[例2-2]

<link rel="DC.relation" href="http://example.org/" />

合わせて、このDC.という接頭辞がDublin Coreの語彙を意味すること示すために、link要素で次のようにしてDCの名前空間に結びつけます。

[例3]

<link rel="schema.DC" href="http://purl.org/dc/elements/1.1/" />

使用できる要素タイプがDTDで定められているHTMLなどは、RDFを直接埋め込むと仕様に厳密適合しない文書になってしまいますから、それが困る場合は、RDFで記述したメタデータは外部ファイルなどに保存し、HTML文書にリンクすることになります。HTML側でこのメタデータの存在を指定する方法としては、次のようなlink要素を使うことがRDF Model and Syntax仕様書(付録B)[RDFMS]などで推奨されています。

[例4] <link rel="meta" href="dublin-core.html.rdf" />

RDFメタデータを示すのに、HTML等のリソースのURIの最後に.rdfという拡張子を加える方法は、特別に定義されたものではありませんが、DCMIのサイトでも利用している、比較的普及した手段です。

〔補足〕

HTML4の仕様書は、仕様書に記載されているリンクタイプ以外のものを使う場合はhead要素のprofile属性でその定義を参照すること、と定めています。この規定はほとんど有名無実と化してはいますが、厳密を期したい方は、次のように記述することができます。

[例5] <head profile="http://purl.org/net/ns/metaprof">

このプロファイルにより、大手を振ってrel="meta"というリンクタイプが使えるようになります ;-)

〔以上補足〕

XHTMLにDCメタデータを直接記述する

XHTMLは名前空間を使って語彙を拡張できますから、DC/RDFのメタデータを直接記述することも可能です。この方法については、実験的な議論であるXHTMLを拡張し、メタデータを直接記述するを参照してください。

拡張語彙を使ってDCメタデータを記述する

DC拡張語彙(DCタームズ)をRDFで表現する方法は、2008年に改訂版が勧告されましたが[DCRDF]、今ひとつしっくり来ないのと、普通のRDFの書き方と同じであることから、説明は割愛します。

HTMLでDC拡張語彙を用いる

HTML文書でDC精密化要素(DCタームズ)を使う方法は、Using Dublin Core[DCUSAGE]の6.3 Qualified HTML Examplesに示されています。要素の精密化の拡張語彙はmeta要素のname属性に記述するDC要素名の接尾辞として、スキームのための修飾子はscheme属性として記述します。

[例8]

<meta name="DCTERMS.created" content="2001-09-04" />
<meta name="DC.subject" scheme="DCTERMS.DDC" content="158.25" />

※以前のDCMI勧告では、<meta name="DC.Date.Creator" ...scheme="DDC" ...、という具合に、異なる記述となっていましたが、2003年11月の新しい勧告[DC-XHTML]で上記の形に改められています。

参照文献

[DCMITERMS]
DCMI Usage Board, Dublin Core Metadata Terms, , DCMI Recommendation, (updates DCMES, DCQ and DCTYPE)
<http://dublincore.org/documents/dcmi-terms/>
[DCABSTMODEL]
Andy Powell, et al., DCMI Abstract Model, , DCMI Recommendation
<http://dublincore.org/documents/abstract-model/>
[DCRDF]
Mikael Nilsson, et al., Expressing Dublin Core metadata using the Resource Description Framework (RDF), , DCMI Recommendation
<http://dublincore.org/documents/dcq-rdf-xml/>
[ISO15836]
ISO TC 46/SC 4, ISO 15836:2003(E) Information and documentation -- The Dublin Core metadata element set, , International Standard
<http://www.niso.org/international/SC4/n515.pdf>
[RFC2731]
J. Kunze, Encoding Dublin Core Metadata in HTML, , The Internet Society
<http://www.ietf.org/rfc/rfc2731.txt>
[RDFP]
Frank Manola and Eric Miller, RDF Primer, , W3C Recommendation
<http://www.w3.org/TR/rdf-primer/>
[DCMES]
DCMI, Dublin Core Metadata Element Set, Version 1.1: Reference Description, , DCMI Recommendation (see DCMITERMS)
<http://dublincore.org/documents/dces/>
[DCQ]
DCMI, Dublin Core Qualifiers, , DCMI Recommendation (see DCMITERMS)
<http://dublincore.org/documents/dcmes-qualifiers/>
[DCTYPE]
DCMI Usage Board, DCMI Type Vocabulary, , DCMI Recommendation (see DCMITERMS)
<http://dublincore.org/documents/dcmi-type-vocabulary/>
[DC-XHTML]
Andy Powell, Expressing Dublin Core in HTML/XHTML meta and link elements, , DCMI Recommendation
<http://dublincore.org/documents/dcq-html/>
[DCUSAGE]
Diane Hillmann, Using Dublin Core, , DCMI Recommendation
<http://dublincore.org/documents/usageguide/>
[DCNS]
Stuart Weibel, Namespace Policy for the Dublin Core Metadata Initiative (DCMI), , DCMI Recomendation
<http://dublincore.org/documents/dcmi-namespace/>