Packages added to the Bioconductor Project require a
field in their DESCRIPTION file. The field name “biocViews” is
case-sensitive and must begin with a lower-case ‘b’.
biocViews terms are “keywords” used to describe a given package. They are broadly divided into four categories, representing the type of packages present in the Bioconductor Project
- Annotation Data
- Experiment Data
biocViews are available for the release and devel branches of Bioconductor. The devel branch has a check box under the tree structure which, when checked, displays biocViews that are defined but not used by any package, in addition to biocViews that are in use. See also description section
One can use biocViews for two broad purposes.
A researcher might want to identify all packages in the Bioconductor Project which are related to a specific purpose. For example, one may want to look for all packages related to “Copy Number Variants”.
During development, a package contributor can “tag” their package with biocViews so that when someone looking for packages (like in scenario 1) can easily find their package.
Visit the ‘devel’ biocViews when you are in the process of adding biocViews to your new package. Identify as many terms as appropriate from the hierarchy. Prefer ‘leaf’ terms at the end of the hierarchy, over more inclusive terms. Remember to check the box displaying all available terms.
Your package will belong to only one part of Bioconductor Project (Software, Annotation Data, Experiment Data, Workflow), so choose only biocViews from that category.
biocViews listed in your package must match exactly (e.g., spelling, capitalization) the terms in the biocViews hierarchy.
When you submit your new package for review , your package is checked and built by the Bioconductor Project. We check the following for biocViews:
Package contributor has added biocViews.
biocViews are valid.
Package contributor has added biocViews from only one of the categories.
If you receive a “RECOMMENDED” direction for any of these biocViews after you have submitted your package, you can try correcting them on your own following the directions given here or ask your package reviewer for more information.
If a developer thinks a biocViews term should be added to the current acceptable list, please email firstname.lastname@example.org requesting the new biocView, under which hierarchy the term should be placed, and the justification for the new term.
We strongly recommend reusing existing methods for importing data, and reusing established classes for representing data. Here are some suggestions for importing different file types and commonly used Bioconductor classes. For more classes and functionality also try searching in biocViews for your data type.
- GTF, GFF, BED, BigWig, etc., – rtracklayer
- VCF – VariantAnnotation
- SAM / BAM – Rsamtools
- FASTA – Biostrings
- FASTQ – ShortRead
- MS data (XML-based and mgf formats) – Spectra
::Spectra(source = MsBackendMgf::MsBackendMgf()), MSnbase
- Rectangular feature x sample data –
::SummarizedExperiment()(RNAseq count matrix, microarray, …)
- Genomic coordinates – GenomicRanges
::GRanges()(1-based, closed interval)
- Genomic coordinates from multiple samples –
- Ragged genomic coordinates – RaggedExperiment
- DNA / RNA / AA sequences – Biostrings
- Gene sets – BiocSet
- Multi-omics data –
- Single cell data –
- Mass spec data – Spectra
In general, a package will not be accepted if it does not show interoperability with the current Bioconductor ecosystem.
Every submitted Bioconductor package should have at least one Rmd (preferred) or
Rnw vignette, ideally utilizing
BiocStyle::html_document as output
rendering. This should include evaluated R package code and a detailed
introduction/abstract section that provides motivation for inclusion in
Bioconductor and when appropriate a review and comparison to existing
Bioconductor packages with similar functionality or scope. See vignette
documentation section for more details.