Наименее ограничительным подходом является индексирование всех элементов

Наименее ограничительным подходом является индексирование всех элементов Это также проблематично. Многие XML-элементы не являются осмысленными результатами поиска, например типографские элементы вида <b>def initely</b> или номер ISBN, которые невозможно интерпретировать без контекста. Кроме того, индексация всех элементов означает, что результаты поиска будут слишком избыточными Для запроса Macbeth's castle и документа, мы получим в ответ элементы play, act, scene и title, лежащие на пути от корня до узла Macbeth' в castle. Листовой узел в этом случае будет четыре раза повторяться в списке результатов: один раз — непосредственно и три раза - как часть других элементов. Назовем элементы, содержащиеся в других элементах, вложенными (nested). Возврат избыточных вложенных элементов в списке результатов является не слишком дружественным актом по отношению к пользователю.

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

Отбросить все маленькие элементы.

Отбросить все элементы, которые пользователи обычно не ищут (для этого необходимо, чтобы система XML-поиска регистрировала такую информацию).

Отбросить все элементы, которые эксперты обычно считают нерелевантными (если существует возможность получить оценку релевантности).

Хранить только элементы, которые разработчик системы или библиотекарь считает полезными для поиска.

В большинстве этих подходов совокупности результатов все же содержат вложенные элементы. Таким образом, для уменьшения избыточности требуется удалить некоторые элементы на этапе постобработки. В качестве альтернативы можно свернуть несколько вложенных элементов в списке результатов и использовать подсветку терминов запроса, для того чтобы привлечь внимание пользователя к релевантным фрагментам. Если термины запроса выделены подсветкой, то просмотр элементов среднего размера (например, разделов) займет ненамного больше времени, чем просмотр небольших подэле- ментов (например, абзацев). Таким образом, если раздел и параграф одновременно оказываются в списке результатов, то достаточно показать раздел. Дополнительное преимущество этого подхода состоит в том, что абзац представляется вместе со своим кон-текстом (например, с разделом, содержащим этот абзац). Этот контекст может помочь интерпретировать абзац (например, выявить источник информации;, даже если параграф сам по себе уже удовлетворяет запрос.

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

Проблема вложенных узлов в XML-поиске заключается в том, что разработчики должны различать разные контексты термина при вычислении статистики встречаемости терминов для ранжирования, в частности при подсчете обратной документной частоты (idf). Например, термин Gates в узле author никак не связан с множественным числом слова gate в узле section. В таком случае мало смысла в том, чтобы вычислять единую документную частоту слова Gates.

Для решения этой задачи можно вычислить показатель idf для пар “XML-контекст/ термин”, например вычислить разные веса idf для author# "Gates" и section#nGates" К сожалению, эта схема наталкивается на проблемы, связанные с разреженными данными: многие пары “XML-контекст” появляются слишком редко, чтобы надежно оценить их документную частоту. В качестве компромиссного решения для раз- чичения контекстов можно рассматривать только родительский узел х термина, а остальную часть пути от корня до узла х игнорировать. Тем не менее существуют объединения контекстов, которые оказываются опасными в этой схеме. Например, мы не можем различить имена авторов и названия корпораций, если у обоих родительским узлом является узел пате. Однако большинство важных различий, скажем, между author#"Gates" и section#"Gates". распознаются хорошо.

tel-icq