S4 class extension for backend implementation
Curated, evidence-grounded skill and software-tool collections for scientific AI agents, generated by the AgenticScienceBuilder
npx -y skills add HolobiomicsLab/asb-skill-collections --skill s4-class-extension-for-backend-implementationAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 14 stars14 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Use when you are building a new data representation or storage strategy for MS spectra (e.g., on-disk HDF5, SQL database, remote file access) and need to integrate it seamlessly into workflows that use the Spectra package.
The file declares its own license as CC-BY-4.0. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
10.0 KB, ~1.9k tokens by cl100k_base, as published. Nobody here has run it
s4-class-extension-for-backend-implementation
Summary
Design and implement a custom S4 class that extends the MsBackend virtual class to define a new backend representation for mass spectrometry data. This skill enables integration of alternative data storage strategies (e.g., on-disk, database, memory) into the Spectra ecosystem while decoupling data representation from analysis code.
When to use
You are building a new data representation or storage strategy for MS spectra (e.g., on-disk HDF5, SQL database, remote file access) and need to integrate it seamlessly into workflows that use the Spectra package. Use this when existing backends (MsBackendMemory, MsBackendMzR, MsBackendSql) do not match your storage constraints or data access patterns.
When NOT to use
- Your data already fits comfortably in memory and speed is the priority; use MsBackendMemory instead.
- You are importing MS data from a standard format (mzML, mzXML, CDF) with no custom access pattern; MsBackendMzR is sufficient.
- You only need to read-only access a SQL database without custom filtering or transformation; MsBackendSql or MsBackendMassbankSql are designed for this.
Inputs
- Raw MS data files (mzML, mzXML, CDF, or custom formats)
- Metadata defining spectra variables (e.g., precursor m/z, retention time, scan number)
- Peak data source (m/z and intensity pairs per spectrum)
Outputs
- Custom MsBackend S4 class instance with fully implemented required methods
- Spectra object linked to the custom backend via @backend slot
- Memory profile and chunk-wise processing benchmark results
How to apply
Create an S4 class that extends the MsBackend virtual class and define slots for spectra variables (as a DataFrame or data.frame) and peak data (m/z and intensity as NumericList or equivalent). Implement the required methods: backendInitialize() to load and prepare MS data from your source (e.g., raw files via MsBackendMzR, databases, or custom formats); spectraData() and spectraVariables() to expose all available metadata; peaksData(), intensity(), and mz() accessor methods to extract peak values; extractByIndex() and [ for subsetting; and backendMerge() for combining multiple instances. Ensure m/z values are sorted increasingly within each spectrum. For parallel processing efficiency, implement backendParallelFactor() to return a factor (typically based on dataStorage file paths) that enables chunk-wise processing rather than loading all peaks into memory. Test memory usage during chunk-wise versus whole-load scenarios to validate the overhead reduction.
Related tools
- Spectra (Provides the MsBackend virtual class, Spectra container, and integration framework for backends) — https://github.com/RforMassSpectrometry/Spectra
- MsBackendMzR (Reference backend implementation for on-disk peak data retrieval from mzML/mzXML/CDF; used as data source during backendInitialize()) — https://github.com/RforMassSpectrometry/Spectra
- S4Vectors (Provides DataFrame and NumericList classes for storing spectra variables and peak data in backend slots) — https://bioconductor.org/packages/release/bioc/html/S4Vectors.html
- IRanges (Complementary S4 infrastructure for range-based data manipulation in backend implementation)
Examples
setClass('MyMsBackend', contains='MsBackend', slots=c(spectraVars='data.frame', mz='NumericList', intensity='NumericList')); setMethod('backendInitialize', 'MyMsBackend', function(object, x, ...) { b <- backendInitialize(MsBackendMzR(), x); object@spectraVars <- spectraData(b); object@mz <- mz(b); object@intensity <- intensity(b); object }); sps <- Spectra(backendInitialize(new('MyMsBackend'), 'data.mzML'))
Evaluation signals
- All required MsBackend virtual methods are implemented and do not raise 'not implemented' errors when called on a Spectra object using your backend.
- peaksData() returns a list of matrices with m/z and intensity columns; row count per matrix matches the number of peaks in each spectrum.
- m/z values within each spectrum are sorted in increasing order (verifiable via lapply(peaksData(backend), function(x) is.unsorted(x[, 'mz'])) should return all FALSE).
- backendParallelFactor() returns a factor with length equal to the number of spectra, grouping spectra by dataStorage file path.
- Chunk-wise processing (using backendParallelFactor() to subset via extractByIndex()) consumes measurably less peak memory than loading all spectra peaksData() at once; memory reduction ≥ 20% for moderately sized datasets is typical.
Limitations
- The virtual MsBackend class requires implementation of all accessor and manipulation methods; partial implementations will fail when workflows attempt data access patterns you did not implement.
- Chunk-wise memory advantage only manifests if your backend does lazy loading of peak data; eagerly loading all peaks during backendInitialize() negates the memory benefit.
- Parallel processing via backendParallelFactor() assumes spectra are logically grouped by dataStorage (file path); custom grouping strategies require overriding this method.
- Read-only backends (those extending MsBackendCached) need not implement data replacement methods, but analysis workflows expecting mutable backends will fail silently or with cryptic errors if mutations are attempted.
Evidence
- [intro] To create a new backend a class extending the virtual
MsBackendneeds to be implemented.: "To create a new backend a class extending the virtualMsBackendneeds to be implemented." - [intro] Each
Spectraobject contains an implementation of such aMsBackendwithin its@backendslot which provides the MS data to theSpectraobject.: "EachSpectraobject contains an implementation of such aMsBackendwithin its@backendslot which provides the MS data to theSpectraobject." - [intro] The
MsBackendvirtual class defines the API that new backend classes need to implement in order to be used with theSpectraobject.: "TheMsBackendvirtual class defines the API that new backend classes need to implement in order to be used with theSpectraobject." - [intro] this separation allows to define new, alternative, data representations and integrate them seamlessly into a
Spectra-based data analysis workflow.: "this separation allows to define new, alternative, data representations and integrate them seamlessly into aSpectra-based data analysis workflow." - [intro] The
backendInitialize()method is expected to be called after creating an instance of the backend class and should prepare (initialize) the backend: "ThebackendInitialize()method is expected to be called after creating an instance of the backend class and should prepare (initialize) the backend" - [other] MsBackendMzR's backendParallelFactor() returns a factor based on dataStorage file names to split the backend for parallel or serial processing. Chunk-wise processing via this splitting reduces memory demand because only the peak data of the current chunk—not all spectra—needs to be realized in memory during operations.: "MsBackendMzR's backendParallelFactor() returns a factor based on dataStorage file names to split the backend for parallel or serial processing. Chunk-wise processing via this splitting reduces memory"
- [intro]
dataStorageanddataOriginare two special spectra variables that define for each spectrum where the data is stored and from where the data derived: "dataStorageanddataOriginare two special spectra variables that define for each spectrum where the data is stored and from where the data derived" - [intro] The
peaksData()method extracts the MS peaks data from a backend, which includes the m/z and intensity values of each MS peak of a spectrum.: "ThepeaksData()method extracts the MS peaks data from a backend, which includes the m/z and intensity values of each MS peak of a spectrum." - [intro] m/z values within each spectrum are expected to be sorted increasingly.: "m/z values within each spectrum are expected to be sorted increasingly."
- [intro] Backends such as the
MsBackendMzRfor example retrieve the data on the fly from the raw MS data files: "Backends such as theMsBackendMzRfor example retrieve the data on the fly from the raw MS data files" - [readme] Spectra provides different implementations (backends) to store mass spectrometry data. These comprise backends tuned for fast data access and processing and backends for very large data sets ensuring a small memory footprint.: "Spectra provides different implementations (backends) to store mass spectrometry data. These comprise backends tuned for fast data access and processing and backends for very large data sets"