Projet : CARAVEL - caravel

<body bgcolor="#FFFFFF" text="#000000" link="#9944EE" vlink= "#0000FF" alink="#00FF00">  <a name="CHILD_LINKS" id= "CHILD_LINKS"><strong>Sous-sections</strong></a> <ul> <li><a name="tex2html258" href= "resul_theme2_mn.html#SECTION00062100000000000000" target= "main" id="tex2html258"><small>Modèles, langages et algorithmes pour le nettoyage de données</small></a></li> <li><a name="tex2html259" href= "resul_theme2_mn.html#SECTION00062200000000000000" target= "main" id="tex2html259"><small>Workflow scientifiques</small></a></li> </ul> <hr /> <h2><a name="SECTION00062000000000000000" id= "SECTION00062000000000000000">Production de données dérivées</a></h2> <a name="CARAVEL_resultats_theme2" id= "CARAVEL_resultats_theme2"></a> <p><strong>Mots clés :</strong> <i>hétérogénéité, optimisation, répartition .</i></p> <h3>Résumé :</h3> <div class="ABSTRACT"> <i>Lorsqu'on recherche une information précise dans un système d'information global, cette information n'existe pas toujours à l'état brut dans une source d'information. Dans ce cas, l'information doit être construite sur mesure (c'est souvent le cas dans les applications d'aide à la décision). Deux cas de figure assez différents se produisent. Dans le premier cas, la donnée recherchée peut être obtenue par intégration, consolidation, ou restructuration de données existantes. Le nettoyage de données (``data cleaning'', en anglais) qui intervient dans la construction d'entrepÔts de données (``data warehouse'', en anglais) est un cas typique de cette situation. Dans l'autre cas, les données recherchées peuvent s'obtenir au moyen d'un programme publié dans le système d'information global. Par exemple, on recherche une prédiction de l'évolution d'une nappe de pétrole lors d'une marée noire; cette information peut être calculée par un programme scientifique de modélisation de l'évolution de nappes. Mais l'exécution de ce programme peut à son tour nécessiter des données d'entrée qui n'existent pas de faÇon brute et qui doivent être elles aussi calculées. On obtient ainsi une chaîne de traitement dont les étapes de traitement correspondent à l'exécution de programmes publiés. Dans ces deux cas de figure, toute la difficulté est de simplifier la mise en oeuvre du calcul de ces données recherchées et de garantir que les données produites ont la qualité désirée. Les deux actions qui composent ce thème ciblent ce problème avec des approches adaptées aux deux cas de figure cités.</i> </div> <h3><a name="SECTION00062100000000000000" id= "SECTION00062100000000000000">Modèles, langages et algorithmes pour le nettoyage de données</a></h3><br /> <br /> <span class="textbf">Participants :</span> Daniela Florescu, Helena Galhardas, Eric Simon.<br /> <br /> <p>Le problème du nettoyage de données est bien connu dans le domaine des systèmes d'aide à la décision et des entrepÔts de données où il constitue l'un des problèmes les plus difficiles à résoudre. De nombreux outils, appelés ETL ou ``data cleansing'', ont été développés pour répondre à cette difficulté. Cependant, dans le cas d'applications telles que la migration de données très faiblement structurées vers des données structurées ou l'intégration de données scientifiques dans des domaines pluri-disciplinaires (e.g., la santé ou l'environnement), les outils existant destinés à l'écriture de programmes de nettoyage de données sont très insuffisants. Le problème principal rencontré est la conception d'un programme qui modélise un graphe à flots de données capable de transformer les données d'origine en données correctes et cohérentes et qui s'exécute efficacement sur de gros volumes de données. Ce problème résulte de deux lacunes dans les systèmes existant: (i) le manque de séparation claire entre la spécification logique des opérations de transformation de données nécessaires et leur implantation physique, et (ii) le manque de fonctionalités permettant d'assister l'utilisateur dans la mise au point de son programme de nettoyage. Les recherches effectuées dans cette action ont répondu à ces lacunes par la proposition d'un langage déclaratif de spécification de programmes de nettoyage, d'un modèle d'exécution logique pour les opérations de nettoyage de données et des algorithmes efficaces de mise en oeuvre de ces opérations. Le modèle d'exécution intègre quatre opérateurs spécifiques (mapping, matching, clustering, merging) qui permettent de décomposer un flot de données en plusieurs flots, de recomposer plusieurs flots par comparaison de la similitude de leurs données, de partitioner un flot en groupes, ou de fusionner un groupe de données en une donnée unique. Tous ces opérateurs sont paramétrables par des fonctions fournies par l'utilisateur (par exemple, des fonctions de calcul de similitude entre données). Le langage utilise une syntaxe proche de SQL et permet d'exprimer les opérations du modèle d'exécution de faÇon déclarative. Il permet également de spécifier les conditions dans lesquelles des exceptions doivent être générées et l'utilisateur doit être sollicité pour une intervention manuelle dans le processus de nettoyage. Un mécanisme sophistiqué de gestion d'exceptions et d'explication assiste l'utilisateur à mettre au point son programme. Enfin, le choix d'algorithmes efficaces pour exécuter les opérations est effectué par un optimiseur. Toutes ces propositions ont été implantées dans le logiciel AJAX et validées sur une application de nettoyage des références bibliographiques utilisées par le cite Web Citeseer avec un échantillon de 100.000 références. Cette validation a permis de vérifier l'utilité du langage et des fonctionnalités de gestion d'exceptions dans la mise au point de programmes ainsi que la performance des algorithmes proposés.</p> <h3><a name="SECTION00062200000000000000" id= "SECTION00062200000000000000">Workflow scientifiques</a></h3><br /> <br /> <span class="textbf">Participants :</span> FranÇois Llirbat, Eric Simon.<br /> <br /> <p>Les workflows scientifiques, dérivés des workflows de gestion, on été introduits comme un moyen pratique pour spécifier des expériences scientifiques. En effet, ils fournissent un modèle permettant une description formelle des expériences, facilitant ainsi leur exécution automatisée. Ils permettent aussi l'archivage et l'interrogation des expériences passées. Enfin, en imposant une notation commune, ils permettent aux différents laboratoires de comparer plus facilement leurs expériences. Cependant les solutions actuelles imposent une gestion centralisée des expériences autour d'une même base de données. Cette approche n'est pas adaptée à un contexte d'information global dans lequel les scientifiques peuvent partager facilement leurs données, leurs programmes et leurs expériences au travers d'internet tout en preservant le principe d'autonomie: chaque donnée et chaque programme produit par les scientifiques d'un laboratoire restent la propriété du laboratoire et sont maintenus par leurs créateurs. Dans un tel contexte, un premier problème est la publication de ces ressources de façon à permettre leur utilisation par d'autres scientifiques. Ce problème de publication est un problème difficile car il faut fournir un environnement de publication dans lequel les scientifiques puissent spécifier les conditions (parfois complexes) dans lesquelles leur données ou programmes peuvent être utilisés. Une fois ces informations publiées, une deuxième difficulté est la mise au point d'expériences distribuées conbinant l'exécution de plusieurs modèles sur différentes données distribuées sur le réseau. Pour mettre au point de telles expériences il faut trouver les bons modèles, sélectionner les données les plus pertinentes et choisir les bons traitements sur ces données et finalement organiser leur exécution. Les recherches que nous avons effectuées dans ce domaine ont conduit à la mise au point d'un modèle formel pour les workflows scientifiques avec une sémantique déclarative bien définie. Ce modèle distingue trois niveaux d'information. Tout d'abord l'information brute comprenant le code des programmes et le contenu des données directement utilisées par les programmes, deuxièmement l'information contextuelle qui décrit chaque donnée et chaque programme ainsi que les contraintes opérationnelles associées, et enfin le schema du workflow qui décrit le flot de données entre les programmes et leur synchronisation. La mise au point d'expériences avec ce modèle consiste en trois phases. D'abord, l'expérience est spécifiée en definissant un schema de workflow à partir des schema contextuels décrivant les différent types de données et de programmes publiés au travers du système. La deuxième phase est une phase d'instanciation qui permet de choisir les instances de programmes et les données les mieux adaptées à l'expérience; cette phase peut être automatique ou semi-automatique. La dernière phase consiste en l'exécution distribuée des ces programmes sur le réseau. Cette dernière phase est basèe sur l'utilisation du middleware LeSelect.</p> </body>