From: Steve F. <sfi...@pc...> - 2005-02-15 17:28:54
|
sucheta- i *think* the answer to your question may be that features have parent_id. this is used to build feature trees. steve Sucheta Tripathy wrote: > Thank you all for the response. My original question was bit premature > and based on more of our convenience than the design of GUS per se. > > But these are some issues, I think the group may need to consider: > > By keeping different prediction outputs as different feature_ids and > finally merging them through gene and gene_instance seems fine. But we > need to distinguish between features within a gene and features of a > gene. What I mean by that is a gene may have different features like > an UTR feature , a promoter element feature etc, a cpg island feature > and so on. which needs to be linked to a particular prediction output. > > For example I have gene 1 with gene_id 1 which has several > gene_instances represented by different prediction algorithms and each > having a different na_feature_id say: 1,2,3,4. > > For prediction algorithm with na_feature_id=1, I have a set of UTR > locations and say I have feature_id 5 for UTR_5 and 6 for UTR_3 and a > promoter feature with na_feature_id 7. Then how would I link > na_feature_ids 1,5,6 and 7. > > So, for this I was thinking if one na_feature_id could represent a > gene and its locations could have a description each with reviewer's > status etc. And to save the geneinstances for any kind of splice > variants or any other types of instances. > > Many thanks > > Sucheta > > At 09:40 AM 2/14/2005 -0500, you wrote: > >> This question is a bit more complex than it seems. >> >> All three of these may be necessary for every level of >> analysis. first, was the overall gene prediction/feature >> prediction reviewed and how was it algorithmically arrived at? >> Then you can ask the same question about the locations. >> Early locations may be provided by the same algorithm as the >> feature, but these may be further defined later and require >> their own review annotations. >> >> One thing that I think needs to be addressed, however, is how >> these columns appear throughout the schema like mushrooms. I >> have been told that GUS was hyper-normalized when it was first >> written to 4N or 5N form, but that is definitely not the case >> now. Why do you want review_status, reviewer and algorithm in >> the feature table? Since these usually will appear in >> clusters (i.e. running an algorithm once gives you 500 cases >> of the same entry for all three on the same date), shouldn't >> we have a table to collect these into an annotation_status >> table and just have an FK to an entry in that table for every >> table that uses these? The same goes for other SRes entries >> such as taxon, project, etc. >> >> -Ed >> >> >> >> ---- Original message ---- >> >Date: Sat, 12 Feb 2005 22:34:03 -0500 (EST) >> >From: "Sucheta Tripathy" <su...@vb...> >> >Subject: [Gusdev-gusdev] dots.nalocation table >> >To: Gus...@li... >> > >> > >> >Hi Group, >> > >> >From community annotation point of view, I was wondering if >> it is a good >> >idea to have is_reviewed, algorithm_id and reviewer_id in >> dots.nalocation >> >table. >> > >> >Since one na_feature_id( a transcript or a gene) may be >> having multiple >> >sets of nalocations, so one can easily capture them in >> nalocation with >> >different algorithms and with a reviewed option. >> > >> >In our application we need several gene calling programs to >> have locations >> >as well as related information registered. >> > >> >Sucheta >> > >> > >> >-- >> >Sucheta Tripathy >> >Virginia Bioinformatics Institute Phase-I >> >Washington street. >> >Virginia Tech. >> >Blacksburg,VA 24061-0447 >> >phone:(540)231-8138 >> >Fax: (540) 231-2606 >> > >> > >> >------------------------------------------------------- >> >SF email is sponsored by - The IT Product Guide >> >Read honest & candid reviews on hundreds of IT Products from >> real users. >> >Discover which products truly live up to the hype. Start >> reading now. >> >http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >> >_______________________________________________ >> >Gusdev-gusdev mailing list >> >Gus...@li... >> >https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev >> ----------------- >> Ed Robinson >> Center for Tropical and Emerging Global Diseases >> University of Georgia, Athens, GA 30602 >> ero...@ug.../(706)542.1447/254.8883 >> >> >> ------------------------------------------------------- >> SF email is sponsored by - The IT Product Guide >> Read honest & candid reviews on hundreds of IT Products from real users. >> Discover which products truly live up to the hype. Start reading now. >> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >> _______________________________________________ >> Gusdev-gusdev mailing list >> Gus...@li... >> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev > > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Gusdev-gusdev mailing list > Gus...@li... > https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev |