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

[Ewan Birney]

On Mon, 15 Jul 2002, Matthew Pocock wrote:

> Hi.
> 
> My vote would be on containment/agregation. This is nearly always the 
> answer over inheritance. Perhaps Bio::IdentifiableI provides an 
> identifier method that returns a Bio::IdentifierI. Bio::SeqI implements 
> Bio::IdentifiableI. Bio::IdentifierI stores all of the info necisary for 
> regenerating the resource (in this case a sequence) and can exist 
> potentialy (or even preferably) without a reference to the object it 
> identifies. A Bio::Resolver class is used as the factory or hub for 
> returning objects for identifiers.


But... you are arguing here that Bio::SeqI implemnts Bio::IdentifiableI - 
inherietance in my book - the containment could be an implementation 
detail here.


> 
> XRefs are a different use case of identifiers, and may be better moddled 
> by sticking Bio::Identifier objects in some well-known annotation 
> bundle, totaly disjoint from any Bio::IdentifiableI API.
> 
> For cases where an identifiable object has a primary and several 
> secondary identifiers, why not have the Bio::IdentifiableI::identifier 
> method take an optional argument (something like "ACC" or "SID" or 
> whatever). No argument returns the default identifier. An argument 
> returns a list (possibly empty) of all identifiers of that type.
> 
> Sequences have identifiers, they are not themselves identifiers.
> 
> Matthew
> 
> Ewan Birney wrote:
> > 
> > On Mon, 15 Jul 2002, Steve Chervitz wrote:
> > 
> > 
> >>Glad we're all thinking alike here. However, why not use containment instead of
> >>inheritance, to allow a Bio::IdentifiableI to contain one or more
> >>Bio::Identifiers?
> > 
> > 
> > 
> > Hmmm. Doable.
> > 
> > Is this ideal - this is saying that one object is usually represented by a
> > "cloud" of identifiers?
> > 
> > 
> > I would claim that the opposite pattern is more true - on object usually
> > has one "main" identifier and then points to a cloud of related
> > identifers, the DBxREFs
> > 
> > Certainly merging the idea of DBxREFs - or DBLinks in Bioperl which should
> > also be Identifiable would be a good idea.
> > 
> > 
> > I can see your arguement, but I would marginally favour the strict
> > one-object-one-identifier and not factor out the identifier objects as a
> > separate thing - claiming that in those cases most people want an
> > Identifiable object that is an AnnotationCollectionI and has a cloud of
> > Identifiable DBxREFs
> > 
> > 
> > But... not a clear cut decision. Any other views
> > 
> > 
> > (PS - I liked Lincoln's simple "yes")
> > 
> > 
> > 
> > 
> >>If an IdentifiableI also has a preferred identifier slot, then it could have
> >>methods such as namespace(), id(), version() that would delegate to their
> >>preferred identifier. This would allow us to maintain the current interface yet
> >>still be I3C-compliant.
> >>
> >>For those that don't know about it, the I3C thingy that Ewan mentions is called
> >>the LSID (Life Science Identifier), a draft specification of which can be found
> >>at http://www.i3c.org/workgroups/technical_architecture/index.html. It's
> >>generated a bunch of interesting discussion.
> >>
> >>The LSID concept is still evolving, but current thinking is to have at least
> >>these fields: authority, namespace, id. A version field will probably be added
> >>and security info may be dropped.
> >>
> >>Steve
> >>
> >>--- Lincoln Stein <lstein@cshl.org> wrote:
> >>
> >>>Yes.
> >>>
> >>>Lincoln
> >>>
> >>>On Monday 15 July 2002 04:48 am, Ewan Birney wrote:
> >>>
> >>>>I would claim the right pattern here is to have
> >>>>
> >>>>
> >>>>  Bio::IdentifiableI
> >>>>
> >>>>which Bio::PrimarySeqI inheriets from and Bio::PrimarySeq implements.
> >>>>
> >>>>
> >>>>  Bio::IdentifiableI would have slots for namespace, version, id (NB
> >>>>**no** type) and would be compatiable with the 13C naming convention
> >>>>thingy to produce I3C style names (so it might also have "authority" as a
> >>>>slot).
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>-----------------------------------------------------------------
> >>>>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
> >>>
> >>>--
> >>>========================================================================
> >>>Lincoln D. Stein                           Cold Spring Harbor Laboratory
> >>>lstein@cshl.org			                  Cold Spring Harbor, NY
> >>>========================================================================
> >>>_______________________________________________
> >>>Bioperl-l mailing list
> >>>Bioperl-l@bioperl.org
> >>>http://bioperl.org/mailman/listinfo/bioperl-l
> >>
> >>
> >>
> >>=====
> >>Steve Chervitz
> >>sac@bioperl.org
> >>
> >>__________________________________________________
> >>Do You Yahoo!?
> >>Yahoo! Autos - Get free new car price quotes
> >>http://autos.yahoo.com
> >>_______________________________________________
> >>Open-Bio-l mailing list
> >>Open-Bio-l@open-bio.org
> >>http://open-bio.org/mailman/listinfo/open-bio-l
> >>
> > 
> > 
> > _______________________________________________
> > Open-Bio-l mailing list
> > Open-Bio-l@open-bio.org
> > http://open-bio.org/mailman/listinfo/open-bio-l
> > 
> 
> 
> 
> _______________________________________________
> Open-Bio-l mailing list
> Open-Bio-l@open-bio.org
> http://open-bio.org/mailman/listinfo/open-bio-l
> 

-----------------------------------------------------------------
Ewan Birney. Mobile: +44 (0)7970 151230, Work: +44 1223 494420
<birney@ebi.ac.uk>. 
-----------------------------------------------------------------