Re: [sdx-users] indexation et controle de l'index par un lexique ou un thésaurus

[Pierrick Brihaye]

Bonjour,

> hmm. ok , donc SDX ne gere pas ..

Il laisse gérer, nuance : ça fait précisément partie du design.

> un langage comme XSLT pour gêrer cela.. hmm je ne maitrise pas trop ce
> langage..

Dans ce cas, le déploiement SDX risque d'être délicat :-)

> mais je me demande, dans le cas ou le thésaurus atteint plusieurs
> milliers de mots si c'est vraiment la meilleure solution en terme de
> performance

On parle bien d'indexation ? Dans ce cas, pourquoi rechercher de la
performance ? Tout le monde veut de la performance partout et tout le temps
mais, IMHO, ce n'est pas là qu'il faut la chercher en priorité...

> mais bon d'un point de vue conceptuel, c'est pas beau :

Les gôuts et les couleurs : moi, je trouve cette liberté d'approche
extraordinaire !

> normalement c'est lucene qui s'occupe "d'indexer" (analyse+ stockage dans
> base index),

Conceptuellement, ça me gêne un peu : l'indexation de haut niveau est
confiée à une XSLT (bien) et celle de bas niveau à Java. Je verrais bien un
filière tout-XML pour faire ça (et j'ai ma petite idée là-dessus).

> SDX ne fournie qu'une vue d'un document par "transformation"
> XSLT, cette vue n'a pas pour objectif "l'analyse" du document.

1) SDX fournit autant de vues qu'on veut : il suffit d'avoir autant de bases
de documents derrière pour les stocker.
2) la vue d'indexation est à finalité libre : analytique, synthétique,
apocalyptique.. :-)

> le concept SDX de dissocier l'information à indexer de l'information du
> document et de dire que ces informations peuvent être à priori
différentes.
> mais à aucun moment il est question d'analyse et de réduction en concepts
du
> document originale..

Pourquoi pas ? Si votre document original et votre vue d'indexation
s'y prêtent ?

> Biensur cette transformation pourrait servir d'analyse : après tout tout
ce
> que lucene fait (elimination sens vide, minuscule, accents) pourraît etre
> fait par une feuille XSL mais dans ce cas la Lucene ne sert que de
> stockage.. ce qui est dommage et perd de la performance dans l'analyse
(perf
> XSLT<java)

Entièrement d'accord. Mais je le répète : ce besoin de performance en
indexation me paraît marginal au regard des autres besoins (fonctionnels
notamment).

> je pensais plutôt intégrer cela au niveau de Lucene , dans un Analyser ,
en
> tant que Filter ce qui me paraît plus propre, plus réutilisable non ?

Pas sûr : j'en veux pour preuve le nombre réduits d'analyseurs Lucene
fournis en standard... Comme quoi le concept semble loin d'être unanimement
partagé :-)

> Avez vous déjà eu le besoin de classer des documents par catégories ?

Oui. Je pense même que c'est un besoin qui se manifeste assez vite, non ?

> si oui, comment avez vous procédé ?

On met des champs brief qui contiennent l'info de "hiérarchisation" et on
filtre/trie dessus.

> Avez vous un réseau sémantique des différents catégories (thésaurus ou
> autre) pour gerer les categories

Avec les champs que je viens de décrire, c'est très simple à mettre en
oeuvre (comparable à l'exemple donné).

[snip]

A bientôt,

p.b.