– IFFF pour les bibliothèques numériques

IIIF (International Image Interoperability Framework) est un protocole d’échange qui rend les documents des archives ouvertes ou des bibliothèques numériques consultables, manipulables et annotables par n’importe quelle application ou logiciel compatible.

En termes informatiques, IFFF est un ensemble de standards à la fois client et serveur qui définissent un cadre d’interopérabilité pour les bibliothèques numériques.  La mise en interopérabilité des entrepôts d’images repose sur un schéma d’échange ainsi que sur des spécifications web par le biais d’API (Application Programming Interface en web services).

Ainsi l’interopérabilité du standard IIIF est structurée par les interactions entre :

  • un modèle de données, “Shared Canvas”, articulé autour de la notion centrale de “Canvas” et du paradigme de l’annotation
  • et quatre APIs spécifiques :
    • deux principales : API “Image” et API “Presentation”
    • deux secondaires : API Recherche “Content Search” et API “Authentification”

 

1.1  L’organisation de l’information à travers les “manifests” et les “canvas”

1.1.1 Le “manifest”

Les  métadonnées sont embarquées dans un fichier appelé « manifest IIIF », qui peut représenter tout type d’objets numériques :

  • il permet de décrire la structure interne de l’objet numérique, du point de vue intellectuel ou matériel : succession de chapitres dans un livre ou d’articles dans un journal, structure codicologique d’un manuscrit etc.
  • Il contient aussi une ou plusieurs séquences de “canvas”, liste ordonnée des pages ou vues d’un objet.

1.1.2 Le “canvas”

 il est fondé sur le principe de l’annotation. Il s’agit d’une feuille vierge servant de réceptacle à toutes sortes de ressources numériques (comme un slide dans PowerPoint) organisées en couches comprenant notamment :

  • l’image numérisée d’une page (voire le cas échéant plusieurs images d’une même page)
  • la transcription du texte de cette page
  • la traduction de la page
  • des commentaires d’utilisateurs
  • des tags et annotations
  • des ressources audio ou vidéo associées

A chaque page/vue d’un livre numérisé correspond un “canvas”.

 

1.2 Les API

1.2.1 L’API “Image”

L’API “Image” permet de manipuler de manière dynamique une image numérique (zoomer, pivoter, redimensionner ou recadrer) par le biais d’un visualiseur.

Cette API :

  • produit une URL contenant des paramètres de région, taille, rotation, qualité, format. modèle : http(s)://{server}{/prefix}/{identifier}/{region}/{size}/{rotation}/{quality}.{format}.
  • est prise en charge par un logiciel appelé “serveur d’images” capable de répondre aux requêtes et de délivrer les images selon les paramètres qui lui sont passés dans l’URL (ex. de logiciels compatibles avec l’API Image : Loris, Cantaloupe, IIPImage…).
  • doit pouvoir s’appuyer sur une base d’images stockées quelque part, cet endroit pouvant varier selon les cas et selon l’infrastructure informatique propre à une institution…
    Les fichiers images peuvent être notamment :

    • stockés sur la même machine que le serveur d’images (le logiciel), dans le système de fichiers (simple hiérarchie de dossiers contenant les images)
    • stockés sur une autre machine (par ex. un NAS), “montée” en NFS sur la machine hébergeant le serveur d’images
    • stockés sur une autre machine, accessible uniquement en HTTP
    • gérés et référencés dans une base de données dédiée (par ex. logiciel de type DAM, ou base de données relationnelles…)

→ ces éléments d’infrastructure technique peuvent avoir un impact direct sur le choix du serveur d’images à installer : tous ne présentent pas nativement les mêmes capacités en terme de communication avec une “source de stockage” (c-a-d comment le serveur d’images va pouvoir récupérer les images depuis une source donnée, qu’elle soit locale ou distante)

→ il faut aussi se poser la question des formats d’images sources, car là aussi les logiciels de serveurs d’images n’ont pas les mêmes capacités (par ex. certains ne prennent en charge en entrée que des formats d’image dits “tuilés”, comme JPEG2000 ou TIFF Pyramidal)

1.2.2 L’API Présentation

L’API “Présentation” délivre de manière standardisée des informations de présentation et de structure d’un objet numérique. Elle permet d’exposer sur le web les métadonnées nécessaires au rendu de cet objet dans une interface .

L’API “présentation” génère :

  • des “manifests” individuels pour chaque document
  • comprenant au moins une “séquence”, qui est une suite ordonnée de “canvas”
  • chaque “canvas” représente une page d’un document
  • à chaque “canvas” est associé au moins une image numérique (en principe)
  • ces “canvas” peuvent être regroupés dans des “ranges”, qui permettent de représenter différents types de structures au sein de l’objet (table des matières, index des enluminures, structure codicologique etc.)

Ces métadonnées IIIF sont à distinguer des métadonnées documentaires :

  • elles ne sont pas orientées vers la recherche de documents au sein d’un corpus;
  • elles décrivent le rendu d’un objet numérisé dans l’optique d’enrichir l’expérience utilisateur;
  • elles sont produites au format JSON-LD (format JSON compatible avec RDF)
  • elles permettent la création d’une séquence d’images selon un ensemble ordonné
  • elles contiennent des données additionnelles (annotations associées à des pages ou à chaque image)

C’est le format des manifests (ce qui représente l’objet numérisé dans son ensemble) et donne le contexte (fichier JSON-LD). Ce fichier JSON va encapsuler :

  • métadonnées descriptives (ex : DC de la BSG : titre, auteur, date etc.)
  • séquence d’images (ordre des images)
  • données de structure (“ranges”), le cas échéant
  • données additionnelles à propos de l’objet ou d’une page à l’intérieur d’un document (liens vers métadonnées plus riches, données sous forme d’annotation associée au niveau de chaque image ex : info sur le décor, transcription etc.)

Des “collections”, conteneurs de “manifests” peuvent être imbriqués en sous-collection. Un document peut être dans plusieurs “collections”.

Exemple :

  • Collection : Manuscrits de la bibliothèque
  • sous-collection : Manuscrits enluminés
  • Manifest : un manuscrit en particulier
  • Sequence : tous les folios de ce manuscrit (à chaque folio un “Canvas”)
  • Canvas : un feuillet particulier de ce manuscrit avec données sur les enluminures pouvant être éventuellement associées.
  • Range : une zone dans le feuillet du manuscrit (correspondant à l’oeuvre Y, par ex.) 

1.2.3 L’API “Authentification”

Elle donne des droits d’accès à l’image sur le modèle de Gallica intramuros, qui restreint l’accès à certains documents numérisés à la consultation sur place.

Pour prendre l’exemple de Gallica vs Gallica intra-muros, L’API “Authentification” permettrait de supporter un scénario dans lequel il pourrait y avoir une seule version de Gallica (tous les documents sont trouvables ensemble) mais où la consultation des documents sous droits serait soumise à des restrictions d’accès (l’accès aux images serait dans ce cas bloqué pour tous les internautes hors des murs de la BnF). L’API Authentification est la couche intermédiaire entre le visualiseur de Gallica et le système d’authentification/autorisation, qui permettrait de dire au visualiseur “ce document est sous droit” (et d’afficher un message à l’utilisateur).

1.2.4 L’API “Content Search”

Elle permet de rechercher des occurrences de texte au sein des “manifests”. C’est la mise à disposition d’un web service pour interroger le document et ses annotations (équivalent d’un ctrl + F). Cette API est interopérable car elle peut être actionnée dans tout visualiseur.

Si le texte issu de l’OCR a été associé au “manifest”, l’API “Content Search” permet une recherche en texte intégral dans le document à partir d’un champ de recherche intégré au visualiseur.

Pour aller plus loin :