Accessibility Tools

- Le blog participatif de bioinformatique francophone depuis 2012 -

Les identifiants : a (name)space oddity

Sur Bioin​fo​-fr​.net, nous avons plu­sieurs fois par­lé des bases de don­nées bio­lo­giques. Que ce soit du point de vue de la ges­tion, de l'exploitation ou même du sto­ckage phy­sique. J'aimerai reve­nir aujourd'hui sur un sou­ci qui se pré­sente sou­vent lors de l'exploitation de plu­sieurs bases de don­nées : les iden­ti­fiants.

Un objet bio­lo­gique dans une base de don­nées est repré­sen­té par un iden­ti­fiant. Cet iden­ti­fiant est unique du point de vue de la base consi­dé­rée. Mais com­ment faire le lien entre des iden­ti­fiants venant de dif­fé­rentes bases de don­nées ? Et sur­tout, com­ment être sûr qu'ils repré­sentent bien le même objet bio­lo­gique ?

clone_army_by_riser38-d5rnslr
by riser38 (CC BY-NC-ND 3.0)

Dans le cadre de mon tra­vail, j'ai eu à faire l'union de deux réseaux méta­bo­liques. L'un basé sur les iden­ti­fiants de la base Meta­Cyc, l'autre sur les iden­ti­fiants de la base KEGG. Sachant que dans Meta­Cyc, il y a des liens vers KEGG, j'ai sim­ple­ment récu­pé­ré les fichiers four­nis par Meta­Cyc et j'ai écris un pro­gramme qui lit un réseau méta­bo­lique, récu­père les iden­ti­fiants et les cherche dans les fichiers Meta­Cyc. De cette simple recherche, j'ai fait deux obser­va­tions.

La pre­mière était que cer­tains iden­ti­fiants du réseau pro­duit à par­tir de Meta­Cyc n'étaient plus dans la der­nière ver­sion de Meta­Cyc. Il y avait donc un pro­blème de mise à jour des iden­ti­fiants. La deuxième était que seule­ment 1564 iden­ti­fiants KEGG sur 2553 étaient pré­sents dans Meta­Cyc. Il y avait donc un pro­blème de lien entre les bases de don­nées.

Cela m'a conduit à cher­cher si des solu­tions exis­taient pour résoudre ce genre de pro­blèmes. Et il en existe beau­coup… mais avant de par­ler de ces diverses ini­tia­tives, par­lons du pro­blème à résoudre.

L'hétérogénéité des identifiants, des formats, des données.

Les don­nées bio­lo­giques, comme beau­coup d'autres don­nées, sont hété­ro­gènes et sur­tout dis­sé­mi­nées dans diverses bases de don­nées, dans divers for­mats, pour diverses uti­li­sa­tions. Cela est une obser­va­tion qui peut être faite dans de nom­breux domaines. J'ai assis­té à une sou­te­nance de thèse en réa­li­té vir­tuelle où ils avaient le même genre de sou­cis avec les dif­fé­rents for­mats de repré­sen­ta­tion 3D, de trai­te­ment des tex­tures, des moteurs de ren­du, etc. Alors, quelque soit le domaine, com­ment résoudre cette hété­ro­gé­néi­té ?

En gros, trois solu­tions s'offrent à nous :

  1. On crée un stan­dard avec un sys­tème d'identifiants uniques et tout le monde s'y tient.
  2. On crée un méta-stan­dard qui per­met de lire chaque don­née dans chaque stan­dard.
  3. On crée un tra­duc­teur uni­ver­sel qui fait juste le lien entre les dif­fé­rents iden­ti­fiants.

Pro­blèmes :

  1. Les stan­dards, il y en a déjà plein (cf xkcd.com-927) et on ne s'y tient pas.
  2. Les méta-stan­dards intro­duisent de nou­veau iden­ti­fiants qu'il faut mettre à jour (donc un nou­veau stan­dard).
  3. Un tra­duc­teur est uni­ver­sel s'il connaît toutes les sources de don­nées… et il y aura tou­jours de nou­velles sources de don­nées (avec de nou­veaux stan­dards).
xkcd (CC BY-NC 2.5)
xkcd (CC BY-NC 2.5)

Sommes-nous donc condam­nés à nager dans un océan de don­nées sans lien entre elles ? J'aurai ten­dance à répondre oui… mais il existe quelques solu­tions.

Différentes initiatives

Je ne vais évi­dem­ment pas faire une énu­mé­ra­tion exhaus­tive des dif­fé­rentes ini­tia­tives. Je vous pro­pose plu­tôt deux solu­tions qui abordent des points qui me semblent per­ti­nents.

The Syner­gi­zer, tout d'abord, est une ini­tia­tive consis­tant à créer un "tra­duc­teur" uni­ver­sel d'identifiants à par­tir de cer­taines sources de don­nées (ncbi, ensem­bl…). Le prin­cipe est d'associer à des iden­ti­fiants de gènes et de pro­téines leurs dif­fé­rents syno­nymes dans d'autres bases de don­nées. La connais­sance des syno­nymes est direc­te­ment extraite des sources. Ils uti­lisent donc une infor­ma­tion venant d'une "auto­ri­té" qu'ils sup­posent vraie. Cela est une approche plu­tôt ration­nelle qui me semble natu­relle. Bien que les don­nées soient hété­ro­gènes, il faut bien faire confiance à quelqu'un.

D'un autre coté, avec cette méthode, nous n'obtenons que ce qui est déjà connu. Une autre approche consiste à essayer de trou­ver des syno­nymes sans connais­sance a prio­ri. C'est ce qu'essaye de faire MNX­ref dans le domaine des réseaux méta­bo­liques (le papier). Ils essayent de "récon­ci­lier" des méta­bo­lites en se basant sur leur struc­ture chi­mique (SMILE, InChi), sur leur nom (en consi­dé­rant les homo­nymes et syno­nymes) mais éga­le­ment sur des réfé­rences croi­sées entre bases de don­nées. Ils essayent éga­le­ment de relier des réac­tions chi­miques en fonc­tions des méta­bo­lites impli­qués et des réfé­rences croi­sées.

Enfin, ces deux approches (comme beau­coup d'autres) sont dis­po­nibles via des inter­faces web ou des API, ce qui les rend très acces­sibles.

Mal­gré ces ini­tia­tives et de nom­breuses autres, un papier paru l'année der­nière (lien) montre que nous ne sommes pas au bout de nos peines. Les auteurs ont choi­si de s'intéresser au cycle TCA chez l'humain. Ce cycle est par­ti­cu­liè­re­ment bien étu­dié depuis de nom­breuses années. Ils ont extrait ce cycle dans 10 bases de don­nées de réseaux méta­bo­liques. Sur ces dix réseaux, aucun n'était cor­rect par rap­port à la lit­té­ra­ture et en plus ils n'étaient d'accord que sur trois réac­tions.

By Yikrazuul (CC-BY-3.0)
By Yikra­zuul (CC-BY‑3.0)

Cela prouve com­bien l'expertise manuelle est encore néces­saire dans la mise à jour et la cor­rec­tion des bases de don­nées. Dans cet objec­tif, les auteurs pro­posent d'ailleurs l'utilisation mas­sive d'un sys­tème type Wiki (Wiki­Pa­th­way), afin que les cor­rec­tions puissent être sou­mises, vali­dées ou inva­li­dées par la com­mu­nau­té scien­ti­fique.

Conclusion

Pour conclure, après quelques mois à nager dans les don­nées, je pense qu'une solu­tion pérenne vien­dra d'une approche qui réuni­ra les trois aspects :

  • exploi­ta­tion des liens exis­tants entre bases de don­nées pour construire sur ce que nous savons déjà ;
  • décou­verte auto­ma­tique de nou­veaux liens ;
  • vali­da­tion par exper­tise manuelle.

En espé­rant que vous n'êtes pas trop déses­pé­rés par cet océan de don­nées, n'hésitez pas à nous faire part de vos com­men­taires sur ce sujet.

Mer­ci à Yoann, Julien et Syl­vain pour leur relec­ture.

Vous avez aimé ? Dites-le nous !

Moyenne : 0 /​ 5. Nb de votes : 0

Pas encore de vote pour cet article.

Partagez cet article



Pour continuer la lecture :


Commentaires

2 réponses à “Les identifiants : a (name)space oddity”

  1. Inté­res­sant, pen­sez-vous qu'un pro­to­cole comme SPARQL puisse être à la base d'une solu­tion ?

    1. Oui 🙂

      Je tra­vaille d'ailleurs à inté­grer les dif­fé­rentes infor­ma­tions dans une base de don­nées en graphe (avec tri­plets rdf) que j'interroge ensuite avec des requêtes SPARQL.

Laisser un commentaire

Pour insérer du code dans vos commentaires, utilisez les balises <code> et <\code>.