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

[Furge, Kyle]

Vincent, 

It seems the discussion has moved on significantly since I last had a chance
to partake, but I did not want to leave you without a response.

I think the point I was attempting to made has been more elegantly made by
you and others in the meantime. In choosing between between consistency
derived by raising barriers verses consistency derived by providing an
environment for improved training/interaction, I was advocating the later.
However, others may disagree with this approach or advocate a parallel
approach.

The specifics of the ArrayCGH TaskView seem likely to be addressed at
another time, so I will defer making suggestions (if desired) until then.
However, I would be remiss if I did not mention that I have quite happily
used several of the packages already, including Jane Fridlyand's excellent
aCGH package. We generated a number of figures in a recent BMC Genomics
paper using this package.

-kyle

> From: Vincent Carey 525-2265 <stvjc at channing.harvard.edu>
> Date: Fri, 5 Aug 2005 14:19:56 -0400 (EDT)
> To: "Furge, Kyle" <Kyle.Furge at vai.org>
> Cc: Matthias Futschik <m.futschik at biologie.hu-berlin.de>, Bioconductor
> Development <bioc-devel at stat.math.ethz.ch>
> Subject: Re: [Bioc-devel] Invitation to the bioC developers Meeting in Seattle
> Mon 15 Aug
> 
>>> 
>>> 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
> 


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