OncoBase

De Challenge4Cancer
Aller à : navigation, rechercher

Le projet

Introduction

Le cancer étant une problématique complexe hautement multiparamétrique, les approches statistiques qui lui sont liées s'appuient généralement sur un corpus de données étendu prenant en compte un très grand nombre de facteurs. Le site http://data.epidemium.cc regroupe à ce titre des dizaines de milliers de liens vers des bases de données en rapport avec le cancer : facteurs environnementaux, études locales, suivi temporel, données génétiques... La littérature scientifique est également abondante sur le sujet et regorge de données statistiques sur ce dernier. Cependant toutes ces données sont disponibles dans des formats et sur des plateformes très hétérogènes.

Description

Le projet Epidemium OncoBase vise à produire une base de données unifiée pour la communauté Epidemium, mêlant des données issues de sources diverses et variées, et permettant de construire des analyses statistiques solides. Suivant son avancement, le projet pourra lui même proposer des analyses sur la base de données qu'il aura produite, même si il ne s'agit pas là de son objectif originel. L'originalité du projet tient dans le fait que la base de données unifiée sera produite de façon algorithmique, grâce à de l'analyse syntaxique des documents. En effet, au lieu de traiter manuellement des dizaines de milliers de jeux de données et des centaines de milliers d'articles scientifiques, les algorithmes mis en oeuvre seront capable de rechercher automatiquement les données sur internet, les télécharger, les analyser, et les mettre en forme pour les intégrer à la base de données unifiée, favorisant ainsi une approche du problème dans toute sa complexité.

Liens

Normes et conventions

Nom du projet

  • Dans un contexte uniquement textuel, le nom du projet est Epidemium OncoBase. Le préfixage Epidemium est important dans la mesure ou le nom OncoBase existe déjà.
  • Dans un contexte informatique (nom de fichier, nom d'utilisateur, lien web...), le nom du projet est epidemium_oncobase.
  • Si toutefois l'underscore _ n'est pas disponible, alors il est remplacé par un tiret -.

Langues

  • Dans un contexte informatique (nom de fichier, nom d'utilisateur, lien web, code, documentation...), la langue utilisée est l'anglais.
  • Dans un contexte de contenu multimédia (page du projet, texte, vidéo, infographies...), et dans la mesure ou la langue utilisée par Epidemium est le français, l'anglais ou le français peuvent être utilisés.
  • Dans un contexte d'échange et de communication, l'anglais ou le français peuvent être utilisés.

Licence

Noms de dossiers, fichiers et pages web

Pour maximiser l'interopérabilité des ressources entre plateformes, les noms de dossiers, fichiers et pages web crées dans le cadre du projet sont au format lower_case_with_underscores en anglais.

Développement

Le langage de référence du projet est Python 3.4. Pour les parties du projet nécessitant un maximum de performances, les langages C11 et C++11 peuvent être utilisés à la marge pour produire des exécutables ou des bibliothèques qui seront appelées par Python. Pour éviter de s'arracher les cheveux sur les conventions de développement, le projet se base sur les conventions utilisées dans le cadre des développements officiels des langages sus-mentionnés :

Suivant les langages, et les règles officielles, les conventions de nommage suivantes peuvent être adoptées : lowercase, lower_case_with_underscores, UPPERCASE, UPPER_CASE_WITH_UNDERSCORES, CamelCase et mixedCase. En complément l'ajout d'underscores pour des variables ou des fonctions spéciales peut être utilisé : _single_leading_underscore, single_trailing_underscore_, _single_leading_and_trailing_underscores_, __double_leading_underscores, double_trailing_underscores__ et __double_leading_and_trailing_underscores__.

Comme suggéré par les conventions Python, 4 espaces seront privilégiés face à 1 tabulation pour l'indentation. D'autre part, les systèmes Unix-like servant de plateforme par défaut à ce projet, LF sera utilisé pour encoder les sauts de ligne. Enfin, l'architecture considérée par défaut dans le cadre de ce projet est une architecture 64-bits little-endian.

Brainstorming

Ci-dessous une première proposition des différentes étapes nécessaires à la production de la base de données.

Database production steps.png

Suite de nos réflexions

« Depuis 2005, la loi relative à la liberté d'accès aux documents administratifs et à la réutilisation des informations publiques, prévoit la possibilité de réutiliser les informations publiques à d’autres fins que celles pour lesquelles elles sont détenues ou élaborées. En conformité au principe général de réutilisation libre, facile et gratuite fixé par les circulaires du Premier ministre du 26 mai 2011 et du 13 septembre 2013 relatives à l’ouverture des données publiques, Etalab est engagée à promouvoir la réutilisation des données publiques ouvertes par le biais d’actions spécifiques.[1] »

Selon ces extraits du site data.gouv, de nombreuses sources de données sont réunies et répertoriées au sein d'un même site web.


Les sources de données qui sont accessibles sont ainsi devenues multiples et extrêmement variées. Les données ainsi accessibles sont hétérogènes et volumineuses. Cela peut nous amener à utiliser dans cet exercice le terme Big Data pour la mise en œuvre de ce type de base de données.

Dans le cadre des approches Big Data on manipule non pas un échantillon représentatif d’une population donnée, mais de grands volumes de données concernant cette population. Au regard des quantités, on peut être amené à tolérer des valeurs inexactes en présumant que celles-ci seront équilibrées par la masse. On devient moins exigeant vis-à-vis de l’exactitude.


D'ailleurs lorsque l’on évoque un projet Big Data, volume de données et variétés sont rapidement mentionnés, mais la qualité et la traçabilité de ces données viennent moins spontanément dans les discussions. Pourtant, l’inquiétude est bien réelle dans les esprits puisque selon une étude menée en mars 2015 par l'organisme Experian, 92% des entreprises ont le sentiment que leurs bases de données clients comportent des erreurs : champs incomplets, mauvais formats, erreurs de mise à jour, doublons, etc.

Parmi les sites de données en licence libre accès, la donnée brute est souvent de qualité moyenne (informations manquantes, libellés à harmoniser...), ou doit être enrichie (par exemple en transformant un code postal en coordonnées GPS), ou encore jointe à d'autres données (par exemple en divisant le tonnage de déchets par le nombre d'habitants), avant de pouvoir la traiter, notamment au travers d'un outillage pour les data-visualisations. Parfois, elle doit être extraite de documents fermés, et nécessite par exemple d'extraire des données PDF ou d'extraire des données tabulaires à partir de pages Web.[1] (source DataGouv https://www.data.gouv.fr/fr/faq/reuser/). Les données se présentant souvent en séries incomplètes, par année, par département, la première opération consiste à fabriquer des ensemble de données (ou fichiers) complets. Il existe des outils en libre accès pour aider à cette opération comme OpenRife. Ces outils restent limités sur le traitement en masse d'un grand volume de données.

Notre contribution au challenge pour le Cancer était d'expérimenter si l'exploitation des données Open source ouvrirait la perspective de découvrir de nouveaux facteurs de risque du cancer.

Le projet OncoBase, s'est concentré sur l'objectif de constituer une base de données de haute qualité, réutilisable par tous les autres projets. L'idée est de collecter les données  :

  • automatiquement afin d'éviter les erreurs et les oublis de récupération de données en manuelle.
  • en conservant l'identification de l’origine (trace de la source) avec l'objectif de gérer le suivi de la donnée durant tout son cycle de vie (notamment les données supprimées)

Notre problématique consiste à se demander si le grand volume des données à notre disposition peut être géré sans perdre de l'information. Par ailleurs, nous avons la possibilité de collecter des données de différents pays, différents organismes avec des fichiers de formats variés. Il se peut également qu'on ait à faire face, selon les pays, à des questions de conversions de métriques, standards...

L'objectif final étant de minimiser tant que possible les erreurs d’interprétation et d'exploitation qui parviennent lors de collectes de données. Pour cela, nous avons réfléchi à des procédures automatiques visant à :

  1. forme des fichiers
    • Nettoyer (supprimer les fichiers vides, ou en doublons)
    • Trier (les fichiers de données selon leur extension)
    • Classer les fichiers (selon leur titre, organismes)
    • Regrouper (indexer les fichiers par mots-clés)
  2. structure des fichiers
    • Identifier les métadonnées (en tête ou structure xml, json, etc)
    • Rapprocher et regrouper sémantiquement les métadata.

Les scripts python et les programmes C++ du projet nous ont permis la récupération de données suivantes :

  • d'articles de recherches
  • tableau d'indice de mortalité par cancer rester / type de cancer par population *
  • data.gouv.fr

Une première réalisation de mi-parcours a permis de récupérer des articles « open » du site PubMed en lien avec le cancer et de procéder à une analyse statistiques sur les termes.

Fin du projet... A suivre !

Le projet OncoBase a pour vocation de continuer. Pour la prochaine étape notre objectif est, entre autre, l'analyse de ces volumes de données tout en s'appuyant sur l'intelligence

des ontologies de domaines.
  1. 1,0 et 1,1 data.gouv.fr