Menu
▾
▴
Re: [GUSDEV] using VirtualSequence for scaffolding assemblies (not EST assemblies!)
|
From: Aaron J. M. <am...@pc...> - 2005-07-14 15:13:47
|
Thanks Chris, I got it. If we are going to start hanging features off these, should we hang them off the virtual chromosome sequence entries, or the scaffold entries in externalnasequence? Would it make sense to "codify" this usage with associate PL/SQL code to reconstruct virtual sequence and associated features in the virtual coordinate space? I guess one way to do this would be to have Virtual*Feature read-only views (and thus target everything to the "real" coordinate system such that future rebuilds of the virtual sequence would not require recalculation of feature locations)? Relatedly, is there coordinate mapping code already in some GUS utility module (if not, I'm happy to contribute mine, based on BioPerl's powerful Bio::Coordinate::Map framework)? -Aaron On Jul 14, 2005, at 11:05 AM, Chris Stoeckert wrote: > Hi Aaron, > > >> 1) VirtualSequence has a required sequence_version attribute - >> what is this for? Is this redundant to external_database_release_id? >> > This is a superclass attribute inherited by all NASequence views. > My recollection is that individual GenBank sequence entries have > version tags at the end of accessions as in "DQ094190.1" for > Toxoplasma gondii ATP-binding cassette protein subfamily B member 3 > (found in VERSION field). > > >> 2) VirtualSequence has a clob for storing the assembled sequence >> (I suspect), but the Perl object layer doesn't use this slot, >> instead rebuilding the sequence from the sequence pieces. Am I >> correct in this usage, or should I not, in fact, be storing the >> assembled sequence in VirtualSequence? >> > > Again this is a superclass attribute. I think using it is optional. > Reasons not to use it are that the virtual sequence is hard to > represent as a single entity (e.g., contains gaps) or is very large > and has a significant overhead cost of storing what can be easily > regenerated (and avoid denormalization). Reasons to use are for > convenience and efficiency of retrieving the sequence without the > need to rebuild. > > Chris > > > >> >> Thanks, >> >> -Aaron >> >> -- >> Aaron J. Mackey, Ph.D. >> Project Manager, ApiDB Bioinformatics Resource Center >> Penn Genomics Institute, University of Pennsylvania >> email: am...@pc... >> office: 215-898-1205 >> fax: 215-746-6697 >> postal: Penn Genomics Institute >> Goddard Labs 212 >> 415 S. University Avenue >> Philadelphia, PA 19104-6017 >> >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by the 'Do More With Dual!' webinar >> happening >> July 14 at 8am PDT/11am EDT. We invite you to explore the latest >> in dual >> core and dual graphics technology at this free one hour event >> hosted by HP,AMD, and NVIDIA. To register visit http://www.hp.com/ >> go/dualwebinar >> _______________________________________________ >> Gusdev-gusdev mailing list >> Gus...@li... >> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev >> > -- Aaron J. Mackey, Ph.D. Project Manager, ApiDB Bioinformatics Resource Center Penn Genomics Institute, University of Pennsylvania email: am...@pc... office: 215-898-1205 fax: 215-746-6697 postal: Penn Genomics Institute Goddard Labs 212 415 S. University Avenue Philadelphia, PA 19104-6017 |
