[Open-bio-l] Re: [Bioperl-l] seq namespace method

Ewan Birney birney@ebi.ac.uk
Thu, 18 Jul 2002 03:18:26 -0400 (EDT)


On Wed, 17 Jul 2002, Hilmar Lapp wrote:

> I think I like that best too.

ok, I will implement.


>
> 	-hilmar
>
> > -----Original Message-----
> > From: Lincoln Stein [mailto:lstein@cshl.org]
> > Sent: Wednesday, July 17, 2002 1:56 PM
> > To: Ewan Birney
> > Cc: sac@bioperl.org; Hilmar Lapp; OBDA BioSQL (E-mail);
> > BioPerl (E-mail)
> > Subject: Re: [Open-bio-l] Re: [Bioperl-l] seq namespace method
> >
> >
> > I liked the compromise you published earlier yesterday:
> >
> > 	- Bio::PrimarySeqI inherits/implements IdentifiableI.
> > 		This is its "one true" name.
> > 	- The cloud of other identifiers is attached to Bio::Seq via
> > 	its AnnotationCollectionI.
> >
> > I will work on IdentifierCollectionI as a separate interface.
> >
> > Lincoln
> >
> > On Tuesday 16 July 2002 04:04 am, Ewan Birney wrote:
> > > Ok. Both Lincoln and Steve prefer I think the pattern
> > >
> > >
> > >   Bio::IdentifierCollectionI
> > >
> > >
> > > which Bio::PrimarySeqI inheriets from
> > >
> > >
> > > gives out something like ->identifiers() -   # a set of
> > Bio::Identifier
> > >                          ->identifier('sp'); #
> > identifier(s?) for this
> > > namespace
> > >
> > >
> > > Lincoln is suggesting this handles cardinality/split/merges
> > >
> > >
> > >
> > > I am wary of this because of two things:
> > >
> > >
> > >    (a) Most objects come from one authority/namespace - how
> > do we indicate
> > > the "main" authority/namespace of this object. There are *very few*
> > > objects which honestly have two equally valid Identifiers -
> > >
> > >
> > >     --- my view is that we are giving ourselves too much
> > rope to hang
> > > ourselves with and we will endlessly have things about "assummed
> > > namespace" or - even worse - assumming that the first
> > identifier in the
> > > list of identifiers pulled out of the colleciton is the "main" one.
> > >
> > >
> > >    (b) We are making life harder for non-standard
> > implementations who have
> > > to implement this - certainly putting in split/merge
> > capibility as part of
> > > the *interface* is a bad idea - split/merge is nasty to implement.
> > >
> > >
> > >
> > > Does anyone else want to weigh in. Steve/Lincoln - can you
> > show me that my
> > > fears are unfounded?
> > >
> > >
> > >
> > >
> > >
> > >
> > > -----------------------------------------------------------------
> > > Ewan Birney. Mobile: +44 (0)7970 151230, Work: +44 1223 494420
> > > <birney@ebi.ac.uk>.
> > > -----------------------------------------------------------------
> >
> > --
> > ==============================================================
> > ==========
> > Lincoln D. Stein                           Cold Spring Harbor
> > Laboratory
> > lstein@cshl.org			                  Cold
> > Spring Harbor, NY
> > ==============================================================
> > ==========
> >
>