exploitation et la fouille des données hétérogènes en écologie
2. Méthodes de conception des processus de test
2.1.
Conception de l’architecture et des services
La méthode proposée pour utiliser des graphes pour fouiller des données hétérogènes en environnement et écologie a été élaborée dans le cadre d’IndexMEED. Elle s’appuie sur une architecture d’indexation elle-même définie lors du séminaire «Design your infrastructure» organisée par European Grid Infrastructure http://www.egi.eu/ (avril 2016) (David et al., 2016b). Celle-ci a l’avantage de pouvoir, soit laisser les jeux de données chez le repository officiel (ce sont alors des flux paramétrables qui sont interrogés), soit de se baser sur des
imports (CSV, XML, JSON…). Il a été décidé de construire les graphes via un prototype de visualisation de graphes (sur un serveur WEB) à partir d’informations agrégées grâce à des points nodaux d’indexation104 et de qualification des données de contexte sur
l’environnement (qui peuvent être hébergées sur des serveurs de partenaires externes). Le système d’information et a fortiori les données auxquels il organise l’accès, doivent être évolutifs. L’architecture du système a été conçue pour organiser ces itérations qualitatives (Figure 40) selon un modèle qui se veut générique et transposable à tout type de données scientifiques. Les services d’indexation ont été voulus réplicables à la manière d’un plugin pour permettre la création d’un nouveau point nodal pour chaque nouvelle thématique disciplinaire ou interdisciplinaire, ou le développement d’une thématique à un niveau géographique différent. A l’image des registrars répliquant les bases d’IP, ces index se recopient d’un système à un autre avec toutes les qualifications de données en rapport avec son périmètre thématique ou géographique de recherche. Une généralisation de ce système devra s’appuyer sur une gouvernance des autorités gérant un point nodal, et une gestion des autorités produisant ou transformant la donnée et administrant un service d’accès aux données.
104 On appelle point nodal d’indexation un service web qui va moissonner les flux de données pour
indexer les enregistrements en utilisant des descripteurs communs à ces flux de données. Un point nodal peut être spécifique d’un domaine et/ou d’une zone géographique, et peut sélectionner une partie d’un flux servi par un autre point nodal, ou regrouper des flux de plusieurs points nodaux.
Figure 40 : Cette figure montre l'approche itérative utilisant les jeux de données CIGESMED et les workflow IndexMed. Les données provenant de différents fournisseurs/producteurs sont tout d’abord indexées par le prototype, puis qualifiées avec des descripteurs communs. Ces descripteurs sont choisis en fonction des standards disponibles si il y en a , sinon, de nouvelles propositions sont faites en intégrant au mieux les travaux antérieurs. On aboutit à une qualification commune des données (avec le processus de curation si nécessaire, il est alors possible de construire des graphes en effectuant des hypothèses à partir des données et les valeurs de descripteurs communs aux enregistrements étant les liens entre ces enregistrements (des objets de la base de données). À large échelle, ces descripteurs peuvent porter de nouvelles informations (enrichir la base de données) et aboutir à de nouveaux concepts, ce qui permet d’alimenter des thésaurus voire des ontologies. L’analyse des clusters de graphes permet ensuite de faire émerger des motifs de contextes qui sont significativement fréquents dans certains clusters, et sont conservés dans une base d’aide à la décision ou en tant qu’indicateur pour un gestionnaire. Les “output” sont génériques, et peuvent s’appliquer dans différents champs disciplinaires, et les bases de données, si elles décrivent les mêmes objets peuvent être de disciplines différentes.
Figure 41 : L’interface permet de paramétrer des requêtes en langage “Cypher”105 ou
de les générer via des formulaires (à gauche de l’image) et de visualiser les données sous forme de graphe ou de flux aux formats JSON ou XML (ici, on peut voir le flux JSON comportant les informations rattachées à un noeud du graphe). Ce fichier est généré à chaque requête, il peut être sauvegardé pour être utilisé à distance par une autre plateforme (bouton {URL} en haut à droite) ou être téléchargé directement (bouton avec la flèche dans le nuage en haut à droite). Ces fonctionnalités permettront d’interroger l’interface depuis les centres de calcul pour réaliser la fouille des graphes préparés et peuvent être conservés sur le serveur ou dans un centre de donnée distant.
Dans un premier temps, un prototype de visualisation est développé et testé pour visualiser des analyses de quadrats photo. Le modèle de données est simplifié pour rendre toutes les données adaptables. Ce modèle prend la forme "objet / attribut / valeur d'attribut", un modèle qui peut être formalisé en différents langages (OWL, RDF) et permettant de connecter des systèmes distants et multiformats (RSS, WMS, WFS, XML, JSON voir figure 41). Pour réaliser cette visualisation, les requêtes sont configurables et décrites dans David et al. 2016a.
Pour pouvoir visualiser et explorer simultanément des ensembles de données différents et distribués, un "service de résolution d'objet" (c'est-à-dire un service Web qui trouve des liens et des dépendances entre objets indexés, basés sur l'identifiant d'objets uniques) est partagé par différents partenaires sur un point nodal expérimental. Il est destiné à être géré comme un logiciel libre, installable sur un site web sous la forme d’un plugin et s'appuiera pour les besoins de fouille de la donnée sur un service sur la grille européenne (notamment via EGI). Les objectifs de ce prototype sont de :
i) Lister les données et séries de données disponibles sous forme de flux,
ii) Analyser le contenu des flux de données et le niveau de correspondance avec des standards existants,
iii) Qualifier les flux, les séries de données avec des identificateurs uniques s'il n'y a pas d'identifiants,
iv) Suggérer des correspondances entre les champs aux utilisateurs et des correspondances entre lignes de données équivalentes.
Un des rôles de ce service de résolution d'objet est d'établir des liens entre des lignes de données avec des "identificateurs uniques" différents (par exemple, des versions différentes
de données brutes, des interdépendances entre des données brutes et des données transformées, etc.).