Synonimy znaczników są popularną, ważną funkcją wielu witryn (na przykład stosowaną tutaj na StackExchange), a synonimy taksonomii były częścią podstawowego modułu taksonomii Drupala 6, zanim zostały odrzucone na korzyść niestandardowych systemów synonimów „Rzuć własne” za pomocą Field API .
Kiedy synonimy działają niezawodnie, są niezwykle przydatne w wyszukiwaniu; na przykład, aby upewnić się, że podczas wyszukiwania hasła „Ameryka” znajduje się treść oznaczona jako „USA” itp. Nie mogę jednak znaleźć żadnych informacji na temat standardowej metody wdrażania tej funkcji podczas pracy z popularnym interfejsem API wyszukiwania - API Facet rodzina powiązanych zintegrowanych modułów wyszukiwania do wyszukiwania w węzłach.
„Praca z przepływem” jest ważna podczas pracy z takimi klastrami modułów, aby upewnić się, że wdrażane systemy nie są sprzeczne z koncepcją społeczności i opiekunów modułów. Kiedy są sprzeczne z rzeczywistością, są płatkowe i ryzykują, że zostaną złamane przez przyszłe zmiany tych modułów.
Jaka jest niezawodna / niezawodna / standardowa / oczekiwana metoda implementacji synonimów taksonomii w D7 dla witryn korzystających z API Search? (w szczególności z Search API Solr , ale mam nadzieję, że próby Search API wyodrębnienia konkretnego dostawcy wyszukiwania będą w tym przypadku skuteczne).
Jeśli masz system, który wydaje się działać, ale to jest coś, co wymyśliłeś i nie masz pewności, czy jest to sprzeczne z rzeczywistością (dość powszechne w Drupal), proszę podziel się tym z informacjami z twojego testowanie, wykorzystanie i doświadczenie w zakresie funkcji i modułów z rodziny Search API-Facet API, które działają i nie działają dobrze.
Kilka wiarygodnych, ale potencjalnie płatkowych opcji, które znalazłem w badaniach:
- Istnieje moduł wyszukiwania synonimów wyszukiwania D7 , ale wygląda na to, że jest mało używany i nie ma potwierdzenia, że działa lub będzie nadal współpracował z modułami wyszukiwania innych firm, takimi jak Search API (został zaprojektowany z myślą o wyszukiwaniu rdzeniowym Drupal). Edycja: też ogólnie nie wygląda na zbyt niezawodnego w D7 .
- Teoretycznie możliwe jest dodanie pola referencyjnego terminu o nazwie „Synonimy” do słownika taksonomii i zindeksowanie tego pola od terminu w interfejsie API wyszukiwania z równą wagą do terminu w samym węźle. Mogłoby to działać w przypadku wyszukiwania tekstu, ale wydaje się, że jest to raczej płytkie rozwiązanie taśmy klejącej MacGuyver-y niż coś solidnego, które płynnie wpasowuje się w całą rodzinę API wyszukiwania. Na przykład, jeśli termin „Wielka Brytania” ma synonim „Wielka Brytania”, ktoś, kto szuka hasła „Wielka Brytania”, otrzyma wyniki oznaczone jako United Kindgom, ale ktoś, kto wpisze „Wielka Brytania” w autouzupełniającym filtrze narażonym na taksonomię lub wybierze Wielką Brytanię z faktem taksonomicznym nie zobaczyłby żadnych treści oznaczonych jako „Wielka Brytania”. *****
- Inną podobną możliwością jest dodanie wielowartościowego pola tekstowego „Synonimy” do słownika terminu (lub nawet oddzielone przecinkami, jak sądzę) i zindeksowanie go z taką samą wagą jak nazwa terminu jak powyżej. Ale ma to podobne, jeśli nie gorsze, problemy do powyższego w powyższym przykładzie: „Wielkiej Brytanii” nawet nie wymieniono by jako opcji w filtrze aspektu lub odsłoniętym filtrze. Może istnieć jakiś sposób na utworzenie złożonego pola poprzez połączenie nazwy i synonimów („Wielka Brytania (Wielka Brytania, Wielka Brytania)”) oraz ustawienie aspektów / filtrów narażonych / etc, aby z nich korzystać… ale nie mogę wymyślić żadnego sposobu robić to, co nie jest niepokojąco zuchwałe i nie jest niepokojące w stosunku do ziarna. Edycja: Search API Combined wydaje się być przeznaczony do czegoś takiego, ale „
- Jest też ostatnia opcja, aby po prostu wcisnąć wszystko w nazwę terminu: powinno być jasne, że nie jest to pożądane i w wielu przypadkach stworzyłoby bardzo brzydkie listy (np. Wyobraź sobie listę nawigacyjną krajów, które zostały napisane jak „Północ Korea (PRK, KRLD, Koreańska Republika Ludowo-Demokratyczna) „...). Lub posiadanie pola „Wyświetlana nazwa”, która pokazuje krótką wersję, i ustawianie wszystkiego oprócz wyszukiwania (wszystkie Widoki, Pathauto, każdy inny moduł contrib / core, który używa nazwy terminu), aby używał tego zamiast nazwy terminu… ponownie, bardzo zuchwały i bardzo przeciwnie do ziarna.
- Apache Solr ma funkcję synonimów, w której odczytywany jest plik tekstowy synonimów, a te terminy są traktowane jako synonim w wyszukiwaniach, które go używają. Jednak, chociaż jest to możliwe w konfiguracji Search API korzystającej z Solr, opiekunowie modułów uważają to za nieobsługiwaną zaawansowaną konfigurację Solr „próby na własne ryzyko” . Ponadto jest bardziej odpowiedni dla ogólnej synonimii w języku witryny niż dla synonimów, szczególnie w kontekście taksonomii. Na przykład witryna z taksonomią, która nie dyskryminuje Anglii, Szkocji itp. Z Wielkiej Brytanii, może chcieć uznać ją za synonim w kontekście tagowania, ale nie jako synonim w kontekście wyszukiwania tekstu podstawowego. Edycja: Główny opiekun API Facet API ostrzega przed tą trasą ponieważ moduły integracji Solr działają z terminami, ponieważ TID-y nie są tekstem.
Wiem, że jest to wadliwy przykład, ponieważ w przypadku Wielkiej Brytanii i Wielkiej Brytanii oraz krajów w ogóle ludzie są przyzwyczajeni do korzystania z list, które mają tylko jedno lub drugie. Istnieje wiele mniej prostych przypadków (np. Kategorii produktów), w których ludzie nie myśleli o szukaniu synonimu.
Aktualizacja: Odpowiednie informacje w nowym wątku w kolejce interfejsu API aspektów Drupal.org . Również wątek (obecnie bez odpowiedzi) w kolejce interfejsu API wyszukiwania .
(wszelkie zasady, które prawnicy zastanawiają się, czy jest w porządku, aby były prośby o pomoc drupal.org i drupal odpowiadają na pytania na ten sam temat: tak, w rzeczywistości zachęca się do odciążenia opiekunów modułów )