要約
- RFC 1625に記されたWAISのType-3検索要求には、読者が入力した語句と、関連度フィードバックに使う文書全体または選択箇所の両方を含められた。サーバーが返したのは順位付きの引用情報であって、文書本文ではない。
- サーバーは後から提示するための検索結果セットを保存しなかった。選んだ引用の取得には、Doc-ID、形式、必要に応じてバイト・行・段落単位の範囲を指定した別のSearch要求が必要だった。
- RFC 1625が定義したのは要求と応答の接点である。サーバー間で比較できる共通の関連度尺度、完全な導入実績、WAISが後年に衰退した理由までは定めていない。
文書を次の問いに組み込む
1994年6月、WAISによるZ39.50-1988の利用を説明した情報提供RFCが公開された。本文は、インターネット標準を規定する文書ではないと明記している。焦点の一つは、クライアントとサーバーの接点を単純に保つことだった。クライアントは読者の入力をそのまま送ればよく、サーバー固有のType-1検索式に変換したり、相手がどのZ39.50属性を実装しているかを知ったりする必要がなかった。
WAISはこの自由なテキスト形式をType-3クエリと呼んだ。ただし、クエリは文字列だけではない。読者が入力する「seed words」に加え、文書オブジェクトのリストを含められた。オブジェクトは全文でも一部分でもよく、Doc-ID、形式、分割単位を示すコード、開始位置と終了位置で指定された。位置の単位にはバイト、行、段落などがあった。
二つ目の入力は、関連度フィードバックを可能にした。文書または一節を選び、それに似た文書を探す。クライアント側で文章をキーワードに縮めて元の資料を捨てるのではなく、選択したオブジェクト自体を次の要求に添えられる。入力語句と資料片が一つの検索に入る一方、データベースをどう検索するかは各サーバー側に残る。RFCは境界を越える情報を説明しているが、すべての索引に同じ順位付けを要求してはいない。
これは「インターネットが検索を覚えた」という大きな物語とは異なる。WAISはクライアント、サーバー、データベース、プロトコルを組み合わせたネットワーク情報検索システムだった。1994年8月のRFC 1689は当時のツールを報告し、初期のWAISクライアントが自然言語の検索を受け付けたこと、世界に100超のデータベースと5,000人の利用者がいたことを記している。これは同時代の状況報告に記された数字であり、独立監査済みの利用者調査でも、その後の普及を測った数字でもない。
順位付きの引用は答えではない
サーバーの応答にはWAIS Citationの一覧が入る。各項目には見出し、関連度順位、利用可能な形式、Doc-ID、バイト長などが含まれ得た。RFC 1625は最高点を1,000に正規化する。これは同一応答内の並びを読みやすくするが、別サーバーの900点同士を比較できるとは限らない。先頭の文書が客観的に適切だとも、読者が必要な答えを得たとも証明しない。
Citationはサーバー上のオブジェクトを指す情報であって、本文そのものではない。その違いが取得方法を決めた。RFC 1625によれば、WAISサーバーはステートレスに動作し、検索結果セットを保持せず、応答を送った後に削除できた。このため、この処理ではZ39.50のPresent機能を使わなかった。選択した項目を取得するには、クライアントが別のSearch要求を送り、Type-1クエリでDoc-IDと希望形式を指定する。必要なら開始位置と終了位置も指定した。
取得応答は文書全体にも、一部分にもなり得た。RFC 1625は、全文や画像がクライアントの受信バッファーを超える場合があるため、クライアントがチャンク単位で要求できると説明する。これは設計上の理由と選択肢であり、すべての実装が常に分割取得した証拠ではない。指定した範囲の断片を得たことを、全文を取得したことと取り違えてもいけない。実際に要求した範囲と返された範囲を確認する必要がある。
検索の記録は三つに分かれる。読者が入力・選択したもの、サーバーが順位付けした引用、クライアントが後から取得した内容だ。Type-3要求には入力語句と選択文書を併記できる。Citationはサーバー上のオブジェクトと形式を指す。別の要求が範囲を指定して内容を返す。これらを一つの「検索結果」と呼ぶだけでは、解釈・保存・取得をどこが担ったのか見えなくなる。
URIにも適用範囲があった
同じ1994年に公開されたURL仕様は、WAIS用のwais:形式を、データベース、検索、個別文書の三つに分けた。また、任意のZ39.50サービスに使える汎用アドレスではないと説明している。プロトコル名と宛先の種類を明示する仕組みであり、すべての引用をどこからでもアクセス可能にするものではない。
2005年のRFCは歴史的なwais: URI方式を残し、WAISプロトコルは広く実装されず、当時稼働中のサーバーはほとんどないと記した。これはその時点の状態を示す記録であり、衰退の原因までは語らない。後継サービスがWAISを置き換えた、あるいは文書フィードバックがWeb検索の普及を生んだ、といった因果関係は資料から導けない。
この連載で近い題材を扱ったのは、RFC 1432の書籍目録に関するSofia Renの記事だ。あちらの論点は、書誌レコードや価格、連絡先が、実際に本を入手する手がかりとして今も有効かどうかだった。本稿は別の層、つまり選んだ文書がどう次のクエリになり、サーバーが引用をどう並べ、クライアントがDoc-IDと範囲を使ってどう取得したかに絞る。ここで論じるのは検索プロトコルの循環であり、目録の鮮度ではない。
出典と証拠の限界
中心資料はRFC 1625、同時代の状況はRFC 1689を参照した。URIの適用範囲はRFC 1738、後年の歴史的注記はRFC 4156にある。いずれも実装状況の完全な調査、サーバー間の順位比較、WAIS衰退の因果史は提供していない。
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加

