Dublin Coreについて−最近の動向、特にqualifierについて

杉本重雄
図書館情報大学
sugimoto@ulis.ac.jp

概要

Dublin Core Metadata Element Setはインターネット上における情報資源の発見を目的として開発 されてきたメタデータ記述規則であり、これまで15エレメントからなる基本エレメントセットを決め てきた。一方、より詳細で明確なメタデータ記述のためのqualifierと呼ばれるメタデータ記述のため の要素が以前から議論されてきている。昨年開催された第7回ワークショップ（DC-7）以降、Dublin Core Metadata Initiativeとして推奨するqualifierに関する議論を進め、2000年7月qualifierセッ トをはじめてアナウンスした。今回承認されたqualifierにはエレメントの意味をより詳細化する Element Refinement qualifierと、エレメントに記述する値の形式を規定するEncoding Scheme qualifierがある。本稿では、承認されたqualifierを中心として、DC-7以降の話題について述べる。

キーワード

メタデータ、Dublin Core Metadata Element Set、Dublin Core Metadata Initiative、qualifier、情報資源の発見

Dublin Core - Recent Development and the First Qualifier Set

Shigeo Sugimoto
University of Library and Information Science

abstract

Dublin Core Metadata Element Set is a metadata schema developed for information resource discovery on the Internet. It defines a metadata element set consisting of 15 basic elements. Qualifiers for the metadata elements have been discussed for more semantically refined description and for more accurate interpretation of metadata After the 7th Dublin Core Workshop (DC-7) held in October 1999, the Dublin Core Metadata Initiative (DCMI) discussed the qualifiers to announce the first set of qualifiers approved for interoperability. DCMI announced the first set in July 2000.The announced qualifiers include element refinement qualifiers and encoding scheme qualifiers. The former refines or narrows the meaning of an element. The latter specifies the encoding scheme or vocabulary of a value of an element. This article presents the overview of the recent development of Dublin Core since DC-7, especially the qualifiers.

keywords

Metadata, Dublin Core Metadata Element Set, Dublin Core Metadata Initiative, Qualifier, Information Resource Discovery

1. はじめに

　Dublin Core Metadata Element Set1）は、1995年頃からインターネット上の情報資源の発見を目 的として開発されてきたメタデータ記述規則であり、メタデータ記述のエレメントセット（メタデー タの記述要素のセット）を決めている[1]。最近では、その利用も広まってきている。Dublin Coreの 開発はメーリングリストとワークショップでの議論によって進められてきている。昨年開かれた第7 回ワークショップ（1999年10月、ドイツ国立図書館（フランクフルト））では、それ以前とは異なり Dublin Coreの応用や今後の開発活動の方向・維持に関する議論が行われた[2]。本稿では第7回ワークシ ョップ(DC-7と記す)以降の話題、特に2000年7月に承認されたqualifierに関して詳しく述べる。

　実質的には1997年秋の第5回ワークショップ（DC-5、フィンランド国立図書館）以来、基本15エレ メントからなるDublin Core Metadata Element Set（Simple Dublin Coreと呼ばれる）は固定して いる。この基本エレメントセットの標準化が進められており、インターネットのコミュニティのため の標準として作られるRFC文書として、Simple Dublin Coreを定義したRFC2413とDublin Core メタデータのHTML上での表現を定めたRFC2731が作られている。現在欧米での標準化機関におけ る作業も進められており、ヨーロッパではCENによる標準化が進み、一方アメリカではNISOでの 投票が本年8月に行われている[3]。

　基本エレメントに加えて、以前から議論されてきたより詳細な記述のための記述子であるqualifierに 関するDCMIとしての推奨セットを2000年1月にはアナウンスすることをアナウンスしたことが、 DC-7でのもっとも大きな事柄であった。予定よりは遅れたものの2000年7月にはじめのセットをア ナウンスした。このほかDC-7では、応用や将来に向けたDublin Coreの維持管理に関するワーキン ググループを立ち上げた。以下本稿では、qualifierを中心として解説する。

2. 第7回ワークショップとその後

　qualifier2）はエレメントの意味をより正確に示すために、エレメントの表す意味を限定、あるいは エレメントに表す値のボキャブラリや記述形式を表現するものである。DC-7での最も重要な点は DCMIとして認めたqualifierを2000年1月までにアナウンスする ことをアナウンスしたことであった。このほかには、今後Dublin Coreの開発を続けていく上でのバ ージョン管理に関する議論、実応用に即した議論を進めるためのワーキンググループの設置等がDC-7 での主たる話題であった。

　バージョン管理に関しては、現在決められている15エレメントからなる定義をバージョン1.1(DC 1.1) としている3)。これはいわゆるSimple Dublin Coreと呼ばれるもので、そこにはqualifierの定義は まったく含まれていない。今回承認されたqualifierのセットはDC1.1に対して決められたもので、 qualifierのセットそのものにはまだバージョンは与えられていない。現時点ではバージョンに関する 合意はまだ得られておらず、今後の議論によることになっている。

　ここでqualifierに関して少し解説する。DCMESの基本エレメントのみでメタデータを表そうとする と意味が十分に詳しく表現できないという要求が以前からあり、qualifierはかなり以前から議論され てきたものである。第4回ワークショップ（DC-4、オーストラリア国立図書館、1997年3月）では、 Dublin Coreをできるだけシンプルにとどめるべきとする考え方と、内容を正確に表現するためにエ レメントをより詳しく記述するための枠組みを入れるべきであるという考え方が議論された。（前者を minimalist、後者をstructuralistと呼んだ。）たとえば、論文の著者を著す場合、その人の「名前」、 「所属」といったことを表したくなる。また、ある資料に関する日付を表す日付（Date）エレメント を考えた場合、表されている日付が、この資料が「作られた日付」、「公開された日付」、「更新された 日付」、「無効になる日付」などいろいろな可能性がある。したがって、こうした日付の種類を明確に 表す記述方法が欲しくなる。また、主題（Subject）エレメントの場合、表された主題語がどのような 統制語彙、たとえばLCSHやMeSH、に基づいて表されているのかを書き表したい場合がある。この ように要素の表す意味をより厳密にしたり、要素に与えられる値の範囲を制約したりするために用い られるものがqualifierである。

　DC-7の後、エレメントを議論してきたワーキンググループからqualifierの提案が出され、それに関 する投票が進められた。最終的な投票はDC-7での計画より遅れ2000年4月に行われた。その後 qualifierの定義の表現方法を改めた後2000年7月に正式にアナウンスされた[4]。承認されたqualifier について次節で詳しく述べる。

3. qualifierについて

3.1 概要

　先に述べたように、基本15エレメントはDC-5で実質的に固定し、それ以降変更はされていない。 qualifierに関して、第6回ワークショップ(DC-6、アメリカ議会図書館、1998年秋)ではDumb-Down 原理が提案された。これは、次のようにqualifierを定義する際の原則を与えるものである。

Dumb-Down規則：
　qualifierを定義する場合、qualifierを含めて書き表したメタデータからqualifierを取り除いても値 とエレメントの間に矛盾が生じてはならない。

　qualifierの種類には、Element RefinementとEncoding Schemeの2種類がある。前者はエレメント の意味をより詳しく表すもので、後者はエレメントの値の表現方法を明示するものである。たとえば、 情報資源が作成された日付や出版された日付はElement Refinementにあたる。一方、日付を yyyy-mm-dd（年-月-日）のように表すための記述形式を指示するW3C-DTFや、LCSHやMeSHの ように件名（主題）を記述するための語彙を表す名前はEncoding Schemeと呼ばれる。

　Element Refinement qualifierとEncoding Scheme qualifierのより詳しい定義を下の段落に示す4）。

Element Refinement （エレメント詳細化） qualifier: これはあるエレメントの意味をより狭くある いは特化させるものである。qualifierによって詳細化されたエレメントは、より限定された範囲の意 味を表すとはいえ、qualifierを用いずに書かれたエレメントと共通の意味を持たねばならない。エレ メントの詳細化を意味するqualifierを理解できないクライアントの場合、qualifierを無視し、qualifier を持たないエレメント、すなわちより広い意味を表すエレメントとしてその値を処理できねばならな い。qualifierに関してエレメント詳細化の定義は公開されていなければならない。

Encoding Scheme （コード化スキーム）qualifier: これはエレメントの値の解釈を助けるために値の スキーム（体系、仕組み）を明示するためのqualifierである。このスキームには統制語彙（controlled vocabulary）や、形式的記述形式あるいは構文解析規則が含まれる。したがって、Encoding Scheme を用いて表された値は統制語彙から得たトークン（たとえば、分類システムや件名標目から得た語）、 あるいは形式的記述形式に適合するよう構成された文字列（たとえば、日付の標準形式として "2000-01-01"）である。あるEncoding Schemeをクライアントやエージェントが解釈できない場合で あっても、そうした値は人間の読者にとって有用である。Encoding Schemeの定義記述は明確に示さ れねばならず、かつ公開されていなければならない。

　DC-4以来のqualifierに関する議論の中で、構造を持つ値を表すqualifier（structured value qualifier） を含めて議論がなされてきた。たとえば、ある人を表すためにその人の名前、所属、連絡先を組にす ることが一般的に行われ、それに基づくqualifierも提案されてきた。しかしながら、最終的に structured valueはqualifierから除かれることになった。次段落に、Dumb-Downに関する説明と合 わせてstructured valueが除かれた理由を示す。

　たとえば、情報資源が作成された日付(Crated)と出版された日付(Available)を表すために下のように

	<Date><Created>2000-8-30</Created</Date>
	<Date><Available>2000-9-27</Available></Date>
と書いたとする。ここでCreated、AvailableはいずれもDateに対するqualifierである。このqualifier をとってしまうと、下のように日付の種類はわからなくなるが矛盾は生じず、それぞれの日付が何ら かの理由で当該資源に関連していることがわかる。
	<Date>2000-8-30</Date>
	<Date>2000-9-27</Date>
一方、作者(Creator)エレメントに関して、名前(Name)、所属(Affiliation)、連絡先(Contact)というサ ブエレメント（qualifier）を定義するとする。
	<Creator><Name>杉本, 重雄</Name></Creator>
	<Creator><Affiliation>図書館情報大学</Affiiation></Creator>
	<Creator><Contact>sugimoto@ulis.ac.jp</Contact></Creator>
この3つのサブエレメントのうち、名前は直接作者を表すものであるが、他の二つは作者に付随する 情報である。そのため、上と同じようにqualifierを取り去ると
	<Creator>杉本, 重雄<Creator>
	<Creator>図書館情報大学<Creator>
	<Creator>sugimoto@ulis.ac.jp<Creator>
となり、たとえば「図書館情報大学」が作者になってしまう。また、構造をより反映して
	<Creator>
		<Name>杉本, 重雄</Name>
		<Affiliation>図書館情報大学</Affiiation>
		<Contact>sugimoto@ulis.ac.jp</Contact>
	</Creator>
として表現した場合、
	<Creator>杉本, 重雄, 図書館情報大学, sugimoto@ulis.ac.jp</Creator>
というように書き直すことができるが、この場合は作者エレメントに表された文字列の解釈が問題に なる。

　structured valueを表すqualifierの場合、何らかの対象に関する要素情報を表すことになる。たとえ ば、「人」という対象の要素情報「名前」、「所属」、「連絡先」である。上の例で、「所属」は対象資源 に関する直接の要素情報ではなく作者である「人」の要素情報であるために、Dumb-Downがうまく いかなかったと言うことができる。一方、作者エレメントとしては「人」である何かを記述すればよ いので、次のような記述方法が考えられる。

Structured valueを含めないことにしたことは、これまでにワーキンググループから提案された qualifierの一部を否定することになった。また、この結論を導く上でResource Description Framework(RDF)が提案した情報資源記述のためのモデルが下敷きになっている5）。

表1　DCMI Qualifierの一覧
(http://purl.org/dc/documents/rec/dcmes-qualifiers-20000711.htmより)

DCMES Element Element Refinement(s) Element Encoding Scheme(s)
Title Alternative −
Creator − −
Subject− LCSH
MeSH
DDC
LCC
UDC
Description Table Of Contents
Abstract		 −
Publisher − −
Contributor − −
Date Created
Valid
Available
Issued
Modified		DCMI Period
W3C DTF
Type − DCMI Type Vocabulary
Format Extent −
Medium IMT
Identifier − URI
Source − URI
Language − ISO 639-2
RFC 1766
Relation Is Version Of
Has Version
Is Replaced By
Replaces
Is Required By
Requires
Is Part Of
Has Part
Is Referenced By
References
Is Format Of
Has Format		 URI
Coverage Spatial DCMI Point
ISO 3166
DCMI Box
TGN
Temporal DCMI Period
W3C-DTF
Rights − −

3.2 承認されたqualifierについて

　表1に承認されたqualifierの一覧を示す。また、以下に承認されたqualifierの定義を示す。 これに加えてタイプエレメントの統制語彙としてDCMIが用意したDCMI Type Vocabularyも示す。 これらはそれぞれ資料[4]と[6]の当該部分の翻訳である。 なお、下の記述において各qualifierに関して下記の属性を示す。 タイトル（Title）エレメント 主題（Subject）エレメント 内容記述（Description）エレメント 日付（Date）エレメント タイプ（Resource Type）エレメント フォーマット（Format）エレメント 資源識別子（Resource Identifier）エレメント 言語（Language）エレメント 関係（Relation）エレメント 時間的・空間的範囲（Coverage）エレメント 　Spatial、TemporalそれぞれにEncoding Schemeが定義されている。下にはそれぞれのEncoding Schemeを示す。
DCMI Type Vocabulary

　qualifierの承認と同時に、タイプエレメントを記述するのに用いる統制語彙を決めた。それがDCMI Type Vocabularyである[6]。DCMI Type Vocabularyに含まれる語は、Collection、Dataset、Event、Image、Interactive Resource、Service、Software、Sound、Textの９語である。以下に各語の定義を示す。なお、記述方法は上の方法に従う。

4. 今後の開発について

　はじめてのqualifierの承認が終わり一段楽した感じがある一方、将来に向けた話題として次のような 点が議論の対象となっている。

(1) バージョンについて
　現時点で基本15エレメントについてバージョン1.0と1.1があるが、これは参照記述の表現を改めた ものに過ぎないので実質的には単一のバージョンしか存在していない。また、qualifierセットに関し ても現時点ではひとつのバージョンしかない。今後、利用経験が増えるにしたがってエレメントや qualifierの改訂の要求が出てくることが考えられる。長期に渡るDublin Coreメタデータの安定した 利用を考えると、一貫したデータの利用を可能にするためのバージョン定義の必要性が認められてい る。しかしながら現時点では、バージョンの定義や今後のバージョンの管理の方針などについての結 論はまだ出ていない。

(2) qualifierの追加と今後の維持管理に関して
　今回承認されたqualifierは、Dublin Coreを利用するグローバルなコミュニティ全体にとって現時点 で共通して有用であるものであることを、DCMIとして認めたものである。今後のDublin Coreの利 用の拡大、利用経験の増加に基づき新しいqualifierの利用の要求が出てくることが予想できる。その ため、現時点では、qualifierを承認していくための下に示す3段階のプロセスがDCMIによって提案 されている。

こうした段階に加えてqualifierの中には利用されなくなり、無効であるとされるものもでてくる。

　コミュニティにおける新しいqualifierに関する合意の形成方法、それらのグローバルなコミュニティ への提案方法等、今後の実践の中で明らかになっていくものと思われる。たとえば、日本語で書くメ タデータの場合、名前の読みは必要な情報であるが、現在のqualifierには含まれていない。「読み」 を表すqualifierをグローバルなコミュニティで利用できるようにするには、日本語のメタデータを定 義、利用するコミュニティを形成し、そこでの議論を元にDCMIに提案する必要がある。

(3) レジストリに関して
　今後、Dublin Coreを長期にわたって実利用していくためには、Dublin Coreのエレメントやqualifier の定義を蓄積し、ネットワークを介して提供するサービスが必要とされる。そのサービスをDublin Coreレジストリと呼ぶ。Dublin Coreレジストリに格納されるデータには、DCMIがグローバルなコ ミュニティでの利用を推奨するものから、ローカルなコミュニティでの利用のみのものまである。そ のため、グローバルなコミュニティとローカルなコミュニティの両方に利用できるものである必要が ある。また、利用者は世界中に広がるので、各国語での提供も望まれる。エレメントやqualifierの定 義を各国語に翻訳するにはそれなりの時間がかかる。そのため、言語によって翻訳されたもののバー ジョンが異なることも有得る。こうした問題を議論するため、レジストリに関するワーキンググルー プが構成され、どのような機能が要求されるのかの議論を進めている。筆者等はレジストリに関する 研究開発を進めているが、それに関しては別稿[7]に任せたい。

5. おわりに

　最近、Dublin Coreに基づいてメタデータの枠組みを決めていることをしばしば耳にするようになっ てきた。その使い方もいろいろのようである。これは、Simple Elementとはいっても、15のエレメ ントそれぞれがかなり一般的に定義されているため、15エレメント全体ではカバーする範囲が広く、 個々の応用には必ずしも全てのエレメントが用いられないことを意味していると言えよう。また、 Dublin Coreに基づいて新たにデータを作ることはせず、Dublin Coreを異なるメタデータ規則に基づ くメタデータを横断的に見るための窓として利用することもできる。

　一方、教育用資料の場合に必要とされる「利用者の種類」を表すエレメントのように[8]、本質的に15 エレメントには含まれないものもある。こうした情報については現在のエレメント定義では扱えず、 Dublin Coreと他のメタデータ規則を組み合わせて記述しなければならない。こうした応用に依存し て必要とされる情報については複数の規則を組み合わせて記述していくことになるのであろうと筆者 は考えている。また、そうした応用ごとのメタデータ記述の規則を定義するapplication profileが必 要とされることになるのであろう。

　第8回ワークショップ（DC-8）は2000年10月、カナダ国立図書館で開催されることになっている。 これまでのワークショップが参加のための招待を必要としたのに対し、DC-8ははじめて一般に公開さ れたワークショップとなる。その意味ではこれまでとは異なり、Dublin Coreに基づくシステムの開 発者、利用者が集まるConference的色彩の会議となることが期待されている。一方、これまでOCLC を中心として草の根参加者によって支えられてきた組織を、今後の長期にわたる維持・運営に適した 組織に作り変えたいという動きもある。開発の開始から6年近く経過して利用が広がるとともに、変 わり目にあるように思われる。

参考文献

[1] Dublin Core Metadata Initiative, http://purl.org/dc/

[2] 杉本重雄, Dublin Coreに関する最近の話題から−第7回Dublin Coreワークショップほか, ディジ タル図書館（ISSN 1340-7287）, No.17, pp.32-36, 2000.2, http://www.dl.ulis.ac.jp/DLjournal/No_17/3-sugimoto/3-sugimoto.html

[3] Draft Standard Z39.85-200X The Dublin Core Metadata Element Set, http://www.niso.org/Z3985.html

[4] Dublin Core Qualifiers, http://purl.org/DC/documents/rec/dcmes-qualifiers-20000711.htm, 2000.7

[5] Resource Description Framework (RDF) Model and Syntax Specification, http://www.w3.org/TR/REC-rdf-syntax/, 1999.2

[6] DCMI Type Vocabulary, http://purl.org/dc/documents/rec/dcmi-type-vocabulary-20000711.htm, 2000.7

[7] 永森光晴他, RDF Schemaに基づくメタデータレジストリ, 情報学基礎研究会, 2000.9

[8] Education Working Group: Draft Proposal, http://purl.org/DC/documents/wd/education-20000430.htm, 2000.4

1) Dublin Coreと呼ぶ場合にメタデータのエレメントセットであるDublin Core Metadata Element Set (DCMES) を意味する場合と、Element Setの開発を行ってきた活動ならびにそれを支える組織であるDublin Core Metadata Initiative (DCMI) を意味する場合がある。ここでは明確に区別する必要がある場合には前者DCMES、後者をDCMIと呼んで区別する。

2) 制約子あるいは限定子と訳すのが適切とも思われるが、ここでは訳語は決めずにqualifierと記す。

3) DC 1.1とDC 1.0の間に意味的な違いはなく、表現が改訂されたのみである。4節でバージョンに関して簡単に触れる。

4) この段落は資料[4]の当該個所の訳である。

5) RDFの記述モデルは、資源、属性、値の3つ組みで記述するものである。たとえば、「この論文の著者は杉本重雄である」場合、資源＝「この論文」、属性＝「著者（作者）」、値＝「杉本重雄」である。「杉本重雄」が属性を持つ場合、たとえば、「杉本重雄の名前は"杉本, 重雄"である。」、「杉本重雄の所属は図書館情報大学である。」というようにとらえる。詳しくは資料[5]を参照されたい。