Identifier Scheme Selection: DOI vs ARK vs Handle for Research Data #

Choosing a persistent identifier scheme is a decision a repository makes once and lives with for decades, because the identifiers it mints outlive the software that minted them, the staff who configured it, and often the institution’s original mandate. Pick a scheme whose cost model does not fit your minting volume, whose governance does not match your autonomy needs, or whose resolution infrastructure you cannot operate, and you inherit either a recurring bill you cannot justify or a resolver you cannot keep running. This comparison sets the three schemes that dominate research-data practice — the Digital Object Identifier (DOI), the Archival Resource Key (ARK), and the Handle System — against the criteria that actually decide the outcome: resolution infrastructure, governance and cost, granularity and suffix passthrough, metadata obligations, persistence guarantees, and tooling. It sits within Persistent Identifiers & Repository Integration as the decision that precedes any minting work, and it feeds directly into the operational guides: the DataCite path in DOI Minting with DataCite and the self-managed path in Minting and Resolving ARK Identifiers. The goal is not to crown a winner but to make the trade-offs explicit enough that your context picks for you.

The three schemes are not competing implementations of the same idea; they occupy different layers. The Handle System is a general-purpose resolution protocol and infrastructure. A DOI is a specific, governed application built on top of the Handle System, with mandatory metadata and a citation-oriented social contract layered over it. An ARK is a scheme deliberately designed to impose no fees and no central metadata mandate, resolving through a shared or local resolver rather than a single global registry. Understanding that layering is what keeps the comparison honest: a DOI is more than a Handle in the same way a managed service is more than the server it runs on.

Resolution Infrastructure #

Resolution is the property that makes an identifier persistent: the ability to send a client from an opaque string to the current location of the thing it names. The three schemes resolve through two distinct infrastructures.

The Handle System is the substrate. It is a distributed resolution protocol in which a handle — a prefix/suffix string such as 20.500.12345/abc — is looked up in a global handle registry and returns one or more typed values, most commonly a URL. Clients resolve either through the native Handle protocol or through the HTTP proxy at the Handle System’s global resolver. Crucially, a Digital Object Identifier (DOI) is a handle: every DOI lives under a reserved Handle System prefix (the 10. namespace), so DOI resolution is Handle resolution, wrapped by the doi.org proxy that adds link-checking and multiple-resolution semantics on top. When you mint a DOI you are, at the wire level, writing a handle record; the difference is everything layered above it.

An Archival Resource Key (ARK) resolves through a different path. ARKs are designed to resolve through the Name-to-Thing (N2T) resolver — a shared resolver that maps an ARK’s Name Assigning Authority Number (NAAN) to the resolving institution and forwards the request — or through any ARK-aware resolver, including one you run yourself against your own base URL. This is the pivotal architectural difference: DOI and Handle resolution depend on a single global registry you must be a member of to write to, while ARK resolution is federated and can be operated locally. An institution can mint and resolve ARKs entirely on its own infrastructure and optionally register its NAAN with N2T for global resolution. That independence is ARK’s defining strength and, without discipline, its defining risk — nobody but you guarantees your ARKs keep resolving. The routing and fallback patterns that keep any of these resolvers highly available are covered in API Routing & Fallbacks.

Governance and Cost #

The governance model determines who can revoke your ability to mint, who sets the rules, and what you pay.

The DOI ecosystem is governed by the International DOI Foundation, which delegates registration to agencies — DataCite for research data and software, Crossref for the scholarly literature. You do not mint DOIs directly; you become a member (or a client of a member) of a registration agency, which assigns you a prefix and charges for the service. Costs are real and recurring: annual membership plus a per-DOI or tiered fee, the exact figures depending on the agency and your organization type. In return you get a curated, well-supported system with strong network effects — a DOI is the identifier funders and journals expect.

The Handle System is governed by the DONA Foundation, which authorizes Multi-Primary Administrators to allocate prefixes. Obtaining a Handle prefix carries a fee, typically an annual prefix charge, but there is no per-identifier cost and no mandated metadata service — you pay for the right to run a prefix and then mint freely under it. This suits an organization that wants control of its own resolution namespace without DOI’s metadata obligations or citation framing.

ARK governance is the lightest of the three. The ARK Alliance stewards the specification and the NAAN registry, and obtaining a NAAN is free. There is no membership, no per-identifier fee, and no central body that can bill you or revoke minting. The cost of ARKs is entirely internal: the staff time and infrastructure to run a resolver and honor a persistence commitment. For a high-volume minting scenario — an object-per-file archive producing millions of identifiers — that zero-marginal-cost model is often decisive.

Granularity and Suffix Passthrough #

Granularity is how finely you can name things, and here ARK offers a capability the others do not expose natively.

All three schemes use an opaque authority/name shape and are agnostic about what the name points to. Where ARK differs is suffix passthrough: an ARK resolver treats a trailing suffix on a base ARK as a request for a component of the named object. Resolving ark:/12345/x54xz321/chapter3/figure2 can pass chapter3/figure2 through to the base object ark:/12345/x54xz321, so a single minted identifier addresses a whole tree of parts without minting one identifier per part. For a dataset with thousands of files, this collapses identifier management from millions of records to one. DOIs and Handles can express component relationships, but only by minting a separate identifier for each component or by encoding structure you resolve yourself; neither defines passthrough as a resolver behavior.

ARK also defines metadata inflections: appending ? to an ARK requests brief metadata and ?? requests a full description and the provider’s persistence commitment, all without a separate metadata endpoint. This inflection mechanism folds discovery into the identifier itself. DOIs achieve the equivalent through HTTP content negotiation against the registration agency’s metadata service — a more capable but more centralized route. The mechanics of NAANs, suffix passthrough, and inflections are worked end to end in Minting and Resolving ARK Identifiers.

Metadata Obligations #

This criterion often decides the choice on its own, because it is where the schemes diverge most sharply in what they demand of you.

A DOI is inseparable from its metadata. To register one you must supply a metadata record conforming to the registration agency’s schema — the DataCite Metadata Schema for data, the Crossref deposit schema for articles — with mandatory fields for title, creators, publisher, publication year, and resource type. The registry stores and exposes this record, and it is a first-class part of the identifier’s value: a DOI is machine-actionable precisely because its metadata is guaranteed present and well-formed. This obligation is a benefit for findability and a burden for lightweight minting, and it is why DOI workflows begin with the crosswalk detailed in the DataCite guide.

The Handle System mandates no metadata schema. A handle record stores typed values, and while you can store descriptive values, nothing requires it. Handle is pure resolution; metadata is your problem to model and serve.

ARK sits in between by design. It mandates nothing but supports metadata through inflections and strongly encourages a machine-readable persistence commitment statement retrievable via ??. The philosophy is that persistence and description are services an institution chooses to provide, not properties the identifier enforces. This makes ARK ideal for naming things early — even things not yet fully described — and enriching them later, which fits archival and repository workflows where identifiers are assigned before cataloging is complete.

Persistence Guarantees #

No identifier scheme makes a thing persist; only an institution does. What the schemes differ on is how explicit they are about that fact.

DOI carries the strongest social guarantee. The registration agency contract obligates you to maintain resolution, keep landing pages live, and publish tombstone pages for withdrawn objects; the community treats a broken DOI as a serious failure. The technology does not enforce persistence, but the contractual and reputational framework around it is the strongest of the three, which is exactly why funders require DOIs.

The Handle System provides a durable technical resolution guarantee — the infrastructure is engineered to resolve handles reliably for the long term — but persistence of the target is administrative and entirely on the prefix holder. A handle resolves as long as you keep its record current.

ARK is the most honest and the most demanding: its design philosophy states outright that persistence is a matter of service and commitment, not technology, and it gives you the ?? inflection specifically to publish your commitment. ARK hands you the mechanism and the responsibility in equal measure. For an institution with strong long-term stewardship, that candor is a feature; for one without it, the absence of an external contract is a risk.

Tooling and Ecosystem #

DOI has the deepest tooling: mature registration-agency APIs, client libraries, harvesting via OAI-PMH and the registry’s REST interfaces, and integration in virtually every reference manager and repository platform. Handle has robust reference server software and native protocol libraries, but its ecosystem is oriented toward infrastructure operators rather than end-user discovery. ARK tooling is lighter and more do-it-yourself — the resolver logic is simple enough to implement in a few hundred lines, minting libraries exist, and N2T provides shared resolution — which is liberating if you have engineering capacity and limiting if you do not.

Interoperability and Lock-In #

The last criterion is exit cost: what happens when you outgrow or lose confidence in a choice. None of the three schemes lets you change an already-minted identifier without breaking every citation of it, so lock-in is real for all of them — but it differs in shape. With a DOI, your prefix and metadata are portable between clients of the same registration agency, and even between agencies through negotiated transfers, but you cannot stop being a member and keep minting; resolution continues only while the agency contract does. With the Handle System, you own your prefix and can move its resolution to any Handle server you run, so operational control is high, but you remain dependent on the global handle registry to advertise that prefix. With ARK, exit cost is lowest in principle — you control the resolver and can repoint a NAAN’s resolution wherever you like — yet that same freedom means nothing external prevents your identifiers from going dark if the institution lapses. The pragmatic hedge that many repositories adopt is to treat the schemes as complementary rather than exclusive: mint ARKs for volume and internal structure, register DOIs for the citable subset, and record the relationships between them so a future migration is a metadata exercise, not a re-minting one.

Decision Matrix #

The matrix condenses the comparison. Read each row as a criterion and each cell as the scheme’s position on it; the right-hand fit column names the situation the scheme wins.

Frequently Asked Questions #

If a DOI is just a handle, why not use the Handle System directly and save the fees? #

Because you are paying for the layer above resolution, not resolution itself. A DOI buys mandatory, well-formed metadata; a citation-oriented social contract that funders and journals recognize; and a curated ecosystem of tooling and harvesting. If your outputs must be cited in the literature or satisfy a data-sharing mandate, a raw handle does not carry that weight even though the resolution mechanism is identical. Use the Handle System directly when you want to run your own resolution namespace and are prepared to model, serve, and guarantee metadata and persistence yourself.

When is an ARK the right choice over a DOI for research data? #

When you mint at very high volume, want zero per-identifier cost, need suffix passthrough to address components of large objects without minting per part, or want to assign identifiers before full description. Archives producing millions of file-level identifiers, or repositories that name objects early and catalog later, fit ARK well. The trade-off is that you provide the resolver and the persistence commitment yourself, with no external contract backing them. Many institutions mint ARKs for internal granularity and additionally register DOIs for the small subset of outputs that need formal citation.

Can one object carry more than one identifier scheme? #

Yes, and it is common. A dataset can hold an ARK for fine-grained internal addressing and a DOI for external citation, with each scheme’s metadata cross-referencing the other. The discipline required is that one identifier is designated canonical for citation and the others declare their relationship to it, so resolvers and readers are never ambiguous about which identifier to cite. Reconciling identifier state across such multi-scheme records is its own operational concern within the wider Persistent Identifiers & Repository Integration area.

Does choosing ARK mean my identifiers will not resolve globally? #

No, provided you register your NAAN with the Name-to-Thing (N2T) resolver and keep your resolver mapping current. N2T forwards a globally issued ARK to your institution’s resolver, so an ARK is as globally resolvable as your uptime and your NAAN registration make it. The difference from DOI is that the guarantee rests on your infrastructure and commitment rather than a registration agency’s contract, which is precisely the autonomy-versus-assurance trade-off the whole choice turns on.

Related Guides #

• Persistent Identifiers & Repository Integration — the overview that frames identifier selection within the wider minting, deposit, and reconciliation workflow.
• Minting and Resolving ARK Identifiers — the hands-on walkthrough of NAANs, suffix passthrough, inflections, and N2T resolution.
• DOI Minting with DataCite — the operational path once the choice lands on a DOI.
• API Routing & Fallbacks — keeping whichever resolver you choose highly available under degradation.