sdx-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Pierrick Brihaye
Subject: Re: RE : RE : [sdx-developers] Etat des questions
Date: Wed, 12 Nov 2003 10:26:34 +0100
User-agent: Mozilla/5.0 (Windows; U; Win98; fr-FR; rv:1.0.2) Gecko/20030208 Netscape/7.02

Salut,

Rasik Pandey a écrit:

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 (?)

Ce qui n'est pas normal IMHO. Si le QueryParser de Lucene utilise des analyseurs, il *doit* pouvoir gérer *tous* les analyseurs qui respectent le contrat fixé par la classe TokenStream.

Or, TokenStream renvoie des Token et ces tokens peuvent avoir un PositionIncrement != 1 donc... le QueryParser de Lucene ne respecte *pas* ce contrat :-(

Ils auraient pu faire autrement en ayant des callbacks qui auraient donné tout le travail aux dévelopeurs ; ça ne m'aurait pas gêné...

Le problème, c'est qu'en déclarant Query getFieldQuery(String field, Analyzer analyzer, String queryText) protected, ils nous obligent à réécrire toute cette méthode en restant dans le package :-(

> Ceci dit,
rien ne t'empêche de faire un surchargement du DefaultQueryParser comme
ArabicQueryParser, AggluinateQueryParser

Mon problème serait plutôt un ZeroPositionIncrementTokenQueryParser :-) Au stade d'analyse de la *query*, on n'a plus de dépendance à la langue (qui, elle, est gérée par un analyseur) mais aux tokens...

>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?

Oui.

La construction d'une requête est dépendante sur des analyseurs, non?

Oui. Le problème c'est que le QueryParser construit des PhraseQuery même si l'analyseur lui dit de faire autre chose :-) C'est exactement ce qui se passe avec l'analyseur arabe.

Ce qui me gêne dans Lucene, c'est que la notion de slop est totalement sous-utilisée. En effet, il n'a pas de notion de sens : un slop de 10, c'est un slop de -10 ou de +10.

Si c'était bien utilisé, on pourrait mapper une PhraseQuery en une SlopQuery de +1.

Avec de vraies SlopQuery's on pourrait faire matcher :

"Is Lucene nice ?"
avec
"Lucene is nice"

Les perspectives de recherche documentaire seraient diaboliquement augmentées !

A+

--
Pierrick Brihaye, informaticien
Service régional de l'Inventaire
DRAC Bretagne
mailto:address@hidden





reply via email to

[Prev in Thread] Current Thread [Next in Thread]