php – Archives du blog de Stéphane Pouyllau

ChronoSIDORE : explorons les données d’ISIDORE avec SPARQL #2

ChronoSIDORE n’est pas le nom d’une nouvelle espèce de dinosaures, c’est le nom d’une application web qui utilise les ressources d’Isidore. ChronoSIDORE est donc un petit « mashup » que j’ai programmé pendant mes congés d’été. L’idée est double, poursuivre l’exploration concrète des possibilités d’un outil comme Isidore et donner des idées à d’autres personnes, en particulier dans le monde des bibliothèques et de la documentation, pour développer d’autres mashups s’appuyant soit sur l’API d’Isidore soit sur son SPARQL endpoint.

Que propose-t-il ?

ChronoSIDORE, accessible sur www.stephanepouyllau.org/labs/isidore/chronosidore, propose une autre façon de « voir » les ressources d’Isidore ; différente des vues traditionnelles en « pages de résultats » comme cela est le cas dans les bases de données bibliographiques ou catalogues. Ce mashup propose une vision des ressources en « tableau de bord » : il s’agit de projeter sur une frise chronologique un ensemble de ressources issues d’une ou de plusieurs requêtes SPARQL. Ainsi, une vision plus globale est proposée permettant une représentation différente de la répartition des ressources : dans notre cas, une mise en lumière de l’évolution disciplinaire des ressources fondée sur la catégorisation automatique effectuée par Isidore. ChronoSIDORE offre la possibilité de « voir » l’évolution chronologique des tendances disciplinaires pour un ensemble fini de ressources documentaires définit dans Isidore ou « source » : il peut s’agir des publications d’un laboratoire (à la condition qu’il possède une collection dans HALSHS), des articles d’une revue, des notices d’une base de données, des billets d’un carnet de recherche (voir la liste des sources dans l’annuaire d’Isidore). ChronoSIDORE propose deux types de requêtes SPARQL : l’une est orientée « sources » la seconde est orienté « auteurs » (permettant de projeter sur la frise les ressources d’un auteur). ChronoIsidore est un exemple de mashup possible, bien d’autres mashup sont possibles (autour des langues, des types de documents…).

Comment fonctionne-t-il ?

N’étant pas un développeur professionnel, j’ai fais avec mes connaissances en PHP, Xpath, SPARQL et Javascript pour développer. J’en profite pour remercier ici mes collègues Laurent Capelli, Shadia Kilouchi et Jean-Luc Minel qui m’ont aidé, en particulier sur SPARQL. Ainsi, je pense qu’une équipe de développeurs professionnels ferait beaucoup mieux, mais j’ai pensé aussi qu’il serait bien de montrer que l’ancien étudiant en histoire et archéologie du Moyen Age que je suis est capable d’exploiter avec un peu de PHP, les gisements de données enrichies proposés par Isidore, en espérant que cela donnera des idées à d’autres. J’en profite pour ré-affirmer ici le rôle et l’importance des ingénieurs en digital humanities dont les métiers sont multiples et qui interviennent à différents niveaux de technicité : Il faut des très grands spécialistes, érudits mais aussi des intermédiaires qui vont chercher la compétence à l’extérieur et l’adapte aux besoins SHS . On fait souvent le reproche aux ingénieurs du CNRS, surtout en digital humanities, de ré-inventer l’eau chaude, mais je pense qu’ils développent des outils, des méthodes qui sont adaptés à des publics présentant une multitude de rapports au numérique et différents niveaux d’appropriation et c’est très important. Il faut parfois avoir un outil imparfait, ou un démonstrateur fonctionnel pour offrir un service qui permettra à certains de profiter d’outils communs, fondés sur des standards ouverts et bien documentés et de « sauter le pas », ensuite on peut toujours améliorer les fonctionnalités. Je préfère cela à deux extrêmes : passer cinq ans à faire un outil qui ne fonctionnera jamais et qui sera dépassé avant de sortir (car nous n’avons que trop rarement les moyens de faire vite et bien) et dire qu’au prétexte que cela existe en ligne, il ne faut rien, s’en contenter, faire avec, et ne rien tenter car on n’égalera jamais les autres. Il s’agit parfois de faire juste « un pas de plus » pour ouvrir des données aux autres et savoir que ce « pas » est maitrisé, accompagné par des collègues du monde académique peut être plus sécurisant que de plonger de suite dans jungle des outils en lignes et des « consultants » (même si, comme je l’ai dit, cela peut être nécessaire). J’aime bien l’idée que ChronoSIDORE donnera peut-être des idées à d’autres, nous en reparlerons au THATCamp Paris 2012 en septembre.

ChonoSIDORE réalise en fait plusieurs tâches :

Il interroge le triple store RDF d’Isidore : il s’agit d’une base de données RDF qui contient l’ensemble des informations d’Isidore formalisées en RDF et proposées selon les principes du linked data.
Il utilise pour cela le langage normalisé et international SPARQL (W3C) qui permet d’interroger les triplets RDF.
Il assemble les informations reçues du triple store sous la forme d’un flux de réponse Xml lisible avec l’application timeline créé dans le cadre du projet Simile du MIT (plutôt que refaire un système propre, j’ai préféré utiliser cet outil, même si je le trouve quelque peu rigide, il existe aussi d’autres systèmes : par exemple Timeline JS mais quelque peu différent).

Quelques limites

Il s’agit d’une version bêta, en fait un démonstrateur, donc il présente des limites. Deux sont à signaler :

Isidore catégorise automatiquement via un corpus de référence (HALSHS) et à l’aide de signatures sémantiques : cela peut donc générer des erreurs de catégorisation. Pour aller plus loin, voir les principes de catégorisation dans Isidore avec la vidéo de présentation des systèmes d’Isidore par Fabrice Lacroix, président d’Antidot, lors de l’université d’hiver du TGE Adonis à Valpré en décembre 2010 (ouverture d’Isidore).

Isidore ne catégorise pas toute les ressources qu’il moissonne : cela dépend de la richesse sémantique des métadonnées : plus les métadonnées moissonnée seront riches (description, résumé, mots-clés) plus la catégorisation proposée par Isidore sera pertinente et donc utilisable dans ChronoSIDORE. Donc toutes les ressources ne « montent » pas dans la frise chronologie.

Je vous invite donc à utiliser ChronoSIDORE, à le tester, à le faire « craquer » et si vous le souhaitez vous pouvez laisser un commentaire, des idées, des critiques…

Stéphane.

Tout ce qu’il reste à faire…

Le développement de l’archive ouverte MédiHAL fut court, 3 mois en tout et avec une toute petite équipe (3 personnes). Même si nous avons largement utilisé le framework HAL, il reste plein de choses à faire, à améliorer, à reprendre, à redessiner et à écouter les chercheurs, documentalistes et bibliothécaires qui déjà par dizaines nous ont écrit pour nous encourager, nous demander conseil avant de se lancer. Ils nous ont aussi dit que MédiHAL est une bonne chose à l’heure des départs massifs en retraite dans le monde de la recherche. Certains nous ont demandé des choses précises, d’autre nous ont signalé des bugs, etc.
Je suis très heureux de voir que des développeurs nous ont demandé l’accès à l’api de HAL pour développer des widgets de chargement de masse et de visualisation. Au cours des prochains mois, MédiHAL trouvera petit à petit son rythme et je tiens à remercier toutes les personnes qui nous ont contactées. Elles ont exprimé leurs critiques, positives ou négatives, et leurs doutes et/ou un soutien. Certains déposeront dans quelques semaines ou quelques mois, ils sont les bienvenues.

Bon dimanche.

Stéphane.

Frises chronologiques sur le web : utilisation de Timeline pour faire un mashup AJAX avec PHP et MySQL

Bonsoir,

Je profite d’un week-end loin de Paris et d’un long voyage en train pour décrire (mais avec beaucoup de retard) un petit mashup que j’ai réalisé pour le site @.ampère et l’histoire de l’électricité. L’idée de départ était de développer des chronologies avec l’outil Timeline mis au point par le MIT et que pas mal de développeurs connaissent et utilisent. Timeline permet de créer des frises chronologiques à l’image de celles encore présentes dans les livres scolaires d’histoire (nous avons tous rêvés devant ces frises en couleurs présentant l’histoire de l’Homme par exemple). C’est outil utilise des éléments en javascript et du XML : c’est donc un système basé sur AJAX. Dans le site @.ampère nous voulions faire une frise avec des éléments historiques différents le tout devant être synchronisé :

une sous-frise sur les grands personnages de l’histoire de l’électricité
une sous-frise sur les grandes découvertes de ce même domaine

Dans Timeline, les évènements (events) sont stockés dans un fichier XML très simple. Dans le but d’inclure Timeline dans le système d’information (SI) du site, nous avons utilisé deux tables MySQL pour mettre les données brutes (date, contenu de l’évènement, etc.). Un script PHP utilisant DOM réalise alors une présentation XML de ces données : en sortie, nous avons deux fichiers XML, un pour chaque sous-frise, qui sont normés suivant le schéma des fichier nécessaire au fonctionnement de Timeline. Nos deux tables MySQL sont indépendantes du système AJAX de Timeline : c’est PHP/DOM qui formate les données en XML suivant la grammaire Timeline. Nous avons d’ailleurs un autre programme PHP qui présente ces même données sous la forme d’une page web classique. Le schéma suivant en résume le modèle :

Les deux fichiers XML sont stockés dans un répertoire du serveur et chargé dans l’application AJAX qui gère Timeline. Le XML resemble à ceci :

<?xml version="1.0" encoding="iso-8859-1"?><data>

<event start="Jan 00 1544 00:00:00 GMT" end="Jan 00 1603 00:00:00 GMT"

image="AMP_1015.jpg" isDuration="true" title="William GILBERT">(1544-1603)</event><event start="Jan 00 1666 00:00:00 GMT" end="Jan 00 1736 00:00:00 GMT"

isDuration="true" title="Stephen GRAY">(1666-1736)</event> ...

</data>

Pour le tout fonctionne, il nous a fallu ajouter un petit programme php de vérification de la forme des dates/heures histoire de ne pas avoir de bug dans l’une des deux sous-frises. Pour terminer nous avons ajouté, dans le fichier javascript de la frise (main.js) qui pilote l’affichage écran, les instructions suivantes :

bandInfos[1].eventPainter.setLayout(bandInfos[1].eventPainter.getLayout());

tl = Timeline.create(document.getElementById("my-timeline"), bandInfos, Timeline.HORIZONTAL);

Timeline.loadXML("kronos1.xml", function(xml, url) { eventSourceA.loadXML(xml, url); });

Timeline.loadXML("kronos2.xml", function(xml, url) { eventSourceB.loadXML(xml, url); });

Nous avons une « bandInfos » dans laquelle nous « chargeons » les deux fichier XML : kronos1.xml et kronos2.xml. Ce chargement est réalisé au sein des deux eventSource (A et B). Ce fichier, main.js, qui est un fichier javascript pur est chargé dans une page HTML (ou PHP dans notre cas) par l’utilisation d’une simple balise <script> dans l’entête. La frise « double » est ensuite affiché dans le code HTML via un « id » de balise <div> :

<div id="my-timeline" style="height:800px; width:100%;"></div>

Le tour est joué, nous avons une belle frise chronologique présentant de façon synoptique ces deux types d’évènements. Voici le résultat :

Bonne fin de week-end,

Stéphane.

PS : Merci à Marie-Hélène Wronecki pour le travail sur la base de données MySQL.

Trancodage de dates informatiques

Bonsoir,

Un petit script php très simple pour convertir une date du type AAAA-MM-JJ HH:MM:SS en date normée suivant RFC 822 utilisée dans les flux RSS ou dans le monde OAI-PMH :

$datedepart = '2007-09-10 00:00:00'; // on entre la date (qui peut venir d'un champ de type datetime de SGBDR : MySQL, PostgreSQL, etc.)

list($date, $hours) = split(' ', $datedepart);
list($year,$month,$day) = split('-',$date);
list($hour,$min,$sec) = split(':',$hours);

$date = date(r,mktime($hour, $min, $sec, $month, $day, $year));
print "$date";

Stéphane.

Source : http://www.phpfreaks.com/quickcode/from-MySQL-datetime-to-RFC-822-for-RSS/597.php

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 :

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

Zend Framework : un nouveau site pour la communauté française des utilisateurs.

Bonjour,
De retour de vacances, je mets au propre quelques notes informatiques glanées tout au long de l’été. Utilisateur du Zend Framework depuis quelques semaines (pour une application en test pour le moment), j’ai découvert dernièrement que la communauté française des utilisateurs du Zend Framework s’organisait autour d’un nouveau site web, très bien fait et plein d’informations. Un très bon forum, très professionnel, permet de poser des questions simples ou complexes suivant son niveau de pratique du Zend Framework.
Le Zend Framework (ZF) est un projet PHP créé par la société Zend, grande prêtresse du langage PHP dans le monde. Le ZF est un ensemble de librairies permettant d’accélérer le développement d’applications PHP professionnel. Il permet aux entreprises d’appuyer leurs outils sur une infrastructure robuste orienté MVC (modèle, vue, contrôleur). En terme de sécurité, l’utilisation du ZF entraine des gains importants, notamment au niveau des injections SQL. Comme tous les frameworks, ZF n’est cependant pas très simple au début, il faut bien comprendre le système MVC avant tout.
Mais un signe ne trompe pas, la communauté ZF augmente et en mai 2007, l’association française des utilisateurs de PHP, a organisé une présentation ZF dont la vidéo (amateur ?) est en ligne sur http://php.developpez.tv. Certaines applications « grand public » utilisent ZF et un premier CMS vient de voir le jour : http://zfcms.tebe.ch (démonstration de l’outil de gestion : http://zfcms.tebe.ch/admin/ avec identifiant/mot de passe : admin/admin).
ZF est un framework à suivre dans l’environnement PHP.

Stéphane.
PS : un tutoriel plutôt bien fait existe sur le site : developpez.com

Un moteur de recherche de codes source ?

Bonjour,
Le moteur de recherche Krugle annonce pour septembre 2007 une version entreprise de son moteur de recherche. Il s’agit donc d’un moteur de recherche qui indexe le contenu des codes sources déposés dans un forum ou dans des pages web (il y en aurait 20 millions de fichiers de code source sur le web selon Krugle, source : 01net). Il existe aussi Google Code Search (version en français) issu du « Labs » Californien de Google. Encore en développement il pourrait s’agir d’une sources non négligeable pour les développeurs. Si l’on veut recherche des bouts de code sur la commande addslashes en PHP, il suffit de taper lang:php addslashes. Dans les résultats de recherche, le type de licence du source trouvé est indiqué (GPL, LGPL, BSD, etc.). A vos codes…et bonne fin de semaine. Stéphane.

Un peu de javascript

Bonjour,
Il est important, parfois, de revenir à la programmation directe : dans le « coeur du code » (utilisez Zend, PDO…, c’est super mais bon l’assemblage au bout d’un moment…). Au cours d’un développement ou plutôt d’un patchage d’ICEberg, j’ai du surmonter le problème du document.getSelection(); en javascript qui ne fonctionne qu’avec les navigateurs Mozilliesque (Firefox, Netscape, Mozilla). document.getSelection(); n’est donc pas compatible avec IE. Je suis dans une application en PHP et j’ai besoin du document.getSelection(); pour transmettre via des variables une selection de texte éffectuée par l’internaute sur la page consultée pour l’injecter ensuite dans un formulaire. Si IE n’existait pas, nous pourrions nous contenter de :

location.href='formAK.php/user?action=add& description='+encodeURIComponent(document.getSelection())+';

Seulement voilà, il y a IE et document.getSelection(); renvoit une belle erreur javascript. Mais il y a une petite solution très simple qui permet de rendre cette action compatible quelque soit votre navigateur préféré (sous MacOS X, cela fonctionne aussi). Plutôt que de détecter le navigateur (son nom via : navigator.appName), il plus intéressant de détecter la méthode (ou l’objet) dont le fonctionement avec les navigateurs n’est pas possible (ou mal gérée). Ainsi, avec un système conditionnel classique et une nouvelle variable « methodeselection » :

if (document.getSelection) methodeselection = document.getSelection(); else if (document.selection) methodeselection = document.selection.createRange().text; else return;

Préparé pour une page web, nous pouvons écrire :

function envoyer_une_selection_quelquepart() { if (document.getSelection) sel = document.getSelection(); else if (document.selection) sel = document.selection.createRange().text; else return; location.href='http://www.monsite.fr/?action=ajouteramonforumulaire& description='+encodeURIComponent(sel)+'; }

Bonne fin de semaine,
Stéphane.

Utilisation massive de la librairie GD pour PHP : les lettres de Stephen Gray dans le site @.ampere

Bonjour,
Dans le site @.ampere (direction ; C. Blondel, CNRS) dont je suis le webmaster, j’ai placé des lettres de Stephen Gray (voir dans Wikipedia), pour le zoom j’utilise la GD de PHP, cette librairie est connue mais elle rend bien des services quoiqu’un peu lente. Je l’utilise pour le zoom 100% 75% 50% 25% mais aussi dans le site du CN2SV pour le génération d’images « vignettes » à la volée. La GD a été intégré à PHP depuis la version 4.3 et commence à faire du JPEG2000. En complément, il y a surtout la fonction « iptcparse » qui permet de lire les méta-données IPTC et même de les mettre à jour avec « iptcembed ».
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.

Notes scientifiques électroniques. Comment anoter des textes électroniques sur le web. (volet technique n°1)

bonjour, Tout le monde développe son outil de publication en ligne (à base de CMS le plus souvant, d’XML plus rarement). La question des notes de bas de pages ou de fin de documents et récurente : tout les webmestres, développeurs IT, chefs de projet web se sont vu poser LA question : « Et pour mes notes ? je fais comment ? »

Dans le cadre de la boite à outils ICEberg, que j’ai développé pour le CNRS au CRHST, nous proposons maintenant des notes dans le texte intégral (pour les textes au format « mots ») sous la forme d’un sous-bloc de texte entouré de BBcode. S’il faut un jour nettoyer le texte numérique des notes c’est ainsi très facile (un petit programme Perl ou Php avec un ereg_replace et le tour est joué). Cette fonction est disponible dans la nouvelle version d’ICEberg. Elle est en court de test et sera présentée en janvier 2007 et déployée sur les sites fonctionnant déjà sous la version 3.0 BD et 1.5 XML (qui changera de nom pour l’occasion afin d’unifier les outils et les versions).

Il s’agit de faire très simple une fois encore. J’ai vu tellement de système de notes complexe que finalement, nous nous sommes orienté sur le plus simple : du BBcode pour ne pas effrayer le chercheur/client, du parsage pour la numérotation automatique, des bullets pour la consultation et le tour est joué. Le tout dans le respect des standards du W3C.
Notement-votre,
Stéphane.

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