What Frictionless Data and the Data Package Standard Are
Frictionless Data is a project of the Open Knowledge Foundation (OKFN) that produces a small family of lightweight, open specifications for describing and packaging data, plus open-source tooling that implements them. The central specification is Data Package: a simple, JSON-based container format for describing a coherent collection of data files (“resources”) together with metadata about the collection as a whole — title, description, contributors, licenses, and, for tabular resources, the structure of the data itself.
The current version, Data Package v2, was released in June 2024 and is maintained by the Open Knowledge Foundation at datapackage.org. The project began over a decade earlier as an OKFN community effort (the first Data Package specification shipped around 2017) and has been refined since through the “Frictionless Standards” initiative, which received NGI0 Entrust Fund support for continued development between 2023 and 2024.
Unlike heavier, general-purpose research-object or linked-data frameworks, Data Package deliberately stays small: it is a JSON descriptor file, a small set of required and optional properties, and (for tabular data) a companion schema for describing columns. That minimalism is the point — it is meant to be readable by both humans and machines with no special software required to author it.
The Core Components: Data Package, Data Resource, Table Schema, Table Dialect
The Frictionless Standards are actually four related, composable specifications:
- Data Package — the container-level descriptor. A single JSON file, conventionally named
datapackage.json, that lists the resources in the package and carries package-level metadata (name, license, contributors, sources). - Data Resource — describes a single file or data source within the package: its name, path or URL, format, and (optionally) an inline schema.
- Table Schema — a JSON-based schema for describing the structure of tabular data: field names, data types (string, integer, date, geopoint, and others), constraints (required, unique, minimum/maximum, enumerated values), and primary/foreign key relationships between tables.
- Table Dialect — describes how a tabular file (typically CSV) is physically formatted: delimiter, quote character, header row presence, and escaping rules, so a consumer can parse the file correctly without guessing.
Together, these let a publisher ship a set of CSV files with a single descriptor that says, unambiguously, what each column means, what type of value it holds, and what values are valid — which is what makes automated validation possible before the data is ever loaded into an analysis pipeline.
How It Works: the datapackage.json Descriptor
A minimal Data Package consists of a directory containing one or more data files (most often CSVs) plus a datapackage.json descriptor. A simplified example describing a single tabular resource might read:
{
"name": "population-by-region",
"title": "Population by Region",
"licenses": [{ "name": "CC-BY-4.0" }],
"resources": [
{
"name": "population",
"path": "population.csv",
"schema": {
"fields": [
{ "name": "region", "type": "string" },
{ "name": "year", "type": "year" },
{ "name": "population", "type": "integer", "constraints": { "minimum": 0 } }
]
}
}
]
}A consuming tool — a validator, a loading script, an analysis notebook — can read this one file and know exactly what it is about to parse: which files belong to the package, how each column should be typed, and which values would violate the declared constraints. That is the practical value proposition: catching a malformed date, an out-of-range value, or a missing required field before a dataset is deposited or shared, rather than after a downstream user’s pipeline breaks on it.
Tooling: the Frictionless Framework
OKFN and the wider community maintain reference implementations across roughly ten programming languages, with Python and JavaScript (“Frictionless Framework”) as the most actively developed. These libraries can read, write, and validate Data Packages, and generate a Table Schema automatically by inferring types from an existing CSV. The ecosystem also includes the Open Data Editor, a no-code desktop tool for building and validating packages without writing JSON by hand, and hosted validators such as the community-run validator at datapackage-validator.datist.io. For research teams already scripting data cleaning in Python or R, this tooling is typically the actual point of adoption — the specification matters because working validators and loaders exist for it.
Who Uses It
Data Package has seen real, citable adoption beyond OKFN’s own projects. The Global Biodiversity Information Facility (GBIF) uses Frictionless-based tooling in its Darwin Core data-publishing workflows, and organizations including Our World in Data, Dryad, the European Commission, and GitHub use or reference the standard in their own data-publishing infrastructure. It is a common choice wherever the underlying data is tabular (CSV-shaped) and the publisher wants machine-checkable structure without adopting a full linked-data or RDF stack.
How Data Package Differs From RO-Crate and DCAT
CASRAI covers two adjacent research-data packaging and description standards: RO-Crate and the W3C DCAT (Data Catalog Vocabulary). All three sit somewhere in the broad space of “describing research data so it can be found and reused,” but they solve different problems, at different layers, for different kinds of data:
| Standard | What it actually describes | Format | Best fit | Governance |
|---|---|---|---|---|
| Data Package | The contents of one dataset package: which files it contains, and — for tabular files — the exact column-level structure and constraints of the data itself | Plain JSON (datapackage.json) + Table Schema |
Tabular / CSV data that needs to be validated and exchanged with minimal tooling overhead | Open Knowledge Foundation |
| RO-Crate | A heterogeneous research object — data files, software, workflows — and the relationships and provenance between them | JSON-LD built on schema.org | Multi-file, mixed-provenance deposits: workflow runs, software packages, composite datasets | Research Object community (University of Technology Sydney / University of Manchester) |
| DCAT | A catalog of many datasets published by one or more organizations, for harvesting and cross-portal search | RDF (JSON-LD, Turtle, or RDF/XML) | Federated discovery across data portals — the catalog layer, not the package itself | W3C |
The clearest way to hold the distinction: DCAT describes a catalog of datasets so different organizations’ portals can be searched together; RO-Crate describes the internal structure and provenance of one composite research object (which may include software and workflows, not just data); Data Package describes the internal structure of one predominantly tabular dataset, down to the column and value-constraint level, so it can be validated and consumed correctly. They are not mutually exclusive — a dataset registered in a DCAT-based catalog could itself be published as a Data Package, and a workflow’s tabular outputs inside an RO-Crate could each carry their own Table Schema. In practice, most projects pick one primary packaging standard based on what their data actually looks like: predominantly flat, tabular CSV data with column-level validation needs points toward Data Package; heterogeneous multi-file research objects with software and provenance point toward RO-Crate; and building or contributing to a searchable catalog of many datasets points toward DCAT.
See also CASRAI’s comparison of the related data catalog vs. data dictionary distinction, which addresses a similar “structure vs. discovery” question at a different level of research data infrastructure.
When Data Package Is (and Isn’t) the Right Choice
Data Package tends to fit well when:
- The data is fundamentally tabular — spreadsheets, CSV exports, survey results, time series, reference tables — rather than a mix of software, workflows, and unstructured files.
- The team wants automated validation (type-checking, range-checking, required-field-checking) as part of a data-cleaning or deposit pipeline, without adopting RDF or JSON-LD.
- Minimal dependencies matter — a plain JSON descriptor can be authored and read without specialized linked-data tooling.
- The publishing target does not itself mandate a different packaging format (some domain repositories and funders specify their own required schema or deposit format).
It fits less well when the deposit is fundamentally heterogeneous — software plus data plus a workflow definition plus provenance graph — where RO-Crate’s JSON-LD/schema.org foundation and explicit provenance modeling do more work, or when the actual goal is building a cross-institutional, harvestable catalog of many datasets, where DCAT is the standard funders and portal operators (e.g., data.europa.eu and U.S. federal Data.gov infrastructure) actually expect.
Relationship to FAIR and Data Management Plans
Data Package is, like RO-Crate, one concrete technical mechanism that can help satisfy the FAIR Data Principles rather than a competing framework: structured, machine-readable metadata in datapackage.json supports Findability and Interoperability, while explicit licensing fields support Reusability. It operates below the level of a Data Management Plan (DMP) — a DMP is project-level planning drafted before or during a study; Data Package is a technical packaging format applied to the resulting data at the point of sharing or deposit. Choosing to package tabular outputs as Data Packages can be one of the concrete steps a DMP commits to, alongside repository choice and licensing.
Practical Adoption Considerations for Research Data Managers
- Check your target repository or funder first. Data Package is not a universal requirement; adoption is voluntary and use-case driven. Confirm whether your repository, funder, or domain (biodiversity data via GBIF/Darwin Core is a notable example) already expects or supports it before committing.
- It complements, not replaces, your repository. Like RO-Crate, Data Package describes what a set of files contains; it does not provide storage, versioning, or long-term preservation on its own.
- Best return on investment is with genuinely tabular data. Column-level schema and constraint-checking are the main practical benefit; there is little reason to reach for Data Package over RO-Crate for primarily software- or workflow-heavy deposits.
- Use the existing tooling rather than hand-authoring. The Frictionless Framework libraries can infer a Table Schema from an existing CSV automatically, which is faster and less error-prone than writing the schema by hand.
- Combine with licensing decisions early. See CASRAI’s guide to data licensing for research datasets for how license choice interacts with reuse rights once data is packaged.
Frequently Asked Questions
Is Data Package the same thing as Frictionless Data?
“Frictionless Data” is the umbrella name for the Open Knowledge Foundation’s initiative and its tooling; “Data Package” (together with Data Resource, Table Schema, and Table Dialect) is the specific specification it produces. In practice the names are often used interchangeably, but Data Package is the precise standard to cite.
Does Data Package require CSV files specifically?
No. A Data Package resource can point to data in other formats, but Table Schema — the piece that provides column-level typing and validation — is designed specifically for tabular data, and CSV is by far the most common format it is applied to in practice.
Is Data Package a formal standards-body specification, like DCAT is for W3C?
No. Like RO-Crate, it is a community/organizational specification rather than a formal standards-body recommendation — in this case maintained by the Open Knowledge Foundation rather than a body such as W3C or ISO. That does not diminish its practical adoption, but it is a governance distinction worth noting when a funder or repository policy specifically requires a formal standard.
Can I use Data Package and RO-Crate together?
There is no formal conflict between them, and nothing prevents a tabular resource inside an RO-Crate from also carrying its own Table Schema. In practice, most projects choose one as their primary packaging format based on whether their deposit is predominantly tabular data (Data Package) or a heterogeneous research object involving software and workflows (RO-Crate), rather than layering both.
Where can I read the current specification?
The current (v2) specification is published at datapackage.org, maintained by the Open Knowledge Foundation.
