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

[Ewan Birney]

On Mon, 15 Jul 2002, Lincoln Stein wrote:

> I think it's important to separate the notion of an identifier from the notion
> of a collection of identifiers assigned to an object.

Agreed. I like your proposed set of interfaces lincoln (inc
NameCollectionI or IdentifierCollectionI) - would you like PrimarySeqI to
inheriet from IdentifierCollectionI or IdentifiableI - I still prefer
IdentifiableI


To make IdentifiableI work smoothly with DBLink and PrimarySeqI methods I
suggest adding the method

   ->display_name()

this is make the distinction between the hardnosed identifier (accession
in primaryseqI, primary_id in DBLink) and the fluffy biologist friendly
display id (the HUGO symbol/genename etc).


I don't think the LSID has a slot for teh fluffy name and of course, the
next thing is someone wants to add another slot of description or
something....



Anway - I would ovte for display_name, PrimarySeqI inherieting from
Identifiable and PrimarySeqI

PrimarySeqI     IdentifiableO
  id       ---> display_name (tough call this - what is the id in a fasta  file)?
accession  ---> object_id
namespace  ---> namespace
authority  --->  authority


In BioSQL - the authority is perhaps implicit in the database or we add a
slot in the BioDatabase area - authorities are over databases?



Then DBLink's also become IdentifiableI. For Steve's use case (cloud of
identifiers on a sequence), one of them has to be selected as the
definitive one and others attached as DBLinks on the AnnotationCollectionI





>
> Lincoln
>
> On Monday 15 July 2002 04:08 pm, 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
>
> --
> ========================================================================
> Lincoln D. Stein                           Cold Spring Harbor Laboratory
> lstein@cshl.org			                  Cold Spring Harbor, NY
> ========================================================================
>