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

コンテンツの意味内容を機械的な処理に適用可能な形式で取り込むために，アノテーションに関する研究が進められている．アノテーションとは，図に示されるように，あるコンテンツに対して関連付けられるメタ情報である．

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

アノテーションに関する研究を分類すると，主に1. 規格化，2. 収集，3. 応用の3種類に分類されると考えられる．

[アノテーションの規格化]：アノテーションの規格化は，コンテンツに付与されるメタ情報の記述能力を左右する重要な点であるといえる．コンテンツの種類に依存したアノテーション形式と，コンテンツの種類に依存しないアノテーション形式に二分される．

コンテンツの種類に依存する形式としては，GDA(Global DocumentAnnotation)やMPEG-7が挙げられる．GDAはテキストに対する構文・意味情報を詳細に記述するための形式である．MPEG-7はマルチメディア・コンテンツに対するメタデータの表記方法に関する国際標準規格である．正式名称をMultimedia Content Description Interface という．マルチメディア・コンテンツの検索の際に直接の検索対象となる画像・音響特徴データを規格化された手段で表現可能である点が特徴である．MPEG-7によって画像データのメタデータを記述した例を図に挙げる．MPEG-7は，{Mpeg7}タグから始まるXML形式で記述され，{description}タグ内に画像から抽出される色ヒストグラム情報や，撮影日時，コンテンツ管理など，規格として定められた属性を入力することができる．

図1.2: MPEG-7の記述例

これらの形式は，コンテンツ内部の意味内容に関するアノテーションを記述することを目的としており，それぞれがコンテンツの種類に依存する形式となっている．そのため，横断的にこれらのコンテンツを扱うためには，専門性の高いそれぞれのアノテーション形式を熟知しなければならない．またコンテンツの種類は多様化を続けているため，コンテンツの種類の追加に伴い定義される新しいアノテーション形式に対応しなければならない．

一方で，コンテンツ自体の情報や，コンテンツ同士の関連性などを記述するアノテーション形式として，RDF (Resource Description Framework)が標準化されている．URI(Uniform Resource Identifier)を持つリソースであれば，コンテンツの形式を問わずアノテーションの対象に指定可能であるため，異種類のコンテンツ間の関連性を表現することができる．従来，コンテンツ間の関連は，HTMLのハイパーリンク構造により導き出されることが一般的であるが，ハイパーリンクには，リンクの意味を記述することができない点が問題であった．RDFのデータ構造は，図に表すように，主語・述語・目的語の組みによって，ラベル付き有向グラフとして表現される．例えばある楽曲の制作者を記述する場合，楽曲のURIを主語に，制作者のURIを目的語に，それらの間の関連性として，制作者であることを示す{dc:creator}という述語を記述する．またアノテーションの述語に相当する部分の柔軟な定義が可能であり，様々な関連性に関する情報を表現することができる．このことから様々な種類のコンテンツ同士の関連の把握を容易にし，多様なアプリケーションに適用可能な形式であるといえる．しかしURI によってコンテンツを指し示すため，それ以上に詳細なコンテンツ内部に関する記述が困難である．そのためコンテンツの種類を横断するアノテーション形式であるRDF はコンテンツの内部構造までを扱うことができない．

図1.3: RDFのデータ構造

図に示すように，コンテンツの内部構造を記述するためのアノテーション形式であるGDAやMPEG-7はコンテンツの種類に依存する．また新規のコンテンツが出現した場合には，そのコンテンツに特化した新しいアノテーション形式が提案されるだろう．一方でコンテンツ間の関連性を記述するためのRDFには，一般にコンテンツの内部構造を扱うことができず，双方の間には大きな壁が存在する．このように多様化するコンテンツとその内部構造や，コンテンツ同士の関連性を統一的に扱う仕組みが求められるが，現在そのような仕組みが存在しないという問題がある．

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

また，アノテーションには計算機によって自動的に生成されるものと人間の手によって作成されるものが存在する．計算機の自動解析によってコンテンツの構造を認識する研究が多く存在するが，一方では自動解析によって得ることの困難な情報を，人間の手によって付与するシステムに関する研究が盛んになってきている．アノテーションを付与するための特別なエディタを用意し，詳細な構造情報等を付与するというものである．

[アノテーションの収集]：人手によるアノテーションには，アノテーションの付与のコストという問題が存在する．人手により詳細な情報を付与可能である反面，膨大な量のコンテンツをアノテーションの対象としなければならない．その解決策の一つとしてFolksonomy が挙げられる．del.icio.usやFlickr において，Web 上の多くのユーザがそれぞれのコンテンツにタグと呼ばれる分類キーワードを付与することで，そのタグを基に分類やコンテンツへのアクセスを可能にする仕組みを構成している．Web上の文書や写真といったコンテンツに何が表現されているかは，計算機がそれを自動解析することが困難であるが，その制作者や閲覧者は容易に理解することができる．そのような情報を幅広いユーザの手によって記述することで，アノテーション付与のコストを軽減することが可能である．このように多くの人の分類作業を蓄積して再利用可能にする仕組みをFolksonomy と呼ぶ．またWeb上の文書に対して，多くのユーザから少しずつ文書情報を収集するシステムも研究が進められており，一般大衆から得られる情報を蓄積することで形成される「集合知」に期待が寄せられている．

[アノテーションの応用]：アノテーションの応用としては，ビデオのシーン検索など，膨大な量のコンテンツの内容を考慮したコンテンツ検索がある．またアノテーションを用いることで，目的に合わせてコンテンツを変換することも可能になる．文書に対する構文や単語の意味に関するアノテーションを用いた応用として，SemCodeがある．それは文書の翻訳・要約・音声化・言い換えや，表示端末への適応を行っている．また複数のコンテンツを組み合わせることで新しいコンテンツを生成するための規格化や研究が進められている．

以上のことから，現状では多様なコンテンツを対象とした場合にはコンテンツの内部に関する情報を扱うことが困難であり，逆にコンテンツの内部構造を扱うためにはコンテンツの種類を横断することが困難であることが分かる．今後は多様なコンテンツを対象とし，かつコンテンツの内部に関する情報を扱うことが求められようになると思われる．

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

音楽は個人の嗜好・状況への適応が強く求められるコンテンツであり，機械的に音楽利用を支援する研究が進められている．以下に音楽情報処理研究の動向を述べる．

音楽メディアは，MP3等の音響信号などの連続メディア以外に，音楽の離散的な構造を記述する形式が提案されている．特に音楽の詳細な楽譜構造を表現する形式として，WEDELMUSIC XML とMusicXMLがある．これらの形式は楽譜を構成する情報を記述することができ，またXML形式で記述されているため，計算機は音符や小節，楽器パートなどの詳細な楽曲構造を把握でき，また楽曲の一部を変更するなどのコンテンツ変換の操作が容易に実現可能である．また音楽の構造化に関する研究も進められており，今後も変更・拡張されていくだろう．そのため音楽のみを扱ったコンテンツ処理であっても，このような多様なメディアに横断的に対応しなければならない．

楽曲のタイトルやアーティスト・ジャンルなどのアノテーションを付与する方法として，MP3はID3タグを埋め込む方式をとっている．一方CDDBやMusicBrainzは楽曲の書誌情報などを外部アノテーションとして一括管理し，そのアノテーションを対象とした楽曲検索が可能である．CDDBは拡張性に乏しく，新しい属性を追加することができないが，MusicBrainzではRDFをデータ形式として利用しており，新しい属性を定義することで，柔軟に拡張することができる．このような拡張性は，アノテーションの利用法を特定せず，幅広いアプリケーションに適用可能になるという利点がある．一方で，柔軟に定義可能なアノテーションは，あらかじめ定義が固定されたアノテーションと比較して，他人が定義したアノテーションをどのように共有し，利用を支援するかに関して問題があるといえる．

音楽コンテンツの意味内容の中には，自動認識することの困難な情報が多く存在する．例えば楽曲から受ける印象は，テンポや曲調，歌詞の内容，時代背景などを踏まえて判断する必要があり，一般に自動的に解析することが困難である．また音楽は特に芸術作品としての側面を持ち，コンテンツ自体に多義性が残されていることが多く，人が解釈することによって初めてコンテンツの内容を把握することが可能になる場合が多い．そのため音楽は人手によるアノテーション付与が特に有効となる．音楽に関するアノテーションを人手により付与する研究がいくつか存在するが，コンテンツの内部構造に対するアノテーション付与ができない，人によって異なる解釈を管理することができないなどの問題点が存在し，音楽の意味内容を記述するためには不十分である．

また音楽のメディア形式の多様性や拡張性の点から，図に示したアノテーションの壁は，音楽のみを対象とした場合も存在しており，音楽を対象としてこの壁を取り除くことは，一般的なコンテンツに対するアノテーションの壁を取り除くことにもつながると考えられる．

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

音楽コンテンツの応用として，楽曲の推薦や配信など，楽曲単位あるいはその集合単位の利用法に関するサービスや研究が盛んに行われている．近年，特にiPodなどのポータブル音楽プレイヤの普及によりプレイリストの有効性が注目されている．また，様々なCGMの中でも，作曲や演奏をしたり，小説を書くといった敷居の高いコンテンツ制作に比べ，作成が容易であるプレイリストは，より手軽な音楽を楽しむ手段として注目されている．

プレイリストとは，ユーザによって事前に選択された曲目リストである．プレイリストを利用することで，一曲ずつ再生する楽曲を決定するといった煩雑な操作を必要とせず，より容易に楽曲が鑑賞できるようになった．そのためプレイリストの自動作成や推薦に関する研究が進められている．これらの研究では，音楽の音響信号の類似度や，ジャンル・アーティストといった基本情報，ユーザの嗜好，またユーザ同士の類似度などを用いることで，それぞれのユーザに適合したプレイリストを作成，推薦している．

音楽以外の他の種類のコンテンツにも，プレイリストと同様の概念が存在する．写真のアルバム，複数人の作品を集めた歌集や詩集，テレビのコマーシャルフィルムを集めたCM集などである．また，あるテーマに関連したコンテンツを列挙させるプレイリストなど，プレイリストを構成する要素が複数の種類になる場合も考えられる．これらのことから，プレイリストの作成や利用に関する研究は，音楽情報処理の枠を超えて，コンテンツ処理に関する研究全体に対して貢献すると考えられる．

このように，音楽コンテンツを利用したアプリケーションとして，プレイリスト作成の計算機による支援や，作成されたプレイリストの他のユーザへの推薦などの研究を進めることは非常に有意義であり，コンテンツの種類を横断するクロスコンテンツ処理へ発展する可能性もある．

2.2.1 ElementPointer の形式

ElementPointerをXPointerの書式を参考にして定義する．XPointerは以下の形式でXMLドキュメントの任意のノードを指し示す．

[Content]\#xpointer([XPath])

コンテンツのURIである[Content]に続き，{\#xpointer}以降[XPath]にXMLドキュメント内部ノードを指し示す手段として標準化されているXPath を記述することで，内部構造への言及を可能にしている．全ての中括弧は表記には含まない． 例えば図 のように，XML ドキュメント(http://localhost/test.xml)の，ルートノード(doc)の子ノードであるperson の中で，id属性がkajiであるものを指し示すXPointerが示されている．XPointer は一般的に以下のように表現される．

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

一方で，任意のコンテンツの任意の箇所を指し示すXPathに相当する形式が存在しない．そこでElementPointerではコンテンツ内部を指し示すための定義を別途用意し，その定義を引用する．また，例えば図でハイライトされている，「MIDIのチャンネル１における，楽曲開始後10秒から20秒までの時間範囲」のようなセグメントを指し示すためには，MIDIのチャンネル番号，開始時間，終了時間という属性名，属性値が必要となる．そこで，ElementPointerは以下のように，定義と，属性名・属性値の組を列挙する形式をとる．

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

[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)をElementPointerの定義に採用した．リソース間の関係をグラフ構造として表現するRDFやRDFSを用いることで，その検索言語であるSPARQL(SPARQL Query Language forRDF)によって，コンテンツの構造を扱う際に有効なグラフ検索が可能になる．そのためElementPointerの定義を共有することに適していると考えられる．Annphonyにおいてその定義の検索や利用を支援し，任意のユーザによるElementPointerの定義の利用を支援する．

ElementPointerの具体例を示す．前述の「MIDIのチャンネル１における，楽曲開始後10秒から20秒までの時間範囲」を指し示すため，MIDIチャンネル別の時間範囲を表すElementPointerを定義する．本定義で利用される属性とそのデータ型として，MIDIのチャンネル番号(1から16までのinteger型)，時間区分の開始時間(double型)，終了時間(double型)を記述する．また時間区分の開始時間，終了時間は楽曲の演奏の開始からの秒数であることを同時に記述する．具体的なRDFSの書式については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\%2Fschema\%2Fmidi.rdfs\%23midi\%28\%28http\%3A\%2F\%2Flocalhost\%2Fannphony\%2Fschema\%2Fmidi.rdfs\%23channel\%2C1\%29\%2C\%28http\%3A\%2F\%2Flocalhost\%2Fannphony\%2Fschema\%2Fmidi.rdfs\%23from\%2C10.0\%29\%2C\%28http\%3A\%2F\%2Flocalhost\%2Fannphony\%2Fschema\%2Fmidi.rdfs\%23to\%2C20.0\%29\%29)

また，例えば画像の矩形範囲を指定するためには，画像のX 座標，Y座標，幅，高さが決定される必要がある．そこで同様にX座標，Y座標，幅，高さの4種類の属性を記述し，さらにそれぞれの値のデータ型を指定する．またそれぞれの値は，画像の左上を頂点とし，それぞれの数値がピクセル単位であることを記述することで，画像の矩形範囲を表すElementPointerを定義する．

2.2.2 ElementPointer プロセッサ

またElementPointerによって指し示された部分を扱う処理系を同時に作成し，後述するElementPointerの定義へのアノテーションとして関連付けを行えば，Annphonyにおいてそのセグメントのプログラム中での取得・利用が可能になる．ElementPointer プロセッサは，指定された部分の存在確認や，実際に指定された部分の取得など，部分同士の演算を行うためのメソッドで構成される．例えば上記の例のように矩形範囲指定により二次元のメディアを指し示すElementPointerプロセッサとして，その矩形範囲の画像を取得して表示するプログラムを用意しておくことで，該当部分が抜き出された画像を容易に扱うことが可能になる．

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

リソースの関係を有向グラフで表現するアノテーション形式としてRDFが提案されている．1.1.1節で述べたように，URIを持つリソースであれば，コンテンツの形式を問わずアノテーションの対象に指定可能であるため，異種類のコンテンツ間の関連性を表現することができる．しかし2.1節で述べたように，RDF は一意の解釈や定義の記述を目的とした形式であり，多様な解釈を記述することに適していない．一方RDFを拡張した形式として提案されているNamed Graphs は，任意のグラフのまとまりを一意に識別し，他と区別するために，グラフのまとまりに識別子を付与することができる．図のように，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では図の右側のようにA，B，Cの各部分を分離してURIを付与することも可能であるが，左側のようにA，B，C というアノテーションをまとめたものに対して一つの識別子を付与することもできてしまう．この場合識別子が付与されていないA，B，Cの各部分への言及が困難である．Annphony では，図 の右側のように，それぞれのリソース記述を明確に分離する．具体的には，あるアノテータが，ある主語(リソース)に対して述語・目的語の組を列挙したものを一つのアノテーションとし，それぞれのアノテーションにURI を発行する．

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

音楽のプレイリスト中に含まれる複数の楽曲を対象としてコメントを付与する場合など，複数の楽曲という単一ではないリソースを主語としたアノテーションが想定される．そこでAnnphonyではアノテーションの主語として複数のリソースを指定することを許可している．また図の左側においてA，B，C が何らかの意図を持ってまとめられていたということも，A，B，Cという複数のリソースを主語とするアノテーションにより表現可能である．

コンテンツの代表的な構造として，グルーピング構造，ツリー構造，グラフ構造が挙げられる．RDFはリソース間の関係をグラフ構造で表現する形式であり，グラフ構造はツリー構造を内包するため，RDFはこれらの構造を扱うことのできる形式であるといえる．しかしRDFでは，主語に直接複数のリソースを指定できないという，グルーピング構造を表現するために問題がある．そこでAnnphonyではそれに加え，前述のElementPointerによるコンテンツのセグメント指定と，主語に複数のリソースの記述を許すアノテーション形式により，コンテンツのグルーピング構造を表現する．例えば楽譜中に表れる音符や休符群をまとめて，そのグループに対してイントロやサビなどの楽曲構成情報などを関連付けることが可能になる．以上よりAnnphonyはコンテンツの代表的な構造に関する情報を扱える基盤である．

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

従来のコンテンツの内部構造に言及するアノテーション記述形式は，アノテーション記述のための全ての仕様が固定されており，拡張性が低い．そのためこれらの形式で記述することのできないアノテーションを利用することが困難である．そこで，Annphonyのアノテーション形式のベースであるRDFのスキーマ言語であるRDFSを，アノテーション定義のための言語に採用した．取得すべきアノテーションの形式をRDFSで記述することにより，Annphonyはそれに基づく検索やアノテーション利用を支援する．

スキーマ(アノテーション定義)とはデータの構造を決定するものである．図にRDFにおけるスキーマとデータの関係を示す．左側のRDFSでは，アノテーションの種類として「楽曲の基本情報」を定義し，その中では，アーティストやタイトルなど複数の属性の記述を許可する．また各属性のデータ型の指定を行う．図の右側は，そのスキーマに基づいたRDFである．RDFSで定められた「楽曲の基本情報」というアノテーション定義に則り，アーティストやタイトルなどの属性を指定されたデータ型で記述する．また，どのリソースを対象としたアノテーションであるかを同時に記述する．

図2.5: RDF SchemaとRDFの関係

Annphonyにおけるアノテーション定義の記述方法を以下に述べる．例として，事前に決められた「陽気」「刺激的」「厳格」という3種類の印象語のいずれかを値として持つ「印象情報」という名前のアノテーションを定義する場合を挙げる．

まずこれら3種類の印象語のうちいずれかの値のみを許可するデータ型を定義する．データ型の定義はXML Schema により記述される．XML SchemaはXML文書の構造を定義するスキーマ言語の一つであり，柔軟にデータ型を拡張することができる特徴を持つ．一般的にRDFSではXML Schema において定義されるデータ型が利用されている．図に実際のデータ型の定義を示す．XML Schemaにおいて定義された語彙を{xsd:} という接頭辞を用いて利用する．データ型の拡張には{simpleType}を用いる．この例ではXML Schemaで定義された基本データ型であるstring型を{xsd:restriction} という語彙で拡張している．{xsd:enumeration}により列挙された3種類の語の中から一つを選択するためのデータ型が定義されている．

図2.6: データ型定義の例

次に，これらの印象語を値として持つアノテーションの定義を図 のように記述する．RDF，RDFSにより定義されている語彙は，{rdf:}や{\bfrdfs:}という接頭辞を用いて利用している．RDFSにおいて新しいアノテーション定義を行うために，まず{rdfs:Class}を記述する．属性として，その定義を利用するために必要なURIを，{rdf:about}という属性において記述する．{rdfs:label}にはその定義の名前を，{rdfs:comment} にはさらに詳細な説明を自然言語で記述する．次に，{rdf:Property}において，利用可能な属性を定義する．属性にも同様に，属性のURI，名前，説明を記述する．また，どの定義に対してこの属性が適用されるかを{rdfs:domain}の属性である{rdf:resource}において指定する．さらに，その属性がどのようなデータ型であるかを{rdf:range}において指定する．rdfs:Classである{\bfimpression}，rdfs:Propertyである{impression_term}，impression_termのデータ型である{impressionType}間の関係は図のようになる．impression_termのドメインとしてimpression が，rangeとしてimpressionTypeが指定されていることがわかる．ここで指定されているデータ型であるimpressionTypeは，図において定義した3種類の印象語からいずれかを選択するデータ型として定義されている．以上で印象情報のアノテーションが定義された．

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

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

上記のアノテーション定義に基づいた実際のアノテーションの例を図に示す．{an:}はAnnphonyで定義されている語彙を，{def:} は上記のアノテーション定義を利用するための接頭辞である．この例では図で定義した印象情報アノテーションを表す{def:impression}が指定され，ある楽曲(http://bar/tune.mp3)に「厳格」というアノテーションを付与している．属性である{rdf:about}のURIは，Annphonyが自動的に発行するアノテーションの識別子である．アノテーションの対象となるリソースは{\bfan:target}に，また，アノテータのURIは{an:annotator}において指定されている．楽曲そのものに対してのアノテーションである場合は，{\bfan:target}としてその楽曲のURIを，ある楽曲の区間に対するアノテーションの場合，2.1節で述べたElementPointer のURIを記述する．またそれらのリソースの集合を対象とする場合，図 のように，RDFのコレクション表現のための形式である{rdf:Seq}(順序付リスト)，{rdf:Bag}(順序無し集合)，{rdf:Alt}(代替表現リスト)を用いて複数の対象を列挙する．印象語を記述する属性である{def:impression_term}には，図において定義された範囲の値を記述する．

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

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

このようにAnnphonyはアノテーション定義に基づくアノテーションを管理する．アノテーション定義は任意のユーザにより記述されるため，Annphony によりコンテンツの内部構造や解釈に対する幅広い種類のアノテーションを管理することができる．2.1節で述べたElementPointer の定義も，本アノテーション定義と同様の形式で記述されることで，有限個の属性を列挙する定義によって任意のコンテンツの任意の部分を指し示すことが可能になる．

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では，アノテーション定義の継承関係を考慮し，着目した定義の継承元や継承先のアノテーションに関しても検索対象とすることができる．また，ある特定の属性に着目し，その属性が利用されている定義に基づくアノテーション全てを検索対象にするなど，アプリケーションが，動的に追加されたアノテーション定義に基づくアノテーションを利用できる機能を備えている．

[コンテンツの構造記述]：様々なコンテンツの構造化に関する研究が行われているが，それらに多く見られる手法として，コンテンツのグループ化，または階層化が挙げられる．AnnphonyではElementPointerの採用により，コンテンツの任意の箇所のグループ化に対応している．また，コンテンツやアノテーションを一つのノードとみなし，それらの関係をツリー形式で記述し，そのツリーを利用する機能を備える．さらに，アノテーションの基本構造としてRDFを採用しているため，他のコンテンツとの間の複雑なグラフ構造の関係を扱うことができる．

[アノテーション信頼度の導入]： アノテータに関する情報は，コンテンツの変換や推薦など，個人の嗜好や解釈を踏まえた応用を実現する際に必須となる．AnnphonyではそれぞれのアノテータにURI を持たせ，そのプロファイルをアノテーションとして管理する機能を提供する．

また，あるコンテンツに対し複数の解釈が存在する場合，それぞれの解釈が正確であるか，または信頼できる情報であるかを判断する必要がある．そこで各アノテーションとアノテータに「信頼度」という属性を付与する．信頼度の算出に関しては，文献において提案された手法を採用した．

アプリケーションはアノテーションの信頼度に基づき，複数のアノテーションの中から最も信頼性の高いアノテーションを採用したり，信頼度が閾値以上である全てのアノテーションを採用したりするなど，複数の解釈の扱いを決定することができる．

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

MP3形式の音楽ファイルにはアーティストやタイトルなどのメタデータをそのファイル自身に埋め込むことができ，Exif(Exchangeable Image File Format)形式の画像には，撮影日時やその画像についての情報を埋め込むことができる．このようなコンテンツの内部にアノテーションを埋め込む方式の場合，コンテンツとアノテーションが切り離されないため，利用が容易であるが，コンテンツとアノテーションを同時に管理する必要がある．しかし様々な種類のコンテンツを対象としたアノテーションを扱う場合，必ずしもコンテンツとアノテーションが同時に管理されるとは限らない．そのためAnnphonyではコンテンツとアノテーションを切り離した管理方法を採用している．

2.4.2 Orphan/Misleading Annotation への対処

コンテンツとそのアノテーションが分離されている場合，コンテンツの改変・移動・削除によって，そのコンテンツに関連付けられたアノテーションがOrphanAnnotation(指し先の無いアノテーション) やMisleading Annotation (誤解を生むアノテーション)になってしまう危険性が指摘されている．そこでAnnphonyではこれらの問題の発生を抑えるために以下の機能を提供する．

コンテンツとそのアノテーションが分離されている場合，コンテンツの改変・移動・削除によって，そのコンテンツに関連付けられたアノテーションがOrphanAnnotation(指し先の無いアノテーション) やMisleading Annotation (誤解を生むアノテーション)になってしまう危険性が指摘されている．そこでAnnphonyではこれらの問題の発生を抑えるために以下の機能を提供する．

一般的にポータルサイトと呼ばれるページや，Webニュースのトップページなどは，頻繁に更新される．このように，対象となるコンテンツやアノテーションが編集されることで，そのリソースを指し示しているアノテーションが意味をなさなくなったり，別の意味になったりしてしまうことをMisleading Annotationと呼ぶ．Annphonyでは，アノテーションが編集・再登録された場合，そのアノテーションに関連するアノテーションを取得し，それらの確認・編集を管理者に促す．

また一定時間ごとに登録されたアノテーションを巡回してコンテンツの編集の有無を確認し，編集や削除が確認されたコンテンツに関連するアノテーションに関しても同様にそれらの確認・編集を促す．

3.2.1 Annphony の利用

前章で述べたAnnphonyの有用性を向上させることと，音楽を具体的な題材として，一般のコンテンツに対するアノテーション獲得・管理するための指針を示すために，アノテーション管理のための基盤としてAnnphonyを利用した．また多様なアノテーションを収集するために，Annphonyで管理されるアノテーション定義に基づくアノテーションを収集するシステムとなっている．アノテーション定義とアノテーションシステムを分離し，Annphonyにおいて管理されるアノテーション定義に基づいてアノテーションのメニューを動的に構成するため，収集するアノテーションの種類を限定せず，幅広いアプリケーションで利用可能なアノテーション収集を支援する．

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

本システムではメタ情報を幅広いユーザから集め，その情報を様々に応用していくことを目的としている．しかしアノテーション獲得のためのシステムがスタンドアロンのシステムであった場合，ソフトウェアのインストール作業やサーバへの接続作業などに手間がかかるためユーザがそのシステムを利用する際の足かせとなり，結果多くの情報を集めることが困難である．

そこで，ネットワークにつながっている人なら煩雑な手続き無しでアノテーションが行えるように，Webブラウザベースシステムの形態をとった．多数のユーザから少量のライトウェイト・アノテーションを収集することにより，一人一人にかかる人的コストを低く抑える．

多人数のユーザを対象とする場合，アノテーションの信頼性を考慮する必要がある．そのため前準備として，ユーザはあらかじめユーザ登録を行い，本システムを利用する際にはベーシック認証を通してログインする．誰がどのアノテーションを作成したかを全て記述するためである．

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

様々な種類のアノテーションを取得するために，対象となるリソースの粒度に応じたエディタを構築する必要がある．楽曲に対するアノテーション付与の代表例として，CDDB やMusicBrainz が挙げられる．これらのように，書誌情報などの基本情報を楽曲自体に対するアノテーションが必要であり，一方でコンテンツの意味内容に基づく応用のためには，コンテンツの内部構造に関するアノテーションが必要である．

そこで我々は，楽曲の形態や取得するアノテーションの種類に応じて様々な粒度のアノテーション取得を支援するため，1．Tune Annotator，2．TimelineAnnotator，3．Score Annotatorの3種類のエディタを構築した．図 は音楽アノテーションシステムのトップページである．システムは登録されている楽曲を列挙し，さらにそれぞれの楽曲のメディア形式から，適用可能なアノテーションエディタを識別してそれぞれのアノテーションエディタへのリンクを生成する．それぞれのアノテーションエディタを利用する前提と，付与されるアノテーションの粒度を表に示す．ユーザは本ページを通してアノテーションを行う楽曲とエディタを選択する．アノテーション対象となる楽曲は随時追加可能である．

図3.4: 音楽アノテーションシステムのトップページ

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

以下にそれぞれのアノテーションエディタの詳細を述べる．

[Tune Annotator]：Tune Annotatorは書誌情報など楽曲自体に関する情報を収集するためのエディタである．タイトルやアーティスト情報などの，楽曲の基本情報の記述にとどまらず，楽曲の推薦度やアンケートなどの柔軟なアノテーション取得を支援する．図にTune Annotatorの画面例を示す．画面の左側には，タイトルやアーティストなどの楽曲の基本情報，再生用のプレイヤが配置され，右側にはアノテーションメニューがHTMLのフォームとして表示され，ユーザはこのフォームを通してアノテーションを記述する．

図3.6: Tune Annotatorの画面例

ユーザは記述するアノテーションの項目を動的に変更することができる．図の左側はタイトルやアーティストなどの楽曲の基本情報を入力するためのアノテーションメニューが表示されているが，ユーザが「アノテーションの種類」の部分のプルダウンメニューから，記述したいアノテーションの種類を選択すると，Tune Annotatorは図の左側のように自動的に該当するアノテーションの属性のフォームに変更する．

図3.7: アノテーションメニューの動的な変更

本エディタを利用するための条件は，楽曲がURIで表現されることである．つまり，Web上に存在する全てのメディア形式の楽曲に対してTune Annotatorを利用したアノテーション収集が可能である．

[Timeline Annotator]：楽曲の最も単純なセグメンテーション手法は時間による区分であり，エンドユーザにとって直感的に理解可能である．そこで，MP3などの連続メディアに対する時間的なセグメンテーションと，セグメントに対しアノテーションを付与するエディタであるTimeline Annotatorを構築した．図にTimeline Annotatorの画面例を示す．上部の音楽プレイヤで楽曲を鑑賞しながら，[FROM][TO]ボタンにより開始，終了時間を指定することで時間的なセグメントを切り出す．さらに[ANNOTATE]ボタンを押すと，図に示すアノテーションフォームが現れる．ユーザはアノテーションの種類を選択すると，アノテーションの属性の入力フォームを自動的に構成する．ユーザが各項目に入力することでアノテーションを行う．図に例示した音符情報は，3.3 節において連続メディアの構造化を行うためのアノテーションの一つである．

図3.8: Timeline Annotatorの画面例

図3.9: Timeline Annotatorのアノテーションメニュー例

付与されたアノテーションは，図の下部にリンクとして表示され，リンクにマウスポインタを当てることで内容の確認を行う．

楽曲の時間区分の表現形式として，前章で述べたElementPointerを利用している．セグメントの開始時間，終了時間という二つの属性を持つElementPointer を定義することで，楽曲の時間的な区間をURIにより表現することが可能になる．Timeline Annotatorはこの連続メディアの時間区分を表すElementPointer URIを対象としたアノテーションを記述することで，楽曲の内部へのアノテーションを実現している．

全ての小節にアノテーションを付与する場合など，開始時間，終了時間の指定を一定の間隔で行うために，本エディタは一括で時間的セグメンテーションを行う機能を備えている．図に表れるセグメント幅と開始時間の秒数を指定して，「自動セグメント切り出し」ボタンを押すことによって，画面下部に一定間隔で切り出されたセグメントが表示される．ユーザはそれぞれのセグメントをクリックし，そのセグメントへのアノテーションを記述する．

図3.10: 時間的セグメントの一括切り出し

本エディタを利用するためには，1．楽曲がURIを持ち，2．音楽プレイヤで再生可能な連続メディアである必要がある．広く普及しているMP3やMIDIなどのメディア形式に対応するため，実用性の高いエディタであるといえる．

[Score Annotator]：Score Annotatorは，楽譜に現れる要素の集合に対するアノテーションを付与するためのエディタである．アノテーションの付与が可能な楽譜の要素は，各楽器パートの音符，歌詞，タイトル，作詞者，作曲者，発想記号である．ユーザには図のように楽譜とアノテーションを可視化したオブジェクトが重ねて表示される．ユーザがブラウザに表示された楽譜から，マウスのドラッグにより矩形の範囲指定を行うと，矩形内に存在する要素または要素集合が選択され，赤色で強調表示される．複数の矩形範囲を同時に選択することも可能であるため，楽譜上で遠い位置に存在する要素に対して同時にアノテーションを付与することが可能である．次に図のように，矩形上でマウスを右クリックし，出現するメニューからアノテーションの種類を決定し，その後具体的な情報を記述する．

図3.11: Score Annotatorの画面例

図3.12: 選択したオブジェクトへのアノテーション付与

感想や解説などのアノテーションは，人間が記述する情報であるために，それが不十分であったり誤っていたりする場合があるだろう．2.3節で述べたように，Annphonyで管理されるアノテーションには，全て識別子が自動的に付与されるため，アノテーションに対するアノテーションを付与可能である．しかしアノテーションエディタにもアノテーションへのアノテーションを行う仕組みが必要である．そのため本エディタは，アノテーションを補足，修正するために，画面に出現するアノテーションオブジェクトに対してアノテーションを関連付ける機能を持つ．

アノテーションを楽譜上に重ね合わせる場合，アノテーションの量が増えると楽譜が見づらくなってしまうという問題がある．そこで，本エディタでは表示するアノテーションを，アノテータやアノテーションの種類からフィルタリングする機能を持つ．図は本エディタの左側に表れるアノテーション表示のメニューである．このメニューから，楽譜上に表示するアノテーションをマウスクリックにより選択すると，表示されるアノテーションをフィルタリングする．図は，kaji，shimizuというアノテータが付与した，和音情報と楽曲の大まかな構造に関するアノテーションのみを表示した例である．

図3.13: アノテーション表示メニュー部

図3.14: アノテーションのフィルタリング

本エディタを利用するためには，1．URIを持ち，2．メディア形式がMusicXML である必要がある．MusicXMLは楽譜を形成するために十分な情報が記述されており，楽曲の構造を表現する形式であるといえる．音楽的に構造化されたメディアに対するアノテーションを行うことにより，楽曲そのものや時間区分といった大まかな対象ではなく，楽譜という音楽の論理構造に基づいた詳細な対象への言及を実現している．音楽的に意味のある箇所へのアノテーションにより，楽曲の意味内容に基づく，より高度な音楽アプリケーションの実現が期待される．

3.5.1 実験方法

「ハイライト」の認識に関する実験を行った．楽曲のどの部分を，どのような理由でハイライトと認識するかが解釈に相当する．本実験では，ハイライトの定義を「楽曲の最も印象的な部分」とした．以下に実験の詳細を述べる．またハイライトと認識する理由の一つに「サビである」という理由が予想されるが，本実験ではサビの定義を「楽曲の中で繰り返しの最も多い区間」としている．

実験に利用する楽曲は，過去5年におけるオリコン年間売り上げの上位10曲ずつ，計50曲であり，被験者は20代の男女10名である．それぞれの被験者は，時間区分に対するアノテーションエディタであるTimeline Annotatorを用い，各楽曲について，ハイライトであると認識した時間区分を切り出し，同時にその部分をハイライトであると認識した理由を自然言語により記述する．ハイライト区間は，各楽曲につき一箇所であり，切り出しの長さに制限を設けていない．50曲の楽曲に対して500箇所のハイライト区間と，645個の理由を収集した．ハイライトであると認識した理由には複数の記述を許しているため，理由の合計は500個を超えている．

3.5.2 実験の結果と考察

収集されたアノテーションを基に，ハイライトと認識した理由を人手で分類したところ，以下の9種類に分類された．

• サビである

• 聴いたことがある

• 歌詞が良い

• 歌い方が特徴的

• 盛り上がるから

• メロディが良い

• リズム・テンポが良い

• 個人的な思い入れ

• 演奏が特徴的

図はハイライトと認識した理由ごとのハイライト区間の数を表している．従来からハイライトであることが多いとされる「サビである」という理由以外にも，「聴いたことがある」「歌詞が特徴的」「歌い方が特徴的」という理由に基づく認識が多いことが分かる．

図3.16: 理由ごとのハイライト区間数

次にユーザごとのハイライト認識理由の個人性について考察する．図にユーザAが，図にユーザB がハイライトだと認識した理由の割合を示す．ユーザAは「サビである」「聴いたことがある」という理由でハイライトであると認識された箇所が多く，一方ユーザBは「歌詞が良い」，「歌い方が特徴的」という理由でハイライトであると認識する可能性が高いことが読み取れる．このようにユーザごとのアノテーションを解析することにより，それぞれのユーザの個人性を浮き上がらせることができることを確認した．

図3.17: ユーザAにおける理由ごとのハイライト区間数

図3.18: ユーザBにおける理由ごとのハイライト区間数

次に切り出されたハイライト区間についての考察を行う．図 に，ある楽曲のサビ区間と理由別のハイライトを可視化した図を示す．楽曲中で，多くの被験者がハイライトだと認識した区間ほど濃い色で表されている．一段目には理由に関わらずハイライトだと認識された区間を表示し，二段目にはサビであるという理由で，三段目には歌詞が特徴的であるという理由で認識されたハイライト区間を表示している．一段目から，ハイライトであると認識された区間は楽曲の多くの区間に渡っていることが分かる．また二段目と三段目には重複する区間が少なく，大きな違いがあることが分かる．このことからハイライトと認識する理由によって切り出される区間の多様性を，アノテーションの分類という統計的な処理によって浮き上がらせることができたといえる．

図3.19: ハイライトと認識された区間の分布

楽曲の解釈に関する多様性や個人性を利用することにより，それぞれのユーザに適応するアプリケーションの実現が可能になると考えられる．例えば楽曲のハイライトを試聴支援に用いる場合，サビを高い確率でハイライトと認識するユーザA にとっては，図の区間A，Bを中心に試聴させることが効果的であり，歌詞に基づきハイライトを認識するユーザBにとっては区間Cを中心に試聴を促すことが効果的であると考えられる．実際に図にはユーザAが本実験で切り出したハイライト区間Dは，ユーザAにとって試聴支援に効果的であると思われる区間A，Bに含まれており，またユーザBのハイライト区間Eも同様に，試聴支援に効果的であると思われる区間Cに含まれている．

本実験により，楽曲の内部構造に関する解釈の多様性と各ユーザの個人性を，本システムで収集されるアノテーションを解析することによって浮き上がらせることが可能であること，またこうして導き出された個人性をアプリケーションに適用可能であることが確認された．

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

ユーザが本検索システムにログインすると，図のように検索フォームが提示される．検索フォームの「アノテーションを用いた検索」では，左側のリストボックスから楽曲の構造を，右側のリストボックスからキーワードの記述，印象や楽曲構造，コードを指定することにより，ユーザの検索要求がシステムに送信される. 検索結果は図のように，検索ランクが上位の楽曲から順に列挙される．

図4.1: 楽曲検索システムの検索フォーム}

図4.2: 楽曲検索システムでの検索結果

4.2.2 キーワード検索

タイトル，作詞者，作曲者，印象，意見・感想，解説の情報に関してキーワード検索を行うことができる．楽曲の基本情報であるタイトルや作詞・作曲者情報からの検索以外に，Web上のユーザが付与したアノテーションに基づく検索が実現されている．楽曲の基本情報以外の，楽曲の鑑賞を通じて得られた感想などによる検索は，ユーザが目的の楽曲にたどり着く支援となると考えられる．

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

楽曲の論理構造に基づく検索の例として，コード進行検索を実装した．本検索機能は作曲の際に参考となる楽曲を参照したり，ある楽曲のコード進行と類似する楽曲を検出して楽曲同士のミキシングを行うなど，幅広いアプリケーションでの利用が期待される．

検索要求としてコード進行を入力すると，システムはまず各コードの基音とベース音を相対値に変換する．例えば「C G/B Dm C」というコード進行の場合は「0,-5/-1,2m,0」となる．次にそれぞれの楽曲のコード進行に対してDPマッチングを行い，検索要求との距離を計算し，距離の近い順に正答の候補とする．検索ランクはDPマッチングの距離の逆数を正規化した値を利用しているため，コード進行が完全一致する楽曲だけでなく，類似するコード進行が出現する楽曲が検索結果として提示される．

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

楽曲に対する多様な解釈を利用し，個人の感性に適応する検索機能として，印象に基づく楽曲検索機能を構築した．印象情報はユーザ間の競合がしばしば見られる情報であるが，類似する感性を持つユーザ同士は，同一楽曲やセグメントから類似する印象を受ける．そこで本検索システムでは，検索するユーザと，ある閾値以上感性の類似するユーザが付与した印象アノテーションのみを利用し，楽曲検索を行う．それぞれのユーザがどのような感性であるかというユーザモデルとユーザ間の類似度の閾値は，5章において述べるプレイリスト作成支援システムのものを用いた．

一般的な楽曲検索の場合，検索結果のランクは検索要求との適合度のみによってランキングされるが，本検索システムではアノテータに合わせたアノテーションのフィルタリングを行うことで，例えばある二つの楽曲に，等しい数の「悲しい」という印象が付与されていた場合，嗜好の類似したユーザによるアノテーションが多い楽曲の方が上位にランクされる．ユーザの感性に合わせた検索結果のランキングを行うことで，それぞれのユーザが要求する楽曲を適切に提示する．

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

サビやイントロなどの楽曲の構成は，エンドユーザが容易に認識可能な楽曲の内部構造であるといえる．そこで本検索システムでは，多くのアノテーション収集を期待される楽曲の構成情報を用いて，絞込み検索を行う機能を実装した．

「サビが悲しい曲」という検索要求を受け取った場合，「サビ」が絞込みを行う楽曲の構成であり，検索対象は「悲しい」という印象である．まず，楽曲の構成以外の検索要求である「悲しい」について，前述の印象に基づく検索を行う．この時の検索結果のランクを計算する．この時の検索結果のランクをとする．次に，絞込む楽曲の構成「サビ」の部分に対する「悲しい」などの含有率を計算し，含有率に基づき絞込み検索のランクを決定する．

「サビ」のアノテーションが付与されている音符，休符などの音楽オブジェクトが，，…の要素であり，その要素数はであるとする．また，「悲しい」というアノテーションが付与されている音楽オブジェクトは，からまでで，その要素数は であるとし，これら二つのアノテーションが共通して付与されているオブジェクトの要素数はであるとすると，含有率は以下の式で求める．

\mathrm{contains}=\max\left(\frac{p}{k},\frac{p}{n}\right)

「サビ」の部分に多く「悲しい」の要素が含まれている場合，または「悲しい」と関連付けられた要素が多く「サビ」に含まれている場合にが高くなる．最終的な絞り込みの検索ランクは以下の式で表される．

\mathrm{rank}=\mathrm{contains}\times\mathrm{priorrank}

本機能により，楽曲の論理的なセグメントの検索が可能となり，引用・要約など様々なアプリケーションにおいてそのセグメントを利用可能になる．

本節で述べた個人適応された楽曲の内部検索は，楽曲要約や編曲など様々な音楽アプリケーションにおいて，利用する楽曲やその部分を選出する導入部として利用可能であると考えられる．

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

再構成システムを実現するために，曲の構成というアノテーションが必要となるが，前述の音楽検索システムのため，既に曲の構成のアノテーションが作成されているので，簡単のため，再構成用に新しくアノテーション定義XMLを記述せず，検索用に生成されたアノテーションを利用する．

ユーザは再構成を行いたい曲を選択することで再構成システムにログインする．図はログイン直後の再構成システムの画像である．本再構成システムは，曲の構成，楽器パート，歌詞による音楽コンテンツの再構成を行う．

図4.3: 再構成前の画面

左のフレームが再構成システムのメニューとなっている．曲の構成による再構成を行いたい場合は，＜パート＞の部分にある曲の構成から，表示したい部分を選択する．歌詞の有無を変更したい場合は，＜歌詞＞の部分のセレクトボックスにチェックを行い，楽器パートを選びたい場合は，＜楽器パート＞の部分にあるチョイスボックスから，表示したい楽器パートを選択する．選択が終了したら「再構成」のボタンをクリックすると，曲の構成，歌詞の有無，楽器パートの選択を反映させた楽譜が表示される．

また，こうして再構成された音楽コンテンツのMusicXMLをダウンロードすることも可能である．

上記のように，歌詞，楽器パート，曲の構成により再構成したMusicXMLが生成される．このMusicXMLからブラウザに表示できるSVG(Scalable VectorGraphics)形式の楽譜を生成しブラウザに表示し，同時に，再構成済みのMusicXMLをファイルとしてサーバに保存し，ユーザはそれをダウンロードすることができる．再構成後の画面は図のようになる．図中の左側に表示される，再構成メニューから，Aメロ(verse-a)とサビ(chorus) の二つのパートが選択されており，それらのパートのみを抜き出して短縮された楽譜が表示されている．

図4.4: 再構成後の画面

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

MusicXMLには，歌詞や，楽器パートの情報が含まれているため，歌詞と楽器パートによる再構成は，元の音楽コンテンツであるMusicXMLのみを利用して実現する．

歌詞はMusicXMLでは図のように音符であるnoteタグの内部にlyricタグとして記述されている．

図4.5: MusicXMLにおける歌詞の記述

また楽器パートは，MusicXMLでは図のように，part-listとして定義し，さらにそれぞれの楽器パートについて演奏情報が記述される．楽器パートによる再構成では，P1，P2といった楽器パートのIDを取得し，MusicXML のpart-listタグから残しておくID以外のscore-partタグを削除し，さらにpart-list以降に記述されているpartタグも，残しておくIDのもの以外は削除する．

図4.6: MusicXMLにおける楽器パートの記述

アノテーションである楽曲の構成情報に基づく再構成について説明する．例えば音楽コンテンツが「きらきら星」であり，その楽曲を「イントロ- サビ-エンディング」という再構成するよう要求された場合，まずシステムはアノテーションが格納されたデータベースから，「きらきら星」の内部要素に対して付与されたアノテーションのうち，「イントロ」「サビ」「エンディング」という楽曲構成のアノテーションを全て検索する．次にそれらのアノテーションの指し先である楽譜中の要素を全て抜き出し，「イントロ-サビ- エンディング」という順番にそれらを列挙した新しいMusicXMLを作成し，再構成した楽譜をユーザに提示する．

同一の要素に対して，複数のユーザが異なる楽曲構成アノテーションを付与している場合，再構成システムを利用しているユーザの嗜好と類似するユーザが付与したアノテーションを優先させる．多様な解釈から，ユーザにとって適切なアノテーションを選出することで，本システムも楽曲検索システムと同様に，個人の解釈に適応させる．また本システムは，楽曲の論理構造であるサビやイントロなどの大まかな構成，楽器パート，歌詞などの情報を基に，楽曲を容易に再構成することから，コンテンツの意味内容に基づきコンテンツ変換を行うアプリケーションの一つであるといえる．

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

ユーザの置かれている状況をシステムが受け取ると，まずシステムは過去に作成されたプレイリストの中から，ユーザの嗜好モデルと類似し，さらに現在のユーザの状況と類似する状況で作成された基プレイリストをデータベースから選出する協調フィルタリングを行う．

システムはそれぞれのユーザのプレイリスト作成履歴から，そのユーザの嗜好に合った楽曲集合を保持している．ここで，ユーザにとって最も嗜好に合う楽曲が存在し，その楽曲はユーザの嗜好に合った楽曲集合を元に推測できると仮定した．そして歌詞と楽曲情景の特徴量に関してそれぞれユーザの嗜好に合った楽曲集合の平均を計算し，図のようにそれぞれの特徴量空間にマップする．また，ユーザの置かれている状況に関しては，本システムの鑑賞状況入力フォームからの入力に基づき，ユーザを鑑賞状況の特徴量空間にマップする．鑑賞状況入力フォームの項目は，5.1節で述べた各楽曲に対する音楽アノテーションシステムにおける鑑賞状況の項目と同等である．

図5.4: 歌詞・楽曲情景・鑑賞状況の特徴量空間

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

次に基プレイリストをさらにユーザの嗜好に適合させるトランスコーディングを施す．具体的には，ユーザが過去に嗜好に合わないとシステムにフィードバックした楽曲を取り除き，楽曲データベースから代わりの楽曲を選んで追加する．同時に，ユーザが鑑賞経験のない楽曲を3割の割合で含ませている．聴き慣れた楽曲の中に適度に鑑賞経験のない楽曲を挿入することで，ユーザの嗜好の幅を徐々に広げる効果が期待される．

嗜好に合わない楽曲などの代わりに追加する楽曲は，ユーザの嗜好と，置かれた状況から，各特徴量空間におけるユーザと楽曲の類似度を踏まえて選出される．ユーザと楽曲間の類似度は，5.2節で述べた楽曲間の類似度計算と同様の計算式から導き出される．

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

以上の処理を経てユーザには図のようにプレイリストが提示される．作成されたプレイリストは左側に，プレイリストを介したコミュニケーションを行う部分は右側に表示される．ユーザはプレイリスト上部に埋め込まれたプレイヤから，通常の音楽プレイヤと同様の操作でプレイリストを楽しむことができる．

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

ユーザは実際にプレイリストを鑑賞し，各楽曲が嗜好に合っているか，状況に合っているかといった情報をフィードバックする．画面左側に楽曲リストと共に表示される「○」「×」を選択して申告する．また現在のプレイリストから，入れ替えを行いたい楽曲の「入替」のボックスをチェックする．システムはユーザからのフィードバックを受け取り，気に入らない・現在の状況に適していない楽曲の入れ替えを行い再度ユーザにプレイリストを提示する．

このように協調フィルタリングとトランスコーディングによって自動的にプレイリストを生成し，そのプレイリストをユーザとのインタラクションによって洗練していくことで，ユーザが大量の楽曲群からプレイリストとなる楽曲を選択するよりも低いコストでプレイリストを作成することができる．

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

図の左下に現れる''manual edit''ボタンを押すと，図のようにユーザ自身が登録楽曲中から選択した楽曲を追加したり，プレイリスト中の楽曲を削除するプレイリスト編集ページが表示される．登録されている楽曲のアーティスト，アルバムのリストが上段左側と上段中央に表示され，それらを選択し，プレイリストに追加する楽曲の候補を絞り込むことにより下部左側に選択されたアーティスト・アルバムの楽曲一覧が表示される．ユーザは楽曲タイトルの右に現れるaddボタンを押すと，楽曲一覧の右側に現れるプレイリストに楽曲が追加される．またプレイリストの楽曲タイトルの左に現れるdelete ボタンを押すと，編集中のプレイリストから該当する楽曲が削除される．また楽曲を選択し，矢印のボタンを押すことによりプレイリスト中の楽曲の順序を変更することができる．

図5.6: プレイリスト編集画面

プレイリストを人手により作成・編集する際に最も時間を要するのが，膨大な量の楽曲の中からどの楽曲を選択したらよいかを決定する作業である．そこで本システムではその作業の時間を短縮するよう，嗜好と状況に基づいてプレイリストに追加する候補となる楽曲を自動的に絞り込む機能を備える．画面上部右側に現れるフィルタリングのメニューから，絞り込む楽曲数を入力し，ボタンを押すことでユーザの嗜好とユーザの状況に最も適合する楽曲から，指定された数までの楽曲を検索し，画面下部左側に表示する．

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

ユーザの嗜好モデルは，本システムに対して，それぞれの楽曲が嗜好に合うかどうか，また状況に合っているかどうかというフィードバック情報を用いて順次更新される．TF*IDFで得られるキーワード数がである場合，歌詞の特徴量空間における初期状態の基底は，次元単位行列と同等の標準基底である．ユーザが嗜好に合っているとフィードバックした楽曲群と，合っていないとフィードバックした楽曲群を用い，各ベクトル空間の基底をユーザの嗜好に適応させる．そのためベクトル空間の基底はそれぞれのユーザについて異なる．以下は歌詞の特徴量空間における基底をフィードバックに応じて変化させるための式である．

\mathrm{b}_{u}\leftarrow\mathrm{normalize}(\mathrm{b}_u+\mathrm{diag}(\delta\frac{sl_{f}-l_{u}}{|l_{f}-l_{u}|}-\delta\frac{l_{d}-l_u}{|l_{d}-l_u|}))

はユーザの歌詞の特徴量空間における基底である． はフィードバックによって嗜好に合っているとされた楽曲の歌詞特徴ベクトルの平均であり， は嗜好に合わないとされた楽曲の歌詞特徴ベクトルの平均である．は，ユーザがこれまでに嗜好に合っているとフィードバックした楽曲全体の歌詞特徴ベクトルの平均である．一回のフィードバックにおいてどれだけ基底を変化させるかを決定する変換レートはで表されている．本システムでは経験的に の値を設定している．は列ベクトルを対角行列に変換する関数である．

例えばユーザが「愛」というキーワードの入った楽曲を嗜好に合うとし，「死」というキーワードの入った楽曲を嗜好に合わないとフィードバックした場合，上記の基底変換により，歌詞の特徴量空間は図に示すように愛の要素が短縮され，死の方向へ拡張される．特徴量空間を嗜好に合った楽曲の方向に短縮し，嗜好に合わない楽曲の方向に拡張することで，ユーザの好む楽曲とユーザの間の距離を縮め，逆にユーザと嗜好に合わない楽曲同士を遠ざける．楽曲情景と鑑賞状況の特徴量空間についても同様に，アノテーションの項目数を，とした場合，，次元単位行列を初期状態とし，ユーザからのフィードバックごとに基底をユーザに適応させる．ユーザ間の類似度計算の際の基底変換には，プレイリストを作成する主体となるユーザの基底を用いる．

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

5.5.1 実験方法

評価実験に利用した楽曲はRWC音楽データベースのPOPS100曲と，一般のPOPS130曲である．事前に各楽曲に対して，5.1節で述べた楽曲情景・鑑賞状況に関するアノテーションを収集し，その情報を楽曲の特徴量として利用した．

構築したシステムの評価を行うため，7人の被験者に対して以下の手順で評価実験を行った．まず自由に自分の置かれている状況を設定してもらい，本システムの鑑賞状況入力フォームから入力してもらう．システムは各被験者の嗜好と，入力した鑑賞状況に適したプレイリストを提示する．そこで実際にプレイリストを鑑賞してもらい，各楽曲に対して嗜好に合っていたか，状況に合っていたかの情報をチェックしてもらい，システムにフィードバックしてもらう．システムは受け取った情報を基にプレイリスト作り変え，再びユーザにプレイリストを提示する．以上の行為をプレイリストのすべての楽曲が嗜好・状況共に合ったものになるまで繰り返してもらう．以上のプレイリスト作成プロセスを，3回繰り返してもらった．

本システムによってユーザの嗜好・状況に合っているプレイリストを作成されているかどうかを確認するため，各プレイリスト作成プロセスにおいて，鑑賞状況入力後提示されるプレイリスト中に，嗜好に合う楽曲・状況に合う楽曲・嗜好と状況に合う楽曲はそれぞれ何曲存在したか，またすべての楽曲が嗜好と状況に合うまで行ったインタラクションの回数を評価した．

5.5.2 実験の結果と考察

評価実験の結果を図に示す．それぞれのグループは3種類のバーによって構成されており，左から1回目，2回目，3回目のプレイリスト作成プロセスにおける評価値である．各バーの頂点の矢印は各評価値の標準偏差を表している．

図5.9: 評価実験の結果}

図の左から2番目に表される嗜好に合った楽曲数のグラフと，左端の嗜好・状況共に合った楽曲数のグラフからは，プレイリスト作成プロセスを重ねるにつれてユーザに合った楽曲数が増加していることが読み取れる．また右端のインタラクションの回数は，徐々に減少していることがわかる．このことから本システムを長く利用するユーザほど，嗜好と状況に合ったプレイリストを，少ないインタラクションにより得ることができるといえる．

一方，左から3番目のグループに現れている，状況に合った楽曲数のグラフでは，1回目，2回目，3回目とプレイリスト作成を繰り返すことによる増加傾向は見られない．鑑賞状況に合った楽曲提示については，プレイリスト作成を繰り返すことにより改善されているとはいえない結果であった．

この結果は以下の2つの問題点が原因となって起こったと考えられる．一つ目は本システムで入力を要求する鑑賞状況項目の組み合わせが，利用できる楽曲数に比べて非常に多いという点，二つ目に，各楽曲に対して収集した楽曲情景・鑑賞状況のアノテーションは各楽曲に均一に付与されているわけではないという点である．

前者の問題点に対しては，より多くの評価実験を繰り返し，鑑賞状況項目をより効果的な項目に絞り込み，同時にプレイリストの要素として利用可能な楽曲数を追加することで対応できると考えられる．後者の，情報の偏りに関する問題は，一般ユーザを対象としたアノテーション獲得のためのシステムにおいては，コンテンツの人気などにより頻繁に発生する問題である．この問題を解決するために，ユーザをアノテーションが不足しているコンテンツに誘導したり，リスナの鑑賞履歴などを利用することでアノテーションの均一化を図る仕組みが必要となる．

しかし鑑賞履歴のような情報は，アノテーション獲得のためのシステムから付与された情報と比べて一般的に信頼性に劣るため，そういった情報を適用するためには，各アノテーションの重みを考慮する必要がある．

7.3.1 CGMサービスの拡張

今後Web 上のコンテンツの多くはCGMサービスによって管理されることになると予想されるため，AnnphonyをCGMサービスに適用することで，様々なコンテンツ同士の引用と，その引用情報の共有を可能にする．

例えば，引用元のCGMサービスとしてビデオ共有システムSynvieとオンライン辞典システムである認知科学辞典Web版にAnnphonyを適用する．コンテンツの種類はCGMサービスによって異なるため，コンテンツ内部を指し示すElementPointer の定義はCGMサービスごとに用意する．ビデオ共有システムではビデオの時間区分を指し示すためには，開始・終了時間が必要であるため，その旨をElementPointerの定義に記述した．またオンライン辞典システムの各専門用語は，文書の言語構造を表現するための言語であるGDA(Global DocumentAnnotation)形式で保持されているため，単語・文節・文など，文書の論理構造に基づく部分を指し示すための定義を記述する．

また引用先となるCGMサービスとして，ブログを採用した．ブログシステムにAnnphonyを適用し，ブログにビデオや辞典などの他のコンテンツを部分引用した記事を投稿する際に，その部分引用の情報をAnnphonyに保存する．図 はブログにおいてビデオ・辞典を引用した記事を投稿した画面例である．図では，ある分野の詳細な解説として，参考となるビデオと辞典の一部を引用している．このように同時に引用されるビデオと辞典には，明らかな関連性を認めることができる．

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

一般的にユーザは，あるコンテンツと他の様々なコンテンツとの多項関係を完全に把握してはいないため，一人のユーザによって網羅的な関連性を記述することは困難である．そのため，一般ユーザが記述可能な同時引用の情報は二項，三項関係といった少数の関連性にとどまると考えられる．しかしCGMサービスを通じて同時引用の情報を広く収集することにより，コンテンツ間の多項関係に拡張することができる．

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

関連する複数コンテンツを自動的に統合して新たなコンテンツを生成することをマッシュアップと言う．Webコンテンツを用いてマッシュアップコンテンツを自動生成する例として，オンライン辞典システムを拡張し，ビデオ用例付き辞典システムを構築する．本システムでは，各専門用語の項に，ブログにおいて同時引用された，用例の一つと見なされるビデオを提示することで，その専門用語の理解を深めることができる．

キーワード検索の要求を本システムが受け取ると，オンライン辞典システム・ビデオ共有システムに対して，検索要求のキーワードが存在する辞典の項目・ビデオを検索する．次にそれらがブログにおいて過去に同時引用されているかを検索し，同時に引用されたことのあるビデオの一部と辞典項目の一部の組を列挙する．またブログに対してもキーワード検索を行い，検出されたブログエントリ内で同時引用されているビデオの一部と辞典項目の一部の組を列挙する．

こうして列挙されたビデオの一部と辞典の項目の一部の組を用い，辞典の項目中の同時引用された文以降に，ビデオへのリンクを埋め込む．図はビデオが埋め込まれた辞典の項目の例である．辞典の項目中に具体的な例であるビデオを埋め込むことで，その項目をより深く理解することができる．

図7.2: ビデオ用例付き辞典システム

このように同時引用の情報を用いることにより，ビデオやオンライン辞典の項目といった異種類のコンテンツ同士を結びつけることで，付加価値を持ったコンテンツを作成することが可能である．これも本研究の成果から自然に導かれる結論の一つである．