RDA のモデルと記述
DC アプリケーションプロファイルの観点から捉える
谷口 祥一（慶應義塾大学文学部）taniguchi@z2.keio.jp
１．はじめにRDA (Resource Description andAccess)1) は、記述とアクセスポイントの構成および記録にかかわる規則、正確にはガイドラインとインストラクションである。
これまでに筆者は、RDA を FRBR およびFRAD の観点から分析し、RDA は両モデルに依拠しつつも、独自の概念モデルを有すると捉えるべきことを明らかにした 2),3)。
この点から、RDA を大きくはモデルとそれに依拠した記述（記述とアクセスポイントの構成および記録にかかわるガイドラインとインストラクション）の部分に分けて捉えるべきことになる。本研究は、これら成果を踏まえて、RDA をより的確かつ構造的に理解する枠組みとして、DCMI（ダブリンコア・メタデータ・イニシアティブ）が提案する DC アプリケーションプロファイル（DCAP）およびその構成枠組みを示したシンガポールフレームワークの観点からRDA を捉えることを試みる。同時に、現在進行中の関連するプロジェクトとその成果を検討し、理解の構図に加える。
２．DCAP とシンガポールフレームワーク
DCAP とは、メタデータ作成上の必要事項の一式（エレメント集合、方針、ガイドラインなど）を定めた、広義のメタデータスキーマを指す。特にメタデータの必要な語彙定義と構造的な制約を分離することで相互運用性を確保することが意図されており、ダブリンコアへの適用に限定されない。
2008 年にシンガポールフレームワーク 4)が新たに提示され、DCAP の趣旨と構成がより明確化された。同フレームワークは、
DCAP が、a)機能要件（要求定義に相当）、
b)ドメインモデル（概念モデルに相当）、
c)記述セットプロファイル（DSP）、d)利用ガイドライン、そして e)構文ガイドラインから構成されることを明示している。また、これらが、ドメイン標準の層に位置づけられる、f)コミュニティ・ドメインモデ

ル、g)メタデータ語彙、h)DCMI 抽象モデ
ル、i)DCMI 構文ガイドラインと、それぞれどのように関係するのかを示している。
さらに基盤的な標準である j)RDF、k)RDFスキーマとの関係も示されており、結果的に Linked データへの道筋をも示している。
このフレームワークを RDA に当てはめ、構成の微調整を図った結果を図１に示す。
全体的には DCAP を RDA に当てはめることができる点が確認された。
1) 機能要件：RDA 0.0 Purpose and Scope、0.4.2 Objectives で示された内容が当てはまる。
2) モデル：RDA 独自のモデルを位置づけ、他方ドメイン標準の層に FRBR と FRADを位置づけ、RDA モデルはこれらに依拠している点を明示する。
3) 記述の構造定義と語彙定義：DSP に該当する部分を RDA 記述の構造定義とし、また RDA 語彙定義を DCAP の内部に位置づけ、ドメイン標準である FRBR/FRAD/ISBD の語彙を参照させている（詳細については後述）。なお、DCMI 抽象モデルは、メタデータの汎用的な構成を示すモデルであり、特定のドメインに依存しないため、図では基盤的標準に位置づけた。
4) 記述原則：RDA 0.4.3 Principles に挙げら れ て い る 原 則 （ Differentiation か らUniformity まで）は、記述の原則として新たに DCAP 内に位置づけた。
5) 構文ガイドライン：RDA では付録 D とE に規定されているのみであるため、図には含めていない。
6) 実際にレコード作成を行う、いわゆるRDA 実装の場面においては、レコードの構造規定（DSP に相当）、採用する記述処理規則（利用ガイドライン）の範囲等がより具体的に規定され、構文ガイドラインも導入されることになる。例えば、米国でのRDA 導入の当初段階では MARC21 修正版、
RDA への LC 適用細則、MARC21 フォー

マットがそれぞれ採用されることになる。
こうした構図を、図 1 に示したフレームワークは適切に表現することができる。
３．RDA 語彙定義とその課題語彙として登録されるものには、メタデータ記述に用いるプロパティ、クラス、構文エンコーディングスキームおよび語彙エンコーディングスキームがある。プロパテ
ィは、記述対象リソースの属性やリソース間の関連を表すもの（概念モデルでの実体の属性や関連に相当）であり、個々のプロパティに対して、それが属する定義域も、取り得る値の値域もともにクラス（共通した特性をもつリソースをグループ化したもの）をもって定義される。こうしたリソース（クラス）とプロパティの区別は RDFに依拠しており、RDF は基本的に「主語：リソース、述語：プロパティ、目的語：リソースまたはリテラル」という文を単位に構成している。なお、プロパティの取り得る値の構文を指定する構文エンコーディン
グスキーム、および値に用いる語彙を指定する語彙エンコーディングスキームも、こうした 2 分法ではクラスとなる。
これら個々のプロパティとクラスを定義するとは、記述言語である RDF スキーマ（または OWL を加え）を用いて定義を確定させていくことを指す。そこではプロパティ間、クラス間の上位下位関係を規定することなどが含まれる。また、一意に識別できるよう個々のプロパティ、クラスにURI を付与することを指す。
RDA 本体に基づく、こうした語彙定義作
業は、RDA 策定組織である JSC 自身ではなく、DCMI/RDA タスクグループが実施しており、現在 Open Metadata Registry5)を用いて登録・公開を進めている。そこでは、プロパティとして RDA エレメントに加えて、著作相互・表現形相互などの関連指示子（RDA 付録 J）、個人と著作の関連など、個人等の役割を示す関連指示子（RDA 付録 I）が登録されている。他方、クラスとしては、FRBR と FRAD の実体を始めとして、体現形のメディア種別（mediatype）、表現形の種別（content type）など、多数の種別とそれに属する個々のクラスが登録されている。
以上の状況にある RDA 語彙定義であるが、補足や検討が必要な事項を次に挙げる。
1) RDA にはエレメントとサブエレメント、エレメントサブタイプとの区別がある。エレ メ ン ト 「 出 版 事 項 （ PublicationStatement）」に対して、出版地、出版者、出版日付などがサブエレメントであり、他方、エレメント「タイトル」に対して、本タイトル、タイトル関連情報、異形タイトルなどがエレメントサブタイプとされている。後者のエレメントサブタイプは、エレメントとプロパティ→サブプロパティの上位下位関係にあり、RDF スキーマで表現できる。それに対して、エレメントサブタイ
プは、エレメントとは全体部分関連にあり、位置づけが異なる。それゆえ、サブプロパ
ティとするには若干違和感があり、後述する他の理由もあって、DCMI/RDA タスク
グループは、先の出版事項のようなエレメントについては、エレメントサブタイプと関係をもたない内容で登録している 6)。加えて、エレメントサブタイプを集めた擬似的なエレメントのまとまりを、後述の構造定義において指定している。
2)プロパティの大半は RDA モデルの属性 ・ 関 連 に 対 応 づ け ら れ る が 、 Source
consulted、Cataloguer's note、Status ofidentification などはモデルの属性や関連には対応せず、記述においてのみ出現する。
3)注記は対象となるエレメントからは独立したエレメントにまとめられているが、相互の関連（版表示と版にかかわる注記など）は定義中には示されていない。
4) RDA 語彙定義と、ドメイン標準であるFRBR/FRAD/ISBD 語彙定義との対応づけ、具体的には同一クラスまたは同一プロパティであることを示す方策が必要と考えられる。OWL を用いれば（OWL 自体にも Lite、DL、Full との３つのレベルがあるが）、owl:equivalentClass 、 owl:equivalent
Property、owl:sameAs などによる表現がありうる。
5) RDA 語彙自体をドメイン標準に位置づける考え方もあり、DCMI/RDA タスクグ

ループはこの方針を採用している。そのときには、標準語彙の一つとして使用できるよう、定義の自立性と充実が求められる。
４．RDA 記述の構造定義とその課題
メタデータの構造定義や制約の規定は、記述セットプロファイル（DSP）において行われる。規定する制約事項と XML によるコーディング法が提案されているが、草案の段階にあり、確定はしていない 7)。また、同案の制約事項が十分ではないとして、わが国のメタデータ情報基盤構築事業では独自の制約記述を提案している 8)。ただし、本稿で論じる範囲においては、いずれも同じ記述力をもつと考え、DCMI による前者の規定のみ取り上げる。
DSP は、１つまたは複数の「記述テンプレート（Description Template）」から構成され、それぞれのテンプレートが記述対象とする単一のリソースに関する制約条件を指定する。そして、単一の記述テンプレー
トが、１つまたは複数の「文テンプレート（Statement Template）」から構成される。
個々の文テンプレートは、対応するプロパティごとに制約を指定し、値がリテラルか否かに従い「リテラル文テンプレート」と「非リテラル文テンプレート」に分かれ、それぞれの制約をさらに指定する。プロパ
ティの値域は語彙定義においても、そのクラスを指定することができるが、値のより詳細な制約条件指定は DSP において行うことになる。なお、こうした DSP 自体の構成は、メタデータの汎用的な構成を規定した DCMI 抽象モデルにそのまま合致する。
JSC が公開している文書 RDA Element
Analysis は、DCMI 抽象モデルに沿ってRDA の各エレメントについて、その定義域、値がリテラルか否か、値文字列がプレーン値か型付き値か、構文または語彙のエンコーディングスキームが適用されるか、適用されるときにはそのスキーム名を明らかにしている 9),10)。これをそのまま RDA 記述の構造定義、すなわち DSP の文テンプレー
トに流用することができ、これによって制約の主要部分が決まることになる。コアエ
レメントか否か、エレメントの繰り返しが可能か否か等をこれに追加して指定すれば、十分な構造定義の規定となろう。
以上の RDA 記述の構造定義について、補足や検討が必要な事項を次に挙げる。
1) 語 彙 定 義 の と こ ろ で 言 及 し た 通 り 、RDA サブエレメントの集合である擬似的なエレメントを、DCMI/RDA タスクグループは、構文エンコーディングスキームによって表現しようとしている。そのために該当する構文エンコーディングスキームをクラスとして語彙定義に加えており、DSPにおいては、非リテラル文テンプレートの値文字列制約において当該構文エンコーディングスキームを指定することになる。ただし、クラスとして登録された構文エンコーディングスキームにおいては、実際にエンコーディングが可能な構文までは示されていない。むしろ、記述テンプレートの階層構造（語彙定義における階層構造ではなく）をもって、このエレメントとサブエレメントをプロパティ→サブプロパティの関係として表現するのが素直な方式であると筆者は考える。
2) 全 体 部 分 関 連 に あ る リ ソ ー ス の 体 現形・個別資料の記述タイプ（RDA 1.5）として、完結型（comprehensive）、分出型（analytical）、階層型（hierarchical）が規定されている。
これらを DSP で指定するには、別個の DSP とするか、単一 DSP で表すかという選択肢があるが、後者については複数の記述テンプレートの排他的論理和が表現できなければならない。個々のテンプレートの最小出現回数を'0'と指定するだけでは、通常の論理和となり、排他的論理和とはならない。同様に、著作・表現形・体現形のリソースタイプごとの記述の構成についても、別個の DSP とするか、単一 DSP で表すかという選択肢があり、後者については上記の問題がある。なお、川向らによる日本目録規則の DSP では、別個のDSP を設けるとの選択肢を採用している
11)。同様に、文テンプレートにおいて、値がリテラル値と非リテラル値の排他的論理和である場合の指定についても、同じ問題がある。なお、DCMI 抽象モデルもこうした表現力は備えていない。

Classification Quarterly. 2012, in press.
3) 谷口祥一. RDA を FRBR/FRAD から見る：
RDA は新たなモデルか？ 2012 年日本図書館情報学会春季研究集会発表要綱. 2012,p.125-128.
4) Mikael Nilsson, et al. The Singapore
Framework for Dublin Core Application
Profiles. 2008. http://dublincore.org/
documents/singapore- framework/5) Open Metadata Registry.
http://metadataregistry.org/
6) Diane Hillmann, et al. RDA vocabularies:
process, outcome, use. D-Lib Magazine,
16(1/2), 2010. http://dlib.org/dlib/january10/
hillmann/01hillmann.html
7) Mikael Nilsson. Description Set Profiles: A
constraint language for Dublin Core
Application Profiles. 2008.
http://dublincore.org/documents/dc-dsp/
8) メタデータ情報基盤構築事業報告書. 2010.
http://meta-proj.jp/metaproj2010.pdf
9) JSC. RDA Element Analysis (1 July 2009).
http://www.rda-jsc.org/docs/5rda-elementan
alysisrev3.pdf10) JSC. RDA Element Analysis Table, April
2012. http://www.rda-jsc.org/docs/6rdaelement-analysis-table.pdf
11) 川向直樹ほか. 日本目録規則の Application
Profile 化に関する研究. 情報処理学会情報学基礎研究会報告. 2010-IFAT- 100(6), p.1-8,
20103) 同一プロパティの繰り返し出現が認められているとき、値の出現順序を DSP で指定する機能がない。RDF によるインスタン
スレベルの記述ではコンテナ（'seq'）を用いて表現できるが、DSP の文テンプレート
そして DCMI 抽象モデルでは表現できない。
５．まとめ
上述した語彙定義そして構造定義にかかわる問題のいくつかは、これまでのレコードという記述の単位（パッケージ）の考え方を放棄するのか、部分的にでも保持するのか、保持するときにはどのような方式とす る の か と い う 点 に か か わ る 。 RDF 、
Linked データ、そしてセマンティック Webの考え方が、メタデータ記述は文単位で適宜組み立てかつ流通させるという指向性をもつとするならば、その点において、せめぎ合いがあるといえよう。
引用文献
1) The Joint Steering Committee forDevelopment of RDA. RDA: Resource
Description and Access. Chicago, American
Library Association, 2011.
2) Shoichi Taniguchi. Viewing RDA fromFRBR and FRAD: Does RDA represent adifferent conceptual model? Cataloging &RDAアプリケーションプロファイル
RDAモデル RDA記述

基づく

基盤的標準

RDA記述
指示する 処理規則

RDA語彙
定義

用いる

用いる

FRBRモデル
FRADモデル

FRBR語彙
FRAD語彙基づく
ISBD語彙

基づく

基づく

基づく

RDFスキーマ/
OWL
基づく

図１

RDA記述
構造定義

支えるRDAモデル
基づくドメイン標準

支える

用いる

基づく

RDA機能要件

RDA記述原則

RDF

基づく

RDA アプリケーションプロファイル

DCMI抽象モデル