[ensembl-dev] getting the entrez gene id from an ensembl record

[Bert Overduin]

On Thu, Dec 2, 2010 at 10:33 AM, Andreas Kahari <ak at ebi.ac.uk> wrote:

> On Thu, Dec 02, 2010 at 10:53:36AM +0100, Patrick Meidl wrote:
> > On Thu, Dec 02 2010, Andy Jenkinson <andy.jenkinson at ebi.ac.uk> wrote:
> >
> > > > On Thu, Dec 02 2010, ian Longden <ianl at ebi.ac.uk> wrote:
> > > >
> > > >> Use $gene->get_all_DBLinks as this gets the external database
> > > >> references on the transcripts and translations of the gene too.
> > > >>
> > > >> DBEntries only gets the ones attached to the gene directly.
> > >
> > > Also, whether something is attached to a gene or transcript is not
> > > always intuitive: as I understand it, it depends on how the mapping
> > > was done, not the logical data model relationships. You have to know
> > > the internal data model before you can use it. For example, why is an
> > > EntrezGene not a gene-related record?
> >
> > exactly. I therefore think that what is now called get_all_DBLinks()
> > should have an intuitive name which highlights that in most cases,
> > _this_ is the right method for getting xrefs.
>
> On the contrary.  If the users knows what external database they are
> querying for (which they often do), and they know what level the xref
> are annotated on (which they also often do),


>From the fact that I've seen quite some helpdesk tickets in the past from
people who are trying to get xrefs from the wrong level and the fact that I
myself, even though I teach the core API, can never remember which xref is
done on which level, I I am afraid you're far too optimistic here .... :0

then get_all_DBEntries()
> is definitely the most correct method to call.  It is lots quicker than
> get_all_DBLinks().  The DBLinks method is a lazy catch-all.


> > get_all_DBEntries() is a special case which most users won't need, and
> > the name should indicate its nature as well (and maybe have a less
> > catchy name so that people don't use it by accident, as is the case
> > now).
>
> See above.
>
> Cheers,
> Andreas
>
>
> > sure, all this is documented in the POD, but the beauty of the Ensembl
> > core API is that object and method names are so intuitive that in 95% of
> > the use cases you don't have to read the documentation. so, ironing out
> > the few wriggles would be cool.
> >
> > cheers
> >
> >     patrick
> >
> > --
> > Patrick Meidl, Mag.
> > Bioinformatician
> >
> > Ce-M-M-
> > Research Centre for Molecular Medicine
> > of the Austrian Academy of Science
> >
> > Lazarettgasse 14 / AKH BT 25.3
> > Vienna, Austria
> >
> > room 02.205
> > phone +43 1 40160 70016
> > email pmeidl at cemm.oeaw.ac.at
> > web http://www.cemm.at/
> >
> >
> > _______________________________________________
> > Dev mailing list
> > Dev at ensembl.org
> > http://lists.ensembl.org/mailman/listinfo/dev
> >
>
> --
> Andreas Kähäri, Ensembl Software Developer
> European Bioinformatics Institute (EMBL-EBI)
> Wellcome Trust Genome Campus
> Hinxton, Cambridge CB10 1SD, United Kingdom
>
> _______________________________________________
> Dev mailing list
> Dev at ensembl.org
> http://lists.ensembl.org/mailman/listinfo/dev
>



-- 
Bert Overduin, Ph.D.
PANDA Coordination & Outreach

EMBL - European Bioinformatics Institute
Wellcome Trust Genome Campus
Hinxton, Cambridge CB10 1SD
United Kingdom

http://www.ebi.ac.uk/~bert <http://www.ebi.ac.uk/%7Ebert>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ensembl.org/pipermail/dev_ensembl.org/attachments/20101202/465d1e19/attachment.html>