Re: [Gusdev-gusdev] dots.nalocation table

[Sucheta T. <su...@vb...>]

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