このドキュメントは
Metadata Architecture
http://www.w3.org/DesignIssues/Metadata.html
の和訳です。
この文書には和訳上の誤りがありえます。
内容の保証はいたしかねますので、必ずW3C Webサイトの正式版文書を参照して下さい。
開始日：１９９７年１月６日
. ステータス：個人的意見，しかし，メタデータのためのW3Cアーキテクチャに広く対応する
.
末尾に， ラベル／メタセット／コレクションの構文とセマンティクスにおける整合性に関する補足を置く．
このドキュメントで使われている構文は，アーキテクチャを説明し明確にすることを意図したものであり， その他の点では正確ではない． この覚書は，より一般的な セマンティックWeb ノート 以前に書かれたものである．
このドキュメントはセマンティックWeb ロードマップよりも前に書かれたものであるが， 同じアイディアへのイントロダクションである． このドキュメントもセマンティックWeb ロードマップもともに， web上のマシンリーダブルなデータの世界を紹介する． このドキュメントは，セマンティックWebの概念をW3Cでの歴史的順序 - セマンティックWebの最初の有望なアプリケーションはメタデータであり， 最初の有望なメタデータアプリケーションはエンドースメントラベルであった - にしたがって紹介する． (PICS).
リンクをたどったりURIを下方参照した時に得られるものは， 様々な名前で呼ばれている． 正式には，私達はそれをリソースと呼ぶ． 現在のところWeb上のものの多くは人間が読むことのできるドキュメントなので， ドキュメントと呼ばれることもある． また，事実上マシンリーダブルであるか，隠蔽された状態を持っている時には， オブジェクトとも呼ばれる． 以下では，ドキュメントという言葉とリソースという言葉を区別せずに用い， 時には「オブジェクト」を使う．
World Wide Webの特徴の一つは， リソースを引き出した時に， リソースが何の説明もなく単にそれ自身で存在するのではなく， リソースに関する情報が存在することである． 情報に関する情報は一般に「メタデータ」として知られている．
| メタデータは，webリソースその他に関する，機械によって理解可能な情報である |
「機械によって理解可能」という部分が鍵である． ここで言う情報は， 私達の生活を楽にしたり， 私達が法律にしたがっていることを保証したり， 私達が行っていることが信頼できることをチェックしたり， あらゆることを円滑に迅速に進めるために， ソフトウェアエージェントが使う情報である． メタデータは，良定義された（well definedな）意味論と構造を持つ．
メタデータが「メタデータ」と呼ばれているのは， webリソースに関する情報がメタデータの始まりであり，現在でも主にそうであるからである． 将来メタデータ言語とエンジンが整備されれば， 人々や物事，概念やアイディアなどあらゆることに関する， 機械によって理解可能な情報のwebのための強力な基礎がメタデータによって形成されるであろう． 私達は，最初の一歩は情報に関する情報のためのシステムを作ることであっても， 設計の際にはこのことを念頭におくべきである．
オブジェクトがHTTPプロトコルを使って引き出される際にプロトコルが伝える， 日付や有効期限，所有者，サーバによって送られるその他の任意の情報は， メタデータの例である． したがってWorld Wide Webの世界は情報の世界であり， そのような情報の一部は情報に関する情報である． このことの首尾一貫した描像を得るためには，メタデータに関するいくつかの原理が必要である． 最初の原理は：
| メタデータはデータである |
つまり，情報に関する情報はあらゆる点で情報とみなされるべきである． これには様々な側面がある．
一つは，メタデータをデータとみなして格納できることで， メタデータはリソースの中に格納することができる． したがって， 一つのリソースが自分自身に関する情報や他のリソースに関する情報を含んでも良い． 現在のWorld Wide Webの慣習では，メタデータを得る方法は３つある． 第１は，例えばHTMLドキュメントのHEAD部分やワードプロセッサのドキュメントの中などドキュメント自身に含まれる， ドキュメントに関するデータである． 第２は，HTTP転送中にサーバがクライアントに送る，転送しているオブジェクトに関するメタデータである． これはhttp GETの中でサーバからクライアントに送られ， PUTあるいはPOSTの中でクライアントからサーバに送られる． 誰がそのステートメントを作っているか， そのメタデータが誰のステートメントで誰の特性であるかは， World Wide Webアーキテクチャの中で私達が合理的に扱わなければならないことの一つである． メタデータが見つかる第３の方法は， それが他のドキュメントの中で調べられている時である． これは， PICSイニシアティブがWorld Wide Webリソースに関する情報の表現に適したラベル形式を定義しなければならなくなるまでは一般的ではなかった． PICSアーキテクチャは， 他のリソースに関するリソースであるPICSラベルを， リソース自身の中に埋め込み， 独立したリソースとして取り出し， httpトランザクションの中で渡すことを， 明確に認める． 結論として，
| 一つのドキュメントに関するメタデータは，そのドキュメントの中や独立したドキュメントの中に存在し得る，
あるいはドキュメントに伴って転送され得る．
|
言い換えれば， メタデータはファーストクラスオブジェクトであり得る．
先の原理の第二の部分は：
| メタデータはメタデータを記述することができる |
つまり，メタデータ自身も所有者や有効期限などのような属性を持ち得るためメタ−メタデータが存在するが， 私達は多重レベルを区別しないので，単にメタデータはデータであると言う． このことから， メタデータは自身に関するほかのデータを持つ事ができる． これはWebに一定の整合性を与える．
メタデータはデータに関するアサーションから成り，そのようなアサーションは典型的には， 計算機システムで表現された時にアサーションの名前あるいは型とパラメタの集合の形式をとる． これは，自然言語では文が動詞と主語，目的語，種々の節から構成されるのと同じである．
| アーキテクチャは，独立なアサーションの集合として表現されたメタデータのためのものである |
このモデルは，一般には同一のリソースに関する２つのアサーションが孤立して独立に存在し得ることを意味する． それらを１箇所にまとめた場合，結合したアサーションは単純に独立なアサーションの和（実際には論理積）となる． したがって（論理積は可換なので）アサーションの集まりは本質的に非順序集合である． この設計方針では， 例えばデータの単純な集合では， 累積的なアサーションや， 後のアサーションによる前のアサーションのオーバーライドは除外される． 各々のアサーションは，他のアサーションとは独立に存在する．
後で， より多彩な方法でアサーションを結合するための論理式の構成法や， 少なくともアサーションの主語を暗黙にすることを許す構文規則を示す． しかし，これらはアサーションを非順序ANDリストに結合する基本演算を変更するものではない．
リソースに関するアサーションは，リソースの属性と呼ばれることが多い． つまり， リソースであるオブジェクトが， 例えば著者のような， 特定の名前の付いた特性を持つアサーションであるようなタイプで， その場合のパラメタは著者の名前あるいは身分証明である． 同様に，もし属性がドキュメントの有効期間ならば，パラメタはその日付である．
同一のリソースに関するアサーションのグループがまとまって存在し，
構文上はリソースのURIを暗黙のものとして省略する場合がしばしばある．
この場合，
アサーションがどのリソースに関して作られているかが文脈から明らかな時には，
アサーションは属性と値のリストの形式をとることが多い．
メイルメッセージやHTTPメッセージのようなRFC822形式のメッセージでは，
属性名がRFC822ヘッダ名で，
Data:やFrom:やTo:情報のようなRFC822行の残りがその属性の値である，
メタデータが転送される．
今日，属性と値の対モデルは，メタデータの意味を定義するほとんどの活動で使われている．
私は「アサーション」という言葉を， 転送時には属性と値の対が誰かによって作られたステートメントであることを強調するために使っている． リソースが，ある与えられた時間に与えられた属性としてその値を持つことを単純かつ直接に意味するものではない． 正しいことを特定の誰かが暗黙的あるいは明示的に保証したり保証しなかったりする， ステートメントとみなされなければならない． World Wide Webでは，信頼は重要な問題になっているが， 誰が何を言ったかを， ソフトウェア−と人々−がデータとメタデータによって履歴をたどり， 考慮に入れることは重要である． したがって， リソースのデータについての私達のモデルは， 典型的には作成者や責任者， 情報が作成された日付（アサーションを作る情報の断片の場合には，これはアサーションが作成された日付を意味する）， について知るためのものである．
アサーション
(A u1, p, q...)
明示的なパラメタとして，典型的には以下を持つ．
暗黙的あるいは明示／暗黙パラメタとして，
（アサーションは）プログラミング言語と対比させることができる． メタデータのアサーションは，プログラミング言語の関数呼び出しと対応する． メタデータでアサーションの主語が特別な位置にあるように， オブジェクト指向言語では関数のオブジェクトがパラメタの中で特別な位置にある． オブジェクト指向言語では， 持つことのできる関数の集合がオブジェクトに依存するが， メタデータではアサーションの型の集合は，語彙の自由な選択によって定義され，全く制限されない． 誰もが何についても何でも言うことができる .
Webアーキテクチャにおいて， リンクやメタデータのトポロジーと一般概念をこのように定義することは適切である． では，一つ一つの関係の意味についてはどうであろうか？ これらの関係には， 上述のようにアーキテクチャで定義されてアーキテクチャ上の重要性を持つものや， プロトコルにとって重要なもののように， 特別なものがある． それ以外の場合には， 関係や属性の意味は他の仕様や設計あるいはアプリケーションの一部であり， サードパーティによって簡単に定義できる必要がある． したがって， そのような関係と属性名の集合は極めて容易に，非集中的なやり方で，拡張可能でなければならない． このことが，以下の理由である．
| URL空間は属性名の定義のための適切な空間である． |
私達は既に(1997)属性名の語彙を持っている： 例えばHEADエレメント中にあるHTMLエレメントや， 他の例ではオブジェクトの属性を指定するHTTPリクエストの中のヘッダがそうである． これらは特定の仕様の範囲内で定義されており， 仕様の柔軟な拡張を求める圧力が常に存在する． HTTPヘッダ名は，実験を行う人々によって一般に任意に拡張されている． 同様のことはHTMLエレメントについても言え， 両者に対する拡張機構が提案されてきた． 一般に， そのようなメタデータ属性名の全てが作る大変広い空間では辞書は巨大になって， 集中化した登録がアドホックな任意の拡張によって滞るほど， 無秩序なものとなるであろう．
傍白：実体−関連モデルとの比較．このアーキテクチャは， アサーションの識別子が（基本的に）URL空間から取られており， 「実体−関連」 (ER) モデルや， ほとんどのオブジェクト指向プログラミングモデルなど多くの類似するモデルとは異なる． ERモデルでは， 典型的には全てのオブジェクトが型を持ち， オブジェクトの型がオブジェクトが持ち得る属性， すなわちそのオブジェクトに関して付けられるアサーション，を規定する． 例えば，人は名前や住所や電話番号を持つと一旦定義すると， 人種，肌の色，クレジットカード番号に関するアサーションを作るためには， 初めのスキーマを作り変えるか，あるいは新しく誘導型を導入する必要がある． 属性名のスコープは，OOPでメソッド名のスコープがオブジェクトの型（あるいはインタフェース）であるように， 実体の型である． これに対してwebでは， （構文チェックが通れば）たとえ無意味あるいは矛盾するものであっても， いかなるオブジェクトに関してもハイパーテキストリンクによって新しい形式の文を作ることが許される． Webの自分自身の場所で"coolness"という特性を定義し， web上のあらゆるオブジェクトの"coolness"についてステートメントを作ることができる．
この設計上の違いは， 本質的には， スケーラビリティのために整合性を犠牲にしリンクをmondirectionalにする設計方針の現れである．
ERシステムの優位性は， 例えばユーザインタフェースにおいて， 各々の実態に「定義されるべき」属性の集合を利用できることである． "well-specified"なオブジェクトに関する式を定義することによって， これらを「メタデータ」の述語計算で定義することができる． ("Xが顧客Xであるような全てのXについて"は， n が X の名前であるようなn が存在し， かつ，t が Xの電話番号であるようなt が存在し，かつ，… である時，well-specifiedである）
傍白終わり
上記で， メタデータ（"entity headers"）とみなし得るものを含むHTTPヘッダは， そうでないHTTPヘッダとは明確に区別されるべきであることを理解するのは重要である． メタデータを含むHTTPヘッダは， 周りのドキュメントをフォローすることのできる情報を含む． 例えば， キャッシュがそのような情報を処理することなく伝えることはリーズナブルであり， クライアントやデータを処理する他のプログラムがこのようなヘッダを後で処理するためにドキュメントとともにメタデータとして格納することはリーズナブルである． これらのヘッダの内容は， 特定のHTTPトランザクションと結びついている必要はない． これに対して， 特にトランザクションや２つのアプリケーションプログラムの間のTCPリンクを扱うHTTPのRFC822ヘッダは， より短いスコープを持ち，HTTPメソッドの単なるパラメタとみなすことができる． この違いを明確にすることで， HTTPとその処理方法に関する理解が容易になるだけではなく， 異なるパラメタを持つ異なるメソッドを使っているかもしれない他のプロトコルについて， HTTPのどの部分を手軽にかつ透過性を持って使うことができるかを理解することも容易になる． メタデータとメソッドのどちらも他のドメインに拡張できる程度にまでHTTPアーキテクチャを明確にすることは， World Wide Web コンソーシアムの仕事の重要な部分である． 提案されている多くの新しいインターネットプロトコルと同じく， SMTPやNNTPやHTTPプロトコルはRFC822ヘッダーの意味の多くを共有する． 共有空間の形式化と， １つの特定のヘッダーには１つの設計（４つの独立ではあるがたまたま良く似た設計ではなく）があることを明確にすることは， 一般性のあるアーキテクチャと注意深い思考が求められ， プロトコルの将来の設計にとって本質的である． これによって， 以前の仕事の大半を承認されたものとして， それとは独立な新しい設計に集中することができ， 小さなグループでプロトコル設計を行うことが可能になる．
サーバがHTTPヘッダの中で与えた属性の集合にドキュメント自身をリンクする特別なリンクの型を作成することによって， HTTPサーバから送られたメタデータの明らかな変異を除いたり， 少なくとも囲い込むことは可能であるかもしれない． 言い換えれば， サーバは次のように言うことができるであろう． 「ここにドキュメントがある，ドキュメントに関するメタデータがここにある， そして，ドキュメントに関するメタデータは次のURLを持つ」 このことで，例えば署名のあるHTTPヘッダーを要求することが可能になるだろう． それによって， ヘッダーの知的所有権や出所について問うことができる．
HTTPヘッダーの出所について完全に明確にすることは重要である． サーバは， ドキュメントの発行者または著者（URIからリソースの本体への写像の定義者）の代理として振舞うソフトウェアエージェントとみなすことができる． ウェブマスターは， 電線上のトランザクションが発行者や著者のステートメントあるいは要請を忠実に表現することを（サーバを適切に設定して）保証する責任を負う管理者に過ぎない．
２つのリソースの間の関係に関するアサーションは， リンクとして知られる．
この場合，それは３項組
(A u1 u2)
であり，その内容は：
この種のアサーション，つまりリンク，は， World Wide Webのナビゲーションの基盤である； それらは，World Wide Webの中に構造を作り， さらに世界そのものに関する知識を表現可能な意味のWebを作るのにも使うことができる． すなわち， リンクはデータ，その場合はメタデータ，の構造としてだけでなく， データの形式としても使うことができる．
リンクは，すべてのメタデータと同様に３つの方法で受け渡すことができる． リンクはリンクの一方の端であるドキュメントの中に埋め込むことができ， 例えばドキュメントのヘッダと呼ばれるHTTPメッセージの中で送ることができ， （リンクのどちらの端でもない）第３のドキュメントの中に格納することができる． この最後の方法は，World Wide Webでは今までのところあまり使われていない．
メタデータさらにはデータのセマンティクスが定義される方法は， システム全体の設計で重要な部分である． メイルメッセージやHTTPメッセージのRFC822ヘッダー中のメタデータのセマンティクスは， プロトコルの仕様の中で英語によって人手で定義されている． PICSシステムは， PICS ラベルの中で作られる各々のアサーションのセマンティクスを人間に読める言葉で定義するドキュメントへのポインタをメッセージに含め得ることで， 柔軟性の点でこれを一段進めている． 将来は， 全てのメタデータあるいは事実上全ての形式のマシンリーダブルなデータが， 自身を作った全てのアサーションの意味仕様への参照を持ち運ぶ状態へと向かいたい．
例えば２つのドキュメントの間にリンクが定義されている場合を考えると， アサートされている関係は， World Wide Web上で（URIの形式の一つを使って）見ることができ， 以前にその関係に出合ったことのない人やプログラムがリンクをたどってこの新しい形式のアサーションを利用するための理解や機能を拡張するよう， 定義される．
PICSの場合， アサーションが意味していることの人間に読むことのできる定義を， 動的に拾い上げることができる． さらにPICS（と理論的にはDTDを使ったSGML）では， アサーションがとることのできる形式や構文や持ち得るパラメタの型のマシンリーダブルな定義を， 拾い上げることができる． このことは， ヒューマンインタフェースが新しいPICSスキーマをオン ザ フライで作り上げることを許す． 次の段階では， 適当な論理あるいは表現言語が与えられ， 他の関係によって表現したアサーションのセマンティクスのマシンリーダブルな定義を拾い上げることができて欲しい．
そのような自己記述的な情報の利点は， web上の多数のグループが， 新しいアプリケーションや新しい機能を独立に開発できることにある． 自己記述的な情報がなければ， 大企業や標準化委員会が会合を開いて共通化したセマンティクスに同意するのを， 開発の際に待つ必要がある．
もちろん，新しい形式の情報を扱えるようにソフトウェアを拡張する実際的な方法は， そのようなデータを扱えるソフトウェアオブジェクトをサポートするコードを動的にダウンロードすることである． これは強力なテクニックであり，ますます使われるテクニックではあるが， 十分ではない． なぜなら，オブジェクトの実装と状態を信頼しなければならないからである．
| 構文とセマンティクスは，可能な限りメタデータドキュメントからの参照によって獲得できるべきである． |
webの上に構築されたアプリケーションでは， Webのインフラストラクチャーの中に構築されたアプリケーションでも同様に， 大変多くのアプリケーションが新しい関係型を定義することによって大部分定義できることが明らかになった． これらの例はドキュメントの版管理であり， ドキュメントを前と次の版および版のリストに関連付けるリンク値を定義することによって， ほぼ解決できる； 知的所有権，配布条件， ドキュメントからメタデータを含むドキュメントへのリンクを作ることによって解決できる他のラベルなども同様である．
ここからは未完成
情報にラベル付けする時に， 同一のオブジェクトに関する多数のステートメントを作ることはしばしば有益である． また， リソースの集合に関する同じステートメントの集合を作れることも，同様に有益である． 例えば， アサーション
(A1 u1 a b ... ) (A2 u1 c d ) (A2 u1 a f g h )
は以下のように書いても良い．
(for u1
(A1 a b ... )
(A2 c d )
(A3 a f g h )
)
このことで， アサーションの構文の中では主語は暗黙のものとなる． これは， RFC822ヘッダがボディを暗黙に参照したり， HTMLの"HEAD"エレメントの内容が包含するドキュメントを参照するのと同じである． （しかし，メッセージヘッダは完成したものであるため， 一般のラベルとメッセージヘッダの間には以下で議論する根本的な違いがあることに注意）
したがって， ラベルは， 本質的に構文の中で最適化するのが賢明な場合として理解するのが良い． [RDFでは，主語は文脈として確立され， 多くの特性は文脈の中で与えられる．-2000/9]
上で議論したように，主語が暗黙の場合にはアサーションは属性−値の対として知られている． 主語を抜き出したアサーションの集合に対して，「ラベル」という用語を使うことにする． ラベルは，ジャム瓶のラベルと同様に情報を持つが， 何に対して適用されるのかを教える他の情報（ジャム瓶のラベルの場合，その瓶の上に貼られているように）もなければならない． （実際PICSラベルは，主語とラベルの起源に関するメタ−メタデータなど，他の情報も含む）
局所定義：
| ラベルは共通の暗黙の主語を持つアサーションの集合である． このアーキテクチャでは，それは属性−値の対の集合である |
（慣習的に，ジャム瓶のラベルに「ジャム」と書くことができる． 「ジャム瓶」あるいは「ジャム瓶ラベル」とは書かない． そうは言っても， 私は「機器輸送箱のラベル」と書いたラベルの付いたボール箱を見たことがある！）
メタデータがデータであることから， それに関するメタデータが存在し得る． このメタデータのいくつかは， 信頼モデルを考える際に重要になる． 私達が必要とする論理には，メタデータの著者が含まれる．
p1: (A u1 . . .)
ここでp1は，信頼度の低いシステムでは書かれたとおりの著者であるが， 暗号化されたセキュアなシステムでは鍵で表現されたprincipleである．
webでは，情報の粒子はリソースである． 起源やアクセス制御は，一般にこの粒子を使う． したがって，典型的には， アサーションに置く信頼は， それをアサートしたドキュメントと，そのドキュメントに関するメタデータから決定される． しかし， 多くのリソースから情報が結合される時には， オリジナルの情報源を記録できる言語が必要になる． HTMLのブロッククオートのように， これはデータ自身をリソースから分離し， リソースはデータを直接アサートするが， データがアサートされていたことをアサートする．
PICSラベルを考察し， ラベルの実セマンティクスを取り出そうとする時には， 一般的なメタデータとしてのPICSラベルの解析 を参照
これは，要求を生み出すための思考実験である． 結論は， 起源や日付情報は実際のところアサーションに関するアサーションのツリーを形成し， そのツリーの構造について明確にすることが重要である， ということである． メッセージの概念はそこでもまた持ち出されるが， この点の議論にはgermaineではないとして追求されない．
もしラベルの特性について何らかの仮定を置くことができれば， ラベルの意味について全てを知ることなく， ラベルを操作することができる． 可換性，推移性，結合性などの特性は， おそらく構文において，そうでなければそれがスキーマにおいては成立しないことで， 簡単に利用するために大変有用であろう．
[より高いレベルの論理については， セマンティックWebロードマップ を参照]
例えば， 一つのジーンズがウェスト３２インチで値段が＄２８であることを示すラベルが与えられた時， 価格が＄２８であることだけを示すラベルを推論することができる． しかし， 犯罪の刑罰が拘置２ヶ月で罰金＄３０００であることを示すラベルが与えられた時， 刑罰が拘置２ヶ月であることを示すラベルを推論することはできない．
メタデータの典型的な利用は， 他の関係者によって検証されるべき証明と一緒にステートメントを提供することであろう． これらを効果的に，限られた知識の下で処理できることは重要である．
このための最も現実的な方法は， 論理機能のための基本的な共通語彙を作ることである． これらは「RDF上位レイヤ」として知られ， セマンティックWebノート で言及されている．
上記の アサーションの独立性の原理 によって， アサーションが独立して真であれば， どのようなアサーションの集合においても， 特定のアサーションを除いたり順序を変えてもドキュメントの正当性は変わらない（情報は減るが）．
現時点で非順序的なものの例には次のものがある： RFC822メッセージヘッダ行，SGML属性． 順序的なものの例は： HTTPヘッダ行とSGMLエレメント．
互換でないパラメタを多く持つアサーションを作れる形式が，どうしても必要であろうか？
上記の，メッセージ，ラベル，ラベルの区分，ステートメント，を表現する方法はいくつかあり， それらを区別しなさい．
可能なかぎり， 構文とセマンティクスは他のメタデータドキュメントからの参照によって獲得できるべきである．
複数の語彙を同一のスコープの中に混在できなければならない．
構文と構造は， 使われている語彙の意味について知ることなく， できるだけ多くの操作ができるようなものであるべきである．
基本的な論理や知識表現の機能のための共通語彙が必要であろう．
PICS − PICSプロジェクトは， コンテント・フィルタリング問題のためのエンドースメント情報を交換するための標準を定義するプロジェクトであった． PICSホームページを参照．
Last edit $Date: 2000/09/21 15:54:40 $