A persistent identifier tells you where something is and, usually, a little about what it is. A FAIR Digital Object (FDO) is a different, more ambitious idea: a self-describing package that binds the data itself, its metadata, its type definition, and a resolvable identifier together into one unit that a machine — not just a human following a link — can discover, interpret, and act on without prior knowledge of the source system. It is the leading proposal for what comes after “FAIR-compliant repository” as the unit of interoperability in research infrastructure, and it is being actively built out by a named international community rather than existing only as a proposal on paper. This guide explains what an FDO actually is, how it differs from the FAIR data principles it implements, who is building the supporting infrastructure, and what research administrators and CRIS/repository managers should realistically expect from it over the next few years.
FAIR Digital Objects vs. the FAIR data principles: two different things with the same name
It is easy to conflate “FAIR Digital Object” with “FAIR data,” but they answer different questions. The FAIR data principles (Findable, Accessible, Interoperable, Reusable — formalized by Wilkinson et al. in the 2016 Scientific Data paper “The FAIR Guiding Principles for scientific data management and stewardship”) are a set of goals: fifteen sub-principles describing what good data stewardship should achieve, deliberately agnostic about the technology used to get there. They tell you a dataset should have a persistent identifier, rich metadata, and a clear usage license — but not what format that identifier, metadata, or license declaration should take, or how a piece of software should locate and parse them automatically.
An FDO is one concrete technical answer to “how do we actually implement FAIR in a machine-actionable way.” Where the FAIR principles are a checklist a human curator or a funder can audit a repository against, an FDO is a specific packaging and typing scheme intended to let software — a workflow engine, an AI agent, another FDO — discover what an object is and what can be done with it, without a human reading a landing page first. This is the distinction the FDO community itself draws consistently: FAIR describes desirable properties of data; FDO is infrastructure for making those properties computable.
What actually makes something a FAIR Digital Object
Definitions vary slightly by source, but the FDO Forum’s and GO FAIR’s own material converge on the same core structure. An FDO is generally described as having five interlocking parts:
- Content (the bit sequence). The actual data — a file, dataset, or other digital artifact — stored in an accessible repository, exactly as with any other digital object.
- A persistent identifier (PID). A globally unique, resolvable identifier — conceptually the same role a DOI plays for a publication, but the FDO model traces its lineage to the Handle System (the resolution infrastructure DOIs themselves are built on, coordinated today by the DONA Foundation) and specifically requires the PID to resolve not just to a landing page, but to structured, typed metadata a machine can parse.
- Rich, machine-actionable metadata, itself treated as a distinct FDO with its own identifier — not a static description field bolted onto the record, but a structured, resolvable object in its own right.
- A type definition, also a separately identified FDO, that declares what kind of object this is and, critically, what operations are valid on it. This is the piece that lets software reason about an unfamiliar object automatically: instead of a human reading documentation to learn “this is a genomic sequence file, here’s how to open it,” the type record itself states the object’s kind and its permitted operations.
- Associated operations defined for that type — the actions (retrieve, validate, transform, cite) a piece of software can invoke against the object because its type says those operations are valid.
The practical effect of this structure is that an FDO carries its own machine-readable “instruction manual.” A human researcher can already figure out what a dataset is and how to use it by reading a repository page; an FDO is designed so that a script, workflow orchestrator, or AI agent operating across institutional and disciplinary boundaries can do the equivalent without a human in the loop for every step.
The Digital Object Interface Protocol (DOIP)
A shared package structure is only useful if there is also a shared way to talk to it. The FDO ecosystem uses the Digital Object Interface Protocol (DOIP), a standardized communication protocol for interacting with digital objects — retrieving them, invoking their declared operations, and resolving their identifiers — regardless of which specific repository or system is hosting the object. DOIP is the transport-and-interaction layer underneath the FDO abstraction; the FDO Forum’s specification work covers both the object model (what an FDO must contain) and this protocol layer (how systems exchange FDOs and their operations). This two-layer approach — a data structure plus a shared interaction protocol — is what distinguishes the FDO approach from simply publishing well-described data behind a standard web API: the goal is that any DOIP-speaking client can interoperate with any DOIP-compliant repository, not just repositories built with a particular vendor’s API in mind.
Who is building this: the FDO Forum, DONA Foundation, GO FAIR, and RDA
FDO is not a single organization’s product; it is a coordinated effort across several bodies, which matters for anyone assessing how durable or how “official” the framework actually is:
- The FDO Forum is the self-organized international community of data infrastructure experts most directly responsible for developing the FDO specification and its components, and for coordinating implementation projects that test the model in practice. It runs the annual FDO Conference (the third was held in 2026) as its main venue for specification progress and adoption case studies.
- GO FAIR, the broader initiative built around implementing the FAIR principles, hosts the FDO Forum as one of its formal Implementation Networks — situating FDO explicitly as a FAIR-implementation project rather than a competing standard.
- The DONA Foundation governs the Digital Object Cloud and the Handle System infrastructure that much of the FDO identifier-resolution model builds on — the same underlying resolution technology that DOI registration agencies (coordinated by the International DOI Foundation) already use to resolve DOIs at scale, which is part of why the FDO community treats Handle-based resolution as a proven foundation rather than an unproven bet.
- The Research Data Alliance (RDA) contributes working-group structure and cross-community coordination, the same role it plays elsewhere in persistent-identifier and CRIS interoperability work more broadly, and FDO specification work has also engaged standards bodies including ISO, IETF, and W3C on specific technical liaison points.
For a research administrator evaluating whether to take FDO seriously as more than a research-infrastructure side project, this multi-body coordination — rather than one vendor or one lab pushing a proprietary format — is the relevant signal, alongside the fact that the underlying resolution layer (Handle System) is the same infrastructure already load-bearing for DOI resolution today.
How FDO relates to identifier and CRIS infrastructure research administrators already use
FDO is not a replacement for the PID infrastructure research administrators work with daily — ORCID iDs, DOIs, ROR IDs — it is a proposed layer that makes the objects those identifiers point to more directly machine-interoperable with each other. Concretely:
- A DOI already resolves to a landing page and, via Crossref/DataCite metadata, to structured bibliographic metadata. An FDO built around that same content would additionally attach a formal type definition and a declared set of valid operations, so that software — not just a human reading the landing page — can determine what the object is and what it can legitimately do with it.
- Institutional research information systems (CRIS platforms built on data models such as CERIF) already aim to link people, projects, publications, and datasets into one connected graph. FDO’s typing and operations model is a candidate mechanism for making that graph traversable by automated agents across institutional boundaries, not just within a single CRIS deployment or a single national research infrastructure.
- Machine-actionable data management plans and provenance records (expressible in models such as PROV-O) are natural candidates for FDO packaging, since both already aim at the same goal — letting software, not only a human reviewer, verify what happened to a dataset and under what conditions it can be reused.
In short: FDO doesn’t ask an institution to abandon DOIs, ORCID, ROR, or CERIF-based CRIS deployments. It proposes a common packaging and typing layer that could sit on top of that existing PID and CRIS infrastructure, making the objects those systems already track more directly actionable by other software.
What “emerging” actually means here: current maturity and what to watch
FDO is real, named, and actively developed — it is not vaporware or a single lab’s proposal — but it is not yet a ratified international standard in the way ISO 26324 (the DOI standard) or the Handle System protocol itself are. As of 2026, the FDO Forum’s work is best described as a live, multi-institution specification-and-implementation effort: it is producing draft specifications, running pilot implementation projects, and holding annual conferences to converge on a shared technical approach across participating data infrastructures, rather than publishing a single finished, universally adopted standard that repositories and CRIS vendors already implement as a matter of course.
Practically, that means a research administrator or repository manager evaluating FDO today should treat it the way one would treat any pre-standardization infrastructure effort with credible institutional backing: worth monitoring, worth engaging with through RDA or GO FAIR working groups if your institution runs research infrastructure at a national or disciplinary-hub scale, but not yet something a funder mandate or an institutional repository policy should assume as a compliance requirement. That is a meaningfully different position from the FAIR data principles themselves, which are already widely referenced in funder data management plan requirements — see CASRAI’s guide to the Horizon Europe FAIR data management plan requirements for an example of FAIR already operating as policy, which FDO does not yet do.
Frequently asked questions
Is a FAIR Digital Object the same thing as a DOI?
No. A DOI is a persistent identifier — one of the components an FDO requires. An FDO is the larger packaging concept: content, a PID, machine-actionable metadata, a type definition, and declared operations, bound together. A DOI-identified publication could, in principle, be re-expressed as an FDO by adding the typing and operations layer on top of the identifier and metadata it already has.
Do I need to do anything about FDO right now as a research administrator?
For most institutions, no immediate compliance action is needed — no major funder currently mandates FDO packaging the way several mandate FAIR-compliant data management plans. It is worth knowing the term and the concept, particularly if your institution participates in a national research data infrastructure, a domain-specific data commons, or an RDA working group where FDO adoption decisions are being actively discussed.
How is DOIP different from a normal web API?
DOIP is designed as a common, protocol-level interface intended to work consistently across any FDO-compliant repository, rather than each repository or platform exposing its own bespoke REST API. The goal is that a single client implementation can interact with digital objects hosted by different, independently operated infrastructures, in the same way a single email client can talk to any standards-compliant mail server.
Who maintains the FDO specification?
The FDO Forum, an international community of data-infrastructure experts operating as a GO FAIR Implementation Network, leads specification development, with coordination from the DONA Foundation (Handle System governance) and the Research Data Alliance, and technical liaison touchpoints with bodies including ISO, IETF, and W3C.
