Guide Technique Général

Cette page contient quelques recommandations générales pour la numérisation et l'enreigstrement des données. En Décembre 2009, les responsables de Corpus IR et du TGE Adonis rédigent un "Guide des Bonnes Pratiques Numériques" qui décrit les bases et exigeances minimales de l'interopérabilité. Ce guide est aujourd'hui toujours globalement valable pour les Consortiums de l'Infrastructure de Recherche Corpus. En voici, dans leurs grandes lignes, les principes élémentaires. Nous renvoyons le lecteur aux guides de bonnes pratiques sur le site du TGE Adonis.


Recommandations générales pour la numérisation

Les étapes principales de chaque projet numérique sont les suivantes :

  • Sélectionner les documents à traiter (corpus de fait ou créé, cohérence du regroupement, respect du contenu et des droits).
  • Définir des modes opératoires (recopie brute, corrections).
  • Choisir des formats d’enregistrement adaptés (non propriétaires, avec standards officiels ou de fait, indépendance vis-à-vis des logiciels et des plates-formes).
  • Définir un plan de nomenclature des fichiers (déterminer les noms des fichiers).
  • Numériser avec un cahier des charges adapté aux spécificités de l’objet.
  • Indexer et décrire les métadonnées. Souvent cette étape demande un investissement humain considérable. Il importe

a) de se conformer à une initiative existante et là aussi adaptée aux spécificités de l’objet (voir plus loin dans ce document)

b) de ne pas perdre le lien entre les métadonnées et le fichier numérique produit.

  • Annoter et commenter éventuellement les ressources produites.
  • Archiver de manière pérenne les données numérisées : l'OAIS (Open Archival Information System) est un modèle pour la gestion et l’archivage à long terme de documents numériques. Norme ISO 14721 :2002.
  • Construire des entrepôts de données : l’OAI-PMH (Open Archives Initiative Protocol for Metadata Harvesting), couplé aux descriptions utilisant à minima le Dublin Core simple (DC Element Set), est une solution simple, qui permet de faire de l'interopérabilité.
  • Placer les données numérisées dans le web de données en utilisant les principes du linked data et le modèle RDF de description des informations.

Recommandations particulières pour la description : Unicode

Les métadonnées descriptives doivent être encodées en Unicode UTF-8. Unicode est une norme développée par le Consortium Unicode, qui vise à donner à tout caractère de n’importe quel système d’écriture un nom et un identifiant numérique, et ce de manière unifiée, quelle que soit la plateforme informatique ou le logiciel. Le choix d’UTF-8 garanti au mieux que vos données seront lisibles sur n’importe quel système d’exploitation ou plateforme, si on dispose d’une police de caractères adéquate

Cette norme concerne l’encodage des caractères et non leur visualisation qui a besoin d’une police adaptée. Le choix d’UTF-8 n’a ainsi pas de répercussion sur la police que vous allez utiliser pour visualiser vos données sur l’écran. D’autres encodages existent (ISO 8859-1 et ASCII par exemple) mais ils sont beaucoup moins complets, particulièrement pour les langues anciennes ou rares.

Nomenclature des fichiers numériques

Une identification claire et en prévision de la réalisation d'inventaires doit être respectée. L'utilisation d'identifiants uniques est très importante : il s'agit, dès le nom du fichier, d'avoir une nomenclature unique. Ceci permet d’éviter la confusion entre fichiers. Nous faisons référence au document Écrire un cahier des charges de numérisation de collections sonores, audiovisuelles et filmiques édité par la BNF :

« Attribution d’un identifiant unique : dans un environnement informatique où chaque fichier doit pouvoir être "adressé" de façon univoque, un nom (ou numéro) unique devra être attribué à chaque document à numériser (par exemple : XX_000001). Volumaison: les différentes parties (volumes, bobines, cassettes…) d’un tout (le document, la cote, la référence…) font également l’objet d’une identification grâce à la subdivision d’un identifiant unique (par exemple : XX_000001_V1_1 ou XX_000001_V1_n, si n parties). D’autres choix pourront être faits, mais il est impératif de reporter automatiquement l’identifiant unique attribué sur le boîtier (s’il y en a un) et sur le support lui-même. En cas de volumes importants et pour la gestion ultérieure des supports, l’usage de codes à barres est souhaitable.

Il est possible, selon les supports et les renseignements dont on dispose, d’affiner encore à ce stade l’identification en précisant les notions de faces (cassette audio) ou de pistes (CD). Si ces informations ne sont pas disponibles ou suffisamment fiables, elles seront renseignées ultérieurement lors du transfert. »

Donc, quelle que soit la hiérarchie de dossiers et sous-dossiers dans lesquels vous allez placer vos fichiers numérisés ou les fichiers de métadonnées (voir ci-dessous) qui les accompagnent, veillez à ce que chaque fichier porte un nom unique. Veillez aussi à ne jamais utiliser des caractères spéciaux dans les noms des fichiers et évitez également les espaces. N’utilisez donc, dans vos noms de fichiers, que les lettres et chiffres a…z et 0…9. Le signe _ (underscore) est autorisé et recommandé pour distinguer des entités au sein du nom du fichier mais en cas d’utilisation sur le web l’underscore peut être confondu avec le soulignement propre au lien hypertexte.

Les métadonnées

Ce chapitre est issu du travail du centre de ressource numérique sur la description de l'oral (Lacito, Paris) dans le guide de 2009 du TGE Adonis.

Les métadonnées sont des données qui décrivent d'autres données. On les appelle aussi des descripteurs. Dans les bibliothèques classiques, les documents sont décrits à l'aide de notices bibliographiques où l'on identifie les auteurs, les éditeurs, les titres, les dates de parution, etc. Ces notices sont utiles tant aux bibliothécaires pour la gestion de leur fond, qu'aux usagers pour retrouver un ouvrage.

Pour un document numérique, et plus particulièrement dans le cadre d'une diffusion par Internet, ces notices portent le nom de « métadonnées », alors que les documents eux-mêmes sont nommés « ressources ».

Les documents électroniques prennent de plus en plus d'importance dans notre vie quotidienne et leur nombre ne fait qu'augmenter. Rechercher une « ressource » spécifique est devenu une tâche à la fois complexe et indispensable d'autant plus que cette recherche s'effectue maintenant dans des architectures distribuées (les « ressources » ne se trouvent pas toutes au même endroit physique, sur le même serveur). C'est dans ce contexte que les préoccupations de standardisation et de normalisation des pratiques de codage et d'échange de métadonnées trouvent leurs origines.

Des métadonnées génériques : le Dublin-Core

En 1995, à Dublin (Ohio), des représentants de communautés diverses, issus du monde des bibliothèques, de l'informatique et du web, se réunissent pour définir un noyau commun de métadonnées : le Dublin Core Metadata Initiative (DCMI), abrégé souvent comme « Dublin-Core » ou DC.

Le Dublin-Core est un ensemble de 15 descripteurs de portée très large et de sens très générique. Certains ont trait au contenu, d'autres à la propriété intellectuelle, d'autres enfin à l'instanciation. Cet ensemble de descripteurs a été normalisé au sein de l'ISO en 2003 sous le nom d’ISO Standard 15836-2003. Les 15 descripteurs sont les suivants :

  • Contributor
  • Coverage
  • Creator
  • Date
  • Description
  • Format
  • Identifier
  • Language
  • Publisher
  • Relation
  • Rights
  • Source
  • Subject
  • Title
  • Type

Des informations supplémentaires sur ces descripteurs peuvent être trouvées sur la page suivante : http://dublincore.org/documents/dces/

Ces éléments de base peuvent dans certains cas être jugés insuffisamment précis, il est alors possible d'utiliser un autre ensemble de « qualifiers » qui en précisent l'acception. Dublin-Core définit deux classes de qualifieurs :

  • Les « refinements » qui rendent plus spécifique le sens d'un élément. Par exemple, à la place de l'élément « date » il est possible d'utiliser un de ces refinements : created, valid, available, issued, modified, dateAccepted, dateCopyrighted, dateSubmitted.
  • Les schémas d'encodage, et les vocabulaires contrôlés comme par exemple le schéma « Point » qui permet de définir les propriétés d'un point géographique (coordonnées: longitude, latitude, altitude, référentiel, nom).

Le DC peut servir de base au Dublin Core dit qualifié dans lequel il est possible de typer les métadonnées, en utilisant les types de données proposés par le DCMI ou ses propres types de données définis dans un schéma XML (cf. ci-dessous).

Un fichier XML est un fichier texte mais dans lequel des balises, suite de caractères délimités par des chevrons, comme par exemple <Exemple_balise>  encadrent et structurent les zones de texte qui contiennent l’information. Par exemple, si nous voulions délimiter le titre d’un ouvrage, en utilisant les balises du Dublin Core, nous écririons :

<dc:title> La Géographie locale du notaire languedocien </dc:title>

Un schéma XML est un ensemble de rubriques (balises) qui sont prédéfinies et propres à ce schéma. La définition d’un schéma XML est assez similaire à la définition des champs dans une table de base de données.

 

Les données "texte"

Les types de données

Les données textuelles peuvent refléter des contenus très variables :

·       Textes linéaires

·       Textes structurés

·       Textes typés (poème en vers, théâtre, etc.)

·       Liste de mots

·       Dictionnaires

·       Etc.

Il s’agit donc aussi bien de textes « bruts » intéressants par leur contenu que de ressources linguistiques qui sont déjà organisées par une logique scientifique ou documentaire.

La numérisation

Les sources textuelles peuvent être de format très différent. On ne numérise pas de la même façon un atlas linguistique, un manuscrit médiéval ou une collection d’ouvrages reliés, au format identique ou non.

Une chaine de traitement spécifique doit être mise en place selon chaque format. Elle est toujours basée sur la captation par une image du contenu (pour le traitement de cette image, voir la partie « Images fixes »). Pour le dire rapidement, on numérise en format image la page d’un ouvrage, la feuille de manuscrit etc.

Selon les besoins et la qualité de l’original numérisé, une OCR (Optical character recognition) pourra être effectuée sur le contenu pour transformer le contenu de l’image en du texte éditable. Cette « océrisation » n’est pas pertinente pour du texte avec une langue non reconnue par le logiciel ORC, ou avec une écriture manuscrite difficilement déchiffrable par ce même logiciel. Des programmes de reconnaissance par effet d’entrainement existent. Il est alors possible de tester la capacité du logiciel sur une petite partie du corpus sur laquelle un apprentissage des formes rencontrées est effectué. Puis, selon la régularité du graphisme, il est possible d’appliquer cet apprentissage sur l’ensemble du corpus numérisé. Cette méthode est efficace pour de gros volumes, mais une vérification manuelle reste souhaitable, sinon nécessaire. L’OCR simple ou par effet d’entrainement ne remplacera jamais une relecture attentive et donc « humaine ».

Les métadonnées

Pour permettre une exploitation ultérieure, il est nécessaire :

a)   De choisir un format structuré et construit,

b)   D’accoler à ce format structuré un modèle de données ou une documentation sur les différentes catégories créées.

En d’autres termes, une fois que vous avez numérisé et éventuellement « océrisé » vos documents textes, il vous faut en plus décrire le contenu (créer des descriptifs) de vos textes qui permettent de les organiser, de les classer, des les moissonner et de les exploiter : créer des métadonnées. Ces métadonnées sont le plus souvent, comme ce document l’a déjà expliqué, exprimées dans le format XML et suivant un schéma/encodages prédéfinis (Dublin Core par exemple). Un schéma ou encodage définit les champs nécessaires pour décrire vos documents. Différentes initiatives d’encodage existent, dont la principale est aussi celle que nous recommandons pour les textes : la TEI.

La TEI

La TEI (Text encoding initiative) est un modèle XML pour l’édition structurée et l’échange de tout type de texte. La TEI a été lancée en 1987 et elle est supportée par un consortium TEI. Un conseil TEI est chargé de l’amélioration du modèle et des aspects techniques de cette initiative qui en est à sa 5e version (P5).

Elle est plus souple qu’un schéma XML classique car elle propose un ensemble de recommandations (« Guidelines ») et d’éléments particuliers rassemblés dans des modules distincts (« Tag sets ») qui s’adaptent à des besoins particuliers. Elle est largement utilisée en sciences humaines et sociales et sert aussi pour indiquer la structure sémantique d’un contenu.

TEI : http://www.tei-c.org

 

Les données iconographiques - images fixes

Les types de données

Les données iconographiques fixes recouvrent les :

  • photographies (diapositives, négatif, tirages positifs)
  • documents visuels fixes :
    • documents 2D numérisés
    • illustrations
    • plans, croquis, dessins etc.
    • cartes anciennes ou plus récentes, excluant les cartes construites automatiquement à partir de coordonnées et données géographiques

Numérisation et stockage

Les images numériques fixes entrent dans deux catégories principales : les images matricielles (ou « pixelisées ») et les images vectorielles (« orientées objet »). Les images matricielles prennent la forme d’une grille ou matrice, où chaque « élément d’image » (pixel) a un emplacement unique dans la matrice et une valeur de couleur indépendante pouvant être modifiée séparément. Les fichiers vectoriels fournissent un ensemble d’instructions mathématiques utilisées par un programme de dessin pour construire une image. En général, le processus de numérisation génère une image matricielle, les images vectorielles étant plus souvent le produit d’un logiciel de dessin. Par exemple, Photoshop ou Gimp créent et lisent en règle générale des images matricielles, alors que Illustrator crée et lit des images vectorielles. Les images vectorielles peuvent être converties en images matricielles. L’inverse n’est que difficilement possible.

Lors de la création et du stockage d’images matricielles, deux facteurs doivent être pris en considération : le format de fichier et les paramètres de qualité. Les images matricielles devraient en principe être stockées sous une forme non comprimée générée par le processus de numérisation, sans aucun retraitement. Les images matricielles doivent être créées et enregistrées sous l’un des formats suivants : Tagged Image File Format (TIFF), Portable Network Graphics (PNG), Graphical Interchange Format (GIF) ou JPEG Still Picture Interchange File Format (JPEG/SPIFF).

Deux paramètres fondamentaux doivent être pris en compte :

  • La résolution spatiale : la fréquence à laquelle des échantillons de l’original sont capturés par le dispositif de numérisation, exprimée sous la forme d’un nombre d’échantillons par pouce (spi) ou plus communément sous la forme de pixels par pouce (ppp dans l’image numérique qui en résulte). Il s’agit là de la densité d’information (le nombre de points) enregistrée par unité de surface. Plus cette densité est haute et plus l’image numérisée est de bonne qualité. La densité pour les pages web est normalement de 72ppp. L’impression se sert normalement de densités oscillant entre 300 et 600ppp. Il est important de noter que plus l’original est petit, et plus la densité (les ppp) devra être élevée.
  • La résolution des couleurs (profondeur de bits) : le nombre de couleurs (ou de niveaux de luminosité/gris) disponibles pour représenter différentes couleurs (ou tons de gris) dans l’original, exprimé en nombre de bits. Par exemple, une résolution de couleurs de 8 bits signifie que 256 couleurs différentes sont disponibles.

La sélection des paramètres de qualité nécessaires à la numérisation d’une ressource est déterminée par la taille de l’original, la quantité de détails présents dans l’original et les utilisations prévues de l’image numérique. Numériser une diapositive de 35mm exige une résolution plus élevée que dans le cas d’une lithographie de 6x4 car la diapositive est plus petite et plus détaillée. Si l’une des utilisations de l’image d’une aquarelle requiert de pouvoir analyser d’infimes détails de coups de pinceaux, la résolution nécessaire est plus élevée que pour le seul affichage de l’image à l’écran. Plus la qualité de l’image numérisée est haute, et plus le fichier sera lourd, mais plus, également, vous pourrez agrandir l’image sans perdre de la qualité visuelle.

Les images devraient être créées à la résolution adaptée et à la profondeur de bits la plus élevée possible, à un cout acceptable et en demeurant pratiques et maniables au vu des utilisations envisagées. Chaque équipe projet doit identifier le niveau minimal de qualité et de densité d’informations dont elle a besoin. A titre d’exemple, une résolution de 600 points par pouce (ppp) et une profondeur de bits de 24 bits couleur ou de 8 bits à échelle de niveaux de gris devraient être envisagées pour les impressions photographiques. Une résolution de 2400 ppp devrait être appliquée pour des diapositives de 35 mm afin de capturer la plus grande densité d’informations. (Source : EMII DCF)

Dans certains cas, par exemple lors de l’utilisation d’appareils photo numériques de moindre qualité, il peut être indiqué de stocker les images sous un format JPEG/SPIFF, comme alternative au format TIFF. Les images seront alors plus petites et de plus basses qualité. De telles images peuvent être utiles pour la présentation de photographies d’évènements pour un site Internet, par exemple. Mais l’utilisation de tels appareils photos n’est pas recommandée pour la numérisation de contenu à grande échelle.

Les métadonnées

La photographie elle-même n’est pas encore une information exploitable dans le domaine du numérique. Pour ce faire il faut ajouter des métadonnées. Plusieurs méthodes existent qui peuvent être complémentaires. Soit les métadonnées sont incrustées dans le fichier de l’image, soit elles accompagnent le fichier d’image dans un fichier parallèle.

Les métadonnées EXIF

Exif : http://www.exif.org

L'Exchangeable Image File (Exif) est un format crée en octobre 1995 par le Japan Electronic Industry Development Association (JEIDA). La version 2.1 des spécifications date du 12 juin 1998 et la version 2.2 a été publiée en avril 2002.

Le format Exif, bien que n’étant pas établi par une organisation internationale de standardisation, reste un format incontournable puisque la majorité des constructeurs d’appareils photographiques numériques l’utilisent. Il peut être également exprimé selon le standard MIX en XML.

Ce format définit un schéma de métadonnées permettant le stockage des informations techniques concernant les paramètres de prise de vue et les réglages des appareils photographiques numériques lors de la capture numérique.

Ces données sont fournies automatiquement par l'appareil photographique numérique et sont contenues dans le fichier image lui-même. Voici la liste des principaux champs Exif :

  • Tag name : Description
  • MakerNote : Données constructeur
  • File Size : Taille du fichier
  • Mime Type : Type MIME du fichier (ex : image/jpeg)
  • ExposureTime : Temps d'exposition en s
  • FocalLength : Distance focale en mm
  • ExifImageWidth : Dimensions de l'image
  • ExifImageLength
  • X-Resolution : Résolution de l’image
  • Y-Resolution
  • Date and Time (Original) : Date et heure de l'original
  • DateTimeDigitized : Date et heure de numérisation
  • Tags Relating to GPS : Toutes les données relatives aux coordonnées GPS.

Quelques logiciels open source ou gratuits permettant d'afficher, éditer et extraire les métadonnées Exif :

  • Exifer
  • Exif Reader
  • ExifTool
  • ExifPro Image Viewer
  • Exiv2
  • IrfanView
  • Photo Studio
  • XnView

Métadonnées IPTC

L'International Press Telecommunications Council (IPTC) est une organisation internationale créée par les agences de presse en 1965, dont la mission est d'établir un standard normalisé de stockage des métadonnées relatives aux images de presse pour en faciliter l'échange.

IPTC/IIM

Les travaux de l'IPTC ont abouti à la mise en place d'un schéma normalisé des métadonnées des images de presse : l'IPTC/IIM.

XMP

Adobe a créé en 2001, un schéma qui utilise une expression en RDF simplifié de champs totalement paramétrables et donc extensible à des besoins particuliers. Mais ce schéma XMP est propriété d'Adobe.

IPCT-Core 1.1

IPTC : http://www.iptc.org/cms/site/index.html;jsessionid=a6fFGl6cnmYe?channel=CH0089

IPTC Core redéfinit en XMP les métadonnées IPTC/IIM, c'est-à-dire les champs IPTC habituels plus quelques champs nouveaux. IPTC-Core n'est pas une norme ouverte, mais un standard de fait.

(Cf. http://www.iptc.org/cms/site/index.html?channel=CH0089)

Quelques logiciels open source ou gratuits permettant d'afficher, éditer et extraire les métadonnées IPTC, XMP et IPCT-Core :

  • Exifer
  • ExifTool
  • Exiv2
  • IrfanView
  • PhotoThumb IPTCExt
  • Rodeo Info (Mac OSX)
  • XnView

Les recommandations

  • R01) Formats et jeux de données : Il est préférable et conseillé de faire deux jeux de données :
  1. un au format TIFF non compressé pour la conservation,
  2. un au format JPG en qualité maximale pour une exploitation sur le web.

De manière générale, les images photographiques ou documents numérisés doivent être créés au format TIFF.

Vous pouvez numériser l’ensemble de vos images en haute résolution et format TIFF, dupliquer l’ensemble puis utiliser un logiciel comme mogrify pour créer votre second jeu d’images (http://www.imagemagick.org).

  • R02) Taille des données : Une numérisation à 300 dpi est le minimum pour le format TIFF. Pour le jeu destiné au web, au regard des possibilités de stockage actuel et de débit (2009), la taille d'exploitation web peut être équivalente à celle des TIFF. (La résolution de l’image standard pour le web étant de 72 ppp, vous pourrez agrandir votre image en ligne d’un facteur 4 environ sans perdre de qualité).
  • R03) Les métadonnées descriptives des images peuvent être exprimées selon les standards :
  1. EXIF (métadonnées techniques),
  2. IPTC-Core (métadonnées descriptives).

Nous encourageons cependant la structuration des métadonnées selon les vocabulaires DC Element Set (15 champs, voir plus haut) ou du DC:Terms dans des fichiers indépendants aux fichiers images eux-mêmes :

  • dans un fichier XML séparé et nommé selon le nom de fichier de l'image dont seule l’extension (les derniers trois caractères) change : (NomDuFichierDelImage.xml).
  • DC : Terms : http://dublincore.org/documents/dcmi-terms