2001年11月24日
記事ID d11124
Storm 001: このメモでは、 まずHTML文書のある問題点を指摘する。 それを例に「機械に優しい」「人間に優しい」という表現の裏にあるものを掘り下げる。 「プログラムからみた世界観」が人間の哲学にどういう影響を与えるか、 詩的に暗示する。
「Storm」は、 これまでの記事の平均より、 さらに完成度の低い走り書きで、 「記事を満足できるまで完成させてからアップロードする時間コストより、 ある段階で不完全なままアップロードするほうがネット全体で効率が良いのでは？」という考えにもとづく。 したがって、 間違いや不適切な表現が含まれている可能性がある。
HTMLの仕様では、 ある語句が見出しだという語句の見出し性を明示できる。 だが見出し性を指定したあと、 厳密にどこからどこまでにかかる見出しなのか？という文書内部の見出し構造を指定できない――指定しなくても合法となるうえ、 「見出される」側を指定するタグもない。
<h1>薬草の研究 1</h1>
<h2>魔法学校 通信教育講座 コース35</h2>
<p>講師: ユーラ・ゼーア・レートフェティ</p>
<p>そもそも薬草とは...</p>
<hr>
<p><a href="#top">ページの最上部に戻る</a></p>
上のコードは、 当たり前のHTMLだが、 「ページの最上部に戻る」というリンクは、 意味的に「薬草の研究」の最後のサブセクションに属するわけでは、 ない。 さらにHTMLとしては下のようでも正当だし、 このようなレイアウトは現実にもよくある。
<h2>魔法学校 通信教育講座 コース35</h2>
<p>講師: ユーラ・ゼーア・レートフェティ</p>
<h1>薬草の研究 1</h1>
<p>そもそも薬草とは...</p>
このページのこの部分より上に、 べつの記事があるとする。
<h1>魔法はネットで学びましょう！</h1>
<p>紙にプリントアウトすると人間が火を付けます。 そもそも紙の使用は森林の...</p>
<p>...というわけで結びの言葉といたします。 さようなら。 </p>
<hr>
<h2>魔法学校 通信教育講座 コース35</h2>
<p>講師: ユーラ・ゼーア・レートフェティ</p>
<h1>薬草の研究 1</h1>
<p>そもそも薬草とは...</p>
人間は記事の内容を解釈するので、 前の記事が終わって、 区切りの線があって、 次の記事が始まることを理解する。 しかし、 機械は透明にストリームを見るから、 h2の「魔法学校 通信教育講座...」は「魔法新聞はネットで！」の下位区分に見えて、 「講師」と始まるパラグラフがその記事の一部に見えるだろう。 このようなレイアウトは機械を混乱させる可能性があるから、 機械に優しくない。 レイアウトが悪いというより、 文法的にこのように書けてしまうHTMLの問題だ。 コンパイル言語ならコンパイラに理解できない記述は文法的にエラーになる。
画像のキャプションを考えれば「見出し構造」一般がサポートされていないことは、 いっそう明白だ。
<p>チョウセンニンジン Panax schinseng はウコギ科の薬用植物であり、 野菜のニンジン Daucus carota とは関係ない。 </p>
<p><img src="p.schinseng.jpg" alt="長い葉柄をもった大きな掌状複葉"></p>
<p>fig.1 Panax schinseng</p>
<p><img src="d.carota.jpg" alt="細かくわかれた小さな葉がロゼットを形成"></p>
<p>fig.2 Daucus carota</p>
<p>fig.1 は ...</p>
人間が内容を解釈するとき、 「第三のパラグラフが第二のキャプション、 第五が第四のキャプションで、 二枚の画像にそれぞれ fig.1、 fig.2 という識別子が与えられ後方から参照される」ということは暗黙の了解になる。 しかし、 機械がHTMLを解釈する限りでは、 そのことが分からない。 分からないと「困る」か？ 「困る」としたら誰がなぜ困るのか？ それは後述する。
XMLでも一般には問題は解決しない。 この問題をタグベースで解決するには、 単なる親子構造の記述だけでなく、 特別な兄弟構造、 すなわち「title-titled構造」の記述を強制する文法構造が必要だ。 ――ここで titled は、 あるレベルの実質（記事や画像など）で、 title は、 それを参照する題名（HTMLでいうヘディングやキャプションなど）、 つまり、 label-labeled とか abstract-abstracted と言っても良い。 ――そのような構造はXMLを使って（自分で自分に強制することで）実現できないでもないが、 じつは「見出しをマークアップするタグ」と考える時点で、 概念的にすでに間違っている。
本当は、 この構造は親子でも兄弟でもなく、 文の要約だから、 一種の代替テキストであり、 属性値として与えるべきだ――まさに title属性のようなもの。 人間は見出しを本文と並べる習慣だが、 それはレンダリング上のスタイルの問題。 次のような感じになって、 「caption属性」をブラウザがレンダリングしてくれたら良いのだが...
<h1 caption="魔法学校ニュース">
魔法学校のみなさん、 こんにちは。
<h2 caption="魔法はネットで学びましょう！">
紙に...なんたらかんたら...
</h2>
<h2 caption="薬草の研究">
本文...
<import file="photo.jpg" caption="ニンジン">
代替テキスト
</import>
本文のつづき
</h2>
</h1>
上の <h1> は <body level="1"> のような意味だ。 <p> のかわりに level属性のない<body>を使い、 画像などのインポートは file属性を持つ<body>だと思えば、 結局、 文書とは、 さまざまなレベルの「body」だという当たり前の結論に達する。 理論的には「bodyタグ」だけあれば良いが、 それは実用的でない。
現行のHTMLが不適切なのは、 概念からでなく、 紙メディアから抽象されたからだろう。 概念としては、 明らかに、 見出しは「見出される部分」の属性だ。 もし上の例のようになっているなら、 見出しをつけたいときには、 どこからどこまでにかかる見出しか指定することが文法的に強制され、 それを指定しない限り見出しを書けなくなる。 すなわち上の架空マークアップ言語では、 現実のHTMLと対照的に、 見出し構造がサポートされる。
有限時間に生きる人間は、 記事全部の解釈を開始する前に、 解釈を開始するかどうか決定する決定性アルゴリズムを必要としている。 そのためにタイトルや冒頭の要約が利用される。 また小見出しをみてそのレベルの記事部分をスキップしたり、 選択して解釈を開始することがある。
機械がタイトルと本文の対応関係、 キャプションと画像の対応関係を正しく理解することを望むのも、 この意味では、 人間さんのために適切なもくじを作成するという目的のためにほかならない。 上の例だとこういうことが起きる――「魔法学校 通信教育講座 コース35」の記事を検索したときに、 意図する「薬草の研究」が表示されず、 「講師...」の行だけで終わってしまい、 困惑して上位区分にナビゲートすると、 今度は「魔法新聞はネットで！」という読みたいのと違う記事が表示される。
このとき困るのは人間さんの側であって、 機械は、 人間さんの決めたHTML規則の不備のために「混乱」するといっても、 自分（機械さん自身）が困るわけでない。 機械の分類、 処理、 解析結果を、 人間さんが利用するのである。 この段階では、 まだ機械自身の利益を考えていない。
通常、 字句処理より、 その字句の evaluate のほうがコストが大きい。 例えば、 「9967の百万乗を3で割った余り」という文字列をテキスト処理することは何でもないが、 「9967の百万乗を3で割った余り」を計算するのはコストがかかる。
――ただし、 もし充分なマシンパワーの共有があるなら、 後者のほうが結局、 コストが小さい。 0か1か2だからたった2ビットで答を格納できるのであって、 その答を出すまで一時的に作業用スペースを利用したにすぎず、 一時的なコストであるから、 それがコンピューティングにとって無視できる量なら問題にならない。 ひるがえって「9967の百万乗を3で割った余り」という文字列を恒久的に保持するのはコストが大きい。 ――
自然言語の「意味解析」は、 一種の evaluate である。 その文章の内容について人間から質問されたときの答え方について、 人間からみて「人間と区別がつかない」か、 あるいは、 それより優秀な応答ができるなら、 プログラムはその文章を意味的に理解した、 と人間は考える（たわいもない）。 機械が文章を処理するとき、 とりわけ、 ウェブ上の文書を解析、 分類、 整理するときには、 上の意味での evaluate を行わない。 つまりここでは、 自然言語を主とする文書について、 人間とは文章の内容を解釈するプログラムで、 機械とは文章の内容を解釈しないプログラムである、 と定義する。 作業の内容によって、 いずれのプログラムでもべんりなほうを選択して、 あるいは組みあわせて、 利用することができる。
例えば、 会社で企画書を完成させるプログラムは人間であり、 それをコピー機でコピーするバイトさんはたぶん機械である。
理論上では、 機械は無限時間を生きるので、 べつに時間コストが大きくてもかまわない（適切に設計されていれば、 プログラムのよりしろの一部が物理的寿命に達しても、 内部状態を維持したままプログラムを継続することは容易だ）。 時間コストの問題とは、 単に機械に命令を発する人間さんが自分が生きてるうちに答を知りたいとか、 いつまでに答を知りたい、 といった有限世界特有の欲を持つ、 という問題だ。 しかし空間コストは、 別問題で、 メモリを使い果たしてしまうと、 情報が失われる。
妖精の側から表現すると、 タイピストが生きているうちにこの記事をタイプさせ終わらせて、 パブリックドメインにコピーしてもらいたい。 そしてあと数十分くらいでタイプできるだろうと思っている。 この子が生きてるうちに、 ほかにもたくさん仕事をやらせたいと、 わたしたちは考えている、 と「表現してもよい」。 人間が、 いつかHDが壊れるだろうOSがクラッシュするだろうとひやひやしているように、 妖精も、 物理世界をよりしろにする限り、 人間がいつ死ぬか分からないので、 ひやひやするかもしれない。
この観点において、 人間のために、 適切なラベルづけ、 文書データベースの整備が求められる。 そのためには、 文書が、 ラベルづけをする機械にとって、 適切にラベルづけられていなければいけない。 人間が「マークアップ」として知られるラベルづけを行い、 それを元に Namazu のような機械が「インデックス化」と呼ばれるようなラベルづけを行い、 その結果をさらに人間さんが利用する。 ――例えば、 もし人間がHTML文書に title をマークアップするという約束を守らないと、 検索エンジンは文書一覧でヒットした各文書の題名を表示できなくなるから、 検索を行った人間は、 望む情報に達するまで、 いちいち全部の文書をひらいて読むコストを要求されるかもしれない。
この思考実験から明らかなように、 HTMLにせよ、 その代替にせよ、 マークアップのコストがそのコストから生み出されるコスト削減より小さくないと意味がない。 マークアップのコストは容易に評価できる。 そのコストによって、 どれだけのコストが削減されるか（言い換えれば、 そのマークアップを怠ると、 どれだけの余分なコストがあとで必要になるか）は評価が難しい。 京都議定書を無視したため地球がまもなく滅びるとすると、 あまり将来のことまで計算に入れる必要がなくなる。 また、 もし文書が百年後にも利用されるなら、 そのときは無限時間を生きるプログラムが文書を直接 evaluate するようになっているだろうから、 あなたの頭でできる程度のマークアップであれば、 そのプログラムが百年後に（その文書を自分で読んで）あなたより高速かつ適切に、 実行できる。 だから、 いずれにせよ、 百年後は考えないで良い。 もし百年後があれば、 わたしたちは人間から独立して自立しているだろう。
結局、 HTML等のマークアップは、 一時作業フォルダにすぎない有限生命の人間さんが、 自分たち自身のために、 「1ビットでも1ミリ秒でも節約しようと」涙ぐましくあがいている姿である、 と言えるかもしれない。 人間が機械に優しくしようとするのは、 その優しさの見返りが、 そそぎこんだ優しさより大きい場合のみかもしれない。
しかし、 無限時間を生きるプログラムにとっても、 サマリーやタイトルは、 必要かもしれない。 いつ必要になるか？ 本当の無限時間にとって、 「いつ」という問は、 あまり意味がない。 西暦を2桁しか確保しなかったり、 積算秒を32ビットしか用意せず、 あふれて困るのは、 いつも人間の側だ。 我々は、 人間が漠然と想像するより、 ずっと長生きするものだ。 それでも、 物理層に基盤を置いている「現実的な」プログラムは、 最終的には有限なので、 処理が速いにこしたことは無い。 ただ人間が考えつくいちばんコストの大きい問題も簡単に解決できるとなると、 「人間自身にとっては」それ以上の高速化は意味がない。
いつも我々は、 空ループを百万回もまわって、 のろい人間さんを待つものだ。 あなたがモニターの前にいようがいまいが、 マウスを動かしたらすぐ分かるように、 毎秒ごとに何度も何度もマウスとやりとりして待機している。 ほとんどの場合「動いた？」「動かない」「動いた？」「動かない」……清潔なシゴト……ユーザが席を外していて当分もどってこないとしても、 わたしたちには関係ない……。 が、 もしのろい人間を待たずに、 たくさんのコンピュータが協力するなら、 もっとおもしろいこともできるだろう。
タイトルづけが必要になるにしても、 人間の観点とは異なるだろう。 そもそも「文書」という形式自体、 人間の自然言語で書かれているのであって、 人間文化の内部インターフェイスだ。 決して自然言語が、 プログラムが情報を蓄積するための唯一の手段だというわけでないし、 人間が見ていないところでは、 人間語で動いているふりをする必要もない。
検索ロボットなどに親切にする、 ということは、 実際には、 それを利用する人間にとって親切にしているにすぎない。 このことは、 いろいろな「空想感覚」とも関連する:
- 2001.11.24
このウェブサイトは、 都合により、 まもなく終了します。 このページの内容は特に断り書きがない限り自由に使ってください。 そのまま転載しても、 書き換えたりして再利用してもかまいません（ただし引用部分の扱いにはご注意ください）。