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

[Chris Fields]

On Aug 22, 2006, at 7:18 AM, Sendu Bala wrote:
> ...

> In any case, I don't see that your argument is valid. Why should  
> bioperl
> be restricted to only dealing with 'open' data sources? If someone is
> willing to develop and maintain a module that deals with a data  
> source,
> it makes no difference if that source is open or not - it is useful
> either way to other people who also have access to that data. If there
> comes a time that the maintainer can no longer maintain it and it  
> stops
> working because the data format changes, and no one knows the new
> format, it can be deprecated.

It all depends on how open the data format is and how well tested the  
class is.  There are public and private versions of TRANSFAC if  
memory serves, so I see no problem as long as everyone realizes we  
will be limited on how much we can help out with the private data if  
a problem pops up (common sense : not everyone would have access to it).

We deal with private/proprietary data here all the time; there have  
been many instances where someone didn't want to send their sequence  
or code for various perfectly valid reasons.

>
> Is there some 'popularity' threshold that must be passed before it is
> 'worth' adding a database module to Bioperl? Why should there be one?
> The cost of having one is a few kb in disc storage space, the benefit
> extremely large to the person who might want to use it. There may  
> be an
> argument that core shouldn't become cluttered with too much stuff that
> the majority of people won't use, but how is that line drawn? I don't
> personally use the majority of bioperl modules, but I don't think they
> should all be removed. And clearly the idea of having PWM, transfac
> related modules in bioperl has been deemed acceptable in the past,  
> or we
> wouldn't have Bio::Matrix::PSM::transfac.

Remember Hilmar's saying (I'll probably butcher it here): "Never  
stand in the way of someone who threatens to code."   As long as the  
code itself and the test data doesn't contain anything that would be  
considered private/proprietary, I see no problem.

Chris


Christopher Fields
Postdoctoral Researcher
Lab of Dr. Robert Switzer
Dept of Biochemistry
University of Illinois Urbana-Champaign