gcv
gcv copied to clipboard
legumeinfo
Gene family accessions meaningless
Is there a way to show gene family definitions, or to otherwise give some clue as to the putative function of a family of genes? Knowing that one is looking at, for example, a cluster of disease resistance genes, or some other cluster of genes of similar function would be valuable.
for now the best way to do this is to click on the family in the legend and follow the link that is offered to the phylotree. However, we have discussed in past bringing family descriptors into the GCV proper, and I agree it would preferable to have the functional info better integrated. It will probably happen under the auspices of #63
This issue is stale. Closing.
If anyone is still interested in pursuing this, perhaps it could be wrapped into Epic #63.
FIg 5 of https://apsjournals.apsnet.org/doi/full/10.1094/MPMI-07-18-0198-FI?url_ver=Z39.88-2003&rfr_id=ori:rid:crossref.org&rfr_dat=cr_pub%20%200pubmed suggests we should still pursue this
one relatively easy approach might be to follow the model of the gene popovers and add such for gene families, allowing a service call to produce descriptive info content (similar to the way positional info is being retrieved on demand for the genes)
@adf-ncgr Can you elaborate, i.e. would these data come from a linkout type of service or would they be a core data type that GCV handles. Genes are well defined entities in the GCV database. This is what's dynamically loaded when you mouse over a gene. Families, however, are just meta used for search and alignment. They could be expanded into their own type if need be. The transition to microservices would be a good time to do that.
I was imagining this to be a linkout type of service, ie one that GCV knows how to use if configured, but not one that is part of its core. One could have a similar service for genes, to load descriptive info on demand. One issue with the families is that they don't "belong" to any specific datasource, so while it would be clear whose gene description service to call, it would be ambiguous whose family description service to call (unless we simply made that be a service that stood apart from the datasources). Suffice it to say I haven't thought this through all that much. But, I think we probably agree that the core data model should be kept minimal unless there's a compelling reason to extend it.