[Biopython-dev] Namespace for online resources?
Kevin Murray
k.d.murray.91 at gmail.com
Sat Feb 2 01:00:34 EST 2013
Michiel,
TAIR (http://www.arabidopsis.org/) is primarily a sequence repository. I
have no intention to extend it beyond that, and any other features would
not be easily scriptable, or would be pointless to include in Biopython.
Regards
Kevin Murray
On 2 February 2013 12:36, Michiel de Hoon <mjldehoon at yahoo.com> wrote:
> In principle I am OK with this, but is TAIR only used for sequences? Or is
> it possible / likely that in the future we may want to add other
> functionality to TAIR? Anyway, if TAIR is predominantly used for sequences,
> then Bio.Seq.Web is a good option I think.
>
> Best,
> -Michiel.
>
> --- On Fri, 2/1/13, Kevin Murray <k.d.murray.91 at gmail.com> wrote:
>
> > From: Kevin Murray <k.d.murray.91 at gmail.com>
> > Subject: Re: [Biopython-dev] Namespace for online resources?
> > To: "Peter Cock" <p.j.a.cock at googlemail.com>
> > Cc: "Biopython-Dev Mailing List" <biopython-dev at biopython.org>
> > Date: Friday, February 1, 2013, 6:59 PM
> > Hi All,
> >
> > How about this:
> > In the vein of Lenna's last email, we create a module WebSeq
> > (or Seq.Web,
> > or whatever), containing modules whose sole purpose is to
> > get sequences
> > (Seq/SeqRecord objects) from an internet database. This
> > would i think
> > provide a good balance between a messy top-level domain full
> > of modules
> > like Bio.tair, and the absolutisim of having anything vaugly
> > web related in
> > a single WWW module. It should also provide the unified
> > theme per module
> > which Michiel talks of, and unit/doctests should be fine, as
> > no modules
> > will be split (simply moved in their entirety from Bio.x to
> > Bio.WebSeq.x).
> >
> > >From a quick look, the only candiate (apart from TAIR)
> > for a shift is
> > TogoWS, and even then I'm not sure, as TogoWS isn't used
> > just for Seq's
> > (and does not return them).
> >
> > Regards
> > Kevin Murray
> >
> >
> > On 2 February 2013 08:00, Peter Cock <p.j.a.cock at googlemail.com>
> > wrote:
> >
> > > On Fri, Feb 1, 2013 at 7:05 PM, Lenna Peterson <arklenna at gmail.com>
> > wrote:
> > > > On Fri, Feb 1, 2013 at 9:14 AM, Peter Cock <
> p.j.a.cock at googlemail.com>
> > > > wrote:
> > > >>
> > > >>
> > > >> People leaning for a Bio.WWW grouping: Bow,
> > Lenna, Kevin
> > > >> (which could be a big disruption with lots of
> > code relocation)
> > > >>
> > > >> People leaning against a Bio.WWW grouping:
> > Michiel, Peter (me)
> > > >> (which would also be the status quo, so no
> > disruption).
> > > >>
> > > >
> > > > I concede that the potential benefit of
> > refactoring to separate WWW is
> > > > outweighed both by potential downsides and the
> > disruption and effort
> > > > involved.
> > > >
> > > >> In the specific case of Kevin's TAIR code for
> > fetch Arabidopsis
> > > sequences,
> > > >> Bio.TAIR (lower case?) is consistent with
> > current usage. Somewhere under
> > > >> Bio.Seq* also seems sensible to me, as I wrote
> > at the start of this
> > > >> thread.
> > > >>
> > > >
> > > > Populating the top level namespace with a
> > submodule for each web-only
> > > > service has the risk of creating too many
> > submodules. Bio.Seq* makes
> > > sense,
> > > > because the TAIR code pulls data into a Seq. Web
> > services that connect
> > > to a
> > > > single biopython representation can be organized
> > under that submodule.
> > > Web
> > > > services that return multiple types of information
> > (e.g. Entrez) are big
> > > > enough to logically comprise their own submodule.
> > > >
> > > > Is my interpretation of the biopython
> > classification scheme more or less
> > > > correct?
> > >
> > > Yes that sounds about right :)
> > >
> > > Of course, the historical muddle of Bio.Seq* is
> > something we've talked
> > > about addressing recently - see this thread from
> > October,
> > >
> http://lists.open-bio.org/pipermail/biopython-dev/2012-October/009999.html
> > >
> > > Peter
> > > _______________________________________________
> > > Biopython-dev mailing list
> > > Biopython-dev at lists.open-bio.org
> > > http://lists.open-bio.org/mailman/listinfo/biopython-dev
> > >
> > _______________________________________________
> > Biopython-dev mailing list
> > Biopython-dev at lists.open-bio.org
> > http://lists.open-bio.org/mailman/listinfo/biopython-dev
> >
>
More information about the Biopython-dev
mailing list