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 - 12:02
> Si, mais dans l'élément "hedline", j'ai tendance à utiliser l'élément
> "hl2" comme une description de l'article plutôt que suivant à la lettre
> la sémantique qui en est donnée dans NITF, c'est à dire : "Headline 2
> (sub-headline) A subordinate headline for the article".
Les meilleurs schémas finissent toujours par avoir une vie sémantique
qui échappent aux concepteurs :o)
>>Sans vouloir pinailler, les "fragments" ou toute autre notion de
>>hiérarchie peut être regretté dans ce modèle.
>
>
> Pouvez-vous détailler ce point?
Comme je l'ai dit avant, mes réflexions viennent de l'expérience extrême
d'indexer une thèse (disons 600p).
> "1 information = 1 page".
Il est en tous cas certain que dans l'esprit Lucene, il y a une
granularité obligatoire, "l'unité documentaire". Autrement dit, un
identifiant de quelque chose de trouvé. Peu importe qu'il s'agisse d'un
fichier ou d'une URI (avec un #).
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
> Dans le cas des brèves, si vous regardez par exemple
> http://xmlfr.org/actualites/breves/2004-06-24, vous avez toutes les
> brèves publiées le 24 juin mais cela n'empêche pas que chaque a son URL,
> par exemple http://xmlfr.org/actualites/breves/2004-06-24#T14:56:44:354
> et le fait de pouvoir les indexer individuellement me semble
> intéressant.
Entièrement d'accord avec vous. Ce sont des unités documentaires à part
entière, le seul problème sera (ensuite), la pertinence dans les
résultats mais nous en avons déjà parlé.
> Pour un moteur de recherche qui n'a pas de connaissance de la structure
> des sites,
Ou dont l'API est optimisée à la Google...
Mais au fond, quand tout est dynamique, rien ne vous empêche de fournir
aussi des URLs unitaires et pérenne pour chaque brève ? Dans mes
développements cocoon, j'ai coutume de laisser répondre une URL en
**.xhtml (avec meta Dublin Core) sous prétexte de vue imprimable. C'est
ce que j'indexe avec un crawler, pour ne pas rendre les navigations
cherchables, et aussi parce que je travaille avec des sources de
documents navigables très diverses (exemples, méta-données d'images en
XMP). Au moins ce qui parait en xhtml, je suis à peu près sûr que cela
se destine au public.
> A l'inverse, on pourrait également se demander s'il est intéressant
> d'indexer en tant que tel la page 3 d'un document qui serait
> incompréhensible sans lecture préalable des pages 1 et 2 (mais je n'ai
> pas d'exemples de tels documents sur XMLfr et le débat serait donc plus
> théorique!).
Cela dépend en effet du projet éditorial. Votre unité étant l'article,
il y aurait juste à bien typer les brèves pour ne pas surprendre les
réponses au public qui ne reçoit que 10 lignes alors qu'il s'attendait à
3 pages.
--
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
|
