ICUFoldingFilterではなく、MappingCharFilterを使用することで解決できます。

そこでは、マッピングファイルを提供し、ユーザーの母国語の基本文字のマッピングをスキップすることができます。なぜなら、彼ら自身の言語では、正しいスペルを知っているからです...ほとんどの場合...時々。

これは複数の言語で本当に役立ち、ICUFoldingFilterの便利さを失う代わりに、助けになります。

André

こんにちは、Janさん、

ICUFoldingFilterやASCIIFoldingFilterは、私が最後に確認したときにはkeyword=true属性を尊重しないと思います。KeywordRepeatFilterを使用して、上記のTokenFiltersをkeyword属性を尊重するように変更すれば、問題が解決されるように思います。

よろしくお願いします。

Markus

いい方法ですね。ただし、私たちは後でステミングを使用しているため、すべての元の用語がチェーン全体で残るわけではなく、ICUフィルターによって変更されたトークンだけが元のトークンも出力することを望んでいます。

入力：Genéve
LCF：genéve
ICU：genéve geneve
STEM：genév genev

クエリ：Genève -> (genéve OR geneve) -> (genév OR genev) ==> 'Geneve'単体よりも、両方の用語に一致し、より高いスコアを得ます。

これはでっち上げの例であり、固有名詞にステミングを適用するのはひどい考えですが、アイデアは理解できます。preserveOriginalフラグがあれば解決されたでしょう。

Jan

こんにちは、

フィンランドのユーザー向けに、問題を緩和するために一部の文字の変換を避けています。MappingCharFilterと共にこれを使うと、かなりうまく機能します。https://github.com/NatLibFi/finna-solr/blob/dev/vufind/biblio/conf/schema.xml#L7 を参照してください。あなたのユースケースに応じて、これも解決策となるかもしれません。フィルターパラメータが常にそこにあったわけではないので、最新のSolrバージョンが必要です（正確なバージョンを思い出せません）。

Ere

こんにちは、

ご意見ありがとうございます。私たちはすでに、æøåäöを保護するためにフィルターパラメータを使用しています。もちろん、éやôも正規化に対して保護することができますが、これはかなり広範囲になり、利点の大部分が消えてしまいます。もしフィルターが例外用のプロトワーズリストをサポートしていれば、衝突することが確実な単語を集めて、それらを除外することができます。ただし、完全一致のランクブーストアプローチの方が柔軟性があるように思われます。

Jan

こんにちは、

わかりました。

完全一致のブーストを実現するには、やはり異なる解析チェーンで別のフィールドにインデックス化する必要があるのでしょうか？私はこれについて経験が足りないかもしれませんが、元の用語に高いブーストを与える方法が見当たりません。また、フィルターが正しく動作するためには、位置などの情報を考慮したグラフフィルターである必要がありますか？

ICUFoldingFilterにprotwordsのサポートを追加することは比較的簡単だと思いますが、特定の文字に対して一部の単語のみ完全一致を要求する場合に、ユーザーの観点からの潜在的な不整合に懸念があります。

Ere

フィールドの複製は最後の手段です。
私の提案は、同じ位置にシンプルな用語の積み重ねです。ICUフィルターは決して異なる数の用語を出力しないため、グラフは必要ありません。
元の用語のブーストを完全に制御する必要はありません。元の用語と正規化された用語の両方に一致するドキュメントが高いスコアを取得するだけで十分です。通常、IDFが高いため、多くの場合、元の用語のスコアがわずかに高くなります。

Jan

説明してくれてありがとう。

二つのトークンフィルタを呼び出し、その結果をマージするだけのトークンフィルタを作成することが可能かどうか疑問です。それは本当に強力で、他の状況にも対応できるかもしれません。

Ere