[Bioc-devel] ANN: BioC Developer's Meeting/agenda/discussion
rgentlem at fhcrc.org
Sun Jul 17 20:24:59 CEST 2005
To amplify a bit on both Gordon and Vince's comments. Yes packages
should be mentioned in multiple places, but there are also reasons to
split functionality into separate packages so that users have more
choice about methods that they use (this has always been a strength of R
and one that I am much in favor of) and the situations in which they use
them. But that said, we still need a mechanism that will allow for
multiple listings, one that lets package authors control the comments
and as Vince suggested, different comments for different headings does
seem worthwile, but not necessary.
Also, I think Achim had mostly a CRAN view in mind when designing ctv
(hence its name) and while that view (where most packages do only one
thing and package dependencies are rare and not very complicated) is a
pretty good one for CRAN, it is less good for Bioconductor where there
are both more dependencies and more multi-purpose packages. So I think
some changes would be helpful, or perhaps the two repositories are so
different that we need a btv :-)
We almost surely need some standard markup for the package author to
write what they want to have seen, once some vague notion of task views
are set up. My very strong preference is to do this in XML since there
are good tools for parsing and working with it. Quite possible in
inst/ctv would be a sensible spot so that it was available after
installation (although that might not be necessary). It would be very
straight forward to write some code to put in ctv that wrote one of
these out from basic user input, no need for them to know XML and
someone could surely write a widget in tcl/tk if they were so inclined.
Life would be much simpler with an ontology, but that does not seem
likely to appear in any short order but perhaps we could decide if we
like the terms that Vince has used, and if there are any other
extensions. In some sense these belong either in ctv, or some other
place so that new developers have easy access to them (and no I don't
think we should use the KEYWORDS file in R; I have to say I find that
mechanism distinctly unhelpful). Gordon, do you have input on the
hierarchy of terms? And do you think it would be useful to have package
developers add themselves in and out, or should this be done by the
Initially there were some arguments against developers doing it, as we
might want to have the view managed by an expert in the field who could
also give recommendations.
Vincent Carey 525-2265 wrote:
>>>>> (or competing with) each other.
>>>>Yes, the task view catalog that I have established will help identify
>>>>these competitions more conveniently. I will shortly post links to
>>>The first task view rendering can now be seen at
>>>comments welcome. this was a fairly haphazard construction
>>>of topic-set and mapping to packages.
>>Are you trying to put each package into one and only one category? I think
> definitely not -- but that is a limitation of this first attempt
>>that this approach tends to emphasis fragmentation rather than unity and
>>doesn't do justice to packages with virtual integration. Topics like
>>"Bayes", "linear modelling", "factorial design", "differential expression"
>>and "multiple testing", for example, don't split into non-overlapping
>>topics. Rather they are all aspects of the same thing. Pre-processing and
>>normalization is somewhat more separate, but even this interacts deeply
>>with the same topics.
>>I suggest that a grouping into larger and not mutually exclusive groups
>>might be more helpful.
>>Here are some specific problems:
>>The limma package isn't mentioned under "Bayesian", "FactorialDesigns",
>>"TimeSeries" or "MultipleTesting", even though it is probably the most used
>>package in each of these categories.
>>Limma isn't mentioned anywhere in any of the Preprocessing categories,
>>although it is one of the most used packages for non-affy pre-processing.
>>The preprocessing package arrayMagic package, for example, calls limma
>>functions to do normalization and pre-processing.
>>How are "ErrorModels" different from statistical models used to assess
>>differential expression? The LPE and plgem packages should surely get a
>>mention under differential expression rather than here. The LPE package is
>>very similar in spirit to the empirical Bayes approach for differential
>>expression, and should be grouped somewhere with packages like limma,
>>EBayes, siggenes etc.
>>twilight is another package which seems to me to be doing differential
>>expression, but is currently only listed under "MultipleTesting".
>>What sort of graphics is included under "Visualization"? Many of the
>>packages with pre-processing functionality including plotting functions,
>>including marray, limma, arrayMagic.
> all that you say is true. i will soon have the ability
> for a package to lie in indefinitely many views. i want to
> hear more dialogue on how the view set can be made more
> faithful to creators' intentions, and on which packages
> should be associated with which views.
> ultimately the view association efforts have to go back
> to the developers, with curation at the repository level.
> you'll be able to say which views you want your packages
> to be associated with, and with what comments.
> the metadata about a package that is presented with a
> view should vary from view to view. this is a job the
> maintainer/developer should think about. as you say,
> limma can be used for preprocessing and for visualization,
> but the comments associated with the view entry for each
> of these should be specific to the view. (i don't have a
> comment-associating mechanism yet, but we need one)
> this is very early but could move rapidly to something useful
> if we do it well.
> Bioc-devel at stat.math.ethz.ch mailing list
More information about the Bioc-devel