Правила перезаписи поисковых запросов протокола 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 (колл. автор) 1, 1004 (персональное имя) 4 (заглавие) 5 (серия) 35 (паралл. заглавие) 21 (тема)

Изменение атрибутов Изменение значений атрибутов Индивидуальные правила для каждого атрибута Например, если для значения не поддерживается «правое усечение», то минимальное расширение – «левое и правое усечение», а минимальное сужение – «без усечения»

Проблемы реализации Часто неподдерживаемые термы преобразуются в «True» или «False» из-за отсутствия другого осмысленного минимального расширения или сужения Однако это происходит в случаях, когда действительно невозможно заменить терм на поддерживаемый Например, если не поддерживается поиск по «больше», то его приходится заменить на константу, и добавить пост-фильтр Практическое применение пост-фильтрации результатов осложнено в связи с: Низкой скоростью передачи результатов поиска Высоким влиянием фильтров на результат (фильтр по году может в 1000 раз уменьшить результат)

Нет оценки точности и полноты модифицированного запроса Так как в каждом преобразовании термы меняются минимальным (в заранее определенной постановке задачи) образом, то эта минимальность распространяется на весь запрос Однако точность и полноту оценить сложно, т.к. точное влияние изменений на результат (кроме расширения / сужения) неизвестно Плохо: термин может замениться на «True» или «False» Хорошо: это происходит только в «фатальных» случаях

С точки зрения пользователя При преобразовании запроса и отсутствии пост- фильтрации пользователь получает результат, который не соответствует исходному запросу Необходимо сообщать о тех изменениях, которые произошли для получения представленного результата Для устранения использования полей, используемых только в небольшой части баз данных, имеет смысл разбить базы данных на группы по предметной области Сделать для каждой области свой набор полей Разбиение по предметным областям упростит понимание поиска

Выводы Применение общей техники перезаписи булевых запросов для протокола Z39.50 возможно Аналогично для протокола SRW/SRU с CQL- запросами Это позволяет сократить расходы на настройку поиска по сильно разнородным базам данных Позволяет устранить «мелкие» ошибки или различия между базами данных в одной предметной области

Спасибо за внимание! Вопросы? Хохлов Александр