[Bioc-devel] Invitation to the bioC developers Meeting in Seattle Mon 15 Aug

[Furge, Kyle]

> From: Vincent Carey 525-2265 <stvjc at channing.harvard.edu>
> Date: Thu, 4 Aug 2005 12:38:19 -0400 (EDT)
> To: Matthias Futschik <m.futschik at biologie.hu-berlin.de>
> Cc: bioc-devel at stat.math.ethz.ch, Wolfgang Huber <huber at ebi.ac.uk>
> Subject: Re: [Bioc-devel] Invitation to the bioC developers Meeting in Seattle
> Mon 15 Aug
> 
<snip'ed> 
>> 
>> And equally importantly: An agreement on a small number of data formats which
>> should
>> then be used  in newly contributed packages. If new data formats are included
>> a package, a set of conversion tools from and to the standard Bioconductor
>> data formats
>> should be included.
> 
> Please be more specific on what deficits need to be addressed.
> exprSet has a reasonable role as a target format for the combination of
> experiment metadata (MIAME object in description slot), sample level data
> (phenoData slot), and assay quantitations (exprs slot).  Various software
> tools and a convert package make use of this container structure.

As also a once-a-while developer, but heavily user, of Bioconductor I think
an instructive example of this issue is the the ArrayCGH section in
TaskView.

aCGH, DNAcopy, GLAD all use different, internally defined formats for data
storage. In addition, feature annotations are stored in separate formats
rather then annotation environments.

Currently, the convert package does not handle the aCGH, DNAcopy, or GLAD
data or annotation formats. I do not want to speak for the original author
or the authors of these packages, but in this example, it is worth requiring
coerce methods for these (and other) formats into exprSets/annotation
environments at the package acceptance stage?

While the idea of in-depth package review is debatable, it is an advantage
that projects like BioPerl and BioJava enjoy (i.e. you can't commit to the
source tree unless you follow some conventions, like putting coerce methods
in the convert package).  However, BioPerl and BioJava started out with more
rigorous code review, while BioC did not. I think it will be hard to put the
genie back in the bottle and require additional standards now.

Practically (even though I am guilty as others for lack of effort) I think a
requirement for package inclusion *should* be relevant biocViews
information. Outside of the vertically integrated packages, at least with
this information, interested developers have some idea of the feasibility of
setting up working groups, email lists, etc to develop more smoothly
operating "meta-packages".  As smaller developer communities develop perhaps
so will the flow of comments/suggestions/patches/integration, etc.

-kyle




This email message, including any attachments, is for the so...{{dropped}}