[Bioperl-l] TFBS databases, Bio::Matrix::PSM suitable?

Chris Fields cjfields at uiuc.edu
Tue Aug 22 16:04:40 EDT 2006


> Taxonomy is not a good example since it is available to anyone. Transfac
> is
> not.

How about Bio::SeqIO::lasergene or Bio::SeqIO::strider (both proprietary, I
believe)?  There isn't any restriction on using the data or converting the
format, but it might be considered in the same category as TRANSFAC.  One
might also consider certain GCG formats (GCG, MSF) in the same category
thought they have been available for years, but what if they decide to tweak
their format and that breaks parsing?  They definitely have the right to,
even though it may annoy the rest of the biological community.

I don't have access to Lasergene or DNA Strider so I can't do anything about
those classes, but someone who has access to them could give it a try.  Why
is this any different than TRANSFAC?


> >Look, the TFBS:: module seems to have survived without causing anguish
> >and heartache. If /you/ don't have access to the data maybe you can't
> >fix some possible future bug. But the nice thing about an open-source
> >project like Bioperl is that maybe someone else /does/ have access, and
> >/they/ can fix the bug.
> I think TFBS is quite different project with different goals and scope. I
> do
> not think it is fair to make a comparison between TFBS and Bioperl.
> My concern is how many people are going to be able to take care of this
> code.

BioPerl has lots of code which works and hasn't actively been maintained,
sometimes for years. If Sendu ever decides that he wants to move on to
bigger and better things, that's fine.  The code he generates will stay in
BioPerl and someone else could take it up if they are interested.  

Generally, if someone really wants to add functionality or fix bugs in a
Bioperl class they will try working it out themselves, then contribute the
additional code in the form of a patch submitted via Bugzilla.  

> >>> Who says it won't be maintained? I will maintain it. The very second I
> >>> can no longer maintain it and no one else can, it can be deprecated to
> >>> avoid clutter. I don't see the problem. But in any case see below -
> >>> anyone could probably maintain it.
> > >
> >> I guess that if you decide you can no longer do that you are going to
> remove
> >> it? Go ahead, but do not forget what you are promising now.
> >
> >I made no such promise. It is the case that with all modules in bioperl
> >that if they are no longer maintained and no longer work, they should be
> >deprecated. My proposed module would be different in this regard.

Generally, once code is donated to the project it stays around until
something better comes along (read Bio::Tools::BPLite,
Bio::Tools::Restriction) or it becomes broken and useless for whatever
reason (server no longer exists, outdated method, software no longer
available).  If tests are written well they will catch these issues.
Anyway, if the module is of use, it has a home here!

Again, why should it be removed once Sendu no longer works on it?  By that
same reasoning we should remove a huge number of the modules in BioPerl as
the original contributors have long since abandoned them.


More information about the Bioperl-l mailing list