new specs document: “Retrieve tissue expression information from “Human Protein Atlas” (HPA)”

[yvandenb]

...uploaded on bioproj at the following URL: https://bioproj.extra.cea.fr/redmine/projects/proteore/repository/changes/Use_Cases_ProteoRE/UseCase1_HumanSampleProteomeBioanalysis/RetreiveInfoFromHPA_Specs_YV_20170804.pptx To be developped once bugs related to all components (useCase1) have been fixed

[NguyenLien]

I'm a little confused.. this one is the update of HPA filter or Get Data component?

[yvandenb]

Soory for that Lien, you're right! Indeed, the naming of these two components is clearly confusing as the name of a given component must be self-explicit, indicating what it does to the end-user! I thus propose to rename them like this: Component n°1. proposed name "Retrieve tissue annotations on gene level from Human Protein Atlas" (formerly called "Filter your data with HPA information") - this component relies on information contained in the "proteinatlas.tab" file (http://www.proteinatlas.org/download/proteinatlas.tab.gz) and allow to collect/append HPA annotations based on RNAseq and Antibodies assays data to your protein list (see user documentation in the pptx document) Component n°2. proposed name "Sort/Filter your protein according to their tissue expression profiles (formely called "Retrieve tissue/cell distribution (resource: Human Protein Atlas) Filter by tissue name (using Human Protein Atlas resource) ") - this component relies on information contained in the "normal_tissue.csv file (http://www.proteinatlas.org/download/normal_tissue.csv.zip) which correspond to expression profiles for proteins in human tissues based on immunohistochemisty using tissue micro arrays. This component (which works correctly) is expected to evolve and new specs will be sent to you... Hope I've made it clear for now ? you opinion?

[NguyenLien]

In fact these 2 components is confusing because for now we only defined the resource of HPA for Get Data component, but the purpose of Get Data is to collect data from different resources (in additional to HPA, we want data from neXtProt/UniProt too). So when we define other resources, it will be clearer (and the name won't be related to HPA only).

[yvandenb]

Absolutely, this is the idea! The mid-term goal is actually to make this component as generic as possible; nevertheless, considering the dvpt process, we are not able at the moment, to anticipate how this final tool should look like, behave and how easy it would be to make it suitable for every data source...this is why I'd suggest in the meantime, to proceed like this; an important point we must estimate is how costly it would be in terms of programming ? Any suggestion, Lien?

[NguyenLien]

For Get Data component, we can propose to users different resources, for each resource chosen, we have different parameters. The ones for HPA can be kept as your suggestion in this document, and we build other parameters for other resources. Programming time depends on what information we need to collect, and if we how can we collect them. So what we need to do first is to define which information we want to collect from which sources. Don't worry about how to make it suitable for every data sources because we can create different parameters for each source (from "select" parameter).

[yvandenb]

At the moment only two public resources have been identified: HPA and neXtProt. What we could do would be to build upon these two resources to design a first version of a "Get data component". In addition, as Lisa already developed on her side a tool for neXtProt (see the "Retrieve information from public databases" tool listed at the bottom of the tools panel), it should be easy to reuse some part of the code and flat files containing data retrieved by Lisa via the nextprot's REST API. So I propose to draw new specs for this tool for further discussion with Lisa and you; agree?

[NguyenLien]

44