5.1 Handleシステムを活用した識別子/解決サービス

DOI®システムでは、ISO 26324で定義された機能要件を満たすHandleシステム®を活用して、DOI識別子/解決サービスを提供します。

5.1.1 ISO 26234 の解決システム機能要件

ISO 26234に従い、DOI名解決を管理するために使われる技術は、以下の機能をサポートする必要があります。

インターネット対応：グローバルに一意なアドレス空間と通信によって論理的に結ばれたグローバル情報システムを介した伝送。
ファーストクラス命名：システムによって解決される識別子は他のオブジェクトから独立した固有性（アイデンティティ）を持つ必要がある。
一意識別：識別子文字列による唯一の対象物の指定。
機能的粒度：オブジェクトを区別する必要がある場合は、各オブジェクトを別々に解決可能としなければならない。
データ型：解決レコードの特定データ項目の解釈に課される制約に、拡張可能な定義を設けて、類似する制約を持つデータ値をグループ化して、同様に扱えるようにする。
マルチプルレゾリューション：オブジェクトに関する複数の最新情報を（分類された所定のデータ構造で）出力として同時に返す。
解決リクエストから最新情報のすべての関連する値、個々の値、または1つのデータ型のすべての値を返すことができる必要がある。
指定権限：識別子の管理者は確実に識別され、転送できる必要があります。
解決レコードへの適切なアクセス：解決レコードへの変更は記録されなければならず、管理者が依存するデータへのアクセスを提供できなければならない。また、当該データに依存しない人からのプライバシーと機密性を提供できなければならない。
DNSから独立しつつ、DNSとの互換性を保持：ドメイン名システム（DNS）に依存しないが、DNSのドメイン命名や解決サービスと連携できる。
管理の粒度：DOI名は個別またはグループ単位で管理できる。
拡張性：
- 効率的で無限に拡張可能なプロトコル
- 割り当てられる識別子の絶対数や識別子文字列の長さに制限なし
Unicode準拠

注：DOIレコードの定期的な更新は、質の高いサービスを維持するために極めて重要です。

5.1.2 Handleレコード序論

Handleシステムでは、HandleはHandleレコード（DOI名の場合はDOIレコード）と呼ばれる要素の集合に解決されます。要素とは型付けされたデータです。Handleシステムには定義済みのタイプが存在し、いつもで新しいタイプを追加できます（新しいタイプを追加するプロセスは開発中です）。例えば、DOI名はJavaサーブレットなど動的メカニズムに解決することができます。

DOIレコード内の要素には、次のものがあります。

リソースへのリンク：Webアドレス、IPアドレスなど。
メタデータ：DOI名で表されるエンティティの記述、タイプ、条件、所有権など
セキュリティ情報：公開鍵、デジタル署名など。
管理情報:許可を得たDOIレコードの管理者。
ステータス情報：エンティティのステータスなど

図11は、DOIレコードの例です。

要素は、以下で構成されます。

インデックス：DOIレコード内の一意な要素識別子/li>
グローバルな登録タイプ（例えば、URL、記述、IPアドレス、メールアドレスなど）。
値（データ）
許可レベル：値が一般に公開されているか否か、また権限を与えられた管理者が変更できるかどうかを示す。
タイムスタンプ
TTL（有効期限）：情報ソース再度問い合わせるまでに、要素の値をキャッシュできる期間を示す。

注：Handleレコード内の要素は、1つまたは複数のHandleを指すことも、同じあるいは別のHandleレコード内の1つまたは複数の要素を指すこともあります。

5.1.3 Handleシステムのサービスアーキテクチャ

このセクションでは、Handleシステムサービスを簡単に紹介します。詳細については、デジタルオブジェクト識別子解決プロトコル(DO-IRP)仕様を参照してください。

Handleシステムは、単一の分散型グローバルHandleレジストリ（GHR）と、数に制限のないローカルHandleサービス（LHS）で構成されています。

識別子（Handleと呼ばれる）はLHSが管理し、プレフィックスが同じHandleは、同じLHSが管理します。
GHRは、システム内のHandleを担当するLHSを探し出すのに必要な情報を格納しています。

Handleを解決するには、Handleシステムのクライアントはまず、GHRに接続します。すると、このGHRが、要求されたHandleを担当するLHSにクライアントをリダイレクトします。

GHRとLHSの仕組みをより詳しく理解するためには、まずプレフィックスHandleの概念を紹介する必要があります。

プレフィックスHandleの序論（プレフィックス「0.NA」）

Handleシステムではプレフィックスを表す特定のHandleが使用されます。

プレフィックスのHandleは「0.NA/<プレフィックス>」という形で表されます。
プレフィックスHandleのレコード（Handle解決により返されるレコード）には、プレフィックスを管理するための管理データが含まれています。例えば、「0.NA/10.100」というレコードには、10.100のDOI名の解決を担当するLHSの場所（サービス情報）が格納されています（10.6のプレフィックスHandleの例も参照してください）。

グローバルHandleレジストリ（GHR）

GHRは分散型レジストリであり、その運用はDONA財団と複数の組織が共同で管理しています。GHRの分散管理への参加をDONA財団から認められた組織を、マルチプライマリ管理者（MPA）といいます。各MPAはDONA財団から「資格認定」され、「0」区切りのプレフィックスが割り当てられます。MPAはDONA財団の手順に従って独自のGHRサービスを運営し、マルチプライマリベースで他のMPAやDONAと調整します。

DOI財団はMPAであり、プレフィックス「10」が割り当てられています。

GHRの構成：

MPA GHRサービス
DONA財団が運営するGHRサービス

MPA GHRサービスが提供するもの：

Handleの一次レベル（first level）解決
GHRは、Handle解決をリクエストするクライアントの最初のアクセスポイントです。GHRにホストされているプレフィックスHandleに基づいて、クライアントをそのHandleを担当するローカルHandleサービス（LHS）にリダイレクトします。
割り当てられた認証プレフィックスの管理
MPA GHR サービスでは、権限のある管理者は、認証プレフィックスに由来する区切り文字が「1」のプレフィックスHandleの作成と管理を行うことができます。GHRサービスで管理されるすべてのプレフィックスHandleは、他の全GHRサービスに自動的にコピーされます。

GHRは区切り文字が「0」と「1」のプレフィックスHandleのレコードだけを（最大100万件）格納します。その他のプレフィックスはLHSを通して管理されます。

ローカルHandleサービス（LHS）

LHSは、サービスプロバイダーによって独自に運営され、また、1つまたは複数のプレフィックスが割り当てられます。

LHSインスタンス：Handleとプレフィックス

LHSのインスタンスには2種類あります。

Handle LHS
Handle LHSは、ある特定のプレフィックスを持つすべてのHandleをホストし、その解決と管理を提供します。
プレフィックスLHS
プレフィックスLHSは、ある特定のプレフィックスから派生するプレフィックスをホストし、その解決と管理を提供します。

注：管理とは、Handleレコードの作成、変更、削除を意味します。これには管理者の許可が必要です。詳細については、デジタルオブジェクト識別子解決プロトコル(DO-IRP)仕様を参照してください。

同じLHSが両方のインスタンスを提供でき、また任意の数のプレフィックスを担当することができます。

このLHSはいずれも、同じLHSソフトウェアで動作し、設定方法も同じです。

LHSのサービスサイト

Handleシステムのサービスコンポーネントは拡張可能で、どんな大量のサービス負荷にも対応できます。LHSは複数のサービスサイトで構成され、各サイトはサービスが管理するHandleの完全な複製をホストします。各サイトはプライマリサイト（データベースに格納されたHandleレコードの作成、変更、削除などの管理操作に使用できるサイト）の場合もあれば、ミラーサイト（管理操作ができないサイト）の場合もあります。各サービスサイトが、コンピュータクラスタ（コンピュータが密接に接続されて連動する集合）で構成されることもあります。各々が、そのサービスが管理するHandleの特定の小集団を持ちます。複数のサービスサイトがあることで、単一障害点を回避できるほか、これらのサービスサイト間の負荷分散が可能になります。どのサービスサイトでも複数のサーバーを使用することで、サービス負荷が複数のサーバープロセスに分散されるため、処理能力がそれほど高くないコンピュータでもネームサービスに利用することができます。