sdx-developers
[Top][All Lists]
Advanced
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [sdx-developers] Le developpement de SDX

From: Frédéric Glorieux
Subject: Re: [sdx-developers] Le developpement de SDX
Date: Fri, 04 Feb 2005 11:51:14 +0100
User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)
Ok. Le composant indexeur dans org.apache.cocoon.components.search permet de spécifier des noms de balises dans le document indexé qui seront stockés dans des champs particuliers.
Au bout d'un temps cela tient du hack ? Autant préparer d'avance une vue d'indexation propre ? En XML réel (ex:docbook), les tests pour remplir un champ peuvent être très conditionnels. Prenons le champ sujet 

<http://www.docbook.org/tdg/en/html/subjectset.html>
<http://www.docbook.org/tdg/en/html/keywordset.html>

Comment en tirer parti sans une bonne XSL ?

> mais c'est vrai que des utilisateurs "hard-core"

Un exemple vraiment pas hard-core

title   : Bien indexer du XML
body    : {du texte brut}
Je voudrais pour le moins pouvoir chercher tous les articles ayant "XML" dans leur titre (indexation "tokenized"), et retrouver l'article avec valeur exacte "Bien indexer du XML", sans compter que j'aimerai pouvoir choisir un analyseur par langue, voir par genre de champs.
Un exemple utile d'analyseur non standard ? Google a 8 milliard de pages, il réponds *presque* toujours quelque chose, mais les sites réels répondent plus souvent "pas de document trouvé" que quelque chose. D'où le besoin d'augmenter les potentialités de trouver, soit en élargissant la requête utilisateur, soit en élargissant l'indexation. Ainsi on peut avoir un champ "titre" un peu blob où le mot "indexer" est élargi avec un thesaurus ou un algorytme pour contenir "indexation", "index", "lucene" ou quelques autres convenant au champ sémantique de la collection. 




Effectivement. Merci pour la clarification !


Depuis des mois j'ai sur mon bureau ceci

<http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105974910314556&w=2>
C'est un étudiant qui est passé voir SDX, a trouvé cela un peu lourd, est parti sur son projet pour des travaux d'études. 

Ce n'est pas exactement le design que je souhaite, mais l'idée est là.

Dans un pipe de publication d'un article, j'arrive à un moment à cette étape

<madtd>
  <title>Bien indexer du XML</title>
  <body>...</body>
  <lucene:document>
    <lucene:field name="id"></lucene:field>
<lucene:field name="title" tokenize="true">Bien indexer du XML</lucene:field> <lucene:field name="title_" tokenize="false">Bien indexer du XML</lucene:field> <lucene:field name="title_expanded" tokenize="false">indexer, indexation, lucene, moteur de recherche, XML</lucene:field> 

  </lucene:document>
</madtd>
Un transformeur d'indexation attrape en passant ce qui le concerne (<lucene:*/>) et va créer/mettre à jour le/les enregistrements lucene concernant cette source XML.
Pour les documents supprimés, je propose les requêtes d'administration (topujours l'expérience SDX). Des résultats de recherche normaux, avec pour chaque enregistrement des boutons delete/update (update=détruit le doc lucene si son pipe de publication cocoon ne réponds plus), et en tête, deleteAll/updateAll (pour administrateur averti qui sait ce qui s'est passé dans son index, genre supprimer sur une date ou un auteur). Un chron peut mettre à jour l'index en faisant une requête qui trouve tous les docs et les passe en revue pour voir s'ils répondent (injouable pour nos index à plus d'1 million d'enregistrements mais tout à fait adapté à un CMS tout automatique). Evidemment tout est plus simple si l'entrée/sortie des docs est contrôlée par l'appli. 

--frédéric
reply via email to
[Prev in Thread] Current Thread [Next in Thread]