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

[Vincent Carey 525-2265]

> reward package fragmentation rather than reducing the number of packages. A

as long as we allow association of packages to any relevant terms the
ontology/view system does not reward any approach to package design.

> package ontology needs to be done very well indeed, but someone who has
> taken time to understand all the packages well, otherwise it risks being a
> hindrance rather than a help. I don't think that the list of terms that
> Vince currently has will do the job.

please supply a termlist (better, a DAG of terms) that will do a better job.
i have been working on a general infrastructure for this problem: we build
a graph representing the vocabulary, we have a primitive GUI
that allows a curator to associate any package with any number
of terms in the graph, we build XML documents describing the views
according to ctv's model, and then ctv infrastructure builds a set
of html pages.  in principle anyone can make their own view set
with these tools.  if we can fold the package annotation problem into
maintenance/development, there is minimal need for a centralized
curator.  biocore can be asked to vote from time to time on
specific conflicts between developers' characterizations
if such arise.

>
> 1. The terms in the ontology need to stay fairly broad. Drilling down into
> small topics with just one or two packages in them tends to hide package
> overlaps, not display them.

if someone is interested in a very specific topic and the view
association is accurate, i do not see why this is a problem.
as long as the broad terms are available and are properly used,
a surveyor will observe the overlaps when visiting views of
broad concepts.  associated commentary at
the view level can also help describe the landscape and interactions
between package concepts.

>
> 2. In order to be useful to users, the ontologies needs to focus on
> processes that users want to do, not on mathematical concepts. A user
> doesn't seek to fit a linear model for example, but they might want to
> analyse a microarray experiments with multiple RNA sources. They certainly
> don't start out wanting to fit an Error Model ...

fair enough, this first attempt has been advertised as highly
tentative.

>
> >  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.
>
> The idea of an expert in the field editing the work of the developers
> really fills me with trepidation. Who are the experts if not the developers
> themselves? I don't think that anyone could claim to know what all the

as long as the terminology system is available to them it seems
reasonable to hold the developers as the experts for annotation
purposes.  but it is not necessarily the case that a developer
can create/curate the ontology, so some other locus is needed.

> packages do. I think that the Harvard and Seattle BioC maintainers should
> be very cautious about putting themselves forward as experts in this sense.

agreed.

>
> If the "task view" remains a relaxed view like what is currently in the
> BioC faq web page, then I am happy for it to be done by a BioC maintainer.
> If a detailed package ontology is envisaged, then it needs to be done by
> the package developers themselves.

one simple way to proceed is to identify the unobjectionable subgraph
of the current graph and to verify the associations already made.  i
will revise the view set to this restriction and we will republish.

i hope to check in biocViews infrastructure package, with a vignette
that illustrates the whole process, later today.

thanks very much for your assistance.