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

[skirov]

>===== Original Message From Chris Fields <cjfields at uiuc.edu> =====
>Stefan,
>
>> 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?

Well, we are talking not just about the format but also about the data, aren't 
we? None of the examples you mentioned are comparable to the transfac case as 
these are not databases. This is my personal opinion on this matter- I think 
that the data provider should be at least partially involved in the process.

>
>..
>
>> >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.

There was a push to remove some of the code that is not mainained a year or so 
ago... And that is what I am saying too- I am just concerned about how many 
people with access to the data would be contributing....


>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.
I think you missunderstood me here- I mean that Sendu is making a fairly 
strong statement... When transfac stopped providing the data files I announced 
that I am not providing further maintenance and said that it should be 
probably removed- this is my opinion in general and has nothing to do with 
Sendu or any other developer. I think this discussion becomes a bit religious 
in nature and there is a little point in continuing.
I think Sendu is taking the right approach here by contacting the provider and 
if Biobase gets involved (I think they should be interested in doing so) then 
concerns I expressed will not be valid.
Stefan
>
>Chris