永続的なユニフォーム リソース ロケータ

永続的なユニフォーム リソース ロケータ( PURL )は、要求されたWeb リソースの場所にリダイレクトするために使用されるユニフォーム リソース ロケータ(URL) (つまり、場所ベースのユニフォーム リソース識別子または URI)です。PURL は、 HTTP ステータス コードを使用してHTTPクライアントをリダイレクトします。

もともと、PURL は、purl.org または を含む他のホスト名でホストされていることで認識されていましたpurl。初期の頃は、他のホストの多くは、オリジナルの OCLC PURL システム ソフトウェアの派生を使用していました。しかし、最終的にPURL の概念は一般的なものとなり、次のようなリダイレクト サービス ( PURL リゾルバと呼ばれる) を指すようになりました。^[1]

• リゾルバ参照として「ルート URL」を持ちます(例http://myPurlResolver.example)。
• ユーザーコミュニティに、ルート URL に新しい名前をhttp://myPurlResolver.example/name22含める手段を提供します (例)。
• 各名前をその URL (リダイレクト先) に関連付け、このリダイレクト URL を更新する手段を提供します。
• ルート URL とPURL リゾルバサービスの永続性 (たとえば、契約による) を確保します。

PURL は URL 解決プロセスをキュレートするために使用され、 HTTP のようなロケーション ベースのURI スキームにおける一時的な URI の問題を解決します。技術的には、PURL の文字列解決はSEF URL解決に似ています。この記事の残りの部分は、 OCLC (Online Computer Library Center) によって提案および実装された OCLC の PURL システムについて説明しています。

PURLのコンセプトは、1995年にOCLCのStuart WeibelとErik Julによって開発されました^{。[2] PURLシステムは、} Apache HTTP Serverの1.0より前のリリースから分岐して実装されました。このソフトウェアは、OCLCとの契約に基づいてZepheiraによって2007年に近代化および拡張され、公式ウェブサイトはhttp://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 ライセンスの下でリリースしました (http://opensource.org/licenses/oclc2)。Zepheira は、2007 年に Apache License バージョン 2.0 の下で PURLz 1.0 をリリースしました。PURLz 2.0 は2010 年にベータ テストでリリースされましたが、リリースは確定しませんでした。Callimachus プロジェクトは、2012 年の 1.0 リリースで PURL を実装しました。

最も古い PURL HTTPリゾルバは1995 年から 2016 年 9 月までOCLCによって運用され、、、purl.oclc.orgおよび にもアクセスされました。 purl.orgpurl.netpurl.com

その他の注目すべき PURL リゾルバには、連邦寄託図書館プログラムのために運営され、1997 年から運用されている 米国政府印刷局 (http://purl.fdlp.gov) があります。

PURL コンセプトは w3id.org で使用されており、古い PURL サービスと PURL テクノロジーを置き換える可能性があります。

2016年9月27日、OCLCはインターネットアーカイブとの協力を発表し、その結果、リゾルバサービスとその管理インターフェースがインターネットアーカイブに移管されました。^[3]このサービスは、以前のすべての実装とは別に、新しく作成されたソフトウェアでサポートされています。この移管により、数か月間OCLCがホストするサービスで無効になっていたPURL定義を管理する機能が再度有効になりました。インターネットアーカイブサーバーでホストされているサービスはpurl.org、、、、およびを介したアクセスをサポートしています。OCLCは現在、のDNS要求をにリダイレクトします。 purl.netpurl.infopurl.compurl.oclc.orgpurl.org

PURL コンセプトにより、World Wide Web上の HTTP URI の URL キュレーションを一般化できます。PURL により、URL 解決とリソース メタデータの提供の両方をサード パーティが制御できるようになります。

URL は、World Wide Web 上のリソースのアドレスにすぎません。永続 URL は、別の Web リソースへのリダイレクトを引き起こす World Wide Web 上のアドレスです。Web リソースの場所 (つまり URL) が変更されると、そのリソースを指す PURL を更新できます。PURL のユーザーは、問題のリソースが移動した場合でも、常に同じ Web アドレスを使用します。PURL は、発行者が独自の情報空間を管理するために、または Web ユーザーが自分の情報空間を管理するために使用できます。PURL サービスは、情報の発行者からは独立しています。したがって、PURL サービスを使用すると、ハイパーリンクの整合性を管理できます。ハイパーリンクの整合性は、World Wide Web の設計上のトレードオフですが、リソース ユーザーまたはサード パーティが URL が解決される場所と方法に影響を与えることを許可することで、部分的に復元できます。

単純な PURL は、HTTP GET 要求に応答して、タイプ 302 (HTTP ステータス コード 302 に相当、つまり「見つかりました」) の応答を返すことによって機能します。応答には HTTP「Location」ヘッダーが含まれており、その値はクライアントが新しい HTTP GET 要求を介して後で取得する必要がある URL です。

PURL は、仮想リソースの永続的な識別子の 1 つの形式を実装します。その他の永続的な識別子スキームには、デジタル オブジェクト識別子(DOI)、ライフ サイエンス識別子(LSID)、INFO URIなどがあります。すべての永続的な識別スキームは、(変化する可能性のある) 仮想リソースに一意の識別子を提供しますが、すべてのスキームがキュレーションの機会を提供するわけではありません。仮想リソースのキュレーションは、「将来の使用のためにデジタル データの保存を含む管理に情報専門家が積極的に関与すること」と定義されています。^[4]

PURL は URL を解決する必要があるため、ネットワーク ロケーションに PURL が結び付けられるという批判を受けてきました。ネットワーク ロケーションには、ドメイン ネーム システム登録やホスト依存性など、いくつかの脆弱性があります。PURL を解決できない場合、あいまいな状態になる可能性があります。PURL が解決できなかったのは、ネットワーク障害によって解決できなかったのか、それとも PURL が存在しなかったのかが明確ではありません。^[5]

PURL 自体は有効な URL なので、そのコンポーネントは URL 仕様にマッピングする必要があります。スキーム部分は、Web ブラウザなどのコンピュータ プログラムに、アドレスを解決するときに使用するプロトコルを指示します。PURL に使用されるスキームは通常 HTTP です。ホスト部分は、接続する PURL サーバーを指示します。次の部分である PURL ドメインは、URL のリソース パスに似ています。ドメインは、PURL を分離し、PURL に異なる管理者を割り当てることができる階層的な情報空間です。各 PURL ドメインは、1 人以上の指定された管理者によって管理されます。最後に、PURL 名は PURL 自体の名前です。ドメインと名前は、一緒に PURL の「ID」を構成します。

パーマリンクとPURL はどちらも永続的な URL として使用され、要求されたWeb リソースの場所にリダイレクトします。大まかに言えば、それらは同じです。違いはドメイン名と時間スケールに関するものです。

• パーマリンクは通常、URL のドメインを変更せず、何年も存続するように設計されています。
• PURLドメイン名は独立して変更可能であり、数十年にわたって存続するように設計されています。

最も一般的なタイプの PURL は、返される HTTP 応答コードと一致するように名前が付けられています。すべての HTTP 応答コードに同等の PURL タイプがあるわけではなく、すべての PURL サーバーがすべての PURL タイプを実装しているわけではありません。一部の HTTP 応答コード (例: 401、Unauthorized) は、HTTP 会話のコンテキストでは明確な意味を持ちますが、HTTP リダイレクトのプロセスには適用されません。その他の 3 つのタイプの PURL (「チェーン」、「部分的」、および「クローン」) には、機能に関連したニーモニック名が付けられています。

ほとんどの PURL は、いわゆる「シンプル PURL」で、目的のリソースへのリダイレクトを提供します。シンプル PURL の HTTP ステータス コード (つまり PURL タイプ) は 302 です。302 PURL の目的は、Web クライアントとエンド ユーザーに、要求されたリソースのアドレス指定には、解決された最終 URI ではなく、常に PURL を使用する必要があることを通知することです。これは、PURL が変更された場合でも、リソースの解決を継続できるようにするためです。一部のオペレーターは、タイプ 301 (将来の要求で最終 URI をアドレス指定する必要があることを示す) の PURL を使用することを好みます。

「チェーン」タイプの PURL を使用すると、301 または 302 リダイレクトと同じ方法で PURL を別の PURL にリダイレクトできますが、PURL サーバーがリダイレクトを内部的に処理して効率性を高めるという違いがあります。この効率性は、多数のリダイレクトが可能な場合に便利です。一部の Web ブラウザーは、設定された制限に達すると (ループを回避するために) リダイレクトの追跡を停止するためです。

タイプ「200」の PURL は「アクティブ PURL」であり、返されるメタデータの作成または集約に PURL が積極的に参加します。アクティブ PURL には、出力を生成するための任意の計算が含まれます。アクティブ PURL は、PURLz 2.0 および Callimachus プロジェクトで実装されています。これらは、実行時のステータス レポートの収集、分散クエリの実行、または永続的な識別子が必要なその他のタイプのデータ収集に使用できます。アクティブ PURL は、リレーショナル データベースのストアド プロシージャと同様に動作します。^[6]

タイプ「303」の PURL は、Web クライアントを、要求されたリソースに関する追加情報を提供するリソースに誘導するために使用されます。リソース自体は返されません。この微妙な違いは、要求された HTTP URI が、情報リソースとして表すことができない物理的または概念的なオブジェクトの識別子として使用されている場合に便利です。タイプ 303 の PURL は、リソース記述フレームワーク(RDF) のシリアル化形式のメタデータにリダイレクトするために最もよく使用され、セマンティック Webおよびリンクされたデータコンテンツに関連しています。この 303 HTTP ステータス コードの使用は、 World Wide Web Consortiumの技術アーキテクチャ グループの http-range-14 の調査結果に準拠しています。

タイプ「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://example.com/another/path/ である、URL が http//purl.org/some/path/ の PURL について考えてみましょう。URL http//purl.org/some/path/and/some/more/data に対して HTTP GET 操作を実行しようとすると、http://example.com/another/path/and/some/more/data に部分リダイレクトされます。部分リダイレクトの概念により、Web ベースのリソースの階層を PURL 経由でアドレス指定でき、各リソースに独自の PURL は必要ありません。1 つのターゲット サーバー上の階層の最上位ノードとして機能するには、1 つの PURL で十分です。新しい PURL サービスでは、部分的なリダイレクトを実行する PURL を示すために「partial」タイプを使用します。

URLパスレベルでの部分的なリダイレクトは、HTTP 1.1仕様の一般的な解釈に違反しません。ただし、リダイレクト間のURLフラグメントの処理は標準化されておらず、コンセンサスはまだ得られていません。フラグメント識別子は、リソース内のより具体的な情報へのポインタを示し、URIの#区切り文字の後に指定されます。^[7]

フラグメント識別子が存在する場合の部分的なリダイレクトは、2 つの矛盾する解釈が可能なため問題があります。^[8]フラグメントが「部分的」タイプの PURL に添付されている場合、PURL サービスがフラグメントがターゲット URL 上で意味を持つと想定するべきか、または場所が変更されたリソースはコンテンツも変更されている可能性があるという推定に基づいてフラグメントを破棄し、以前に定義されたフラグメントを無効にするべきかは不明です。Bos は、指定されたターゲット URL にフラグメント識別子がすでに含まれていない限り、フラグメントを保持して HTTP リダイレクト中にターゲット URL に渡し、300 (複数選択)、301 (永久に移動)、302 (見つかった)、または 303 (その他を参照) の応答を返すことを提案しました。フラグメント識別子がターゲット URL にすでに存在する場合、元の URL のフラグメントは破棄する必要があります。Bos の提案は IETF の標準化トラックをナビゲートできず、それ以上作業が行われずに期限切れになりました。Dubostらは、 W3C ノート (標準ではなく、標準がない場合のガイダンス) で Bos の提案を復活させました。^[9] ブラウザなどのWebクライアントのメーカーは「一般的に」^[9] Bosのガイダンスに従わなかった。

PURLz 1.0シリーズ以降、PURLサービスは、^[9]に準拠し、ブラウザベンダーによる問題のある一貫性のない動作を回避するために、フラグメントをターゲットURLに書き込むことでフラグメント識別子を含む部分的なリダイレクトを実装しています。

• 実装例:
  • アーカイブ リソース キー(ARK)
  • デジタルオブジェクト識別子(DOI)
  • システム識別子を処理する
• リンクの腐敗
• OPAC
• パーマリンク
• URLリダイレクト
• URL短縮
• ユニフォーム リソース名(URN)
• ウェイバックマシン

• PURLzの公式ウェブサイト
• カリマコスプロジェクトの公式ウェブサイト
• インターネット アーカイブの PURL リゾルバ
• 米国政府印刷局の PURL リゾルバ
• 永続識別子.de
• DPE/PURL 情報およびリゾルバ サイト