Closed davidchristiany closed 4 years ago
La maj a été faite avec le data manager sur proteore-migale (09-05-2019).
Super David, peux-tu indiquer la version du fichier de mapping Uniprot utilisé; je souhaite faire des vérifications de cohérence Merci d'indiquer aussi dans la partie USerDoc la version et lien (par ex. pour May 2019 ftp://ftp.uniprot.org/pub/databases/uniprot/current_release/knowledgebase/reference_proteomes/Eukaryota/UP000005640_9606.idmapping.gz) :
Le fichier ayant été produit le 23/10/2018, la current release de l'époque était celle-ci : ftp://ftp.uniprot.org/pub/databases/uniprot/previous_releases/release-2018_08/knowledgebase/
La release en mai 2019 a été créée avec le data manager (pour tester si tout marchait bien), c'est pourquoi il n'est pas dans la doc. Je l'inclus dans la version officielle pour proteore.org ? Si oui, je laisse quand même celle du 23/10/2018 ?
le job plante car il est trop gourmand en ressources, ce n'est pas le mapping des ids qui est en cause mais la création du fichier output. Je vais optimiser l'écriture du fichier résultat pour qu'il écrive ligne par ligne sans garder en mémoire la ligne précédente. Ca devrait corriger le problème
Je pense qu'il faut peut être revoir les ids pour lesquels on garde plusieurs id par ligne (comme GO et OMIM). On arrive à un nombre de ligne abhérants si on garde toute les possibilités en ne gardant qu'un id par ligne. C'est pour cela que la taille de la liste qui contenait toutes les lignes devenait problématique et prenait trop de ressources. Pour le job que tu as lancé, j'en suis à 51 651 533 de lignes et le job n'a toujours pas fini de tourner ... Il fait plus de 49Go, voilà d'où vient ton erreur de place disponible dans ton historique.
Arg, le cauchemar des multi-referencements ! bon, je te propose de n'appliquer la rêgle du 'un ID par ligne' aux ressources suivantes (en pratique, ce sont les ID les plus utilisés) : neXtProt ID (e.g. NX_P31946) UniProt accession number (e.g. P31946) UniProt ID (e.g 1433B_HUMAN) Entrez gene ID (e.g. 7529) RefSeq protein (NCBI) (e.g. NP_003395.1) Ensembl gene ID (e.g. ENSG00000166913) Ensembl transcript ID (e.g. ENST00000353703) Ensembl protein ID (e.g. ENSP00000300161) KEGG gene id (e.g. hsa:7529)
Les autres ci-dessous peuvent être laissés en ID multiples par cellule (séparés par un ";")
GI (NCBI GI number) (e.g. 21328448) Protein DataBank ID (e.g. 2BR9:A) GOterms (Gene Ontology) ID (e.g. GO:0070062) Protein Information Resource ID (e.g. S34755) OMIM (Online Mendelian Inheritance in Man database) ID (e.g: 601289) Unigene ID (e.g. Hs.643544) BioGrid (e.g. 113361) STRING (e.g. 9606.ENSP00000300161)
Qu'en penses-tu ?
Je pense qu'il faut aussi laisser Ensembl transcript ID en multiple ids par ligne mais je peux déjà tester comme ça et voir ce que ça donne avec le même input (ton job).
Le job fini assez rapidement et passe de plus de 100Go à 5,1Go. C'est toujours trop grand, je pense qu'il vaut mieux laisser en multiple ids par ligne et gérer avec les autres outils ce type d'entrée finalement. La question du temps nécessaire pour réaliser cela se pose en revanche. Que fait-on ? @yvandenb @vloux
5 Go semble plus "raisonnable". A mon sens on laisse comme cela (en documentant)
On laisse comme cela, mais c'est une vraie question à laquelle je crois nous avions répondu si je me souviens bien en disant que ce serait aux autres outils d'être en capacité de gérer les cellules à ID multiples...perso je pense que ce serait la solution la plus pragmatique pour éviter ces effets mais elle nécessité de passer en revue tous les outils - peut-on estimer le coût associé à cette revue de code/amélioration (par ex sur la base de ce que tu as fait pour "Get MS/MS obs" tool?)
tools | Handle multiple ids per line in input | modified |
---|---|---|
id converter | yes | |
filter by keywors | non | |
venn diagram | yes | yes |
Heatmap | non | |
add expression data | yes | |
add protein features | yes | yes |
get msms obs | yes | yes |
build tissue specific expression | X | |
Get expression profiles | yes | yes |
add protein features mouse | yes | yes |
statistical analysis of functional profiles | yes | yes |
enrichment analysis for gene ontology | yes | |
go terms classification and enrichment analysis | yes | yes |
query pathway database | yes | yes |
pathways identification | yes | |
pathways visualization | yes | yes |
Build protein protein interaction network | yes |
Tableau récapitulatif des outils que j'ai modifié pour prendre en compte les ids séparés par des ";" sur une même ligne ou dans un copier coller.
Les dernières versions sont disponible sur proteore-migale.
Les outils suivant ont étés mis à jour sur proteore-migale :
Pour ces outils, après une mise à jour avec le data manager, le dernière release est toujours en tête de liste (dans le menu déroulant)
Je n'ai pas modifié get ms/ms observations car le trie par ordre alphabétique est plus adapté.
ProteoRE-migale History: "Test_ID_converter" shared with David and Flo item n° 10 : Header dupliqué-et incohérents et
lié à l'option "header" coché à "No" - to be checked
UserDoc à metttre à jour....qd on est en mode species "souris" les ensembl ID sont notés : ENSMUSG00000031239 et non ENSG00000166913 idem pour ENST et ENSP, corriger l'interface de saisie en conséquence qd on switche d'une "specie" à une autre...idem pour rattus (verifier)
Même History: item n°14
Fatal error: Exit code 1 ()
Traceback (most recent call last):
File "/projet/galaxyprod/proteore2/shed_tools/testtoolshed.g2.bx.psu.edu/repos/proteore/proteore_id_converter/6dfe5e809163/proteore_id_converter/id_converter.py", line 213, in
J'ai mis à jour id_converter sur proteore-migale:
Il n'y aura pas de message d'erreur avec les anciens fichiers ref (ou release). J'ai précisé dans la doc que les anciennes release contiennent tous les uniprot-AC et pas seulement les reviewed.
Merci David d'avoir tenu le timing, on va lancer les tests...
Même History: item n°15
Il y a pas mal de doublons (cf ci-dessous) ? aussi, des choses surprenantes: par ex. ici
ENSMUSG00000047104 | NA | E9QLE5_MOUSE
comment expliquer qu'il y un Uniprot_ID et pas d'uniprot AccNum correspondant ?
de même cette ligne
ENSMUSG00000016239 | NA;Q9D4H7 | LONF3_MOUSE;A2A3U8_MOUSE
un NA en AccNum et LONF3_MOUSE en ID alors que l'AccNum est réferencé dans Uniprot (see https://www.uniprot.org/uniprot/Q9D4H7)?
Il y a bien un uniprot-AC associé : "E9QLE5", mais étant donné qu'il ne fait pas parti des uniprot-AC "reviewed" il n'est pas conservé. C'est pourquoi on ne le retrouve pas en faisant cette conversion. Si on utilise la release 23-10-2018, on retrouve bien l'uniprot-AC correspondant car cette release contient tout les uniprot-AC et pas seulement les "reviewed".
Ci dessous la liste des uniprot-AC reviewed que j'ai récupéré pour la souris : https://www.uniprot.org/uniprot/?query=reviewed:yes+AND+organism:10090&format=list
2 choses:
Dans le fichier Uniprot d'origine: UP000000589_10090.idmapping (de Mai 2019) on a : Q8R3B7 | Ensembl | ENSMUSG00000003778 ET D3YZC7 | Ensembl | ENSMUSG00000003778 de fait, j'imagine que i. D3YZC7 est "unreviewed" car il est reporté "NA" ii. Q8R3B7 a un statut "reviewed" et iii que son ID est BRD8_MOUSE...le "NA" ne devrait pas apparaitre, non ?
En effet les NA ne devrait pas apparaitre, c'est corrigé. En ce qui concerne les lignes doublons, cela vient de l'input qui contient des doublons. Je peux faire en sorte de supprimer les lignes doublons en sortie cependant. On part là dessus ?
OK pour les "NA", on va tester...pour les doublons, c'est donc logique si l'input contient des lignes doublonnées; ok pour la suppression des lignes doublonnes (seulement si l'intégralité de la ligne (i.e. toutes les colonnes) est dupliquée...merci David...
Je n'ai pas encore mis à jour sur proteore-migale
j'ai mis à jour id converter sur proteore-migale
Pour rappel, chaque entrée Uniprot possède 2 identifiants; Un UP Accession Number (e.g. P09876) et un Uniprot_ID (e.g. AMYB_HUMAN); avec la nvelle release des amppings, on ne gère que les "reviewed", on devrait donc avoir 1 UP_AccNum associé à 1 UP_ID; or pour le moment ci-dessous: En ne considérant que les entries "reviewed" on devrait avoir une relation one-to-one pour chaque duplet [AccNum-UP_ID]; cela suggère que les UP_ID "unreviewed" sont tjrs présents pour le moment...to be fixed...
J'ai mis à jour le data manager et généré un nouveau fichier ref pour id converter sur proteore-migale. Les uniprot-ID associés a des uniprot-AC non reviewed ne sont plus affichés.
Dites moi si c'est bon pour vous, une fois validé je mettrais la release 13/09/19 (Human, Mouse, Souris) dans le dossier de l'outil id_converter.
Merci David ! :-) Tests en cours sur les 3 species pour le coup for final validation (roulements de tambours) et réponse d'ici mardi je pense pour déploiement complet sur Proteore.org En attendant pourrais-tu mettre àjour le xml partie USerDoc, parag
Mis à jour sur proteore-migale
Sur migale-proteore: History "Test_ID_converter" Test sur un jeu d'ID souris (Wilson-foie-souris-up.txt) : item n°26 conversion UP_AccNum -> UP_ID Un certain UP_ID sont retournées comme 'NA'; alors qu'en pratique ces UP_ID existent bel et bien dans le fichier de mapping MOUSE_10090_idmapping_selected.tab (last_release) ; par ex : Q9D566 | Q9D566_MOUSE Q3V3U0 | Q3V3U0_MOUSE Au total sur 145 UP_ID sur 231 sont renvoyés "NA" alors qu'il semble être présent ds ce fichier source (je n'ai pas tout vérifié) : d'où ma question : quel fichier prends-tu pour faire les mappings ? Autre test: Pour le Rat : OK (cf item n°30); pour Homo sapiens:
A corriger ds:
Parameters .xml Mettre en correspondance ce qui est indiqué comme release et ce qui est donné dans la seciton USerDoc (cf ci-dessous)
Userdoc section .xml:
INPUT:
Replace "The number limit of IDs allowed in copy/paste is 5000." by "in copy/paste mode, the number of IDs considered in input is limited to 5000"
"Data sources (release date)":
"HUMAN_9606_idmapping_selected.tab (Uniprot 23/10/2018): ftp://ftp.uniprot.org/pub/databases/uniprot/current_release/knowledgebase/idmapping/by_organism/" les url indiqués ne sont pas les bons; tu parles d'une release 23/10/2018, si on clique on trouve la release actuelle come explicitement indiqué par l'URL :-/
idem pour le lien "Human uniprot-AC entries reviewed." qui correspond à l'instant temps t où tu cliques pas à la date où tu les as récupéré...merci d'indiquer les liens et dates exacts
Je poursuis les vérifs de conhérence...
Il est normal que tu ne retrouves pas tout les UP_ID comme auparavant car j'ai retiré les uniprot-ID correspondant aux uniprot-AC non reviewed comme convenu.
J'ai modifié la doc de l'outil (proteore_migale), il y a maintenant des liens pour toutes les releases concernant les Uniprot-Ac reviewed. Tu peux vérifier, les unirpot-AC qui n'ont pas de correspondance ne font pas parti des reviewed.
Si tu relance le même job avec la release du 10/10/2018 tu auras la correspondance car cette release contient tous les uniprto-AC (pas eulement les reviewed).
Tu peux vérifier, les unirpot-AC qui n'ont pas de correspondance ne font pas parti des reviewed.
Merci David, c'est clair désormais 👍 - Flo: il faudra à terme que l'on tranche de l'interet à ne gérer que les reviewed ou rajouter l'option (AccNum reviewed + unreviewed) - typiquement avec le dataset test souris -Wilson que j'ai utilisé, on perd 2/3 des IDs... Pour le USerDoc c'est OK pour moi, David => tu peux (enfin) déployer sur proteore.org, merci pour ta persévérance
J'ai déployé ID_converter et la dernière version du data manager sur proteore.org
Je laisse l'issue ouverte car 2 points en suspens pour discussion:
Mettre à jour les fichiers refs pour la convertion des ids avec la release du 10 avril.