附属資料
A. Warwick Framework翻訳

Warwick Framework - メタデータ集合のためのコンテナアーキテクチャ

Carl Lagoze, Clifford A. Lynch, Ron Daniel Jr.著

1.　概要

この文書は、英国Warwickで1996年4月に行われた第2回メタデータ研究会の成果である、Warwick Frameworkと呼ばれるアーキテクチャに関して述べたものである。Warwick研究会の目的は、Dublin Coreメタデータ集合の開発された、Ohio州Dublinにおける1995年3月のメタデータ研究会の成果を発展させることである。

Dublin Coreは、ネットワーク化された文書 --- Dublin会合の報告書でオブジェクトライクなドキュメントという言い方をされたもの --- の本質的特徴を記述するための、簡単ではあるが有用なメタデータ要素の集合を定式化するための試みである。Dublin Coreは、まず第一に --- それ以外に注目しないという訳ではないが --- オブジェクトの記述に焦点を当てている。Dublin Coreメタデータ集合は、人気あるWWW検索エンジン（例えば、LycosやAlta Vista）で使われている "webcrawlers" などのインターネット上のリソース発見ツールによる使用に適合することを目的としている。Dublin Coreの13の要素は、著者、タイトル、主題といったよくある記述データを含んでいる。Dublin Coreのデザインにおいて考慮されたことは、コアの要素と図書分類（AACR2/MARC）やFGDCメタデータ・スキームなどの、現存するより専門化された記述システムとの間のマッピングである。対象範囲や関連性といった、コアの分野のうちの少数のものについては、それほど記述的分類の典型であるとは言えないが、伝統的アプローチで求められていた熟練した分類作業者を必要とするような細かな分類を行わない、記述的分類の仕方の一般化を試みている。

Warwick研究会は、ドキュメント内容の提供者、分類作業者・インデックス作成者、および自動化されたリソースの発見と記述のシステムの間の、より大きな相互運用性を促進するために、Dublin Coreプログラムを発展させ、より具体的で機能的に利用できるDublin Coreの形式を提供することである。二度目の研究会もまた、Dublin Coreとともに行われた一年間の実験の成果を評価する機会であった。

参加者の間には簡単な記述的メタデータ集合の考え方が有用であるという一般的なコンセンサスはあったが、Dublin Coreの実際の利用に関しては、それが前回の研究会の最後に決定されたことから、数多くの根本的な問題があった。非常に緩やかに定義されたDublin Coreが、プログラムに基づいて読み、処理することのできる基準として本当に適切であるのか？  コアの要素数は、セマンティクスを豊富にするために拡大すべきであろうか、あるいは、作者および（または「あるいは」）ウェブ上の出版者による使いやすさを促進するために減らすべきであろうか？  作者が彼らのドキュメントの内容に付け加えたコアの記述的メタデータ集合を信頼することができるだろうか？  コア・メタデータ集合は記述的分類情報のみに制限されるべきであろうか、それとも、管理用の情報やリンクデータとかいったその他の型のメタデータも含むべきであろうか？  Dublin Coreとメタデータ・スキームにおけるその他の開発中の作業との関係はどうなるのであろうか？  特に、主にDublin Coreの射程の外で考えられていた権利に関する管理情報（利用条件）などの分野における作業との関係はどうなるのであろうか？

われわれは、これらの問題に対する解答とメタデータの問題を前進させる道は、Dublin Coreに対してよりレベルの高い文脈を提供するわれわれの能力にかかっていると結論した。Dublin Coreが、これらのメタデータ集合を特徴づける、個々の保全性（integrity）、異なる閲覧者、そして別々の領域の責任と管理などに関わる方法で、その他のメタデータ集合とどのように結合されるかが、この文脈によって定義されるべき事柄である。

Warwick研究会の成果は、Warwick Frameworkとして知られるコンテナ・アーキテクチャの提案である。この枠組は異なるメタデータのパッケージを、論理的に、そしておそらく（特定のデータ構造の利用を通して）具体的に集めるメカニズムである。これは、メタデータの問題をいくつかのモジュールに分解することであり、数多くの顕著な特徴をもつ。

メタデータ集合のパッケージへの分割は、パッケージが完全にセマンティクス的に別々のものとなることを意味しない。実際、Warwick Frameworkの一つの特徴は、個々のコンテナが、別々のグループによって管理・維持されている、複雑なセマンティクスのオーバーラップを伴った、これらの範囲の問題の現実を認識させるようなパッケージを持つかもしれないということである。
 

2.　この文章の構成

この文章の残りの部分は六つの大きなセクションに分かれている。セクション３では、Warwick Frameworkに関連した二つのメタデータ研究会（1995年のOhio州Dublinでの研究会と1996年の英国Warwickでの研究会）についての概要を述べる。セクション４は、Dublin Coreに関する短い記述であり、セクション５は、最初の研究会で定義されたコアとしてのDublin Coreを評価し、その限界のいくつかについて記述する。セクション６は、メタデータの問題をより大きな文脈の中で考えることによってこの文章の残りの流れを示す。セクション７は、この文章の中心であり、Warwick Frameworkアーキテクチャに関する記述である。セクション８は、コアの完全な実装以前に解決する必要のある、明らかになっている数多くの問題について述べる。最後に、セクション９は、提案されている四つの実装（HTML、MIME、SGML、および分散オブジェクトアーキテクチャに基づいたもの）について述べる。
 

3.　メタデータ研究会

メタデータ研究会という案は、1994年にシカゴで行われた第２回WWW会議(the Second International World Wide Web Conference)における非公式会合から生まれた。この会合の参加者は、ウェブ上のリソースの数が爆発的に増え、リソース発見能力がそれに応じて複雑になっていっていると認識していた。

ウェブ上でのリソースの発見と配置に関する２年前の問題は、いまだにわれわれを悩ませている。ウェブ上のドキュメントはそれらに関連した何の記述的データもメタデータも持たず、LycosやAlta Vistaのようなリソース発見ツールは、ドキュメントの内容からインデックスを作る以外の代替手段を持っていない。せいぜい、これらのツールは、単なるすべてテキストベースのインデックス作りを越える方法としての、HTML表示のマークアップの利用に基づいたヒューリスティクス（heuristics)に適用されるくらいである。これらのテキストのみのインデックスに関する問題が明らかになるのは、"Mercury" に関するドキュメントを検索して、惑星の "Mercury"（水星）や、元素の "Mercury"（水銀）、ギリシャの神の "Mercury"、"San Jose Mercury-News" からの記事が混ざって発見されたときである。さらに、テキストのみのインデックス作成アプローチでは、ますます多くなりつつあるネットワークへ流れこむ非テキストデータにまで合理的に到達することがない。全てテキストベースのインデックス作成アプローチは、多くの画像、音声、動画、さらには（CGIを通してアクセス可能な）実行プログラムなどの、非テキストドキュメントに対してはまったく役に立たない。

Yahooなどの、ネットワーク上のリソースに対する知的な分類の実践を適用する試みも行われてきたが、これらの分類を構築するための労働力を雇うコストを考えると、それらはただ、ネットワークを通してアクセス可能な豊富なリソースの非常にほんのわずかな部分に対するガイドしか提供できないことが分かる。最も一般的には、それらは、ドキュメントレベルというよりも、ウェブサイト全体のレベルで機能する。そして、人間の行う調査と分類にありがちな時間の遅れを考えると、分類アプローチはまずは相対的に静的なサイトに対して適切である。それは、ネット上にある大量の、かつ相対的に短時間で変化する資料をカバーするために効果的かつ安価に拡張することができないのである。

第1回メタデータ研究会は、Online Computer Library Center(OCLC)とthe National Center for Supercomputer Applications (NCSA)が資金を提供、Ohio州Dublinで1995年3月に開かれた。Dublin研究会は、ますます大きくなっているリソース発見問題への解決策の定式化を試みるために、コンピュータと情報科学者や図書館司書、情報提供者をまとめて招集した。

Dublin研究会の目標はわざとかなり控えめなものにしていた。決定は、「総合目的」であるメタデータの問題を別にし、一般的に文字だけのWWWページに対応した「ドキュメントライクなオブジェクト」（DLOs）という用語で表されるものを記述するのに有用なメタデータにその範囲を制限して行われた。記述的データの範囲は、記述的分類として一般的に知られているもの、そしてそれほどではないにしても、類別区分というものに対しては、より制限されていた。例えば、オブジェクトの記述の一部と充分なり得たであろう評価情報に関してはほとんど考慮がされなかった。さらに、研究会の焦点は概念的なコンセンサスの構築（それには、シンタクス論争が特にネックとなった）であった。シンタクスに関して議論しないことに合意することによって、研究会の参加者たちは、DLOsの記述の要素であるメタデータ要素の集合を列挙することと、それらの要素のセマンティクスを定義することを制限されたのである。

このDublin研究会の第一の成果は、Dublin Core Metadata Set（註1）、あるいはDublin Coreと名づけられた13のメタデータ要素の集合である。Dublin Coreは、WWWドキュメントの大多数の作者や管理者によって提供されうる、そしてWWW内での場所特定サービスに役立つような記述データの相対的に単純な集合であることを意図されたものであった。

Dublin研究会の成果はかなりのレベルの関心を呼んだ。Workshop Report（註2）の要約記事（d-Lib Magazine（註3）が掲載）は相当な読者を惹きつけた。Dublin Coreを利用する数多くのプロトタイプの実装が、北米、ヨーロッパ、オーストラリアで計画された。
Dublin研究会の成果を発展させるため、研究会のフォローアップが1996年4月、英国Warwickで開かれた。今回は、OCLCとthe United Kingdom Office for Library and Information Networking (UKOLN)が資金を提供した。この第２回研究会に対する発表には、次の二つの目標が述べられていた。

参加者たちがこの第２回研究会に招集されたとき、これらの目標は前回の研究会の概念的なコンセンサスを形成するという目標よりも合意が難しいだろうという共通認識があった。システム間の相互運用性はもともとのDublin Coreで提供されたものよりも具体的なシンタクスとセマンティクスの記述を必要としている。相互運用性の考察と拡張性の問題もまた、Dublin Core（とその他のメタデータ）に関する利用の筋書きの細かな考慮を必要とする。つまり、それがどのように作られるか、それがどのように配置され相互作用を受けるか、そしてそれが様々なアプリケーションによってどのように用いられるか、という問題である。
 

4.　Dublin Coreの概要

Dublin Coreに関する詳細に関心のある読者の方は完全版のDublin Workshop Report（註4）を読まれることを勧める。このセクションは、Dublinでのメタデータ研究会で定義されたDublin Coreメタデータ集合の要約を目的としている。この文章の残りの部分の文脈はそれによっている。

読者は、Dublin Coreを理解するには用語法上の問題があることに注意されたい。Warwick研究会の作業の一つは、Dublin Coreをここで述べるより大きな文脈の中で検証するとともに、Dublin Coreそれ自体を再評価することであった。研究会報告の中には、Warwickでの会合の成果としてのDublin Coreの定義に対する変化と改善について議論がなされるものも含まれている。さらには、この論文で後ほど言及する未解決の問題は、Dublin Coreの定義の中での潜在的な変化の追加的領域を指し示している。このセクションと次のセクションの焦点は、Warwickでの会合に先行して存在していたものとして、Dublin Coreの状況を記述・評価することである。

Dublin Coreの目的は、ドキュメントライクなネットワークオブジェクトの記述および自動化されたインデックス作成を容易にする、記述的要素の最小限度の集合を提供することである。加えて、Dublin Coreは、インターネットに情報を提供してくれる作者や形式的な出版者のかなりの部分が理解し、利用するのに充分な程度に簡単であることが意味されている。先ほど述べたように、もともとのDublin Coreの提案は意図的にシンタクスの問題を避けたのである。

Dublin Coreの13の要素が図1に示されている。
 

図1 - Dublin Coreのフィールド

これらのデータ要素を列挙することに加えて、Dublin研究会報告は中核をなすメタデータ集合全体に適用される数多くの基底となる原理を明確にしている。

・コア・メタデータ集合はサイト特有あるいはドメイン特有の追加的データ要素の包含を認めるために、拡張可能である。

・コア・メタデータ集合のすべての要素は、コアを利用するオブジェクトのどの特定の記述においてもオプションである。この理由は二つある。一つは、コアの要素の中にはある一定のドキュメントに対してのみ意味を持つものがあるということである。たとえば、coverageフィールドは主に空間的なリソースに対し有用である。第二は、不完全な記述はどうしても、確実に、Dublin Coreが扱うことを意図されたこれらの使用法のシナリオの下にあるということである。つまり、プロの分類者やインデックス作成者というよりも、作者やサイトの管理者、プロでない出版者や情報提供者によるドキュメントの記述のことである。

もともとのDublin Core文書においては、これらの拡張のレジストリや、それらの相互運用性や拡張性に対する意味付け、あるいは実際、典型的な使用法のシナリオの文脈における修飾語の使用に関しては、何の考慮もなされていない。
 

5.　Dublin Coreの評価

1995年のDublinメタデータ研究会の成果は、記述的メタデータ集合の完全な定義ではなく、中核をなす記述的メタデータ集合へ向けての最初の一歩となることを目指していた。Warwick研究会において前進するためには、Dublin Coreの定義の評価と実装のためのプラットフォームを提供するのに必要な作業を決定することが必要となった。このセクションではその評価についての要約を述べる。ここで述べられている問題の中には、Warwick Frameworkによって扱われたものもある。また、Dublin Coreの要素のためのシンタクスや著者のためのガイドラインといった問題は、Warwick研究会から生まれた他の文書で扱われている。将来の作業のために残っているのはあまりないといってもよいだろう。

ここでなされている批判の多くが実際上の意味においては不公平であると認めることは重要である。Dublin研究会は、充分に定義された最終的な生産物を作ることではなく、むしろ最終的な生産物の究極的な定義に向けて発展し、コンセンサスを築くことを、意図的にその目的としている。
 

5.1　Dublin Coreの定義は緩い

Dublin Coreの著者たちは、その定義が極めて緩いことをたやすく認める。シンタクスについての定義もなく、すべてがオプションで、すべてが拡張可能で、すべてが変更可能であるという原理を持っているため、Dublin Coreの定義は相互運用性の基準にさえ到達していない。専門化することは、Dublin Coreをリソース発見とインデックス作成のもととして利用する可能性のあるシステム・デザイナーや検索エンジン（"web crawlers and spiders"）のためのガイダンスを提供しない。このレベルの正確さと具体性に到達することはDublin研究会の範囲を超えたものではあるが、将来の発展にとって欠かせないものである。
 

5.2　ネットワーク上のリソースの作者と出版者はコア情報を提供しないかもしれない

Dublin Coreの単純さは、WWW上の一般的な、多くの専門家でない作者や出版者のために役立てるという希望がもとになっている。しかし、この層の情報提供者は、最も簡単な記述的情報すら提供しないという経験的証拠がある。さらに、ただ非常にあいまいなセマンティクスで、統制のない語句使用がなされ、Dublin Coreの領域内での適切なシンタクスの定義もないために、提供されたいかなる情報も疑問点を有する、あるいは意味がないという可能性すらあるのである。少なくとも、アルゴリズムに従って処理することは不可能かもしれない。Dublin Coreのデータの要素は、実際上は、エンドユーザである人間に対して示される情報のための輸送メカニズムとか分類メカニズムとして役立っている。つまり、せいぜい、ヒューリスティクスを発展させる際にタグをつけていくDublin Coreを少々考慮して、ヒューリスティックに処理されるだけである。

このことは、Dublin Core自体の批判というよりも、むしろ作者から提供される記述的メタデータの要素を含む実装シナリオを発展させる際の問題認識であると認識することが重要である。著述やネットワーク「出版」の一部としてこのような情報をつくりだすことを促進することは発展への鍵である。Warwickでの会合の主な焦点は、作者や管理者がDublin Coreのデータの要素を提供できるようにするための実践的メカニズムの発展であった。
 

5.3　Dublin Coreは機能的で管理的なメタデータの問題を避け、記述的分類の優越性を提示している

Dublin Coreは、省略された記述的分類のための手段以上のものではないということを明示している。しかし、この問題には後でまた戻るが、記述的分類はネットワーク・オブジェクトに関連する可能性のある多くの異なったメタデータ集合のうちの一つの集合に過ぎないことに注意しておくことは大切である。オブジェクトの管理と関係するものなど、これら他の多くのメタデータ集合も同じように重要であり、明記する必要がある。Warwickでの会合における実装経験に関する議論において、ほとんどすべての実装が、記述的分類に加え別のタイプのメタデータとともに作業することが必要であると分かり、異なったタイプのメタデータを首尾一貫して扱えるようにするパッケージ化と搬送および組織化戦略を発展させることが得策であると分かったということに注意することが大切である。
 

5.4　Dublin Coreは一般的な記述的分類の要素に集中する一方、いくつかのドメイン独特の要素も含んでいる

繰り返すが、達成したコンセンサスの重要な点は、Dublin Coreは一般的目的の実行から記述的分類を明白に分離する数多くの要素を含んでいたということである。たとえば、カバー範囲という要素は空間的、時間的データに特有であり、ソースという要素は一般にもともとデジタル形式でない資料にとって意味がある。関連という要素は極端にドメインに依存している、独特の疑わしさと不明確をもったセマンティクスを有している。その他の専門化された要素もコアに含めるべきという議論もあるかもしれないが、そのことは、すべての種類の新しいメタデータに関する定義を爆発的に増やす恐れがある。
 

5.5　しかしDublin Coreはメタデータにおけるコンセンサスの発展に向けての重要なステップである

これらの批判の多くは当たっているけれども、Dublin Coreは、少なくとも、重要な分野における将来の議論のためのしっかりした基盤である。完全なライブラリ・スタイルの記述的分類はただ単に、圧倒的大多数のネットワーク上のドキュメントにとってあまりにも高くつくだけであり、より安い代替策への必要性は明白である。Dublin Coreは少なくともこの問題を扱っており、それを作り上げる努力はより長いプロセスの中での最初の一歩として価値のあるものであったといえよう。

加えて、限られたコンテクストにおけるDublin Coreの使用は非常に有用な結果を作ったかもしれない。たとえば、保全性の高いサイトの集合を想定してみよう。そのようなサイトの管理者は、相対的に統制のとれた語彙と規則的なシンタクスを含んだ非常に特定化された実践の集合を利用して、こういったサイトのドキュメントをDublin Coreのメタデータ要素を用いてタグ付けするかもしれない。このような 保全性の高いサイトを通しての情報検索効果は、おそらくLycosやAlta Vistaを通して現在利用可能な構造化されていない検索に比べて（メタデータを利用する情報の獲得・検索のツールを想定すれば）非常によいものとなるであろう。 われわれは、これらのサイトが有料で検索サービスプロバイダを記載し、ユーザが検索をこのようなサイトに限って行なうことが可能となるような市場構造を想像することができるのである。
 

6.　より広範な文脈におけるメタデータ事情

1995年のDublinメタデータ研究会の主催者たちは、研究会の報告書にも「情報源の記述問題の大きさと複雑さを避けて」とあるように、意図的にその範囲を狭めていた。この制限は研究会において何らかの具体的な成果を出すためには不可欠であると思われた。

Warwick研究会の初日が終わるまでには、この「制限を設けるという」戦略が以前に達成されてきたものを越えるには障害であることが明らかになった。三つの問題が表面化し、それぞれわれわれの視野を広げる必要性を明確にした。

1.　Dublin Coreの要素の数は拡大されるべきか？ または減らすべきなのか？

研究会参加者の中には、著作者の道具としてコアが成功するために、記述要素は最低限の基本的なものに限定すべきであると感じるものがいた。また一方で、利用条件、管理者のための新しいフィールドを追加する必要を主張する向きもあった。

2.　コアのシンタクスは厳密に定義されるべきか？ またはそのままに残されるべきか？　

多くの参加者が、標準化の作業に加わった者はなら直面したことのある、厳しい「シンタクスをめぐる戦争」を回避したいと考えていた。しかし、シンタクスのより具体的な定義がなければ、Dublin Coreは期待されるレベルの相互運用性を提供できない。

3.　コアは既存のWWW構造のみを射程に入れるべきなのか？ または構造を広げるべきか？

ウェブ環境の上で最近の実践とより緊密に合わせた、また簡単に既存のWWWフレームワーク（ブラウザ、サーバ、HTML仕様など）の中で実装されることの可能な、メタデータ基準の特定化によって簡単に採用をすすめる議論が根強く存在する。しかしながら、ウェブは明らかに有限のネットワーク化された情報提供媒体であり、多くのウェブの欠点がIEFT、W3Cや他の場所で活発に議論されている。多くの研究会参加者は、彼らが記述するメタデータフレームワークが、一方で、既存のWWWの技術を拡大させ、FTPアーカイブのような、古いもののいまだに重要であるネットワーク情報モデルを収容するだけの十分な柔軟性を維持すること、しかし他方で、分散オブジェクトシステムのように新しい情報提供環境へと拡張可能であることが重要であると感じていた。

われわれは、コアメタデータ要素から焦点を外し、メタデータの一般的な原則を検討することで、これらの問題にこたえることができる。
 

6.1　メタデータの形成の多様性　特殊化と一般化

記述的分類はメタデータの分類分けのひとつにすぎない。しかし、たとえわれわれがこの分類に自分たちを制限しても、多様な分類手法と交換フォーマットは存在し、その正当な理由も存在する。

完成度の高いAnglo-American分類規則（AACR2）とMARC（註5）交換フォーマット（その数多くのバリエーションも含む）は既存のすべての電子図書館システムの基礎になっており、非常に多くの種類の内容を記述する創造性と符号化の点で効率が良いことが証明されている。しかしながら、非常に複雑な規則は円滑に適応を行なうための熟練した分類担当者を必要とする。また、MARCレコードの隠された構造は複雑で、記録と交換のための特別なシステムを必要とする。Dublin Coreのような単純化された記述的規則では、大半の著作者にとって簡便であるが、図書館の分類の特徴である検索精度、類別区分や系統化についてはそこまでの段階にいたっていない。「Computer Science Technical Reports（註6）」などの計画によれば、簡潔な記述的規則は、ごく普通のテキストエディタによってさえ作られ得る簡単な交換フォーマットと合わせることで、訓練されていない著作者や編集スタッフにも、記述的な記録を充分なレベルで作ることを可能にすることが証明されているという。Dublin Coreはこの経験に基づいて設計されたものである。最終的には、Federal Geographic Data Committee（註8）（FGDC）の成果である「Content Standard for Degital Geospatial Metadata（註7）（CSDGM）フォーマット」のような、ドメイン特化のフォーマットや、数学ソフトウェアパッケージを表記するためのスキーム、または保健科学における類別区分と表記のためのスキームが存在することになる。これらのスキームはかなりの程度の記述的な分類を含み、そしてMARCやAACR2よりも複雑なものであるならば、特定の利用者の共同体や特定のソフトウェア環境（ともに記録も検索も）の複雑なデータ群を正確に表記するために、補完的な存在としてではなく、提供されることになる。

しかし、実際の世界で応用するには記述的な分類よりもより広い範囲のメタデータを使用する必要性がある。すべてを網羅していることはないと断りをつけた上で、この範囲の意味を提供する他のメタデータの種類を以下に列挙する。

6.2　ネットワーク情報通信基盤の発達としての新しいメタデータ集合の発展

オブジェクトを記述し、管理するために必要なメタデータの範囲は、われわれがより洗練された方法でオブジェクトを特徴付け、検索していくこと、またネットワーク情報オブジェクトの使用を管理をする要求が高まることにともなって、拡大しつづけていく傾向がある。マルチメディアWWWそしてあらゆる所でアクセス可能（つまりは子供も家庭でアクセス可能）なインターネットの時代である今日に至るまでに、内容評価の必要性を誰が考えたというのだろうか？例が示すように、グローバルインターネットにおいて所有権のかかわるコンテンツが多く入手可能になるほど、利用条件の定義などがネットワーク化された情報市場を作るための必要条件として強調されることになる。このためのアーキテクチャは十分に柔軟性をもち、既存の集合を書き換えることなく、新しい分類のセマンティクを含み込むことができなくてはならない（メタデータを書き換えるためにネット上を走り回らなければならないことを考えてほしい）。

6.3　異なる共同体が異なる型のメタデータを提案し、デザインし、責任をもつ

それぞれ論理的に異なるメタデータ集合は、特定の共同体の専門知識についての利益や分野を表している。たとえば精巧な記述的分類集合は図書館司書、特にその中の分類専門家によって最もよく作成され、維持されている。利用条件のメタデータ集合の内容は、ビジネスや法律の専門知識をもち、知的財産権問題の背景をもつ人々によって最もよく理解される。それぞれの共同体は独立して「その影響下」にあるべきメタデータをつくりだし、維持することが可能でなければならない。いくつかのメタデータ分類は、特定の法的な、または規制的な必要性を満たすために存在する。たとえば、そのようなメタデータの一部で行なわれる主張には、その共同体に関係する特定の法的責任が存在することがある。

異なるメタデータ集合についての異なる起源や管理は、非常に多様なシンタクスと記法をもたらす。たとえば記述的分類データなど、いくつかの型のメタデータでは、静的なテキスト表現で必要が満たされる。他の種類のメタデータは、実行可能な（または解釈可能な）プログラムのような、より強力な方法によってのみ表現される。これは特に、クライアントとエージェント、外部サービス（認証サービスや支払いサービス）の間での交渉を明確化するような、利用条件を符号化するようなメタデータに該当する。

6.4　メタデータの多くの「利用者」

メタデータの情報ソースがさまざまに異なるのと同様、異なるメタデータ集合は別々の共同体に属する利用者とエージェントに利用され、そのような共同体に制限されうる。機械解読性がある型のメタデータにとっては重要であるが、別の型のメタデータでは人間にとっての解読性が重要な場合もある。ある型のメタデータ集合の用語法は分野に特化しているかもしれない。それぞれのメタデータ“利用者”は関連するメタデータに直接アクセスできることが必要である。逆の視点から眺めてみれば、特定の共同体の利用者とエージェントに関係した一定の種類のメタデータへのアクセスを選択的に制限する理由がある場合もある。特定のメタデータ集合を、システムがその内容にアクセスすることなく、システム間を横断して搬送できる必要性が生ずるだろう。

6.5　メタデータとデータの類似的な振る舞いおよび特徴

厳密に、また杓子定規に「情報」をデータとメタデータに区分けすることは正しくない。ある文脈でメタデータと見えるものも、他の文脈ではデータに思われることがある。たとえば評論家の映画評論が、映画というコンテンツを記述するとして、メタデータとして分類されることがある。しかし、評論自体は知的コンテンツであって、多くの場合、データとみなされる。他のデータのように、その評論はメタデータや、特に、知的財産としてそれを保護する利用条件と関連しうる。このデータとメタデータの再帰的な関係は、恣意的に深いレベルにその根をもっている。

6.6　物理的に配置された、または間接的に参照されたオブジェクトとメタデータ集合の連関

もしもわれわれが本当の意味で分散情報通信基盤を想像するとすれば、われわれの分散の概念はオブジェクト間だけに関わるのではなく、オブジェクト内に関わるものでもあるはずである。つまり、オブジェクトのためのメタデータは、複数の独立して管理されているメタデータ集合の集合体であり、それぞれのメタデータ集合はネットワークで別々に維持される。物理的に離れた集合への参照は、Universal Resource Names（註10）（URNs）やHandles（註11）として提案されているような、信頼できる永続的な名の通ったスキームで行なわれるべきである。

メタデータ集合への間接的参照はメタデータ集合の共有によって協力しておこなわれる。たとえば、多くのコンテンツオブジェクトをともなったレポジトリを仮定したときに、それらのうちの数多くが同じアクセスのための利用条件をもっている（たとえば定期刊行物の集合のためのサイトライセンスをともなった大学電子図書館など）。われわれはこのことを、名前の参照を使い、オブジェクトの集合を利用条件を符号化したものにリンクさせることで表現できるはずである。したがって、われわれは、その共有された符号化を変更することによって、オブジェクト集合のための利用条件を修正することができなければならない。共有された利用条件メタデータは、逆に知的財産管理を専門にする外部提供者によって管理されるレポジトリの中に存在することもある。
 

7.　Warwick Frameworkアーキテクチャ

Warwick研究会における、これまでに述べた分析の結果として生まれたものが、複数のメタデータ集合を総合化するためのアーキテクチャ、すなわちWarwick Frameworkである。Warwick Frameworkの基本的な構成要素は二つある。ひとつは型付けられたメタデータ集合、すなわち「パッケージ」であり、もうひとつはパッケージを総合化するための単位、すなわち「コンテナ」である。

コンテナは一時的でもあり、永続的でもある。一時的な形式においては、コンテナはレポジトリとクライアント、エージェント間の交換オブジェクトとして存在する。永続的な形式では、情報通信基盤の第一級オブジェクトとして存在する。つまりコンテナはひとつ以上のサーバに貯められ、それらのサーバからグローバルなアクセス識別子（URI）を使ってアクセスすることができる。コンテナが他のオブジェクト内でもラップされることがある（つまりあるオブジェクトがデータとメタデータ双方のラッパーになっている）ことには留意する必要がある（これは後に提案されている分散オブジェクト実装の部分で示される）。この場合、ラップするオブジェクトは、メタデータコンテナそのものでなく、またはそれに加えて、URIをもつ。

実装から独立して定義されたコンテナの唯一の操作は、コンテナ中のパッケージの連鎖を返す操作である。この連鎖の成員を順序立てるための規定は、この操作にはない。そのため、クライアントが、あるパッケージが、他のパッケージよりも重要なのか、よいのかを想定する方法はない。

コンテナレベルでは、パッケージは不透明なビットのストリームである。これらの特性から示されることの一つは、コンテナのためのどのような符号化（交換シンタクス）であっても、コンテナの受容者が、コンテナ内の未知のパッケージをスキップできるということである（換言すれば、パッケージの大きさはコンテナレベルで自己で記述していなければならないことになる）。この特性は、個々のパッケージの内容が暗号化され、特定の集合へのアクセスを必要としない、あるいはそのようなアクセスを入手する（つまり、購入する）必要がある、メタデータの搬送をシステム間で許容する。この文書で後に提案されるHTMLの例のように、これらの含意は、コンテナの抽象的な特性を充分に主張するだけの力を欠いている。

パッケージは型付けられたオブジェクトである。パッケージの型はクライアントとエージェントによるアクセスのあとで決定されるもので、次の三つの種類がある。

  1. メタデータ集合：これらは実際のメタデータを含むパッケージである。MARCレコードやDublin Coreレコードや符号化された利用条件などのパッケージがその例である。潜在的な問題は、クライアントとエージェントが、多くのメタデータ集合のセマンティクスを認識し処理する能力である。加えて、クライアントとエージェントはと、新しく導入されたメタデータ型に対応しなくてはならない。少なくとも上品に無視できるほどではなくてはならないか、そのメタデータ型の使用方法を知っている下流アプリケーションのためにコピーしなければならない。初期のWarwick Frameworkの実装は、良く知られたメタデータ集合を含むものであるはずで、これは大半のウェブブラウザが、良く知られたMIMEタイプのための処理系をもっていることと同じようなものである。拡張可能なメタデータ集合を処理するものとしてWarwick Frameworkの実装を拡張するためには、型レジストリスキームに頼ることになる。これについてはこの文書の実装の部分においてさらに詳しく述べることとする。
  2. インダイレクト：これは情報通信基盤の中で他のオブジェクトに間接的参照を行なうためのパッケージである。間接的な参照はURLを使用して行なわれることになるので、信頼できるURNの実装の存在が、ウェブを悩ませる参照を多用しなくてはならなくなる問題を回避するために不可欠と思われる。間接的な参照に関しては三つの明確な、そして重要なポイントがある。一つは間接パッケージの参照先が第一級オブジェクトであって、自分自身のメタデータを、そして重要なのは、アクセスのための利用条件を自分自身でもっていることである。2番目には、間接パッケージの参照先が他のコンテナによっても間接的に参照されていることである（つまりメタデータオブジェクトの共有）。最後に、間接的な参照の参照先が、参照の対象となっているコンテナの中ではなく、他のレポジトリやサーバの中にある場合である。
  3. コンテナ：これはそれ自身がコンテナであるパッケージである。この場合、再帰のための定義された限界は存在しない。
図2はWarwick Frameworkコンテナの単純な例を示したものである。この例では、コンテナは三つのメタデータの論理パッケージをもつ。最初の二つはDublin CoreレコードとMARCレコードであり、コンテナに二つのパッケージの組として含まれている。三つめのメタデータ集合は、コンテンツオブジェクトへのアクセスのための利用条件を定義していて、コンテナ内のURIから間接的に参照される。利用条件のメタデータと管理用のメタデータのためのシンタクスはまだ定義されていないことに注意すべきである。
 
 
figure 2
図2 - 三つのパッケージ（一つはインダイレクト）を内包したメタデータコンテナ
 

コンテンツオブジェクト（つまり文書）をWarwick Frameworkコンテナに関連づけるための機構は、Warwick Frameworkの実装に依存する。この文書で提案される実装については後述されるが、そこにはいくつかの選択肢が挙げられている。たとえば、単純なWarwick Frameworkコンテナは、HTML実装提案で示されているように、文書内に埋め込むことができる。または、HTML文書は別のファイルとして記憶されたコンテナにリンクを張ることができる。一方では、分散オブジェクトに関する提案で示されたように、コンテナは、ネットワーク化されたオブジェクトを表すデータ構造ともいえる、いわゆるデジタルオブジェクトの論理的な部品として存在する可能性もある。

コンテナを知的コンテンツの部分と結び付ける、逆のリンケ付けも関連する。実際、情報源の所有者や管理者の許可もなく、彼らに知らせることもなく、誰でもネットワーク情報ソースのために記述的なデータをつくりだすことができる。このメタデータは、本質的に、ある情報ソースの所有者がその情報ソースからリンクを張るメタデータや、オブェクト内に埋め込むメタデータとは異なるものである。そのため、われわれは同じ実装の手法を用いるとしても、非公式ながら二つのカテゴリのメタデータコンテナに分けなければならない。
 

 figure 3
図3　コンテンツとメタデータの関係
 

図3はコンテンツとメタデータの関係を示したものである。三つのメタデータコンテナが描かれており、ひとつは内部から参照されるメタデータコンテナで、コンテンツオブジェクトに埋め込まれている（URIをもたない。またコンテンツへの参照のためのリンク付けパッケージも存在しない）。二つの外部から参照されるメタデータコンテナは独立のオブジェクトである。これらはURIをもち、URIを通じてコンテンツオブジェクトを参照する。

内部から参照されるメタデータコンテナは、この図では間接的にコンテンツによって参照されることも可能である。この場合には、独自のURI（URI4と呼んでおく）をもち、URI3（コンテンツ）を参照するリンク付けパッケージが存在する。
 

8.　Warwick研究会における未解決の問題

Warwick研究会における時間的な制約により、提案されたフレームワークの全ての問題を十全に解決することはできなかった。フレームワークを仕上げる前により細かな拡大された考察を緊急に要するいくつかの項目がある。当然、Warwick Frameworkにおける最も根本的な問題は、コンテナの中で起こりうる、多くのメタデータ集合の間のセマンティクスの相互作用とオーバーラップである。パッケージはそれぞれある程度論理的に区別できるが、それらはいくつかの仕方でオーバーラップする可能性のあるセマンティクスを持つ。

このオーバーラップは様々なレベルで起こりうる。まず、一つのコンテナ内の二つのメタデータ集合の間で起こりうるセマンティクスの水平的なオーバーラップがある。その一例は、二つの記述的分類レコードを持つコンテナであり、一つがMARC、もう一つがDublin Coreである場合。また、一方がコンテナの中にあり、一方がそのコンテナに由来する任意の再帰レベルにある二つのメタデータ集合の間に起こるセマンティクスの垂直的なオーバーラップの可能性もある（コンテナは別のコンテナを含んだり、間接的に他のコンテナを参照することがある）。一例は、オブジェクトの構造を下るに従って多様な利用条件を持つ複雑なオブジェクトである。ここでの問題は、複合的オブジェクトの中のパッケージに含まれるメタデータがそれに当てはまるであろう、一つまたは複数のオブジェクトの範囲である。

最後に、オブジェクトに関連したメタデータのセマンティクスはメタデータの「消費者」によって理解される必要がある。つまり、オブジェクトにアクセスするクライアントやエージェント、そしてこれらのクライアントやエージェントを形成するユーザーである。われわれはWarwick Frameworkの完全な表現をする際に、メタデータを使いものにならないほどに複雑なものにしてしまうという危険を冒している。適当なバランスを見つけることはデザインの中心的問題である。

例えば、普通のメタデータの消費者 --- 記述的データやネットワーク化されたオブジェクトを集めてそれを検索可能な目次に編集しようとする検索エンジンのことを考えるとよい。このエージェントの設計は、記述的分類のメタデータが、関連性や一貫性なしにそれぞれのオブジェクトごとに異なるいくつかのメタデータ集合に入っていたならば難しいだろう。この恣意的に混ぜられたメタデータから使用可能な目次をつくるルールはどうなるか？ 複数のメタデータ集合間でどのようなセマンティクスの変形が可能だろうか？

われわれは、より複雑ではないにせよ類似の問題を、オーバーラップするオブジェクトのアクセス規則や利用条件を説明するメタデータに見出すことができる。マルチメディア文書のような複雑なオブジェクトへのクライアントアクセスの際には、いくつかの利用条件を文書の複数のレベルで交渉する必要があるかもしれない（ある利用条件をテキストのある節に、他の利用条件ををフルモーションビデオの一部分、というように）。しかしまず第一に、クライアントに関係があるのは、オブジェクトがアクセス可能かどうか、そしてどれだけのコストがかかるかということである。これは、特にコンテナ間の恣意的に深い再帰や循環参照の可能性を考えると計算は困難である。われわれは、オブジェクトをクライアントやエージェントにアクセスできるように強く促す市場の力が、この性質の最も複雑な問題を回避すると考える。

Warwick研究会で表面的にしか議論されなかった提案が、Dublin Coreの関係性要素を外部化・一般化する関係性メタデータパッケージを開発することの可能性であった。もしこの方法が採用されれば、改訂Dublin Coreからは関係性要素は取り除かれ、複合オブジェクトについての曖昧さの一因が消えることになる。しかし、Dublin Coreだけでなく多くのメタデータ計画が、関係性や階層構造の概念を含むため、これは問題を完全には解決しない。

この根本的な問題に加えて、Warwick Frameworkを実装する上で検討が必要ないくつかの実装の問題を次に掲げる。
 

8.1　型レジストリ

Warwick Frameworkの設計は、パッケージが強く型付けられることを要求する。これは、エージェントやクライアントがパッケージの中のメタデータの型を特定できるということを意味する。メタデータ集合の定義者は、一連の操作やその操作のセマンティクスがパッケージ毎に厳密に定義されているようにしなければいけないということである。われわれはメタデータの型の限られた集合が広く使われ、エージェントやブラウザやクライアントはこれらのメタデータの型を加工するように設定されていくことを期待する。これは既存のWWWブラウザが内部的にMIME型の文書を加工することができることと類似である。

後述するように、新しいメタデータ集合や既存の集合のバリエーションが現われることにそなえて、型システムは拡張可能でなければならない。既存のクライアントやブラウザはこの新しい型をどのように扱うのだろうか？ 最も単純な解決法は、新しいメタデータ型が現れるたびに既存のソフトウェアがアップグレードされるべきである、というものである。そのアップグレードが行なわれるまでは、コンテナ構造は少なくとも、ソフトウェアが新しい未知のパッケージ型を飛ばし、ユーザにそのことを伝えることを許可するものになっていなければならない。このような解決法は新しい型がしばしば現れると対応できない。よりよい解決は、ネットワークを基にしたソフトウェアによって問い合わせ可能な型レジストリサービスである。このサービスは、クライアントにそれ自身を新しい型を処理できるように再設定することや、新しい型を処理するためにネットワークでアクセスできるアプレットまたはヘルパーアプリケーションのダウンロードを可能にする情報を提供することができる。

しかし、この方法にも限界は存在するが、十分理解されていない。型のシステムは処理アプリケーションに、新しい型のある種の意味を伝達する必要がある。これは、アプリケーションにまず、その新しい型を知らないことが果たして問題なのかどうかを最初に判断することを可能にするかもしれない。この回答に基づいて、アプリケーションは機能拡張やヘルパーアプリケーションをダウンロードする必要があるかを判断することができる。例えば、現在のブラウザは起源についての情報を処理しないし、多くのユーザは起源について理解しも気にもしない。

階層構造や、もしかしたらある種の継承が、型システムに必要かどうかの問題もある。例えば、われわれは、権利と許可のメタデータについての一般的なクラスが、このメタデータの型に使われている多様な「方言」、および転送シンタクスならびに表現を理解することを望むだろうか。
 

8.2　データの符号化

Warwick Frameworkは、データ符号化に関して二つの問題を持っている。コンテナのレベルでは、パッケージの集合を転送するためのシンタクスは何かという問題である。転送シンタクスは、コンテナのレベルでは内容が不明であるパッケージのシンタクスからそれ自体独立である必要がある（パッケージそのものが符号化されることさえあるかもしれない）。それは型の情報を持っている必要がある。理想的には、われわれはそのシンタクスが比較的単純になることを信じている。われわれはこのコンテナのシンタクスについての提案を後続の実装の節に含めることにする。

データ符号化に関するより困難な問題はパッケージのレベルにある。ここにはただ一つの正解は存在しない。いくつかのメタデータ集合はASCII文字で属性と値の組として適切に表現されうる。他のメタデータ集合のデザイナはSGML、HTML、ASN.1といった他の構造を好むかもしれない。このシンタクスに含まれるフィールドは、単なる文字列や整数よりも遥かに複雑かもしれない。例えば、オブジェクトへアクセスするための利用条件を説明したルールを考えるとよい。最も単純な場合には、このルールはオペレーティングシステムの世界でよく確立されているようなアクセス制御リストによって表現されるだろう。しかしながら、デジタル分野における現在の法律とビジネスの枠組みの完全な表現の為には、交渉、挑戦と応答、第三者サービス（支払いサービス、認証サービスなど）との相互作用などに対応するルールも必要となる。この型の適応的・相互作用的メタデータは実行可能なプログラムやエージェントを通じて最もよく表現される。

メタデータをそれぞれ独立したシンタクスを持つ分離したパッケージに分節化するというわれわれの方法は、この問題において少なくとも進歩をもたらす。単純なクラスのメタデータは単純なシンタクスを使用できるし、より複雑な要求を含むクラスはより複雑で強力なシンタクスを得ることができる。しかし、Warwick研究会を動機づけた中心的な問題に立ち帰ると、Dublin Coreのデータ要素それ自身のための一つ以上のシンタクスについての合意が必要である。
 

8.3　効率性

Warwick Frameworkの力は、その再帰的で、分散的な特質に求められる。このことはモデルに大きな力を与えるが、実際の実装においては非効率になる恐れがある。比較的単純なWorld Wide Webにおいても、インターネットはしばしば耐え難く遅く、信頼性に欠ける。接続は、しばしば過負荷、サーバの失敗、その他によって失敗したりタイムアウトに陥ったりする。Warwick Frameworkの完全な実装においては、「文書」へのアクセスは、分散されたレポジトリ間での複雑な交渉を必要とするかもしれない。この分散アーキテクチャのパフォーマンスは予測不可能で、複数の場所での失敗の可能性を秘めている。この分散アーキテクチャにおける効率的な操作は、キャッシュ、データやオブジェクトの複製、動的な負荷の均衡化や分散システム研究で検討されているその他の方法を用いて改良されたネットワークの情報通信基盤に依存することになる。
 

8.4　レポジトリアクセス

コンテナやパッケージの交換と検索のために、いくつかのプロトコル作業が必要であることは明白である。われわれは、検索の為の多様な形式の必要性を予想する。単純な場合は、オブジェクトの為のコンテナの検索である。より複雑なケースは、特定の型の集合を持つパッケージを含むコンテナだけを検索する場合である。このプロトコルへの要求の詳細は全く研究されていない。Warwick Frameworkとレポジトリ構造における現在進行中の作業との間の関係性の調査は有意義なものとなるだろう。
 
 

9.　Warwick Frameworkの実装

デザインの簡単さと素早い普及は、Dublin Coreの設計において最も重要なポイントであった。一見、Warwick Frameworkは、私たちに以上のような長所を見捨てさせ、現在のHTML、HTTP、WWWブラウザの世界に合わない構造を提案させるように見えるかもしれない。しかし、実際、Warwick Frameworkの基本的な概念、つまり一つのコンテナの中に多くのメタデータ集合を配置する能力は、現存するWWW基盤の中で発揮できるのである。このセクションでは、Warwick Frameworkの実装について説明する。

しかし、もしも現存するWWWに対応してデザインと実装を抑制したものにすると、われわれは大きなチャンスを逃してしまう。WWWは発展し、よりパワフルな情報通信基盤に置き換えられるだろうと考えられる。このような情報通信基盤の研究開発は、DARPA/NSF/NASAのJoint Digital Library Initiative（註12）や、その他の国際的な電子図書館研究プロジェクト、そしてその他の多くの主体の手によってなされつつある。情報通信基盤の発展を想定しつつ、これから、Warwick Frameworkの実力が十分発揮することができる実装をいくつか提案する。
 

9.1　HTMLによる実装

もしも初期の実装が、現存するWWWのソフトウェアに何の修正も要求しないのでなければ、Warwick Frameworkの素早い普及はみられないだろう。このセクションでは、HTML 2.0に適合したWarwick Frameworkの実装について説明するが、これは、現存するブラウザや検索エンジン、HTMLオーサリングツールで使用可能である。OCLC（註14）のEric Miller（註13）がこの実装の最初の提案者である。この提案は、1996年5月に行われたW3Cが資金提供したDistributed Indexing/Searching Workshop（註15）においてなされた。後に述べるシンタクスは、メタデータ集合への間接的参照に対する対応を視野にいれつつ、研究会においてなされたこの提案（註16）を拡張したものである。

この実装はHTML2.0の二つのタグを使用する。
 

 

9.1.1　METAタグ

HTML2.0のMETAタグは、名前と値の組み合わせを特定する役割を持つ。この組み合わせはNAME属性とCONTENT属性を使用して符合化してある。HTML文書のHEAD部は複数のMETA要素を含むことがある。METAタグの簡単な例としては、次のようなものがあげられる。

<META NAME="title" CONTENT="Gone With the Wind">

複数のMETAタグを一つのメタデータ集合にまとめるNAME属性の値のための符合化について説明する。その符合化は次のようなものである。

<META NAME="<schema_name>.<element_name>" CONTENT="string data">

この符合化においては、<schema_name>テンプレートはそれぞれの相当するメタデータ集合の一意の接頭辞によって置き換えられる。また、<element_name>はメタデータ集合の中の属性名によって置き換えられる。一意の<scema_name>符合化の登録は、現時点ではなされないままである。もし<schema_name> DCがDublin Coreの要素に適用可能であるならば、部分的なDublin Coreメタデータ集合は次のように符合化できる。

<META NAME="DC.Title" CONTENT="HTML 2.0 Specification">
<META NAME="DC.Author" CONTENT="Tim Berners-Lee">
<META NAME="DC.Author" CONTENT=Dan Connolly">

この同じHTML文書は<schema_name>接頭辞を持つ他のメタデータの集合を含むかもしれない。例えば、ADM集合と呼ばれるであろう管理用メタデータの基準、といったものが挙げられる。ADM集合は次のように符合化される。

<META NAME="ADM.Administrator" CONTENT="Bill Clinton">
<META NAME="ADM.Modified_Date" CONTENT="050696">
 

9.1.2　LINKタグ

次にあげるLINKのためのシンタクスは、<schema_name>型のメタデータを含むドキュメントが<URL>に存在することを示すために用いられる。

<LINK REL=META.<schema_name> HREF="<URL>">

例えば、<schema_name>CSDGMを用いた地理空間的メタデータ集合への間接リンクは次のようになる。

<LINK REL="META.CSDGM" "HREF=http://meta_repo.ukp.edu/geometa">

LINKタグには、他にも人間可読なメタデータスキーマの参照定義へのポインタを与える、という機能がある。この符合化はメタデータスキーマの中心レジストリがないことによって動機づけられる。次に挙げるLINKタグのシンタクスは、メタデータスキームの参照定義<schema_name>は<URL>にある、ということを指し示している。

<LINK REL=SCHEMA.<schema_name> HREF="<URL>">

すなわち、Dublin Coreのメタデータスキーマの参照定義は、次の符合化によって示される。

<LINK REL=SCHEMA.dc HREF="http://purl.org/metadata/dublin_core">

HTML文書の中にあるこれらの要素の組合せは図4を参照。
 

<HTML>
<HEAD>
<TITLE>A Sample Document with Mixed Metadata</TITLE>
<META NAME="DC.Title" CONTENT="Sample Document">
<META NAME="DC.Author" CONTENT="Bob Dole">
<META NAME="DC.Author" Content=Bill Clinton">
<META NAME="ADM.Administrator" CONTENT="Bill Clinton">
<META NAME="ADM.Modified_Date" CONTENT="050696">
<LINK REL="SCHEMA.DC" HREF="http://meta.org/meta-reg/Dublin-Core.html">
<LINK REL="META.CSDGM" HREF="http://meta_repo.ukp.edu/geometa">
</HEAD>

<BODY>
This is the body of the sample document
</BODY>

</HTML>

図4 - メタデータが埋め込まれたHTML文書
 

Warwick FrameworkにおけるHTMLの実装は現存するブラウザとの下位互換性（backward compatibility）があるが、コンテナ／パッケージ構造を定義するという甚大な作業を必要とする。HTMLにおいてWarwick Frameworkを充分実装することは難しい。なぜなら、META要素によって出された簡単な名前と価値の組み合わせにおいて複雑に絡み合ったコンテナを扱うのが困難であるからである。

ブラウザがWarwick Frameworkの充分な能力を実装するためには少なくとも二つの潜在的な抜け道がある。MIMEとSGMLである。MIME（多目的インターネットメール拡張）は、電子メールが豊富なデータフォーマットや構造を含むことができるように開発された一連のインターネット規格である。ブラウザはすでにMIMEに対するサポートを制限してきたが、時が経てばサポートのレベルは上昇するであろう。SGML（文書マーク付け言語）は、HTMLを定義するのに使われてきたメタ言語である。すでにSGMLドキュメントを閲覧するためのブラウザの拡張製品は存在するし、ブラウザがもともとSGML機能を持つものとして発展させることも可能である。次の二つのセクションでは、MIMEとSGMLにおいて、Warwick Frameworkがどのように実装されるか説明する。続いて、分散して存在するオブジェクトを使うWarwick Frameworkの実装について説明する。これは、現存するWWWとは全く異なる情報通信基盤を想定したものである。
 

9.2　MIMEによる実装

既に述べたように、そもそもMIMEは電子メールメッセージに様々な内容を入れることを可能にするために作られた標準（RFC-1522他）の集合である。RFC-822のような初期の標準は、メールヘッダの標準化を扱ったが、メールのメッセージ自体の構造については扱わなかった。MIMEは、メッセージの構造を、バイナリデータと複数の構成要素または添付ファイルをメッセージに含むことができるものとした。これらの能力は、Warwick Frameworkのコンテナ／パッケージアーキテクチャの実装に用いることができる。このセクションでは、MIMEの概要を簡単に説明し、その後、Warwick Frameworkにおけるパッケージの三つの型（コンテナ、インダイレクト、メタデータ集合）がMIMEの構成によってどのように表されるかについて言及する。MIMEによるWarwick Frameworkの実装についてのより詳しい報告は、Jon KnightとMartin Tomlinsonによって現在準備中である。
 

9.2.1　MIMEの概要

MIMEは単純な２段階の型付けスキームを定義する。全てのMIMEメッセージはcontent-typeフィールドにおいてこの型を特定する。その型には、text、audio、video、image、application、multipart、messageという七つの主要なものがある。このような型は拡張可能な下位型の集合を持つ。例えば、text型は、text/plain, text/sgml, text/html などといった下位型を持つ。image型は、異なる画像フォーマットを扱うために image/gif, image/jpag, image/tiff などの下位型の集合を持つ。

multipart型は、複数の構成要素を含むメッセージに使用されるが、それぞれの構成要素は異なる型を持ちうる。multipartメッセージの一般的な例はスプレッドシートやグラフィックなどを添付されたASCII電子メールメッセージである。multipartメッセージはbodyパートより構成されるが、その境界は、境界文字列によって示される。bodyパートは、それぞれ関連するcontent-typeを持つ。multipartメッセージは入り組んだmutlipart bodyパートを含むこともあり得る。

multipart型の下位型はいくつかある。
 

 

9.2.2　MIMEによるWarwick Frameworkの符合化

MIME複数パートメッセージのbodyパートは、Warwick Frameworkコンテナのパッケージと直接対応している。これは、図5の例で示されるとおり、MIMEメッセージとしてのメタデータパッケージの符合化を可能にする。図5の例は、二つのパッケージと一つのコンテナを表しているが、これらはそれぞれ、既に定義したメタデータ集合である。コンテナは、multipart/alternative と型付けされるが、これは、包含された二つのパッケージが似たような意味を持つことを表す。コンテナの最初にあるboundary="#####"というテキストは、複数パートメッセージのパッケージの境界を定めるために一意の境界文字列を定義する。最初のパッケージは、SGMLによって符号化されたDublin Core記述であるり、二つめのパッケージは、application/usmarcという型をもつMARCレコードである。USMARCが使えるシステムではDublin Coreよりもそれを使った方が良い。しかし、より単純なシステムのための代替物として、Dublin Coreがある。USMARCは  Content-Transfer-Encodingのためのヘッダを持つ。これは、特殊文字が7ビット文字のみを扱うメールシステムを通して安全に送信されることを可能にする。
 

MIME-Version: 1.0
Content-type: multipart/alternative; boundary="######"

--######
Content-type: text/sgml

<!DOCTYPE dublinCore PUBLIC '-//OCLC//DTD Dublin core v.1//EN'>
<dublinCore>
  <title>On the Pulse of Morning</title>
  <author>Maya Angelou</author>
...
</dublinCore>
--######
Content-type: application/usmarc
Content-Transfer-Encoding: Quoted-Printable

... USMARC record appears in here, a quoted-printable
    encoding is used to handle special characters ...
--######

図5 - MIME 複数パートメッセージとして符合化されたWarwick Frameworkコンテナ
 

message/external-bodyというMIME内容型は、Warwick Frameworkにおける、コンテナの外にあるパッケージを定義するインダイレクトパッケージを実装するのに使用できる。図6の例は、URIを用いてMARCパッケージへの間接的参照を行なっている。IESG（Internet Steering Group）は最近、外部のbodyパートのためのaccess-typeとしてURLを使用することを可能にした標準原案を承認した。

Content-type: message/external-body; access-type=URI;
              name="http://www.foo.bar.com/path/huh.marc"
 
図6 - URIを用いるMARCパッケージへの間接的参照
 
 

9.3　SGMLによる実装

前述したとおり、SGML（註17,18）は、HTMLを定義するのに用いられるメタ言語である。このことは、SGMLが他の言語を定義するのに用いられる言語であり、典型的には、テキストドキュメントにマーク付けするものである、ということを意味する。こうした言語、例えばHTMLは、文書型定義（DTD）を用意することによって定義される。DTDは、大筋では、関係データベースにおけるスキーマ定義に類似している。それらは、ドキュメントにおいて、どのような構造やその組合せが可能であるかを定義する。SGMLにおけるWarwick Frameworkの実装に関する詳細な論文は、Lou Burnard、C.M.Sperberg-McQueen、Liam Quin、Eric Millerによって準備されている。このセクションでは、この論文の草稿段階で考案した、SGMLによるWarwick Frameworkの実装の一つの方法を述べる。

SGMLによるWarwick Frameworkの実装の際には、コンテナ／パッケージ構造を扱うことができ、間接的パッケージやメタデータ集合も扱えうことのできるDTDが要求される。このDTDは、独自のDTDをもつパッケージを含むことができなければならない。例えば、Warwick研究会の成果のうちの一つとして準備されているDublin Core DTDである。また、Warwick FrameworkのDTDは、どんなDTDとも適合しないようなメタデータパッケージを包み込むこともできなければならない。この問題が生じるのは、非SGML表記、例えば、USMARCフォーマットのような表記を使うパッケージを実装する場合である。最後に、SGMLによってメタデータ要素を表現する、迅速かつ簡便な方法がなければならないが、それは、一つの文書に多くのDTDを集める際に生じる、要素名の間で重複が起こらないものでなければならない。

図7におけるDTDは、そうした要求を満たしている。コンテナ／パッケージ階層は、<container>要素と、%PackageTypesパラメタによって実装される。パラメタ実体は、本質的には、DTDの一部分の、テキスト置換マクロである。固有のDTDを持っているパッケージは、%md-setパラメタ実体の定義を上書きするSGML慣用句を使用し、また、文書の宣言部分集合で要求されたDTDを供給することによって、容易に包含される。非SGMLフォーマットのパッケージは、<package>要素にあるNOTATION属性を使用することによって合致させることができる。NOTATION属性の使用についての例は、図8に示してある。例の中では行なっていないが、非SGMLデータは実体参照によって包含されるようにすることを推奨する。これは、パッケージ内に文字“<”が現われると、解析の際に抵触するためである。図8は、文字“<”がデータの中に現われないと保証できる場合には適切である。外部実体への参照は、本質的にはインダイレクトパッケージであるということは、注意するべきである。そうすれば、ほとんどの非SGMLデータがインダイレクトパッケージとして扱われるべきだということになるかもしれない。最後に、<matagroup>要素と<metadata>要素は、新規の要素がDTD定義を増やすことなく取り込む可能にする。

DTDがあることで、SGMLは強く型付けされたパッケージに対する要求に答えられる。しかし、要素のレジストリに対する用意は何もない。このため、異なるDTDにおける要素名は、潜在的に対立する可能性がある。この問題の対処法として、本当に満足できるものは存在しない。SGMLのSUBDOC機能は、名前空間の重複を避けることができるが、広くは実装されていない。前の段落で記述した<matadata>要素は、同じ要素を定義しているDTDを結合する際に生じる玉恵空間の衝突を避けるためには、適当な方法になりうる。しかし、これを応用するには、複数の<metadata>要素がNAME属性に対して同じ値を持っている場合の処理について知る責任がともなう。

図7のDTDに合致するドキュメントは、外側の<container>要素を持っているが、それは既知の型のパッケージの、一つかそれ以上の要素を包含していなければならない。パッケージは他のコンテナ、indirectパッケージやmd-setでもありうる。md-setはパラメタ実体であり、固有のDTDをもつパッケージが収容されなければならないときに、その定義を用意に変更することができる。パッケージ型のリストはまた、似たような理由で、パラメタ実体としても定義される。
 

<!--  Warwick Framework DTD -->
<!-- Override this entity definition to add other metadata packages
     that follow their own DTDs. -->
<!ENTITY % md-set 'DublinCore | package'>

<!-- Override this entity to add other notations for non-SGML data. -->
<!ENTITY % notations 'SGML | USMARC | MIME | RFC-822'>
<!NOTATION SGML    SYSTEM "" -- Default value for package notation -->
<!NOTATION USMARC  SYSTEM "" -- Some known encoding of US MARC -->
<!NOTATION MIME    SYSTEM "" -- An IETF MIME message -- >
<!NOTATION RFC-822 SYSTEM "" -- Simple attribute: value pairs -->

<!ENTITY % PackageTypes  'container | indirect | %md-set'>

<!ELEMENT  container - - (%PackageTypes)+>
<!ATTLIST  container
  Name     CDATA  #REQUIRED  -- Name of container schema --
  Schema   CDATA  #IMPLIED   -- URI for container schema def.--
  Version  CDATA  #IMPLIED   -- Version of the package schema -->

<!-- The <indirect> element refers to packages of metadata held
     externally. The URI attribute specifies the remote package.
-->
<!ELEMENT indirect  - O EMPTY>
<!ATTLIST indirect
  URI      CDATA  #REQUIRED -- The reference to the data --
  Name     CDATA  #IMPLIED  -- Name of ext. package schema --
  Version  CDATA  #IMPLIED  -- Version of the package schema -->

<!-- The MD-SET parameter entity should be overridden when people
     wish to add packages with known DTDs. For now it mentions DublinCore
     and Package. DublinCore has its own DTD, but for this example we
     take the easy way out by declaring its content as #PCDATA.
     The NOTATION attribute allows the Package element to include a
     metadata package that is in a non-SGML format. If people do not
     want to follw a package-specific DTD, they may use the metadata
     and metagrou elements inside a package.
-->

<!ELEMENT DublinCore - - (#PCDATA) -- deal w/ this later -->
<!ELEMENT package  - - (#PCDATA | metadata | metagroup)+ >
<!ATTLIST package
  Name     CDATA                 #REQUIRED -- Name of package schema --
  Schema   CDATA                 #IMPLIED  -- URI of schema definition --
  Version  CDATA                 #IMPLIED  -- Version of package schema --
  Notation NOTATION (%notations) SGML      -- non-SGML formats allowed,
                                              but SGML is the default -->
<!ELEMENT metagroup - - (metadata | metagroup)+ >
<!ATTLIST metagroup
    Name   CDATA  #Required  -- Name of the metadata grouping --
    Type   CDATA  #IMPLIED   -- Categorization of metadata --
    Scheme CDATA  #IMPLIED   -- Reference to controlled vocabulary -->
<!ELEMENT metadata - - (#PCDATA) >
<!ATTLIST metadata
    Name   CDATA  #Required  -- Name of the metadata field --
    Type   CDATA  #IMPLIED   -- Categorization of metadata --
    Scheme CDATA  #IMPLIED   -- Reference to controlled vocabulary -->

図7 - Warwick Framework DTD
 

<container>要素および<package>要素は、同一の属性リストを持っており、それによってパッケージの名前、バージョンおよびURIを特定し、パッケージの型に関する更なる情報を引き出すことが可能になる。<indirect>パッケージ要素は、URI属性が、どのパッケージデータを引き出すのかを特定するという点で、若干異なる。われわれが解決しなければならない問題は、どのくらいの情報が、インダイレクトパッケージに関して供給されねばならないか、ということである。われわれはそのデータ型を提示するべきなのだろうか。

図7のDTDにおいては、<DublinCore>要素はテキストを保存しておくためにだけ定義されていることに注意すること。これによって、例はより簡潔になるが、現実にはDTDを現在開発中のDublinCoreのために使用することになるだろう。

Warwick DTDの使用例を、図8に示す。
 

<!DOCTYPE container system "warwick.dtd">
<container name="example">
<indirect uri="http://foo.bar.com/huh">
<package name="admin">
<metadata Name="date-created">12/31/95</metadata>
<metadata Name="last-revised">4/5/96</metadata>
</package>
<DublinCore>
  For this example, just some text. A DTD for Dublin
  core is being developed, and the content here should conform
  to it in real use.
</DublinCore>
<package name="misc" notation="RFC-822">
From: daniel@acl.lanl.gov (Ron Daniel)
Subject: Metadata tagging schemes
</package>
</container>

図8 - SGMLに符合化されたWarwick Frameworkコンテナ
 
 

9.4　分散オブジェクトによる実装

Warwick Frameworkのオブジェクト指向の実装は、いくつかの理由で適当である。
  分散オブジェクト技術はオブジェクトの抽象性を、オブジェクトへの非局所的アクセスを可能にすることで拡大する --- オブジェクトのクライアントは、オブジェクトの実際の実装を含むサーバとは別のアドレス空間内や別の端末上に存在するかもしれない。分散オブジェクトの実装の例としては、Object Management Group（註21）のCORBA（註22）仕様、ILU（註23）（CORBAと似たXeroxによる実装）そしてMicrosoftによって提案されているOLE（註24）へのDCOM拡張がある。

これらの実装は、それぞれ拡張可能なセキュリティ枠組みを提案し、またはその予備的実装を行なっており、これによって実装者やサーバ管理者はオブジェクトへのアクセスやオブジェクト内での方法を制御することができる。このことは、特に、Warwick Frameworkの実装と関連し、特に、実際上は、知的コンテンツへのアクセスが、認可された者に、およびオブジェクトに関連した利用条件（メタデータなど）の下に限定されなければいけないという、情報通信の基盤構造と関連している。

CORBAの仕様は、いくつかの高次のサービスについての提案を含んでいる。そのうち二つはこの文書で説明されたメタデータとコンテンツの問題に関連する。インタフェースレポジトリ（註25）サービスは、プロバイダが新しいオブジェクト型を登録することを可能にする。クライアントは、それらの型にアクセスするためにレジストリの情報を用いることができる。動的呼び出しインタフェース（註26）サービスは、クライアントがそれらの新しい型のために定義された操作へのメソッド呼び出しを収集することを可能にする。

ただし、Warwick Frameworkの分散オブジェクト実装は、現存するものとはかなり異なる情報通信基盤構造を前提としていることを断っておかねばならない。そのような基盤構造を構築するいくつかの試みは現在進行中である。その試みの中には例えば、Stanford Universityの電子図書館プロジェクト（註27）や、1996年6月にW3CとOMGが合同で行ったW3C/OMG Workshop on Distributed Objects and Mobile Code（註28）のようなものがある。

図9は、オブジェクト指向のWarwick Frameworkの実装のための型の階層構造を示している。


figure 9
図9 - メタデータのための型の階層構造
 

この型の階層構造におけるメタデータのクラスは次の通りである。
 

The Kahn/Wilensky Framework（註29）は、DARPAの資金提供によって行われたComputer Science Technical Reports Project（註30）の成果の一つであるが、Warwick Frameworkにおけるオブジェクト実装がその中に当てはまる分散情報通信基盤を提案している。Kahn/Wilensky Frameworkとは、簡潔にまとめるとおよそ次のようなものである。すなわち、枠組みが提案している情報通信基盤とは、情報の保管、記憶、配布、管理をデジタル形式で支援するオープンアーキテクチャだということである。そのシステム内部において、情報は、デジタルオブジェクト、つまり、知的コンテンツをカプセル化するコンテンツ非依存なパッケージや、オブジェクトのデータ、およびその他に関連するもの（すなわち、この文書の主題である目メタデータ）という形式で記憶される。このような情報通信基盤の重要な側面は、デジタルオブジェクトのレベルにおけるコンテンツ非依存の問題と、データのレベルでのコンテンツ依存的な問題を、厳格に区別したところにある。 
図10 - MetaDataSetのための型の階層構造
 

The Kahn/Wilensky文書は、デジタルオブジェクトと結びついたメタデータについての定義を厳密にしているわけではないが、情報通信基盤にとって欠かせない二つの型のメタデータについて記述している。
 

デジタルオブジェクトは、レポジトリにおいて論理的に記憶される。KahnとWilenskyは、基本的なRepository Access Protocol (RAP)の機能を、以下のような下位レベルでの操作をもって記述している。 レポジトリは、そのレポジトリおよび操作の対象となるデジタルオブジェクトのために定義された利用条件にもとづいた操作にアクセスを制限する重要な役割を担っている。

Kahn/Wilenskyの研究に続くものとしては、Cornell Digital Library Research Group（註32）やCNRI、NCSAなどの研究者が、Kahn/Wilensky Frameworkを実装する際の問題について検討し（註33）、また、その枠組みにおける分散オブジェクトを実装するための設計を作成している（註34）。後者の論文は、さらに分散オブジェクトの実装において利用条件を強制することに関連した問題についても検討している。

ILUを用いた分散オブジェクトの実装についての研究は、現在Cornell大学において進められている。この研究は、Warwick Frameworkの概念をKahn/Wilensky Frameworkに統合するものである。そこでの実装においては、デジタルオブジェクトは三つの型のオブジェクトにわけて考えられる。

  1. URN - デジタルオブジェクトの一意的識別子。
  2. MetaDataContainer - デジタルオブジェクトのコンテンツのためのメタデータコンテナ（これは前述した意味で、「内部的に参照される」）。MetaDataContainerはMetaDataPackage型のオブジェクトの連鎖である。Warwick Frameworkのコンテナのセマンティクスは完全にサポートされている。
  3. ContentContainer - このデジタルオブジェクトにおける一連のコンテンツ。これは、ContentElementの型のオブジェクトの連鎖である。個々のContentElementはそれぞれMetaDataContainerおよびContentPackageのオブジェクトを含む。ContentPackageとは、MetaDataPackageのクラス階層構造に合致するクラス階層構造にとっての原初的上位型である。つまり、ContentPackageは“真の”コンテンツ（例　PostScript、GIF画像、Javaのアプレット）や、他のデジタルオブジェクトへの間接的参照や、他のContentContainerへの再帰的参照にとっての下位型であり得るということである。
一つのデジタルオブジェクトの中に、二つのメタデータコンテナの集合が含まれるということには注意しておく必要がある。そのうちの一つは、オブジェクトのレベルのものであって、全体としてそのデジタルオブジェクトに関連するメタデータを保持しておくものである。他方は、個々のコンテンツ要素に添付されるものであり、特定のコンテンツに関連したメタデータを保持しておくものである。デジタルオブジェクトのデータ構造を、図11に示す。

figure 11
図11 - Warwick Frameworkのコンテナを含むデジタルオブジェクト
 

この図では説明していないが、クラス階層構造のもう一つの特徴として、次のことを追加しておく。それは、メタデータとデータの区別は、ある“コンテンツ”がどのようにしてデジタルオブジェクトの中に収められたかについての恣意的なものだということである。MetaDataContainerとContentContainerは両方とも、“コンテンツ”をその末節にもった階層構造の集合体なのである。例えばMARCレコードなどといったコンテンツの型は、あるデジタルオブジェクトのMetaDataContainerに由来するものとしても、または他のオブジェクトのContentContainerに由来するものとしても存在しうるのである。このことは、本当のところ何がメタデータで何がデータかを分かつ絶対的な境界はなく、両者の区別は、使用される文脈によるのだという、われわれの今まで行ってきた考察とも矛盾しない。

まとめていうと、このデジタルオブジェクトのデザインは、第一級（名前のついた）オブジェクトの範囲の中での、メタデータとコンテンツの恣意的な集合体を許容している。集合体の個々の要素自体が、独立した管理、記述的データ、そしてアクセスのためのルールを備えた第一級のオブジェクトになり得るということである。
 

10.　謝辞

メタデータ研究会の主催者、特にこの研究ならびに関連する研究にとって欠かせなかったフォーラムの実施に多大な努力を注いだS. Weibelに感謝したい。 ここで述べられたアイデアは、Warwick研究会における議論の結果にその多くを依っている。また、C. Lynch、A. Michaelson、C. PrestonおよびC. Summerhillらによってthe Coalition for Networked Informationのために準備され、現在まだ完成していない「ネット上の情報検索および取得に関する白書（the White Paper on Networked Information Discovery and Retrieval）」における議論もここに反映されている。この文章で示されたHTML、MIME、SGMLの実装案についての広範にわたる研究を担当したE. Miller、J. Knight、M.Tomlinson、L. Burnard、C.M. Sperberg-McQueen、およびL. Quinにも謝意を表する。最後に、編集の労をとってくれたCornell大のJ. DavisとM. Curtinに感謝したい。
 
 

註

［目次に戻る］ ［附属資料B.に移る］