28 février 2008

Gallica 2 : notables améliorations

Suite à un mail paru sur Biblio-fr (liste de diffusion des professionnels des bibliothèques), je découvre de nouvelles fonctionnalités sur Gallica 2, précisément celles qui manquaient cruellement :
  • Fonction de recherche avancée : on peut enfin chercher spécifiquement un titre ou un auteur. Et les possibilités de filtres sont assez riches : notamment la possibilité de limiter par thème. On peut également choisir l'ordre de tri : pertinence, titre, auteur, date.
  • Zoom : ça ne s'appelle pas tout à fait comme ça, mais quand on consulte un ouvrage, en haut de la page est proposée l'option d'affichage "Normal" ou "Pleine page", qui agrandit l'image visualisée.
De très bonnes nouvelles, donc.

Libellés : ,

25 février 2008

Pleade 3


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 :

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 :
  1. Tout en haut, les onglets supérieurs.
  2. Du choix de l'onglet supérieur dépend le menu latéral
  3. 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) :
  1. Chemin pour sélectionner le fichier
  2. Paramètres de publication (correspond à l'actuelle "fragmentation", etc.)
  3. 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 pour chaque résultat l'indication en plus petits caractères de l'émetteur.
  • avec la V3, j'aurais forcément l'émetteur en "chapeau", avec l'arborescence des monnaies en dessous :
    • Agen
      • obole
      • denier
    • Anjou
      • Foulques Nerra
        • denier
    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.

Libellés : , , ,

20 février 2008

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

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 :
  1. il n'y a rigoureusement rien en français. Mais ce n'est pas le plus grave.
  2. 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 :
  1. un fil RSS, avec un classement par date : en tête (les plus urgents, donc) les expositions qui se terminent bientôt.
  2. 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]


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 !

Libellés : , , ,

18 février 2008

Europeana : nouvelle maquette

Figoblog signale la présentation d'une maquette de la prochaine version d'Europeana, telle que reprise par The European Library -- donc avec des acteurs vraiment européens, et pas seulement issus de la Bibliothèque nationale de France.
On ne peut que s'en réjouir.
Je vous laisse découvrir la maquette et ne la commenterai pas (exercice périlleux puisqu'on est guidé de bout en bout dans les manipulations). Je note deux choses tout de même :
  1. l'accent mis sur des nouveaux modes de navigation : par frise chronologique et par carte géographique. J'ai vu que ce besoin était assez récent mais extrêmement légitime de naviguer dans des collections autrement que par l'alternative moteur de recherche/liste de documents.
  2. la quasi-totalité des manipulations de la démo porte sur des objets qui ne sont pas des livres. Europeana serait donc plus comparable à un portail Patrimoine qu'à une bibliothèque numérique. Mais pourquoi pas ?
L'ancien site d'Europeana a été complètement balayé pour laisser place à la nouvelle présentation. Et je n'ai gardé aucune copie d'écran en souvenir...

Libellés : ,

16 février 2008

A quoi me sert Poey d'Avant

Suite à plusieurs remarques, il me semble utile d'expliciter le rôle que je donner à Poey d'Avant dans mes recherches. En effet j'ai le sentiment d'être assez seul pour trouver dans cet antique ouvrage (ca. 1860) une source encore importante pour l'étude de la numismatique médiévale.

Pour rappel : les trois tomes de Poey d'Avant s'efforce de cataloguer toutes les différentes monnaies connues (et non les exemplaires) pour les monnaies françaises non royales, en fournissant pour chaque monnayage :
  • un exposé historique du monnayage
  • la liste des seigneurs, évêques ou abbés
  • la description de chaque monnaie connue, avec datation et attribution éventuelle. Les planches suivent à la fin de chaque volume.
Ces volumes ont été réédités (ou plutôt réimprimés) deux fois récemment :
  1. Par Georges Depeyrot (en 1996), qui fait précéder son édition d'une introduction indiquant les erreurs d'attribution et de datation.
  2. Par l'éditeur les Chevau-Légers (en 2002), qui justifie cette réédition après celle de Depeyrot notamment par la taille des illustrations qui, d'après eux, ont été réduites. Les descriptions ont été réimprimées à l'identique, mais aux reproductions sur les planches sont ajoutées des corrections d'identification.
Cette dernière réimpression est à mon sens d'usage plus aisé, mais ne résoud pas le problème pour les monnaies non illustrées (donc non corrigées...).
Toujours est-il que la plupart du temps je me sers de l'édition originale du XIXe siècle, en particulier parce qu'elle est désormais disponible en ligne. Et je le fais en étant parfaitement conscient de ses erreurs sans nombre.
Il me semble que j'ai raison de l'utiliser et que les autres numismates ont raison de ne pas s'en servir, tout simplement parce que l'objet d'étude n'est pas le même.
En général (pour ce que j'en ai vu) un numismate est spécialiste surtout d'une région, et pour cette région connaît la dernière monographie qui met les connaissances à jour1.
Pour ma part, j'étudie généralement un type iconographique (la dextre bénissante, le châtel tournois, etc.). Je connais certains monnayages, mais, à ce jour, le Poey d'Avant est le seul corpus me présentant rapidement, en feuilletant quelques planches, l'intégralité du monnayage dans la France médiévale (en complétant évidemment avec le Duplessy pour les monnaies royales).
Si je trouve des monnaies qui m'intéressent, chez les ducs d'Anjou ou les évêques de Gap, alors je cherche l'étude la plus à jour sur ce monnayage pour confirmer (ou contredire) les propos de Poey d'Avant.
Mais, humainement, serait-il raisonnable -- et, techniquement, serait-il possible -- de prendre les 120 monographies que je pourrais me procurer, et les feuilleter une à une.
La solution ultime, évidemment, ce serait une base de données (faute de mieux, j'utilise pour l'instant CoinArchives.com). Mais, en attendant une telle base de monnaies, scientifique, je préfère utiliser le Poey d'Avant ancien, comme première étape d'une recherche, que de renoncer à tout élargissement de mon étude et me cantonner à mes deniers de Reims pour étudier l'utilisation du monogramme.
Denier de Reims - Poey d'Avant 6061
Il me faudrait commencer à rédiger une liste des fonctionnalités (une sorte de cahier des charges) pour une telle base de données. J'essaierai de voir comment y intégrer la fonction d'indexation de Wikio que j'ai découverte récemment.
______________________
1. Pour ceux qui, pour un atelier donné, ne savent qu'utiliser, je les renvoie à la riche bibliographie, datant de 2000 (donc presque récente dans l'absolu, mais très récente pour la vitesse de renouvellement de la numismatique médiévale) dans l'ouvrage de Marc Bompaire et Françoise Dumas, Numismatique Médiévale, Turnhout, Brepols, 2000.

Libellés : , , , ,

15 février 2008

Fonction d'indexation sur Wikio

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...

Libellés : , , , ,

09 février 2008

La dextre bénissante de Besançon

Je viens de recevoir le Bulletin de la Société française de numismatique de décembre 2007, contenant un article de Jean-Claude Alcamo intitulé : La représentation de la vision de saint Etienne sur le monnayage de l'archevêché de Besançon (XIe siècle).
Pour mémoire : dans Poey d'Avant, ce monnayage est étudié ici et les planches sont .
J'ai mis ici les photos que je connaissais des monnaies bisontines.
denier de l'archevêque de Besançon
Je suis enchanté de l'activité scientifique de ce numismate que je ne connais malheureusement pas : il s'intéresse précisément au même domaine que moi, à savoir l'iconographie sur les monnaies médiévales.
Ainsi, je n'avais jamais cherché à comprendre pourquoi une dextre bénissante pouvait représenter le martyre de saint Etienne : je pensais simplement, comme dans d'autres cas, qu'il s'agissait d'un reliquaire et que de nombreux reliquaires sont anthropomorphes. En outre à Metz la scène de la lapidation est directement représentée.
Metz-ROBERT-Collection-458
J'ai donc appris par cet article qu'il ne s'agissait vraisemblablement pas du reliquaire lui-même, mais du doigt de Dieu représenté sur de nombreuses scènes de lapidation de saint Etienne (par exemple sur ce manuscrit du XIVe siècle).

En revanche j'ai le sentiment que nous n'avons pas tout à fait les mêmes méthodes, ou que je me bride peut-être trop lorsque j'essaie d'interpréter ce que je vois.
Il se trouve aussi que, ayant moins le temps de faire des recherches, je prends davantage celui de réfléchir à la méthodologie d'investigation sur ce domaine. En outre, comme je m'intéresse beaucoup aux bases de données, l'approche quantitative des études iconographiques.

D'abord, un article dans une revue "classique" est désormais bloquée par l'absence d'hypertexte. Si bien que l'auteur est obligé de donner des exemples (ici, sur des représentations de cette lapidation) qui paraissent erratiques, arbitraires, sans qu'on puisse se rendre compte si c'est représentatif ou non.
Désormais, avant toute étude iconographique, je lancerai une requête sur la base Culture.fr. Et j'en rendrai compte en termes de pourcentages dans la mesure du possible.
Ainsi, pour la lapidation de saint Etienne, la base recense 282 "objets", ce qui est un corpus déjà intéressant pour s'assurer par exemple que le doigt de Dieu est réellement souvent présent dans ces scènes, à partir de quelle époque, dans quelles régions, etc.
Je n'en retrouve aucune illustration sur Internet (comme quoi tout n'est pas sur Internet !) mais j'ai souvenir d'avoir vu d'une part dans le trésor de la cathédrale de Sens, et d'autre part dans celui de la cathédrale de Canterbury, des patènes portant une dextre bénissante, sur le même modèle qu'à Saint-Etienne.
J'ai déjà remarqué pour l'Agneau pascal de Saint-Gilles, mais aussi pour d'autres types (homme à cheval, ou tout simplement croix) le transfert assez facile d'un support à l'autre, pour peu que les deux soient de forme ronde.
Il me semble qu'on pourrait considérer la dextre bénissante comme une image qui s'applique "naturellement" (au Moyen Age) sur un support rond. Si ce n'était pas le cas, il faudrait trouver de nouvelles explications pour les autres dextres bénissantes sur les autres monnaies médiévales, y compris lorsque la légende ne porte pas sur saint Etienne.

Pour les ateliers ecclésiastiques, j'ai ainsi recensé 59 monnaies différentes (sur un corpus de 715) répartis sur 9 ateliers différents, tous du Nord, de l'Est ou du Sud-Est :
  • Arles
  • Besançon
  • Cambrai
  • Embrun
  • Meaux
  • Metz
  • Saint-Bertin de Saint-Omer
  • Strasbourg
  • Toul
  • Verdun
Il faut donc bien qu'il y ait une logique géographique.
En termes chronologiques, ce n'est pas inintéressant non plus. :


même si l'atelier de Metz occupe toute la place.

Enfin la question qui achève l'article me paraît risquée : "La question se pose, en particulier, de savoir quel est le message religieux dont cette représentation monétaire est porteuse ?"
Le risque pour moi est de confondre la portée de l'image "dans l'absolu", à savoir une main bénissante et ce qu'elle signifie pour l'oeil médiéval. Il faut faire alors appel à l'iconographe pur, qui aura étudié d'autres supports, ainsi que les sources écrites, et pourra donner des éléments de réponses -- et la portée d'une telle image sur une monnaie, qui rejoint une question beaucoup plus générale et non résolue :
quelle est la portée d'une image sur une monnaie ?
La voit-on réellement ?
L'analyse-t-on ?
En fait-on un objet de méditation ? de prière ?
Notre expériences d'hommes du XX(I)e siècle nous porte à croire que non : qui regarde les pièces de monnaies de nos jours (si l'on excepte le phénomène de curiosité dû, en France, à la circulation de pièces européennes) ? J'aurais tendance à dire : personne.
Mais évidemment cette réponse ne saurait s'appliquer sans réflexion aux hommes du Moyen Age.
Quoi qu'il en soit, tant qu'on aura pas répondu à cette question plus générale, il sera impossible de répondre à cette question appliquée à un type en particulier, au risque de répondre sur la question de l'image "dans l'absolu" en croyant avoir répondu à l'autre...
En m'excusant enfin de ces critiques, je terminerai encore sur une affirmation de l'auteur qui me semble presque grave :
"Le cycle de la passion n'est toutefois pas absent de l'image [sur les deniers bisontins]. Il transparaît à travers les trois points gravés dans l'extrémité de la manche. Ils représentent le triple secours que saint Etienne reçoit du Ciel entre le moment où il est amené à comparaître devant ses juges pour blasphème et celui de sa lapidation [...], trois points qui résument à eux seuls l'ensemble des chapitres des Actes des Apôtres consacrés à Etienne."
L'interprétation de trois points comme mentions de passages de l'écriture est pour moi une aberration a priori. A moins que l'on me produise un texte médiéval interprétant ces meubles comme tels, je refuse de l'adopter.
Peut-être suis-je trop frileux ?

Libellés : , , , ,

Mentions légales

MonnaieCe n'est pas un blog de collectionneur.
Je suis historien, un peu informaticien (j'adore les métadonnées !). D'où ce que vous pouvez lire ici.
Comme vous pouvez le constater, même si je le laisse en ligne, il n'est plus alimenté depuis longtemps.

Recherche sur le web numismate

Recherche dans les livres de numismatique de Google Book Search[...]

 

 

Généré par Blogger

Site Meter