目的と進め方

杉本重雄
知的コミュニティ基盤研究センター
図書館情報メディア研究科
筑波大学• メタデータに関する自由な議論がしてみたい• メタデータそのものの概念はとても広いので、はじめは、メタデータについての基本概念を述べ、つづいて、本研究室で扱っているメタデータについて述べる。
• そのあと、筆者にとっての最近の研究的に関心のあるトピックをいくつか挙げて、議論した
いメタデータ

メタデータ

メタデータについて議論してみよう

記述の視点

なにかA

• メタデータの例
Aについて書いたもの「Aについて書いたもの」
について書いたもの– レストランのメニュー、おもちゃに書いてある想定利用者の年齢、ソフトウェアの利用条件、食品の内容、お店の看板など、いろいろ• 筆者の研究室で扱ってきたメタデータ– 情報資源の記述と発見のためのメタデータ
別の視点• 目録、書誌情報のようなもの

Aについて書いたもの– 利用者、利用者環境の特性のメタデータ– 資源の保存のためのメタデータ• 主にメタデータの記述規則に関する研究

メタデータとメタデータスキーマ• メタデータを書くためには記述規則が必要• メタデータの記述規則– 形式を決める– 実際に記述の指針を決める• メタデータスキーマ
メタデータの記述形式を決めるもの

メタデータスキーマについて：具体表現の例
Title (en)Digital Library Researches in Tsukuba:

Creator (en)Sugimoto, Shigeo

Creator (ja)杉本, 重雄Subject (en)Metadata Schema

Subject (en)Interoperability

Publisher (en)Shanghai Library

Publishing Location (en)Shanghai, China

Date (ISO-8601)

2004-10-13

Language (ISO-639)

en（pronunciation: すぎもと, しげお）

Metadata DB(Catalog DB)

1

メタデータスキーマについて：具体表現の例<dc:title> Digital Library Researches inTsukuba:</dc:title><dc:creator> Sugimoto, Shigeo</dc:creator><dc:creator xml:lang=“ja”><rdf:value>杉本, 重雄 </rdf:value><uliscore:pronunciation>すぎもと, しげお</uliscore:pronunciation></dc:creator>…

メタデータスキーマを考える：構造的な制約実現形式には依存しない制約

Title: Mandatory
Creator: Mandatory if Applicable, Repeatable
Subject: Optional, Repeatableetc.
Metadata DB(Catalog DB)

メタデータスキーマを考える：エレメント
基本的要素（記述項目と値の語彙）

Application Profile

Title
Element Name: Title
Label: Title
Definition: A name given to the resource.
Comment: Typically, Title will be a name by which
the resource is formally known.
CreatorElement Name: Creator
Label: Creator
Definition: An entity primarily responsible for making
the content of the resource.
Comment: Examples of Creator include a person, …

メタデータスキーマを階層的に見てみるとLayer 3Concrete
SyntaxLayer 2
Abstract
SyntaxLayer 1
Semantics

XML
implementationin an XML
SchemaDCMI Library
Application
ProfileDCMES(ElementsandQualifiers)

An Oracle
implementation

Open
Archives
Initiative
SchemaIEEE-LOM

termA:
Mandatory

termA

termB

termC

Metadata Vocabulary 1(Metadata Element Set)

termXtermZ:
Mandatory
if applicable

termZ

termY

Metadata Vocabulary 2(Metadata Element Set)

A structural view of application profile

Application Profileと相互運用性
Element Set B

Element Set A

RDF
implementation

IPL Asia
SchematermC:
termX:
Optional
Mandatory
Repeatable Repeatable

ULIS
Core
SchemaULIS
elementextension

M

O

M

Application Profile X

OO

M

M

O

Application Profile Y

Layered Model of Metadata Schema

2

Application Profileと相互運用性
Q is a refinement of P.

階層モデルと メタデータスキーマレジストリ
Layer 3Element Set B

Element Set A

Q

P

Layer 2

Application Profile A

Application Profile B

Layer 1

Registry A

M

OM

OO

M

M

Element Set A
e.g. Dublin
Core Metadata
Element SetO

Application Profile Y

Application Profile X

Registry B

Element Set Be.g. Tsukuba
Element Set

ULIS-DL
Subject
Vocabulary

Shared Element between X and Y

階層モデルと メタデータスキーマレジ
ストリ

主題語彙に関して• ULIS-DLの経験から

Layer 3

Implementation Syntax A1
for Application Profile A

Implementation Syntax A2
for Application Profile A

Layer 2

– 中味を一覧できるようにしたい– 適切な見出し語を用意したディレクトリが作りたい– 収集したリソースに対し、既存の語彙（分類、件名標目表）は適用しやすくない

Registry
Layer 1

Application Profiles
Metadata Terms

ULIS-DLでの主題語彙の評価• ２００３年までに作られたメタデータのSubjectエレメントから取り出したキーワード（生データで約16000語）を正規化後、何語でどれだけのメタデータ件数をカバーできるかを評価してみた。
キーワード

カバーできなかった
メタデータ件数

非カバー率

CTS-239791519

6%

CTS-3

2045

2083

8%

CTS-4

1366

2590

10%

CTS-51025

2801

11%

岡山県立図書館のデジタル岡山大百科• デジタル岡山大百科– 県立図書館による地域ポータル– 図書館員のほか教員や地域のボランティアも参加– Simple Dublin Coreを基礎– 主題分類の語彙• NDC• 子ども分類• 夢作り分類3

子ども分類

主題分類の語彙の比較• ひとつの概念に対して複数のラベル• NDCと子ども分類、夢作り分類の比較• 主題分類はディレクトリを作るのに必要– Web上で発信される資料に対してNDCは必要か“としょかん”“図書館（トショカン）”senior graderselementary school

junior graderselementary schoolpresentation labels“Library”– 独自に分類を作ると後のメインテナンスが大変

presentation labels
a subject term

“図書館”

“図書館”

junior high school

high school and above

分類の比較（子ども分類＝KV、夢作り分類＝PV）

Distribution of Terms in the NDC term space- Okayama’s Case -NDC

000 100 200 300#Kidsterms

1788196 58

54

#NDC
in KV

7734427

#Pref
terms

152

#NDC
in PV

42400 500 600

700800900

total

NDC

000 100 200 300

286266443

#Kids
terms

1788196 5854

27202644169

#NDC
in KV

77344

27

12 171 3056441711349

#Pref
terms

152518251511116

#NDC
in PV

423411400 500 600

700

800

900

total

28626644327202644169

12 171 3056441711349

51825

15111163411

NDC: 000=総記, 100=哲学, 200=歴史, 300=社会科学, 400=自然科学,
500=技術・工学・工業, 600=産業, 700=芸術, 800=言語, 900=文学

NDC: 000=総記, 100=哲学, 200=歴史, 300=社会科学, 400=自然科学,
500=技術・工学・工業, 600=産業, 700=芸術, 800=言語, 900=文学

主題分類の比較

自治体の分類の語彙の比較
Web上に出ている分類表から行政リソース（県のWebページなど）

夢作り分類

子ども分類

社会科学
技術・工学・工業
産業

教育学習リソース

自然科学
芸術

NDC

茨城県

香川県

神奈川県

岡山県

トップレベル

23

1114

16

深さ2223

語数115+82

88

280+

網羅的

一般のリソース

4主題語彙について• 対象領域にあった主題語彙がほしい• 作ること、メンテすること、再利用することをできるだけ簡単におこないたい

Identifierは何を指す？
• ISBNの場合– 本につけられた番号• 書棚に並べられた一冊一冊の個々の本ではなく、出版物としての1点に対して与えられる。

• 電話番号の場合– 回線につけられた番号• 電話機につけられた番号ではない– 転送される場合もあり、実際にどこにつながるかはわからない。

Identifierは何を指す？

FRBRによる実体間関係のモデル
メタデータの記述対象は何か？

• URLの場合• Identifierは、それを解釈するもの（resolver)があってはじめて意味を持つ。

「蜘蛛の糸」という作品, 「蜘蛛の糸」の子供向けの作品

Work– ＜プロトコル＞＜ドメイン＞＜ドメイン内の場所・パラメータ＞– ドメイン名はIPアドレスに対応付けられている– ＜ドメイン内の場所・パラメータ＞の部分の解釈はサーバに任される。

is realized through「蜘蛛の糸」の冊子（図書）向けの表現、電子版向けの表現

Expression
is embodied in

Manifestationある出版社からだされた本（ISBNで表される1点の図書）、ビデオ

Item

is exemplified by

本の一冊一冊、ビデオの一巻一巻「何」に対してメタデータを書くか

Identifierは何を指す？

• IFLAのFRBRモデル
identifier– 書誌記述のためのモデル– 4段階でとらえる• Work： 表現を限定しないで識別でされる作品• Expression： Workをなんらかの方法で表現したもの• Manifestation： Expressionを何らかの媒体上に実現したもの• Item： Manifestationの個別の実体

aResource

FRBR
WorkWorkWork

Expression

Expression

Expression

Manifestation
Item

Manifestation
Item

Manifestation
Item5

aResource

OpenURL
identifier

OpenURL framework
Context Object

ActualResource A

aResourceaResource
identifier

ActualResource B

Context

実際にアクセスする先はContextに依存する。

Resource Aidentifier

誰が、どこから、どこを介して、どのようなサービスを求めて、アクセスしているか。

Resource B

OPACを用いる際の検索パラメー
タを編みこんだURLと考えよう。

ActualResource C

Resource C

OpenURL framework

Combining FRBR and OpenURL framework: an example

aResource
OpenURL framework
Context Object

ActualResource A

identifier

ActualResource A

ActualResource B

Context
Context Object
Characteristics of User
Language
CulturePhysicalCharacteristics of User Environment
DeviceNetwork
Physical Environment (in/out-door, etc.)
Intellectual Property Conditions

ActualResource C

Context

Context

ActualResource B

Work
Manifestation

Manifestation
Expression

ActualResource C

Characteristics of UserCharacteristics of User EnvironmentIntellectual Property Conditions
etc.

Manifestation
Expression

Expression

identifier

ActualResource B
ActualResource CaResource
ActualResource A

Manifestation
Expression

identifier+Work

aResource

Manifestation

Choose appropriate
entity in accordancewith user’s
characteristics andpreference.

Manifestation

Accessibility, FRBR, OpenURL• Accessibilityを良くするには、利用者、利用環境に応じて、最も適切なリソースを探し出し、適切に提供することが必要である。
• OpenURLはコンテキストにあったアクセスのための基本モデルを与えてくれる• FRBRは「同じ内容」のリソースの間の関係を与えてくれる• Accessibility Metadataは利用者、利用環境の特性の記述の枠組みを与えてくれる• これらをくみあわせてみればどうなるか？

6メタデータについて議論してみよう• メタデータはどのようにつくる• メタデータの語彙– エレメントセット– 主題語彙、分類• メタデータスキーマのモデルとレジストリ– Global Interoperability vs. Domain Specificity– 相互運用性とSemantic Webの技術

メタデータはどのように作る?
• メタデータの作り方– 専門家による（Librarian/Cataloger model)– 機械による(Software-generated Metadata model)– リソース作成者による(Submission model)• 専門家による作成は高くつき、大量のものを作ることが難しい• ソフトウェアによる作成は品質に問題• リソース作成者によるものは、品質の問題が残る• そのほか

主題語彙の問題• 大きな語彙vs小さな語彙– Dublin Coreは小さな語彙– 大きな語彙(MPEG7, MARC, etc.)• 主題語彙に関する素朴な疑問

メタデータスキーマのモデルとレジストリ• 相互運用性はメタデータのキーワード– 相互運用のために共通化を進めたい– 応用毎にできるだけ適した記述をしたい• Application Profileの役割– 図書館でよく使われる語彙はそのままでWebリ
ソースに使えるか– 素人利用者に使いやすいか– 見せ方をうまくできないか– いろいろなエレメントセットから必要な項目を取り出せる– 異なるスキーマを組み合わせる際のキー

メタデータスキーマのモデルとレジストリ

その他• Semantic Webの技術– メタデータスキーマのベースは語（語彙）の定義– 定義した語を共有したい– 定義した語を再利用したい– 定義した語をメンテナンスしやすくしたい– Dumb-downとCrosswalkのための仕組み• Dublin Coreのはたした役割– Dublin Coreはシンプルなメタデータとして有名になった• 「15項目だけ!」• 本当にシンプルか?

– Application Profileは重要な概念• RDFと組み合わせることで、メタデータの相互運用性を支える基盤概念– 日本国内で求められるものは?
• （頼りになる）翻訳？
• 組織?

• そのほか7