What ARK is¶

In the ARK Alliance's own words, Archival Resource Key (ARK) identifiers are URLs that support long-term access to information. They are issued by organisations that register as Name Assigning Authorities, and nobody pays for the right to create them.

This page is an orientation, not the specification

The scheme itself, the FAQ, the shoulder conventions, the registry of assigning organisations and the current draft all live at https://arks.org/. Read it for anything this page states too briefly — everything below is only the part that explains why arkhe is shaped the way it is.

The parts of an ARK¶

     https://ark.example.ac.jp/ark:99999/x9tn1qkq2g7/c3/s5.pdf
     \________________________/\__/\___/ \/\_______/\_/\_____/
                NMA           label NAAN     blade  part variant
                                     shoulder

     https://ark.example.ac.jp/ark:99999/x9tn1qkq2g7/c3/s5.pdf
                               \___________________/\________/
                                 base compact name  qualifiers


NMA	Name Mapping Authority — the resolver that happens to be answering today. Identity inert: ARKs that differ only here identify the same thing, so it can be replaced when an organisation or a host changes
label	`ark:` marks the start of the identifier proper. The older `ark:/` means the same thing and must be recognised in perpetuity
NAAN	The number of the organisation that assigned the name. Requested from the ARK Alliance, free, and never re-registered
shoulder	A sub-namespace inside a NAAN, delegated to a department or unit
blade	The part that varies per object. arkhe mints it at random, ending in a check digit
part (`/`)	Says this names something contained in what precedes it
variant (`.`)	Says this names a variant form — a format, a language, a version — of what precedes it

The shoulder and blade come from locksmithing, and arks.org carries the metaphor through the whole string: the NMA is the cover the key comes in, ark:99999 is the bow you hold, and the shoulder and blade are the parts that do the work. Only the cover is disposable.

/ and . are the reason a recipient can infer structure from the string alone. Publishing ark:99999/x9tn1qkq2g7/c3/s5.pdf says, without anyone having to fetch a metadata record, that s5.pdf is a variant of s5, which is contained in x9tn1qkq2g7.

It sits on plain HTTP and DNS. That single fact separates it from DOI and Handle, and most of what follows comes from it.

ARK is not a peer of DOI and Handle¶

This is the part people get wrong, so it is worth stating plainly.

flowchart TB
    subgraph H["Handle System (CNRI / DONA)"]
        DOI["10.xxxx — DOI<br/><small>registration agencies manage the namespace;<br/>records live with the RA</small>"]
        HDL["20.500.xxxxx — CNRI Handle<br/><small>a prefix an organisation buys</small>"]
    end
    ARK["ark:99999/…<br/><small>plain HTTP and DNS. No substructure beneath it.</small>"]

DOI is built on Handle. doi.org is a Handle resolver, and a DOI is a name in Handle's 10.x namespace. ARK alone is a separate lineage — nothing sits beneath it that has to be bought, joined or operated by someone else.

The three differences that matter¶

It is free, and the namespace is free. A NAAN costs nothing and is granted by the ARK Alliance. There is no registration agency to pay and no membership to maintain.

Nobody guarantees persistence on your behalf. With a DOI, the registration agency is part of the promise. With an ARK, the promise is yours and you say what it is — which is why the scheme has a way to ask:

curl "https://example.org/ark:99999/x9tn1qkq2g7??"

erc:
who: 山田太郎
what: A dataset
when: 2026
where: ark:99999/x9tn1qkq2g7
redirect: https://repo.example.ac.jp/records/1
policy: NP | NR, OP, CC | 2026 | https://example.org/policy
commitment-level: permanent-dynamic

An identifier that claims nothing is worth less than one that says exactly what it claims. ARK makes the claim explicit and checkable rather than implied by a logo.

It can name anything, at any granularity. A dataset, a page of a manuscript, a physical specimen, a concept. There is no requirement that the thing be online, or even that it exist any more — the resolver can still return a description (FAIR A2).

The same holds for things that cannot be published. When the reason it is out of reach is "closed" rather than "lost", the identifier can be handed out first — and when the embargo lifts, changing the target is all that publication takes. Holding closed and open identifiers in the same shape is covered in Closed PIDs and open PIDs.

The promise the design turns on¶

ARK declares NR — no re-assignment. A name, once given out, never comes to mean something else.

That one commitment is why arkhe:

has no delete for a published ARK or for a namespace (only one that never went out can go),
refuses to move a shoulder back out of retired,
makes a primary key collision fail rather than quietly become an update,
keeps resolving through mergers, splits and departures.

Read Invariants for how each of those is enforced in code rather than left to discipline.

Two more terms¶

The parts of the string are in the table above. Two words that appear throughout this documentation are not parts of the string at all:


inflection	A `?`, `??` or `?info` suffix that asks the resolver about the identifier instead of following it. `?info` is the one the specification requires
suffix passthrough	`…/x9tn1qkq2g7/page/3` resolves through the record for `…/x9tn1qkq2g7`, so children need no identifiers of their own — one record per minting is enough

Qualifiers in use¶

A qualifier (the /c3/s5.pdf part) lets one minted name point into what it names, or at another form of it. Every example below assumes a ledger where only ark:99999/x9tn1qkq2g7 was minted, with the target https://repo.example.ac.jp/records/1.

Used for	Name requested	What arkhe answers
Chapter 3, section 5 of a thesis, as PDF	`ark:99999/x9tn1qkq2g7/c3/s5.pdf`	`302` → `https://repo.example.ac.jp/records/1/c3/s5.pdf`
Frame 12 of a digitised item	`ark:99999/x9tn1qkq2g7/f12`	`302` → `https://repo.example.ac.jp/records/1/f12`
One file inside a dataset	`ark:99999/x9tn1qkq2g7/data/2020.csv`	`302` → `https://repo.example.ac.jp/records/1/data/2020.csv`
The same item in another format	`ark:99999/x9tn1qkq2g7.pdf`	`302` → `https://repo.example.ac.jp/records/1.pdf`

None of the children was given an identifier. A name the ledger does not hold is resolved through its longest registered ancestor (here x9tn1qkq2g7), and the rest is appended to that target as it is — suffix passthrough. So the server at the target has to answer the URL that results; what arkhe guarantees is the mapping from name to URL.

Do not end the target with `/`¶

The suffix begins with its own separator (/ or .), so the target needs none. End the target with / and slashes double up — and, worse, a variant becomes a different path.

Name requested	Target `…/viewer/1`	Target `…/viewer/1/`
`…/x9tn1qkq2g7`	`…/viewer/1`	`…/viewer/1/`
`…/x9tn1qkq2g7/c3/s6.pdf`	`…/viewer/1/c3/s6.pdf`	`…/viewer/1//c3/s6.pdf`
`…/x9tn1qkq2g7.pdf`	`…/viewer/1.pdf`	`…/viewer/1/.pdf` ← a different path

Most servers absorb //, but nothing turns 1/.pdf back into 1.pdf. Register the target as https://repo.example.ac.jp/viewer/1.

When one part lives somewhere else¶

If chapter 3 alone moved to another server, register just that part with POST /api/register (qualifier /c3). From then on the longer match wins.

Name requested	Record it resolves through	What arkhe answers
`…/x9tn1qkq2g7/c3`	`…/x9tn1qkq2g7/c3`	`302` → `https://cold.example.ac.jp/archive/x9tn1qkq2g7/chapter3`
`…/x9tn1qkq2g7/c3/s6.pdf`	`…/x9tn1qkq2g7/c3`	`302` → `https://cold.example.ac.jp/archive/x9tn1qkq2g7/chapter3/s6.pdf`
`…/x9tn1qkq2g7/c4/s5.pdf`	`…/x9tn1qkq2g7`	`302` → `https://repo.example.ac.jp/records/1/c4/s5.pdf`

The steps are in Point one part somewhere else.

Passing the suffix as a request parameter¶

If the server at the target takes the part in the query string rather than the path, end the target with the parameter name and =. The suffix is appended as it is, so it becomes that parameter's value.

target  https://repo.example.ac.jp/viewer?id=1&part=

Name requested	What arkhe answers
`…/x9tn1qkq2g7`	`302` → `https://repo.example.ac.jp/viewer?id=1&part=`
`…/x9tn1qkq2g7/c3/s5.pdf`	`302` → `https://repo.example.ac.jp/viewer?id=1&part=/c3/s5.pdf`
`…/x9tn1qkq2g7/c3/s6.pdf`	`302` → `https://repo.example.ac.jp/viewer?id=1&part=/c3/s6.pdf`
`…/x9tn1qkq2g7.pdf`	`302` → `https://repo.example.ac.jp/viewer?id=1&part=.pdf`

Three things are for the receiving side to settle:

With no qualifier the value is empty (part=). Read empty as "the whole thing".
The value begins with / or .: it is the suffix exactly as sent, separators included.
Percent-encoding arrives undecoded (/c3/s6%20a.pdf gives part=/c3/s6%20a.pdf). %26 does not turn back into & either, so a suffix cannot add a parameter of its own. Decode the value once before using it.

When the target moves, move the parameter form with it, or keep accepting the old form — if the new server takes paths, PATCH the target without part= and suffixes land on the path from then on.

For a namespace whose whole shoulder is handed to someone else, a template does the same (https://other.example.org/resolve?id=${blade}, or ?ark=$id; both include the qualifier). See Running several arkhe.

Part of something with no target¶

Things with no target — a physical specimen, an original that is not online — take qualifiers too. For ark:99999/x9m3k8rv5q4 (no target), …/x9m3k8rv5q4/c4/s5.pdf is not redirected: the ancestor's description comes back with 200. arkhe never builds a URL out of a suffix with nothing in front of it.

Asking about a qualified name¶

?info and ?json may follow a qualifier. The answer is the ancestor's description, together with where it was inherited from and the suffix that was carried.

$ curl "https://ark.example.ac.jp/ark:99999/x9tn1qkq2g7/c4/s5.pdf?json"

{
  "ark": "ark:99999/x9tn1qkq2g7/c4/s5.pdf",
  "inherited_from": "ark:99999/x9tn1qkq2g7",
  "suffix": "/c4/s5.pdf",
  "redirect": "https://repo.example.ac.jp/records/1/c4/s5.pdf"
}

(An excerpt: the description's own fields come with it.)

Spellings that vary, and ones that do not¶

Request	How it is treated
`ark:/99999/x9tn1qkq2g7/c4/s5.pdf` (the older label)	Resolved as the same name
`…/x9tn1qkq2g7//c4/s5.pdf/` (doubled or trailing separators)	Normalised as the specification says, and resolved like `…/c4/s5.pdf`
`…/x9tn1-qkq2g7/c4/s5.pdf` (a hyphen in the base)	Ignored when matching. Hyphens in the suffix are passed to the target as they are
`…/x9tn1qkq2g7/c4/s5.pdf?x=1` (a query that is not an inflection)	Not carried to the target. Only the path is appended
`…/x9tn1qkq2g7%2Fc4/s5.pdf`	A different identifier. `%2F` is not a separator, so this is no child of `x9tn1qkq2g7`, and it answers `404`
`…/x9tn1qkq2g8/c4/s5.pdf` (a wrong check digit)	`404` (`ARKHE-1403`). The check digit is verified over the base, without the qualifier
`ark:12345/…/c4/s5.pdf` (a NAAN this ledger does not hold)	`302` to the global resolver, suffix and all

Read on¶

https://arks.org/ — the scheme, the FAQ, shoulder conventions, the registry of assigning organisations, and how to request a NAAN
The ARK Identifier Scheme — the current draft, which is what arkhe is written against