Thread: proposal: a new mailing list for biomedical postgresql ( pgsql-bio )
Dear all, I would like to propose a dedicated mailing list for the usage of PostgreSQL in biological/biomedical application - a good name might be "pgsql-bio". a little background: In biomedical research, there are often two main sources of data: On the one hand, locally-produced experimental data from an ever-growing array of data-spewing machinery (e.g. high-throughput sequencing; mass spectrometry; microarrays). On the other hand, there are large biomedical databases freely downloadable (e.g.: NCBI; ensembl.org; hapmap.org; many, many others). (science publications are increasingly obliged to provide (raw) data as well.) Work for the (database) programmer often involves joining the locally produced experimental data to (local copies of) the huge public databases. (Biologists refer to this as "annotation"). The preparation of such "annotation" databases can be the same for many research groups. In combination with the possibility of example code on a bioinformatics section of the wiki, a mailing list could provide a platform to discuss ways to prepare such databases, & their respective applications. Thanks, Erik Rijkers Erasmus University Medical Center Rotterdam (Netherlands)
Re: proposal: a new mailing list for biomedical postgresql ( pgsql-bio )
From
"Joshua D. Drake"
Date:
Erik wrote: > Dear all, > > I would like to propose a dedicated mailing list for the usage of PostgreSQL > in biological/biomedical application - a good name might be "pgsql-bio". This seems like a perfect case of a pgfoundry mailing list. http://www.pgfoundry.org Joshua D. Drake
"Erik" <er@xs4all.nl> writes: > I would like to propose a dedicated mailing list for the usage of PostgreSQL > in biological/biomedical application - a good name might be "pgsql-bio". Given that the amount of such traffic in the past on the postgres lists has been approximately zero, I can't see why we need such a list. Our usual rule for establishing new lists has been to split out a sub-topic that's taking too much space on pgsql-general, and this is certainly far from qualifying. regards, tom lane