電子情報資源のページへ戻る

電子情報資源管理
DLF/ERMイニシアティブ報告書

Copyright 2004 Council on Library and Information Resources 本出版物を出版者の許可なく何らかの形で複製・転写することは、たとえ一部であっても禁止する。複製の依頼は図書館･情報資源協議会広報部長に行うこと。

緒言

デジタル図書館連盟（Digital Library Federation: DLF）は33の会員と5つの協力組織からなるコンソーシアムであり、電子情報技術を利用して図書館のコレクションやサービスを拡大するための先駆的な取り組みを行っている。我々は加盟館の図書館員と技術者が英知を結集して共通する重要な問題に対処する能力に誇りを持っている。電子情報資源管理イニシアティブ（Electronic Resources Management Initiative: ERMI）はそのような共同作業の1つであり、図書館やシステムベンダー、標準化組織がその成果をまさに必要としているタイムリーで広範囲にわたる活動である。

このイニシアティブが取り組む問題は多岐にわたる。図書館がライセンスを要する電子情報資源を収集する場合、その処理に関する財政的・法的側面およびアクセス上の問題について理解し、同僚や利用者などに伝達し通知しなければならないからである。出版者はこのような情報を様々な文書や電子媒体で図書館に通知するので、収集とライセンス処理の過程は複雑である。また、図書館が収集するライセンス契約の電子製品の数は急速に増加している。このような状況下では、各図書館で独自のその場限りの処理が行われる恐れがある。これに対し、DLF/ERMIは、本報告書で見られるように、ライセンス契約、関連する管理情報、ライセンス契約の電子情報資源に関する内部処理を管理するための共通仕様を策定することにより、組織的な解決策を作成した。

草稿の段階ですでに、本報告書に対する反応は早く満足のいくものであった。図書館システムの主要なベンダーには図書館システムに追加するライセンス管理機能を設計する際に既にERMI報告書の勧告が知らされていた。学術出版社や商業出版社に広く採用されているメタデータスキームであるONIXの開発者は、ライセンス表現の要件を検討する際にERMIの採用を詳細に調査している。また、英国の全国逐次刊行物総合目録（SUNCAT）は開発中の全国サービスにおいて、ライセンスを表現･保管する方法を模索する中でERMIをテストを行っている。

目次

先頭に戻る

要旨

電子情報資源を図書館のコレクション、サービス、運用の一部に組み込む際、ほとんどの図書館は既存の図書館システム（ILS）がこの新しい情報資源をサポートする能力に欠けていることに気が付く。Jewellによる2001年の調査 [1]は、この不足を補うために多くの図書館がローカルシステムの開発に着手していたことを報告している。そのようなシステムの迅速な開発を支援するために、デジタル図書館連盟（DLF）電子情報資源管理イニシアティブ（ERMI）が組織され、要件を定義しデータ標準の確立を支援するための相互に関連する一連の文書を作成した。

2002年5月に開催された米国情報標準化機構（NISO）とDLFによるワークショップの結果、ERMIの作業を指導する運営グループが発足した。さらに、DLFは、図書館員、図書館システムベンダー、関連組織の代表を招待して2つのプロジェクト諮問グループを発足させた。運営グループはこれら2つの作業パネルのメンバーと共同で文書の原案を作成した。原案は、コーネル大学に置かれた電子情報資源管理のための管理メタデータ作成作業用のWebポータルにおいて公開された。

本文書は、運営委員会が作業期間中に作成した報告書と複数の付録から成る。報告書自体は、電子情報資源管理（ERM）のためのロードマップを提供することをめざした。報告書ではERMシステムの要件について概略を述べ、マサチューセッツ工科大学（MIT）やカリフォルニア大学ロサンゼルス校（UCLA）、ジョン･ホプキンス大学（JHU）などの機関に既に存在するシステムについて画面を示しながら検討する。付録Aでは実効的なERMのために必要なおよそ50の機能要件の詳細をまとめる。付録Bでは紙媒体の情報資源と電子情報資源を処理する各々のワークフローの主要な相違点を示す図を提供する。また、この付録には電子情報資源のライフサイクルに固有のフェーズを示す図が含まれている。

付録C、D、Eは互いに密接に関連している。付録Cはデータ要素のグループが互いにどのように関連しているかを示す実体関連図である。付録Dは300を超える要素を網羅したデータ辞書である。付録Eはデータ構造、実体によるデータ要素のグループ化、および、その機能要件への関連付けを扱っている。最後のXMLの調査では、既存のいくつかの権利表現言語（Rights Expression Language: REL）を比較・検討する。その結果、ライセンス管理で鍵となる用語を記述する標準化されたXMLベースの方法を持つことは、図書館や出版者、ベンダーにとって望ましいことではあるが、既存のRELやスキーマで大きな変更なしに実用に供せるものはないことに注目する。そして、この必要性を満たすために、ERMIデータ辞書に基づいたERMのネイティブスキーマの作成を提案する。

ERMIの作業は、図書館員とベンダーの両者から非常に好意的に受け止められ、大部分が本報告書や付録に基づいているシステムを既に開発中の者もある。さらなる作業が必要な分野としては、コンソーシアムのための機能要件、利用データの組込みと報告のための仕様、さらなるデータ標準の策定があげられる。

先頭に戻る

報告書

1. はじめに: 包括的電子情報資源管理システムの必要性

数年前、コーネル大学図書館はその戦略的計画において、2005年までにその図書館システムは「ほとんどデジタル環境」になるという大胆で驚くべき予想を行った（コーネル大学図書館 2000）。この予想がコーネル大学において的中するのかどうか、また他のほとんどの図書館にも適用できるようになるのかどうかはともかくとして、電子情報資源（以後、電子資源と呼ぶ）に費やす経費が通常そのような資料を含む資料購入予算に比べて急速に成長していることは研究図書館協会（ARL）の支出傾向データから明らかである。2001/2002年度において、ARL加盟の少なくともいくつかの図書館が既に資料購入予算の半分を電子資源に費やしている（ARL 2002,2003）。図書館は今、電子資源依存環境に向けた急速な移行過程の渦中にある。そして、オンラインアクセスを確保するために冊子体の雑誌購読を削減しているように、この依存性はこの1、2年の内にさらに深くなってきたと思われる。

一方、利用者の行動や考え方はさらに急速に変化していると思われる。たとえば、アウトセル社が行った学術情報環境に関する最近の調査では、半数近くの学部学生が電子資源のみ、あるいはほとんど電子資源のみを使用していることを示している（Friedlander 2002）。同調査はまた、多くの教官や大学院生がさらに多くの雑誌を電子的に利用したいと考えていることを示した。しかし、多くの図書館員が立証できるように、電子資源へのさらなるアクセスの要求は物語の一部に過ぎない。今や利用者は図書館サービスをGoogleサーチエンジンやAmazon.comといった最近登場した革新的サービスと比較しており、これらと同程度の単純さ、能力、利便性を図書館が提供することを期待している。

これらの発展は、電子資源コレクションの管理を首尾よく行うという、ますます複雑になり気が遠くなるような挑戦であると多くの図書館員が考えるような状況を生み出す。DLF加盟図書館における業務を調査した先の研究において、Jewell（2001）は、これら図書館がライセンス契約の電子資源を選択・収集し、それらに関する情報を利用者に提供する方法にある顕著な傾向があることを発見した。今回の考察において最も重要なことは、おそらく、回答したほとんどの図書館が既存の図書館システムがこれらの機能をサポートできないことに気付き、そのギャップを埋めるために独自の自動化ツールの設計・開発を開始したことである。

これらのシステムが取り組もうとした管理上の基本的な課題の1つは、ますます大規模化する書誌データベースを記述し、その情報を利用者に提供する必要性である。もう1つの課題は新しい情報資源の性質と特性に由来する。たとえば、現在ほとんどの図書館はアグリゲータデータベースに多額のお金を費やしている。EBSCOやGale、LexisNexis、ProQuestといった会社が提供するこれらのデータベースは、数多くの逐次刊行物のコンテンツ、あるいはコンテンツの一部へのアクセスを提供している。このようなコレクションは通常大きな利便性を提供するが、これらのデータベースがどの雑誌のどの範囲をどのような形式で、また、どの程度の最新性または網羅性で提供するかを確実かつ定期的に確定することは達成しがたい目標となっている。電子ジャーナルとデータベースの発展は図書館資料の収集やサービスに関わる処理を複雑化し、変容させたが、この問題を大きくするものでもあった。

先に引用した2001年のDLF報告書では、利用者には通常、資料について解説したり資料を発見し易くするように、アルファベット順や主題別の電子資源リストが提供されていることが記されている。これらのグループではアグリゲータデータベースが定番となり、多くの図書館はそのコンテンツを購読している電子ジャーナルと共にリスト化することを開始した。DLF報告書のための調査が行われた後、Serials SolutionsやTDNet、EBSCOといった会社がこれらのニーズを満たすことを目的とするサービスの提供を開始した。しかし、これらのサービスを完全にサポートしたり、連携をとることができる図書館システムはほとんどなかった。この数年、図書館はデータベースベンダーの独自ソルーションやより一般的な標準に基づいたツールであるEx Libris社のSFXを通じて、これらのインデックスとフルテキスト資料とのリンク付けを開始した。これは利用者に大きな利便性をもたらすものであるが、電子資源管理の複雑性に新たな層を追加するものでもあった。

利用者の目に触れることはほとんどないが、別の変化も生じている。電子資源が普及するにつれ、その適正な利用を定義し決定付ける基礎として正式なライセンス契約が著作権を補完したり、優先したりする存在になってきた。歓迎すべき有望なモデルライセンス（Cox 2000; Council on Library and Information Resources 2001）やその他のライセンス条項標準化の取り組みが現れたが、図書館はライセンス条項の点検や交渉に多大な時間と労力を費やすようになっている。ライセンスを与える側、受ける側で様々なレベルの職員が関わるようになると、各図書館でのライセンス交渉は複雑で長期にわたるものになるだろう。その結果、個々の交渉状況を逐次記録し、重要なライセンス条項を記述し、これら条項を利用者や職員に公開する特別な活動を行う図書館が出てきた。

同時に、図書館は他の図書館とコンソーシアムベースの複雑な購入協定を結ぶようになってきている。これらの協定は継続的な費用分担と新たなコミュニケーション、評価、意思決定プロセスにより特徴付けられる。これらの情報資源は、一旦受け入れると特別な技能や新たな種類の情報によりサポートする必要がある。電子資源の複雑さや利便性に対する利用者の期待を理解するにつれ、図書館はWebサイトを通じてその使用法やその他の専門的な情報を利用者に直接提供するようになった。

2001年のDLF調査において明らかになった新しい電子環境のもう一つの特徴的な側面は、大規模図書館では部署の異なる多くの職員が電子資源の選択、支援、評価において新たに専門的で重要な役割を果たすようになったことである。これら職員のほとんどは幅広い専門的な情報を必要とした。たとえば、様々な部局の職員は収集やライセンス処理の過程にある特定の資料の状態を知る必要があるだろう。また、別の者は、アクセス法の詳細や、特定の資料に関係するアクセス障害が生じているか否か、特定の障害対策が誰の担当であるかを知る必要があるだろう。電子資源の計画的かつ周期的な評価を行い、これらを念頭に置き、その利用に関する入手可能なあらゆる情報を体系的に収集して報告することを開始した図書館も登場した。

2. 現在行われている電子情報資源管理システム構築の取り組み

図書館におけるERMシステムへの関心の高まりを受けて、Jewellとコーネル大学のAdma Chandlerは2001年にWebポータルを立ち上げ、ローカルシステムに関する情報の交換や関心を持つ図書館員の交流を促した。ローカルシステムが判明すると、システムの開発に参加した図書館員にシステムの機能やデータ要素について系統的な質問を行った。要素は分析され、先に示したDLF報告書にまとめられた（Jewll 2001, p. 26）。次の7つの機能分野 ――― リスト化と記述、ライセンス関連、財政と購入、処理と状態、システムと技術、連絡とサポート、利用統計 ――― が特定された。また、非公式な議論では、これらの機能をサポートする機能記述、要素名、定義の標準化の意義に関心が持たれるようになった。

1、2年以内に、およそ20の図書館とベンダーがそのようなシステムを開発する、または、開発する予定があることを発表した（表1）

各図書館で開発されたシステムはその大学固有の要件や開発上の制約を反映しているが、多くのシステムは創造的で注目すべき機能を誇示している。ここではこれらシステムの包括的な評価を行うのではなく、いくつかのシステムが持つ機能に焦点を絞って検討する。その目的は、電子資源を管理するための理想的かつ実現可能なシステムの要素の特定に着手することである。

1999年に構築されたペンシルバニア州立大学図書館のERLIC（Electronic Resources Licensing and Information Center）は比較的限られた要求に対応するために設計されたが、その後その機能が抜本的に拡張されたシステムの好例である（Penn State Libraries 2001）。ERLICはMicrosoft Accessを使って開発された発注状態の追跡と購読更新処理を行うシステムであったが、ERLIC2となった今では、発注、アクセス、認証、ライセンス情報を集中的に扱うシステムへと進化している（Stanleyら 2000; Alan 2002）。MIT図書館のVERA（Virtual Electronic Resource Access）もペンシルバニア州立大学とほぼ同時期に開発され、幅広い機能を有している（Duranceau 2000a; Duranceau 2000b; Hennig 2002）。VERAは「事務管理部門」の職員向けの機能と要件に対する幅広いサポートと数多くの注目に値する公開用Webページデザインを提供している。イェール大学のライセンス条項の体系的な取扱い方と一般への公開は、同じ問題に対するMITのアプローチを補完するものであり興味深い。

ERLICやVERA同様、UCLAのERDbシステムも幅広い機能を提供する目的で開発された。その機能と画面デザインは非常に興味深く後で詳しく検討するが、関連する作業用文書（Farb 2002）では、ERMシステムの開発に一般的に適用可能な有益なガイドラインを明確に述べている。このガイドラインによれば、システムは次の要件を満たすべきである。

• 成長への対応
• 柔軟性をもたらす設計
• 「1つのデータベースで多彩な見せ方」を提供
• 不要な重複の回避
• 段階的実装が可能

同様に幅広い対象を持つのがジョン･ホプキンス大学のHERMES（Hopkins Electronic Resource Management System）である（Cyzyk and Robertson 2003）。PostgreSQLとCold Fusionを使用して作成されたHERMESは最近オープンソースとして利用可能となった。HERMESはそのような機能を公開Webページの動的な生成により提供することを意図しているが、何より興味深いのは、システムに組み込まれた職員の役割やワークフロー、関連する機能要件に対する注意深い分析である。同様に取り上げる価値のあるシステムがコロラド研究図書館連合の開発したGold Rushである（Stockton and Machovec 2001）。Gold Rushは電子資源の購読管理に関する数多くの機能を組み込んだ初の商用システムであった。Gold Rushは妥当な価格であり、個々の図書館と図書館コンソーシアムの両者をサポートするので、中央のコンソーシアム管理者は会員図書館に電子資源に関する幅広い情報を持つレコードを「押し付ける」ことが可能である。

3. 機能と例

3.1. ライフサイクルから見た概要

記録管理とは「そのライフサイクルの様々な段階（作成または受入で始まり、処理・配布・維持・利用を経由し、最後には廃棄にいたる）における組織上のすべての記録を体系的に管理すること」と定義されている（Robekら 1996）。電子資源の効率的な管理は、少しずつ異なるライフサイクルに沿った幅広い機能を実行できるか否かにかかっている。たとえば、現在のところ、図書館は通常ライセンス契約の電子資源の生産には関与していないが、新しい製品やサービスの評価を行う必要がある。また、簡略的な記録管理のライフサイクルモデルと電子資源のためのライフサイクルモデルの間には非常に密接な類似関係が存在する。

表2に、電子資源の管理で行われる数多くの作業とライフサイクルの様々な局面に関与する職員の概要を示した。表は、HERMESの職員利用者が利用できる機能と報告書に基づいており、大部分はDLF電子情報資源管理イニシアティブ（ERMI）のワークフロー手順にしたがっている（付録B参照）。列タイトルはジョン･ホプキンス大学の職員が果たしている5つの役割: 選書担当者、選書管理者、収集管理者、図書館システム管理者、公開画面管理者、を示している。各役割について、次に説明する。

1. 製品の検討と試行プロセス。ジョン･ホプキンス大学では、選書担当者が資料の特定、試行の必要性の有無の決定、予備的なライセンス情報の収集を担当する。必要であれば、収集管理者が試行ライセンスの交渉を担当する。選書担当者は試行の結果に基づいて処理を進めるか否かを提案し、選書管理者はそれを承認または否認する。この段階において、試行用のURLやパスワード、広報といったその他の詳細が確定し、記録される。

2. 収集プロセス。このプロセスには各々極めて異なる3つのサブプロセスが存在する。これらのサブプロセスは同時に進行することもある。ジョン･ホプキンス大学では、収集管理者がライセンス交渉と関連情報のHERMESへの入力を担当している。システム管理者は技術上の実現可能性を判断し、処理続行の認否を決定する。この他に残っている作業は資金調達と購入に関連するものであるが、これも収集管理官の担当である。

3. 提供プロセス。この段階では、認証の詳細が決定・記録され、データベース利用のための設定が行われ、情報資源とその関連要素の目録が作成され、Webページに組み込まれる。この段階における記述作業は、対象となる資源が電子ジャーナルや数多くの雑誌やその他のコンテンツを含むアグリゲーションパッケージの場合は、特に難しく時間のかかる作業になるだろう。Webページによる公開は数多くの方法で提供することができ、後で示すように、ライセンス条項に関する情報を職員や利用者に提供することもできるだろう。また、リンクリゾルバやプロキシサーバに資源を登録する必要もあるかもしれない。

4. 製品の保守と評価プロセス。この段階で重要な作業の1つは購読の更新である。購入期間を設定することにより職員に更新時期を知らせることが可能であるが、価格やライセンス条項の再交渉が必要な場合もあるだろう。もう1つの作業は、提供プロセスで行われた所蔵情報や利用範囲の保守である。更新プロセスに含まれる可能性のあるさらなる作業としては、利用データの収集と職員への提供、アクセスやその他の技術的な問題の特定とその解決があげられる。

表 2. ジョン･ホプキンス大学のHERMESにおける選書・収集に関する作業と役割および報告書

3.2. ERMシステムの例とその公開Web画面

3.2.1. 製品の検討と試行プロセス

先のライフサイクル、作業、役割一覧は、職員がERMシステムなどで実際目にする画面と完全に一致しないかもしれない。たとえば、HERMESにおける職員の役割に基づいて作成した表2に挙げられている機能を別のシステムにおける職員の役割にしたがって再編成して示すこともできるだろう。これは先に述べたUCLAの設計原則の1つ「1つのデータベースで多彩な見せ方」の価値を強調する。多彩な見せ方と同一情報の再組織化のもう1つの例は、MITのVERAの次の画面である（図1）。

図1

この画面では、収集（発注書番号とベンダー）、提供（URLと配置場所）、製品の保守と評価（更新日付、技術サポートの連絡先、利用統計データに関する情報）といったライフサイクルの様々な局面における情報がまとめて表示されている。これはおそらく、この画面を利用する職員がこれらの情報を同時に見る必要があるためであろう。

図2にUCLAのERDbシステムの画面を示した。リソース･スクリーンと呼ばれるこの画面には、電子資源のライフサイクルの複数の局面に関する情報が含まれている。情報資源のライフサイクル全般にわたって役に立ち、利用される基本的な識別情報と記述情報に加えて、選書情報（たとえば、出資部局や選書担当者）や収集情報（たとえば、ベンダーや発注書番号）も見ることができる。

図2

図3は同じくERDbの画面で、図2と同じ資料のライセンス･スクリーンを示したものである。UCLA担当のライセンサーまたは契約担当者に関する情報や編集済みの該当ライセンスへのリンクに加えて、ライセンスに含まれる特定の権利やその他の詳細について詳しく分析するためのスペースが提供されている。

図3

3.2.2. 提供プロセスと公開Webページ: アルファベット順・主題別の提供

図書館は通常、ライセンスを受けた情報資源に至る複数のルートを利用者に提供する。OPACへの登録、アルファベット順や主題別の一覧リスト、eリザーブ（Web上の取り置き機能）へのリンク、索引や摘要から該当するフルテキストに接続するリンクなどである。これらを作成する仕組みは通常一般には公開されていない。図4は、UCLAの利用者が図書館のゲートウェイページからオンライン資料へのリンクをクリックした際に表示される画面を示している。

図4

他の多くの図書館と同じように、UCLAも電子ジャーナルと論文データベースを区別している。したがって、その区別はUCLAのデータベース内で行う必要がある。UCLAのアァベット順（図5）と主題別（図6）の提供方法は他の多くの図書館と同じものである。

図5

図6

これらの画面の作成をサポートしているのは、ERDbタイトルビュー（図7）を通じて収集・保守されている資源に関する基本的な書誌データなどの情報である。まもなくリリースされる予定の別の画面では、ある特定の電子ジャーナルパッケージを構成するタイトルと親レコードを関連付けるものであり、これは、ライセンス条項を特定のタイトルに結び付けるなど、数多くの機能に必要なものである。タイトルビュー画面では、資源を主題（図8）や資料種別（図9）と結び付けることも可能である。

図7

図8

図9

3.2.3. 提供プロセスと公開Webページ: さらなる情報

UCLAのERDbシステムと同じように、MITのVERAもデータベースや電子ジャーナルの主題別（図10）やアルファベット順（図11）の一覧ページの生成に使用されている。VERAは、ロケーション別の電子資源利用の可否の記述や個々の資源固有のURLの生成と管理にも使用されている。

図10

図11

VERAが目的別のアイコンを使用することにより幅広い種類の情報を組み込んで提供している方法は特に注目に値する（図11の左下を参照）。たとえば、「Go」アイコンはその資源がMIT構成員には学外から利用可能であることを示している。「?」アイコンは検索ヒントやその他の文書に導き、「C」アイコンは特定の資源の使用法に関する講習会の情報に導く。また、万国共通の「否定」記号（赤丸に斜め線）は特定の資源のアクセスに障害が発生していることを示している。さらに注目すべきものは、VERAが行っているライセンス情報を組み込む方法である。資源リストの先頭に示されている資源の適正な利用と不正な利用に関する一般的な文言に加え、個別のライセンス関連情報がある場合は「L」アイコンが示されている。たとえば、図11はJSTORが提供する"Abstracts of the Papers Communicated to the Royal Society of London"を示しているが、ここに見られる「L」アイコンは、その使用法を定めたJSTORライセンスの主要な条項をまとめたページ（図12）に利用者を導く。

図12

イェール大学図書館の電子資源ページも使用法やライセンス情報を明確で理解しやすい方法でまとめている。たとえば、図13は、"Academic Universe"など社会科学系のデータベースのアルファベット順リストを示している。

図13

利用者が"Academic Universe"をクリックすると、図14のような追加情報が表示される。この画面には各種のヘルプツールに加えて、「許されるデータベース利用法」へのリンクが含まれている。

図14

「許されるデータベース利用法」リンクをクリックすると、図書館がライセンスを受けた情報資源の多くまたはほとんどについて許可されている利用法をまとめた非常に長い文書の内、その資源に相応しい部分を利用者に示す（図15）。

図15

この画面は少なくとも3つの理由で注目に値する。第1に、情報資源のライセンスを分析して8つの主要事項についてその利用が許可されているか否かを判定して、その結果を単純に「はい」「いいえ」で示している。第2に、表には各事項について必要に応じて拡張できるスペースが用意されている。第3に、契約条項全文へのリンクが可能である。この例では、リンクは利用者をLexisNexsのWebページに導いている（図16）が、機関固有のライセンス条項をデジタル化して利用者に見せることも同じように簡単にできるだろう。

図16

MITやイェール大学のライセンス情報の提供法に対して対照的で興味深い提供を行っているのがコロラド連合のGold Rushのスタッフ･ツールボックスである（図17）。MITやイェールの要約情報が各大学の図書館システム単独で利用されるよう設計されているのに対して、Gold Rushはシステムや特定の情報資源を共有するすべての図書館に要約したライセンス情報を提供することが可能である。

図17

3.2.4. 製品の保守と評価

製品へのアクセスが確立し、利用可能であることが職員や利用者に知られるようになると、いろいろな問題が生ずるだろう。たとえば、ベンダーや情報プロバイダが定期保守や予期しない技術上の問題を修復するためにサービスを一時的に、あるいは長期にわたって停止する必要が生ずる可能性がある。時には、購読者のIPアドレスが保存されているベンダー側のファイルで最新情報の更新に失敗したり、ファイルが壊れたりする可能性もあり、これにより購読しているサービスへのアクセスに影響を与えることになる。製品のインボイスや支払いの遅れにより契約の停止期間が、特に月初めに、生じる可能性がある。これらの問題は、ユーザ名やパスワードの要求や理解困難なメッセージなど様々な方法で明らかになる。さらに悩ましいのは、出版者の電子ジャーナルパッケージやアグリゲータサービスにおけるアクセス障害はそれに含まれているすべての雑誌に影響を与えるが、これらの雑誌はオンライン目録やWeb上で公開しているオンラインで利用可能な雑誌リストではバラバラに存在していることである。

これらの状況のどれか1つでも発生すると、職員や影響を受けた利用者とのコミュニケーションを図書館で効果的に管理することは困難であるか、不可能であろう。職員とのコミュニケーションを図る有望なアプローチの1つが、図18に示したUCLAのERDbシステムのステータス画面である。この画面の上半分は問題となっている情報資源の基本的な情報を示しており、下半分は、ユーザ名やIPアドレス、インターネットサービスプロバイダ、ブラウザなど、報告された出来事に関する情報、問題の記述、必要な処置、問題の現状を記録するスペースを提供している。

図18

上で述べたようなコミュニケーションの問題に対処するもう一つのアプローチを図19に示した。これはペンシルバニア州立大学のERLIC2で構想されている掲示板機能の模擬画面である。この機能により、ある時間にアクセス障害が発生したと思われる情報資源を利用者や職員が迅速に確認することが可能になると思われる。

図19

4. DLF/ERMイニシアティブ

4.1. 背景: プロジェクトの展開と組織

後にDLF/ERMIとなるプロジェクトは、JewellとChandlerにより構築されたポータルサイトに始まる。このポータルサイトが構築された当時、ALCTS（図書館コレクション・技術サービス協会）の大規模研究図書館技術サービス部門長ディスカッショングループでERMに対する関心が高まっており、2001年の米国図書館協会（ALA）の年次総会においてこの問題に関する非公式の会議を開催することが合意された。この会議にはおよそ40名の図書館員の参加があり、機能とデータ要素に関してさらに検討することになった。まもなく、Jewell、Chandler、UCLAのSharon FarbとAngela Riggio、ジョン･ホプキンス大学のNathan Robertson、ハーバード大学のIvy Anderson、イェール大学のKimberly Parkerから成る非公式の運営グループが形成された。このグループは、NISOのPatricia HarrisとPriscilla Caplan、（当時DLFの）Daniel Greensteinと共に作業を行った。これらの人々の間で考えうる標準について議論が行われ、最終的には2002年5月に開催された電子情報資源管理のための標準に関するNISO/DLFワークショップでの発表につながった。ワークショップにはおよそ50名の図書館員とEBSCOやEndeavor、Ex Libris、Fretwell-Downing、Innovative Interfaces、SIRSI、Serials Solutionsなど数多くのベンダーや出版社の代表が参加した。

ワークショップでは、ERMの性格と範囲に関する発表と議論に加えて、実体関連図（ERD）案やいつかのデータ要素リストが提出されて議論された。この会議の重要な成果の1つは、ERMシステムの開発の指針となるべき標準が本当に望まれているという合意が形成されたことであった。この確認により、ワークショップ運営グループは関連するベストプラクティスや標準を確立するためにより公式で協力的なアプローチを検討することになった。引き続き運営グループのメンバーが行ったそのような努力は、機関レベルの不要な経費や重複を減少させ、様々なシステムや組織間の相互運用性やデータ共有を支援し、さらには図書館コミュニティにも広範な利益を与えることになるだろう。

そして、運営グループはERMI発足の提案書を作成し、DLFに提出した。このプロジェクトの目的は、これまできわめて非公式かつ個別的に行われてきた活動を正式なものとし、さらなる形と方向性を提供することであった。その第1の目標は、個々の図書館やコンソーシアム、ベンダーによる電子情報資源を管理するシステムやツールの迅速な開発を促進することであった。より具体的には次のような事柄である。

• ライセンス契約の電子資源の大規模コレクションをシステムが効率的に管理するために必要な機能とアーキテクチャの記述
• それをサポートする適切なデータ要素と一般定義のリストの作成
• ローカルテストのための実験的なXMLスキーマ定義またはDTDの作成と公開
• 適切なベストプラクティスの特定とその普及
• データ交換を支援する適切な標準の策定とその普及

DLFは2002年10月に提案を受け入れた。2002年5月のNISO/DLFワークショップを組織した7名の図書館員がこの新しいイニシアティブの運営グループを形成した。運営グループの任務は既に始まっていた活動の継続であり、以下で説明する文書（すなわちプロジェクトの成果物）を作成することであった。

運営グループは2年間、毎週電話会議を行った。さらに、専門家の意見を継続的に受けるために、2つの作業パネル（諮問グループ）を形成した。パネルの1つは、ERMシステムに対する経験と関心においてとくに相応しいと考えられた図書館員により構成され（表3)、必要とされる様々な意見を提供する。

運営グループと図書館員作業パネルのメンバーは様々な方法でコミュニケーションを取った。まず、パネルと運営グループの何人かのメンバーはニューヨークで開催されたDLF2003年春季フォーラムに併せて開催された臨時会議に出席した。さらに、運営グループはMicrosoft社のSharePointを使ってUCLAにグループウェアサイトを構築した。このサイトは、文書案や作業リスト、次回開催会議や締め切りに関する情報の共有を容易にした。このサイトはパネルメンバーへの質問の投稿やそれに対する回答や意見を述べるスペースも提供した。作業パネルのすべてのメンバーがSharePointサイトを利用できるわけではなかったので、質問と回答はメールでも配布された。必要に応じて、運営グループはコメントや質問を寄せたパネルメンバーを電話会議に招待した。運営グループは議論やフィードバックにより問題に対する理解が大幅に高まることや多くの意見や質問により提出される文書がより洗練されることを知っていた。

2つ目のパネルであるベンダー作業パネルは、イニシアティブが取り組むべき問題に関心を示す図書館以外の幅広い組織の代表で構成された。このグループには数多くの統合図書館システム（ILS）提供プロバイダや図書館界にサービスを提供している会社の代表が参加している（表4）。

運営グループとベンダーパネルとの間のコミュニケーションには図書館パネルとは異なる方法を使用した。ベンダーグループには、様々なバージョンの文書案や図書館員パネルへの質問が提供されたが、当時はそのような文書に関するそれ以上のコミュニケーションは比較的まれだった。しかし、ベンダーパネルに代表を出している会社の多くは引き続きプロジェクトに強い関心を示していた。ILSベンダーは特に反応が良かった。多くの議論が運営グループメンバーと行われた。たとえば、Innovative Interfaces社（II社）は2002年の春からERMモジュールの開発に取り組んでいた。Tim Jewellは関連する議論に加わり、II社のデータ要素ができるだけ作業中のデータ要素と一致するように、データ要素に関する作業（以下を参照）の情報をII社に随時提供した。Ex Libris社も製品開発の準備のために本格的な分析作業を行っていた。Ivy Andersonはこれらの作業に多大な貢献をしたが、特に指針となる機能要件の記述への貢献が大きい。最近、Dynix社が開発事前会議を開催しNathan Robertsonが参加した。その後、同社は運営グループの作業を参考に将来のシステムのアーキテクチャを記述する内部向けの白書を作成している。

4.2. プロジェクト成果物とその使用のシナリオ

ERMIは数多くの文書を作成し、公開してきた。その全体的な目標は、図書館やベンダーが作業の基本として使用できる相互に関連する一連の文書を提供することにより経費を抑制し時間を節約することであった。しかし、文書はその他様々な用途で使用されることが期待された。文書とその想定した使用法は次のようなものである。

• 問題の特定とロードマップ。ロードマップの目的は、ERMに関する問題の概要を提示し、その解決のために図書館が採るべき創造的なアプローチの例を提供し、解決が必要な問題を明らかにすることである。
• ワークフロー図。詳細かつ汎用的なワークフロー図の作成は、運営グループの作業プロセスに対する理解を助け、それにより、その他の文書が適切かつ完璧に作成されるようにすることが期待された。ワークフロー図は各機関におけるワークフロー分析の基準となり、組織内のコミュニケーションを改善し、より合理的なプロセスに導くことが期待される。
• 機能仕様。この文書はERMシステムが提供すべき機能を明確かつ包括的に特定することを目的とした。図書館はこの文書を使用して購入したい機能あるいは独自に開発したERMシステムに組み込みたい機能を検討したり、業者への提案依頼書案の中でこれらの仕様を使用することができると思われる。
• 実体関連図。実体関連図（ERD）とは、設計者がデータ要素群（実体）とそれらの関係を概念化して表現することを支援する標準的なシステム開発ツールである。先に示したように、ERMのための実体関連図案がDLF/NISOワークショップで提案された。その改訂版は本イニシアティブ期間中の議論を明確化し、将来のシステム設計者を支援することが期待された。
• データ要素とその定義。実体とデータ要素の標準的なリストの提供により、開発者の時間は大幅に節約されることが予想される。このようなリストは、データ標準の策定にも役立つであろう。データ要素のリスト案がNISO/DLFワークショップで議論されたが、ERDに適合し、ERDを反映して編成された最終的な単一のリストを作成することが目的であった。自然に例えると（システム全体の略図としての）ERDは木に、データ要素はその葉に例えることができるだろう。
• XMLスキーマ。XMLスキーマはデータ交換用の方法を提供することにより実体と要素の標準リストの価値を高めることを目的とした。このようなスキーマは、異なるシステム間のライセンス情報共有化のテストを行うためのプラットフォームを提供するが、図書館やベンダーの開発作業をさらに促進することになるだろう。
• 最終報告書。最終報告者はこのような文書を1つにまとめて提供するものである。

ERMシステムにとって標準化の重要性とその潜在的価値は言うまでもない。この場合における標準確立の第一の動機は、ベンダーによるシステム開発のコストとリスクを減少させ、それにより開発プロセスを促進することである。さらに、ERMシステムは独立したシステムとして開発され販売されると考えられるが、雑誌システムや収集システム、オンライン目録、電子資源ゲートウェイといった既存のツールに組み込んだり、連携したりする必要があると思われる（Warner 2003）。したがって、様々なデータストリーム間で予測可能な通路を確立することが非常に重要である。既に独自のシステムを開発した図書館や近い将来開発したいと考えている図書館も、最終的にはベンダーシステムにデータを移行したいと考えるかもしれない。標準に対する合意がなされていれば、図書館は自らのシステムを標準にしたがって開発・改造・調整することができ、システムやデータの移行への道を開くことができるであろう。最後に、そうするための標準的な方法が提供されれば、図書館はライセンス情報を仲介業者と交換したり、特定の電子資源がILLのような特別な用途に使用できるか否かを記載するシステムを作成したりすることが可能になるだろう。

これらの検討を経て、運営グループはその作業に相応しい、あるいは関連する標準の策定状況の調査・監視を開始した。FarbとRiggio（2004）は、その調査結果を次のようにまとめている。

我々は、様々なコミュニティや団体の問題に対処するために設計された新しいメタデータスキーマや構造、標準について次々と学習している。しかしながら、現在のところ、ライセンス契約の電子資源の長期にわたる収集・管理の動的で多面的、かつ法的な性格に対応できるものは存在しない。

表5は、計画中のDLF/ERMIメタデータスキーマの適用範囲とERMの特定の側面に取り組んでいるいくつかの他のメタデータスキーマを大まかに対応させたものである。最初の7カラムは標準により取り扱う必要のある一般的な機能分野を示している。一番右のカラムは各規格が特定の企業の著作物であるか否かを示しているが、これは、図書館やその他の利害団体にとっての潜在的価値を決める重要な要素であると運営グループは考えている。「DLF/ERMI」と名付けられた行は、「利用統計」に対する関心は他のカテゴリに比べてやや劣るが、ERMIの活動は7つのすべての機能分野について本格的に取り組んでいるという運営グループの評価を示している。関連の標準化作業は少数の分野（たとえば、識別と記述）に焦点を絞っていることが示されているが、ERMIの活動が他の標準化作業の代わりになることを運営グループは期待したわけではなく、その意図は、共通の関心領域を特定し、作業の重複を避けることであった

4.3. プロジェクトの成果

この節では、様々なERMI文書の作成過程やXMLの調査結果から学んだものを総括する。文書自体は付録に示した。

4.3.1. 機能要件（付録A）

2003年春、ハーバード大学図書館とMIT図書館がEx Libris社と会合を持ち、ERMツールに関して実行可能な作業について議論した。考えうるデータ要素のリストが提供され議論されたが、すぐに関心は「そもそも機能性とは何だ」という疑問に向けられた。この疑問に答えるために、運営グループのIvy AnderSonとMITのEllen Duranceauをリーダーに、ハーバード大学とMITの図書館員は共同でERMシステムに必要な機能を書き出した。この文書はその後DLF/ERMIの成果物の1つとして利用に供された。

機能要件は、電子資源をそのライフサイクル（選択、収集、アクセス提供、資源管理、職員と利用者の支援、更新と保存の判断など）を通じてサポートするために必要な機能を特定して記述したものである。要件は、次の指針に基づいている。

• 印刷資料と電子資源の管理とアクセスは統合された環境で行われるべきである。
• 提供される情報はその提供方法に関わらず同一のものであるべきである。
• 各データ要素は単一の保守窓口を持つべきである。
• ERMシステムはフィールドやデータ要素を容易に作成・追加できるように十分な柔軟性を持っているべきである。

さらに、ERMシステムにとってコアとなる要件がいくつか特定された。たとえば、システムは個々の電子資源、パッケージ、ライセンス、オンラインインターフェース間の関係を表現できるべきである。また、指定されたライセンス、インターフェース、パッケージの特性とこれらが適用される資源とを関連付けることができるべきである。さらに、堅牢な報告機能やデータ出力機能を提供するべきである。

この文書は47の要件を網羅しており、その半数以上は職員を支援するために必要な機能を論じている。要件の適用範囲は以下のカテゴリ毎の要約から知ることができる。

• 一般（4要件）。既に述べた3つのコア要件をより正確な言葉で記述しており、さらに、「職員の閲覧範囲と保守権限を管理するためのセキュリティ機能」も必要であることを述べている。
• 資源発見（7要件）。これらの要件は、OPACやWeb提供サービスを通じて、あるいはそれらに至る情報を提供することにより情報資源を利用可能にすること、およびアクセス時にそのコンテキストに即したライセンス情報を提供可能にすることを扱うものである。
• 書誌情報管理（2要件）。単一のデータ入力窓口、書誌情報の保守、アグリゲータの所蔵データや購読管理データのインポート機能を扱う。
• アクセス管理（5要件）。このグループは、統一資源識別子（URI）、ユーザIDとパスワード、機関のIPアドレス表などの基本的なアクセス関連情報の管理、およびプロキシサーバや永続的名前サービスなどの関連する技術システムとの連携やシステムへのデータ提供を行うための要件を扱う。
• 職員に関する要件（29要件）。
  • 一般的なインターフェースに関する要件（4要件）。職員用のインターフェースは、資料収集、障害対策、ライセンス管理、システム管理と統計といった職員の仕事や関心に沿った特定の分野に最適化された画面としてまとめられるべきである。
  • 選択と評価プロセス（9要件）。ERMシステムは、分散化された処理の様々な局面における作業やその他の情報を記録できるようにするべきである。また、指定した状況になった場合に特定の処理を行ったり、警告メールを送信したりする機能を持たねばならない。機関独自のワークフローを実現するために動作やトリガを図書館でカスタマイズできるべきである。
  • 資源管理とシステム管理（11要件）。このグループは、管理用のユーザ名とパスワードに関する機能、ローカルの設定オプション、ハードウェアとソフトウェアに関する要件、問題解決と障害対応の支援、利用できない資源にフラグを立てる機能、利用データに関する情報を格納する機能を記述している。
  • ビジネス機能（5要件）。このグループは価格モデル、キャンセルの制限、購読の更新と終了処理、共同購入やコンソーシアム関連情報を扱う。

機能要件をできるだけ広く適用できるようにするために、運営グループは図書館員作業パネルのメンバーと共に評価と検討を行った。パネルメンバーには、コアあるいは不可欠と思われる要件とそうではない要件との区別が問われた。すべての要件についてパネルメンバーの少なくとも1人がコア要件であるとみなしたことは（ベンダーを動揺させたかもしれないが）運営グループを満足させた。ただし、パネルメンバーが最も重要であると考えたいくつかの機能を特定することが可能である。

最も重要な要件の1つは、書誌的実体（すなわち、個々のタイトル）とそれを利用可能とするパッケージやライセンス、インターフェースとの関係を管理する機能であった。もう1つ重要な要件は、URLやユーザIDとパスワード、機関IPアドレスなどのアクセス関連情報を格納する機能であった。承認ユーザの種類やその他のライセンスによる許可と制限、契約自体に関するメタデータを記録する機能も同様に重要であるとみなされた。驚くことではないが、ライセンスによる許可事項や関連のメタデータを格納する機能はコア要件として最も多く挙げられた要件の1つであり、デジタル化した編集済みのライセンスにリンクする機能もほとんどのパネルメンバーが望んだものであった。書誌データやその他の記述データを保守するための単一窓口の提供や所蔵データやその他の購読データを外部プロバイダから電子的に転送することを容易にする機能も、カスタマイズ可能なルーティングや通知ツールによる機関独自のワークフローのサポートと共に、不可欠な機能であるとみなされた。

その他のコアまたは不可欠な機能は管理用のIDとパスワードに関する情報や利用統計に関する情報を格納する機能と利用統計にアクセスする機能であった。

次のテーマも作業パネルとの議論において登場した。

• ほとんどの図書館が、発注、予算管理、会計処理といった収集処理のコア機能には既存の図書館システムを使えるようにしたいと希望した。しかし、電子資源が必要とする追加機能を実現するにはこれらのシステムの機能を向上させる必要がある。もし、ERMが独立のアプリケーションとして実装されれば、おそらく図書館はコアである収集作業を既存の図書館システムで処理し続けることを選択し、一方で、分析や報告書作成のために何らかのデータをERMシステムにエクスポートしたいと考えるだろう。
• ERMシステムにおける記述データと、OAPCや統合検索ツール、リンクリゾルーションサービスといったその他の記述システムとの関係は多くの図書館にとって関心の的である。データの重複を最小限にすることとこれらのシステムが互いに「話し合える」ようにすることが重要であることは全員が同意した。あるパネルメンバーが言ったように、OPACはMARC書誌データの故郷であると認識されるべきである。
• 利用統計は多くの図書館にとってますます関心を引くものとなっている。業者が提供する利用データを当てにするだけではなく、多くの図書館がそのようなデータを独自に収集している。運営グループはパネルメンバーに、ERMシステムが利用データを格納すべきか、それとも単に外部のデータソースを利用者に示せば良いのかを尋ねた。ほとんどのメンバーは外部ソースの提示で十分であると考えたが、別のソースからデータを収集して統計を提供するための共通の枠組みが提供されるべきだと考えたメンバーも多かった。
• 多くの大規模図書館は永続的URIを使用している。これらのサポートは図書館の運営にとって不可欠に違いない。通常、永続的URIを付与している図書館はこれをERMシステムに記録できることを望んでいる。永続的URIを付与するアルゴリズムは通常極めて定型的であるので、永続的URIを生成できることは望ましく、かつ実現可能な機能であることに多くのメンバーが同意した。

4.3.2. 管理作業のワークフロー図（付録B）

管理作業のワークフロー図作成の目的は、電子製品のライフサイクルを管理する作業の詳細な概要を提供することであった。従来の物理的な図書館資料の収集・管理作業と電子製品のそれとは類似点もあるが、電子製品に特有な問題が多いことを認識することから始まった。

いくつかの相違点は、付録Bの概要ワークフロー図から明らかである。たとえば、電子製品は定期的なライセンス処理を必要とし、提供する際に技術的な問題が発生する可能性がある。ネットワーク製品を収集して有効化する処理は、物理的資料の受付・処理手続きとは大幅に異なる。電子製品に必要な保守、障害対策、ライセンス更新は物理的資料の閲覧、現物保存、修理とはまったく異なるものである。

主としてKimberly ParkerとNathan Robertsonにより作成されたプロジェクトのワークフロー図はこれらの複雑な現実を反映しており、モデルワークフローを3.1節で示したHERMESで特定された4つの主要なサブプロセスに分割している。各サブプロセスは独立したダイアグラムで表現されている。第1のサブプロセス「製品の検討と試行プロセス」は、図書館職員が興味深い電子資源の存在に気付いた時点から始まり、試行と評価の段階を経て、処理の「継続/中止」の判断に至る典型的な処理を辿っている。継続の決定により図に示されている3つの処理、「ライセンス交渉」、「技術的評価」、「ビジネス交渉」が（これらは通常同時に発生するので）開始されることになる。

これらすべての処理で「継続の承認」に至ると、3つ目の主要なサブプロセスが開始される。これらは「提供プロセス」と名付けられており、製品の登録と設定、目録作成、適当なWebページへの記載、利用の可否や利用データの処理など、それぞれ独立した処理を含んでいる。最後のサブプロセスは「製品の保守と評価」である。ルーチン的保守カテゴリに含まれる機能には、利用統計の収集、障害対応と問題解決、ベンダーによる製品の定期的な変更（URLの変更など）、公開文書の改訂がある。

4.3.3. データ実体、要素、構造（付録C, D, E）

プロジェクトの3つの成果物、「実体関連図」、「データ要素辞書」、「データ構造」は特に密接に関連している。実体関連図は、ERMの概念とそれらの間の関係を視覚的に表したものである。データ要素辞書は、ERMシステムが保管･管理しなければならない個々のデータ要素を特定して定義したものである。ただし、要素間の関係については読者の判断に任せた。データ構造は、各データ要素を実体関連図で定義された実体や関連に関係付けるものである。3つの文書は合わせて1つのERMに関する完全な概念モデルを形成する。

通常、実体関連図は関係データベースを視覚化する方法として使用されている。各実体はデータベースの1つのテーブルを表しており、関連線は1つのテーブルの複数のキーを表しており、これらのキーは関連するテーブルの特定のレコードを指している。実体関連図はさらに抽象化されている場合もあり、この場合は、必ずしもデータベースのすべてのテーブルを扱ってはおらず、主要な概念と関係を簡単に図式化したものである。ERMIのために作成した実体関連図は後者のタイプである。電子資源の管理に必要な主要な実体と関連を抽象的かつ理論的に示すことが目的であり、ERMデータベースに必要と思われるすべてのテーブルを特定しているものではない。

データ要素辞書は、現在およそ300要素を含んでおり、UCLAのERDbで作成されたデータ辞書を起源とする。データ要素を要素名のアルファベット順にリストし、識別子と定義、さらに必要に応じて注釈を記載している。要素のネーミングと定義はできる限り国際標準化機構（ISO）11179で提供されているガイドラインに従った。さらに、Dublin CoreやONIX、ONIX for Serials、METSなどの関連する既存のメタデータスキーマで使用されている要素名を特定して使用するよう努めた。これらの標準やスキーマに関するさらに詳細な考察と本イニシアティブの作業がこれらの標準やスキーマとどのように関係するかは付録Ｆに示した。

データ構造文書は、データ辞書に含まれるデータ要素を実体関連図に示されたおよそ2ダースの実体に関連付けることにより実体関連図とデータ要素辞書を統合化したものである。データ構造では、名前と定義に加えて、要素種別（たとえば、論理値、ポインタ、テキスト）、用途または機能（機能要件文書の特定の項目への参照を含む）、推奨値、任意性（任意か必須か）、繰り返し（要素は唯一の値を持つか、繰り返し可能か）、データをより明確にするための注記や例を記載している。

電子情報資源やインターフェースに関する実体のように、定義されたおよそ2ダースの実体のいくつかは主として記述的機能を提供するものとして特徴づけられる。ライセンス条項を要約するには数多くのデータ要素が必要である。たとえば、規定条項実体は、識別グループ、ユーザグループ、利用条件グループを含み、利用条件グループはそれ自体、公正利用や学術的共有、ILL、コース利用などのライセンス条項をカバーするおよそ30の要素を含んでいる。

また、収集や処理ワークフローに関する実体、アクセス情報や管理情報に関する実体も存在する。実体の中には様々な目的で使用できるものもある。たとえば、組織実体は、図書館が電子資源に関する取引をする企業やベンダー、プロバイダ、出版者、ライセンサーなどに関する情報を記録することに使用できる。

本プロジェクトで識別、命名、定義した要素は、新たに策定されるデータ交換用標準のコアを形成するものと考えられるので、リストは以前からWebポータルを通じて公開されていた。ERMシステムを開発中であった2つの図書館システムベンダー（Innovative Interfaces社とEx Libris社）とは特に密接なコミュニケーションを行い、両社とも自社システムのデータ要素が本イニシアティブのデータ要素と矛盾をきたさないよう多大な作業を行った。

4.3.4. XMLの調査（付録F）

提供する成果物の最後はXMLスキーマである。これは、電子資源、電子資源パッケージ、ライセンスに関する情報を交換するためのメタデータ標準の策定を促進するものである。2003年秋にこの作業を行うグループが作成された。Adam Chandlerをコーディネータに、運営グループからSharon Farb、Angela Riggio、Nathan Robertsonが参加し、加えてハーバード大学のRobin Wendler、スタンフォード大学のNancy Hoebelheinrich、O'Reilly & Associates社のSimon St. Laurentが参加した。後に、コーネル大学のRick Silterraも作業に加わった。この作業はデータ実体、要素、構造に関する作業が終わらなければ開始できないので、これらの作業よりはるかに先行することはできなかった。プロジェクトを期間内に完成させたいし、コメントや利用を得るために先行公開もしたかったので、この作業に費やすことができる時間は非常に限られていた。データ要素に関する作業では、逐次刊行物購読情報の交換に関するNISO/EDItEUR共同作業グループの作業など、他の場所で新たに行われていた標準化作業から運営グループは情報を入手し、影響を受けた。

XMLの調査は、ERMスキーマの想定される用途の考察から開始した。想定される用途には次のようなものがある。

• ユーザグループライセンス条項を含むリンクリゾルバで使用されるデータのベンダーと図書館の間の交換
• 出版者の電子資源タイトルリスト
• （たとえば、METSを使って）関連オブジェクト化した実用的なライセンス条項の保存アーカイブへの組込み
• コンソーシアム会員へのライセンスや管理データの配布
• 契約相手とのライセンスデータの交換

これらの多様な可能性を考慮に入れて、XMLグループのメンバーのWedlerが、Dublin CoreとMODSの名前空間とスキーマ、および権利表現のためのスロットまたはプレスフォルダを持つ一般的な用途のためのスキーマ案を作成した。グループによるスキーマ案の検討やNISO/EDItEURとXrML/ODRLの活動がさらに進むにつれ、より実りのあるアプローチは少数の実践的なシナリオに作業を集中させることであることが明らかになった。ライセンス条項はこの数年図書館の最大の関心事であったが、直接関連する既存のXMLに関する作業は図書館コミュニティではまだ行われていなかったので、ライセンス条項に焦点を絞ることが決定された。グループは次の2組の要素セットに焦点を絞った。

• 職員と利用者が何よりも知る必要があるライセンス条項を最も的確に表現する簡潔な応急処置セット
• 2つの図書館の間、または出版者やコンソーシアムなど図書館以外の実体と図書館の間で共有されると最も役立つと思われるより多くの要素を持つライセンスセット

グループメンバーはDLF/ERMシステムデータ構造文書から必要な要素を選択してインスタンス文書を作成した。そして、このインスタンス文書を使って、上に示した限られた用途に最適化したスキーマを作成した。

既存のスキーマを使用することは潜在的に多くの利点があるので、グループは検討中の目的に密接に関連する作業や適用可能な作業を捜した。そして、明らかに類似性のあるデジタル著作権管理（DRM）と権利表現言語（REL）に関する作業を検討することになった。Karen Coyleは議会図書館に最近提出した報告書において、現在2つの定評のある権利表現言語がDVD動画などのメディア製品の規格としてしのぎを削っていると報告している(Coyle 2004)。1つ目は、今ではMPEG-21/5と呼ばれるもので、ContentGuardという名の会社が開発したXrML言語に由来する。2つ目はオープンデジタル権利言語（ODRL: Open Digital Rights Language）と呼ばれるものである。これらの言語はいずれも、利用者が特定の資源を使って行えることを権利保有者が記述できるようにするだけでなく、実装者がユーザの行動を大幅にコントールできるようにすることも目的としていた。MPEG-21/5には広範囲にわたる特許請求項があることがわかり、また、XML調査グループはオープンな規格を好んだので、ODRLに焦点を絞ることになった。

関心を引いた3つ目の作業はCreative Commonsのもので、RDF（資源記述フレームワーク）に基づくものである。Creative Commonsの目的は、MPEG-21/5やODRLとは異なり、作品をインターネット上で無料で公開するための条件を著者が定義する方法を提供することであり、利用をコントロールするものではなかった。グループはCreative Commonsのスキーマにも注目することを決め、（上で述べた2つのユースケースに対して各々）4つのスキーマを作成した。1つはODRLに、もう1つはCreative Commons RDFに基づいたもので、残りの2つはERMIネイティブのである。いずれもERMIプロジェクトの要素と値に基づいている。

ODRL使用の試みは功罪相半ばする結果となった。ODRLは拡張性があり柔軟であることが証明されたが、その効果的な使用法を学習するには多大な時間がかかり、ODRLイニシアティブのRenato IannellaとSusanne Guthの献身的な援助がなければさらに多くの時間を要しただろうと思われた。たとえば、グループが作成したODRLスキーマではXML文書の形式しか検証できないことがわかった。これは、（不正な値を含む）任意の値が受け付けられることを意味している。(その後、Iannellaは文書をより完璧に検証することが可能であると教えてくれたが、デモンストレーション用のODRLスキーマを変更してその機能を組み込む時間はなかった。）さらに、ODRLでは許可された全ての利用法を記述する必要があるが、これは明らかに、ライセンスにより禁止されていない資源の利用は正当な利用となるべきであるという図書館の期待と合致しない。

より大きな成功がCreative Commons RDFには期待された。これは利用を直接コントロールするように設計されたものではなく、その精神はオープンアクセスや公正利用の精神に一致しているからである。Creative Commons RDFはODRLに比べて制約が少なく、拡張性が高かったが、残念なことに、これも構造やデータ種別を検証する方法を欠いていた。その結果、調査グループはCreative Commons RDFもライセンスの記述と交換のための基礎となることはできないと結論付けた。

これらの結果は、先に述べたERMIネイティブのライセンス表現の作成という3番目の候補に目を向けることになった。これは手短に言えば、ERMIが作成したデータ辞書とデータ構造文書にある要素と値に基づいてライセンス表現のための名前空間を確立することを意味している。その利点には、これらの任意の要素と値を簡単に利用できること、既存のRELをその目的に合わない用途に適合させるために必要な時間を回避できること、構文と値をより厳密に検証できることが挙げられる。試験用の2つのERMIネイティブスキーマの作成中にわかったもう1つの利点は、ODRLやCreative Commons RDFを使って作成したスキーマより簡潔なものになることであった。この「最適性」により、図書館と学術出版業界におけるライセンス表現標準化に関する議論は短期的にはERMIネイティブスキーマに焦点を絞るべきであると、グループは考える。

5. イニシアティブに対する反応と将来の検討事項

DLF/ERMIの成果については十分に述べたので、次はイニシアティブの作業に対する図書館やベンダー業界の反応を簡単に述べ、さらに運営グループのメンバーが考えるさらなる作業が最も必要である分野について検討する。

5.1. 図書館とベンダーの反応

ERMIの活動を後押しした主な理由は、電子資源を正しく管理するために必要なツールを持っている図書館が少なく、また、そのようなシステムの開発が複雑で時間のかかることが理解されていたことであった。当初から、ERMI運営グループのメンバーはそのような問題の解決には広範な協力と投資が必要であると考えた。したがって、図書館とベンダーがこのイニシアティブに対して非常に肯定的な反応を示したことを報告でき、極めて満足である。

本稿執筆時点において最も重要なことは、いくつかのベンダーが既にERMシステムやサービスの開発を開始した、あるいは開発計画を発表したことであり、これらの開発のほとんどが本プロジェクトの機能要件案やデータ要素案を大幅に取り入れたことである。これらの組織とそのERM関連製品・サービスには次のようなものがある。

• Colorado Allianceは2004年にGold Rushの改善・強化を計画している。
• Dynixは2004年のALA年次総会において電子情報資源管理モジュールの開発を発表した。
• EBSCOは主要なERM機能を組み込み、その文献に電子資源のライフサイクル図を使用した電子ジャーナルサービスを開発した。
• EndeavorはMeridianという名のフル機能のERM製品を2005年にリリースする計画を発表した。
• Ex LibrisはVerdeという名のSFX知識ベースを利用した製品の開発を発表した。 2004年末までに最初のリリースを出すことが計画されている。
• HarrassowitzはERM機能を組み込んだサービスであるHERMES 2.0の計画を発表した。
• Innovative Interfaces, Inc.はERMモジュールを開発しており、開発から製品に向けたベータテストに移行している。
• Serials Solutionsは短期計画にERM製品を挙げている。
• SIRSIはプロトタイプシステムを開発し、2004年のALA年次総会で紹介した。
• VTLSはVerifyという名のERM製品を開発する計画をこの春発表した(VTLS 2004)。

5.2. 未解決の問題

これらのベンダーが製品やサービスを開発するにつれ、ベンダーとその顧客である図書館は、ERMI製品に欠けていたり不完全な部分を発見することになるだろう。そして、本報告書で概略を述べた問題や未だ特定されていない問題を解決する有用な新しいアプローチを工夫することになると思われる。これを踏まえて、時間の制約により解決できなかったが、さらなる作業をする価値のある問題をいくつか指摘したい。

5.2.1. コンソーシアムのサポートと機能

ERMIは現在多くの図書館が参加している図書館コンソーシアムではなく個々の図書館のニーズに焦点を絞った。これは急速な進歩を可能にしたが、コンソーシアムのサポート機能を考慮に入れたより広い見方が大いに望まれる。しかし、図書館コンソーシアムは各々大きく異なるので、その実現は複雑なものになる。OhiolinkやCDLのように多額の中央資金を持ち、幅広いサービスを行わなければならないコンソーシアムがある一方で、購入クラブ的な機能が大きく、相応のより限られた任務、職員、目標を持つコンソーシアムもある。困難ではあるが、最後の数ヶ月はこの方向の作業がいくらか行われた。この広がりの一方の端である「中央資金と広範な任務」を持つコンソーシアムにとって望ましいコンソーシアムサポートの範囲は、CDLがERMIの作業を参考にして行った評価において示唆された(Wright 2003)。2004年3月、カリフォルニア大学システム（UC）図書館のシステム全般の運用と計画に関する諮問委員会（SOPAG）は、ERMの必要性の議論にまで遡ってこの評価をフォローした。UCの各図書館はこの会議に代表を送り込んだ。ERMI文書に記載された機能やアーキテクチャについても議論され承認されたが、もっと高度な機能が必要と考えられる、あるいはDLFイニシアティブでは取り上げられなかったSOPAG要件にも注目が集まった。たとえば、CDLはどの会員図書館が自発的な購入活動に参加しているか、どのような経費分担が適用されているかを把握することに多くの労力を費やしている。さらに、電子ジャーナルパッケージの評価と交渉には、個々のキャンパスとコンソーシアム両者の冊子体と電子ジャーナルの現在の購読情報を把握し、それを価格や利用統計、Thomson ISI社の「インパクトファクター」といった他の情報と結びつける機能を必要とする。CDL加盟図書館は各々異なる図書館システムとERMシステムを使用し続ける可能性が高いと考えられるので、上に示したデータ標準と相互運用性に対するニーズは特に大きい。

SOPAGによるERMの再検討に続き、関連する2つのセッションが国際図書館コンソーシアム連合（ICOLC）の会議で開催された。1つ目のセッションではコンソーシアムの管理雑学（administrivia）に焦点を絞り、コンソーシアム管理者が把握したりベンダーや会員図書館と交換しなければならない情報や彼らが考案したサポートツールについて議論する機会を提供した。ERMに関する議論に参加した図書館員は、必要とされるデータの多様性（図書館とベンダーが交渉するIP範囲、更新日付、そのような作業を行うための様々なスプレットシートやデータベースの信頼性など）を始めとする多くのテーマがあることを認識した。2つ目のセッションは、コンソーシアムにおける電子資源の管理に関するものであり、DLFの作業やUCシステム、Gold Rush製品の説明が行われた。参加者は、ベンダーによる開発、そのコンソーシアムのサポート、データ標準に強い関心を示した。これら2つのセッションで挙げられた話題に関するその後のERMI運営グループの議論により、ERMIデータモデルは、主要なコンソーシアム要件をサポートする、あるいは対応するために拡張できるようにする、ただし、さらに慎重な評価が必要であると結論づけた。CDLは現在その要件の分析に当たっているので、その作業の結果作成される文書はコンソーシアムのERM要件に関するより汎用的な記述となり、ICOLCの後援でリリースされるものと考えられる。

5.2.2. 利用データ

ERMIデータモデルにも若干利用データに触れている個所があるが、利用可能なデータを使って図書館が行う分析やERMシステムに組み込むために利用データをより簡単な形で図書館に送る方法について、さらに詳しく記述することが望ましいだろう。この種の機能の分析の重要なソースとしては、ペンシルバニア大学で開発されたData Farm（Zucca 2003; University of Pennsylvania Libraries 2004）やARLのE-metricsイニシアティブ（Association of Research Libraries 2004）のようなモデルとなる利用データプログラムが存在する。COUNTERプロジェクトの「オンライン利用データの記録と交換」のための実行規約は、疑いなくこの分野における標準としてますます重要性を増すだろう。また、最近発表されたCOUNTER利用報告のためのXML DTDの公開は特に歓迎される。利用データをより円滑かつ簡単な方法で伝える道を開くからである。

5.2.3. 資源の継承

ERMIデータモデルに関する問題の1つとして、個々の雑誌がある出版社から別の出版社へ、または、あるプラットフォームから別のプラットフォームへと頻繁に移動することがある。これが起きると各変更に関連する特定のライセンス条項、保存のための権利、アクセス情報を追跡することが困難になる場合がある。

5.2.4. データ標準

これらの作業も重要ではあるが、関連するデータ標準の策定と維持のための作業が同時に継続されない限り、長い目で見れば成功するとは思われない。

• 逐次刊行物の記述と所蔵情報。逐次刊行物購読情報の交換のためのNISO/EDItEUR共同作業委員会が逐次刊行物の購読データの標準的な交換フォーマットを策定中であることが知られていたので、ERMI運営グループはこれに対抗する標準を策定することはせず同委員会の作業に任せることにした。運営グループは共同作業委員会の作業が非常に重要なものであると考えており、さらなる発展を期待している。
• 標準的な識別子。運営グループは、パッケージやプロバイダ、インターフェースに関する単一でグローバルな電子資源識別システムまたはレジストリがあれば、ある種の情報の交換を現在よりはるかに信頼性があり、正確なものにすることができると結論づけた。
• ライセンス条項の表現。知的所有権、ライセンス供与、容認使用法に関するコミュニケーションの標準化の問題を解決することもさらなる作業が必要であろう。幸いなことに、この問題に関心がもたれている証拠が存在する。たとえば、最近行われた電子環境における逐次刊行物に関するCONSERサミットでの議論では、ライセンスの公開バージョンを図書館に提供する実験を行う用意がある出版社が存在することが示唆された。また、ローカルのERMシステムにインポートするためのXMLによるライセンスのマークアップ案の作成に関心が集まった。さらに、ERMIデータ辞書をたたき台として、出版社のライセンス供与および権利表現のための標準的なデータ辞書作成の可能性についても議論された。
• 相互運用性。他のベンダーが作成した図書館システムに完全な形で組み込むことができるスタンドアロンのERMソフトを開発することが果たして可能であるかという疑問はもっともなものであると思われる。運営グループはデータ要素の標準化はこの方向に向けた重要な第一歩であると信ずるが、「図書館で使用されている異なるソフトウェア間でWebサービスを可能にする」ことを目的とするVIEWSと名付けられた新しいイニシアティブももう一つの方法になるかもしれない（Dynix 2004）。

これらの問題の解決には、図書館、コンソーシアム、出版社、雑誌の販売代理店およびサポート企業、図書館システムベンダーの組織的かつ協力的な努力とこれらの間の実効的なコミュニケーションの構築が必要となるだろう。

6. 結論

図書館、出版社、ベンダーが活動している新しい電子環境は、比較的短期間の間に急速に進化し、極めて複雑になったが、我々が現在認識している複雑性は、もう間近に迫っている電子資源への投資が進み、技術革新が続き、ビジネスモデルが進化した場合の複雑性に比べればたいしたものではないかも知れない。環境がどのように進化するにせよ、新しいツールや標準、賢い選択、共同作業が必要となるだろう。我々はDLF/ERMIがこれらすべての活動をよりすばやく、より効率的かつ効果的に実行可能にすることを希望している。

参考文献

• Alan, Robert. "Keeping Track of Electronic Resources to Keep Them on Track." PowerPoint presentation, 17th Annual North American Serials Interest Group (NASIG), Williamsburg, VA, June 20-23, 2002.
• Association of Research Libraries. "Collections and Access for the 21st-Century Scholar: Changing Roles of Research Libraries. ARL: A Bimonthly Report on Research Library Issues and Actions from ARL, CNI, and SPARC, no. 225 (December 2002), http://www.arl.org/newsltr/225/index.html.
• ------. ARL Supplementary Statistics 2001-2002. Washington, D.C.: Association of Research Libraries, 2003. http://www.arl.org/stats/pubpdf/sup02.pdf.
• ------. E-Metrics: Measures for Electronic Resources. Washington, D.C.: Association of Research Libraries, 2004. http://www.arl.org/stats/newmeas/emetrics/.
• Cornell University Library. "Cornell University Library Digital Futures Plan: July 2000 to June 2002." Ithaca, NY: Cornell University Library, 2000. http://www.library.cornell.edu/staffweb/CULDigitalFuturesPlan.html.
• Cornell University Library. "Digital Library Federation Meeting, November 2002." Summary, 2002. http://www.library.cornell.edu/cts/elicensestudy/dlf2002fall/home.htm.
• Counter Online Metrics. "COUNTER: Counting Online Usage of Networked Electronic Resources," Web site, 2004. http://www.projectcounter.org/.
• Cox, John. "Model Generic Licenses: Cooperation and Competition." Serials Review 26, no. 1 (2000):3-9.
• Coyle, Karen. "Rights Expression Languages: A Report for the Library of Congress." White paper, 2004. http://www.loc.gov/standards/Coylereport_final1single.pdf.
• Cyzyk, Mark, and Nathan D.M. Robertson. "HERMES: The Hopkins Electronic Resource Management System." Information Technology and Libraries 22, no. 3 (2003): 12-17.
• Digital Library Federation. "DLF Electronic Resource Management Initiative." Project description, 2002. http://www.diglib.org/standards/dlf-erm02.htm.
• Duranceau, Ellen Finnie. "License Compliance." Serials Review 26, no. 1 (2000):53-58.
• ------. "License Tracking." Serials Review 26, no. 3 (2000):69-73.
• Dynix. Web site. Dynix. http://www.dynix.com/
• Farb, Sharon E. "UCLA Electronic Resource Database Project Overview." PowerPoint presentation, ALA Midwinter 2002, New Orleans, LA, January 18, 2002. http://www.library.cornell.edu/cts/elicensestudy/ucla/ALAMidwinter2002.ppt.
• Farb, Sharon E., and Angela Riggio. "Medium or Message: A New Look at Standards, Structures, and Schemata for Managing Electronic Resources." Library Hi Tech 22, no. 2 (2004):144-152.
• Friedlander, Amy. Dimensions and Use of the Scholarly Information Environment: Introduction to a Data Set Assembled by the Digital Library Federation and Outsell, Inc. Washington, D.C.: Digital Library Federation and Council on Library and Information Resources, 2002. http://www.clir.org/pubs/reports/pub110/contents.html.
• Hennig, Nicole. "Improving Access to E-Journals and Databases at the MIT Libraries: Building a Database-Backed Web Site Called 'VERA'." Serials Librarian 41, no. 3/4 (2002):227-254. http://www.hennigweb.com/publications/vera.html.
• International Standards Office. International Electrotechnical Commission.
• International Standard 11179, Information Technology, "Specification and
• Standardization of Data Elements." Geneva, Switzerland: ISO/IEC, 1995-2000.
• Jewell, Timothy D. Selection and Presentation of Commercially Available Electronic Resources. Washington, D.C.: Digital Library Federation and Council on Library and Information Resources, 2001. http://www.clir.org/pubs/reports/pub99/pub99.pdf.
• Johns Hopkins University Libraries. "HERMES--Hopkins Electronic Resources ManagEment System." Web site. Johns Hopkins University Libraries. http://hermes.mse.jhu.edu:8008/hermesdocs/.
• National Information Standards Organization and Digital Library Federation. "NISO/DLF Workshop on Standards for Electronic Resource Management, May 2002." Notes, slides, and other materials. Ithaca, NY: Cornell University Library, 2002. http://www.library.cornell.edu/cts/elicensestudy/nisodlf/home.htm)
• National Information Standards Organization. "NISO/EDItEUR Joint Working Party for the Exchange of Serials Subscription Information." Web site. http://www.fcla.edu/~pcaplan/jwp/.
• Nawrocki, Robert F. 2003. "Electronic Records Management," in Encyclopedia of Library and Information Science. New York: Marcel Dekker, 2003.
• Okerson, Ann S., principal investigator, Alex Edelman, Georgia Harper, Earl Hood, and Rod Stenlake. "CLIR/DLF Model License," Liblicense: Licensing Digital Information, 2001. Council on Library and Information Resources, Digital Library Federation, and Yale University Library. http://www.library.yale.edu/~llicense/modlic.shtml.
• Robek, M.F., G.F. Brown, and D.O. Stephens. 1996. Information and Records Management, 4th ed. New York: McGraw Hill, 1996.
• Stanley, Nancy Markle, Angelina F. Holden, and Betty L. Nirnberger. "Taming the Octopus: Getting a Grip on Electronic Resources." Serials Librarian 38, no. 3-4 (2000):363-368.
• Stockton, Melissa, and George Machovec. "Gold Rush: A Digital Registry of Electronic Journals." Technical Services Quarterly 19, no. 3 (2001):51-59.
• University Libraries, The Pennsylvania State University. "Data Farm." Web page, 2004. Pennsylvania State University. http://metrics.library.upenn.edu/prototype/datafarm/.
• University Libraries, The Pennsylvania State University. "ERLIC Shareware: Electronic Resources and Licensing Information Center." Pennsylvania State University Libraries, 2001. http://www.libraries.psu.edu/tas/fiscal_data/electronicresources.htm.
• Visionary Technology in Library Solutions. "'VIEWS': A Newly Created Vendor Initiative for Enabling Web Services Announced. Online article. VTLS, 2004.
• http://www.vtls.com/Corporate/Releases/2004/21.shtml.
• Warner, Beth Forrest. "Managing Electronic Resources in Today's ILMS Environment." PowerPoint presentation, ALCTS Managing Electronic Resources: Meeting the Challenge Symposium, ALA Midwinter Meeting, Philadelphia, PA, January 24, 2003. http://kudiglib.ku.edu/Personal_prsns/ALA_Preconf_2003MW.htm.
• Cornell University Library. "Web Hub for Developing Administrative Metadata for Electronic Resource Management." Web site. Cornell University Library. http://www.library.cornell.edu/cts/elicensestudy/.
• Wright, Alex. "California Digital Library Electronic Resource Management Assessment: Final Report." Oakland, CA: California Digital Library, 2003.
• Zucca, Joseph. "Traces in the Clickstream: Early Work on a Management Information Repository at the University of Pennsylvania." Information Technology and Libraries 22, no. 4 (2003):175-179.

先頭に戻る

付録 A: 電子情報資源管理のための機能要件 [2]

Ivy Anderson, Sharon E. Farb, Adam Chandler, Timothy Jewell, Kimberly Parker, Angela Riggio, Nathan D. M. Robertson

はじめに

本文書に掲げる要件が想定している対象は、契約ライセンス条項に従い電子情報資源を効率的に選択、評価、収集、保守、アクセス提供するために必要な情報とワークフローの管理を支援するシステムである。そのようなシステムは、電子資源のサービス要件を支援すると同時に、従来のMARCベースのオンライン目録やWebボータル、統合検索ツール、ローカルのリゾルーションサービス、ローカルのユーザ認証やアクセス管理システム、既存の図書館管理機能とのシームレスな連携やデータの効率的な共有を通じて、これまでに投資した既存の図書館技術の上に構築されるべきである。単独システムとして実装されたとしても、既存の図書館管理システムの一部として実装されたとしても、電子情報資源管理機能は、図書館で開発された他のシステムの機能と重複せず、補完するものであるべきである。

本文書は、そのような電子情報資源管理（ERM）システムに要求される幅広い分野の機能性の概略を示すものである。現時点の目的は、必要なすべての機能を詳細に記述することではなく、システムに要求される主要な機能の概要を提供することである。各要件について示す例は、典型的で説明的なものであり、包括的なものではない。

ガイドラインの原則

ERMシステムは、1つのシステムで管理とアクセスの両者をサポートする統合環境を提供するべきである。システムは、フィールドの一括更新や柔軟な追加を行う機能を提供するべきである。システムは、フィールドやレコードを公開画面から隠す機能や各データ要素を1つの画面で管理する機能を持つべきである。システムは、既存のOPACやWebポータル、図書館管理システム、リンクリゾルーションサービスとの連携や動的なデータ共有をサポートするべきである。システムは、その方法によらず利用者に一貫した情報を提供するべきである。最後に、ERMシステムは、保有する情報を保管、アクセス、検索、報告書を作成する機能を長期にわたってサポートするべきである。

機能要件

一般的要件

情報資源や契約条項、ライセンスおよびその他の要素の相互関係を正確に位置付け、多対多の複雑な関係に対処する能力は、本文書で説明する機能性をサポートするための不可欠な要素である。

添付する「電子情報資源管理のための実体関連図」（付録C参照）はこれらの関係を図式化して示したものである。

本文書で説明するすべての機能分野において、以下の事項が可能でなければならない。

1. 所定のライセンスや一連の契約条項、パッケージ、オンラインインターフェースプラットフォーム（以後、「インターフェース」と呼ぶ）で対象とされる、あるいは提供される書誌的実体（電子媒体と紙媒体）が何であるかを識別する。
2. 所定のライセンスや一連の契約条項、パッケージ、インターフェースの特性とこれらが適用されるすべての書誌的実体（電子媒体と紙媒体）とを関連付ける。
3. 職員の閲覧範囲と保守権限を管理するセキュリティ機能を提供する。
   • 3.1. 一部の職員に機密情報を見せない。
   • 3.2. （分野毎に）データの追加・更新・削除を指定した職員に限定する。
   • 3.3. 不要なフィールドを表示しない簡潔なデータ表示画面を構築する機能を提供する。
4. 必要に応じたクエリを実行して、様々なフィールドやテーブルの値を使った報告書を作成する。

資源発見に関する要件

電子資源の検索やブラウジングに適したツールは（著者やタイトル、別タイトル、相互参照、主題、キーワード、その他の項目による検索を通じて）既に多くの図書館のOPACやポータルで見ることができるが、資源発見を目的として電子資源を選抜するツールを持っていない機関も存在する。理想的には、ERMシステムはこれを必要とする図書館にユーザインターフェースを提供するだけでなく、ERMシステムとは別のシステムの検索結果にしかるべきライセンスデータを組み込む方法も提供するべきである。

理想的なシステムは、Web開発者にデータベースのテーブルまたはビューレベルのアクセスとシステム独自の検索インターフェースを回避する機能を提供して、数多くの設定可能な方法でユーザにデータを提供できるようにするべきである。ERMSの実装は、以下で述べる機能を持つ統合化されたユーザ画面を作成するために、他のシステムが持つしかるべきデータを入手したり他のシステムがサポートしている要素と情報を共有したりすることができる専用のユーザインターフェースを持つべきである。

ERMシステムは、以下の事項が可能であるべきである。

5. OPACやWebサービスを通じて、またはこれらに情報資源に関する情報を提供することにより、著者やタイトル、別タイトル、相互参照、主題、キーワードによる検索やブラウジングといった伝統的な資源発見方法を使用して情報資源を利用できるようにする。パスファインダー、コース別や分野別のWebページ、特定の主題分野や資料種別（電子ジャーナルや論文データベースなど）で選抜した電子資源リストなどのデータベースからの動的な作成を容易にする。さらに、ブランディングやインターフェースの見かけだけに留まらない全面的にカスタマイズ可能な表示テンプレートをサポートする。
6. サポートされているツールのアクセス方法にかかわらず、アクセスした時点のコンテキストに即したライセンス情報を利用者に提供する。
   • 6.1. ライセンスにより利用者がアクセス権限を与えられているか否かを利用者に明確に示す。
   • 6.2. 許可された使用と使用の制限、次のような特別な使用条件を表示する。
     • 6.2.1. 講義資料、コースWebサイト、遠隔教育における使用の許可
     • 6.2.2. ダウンロード数の制限や時刻による制限などの例外的な禁止
     • 6.2.3. 引用の要求
7. ローカルで定義した補助的な記述データをサポートする。次のようなデータが該当する。
   • 7.1. 既存のMARCレコードには定義されていないが記述上必要なためローカルで定義したフィールド
   • 7.2. 自由形式の注記
   • 7.3. ローカルで定義した一覧表や記述子
8. 表示されている情報資源の別バージョンに関する情報を公開し、別バージョンにアクセスできるようにする。たとえば、冊子体版の目録所在情報へのリンクやアクセス可能な全ての電子版へのリンクなど。
9. オンラインインターフェースに関する障害情報を公開する。たとえば、サイトでその旨の表示がないまま一部の資源がアクセス不能または未購読状態になっている、例外的なログイン・ログオフ実行の要求、ナビゲーションやユーザ補助機能の障害など。
10. 資源が利用できなくなったらすぐにその旨のフラグを立てる。理由を書くオプションの注記欄を持つ（管理運用機能を参照のこと）。
11. システム停止予定など日程の決まった情報を提供する。

書誌情報管理に関する要件

多くの図書館では、図書館管理システムや統合検索ポータル、リンクリゾルーションサービスといった様々なシステムに従来の一般的な書誌データと補足的な書誌データが分散して存在しているだろう。しかし、ユニークなデータ要素の保守作業はできる限り1回で済ませられるべきである。動的なデータ共有、または（データの重複保存が避けられない場合は）他のシステムへの伝達により、あるシステムで行われた更新が自動的に他のシステムに反映されるべきである。外部システムで作成されたデータのロード機能もサポートするべきである。

特に、以下が可能であるべきである。

12. OPACやポータルリスト、統合検索ツール、ローカルリゾルーションサービス、その他の書誌関連システムやサービスの間で交換や共有をすることができる書誌データや補足的な記述データを管理保守するための単一の窓口を提供する。
13. 標準的なソフトウェアや策定中のプロトコルを使用して外部プロバイダから提供される次のような購読管理データをインポートする。
    • 13.1. Excelや文字区切り形式のタイトル、ISSN、URIのリスト
    • 13.2. ONIX for serialsなどのXMLベースまたは標準ベースのデータ転送プロトコルにより通知される集約データベースに収録されているタイトルや収録範囲の変更データ
    • 13.3. 電子チェックインを容易にするために出版社や販売代理店から提供される所蔵情報の更新データ

アクセス管理に関する要件

全ての図書館は、本文書で説明されているシステムやツールの外部に存在するユーザ認証やアクセス管理システムに依存している。このような外部システムには、オンラインプロバイダの（IPアドレスやユーザ名とパスワードによる）リモート認証メカニズムに任せるというように簡単なものもあれば、資源に永続的識別子を付与し、（Kerberosなどの）ローカルユーザ認証方式にしたがってユーザを認証してシステムへの接続要求を受け付け、承認ユーザをプロキシサーバを介して接続させるといったローカル開発のアクセス管理サービスのように複雑なものもある。複雑なローカル環境を持つ機関は、これらの機能を実行するカスタマイズされたシステムやツールを持っているものと思われるので、ERMシステムはこれらと連携できなければならない。

ERMシステムは互いに異なる様々なニーズを持つ単純な環境と複雑な環境の両者に対応するべきである。これを実現するために、次の一般的な要件が必要である。

• URI、ユーザIDとパスワード、機関のIPアドレスリストなどのアクセス関連の基本的な情報の管理
• 永続的URIの生成とプロキシサーバなどの複雑なローカルアクセス管理サービスを支援するために必要なデータ要素の追加機能
• ERMSがローカルシステムやサービスに情報を提供することができる一連のデータエクスポート機能

具体的に言えば、次の事項が可能であるべきである。

14. アクセス用のURIを保管･管理し、ローカルの要件にしたがってユーザが利用できるようにする。
    • 14.1. 情報資源にアクセスする際に使用するベンダー提供のプライマリURIとセカンダリURI（ミラーサイトのURIなど）を保管する。
    • 14.2. 永続的URIの生成・保管・更新をサポートする、または永続的識別子を管理する外部システムを統合する。
    • 14.3. 保管されたデータ要素を元にURIをその場で作成するような認証およびアクセス管理システム（プロキシサーバや統計作成スクリプトなど）をサポートする。
    • 14.4. ローカル要件にしたがって、URI情報を適当なリンク済みのシステムまたは外部システムに通知またはエクスポートする（たとえば、目録および情報技術部やシステムへの通知やエクスポート）
    • 14.5. この情報を記録する外部システムとの（共有ポインタなどによる）シームレスな機能統合を行う。
15. プロキシサーバ/アクセス管理システムを他の機能と統合する。
    • 15.1. ユーザの制限や資源の制限を行うためにプロキシサーバアクセスをシームレスに統合する方法を提供する。
16. 特定の情報資源へのアクセスの登録に使用されたIPアドレスリストを保管し、IPアドレスが更新された際は自動的にオンラインプロバイダにメールで通知する。
    • 16.1. 各ロケーションについてライセンスの有無を関連付けることができ、1つ以上の書誌的実体にリンクされた複数のIPアドレスリストの作成・保守をサポートする。
    • 16.2. 指定の情報資源またはオンラインプロバイダについて、IPアドレスがオンライン登録されているか否かを示し、登録用のURIを記録する。
    • 16.3. IPアドレスが更新された際は自動的にベンダーやプロバイダにメールで通知し、通知メールを送信した日付を記録する。受領確認日付を記録する機能を含む。これは、IPアドレスを通知するためのベンダーやプロバイダの連絡アドレスを指定できることを意味する。
17. 1つ以上のユーザIDとパスワードを保管し、関連テキストを使って承認ユーザや職員のこの情報を安全に画面表示する機能またはJavaScriptで自動入力する機能を提供する。
18. アクセス制限を実装する。
    • 18.1. 承認ユーザの種類や承認サイトを記録する。これらの要素に次のような特定の処理を関連付ける機能を含む。
      • 18.1.1. 職員用、ユーザ用画面の作成
      • 18.1.2. アクセスコントロールの実装
      • 18.1.3. ローカルのアクセス管理システム（ユーザ認証システムやプロキシサーバなどの各機関で使用されているシステム）への情報のエクスポート（「情報資源の管理と運用機能」を参照のこと）

職員に関する要件

職員用インターフェース

ERMシステムは、図書館職員がこの後の節で記述する作業を効率的に行えるようにするために職員用のインターフェースを必要とする。このインターフェースは、資源収集、障害対応、ライセンス管理、管理運営、統計などの職員の仕事や関心に合わせて最適化された画面にまとめられるべきである。適切なインターフェースの詳細についてはこの要件では扱わない。これについてはシステム開発者の技術と判断に委ねる。

このインターフェースにより、職員は以下のことができなければならない。

19. ライセンスやベンダー、レコードステータス、認可サイト、コンソーシアム、図書館の選書担当者やその他の連絡担当者など、電子資源に付随するユニークな属性によりレコードを検索、ブラウズ、抽出する。
20. 職員のアクセス権限や機能的役割に適合するあらゆる種類の情報を閲覧する。
21. 図書館管理システムやポータル、その他の関連システムに保管されている関連情報に可能な限りリンクする。
22. 非公開レコードを閲覧する。

選択･評価プロセス

選択･評価プロセスの間は、通常、様々な部署に存在する人々が行う一連の複雑で反復的な作業を調整する必要がある。ERMシステムはこれら各段階の作業を記録し、指定した順で次々に作業を行い、想定された作業が行われない場合は警告をする機能をサポートするべきである。

通常の選択・評価プロセスには次のような段階があり、以下のような注意喚起（リマインダ）と通知が必要である。これらはすべて、指定した作業日とローカルで定義可能なステータスフィールドに基づいて行われる必要がある。

• 試行のためのリクエストレコードを作成する。
• 試行中の情報資源にフラグを立てる。
• 関係者に試行開始を通知し、アクセス方法や試行期限日を知らせる（試行開始日とリクエストレコードに入力されたメールアドレスをトリガとする）。
• 設定したURLから職員（や場合によってはユーザ）が試行サイトにアクセスできるようにする。
• 試行開始を通知した人に試行期限が近づいたこと知らせるリマインダを送付する（試行終了日とリクエストレコードに入力されたメールアドレスをトリガとする）。
• 責任者の意見と最終的な購入判断を記録する。当局と部局双方の意見と予算提供の申し出をリクエストレコードの注記フィールドに入力できるようにする。
• ライセンス処理および収集担当者に購読判断の入力を促す（リクエストレコードに入力された判断日をトリガとする）。最も一般的な選択肢は「承認」「却下」「保留」である。
• 購入が承認された情報資源については、さらに次のようなステータス情報と作業が必要となる。
• ライセンス処理担当者にライセンスの入手と交渉を通知し、指定期限までにライセンス処理が完了しない場合はこの担当者に督促する（入力されたライセンス処理担当者、承認状態の通知日、承認時に入力された期限日をトリガとする）。
• 期限日までにステータス情報が「サービス中」に変更されなかった場合はアクセス担当者に通知する（承認時にシステムに入力された想定アクセス開始日をトリガとする）
• アクセスが可能になったら、目録担当者、選書担当者、予算提供者、その他の関係者に通知する（たとえば、ステータス情報が「サービス中」に変更したことと購入に関係した者のメールアドレスをトリガとする）

付録の「電子情報資源のワークフロー図」では、判断に至る作業手順を詳細な図で示している（付録B参照）。

これらの処理を支援するために、次の事項が可能であるべきである。

23. 収集の可否を判断する対象となる情報資源の暫定的な記録を作成し、収集または却下に至る選択と評価のプロセスを追跡する。
24. リクエストレコードにローカル定義可能なステータスフィールドを付与し、これらのステータスに特定の作業を関連付ける。このようなフィールドの例としては「新規リクエスト」「試行中」「試行終了/判断待ち」「承認」「却下」「保留」がある。
25. リクエストレコードにローカル定義可能なライセンス取得作業とそのステータスを示すフィールドを付与し、これらのフィールドに特定の作業を関連付ける。機関ではたとえば、署名が必要な関係者リストの定義、ライセンス評価者への督促メールの送信、注記つきの承認・却下判断の記録ができるべきである。
26. リクエストレコードと永久保存の情報資源レコードの双方に機関の各担当者とサイトで定義した役割を付与する。
27. 機関の連絡担当者またはライセンス担当者に指名した個人へメール通知を送信する。
28. 図書館が選択する情報資源ツールを使用して、承認ユーザと（必要であれば）職員が情報資源の試行を安全な方法で行えるようにする。
    • 28.1. 試行用URIとパスワードを保管し、これらを、必要に応じて安全な方法で利用できるようにする。
    • 28.2. 対象となるユーザ向け、職員向けの注記をつけ、アイテムが試行中の情報資源であることを明確に示す。
    • 28.3. 試期限日を記録する。オプションとして、試行期限日のn日前に指定した受信者へ警告メールを送信する。
29. 判断期限日を記録する。オプションとして、判断期限のn日前に指定した受信者へ警告メールを送信する。
30. 購入が承認された情報資源に対する機関独自の作業ワークフローを確立する。たとえば、指定した職員や部局への通知書の送付や、指定した職員による発注処理や目録作成、アクセス管理の実行など、その資料に対するさらなる作業を行うために資料を作業キューに置くことが可能であるべきである。
31. 図書館の判断により、却下されたレコードをシステムから消去、履歴アーカイブへ移動、判断プロセスに関する注記を付してレコードを保持（必要であれば書面による評価へのリンクを含む）のいずれかができるようにする。

情報資源の管理･運営機能

本節では、ラインセンス義務を果たし、収集した情報資源を管理・支援するために必要な活動に関する機能を記述する。データや機能の中にはライセンスそれ自体に関するものと個々の情報資源の管理に関するものがある。システムは、実体間の関係を元に他の適当なレベル（個々の情報資源やパッケージ、インターフェースなど）で情報を利用できるようにした上で、冗長性を避けるために必要とされる最も効率的なレベルでデータを記録できなければならない。

以下の事項が可能であるべきである。

32. 参照、報告書作成、サービスの管理をするためにライセンスの権利と契約条件を保管する。
    • 32.1. ILL、コースリザーブ、遠隔教育、コースWebサイト、コースパックなどのサービス（ただし、これに限定しない）について
      • 32.1.1. 指定のタイトルがこれらのサービスで使用できるか、また、どんな条件で使用できるかを特定する。
      • 32.1.2. 全ての資料について、これらのサービスで利用できる否かを条件付きで示した報告書を作成する。
    • 32.2. 新しいサービスを追加する方法を持ち、サービス名とその内容（一般公開、報告、警告など）を職員が指定できるようにする。
33. 指定の情報資源へのアクセスが許可されたユーザとサイトの種類を記録し、この情報に基づいてエンドユーザ用と職員用の画面を生成する（アクセス管理に関する要件を参照のこと）。
34. 不正行為の発見、その対応作業、その他ライセンス義務を果たすために必要となる作業を支援する。
    • 34.1. 不正行為の対応期間を記録し、不正行為が報告された場合、この情報に基づいて図書館指定の間隔で警告を発する。
    • 34.2. 不正行為と思われる行動の報告を記録する不正行為事件ログ（第一報告の日付と情報提供者、処理状態、解決日付、実施措置などを含む）を提供する。これには、不正行為の共通性に関する報告書（不正行為の種類、定期的に不正行為が見られる部局など）を生成できる機能が含まれるべきである。
    • 34.3. 図書館が把握したいと考える一般的ではない順守要件を記録するためのフィールドを追加する仕組みを持つ。記録する内容は、実施状態と実施日付、この情報に基づく報告書や警告の生成機能などである。一般的でない要件の例としては、エンドユーザへの注意の喚起や利用終了時のローカル側保存コピーの破棄などが考えられる（終了作業も参照のこと）
35. 契約管理や監査のために、ライセンス開始日や契約期間、守秘義務条件、その他サイトで定義可能な重要事項などの追加ライセンス条項やメタデータを記録する。
36. ライセンス契約書のオンライン版を表示したり、リンクしたりする機能を提供する。
37. 電子コンテンツに対する図書館のアーカイブ権を管理する。
    • 37.1. 指定の情報資源について年レベルの永続的権利が存在するか否か、存在するとしたら、その情報源、対象巻号範囲、利用方法、権利提供の根拠となるライセンスを記録する。指定の情報資源でアーカイブ用に複数のフィールド群を関連付け、権利が複数のプロバイダに引き継がれても追跡できるようにするべきである。
    • 37.2. 必要に応じてライセンス条項のアーカイブ版を保持し、それ以前に存在した契約条項を書誌実体やその条項が適用された日付に対応付けられるようにする。
38. 電子情報資源の管理を支援する。
    • 38.1. 管理用のURI、IDとパスワード、これらに関係する注記を保管し、担当職員が利用できるようにする。
    • 38.2. 冊子体雑誌に付帯しているオンラインジャーナル版の利用登録に使用する購読者番号を保管する。
    • 38.3. 設定オプションで、機関のブランディング、所蔵情報への接続、Z39.50とOpenURLのサポートなどの機能を提供する。
      • 38.3.1. 指定したタイトルがこれらの機能をサポートしているか、また、実装されているかを関連注記付きで示す。
      • 38.3.2. あらゆる資料について、特定の機能をサポートしているか否かを、実装状態を含めて示す報告書を作成する。
      • 38.3.3. 新しい機能を追加する方法を持ち、機能名や実装状態、注記、報告書作成などの機能の内容を職員が指定できるようにする。
    • 38.4. 指定した情報資源、インターフェース、集合ユーザグループ（集合コンソーシアムユーザを含む）について、ライセンスされた同時利用ユーザ数を記録する。
    • 38.5. 次のような目録作成に関するデータを記録する。
      • 38.5.1. 個々のタイトルを含むパッケージアイテムに関するローディングや優先順の状態、追加注記などを含むMARCレコードの利用の可否とレコード品質。
      • 38.5.2. 該当する場合、目録を担当する個人や部署。
      • 38.5.3. 目録レコードに含まれるべき具体的な記入事項やその他のデータなどを示す関連の仕様。
39. 図書館が行う利用者教育を支援する。
    • 39.1. 教育用アカウント（URI、ID、パスワード）やその他のユーザ教育実施に関する情報を保管し、これらをユーザ教育担当職員や（オプションとして）エンドユーザが安全な方法で利用できるようにする。
    • 39.2. 職員やエンドユーザが利用できる文書に関する情報を記録し、リンクを提供する。
    • 39.3. 講習会に関する情報を記録し、リンクを提供する。
40. 利用統計の管理とアクセスの提供
    • 40.1. 利用統計が提供されているか否かを示し、提供頻度や提供方法、利用可能なフォーマットなど関連するデータを記録する。
    • 40.2. オンライン統計にアクセスするためのURI、IDとパスワードを記録する。
    • 40.3. ローカル保存されている利用データに関する情報やデータへのリンクを保管・提供する。
    • 40.4. ローカル保存の利用統計がある場合、スプレットシートで処理できるようにローカル保存データをダウンロードする機能を提供する。
    • 40.5. 職員が利用データにアクセスするための画面を生成する。
    • 40.6. 利用統計に関する特別な情報（記録のない期間やデータエラーなど）を記入するための注記フィールドを提供する。
    • 40.7. 40.1項で示した提供頻度パラメタに基づいて、利用統計が利用可能になったことを示す報告書や通知文を作成する。
41. アクセスやシステム稼動に関する障害対応を支援する。
    • 41.1. パフォーマンス監視を行うためにライセンス契約で定められた許容システム停止時間または比率を記録する。
    • 41.2. プロバイダによる規定の保守期間に関する情報を保管し、この情報をエンドユーザに表示する機能を持つ。
    • 41.3. パフォーマンス監視を行うローカルのWebサイトやプログラムに関するローカル定義の注記情報を保管する。
    • 41.4. サーバの稼動状況を示すベンダー提供サイトのURIを表示する。
    • 41.5. URIやプロキシ情報、ハードウェアとソフトウェアの要件、ライセンスされた同時利用ユーザ数、購読期限日、（サイトで定義された）ローカルの契約情報、ベンダーの連絡先などを障害対応を行う職員に表示する。
    • 41.6. 一時的に利用できない情報資源にフラグを立て、職員と利用者双方向けの注記をつける機能を提供する。フラグは、個々のタイトル、指定したパッケージの全タイトル、指定したオンラインインターフェースを使用する全タイトルに対して立てることができなければならない（エンドユーザ要件を参照のこと）。
    • 41.7. 問題を記録・追跡するために、第一報告の日付と情報提供者、問題の種類と記述、処理状態、解決日付、実施措置の記録などからなる障害対応ログをシステムに組み込む。
      • 41.7.1. 問題や障害対応報告書のメール通知機能など、次の手を打つために問題発生を適切な担当者に伝える機能を提供する。
      • 41.7.2. サイトで定義した間隔で、未解決問題に対する注意勧告を生成する。
      • 41.7.3. パフォーマンス監視と監査のために情報資源やパッケージ、インターフェース、ベンダーを指定して障害履歴報告書を生成する。
    • 41.8. [望ましい]: ログに記録されたデータに基づいてシステム停止時間を計算し、ライセンス契約で定められた許容システム停止時間（または比率）を超えた場合に警告を発する。
42. ベンダーとの連絡を容易にする。
    • 42.1. ベンダーの複数の担当者の氏名や身分、メールアドレス、電場番号、FAX番号などの情報を記録する。また、サイトが定義した役割を担当者に割り当てる機能を持つ。1人の担当者に複数の役割（技術サポート、顧客サポート、営業、支払いサポートなど）を割り当てることが可能であるべきである。
    • 42.2. ベンダーにIPアドレスとその変更を通知する標準的な文書を生成する機能を提供する。
    • 42.3. 正式な契約通知アドレスと関連する要件（配布要件など）を記録する。
    • 42.4. 障害ログのデータから指定した技術サポート担当者に送るメールを生成する機能を提供する。

ビジネス機能

ここで述べるビジネス活動の多くは、従来の図書館管理システムに存在する機能に関連するものであり、場合によっては既に実現されているかもしれない。本節の44項は、発注や資金会計、予算の計上・管理機能、予算報告書の作成機能といった従来の受入関連機能を支援する一般的要件を確認するものであるが、全ての受入機能は今後も図書館管理システムに留まると思われるので、これらの要件を詳細に記述するつもりはない。ここでの説明は電子資源の管理で独自に必要とされる機能や要素に限定する。

以下の事項が可能であるべきである。

43. 複雑なビジネス情報を職員が利用できるようにする。
    • 43.1. 情報資源に適用可能な価格モデルの記述を保管する。
    • 43.2. 指定した一連の取引条件にどんなライセンス契約が適用できるかを知る。
    • 43.3. パッケージの一部としてどんな冊子体情報資源が購読されるかを知る。
    • 43.4. 冊子体の購読中止が制限されている場合、
      • 43.4.1. この情報を記録する。
      • 43.4.2. システムが冊子体資料をサポートする図書館管理システムに統合されている場合は、冊子体の購読を中止しようとした場合に警告を発する（または、阻止する。ただし、権限を持つ職員は阻止を無効にできる）。
    • 43.5. 複数年契約によるプライスキャップがある場合、
      • 43.5.1. この情報を記録する
      • 43.5.2. 可能であれば、プライスキャップを超過していないことを保証するために更新請求額を算出する。
    • 43.6. システムが冊子体資料をサポートする図書館管理システムに統合されている場合は、更新時に、関連する冊子体購読の継続の可否を評価するよう図書館に促す。
44. 収集処理を容易にする。
    • 44.1. 以下の従来からの収集機能を実行する。
      • 44.1.1. 資金会計
        • 44.1.1.1. 予算の計上、消化、更新
        • 44.1.1.2. 決算報告書の作成
      • 44.1.2. 発注
        • 44.1.2.1. 任意の標準的形式やプロトコルによる発注書の作成と発行。たとえば、文書、メール、X.12やEDIFACT、その他のXMLベースのファイルを使った電子データ交換（EDI）などによる。
        • 44.1.2.2. 発注書は、IPアドレスや有効化の方法など電子資源に特有のサイト定義のデータ要素に対応するべきである。
      • 44.1.3. 請求書による支払い
    • 44.2. 利用や総予算、対象人数、特別な式など、ある種の指標による固定値や比率に基づいて、複数部局や費目で経費を分担する機能をサポートする。
    • 44.3. 前項のアルゴリズムにしたがって異なる予算部局や管理部局が供する複数の資金で支払うこととは反対に、1つの資金や支払費目で支払う機能をサポートする。
45. ライセンス契約におけるコンソーシアム参加者との共同作業を容易にする。
    • 45.1. コンソーシアムを通じて収集した情報資源について、コンソーシアム名と関連注記を記録する。さらにオプションとして、他の参加機関の名称とコンソーシアムに参加することにより利用可能となった資料を記録する。
    • 45.2. コンソーシアムの主な連絡担当者の名前と連絡先を保管する。
46. 購読更新作業を容易にする。
    • 46.1. 有効期限日を記録し、購読更新処理によりこの日付を自動的に更新する。
    • 46.2. 購読更新を事前に知らせる時期を（有効期限日のn日前という形式で）記録し、この情報を元に更新通知日を算出する。
    • 46.3. 購読更新通知日のn日前に関連の注記を付した報告書を作成する。または指定した受信者に警告メールを送付する。（既存の督促機能と同様に）指定の情報資源に上書き可能なシステムのデフォルト時期を設定できるようにするべきである。
    • 46.4. 購読更新処理が自動的に行われるか、明示的に行う必要があるかを記録し、明示的な更新処理が必要な資料については更新日または通知日のn日前に処理指示報告書または警告メールを生成する。
    • 46.5. 購読更新の自動処理または更新決定とその日付を記録する。
    • 46.6. 更新決定に関する書面による評価へのポインタまたはリンクを提供する。
47. 購読中止の作業と判断を容易にする。
    • 47.1. 契約期間中に図書館から購読を中止することができるか否かを記録する。可能である場合は、事前通知期間とその条件（不正行為や具体的な契約不履行など）を記録する。
    • 47.2. 契約期間中にライセンサーから購読を中止することができるか否かを記録する。可能である場合は、事前通知期間とその条件（不正行為や具体的な契約不履行など）を記録する。
    • 47.3. 購読の中止日付と中止理由を保管する。
    • 47.4. 購読中止に関する書面による評価へのポインタまたはリンクを提供する。
    • 47.5. 購読中止の際に果たすべきライセンス条件（ローカル保管コピーの破棄など）を記録し、この情報に基づく警告書を生成する（情報資源の管理･運営機能も参照のこと）。
    • 47.6. 以前にライセンスされていた資料にも適用可能な条項を持つ固定的ライセンスのライセンス情報を保存する機能を提供する。
    • 47.7. 現在の契約終了後の永続的アクセス権を管理、記録、報告する機能を提供する。

先頭に戻る

付録 B: 電子情報資源管理ワークフロー図

Kimberly Parker, Nathan D. M. Robertson, Ivy Anderson, Adam Chandler, Sharon E. Farb, Timothy Jewell, Angela Riggio

はじめに

電子情報資源管理ワークフロー図は、電子製品のライフサイクルを管理する作業の詳細な概要を提供し、ほとんどの機関で行われている処理に対して一般的に適用できることを意図している。ワークフロー図は、電子製品の収集とそれに続く管理に必要な機能とプロセスを明らかにする。従来の物理的な図書館資料の収集･管理プロセスと電子製品のそれには類似点もあるが、電子製品に特有な問題や複雑さが数多く存在する。物理的資料と電子資源のワークフローを示した以下の概観図は両プロセスの類似点と相違点を明らかにしている。

図が示しているように、物理的資料と電子製品の管理には根本的な違いがある。電子製品は定期的なライセンス処理を必要とし、提供する際に技術的な問題が発生する可能性がある。電子製品を収集して有効化する処理は、物理的資料の受付と物理的な処理方法とは本質的に異なるものである。さらに、電子製品に必要な継続的な保守作業や障害対応、ライセンス更新は、物理的資料に必要な閲覧、現物保存、修理などとはまったく異なるものである。

以下に示すワークフロー図では、多くのプロセスが詳細に図示されているが、そうでないプロセスもある。詳細なワークフローが示されているプロセスは、多くの機関が同様な方法で処理していることと、電子製品と物理的資料のプロセスが大幅に異なることを表している。詳細なワークフローが示されていないプロセスは、機関により処理方法が異なるものか、従来のワークフローが電子製品の処理にも（おそらく多少変更することで）利用できるものである。

フローチャート記号

次の図は、完全な電子情報資源管理ワークフロー図である（各図におけるページ参照は図のページを表しており、本付録のページを表しているわけではないことに注意）。図の後に解説を付けた。

注

1. 「処理継続」の判断は、事前の検討プロセスで製品の内容が評価され、製品収集のための本格的な作業を開始すべきであることを示している。
2. 2ページに示されている並行プロセスは試行期間の終了後に行うよう示されているが、もし可能であり、並行する評価プロセスで生ずる疑問に試行が答えるものである場合は、施行期間中に開始しても良い。
3. 「技術的に実現可能か?」の判断は、機関の持つ技術的環境で製品が無理なく機能するか否か、もし機能しない場合は、容認できる程度の努力で製品を機能させることができるか否かの評価を表す。
4. 「ビジネス条件の検討」は広範囲に及ぶ重要な概念を表している。ここで検討するべき項目には、価格、保存の必要性、インターフェースの流れ、ベンダーの質、ブランディングの可能性、利用統計、MARCレコードの利用の可否と（可能な場合）その価格、（可能な場合）教育用のポートとアカウント、OpenURL準拠、直リンク機能などがある。
5. この時点までに既にライセンスに署名されていることやライセンスへの署名が発注処理から完全に分離されている可能性は大いにある。「発注/登録/ライセンスへの正式署名」は、必要なあらゆる点において製品の収集を機関が正式に認めた時点で開始することができる。
6. 目録作成者やサービス管理者（たとえば、プロキシサーバ管理者やOpenURLリゾルバ管理者、公開検索サービス管理者など）に通知する作業は、幾つかの地点で発生する可能性がある。この項目は、ある種の製品がサーバ管理者にとって問題となることや通常早く通知することが非常に有効なことを強調するために、ワークフロー図の早い段階に置かれている。
7. 「製品の定期保守」はここでは詳細に述べていない非常に多岐にわたる機能を含んでいる。この概念に含まれる機能には、利用統計の収集、障害対応と問題解決、ベンダーによる製品の定期的な変更（URLの変更など）、公開文書の改訂などがある。
8. 4ページの「製品再評価」は単に、2ページにある新製品の評価の省略形である。再評価の範囲は、製品や機関ごとに異なるだろう。

先頭に戻る

Appendix C: 電子情報資源管理のための実体関連図

Nathan D. M. Robertson, Ivy Anderson, Adam Chandler, Sharon E. Farb, Timothy Jewell, Kimberly Parker, Angela Riggio

はじめに

本文書は電子資源を管理するシステムのための実体関連図（Entity Relationship Diagram）である。実体関連図はシステムに存在する概念や実体とこれらの間の関連を識別するモデルである。通常、実体関連図は関係データベースを視覚化する方法として使用されている。各実体はデータベースの1つのテーブルを表しており、関連線は1つのテーブルの複数のキーを表しており、これらのキーは関連するテーブルの特定のレコードを指している。実体関連図はさらに抽象化されている場合もあり、この場合は、必ずしもデータベースのすべてのテーブルを扱ってはおらず、主要な概念と関連を簡単に図式化したものである。ここで示す実体関連図は後者のタイプであり、電子資源の管理に必要な主要な実体と関連を抽象的かつ理論的に示すことを目的としている。これは電子情報資源管理システムのデータベース設計プロセスを支援するものであるが、電子資源管理データベースに必要となる全てのテーブルを特定しているものではない。

本実体関連図を読む場合は、DLF/ERMI報告書の他の文書、とりわけ、付録D（データ要素辞書）と付録E（データ構造）を参考にするべきである。実体関連図は電子資源管理の諸概念とその間の関連を視覚的に表現するものである。データ要素辞書は電子資源管理システムが保管・管理しなければならない個々のデータ要素を識別･定義しているが、要素間の関係は読者の判断に任せられている。データ構造は各データ要素を実体関連図に定義されている実体や関連と結びつける。これら3つの文書は合わせて1つの電子資源管理のための完全な概念的データモデルを形成している。

モデルの理解

実体関連図には複数の異なるモデル化システムが存在する。本実体関連図では「情報工学」スタイルを採用している。実体関連図やこのスタイルの記法に不慣れな読者は図を構成する記法を明確にするために以下の節を参考にすると良いだろう。

実体

実体（Entitiy）とは、データモデルにおける概念である。各実体は実体関連図では1つの箱で表現される。実体は抽象的な概念であり、各実体は当該概念の1つ以上のインスタンスを表している。実体はシステムに存在する特定のものの全てのインスタンスを含むコンテナと考えることができるだろう。実体は関係データベースにおけるデータベーステーブルに相当し、テーブルの各行はその実体のインスタンスを表している。

各実体が該当するもののインスタンスのコンテナを表していることを思い出して欲しい。下の図には生徒を表す実体と学校を表す実体がある。これは、モデル化されたシステムが1人以上の生徒と1校以上の学校を含んでいることを示している。

今のところ、生徒と学校の間には関連がないことが示されている。

関連

関連（Relationship）は実体間の線で表現される。関連線はある実体の各インスタンスが結合先の実体のインスタンスと関係を持つこと、およびその逆が成り立つことを示している。

上の図は、今や、生徒が学校と何らかの関係を持っていることを示している。より具体的に言えば、ある特定の生徒（生徒実体の1つのインスタンス）とある特定の学校（学校実体の1つのインスタンス）の間にはある関係が存在する。

必要であれば、関連を定義するラベルを関連線に付けることができる。上の図の場合、生徒が学校に通っていることや学校が生徒を登録していることを推測することができる。そこで、必要であれば、関係を明確にするためにこの関連に次のようにラベルをつけることができる。

関連を左から右、あるいは上から下に見る時は第1の関連定義 通うを読み、関連を右から左、あるいは下から上に見る時は第2の定義登録するを読む。

選択性と濃度

関連線の終端にある記号は、各関連の選択性（Optionality）と濃度（Cardinality）を示している。ここで、「選択性」は関連が任意であるか必須であるかを表し、「濃度」は関連の最大数を表す。

関連線がある実体から別の実体に引かれる際、関連する実体の近くに2つの記号が付く。1つ目の記号は選択性標識である。円（○）は、その関連が任意であること、すなわち、第1の実体の各インスタンスと関連する実体のインスタンスとの間の関連の最小数がゼロであることを示す。円はゼロ、またはオプショナルのオーであると考えることができる。縦棒（｜）は、関連が必須であること、すなわち、第1の実体の各インスタンスと関連する実体のインスタンスとの間の関連の最小数が1であることを示す。

2番目の記号は濃度を示す。縦棒（｜）は関連の最大数が1であることを示す。カラスの足（）は、関連する実体のインスタンスの間にそのような関連が多数存在する場合があることを示す。

次の図は、可能な全ての組み合わせを示している。

先の例で、各学校は多くの生徒を登録する場合もあれば、まったく生徒を登録しない場合もあることを、また、各生徒は丁度1つの学校に通うことを示したいとする。以下の図が、この選択性と濃度を示している。

関連の選択性制約と濃度制約は、モデル化されているシステムに限って適用するものであり、考えられる全てのシステムに適用するものではないことに注意することが重要である。上でモデル化した例について言えば、ある学校はまったく生徒を登録しない場合がある。すなわち、関連は任意である。生徒を登録しない学校はたいした数ではなく、実際、モデル化されているシステムが学籍簿データベースであれば、関連はおそらく必須になるだろう。しかし、モデル化されているシステムが優等生課外特別教育プログラムであれば、そのようなプログラムに参加している生徒が現在1人もいない学校が存在するだろう。モデル化の方法を明確にするには、システムの機能を検討し、データモデルに関する他の文書を参照されたい。

ブリッジ実体

ある実体のインスタンスが別の実体の複数のインスタンスと関係を持ち、その逆も成り立つ場合、多対多の関連と呼ばれる。下の例では、ある供給者は多くの異なる製品を提供でき、各々の製品は多くの供給者により提供されうる。

この関連モデルは完全に正しいが、関係データベースの設計に直接翻訳することができない。関係データベースでは、関連は、関連するテーブルの正しいインスタンスを指すテーブルカラムのキーで表現される。多対多の関連はこの関連表現では表現できない。多対多では、各テーブルの各レコードが別のテーブルの複数のレコードを指す必要があるからである。

この関連を表現する関係データベースを構築するためには、2つの実体の間に各関連インスタンスを一意に表現する橋（ブリッジ）を構築する必要がある。実体関連図ではこれをブリッジ実体（Bridge Entity）でモデル化することができる。ブリッジ実体は内部にひし形を持つ箱で表現され、多対多の関連を置き換える（ひし形は他の実体関連モデル化システムでは関連を示すために使用されているが、多対多のカラスの足型の結合（ブリッジ）であると考えることができるだろう）。

この図は、上の図と同じ関連を表している。提供ブリッジ実体の各インスタンスは、ある供給者がある製品を提供することができることを示している。

多対多の関連に対応できる関係データベース構造を明確に示す機能に加えて、ブリッジ実体は抽象的な実体/関連のモデル化でもう1つの機能を持っている。すなわち、ブリッジ実体は、ブリッジされる実体のインスタンス間の関連に特有な属性を示すことができることである。供給者と製品の例では、製品が固有の価格を持っておらず、それを売る供給者に応じて価格が決まる場合である。同様に、供給者は統一的な出荷日を持っておらず、出荷日は出荷する製品により変化する場合である。このような関連に依存する属性は全て、関連のブリッジ実体に関連付けられることになる。

再帰的関連

実体のインスタンスが同じ実体の別のインスタンスと関連を持つ場合がある。これらの関連は開始点と終了点が同じ実体に結合される関連線で描かれる。この再帰的関連は親子の関連でよく見られる。

上の図は、ある人は0人または多くの人の父親であり、また、ある人は0人または1人の人の子供であることを示している。（全ての人の父親がシステムに記録されているわけではないので、関連は任意としてモデル化されている。）

実体間の複数の関連

ある実体が別の実体と複数の関連を持つ場合がある。これは、実体関連図では2つの実体を複数の関連線で結ぶことにより表現される。

上の図は、ある従業員は0人または多くの顧客を持つ販売員であり、ある従業員は0人または多くの顧客を持つ顧客サービス担当者であることを示している。各顧客は丁度1人の販売員と丁度1人の顧客サービス担当者を持っている。各顧客の販売員は、その顧客の顧客サービス担当者と同じ場合もあれば、違う場合もある。すなわち、各関連は独立に扱われる。

実体サブタイプ

あるもののクラス全体に適用する関連を示すだけでなく、大きなクラスの特定のタイプのみに適用する関連を示すと便利な場合がある。実体サブタイプはこの種の関連を示すのに適している。実体関連図では、実体サブタイプはより大きな実体箱の中に描かれる実体箱により表現される。大きな実体はクラスを表し、より小さい箱はサブクラスを示す。

上の例は、車と部品というサブタイプを持つ在庫品目実体を示している。車は1つ以上の部品を持ち、全ての部品は1つの、そして1つだけの種類の車に関連付けられている（この図に従うと、交換可能な部品は存在しない）。在庫品目の全てのアイテムは、車であれ部品であれ、1つの生産場所を持っているが、車のみが特定のモデルのものとなる。

排他的論理和関連

ある実体のインスタンスが、2つの関連の内どちらか一方の関連は持つが両方の関連は持たない場合、この制約は、その点で木が枝分かれする黒丸を持つ木で表現される排他的論理和関連でモデル化される。木の幹に結合された実体が排他的論理和制約に従う実体である。枝に結合された実体の間の関連は示されない。

上の図は、各受刑者には、1つの刑務所か1人の保護監察官が割り当てられているが、両方は割り当てられていないことを示している。1つの刑務所は0人以上の受刑者を持つことができ、1人の保護監察官は0人以上の受刑者を持つことができる。そして、刑務所と保護監察官の間には何の関係もない。

包括的論理和関連

ある実体のインスタンスが1つかそれ以上の関連を持つことができるが、考えられる少なくとも1つの関連を持たなければならない場合、この制約は、その点で木が枝分かれする白丸を持つ木で表現される包括的論理和関連でモデル化される。排他的論理和制約同様、木の幹に結合された実体が包括的論理和制約に従う実体であり、枝に結合された実体は、この制約に関して互いに何の関係も持たない。

上の図では、農場は家畜か作物のどちらかを持たねばならないが、両方を持つことも可能である。任意の種類の家畜は0以上の農場に所属することができ、任意の種類の作物は0以上の農場で栽培されることが可能である。

電子情報資源管理のための実体関連図

下の図は、電子情報資源管理のための完全な実体関連図である。これは、電子資源の管理に必要となる主要な実体と関連を抽象的かつ理論的に表現したものである。

付加的な関連継承制約

他のモデル化システムとは異なり、実体関連図は、実体インスタンスが関連する実体インスタンスの属性や関連を継承することを期待される状況を明確に示すことがない。

このデータモデルは次のような関連継承制約を仮定している。

• 電子資源はそのインターフェースが持つ収集、管理情報、アクセス情報との関連を継承することができる。また、電子資源はそのインターフェストとは異なる収集、管理情報、アクセス情報との関連を持つこともできる。
• 電子資源はそのインターフェースが持つライセンス（およびインターフェースのライセンスで定義されている条項。ただし、別のライセンスの別の条項がその電子資源に関して優先する場合もある）との関連を継承しなければならない。
• 電子資源はその親である電子資源が持つ収集、管理情報、アクセス情報との関連を継承することができる。また、子である電子資源はその親とは異なる収集、管理情報、アクセス情報との関連を持つこともできる。
• 電子資源はその親である電子資源が持つインターフェースのライセンス（および親のライセンスで定義された条項。ただし、別のライセンスの別の条項が子の電子資源に関して優先する場合もある）との関連を継承しなければならない。

複雑な関連や概念の説明

全体図は大きくて複雑ではあるが、実体関連図に示されているほとんどの実体と関連は比較的簡単であり、付録D（データ要素辞書）と付録E（データ構造）で提供されている定義を参照すれば完全に理解することが可能である。

しかし、いくつかの関連についてはさらに説明する必要があるだろう。

電子製品とそのサブタイプ

電子製品実体は、収集、ライセンス取得、管理される電子的なものを表している。電子製品はインターフェース、電子資源パッケージ、パッケージのパッケージ、個々の電子資源タイトルを含んでいる。

電子製品は、インターフェースであれ、パッケージであれ、個々のタイトルであれ、多くの属性や関連が全ての電子製品により共有されている。たとえば、あらゆる種類の電子製品はライセンスを受けたり、収集したり、製品の試行を行ったりすることが可能である。一方、インターフェースと電子資源はある種のユニークな特徴を持ち、場合によっては、異なる方法で扱う必要がある。電子製品実体とそのサブタイプはこれらの関係を示すのに適している。

電子資源の再帰的関連

電子資源実体は、電子資源のパッケージ、パッケージのパッケージ、個々の電子資源タイトルを表している。任意の電子資源タイトルは個別の製品である場合もあれば、電子資源パッケージの一部である場合もある。電子資源パッケージもさらに大きなパッケージの一部になりうる。これらの考えうる関係は、電子資源に関する任意の再帰的関連で表現されている。

組織実体

組織実体は、電子製品に関して図書館が取引を行う任意の会社、ベンダー、プロバイダ、出版社、ライセンサーなどを表している。一般に、組織が果たす役割に関係なく、名称や住所など組織に関する同一の属性を記録する。さらに、1つの組織がベンダーやライセンサー、出版社、プロバイダとして機能するなど、電子資源の管理環境において複数の役割を果たすことも多い。

このモデルでは（互いに重複したインスタンスを持つことになるので）役割ごとに別の実体を作成するのではなく、1つの組織には1つの組織実体を割り当て、その組織が関わる関連に基づいて1つ以上の役割を持つようにしている。

この関連で示されている複数の役割の詳細については、付録D（データ要素辞書）と付録E（データ構造）を参照のこと。

規定条項と優先条項

各ライセンスと各収集は、そのライセンスや収集でカバーされる電子製品の利用と管理に関する一連の権利と制限を規定する（または規定できる）。時には、ある条項がライセンスで規定されているのに、同じ概念の条項がビジネス契約書でも規定されている場合がある。特定の権利や義務、その他の条項がどこで規定されているのかがはっきりしないような状況に対応するために、我々のモデルでは独立した規定条項実体を設けた。

規定条項実体は、考えられる全ての権利や義務、（「ILL」や「学術的共有」の許可など）通常ライセンスで規定されている条項や（「同時利用ユーザ数」など）通常収集条項やビジネス条項で規定されている条項などを記録することができる。

各収集は高々1つの規定条項インスタンスを規定することができる。各ライセンスは高々1つの規定条項インスタンスを規定することができる。各規定条項インスタンスは1つの収集、または1つのライセンスのいずれかで規定される。この関連は排他的論理和関連を使ってモデル化されている。

指定した電子資源の利用、権利、制限が、法的なライセンス条項と交渉による収集条件を表す複数の契約で規定されている場合がある。各収集は1組の条件を規定し、各ライセンスも1組の条項を規定している。各電子製品の収集との関連と1つ以上のライセンスとの関連により、各電子資源に適用する全ての規定条項インスタンスを知ることが可能である。

指定した電子製品に適用する規定条項インスタンスの中には、個々の条項に矛盾が生ずる場合がある。これは、複数のライセンス契約が1つの電子製品を対象としている場合に特に生じる可能性が高い。そのような場合、矛盾する条項のうちどれが指定した電子製品に対して優先するかを決める必要がある。これは優先条項実体とその規定条項実体との関連を使ってモデル化されている。

優先条項実体は、規定条項実体とまったく同じように、考えられるすべての条項を表している。ただし、各条項は単に優先する規定条項を指しているだけである。上の図では4本の関連線で示されているが、実際は多くの関連を表している。1本が1つの規定条項を表している。各電子製品は、条件を定める多くの収集やライセンスで規定されている場合もあるが、すべて高々1揃えの優先条項で規定されている。

結論

本実体関連図は電子資源の管理に必要な主な概念と関連を図示するものである。必要な全ての関係データベース表を示している完全なデータモデルではないし、電子情報資源管理システムを実装するための排他的設計図になることを意図したものでもない。必要となる属性と関連を表現するには別のモデルがふさわしい可能性もある。本文書がDLF/ERMI報告書を構成する他の文書と共に、電子情報資源管理システムが対応しなければならない環境の複雑性を開発者が想定する一助となり、欠くべからざる関連や機能が電子情報資源管理システム製品に含まれるようになることを保証することを期待する。

先頭に戻る

Appendix D: データ要素辞書

Angela Riggio, Ivy Anderson, Adam Chandler, Sharon E. Farb, Timothy Jewell, Kimberly Parker, Nathan D. M. Robertson

はじめに

DLF/ERMIの作業の中で、データ要素辞書は基本的な参照文書の役割を果たすものであり、データ要素の属性と要素間の関連を表しているデータ構造（付録E）とシステムで使用されるデータ要素群に見られる概念相互の関係を定義している実体関連図（付録C）を補完するものである。

データ要素辞書は、4つの項目からなる非常に単純な構成でできている。データ要素名は、この辞書の各要素に与えられた名称である。識別子は、他のプログラムが特定の要素を識別するための名前である。たとえば、要素「電子製品の役割」はXMLスキーマで使用される際には「eprole」と呼ばれることになる。データ要素の定義は、各要素の解説である。要素名と定義についてはできる限りISO 11179『データ要素の仕様と標準』に準拠するよう努めた。データ要素辞書は、そのデータ要素の設定値の例を挙げたり、そのデータ要素が使用される状況を記述するオプションの注記欄も持っている。また、この欄では、そのデータ要素の定義を流用した他の標準を示したり、電子情報資源管理システムにおいてその要素に値を入力する際に使用するべき標準を推奨したりしている。

DLF電子情報資源管理イニシアティブ
データ要素辞書

• ブリッジ（ブリッジ実体）: ブリッジ実体は、2つの実体が多対多の関連でリンク付けされている場合に、個々の単一の関連を一意に表現することを可能にする。また、各個別の関連にユニークな属性を表すこともできる（より詳しくは、付録C「電子情報資源管理のための実体関連図」を参照のこと）
• コンソーシアム: 特定の電子製品を共同購入する契約に参加した2つ以上の図書館や組織からなるグループ
• 電子製品: 本モデルでは、電子製品はスーパークラスを表しており、電子情報資源実体とインターフェース実体から成る（より詳しくは、付録E「電子情報資源管理システムのデータ構造」を参照のこと）
• 電子情報資源: コンピュータにより操作されるように符号化された資料で、テキストや音源、画像、数値データ、コンピュータプログラムなどを単独または組み合わせて含んでいる。また、コンピュータに直接接続された周辺装置（CD-ROMドライブやプレイヤなど）の使用を必要とする資料やコンピュータネットワーク（インターネットなど）への接続が必要な資料も含む。AACR2による。
• 実体: データモデルにおける高水準な概念。実体は、関係データベースにおけるテーブルで表現することができる（より詳しくは、付録C「電子情報資源管理のための実体関連図」を参照のこと）
• 外部リンク: 製品内でコンテキストに即した外部情報資源へ導くハイパーリンクを提供すること
• インターフェース: 特定の電子情報資源を利用可能にするソフトウェアプラットフォームまたはWebサイト
• IPアドレス: インターネットを通じて情報の送受信を行うネットワーク、ノード、サーバ、個々のワークステーションを識別する番号
• オンライン管理モジュール: プロバイダにより提供される管理用インターフェースであり、これを使って図書館職員は電子製品の公開インターフェースをローカルの仕様にあわせて変更することができる
• プラットフォーム同時接続ユーザ: インターフェースに同時にアクセスできるユーザ数の制限。この数は、インターフェースに含まれる個々の情報資源に設定されているユーザ制限数とは異なる。利用可能なインターフェースに対するユーザ数の一部あるいは全てを他の資料が使用している場合、特定の資料へのアクセスに影響を与える場合がある。
• 集合ユーザ: パートナー図書館グループで共有されている同時利用ユーザの制限数。1つの機関が利用可能な集合ユーザ数を全て使用することが常に可能である。本モデルでは、通常、集合ユーザはコンソーシアム内で共有されている。
• 冊子体版: 電子情報資源の紙媒体による形態であり、電子コンテンツの元となっている場合が多い。
• プロバイダ: 電子コンテンツへの電子的アクセスを提供する組織又またはサービス
• 出版者: 製品に含まれる情報の生産を行う組織
• 関連版: 電子情報資源の印刷などによる有形な形態であり、電子コンテンツの元となっている場合が多い。
• 購読者ブランディング: 電子情報資源に表示された購読者の名称や識別子、ロゴ、記号であり、購読者が特定の機関やユーザグループにその情報資源の利用を提供している団体であることを示す。
• 統一資源識別子（URI）: 電子情報資源のアクセス法、ロケーション、ファイル名を特定する。
• 統一資源位置子（URL）: URIの一種で、インターネット上に存在するファイルのロケーションを示す。
• ベンダー: 電子情報資源の支払いを受け取る組織

先頭に戻る

Appendix E: 電子情報資源管理システムのデータ構造

Kimberly Parker, Ivy Anderson, Adam Chandler, Sharon E. Farb, Timothy Jewell, Angela Riggio, Nathan D. M. Robertson

目次

• はじめに
• 電子製品セット
• 電子情報資源実体
  • 電子情報資源ID
• 電子情報資源実体識別グループ
  • 電子情報資源の関連作品
  • 電子情報資源の収集
  • 電子情報資源優先条項
  • 電子情報資源アクセス情報
  • 電子情報資源管理情報
  • OCLC番号
  • 電子版ISSN
  • 電子版ISBN
  • ジタルオブジェクト識別子
  • ローカルシステム番号
  • 購読識別子
  • その他の識別情報源
  • その他の識別番号
• 電子情報資源実体タイトルグループ
• 電子情報資源タイトル
• 電子情報資源別タイトル
• 電子情報資源実体リンク化資源グループ
  • 電子情報資源インターフェース
  • 集合電子情報資源
  • 電子情報資源要素
• 電子情報資源実体その他の記述グループ
  • 電子情報資源パッケージ種別
  • 言語
  • フォーマット
  • 資源種別
  • データ更新頻度
  • 説明
  • 一般注記
• 電子情報資源実体所蔵グループ
  • 電子所蔵情報
  • エンバーゴ期間
• 電子情報資源実体状態グループ
  • 電子情報資源状態
  • 電子情報資源制限表示
• インターフェース実体
• インターフェースID
• インターフェース収集
• インターフェース優先条項
• インターフェースアクセス情報
• インターフェース管理情報
• インターフェース名
• インターフェースデジタルオブジェクト識別子
• インターフェースその他の識別情報源
• インターフェースその他の識別番号
• インターフェースプロバイダ
• 媒体
• インターフェース状態
• インターフェース一般注記
• 収集実体
  • 収集ID
• 収集実体識別グループ
  • 収集ベンダー
  • 発注番号
• 収集実体コンソーシアムグループ
  • コンソーシアム契約表示
• 収集実体更新・終了グループ
  • 購読更新日
  • 購読更新警告
  • 更新状態
  • 更新判断日
  • 終了日
  • 終了理由
• 収集実体価格・支払いグループ
  • 価格
  • 価格値引き
  • 価格モデル
  • 冊子体中止制限表示
  • 冊子体中止注記
  • プライスキャップ
  • 支払明細
  • 支払注記
• 収集実体ローカルグループ
  • 収集注記
  • ローカル定義の収集フィールド
• ライセンス実体
  • ライセンスID
• ライセンス実体識別グループ
  • ライセンス名
  • ライセンス種別
  • ライセンスURI
  • ライセンスURI種別
  • 物理的ライセンス保管場所
• ライセンス実体評価グループ
  • ライセンス状態
  • ライセンス評価者
  • ライセンス評価者注記
  • ライセンス注記
• ライセンス実体日付グループ
  • ライセンス締結日
  • ライセンス開始日
  • ライセンス終了日
  • ライセンス終了日警告
  • ライセンス期間
• ライセンス実体関係者グループ
  • ライセンサー
  • ライセンシー
  • ライセンス代行者
  • ライセンス配布指示
• ライセンス実体リンク化ライセンスグループ
  • 後継ライセンス
  • 先行ライセンス
• 電子製品/ライセンス間ブリッジ実体
  • 電子情報資源ライセンスID
  • ライセンスされた電子情報資源
  • ライセンスされたインターフェース
  • 電子製品用ライセンス
• 規定条項実体
  • 規定条項ID
• 規定条項実体識別グループ
  • 条項作成収集
  • 条項作成ライセンス
• 規定条項実体金額グループ
  • 金額
  • 金額注記
• 規定条項実体承認ユーザグループ
  • 承認ユーザ定義
  • ローカル承認ユーザ定義表示
• 規定条項実体利用条件グループ
  • 公正利用条項表示
  • 著作権保有表示
  • データベース保護無効化条項表示
  • 引用要求詳細
  • デジタル複製
  • デジタル複製条項注記
  • 印刷複写
  • 印刷複写条項注記
  • 学術的共有
  • 学術的共有注記
  • 遠隔教育
  • 遠隔教育注記
  • プリント・ファックスILL
  • セキュアなデジタル送信ILL
  • デジタル複製ILL
  • ILL記録保管要求表示
  • ILL条項注記
  • 冊子体コースリザーブ
  • デジタルコースリザーブ
  • コースリザーブ条項注記
  • デジタルリンク
  • デジタルリンク条項注記
  • 冊子体コースパック
  • デジタルコースパック
  • コースパック条項注記
  • リモートアクセス
  • ウォークインユーザ条項注記
  • ローカル利用許諾条項フィールド
• 規定条項実体制限グループ
  • 同時利用ユーザ
  • 集合同時利用ユーザ
  • 同時利用ユーザ注記
  • その他のユーザ制限注記
  • その他の利用制限注記
• 規定条項実体恒久的権利グループ
  • 恒久的アクセス権
  • 恒久的アクセス所蔵
  • 恒久的アクセス注記
  • アーカイブ権
  • アーカイブフォーマット
  • アーカイブ注記
• 規定条項実体義務グループ
  • アクセシビリティ準拠表示
  • コンテンツ完全性明示条項表示
  • 冊子体との同時提供条項表示
  • 知的財産権保証表示
  • ユーザ情報守秘義務表示
  • UCITA無効化条項表示
  • クリックラップ無効化条項表示
  • ライセンサー賠償条項
  • ライセンシー賠償条項表示
  • 賠償条項注記
  • 契約守秘義務
  • 契約守秘義務注記
  • 準拠法
  • 裁判権管轄
  • 適用著作権法
  • 不正利用対応期間
  • 不正利用対応期間指定単位
  • コンテンツ保証
  • パフォーマンス保証表示
  • パフォーマンス保証稼動率
  • 定期保守日
  • 更新種別
  • 非更新通知期間
  • 非更新通知期間指定単位
• 規定条項実体終了時義務グループ
  • ライセンシー終了権利表示
  • ライセンシー終了条件
  • ライセンシー終了通知期間
  • ライセンシー終了通知期間指定単位
  • ライセンサー終了権利表示
  • ライセンサー終了条件
  • ライセンサー終了通知期間
  • ライセンサー終了通知期間指定単位
  • 終了権注記
  • 終了要件
  • 終了要件注記
• 規定条項実体注記グループ
  • 条項注記
  • ローカル利用条項フィールド
• 優先条項実体
  • 優先条項ID
• 優先条項実体金額グループ
  • 優先金額
  • 優先金額注記
• 優先条項実体承認ユーザグループ
  • 優先承認ユーザ定義
  • 優先ローカル承認ユーザ定義表示
• 優先条項実体利用条件グループ
  • 優先公正利用条項表示
  • 優先著作権保有表示
  • 優先データベース保護無効化条項表示
  • 優先引用要求詳細
  • 優先デジタル複製
  • 優先デジタル複製条項注記
  • 優先印刷複写
  • 優先印刷複写条項注記
  • 優先学術的共有
  • 優先学術的共有注記
  • 優先遠隔教育
  • 優先遠隔教育注記
  • 優先プリント･ファックスILL
  • 優先セキュアなデジタル送信ILL
  • 優先デジタル複製ILL
  • 優先ILL記録保管要求表示
  • 優先ILL条項注記
  • 優先冊子体コースリザーブ
  • 優先デジタルコースリザーブ
  • 優先コースリザーブ条項注記
  • 優先デジタルリンク
  • 優先デジタルリンク条項注記
  • 優先冊子体コースパック
  • 優先デジタルコースパック
  • 優先コースパック条項注記
  • 優先リモートアクセス
  • 優先ウォークインユーザ条項注記
  • 優先ローカル利用許諾条項フィールド
• 優先条項実体制限グループ
  • 優先同時利用ユーザ
  • 優先集合同時利用ユーザ
  • 優先同時利用ユーザ注記
  • 優先その他のユーザ制限注記
  • 優先その他の利用制限注記
• 優先条項実体恒久的権利グループ
  • 優先恒久的アクセス権
  • 優先恒久的アクセス所蔵
  • 優先恒久的アクセス注記
  • 優先アーカイブ権
  • 優先アーカイブフォーマット
  • 優先アーカイブ注記
• 優先条項実体義務グループ
  • 優先アクセシビリティ準拠表示
  • 優先コンテンツ完全性明示条項表示
  • 優先冊子体同時提供条項表示
  • 優先知的財産権保証表示
  • 優先ユーザ情報守秘義務表示
  • 優先UCITA無効化条項表示
  • 優先クリックラップ無効化条項表示
  • 優先ライセンサー賠償条項
  • 優先ライセンシー賠償条項表示
  • 優先賠償条項注記
  • 優先契約守秘義務
  • 優先契約守秘義務注記
  • 優先準拠法
  • 優先裁判権管轄
  • 優先適用著作権法
  • 優先不正利用対応期間
  • 優先不正利用対応期間指定単位
  • 優先コンテンツ保証
  • 優先パフォーマンス保証表示
  • 優先パフォーマンス保証稼動率
  • 優先定期保守日
  • 優先更新種別
  • 優先非更新通知期間
  • 優先非更新通知期間指定単位
• 優先条項実体終了時義務グループ
  • 優先ライセンシー終了権利表示
  • 優先ライセンシー終了条件
  • 優先ライセンシー終了通知期間
  • 優先ライセンシー終了通知期間指定単位
  • 優先ライセンサー終了権利表示
  • 優先ライセンサー終了条件
  • 優先ライセンサー終了通知期間
  • 優先ライセンサー終了通知期間指定単位
  • 優先終了権注記
  • 優先終了要件
  • 優先終了要件注記
• 優先条項実体注記グループ
  • 優先条項注記
  • 優先ローカル利用条項フィールド
• ユーザグループ実体
  • ユーザグループ識別子
  • ユーザ身分
  • ユーザプロキシ情報
  • ユーザ注記
• 利用可能ユーザブリッジ実体
  • 利用可能ユーザID
  • ユーザグループ関連条項レコード
  • 条項関連ユーザグループ
  • ユーザグループ許諾の法的解釈
  • ユーザグループ許諾の運用値
• ロケーション実体
  • ロケーションID
  • ロケーション名
  • ロケーションIPサブセット
  • ロケーションプロキシ情報
  • ロケーション注記
• 利用可能ロケーションブリッジ実体
  • 利用可能ロケーションID
  • 利用可能ロケーション条項
  • 条項指定ロケーション
  • ロケーション許諾の法的解釈
  • ロケーション許諾の運用値
• アクセス情報実体
  • アクセス情報ID
• アクセス情報実体識別グループ
  • プライマリアクセスURI
  • プライマリアクセスURI種別
  • 代替URI
  • 代替URI種別
  • ローカル永続的URI
  • ローカル永続的URI種別
• アクセス情報実体認証グループ
  • 採用認証方式
  • 代替認証方式
  • 電子製品ユーザ識別子
  • 電子製品ユーザパスワード
  • 電子製品ローカルユーザ識別子
  • 電子製品ユーザパスワード注記
  • IPアドレス登録方式
  • IPアドレス登録指示
  • 登録IPアドレス
  • IPアドレス登録日
  • IPアドレス一般注記
  • アクセス情報注記
• アクセス情報実体プロキシグループ
  • プロキシサーバ使用表示
  • プロキシ登録状態
  • ドメイン名
• アクセス情報実体Z39.50グループ
  • Z39.50アドレス
  • Z39.50ポート
  • Z39.50属性
  • Z39.50接続URI情報
  • Z39.50データベース名
  • Z39.50データベース短縮名
  • Z39.50認証情報
• 管理情報実体
  • 管理情報ID
• 管理情報実体識別グループ
  • 管理URI
  • 管理URI種別
  • 管理識別子
  • 管理パスワード
  • 管理パスワード注記
• 管理情報実体設定グループ
  • セッションタイムアウト設定表示
  • セッションタイムアウト値
  • ログアウトURI表示
  • ログアウトURI値
  • ログアウトURI種別
  • ユーザインターフェース設定表示
  • 購読者ブランディング表示
  • 購読者ブランディング利用状態表示
  • 購読者ブランディング注記
  • パーソナル化サービス表示
  • Z39.50表示
  • 所蔵情報フック表示
  • 所蔵リンク使用表示
  • プロバイダ参照リンク表示
  • 内部リンク表示
  • 内部リンク使用状態表示
  • OpenURL準拠表示
  • OpenURL使用状態表示
  • リンキング注記
  • MARCレコード利用可能性表示
  • MARCレコード注記
  • インターフェース多言語化表示
  • 採用インターフェース言語
  • ローカル利用管理フィールド
• 管理情報実体利用統計グループ
  • 利用統計提供表示
  • 統計標準準拠
  • 利用統計提供方法
  • 利用統計フォーマット
  • 利用統計頻度
  • 利用統計オンラインロケーション
  • 利用統計ユーザ識別子
  • 利用統計パスワード
  • 利用統計受取人
  • 利用統計注記
  • 利用統計ローカル保管
• 管理情報実体サポートグループ
  • ハードウェア要件
  • ソフトウェア要件
  • 定期保守時間
  • プロバイダシステム状態提供URI
  • プロバイダシステム状態提供URI種別
  • 製品使用不能表示
  • 製品報告注記
  • ローカルパフォーマンス監視注記
  • 事故ログ
  • 講習会情報
  • 管理文書
  • ユーザ文書
• 処理ワークフロー実体
  • 処理ID
• 処理ワークフロー実体識別グループ
  • 対象インターフェース
  • 対象電子情報資源
• 処理ワークフロー実体選択前グループ
  • 電子製品選択前想定判断日
  • 電子製品選択前経費情報
  • 電子製品評価履歴
  • 電子製品選択前注記
• 処理ワークフロー実体工程グループ
  • 発注依頼日
  • 発注依頼注記
  • 認証状態
  • Z39.50アクセス状態
  • 目録作業依頼日付
  • 目録優先度
  • アクセス確認表示
  • アクセステスト日
  • ローカルサービス状態
  • インターフェースカスタマイズ状況
  • 広報状態
  • 教育ツール状態
  • 一般公開状態
  • 利用データ設定状態
  • 処理中注記
• 処理ワークフロー実体更新･終了グループ
  • 電子製品更新評価状況
  • 電子製品更新想定判断日
  • 電子製品更新評価状況注記
  • 電子製品評価履歴
  • 電子製品終了状況
  • 電子製品終了状況注記
• ワークフロー規則実体
• 試行実体
• 試行ID
• 試行電子情報資源
• 試行インターフェース
• 試行URI
• 試行URI種別
• 試行ユーザ名
• 試行パスワード
• 試行開始日
• 試行終了日
• 試行公開表示
• 試行要ライセンス表示
• 試行注記
• コンソーシアム実体
  • コンソーシアムID
  • コンソーシアム名
  • コンソーシアム別名
  • コンソーシアム住所
  • コンソーシアム注記
• パートナー図書館実体
  • パートナー図書館ID
  • パートナー図書館名
  • パートナー図書館別名
  • パートナー図書館住所
  • パートナー図書館IP範囲
  • パートナー図書館注記
• コンソーシアム/参加館ブリッジ実体
  • コンソーシアム参加館ID
  • コンソーシアム収集
  • 収集コンソーシアム
  • コンソーシアムパートナー
  • コンソーシアム資金貢献
  • コンソーシアム参加機関数
  • コンソーシアム課題注記
• 図書館実体
  • 図書館ID
  • 図書館名
  • 図書館別名
  • 図書館住所
  • 図書館ロケーション
  • プロキシ情報
  • 図書館注記
• 図書館/収集ブリッジ実体
  • 図書館収集ID
  • 被対象収集
  • 協力図書館
  • 経費負担
  • 経費負担率
  • 経費負担注記
• 組織実体
• 組織ID
• 組織名
• 組織別名
• 組織住所
• ライセンサー通知住所
• 組織注記
• 組織/図書館ブリッジ実体
  • 組織/図書館ブリッジID
  • 図書館の協働組織
  • 組織の協働図書館
  • 図書館のアカウント識別子
• 連絡担当者実体
  • 連絡担当者ID
  • 連絡担当者名
  • 連絡担当者身分
  • 連絡担当者住所
  • 連絡担当者メールアドレス
  • 連絡担当者電話番号
  • 連絡担当者ファックス番号
  • 連絡担当者役割
  • 被代表組織
  • 被代表コンソーシアム
  • 被代表図書館
  • 被代表パートナー図書館
• 連絡担当者/担当ブリッジ実体
  • 連絡担当者担当ID
  • 連絡担当者
  • 担当電子情報資源
  • 担当インターフェース
  • 担当ライセンス
  • 担当収集
  • 電子製品役割
• 作品実体
  • 作品ID
  • 電子情報資源継続前タイトル
  • 電子情報資源継続後タイトル
  • 国際標準テキストコード
  • 主題
  • 統一タイトル
  • 著者
• 関連版実体
  • 関連版ID
  • 関連版関係作品
  • 関連版タイトル
  • 冊子体ISBN
  • 冊子体ISSN
  • ローカルレコード番号
  • 冊子体価格
  • 冊子体購読識別子
• 付録 A1 連絡担当者役割
• 付録 A2 ユーザグループ
• 注
• 実体・グループ・要素索引

はじめに

本文書は、「実体関連図」と「データ要素辞書」の関係を理解･解釈するためのデータ構造とサポートツールである。「データ構造」は、「機能要件」に取り上げられている機能仕様と「ワークフロー図」で説明されているワークフローに対応する形で「データ要素辞書」で定義されている要素を「実体関連図」で定義されている実体に対応付けるものである。データモデルの一部として、「データ構造」は絶対的な規範になることは意図していない。システム設計者は要素と実体を統合する独自のアプローチを自由に開発するべきである。ただし、設計者には以下のアプローチの概念から大幅に逸脱することのないよう忠告する。どんなに逸脱したとしてもデータの共有と移行という目的のために変更を余儀なくされるからである。

以下の情報は、「電子情報資源管理システムのデータ構造」のデータモデルの表現を理解する一助となるだろう。

データ要素と定義は「データ要素辞書」からできるだけ変更することなく使用した。しかし、概念が重複している要素（優先条項実体の要素など）や（実質的には他の実体への参照である）ポインタなど、「データ要素辞書」にリストされていないものもある。

要素種別は、テキスト、数値、論理値、日付、ユニークID、ポインタに限定した。ユニークIDは各実体のレコード識別子としてのみ使用した。ポインタは、ポインタを持つ実体が必要とする情報を提供する、または関連の種類を規定する別の実体のID要素である。たとえば、1対多の関連では、関連の「多」の方の実体で「1」の方の実体のIDへのポインタをリストする必要がある。

システム用途/機能欄は、システムソフトウェアがその要素を使用または処理する方法、およびその要素が満たすべき機能を説明するために使用した。「機能要件」の項番への参照を、実体の注記欄（全ての実体が満たすべき仕様）またはシステム用途/機能欄に示した。「機能要件」の項番参照は"FR#.#"の形式で表示し、本表に記載されていない項番については付録の注で解説した。各要素の全ての機能的用途が説明されているわけではないが、「データ構造」の注記はデータモデルと「機能要件」文書の対応関係を指摘することを意図している。システム用途/機能欄のもう一つの用途は、ペアやグループを形成する要素の結合を記録することである。ある種のペアやグループは単純な論理的関係にある。たとえば、測定単位は、それで測定されているアイテムを記録する要素に結び付けられているはずである。他に、ペアやグループが機能的に必要になる場合もある。たとえば、ペアやグループがペアやグループとして繰り返され、要素の個々の入れ子表の実質的な代理表現となる場合である。

値欄には要素の記入例や記入のレイアウト例を示した。いくつかの長大な値リストは付録に示した。システムの実装にあたっては適宜別の用語を使うことができる。

任意性欄には要素が必須であるか否かを示した。省略表示の意味は次のとおりである。

• R = 必須
• RA = あれば必須
• O = 任意

繰り返し欄は要素が1つだけなのか、繰り返しがあるのかについての情報を提供する。

注記/例欄は、要素に関してさらに詳細に説明するための場を提供したり、未解決な問題を取り上げる。

非常に長い要素リストを持つ多くの実体は、利便性と明瞭性のためグループに分割した。グループ化には機能的な意味はなく、システムの設計構造上は無視することができる。

電子情報資源という言葉は、簡潔にするために本文書では電子資源と略した。完全な要素名については付録Dのデータ辞書を参照のこと。