Loading article…
永続的な統一リソースロケータ（PURL）は、要求されたWebリソースの場所にリダイレクトするために使用される、場所に基づいた統一リソースロケータ（URL、つまり統一リソース識別子、またはURI）です。PURLはHTTPステータスコードを使用してHTTPクライアントをリダイレクトします。
当初、PURL はpurl.orgまたは を含む他のホスト名でホストされていることで識別できましたpurl。初期の頃、それらの他のホストの多くは、オリジナルの OCLC PURL システム ソフトウェアの子孫を使用していました。しかし、最終的にはPURL の概念は汎用的になり、次のようなリダイレクト サービス ( PURL リゾルバと呼ばれる) を指定するために使用されるようになりました。[ 1 ]
http://myPurlResolver.example：）。http://myPurlResolver.example/name22を含める手段を提供します (例);PURLはURL解決プロセスを管理するために使用され、HTTPのような位置情報に基づくURIスキームにおける一時的なURIの問題を解決します。技術的には、 PURLの文字列解決はSEF URL解決に似ています。この記事の残りの部分では、 OCLC（オンラインコンピュータライブラリーセンター）が提案および実装したOCLCのPURLシステムについて説明します。
PURL の概念は、1995 年にOCLCの Stuart Weibel と Erik Jul によって開発されました。 [ 2 ] PURL システムは、Apache HTTP Serverの 1.0 リリース以前のフォーク版を使用して実装されました。このソフトウェアは、2007 年にOCLC との契約に基づきZepheiraによって近代化および拡張され、公式 Web サイトはpurlz.org(「Z」は Zepheira の名前から取られ、PURLオープンソース ソフトウェアサイトと OCLC が運営する PURL リゾルバを区別するために使用されました) に移転しました。
PURL のバージョン番号は紛らわしいと思われるかもしれません。OCLC は、Apache ベースのソースツリーのバージョン 1 と 2 を、最初は 1999 年に OCLC Research Public License 1.0 ライセンスの下で、後に OCLC Research Public License 2.0 ライセンスの下でリリースしました。[ 3 ] Zepheira は、2007 年にApache Licenseバージョン 2.0 の下で PURLz 1.0 をリリースしました。[ 4 ] PURLz 2.0 は 2010 年にベータ テストでリリースされましたが、リリースは最終化されませんでした。Callimachusプロジェクトは、 2012 年に 1.0 をリリースした時点で PURL を実装しました。
最も古い PURL HTTPリゾルバは1995 年から 2016 年 9 月までOCLCによって運用され、 、、 、purl.oclc.orgとしてアクセスできました。purl.orgpurl.netpurl.com
その他の注目すべきPURLリゾルバーとしては、米国政府印刷局（US Government Printing Office purl.fdlp.gov）があり、これは連邦寄託図書館プログラムのために運営されており、1997年から運用されています。
PURL の概念はw3id.org、従来の PURL サービスや PURL テクノロジーに取って代わる可能性のある で使用されています。
2016 年 9 月 27 日、OCLC はInternet Archiveとの協力を発表し、その結果、リゾルバ サービスとその管理インターフェースが Internet Archive に移管されました。[ 5 ]このサービスは、以前のすべての実装とは別に、新たに作成されたソフトウェアでサポートされています。この移管により、OCLC がホストするサービスで数か月間無効になっていた PURL 定義の管理機能が再び有効になりました。Internet Archive サーバーでホストされているサービスはpurl.org、、、、、を介してアクセスをサポートしています。OCLC は現在、DNS リクエストを にリダイレクトしています。purl.netpurl.infopurl.compurl.oclc.orgpurl.org
PURLの概念は、ワールドワイドウェブ上のHTTP URIの汎用的なURLキュレーションを可能にする。PURLを使用することで、サードパーティはURL解決とリソースメタデータ提供の両方を制御できる。
URLとは、ワールドワイドウェブ上のリソースのアドレスのことです。パーシステントURL（PURL）とは、ワールドワイドウェブ上のアドレスで、別のWebリソースへのリダイレクトを引き起こすものです。Webリソースの場所（つまりURL）が変更された場合、それを指すPURLを更新できます。PURLの利用者は、対象のリソースが移動した場合でも、常に同じWebアドレスを使用します。PURLは、情報発行者が自身の情報空間を管理するため、またはWeb利用者が自身の情報空間を管理するために使用できます。PURLサービスは、情報の発行者とは独立しています。したがって、PURLサービスはハイパーリンクの整合性の管理を可能にします。ハイパーリンクの整合性はワールドワイドウェブの設計上のトレードオフですが、リソース利用者や第三者がURLの解決場所や解決方法に影響を与えることを許可することで、部分的に回復できます。
シンプルなPURLは、HTTP GETリクエストに対してタイプ302（HTTPステータスコード302、つまり「Found」に相当）のレスポンスを返すことで機能します。このレスポンスにはHTTP Locationヘッダーが含まれており、その値はクライアントが後続のHTTP GETリクエストで取得するURLです。
PURLは、仮想リソースの永続識別子の1つの形式を実装しています。他の永続識別子スキームには、デジタルオブジェクト識別子（DOI）、ライフサイエンス識別子（LSID）、INFO URIなどがあります。すべての永続識別スキームは、（変更される可能性のある）仮想リソースに一意の識別子を提供しますが、すべてのスキームがキュレーションの機会を提供するわけではありません。仮想リソースのキュレーションは、「将来の使用のためにデジタルデータを保存することを含め、管理に情報専門家が積極的に関与すること」と定義されています。[ 6 ]
PURLはURLを解決する必要があるため、ネットワーク上の場所に紐づいてしまうという点で批判されてきた。ネットワーク上の場所には、ドメインネームシステム登録やホスト依存性など、いくつかの脆弱性がある。PURLの解決に失敗すると、曖昧な状態になる可能性がある。ネットワーク障害によって解決できなかったのか、それともPURLが存在しなかったのかが明確にならない。[ 7 ]
PURL 自体が有効な URL であるため、その構成要素は URL 仕様にマッピングされる必要があります。スキーム部分は、Web ブラウザなどのコンピュータ プログラムに、アドレスを解決する際に使用するプロトコルを指示します。PURL に使用されるスキームは、一般的に HTTP です。ホスト部分は、接続する PURL サーバーを指定します。次の部分である PURL ドメインは、URL のリソース パスに相当します。ドメインは、PURL を分離し、PURL に異なるメンテナーを設定できるようにする階層的な情報空間です。各 PURL ドメインは、1 つ以上の指定されたメンテナーによって管理される場合があります。最後に、PURL 名は PURL 自体の名前です。ドメインと名前を合わせて、PURL のIDを構成します。
パーマリンクとPURLはどちらも永続的なURLとして使用され、要求されたWebリソースの場所にリダイレクトします。大まかに言えば、両者は同じです。違いはドメイン名と時間軸にあります。
最も一般的なPURLの種類は、返されるHTTPレスポンスコードに合わせて命名されています。すべてのHTTPレスポンスコードに対応するPURLの種類があるわけではなく、すべてのPURLサーバーがすべてのPURLの種類を実装しているわけでもありません。一部のHTTPレスポンスコード（例：401、unauthorized）はHTTP通信のコンテキストでは明確な意味を持ちますが、HTTPリダイレクトのプロセスには適用されません。さらに3種類のPURL（chain、partial、clone）には、その機能に関連した覚えやすい名前が付けられています。
ほとんどのPURLは、いわゆるシンプルPURLであり、目的のリソースへのリダイレクトを提供します。シンプルPURLのHTTPステータスコード、つまりPURLタイプは302です。302 PURLの目的は、Webクライアントとエンドユーザーに対し、要求されたリソースにアクセスするには、解決された最終URIではなく、常にPURLを使用する必要があることを通知することです。これは、PURLが変更された場合でも、リソースの解決を継続できるようにするためです。一部のオペレーターは、301タイプのPURL（今後のリクエストでは最終URIにアクセスする必要があることを示す）を使用することを好みます。
チェーン型のPURLを使用すると、301リダイレクトや302リダイレクトと同様の方法で、PURLから別のPURLにリダイレクトできます。ただし、PURLサーバーが内部でリダイレクトを処理するため、効率が向上します。この効率性は、リダイレクトが多数発生する可能性がある場合に特に役立ちます。なぜなら、一部のWebブラウザは、設定された制限に達すると（ループを回避するために）リダイレクトの追跡を停止するからです。
タイプ 200 の PURL はアクティブ PURLであり、返されるメタデータの作成または集約に PURL が積極的に関与します。アクティブ PURL は、出力を生成するために任意の計算を含みます。アクティブ PURL は PURLz 2.0 および The Callimachus Projectで実装されています。これらは、実行時ステータス レポートの収集、分散クエリの実行、または永続的な識別子が必要なその他のタイプのデータ収集に使用できます。アクティブ PURL は、リレーショナル データベースのストアド プロシージャに似た動作をします。 [ 8 ]
303 型の PURL は、Web クライアントを、要求したリソースに関する追加情報を提供するリソースに誘導するために使用されますが、リソース自体は返されません。この微妙な点は、要求された HTTP URI が、情報リソースとして表現できない物理的または概念的なオブジェクトの識別子として使用される場合に便利です。303 型の PURL は、リソース記述フレームワーク(RDF) のシリアル化形式のメタデータにリダイレクトするために最もよく使用され、セマンティック Webやリンクされたデータコンテンツに関連しています。この 303 HTTP ステータス コードの使用は、ワールド ワイド ウェブ コンソーシアムの技術アーキテクチャ グループの http-range-14 の発見に準拠しています。[ 9 ]
307タイプのPURLは、リソースが一時的に通常とは異なるURLに存在することをユーザーに通知します。404および410タイプのPURLは、要求されたリソースが見つからなかったことを示し、その理由に関する情報を提供します。HTTP 307（一時リダイレクト）、404（見つかりません）、および410（アクセス不可）のレスポンスコードのサポートは、完全性のために提供されています。
404番と410番のPURLは、管理者が修復が必要なPURLをマークする際に役立ちます。これらのタイプのPURLを使用することで、対象リソースが移動し、適切な代替リソースが見つかっていない場合に、リソース識別の失敗をより効率的に示すことができます。
クローンタイプのPURLは、既存のPURLレコードを新しいPURLにコピーする便利な方法として、PURL管理時のみに使用されます。
PURL サービスには、部分リダイレクトと呼ばれる概念が含まれています。リクエストが PURL と完全に一致しない場合、リクエストされた URL がチェックされ、PURL 文字列の連続する先頭部分が登録済みの PURL と一致するかどうかが判断されます。一致する場合は、リクエストされた URL の残りの部分がターゲット URL に追加されてリダイレクトされます。たとえば、URL が で、http://purl.org/some/path/ターゲット URL がの PURL を考えてみましょうhttp://example.com/another/path/。この URL に対して HTTP GET 操作を実行しよhttp://purl.org/some/path/and/some/more/dataうとすると、 への部分リダイレクトが発生しますhttp://example.com/another/path/and/some/more/data。部分リダイレクトの概念により、Web ベースのリソースの階層を、各リソースに独自の PURL を用意することなく、PURL を介してアクセスできるようになります。単一のターゲット サーバー上の階層のトップレベル ノードとして機能するには、1 つの PURL で十分です。新しい PURL サービスでは、部分リダイレクトを実行する PURL を示すために、partial というタイプを使用します。
URL パスレベルでの部分的なリダイレクトは、HTTP 1.1 仕様の一般的な解釈に違反しません。ただし、リダイレクトをまたいだ URL フラグメントの処理は標準化されておらず、まだ合意が得られていません。フラグメント識別子は、リソース内のより具体的な情報へのポインタを示し、URI の区切り文字の後に指定されます#。[ 10 ]
フラグメント識別子が存在する場合の部分リダイレクトは、2 つの矛盾する解釈が可能であるため問題があります。[ 11 ]フラグメントがpartial型の PURL に添付されている場合、PURL サービスは、フラグメントがターゲット URL で意味を持つと想定すべきか、場所が変更されたリソースはコンテンツも変更されている可能性があり、以前に定義されたフラグメントが無効になる可能性があるという前提でフラグメントを破棄すべきかが不明です。Bos は、指定されたターゲット URL にフラグメント識別子が既に含まれていない限り、300 (複数選択)、301 (恒久的に移動)、302 (見つかった)、または 303 (その他を参照) の応答をもたらす HTTP リダイレクト中にフラグメントを保持してターゲット URL に渡すべきだと提案しました。フラグメント識別子がターゲット URL に既に存在する場合は、元の URL のフラグメントはすべて破棄する必要があります。Bos の提案は IETF 標準化トラックを通過できず、それ以上の作業なしに終了しました。Dubostらは、 W3C ノート (標準ではなく、標準がない場合のガイダンス) で Bos の提案を復活させました。[ 12 ] ブラウザなどのウェブクライアントのメーカーは「概して」[ 12 ] Bosの指導に従ってこなかった。
PURLz 1.0 シリーズ以降、PURL サービスは、[ 12 ]に準拠し、ブラウザベンダーによる問題のある一貫性のない動作を回避するために、フラグメント識別子を含む部分リダイレクトをターゲット URL に書き込むことで実装しています。
とインターネットアーカイブは本日、purl.orgの将来的な持続可能性を確保するための1年間にわたる協力の成果を発表しました。両組織は協力して、インターネットアーカイブがホストする新しい持続可能なサービスを構築しました。このサービスは、purl.org、purl.com、purl.info、purl.netの永続URLとサブドメインのリダイレクトを管理します。