Numismatique médiévale

Zotero : on avance

2008-11-04T13:25:00.004+01:00

Ne disposant pas de mon matériel habituel, je ne peux rien tester, donc je me contente de relayer les nouvelles :
le projet de Zotero 1.5 Sync avance : la dernière version pré-publique vient d'être annoncée sur le blog de Zotero. C'est encore une version pour développeurs, mais c'est un signe que c'est pour presque bientôt.
Zotero Sync, c'est la possibilité de gérer sa bibliographie Zotero en ligne, avec synchronisation de la bibliographie en ligne avec celle stockée sur son extension Firefox. C'est comme de fusionner Endnote en Endnote Web (à propos de Zotero vs Endnote, procès en cours, je vous renvoie à l'analyse confiante de Darcusblog : ça ressemble au jour où Microsoft a affirmé, en mai 2007, qu'OpenOffice violait 235 brevets -- c'était surtout pour effrayer les utilisateurs et retarder l'inéluctable).
Donc je n'ai pas essayé, mais ça progresse.

Un truc que j'aimerais bien que Zotero mette en place, c'est la configuration initiale lors de l'installation du logiciel sur son navigateur Firefox : pour les premiers paramétrages, il faudrait que Zotero propose d'emblée de rattacher l'utilisateur à une bibliothèque, sur le modèle des "liens vers les bibliothèques" de Google Scholar (pourrait-on envisager que Zotero exploite précisément cette base ?) : cela permet ensuite pour tout article de cliquer sur le bouton "Localiser" (en haut à droite de la notice d'article), et d'interroger le catalogue de sa bibliothèque universitaire, pour obtenir éventuellement un lien vers l'article, où la localisation de la revue papier.
Ce service exploite le standard OpenURL : les métadonnées (titre de la revue, nom d'auteur, année, etc.) de l'article sont mises dans l'URL, transmises au catalogue de bibliothèque. Tout ce qu'il manque, c'est l'URL du résolveur OpenURL de la bibliothèque (différent de l'URL du catalogue, hélas), et les utilisateurs l'ignorent le plus souvent.
Donc si Zotero peut proposer à l'internaute, lors de l'installation, d'indiquer quelle est sa bibliothèque universitaire, il pourrait aller interroger dans la liste des URL de résolveurs connues de Google Scholar et rapatrier celle de la bibliothèque indiquée.
Un accord Zotero - Google ? J'ignore si ce genre de choses est possible ou contre nature. Mais pour nous, ce ne serait pas si mal.

Florins : un exemple d'utilisation de Yahoo! Pipes et Google Maps

2008-03-15T17:25:00.009+01:00

Liste des lieux où ont été frappées des imitations de florins (en France)
Lieu : Hainaut ; Ville : Valenciennes ; Pays : France
Lieu : Cambrai ; Ville : Cambrai ; Pays : France
Lieu : Metz ; Ville : Metz ; Pays : France
Lieu : Lorraine ; Ville : Nancy ; Pays : France
Lieu : Bar ; Ville : Bar-le-Duc ; Pays : France
Lieu : Haguenau ; Ville : Haguenau ; Pays : France
Lieu : Bourgogne ; Ville : Dijon ; Pays : France
Lieu : Aquitaine ; Ville : Agen ; Pays : France
Lieu : Viennois ; Ville : Vienne ; Pays : France
Lieu : Montélimar ; Ville : Montélimar ; Pays : France
Lieu : Valentinois ; Ville : Valence ; Pays : France
Lieu : Béarn ; Ville : Pau ; Pays : France
Lieu : Toulouse ; Ville : Toulouse ; Pays : France
Lieu : Savoie ; Ville : Chambéry ; Pays : France
Lieu : Saint-Paul-Trois-Châteaux ; Ville : Saint-Paul-Trois-Châteaux ; Pays : France
Lieu : Montpellier ; Ville : Montpellier ; Pays : France
Lieu : Perpignan ; Ville : Perpignan ; Pays : France
Lieu : Arles ; Ville : Arles ; Pays : France
Lieu : Provence ; Ville : Aix-en-Provence ; Pays : France
(source : BERNOCCHI, M. Le monete della Republica fiorentina. Florence, 1974.)

Agrandir le plan

Vous voyez ci-dessus une exploitation très perfectible d'une chaîne de traitement
Liste de lieux > Yahoo Pipes > Google Maps
Yahoo Pipes devient un outil extrêmement utile pour générer des cartes, quand on ne sait pas (ou pas encore) manipuler le JavaScript minimal pour faire ça directement dans Google.
J'indique donc la liste des noms à faire apparaître sur la carte (ville, province, etc.), dans une page HTML. Je rentre cette page dans un pipe, et je lui dis qu'il faut extraire une mention de lieu en combinant la ville avec le pays.
Il me produit ainsi une jolie carte dont j'exporte le fichier KML, et j'importe le fichier KML dans Google Maps.
Deux avantages à utiliser à la fois Yahoo Pipes et Google Maps :

les entrées dans Yahoo Pipes peuvent être des variables : je peux générer une carte en entrant à chaque fois une page différente, tout en utilisant le même pipe.
Google Maps indique facilement comment insérer une carte Google dans une page web.

Ainsi Yahoo Pipes me produit une carte temporaire, dont j'extrais les données de lieu, et Google Maps stocke mes cartes.
Problème ici : bizarrement, l'export KML ne contient pas l'intégralité des ateliers listés, pourtant bien présents sur la carte Yahoo. Il faudra que j'explore ce mystère, et que je vois si c'est récurrent.

A priori, si ça fonctionne bien, ça permettrait de génerer en quelques minutes, pour tout type iconographique étudié (ou autre phénomène), une cartographie souple (car on peut ensuite modifier la carte Google à la main).
En outre, rien n'empêche d'enrichir la liste initiale, avec une référence à une image (en ligne), une ou plusieurs références bibliographiques, une description, etc. En cliquant sur les bulles Google, un encart complet apparaîtrait avec toutes ces informations.

<update> Un billet du blog officiel de Yahoo! Pipes explique comment insérer un "badge" dans un site web. Et voici la carte qui résulte de la liste ci-dessous.

Wikio : je suis peut-être visionnaire... mais moins qu'eux

2008-03-10T08:57:00.006+01:00

J'ai installé il y a quelques mois dans la colonne de gauche des bouton qui permettent de suivre l'actualisation de ce blog sans avoir à afficher l'horrible "fil RSS" :

Il suffit de cliquer sur l'un des boutons pour que la liste des derniers billets apparaisse directement sur son espace personnalisé Netvibes, Google ou Bloglines.
Or début février Wikio, moteur d'actualités dont je me passerais difficilement, me contacte pour me proposer d'ajouter un bouton dans cette liste.
En effet Wikio veut également exister comme agrégateur de flux RSS, personnalisable, et non comme moteur d'actualités.

Voici ma réponse, datée du 16 février :

Je trouve que Wikio est un outil extrêmement utile, et même indispensable pour toute recherche concernant des sujets d'actualité (en fait, je l'utilise presque exclusivement). Mais je ne suis toujours pas convaincu par sa fonction d'agrégateur.
Je l'ai testé suite à votre proposition, et je suis gêné par la chose suivante :
Actuellement, pour s'abonner à un fil RSS sur Wikio, il faut :

soit que sur le site consulté se trouve un bouton "S'abonner sur Wikio"
soit que l'on soit en train de faire une recherche sur Wikio.

Mais sur un onglet personnalisé Wikio, si je veux rajouter un fil RSS de site extérieur, je ne vois pas comment faire (la fonction existe peut-être, mais n'est pas clairement visible)

Si vous êtes diffuseurs et agrégateurs de fils RSS, cela signifie que vous concevez le web (et j'aimerais que ce soit le cas) comme un réseau de fils RSS, et que la consultation de Wikio suffit à naviguer dans l'information. Donc, logiquement, depuis Wikio on doit pouvoir trouver toute l'information voulue, et s'abonner facilement à n'importe quel fil RSS.

J'attendrais donc plusieurs fonctions avant de trouver que Wikio est un agrégateur intéressant, donc avant de le proposer sur mon blog en estimant que je rendrais ainsi service à mes lecteurs :

Quand je suis sur une liste de résultats Wikio, pour chaque billet, Wikio doit me proposer de m'abonner au(x) fil(s) RSS du site qui a publié le billet
Sur un onglet personnalisé Wikio, la fonction "Rajouter un flux/site" doit être beaucoup plus évidente.

Faute de ces fonctions, je ne vois pas comment je peux à l'heure actuelle m'abonner facilement au Monde sur Wikio, ou à toute autre ressource "de base". Donc je ne vois pas comment Wikio pourrait devenir mon agrégateur.

Le 25 février (9 jours après mon mail), Wikio annonçait l'ouverture de Wikio Europa à des beta-testeurs (et me proposait peu après une invitation).
Je n'ai pas encore eu le temps de tout explorer, loin s'en faut (d'autres s'en chargent, dont le blog Wikio), mais j'ai pu constater que les deux fonctions manquantes qui conditionnaient mon adhésion à l'agrégateur Wikio y étaient désormais présentes.

Conclusion logique :

sur Wikio, le web devient un immense réseau de flux RSS
dès que Wikio Europa sort de la version de test et devient le site officiel de Wikio, je rajoute un bouton sur mon blog

Pleade 3

2008-02-25T09:58:00.007+01:00

Je m'étonne du silence complet du web sur la nouvelle version "pour développeurs" de Pleade 3. C'est une version pour développeurs, mais elle est déjà en cours de développement pour plusieurs centres d'archives qui paraîtront bientôt sur la Toile.
Je me rends compte aussi que j'ai laissé passer beaucoup de temps depuis le jour où je l'ai chargé sur mon poste, sans l'examiner de nouveau. Donc je mets ici mes premières réactions, écrites au mois de janvier.

Appréciation globale

Beaucoup de choses ont été repensées très intelligemment. Disparition des frames, possibilité de gérer en back-office beaucoup de choses qui nécessitaient du FTP jusque-là (pour charger sur le serveur des fichiers de configuration)
Problème des URL pérennes : le mode de fabrication de l'URL d'un document est plus simple... mais différent :

http://www.urldebase.fr/ead.html?id=CH_00000126

au lieu de

http://www.urldebase.fr/sdx/pl/toc.xsp?id=CH_00000126&fmt=upmc&idtoc=CH_00000126-pleadetoc&base=fa

Donc si on a décidé de pointer vers certaines pages de sa base Pleade (une notice de fonds, etc.), le passage à Pleade 3 nécessitera de mettre toutes ses URLs à jour.

Différences d'interface publique

A la fois un système d'onglets supérieurs (permanent) + menu latéral (contextuel aux onglets).

Différences d'interface de gestion/administration

Beaucoup plus de fichiers sont configurables directement via l'interface web. Ou au moins le back-office permet de récupérer ces fichiers XML pour les reconfigurer et les uploader ensuite.

Cela ouvre la possibilité de modifier l'architecture du site à toute personne autorisée à charger des fichiers EAD (sauf si gestion des droits fine, ce qui est probable mais à vérifier).

Les onglets supérieurs définissent des rubriques de gestion, et le menu latéral est contextuel à ces onglets. On a vite fait de publier un document EAD dans l'onglet Administration au lieu de Gestion de contenu... Donc il faut bien distinguer les comptes pour éviter ce genre de problème : un compte servant au chargement, un autre au paramétrage de Pleade.
L'augmentation des fonctions de gestion/administration est permise notamment par des menus contextuels successifs :

Tout en haut, les onglets supérieurs.
Du choix de l'onglet supérieur dépend le menu latéral
Du choix de la rubrique dans le menu latéral dépendent les sous-onglets

Cela peut rendre les choses un peu complexes au début, mais cette imbrication est finalement assez intuitive.
La publication d'un document se fait avec 3 onglets (au lieu d'une longue page) :

Chemin pour sélectionner le fichier
Paramètres de publication (correspond à l'actuelle "fragmentation", etc.)
Paramètres d'affichage

Les libellés ne sont pas plus clairs qu'avant. Il faut s'habituer... En outre pour chaque champ une aide contextuelle (point d'interrogation) est prévue. Elle reste à remplir encore (par les développeurs ? par la communauté ?)

Différences configuration/architecture interne

i18n : gestion des libellés très différente
Pleade 2 : les versions d'un libellé selon différentes langues s'expriment ainsi dans les fichiers de config :
Le contenu du texte est dans la config, même, sous cette forme :

          <zone role="subsets">
   <header xml:lang="fr">Accès aux collections</header>
   <header xml:lang="en">Access to collections</header>
</zone>

Pleade 3 : tous les libellés sont dans un fichier spécifique, appelés d'une manière conforme aux recommandations i18n :

          <form ref="test" display="link">
   <header i18n-key="subset.header-search-form-test-surcharge"/>
   <intro i18n-key="subset.intro-search-form-test-surcharge"/>
</form>

Il est donc probable que la migration des données ne se fera pas sans labeur (à moins de trouver LA feuille de conversion ?).

Pages du site

La partie "site" (pages XHTML) ne semble toujours pas pouvoir être gérée (par download/upload) dans le back-office.

Structuration en fonds et sous-fonds (ou collections)

L'arborescence est décrite par un fichier EAD au lieu d'un XML "maison". Excellente idée (vérifier l'application concrète dans ses détails)

Problèmes relevés

En superadministrateur, pour la gestion des droits, on ignore quelles sont les valeurs possibles.
Apparemment le droit "eadeac-editor" donne à la fois la possibilité de charger des documents, et de configurer le site (menus, collections, etc.). Le seul droit non donné est la gestion des autres utilisateurs.

C'est un problème si on veut ne pouvoir permettre à une personne que de publier (ne serait-ce que pour éviter les erreurs).
Les fonctions de gestion et d'administration sont trop liées entre elles. Il semble difficile de vouloir les distinguer
Je n'ai pas trouvé comment indiquer qu'un document EAD doit aller dans tel ou tel fonds ou sous-fonds (ou éventuellement dans plusieurs fonds à la fois)
Quand on publie un document dont le titre est très long, si on veut le republier (Gérer les documents EAD publiés), il propose dans la liste déroulante des documents publiés le titre tronqué par la fin : les 9 derniers caractères suivis de "[...]" au lieu des premiers caractères suivi du même signe d'abréviation. De toute façon il faut plus de caractères avant de tronquer
L'URL d'un document est structurée de manière simplifiée (en reprenant l'identifiant unique), mais avec la disparition des frames elle est identique pour toutes les pages du document. Il n'est plus possible de citer une page précise et de créer un lien profond dans le document.

Conclusion

Pleade était jusque-là, il me semble, le fruit d'une collaboration entre des sociétés (AJLSM et Anaphore notamment) et le Ministère de la Culture (la Direction des Archives de France et les Archives nationales essentiellement).
Bon nombre de questions seront sans doute éclaircies lors de la journée Pleade 3, le mercredi 26 mars 2008 au Muséum national d'histoire naturelle.
La version 3 de Pleade est extrêmement intéressante, très inventive, mais me semble plus le fruit des développeurs privés sans participation claire de l'Etat. Que va devenir le logiciel, entre les mains d'une petite communauté de développeurs (car il est peu vraisemblable que cette communauté de développeurs s'étende beaucoup : les centres d'archives n'ont jamais d'informaticiens, ils doivent faire appel au service informatique du Conseil général).
Pleade a été adopté outre-Atlantique. Il y a là-bas des informaticiens, et je n'ai pas l'impression qu'ils ont participé à la naissance de la version 3. Peuvent-ils décider d'en faire une autre version ? ou de renommer le logiciel pour se l'approprier plus complètement ? Tout cela pour moi n'est pas clair.
Donc techniquement, c'est bourré de bonnes idées, mais avec une migration complexe des données (et surtout que faire du travail de personnalisation réalisé sur la version 2, pour le passage en V3 ?).
Mais politiquement, je trouve que ce serait encore hasardeux de se lancer dans la V3 si on dispose déjà de la V2, et ce d'autant plus que toute la documentation sur la V3 reste à faire (ou, si elle est rédigée, elle n'est en tout cas pas disponible à ma connaissance), et que cette version reste donc encore actuellement la "chose" de ses concepteurs.
Enfin, pour le projet qui me tient à coeur d'une base de monnaies en EAD, la V3 ne me paraît pas nécessaire :

actuellement, si j'interroge une base de monnaies avec Pleade sur les termes "alpha oméga", j'obtiendrai une liste de résultats
- denier. XIIe siècle
- obole. XIe siècle
avec la V3, j'aurais forcément l'émetteur en "chapeau", avec l'arborescence des monnaies en dessous :
- Agen
- Anjou
et je ne suis pas sûr que ce soit d'un usage plus aisé.

Même pour une recherche dans un fonds d'archives, c'est professionnellement pertinent, mais on touche une problématique, un débat plus vastes, entre les utilisateurs (chercheurs, généalogistes) et les professionnels (archivistes).
Ces derniers souhaitent a priori faire voir la logique du fonds pour donner un sens aux résultats, forcer le chercheur (pour son bien, pour qu'il comprenne ce qu'il est en train de faire) à voir l'arborescence des fonds qu'il consulte.
Les chercheurs, eux, ne sont (il me semble) intéressés que par les résultats, pas par la connaissance des fonds. Et si on peut leur fournir les documents qui les intéressent en les dispensant d'apprendre le cadre de classement du fonds consulté, sans doute en seraient-ils enchantés.
A cela s'ajoute qu'ils savent désormais se servir de Yahoo! et de Google, et qu'ils sont de plus en plus habitués à des résultats non hiérarchisés. Est-ce une bonne chose ? Je ne crois pas, mais c'est ce qui est, et il me semble risqué de vouloir en faire abstraction.

Les choix de Pleade 3 satisferont donc -- je pense -- les professionnels de la culture et tiennent compte d'importantes évolutions du web et des usages. Mais le choix de Pleade 3 s'impose-t-il pour autant -- surtout à l'heure où naissent de nouveaux outils extrêmement performants (mais dont on ignore l'avenir) ? Je n'en sais rien. Je pose des questions, et vous invite volontiers à proposer des réponses.

Yahoo! Pipes : un cas d'école et quelques explications

2008-02-20T18:35:00.032+01:00

Je me suis lancé il y a quelques semaines dans Yahoo! Pipes, outil de Yahoo de génération de fils RSS, mais dont les capacités vont bien au-delà. Justement, c'est cet "au-delà" que je voulais explorer, au-delà de Ponyfish et Feed43 qui permettent de générer des fils RSS à partir de pages qui n'en possèdent pas, mais présentent leurs informations sous forme de listes.

Au moment de commencer l'expérimentation de cet outil, j'ai voulu me documenter pour voir à quoi cela ressemblait. Remarques :

il n'y a rigoureusement rien en français. Mais ce n'est pas le plus grave.
Yahoo! ne donne pour ainsi dire aucune documentation : un seul exemple par fonction, et l'exemple est d'une pauvreté désolante. Donc je ne renvoie même pas à cette documentation.

A défaut d'autre solution, je me suis donc lancé dans le vide, j'ai produit quelques "pipes", et je vais en présenter un ici, en expliquant les modules un par un, du début à la fin.
J'espère que ça donnera une idée plus claire de ce que permet Yahoo! Pipes (car en dépit de sa documentation indigente, l'outil est extraordinaire, bien qu'encore en beta). C'est une forme de tutoriel ou mode d'emploi par l'exemple.
Je ne prétend pas, par ailleurs, avoir utilisé les fonctions le plus intelligemment du monde. Il est certain que j'aurais pu économiser de l'énergie en utilisant certains modules de Yahoo! Pipes de manière plus appropriée. J'ai fait comme j'ai pu et il vous reste à aller encore plus loin.

Voici le "pipe" que je vais vous présenter : http://pipes.yahoo.com/pipes/pipe.info?_id=0de3ef5e7c6a74ded3f7a584c2b82ba3
L'objectif était le suivant : l'association des archivistes d'Angers (AEDAA) donne sur son site internet une liste d'expositions en cours dans les centres d'archives français (en essayant d'être exhaustive).
J'ai voulu la transformer pour en faire :

un fil RSS, avec un classement par date : en tête (les plus urgents, donc) les expositions qui se terminent bientôt.
une projection cartographique : on visualise une carte avec de petites icônes, et chaque icône correspond à une exposition. On clique sur une icône pour obtenir le détail de l'expo.

Difficulté supplémentaire : chaque exposition indiquée n'est pas "cliquable" vers le site officiel du service d'archives. J'ai voulu restituer l'URL.

Evidemment, tout doit être fait automatiquement : dès que la liste est enrichie, le fil RSS, la carte et le lien sont générés dynamiquement.
Donc il faut traiter la liste de départ, pour la transformer progressivement, étape par étape, afin d'obtenir le résultat attendu à la fin.
Je vous invite à voir le code source de ce "pipe", puis à lire ce qui suit pour le comprendre.
[quand on crée un nouveau pipe, la partie de droite est vide. On choisit avec la souris le module à intégrer et on le glisse (par drag'n'drop) dans la partie de droite]

Voir le résultat du pipe
Voir le code source du pipe
Voir les données de départ (sur @rchinet.aedaa)

1.
D'abord, je choisis le module "Fetch Page", qui permet de traiter une page n'ayant pas de fil RSS. Dans cette page (champ URL), j'indique que la liste à transformer en fil RSS se trouve entre telle et telle balise.
Et dans cette liste chaque item est séparé du suivant par la balise HTML </h4>
Donc chaque "item.content" va contenir à chaque fois l'intégralité de l'item en code HTML. Je vais aller y piocher les informations qu'il me faut, pour les répartir aux bons endroits.

2.
Le module "loop" fait une boucle : pour chaque item défini plus haut (le contenu entre chaque balise <h4>) et où tout est mélangé, j'extrais une information sur le titre, avec des expressions Perl.
Je ne vais pas vous donner des cours de Perl (expressions régulières), alors j'explique juste le principe de cette formule :
Remplacer : [\d\D]*]*>([^<]*)[\d\D]*
Par : $1
= Dans ce qui a été récupéré (l'intégralité du contenu de chaque item) j'extrais ce qui se trouve entre les balises <a> et </a>, et je le place dans le "item.title".
Le résultat, c'est que chaque item a désormais un titre.
De même, il me faut attribuer à chaque item (par des loop) :

une "description" (c'est ce qui correspond au contenu d'un fil RSS, sous le titre),
un lien (vers lequel pointe chaque billet),
une géolocalisation pour projection cartographique.

3.
Ici, je reprends ce qui se trouve après le saut de ligne (balise <br>) pour le mettre dans la "description", c'est-à-dire le corps du message du fil RSS.
4.
J'ai passé un certain temps pour savoir comment construire une URL pointant automatiquement vers la page de présentation de l'exposition.
J'ai finalement utilisé la fonction "J'ai de la chance de Google". En effet pour n'importe quelle requête, vous pouvez pointer vers une liste de résultats Google.
Par exemple, si je veux vous indiquer ce que donne la recherche "numismatique" dans Google, je vous enverrai vers l'URL :
http://www.google.fr/search?q=numismatique&btnG
Mais en remplaçant à la fin btnG par btnI (ce qui correspond au code envoyé par le bouton "J'ai de la chance" de Google), j'obtiendrai non pas la liste des résultats, mais directement le premier résultat qui sort quand on chaque "numismatique" dans Google.
Essayez : http://www.google.fr/search?q=numismatique&btnI
Donc au lieu de chercher "numismatique", je vais lancer une requête Google avec ce qui se trouve dans le titre de chaque billet. Le titre a été défini à l'étape 2, et correspond exactement au titre de l'exposition.
Certains titres d'expositions sont un peu "flous" (ex. : "Travaux publics, travaux privés") et ne donnaient pas sur Google le résultat escompté. J'ai donc lancé la requête sur :
archives+exposition+"titre".
Les trois premières lignes du "loop" ci-dessus sont pour supprimer du titre toute apostrophe ' par un espace, parce qu'elles entraient en conflit avec les guillemets dans l'URL demandée à Google.
Il reste donc à Google à avoir un classement pertinent de ses résultats pour que le premier soit le bon !

Toutes les étapes suivantes sont consacrées à la géolocalisation : il faut extraire une notion de lieu, en récupérant l'indication du département (ou de la ville) dans des intitulés comme "AD du Tarn-et-Garonne", "AM de Marseille".
Le problème est que Yahoo est incapable de reconnaître certains départements au nom trop "flou" : la Creuse, les Landes.
En outre, tous les signes diacritiques (é, è, â) lui posent problème. Donc je suis obligé de remplacer les noms : Ardèche devient Ardeche, etc.
J'ai essayé de remplacer simplement les lettres (è devient e), mais il m'escamote alors la lettre suivante, et Ardèche devient Areche. C'est encore une version beta !
5.
Ici, j'extrais du titre (qui contient par exemple : "AD Haute-Garonne - Les Cathares : quelles sources pour l'histoire ?") l'indication du lieu (Haute-Garonne).
Je place le résultat dans un champ temporaire : item.loop:strregex (c'est Yahoo! qui me propose tout seul le nom de ce champ. Je le garde -- mais je pourrais lui donner un autre nom).

6.
Je remplace dans ce champ tous les mots accentués par les mêmes mots non accentués.
J'ajoute pour les départements problématiques le nom de la préfecture : "Creuse" devient "Creuse Guéret".
Je place le tout dans un nouveau champ : item.loop:strreplace.
7.
Encore une boucle : dans le résultat précédent, je rajoute le nom du pays, pour lui éviter de me localiser Paris au Texas !
A ce stade :

"AM Marseille" est devenu "Marseille FRANCE"
"Côtes d'Armor" est devenu "Cotes d'Armor FRANCE"
"Landes" est devenu "Landes Mont-de-Marsan FRANCE"

Je remets le résultat obtenu dans un nouveau champ (toujours proposé par Yahoo!). Je peux désormais utiliser la fonction qui va interroger Yahoo! Maps et reconnaît dans la valeur obtenue un nom de lieu
8.

"Location Builder" va chercher pour chaque item (Location Builder doit être inséré dans un module "Loop") la valeur obtenue précédemment.
Il lui attribue une longitude et une latitude.
Par exemple pour les AD de l'Ardèche, il me dit qu'il a dans item.y:location :

country: France
lat: 44.815340
lon: 4.373790
quality: 30 (qualité = niveau de précision de la localisation)

Il va ainsi placer le curseur sur la carte au centre du département. Pas sur la préfecture. A ce stade, je ne sais pas encore faire mieux, mais il existe une fonction "Yahoo! local" qui théoriquement sait trouver, pour un lieu indiqué (latitude et longitude), des services à proximité (5 miles, 10 miles, 20 miles). Mais il semble que les services d'archives ne sont pas référencés dans Yahoo! local. En outre, il faudrait chercher tantôt des services d'archives départementales, tantôt des services d'archives municipales...

Donc à ce stade, nous avons un fil RSS avec :

un titre
une "description" (= contenu du message)
une URL
une géolocalisation

Mais les items sont encore classés dans leur ordre de départ, à savoir par numéro de département.
Les étapes qui restent extraient une notion de date de fin (exposition jusqu'au 20 mars 2008, jusqu'au 30 juillet 2008, etc.) pour retrier l'ensemble, afin de faire apparaître en tête celles qui se terminent bientôt.
9.
C'est la "description" qui contient l'indication de date. Avec une expression régulière, je récupère la mention de jour et de mois (si elle existe) et l'indication de l'année.
Je suis obligé de séparer l'année, car Yahoo propose un "Date Builder" de même que son "Location Builder", et celui-ci fonctionne mieux si l'année est avant ("2008 Mars", plutôt que "Mars 2008").
Par ailleurs, il ne fonctionne que si les noms des mois sont en anglais. Je dois donc utiliser la fonction "Translate".
10.
Dans une nouvelle boucle, j'entre la valeur du champ obtenu juste avant, où j'avais interverti la l'année et le mois. Et je traduis cette valeur du français vers l'anglais.
J'obtiens une valeur en anglais :
"jusqu'au 28 mars 2008" est devenu : "2008, 28 March".
11.
Je fais une nouvelle boucle pour "construire" une date à partir de la valeur traduite.
Désormais, mon "pipe" sait que cette valeur est une date, il peut la traiter sous la forme normalisée "2008-03-28".
Cette valeur normalisée va me permettre de faire un tri.
J'aurais pu aller plus loin, et obtenir de Yahoo! Pipes une sortie au format ICal, c'est-à-dire un format plus ou moins standardisé qui permet à des calendriers de dialoguer : le fichier ICal obtenu aurait pu être rentré dans un Agenda Google, ou Netvibes, et on aurait pu naviguer dans cette liste d'expositions à la fois sous forme de liste (fil RSS), de carte géographique, et d'agenda.
Mais j'avoue que je fatigue un peu, et vous aussi sans doute.
12.
Voilà le tri : je prends l'information stockée dans le champ précédent (item.loop:datebuilder) et j'en fais un tri "ascendant".
Ouf ! une fonction toute simple.
13.
On sort du pipe.

Il n'est pas nécessaire de faire son premier pipe avec autant d'étapes. Les choses plus simples sont également autorisées. Mais j'ai choisi d'expliquer celui-ci précisément parce qu'il est complexe, et parce que j'ai beaucoup peiné sur certaines fonctions.
Yahoo! Pipes permet aussi plus simplement de fusionner deux fils RSS, de les trier de nouveau, etc.
Par exemple : si vous voulez savoir qui parle de votre blog, vous utiliser la recherche Yahoo! qui vous fournit un fil RSS + une recherche Google Blog Search + une recherche Technorati + Ask.com Blogs et Flux, vous fusionnez tout ça (fonction Union), puis vous dédoublonnez les résultats (car évidemment toutes ces requêtes vont souvent vous donner les mêmes réponses) avec la fonction Unique. Et ce sera très bien pour commencer.

Outil simple ou complexe ?
Beaucoup plus simple que de tout taper en code (il paraît que c'est possible avec des httpRequest).
Mais il faut connaître un peu de Perl (uniquement les expressions régulières), et maîtriser progressivement l'interface Yahoo! Pipes elle-même.
Surtout, il faut être capable de renoncer à toute documentation, et ça, c'est dur !
Par exemple, je n'ai toujours pas réussi à trouver comment insérer la carte obtenu sur un autre site (le mien, par exemple).
J'espère en tout cas que vous voyez à peu près tout ce que permet Yahoo! Pipes en terme de traitement des données : c'est assez prodigieux !

Fonction d'indexation sur Wikio

2008-02-15T08:10:00.003+01:00

Je viens de découvrir sur Wikio une fonction intéressante, mais dont, je pense, je ne perçois pas encore toutes les possibilités.
J'ai retrouvé mon précédent article (sur l'estévenant bisontin) indexé dans Wikio (URL de la requête. Rq : cette URL ne signifiera plus rien dans quelques jours, étant donné le taux de renouvellement des articles de Wikio).
Or dans les premières lignes affichées du billet, on constate que les mots "Jean-Claude Alcamo" ont été indexés (et cliquables), c'est-à-dire qu'ils sont identifiés comme désignant une personne pouvant être "interrogée" dans Wikio.

Le lien pointe vers l'URL http://www.wikio.fr/tag/Jean-Claude+Alcamo, cliquable, fournissant la liste des "actualités" mentionnant également cette personne (en l'occurrence, il n'y a que mon billet).
En général, une telle indexation se fait à la suite du texte, avec un système de tags (à peu près tous les blogs, dont celui-ci, utilisent ce système pour indexer leurs billets). De même, dans les catalogues de bibliothèques et les bases de données, on indique à la suite des infos bibliographiques (Titre, Auteur, Date, etc.) des mots-clés.
Ici, les mots-clés sont directement intégrés au texte. C'est une démarche presque évidente étant données les possibilités du web, mais j'avoue que je n'y avais encore jamais songé.
Dans "Ma Bibliothèque" Google Book Search, j'ai rajouté pour certains livres (par manque de temps, je ne les ai pas indexés tous) des tags. Mais ne pourrait-on envisager le système suivant : je fournis à Google Book Search une liste de mots (que je trouve significatifs) et, pour ma bibliothèque, tous ces mots deviennent cliquables et relancent une recherche dans cette même bibliothèque...
D'autres exploitations sont certainement envisageables, et même existent déjà certainement.
Je précise que c'est un autre cas de figure que tous les liens inter-articles de la Wikipedia, par exemple : dans la Wikipedia, on pointe vers un article donné. Wikio ne pointe pas vers une notice bibliographique, mais vers un sujet présent dans sa base d'articles, et pour lesquels il y a n articles présents.
Moralité : il me faut de nouveau me plonger dans Wikio...

Google Book Search : chercher dans une sélection de livres

2007-09-01T19:17:00.000+02:00

Découvrant récemment que le rayon Numismatique de Google Book Search s'était enrichi de façon vraiment intéressante, je me suis mis à chercher comment bidouiller un moteur n'allant chercher que dans les ouvrages en question, et pas dans toute la base (un genre de Google Custom Search Engine pour Google Book Search).
En vain.
Et Figoblog, grâce lui en soit rendue ! m'apporte la réponse simple sur un plateau : on peut se constituer une bibliothèque...

Sur les listes de résultats apparaît un lien "Ajouter à ma bibliothèque" :

Le lien est aussi proposé dans chaque page de présentation d'un ouvrage.
Comme, bien évidemment, il est possible de lancer des recherches exclusivement dans sa bibliothèque, je vais m'empresser de l'enrichir de tous les titres que je pourrai dénicher en numismatique.
Vous pouvez avoir accès à cette recherche réduite à quelques titres : sur ce lien.
Si je rajoute un titre, vous pouvez en être informés par un fil RSS.
Vous pouvez aussi me signaler des titres à rajouter dans cette "bibliothèque numérique numismatique en m'envoyant un mail.

Classement web

2007-08-31T11:35:00.000+02:00

Puisque d'autres en parlent, je le signale en passant : wikio sort une mise à jour de son classement des blogs par popularité.
Pour le fun : je suis 9505e sur 17300 (il paraît que je perds 108 places...). J'ai deux remarques :

Ce n'est peut-être pas si mal pour un blog intitulé "Numismatique médiévale"...
Je ne suis plus classé en "Nouvelles technologies" (ce qui me gênait un peu quand même, malgré ma forte tendance à digresser sur ce genre de sujets) mais en "Autres". J'en suis extrêmement satisfait : cela me rappelle la catégorie "Insolite" dans laquelle sont classées les infos sur des trouvailles de trésor dans les sites de presse (cf. ce billet).

J'en profite pour signaler un autre classement qui m'étonne davantage : j'avais toujours lu que les blogs hébergés par Blogger (qui appartient à Google) étaient surclassés dans une recherche Google.
Or en cherchant "Numismatique médiévale" (entre guillemets) sur Google et sur Yahoo!, je constate que je ne suis pas sur la première page, alors que sur le second je suis en 1ère et 3e ou 4e position (ça dépend des jours), la seconde ou troisième place étant prise par l'article Wikipedia du même nom.
Sur Google, la même recherche renvoie d'abord l'ouvrage de Françoise Dumas et Marc Bompaire, qui est bien au-delà de ce que je pourrais rêver écrire (donc sa première place est amplement méritée), mais sur Amazon.fr. Donc je ne suis pas sûr que ce soit la valeur scientifique de son contenu qui explique sa mise en valeur sur Google.
Cette même page Amazon est en seconde position sur Yahoo!
Je n'ai rien à conclure de tout cela, sauf : s'intéresser au classement de son site n'a pas grand intérêt.

[Ajout du 17 octobre 2007 : je suis indiqué 5452e en perdant 209 places, et je suis repassé dans High-Tech... Donc je n'arrête pas de perdre des places, mais en montant tout de même. Je suis plus navré de ma catégorie tout de même]

WikiMindMap

2007-07-09T09:23:00.000+02:00

Je m'intéresse de plus en plus à la cartographie de l'information, c'est-à-dire une manière de représenter des résultats de recherche non sous forme de listes, mais sous forme de cartes qui rapprochent sur l'écran les sites se référençant mutuellement, ou ayant les mêmes contenus, et en créant des liens entre eux.
Cette représentation des résultats est moins familière, mais elle est beaucoup plus logique. Et dans certains cas (que je dois encore approfondir) elle rend beaucoup mieux compte de la nature de l'information que l'on retrouve.
Par exemple, pour découvrir à quelle "sphère" appartient un site, c'est beaucoup plus rapide de le faire avec Kartoo qu'avec une recherche Google du type link:http://www.nomdusite.fr.

J'avoue toutefois n'avoir pas toujours le réflexe d'utiliser ce genre d'outils. Je m'en sers généralement quand je dois découvrir des sites sur un sujet qui m'est inconnu, et me faire une idée rapide de leur portée (sur les nanotechnologies, ou les capteurs photovoltaïques...). Mais je devrais le faire de manière plus systématique, car ça apporte toujours de bonne surprise.
Dans ce cadre-là, je découvre tout juste un outil produisant des "cartes heuristiques" de Wikipédia : WikiMindMap.
Sommairement, une carte heuristique est une carte dynamique qui relie des informations entre elles par des connexions sémantiques (des connexions qui ont du sens). Mais l'utilité d'une telle chose est beaucoup plus visible en l'utilisant.
Voici donc la carte heuristique pour "Numismatique".

Le moteur va chercher l'information dans la Wikipedia, et structure les résultats sous forme de cartes, en affichant le début du texte en info-bulle quand on passe la souris sur une des cases.
On découvre ainsi de nouveaux articles, d'une part. Mais ça peut donner aussi l'idée d'aborder son thème sous des angles non envisagés d'abord.
De toute façon, sans prétendre remplacer le moteur de recherche "classique", c'est une excellent complément

Indexation bibliothécaires et indexation chercheurs

2007-06-13T09:47:00.000+02:00

Un petit billet pour répéter ici ce que j'ai dit dans un commentaire -- et comme les commentaires ne sont pas beaucoup lus, et pas du tout indexés par les moteurs de recherche, il m'a semblé que cette remarque méritait mieux que ça.
[comme tout ce que je dit, c'est évidemment sujet à contestation, controverse voire critique]
Il me semble que l'indexation telle que l'utilise le bibliothécaire vise à catégoriser la ressource.
L'objectif est donc clairement qu'un même mot-clé serve à un grand nombre de documents. Un mot-clé servant à un seul ouvrage doit être changé. L'objectif est,

d'une part de "ranger" le livre sur une étagère virtuelle thématique, et correspond à une cote. En ce sens, le travail du bibliothécaire (ou du gestionnaire d'une base de données) est une cotation par mots plus qu'une indexation.
d'autre part, que l'internaute, lorsqu'il arrive sur une notice détaillée, puisse rebondir sur ces mots-clés catégoriels et retrouver d'autres ressources similaires.

L'indexation faite par le chercheur (sur HAL, par exemple) vise à individualiser la ressource de manière unique : chaque ressource a ainsi une combinaison de mots-clés unique, voire des mots-clés utilisés uniquement pour cette ressource. L'objectif est de retrouver cette ressource précisément lorsqu'un internaute lance une recherche, généralement avec des termes très précis (nom d'une molécule pour un chimiste, ou d'un comte de Saint-Gilles pour un numismate).
Voilà pourquoi ces deux types de mots-clés sont utiles au sein d'une même base de données.
Le problème est la clarté de la distinction lorsqu'on consulte une notice : comment expliquer à l'utilisateur que tel mot-clé est catégoriel, et tel autre personnel ?
Peut-être en renforçant cette spécificité de l'indexation rameau (ou autre), et en indiquant pour le premier type : "catégories", et pour le second : "mots-clés" ?
Après tout, les blogs permettent à la fois de ranger un billet dans une catégorie, et de lui attribuer des tags ! Donc nous sommes dans le domaine du connu pour l'utilisateur.

Pleade : nouveau site

2007-05-30T12:38:00.000+02:00

Pourquoi personne ne m'a-t-il dit (pourquoi n'ai-je vu ça nulle part ?) que Pleade avait un nouveau site : http://www.pleade.com, alors que l'ancien n'est plus à jour depuis 2005 (je crois) ?
La page A propos précise tout de même "ce site n'est pas le site officiel", "il s'agit plutôt d'un site géré par les sociétés Anaphore et AJLSM".
Sans doute. Mais celui-ci a une page d'actualité dont le dernier billet date du 10 mai 2007, il parle de la version 3.0 et de la feuille de route pour y parvenir, des nouveautés à attendre, etc.
Et il a un fil RSS pour chaque page ou presque, dont celui des actualités.
J'ai encore un gros regret : la page de documentation ne fait que renvoyer à celle de Pleade.org, avec cette promesse : "Prochainement, vous trouverez ici de la documentation complémentaire proposée par les sociétés AJLSM et Anaphore. "

Au moins, je découvre qu'on travaille encore à développer l'outil.
Parmi les promesses de la version 3.0 :

Une meilleure gestion des groupes d'instruments de recherche : rendre plus explicite les possibilités de recherche dans un groupe d'instruments de recherche, faciliter la navigation entre ces instruments de recherche, etc.
L'utilisation d'un cadre de classement pour organiser les instruments de recherche : ce cadre de classement pourra être utilisé pour consulter directement des instruments de recherche, mais il pourra également servir à une meilleure présentation des résultats de recherche.
L'utilisation autonome des feuilles de styles de conversion de l'EAD vers XHTML : ces feuilles de styles pourront donc être utilisées en-dehors de PLEADE afin de permettre de produire des instruments de recherche en format HTML statique, utilisables hors PLEADE.
Outil de gestion et de consultation de documents numériques : une puissante visionneuse de lots d'images sera intégrée à PLEADE, ainsi qu'un serveur d'images qui permettra d'offrir des fonctionnalités de consultation très intéressantes aux utilisateurs. Ces fonctions seront particulièrement utiles pour les archives numérisées. A noter que la consultation pourra se faire entièrement à l'aide du navigateur Web, sans l'utilisation de modules externes.

Comment bien utiliser les "tags"

2007-05-24T09:53:00.000+02:00

Les "tags", cette possibilité pour les utilisateurs d'ajouter des mots-clés aux ressources trouvées dans les bases de données qu'ils consultent, font peur aux concepteurs de ces mêmes bases de données.
Surtout si ces derniers sont des professionnels de l'information, qui utilisent un vocabulaire cadré, structuré, limité : Rameau, le MeSH, etc.
Comment permettre aux internautes d'ajouter des mots-clés sans tomber dans la dérive d'un vocabulaire complètement anarchique, avec les variantes singulier-pluriel, les fautes de frappe, etc.

Je vois deux possibilités qui me paraissent largement suffire l'une comme l'autre :

En utilisant la méthode de Delicious de suggestion de mots-clés. Quand on rentre un nouveau favori sur Delicious, il va chercher tous les utilisateurs ayant déjà rentré la même URL, et propose les tags utilisés. Parmi ces tags, il distingue ceux que l'internaute a déjà utilisé pour ses propres favoris déjà créés.
Cela me paraît très incitatif.
La seconde a été adoptée récemment sur Allociné : pour un film donné, on indique les tags déjà rentrés par les autres internautes, et le nombre de fois où ce tag a été utilisé pour ce film. L'internaute peut bien être rapide de ses dix doigts (ou de ses deux index), il a toujours plus vite fait de recliquer sur un mot déjà rentré que de le retaper avec des variantes ou des fautes (pour l'exemple ci-dessous, "18e siecle" existe, et il faut être obstiné pour vouloir ajouter "XVIIIe siècle)

J'ai lu naguère quelque part que les utilisateurs de FlickR se rendaient rapidement compte des tags les plus utilisés par les autres internautes, et se mettaient à les employer eux-mêmes. On favorise de cette manière la cohérence de la base, sans donner à l'internaute l'impression de le corseter. Et celui-ci enrichit ainsi l'indexation à peu de frais.

Je suis résolument pour la possible intervention des utilisateurs dans une base de données, institutionnelle. Une fois ce principe posé, il suffit de voir comment résoudre les craintes des gestionnaires de la base.

Un wiki un jour

2007-05-22T19:43:00.001+02:00

C'est très pénible, mais je fourmille d'idées, et je ne travaille pas au Cabinet des Médailles.
Sans abandonner mes autres projets, et notamment Pleade qui me tient à coeur, j'ai très envie à présent de mettre en place un wiki sur la numismatique, pour avoir une base à jour, rendant compte des discussions autour des attributions et des datations.
En effet depuis Poey d'Avant on n'a plus que des monographies, mais aucun outil global sur la numismatique médiévale.
Une base de données "fermée" nécessiterait chez son ou ses concepteurs une connaissance encyclopédique devenue impossible aujourd'hui. Et elle entraînerait une série de critiques des spécialistes, surtout parce qu'elle ne pourrait pas rendre compte des différents avis pour une monnaie donnée.
C'est d'ailleurs bien pour éviter les critiques autant que possible que les RPC, pour leur dernier volume, l'ont mis en ligne d'abord en laissant la possibilité aux chercheurs de réagir et de demander des corrections (cf. ce que j'ai dit de l'interface de consultation).
Un wiki, si tout le monde se prend au jeu, devrait pallier ces défauts et permettre, avec sa forte réactivité, une mise à jour constante.

A cela je donne deux précisions :

il faut une "masse critique" initiale, c'est-à-dire ne pas fournir une coquille complètement vide mais une coquille avec un peu de jaune, afin que les premiers lecteurs puissent progressivement devenir contributeurs avant de se promouvoir auteurs. Donc je pense que je mettrai toutes les monographies d'ateliers de ma thèse en ligne de cette manière.
j'ai avant tout envie d'expérimenter ce nouveau type de site. J'ai essayé le blog, j'ai testé FlickR, Pleade, Spip (logiciel de création de site internet). J'aimerais bien voir à quoi ressemble la création d'un wiki. Mais si "ça ne marche pas", c'est-à-dire si personne ne vient enrichir les articles, je n'y perds rien : j'aurais toujours appris beaucoup en informatique à défaut d'apprendre en numismatique.

Je n'envisage aucun contrôle a priori : il n'y a aucun enjeu politique majeur, aucun risque de dérapage (il me semble). Si des personnes viennent rajouter des liens publicitaires, cela signifie qu'il devient intéressant d'être mentionné sur le site, donc qu'il y a des lecteurs, donc que ces lecteurs sont suffisamment nombreux pour enlever les liens qu'ils jugeraient non pertinents.
Je pense que je reprendrai les choix faits par le concepteur de Bibliopedia, avec le même logiciel (celui de Wikipedia), dont l'interface est familière à tous. En outre un espace d'hébergement de wiki est possible gratuitement -- à condition de laisser une colonne pour la pub : pour une fois je serais prêt à cette concession qui fondamentalement me désole... (je pense que je mettrai alors au point un script Greasemonkey¹, si celui-ci n'existe pas déjà, pour masquer la pub).

Pour moi cela implique de convertir plus de 70 fichiers Word en wiki, donc avec tous les paramétrages ça va demander un certain temps. Mais c'est égal : comme ça me semble une bonne idée, j'en viendrai à bout. En outre, il me semble que, si ça marche, ça peut être beaucoup plus utile à la recherche qu'une thèse de doctorat (mais je vais essayer de faire les deux plutôt que de choisir).

Il existe déjà AncienCoinsWiki, anglophone, consacré aux monnaies antiques. J'ignore complètement la valeur scientifique de son contenu.
Il y a également NumisWiki, destiné aux collectionneurs (et j'ai déjà pu voir que les chercheurs n'avaient pas vraiment les mêmes centres d'intérêts). Le site n'a pas évolué depuis quatre mois. Et il est également en anglais.
Je précise que j'ai eu connaissance de ces wikis par WikiIndex (ou chaque créateur de wiki peut venir inscire le sien et faire ainsi connaître son existence).

NB : Figoblog m'apprend que les Archives nationales anglaises se sont enfin lancées dans un projet national de wiki pour les archives. Depuis le temps qu'il paraît évident que les AN françaises devraient faire de même !
Je suppose qu'on est en train d'admettre la possibilité pour un wiki d'avoir une valeur scientifique réelle.

_____________________
1. Greasemonkey est une extension Firefox qui permet d'associer à certains sites définis des petits scripts Javascript, pour par exemple modifier les couleurs d'une page, etc. Il faut à l'occasion de que recense les scripts Greasemonkey utiles à la recherche.

Génération 2.0

2007-05-22T19:35:00.000+02:00

Mon enfant sera ce qu'il voudra, bien sûr : agriculteur, ingénieur, prof, voire même bibliothécaire.
Mais avant tout, il sera

Un sceau de Charles IV (1355-1378)

2007-05-13T17:57:00.000+02:00

La première demande d'identification m'est arrivée via ce blog. Je doute de pouvoir suivre activement si celles-ci se multiplient, mais comme pour l'instant c'est exceptionnel, je ne vois aucune raison de ne pas m'y intéresser, puisque cela me permet toujours d'élargir mes connaissances.
En l'occurrence, n'ayant que ma maigre bibliothèque et les ressources disponibles sur Internet, j'ai été vite coincé et j'ai vite pu déplorer les limites de ces dernières.
La localisation et la datation de cet objet s'est faite sans trop de difficultés, car l'exemplaire est en excellent état.

L'objet appartient à l'empereur Charles IV (1355-1378), et en voici la description complète :
+ ROMA CAPVT MVNDI REGIT ORBIS FRENA ROTVNDI
Porte de ville avec inscrit sur la porte : AVR-EA R - OMA

+ KAROLVS DEI GRA ROMANOR' REX SEMP AVGVSTVS
Personnage couronné en majesté, sur un trône, tenant le globe crucigère. Inscription dans le champ : ET REX BOEMIE

Recherches sur Internet

Je n'ai pas de bibliothèque numismatique à ma disposition, et cet objet dépasse mes compétences (centrées sur le royaume, et même sur les émissions épiscopales et abbatiales -- et un peu les royales). Donc je n'ai pas pu aller très loin et j'espère achever cette recherche lors de ma prochaine visite au Cabinet des Médailles. Mais en attendant...

D'après l'image, l'objet fait 6 cm de diamètre, ce qui est beaucoup trop gros pour être une monnaie au XIVe siècle. J'ai essayé de le retrouver sur Internet directement, à partir de l'intitulé de la légende (d'une portion de légende non abrégée : "KAROLVS DEI GRA" pourrait avoir été transcrit Carolus Dei gratia, par exemple), et suis tombé directement sur un sceau (bulle d'or) de l'empereur Charles IV, avec exactement le même type et la même légende (en plus stylé tout de même).

Les légendes et l'iconographie rattachent cet exemplaire aux bulles d'or des empereurs du Saint-Empire Romain Germanique. La première bulle d'or connue, de Frédéric Barberousse, datant de 1164, montre déjà l'empereur en majesté avec la même légende au droit, et la porte de la ville de Rome, avec également la même légende, au revers.
Ce revers, pour remonter encore plus loin, se retrouve sur un sceau de 1033-1038 de l'empereur Conrad II.
Pourquoi KAROLVS désigne Charles IV ? Parce que l'empereur Charles III (le Gros) règne au IXe siècle, et que la monnaie ne date certainement pas d'aussi loin. Et Charles V (Charles Quint) a régné au XVIe siècle, ce qui serait trop tardif.
La réponse définitive se trouve sans doute dans :
Posse Otto, Die Siegel der deutschen Kaiser und Könige von 751 bis 1806. Tome II : Die Siegel der deutschen Kaiser und Könige von Karl IV. bis Friedrich III. Mittelalterliche Fälschungen. Landfriedenssiegel, Dresde, 1910.
L'ouvrage est numérisé dans le Wikisource allemand, mais il faut feuilleter image par image. J'essaierai de l'y repérer.
En attendant, j'ai tout de même trouvé sur Google Book Search un ouvrage de 1851, Die Siegel der deutschen Kaiser, Könige und Gegenkönige, ou la p. 44 s'intéresse à Charles IV. Mais seule la bulle d'or est répertoriée avec double face : les autres sceaux (le matériau n'est pas spécifié, donc je suppose que c'est de la cire) n'ont qu'une face, et aucun sceau d'argent n'est décrit.
On y apprend également que les bulles d'or de ce souverain font environ 10 cm, et les sceaux 8 cm.

Quelques infos

2007-05-04T09:22:00.000+02:00

Ainsi que m'en avait aimablement prévenu un commentaire, l'arrivée de mon enfant a ralenti l'activité de ce blog. Cela ne veut pas dire que je ne fais plus rien, mais que j'ai beaucoup moins de temps pour commenter ce que je fais.
Pour ceux que ça intéresse, je prépare pour être diffusés sur le portail de ma bibliothèque :

un dossier sur Zotero (plus structuré que les billets épars de ce blog).
une actualité régulière (j'envisage comme périodicité : toutes les deux semaines) sur un outil (ou un type d'outils) web 2 utile à la recherche (moteurs de recherche web 2, outils bibliographiques en ligne, etc.).

Le dossier sera aussi mentionné dans les actualités, si bien que vous pouvez vous abonner au fil RSS des actus si ça vous tente.

Parallèlement, si c'est validé (le marché est encore en cours), cette même bibliothèque pourrait bien utiliser Pleade comme outil de gestion d'une bibliothèque numérique. Une utilisation un peu dévoyée de Pleade, donc, comme ce que j'en fais moi-même, et qui apporte nombre d'insatisfactions mais également des découvertes. Et cela me permet de mieux connaître le logiciel. Donc d'en faire meilleur usage pour mes monnaies.
A ce jour, je n'ai converti en EAD qu'un seul inventaire, celui des monnaies de Malte, qui était en Word stylé.
Il faut que j'effectue à présent, pour enrichir ma base, la conversion d'un tableau Excel en EAD. Ce sera beaucoup plus simple, car la structure d'un tableau est par définition beaucoup plus clair qu'un fichier texte.
La grosse difficulté, c'est qu'un tableau Excel s'apparente beaucoup plus à une base de données relationnelle : pour chaque entrée l'information est répétée (pour chaque monnaie, on indique le nom de l'émetteur, le lieu de frappe, etc.) alors qu'en EAD l'information commune à un ensemble d'éléments n'est dit qu'une fois, en tête.
J'opérerai donc en deux fois :

avec l'outil "Publipostage" de Word, je récupère l'information dans les cellules du tableau, que j'encadre de balises XML :

<monnaie>
<emetteur>Evêque de Cambrai</emetteur>
<ref>IX.9.12</ref>
<nom>Denier</nom>
<description>
 <avers><
  <champ>Description du champ<champ>
  <legende>Contenu de la légende<legende>
 </avers>
 <revers>
  <champ>Description du champ<champ>
  <legende>Contenu de la légende<legende>
 </revers>
</description>
</monnaie>
<monnaie>
<emetteur>Evêque de Cambrai</emetteur>
<ref>IX.9.13</ref>
<nom>Gros</nom>
<description>
 <avers><
  <champ>Description du champ<champ>
  <legende>Contenu de la légende<legende>
 </avers>
 <revers><
  <champ>Description du champ<champ>
  <legende>Contenu de la légende<legende>
 </revers>
</description>
</monnaie>

j'utilise une feuille XSLT qui convertit cette information en EAD, en mettant en commun , au niveau supérieur, les éléments à ne pas répéter :

<c>
<unittitle>Evêque de Cambrai</unittitle>
<unitid>IX.9</unitid>
<c level="item">
<unittitle>Denier</unittitle>
<unitid>IX.9.12</unitid>
<c level="otherlevel" otherlevel="avers">
<scopecontent>
<p>Description du champ</p>
<p>Légende</p>
</scopecontent>
</c>
<c level="otherlevel" otherlevel="revers">
<scopecontent>
<p>Description du champ</p>
<p>Légende</p>
</scopecontent>
</c>
</c>
<c level="item">
<unittitle>Gros</unittitle>
<unitid>IX.9.13</unitid>
etc.
</c>
</c>

Il y a bien évidemment d'autres informations dans mes monnaies : références bibliographiques, mots de description (sur la présence de certains types), métal, etc. Ceci n'est qu'un exemple rapide. Il est toujours très pénible d'encoder directement du XML : on perd un temps fou à saisir les balises, et c'est bien pourquoi je dis qu'il faut laisser à la machine le soin de les générer.

A terme, j'ai également l'intention de proposer dans ma base de données, pour chaque notice un export "bibliographique" : je suis sûr qu'en adaptant (très librement et arbitrairement) certains standards bibliographiques, on peut faire rentrer des monnaies dedans, et donc utiliser les outils qui vont avec.

Une "Guiche Unique" de la culture

2007-04-27T10:11:00.000+02:00

Ne me demandez pas ce que signifie "Guiche" : je pense que c'est simplement une faute de frappe du développeur du nouveau moteur de recherche fédérée développé par le ministère de la culture. Les pages ont toutes pour titre "Guiche unique" au lieu de "Guichet unique".
Le moteur s'appelle Collections, bien que le titre ne soit visible nulle part : en réalité ce n'est pas un outil bien identifié comme tel, avec page d'accueil précise, mais un bandeau qui chapeaute toutes les pages du site.

Toujours est-il que l'outil existe, à cette adresse.
Les onglets supérieurs permettent de choisir le moteur à utiliser : recherche de musées, d'événements, etc. ou de "collections".
Il propose un champ de recherche libre, et va interroger 14 bases de données¹.

Un mode d'emploi est fourni.
On y note notamment que le tri est "par pertinence". Cette notion est formidable et un peu fourre-tout, puisqu'elle est définie complètement différemment d'un moteur à l'autre.
Pour Google, la pertinence d'un site est la citation par d'autres sites (le PageRank). D'expérience, je dirais que le ministère de la Culture a choisi le moteur Lucene (utilisé notamment pour Europeana), qui donc estime que dans toutes les informations décrivant un objet, certaines sont plus importantes que d'autres (le titre et l'auteur plus que la description, par exemple).

De même que pour Europeana, j'ai l'impression qu'il y a un sérieux problème de compréhension de nos concepteurs gouvernementaux pour la mise en place d'outils de recherche : ils considèrent que le besoin d'une recherche type "Google" doit être satisfaite, et ils ont raison.
Mais de là à croire qu'une telle recherche est satisfaisante ! Même Google propose un mode de recherche avancée. Et comme pour Europeana, la recherche simple s'avère très vite frustrante : les objets étant d'une telle variété, on est vite noyé sous le bruit.

Toutefois, comme dans Europeana, et comme dans Exalead (donc je devrais être satisfait, car je saluais cette fonction sur le catalogue fédéré des NCSU), une colonne permet de filtrer les résultats affichés, avec les catégories suivantes :

Termes associés
Qui ? (cette notion d'auteur est problématique : elle peut désigner l'auteur du cliché comme l'auteur de l'objet. Europeana avait renoncé à mettre ce mot "Qui ?" sur sa page d'accueil, pour finalement ne rien mettre, préférant enlever une fonction que susciter la confusion. A moins que ça ne fasse partie des développements ultérieurs).
Quand ?
Où ?
Catégorie. Cette notion est également problématique : elle se rattache non à la catégorie de l'objet (pour une recherche Corbie, on aurait pu attendre les catégories "Monument", "sculpture", "objets"), mais de la notice. Cela rejoint un peu l'idée de provenance de l'information. Exemples de catégories proposées :

Notice d'œuvres, de monuments, ou de documents
Visites virtuelles et parcours thématiques
Notices de fonds, catalogues et collections

La simplicité de l'interface laisse penser que l'outil s'adresse au grand public. Mais les règles de recherche et d'affichage me font me demander s'il ne s'agit pas d'un outil pour professionnels du patrimoine.
A moins que ce ne soit des professionnels qui espèrent toucher du grand public...

Un bug curieux pour finir : une fois qu'une recherche est effectuée, l'URL ne se renouvelle plus aux recherches suivantes. Donc si on veut pointer vers une liste de résultats, il faut (je pense) nettoyer ses cookies, ou changer de navigateur...

_________

1. Avec cette annonce : "A la rentrée prochaine, «Collections» sera complété de 17 nouvelles bases, ce qui portera à 31 le nombre de sources différentes accessibles par une interrogation unique." Mais pour l'instant je n'ai pas trouvé sur le site de quelles bases il s'agissait exactement.

Zotero et Wikipedia

2007-04-11T18:38:00.000+02:00

Des nouvelles de Zotero : les articles de la Wikipedia sont reconnus automatiquement comme tels par la nouvelle version (1.0 Beta 4). Traduction du début du billet d'annonce :

Nous sommes heureux d'annoncer que les utilisateurs de Zotero peuvent désormais récupérer automatiquement les références mentionnées dans la Wikipedia en utilisant le format de citation natif de la célèbre encyclopédie en ligne. La version Zotero 1.0 Beta 4 inclut également les modèles de citations de la Wikipedia dans les formats d'export bibliographique de Zotero pour ajouter directement des références dans la Wikipedia. Pour copier et coller facilement les citations formatées dans la Wikipedia, vous pouvez utiliser la nouvelle fonction "Quick Copy" : d'abord, indiquez la Wikipedia comme style de sortie en cliquant sur l'icône au-dessus de la colonne de gauche de la fenêtre Zotero, en cliquant sur "Préférences" puis "Wikipedia Citation Templates" à partir du menu en liste déroulante sous l'onglet "Export". Ensuite sélectionnez chaque référence ou collection de votre bibliothèque Zotero, cliquez sur le raccourci clavier "Copier" (Ctrl+Alt+C) et collez le contenu du presse-papier dans le code source de l'article de la Wikipedia.

La suite ici...

Le problème, c'est que le code wiki produit est fait pour la version anglophone (avec des libellés de champs en anglais) : et la version française ne comprend pas les "publisher", "author", etc.
J'ai généré ainsi une référence (Numismatique médiévale, de Marc Bompaire et Françoise Dumas), et j'ai dû resaisir les codes correspondants en français, avec la page d'aide sur les références bibliographiques de la Wikipedia.
Mais peut-être des traducteurs vont-ils se lancer dans la traduction de la table de conversion Zotero-Wikipedia pour les francophones.
J'ai découvert grâce à ça qu'il y avait un format bibliographique wiki d'une part, et que si j'étais anglais, je pourrais agrémenter mon article Medieval coinage de nombreuses références sans trop d'effort. Hélas, l'article n'existe pas et je me retrouve avec mon malheureux "Numismatique médiévale".

Perspectives d'EDL Project

2007-04-03T14:09:00.000+02:00

ACRL Blog résume une présentation par Olaf Janssen des évolutions prévues de The European Library et The European Digital Library (Project).

Les bibliothèques travaillent à détendre l'accès en une seule interface aux catalogues des bibliothèques nationales européennes (400 collections, 43 bibliothèques) pour la fin 2008. Actuellement 4% seulement des notices cataloguées sont des ressources numériques. L'objectif à 5-10 ans est d'atteindre 40%. Pour cela 10 "centres de compétence" ont été institués à travers l'Europe.
Les grands défis à relever dans ce cadre sont :

Trouver plus de partenaires. La bibliothèque numérique comprendra les musées et les archives, qui n'ont pas la même expérience de collaboration que les bibliothèques nationales.
Développer un modèle économique supportable. La collaboration fonctionne mieux quand il y a de l'argent pour aider la volonté de coopérer à naître.
Utiliser des standards ouverts.
Le copyright. Pour éviter les problèmes de Google ils travaillent directement avec les principaux éditeurs européens.
Le plus grand défi est la recherche multilingue et pertinente (retrieval ?).

Pour moi, cela ressemble plutôt à des évidences, ou si l'on préfère des bases de travail, qu'à des défis ("challenge"). Mais le point de départ n'est pas si mauvais.

Enquête dans la sphère des biblioblogs

2007-04-02T13:36:00.000+02:00

Si d'une part vous suivez ce blog, et que d'autre part vous vous intéressez aux bibliothèques, vous avez sûrement déjà vu ailleurs cette annonce : la biblioblogosphère essaie de vous connaître.
Non, ce n'est pas du nombrilisme : c'est le principe même du web que de permettre aux lecteurs de réagir, de réclamer, voire de récriminer.
Si donc vous suivez ce blog en vous rattachant plus au côté "métadonnées" qu'au côté "numismatique", je vous invite vivement à participer à ce sondage.
Je précise que je ne suis pas moi-même bibliobloggeur, seulement bibliothécaire et bloggeur. Je ne suis pas sûr de faire partie de la biblioblogosphère. A votre avis ?

Faire de la veille numismatique

2007-04-01T14:21:00.000+02:00

Je cherche encore la bonne manière de me tenir au courant des actualités numismatiques, en utilisant les possibilités d'internet.
Comme je l'ai dit, les communautés de numismates n'existent pas sous forme de blogs, mais sur les forums. Cela influe considérablement sur le type d'information qui y passe :

le support papier, c'est plusieurs dizaines de pages souvent pour les articles, donc des réflexions approfondies.
le billet de blog, c'est au maximum l'équivalent d'une page A4. C'est de la petite analyse.
le forum : quelques lignes, pour transmettre une information, ou poser une question ("avez-vous vu ce site ?", "J'ai une pièce de monnaie qui...").

Donc je n'ai pas trop envie de suivre l'enrichissement des forums (faute d'autre chose, j'y viendrais peut-être un jour). Ce dont j'ai besoin, c'est que l'information fournie soit analysée au moins un peu, afin de savoir si ça m'intéressera réellement.
J'ai essayé de m'abonner à des fils RSS sur les actualités paraissant sur Yahoo! Actus et Wikio, sur des recherches comme "monnaies", "trésors", etc. Mais les fils sont complètement parasités par les nouvelles monétaires internationales (le Gabon crée une nouvelle monnaie, etc.) et les cours de la Bourse. J'abandonne donc cette voie.
J'essaie autre chose. Les related users de Connotea m'ont donné une nouvelle idée. Aucun utilisateur de Connotea n'utilise le tag "numismatique", la communauté étant trop anglophone. Deux utilisent le terme "numismatics", dont un qui utilise Connotea pour ses recherches en histoire (mon usage de ce service est plutôt centré sur les nouvelles technologies). Donc en bon parasite web 2, je m'abonne à ses nouveaux signets. Et je verrai bien ce que ça donne. Le dernier en date (du 25 mars dernier, donc un usage récent) référence un wiki sur les monnais antiques (grecques et romaines). Ce n'est pas mon domaine, mais c'est intéressant de savoir que ça existe.
Je vais faire aussi la même chose avec CiteULike.

Si j'obtiens des infos intéressantes par ce biais (signalement de ressources numismatiques), ce ne sera jamais que sur une partie : je n'ai toujours pas d'indication sur les découvertes de trésors par exemple lors de fouilles archéologiques, ou la parution d'articles/ouvrages pouvant m'intéresser.
Pour les découvertes, j'essaie autre chose : limiter sur Wikio la recherche "trésor" au domaine "Archéologie", ce qui me donne un autre fil RSS. Je verrai si ça marche.
Pour les parutions d'articles, la bibliographie nationale française ne propose aucun abonnement. La base d'articles en sciences humaines, Francis non plus, Article@INIST non plus.
Bref, j'attends encore l'idée lumineuse...

Connotea : Related Users

2007-03-29T12:57:00.000+02:00

Une fois qu'on se met à utiliser les outils, il est parfois difficile (aussi absurde que cela puisse paraître) d'en remarquer les modifications.
C'est d'ailleurs pour cela que la plupart des services (Yahoo!, Google, Netvibes, Connotea, etc.) entretiennent des blogs avec fil RSS, indiquant les évolutions et enrichissements.
Je viens donc de découvrir (est-il là depuis le début ?) que sur tout compte Connotea existe une rubrique (en bas de la colonne de droite) "Related Users".
Me sont donc proposés 8 "utilisateurs liés". J'en ai tiré 8 fils RSS, que j'ai mixé en un seul fil avec Atiki (je ne supporte plus RSSMix, qui ne permet pas d'attribuer un titre aux fils générés et qui avale les lettres accentuées) : Favoris Connotea Related Users Lully.
Plutôt que de voir si chacun des comptes est réellement pertinent, je préfère pour le moment les suivre tous. Je filtrerai après.

Cela me rappelle ma préférence pour les moteurs de recherche qui proposent un encart simple pour la requête, mais des filtres dans la liste des résultats. C'est exactement le même processus : s'il y en a trop, ou d'inutiles, on trie. Sinon on garde tout.

Un blog institutionnel, pourquoi faire ?

2007-03-24T13:06:00.000+01:00

Lorsque tous les membres d'une profession sont passés par la même formation, il y a de fortes chances pour que

ils aient des avis différents, c'est humain.
les principes sur lesquels ils fondent leur réflexion soient communs.

Confrontons par exemple deux discours :

Une journée d'études sur les blogs et wikis en bibliothèques, organisée par l'ADDNB (qu'elle soit ici remerciée), avec le créateur de Bibliopedia pour parler notamment des blogs de bibliothèques et de bibliothécaires. Il rappelle quelques fondamentaux sur les règles à se donner quand une bibliothèque envisage de créer un blog : quel public, quelle ligne éditoriale, quelle régularité, etc. Ce sont des bases, mais mieux vaut les remémorer, ça ne peut pas faire de mal. Il signale aussi que les biblioblogs américains ont une certaine tendance à mélanger vie publique et vie privée.
Un passage à l'Enssib d'une bibliothécaire américaine, qui demande aux DCB16 : "Bien sûr, vous avez tous un blog ?"

Quand un étudiant de l'Enssib normalement constitué pense à créer un blog, il se demande d'abord : "Qu'est-ce que je vais y mettre ?" Ensuite, soit il a une idée de "ligne éditoriale" (ou, plus modestement, de thématique d'ensemble) et il met son impulsion initiale à exécution, soit il n'a pas d'idée et il abandonne en attendant des jours meilleurs. C'est évidemment la même chose pour les bibliothèques.
Il n'est pas nécessaire d'imiter l'attitude de nos collègues américains, mais peut-être serait-il bon de comprendre pourquoi eux créent des blogs : cela nous permettrait de remettre en cause quelques principes "évidents" (quitte à les réaffirmer ensuite).

Si j'ai bien compris, un Américain ne crée pas un blog pour y mettre quelque chose de particulier. Il crée un blog comme on se dote d'un téléphone (fixe ou portable) : généralement, quand on s'abonne à un service téléphonique, on ne se demande jamais au préalable "Qui vais-je bien pouvoir appeler ? Est-ce que j'ai des choses à dire ? Est-ce qu'on va vraiment me téléphoner ? De toute façon personne ne m'aime..." On s'abonne, et c'est tout.
Quand les sites internet de bibliothèques ont commencé à apparaître, il n'y avait généralement pour commencer qu'une page indiquant les horaires d'ouverture, éventuellement les conditions d'inscription et de prêt. Aujourd'hui on y trouve beaucoup d'autres choses : le contenu s'est construit progressivement, mais la création du site elle-même est venue de l'idée qu'il fallait avoir un site internet. Le fait d'avoir un site relevait de l'évidence.
Pour le blog, les Américains en sont à ce stade-là, de même que leur inscription sur MySpace (cf. le billet sur les bibliothèques américaines et MySpace chez Bibliothèques 2.0).

L'utilisation du blog relève de l'évidence pour les Américains. Il relève du choix pour les Français. Une bibliothèque française peut continuer à se demander pourquoi elle devrait faire un blog. Mais elle devrait impérativement se demander au préalable s'il faut absolument une raison. Dès qu'elle aura répondu affirmativement, elle pourra passer aux problèmes secondaires ("Ai-je quelque chose à dire à quelqu'un sous la forme de blog ?").
Mais elle peut aussi estimer finalement comme une bibliothèque américaine que le blog va de soi, et ainsi se dispenser d'une analyse préalable des besoins, des attentes et des motivations nécessaires à la création d'un blog.

Une dernière précision :
On oppose souvent deux usages d'internet, à savoir les outils d'information/documentation d'un côté, les outils de communication de l'autre. Ces usages distinguent les générations : les jeunes se servent d'internet comme outil de communication (MySpace, chat, etc.), les plus âgés (> 25-30 ans) comme outil de documentation.
Les bibliothèques qui tiennent à définir une ligne éditoriale sont clairement du côté de la documentation (c'est leur métier !).
Les bibliothèques américaines me paraissent, du moins à travers leur blog, du côté de la communication. Elles ont d'autres outils pour la doc (portails, opac 2.0, etc.), mais le blog ne relève pas du même objectif.

Tout cela serait à débattre et à discuter, évidemment...

[Ajout ultérieur : l'autre réponse des bibliothécaires américains sur "Pourquoi être sur MySpace ?" est "Parce que nos lecteurs y sont." Il me semble que la proportion d'internautes français utilisant MySpace est bien moindre qu'aux Etats-Unis. Nos usagers prennent plein d'autres habitudes avec un produit bien français que n'ont pas les Américains : Skyblog. Et je n'imagine pas (encore) les bibliothèques sur Skyblog !]

Europeana existe !

2007-03-22T10:39:00.000+01:00

Voilà, je découvre l'interface, je me suis même créé un compte.
Après avoir essayé http://www.europeana.fr, .com, .org, j'ai tout simplement (mais l'info existait peut-être quelque part) essayé http://www.europeana.eu, et pour l'instant ça fonctionne !
J'ai même créé un plugin de recherche pour Firefox 2 [et IE 7].
Les remarques approfondies viendront plus tard.
Je note au passage que l'OCR (icône en haut de chaque page) est assez médiocre, et que l'info-bulle qui correspond à l'icône dit "Mode texte pour déficients visuel". Je trouve qu'on peut trouver un usage intéressant au mode texte (le copier-coller, par exemple) sans être déficient visuel. "Pour faignant manuel" serait alors plus juste ? Et j'avoue n'avoir pas compris comment revenir au mode image.
Décidément, les encarts flottants me déplaisent, mais comme ça plaît à d'autres, pourquoi pas ?

Notons le logo, qui précise qu'Europeana est "beta", et qu'il s'agit de "la contribution française à la bibliothèque numérique européenne".

Les bonnes choses :

la recherche simple
la possibilité d'affiner la liste des résultats (on veut maintenant préciser la recherche au niveau de la liste, plus de la requête : les formulaires de recherche avancée ne servent plus vraiment).
~~les fils RSS (évidemment)~~ Je suis allé trop vite : il n'y en a plus un seul !
la possibilité de se gérer une bibliothèque à soi (et, je crois, de la partager). Il faudra que Zotero et Connotea apprennent à reconnaître l'interface.

Les problèmes :

Où est la recherche avancée ? La recherche peut rapidement être parasitée par la présence du texte intégral. La possibilité de définir que tel mot doit être dans le titre, et tel nom comme auteur, je n'arrive pas à la trouver.
Les guillemets en fonctionnent pas (c'est encore possible, ça ?) : sur "Poey d'Avant", je trouve beaucoup de Poey.
Les modalités de recherche devraient être expliquées. J'ai l'impression qu'il y a une pondération des résultats, mais est-ce sur le nombre d'occurrences du mot recherché dans l'ouvrage ? ou sur l'importance du titre par rapport au texte intégral ? ou sur autre chose encore ? Est-ce qu'en cherchant deux mots, il me ramène d'abord les résultats contenant les deux mots, puis ceux contenant un seul mot ? Par exemple, si je cherche "Poey d'Avant" monnaies, j'obtiens 3000 résultats, contre 31 pour "Poey d'Avant" seul. En revanche, "Poey d'Avant" AND monnaies ramène 21 résultats. Donc l'opérateur booléen OU est utilisé par défaut pour toute recherche...
Pour une liste de résultats, je ne peux pas tous les verser d'un seul coup dans ma "bibliothèque numérique" pour pouvoir les revoir plus tard.

L'expression exacte "numismatique médiévale" ramène 0 résultat. Snif !
Et la première page de résultats pour "numismatique" n'est vraiment pas pertinente.
Pour neutralité, j'ai essayé sur Machiavel "le prince". Rien de bien satisfaisant non plus.
Mais je finirai par comprendre comment ça marche. Et à partir de là...

A partir de là, il faudra voir ce que devient cette "contribution de la France". Je vois mal l'interface disparaître, désormais.
Et pour suivre l'actualité sur Wikio, et les réactions des bloggeurs sur Libworm.

Les autres services que j'utilise

2007-03-17T14:22:00.000+01:00

Pour récapituler :

un compte Bloglines.
un compte Connotea (avec fil RSS).
un compte Del.icio.us (avec fil RSS).
un compte FlickR (dessins et photos des monnaies que j'étudie), avec fil RSS.
un moteur de recherche spécialisé en numismatique (avec Google Coop) : Numismatique Search (ce nom est nul, c'est atroce).
un compte Esnips (utilisé ponctuellement. Il n'y a pas grand chose dedans).

Et, en non accessible : Feedburner, Feed43, Google Agenda, Netvibes, Protopage, une page d'accueil Google personnalisée, une page Exalead personnalisée. J'ai un espace MyYahoo que je n'utilise pas vraiment sauf pour la fonction Site Explorer (mais dès que j'aurai le temps je m'intéresserai à Yahoo! Pipes).

Les extensions Firefox qui me sont indispensables :

Zotero, évidemment.
Launchy, pour éditer des pages HTML en cours de navigation.
CustomizeGoogle.
SiteAdvisor.
OpenSearchFox, pour créer un plugin de recherche sur n'importe quel moteur à champ unique (c'est par exemple pour cela que je consulte les pages jaunes de 118012 et non les pages jaunes classiques).
Repagination, pour afficher d'un coup tous les résultats Google ou autres.
Reveal était indispensable, mais n'a pas migré vers Firefox 2.0. Donc j'ai dû abandonner.
IE Tab, parce qu'il y a toujours des sites où Firefox pose problème par manque de conformité aux standards du web...
GreaseMonkey est certainement indispensable, mais je n'ai pas encore trouvé de "bibliothèque" de fonctions adaptée à mes besoins les plus fréquents.