Actions
Feature #488
open
Allow non-nsSNP variants
Story points:
-
Description
Need to stop restricting database to nsSNP variants.
- Support lookup/create by dbSNP id
- Support lookup/create by {chromosome, position, ref_seq, variant_seq}
- Is "strand" helpful? Or should "chr1:1234:-:A:C" just be described as "chr1:1234:T:G"?
- How to deal with different references?
- Include a reference identifier in database key -- "hg18:chr:pos:refseq:varseq"
- Extend database schema to include multiple identifiers per locus, so "hg18:chr1:1234" and "hg19:chr1:1235" can map to the same variant ID
- Ensure only one page per variant. E.g., if rs1234 maps to chr1:1234:T:G and causes ABCD-A1T, then there should only be one GET-Evidence page regardless of which order those identifiers are looked up / used to create a page.
Updated by Tom Clegg over 14 years ago
dbSNP rsid's can now be used by import robots. Non-nsSNP variants have been imported from PharmGKB and HuGENet GWAS.
In order to allow GET-Evidence to show genome hits for these variants, Trait-o-matic's "/browse/allsnps" report now includes all GET-Evidence hits -- even the "uninteresting" ones that don't appear on the Trait-o-matic result pages -- in addition to nsSNPs.
Updated by Tom Clegg over 14 years ago
Need to prevent redundant entries -- for example, PharmGKB citations were attached to http://evidence.personalgenomes.org/rs1142345 instead of http://evidence.personalgenomes.org/TPMT-Tyr240Cys
Updated by Ward Vandewege almost 14 years ago
- Project changed from 19 to GET-Evidence
- Category deleted (
GET-Evidence)
Updated by Madeleine Ball almost 14 years ago
- Priority changed from High to Normal
Actions