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