Documenting a Dataset: Datasheets, Data Cards and Nutrition Labels

A datasheet for a dataset is a structured document that travels with the data and answers what a user needs to know before relying on it: why the dataset was made, what it contains, how it was collected and processed, what it is suitable for, how it is distributed and who maintains it. Datasheets for Datasets, Google's Data Cards, the Dataset Nutrition Label and Hugging Face dataset cards are variations on the same idea, and most of their questions overlap.

For a content owner, documentation is where knowledge held in people's heads (which years are missing, why a section name changed, which titles were scanned from microfilm) becomes something a data team can use.

This guide compares the main frameworks, walks through what to document section by section, and gives a practical template for a content archive dataset.

Key takeaways

• Dataset documentation exists so that users can make informed decisions and avoid misuse, and so that creators reflect carefully on how the dataset was made.
• Datasheets for Datasets, Data Cards, the Dataset Nutrition Label and Hugging Face dataset cards differ in format and audience but cover largely the same ground.
• The seven datasheet sections (motivation, composition, collection process, preprocessing and labelling, uses, distribution and maintenance) work well as a checklist for any content archive.
• Good documentation is specific and quantified, says 'unknown' where that is the truth, and is versioned with every release of the dataset.
• A human-readable datasheet and a machine-readable metadata file such as Croissant complement each other rather than compete.

Why dataset documentation matters

The idea of a datasheet comes from electronics. Every component, however simple, ships with a sheet describing its operating characteristics, test results and recommended uses. In Datasheets for Datasets, Timnit Gebru and colleagues proposed the same discipline for machine learning data, arguing that the field had no standard way to document datasets and that this gap could cause real harm in high-stakes settings.

They identify two audiences. For dataset creators, the aim is careful reflection on how a dataset is created, distributed and maintained, including its assumptions and risks. For dataset consumers, the aim is to have the information needed to choose an appropriate dataset and avoid unintentional misuse. A secondary benefit is reproducibility: someone without access to a dataset can use its datasheet to build a comparable one.

Content archives have a particular stake in this. Gebru and colleagues recommend a broad reading of which datasets relate to people (any dataset of text written by people does), so almost every archive falls within their questions about people. Most archives also have a production history (migrations, rescans, changes of editorial policy) that no recipient can infer from the files.

The main frameworks compared

Datasheets for Datasets

First posted in March 2018 and published in Communications of the ACM in December 2021, the datasheets paper by Timnit Gebru and six co-authors is a common reference point for later frameworks. The authors refined their questions over roughly two years, testing them on two widely used datasets and with product teams at two large US technology companies. The questions fall into seven sections that follow the dataset lifecycle. The authors stress that they are not prescriptive, and that creating a datasheet is not meant to be automated, because automation would undercut the reflection it is designed to encourage.

Data Cards

Data Cards, described by Mahima Pushkarna, Andrew Zaldivar and Oddur Kjartansson of Google Research in a 2022 paper submitted to ACM FAccT, are "structured summaries of essential facts about various aspects of ML datasets". The paper draws on lessons from deploying more than 20 Data Cards. The accompanying Data Cards Playbook organises the work into four modules (Ask, Inspect, Answer and Audit) and offers a template whose themes include provenance, transformations, annotations and labelling, validation types, sampling methods, known applications and benchmarks, and terms of art. The Playbook now notes that it was drafted in 2022 as exploratory research and may not reflect current approaches.

The Dataset Nutrition Label

The Dataset Nutrition Label, introduced in 2018 by Sarah Holland, Ahmed Hosny, Sarah Newman, Joshua Joseph and Kasia Chmielinski, borrows the idea of a food nutrition label to give a distilled overview of a dataset's 'ingredients' before anyone builds a model on it. The original prototype had seven modules and was demonstrated on ProPublica's Dollars for Docs data. The Data Nutrition Project's third-generation label, from 2022, covers intended and other known uses, data handling (cleaning, management and curation), ethical and technical reviews, the inclusion of subpopulations, and a series of potential risks and limitations.

Hugging Face dataset cards

On the Hugging Face Hub, a dataset card is the README.md file in a dataset repository. Its YAML header carries metadata such as language, a display name, task categories and size categories, which help people discover the dataset, while the Markdown body describes its contents, creation and considerations for use. Hugging Face credits Model Cards as the inspiration, provides a template to import, and suggests writing [More Information Needed] for fields that cannot yet be completed.

Data statements and Croissant

Data statements, proposed by Emily Bender and Batya Friedman in 2018, are designed for natural language processing and address the problems that arise when technology for one population is built with language data from another. Croissant, from MLCommons, is a machine-readable metadata format: version 1.0 was published in March 2024, it is encoded in JSON-LD as an extension of schema.org's Dataset type, and it describes a dataset's files (including each file's format, size and SHA-256 checksum), its record sets and fields. Its specification presents it as a machine-readable form for documentation such as Data Cards, with a separate responsible AI extension.

What to document: the seven sections

The datasheet sections make a sound backbone for any archive dataset. Here is what each asks and means for content.

Motivation. Why was the dataset created, by whom, on behalf of which organisation, and who funded it? For an archive, state the purpose of this particular release: for example, an article-level text dataset of a daily newspaper prepared for retrieval and model evaluation.

Composition. What does each record represent, how many are there, and is this everything or a sample? What is missing and why, and are there errors, noise or redundancies? Could any content be offensive or distressing? For an archive this is the longest section: the record unit, counts by title, year, language and format, known gaps, how duplicates are flagged (see finding duplicates and near-duplicates), and an honest note that historical material contains language and views now considered offensive. Where records name private individuals, as personal notices and court reports do, say so factually.

Collection process. How was the data acquired, with what mechanisms, over what timeframe, and by whom? Gebru and colleagues ask specifically whether the collection timeframe matches the period in which the content was created, giving the example of a recent crawl of old news articles. For a digitised archive, that distinction is central: print from the 1950s scanned from microfilm in 2010 is a different object from articles exported from a content management system.

Preprocessing, cleaning and labelling. What was done to the raw material, was the raw material kept, and is the software available? Record the OCR or transcription tools and versions, article segmentation, boilerplate removal, normalisation, the deduplication policy, how labels were produced (by a model, by people, against which taxonomy) and whether confidence scores are included. Link to measured results; our guide to data quality for AI datasets covers what to measure.

Uses. What has the dataset been used for, what else could it serve, what might affect future uses, and what should it not be used for? An archive might say that OCR text before a certain decade is too noisy for character-level tasks, or that coverage is skewed towards one region.

Distribution. How and when will the dataset be distributed, in what format, and does it have a persistent identifier? Describe the file layout and delivery format (see JSONL, Parquet and other formats).

Maintenance. Who maintains the dataset and how can they be contacted? How will updates be communicated, and will older versions remain available? For archives, say how corrections and withdrawals will be handled between releases.

A practical template for a content archive dataset

The starting template below uses illustrative answers for a fictional regional newspaper archive.

If the dataset will be shared on the Hugging Face Hub, the same information goes into the card's body, with a short YAML header for discovery at the very top of the README, between two lines of three dashes:

pretty_name: Example Regional Newspaper Archive, 1950-2020
language:
- en
task_categories:
- text-retrieval
- summarization
size_categories:
- 100K<n<1M
tags:
- news
- archive

Writing documentation that people use

• Start before the work does. Gebru and colleagues recommend reading the composition and collection questions before collecting any data, then answering them afterwards.
• Quantify. Counts, denominators, date ranges and sample sizes are more useful than adjectives such as 'comprehensive' or 'high quality'.
• Say 'unknown' when it is. The authors' own example datasheets answer some questions with 'Unknown to the authors of the datasheet', and Hugging Face suggests [More Information Needed]. Both are better than guessing, and the datasheet authors recommend answering as many questions as possible rather than skipping the exercise.
• Automate the statistics, not the thinking. Counts and distributions can be generated on each release; judgements about gaps, risks and suitable uses need people.
• Version it with the data. For datasets that change only infrequently, Gebru and colleagues recommend accompanying updated versions with updated datasheets; they note that fast-changing datasets pose harder problems.
• Pair it with machine-readable metadata. A Croissant file or a YAML header lets tools find and load the dataset, while the prose explains it to people. For research collections, see also research data and the FAIR principles.

Common mistakes

• Writing a brochure. Documentation that describes only strengths is not trusted, and users find the gaps anyway.
• Writing it once. A datasheet that describes an earlier release can mislead more than none at all.
• Separating the document from the data. Keep the datasheet in the dataset's root folder and under the same version number.

How Druid Learning helps

Druid Learning is an AI archival processing platform, based in Dublin and New York, that turns content archives into AI-ready datasets. Through Data Partnerships, it prepares an archive, raw or structured, and connects content owners with AI companies. Archive Optimization produces an indexed, labelled dataset from formats including OCR scans, PDF, XML, EPUB and audio files. For the Netherlands Cancer Institute, more than 20,000 research samples were enriched with standardised metadata, producing over 100,000 structured data points, each with a confidence score.

Frequently asked questions

What is a datasheet for a dataset?

A datasheet for a dataset is a structured document, proposed by Timnit Gebru and colleagues, that accompanies a dataset and answers questions about its motivation, composition, collection process, preprocessing and labelling, uses, distribution and maintenance. It helps users decide whether the dataset suits their task and avoid misusing it, and it encourages creators to reflect on how the dataset was made.

What is the difference between a datasheet and a data card?

They cover similar ground in different forms. A datasheet is a set of questions answered in prose, designed to prompt reflection across the dataset's lifecycle. A Data Card, developed at Google Research, is a structured summary built from a template, designed to be concise and comparable across many datasets. A practical approach is to use datasheet questions to gather information and a card format to present it.

What should a dataset card for a content archive include?

It should state the purpose of the release, the record unit and counts, coverage by year, title and language, known gaps, the duplicate policy, and how the text and labels were produced, including tools and versions. It should also report measured quality with sample sizes, suitable and unsuitable uses, the delivery format, the owner and how corrections will be handled between releases.

Can dataset documentation be generated automatically?

Partly. Counts, distributions, field completeness and duplicate rates can and should be generated from the data on every release. The judgements are a different matter: why gaps exist, which uses are unsuitable and what risks the content carries. The authors of Datasheets for Datasets argue that creating a datasheet should not be automated, because the value lies in that reflection.

How often should dataset documentation be updated?

Update it with every release of the dataset, and give it the same version number. If records are added, corrected or withdrawn, or processing changes, the documentation should say so. Gebru and colleagues recommend accompanying updated versions of a dataset with updated datasheets, and a short changelog makes the differences between releases easy to see.

Sources

• Datasheets for Datasets — Gebru et al., arXiv
• Data Cards: Purposeful and Transparent Dataset Documentation for Responsible AI — Pushkarna, Zaldivar and Kjartansson, arXiv
• The Data Cards Playbook — Google PAIR
• The Dataset Nutrition Label: A Framework To Drive Higher Data Quality Standards — Holland et al., arXiv
• The Dataset Nutrition Label — Data Nutrition Project
• Create a dataset card — Hugging Face
• Croissant Format Specification — MLCommons
• Data Statements for Natural Language Processing — Bender and Friedman, ACL Anthology