ARK とは何か¶

ARK Alliance 自身の言葉では、ARK（Archival Resource Key）識別子とは、情報への長期的なアクセスを支える URL である。発行するのは Name Assigning Authority として登録した組織で、作る権利に金はかからない。

このページは入口であって、仕様書ではない

体系そのもの、FAQ、shoulder の作法、発行組織の登録簿、現行のドラフトはすべて https://arks.org/ にある。ここで短く書きすぎていると思ったらそちらを読むこと——以下はあくまで、arkhe がなぜこの形なのかを説明するぶんだけである。

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。今日たまたま答えているリゾルバ。ここだけが違う ARK は同じものを指す（identity inert）ので、組織やホストが変われば差し替えてよい
label	`ark:` から識別子本体が始まる。旧形式の `ark:/` も同じ意味で、永久に認識しなければならない
NAAN	名前を割り当てた組織の番号。ARK Alliance に申請する。無料で、二度と再登録されない
shoulder	NAAN の内側の下位名前空間。部門や単位に委譲する
blade	対象ごとに変わる部分。arkhe は乱数で採り、末尾に検査桁を置く
part（`/`）	その手前のものに含まれるものを指す、と述べる
variant（`.`）	その手前のものの変種——形式・言語・版——を指す、と述べる

shoulder と blade は錠前屋の言葉で、arks.org はこの比喩を文字列全体に通している。 NMA は鍵が入っていたカバー、ark:99999 は手で持つ弓（bow）、shoulder と blade が実際に働く部分である。捨てられるのはカバーだけ。

/ と . があるおかげで、受け取った側は文字列だけから構造を推測できる。 ark:99999/x9tn1qkq2g7/c3/s5.pdf を公開するということは、メタデータを引かなくても「s5.pdf は s5 の変種で、それは x9tn1qkq2g7 に含まれる」と述べたことになる。

HTTP と DNS の上に直接建っている。 この一点が DOI や Handle との違いを生み、以下のほとんどはそこから出てくる。

ARK は DOI や Handle と横並びではない¶

ここが誤解されやすいので、はっきり書いておく。

flowchart TB
    subgraph H["Handle System（CNRI / DONA）"]
        DOI["10.xxxx — DOI<br/><small>登録組織が名前空間を管理し、<br/>レコードは RA 側に置かれる</small>"]
        HDL["20.500.xxxxx — CNRI Handle<br/><small>組織が購入する prefix</small>"]
    end
    ARK["ark:99999/…<br/><small>HTTP と DNS の上に直接。下部構造を持たない。</small>"]

DOI は Handle の上に建っている。 doi.org は Handle のリゾルバであり、DOI は Handle の 10.x 名前空間の名前である。ARK だけが別系統で、購入したり加入したり誰かに運用してもらったりする土台を、下に持たない。

効いてくる違いは 3 つ¶

無償で、名前空間も無償。 NAAN は ARK Alliance から無償で交付される。支払う登録組織も、維持する会員資格も無い。

誰も代わりに永続性を保証しない。 DOI では登録組織が約束の一部だが、ARK では 約束はあなたのもので、その中身も自分で述べる。だからこそ尋ねる手段が用意されている。

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

erc:
who: 山田太郎
what: あるデータセット
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

何も名乗らない識別子より、何を名乗っているかが言える識別子のほうが価値がある。 ARK は、ロゴで匂わせるのではなく、主張を明示して検証可能にする。

何でも、どの粒度でも指せる。 データセット、写本の 1 ページ、実物の標本、概念。オンラインである必要も、今も存在している必要もない——対象が失われても、リゾルバは記述を返せる（FAIR A2）。

公開できない対象にも同じことが言える。 到達できない理由が「失われた」ではなく「閉じている」だけなら、識別子は先に配っておける——そして禁止期間が明けたときに 行き先を付け替えるだけで公開になる。閉じた識別子と公開の識別子を同じ形で持つ組み方はクローズド PID とオープン PIDにある。

設計の軸になっている約束¶

ARK は NR（No Re-assignment、再割当てしない） を宣言する。一度配った名前が、別のものを指すようになることはない。

この 1 つの約束のために、arkhe は:

外に出した ARK にも名前空間にも削除を持たない（公開前のものだけが消せる）、
retired にした shoulder を元に戻さない、
主キーの衝突を UPDATE に化けさせず必ず失敗させる、
統合・分割・離脱を跨いで解決し続ける。

それぞれを規律ではなくコードでどう守っているかは壊さないものに書いた。

もう 2 つの用語¶

文字列を構成するものは上の表にある。この文書で何度も出てくるのに、文字列の一部ではない語が 2 つある。


inflection	`?` `??` `?info` の接尾。対象へ行くのではなく、識別子について尋ねる。仕様が必須としているのは `?info`
suffix passthrough	`…/x9tn1qkq2g7/page/3` は `…/x9tn1qkq2g7` のレコードで解決される。子に識別子を振らなくてよい——1 レコード 1 採番で足りる

修飾子の使われ方¶

修飾子（/c3/s5.pdf の部分）は、1 つ採番した名前から、その中身や別の形を指す ために使う。以下はどれも、ark:99999/x9tn1qkq2g7 を 1 件だけ採番し、行き先を https://repo.example.ac.jp/records/1 にした台帳での例である。

使われ方	要求する名前	arkhe の答え
論文の第 3 章第 5 節の PDF	`ark:99999/x9tn1qkq2g7/c3/s5.pdf`	`302` → `https://repo.example.ac.jp/records/1/c3/s5.pdf`
デジタル化した資料の 12 コマ目	`ark:99999/x9tn1qkq2g7/f12`	`302` → `https://repo.example.ac.jp/records/1/f12`
データセットの中の 1 ファイル	`ark:99999/x9tn1qkq2g7/data/2020.csv`	`302` → `https://repo.example.ac.jp/records/1/data/2020.csv`
同じ資料の別の形式	`ark:99999/x9tn1qkq2g7.pdf`	`302` → `https://repo.example.ac.jp/records/1.pdf`

どれも子に識別子を振っていない。台帳に無い名前は、登録されているいちばん長い祖先（ここでは x9tn1qkq2g7）で解決し、残りの尾を行き先の後ろにそのまま継ぐ（suffix passthrough）。したがって継いだ先の URL を、行き先のサーバが実際に返せることが前提になる——arkhe が保証するのは名前から URL への写像までである。

行き先の末尾に `/` を付けない¶

尾は区切り（/ か .）から始まるので、行き先の側に区切りは要らない。末尾に / を付けると、/ が重なるだけでなく、変種が別のパスになる。

要求する名前	行き先 `…/viewer/1`	行き先 `…/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` ← 別のパス

// は大抵のサーバが吸収するが、1.pdf と 1/.pdf は吸収されない。行き先は https://repo.example.ac.jp/viewer/1 の形で登録する。

一部だけ別の場所にあるとき¶

第 3 章だけが別のサーバに移った、という場合は、その部分だけを POST /api/register で登録する（修飾子 /c3）。以後は長いほうの一致が勝つ。

要求する名前	解決に使う記録	arkhe の答え
`…/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`

手順は一部だけ別の所在に向ける。

尾をリクエストパラメータとして渡す¶

行き先のサーバがパスではなくクエリで部分を受け取る作りなら、行き先を パラメータ名と = で終わらせる。尾は単純に連結されるので、そのままその値になる。

行き先  https://repo.example.ac.jp/viewer?id=1&part=

要求する名前	arkhe の答え
`…/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`

受け取る側が決めておくことは 3 つ。

修飾子の無い要求では値が空になる（part=）。空を「全体」と読むこと。
値は / か . で始まる。区切りも含めて送られたままの尾である。
%-エンコードは復号せずに渡る（/c3/s6%20a.pdf は part=/c3/s6%20a.pdf）。 %26 も & に戻らないので、尾が別のパラメータを付け足すことはできない。値を使う前に 1 度だけ復号すること。

行き先を移すときは、パラメータの形ごと移すか、受け取り側で古い形を受けつづける ——移した先がパスで受けるなら、part= を外した行き先に PATCH すれば以後の尾はパスに付く。

shoulder ごと外に委ねている名前空間では、テンプレートで同じことができる（https://other.example.org/resolve?id=${blade} や ?ark=$id。どちらも修飾子まで含む）。設定は分散して運用するを参照。

行き先の無い対象の一部¶

実物の標本や、公開していない原本のように行き先を持たないものにも修飾子は付けられる。 ark:99999/x9m3k8rv5q4（行き先なし）に対する …/x9m3k8rv5q4/c4/s5.pdf は、転送せずに 祖先の記述を 200 で返す。尾だけを持った行き先の無い URL を作ることはしない。

修飾子つきの名前について尋ねる¶

?info や ?json は修飾子の後ろに付けてよい。答えるのは祖先の記述で、 どこから継いだかと、継いだ尾も併せて返る。

$ 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"
}

（抜粋。実際にはこのほかに記述の欄が並ぶ。）

書き方の揺れと、揺れではないもの¶

要求	扱い
`ark:/99999/x9tn1qkq2g7/c4/s5.pdf`（旧形式のラベル）	同じ名前として解決する
`…/x9tn1qkq2g7//c4/s5.pdf/`（区切りの重複・末尾の `/`）	仕様どおり正規化して、`…/c4/s5.pdf` と同じに解決する
`…/x9tn1-qkq2g7/c4/s5.pdf`（base の中のハイフン）	照合では無視する。尾の中のハイフンはそのまま行き先へ渡す
`…/x9tn1qkq2g7/c4/s5.pdf?x=1`（inflection でないクエリ）	行き先には付かない。行き先へ継ぐのはパスだけ
`…/x9tn1qkq2g7%2Fc4/s5.pdf`	別の識別子。`%2F` は区切りではないので `x9tn1qkq2g7` の子にならず、`404`
`…/x9tn1qkq2g8/c4/s5.pdf`（検査桁の誤り）	`404`（`ARKHE-1403`）。検査桁は修飾子を除いた base で確かめる
`ark:12345/…/c4/s5.pdf`（この台帳が預からない NAAN）	尾ごとグローバルリゾルバへ `302`

この先を読む¶

https://arks.org/ — 体系、FAQ、shoulder の作法、発行組織の登録簿、 NAAN の申請方法
The ARK Identifier Scheme — 現行のドラフト。arkhe はこれに合わせて書かれている