dev@xmlfr.org : liste de discussion des développeurs du site XMLfr
[dev@xmlfr.org] Re: Première(naïve) proposition d'utilisation de Lucene
From: Eric van der Vlist (vdv@dyomedea.com)
Date: 28/06/2004 - 09:31
Bonjour,
On Mon, 2004-06-28 at 11:07, Frédéric Glorieux wrote:
> > http://dev.xmlfr.org/cgi-bin/viewcvs.cgi/xmlfr-beta/sources/org/xmlfr/lucene/
>
> Premier point, j'ai reçcu cela de l'URL, information utile ?
>
> <<
> An Exception Has Occurred
> Python Traceback
>
> Traceback (most recent call last):
> File "/usr/lib/python2.1/viewcvs/viewcvs.py", line 3088, in main
> request.run_viewcvs()
> File "/usr/lib/python2.1/viewcvs/viewcvs.py", line 252, in run_viewcvs
> self.rootpath, rev)
> File "/usr/lib/python2.1/viewcvs/__init__.py", line 233, in __init__
> RuntimeError: Berkeley DB error while opening environment for filesystem
> /home/redacteurs/svn/db:
> DB_RUNRECOVERY: Fatal error, run database recovery
> >>
Je viens de réparer la base de données et cela devrait aller mieux!
>
> > Un petit bout de code vaut mieux qu'un long discours
>
> J'espère que cela m'autorise à discourir encore un peu avant de coder ?
Bien entendu!
> Ceci dit je me met à intégrer un Lucene plus proprement dans cocoon.
>
> L'indexeur par défaut vient de cette démo
> http://cvs.apache.org/viewcvs.cgi/jakarta-lucene-sandbox/contributions/XML-Indexing-Demo/
> manifestement un peu vieille, et qui repose sur l'idée que les noms
> d'éléments et d'attributs sont pertinents pour définir des champs de
> recherche.
Pour ma part, je suis parti pour l'instant sur l'idée d'une intégration
de Lucene sur XMLfr tel qu'il est aujourd'hui et n'ai pas utilisé
l'intégration Cocoon.
> > J'ai voulu proposer quelque chose de plus léger que les pipelines
> > d'indexation de SDX et l'indexeur (XmlAnalyser.java) est écrit sous
> > forme d'un récepteur SAX paramétrable de la manière suivante :
>
> Tout cela est très dans l'environnement SDX, par contre la logique a du
> bon. L'idée est qu'une indexation est une vue spécifique sur un
> document. On ne précipite pas une hiérarchie XML dans un modèle à champs
> sans un peu de préparation (= 1 XSL). Par exemple, un titre peut
> résulter d'une concaténation de plusieurs éléments.
>
> De plus, l'auteur de cette transformation d'indexation sait si
> l'information qu'il envoit doit être
>
> analysée (termes pour le plein texte) ou indexée brute (mot clés, URI...)
> cherchable ou non indexée
> non stockée ou rendue dans des résultats brefs
>
> Par exemple, il s'avère très utile d'avoir des titres ou des auteurs
> indexés, à la fois en analysé (pour recherche plein texte), mais aussi
> en brut (pour des recherche exactes, à partir d'une liste générée de
> titres par exemple).
Mon idée à ce niveau est de conserver l'index XMLfr tel qu'il fonctionne
aujourd'hui et de consolider les deux fonctions (index et moteur de
recherche).
Il faut également dire que sur XMLfr, nous n'avons (en tout cas pour
l'instant) pas une grande diversité de type de documents puisque nous
avons essentiellement des documents NITF et leur résumé en RSS.
> >
> > Pour l'instant, il s'agit de deux utilitaires ligne de commande (Indexer
> > et Search) qui permettent respectivement d'indexer un jeu de documents
> > XML au format NITF et d'effectuer des recherches.
> >
> >
> > mappings.put("/nitf", new FieldType("contenu", FieldType.UNSTORED));
> > mappings.put("hedline/hl1", new FieldType("titre1", FieldType.TEXT));
> > mappings.put("hedline/hl2", new FieldType("titre2", FieldType.TEXT));
> > mappings.put(
> > "dateline/story.date/chron/@norm",
> > new FieldType("date", FieldType.DATE));
> > mappings.put(
> > "dateline/story.date/@norm",
> > new FieldType("date", FieldType.DATE));
> >
> > Ces instructions indiquent que tout les textes sous l'élément "/nitf"
> > seront indexés dans un champ de type "UNSTORED" appelé "contenu", que
> > les textes sous les éléments hedline/hl1 et hedline/hl2 seront stockés
> > dans des champs de type TEXT nommés respectivement "titre1" et "titre2"
>
> Sur vos champs titre1 et titre2, je ne sais pas si beaucoup de gens
> feraient la distinction de chercher dans titre ou sous-titre (c'est bien
> la sémantique ?
> <http://www.nitf.org/IPTC/NITF/3.2/documentation/nitf-documentation.html#hl1>),
> personnellement je me suffirais d'un champ titre répété.
En fait, j'utilise hl1 comme un titre RSS ou Dublin Core et hl2 comme
une description RSS ou Dublin Core. On pourrait donc également appeler
ces champs "titre" et "description".
> > et que les attributs dateline/story.date/chron/@norm et
> > dateline/story.date/@norm seront stockés dans des champs de type DATE
> > nommés "date".
> >
> > Les chemins sont du simili XPath (je ne me suis pas (encore?) ennuyé à
> > supporter les espaces de noms).
>
> Je ne vous conseillerai pas d'aller si loin, selon la logique exposée
> plus haut.
> >
> > Ce paramétrage doit pouvoir être relativement facilement étendu pour
> > indexer les documents RSS dans lesquels sont stockées les brèves.
>
> Il me semble que chaque brève aurait intérêt à être indexée comme un
> document à part entière. Par contre, cela pose le problème de la
> pertinence des documents courts. Mais ceci peut peut-être se corriger en
> "boostant" les documents longs, ou mieux encore, trouver un coefficient
> selon la longueur. Mais sur ce point je n'ai pas d'expérience concrète.
C'est un des points, discuté sur la liste redacteurs@xmlfr.org, qui est
le déclencheur de l'évaluation de Lucene : avec Lucene, on peut indexer
des fragments de documents aussi bien que des documents à part entière
et, finalement, le fait de stocker une brève par document ou uniquement
comme des fragments devient un détail d'implémentation.
Dans les deux cas, la brève est indexée comme une entité à part entière.
Et c'est ce que j'ai voulu vérifier dans la deuxième version de mon
indexeur.
Quant à booster les résultats des documents longs, je pense que cela
pose le problème du tri des résultats qui est effectivement une question
délicate!
Merci,
Eric
>
--
See you in Portland.
http://conferences.oreillynet.com/os2004/
Upcoming XML schema languages tutorial:
- Portland -half day- (27/07/2004) http://masl.to/?E6ED13728
------------------------------------------------------------------------
Eric van der Vlist http://xmlfr.org http://dyomedea.com
(ISO) RELAX NG ISBN:0-596-00421-4 http://oreilly.com/catalog/relax
(W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema
------------------------------------------------------------------------
--
Devenez redacteur <XML>fr et contribuez au developpement du
xml francophone (http://xmlfr.org/infos/redacteurs/) !
Liste de diffusion "dev@xmlfr.org" (http://xmlfr.org).
Cette liste est a votre disposition pour discuter en francais de
tout sujet technique lie au developpement du site XMLfr.
Pour resilier votre abonnement, envoyez un message contenant
la commande "unsubscribe" a dev-request@xmlfr.org
(mailto:dev-request@xmlfr.org?Subject=unsubscribe)
Archive générée par hypermail 2.1.3 le 28/06/2004 - 21:32 UTC
webmaster@xmlfr.org
|
