 |
HOME | HANDBOOK | FACTSHEETS | FAQs | RESOURCES | USERS | NEWS | MEMBERS AREA |
この章ではDOI®名と関連メタデータの登録、保守に関する共通の手順とルールを手短に説明します。登録機関は独自の詳細業務手順を採用するため、ここに記載された一般指針と併せて該当する登録機関の手順も参照してください。
© 国際DOI財団 • 最終更新日: 2016年11月2日
DOIディレクトリは、登録機関（以下RA）によって異なる運営体制に関わりなく全てのDOI名に対して信頼性の高いHandle解決、管理、バックアップを提供するよう配置・構成されたウェブプロキシとHandleサービスからなる仮想サービスです。このアプローチは、RAが信頼性のある全体的なサービスを保証しながら、独自のビジネスモデルを開発して顧客の要求を満たすための柔軟性を提供します。
このディレクトリは複数のHandleサイトを含むローカルHandleサービス (LHS) で構成されています。自前のHandleサービスを維持管理することを望まないRAは、第9.1.2節で後述するDOIディレクトリマネージャによって管理されるローカルHandleサービスの利用を選べます。
それぞれのサービスには一次サイトと1つ以上の二次（ミラー）サイトがあります。二次サイトの中には、自前のローカルHandleサービスを運営することを選んだ登録機関によって管理されるものもありますが、IDFは、少なくとも1つの二次サイトはIDFによって運営される二次サイトにすることを義務付けています。独立したHandleサービスを運営する場合にも、ディレクトリマネージャによって運営されるサービスを利用する場合にも、ディレクトリマネージャがプレフィックスを作成し割り当てる必要があります。
このディレクトリ構造にはプロキシサーバー（いずれもドメイン名はdoi.org）も含まれています。ホスティングサイトやRAの運営施設で多数のプロキシサーバーが地理的に分散して稼働していますが、いずれもCNRIによって開発されたソフトウェアを使用しています（以前使われていたプロキシサーバーのドメイン名dx.doi.orgは現在推奨されていませんが、引き続きサポートされています）。
9.1.1 DOIプレフィックスの割り当て
プレフィックスは、DOI名の最初の部分を構成し、HandleシステムのグローバルHandleレジストリ®(GHR)にHandleとして格納される一意な文字列です（例えば0.NA/10.1000）。登録機関は必要なプレフィックスをいくつでも受け取って割り当てることができます。
DOI名のプレフィックスはどれも10で始まり、順番に割り当てられていきます。予約済みのプレフィックスを要求することはできません。サフィックスと呼ばれるDOI名の2番目の部分は、所有者かその代理機関によって割り当てられるローカルな文字列です（例えば10.1000/34004JFR）。プレフィックスとサフィックスはフォワードスラッシュ（/）で区切られます。サフィックスの番号付与に関する推奨指針については第2章：付番 を参照してください
プレフィックスは事業の要求に見合ったレベルで割り当てることが推奨されます。通常、RAは顧客ごとに1つのプレフィックスを発行しますが、ブランドごとにプレフィックスを発行したり、認識可能な何らかの製品群にプレフィックスを発行することもできます（例えば出版社のインプリント）。その選択権はRAにありますが、IDFや他のRAが要件を協議し提言を行うこともあります。
それぞれのRAには、特別な意味を持たないひとまとまりの（ブロック単位の）連続番号としてプレフィックスが分配されます。RAは、特に自前のローカルHandleサービスを運営する登録機関は、自身のプレフィックスの基本的構成を理解する必要があります。それぞれのプレフィックスには「サービス情報」が対応付けられます。このサービス情報はHandleサービスのマップ/レイアウトです。サービス情報はサービスHandleに組み込まれます（管理を容易にするためのもうひとつの間接レベル）。
プレフィックスの値は次の通りです（例）：
プレフィックス：0.NA/10.1201
データ値：100:HS_ADMIN 0.NA/10:200（別のHandleを指し示すCNRIアドミン）
データ値：101:HS_ADMIN 0.NA/10.1201:200（プレフィックスレコード内のグループを指し示すRAアドミン － リスト内の次を参照）
データ値：200:HS_VLIST（アドミニストレータのグループ/リスト）
0.NA/10.1201:300
10.1.admin/user1:300
データ値：300:HS_PUBKEY（ローカルサーバー管理のための公開鍵）
データ値：1:HS_SERV 0.SERV/10.1（サービスHandle）
CNRIはプレフィックスとRAの管理権限を保持します。これは管理のためのバックアップを目的とするものです。DOI名の管理にあたってはアドミンDOIの使用が必要となります。アドミンDOIは10.1.admin/等で始まり、RAのLHSごとに若干異なります。RAには、ミラーリング機構の妨げとなる恐れのある大きなトランザクションが行われる場合にCNRIとIDFに通知する義務があります。RAには、自身のLHSで設定変更がある場合にもCNRIに通知する義務があります。プレフィックスの分配や管理業務を含む、プレフィックス割り当てに関する情報は、ディレクトリマネージャから（jeuler@cnri.reston.va.usに連絡してください）RAに提供されます。
9.1.2 DOIディレクトリマネージャによって運営されるローカルHandleサービスの使用
ディレクトリマネージャによって運営されるサービスの使用を決め、1つまたはブロック単位のプレフィックスを受け取る準備ができたRAは、サービスの開始にあたってディレクトリマネージャに連絡しなければなりません。それぞれのプレフィックスにはユーザー名とパスワードがあります。ユーザー名/パスワードはDOI名をデポジットするときの認証に必要となります。
RAが利用するサービスが何であれ、何をどの程度の粒度で識別するか、識別子にどんな情報を関連付けるか、作業の流れ、権限等を最初に決めることが大切です。ディレクトリマネージャによって運営されるサービスでメタデータをデポジットするためのメカニズムやメタデータデータベースは現在存在しません。RAが独自のメタデータデポジット工程を構成する例については、第9.14節を参照してください。
9.1.3 ローカルHandleサービスの運営
RAがDOI名のためローカルHandleサービス（LHS）を設置し使用することを選ぶ場合でも、プレフィックスはディレクトリマネージャが作成しますが、RAには他にもやるべきことがあります。
まずはサーバーディストリビューションをダウンロードします(現行バージョン 8.1, 2015/12リリース、Handle.Net Registryからダウンロード可能)。インストール手順はディストリビューションに含まれるREADME.txtに記載されています。ローカルHandleサービスの準備と管理にあたってはシステム管理者タイプの人材が必要となります。HandleサーバーはJavaで書かれており、WindowsかUnixで作動しますが、品質がサーバー級のコンピュータが推奨されます。Handleサーバーはインターネット上に存在しなければなりません。つまり、Handleサーバーに必要なポート（2641および8000）が送受信リクエストに対し開放されている場合を除き、Handleサーバーをファイアウォールの裏で作動させることはできません。
SimpleSetupスクリプトはsitebndl.binというファイルを作成しローカルHandleサービスのサービス情報を収容します。RAはディストリビューションの説明書に従ってhdladmin@cnri.reston.va.usへファイルを送る必要があります（ディレクトリマネージャへファイルを直接送る場合はjeuler@cnri.reston.va.us）。ディレクトリマネージャが10で始まるプレフィックスを作成するには、氏名、組織名、要請がIDF RAからのものであることを、ディレクトリマネージャに知らせることが重要です。プレフィックスはグローバルHandleレジストリ（GHR）で作成されます。プレフィックスには、IPアドレスやサーバーの公開鍵等、ローカルHandleサービスを一意に識別する情報が含まれます。GHRはこの情報をもとにDOI名解決リクエストの送信先を判断します。
この時点でRAが使用する認証の種類について協議が行われる場合があります。Handleシステムは公開鍵か秘密鍵を使用します。DOI名を作成する権限はプレフィックスレベルになりますが、それぞれのDOI名は管理者（通常はプレフィックスレコード内のグループへのリファレンス）がいます。詳しい技術情報はHandleシステム技術マニュアルに記載されています。
CNRIでセカンダリサーバーをインストールできるようにするため、IDFの方針では、RAが自身のHandleサーバーの設定の変更について責任を負うことになっています。セカンダリサーバーは登録機関サーバーのDOI名のデータベースを収容します。それにはサーバーの設定ファイルに些細な変更が必要となります。この作業にあたってディレクトリマネージャが調整を図ります。設定が完了した後には、セカンダリサーバーがRAのサーバーへ接続できるか否かを確かめるためcronジョブが作成されます。接続に関わる問題(RAのサーバーがシャットダウン）が生じる場合はRAに電子メールで通知され、できるだけ速やかに問題を解消することがRAに求められます。
自前のローカルHandleサービスを運営することを選択する場合は、RA側により一層の専門知識が要求されますが、技術的な困難に直面する場合はいつでもディレクトリマネージャの支援を受けることができます。ウェブサーバーやメールサーバーに比べるとシステム管理者にとって馴染が薄いかもしれませんが、他のサーバーを設定する場合と大差ありません。
DOI登録をはじめとするビジネスに不可欠な基盤要素を直接管理することを望むRAにとっては、ローカルHandleサービスの運営がベストな選択かもしれません。例えば、自身の用途に相応しい性能レベルを選択することによって管理と解決に高い性能水準を実現しようと計画するRA、自身のビジネスを妨げることなく必要なDOIデポジットデータの第三者預託コピーをIDFに進んで提供できるRA、費用と運営収益の大半をIDFではなくRAが負担しかつ受け取る「運営連盟」構造への迅速な移行を望むRAなどがこれに該当します。「運営連盟が引き継ぐまでは会費で開発を支える」という基本的前提は今なお有効と考えられていますが、IDFは移行を奨励しようとしています。
ローカルHandleサービスの運営に関心を寄せるRAにとっては、CNRI職員を交えた技術総括会議の予定を組むことが賢明な選択です。この会議を手配する場合や疑問がある場合はディレクトリマネージャjeuler@cnri.reston.va.usへ電子メールを送ってください。
9.1.4 DOI名と関連メタデータの登録
登録機関はDOI名と関連メタデータ申告の登録をサポートします。それにはDOI®アプリケーションプロファイルを使用します。登録機関はDOI名登録の管理とメタデータデポジット/保守について独自のワークフローと手順を開発し、登録者コミュニティに独自の情報を提供します。
以下に述べる手順はRAがDOI名と申告されたメタデータを登録するプロセスの一例です。この手順に従えば、DOI名と関連メタデータレコードをRAによって運営されるDOIシステムセントラルメタデータディレクトリに一括登録（バッチ登録）でき、登録後はディレクトリに対して問い合わせ（クエリー）を行えます。現在使用されているバッチファイル形式は特定のXMLスキーマによって規定されたXMLで、送信はHTTP POST経由で行われています。セキュリティはHTTP基本認証で、PGP暗号化が後ほど追加されます。送信元へのバッチ受信確認は電子メールで行われます。
メタデータ作成: 登録者はスキーマに従ってXMLバッチファイルを準備します。これらのバッチファイルは、それぞれのメタデータ要素に期待される内容を規定する一連のルールによって制約されます。1つのXMLバッチに何百ものDOI名のメタデータを含めることができます。メタデータの内容の妥当性を保証するための品質管理対策の開発、実装は登録者の責任となります。品質管理とデータチェックにはRAのメタデータ収集工程に導入されたプロセスを役立てることができます。
メタデータ収集: XMLは受信時にスキーマに照らして検証されます。XMLを解析できない場合はバッチは却下され、登録者はXMLを訂正し、バッチを再度送信しなければなりません。XMLバッチはHTTP POSTで指定のHTTPサーバーへ送られた後にJavaサーブレットに送られます。Javaサーブレットは受け取ったXMLファイルを解析、検証し、XMLが妥当で受理されたか否かを登録者にリアルタイムで知らせます。送信過程では、XMLの検証に先立ちDOIシステムプレフィックスホルダーのログインとパスワードを捕捉し、検査します。XMLファイルにはバッチの識別子として使われるタイムスタンプが入っています。登録者が望む場合は、それぞれのDOI名レコードに専用のタイムスタンプを付けることもできます。
DOI名デポジット: 次にサーブレットはDOI名と対応するURLをDOIシステムにデポジットし、タイムスタンプデータ値を付け加えます。そのDOI名が新規でなくDOIシステムの中に既に存在する場合は、提出されたDOI名データがシステム内に既に存在するデータより新しいか否かをタイムスタンプから判断します。提出されたDOI名データのほうが新しい場合は、既存のDOI名データが更新されます。同様にXMLで書かれたログファイルがバッチごとに作成されます。このログファイルはバッチ内の合計DOI名レコード数とDOIシステムへのデポジットの成功数と失敗数を伝えます。失敗の場合は、失敗したDOI名と失敗の理由が記録されます。DOIシステムの障害はシステムエラーが原因で起こる場合もありますが、多くの場合は既存のDOI名データをそれよりも古いデータで上書きしようとしたときに起こります。
メタデータデータベースレコード作成: 元のXMLバッチファイルとログファイルは、メタデータデータベースデポジット工程へ毎日投入され、そこでインデックスが付けられ、検索できるようになります。データベースへのデポジットの成功（前述したように失敗の主な原因はネットワーク/システムエラー）を伝える最終的なXMLログファイルが作成され、これにDOI名デポジット工程のログファイルを結合したものをXMLバッチ診断として登録者へ電子メールで送られます。メタデータ収集の全工程はできるだけリアルタイムに近い時間で完了し登録者へ報告することが期待されていますが、現時点では24時間が妥当な目標時間と見られています。ただし、登録者が最初にデポジットを行う際には大量のレガシー素材が存在するため、システム性能を損なわないため、レガシーバッチをデポジットするタイミングを調整する必要があります。
データクエリー: 所定の形式による既知メタデータフィールドからなるバッチファイルを送って、メタデータデータベース（MDDB）に問い合わせ（クエリー）を行うことができます。現在の所定形式は純粋なASCIIテキストを別々の行に配置し、縦棒でフィールドを区切ったものです。バッチインターフェースはデータベースに問い合わせを行い、一致するDOI名（分かる場合）か診断メッセージを返します。バッチクエリーファイルはHTTP POSTによって指定されたHTTPサーバーに送られます。
9.1.5 登録者間のDOI名譲渡
複数の割り当て済みDOI名からなる集合（例えば複数の記事を含む定期刊行物、インプリント、レコード目録等）があるRAから別のRAに譲渡される場合は、当該集合の中にあるDOI名も譲渡されることになります。RAは適切な譲渡手順を開発します。譲渡には販売や営利/非営利目的の交換があります。新たな所有者がRAにまだなっていない場合は、状況に応じて特別な措置を講じる必要があるかもしれません。そのような場合には、必要に応じIDFに相談して指導を受けてください。
譲渡後も個々のDOI名は同じまま残ります。DOI名によって識別される対象は変わりません。これは基本的要件です。DOI名のプレフィックスは変化しません。（プレフィックスに意味はなく、専らDOI名の作成にあたって便宜を図るため登録者に割り当てられるものです。プレフィックスから遡って何かを推測することはできません。）新しい所有者がデータ値（ほとんどの場合はURL値）を修正できるようにするため、管理値は変更されます。譲渡の両当事者にあたる登録者はディレクトリマネージャjeuler@cnri.reston.va.usに電子メールを送って譲渡の許可を得る必要があります。ディレクトリマネージャはこれを受けて、譲渡を効率よく確実に行えるようRAを支援します。
9.1.6 RA間のDOI名譲渡
登録機関協調に関するIDF方針によると、顧客は必要に応じて複数のRAのサービスを利用できることになっています。ただしRAのサービスは様々で、顧客が移動する場合、顧客が必ずしも同じサービスを利用できるとは限らないので注意してください。
譲渡にあたっての最大の技術的課題はプレフィックスとローカルHandleサービスとの1対1の関係です。基本的制約として全てのDOI名は所与のプレフィックスのもとで同じHandleサービスに存在しなければならないため、RAは各顧客につき少なくとも1つのプレフィックスを割り当て、必要に応じて複数のプレフィックスを割り当てなければなりません（この一般的構造は分散サービスのための論理的で効率的なアプローチであり、決してHandleシステムに特有のものではありません）。
ある1つのサービスから別のサービスへ1プレフィックス分のDOI名を移すことは簡単です。同じHandleサービスを使用する2つの管理団体（別々のプレフィックスを発行することによって分割を見通せなかった場合）でプレフィックスの管理を分離することも可能ですが、手間がかかります。一般的には2つの解決策があります。（1）一方または他方のサービス（またはIDFに代わってCNRIによって運営されるDOIデフォルトHandleサービス）にプレフィックスを残し、管理を分割し、一方のサービスの管理者が「外部」アドミンアクセスを許す。（2）古いプレフィックスのもとにある全てのDOI名を新しいRAによって管理される新しいプレフィックスのもとにあるDOI名にエイリアスする。新しいDOI名への解決を保証すればよく、古いDOI名を維持する必要はありません。
上記は専らDOIシステムの観点に立つもので、Handle管理に取り組むRAが提供する付加価値サービスや内部ワークフローの問題に対処するものではありません。これらはRAの問題です。
9.1.7 DOIシステム®エラーメッセージ
解決を試みて成功しないとエラーメッセージが現れます。エラーメッセージはRAから提供されるか、DOIシステムから一元的に提供されます。ほとんどのエラーレポートはRAへ行くことが見込まれます。下記は典型的なエラーメッセージです。RAも自身のサービスで似たような文言と手順を使用できます。
システム内にないDOI名を解決しようとすると「DOI Name Not Found（DOI名は見つかりません）」というエラーページがユーザーへ返されます。このページはユーザーをDOIヘルプアドレス（doi-help@doi.org.）に誘導します。問題がHandleシステムに関わるものなら、CNRIが送信元に応答します。DOI名が見つからない場合は、下記文面を含む応答ページによってエラーメッセージの受信確認が行われます。
「このDOIはDOIシステムで見つかりません。考えられる原因は次の通りです。
ユーザーをさらに支援するため、エラー対応システムは、ユーザーがDOIプレフィックスのみの解決を試みたかどうかをチェックします。DOIに複数のスラッシュが入っているか、末尾にスラッシュが付いているかどうかもチェックします。これらはエラーの原因になります。エラー対応システムはこれらのチェックの結果に基づいてユーザーに相応の応答ページを提示し、助言を与えます。
CNRIは送信元のメッセージをRAに転送します。RAはしかるべき処置を講じ、講じた処置を送信元とCNRIに（doi-help@doi.orgアドレスのccで）伝えます。サーブレットを使って該当するRAへエラーをリダイレクトする場合もあります。
Handleシステム®は CNRIによって開発されたデジタルオブジェクトアーキテクチャの1構成要素です。デジタルオブジェクト（「DO」）や他のネットワークリソースを一意に識別し、Handleと呼ばれる識別子を使ってデジタルオブジェクトに関する状態情報を含むレコードを保存し、検索するための手段を提供します。識別子を継続的に管理する管理機構も提供します。DOIシステムはHandleシステムを使用し、Handleシステムの基礎的方針・手順を継承しています。IDFはローカルHandleシステムソフトウェアの著作権、米国特許第6,135,646号、HandleシステムおよびグローバルHandleレジストリ®の商標、Handleシステム技術に関するノウハウを含む、技術やソフトウェアの権利をCNRIから許諾されており、CNRIとのHandleシステム技術商用許諾契約に基づきHandleシステム技術の限定権利をサブライセンスする権限を与えられています。
CNRIは、Handle解決サービスの提供のため、Handleシステム技術を、具体的にはHANDLE.NET®ソフトウェアを、原価回収ベースで組織や個人に提供しています。これは、Handleシステム運営全般を支援しながらシステムを健全な状態に維持する形で行われています。Handleシステム技術を用いて解決サービスを提供することを望むRAをはじめとする個人や組織はローカルHandleサービス（LHS）管理者として登録し、CNRIと契約を結ばなければなりません。ほとんどの場合、この手続きはインターネット上で済ますことができます。
9.2.1 ローカルHandleサービス（LHS)の運営に関する要件
Handleシステム全体を健全な状態に維持するには、認可された期間中に解決サービスを運営することに同意するLHS管理者によって下記条件が満たされるよう徹底しなければなりません。以下で使用される用語「システム」は、LHS管理者によって運営されるLHSの構成要素と、当該構成要素とグローバルHandleレジストリ（GHR）ならびにLHSユーザーとの相互作用を指します。LHS管理者の運営目標には次のものがあります。
9.2.2 解決サービス提供者の要件
解決サービス提供者には、自身のDOIプレフィックスとDOI名を確実に保守するにあたって必要な措置を講じる責任があります。これには下記事項が含まれます。
性能、セキュリティ、運営を含む互換性テストスイートへの準拠のための要件も導入される場合があります。
9.2.3 Handleシステムクライアントソフトウェアの開発
Handleシステムクライアントコンポーネントを開発する組織または個人には、CNRIの クライアントソフトウェアとこれに付属する標準インターフェースの使用が奨励されます。特に、HandleシステムクライアントソフトウェアやGHRとのやり取りにあたってローカルHandleサービスや他のクライアントアプリケーションの正常動作を妨げることがあってはなりません。独自のインターフェースソフトウェアの使用を望む組織または個人は、使用するインターフェースが最新のHandleシステムインターフェース仕様に適合するよう徹底しなければなりません。Handleシステムインターフェース仕様はHandleシステムのウェブサイトに掲載されていますが、時間の経過にともない進化する可能性があります。
カーネルや他のスキーマへの用語の追加を求めるRAは、第4章：データモデル、第4.3.3節に記載されたDOIメタデータスキーマ管理手順に従ってください。
追加の（非カーネル）メタデータ用語やスキーマのマッピングを開発することを望むRAにも上記と同じ手順に従うことが強く推奨されます。こうすることでDOIデータディクショナリへの追加にあたって一貫性を確保できます。用語はIDF活動の一環としてVMFにも追加されます。VMFで用語を登録したり他の用語へマッピングする技術的手順は同じですが、RAはVMF新規用語登録手順に記載された手順に従う必要はありませんし、そこに記載された料金を支払う必要はありません。
新しい制度や新しいメタデータ応用の開発を望むRAにも、全ての会員が無料で利用できるIDFのメタデータコンサルタントを活用することが推奨されます。
|
®、DOI®、 DOI.ORG®及びshortDOI®は国際DOI®財団 (IDF)の登録商標です。 |