[Bioc-devel] ANN: BioC Developer's Meeting/agenda/discussion

[Robert Gentleman]

Hi,

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

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.

  Best wishes
   Robert

Best wishes,
   Robert



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
>>>
>>>this catalog.
>>>
>>>The first task view rendering can now be seen at
>>>http://www.biostat.harvard.edu/~carey/top.html
>>>
>>>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.
>>
>>Gordon
> 
> 
> 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
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>