La communauté française des digital humanities

THATCamp Paris 2010, sur la Baleine blanche - Crédits : Elodie Picard / CC

Après deux jours d’ateliers, démos, débats, discussions le THATCamp Paris 2010, la non-conférence sur les digital humanities, lance le Manifeste des digital humanities. Ce texte, fondateur de la communauté des digital humanities en France est très important. Il a permis tout d’abord de répondre à la question posée dans le THATCamp : « voulons-nous travailler ensemble ? ». La réponse est largement positive à mon sens.

Ce besoin de travailler ensemble est partagé par tous, et nous avons vu qu’il dépasse bien évidement les cadres institutionnels actuels. C’est une vision personnelle, mais ces derniers me semblent peu adaptés au développement d’une communauté qui a conscience que les actions locales se font mieux si elle s’appuient sur des structures nationales mutualisées (ex. grilles de calcul, infrastructures d’hébergement de données, services d’archivage de données numériques). J’invite tous les lecteurs de ce blog, qui soient ou qui se sentent acteurs des digital humanities à signer ce Manifeste qui pose les bases claires d’une communauté se donnant des objectifs précis.

Je pense en particulier aux documentalistes qui sont dans les laboratoires de recherche des sciences humaines et sociales, et dont certains étaient au THATCamp Paris 2010, mais que je trouve toujours trop absents de ces moments de réflexion sur l’évolution des métiers, méthodes, etc. Les documentalistes font un travail de production sur le terrain très important. Au delà des centres de documentation et des bibliothèques de recherche, certains coordonnent réellement des projets de recherche sur le plan documentaire et donc sont pleinement dans les problématiques dont nous avons discutées lors de ces deux jours.

Par exemple, le point 14 du Manifeste propose de construire, de façon itérative, des cyberinfrastructures correspondant à des besoins réels. Voici un chalenge difficile, pris entre les intérêts des économies locales de la recherche proches des chercheurs (Universités, Maisons des sciences de l’homme par exemple) et ceux « inter-nationaux », européens par exemple, pourtant nécessaires mais complexe à comprendre tant il est difficile pour un chercheur de s’y projeter.
Un exemple a été pris par Got sur les questions de l’archivage des données numériques (la mémoire du XXIe siècle). Il faut accepter de faire confiance à une autre institution, à une autre personne, pour archiver ses propres données, issues d’une collecte qui a pu prendre, parfois, toute une vie. « Accepter de faire confiance » c’est avant tout reconnaitre que l’on est pas compétent pour traiter tel ou tel sujets, ou techniques, ou méthode. Cela ne veut pas dire que l’on va perdre « la main » sur les données (les mécanismes de contrôle d’accès existent et sont fiables). Cela ne veut pas dire non plus qu’il ne faut pas tenter de comprendre (loin de moi l’idée de saucissonner les métiers et les taches), mais c’est reconnaitre qu’à un moment, il faut accepter de faire 10 à 15% d’un travail pour lequel l’on ne sera pas reconnu, qui ne comptera pas dans son évaluation personnelle, afin de transmettre à un autre de l’information afin qu’il l’archive, la traite, l’édite, la valorise, la distribue, etc. et vous la repasse parfois pour en faire autre chose. C’est l’un des enjeux majeur du Manifeste selon moi. Les cyberinfrastructures seront ce que nous en ferons, pour cela il faut accepter de faire 10 à 15% du chemin vers le collègue (l’ingénieur ou le chercheur) qui a une ou plusieurs compétences et donc qui a un Métier. C’est aussi considérer que ce qu’il fait est égal à ce l’on fait. Publier un article dans une revue de rang A est égal à concevoir un logiciel permettant de calculer des résultats à partir de données : la seconde tache permettant de faire la première, la première est dépendante de la seconde et la seconde sans la première dans pas de finalité réelle (exception faite pour les questions d’archivages).

Pour moi, il s’agit là d’une formidable aventure que la communauté des digital humanities, rassemblée autour du Manifeste, doit mener.

Crédits photos : Elodie Picard/CLEO-Revues.org – Licence Creative Commons : Attribution-NonCommercial-NoDerivs 2.0 Generic

Le meilleur format de conservation des données numériques, c’est vous.

Got vient de publier un billet très intéressant sur le fait que la notion de format pérenne ne veut rien dire. Je suis entièrement d’accord et nous sommes plusieurs ingénieurs, dans les sciences humaines et sociales numériques, à partager cet avis. L’information, encodée dans un fichier numérique, est dépendante de la structure du format, de ses spécifications, des logiciels capables de lire ce format et d’offrir ainsi « une vue », à un instant T, sur l’information. Faire de l’édition en ligne, diffuser des données, nécessite d’être conscient de fragilité des formats dans le temps. Il est facile de l’être pour qui a déjà perdu des données importantes.
Cela dit, j’irai plus loin que Got.
Dans un cas extrême, un format ouvert, mais mal documenté ou dont la documentation n’a pas été bien maintenue dans le temps, peut être plus complexe à migrer qu’un format propriétaire. Pourtant les formats propriétaires sont liés au cycle de vie de plus en plus court des versions de leurs logiciels « maitres ». S’il est aujourd’hui possible de migrer, sans trop de problème, un fichier propriétaire de la version N à N+1 de son logiciel « maitre », il souvent difficile de faire du N+3 ou 4. Également, certains types de formats sont encore trop propriétaires : c’est le cas des fichiers 3D. Si le VRML, et son « successeur » le X3D sont ouverts et normalisés, ces formats n’occupent pas réellement la place de « format pivots », éligibles à un archivage à long terme de type OAIS : ils sont considérés comme « trop pauvres » par les modeleurs que les format 3D propriétaires de type .max de 3DS max pour cela. Il est d’ailleurs curieux que le VRML et le X3D soient vus comme des formats pivots alors qu’ils n’ont pas été créés pour cela. Souvent, des collègues non spécialistes me dise : « on fera une sortie VRML pour sauvegarde » : sont-ils conscient de l’appauvrissement de l’information entre un fichier max et VRML ? Les travaux du centre de ressources ArchéoVision du CNRS, dirigé par Robert Vergnieux, éclairera ces questions dans les années qui viennent par la création du conservatoire des données 3D du patrimoine.

Formats ouverts, formats propriétaires… maintenir l’accès à l’information est avant tout une histoire de veille technologique humaine et de conseils aux utilisateurs et aux décideurs. Il est aussi important de dire clairement pourquoi un format ouvert peut être, à un moment de son évolution, moins bon pour l’archivage numérique à long terme. Un format bien documenté ne sert a rien si personne n’en suit les évolutions et les usages. Il faut des équipes qui « suivent » les choses dans le temps : l’archivage à long terme des données déposés dans HAL a mobilisé plusieurs équipes formées d’archivistes, d’informaticiens, de chercheurs en amont même !

Ainsi, le meilleur « format » numérique de conservation ne sert-il pas l’humain ?

Stéphane.

Diffusion et édition de bases de données (1)

Bonjour,

La construction des savoirs passe par l’échange, la discussion, la critique et le partage. A l’heure ou l’on utilise la compétition entre les acteurs du monde des sciences pour démanteler les structures recherche, de plus en plus de données : primaires, secondaires ou/et tertiaires sont diffusées ou éditées en ligne sur le web. Dans un précédent billet je tentais, assez maladroitement, de dresser une mini chronologie des digital humanities « à la française » comme dirait Lou Burnard et ce depuis l’arrivée du vecteur web. Ce découpage n’est pas si simple car les acteurs des SHS ne sont pas tous dans une case bien précise. L’appropriation des méthodes et des bonnes pratiques de l’édition électronique sur support web est très inégale et la notion même « d’édition électronique » fait débat : beaucoup de chercheurs dissocient même l’action « d’éditer » du monde du web : un peu comme si le web ne méritait pas d’avoir ses éditeurs et l’idée même de qualité dans l’édition électronique semble parfois impossible à imaginer chez certains. Il faut donc faire œuvre de pédagogie et reprendre nos bâtons d’évangélisateurs pour diffuser les bonnes pratiques de ce domaine, savant mélange de ce qui se fait ailleurs et de ce que nous savons faire de façon collective.

Lors d’une journée d’information organisée par le Centre national de la recherche scientifique (CNRS) à Ivry-sur-Seine, Thierry Buquet, webmaster de l’Institut de recherche et d’histoire des textes (l’IRHT est un laboratoire du CNRS), réalisa un état de l’art de l’édition électronique dans les SHS en 2009 : il indiquait alors le fait que certains « chercheurs éditent des bases de données ». Dans le trop petit monde des humanités numériques, tout le monde comprend presque instantanément ce que cela veut dire et implique et surtout le fait que l’action d’éditer une BDD revient à fabriquer une « vue », un « regard » sur des méta-données ou des données, à un instant « T » : ce sont ces vues qui sont éditées. Les données ont pu être collectées il y a très longtemps, ou bien hier, et elles vont continuer à évoluer dans le temps. Il faudra les pérenniser, les archiver un jour… Ainsi la BDD est un réservoir dont l’une des vocations est de donner accès à de l’information au travers de méta-données (notices bibliographiques par exemple) ou directement de « données brutes » (des données spatiales, des données historiques, etc.) soit à un moment « T » via une édition électronique statique (PDF, etc.), soit via un accès « en flux » via une interface web de recherche par exemple ou via un flux d’information de type syndication (RSS, Atom, etc.), nous pouvons parler là d’édition dynamique des données. Dans ce dernier cas, les informations sont rendues accessibles juste après validation par le chercheurs ou du moins celui qui a l’autorité de valider des informations, mais le contenu de la BDD est vivant : de nouvelles données arrivent, certaines sont corrigées, d’autres supprimées (ce qui pose un problème pour les futurs historiens des sciences), etc. Il s’agit de bien faire la différence entre le fait de stocker de méta-données et des données et de mettre en place des moyens d’éditions de ces éléments. Éditer une BDD consiste donc à créer des vues, des regards, souvent multiples sur ensemble contenu dans un système d’information ou simplement dans un gestionnaire de bases de données.

Cependant, le flux n’est qu’une répétition de « vues à l’instant T » dont le cycle peut-être très court : quelques minutes, secondes, etc. Cette notion de diffusion des « informations en cours de traitement » (data in progress) est assez nouvelle pour les chercheurs des sciences humaines et sociales et elle peut être perçue de façon contradictoire par certains d’entre eux, plus habitués à communiquer seulement les résultats de la recherche qu’une combinaison de résultats étayés par les sources. Concevoir la BDD en SHS comme un réservoir évolutif de méta-données ou de données et en éditer des vues à l’instant « T », permet d’associer à un article les information sources ayant été utilisées dans celui-ci. Cela permet aussi de diffuser plus largement des données vers d’autres collègues, etc.

Mais il y a un revers à la médaille : l’abandon de BDD après la publication finale d’une recherche (c’est le cas dans les projets ANR qui sont plus court que les grands programmes des années 70-90). Avec le numérique et l’obsolescence des formats, logiciels, etc. cela provoque (provoquera) une perte de données. Il faut donc réfléchir en amont à la pérennisation/archivage et aux valorisations futures des BDD construites sur le modèle réservoir/vues. Une piste pour anticiper ces questions : application de certaines méthodes de travail très simples :

  • études, rapport d’étonnement, veille
  • gestion de projets (scénarii pour atteindre l »objectif final, planning, budget)
  • étapes de travail (objectifs à atteindre)
  • validation intermédiaire (audits internes)
  • évaluation des risques

associée à :

  • l’utilisation de standards internationaux normalisés pour l’encodage des données
  • l’utilisation de formats « ouverts » (dont les algorithmes sont ouverts, libres, et bien documentés, etc.)
  • la réalisation d’un effort pour intégrer des outils structures mutualisées.

permet assez facilement de construire et de diffuser des BDD dans le domaine des SHS. Cette réflexion et cette mise en œuvre de solutions, dans les équipes de recherche SHS, c’est le métier des ingénieurs, assistants ingénieurs en humanités numériques, mais c’est aussi celui des documentalistes et e-documentalistes, des bibliothécaires, des informaticiens.

Comprendre cette notion de réservoir d’information prenant la forme de méta-données ou de données (data in progress) et la possibilité de créer des vues multiples – qui elles peuvent être éditées et liées à un ouvrage numérique ou un article – est un point fondamental dans le déroulement d’un programme de recherche. L’édition d’une BDD ne peut se limiter à la mise en place d’un formulaire de recherche, à l’élaboration d’une maquette graphique pour en visualiser les résultats et en faire la promotion ; il faut concevoir les BDD comme des réservoirs capables de diffuser des flux de méta-données ou de données ayant de multiples formes, mais utilisant des formats connus, standards, et donnant accès à de l’information évolutive et validée par versions progressives. Cela nous amènerait-il plus facilement vers le web de données ?

Bien sur toutes les BDD n’ont pas cette vocation, certaines sont uniquement personnelles : le temps d’un article ou d’un ouvrage, mais force est de constater que le nombre de BDD personnelles (sous FileMaker Pro par exemple), qui ont tendance à évoluer vers une BDD « pour le web », est en progression constante depuis quelques années. C’est bien pour la construction des collectives des savoirs et cela fait avancer l’idée de l’importance de la pérennisation des données : mais attention à ne pas déraper dans sens inverse.

Les BDD ne sont pas des livres, mais de nos jours, elles permettent d’en faire. Les BDD ne sont pas des livres et donc elles ne se posent pas, comme un livre, sur l’étagère d’une bibliothèque.

Dans la partie 2, je présenterai la notion d’interopérabilité entre les BDD, que je détaillerai lors de l’université d’été du Centre pour l’édition scientifique ouverte (CLEO).

Stéphane.

digital humanities in Orleans

Bonjour,

Tout en préparant un billet (depuis noël, aie aie aie) sur un outil d’encapsulage des méta-données dans une image avec les possibilités offertes par le format XML couplé à du Dublin Core, j’ai eu l’honneur d’intervenir dans le séminaire de recherche sur l’édition électronique et les digital humanities nouvellement créé par Richard Walter à l’Institut de Recherche et d’Histoire des Textes du CNRS (Orléans). J’ai partagé la première séance de ce séminaire avec Michel Jacobson (DAF ; CNRS), responsable du Centre de Ressources pour la Description de l’Oral (Paris), un centre de ressources numériques du CNRS au même titre que celui que j’anime sur les données iconographiques. Un compte-rendu de ce séminaire a été écrit par Constance Krebs dans son blog amontour.net. Les digital humanities « à la française » comme dirait lou burnard avancent encore un peu, se structurent, réfléchissent et je pense dans le bon sens.
A bientôt pour parler XMP, Dublin Core et Perl.

Stéphane.

De la pérennité des applications web : les 10 ans de DBMAN

Bonjour,

Dans les métiers du Web et des bases de données, il y a parfois des petits miracles ! Je veux dire que les logiciels clients et les applications Web sont souvent considérés comme extrêmement fragiles et que l’évolution technologique les condamnent très rapidement. Cette impression est accentuée par le « vieillissement » de leurs interfaces dû aux modes successives que nous avons traversé (j’entends par là, le Web 1.0, le tout Javascript, le Web 2.0, etc.). Au milieu de tout ça, et du grand « plongeon » vers plus d’interaction entre l’internaute et les sites Web (je préfère d’ailleurs l’expression de plateformes Web, tant « sites web » paraît ancien, cf. le Web 1.0), il est des applications Web qui restent en place, elle évoluent peu, et s’appuient – encore aujourd’hui – sur des langages de programmation et des infrastructures simples. Il en est une qui me tient particulièrement à coeur car elle fut pour moi l’une des briques qui m’a permis de comprendre qu’il était important de mélanger les langages, de tordre les technologies : il s’agit de DBMAN ou Database Administrator.

DBMAN est un système de base de données écrit en langage Perl et qui utilise un simple fichier texte pour le stockage des données. En cette année 2007, DBMAN a 10 ans ! Oui, 10 ans. N’est-ce pas impressionnant tout de même ? J’ai découvert DBMAN grâce à O. Mougel dans le cadre de la réalisation du site du GIS Réseau Aquitain Formation et Information pour le Développement RAFID. Puis j’ai utilisé DBMAN pour plein de choses : Mon DEA d’histoire et d’archéologie médiévale, les bases de données de la filière documentation d’entreprise de l’IUT de Bordeaux où j’étais moniteur puis chargé de cours, Pour la bibliothèque d’Ausonius, pour le GIS Réseau Amérique Latine qui va être l’un des piliers de l’Institut des Amériques, etc. J’ai décliné cette application sous toutes ces formes, j’ai même écrit un plugin en Perl pour faire afficher des objets VRML à la place des notices classiques d’une base de données. Vous le voyez, DBMAN est pierre importante dans mon parcours, puis le couple PHP+MySQL est arrivé est la suite est connue. Mais aujourd’hui, certains DBMAN mis en place en 1997 fonctionnent toujours, ceux utilisés pour mon travail de Maîtrise/DEA par exemple autour de la restitution de la maison forte du Boisset.

Le 12 septembre 2007, DBMAN aura 10 ans. Je tenais, dans un billet de ce blog, tirer mon chapeau à A. Krohn de Gossamer Threads Inc. qui a créé DBMAN et souhaiter longue vie à cette application toute simple mais particulièrement géniale de gestion de bases de données. A l’heure d’AJAX, PHP6, XSTL et Ruby on Rail et des outils web 2.0, j’ai aussi envie de dire : vive le Perl !