A dataset needs a label like a component does

An electronics idea applied to data

The Datasheets for Datasets paper, submitted to arXiv on 23 March 2018, borrows a practice from the electronics industry, where a component ships with a datasheet recording its operating characteristics and recommended uses, and proposes the equivalent for machine learning datasets. The authors argue that datasets are typically released with little or no accompanying documentation, which leaves the people reusing a dataset to guess at how it was collected, who is represented in it, and what it is, or is not, appropriate for.

What the proposal asks a creator to record

The paper sets out a structured set of questions a dataset's documentation should answer, organised loosely around motivation, composition, the collection process and recommended uses. Motivation covers why the dataset was created and by whom; composition covers what the instances represent and whether the dataset is a full population or a sample; collection process covers how and from whom the data was gathered, including any consent or licensing constraints; and recommended uses is explicit about the flip side of that question, asking creators to record tasks the dataset should not be used for, given how it was built. That last category is the part most easily skipped in practice, since it requires a creator to anticipate misuse rather than only describe intended use.

How model cards extended the idea, and why the practice stayed uneven

A related Model Cards for Model Reporting paper, submitted 5 October 2018, applies the same logic one step downstream, to trained models rather than the datasets behind them: it proposes short documents reporting evaluation results across different demographic, cultural or phenotypic groups, alongside the context a model is intended for. Read together, the two proposals describe a documentation chain running from raw data through to deployed model, each stage recording its own scope and limits. A later version of the datasets paper was reviewed and printed by the Communications of the ACM; this piece could not open that publisher's page to check what, if anything, it added, so no claim beyond the arXiv text is made here. What both preprints establish is the proposal itself, not evidence about how widely it has since been adopted, and dataset documentation quality has stayed visibly uneven since 2018, between a released dataset with a full datasheet and one shipped as a bare file with no accompanying record.

Questions to carry into your own evaluation

• Does a dataset or model you rely on ship with anything answering the datasheet's motivation, composition and collection-process questions?
• Does its documentation state what it should not be used for, or only what it is intended for?
• If no datasheet or model card exists, what is the actual source of your assumptions about how representative or consented the underlying data is?

The lasting contribution of both papers is a checklist rather than a rule: they do not mandate disclosure, and adoption has been voluntary and uneven, but they gave the field a shared vocabulary for naming what a dataset or model description is missing.