ホーム > ドキュメント > DC引用情報ガイドライン >

ダブリンコア・メタデータにおける書誌引用情報の符号化ガイドライン

1 序言および適用範囲

本文書は書誌引用情報をダブリンコア記述に記録するためのガイドラインを提供する。主に、次の事項に焦点を絞る。

• 雑誌論文の書誌引用。これは、そのような記述が必要である最も一般的なジャンルである。ただし、他のジャンルについてのガイドラインも提供される。
• リソースの書誌引用を自身のメタデータに記録すること。ただし、他のリソースの参照を記録するためのガイドラインもいくつか示される。
• 限定子付きのダブリンコア記述。ただし、この情報をシンプルダブリンコアに記録するための提案もいくつか提供される。

レコードを発見し、検索したレコードを人間が読むことができるように書誌引用情報を記述する必要性に加えて、ある種の応用では機械が読むためにふさわしいフォーマットにこの情報を符号化したいという要求を持っている。本ガイドラインでは、新たに別のDCMI構文を考案するのではなく、OpenURLフレームワーク標準（Z39.88-2004）[1]による記述を使用することを提案する。

多くの実装では雑誌論文を記述する方法が必要であったが、ガイドラインが存在しなかったので、その場限りの解決策がたくさん考案されてきた。これらは各自の問題は解決するものの、相互運用性を阻むものである。本ガイドラインは、書誌引用情報をダブリンコア記述に符号化するために推奨される、そして、その結果として相互運用可能となる方法を提供する。

リソースの発見やシンプルで相互運用可能なリソースの記述のためにダブリンコア・メタデータを使用して書誌アイテムを記述しようとする際に、本ガイドラインが有用であることが期待される。本ガイドラインは、より複雑なメタデータ記述要件に対する解決策を提供することを目的とするものではない。また、そのような場合によりふさわしいメタデータスキームを置き換えようとするものでもない。書誌アイテムをXMLで記述するためのより詳細な方法については、PRISM[2]やMODS[3]、NLM Data[4]など、他のスキームがより適していることが示されている。

本文書は、ダブリンコアにおける書誌引用情報のXML符号化のための詳細なガイドラインを提供するものではない。XML符号化のためのガイドラインは、将来、本文書とは別に公開される予定である。

以下の様々なデータの表において、「文字列値」として知られている単純な文字列であるプロパティ値と、「URI値」として知られているURIとして解釈されるべきプロパティ値は区別されている。文字列値には必要に応じて語彙の符号化スキームを示した。

本文書においては、ダブリンコア名前空間について以下の略語を使用する。

本ガイドラインは、DCMI引用作業部会[5]における数年にわたる議論の成果である。本部会による過去の勧告案は、DCMI利用委員会により承認されたものを除き、本ガイドラインにより、すべて廃止あるいは非推奨とする。ダブリンコア用語「bibliographicCitation」が導入される以前は、ダブリンコア・メタデータを使って雑誌論文を完全に記述する方法は明らかではなかった。雑誌タイトルを論文タイトルとは別のものとして記録するのに適したダブリンコア・プロパティや、一般記述の一部として記述する以外に、巻号やページ詳細の記録に適したダブリンコア・プロパティは存在しなかった。様々な解決策が提案された中で、もっとも魅力的な案は雑誌情報や巻号情報を関係要素の「isPartOf」として記述するものであった。しかし、これには論文自体に付随するページ詳細を含めることはできないだろう。

2 限定子付きダブリンコアにおける書誌引用

2.1 記述されるリソースの引用情報

勧告 1. リソースの書誌引用情報を記録するには dcterms:bibliographicCitation を使用すること。

リソースの書誌引用情報を自身のメタデータに記述するための推奨プロパティはdcterms:bibliographicCitationである。これは、dc:identifierの要素詳細化であり、'dcterms'名前空間で定義されている。このプロパティの値は、リソースを含む書誌アイテムの詳細をその書誌アイテムにおけるリソースの位置と共に保持する。したがって、雑誌論文では、雑誌タイトル・巻号数・ページ付け・出版日を、図書の章では、図書詳細とページ付けを、記録することができる。自身のタイトルや著者など、リソースのその他の詳細は、通常のダブリンコア・プロパティを使って記述することになる。オプションとして、ただし、重複して、これらの詳細についても引用に含めることができる。雑誌のISSNや図書のISBNは 関係要素のdcterms:isPartOfプロパティにURI値として記録することができる。例1と2に、雑誌論文と会議論文のダブリンコア・メタデータ記述を示す。これらの例は特定の構文ではなく表形式で示されているが、この形式の方が任意の推奨ダブリンコア構文での使用には適しているだろう。

例 1. 雑誌論文のダブリンコア記述

例 2. 会議論文のダブリンコア記述

2.2 テキストによる引用

勧告 2. 常にプレーンテキストによる引用を提供すること。

一般的なリソース発見および人間の可読性のために、bibliographicCitationプロパティの値はプレーンテキストで与えられるべきである。たとえ機械がパース可能な引用が提供される場合にも、対応するプレーンテキストによる引用で引用が繰り返されることが推奨される。

プレーンテキストによる引用は広く認められている引用スタイルに従うことができる。いくつかの引用スタイルがDCMI引用作業部会で検討された。これらのスタイルは、引用スタイル[6]ページにリストアップされているが、スタイルの選択については特別な勧告は存在しない。使用されたスタイルは、そのスタイルがURIを持っている場合は符号化スキームとして示すことができる。それ以外の場合は、引用スタイルを示すDCMI承認の符号化スキームは存在しない。

勧告 3. テキストによる書誌引用には、リソースを識別できるだけの十分詳細な記述を含めるべきである。

テキストによる書誌引用には、その引用によりリソースを識別できるだけの十分詳細な記述を含めるべきである。dcterms:bibliographicCitation は dc:identifier の要素詳細化であり、実際上、書誌的リソースはその引用情報により識別されると認識されている。したがって、雑誌論文では、dcterms:bibliographicCitationプロパティの値には、少なくとも、雑誌タイトル（あるいは、他の何らかの雑誌識別子）; 巻、号、あるいは必要に応じてパート番号; 開始ページ、あるいは、電子論文のみの場合はその雑誌において論文を識別する何らかの情報、を含んでいるべきである。また、完全なページ付け情報、すなわち、最終ページを含めることや（たとえdcterms:issuedプロパティの値を繰り返すことになったとしても）出版日付を提供することもおそらく意味のあることであろう。プレーンテキストによる引用のサンプルをいくつか例3に示す。

例 3. テキストによる引用の例

• Scripta Materialia 48(5), 475-481 (2003)
• Schrader, Alvin. "Internet Censorship: Issues for Teacher-Librarian." Teacher Librarian 26, no.5 (1999): 5 pp
• Martin Greenberger et al., eds., Networks for Research and Education: Sharing of Computer Information Resources Nationwide (Cambridge: MIT Press, 1974)

2.3 機械がパース可能な引用

勧告 4. 機械可読の引用にはOpenURLのContextObjectを使用すること。

機械がパース可能な引用の提供は、デジタルな相互運用性の普及を促進する。

「文脈依存サービスのためのOpenURLフレームワーク」は、ANSI/NISO標準 Z39.88-2004である。この標準は、被参照リソースを、参照コンテキストを構成する関連リソースとともに記述する方法を提供する。このパッケージは「ContextObjext」と呼ばれる。また、この標準は、ネットワーク上のシステム間でこれらの記述を転送する方法である「OpenURL」の種類も定義している。ContextObjextはOpenURLの「ペイロード」であるが、自立したデータオブジェクトひいてはダブリンコア・プロパティの値になることも可能である。OpenURLフレームワーク標準のさらなる詳細については付録 Aに示した。

現在のところ、OpenURLフレームワークは、その最初のレジストリ [7]において、標準の一部として以下のアイテムのメタデータフォーマットを定義している: 雑誌および雑誌の一部; 図書および図書の一部。これには、会議録や会議論文、報告書、単純な文書を含む; 学位論文; 特許。将来、おそらくさらに多くのメタデータフォーマットが定義されると思われる。

これらのメタデータフォーマットは、キー/符号化値（KEV）フォーマットおよびXMLフォーマットとして利用可能である。XMLフォーマットの使用は将来の文書で記述される予定である。しかし、XMLアプリケーション以外の多くの利用には、KEVフォーマットが最も適しているだろう。KEVフォーマットは、「アンパサント（＆）」区切りのペアの文字列であり、各ペアは「等号（＝）」で分けられたラベル（キー）とその値で構成される。値は「URLエンコード」される。これは、HTTPにより転送される際に誤って解釈されないように、特定の文字を同等な16進バイト列に変換することを意味する（たとえば、'/'は'%2F'に、':'は'%3A'になる）。

例4と6は、例1と2で示した雑誌論文と会議論文の書誌引用情報をキーと値で示したものである。例5と7は、同じ例をURLエンコードされた完全なContextObjextで示したものであり、XHTMLに符号化されたbibliographicCitationプロパティに示されている。例5は dcterms:isPartOfプロパティのURI値として雑誌のISSNも含んでいる。これらの例は、OpenURLフレームワークの用語では「被参照体（referent）」と呼ばれているリソースを記述する際に最も一般的に使用されると考えられるContextObjextのキーを含んでいる。完全なメタデータフォーマットはOpenURLレジストリ[7]に定義されているが、これらの例では、雑誌メタデータフォーマット[8]と図書メタデータフォーマット[9]を使用している。KEV実装ガイドライン[10]にはもっと多くの例が示されている。オプションとして、ContextObjectには論文タイトルや著者といったさらに詳細な情報を含めるができるが、これらはダブリンコア記述の中では冗長である。勧告 3により、ContextObjectにはリソースを識別するだけの十分な情報が存在するべきであることに注意のこと。

オプションとして、ContextObjectには、ContextObjectの作成者であり、その来歴を示している「リファラ（referrer）」を含めることができる。この例ではリファラは、カレントアウェアネスとドキュメントデリバリーサービスであるZetocである。リファラは、'info:sid/'スキームにサービスのDNS名を使い、オプションとしてデータベース名を付けたURI、たとえば、info:sid/mimas.ac.uk:zetoc で識別される。

引用を記述するためにここで使用したKEV ContextObjectは、URI 'info:ofi/fmt:kev:mtx:ctx'で識別される。XHMLTの例では、XHTMLによりダブリンコアを表現するためのガイドラインに合わせるために、'KEV'と名付けられたスキーマ'info:ofi/fmt:kev:mtx:'の要素'ctx'として参照されている。必要な宣言は例5の冒頭に示されている。

ダブリンコア抽象化モデル[11]規約では、dcterms:bibliographicCitationプロパティの値は、KEV ContextObject符号化スキームに従って符号化された文字列値である。これはリソース識別子になることを意図していない。雑誌論文のリソース識別子としては、おそらくDOIなどの適切なURIスキームを使用することになるだろう。

例 4. 雑誌論文用のContextObjectのキーとその値

例 5. 雑誌論文用の書誌引用ダブリンコア・プロパティ

<link rel="schema.DCTERMS" href="http://purl.org/dc/terms/" />
<link rel="schema.KEV" href="info:ofi/fmt:kev:mtx:" />

<meta name="DCTERMS.bibliographicCitation" 
content="Library and Information Science Research 22(3), 311-338" />

<meta name="DCTERMS.bibliographicCitation" scheme="KEV.ctx"
content="&ctx_ver=Z39.88-2004
&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal
&rft.jtitle=Library+and+Information+Science+Research&rft.stitle=LISR
&rft.volume=22&rft.issue=3&rft.spage=311
&rfr_id=info%3Asid%2Fmimas.ac.uk%3Azetoc" />

<link rel="DCTERMS.isPartOf" href="urn:ISSN:0740-8188" />

[注: 'content'値内の改行は、例示目的で追加したものである。ContextObjectは改行なしの単一行でなければならない。]

例 6. 会議論文用のContextObjectのキーとその値

例 7. 会議論文用の書誌引用ダブリンコア・プロパティ

<link rel="schema.DCTERMS" href="http://purl.org/dc/terms/" />
<link rel="schema.KEV" href="info:ofi/fmt:kev:mtx:" />

<meta name="DCTERMS.bibliographicCitation" 
content="Proceedings of the International Conference on 
Dublin Core and metadata for e-communities, 2002;
DC-2002: Metadata for e-Communities:
Supporting Diversity and Convergence, Florence, Italy, 13-17 October 2002, pp 71-80" />

<meta name="DCTERMS.bibliographicCitation" scheme="KEV.ctx"
content="&ctx_ver=Z39.88-2004
&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook
&rft.btitle=Proceedings+of+the+International+Conference+on+Dublin+Core+and+
metadata+for+e-communities%2C+2002%3B+DC-2002%3A+Metadata+for+e-Communities
%3A+Supporting+Diversity+and+Convergence%2C+Florence%2C+Italy%2C+13-17+October+2002
&rft.spage=71&rft.isbn=8884530431&rfr_id=info%3Asid%2Fmimas.ac.uk%3Azetoc" />

[注: 'content'値内の改行は、例示目的で追加したものである。ContextObjectは改行なしの単一行でなければならない。]

2.4 参照の引用

勧告 5. リソースによる参照の引用情報を記録するには dcterms:references を使用すること。

記述したリソースにより参照された別のリソースの書誌詳細は、dc:relationの要素詳細化である dcterms:references プロパティの値として記録することができる。dcterms:bibliographicCitationの値を符号化するための上記勧告3および4を dcterms:references の値にも適用する。ただし、可能であれば、引用元のリソースにおける参照文を正確に写すことになるので、参照されるリソースのタイトルや著者など、さらに詳細な情報が含まれるだろう。例8は、2つの参照を含む雑誌論文のメタデータを表形式で示した。例9と10は各々、1つの雑誌論文への参照をXHTMLで符号化した例で、例9はプレーンテキストによる引用を、例10はOpenURLのContextObjectとして符号化された文字列値を示したものである。

リソース自体の書誌詳細とは異なり、参照は、人間が読むためのプレーンテキスト引用か、あるいは、機械が読むためのOpenURLのContextObjextのいずれかで提供されるべきである。これらの両方を提供することは正しくない。1つの参照に2つの異なる符号化インスタンスを関連付ける方法が存在しないからである。

例 8. いくつかの参照を持つ雑誌論文

OpenURLのContextObjectがURLエンコードされていないことと、わかりやすいように改行を入れてあることに注意のこと。

例 9. プレーンテキストによる引用としてXHTMLに符号化した雑誌論文の参照

<meta name="DCTERMS.references" 
content="Apps , A., MacIntyre, R. zetoc: A Dublin Core Based Current Awareness Service. 
Journal of Digital Information (2) (2002)" />

例 10. OpenURLのContextObjectとしてXHTMLに符号化した雑誌論文の参照

<link rel="schema.DCTERMS" href="http://purl.org/dc/terms/" />
<link rel="schema.KEV" href="info:ofi/fmt:kev:mtx:" />

<meta name="DCTERMS.references" scheme="KEV.ctx"
content="&ctx_ver=Z39.88-2004
&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal
&rft.aulast=Carnall&rft.auinit=D
&rft.atitle=Website+of+the+week%3A+Email+alerting+services 
&rft.jtitle=British+Medical+Journal
&rft.volume=324&rft.spage=56&rft.date=2002" />

[注: 'content'値内の改行は、例示目的で追加したものである。ContextObjectは改行なしの単一行でなければならない。]

3 シンプルダブリンコアにおける書誌引用

シンプルダブリンコアにおいて書誌引用を提供するための勧告は存在しない。シンプルダブリンコアは、プロパティの値を制約する符号化スキームや統制語彙の概念を含んでおらず、全ての値はプレーンテキストの文字列値であると見なされている。そのため、ローカル的な取り決めを除いて、シンプルダブリンコアにおいて機械可読な詳細情報を提供することは不可能である。シンプルダルリンコアによる記述において、書誌引用情報を次のいずれかに含めることが提案されている。

• この情報はリソースを実際上識別するものであり、dcterms:bibliographicCitation は dc:identifierの要素詳細化であると認識されることから、文字列値として dc:identifierに。さらに、このテキスト文字列が勧告 3に従うことも提案されている。
• リソース記述の一部として dc:descriptionに。

例11に示したように、プレーンテキストによる引用と並行して、機械が理解できる可能性をいくらかでも提供する（保証するものではない）ために、KEV OpenURL ContextObjectをシンプルダブリンコアの dc:identifierプロパティの値として含めることができるだろう。DCMI抽象化モデルの文書の付録Dに示されているように、XHTML符号化で使用される場合は、人間の目にはURIあるいはその一部のように見えるとしても、DC.identifierの値は文字列値である。

例 11. 雑誌論文用のシンプルダブリンコアにおける書誌引用

<meta name="DC.identifier" 
content="Library and Information Science Research 22(3), 311-338" />

<meta name="DC.identifier"
content="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal
&rft.issn=0740-8188&rft.volume=22&rft.issue=3&rft.spage=311&rfr_id=info%3Asid%2Fmimas.ac.uk%3Azetoc" />

[注: 'content'値内の改行は、例示目的で追加したものである。ContextObjectは改行なしの単一行でなければならない。]

シンプルダブリンコアで記述されたリソースにより参照された別のリソースの引用情報は、dc:relationプロパティの文字列値として記録することができるだろう。これもまた、文字列値として提供されるKEV ContextObjectを使って記録できるだろう。

例 12. OpenURLのContextObjectとしてXHTMLに符号化したシンプルダブリンコアにおける雑誌論文の参照

<meta name="DC.relation"
content="ctx_ver=Z39.88-2004
&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal
&rft.aulast=Carnall&rft.auinit=D
&rft.atitle=Website+of+the+week%3A+Email+alerting+services 
&rft.jtitle=British+Medical+Journal
&rft.volume=324&rft.spage=56&rft.date=2002" />

[注: 'content'値内の改行は、例示目的で追加したものである。ContextObjectは改行なしの単一行でなければならない。]

4 書誌引用のXMLによるエンコーディング

書誌引用情報をXMLにより符号化する勧告は将来の文書で提供される予定である。

序論で示唆したように、複雑なXMLメタデータ記述を必要とする応用については、特に書誌アイテム向けに設計された他のメタデータスキーマ、たとえば、OpenURLフレームワーク[1]やPRISM[2]、MODS[3]、NLM Data[4]などがより適しているだろう。

5 その他の問題

ダブリンコアで書誌引用情報を記述することに関連するいくつかの問題が他に確認されている。

5.1 著者の所属

勧告 6. 著者の所属は、dc:contributorを使って記録すること。

書誌リソース、特に雑誌論文にとって、著者の所属は、リソース記述のためだけでなく、リソース発見（たとえば、「マンチェスター大学の構成員により発表されたマグネシウムに関する全ての論文を見つける」）のための情報としても重要な項目である。雑誌論文や会議論文の所属はリソースに付随するものである。それは、そのリソースを作成した時の著者の所属であり、たとえ著者が別の機関に移ったとしても変わることはない。したがって、それは著者の属性というよりむしろリソースの属性である。著者の所属機関はリソースの作成に貢献したと認識されることから、この所属はdc:contributorプロパティの値として記録することが提案された。所属は作者というよりむしろリソースの属性であるので、（複数の著者が存在する場合に）特定の著者にその所属を関連付ける方法がないという事実は問題ではない。

例 13. 著者の所属を含む会議論文のダブリンコア記述

5.2 識別子

勧告 7. グローバル識別子はURIとして符号化すべきである。

書誌リソースに関連する様々なグローバル識別子が存在する。たとえば、逐次刊行物のISSNや図書のISBN、SICI（Serial Item and Contribution Identifier）、DOI（Digital Object Identifier）などである。これらは、ダブリンコア・プロパティの値において、URI値として符号化されるべきである。表1にこれらの識別子の一部をリストアップした。これらの識別子の一部は新しいURIスキームである'info'[12]を使用している。このスキームが導入されるまで、書誌リソースで一般的に使用されていたこれらの識別子のためのグローバルなURI名前空間は存在しなかった。

表 1. 書誌リソースのための識別子

5.3 電子版のみの論文

雑誌論文の書誌引用情報を記述するための上記の勧告は、論文が印刷された雑誌で出版され、該当号において開始ページで特定されることを前提としている。現在、大多数の雑誌論文は電子的に利用可能であるが、いまだに、開始ページという概念を持つ発行物としてパッケージ化されている（実際、いまだに電子版だけでなく印刷版も出版されている）。しかし、次第に、並行する印刷版を持たない「ボーンデジタル」な電子ジャーナルが現れてきており、これらにはページ付けという概念が存在しない。また、急速に進展している分野の雑誌論文には、掲載号が確定される前に発表されるものもある。したがって、電子版のみの雑誌論文を記述するためには、掲載号での、あるいは独立した、何らかの論文識別子が必要である。この識別子は個々の論文やその発表状況によって決定されるだろう。刊行物として出版された電子ジャーナルの論文は、例14に示すように、その号における何らかの論文識別子を持つだろう。電子論文の中には、可能であればDOIなどの識別子や論文を読むことのできる場所を指定するURLで記述した方がよりふさわしいものもあるだろう。

例 14. 電子ジャーナル論文用の書誌引用

5.4 リソース種別

書誌アイテムのリソース種別（たとえば、雑誌論文や会議論文など）を示すのは望ましいことであろう。dc:typeプロパティを使い、その値として認められている語彙から選んだ語を指定することが提案されている。

例 15. 雑誌論文を示すリソース種別

<meta name="DC.type" scheme="DCTERMS.MESH" content="Journal Article [Publication Type]" />

5.5 DCMI引用作業部会による以前の提案

DCMICiteダブリンコア構造化値は非推奨である。

DCMI引用作業部会は、その任期中に、人間にも読め、機械がパース可能な形式で書誌引用情報を記録するためにダブリンコア構造化値（DCSV: Dublin Core Structured Value）であるDCMICiteを提案した。この提案の複数の版が様々な文書で発表され、主にそれに続く勧告がなかったという理由で、いくつかの実装で使用された。この提案は、今後非推奨であり、ローカルアプリケーションを除いて使用すべきではない。DCMICiteはDCMI利用委員会には承認されていなかったので、DCMICiteの使用は将来の相互運用性を保証できない。提案は、これも非推奨の構文であるDCSVに基づいていた。書誌引用を記述するにはもはやそれは必要ない。今や、それに代わるOpenURLフレームワークメタデータフォーマットが利用できるからである。

付録 A. 文脈依存サービスのためのOpenURLフレームワーク

「文脈依存サービスのためのOpenURLフレームワーク」は、ANSI/NISO標準 Z39.88-2004[1]である。この標準は、被参照リソースを、参照コンテキストを構成する関連リソースとともに記述する方法を提供する。このパッケージは「ContextObjext」と呼ばれる。また、この標準は、ネットワーク上のシステム間でこれらの記述を転送する方法である「OpenURL」の種類も定義している。ContextObjextはOpenURLの「ペイロード」であるが、自立したデータオブジェクトになることも可能である。

通常、デジタルライブラリのコンテキストでは、利用者は、HTMLページにあるOpenURLリンク、たとえば、電子ジャーナル論文の参照リストの引用文のそばにあるOpenURLリンクをクリックする。参照のOpenURLはリンキングサーバあるいはリゾルバに渡され、これらは利用者に、可能であれば論文フルテキストの適切コピーへのリンクを含む、引用された論文に該当するリソースの選抜を返す。

ContextObjectは最大6つまでのエンティティを含むことができる。そのうちの1つ「被参照体（referent）」は、参照されたリソースについての情報を持つ。これは常にContextObjectに含まれなければならない。その他の5つのエンティティは、参照を行ったリソース（参照体: referring entity）、利用者（リクエスタ: requester）、リクエストの送り先のサービス（リゾルバ: resolver）、OpenURLを生成したサービス（リファラ: referrer）、リクエストされたサービス種別である。

ContextObjectにおいて、各エンティティに関する情報は4つの方法で詳述することができる。まず、指定された名前空間の識別子はリソースを定義する。次に、「値による」あるいは「参照による」符号化を行った一組のメタデータでエンティティを記述することができる。その違いは、「値による」メタデータ記述はContextObjectの中に含まれており、「参照による」メタデータ記述はContextObjectで指定されたURIという他の場所にあることである。4番目の方法は、未定義の私的データであり、この場合は事前にリゾルバとリファラの間で合意を得る必要がある。

エンティティは、「キー/符号化値」（KEV: Key/Encoded-Value）フォーマットあるいはXMLのいずれかで符号化することができる。KEVは、「アンパサント（＆）」区切りのペアの文字列であり、各ペアは「等号（＝）」で分けられたラベル（キー）とその値で構成される。値は「URLエンコード」される。これは、HTTPにより転送される際に誤って解釈されないように、特定の文字を同等な16進バイト列に変換することを意味する。

OpenURLフレームワークは極めて汎用的であり、多くの応用分野やコミュニティで使用される可能性を持っている。その中心となる要素はOpenURLレジストリ[7]で定義されている。レジストリは識別子名前空間やメタデータフォーマットのリストを含んでいる。レジストリから特定の応用分野にふさわしい整合性のある要素の組み合わせを選択したものが「コミュニティプロファイル」であり、これもレジストリに定義されている。

OpenURLフレームワークに関するさらなる詳細や説明はKEV実装ガイドライン[10]や標準[1]それ自体で見ることができる。

参考文献

• [1] ANSI/NISO Z39.88-2004, The OpenURL Framework for Context-Sensitive Services. http://www.niso.org/standards/standard_detail.cfm?std_id=783
• [2] PRISM: Publishing Requirements for Industry Standard Metadata. http://www.prismstandard.org/
• [3] MODS: Metadata Object Description Schema. http://www.loc.gov/standards/mods/
• [4] NLM Data. http://www.nlm.nih.gov/bsd/licensee.html
• [5] DCMI Citation Working Group. http://www.dublincore.org/groups/citation/
• [6] Citation Styles (a DCMI Citation Working Group resource available via its web page).
• [7] Registry for the OpenURL Framework. http://www.openurl.info/registry/
• [8] The OpenURL Framework Key/Encoded-Value Journal Metadata Format. http://www.openurl.info/registry/docs/mtx/info:ofi/fmt:kev:mtx:journal
• [9] The OpenURL Framework Key/Encoded-Value Book Metadata Format. http://www.openurl.info/registry/docs/mtx/info:ofi/fmt:kev:mtx:book
• [10] NISO Committee AX and Apps, Ann. (2004) Z39.88-2004: The Key/Encoded Value Format Implementation Guidelines. http://www.openurl.info/registry/docs/implementation_guidelines
• [11] Powell, Andy, Nilsson, Mikael, Naeve, Ambjön and Johnston, Pete. (2005) DCMI Abstract Model. http://www.dublincore.org/documents/abstract-model/
• [12] The 'info' URI scheme. http://info-uri.info/