RO-Crate (Research Object Crate) is a lightweight specification for packaging research data, software, and their associated metadata into a single, self-describing bundle that both people and machines can interpret. It was developed within the Research Object community — an initiative that grew out of earlier “research object” work at the University of Manchester and elsewhere aimed at making digital research outputs reproducible and citable as first-class objects — and is now maintained collaboratively, with the University of Technology Sydney and the University of Manchester holding copyright on the current specification text alongside a broader base of RO-Crate contributors. For anyone managing research data, RO-Crate matters because it gives a dataset, workflow, or software package a standard, machine-readable way to say what it contains, who made it, and how its parts relate to each other — the kind of rich description the FAIR data principles call for but that most ad hoc folder-and-README bundles never actually provide.
What Is RO-Crate?
At its core, RO-Crate is a convention for adding a single metadata file, ro-crate-metadata.json, to the root of any directory (a “crate”) of research data. That file is written in JSON-LD — JSON that carries an explicit, linked-data context — built primarily on schema.org vocabulary, with RO-Crate-specific terms layered on top where schema.org doesn’t cover a research-specific need (workflow inputs/outputs, computational environments, and so on). Because the metadata is JSON-LD, it is simultaneously easy for a person to read, easy for a script to parse, and interoperable with the broader linked-data and search-engine ecosystem that already understands schema.org.
Every RO-Crate has a designated Root Data Entity: the single entity in the metadata graph that represents the crate as a whole (typically typed as a schema.org Dataset), from which every other file, person, organization, and relationship described in the crate hangs off. That root entity is where a crate declares its own core FAIR-relevant metadata — name, description, license, and creators — before describing the individual files and how they relate.
RO-Crate does not require any particular storage or transport mechanism; a crate can be a plain folder, a zipped archive, or a directory deposited directly into a repository. This deliberately narrow scope — describe what’s in the package, don’t dictate how the package is stored or moved — is a large part of why it has been adopted across such different contexts: it can sit underneath a workflow run, a dataset deposit, or a software release without requiring any of those systems to change how they store files.
How RO-Crate Supports FAIR Data Practice
RO-Crate is not itself a FAIR-compliance framework, but it directly operationalizes several parts of the FAIR principles at the packaging level:
- Findable — a well-formed crate carries structured identifiers, titles, and descriptions in its root entity that make the package’s contents legible to indexing tools and search interfaces, rather than requiring a human to open and read a plain-text README.
- Accessible — because the metadata format is open, published, and versioned, any tool implementing the specification can retrieve and parse a crate’s description without proprietary software.
- Interoperable — JSON-LD grounded in schema.org means a crate’s metadata can be understood by any system that already speaks linked data, not just RO-Crate-aware tools specifically.
- Reusable — RO-Crate’s data model has explicit places to record licensing, provenance (who created what, from which inputs), and contextual entities like people, organizations, and funding — the detail a downstream reuser needs to evaluate and cite the work correctly.
Research-data managers evaluating whether a dataset meets funder or repository FAIR expectations can treat RO-Crate as one concrete, implementable answer to “how do I actually attach machine-readable metadata to this deposit,” alongside repository-level metadata schemas. See CASRAI’s step-by-step FAIR checklist for the broader compliance picture, and how to choose a metadata schema for a dataset for how RO-Crate compares with other schema choices at deposit time.
Core Use Cases
RO-Crate’s own documentation and example gallery point to a consistent set of use cases where the format has seen real implementation:
Workflow provenance and reproducibility
RO-Crate is widely used to package computational workflows together with their provenance record — which tools ran, in what order, on which inputs, in what computational environment. WorkflowHub, a registry for FAIR scientific workflows, uses RO-Crate as its packaging format so that a deposited workflow arrives with structured, machine-readable metadata rather than just source code and a description field. The Nextflow ecosystem’s nf-prov plugin similarly generates an RO-Crate as a structured provenance record of a completed pipeline run. This overlaps closely with CASRAI’s broader guides on data provenance and reproducibility infrastructure — RO-Crate is best understood as one concrete packaging mechanism for the provenance concepts those pages cover, expressed specifically as portable, deposit-ready metadata rather than a live system’s internal logs.
Dataset packaging and interchange
Beyond workflows, RO-Crate is used to bundle datasets — particularly heterogeneous collections of files — with rich descriptive and structural metadata for deposit or exchange between systems. The Language Data Commons of Australia (LDaCA) is a documented example of RO-Crate used this way, packaging linguistic and cultural data collections with the contextual metadata needed to interpret and reuse them responsibly.
Software and model packaging
RO-Crate has also been applied to packaging research software and computational models with their metadata, provenance, and dependencies attached — the Model Atlas of the Earth (M@TE) project is a documented example for scientific models specifically. This is a natural extension of the same core idea used for workflows: describing the software or model, its inputs/outputs, and its relationship to any associated data in one machine-readable bundle. Where software carries a formal citation record rather than just a description, that work connects to CASRAI’s coverage of the FAIR4RS Software Citation Principles and the FAIR Working Group’s software citation guidance.
Other documented implementations include AROMA (the ARP RO-Crate Manager) and use within the Open Microscopy Environment (OME) for structured data transfer — both concrete signals that RO-Crate adoption spans beyond a single discipline or infrastructure project, though the specification’s overall adoption should be understood as an active, growing community effort rather than a universal standard every repository already requires.
How RO-Crate Relates to Other Standards
RO-Crate sits alongside, rather than replaces, several standards research-data managers already work with:
- PROV-O, the W3C provenance ontology, defines a formal, general-purpose vocabulary for expressing provenance on the web. RO-Crate’s provenance modeling is built on schema.org rather than PROV-O directly, but the two are interoperable in intent — both are ways of answering “what produced this, and from what.”
- Workflow languages (CWL/WDL) describe how a computational pipeline executes; RO-Crate describes the resulting package of code, data, and provenance around a workflow run, and the two are frequently used together rather than as alternatives.
- DataCite’s metadata schema and repository-level schemas govern what a repository record must contain to register a persistent identifier; RO-Crate operates one level down, describing the internal structure and relationships of the deposited package itself, and the two can coexist on the same deposit.
- DMP Common Standard (RDA, JSON-LD) is a separate, machine-actionable JSON-LD standard for data management plans specifically, not data packages — both share JSON-LD as an underlying technology, illustrating a broader trend toward linked-data formats across the research data infrastructure.
Adopting RO-Crate: Practical Considerations for Research Data Managers
For an institution or research-data management team weighing RO-Crate, a few practical points matter more than the technical spec itself:
- It’s additive, not a repository replacement. RO-Crate describes what’s inside a package; it doesn’t provide storage, access control, or long-term preservation. Those remain the job of the repository the crate is ultimately deposited into — see CASRAI’s guide on choosing an open data repository.
- It’s most valuable where a deposit is genuinely composite. A single flat dataset file may not need RO-Crate’s structure; a workflow run, a multi-file dataset with mixed provenance, or a software release with dependencies benefits far more from being able to declare relationships explicitly.
- Check whether your target repository or registry already expects it. Adoption is domain- and infrastructure-specific rather than universal; workflow registries like WorkflowHub build RO-Crate in as their native packaging format, while a general-purpose institutional repository may not have any built-in awareness of it. Confirm expectations with the receiving repository before assuming RO-Crate is required or even recognized.
- The specification is versioned and actively maintained. As with any actively developed community specification, confirm the current version and any breaking changes directly against the specification pages at researchobject.org/ro-crate before building tooling against it, rather than assuming a version number cited elsewhere is still current.
Frequently Asked Questions
Is RO-Crate the same thing as FAIR data?
No. FAIR is a set of principles for making data findable, accessible, interoperable, and reusable; RO-Crate is one concrete technical implementation that helps satisfy those principles at the packaging and metadata level. A dataset can be FAIR without using RO-Crate specifically, and a crate built with RO-Crate still needs to be deposited somewhere accessible, licensed appropriately, and documented well to actually be FAIR in practice.
Do I need special software to create an RO-Crate?
An RO-Crate’s core requirement is simply a correctly structured ro-crate-metadata.json file at the root of a directory, which can in principle be authored by hand for a simple case. In practice, most adopters use tooling built around specific platforms (for example, workflow registries and pipeline plugins that generate RO-Crate output automatically) rather than writing the JSON-LD manually. Check the current tooling landscape at researchobject.org before committing to a particular workflow.
Does RO-Crate replace a Data Management Plan?
No. A Data Management Plan is a project-level planning document describing how data will be handled across a research project’s lifecycle. RO-Crate operates at the level of an individual data package, describing what that package actually contains once produced. They’re complementary: a DMP might commit to depositing data with rich, structured metadata, and RO-Crate is one way of fulfilling that commitment for composite or workflow-based outputs.
Who governs the RO-Crate specification?
RO-Crate is developed as a community specification by the Research Object community and RO-Crate contributors, with the University of Technology Sydney and the University of Manchester holding copyright on the published specification text. It is not a formal standards-body specification in the way an ISO or W3C Recommendation is, though it draws heavily on the W3C’s JSON-LD standard and schema.org vocabulary.
