monarch-initiative / phenogrid

The phenogrid widget
13 stars 14 forks source link

Allow loading of json directly into phenogrid #233

Closed kshefchek closed 8 years ago

kshefchek commented 8 years ago

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

  1. Send entire json object to phenogrid and display
  2. Send skeleton json structure to phenogrid, compare using owlsim, and display.

@yuanzhou perhaps this is in line with what you are working on with the impc branch?

harryhoch commented 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?

yuanzhou commented 8 years ago

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.

harryhoch commented 8 years ago

@yuanzhou yes, we can certainly discuss

julesjacobsen commented 8 years ago

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>
yuanzhou commented 8 years ago

@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.

harryhoch commented 8 years ago

@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?

yuanzhou commented 8 years ago

@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.

harryhoch commented 8 years ago

@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?

yuanzhou commented 8 years ago

@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.

julesjacobsen commented 8 years ago

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.

yuanzhou commented 8 years ago

@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.

julesjacobsen commented 8 years ago

I think this can be closed now.