[Bioc-devel] biocViews preprocessing term

[Vincent Carey 525-2265]

On Sun, 7 Sep 2008, Florian Hahne wrote:

> Sure, I can do that. Just need to figure out if there is an easy way
> to parse through the whole repository, I hope that Patrick can help
> with that. However, I still don't see how one would specify a term
> like flow cytometry -> preprocessing in the DESCRIPTION file. Or do yo
> mean unique node names by syntactic atoms? So far, only the leaf node
> seems to be used to assign a package to a category.

we can certainly do something like flowCytometry -> flowPreprocessing
[you might even be able to embed a blank; the code was written before backticks
were well established]

however, sharing "Preprocessing" between view paths isn't going to work
without additional structure -- either namespaces or a distinction
between nodename and displayname ... the node names need to be unique,
not so the display names.  personally i don't want to go down this
path but repurposing namespace technology would definitely be a fun
and rewarding project for someone with some time and energy.

> Florian
>
>
> On 03.09.2008, at 03:42, Vincent Carey 525-2265 wrote:
>
> > 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
> >>>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> > _______________________________________________
> > Bioc-devel at stat.math.ethz.ch mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
>