dev@xmlfr.org : liste de discussion des développeurs du site XMLfr
[dev@xmlfr.org] Re: Première(naïve) pr oposition d'utilisation de Lucene
From: Frédéric Glorieux (frederic.glorieux@ajlsm.com)
Date: 28/06/2004 - 09:07
> 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
>>
> 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 ?
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.
> 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).
>
> 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é.
> 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.
--
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
|
