Правила перезаписи поисковых запросов протокола Z39.50 Хохлов Александр

Правила перезаписи
поисковых запросов
протокола Z39.50
Хохлов Александр
Задача поиска по разнородным
коллекциям
 Пусть существует несколько отдельных
коллекций документов
 Структура и типы данных в пределах одной
коллекции совпадают
 Между собой коллекции могут иметь различия
 Необходимо сделать одновременный
поиск по этим коллекциям
 Заполняемая форма поиска – одна для поиска
по всем коллекциям
 Форма поиска должна позволять задавать
сложные запросы и специфические поисковые
поля
Примеры
 Мета-поиск в интернет-коллекциях
 У каждого сервиса поиска свои возможности и
поля поиска
 Поиск по библиографическим базам
данных
 Схожие поля, но есть различия между собой
по степени детализации предоставляемых
поисковых возможностей
 Одновременный поиск по различным
типам коллекций
 Поиск книг, статей, журналов, музейных
экспонатов, картин, нот, писем ведется по
различным критериям
Следствие «одной формы»
 При посылке поискового запроса в конкретную
коллекцию требуется ее «адаптация» к
возможностям поиска
 Необходимо делать автоматически, с
минимальными предварительными настройками
 Необходимо минимизировать искажения,
возникающие от изменения запроса
 Необходимо «сгладить» те моменты, которые не
отрабатываются конкретным поисковым аппаратом
  правила перезаписи булевых поисковых
запросов + фильтрация результатов поиска
 Вопрос ранжирования не рассматривается
 Предполагается, что поисковый запрос возвращает
просто множество результатов
Основные моменты перезаписи
булевых запросов и фильтрации




Chen-Chuan K. Chang, Hector Garcıa-Molina, Andreas
Paepcke. Predicate Rewriting for Translating Boolean
Queries in a Heterogeneous Information System. ACM
Transactions on Information Systems, 17(1):1-39, January
1999
Запрос представляется в виде дерева из термов,
преобразуется в ДНФ
Каждый элемент ДНФ (поисковый терм) преобразуется к
поддерживаемому виду, максимально близкому к оригиналу
 Это может быть сформулировано как «минимизировать
шум» (минимальное расширение терма)
 Или как «оставить только релевантные результаты»
(минимальное сужение терма)
 Отрицание к терму меняет задачу на противоположную
Попутно при преобразованиях запоминается информация
для пост-фильтрации результата поиска
Приложение к протоколу Z39.50
 Используется булева модель поисковых запросов
 Термы представляют собой некоторое значение
плюс набор атрибутов, характеризующих его
 Например, значение «Пушкин» может быть
обозначено как «полное значение поля имени»
 Или как «значение встречается в поле имени»
 Базы данных при ошибках возвращают
диагностическую информацию о невозможности
исполнения представленного запроса и ее
причинах
 Можно строить базу знаний о возможностях поиска
на этапе исполнения поискового запроса
 Не требуется предварительной настройки
преобразований к конкретному поисковому
аппарату
Как преобразовывать термы в
Z39.50
 Изменение точки доступа (поискового
поля)
 Строится дерево зависимостей точек
доступа по признаку «включает»
 Замена происходит либо на верхнюю
точку доступа в дереве (минимальное
расширение), либо на объединение по
«ИЛИ» низлежащих точек доступа
(минимальное сужение)
Иерархия некоторых значений
1016 (любое)
1035 (везде)
1003
(автор)
2, 1005
(организация)
3, 1006
(колл. автор)
4
(заглавие)
1, 1004
(персональное имя)
5
(серия)
21
(тема)
35
(паралл. заглавие)
Изменение атрибутов
 Изменение значений атрибутов
 Индивидуальные правила для каждого
атрибута
 Например, если для значения не
поддерживается «правое усечение», то
минимальное расширение – «левое и
правое усечение», а минимальное
сужение – «без усечения»
Проблемы реализации
 Часто неподдерживаемые термы преобразуются в
«True» или «False» из-за отсутствия другого
осмысленного минимального расширения или
сужения
 Однако это происходит в случаях, когда
действительно невозможно заменить терм на
поддерживаемый
 Например, если не поддерживается поиск по
«больше», то его приходится заменить на
константу, и добавить пост-фильтр
 Практическое применение пост-фильтрации
результатов осложнено в связи с:
 Низкой скоростью передачи результатов поиска
 Высоким влиянием фильтров на результат (фильтр
по году может в 1000 раз уменьшить результат)
Нет оценки точности и полноты
модифицированного запроса
 Так как в каждом преобразовании термы
меняются минимальным (в заранее
определенной постановке задачи)
образом, то эта минимальность
распространяется на весь запрос
 Однако точность и полноту оценить
сложно, т.к. точное влияние изменений
на результат (кроме расширения /
сужения) неизвестно
 Плохо: термин может замениться на «True»
или «False»
 Хорошо: это происходит только в
«фатальных» случаях
С точки зрения пользователя
 При преобразовании запроса и отсутствии постфильтрации пользователь получает результат,
который не соответствует исходному запросу
 Необходимо сообщать о тех изменениях, которые
произошли для получения представленного
результата
 Для устранения использования полей,
используемых только в небольшой части баз
данных, имеет смысл разбить базы данных на
группы по предметной области
 Сделать для каждой области свой набор полей
 Разбиение по предметным областям упростит
понимание поиска
Выводы
 Применение общей техники перезаписи
булевых запросов для протокола Z39.50
возможно
 Аналогично для протокола SRW/SRU с CQLзапросами
 Это позволяет сократить расходы на
настройку поиска по сильно разнородным
базам данных
 Позволяет устранить «мелкие» ошибки
или различия между базами данных в
одной предметной области
Спасибо за внимание!
Вопросы?
Хохлов Александр
alex-khokhlov@yandex.ru