研究会報告


| 1 | 2 | 3 | TOP |

開会・挨拶

[入江]第3回目の研究会を始めさせていただきたいと思います。

お忙しい中皆さんお集まりいただきまして、ありがとうございました。みなさんのおかげで研究会も第3回目を迎えることができ、上智大学の場所をお借りして、やらせていただくことになりました。この準備で上智大学のみなさんには、随分ご協力いただいて、どうもありがとうございます。また、これから懇親会もありまして、上智大学のみなさんにはご迷惑をおかけしますが、よろしくお願いいたします。

第3回ということで、1回目の時はどうなるかと思っていたのですがNIIのZ39.50 Targetの立ち上げもありまして、なんとなく、ある程度の合意がとれている状態にはなってきているのですが、前回その合意についてのお話がありまして、今日はそのご提案を中心に、おこなっていきたいと思います。それと標準化という問題と、業務への適用ということをこれからやらなければならないのですが、業務への適用という問題をめぐって研究会の報告をお願いしています。ユサコさん、リコーさん、丸善さん、それから慶應の木下の方で、それに伴う報告をさせていただくことになっています。それからNIIの方からメタデータに関するご報告をしていただくことになっていますので、よろしくお願いいたします。では議事にうつっていきたいと思います。本日会場をお借りして、随分ご協力いただいてます上智大学の事務部長岡本様からご挨拶いただきたいと思います。よろしくお願いいたします。

[岡本]事務部長の岡本です、よろしくお願いいたします。本日は関西からも3名みえてますし、遠いところ、ようこそお出でいただきました。心より歓迎いたします。この中央図書館研究総合棟ですが、1984年の開設でちょうど18年くらい経つかと思います。開設当時は東洋一と言われておりました。私は学生寮におったのですが、できた当時は東洋一、で半年経ったら東洋一じゃなくなっちゃったと、一年後には日本一じゃなくなったと話を聞いておりまして、18年経った今、トップ30にこの上智大学の図書館があるかのどうか不安なのでございます。

そういうことを含めまして、もう一つ、本学の図書館の事務部にとって特別な意味ある日なんです。と言うのは、昨年度からこの新しい図書館、いわば電子図書館化、情報化に対した図書館の組織の見直し改善等を検討してまして、ちょうど今日をもちまして現在ある3課、学術情報課、情報サービス課、資料サービス課の1つをつぶして、統合廃合を行いまして、7月1日から学術情報課、情報サービス課の2課体制で進めていくと位置づけております。従いまして、今日このライブラリーシステム研究会をやっていただく意味というのは、私自身、勇気を持つ一つのきっかけになっております。と言いますのもインターネットでこの研究会の紹介文を見たところ、国内最強の図書館システム研究会であると、なおかつメーカーさんが参加した中での21世紀の図書館システムの模索を検討するという紹介文でありまして、つまり私たちが7月1日から動く方向としては、このメディア化の推進、Z39.50・メタデータの導入・検討、情報発信の推進という大きな方向を打ち出した形での事務組織という風に位置づけております。この研究会の今後の研究成果を期待しております。多いに注目しつつご活躍いただきたいと思います。簡単ではありますが、挨拶にかえさえていただきます。本日はどうぞよろしくお願いいたします。

[入江]どうもありがとうございました。今日は国内最強とホームページに書いてくださった黒澤さんもいらしていただいてますので、ちょっとみんな運営委員は恥ずかしかったんですが。今日は、今の岡本事務部長のお話にあったように、これはメーカーさんも同じレベルで話をしようということで、第1回はメーカーと図書館側と大学とわかれて座っていただいてしまったのですが、2回目から参加者の皆さんのあいうえお順でお座りいただいてます。みんな平等で話をしようよという前提で、この会を運営させていただいています。また参加者ですが個人参加をベースとしながら、各組織1名という訳のわからないことになっているのですが、あまり沢山で論議をしてもまとまらないということもありまして、できるだけ絞ったメンバーで論議を進めていきたいと思っております。参加者の方で代表される方だけ前に座っていただいて、他の方は後ろに座っていただくということになっていますので、ご了承ください。今日は、慶應の方から事務長の天野が来ていまして、実は慶應の方で学事振興資金がとれまして、コーヒー代くらいは出せるようにやっとなれまして、これまで運営にみなさんの参加費や懇親会費をいろいろ工面していたのですが、ちょっとくらい出せるようになったので、ご挨拶を兼ねまして、慶應の天野より一言お願いいたします。

[天野]ご紹介いただきました慶應大学の天野と申します。よろしくお願いいたします。知った顔はあまりいないのですが、私、実はもともと図書館畑の人間でして、この4年半ばかり、どういう訳だか国際センターの方の仕事をしろということで外国人の留学生とか研究者を扱うような仕事をしていました。その国際センターの仕事というのも、なかなか大変でしてなかなか素人の気分が抜けなかったのですが、どうやら4年半経って国際交流の仕事にも慣れてきてレイマンとは言えなくなったなという風に思っていたところで、また、この古巣のメディアセンターに戻ることになりました。ところがこの4年半というのは、この分野、足が早いと言いますか、技術の進歩が早い領域であると思います。4年半の間に、またこの分野でのレイマンになってしまったなぁという風に感じておりまして、ちょうどこの6月末で着任して一ヶ月になるんですけれども、連日、この新しい技術、新しい知識に追いかけ回されているような状況になっております。この研究会、日本一の研究会だそうでありますけれども、3回目というのは、多分この辺で、これからほんとに長続きするかの分かれ目になるのではないかと思います。情報の分野での標準化というのは、昔からついていってまわる問題ですので、ぜひ長く続けて成果のあるものにしていっていただきたいと思っています。私も、この研究会にずっと参加させていただいて勉強するつもりでおりますので、どうぞよろしくお願いいたします。

[入江]どうもありがとうございました。それでは報告の方に入っていきたいと思います。

1. Z39.50 ポリシーについての説明

[入江]まず私の方が発表することになります。前回酒井さんの方から方向が出てきたと言いながら何も出ていないじゃないかと言われましたので、ちょっとその辺の流れを整理していきたいと思います。丸善の佐藤さんには随分ご迷惑をおかけして、一緒に調べていただきました。報告に入ります。資料は4種類です。まず最初にマンガがありまして、その次がマンガの説明の文章です。これは何かと言いますとZ39.50の基本的な動きなり、問題点につきまして、ちょっと整理しようと、知識もばらばらなので図書館サイドで最低必要な知識レベルをまとめました。その後のものが、これまでの研究会論議の流れの中で最終的な提案の方向の結論です。これを、これから案として出させて頂いて、揉んでいくためのベースの資料だと思ってください。最後にあるのがコンフィグレーションガイドです。これが基本的なZの方向性を決めていきたいと思いまして、ポリシーとしての提案です。問題点もいくつかありますので論議をしていきたいと思います。この流れを理解していただくためにご提案したいと思います。30分で短いのでちょっと早くなるかと思いますが説明していきたいと思います。

[入江]Z39.50と言っているプロトコルは極めて多様な概念なので、ネットワークまでからめると面倒くさいので、データベースの検索という部分をメインとした部分を中心に知識を共有しよう思って資料を作りました。間違っている部分があれば教えて下さい。僕もまだ自信のないところがありますので。事前にリコーの宮本さんとかにみていただいたらよかったのですが、その時間がありませんでした。

Z39.50のデータベースモデルとは抽象データベースなので、抽象データベースモデルのサーバとクライアントがあります。そこから通常はローカルデータベースの実装モデルにはいっていく訳です。英語文化の検索モデルが基本となっていますので、サーバクライアント部分がダイアログだとすると、ローカルデータベースが日本語のデータベースモデルと言うことです。これまでは、日本語透過の問題がありましたので、サーバからクライアントへの日本語透過やクライアントからローカルデータベースへの日本語透過の問題があったのですが、それも通るようになりました。サーバが持っているデータベースの抽象モデルと、ローカルデータベースが持っているデータベースモデルが違うという問題がありまして、それをどうしたらいいかが分からないところがあるのです。英語文化が作ったMARCベースのデータベースモデルと、日本で作られたデータベースモデルが異なるということにより検索結果が異なることがあります。するとデータベースとしては使い物にならないものになってしまいますので、そこを合わせたいというのが今回のプロファイルを作るための前提事項です。Z39.50の入門書を読んでもBib-1の定義の説明があまりないので、Bib-1の定義を簡単に解説します。

Attribute setの説明を少しします。1番というのはUseというAttributeでどういう検索をするかということです。タイトルとか著者とかの検索項目です。Relationは検索の演算子なのでイコールとか大なり小なりという演算子を指定します。Positionは日本語の場合はどこでもいいと思うのですが、データの最初から検索しますか、どこでもいいですかということを決めます。StructureというのがWordかPhraseかということを指定します。Truncationは語尾変化等に対応するかどうかのオプションです。Completenessは完全一致を検索するための識別子です。

まずwebでもあるのですが、タイトルの検索でinformationと入れた時には対応するbib-1の検索式が作られます。Bib-1 Attribute setではAttributeの1番にUseという何を検索するかを設定する項目がありまして、そこでタイトルは4と決められていますので1には4を入れます。演算子が"="ということを示すにはAttribute setの2番のRelationで3を設定します。StructureというAttributeがあって、Wordで検索しますという設定をします。検索する単語はinformationと指定します。これが検索式として投げられます。このAttribute setと言われているものが、なかなか日本語にはマッチしないのものでそこが問題です。こういう検索式を作ってターゲット側になげて、ターゲットが実装データベースモデルに対して実際の検索要求を投げます。Bib-1というのはMARC21を基本としたシステムなのでローカルデータベースが実体に持っているデータベースのデータはMARC21ベースのモデルとしたデータです。MARC21ベースのモデルを考えるとMARC21のタグでタイトルというのはどこであるというの基準が決められています。たとえば24Xというのは245、246を含むと言う意味でXがワイルドカードなんですが、タイトルというインデックスを指定されたら、アクセスポイントとしてとってきたものを検索するようにと指定された推奨があります。これが一単語でのタイトル検索をしたときの流れです。

それでは論理式になったときにはどうなるかというと、Type-1queryというのがあって、逆ポーランド展開で、たとえばinformationとscienceでand検索をしたい場合には検索式はfind @and ( @attr 1=4 @attr 2=3 @attr 4=2 information ) (@attr 1=4 @attr 2=3 @attr 4=2 science)のようになります。なので日本語の透過の問題が解決した後は、Z39.50のBib-1というのは抽象データモデルと実装データモデルのマッピングをどうするかということが最大の問題になるのです。次にPhraseでinformation scienceというを検索する場合はStructureで1番のPhraseを設定して検索をします。英語の場合はStructureがWordかPhraseかということは意味を持つ訳ですがMARC21をベースとして英語で検索した場合にはデータモデルの写像は大きな問題にはなりません。問題なのはこれを日本語にどう活用させるのかという問題です。日本でデータベースを作るときに英語と日本語をどうやって同じように検索させるのかという問題をやってこられた方も多いと思うのですが同じような問題にぶつかることになります。

例えば日本語で経済を検索するときに、Wordで経済を検索した時に、分かち書きをベースにした日本語データベースでは分かち書きが揺れるという問題を抱えることになります。例えば、慶應のデータベースを例にとりますと「現代日本語経済論」という図書は「現代 日本語 経済論」と分かち書きされたインデックスを持ちます。これで経済を検索しようとすると完全一致形では引けないという矛盾に陥って、ある意味で、分かち書きはスタートポイントを示すためのもので、完全一致形では探さないという日本ではある意味では合意がありまして、だいたいフレーズ型のインデックスを持っていて前方一致で検索をかけるという方法があります。日本語の場合、どんな検索が投げられてもフレーズの前方一致で検索をかけるという、それを前提にインデックスを作っているというのが、分かち書きデータベースでは一番多い形だと思います。NIIの場合はWordで検索されると思います。日本語の場合はWordできてもPhraseできてもPhraseで検索して結果を返すという形になるのではないかと思っています。日本語のデータベースでは日本語も英語も同じ形で持っていると思われますし、投げられた検索要求も英語なのか日本語なのかの区別はつかないと思うので、同じように英語の検索もWordでなげられてもPhraseで検索されることになると思います。そういう形で日本語ではZ39.50からローカルデータベースへの対応をしてきてると思います。

ここまで問題を考えると、いろいろやった結果、落ち着くところは古典的な問題だった日本語における単語という概念をどう扱うかというところになり、この形で提案したいと思います。残された課題は、以前話題になったローマ字の問題になります。以前にメーリングリストに投げましたけれども、日本の現状というのが、ローマ字問題を避けるために、みんなカタカナを持っているということがありまして、NDLも含めてカタカナからローマ字への自動変換で対応しているということでしたので基本は自動変換なのかなぁとは思っているのですが、今それを提案すると、また新しいローマ字が増えるだけですので別途考えたいと思っています。

NIIの分かちがどうなっているかも公開していただきたいなぁと思っています。

あと、慶應であげてるZクライアントのweb版というのがありまして、まぁ引けるは引けるのですがBib-1の全機能をマッピングできているわけではないので、完全一致の場合ですとかBib-1の設定を切り替える場合の指定の時に、Web画面をどうするのかという問題があります。これをしないとBib-1を実装してもBib-1の恩恵を蒙らないということがあります。ここまでの論議を踏まえて結論です。

NIIの実装がありますので、それ以外にはないというのがありますが、文字コードはUTF8、レコードシンタックスは内部実装は別にして、外に出す場合にはMARC21でしょう。最近中国とかロシアとか韓国のMARCが売りに出るのですが彼らのMARCもほとんどMARC21に近い形で、中には245にはそこの国の言葉が入っていて880展開をしてないものが多いのですが、それしかないのではないかと思っています。国内交換フォーマットの問題があります。分かち書きを入れる場所がないとデータ交換の際には困りますが、現状ではデータ交換をしたいというところは、ほとんどないと思いますのでしばらく保留としたいと思います。

最後にサポートするBib-1ですが、ざっと配付資料を読んでいただければ分かると思うのですが、大きなデータベースを検索するときの問題を考えなければいけないということでしょう。いろいろ考えた結果、NIIの実装にほぼ近いものをご提案することになっています。読んでみてください。StructureはNIIはWordなのですがWordの概念がはっきりしないので、デフォルトはPhraseで対応した方がいいのではないかと思っています。ローカルデータベースに求める仕様ということで分かち書きインデックスを持つことと、ローマ字インデックスを持つことというのがありますが、あとでユサコさんの発表でもあると思うのですが、クロスサーチをしたときの共通のインデックスは何かというとアメリカの商品とクロスサーチできるインデックスはローマ字しかないと思います。日本にアメリカのパッケージを導入するときに、分かちという概念なしにはアメリカなりヨーロッパの図書館システムを使うときには使いにくくなってしまいます。最終的にはコンフィグレーションガイドラインを作りましたので案として見ていただいて、ある程度合意がとれたらZIGなりRLGなりに送ってみようかなぁと思っています。報告はちょっと走りましたがこれで終わりにしたいと思います。

2. MetaLib / SFX の紹介

[増田]皆さん、こんにちは。ユサコ株式会社の増田と言います。約30分間の製品紹介よろしくお願いいたします。今日の製品紹介なんですけれども、イスラエルに本社を置くEx Librisという図書館オートメーションの会社の製品でMetaLibいうものとSFXいうものを紹介いたします。特にSFX、よくいろんなカタログで名前が出てきていると思います。だいたいこんなものだということで、ご存知な方も多いと思うのですが、今日はもう少しつっこんだ説明ができればいいなと思います。約30分間の話の中でできるだけデモをと言う話もありましたので前半だいたい15分くらいを私の方で話をさせていただいて、後半の方、私どもの技術サポート部門の伊藤がデモをさせていただきます。今ExLibrisと言う会社は本社はイスラエルにあるんですがSFXの開発はボストンで行っておりまして、その他の製品もハンブルグだとか世界に散らばっております。Ex Librisの場合、かなり代理店がローカライズを担当するというような契約がありまして国内の製品とのインプリメンテーションに関してはユサコがある程度負うということになっております。

早速中身の方に入っていきます。まずSFXの説明をさしていただくのですが、その誕生の背景といいますか、最近のWeb事情といいますかその辺をレビューしてみたいのです。皆さんのサイトで商用出版社から出ているいろんなWeb資源をお使いだと思います。そのようなWeb資源でいろんなリンク機能が提供されていたりすることが多いと思うのですが、そのリンクには多少の傾向があって、どうしても同じ出版系列のグループの製品にリンクしやすいということが否めないと思います。たとえばEMBASE、リード・エルゼビアが親になってその下にエルゼビア・サイエンスとかPergamonだとかMDLだとか最近ではAcademic Press、Churchill Livingstoneといろんな会社が入ってしまいましたが、そこで2次データベースを扱っているEMBASEは3年くらい前に買収したBioMedNetにリンクするということは今も一部ありますし、これからも増えていくと思います。逆にOvid、Wolters Kluwerという出版グループの傘下ですが、このOvidの製品は昔UMIとかBell&Howellと言っていたProQuest、今はProQuest informationになりましたけれどもその製品にくっつくということはなかなか難しいと思います。OvidにはいったSilverPlatterは昔ProQuestにリンクを張っていたのですがWolters Kluwerに入ってしまったらリンクはなくなってしまったと、どうしても利用者不在で出版業界の競争に翻弄されているという一面があると思います。特にエルゼビアグループとWolters Kluwerはどちらもリンクを拒否しているんじゃないかと思われる節もありまして、こういうところでせっかくリンク機能がついても契約の問題で使えないという物もあります。それから今Webで提供されている資料、有料のものも随分増えましたが無料のものもSubject Gatewayと呼ばれているもの、それからE-print server、この辺はあまり違いが分からないというか、Subject GatewayもE-print serverもかなり似通った性格の物ですが、そういったものであるですとか、研究者のホームページ、機関内でデータベースを作られているというところも多いでしょうし、図書館管理システムOPACなどがWeb化されるというのも一般的ですし、それからNIIのUnion Catalog、そのほかYahoo、googleなどのようなサーチエンジンも使いようによっては非常に科学者重宝しているんじゃないかと思いますし、一番みなさんの命題であると思われる電子ジャーナルこれもかなり増えてきていると思います。

こういうWebコンテンツが増加してきて便利になった反面、参照すべきサイトが増えてしまったと、参照すべきサイトもチャネルも増えてしまったということが言えると思います。そんなような背景プラス、どうしてもリンク先を一つに絞れないというようなことも出てくると思います。リンクさせたいんだけども3つくらいの中から選んでリンクさせたいなということもあるでしょうし、リンクのメニューを見せる時に余り多くの想定できる項目を考えてもなかなかユーザーの方が理解できないということもあって、ある程度フィルターをかけてリンクを見せてあげたいということもあると思います。それから機関独自の選択、特異性の対応というようなところもありまして、たとえば留学生が非常に多いような大学であれば、中国からの留学生が利用していると関知できるのであれば中国語のメニューを出してあげるだとか、日本人であれば、日本語のメニューを、スペイン人だったらスペイン語のメニューだとか、いろいろな利用者個々への対応ということもあるでしょうし、先ほど言ったような出版社への依存をできるだけ少なくするという、リンクの矛先の他にも開発スケジュールに翻弄されてしまうということもあるでしょうし、同一タイトルが複数のサービスで提供されていると、たとえばProQuestに入っているような電子ジャーナルはEBSCOからも提供されていることが多いですし、Galeグループという競合会社から提供されていることも多いですし、その他にもオリジナルの出版社から提供されているような場合もあります。そういうような場合、その大学、その利用機関でとっているチャネルを使うことが一番な訳ですけれども、そのようなナビゲーションもこれからの課題、これからと言いますか今の課題だと思います。

その他にも、yahooだとか電子ジャーナルの検索サイトでもいいんですけど、何かコマンドを送ってリンクの先がコマンドを送った結果を見せたいというような場合も、今のハイパーリンクで対応できない場合も多いです。そんなようなことを考えるとリンクを自由に扱うような仕組み、リンクの統合管理というようなものも必要になってくるのではないかと思います。いろんな製品でOPACリンクをさせたいということになるとOvidのために一つOPACリンクの仕組みを作って、他のEBSCOのためにまた作る、Web of Scienceのために作るというようになって手間が増えたりします。そういうことがありますので、統合化ということが非常に重要になってきます。そういうようなことを考えると何かしら仕組みが必要で、今から4、5年前にベルギーのゲント大学などを中心に研究されてきたんですが、その成果がSFXという形で発表されました。そのSFXをEx Libris社が、開発の時もだいぶ協力していたのですけれども買い取りまして製品化したということです。このゲント大学で中心になっていた方はヘルベルトフォンサンベルトという方は今Los Alamos研究所の研究員という立場になっています。そしてSFXという製品の名前になったのですがSFXという英語は一般的にもspecial effectという意味で使われておりまして、このようなSFXリンクを扱う仕組みを作ることは、科学技術に対してspecial effectをもたらすのではないかということで命名したそうです。このSFXを語る時にある程度の技術的なバックグラウンドもお話しないといけないのですが、メタデータに関してはNIIの杉田さんもお話になるということですので簡単に留めたいんですが、一応メタデータはレコードを定義するためのデータという訳語されていることが多くて、そのレコード、実際は何でもよくて、たとえば私を形容するものとして運転免許証だとかパスポートがあると、私を形容するために運転免許証なら運転免許証の独自の項目がありますから、そういう構造を持ったデータが作られている物はすべてメタデータと言えるということになっているはずです。我々がよく図書館関係の世界で言うのは、図書の書誌事項であるとか、インターネットのページ、あるいは、インターネット上のレコードを形容するための書誌データをメタデータということが多いということになっていると思います。何かを形容するために構造化されたデータをすべてメタデータと言えるということだけは、ちょっと覚えていただければと思います。その構造化のフォーマットとして、一番有名なのがダブリンコアと、DCと略したりしてるかと思いますが、割合とEx Librisの製品もDCに近いフォーマットを使っております。そういうメタデータをどう取り扱っていくかということで、メタデータをあるURLとして、ある目的のサーバに送信すると何かしらのことができるのではないかという発想がありまして、そのURLとして発信するための記述方法がたとえばOvidならOvidである方法がとられている、ProQuestだったらProQuest独自の方法があるというのでは非常に困ると、でその記述の方法を公開して、皆さんこれを使ってくださいと出しているのがOpenURLというものです。この記述の方法はホームページにあります。

記述例を3つこちらに載せてます。一番最初のものが、割と馴染みの深いようなメタデータなんですけれども、このOpenURLというのは前半と後半にわかれまして、前半部分が送りたいターゲットのサーバのアドレス、この例で言うとhttp://SFX.usaco.co.jpと。こういう名前ではないですがユサコにもSFXのサーバがありまして、そのサーバに対してデータを送りたいんだという宣言をしておきます。その後にデータをさばいてくれるプログラムの入ったディレクトリなどの名前がきまして、?の後に割と書誌事項的なメタデータが記述されてます。この記述の方法もちゃんと定義されておりまして、ホームページにいけばその記述のルールが見られます。ここではジャンル=articleとありまして、articleと来ると雑誌の論文を表すということになってますし、その後&でデリミターの意味を表してまして、ISSN=1234-5678と、でまたデリミターが入ってボリュームいくつとか。この後は特にご説明しなくてもお分かりになると思います。このような記述の仕方ですとか、2次的なメタデータといいますか、ちょっと書誌事項的なものと違うメタデータもあるんですけれども、それが2番目の例で、やはりSFXのユサコのサーバにターゲットをもって、その?のあとにsidとありますがサービスプロバイダーのIDはOvidだと、でOvidのMEDLINEを使っていて、OvidのMEDLINEプライベートのIDが123456だと、後でOvidのMEDLINEに対してpid=123456は何かという問い合わせをすればこのような1次的なメタデータが得られるということになりますので、こういうものもメタデータと考えています。

その下がDOIを使った例です。DOIをなげてあげればCROSSREFのサイトでメタデータ化することもできますので、この場合、Academic PressのGenomicsというもののDOIが入ってますが、こういうものもOpenURLで送信することができます。これ実際にOvidという会社のSilverPlatterインターフェースでMEDLINEの検索結果なのですけれども、この検索結果からどんな拡張サービスが受けられるかというと、著者のところからcitation indexに飛ぶこともできますよ。と それからソースのところからフルテキストに飛ぶことも、ISSNからULRICHのデータを参照するとかOPACのデータを参照するだとか、キーワードのところからSubject Gateway を参照するだとかMEDLINEのアクセッションナンバーからPubMedのデータを引っ張ってみるだとか、いろいろな使い方が考えられます。そういうことを図書館側が利用者にとって適切だと思えば、リンク先として作れるということになります。

そういうメタデータをOpenURLという規則で送れるという環境が整うと、どんなことができるのかということをフローチャートに示してあります。左側から見ていただくのですが、利用者側で元になるサービスとしてWeb of Scienceを使っている前提で作ってあります。一番左のNetscapeの画面はWeb of Scienceの結果画面になります。検索結果にはSFXのボタンが並んでいて、Web of Scienceを例にとってますからISIに私の機関はSFXサーバを導入しましたよと連絡していただければ、ISI社が勝手にこのボタンを作ってくれます。そういう導入をSFX Enabeledと言います。そういう手続きをISI社にしなければならないということが、まず重要なのですが、SFX Enabeledにしますとユーザーがこのボタンをクリックした時に、この検索結果が持っているメタデータをOpenURLの記述方法に乗せてURLとして飛ばしてくれます。その矛先が何でSFXサーバに行くかというと、先ほどのOpenURLの前半の部分がSFXサーバのアドレスだから、こちらに行く訳です。そのOpenURLの解析部分でOpenURLのデータを読み取りましてそれがどんなものかという解析をするわけですけれども、先ほどのDOIだったりOvidのMEDLINEのパーソナルIDが出てる場合がありましたけど、そういう場合にはもう一回サービスベンダーの方にDOIなりパーソナルIDを問い合わせに行って、もっと細かいメタデータをもらうという作業が発生することもあります。そうやって得たメタデータを処理するんですけど、この処理の過程で、例えばユーザーが中国からの留学の方ですよとか、何々学部の方ですよとか、いろんな情報も取り込むことができまして、そういう情報をもってThreshold部分、条件フィルター設定部分にデータを持ってきます。持ってきた物を解析して中国の留学生の方だったら中国語のリンクメニューを作ろうとか、今どんなデータを見てるのかも分かる訳ですから、そういうデータを見ているのだったら拡張サービスが、学内にあるこんなサービスが有効なんじゃないかだとかがリスト化されてユーザーに提示されます。それがSFXメニューと呼ばれるものです。こういう設定をするためにはリンク設定ファイルに図書館の方がどんなサービスが有効なものかということを入力しなければならないのですが、それもSFXのソフトの中で段階的に作れるようになっています。このリンクメニューで、このオリジナル文献がHighWireのProceedings of National Academy of Sciencesだとすると、このオリジナルで取りたいですか、というメニューがありまして、それをクリックするとまだSFXサーバの方に行きまして、ボリュームだとか巻号だとかページだとかそういうデータが行きまして、StanfordのPRNASのサーバに投げてこの該当するフルテキストの画面を出すということになります。ここでまたHighWireの方もSFX Enabeledにすることもできたりしますので、また同じサイクルが生まれるということもあります。

これがSFXの仕組みのあらましです。どんなソースがSFX Enabeledにできるのかということが、こちらに出てましてISI, Ovid, EBSCO, ProQuest という商業出版の他にもPubMedもこの4月にSFX Enabeledの仲間に加わりましたし、だいぶん前からIOPだとかLos Alamosの国立研究所のサイトも入ってますし、CASだとかOCLC、BioMed Centralというフリーの電子ジャーナルサイトも入ってますし、最近またDialogも追加されたということで、だいぶん増えてきていると思います。物理関係のサイトというのは随分初期の頃から入っていたなという風な印象があります。先ほどの元になるサービスが左側だったのがSFXのenableソース、その後メニューにのってどこに飛ばすかというところがターゲットになるのですけれども、リソースもターゲットも添付資料としてつけさせていただいてます。

我々の問題として、SFXのターゲットに国内のサイトをどんどん追加しなければならないということで、一番最初に取り組んだのがRICOHのLIMEDIOのサイト、それからNIIのWebCATに取り組みました。今後はNDLのWebCATだとか、他の会社さんのOPAC製品などもターゲットとして付け加えていきたいと思います。リンクレベルが重要と書いたのですが、ターゲットが電子ジャーナルの時にすべて該当論文までいくとは限りません。これはそれぞれの電子ジャーナルのサイトがどのくらい利口かということにかかっているのですけれども、どういうコマンドを送ってどういうリクエストをすればどこまで出てくるかということが、なかなか一様ではないので、その辺である物に関してはその雑誌のホームページまでしかいかないというようなことも出てきてます。この辺もいろんな手を使って解決しようとしてます。SFXという仕組みを作るのに、こんなようなモジュールがありますよと書いたのですけれども一応ソースを解析するためにロジカルに組まれたツールが付いてきます。Threshold設定というのはある条件でこれ以上数値が増えたらこうしろとか、数値じゃなくてもいいんですけど、そういう条件分けをするための設定ができる、組み合わせでマクロのような形で作れるものがついておりまして、かなり重宝します。ターゲットを自分たちで作っていく、例えば今回もWebCATの設定をなどすることがあったんですけれども、そういうターゲットを作るときのいろいろな分析プログラムというのも、今のところ25種類くらい最初からこのSFXのパッケージに入っています。あとKnowledge baseといいましていろいろな電子ジャーナルの動向をEx Libris、それから代理店側がwatchingしてKnowledge baseに追加するということをしてますので、それを2ヶ月に一度更新して利用機関の方に提供するというサービスもしています。あと、もう一つのコンポーネントでMetaLibというものがあるのですけれども、ポータルツール作成ツールというもので、図書館の電子製品に対する玄関を作ってくれます。最初に入ったときにユーザー認証をしてくれますし、ユーザー毎に自分のページを作りたいだとか、自分のスペースを持って検索式を置いておきたいとか検索結果を置いておきたいというようなこともこの中でできるようになってます。全サービスに対する統一のインターフェースを提供するということもあるのですが、これはZ39.50のプロトコルにも対応してますし、その他にも何種類かの図書館システムが使っているプロトコルにも対応しています。その他にもAPIといいますか、大概の検索インターフェースというのはどんなコマンドを送ったら、どんな結果が出るのかということが決まってますので、そういうコマンドを覚えて送る機能がついています。検索結果のサービス別統合表示、たとえばOvidのMEDLINEとPubMedをいっぺんに検索するという場合にその結果を別々に表示したり、合わせて表示したりということができます。それから異なるサービス間の検索履歴の演算処理ということで、今までできなかったのは例えばOvidのMEDLINEとPubMedのandをとるだとかorをとるということはできなかったと思います。こういうものも、このMetaLibではできるようになっていまして、その処理のためには中でOracleを使っています。それからこのMetaLibのコンポーネントの中にはSFXも入っていますので、ある検索結果から拡張サービスにナビゲーションするということもこのSFXでできるようになっています。それからいろいろな管理者機能がありまして、統計をとるだとかグループ設定で、あるグループに対してこういうことができるようにする、できないようにするということができます。情報資源、いろいろなタダのサイトだとか有料のサイトを合わせて一覧表示するだとか、Subject別に表示するだとかいうようなことができるようになってます。こんなことを合わせて、このMetaLibキャッチフレーズとしましてWeb資源をうまく収めるための本棚じゃないかというふうに我々では考えております。

構成インターフェースとしまして、4つありましてリソースを管理するためのinformation Gateway 機能、統一インターフェースを作るためのUniversal Gateway機能、それからユーザー管理やユーザーエリアを提供するためのuser admin機能、状況判断型のリンクを司るSFXサーバと大別すると4つのコンポーネントからなっています。それを支えているのがKnowledge baseです。今導入機関として、多分機関数に直すと300とか、そのくらいはなると思うのですが、大きなコンソーシアムが随分入ってますので、Ex Libris側の発表では65くらいです。これもEx Libris社のサイトでcustomerというところを見れば、ある程度検索できます。導入費用は、ちょっと価額が最近、去年よりあがったのかなと我々も思っていまして、だいたいソフトの価額がFTEで2万人くらいのところで600万とか700万とかしてしまっています。これFTEベースで値段が変わりまして我々も正確なスケールを持っていないのですけれども、開発コストといいますか、どんなものを資源として取り込んでいくかということで、また値段も追加されますので、例えば社内のデータベースもSFXでターゲットになるようにしてくれ、あるいはEnableできるようにしてくれ、MetaLibのリソースとして一括検索できるようにしろとかいろんな要求を受けると、それに見合った開発の工数を計ってそれで見積書に加えていくということになりますし、あとインストールトレーニングも、割と簡単なメニューがついていろいろ設定できるんですよとは言うものの、ある程度、全貌をお話するだけでも何日か掛かりますので、この部分も何十万単位のお金がかかりますし、あとOracleを使っていることもありますし他のソフトのバージョンアップなどに対応するだとか、Knowledge baseを購読するだとかいうことで保守料も結構かかります。ハードウェアの方ですが一応プラットホームとしてSolarisとLinuxに対応していますが、Solarisでいくと300万円台、Linuxでいくと100万円前後というところが目安の金額だと思います。ここからはデモを伊藤の方からさせていただきたいと思います。

[伊藤]今回なんですが弊社の方に設置しましたデモサーバでやらせていただきたいと思います。まずMetaLibのログインのところに、ログインとguestというボタンがあるんですが今回は登録したユーザーで入ろうと思うのですが、別にguestで入ることもできまして、guestで入った場合は機能に一部制限があります。検索できるデータベースもフリーのリソースのみ、たとえばOPACですとかPubMedといったその辺のフリーのリソースのみとなってしまいますので、今回は登録したユーザーで入りたいと思います。登録したユーザで入りますとここにプロファイル、後でご覧いただきますけれども、登録したユーザーの名前が出ます。一応日本語も通ってますね。これMetaLibのホーム画面と呼ばれる画面なのですが、ホーム画面の左側にそれぞれのリソースが分野ごとに並んでまして、それをクリックしますとHistoryですとHistoryの分野のデータベースを見ることができます。登録したユーザーですと自分でMy リソースリストというものを持つことができまして、Myリソースリストの中には自分がよく検索するデータベースを予めセットしておいて、それを毎回検索するということができますので、今回はMyリソースリストでやりたいと思います。

今回デモで用意しましたのがOvidのデータベースと、フリーのリソースでHighWireとPubMedと札幌医大さんの方で実績がありましたので、Limedioさん、札幌医大さんのOPAC、LimedioさんのZのサーバーなんですけれども、そちらににつないで、あとNIIさんのZのサーバにもつないでます。最大40くらいはここに付け加えることができるのですけれども、実際検索できるのは8つのデータベースということを目安でやっています。検索し始めますと、画面にstatusでSearchとfitchingというのが出ます。今回、同じMEDLINEですけれどもOvidとPubMedで検索の年代が変わってますので検索結果がかなり差が出てしまっています。それぞれの検索結果をご覧いただきたい場合は、それぞれのタブを押していただいて中に行きますとAuthorですとかTitleですとか一覧にいきます。さらに詳細な情報をご覧いただきたいときにはmoreを押しますと見られます。Holdingも日本語が通るようになりました。この検索結果に対して掛け合わせですとかマージをしたりということもできるんですけれども、マージはちょっと時間がかかりますので今回は省略させていただいて、検索の履歴はhistoryというところでご覧いただけます。今回のセッションの履歴は、ここにカレントqueryと出ますけれども、以前検索をしてsaveをしたものに関してはSaved queryでここに残りますので、いつでも戻ってもう一度検索することができます。さらに登録したユーザですと、それぞれの検索の結果をe-shelfというホルダに収めることができます。e-shelfというのの中を見ますと過去に検索したものも毎回参照することができます。リソースリストなんですけれども希望に応じてデータの付け加えということもできます。ここにlink toというまた別の項目があるのですが、これはMetaLibのこの検索画面では検索できないのですがWebサイトの方にリンクすることができます。MetaLibは、先ほどUniversal Gatewayというような感じで統一インターフェースの提供というのが出ましたけども、リソースの管理ということでinformation Gateway 機能といった両方の機能を持つことができます。

先ほどの検索結果の画面の上の方にSFXをいうアイコンが出ていたかと思うのですが、それをクリックしますとSFXのメニュー画面というのが現れます。今回は札幌医大さんのOPACですとか、ISIのダイレクトエクスポートツールがEndNoteとかそういった文献関係のものになりますし、googleでさらに検索することもできます。札幌医大さんの方はここから文献複写の方にとんでILLのリクエストフォームにデータを渡したりという使用ができています。

次にPubMedの検索結果からSFXのメニューを出してみたのですが、今回はメニューがちょっと変わりましてエルゼビアのWeb editionというフルテキストの方にリンクをはることができます。先ほどのリンクのレベルという話をしましたが、エルゼビアのWeb editionはまだフルテキストには直には行かない状態になってます。さらにPubMedに行ってAbstractを確認するというようなこともできます。このSFXを利用できるサービスなんですけれども、先ほどSFXのリソースのリストというものがございましたがMetaLib以外にも他にいろいろございまして、今回はGaleのInfoTracというのをデモに取り上げたいと思います。まず普通に検索をしてみます。通常SFXのサーバを導入されていない機関では、ボタンがでませんが、今回はSFXのボタンが出るようにしてあります。SFXメニューをここで表示させますと、JSTORというアーカイブの方のフルテキストにリンクを張ったりですとかWeb of Scienceの方につないで著者名等で再度検索したりとかはできるようになります。SFX、ただのリンクのツールというよりも、各機関で導入されているデータベースのリソースを、そこにこれだけのデータベースが学内で利用できますよという指針というか目安、ツールにも使うことができるのではないかと思います。契約が必要なリソースと、OPACとかgoogleですとか無料のリソースも含めた総合的なサービスがSFXの方でできるようになります。さらにWeb of ScienceですとSFXのターゲットでもあり、リソースでもありますのでWeb of Scienceで検索した結果のところにもまたSFXのボタンが出てきて、そこから更にSFXのサービスを受けることができます。今回Web of Scienceはデモのサイトにつなぎますので残念ながらSFXのボタンが出てきませんが、本来なら出てきます。

以上でデモを終わります。

[増田]状況判断型リンクというのがSFXなんですけれども、それぞれのデータベース、あるいは場面によってメニューが変わると、また利用者の身元などにも反映させることもできますけれども、その辺がSFXの特徴です。あと、リンクのレベルもどこまで、articleレベルまでいくのか、issueレベルまでしか行かないのかというのもホームページ上で掲載されてますので、そちらも参照していただければと思います。製品紹介をこれで終わります。どうもありがとうございました。

[入江]こういう仕組みというのは、日本でも図書館情報大とか一番大きなところでは東工大とかで、実はやってこられているんです。個別的にはいろんな意味でいいものができていたし、そんなに遅れてはいなかったんです。こういうふうにポリシーで動く人たちと、それを維持できる力と、自分のOPACも含めてオープンリソースとして、うまくWebの世界の中でリンクしていこういう考え方が弱かったんだと思います。個別的な技術でいくと、東工大のものも当時でいえば先駆的でよかったのですが、その時もZを使っていたのですが、MARCフォーマットをZで使えなくてSUTRSでやっていました。もともとこの研究会を始める前提となったのが、目録データベースも含めて、通常のオープンリソースとして全体で利用していく形で物を作っていきたいというのが僕なんかの考え方で、そのためには検索のやり方やインターフェースも含めて合わせていこうと、NIIがある意味で目録データを含めて全体的な日本における標準化、統一化をしてきているんですが、それをもう少し国際レベルでうまくいけるような形でやっていきたいというのが、この研究会のはじめだったと思います。そういう意味で、こういう動きというのはどんどん広がっていくでしょうから、日本においてもいろんなデータベースがこういうデータベースとオープンリソースとして、うまくリンクできるような形で物事を展開していけるような準備をしていかないといけないんだろうと思っています。日本におけるCD-ROMサーバが、全然横断検索できなかったけれども、外国の製品はほとんどできるようになっているという前提は、考え方が違うんだろうということがあるんですけれども、こういう流れの中で、僕らもなんとかしたいとこれを見る度に思っています。

--休憩--

| 1 | 2 | 3 | TOP |