Chapter 17 — FAIR Principles & Data Sharing

Author

Single Cell RNA-seq Workshop

Note

Where this chapter sits. Companion to Lecture 17 and Tutorial 17. Cross-reference: Appendix E — Gene-Expression Databases & File Formats, Appendix G — Methods Section Template.

17.1 Why this chapter is the closing chapter

Every paragraph of this workshop has been about generating good scRNA-seq results. This chapter is about preserving them — making sure that the data you’ve collected, the analysis you’ve done, and the conclusions you’ve drawn don’t disappear into a lab hard drive.

Done well, data sharing produces:

  • Citations. Reanalysis papers cite their input datasets. A well-deposited dataset is reused; reuse means citation.
  • Reproducibility. A reviewer asking “can I see your raw data?” gets a one-line answer.
  • Atlas integration. Your dataset can be pulled into HCA / CELLxGENE / Tabula Sapiens. Visibility you won’t get otherwise.
  • Funder compliance. NIH (2023+) and most major funders require a Data Management & Sharing Plan; FAIR-aligned plans pass review faster.

Done poorly, sharing produces nothing — the dataset sits in someone’s old lab drive, eventually unreadable, unused, eventually deleted.

The cost of doing FAIR is paid up-front during the project. The payoff is paid back over the rest of your career and the lifetime of the data. Skipping it feels efficient and is not.

17.2 The FAIR principles

Wilkinson et al.1 proposed four guiding principles for data management, summarized in Table 1.

Table 1: The four FAIR principles1. FAIR is not synonymous with “open” — FAIR data can be access-controlled while still satisfying all four criteria.
Principle One-line definition
Findable Data + metadata have a persistent identifier searchable in a registry
Accessible Anyone (or anyone authorized) can retrieve the data via an open protocol
Interoperable Data uses shared vocabularies so different datasets combine cleanly
Reusable Provenance + clear licence + sufficient metadata for reanalysis

FAIR is not “open” — FAIR data can be access-controlled (e.g. patient genomes in a controlled-access archive). The “A” requires that the protocol for access is open and standardized, not that the data itself is.

Every line in your data-deposition workflow should map back to one of these four. The most common failure is “I”; the most common omission is “F” (people deposit data without a stable identifier or without indexing it where searchers will look).

Note🔑 Key concept — the four FAIR principles in one idea

FAIR is a framework for making data reusable, not just accessible. Findable means giving data a stable, searchable identifier (a GEO accession, a DOI) so other researchers can discover it without already knowing it exists. Accessible means providing an open, documented protocol to retrieve the data — which can still require authentication for sensitive human data. Interoperable means using controlled vocabularies (Cell Ontology for cell types, Uberon for tissues, MONDO for diseases, EFO for assay types) so your dataset’s metadata can be joined to other datasets’ metadata without manual curation. Reusable means providing enough provenance — methods, software versions, sample metadata, a clear license — that an independent researcher could reproduce your analysis from your raw data. The “I” criterion is the one that most datasets fail: saying “B cells” in a free-text field rather than CL:0000236 means every downstream data integration requires a human to manually reconcile the term against every other study’s vocabulary. Ontology terms are what make computational atlases possible2.

FAIR in practice for scRNA-seq. The table above maps cleanly to specific choices in data deposition. For Findability: obtain a stable accession (GEO GSE, SRA PRJNA, or CELLxGENE slug) and register your dataset in at least one indexed repository — not just a lab website that may go offline. For Accessibility: make sure that not only the data but also the per-cell metadata is downloadable via standard protocols (HTTPS/FTP), and that the data remains accessible under controlled access if human-sensitive. For Interoperability: the CELLxGENE schema3 is the highest bar and most demanding interpreter of this criterion — its required ontology fields are the reason CELLxGENE can build an integrated atlas of millions of cells across thousands of studies. For Reusability: deposit analysis code to Zenodo or GitHub (with a DOI for archival), provide a methods section that specifies exact software versions, and include the canonical sample sheet that links every cell to its biological sample.

17.3 The repository ecosystem

For an scRNA-seq study you typically deposit in multiple repositories, each serving a different audience:

NCBI hierarchy (the canonical raw-data and processed-data archive)

  • BioProject (PRJNA######) — the study as a whole. One per paper.
  • BioSample (SAMN########) — each biological sample. Tissue, treatment, donor metadata lives here.
  • SRA (SRR#######) — the raw sequencing reads (FASTQs, BAMs).
  • GEO (GSE######)4 — the processed data: counts matrices, normalized files, expression metadata. GEO records pull SRA + BioSample IDs in.

For scRNA-seq, you create all four. The Appendix E reference card details what each one holds.

Single-cell-aware repositories

Beyond the generic raw archive, deposit in a scRNA-seq–native repository so the data is queryable as scRNA-seq. Table 2 summarizes the major options.

Table 2: Single-cell-aware repositories for scRNA-seq data deposition. The recommended workflow is triple-deposit: raw FASTQs to SRA, processed data to GEO, and AnnData to CELLxGENE.
Repository Run by What it accepts Strengths
CELLxGENE Discover3 CZI AnnData (.h5ad) with required metadata Browseable atlas, in-browser visualization, schema-validated
Human Cell Atlas Data Portal5 HCA Consortium Raw + processed, full provenance graph Strict QC, integrated atlas
Single Cell Expression Atlas EBI Counts + author annotations Curated, queryable per-gene across studies
Single Cell Portal Broad Institute Loose; raw + processed Easy upload, less curation

The recommended workflow in 2026: raw FASTQs to SRA + BioProject; processed data to GEO; AnnData with cell-type metadata to CELLxGENE. The triple-deposit is not redundant — each repository serves a different audience (raw-data reanalyzers, traditional bench biologists, single-cell-tool users).

17.4 The metadata is most of the work

You can’t reuse a counts matrix you can’t interpret. “Sample 1, Sample 2, Sample 3” is not metadata. At minimum, your metadata answers: who is the donor, what’s the tissue, what’s the condition, what’s the protocol, who processed it, when, with what library prep, on what machine, with what software version.

For human samples: also consent type, age range (often binned for de-identification), self-reported sex / gender, and ancestry.

The CELLxGENE schema3 is the most demanding of the major repositories and also the most reusable. Its insistence on ontology-typed fields is exactly what makes cross-dataset atlases possible2. The required fields are listed in Table 3; meeting this bar gets you GEO + HCA compatibility for free.

Three fields deserve a brief explanation that is easy to get wrong:

  • disease_ontology_term_id encodes the clinical disease state of the donor, not the experimental treatment. For an in vitro perturbation (IFN-β stimulation, a CRISPR knock-out), both the stimulated and unstimulated cells are biologically normal (PATO:0000461). The perturbation goes in a free-text treatment column alongside the required schema fields. Encoding an experimental treatment as a disease term breaks atlas integration.
  • is_primary_data is a Boolean flag: TRUE for data deposited by the generating lab for the first time; FALSE for a re-analysis of someone else’s data. This flag is how atlases avoid double-counting the same cells.
  • suspension_type distinguishes cell (dissociated whole cells, the usual case) from nucleus (single-nucleus RNA-seq / snRNA-seq). This field matters for atlas integration because snRNA-seq counts are systematically lower than scRNA-seq counts for the same cell type.

Why ontology terms matter for interoperability. When two independent labs deposit “B cells” in free-text fields, a computational tool cannot know whether both mean the same thing without human curation. But when both use CL:0000236, they are guaranteed to be using the same controlled definition from the Cell Ontology, which is maintained with a formal taxonomy. The ontology also carries hierarchical relationships: CL:0000236 (B cell) is a child of CL:0000945 (lymphocyte), so a query for “all lymphocytes” will automatically include B cells without needing to know all the specific child terms. This hierarchical querying is what makes large-scale meta-analyses and cell atlases computationally tractable2,6. The human Cell Ontology has ~2,500 cell types; most immune cell types have well-defined terms, while many tissue-specific or novel cell states require either choosing the closest parent term or working with the CL maintainers to add a new term.

Note🔑 Key concept — ontology terms make metadata machine-readable and atlas-compatible

An ontology is a controlled vocabulary with formal definitions and hierarchical relationships. When you label a cell type as CL:0000236 rather than “B cell,” you are linking your data to a shared, versioned, internationally-maintained definition. Any downstream tool, database, or analysis pipeline that understands the Cell Ontology can automatically infer that CL:0000236 is a lymphocyte, a blood cell, and a hematopoietic cell — and can join it with every other dataset that uses the same term. Free-text labels break this: “B-cell,” “Bcell,” “B_cell,” “mature B lymphocyte,” and “B cell” are all distinct strings to a computer but the same thing to a biologist. The CELLxGENE Discover schema requires ontology terms precisely because they are the technical prerequisite for building multi-million-cell integrated atlases.

Table 3: Required CELLxGENE schema fields3 and their controlled vocabularies. Ontology IDs are looked up at the Ontology Lookup Service. The mapping from “B cell” to CL:0000236 is what makes your dataset interoperable with every other CELLxGENE-deposited dataset.
Field Vocabulary
donor_id study-internal, anonymized
tissue + tissue_ontology_term_id Uberon (UBERON:0002048 = lung)
cell_type_ontology_term_id Cell Ontology (CL:0000236 = B cell)
disease_ontology_term_id MONDO or PATO:0000461 (normal)
assay_ontology_term_id EFO (EFO:0009922 = 10x 3’ v3)
organism_ontology_term_id NCBI Taxonomy (NCBITaxon:9606 = human)
sex_ontology_term_id PATO (PATO:0000383 female / PATO:0000384 male)
development_stage_ontology_term_id HsapDv (human) / MmusDv (mouse)
self_reported_ethnicity_ontology_term_id HANCESTRO
is_primary_data Boolean
suspension_type cell / nucleus

17.5 File formats and what to deposit

Table 4 lists the file types you should deposit at each layer of the data lifecycle.

Table 4: Recommended file formats for each layer of an scRNA-seq data deposition. AnnData (.h5ad) is the preferred archival format for annotated objects; .rds files are Seurat-version-locked and are not future-proof.
Layer Format Why
Raw reads .fastq.gz (paired or single-end) Universally supported
Aligned reads .bam + .bai Optional — useful for re-alignment
Per-cell counts .h5 (10x), .mtx + barcodes.tsv + features.tsv Cell Ranger output
Annotated object .h5ad (AnnData) preferred; .rds (Seurat) accepted by some CELLxGENE / scverse-native
Metadata sheet .csv / .tsv (also embedded in .h5ad via .obs) Sample-level + per-cell
Analysis code git repo (Zenodo for archival) Reproducibility
Warning

Seurat .rds files are not future-proof. They lock the data to the Seurat version that wrote them. For long-term archival use AnnData (.h5ad) — versioned, language-agnostic, HDF5-based, readable by Scanpy / Seurat 5 / anndata-rs.

Note⚙️ Key parameter — AnnData .h5ad vs. Seurat .rds for archival

Both .h5ad (AnnData) and .rds (Seurat) store an annotated single-cell object, but they have very different archival properties. .h5ad is an HDF5 file with a defined, versioned schema: the raw counts are in adata.X or adata.raw.X, normalized data in adata.layers, per-cell metadata in adata.obs, per-gene metadata in adata.var, and embeddings in adata.obsm. It can be read by Python (anndata), R (zellkonverter::readH5AD(), anndata, or SeuratDisk), Rust (anndata-rs), and the CELLxGENE browser — it is language-agnostic. .rds is an R binary serialization that includes the full Seurat object graph — but Seurat’s internal structure has changed substantially between v4 and v5, so a .rds written by Seurat 4 may not load in Seurat 5 without conversion. For a dataset that should remain usable in 2030, .h5ad is the correct choice for archival. The conversion from Seurat to AnnData is done via zellkonverter::writeH5AD() (recommended), sceasy::convertFormat(), or SeuratDisk::SaveH5Seurat() + SeuratDisk::Convert(). (Seurat itself does not ship a WriteH5AD() function.)

The CELLxGENE schema validation step. The CELLxGENE consortium provides a Python command-line validator (cellxgene-schema validate <file.h5ad>) that checks every required field, every ontology ID, and the overall structure of the .h5ad before submission. Running this validator is mandatory before attempting to submit to CELLxGENE Discover — the portal will reject non-conformant files. The validator is version-specific: the schema is updated periodically (v4, v5, …) and an .h5ad that passed an older validator version may not pass the current one. Always run the current validator, not a cached version from months earlier. Common validation failures include: missing required fields (e.g., suspension_type not added to the .obs frame), deprecated ontology IDs (cell type or disease ontology terms that were retired in a recent ontology release), and incorrect data types (e.g., is_primary_data stored as a string "TRUE" rather than a Boolean True).

Note⚙️ Key parameter — CELLxGENE schema / required fields and controlled vocabulary strictness

The CELLxGENE Discover schema (currently v5+) requires a specific set of per-cell columns in adata.obs, and each must use the exact controlled vocabulary specified. Required fields with no defaults: cell_type_ontology_term_id (Cell Ontology CL: prefix), tissue_ontology_term_id (Uberon UBERON: prefix), assay_ontology_term_id (EFO EFO: prefix), disease_ontology_term_id (MONDO MONDO: or PATO:0000461 for normal), organism_ontology_term_id (NCBITaxon), sex_ontology_term_id (PATO), is_primary_data (Boolean), and suspension_type ("cell" or "nucleus"). There is no fallback for missing or NA values — the validator will reject the file. Each ontology ID must be a currently valid, non-deprecated term in the appropriate ontology version used by the schema; IDs are versioned and can be deprecated in new ontology releases without notice. The practical workflow is: (1) look up current IDs at the EBI Ontology Lookup Service (https://www.ebi.ac.uk/ols4/); (2) add them to the per-cell metadata frame; (3) run cellxgene-schema validate locally before submission; (4) repeat until the validator passes cleanly.

17.6 Plan submission at experimental design time

The biggest mistake: thinking about deposition only after the manuscript is in revision. By then:

  • Sample-level metadata is buried in lab notebooks across multiple students
  • Ontology terms have to be reverse-engineered from sketchy memory
  • You need to chase three former rotation students for their consent forms

Do this instead: at experimental design time, build the canonical sample sheet (Tutorial 17 ships a template). Include every field you’ll need at deposition. Version-control it alongside your code. As samples come in, update the sheet. At the end of the project, the sheet is your BioSample / SRA / GEO upload.

This single discipline will save you a week of frantic data archeology at submission time.

17.6b Design consideration: one canonical sheet as the single source of truth

The three NCBI upload templates (BioSample, SRA, and GEO) all use sample_id as the join key that links records across portals. NCBI’s accession-linking is case-sensitive and literal: “donor1_CTRL” and “Donor1_CTRL” will not link. Manual transcription of sample names across three spreadsheets is the single most common cause of broken cross-links in a submission.

The solution is to maintain one canonical sample sheet in version control and programmatically derive all upload templates from it with transmute() or equivalent. Every name, date, and ontology ID appears in one place; all three submissions are generated from the same object. Inconsistencies must be fixed in the sheet — they then propagate correctly to all outputs. Tutorial 17 demonstrates this pattern end-to-end.

17.7 The end-to-end submission workflow

Eight steps:

  1. Plan. Build the canonical sample sheet at design time.
  2. Create BioProject (one per study) at submit.ncbi.nlm.nih.gov. Get a PRJNA######.
  3. Create BioSamples (one per sample). Batch-upload .tsv from the canonical sheet. Each gets a SAMN########.
  4. Submit raw .fastq.gz to SRA. Each sequencing run gets an SRR#######. Link each to its SAMN.
  5. Analyze the data. This is the rest of the workshop.
  6. Submit processed counts + per-cell metadata to GEO. Get a GSE######. Link to BioProject + SRA.
  7. Convert Seurat → AnnData and submit to CELLxGENE Discover. Schema-validate first; iterate until the validator passes.
  8. Cite all accessions in your manuscript’s Data Availability section.

Tutorial 17 walks all of this hands-on, generating the BioSample / SRA / GEO upload .tsv files and the AnnData from the workshop’s ifnb_annotated_final.rds.

17.8 Common errors

Table 5 collects the errors most commonly encountered during FAIR metadata preparation and submission, their causes, and the fix.

Table 5: Common FAIR data-deposition errors, their underlying causes, and fixes.
You see What’s wrong What to do
SeuratDisk::SaveH5Seurat fails Seurat v5 Assay5 not supported by old SeuratDisk Use the dev branch: remotes::install_github("mojaveazure/seurat-disk")
bitr returns empty Case mismatch (Cd3d vs CD3D) or wrong organism DB Check; use org.Mm.eg.db for mouse
CELLxGENE validator: “ontology term not found” Ontology IDs get updated periodically Look up current IDs at ols4
Validator passes locally but submission portal rejects Schema version updates faster than your local validator Check current schema before submitting
“Inconsistent sample names” between BioSample / SRA / GEO sheets Manual transcription error Always derive all sheets from a single canonical sheet programmatically

17.9 Where this material is also discussed

  • Lecture: Lecture 17
  • Tutorial: Tutorial 17
  • Database & file-format reference: Appendix E
  • Methods-section template (the “Data availability” paragraph): Appendix G
  • scNotebooks Module 13 — parallel walkthrough

17.10 Going further

The principles come from the FAIR paper1; the single-cell infrastructure that operationalizes them is the Human Cell Atlas5, its cell-type ontology standards2, and the CZ CELLxGENE Discover platform3 (whose schema is documented at github.com/chanzuckerberg/single-cell-curation). The canonical raw/processed archive is NCBI GEO/SRA4, and large reference atlases such as Tabula Sapiens6 show what well-shared data enables. Also consult the NIH Data Management & Sharing Policy (2023), required for all NIH-funded studies. The full curated list is on Key Papers, Reviews & Benchmarks.

References

1.
Wilkinson, M. D. et al. The FAIR guiding principles for scientific data management and stewardship. Scientific Data 3, 160018 (2016).
2.
Osumi-Sutherland, D. et al. Cell type ontologies of the human cell atlas. Nature Cell Biology 23, 1129–1135 (2021).
3.
CZI Cell Science Program et al. CZ CELLxGENE discover: A single-cell data platform for scalable exploration, analysis and modeling of aggregated data. Nucleic Acids Research 53, D886–D900 (2025).
4.
Barrett, T. et al. NCBI GEO: Archive for functional genomics data sets—update. Nucleic Acids Research 41, D991–D995 (2013).
5.
Regev, A. et al. The human cell atlas. eLife 6, e27041 (2017).
6.
Tabula Sapiens Consortium. The tabula sapiens: A multiple-organ, single-cell transcriptomic atlas of humans. Science 376, eabl4896 (2022).
Back to top