Кратко

  • Запрос WAIS Type-3, описанный в RFC 1625, мог содержать и введённые читателем исходные слова, и полный документ либо выбранный отрывок для обратной связи по релевантности; сервер возвращал ранжированные описания, а не сами документы.
  • Сервер не сохранял набор результатов для последующей выдачи. Чтобы получить выбранную запись, клиент отправлял новый запрос Search с Doc-ID, форматом и, при необходимости, диапазоном байтов, строк или абзацев.
  • RFC 1625 определял интерфейс запроса и ответа, но не общую для серверов шкалу релевантности, не полную статистику внедрения и не причины последующего упадка WAIS.

Документ становился частью вопроса

В июне 1994 года информационный документ описал, как WAIS использовала Z39.50-1988. В нём прямо сказано, что он не устанавливает интернет-стандарт. Практическая цель состояла в простом взаимодействии клиента и сервера: клиент передавал текст читателя, не превращая его заранее в серверный запрос Type-1 и не изучая весь набор поддерживаемых сервером атрибутов Z39.50.

WAIS называла такую форму свободного текста запросом Type-3. Но запрос не сводился к строке. Он мог объединять «seed words» — введённые читателем исходные слова — со списком объектов-документов. Объектом мог быть документ целиком или его часть; описание включало Doc-ID, тип объекта, код разбиения, начальную и конечную позиции. Код задавал единицы диапазона: байты, строки или абзацы.

Второй вход и создавал обратную связь по релевантности: выбрать документ или его часть и найти похожие документы. Клиенту не нужно было сначала сжать фрагмент до набора ключевых слов, а затем отбросить исходный материал. Сам объект можно было включить в следующий запрос вместе с новым текстом. Способ поиска по базе данных оставался на стороне сервера. Протокол описывал, что проходит через интерфейс, а не требовал единого алгоритма ранжирования для всех индексов.

Это более узкая история, чем утверждение, будто «Интернет научился искать». WAIS была сетевой системой информационного поиска с клиентами, серверами, базами данных и протоколом. Отчёт об инструментах RFC 1689, опубликованный в августе 1994 года, описал ранние клиенты WAIS с запросами на естественном языке и указал, что в мире было более 100 баз данных и 5 000 пользователей. Это данные современного инструментального обзора, а не независимо проверенная перепись и не показатель дальнейшего распространения.

Ранжированная запись не была ответом

Сервер возвращал список WAIS Citations. В каждой записи могли быть заголовок, ранг релевантности, доступные форматы, Doc-ID и длина в байтах. RFC 1625 нормировала верхнюю оценку до 1 000. Так было удобнее видеть порядок внутри ответа; это не делало оценки разных серверов сопоставимыми, не доказывало объективную релевантность первой записи и не показывало, что читатель нашёл нужный ответ.

Описание указывало на объект на сервере, но не содержало его тела. Это различие определяло следующий этап. RFC 1625 описывала WAIS как систему без состояния: сервер не хранил набор результатов и мог удалить его сразу после отправки ответа. Поэтому в этом сценарии WAIS не использовала функцию Present в Z39.50. Чтобы получить выбранный объект, клиент отправлял ещё один запрос Search, теперь с запросом Type-1, где указывались Doc-ID и нужный формат. При необходимости задавались начало и конец диапазона.

Ответ на извлечение мог содержать весь документ или только часть. RFC 1625 объясняет, что полные тексты и изображения могли быть больше приёмного буфера клиента, поэтому клиент мог запросить их фрагментами. Это обоснование проектного решения и доступная возможность, а не доказательство, что каждый клиент всегда применял разбиение. Полученный отрывок также не следует принимать за полный документ: важно сверить запрошенный и фактически возвращённый диапазон.

Таким образом, остаются три разных свидетельства: что ввёл и выбрал читатель, как сервер упорядочил записи и что клиент затем получил. Type-3 мог объединить слова и выбранный отрывок. Citation указывала на формат объекта на сервере. Второй запрос возвращал ограниченную часть. Если назвать всё это одним «результатом поиска», становится непонятно, где происходили интерпретация, хранение и извлечение.

У URI была определённая область действия

Спецификация URL, опубликованная позднее в 1994 году, задала отдельные формы wais: для базы данных, поиска в ней и конкретного документа. Там же оговорено, что такая схема не предназначена для произвольных служб Z39.50. Адрес сообщал, к какому сервису и типу цели он относится, но не делал каждую ссылку доступной отовсюду.

В 2005 году другая RFC сохранила историческую URI-схему wais: и добавила краткую оценку состояния: протокол WAIS не получил широкого внедрения, и к тому времени почти не осталось работающих серверов WAIS. Это датированная запись о состоянии, а не объяснение его причин. Доступные документы не позволяют утверждать, что конкретный преемник вытеснил WAIS или что её цикл обратной связи вызвал широкое распространение веб-поиска.

Ближайшая параллель в этой серии — статья Sofia Ren о книжной библиографии RFC 1432. Там вопрос состоял в том, помогали ли запись, цена и контактные данные действительно получить книгу. Здесь рассматривается другой уровень: как выбранный документ попадал в следующий запрос, как сервер ранжировал описания и как клиент затем указывал объект и диапазон для извлечения. Тезис относится к механике протокола, а не к актуальности каталога.

Источники и пределы доказательств

Основной источник — RFC 1625, современный контекст даёт RFC 1689. Область URI-схемы описана в RFC 1738, а более поздняя историческая оговорка — в RFC 4156. Эти документы не дают полного учёта реализаций, сравнения рангов разных серверов или причинной истории упадка WAIS.