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

[Vincent Carey 525-2265]

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

Thanks for the comments.  This particular set of packages has been
of interest to me for assessment of redundancies and for thinking about
how to get developers to pool resources and unify the products.  I have
not had time to look closely at the packages however so I have no
recommendations yet.

Are the data formats and approaches to annotation the key problem?
Would conversion resources make it easier to deal with three
packages that deal with array CGH data analysis?  Are there other
reasons to ask for a more unified approach?  These are not rhetorical
questions.

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

Agreed.  But we can make it easier for developers to meet high standards
by coming up with guidance documents and having some sort of formal
evaluation from time to time.  I would like to see an extension to
"Writing R Extensions", called "Writing Bioconductor Packages", which would
deal with the extra steps that should be taken to make a package fit
best with the project as a whole.

>
> Practically (even though I am guilty as others for lack of effort) I think a
> requirement for package inclusion *should* be relevant biocViews

We will do this once the view set matures.

> 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

Let's not come up with another term if we don't need one.  Task views
seems to be working nicely at CRAN (see the button on the main CRAN
page); we are adding a view terminology graph to that technology.
Your "meta-package" corresponds, I think, to a task view, and we will
need view maintainers who keep an eye on package evolution and provide
some textual guidance to view visitors.

> so will the flow of comments/suggestions/patches/integration, etc.
>
> -kyle