Étiquette : xml (Page 1 sur 3)

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

1er mai

Bonjour et bon 1er mai !

C’est le début des ponts : période plus calme qui permet d’explorer quelques nouvelles technologies et outils. Je teste depuis quelques jours PLEADE3, outil de publication d’inventaires d’archives encodés selon le schéma XML EAD. Si la version 3.0 comporte encore quelques lacunes et bugs gênants (problème autour des accents sous Tomcat, par exemple), les progrès par rapport à la v2.x sont majeurs : c’est un autre monde. Il est cependant dommage que pour un logiciel open source, les auteurs n’aient pas prévu une documentation digne de ce nom (pour ne pas favoriser la concurrence selon AJLSM qui produit PLEADE). Peut-être la communauté PLEADE produira elle-même une documentation « non-officelle » sous la forme d’un wiki par exemple.

Pour ceux qui recherche un outil multi-plateformes (Windows, Linux, Mac) permettant la mise en ligne d’inventaire EAD, je vous conseille vivement de tester PLEADE3.

bon 1er mai,

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).

 

Un article consacré aux bibliothèques numériques dans le domaine des mathématiques

Bonjour,
Je prépare un billet sur l’exploitation du format KML utilisé dans Google Earth et Maps. En attendant, je vous invite à lire l’article d’Alexandre Moatti (Blog Bibliothèque numérique) consacré aux bibliothèques numériques dans le domaine des mathématiques. Cet article, publié dans la revue Tangente (n° 117 de juillet-août 2007) , est disponible en pdf sur le blog de l’auteur. A bientôt pour (re)parler du KML, donc du XML.

Stéphane.

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.

Page 1 sur 3

Fièrement propulsé par WordPress & Thème par Anders Norén