Closed kshefchek closed 8 years ago
yes, this is on our list. @yuanzhou, this shouldn't be too hard, right? @kltm, this is what you need as well, right?
Thanks for the suggestion @kshefchek, I'll work on this. It does sound similar to the IMPC integration.
@harryhoch, I'll probably need more of your input since it sounds like there are some discussions around this topic during the meeting.
@yuanzhou yes, we can certainly discuss
This should absolutely be a top priority to fulfill the 'generic reuse' requirement. Giving people vendor codes and writing custom loaders for them is really going to make your life hell ;)
<script>
window.onload = function() {
// IMPC testing
Phenogrid.createPhenogridForElement(document.getElementById('phenogrid_container'), {
serverURL: "http://monarchinitiative.org",
dataFromVendor: true,
dataVendorName: 'IMPC',
dataVendorQueryValue: {
disease: 'OMIM:101600',
gene: 'MGI:95523'
}
});
}
</script>
@julesjacobsen there are things we can do to minimize the use of custom loaders for vendor data. But as long as the vendor data doesn't follow the same schema/convention/format, we still need custom loaders. Please let me know if you have any good suggestions based on the IMPC integration.
@yuanzhou, I think we should start with handling data that passed in thorugh the usual phenogrid format.
As I see it, the change would be like this. Right now, we have
Phenogrid.createPhenogridForElement(document.getElementById('phenogrid_container5'), {
serverURL : "http://beta.monarchinitiative.org",
phenotypeData: phenotypes,
targetGroupList: [
{name: "Homo sapiens", taxon: "9606", crossComparisonView: true, active: true},
{name: "Mus musculus", taxon: "10090", crossComparisonView: true, active: true},
{name: "Danio rerio", taxon: "7955", crossComparisonView: false, active: true},
{name: "Drosophila melanogaster", taxon: "7227", crossComparisonView: true, active: true}
]
});
This could be changed to
Phenogrid.createPhenogridForElement(document.getElementById('phenogrid_container5'), {
serverURL : "http://beta.monarchinitiative.org",
similarityData: {.... a JSON blob with structure identical to what we get back from simsearch...
}
});
Or something like that. @julesjacobsen, @kshefchek, would that do the trick for you?
@harryhoch are you suggesting not to allow users to specific the target species as well as if that species should appear in the cross-comparison view? That targetGroupList
controls what species we want to display and if each one needs to be in the cross-comparison view.
A similar thought: by default we can just load data for all species and show them all in cross-comparison view, and users can decide if they want to turn any species off from the comparison view. This would make the config simpler as well.
@yuanzhou - no we can include the target species there, that's fine.
I think the point that @julesjacobsen and @kshefchek are looking for is that we should have a means of populating the grid without ever calling against the monarch server, if the client wants... ok?
@harryhoch I agree. Both options that @kshefchek suggested are great. And the skeleton JSON structure/schema can also be used as a format validator of the incoming data. This would certainly pass the data loading and formatting to the users and make the phenogrid rendering faster.
The second option that @kshefchek suggested was exactly what I was originally trying to suggest that you did. The whole point of giving you the skeleton json structure was that it gave you a skeleton json structure with which to build the grid and then populate using the compare API.
This is how I was though would be a super-easy way for any developer to drop data in to the phenogrid without you having to write a new vendor import:
var skeletonJsonData = functionToCreateSkeletonJson();
Phenogrid.createPhenogridForElement(targetElement, {
serverURL: "http://monarchinitiative.org",
grid: {
gridAxes: skeletonJsonData,
//Not entirely sure how many people wouldn't want to call the monarch API as that's kind of the point of the phenogrid, otherwise its just a grid...
useMonarchCompareApi: true
}
});
The whole concept of species is only relevant to the Monarch page and should be abstracted away to something like 'pheno group' or maybe just plain old 'group'.
Yes, the only way to do this is to fundamentally change the internals of the phenogrid to make it generic. The only hard requirements you have is that there is a group of phenotype ids being compared against another group of phenotype ids.
@julesjacobsen thanks for the suggestion. I'm working towards this goal. Using the skeletonJsonData directly will also eliminate the needs of having a gene ID and disease ID to be provided via the constructor in terms of the IMPC integration.
I think this can be closed now.
There may be some use cases where a client would generate a JSON object and directly pass this into phenogrid, ideally via a lightweight API. The two use cases would be
@yuanzhou perhaps this is in line with what you are working on with the impc branch?