Archives par étiquette : bdd

Database

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.

MariaDB : l’avenir de MySQL ?

Bonjour,

Le monde autour de MySQL est en ébullition. Depuis le rachat par Oracle de Sun qui avait lui-même racheté MySQL, l’avenir du développement du système de gestion de bases de données open source le plus utilisé dans le monde est un peu en pointillé ce qui inquiète beaucoup de développeurs, principalement dans le monde de la recherche et de l’enseignement. Premier signe peut-être : la version open source de MySQL dite « Community » est d’ailleurs maintenant fondue dans celle payante nommée « Entreprise ».

Cependant, le créateur de MySQL, Michael « Monty » Widenius, lance MariaDB, un clone de MySQL dans le cadre de l’Open Database Alliance. MariaDB 5.1, qui sortira dans quelques mois, s’appuie donc sur la version open sources de MySQL 5.1 : elle en aura l’ensemble des fonctionnalités selon les dires de M. Widenus.

Stéphane.

La boite à outil de l’e-archiviste

Bonjour,
Les Archives de France ont signalé il y a quelques semaines l’arrivée sur le web du Archivists’ Toolkit ou AT. Il s’agit d’une suite logicielle permettant de produire des instruments de recherche et des outils de gestion pour du matériel archivistique. Il propose également des méthodes permettant l’aide à la création d’inventaires et de descriptions archivistiques. Ce projet est soutenu par The University of California, San Diego, New York University, and the Five Colleges, Inc.. Cette boite à outil est proposée sous licence ECL (Educational Community License).
AT utilise une simple base de données MySQL pour fonctionner. Il permet l’import d’EAD 2002, MODS, METS et en sortie : EAD 2002, MARC XML, METS, MODS, Dublin Core. L’interface de saisie est très simple, clair, et permet de travailler rapidement pour peut que la machine soit un peu puissante.
Je teste activement cette suite, résultats dans quelques semaines, après la 3eme conférence sur les normes internationales pour les archives numériques.

Archives scientifiques, instruments de recherche XML et virtualisation des données

Bonjour,
L’utilisation de la DTD, puis maintenant du schéma Encoded Archival Description ou EAD permet de réaliser une version numérique d’un inventaire archivistique. L’inventaire (qui lui doit respecter la norme ISAg de l’ICA) est à l’archiviste ce que la base bibliographique est au bibliothécaire, c’est à dire la pièce maitresse avant toute diffusion d’un fonds. Sans inventaire, pas de communication du fonds d’archive. C’est particulièrement vrai – et important – avec les archives de science et les fonds d’archives de savants (au sens XIXe siècle du terme) et de chercheurs. L’inventaire peut être réalisé sous un simple éditeur de texte (MSWord, Open Office Writer, etc.) mais aujourd’hui, il est mieux de le réaliser en XML en suivant le schéma EAD. (ex. DTD datant de 2002). L’encodage en EAD, permet de créer un fichier XML composé de deux grandes parties :

• le header : l’entete du document avec les descriptions du fonds
• le archdesc : la presentation des niveaux : du fonds jusqu’à la pièce (item), c’est à dire le document lui-même (la photo, le cahier de notes, etc.)

L’encodage EAD peut-être réalisé dans logiciel d’encodage XML tel que XMetal (payant) ou XMLmind (gratuit). XMLmind est particulièrement intéressant car l’on peut y ajouter des feuilles de style XSL permettant de travailler très simplement via des formulaires de saisie de type « pages web » (voir le système ATES). Une fois l’encodage XML réalisé, il faut différencier le stockage des fichiers XML+les documents numériques qui y sont associés d’exploitation que l’utilisateur peut en faire. D’une part, il faut mettre en place un système de gestion qui assure la pérennité des données (transformations des formats images, suivit de l’évolution des DTD et des schémas XML, suivit juridique de la communicabilité, etc.) et d’autre part une plateforme qui permet la diffusion, via des applications (qui peuvent être multiples), de ces fichiers XML encodés suivant la DTD ou le schéma EAD. Les fichiers EAD deviennent alors des instruments de recherche dans les fonds d’archives. Dans l’application du modèle OAIS, la pérennité des données est une chose, l’exploitation des données en est une autre. Les images et fichier EAD peuvent être sur un serveurs dédié, les applications sur un autre (avec derrière une belle équipe d’ingénieur système) : c’est la virtualisation des données. Le tout fonctionne car l’ensemble des briques (stockage, exploitation, diffusion) respecte des règles communes : c’est le modèle OAIS.

Bonne fin de semaine,

Stéphane.

USBDS : Unité de Stockage des Bases de Données Scientifiques

Bonsoir,

Toujours dans mes réflexions sur le stockage et l’archivage des bases de données scientifiques des chercheurs de mon équipe, je travaille sur la mise en place d’une USBDS (Unité de Stockage des Bases de Données Scientifiques) autour d’un schéma XML. L’idée est partie d’un problème semble, un serveur web contenant des bases de données avec interface de gestion et d’interrogation n’est pas éternel.

Il faut donc une unité de stockage et d’archivage des bases de données scientifique ou les chercheurs et ingénieurs pourraient déposer outre les données au format natif de leurs bases (.sql par exemple) mais aussi un fichier XML respectant mon schéma XML et décrivant l’application et la base de données (format, système, etc.).

Tout cela pour ne plus perdre des données, des heures de travail, et des pratiques. Suite… au prochain épisode.

Stéphane.

ICEberg 4 sur les rails.

Bonsoir,

Je profite des vacances pour avancer la mise en place d’ICEberg 4 ! Les tests avancent plutôt bien : il est sûr que préparer la nouvelle version de mon gestionnaire de corpus numériques au bord d’une piscine c’est assez génial : un plouf entre deux class php. Mes deux compagnons de programmation de cette nouvelle version : Romain et Frédéric ont maintenant terminé leur travail, j’ai pris la suite pour assembler les blocs, débuguer, relire, reprendre, améliorer le tout. ICEberg 4 s’appuyera sur MySQL et PHP 4 ou PHP 5 (nous avons prévu les deux versions au cas ou…la version « tout XML » : ICEbergXML reste toujours disponible…). La partie « berg » est nettement plus opérationnelle : les chercheurs maitrisant l’informatisation de leurs propres corpus vont être contents ! la partie ICE reste dans la même idée que celle de la version 3 : nous n’avons changé que de petites choses sur le plan de l’interface. Cependant, le code a été totalement ré-écrit par Frédéric avec des class en PHP 5.

L’autre jour, un chercheur me demandait pourquoi j’avais fait un outil « propre » alors qu’il en existe plein sur le web tel que PLEADE, ARCANE, etc. Je lui est dit qu’il arrive un moment ou il faut développer un outil dédié pour répondre à une demande forte qui apparaît. Il existe Photoshop, pourtant des programmeurs ont développé GIMP ! ICEberg répond à un besoin : la mise en ligne et la gestion de paquets de documents numériques (d’archives, issus de documents actuels, des photos, bref tout type de documents numérisés) en utilisant un gestionnaire de base de données « libre » ou du XML, rien de plus. J’ajoutais qu’il n’y a pas de moteur recherche puissant dans ICEberg, j’en prépare un avec l’aide du CNRS mais il ne sera pas dans ICEberg, mais il fonctionnera au-dessus ; balayant ainsi l’ensemble des corpus numériques, même chose pour le module OAI d’ICEberg.
Ainsi, ICEberg tend toujours vers le plus simple : des modules y sont ajoutés, mais toujours de façon annexe, sans toucher au noyau. Mais de temps en temps, nous réécrivons une nouvelle version de la partie « dure » d’ICEberg : nous y sommes.

Je m’en retour à mon code :-). Bonne soirée, Stéphane.

ICEberg 4 béta.

Bonjour, Nous allons sortir ICEberg 4.0.1 en version béta avec une démo sur le serveur du CRHST (http://www.crhst.cnrs.fr). ICEberg, le produit phare qui permet à nos corpus numériques de tourner a été totalement re-programmé par notre équipe (Frédéric Costantini, Romain Mindchella, sous ma direction et avec l’aide et les conseils de Lucie Secchiaroli, Delphine Usal, Christine Blondel, Marie-Hélene Wronesky et Françoise Cornière). Il est compatible avec PHP 5 et MySQL 4. D’un simple ensemble de scripts écrit en PHP, ICEberg est devenu un CMS ou plutôt un CM2S : Content Management System for Science.

Cette refonte d’ICEberg va d’ailleurs aller plus loin, ICEberg 4.0 changera de nom en octobre 2006 et il sera diffusé sous licence CeCILL. Car le concept de l’outil a évolué.

Stéphane.

Editer sur le web des sources pour la recherche.

Bonjour,
J’ai pris du retard dans la publication de mon blog. Je suis dans la création de silos de documents numériques (norme ISA(G) pour les catalogues, etc). Je vous conseille en tout cas de lire l’article d’un collègue de l’Ecole Nationale des Chartes sur l’édition électronique :

Gautier Poupeau, L’édition électronique change tout et rien. Dépasser les promesses de l’édition électronique, Le Médiéviste et l’ordinateur, 43, 2004, [En ligne] http://lemo.irht.cnrs.fr/43/43-03.htm et surtout de consulter le site sur METS : http://www.loc.gov/standards/mets/.

ICEberg : présentation générale

ICEberg est un outil de gestion de corpus scientifiques en ligne. Il permet la mise sur internet de collections de documents numériques en séparant la nature du document de son traitement scientifique (qui peut-être réalisé par d’autres outils). Ce n’est pas un CMS (tel que SPIP, Plone, etc.) ni un outil de publication ou d’édition en ligne (avec une charte éditoriale et des styles par exemple), c’est un gestionnaire simple de données textes ou images (jpg, png ou gif), mais il est composé de deux blocs : ICE (partie de navigation) et berg (partie de gestion). Il est programmé en PHP et fonctionnant avec MySQL. Cet outil a une histoire qui est liée à mon parcours professionnel. Vous pouvez en savoir plus avec le powerpoint suivant sur les dernières infos d’ICEberg : http://halshs.ccsd.cnrs.fr/halshs-00006568.

1) L’histoire d’ICEberg : histoire de l’outil et parcours de fin d’étudiant

En 1997, au cours de ma maîtrise d’histoire (UMR Ausonius – Service Informatique de Recherche en Archéologie dépendant de l’Université de Bordeaux 3 et du CNRS), j’ai été confronté à la question de la mise en ligne de mes sources historiques. Très rapidement et sous la direction de Robert Vergnieux et de Gérard Louise, j’ai du trouver un outil simple de gestion de base de données en ligne (voir : http://www-sira.u-bordeaux3.fr/boisset/). Dans mon travail de maîtrise et de DEA j’ai travaillé avec le logiciel DBMAN créé par Gossamer Threads Inc. DBMAN est outil de gestion de fichier .txt écrit en perl. DBMAN est un shareware. Il est cependant limité car il ne permet pas de faire du relationnel entre les bases de données. J’ai donc commencé à concevoir un outil propre s’appuyant sur un modèle de table très simple dont le but fut de séparer le contenant du contenu. Travaillant sous la direction de Robert Vergnieux et avec Jacques Perconte sur ce sujet nous avons créer le tabloïde (là aussi du perl et des fichiers .txt pour les tables : permettant un stockage pérenne des données). Le tabloïde permet la gestion simple de galerie d’images en ouvrant un lien vers une gestion du contenu scientifique de façon ad hoc.

Lors de mon DEA d’histoire à Bordeaux 3, j’ai créé un autre outil à l’aide de DBMAN qui permet de gérer du VRML de façon dynamique : c’est le SIHA3D qui est d’ailleurs de précurseur d’ICEberg (voir : http://www-sira.montaigne.u-bordeaux.fr/boisset/cgi/vrml/db.cgi?db=default&uid=default) et surtout ce résumé du process : http://www.technart.net/metamorph/mem/STEPHANE/.

Je passe mon DEA…puis vint le PHP et MySQL…:-)

Entre 1999 et 2001 j’ai commencé à développer en PHP et avec MySQL des outils proches du SIHA3D à destination d’autres disciplines la géographie, l’histoire, la documentation (voir RAFID www.rafid.u-bordeaux.fr. C’est la période ou ICEberg est né. J’avais du temps – j’étais encore étudiant :-) – et PHP+MySQL m’ont permis de développer un outil simple (des scripts en PHP) et sur un modèle de tables relationnelles sous MySQL (nommé « la triplette ») qui permet de faire fonctionner le tout.

En 2002…Je rentre sur concours au CNRS en tant qu’IE !

Je suis affecté dans l’UMR 2139 (aujourd’hui regroupée avec le Centre Koyré – UMR 8560). Je suis le webmestre de l’équipe et je travaille sur le site www.lamarck.net créé par Pietro Corsi (Professeur à l’Université de Paris 1 et à l’EHESS et aujourd’hui professeur à Oxford). Le site Lamarck fonctionne en ASP+ACCESS avec l’outil PINAKES développé par Andrea Scotti en Italie (Florence). Le serveur est installé à l’ENS sur une machine windows. Très rapidement le développement du site nécessite un changement de technologie : l’ASP est peu fiable en terme de sécurité (c’est un mystère pour personne) et ACCESS est limite pour gérer les 10.000 pages de manuscrits + les 19.000 planches d’herbier que Pietro Corsi souhaite ajouter au site. Personnellement je connais bien mieux le PHP que l’ASP que je trouve lourd en terme de développement et gourmant en ressources. Sortant ICEberg de mes tiroirs, nous avons donc mis ICEberg en production pour le site Lamarck. Le basculement ACCESS vers MySQL n’a pas été simple. Nous avons tout re-modélisé en utilisant la triplette plutôt que les 40 tables ACCESS (je ne me souviens plus du chiffre exact en fait, mais c’était pas « migrable » en tout cas !).

En 2002, je réalise pour le Lamarck un ICEberg V0.1 qui fonctionne toujours sur le serveur. Nous créons avec cette version le site Lavoisier avec association avec Marco Beretta (Panopticon Lavoisier) et le site Science 1800 (créé par Pietro Corsi).

En 2003, Je sort la version 0.7 : première version ayant la forme actuelle (avec les menus en haut). Le site Lamarck bascule dans cette version. Bien entendu les version 0.1 et 0.7 sont compatibles…

En 2004-2005 : Nous montons les sites www.ampere.cnrs.fr, www.buffon.cnrs.fr, www.histmap.net, www.hstl.crhst.cnrs.fr/criminocorpus avec la version ICEberg 0.7 puis 1.0.

En juillet 2005, je réalise la version ICEberg-XML (expérimentale et n’utilisant plus MySQL, juste des fichiers XML). Nous avons donc aujourd’hui deux outils :

ICEberg-DB : PHP+MySQL
ICEberg-XML : PHP5+XML

ICEberg est le fruit d’un travail commencé en 1997 lors de ma maîtrise d’histoire et il n’aurait pas vu le jour sans le soutien de Robert Vergnieux (IR CNRS), Gérard Louise (Professeur des Universités) aujourd’hui décédé, Michel Bochaca (Professeur des Universités), Jean-Michel Roddaz (alors directeur d’Ausonius). Mais également de Daniel Pouyllau (IR CNRS), Marie-France Pouyllau et mon épouse Jannick.

Ainsi que Gwenaëlle Boulissière, Anne Dubois, Jacques Personte, Marie Péres, Pietro Corsi, Dominique Pestre (Directeur d’Etudes à l’EHESS), Vincent Leguy, Delphine Usal, Lucie Secchiaroli, Olivier Bertoncello.

2) Caractéristiques

ICEberg est un outil au sens ou il rend un service entre un serveur Apache et un chercheur : c’est donc un service web développé en PHP 4.3 et fonctionnant sous MySQL 4.0.x dans sa version actuelle. Il permet la diffusion de documents structurée. Il est un élément (une brique!) de base dans la construction d’un site web de recherche. Il est programmé en fonctions PHP. Il est compatible avec Verity via XVgateway.

3 ) Développement

J’assure le développement d’ICEberg. Le rythme n’est pas régulier pour le moment car je suis seul à y travailler en tant que codeur. Un jour, je monterai une équipe CNRS peut être ;-). J’ai en ce moment une petite équipe de bénévole qui travaille avec moi.

4) Mini-FAQ

ICEberg est-il libre ou open source ? :

Non, son code n’est pas encore ouvert et sa diffusion n’est pas encore possible car l’outil n’est pas terminé pour une exploitation par des tiers. Je pense mettre un jour ICEberg sous licence CeCILL.

Est-il gratuit ?

Quand il sera diffusable, il sera gratuit (sous licence CeCCIL).