 |
HOME | HANDBOOK | FACTSHEETS | FAQs | RESOURCES | USERS | NEWS | MEMBERS AREA |
この章では、マルチプルレゾリューションを利用し、DOI名を複数の解決選択肢から選ばれた最も適切なコンテンツに解決できるアプリケーションを提供する方法をいくつか説明します。選択肢には手作業で選択できるポップアップメニューや、コンテンツネゴシエーションとリンクトデータ（Linked Data）による統一自動選択があります。
© 国際DOI財団 • 最終更新日: 2016年2月3日
永続的な識別子を維持するには、登録者と連携した積極的な管理業務が求められます。このためDOIアプリケーションは通常、単にDOIを登録する以上の価値を提供します。登録機関は通常、引用リンクやメタデータ管理等の付加価値サービスを提供します（第8章：登録機関)参照）。
DOI名は様々な種類のコンテンツを識別でき、そのコンテンツへ至る単なる永久的間接的リンク以上のものにリンクできます。DOI名はオブジェクトに関する有用な情報を提供/指示することもできます（当該情報が登録者や第三者によってあらかじめ用意されている場合）。この情報には記述的メタデータやオブジェクトに関係するサービスが含まれます（例えば権利処理、警報サービス、データ可視化、その他関連情報/サービス）。この情報は、ユーザーのニーズを満たすようカスタマイズされたDOIアプリケーションによって様々な形で利用されます。
この章ではDOIアプリケーションの基礎を取り上げ、開発者がシステムの特徴を活かした新たなサービスを作るときに検討すべき設計要素を説明し、DOI名解決に基づいて登録機関から提供されるサービスの例を説明します。アプリケーションプロファイルによるグルーピングサービスへの取り組み、ボキャブラリマッピングフレームワークを使ってDOI名解決と相互運用可能なセマンティクスを融合する方法、DOIシステムとデジタルオブジェクトレジストリ技術の関係も説明します。
5.2.1 基本的機能性
DOI名の関連データは、それぞれ固有のIDを持つタイプ/値ペアとしてDOIシステムに格納されます。いつでも新しいタイプを追加でき、値の複雑さは自由に決めてよいため、極めて柔軟でオープンです。タイプ/値ペアには管理用のもの（例えば作成日、権限等）、周知で規格化されたもの（例えばURL、電子メール、10320/loc）、特定の用途のため登録機関によって作られるものがあります（例えば値がバイナリデータや特別な形式をとる文字列となるカスタムタイプ）。1つのDOI名に多数のタイプ/値ペアがあってよく、複数の同じタイプがあってもかまいませんが、全てのDOI名は少なくとも1つの「URL」タイプを持ちます。URLタイプの値はエンティティに関連するURLです。
最も基礎的なレベルにおいて、全てのDOIアプリケーションはDOI名を解決することによってDOIシステムに問い合わせ（クエリー）を行います。リクエストは、DOI名に関連する全データ（特定のタイプの全てのデータ、または特定の識別子を持つデータ）を所望する形に構成できます。（DOI名解決の基礎については第3章：解決.) を参照してください。）アプリケーションは1つ以上のタイプを理解し、値を解析し、評価し、処置を講じます。
Handle解決から返されたタイプ/値ペアを調べて特定の情報を提供するよう構成された簡素なサービスの一例をdx.doi.orgプロキシシステムから入手できます。このサービスは特定のDOI/DOI集団について責任を持つDOI登録機関（RA）の名称を返します。文字列「https://doi.org/doiRA/」の後ろにDOI名を付けると、そのURLの解決（HTTP GET）は登録機関の名称を指定するJSONのビットを返します。https://doi.org/doiRA/10.5240/B1FA-0EEC-C316-3316-3A73-Lを解決すると下記が返されます。
[
{
"DOI": "10.5240/B1FA-0EEC-C316-3316-3A73-L",
"RA": "EIDR"
}
]
URL文字列の中で複数のDOIを表すためコンマを使用すると、1つのリクエストで複数の結果が返されます。
5.2.2 設計上の検討事項
柔軟性と拡張性は良好に設計されたDOI方式サービスの重要な特徴です。柔軟性と拡張性に最も優れた方法は、軽量リダイレクトメカニズムとしてDOIシステムを使用し、識別子をしっかりと構成されたデータに解決することです。この方法を用いれば単一レベルのリダイレクトを超えたDOI関連サービスを提供できます。DOI登録機関はただ単にDOI名を解決して1つのURLを返すだけでなく、DOI名をコンテンツに関する複数の選択肢（例えば書誌メタデータ）に結びつけるマルチプルレゾリューションサービスを提供できます。選択肢には特定のメタデータ表現を求めるリクエスト、特定の状況（コンテクスト）だけに使用できるメタデータを求めるリクエスト等があります。
開発者は、サービスから提供される情報の全てか大半をDOIシステムに入れてDOIシステムを主たるサービス提供者にする方法や、DOIシステムを使って所望の情報や機能を提供する1つ以上の外部サービスを指示する方法を選ぶことができます。例えば、ユーザーに選ばせるラベルが付いた選択肢からなる簡素なメニューを表示するのに必要な全てのデータをDOIシステムに格納することもできますが、視覚化ツールのため大量の学術データや多数の画像ファイルを格納する外部サービスへリダイレクトするほうが、それらのデータをDOIシステムに格納するより好ましい場合もあります。
もうひとつの設計上の検討事項として、規格化された形式をとる上質の機械可読データを格納、使用、共有するアプリケーションの開発があります。標準HTTPウェブプロトコルのコンテンツネゴシエーション機能を利用すれば、リンクトデータ（Linked Data: 機械可読形式でデータを露出する周知のコンセプト）のベストプラクティスに準拠するDOIアプリケーションを設計できます。
DOI構造化データを活用して複数の登録機関用途にわたって一貫性のあるサービスを作ることが推奨されます。できる限りの協調が奨励されます。国際DOI財団（IDF）に加入していない第三者アプリケーション開発者にもDOI構造化データを活用するサービス作りに参加することが奨励されます。
これよりマルチプルレゾリューションとコンテンツネゴシエーションに基づくDOIアプリケーションサービスのサンプルを説明します。いつでも新しいサービスを作ることができます。質問はcontact@doi.orgへ送ることができます。
最も初歩的なDOIアプリケーションはDOIから「URL」タイプに解決するシンプルな単一点解決です。プロキシはDOI名を解決し、URLタイプを調べ、HTTPリダイレクトとしてエンドユーザークライアント（おそらくウェブブラウザ）へ値を返せることを理解します。このサービスが成功するのは、1）クライアントソフトウェア(プロキシサーバー https://doi.org (推奨) と https://dx.doi.org)がURLタイプを探し、値を抽出し、HTTPリダイレクトに埋込み、エンドユーザークライアントへ送り返すようプログラムされているから、2）DOI名の管理者がURLタイプを理解し、適切なタイプ/値ペアを加えたからです。
マルチプルレゾリューションはある1つのエンティティを複数のデータやエンティティに解決します。URLタイプに限らない複数のタイプ/値ペアをクライアントへ返すことができ、クライアントはデータを評価して次にとるべき処置を決定できます。（第3章、 第3.3節：マルチプルレゾリューションも参照してください。） XMLや他の機械可読データをDOI名に関連付けることによってマルチプルレゾリューションの有用性はさらに広がり、機能が加わり、コンテンツネゴシエーションの選択肢が増え、リンクトデータ（Linked Data）方式アプリケーションの作成が容易になります。
マルチプルレゾリューションは、何らかの基準に基づいて一連の候補の中から1つを選ぶアプリケーションを作る場合に向いています。アプリケーション開発者は値を入れるタイプを作ることができます。クライアントはこの値をもとにDOI名を解決しようとするユーザーに向けて選択肢のメニューを作ります。文書の場合は、文書を見る選択肢、文書のメタデータを見る選択肢、電子メールでURLを友人/同僚に送って文書をシェアする選択肢、著者のブログを訪ねる選択肢等がユーザーに与えられます。データセットの場合は、データセット一式を見る選択肢、選ばれたデータだけを見る選択肢、DOI名解決によりクライアントへ提供される情報に基づきデータセットを操作する選択肢等がランディングページでユーザーに提示されます。
例：学術雑誌の記事には1つのDOI名が割り当てられますが、それらの記事は複数のウェブサイトから入手可能であり、読者は自身が契約しているサービスから記事をダウンロードすることを望むかもしれません。図1に見られるように、Crossrefではマルチプルレゾリューションを利用しており、ユーザーは記事のDOI名を解決し、見たい記事のバージョンを選ぶことができます。
図1：2つのウェブサイトJSTORおよびBioOneから入手できる雑誌記事
このサービスには「10320/loc」タイプが使われています。10320/locは「場所」のリストを含む機械可読XML形式値を指定するタイプで、操作の選択肢を、すなわち「choose-by」オプションを、クライアントを提供し、DOI名を解決するときに取るべき処置を選べるようにします。複数の選択肢から特定のURLやその他の情報を選ぶための標準機構を提供します。リゾルバは既知の選択方法を順次適用し、リゾルバのコンテクスト（プロキシサーバーの場合はHTTPリクエスト）と場所の属性に基づいて場所を選択できます。（「choose-by」メカニズムの仕組みについては第3章：解決、第3.8.1.3節を参照してください。）
10320/locタイプはDOIサービスの選択肢を大幅に拡大します。図1に見られる「ユーザー選択」オプションのほかに、10320/locタイプに格納されるデータを利用することにより、所定の基準に基づき、特定のユーザーに対するDOI名解決の結果をクライアントに選ばせることができます。下の図1はDOI名10.1525/bio.2009.59.5.9に関連する（非管理）値を示しています。このDOI名は登録時に1つのURL値を持っていました（URLタイプと値、すなわちデータ、JSTOR URLに等しい）。他の解決オプションを提示する指導を提供するため10320/locタイプが追加されました。このレコードがプロキシへ返されると、プロキシは10320/locタイプを認識し、場所値の評価を依頼される場合は、所定の基準に基づいて場所値の評価を行います。
図2は10320/locタイプのデータを持つ同じDOI名を示しています。これは地理的位置を含み、これをもとにクライアントはユーザーのリダイレクト先にあたるURLを自動的に選択できます。
| 10.1525/bio.2009.59.5.9の値 | |||
| インデックス | タイプ | タイムスタンプ | データ |
| 1 | URL | Sun Jan 02 2011 13:32:18 EST | http://www.jstor.org/stable/25502450 |
| 1000 | 10320/LOC | Mon Jul 27 2009 13:18:25 EDT | <locations chooseby="locatt,country,weighted"> <location id="1" cr_type="MR-LIST" href="http://mr.crossref.org/iPage?doi=10.1525%2Fbio.2009.59.5.9" weight="1" /> <location id="2" cr_src="unca" label="SECONDARY_BIOONE" cr_type="MR-LIST" href="http://www.bioone.org/doi/full/10.1525/bio.2009.59.5.9" country="uk" weight="0" /> </locations> |
図2：10320/locタイプのXMLデータ
クライアントは次の通りに設定できます。
10320/locタイプを理解しないクライアントはタイプ/値ペアを無視し、URLタイプを使った単一レベルのリダイレクトを使用します。我々の知る限り、古いDOIクライアントはどれもこのように振る舞います。このため、何百万もの既存DOI名を壊さずにDOI解決に新しい機能を加えることができます。
この方法を登録機関にある何百万ものDOI名に応用した場合でも、全てのDOIレコードをことごとく変える必要はありません。DOIシステムのインフラでは、所与のDOIプレフィックスのもとで全てのDOI名に当てはまる情報を、当該プレフィックスを扱うサービスを識別するDOIプレフィックスレコードに記録でき、クライアントはその情報を解決プロセスに通すことができます。登録機関がリンクトデータに対するアプローチを変え、異なるサービスを指示したり異なるパラメータを使用する場合でも、変更は1つのDOIプレフィックスに加えるだけでよく、何百万ものDOI名の全てに自動的に適用されます。
興味深いことに、Schema.orgは、サイトからコンテンツやデータの「リッチスニペット」を検索エンジンの結果ページに直接取り込むことによって主要検索エンジンがウェブページで構造化データを認識する方法に関する技術文書を提供しています。Schema.orgはRDFを避け、よりシンプルなHTML5マークアップを支持しています。「リッチスニペット」によって検索エンジンは有意義なセマンティクスをウェブ上のコンテンツに読み込むことができます。この「リッチスニペット」は10320/locと「chooseby」を使ってやれることとまったく同じです。Schema.orgが興味深いスニペットを規定し、それらが十分に重要になったら、それらを値として記録したりプロキシから生成することは容易です。
上述した「choose-by」メカニズムの顕著な用途は、リンクトデータ（Linked Data）サービスへのリダイレクトです。リンクトデータは、標準HTTPウェブプロトコルのコンテンツネゴシエーション機能を用いて機械可読形式でデータを可視化する一連のベストプラクティスの総称です。これらのベストプラクティスは、複数のウェブソースからのデータをリンクして利用するツールの開発を支援します。互いに整合しない多数の異なる独自のアプリケーションプログラミングインターフェース（API）を扱ったり、人が読める表示ではなく機械のために構成された形式でデータを要求するためHTTPを使用する必要はありません。ウェブの初期には人がほとんどのURLをたどっていたので、DOIウェブプロキシがDOI名を人可読ウェブページに解決したことは理に適っていましたが、今はそうではありません。
dx.doi.orgのDOIプロキシはDOI名のコンテンツネゴシエーションをサポートします。リンクトデータ方式アプリケーションにおいて、プロキシサービスに届くHTTPリクエストの評価は、それがapplication/rdf+xml形式のコンテンツを求めるリクエストなのか、それともリンクトデータを求めるリクエストとして一般的に理解されているタイプのいずれか1つなのかを判断します。これらの特別な種類のコンテンツを求めるリクエストは自動プロセスか特別な「リンクトデータ」ブラウザから届き、通常はエンドユーザーから届きません。その有用性として、外部の開発者はIDF登録機関で保管されている豊富で信頼できるメタデータレコードを問い合わせて付加価値のあるサービスを構築できます。
コンテンツネゴシエーションはデータをリンクするという目標に到達するための方法として認められています。ウェブサーバーにとって、そしてDOIプロキシサーバーにとって、コンテンツネゴシエーションは「私は何を送りかえすべきか」を意味します。ユーザーは特定のウェブリソース表現をリクエストできます。例えば、DOIリゾルバはコンテンツネゴシエーションを使ってDOI名の様々なメタデータ表現を提供できます。DOIリゾルバに対するコンテンツネゴシエーション方式リクエストは一般的なHTTPリクエストに似ていますが、クライアントが提供する許容コンテンツ種類のリストに基づいてサーバー主導型ネゴシエーションが行われます。
一部のDOI登録機関は自身の全DOI名にこの方法を採用し、共通の機械可読形式でメタデータを返すサービスを提供しています。DOI登録素材にリンクトデータの原則と技術を応用する場合の大きな利点は、それが「リンクする価値のあるデータ」だということです。それは整理され、付加価値のあるデータであり、登録機関によって管理され、訂正され、更新され、一貫的に保守されます。永続的でもあるので「ビット崩壊」を回避できます。実際、リンクトデータ実装のクオリティは、リンクしようとするデータと、使用するリンクの意味と文脈付けに左右されます。DOIシステムは整理されたデータを提供できます。リンクは管理され一貫性があるため、標準リンクトデータ技術を使いながら他の「上質データ」へ確実にリンクできます。
5.4.1 コンテンツネゴシエーション
DOI登録機関は、付加価値のあるメタデータ表現をユーザーに提供するため、自身のDOI名でコンテンツネゴシエーションを実施しています。いくつかの引用スタイルがサポートされており、一部は複数の登録機関で共通となっています。コンテンツネゴシエーションを使用すると、特定の登録機関に相応しい種類のコンテンツを優先するリクエストが可能であり、他の登録機関の場合にはより一般的なコンテンツで応答します。これらのサービスに対するリクエストは自動プロセスか特別な「リンクトデータ」ブラウザから届き、通常はエンドユーザーから届きません。その有用性として、外部の開発者はIDF登録機関で保管されている豊富で信頼できるメタデータレコードを問い合わせて付加価値のあるサービスを構築できます。CrossrefとDataCiteとmEDRAはそれぞれhttp://data.crossref.org、http://data.datacite.org、およびhttp://data.medra.orgサービスでコンテンツネゴシエーション方式DOI名をサポートしており、フォーマットされたメタデータを問い合わせることができます。
HTMLページヘッダーがGET "Accept: text/html"を含む通常のブラウザリクエストの場合は、DOI名が解決され、ユーザーは発行者のランディングページURLへリダイレクトされます。例えばDOI「10.1126/science.169.3946.635」は記事「The Structure of Ordinary Water」を記述するランディングページへリダイレクトします。コンテンツネゴシエーション方式リクエストを作るには、HTTPヘッダー「Accept」を使用する必要があり、GETは、クライアントにとって受入可能で（クライアントにとって解析の仕方が分かるもの）、リンクトデータのリクエストであると一般的に理解される、他の既知コンテンツタイプを含みます。ヘッダーがGET "Accept: application/ref+smlというブラウザリクエストの場合、上記と同じDOI名を解決すると、ユーザーは登録機関のメタデータサービスへリダイレクトされます。また、citeproc JSONが入手可能であればciteproc JSONを受け取ることを望み、citeproc JSONが入手不能の場合はRDF XMLを処理できるクライアントは、Acceptヘッダーで「application/citeproc+json」と「application/rdf+xml」の両方をリストするリクエストを行います。
10320/locタイプはプロキシによって解釈され、GETに基づき、場所値をもとに適切なメタデータサービスへリダイレクトが行われ、そこでユーザー向けのレスポンスが作られます。Crossref、DataCite、およびmEDRA DOI名の場合、「text/html」ではないコンテンツタイプを所望するdx.doi.orgに対するリクエストは、DOI名の登録機関によってホストされているメタデータサービスへリダイレクトされます。
説明のため上記のDOIメタデータを使用。全てのCrossref DOI名はURLタイプに加えて10320/locタイプを持ちます。
| 10.1126/science.169.3946.635の値 | |||
| インデックス | タイプ | タイムスタンプ | データ |
| 1 | URL | Tue Jan 17 2012 14:39:18 EST | http://www.sciencemag.org/cgi/doi/10.1126/science.169.3946.635 |
| 1000 | 10320/LOC | Tue Jan 17 2012 14:39:18 EST | <locations chooseby="locatt,country,weighted"> <location weight="0" http_role="conneg" href_template="http://data.crossref.org/10.1126/science.169.3946.635" /> </locations> |
全てのコンテンツネゴシエーションクエリーは、引数として要求されたDOI名を用いてdata.crossref.orgのサービスへリダイレクトされます。（同じDOI名に対する解決リクエストでありながら、特別な｢リンクトデータ｣コンテンツネゴシエーションマーキングのないものは（例えば従来のウェブブラウザトランザクション）、期待されるURLタイプに帰り、従来のDOIリダイレクトを戻します。）「application/citeproc+json」と「application/rdf+xml」の両方をリストするコンテンツネゴシエーション方式リクエストのAcceptヘッダーと、サービスによって返されるメタデータを以下に示します。このリンクトデータ方式アプリケーションの詳細はhttp://crosscite.org/cn/で見ることができます。
プロキシは、コンテンツネゴシエーションリクエストに対し別々の解決を持つDOIが解決される場合に「Vary: Accept」HTTPヘッダーを返します。開発者はこれを用いてコンテンツネゴシエーションサポートを提供するDOIがどれなのかを判断できます。
リンクトデータの目標（HTTP URIを用いたコンテンツネゴシエーションにより、人とユーザーエージェントがRDFやXML等の標準形式でオブジェクトに関する情報を利用し、発見を向上させる他の関連URIへ至るリンクを獲得する）はDOIシステムの永続性のある上質データを用いて達成されます。リンクトデータ方式アプリケーションの数は増え続けています。新しいサービスに関するアイデアや要求がある場合はcontact@doi.orgに問い合わせてください。
DOI名はアプリケーションプロファイル（AP）に分類できます。アプリケーションプロファイルはDOI名で利用できるサービス（メタデータサービスを含む）を規定するものです。それぞれのDOI名は1つ以上のアプリケーションプロファイルに属します。例えば、デフォルトでは全てのDOI名がある1つのアプリケーションプロファイルに属します。これによりDOI名は、少なくとも当該DOI名の最小限のカーネルメタデータを含むネットワーク上の場所まで解決されます。アプリケーションプロファイルは概念的分類に役立ちますが、厳密にはDOIデータモデルにおける解決機構の一部とみなすこともできます。アプリケーションプロファイルを正式に登録し、例えばラベルとして、それをDOI解決とともに返される構造化データの一部として組み込むメカニズムは、アプリケーションの所要条件によって異なります。ユーザーになる見込みのある方は国際DOI財団（IDF）に相談してください。
DOIシステムは、解決能力と、ボキャブラリマッピングフレームワーク (VMF)を用いて関係を規定する（または既存制度からマッピングする）シンプルで有用で相互運用可能なセマンティクスを提供することによって、DOI名で識別されるエンティティを互いに関係付けるリンクトデータ等のメカニズムの開発にあたってさらなる支援を提供します。これを利用する見込みのあるユーザーにはIDFコミュニティと協議を行うことを強くお勧めします。
以下に示すリレータは、タイプによる関係の形成（「このDOI名は所定のタイプの関係によって別のDOI名に関係している」）にあたって登録機関による使用が推奨されるものです。
ここで関連するセマンティクスは、リソースや当事者を表す2つのDOI名を結び付ける「リレータ」、もしくはOWL/RDFの用語で「プロパティ」と呼ばれているものです。国際DOI財団（IDF）はそのデータディクショナリの名前空間に少数の「主要」リレータを追加しました。「主要」リレータは、既存のコンテンツ規格/データベースの中でリソースや当事者の最も一般的かつ重要な関係を表すものです。登録機関には自身のスキーマの中でこれらのリレータを使用することが推奨されます。IDFは手始めに、主要「リソース対リソース」リレータ5個と主要「当事者対リソース」リレータ1個を提案しています。
このリストはコンテンツ規格/データベースに基づくスタート地点で、それぞれがVMFで鍵となるコンセプトを代表しています。ただし、登録機関が独自のリレータを所有したり、より特化されたリレータの使用を望むことも多々あるでしょう。例えば登録機関は、単なる派生ではなく、適応、抽出、改訂版を指定することを望むかもしれません。原則として、これはどのような粒度にも拡張できます。VMFを用いて、主要リレータにサブリレータの階層を設けることもできます。例：
IsDerivedFrom
IsAdaptedFrom
IsTranslatedFrom
IsAutomaticallyTranslatedFrom
IsCompiledFrom
IsExtractedFrom
IsUpdatedVersionOf
IsCreatedFromBasis
IsReplicaOf
etc
登録機関は必要に応じてこれらをDOIデータディクショナリに追加できます。これは非常に小さく的を絞ったVMFのサブセットであり、使用されている例はどれも既に別の名前でVMFに入っており、他にもたくさんあります。
このミニオントロジーは、特定のリレータへの「IsSameAs」マッピングを登録機関自身のスキーマや他のスキーマ（DC、foaf等）に含めることもできます。例：
doi:HasMainSubject owl:equivalentProperty foaf:IsPrimaryTopicOf
明らかな相互運用性の理由から、構造リレータはRDF/OWL規格を利用します（例えばowl:equivalentProperty、rdfs:subPropertyOf）。この構造は、望ましい用語や必須の用語へ翻訳できるという基本的推論に裏付けられた、小さいながら力強い階層的で等価のリレータオントロジーを提供し、登録機関はDOI名が関わるリンクトデータを作成し、収穫できます。最初の主要リレータを越えたリレータオントロジーの規模と範囲は拡張可能で、登録機関の要求によって決まります。
表：推奨される主要リレータ
| リレータ | 定義 |
| doi:IsDerivedFrom | 派生（例えば適応、抜粋、編集）とこれの派生元にあたるソースとの関係を示すリレータ。 |
| doi:IsManifestationOf | 明示（例えば固定化、パフォーマンス）とこれが実現する働きとの関係を示すリレータ。 |
| doi:HasSubject | 産物とこれによって参照されるエンティティとの関係を示すリレータ。 |
| doi:IsReplacementFor | 産物とこれが（例えばソフトウェアの更新版として）取って代わる産物との関係を示すリレータ。 |
| doi:IsPartOf | 産物とこれによって一部が形成される産物との関係を示すリレータ。 |
| doi:HasContributor | 産物とこれの製作に貢献した当事者との関係を示すリレータ。 |
上記の関係はいずれも多対多です。
主要リレータはいくつもの特化された子を持ちます（子はデータディクショナリ内のどこにでも追加できます）。その例を以下に示します。
IsDerivedFrom
IsAdaptedFrom
IsTranslatedFrom
IsCompiledFrom
IsExtractedFrom
IsUpdatedVersionOf
IsCreatedFromBasis
IsReplicaOf
etc
IsManifestationOf
IsPerformanceOf
IsFixationOf
IsRecordingOf
etc
IsReplacementOf
IsUpdatedVersionOf
etc
IsPartOf
IsChapterOf
IsMemberOf (for sets)
etc
HasSubject
RefersTo
HasMainSubject
etc
HasContributor
HasAuthor
HasPrefaceAuthor
HasEditor
HasIllustrator
etc
一部のDOI実装では、DOIシステムと補完的機能を提供するCNRIのCordraソフトウェアが使われています。 HandleシステムとCordraはいずれも、より広範なデジタルオブジェクトアーキテクチャの一部です。基礎的な技術をある程度カスタマイズすることが求められる場合があり、これはCNRI等によって行われます（このレジストリ技術はDOIシステムの一部ではなく、IDFによって管理されていませんが、DOIへの使用が推奨されています）。
5.7.1 デジタルオブジェクトレジストリ
デジタルオブジェクト（DO）レジストリソフトウェアは（DOIシステムで使用される）Handleシステムを補完するためCNRIによって開発されました。現行バージョンであるCordraは CNRIのDOリポジトリソフトウエアで DOレジストリを統合しています。カード目録や電話帳に似た逆引き機能を提供し、登録済みの属性を探すことによって識別子を見つけることができます。Cordraはオープンで、自由に利用でき、DOIアプリケーションを含む多くの分野で利用されています（例えば映画テレビ業界のエンターテイメントIDレジストリ、EIDR)。レジストリは、今日現存し日常的に利用されている既存システムを用いて比較的安価に比較的迅速に構築できます。CNRIによって開発されたDO技術は、その大部分が政府の資金提供で支えられており、少額もしくは無料で自由に利用できます。
このレジストリソフトウェアをDOIシステムに利用することで、分散したデータソースを様々な形で連合させることができます。つまり、多数のネットワークアーキテクチャが可能です。シンプルな方法では、所定のエンティティに関するメタデータを検索可能な1つのレジストリへ提出する権限を登記係に与えます。提出されるメタデータは所定のメタデータスキーマに従って構成されるため、構文的に検証できます。また、登録されたエンティティにはまだ識別子がないと仮定して識別子（DOI）が与えられます。メタデータにはインデックスを付けて検索できるようにします。検索は識別子を含む1つ以上の項目を返します。これをもとに、どんなトランザクションやコンテクストでも識別されたエンティティを参照できます。
このシンプルなシナリオにはいくつかの問題とバリエーションがあり、シナリオそのものにも構造上のバリエーションがあります。このシナリオの中で、レジストリの識別子解決システム内に保管され、登記係で保持されるデータは多種多様です。例えば、レジストリは最低限の参照データを収容し、それ以上のものは保持せず、登記係はレジストリで保管されているコアを超えた、ことによると規格化されてない、追加的データを提供するサービスを運営し、識別子システムはレジストリを指し示すポインタのみ保管することもあり得ます。あるいは、解決システムでコアデータを保管し、レジストリで広範なデータを保管し、登記係の役割がデータの提出となることもあり得ます。構造的に、レジストリソフトウェアは単一集中型レジストリのシナリオに限定されません。複数のレジストリを構築して互いに並行して稼働させることもでき、その場合は、新しい項目や項目の変更が他のレジストリで直ちに反映されます。
このようなシステムの試作に要する労力は機能的要件に大きく左右されます。大切な作業は事前の分析で既存ソフトウェアの構成やカスタマイズに関する要件を判断することです。
5.7.2 DOアーキテクチャ
DOIシステムはどのような形態のオブジェクトも定義します。DOI名は、物理的、デジタルまたは抽象の任意のエンティティに割り当てることができます。デジタルオブジェクトアーキテクチャで定義されたオブジェクトは、デジタルのみです。任意のエンティティがデジタル表現として扱うことができるように、これら二つのアプローチの間に衝突は存在しません。これはシンプルに説明のレベルとして使用されている以下の図で言う、もう１つの「既存または将来の情報記憶システムへのオーバーレイ」です。
図３：DOIシステムに使用されるHandleシステムがコンポーネントとなっているデジタルオブジェクトアーキテクチャにおいて想定されるデジタルオブジェクトクラウド
私たちはいつも多くのレベルでオーバーレイを扱います。 例えばスプレッドシートはデータセル行列上のオーバーレイです。 次に基本的なマシンコード上のオーバーレイがあります。金融システムは、スプレッドシート上のオーバーレイです。 抽象的な作品は作品の個々の表現の上のオーバーレイです、など。 「自己説明」はデジタルオブジェクトにアプリケーションで明確に使用されるオブジェクトの十分な情報が含まれていることを、直接そのコンテンツの一部として、または間接的にいくつかのメタデータへのリンクとして示しています。 自己説明オブジェクトは適切な情報を取得する低いレベルの情報オーバーレイにアクセスすることができます。
場合によってはエンティティ全体ではなくエンティティの断片（フラグメント）を識別することがアプリケーションに求められます。そのような断片に別々のDOI名を割り当ることが現実的で好都合なら（例えば、ある書物の中の特定の表が何度も繰り返し使われる見込みがある場合は）、そのような断片にもDOI名を割り当てることができます。 DataCite（DOI登録機関）は、標準#フラグメント、DOIのリダイレクトとスクリプティング、W3C MFID (メディアフラグメント識別子)を使用しています。これはDOI https://doi.org/10.5446/12780#t=00:20,00:27の解決によって実証されるように、DOIリゾルバにとらわれない、広く認められた標準です。
ただしこれが常に可能とは限りません。「このエンティティのいずれかの断片」を識別することが急遽必要になる場合もあります。そのような場合には「テンプレートHandle」を利用できます。ベース式の形で1個のテンプレートDOIHandleを含めることで、パターンに応じてそのベースに対するいくつものエクステンションを完全なDOIHandleとして解決でき、Handleを個別に登録する必要はありません。例えばDOI名を使ってビデオの中のいくつものレンジを参照でき、レンジごとに別々のHandleを登録する必要はありません。パターンを変える必要がある場合（例えばビデオが動く場合、またはビデオクリップを提供するため種類が異なるサーバーが使われる場合）でも、1個のベースDOI名（Handle）を変えるだけでよく、あらかじめ構成されたいくつものエクステンションは引き続き適切に解決できます。
|
®、DOI®、DOI.ORG®及びshortDOI®は国際DOI®財団 (IDF)の登録商標です。 |