Nous remercions vivement tous les participants de cette dernière édition 2024, qui ont participé aux discussions et présenté leurs travaux !

Cette édition 2024 a subi un léger lifting: nous avons modifié le format de la conférence en réduisant le nombre de présentations au profit de plus de temps pour les échanges pendant une session poster ouverte par des présentations éclairs (moins de 3 min pour présenter son sujet et donner au public l'envie d'en savoir plus).

Comme chaque année depuis 2020, Pierre-Antoine Champin est venu faire le bilan des avancées des différents groupes de travail de l'écosystème Data and Knowlegde du W3C.

Nous espérons que ce nouveau format vous aura plu !

Pour tous ceux qui n'ont pas pu être présent, vous retrouverez les supports des présentations et les vidéos SemWeb.Pro 2024 et sur PeerTube.SemWeb.Pro.

La prochaine édition de la conférence SemWeb.Pro, qui se tiendra en novembre 2025, est déjà en préparation. Si vous souhaitez recevoir les annonces, abonnez-vous à la liste de diffusion en envoyant un mail à contact at semweb.pro ou bien suivez le compte mastodon.logilab.fr/@semwebpro !

400 mots: ~3min

Après une décennie d'accompagnement de grandes institutions culturelles dans la gestion et la publication de leurs données, Logilab propose un parcours complet de formation pour découvrir et contribuer au Web des données (ou Web sémantique).

Le Web sémantique est l'ensemble des technologies et standards pour rendre des données accessibles sur la toile de manière décentralisée et les lier entre elles. Les données publiées de cette façon se complètent les unes les autres, comme les articles qui se référencent mutuellement sur le Web via des liens hypertexte. A l'instar du Web des documents où tout un chacun peut publier des pages Web et y placer des liens vers les pages déjà existantes, les standards du W3C pour le Web sémantique permettent de publier des données en y insérant des liens vers les autres données déjà existantes.

Une première formation permet de découvrir pas à pas les notions du Web des données, en allant de l'hypertexte du Web des documents jusqu'aux ontologies du Web Sémantique et en passant par le cycle de vie des données et les standards de publication et d'interrogation. L'objectif de la formation est de repartir avec des points de repères clairs sur le sujet.

Une deuxième formation est dispensée afin d'apprendre à contribuer au Web des données dans le respect des standards du W3C. Les principales techniques de description de ressources et de publication sont abordées sous un angle concret avec des exercices de mise en pratique. L'objectif étant d'apprendre à passer d'un ensemble de données CSV à un entrepôt SPARQL contenant des triplets RDF de ces données et de les interroger en SPARQL.

Une troisième formation complète le parcours en abordant la réalisation d'un projet mettant en place les techniques du Web des données. Le but est de fournir des principes servant de boussole pour garder le cap d'un projet de ce type et ne pas passer à côté des caractères différenciant qui font l'intérêt du Web Sémantique.

À l'issue de ces formations, qui ont déjà été suivies par plusieurs dizaines de personnes, les participantes et participants seront à même de proposer à l'institution ou l'entreprise qui les emploie une stratégie adaptée à ses objectifs de valorisation et de diffusion et de les mettre en œuvre en publiant des données sur le Web sémantique.

1500 mots: ~7min

Du 1er au 3 juin 2023 a eu lieu le colloque "Des archives aux données" au cours duquel deux jours de hackathon ont permis de s'interroger sur l'interopérabilité des données entre différentes institutions culturelles.

Les données présentées concernaient les représentations théâtrales de la Comédie Française (Base RCF), de la Comédie Italienne, du théâtre d'Amsterdam (Base On Stage) et du théâtre français des XVIIe et XVIIIe siècles (Base CESAR).

Ce fut l'occasion d'éprouver dans un contexte concret les avantages des technologies du Web Sémantique. Les requêtes fédérées ont en effet permis d'assembler et de manipuler des données publiées sans concertation préalable par les différents participants.

Tempête de cerveaux sur les besoins en interopérabilité

Lors de la première journée nous avons commencé par faire émerger des idées de traitements qui nécessitent une interopérabilité des données. Cette session a été très riche et il nous a fallu quelques efforts pour résumér les diverses idées et choisir vers quoi nous diriger.

Nos sources de données divergent principalement sur le périmètre étudié: les registres de la Comédie Française concernent une unique troupe, la base "ON_Stage" se focalise sur le théâtre d'Amsterdam et la base CESAR se limite à une période de temps.

La date des représentation théâtrales a été clairement identifiée comme centrale puisqu'elle permet de les aligner de manière non ambigüe. Chaque source de données décrit différemment les représentations, mais toutes ont renseigné la date.

Les lieux des représentations constituent un autre point de contact, pour autant que les périodes temporelles soient les mêmes.

Partant de ces deux constats, nous nous sommes demandé s'il serait possible d'afficher un graphique qui rendrait compte de l'évolution géographique d'une pièce dans une période de temps donnée.

Maquette d'une potentielle application

Dans la maquette ci-dessous, nous pouvons observer l'évolution dans le temps d'une pièce donnée. Au centre on voit l'enchaînement des villes où la pièce a été jouée. Une ville peut apparaître plusieurs fois si la pièce y a été rejouée après avoir tourné ailleurs. En bas figure la ligne de temps, qui est sous-divisée par année. A droite, on trouve un cadre avec des boutons qui permettent de choisir le mode de représentation.

Dans la première figure, la taille des cercles qui représentent les villes est liée au nombre de représentations.

Dans la deuxième figure, la taille des cercles qui représentent les villes est liée au revenu généré.

Dans la troisième figure, les données sont affichées sur une carte plutôt qu'avec un graphe.

Analyse des sources de données

Nous avons choisi de nous focaliser sur les sources déjà publiées dans des entrepôts SPARQL pour deux raisons. D'une part le hackathon était court, donc il fallait éviter de onsacrer du temps à des questions de lecture de formats de fichiers qui ne produiraient aucun résultat visible. D'autre part les gens autour de la table connaissaient déjà bien ces jeux de données.

Nous avons donc privilégié l'utilisation de ces trois sources de données: * Les registres de la Comédie Française / accès sparql * La base CESAR / accès sparql * La base ON-STAGE / accès sparql

Nous avons tout d'abord écrit des requêtes SPARQL fédérées afin de pouvoir joindre avec une seule requête des données de plusieurs bases.

Ce faisant, nous avons rencontré un premier problème technique, à savoir que l'entrepôt qui héberge les données de la Comédie Française n'était pas configuré pour accepter les requêtes fédérées. Nous avons donc essayé l'inverse, à savoir interroger l'entrepôt de la base CESAR, mais ce dernier repose sur Ontop, qui ne permet pas non plus les requêtes fédérées. Nous avons finalement utilisé l'entrepôt de la base ONSTAGE, déployé avec TriplyDB, pour exécuter une requête fédérée assemblant des données de RCF et CESAR... mais aucune de ONSTAGE. Ceci nous a rappelé que la fédération de requêtes, séduisante sur le papier, est parfois plus compliquée qu'il n'y paraît.

Alignement des modèles

Nous avons ensuite cherché quel modèle utiliser pour assembler les données obtenues avec ces requêtes.

La base CESAR décrit des "Séances", qui peuvent être définies comme des ensembles de représentations contigües. Cette notion peut être rapprochée de celle de "Journée" dans le modèle RCF, mais cet alignement n'est pas tout à fait exact puisqu'il est possible qu'il y ait plusieurs "Séances" à la même date, donc plusieurs "Séances" dans une "Journée". Les registres de la Comédie Française ne détiennent pas cette information de "Séance" spécifique et se contentent de considérer uniquement la "Journée".

Ces différences de modélisation sont monnaie courante et nous avons dû, sans surprise, définir un modèle intermédiaire adapté à notre objectif et des opérations de transformation des données pour les convertir de leur modèle d'origine vers ce modèle afin de les fusionner.

Nous avons retenu les notions de Pièce, de Représentation, de Séance et de Lieu.

Alignement des données

L'objectif de notre maquette étant de rendre visible les évolutions des pièces qui apparaissent quand on fusionne les données complémentaires issues des différentes sources, nous avons ensuite aligné les pièces.

Pour cela, nous avons utilisé la date de représentation pour restreindre les candidats à l'alignement, puis le nom de la pièce. Par exemple, nous savons que le 30 septembre 1681 on a joué d'après la base CESAR une pièce 123303 intitulée "Phèdre et Hippolyte" et une pièce 23287 intitulée "Les Fragments de Molière". A la même date, d'après la base RCF, on a joué une pièce 5772 intitulée "Phèdre et Hippolyte ou Phèdre" et une pièce 5396 intitulée "Fragments de Molière (Les)". Avec une simple distance de Levenshtein entre chaînes de caractères, nous pouvons aligner les pièces et affimer que 123303 chez CESAR correspond à 5396 chez RCF.

En appliquant ce traitement sur l'ensemble des dates, nous avons obtenu un alignement entre les 49 pièces de CESAR et RCF.

Vu le temps imparti, nous nous sommes limité aux pièces, mais on pourrait pousser plus loin et par exemple inclure dans le modèle les personnes, puis les aligner en utilisant des critères appropriés.

Exploitation des données

Une fois les données importées depuis les différentes sources, converties dans le même modèle et alignées automatiquement entre CESAR et RCR ou une par une pour quelques pièces de ONSTAGE, il devient possible de les exploiter.

Les bases RCF et ONSTAGE ne contenant pas de lieux, nous avons supposé que toutes les représentations RCF étaient à Paris et toutes celles d'ONSTAGE à Amsterdam. C'est probablement faux, donc pour améliorer la qualité du résultat il faudrait trouver des sources complémentaires à partir desquelles importer les lieux exacts des représentations.

Dans le calepin Jupyter qui nous a servi pour consigner nos expérimentations de manière reproductible, nous avons finalement produit le graphique ci-dessous:

Le menu déroulant en haut à gauche permet de choisir une pièce.

Nous voyons au centre un nuage de points, avec l'année en abscisse et la ville en ordonnée. La couleur des points reflète la source de données et leur taille dépend du nombre de représentations.

L'histogramme au-dessus du graphique est l'aggrégation des données par an pour toutes les villes. L'histogramme de droite est l'agrégation par ville pour toutes les années.

Ce graphique démontre que nous avons produit les données souhaitées, mais il aurait fallu plus de temps pour les représenter comme imaginé en début de hackathon lorsque nous avons dessiné les maquettes graphiques.

Conditions de l'interopérabilité et gouvernance

Ce hackathon a mis en lumière pour tous les participants des questions bien connues de ceux qui ont l'habitude de ce genre d'exercice:

1. un modèle commun est nécessaire pour communiquer entre les bases et celles et ceux qui administrent ces bases
2. la qualité des données d'entrée détermine l'efficacité du traitement, c'est à dire le rapport entre la qualité du résultat et l'effort nécessaire pour le produire
3. l'alignement est une étape cruciale de la fusion des données issues de plusieurs sources
4. les standards du Web Sémantique, et particulièrement le RDF et le SPARQL sont des atouts indéniables pour faire interopérer plusieurs sources de données

Ces constats ont fait émerger, au sein de la communauté présente à ce colloque, la question du partage des bonnes pratiques de publication de données. Effectivement, maintenir un modèle commun d'échange, rédiger une guide de bonnes pratiques pour la publication, accompagner les institutions dans leur parcours d'apprentissage, tout cela est un travail long, mais primordial pour supprimer les obstacles à l'interopérabilité.

Il a été discuté de créer un consortium Huma-Num consacré à la gestion des données du spectacle vivant et à l'expression de ces bonnes pratiques, pour orienter la suite des travaux vers des solutions communes et faciliter les interactions entre les données de différentes institutions.

A Logilab, nous apprécions le travail que nous réalisons depuis plusieurs années pour le projet des Registres de la Comédie François et nous avons été honorés d'être invités à ce colloque. Ce hackathon nous a permis de relier les données de RCF, que nous connaissons bien, à d'autres jeux de données, que nous avons découverts, mais aussi de prendre part aux débats sur leur gouvernance future. Nous espérons pouvoir continuer à apporter nos compétences techniques à ces projets, pour faciliter le travail de recherche sur le théâtre et son histoire.

380 mots - 2 minutes de lecture

Nous collaborons avec Siemens sur un projet relatif au Web sémantique des objets (Semantic Web of Things ou SWoT en anglais).

Semantic Web of Things

Le Web des objets (Web of Things, WoT), a pour objectif de standardiser l'utilisation des technologies du Web (HTTP, URI, etc.) pour contrer la fragmentation de l'Internet des objets.

Cette standardisation est menée par un groupe de travail du W3C.

Le Web des objets profite notamment de l'interopérabilité offerte par le Web sémantique via la réutilisation de ses standards de représentation de données (RDF, ontologies OWL/RDFS, etc.).

WoT - Thing Description

La spécification WoT-Thing Description (WOT-TD) permet de décrire l'API de chaque objet connecté : quelles propriétés, actions, événements et interactions sont propres à l'objet. Toutes ces informations sont exprimées à la fois dans un JSON normalisé et en RDF avec une ontologie dédiée. Le document numérique décrivant l'objet est nommé Thing Description (TD).

WoT - Thing Description Directory

Une fois que les TD sont créées, il faut les rendre accessibles et découvrables. La spécification WoT-Discovery décrit les différentes manières de publier et de centraliser les TD. Un Thing Description Directory, décrit dans WoT-Discovery, est entrepôt de TD ayant une API en JSON, RDF et SPARQL. Nous avons developpé un prototype de Thing Description Directory (SparTDD) en Flask et SPARQL, que nous avons présenté à la conférence ESWC2022.

Asset Administration Shell

Asset Administration Shell est une spécification issue du projet allemand Platform Industry 4.0, qui a pour but de numériser les données de l'industrie et de permettre la création de jumeaux numériques.

Un Asset Administration Shell (AAS) caractérise une ressource (asset) en donnant sa description, ses fonctionnalités, la documentation des objets électroniques, etc.

La spécification se veut très générique pour couvrir un maximum de cas d'usages ; c'est de fait une sorte de méta-modèle. Elle comprend un JSON-Schema et une ontologie OWL générée à partir de ce JSON-Schema.

Avec Siemens, nous avons étendu SparTDD pour qu'il puisse ingérer et servir des AAS en plus des TD. Nous avons également créé un module de traduction d'une TD vers un AAS pour, lors de l'import d'une TD créer son pendant en AAS. Les AAS obtenus de SparTDD peuvent ensuite être ingérés par les outils existants qui savent manipuler des AAS.

500 mots - 3 minutes

La PyConFR est le rendez-vous immanquable de la communauté Python en France. Hébergé cette année par l'Université de Bordeaux, cet évènement a rassemblé des développeurs, novices et expérimentés, pendant quatre jours autour de sprints, conférence et ateliers. Après presque trois ans d'attente, nous étions contents de pouvoir enfin retrouver la communauté Python.

Sprint ReservoirPy

Les jeudi et vendredi 15 et 16 étaient consacrés aux sprints, ces ateliers qui rassemblent plusieurs personnes pour faire avancer des projets choisis au préalable.

Nous avons pu contribuer à reservoirpy, une bibliothèque de Reservoir Computing développée à l'INRIA. Nous avons travaillé sur la publication automatique via l'intégration continue (GitHub Actions en l'occurrence) de nouvelles versions de la bibliothèque sur Pypi et sur un entrepôt Anaconda.

Pour en savoir plus sur le Reservoir Computing, vous pouvez regarder cette vidéo d'introduction captée à Dataquitaine en février 2022).

Conférences

Le programme des conférences était très riche et nous avons apprécié la diversité des thématiques (généralistes, web, science des données, devops, ...). Nous n'avons pas pu aller voir toutes les conférences, mais voici un échantillon de celles qui ont particulièrement retenu notre attention.

NucliaDB, une base de données pour le machine learning et les données non-structurées

Éric Bréhault (Nuclia) a présenté NucliaDB qui est une base de données vectorielle, c'est-à-dire qu'elle permet d'associer des données à des vecteurs situés dans un espace ayant de nombreuses dimensions. Adaptée à un usage en machine learning, cette base de données propose une API permettant d'indexer des données non structurées, de faire des recherches sémantiques, etc.

À la découverte de Polars (ou pourquoi vous pourriez quitter pandas)

Cette présentation de Olivier Hervieu nous a fait découvrir une alternative à Pandas pour le traitement de données tabulaires, nommée Polars. Cette bibliothèque est utilisable en Rust et en Python. Nous avons retenu sa capacité à charger des données de manière paresseuse à partir de fichiers.

Python moderne et fonctionnel pour des logiciels robustes

La présentation de Guillaume Desforges (Tweag) a mis en avant les avantages de la programmation fonctionnelle et son applicabilité au langage Python. Elle s'est terminée par une présentation de l'architecture en oignon appliquée à une application Flask.

Psycopg, troisième du nom

Durant cette conférence, Denis Laxalde (Dalibo) a présenté l'historique de la bibliothèque Psycopg. Nous avons également pu découvrir le protocole de communication utilisé pour parler avec un cluster PostgreSQL. Enfin, nous avons observé comment Psycopg s'appuie sur la bibliothèque libpq pour proposer une API haut niveau aux développeurs Python. La version 3 de Psycopg apporte de nombreuses améliorations dont le support de async/await, le support du mode pipeline ou encore le typage statique. Nous sommes fiers à Logilab d'avoir contribué à son financement.

Conclusion

Les PyConFR sont toujours un grand moment partagé avec la communauté Python. Que ce soit pendant les sprints ou entre les conférences, nous avons eu l'opportunité de rencontrer des développeurs de tous horizons et d'échanger avec eux sur des problématiques communes. Rendez-vous dans un an pour la prochaine édition et le 16 mars dans nos locaux parisiens pour un Afpyro.

Les AFPYRo reprennent et le prochain aura lieu dans nos locaux parisiens entre Denfert Rochereau et la Place d'Italie !

Un AFPYRo est un événement organisé par l’AFPy − Association Francophone Python − pour regrouper des personnes souhaitant discuter du langage de programmation Python dans un cadre convivial. Après une ou deux présentations (vous pouvez proposer la vôtre), nous échangerons autour de quelques pizzas.

Le prochain AFPYRo sera donc à Logilab, au 104 Boulevard Auguste Blanqui 75013 Paris, le 16 mars 2023 de 19h à 21h et nous offrirons les pizzas.

N’hésitez pas à vous inscrire et à passer nous voir !

Comme annoncé en novembre dernier, nous allons essayer de diversifier les événements SemWeb.Pro. Nous commençons par organiser une journée d'ateliers Semweb.pro à Toulouse au sujet du web sémantique et orientée vers les données industrielles.

L'idée est de réunir les acteurs industriels locaux ou non pour échanger ensemble sur l'usage des standards du web sémantique, qu'il s'agisse de décrire des installations, des processus ou des équipements, exploiter des réseaux de capteurs, etc.

Cette journée aura lieu le 14 Mars à Toulouse, dans l'espace de coworking et de réunion O'Local, dans une belle bâtisse typiquement toulousaine, avec comme objectif de favoriser au maximum les interactions.

La matinée sera dédiée à des présentations sur le thème du Web Sémantique pour l'industrie. L'après-midi sera l'occasion de mener des ateliers en petits groupes pour prendre le temps d'échanger. Une restitution rapide des ateliers clôturera la journée.

Tous les détails relatifs à l'inscription sont sur le site semweb.pro. Attention, le nombre de places est limité.

Logilab a publié son calendrier de formations pour le premier semestre 2023. Ces formations commenceront à partir du mois de mars avec un programme varié et modulable.

Cette année, nous proposons des formations sur Toulouse en plus de nos incontournables formations à Paris. Par ailleurs, quelques-unes de nos formations (qui s'y prêtent bien) se dérouleront en ligne afin d'éviter des déplacements et des heures de trajet inutiles. Grâce à nos outils de visio-conférence, vous pourrez profiter de sessions d'exercices avec un suivi aussi soigné que pour nos formations en présentiel.

Cette année, quelques nouveautés ont été ajoutées au catalogue afin de couvrir au mieux les besoins de formation que nous avons identifiés. Par exemple, la formation "Exploiter le Web des données avec Python (2 jours)" qui s'adresse à des experts et des techniciens dans le domaine de la publication de données ouvertes.

Spécialiste de Python en France depuis 2000, nous proposons toujours un large choix de formations sur ce langage de programmation et ses bibliothèques. Nous proposons également des formations sur :

• le Web des données pour découvrir le Web Sémantique et son utilisation dans des projets ;
• la création d'interfaces utilisateur avec Jupyter pour créer aisément de véritables petites applications Web interactives ;
• l'administration système avec Salt pour apprendre à gérer de façon industrielle des serveurs avec leurs divers services.

Nous limitons volontairement le spectre de nos formations pour ne proposer que les sujets que nous pratiquons au quotitien. Assister à une formation Logilab, c'est donc la garantie d'apprendre avec des professionnels compétents maîtrisant parfaitement le sujet qu'ils enseignent. Nos formations sont toujours ajustées en fonction des stagiaires présents. Pour toute demande spécifique, n'hésitez pas à contacter notre service dédié.

Logilab est déclarée comme organisme de formation depuis sa création, est référencée dans Data-Dock, et a été certifiée Qualiopi au titre des actions de formations. Les formations que nous proposons peuvent donc être financées par vos OPCO.

Ce week end, samedi 19 et dimanche 20 novembre, aura lieu le Capitole du libre à Toulouse. Cet évènement est toujours important dans notre calendrier car Logilab porte depuis sa création les valeurs du Logiciel Libre et dispose de locaux à Paris et à Toulouse. Nous serons donc, cette année encore, sponsor de cette conférence et prévoyons d'assister à de nombreuses présentations.

Nous présenterons, le samedi 19 novembre à 17h en salle A202, les dernières avancées de nos travaux de recherche, à savoir "CubicWeb-as-a-Service: Publier des données ouvertes ‘as a service’".

Nous serons enchantés de faire de nouvelles rencontres à l'occasion de Capitole du Libre. Contactez-nous par les réseaux sociaux si vous voulez convenir d'un moment pour discuter. Au plaisir de vous croiser cette fin de semaine à Toulouse !

Nous avons le plaisir de vous annoncer le programme de la conférence SemWeb.Pro 2022, que Logilab organise tous les ans depuis 2011 et qui réunit les professionnels du Web sémantique.

Après deux années chamboulées par la pandémie qui nous a imposé d'innover avec des conférences virtuelles dont les archives sont visibles sur peertube.semweb.pro, cette édition sera (enfin!) l'occasion de se retrouver en présentiel le 8 novembre 2022 prochain de 10h à 17h au FIAP de Paris. Vous avez jusqu'au 8 octobre pour profiter du tarif préferentiel de 82€.

Cette année, nous avons la chance de bénéficier du soutien de l'AFIA (l'Association Française en Intelligence Artificielle) qui offrira des entrées gratuites aux étudiantes et étudiants qui en feront la demande.

Le programme de cette édition s'articule autour de trois thématiques: le Web Sémantique face à de gros volumes de données, le Web Sémantique pour la culture et l'avenir du Web Sémantique.

Nous présenterons avec l'École normale supérieure de Lyon nos travaux sur la publication des données extraites des registres de la Comédie française dans la session Registres de la Comédie Française: du papier aux données RDF quantitatives.

Nous espérons que cet événement tiendra ses promesses en rassemblant comme tous les ans une centaine de personnes et en leur permettant de partager leurs travaux et d'entretenir leur réseau ou de découvrir les possibilités du web sémantique.

Temps de lecture 2 min (325 mots)

Nous sommes allés à la Plateforme Française en Intelligence Artificielle 2022 à Saint-Étienne cette année. Cet ensemble de conférences rassemble chaque année les acteurs de l'intelligence artificielle francophone. Nous étions très heureux et heureuses de pouvoir y participer cette année encore.

Nous avons suivi la conférence d'Ingénierie des Connaissances, qui est la plus proche de notre domaine d'expertise. Nous y avons présenté nos travaux actuels sur OWL2YAMS et avons eu des retours positifs avec plusieurs perspectives dont nous vous ferons part dans de futurs articles.

Même si toutes les présentations étaient enrichissantes (nous avons appris beaucoup de choses !), nous avons choisi d'en mettre trois en lumière.

DAGOBAH est un outil permettant de générer un graphe RDF à partir d'un fichier CSV, en alignant au passage les données avec Wikidata et DBPedia. Cet outil est arrivé premier à SemTab 2021, un challenge de sémantisation de données tabulaires. Cet outil, que nous avions déjà vu lors de SemWeb.Pro 2021 pourrait nous servir de base de départ pour les projets de sémantisation de données CSV, mais ses conditions d'utilisation (libre ou non ?), restent à préciser.

Un état de l'art sur la négociation de contenu a été présenté. Il catégorise les approches existantes et ouvre des perspectives en proposant de la négociation de contenu par vocabulaire ou par forme SHACL sur les données RDF disponibles. Nous allons voir comment utiliser ces résultats dans nos travaux sur la négociation de contenu dans CubicWeb. Les dernières propositions, si elles sont standardisées, pourraient être utiles dans notre navigateur pour le web de données.

Le projet ATLANTIS a pour but de sémantiser des instructions nautiques, jusque là conservées dans un document textuel, afin de simplifier la recherche en leur sein. Ce projet est une application très concrète des technologies du Web sémantique, qui montre comment elles peuvent aider les utilisateurs et utilisatrices. Nous essayons, à Logilab, de promouvoir les mêmes idées à travers de projets comme data.bnf.fr, ou encore FranceArchives.

Temps de lecture estimé 3 minutes.

Dans les articles précédents nous avons utilisé Pandas pour analyser un jeu de données, et avons créé des graphiques interactifs avec un calepin Jupyter. Cet article conclut la série en montrant comment utiliser Voilà et Jupyter-flex pour créer une application Web à partir d'un tel calepin.

Comme nous l'avons vu dans les deux premiers articles de cette série, l'utilisation de calepins Jupyter améliore le flux de travail des chercheurs et scientifiques depuis la phase exploratoire jusqu'à la communication des résultats. Pour un public non spécialisé, la présentation du code dans les calepins peut avoir un aspect rebutant, c'est pourquoi nous allons maintenant examiner Voilà et Jupyter-flex, qui permettent de créer facilement des tableaux de bord à partir des calepins.

Voilà

Voilà est un outil très simple qui permet de transformer nos calepins en applications web ou en tableaux de bord.

Voilà cache le code et affiche seulement le texte, les widgets et les résultats des calculs réalisés par le code, y compris les graphiques. Il se lance avec la commande voila <mon-calepin.ipynb>.

Si l'on reprend nos exemples précédents, cela donne :

Et si l'on reprend nos tableaux :

Le document reste interactif et on peut jouer avec, tout comme on le ferait avec un calepin, mais sans intervenir sur le code.

Jupyter Flex

Jupyter-flex quant à lui permet de créer des tableaux de bord HTML basés sur des calepins Jupyter. Il suffit pour cela d'ajouter un tag body dans la ou les cellules que l'on souhaite afficher dans le tableau de bord, puis de lancer la commande jupyter nbconvert --to flex <mon-calepin.ipynb> --execute qui exécutera toutes les cellules du calepin et retournera un joli tableau de bord composé avec les cellules taguées.

À noter : si nous utilisons la commande précédente, nous obtenons une version statique, ce qui peut être le comportement souhaité pour un tableau de bord. Si nous lançons le calepin avec Voilà, nous avons un tableau de bord dynamique.

Chez Logilab, nous utilisons Jupyter-flex pour notre tableau de bord interne. Couplé à la CI, il est mis à jour régulièrement.

Nous avons utilisé Jupyter et Jupyter-flex dans le cadre de projets clients, notamment le projet Resourcecode pour l'IFREMER (Institut Français de Recherche pour l'Exploitation de la Mer) et ses partenaires.

Les outils créés à cette occasion sont visibles dans la page ResourceCodeTools et le code disponible dans l'entrepôt GitLab de l'Ifremer.

Comme on le voit dans cette illustration tirée du projet Resourcecode, on peut ajouter un menu latéral, des onglets ou une infobulle d’information. Jupyter-flex propose une architecture Cards -> Section : une Card (encart) contient une ou plusieurs cellules (code ou markdown) taguées (body, source, footer, ou même help pour afficher un modal) et une Section est constituée d'un ou plusieurs encarts que l'on affiche en colonnes ou en rangées. Jupyter-flex utilise Material UI qui s'appuie sur Grid qui est basé sur CSS Flexbox.

La documentation de Jupyter-flex est claire et comporte bien d'autres informations et options intéressantes, notamment pour la mise en page ou pour l'association Voilà et Jupyter-flex.

Note : à la date où nous écrivons, Jupyter-flex n'est pas compatible avec les dernières versions de Voilà ce qui devrait être rapidement résolu.

Temps de lecture estimé à 5 minutes.

Cet article explique notre reflexion sur le choix de la technologie la plus adaptée entre React Admin et Refine pour refaire l'interface de notre cadriciel CubicWeb.

Le stage d'Arnaud Vergnet s'est déroulé sur le premier semestre 2022 et son objectif était de réaliser une interface d'administration pour CubicWeb en React, en remplacement de l'interface web générée par CubicWeb.

La communauté React est très active et on trouve de de nombreuses bibliothèques pour résoudre des problèmes récurrents, dont la réalisation d'interfaces d'administration. La première étape consistait donc à faire un état de l'art des différentes technologies disponibles pour réaliser de telles interfaces.

De nombreuses technologies sont disponibles, mais deux se sont démarquées par la richesse de leurs fonctionnalités et leur communauté active: Refine et React Admin. Cet article va donc présenter et comparer ces deux bibliothèques ainsi que présenter le choix qui a été fait pour la suite du stage.

Refine

Cette technologie est récente (créée en 2021). C'est une bibliothèque sans affichage (headless) de création d'interface d'administration. Cette technologie est donc indépendante de la bibliothèque de composants graphique utilisée et s'occupe seulement de la phase de récupération et modification de données grâce à des hooks React. L'avantage de cette méthode est qu'elle permet de créer plus que des interfaces d'administration car elle ne s'occupe que de la gestion des données. Il est donc possible de créer une interface complètement customisée.

Malgré le fait d'être découplée d'une bibliothèque graphique, cette technologie propose tout de même une intégration out-of-the-box avec la bibliothèque Ant Design. Ces composants sont donc directement utilisables avec Refine sans avoir à construire une couche de compatibilité. Ant Design propose de nombreux composants de haute qualité et possède une communauté très active.

React Admin

Cette technologie est bien établie (créée en 2016) et propose une solution centrée sur la création d'interface d'administration. Ici de nombreux composants utilisant la bibliothèque MUI sont proposés, ainsi que de nombreux hooks React pour créer ses propres composants. MUI est une autre bibliothèque de composants React très populaire suivant les règles Material Design de Google. Grâce à cette intégration avec une bibliothèque de composants, il est possible de créer une interface d'administration en peu de temps et de lignes de code.

Comparaison

Les deux bibliothèques reposent sur le même principe: l'utilisateur doit écrire un objet appelé Data Provider décrivant les méthodes pour interagir avec le serveur de données, réalisant ainsi une couche d'abstraction sur les données. Les figures 1 et 2 présentent l'interface de ces objets pour Refine et React Admin et nous pouvons remarquer que ces interfaces sont similaires. Il serait donc possible de réutiliser tout ou une partie de cet objet entre les deux technologies, améliorant ainsi leur interopérabilité.

Figure 1 : Data Provider de React Admin

Figure 2 : Data Provider de Refine

Comme nous pouvons le voir en figure 3, en plus de cette ressemblance pour le Data Provider, Refine et React Admin gardent une approche semblable pour résoudre le problème de génération d'interface, simplifiant encore leur interopérabilité. La différence réside principalement dans les bibliothèques de composants graphiques compatibles et donc leur utilisation finale.

Figure 3 : Comparaison de Refine et React Admin

Dans les deux cas il est possible de gérer les permissions et l'authentification. Les deux supportent aussi TypeScript pour avoir un typage fort afin de détecter les erreurs rapidement. Ant Design et Material design sont tout deux des bibliothèques matures avec une grande richesse de composants.

Ces points communs rendent le choix de technologie non-trivial et expliquent pourquoi il a été décidé de se concentrer principalement sur ces deux bibliothèques. Malgré toutes ces similarités, certaines différences ont fait pencher la balance vers une des deux technologies.

La première différence est le support de ces bibliothèques. React Admin a été créé en 2016 (React lui-même datant de 2013) et les développeurs (l'entreprise Marmelab) le maintiennent et ajoutent toujours des fonctionnalités. La version 4 est sortie pendant le stage d'Arnaud et le support réagit dans de courts délais. Refine est aussi activement maintenu par l'entreprise Pankod, mais le projet est beaucoup plus récent (début 2021), il est donc plus difficile d'estimer si le projet durera dans le temps. React Admin est donc un choix plus adapté en termes de stabilité.

Une autre différence majeure est sur l'utilisation de bibliothèques de composants d'interface. React Admin est fait pour marcher avec MUI et il serait difficile d'utiliser une autre bibliothèque sans tout réécrire. Refine quand à lui fonctionne par défaut avec Ant Design mais peut fonctionner avec n'importe quelle bibliothèque de composants. Cette liberté peut être utile pour s'adapter à n'importe quelle situation et client. En revanche il devient alors plus complexe de réaliser de simples interfaces comparé à React Admin. Pour faire une interface d'administration moderne sans besoins particuliers de design, React Admin offre alors une plus grande facilité et rapidité de développement.

Suite à cet état de l'art, il a été choisi d'utiliser React Admin pour réaliser l'interface d'administration de CubicWeb auto-générée. Refine n'est tout de même pas abandonné. Grâce au système de data provider adopté par les deux technologies, il sera possible d'adapter la logique utilisée pour React Admin à Refine. Il sera ainsi possible d'utiliser Refine pour développer des applications utilisateurs plus complexes si le besoin se fait sentir.

Suite ?

Tous ces développements sont Open-Source et vous pouvez retrouver le code permettant d'adapter React Admin à CubicWeb sur la forge de Logilab.

Temps de lecture estimé 10 minutes.

Dans un article précédent nous vous proposions une analyse de données à l’aide de la bibliothèque Pandas. Nous y avions construit une série de graphiques simples pour réaliser cette analyse. Dans cet épisode, nous allons aborder les widgets qui vont nous permettre de rendre ces graphiques dynamiques.

Il est conseillé d’avoir lu l’article précédent qui détaille la structure des données utilisées.

Qu’est-ce qu’un widget ?

Dans un calepin jupyter, le code peut facilement être édité et rejoué. Il est donc assez simple d’effectuer des changements. Il est toutefois possible que les utilisateurs finaux de l’application ne sachent pas programmer ou simplement qu’on préfère avoir un moyen simple d'interagir (sans avoir à relire le code Python et à le modifier). Dans de tels cas, les widgets constituent une bonne solution.

Les widgets sont des objets qui sont rendus dynamiquement dans les calepins Jupyter, et avec lesquels il est possible d’interagir.

La bibliothèque de base pour construire ces widgets est ipywidgets.

Dans l’exemple ci-dessous, la bibliothèque est importée puis un curseur glissant est construit.

>>> import ipywidgets as ipw
>>> ipw.IntSlider(min=0, max=20, step=2)

À l’exécution de la cellule Jupyter, le widget est affiché.

La connexion entre le widget affiché dans la page Web et l’objet python a été automatiquement définie. Cela signifie que si l’objet python est modifié, le rendu du widget est modifié et vice-versa. Dans le cas présent, l’attribut value du widget vaut 6.

À titre d’exemple, on peut construire un curseur glissant comme ceci :

>>> slider = ipw.IntSlider(min=0, max=20, step=2)
>>> slider

puis modifier dynamiquement la valeur de cet objet. Le rendu sera alors mis à jour.

>>> from time import sleep
>>> for i in range(0, 22, 2):
...    sleep(1)
...    slider.value = i

Les widgets deviennent très intéressants dès lors que l’on associe des fonctions python à des évènements. Dans l’exemple ci-dessous, nous avons défini deux widgets de type “curseur glissant” et un widget d’affichage. Nous voulons afficher dans ce dernier widget la somme des deux curseurs.

On construit un widget de type Bouton, et on associe le clic sur ce bouton à l’appel de la fonction compute_add qui somme les valeurs des deux curseurs et met à jour l’affichage.

>>> from IPython.display import clear_output
>>> sld1 = ipw.IntSlider(min=0, max=20)
>>> sld2 = ipw.IntSlider(min=0, max=20)
>>>
>>> out = ipw.Output()
>>> with out:
...    print("0 + 0 = 0")
...
>>> def compute_add(evt):
...    with out:
...       clear_output()
...       res = sld1.value + sld2.value
...       print(f"{sld1.value} + {sld2.value} = {res}")
...
>>> btn = ipw.Button(description="Sum")
>>> btn.on_click(compute_add)
>>> ipw.HBox([ipw.VBox([sld1, sld2, btn]), out])

Le rendu est alors le suivant :

Utiliser un widget pour sélectionner les données à afficher

Dans l’épisode précédent, nous avions écrit une fonction pour charger toutes les données des licenciés inscrits dans les fédérations sportives pour les années 2012 à 2019. La fonction est la suivante :

>>> from pathlib import Path
>>> import pandas as pd
>>> DATA_DIR = Path().resolve() / "data"
>>> def load_data():
...    year_dfs = []
...    for year in range(2012, 2019):
...       fname = f"sport_license_holders_{year}.csv"
...       yr_df = pd.read_csv(
...          DATA_DIR / fname,
...          dtype={"dep_code": str},
...          index_col=["dep_code", "dep_name", "fed_code", "fed_name", "gender", "age"],
...       )
...       yr_df.rename(columns={"lic_holders": str(year)}, inplace=True)
...       year_dfs.append(yr_df)
...    data = pd.concat(year_dfs, axis=1)
...    return data
...
>>> d = load_data()

Le DataFrame résultant contient plus de 1.6 millions de lignes et 7 colonnes. Nous pouvons maintenant écrire une fonction très simple qui affiche l’évolution du nombre de licenciés de 2012 à 2019 pour les fédérations qui sont données en paramètre.

>>> pd.options.plotting.backend = "plotly"  # Choose Plotly as the plotting back-end
>>> def plot_license_holders_evolution_by_sport(data, fed_codes):
...    data_sports = data.groupby(level=["fed_code", "fed_name"]).sum()
...    sel_data_sports = data_sports.loc[list(fed_codes)]
...    sel_data_sports = sel_data_sports.droplevel(0)
...    sel_data_sports.index.name = "Federations"
...    fig = sel_data_sports.transpose().plot(title="Sport license holders")
...    fig.update_layout(xaxis_title="year", yaxis_title="number of license holders")
...    return fig
...
>>> plot_license_holders_evolution_by_sport(d, [109, 115, 242, 117])

Nous souhaitons utiliser un widget proposant de sélectionner une ou plusieurs disciplines, puis afficher le graphique correspondant lorsque la sélection est validée.

La première chose que nous réalisons est un dictionnaire contenant en clef le nom des fédérations sportives et en valeur leur numéro associé. Ce dictionnaire pourra être fourni à un widget de type SelectMultiple.

Nous utilisons le code suivant pour obtenir le dictionnaire de correspondance :

>>> def extract_federation_names_codes(data):
...    codes = data.index.get_level_values(
...        "fed_code"
...    )  # Extract all the values from the level ``fed_codes`` of the index
...    names = data.index.get_level_values(
...        "fed_name"
...    )  # Extract all the values from the level ``fed_names`` of the index
...    dic = {name: code for code, name in zip(codes, names)}
...    return dic
...

Et finalement, la fonction suivante permet de construire l’interface souhaitée :

>>> from IPython.display import display
>>> def build_gui(data):
...    fed_values = extract_federation_names_codes(data)
...    fed_wdg = ipw.SelectMultiple(
...        options=fed_values, description="Sport federations", rows=20
...    )
...    plt_btn = ipw.Button(description="Plot")
...    out_wdg = ipw.Output()
...    # Define the hook function that will be called each time the button is clicked
...    def refresh_plot(evt):
...        fed_codes = fed_wdg.value
...        with out_wdg:
...            clear_output()
...            display(plot_license_holders_evolution_by_sport(data, fed_codes))
...
...    plt_btn.on_click(refresh_plot)
...    gui_wdg = ipw.HBox([ipw.VBox([fed_wdg, plt_btn]), out_wdg])
...    return gui_wdg
...
>>> build_gui(d)

Nous venons ainsi de faire une fonction qui construit une interface utilisateur, composée d’un widget permettant de faire une sélection multiple. Lorsque la sélection est validée, la fonction d’affichage du graphique est rappelée, mettant ainsi le composant à jour. Le développement de cette interface utilisateur est bien plus simple que ce que nous aurions eu à faire avec d'autres solutions comme Qt, Tkinter ou même Flask + Javascript.

On voit que cela permet à tous les utilisateurs de faire leur propre analyse sans avoir à changer une seule ligne de code.

Dans le prochain épisode, nous présenterons Voila qui permet de transformer un calepin Jupyter en une petite application Web, utilisable sans aucune connaissance de Python. Nous utiliserons également jupyter-flex pour obtenir une jolie application Web dotée de bulles d’aides, d’onglets et d’un menu latéral.

Temps de lecture 2 min (400 mots)

Dans le cadre de son stage de fin d'étude à Logilab, Arnaud à été amené à travailler avec des projets JavaScript (CubicWebJS et react-admin-cubicweb) nécessitant un processus d'intégration continue (CI) qui s'exécute sur notre forge heptapod.

Pour éviter de répéter le code décrivant la CI, Arnaud a écrit plusieurs scripts à utiliser comme patrons dans les projets JavaScript. Ces scripts sont intégrés au projet gitlab-ci-templates. Ils supposent l'utilisation de nodejs et sont compatibles avec yarn et npm. La détection se fait automatiquement : si le fichier yarn.lock est présent à la racine du projet, yarn est utilisé, sinon c'est npm. L'image de base utilisée pour tous ces scripts est node:latest, si vous avez besoin d'une version spécifique, vous pouvez remplacer latest par la version de votre choix en surchargeant le script dans votre projet.

Voici un bref descriptif des différents scripts disponibles :

• js-install : installe les dépendances listées dans le fichier package.json et génère un artifact avec le dossier node_modules (ou les dossiers si on est dans le cas d'un workspace yarn). Cette installation est utilisable par les étapes suivantes si elles incluent js-install en tant que dépendance.
• js-lint : lance la commande lint spécifiée dans le fichier package.json.
• js-test : lance la commande test spécifiée dans le fichier package.json.
• js-build : construit le projet avec la commande build spécifiée dans le fichier package.json. Il peut être utile de générer un artifact avec le résultat du build pour le rendre utilisable lors d'une autre étape.
• npm-publish : publie le projet sur npmjs.com. Ce script n'est lancé que lorsqu'un tag est détecté et seulement si les scripts de test, lint et build précédents ont réussi (ces scripts étant optionnels). Si vous avez généré un artifact avec le résultat du build, il sera disponible ici pour publication. Ce script considère qu'il existe une variable d'enrivonnement NPM_TOKEN contenant le token de connexion pour la publication. Il est possible de spécifier ce token comme variable cachée dans GitLab (et donc dans Heptapod).
• webpack-publish : compile le projet en utilisant webpack et génère un artifact avec le dossier public pour préparer le déploiement sur les Gitlab pages. Ce script n'est executé que sur la branche default et seulement si les scripts de test, lint et build précédents ont réussi (ces scripts étant optionnels). Si vous avez généré un artifact avec le résultat du build, il sera disponible ici pour publication.
• gitlab-pages : Publie le contenu du dossier public sur les Gitlab pages du projet. Ce script n'est executé que sur la branche default. Pour l'utiliser dans vos projets, vous aurez besoin de définir vous-même ses dépendances pour pouvoir publier les résultats de compilation.

Voici un exemple de l'utilisation de ces scripts dans le projet react-admin-cubicweb :

N'hésitez pas à utiliser ces scripts dans vos projets JavaScript, ils sont faits pour ça !

Temps de lecture ~1 min (100 mots)

Dans le cadre de ses formations, Logilab à créé jupyterlab-friendly-traceback, une extension JupyterLab qui permet d'utiliser friendly-traceback de façon interactive dans les calepins Jupyter.

Le but du module Friendly-traceback est de remplacer les messages d'erreurs standards de Python par des messages plus complets et plus faciles à comprendre. Ce module permet, entre autre, d'expliquer ce qui a provoqué la levée d'une exception dans un programme.

Les informations données par Friendly-traceback ont une grande valeur pédagogique et permettent aux développeurs Python débutants, voir confirmés, de mieux comprendre les erreurs présentes dans leur code.

Pour utiliser l'extension jupyterlab-friendly-traceback, il suffit de la pip-installer dans votre environnement de la façon suivante:

$> pip install jupyterlab-friendly-traceback

Il est ensuite possible d'activer et de désactiver l'extension JupyterLab en cliquant sur un bouton qui apparaît dans la barre d'outils du calepin Jupyter.

Temps de lecture 4min (~800 mots)

Nous poursuivons notre participation au libre en envoyant deux nouveaux logilabiens, Yoelis et Arnaud aux JDLL de Lyon, le rendez-vous annuel de celles et ceux qui sont curieux·ses et passionné·e·s de numérique libre et émancipé. Ils y ont découvert l'actualité économique et les enjeux politiques inhérents à la pratique du libre. Ils ont également été surpris par la richesse de l'innovation qui se déploie dans ces espaces.

Ce week-end fût riche en idées et les résumer en quelques lignes n'est pas tâche aisée. Nous nous sommes concentrés sur quelques conférences, mais vous trouverez la liste complète de toutes les conférences. Les différentes discussions auxquelles ont participé nos Logilabiens tournent autour de trois grandes questions.

Comment défendre nos droits et s'organiser en dehors des structures verticales et traditionnelle du pouvoir ?

Le collectif des chatons avait des choses à en dire. Les CHATONS, l'acronyme de Collectif des Hébergeurs Alternatifs, Transparents, Ouverts, Neutres et Solidaires, est un collectif d'hébergeurs citoyens. Ils permettent à chacun d'accéder à différents services hébergés (email, sites web, outils collaboratifs) près de chez eux afin que chacun puisse se réapproprier ses données et réduire sa dépendance aux GAFAM.

Les étudiants de Compiègne qui ont lancé Picasoft ont parlé de leur expérience de mise en œuvre d'un CHATONS et de la façon qu'ils ont eu de déconstruire progressivement au cours de cette expérience les structures classiques de l'organisation d'une association. Ils sont parvenus, non sans peine, à un mode de fonctionnement organique où celles et ceux qui font sont les décideurs, dans la bienveillance et l'écoute mutuelle.

Comment promouvoir la notion de commun, l'open-data et la réappropriation des données par les collectifs ?

Le langage n'est pas neutre et les dictionnaires sont imprégnés de la vision du monde de leurs auteurs et affectés par leurs conditions de production. S'il est le fruit d'un travail institutionnel, il y a un risque qu'il soit stoppé si les financements devaient s'arrêter ou si la situation politique changeait. La communauté est moins impliquée et le travail laissé à quelques sachants. La ligne éditoriale encourt un risque de censure et le contenu peut-être daté ou anachronique. Même si les projets issus de communautés ne sont pas concernés par ces problèmes, ils ont souvent du mal à atteindre les communautés érudites et ne sont pas toujours à la pointe en ergonomie et design.

Le Dictionnaire Des Francophones (DDF) a ainsi essayé de lier ces deux mondes. Basé sur les données du projet ouvert du Wiktionnaire (projet de la Fondation Wikimedia), le DDF est une initiative du ministère de la Culture pour représenter la diversité de la langue Française à travers toute la francophonie. Comparé au Wiktionnaire, le DDF possède une meilleure ergonomie et est plus facilement utilisable par d'autres applications grâce à la publication de ses données aux formats du Web Sémantique comme le RDF.

La métropole de Lyon a bien compris l'enjeu d'impliquer la communauté et mène un projet ambitieux d'ouverture de ses données. Cette initiative multiplie ainsi les possibilités de valorisation des données par les scientifiques et les journalistes. En revanche, contrairement au DDF, les données publiées ne sont pas au format du Web Sémantique, limitant les possibles utilisations. La perspective est tout de même envisagée sur le long terme.

Quels outils innovants pour l'ingénierie logicielle ?

En parallèle des conférences, nos logilabiens ont assisté à des ateliers techniques, tels que l'atelier d'initiation à Rust et à la conception d'un jeu avec Rust.

Rust est un langage de programmation à typage fort, garantissant l'absence d'erreurs de mémoire au moment de la compilation. Il est fortement inspiré de la famille du C avec une syntaxe moderne. Il permet différents styles de programmation, notamment fonctionnel. Contrairement au C et au C++, Rust utilise le gestionnaire de dépendances Cargo, similaire à Pip pour Python et NPM pour JavaScript. Rust est donc un langage système moderne possédant de nombreuses qualités pour simplifier le travail de ses utilisateurs, expliquant sa popularité en hausse.

Pijul est un nouveau système de contrôle de version ayant pour objectif de résoudre de multiples problèmes existants dans les solutions actuelles. Contrairement à Git et Mercurial qui se basent sur la théorie des snapshots, Pijul suit les pas de Darcs en s'appuyant sur la théorie des patchs. Historiquement, l'approche par snapshot possède de bien meilleures performances que celle par patchs, mais possède de nombreux problèmes lors d'opérations complexes (merge ambigus). L'objectif de Pijul est de résoudre les problèmes de performances présents chez Darcs pour créer un système performant à la Git, fiable et simple à utiliser à la Darcs.

Bilan

Participer à de tels événements est toujours une source d'inspiration pour nos logilabiens. La découverte de nouvelles technologies et de nouveaux projets libres est ce qui nourrit notre activité au quotidien. Grâce aux JDLL, Logilab sera sûrement amenée à utiliser une de ces technologies lors de projets. Nous avons hâte de retrouver tout ce joli monde à la prochaine édition !

400 mots - Temps de lecture 2 min

Le 10 mars 2022 a eu lieu le lancement de la « boite-à-outils Resourcecode » devant plus d’une centaine de partenaires du projet. Logilab est fière d’avoir pu participer à ce projet.

Resourcecode est un projet visant à soutenir les investissements et la croissance dans le secteur de l’énergie houlomotrice et maréomotrice par la création d’une boîte à outils intégrée de données marines.

Concrètement, des données décrivant l’état de la mer (vitesse du vent, hauteur des vagues, direction du courant, etc) sont enregistrées par des bouées de l’IFREMER (Institut Français de Recherche pour l'Exploitation de la Mer) et de ses partenaires. Des données de 1994 à 2020 sont disponibles pour des milliers de points de l’océan Atlantique et de la mer du Nord avec une résolution temporelle de l’ordre de l’heure. Une fois ces données enregistrées, elles peuvent être interpolées sur les points d’un maillage triangulaire.

Logilab a remporté un appel d’offre, déposé par l’Ifremer, dans le cadre de ce projet. Nous avons eu la charge de réaliser :

• une application web resourcecode.ifremer.fr permettant la visualisation des points où les données sont accessibles et proposant des outils statiques ou interactifs basés sur des calepins Jupyter afin d’étudier la mer au point considéré.
• produire une bibliothèque python resourcecode permettant de télécharger localement les données d’un point sous forme de DataFrame Pandas. L'intégration continue de la forge GitLab de l'IFREMER génère avec Sphinx la documentation de cette bibliothèque.
• intégrer à cette bibliothèque des codes de calculs écrits par l’IFREMER et ses partenaires (codes écrits en R, MATLAB ou Python)
• mettre en place une architecture permettant à l’IFREMER et ses partenaires de construire des nouveaux outils (statiques ou interactifs). Ces outils sont développés et maintenus par l’IFREMER et ses partenaires, et automatiquement intégré à l’application web. Ils sont développés sur l’instance GitLab de l’Ifremer.

Lors de cet événement de lancement de Resourcecode, une démonstration en direct a pu être effectuée auprès du public : la bibliothèque a été installée et un dépôt de code contenant un calepin Jupyter a été cloné puis exécuté. Cela a permis de démontrer la facilité d'utilisation de cet outil, ainsi que la répétabilité offerte par ce type d’architecture, qui correspond aux attentes actuelles en matière de science ouverte (Open Science).