情報管理
Online ISSN : 1347-1597
Print ISSN : 0021-7298
ISSN-L : 0021-7298
視点
視点 「ロメジュリ」って何?:識別子を巡って
神崎 正英
著者情報
ジャーナル フリー HTML

2017 年 59 巻 11 号 p. 772-776

詳細

 名前の適用範囲

「次はロメジュリだよ」「チャイコ? プロコ?」「いや,ベルリオーズ」

オーケストラ奏者たちが,次回のプログラムを話題にしているようだ。さてこの会話は,どんな範囲で通じるだろう。

「ロメジュリ」は「ロミオとジュリエット」注1),「チャイコ」「プロコ」はそれぞれ「チャイコフスキー」「プロコフィエフ」の略称だ。分かるような気もするが,想像がつかなかったとしても不思議ではない。こうした仲間内での呼び名は,いわば専門用語であり,その領域においては通じるが外部では理解されないかもしれない名称である。

専門用語に限らず,一般に識別のための名前には適用範囲がある。そしてその範囲においては,名指すものを他と曖昧さなく区別できなければならない。たとえば「港区…」という住所は,全国レベルでは名古屋市や大阪市の港区との区別がつかないから,適用範囲は都内に限られる。「ロメジュリ」は該当する作品が複数あるため,ある作曲家の作品リストの範囲でしか識別の役割を果たさないのだ。

適用範囲を広げるためには,名前に情報を追加して限定の度合いを高めればよい。上の会話では「ロメジュリ」に「ベルリオーズ」と加えることで,音楽仲間には区別がつくものとなった。「東京都港区…」という住所は,都道府県名を限定句とし,適用範囲を日本全国に拡大したものといえる。

誰もがアクセス可能な空間であるウェブでは,情報資源を識別する名前はその全体を適用範囲としなければならない。これを実現するのが,URI(Uniform Resource Identifier)注2)である(1)。たとえばDBpedia注3)の次のURIは,作曲家プロコフィエフを,ウェブ全体において識別している。

  • http://ja.dbpedia.org/resource/セルゲイ・プロコフィエフ

範囲がどれだけ広がっても,対象を明確に区別するという識別子の役割に違いはない。ウェブ全体では同姓同名の人がいてもおかしくないが,このURIは1891年生まれのロシアの作曲家を曖昧さなく指し示す名前として機能する注4)

図1 識別子の適用範囲

 識別の対象

「ガーディナーのロメジュリ聴いた?」「あぁ,それ持ってるよ」

この会話で「ロメジュリ」を限定する「ガーディナー」は,作曲家ではなく指揮者である。したがって,誰が書いた「ロミオとジュリエット」なのかを直接示してはくれない。ただこの場合は,彼が録音している「ロメジュリ」は1種類だけであるため,話題になっているのはベルリオーズの作品だということが(知っている人には)分かる。

さて,この会話をよくみると,問いと答えで指示している対象が微妙にずれていることに気がつく。問いは「ガーディナーによる演奏」の話をしているのだが,答えは「持っている」と物理的なCDなどを指している。いずれも,ベルリオーズの作曲した交響曲という作品の概念ではなく,話はより具体的だ。

このように,音楽などの創作物についての言及には,作品そのものだったり演奏だったり,あるいは特定のCDだったりと対象が混在する可能性がある。これらを的確にとらえるために,図書館の国際組織であるIFLA(国際図書館連盟)が1997年に発表したのが,書誌レコードの機能要件(FRBR)の概念モデルである注5)。このモデルが提示する4レベルの実体を,上の会話に当てはめてみよう。

  • ・作品(Work):ベルリオーズが1839年に作曲した「ロミオとジュリエット」
  • ・表現形(Expression):ガーディナー指揮によるその1995年の演奏
  • ・体現形(Manifestation):Deccaから2012年に再発売されたそのCD
  • ・アイテム(Item):「持ってる」と答えた人が購入した1枚

文学なら,シェイクスピアの「ロミオとジュリエット」が作品,松岡和子の訳がその表現形,ちくま文庫の「シェイクスピア全集 2」がその体現形,図書館にある1冊がそのアイテム,という具合になる。

これらを区別した識別子(URI)で文献の主題が示されれば,ベルリオーズの「ロミオとジュリエット」の作品論を探しているのに,結果の大半はその演奏のCD評ということもなくなる注6)。各実体レベル間の関係(たとえば「作品」と「表現形」はrealized throughという関係にある)を利用して,逆に作品についての演奏評を一括検索することも可能だ(2)。

作品にせよ演奏にせよ,それについて語られた情報をURIを介して的確に集約できるという点は,とても重要である。関連文献や資料の収集は研究の第一歩だが,著名なものを別にすれば作品・演奏単位での資料リストは少なく,キーワードや大まかな主題で苦労して探し出すしかないからだ。

もちろんそのためには,同じ作品は同じURIで指示できるように,識別子が共有されていなければならない。DBpedia(Wikipedia)は人々の関心事項を広く収録しており,そうした共有識別子の出発点になり得るだろう。とはいえ,やはり単独でカバーできる深さや精度には限界があるから,分野ごとのアーカイブや作品データベースなどが,URIを提供する識別子のハブ注7)の機能を担ってくれることが期待される。

図2 FRBRの概念モデルを利用した識別

 部分を指す識別子

「ガーディナーのロメジュリで“愛の場面”のジュリエットの主題を聴いてみて」「第3部の146小節目からだね」「CDでは8トラック目の6′00″だよ」

作品のある部分についての考えを述べるためには,その箇所を特定する識別手段が必要になる。音楽作品の場合,通常は楽章と小節番号や練習記号が用いられるが,残念ながらこれをURIとして表現する標準的な方法がない。

前回取り上げた注釈モデルでは,画像の一部について説明するために,座標をメディア・フラグメント注8)で表現した。同様にして,CDのトラックに対応するURIがあれば,その特定タイムをメディア・フラグメントで表すことは可能だ。Naxos Music LibraryのトラックURIを例にするなら次のような形になる。

  • http://ml.naxos.jp/track/3004499#t=360

しかしメディア・フラグメントでの識別は,基本的に体現形が対象になってしまう。作品レベルで部分を指すためには,たとえば電子楽譜の構造を利用してXPathなどで目的の小節を示す方法は考えられる注9)が,普及はまだこれからであり,すぐ利用できそうにはない。

電子書籍では,EPUBのCFI(Canonical Fragment Identifiers)仕様がある注10)。ツールなしには使いにくいものだが,部分識別子の標準候補ではあるだろう(ただしこれも体現形に依存するものではある)。文献の識別子として普及しているDOIは,任意の粒度で割り当てが可能で,書籍と同時にその各章にもDOIを付与するなどの例はある。とはいえ個別の段落すべてにまで割り当てを受けるのは現実的ではないので,やはり章節番号などから規則的に導けるフラグメント識別子が欲しいところだ。

まだ作品レベルのURIも確立していない今の段階では,部分を示すURIの標準化は遠い話ではある。しかし,いずれ必要となる課題であることは間違いない。具体的メディア(体現形)を基準にして識別するなら,レファレンスとするものを決めてメディア・フラグメントやCFIを用いるか。あるいは古典文学作品の行番号や聖書の章節番号のような規範的識別子を,ナリッジサイトやアーカイブが定義してくれることに期待するか。

 リンクする名前

「ベルリオーズのロメジュリにはオフィクレイド注11)が出てくるよね」「そういえば,オフィクレイドはメンデルスゾーンも使ってるんだっけ?」

人はこんな具合に,ある名前をきっかけとする「連想」によって話を展開する。バネバー・ブッシュが「私たちが考えるように(As We May Think)」で提示したmemexも,こうした連想に基づいて文書をつないでいくものだった。ティム・バーナーズ=リーが,これをインターネットと組み合わせて,WWWが誕生した。

WWWでのつながり=リンクを実現する要は,やはりURIである。最初がhttpで始まるURIは,相手サーバーに要求を送って文書を得るための情報,つまりリンクのアドレスとしての機能を持つ。ウェブ文書でリンクのきっかけとなる名前(クリックするテキスト)の背後には,URIが隠れてアドレスの役割を担っている。一方“ウェブを適用範囲とする名前”としてのURIにおいては,第一義的な機能は識別であり,アドレスの働きは期待されていなかった。作品や作曲家を識別するURIにアクセスしても,書物や人がインターネットで運ばれてくるわけではないからだ。

2004年の「WWWのアーキテクチャ」勧告とその前後の議論によって,状況が変わる。人などのネットワーク上にない対象(非情報資源)のURIにアクセスがあったら,その対象についての説明文書URIに転送するなどの方法で,識別とアクセスが両立するように整理されたのだ注12)。そしてバーナーズ=リーは,識別のURIをリンクにも用い,データをウェブに組み込むLinked Data(リンクするデータ)の考えを提唱した注13)

Linked Data対応アプリケーションでDBpediaの(名前としての)URIにアクセスすると,転送の結果RDFで記述されたデータが返ってくる。そのデータには関連情報のURIが含まれており,そこにアクセスすると同じようにしてRDFデータが得られ……と,「データのリンク」をたどっていくことができる(3)。ウェブページのブラウジングで思わぬ情報に出会うように,データのつながりから新たな「発見」が生まれることもあるだろう。

オープンデータをLinked Dataとして提供するLOD(Linked Open Data)が注目され始めている。だがそこで何よりも重要なURIは,適切に使われていない場合がまだ多いようにもみえる。「ロメジュリ」ではなく(もちろん名無しではなく!)ウェブで通じる名前=URIをすべての対象に与えること,そしてその名前から他のデータにもリンクできるようにすること。つながりあったデータは,足し算を超えた価値を生み出すものとなるはずなのだ。

図3 リンクするデータ

執筆者略歴

  • 神崎 正英(かんざき まさひで)

サントリー広報部時代に同社ウェブサイトの提案・構築を行ったことなどをきっかけに,文書構造表現/データモデルの設計や標準化の方向に進み,黎明期(れいめいき)セマンティック・ウェブのプロジェクトにかかわってきた。慶應義塾大学文学部講師を兼務。

本文の注
注1)  舞台がイタリアなので以前は「ロメオ」とされていた(たとえば坪内逍遥訳だと『ロメオとヂュリエット』(中央公論社))が,最近では「ロミオとジュリエット」が,少なくとも文学作品としては一般的。ただし音楽作品の場合は依然として「ロメオとジュリエット」と記述されることが多く,略称も「ロメジュリ」が通用している。

注2)  URIには英数字と一部の記号しか使えないが,これを国際化したIRI(Internationalized Resource Identifier)では漢字,かなを含むUnicodeの文字を利用できる。以下,一般的な用語としてURIを用いるが,実際にはすべてIRIを意味している。

注3)  DBpediaはWikipediaの情報ボックスを中心とした内容をRDFグラフで表現したもので,ページ名にあたるURIの末尾(ローカル名)が同じ。WikipediaのURIはその「ウェブページ」を表すものだが,DBpediaは対応するWikipediaページで「説明されているもの」を表すURIとして用いることができる。

注4)  Wikipedia/DBpediaには「ロミオとジュリエット_(曖昧さ回避)」のように複数の対象が当てはまりそうなURIがあるが,これはその曖昧なもの全体を1つの対象として識別するので,URIが指すものはやはり1つだけである。ちなみに,国立国会図書館の名称典拠には人智(じんち)学者のセルゲイ・プロコフィエフも収録されているが,英文つづりが微妙に異なる他,生没年で修飾することで区別している。国立国会図書館名称典拠のURIとしては,曖昧さをなくすために数字のIDを採用している。

注5)  Functional Requirements for Bibliographic Records - Final Report:http://archive.ifla.org/VII/s13/frbr/

注6)  前回(情報管理 vol. 59, no. 7:http://doi.org/10.1241/johokanri.59.479)に取り上げた注釈モデル(Web Annotation)で記述することもできるが,ここではシンプルに文献の主題としておく。また実際には,表現形(演奏/翻訳)は具体的な形がないために識別子を選びにくく,体現形(音源/書籍)のCD番号やISBNに基づく識別の方が便利な場合が多い。FRBRの概念モデルを応用した米国議会図書館のBIBFRAMEやSchema.orgの書誌拡張では,体現形を作品と直接関連付ける3階層モデルを用いている。

注7)  識別子のハブという考え方は,たとえばCooperative Identities Hub (http://www.oclc.org/content/dam/research/publications/library/2009/2009-05.pdf)に示されている。文献ではDOI(Digital Object Identifier)がこれに近い役割を果たしているともいえる。前々回(情報管理 vol. 59, no. 3: http://doi.org/10.1241/johokanri.59.189)に取り上げたナリッジサイトに期待することでもある。

注8)  メディア・フラグメント(https://www.w3.org/TR/media-frags/)は画像,オーディオ,動画などのマルチメディア・コンテンツ内の特定箇所を指し示すための仕様。時間軸の場合はt=として秒数を示す。

注9)  たとえば前々回に紹介したMusic Encoding Initiative (MEI)をマークアップに用いた電子楽譜ならば,「第3部の146小節目」を「//mdiv[@type='part'][3]//measure[146]」と表現することはできる。Web Annotationでは,これをXPathSelectorタイプの値として楽譜のURIと組み合わせればよいことになる。

注10)  EPUB Canonical Fragment Identifiers 1.1:http://www.idpf.org/epub/linking/cfi/epub-cfi.html ウェブで利用可能な電書フォーマットを検討しているW3Cの電子出版IGでも,Identifiers Task Force (https://www.w3.org/dpub/IG/wiki/Task_Forces/identifiers#Background)がCIFを候補の1つに挙げている。

注11)  オフィクレイドは当時使われていた低音金管楽器で,現代ではチューバに取って代わられているが,ガーディナーはこれを復元して演奏に用いた。Wikipediaの「ロメオとジュリエット_(ベルリオーズ)」ページには,この曲の楽器編成のセクションがあり,その中の「オフィクレイド」のリンクをたどった先には,メンデルスゾーンが「夏の夜の夢」でこの楽器を使っていたことなどが記されている。

注12)  人や書物のような非情報資源の識別は,フラグメント識別子を加えたURIならば問題はなかった(URIにアクセスして取得できるのはフラグメントを除いた本体部分URIで識別される文書であり,人や書物が運ばれてくると考える必要はない)。フラグメントなしURIでの識別については,2004年のArchitecture of the World Wide Web, Volume One (https://www.w3.org/TR/webarch/)でURIの望ましい扱いが整理されるのと前後して,W3CのTAG(Technical Architecture Group)で議論され,アクセスがあれば情報資源URIに転送するという解決案が2005年に合意された(https://lists.w3.org/Archives/Public/www-tag/2005Jun/0039)。これらの具体的な方法は,Cool URIs for the Semantic Web(https://www.w3.org/TR/cooluris/)にまとめられている。

注13)  Linked Data - Design Issues:https://www.w3.org/DesignIssues/LinkedData.html

 
© 2017 Japan Science and Technology Agency
feedback
Top