[Bioperl-l] SeqFeature containment hierarchies

Chris Mungall cjm at fruitfly.org
Thu Jul 17 17:27:16 EDT 2003


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.



More information about the Bioperl-l mailing list