How to cite research data: DOI, version and access

Treat the dataset as a research output

A dataset is not merely the location from which numbers were downloaded. A formal citation gives credit to those who collected and curated the material, creates a route back to the evidence and lets indexing services recognise the connection between outputs. A bare URL is weak evidence: a home page may describe several collections, links can move, and the files behind an interface can be replaced. A DOI or another managed persistent identifier points to a maintained metadata record intended to remain resolvable.

Persistence does not mean that every byte is frozen forever. Repositories may publish successive releases while retaining a record for each one. This is why the cited version matters. The FORCE11 data citation principles also call for data references to appear alongside other scholarly references rather than being buried in prose. Doing so keeps the object visible, attributable and machine discoverable.

Build the citation from the repository record

Start on the dataset landing page and look for “Cite”, “Citation” or an export to a reference manager. Copy the creator names, title, publication year, publisher or repository, version and identifier from that record. Then apply the punctuation and ordering required by your department’s reference style. Do not silently replace the data creators with the authors of a related article; the paper and the dataset may have different contributor lists.

• Responsibility: the named dataset creators or responsible organisation.
• Identity: the complete dataset or collection title, including a relevant subtitle.
• Date: the publication year of the cited release rather than your analysis date.
• Edition: version, release, wave or a clearly identified snapshot where available.
• Publisher: the repository or data service that issued the record.
• Locator: preferably a DOI expressed as https://doi.org/…, or another stable identifier.

An access date is useful for a changing database or an ordinary web resource. It is usually supplementary rather than a substitute for a version and persistent identifier.

Choose the release that your result depends on

Some repositories offer both a concept DOI for the evolving collection and a version DOI for one release. When reporting an analysis, the version-specific identifier normally gives the clearer evidential route. The concept identifier is useful when discussing the project or software family across releases. DataCite provides metadata fields for a resource version and controlled relationships between related versions. Use the repository’s own explanation rather than trying to infer the distinction from the characters in a DOI.

Large collections require more granularity than a reference-list entry can provide. In the methods section, name the particular files, tables, survey waves, geographical scope and filters used. If checksums are supplied, compare the downloaded files and retain the value in your internal record. A checksum demonstrates byte identity between files; it does not replace the descriptive metadata, version or identifier.

Separate citation, availability and analytical provenance

Three statements answer three different questions. The reference says which scholarly object you used. A data availability statement explains where it can be accessed and under what conditions. The method explains which subset entered the analysis and what happened to it. Keeping these functions distinct produces a shorter, cleaner citation and a much stronger audit trail.

Restricted data can still be cited accurately. Describe the access route without implying that every reader will qualify. Never place participant names, private tokens or access credentials in a citation. For your own unpublished data, state the creator, collection period, internal version and controlled location as far as confidentiality permits. If a repository record becomes available before submission, replace the provisional description with its persistent citation.

Common citation failures

A link to a repository search result is not the same as a dataset landing page. Citing only the accompanying article hides the exact input. Listing a retrieval date without the query leaves a dynamic extraction impossible to reconstruct. Conversely, pasting a complete API URL can expose keys or include parameters that are not stable. Save the query in a safe method file, redact secrets and state the meaningful filters in ordinary language.

Another frequent error is to cite the newest release even though the analysis used an older one. Check the timestamp of the downloaded file and compare its contents with the release record. If the version cannot be established, say so and document the evidence you do have; do not manufacture precision.

A short pre-submission audit

1. Resolve the DOI in a fresh browser session and verify that it reaches the intended landing page.
2. Match creator names, year, title and version against the repository metadata.
3. Confirm that the cited release is the one actually analysed.
4. Locate the file selection, variables, filters and transformations in your methods record.
5. Check that in-text references and the bibliography identify the same object.