研究会の趣旨と慶應大学の報告
[入江] 今日は雨の中みなさんお集まりいただいてありがとうございました。私今回の呼びかけをさせていただきました慶應大学メディアセンター本部の入江と申します。皆様のご協力というか、みなさまの強い反応がありまして、思った以上に多くの方々にお集まり頂いて、呼びかけ人として大変嬉しく思っております。
これから第一回の研究会の全体会を開催させていただきたいと思います。昨日からのNIMDA騒ぎでみなさん大変かと思うのですが、今日も何人かの方が対応のために来られなくなって、大変な時代だなぁと思っておりますが今回の開催につきまして、以前にお送りしましたメールにもありますように、早稲田の金子さんや、NIIの米沢さん、阿蘓品さんにご協力いただきまして今回の開催までこぎつけました。ここでみなさまにあらためて感謝したいと思います。
今回の開催のお知らせは、ほとんど一般的に送ったのではなくてみささまの個人的なところに送らせて頂きました。具体僕の出身がソフトハウスであったということもありまして図書館の方メーカーの方、ソフトハウスの方々と付き合いがあったということで具体的なターゲットをしぼって直接お願いさせていただきました。ご無礼を謝っておきたいと思います。今回の研究会の趣旨について説明したいと思います。始めに皆様のご紹介と現状の報告をいただきまして、休憩後石田さんの方から現在のZ39.50の方向性と課題についてお話いただいたあとに討論をし、その後で今後の方向性をつけていきたいと思います。趣意については皆様に送られているメールでもありますように、グローバル化と図書館自身の今までの運営を変えなければならないと次どうしていくのかと言う時代の中で図書館もメーカーもそんなに余力がある訳ではありませんし、体力もどんどん削られていっている中で具体的なメーカーも図書館も相互協力を前提にしたものをどうやって作っていくのかということを見いださなければならないと思っています。今回の目的としてはZ39.50の環境が変化してきていまして、NIIの方でもZ39.50のターゲットを開発しテスト環境でテストをしている最中です。今年度、複数のメーカーでZ39.50のターゲットを開発するという計画があります。ただそのZ39.50の開発をされるというメーカさんにもいろいろな壁がありますし、いろいろ決めなければならないこともある中で、個別で動いていくとロスも多いだろうということで、相互接続のための実装レベルを合わしていくということを具体的な目標にして研究会を上げたいと考えていました。それでそのための準備をするためにこの会議を開催させてもらっています。それを始めると色々な問題がでてくるのですが、具体的には実装レベルでどうしていくかである程度解決していきたいと思っていますのでその準備をしたいということです。基本的には今年度くらいからテストを始めて作られていくので、１年間くらいをめどにZ39.50の課題については論議をしていきたいと思っています。それで実装してしまえばある程度進むと思っていますし、そのための環境を準備したいと思っています。結論からいうと、今年１年間のアウトプットの目標としては各メーカーさんのZ39.50の実装レベルと具体的なテスト環境なり標準的な実装モデルを提供していきたいと思っていますのでご協力お願い致します。アウトプットとしてはそういうドキュメントを全部残していって実際的な環境を提供していきたいと思っています。今回の研究会の運営につきましてはメーリングリストとホームページでやろうと思っていますので具体的な論議についてはその中で進めていきたいと思っております。氏名所属メールアドレスを掲載しますのでご協力ください。本日の議事内容についてもホームページに掲載しておきます。メーリングリストできたメールについては全てメールログが掲載されますので、もし出したくないメールがあれば個別に送るか事務局に送ってください。ホームページについては私の説明資料にありますが、今作成中ですが、できましたらお知らせ致します。（http://libsys.lib.keio.ac.jp）
メーリングリストはが全体のメーリングリストです。事務局メーリングリストはlibsys_jim@mita.lib.keio.ac.jp事務局宛で慶應の沢田と片桐、私と運営委員に送られるメーリングリストです。
運営委員ですが早稲田の金子さん、丸善の佐藤さん、紀伊國屋の加茂さん、慶應の私で運営していきたいと考えております。この運営会議では具体的な企画やメーリングリストの討論の中身のホームページへのアップや定例会の開催の準備をしていきたいと思います。ということで今回の会の目的は具体的なZ39.50ターゲットができていますので日本で実装していくことと、それを業務レベルに実装して利用していくための環境をつくることだと思っていますのでご協力お願いいたします。
慶應の報告なんですが、資料がいっぱいあるので簡単にご説明します。私のレジメとその後ろに丸善さんのコンフィグレーションガイドがあります。これが慶應のZ39.50のターゲットの今のサービスのコンフィグレーションです。あと最後に簡単にタグ単位のサブフィールド単位のインデックスとBIB１のvalueの対応が書いてあります。これが合っているかどうかは問題がありますが現在の実装レベルです。Z39.50のアプリケーション概説書がありまして、これはコンパックさんが作ったものの抜粋です。慶應の今サービスしているZ39.50のGATEWAYの画面のサンプルです。これを標準にしてあげていくんですがMARC21対応とUTF対応を中心にしてやっていきたいと思ってます。次が以前に富士通さんに説明したときの資料とあとNIIさんのZ39.50のテストがあがったときに慶應のゲートウェイから接続したときの説明資料です。NIIさんのZ39.50がひけるようになってますので参考であげています。次がMARCフォーマットの関係でOCLCのCJKをつかったテストサンプルがありましてそれを載せています。最後に偶然ISIの方から資料が出されまして、最近のISIへのホールディングへのリンクというのがよくあるのですが、なかなかOPACでリンクできないとこがあるので各メーカーさんに資料を出しています。慶應の方はZを具体的なターゲットにして展開する準備をしていましてEACCなりUSMARCのハンドリングをしています。慶應の具体的な開発状況をご説明する資料を用意しました。これが慶應の状況でして、慶應ではUSMARCを標準にして展開してますし、RLINとOCLCのデータをルーチンに取り入れている状況です。あとについてはMARC21の対応とUCSの対応をしていく計画になっていますのでどうやってやっていくか皆さんと論議をしながらすすめていきたいと思っています。そういう意味で今回のアウトプットについては慶應のGATEWAYの中で接続できるような環境ができればいいかなと思っています。
ちょっとバラバラになって申し訳ありませんが慶應の報告と趣意を説明させていただきました。この後早稲田の金子さんの方からINNOPACをいれられた運用などについて説明を受けたいと思います。宜しくお願いします。
早稲田大学現状報告
[金子] 早稲田大学の金子でございます。よろしくお願い致します。研究会運営委員として私も参加させていただいておりますが、ここまでの準備は入江さんはじめ慶應の方々にやっていただきました。まず改めてお礼を申し上げます。早大の図書館システムWINEは、1998年の秋にシステムの更新を行って、米国INNOVATIVE社のINNOPACを使っております。この製品は在日カナダ大使館も使っているようですが、これは日本のユーザーというよりはカナダのユーザーと考えた方が妥当なので、普通に日本語を扱っているという意味では、私どもが日本で唯一の利用者ということになります。研究会のさしあたりのテーマはZ39.50ということですが、それ以前に米国の製品を使っている経緯とか現状を簡単にご報告させていただきます。 なお、INNOPACの導入の経緯につきましては、『1998年度早稲田大学図書館年報』に報告してあります。これはホームページにも載せ ています（http://www.wul.waseda.ac.jp/PUBS/nenpo/1998/windex.html)。
1986年に、早大は図書館システムとしてDOBIS/LIBISを導入しました。これはドイツ、ついでベルギーにおいて開発されたヨーロッパIBMの製品です。しかし、90年代に入りますと、WEBの対応など高機能なものが欲しいということもありまして、システムの変更の検討を始め、具体的にはワーキンググループなどをつくって検討をすすめておりました。一方で私どもはIBMさんと組んでハード面の構築をしたのですが、そのリースが切れる時期 が1998年で、ホストマシンからクライアントへというようなことも考慮して、システムの変更もそれにあわせることになりました。IBMさんからの提案や、他の業者さんの話なども聞いて、何にしようかということについては非常に苦慮いたしました。今となってはDOBIS/LIBISは古いシステムとなりましたが、その当時はそれなりに動いておりまして、レスポンスの早さとか、それまで実現していたことは新しいシステムでも対応できなければならない、またプラスαも欲しいということで、検討を重ねました。しかし、日本国内で我々の要求を満たしうる製品はないように思われました。外国のシステムをのぞいて、そこで実現していることを業者さんに指摘するなど、そういう意味ではプレッシャーをかけたりもしました。そのうちに、製品ではなく独自に開発をしたいという提案があったり、いろいろな経緯がありまして、INNOPACを使って動かすということがIBMさんの方から提案されたのを受けてこれを次期システムの基本として、作業を進めました。
いろいろな考慮点がありましたが一つ大きかったのは、完成した製品を利用するということでした。DOBISの時代には結構カスタマイズをやりま して個別の要望に応じた改良を積み重ねました。従って日本でDOBISユー ザーが20以上あったと思いますけれども、カスタマイズの結果、いわば「早大版」ができて便利に使えた反面、大きな変更を考える上では難しい点がありました。そこで私どもは、図書館システムについては完成された製品を使い、カスタマイズはせず、製品のバージョンアップによって機能が大きく変わるのを待つ、自分たちでは細かな改良はしないという方針を持ちました。INNOPACを使うという提案は、まさにそれに合致するものでした。ただし、INNOPACには日本ユーザーがなく、日本語にも対応していませんでした。その部分はINNOVATIVE社、早大、IBMの３者で協力して作りました。具体的には我々使っているのはシフトJISのコードなのに対し、INNOPACの内部コードはEACCであるためそれを変換する仕組みですとか、画面のメニューメッセージが英語しかなかったため日本語にするとか（総計で１万行分近くを訳したと思います）、その他さまざまな課題がありました。
日本語対応の部分は、製品を買ったとは言っても大きな変更ということになりまして、今ではINNOPACの日本語版としてINNOVATIVE社から提供されています。ZについてはINNOPACで提要されているものを用いて、OPACの「他図書館の検索」というメニューで提供しています。図書館の一覧には２０いくつかをあげています。候補が沢山あったなかである程度選びまして米国のほか、台湾、香港、オーストラリなどをリストアップしました。レファレンス部門の意見もきいてILL依頼の比較的多い図書館、試してみて応答がよかったところ、香港、台湾はINNOPACユーザーが多いこともあって選びました。検索をしてみます。(参考： http://wine.wul.waseda.ac.jp/search/、http://www.wul.waseda.ac.jp/opac/wine/z39m/（Z39.50））
外国のシステムということで見学の方からよくサポートのことを聞かれます。日常的なオペレーションとしてはソフトハウスの方にはいってもらってやってますがシステムそのものの問題はINNOVATIVE社のヘルプデスクにメールを投げます。日本語の扱いはINNOPACにとって新しい経験だったこともあり、日本語部分にバグが非常に多かったのですが、段々解消してきています。現在オープン中の問題はけっこうありますが、大きな問題はほとんどクリアされてきています。
このINNOPACをいれるにあたりまして、書誌レコードのフォーマットについても検討しました。DOBISの時代には標準的なMARCの形とは異なるものでした。INNOPACはUSMARC仕様ということで、私どもにとっても、OCLCを利用している洋書についてはもちろん親和性が高く、問題はありませんでした。そして日本語のデータにつきましても、USMARCフォーマットに準ずるという変更をその時点で行いました。OPACで日本語の図書を検索していただいて「MARC表示」のボタンをおしていただくと、MARCフォーマットでのデータが見られます。日本語に該当する部分たとえば２４５のタイトルの部分に漢字を含んだ表示の形とカナの形と、アルファベットヘボン式でローマナイズされた形というこの３つの形を245の811、812、813というサブフィールドに新設いたしました。これは標準のではありませんがINNOVATIVE社の方と日本語をどうもつかという打ち合わせをしたときに、USMARCでは880のvernacularでもつのが通例でしょうが、やはり本国のMARCとして本国のデータをもつときには、880ではなく本来のタグでもつべきではないかという指摘がありまして、そのように決定しました。
基本的な考え方は、標準的なフォーマットに従うということで、日本語についても同じ方針を持ちました。そのことにより、データの交換・相互利用が可能となりますし、外国とのやりとりも容易になります。紀伊國屋さんの御尽力もありまして、早大で作ったデータをOCLCに提供し、50万件以上を出しております。それからユニコード対応ということで言いますと、ユニコード版というのがINNOPACにありまして、それも私どもでは持っておりますが、処理すべきデータについてはこれから蓄積していこうと思っています。
繰り返しですが、システムそのものについても、また蓄えるデータの持ち方についても、標準的なものを利用し、カスタマイズは行わないというのが基本的な考えであるといえます。簡単ですが以上で終わりたいと思います。
国立情報学研究所の報告
[阿蘓品] ただいまご紹介に預かりました文字情報係というとこにおります阿蘓品といいます。どうぞよろしくお願い致します。
[米沢] ということで二人になってしまったのですが、そもそもNIIの目録所在情報サービスの方でZ39.50をし始めた経緯を簡単に説明したいと思います。
そもそも我々の目録というのはZ39.50にしろUSMARC形式にしろ一線画したというか独自の世界で築きあげてきたところがあります。Z39.50対応についても情報検索系というかNACSIS-IRの方に任せてきてあまり力をいれてきませんでした。その一方で新CATとか新ILLの目録専用のプロトコルの開発とか普及とかについては図書館システム開発の方々には随分御盡力いただいて、ようやくここにいたって大多数の図書館が新システムの方に移行してくれたという状況になっています。
ところが一方で、何でこうなったかよくわからないのですがCULCONという日米の大きな会議がありまして日米の情報交換をもっと活発にという大きな動きの要請のもとに日米のILLドキュメントデリバリーを改善していこうということでシステム的な対応をNIIがするということになりました。具体的には、そういった国際的な要請でISOプロトコルに対応しなければいけない、検索の仕掛けとしてはZ39.50ということで対応していこうという急展開がありまして昨年度システム開発をしようと私と二人でバタバタと先行の開発メーカーさんの状況をききながら着手したというのが経緯です。昨年から開発を始めまして、今日もいらしているリコーの宮本さんのところに仕事はやっていただいているのですが、今日お配りしていますがZ39.50のGATEWAYサーバーの開発をし始めたというのが実状であります。
このGATEWAYについては今年の6月プロトタイプで公開しております。これはこういった場も活用してBIB1やUSMARCについても標準的なものに仕上げていきたいと考えております。この会の我々にとっての目的はそれが一番大きいのではないかと思っています。サーバーはリコーさんと開発をしてますが詳細については皆さん我々のホームページ等ご覧になっていると思いますので、特にここでは紹介しません。もう一方目録システムからILLシステムからZ39.50で他のサービスを見に行くというのも開発をすすめております。これはCATPサーバー側の機能ですが今日はいらしてないHITACHIさんの方で改造を行っております。それが実現できますと目録システムILLシステムでみなさまの開発したクライアントでもってCATPサーバーにアクセスして、具体的にはOCLC、RLGを想定していますけれどもその双方の書誌ユーティリティーのZ39.50のターゲットにアクセスしてILLのための検索をするあるいは目録のための書誌データダウンロードするための検索を行うというようなことを考えています。目録システムの場合は参照ファイルとして外部Z39.50サーバーを利用するとOCLCの書誌を参照ファイル的に利用するということを考えています。現在はシステムづくりというか、システム的な実現をかんがえていまして、それとは別途紀伊國屋さんを通じてOCLCの利用についての交渉をこれからすすめるといった状況になっています。RLGについては丸善さんと契約的な話しをすすめて各図書館で利用できると言う形にしていきたいと思っております。
我々としてはMARCの標準化とかZ39.50のアトリビュートセットの標準化に大変関心がありまして同行をみて開発を進めていきたいと考えております。以上で報告に変えさせて頂きます
[入江] ありがとうございました。Z39.50についての論議が高まってきているのはNIIさんの開発が始まっているからだと思っていますので今後もご協力をお願いします。続きまして国立国会図書館の原井さんの方から資料でいただいてますUNIMARCの資料は配ってよいかわからなかったので配布してないのですがJPMARCのUNIMARC化ということについてその背景などをお話をいただければと思います。よろしくお願い致します。
国立国会図書館の報告
UNIMARCフォーマット提供の進行状況としましては、JAPAN/MARCのUNIMARCフォーマット版を一応定義はできまして、今月の末か10月初めにずれこむかもしれませんが、当館でいつも出している『全国書誌通信』で公開します。これはJAPAN/MARCを実際買って頂いているユーザにはすでに通知してある内容です。また、サンプルデータもUNIMARCフォーマット版とJAPAN/MARCフォーマット版の両方とも提供しています。今のところユーザーのうちの希望者にのみ提供しています。JAPAN/MARCフォーマットの方も来年４月よりフォーマットを改訂しますので。予定ではUNIMARCフォーマット版の方の提供を開始するのは15年の1月、もしかしたらもう２，３ヶ月遅れるかもしれませんが、遅くとも15年度には可能と考えています。今のところ定義ができてサンプルも作ったのですが最終的なマッピングがこれからで、まだ時間がもう少しかかる予定でいます。UNIMARCフォーマットからUSMARCフォーマットへの変換の仕組みについては今のところ何も考えていません。その余裕がないのです。将来的には考えなくてはいけないのかなとは思っていますが。フォーマットに関してはこういったところが現状です。
フォーマット自体の話ではないのですが、当館の場合マスターデータというのはMARCフォーマットではなく独自の形です。JAPAN/MARCフォーマットも、UNIMARCフォーマットもそのマスターから別々に編集します。編集が２系列になるわけで、JAPAN/MARCフォーマットからUNIMARCフォーマットへ編集している訳ではありません。それは、かなり困難かと思います。やってやれないわけではないでしょうが、かなりデータが欠けるところが出てくるはずです。
しかもマスターデータは、基本的には読みはカナしか持っていませんのでアルファベット系の読みについては、すべて機械的に変換します。どういう変換かというと簡単にいえば一字一字カナを規則に則って変換するという形です。過去に提供してきたデータには母音に山傘がついたものを長音としていましたが、そういった外字をできるだけ使いたくないということで長音はカットすることにしました。長音記号の長音はカットしまして「オウ」のようなものは「ou」になるという非常に原始的で、機械的な変換を行います。このローマ字変換規則の内容については、いずれは公開するつもりでおりますが、まだルール自体内部的な形式なものしかありませんので公表はもう少し先になるかと思います。
とりあえず今は当館内部で多様な形式のデータを一つのフォーマットに統一するということに全力をそそいでおりまして、それ以外のことに手がまわらないというのが残念なことに実状です。本日は、国会図書館で提供する予定のMARCフォーマットについてを中心に、少しローマ字変換についても話させていただきました。
[入江]フォーマットの話がでたので慶應のサンプル（参照：http://decsv001.lib.mita.keio.ac.jp/cgi-bin/kmc/cal950.cgi)です。慶應のフォーマットはタグを4バイトにしてカナ形分かち形ローマ字形という形を２４５に入れたかったということもありまして拡張しました。よかったかどうかはわかりませんが後でコンバートできるだろうと思いまして考え方としては早稲田のWINEによく似ています。つづきまして尾城さんの方からお願いしたいと思います。尾城さんは今は国会図書館にいらっしゃいますが2年前まで東工大でZ39.50のことなどされていた方なので、もしその話がきければと思います。よろしくお願い致します。
今日は私米沢コンテンツ形成管理課といって図書の目録をやっているのですが一緒にきた阿蘓品と申しましてZ39.50の開発を二人で作業を行いました。では一言自己紹介を。