（原文: Persistent Identifiers: Considering the Options, Ariadne, Issue 56 (July 2008)）
永続識別子（Persistent Identifier）とはデジタルオブジェクト、すなわち、e-プリント（記事や論文、報告書）や画像ファイル、ソフトウェアインストールファイルなどをいつまでも参照できるただの識別子である。ここで興味のある永続識別子は同時に永続的に動作可能な（すなわち、「クリック」できる）ものだけである。しかし、永続識別子は単なるハイパーリンクとは異なり、リソースが他のサーバはおろか他の組織に移管されたとしても、リソースへのアクセスを継続的に提供しなければならない。デジタルオブジェクトは、様々な理由で移管、削除、改名される可能性がある。本論文では、永続識別子の現状を調査し、現在提供されているいくつかのサービスについて説明し、その構造と利用の背後にある理論的背景を考察する。また、各自の目的のために何らかの標準の採用を検討しているすべての人に関連すると思われる問題を提起する。
URLは通常、サーバのファイルシステムを使って一種のルックアップデータベースとして実装されている。例えば、http://www.ukoln.ac.uk/index.html は、www.ukoln.ac.uk に応答するマシンの80番ポートで稼動しているWebサーバのルートディレクトリに位置する "index.html" と呼ばれるファイルである。これは手早く立ち上げて稼動させることが極めて簡単だったので、初期の多くのサーバはこの方法でデジタルオブジェクトを参照する傾向にあった。例えば、http://www.ukoln.ac.uk/index.html は、「（ドメイン "www.ukoln.ac.uk" に対してDNSサーバが今現在返すIPアドレスの80番ポートで稼動している）Webサーバに文字列 "index.html" について尋ねると提供されるデジタルオブジェクト」を意味し、これは多くのサーバにとって「ルート位置にある "index.html" という名のファイル」を意味する。確かにこの方法には利点がある。例えば、ファイルシステムとWebサイトの構造が明確に対応しているので、管理者がサイトの構成を理解するのが容易である。しかし、他の仕組みが用意されていないと、誰かがファイルを削除するとリンクが壊れてしまうことになる。簡単に手に入ったものは、簡単に出て行くのである。
この設計方法には脆弱性があることが認識され、URLの実装方法に変化が見られるようになった。もう1つ例を挙げると、多くのWebアプリケーションはURL内の複数の要素に異なる構文を使用している。Webオブジェクトに適用された各技術固有のURL拡張子（.asp, .php4, .jsp）は、通常（Apacheのmod-rewriteなどの）インタープリタによってサーバの内部ファイルシステム構造を隠すような方法でマッピングされる。例えば、あるブログ作成ソフトウェアは簡単な書き換え規則を適用することにより、"http://joansmith.com/2007/11/30" といったセマンティク的に意味のあるURLを Joan Smith が2007年11月30日に書いたブログ記事一覧表へのリクエストであると読むよう設計されている。ソフトウェアを新バージョンに置き換えても、新バージョンでもこのURLを適切に解釈することができると思われるのでこれらのリンクが壊れることはない。
これはサーバ内での識別子の脆弱性を減らすには大いに役立つが、動作可能なすべての識別子はサーバ自体の名称に関係する別の種類の破壊には弱い。例えば、Joanのブログがある話題に関するニュースで非常に有名になった場合、彼女は同じ関心を持つ他人がブログに記事を投稿できるようにするかもしれない。すると、個人サイトから話題中心のサイトへと焦点が変化するので、話題を反映させるためにサイトのホスト名を変更した方がよくなるかもしれない。もう1つ例を挙げると、Webサイトが会社のものである場合、時には会社の買収や合併、商標変更などの商売上の理由でその名前が変更される可能性が非常に高いと思われる。サイトのコンテンツも同様な理由で、あるいはWebベースの公開が我々の生活やマーケティング、個人や企業のイメージに果たす役割に関するその他の理由で変更される可能性がある。そのようなURLを後になって永続化することはできない。しかし、今後公開するURLを変更の必要に迫られないような形の（例えば、ブランドなどの意味のある名称を使用しない）ホスト名の元に置くことで、この種のリンク破壊の可能性を減少させることができるだろう。
名称変更を含む通常のサーバ管理が永続化したいと願う識別子を破壊するのは当然か。永続識別子コミュニティの意見は、そうではない、である。
ほとんどのクリッカブル識別子は脆弱である。これは予想されることである。なぜなら、永続性には計画と監視が必要であるが、これを実際にすべてのオブジェクトに適用することは不可能であり、また、ほとんどの組織においてこれが優先リストの上位に現れることはほとんどないからである。通常、構築が簡単すぎるものは持続力のあるものではないのである。組織は永続化のための計画を行い、落とし穴に気をつけ、自らの責務を熟知する必要がある。この計画段階において自問自答すると思われる質問には、「識別子のどの部分が商業的、政治的、技術的、組織的変化に対して脆弱なのか」、「どの識別子を採用するべきなのか」、「我々が採用しない識別子は利用者の期待をどのように形成しているのか」がある。時が経つにつれ、公開したすべてのURLの記録を保管している機関はほとんどなく、たいていは、大規模な技術的、構造的な再編成により、大多数のURLは単に放棄される。
これは受け入れがたいことである。かつて Tim Berners-Lee が言ったようにクールなURIは変化しない [1] からである。多くの組織が現在、様々な理由で彼らのURLのどれが "クール" であるかを判断できず、クールであり続けることを保証する戦略の策定に失敗していることが問題である。
URI と URL
URI（統一資源識別子）は、URL（統一資源位置指定子）より3年遅れて登場した。URLはリソースの「住所」、すなわちリソースを見つけられる場所を記述する。一方、URIは「名前、位置、またはその両者」を記述することができる [2]。
その技術的背景は次のとおりである。オブジェクトを取り込むためにはブラウザはそのオブジェクトの場所を提供するサービスとコミュニケーションを取る必要がある。リンクが切れていることが判明した場合は、"404 Not Found" エラーメッセージが返される。もちろん、間違ったオブジェクトが取り込まれる可能性など、より微妙な失敗例も数多く存在する。
オブジェクトの取り込みに失敗する危険性を減少させるための重要な戦略は、ブラウザと対象となるオブジェクトの間に間接層を追加することである。永続識別子自体は具体的なインスタンス（オブジェクトのコピー）を参照するのではなく、デジタルオブジェクトの何らかの形の記述を提供する。間接識別子はあなたをオブジェクトの最新コピーへ転送するリゾルバを必要とする。オブジェクトをリゾルバに伝えると、ブラウザはオブジェクトの具体的なインスタンスを直ちに見つけることができる。例えば、間接指定は先に述べたファイルシステムをルックアップデータベースとして使用しているサーバの一般的な解決策である。リゾルバサービスは、サーバ上に一連の書き換え規則を持つだけの簡単なものもあれば、（DNSやハンドルなど）特定用途サーバの世界規模のネットワークのような複雑なものもあるが、対象となるオブジェクトの適切な、あるいは最新のコピーへブラウザをリダイレクトすることを目的としている。間接指定は通常利用者には見えない。
リンクリゾルバは数多くの理由で有用である。リンクリゾルバは利用者の地理的位置やオブジェクトに対するアクセス権を理解し、適切なバージョンのデジタルオブジェクトに利用者を転送することができる。さらに、地理情報や製品クレジット、コンテンツ管理サービス、権利管理、ライセンス管理など、URIリゾルバがリンク可能なオブジェクトに関連する数多くの二次的サービスが考えられる [3]。
図 1: 永続URIリゾルバの機能
この二次的機能の多くはそれ自体興味深いものであるが、本論文の第一の主題である永続性と直接関連すると考えるべきではない。
永続識別子システムの設計と採用には次のような問題が特に関連する。
以下の節では、永続識別子の現状に関する概略を得るために、こららの基準に基づいていくつかの標準を調査する。
現在、既に策定が完了している標準がいくつか存在する。
これらの多くはインターネット標準の提案方法として一般的に使用されているRFC（Request for Comment）文書に記述されている。その場合は対象となるRFCへのリンクをテキストに貼った。それ以外の標準は別の公開方法を通じて記述されている。
また、コンテンツベースの永続識別子には「非公式な」標準が数多く存在する。コンテンツベースの識別子（例えば、検索用のメッセージダイジェストや特徴語シーケンス、あるいはファイル共有ネットワーク上でピア・ツー・ピアのオブジェクト発見用途に使用されているed2kハッシュなど）は、文書の特徴的な「フィンガープリント」を検索・照合することによりデジタルオブジェクトを特徴付け、場合によっては取り込みも可能にしている。これらのスキームは本論文では検討しないが、他の分野で適用に成功していることもある特徴抽出とそのデジタルオブジェクト識別への応用である「フィンガープリンティング」アプローチと以下で述べる標準群とを対比させることには価値がある。
本論文で示した日付は、アイデアが生まれた日付ではなく、最初の完全な仕様が発表された日付、またはサービスが公開された日付のいずれかである。これら標準の多くについてさらに掘り下げた考察を捜している人は、2006年にHans-Werner HilseとJochen Kotheにより書かれた永続識別子に関する報告 [2] を先に読むと良いだろう。
URN（統一資源名）は1997年5月に完全な仕様が公開された。その要件は元々 RFC 1737 で定義され、仕様は RFC 2141 で発表された。URNの使用は必ずしもそれが参照しているリソースが利用可能であることを意味していない。
URNは場所ではなく存在を記述するために設計されている。例えば、URNは（ユニークな商用の図書識別子として使用されている）ISBN（国際標準図書番号）を含むことができる。例えば、次のURNは、Partha Nyogiが書いた『The Computational Nature of Language Learning and Evolution』という図書を記述している。
urn:isbn:0262140942
URNエンコーディングには数多くの種類のオブジェクトが存在する。雑誌のISSN（国際標準逐次刊行物番号）、フィルムとビデオのISAN（国際標準視聴覚番号）、IETF（インターネット技術タスクフォース）のRFCなどである。OID（Object IDentifier: オブジェクト識別子）システムを使用すると、URNでイギリスを参照することさえ可能である。
urn:oid:1.2.826
URN名前空間の割当は IANA（Internet Assigned Numbers Authority）で行われている。URN名前空間の定義方法は RFC 3406 に記述されている。文書は名前空間の登録に伴う費用負担の可能性について規定している。
NBN（全国書誌番号）の正確な仕様は2001年に公開された。NBNは国立図書館により独占的に使用されるURN名前空間であり、識別子を欠く納本出版物の識別とリソースを記述する記述メタデータ（目録）の参照を行うことを目的としている（RFC3188）。NBNはデジタル表現を持つオブジェクトにも物理的にしか存在しないオブジェクトにも使用することができるが、後者の場合は利用可能な書誌データが代わりに提供される。NBNは予備的メカニズムであるので、ISBNなどの代替となる識別子が利用できる場合はNBNの代わりに使用されるべきである。そのような識別子がない場合にNBNが与えられる。
NBNはRFC3188に記述されているエンコーディングに従ってURN内にエンコードされる。
DOI（デジタルオブジェクト識別子）は1998年に一般に公開された。DOIはハンドルリゾルバを基礎とする電子文書のための間接識別子である。DOIシステムの管理を行うために1997年10月に設立された国際DOI財団（IDF）によれば、DOIとは「デジタルコンテンツを永久に識別する仕組み」である。
DOIは主に物理的オブジェクトではなく電子文書に適用される。DOIは世界規模の適用範囲と単一の中央化された管理システムを持つ。また、ISBNなどの代替システムを置換するものではなく、それらを補完するものとして設計されている [4]。DOIは2つの部分から成る。1つは数値識別で、語をDOIとして識別する接頭辞（10.）と文書の出版者を識別する接尾辞から成る。もう1つは文書識別で、各文書を別個の語句で識別する。数値識別と文書識別はスラッシュで区切られ、次のような形をとる。
doi:10.345/document.identifier12345
スラッシュに続く文書識別は、DOIを登録するエージェントにより自動的に生成されるか、登録者により付与される。実際上、文書識別の語句はURLとしてエンコード可能な文字に限られる。DOIは大文字と小文字を区別しない。
一般に、ユニークIDとしての使用目的を超えて文書識別の語句に意味を持たせるべきではない。DOIはハンドルシステムにより解決される。DOIはUnicode-2（ISO/IEC 10646）用に設計されているが、Handle.netリゾルバがUTF-8を使用しているという事実により、UTF-8が必須のエンコーディングである。DOIはANSI/NISO Z39.84-2005として正式に承認されており、現在、ISO承認過程の後期段階にある。
DOIの登録には会費と各文書の登録・維持のための経費がかかる。従って、DOIを使用せずにHandle.netリゾルバを使用した方が望ましいと考えられる場合があるかもしれない。
Tim Berners-Lee等による論文 "Creating a Science of the Web" は実在の例を提供する。この論文には次のDOIが付与されている。
10.1126/science.1126902
このDOIは次のURL（dx.doi.orgはハンドルシステムの実装であり、DOIリゾルバとして機能する）で解決することができる。
http://dx.doi.org/10.1126/science.1126902
リゾルバにより利用者は適切なページに転送されるはずである。
1995年に提案されOCLCにより開発されたPURL（Persistent Uniform Resource Locator）は、動作可能な識別子である。PURLは1つのURLから成る。PURLはデジタルオブジェクトの位置を直接指し示す代わりにリゾルバを指し示す。このリゾルバはそのリソースの適切なURLを調べ、HTTPリダイレクトとしてクライアントへ返す。その結果、通常通り目的とするリソースの取り込み処理が行われる。PURLはURNなどの他の文書識別標準と互換性がある。この意味で、PURLはURNが普及するまでの暫定的解決策だと評されることがある。
PURLリゾルバを実装するソフトウェアパッケージはOCLCから無償でダウンロードできる [5]。PURLは公共PURLサーバを使って作成することもできる [6]。
PURLは主としてOCLCに結び付けられる。OCLCは現存する最古のPURLリゾルバを今も稼働しているが、これは、OCLC研究開発室がIETF統一資源識別子作業グループに積極的に参加したことに強く影響されている [6]。PURLの使用に経費はかからない。
ハンドルシステムは、1994年に初めて実装され、2003年11月にRFCとして公開された。ハンドルシステムは主にDOIリゾルバとして使用されている（上の例を参照）。実際には、ハンドルシステムは識別子を識別・解決する分散型で汎用の方法である。マスターとミラーの両サイトがCNRI（Corporation for National Research Initiatives）により管理されている。分散型というサービスの性格により信頼性のある可用性が保証されている。ハンドルシステムの概要はLannom [8] や関連のRFC [9][10] により提供されている。Handle.netのシステムはDOIシステムとは独立に使用することも可能である。基本となるソフトウェアパッケージがダウンロードでき、インストールして機関で使用することができる。
ハンドルシステムはCNRIにより設計され、当初は米国国防総省国防高等研究事業局（DARPA）のサポートを受けた。2003年11月に、RFC 3650、RFC 3651、RFC 3652 として公開された。
2000年に始まるOpenURLは、リソースのメタデータをエンコーディングしてURLに含めるもので、情報資源と図書館サービスを仲介するリンク付けを支援するように設計された。OpenURLは様々なメタデータ要素を含む。リゾルバはこれらを抽出し、適切なサービスを見つけ、その情報を返す。OpenURLはメタデータ転送プロトコルと評されることもある。
この標準は本来永続識別子/リゾルバとして設計されていない。機関でのリゾルバサービスを有用なものにする他の多くの課題が存在する。例えば、アクセス権の問題や利用者の閲覧許可を確認する情報源を捜さなければならないことなどである。さらに、テキスト文書に関してはそれほど問題になることはないが、帯域幅や性能の問題でローカルミラーを使用したほうが良い場合もあるだろう。これはマルチメディアリソースやソフトウェアの配布においては未だに大きな問題である。
OpenURLは2つの部分から成る。1つは利用者が所属する機関のOpenURLリゾルバにリンクする妥当なHTTP URLであり、もう1つはURI RFC（例えば、OpenURLの最初の定義が対象としたRFC2396を置き換える RFC3986）に則ってエンコーディングされた単なるクエリ文字列である。以下はOpenURLの例である。
http://www.springerlink.com/openurl.asp?genre=journal&issn=0942-4962
この例は、雑誌『Multimedia Systems journal』（ISSN 0942-4962）を示しており、SpringerLinkのリゾルバにより解決される。次の例は、図書『Understanding Search Engines』を示している。これらの例はどちらもユニークな識別子（ISBNとISSN）を含んでいるが、OpenURLはこれら情報の一部（例えば、タイトルや著者など）だけでも妥当である場合があることに注意されたい。
http://www.example.domain/resolver.cgi?genre=book&isbn=0898714370&title=Understanding%20Search%20Engines
OpenURLは、2000年に最初の草稿が作成され、2003年にNISO OpenURLバージョン0.1として正式に承認された。その後、ANSI標準Z39.88に発展した。この標準はOCLCにより維持管理されている。
2001年3月に登場したARK（Archival Resource Key）は米国国立医学図書館で開発され、カリフォルニア・デジタル・ライブラリで維持管理されているURLスキームである。ARKは任意の種類のオブジェクト（デジタルオブジェクトと物理的オブジェクトの双方）を識別するために設計された。
一般に、ARKの構文は次の形をとる（角カッコは[オプションの]要素を示す）。
[http://NMA/]ark:/NAAN/Name[Qualifier]
ここで、NAA（Name Assigning Authority）はこの具体的なオブジェクトの命名に責任を持つ組織を表す。この情報はNAAN（Name Assigning Authority Number）を通じて各ARKにエンコードされる。NAANはこの組織のユニークな識別子であり、URN名前空間と同じ方法で登録されている。NMA（Name Mapping Authority）は、このオブジェクトそのものに責任を持つ現在のサービスプロバイダ（例えば、Webサイト）である。NAAは通常独自のNMAを運用するが、これは必須ではない。ARKスキームはセマンティック的にはコアオブジェクトに不透明な識別子の使用を推奨しているが、ホスト名（NMA）のブランド化は許容している。しかし、これは永続性に関して常にうまく行くとは限らないことがわかっているので、識別のために2つのARKを比較する際はどんな場合であれホスト名は使用しない。また、セマンティック拡張（修飾語句）の使用も許容されており、通常一時的なサービスアクセスポイントを命名する際に使用される。以下に、ARKの例を示す [12]。
図 2: ARK構文の例
普通のURLとは異なり、ARKを使って次の3つ: オブジェクト自身、そのメタデータ（"?"を1つ付ける）、現在のプロバイダの責務宣言（"?"を2つ付ける）を取り込むことができる。ARKは様々な種類のメタデータを取り込むことができ、メタデータフォーマットを問わない。ただし、その使用が密接に関係付けられているメタデータフォーマットが1つある。ERC（Electronic Resource Citation）である。ERCはカーネルメタデータと共に同じ草稿文書（RFC draft-kunze-erc-01）で定義されている。ARK仕様の完全版も入手可能である [13]。
2003年に始まるWebCiteと国際インターネット保存コンソーシアム（International Internet Preservation Consortium）のメンバーは、DOIなどのシステムでは文書の改訂版ごとにユニークな識別子が付与される必要があるので、あまり安定していないリソースや正式に発表されていないリソースに使用するとそれ程効果がないことに気付いた。そこで、少し異なるアプローチで保存に取り組んだ。そのアイデアは1998年にWebベースの引用索引の可能性を考察した『British Medical Journal』誌の論文の中で初めて発表された [14]。このアイデアは簡単にテストされた後数年間放置されたが、引用されたWeb参考文献がリンク切れであったり、利用できなくなったりすることが依然として深刻な問題であることに気付いた2003年に復活した。WebCiteは正確に言えば永続識別子システムではない。正しくは、オンラインリソースのオンデマンド型のアーカイビングを提供するものであり、このキャッシュされたコピーを引用することにより将来においても継続的に利用できる可能性をより大きなものにするためのものである。そのため、WebCiteは他の識別子とは異なる種類の問題に遭遇する。例えば、サービスで利用できないためにキャッシュすることができない情報が存在する。これはおそらくファイアーウォールの中にあるか、特定のデジタルライブラリを購読していないと利用できないためである。さらに、サイト管理者が様々な理由でインターネットロボットやスパイダがWebサイトを利用できないようにrobots.txtファイルを書く可能性もある。
上記のシステムや仕様の間には実用上の違いが数多く存在する。永続識別子の話は必然的にURNやDOIといったセマンティク識別子の話を含むことになる。その結果、これら標準の区別の多くは、該当する標準識別子のリゾルバではなくその目的と適用範囲で行わなけれならない。
システムの中にはセマンティク的に意味のある文字列ではない不透明な（opaque）識別子の使用を推奨するものがある。不透明な語の使用を勧めるのには正当な理由がある。まず、ブランド化や組織的命名法は静的なものではなく、組織や話題、任務と共に変化する。また、文化的・社会的文脈に置かれることになる。従って、不透明な識別子は、再ブランド化や再定義といった名称の変更（セマンティク的なシフトとドリフト）を行う1つの動機を取り除く。ただし、それはある程度利用者の利便性を犠牲にすることになる。永続識別子の解決に失敗しても文字列に含まれるセマンティク情報からリソースを探し出せる能力と、意味のあるセマンティクスを含む文字列がある時点で変更される可能性の増大はトレードオフの関係にある。
このスペクトルの一方の端には（少なくともコアオブジェクト識別子に関しては）ARKシステムが位置し、もう一方の端にはOpenURLが位置する。
ARKとPURL（実際はURLも）の仕様は、誰もが運用可能なシステムを記述している。同様に、ハンドルサーバは他のWebサーバと同じような方法でローカルにインストールすることができる。これに対して、DOI識別子には関連手数料が数多く存在し、国際DOI財団により集中的に管理されている。手数料は通常、信頼性と権限に関係する。システムへ投資する意思のある者はその組織に対し経済的に関与することになるという見方がある。しかし、これははっきりとはしない事実を仮定している。経済的関与は組織がその目的をよく考えて決断を行ったことを暗示しているということは不当な仮定ではないが、DOIの使用は「ビジネス遂行経費」の一部であると考えられる可能性が存在する。
識別子標準における柔軟性の増加は、複雑性というコストをもたらすことになる。URNは様々な多くの名前空間やエンコーディングのスーパークラスである。これはある種の哲学的（認識論的）な問題を引き起こす。イギリスを示すURNと雑誌論文を示すURNとではどんな共通点を持つのか。URNはあいまいな話し言葉を記述する代用品として機能することができるが、これを永続識別子スキームの候補として考えることができるのか。また、上の例は次のような疑問も引き起こす。イギリスの4カ国の認識が結果的にスコットランドのグレート・ブリテンおよび北アイルランド連合王国からの脱退という選択を招いたとしたら、これはURN名前空間にどんな影響を及ぼすのか。一般に、野心的な識別子（特にURN）は標準の機能が完全に適用されることはない。柔軟性を増すにはコストがかかる。それはアプリケーションレベルで完全な実装を行うためのコストの増加や潜在的にはインターフェースデザインに対する負荷の増加として現れる。
これら標準の採用レベルは現時点においては明らかに大きく異なっている。多くの組織がARKに関心を示しているが、本格的に運用されている例は（フランス国立図書館、Portico、CDL、カリフォルニア大学など）わずかにすぎない。これに比較すると、DOIは幅広く使用されており、特に特定の分野での利用が多い。この違いは、特定の雑誌が他に比べていち早く永続URIの概念を取り上げたという事実によるものと思われる。
DOIのコストは通常、その投資がデジタルリソースの長期的可用性への組織的関与を一般に対して明らかにする手段であると説明することにより正当化されている。この意見は、永続URIに関してここ数年間繰り返されてきた多くの議論を通じてまとめられた共通のテーマを反映している。すなわち、組織的関与の長期的可用性への集中である。一連の永続識別子を集中的に管理し、迅速に更新できることには価値がある。しかし、継続的にこの目的に割く労働時間という点で言えば、保守管理処理を行うことが確実に必要となり、多くの場合、この作業は永続識別子を公開した者が行うことになる。
初めて永続識別子を見た人の観点から言えば、この標準の集団は少々威圧的である。各標準はそれぞれのニーズに合わせて構築されている。これら数多くの標準を調べ、各イニシアティブを結びつける共通の話題の数を知ることができるのは、おそらく後になって改めて考えた場合だけである。
簡単な説明を元にこれらの選択肢から選択することは不可能ではないにせよ困難なことである。一般に、ほとんどのソフトウェア構築プロセスは要件の収集と分析から始めるが、永続識別子システムの選択も例外ではない。システムが使用される文脈は重要な要因である。特に、これらの標準を採用した結果は非常に異なり、意図する利用や主題分野に大きく依存するためである。特定の文脈において採用を検討している団体は数多く存在するが、様々な学問分野や主題分野にわたる採用の正確なパターンは今のところ知られていない。
ARKでは想定される数多くのユーザ関連の問題に特別な注意が注がれた。例えば、紙媒体に書かれたURLをブラウザのロケーションバーにコピーする際に遭遇する問題など、実際的な問題点が設計に取り入れられた。この理由により、永続識別子標準の様々な選択肢を検討している人にはARKの仕様と関連文書を読むことを勧める。ただし、最も幅広く市場に浸透した標準は、（DOIを一般的なURN概念の暫定的な体現形と考えれば）URN/DOIと関連のリゾルバであると思われる。
ハイパーリンクの結果的な「崩壊」が問題であるという十分な証拠が存在する。一般に出版後も継続して利用可能なリソースの数を提供する統計が公開されている。例えば、生物医学出版物における補足的リソースを提供する約600のリンクを調べた小規模な調査の結果 [15] から、著者が提供したリンクを通じて71〜92%の補足データが継続的に利用可能であり、リンクが出版者のコントロールが及ばないサイトに移動した場合にリンクが利用できなくなる可能性が高いことがわかった。MEDLINEのURLに関する2004年の調査では、URLの12%にタイポやその他のフォーマットエラーがあり、HTTP URLのおよそ2/3は常に利用可能であり、他の19%は断続的に利用可能であることがわかった。FTPの状況ははるかに悪く、反応を返したのは1/3をわずかに超えるサイトだけであった [16]。
努力を集中させることを考えると、リソースの長期的可用性の保証という点で永続識別子はどの程度有効なのか、が最も重要な疑問である。各標準はまだ非常に新しいものである。これらはどの程度うまく働くのか。すべての標準が同じく成功するのか。何が不成功に終わるのか。
永続識別子を導入しようと考えている人にとってその他の重要な問題には対象となるドメインにおける標準の妥当性と寿命がある。例えば、ビジネス環境に最適化された標準がアカデミック環境には適さないことが判明することはあり得る。また、もしあれとすれば、その分野のユーザと統計調査を連動させることにより、対象とする使用ドメインのユーザに最もよく知られることになる標準を解明することは有用である。
他にも考慮すべき事項が数多く存在する。例えば、ある永続識別子標準が主として紙媒体での使用が想定されている場合、ARK仕様で示唆されているように、それは必須の機能セットに影響を及ぼすのか。チェックサムやエラー補正機能は適切だろうか。（上で述べたように）識別子のセマンティク的可読性が実際にその寿命に悪い影響を及ぼしているとしたら、この効果を量的に示すことは可能か。一方、もはや正しく解決できなくなった識別子から適切な情報を抽出する能力は、サーチエンジンや図書館目録で検索し、行方不明となったリソースの新しい配置場所を見つけ出すことを可能にするかもしれない。これらの効果のどちらがより注目に値するのか。また、どこにトレードオフを置くべきか。エンドユーザは永続識別子の意義を理解しているか。また、現在どんな場合に識別子が正しく適用されるているのか。
デジタルライブラリコミュニティが使用する用語の意味における永続識別子を技術は作成することができない。これは主として、これら永続識別子スキームの各々の寿命が（OpenURLを除いて）そのデータに付随するレコードを公開し、常に最新に保つことに対して情報プロバイダが長期的に関与するかどうかに密接に関わっているからである。さらに、あるリゾルバを通じて文書の永続識別子を提供することは、そのリゾルバを保守管理している組織と長期的な関係を結ぶことを意味する。しかし、適切な標準の選択はインフラが継続して利用可能であることを保証するための重要な第一歩である。ソフトウェアは時間と共に古びるので、より複雑なインフラはリゾルバパッケージを開発・公開した組織とのより大きな関係を意味する。
デジタルライブラリ界の内外には様々な永続識別子標準が入り込む余地があると思われる。一般に、インターネットインフラは同じような複数の標準によって利益を得る。実際、永続識別子の機能の一部を提供する数多くのリゾルバサービスが登場している。TinyURL（tinyurl.com）やSNURL（snipurl.com）、elfurl（elfurl.com）などである。しかし、これらのサービスは永続性や高度な可用性を約束していない。とは言え、これらのサービスはデジタルライブラリ界における正式な永続識別子サービスよりもはるかに広く利用されている。上で示したコンテンツベースの永続識別アプローチにもほぼ同じことが言える。これはそのようなスキームの最も一般的なアプリケーションの目的がピア・ツー・ピアのダウンロードであるという事実の結果にすぎないと言いたい誘惑に駆られるが、これには別の側面もある。すなわち、快適なインターフェースとアプリケーションの目的の明確な説明が提供されれば、平均的なエンドユーザはリゾルバサービスを喜んで使用できることを示している。
要約すると、永続識別子は重要な領域であるが、答えより質問の方が多い領域である。現在利用できる有用なサービスや標準は、この領域をさらに探索するための素晴らしい基礎となる。しかし、依然としてエンドユーザや永続識別子の潜在的貢献者にとって状況は混乱している。実用的なユースケースを明確化し、永続識別子の定義と維持管理に投資する理由をさらに公開する必要がある。各標準は他の標準の成功、失敗、見識から等しく学ぶことができる。
ある種の文脈において管理された永続性が達成されない場合があることを受け入れることは重要である。古いデータの可用性を保証するために割けるリソースは限られており、運営経費は毎年のデータ作成共に増加する。それ故、実際には、引き受けた永続識別子の管理義務から手を引き、代わりにできたら情報発見のためのより安価だが信頼性の低いスキームに移行するための整合性のある方法を提供したくなるかもしれない。
最後に、一般的な意味において問題を解決することは九分九厘無いものねだりであると認めなければならないが、長期的可用性を優先事項として挙げる機関には今や数多くの利用可能な選択肢が存在する。これは国立図書館や有名な雑誌から小規模出版者や個人にわたる多くの参加者を有する複雑な空間であり、「1つのサイズがすべてに適する」とは思われない。「保存の実験」と思われるほど矛盾したものではあるが、我々がしなければならないものはおそらくそれである。
本論文を執筆するにあたってJohn A. Kunzeが与えてくれた熱意、意見、提案に感謝いたします。
Ariadne is published every three months by UKOLN. UKOLN is funded by MLA the Museums, Libraries and Archives Council, the Joint Information Systems Committee (JISC) of the Higher Education Funding Councils, as well as by project funding from the JISC and the European Union. UKOLN also receives support from the University of Bath where it is based. Material referred to on this page is copyright Ariadne (University of Bath) and original authors.
2008年7月 第56号