2.5 Suche

Die Picturepark Suche bietet 3 Suchmodi, sowie Suchvorschläge aus den Listeneinstellungen.
Wann welcher Suchmodus zu verwenden ist, wird unten erklärt.

AND Suche

Die AND Suche sucht nach Inhalten, die alle eingegebenen Suchbegriffe enthalten. Wenn Sie zum Beispiel nach “Stock shot” suchen, übersetzt Picturepark dies in Stock AND shot und sucht nach Bildern, die diese beiden Werte enthalten.

OR Suche

Bei Verwendung der OR Suche übersetzt die Picturepark Suche den Suchbegriff “Stock Shot” in “Stock OR Shot” und sucht nach Inhalten, die einen oder mehrere eingegebene Suchbegriffe enthalten.

Erweiterte Suche

Der Picturepark erlaubt eine Vielzahl von exakten, Fuzzy oder ersetzenden Suchen. Sie können auf das Cheat Sheet der erweiterten Suche mit den Beispielen unten zugreifen. Diese Suchanfragen funktionieren nur im “Advanced Mode”. Diese Suchabfragen erlauben es nach spezifischen Werten in spezifischen Feldern zu suchen auf spezifischen layern. Überprüfen Sie die individuelle syntax pro Feld.

Simple Search Analyzer

Suchanalyzer legen fest, wie Text verarbeitet oder manipuliert wird. Diese Analyzer geben Ihnen die Kontrolle darüber, wie Ihre Textdaten in der Suche verwendet werden. Ziel ist es, Text zu standardisieren, z. B. Kleinschreibung oder Umwandlung von Sonderzeichen (Diakritika) oder Behandlung von Singular/Plural in Übersetzungen (z. B. Männer, Mann). Search Analyzers sind für String- und übersetzte String-Felder verfügbar.

Simple Search Analyzer

 Zugriff in Suchanfragen: simple

Der Simple Search Analyzer ist eine benutzerdefinierte Picturepark-Implementation, die keine Elastic-Suchvorgaben verwendet. Der Custom Analyzer verwendet eine Regex:

  • Regex

    */"(\[^\\p\{L\}\\d\]+)|(?<=\\D)(?=\\d)|(?<=\\d)(?=\\D)|(?<=\[\\p\{L\}&&\[^\\p\{Lu\}\]\])(?=\\p\{Lu\})|(?<=\\p\{Lu\})(?=\\p\{Lu\}\[\\p\{L\}&&\[^\\p\{Lu\}\]\])"/*
  • Ergebnis:

    • Kleinbuchstaben/Großbuchstaben

    • Ziffern / Nicht-Ziffern

    • Stemming

    • HTML-Streifen

  • Beispiele

    • Picturepark = Picturepark, picturepark

    • Case Study = Case, Study, case, study

Wenn Sie den einfachen Suchanalysator testen möchten, können Sie Ihre Begriffe in einem Regex-Tester überprüfen, um das Ergebnis zu sehen.

  1. Öffnen Sie einen regex checker

    1. https://regex101.com/

    2. https://regexr.com/

  2. Fügen Sie Ihren Begriff als Prüfzeichenfolge hinzu

  3. Überprüfen Sie das Resultat

No Diacritics Analyzer

 Zugriff in Suchanfragen: no-diacritics

Der no diacritics analyzer:

  • funktioniert nur bei Textfeldern

  • diakritische Zeichen werden entfernt, wenn also der Textwert lautet: Kovačić Mateo können Sie nach "Kovačić Mateo" oder "Kovacic Mateo" suchen.

Ein Beispiel finden Sie in der Elastic Search Dokumentation: https://www.elastic.co/guide/en/elasticsearch/reference/current/analysis-asciifolding-tokenfilter.html

Path Hierarchy Analyzer

 Zugriff in Suchanfragen: pathHierarchy

Der path hierarchy analyzer:

  • Nimmt einen in einem Feld gefundenen Pfad (picturepark\platform\manual) und grenzt die einzelnen Begriffe ab

  • Beispiel

    • picturepark\platform\manual = picturepark\platform\manual, picturepark\platform, manual

    • Products/Family/Industry = Products/Family, Products, Products/Family/Industry

Sie sollten diesen Analyzer nur konfigurieren, wenn er über die API verwendet wird. Bei der einfachen Suche in Picturepark werden Sonderzeichen umgangen, so dass Sie bei der Suche nach einigen der von diesem Analyzer generierten Token keine Assets finden werden.
Ein Beispiel finden Sie in der Elastic Search Dokumentation:

Language Analyzer

 Zugriff in Suchanfragen: language

Für die elastische Suche gibt es mehrere Sprachanalysatoren. Sprachanalysatoren verhindern das Stemming aus sprachspezifischen Werten und sprachspezifischen Stoppwörtern.

Die aktuelle Implementierung verwendet die Standard-Analysatoren von Elastic Search Language, wie im Link aufgeführt. Wir verwenden die Standard-Stoppwörter und -Regeln für das Stemming, ohne eigene Anpassungen.

Ngram Analyzer

  Zugriff in Suchanfragen: ngram

Ausgangspunkt für exakte Teilstring-Übereinstimmungen war die ngram-Tokenisierung, die alle Teilstrings bis zur Länge n indiziert. Der Nachteil der ngram-Tokenisierung ist der große Speicherplatzbedarf.

Best practice:

  • ngram nur bei Bedarf verwenden - vorsichtig und nicht für jede Zeichenfolge verwenden

Die Einstellungen erlauben es, min und max Gramm zu definieren, die bei der Indizierung erstellt werden, und token_chars, die Zeichenklassen, die in den Token beibehalten werden sollen, Elasticsearch splittet auf Zeichen, die zu keiner dieser Klassen gehören. Beispiel: Suche "Raven"
Beispiel: Suche "Raven"

  • NGrams (splits term into tokens with one character):

  • Rav

  • Rave

  • Raven

  • ave

  • aven

  • Ven

  • ...

Beispiel: Suche "Pegasus"

  • NGrams (zerlegt den Begriff in Token mit einem Zeichen):

  • Pegasus

  • Degas

Beispiele finden Sie in der Elastic Search Dokumentation:

Bei erweiterten Suchabfragen nach analysierten Feldern kann die Abfrage so angepasst werden, dass der Analysator berücksichtigt wird.