 |
HOME | HANDBOOK | FACTSHEETS | FAQs | RESOURCES | USERS | NEWS | MEMBERS AREA |
本書のこの章ではDOI®名の構文を規定します。DOI名は、物質的（デジタル、物理的）な形態をとるオブジェクトや抽象概念（作文等）を、他のオブジェクトから区別する機能的必要性がある場合に、識別するためのものです。 DOI® システムは他の識別子制度と併せて使用できます（例えば現在利用できない追加的機能を提供する場合）。DOIメタデータ記録/DOI構文により、併用する他の制度の文字列をDOIシステムに組み込むこともできます。文字セット、大文字/小文字の区別、一意性、インターネット識別子仕様もここで説明します。
© 国際DOI財団 • 最終更新日: 2016年2月1日
DOI® 名はただひとつの存在（エンティティ）を識別するために割り当てられる一意な「番号」です。DOIシステムは同じDOI名が2度発行されないことを保証しますが、DOI名のプレフィックスの中でオブジェクトを一意に識別する主たる責任は登録者（DOI名を割り当てる企業または個人）とその登録機関にあります。
DOIシステムでは一意性（DOI名による唯一の指示対象の指定）が強制されます。同じ物に2つのDOI名が割り当てられないようにすることが望まれます。
DOIシステムは、物理的形態やデジタル形態をとる有形、無形の知的財産を一意に命名する作業をできるだけシンプルにするよう設計されています。DOI名やDOIレコードの一部として既存の識別子を使用できるため、登録者は自身の既存「コンテンツ資産」にDOI名を簡単に発行できます。プレフィックスは組織の事業要求に見合ったレベルで割り当てることが推奨されます。通常、登録機関は顧客ごとに1つのプレフィックスを発行しますが、ブランドごとにプレフィックスを発行したり、認識可能な何らかのひとまとまりの製品群にプレフィックスを発行することもできます（例えば出版社のインプリント）。
ただし、コンテンツの小さな「断片」を識別したり、既存識別スキーマ（レガシー識別子）では対応できない知的財産を識別できるDOIシステムは、殆どの既存識別子スキーマより格段に進歩しています。
本書のこの節ではDOI名の構文を規定します。DOI名は、物質的（デジタル、物理的）な形態をとるオブジェクトや抽象的概念（作文等）を、他のオブジェクトから区別する機能的必要性がある場合に、識別するためのものです。DOIシステムは他の識別子スキーマと併せて使用できます（例えば現在利用できない追加的機能を、例えば解決機能を、提供する場合）。DOIメタデータ記録/DOI構文により、併用する他スキーマの文字列をDOIシステムに組み込むこともできます。
DOI名の構文は当初ANSI/NISO Z39.84-2000（2005年、2010年に再確認）として規格化され、その後ISO 26324（2010年）の一部として規格化されました。
DOI名は「曖昧な文字列」または「無言の番号」であり、DOIシステムにおけるDOI名の運用について番号から何も推測できないようになっています。ある特定のDOI名によって識別される存在（エンティティ）について何かを知る唯一の確実な方法は、当該DOI名の登録者が登録時に申告するメタデータを見ることです。例えば、ある特定の品物の所有者が変わってもその識別子は永久に同じままです。DOI名が「永続的な識別子」と呼ばれる所以はここにあります。
2.2.1 一般的特徴
DOI構文はフォワードスラッシュで区切られたDOIプレフィックスとDOIサフィックスからなります。
DOI名の長さ、DOIプレフィックスの長さ、DOIサフィックスの長さに制限は設けられていません。
DOI名に大文字/小文字の区別はなく、Unicodeの正規図形文字からどんな印刷可能文字でも組み込むことができます。用途に応じて文字の使用（例えば言語固有の英数字の使用）に関する追加的制約がISO 26324登録認定機関によって規定されることがあります。
（特定のDOI登録者に割り当てられる）一意なDOIプレフィックスと（当該登録者によって特定のオブジェクトに付与される）一意なDOIサフィックスの組み合わせは一意であるため、DOI名の分散的割り当てが可能となります。
DOIシステムの種々目的のため、DOI名は曖昧な文字列です。DOI名の文字列から決定的な情報を推測することはできません。具体的に言うと、登録者に割り当てられた登録者コードをDOI名に含めても、指示対象にあたる知的財産の所有権や現在の管理責任に関する証拠は得られません。このような情報は付随するメタデータで断定できます。
2.2.2 DOI プレフィックス
概要
DOIプレフィックスはディレクトリインジケータとその後に続く登録者コードで構成しなければなりません。これら2つの構成要素は終止符（ピリオド）で区切らなければなりません。
ディレクトリインジケータ
ディレクトリインジケータは「10」にしなければなりません。ディレクトリインジケータは解決システムの中で文字列全体（プレフィックスとサフィックス）をデジタルオブジェクト識別子として区別します。
登録者コード
DOIプレフィックスの2番目の要素は登録者コードにしなければなりません。登録者コードは登録者に割り当てられる一意な文字列です。
|
例 1 | |
|
|
10.1000 | ディレクトリインジケータ「10」とその後ろに続く登録者コード「1000」からなるDOIプレフィックス。 |
|
|
登録者コードは管理を容易にするため必要に応じ子要素に細分することもできます。登録者コードの子要素の手前には終止符を付けなければなりません。このような細分は上下関係を示唆するものではなく、登録者コードは、細分されようがされまいが、DOIシステムの中で同等の地位を持ちます。ただし細分された登録者コードは解決に関して技術的な意味合いを持つことがあります。登録者コード割り当ての詳細についてはISO 26324登録認定機関に相談することが登録者に推奨されます。 | |
|
|
例 2 | |
|
|
10.1000.10 | 登録者コードが細分区分「10」を持つDOIプレフィックス（例1参照）。 |
変更
指示対象の所有権や管理に変化があろうがなかろうが、一旦割り当てられたDOI名は変えてはなりません。
注：登録者コードはDOI名の永久的要素として存続しますが、当初の登録者がDOI名やその関連記録の維持管理にあたって何ら役割を果たさなくなる場合もあります。
2.2.3 DOI サフィックス
DOIサフィックスは登録者によって選ばれた長さが任意の文字列で構成しなければなりません。サフィックスは、それに先行するプレフィックス要素に対し一意でなければなりません。一意なサフィックスは連続する番号であってよく、さもなくば登録者が使用する別のシステムから生成された識別子を組み入れることもできます（例えばISAN、ISBN、ISRC、ISSN、ISTC、ISNI。この場合は例1のようにサフィックスの望ましい構成を指定できます）。
|
|
例 1 | |
|
|
10.1000/123456 | DOIプレフィックス「10.1000」とDOIサフィックス「123456」からなるDOI名。 |
|
|
例 2 | |
|
|
10.1038/issn.1476-4687 | ISSNを使用するDOIサフィックス。ISSNを使ってDOIサフィックスを構成するには、この電子版Nature誌のDOIの仮想的例に見られるように、ISSN（ハイフンを含む）の手前に小文字の「issn」とピリオドを配置します。 |
2.3.1 割り当て原則
DOI名を他のISO識別子スキーマの代わりに使用してはなりません。詳細については第2.7節を参照してください。
あるオブジェクトを他のオブジェクトから区別する機能的必要性がある場合は、どんなオブジェクトにもDOI名を割り当てることができます。
「DOI」は「デジタルオブジェクトの識別子」ではなく「オブジェクトのデジタル識別子」と解釈すべきものです。
DOI名の割り当てに関するルールは、DOIアプリケーションプロファイルによる適切なメタデータに基づく機能的範囲定義も含みます。
2.3.2 粒度
DOI名は、オブジェクトがより大きいエンティティに占める割合に関わりなく、どんなオブジェクトにも割り当てることができます。DOI名は、登録者が適切と考える任意の精度と粒度で割り当てることができます。
テキスト素材の粒度を例にとると、抽象的作品としての小説、その小説の特定の版、その小説のその版の中の特定の章、1つの段落、特定の画像、引用文に、別々のDOI名を割り当てることができます。これらの物を公表/提供するための表明手段にDOI名を割り当てることもできます。
2.3.3 変更されたアイテム
既にDOI名を持つアイテムに変更があった場合、そのアイテムに新たなDOI名を割り当てるか否かの選択は機能的粒度のひとつです。区別の必要がある存在（エンティティ）は何でも識別できます。IDFはこの点についてルールを定めていません。登録機関はそれぞれのコミュニティに相応しいルールを採用できます。
2.3.4 記述
DOI名を割り当てるには、そのDOI名が割り当てられようとしているオブジェクトを記述/説明するメタデータを登録者が提供する必要があります。メタデータでは、DOIシステムの中でオブジェクトを単独のエンティティとして区別できる程度まで当該オブジェクトを記述しなければなりません。
2.3.5 一意性
DOIシステムでは、それぞれのDOI名でただ1つの指示対象を指定しなければなりません。1つの指示対象を複数のDOI名で指定することもできますが、DOI名は各指示対象につき1つずつに限定することが推奨されます。
2.3.6 永続性
どのような割り当て、サービス、用途であってもDOI名が存続する期限を設けてはなりません。
DOI名とその指示対象は、指示対象に関わる権利に変更があっても、あるいは指示対象の管理責任に変更があっても、変更の影響を受けません。
DOIシステムは、識別されるエンティティに関する情報（最低でも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と異なり、それぞれ異なる識別子として区別できますが、IDFは大文字/小文字区別を廃止した場合の影響を詳しく検討した末、大文字/小文字区別の廃止を決定しました。Handleシステムはサービスごとに大文字/小文字区別有りにも大文字/小文字区別無しにも設定できるため、廃止は可能です。この制約は初期段階から導入されていますが、IDF代理機関はASCIIの大文字/小文字だけで区別可能な2つのDOI名が同一URLを解決した事例を一件も提出していません。
大文字/小文字を区別する場合の利点（司書や出版者の実務、人間にとっての読みやすさと期待）よりも重要視されたのがデータ整合性への配慮でした。インターネットにおける大文字/小文字の区別は様々です。DNSは区別しませんが、残りのURLは一部の例外を除いて区別します（これはサーバーによります）。Unixのファイル名とPC/Macのファイル名では大文字/小文字の扱いが異なります（Microsoft Windowsは概して大文字/小文字を区別しませんが、Unixオペレーティングシステムは常に大文字/小文字を区別します）。マークアップ言語タグ等には予期せぬ問題を引き起こす可能性があり、ある特定のソフトウェアが大文字/小文字の区別を尊重し、違うはずの2つのDOI名を混同しないと保証することは誰にもできません。一部の検索エンジンとディレクトリは部分的に大文字/小文字を区別します。ウェブブラウザによっても大文字/小文字区別の扱いは異なります（ウェブブラウザ開発者は「作者は完全に規格に準拠したブラウザのためだけに設計する場合を除き、個別の識別子を作る手段として大文字/小文字の区別に頼るべきではない」と忠告しています）。
これは、大文字/小文字を区別しないほうが安全で確実でDOIシステムの将来の進化と発展のために望ましい選択肢だということを物語っています。
2.5.1 エンコーディング原則
DOI名には、ISO/IEC 10646の汎用文字セット（UCS-2）に含まれる印刷可能文字ならどれでも組み込むことができます。これはUnicode v2.0によって規定された文字セットです。UCS-2文字セットは今日書かれている主要言語で使われる文字の大半を網羅しています。ただし、一部のインターネット技術におけるある種の文字の特殊な使い方のため（例えばxmlにおける角括弧〈〉の使用）、日常的な使用に制約が生じる場合があります(下記参照）。
プレフィックスとサフィックスと文字セットについて考える場合は、DOIシステムをその基礎となる技術から、すなわちHandleシステムから、区別することが大切です。DOIシステムはHandleシステムの1実装です。現在の用途は（これが考えうる/起こりうる唯一の用途というわけではありませんが）、ほぼ完全にワールドワイドウェブがらみで発生しており（ワールドワイドウェブとインターネットは同一ではありません）、進化を遂げるIDF方針によって管理されています。
プレフィックス/サフィックス Handleシステムも、DOIシステム方針も、現在想像しうるいかなるウェブ用途も、エンコーディング以外の部分でサフィックスに何ら制約を課しません（下記参照）。Handle構文はプレフィックスに2つの制約を課します。つまりスラッシュとドットはいずれも「予約された文字」であり、スラッシュはサフィックスからプレフィックスを区切り、ドットはサブプレフィックスの延長に使用します。Handleシステムのルート管理者は「10.」で始まるプレフィックス（例えば10.1000、10.1000.1、10.23）をIDFがDOI名に使うためのプレフィックスとして全て予約しています。
エンコーディング Handleシステムはその核となる部分でUnicodeの1実装にあたるUTF-8を使用しているため、その純粋な形においては文字セットに関する制約は一切ありません。どんな文字でもHandleサーバーへ送ることができ、Handleサーバーに格納でき、Handleサーバーから引き出すことができます。IDFも文字セットに関する制約を課していません。ただし実際には、個々のユーザーの状況しだいでは（例えば使っているブラウザの種類）、現在のウェブ環境によって数多くの文字セット制約が強いられます。（これは動く標的のようなものです。例えばお使いのブラウザが漢字を表示するかどうか、ご存知ですか？）エンコーディングに関する最新の推奨事項の一覧は次節に記載されています。
実装 規格と実装の現実を併せて検討することが大切です。例えばURLでは文字「#」を「16進エンコーディング」しなければなりません。この文字はURLフラグメントの始まりを示すからです。この文字はHandleシステムにとって特別な意味を持ちませんし、DOI名構文の中でも特別な意味を持ちませんが、URLの中に含まれるHandleでは#文字をエンコーディングしなければなりません。さもないとブラウザは#記号のところでHandleを省略します。これはあらゆるウェブ実装に当てはまります。他の文字を、例えば「〈」や「〉」を、「16進エンコーディング」する必要があるか否かはブラウザの実装に応じて異なります。DOI名構文で必要となるこのようなエンコーディングはNISO規格の中で検討されています。総じて、デジタル状況における識別子の実装にあたっては、起こりうるエンコーディング問題を検討し、文字セットに関する制約に対処しなければなりません。これらの文字はウェブ等の環境の中を変更されずに通過できるように動かす必要があります。
2.5.2エンコーディング仕様
本規格によって課せられる具体的要件（Unicodeの使用や予約文字等）を除き、DOIで使われる文字について制約や前提条件はありません。本節ではURLのような特定の応用状況でDOIを使用する場合やHTTPプロトコルとともにDOIを使用する場合に生じるエンコーディング問題をいくつか取り上げます。DOIを使用する他の応用状況でも似たような要件や制約が設けられる可能性があります。ただし、エンコーディングに関するそのような要件や特定の文字の使用に関する制約は、該当する応用状況の中でDOIを使用する場合にのみ当てはまります。これらは本書で定めるDOI構文に含まれません。
URIやURN等の形式でDOI名を提示する方法については、第 2.6とファクトシートDOI® システムとインターネット識別子の仕様を参照してください。."
2.5.2.1 UTF-8エンコーディング
HandleシステムはDOI文字列のエンコーディング方式としてUTF-8を指定しています。UTF-8のもとでASCII文字は維持されます。UTF-8エンコーディングに準拠するにあたってASCII文字に変更を加える必要はありません。Unicodeのデフォルトエンコーディングでは各文字が16ビット（2オクテット）からなります。UTF-8は文字を1～6オクテットでエンコーディングするUnicodeエンコーディングの一種です。UTF-8エンコーディングはASCII以外の文字が使われるときに役割を果たします。例えば「nihongo」という日本語は次のように書きます。
「nihongo」という漢字を表すUnicode列は65E5 672C 8A9Eです。この列はUTF-8でE6 97 A5 E6 9C AC E8 AA 9Eとエンコーディングできます。UTF-8の詳細については1996年10月発行の RFC 2044「UTF-8 UnicodeとISO10646のための変換形式」を参照してください。
詳細についてはUnicodeの最新版を参照してください。UnicodeはUnicode社の商標です。Unicode規格はISO/IEC 10646:2003「汎用多オクテットエンコーディング文字セット（通称：汎用文字セット、UCS」の実装に追加的制約を課します。
2.5.2.2 URLで使用する際のエンコーディングに関する推奨事項
ブラウザでDOIを本格的に利用できるようにするには現在のウェブブラウザ技術に機能性を加える必要があります。つまり追加のブラウザ機能が必要です。将来的には解決をサポートする機能がブラウザに普通に組み込まれるようになると予想されます。
Handle.Netでは自由に使えるFirefox向けリゾルバプラグインをダウンロードできます。このプラグインは一般的なブラウザの機能性を拡張して、ブラウザがHandleプロトコルを理解できるようにします。
ウェブブラウザの機能を拡張する代わりに、デフォルトパブリックDOIプロキシサーバーhttps://doi.org（または以前は完全にサポートされ現在は好まれない構文https://dx.doi.org）を使用するようDOIを構成することもできます。この場合のDOIの解決はURL構文の使用に左右されます。例えば「doi:10.123/456」はhttps://doi.org/10.123/456と書かれます。
DOIはHTMLページでもよく使われます。HTMLページ内のリンクとしてのDOI 10.1006/rwei.1999".0001は次のようになります。
<a href="https://doi.org/10.1006/rwei.1999%22.0001">10.1006/rwei.1999%22.0001</a>
URLの中でDOIを周りのテキストから区別するため " がエンコーディングされていることに注意してください（次節参照）。ユーザーは自身のブラウザにDOIを直接入力する可能性があるため、DOIはエンコーディングされた形で表示されます。
2.5.2.3 エンコーディングに関する問題点
DOIをHTMLやURLやHTTPとともに使用する場合は特別なエンコーディング要件があります。統一資源識別子（URI）の構文はDOIの構文より格段に制限的です。URIは統一資源位置指定子（URL）や統一資源名（URN）にもなります。
URLやURNで許可されないDOI内の文字や別の意味を持つDOI内の文字には16進（%）エンコーディングを使用しなければなりません。16進エンコーディングでは所与の文字の代わりに手前にパーセントを付けた16進値を使用します。したがって#は%23になり、https://doi.org/10.1000/456#789はhttps://doi.org/10.1000/456%23789とエンコーディングされます。このため、ブラウザが通常ならばURLの終点とフラグメントの始点として扱うありのままの#に遭遇することはなくなり、ブラウザは、#で止まる代わりに、文字列全体を解決のためDOIサーバーネットワークへ送ります。注：エンコーディングによりDOIそのものが変わることはなく、変わるのはURLにおけるDOIの表現だけです。エンコーディングされたDOIはDOIレジストリへ送られる前に復号化されます。復号化はプロキシサーバーhttps://doi.org/によって処理されます。DOIレジストリデータベースにはエンコーディングされてないDOIだけが格納されます。例えば上記の数字は「10.1000/456%23789」ではなく「10.1000/456#789」としてDOIレジストリに格納されます。いかなるURLにおいてもパーセント文字（%）は常に16進エンコーディング（%25）しなければなりません。
DOI数字列そのもの関して文字制約は殆どありません。DOIがURLに埋め込まれる場合はURL構文の規約に従わなければなりません。このDOIが別の状況でURL構文の規約に従う必要はありません。
2.5.2.4 DOIのデポジットとURLに義務付けられるエンコーディングと推奨されるエンコーディング
表1および2はDOIのエンコーディング指針を要約したものです。URLの文字セットが最も制限されています。表1は常に16進エンコーディングしなければならない文字のリストです。表2には16進エンコーディングによる置き換えが推奨される文字のリストです。これらのリストの違いは、現在のウェブブラウザでの実際的経験とより正式なURL構文仕様の違いです。DOIディレクトリでは全ての文字が本来の姿で表示されます。
表1：義務付けられるエンコーディング
文字 エンコーディング % (%25) " (%22) # (%23) SPACE (%20) ? (%3F)
表2：推奨されるエンコーディング
文字 エンコーディング < (%3C) > (%3E) { (%7B) } (%7D) ^ (%5E) [ (%5B) ] (%5D) ` (%60) | (%7C) \ (%5C) + (%2B)
尚、ウェブブラウザによる「/./」と「/../」の取り扱いにはばらつきが生じることがあります。スラッシュの一方はパーセントエンコーディングすることが推奨されます。例えば「/./」は「/.%2F」、「/../」は「/..%2F」に変えます。
文脈からDOI名であることがはっきり分かる場合を除き、画面や印刷物に表示されるDOI名の手前には小文字の「doi:」を付けます。この「doi:」ラベルはDOI名値の一部ではありません。
|
|
例 | |
|
|
DOI名「10.1006/jmbi.1998.2354」は「doi:10.1006/jmbi.1998.2354」と表示され印刷されます。 | |
2.6.2 URI表示
小文字の文字列「doi」の使用は、「ftp:」や「http:」等、URI（統一資源識別子）としての表現に関するIETF仕様、RFC 3986に準拠しています。ウェブブラウザに表示される場合は、標準ウェブハイパーリンクを介したDOI名解決を可能にするため、しかるべきプロキシサーバーのアドレスにDOI名を付け加えることができます。標準ウェブハイパーリンクを介してDOIを解決するには、プロキシサーバーのアドレスの後ろにDOI名を付けなければなりません。
|
|
例 | |
|
|
DOI名「10.1006/jmbi.1998.2354」は「https://doi.org/10.1006/jmbi.1998.2354」とすることによって作動可能リンクになります。 | |
URLの中でこのように表現されてHTTPプロトコルで伝送されるDOI名は、URI表現に関する標準IETF指針に準拠しなければなりません。URIの構文はDOIの構文より制限的であり、一部の文字は予約されており、パーセントエンコーディングが必要となります。
注：一部のクライアントソフトウェアやサーバーソフトウェアは自己に本来備わる解決技術を使ってDOIを処理できる場合があります（つまりdoi:10.1006/jmbi.1998.2354はプロキシサーバーのアドレスを加えなくともブラウザによって解釈され、自動的に解決します）。
注：DOIシステムは特定の技術実装から可能な限り独立しています。ウェブ用途の場合はHTTP URIとしてDOI名を表すことができます。それには、第2.5.2.4節で説明したようにDOIの手前にhttps://doi.org/を付け、（必要に応じ）URLやURNに必要な16進（%）エンコーディングを使用します。
ウェブDOI名解決の運用の詳細については第3章： 解決を参照してください。これに役立つツールについてはDOI Toolsを参照してください。インターネット識別子仕様に関わるDOI情報についてはDOIシステムのファクトシートDOIシステムとインターネット識別子の仕様を参照してください。
2.6.3 URN表示
URNで既に標準となっているワークフローの中でDOIを使えるようにするため、DOIプロキシサーバーはDOI名の中で最初のスラッシュの代わりにコロンを使用することを理解します。例えばDOI名10.123/456をhttps://doi.org/urn:doi:10.123:456形式で書くことにより、doi.orgドメイン内のURNとしてDOI名を表現できます。ただし、DOIサフィックスには別のスラッシュを入れることもでき、別のスラッシュを入れる場合は、それらをコロンに置き換えるのではなくパーセントエンコーディングしなければなりません。例えばDOI名10.123/456ABC/zyzで最後のスラッシュ文字を%2Fにエンコーディングするとhttps://doi.org/urn:doi:10.123:456ABC%2Fzyzになります。
2.6.4 その他の表現
ある種の状況（例えばinfo URIスキーマRFC 4452）ではDOI名を別の形式で表現できます。
特定のネットワークコンテキストや参照コンテキストで直接取り扱えない文字や紛らわしい文字は（例えばマイナス符号とハイフンとen-dashはどれも画面上で似たように見えますが、それぞれ異なる文字値を持っています）、使用を控えるか、しかるべき方法でエンコーディングするべきです（例えばURLの場合はUTF-8に変換してからパーセントエンコーディングする）。
人にとっての読みやすさや識別子文字列の長さを最小限に抑えることが重要視される場合は、ShortDOIサービスでDOI名を表示することもできます(shortdoi.org、第2.10節参照）。
特別な技術的要件を満たすため具体的な表現方法が取り決められる場合があります。例えばANSI規格 "ケーブルのためのデジタルプログラム挿入キューイングメッセージ" （SCTE 35:2013）は、（とりわけ）ケーブルTVシステムで放送される番組とともに帯域内にEIDR DOI名を組み入れるための標準的手法を定めています。これは完全ASCII DOI文字列ではなくコンパクトなロスレスEIDR表現を使用します（表8-7）。これはDOI名の解決能力も利用します。これは、帯域外機構を通じてIDを解決してさらなるデータを収集できることを意味します。
2.6.5 原則
コンテンツ発行の大半がデジタル媒体と印刷媒体の組み合わせで行われているため、多くの場合はDOI名を印刷で再現する必要があります。発行者は自身が名づける文書の中にDOI名を入れ、これがダウンロードされたり印刷されるたびにDOI名が確実に表示されるようにします。これはデジタル版の印刷版にも表示されます。DOI名がウェブページ上のボタンとして表現される場合は、ウェブブラウザでカーソルがボタン上に移動した際に、ブラウザウィンドウ下部にDOI名全体が表示されます。
デジタルコンテキストではDOI名は状況に応じ更新されるものと考えられますが（DOI名が示すアクティブリンクは正しく「つなぐ」ことができる）、一旦発行された印刷版は更新することも変更することもできません。例えばジャーナルの記事に印刷されたDOI名から、DOI名が指す記事が何なのかは分かりますが、ウェブ上でこの記事にアクセスする方法は分かりません。ウェブ上でそのDOI名が作動可能であることは必ずしも読者に伝わりません。これを伝えるには、httpプロキシサーバーURL形式のようにすぐにそれと分かる形式でDOI名を印刷します（例えばhttps://doi.org/10.1002/prot.9999）。ただしURL形式による表示を躊躇する理由もいくつかあります。つまり、URLは記事の識別子ではありません。DOI名が識別子です。印刷物が数十年にわたり、ことによると数世紀にわたり、変わらずに存在することを踏まえると、doi.org形式のURLは最も永続的な形ではないかもしれません。
実際には安心してdoi.org形式を使用することができます。何らかの他の形式でDOI名を使用することが一般的になるとしても、doi.org形式はこれから何年も機能し続けるはずです。しかし私たちは、何世紀も先には、最も認知されたアクセス経路としてのhttp://のずっと先に進んでいることでしょう。ぎこちないかもしれませんが、私たちは、DOI名そのものとこれをオンラインで解決する方法の両方を表示するやり方（「この記事のDOI名は10.1002/prot.999で、最新情報はhttps://doi.org/10.1002/prot.999からウェブ上で見つかります、またはhttps://doi.org/...で入手できます」と手短に伝える方法）を推奨します。
DOIシステム実装と登録機関は該当する用途に相応しい追加的提案を行うことができます。
DOIシステムの目的は、既存の付番方式の保持が望ましい場合はこれを保持できるようにし、且つそれらの付番方式にDOI名の機能性を容易に追加できるようにすることです。詳細については下記ファクトシートを参照してください。
2.7.1 概略
1つのリソースに対し複数の識別子が存在すると（コリファレンス）、多様なシステム間の相互運用性に依存しリンクで結ばれたデータ世界やセマンティクウェブアプリケーション等で問題が生じる可能性があります。別の一般的な識別子の存在が分からない場合には問題が生じる可能性があります。2つの識別子が同じ指示対象を持つとされ、実際にはそうでない場合には、さらに大きな問題が生じます（この場合、相互運用性は根本的に破綻します）。複数のオントロジーと参照スキーマの収束を成功させるには、それらのスキーマを可能な限り明確に宣言し、統合する必要があります。DOIシステムと他のISO識別子スキーマとの関係はこの問題の典型といえます。
DOI-XというDOIアプリケーションレジストリとISXIという既存ISO標準レジストリについて考えてみましょう。それぞれに登録認定機関（DOI-X RAとISXI RA）が存在します。DOI-Xが自身が識別しようとしている何かがISXIを持ち、またそういう事態が起こる見込みが高いと考える場合、DOI-X RAは、DOI名でISXIを指示する標準的方法（メタデータのみ、または構文+メタデータ）を取り決めることを望むかどうかをISXI RAに尋ねる（またはISXI RAに尋ねることをIDFに依頼する）必要があります。ISXIがイエスと答えるなら、そのようなメカニズムを取り決めて運用します。ISXIがノーと答えるなら、DOI-Xは差し支えのない範囲でDOIカーネルでISXIを（referentIdentifier(s)として）指示します。ここで検討すべき重要課題は次の通りです。（1）ISXIが識別する物とDOI-Xが指定する物は本当に同じ物か（これは答えがイエスの場合に限り当てはまります）、（2）ISXI RAとDOI-X RAは記録交換のための協定を結ぶことを希望するか？希望する場合、どのような条件で協定を結ぶか？当然ながら、ISXI RAとDOI-X RAが同一団体ならば、この問題はシンプルな内部決定に落ち着きます
参考文献一覧には他のISO TC46/SC9規格が記載されています。
2.7.2 原則
DOI名はISAN、ISBN、ISRC、ISSN、ISTC、ISNIをはじめとする他の識別子スキーマや広く認められている他の識別子の代わりに使用してはなりません。ただし、他の識別子スキーマ/識別子とともに使用する場合はDOIシステムの機能性が加わることによって、これらのシステムから提供される識別機能を高めることができます。
DOIシステム内での他識別子スキーマ参照に関する指針の目的は、潜在的ユーザーに向けて実用性を最大限まで引き出し、内部管理の効率を最大限に高めることです。
2.7.3 DOI名と他の識別子スキーマの関係表示
2.7.3.1 他の識別子スキーマの中で既存の識別子を持つ場合
DOI名の指示対象が一般に認められた識別子スキーマの中でも既存の識別子を持つ場合は、下記方法のいずれか1つ以上を用いてその関係を表します。
a）他の既存識別子をDOI名の構文に組み込むか否かに関わりなく、他の既存識別子をDOIメタデータフィールド「referentIdentifier(s)」[同一の指示対象を共通参照する他の識別子]の中で指示する。
b）既存識別子を、その指示対象を指すDOI名の明示的部分として組み込む。
例1および2はISBNとISSNをDOI名に組み込む場合を示しています。これとは別の統合構文を取り決めることも可能です。国際DOI財団では最新の合意済みスキーマに関する情報を保管しています（ファクトシートDOI システム® と標準識別子スキーマで確認できます）。例3はDOI名が他の識別子スキーマの代わりにはならないことを示しています。
|
|
例 1 | |
|
|
10.978.86123/45678 | DOIのプレフィックスとサフィックスにISBN（978-86-123-4567-8）を組み込む場合。 |
|
|
例 2 | |
|
|
10.1038/issn.1476-4687 | ISSNを使用するDOIサフィックス 。 |
|
|
例 3 | |
|
|
10.97812345/99990 | DOI名。これをISBNのPOS発注システムへ送ったり、GS1バーコードに変換してISBNバーコードとして使用することはできません。ISBN構文に適合していません。 |
|
|
978-12345-99990 | ISBN。これをDOI解決サービスへ送ることはできません。DOI構文に準拠していません。 |
ただし、これらの識別子文字列はいずれも同じ指示対象を持っています。
2.7.3.2 DOI名への既存識別子の組み込み
他のスキーマの既存識別子をDOI名の一部として組み込むことを認める構文ルールは、本国際規格の一部を形成するものではありません。このような場合は下記の点に注意してください。
a）同一の指示対象は、DOI名と組み込まれる識別子文字列によって、それぞれの識別子スキーマの中で独立したエンティティとして区別できる程度まで、表示されなければなりません。
b）DOIシステムの中でDOI名は曖昧な文字列です。DOI名に使われる特定の文字列から他の識別子スキーマに関する決定的な情報は推測できませんし、他の識別子スキーマ用に設計された非DOIアプリケーションでDOI名を使用できる保証はありません（上記の例3を参照）。
c）複数の（第3、第4...の）識別子の存在は、DOI名に組み込むのではなく、DOIメタデータフィールド「referentIdentifier(s)」（複数の値により同一の指示対象を共通参照する他の識別子）で認識させなければなりません。
d）別スキーマの既存識別子の組み込みに関する具体的な構文ルールはISO 26324登録認定機関によって管理されなければなりません。
2.7.3.3 追加的機能性
他団体を通じて利用できる他識別子サービスを補完するため、例えば様々な状況で識別子を解決するため、DOIシステムの機能性を提供できます。識別子を使うサービスは複数の提供業者から提供される可能性があります。ある特定の識別子システムのルールによって、指定された推奨サービス提供業者の利用が余儀なくされる場合があります。この場合は識別子の応用にあたって該当する登録認定機関のルールに従わなければなりません。それぞれの登録認定機関には自治権があり、各自のスキーマやコミュニティの中での運用についてルールを自主的に決定できます。国際DOI財団では他識別子スキーマとの運用に関する合意済み手順の最新情報を保管しています。
ISOスキーマと同じ原則がISO以外のスキーマにも当てはまります。既存の標準識別システム番号をDOI名に組み込むことが、登録者にとって好都合なら、組み込むことができます。既存の標準識別システム番号をDOIメタデータに組み込むこともできます。既存の標準識別システム番号をDOI名に組み込む場合は、同じ番号をDOIメタデータにも組み込まなければなりません。いずれにせよ、DOIシステムと他システムによって全く同じ存在（エンティティ）を識別することが大切です。既存の識別子を組み込めるシステムはDOIシステムだけではありません。例えば物理的なバーコードを使ってISBNを表示することもできます。
DOI名やDOIレコードの中では既存のレガシー識別子を使用できるため、DOIシステムの実装によってかつてない相互運用性を生み出すことができます。例えばDOIシステムのCrossref実装では、サフィックスとしてPIIを組み込みこんでDOI名を作る出版者がいます。サフィックスとしてSICIを組み込む出版者もいます。将来的にはサフィックスとしてISTCを使用する出版者も現れるかもしれません。サフィックスとしてまったく独自の内部製作番号を使用する出版者も現れるかもしれません。DOI名を使用する出版者はCrossrefシステムの中でデータ相互運用性の恩恵に浴します。別のスキーマで既に識別子が割り当て済みのエンティティに番号を改めて振る必要もありません。
DOI名のカーネルメタデータは「識別子」を含めることを義務付けます。「エンティティに適用される一意な識別子（例えばレガシースキーマの識別子）。レガシー識別子が存在する場合は、これを含めるのが普通」。既存（レガシー）識別子を既に含むデータセットについて考えれば、この要件が存在する理由が分かります。つまり、この要素のカーネル宣言を使用してDOIシステムサービスから体系的メタデータを手に入れる自動工程で既存レガシースキーマを利用できるようにするためです。既に述べたように、DOI名は本質的に曖昧で解析不能の文字列であるため、DOI名のサフィックスそのものからレガシー識別子が確実に回収されることはありません（例えばCrossref応用における異種サフィックス集団について考えてみてください）。サフィックスとしてレガシー識別子を追加的に含めることはDOI名作成の必要条件ではありませんが、含めることによって便利になり、DOI名が人にとって読みやすいものになり、管理上望ましくなります。
2.8.1 DOI名を使った既存レガシー識別子との関係表示
エンティティ間の関係はメタデータで表すことができます。例えばある抽象的作品の1つの章はその作品の抜粋であり（ISTCメタデータ内で表示）、（これを1つの作品として識別する必要がある場合は）これにもISTCを持たせることができます。これらのエンティティから仕様ができあがったら、エンティティ間の関係（「何者かが2つのエンティティの間に存在すると主張する関係」）をメタデータの1項目として表現できます。適切なメタデータや仕様があればどんな関係でも表現できます。DOIシステムの詳細なアプリケーションプロファイル構造とDOIシステムサービスがこれを裏付けています。
2.8.2 レガシー識別子をDOI名とともに使用する利点
DOI名に共通する利点に加えて、既存の標準付番スキーマをDOI名に組み込む場合にもいくつかの利点があります。
2.8.3 他の識別子スキーマにおけるDOI表現
応用分野はそれぞれのシステムの中でDOI名を使用するための正式な表現法を定めることができます。例えば Society of Motion Picture & Television Engineers (SMPTE) 推奨基準2079（SMPTE RP 2079:2013:「デジタルオブジェクト識別子（DOI）名とエンターテイメントIDレジストリ（EIDR）識別子の表現法」）はSMPTEドメインの中でのDOI名表現法を定めています。これに関連するSMPTE RP 2021-5:2013「SMPTE BXFとATSC PMCPにおける代替識別子としてのAd-IDとEIDRの運用」はEIDR登録機関からDOI名をTVセット/ケーブルコンテンツ管理システムに連携ことを認めています。
DOI名は曖昧な文字列です。DOIシステム自体はチェックデジットを利用しません。これはよく考えた上でのことであり、いくつかの理由があります。
ただし用途によってはチェックデジットが使われることもあるため、DOI名の中にチェックサムデジットを挿入することがそれらの用途にとって有益なら、挿入することも可能です。登録機関はDOIシステムアプリケーション用途におけるチェックサムの使用を当該用途の1ルールとして導入できます。例えばEIDRのアプリケーションではDOIサフィックスに限ってチェック文字の計算が行われます。プレフィックスはこれに含まれていません。プレフィックスが間違っているとDOIが不適切な解決システムへ陥る可能性が高いからです。EIDRレジストリはそのAPIを通じて送られたDOIのプレフィックスを個別に検証します。
IDFはhandleに基づく2つのサービスを運営しています。shortDOIサービスは誰でも利用できる公共サービスであり、非常に長い文字列になりがちなDOI名にショートカットを作ります。shortDOIサービスはURLのためのURL短縮サービスに似た働きをします。このサービスは10/abcde形式の短いHandleを作り、電子メール、ブログ、モバイルメッセージング等での利用に理想的なhttps://doi.org/abcde形式の短いHTTP URIを実現します。 （shortDOIそのものはDOIではないので注意してください。そのためISOの標準構文やその他要件に適合しません。shortDOIの作成は既存のDOIに限り可能です。）
DOIシステムプロキシサーバーが完全なDOI名だけを解決するのと同様に、shortDOIサービスプロキシサーバーはショートカットだけを解決します。（両プロキシのエラーページは必要に応じ他方のプロキシへ至るリンクを提供します。）このサービスは新たなショートカットを作成し、ショートカットが作成済みの場合は既存のショートカットを返します。
自動化のため、元のDOI名をshortDOIサービスのURLに付け加えるだけでshortDOIサービスを利用することもできます。フォーマットパラメータを使用すれば情報がどのように返されるかを指定できます。詳細については shortDOIサービスのウェブページを参照してください。
DOIシステムとURL、URN、URI等の一般的な識別子との関係を説明するファクトシートを閲覧できます。 "DOI® システムとインターネット識別子の仕様"を参照してください。.
|
®, DOI®、DOI.ORG®及びshortDOI®は国際DOI®財団 (IDF)の登録商標です。 |