Re: [sdx-users] sdxall:1 et hilite

[Pierrick Brihaye]

Bonjour,

Marjorie Burghart a écrit:

> Une idée pour éviter ça ?

A vrai dire, je ne vois pas l'intérêt de surligner quand le champ de 
recherche est une "métadonnée SDX" (comme sdxdocid, sdxall...) car ces 
métadonnées ne proviennent pas a priori du document. Peut-être 
faudrait-il moduler l'utilisation systématique de "true" dans l'attribut 
highlite ?

Quoi qu'il en soit, la problématique est diablement complexe car :

1) Lucene ne nous offre pas d'API simples pour retrouver simplement les 
termes utilisés par une Query. La version livrée par SDX est un patch 
(apparemment incompatible avec la version actuelle de Lucene : 1.3RC1).

2) Il est par définition impossible de faire un mapping entre un 
document d'origine car XSL ne conserve que rarement la structure (quel 
en serait l'intérêt ?). SDX utilise la flux SAX du document et, 
lorsqu'il rencontre une valeur de terme issue de la query, il la 
surligne. On surligne ainsi tous les 1 si la query est sdxall:1... pour 
le meilleur et pour le pire.

Note : distinguer "terme" = champ + valeur de "valeur de terme". SDX 
surligne des *valeurs*.

Les solutions sont complexes mais relativement simples à énoncer :

1) il faudrait que Lucene soit capable de restituer facilement des 
listes de termes. En gros, il y a 2 écoles :

a) on va associer la liste de termes à la requête. Rapide (car une 
requête bâtit naturellement une liste de termes à rechercher)  mais 
gourmand en mémoire : un terme reste en mémoire même si on n'en a plus 
besoin par la suite.
b) on va associer la liste de termes au résultat. On n'a que les termes 
pertinents mais leur recherche est longue.

Il y a eu de gros débats sur la liste lucene-dev au mois de mars 
là-dessus mais rien de concret n'a abouti :-(

2) quelle que soit la façon de retrouver les termes, en ce qui concerne 
le surlignement du document, il faudrait passer par une 
*retransformation* du document et mapper les termes trouvés sur les 
noeuds du document d'origine, probablement grâce à XPointer.

C'est lourd mais c'est le prix à payer pour un surlignage "pertinent". 
Ca pose également le problème de ce que fait réellement le pipeline 
d'indexation. D'aucuns s'en servent pour faire autre chose que de 
l'indexation. Relancer ce pipeline tel quel pourrait donc avoir des 
circonstances impévues...

Pour terminer : existe-t-il des processeurs XSLT capables de générer un 
tel mapping entre un document et sa transformation ?

A bientôt,

--
Pierrick Brihaye, informaticien
Service régional de l'Inventaire
DRAC Bretagne
mailto:address@hidden