Re: [sdx-users] affichage alphabétique d'un e liste de terme sur un champ

[Pierrick Brihaye]

Re,

Frédéric Glorieux a écrit :

> > Mmmh... je suis en train de me bagarrer là-dessus avec les 
> > développeurs d'eXist :-)) Ma religion est faite : pourquoi faire 
> > porter à du code qui se veut générique une politique d'indexation qui 
> > ne sert pas les objectifs de la politique de requête ?
>
>
> Je ne sais pas si je suis avec ou contre toi,

T'as pas intérêt ;-))))

> pour moi, un index doit 
> contenir "Architecture -- Bâtiment cultuel -- Église", c'est au code à 
> rendre (ou ne pas rendre) le terme à ceux qui cherchent "église".

Je ne suis pas d'accord : on parle de l'index, la chose qui apporte de 
la performance *en dernier ressort* : si on négocie, on la perd ipso facto.

Autant je suis d'accord avec toi sur ce type d'analyse lors d'une 
expansion de requête, autant je pense que si l'on cherche à récolter ce 
qu'il y a dans l'index, on doit aller vite.

> Cela signifie aussi que "architecture -- bâtiment cultuel -- église" 
> (sans majuscules) constitue un autre terme (qui en l'occurence pourrait 
> faire doublon).

Ceci peut être (plus ou moins facilement) résolu dans le cadre d'une 
expansion de requête... on gère les quelques termes de la requête avant 
d'attaquer les nombreux termes de l'index.

> > > Attention, je ne sais pas ce que cela donne avec de l'arabe ou autres 
> > > langues pour laquelle toLowerCase() n'est pas précisément implémenté.
> >
> >
> >
> > C'est implémenté ne serait-ce que parce que que c'est du Java 
> > standard. Mais en arabe... c'est kif-kif :-)
>
>
> Merci JAVA

Ou, plutôt, Unicode.

>  > De plus, ne pas oublier que, pour les champs non
>  > tokenisés, l'espace *peut* être significative :
>  > "cul de sac" peut
>  > représenter un seul token...
>
> C'est le problème que peuvent rencontrer des applications en 
> fonctionnement. J'ai implémenté l'usage des guillemets, mais cela casse 
> les applis qui par exemple fonctionnait sur des choses comme
>
> Architecture*
> Architecture -- Bâtiment cultuel*
>
> (pour par exemple présenter des thesauri hiérarchiques).
>
> Il faudrait alors ajouter des guillemets quand il y a des espaces

Plus compliqué encore dans le cadre d'analyseurs renvoyant plusieurs 
tokens sur la même position. Voir :

http://www.nongnu.org/aramorph/french/lucene.html ;-)
http://svn.apache.org/viewcvs.cgi/lucene/java/trunk/src/test/org/apache/lucene/search/TestPositionIncrement.java?rev=150585&view=markup

> > C'est une idée, mais, d'une façon plus générale, il faudrait offrir 
> > les mêmes possibilités que l'on a pour les requêtes (et, ou, sauf à 
> > partir d'une "baseQuery"). 
>
> A faible coût, on peut probablement implémenter
> le "et" et le "non" de cette manière
>
> +Architecture* -"*bâtiment cultuel*" +*roman*

Mmmmh... <sdx:term> va carrément dans l'IndexReader et, de là, il peut 
renvoyer une TermDocs. A partir de là, on peut combiner (plus facile à 
écrire qu'à coder, je sais :-)

> Attention tout de même de ne pas implémenter trop de choses, on se 
> tromperait a confondre liste de termes et base de documents.

Oui !

A+

p.b.