Science Ouverte : sauvegarder, visualiser et partager vos données - Régis Witz

Titre : Science Ouverte : sauvegarder, visualiser et partager vos données

Intervenants : Régis Witz - Stéphane Igounet - Public

Lieu : Jres, Journées réseaux de l'enseignement et de la recherche - Dijon

Date : décembre 2019

Durée : 20 min 57

Visualiser la vidéo

Licence de la transcription : Verbatim

Illustration :

NB : transcription réalisée par nos soins, fidèle aux propos des intervenant·e·s mais rendant le discours fluide.
Les positions exprimées sont celles des personnes qui interviennent et ne rejoignent pas nécessairement celles de l'April, qui ne sera en aucun cas tenue responsable de leurs propos.

Transcrit : MO

Description

Dans le contexte de la science ouverte, l'Université de Strasbourg s'investit dans le développement de la plateforme POUNT, écosystème libre, modulaire et interopérable d’accès aux savoirs

Transcription

Stéphane Igounet : Bonjour à tous. Bienvenue dans la session « données de recherche », pour la préparation du gala et la session reposée, on va commencer par Régis pour une présentation « Science ouverte, sauvegarde, visualiser et partager vos données ». Régis, dans sa première vie, a travaillé pour les transports et même les banques et depuis quelque temps, à l’université de Strasbourg, il partage son temps entre le soutien à la recherche et l’enseignement. Régis, c’est à toi.

Régis Witz : Merci Stéphane. Merci de me recevoir aujourd’hui, merci à vous d’être là et merci aussi aux personnes de mon équipe dont vous voyez les noms s’afficher parce que les gens de la Direction du numérique, les gens du service de bibliothèque de l’université de Strasbourg ainsi que les chercheurs de la MSH [Maison des sciences de l’homme] de Strasbourg soutiennent le projet depuis son origine et au cours de son développement. Même si c’est moi qui parle aujourd’hui, je vais avant tout vous présenter le fruit du travail d’une équipe, donc merci à tous.

Rapidement sur le plan, quelles sont les problématiques qui émergent, quels sont les questionnements qui se posent quand on parle de la gestion des données de la recherche et une proposition de solution pour résoudre, humblement, une partie des problèmes que je vais vous présenter dans la deuxième partie de cette présentation.

La question à se poser est simple : qu’est-ce qui se passe pour les données de la recherche dans cent ans ? Que deviennent nos données dans cent ans ? C’est la première question qu’on m’a posée lors de la réunion du lancement de projet et, quelque part, ça met les choses en perspective et ça force à bien bosser.

Donc comment on fait ? Quand on réfléchit aux besoins des chercheurs au niveau de leurs données de recherche, leurs besoins sont majoritairement de quatre types :

• le premier c’est le stockage de leurs données de manière la plus pérenne possible ;
• le second c’est la structuration de leurs données de manière à ce que ces données restent exploitables et compréhensibles par le plus grand nombre ;
• le troisième c’est continuer de manière permanente à pouvoir accéder à ces données de manière à pouvoir faire des traitements toujours plus riches et faire une recherche plus avancée ;
• et le quatrième, ce sont les besoins en termes de publication et de valorisation de ces données afin de les donner au plus grand nombre, à la communauté de la recherche, certes, mais aussi au grand public au sens large et à des publics plus particuliers, tels que les journalistes, les gens du patrimoine ou les étudiants. Tous ces gens-là doivent pouvoir avoir accès aux données de la recherche.

Tout ça c’est dans le cadre de l’open data, de la science ouverte, du faire et ainsi de suite.

Quelques rappels rapidement. Quand on parle des données, comment on gère le cycle de vie d’une donnée ? C’est une question à se poser le plus tôt possible dans le cadre d’un projet de recherche, parce qu’encore aujourd’hui, lorsqu’une publication arrive, trop de publications qui sortent ne sont pas sorties de leurs données, ne sont pas sorties du code qui a servi à produire la donnée et, d’une manière générale, ça pose des questionnements en termes de quelle est exhaustivité de ce travail ? Si on n’a que la publication mais que les données qui ont servi à faire le travail ou que les données qui servent de résultat à ce travail-là ne sont pas accessibles, eh bien ça pose ça des problèmes d’exhaustivité, ça pose des problèmes de reproductibilité : comment faire pour reproduire les travaux de recherche si on n’a pas accès à la moitié du de travail ?
Ça pose aussi des questions de traçabilité : même si on héberge les données quelque part comment s’assurer quelles seront au même endroit dans cinq ans, dans dix ans, dans cent ans.
Comment on fait pour y accéder ? Comment on fait pour les citer ? Parce que souvent la recherche se fait de manière incrémentale, il faut pouvoir citer les travaux de ceux qui vous ont précédé mais aussi leurs données de manière à ce qu’on puisse pouvoir continuer à y accéder.
Toutes des questions de pérennité, de traçabilité, ce sont des questionnements à garder en tête quand on parle des données de recherche.

Toutes ces questions qu’on se pose sur les données, il faut aussi se les poser sur les métadonnées qu’elles soient descriptives, structurelles ou administratives, parce que souvent la donnée en elle-même n’est pas suffisante. Le plus souvent spécifiques à un projet particulier, il faut que ces métadonnées accompagnent la donnée à tout instant de manière à pouvoir la contextualiser. Toutes les questions qu’on se pose sur la traçabilité, la pérennité d’une donnée, on peut aussi se les poser sur les métadonnées.
Certaines métadonnées sont incluses de base dans le format de la donnée, par exemple les métadonnées EXIF ; la plupart du temps ce n’est pas le cas. Donc quel format adopter pour ces métadonnées ? Quel modèle de métadonnées choisir ? Aujourd’hui il existe plusieurs modèles de métadonnées, la plupart sont spécifiques à une discipline, ça pose des problèmes parce que souvent certains projets de recherche tirent parti de la transdisciplinarité, or des chercheurs qui ne parlent pas le même langage, qui n’ont pas le même modèle de métadonnées, ça peut poser problème et c’est dommage. C’est pour ça qu’aujourd’hui il y a des modèles interdisciplinaires qui sortent comme DataCite, Dublin Core, sauf que tous les chercheurs n’en ont pas connaissance, ce n’est pas forcément toujours le plus simple à prendre en compte, donc il faut être le plus pédagogue et le plus open possible sur les différents modèles de métadonnées. L’enjeu c’est évidemment l’interdisciplinarité et aussi le fait de pouvoir faire travailler efficacement des chercheurs même au sein de la même discipline. J’ai déjà eu des cas à l’université de Strasbourg où deux chercheurs de la même discipline, qui étaient dans des bureaux en face l’un de l’autre et qui n’utilisaient pas forcément la même manière de décrire leurs données.
Donc comment on héberge ces données, comment on en assure la traçabilité, comment on en assure la fiabilité ? C’est une question à résoudre dans le cadre des données, mais aussi des métadonnées.

Très rapidement un exemple, une illustration puisque c’est de là dont on vient. Au niveau des données 3D Catherine Duvette, à l’origine de ce projet, avait tenté de valoriser ses modèles 3D à travers certaines solutions. On a un exemple ici d’une capture d’écran de Sketchfab. Un de ses premiers modèles, une figurine de l’Égypte ancienne dont le but était de valoriser scientifiquement. Quels sont les problèmes qui surviennent avec une solution telle que celle-ci ?
Sketchfab c’est bien, la visionneuse est jolie, elle valorise bien les modèles 3D, sauf que dedans c‘est du stockage privé, donc qu’est-ce qu’il en est de la pérennité ? Est-ce que ce sera toujours accessible dans quelques années ? On ne le sait pas. Que deviennent nos données ? On ne le sait pas toujours non plus.
De la même manière, en bas vous avez un champ de description où Catherine Duvette a essayé de bien faire les choses, comment citer ce papier, d’où est-ce que ça vient. Mais tout ça c’est juste un champ de texte donc au niveau de l’expressivité, de la descriptivité de ces champs c’est assez limité.
La troisième chose c’est qu’on a un modèle intitulé «Nude Female Figurine », vous vous doutez bien que Sketchfab essaie de nous proposer des modèles liés et, avec une figurine nue, vous vous doutez bien que la valorisation scientifique n’est pas vraiment tiptop et qu’une plateforme comme Sketchfab n’est pas faite pour ce genre de travaux.

Donc ce qu’il faut, ce qu’il fallait, c’est pour ça que je suis là aujourd’hui, c’est une solution institutionnelle, non commerciale, le plus pérenne et générique possible.

6’50

Cette solution c’est POUNT, la plateforme ouverte numérique transdisciplinaire qui est là pour répondre aux quatre besoins des chercheurs dont j’ai parlé en début de présentation et en particulier la valorisation.

POUNT est un logiciel en développement dont les qualités sont celle-ci. Ses qualités ne sont pas des grands mots jolis à lire et à écrire c’est ma spécification à moi en tant que développeur. Il fallait un logiciel qui respecte toutes ces qualités.
Donc rapidement, les qualités de collaboration et de liberté. POUNT est un logiciel libre, placé sous licence GNU Affero GPL 3 et les autres qualités qui découlent, en fait, d’un bon développement logiciel : la modularité, l’extensibilité et ainsi de suite et les qualités on va dire plus métier, la stabilité, la simplicité. Je vais m’efforcer de vous les démontrer dans la suite de cette présentation.

Question : comment faire pour arriver à permettre aux chercheurs d’utiliser le modèle de description de métadonnées qu’ils désirent sans les contraindre avec des modèles de métadonnées existant.
En fait, la première phase du développement a été d’étudier les modèles de métadonnées qui existent et quand on les étudie, on s’aperçoit, en tout cas pour ceux dont on a eu connaissance, qu’au final c’est toujours clé-valeur. C’est toujours des clés, nommées, qui ont une sémantique bien particulière, et des valeurs typées bien particulières. En fait, quand on appelle ça des métadonnées, donc les valeurs, que ces métadonnées on les met dans des containers qu’on a choisi d’appeler éléments par convention et que ces éléments on les range à leur tour dans des containers de plus haut niveau qu’on a appelé des ensembles, un ensemble pouvant représenter un projet, une collection, une anthologie, ce que vous voulez, eh bien on se met à pouvoir exprimer tous les modèles de métadonnées existant.
La particularité c’est que quand un chercheur crée son ensemble, il lui colle un modèle de métadonnées. Il définit cet ensemble-là : je veux par exemple DataCite ou alors si DataCite qui est le modèle proposé par défaut par POUNT ne convient pas, j’ai une interface drag and drop pour enlever ou rajouter rapidement des métadonnées et les faire correspondre à ma propre description en tant que chercheur.
Ça ça nous permet de gérer du DataCite, du DublinCore, différentes nomenclatures ou taxons.
Ça c’est pour l’architecture conceptuelle.

Maintenant l’architecture physique. Au centre de POUNT il y a une API REST, documentés avec swagger, qui donne un accès aux ensembles, aux éléments. Un serveur Django qui est derrière une ??? NGINX. Derrière cette API REST, il y a un stockage. Le stockage des données de la recherche est basé sur ceph avec une passerelle Amazon S3 comme ça les données restent accessibles. Si l’API REST ne devait plus donner satisfaction pour une raison ou pour autre, on garde la main sur les données, en tout cas le chercheur garde la main dessus et sur les données « utilisateurs » de configuration de POUNT, les rôles et ainsi de suite, les permissions Ça c’est une base. PostgreSQL.

Devant l‘API REST il y a donc un client web qu’on a développé avec Vue.js. Pourquoi le framework Vue.js ? Parce qu’on a tout un tas de petits composants réutilisables, qu’on peut développer. En composants réutilisables en particulier par exemple c’est la visionneuse : si vous êtes sur la page de visualisation d’un élément, que vous voulez voir toutes les données et métadonnées liées à cet élément, pour chaque type de métadonnées, on a une visionneuse particulière. Pour une chaîne de caractères ce n’est pas dur, mais si, par exemple, vous avez une image, une vidéo, un PDF, une donnée 3D, eh bien la page de vision de l’élément va s’adapter à ce que contient vraiment cet élément.
La visionneuse 3D, par exemple c’est 3DHOP, c’est une visionneuse créée par de chercheurs italiens dont la référence est dans l’article avec tout ce qu’on veut en termes d’ouverture, de pérennité et d’évolutivité. Le client web étant évidemment multisupport, vu que nos cibles étant certes les chercheurs – notre but c’est de mettre en relation les chercheurs afin qu’ils puissent découvrir ce qui est fait d’autre, de similaire à leurs travaux, afin qu’ils puissent valoriser leurs recherches, afin qu’ils puissent entre guillemets « s’échanger leurs 06 » et travailler ensemble –, mais au grand public, aux étudiants, à eux, en 2019, on ne peut pas proposer une interface web qui est décorrélée du mobile.

Au niveau de l’autorisation, POUNT ne veut pas connaître vos login/mot de passe, vous n’aurez pas de compte sur POUNT.
Actuellement on a une authentification CAS-JWT spécifique à l’Unistra. À moyen terme on va implanter shibboleth et une authentification Oauth et cette manière dont vous vous authentifiez sur POUNT décide d’où vous venez et ce que vous avez comme capacités. Si vous êtes authentifié via shibboleth vous venez à priori d’une université, d’un organisme de recherche accrédité, donc vous avez le droit de créer tout ce que vous voulez en termes d’ensembles et d’éléments. Si jamais vous êtes un grand public authentifié avec son Facebook par exemple ou son GitLab, dans ce cas-là il faut qu’un chercheur vous invite à travailler sur son ensemble pour que vous puissiez collaborer, sinon vous n’avez que les droits en lecture sur votre ensemble si le chercheur a activé les droits en lecture au grand public. Si ce n’est pas le cas, si par exemple on est dans le cadre de données qui sont sous embargo ou dans le cadre d’un chercheur qui est en tain de préparer sa publication sur POUNT, en train de préparer sa valorisation, mais que la publication n’est pas encore, peut-être qu’on sera dans un ensemble qui n’est pas visible pour le grand public. Toute cette gestion des rôles POUNT s’en sert et c’est un des buts de l’API.

Voilà où on en est actuellement : différents composants facilement remplaçables facilement évolutifs. Et qu’est-ce que ça nous permet ? Eh bien vu qu’on a une API REST de s’interfacer avec d’autres clients, si vous avez une appli et que vous voulez voir les contenus hébergés sur POUNT, vous avez juste à développer l’interface qui va bien. Si vous voulez laisser tomber complètement la partie web et juste attaquer les données de POUNT à travers un script pour faire des traitements batch, vous pouvez. Ça nous permet aussi d’envisager un futur plus ou moins lointain. Faire de la réalité virtuelle avec les données 3D POUNT ce n’est pas dans mon plan à court terme, mais qui sait de quoi l’avenir est fait ? On essaye d’être ouverts avec POUNT, on essaye de se permettre d’évoluer, parce que je ne sais pas de quoi sera faite l’informatique dans cent ans, mais en tout cas si j’accueille le changement ça me permet de suivre le changement plutôt que de l’anticiper.
On peut aussi brancher d’autres stockages derrière POUNT. Si vous avez votre propre stockage si vous avez une API Dataverse ou un ???, il nous suffira de développer l’interface de manière à pouvoir publier vos données sur POUNT.
POUNT est interopérable avec elle-même. Donc si dans votre SI POUNT vous plaît, ce que je souhaite, vous pouvez déployer POUNT chez vous et vous pouvez faire communiquer différentes instances de POUNT.
Mon opinion ce n’est pas « je mets ma robe de bure et je dis venez tous sur POUNT c’est mieux que la concurrence ». Non ! C’est complémentaire de la concurrence, ça peut vous offrir en termes de recherche, de valorisation, et on peut, comme ça, créer un maillage de produits logiciels interopérables de manière à rendre les choses le plus visible et le plus interopérable possible.

Voilà où on en est aujourd’hui : POUNT, un logiciel en développement. Actuellement il n’est pas en prod, il le sera dans quelque temps.
Si vous avez de questions, des remarques, n’hésitez pas à nous contacter. Si vous avez envie de tester ou de contribuer, l’URL de notre GitLab est indiquée, elle est aussi dans l’article de recherche. Et si vous avez des questions dès maintenant, n’hésitez pas à me les poser.

[Applaudissements]