DCMES:基本となる15の要素タイプ

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

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

それぞれの要素がかなり広い概念をカバーしており、詳細な記述にはあとで述べる精密化要素を使う方が便利ですが、最も普及している語彙なので、これを用いることで相互運用性の高いメタデータを提供することができます。

ウェブ文書でのDublin Core要素の利用

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

RDFでDublin Coreを使う

Dublin Coreの語彙は、メタデータの普遍的な記述を目指すRDFのプロパティとしてうってつけですから、RFD Primerなどの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://tyonn.ninja-x.jp/sw.htm/">
  <dc:creator>tyonnta</dc:creator>
  <dc:date>2001-09-04</dc:date>
 </rdf:Description>
</rdf:RDF>

DCの要素名が全て小文字で記述されていることに注意してください。HTMLの例では最初が大文字になっていますが、RDFでは通常プロパティは小文字で始めて（クラスは大文字で始めて）表記します。Expressing Simple Dublin Core in RDF/XMLなどの文書でも、all lowercaseと指定されています。

〔補足〕

従来、dc:creatorなどの目的語として「神崎正英」といった文字列が広く使われてきましたが、“文字列”を名前として持つ“作者”というリソースが存在すべきという考え方（RDFの構造化モデルの注を参照）があり、DCの抽象モデル[DCABSTMODEL]が定められた結果、DCプロパティの目的語に値域を定義しようという方向になっています（Dublin CoreのRDFモデル新仕様案を参照）。

〔以上補足〕

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/" />

外部RDFメタデータをHTML文書にリンクする

使用できる要素タイプが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:dateとして記述した日付は、リソースの作成日なのか、更新日なのかを区別することができません。

より厳密なメタデータ記述のために、DCMIは基本要素タイプの意味を精密化する拡張語彙を定義して勧告しました。拡張語彙には(1)要素タイプの精密化（Element Refinement）のためのものと(2)単位や記述ルール（スキーム）の明確化（Element Encoding Scheme）があります。

精密化要素

DCMESをより詳細に記述するためのプロパティとして、次の32要素が定義されています（2000年7月に24の要素が勧告されましたが、その後2001～2003年に追加されています）。

Dublin Coreの精密化要素
DCME要素	精密化要素	意味と役割
title	alternative	正式タイトルの代替
description	tableOfContents	リソースの目次を提供
description	abstract	リソースの要約を提供
date	created	作成日
	valid	有効期日もしくは期間
	available	利用可能日もしくは期間
	issued	正式発行日
	modified	更新日
	dateAccepted*	（論文やジャーナル記事などの）受理日
	dateCopyrighted*	著作権日
	dateSubmitted*	（論文やジャーナル記事などの）提出日
format	extent	サイズもしくは時間
format	medium	リソースの搬送媒体
relation	isVersionOf	リソースはこの要素が示すリソースの1バージョン
	hasVersion	リソースはこの要素が示すリソースをバージョンとして持つ
	isReplacedBy	要素が示すリソースで置き換えられる
	replaces	要素が示すリソースを置き換える
	isRequiredBy	要素が示すリソースで必要とされる
	requires	要素が示すリソースを必要とする
	isPartOf	リソースは要素が示すリソースの一部
	hasPart	要素が示すリソースをその一部として持つ
	isReferencedBy	要素が示すリソースから参照、引用されている
	references	要素が示すリソースを参照、引用する
	isFormatOf	リソースは要素が示すリソースと同じだが、異なるフォーマットによる
	hasFormat	同じ内容だが異なるフォーマットのリソースを持つ
	conformsTo	リソースが準拠している確たる標準を示す
identifier	bibliographicCitation*	リソースへの書誌的な参照。できればそのリソースを曖昧さなく特的できるだけの詳細な書誌を記述する
coverage	spatial	空間的・地理的な対象
coverage	temporal	時間的な対象
rights	accessRights*	リソースにアクセスできる人、もしくはセキュリティ要件
audience	educationLevel*	受講者などの教育、訓練レベル（audience要素はDCMEではなく拡張要素）
-	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要素が定義されています。

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

タイプ要素

DC精密化＝修飾要素のほかに、リソースのタイプを示す「クラス」に相当する語彙として、次の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のインスタンス）

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

DC精密化要素を実際にウェブ文書に応用する方法を見てみましょう。

RDFでDC拡張語彙を用いる

RDFでDC精密化要素を用いる方法は、DCMIの勧告Expressing Qualified Dublin Core in RDF / XML[DCQRDF]で考え方が示されています。DCMESを精密化する要素群は、基本要素と同様にプロパティを示す要素として直接記述します。

DC精密化要素の名前空間URIは、xmlns:dcterms="http://purl.org/dc/terms/"としてdcterms:にマップされているものとします（名前空間の定義はDCMI Namespace Policyによる[DCNS]）。

[例6]

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


<!-- 次のsubPropertyOf関係がスキーマで定義されている -->
<rdf:Description rdf:about="http://purl.org/dc/terms/created">
 <rdfs:subPropertyOf
   rdf:resource="http://purl.org/dc/elements/1.1/date"/>
</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でDC拡張語彙を用いる

HTML文書で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" />

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