研究会報告


| 1 | 2 | 3 | TOP |

開会・挨拶

[入江]第4回のライブラリーシステム研究会を始めさせていただきたいと思います。第4回とするかは随分悩みました。関西でやらせていただくので、東京から行く人はいないだろうと思っていたのですが、随分、沢山の方にいらしていただいてありがとうございます。いつも関西の方に東京での研究会にいらしていただいていたので、一度関西でやろうと考えていたのですが、同志社さんに場所をお借りして開催できることになりました。ありがとうございます。まず初めに同志社大学の田中課長の方からご挨拶いただきたいと思います。よろしくお願いいたします。

[田中]同志社大学の田中です。よろしくお願いいたします。本来でしたら所長がご挨拶ということですけど代わりまして、会場校ということでご挨拶させていただきます。どうも遠い所から本当に逆に東京から沢山こられて、しかもお暑い中といいいますか、昨日慶應の入江さんは「今日の京都は暑いのですか」と言われたのですが、私なんかはだいぶん涼しくなったなぁと思っていて、どうも東の方はだいぶん涼しさが違うようです。
この第4回ということで沢山の方がお集まりいただいてます。お歓び申し上げたいと思います。同志社大学の場合、総合情報センターという名前ですけれども、図書館、計算機部門、それから視聴覚部門が統合された形で12年目を迎えています。やっぱり図書館の方、私も図書館が長いのですけれども段々人が少なくなっていってる、アウトソーシングがすすんでいるということになりますけれでも、いろんな図書館の会合に出まして、いつも話を聞くのは今後の図書館員のあり方というか、そういったところに話が行っています。私は今後テクニカル部門、確かに目録とか収集とかも大事ですけれども、情報サービスの方にやはり重点ウェイトを置くべきだと思っています。本を集めて管理して貸し出す、図書館の待ちの姿勢、入館者を待つという形ではなく図書館外に出て、図書館外からの利用というのも可能になってますので、ますます情報サービスの中枢にするべき時がきているかと思います。同志社大学はまだ大型計算機を使ってます。汎用機を使って図書館システムを運営しています。内部で開発しましたので、その点いろいろ小回りはきくのですが、このインターネットの時代にそろそろ見直しの時期がきてるかと思います。この研究会などを通じていろいろ勉強をさせていただきたいと思います。いろいろ不行届きがあるかと思いますけれども充実した研究会になることをお祈りしています。お手元の袋の中に同志社大学の文化財案内が入ってますので、もしお時間ありましたら国の重要文化財の建物が5つほどありますのでぜひご覧になっていただければと思います。ありがとうございます。よろしくお願いいたします。

[入江]ありがとうございました。それでは関西でやるということで初めての方もいらっしゃいますので、これまでの流れを整理してご説明したいと思っていまして、早稲田大学の金子さんの方に説明をお願いしています。発表お願いいたします。

第1部 これまでの経過と提案

[金子]早稲田大学の金子でございます。本日はお忙しいところお集まりいただきましてありがとうございます。私は昨日京都に参りまして、同志社さん、立命館さん、先ほどは京大さんの図書館を見学させていただきました。関西の方での動きは急だなという実感をもちました。個人的なことなんですけれども、明日の午後、慶應大学でで三田図書館・情報学会の月例会というのがございまして、そこで「大学図書館における研究開発」というテーマで報告するようにと言われておりまして、実はこの研究会について話すことになっております。今晩東京に帰りまして、本日の研究会の結果も含めて報告したいと思っております。よろしくお願いいたします。今、紹介にありましたように、今回初めて関西で行うということでこれまでの経過について、また具体的に提案している事項がございますのでそれについても簡単にご報告したいと思います。

まず発足の趣旨ですが、背景といたしまして、情報環境の著しい変化、コンピュータ、ネットワークを始めとする大きな変化ということがあります。とりわけ90年代以降、インターネットを通じたグローバル化の進展が図書館の現場、あるいはそこでのサービスに大きな影響を与えてきていることは皆さんもお感じのところであろうと思います。そうした流れの中で、たとえばいわゆるオープンリソースという動き、e-journalとOPACといった異なる情報源どうしの連携への対応なども非常に重要になって来ておりますが、そうした展開がどうしても欧米、とりわけ北米から出てまいりまして、残念ながら日本の状況はやはり遅れがちになっています。

一方で経済状況、社会状況を考えすと、会社の経営環境も厳しくなっているでしょうし、大学図書館でも人員が減らされるとか、アウトソーシングをしていかなくちゃいけないとかいう大きな流れの中で、企業も図書館も余力を持てない状況になっているかと思います。企業にせよ大学にせよ、たしかに競争にさらされてはいるのですが、お互いの適正な協力によって打開できることも少なからずあるのではないかと思います。図書館の運用あるいはそのシステムの整備ということも、グローバル化の中で、国内はもちろん海外ともさまざまに協力することによって切り開いていくべき課題があるのではないか。そのために、まずは国内で、関係する機関、図書館ももちろんですし、システムのベンダーさんその他の関係する機関で進めていくことが重要であろうという認識が、まず大きな背景としてあったと思います。

そういう問題意識で研究会を起ち上げたのが昨年の9月です。慶應の入江さんのイニシアチブがございまして、紀伊國屋さん丸善さんとも話し合う中で研究会を起ち上げようということになりました。Z39.50の日本での環境が変化してまいりまして、NIIさんがZ39.50のターゲットを開発していて、それに対応して複数のメーカがシステム構築に乗り出すというような時期でした。そこで、まずはZ39.50による相互接続のために、実装のレベルを合わせるための標準的なモデルが必要である。それをまず具体的な第一の目的として研究会をやろうじゃないかという呼びかけが入江さんからあったわけです。しかしそれは、当面の一つの事例でありまして、関連する話題として、例えば書誌レコードやMARCフォーマットの持ち方、文字コードをどうするかということ、日本語をローマ字に変える際に表記法をどうするかなど、いろいろな課題があります。また、さっき申し上げましたようなオープンリソースの動きもあり、それらについての考え方を整理して実装レベルでの調整を図っていきたいということもあります。そして根本的には、遅れがちな状況を打開するために、図書館どうし、あるいはメーカーさん含めての協力体制によって日本でも標準的なもの、グローバル化に対応するものを作っていきたい、そのための情報発信をしていきたい、ということではないかと思います。この研究会は個人をベースとした緩い集まりに過ぎないのですが、大学だけでなく、企業の主要なところにもお集まりいただいてますので、そうした中でのやりとりを通じまして有効な提案をまとめ、それを発信していきたいということがあります。さらに、研究会の中でも話題になっているのですが、日本における問題状況をふまえて、必要な事柄については海外にも発信していきたいと、例えばLCに対してとか、国際的な取り組みの中にも反映していけないだろうか、あるいはそうすべきであるというご意見もありました。そのことも意識しながら、ここではその下地を作っていければということも考えております。

扱う課題は幅広くまた深いわけですが、簡単に申しますと、図書館はいろんなことをやっている。その中でこの研究会は、名前のとおり「ライブラリシステム」を扱う。括弧つきの「システム」を通じて国内的国際的な図書館サービスの向上をめざすということではないかと思います。ここで「システム」というときには1個のパッケージとは限らず、書誌ユーティリティーもあり、規格や標準的なガイドラインのようなもの、その他いろんな要素がありますけれども、そういったものをまとめて関連づけながら、サービスの向上をめざしていく。もちろん個別の図書館のサービスの向上もありますし、国内協力もありますし、外国との関係、そうしたこと全体でサービスを高めていきたい。それぞれの図書館・企業はなかなか苦しいわけですけれども、集まって知恵を出し合い協力しあって進めていけないか、ということが大きな目的なのではないかと思います。

さて次に具体的な活動のご説明です。こちらにURLを示してありますがホームページを上げておりまして、ご覧になった方も多いと思います。こう言うのも何ですが、かなり充実しておりまして、主に入江さんのご尽力で慶應の皆さんに作っていただいています。まだの方は是非ご覧いただきたいのですが、ホームページによる情報発信をしております。そして会議を開催しています。本日は4回目になりますが、その議事内容、あるいはそこに提出された資料も全てページに掲載しておりまして、結構なボリュームになっています。またメールマガジンを月刊で発行しています。メーリングリストもありまして自由投稿を受け付けているのですが、そのログもページにあります。研究会のメーリングリストはlibsys_mlになります。ほかに事務局のメーリングリストlibsys_jimがありまして、ログ掲載を希望されない連絡事項はこちらで受け付けています。研究会を運営する体制ですが、運営委員会と事務局を設けております。運営委員としては慶應の入江さん、紀伊國屋の加茂さん、丸善の佐藤さん、そして早稲田の私ということになっております。事務局は慶應のスタッフの方々です。

会議のこれまでの開催実績ですが、第1回をちょうど1年前、昨年9月に慶應義塾で、第2回を今年の1月に早稲田、そして第3回を6月に上智さんで行いました。その都度豊富な中身だったのですが、簡単にご説明します。詳しくは研究会ページで記録をご参照いただけます。いろいろな動きがある、それぞれの事例を図書館や企業の方から報告いただいています。第1回目では、そういったいくつかの事例に加えまして、当面の課題でありましたZ39.50についてインテックウェブアンドゲノムインフォマティックの石田さんから非常に詳細な報告をいただきました。資料がページに載っておりますけれども、今後も参考にできる詳しい資料かと思います。それから第2回には東京外国語大学の芝野先生から文字コードをめぐる状況について、これも非常に詳しいご報告をいただきました。石田さんのZ39.50と合わせまして、文字コードの芝野先生のご報告も重要な資料になると思います。第3回では具体的な提案といたしまして、日本におけるZ39.50のガイドラインを提案させていただきました。また、NIIさんの方からも適宜Z39.50やメタデータの取り組みなど、その都度の話題をご報告いただいています。以上のように、さまざまな事例の報告やそれをめぐっての議論ということで進めてまいりました。

次に具体的な提案でございますけれども、Z39.50のガイドライン案を第3回の研究会で提示いたしましたが、今回もそれを資料に加えてありますのでご覧ください(資料)。この提案は、運営委員の中でとりわけ入江さんと佐藤さんにご尽力いただいてまとめたものです。基本的な考え方としては、3つのポイントがあるように思います。第一に国際的な情報交換をするための標準的な仕様とすること。次に出てきますが文字コード、あるいは書誌レコードのフォーマットなどを、いま世界で主流となっている仕様に合わせようということです。二番目には、大枠での統一を優先しまして最低限の項目を規定しているということです。Z39.50の仕様というのは大変細かいものでございまして、実は私自身もあまり把握していないのですが、共通して使えるような大枠についての統一を図るために、まず基本的なことについて規定しています。そして三番目に、いわゆる単語わかちがないといった日本語の特性を考慮しての提案になっています。

具体的には文字コードはユニコードUTF8、レコードフォーマットにつきましては日本の特殊な事情がありますけれども、その辺は酒井さんの方からあとでご報告がありますが、我々としてはデファクトな標準となっているMARC21を採用したいと思っています。標準的なMARC21としては880のところにvernacularな文字を入れ、本来のフィールド、タイトル245などにはローマナイズした形を入れるというのが北米などでとられている形ですが、それをどうするかについては、さらに検討が必要だろうと考えています。たとえば早稲田の場合ですと98年にINNOPACというシステムを入れまして、その際に日本語のMARCフォーマットを疑似USMARCというかMARC21にしまして、その時に880は使わずにタイトルなら245の所に並列して漢字まじりの表示系とカナとローマ字と3つ持たせるという形にしました。慶應さんも類似のやり方かと思います。今後それをどうするかについては考える必要があると思うのですが、いずれにせよMARC21を使うという提案です。具体的なアトリビュート等については資料をご覧いただければと思います。これを第3回の研究会で提案して、資料をページにもあげてご意見等を伺ってきております。以上、簡単ですが報告を終わりたいと思います。

第2部 事例報告

1. iLiswave (富士通)

[松永]富士通の松永と申します。いつも大変お世話になっております。 本日、私が用意した資料は2つです。
「富士通iLiswaveの標準化の状況」
「iLiswave Z39.50ターゲットBib-1アトリビュートセットのサポート詳細」
今回はZ39.50だけではなく、ISO ILLプロトコル対応についてもご報告させていただきます。

まず、Z39.50開発状況についてです。

1.Z39.50ターゲット

iLiswaveでは目録フォーマットとしてNACSISフォーマットを採用しております。Z39.50ターゲットでは、NII様と同様にNACSISフォーマットからMARC21フォーマットに変換して検索結果を返戻をしております。変換仕様はNII様の変換表をベースに開発しました。880タグに表記形、245タグにローマ字ヨミを設定しています。ローマ字ヨミはカタカナヨミから変換して表示しています。Database nameはILIS。Portは標準は210。これはパラメータにて変更可能です。Character SetはEUCとUTF8。Record SyntaxはMARC21とSUTRS。ServiceはInit、Search、Present。 アトリビュートの方ですが、NII様のZ39.50ターゲットとの比較で記載しております。Structure(Type-4)でphrase(1)とword(2)のいずれかを指定可能です。Truncation(Type-5)で前方一致(1)と完全一致(100)のいずれかを指定可能です。例えば、検索キーで'WORLD CUP'と指定した場合です。phraseで前方一致が指定されると'WORLD CUP'からはじまるものを検索します。phraseで完全一致が指定されると'WORLD CUP'というタイトルそのもの(いわゆるフルタイトルキー)を検索します。wordで前方一致が指定されると'WORLD'という語を含み、かつ'CUP'からはじまる語を含むものを検索します。この仕様は今ひとつだと思っています。wordで完全一致が指定されると'WORLD'という語を含み、かつ'CUP'という語を含むものを検索します。

図書所蔵の編集規則は、NII様の編集規則を参考にしています。852の$aに所蔵館と所蔵部署。$bに所蔵館の中の配置場所。$iに巻冊次、請求記号、登録番号。NACSIS-CATと同様にiLiswaveはで巻冊次を所蔵データ側に持っているためこのような仕様となります。雑誌所蔵の編集規則も、NII様の編集規則を参考にしています。資料を参照ください。

2.HTTP-Z39.50ゲートウェイ

クライアント側のシステムとなりますが、第2回の報告からステータスが変わっていません。統合情報検索環境というシステムの中でZ39.50の横断検索機能を提供しています。Z39.50のターゲット以外に通常のwwwOPACを組み合わせて横断検索することが可能です。(wwwOPACの組み合わせはカスタマイズ)

3.NACSIS-CATにおけるRLG参照ファイル

NACSIS-CATからRLGのZ39.50ターゲットに対して検索を行うゲートウェイ機能がNII様より提供されています。(2002/7/1〜) iLiswaveでは即時対応の上、レベルアップとして2002/7から提供しています。書誌検索画面のFILE検索キーフィールドでコード参照するとRLGBKS〜RLGといったデータベースが追加されています。その内、RLGは全データベースを横断検索する仮想データベースとなっています。画面例は、総合目録を検索してヒットしなかったので、RLGを自動検索した例です。

CHINA-MARC・ドイツMARCなどの追加と異なり、レベルアップにおいて困難な点があったので事例としてご紹介します。RLGレコードは固有の書誌レコードIDを持ちません。iLiswaveは書誌詳細表示をカード形式で複数レコード表示・切り替えることができます。書誌レコードIDをキーとしてキャッシュを行い、再表示する際に利用していました。RLGレコードの時は(固有の書誌レコードIDを持たないので)必ずもう一度サーバにアクセスして、表示形を取得する必要がありました。

現状、問題点が一つあります。CATPサーバの制限事項としてNIIのホームページでも通知されています。EXC文字を含む書誌データの場合、CATPサーバからの返戻データが文字化けします。CATPのメーリングリストでご質問したところ、2002年度中に対応予定といった回答をいただいています。

4.ISO-ILLプロトコルの開発状況

第2回の報告時はCATPサーバ側テスト環境がありませんでした。以降、テスト環境を整備いただき、テストを完了しています。レベルアップとして2002/10提供予定です。

実際の変更内容について説明いたします。

参加組織メンテナンスの画面例です。参加組織情報にWebCAT表示用のレンディングポリシーが追加されています。また、OCLCID、OCLCPWDにOCLCのID・パスワードを記入します。OCLCへの複写依頼の画面例です。コメントフィールドにISOプロトコル用のコメント(例えば最大の費用は何ドルまで)を入力するため、よく使うコメントは予め登録しておき、コード参照から選択できるようにしているのが工夫している点です。またメイン画面にISOSTAT・ISOGIDといったISOプロトコル用のフィールドが追加されています。iLiswaveの固有事情となりますが、宛名・担当については国内向け記述と海外向け記述と入力フィールドを2つ持つことにしました。OCLCに依頼する際には英語により異なるフォーマットで記述する必要があります。相手館に応じて各記述の入力フィールドを使用するように変更しました。

OCLCからの複写受付の画面例です。NII様にISO ILLプロトコル対応のテスト利用申請を行うと専用のIDを借用できます。専用のIDで複写依頼を行うと、5分後に受付を行うための別ILLレコードがバッチ処理で自動的に作成されます。自分が依頼したレコードを受付処理してテストすることができます。USドルといった通貨単位をCCODEで指定することが可能です。また、金額フィールドは整数以外に小数点以下2桁の入力が可能となっています。複写依頼と同様にInquireとPardon用のコメントも追加しています。

5.課題

Z39.50ターゲットについては、現在245タグの直後に880タグを設定しています。これで本当にいいのかということですが、先ほどリコーの宮本さんからNII様のZ39.50ターゲットでは245タグの直後とするか、TAG順にまとめるかということをパラメータで選択できるということを伺いました。NII様の方でもその可能性を考えているのだと思いました。

所蔵情報については、メーリングリストでも話題にのぼっていましたが、資料状態等、レファレンスに必要な情報のマッピングについて標準的に決定する必要があると思います。

HTTP-Z39.50ゲートウェイについては、複写依頼などのデリバリー機能に結びつけるという点ですが、第2回からの継続的な課題です。

ISO ILLプロトコルについては、NACSIS-ILL以外の部分です。実際に業務をスムーズに行うためには、受付作業用帳票やローカルシステム側でのOCLCとの統計帳票といったものを用意する必要があります。そういった部分も含めしっかりテストする必要があります。

以上で私からの報告を終わります。

| 1 | 2 | 3 | TOP |