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: Eric van der Vlist (vdv@dyomedea.com)
Date: 28/06/2004 - 12:33
On Mon, 2004-06-28 at 14:02, Frédéric Glorieux wrote:
> > 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)
Oui!
>
> >>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 #).
Oui, tout à fait. L'identifiant de "l'unité documentaire" est d'ailleurs
pour Lucene un champ comme un autre sans aucune restriction lexicale.
> 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.
> > 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 ?
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.
> 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.
Effectivement...
Merci pour vos commentaires!
Eric van der Vlist
--
Tired of typing XML tags?
http://wikiml.org
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
|
