CR lot 4: plan de gestion de donnés, 17/07/2020 

CR Visio ECONECT 

Plan de gestion de données (DMP) et le système d’information 

17/07/2020

 

Présents : Maxime Cauchoix (MC), Arnaud Elger (AE), Rahim Kacimi (RK), Emilie Lerigoleur (EL), François Thiébolt (FT)

Objet de la réunion :

– Plan de gestion des données (DMP) dans le projet ECONECT!

– Choix techniques concernant le format des données / le type de base de données

1) Plan de gestion de données (DMP) 

 

Document devenu livrable pour de nombreux financeurs comme l’ANR, il vise à améliorer la gestion des données tout au long du projet de recherche : les partenaires se mettent d’accord sur les modalités d’acquisition, de stockage/sauvegarde/archivage et de diffusion des différents types de données acquises et produites.

Ce document est évolutif et est complémentaire de l’accord de consortium.

L’outil DMP Opidor permet d’éditer en ligne le modèle de DP de son choix.

 

Plusieurs modèles existent et parmi les 4 proposés par EL, une préférence est donnée au modèle de l’ANR.

→ Choix du modèle de l’ANR, à confirmer auprès de Sabine Pinel lors du prochain Copil

 

Le DMP soulève des questions autour des différents thèmes suivants : 

–    Nature des données, volumétrie

–    Convention de nommage

–    Type de fichiers

–    Organisation du stockage (arborescence dossiers et/ou structure BD)

–    Metadata

–    Identifiant pérenne

–    Validation des données

–    Ouverture (ou non) des données : embargo, licence d’utilisation

–    PI sur les données

–    Données à caractère personnel

–    Administrateur des données (gestion)

–  Stockage à court, moyen et long terme – cf. stockage vs. archivage (quelles données, modalités de conservation et d’accès aux données)

–    Coût du stockage (mais aussi de la préparation / validation des données)

 

Chaque partenaire pourra décider du niveau de partage/ouverture des données en choisissant une licence adaptée. EL recommande l’utilisation des licences creative commons qui offrent un panel des possibles internationalement reconnues et pour certaines compatibles avec les licences ouvertes françaises Etalab (CC-BY notamment). 

 

Se pose la question de l’anonymisation des personnes qui vont collecter les données dans le cadre de la science participative (pour éviter d’être contraint par le Règlement pour la Protection des Données RGPD) : comment identifier et tracer les mêmes personnes collectant des informations à différents moments ?

 

A faire :

  • AE vérifie si le modèle ANR peut convenir auprès de Sabine et du Copil et informe le groupe
  • EL créé dans DMP Opidor le DMP pour ECONECT selon le modèle choisi et validé
  • AE/MC : prévoir une réunion spécifique en septembre avec les représentants de la collecte des données selon les différents systèmes connectés + données géographiques + science participative pour se mettre d’accord sur ;
    • les workflows de données
    • les lieux de stockage, les droits d’accès et de diffusion (choix licences)
    • les entrepôts et systèmes d’information en “sortie”, comme par exemple l’INPN ou le PNDB (Pôle national de données de la biodiversité)
    • les standards de données et métadonnées : à anticiper le plus tôt possible pour faciliter l’interopérabilité de notre système d’information avec les systèmes externes (entrepôts, INPN, PNDB, etc.). Par exemple pour les données écologiques, le standard EML pourrait être privilégié. Des réunions spécifiques par grands types de données collectées pourront suivre cette première réunion pour entrer plus en détail.

 

2) Système d’information ECONECT intégré dans neoCampus

 

FT présente le data lake de neOCampus avec ses trois zones interconnectées ‘landing area” (raw data), “golden area” (end-users data) et “work zone” (softly processed raw data) avec les API qui y permettent d’y accéder.

 

Tous les dispositifs sentinelles ECONECT enverront leurs données vers la plateforme qui s’occupera de leur stockage vers la “landing area” du data lake; un mécanisme de workflow (e.g Apache Airflow) permettra la mise en oeuvre de scripts de traitement de type flot de données pour alimenter les autres bases ou systèmes de fichiers.

Un serveur est provisionné où un moteur MongoDB, entre autres, sera déployé pour ECONECT. Une base mongoDB contiendra les données CAPTEURS stockées sous la forme d’un objet accompagné d’une URL d’origine et d’un timestamp. Les données seront stockées telles quelles (i.e data agnostic way). D’autres bases mongoDB pourront bien évidemment être mises en oeuvre pour les autres types de données (qu’il reste à préciser).

 

Des opérations de backup (dump) de la base CAPTEUR mongoDB seront réalisés à intervalles réguliers.

 

Pour permettre du machine learning et autres traitements de données, la solution Apache Airflow pourra être envisagée. 

Quid en cas de calculs coûteux (trop de données ou calculs trop complexes) ? RK précise que pour les petits calculs il sera possible de les faire en local dans un conteneur docker du serveur ECONECT. Une alternative est l’hébergement de scripts de traitement des données sur un autre serveur géré par un partenaire du projet, qui viendront se connecter aux bases de données sur le serveur ECONECT pour accéder aux données à traiter. Par contre en cas de calculs trop gourmands, il faudra utiliser des VM d’un datacenter comme par exemple Calmip ou OSIRIM (des conditions peuvent s’appliquer) de l’IRIT.  

→ Identifier les besoins en calculs et le ou les éventuels datacenters

 

L’ingénieur recruté à l’IRIT dans le cadre d’ECONECT travaillera pour les lots 3 et 4 dès septembre 2020.

→ Voir avec Adict Solutions comment répartir le travail entre l’ingénieur et eux pour le lot 4.

 

Calendrier ECONECT : pas de report de 6 mois, seulement 2 mois pour les justifications financières (et possiblement le rendu des derniers livrables). 

Discussion (0)

Il n'y a pas encore de commentaire.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *