うっかり書き途中でpostしてしまい，一部のRSS Readerでは拾われてしまったかもしれません．こちらが本postです．
先日，久しぶりにディジタル図書館ワークショップに行ってきました．お目当ては何といっても
筑波大・
杉本重雄先生による「Dublin Coreの現在」．午後から別件があったので，今回は午前中のみの参加です．
Dublin Coreの話以外にもマンガメタデータとか研究者リゾルバとか面白そうなネタはたくさんありました．今回は割愛しますが，多分近日中に
「ディジタル図書館ワークショップ」情報に掲載されると思われますので，ご興味のある方はそちらをチェックしてみてください．
以下，Dublin Coreに関するメモです．やはり第一人者のお話を聞ける機会は少ないので非常に楽しく，勉強になりました．なお，メモはryojin3の理解によるところが大きいので，詳細は予稿集でお確かめ下さい．
■おさらい
- メタデータとは
- Data about data，Structured data about data
- 記述対象となる情報資源に関して，決められた属性についてその属性値を書き表したもの
- メタデータの記述規則（メタデータスキーマ）
- メタデータの作成の実際
- 具体的な表現形式を決める
- 記述対象からどのようにして値を抽出するかについての抽出基準を決める
■Dublin Coreの歴史（規格開発系）
(1)開発初期 - 15エレメントの標準化まで
- 1995年アメリカオハイオ州ダブリン
- 当初13個のエレメント，すぐに15個に拡張
- 最小公倍数的メタデータよりも最大公約数的メタデータを目指した
- ResourceはDocument Like Object（DLO，文書様の実体）と呼ばれていた
- 1996年イギリスウォーリック
- Warwick Frameworkが提案
- 以下はWarwick Frameworkの概念図です．この画像は杉本先生の論文を元に，ryojin3が転記しました
- Warwick Frameworkは各メタデータ基準（パッケージ）を1つのコンテナに入れるモデルが提案
- 応用目的に合わせて詳細な記述能力を持つメタデータ基準とDCの組み合わせ
- 1997年オーストラリアキャンベラ
- RDFの開発が進んだこともあり，構造表現はRDFにまかせ，構造表現を「持たない」合意がなされる
- 1997年フィンランドヘルシンキ
- Simple Dublin Core（「どのエレメントも繰り返し可能であり，かつ省略可能である」という要件を持つDC）の合意
- 1998年以降（Simple Dublin Coreの標準化）
- 現在のDublin Core1.1
| element | element(和) | Namespace |
|---|
| contributor | 寄与者（他の関与者） | http://purl.org/dc/elements/1.1/contributor |
| coverage | 対象範囲（空間的・時間的） | http://purl.org/dc/elements/1.1/coverage |
| creator | 著者あるいは作者 | http://purl.org/dc/elements/1.1/creator |
| date | 日付 | http://purl.org/dc/elements/1.1/date |
| description | 内容記述 | http://purl.org/dc/elements/1.1/description |
| format | 形式（フォーマット） | http://purl.org/dc/elements/1.1/format |
| identifier | 資源識別子 | http://purl.org/dc/elements/1.1/identifier |
| language | 言語 | http://purl.org/dc/elements/1.1/language |
| publisher | 公開者（出版者） | http://purl.org/dc/elements/1.1/publisher |
| relation | 関係 | http://purl.org/dc/elements/1.1/relation |
| rights | 権利管理 | http://purl.org/dc/elements/1.1/rights |
| source | 情報源（出処） | http://purl.org/dc/elements/1.1/source |
| subject | 主題あるいはキーワード | http://purl.org/dc/elements/1.1/subject |
| title | タイトル | http://purl.org/dc/elements/1.1/title |
| type | 資源タイプ | http://purl.org/dc/elements/1.1/type |
(2)Qualified Dublin Coreの導入，そして更なる概念の明確化
- 属性の意味の詳細化
- 日付（一般化）は出版日付か受付日付か有効期限の日付か（詳細化）
- 属性値の記述形式の指定
- 日付は 平成21年3月10日か2009-3-10か10/3/2009か
- QDC：Qualified Dublin Core
- 2000年7月にQDCのエレメントセットが決定
- (a)新しい基本属性の導入
- (b)既存の属性の意味を詳細化する限定子の導入
- (c)属性値の記述形式を指定する限定子の認定
- (a)←→(b)は限定子を取り除けばもとの記述に戻せるDumb-down原則に基づく
- その後
- 意味の詳細化としてRDFSが整備され，QDCは使われなくなった
- 意味の詳細化された属性→「形容詞部分を含む名詞」として属性が定義されていく
- 符号化形式を表す限定子→値の型を表す属性として定義されていく
(3)Application Profileの概念の明確化
■Dublin Coreの歴史（団体(DCMI)系）
(1)開発の初期（～1998年頃まで）
(2)標準化の進展（～2003年頃まで）
- 組織化
- Executive Director，Advisory Board，Usage Boardの整備
- DCMI Metadata RegistryはOCLCから筑波大に移管
- 議論の場
(3)組織としての独立
- 資金の提供：各国の代表機関がLocal Affiliateとなり，資金提供し，DCMIを運営
■Dublin Coreの基本15エレメントの再定義
基本的な問題
- Agentエレメントの導入（1998年，反映されず）
- Creator，Contributor，Publisherの3エレメントをまとめたもの
- 3エレメントの意味の違いが明確でなく，かつ15エレメントが広く流通しているので反映されなかった
- SourceエレメントとRelationエレメント
- SourceエレメントはRelationエレメントを詳細化したものだが，同じレベルで扱われている
- 名前空間
- RDF Schemaにおける名前空間とSimple Dublin Coreの名前空間が統合されないままでいる
再定義
■Abstract Model
- Resource Model
- リソースの記述がどのような要素から成り立っているかを示す
- リソース（described resource）は属性（property）と属性値（value）の対（property-value pair）からなる
- 以下の図はDCMIのサイトから転載しました
- Description Set Model
- メタデータがどのような要素から成り立っているかを示す
- (1)メタデータの実体（record）は1個のdescription setでできている
- (2)1個のdescription setは1個以上のdescriptionが含まれる
- (3)1個のdescriptionは記述対象のリソースへの関連付け（described resource URI）と1個以上の文（statement）を持つ
- (4)1個の文（statement）は属性（property）と属性値（value）の対（property-value pair，Resource Modelに対応）からなる
- (5)属性値（value）はリテラル（literal value surrogate, 文字列）の場合と非リテラル（non-literal value surrogate，統制語彙か何らかのリソース）の場合がある
- 以下の図はDCMIのサイトから転載しました
- Vocabulary Model
- DCメタデータの語彙に含まれる語の性質とそれらの間の関係を示す
- 語彙（Vocabulary）に含まれる語（term）は，以下の4つのいずれかとなる
- 属性（property，domainとrangeをclassに与える）
- クラス（class）
- 符号化の構文（syntax encoding scheme）
- 統制語彙（vocabulary encoding scheme）
- 以下の図はDCMIのサイトから転載しました
■Application Profileの定義
- Singapore Framework（Application Profileのフレームワーク）
- 具体的なシステムやサービスの機能，メタデータ実体，その制約等を明確にするための定義
- 以下の図はDCMIのサイトから転載しました
- Functional Requirement
- Application Profileによって定義されるシステムやサービスにおいて，実現することが必要とされる機能を定義する
- Domain Model
- Application Profileによって定義されるシステムやサービスに含まれる基本的な実体と実体間の関係を定義する
- Description Set Profile
- Application Profileによって定義されるシステムやサービスにおいて，メタデータの実体（レコード）の構造制約を定義し，適用対象メタデータの妥当性を検証できるようにする
- Usage Guidelines
- Application Profileの応用方法や属性の提供方法について示す
- Encoding Syntax Guidelines
- Application Profileで示されるメタデータスキーマを特定のシステムやサービスで実現するためのコード化方法やコード化のためのガイドラインを示す
■まとめ
- この4～5年の進捗
- 基本15エレメントの再定義
- DCMIには他に約70のエレメントが登録されている
- Application Profileの概念の整理
- Semantic Interoperability（メタデータの意味的相互運用性）を得るための仕組み
- DCAMによる基礎概念の定義と関係性の明確化
- Application Profileの概念の明確化と形式的表現の実現
- レジストリの重要性
- Application Profileの広がりは，アリモノの利用にあるので，アリモノを見つけるための仕組みとしてメタデータレジストリが重要
- スキーマの共有と利用するためのコミュニティの活性化が重要
