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 - 21:04
>>Avec un xpath, la requête permet de définir a posteriori la granularité
>>du résultat que l'on souhaite. S'il on veut les "pages" d'une thèse, ou
>>même les paragraphes, cela repose alors sur le schéma XML et surtout les
>>performances du DB:XML
> Oui. Dans mon indexeur, c'est le champ "contenu" qui identifie l'unité
> documentaire (peut-être vaudrait-il d'ailleurs mieux adopter un terme
> plus proche de "unité documentaire").
>
> lorsque j'écris :
>
> mappings.put("/nitf", new FieldType("contenu", FieldType.UNSTORED));
>
> j'indique que mon unité documentaire est "/nitf" ce qui implique qu'il
> n'y en a qu'une seule par document pour un document NITF.
>
> Par contre lorsque j'écris :
>
> mappings.put("RDF/item", new FieldType("contenu", FieldType.UNSTORED));
>
> j'indique que l'unité documentaire est "RDF/item" et qu'il peut donc y
> en avoir plusieurs par document.
>
> C'est donc effectivement les chemins XPath qui font la différence.
Pour me préciser, je voulais dire que même après indexation, il est
possible de modifier la granularité d'une réponse avec un DB:XML
En pseudo syntaxe
sur une même collection, s'il on demande
//book/chapter//p[contains(., "xml")] on a des paragraphes
//book[contains(., "xml")] on a des livres
Autrement dit c'est au moment de la requête que se définit "l'unité
documentaire" (je me demande si ce mot est bien choisi dans ce contexte).
Cela signifie d'ailleurs que l'on ne peut pas ouvrir trop directement
l'API de requête à l'utilisateur, un peu comme un SQL dont on doit
connaître la structure des tables.
tandis que dans un moteur de recherche, je tape
"xml", et l'on me renvoit ce que l'indexation a considéré comme étant
l'unité, qui sera toujours la même tant que l'on ne réindexe pas.
Sur ce document, on a par contre l'avantage de pouvoir préciser des
champs, comme titre ou description, typiquement des "propriétés d'une
ressource", conformément au langage des méta-données auquel Dublin Core
nous a habitué. Le champ "contenu" destiné à la recherche plein texte
étant un cas particulier.
Mais la conversation s'étends probablement au delà des besoins de xmlfr.
> Rien, c'est juste une transformation de
> http://xmlfr.org/actualites/breves/2004-06-24#T14:56:44:354 en
> http://xmlfr.org/actualites/breves/2004-06-24/T14:56:44:354.
>
> Mais pourquoi le faire? Je tiens tout de même à publier les brèves sous
> forme quotidienne pour réduire le nombre de clics et cela signifierait
> que je devrais exposer à la fois
> http://xmlfr.org/actualites/breves/2004-06-24#T14:56:44:354 et
> http://xmlfr.org/actualites/breves/2004-06-24/T14:56:44:354.
L'un n'empêche pas l'autre ? Des URIs peuvent répondre est n'être que
rarement naviguée ? Je me suis obligé à ce genre de finasseries pour
appliquer strictement l'intention qu'une URL sans # suffise à être un
identifiant, c'est juste que cela permet à un crawler rapide (dans
cocoon, pour ne pas le nommer), d'indexer à peu près ce qu'il faut.
--
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
|
