Re: SeqFeature containment hierarchies

Hi,

I can confirm that it doesn't affect drawing code.  I use N transcripts => M 
exons construct frequently.

Lincoln

On Thursday 17 July 2003 07:27 pm, Chris Mungall wrote:
> Any SeqFeatureI can contain any number of child SeqFeatureIs, accessible
> via $sf->get_SeqFeatures();
>
> Are there any restrictions/recommendations on whether this is a tree or a
> graph?
>
> For example, if we have an exon shared between two mRNAs, would this exon
> be represented redundantly by two objects, or by one object?
>
> I prefer the latter, as it avoids redundancy
>
> However, some code may expect the containment hierarchy to be a tree (that
> is, each feature can have zero or one container/parent)
>
> Hilmar - does this affect the biosql code? Would this lead to multiple
> updates of the same exon when storing a gene model?
>
> MarkW/DaveB - does this affect Genquire at all?
>
> I'm assuming this doesn't affect drawing code such as gbrowse at all; a
> graph can be traversed as if it is a tree, visiting some nodes more than
> once. This should only affect code that modifies feature objects in some
> way, shouldn't it?
>
> One problem is the fact that calling get_all_SeqFeatures on the top
> feature will do a tree traversal and return the same object multiple
> times. If we force the containment hierarchy to be a tree rather than a
> graph, then at least this is consistent.
>
> I would actually like to change FeatureHolderI to return a flattened list
> of unique objects - however, I have a feeling this will break code.
>
> c.
>
> _______________________________________________
> Bioperl-l mailing list
> Bioperl-l@xxxxxxxxxxxxxxxxxxx
> http://portal.open-bio.org/mailman/listinfo/bioperl-l

-- 
========================================================================
Lincoln D. Stein                           Cold Spring Harbor Laboratory
lstein@xxxxxxxx                                   Cold Spring Harbor, NY
========================================================================