[Bioperl-l] Re: Gene Structure / GenScan

Ewan Birney birney@ebi.ac.uk
Tue, 1 Aug 2000 14:30:58 +0100 (GMT)


On Tue, 1 Aug 2000 hilmar.lapp@pharma.novartis.com wrote:

> 
> 
> 
> 
> > The Ensembl Genscan parser Ewan sent yesterday seems to be a good
> starting
> > point. However, I'd prefer to have a gene structure represented
> optionally
> > independent of the/an underlying sequence (object), that is, as a feature
> > which may or may not have a sequence attached. In addition, a parser
> should
> > not need to rely on being provided with the source sequence, and the
> > resulting gene structure representation can be attached to the pertaining
> > source sequence by the client.
> >
> > I'd propose the following:
> > Bio::SeqFeature::GeneStructure is-a Bio::SeqFeature::Generic (or just a
> > Bio::SeqFeatureI ?)
> > and offers specific support for gene structure related things, like
> [...]
> 
> Aha. Now you want the appropiate Ensembl gene objects, not the genscan
> parser. Look at
> 
>   Bio::EnsEMBL::Gene
>               ::Transcript
>               ::Translation
> 
> Look at
> 
> http://www.ensembl.org/Docs/Pdoc/ensembl/modules/Bio/EnsEMBL/modules.html
> 
> 
> Again, I would be happy if these moved "across" to bioperl.
> 
> you will want to add additional stuff to the Gene object to handle
> promoters (or perhaps the transcript object). Don't forget about
> alternative splicing.
> 
>      Well, that's not really what I was aiming at. I thought about a
>      representation of the _data_ which make up a gene structure, as, e.g.
>      people find it or programs predict it. IMHO all that _interpretation_
>      of the data (features in this case) belongs to separate classes,

This is a fine distinction to make; I certainly would not object to your
making these feature classes, but if they are "just" to do with gene
prediction - or - even more specifically - just with genscan, put them in
a namespace that indicates this, ie

   Bio::SeqFeature::Gene # bad 


# good namespaces.

   Bio::Tools::GenePrediction::Gene
                             ::Promotor

or

   Bio::Tools::Genscan::Gene




>      either derived ones, or within another hierarchy (you could think of a
>      GeneTranscriber who knows about alternative splicing). So, the modules
>      I proposed shouldn't do much with actual sequences apart from maybe
>      very basic things. They're just features, which in the first place is
>      all you need to represent e.g. GenScan results. And they should be
>      rich enough to allow other modules to make real stuff like protein
>      sequences out of it. So, lightweight, but heavy enough.

I worry about us rewriting things (eg, exons) but I do feel confident that
splitting out Genscan "output" from Genscan "interpretation" is a good
thing. 

go for it.


> 
>      Am I missing something?
> 
>           Hilmar
> 
> 
> _______________________________________________
> Bioperl-l mailing list
> Bioperl-l@bioperl.org
> http://bioperl.org/mailman/listinfo/bioperl-l
> 

-----------------------------------------------------------------
Ewan Birney. Mobile: +44 (0)7970 151230, Work: +44 1223 494420
<birney@ebi.ac.uk>. 
-----------------------------------------------------------------