要約

  • ALIWEBは、何を説明するかを情報提供者に委ねる一方、収集と検索は中央のサービスに置いた。
  • 1994年の試験運用は、小さな索引が別のカタログからも使われたことを示す。ただしWeb全体の網羅や幅広い採用を証明するものではない。

1993年末、Webでは文書を公開するだけでなく、必要なものをどう見つけるかが課題になっていた。手作業の一覧は背景を伝えられるが、移転や新サービスをすべて追うのは難しい。クローラーなら発見できるページは増えるものの、サーバーへの反復アクセスが負担になり、サイト内の構成を読み取れずにばらばらの文書として扱うこともあった。

1993年11月30日、Martijn KosterはALIWEBをWebの「分散」索引の実験として告知した。各サーバーがローカルファイルで内容を知らせ、一つのサイトがそのファイルを自動取得して処理し、集約データベースをWebから検索できるようにする。Kosterの会議論文によれば、NEXOR上の試験サービスは同年10月から動いていた。11月30日の告知では、これを最初の一歩と位置づけ、決定版とは呼ばなかった。より良い方式が現れれば、蓄積したデータを簡単に使い直したり変換したりできるはずだ、という一文も添えていた。

この一文は設計の意味を変える。ALIWEBは検索サービス自体を分散化したのではなく、索引を書く権限を分けた。サイト管理者はどの文書やサービスを載せるか選び、説明を付ける。ALIWEBの運営側は参加サーバーの一覧を管理し、取得の間隔を決め、形式を検査し、受理した記録をまとめ、検索画面を運用する。提供者が自サイトの説明を担い、中央サービスがその説明を他サイトから発見可能にする経路を担った。

入力は、/site.idx と呼ばれることの多いテキストファイルで、Internet Anonymous FTP Archives（IAFA）のテンプレートを使った。テンプレートには属性と値が並び、一つのファイルに複数の対象を記述できる。例にはテンプレート型、タイトル、URI、説明、キーワードなどがある。ALIWEBはページのマークアップから意味を推測しようとせず、サイトの構成を知る人が入口となる資源を選ぶ方式だった。Kosterの例が示すのも、NEXORのPerl資料とマニュアルであり、サーバー上の全ファイルではない。

参加には小さな運用上の取り決めが必要だった。管理者はサーバー、ポート、索引ファイルの場所をWebフォームに登録し、連絡先を届け、取得間隔の下限を指定できた。ALIWEBはファイルの存在と形式を確認してから登録を受け付ける。別のPerlプロセスが登録済みの索引を定期確認し、変更分を取得してUNIXのcronでデータベースを再構成した。検索はALIWEBのフォームだけでなく、CUI W3 Catalogなど別のカタログからも行えた。

Web全体を歩き回るクローラーとの違いは、自動化の有無ではなく、何を取りに行くかだった。ALIWEBも収集と統合を自動化したが、サイトのリンクをたどって文書をすべて取得するのではなく、指定された一つの索引ファイルを取った。通信量を抑え、提供者側の文脈を残せる一方、索引に載っていないページは、クローラーが到達できても検索から漏れ得る。結果の鮮度は中央の定期取得だけでは決まらず、提供者がファイルを更新しているかにも左右された。

Kosterが報告した数字には、利用と限界が同時に表れている。論文の時点で登録ホストは54、データベースの項目は310件だった。ALIWEBの簡易検索は平均して一日80回使われ、CUI W3 Catalogは週に8,000回を超える検索でそのデータベースを利用した。これは動作するサービスと一つの有用な連携を示すが、Web全体のどれだけを収録したか、結果の質、何台のサーバーが有効なファイルを保てたかは測っていない。

登録時のつまずきも早くから見えた。ファイルを用意せずにホストだけを登録する管理者がいた。フォームに先にたどり着き、仕組みを理解していなかったためだとKosterはみた。チームは説明を増やし、ファイルの有無と形式をその場で検証するようにした。それでもファイルの誤りは残り、エラーを記録したうえで、手動実行するスクリプトから担当者にメールを送った。保守が不要になったのではない。全ページを巡回する作業が、選んだ索引の作成、検査、更新へ移った。

「手作業」は、永遠に一行ずつ手入力するという意味ではなかった。検索に使える十分な説明情報が残るなら、プログラムでファイルを生成してよいとKosterは述べた。1995年には別のアーカイブ事例が、ファイルシステムの変更に合わせてIAFAテンプレートを更新し、テキスト、Gopher、HTMLの索引を作る方法を記録している。このWWW会議論文はテンプレートの考え方が複数の表示方法に使えたことを示すが、ALIWEBのデータが移行したことや、サービスが広く採用されたことの証拠ではない。

もう一つの限界は規模だった。KosterはWeb全体を一つのデータベースに収めると大きくなりすぎる可能性を認めた。収集作業の分散、検索用データベースのミラー、分野別のデータベース、ALIWEBサービスの階層化を将来案として挙げた。索引ファイルを新しいディレクトリシステムへ自動変換できるとも考えていた。いずれも論文で検討された選択肢であって、実装済み機能ではない。重要なのは、形式が試験サービスの中央収集器より長く使えるよう意図されていた点だ。

1994年のネットワーク情報検索の概況も、分類制御などがまだ広く使われていない初期の分野として紹介している。ALIWEBは手作業の一覧、CUI W3 Catalog、JumpStationやRBSEのURLデータベースといった自動収集方式と並行して存在した。Web最初の検索ツールではない。より限定された貢献は、提供者が選んだ説明を自動収集し、別のシステムでも再利用できることを示したことにある。

Heng Luの後年のNote 65「Running-Code Primacy」は回顧的な分析の手掛かりであり、Kosterの考えを示す証拠ではない。形式が移行可能性を掲げても、実際に採用して動かすシステムがなければ移行は現実にならない。論文が記録するのはALIWEBの試験運用とW3 Catalogによるデータ利用である。普遍的な採用、Web公開者に対する義務、完了したデータ移行は記録していない。ここで分けて見るべき権限は三つある。提供者は自分のサイトの説明を決め、ALIWEBは共有索引に入れる項目を決め、将来のシステムは中央サービスを引き継がずにファイルだけを再利用できる。