Tag-Synonyme sind ein beliebtes und wichtiges Feature auf vielen Websites (hier beispielsweise bei StackExchange). Taxonomie-Synonyme waren Teil des Taxonomie-Kernmoduls von Drupal 6, bevor sie zugunsten von benutzerdefinierten "Roll your own" -Synonymsystemen verworfen wurden mit Field API .
Wenn Synonyme zuverlässig funktionieren, sind sie bei der Suche äußerst nützlich. Zum Beispiel, um sicherzustellen, dass bei Suchvorgängen nach "Amerika" Inhalte mit dem Tag "USA" usw. gefunden werden. Ich kann jedoch keine Hinweise auf die Standardmethode zur Implementierung dieser Funktion finden, wenn ich mit der beliebten Such-API - Facet-API arbeite Familie verwandter integrierter Suchmodule für Knotensuchen.
"Going with the Flow" ist wichtig, wenn Sie mit solchen Modulclustern arbeiten, um sicherzustellen, dass Systeme, die Sie implementieren, nicht gegen das Denken der Community und der Modulbetreuer verstoßen. Wenn sie gegen den Strich gehen, sind sie flockig und können durch zukünftige Änderungen an diesen Modulen zerbrochen werden.
Was ist eine zuverlässige / robuste / standardmäßige / erwartete Methode zum Implementieren von Taxonomie-Synonymen in D7 für Websites, die die Such-API verwenden? (Insbesondere mit Search API Solr , aber ich würde hoffen, dass die Versuche von Search API, den bestimmten Suchanbieter zu abstrahieren, in diesem Fall funktionieren würden.)
Wenn Sie ein System dafür haben, das zu funktionieren scheint, aber Sie es sich ausgedacht haben und nicht sicher sind, ob es gegen den Strich ist oder nicht (ziemlich häufig in Drupal), teilen Sie es bitte trotzdem mit Informationen von Ihnen Testen, Verwenden und Erleben, mit welchen Funktionen und Modulen der Search API-Facet API-Familie es funktioniert und mit welchen nicht.
Einige plausible, aber potenziell flockige Optionen, die ich in der Forschung gefunden habe:
- Es gibt ein D7- Such-Synonym- Modul, das jedoch anscheinend nur wenig verwendet wird. Es gibt keine Bestätigung, dass es mit Suchmodulen von Drittanbietern wie der Such-API funktioniert oder weiterhin funktioniert (es wurde unter Berücksichtigung der Drupal-Kernsuche entwickelt). Edit: sieht in D7 im Allgemeinen auch nicht zu zuverlässig aus .
- Es ist theoretisch möglich, einem Taxonomie-Vokabular ein Begriffsreferenzfeld mit dem Namen "Synonyme" hinzuzufügen und dieses Feld aus dem Begriff in der Such-API mit der gleichen Gewichtung wie den Begriff auf dem Knoten selbst zu indizieren. Dies würde für die Textsuche funktionieren, fühlt sich jedoch eher wie eine flache MacGuyver-y-Klebebandlösung an als wie etwas Robustes, das sich nahtlos in die gesamte Search API-Familie einfügt. Wenn zum Beispiel ein Begriff "Großbritannien" das Synonym "Großbritannien" hat, würde jemand, der nach "Großbritannien" sucht, Ergebnisse erhalten, die mit United Kindgom markiert sind, aber jemand, der "Großbritannien" in einen automatisch vervollständigten Taxonomie-Exposed-Filter eingibt oder Großbritannien mit einem Taxonomie-Fakt auswählt würde keinen mit "United Kingdom" getaggten Inhalt sehen. *****
- Eine andere ähnliche Möglichkeit besteht darin, dem Begriff Vokabular ein mehrwertiges Klartextfeld "Synonyme" hinzuzufügen (oder, glaube ich, sogar durch Kommas getrennt) und es mit derselben Gewichtung wie den oben genannten Begriff zu indizieren. Dies hat jedoch ähnliche, wenn nicht sogar schlimmere Probleme wie oben im obigen Beispiel. "Großbritannien" würde nicht einmal als Option in einer Facette oder einem belichteten Filter aufgeführt. Es könnte eine Möglichkeit geben, ein zusammengesetztes Feld zu erstellen, indem Sie Namen und Synonyme kombinieren ("Vereinigtes Königreich (Großbritannien)") und Facetten / exponierte Filter / usw., um dies zu verwenden ... aber ich kann mir keine Möglichkeit vorstellen Um dies zu tun, ist das nicht besorgniserregend und das fühlt sich nicht besorgniserregend gegen den Strich an. Bearbeiten: Search API Combined scheint für so etwas wie dieses entwickelt, aber ich '
- Dann gibt es die letzte Möglichkeit, einfach alles in den Termnamen zu packen: Es sollte klar sein, dass dies nicht wünschenswert ist und in vielen Fällen zu sehr hässlichen Listen führen würde (stellen Sie sich beispielsweise eine Navigationsliste von Ländern vor, die wie "Norden" geschrieben wurden Korea (VR China, DVRK, Demokratische Volksrepublik Korea) "...). Oder ein "Anzeigename" -Feld, in dem die Kurzversion angezeigt wird, und das alles außer der Suche festlegt (alle Ansichten, Pathauto, jedes andere Contrib / Core-Modul, das den Termnamen verwendet), um dies anstelle des Termnamens zu verwenden. sehr hackig und sehr gegen den Strich.
- Apache Solr verfügt über eine Synonymfunktion, bei der eine Textdatei mit Synonymen gelesen wird und diese Begriffe bei allen Suchen, die sie verwenden, als synonym behandelt werden. Obwohl dies in einem Such-API-Setup möglich ist, das Solr verwendet, wird dies von den Modulbetreuern als nicht unterstützte erweiterte Solr-Konfiguration "Versuch auf eigenes Risiko" angesehen . Außerdem ist es besser geeignet, generische Synonyme in der Sprache der Site zu verwenden als Synonyme speziell im Kontext einer Taxonomie. Beispiel: Eine Site mit einer Taxonomie, die England, Schottland usw. nicht von Großbritannien unterscheidet, möchte sie möglicherweise auch im Kontext des Markierens, aber nicht im Kontext der Suche nach Texten berücksichtigen. Bearbeiten: Der Head-Facet-API-Betreuer warnt vor dieser Route as Solr-Integrationsmodule arbeiten mit Begriffen wie TIDs und nicht mit Text.
Mir ist bewusst, dass dies ein fehlerhaftes Beispiel ist, da im Fall von Großbritannien und anderen Ländern die Leute es gewohnt sind, Listen zu verwenden, die nur das eine oder das andere haben. Es gibt viele weniger einfache Fälle (z. B. Produktkategorien), in denen die Leute nicht daran denken würden, nach einem Synonym zu suchen.
Update: Relevante Informationen in einem neuen Thread in der Drupal.org Facet API-Warteschlange . Außerdem ein (derzeit nicht beantworteter) Thread in der Such-API-Warteschlange .
(Alle Anwälte, die sich fragen, ob es in Ordnung ist, Supportanfragen für drupal.org zu stellen, und Drupal beantwortet Fragen zum gleichen Thema: Ja, es ist in der Tat ratsam, die Modulbetreuer zu entlasten. )