Информационная система wais (Wide Area Information Servers)

Распределенная информационная система WAIS была задумана как сетевой аналог традиционных информационно-поисковых систем, который давал бы возможность пользователям сети осуществлять поиск в полнотекстовых базах данных с использованием традиционного для ИПС информационно-поискового языка, поисковые предписания которого строятся на основе ключевых слов и/или их усечении, связанных между собой логическими коннекторами OR или AND. Первоначально система разрабатывалась четырьмя фирмами:

• Dow Jones & Со. (деловые базы данных);

• Think Machines Corporation (информационно-поисковые системы);

• Apple Computer (интерфейс пользователя);

• KPMG Peat Maverick (опыт работы с большим числом пользователей).

Первый прототип WAIS был полукоммерческой, полуисследовательской системой с большими ограничениями по использованию как со стороны пользователей данных, так и со стороны администраторов баз данных. Прототип WAIS понимал (насколько возможно) естественный английский язык и переводил его в поисковые предписания системы.

Реально WAIS стала широко применяться только с появлением версии FreeWAIS для операционных систем UNIX. В настоящее время существует большое количество реализаций WAIS, главным образом коммерческих, и система стала своеобразным стандартом информационно-поисковой машины на Internet.

Концептуальная модель wais

WAIS замыкает триаду Gopher, WWW. WAIS, обеспечивая функционально полный набор информационных технологий Internet. Если Gopher - это виртуальная файловая система, где в качестве элементов системы могут использоваться не только файлы различных форматов и директории, но виртуальные объекты в виде поисковых критериев, WWW - распределенная система гипермедиа, то WAIS реализует концепцию распределенной информационно-поисковой системы. Система состоит из двух основных компонентов: поисковой машины и интерфейса пользователя. Поисковая машина и интерфейс связаны между собой универсальным протоколом WAIS, который базируется на стандарте Z39.50.

Протокол z39.50

При чтении документации по различным сервисам Internet, как то Gopher, Wais, World Wide Web, часто приходится видеть ссылку на протокол Z39.50. Как правило, такая ссылка приводится в контексте организации механизма поиска распределенных информационных ресурсов с использованием ключевых слов. В отечественной литературе по данному вопросу за термином "Information Retrieval System" давно закреплено понятие "Информационно-поисковая система". Стандарт Z39.50, собственно, и посвящен организации распределенной информационно-поисковой системы в компьютерных сетях.

Главным основным отличием такой системы от других информационных технологий является язык запросов, который основан на логических высказываниях типа: "Найти все документы, содержащие термин А и термин Б, но не термин В". В ответ на такой запрос для каждого документа, удовлетворяющего критерию, будет получено значение "истина", а в противном случае - "ложь". В данном случае связка "и" употребляется в качестве логического "AND", а "но не" - логического "NOT".

Следует заметить, что в ни в одной сети не существует программных комплексов, реализующих полностью стандарт Z39.50. Существующие системы в той или иной степени реализуют лишь его подмножества, опуская подчас важные элементы, которые связаны как с обработкой запросов, так и с генерацией отчетов на эти запросы.

Общие положения протокола

Z39.50 - это один из протоколов семейства OSI (Open System Interconnection), который описывает прикладной уровень взаимодействия распределенных информационно-поисковых систем. Протокол определяет сам механизм информационного обмена в процессе обработки поисковых запросов и протокол обмена данными в системах, которые поиск осуществляют. Область применения протокола определена как: библиотечные системы и системы научно-технической информации. Стандарт не определяет протоколы взаимодействия с физическими устройствами или их виртуальными аналогами, например терминалами. В настоящее время область применения протокола значительно шире вышеперечисленных приложений, он применяется в информационно-поисковых системах общего назначения.

Модель протокола

При разработке протокола подразумевалось, что он будет описывать порядок обмена информацией между пользователями информационной системы и ядром системы через сеть передачи данных. При этом сами системы могут управлять данными, используя разные модели данных и различные языки манипулирования этими данными. Таким образом информационно-поисковую систему можно построить на основе любой системы управления данными, будь это обычная ИПС или объектно-ориентированная СУБД.

Термин "база данных" в спецификации Z39.50 имеет значение набора файлов, каждый из которых имеет свое уникальное имя. Группа файлов внутри базы данных может также иметь свое собственное имя и образовывать отдельную базу данных. Такой подход аналогичен понятию схемы и подсхемы для систем управления базами данных. Единицей хранения информации, которая может быть найдена при обращении к базе данных, является запись слайда. Все записи одного файла должны иметь одинаковую структуру (т. е. состоять из одного и того же набора элементов и точек доступа). Точка доступа - это уникальный или неуникальный ключ, который может быть указан самостоятельно или в совокупности с другими ключами в поисковом критерии. Ключ может быть элементом данных, может состоять из нескольких элементов, а может быть и частью элемента. Вообще, структуру базы данных в терминах Z39.50 можно изобразить, как на рисунке 13.1.

Запрос выполняется по всей базе данных. При этом проверяется совпадение точек доступа записей и элементов запроса. Набор записей, удовлетворяющих запросу, является ответом системы на запрос. Ответ может быть использован для следующих поисков в базе данных (расширение или сужение запроса пользователя). Если говорить более точно, то при формулировании запроса можно ссылаться на результаты поисков по предыдущим запросам.

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

Информационный сервис

В рамках работы распределенной информационно-поисковой системы рассматриваются два типа прикладных задач:

• задача, инициирующая взаимодействие и посылающая запросы на обслуживание;

• задача, отвечающая за ответы на запросы первой задачи.

Первая задача называется "источник" (origin), а вторая - "мишень" (target). Взаимодействие источника и мишени осуществляется путем установки соединения. Соединение может быть инициализировано только источником и может быть разорвано либо другим источником, либо мишенью, либо по внешним причинам, например, физический разрыв линии связи. В процессе взаимодействия источник и мишень не могут поменяться ролями. В отечественной литературе для такого рода взаимодействия используется обычно термин "сессия". Таким образом, протокол Z39.50 описывает интерактивную сессию между источником запросов и мишенью, которая эти запросы обслуживает. Как видно, Z39.50 описывает типичное взаимодействие по схеме "клиент-сервер".

Полный информационный сервис, как он понимается в стандарте, состоит из инициализации сессии, передачи данных и завершения сессии. В процессе инициализации сессии источник и мишень определяют параметры сессии и окружение сессии.

Согласно Z39.50, существует семь основных видов информационного обмена в рамках распределенной информационно-поисковой системы:

• инициализация сессии;

• поиск информации по запросу;

• представление результатов поиска;

• удаление результатов поиска;

• контроль доступа к информационному ресурсу;

• контроль прав доступа к информационному ресурсу;

• завершение сессии.

При инициализации сессии источник и мишень должны договориться о возможности использования пользователем отдельных баз данных, которые поддерживает мишень.

Первое, что необходимо сделать, - это проидентифицировать пользователя и его права доступа к различным режимам обмена информацией. Сам механизм идентификации в протоколе не описан. После идентификации пользователя источник и мишень начинают диалог, состоящий из ключевых фраз типа "will use..." и "will support" или "will not support". Разрешение на использование того или иного режима запрашивает источник, а мишень подтверждает или отвергает эти запросы. Обычно источник запрашивает режимы "поиск", "представление" и "удаление". В свою очередь, существует два типа запросов мишени: на управление ресурсом и управление доступом. Источник должен уметь на них отвечать для обеспечения надежного доступа к информации.

В дополнение к идентификации пользователя протокол допускает использование дополнительных средств защиты типа системы "КЕРБЕРОС".

Кроме установления возможностей использования различных режимов доступа протокол регламентирует и физические параметры сеанса:

• рекомендованную длину записи данных при обмене;

• максимальную длину записи данных при обмене.

Поиск информации

При реализации запроса на поиск информации подразумевается следующая логика его выполнения: "из обозначенного набора единиц хранения идентифицировать те, которые удовлетворяют запросу".

Набор идентифицированных записей называется результатом поиска, и он может быть использован для последующих поисков информации. В зависимости от параметров запросов ответ сервера может варьироваться.

	ИСТОЧНИК	МИШЕНЬ
Параметр	Запрос	Ответ
Query-type	x
Query	x
Database-names	x
Result-set-name	x
Replace-indicator	x
Small-set-element-set-names	x (optional)
medium-set-element-set-names	x (optional)
prefer#804040-record-syntax	x (optional)
Small-set-upper-bound	x
Large-set-lower-bound	x
Medium-set-present-number	x
Database/ diagnostic-records		x (if applicable)
Result-count		x
Number-of-records-returned		x
Next-result-set-position		x
Search-status		x
Result-set-status		x (if applicable)
Present-status		x (if applicable)
Reference-id	x (optional)	x (if applicable)

В настоящее время в стандарте Z39.50 определен только один тип запроса - RPN-запрос. Форма Бекуса-Наура для этого типа запроса приведена ниже:

RPN-query ::= argument I argument+argument+operator

argument ::= operand I RPN-query

operand ::= attribute-set+term I Result-set-id

operator ::= AND I OR I AND-NOT

В этой записи интересно отметить ее постфиксный характер и отсутствие одноместных операций. Для того чтобы лучше представлять принцип построения запроса и его интерпретации рассмотрим несколько примеров.

Простой запрос состоит из одного термина: "терминал".

Такой запрос позволяет найти все документы, которые имеют в своем поисковом образе слово "терминал".

Запрос из двух терминов и коннектора "AND" позволяет сузить границы поиска до документов, которые содержат оба термина одновременно: "терминал графический AND".

Как видно из этого примера, логический коннектор указан после слов-операндов.

Еще более наглядно постфиксный характер записи проявляется в следующем примере:

"Х-терминал терминал графический AND AND-NOT".

Здесь пользователь требует найти все документы, содержащие слово "X-терминал", но не содержащие комбинацию слова "терминал" и "графический". Таким образом, для операции "AND-NOT" операндами являются слово "Х-терминал" и результат операции, определенной над словами "терминал" и "графический".

Получение найденной информации

Получение найденной информации осуществляется при помощи указания идентификатора документа в виде:

text-address@domain.host.zone.

Где "text-address" - местоположение документа на сервере, "domain.host.zone" - адрес машины. В реальных системах документ хранится под идентификатором, который и указывают при запросе результатов поиска.

Другие режимы работы

Из оставшихся режимов реально используется только режим завершения работы. Режимы удаления, контроля доступа и наличия доступа к ресурсу либо совмещены с режимом инициирования, либо просто не реализованы. Следует заметить, что точного выполнения стандарта не наблюдается ни в одной из реально действующих поисковых программ в Internet. Система WAIS не является здесь исключением.