RE : RE : [sdx-developers] Etat des questions

[Rasik Pandey]

Salut,

 >
 >>En fait, tu voudrais faire une expansion de la requête avec ton 
 >>analyseur.
 >
 >On peut effectivement le voir comme ça. Ceci dit, il faut 
 >voir ce qu'on entend pas une "expansion". Pour moi, ça 
 >consiste à *ajouter* des termes. Exemples :
 >
 >On a un outil qui permet de retrouver "mice" si "mouse" est 
 >donné : mouse || mice Ou un thésaurus qui permet de trouver 
 >des spécifiques ; si "country" est donné, on va avoir : 
 >country || France || USA
 >
 >Dans les 2 cas, on recherche bien un terme "de base" et on 
 >lui adjoint N autres termes.
 >
 >Or, en arabe (ou dans quelques autres langues qui seraient 
 >susceptibles de subir un traitement identique), on ne 
 >recherche *pas* le terme de base. Celui-ci n'existe que comme 
 >"point d'entrée" pour trouver d'autres termes qui ont une 
 >forme plus "canonique". Ca offre d'ailleurs des perspectives 
 >très intéressantes sur ce que l'on pourrait considérer comme 
 >une analyse performante ; j'en reparlerai...

Ok.

 >> Je ne suis pas d'accord que le QueryParser est le bon endroit.....?
 >
 >Moi je veux bien mais le QueryParser de Lucene faisant bel et 
 >bien appel à des analyseurs de champs (ça sera encore mieux 
 >avec Lucene 1.3 et ses "per-field" analyzers), je ne vois pas 
 >pourquoi on ne pourrait pas bénéficier de cette possibilité.

 >De plus, le but de ce QueryParser est bel est bien de 
 >renvoyer des Query "atomiques". Un processus d'expansion (ou 
 >de transformation) différé contreviendrait à cet objectif IMHO.

Le QueryParser standard de Lucene ne prend pas en compte la construction
des requête avec des analyseurs complexe comme ton analyseur Arabe parmi
des autres (?) et je ne pense pas qu'il doit gérer ces cas.  Ceci dit,
rien ne t'empêche de faire un surchargement du DefaultQueryParser comme
ArabicQueryParser, AggluinateQueryParser, etc. Ca sera plus propre et
plus facile à déboguer?


 >J'ajoute que Erik Hatcher a reconnu que les tokenPosition 
 >égaux à 0 lui paraissent pertinents et que l'on peut donc 
 >s'attendre à ce que le QueryParser standard de Lucene intègre 
 >cette préoccupation (je peux leur envoyer le patch quand j'en 
 >aurai fini avec les quelques problèmes qui restent).

Tu parles du Thread "positional token info" sur Lucene users? 

La construction d'une requête est dépendante sur des analyseurs, non? Vu
que les analyseurs pourraient différés d'un cas à l'autre tu penses
qu'il y a une approche pour des cas assez générique qui pourraient être
gérer dans le QueryParser standard de Lucene ou au moins
DefaultQueryParser de SDX sans trop compliquer l'architecture?

 
 >C'est un gros point de doctrine : la discussion est ouverte :-)
 
On continue doucement....


Rasik