3.2 DOI名の構文
DOI名の構文はISO 26324の一部として規格化されています。
3.2.1 DOI構文の一般的特徴
DOI構文は、フォワードスラッシュで区切られたDOIプレフィックスとDOIサフィックスから構成されます。
DOI名の長さ、DOIプレフィックスの長さ、DOIサフィックスの長さに制限は設けられていません。DOI名に大文字/小文字の区別はなく、Unicodeの正規図形文字からどんな印刷可能文字でも組み込むことができます。用途に応じて文字の使用(例えば、言語固有の英数字の使用)に関する追加的制約がISO 26324登録管理機関によって規定されることがあります。
注:大文字/小文字を区別しないことの正確な定義は、今後の国際規格改訂で明確にされる予定です。
DOIシステムの種々目的のため、DOI名は曖昧な文字列です。DOI名の特定の文字列から確定的な情報を推測することはできません。具体的に言うと、特定の登録者に割り当てられた登録者コードをDOI名に含めていても、対象物にあたる知的財産の所有権や現在の管理責任を証明することはできません。このような情報は、付随するメタデータで主張できます。
3.2.2 DOIプレフィックス
DOIプレフィックスとはDOI名前空間を指します(名前空間は任意の提携事業者に割り当てられます)。1.7.4 DOI名前空間割り当ての仕組みを参照。
DOIプレフィックスは<directoryIndicator>.<registrantCode>です。
以下のルールが適用されます。
- ディレクトリインジケータは、数値のみを含むことができます。ディレクトリインジケータは通常「10」ですが、DOI財団による規格などの準拠にともない、他のインジケータが指定される場合もあります。
- 登録者コードは、数値と、1つまたは複数のピリオド(終止符)(コードを細分化するために使用)のみを含めることができます。例:10.1000、10.500.100など。
ディレクトリインジケータが「10」の場合、登録者コードは必須です。
3.2.3 DOIサフィックス
各サフィックスは、その前にくるプレフィックス要素に対して一意でなければなりません。一意のサフィックスは連番にすることも、登録者が使用する別のシステムから生成されたまたはそれに基づいた識別子を組み入れることもできます(例えば、ISAN、ISBN、ISRC、ISSN、ISTC、ISNI。これらの場合は例2のようにサフィックスの推奨構成を指定できます)。DOIシステムではサフィックスの長さに制限はありません。
8.3 DOI名登録方針の定義も参照してください。
実例:
- 例1
10.1000/123456:DOIプレフィックス「10.1000」とDOIサフィックス「123456」からなるDOI名 - 例2
10.1038/issn.1476-4687:ISSNを使用するDOIサフィックス
ISSNを使ってDOIサフィックスを構成するには、ISSN(ハイフンを含む)の手前に小文字の 「issn」とピリオドを付けます。(科学誌「Nature」電子版の仮想のDOI名の例です。)
3.2.4 DOI名でサポートされる文字セット
DOI名には、ISO/IEC 10646の汎用文字セット(UCS)に含まれる印刷可能文字ならばどれでも組み込むことができます。これはUnicodeによって規定された文字セットです。Handleシステム®はその核となる部分で、Unicodeの実装にあたるUTF-8を使用しているため、その純粋な形においては文字セットに関する制約が一切ありません。どんな文字でもHandleサーバーへ送ること、Handleサーバーに格納すること、Handleサーバーから引き出すことができます。
文字セットは、現在使用されている主要言語で使われる文字の大半を網羅しています(10.2.1 ASCII以外の文字のUTF-8エンコーディングも参照)。
注:一部の文字は使用を避ける必要があります。3.4 特定のコンテキストにおけるDOI名の構文の制約を参照。
3.2.5 DOI名の大文字と小文字の区別
DOI名に大文字/小文字の区別はありません。テキストの比較にはASCII大文字/小文字変換を使用します(DOI名で大文字/小文字の区別がなされないのはASCII文字のみに当てはまります。非ASCII Unicode文字で大文字/小文字が異なるDOI名は異なる識別子である場合があります)。10.123/ABCは10.123/AbCと同じです。すべてのDOI名は登録時に大文字に変換されます。これは、あらゆる種類のサービスで大文字/小文字の区別をなくす場合に一般的な方法です。解決についても同様です。10.123/ABCというDOI名が登録された場合でも、10.123/abcでこのDOI名は解決します。また、10.123/AbCを登録しようとすると、このDOI名がすでに存在することを伝えるエラーメッセージを受けて、登録は却下されます。
文字エンコーディングの観点からは、サフィックスは大文字/小文字の区別がなされるため、例えば10.123/ABCと10.123/AbCは異なり、それぞれ異なる識別子として区別できますが、DOI財団は、大文字/小文字区別を廃止した場合の影響を詳しく検討した結果、大文字/小文字区別の廃止を決定しました。Handleシステムは、サービスごとに大文字/小文字区別するかしないか設定できるため、区別しない設定は可能です。この制限は初期段階から実装されていて、登録機関は、ASCII文字の大文字と小文字によってのみ区別可能な2つのDOI名が同じものに解決されるようなケースを導入していません。
大文字/小文字を区別することの利点(図書館員や出版社の慣例、人間にとっての読みやすさと期待)よりも重要視されたのが、データ完全性への配慮でした。インターネットにおける大文字/小文字の区別は様々です。DNSは区別しませんが、他のURLは一部の例外を除いて区別します(これはサーバーによります)。UnixとPC/Macのファイル名では大文字/小文字の扱いが異なります(Microsoft Windowsは概して大文字/小文字を区別しませんが、Unixオペレーティングシステムは常に大文字/小文字を区別します)。マークアップ言語タグなどには予期せぬ問題を引き起こす可能性があり、ある特定のソフトウェアが大文字/小文字の区別を尊重し、違うはずの2つのDOI名を混同しないこと保証することはできません。一部の検索エンジンとディレクトリは部分的に大文字/小文字を区別します。ウェブブラウザによっても大文字/小文字区別の扱いは異なります(ウェブブラウザ開発者は「作者は、完全に規格に準拠したブラウザのためだけに設計する場合を除き、個別の識別子を作る手段として大文字/小文字の区別に頼るべきではない」と忠告しています)。
これは、大文字/小文字を区別しないほうが安全で確実、DOIシステムの将来の進化と発展のために望ましい選択肢だということを物語っています。
3.2.6 DOI名におけるチェックデジットの使用について
DOI名は曖昧な文字列です。DOIシステム自体はチェックデジットを使用しません。これは、いくつかの理由から意図的なものです。
- 既存の識別子文字列を変えることなく、プレフィックスとしてDOIに含められること。ISO識別子のような一部の一般的な文字列には既にチェックデジットが入っています。これは自動プロトコル訂正がない場合のキーボード入力や可読性に役立ちます。
- チェックサムが解決ごとに計算される場合の性能上の検討課題
- URLなどの識別子スキームにはチェックデジットがありません。その基礎となるTCP/IPプロトコルにはエラー訂正コンポーネントがあります。これは作成と使用に役立ちます。
ただし、アプリケーションによってはチェックデジットが使われることもあるため、DOI名の中にチェックサムデジットを挿入することがそれらのアプリケーションにとって有益ならば、挿入することも可能です。登録機関は特定のDOIシステムアプリケーションにおけるチェックサムの使用を当該アプリケーションの1ルールとして導入できます。例えば、EIDRのアプリケーションでは、DOIサフィックスに限ってチェック文字の計算が行われます。プレフィックスはこれに含まれていません。プレフィックスが間違っていると、DOI名が不適切な解決システムへ陥る可能性が高いからです。EIDRレジストリはそのAPIを通じて送られたDOI名のプレフィックスを個別に検証します。