---
title: 'SSBD Ontology: Bioimaging Metadata Framework'
url: https://www.emergentmind.com/topics/ssbd-ontology
type: topic
---

# SSBD Ontology: Bioimaging Metadata Framework

Searching arXiv for the SSBD Ontology paper and closely related naming variants.
The **SSBD Ontology** is an **OWL 2–based, two-tier metadata framework** for the **Systems Science of Biological Dynamics Database (SSBD)** that is intended to make **diverse, multidimensional bioimaging datasets interoperable and reusable**. Its central design decision is a separation between a **class-centric core layer**, which references existing biomedical ontologies and supports reasoning and validation, and an **instance layer**, which represents actual imaging dataset information as RDF individuals explicitly linked to the core classes. This architecture is designed to reconcile two operational requirements within the same platform: **rapid dataset publication with minimal metadata** in **SSBD:repository** and **value-added, richly annotated curation** in **SSBD:database**. The ontology is aligned with **REMBI**, integrates external biomedical ontologies, and supports advanced semantic queries over projects, datasets, biosamples, imaging methods, instruments, dimensional metadata, and cloud-accessible image assets [2508.02084].

## 1. Scope, naming, and domain position

In its strict usage, **SSBD Ontology** denotes the ontology-driven framework for interoperable bioimaging metadata used by **RIKEN’s Systems Science of Biological Dynamics Database**. It is explicitly described as a **two-tier metadata framework** for **heterogeneous metadata vocabularies across repositories** and for the tension between **rapid, minimally annotated data release** and **richly annotated, high-value datasets needed for discovery** [2508.02084].

A recurrent source of confusion is terminological rather than conceptual. **SSDOnt** is a distinct ontology for **Single-Subject Design studies**, implemented in **OWL 2 DL** for representing phases, interventions, outcomes, participants, and results in single-case research [2401.14933]. By contrast, **SSbD** in the smart-fab literature refers to **Safe and Sustainable by Design**, a governance framework involving trusted industrial data spaces, professional proxies, and compliance tokens, rather than a bioimaging metadata ontology [2606.09227]. This suggests that references to “SSBD Ontology” should ordinarily be interpreted as the **bioimaging ontology for SSBD**, not as a synonym for either **SSDOnt** or **SSbD**.

The ontology is positioned as part of the **foundingGIDE harmonization effort** and as an infrastructure component for a **Findable, Accessible, Interoperable, and Reusable** data ecosystem within the bioimaging community [2508.02084].

## 2. Two-tier architecture and design rationale

The ontology is explicitly organized into a **core layer** and an **instance layer**. The **core layer** is a **hierarchy of classes and properties defined in OWL 2 and anchored to OBO Foundry ontologies**, designed for **open-world reasoning, cross-ontology alignment, and SHACL validation**. The **instance layer** encodes actual datasets and related entities as **RDF individuals** typed by the core classes and connected through object and data property assertions [2508.02084].

This architectural split is matched to the reorganized SSBD platform. **SSBD:repository** supports **rapid publication at paper submission time with minimal metadata**. Its schema centers on **project, dataset, paper information, and person**, and it uses **simple, essential relationships and a small set of required fields**. **SSBD:database**, by contrast, is a **value-added tier** in which datasets are enriched with **detailed biological and imaging annotations using controlled vocabularies and external ontologies**, enabling deeper reuse and semantic discovery [2508.02084].

The paper frames this as a deliberate balance between **flexibility** and **rigor**. Flexibility is provided by the instance layer, which can represent **heterogeneous, dataset-specific facts**, including different imaging modalities, variable instrument subcomponents, and multiple tags. Rigor is provided by the core layer through **domain/range and cardinality patterns in OWL**, together with **SHACL shapes checking required fields for rapid-release records**. A plausible implication is that the ontology is intended not merely as a vocabulary, but as a curation and validation scaffold for incremental metadata maturation.

The formal constraints illustrate this design. For example, **Project** is constrained by **has_paper_information exactly 1 PaperInformation**, **has_dataset_output min 1 Dataset**, and **has_project_participant min 1 Person**. **Dataset** is constrained by **has_biosample_information min 1 BiosampleInformation**, **has_imaging_method_total_information min 1 ImagingMethodInformation**, and **has_dimension_information min 1 DimensionData** [2508.02084].

## 3. Core classes, properties, and semantic coverage

The core schema covers bibliographic, biological, imaging, storage, and dimensional aspects of imaging datasets. The principal classes are **Project**, **Dataset**, **PaperInformation**, **Person**, **BiosampleInformation**, **ImagingMethodInformation**, **ImagingInstruments**, **OME-NGFF-ZARR_Information**, and **DimensionData** [2508.02084].

**Project** is the top-level container for related datasets and bibliographic context. **Dataset** is the imaging dataset entity and serves as the hub for links to biosample information, imaging method metadata, OME-Zarr locations, and dimensional data. **PaperInformation** stores title, DOI, PMID, URL, and **MeSH** topical descriptors. **Person** includes contributor and author records with identifiers such as **ORCID**, and the paper also lists **J_Global_id** and **researchermap_id** among the represented identifiers [2508.02084].

The biosample layer is carried by **BiosampleInformation**, which includes **organism, strain, anatomical structure, cell type, cell line, genetic modifications, and reagents**. Related classes such as **GeneticModification** and **ReagentInformation** capture fields such as **gene_name**, **genotype**, **method**, **Ensembl_gene_ID**, **UniProt_ID**, **reagent_term**, **reagent_url**, **concentration**, **concentration_unit**, **fold_dilution**, **tag_uri**, and **oligo_primer** [2508.02084].

The imaging layer is modeled through **ImagingMethodInformation** and **ImagingInstruments**. The ontology represents **modality**, **detection method**, **illumination**, **contrast sources**, **resolution-enhancing method**, **visualization method**, and **imaged parameters**. Instrument structure includes **device_body**, **device_module**, **device_objective**, **detector**, **light_source**, **filter set**, and **device_dichroic**. This enables representation of image-acquisition details such as **laser wavelength**, **power**, **magnification**, **numerical aperture**, and **detector type**, where available [2508.02084].

The storage and access layer is modeled by **OME-NGFF-ZARR_Information**, which links datasets to **s3_endpoint_url**, **vizarr_url**, **thumbnail_url**, and **file_sets_url**. Dimensional and sampling metadata are captured by **DimensionData**, including **x_dimension_data**, **y_dimension_data**, **z_dimension_data**, **xyzct**, and **time_scale_data** [2508.02084].

Representative object properties include **has_dataset_output**, **has_paper_information**, **has_project_participant**, **has_biosample_information**, **has_imaging_method_total_information**, **has_instrument_information**, **has_ome_zarr_information**, **has_dimension_information**, **is_about_organism**, **is_about_strain**, **has_genetic_modification**, **has_reagent_information**, **has_detection_method**, **has_imaging_method_recorded_type**, and **has_tag**. Notably, **has_project_participant** is declared as a **sub-property of RO:0000057 from Relation Ontology**, which situates participation semantics within a broader interoperable framework [2508.02084].

## 4. Alignment with external ontologies and metadata standards

A defining feature of the SSBD Ontology is its selective reuse of external ontologies and vocabularies. The core layer references **OBO Foundry ontologies**, including **Gene Ontology (GO)**, **Cell Ontology (CL)**, **UBERON**, **Cell Line Ontology (CLO)**, **NCBI Taxonomy (NCBITAXON)**, and **MONDO**. It also aligns with **Relation Ontology (RO)**, **FBbi**, **MeSH**, and **OME-NGFF / OME-Zarr** [2508.02084].

These alignments are operational rather than merely declarative. **is_about_organism** can link a biosample to **NCBITaxon:10090**. **has_imaging_method_recorded_type** can link to **FBbi:00000246 fluorescence microscopy**. **has_detection_method** can link to **FBbi:00000304 CMOS**. **has_tag** can link to **FBbi:00000477 VenusFP** or **FBbi:00000082 EGFP**. **is_about_strain** can link to a **JAX:000664** strain identifier. Paper records are enriched with **MeSH Topical Descriptors via PubMed** [2508.02084].

The ontology also states that **SSBD metadata version 3 complies with REMBI**, and the core layer is designed to cover REMBI fields. These include **study-level identifiers and contacts**, **sample description**, **imaging instrument and modality**, **image acquisition parameters and dimensions**, **data access and formats**, and **publication links**. The REMBI alignment is expressed through specific class mappings: **Project** and **Person** for contacts and identifiers; **BiosampleInformation** for organism, strain, anatomical structure, cell type, cell line, genetic modification, and reagents; **ImagingMethodInformation** and **ImagingInstruments** for modality and instrument descriptors; **DimensionData** for x/y/z and temporal scaling; **OME-NGFF-ZARR_Information** for access endpoints; and **PaperInformation** for DOI, PubMed, and MeSH [2508.02084].

This suggests that SSBD Ontology functions as a semantic superstructure over checklist-style metadata. Rather than replacing formats such as **OME-Zarr**, it adds the biological, bibliographic, and ontological relations needed for cross-dataset discovery and knowledge-graph integration.

## 5. Curation workflow, instance modeling, and query capabilities

The curation workflow is described in **Section 2.2** of the paper. **Domain curators populate spreadsheet templates**, **imaging experts review**, and **an ontologist translates the curated sheets into OWL/RDF**, reusing **OBO Foundry classes**, establishing object properties, and generating instance-level assertions. The paper characterizes this as a **curator–ontologist complementary workflow** that bridges rapid data ingestion and later semantic enrichment [2508.02084].

The instance layer makes the ontology operational. A concrete example in the paper shows **project-199** containing **dataset-199-Fig2_BrainSliceRGB**, linked to a biosample annotated with **NCBITaxon:10090 Mus musculus** and **JAX:000664 C57BL/6J**, to imaging metadata including **FBbi:00000246 fluorescence microscopy** and **FBbi:00000304 CMOS detection**, and to an **OME-Zarr** location with **S3 endpoints** and **Vizarr URLs** [2508.02084].

The ontology is deployed in **Apache Jena Fuseki (4.7.0)** with core and instance data, enabling competency queries. Three representative use cases are reported. First, a **species-specific dataset search** for **Homo sapiens (NCBITaxon:9606)** returned **12 human-derived datasets**. Second, a **cross-modality comparison for a shared strain** retrieved datasets annotated with **JAX:000664 (C57BL/6J)** and listed distinct imaging modalities with **Vizarr URLs** for side-by-side comparison. Third, a **federated cross-ontology query** linked biosamples annotated with **GO:0005739 (mitochondrion)** to **MONDO** diseases defined via **RO:0004020 “disease has basis in dysfunction of”**, returning diseases such as **MONDO:0004069** and **MONDO:0044970** [2508.02084].

The paper further notes an operational workflow in which **semantic discovery via SPARQL** is followed by **programmatic streaming of OME-Zarr images and BDZarr quantitative tables into Python/Napari for analysis**, supporting **cross-study phenotype screening and morphometrics**. A plausible implication is that the ontology is intended to support both retrieval and downstream computational analysis, rather than acting solely as catalog metadata.

## 6. FAIR support, implementation status, and limitations

The ontology is presented as a FAIR-enabling infrastructure. **Findability** is supported by links between datasets, projects, and publications, a public **SPARQL endpoint** at **https://knowledge.brc.riken.jp/bioresource/sparql**, and indexing with **VoID + DCAT metadata.ttl**. **Accessibility** is supported through **OME-Zarr S3 endpoints** and **Vizarr URLs**. **Interoperability** is supported by **dereferenceable URIs** from **OBO Foundry** and **FBbi**, **Relation Ontology alignment**, **OWL 2 axioms**, **SHACL shapes**, and **Linked Open Data federation** with **MONDO**. **Reusability** is supported through **REMBI-compliant coverage**, detailed biological and imaging annotations, and constraints validated by **HermiT** [2508.02084].

The implementation details reported in the paper are specific. The ontology contains **OWL 2 axioms** and, **as of 05/12/2025, 1,478 classes, 522 instances, 235 properties (116 object, 119 data)**. The reported tools are **HermiT reasoner** for consistency checking and **Apache Jena Fuseki 4.7.0** for the SPARQL endpoint. Availability is stated through **NCBO BioPortal under CC BY 4.0**, a **GitHub repository with queries and usage notes**, a **read-only SPARQL service online**, and long-term preservation in **Zenodo** with a **concept DOI (10.5281/zenodo.15700645)**. The project uses **semantic versioning**, and **every tagged release** is said to be **validated by HermiT and archived in Zenodo for reproducibility** [2508.02084].

The paper also states several limitations and future directions. It notes that **legacy RDF (pre-2018) lacked hierarchical structure and property constraints**, and that the new ontology addresses this, but that **continued harmonization with other repositories (IDR, BIA) remains necessary**, including differences such as **ChEBI vs PubChem for chemicals**. It further states that **disease knowledge is not embedded directly**, although **federation with MONDO** provides a practical workaround. Planned work includes **LOV registration**, **broader dataset coverage**, **RDF-star for compact provenance**, **LLM/VLM-assisted annotations**, **fine-grained lineage metadata**, and **enhanced cross-database compatibility and automated quality control** [2508.02084].

In that form, the SSBD Ontology is best understood as a semantic framework that links **organism → biosample → imaging method → image URI**, while simultaneously preserving publication context, dimensional metadata, and cloud-native access paths. Its distinctive contribution lies in the combination of **two-tier curation**, **REMBI alignment**, **OBO/FBbi interoperability**, and an operational RDF/OWL deployment that supports cross-dataset semantic discovery in bioimaging [2508.02084].

Source: https://www.emergentmind.com/topics/ssbd-ontology