DOI Handbook - 解決

この章ではDOI^® システムの解決コンポーネントと、識別子と関連データを永続的に関連付ける解決コンポーネントの能力について説明します。DOI名解決に使われるHandleシステム^®も概説します。

3.1 解決
3.2 単純解決
3.3 マルチプルレゾリューション
3.4 DOIシステムの解決要件
3.5 Handle^® システム技術
      3.5.1 概説
      3.5.2 DOI名解決のための技術的サポート
      3.5.3 DOI名使用のためのソフトウェアサポート
3.6 DOI名「ステートデータ」の保守
3.7 Handleシステムとの解決インターフェース
      3.7.1 カスタム解決ソフトウェア
      3.7.2 ネイティブリゾルバ
      3.7.3 プロキシサーバ
      3.7.4 他のメカニズム
3.8 DOIシステムプロキシサーバーの技術的詳細
      3.8.1 プロキシサーバシステムを用いたDOI解決
      3.8.2 プロキシサーバのクエリーパラメータ
      3.8.3 プロキシサーバ REST API
      3.8.4 追加的機能性
            3.8.4.1 ローカルコンテンツサーバー（「適切なコピー」の問題）
            3.8.4.2 パラメータパッシング
            3.8.4.3 10320/locHandleタイプを用いた複数URLの解決

3.1 解決

解決とは、識別子を入力（リクエスト）としてネットワークサービスへ送り、これと引き換えに特定の存在（エンティティ）に関する1つ以上の最新情報（ステートデータ）を、例えば場所（URL）を、出力として受け取るプロセスです。DOI解決コンポーネントとして使用されるHandleシステムによるマルチプルレゾリューションは、DOIによって特定されたエンティティに関する複数の最新情報（具体的には1つ以上のURLと管理を可能にする既定データ構造）を出力として返します。

基準実装として Handleシステム^®を使用するDOI^®システムの場合は、1つのDOI名を、例えば10.1000/140を、1つ以上の（複数の） 分類されたデータに解決します。例えばオブジェクトのインスタンス（明示）を表すURL、電子メール等のサービス、または1つ以上のメタデータ項目に解決します。新しいタイプをいつでも追加できるDOI解決システムは極めて柔軟性に富み、新たな要求に応じることができます。解決は2つのデータエンティティの関係を維持するメカニズムと考えることができます。1つのメタデータ項目は、何者かが2つのエンティティの間に存在すると主張する関係に相当します。このようなエンティティ間のメタデータ関係は解決によって表現し、自動化することができます。

マルチプルレゾリューションを使用する場合は1つのDOI名をいくつもの異なる値（複数のURL、他のDOI名、メタデータ項目を表す他のデータ型）に解決できます。解決リクエストから最新情報の全ての値が返却されることもあれば、1データ型の全ての値が返却されることもあります。返却された値はその後、特定の「クライアント」ソフトウェアアプリケーションで処理される場合があります。最もシンプルな方法では選択肢のリストがユーザーに提供されます。より洗練された自動処理では適切な値を自動的に選択してさらなる処理が行われます。

3.2 単純解決

DOI名は特定の知的財産物（オブジェクト）を永続的に識別します。このオブジェクトはインターネットでアクセスできるファイルである場合とそうでない場合とがあります。URLはインターネット上に存在する物（エンティティ）のアドレスを提供します。これらは用途がまったく異なるものです。つまり、DOI名はエンティティを識別し、URLは場所を識別します（この場所でエンティティが見つかる場合とそうでない場合とがあります）。

最も初期のDOIアプリケーションシステムは、永続的な識別子を提供するシンプルな単一点解決でした（「404　見つかりません」というメッセージを回避）。それぞれのDOI名は1つのURLを持ち、そのURLまで解決できます。エンティティの場所が変わっても、DOIレコードの中でDOIと対応するURLとのリンクを積極的に管理することによって、エンティティの名前を作動可能な識別子として維持できます。詳細については第5章：アプリケーションを参照してください。URLの永続性の欠如が当初の－最も単純な－課題であり、DOIシステムはこれに対処するよう設計されています。

3.3 マルチプルレゾリューション

マルチプルレゾリューションは1つのエンティティを複数の別のデータやエンティティに解決できます。

DOI名の解決は、関連値への解決、例えば場所（URL）への解決、電子メールアドレスへの解決、別のDOI名への解決、記述的メタデータへの解決を含み、ただしこれらに限定されません。指示対象には様々な種類があり（例えば抽象的な「作品」、物理的な「表明」、パフォーマンス）、デジタルファイル等の形で直接アクセスできるとは限りません。つまり、解決はオブジェクトのインスタンスを返す場合とそうでない場合があります。解決にあたって1つ以上の中間マッピング操作をともなう場合もあります。

DOI解決レコードは、1つ以上のURL（オブジェクトの場所）とDOI名が割り当てられたオブジェクトに関するその他の情報を含むことがあります。場合によっては下記を含むこともありますが、下記に限定されません。

自動化されたマルチプルレゾリューションではDOI名をインターネット上の複数の異なる点（複数のURL、他のDOI名、他のデータ型タイプ）まで解決できます。DOI名が多数の異なる「解決」を指し示す場合はどれを選べばよいかという問題があります。最もシンプルな方法ではユーザーに選択肢のリストが提示され、ユーザーが手作業で選びます。これでは複雑さと自動化が進む環境にとって拡張性のある解決策とは言えません。DOIシステムは「サービスリクエスト」の自動化を可能にします。サービスリクエストの自動化により、ユーザー（ならびに更に重要なユーザーのアプリケーションソフトウェア）をDOI名から所望のサービスへシームレスに誘導することができます。

3.4 DOIシステムの解決要件

ISO 26324はDOIシステムの解決で満たすべき機能的要件（下記）を定めています。

DOI名解決を管理するために使われる技術はa）～l）に記載された機能をサポートしなければなりません。

3.5 Handle^®システム技術

DOIシステムにおける解決任務にはCNRIによって開発され、現在DONA財団が管理運営する、 Handleシステム技術が選ばれました。他の技術を凌ぐ数々の実質的利点（下記）を提供してDOIコンセプトの解決要求を満たすことが選ばれた理由です。

多種データ（種類は拡張可能）への解決はHandleシステム技術の特徴の１つです。Handleシステムに既存の制約はありませんが、DOIシステムはHandleシステムの1アプリケーションであり、既定メタデータ要素や運営方針等、知的財産の取引等でオブジェクトの管理に適した制約を加えます。Handleシステムは、ネットワークで長期間にわたり情報を管理するために考案されたデジタルオブジェクトアーキテクチャの解決コンポーネントです。デジタルオブジェクトアーキテクチャのその他のコンポーネント（リポジトリコンポーネントとレジストリコンポーネント）はDOIシステムの一部を形成するものではありませんが、DOIの実装にあたってこれらのコンポーネントの利用を選ぶこともできます（第5章：アプリケーション、第5.7)章参照）。

HandleシステムはローカルHandleサービスから構成されます。ローカルHandleサービス（LHS）は1つ以上のサイトからなり、各サイトは1つ以上のHandleサーバーからなります。HandleサーバーはHandleを格納します。ローカルHandleサービスの1つ、グローバルHandleレジストリ（Global Handle Registry® ）は特別なローカルHandleサービスです。ここに格納されるHandleは「プレフィックス」Handleです。これをもとにLHSは他のHandleを格納するサービスがどれなのかを知ることができます。DOI名ではHandle構文の一部として割り当てられたプレフィックス10のみを使用します。DOI名は本書で説明するDOIシステムのトータル性によって他のHandleから区別されます。

DOIにおけるHandle運用の詳細についてはファクトシートDOIシステム® とHandleシステム®を参照してください。まｔHandle.netソフトウェアに関するFAQを参照してください。

CNRIは引き続き契約業者としてDOIシステムの技術的サポートと運営面のサポートを提供します。現在の登録機関と今後登録機関になる見込みがある団体は技術サービス関係契約の詳細情報を入手できます。

現在利用されているツールと現在開発中のツールの最新リストについてはDOI Toolsを参照してください。このリストにはツールの説明とソースに至るリンクも記載されています。

CNRIでは一部のユーザーやプログラマに役立つサーブレットやツールを提供しています。（詳細についてはhdladmin@cnri.reston.va.usにてHandleシステムアドミニストレータに問い合わせてください）。サーブレット/ツールには次のものがあります。

ウェブ経由でHandleを管理するためのサーブレット。ローカルウェブサーバーからDOI名を管理する場合に有用。

このパッケージには独自のHandleソフトウェアを操作する場合に役立つHandleクライアントライブラリの用例が入っています。

Handleサーバーのローレベルメンテナンスに役立つユーティリティ。別なやり方で何かを書く前には必ずチェックしてください。

Javaに加えて、Python、Perl、Cでもライブラリを利用できます。また3.8.3に記述のあるプロキシサーバーREST APIを参照して下さい。

3.6 DOI名「ステートデータ」の保守

DOIシステムの効果的運用は、DOI名を適切なURLやその他のデータタイプに正確に解決することにかかっています。

「ステートデータ」の保守はDOI名の登録者が果たさなければならない責務の1つです。ステートデータの保守を許されるのは登録者か登録者の管轄下にあるサービス組織だけです。DOI名レコードの中にあるDOI名ステートデータレコードのアクセスや権限については、より洗練されたモデルを考案することも可能であり、これに関する所要条件は国際DOI財団（IDF）で現在検討中です。

DOI名から解決されるデータタイプはHandleシステムの中で必要なだけ拡張できるため、インターネット上でアクセスできるデータならどんなデータでもDOI名から解決できます。

URLデータ型に使用する場合は（現在最も一般的な用途）、相対的参照ではなく完全パスとしてDOI名データを入力することが推奨されます（例えばhttp://www.somepublisher.com/photo/photo#1.gif）。DOI名データとして相対リンクを使用することもできますが、DOI名が解決される前後関係は予測できません。つまり現在のベースhtmlリファレンスを予測することはできません。

DOI名からJavaアプレット-、CGIスクリプト、他の動的メカニズムに解決することもできます。

3.7 Handleシステムとの解決インターフェース

ブラウザで単純な場所ではなくオブジェクトの名前を扱えるようにするには、現在のウェブブラウザ技術に機能を加える必要があります（ウェブ上でのネーミングアプローチに共通の事実）。つまり、DOI名解決機能を十分に活用するには追加的ブラウザ機能が必要です。将来的には解決をサポートする機能がブラウザに普通に組み込まれるようになると見込まれており、IDFはこれを推進するため積極的に協議を進めています。必要な機能は数通りの形で現在提供されています。

Handle.Net® System Client Library Java™ Versionは自由に利用できこれを使用して、必要に応じ個別のアプリケーションとして、または完全に分離したシステムで使用するため新しい解決クライアントを開発できます。解決は自由に利用できるため、この作業もIDFから完全に切り離して自主的に行うこともできますが、IDFは2つの理由から、すなわち1）アプリケーションが公共的なものである場合に他の人々に当該アプリケーションを知ってもらうため、2）開発者たちとともにDOIシステムの理解を深めて開発者たちの取り組みを成功に導くため、開発者たちに自身のアプリケーションのことをIDFに知らせることを奨励しています。

プロキシサーバーを使わずブラウザで「doi:10.123/456」形式のDOI名を解決できるようにするFireFox向け「リゾルバプラグイン」をCNRIから入手できます。ユーザーがこのプラグインをダウンロードし、インストールし、DOI名を「クリック」するだけで（またはブラウザのアドレス行にDOI名を打ち込むだけで）、DOI名は直接解決されます。 FireFox向けHANDLE拡張を参照してください。

ウェブブラウザの機能を拡張する代わりに、DOIシステムのプロキシサーバー（https://doi.org/（推奨）またはhttps://dx.doi.org）を使用するよう構成されたDOI名を解決することもできます。この場合のDOI名解決はURL構文の使用に左右されます。本書で使われているDOI名の例（doi:10.10.123/456）はアドレス「https://doi.org/10.123/456」から解決されます。この形式をとるDOI名について標準的なブラウザであれば解決可能です。プロキシサービス（doi.org とdx.doi.org）はIPv6でアクセスでき、DNSSECをサポートします。

プロキシサーバー（HandleシステムとHTTPとの間のゲートウェイ）の使用はHTTPリファラフィールドの妨げになりません（つまり、リンクのソースは維持され、ユーザーがソースからではなくdoi.orgまたはdx.doi.orgから来ているようには見えません）。何もそのプロキシサーバーを通過しません。プロキシサーバーはリダイレクトを現在のURLやHandle解決に関わる他の情報と併せて元のクライアントへ送り返し、最終的なHTTP GETリクエストはユーザーのクライアントから来ます。

HTTPプロキシサーバー（URLは「https://doi.org」形式）を通して使用されるDOI名は存続します。（1）コアDOIシステムが維持される限り、つまりHandleシステムを使って所与のDOI名（10.123/456）を解決できる限り、（2）doi.orgという名前のプロキシサーバーが稼働し続ける限り、（3）http方式のウェブを機能させるコアネットワークサービスが存在し続ける限り、そのプロキシを通して参照されるDOI名（https://doi.org/10.123/456）は存続します。その理由を理解するにあたって鍵となるのがモジュール方式です。コアDOI名解決サービスはプロキシによって使用されますが、プロキシの制約は受けません。doi.orgプロキシの継続的運営を妨げとなることなく、追加のゲートウェイを構築し、追加の方法を用いてコアDOI名解決システムにアクセスできます。

プロキシを構築し、その利用を推奨してきたCNRIとIDFは、プロキシを永久に保つことに注力しています。これが何百万ものDOI名方式ウェブリンクを保全するにあたって必要不可欠な要素となるからです。それらのリンクの有用性を長期間にわたって維持するには、コアDOIシステムと、それらのリンクが参照し、コアDOIシステムへのアクセスを得るために使用するゲートウェイサービス（doi.org）を、維持する必要があります。勿論これは何ら特別なことではなく、サービスを重ね合せるインターネットのテーマのバリエーションに過ぎません。doi.org自体はドメイン名システム（DNS）に依存しており、DNS自体はIPアドレシング/ルーティング等に依存しています。コアDOI名解決機能は多数のサービスによって様々な形で使用され、この状況はおそらく時間が経つにつれてより複雑化するでしょう（我々はそうなることを望んでいます）。例えばOpenURLリゾルバは「ありのままの形」のDOI名を、例えばid=doi:10.123/456を、見つけ、doi.orgプロキシを使用するか、独自のウェブ－DOI名プロキシサーバーを準備するか、Handleプロトコルを使ってDOIシステムに直接問い合わせるかを選ぶことができます。

JavaScript等のスクリプト機能を用いてブラウザに必要な機能を提供することもできます。ただし、スクリプト機能は中長期的にブラウザによるサポートを確保できる見込みがないため、長期的DOIシステム戦略には推奨されません。例えば、現在多くのセキュリティ専門家が電子メールシステムの基本設定でJavaScriptをオフにすることをコンピュータユーザーに呼びかけています。

また、DOIがinfo-URI名前空間の中で登録されたURIであることに注意してください（IETF RFC 4452、パブリック名前空間で識別子を有する情報資産のための「info」URI制度）。ファクトシート「DOIシステムとインターネット識別子の仕様」も参照してください。

3.8 DOIシステムプロキシサーバーの技術詳細

ユーザーはDOIシステムのプロキシサーバー（https://doi.org/（推奨）またはhttps://dx.doi.org）を使用するよう構成されたDOI名を解決することもできます。この場合のDOI名解決はURL構文の使用に左右されます。本書で使われているDOI名の例doi:10.10.123/456はアドレス「https://doi.org/10.123/456」から解決されます。この形式をとるDOI名について標準的なブラウザであれば解決可能です。プロキシサービス（doi.org とdx.doi.org）はIPv6でアクセスでき、DNSSECをサポートします。プロキシサーバはHTTPリクエストと同様にHTTPSリクエストにも対応します。

DOIシステムはデジタルオブジェクトを管理するためHandleシステム^®を使用します（DOIファクトシート「DOIシステムとHandleシステム"」参照）。インフラレベルではDOI名はHandleです。

DOIシステムのプロキシサーバーは基本的にはHandleシステムと対話する方法を知っているウェブサーバーであり、本書の執筆時点でウェブ上に見られるDOI^®名のほとんどは、DOI名解決にプロキシサーバーを使用するURLに埋め込まれています。例えば、プロキシのドメイン名とDOI名を組み合わせたHTTPリクエストの場合、

プロキシはHandleシステムにDOI名を問い合わせ、Handleレコードの中にあるURLを取り（Handleレコードの中に複数のURLがある場合は1つのURLを選択。選択は順不同）、そのURLに至るHTTPリダイレクトをユーザーのウェブブラウザに送ります。

1個のデフォルトURLのほかにデータを追加的に含むDOI名が増えています。これはマルチプルレゾリューションと呼ばれることがあります。追加された値は、複数のデータ（例えば改良されたメタデータや関連文書の場所）を活用できるより先進的アプリケーションに使用されます。

URL型のHandle値に加え、プロキシサーバーは10320/loc型のHandle値を理解します。これらの値は、DOI名のための複数のリダイレクトエンドポイントとプロキシがそれらを使用する条件を記述するXMLを含んでいます。詳細については第3.8.4.3節：10320/locHandle型を用いた複数URLの解決を参照してください。

プロキシサーバーは、見つけることのできないDOI名の問い合わせを受けたときに「DOI Name Not Found（DOI名が見つかりません）」というエラーページを表示するよう設定されています。

10.1000/demo_DOIというDOI名と10.1000/demo_DOI/というDOI名はいずれも有効なDOI名ですが、今後スラッシュが後ろに付くDOI名が作られる見込みはありません。後ろにスラッシュが付くDOI名の解決要請（リクエスト）をプロキシサーバーが受け、そのDOI名が見つからない場合、プロキシサーバーは、解決を要請されたDOI名の後ろにスラッシュが付いていることを伝える警告と、クリックするとスラッシュがない同じ文字列を解決できるリンクを含む、エラーレポートを返します。.

DOIシステムのプロキシサーバーは、実際には複数の場所で稼働する複数のサーバーであり、均一に負荷分散されています。解決を加速するため、プロキシサーバーはHandle値をキャッシュします。TTL（有効期限）は24時間に設定されています。これは、Handle値が変更された場合に新しい値が返されるまでに最高24時間かかることを意味します。

尚、IDFは本DOIシステムプロキシサーバー仕様に含まれない shortDOI™ サービスのためのプロキシサーバーも運営しています。

一部の図書館やその他の組織では、DOIシステムプロキシサーバーでローカルサービスを使用し「適切なコピー」へユーザーをリダイレクトさせるため特別なクッキーを使用しています。例えばユーザーは、料金を伝えるランディングページの代わりに、図書館で購入された定期刊行物の記事の全文へリダイレクトされます。ユーザーは「nols=y」クエリーパラメータを加えることでローカルサービスリダイレクトを抑止できます。

DOIシステムのプロキシサーバーREST APIはHTTPを使用しDOI名解決へのプログラム的アクセスを可能にします。

REST API要請（リクエスト）は下記の標準HTTP GETを実行することによって行うことができます。

例えばhttps://doi.org/api/handles/10.1000/1の応答（レスポンス）は次の通りになります。

{
  "responseCode": 1,
  "handle": "10.1000/1",
  "values": [
    {
      "index": 100,
      "type": "HS_ADMIN",
      "data": {
        "format": "admin",
        "value": {
          "handle": "0.NA/10.1000",
          "index": 200,
          "permissions": "011111111111"
        }
      },
      "ttl": 86400,
      "timestamp": "2000-04-13T15:08:57Z"
    },
    {
      "index": 1,
      "type": "URL",
      "data": { "format": "string", "value": "http://www.doi.org/index.html" },
      "ttl": 86400,
      "timestamp": "2004-09-10T19:49:59Z"
    }
  ]
}

応答（レスポンス）は、「responseCode」（Handleプロトコルのレスポンスコードを示す整数）と、解決される「Handle」のエコーと、「値」のリストを含むJSONオブジェクトです。エラーの場合はオプションの「メッセージ」がJSONオブジェクトに含まれます。このメッセージはエラーを記述する文字列です。

それぞれの値は5つの属性を通常有するJSONオブジェクトです。

Handle値データはプロパティとして「format」、文字列、および「value」を有するオブジェクトです。

このDOIシステムプロキシサーバーREST APIはCORS適合ですが、「callback」クエリーパラメータの使用によりJSONPコールバックもサポートされます。

「pretty」クエリーパラメータは、JSON出力をプリティプリントすることをサーバーに指示します。

「auth」クエリーパラメータは、プロキシサーバーがそのキャッシュを迂回し、プライマリHandleサーバーで最新のHandleデータを直接問い合わせるようにします。

「cert」クエリーパラメータは、プロキシサーバーがソースHandleサーバーに認証済みの応答（レスポンス）を要求するようにします。通常、エンドユーザーには不要です。

「type」クエリーパラメータと「index」クエリーパラメータは、解決のレスポンスを特定の型およびインデックスに限定します。複数の「type」パラメータや複数の「index」パラメータを使用できます。この場合は指定された型またはインデックスのいずれかに一致する値が返却されます。

例えばhttps://doi.org/api/handles/10.1000/1?type=URL&callback=processResponseの応答は次の通りになります。

DOIプロキシサーバーを使用するようDOI名を構成するDOIシステムユーザーに追加的サービスを提供するため、DOIシステムプロキシサーバーには追加的機能性が組み込まれています。

学術誌や技術誌に掲載される記事のDOI名は通常、出版者のウェブサイトまで解決されます。それらのウェブサイトから記事を引き出すには、通常ならば料金か購読契約が必要となります。図書館は普通、機関誌のコピーを購入して自身の利用者向けコレクションに保管します。多くの場合は機関誌の複数コピーを所有するか購読契約します。これらの施設の利用者の場合、DOI名から適切に解決されるべきアドレスは、解決を要請している利用者の所属や場所に左右され、適切な選択は通常ならば施設にあるコピー（ローカルコピー）のいずれか1つです。

国際DOI財団、Crossref、CNRI、図書館、ならびに図書館サービス提供業者はこれを「適切なコピーの問題」と呼び、解決策（ソリューション）に向けて共同作業を開始し、1999年にプロトタイプの開発に着手しました。（詳細については2001年9月の D-Libマガジン「適切なコピーへのリンク」.)を参照してください。）

DOI名解決システムとCrossrefメタデータデータベースとOpenURLの組み合わせは、図書館の「適切なコピーの問題」に向けて実用的なソリューションを提供します。このアーキテクチャは主に（1）アイテムに対するクエリーを図書館にある適切なコピーに照合できるローカルコンテンツサーバー、（2）クエリーをローカルコンテンツサーバーへリダイレクトできるDOI名解決システム、（3）クエリーの発信元が解決システムに対し適切なローカルコンテンツサーバーを識別する仕組み、（4）ローカルコンテンツサーバーがクエリーを適切なコピーに照合するにあたって十分なアイテムに関するメタデータのソースからなります。 Crossrefがその図書館会員に提供しているソリューションは次の通りです。会員組織にいるユーザーはDOI名をクリックします。そのDOI名とクッキー（「CookiePusher」メカニズムによりユーザーのウェブブラウザであらかじめ設定）はDOIシステムプロキシサーバーへ送られます。プロキシサーバーはクッキーでローカルコンテンツサーバーを認識し、DOI名を含むOpenURLを構成し、これをユーザーのブラウザへ至るHTTP「リダイレクト」によりユーザーのローカルリゾルバへ送ります。ローカルリゾルバはOpenURL形式のDOI名をCrossrefへ送ります。CrossrefはDOI名によって指定されたアイテムのメタデータを返します。ローカルコンテンツサーバーはこれを現地に保管されている記事と認識し、そのアイテムを指し示すURLを構成し、HTTP「リダイレクト」としてユーザーのブラウザへ送ります。

Crossrefがその図書館会員に提供しているソリューションは次の通りです。会員組織にいるユーザーはDOI名をクリックします。そのDOI名とクッキー（「CookiePusher」メカニズムによりユーザーのウェブブラウザであらかじめ設定）はDOIシステムプロキシサーバーへ送られます。プロキシサーバーはクッキーでローカルコンテンツサーバーを認識し、DOI名を含むOpenURLを構成し、これをユーザーのブラウザへ至るHTTP「リダイレクト」によりユーザーのローカルリゾルバへ送ります。ローカルリゾルバはOpenURL形式のDOI名をCrossrefへ送ります。CrossrefはDOI名によって指定されたアイテムのメタデータを返します。ローカルコンテンツサーバーはこれを現地に保管されている記事と認識し、そのアイテムを指し示すURLを構成し、HTTP「リダイレクト」としてユーザーのブラウザへ送ります。

その記事が現地に保管されてない場合、ローカルコンテンツサーバーはリクエストをローカルコピーの不在を知らせるフラグと併せてプロキシサーバーに返します。プロキシサーバーはDOI名を通常通り解決し、ユーザーのブラウザを出版者のサイトへリダイレクトします。

この方法の詳しい説明と図書館がこのローカルリンキングソリューションに参加する方法については、ウェブサイトで「Crossref図書館会員のためのローカルリンキングに関する文書」を参照してください。

現在のソリューションはCrossrefのためのソリューションであり、Crossrefは、本書の執筆時点においては、この問題に関わるほとんどDOI名と関連メタデータのソースとなっています。ただしこの状況はDOIシステムの継続的成長にともない変わりつつあり、将来的には多数のメタデータソースに対応する必要があることが広く認められています。それにはDOI名解決データとローカルコンテンツサーバーの挙動の両方に調整が必要となります。当初の「適切なコピーの問題」を解決するため集まったグループはその必要性を認めており、この件について打ち合わせを行っています。また、状況の進展にともないさらなる協同作業が必要になると予想しています。

「CookiePusher」（詳細についてはD-Libの記事を参照）はユーザーのブラウザでクッキーを設定するためのメカニズムです。このクッキーはプロキシサーバーによって認識され、プロキシサーバーがDOI名解決リクエストをリダイレクトするURLを含んでいます。権限を持たないユーザーがクッキーを設定して自分自身のリゾルバへトラフィックをリダイレクトすることを防ぐため、CookiePusherには、認可済みローカルコンテンツサーバーのURLを含むBASE-URLリストが入っています。BASE-URLはスクリプトやディレクトリのURLであってよく、最上位ドメインであってもかまいませんが、OpenURL認識サーバーでなければなりません。リクエストに含まれるBASE-URLがリストにない場合、スクリプトはクッキーを設定せず、「あなたのクッキーはありません（no cookie for you）」というメッセージを返します。BASE-URLはCrossrefに加入する会員から収集されます。

CookiePusherスクリプトはDOIシステムウェブサイト (http://www.doi.org)で稼動します。プロキシサーバ (https://doi.org (推奨）またはhttps://dx.doi.org) はDOI.ORG^®ドメイン下にあります。CookiePusherスクリプトのURLは次の通りです。

ローカルコンテンツサーバーのURLプレフィックスを含むCookiePusherへのリクエストの例：

URI 16進（%）エンコードが推奨されます。

ユーザーのウェブブラウザのクッキーファイルへクッキーを追加するリクエストは通常、透過GIFを用いて導入/ログインウェブページから見えないようにします。

クッキー設定後、プロキシサーバーはクッキーの中で特定されるローカルコンテンツサーバーを認識し、ローカルコンテンツサーバーのURLとDOI名を含むOpenURLを組み立てます。

そしてHTTP「リダイレクト」によりローカルコンテンツサーバーへリクエストを送信します。

コンテンツのローカルコピーがない場合、ローカルサーバーは「nols=y」フラグを設定してプロキシサーバーへリクエストを返さなければなりません。この場合はプロキシサーバーがDOI名を解決し、出版者のコンテンツへユーザーを誘導します。（プロトタイプで使われていた「nosfx=y」設定は廃止される予定ですが、今なおサポートされています。）無限ループを防ぐため、「ローカルサービスはありません（no local service）」というフラグを正しく設定することが極めて重要です。

学術出版業界はDOIシステムとCrossrefが登場する前に、標準URLに含まれるパラメータ（名前/値ペア）を使ってデータをやり取りする二者間リンク協定を結んでいました。この方法によりサイトに到来するリクエストに関する情報（例えばリクエストの出所にあたる出版者のサイトはどれか、どの定期刊行物/記事を求めているのか）を収集できました。また、特別なアクセスルールを実施したり、コンテンツを要望する者が誰なのかに応じてコンテンツの価格を定めていました。

出版者はDOI名を使い始めた当時、DOI名とDOIシステムのプロキシサーバーを利用してパラメータの交換を促進し、二者間リンク協定を廃止することも検討し始めました。数年がかりで練り上げられた手順が現在Crossefの会員になっている出版者たちの合意に至り、プロキシサーバーに導入され、「パラメータパッシング」と呼ばれるようになりました。

パラメータパッシングには2つのURLが関与します。いずれもクエリー文字列になるか、パラメータを含むことがあります。（1）「参照元」によってDOI名を持つhttps://doi.org/へ送られる解決リクエスト。（2）「指示対象」によってDOIシステムの中で登録された、当該DOI名に対応するURL。パラメータパッシングでは2つのURLのクエリー文字列をまとめて「アウトバウンド」リンクを形成する必要があります。両方の文字列に使われるパラメータの名前は一意で全当事者にとって明確なものにしなければなりません。これらのURLには1組みのパラメータ名を指定するOpenURL形式が選ばれました。これにより名前が重複する可能性を解消できます。

DOIシステムのプロキシサーバーはOpenURL形式の解決リクエストを受け付けます。例：

これはプロキシサーバーによってパラメータパッシングリクエストとして認識されます。これはDOI名を解決し、次にパラメータパッシングに参加する組織を識別する「オプトイン」リストに照らしてURLのドメインをチェックします。

オプトインリストの中にURLがある場合、プロキシサーバーは次のようにして新しいURLを構成します。

オプトインリストで差し替えが指定されている場合は、登録済みURLのドメイン名/ポート番号を別の値に差し替えます。

rft_datパラメータを除くすべてのパラメータをインバウンドリンクからアウトバウンドリンクへ移します。

rft_datパラメータの場合、登録済みURLがOpenURLなら、rft_datパラメータをアウトバウンドリンクへ移します。あらかじめOpenURL形式になっていない場合はURLの中のクエリー文字列全体を16進符号化し、rft_datパラメータの値としてアウトバウンドリンクに入れます。

指示対象は、親子構造パラメータを使用できるサービスを実装済みと仮定されます。この仮定によると、出版者はパラメータパッシングへの参加に同意することより、共通Crossrefパラメータセットの中で特定される全てのパラメータを受け付けます。

OpenURL形式の変更に起因する、またはパラメータパッシング参加者条件の変更に起因する、パラメータの変更は、文書 Crossrefヘルプで説明されています。

DOIシステムプロキシサーバーの、またはウェブブラウザプラグインの、主たる用途の1つは、DOI名(handle) を解決してリソースのURLを得ることです。複数のURL値を持つDOI名の場合、プロキシサーバー（https://doi.orgとhttp://hdl.handle.net）はDOI名解決から返される値のリストで最初のURL値を単純に選択します。このリストの順序は非決定的であるため、クライアントのリダイレクト先にあたるURLを合理的に選択するようにはなっていません。複数のURLを含むDOI名やHandleから特定のリソースURLを選択する方法を改善し、HandleからURLへの解決プロセスに機能を追加するため、10320/locHandle値型が開発されました。

全てのHandleには、すなわち全てのDOI名には、1組みの値が割り当てられ、それぞれの値には、データの構文や意味規則を決定づけるタイプがあります。タイプに分類された値には管理のためのものや（所有者、作成日）、クライアント用のものがあります（URL文字列、電子メールアドレス、バイナリデータ等の複雑なデータ型、XMLコード、他のHandle）。ユーザーがユーザーコミュニティの中で認知されていない未登録のタイプを割り当てた場合のクライアントの衝突を回避するため、タイプには独自のHandleが割り当てられています。これによりHandleシステムの中でタイプを定義し登録することができるようになります。

ユーザーがユーザーコミュニティの中で認知されていない未登録のタイプを割り当てた場合のクライアントの衝突を回避するため、タイプには独自のHandleが割り当てられています。これによりHandleシステムの中でタイプを定義し登録することができるようになります。この手順は現在開発過程にあります。プレフィックス「10320」（5桁からなる任意の文字列）は、Handleの種類を識別するための手段としてHandleシステムアドミニストレータによって押えられています。10320/locタイプのサフィックス「loc」は場所（location）の省略形です。

10320/locタイプは場所のリストを含むXML形式Handle値を指定します。それぞれの場所には1組みの属性があります。これらの属性は、場所が使われたか否か、使われたのであればいつ使われたのかを判断するのに役立ちます。場所のリストは、解決するクライアントが場所をどのように選択するべきかについてのヒント（順序付けされた一連の選択方法等）を含むことがあります。プロキシサーバー（または他の解決クライアント）は、それぞれの選択方法を順次適用しながら、リゾルバのコンテクスト（プロキシサーバーの場合はHTTPリクエスト）と各場所の属性に基づいて場所を選択できます。

将来的に後方互換性のある形で機能を追加できるようにするため、複数の場所からなる組の属性と組の中の各場所項目に制限はありません。少数の属性は全てのリゾルバが理解する「標準」として規定されています。

XML構造の最上位には以下に記す属性が規定されています。

それぞれの場所に以下に記す属性が規定されています。

無作為選択を行う場合にこの場所に適用される重み（ゼロから1）。a）場所が別の属性によって明示的に参照される場合、b）ほかに適当な場所がない場合、c）国や言語等、他の選択方法のいずれか1つに基づき場所が選択される場合を除き、weight属性をゼロに設定すると場所は選択されません。weight属性を持たない場所は重み1を持つと想定されます。

現時点で規定されている選択方法は次の通りです。

クライアントの国に一致する「country」属性を持つ場所を選択します。一致する場所が見つからない場合は、country属性を持たない場所を選択します（ミスマッチではありません）。プロキシhttp://hdl.handle.netおよびhttps://doi.orgは GeoIPルックアップを使ってクライアントの国を判断します。

無作為選択に基づいて1つの場所を選択します。プロキシは各場所の「weight」属性（浮動小数点非負数）を順守します。重み付けによってごく基礎的な負荷均等化（ロードバランシング）が可能になります。いくつかの場所だけを直接アドレスする手段にもなります（例えばcountryまたはlocatt/属性）。正以外の重みを持つ場所に重み付け選択方法が適用される場合は、場所の重みは無視して残りの場所の中から1つの場所を無作為に選択します。

プロキシは1つの場所が選択されるまで選択方法を順次繰り返します。繰り返しのたびに以下に記す4つの手順のいずれか1つを実行します。

残っている場所要素がただ1つの場合は、それがリダイレクトとして返されます。
場所要素が残っていない場合、プロキシは場所要素を最後の方法が適用される前の状態に戻します。
複数の場所要素がある場合、プロキシはそれらの場所に残りの選択方法を適用します。
試すべき選択方法がそれ以上ない場合は、1つの場所が返されることが保証される重み付け無作為選択方法が適用されます。ある意味、重み付け無作為法は常に「最後のよりどころ」です。

以下に示す場所属性のリストを持つ値のタイプが10320/locであるDOI名10.123/456の参照の場合

以下に記す選択を行えます。

参照: UKにあるクライアントから10.123/456
結果:「country」選択方法は、最初の場所の「country」属性とクライアントの位置に基づいて最初の場所を選択します。

参照: UK外にあるクライアントから10.123/456
Result: 「country」選択方法は、その「country」属性に基づいて最初の場所を検討対象から外し、「weighted」無作為選択方法を用いて最後の2つの場所のいずれか一方を選択します。

参照: 10.123/456?locatt=id:1
結果: 「locatt」選択方法と「id」属性に基づいて2番目の場所が使用されます。

参照: 10.123/456?locatt=id:0
結果: 「locatt」選択方法と「id」属性に基づいて1番目の場所が使用されます。「locatt」選択方法でただ1つの一致する場所になるため、リゾルバは「country」選択方法をとりません。

参照: 10.123/456?locatt=country:uk
結果: 「locatt」選択方法と「country」属性に基づいて1番目の場所が使用されます。

参照: 10.123/456?locatt=country:us
結果: 「country」選択方法は、その「country」属性に基づいて最初の場所を検討対象から外し、米国の場所を見つけず、「weighted」無作為選択方法を用いて最後の2つの場所のいずれか一方を選択します。

具体的な使用例 – – Crossref

廃刊となった定期刊行物「Graft: Organ and Cell Transplantation」の記事にはDOI名10.1177/1522162802239753が割り当てられました。このDOI名はこの記事を提供する2つのアーカイブサービスを指示するよう更新されました。

プロキシがリダイレクトに使用できるようにするため、下記情報を含む10320/locタイプがレコードに追加されました。

「chooseby」属性（locatt,country,weighted）はデフォルトセットです。この例で、評価は最初の2つを通過し、プロキシは選択基準として「weighted」を使用します。最初の場所（mr.crossref.org）が重み1で選択されます。プロキシはmr.crossref.orgへリダイレクトします。この例のmr.crossref.orgは、下記形式のDOI名を解決するときにユーザーが見るページを構築するCrossrefサイトのスクリプトです。

https://doi.org/10.1177/1522162802239753

結果的に得られるページは2つのアーカイブサービスで記事をダウンロードできることを伝えます。これらのサービスのいずれか一方から2つのソースを表示するため、id="2"とid="3"の10320/locデータはCrossrefスクリプトによって使用されます。

パラメータとして2つの場所のいずれか一方の属性を指定したリンクを構築する等、様々な設定で一般的なメカニズムを利用できます。この場合、ユーザーは通常通りそこにリダイレクトされ、Crossrefが構築するマルチプルレゾリューションページは表示されません。もともとのURLは、10320/locを理解しない古いプロキシやプラグインの場合に予備として役立ちます。

3 解決