Archives d’Auteur: manuefig

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 !

Pauvre Gutenberg

Publié le par

Il doit se retourner dans sa tombe à chaque fois qu’on lui fait le coup : Gutenberg est encore une fois l’anti-héros d’un ouvrage sur l’évolution de l’édition à l’heure d’Internet. Une presse sans Gutenberg analyse les conséquences du développement d’Internet sur la presse.

Je recommande tout particulièrement l’article du blog de ZDNet qui explique bien ce qu’on y trouve… et ce qu’on n’y trouve pas.

A compléter par la lecture d’un avis du CES intitulé Garantir le pluralisme et l’indépendance de la presse quotidienne pour préserver son avenir (pdf) (via Juriblog).

PS : Non Gutenberg n’a pas inventé la rotative ;-)

Mise à jour :

PS2 : Ni le codex !

Figues liquides

Publié le par

Voilà, la saison des figues est sur sa fin. Les dernières qu’on trouve voient leur prix tripler (et pourtant elles étaient déjà chères), les confitures de figues pour l’année sont prêtes, et je vais pouvoir de nouveau m’intéresser aux produits dérivés.

Aujourd’hui je vous propose les produits liquides, principalement de trois sortes : le sirop de figues, le vinaigre de figues et l’alcool de figues.

En ce qui concerne le sirop, on en trouve diverses variétés dans le commerce : par exemple là ou encore là. On m’en a offert une petite bouteille, mais je n’ai pas été très convaincue : il n’avait pas vraiment le goût de figues, et il a tourné très rapidement.
La meilleure solution est peut-être encore, si vous avez un figuier, de le faire soi-même : en voici une recette.
Au peut aussi faire des figues au sirop (recette là) mais ça n’a rien à voir et c’est plus proche de la confiture apparemment.

Le vinaigre de figues, c’est Mimi qui me l’a acheté au marché à Castelnou. Il est excellent et donne un bon petit goût à la salade. Hautement recommandé si vous en trouvez.

Enfin, les alcools de figues : je n’ai jamais eu la joie d’en goûter, mais on en trouve aussi en vente sur le Web : voir les caves du Granit Bleu en Bretagne (?!?) ou la Liquoristerie de Provence qui fait le fameux (apparemment) Figoun. Si quelqu’un veut m’en offrir une bouteille, Noël arrivera vite et mon anniversaire est en février ;-)