Citing a dataset correctly is different from citing a journal article. The source is often a repository record rather than a publisher, the “author” may be an institution rather than a person, and the object being cited can change over time as new versions are deposited. This guide covers what a complete dataset citation needs, why those specific elements matter, and shows two real worked examples — DataCite’s own recommended format and APA 7th edition style — built from actual published dataset records.
Why dataset citation has its own rules
Research data is a citable product in its own right, not just supporting material buried in a paper’s methods section. That principle was formalized in the Joint Declaration of Data Citation Principles, published by FORCE11’s Data Citation Synthesis Group in 2014 after reconciling four earlier, overlapping sets of principles (the Amsterdam Manifesto, CoData, DataCite, and the Digital Curation Centre). The declaration sets out eight principles a proper data citation practice should satisfy:
- Importance — data should be considered a legitimate, citable product of research, not an afterthought.
- Credit and attribution — citations should give scholarly recognition and legal attribution to everyone who created or curated the data.
- Evidence — wherever a published claim relies on data, that data should be cited.
- Unique identification — a citation should use a persistent, machine-actionable, globally unique identifier.
- Access — the citation should facilitate access to the data itself and to the metadata, documentation, and code needed to understand it.
- Persistence — identifiers and metadata should persist, even after the data itself is no longer available.
- Specificity and verifiability — a citation should point to the precise version and subset of data actually used, with enough provenance detail to verify the claim.
- Interoperability and flexibility — citation practices should accommodate differences across research communities while remaining broadly standardized.
CASRAI’s Dictionary entries for the data citation principle and the Joint Declaration itself cover the concept definitionally; this guide is the practical companion — what to actually put in a citation and how to build one from a real DOI record.
The elements every dataset citation needs
Regardless of citation style, a complete dataset citation draws from the same underlying metadata. This is exactly the set of properties the DataCite Metadata Schema treats as mandatory (plus one commonly-included optional field) for any dataset assigned a DataCite DOI:
- Creator — the person(s) or organization responsible for producing the dataset. For an institutionally-curated dataset with no individual named author, the depositing organization or repository can stand in as the creator.
- Title — the dataset’s title, exactly as registered with the repository.
- Publisher — in DataCite’s schema, this is the repository or data center that holds and disseminates the dataset (e.g. PANGAEA, ICPSR, Zenodo, Dryad) — not a commercial publishing house.
- PublicationYear — the year associated with the specific version being cited, not necessarily the year the underlying research was conducted.
- Version — optional in the schema but important in practice: datasets get revised, and citing a version number (or a version-specific DOI, where the repository mints one) is what makes a citation actually reproducible. This matters enough that it’s worth treating as effectively required whenever the repository provides it.
- ResourceType — DataCite’s general resource-type category,
Dataset, which is what tells downstream systems (including citation software and Google Dataset Search) that this record is data rather than, say, a software release. - Identifier — the persistent identifier, almost always a DOI. This is the single element that makes every other element machine-verifiable: resolve the DOI and you can confirm the rest of the citation matches the actual record.
If a repository’s landing page doesn’t make one of these obvious, the DOI itself is the fastest way to find it — see CASRAI’s guide on how to find, look up, and resolve a DOI for the mechanics of pulling structured metadata directly from a DOI rather than guessing from the rendered page.
DataCite’s recommended citation format
Because DataCite is the registration agency behind most dataset DOIs, its own recommended citation format is a reasonable default when a repository doesn’t specify its own preferred style. The mandatory-element form is:
Creator (PublicationYear): Title. Publisher. (ResourceTypeGeneral). Identifier
and, when a version number is available:
Creator (PublicationYear): Title. Version. Publisher. (ResourceTypeGeneral). Identifier
Worked example (DataCite’s own published example, built from a real, resolvable dataset DOI):
Irino, T; Tada, R (2009): Chemical and mineral compositions of sediments from ODP Site 127-797. V. 2.1. Geological Institute, University of Tokyo. (dataset). https://doi.org/10.1594/PANGAEA.726855
Note the structure maps directly onto the element list above: two creators, publication year, title, version, publisher (the institution operating as data center for this deposit), resource type in parentheses, and the DOI as a full resolvable link rather than a bare “doi:” prefix — the display convention Crossref and DataCite both currently recommend.
APA style (7th edition)
Most researchers citing a dataset inside a manuscript will use whatever reference style the target journal requires, not DataCite’s own format directly. APA 7th edition is one of the most common in the social and behavioral sciences and treats a dataset as its own reference type:
Author, A. A. (Year). Title of data set (Version number) [Data set]. Publisher. DOI or URL
Worked example (from APA Style’s own published examples):
O’Donohue, W. (2017). Content analysis of undergraduate psychology textbooks (ICPSR 36966; Version V1) [Data set]. ICPSR. https://doi.org/10.3886/ICPSR36966.v1
The bracketed descriptor [Data set] is what signals to a reader that this reference points to data rather than a text; APA allows the bracket to be adapted (e.g. “[Data set and code book]”) when a deposit bundles data with other material. The same underlying elements — creator, year, title, version/identifier, publisher, persistent identifier — are just arranged and punctuated differently than in DataCite’s own format.
A shortcut: let the DOI generate the citation for you
Rather than manually assembling a citation from a repository’s landing page, DOI content negotiation can return a fully formatted citation directly from the DOI itself, in whichever style you need. Sending an HTTP request to a DOI’s resolver with an Accept header specifying a citation style returns ready-to-use text:
curl -LH "Accept: text/x-bibliography; style=apa" https://doi.org/10.5438/0000-0C2GThis works because DataCite’s content negotiation service converts the DOI’s underlying metadata into Citation Style Language (CSL) input, then runs it through a CSL processor supporting thousands of citation styles — APA and DataCite’s own format among them. It’s a genuinely useful trick for generating a citation you can trust matches the actual registered metadata, rather than retyping fields from a web page and risking a transcription error.
Special cases worth knowing
No named individual author
Not every dataset has a person listed as creator. Where a repository or research consortium is the entity of record, cite that organization as the creator — the same way an institutional report is cited when no individual author is named.
Citing a specific version or subset
If a dataset has been revised since the version you actually used, cite the version-specific DOI or version number if the repository provides one, not just the dataset’s general landing DOI. This is the practical expression of the Joint Declaration’s specificity and verifiability principle above — a citation that points to “the dataset” in general, when the data has since changed, no longer verifiably supports the original claim.
No DOI available
Not every dataset has a DOI, particularly older or informally shared data. In that case, cite the most stable persistent identifier available (a handle, an accession number for a domain repository, or as a last resort a stable URL with an access date). The absence of a persistent identifier is itself a sign the data may not meet baseline FAIR discoverability expectations — see CASRAI’s guide on choosing an open data repository if you’re the one depositing data and want it to be reliably citable in the first place.
Citing software, not data
Software and data citation share the same underlying logic but aren’t identical — the version field carries more weight for software, and the research community has developed a parallel FAIR4RS Software Citation Principles framework alongside the data-citation principles above. Don’t cite a code release using the dataset conventions on this page without checking that framework first.
Frequently asked questions
Do I need to cite a dataset separately from the paper that describes it?
Yes, if you are using the data itself — not just the paper’s findings. Citing only the paper doesn’t give credit to the dataset as a distinct research output, and doesn’t let a reader independently verify or reuse the actual data.
Which citation format should I use: DataCite’s or my target journal’s style (APA, etc.)?
Use whatever reference style your target venue requires (APA, Chicago, Vancouver, and others each have their own dataset conventions). DataCite’s recommended format is the right default only when no other style is specified, or when citing data outside a formal manuscript context.
What if the repository doesn’t show a suggested citation on the landing page?
Many repositories (DataCite-affiliated ones especially) display a “Cite as” or suggested-citation block directly on the dataset’s landing page. If one isn’t shown, use the DOI content-negotiation method above, or assemble a citation manually from the elements listed earlier in this guide.
Does the dataset’s DOI change every time the data is updated?
It depends on the repository’s versioning policy. Some repositories mint a new, version-specific DOI for each release while keeping a stable “concept” DOI that always resolves to the latest version; others update metadata under a single DOI. Check the specific repository’s documentation, and always prefer citing the version-specific identifier when one exists.
For the wider research data management context this guide sits within — data management plans, repository selection, FAIR principles, and dataset discoverability — see the CASRAI Research Data Management hub.
