ãäÊÏíÇÊ ÇáíÓíÑ ááãßÊÈÇÊ æÊÞäíÉ ÇáãÚáæãÇÊ » ãäÊÏíÇÊ ÇáíÓíÑ ÇáÚÇãÉ » ãäÊÏì ÇáÃäÙãÉ ÇáÂáíÉ Ýí ÇáãßÊÈÇÊ æãÑÇßÒ ÇáãÚáæãÇÊ » ÈÑãÌíÉ Navimages

ãäÊÏì ÇáÃäÙãÉ ÇáÂáíÉ Ýí ÇáãßÊÈÇÊ æãÑÇßÒ ÇáãÚáæãÇÊ åÐÇ ÇáãäÊÏì ÎÇÕ Èßá ãÇ íÊÚáÞ ÈÇáÇäÙãÉ ÇáãßÊÈíÉ ÇáÂáíÉ ÇáãÓÊÎÏãÉ Ýí ÇáãßÊÈÇÊ ÇáÚÑÈíÉ.

 
ÃÏæÇÊ ÇáãæÖæÚ ÇáÊÞííã: ÊÞííã ÇáãæÖæÚ: 1 ÊÕæíÊÇÊ, ÇáãÚÏá 5.00. ÇäæÇÚ ÚÑÖ ÇáãæÖæÚ
 
ÞÏíã Mar-31-2009, 03:00 AM   ÇáãÔÇÑßÉ1
ÇáãÚáæãÇÊ

yahiaoui55
ãßÊÈí ÌÏíÏ

yahiaoui55 ÛíÑ ãÊæÇÌÏ ÍÇáíÇð
ÇáÈíÇäÇÊ
 
ÇáÚÖæíÉ: 59940
ÊÇÑíÎ ÇáÊÓÌíá: Dec 2008
ÇáÏæáÉ: ÇáÌÜÒÇÆÑ
ÇáãÔÇÑßÇÊ: 19
ÈãÚÏá : 0.00 íæãíÇð


ÇÝÊÑÇÖí ÈÑãÌíÉ Navimages

ÇáÓáÇã Úáíßã
äÙÑÇ áÃåãíÉ åÐå ÇáÈÑãÌíÉ Ýí ÊÓíÑ ÇáæËÇÆÞ æ ÇáÕæÑ ÇáÑÞãíÉ
ÇÑÏÊ Çä ÇÏÑÌ åÐÇ ÇáãÞÇá æãÚ ÇÓãÇÁ ÇáÇÓÇÊÐÉ ÇáãÔÑÝíä æÇãíáÇÊåã ááÇÓÊÝÇÏÉ ãäåã æãä ÇáÊÌÑÈÉ ÇáÝÑäÓíÉ Ýí åÐÇ ÇáãÌÇá
æÇäÇ ãÊÇÓÝ ÌÏÇ áÇäåÇ ÈÇááÛÉ ÇáÝÑäÓíÉ

Navimages
Un environnement web pour la consultation de grandes collections de documents numérisés


Martin Sévigny
AJLSM Sévigny 17, rue Vital Carles F-33000 Bordeauxsevigny@ajlsm.com
Frédéric Glorieux
AJLSM 17, rue Vital Carles F-33000 Bordeauxfrederic.glorieux@ajlsm.com
Florence Clavaud
Centre historique des archives nationales 60, rue des Francs-Bourgeois F-75003 Parisfrederic.glorieux@ajlsm.com

RESUME
La Direction des archives de France a initié et finance Navimages, unenvironnement libre permettant de préparer et diffuser de grandes séries d’images numérisées. Navimages est composé de trois modules qui peuvent fonctionner de manière indépendante: le collecteur va identifier et préparer les images; la base documentaire va permettre d’effectuer des recherches dans les données descriptives associées aux séries d’images, données sous la forme de champs ou en format XML EAD; la visionneuse permet de consulter les images dans un navigateur web et de les manipuler aisément. Différents projets de numérisation utilisent cet outil: l’état civil des Français d’Algérie; le projet Champlain; le fonds d’archives de la période du Premier Empire.

La Direction des archives de France a initié et finance Navimages, un environnement libre permettant de préparer et diffuser de grandes séries d’images numérisées. Navimages est composé de trois modules qui peuvent fonctionner de manière indépendante: le collecteur va identifier et préparer les images; la base documentaire va permettre d’effectuer des recherches dans les données descriptives associées aux séries d’images, données sous la forme de champs ou en format XML EAD; la visionneuse permet de consulter les images dans un navigateur web et de les manipuler aisément. Différents projets de numérisation utilisent cet outil: l’état civil des Français d’Algérie; le projet Champlain; le fonds d’archives de la période du Premier Empire.

ABSTRACT —

The Direction des archives de France has initiated and is financing Navimages, a free environment for preparing and publishing large collections of digitized images. Navimages comprises three independent modules: a collector, to identify and prepare images; the document base, for searching in descriptive data about the collections, data in either field based or in XML EAD; a viewer for easily browsing and manipulating images in a Web browser. Several projects use Navimages: civil registers for French in Algeria; Champlain project; archives from the Premier Empire.

The Direction des archives de France has initiated and is financing Navimages, a free environment for preparing and publishing large collections of digitized images. Navimages comprises three independent modules: a collector, to identify and prepare images; the document base, for searching in descriptive data about the collections, data in either field based or in XML EAD; a viewer for easily browsing and manipulating images in a Web browser. Several projects use Navimages: civil registers for French in Algeria; Champlain project; archives from the Premier Empire.
Keywords : numérisation, archives, XML, EAD, collections d’imagesdigitization, archives, XML, EAD, image collections.


1. Introduction


Bibliothèques, services d’archives, musées, beaucoup d’organisations gèrent d’importantes collections patrimoniales. La numérisation ouvre des perspectives alléchantes: préserver les originaux, dupliquer les substituts numériques sans perte, les conserver avec peu d’encombrement, les communiquer à n’importe quel ordinateur connecté… Aussi trouve-t-on de nombreux partenaires pour produire des images numériques à partir des documents originaux (Buresi et al., 2002). Mais il y manque une couche logicielle, et du texte descriptif, pour organiser cet ensemble et le rendre commode à chercher et consulter. Numériser, c’est aussi donner une forme informatique à cette aide, à ce conseil que le spécialiste sait donner, lorsqu’on lui demande à voir un document précis dans un lot incomplètement décrit.
[IMG]file:///E:/RACHID/Navimages_files/barre_paragraphe.gif[/IMG]2
La France a nettement pris conscience de ces enjeux, afin d’avancer dans la constitution d’une « république électronique ». Le ministère de la Culture et de la communication s’est par exemple engagé à améliorer et démocratiser l’accès aux sources qui fondent notre patrimoine culturel (CDIM, 2003). Le catalogue des fonds culturels numérisés (MCC, 2001-2003) témoigne de l’ampleur des opérations menées depuis 1997 par tous les organismes sous tutelle de ce ministère. Les collectivités territoriales ont également lancé de vastes opérations, qui concernent par exemple les millions de pages des registres de l’état civil et des registres paroissiaux (Dhérent, 1999-2001) conservés dans les services d’archives départementales. Des documents plus anciens sont également en cours de numérisation (Dhérent, 1999; Clavaud, 2001).

La mise en ligne des fichiers numériques pour une consultation gratuite est souvent l’objectif affiché de ces projets. Gallica [1]en est un exemple: la Bibliothèque nationale de France y offre en ligne des millions de pages, soit des dizaines de milliers d’ouvrages, ainsi que des pièces isolées parfois difficiles d’accès autrement. Cependant, toutes les institutions n’ont pas ces moyens.
[IMG]file:///E:/RACHID/Navimages_files/barre_paragraphe.gif[/IMG]4
C’est dans ce contexte que le projet Navimages [2]est né, en 2002. Il résulte d’une collaboration entre des institutions publiques (Direction des archives de France, Centre historique des archives nationales, Centre des archives d’Outre-Mer) et d’une société privée (AJLSM). Plusieurs applications sont réalisées ou à l’étude, et les outils logiciels (une visionneuse, une base documentaire, un « collecteur » d’images) sont disponibles sous licence libre, afin que toute organisation puisse se les approprier. Il s’agit de donner les moyens de diffuser des ressources numériques, sans engager de frais de licence, ni d’efforts démesurés pour préparer et décrire des ressources.
2. Problématique

Le projet Navimages est issu d’une problématique en cinq volets. D’un côté des volets fonctionnels, à savoir la nécessité de gérer correctement des lots d’images, potentiellement volumineux, le besoin de recherche documentaire efficace, et la nécessité de tenir compte d’une forte variabilité des caractéristiques des images traitées. D’un autre côté, des volets issus du contexte dans lequel évolue la Direction des archives de France, principal initiateur du projet, à savoir l’emploi de logiciels libres et une architecture distribuée utilisant le web.
Les bases de données d’images (ou plus généralement d’objets multimédias) ne manquent pas de satisfaire leurs publics. Elles associent une description documentaire plus ou moins riche à un fichier informatique (ou à quelques-uns, quand l’application gère plusieurs versions, plusieurs formats). Ce texte permet aux utilisateurs d’effectuer des recherches sur des zones descriptives telles que les légendes, les mots-clés, les catégories, les auteurs, etc. Cette approche reste une référence, mais elle devient problématique lorsque la description individuelle des images n’est pas disponible. Ceci peut arriver pour plusieurs raisons:
  • – les ressources humaines nécessaires ne sont pas (encore?) disponibles, par exemple lorsqu’il y a plusieurs centaines de registres administratifs;
  • l’effort est en cours, les images sont déjà consultables, les descriptions s’enrichissent;
  • la description individuelle des images n’est pas pertinente, par exemple pour un livre.
Il existe donc des collections documentaires numérisées intéressantes, où chaque image n’est pas décrite individuellement. Il faudrait pouvoir les consulter de manière souple et agréable, au moins en les feuilletant. De plus, l’absence de notice individuelle ne signifie pas une complète absence de description. Les éléments sont rarement regroupés par hasard. Un lot ou une série d’images est déjà une entité documentaire, susceptible d’information signifiante (ces images concernent un lieu, une personne, correspondent à une période chronologique, à un petit nombre de correspondants, à un chapitre de livre…).
Pour des archivistes, cette approche est évidente; des standards internationaux en témoignent. La norme ISAD (G) (CIA, 2000) indique ainsi une liste des éléments de données à utiliser pour renseigner une unité documentaire (généralement constituée de plusieurs pièces). Ces champs s’articulent en XML, avec la DTD EAD (SAA, 2002.), permettant d’exprimer des imbrications et des hiérarchies difficiles à représenter efficacement dans des bases de données.
Les logiciels de gestion électronique de documents du marché n’apportent pas de solution satisfaisante à de tels besoins. D’abord, parce qu’ils se fondent généralement sur des modèles de données tabulaires (peu compatibles avec l’ordre hiérarchique de XML). De plus, la visualisation qu’ils offrent est adaptée à l’image unique, avec parfois des vues mosaïque, mais ils prévoient rarement des navigations textuelles, comme par exemple des liens entre images, ou des regroupements par sujets.
Un navigateur de séries d’images, parce qu’il doit gérer correctement des descriptions documentaires de ces séries, fera nécessairement usage des techniques habituelles de recherche documentaire, sans révolutionner cette discipline mais sans toutefois faire de compromis sur la souplesse de la recherche. Le seul aspect un peu particulier à bien intégrer à la fonction de recherche documentaire est la présence de descriptions hiérarchisées (l’approche archivistique par exemple), ou à tout le moins de collections organisées de manière hiérarchique.
Il est par ailleurs fondamental d’offrir des outils qui tiennent compte de la variabilité des images. Chaque projet de numérisation observe ses propres règles techniques (couleurs, format, définition des images), conditionnées par la nature des sources et les moyens disponibles (temps, capacités de stockage…).
Par exemple, à partir de registres d’état civil du XIXesiècle microfilmés en négatif, le plus souvent on produira des images numériques en niveaux de gris pour restituer correctement les textes à l’encre plus ou moins pâlie sur du papier plus ou moins blanc (JPEG 300 dpi). On pourra aussi préférer un simple format noir et blanc compressé sans perte (TIFF 600 dpi), ce qui demande une visionneuse qui supporte le format, et qui lisse correctement les bords.
S’il s’agit de cartes géographiques anciennes, de format important (proche du mètre), l’information est à la fois très dense et très finement portée sur le support (légendes, traits, noms de lieux, échelle, etc.). Il faut alors des images en couleur de large taille, à une résolution importante (supérieure à 400 dpi à partir de l’original, et bien sûr beaucoup plus si l’on part d’un cliché). On traite alors des fichiers de plusieurs mégaoctets, voire quelques dizaines de mégaoctets.
La variabilité technique est un aspect, bien sûr, mais d’un point de vue documentaire, une carte géographique et un registre d’état civil ne se consulteront pas pour les mêmes raisons, avec les mêmes outils. Pour une carte on s’intéressera surtout au zoom, aux déplacements par zone; pour une page de registre, on cherchera surtout un défilement facile pour arriver à la page que l’on cherche. Navimages doit se donner les moyens de pouvoir servir au mieux des images très différentes.
L’information patrimoniale est destinée à durer plus longtemps que les technologies. Il est indispensable de construire une architecture en pensant aux évolutions, aux conversions, à la récupération des données. A cette fin, il faut privilégier les standards. XML en est un pour les ressources descriptives; JPEG, TIFF et PNG sont des normes adaptées à la plupart des images.
En s’appuyant sur des standards partagés, on s’ouvre à des communautés d’utilisateurs et de développeurs, à des outils éprouvés et concurrents, à une informatique qui ne dépend plus de la seule volonté des éditeurs. Le terme logiciel libreexprime assez bien cet esprit, et il s’agit d’un élément essentiel du projet Navimages. Il fait d’abord référence à « la liberté pour les utilisateurs d’exécuter, de copier, de distribuer, d’étudier, de modifier et d’améliorer le logiciel » (Free Software Foundation, 2002). Plus précisément, le logiciel est « gratuit », sans frais de licence à la copie et la distribution; mais surtout, il est livré avec les sources. Ceci permet à chacun d’étudier et d’adapter le code à ses besoins, et s’il le souhaite, de rendre à la communauté, en informant sur les problèmes rencontrés, en contribuant au projet par du code ou de la documentation. Cette logique d’intérêt général contribue à la performance et la pérennité des systèmes. Par rapport à une couche logicielle sur une application commerciale (par exemple une base des données très puissante), ou dans un système particulier (Windows, Mac…), un développement logiciel à base d’outils libres et de standards promet plus de portabilité, plus d’utilisateurs critiques et de contribution au développement.
Enfin, le besoin d’une architecture distribuéen’est pas directement issu d’un souci de pérennité. On pourrait envisager Navimages sous la forme d’une application hors ligne. Mais alors, on ne pourrait plus satisfaire la volonté de diffuser au plus large public possible les ressources numérisées, avec leurs descriptions. N’est-ce pas souvent l’un des objectifs principaux d’un projet de numérisation? Aujourd’hui, une telle architecture passe nécessairement par le web ou ses technologies et normes associées. Une architecture webpeut se définir par un trio de protocoles: HTTP pour le transport des données; URL pour l’adressage des ressources; HTML pour la représentation des informations transportées. Elle peut également se définir par un trio d’applications: navigateur web pour la consultation, éventuellement complété par des modules externes; serveur web pour l’envoi des données demandées par le navigateur; système applicatif couplé au serveur web et à des sources de données pour offrir des services dynamiques. Le principal intérêt de cette architecture est son universalité, et ce à deux niveaux: la quasi-totalité des postes informatiques sont équipés d’un navigateur web; de nombreux postes informatiques sont reliés au réseau internet (plus qu’à tout autre réseau) et peuvent ainsi utiliser une architecture web distribuée.
3. Architecture et fonctionnalités

Navimages peut se présenter comme un outil relativement intégré. Pour l’utilisateur, il s’agit d’un site navigable, usant des conventions ergonomiques habituelles. Pour l’administrateur, cela peut se ramener à un seul répertoire sur son serveur.
Cependant, l’autonomie des modules est un point fort de l’architecture. Une application Navimages comporte:
  • une base documentaire: des documents rédactionnels ou des informations structurées, navigables et cherchables, reliés aux images;
  • un collecteur: des collections d’images, ordonnées en arbres et séries, avec des services d’interrogation, de conversion et d’administration;
  • lavisionneuse: un greffon s’intégrant à un navigateur internet, pour explorer une image (zoom, défilement, impression), et communiquer avec les serveurs (feuilletage, navigation).
Cette distinction des modules permet de ne pas lier un effort de traitement documentaire à un seul environnement monolithique. Ainsi, une base documentaire doit pouvoir être installée et interrogée, indépendamment des collections d’images. Il peut arriver que les ressources visuelles ne soient pas autorisées à la diffusion sur internet (disponibles uniquement en intranet), ou qu’elles soient trop lourdes pour une consultation confortable, ou qu’elles soient seulement en partie disponibles. Les notices gardent cependant un intérêt public, ne serait-ce que pour informer sur la présence des sources, et l’endroit où elles peuvent être consultées [3]La visionneuse est configurable selon les images à consulter, et peut s’utiliser hors ligne. Ainsi, elle peut accompagner une distribution de documents sur cédérom, facilitant l’exploration visuelle et la navigation. Le collecteur dispose d’outils pour traiter de grandes quantités de fichiers et les décrire sommairement. Il peut très bien être utilisé pour préparer des collections d’images, simplement servies par un serveur statique.
Navimages est distribué avec une licence libre (GPL) et n’intègre que des composants logiciels libres. Chacun peut donc modifier une application pour l’adapter à ses besoins, ou contribuer à l’outil. Cette approche, au-delà de ses mérites en termes de pérennité et d’indépendance par rapport aux éditeurs, constitue également un excellent moyen d’offrir une application très ouvertesur son environnement extérieur.
3.1. La base documentaire

Dans la plupart des scénarios, la base documentaire est l’accès principal aux collections. Une application peut proposer une navigation complète des images, des parcours choisis, mais Navimages est surtout conçu pour la recherche simple ou avancée (formulaire), afin d’accéder rapidement au lot d’images que l’on cherche.
Ce module de Navimages est en fait une application conçue à l’aide de la plateforme SDX [4]un outil de recherche et de publication d’information structurée en format XML. Cette plate-forme, développée à l’initiative de la mission de la recherche et de la technologie du ministère de la Culture et de la communication, est déjà largement utilisée dans les services documentaires patrimoniaux, et en particulier à la Direction des archives de France, et son utilisation pour Navimages permet donc de mutualiser des efforts déjà consentis dans le cadre d’autres projets.
Le module base documentaire de Navimages supporte pour l’instant deux modèles descriptifs:
  • la DTD EAD pour des collections fortement hiérarchisées;
  • une structure platede type base de données documentaires.
Ce choix de la DTD EAD se justifie pour plusieurs raisons. D’abord, parce que c’est l’outil XML des archivistes, et Navimages est notamment pensé pour répondre aux besoins spécifiques de la numérisation de fonds d’archives. De plus, l’EAD s’avère un outil très adapté pour décrire des collections d’images en général, notamment grâce à son approche hiérarchique basée sur la récursivité d’éléments descriptifs de structure semblable.
Matériellement, un fonds d’archives est formé de séries, comportant plusieurs dossiers, réunissant des pièces… soit souvent des dizaines de milliers de pages, et donc d’images. Prenons l’élément EAD Component <c> (composant), il porte le nécessaire pour une description documentaire. De plus tout composant peut aussi contenir un composant, et ainsi de suite sans limite. Cela signifie qu’il y a un héritage récursif des descriptions, le fonds renseignant la série, etc., pour arriver à la pièce – la plus petite unité archivistique, qui peut déjà comporter plusieurs pages.
Un composant <c> peut aussi être lié à des ressources numériques (Digital Archival Object Group, groupe d’objets archivistiques numériques, <daogrp>). On comprend alors que l’usage de cette DTD appelle naturellement une application qui sache servir les images numériques que l’on attend à chaque niveau d’une hiérarchie. Bien sûr, elles ne peuvent pas être affichées toutes en même temps, mais le nécessaire de navigation sera fourni pour que l’on puisse les feuilleter, en gardant le contexte hiérarchique de ces descriptions.
Figure 1

Exemple partiel d’un document ead avec lien vers un lot d’images
[IMG]file:///E:/RACHID/Navimages_files/barre_paragraphe.gif[/IMG]25
On souhaiterait bien sûr qu’un tel document EAD puisse toujours être renseigné avec soin par des professionnels des archives, parfois aussi, il faudra se résigner à ce qu’un squelette soit généré automatiquement à partir d’une liste de cotes, ou même des noms d’images, pourvu qu’il y ait une loi déterministe sur laquelle une machine puisse s’appuyer; ce que peut faire Navimages.
Lorsqu’il existe déjà des descriptions tabulaires pour des objets nettement distincts et sans liens entre eux, le recours à l’EAD deviendrait artificiel, et même, peu pratique. C’est souvent le cas dans la publication de registres, tel que pour le projet Etat civil des Français d’Algérie décrit ci-dessous. Les Archives nationales de France fournissent d’autres exemples [5]
Pour l’essentiel, il s’agit que la source documentaire soit:
  • divisible en unités qui gardent un sens;
  • liée à des images;
  • avec du texte, si possible structuré.
La recherchedans les ressources descriptives peut être paramétrée de diverses manières, notamment en exploitant toutes les possibilités offertes par SDX. Au départ, Navimages offre systématiquement la recherche en texte intégral et dans les intitulés, deux zones de recherche quasi universelles. Ensuite, lorsque les descriptions sont en format EAD, le gestionnaire peut permettre des recherches dans des zones telles que les dates extrêmes, le producteur, la cote du document original, le type de document, des mots matières, etc. Les traitements EAD proposés par Navimages s’appuient sur les puissantes librairies d’indexation, de recherche et d’affichage de documents EAD proposées par le projet PLEADE [6]
Au-delà de la recherche, ce sont les fonctions de consultation qui proposent un défi plus intéressant pour l’outil. En effet, deux aspects doivent être considérés et manipulés de manière à les rendre clairs et efficaces pour l’utilisateur:
  • les unités documentaires retournées comme résultat de recherche peuvent être hiérarchisées, en particulier lorsque les ressources descriptives sont en format EAD;
  • trois niveaux d’information peuvent être disponibles en résultats: une fiche brève qui résume l’unité retrouvée (par exemple l’intitule et la date); la ressource descriptive au complet (par exemple un élément <c/> dans le document EAD); la ou les séries d’images référencées par cette unité documentaire.
Par une utilisation judicieuse de l’espace écran et par des affichages ergonomiques, Navimages offre à l’utilisateur une interface tout à fait compréhensible et utilisable. De plus, le gestionnaire de l’application peut choisir entre différents modèles de présentation, car ce ne sont pas toutes les collections numérisées qui bénéficieront des mêmes éléments d’interface ou des mêmes approches ergonomiques.
3.2. La visionneuse

Le second module de Navimages est une visionneuse d’images, à laquelle on demande quelques fonctionnalités relativement classiques:
  • navigation dans la collection: image précédente, suivante, première ou dernière, et parfois parents ou enfants;
  • exploration d’une image: zooms, défilements, rotations, avec une fenêtre réduite de repérage.
Il existe déjà de nombreux greffons qui répondent à ce besoin. Cependant, des développements spécifiques étaient nécessaires pour assurer la communication avec le collecteur et la base documentaire afin, en particulier, d’assurer l’exploration de grandes images, ou de mémoriser des paramètres de visualisation (selon le choix du client ou le type d’images). Il était possible de développer un greffon spécifique, que l’utilisateur aurait dû télécharger avant de consulter la première image. Un autre choix a été fait.
De plus en plus de navigateurs ont désormais un greffon pour interpréter des documents SVG [7] (Scalable Vector Graphics). Il s’agit d’un format XML du W3C pour représenter des dessins vectoriels à deux dimensions. Chaque élément graphique peut être lié à des scripts, pour être animé ou modifié (dans le même esprit que HTML/DOM/EcmaScript). Navimages traite essentiellement des images pixellisées (bitmap), mais l’utilisation de SVG se justifie de plusieurs manières.
[IMG]file:///E:/RACHID/Navimages_files/barre_paragraphe.gif[/IMG]31
On constate d’abord que les greffons SVG assurent aussi un excellent rendu des formats matriciels (JPEG, PNG…), et le format prévoit des fonctions pour ajouter un filtre, du contraste, etc. Tout cela est accessible par scripts, si bien qu’un document SVG peut effectivement devenir une petite application autonome. Ce qui ne gâte rien, les barres, les boutons, toute l’interface utilisateur peut être décrite en SVG, en un seul fichier. Il n’est pas nécessaire de générer des images différentes, pour peu que l’on veuille changer le symbole d’un bouton. Et pour modifier l’apparence, il suffit d’éditer du code CSS, pour mettre la visionneuse aux couleurs du site qui l’héberge.
Par ailleurs, l’utilisation d’un format XML, permet de générer la visionneuse en entier, pour peu que l’environnement ait accès à un moteur XSL. Cela peut être une transformation préalable, à l’installation d’une application adaptée à un certains types d’images. On peut aussi proposer des transformations dynamiques à la demande de l’utilisateur, en environnement SDX par exemple. Il est possible d’offrir des interfaces personnalisées, en termes de fonctionnalités ou d’apparence, et ce de façon très simple.
3.3. Le collecteur

Le troisième module de Navimages est le collecteur, dont le rôle est:
  • d’organiser les collections;
  • de renseigner les collections (métadonnées minimales);
  • de préparer les collections à la diffusion (conversions, dimensionnement…).
Ce collecteur fonctionne en mode statique, c’est-à-dire qu’il prépare à l’avance les images pour qu’elles puissent ensuite être utilisées par la base documentaire et la visionneuse, ou tout autre outil. Pour ce faire, il s’appuie sur deux puissantes librairies:
  • – Ant [8], un environnement d’exécution de scripts souple, puissant et très extensible;
  • – ImageMagick [9], une librairie graphique qui permet de manipuler des images par lots, avec des fonctions simples (modifier la taille par exemple) ou complexes (fragmenter une image en plusieurs parties).
Les fonctions d’organisationde collecteur permettent de conserver les images en ordre, dans une hiérarchie et des séries. On ne saurait trop conseiller de toujours avoir une bonne politique de nommage des images, afin que chaque nom soit unique à l’échelle de son utilisation, qu’il permette de reconstruire sa provenance s’il perdait son contexte, et qu’il conserve l’ordre alphabétique de sa source. Navimages a des outils pour renommer des fichiers selon des expressions régulières, tout en en lisant des informations d’indexation ou de récolement (fichiers texte délimité, XML, SQL sont supportés).
Pour gérer cette organisation, Navimages utilise un système de stockage connu de tous, disponible dans tous les environnements avec de nombreux outils, et qui ne manque pas de sémantique: le système de fichiers. Ce choix permet d’accéder aux images, même si aucun serveur n’est démarré. Un éditeur peut composer ses collections, avec l’explorateur de fichiers de son choix; on peut aussi établir des hiérarchies automatiquement.
Toutefois, il manque encore une information importante, un ordre éditorial dans chaque répertoire. Considérons le cas de livres. Une application bibliographique au format MARC peut tout à faire suffire d’instrument de recherche dans cette « collection d’images ». Cependant, il n’est pas de la responsabilité d’une notice de garder la liste des pages, ainsi que la correspondance entre par exemple, la page VII de la préface, et le fichier p0017.tif. Il entre par contre dans le travail du collecteur de pouvoir retourner ce fichier dans le format demandé.
A cette fin, chaque répertoire (correspondant à une série) est renseigné par un fichier de métadonnées. XML se présente comme un format pratique pour conserver cette information, car il permet toujours d’ajouter des champs en cours d’exploitation, sans problème pour le reste du système. Le format utilise surtout les noms Dublin Core [10], et Navimages se fonde sur ces informations pour renseigner la visionneuse. C’est aussi un document portable, de grande utilité pour la vie future des collections.
Format, taille, définition, couleurs... on y porte la description « physique » d’une image numérique. Cette information n’a pas sa place dans les documents rédactionnels d’une base interrogeable. De plus, on peut les extraire automatiquement, depuis les fichiers eux-mêmes. C’est en conséquence que le « collecteur » s’emploie à les collecter, ne serait-ce que pour les conversions. Ce collecteur va également recenser, lorsqu’on lui demande, les différentes parties d’une image qu’il aura fragmentée.
Sur une collection dûment organisée et renseignée, on peut ensuite préparer un arbre adapté à la diffusion, avec en particulier selon les cas, conversions dans des formats web (TIFF vers PNG), allègements (600 dpi vers 200 dpi), préparation de vignettes (100 x 150 px), fragmentation des images de grande taille pour les visualiser partie par partie dans un contexte où les ressources (bande passante par exemple) sont limitées…
Les opérations permises sont nombreuses; de manière générale Navimages donne accès à toutes les fonctionnalités accessibles en ligne de commande avec ImageMagick. Toutefois, les opérations les plus courantes (redimensionnement, changement de format, fragmentation) sont offertes à l’aide de syntaxes simplifiées.
En terminant, soulignons que le collecteur produit essentiellement des images organisées hiérarchiquement, de même que des métadonnées en format XML; il va sans dire que ces fonctions pourraient très bien être assurées par d’autres outils, voire manuellement, lorsque le contexte le permet.
4. Exemples d’applications

Le développement de Navimages s’effectue à l’occasion de trois projets, mais d’autres applications sont aussi prévues. La variété des problèmes à traiter justifie d’abord le besoin d’un tel outil, mais aussi, donne l’occasion de mieux généraliser et factoriser les fonctionnalités.
4.1. Etat civil des français d’algérie

Les registres d’état civil des Français d’Algérie ont été microfilmés vers la fin de la présence coloniale française. Les bobines ont été rapatriées en France, où elles sont gérées par le service central de l’Etat civil de Nantes, dépendant du ministère des Affaires étrangères. Tous les actes ne sont pas diffusables publiquement (ainsi que leurs reproductions argentiques ou numériques [11]). Cependant, les actes centenaires sont destinés à être versés au Centre des archives d’Outre-Mer (CAOM) à Aix-en-Provence. Le CAOM et le service central de l’Etat civil ont décidé de procéder à la numérisation de l’intégralité des microfilms. Ainsi depuis le mois de juin 2003, une partie de cet état civil est consultable en format numérique, à l’aide de Navimages, dans la salle de lecture du CAOM. Cette partie correspond aux actes centenaires déjà numérisés, puisque l’effort de numérisation ne prendra fin qu’à la fin de l’année 2004.
Le nombre total d’images d’actes centenaires en 2003 est estimé à 600 000; le nombre total d’images à produire (et donc à consulter) avoisinera les 1 500 000; pour environ 3 500 000 actes. Ces chiffres importants sont comparables à ceux des corpus d’actes d’Etat civil conservés dans les services français d’archives départementales. La numérisation produit une image pour chaque vue du microfilm, ce qui correspond à deux pages des registres. Les images sont en format JPEG, avec une taille d’environ 4 400 x 3 300 pixels, en niveaux de gris. Les fichiers ont un poids de l’ordre de 900 Ko en moyenne.
L’approche documentaire préconisée est une description à l’acte, c’est-à-dire que chaque acte (naissance, mariage, décès, etc.) fait l’objet d’une notice descriptive où l’on retrouve des informations sur la commune, l’année, le type d’acte, le type de registre, les personnes concernées (nom et prénom), et une références aux images. Il n’a pas été possible d’assurer une indexation automatique fiable des registres manuscrits, le travail est effectué humainement, par un prestataire, vérifié par un archiviste, et toujours susceptible de correction en cours d’exploitation (selon les remarques des utilisateurs). Malgré le détail de ces « notices », il ne s’agit pas de descriptions individuelles mais de descriptions de lots d’images.
En effet, chaque vue présente un registre ouvert, deux pages. Un feuillet peut contenir plusieurs actes, un acte peut se poursuivre sur plusieurs feuillets. Une manipulation très précise des données est nécessaire pour retrouver un acte et son lien aux images, ensuite les utilisateurs le montrent, il est très simple de chercher un nom, une commune, que l’on soit généalogiste ou chercheur.
Figure 2

[IMG]file:///E:/Navimages_files/loadimg(1).php[/IMG]
Ecran de recherche et visionneuse Navimages, application « Etat civil des Français d’Algérie »
4.2. Projet champlain

Les Archives nationales du Canada, les Archives nationales du Québec, les Archives nationales de France (Centre des archives d’Outre-Mer et Centre historique) et plusieurs services d’archives départementaux français situés sur la façade Atlantique collaborent dans le cadre d’un projet visant à commémorer la venue de Champlain au Canada en 1604. Ces institutions rendent disponibles, sur le web en format numérique, des documents d’archives de l’époque de la Nouvelle France, tels que des traités, de la correspondance, des cartes et plans, etc. Navimages est au cœur de cette application documentaire lancée le 7 novembre 2003.
Dans ce projet, une série d’images correspond à un document d’archives numérisé. Le nombre d’images par série est de façon générale assez faible, allant d’une seule image (le cas des cartes et plans, par exemple, qui seront tous décrits individuellement) à quelques dizaines dans le cas des documents textuels plus volumineux. Les caractéristiques techniques de ces images sont assez variées, mais deux tendances se dessinent: des images en niveaux de gris, au format JPEG, pour les documents numérisés à partir de microfilms, et des cartes anciennes, numérisées en haute définition et en couleur, en format JPEG également.
Les descriptions documentaires sont en format XML respectant la DTD EAD. Le grand nombre de documents concernés (plusieurs dizaines de milliers dès le lancement) exigera des fonctionnalités de recherche précises et performantes. L’une des originalités de l’architecture documentaire de ce projet est que les documents descriptifs en format EAD contiennent des références explicites aux images des documents qu’ils décrivent, références basées sur des adresses URL. De plus, le serveur hébergeant l’application sera situé à Paris et hébergera les descriptions en EAD et la base documentaire, alors qu’une partie des images resteront sur place au Canada. Nous sommes donc dans une situation où le collecteur ne peut pas connaître a prioritous les objets numériques qu’il manipulera à l’aide des références aux images présentes dans les documents EAD.
4.3. Fonds d’archives de la période du premier empire

Ce projet, pour l’instant baptisé Napoléon, s’inscrit dans le cadre de la célébration du bicentenaire du sacre de Napoléon 1erLe Centre historique des archives nationales (CHAN), qui conserve les fonds d’archives des administrations centrales et de nombreux fonds privés de personnalités de cette période, contribuera notamment à ce programme par la mise en ligne progressive à partir de la fin de l’année 2003, des instruments de recherche et images numériques des fonds d’archives concernés. Le CHAN bénéficie d’un mécénat de la Fondation Napoléon [12]12 pour former les contenus de l’application informatique. L’application informatique sera une application SDX qui utilisera PLEADE et Navimages. L’objectif est de permettre aux chercheurs et au grand public de consulter ces corpus de sources primaires beaucoup plus facilement, avec des fonctionnalités d’interrogation précises et nouvelles, et de les mettre en relation et confronter comme il n’est pas possible de le faire en salle de lecture.
Le cœur de ces contenus sera composé de l’inventaire en format EAD du fonds d’archives Napoléon, dont une version sommaire est déjà en ligne en HTML statique sur le site web du CHAN [13]qui donnera accès aux images de ce fonds. Les 169 premiers cartons de ce fonds qui en compte 222 ont déjà été numérisés à partir d’un microfilm, ce qui a donné environ 85 000 images niveaux de gris, pour l’essentiel des documents manuscrits. Lorsque la totalité du fonds aura été numérisée, le nombre d’images sera d’environ 125 000, soit en moyenne 560 images pour un carton de documents originaux. Chacune de ces images pèse environ 900 Ko, pour une définition de 2 900 par 3 000 pixels. Les séries d’images correspondront, à l’intérieur d’un carton, soit à des dossiers d’archives constitués, soit à des pièces individualisées comportant un nombre important de pages; le nombre d’images par série sera de quelques dizaines à quelques centaines. La description XML/EAD déjà produite sera donc affinée par le CHAN pour parvenir à une description de chaque série d’images. Une indexation dans le corps de la description sera également réalisée en utilisant les éléments ad hocde la DTD EAD.
Outre le fonds Napoléon, l’application accueillera progressivement en 2004 les descriptions et images numériques d’autres fonds privés également conservés au CHAN, notamment des fonds Joseph Bonaparte (frère de Napoléon 1er, roi de Naples puis d’Espagne: 381AP), fonds de la famille Murat (depuis Joachim Murat, roi de Naples: 31AP), fonds de la famille Ney (depuis le maréchal Michel Ney: 137AP). Une sélection de pièces d’archives d’intérêt majeur (actes notariés relatifs à la famille Bonaparte, textes de traités et constitutions, cartes des états annexés, mais aussi objets tels que médailles...) sera également traitée, chaque pièce étant décrite et rendue accessible individuellement, avec le cas échéant des liens de la description de la pièce vers la description du fonds (par exemple le fonds Napoléon) dont elle a pu être extraite pour être rangée en réserve. Enfin il est prévu d’intégrer à l’application à tout le moins la description sommaire des fonds publics de l’administration centrale de l’époque.
Navimages est parfaitement approprié pour une telle collection d’images numérisées et pour une description de cette nature. Puisque d’une part le CHAN doit travailler le document EAD afin de préciser la plupart des descriptions et que d’autre part les images issues de la numérisation doivent être revues et réorganisées, la relation entre le document EAD et les séries d’images sera encodée explicitement, à l’aide des éléments <daogrp/> et <daoloc/> tels qu’illustrés dans la section 3.1.
5. Perspectives d’avenir

Outre les trois applications décrites ci-dessus, d’autres instanciations sont déjà prévues, et verront le jour fin 2003 ou en 2004. On peut déjà mentionner que le Centre historique des archives nationales utilisera Navimages pour mettre en ligne:
  • les images des 3 500 répertoires des notaires parisiens des XVe-XXesiècles, dont 271 registres sont déjà numérisés (soit déjà 104 000 images pour un million au total). Ces répertoires seront décrits en EAD et indexés selon des règles précises, les séries d’images correspondront à des subdivisions chronologiques (année ou mois) dans l’enregistrement des actes;
  • les images des 20 000 décrets de naturalisation datant des années 1883 à 1930 (150 000 pages de documents manuscrits ou dactylographiés en cours de numérisation directe). Ces décrets seront décrits dans un format XML simple issu d’une base de données documentaire. Une série d’images correspondra à un décret (soit en moyenne 7 images par décret);
  • les images couleur en cours de production dans le cadre du projet ARCHIM [14], déjà en partie visibles sur internet au sein d’une application documentaire classique sous le logiciel MISTRAL. Les séries d’images seront de taille et contenu variable, de même que les documents XML/EAD décrivant les archives originales. Parmi ces images, figurent notamment les 3 208 images couleur de poids et de définition importants correspondant aux 62 atlas des routes royales françaises au XVIIIesiècle, corpus connu sous le nom de « atlas de Trudaine ».
A partir de l’architecture et des fonctionnalités décrites ci-dessus, et en fonction notamment des besoins exprimés par la communauté d’utilisateurs qui pourrait se former, beaucoup d’extensions pourraient être imaginées et développées:
  • le support de la DTD BiblioML (MCC, 2001-2003), DTD XML pour les références bibliographiques, basée sur le format UNIMARC, comme modèle de description des documents numérisés, afin de permettre une utilisation de Navimages au sein d’applications bibliographiques, pour gérer et diffuser des séries d’images correspondant aux parties constitutives d’un livre;
  • des fonctionnalités nouvelles pour l’utilisateur telles que: la constitution d’un « panier » de séries d’images et descriptions associées répondant aux requêtes, afin d’enregistrer le contenu de ce panier sur le poste client; la juxtaposition, au simple passage de la souris sur l’image, de la ligne de texte contenu dans le document original numérisé et de la transcription de ce texte, pour les manuscrits les plus difficiles à lire, comme déjà proposé sur le site de l’Ecole nationale des Chartes [15].
D’autres fonctionnalités avancées, impliquant notamment la collaboration avec des centres de recherche, et évoquées dans d’autres articles de ce numéro spécial, pourraient être offertes:
  • l’intégration de modules d’annotation ou d’indexation coopérative, permettant à l’utilisateur final de compléter la description XML des fichiers numériques et à l’outil de rendre ces compléments disponibles pour les autres utilisateurs finaux;
  • l’intégration à l’outil de gestion de Navimages de moteurs d’indexation automatique de documents manuscrits;
Sur ce dernier point, on sait qu’aujourd’hui, de nombreux projets de numérisation cherchent à obtenir des produits numériques qui vont au-delà de l’image brute obtenue du processus de numérisation. En particulier lorsque les documents d’origine sont imprimés avec des caractères réguliers et bien définis, où il est bien connu que les techniques de reconnaissance optique de caractères permettent d’obtenir des résultats intéressants. Ces techniques sont toujours l’objet de recherches, en particulier pour améliorer le produit obtenu de la ROC (structuration des documents par exemple) ou pour l’appliquer à des corpus plus difficiles (manuscrits par exemple). D’autres projets cherchent à mettre en œuvre, voire améliorer, des techniques de recherche utilisant la forme des images, formes bien entendu reconnues automatiquement par des procédés informatiques. Les mêmes techniques peuvent être utilisées a prioriafin de produire une forme d’indexation automatisée, imparfaite mais utile.
Toutes ces techniques intéressantes et prometteuses ne limitent pas l’intérêt d’un outil tel que Navimages car les collections d’images numériques seront encore d’actualité pour une période assez longue, avant que les autres techniques ne soient couramment mises en œuvre sur des quantités importantes d’images. Une fois ces techniques fréquemment utilisées, diverses combinaisons pourraient même être envisagées entre les fonctionnalités de Navimages et la recherche dans les résultats de la ROC. On pourrait par exemple imaginer que l’utilisateur final affine sa recherche en lançant une requête sur un mot au sein du texte contenu dans la ou les séries d’images précédemment trouvées grâce à une recherche dans la description XML des séries. Ou bien, dans l’autre sens, que l’utilisateur lance directement dans une grande collection d’images une requête sur un terme indexé par ROC, et que Navimages retourne des séries d’images constituées dynamiquement, avec les descriptions XML associées.

6. Conclusion

Il est d’ores et déjà clair que Navimages, en tant qu’outil générique, constitue une réponse appropriée aux besoins de nombreux organismes – tous ceux qui détiennent et veulent diffuser des corpus d’images organisés et décrits par séries. S’il est issu de besoins exprimés par des services d’archives, il peut donc être utile à d’autres: centres de documentation, bibliothèques, musées, agences photographiques, etc. Comme il est conçu avec des logiciels libres sur la base de standards technologiques internationaux, il pourra également être utilisé hors de France et dans des contextes non francophones.













ÇáÊÚÏíá ÇáÃÎíÑ Êã ÈæÇÓØÉ yahiaoui55 ; Mar-31-2009 ÇáÓÇÚÉ 03:29 AM ÓÈÈ ÂÎÑ: ÇáÊÞÏíã
  ÑÏ ãÚ ÇÞÊÈÇÓ
 

ãæÇÞÚ ÇáäÔÑ (ÇáãÝÖáÉ)


ÇáÐíä íÔÇåÏæä ãÍÊæì ÇáãæÖæÚ ÇáÂä : 1 ( ÇáÃÚÖÇÁ 0 æÇáÒæÇÑ 1)
 

ÊÚáíãÇÊ ÇáãÔÇÑßÉ
áÇ ÊÓÊØíÚ ÅÖÇÝÉ ãæÇÖíÚ ÌÏíÏÉ
áÇ ÊÓÊØíÚ ÇáÑÏ Úáì ÇáãæÇÖíÚ
áÇ ÊÓÊØíÚ ÅÑÝÇÞ ãáÝÇÊ
áÇ ÊÓÊØíÚ ÊÚÏíá ãÔÇÑßÇÊß

BB code is ãÊÇÍÉ
ßæÏ [IMG] ãÊÇÍÉ
ßæÏ HTML ãÚØáÉ

ÇáÇäÊÞÇá ÇáÓÑíÚ


ÇáÓÇÚÉ ÇáÂä 01:56 PM.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd. ÌãíÚ ÇáÍÞæÞ ãÍÝæÙÉ áÜ : ãäÊÏíÇÊ ÇáíÓíÑ ááãßÊÈÇÊ æÊÞäíÉ ÇáãÚáæãÇÊ
ÇáãÔÇÑßÇÊ æÇáÑÏæÏ ÊõÚÈÑ ÝÞØ Úä ÑÃí ßÊøÇÈåÇ
ÊæËíÞ ÇáãÚáæãÉ æäÓÈÊåÇ Åáì ãÕÏÑåÇ ÃãÑ ÖÑæÑí áÍÝÙ ÍÞæÞ ÇáÂÎÑíä