Data Curation

Data curation is the active, ongoing management of research data across its lifecycle: organizing it, describing it with standardized metadata, validating and cleaning its values, and taking preservation actions so it remains findable, interpretable, and usable by someone other than the person who created it, long after the project that produced it has ended. The word “curated” applied to a dataset signals that these specific actions have actually happened — not merely that a copy of the file still exists somewhere.

What counts as curation, operationally

A dataset is genuinely curated — as opposed to merely stored — when some combination of the following has actually been done to it:

• Organizing — imposing a coherent file and folder structure, consistent naming conventions, and version control, so the dataset’s components relate to each other predictably.
• Describing (adding metadata) — attaching structured, standardized information about the data’s provenance, collection method, variables, and format, rather than leaving that knowledge to live only in a researcher’s memory or an informal README.
• Validating and cleaning — checking for missing values, inconsistent units, duplicate records, or encoding errors, and correcting or documenting them rather than passing them downstream unexamined.
• Preserving — taking deliberate action against long-term technical obsolescence: fixity checking (confirming a file hasn’t silently corrupted or changed), and format migration when a file type risks becoming unreadable.

The Digital Curation Centre (DCC), the UK-based body most closely associated with formalizing the concept, defines digital curation as maintaining and adding value to a trusted body of digital data for current and future use, and models it as a continuous lifecycle (its own Curation Lifecycle Model runs from conceptualizing and creating a digital object through appraisal, ingest into a trusted repository, preservation action, and ongoing access and reuse) rather than a single step completed once and left alone.

Curation vs. storage and backup

This is the distinction that most often gets collapsed in casual use, and it matters for anyone writing a data management plan or evaluating whether a dataset is actually reusable:

• Storage/backup is passive. A file sits on a drive, a server, or a cloud account. The goal is that a copy continues to exist and isn’t lost to hardware failure. Nothing about storage, by itself, makes the file findable by someone who doesn’t already know it’s there, or interpretable by someone who wasn’t part of the original project.
• Curation is active and ongoing. It is a set of deliberate actions — organizing, describing, validating, preserving — applied to the data with the specific goal of keeping it usable and trustworthy for people who weren’t involved in creating it, including the original researcher’s future self.

A dataset can be stored indefinitely without ever being curated (a folder of unlabeled files on a lab server that no one can interpret five years later is a common real-world case), and curation work can happen before a dataset ever reaches its long-term storage location. Storage answers “does a copy still exist?”; curation answers “can someone actually find, understand, and reuse this?” — two different, if related, questions.

Data curation and the FAIR principles

Curation is largely how the FAIR Guiding Principles (Findable, Accessible, Interoperable, Reusable; Wilkinson et al., 2016) get satisfied in practice, rather than a separate framework alongside them. Two of the clearest connections:

• F2 (“Data are described with rich metadata”) is, in operational terms, a description of curation’s metadata-adding step. FAIR’s own R1 elaborates that (meta)data should be “richly described with a plurality of accurate and relevant attributes” — exactly the kind of structured description that distinguishes a curated dataset from a dumped file.
• F1 (a globally unique, persistent identifier) is typically assigned during deposit into a repository, which is itself usually the point at which curation review happens — see Data repository.

A dataset can technically be FAIR-compliant on paper (correct identifier, a license, a listed format) while still being poorly curated in practice — inconsistent variable names, undocumented codes, no version history. FAIR describes the target properties a dataset should have; curation is the ongoing work that gets it there and keeps it there.

Data curation and data repositories

Curation activity happens on both sides of a deposit into a data repository:

• Before deposit, a researcher (or a data steward supporting them) typically does the organizing, describing, and cleaning described above, often guided by a data management plan’s stated metadata standard.
• At and after deposit, a well-run repository performs its own curation review — checking submitted metadata against required fields (see Core metadata for the DataCite mandatory-property set a repository typically enforces before it will mint a DOI), and, for certified repositories, ongoing fixity checking and format-migration planning as part of maintaining trust in the archive over the long term. This ongoing curation commitment is part of what CoreTrustSeal certification actually assesses in a repository, rather than storage capacity alone.

A repository’s own curation practices are a large part of what separates a trustworthy repository from a general-purpose file host: see Data repository for the fuller distinction.

Who does the curating

In practice, curation work is distributed across roles rather than owned by one person. A researcher curates their own data as they collect and clean it; a designated data steward or data curator may take on curation as an institutional or repository-facing role, particularly for larger or shared datasets; and, when a person’s specific contribution to a published paper was managing and annotating the underlying research data, CRediT’s own “Data curation” contributor role exists to credit that work in an author-contribution statement. That CRediT role names a specific, attributable contribution to one publication; the dictionary entry on this page describes the broader research-data-management practice the role is drawing on, not the authorship-credit mechanism itself. See CASRAI’s CRediT Contributor Roles Taxonomy hub for how Data curation relates to all 14 roles a paper’s contributors can be credited for.

Data curation vs. Formal analysis vs. Software

These three CRediT roles are the ones most often confused with each other, because all three can touch the same dataset. The CRediT taxonomy defines them as distinct contributions, and a single paper’s contributor statement can legitimately credit different people — or the same person under multiple roles — for each:

• Data curation covers “management activities to annotate (produce metadata), scrub data and maintain research data … for initial use and later re-use” — keeping the dataset itself usable and trustworthy. Example: standardizing inconsistent sample-ID formats across spreadsheets, writing a data dictionary, running fixity checks before deposit.
• Formal analysis covers “application of statistical, mathematical, computational, or other formal techniques to analyze or synthesize study data” — producing the paper’s results from the data, not maintaining the data itself. Example: running the regression model or statistical test that generates the reported effect sizes. Cleaning a variable so a model will run is Data curation; deciding which model to run and interpreting its output is Formal analysis.
• Software covers “programming, software development; designing computer programs; implementation of the computer code and supporting algorithms; testing of existing code components” — writing and maintaining code, as distinct from the data it processes. Example: building and testing an analysis pipeline’s codebase. The two roles overlap only when code maintenance is inseparable from data maintenance — CRediT’s own Data curation definition explicitly extends to “software code, where it is necessary for interpreting the data itself” (for example, a bespoke parser required to read a proprietary instrument’s raw output). Writing the statistical analysis script itself is ordinarily Software or Formal analysis, not Data curation.

Because these roles frequently co-occur on the same paper, CRediT allows — and expects — crediting every role that genuinely applies to a given contributor, rather than forcing a single label onto mixed work.

Related terms

• Data repository
• CRediT Contributor Roles Taxonomy (all 14 roles)
• Core metadata
• Data management plan (DMP)
• Data validator
• Open-data contribution
• The research data lifecycle (guide)
• How to make your dataset FAIR (guide)