DOI® HANDBOOK

DOI HANDBOOK オリジナル版（英語）

3.3 DOI名の構文

  1. DOIハンドブック
  2. 第3章 DOI名前空間
  3. 3.3 DOI名の構文

DOI名の構文はISO 26324の一部として規格化されています。

3.3.1 DOI構文の一般的特徴

DOI名は、Unicode標準で規定されているグラフィック型のコードポイントを一列に並べたシーケンスで構成されます。グラフィック型には、文字、記号、数字、句読点、記号、スペースのすべてのコードポイントが含まれますが、U+0009 （HORIZONTAL TABULA-TION：水平タブ）のような制御コードポイントは含まれません。

このシーケンスは、U+002F（SOLIDUS：スラッシュ）で区切られたDOIプレフィックスとDOIサフィックスで構成されます。

例：DOI名「10.5594/SMPTE.ST2067-21.2020」の場合、「10.5594」がDOIプレフィックス、「SMPTE.ST2067-21.2020」がDOIサフィックスにあたります。

なお、DOI 名、DOI プレフィックス、DOI サフィックスの長さには、あらかじめ定められた制限はありません。

3.3.2 DOIプレフィックス

DOIプレフィックスは、「ディレクトリ識別子」と、その後に続く「登録者コード」で構成されます（登録者コードは省略可能です）。登録者コードが含まれる場合、これら2つの構成要素は U+002E（FULL STOP：ピリオド）で区切られます。

例1： DOI名「10.5594/SMPTE.ST2067-21.2020」では、「10.5594」がDOIプレフィックスであり、「10」がディレクトリ識別子、「5594」が登録者コードです。
ディレクトリ識別子は、0から9までの数字列で構成されます。通常は「10」が用いられますが、将来的にDOI®財団によって他の識別子が使用される可能性があります。
登録者コードは、0から9までの数字列で構成され、複数の数字列がある場合は U+002E（ピリオド）で区切られます。

例2： 仮にDOIプレフィックスが「10.500.100」の場合、ディレクトリ識別子は「10」、登録者コードは「500.100」となります。
なお、ディレクトリ識別子が「10」の場合、登録者コードは必須です。

3.3.3 DOIサフィックス

DOIサフィックスは、登録者が任意に選択したUnicodeコードポイントのシーケンスで構成されます。

DOIプレフィックスとサフィックスの組み合わせは一意でなければなりませんが、同じDOIサフィックスを異なるDOIプレフィックスと組み合わせて使用することは可能です。

DOIサフィックスには、連番を使用することも、登録者が運用する他のシステムに基づいた（または生成された）識別子を組み込むこともできます（例：ISAN、ISBN、ISRC、ISSN、ISTC、ISNIなど。これらを使用する場合、例2に示すように、サフィックスの推奨される構成が規定されることがあります）。詳細については、8.3 DOI名登録方針の定義も参照してください。

例：

3.3.4 DOI名の大文字と小文字の区別

2つのDOI名が同一（等価）であるかを比較する際、ISO/IEC 10646で定義されている「正規化」は行われません。DOI名が等価であるための条件は、そのコードポイントのシーケンスが完全に一致していることです。ただし、U+0041〜U+005A（ラテン大文字のA〜Z）の範囲にあるコードポイントは、U+0061〜U+007A（ラテン小文字のa〜z）の対応するコードポイントと同一であるとみなされます。

この規則は、等価性を判定する場合に限り、かつUnicodeの「基本ラテン（Basic Latin）」ブロックに対してのみ、DOI名の大文字・小文字を区別しないという効果をもたらします。この規定によって、DOI名に含める文字が大文字または小文字のみに制限されるものではありません。

例1： 以下のDOI名は等価です。これは、U+0053（LATIN CAPITAL LETTER S）とU+0073（LATIN SMALL LETTER S）が同一とみなされるためです。

例2： 以下のDOI名は等価ではありません。これは、U+00C1（アキュートアクセント付きラテン大文字A）とU+00E1（アキュートアクセント付きラテン小文字a）が同一とはみなされないためです。

大文字・小文字を区別すること（Case Sensitivity）には、図書館員や出版実務における慣習、人間の読みやすさや期待に沿うといった利点があります。しかし、データの整合性（Data Integrity）に関する考慮事項は、それらの利点を上回ります。

インターネット上のアプリケーションにおける大文字・小文字の扱いは一様ではありません。例えば、DNSは区別しませんが、URLの残りの部分は（サーバーの設定に依存するため）区別される場合とされない場合があります。また、OSによるファイル名の扱い（一般的にWindowsは区別せず、Unix系は常に区別する）や、マークアップ言語のタグなども、予期せぬ問題を引き起こす要因となります。

いかなるソフトウェアも、大文字・小文字の区別を正しく遵守し、本来別物として意図された2つのDOI名を混同しないという保証はありません。検索エンジンやディレクトリの中には部分的にしか区別しないものもあり、Webブラウザ間でも対応が異なる場合があります（ブラウザの開発者は「真に標準に準拠したブラウザ専用に設計する場合を除き、識別子を区別する手段として大文字・小文字の差異に依存すべきではない」と助言しています）。

こうした背景から、DOIシステムの将来的な発展と進化においては、限定的な範囲で大文字・小文字を区別しないことが、より安全かつ堅牢な選択肢であると結論付けられました。

3.3.5 DOI名におけるチェックデジットの使用について

DOIシステム自体はチェックデジットを使用しません。これは、いくつかの理由から意図的なものです。

ただし、アプリケーションによってはチェックデジットが使われることもあるため、DOI名の中にチェックサムデジットを挿入することがそれらのアプリケーションにとって有益ならば、挿入することも可能です。登録機関は特定のDOIシステムアプリケーションにおけるチェックサムの使用を当該アプリケーションの1ルールとして導入できます。例えば、EIDRのアプリケーションでは、DOIサフィックスに限ってチェック文字の計算が行われます。プレフィックスはこれに含まれていません。プレフィックスが間違っていると、DOI名が不適切な解決システムへ陥る可能性が高いからです。EIDRレジストリはそのAPIを通じて送られたDOI名のプレフィックスを個別に検証します。