Re: [sdx-users] mise en évidence des termes recher chés (long)

[Pierrick Brihaye]

Bonjour,

>Ce que je ne comprends pas, c'est pourquoi ces termes sont "éclatés" et
>donc donnés comme pertinents alors qu'ils ne devraient pas l'être. Je
>vais regarder le code...

Bon, j'ai regardé...

Le code SDX reprend celui proposé par Maik Schreiber
http://www.iq-computing.de/, dans un des ses articles :
ftp://www.iq-computing.de/lucene/lucene-highlight.tar.gz

Problèmes :

Ce code popose des modifications au code de Lucene : certaines ont été
acceptées et figurent dans la dernière version (1.3-RC1), d'autre non.
Plus grave, ce code (cf LuceneTools) est basé sur un ancien état de Lucene
(1.2-RC2)... qui ne dispose *plus* de la fonction "magique" utilisée par le
code !
Moralité : à moins de recoder nous-mêmes, on ne peut pas livrer une version
de Lucene up-to-date reprenant/s'inspirant du code de Maik Schreiber.

Il y a eu un débat au mois de mars avec un patch intéressant (mais pas testé
de ma part) de Tatu Saloranta :
http://www.mail-archive.com/address@hidden/msg02815.html

Ici encore, les gens de Lucene on accepté certaines des modifications...
mais pas toutes :-(

Ce code a suscité un gros débat qui peut se résumer ainsi : pourquoi
chercher à recréer une liste de termes à partir d'une query alors que, par
définition, la query a déjà utilisé ces termes ? Je me pose effectivement la
question :-)

A imaginer que l'on trouve une solution élégante, efficace, et s'accomodant
du Lucene officiel pour retrouver les termes pertinents pour la requête, il
nous faudra *en plus*, proposer une solution élégante du traitement d'un lot
de caractères (en provenance d'un élément) et, éventuellement, du traitement
des caractères d'un attribut. C'est justement là où ça coince chez toi
puisque ce lot est analysé avec l'analyseur du champ par défaut.

Il faudrait donc analyser le flux avec *chacun* des analyseurs de *chacun*
des champs de *chacun* des termes impliqués dans la requête et placer des
marqueurs là où l'analyse correspond. A la fin, on aurait un texte
complètement marqué qui permettrait la création des <sdx:hilite>. Brrr, ça
prendrait de la ressource et ça poserait le problème de l'analyse multiple
car il y a des risques d'inclusions ("la base" pour un champ field vs. "la"
+ "balle" pour un champ tokenisé) . Quoique, à vrai dire,
<sdx:hilite><sdx:hilite>la</sdx:hilite>
<sdx:hilite>balle</sdx:hilite></sdx:hilite> ne me dérangerait pas.

A supposer que ça soit soluble de cette façon, se poserait un problème
supplémentaire car, normalement, un flux de caractère SAX être tronçonnable
(on peut envoyer ls 4000 premiers caractères pendant que l'on lit les
suivants sur le disque). C'est assez simple à gérer mais, encore une fois,
ça risque de demander de la ressource.

Une autre solution, radicalement différente, serait de retransformer le
document et de mettre un marqueur sur les noeuds qui génèrent les
<sdx:field>. Tellement tordu que je m'arrête là :-)

A propos des highlites, tout est normalement disponible pour que l'on ait
<sdx:hilite field="myfield">, aussi je me demande si ça ne serait pas bien
de mettre ça dans le code : "auteur" en bleu, "titre" en rouge, "année" en
vert...

Voilà , le problème est donc le suivant : Lucene n'a pas été conçu pour
faciliter la tâche des highliters. Si l'on investit dans le code de
récupération des termes de la requêtes tout sera peut-être à refaire lors de
la prochaine mise à jour de Lucene.

Ca n'empêche pas les développeurs de refléchir au problème de la réanalyse
du contenu : ici le code devrait rester assez générique.

A bientôt,

p.b.