Open abretaud opened 6 years ago
Hi- OK, yes this is something we will need to figure out how to handle gracefully in the short term. The tree module has a multiple-sequence-alignment viewer that is nicely integrated with the tree; in general, we are storing the MSAs that are the basis of the tree but I can see that not everyone is going to want to do that. And, as you point out the service that is providing the MSA data is based on some work we were doing before adopting tripal, so we probably ought to: a) make use of MSAs optional for users of the tree module (hopefully not too hard to accomplish) b) make use of MSAs possible for users of the tree module who want to store them in chado for this purpose, but want to stick to using tripal as their framework
I need to do some work on our strategy for storing MSAs soon anyway, so might be able to tackle b) then. But let me know if a) is what you were imagining and if you want to try contributing a patch for that I'd be happy to have it (not sure I'll be able to work on it very soon, though I might be able to enlist someone from my group who is more competent in such things)...
Ok, thanks for the clarification! I'll see if I can write a quick patch for a), but I'll need to display MSA too so b) would be really nice
I guess you're currently using gmod_load_msa.pl
script to load them in the other service? Do you think you'll still use it for b)?
OK, it's good to know you want to handle MSAs too; for b) I was thinking to keep using the perl script as a loader, but switch the database retrieval to using the tripal chado api and then dumping to json.
I should note that I need to work out some issues with the representation of MSAs in chado- currently due to constraints on the featureloc table we are limited to having a sequence belong to at most one MSA, and this is starting to be a problem for us as we plan to move to providing support for multiple gene family definitions- we can support trees for alternate groupings, but currently we can only store one MSA for a sequence. I think there may be an easy workaround that wouldn't involve changes to chado, but I have to find time to work on it. I'm guessing this won't be an immediate concern for you, but thought I'd mention it. It would also be nice to move to using CIGAR to store the alignments, but currently we are doing things using gapped residues in the featureloc- it's easy but not very space-efficient. Not a high priority for us yet...
Ok, that's great plans, I'll see if I can help on some tasks. I'll need to have support for multiple family definitions too at some point, so if you want me to test your workaround I can :)
Now that I've found a workaround for #25, I have this error when I try to display a tree I have loaded in the db:
It looks like it tries to get data from another webapp, like https://legumeinfo.org/lis_gene_families/chado/msa/phytozome_10_2.59086800-consensus/?
Is this mandatory or not? It's not clear to me what are the relations between this tripal module and https://github.com/ncgr/lis_gene_families/ (which seems to be the webapp hosted at https://legumeinfo.org/lis_gene_families/chado/)