Re: RE : [sdx-users] l'affectation d'un analyseur lucenedynamiquement

[Pierrick Brihaye]

Bonsoir,

>> > Est-il possible d'affecter un analyseur lucene dynamiquement
>> > au momemt de
>> > l'indexation d'un champ d'un document?
>>
>> Non.

>Dommage ;-)

La raison est simple : l'unité atomique chez Lucene est le document. Cf. la
formule de calcul de pertinence
(http://lucene.sourceforge.net/cgi-bin/faq/faqmanager.cgi?file=chapter.searc
h&toc=faq#q31) où les champs n'interviennent qu'à la fin du calcul...

IMHO, la meilleure solution serait donc d'utiliser plusieurs jeux d'index et
donc, dans la terminologie SDX, plusieurs bases de documents. V. mes
contributions sur cette liste pour d'autres bonnes raisons de pouvoir gérer
facilement plusieurs bases et, le cas échéant, d'autres moteurs d'indexation
;-)

>Ce que je voulais dire par dynamiquement, c'est la possibilité de
>détecter la langue d'un attribut du champ et pas uniquement de xconf ce
>qui permettrai d'imaginer des documents ayant des champs répétés
>multilingues...

Mmmh... je pense que de tels champs apporteraient plus d'inconvénients que
d'avantages (mais il y a des opinions divergentes sur cette liste ;-). Rien
n'empêche bien sûr qu'ils existent dans plusieurs bases partageant la même
structure et qu'on les interroge via un multiSearcher (sdx:locations).

A l'indexation, le gros truc est donc bien de détecter la langue d'un champ
pour savoir dans quelle BD le dispatcher. Ici, un programme peut aider :
http://frank.spieleck.de/ngram/. Mais bon, sans garanties si le texte est
court : mon test de gallois est vu comme étant du... quechua :-) Il vaut
mieux donc miser autant que faire se peut sur une résolution par la logique
applicative.

Il faudrait également revoir la façon dont se passe l'indexation. A l'heure
actuelle, c'est la base qui s'en occupe. Si l'on choisit l'approche que je
propose, ça suppose qu'on sait déjà dans quelle langue indexer ou que l'on
est prêt à perdre des <sdx:field> au passage :-( Faudrait-il donc confier
l'indexation à l'appli ? Ou confier à l'architecture actuelle un passage
dans N pipelines d'indexation qui sera gourmand en ressources ?

En ce qui concerne la requête, on pourrait appliquer le même algorithme de
détection de langue et dispatcher chaque champ vers le jeu d'index adéquat.
Mais, dans ces conditions, d'aucuns voudront éventuellement un calcul de
"métapertinence" et la construction de "méta jeux de résultats". Brrr...

>Si je cherche en fr comment:(français patrimoine architecture),
>j'attends deux niveaux de résultats :
>- Les documents qui répondent à ma requête dans la langue choisie par
>ordre de pertinence
>- Les documents qui répondent à ma requête dans d'autres langues par
>ordre de pertinence! Avec l'usage pertinent des fonctionnalités
>thésaurus, on devrait y arriver, non ?

Pas de problème a priori et ce, même dans l'architecture actuelle. Tout le
travail consiste à indexer le bon contenu au bon endroit.

PS : mes travaux sur un analyseur arabe on bien avancé. Vous devriez avoir
des nouvelles dans quelques semaines.

A+

p.b.