Re: [sdx-users] analyzerConf?

[Pierrick Brihaye]

Re,

Emmanuel Bégué a écrit :

> Mais aujourd'hui on a bien un analyseur par défaut par base,
> et je pense que l'analyseur par défaut pour l'application est
> celui de la base par défaut: ne peut-on pas continuer ainsi mais
> en permettant, en plus, un analyseur par document?

Un analyseur par document rendrait quasiment impossible une requête sur 
un jeu de documents, non ?

> (Et à la limite, on pourrait stocker dans un champ sdx spécifique
> l'analyseur utilisé pour chaque document, ce qui permettrait, si
> on le souhaite, de restreindre la recherche aux documents analysés
> avec tel analyseur (par défaut, tous, ou par défaut celui de la
> requête en cours...?)).

A la rigueur : mais ça induirait un filtrage préalable qui boufferait la 
performance.

> (En fait dans le cas précis qui a motivé ma question, on a un corpus
> en français avec moins de 1% des documents dans d'autres langues:
> anglais, allemand, espagnol; créer des bases différentes pour
> ces quelques cas particuliers semble très compliqué...)

Pourquoi ne pas créer des champs comme indiqué par Martin ?

> Par ailleurs est-il vraiment logique d'utiliser le même analyseur
> pour la requête que celui qui a été utilisé pour l'indexation?

A priori, c'est la meilleure façon de chercher ce qu'on a indexé, non ?

> En
> restant dans une même langue, on pourrait considérer le fait d'indexer
> sans mots vides et de décider, au moment de la recherche, de prendre
> les mots vides en compte ou non, selon ce que l'on cherche...?

Mmmh... un analyseur peut faire beaucoup plus d'autres choses que de 
filtrer des mots vides : il tokenize, il "normalise" (stemming p.e.) et 
il positionne.

> J'ai le cas avec une application qui contient beaucoup de noms de lieux;
> si on cherche un nom de lieu, la préposition "sur" est très importante:
> mais si on cherche un autre document du même corpus, c'est bien un mot
> vide qui peut amener du bruit...

La solution théorique est de pouvoir identifier tes noms de lieux et de 
les mettre dans un hchamp (probablement non analysé) ad hoc.

A+

--
Pierrick Brihaye, informaticien
Service régional de l'Inventaire
DRAC Bretagne
mailto:address@hidden
+33 (0)2 99 29 67 78