De l’interopérabilité au web de données

J’ai eu la chance de participer à l’Université d’été de l’édition électronique (Marseille, 7-11 septembre 2009) où j’ai parlé d’interopérabilité et de circulation de l’information scientifique et technique. J’ai axé mon propos sur le fait que l’interopérabilité des données est peut-être la première marche vers la mise en place du web de données. Il est probable que pour faire le web de données il nous faille passer d’abord par un web des données (comptons aussi un peu sur les institutions françaises pour cela) même si l’appropriation et l’utilisation de standards communs est de plus en plus naturel et que l’utilisation du Dublin Core Element Set ne fait plus réellement débat dans la communauté  scientifique. Gautier Poupeau a présenté dans un billet une mise au point entre la notion de web sémantique et celle de web de données qui résume assez bien ma vision des choses sur ce que le web de données pourrait être et pourquoi il est important que les professionnels de l’information scientifique et technique soient dans ce train là.

Le web de données c’est la réalisation d’une base de données mondiale ou les données sont-elles même sur le réseau (et pas juste leurs méta-données). En discutant avec des chercheurs, collectant des données et les stockant sur leurs petits disques dur dans leurs bureaux, j’ai envie de leur dire à la façon de Tim Berners Lee : « libérez vos données ! mettez-les sur le réseau ! vous faites des images ? renseignez bien vos champs de description IPTC-Core et mettez vos images sur le réseau ! ». Bien sur, il y a 1.000.000 de raisons pour qu’ils ne le fasse pas : ils ont une recherche en cours que le voisin veut surement leur voler, ils pensent que seul l’article final leur permettra d’être (re)-connus, et peut-être, ce ne sont pas leurs photos. Les documentalistes, bibliothécaire, archivistes ont un rôle majeur dans la réalisation d’un web qui contiendra des données « brutes » (certains disent primaires, factuelles, de terrains, d’enquêtes, etc.). Je renvois au projet data.gov ou nous imaginons bien le travail d’IST qui peut s’y développer. Construire le web de données nécessite de structurer les données avant qu’elles n’existent parfois. Dans les Sciences humaines et sociales, il faut aider les chercheurs – dont le volet technique, normatif, informatique n’est pas le métier – a le faire. Il faut leur expliquer, ce que j’aurai sans doute pu mieux faire à Marseille, que l’augmentation de la masse des données brutes, maintenant accessible, permet aux chercheurs de travailler sur des corpus plus larges, mieux documentés.

L’interopérabilité des données c’est mettre en œuvre une politique scientifique et technique permettant :

  • de rendre (plus) accessible ces propres données dans un maximum de langages documentaires partagés par le plus grand nombre ;

  • de garantir l’accessibilité de ces données dans temps : ceci pour la citabilité des données dont la privatisation, par le DOI par exemple, pourrait avoir des conséquences dramatiques. Je milite là pour une évolution des identifiants OAI ou autres vers de véritables identifiants pérennes et uniques, garantis par un organisme international type UNESCO ;

  • de faire vivre des données numériques : ajout de classifications, de schémas de description (documentaires dans un premier temps), prise en charge de pérennité des données par le développement de formats pivots pour la préservation ;

Ces trois items sont, pour moi, les trois piliers de l’interopérabilité des données dans une optique future du web de données. Aujourd’hui, il nous est difficile de sortir du carcan de la pensée documentaire comme dirait Got car les méthodes, techniques et outils qui sont enseignés correspondent encore au monde d’avant le web et nous n’avons pas encore d’outils de masse pour le monde d’après le web, mais ils arrivent et il nous faut faire œuvre de pédagogie. En attendant, nous chérissons nos méta-données. Il nous faut nous interroger sur l’encapsulation des méta-données descriptives dans les données (étape n°2 sur le chemin du web de données ?), mais aussi comment signaler à nos machines que la description d’une image est là au milieu des bits de l’image.

L’interopérabilité des données entre machines, via des méta-données, est la première marche, le premier pas vers le web de données. Si plusieurs techniques existent, l’OAI-PMH couplé aux descriptions en Dublin Core, représente le plus souvant le volet technique, informatique de l’interopérabilité des données aux yeux des professionnels de l’IST. La mise à plat des méta-données, dans l’OAI-PMH, a un avantage : il met à plat réellement les méta-données et nous oblige à repenser le rapport entre données, méta-données et le fait que, avec l’OAI-PMH, ce qui en sort, c’est du XML et pas une page web en HTML. On utilise le web pour faire autre chose que du HTML et des « pages » ; tout en se gardant la possibilité d’en faire, le web muterait-il ?. Nous faisons des flux de méta-données dans un langage pour des machines (aujourd’hui c’est du XML, mais demain…) : le web n’est pas que le territoire du HTML, il devient dynamique, il est un flux. Avec l’OAI-PMH, ce qui sort, c’est du flux XML (fluxml, cela fait vieux médicament) et pas une page web, pourtant il y a dedans de l’information mais nous échangeons juste de l’information sur la données, il nous faut aller plus loin. L’interopérabilité des données c’est presque un web des données.

Le mouvement est-il en marche ? Le réseau national des documentalistes du CNRS organise en octobre 2009 trois jours autour de l’OAI-PMH et j’espère son évolution future OAI-ORE. En 2010 aura lieu une seconde école thématique, très pratique, sur les sources numériques et l’interopérabilité des données. Ces sessions de formation continue sont bien évidement le reflet de ce qui se passe dans les IUT et à l’Université. Il me semble que ces éléments en sont des signes favorables.

Master Archives et Images

Bonsoir,

Au détour d’un chemin numérique, guidé par del.icio.us, je suis tombé sur cette formation : le Master Archives et Images de l’université de Toulouse II et sur le site des Anciens étudiants de ce master, regroupé en une association : l’AICI. Cette association développe un site web, très intéressant, qui utilise les flux RSS de del.icio.us dans SPIP : voici une belle illustration du web 2.0 pour de la veille.

Stéphane.

La démocratisation du XML documentaire

PS postconférence : la présentation est disponible en ligne, au format PDF (8Mo), depuis ce lien : A l’heure de la démocratisation du XML documentaire

Bonsoir,

Aller, de l’autopromo en ce dimanche soir… J’animerai, le 27 mai 2008, à la Maison des Suds (domaine universitaire de Bordeaux, 12 esplanade des Antilles, Pessac) et à l’invitation de l’ADBS Aquitaine un séminaire sur la démocratisation du XML documentaire. Je présenterai aussi la façon de concevoir des applications composites (ou mashup) utilisant le XML au travers des réalisations du Centre National pour la Numérisation de Sources Visuelles du CNRS (CN2SV) et du Centre de Recherche en Histoire des Sciences et des Techniques dont j’ai le plaisir d’être le responsable technologique. C’est la conception d’applications en « briques ». Nous sommes tous des « chefs de chantier » et des maçons.

Le langage XML a 10 ans. Il s’est imposé dans de nombreuses applications et méthodes permettant le traitement de l’information scientifique primaire (TEI, XML ALTO, MathML, X3D, GeoXML, KML etc.) et secondaire (MarcXML, BiblioML, EAD, EAC, XMP, etc.).

A la démocratisation du XML correspond l’émergence, dans la recherche en sciences humaines et sociales, d’équipes associant documentation, informatique et informatisation des données primaires, archivistique et edition électronique au service de projets de recherche. Un grand nombre de ces équipes font elles-même de la recherche sur un domaine encore nouveau en France: les humanités numériques (ou digital humanities) et créent des réseaux d’échanges d’informations, méthodes, briques logicielles, etc. (ex. : Mutec ; les 5 centres nationaux de ressources numériques ; la plateforme 3D ArchéoVision ; etc. ). L’utilisation du XML permet de partager de l’information (RSS, Atom) ; déployer des solutions hybrides à l’aide de petits connecteurs utilisant XML (GeoData, utilisant GéoXML, pour le CN2SV qui est capable de « dialoguer » avec l’API de Google Maps et donc vers du KML) mais surtout, XML est un moyen de ce comprendre, de s’entendre entre documentalistes, informaticiens, archivistes, chercheurs. Ceci est plus que nécessaire à l’heure de la recherche sur projets où la question de la pérennité des données numériques sera l’un des critères d’évaluation et où elle est déjà fondamentale pour tous projets à dimension internationale (voir, par exemple, le protocole OAI-PMH qui utilise XML).

Le CN2SV (opérateur du TGE ADONIS), associé à la plateforme technologique du Centre de Recherche en Histoire des Sciences et des Techniques, forme, depuis 2002, l’une de ces équipes. Spécialisé dans l’informatisation des données en histoire des sciences et des techniques et en re-documentarisation de données factuelles à caractère iconographiques, le CN2SV et le CRHST ont développé de nombreuses applications qui utilisent du XML normé (EAD, MathML, etc.).

Ainsi, ce séminaire présentera, au travers de l’expérience et des nombreuses réalisations du CRHST et du CN2SV : les méthodes et normes XML qui peuvent être utilisées et associées pour créer des systèmes d’information scientifiques et documentaires, des exemples d’applications web composites et des outils permettant l’interopérabilité des données.

XML est partout et il est de plus en plus transparent (caché dans le format *.odt d’Open Office, ou dans nos flux RSS, etc.). XML peut être un ciment, un langage, un vecteur. Rendez-vous le 27 à Bordeaux…

Bonne soirée.

Stéphane

Décrire un objet numérique ou numérisé : utilisation du Dublin Core

Bonjour,
La semaine passée un chercheur me demande : « J’entends parler de métadonnées en Dublin Core, qu’est-ce ? ». Après explication, je me suis aperçu que faire l’association entre les champs d’une base de donnée – décrivant des objets numériques ou numérisés – et la notion de métadonnées XML n’était pas forcement naturelle. Plus qu’une différence de vocabulaire, il s’agit d’un terrain inconnu avec son lot de mystères et de rumeurs inquiétantes. La notion de champs de description, dans une base de données comportant une ou plusieurs tables, est assez connue aujourd’hui ; mais l’interaction entre ces champs et des métadonnées est assez nouvelle pour le grand public. L’information stockée dans un champ d’une table de données (par exemple le nom de l’auteur du document, ou sa date) peut être utilisée de différente façon. C’est là l’une des clés de la compréhension des métadonnées. Cette information peut être affichée directement sur un site web via l’intermédiaire d’un programme informatique (écrit en PHP ou Perl par exemple). Mais elle peut également servir à renseigner la valeur d’une balise HTML (dans une entête de fichier HTML), ou la valeur d’une balise XML (dans un fichier XML servant à échanger ou préserver donc de l’information de façon indépendante via à vis des logiciels courants).

Prenons l’exemple de deux équipes de recherche qui souhaitent échanger des informations. Chacune des équipes a créé une base de données qui a, pour des raisons historiques et pratiques, des champs différents : c’est à dire que les modélisations sont différentes car les besoins ont été listés sans concertation au départ. L’un des moyens pour échanger des informations entre ces deux bases de données est d’avoir un format commun aux deux équipes : par exemple s’échanger des fichiers textes (ou XML) en ayant structuré l’information de telle façon que les deux équipes seront capables de ranger ces informations dans les bonnes « cases » (champs) de leurs bases de données respectives.
Il existe pour cela des normes de structuration de l’information (l’on dit aussi grammaire ou syntaxe). L’une des plus utile dans le monde de la recherche est la norme Dublin Core (ou DC). Le DC est une norme simple de description bibliographique créée pour les documents numériques. Le DC définit un ensemble d’éléments (l’on dira métadonnées ou « données de données ») qui sont au nombre de 15 pour le DC dit « non qualifié » (norme ISO 15836 de février 2003) :

  • -le titre,
  • -le créateur,
  • -l’éditeur,
  • -le sujet,
  • -la description (sorte de résumé, qui peut se rapprocher de « l’Analyse » pour les médiévistes),
  • -la source,
  • -la langue,
  • -la relation (relation ou lien avec une autre ressource DC),
  • -la couverture (l’aspect spatio-temporelle de la ressource : géographies, chronologie),
  • -la date,
  • -le type (images, sons, textes),
  • -le format (le format de la ressource : txt ; wmv ; pdf ; ogg ; php ; mov ; rtf ; ops ; etc),
  • -l’identificateur (DOI ; URL ; id OAI-PMH),
  • -le contributeur (personne physique ou moral ayant participée à l’élaboration de la ressource),
  • -les droits.

Ainsi, il est facilement possible de configurer une base de données MySQL, PostgreSQL, MS-Access ou même OpenOffice suivant ces « champs » et de créer un format de sortie XML reprennant les 15 élements DC. C’est le coeur, par exemple, des enregistrements dans un entrepôt OAI-PMH :

<record>
   <header>
    <identifier>oai:www.crhst.cnrs.fr:hstl-000101</identifier>
    <datestamp>2007-01-15T15:04:36Z</datestamp>
    <setSpec>manuscript</setSpec>
   </header>
   <metadata>
     <oai_dc:dc
       xmlns:oai_dc="http://www.openarchives.org/OAI/2.0/oai_dc/"
       xmlns:dc="http://purl.org/dc/elements/1.1/"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/oai_dc/
       http://www.openarchives.org/OAI/2.0/oai_dc.xsd">
      <dc:title>Autobiographie d'Ampère.</dc:title>
      <dc:creator>André-Marie AMPERE</dc:creator>
      <dc:subject>history</dc:subject>
      <dc:description>Cahier manuscrit de 16 feuillets dont les 8 premiers feuillets sont autographes...</dc:description>
      <dc:publisher>Christine BLONDEL</dc:publisher>
      <dc:contributor>CNRS, CRHST</dc:contributor>
      <dc:contributor>HSTL : Delphine USAL</dc:contributor>
      <dc:date>1824-00-00</dc:date>
      <dc:type>studies materials</dc:type>
      <dc:type>text</dc:type>
      <dc:format>xhtml from databases</dc:format>
      <dc:identifier>http://www.ampere.cnrs.fr/ice/ice_book_detail-fr-text-ampere-ampere_text-8-3.html</dc:identifier>
      <dc:source>http://www.ampere.cnrs.fr/ice/ice_book_detail-fr-text-ampere-ampere_text-8-3.html</dc:source>
      <dc:language>french</dc:language>
      <dc:coverage>ampère</dc:coverage>
      <dc:coverage>autobiographie</dc:coverage>
      <dc:coverage>electricity</dc:coverage>
      <dc:coverage>AMPERE</dc:coverage>
      <dc:coverage>XIXe</dc:coverage>
      <dc:coverage>France</dc:coverage>
      <dc:rights>public domain</dc:rights>
     </oai_dc:dc>
   </metadata>
  </record>

Nous voyons bien dans ce cas, que les balises XML utilisant le DC sont au coeur de la notice (dc:title par exemple). La notice XML, écrite en DC, est encapsulée dans d’autres balise XML propres à l’OAI-PMH. Cette notice XML DC est en fait générée par un script PHP (que nous pouvons nommer application ou programme) à partir d’une base de données MySQL.

Bonne journée,

Stéphane.

KML simple et géodonnées (partie 1)

Il est possible de construire rapidement de petites applications simples permettant d’exploiter des documents issus d’archives visuelles (cartes, photos, plans) en les connectant a des données bibliographiques. Ces applications utilisent de plus en plus les langages du web (et, depuis 2005, ceux du web 2.0) et elles se développent autour d’XML. Voici une première partie/introduction au KML et le début d’un exemple avec le géo-référencement 2D de cartes anciennes via Google Maps, du KML et du XML.

Le KML (Keyhole Markup Language) est une grammaire XML permettant d’afficher et de gérer des données dans Google Maps et Earth. Il offre la possibilité de poser des points, tracer des lignes, des polygones. Dans Google Earth, s’y ajoute les angles de vue, les objets 3D simples ou texturés. Mais l’une des fonctionnalités les plus intéressante pour la recherche reste l’enrichissement en données externes. KML peut diffuser des données XHTML riches (textes, images, videos), des images plaquées sur la photo satellitaire, etc…

Il existe une version compressé du KML, le KMZ. Pour ceux qui ont utilisé comme moi du VRML (Virtual Reality Modeling Language), nous avions aussi une version « Gzipé » du langage : le .wrz (à la place du .wrl). le KMZ encapsule aussi les images qui peuvent être liées au fichier KML. Il est possible de fabriquer du KMZ avec un simple compresseur : WinZip, Gzip, etc.

Sur le plan syntaxique, le KML se présente comme du XML :

<?xml version= »1.0″ encoding= »UTF-8″?>
<kml xmlns= »http://earth.google.com/kml/2.2″>
<Placemark>
<name>Siège du CNRS</name>
<description>Paris, le siège du CNRS.</description>
<LookAt>
<longitude>2.264605600614077</longitude>
<latitude>48.84727288728012</latitude>
<altitude>0</altitude>
<range>171.6689944655567</range>
<tilt>-6.848248640637841e-011</tilt>
<heading>0.0004740658326556625</heading>
</LookAt>
<Point>
<coordinates>2.264605600614077,48.84727288728013,0</coordinates>
</Point>
</Placemark>
</kml>

Ce petit fichier KML permet de placer dans Google Earth ou Maps, un point localisé sur le siège du CNRS, l’élément <LookAt/> correspondant au point de vue de la caméra qui « regarde » ce point. <Placemark/> encapsule le <Point/> géocodé présentant la latitude et la longitude. Dans le monde Earth / Maps de Google, les coordonnées géographiques sont en degrés décimaux (comptés positivement vers le Nord pour la latitude, et vers l’Est pour la longitude). Ici, le géocodage est très précis (2.264605600614077), mais si vous utilisez l’API de Maps, la précision est de l’ordre du mètre. Autre limite, dans Google Maps, seuls certains éléments peuvent être utilisés : les points, les lignes, les polygones, les styles, les icônes et les liens et l’application de couches multiple (placage d’images), mise en œuvre de dossiers et types de vues. Pour le moment (version 2.2 du KML) la 3D n’est pas utilisée (nous sommes dans Maps, donc le royaume de la 2D).

Ce petit exemple, permet de ce lancer dans la construction de fichiers KML et ainsi enrichir en information de toutes sortes de cartes dans le vaste « bac à sable » que peut être Google Maps ou Earth. De nombreux scientifiques, les géographes principalement, utilisent déjà ce format. J’ai découvert aussi ce site qui présente Google Earth et le KML pour les enseignants du secondaire. Le KML n’est pas le seul format XML dans le domaine des « géo-formats/2D/3D » : il y a le WMS, WFS et GML venant du monde de la géographie, les formats pour « services web » : AtomPub, GeoRSS et le KML/Z (avec d’autres limites cependant).

Dans le cadre du CN2SV, nous avons publié l’inventaire d’un fonds de cartes topographiques anciennes (XIXe-XXe siècle) de la cartothèque du centre de documentation REGARDS-CNRS. Nous avons décidé de coupler ce fonds de cartes, après numérisation, avec une base de données bibliographique/documentaire classique. Pour cela, nous avons utilisé une base de données intermédiaire qui, à partir des données lat./long. des quatres angles d’une carte, a pour mission de stocker des données pour produire à la fois du KML (pour l’instant sous la forme de petit fichier, donc nous sommes en mode asynchrone) qui peut être utilisé dans Google Earth pour visualiser l’emprise de la carte, ces villes importantes, etc. Mais aussi du XML compatible avec l’API de Google Maps (qui est légèrement différent du KML natif, du moins dans sa version 2.2 ).

Dans un second temps, j’ai développé une petit programme PHP qui exploite ces fichiers XML (pour l’API…) dans un contexte l’application riche. Du KML simple, nous passons dans un micro format XML propre (mais nous pourrions faire cela avec du KML directement, c’est juste une histoire d’optimisation du fichier pour l’API de Google Maps), ainsi pour chacune des cartes nous avons ceci :

Capture d'écran de l'application CN2SV pour les géodonnées

 

<?xml version= »1.0″ encoding= »UTF-8″?>
<mygeod xmlns= »http://www.cn2sv.cnrs.fr/xml/mygeoc/0.1″>

<markers>
<marker lat= »-20.53105″ lng= »47.24332″ label= »Ville d’Ambositra » html= »Informations sur la ville d’Ambositra <br>avec la base de données REGARDS-ADES-CNRS » infolink= »query.php?value=Ambositra »/>
<marker lat= »-20.62105″ lng= »47.20332″ label= »Carte de Madagascar » html= »Informations sur la ville d’Ivato <br>avec la base de données REGARDS-ADES-CNRS » infolink= »query.php?value=Ivato+Madagascar »/>
<marker lat= »-19.871795326377995″ lng= »47.03521728515625″ label= »Carte de Madagascar » html= »Informations sur la ville d’Antsirabe <br>avec la base de données REGARDS-ADES-CNRS » infolink= »query.php?value=Antsirabe »/>
<marker lat= »-20.27137605095937″ lng= »44.31661605834961″ label= »Carte de Madagascar » html= »Une carte est disponible » infolink= »?id=R_MADA11_04_00014″/>
<line colour= »#ff0000″ width= »5″>
<point lat= »-19.40″ lng= »45.32″/>
<point lat= »-19.40″ lng= »48.11″/>
<point lat= »-21.20″ lng= »48.11″/>
<point lat= »-21.20″ lng= »45.32″/>
<point lat= »-19.40″ lng= »45.32″/>
</line>
<center lat= »-20.33″ lng= »46.90″ zoom= »8″/>
</markers>

</mygeod>

Ce fichier XML permet de délimiter la couverture de carte et de pointer des lieux (les « markers » de Google Maps). Les attributs sont très simples :

  • label : titre de la vignette/popup
  • html : contenu de la vignette/popup
  • lat : latitude
  • lng : longitude
  • zoom (pour <center/>) : facteur du zoom d’entrée dans la carte
  • infolink : lien vers le connecteur de/des bases de données à interroger (mais on pourrait imaginer une chose avec du xlink et xpointer si l’on veut rester dans le monde XML)

Il suffit d’utiliser de l’API de Google Map pour monter l’application. Mais cela sera pour le prochain billet…

Stéphane.

PS : Le format KML est relativement simple, mais un ouvrage de référence en français manque (à moins qu’il soit sous presse).

 

Encoder en EAD, EAC et METS avec Daofind/Midosa sous Eclipse 3.2

Bonsoir,
Je travaille depuis quelques semaines avec Midosa editor for XML standards issu du Daofind project. Il s’agit d’un environnement de travail EAD/EAC/METS sous Eclipse 3.2. Développé par les Bundesarchiv (Berlin), Midosa/Daofind permet l’encodage XML avec validation des tags et niveaux en temps réel via le schéma EAD ou METS. Si la prise en main est plus complexe que XMLmind+ATES (mais qui ne fonctionne qu’avec la DTD EAD de 2002), le dico des éléments EAD est très pratique et particulièrement fonctionnel. Ainsi il devient assez simple d’encoder en EAD/EAC et de faire du METS par la suite. Midosa/Daofind est un outil intéressant pour les services d’archives et les personnes souhaitant se lancer dans l’EAD/EAC et la gestion des fichiers METS, avec le guide EAD sous le bras tout de même.
Cerise sur le gâteau, l’export HTML, véritable « impression numérique », transforme un fichier EAD en un instrument de recherche à la mode PLEADE.

METS-ment votre,
Stéphane.

SDX, pleade, EAD, et voila !

Bonjour,
La prochaine ouverture de la nouvelle plateforme de publication d’instruments de recherche en XML EAD du Centre National pour la Numérisation de Sources Visuelle est très proche (dans les jours qui viennent). Utilisant SDX et Pleade, elle permet de publier des inventaires archivisitiques encodés en XML-EAD. Les inventaires déjà réalisés par le CN2SV y sont versés. Pour nous, elle fait partie du bloc « Accès » du modèle OAIS. Mais pour le moment, en avant première, une petite vidéo de démonstration postée sur YouTube. bon, ok, l’image n’est pas très nette, mais cela donne tout de même une idée.

A très bientôt, Stéphane.

EAD, EAC, METS à Berlin

Bonjour,
Pendant 3 jours, la communauté des archivistes s’est réunie à Berlin pour faire le point sur les possibilités et les évolutions des grammaires XML EAD, EAC, et METS. Les présentations furent toutes d’un très haut niveau et elle ont prouvé que les méthodes de communication des archives par voie numérique utilisent de plus en plus le XML. Dans plusieurs cas, elles se rapprochent du modèle OAIS en ce qui touche l’organisation et la gestion des archives numérisées. Le milieu des archivistes a bien compris comment tirer profit de ces DTD et autres schémas. Le projet allemand DAOFIND illustre parfaitement cela. Ce logiciel (qui est un module d’Eclipse) permet de travailler très facilement ces fichiers EAD et METS. Il n’est pas le seul exemple en Europe : Italiens, Français, Espagnols ont aussi de nombreux outils très bien conçus. De plus en plus, la chaîne « tout » EAD voit le jour : inventaires, catalogues, numérisation, encodage se font de façon synchronisée et en simultané ce qui permet d’accélérer la diffusion des archives aux publics.

3eme conférence sur l'EAD, l'EAC et METS - Berlin

Stéphane.

Les mains dans Tomcat, Cocoon, SDX, etc.

Bonsoir,
Il est des jours qui sont trop courts… Je suis depuis deux jours dans l’installation d’un serveur pour le pôle HSTL et le CN2SV sous Apache/Tomcat6 faisant tourner en parallèle SDX, Cocoon, METS Navigator. Sous Tomcat 6.0.10 et JVM 1.5 ces briques semblent bien tenir la route. Cependant, chez moi, Cocoon n’est pas encore très stable, mais cela viendra (désolé Got).
L’idée principale est de proposer une plate-forme applicative simple, offrant à nos producteurs la consultation d’AIP stockés soit en EAD soit en METS (voir MODS que j’expérimente en diffusion via un outil OAI-PMH, mais là c’est une autre histoire, et c’est très neuf). Je suis encore septique sur la pérennité à long terme des frameworks java tant l’empilement des couches (ou briques) technologiques semble fragile. Je compare cela à une application « classique » MySQL+PHP tournant sous LA »mp ». L’avenir nous le dira…
Stéphane.

MathML et reconnaissance optique de formules mathématiques

Bonjour,
Après une semaine passée à installer le DataCenter du pôle HSTL de mon labo, J’ai travaillé hier sur l’OCéRisation de formules de mathématiques. Après un peu de veille, j’ai vu que cela n’était pas très facile et que les logiciels commerciaux classiques ne le permettait pas.

J’ai cependant trouvé une suite d’outil : Infty Project for Mathematical Document Recognition and Analysis, User Interface,Accessibility of Scientific Documents. Il s’agit d’une suite d’outils créé par Masakazu Suzuki (Kyushu University, Japon). J’ai testé InftyEditor et à première vue c’est très puissant. Cependant le module d’acquisition depuis un scanner ne fonctionne pas sur mon poste (j’ai pourtant un très bon scanner). Il faut donc scanner les documents indépendement du proscessus d’ORC. Autre limite, les formats possibles en entrée de chaîne : seul le TIFF binaire non compressé est possible. C’est un peu dommage car il semble que d’autres formats soient acceptés (PNG, JPEG, GIF), mais il s’agit peut-être un problème local venant de mes images.

L’intérêt principal reste la puissance de l’ORC et les formats de sortie : XML pour InftyEditor, LaTeX, MathML, PDF, etc. Mais le GROS problème c’est que les accents français ne sont pas gérés. C’est bien dommage. Mais c’est un outil à suivre…

Stéphane.

METS Navigator : une application web robuste pour la diffusion de documents structurés en METS

Bonjour,

Je profite de quelques jours de vacances à la montagne pour tester – entre deux journées de ski – quelques outils d’exploitation de fichiers xml.

Le problème majeur avec les technologies utilisant xml reste l’exploitation réelle en production des documents. Le passage à la production reste complexe. La mise en ligne d’un document xml nécessite l’emploi d’une feuille de style xsl si l’on veut rendre compréhensible par tous les données contenus dans le dit document. Au plus simple, l’action d’interprétation (le parsage) du xml suivant la feuille de style sera laissée au navigateur web du client avec des différences notoires entre les résultats. Il existe des applications web (programmes informatiques exécutables au travers de serveurs web) qui permettent de traiter cette tache du coté du serveur et donc de rendre homogène le résultat à l’écran et surtout de réduire le temps de parsage pour peut que l’on ait un serveur puissant.

Le service informatique de la bibliothèque numérique de l’Université d’Indiana et la Bibliothèque Lilly de cette même Université viennent de mettre au point l’une de ces applications : METS Navigator. Comme son nom l’indique, cette application permet d’exploiter une collection de fichiers xml respectant le schéma METS. METSNav est une application web fonctionnant sous Tomcat d’apache et Java et dont l’installation est facilitée par la mise à disposition par l’équipe de l’UI d’une archive war permettant un déploiement rapide.

Dans la documentation de METS Nav, l’introduction résume bien le produit :

« METS Navigator is an open source METS-based system for displaying and navigating sets of page images or other multi-part digital objects. METS, the Metadata Encoding and Transmission Standard, is a freely available XML standard, maintained by the Library of Congress, for managing and describing digital library objects. Using the information in the METS elements, METS Navigator builds a hierarchical menu that allows users to navigate to specific sections of a document, such as title page, specific chapters, illustrations, etc. METS Navigator also allows simple navigation to the next, previous, first, and last page image or component part of a digital object. METS Navigator also makes use of the descriptive metadata in the METS document to populate the interface with basic descriptive information about the digital object. METS Navigator is built using Java and open source Web technologies, including the Apache Struts Web Application Framework, the Castor Java & XML Data Binding libraries, and Ant, and runs under a Web application server such as Apache Tomcat. METS Navigator was developed by the Indiana University Digital Library Program. »

Cette application sépare bien la partie programme, les interfaces et la partie « stockage » des fichiers xml qu’il est tout à fait possible de virtualiser à minimal sur une autre machine locale ou dans le même réseau (elle ne va pas aussi loin en matière de virtualisation que l’application créé par le Centre de Ressouces NumériquesTelma) mais elle ressemble sur ce plan là, à l’application EXE que nous avons développé avec l’équipe du Centre National pour la Numérisation de Sources Visuelles pour l’exploitation des fichiers xml normalisés en EAD. Il est également très facile de faire sienne cette application, c’est à dire de la mettre en production dans un environnement informatique même restreins : petits services de documentation, de bibliothèques de laboratoires ayant des archives scientifiques, ou même encore services d’archives. « METS Nav. » fonctionne aussi bien avec une architecture Linux ou Windows (avantage du moteur de servlets Tomcat) et semble être très stable. Il y a cependant quelques restrictions au niveau des noeux METS, mais la documentation proposée est très complète.

En conclusion, cette application web me semble très prometteuse pour l’avenir car elle offre un cadre puissant, clair, dans le respect des standards et sous licence propre mais open source. J’ai contacté Mme Michelle Dalmau (une des auteurs de METS Navigator) qui m’a confirmé l’amélioration de l’application dans un futur proche.

Nous le voyons bien, les applications web permettant l’exploitation – en production (voir l’exemple de telma ou du cn2sv) – d’entrepôts xml (stockage distribué ou centralisé, xml natifs ou extractions) donne enfin une nouvelle dimension à la mise à disposition de documents sur le web.

Stéphane.

Ressources : METS Navigator – http://metsnavigator.sourceforge.net/

MathML

Bonjour,
Mes activités sont très « 2.0 » (et complexes) en ce moment : je suis pris entre le temps de rédaction du bilan d’activité du CN2SV et par la mise en place d’entrepôt OAI pour le CRHST mais aussi, par la vie des plateformes web du pôle HSTL, je n’ai plus une minute pour ce blog depuis 8 jours. De plus, les deux derniers billets sortent un peu du thème original de se blog (racontrer, au jour le jour, les aventures d’un ingénieur d’études qui fait du web depuis 1995). Je reviens vers le coeur du métier avec un court (trop court) billet sur une grammaire XML que j’utilise pour la publication de sources comportant des formules mathématiques : le MathML.

1) Le MathML 2.0 : Qu’est-ce ?

Il s’agit langage dérivé du XML permettant d’afficher et d’assurer le traitement de formules de mathématique sur le web. Depuis le 21 février 2001, MathML est devenu une recommandation du W3C.

2) Comment lire le MathML ?

L’un des stagiaires passé au CRHST en 2005 a résumé les solutions de lecture dans une page très bien faite. J’en reprends ici les points principaux.

Certaines pages de ce site requièrent l’affichage d’expressions scientifiques (équations, fractions, symboles mathématiques…).
Utiliser à cet effet des images montre des limites : elles ne sont pas forcément bien dimensionnées ni bien ajustées par rapport au texte. De plus, cela est très lourd à gérer de devoir insérer une image dès la moindre fraction.
La solution est d’utiliser le langage MathML, langage dérivé du XML et recommandé par le W3C. Les navigateurs compatibles devraient comprendre ce langage. Pour Internet Explorer, des plug-in existent (un plug-in est un programme qui apporte de nouvelles fonctionnalités à un logiciel existant).
Le tableau ci-dessous présente la compatibilité des navigateurs les plus utilisés.

  Internet Explorer Netscape Navigator Mozilla / Firefox Opéra Safari Amaya
Windows 5.0 & Techexplorer
5.5 & MathPlayer | Techexplorer
6.0 & MathPlayer | Techexplorer
6.1 & Techexplorer
7.0 ou +
0.9.9 ou + / toute version 7.2 NON pas de support Voir ci-
dessous
Mac OS 5.0 & Techexplorer 6.1 & Techexplorer
7.1 ou +
0.9.9 ou + / toute version 7.2 NON NON
Linux pas de support 6.1 & Techexplorer
7.0 ou +
0.9.9 ou + / toute version 6.0 NON pas de support

Quelques précisions :
1. MathPlayer compense utilement la défaillance d’Internet Explorer ; il est diffusé gratuitement par Design Science.
2. Techexplorer est un plug-in qui s’ajoute à la plupart des navigateurs, sur Windows, Mac et Linux ; anciennement développé par IBM, il est désormais distribué gratuitement par Integre pour un usage personnel. Voir ici pour plus d’informations.
3. Amaya est l’éditeur et navigateur Web officiel du W3C qui permet d’éditer très simplement des pages contenant du texte, des graphiques et des expressions mathématiques (en MathML). Il est disponible pour Windows 98, NT/2000/XP, Unix, Linux et MacOSX. Pour plus d’informations, aller sur le site officiel d’Amaya ou sur une page en français.

Concernant Internet Explorer,vous pouvez télécharger MathPlayer pour Windows.
Bien que nous ne vous le recommandions vraiment pas (risques d’erreurs à l’affichage du MathML), vous pouvez aussi télécharger Techexplorer pour Windows, ou Techexplorer pour Mac OS 8.6 à 9.2 et Mac OS X. Mais découvrir Mozilla demeure encore la meilleure solution !

Polices scientifiques pour Mozilla/Netscape

Afin que les navigateurs compatibles MathML affichent correctement les expressions mathématiques, vous devez éventuellement installer sur votre poste quelques polices de caractères scientifiques.
N.B : Si vous utilisez Internet Explorer avec MathPlayer sous Windows, l’installation de polices supplémentaires n’est pas nécessaire.

Pour plus de détails, voir la page dédiée aux polices pour MathML sur le site de Mozilla.

3) Ca ressemble à quoi ?

Je viens de terminer la relecture de la théorie mathématique d’André-Marie Ampère qui est encodée en MathML et en ligne sur le site @.ampère.

Joyeuses fêtes de fin d’année !

Stéphane.

METS, PREMIS dans des cases

Bonjour,
Got des Petites Cases propose un très bon articles dans son blog sur METS, PREMIS et nos fameux SIP dictés par l’OAIS : j’en profite pour signaler l’atelier technologique du CN2SV (dont je suis le chargé de mission pour le CNRS) qui se tient à Fréjus (Villa Clythia du CAES) à partir de demain (le 16 oct. 2006) et pour trois jours. Nous allons discuté autour de l’EAD, METS, XMP, Archives de scientifiques accessibles via le web (sémantique forcément), etc.
Je file donc à la gare de Lyon…
Stéphane.

Archiver de bases de données factuelles des scientifiques

Bonsoir, L’idée de l’archivage des données des scientifiques du passé et des chercheurs actuels fait son chemin dans les bureaux du CRHST et au sein de l’équipe du CN2SV. Il va nous falloir transmettre aux générations futures les données et leurs clés d’accès. Aujourd’hui la démocratisation du couple MySQL-PHP dans un environnement LAMP permet la création par beaucoup de chercheurs de mini bases de données factuelles. Elles sont très souvant au coeur des processus de recherche. Ils est important d’archiver ces bases en tenant compte de l’environnement technique. Cet archivage doit intégrer à la fois :

  • les données (sous la forme la plus simple possible : un fichier texte contenant toutes les données « purifiées » de l’environnement de gestion : un .xml ou un .txt tabulé)
  • les interfaces développés (PHP, Perl, Python, etc.) sous la forme d’une archive .zip, .tar ou .tgz
  • la modélisation et les commandes SQL (CREATE + INSERT) sous la forme d’un .xml ou .sql

Une initiative du CCSD du CNRS va dans ce sens : l’archive CIEL.

Les principales motivations de ce projet sont :
– “Promouvoir et valoriser les codes de calcul” c’est-à-dire mieux faire connaître les codes de recherche développés dans les laboratoires de recherche et permettre une reconnais- sance aux développeurs de ces codes de la même fa¸con qu’un article dans une revue avec comité de lecture.
– “Pérenniser les codes de calcul” pour parer au problème de la perte de savoir-faire due au départ d’un thésard ou d’un chercheur. C’est également l’un des moyens pour faire connaître l’existence de ce patrimoine scientifique dans notre communauté mais aussi dans le milieu industriel.
– “Assurer la reproductibilité des résultats de publication” pour permettre aux person- nes intéressées par les articles de disposer d’un outil mettant en oeuvre les méthodes proposés et permettant de reproduire les résultats décrits dans l’article. Ainsi, la publication d’un code qui a servi à produire les illustrations d’un papier de sci- ences appliqués accepté dans un journal “classique” va d’une part permettre de “reproduire” les résultats publiés, mais aussi de l’utiliser pour d’autres applications comme n’importe quel résultat théorique issu d’une publication. Par ailleurs, les personnes qui développent des codes de calcul en dehors d’un contexte de publication peuvent trouver ici un outil pour faire con- naitre leurs travaux et valoriser ceux-ci.

Il serait intéressant de concevoir structure d’archivage et de stockage de ces bases de données. Si vous souhaiter participer à ce projet n’hésitez pas à me contacter.

XMP {suite}

La mise en ligne de documents numérique entraîne, outre la question des droits, toutes une série de questions techniques qui sont la plupart du temps le parent pauvre des projets de numérisation et de mise à disposition. Le format IPTC et aujourd’hui le framework XMP permettent, par exemple, d’ajouter des méta-données dans l’image (XMP – eXtensible Metadata Platform – repose sur une version simple de RDF). C’est à dire que les méta-données sont « encapsulées ». Encapsuler…Encapsuler : voici un terme technique qui paraît simple mais qui peut avoir des conséquences sur la pérennité des méta-informations. Le Grand ROBERT de la langue française nous dit :

Encapsuler [ãkapsyle] v.tr. – 1889, Renan, au fig. ; de en-, et capsule. Techn. Enfermer dans un capsule […].

Le fait « d’enfermer » doit attirer l’attention du fournisseur de ressources visuelles (photographiques dans notre exemple) sur la possibilité de « libérer » les méta-données ainsi encapsulés. C’est à dire de pouvoir dans le futur les lire, les exploiter en même temps que l’image, sans avoir de contraintes.
Il est important de ne s’appuyer que sur normes libres (si possible, attention XMP est fortement lié à Adobe Inc. alors que l’IPTC Core est développé par International Press and Telecommunications Council (1965) et succède à l’IPTC « classique »), internationnales et reconnues par les professionels de l’information (iconographes, documentalistes, etc).
Avec un outil simple, tel que PixVue (voir ci-dessus), il est facile à l’aide de la souris et du clavier d’ajouter des « méta » dans une image suivant la norme IPTC.

Bonne fin de semaine,

Stéphane.

Schéma XMP / IPTC parseur

Bonsoir,

Dans le développement du CN2SV, j’ai programmé un parser XMP, IPTC à partir de la librairie « PHP JPEG Metadata Toolkit » de E. Hunter. Le schéma XMP est prometteur même s’il est lié à Adobe. Mais la programmation d’un programme en php lisant les méta-données IPTC est facile et la technologie est mure aujourd’hui. L’IPTC a adopté XMP comme schéma de la toute dernière version de son standard de description des photographies : IPTC Core (http://www.iptc.org/IPTC4XMP/). Avec l’utilisation massive des appareils photos numériques, qui truffent leurs images de méta-données, il est temps d’offrir aux utilisateurs d’intergiciel (middlewares) en php, jsp, java, asp, la possibilité de lire ces données et de les enrichir.

Un simple parseur IPTC en PHP (PHP 3 >= 3.0.6, PHP 4, PHP 5) :

 function output_iptc_data( $image_path ) { 
   $size = getimagesize ( $image_path, $info);      
    if(is_array($info)) {        
     $iptc = iptcparse($info["APP13"]);        
     foreach (array_keys($iptc) as $s) {            
     $c = count ($iptc[$s]);            
      for ($i=0; $i <$c; $i++) {            
       echo $s.' = '.$iptc[$s][$i].' - ';           
      }        
     }    
    } 
  }

(source : site www.php.net)

Nous allons intégrer un lecteur/editeur IPTC/XMP à Iceberg. Je tiens d’ailleurs à remercier Romain et Frédéric, les deux développeurs contractuels du CN2SV qui font un travail formidable.

A bientôt,
Stéphane.

« IPTC Core » est la propriété intellectuelle de IPTC. XMP, Photoshop and Creative Suite (CS) sont des marques commerciales de la société Adobe Systems Inc.