Closed nlwashington closed 10 years ago
for the API definitely getPathwaysForGene(gene_id); getPathwaysForDisease(disease_id);
I can do getGenesForPathway(pathway_id,species); using nif directly
Would these api calls be in the monarch-ui bbop engine or elsewhere?
In api.js - it's then trivial to make it available via REST in webapp.js, e.g. /pathway/gene/:gene_id.json
On Mon, Jan 6, 2014 at 7:12 AM, Jeremy Espino notifications@github.comwrote:
for the API definitely getPathwaysForGene(gene_id); getPathwaysForDisease(disease_id);
I can do getGenesForPathway(pathway_id,species); using nif directly
Would these api calls be in the monarch-ui bbop engine or elsewhere?
— Reply to this email directly or view it on GitHubhttps://github.com/monarch-initiative/monarch-app/issues/31#issuecomment-31655093 .
I will implement all three. We want to make sure that all our tools make use of our own api's, and don't have to rely on NIF directly (shielding the raw data model from our users, which is basically what the NIF tables are). Eventually we may not have those tables, if we move to triples, anyway.
Ok!
On Mon, Jan 6, 2014 at 12:35 PM, Nicole Washington <notifications@github.com
wrote:
I will implement all three. We want to make sure that all our tools make use of our own api's, and don't have to rely on NIF directly (shielding the raw data model from our users, which is basically what the NIF tables are). Eventually we may not have those tables, if we move to triples, anyway.
— Reply to this email directly or view it on GitHubhttps://github.com/monarch-initiative/monarch-app/issues/31#issuecomment-31668206 .
ok, i started implementing these, but part of me doesn't like it. maybe it's doing the right thing. but what i've noticed all over the place (including functions besides mine) is that although the arguments are stated as "id", it can be anything - an id, a label, whatever. this can lead to some messy results. have a look at what i've done, and perhaps we can review.
Well. I know that you are doing from reading the code so I think this is fine. Refactoring later to make id's explicit by method name or by variable name would work. We can generalize by doing fetchXXX(id, id_type) later on.
I'm in favor of using what you just did at this point
I've now implemented methods to map any query id -> ncbi gene id Which can be subsequently used to lookup the kegg_id, and then kegg ortholog class id, which is what is used in pathways.
A call to fetchGeneInfo() will now look up a gene id in our idmapping table, use the ncbi gene identifier as the basis of the gene, get some basic information about it, and fetch the pathways it belongs to (via the KO ids).
a gene object will look like:
{
"id": "NCBI_Gene:30269",
"mapped_id": "ZFIN:ZDB-GENE-980526-166",
"label": "shha",
"taxon": {
"id": "7955",
"label": "Danio rerio"
},
"references": [
"BioGRID",
"ZFIN",
"NCBI_Gene"
],
"pathways": {
"pathways": [
{
"id": "path:map04340",
"label": "Hedgehog signaling pathway"
},
{
"id": "path:map05217",
"label": "Basal cell carcinoma"
},
{
"id": "path:map05200",
"label": "Pathways in cancer"
}
],
"id": "NCBI_Gene:30269",
"ko_id": "ko:K11988",
"resource": "nlx_31015-3",
"source": {
"id": "nlx_31015-3",
"label": "KEGG"
}
},
"@context": null
}
You have pathways under pathways...
I think the outer one is something like "xref" or "has_pathwaydb_representation"
On Mon, Jan 27, 2014 at 12:53 PM, Nicole Washington < notifications@github.com> wrote:
a gene object will look like:
{ "id": "NCBI_Gene:30269", "mapped_id": "ZFIN:ZDB-GENE-980526-166", "label": "shha", "taxon": { "id": "7955", "label": "Danio rerio" }, "references": [ "BioGRID", "ZFIN", "NCBI_Gene" ], "pathways": { "pathways": [ { "id": "path:map04340", "label": "Hedgehog signaling pathway" }, { "id": "path:map05217", "label": "Basal cell carcinoma" }, { "id": "path:map05200", "label": "Pathways in cancer" } ], "id": "NCBI_Gene:30269", "ko_id": "ko:K11988", "resource": "nlx_31015-3", "source": { "id": "nlx_31015-3", "label": "KEGG" } }, "@context": null }
— Reply to this email directly or view it on GitHubhttps://github.com/monarch-initiative/monarch-app/issues/31#issuecomment-33421401 .
fixed pathways under pathways. now is:
{
"id": "NCBI_gene:30269",
"label": "shha",
"description": "sonic hedgehog a",
"taxon": {
"id": 7955
},
"source": "MyGene",
"pathways": [
{
"id": "path:map04340",
"label": "Hedgehog signaling pathway",
"source": {
"id": "nlx_31015-3",
"label": "KEGG"
}
},
{
"id": "path:map05217",
"label": "Basal cell carcinoma",
"source": {
"id": "nlx_31015-3",
"label": "KEGG"
}
},
{
"id": "path:map05200",
"label": "Pathways in cancer",
"source": {
"id": "nlx_31015-3",
"label": "KEGG"
}
}
],
"type": "gene",
"@context": null
}
I have built several views in DISCO that we can now query via services, in order to build the JSON necessary to paint our pathway diagrams.
The nif views from KEGG (in beta) are:
disease-to-pathway mappings (also contains omim mappings for disease identifiers) http://beta.neuinfo.org/mynif/search.php?q=*&t=indexable&nif=nlx_31015-2 (canonical) pathway to KO (kegg ortholog) class http://beta.neuinfo.org/mynif/search.php?q=*&t=indexable&nif=nlx_31015-3 KO to species gene map (orthology map).
http://beta.neuinfo.org/mynif/search.php?q=*&t=indexable&nif=nlx_31015-4
If I am missing something, please let me know!
What this also means is that we also have enough information to have any kind of pathway page. Do we dare make those too?
Jeremy, what kind of API calls do you need? Please define them here. My guess is:
getGenesForPathway(pathway_id,species); getPathwaysForGene(gene_id); getPathwaysForDisease(disease_id);
the two above could generically call getPathwaysForID(id) but then we'd need an id-to-type resolver
This would be a function that will wrap whatever data we have...presently will be hardcoded to KEGG, but can wrap wikipathways at somepoint too.