Source_Exons tag

Richard Durbin rd at sanger.ac.uk
Fri Nov 2 12:26:29 EST 2001


Certainly we support alternative splicing - it is ubiquitous!  And yes we can
support objects for regulatory regions etc (by the SMAP system).  Thank you for
the pointer to your database.

Richard

Donn Davy wrote:
> 
> Can't agree that introns are just 'gaps': we are finding that conserved
> non-coding regions are highly correlated with regulation. Also that
> alternative splicing often involves differences in intron as well as
> exon lengths and composition. Would propose that acedb classes be
> defined which support CNCRs and alternative splicing.  Please see our
> Alternative Splicing Database,
> http://devnull.lbl.gov:8888/alt/index.html, and
> Visualization Tools for Alignment (VISTA), http://www-gsd.lbl.gov/vista
> -
> Donn Davy, CBCG at LBNL
> 
> Tim Cutts wrote:
> >
> > In article <3BDEA54C.FD71A337 at sanger.ac.uk>,
> > Richard Durbin  <rd at sanger.ac.uk> wrote:
> >
> > >We have talked for some time about ways to support an alternative exon
> > >implementation for acedb/fmap more in line with what is standard
> > >elsewhere, i.e. having separate exon objects, with transcripts linking
> > >to the exons that they contain.  Time to have this discussion with
> > >proposals in the open in the acedb newsgroup, I think.
> >
> > Sounds like a good idea to me!
> >
> > >Should we also support Intron objects?  If so, would either exons or introns be
> > >acceptable, and what happens if both are given and they are inconsistent?
> >
> > Storing introns as objects seems a slightly strange concept to me - my
> > mental model is that introns are "gaps".  Certainly technologies such as
> > BioJava are modelling transcripts as lists of exon objects, and that's
> > how we modelled them at Incyte too.
> >
> > >I hasten to add, for reasons of continuity, and because some people strongly like
> > >all the exon structure information being explicit in the transcript-type objects,
> > >I expect we will continue to support the current style.
> >
> > Well something like this in ?Sequence
> >
> > Source_exons Int Int ?Exon
> >
> > would be backward compaible with current databases.  It works well in my
> > mind because it separates properties of the transcript (CDS etc, which
> > should indeed be properties of the ?Sequence object) from properties of
> > the exon itself (which probably aren't that numerous!).
> >
> > I suppose you could add some XREFs so that exons could list which
> > transcripts they belong to, although as a rule I avoid throwing XREFs
> > around like confetti since they can drastically slow things down
> > (parsing large numbers of DNA_homol lines, anyone?!)
> > i.e. something like:
> >
> > // in ?Sequence
> >
> > Source_exons Int Int ?Exon XREF In_transcript
> >
> > ?Exon In_transcript ?Sequence
> >
> > Sorry, might have the syntax wrong there - I don't have a copy of ACeDB
> > on my machine here at home.
> >
> > Thoughts?  My idea is pretty simple, but it certainly would solve my
> > needs, and maintains compatibility with current code.
> >
> > Tim.

-- 
---------------------------------------------------------------------
Richard Durbin                                      The Sanger Centre
email: rd at sanger.ac.uk                   Wellcome Trust Genome Campus
http://www.sanger.ac.uk/Users/rd/                             Hinxton
phone: 01223 494978                                Cambridge CB10 1SA
fax: 01223 494919                                                  UK
---------------------------------------------------------------------






More information about the Acedb mailing list