Re: [Gusdev-gusdev] dots.nalocation table

[Steve F. <sfi...@pc...>]

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