Синонимы тегов являются популярной, важной функцией на многих сайтах (используется здесь, например, в StackExchange), а синонимы таксономии раньше входили в основной модуль Таксономии Drupal 6, прежде чем их отбросили в пользу систем «Сделай сам», сделанных на заказ. используя Field API .
Когда синонимы работают надежно, они чрезвычайно полезны при поиске; например, чтобы убедиться, что при поиске по запросу «Америка» найден контент с тегом «США» и т. д. Однако я не могу найти никаких сведений о том, каков стандартный метод для реализации этой функции при работе с популярным API поиска - Facet API. семейство связанных интегрированных модулей поиска, для поиска Node.
«Работать в потоке» важно при работе с кластерами таких модулей, чтобы убедиться, что внедряемые вами системы не идут вразрез с мнением сообщества и разработчиков модулей. Когда они идут против зерна, они ненадежны и рискуют быть сломаны будущими изменениями в этих модулях.
Что такое надежный / надежный / стандартный / ожидаемый метод для реализации таксономических синонимов в D7 для сайтов, использующих API поиска? (в частности, с помощью Search API Solr , но я надеюсь, что попытки Search API абстрагировать конкретного поставщика поиска в этом случае сработают).
Если у вас есть система для этого, которая, кажется, работает, но это то, что вы выяснили, и вы не уверены, что это против или нет (довольно часто встречается в Drupal), пожалуйста, поделитесь ею в любом случае с информацией из вашего тестирование, использование и опыт работы с функциями и модулями семейства Search API-Facet API, с которыми он работает и с которыми не работает.
Некоторые вероятные, но потенциально ненадежные варианты, которые я нашел в исследовании:
- Существует модуль синонимов поиска D7 , но он выглядит мало используемым, и нет подтверждения, что он работает или продолжит работать со сторонними поисковыми модулями, такими как Search API (он разработан с учетом поиска в ядре Drupal). Изменить: также не выглядит слишком надежным в D7 в целом .
- Теоретически возможно добавить поле справочника терминов под названием «Синонимы» в словарь таксономии и индексировать это поле из термина в API поиска с равным весом для термина на самом узле. Это будет работать для текстового поиска, но похоже на поверхностное решение для клейкой ленты MacGuyver-y, а не на надежное решение, которое плавно вписывается во все семейство Search API. Например, если у термина «Великобритания» есть синоним «Британия», кто-то, выполняющий поиск по «Британии», получит результаты, помеченные с помощью United Kindgom, а кто-то введет «Британия» в фильтр автозаполнения, раскрытый в таксономии, или выберет Британию с фактом таксономии. не будет видеть контент с тегом "Великобритания". *****
- Еще одна похожая возможность - добавить многозначное текстовое поле «Синонимы» к термину словарь (или даже через запятую, я полагаю) и индексировать его с тем же весом, что и у названия термина, как указано выше. Но это имеет аналогичные, если не хуже, проблемы, описанные выше в вышеприведенном примере: «Британия» даже не будет указана в качестве опции в фасетном или экспонированном фильтре. Может быть какой-то способ создать составное поле путем объединения имени и синонимов («Великобритания (Великобритания, Великобритания)») и установки фасетов / открытых фильтров / и т. Д. Для использования этого ... но я не могу придумать никакого способа чтобы сделать это, что не слишком неприятно, и это не беспокоит против зерна. Редактировать: Search API Combined, кажется, предназначен для чего-то вроде этого, но я
- Тогда есть последний вариант - просто втиснуть все в название термина: должно быть ясно, что это нежелательно и во многих случаях приводит к очень уродливым спискам (например, представьте навигационный список стран, которые были написаны как «Север»). Корея (КНДР, КНДР, КНДР) "...). Или с полем «Отображаемое имя», которое показывает краткую версию, и настройкой всего, кроме поиска (все виды, Pathauto, каждый другой модуль contrib / core, использующий термин name), чтобы использовать его вместо термина name ... снова, очень хаки и очень против зерна.
- В Apache Solr есть функция синонимов, где читается текстовый файл синонимов, и эти термины рассматриваются как синонимичные во всех поисковых запросах, которые его используют. Однако, хотя это возможно в настройке Search API, в которой используется Solr, разработчики модулей считают неподдерживаемой расширенную конфигурацию Solr «попытка на свой страх и риск» . Кроме того, это более подходит для общей синонимии на языке сайта, чем синонимия конкретно в контексте таксономии. Например, сайт с таксономией, который не отличает Англию, Шотландию и т.д. от Британии, может захотеть считать их синонимами в контексте тегов, но не синонимами в контексте поиска по основному тексту. Изменить: главный сопровождающий Facet API предупреждает об этом маршруте интеграционные модули Solr работают с терминами, а TID не текстовые.
Я знаю, что это ошибочный пример, потому что в случае Великобритании / Великобритании и стран в целом люди привыкли использовать списки, у которых есть только один или другой. Существует множество менее простых случаев (например, категорий продуктов), когда люди не думают искать синоним.
Обновление: соответствующая информация в новой теме в очереди Drupal.org Facet API . Также (в настоящее время без ответа) поток в очереди API поиска .
(любые юристы по правилам задаются вопросом, нормально ли, что есть запросы на поддержку drupal.org, и drupal отвечает на вопросы по той же теме: да, на самом деле рекомендуется снять давление с сопровождающих модулей )