カレントアウェアネス
No.244 1999.12.20
CA1293
仮想OPAC vs.総合目録データベース
「総合目録データベース」とは，一般的に複数の図書館の所蔵データが単一のデータベースに収められているものを指す。しかし近年，複数館の目録データベースを横断検索し，利用者にとってはあたかも一つの総合目録データベースにアクセスしているかのように感じられる，いわば「仮想の総合目録（以下，ここでは仮想OPACと呼ぶ）」が現れた。
英国の大学図書館コンソーシアム（Consortium of University Research Libraries: CURL）の総合目録COPACでは，従来型の総合目録データベースと平行して，Z39.50情報検索規格を用いたOPAC横断検索サービスを提供している。これら2つの異なるサービスについて，ポイントごとにそれぞれの特徴を見ていこう。
データ 目録データは日々更新される。COPAC総合目録では，個々の参加館より送付された更新ファイルは，エラーチェックを経て1〜2週遅れで検索可能となる。典拠コントロールはされないが，標準フォーマットへの変換により，収録データの調和を図っている。一方の仮想OPACでは，リアルタイムに各図書館の最新の所蔵状況を検索できるという利点があるものの，データの統制や品質管理は存在しない。
収録された各図書館のデータは同定されないと利用者に混乱を招く。COPAC総合目録ではデータ投入時に複雑なマッチングを行っている（CA1248参照）が，この際のオフライン処理にかかる費用は決して少なくない。一方，仮想OPACでの同定処理は極めて難しい。検索結果集合が生成されて初めて同定処理が可能となる訳だが，例えばISBN等のコードを用いて検索レコード間の重複をチェックしようとすれば，マッチングに時間がかかる上に，コードの誤付与や未付与図書の存在などといった問題を解決する必要がある。
検索結果が得られれば，資料の入手のためには各種ローカルデータが必要となる。COPAC総合目録では所蔵情報や雑誌の所蔵巻号の情報は提供しているが，検索時点での貸出状況はわからない。このため，個々の図書館システムにリンクして，貸出状況等の情報を提供することが検討されている。一方，仮想OPACではローカルデータの表示は困難である。
仮想OPACでは，図書館ごとに所蔵データの変換プログラムを作成することにより，この問題に対処している。NISO（米国情報標準化機構：Z39）では，Z39.50の展開として，「貸出データ変換プロトコル」を目下議論中である。
検索 Z39.50を用いたデータベース検索では図書館システム間の一貫性の欠如が重大な影響を及ぼす。例えば「著者」を指定したとき，全ての図書館において個人著者と団体著者が同じフィールドで扱われているとは限らない。つまり，伝統的な総合目録で可能な，フィールドを指定した検索が難しいということだ。また，標準のインデックスがないために，タイトル検索の際に語と句のどちらを検索単位とするかがまちまちだったり，検索結果の適切さを示すランキングやソートも実現が困難であったりする。もともとZ39.50は発信元（クライアント）と受信側（サーバ）が検索に関するデータや命令をやり取りするための規格であり，複数データベース検索のために設計されたものではないため，これらの問題に関する直接のサポートは存在しない。
管理 検索対象の図書館数が多い場合，その内のたった1図書館のシステムダウンが仮想OPAC全体のレスポンスに響き，タイムアウトによる検索不能を引き起こす。このように，個々の参加図書館のネットワーク能力，システム性能は仮想OPACの性能全体に重大な影響を及ぼすのだが，各図書館においては直接の利用者へのサービスが第一であるため，仮想OPACのためにシステムやネットワークの性能を向上させることは難しい。
新しい技術と伝統的な手法 これまで見てきたように，現時点の仮想OPACの持つ問題の多くは，Z39.50の規格範囲外のことに関連している。
伝統的な総合目録データベースはそれ自体が物理的な塊として存在しているため，利用者による検索において一貫性を保ちやすい。しかし，どんな総合目録データベースにも容量に限界があるため，利用者の必要とする全ての情報へのアクセスに応えることは出来ない。ここに仮想OPACの存在意義がある。
新しい技術の導入時には，伝統的な手法を切り捨ててしまいがちだが，利用者へのより良いサービスのためにはそれぞれの利点を取り入れる方が建設的と言えるのではないだろうか。現段階においては，技術の発展が遂げられるまで，仮想OPACと伝統的な総合目録データベースを共存させることが最良であろう。
長嶺 悦子（ながみねえつこ）
COPAC
