[Bioperl-l] SeqFeature proposal

[Alan Robinson]

Ewan et al,

On Sun, 19 Nov 2000, Ewan Birney wrote:

> In a road-to-damascus like experience (on the M25, in driving rain if
> anyone is interested) I saw a new layout of feature and location objects.
> 
> The layout would be 
> 
> 
>    - simple for simple cases
> 
>    - complex for complex cases
> 
>    - could cope with the dreaded fuzziness.
> 
>    - strongly typed


I'm very interested to see if/how this effects our discussions with the
proposed new Bicorba interface.

But first, could you clarify what you consider "complex"? Is a complex
'location' still a 'joining' of Range objects (as it would appear). Or
could it also be made to handle other GenBank/EMBL location operators such
as 'order' and 'one-of'? i.e. an 'operator' method in ParentLocationI that
would describe what to do with the elements of the 'SubLocation' array,
e.g. 'join', 'order', etc.


cheers,
al


PS I'm still trying to "cope with the dreaded fuzziness" of jetlag, so
please excuse any nonsense!

--
============================================================
Alan J. Robinson, D.Phil.             Tel:+44-(0)1223 494444
European Bioinformatics Institute     Fax:+44-(0)1223 494468
EMBL Outstation - Hinxton             Email:  alan@ebi.ac.uk
Wellcome Trust Genome Campus
Hinxton, Cambridge
CB10 1SD, UK                http://industry.ebi.ac.uk/~alan/
============================================================

On Sun, 19 Nov 2000, Ewan Birney wrote:

> 
> 
> In a road-to-damascus like experience (on the M25, in driving rain if
> anyone is interested) I saw a new layout of feature and location objects.
> 
> The layout would be 
> 
> 
>    - simple for simple cases
> 
>    - complex for complex cases
> 
>    - could cope with the dreaded fuzziness.
> 
>    - strongly typed
> 
> Here goes:
> 
> At the interface level we have:
> 
>    RangeI            -> start/end/strand
>    SeqFeatureI       -> implements RangeI, has-a ParentLocationI
>    ParentLocationI   -> implements RangeI, has an array of SubLocationI
>                      ParentLocation could be Fuzzy.
>    SubLocationI      -> implements RangeI nothing else (could remove)
> 
> 
> For simple start/end/strands features, eg, implemented with
> SeqFeature::Simple, SeqFeature::Simple would implement:
> 
>    SeqFeatureI, returning $self to a ParentLocationI call
>    ParentLocationI - returning nothing for SubLocation
> 
> For more complex cases, parsed from GenBank/EMBL, a full blown array'd
> location object could be made.
> 
> 
> For complex cases with complex subSeqFeature heirarchies, there would
> be nothing stopping the, say , Exon objecs implementing the SubLocationI
> interface, such that although one could have two routes to discover
> the same information in the interface hierarchy it is implemented in 
> the same object.
> 
> 
> In other words, I am expanding the interface defintions, but sanctioning
> (indeed encouraging) implementations to support multiple interfaces and
> therefore provide consistency which is not guranenteed by teh interface
> definition.
> 
> 
> What do people think?
> 
> 
> -----------------------------------------------------------------
> Ewan Birney. Mobile: +44 (0)7970 151230, Work: +44 1223 494420
> <birney@ebi.ac.uk>. 
> -----------------------------------------------------------------
> 
> _______________________________________________
> Bioperl-l mailing list
> Bioperl-l@bioperl.org
> http://bioperl.org/mailman/listinfo/bioperl-l
>