Archives Mensuelles: novembre 2005

Qu’est-ce que le modèle OAIS ?

Publié le par

L’OAIS est un modèle conceptuel pour l’archivage de documents (numériques en particulier). Cela signifie qu’il constitue une référence décrivant dans les grandes lignes les fonctions, les responsabilités et l’organisation d’un système qui voudrait préserver de l’information, en particulier des données numériques, sur le long terme. Le long terme est défini comme suffisamment long pour être soumis à l’impact des évolutions technologiques, c’est à dire, pour ce qui concerne le document numérique, très court en fait.
L’OAIS a été défini au départ dans le domaine aérospatial, par le CCSDS qui est l’organisme de normalisation de ce domaine. Aujourd’hui il est très largement adopté au-delà de cette communauté et il a été reçu comme norme par l’ISO sous le numéro 14721.

Que fait / ne fait pas l’OAIS ?

Ce que fait l’OAIS :

  • il donne une terminologie fiable et unique pour manipuler tous les concepts liés à la préservation des données numériques
  • il fait le tour de toutes les questions à se poser au moment de mettre en place un système de préservation
  • il décrit les composantes d’un tel système au niveau de l’organisation interne et externe

Ce qu’il ne fait pas :

  • il ne donne pas de formats, schémas, règles ou techniques pour préserver les documents numériques
  • il ne décrit pas les applications informatiques et techniques à mettre en œuvre, ni logicielles, ni matérielles
  • il ne donne pas de méthodologie concrète de réalisation d’un tel système (cahier des charges, workbook ou autre).

Les grands principes du modèle peuvent être décrits par un schéma simple (mais également par un schéma compliqué si on veut ;-) cf. ci-dessus (cliquer sur l’image pour agrandir). En gros, le modèle est conçu comme une boîte dans laquelle on manipule des paquets. Cette boîte a un ou plusieurs rôles ou missions, et elle interagit avec les producteurs des données en amont, les administrateurs du système, et la communauté d’utilisateurs en aval.

Les paquets

Le modèle OAIS repose sur l’idée que l’information constitue des paquets, et que ces paquets ne sont pas les mêmes suivant qu’on est en train de produire l’information, d’essayer de la conserver, ou de la communiquer à un utilisateur. On a donc trois sortes de paquets :

  • les paquets de versement (SIP) préparés par les producteurs à destination de l’archive
  • les paquets d’archivage (AIP) transformés par l’archive à partir du SIP dans une forme plus facile à conserver dans le temps
  • les paquets de diffusion (DIP) transformés par l’archive à partir de l’AIP dans une forme plus facile à communiquer notamment sur le réseau.

Dans chaque paquet, à chaque stade, on va trouver des fichiers informatiques qui correspondent à l’objet ou au document qu’on veut conserver, et des informations sur ce document c’est à dire des métadonnées. Je ne vais pas rentrer dans le détail, mais la façon de constituer les paquets, y compris et surtout le genre de métadonnées dont on a besoin pour que ça ait une chance de fonctionner, sont très bien décrits dans le modèle.

Les missions d’une archive OAIS

Le but de la mise en place d’une archive OAIS est d’avoir une instance, cette archive, qui va endosser la responsabilité de la préservation à long terme des documents qu’on lui confie en vue de les communiquer à une communauté définie d’utilisateurs. Il y a plusieurs idées importantes ici :

  • la préservation se fait en vue de la communication
  • l’archive cible une communauté d’utilisateurs et s’efforce de répondre aux besoins de cette communauté.

Si on prend l’exemple d’une bibliothèque, la communauté n’est pas la même pour une BU que pour une bibliothèque publique, vous savez cela aussi bien que moi. Donc les services ne seront pas les mêmes non plus.
L’idée de responsabilité est très forte dans le modèle ; à tout moment l’archive doit savoir prouver qu’elle a bien fait son travail – surtout si elle échoue, j’imagine.
Cette responsabilité inclut les relations avec les producteurs : il s’agit de négocier des accords concernant les versements, en particulier les clauses techniques (l’archive et le producteur définissent ensemble à quoi doit ressembler le SIP). Cela inclut aussi le fait d’obtenir de la part du producteur tous les droits nécessaires à la manipulation des documents, en particulier les droits de propriété intellectuelle.
L’archive garantit aussi qu’elle fournira à sa communauté d’utilisateurs des documents compréhensibles, disponibles, et qu’elle mettra en œuvre tout ce qui est en son pouvoir pour préserver les documents dans le temps : c’est une sorte de contrat entre l’archive et sa communauté d’utilisateurs.

L’organisation

Le modèle OAIS va ensuite définir l’organisation de l’archive, c’est à dire comment elle doit s’y prendre pour gérer ses paquets sans rien oublier. Pour cela, on définit des entités organisationnelles et la façon dont elles s’articulent entre elles. Pour prendre un exemple, il y a une entité « entrées » dont le rôle est de recevoir les paquets SIP et de les transformer en paquets AIP ; cette entité est en relation avec l’entité « stockage » à qui elle confie les AIP. Elle a aussi d’autres rôles comme envoyer un accusé de réception au producteur pour certifier qu’elle a bien pris en charge son paquet, ce qui transfère la responsabilité du paquet du producteur vers l’archive.
Je ne vais pas détailler mais tout est un peu sur ce modèle. Les différentes entités sont :

  • les entrées
  • le stockage
  • la gestion des données (en fait, des métadonnées)
  • l’administration qui pilote le tout
  • la planification de la préservation qui prend en charge les actions de veille technologique pour décider des opérations à mettre en œuvre
  • et enfin, l’accès.

Chacune de ces entités a ses rôles, ses fonctions, et doit communiquer avec les autres sous la forme de flux de données. En réalité, tout cela est conceptuel, cela veut dire que dans la mise en œuvre réelle, on n’est pas obligé d’avoir des gens ou des services qui travaillent spécifiquement sur une et une seule de ces entités. Mais toutes les fonctions et les interactions doivent exister.

Migrations, émulations

Ensuite, le modèle OAIS aborde les différentes méthodes qui peuvent être utilisées plus concrètement pour pérenniser l’information. Il y en principalement deux sortes : la migration et l’émulation.
La migration consiste à prendre un AIP et à le transformer en autre chose. Il y a plusieurs sortes de migrations possibles en fonction du type de problème rencontré : par exemple, si on a un support qui se dégrade mais que le document enregistré dessus ne pose pas de problème, on procède à un simple renouvellement (rafraîchissement de support) ou on passe à un support plus récent (duplication). C’est le type de migration qui a le moins d’impact sur l’accès à l’AIP. Par contre, si c’est le format du document ou les logiciels associés qui posent problème, on aura des migrations plus musclées qui modifient la structure même de l’AIP et rendent nécessaire la gestion de versions d’AIP.
Dans l’émulation, on ne touche pas à l’AIP mais on s’efforce de conserver ou reproduire les conditions d’accès au document, de la manière la plus proche possible de ce qu’étaient les conditions de consultation à l’origine. C’est le mode qu’on utilise de préférence pour les documents dans des formats propriétaires et les documents qui ont des comportements très spécifiques, comme les jeux vidéos par exemple.

Et après ?

Maintenant qu’on sait tout cela, et qu’on a acquis la vision d’ensemble des problématiques de conservation des données numériques, ainsi qu’un début de solution pour mettre en œuvre un système d’archivage, yapuka… définir quel sera le stockage, quels seront les formats acceptés dans les paquets, les formats de métadonnées utilisés, les relations avec les producteurs, les services d’accès et de recherche, définir et acquérir ou développer des logiciels qui remplissent toutes ces fonctions, et surveiller de très près son archive, une fois qu’elle est bien remplie, pour s’assurer que les migrations et les émulations sont effectuées à temps. Car dans le domaine numérique, toute conservation est nécessairement préventive : quand on s’aperçoit qu’un document a été altéré, il est généralement trop tard pour faire quoi que ce soit.
Le modèle OAIS ne donne pas de clefs pour mettre tout ceci en œuvre et c’est sans doute la principale difficulté : comment passer de l’abstraction à l’application. En attendant qu’on nous propose des logiciels de type « MyOAIS » clef en main, il est probable qu’on devra s’en remettre, le plus souvent, à des archives centralisées ou à des tiers archiveurs privés. Ces derniers, pour prouver que le modèle OAIS n’est pas pour eux qu’une belle parole, devront sans doute obtenir un niveau de certification officiel et international. C’est pour demain.

Source : le modèle OAIS en français.

PS : Les documents protégés par des DRM ne pourront être, ni migrés, ni émulés. La loi interdisant (prochainement) de créer des logiciels qui retirent ces protections techniques, ainsi que des logiciels qui les ignorent ou les contournent, aucune solution ne pourra être apportée à leur conservation au-delà de la durée de vie de leur support ou de leur environnement matériel et logiciel. Si leurs producteurs ne font pas l’effort de confier à une archive OAIS une version débloquée et documentée (un SIP, quoi), ils seront perdus à jamais. Dommage, quand même.

Numérisation en Europe : cadrage

Publié le par

Un peu de lecture rapidement : deux documents de cadrage des initiatives de numérisation en Europe viennent d’être publiés.

Le premier nous vient du JISC et il porte sur la coordination d’une initiative nationale au Royaume-Uni : 2005 Digitization Report, pdf, 38p.

Le second nous vient du projet Minerva, donc au niveau de l’Europe. Il fait la liste des actions à entreprendre et en particulier celles qui peuvent être menées immédiatement : Plan d’action dynamique pour la coordination dans l’U.E. de la numérisation du contenu culturel et scientifique.

Des murs de verre

Publié le par

Demain, l’information sera présente, reliée sur le réseau ; il sera de plus en plus facile de trouver des ressources. Mais ces ressources contrôlées, surveillées, protégées, pourra-t-on y accéder ? Ou sera-t-on condamnés à regarder, à travers des « murs de verre », ces ouvrages dont on ne pourra que connaître l’existence, et qui seront plus difficiles à communiquer à distance que les ouvrages papier eux-mêmes.

Lire par Charles W. Bailey, "Libraries with glass walls", dans The Public-Access Computer Systems Review, 1990, 1(2).

Oui, c’était il y a 15 ans.

Aujourd’hui les DRM, demain plus rien

Publié le par

A l’occasion de la transposition de la Directive européenne sur les droits d’auteur dans la société de l’information en droit français, on voit ressurgir quelques articles intéressants sur l’un des points les plus problématiques de cette future Loi dite DADVSI, : la protection juridique des mesures de protection techniques, ou DRM.

Par exemple cet article dans Le Monde qui donne des frissons quand on voit jusqu’où ça peut aller :

Il est en effet encore possible de réenregistrer et d’encoder au format numérique la musique qui sort des haut-parleurs d’un ordinateur personnel. Mais  » aux Etats-Unis, précise M. Espern, on teste déjà des systèmes rendant impossible la conversion de flux analogiques en fichiers numériques ».

Tristan Nitot sur son Standblog nous propose aussi une série de 5 billets pédagogiques sur le sujet :

Pour une vision tout à fait polémique mais très intéressante des DRM et de leurs dangers, on peut visiter ce site. Et on retrouvera avec fruits cette pesante synthèse de Thierry Stoehr sur Formats Ouverts.

Question pour tout le monde : quelle maîtrise aurons-nous encore demain sur nos propres ordinateurs ? Et question pour les bibliothécaires : quel espoir de communiquer et pire encore, de conserver au-delà de quelques courtes années les documents protégés par des DRM, s’il est illégal de seulement penser une seule seconde à envisager de réfléchir à un moyen de pouvoir les contourner ?

Archivegrid

Publié le par

Voici un étrange truc que nous annonce RLG, avec un peu de fanfare, pour 2006 : Archivegrid.

Il s’agit de mettre en ligne des ressources archivistiques internationales concernant les personnes, les groupes, les lieux et leur histoire en général, conçu un peu sur le modèle de RedLightGreen.

Comme son nom (et son logo) l’indique, Archivegrid sera quelque chose de plus qu’un portail ou un site fédéré ; un véritable "grid" avec beaucoup de partenaires et une impressionnante interface à facettes (??) dont on se demande ce qu’elle cache comme indexation sujet.

Bref un espèce de méta-inventaire d’archives, apparemment basé sur l’EAD mais pas seulement, qui imite (en mieux ?) les méta-catalogues de bibliothèques. Une future réjouissance pour les historiens. Pour la France on y trouve nos amis de la DAF.

Envie de participer ?

Merci à ResourceShelf.

Construire un « institutional repository »

Publié le par

Le MIT nous propose un tutoriel très complet pour mettre en place un institutional repository, qu’on pourrait traduire imparfaitement par "entrepôt numérique" : LEADIRS (PDF, 134 pages). On y trouve notamment toute sorte de renseignements utiles sur le plan organisationnel, légal, et budgétaire. Il y a aussi un comparatif des solutions logicielles existantes : Dspace, Fedora, Eprints, Greenstone, etc. Une lecture indispensable pour tout bibliothécaire qui se pépare à mettre en place un système de gestion de documents numériques.

Le livre, c’est sacré

Publié le par

L’imaginaire du livre, très puissant dans notre société, en fait un objet sacralisé ce qui peut expliquer certaines réticences à passer à autre chose. (Je répète que ce pauvre Gutenberg n’a pratiquement rien à voir là-dedans).

Qu’est-ce qui explique notre attachement viscéral au codex, qu’on pourrait aussi appeler le tourne-page ? Je ne résiste pas à l’envie de vous proposer sur le sujet une petite citation à la manière de Got :

L’essor du livre-cahier de notes et son passage au livre proprement dit, nous le devons d’abord aux chrétiens et d’une manière générale aux mouvements de religion personnelle du début de notre ère (…) De plus, pour les chrétiens, l’usage du codex leur permettait de se distinguer des Juifs dont les textes sacrés étaient présentés sous forme de rouleau. Ils le sont encore : la Torah, la loi juive, est restée un volumen, unique survivance, dans notre monde, du type de livre usuel dans l’antiquité.

C’était dans Les collections de l’Histoire, oct-dec. 2005 : "Du papyrus au papier, l’invention du livre" entretien avec Jean Irigoin de l’Institut de France.

J’espère que Zid dans son nouveau chez lui Médiévizmes aura quelque chose à dire là-dessus ;-)

Le « paradigme » de Google print ne date pas d’hier

Publié le par

Aujourd’hui, les processus itératifs de production et d’assimilation de l’information sur le Web conduisent souvent à biaiser notre perception temporelle des événements : seules les informations les plus récentes surnagent, les plus anciennes sont noyées et oubliées, ce qui fait qu’on peut facilement (et on le fait) dire tout le temps la même chose sans que ça se voie trop. C’est le principe des blogs, le mien par exemple : ça fait plus d’un an que je répète tout le temps la même chose et il y a toujours des gens pour me lire ;-)

Pour se détendre un peu, je vous propose une petite analyse de textes comparée.

En 1998 : Quelle définition pour les métadonnées. De façon simpliste, on pourrait dire c’est un nouvelle redéfinition du catalogage.
En 2005 : We’ve been managing book metadata basically the same way since Callimachus cataloged the 400,000 scrolls in the Alexandrian Library at the turn of the third century BC.

En 1998 : Ces données qui servent à identifier les documents et à rechercher des informations peuvent être soit créées en tant que telles a priori en accompagnement de la ressource électronique ou elles peuvent être retrouvées et combinées a posteriori par des systèmes de recherche.
En 2005 : Publishers, libraries, even readers can potentially create as many classification schemes as we want.

En 1998 : Une des composantes très importante de métadonnées est l’identifiant unique et permanent de chaque ressource. Ces identifiants qui s’appuient lorsque cela est possible sur les identifiants classiques passifs (ISSN, ISBN) doivent permettre un accès à plus long terme sur le réseau que les seuls URL actuels.
En 2005 : First, we’ll need what are known as unique identifiers-such as the call letters stamped on the spines of library books. (…) the ISBN is a good starting point

En 1998 : A partir d’informations préparées et proposées dans un format universel et révisable on peut toujours rajouter ses propres données dans le même format. C’est l’objectif de l’initiative TEI de faire un format qui soit un format d’édition, de proposition de mise en forme logique de l’information que les chercheurs peuvent utiliser eux-mêmes pour éventuellement ajouter leur propre code pour une exploitation par leur propre logiciel pour du traitement linguistique.
En 2005 : Using metadata to assemble ideas and content from multiple sources, online readers become not passive recipients of bound ideas but active librarians, reviewers, anthologists, editors, commentators, even (re)publishers.

Amusant non ? Evidemment en coupant les citations comme ça on peut faire dire aux textes ce qu’on veut. Mais l’exercice d’une façon générale se vérifie le plus souvent : le soi-disant nouveau paradigme révélé par Google print ne date pas d’hier. Il était au biberon en même temps que Google lui-même…

Visualiser des documents numériques

Publié le par

Ces derniers temps, on m’a demandé à plusieurs reprises de réfléchir à des maquettes de visualisation de documents numériques et j’ai aussi eu l’occasion de donner mon avis sur celle (entre autres) de l’OCA, Open library. Alors je crois qu’il faut que je m’explique sur ce concept d‘exemple inquiétant d’un phénomène de résistance des mentalités à la technologie qui n’est sans doute que transitoire – même si Got fait ça déjà si bien dans son Du livre électronique au wiki, que tout le monde a déjà cité mais qu’importe, un peu de pub, ça fait pas de mal.

Donc première chose, un visualiseur se conçoit de manière générique. A moins que la politique documentaire de votre projet de numérisation soit de sélectionner uniquement les in-8° imprimés en Times corps 12, il faut prévoir que vous allez devoir potentiellement donner accès à des trucs aussi affreusement divers que de des journaux (en colonnes et en très petits caractères sur des très grandes feuilles), des manuscrits et des livres anciens (en couleur pour que ce soit joli, et en détail pour que ce soit utilisable), des dictionnaires (écrits tout petit sur du papier tout fin), toutes sortes de feuillets dépliants de tableaux et autres trucs de taille non conventionnelle cachés entre deux pages, et pourquoi pas des photos, des estampes, des objets en 3D et même, horreur suprême, des plans qu’on ne peut pas lire si on ne peut pas les retourner à 180°.
Donc un bon visualiseur doit être capable de zoomer, de retourner l’image, de s’adapter à la taille du document pour la lecture à l’écran et pour l’impression : c’est un minimum, on peut faire toutes ces choses avec un livre.
Vous pouvez toujours contourner le problème en proposant une interface de consultation dédiée pour chaque type de document. C’est le modèle anglosaxon, à découvrir aux USA, en Angleterre ou encore en Ecosse.

Deuxièmement, un visualiseur doit être capable de gérer ce qu’on peut appeler le paratexte, et les métadonnées. Ce paratexte, c’est notamment la pagination de l’ouvrage, sa table des matières, sa notice… C’est plutôt pas mal dans la Bibliothèque virtuelle des humanistes.
Cela impose aussi d’être capable de gérer différentes versions d’un même document et là, ça se complique. Si le document est indexé en plein texte, cela veut dire qu’on en a une version textuelle. De plus en plus, on propose une version textuelle imparfaite, obtenue automatiquement par OCR, et "cachée" virtuellement derrière l’image, ce qui signifie qu’on enregistre toutes les coordonnées des mots sur la page pour être capable de savoir précisément sur quelle page et à quel endroit de la page se trouve un mot. C’est ce qui permet de souligner joliment (enfin chacun ses goûts) en jaune l’occurence trouvée, ou de placer un petit post-it entre les pages virtuelles de notre livre numérique.
Dans ce cas-là, on peut faire de la recherche plein-texte, mais on ne bénéficie pas de toutes les choses merveilleuses qu’on pourrait faire si on avait accès à cette version textuelle : la copier pour pouvoir la transcrire plus rapidement, jeter un oeil pour évaluer la pertinence de l’OCR et donc le risque de "silence" sur sa requête… On voit ça correctement mis en oeuvre dans Persée.
Si on a une version textuelle corrigée du texte en plus de l’image, une véritable numérisation en mode texte, ça se complique encore plus. Il faut imaginer les outils qui permettent de passer en souplesse d’une version à l’autre, suivant les besoins. Pour voir ce que ça donne quand c’est bien fait, rendez-vous sur les Cartulaires numérisés d’Ile de France.
Je ne parlerai même pas de la question de la visualisation d’une numérisation uniquement en mode texte, il y aurait trop à dire.

Enfin, en vrac (ou en confiture ;-) parmi les choses auxquelles il faut penser :

  • une référence simple et efficace, c’est à dire de belles URL propres, si possible sur chaque page du document numérisé
  • la gestion des documents multiples, les périodiques par exemple ; réfléchir comment on va passer d’un numéro au suivant
  • les possibilités d’impression et de téléchargement d’une page, de plusieurs pages
  • les outils d’aperçus ou de feuilletage, comme les vignettes ou les mosaïques
  • les documents complexes, qui mélangent de l’image et du son, ou du son et du texte, ou autre chose
  • l’accessibilité pour les personnes handicapées
  • etc.

Je ne parlerai pas non plus du problème de l’accès aux documents qui est en amont de la visualisation proprement dite, mais il y aurait beaucoup à dire.

Pour finir sur cette question essentielle de savoir ce qui me chiffonne dans les interfaces qui "imitent" le livre, comme Open library, c’est que d’emblée elles rejettent la spécificité du média numérique.
Le tourne-page, la visualisation en double page, les petits post-its et autres gadgets sont en fait très rassurant pour des gens qui sont peu familiarisés avec Internet, ce qui est le cas de la plupart des décideurs qui tiennent les cordons de la bourse. Mais en proposant une telle interface, on se prive des possibilités ouvertes par le nouveau média pour manipuler le document. On se prive également des possibilités ouvertes par l’ancien média, puisqu’en essayant de copier ce qui était performant sur le papier, on perd de la qualité et de la lisibilité sur l’écran.
Il ne nous reste plus qu’à télécharger l’ouvrage entier en PDF ce qui, à mes yeux, est certes une fonctionnalité indispensable mais aussi un constat d’échec sur l’appropriation du numérique.

Je ne suis pas résolument opposée à l’interface que propose Open library. Je trouve juste qu’elle met de manière excessive l’accent sur des fonctionnalités qui ne sont finalement que "jolies", aux dépends de ce qu’elle pourrait proposer d’efficace, de pertinent et de pratique. Mais je suis consciente que c’est peut-être moi qui ai tort.

Je vous recommande tout de même la lecture de deux articles sympathiques en relation plus ou moins avec ce sujet :

Web services et bibliothèques

Publié le par

Les Web services sont des technologies basées sur les standards du Web qui permettent à des applications de dialoguer entre elles. Il fournissent un cadre pour trouver, décrire et exécuter ces applications.

Les caractéristiques des Web services.

Web based : les Web services sont basés sur les protocoles et les langages du Web, en particulier HTTP et XML (tout comme le Web lui-même s’appuie sur les protocoles d’Internet en particulier TCP/IP : c’est une « couche » supplémentaire).

Self-described, self-contained : le cadre des Web services contient en lui-même toutes les informations nécessaires à l’utilisation des applications, sous la forme de trois fonctions : trouver, décrire et exécuter. Il est donc nécessaire pour faire fonctionner un cadre de Web services de disposer d’un annuaire des applications disponibles, d’une description du fonctionnement de l’application, et d’avoir accès à l’application elle-même.

Modular : les Web services fonctionnent de manière modulaire et non pas intégrée. Cela signifie qu’au lieu d’intégrer dans une seule application globale toutes les fonctionnalités, on crée (ou on récupère) plusieurs applications spécifiques qu’on fait intéropérer entre elles, et qui remplissent chacune une de ces fonctionnalités.

Les perspectives

La longévité et la fiabilité d’un système qui vise à fonctionner de manière distribuée se mesurent à l’ampleur de l’implémentation qui est faite du système par l’industrie.

Nous en sommes actuellement à ce stade pour les Web services. Il existe des formats et des protocoles dont le succès montre qu’ils tendent à se détacher et à devenir des standards de fait pour les Web services : il s’agit du triplet SOAP-WSDL-UDDI. Ces trois technologies constituent l’architecture étendue des Web services, actuellement en discussion pour être adoptée comme standard par le W3C.

Il s’agit bien d’une architecture étendue pour les Web services, pas de la seule architecture possible. C’est certainement le cadre le plus large, le plus stable mais aussi le plus complexe pour faire fonctionner des Web services.
On oppose en général cette architecture basée sur SOAP à celle qui utilise REST . REST consiste à utiliser le protocole HTTP simple plutôt que d’avoir recours à une enveloppe SOAP (on verra ce concept d’enveloppe plus loin). Les défenseurs de REST mettent en avant la simplicité d’utilisation et le fait de ne s’appuyer que sur l’existant, ce qui est selon eux un gage d’intéropérabilité. Les défenseurs de SOAP au contraire pensent que c’est la stabilité et la fiabilité d’un système riche et adaptable à toutes situations qui, malgré la complexité qui en résulte, sont les mieux à même de défendre cette intéropérabilité.

L’architecture étendue des Web services

On désignera donc par « architecture étendue » le cadre de Web services qui repose sur SOAP, WSDL et UDDI. Tous trois sont des technologies basées sur XML, ce qui permet en théorie aux applications de Web services de les utiliser de manière autonome (sans intervention humaine) d’un bout à l’autre des opérations.
Cette architecture fonctionne comme une lettre à la poste (vraiment !):

  • on dispose d’un annuaire des Web services réalisé grâce à la technologie UDDI. Cet annuaire contient plusieurs types d’informations. Les pages blanches regroupent les informations de contact et d’adresse du service. Les pages jaunes proposent un classement thématique standardisé des différents types de services disponibles. Enfin, des pages techniques décrivent plus en détail le fonctionnement des applications et indiquent comment appeler le fichier WSDL.
  • Les fonctionnalités de chaque application et le langage qu’elle comprend sont décrites par un fichier WSDL . WSDL permet donc de savoir pourquoi et comment on peut dialoguer avec l’application cible : quelles informations ou quels services rechercher, quel langage et quelles commandes utiliser, etc.
  • SOAP est une enveloppe : on l’utilise pour y mettre le message que l’on souhaite faire parvenir à l’application cible. L’application utilise à son tour une enveloppe SOAP pour renvoyer la réponse. On peut mettre ce que l’on veut dans cette enveloppe, pourvu que ce soit du XML et que ce soit conforme à ce qui est décrit dans le fichier WSDL associé.

Exemple d’application

Une entreprise par exemple Google ou Amazon, décide de créer un Web service. Elle publie son API , c’est-à-dire un fichier WSDL, une application qui permet de l’exploiter, et la documentation qui l’accompagne (des exemples, des tutoriels, etc.). Il peut aussi d’accompagner d’une licence qui définit les conditions d’utilisation (nombre de requêtes autorisées par jour, demande de compte utilisateur…). Un développeur créée ensuite une application capable de dialoguer avec cette API. La nouvelle application intègre les fonctionnalités de l’ancienne.

Cela permet ensuite de créer des outils capables d’interagir avec différents Web services et de proposer des fonctionnalités intégrées. Par exemple Amazon light 4.0 : cette interface utilise l’API d’Amazon pour rechercher un document dans la base d’Amazon.
Elle combine ensuite différentes API (pas forcément en SOAP dans ce cas précis) pour proposer une batterie de services une fois qu’on a trouvé un document intéressant :

  • Elle utilise l’API d’Amazon pour trouver le document puis pour fournir les mêmes services qu’Amazon (acheter en ligne, ajouter à sa « wishlist »)
  • elle utilise l’API de Gmail pour envoyer un mail, en récupérant le titre du document dans le titre du message et le lien dans le corps du message ;
  • elle utilise l’API de Blogger pour créer directement une entrée de blog comportant le titre de l’ouvrage et le lien (je suppose n’ayant pas de compte blogger)
  • elle utilise l’API de del.icio.us pour permettre de partager le lien dans ce logiciel en ligne de « social bookmarking »
  • elle utilise l’API de Google et en particulier l’indexation de Worldcat par celui-ci pour la fonction « library lookup », qui permet de retrouver directement l’item dans le catalogue de sa bibliothèque (à condition d’habiter en Australie, aux USA et dans quelques autres pays).
  • elle recherche des liens en relation avec le document, notamment le résumé dans Google print et les « related links » dans Google et Yahoo.
  • etc…

Cet outil illustre parfaitement, dans une logique poussée à l’extrême, les possibilités ouvertes par les Web services dans un domaine orienté objet/document.

Applications en bibliothèque

Un travail a été mené depuis quelques années pour faire évoluer la norme Z3950 vers les technologies Web en utilisant les Web services. Deux cadres d’application ont été développés :

  • SRW qui utilise SOAP comme format d’envoi des requêtes et de réponse,
  • SRU qui se base sur REST. On utilise alors une série de verbes pour effectuer des commandes, exactement comme pour l’OAI.

La Library of Congress a expérimenté l’utilisation de SRW et SRU pour améliorer son interface Z3950. Pour cela elle a travaillé avec la société IndexData et son logiciel TAZ.

Notons que Index Data fait partie de VIEWS , un groupement de vendeurs de SIGB et d’organisations liées aux bibliothèques (Dynix, Fretwell-Downing, Index Data, Muse Global, OCLC et VTLS) dont l’objectif est de favoriser la collaboration entre partenaires économiques des bibliothèques pour améliorer l’interopérabilité des interfaces grâce aux Web services. Ce groupe est également soutenu par l’oragnisme de normalisation américain NISO.

Les bibliothèques utilisent déjà un certain nombre d’outils qui fonctionnent sur un mode assimilable à REST (requêtes HTTP GET et POST et envoi de documents en XML) comme l’OAI-PMH. Aux yeux de certains, ces outils peuvent être assimilés à des Web services (même s’ils ne font pas partie de l’architecture étendue des Web services).
Je ne reviens pas ici sur les applications possibles de l’OAI en bibliothèque.

En fait, les Web services devraient intéresser les bibliothèques de plusieurs points de vue :

  • l’intégration des applications (en interne et en partenariat),
  • l’accès au document
  • les services au public.

Du point de vue de l’intégration des applications, les Web services représentent une solution d’interopérabilité simple et fiable, en train de devenir un standard de fait. On devrait songer à des solutions comme SRW (qui s’appuie sur SOAP) pour remplacer Z3950 dans l’interrogation distribuée des bases. Si on a plusieurs bases différentes pour différents types de documents, les Web services peuvent être une solution pour mettre en place une interrogation commune sur bases distribuées, transparente pour l’utilisateur, sans modifier ni intégrer les applications.

Du point de vue de l’accès au document, outre la possibilité d’intégrer des métadonnées comme on le fait avec le protocole OAI et avec SRU/SRW, on peut aussi intégrer les applications elles-mêmes. On peut ainsi partager des données grâce à des échanges en temps réel, mais également exploiter directement ce qui relève des applications développées : moteur de recherche, interface de consultation, et pourquoi pas les contenus eux-mêmes et des ontologies pour les décrire (voir sur ce dernier point, par exemple, l’API de SKOS).

Du point de vue de l’usager, les Web services ouvrent la porte à l’intégration de la bibliothèque dans un certain nombre de fonctions en ligne, surtout des fonctions sociales dont l’importance est croissante. Ils permettraient de donner à l’usager des outils simples pour intégrer la bibliothèque aux outils qu’il utilise couramment sur le Web : suivre les nouveautés avec RSS, relier directement les données du catalogue à celles de Google ou d’Amazon… Aller dans le sens d’une intégration des contenus aux dépends des formats, en suivant la tendance actuelle.

Ma principale source est l’ouvrage The Semantic Web : A Guide to the Future of XML, Web Services, and Knowledge Management. Une recherche dans votre moteur préféré vous donnera de nombreux liens vers des articles plus techniques, notamment (il faut bien le reconnaître) ici. Merci à T. et F. pour leurs encouragements qui sont à l’origine du plus long billet de l’histoire de ce blog !