[Biocorba-l] Re: [Bioperl-l] SeqFeature proposal

[Matthew Pocock]

Alan Robinson wrote:

> 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
>

Hi Alan,

Hope you get over the flying soon.

For my money, the information about what to do with the locations is semantic
and belongs in the feature. E.g. a CDS feature knows that it has to join each
child range that represents a region of coding exon. I think to put this info
into the location hierachy itself encourages data publishers to produce overly
complex location hierachies rather than using hierachies of features (which
should be easier to understand).

Matthew

>
> 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
> >
>
> _______________________________________________
> Biocorba-l mailing list
> Biocorba-l@biocorba.org
> http://www.biocorba.org/mailman/listinfo/biocorba-l