この標準情報(TR)は, 1997年度の電子商取引消費者インタフェース調査研究をもとに, 英国Warwickで1996年4月に行われた第2回メタデータ研究会の報告を翻訳し, 規定部分を抽出して標準情報(TR)の様式にまとめ, 標準情報(TR)タイプIIとして公表するものである。
Warwick Frameworkと呼ぶコンテナ・アーキテクチャを規定する。この枠組は, 異なるメタデータのパッケージを, 論理的に（特定のデータ構造の利用を通して）具体的に集めるメカニズムであって, メタデータの問題をいくつかのモジュールに分解する。 この枠組は, 次に示す顕著な特徴をもつ。
次の規格及び標準情報(TR)に含まれる規定内容は, この標準情報(TR)の文中での引用によって, この標準情報(TR)の規定となる。表示された版は, この標準情報(TR)の出版の際に有効であったものである。
TBD
完成度の高いAnglo-American分類規則（AACR2）とMARC交換フォーマット（そ の数多くのバリエーションも含む）は既存のすべての電子図書館システムの基礎になって おり, 非常に多くの種類の内容を記述する創造性と符号化の点で効率が良いことが証明さ れている。しかしながら, 非常に複雑な規則は円滑に適応を行なうための熟練した分類担 当者を必要とする。また, MARCレコードの隠された構造は複雑で, 記録と交換のための特 別なシステムを必要とする。Dublin Coreのような単純化された記述的規則では, 大半の著作者にとって簡便であるが, 図書館 の分類の特徴である検索精度, 類別区分や系統化についてはそこまでの段階にいたってい ない。"Computer Science Technical Reports"などの計画によれば, 簡潔な記述的規則は, ごく普 通のテキストエディタによってさえ作られ得る簡単な交換フォーマットと合わせることで , 訓練されていない著作者や編集スタッフにも, 記述的な記録を充分なレベルで作ること を可能にすることが証明されているという。Dublin Coreはこの経験に基づいて設計されたものである。最終的には, Federal Geographic Data Committee（FGDC）の成果である"Content Standard for Degital Geospatial Metadata（CSDGM）フォーマット"のような, ドメイン特化のフォー マットや, 数学ソフトウェアパッケージを表記するためのスキーム, または保健科学にお ける類別区分と表記のためのスキームが存在することになる。これらのスキームはかなり の程度の記述的な分類を含み, そしてMARCやAACR2よりも複雑なものであるならば, 特定 の利用者の共同体や特定のソフトウェア環境（ともに記録も検索も）の複雑なデータ群を 正確に表記するために, 補完的な存在としてではなく, 提供されることになる。
しかし, 実際の世界で応用するには記述的な分類よりもより広い範囲のメタデータを 使用する必要性がある。すべてを網羅していることはないと断りをつけた上で, この範囲 の意味を提供する他のメタデータの種類を以下に列挙する。
異なるメタデータ集合についての異なる起源や管理は, 非常に多様なシンタクスと記 法をもたらす。たとえば記述的分類データなど, いくつかの型のメタデータでは, 静的な テキスト表現で必要が満たされる。他の種類のメタデータは, 実行可能な（または解釈可 能な）プログラムのような, より強力な方法によってのみ表現される。これは特に, クラ イアントとエージェント, 外部サービス（認証サービスや支払いサービス）の間での交渉 を明確化するような, 利用条件を符号化するようなメタデータに該当する。
メタデータ集合への間接的参照はメタデータ集合の共有によって協力しておこなわれ
る。たとえば, 多くのコンテンツオブジェクトをともなったレポジトリを仮定したときに
, それらのうちの数多くが同じアクセスのための利用条件をもっている（たとえば定期刊
行物の集合のためのサイトライセンスをともなった大学電子図書館など）。われわれはこ
のことを, 名前の参照を使い, オブジェクトの集合を利用条件を符号化したものにリンク
させることで表現できるはずである。したがって, われわれは, その共有された符号化を
変更することによって, オブジェクト集合のための利用条件を修正することができなけれ
ばならない。共有された利用条件メタデータは, 逆に知的財産管理を専門にする外部提供
者によって管理されるレポジトリの中に存在することもある。
Warwick研究会における, これまでに述べた分析の結果として生まれたものが, 複数のメ タデータ集合を総合化するためのアーキテクチャ, すなわちWarwick Frameworkである。Warwick Frameworkの基本的な構成要素は二つある。ひとつは型付けら れたメタデータ集合, すなわち"パッケージ"であり, もうひとつはパッケージを総合化 するための単位, すなわち"コンテナ"である。
コンテナは一時的でもあり, 永続的でもある。一時的な形式においては, コンテナは レポジトリとクライアント, エージェント間の交換オブジェクトとして存在する。永続的 な形式では, 情報通信基盤の第一級オブジェクトとして存在する。つまりコンテナはひと つ以上のサーバに貯められ, それらのサーバからグローバルなアクセス識別子（URI）を 使ってアクセスすることができる。コンテナが他のオブジェクト内でもラップされること がある（つまりあるオブジェクトがデータとメタデータ双方のラッパーになっている）こ とには留意する必要がある（これは後に提案されている分散オブジェクト実装の部分で示 される）。この場合, ラップするオブジェクトは, メタデータコンテナそのものでなく, またはそれに加えて, URIをもつ。
実装から独立して定義されたコンテナの唯一の操作は, コンテナ中のパッケージの連 鎖を返す操作である。この連鎖の成員を順序立てるための規定は, この操作にはない。そ のため, クライアントが, あるパッケージが, 他のパッケージよりも重要なのか, よいの かを想定する方法はない。
コンテナレベルでは, パッケージは不透明なビットのストリームである。これらの特 性から示されることの一つは, コンテナのためのどのような符号化（交換シンタクス）で あっても, コンテナの受容者が, コンテナ内の未知のパッケージをスキップできるという ことである（換言すれば, パッケージの大きさはコンテナレベルで自己で記述していなけ ればならないことになる）。この特性は, 個々のパッケージの内容が暗号化され, 特定の 集合へのアクセスを必要としない, 又はそのようなアクセスを入手する（つまり, 購 入する）必要がある, メタデータの搬送をシステム間で許容する。この文書で後に提案さ れるHTMLの例のように, これらの含意は, コンテナの抽象的な特性を充分に主張するだけ の力を欠いている。
パッケージは型付けられたオブジェクトである。パッケージの型はクライアントとエ ージェントによるアクセスのあとで決定されるもので, 次の三つの種類がある。
コンテンツオブジェクト（つまり文書）をWarwick Frameworkコンテナに関連づけるた めの機構は, Warwick Frameworkの実装に依存する。この文書で提案される実装については後述されるが, そこ にはいくつかの選択肢が挙げられている。たとえば, 単純なWarwick Frameworkコンテナは, HTML実装提案で示されているように, 文書内に埋め込むことがで きる。または, HTML文書は別のファイルとして記憶されたコンテナにリンクを張ることが できる。一方では, 分散オブジェクトに関する提案で示されたように, コンテナは, ネッ トワーク化されたオブジェクトを表すデータ構造ともいえる, いわゆるデジタルオブジェ クトの論理的な部品として存在する可能性もある。
コンテナを知的コンテンツの部分と結び付ける, 逆のリンケ付けも関連する。実際,
情報源の所有者や管理者の許可もなく, 彼らに知らせることもなく, 誰でもネットワーク
情報ソースのために記述的なデータをつくりだすことができる。このメタデータは, 本質
的に, ある情報ソースの所有者がその情報ソースからリンクを張るメタデータや, オブェ
クト内に埋め込むメタデータとは異なるものである。そのため, われわれは同じ実装の手
法を用いるとしても, 非公式ながら二つのカテゴリのメタデータコンテナに分けなければ
ならない。
図3はコンテンツとメタデータの関係を示したものである。三つのメタデータコンテナ が描かれており, ひとつは内部から参照されるメタデータコンテナで, コンテンツオブジ ェクトに埋め込まれている（URIをもたない。またコンテンツへの参照のためのリンク付 けパッケージも存在しない）。二つの外部から参照されるメタデータコンテナは独立のオ ブジェクトである。これらはURIをもち, URIを通じてコンテンツオブジェクトを参照する 。
内部から参照されるメタデータコンテナは, この図では間接的にコンテンツによって
参照されることも可能である。この場合には, 独自のURI（URI4と呼んでおく）をもち, U
RI3（コンテンツ）を参照するリンク付けパッケージが存在する。
もしも初期の実装が, 現存するWWWのソフトウェアに何の修正も要求しないのでなければ , Warwick Frameworkの素早い普及はみられないだろう。このセクションでは, HTML 2.0に適合したW arwick Frameworkの実装について説明するが, これは, 現存するブラウザや検索エンジン, HTML オーサリングツールで使用可能である。OCLCのEric Millerがこの実装の最初の提案者である。この提案は, 1996年5月に行われたW3C が資金提供したDistributed Indexing/Searching Workshopにおいてなされた。後に述べるシンタクスは, メ タデータ集合への間接的参照に対する対応を視野にいれつつ, 研究会においてなされたこ の提案を拡張したものである。
この実装はHTML2.0の二つのタグを使用する。
<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">
<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とは全く異なる情報通信基盤を
想定したものである。
既に述べたように, そもそもMIMEは電子メールメッセージに様々な内容を入れることを可
能にするために作られた標準（RFC-1522他）の集合である。RFC-822のような初期の標準
は, メールヘッダの標準化を扱ったが, メールのメッセージ自体の構造については扱わな
かった。MIMEは, メッセージの構造を, バイナリデータと複数の構成要素または添付ファ
イルをメッセージに含むことができるものとした。これらの能力は, Warwick
Frameworkのコンテナ／パッケージアーキテクチャの実装に用いることができる。このセ
クションでは, MIMEの概要を簡単に説明し, その後, Warwick
Frameworkにおけるパッケージの三つの型（コンテナ, インダイレクト, メタデータ集合
）がMIMEの構成によってどのように表されるかについて言及する。MIMEによるWarwick
Frameworkの実装についてのより詳しい報告は, Jon KnightとMartin Tomlinsonによって
現在準備中である。
multipart型は, 複数の構成要素を含むメッセージに使用されるが, それぞれの構成要 素は異なる型を持ちうる。multipartメッセージの一般的な例はスプレッドシートやグラ フィックなどを添付されたASCII電子メールメッセージである。multipartメッセージはbo dyパートより構成されるが, その境界は, 境界文字列によって示される。bodyパートは, それぞれ関連するcontent-typeを持つ。multipartメッセージは入り組んだmutlipart bodyパートを含むこともあり得る。
multipart型の下位型はいくつかある。
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パッケージへの間接的参照
前述したとおり, SGMLは, 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をもつパッケージを含むことができなければならない。例えば, Warw ick研究会の成果のうちの一つとして準備されている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 &
nbsp;
#REQUIRED -- Name of package schema --
Schema CDATA
;
#IMPLIED -- URI of schema definition --
Version CDATA &nbs
p;
#IMPLIED -- Version of package schema --
Notation NOTATION (%notations) SGML
-- non-SGML formats allowed,
&n
bsp; &nbs
p;
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コンテナ
Warwick Frameworkのオブジェクト指向の実装は, いくつかの理由で適当である。
これらの実装は, それぞれ拡張可能なセキュリティ枠組みを提案し, またはその予備 的実装を行なっており, これによって実装者やサーバ管理者はオブジェクトへのアクセス やオブジェクト内での方法を制御することができる。このことは, 特に, Warwick Frameworkの実装と関連し, 特に, 実際上は, 知的コンテンツへのアクセスが, 認可され た者に, 及びオブジェクトに関連した利用条件（メタデータなど）の下に限定されなけ ればいけないという, 情報通信の基盤構造と関連している。
CORBAの仕様は, いくつかの高次のサービスについての提案を含んでいる。そのうち二 つはこの文書で説明されたメタデータとコンテンツの問題に関連する。インタフェースレ ポジトリサービスは, プロバイダが新しいオブジェクト型を登録することを可能 にする。クライアントは, それらの型にアクセスするためにレジストリの情報を用いるこ とができる。動的呼び出しインタフェースサービスは, クライアントがそれらの 新しい型のために定義された操作へのメソッド呼び出しを収集することを可能にする。
ただし, Warwick Frameworkの分散オブジェクト実装は, 現存するものとはかなり異な る情報通信基盤構造を前提としていることを断っておかねばならない。そのような基盤構 造を構築するいくつかの試みは現在進行中である。その試みの中には例えば, Stanford Universityの電子図書館プロジェクトや, 1996年6月にW3CとOMGが合同で行ったW 3C/OMG Workshop on Distributed Objects and Mobile Codeのようなものがある。
図9は, オブジェクト指向のWarwick Frameworkの実装のための型の階層構造を示して
いる。
この型の階層構造におけるメタデータのクラスは次の通りである。
The Kahn/Wilensky文書は, デジタルオブジェクトと結びついたメタデータについての
定義を厳密にしているわけではないが, 情報通信基盤にとって欠かせない二つの型のメタ
データについて記述している。
Kahn/Wilenskyの研究に続くものとしては, Cornell Digital Library Research GroupやCNRI, NCSAなどの研究者が, Kahn/Wilensky Frameworkを実装する際の問 題について検討し, また, その枠組みにおける分散オブジェクトを実装するため の設計を作成している。後者の論文は, さらに分散オブジェクトの実装において 利用条件を強制することに関連した問題についても検討している。
ILUを用いた分散オブジェクトの実装についての研究は, 現在Cornell大学において進 められている。この研究は, Warwick Frameworkの概念をKahn/Wilensky Frameworkに統合するものである。そこでの実装におい ては, デジタルオブジェクトは三つの型のオブジェクトにわけて考えられる。
この図では説明していないが, クラス階層構造のもう一つの特徴として, 次のことを 追加しておく。それは, メタデータとデータの区別は, ある“コンテンツ”がどのように してデジタルオブジェクトの中に収められたかについての恣意的なものだということであ る。MetaDataContainerとContentContainerは両方とも, “コンテンツ”をその末節にも った階層構造の集合体なのである。例えばMARCレコードなどといったコンテンツの型は, あるデジタルオブジェクトのMetaDataContainerに由来するものとしても, または他のオ ブジェクトのContentContainerに由来するものとしても存在しうるのである。このことは , 本当のところ何がメタデータで何がデータかを分かつ絶対的な境界はなく, 両者の区別 は, 使用される文脈によるのだという, われわれの今まで行ってきた考察とも矛盾しない 。
まとめていうと, このデジタルオブジェクトのデザインは, 第一級（名前のついた）
オブジェクトの範囲の中での, メタデータとコンテンツの恣意的な集合体を許容している
。集合体の個々の要素自体が, 独立した管理, 記述的データ, そしてアクセスのためのル
ールを備えた第一級のオブジェクトになり得るということである。
Dublin Coreに関する詳細に関心のある読者の方は完全版のDublin Workshop Reportを読まれることを勧める。このセクションは, Dublinでのメタデータ研究会で定義され たDublin Coreメタデータ集合の要約を目的としている。この文章の残りの部分の文脈はそれによっ ている。
読者は, Dublin Coreを理解するには用語法上の問題があることに注意されたい。Warw ick研究会の作業の一つは, Dublin Coreをここで述べるより大きな文脈の中で検証するとともに, Dublin Coreそれ自体を再 評価することであった。研究会報告の中には, Warwickでの会合の成果としてのDublin Coreの定義に対する変化と改善について議論がなされるものも含まれている。さらには, この論文で後ほど言及する未解決の問題は, Dublin Coreの定義の中での潜在的な変化の追加的領域を指し示している。このセクションと次の セクションの焦点は, Warwickでの会合に先行して存在していたものとして, Dublin Coreの状況を記述・評価することである。
Dublin Coreの目的は, ドキュメントライクなネットワークオブジェクトの記述及び 自動化されたインデックス作成を容易にする, 記述的要素の最小限度の集合を提供するこ とである。加えて, Dublin Coreは, インターネットに情報を提供してくれる作者や形式的な出版者のかなりの部分が 理解し, 利用するのに充分な程度に簡単であることが意味されている。先ほど述べたよう に, もともとのDublin Coreの提案は意図的にシンタクスの問題を避けたのである。
Dublin Coreの13の要素が図1に示されている。
これらのデータ要素を列挙することに加えて, Dublin研究会報告は中核をなすメタデ ータ集合全体に適用される数多くの基底となる原理を明確にしている。
・コア・メタデータ集合はサイト特有又はドメイン特有の追加的データ要素の包 含を認めるために, 拡張可能である。
・コア・メタデータ集合のすべての要素は, コアを利用するオブジェクトのどの特定 の記述においてもオプションである。この理由は二つある。一つは, コアの要素の中には ある一定のドキュメントに対してのみ意味を持つものがあるということである。たとえば , coverageフィールドは主に空間的なリソースに対し有用である。第二は, 不完全な記述 はどうしても, 確実に, Dublin Coreが扱うことを意図されたこれらの使用法のシナリオの下にあるということである。つ まり, プロの分類者やインデックス作成者というよりも, 作者やサイトの管理者, プロで ない出版者や情報提供者によるドキュメントの記述のことである。
1995年のDublinメタデータ研究会の成果は, 記述的メタデータ集合の完全な定義ではなく , 中核をなす記述的メタデータ集合へ向けての最初の一歩となることを目指していた。Wa rwick研究会において前進するためには, Dublin Coreの定義の評価と実装のためのプラットフォームを提供するのに必要な作業を決定する ことが必要となった。このセクションではその評価についての要約を述べる。ここで述べ られている問題の中には, Warwick Frameworkによって扱われたものもある。また, Dublin Coreの要素のためのシンタクスや 著者のためのガイドラインといった問題は, Warwick研究会から生まれた他の文書で扱わ れている。将来の作業のために残っているのはあまりないといってもよいだろう。
ここでなされている批判の多くが実際上の意味においては不公平であると認めること
は重要である。Dublin研究会は, 充分に定義された最終的な生産物を作ることではなく,
むしろ最終的な生産物の究極的な定義に向けて発展し, コンセンサスを築くことを, 意図
的にその目的としている。
このことは, Dublin Core自体の批判というよりも, むしろ作者から提供される記述的
メタデータの要素を含む実装シナリオを発展させる際の問題認識であると認識することが
重要である。著述やネットワーク"出版"の一部としてこのような情報をつくりだすこと
を促進することは発展への鍵である。Warwickでの会合の主な焦点は, 作者や管理者がDub
lin
Coreのデータの要素を提供できるようにするための実践的メカニズムの発展であった。
加えて, 限られたコンテクストにおけるDublin Coreの使用は非常に有用な結果を作っ
たかもしれない。たとえば, 保全性の高いサイトの集合を想定してみよう。そのようなサ
イトの管理者は, 相対的に統制のとれた語彙と規則的なシンタクスを含んだ非常に特定化
された実践の集合を利用して, こういったサイトのドキュメントをDublin
Coreのメタデータ要素を用いてタグ付けするかもしれない。このような 保全性の高いサ
イトを通しての情報検索効果は, おそらくLycosやAlta
Vistaを通して現在利用可能な構造化されていない検索に比べて（メタデータを利用する
情報の獲得・検索のツールを想定すれば）非常によいものとなるであろう。
われわれは, これらのサイトが有料で検索サービスプロバイダを記載し, ユーザが検索を
このようなサイトに限って行なうことが可能となるような市場構造を想像することができ
るのである。
1995年のDublinメタデータ研究会の主催者たちは, 研究会の報告書にも"情報源の記述問 題の大きさと複雑さを避けて"とあるように, 意図的にその範囲を狭めていた。この制限 は研究会において何らかの具体的な成果を出すためには不可欠であると思われた。
Warwick研究会の初日が終わるまでには, この"制限を設けるという"戦略が以前に達 成されてきたものを越えるには障害であることが明らかになった。三つの問題が表面化し , それぞれわれわれの視野を広げる必要性を明確にした。
われわれは, コアメタデータ要素から焦点を外し, メタデータの一般的な原則を検討
することで, これらの問題にこたえることができる。
Warwick研究会における時間的な制約により, 提案されたフレームワークの全ての問題を 十全に解決することはできなかった。フレームワークを仕上げる前により細かな拡大され た考察を緊急に要するいくつかの項目がある。当然, Warwick Frameworkにおける最も根本的な問題は, コンテナの中で起こりうる, 多くのメタデータ 集合の間のセマンティクスの相互作用とオーバーラップである。パッケージはそれぞれあ る程度論理的に区別できるが, それらはいくつかの仕方でオーバーラップする可能性のあ るセマンティクスを持つ。
このオーバーラップは様々なレベルで起こりうる。まず, 一つのコンテナ内の二つの メタデータ集合の間で起こりうるセマンティクスの水平的なオーバーラップがある。その 一例は, 二つの記述的分類レコードを持つコンテナであり, 一つがMARC, もう一つがDubl in Coreである場合。また, 一方がコンテナの中にあり, 一方がそのコンテナに由来する任意 の再帰レベルにある二つのメタデータ集合の間に起こるセマンティクスの垂直的なオーバ ーラップの可能性もある（コンテナは別のコンテナを含んだり, 間接的に他のコンテナを 参照することがある）。一例は, オブジェクトの構造を下るに従って多様な利用条件を持 つ複雑なオブジェクトである。ここでの問題は, 複合的オブジェクトの中のパッケージに 含まれるメタデータがそれに当てはまるであろう, 一つまたは複数のオブジェクトの範囲 である。
最後に, オブジェクトに関連したメタデータのセマンティクスはメタデータの"消費 者"によって理解される必要がある。つまり, オブジェクトにアクセスするクライアント やエージェント, そしてこれらのクライアントやエージェントを形成するユーザーである 。われわれはWarwick Frameworkの完全な表現をする際に, メタデータを使いものにならないほどに複雑なもの にしてしまうという危険を冒している。適当なバランスを見つけることはデザインの中心 的問題である。
例えば, 普通のメタデータの消費者 --- 記述的データやネットワーク化されたオブジ ェクトを集めてそれを検索可能な目次に編集しようとする検索エンジンのことを考えると よい。このエージェントの設計は, 記述的分類のメタデータが, 関連性や一貫性なしにそ れぞれのオブジェクトごとに異なるいくつかのメタデータ集合に入っていたならば難しい だろう。この恣意的に混ぜられたメタデータから使用可能な目次をつくるルールはどうな るか？ 複数のメタデータ集合間でどのようなセマンティクスの変形が可能だろうか？
われわれは, より複雑ではないにせよ類似の問題を, オーバーラップするオブジェク トのアクセス規則や利用条件を説明するメタデータに見出すことができる。マルチメディ ア文書のような複雑なオブジェクトへのクライアントアクセスの際には, いくつかの利用 条件を文書の複数のレベルで交渉する必要があるかもしれない（ある利用条件をテキスト のある節に, 他の利用条件ををフルモーションビデオの一部分, というように）。しかし まず第一に, クライアントに関係があるのは, オブジェクトがアクセス可能かどうか, そ してどれだけのコストがかかるかということである。これは, 特にコンテナ間の恣意的に 深い再帰や循環参照の可能性を考えると計算は困難である。われわれは, オブジェクトを クライアントやエージェントにアクセスできるように強く促す市場の力が, この性質の最 も複雑な問題を回避すると考える。
Warwick研究会で表面的にしか議論されなかった提案が, Dublin Coreの関係性要素を 外部化・一般化する関係性メタデータパッケージを開発することの可能性であった。もし この方法が採用されれば, 改訂Dublin Coreからは関係性要素は取り除かれ, 複合オブジェクトについての曖昧さの一因が消える ことになる。しかし, Dublin Coreだけでなく多くのメタデータ計画が, 関係性や階層構造の概念を含むため, これは問 題を完全には解決しない。
この根本的な問題に加えて, Warwick Frameworkを実装する上で検討が必要ないくつか
の実装の問題を次に掲げる。
後述するように, 新しいメタデータ集合や既存の集合のバリエーションが現われるこ とにそなえて, 型システムは拡張可能でなければならない。既存のクライアントやブラウ ザはこの新しい型をどのように扱うのだろうか？ 最も単純な解決法は, 新しいメタデータ型が現れるたびに既存のソフトウェアがアップグ レードされるべきである, というものである。そのアップグレードが行なわれるまでは, コンテナ構造は少なくとも, ソフトウェアが新しい未知のパッケージ型を飛ばし, ユーザ にそのことを伝えることを許可するものになっていなければならない。このような解決法 は新しい型がしばしば現れると対応できない。よりよい解決は, ネットワークを基にした ソフトウェアによって問い合わせ可能な型レジストリサービスである。このサービスは, クライアントにそれ自身を新しい型を処理できるように再設定することや, 新しい型を処 理するためにネットワークでアクセスできるアプレットまたはヘルパーアプリケーション のダウンロードを可能にする情報を提供することができる。
しかし, この方法にも限界は存在するが, 十分理解されていない。型のシステムは処 理アプリケーションに, 新しい型のある種の意味を伝達する必要がある。これは, アプリ ケーションにまず, その新しい型を知らないことが果たして問題なのかどうかを最初に判 断することを可能にするかもしれない。この回答に基づいて, アプリケーションは機能拡 張やヘルパーアプリケーションをダウンロードする必要があるかを判断することができる 。例えば, 現在のブラウザは起源についての情報を処理しないし, 多くのユーザは起源に ついて理解しも気にもしない。
階層構造や, もしかしたらある種の継承が, 型システムに必要かどうかの問題もある
。例えば, われわれは, 権利と許可のメタデータについての一般的なクラスが, このメタ
データの型に使われている多様な"方言", 及び転送シンタクスならびに表現を理解す
ることを望むだろうか。
データ符号化に関するより困難な問題はパッケージのレベルにある。ここにはただ一 つの正解は存在しない。いくつかのメタデータ集合はASCII文字で属性と値の組として適 切に表現されうる。他のメタデータ集合のデザイナはSGML, HTML, ASN.1といった他の構 造を好むかもしれない。このシンタクスに含まれるフィールドは, 単なる文字列や整数よ りも遥かに複雑かもしれない。例えば, オブジェクトへアクセスするための利用条件を説 明したルールを考えるとよい。最も単純な場合には, このルールはオペレーティングシス テムの世界でよく確立されているようなアクセス制御リストによって表現されるだろう。 しかしながら, デジタル分野における現在の法律とビジネスの枠組みの完全な表現の為に は, 交渉, 挑戦と応答, 第三者サービス（支払いサービス, 認証サービスなど）との相互 作用などに対応するルールも必要となる。この型の適応的・相互作用的メタデータは実行 可能なプログラムやエージェントを通じて最もよく表現される。
メタデータをそれぞれ独立したシンタクスを持つ分離したパッケージに分節化すると
いうわれわれの方法は, この問題において少なくとも進歩をもたらす。単純なクラスのメ
タデータは単純なシンタクスを使用できるし, より複雑な要求を含むクラスはより複雑で
強力なシンタクスを得ることができる。しかし, Warwick研究会を動機づけた中心的な問
題に立ち帰ると, Dublin
Coreのデータ要素それ自身のための一つ以上のシンタクスについての合意が必要である。
TBD
この標準情報(TR)原案を作成した国際大学グローバルコミュニケーションセンターの電子商取引消費者インタフェース委員会の委員構成を次に示す。
| 氏名 | 所属 | |
|---|---|---|
| (主査) | 小町 祐史 | 松下電送株式会社 |
| (幹事) | 山内 康英 | 国際大学グローバルコミュニケーションセンター |
| 大久保 彰徳 | 株式会社リコー | |
| 奥井 康弘 | 株式会社日本ユニテック | |
| 上村 圭介 | 国際大学グローバルコミュニケーションセンター | |
| 檜山 正幸 | 檜山オフィス | |
| 古瀬 幸広 | 立教大学 | |
| 堀越 裕太郎 | 通商産業省工業技術院標準部 | |
| (事務局) | 森光 裕行 | 国際大学グローバルコミュニケーションセンター |