デジタルコンテンツのアノテーション基盤技術とそれに基づ …web.nagao.nuie.nagoya-u.ac.jp/papers/pdfs/kaji_doctoral...4.6 MusicXML における楽器パートの記述.....75

デジタルコンテンツのアノテーション

基盤技術とそれに基づく音楽情報処理に関する研究

梶克彦

名古屋大学大学院情報科学研究科

2007年1月

i

目次

概要 1

第 1章序論 5

1.1 背景 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.1.1 アノテーションに関する研究動向 . . . . . . . . . . . . . . . 7

1.1.2 音楽に関するメディア形式とアノテーションの研究動向 . . 11

1.1.3 音楽コンテンツの応用に関する研究動向 . . . . . . . . . . . 13

1.2 本論文の目的 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1.3 本論文の構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

第 2章任意のコンテンツに対するアノテーション基盤 17

2.1 任意のコンテンツに対するアノテーションについての問題点 . . . . 18

2.2 ElementPointer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.2.1 ElementPointerの形式 . . . . . . . . . . . . . . . . . . . . . 20

2.2.2 ElementPointerプロセッサ . . . . . . . . . . . . . . . . . . . 24

2.3 Annphony . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.3.1 構造と解釈のためのアノテーション形式 . . . . . . . . . . . 24

2.3.2 アノテーション定義に基づくアノテーション管理 . . . . . . 26

2.3.3 Annphonyの機能 . . . . . . . . . . . . . . . . . . . . . . . . 32

2.4 アノテーションが持つ諸問題に関する考察 . . . . . . . . . . . . . . 34

2.4.1 埋め込み式アノテーションと外部アノテーション . . . . . . 34

2.4.2 Orphan/Misleading Annotationへの対処 . . . . . . . . . . . 35

ii

2.5 実装 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

2.6 Annphonyと各システム間の関係 . . . . . . . . . . . . . . . . . . . 36

2.7 Annphonyがもたらす効果 . . . . . . . . . . . . . . . . . . . . . . . 38

2.8 本章のまとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

第 3章音楽アノテーションシステム 41

3.1 音楽アノテーションの獲得 . . . . . . . . . . . . . . . . . . . . . . . 41

3.2 音楽アノテーションシステムの機能 . . . . . . . . . . . . . . . . . . 43

3.2.1 Annphonyの利用 . . . . . . . . . . . . . . . . . . . . . . . . 45

3.2.2 Web ブラウザを通したアノテーション . . . . . . . . . . . . 45

3.2.3 3種類のアノテーションエディタ . . . . . . . . . . . . . . . 46

3.3 連続メディアの構造化支援 . . . . . . . . . . . . . . . . . . . . . . . 56

3.4 システム構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

3.5 多様な解釈の顕在化に関する実験 . . . . . . . . . . . . . . . . . . . 58

3.5.1 実験方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

3.5.2 実験の結果と考察 . . . . . . . . . . . . . . . . . . . . . . . . 59

3.6 本章のまとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

第 4章楽曲の解釈・構造を用いたアプリケーション 65

4.1 検索・再構成システムのためのアノテーション定義 . . . . . . . . . 65

4.2 楽曲検索システム . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

4.2.1 検索システムのインタフェース . . . . . . . . . . . . . . . . 66

4.2.2 キーワード検索 . . . . . . . . . . . . . . . . . . . . . . . . . 67

4.2.3 コード進行に基づく検索 . . . . . . . . . . . . . . . . . . . . 67

4.2.4 個人の感性に適応する検索 . . . . . . . . . . . . . . . . . . . 68

4.2.5 楽曲の構成に基づく絞込み検索 . . . . . . . . . . . . . . . . 69

4.3 楽曲再構成システム . . . . . . . . . . . . . . . . . . . . . . . . . . 70

4.3.1 楽曲再構成システムのインタフェース . . . . . . . . . . . . 70

iii

4.3.2 楽曲再構成システムの実装 . . . . . . . . . . . . . . . . . . . 71

4.4 本章のまとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

第 5章コミュニケーションメディアとしてのプレイリスト 77

5.1 プレイリスト作成支援システムのためのアノテーション定義 . . . . 79

5.2 歌詞とアノテーションによる楽曲・ユーザ間の類似度推定 . . . . . 80

5.3 プレイリスト作成支援システム . . . . . . . . . . . . . . . . . . . . 82

5.3.1 協調フィルタリングによる基プレイリストの絞込み . . . . . 83

5.3.2 基プレイリストの個人への適応 . . . . . . . . . . . . . . . . 85

5.3.3 インタラクションによるプレイリスト更新 . . . . . . . . . . 86

5.3.4 プレイリストの人手による編集 . . . . . . . . . . . . . . . . 86

5.3.5 インタラクション内容に基づくユーザモデルの更新 . . . . . 88

5.4 プレイリストを介したコミュニケーション . . . . . . . . . . . . . . 89

5.5 ユーザモデルの適応に関する評価実験 . . . . . . . . . . . . . . . . 91

5.5.1 実験方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

5.5.2 実験の結果と考察 . . . . . . . . . . . . . . . . . . . . . . . . 92

5.6 本章のまとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

第 6章関連研究 95

6.1 マルチメディアアノテーション . . . . . . . . . . . . . . . . . . . . 95

6.2 音楽アノテーション . . . . . . . . . . . . . . . . . . . . . . . . . . 97

6.3 コミュニケーションシステム . . . . . . . . . . . . . . . . . . . . . 99

第 7章結論 102

7.1 まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

7.2 今後の課題 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

7.3 将来展望 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

7.3.1 CGMサービスの拡張 . . . . . . . . . . . . . . . . . . . . . . 106

iv

7.3.2 マッシュアップコンテンツ . . . . . . . . . . . . . . . . . . . 107

謝辞 108

参考文献 110

研究業績 117

v

図目次

1.1 コンテンツとアノテーションの関係 . . . . . . . . . . . . . . . . . . 7

1.2 MPEG-7の記述例 . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.3 RDFのデータ構造 . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.4 アノテーションの枠組みの間の壁 . . . . . . . . . . . . . . . . . . . 10

2.1 同一のリソースに対する解釈の多様性 . . . . . . . . . . . . . . . . 20

2.2 XMLドキュメントの内部ノードのXPointerによる指示 . . . . . . . 21

2.3 MIDIファイルの時間区分 . . . . . . . . . . . . . . . . . . . . . . . 23

2.4 Named Graphs(左)とAnnphonyアノテーション (右) . . . . . . . . 27

2.5 RDF SchemaとRDFの関係 . . . . . . . . . . . . . . . . . . . . . . 28

2.6 データ型定義の例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.7 ”impression”アノテーション型の定義の例 . . . . . . . . . . . . . . 29

2.8 ”impression”アノテーション型の定義間の関係 . . . . . . . . . . . . 30

2.9 Annphonyにおけるアノテーションの例 . . . . . . . . . . . . . . . 31

2.10 複数のアノテーション対象の指定 . . . . . . . . . . . . . . . . . . . 31

2.11 Annphonyと各システム間の関係 . . . . . . . . . . . . . . . . . . . 37

2.12 コンテンツからメタコンテンツへ . . . . . . . . . . . . . . . . . . . 38

3.1 MIDIの内部構造 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.2 MusicXMLの内部構造 . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.3 音楽アノテーションシステムのトップページ . . . . . . . . . . . . . 47

3.4 Tune Annotatorの画面例 . . . . . . . . . . . . . . . . . . . . . . . 48

vi

3.5 アノテーションメニューの動的な変更 . . . . . . . . . . . . . . . . 49

3.6 Timeline Annotatorの画面例 . . . . . . . . . . . . . . . . . . . . . 50

3.7 Timeline Annotatorのアノテーションメニュー例 . . . . . . . . . . 51

3.8 時間的セグメントの一括切り出し . . . . . . . . . . . . . . . . . . . 51

3.9 Score Annotatorの画面例 . . . . . . . . . . . . . . . . . . . . . . . 53

3.10 選択したオブジェクトへのアノテーション付与 . . . . . . . . . . . . 53

3.11 アノテーション表示メニュー部 . . . . . . . . . . . . . . . . . . . . 54

3.12 アノテーションのフィルタリング . . . . . . . . . . . . . . . . . . . 55

3.13 音楽アノテーションシステムの構成 . . . . . . . . . . . . . . . . . . 58

3.14 理由ごとのハイライト区間数 . . . . . . . . . . . . . . . . . . . . . 60

3.15 ユーザAにおける理由ごとのハイライト区間数 . . . . . . . . . . . 61

3.16 ユーザBにおける理由ごとのハイライト区間数 . . . . . . . . . . . 61

3.17 ハイライトと認識された区間の分布 . . . . . . . . . . . . . . . . . . 62

4.1 楽曲検索システムの検索フォーム . . . . . . . . . . . . . . . . . . . 67

4.2 楽曲検索システムでの検索結果 . . . . . . . . . . . . . . . . . . . . 68

4.3 再構成前の画面 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

4.4 再構成後の画面 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

4.5 MusicXMLにおける歌詞の記述 . . . . . . . . . . . . . . . . . . . . 74

4.6 MusicXMLにおける楽器パートの記述 . . . . . . . . . . . . . . . . 75

5.1 コミュニケーションツールとコミュニケーションメディア . . . . . 78

5.2 歌詞・楽曲情景・鑑賞状況の特徴量空間 . . . . . . . . . . . . . . . 81

5.3 プレイリスト作成の流れ . . . . . . . . . . . . . . . . . . . . . . . . 83

5.4 状況入力フォーム . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

5.5 ユーザに提示されるプレイリスト . . . . . . . . . . . . . . . . . . . 85

5.6 プレイリスト編集画面 . . . . . . . . . . . . . . . . . . . . . . . . . 87

5.7 歌詞の特徴量空間の基底変換前 (左)と後 (右) . . . . . . . . . . . . 89

vii

5.8 プレイリスト検索画面 . . . . . . . . . . . . . . . . . . . . . . . . . 90

5.9 評価実験の結果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

7.1 ブログでのビデオ・辞典の同時引用 . . . . . . . . . . . . . . . . . . 108

7.2 ビデオ用例付き辞典システム . . . . . . . . . . . . . . . . . . . . . 109

viii

表目次

2.1 Annphonyの実装環境 . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.1 デジタルコンテンツとしての音楽の主な記述形式 . . . . . . . . . . 42

3.2 各エディタを利用する前提とアノテーション対象となる要素の粒度 46

5.1 鑑賞状況に関するアノテーション項目 . . . . . . . . . . . . . . . . 80

1

概要

近年，音楽・ビデオ・写真などのコンテンツが爆発的に増え続けており，そのコ

ンテンツの種類も多様化してきている．このようにWeb上に存在しているコンテ

ンツを単に視聴するだけでなく，ユーザに適したコンテンツの検索・推薦や，コ

ンテンツ変換など，高度に利用したいという欲求が高まっている．そのためには，

それぞれのコンテンツの構造や関連性といった意味情報を計算機が把握する必要

がある．しかし，コンテンツの種類によって異なる論理構造が存在しており，ま

たコンテンツが持つ潜在的な曖昧性により，複数の解釈が可能な場合があるとい

う問題から，コンテンツを機械的に解析して意味を推論するだけでは，コンテン

ツの理解には限界がある．そこで，人手によってコンテンツに対するメタ情報を

付与するアノテーションの研究が進められている．

本論文では，まずWeb上に存在するコンテンツへのアノテーションのあり方を考

察する．一般的なコンテンツを，1．コンテンツそのもの，2．時間や長さ等に関する

連続メディア，3．ビデオのシーンや音楽の音符・小節などの論理的構造を持つ離散的

なメディアという 3種類の側面を持つものと捉えると，それぞれに対するアノテー

ションを付与するには連続メディアや離散メディアの任意の内部点を指し示す必要

がある．そこでコンテンツの任意の内部点を指し示す手法である ElementPointer

と，RDF を拡張してアノテーション自身が識別子を持つアノテーションを管理す

る基盤技術としてAnnphonyを提案する．Annphonyが ElementPointerを採用す

ることで，コンテンツの内部構造に対する多様な解釈の柔軟な定義・作成・管理

を実現する．Annphonyにより，コンテンツの種類によらず，その構造や解釈に基

づく検索やコンテンツ変換が可能になるとともに，複数のコンテンツを同時に利

2

用したアプリケーションの構築が容易になる．Annphonyの設計・構築を通して，

計算機がコンテンツの構造・解釈・関連性を横断的に扱うために，コンテンツの内

部を指し示す手法と，コンテンツの多義性を扱う必要があること，アノテーショ

ンとその定義を統合的に扱う必要があることを明らかにする．

一般に音楽は必ずしも解釈を一意に決定できず，その楽曲を捉える人によって

異なる解釈を見出すことがしばしばみられる．そこで，このように解釈が多義的

になりやすいコンテンツの一つである音楽を題材とし，音楽に関するアノテーショ

ンを収集するためのシステムを提案する．本システムはユーザによって異なる多義

的な解釈を獲得するため，Web上の多数のユーザからアノテーションを収集する．

収集されたアノテーションはAnnphonyによって管理する．またコンテンツは，連

続メディアとして，離散的メディアとしてなど，それぞれの側面ごとに表示形態が

異なり，さらに付与される補足情報の種類も異なってくる．そのためそれぞれに

対応する 1. 書誌情報などの楽曲自体に対するアノテーション (Tune Annotator)，

2. 連続メディアに対するアノテーション (Timeline Annotator)，3. 音楽の論理構

造である楽譜に対するアノテーション (Score Annotator)の 3 種類のエディタを備

える．収集すべきアノテーションは，そのアノテーションの応用の形態によって

異なるため，Annphonyに登録されるアノテーション定義に応じて，収集するアノ

テーションを変更することが可能である．このように，様々な種類のコンテンツ

のアノテーションを獲得するためには，コンテンツのメディア形式に応じてアノ

テーションエディタを構築する必要があることを示す．また評価実験をつっじて，

多義的なアノテーションをWeb上のユーザからオンラインで収集することが可能

であることを明らかにする．

また楽曲に対する多様な解釈に関するアノテーションを用いることで様々な応

用が実現可能であることを示すため，認識系応用として楽曲検索システムを，生

成系応用として楽曲再構成システムを構築する．楽曲検索システムは，音符や歌

詞など楽曲の論理構造に基づく要素に付与されたアノテーションを用いて，キー

ワード検索・印象検索・コード進行検索・楽曲の構造に基づく絞込み検索を実現

3

する．特に印象検索では，検索を行うユーザと嗜好の類似するユーザが付与した

アノテーションを優先して検索対象とすることで適切な楽曲を発見する．楽曲再

構成システムは，サビ・イントロなどの楽曲の構造に関するアノテーションを用

いて，例えば「イントロ-Aメロ-サビ-Bメロ-エンディング」という構造の楽曲を，

ユーザの要求に応じて「イントロ-サビ- エンディング」のように変換する．これ

らの応用は，楽曲の論理構造に対する，ユーザごとに異なる解釈のアノテーショ

ンを用いることで可能となる．

近年Web上では e-mail・オンラインチャット・ブログ・SNS(Social Networking

Service)などのコミュニケーションツールを通じて，文書や絵，写真などのコンテ

ンツがコミュニケーションメディアとして意思の伝達に用いられている．このよ

うに，コンテンツは人同士のコミュニケーションにおいて利用されるものである

といえる．そのためコミュニケーションの活発化に応じて，Web上に存在するコ

ンテンツが爆発的に増加してきている．コンテンツを介したコミュニケーション

を支援することが，人同士のコミュニケーションをより円滑にし，同時にコンテ

ンツの作成・利用を促進することにつながると考えられる．そこで，近年携帯型音

楽プレイヤの普及などにより注目されてきているプレイリスト (再生曲目リスト)

をコミュニケーションメディアとして利用する．プレイリストを介したコミュニ

ケーションをPlaylist-Mediated Communicationと名付け，その実現を目指し，プ

レイリスト作成支援システムを提案する．

本システムは楽曲の特徴量として歌詞に加え，ユーザの楽曲解釈の情報である

楽曲情景と鑑賞状況に関するアノテーションを利用することにより，ユーザの嗜

好と状況に合わせたプレイリストを作成する．本システムに利用されるアノテー

ションも，楽曲検索システムや楽曲再構成システムと同様，音楽アノテーション

システムにより収集する．プレイリスト作成の手順は，まず基となるプレイリス

トを協調フィルタリングにより発見する．次に，よりユーザの嗜好に適合するよ

うトランスコーディングを行い，ユーザにプレイリストを提示する．ユーザはプ

レイリスト中の各楽曲に対して，嗜好に合っているか，状況に合っているかといっ

4

た情報をフィードバックすることによりプレイリストが洗練される．同時にシス

テムはこの情報を用いてユーザプロファイルを更新し，各ユーザの嗜好に適合さ

せる．また，プレイリストを介してコミュニケーションを行うために，プレイリ

スト中の楽曲に対してライナーノーツ (解説文)を記述したり，他のユーザにプレ

イリストを推薦する機能を持つ．本システムによって，ユーザの嗜好と状況に適

応するコンテンツ推薦のために，コンテンツごとに，ユーザによって異なる解釈

に関するアノテーションを収集し利用することが有効であることを明らかにする．

また，プレイリストがコミュニケーションを円滑にする可能性があることを示す．

5

第1章序論

1.1 背景

現在，Web上には音楽・ビデオ・写真など膨大な量のコンテンツが溢れている．

また，それまではコンテンツを消費する側であったユーザが，ブログやSNS(Social

Networking Service)など，CGM(Consumer Generated Media)サービスを用いて

ユーザ自身によってコンテンツを発信するようになり，コンテンツの増加・多様

化が進んでいる．そのためWebのユーザ数や年齢層の拡大により，様々な属性の

ユーザがコンテンツを扱う機会が増加している．さらに計算機のウェアラブル・

ユビキタス化に伴い，コンテンツを生活のあらゆる場面で楽しむ環境が整いつつ

ある．

このような現状では，計算機が行うコンテンツ処理には個人適応と状況適応が

必要である．ユーザごとに異なる嗜好を踏まえるとともに，ユーザがどのような

環境に置かれているかを考慮することで，その時，そのユーザにとって適切な検

索や推薦，コンテンツ変換などのコンテンツ処理が実現されるだろう．

個人適応・状況適応の必要なコンテンツの代表例に音楽が挙げられる．音楽は，

ユーザごとにジャンルやアーティストなど好みの違いが顕著に現れるコンテンツ

である．利用可能な楽曲も，iTunes Store [1]やAmazon [2]からの楽曲購入が容易

となり，音楽定額制配信サービス等も現れたため，個人が利用可能なデジタルコ

ンテンツとしての楽曲が大幅に増加した [3][4]．さらに iPod等のポータブル音楽

プレイヤの出現により，音楽を持ち歩き，いつでもどこでも手軽に音楽を鑑賞で

きるようになった．また日常生活における音楽との接し方から推測されるように，

第 1章序論 6

例えば「夏の海で大勢で楽しむ時に聴きたい曲」と「クリスマスの夜恋人と聴き

たい曲」は大きく異なるだろう．このようにユーザの置かれている状況が，楽曲

検索や推薦に強く依存すると考えられる．

従来の音楽情報処理の多くは，音響メディアやMIDIなどの構造化メディアな

ど，単一のメディア形式を対象として研究が進められてきたが，音楽情報処理研

究をさらに発展させるためには，複数のメディアの形式を同時に扱わなければな

らないだろう．例えば楽曲検索を例にとってみると，音メディアから認識可能な

テンポや音量等の音響特徴量に加え，テキストである歌詞の情報や，画像である

アルバムのジャケットイメージの情報，映像であるプロモーションビデオの情報

など，他のメディアを対象とした検索を実現することで，ユーザが目的の楽曲に

たどり着く可能性が高まる．このように，音楽に関する研究を行う際に，他のメ

ディアも横断的に利用することが求められる．また複数のメディアを同時に扱う

必要性は，音楽情報処理に限らない．Tim O’Reillyが提唱したWeb 2.0において

も，Web 上のサービスやリソースが互いに連動することによってコンテンツ処理

全般が発展すると述べられている [5]．

膨大な量のコンテンツからの検索や推薦，複数の種類のコンテンツの組み合わ

せなどを行うには，計算機の支援が無くては困難である．特に重要なコンテンツ

の意味内容として，構造・解釈・関連性が挙げられる [6][7]．構造に基づく検索や，

要約などのコンテンツ変換を行うためにはそれぞれのコンテンツの構造を考慮し

なければならず，人によって異なるユーザの嗜好や感性を扱うために，コンテン

ツに対する多様な解釈を扱う必要がある．また種類の異なるコンテンツ同士を横

断的に扱うために，コンテンツ同士の関連性を把握する必要がある．例えば撮り

溜めた写真を用いて自動でアルバムを作成する場合に，写真間の関係や撮影の意

図などを無視して，色ヒストグラムの類似する画像を表示しても，ユーザにとっ

て整理されたアルバムを作成することができない．このように，意味的なつなが

りや個人嗜好にそぐわないコンテンツ処理となってしまう．

そこでTim Berners-Leeは計算機がWeb上のコンテンツの意味内容を把握する

第 1章序論 7

図 1.1: コンテンツとアノテーションの関係

ために，セマンティック・ウェブを提唱した [7]．適切なアノテーション (メタ情報)

を各コンテンツに持たせることによって，コンテンツの意味を計算機が利用可能に

するというものである．現在ではその必要性からアノテーションの管理・収集・利

用などに関する研究が進められている [6]．これからアノテーションの研究動向と，

個人の嗜好・状況への適応を目指した音楽情報処理に関する研究動向を述べる．

1.1.1 アノテーションに関する研究動向

コンテンツの意味内容を機械的な処理に適用可能な形式で取り込むために，ア

ノテーションに関する研究が進められている．アノテーションとは，図 1.1に示さ

れるように，あるコンテンツに対して関連付けられるメタ情報である．

アノテーションに関する研究を分類すると，主に 1. 規格化，2. 収集，3. 応用

の 3種類に分類されると考えられる．

アノテーションの規格化アノテーションの規格化は，コンテンツに付与される

メタ情報の記述能力を左右する重要な点であるといえる．コンテンツの種類に依

存したアノテーション形式と，コンテンツの種類に依存しないアノテーション形

式に二分される．

第 1章序論 8

図 1.2: MPEG-7の記述例

コンテンツの種類に依存する形式としては，GDA(Global Document Annotation)[8]

やMPEG-7[9]が挙げられる．GDAはテキストに対する構文・意味情報を詳細に記

述するための形式である．MPEG-7はマルチメディア・コンテンツに対するメタ

データの表記方法に関する国際標準規格である．正式名称をMultimedia Content

Description Interface という．マルチメディア・コンテンツの検索の際に直接の検

索対象となる画像・音響特徴データを規格化された手段で表現可能である点が特

徴である．MPEG-7によって画像データのメタデータを記述した例を図 1.2に挙

げる．MPEG-7は，Mpeg7タグから始まるXML形式で記述され，description

タグ内に画像から抽出される色ヒストグラム情報や，撮影日時，コンテンツ管理

など，規格として定められた属性を入力することができる．

これらの形式は，コンテンツ内部の意味内容に関するアノテーションを記述す

ることを目的としており，それぞれがコンテンツの種類に依存する形式となって

いる．そのため，横断的にこれらのコンテンツを扱うためには，専門性の高いそ

れぞれのアノテーション形式を熟知しなければならない．またコンテンツの種類

は多様化を続けているため，コンテンツの種類の追加に伴い定義される新しいア

ノテーション形式に対応しなければならない．

一方で，コンテンツ自体の情報や，コンテンツ同士の関連性などを記述するアノ

テーション形式として，RDF (Resource Description Framework)[10]が標準化され

第 1章序論 9

図 1.3: RDFのデータ構造

ている．URI(Uniform Resource Identifier)[11]を持つリソースであれば，コンテン

ツの形式を問わずアノテーションの対象に指定可能であるため，異種類のコンテ

ンツ間の関連性を表現することができる．従来，コンテンツ間の関連は，HTML

のハイパーリンク構造により導き出されることが一般的であるが，ハイパーリン

クには，リンクの意味を記述することができない点が問題であった．RDFのデー

タ構造は，図 1.3に表すように，主語・述語・目的語の組みによって，ラベル付き

有向グラフとして表現される．例えばある楽曲の制作者を記述する場合，楽曲の

URIを主語に，制作者のURIを目的語に，それらの間の関連性として，制作者で

あることを示す dc:creatorという述語を記述する．またアノテーションの述語に

相当する部分の柔軟な定義が可能であり，様々な関連性に関する情報を表現するこ

とができる．このことから様々な種類のコンテンツ同士の関連の把握を容易にし，

多様なアプリケーションに適用可能な形式であるといえる．しかしURI によって

コンテンツを指し示すため，それ以上に詳細なコンテンツ内部に関する記述が困

難である．そのためコンテンツの種類を横断するアノテーション形式であるRDF

はコンテンツの内部構造までを扱うことができない．

図 1.4に示すように，コンテンツの内部構造を記述するためのアノテーション形

式であるGDAやMPEG-7はコンテンツの種類に依存する．また新規のコンテン

ツが出現した場合には，そのコンテンツに特化した新しいアノテーション形式が

提案されるだろう．一方でコンテンツ間の関連性を記述するためのRDFには，一

般にコンテンツの内部構造を扱うことができず，双方の間には大きな壁が存在す

る．このように多様化するコンテンツとその内部構造や，コンテンツ同士の関連

性を統一的に扱う仕組みが求められるが，現在そのような仕組みが存在しないと

第 1章序論 10

・GDA

・MPEG-7

シーン情報

オブジェクト情報

音響解析結果

・・・

構文情報

単語の意味

・・・

・RDF

書誌情報

コンテンツ間の関係

・・・壁

関連性記述のための形式内部構造記述のための形式

･

･

･

図 1.4: アノテーションの枠組みの間の壁

いう問題がある．

また，アノテーションには計算機によって自動的に生成されるものと人間の手

によって作成されるものが存在する．計算機の自動解析によってコンテンツの構

造を認識する研究が多く存在するが，一方では自動解析によって得ることの困難

な情報を，人間の手によって付与するシステムに関する研究が盛んになってきて

いる [6][12][13]．アノテーションを付与するための特別なエディタを用意し，詳細

な構造情報等を付与するというものである．

アノテーションの収集人手によるアノテーションには，アノテーションの付与

のコストという問題が存在する [14]．人手により詳細な情報を付与可能である反

面，膨大な量のコンテンツをアノテーションの対象としなければならない．その

解決策の一つとして Folksonomy [15] が挙げられる．del.icio.us [16]や Flickr [17]

において，Web 上の多くのユーザがそれぞれのコンテンツにタグと呼ばれる分類

キーワードを付与することで，そのタグを基に分類やコンテンツへのアクセスを

可能にする仕組みを構成している．Web上の文書や写真といったコンテンツに何

第 1章序論 11

が表現されているかは，計算機がそれを自動解析することが困難であるが，その

制作者や閲覧者は容易に理解することができる．そのような情報を幅広いユーザ

の手によって記述することで，アノテーション付与のコストを軽減することが可

能である．このように多くの人の分類作業を蓄積して再利用可能にする仕組みを

Folksonomy と呼ぶ．またWeb上の文書に対して，多くのユーザから少しずつ文

書情報を収集するシステムも研究が進められており [18][19]，一般大衆から得られ

る情報を蓄積することで形成される「集合知」に期待が寄せられている．

アノテーションの応用アノテーションの応用としては，ビデオのシーン検索など，

膨大な量のコンテンツの内容を考慮したコンテンツ検索がある．またアノテーショ

ンを用いることで，目的に合わせてコンテンツを変換することも可能になる．文書に

対する構文や単語の意味に関するアノテーションを用いた応用として，SemCode[6]

がある．それは文書の翻訳・要約・音声化・言い換えや，表示端末への適応を行っ

ている．また複数のコンテンツを組み合わせることで新しいコンテンツを生成す

るための規格化 [20]や研究 [21]が進められている．

以上のことから，現状では多様なコンテンツを対象とした場合にはコンテンツ

の内部に関する情報を扱うことが困難であり，逆にコンテンツの内部構造を扱う

ためにはコンテンツの種類を横断することが困難であることが分かる．今後は多

様なコンテンツを対象とし，かつコンテンツの内部に関する情報を扱うことが求

められようになると思われる．

1.1.2 音楽に関するメディア形式とアノテーションの研究動向

音楽は個人の嗜好・状況への適応が強く求められるコンテンツであり，機械的

に音楽利用を支援する研究が進められている．以下に音楽情報処理研究の動向を

述べる．

音楽メディアは，MP3等の音響信号などの連続メディア以外に，音楽の離散的

な構造を記述する形式が提案されている．特に音楽の詳細な楽譜構造を表現する

第 1章序論 12

形式として，WEDELMUSIC XML[22]とMusicXML[23]がある．これらの形式は

楽譜を構成する情報を記述することができ，また XML形式で記述されているた

め，計算機は音符や小節，楽器パートなどの詳細な楽曲構造を把握でき，また楽

曲の一部を変更するなどのコンテンツ変換の操作が容易に実現可能である．また

音楽の構造化に関する研究も進められており [24]，今後も変更・拡張されていくだ

ろう．そのため音楽のみを扱ったコンテンツ処理であっても，このような多様な

メディアに横断的に対応しなければならない．

楽曲のタイトルやアーティスト・ジャンルなどのアノテーションを付与する方法と

して，MP3は ID3タグを埋め込む方式をとっている．一方CDDB[25]やMusicBrainz[26]

は楽曲の書誌情報などを外部アノテーションとして一括管理し，そのアノテーショ

ンを対象とした楽曲検索が可能である．CDDBは拡張性に乏しく，新しい属性を

追加することができないが，MusicBrainzではRDFをデータ形式として利用して

おり，新しい属性を定義することで，柔軟に拡張することができる．このような

拡張性は，アノテーションの利用法を特定せず，幅広いアプリケーションに適用

可能になるという利点がある．一方で，柔軟に定義可能なアノテーションは，あ

らかじめ定義が固定されたアノテーションと比較して，他人が定義したアノテー

ションをどのように共有し，利用を支援するかに関して問題があるといえる．

音楽コンテンツの意味内容の中には，自動認識することの困難な情報が多く存

在する．例えば楽曲から受ける印象は，テンポや曲調，歌詞の内容，時代背景など

を踏まえて判断する必要があり，一般に自動的に解析することが困難である．ま

た音楽は特に芸術作品としての側面を持ち，コンテンツ自体に多義性が残されて

いることが多く，人が解釈することによって初めてコンテンツの内容を把握する

ことが可能になる場合が多い．そのため音楽は人手によるアノテーション付与が

特に有効となる．音楽に関するアノテーションを人手により付与する研究がいく

つか存在するが [27][28][29]，コンテンツの内部構造に対するアノテーション付与

ができない，人によって異なる解釈を管理することができないなどの問題点が存

在し，音楽の意味内容を記述するためには不十分である．

第 1章序論 13

また音楽のメディア形式の多様性や拡張性の点から，図 1.4に示したアノテー

ションの壁は，音楽のみを対象とした場合も存在しており，音楽を対象としてこ

の壁を取り除くことは，一般的なコンテンツに対するアノテーションの壁を取り

除くことにもつながると考えられる．

1.1.3 音楽コンテンツの応用に関する研究動向

音楽コンテンツの応用として，楽曲の推薦 [2][30][31]や配信 [1]など，楽曲単位

あるいはその集合単位の利用法に関するサービスや研究が盛んに行われている．近

年，特に iPodなどのポータブル音楽プレイヤの普及によりプレイリストの有効性

が注目されている．また，様々なCGMの中でも，作曲や演奏をしたり，小説を書

くといった敷居の高いコンテンツ制作に比べ，作成が容易であるプレイリストは，

より手軽な音楽を楽しむ手段として注目されている．

プレイリストとは，ユーザによって事前に選択された曲目リストである．プレ

イリストを利用することで，一曲ずつ再生する楽曲を決定するといった煩雑な操

作を必要とせず，より容易に楽曲が鑑賞できるようになった．そのためプレイリ

ストの自動作成や推薦に関する研究が進められている [32][33][34][35]．これらの研

究では，音楽の音響信号の類似度や，ジャンル・アーティストといった基本情報，

ユーザの嗜好，またユーザ同士の類似度などを用いることで，それぞれのユーザ

に適合したプレイリストを作成，推薦している．

音楽以外の他の種類のコンテンツにも，プレイリストと同様の概念が存在する．

写真のアルバム，複数人の作品を集めた歌集や詩集，テレビのコマーシャルフィル

ムを集めた CM集などである．また，あるテーマに関連したコンテンツを列挙さ

せるプレイリストなど，プレイリストを構成する要素が複数の種類になる場合も

考えられる．これらのことから，プレイリストの作成や利用に関する研究は，音

楽情報処理の枠を超えて，コンテンツ処理に関する研究全体に対して貢献すると

考えられる．

第 1章序論 14

このように，音楽コンテンツを利用したアプリケーションとして，プレイリス

ト作成の計算機による支援や，作成されたプレイリストの他のユーザへの推薦な

どの研究を進めることは非常に有意義であり，コンテンツの種類を横断するクロ

スコンテンツ処理へ発展する可能性もある．

1.2 本論文の目的

以上の背景を踏まえ，本論文では計算機がコンテンツの意味を把握し，様々な

応用が実現可能になることを最終的な目標とする．また前提条件として，本研究

で扱うコンテンツはWeb上で公開され，利用可能であることと設定する．特に着

目するコンテンツとして音楽を選ぶ．音楽は特に個人の嗜好と状況への適応に対

する要求が高く，多様なメディア形式や意味内容を統一的に扱う必要のあるコン

テンツである．

まず図 1.4に示した既存のアノテーションの枠組みの間の壁を取り除くために，

任意のコンテンツの任意の部分に対する，ユーザの多様な解釈や構造・関連性に

関するアノテーションを記述可能にし，アノテーションとその定義を統一的に管

理する基盤技術を構築することを目的とする．

また，特に楽曲に対する構造や解釈・関連性に関するアノテーションを獲得す

ることを目的とする．自動認識の困難な楽曲情報を収集するため，Web上の一般

ユーザを対象とした，オンラインでアノテーションを獲得するシステムを提案し，

音楽に限らず，他のコンテンツに関するオンラインアノテーション収集システム

を実現する際の指針を示す．

さらに，実際に構造や解釈に関するアノテーションを用いた複数の音楽アプリ

ケーションを提案することにより，計算機がユーザのコンテンツ制作・利用を支

援するための手法を示し，また音楽以外のコンテンツへの応用可能性を示すこと

を目的とする．

第 1章序論 15

1.3 本論文の構成

本論文の構成を以下に示す．

まず 2章では，コンテンツに対するアノテーションを管理する基盤技術について

述べる．Web上の任意のコンテンツに対するアノテーションのための基盤として

Annphonyと呼ばれるシステムを提案する．コンテンツの内部要素を指し示す形

式としてElementPointerを提案し，さらに既存のアノテーション形式であるRDF

を拡張することで，コンテンツの構造・解釈に関する情報を扱えるようにする．ま

た記述可能なアノテーションの種類を特定せず，柔軟なアノテーション記述を実

現するために，RDFのスキーマ言語である RDFS(RDF Schema)[36]によって記

述されるアノテーション定義の管理を行っている．

3章では，アノテーションに基づく音楽情報処理を目指し，音楽に関するアノ

テーションを獲得するためのシステムを提案する．楽曲情報には，自動認識する

ことの困難な情報が多く存在している．それらの情報を収集するため，Web上の

ユーザを対象とし，人手によるアノテーション収集を支援する．本システムは 2

章で述べたAnnphonyをアノテーションの管理に利用することで，楽曲の構造や

解釈・関連性に関するアノテーションを収集する．またAnnphonyで管理される

アノテーション定義を，アノテーション収集のためのシステムに適用することで，

収集するアノテーションを柔軟に追加・変更することが可能である．これにより

特定のアプリケーションに限定されないアノテーション収集が実現される．

4章，5章では，音楽アノテーションを複数のアプリケーションで利用する手法

について述べる．まず 4章では楽曲検索・楽曲再構成システムについて述べる．こ

れらのシステムで利用されるアノテーションを定義し，3章の音楽アノテーション

システムに適用することで，印象や楽曲構成などのアノテーションを収集し，利用

する．5章では新しい音楽の利用形態として，プレイリストを介したコミュニケー

ション (Playlist-Mediated Communication)を提案する．

一般的に音楽のプレイリストは作成が手軽であり，プレイリストへの解説や感

第 1章序論 16

想が頻繁にやり取りされるため，Web上のユーザによるプレイリストを中心とし

てコミュニケーションが成立すると考えられる．そこで，嗜好と状況に適合する

プレイリスト作成の支援を行い，さらにそのプレイリストに対する感想や解説を

投稿し合うことで，ユーザ同士がオンラインでコミュニケーションを行うシステ

ムを実現する．本システムでは，楽曲そのものから認識することが困難な情報で

ある楽曲情景 (楽曲中で表現されている情景)・鑑賞状況 (その楽曲を鑑賞したい状

況)というアノテーションを音楽アノテーションシステムによって収集し，利用し

ている．

さらに 6章では関連研究について述べ，7章で本論文をまとめ，今後の課題につ

いて述べる．また将来展望として本論文で提案する音楽を軸としたアプローチが，

音楽情報処理以外にも適用可能であることを述べる．

17

第2章任意のコンテンツに対するア

ノテーション基盤

Web上に存在する大量のデジタルコンテンツを有効利用するため，テキストや

音楽などのコンテンツに対してメタ情報 (アノテーション)を付与し利用する研究

が盛んに行われている [6][12]．これらの研究から，コンテンツの意味内容を考慮

し，それぞれのユーザに適したコンテンツ処理を行うことの重要性と，そのため

にはコンテンツの構造に加えコンテンツの詳細部分にまで踏み込んだ個人の解釈・

嗜好情報が必要であることがわかる．

しかし，1.1.1節で述べたように，現在までに提案されているデジタルコンテン

ツに対するメタデータの表現形式は，コンテンツの構造を記述するためにコンテ

ンツの種類に強く依存した形式となる仕組みと，異なるコンテンツ間の関連性を

記述することができるがコンテンツの内部構造に踏み込むことができない仕組み

の二通りに分断されてしまっている．またコンテンツの種類も多様化を続けてお

り，画像・音楽・文書などのコンテンツを横断的に利用し，意味内容と個人性を考

慮した応用研究を進めるにあたっての障害となっている．

また，横断的にコンテンツを扱うためには，それぞれのコンテンツの意味内容

を記述するためのアノテーション定義を共有しなければならない．同時に，コン

テンツの種類は多様化を続けているため，コンテンツの種類の追加に伴い定義さ

れる新しいアノテーション形式に対応しなければならない．

本章では，1．任意のコンテンツに対するアノテーションを実現するために必要

な要素について，2．我々が構築しているアノテーション基盤Annphony(アンフォ

ニー) におけるアノテーションとそのスキーマの形式について，3．Annphonyに


おいてアノテーションやスキーマの利用・共有を支援する機能について述べる．

2.1 任意のコンテンツに対するアノテーションについて

の問題点

現在デジタルコンテンツに対するアノテーションの記述形式がいくつか提案

されている．例えばテキストに対する構文・意味情報を詳細に記述するための

GDA(Global Document Annotation)[8]や，テキストコーパスに対するアノテー

ション形式であるCES(Corpus Encoding Standard)[37]などがある．Flickr[17]は

Web上で写真を共有するサービスであるが，独自のアノテーション形式により画

像の矩形部分に対するコメント付与を実現している．これらの形式はコンテンツ

の種類に閉じており，例えば Flickrにおいて記述されたコメントに対して，GDA

による詳細な言語構造を記述するといった，あるコンテンツのアノテーションを

異種コンテンツに適用することが困難である．このように，現在提案されている

コンテンツの内部構造にまで踏み込んだアノテーション形式は互換性が乏しいと

いえる．

一方で，コンテンツ全般に対するアノテーションの形式としてリソース間の

関係をグラフ構造で記述する RDF(Resource Description Framework)[10] では，

URI(Uniform Resource Identifier)[11]を持つ対象をリソースと呼び，そのリソー

スに対するメタ情報を主語・述語・目的語の組で表現する．つまり，どのようなリ

ソースであってもそれをURIで表現することができれば，そのリソースに対する

アノテーションを記述することが可能である．

コンテンツの意味情報を扱うためには，そのコンテンツの詳細な部分へのアノ

テーションを実現しなければならない．なぜなら，コンテンツの構造の一部に対し，

その部分がコンテンツの他の部分や，他のコンテンツとどのような関係性を持って

いるか，またその部分は人によってどう解釈されるかという情報を付与する必要が

あるからである．そこで，まずコンテンツの構造を表現するために，コンテンツの


任意の箇所を指し示す方式としては，XMLの特定のノードを指すXPointer[38]や，

ビデオ・オーディオなどの連続メディアの任意の箇所を指し示すURI time interval

specification [39] など，いくつかの形式が提案されており，今後も新しいメディア

形式が提案されると予想される．しかし，未知のメディア形式を含むそれらの全

てを網羅するアノテーション形式は存在しない．さらに，提案されている形式で

は指し示すことのできない場合が多く存在する．そのため，「MIDIの特定のチャン

ネルにおける時間範囲」といった，任意のコンテンツの，任意の箇所を指し示す

ことのできる柔軟な表現形式が必要である．

図 2.1に示すように，音楽や絵画などの芸術作品には，鑑賞者によって解釈は

様々に異なる場合が多い．また楽曲の構造化を行うGTTM(Generative Theory of

Tonal Music)[24]では，楽曲の構造を一意に決定することができない場合がある．

そのため複数の解釈に基づく構造が存在する可能性がある．そのような多義性の

ある構造の一部に，関連性や解釈などの意味情報を付与するためには，同一のメ

ディア形式が複数の構造を持つことを許す必要がある．しかしRDFやGDAでは，

一つのメディア形式に対する複数の構造を扱うような柔軟な関連性記述ができな

いという問題がある．

また構造や解釈といった様々なアノテーションを定義する際には，既存の定義

を利用・拡張することで，アノテーションの再利用性が高まると考えられる．例

えば異なるコンテンツ間で共通の属性を定義し，各コンテンツのアノテーション

でその属性を利用することで，コンテンツの種類にこだわらずそのプロパティを

利用することができるだろう．そのためアノテーションのスキーマの存在が必須

となる．

Flickrではアノテーションを利用するための Flickr APIが用意されており，ま

たRDFに関してはProtégé[40]やRDF Gravity[41]など，RDFの記述・検索・可

視化を行うアプリケーションが提供されている．様々な種類のアノテーションを幅

広く収集し，利用可能にするためには，これらのシステムのように，幅広いユー

ザが利用可能なアノテーション管理基盤が必要である．しかしこれらのシステム


鳥

パレット

鍵盤

図 2.1: 同一のリソースに対する解釈の多様性

では，任意のコンテンツの内部要素に対するアノテーションを扱えない．

2.2 ElementPointer

前節で述べたように，コンテンツの内部構造に対するアノテーションを扱うた

めには，そのコンテンツのセグメントを指し示す手段が必要である．任意のメディ

アの任意のセグメントを指し示す形式としてElementPointer を提案する．

2.2.1 ElementPointerの形式

ElementPointerをXPointerの書式を参考にして定義する．XPointerは以下の形

式でXMLドキュメントの任意のノードを指し示す．

[Content]#xpointer([XPath])


http://localhost/test.xml#xpointer(/doc/person[@id=‘kaji’])

http://localhost/test.xml

図 2.2: XMLドキュメントの内部ノードのXPointerによる指示

コンテンツの URIである [Content]に続き，#xpointer以降 [XPath]に XML

ドキュメント内部ノードを指し示す手段として標準化されているXPath [42]を記

述することで，内部構造への言及を可能にしている．全ての中括弧は表記には含

まない．例えば図 2.2 のように，XML ドキュメント (http://localhost/test.xml)

の，ルートノード (doc)の子ノードである person の中で，id属性が kajiであるも

のを指し示すXPointerが示されている．XPointer は一般的に以下のように表現さ

れる．

一方で，任意のコンテンツの任意の箇所を指し示すXPathに相当する形式が存在

しない．そこでElementPointerではコンテンツ内部を指し示すための定義を別途

用意し，その定義を引用する．また，例えば図 2.3でハイライトされている，「MIDI

のチャンネル１における，楽曲開始後 10秒から 20秒までの時間範囲」のような

セグメントを指し示すためには，MIDIのチャンネル番号，開始時間，終了時間と

いう属性名，属性値が必要となる．そこで，ElementPointerは以下のように，定

義と，属性名・属性値の組を列挙する形式をとる．


[Content]#epointer([Schema](([Prop1],arg1),([Prop2],arg2),...))

コンテンツのURIである [Content]に続き，以降にフラグメント識別子としてコ

ンテンツのどの部分を指し示すかを記述する．本手法では，コンテンツの内部は，

[Schema] で表される ElementPointer定義の URI以降に，[Prop1],[Prop2],...で表

される有限個の属性のURI とその値を列挙することにより指し示される．これら

の属性はコマンドに対する引数の役割を持つ．実際にはURIとしての妥当性を保

つため，[Schema](([Prop1],arg1),([Prop2],arg2)...)の部分を URLエンコー

ディングする．URLエンコーディングによって，URIに含めることのできない文

字を妥当な文字に変換することができる．

アノテーション共有の必要性から，ElementPointerの定義は共有に適した一般

的な形式で記述されるべきである．ElementPointerは，コンテンツの任意の内部

要素を指し示すことで，コンテンツの構造を表現するための形式であるため，意

味的なアノテーションの一つであるといえる．そこで，リソース間の関係を表す

ためのフレームワークであり，一般的なアノテーション形式として知られている

RDFのスキーマ言語であるRDFS(RDF Schema)[36]を ElementPointerの定義に

採用した．リソース間の関係をグラフ構造として表現する RDFや RDFSを用い

ることで，その検索言語である SPARQL(SPARQL Query Language for RDF)[43]

によって，コンテンツの構造を扱う際に有効なグラフ検索が可能になる．そのた

め ElementPointerの定義を共有することに適していると考えられる．Annphony

においてその定義の検索や利用を支援し，任意のユーザによるElementPointerの

定義の利用を支援する．

ElementPointerの具体例を示す．前述の「MIDIのチャンネル１における，楽曲

開始後 10秒から 20秒までの時間範囲」を指し示すため，MIDIチャンネル別の時

間範囲を表すElementPointerを定義する．本定義で利用される属性とそのデータ

型として，MIDIのチャンネル番号 (1から 16までの integer型)，時間区分の開始時

間 (double型)，終了時間 (double型)を記述する．また時間区分の開始時間，終了

時間は楽曲の演奏の開始からの秒数であることを同時に記述する．具体的なRDFS


チャンネル１

チャンネル２

チャンネル３

チャンネル４

演奏開始演奏終了１０．０ｓ 2０．０ｓ

http://foo/bar.mid

図 2.3: MIDIファイルの時間区分

の書式については 2.3.2節において述べる．こうして記述された定義はWeb上に

公開するか，Annphonyに登録し，URIを持たせることで利用可能になる．便宜

的に「MIDIの特定のチャンネルにおける時間範囲」に対する ElementPointer の

定義のURIを [Schema]，チャンネル番号，時間区分の開始時間，終了時間の各属

性のURIは [Content]，[From]，[To]と表現すると，ElementPointerにより，ある

MIDI データ (http://foo/bar.mid)における，チャンネル番号が 1番の，10.0 秒か

ら 20.0秒までの範囲を指し示す ElementPointerは以下のように表現される．

http://foo/bar.mid#epointer([Schema](([Channel],1),([From],10.0),([To],20.0)))

実際にはURIの規格に準拠するため，URLエンコーディングを施す．[Schema]，

[Channel]，[From]，[To]にURIを埋め込み，URLエンコーディングを行った具体

的な例を以下に示す．

http://foo/bar.mid#epointer(http%3A%2F%2Flocalhost%2Fannphony%2F

schema%2Fmidi.rdfs%23midi%28%28http%3A%2F%2Flocalhost%2F

annphony%2Fschema%2Fmidi.rdfs%23channel%2C1%29%2C%28

http%3A%2F%2Flocalhost%2Fannphony%2Fschema%2Fmidi.rdfs%23from%2C

10.0%29%2C%28http%3A%2F%2Flocalhost%2Fannphony%2Fschema%2F

midi.rdfs%23to%2C20.0%29%29)


また，例えば画像の矩形範囲を指定するためには，画像のX 座標，Y座標，幅，

高さが決定される必要がある．そこで同様にX座標，Y座標，幅，高さの 4種類

の属性を記述し，さらにそれぞれの値のデータ型を指定する．またそれぞれの値

は，画像の左上を頂点とし，それぞれの数値がピクセル単位であることを記述す

ることで，画像の矩形範囲を表す ElementPointerを定義する．

2.2.2 ElementPointerプロセッサ

また ElementPointerによって指し示された部分を扱う処理系を同時に作成し，

後述するElementPointerの定義へのアノテーションとして関連付けを行えば，An-

nphonyにおいてそのセグメントのプログラム中での取得・利用が可能になる．El-

ementPointer プロセッサは，指定された部分の存在確認や，実際に指定された部

分の取得など，部分同士の演算を行うためのメソッドで構成される．例えば上記

の例のように矩形範囲指定により二次元のメディアを指し示すElementPointerプ

ロセッサとして，その矩形範囲の画像を取得して表示するプログラムを用意して

おくことで，該当部分が抜き出された画像を容易に扱うことが可能になる．

2.3 Annphony

楽曲に対する複数の解釈を管理するために，任意のデジタルコンテンツに対す

るアノテーションを扱う基盤であるAnnphony を構築した．以下に概要を述べる．

2.3.1 構造と解釈のためのアノテーション形式

リソースの関係を有向グラフで表現するアノテーション形式としてRDFが提案

されている．1.1.1節で述べたように，URIを持つリソースであれば，コンテンツ

の形式を問わずアノテーションの対象に指定可能であるため，異種類のコンテン

ツ間の関連性を表現することができる．しかし 2.1節で述べたように，RDF は一


意の解釈や定義の記述を目的とした形式であり，多様な解釈を記述することに適

していない．一方RDFを拡張した形式として提案されているNamed Graphs [44]

は，任意のグラフのまとまりを一意に識別し，他と区別するために，グラフのま

とまりに識別子を付与することができる．図 1.3のように，RDF では「この楽曲

は (主語) Aさんに (目的語) 作成された (述語)」といった，主語・述語・目的語の

3つ組みで記述されるが，Named Graphsはそれに加え，そのアノテーションの識

別子であるアノテーションURIを持った 4つ組みで表現される．本形式は一つ一

つの解釈が区別されることから，複数の解釈を扱う形式として適していると考え

られる．そこでAnnphonyではNamed Graphsをアノテーション形式の基礎に採

用した．Web上で普及しているURI の枠組みに基づいてアノテーションを指し示

すため，アノテーションの再利用性が高まり，任意のアプリケーションによるア

ノテーションの利用を可能にする．

Annphonyが扱うアノテーションは人により記述されるため，アノテーション自

体の情報が不十分であったり，誤っている場合が考えられる．そのため，そのよ

うな人が記述した不十分な解釈のアノテーションに対して，そのアノテーション

を補足するさらなるアノテーションが必要になるだろう．しかしどのようなアノ

テーションに対してさらなる情報が必要であるかを事前に予測することは不可能

であるため，あらかじめ最小単位のアノテーションに対して識別子が付与される

必要がある．Named Graphsでは，ある楽曲T1と別の楽曲T2についての関連性

と，楽曲T3と楽曲T4についての関連性とを同時に記述し，それらをまとめて一

つのURIで表現することが可能であったが，T1とT2の関連性に対して言及する

際に，直接その部分を指し示すことができない．そこでAnnphonyでは任意のグ

ラフのまとまりに対して識別子を付与することができるというNamed Graphsの

機能に制限を加える．Named Graphs では，Named Graphsでは図 2.4の右側のよ

うにA，B，Cの各部分を分離してURIを付与することも可能であるが，左側の

ようにA，B，C というアノテーションをまとめたものに対して一つの識別子を付

与することもできてしまう．この場合識別子が付与されていないA，B，Cの各部


分への言及が困難である．Annphony では，図 2.4 の右側のように，それぞれのリ

ソース記述を明確に分離する．具体的には，あるアノテータが，ある主語 (リソー

ス) に対して述語・目的語の組を列挙したものを一つのアノテーションとし，それ

ぞれのアノテーションにURI を発行する．

音楽のプレイリスト中に含まれる複数の楽曲を対象としてコメントを付与する

場合など，複数の楽曲という単一ではないリソースを主語としたアノテーション

が想定される．そこでAnnphonyではアノテーションの主語として複数のリソー

スを指定することを許可している．また図 2.4の左側においてA，B，C が何らか

の意図を持ってまとめられていたということも，A，B，Cという複数のリソース

を主語とするアノテーションにより表現可能である．

コンテンツの代表的な構造として，グルーピング構造，ツリー構造，グラフ構造

が挙げられる．RDFはリソース間の関係をグラフ構造で表現する形式であり，グ

ラフ構造はツリー構造を内包するため，RDFはこれらの構造を扱うことのできる

形式であるといえる．しかしRDFでは，主語に直接複数のリソースを指定できな

いという，グルーピング構造を表現するために問題がある．そこでAnnphonyで

はそれに加え，前述のElementPointerによるコンテンツのセグメント指定と，主

語に複数のリソースの記述を許すアノテーション形式により，コンテンツのグルー

ピング構造を表現する．例えば楽譜中に表れる音符や休符群をまとめて，そのグ

ループに対してイントロやサビなどの楽曲構成情報などを関連付けることが可能

になる．以上よりAnnphonyはコンテンツの代表的な構造に関する情報を扱える

基盤である．

2.3.2 アノテーション定義に基づくアノテーション管理

従来のコンテンツの内部構造に言及するアノテーション記述形式 [8][9]は，アノ

テーション記述のための全ての仕様が固定されており，拡張性が低い．そのため

これらの形式で記述することのできないアノテーションを利用することが困難で


… …

…

…

…

…

図 2.4: Named Graphs(左)とAnnphonyアノテーション (右)

ある．そこで，Annphonyのアノテーション形式のベースであるRDFのスキーマ

言語であるRDFSを，アノテーション定義のための言語に採用した．取得すべき

アノテーションの形式を RDFSで記述することにより，Annphonyはそれに基づ

く検索やアノテーション利用を支援する．

スキーマ (アノテーション定義)とはデータの構造を決定するものである．図 2.5

に RDFにおけるスキーマとデータの関係を示す．左側の RDFSでは，アノテー

ションの種類として「楽曲の基本情報」を定義し，その中では，アーティストや

タイトルなど複数の属性の記述を許可する．また各属性のデータ型の指定を行う．

図 2.5の右側は，そのスキーマに基づいたRDFである．RDFSで定められた「楽

曲の基本情報」というアノテーション定義に則り，アーティストやタイトルなど

の属性を指定されたデータ型で記述する．また，どのリソースを対象としたアノ

テーションであるかを同時に記述する．

Annphonyにおけるアノテーション定義の記述方法を以下に述べる．例として，

事前に決められた「陽気」「刺激的」「厳格」という 3種類の印象語のいずれかを

値として持つ「印象情報」という名前のアノテーションを定義する場合を挙げる．


RDFS

楽曲の基本情報

タイトル：文字列

アーティスト：文字列

アルバム：文字列

ジャンル：文字列

リリース：年

RDF

楽曲の基本情報

タイトル：あなたと逢えて

アーティスト：吉井弘美

アルバム：RWC-MDB

ジャンル：JPop

リリース：2001

対象：http://foo/bar.mp3

図 2.5: RDF SchemaとRDFの関係

まずこれら 3種類の印象語のうちいずれかの値のみを許可するデータ型を定義す

る．データ型の定義はXML Schema [45]により記述される．XML SchemaはXML

文書の構造を定義するスキーマ言語の一つであり，柔軟にデータ型を拡張すること

ができる特徴を持つ．一般的にRDFSではXML Schema において定義されるデー

タ型が利用されている．図 2.6に実際のデータ型の定義を示す．XML Schemaに

おいて定義された語彙をxsd: という接頭辞を用いて利用する．データ型の拡張に

は simpleTypeを用いる．この例ではXML Schemaで定義された基本データ型で

ある string型を xsd:restriction という語彙で拡張している．xsd:enumeration

により列挙された 3種類の語の中から一つを選択するためのデータ型が定義され

ている．

次に，これらの印象語を値として持つアノテーションの定義を図 2.7 のように

記述する．RDF，RDFSにより定義されている語彙は，rdf:や rdfs:という接頭辞

を用いて利用している．RDFSにおいて新しいアノテーション定義を行うために，

まず rdfs:Classを記述する．属性として，その定義を利用するために必要なURI

を，rdf:aboutという属性において記述する．rdfs:labelにはその定義の名前を，

rdfs:commentにはさらに詳細な説明を自然言語で記述する．次に，rdf:Property


図 2.6: データ型定義の例

図 2.7: ”impression”アノテーション型の定義の例

において，利用可能な属性を定義する．属性にも同様に，属性のURI，名前，説

明を記述する．また，どの定義に対してこの属性が適用されるかを rdfs:domain

の属性である rdf:resourceにおいて指定する．さらに，その属性がどのような

データ型であるかを rdf:rangeにおいて指定する．rdfs:Classである impression，

rdfs:Propertyである impression term，impression term のデータ型である im-

pressionType間の関係は図 2.8のようになる．impression termのドメインとし

て impression が，rangeとして impressionTypeが指定されていることがわかる．

ここで指定されているデータ型である impressionTypeは，図 2.6において定義し

た 3種類の印象語からいずれかを選択するデータ型として定義されている．以上

で印象情報のアノテーションが定義された．

上記のアノテーション定義に基づいた実際のアノテーションの例を図 2.9に示す．

an:はAnnphonyで定義されている語彙を，def: は上記のアノテーション定義を利


図 2.8: ”impression”アノテーション型の定義間の関係

用するための接頭辞である．この例では図 2.9で定義した印象情報アノテーション

を表すdef:impressionが指定され，ある楽曲 (http://bar/tune.mp3)に「厳格」と

いうアノテーションを付与している．属性である rdf:aboutのURIは，Annphony

が自動的に発行するアノテーションの識別子である．アノテーションの対象となる

リソースは an:targetに，また，アノテータのURIは an:annotatorにおいて指

定されている．楽曲そのものに対してのアノテーションである場合は，an:target

としてその楽曲のURIを，ある楽曲の区間に対するアノテーションの場合，2.1節

で述べた ElementPointer の URIを記述する．またそれらのリソースの集合を対

象とする場合，図 2.10 のように，RDFのコレクション表現のための形式である

rdf:Seq(順序付リスト)，rdf:Bag(順序無し集合)，rdf:Alt(代替表現リスト)を用

いて複数の対象を列挙する．印象語を記述する属性である def:impression term

には，図 2.6において定義された範囲の値を記述する．

このようにAnnphonyはアノテーション定義に基づくアノテーションを管理す

る．アノテーション定義は任意のユーザにより記述されるため，Annphony によ

りコンテンツの内部構造や解釈に対する幅広い種類のアノテーションを管理する

ことができる．2.1節で述べた ElementPointer の定義も，本アノテーション定義

と同様の形式で記述されることで，有限個の属性を列挙する定義によって任意の

コンテンツの任意の部分を指し示すことが可能になる．


図 2.9: Annphonyにおけるアノテーションの例

図 2.10: 複数のアノテーション対象の指定


2.3.3 Annphonyの機能

幅広くアノテーションを共有・利用するためには，アノテーションを利用する

環境を整備しなければならない．Annphonyでは，アノテーションやその定義を容

易に共有・検索・作成・利用する機能，またコンテンツの構造・解釈を扱うために

必要となる機能を提供する．さらに，アノテーションが潜在的に抱える問題に対

処するための機能を備えている．以下にAnnphonyの主要な機能について述べる．

ElementPointerの利用支援

AnnphonyはElementPointer を扱う機能を備える．ElementPointer定義のURI

と対象コンテンツのURIを指定し，またElementPointerの定義に沿った属性の値

を全て設定することでElementPointer URIが生成される．逆にElementPointer の

URI から，コンテンツのURIや各引数の値を取得することも可能である．さらに，

ElementPointer定義に記述されるElementPointerプロセッサを登録し，利用する

ための機能を備える．

アノテーション定義へのアノテーション

アノテーションの定義が登録される際，定義の作成者はその定義へのアノテー

ションを同時に記述する．具体的には定義者情報，自然言語による利用例などの

説明，「Jazz」，「ニュース」，「判例」など複数のタグによる適用可能なコンテンツ

の列挙を行う．

どのような場面においてその定義が利用可能であるかという情報は，定義の作成

者本人が全て網羅することは困難である場合が多い．そこでAnnphony では，定

義者以外の複数のユーザがそのスキーマに対して利用例やタグなどのアノテーショ

ンを行うことを許している．またElementPointerの定義へのアノテーションの場

合，上記のアノテーションに加え 2.2節で述べた ElementPointerプロセッサを指

定する．


またAnnphonyはそれらのアノテーションに基づくアノテーション定義の検索

機能を備えている．アノテーション定義を発見したいユーザは，キーワードでの

検索や，適用するコンテンツのタグ情報から絞り込むことで，目的の定義の発見

や，利用・拡張定義が可能となる．

アノテーション定義に基づくアノテーションの検索

幅広いコンテンツへのアノテーションを扱う環境では，動的にアノテーション

の定義が増加することが予想されるが，アノテーションの定義が追加される度に，

その定義に基づくアノテーションを利用するようアプリケーションを対応させる

ことは非常に高コストになる．

Annphonyでは，アノテーション定義の継承関係を考慮し，着目した定義の継承

元や継承先のアノテーションに関しても検索対象とすることができる．また，あ

る特定の属性に着目し，その属性が利用されている定義に基づくアノテーション

全てを検索対象にするなど，アプリケーションが，動的に追加されたアノテーショ

ン定義に基づくアノテーションを利用できる機能を備えている．

コンテンツの構造記述

様々なコンテンツの構造化に関する研究が行われているが，それらに多く見ら

れる手法として，コンテンツのグループ化，または階層化が挙げられる [8][24]．

Annphonyでは ElementPointerの採用により，コンテンツの任意の箇所のグルー

プ化に対応している．また，コンテンツやアノテーションを一つのノードとみな

し，それらの関係をツリー形式で記述し，そのツリーを利用する機能を備える．さ

らに，アノテーションの基本構造としてRDFを採用しているため，他のコンテン

ツとの間の複雑なグラフ構造の関係を扱うことができる．


アノテーション信頼度の導入

アノテータに関する情報は，コンテンツの変換や推薦など，個人の嗜好や解釈

を踏まえた応用を実現する際に必須となる．Annphonyではそれぞれのアノテー

タにURI を持たせ，そのプロファイルをアノテーションとして管理する機能を提

供する．

また，あるコンテンツに対し複数の解釈が存在する場合，それぞれの解釈が正

確であるか，または信頼できる情報であるかを判断する必要がある．そこで各ア

ノテーションとアノテータに「信頼度」という属性を付与する．信頼度の算出に

関しては，文献 [12]において提案された手法を採用した．

アプリケーションはアノテーションの信頼度に基づき，複数のアノテーション

の中から最も信頼性の高いアノテーションを採用したり，信頼度が閾値以上であ

る全てのアノテーションを採用したりするなど，複数の解釈の扱いを決定するこ

とができる．

2.4 アノテーションが持つ諸問題に関する考察

2.4.1 埋め込み式アノテーションと外部アノテーション

MP3形式の音楽ファイルにはアーティストやタイトルなどのメタデータをその

ファイル自身に埋め込むことができ，Exif(Exchangeable Image File Format)形式

の画像には，撮影日時やその画像についての情報を埋め込むことができる．この

ようなコンテンツの内部にアノテーションを埋め込む方式の場合，コンテンツと

アノテーションが切り離されないため，利用が容易であるが，コンテンツとアノ

テーションを同時に管理する必要がある．しかし様々な種類のコンテンツを対象

としたアノテーションを扱う場合，必ずしもコンテンツとアノテーションが同時

に管理されるとは限らない．そのため Annphonyではコンテンツとアノテーショ

ンを切り離した管理方法を採用している．


2.4.2 Orphan/Misleading Annotationへの対処

コンテンツとそのアノテーションが分離されている場合，コンテンツの改変・

移動・削除によって，そのコンテンツに関連付けられたアノテーションがOrphan

Annotation(指し先の無いアノテーション) やMisleading Annotation (誤解を生む

アノテーション)になってしまう危険性が指摘されている [18]．そこでAnnphony

ではこれらの問題の発生を抑えるために以下の機能を提供する．

Orphan Annotationへの対処のため，指し先が存在しないアノテーションを登

録することを許可しない．データベースへの登録時に，アノテーションの指し先の

リソースへアクセスを試み，存在を確認した後に登録される．指し先が Element-

Pointerによって記述されたURIの場合は，前述の ElementPointerプロセッサに

よって該当するコンテンツのセグメントの存在を確認する．

一般的にポータルサイトと呼ばれるページや，Webニュースのトップページな

どは，頻繁に更新される．このように，対象となるコンテンツやアノテーション

が編集されることで，そのリソースを指し示しているアノテーションが意味をな

さなくなったり，別の意味になったりしてしまうことをMisleading Annotationと

呼ぶ．Annphonyでは，アノテーションが編集・再登録された場合，そのアノテー

ションに関連するアノテーションを取得し，それらの確認・編集を管理者に促す．

また一定時間ごとに登録されたアノテーションを巡回してコンテンツの編集の

有無を確認し，編集や削除が確認されたコンテンツに関連するアノテーションに

関しても同様にそれらの確認・編集を促す．

2.5 実装

実装環境を表 2.1にまとめる．Annphonyは様々なアプリケーションやアノテー

ションエディタによるアノテーションやアノテーション定義の登録や検索の要求な

どをブラウザなどのWebクライアントから受け付けるため，Webサーバとして実

装されている．AnnphonyはXML-RPC(XML-Remote Procedure Call) [46]によっ


て要求を取得し，検索結果の送信などを行う．また，クライアント側はAnnphony

APIを用いることでサーバへの要求や，アノテーションの生成を行う．RDFをJava

で扱うためのAPIとして，Java によるセマンティックWeb アプリケーション開

発のためのフレームワークである Jena[47] を利用している．

実装言語 Java (JDK 1.5)

Java Servlet (Apache Tomcat 5.5)

HTTPサーバ Apache HTTP Server 2.1

使用ライブラリ Jena 2.2

データベース PostgreSQL 8.1

対応

Documents

デジタルコンテンツのアノテーション 基盤技術とそれに基づ …web.nagao.nuie.nagoya-u.ac.jp/papers/pdfs/kaji_doctoral...4.6 MusicXML における楽器パートの記述.....75

デジタルコンテンツのアノテーション基盤技術とそれに基づ …web.nagao.nuie.nagoya-u.ac.jp/papers/pdfs/kaji_doctoral...4.6 MusicXML における楽器パートの記述.....75