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.
_______________________________________________
sdx-users mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/sdx-users
