[Bioc-devel] biocViews preprocessing term

[Vincent Carey 525-2265]

Thanks for carrying on this thread, Patrick,
looks like I got distracted.

Now I see how the vocabulary is maintained.
biocViews/inst/dot has a nice human-readable rendering
of the vocabulary in biocViewsVocab.dot

Each node reference in the dot is a topic, and any
node in that dot file can be used as a biocViews
field value in the package.

Florian, would you like to make the changes to
biocViews/inst/dot that reflect your desired vocabulary
modifications, rebuild the vocabulary using biocViews/updateVocab.sh,
and then commit the modified biocViews package (with a bump to the
version tag in DESCRIPTION)?  It would be nice to have some
mechanism of testing that the build system will survive such
a change (perhaps testing some validity conditions on the new
graph, such as 1 connected component, all nodes are syntactic
atoms, checking the correspondence between biocViews fields
present in the repository and the nodes in the graph).

I will do the changes mentioned in Florian's e-mail and commit
if people want to funnel this through me ...

---
Vince Carey, PhD
Assoc. Prof Med (Biostatistics)
Harvard Medical School
Channing Laboratory - ph 6175252265 fa 6177311541
181 Longwood Ave Boston MA 02115 USA
stvjc at channing.harvard.edu

On Wed, 3 Sep 2008, Patrick Aboyoun wrote:

> On the second point, the build system uses the ontology in biocViews and
> will adapt accordingly when biocViews is changed. Any vocabulary term
> that is not recognized by biocViews will be ignored and an internal
> build warning will be issued. Periodically I check the ignored terms to
> see if this is due to misspellings (which I correct), but in some
> situations packages include categories that don't exist. If changes are
> made to the ontology, package authors can modify their biocViews
> DESCRIPTION field prior to changes being made to biocViews without any
> adverse build outcome.
>
>
> Patrick
>
>
>
> Vincent Carey 525-2265 wrote:
> > yes in specific, and although you did not ask it does
> > appear that we need some renovation of the biocViews
> > vocabulary.
> >
> > alas i am not really clear on how modifications to the
> > vocabulary impact the build system.  i will take a look
> > at this and make a proposal momentarily.
> >
> > ---
> > Vince Carey, PhD
> > Assoc. Prof Med (Biostatistics)
> > Harvard Medical School
> > Channing Laboratory - ph 6175252265 fa 6177311541
> > 181 Longwood Ave Boston MA 02115 USA
> > stvjc at channing.harvard.edu
> >
> > On Tue, 2 Sep 2008, Florian Hahne wrote:
> >
> >
> >> Hi Vince,
> >> the cellHTS and cellHTS2 package provide (mostly) preprocessing
> >> functionality for cell-based assays, and assigning the biocViews term
> >> "Preprocessing" seems to be reasonable. However, in the ontology this is
> >> defined as "Microarray -> Preprocessing;", and that's not really what we
> >> want. Shouldn't there be a general "Preprocessing" term independent of
> >> micro arrays. I guess this will also become interesting for many of the
> >> other emerging new technologies like deep sequencing. With the current
> >> design, it seems this is not possible, since terms have to be
> >> unambiguous. Is there any reasonable way of dealing with this problem
> >> other than adding a new term like "General Preprocessing"? And wouldn't
> >> it be useful to allow for terms like "Technology -> FlowCytometry
> >> ->Preprocessing;"
> >>
> >> Florian
> >>
> >> --
> >> Florian Hahne, PhD
> >> Computational Biology Program
> >> Division of Public Health Sciences
> >> Fred Hutchinson Cancer Research Center
> >> 1100 Fairview Ave. N, M2-B876
> >> PO Box 19024
> >> Seattle, Washington 98109-1024
> >> 206-667-3148
> >> fhahne at fhcrc.org
> >>
> >>
> >>
> >
> > _______________________________________________
> > Bioc-devel at stat.math.ethz.ch mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >
>
>
>
>
>
>