研究会報告


| 1 | 2 | 3 | TOP |

LCへの提案について

[酒井]慶應大学の酒井由紀子でございます。LCへの提案Z39.50推奨プロファイルと関連する目録標準の検討事項ということで発表させていただきます。まずこの発表の目的なんですけれども、本研究会で作成したZ39.50推奨プロファイルを日本語をハンドリングする図書館システムの標準の一つとしてLCを中心としたグローバルなコミュニティに提案してフィードバックを求めたいという行動の予定があったと思います。これについて、今回意義と目的についてWHYということで確認したいと思います。それから、具体的な方法、5W1Hの残りの4つのWとHですけれども、こちらを私の方から提案申し上げますので皆さんで議論していただきたいと思います。そして期待する結果と今後の展開についても確認したいと思います。

まず、この行動についての意義と目的なんですけれども、グローバル標準を視野にいれて日本の標準について議論して推奨プロファイルを作ってきました。この作成した日本の標準というのを実際にグローバルに活用していただかないと意味がございません。そのために、実質的に世界標準を作成維持しているLC、議会図書館に発信しようということです。それから、その目的というのは存在を認知してもらうということがまず一つ、それから実際に具体的なフィードバックを受けて実際に使えるものかを確認すること、そして必要な改訂や残された問題解決の材料としたいと思います。最後には、使えるものとして世界及び国内へも広げていかなければなりませんので、その一助としたいと思っています。

具体的な方法なんですが、これから作業に取りかかって、2003年の2月くらいに具体的に提案をするということを目的にしたいと思います。誰がというと、このライブラリーシステム研究会からです。何をということですが、一つはこのライブラリーシステム研究会の目的と活動について、背景的な情報を提示しなければいけないと思います。具体的には2つあります。Z39.50の推奨プロファイルそのもの、そしてもう一つは目録標準に関する問題点というのが継続的に検討してきています。これについては、まだ最終的に結論を得ていないものもありますが、それもやはり、この時点で提示したいと思います。それぞれの問題についてフィードバックを要請するということです。このWHATの部分について具体的に確認いたします。まずライブラリーシステム研究会の活動と目的ですけれども、図書館システムのグローバル化に対応するために、システムライブラリアン、図書館システムベンダー、書誌ユーティリティや研究機関の有志によって研究会が組織されています。最初のプロダクトとして、日本におけるZ39.50のプロファイルについて論議して推奨プロファイルを作りました。先ほど申し上げましたように、関連する目録標準については継続検討中のものもあります。まず、推奨プロファイルについてですが、前回の研究会、及び前々回でも入江の方からお配りして説明いたしましたけれども、一つのものが出来ています。特徴としてはグローバルに利用できるインターフェースであることと、もう一つは国内でも普及可能であるという特徴があると思います。具体的には、グローバルという意味では文字コードはUTF8を使う、それからレコードフォーマットはMARC21のタイプ1に準拠する、分かち書きインデックスを持つことを前提としている、同様にローマ字インデックスを持つことを前提としている、というものです。国内では、国内インターフェースはMARC21の拡張によって対応が可能である、そしてNIIの提供するターゲットと調整可能である、ということで既にプロファイルができあがっていますので、それをそのままLCのZ39.50の部署へ提案するということでよろしいかと思います。

次に継続検討中のものについてですけれども、これはどちらかというと目録標準の問題になってきています。たとえば件名、これについては日本の図書館のプラクティスでは、もしかしたら言い方が悪いかもしれませんが、これまで軽視されてきています。一方、欧米のプラクティスでは適当なSubject Headingのついていないデータというものの評価は低いです。という認識までは我々はつかんでいるところだと思います。これに対してLCのSubject Headingを付けた方がいいのではないかという議論は見えてますけれども、全員のコンセンサスを得られたというところまでは至ってないかと思います。次にヨミのデータです。これは一般的にヨミのないデータがあります。例えば300、Physical Descriptionのところですが、これについてヨミを付けるかどうかといった細かいところまでは、まだ議論してないと思います。また非ローマ字のタグの持ち方があります。これは70年代にアメリカで始まった880というタグに非ローマ字だけを集めて記述するという手法を維持するかどうかということについて、まだ具体的に議論してないかと思います。これについては、この後に国内交換フォーマットということで丸善の佐藤さんからお話があるかと思います。ということで継続検討事項の中で目録標準の問題についてはZ39.50とは別の次元で国内外で議論が必要であるかと思います。ただ、何も方向性がないままに提示しても仕方がありませんので、ここで、ある程度議論して一定の方向性、たとえばLCSHを付けたらどうだろうか、というような方向性を示した上で、LCのMARCの窓口に投げてあげるのがいいのではないかと思います。それから、もう一つ継続検討事項として日本語の問題が大きいということを我々は確認しています。具体的には、ローマ字の標準がない、あるいは分かち書きの標準がないということです。ただ、これは図書館に限らず、国内唯一の標準がないということですので、一応の指針を示す必要があるかと思いますが、別の次元で、国内の議論を先行させる必要があるかと思いますので、ここで急にLCに提案ができるという段階ではないかと思います。そしてフィードバックの要請です。推奨プロファイルについてはグローバルな利用が可能かということの確認、目録標準の問題についてはグローバルな観点からプリフェランスがないかということのフィードバックを要請したいと思います。先ほど申し上げたように、日本語に特化した問題、ローマ字分かちについては国内の論議を優先させたいと思います。そして、どこにどのようにということですが、Z39.50についてはMaintenance AgencyがLCの中にございます。そしてそこで推奨プロファイルをリストにしています。そこに我々の作ったものをリストにしてください、ということを依頼すればよろしいかと思います。もう一つMARCのことですがMARCのフォーラム、メーリングリストがあります。こちらの方に目録標準についての問題点について一定の方向性を示した上で広くコメントを求めてはいかがでしょうか、ということが私の提案です。実は、このやり方というのはいくつかオプションがあります。まずZ39.50についてのオプションなんですが、プロファイルとしてリストしてもらうだけではなくて、さらにZIG、Z39.50 Implementors Group の推奨をもらうですとか、IRPと呼ばれる Internationally Registered Profile というところの承認をもらうという、一段階二段階上の段階もございます。今回はリストをするというところまでを一つの目標にしたいと思います。その他にRegister of Implementors ということで、実装している団体とか組織をリスト化するということを、LCのMaintenance Agencyでやっています。こちらの方では具体的に国内の実装した団体ができたところであげるですとか、これから作業しなければならないこともあるかと思いますので、今後の問題だと思っています。それからMARC21のことですが、LCの方に窓口が三通り用意されています。一つは先ほど申し上げましたメーリングリストに、まず投げてみるということが一つです。その他に、アドバイザリ委員会というのがあります。これはALAアメリカの図書館協会のMARBIと呼ばれる委員会ですとか、National Libraries、アメリカのナショナルライブラリーも入っています。カナダ、オーストラリアの国立図書館も入ってます。それから大規模なOCLCとかRLINといった書誌ユーティリティも入っています。こちらの方の委員会に提言をするという可能性もあります。もう一つがMARCの標準のオフィスへ直接提言をするということもあります。しかしながら、先ほど申し上げたように、我々でもまだ結論が得られていないということでもありますので、まずはMARCのフォーラムに投げてみてはどうかというのが私の提案です。

そして最後に、期待される結果と今後の展開です。LCを中心に研究会の活動とプロダクトが認知されるということが先決だと思ってます。実にLCというのは日本のことを知っているようで知りません。例えばMARCのメーリングリストで二年ほど前に日本のMARCの標準とは何なのかという質問に対して、JAPAN-MARCがあって、確かUS-MARCとのマッピングしたはずだという答えだったんですね。その時に問うてる人はNACSISのフォーマットがJAPAN-MARCのフォーマットなのかというような言い方だったんですけれども、それについて詳しく答えたのは私で、その他に日本人のポストは一件もございませんでした。

そしてフィードバックを受けて、Z39.50の標準の整備を進めると同時に国内での広報、実装を進めるということ、そして目録標準については継続検討事項については指針をまとめて国内及びグローバルコミュニティにもう一度提案をするということです。先ほどから申し上げているようにローマ字と分かちについては日本語の問題として別途検討する必要があると思っています。以上が私の提案と確認でございます。

[入江]付け足しではないのですが、慶應がRLGのメンバーになったことに伴いRLIN経由でZ39.50のテストをしないかという話がきています。ご報告したいと思います。NIIさん、Z39.50を立ち上げてどうですか。

[阿蘓品]情報研の阿蘓品です。Z39.50のゲートウェイサーバ立ち上げまして、実際に使うという申告を受けましたのは30から40です。実際にどれくらい使われているかについてはログを解析してないので分かりませんが、ちょいちょい問い合わせは来てますので、使われてはいるのかなぁと思っております。

国内交換フォーマットについての提案

[佐藤]丸善の佐藤でございます。今後の問題提起という形でできればいいなと思いまして、大至急でちょっとやってみました。一つは、昔からの思いでUS-MARCに日本語を乗せたいというのを、ずっと思ってまして、実はCALISという図書館システムのエンジニアをやっているときにJAPAN-MARCとUS-MARCという二つのデータを和書と洋書で分けて扱いながらずっとやってきたわけですけれども、大学図書館のところではNACSISのCAT-Pの形式が和洋統一の一つの形として出来ているわけですけれども、公共図書館であるとか、それ以外の所では、未だもってその辺の話は出来ていないという部分があります。一方で、RLG、OCLCのCJKのレコードを見ると、数百万のレベルで日本語の資料がカタロギングされているという実態を目の当たりにしまして、非常にショックを受けたことがありまして、MARC21が多言語化になりましたので、ここに何とか日本語を乗せることができないかということを考えました。国内交換のために求められることは、ということで思いつくままに列挙してみたんですけれども日本語書誌独特の並列の記述漢字かな混じりの部分とカタカナヨミローマ字ヨミ分かち書き、それぞれ、実は例えばローマ字なんかは日本の国内では要らないのではないかといった議論もあったんですけれども、基本的にはそれぞれ役割があるんだなぁということをもう一度確認しないといけないなぁと思っています。例えば漢字仮名混じりの部分というのは標準的な記述で日本のライブラリアンの中で九割が自分の目録をローマ字で書く人なんて一人もいないわけで、自然に書きたいという要求を持ってらっしゃるというふうに思います。カタカナ読み。特にこれはユニコードになると重要な意味を持ってくると思うのですけれども、今後、様々な図書館の中での配列を制御する上ではヨミというのは重要な位置づけになってくると。それからローマ字ヨミについては先進的ないくつかの大学図書館では、アルファベットによる配列を制御しているところもありますので、RLGなんかに言わせますと万国共通のアクセスポイントですよと、この辺は文化的に異議を唱えたい部分もあるわけですけれども、それはとりあえず置いておいて、基本的にはそういった位置づけもあると。それから分かち書き、特に漢字仮名混じりにの部分の分かち書きですけれども、こういったところがでてきていると思います。今あるデータを上手に使えないと意味がないと。一から作っていると気が遠くなるような世界になると思いますので、極力国内の各種マークからの機械的な変換ができることがいいだろうなと思ってます。ただ細かい目録規則ベースの話になってしまいますと、土台機械変換などは無理な話になってしまいまして、あくまで外形式といいますか、形の上でのMARC21対応ができればいいのではないかと思います。場合によれば必要最低限の記述の追加が必要になる部分、先ほどの酒井さんの報告にもありましたようにヨミのない部分をどうするのかということもあるでしょうねと思います。もう一つは国際標準との互換性が維持されることということがあります。これについては一言申し上げたいことがございまして、例えば米国においてはANSI/NISOという標準化規格団体がライブラリに関する様々な問題解決の標準化を進めているわけです。そういったことをどうして共有できないのだろう、と。日本とアメリカとヨーロッパと考え方が違うからというのではなくて、どこも同じことをやっているのはやはり無駄が多いですし、図書館の扱うデータの量からいったら、どこかで共有化していかなくてはまずいだろうと、その基準がMARCだとするならば互換性、互換性というのはもちろん機械的な互換性もそうなんですけれども、ぱっと見てもらって理解してもらえる、そういったレベルの互換性の維持がある程度必要なんじゃないかなと思いました。一つは文字コードについては、UTF8という形で整理できるのではないかと思います。もちろん互換性が維持されることは大事だと思うのですけれども、決してそれが国内の目録作業で簡単だということには、ある面ならないと思います。ある部分において、館内で独自のフォーマットをとりながら逐次的に変換する、向こうの人たちがよくオンザフライと言いますけれども、逐次的に機械変換するような簡単なロジックが必要だろうと。もう一つはBIB-1アトリビュートに代表されるアクセスポイントの共通化、ライブラリアンの方が海外の方とアクセスポイントについて議論するときに245は251だっけっていうふうに読み替えなくてもいいような、そういった共通化があった方がいいだろうなと思います。それから拡張への容易な対応ということで、国内ですとJAPAN-MARCですとかNIIのCAT-PですとかTRCのMARCですとか様々なMARCありますけれども、これを今流行りのXMLのDTDに展開するときどうするんだろう、またみんな一から議論するんですよね、という形で、MARC21にしておくともうできているというか大きなコミュニティーの中で議論が進むでしょうというところで、拡張の容易な対応が必要だろうと思います。あと、一番最後に、これは私の立場で申し上げることではないのかもしれませんが、一年くらい前に中国の方の論文を読んでいた時に、著者名典拠ですとか件名の典拠がLCをベースに動いていると、それはそれでいいのかもしれないのですけれども、その中に例えば中国では国内の考え方をきちっと反映させたいと書かれていた方がいらっしゃいました。それは日本の中でも同じだと思いますのでそういった国際標準といったところに日本としての発言ができるような、そういった部分のベースになるような仕組みが必要なんだろうというふうに考えております。

国内交換のために求められることということで、何か手はあるの?ということで、とりあえずMARC21のマルチスクリプトモデルというのがあります。LCのサイトにすると、たった1ページのところにあがっている内容なんですが、ここにMARC21で多言語をどう扱うかというモデルの提案がされています。提案というか一つの考え方だと思うのですが、大きくはこの考え方には2つありまして、いわゆるモデルAと言われる考え方とモデルBと言う考え方があります。モデルAについては、この一年間当研究会が今まで議論してきました880というAlternate Graphic Representationというフィールドを使ったラテンへの字訳・音訳による記述と漢字の記述を併記しようというやり方です。この後例が出てきます。この後の例の1、2のところではラテンへの字訳・音訳をレギュラーフィールド、880以外のフィールドに記述するというもの、3つ目の例としてあがっているのが非ラテン系言語による通常記述ということでレギュラーフィールドに直接ヘブライなどを書いてしまおうというモデルがあがっています。それからモデルBの方は非常にシンプルな多言語記述という形で、リンクフィールドを持たないでレギュラーフィールドにどんどん母国語を書いてしまおうというような例です。モデルAの中に出てきます880と、それに伴うコントロールサブフィールド$6についてちょっと簡単にLCのページにあったものを列記してみました。$6というサブフィールドは他のサブフィールドとちょっと違って、フィールドをコントロールするためのサブフィールドということになっています。特に、ここはリンケージ、レギュラーフィールドと880の間のリンクを表示するフィールドというふうに定義されていまして、最初にLinking tagということでリンクする通常タグがはいっていまして、次にOccurrence Numberということで1レコード中の各リンク関係を識別するための二桁の番号、数字がはいっています。これはシーケンスでなくてもユニークであればいいみたいですが00はレギュラーフィールドがなく、リンクしないというオプションがあるようです。その後ろはScript Identification Codeということで、880に実際に書かれている記述の識別コードということで、例えば(3と入っていればそれはアラビックだよと$1と入っていれば、それはChinese,Japanese,Koreanだよ、と(2と入っていればヘブライだよというようなことが定義されています。最後のフィールドオリエンテーションコードは記述の向きということでアラビア語のように右から左へ各言語をrをつけて表しています。それを踏まえてLCにあがっているモデルAのデータです。LCのページが分かりにくくて、どこかにいい例がないかなと探したら、たまたまアメリカの図書館システムを作っている会社ですけれどもLibrary Corporationというところが非常にきれいなMARC21のマニュアルをWebにあげていらっしゃって、ちょっとだけ借用しました。これが最初のラテンへの字訳・音訳によるフィールド記述、これが一般的なよく見かける記述の仕方です。今回ライブラリーシステム研究会でプロファイルの中に推奨したMARC21のスタイルというのは、まさにこの形でレギュラーフィールドにローマ字を書いて、880のところに日本語の漢字仮名混じりを埋め込んでいくというやり方です。例2はあまり変わりはないのですが、右から左へ読むものの例です。例3の方はレギュラーフィールドにアラビア語を書いてしまうというような書き方で、ただし880に字訳したラテンをそのまま書いていくというスタイルです。もう一つモデルBのシンプルというのになりますと、レギュラーフィールドの中にラテン系と非ラテン系が混じって入ってしまうというような書き方があるというのがLCが言うところのマルチスクリプトのモデルの例です。なるべく、これをくずしたくないなという方向で国内向けの考え方で整理したんですけれども、日本語の記述を想定すると、モデルBはシンプルな多言語記述だけれどもリンクをもっていないから、カタカナヨミやローマ字ヨミをどういうふうに記述したらいいんだろうかと、場合によってはサブフィールドを拡張するか、もしくは二桁しかないインディケータを拡張するしかないということで、これはちょっとやりにくいなぁというのがモデルBということで最初に消去しました。実はモデルBがいいんじゃないかと最初は入江さんとも話していたのですが、よくよく考えると、これはやばいぞということになり、モデルAの1と2の方を検討しました。まずモデルAの例1なんですがラテンへの字訳・音訳によるレギュラーフィールドなんですが、いわゆる北米におけるCJKレコードの標準的な記述の仕方ではあるんですが、ご存知のようにカタカナヨミが並列して記述しにくいと、記述しにくいというかほとんど記述できないと、ローマ字と漢字仮名混じりは何とかなるという形です。もしこれでカタカナヨミを入れるとするとサブフィールド$6のScript Identification Codeに日本語のカタカナヨミとか日本語のローマ字とか日本語の分かちとかを付けてもらうと書けるかなぁという感じはしました。もう一つ、こちらの方が大きかったのですが、レギュラーフィールドへのラテン以外の記述が制限されるということで、300がもとのデータが日本語で書いたものしかないと、「1冊」とかですね。改めてローマ字を入れるかカタカナのヨミを振ってやらないと、データが作れないというような厳しさがでてくると思います。これは既存のデータをうまく流用するというところでは難しい問題になるなぁということです。続いてマルチスクリプトのモデルの例3の実装かけてみたものです。日本語でレギュラーフィールドを書いてしまおうというもので、実はこういった形を実装しているところでは国内では私の知ってる限りでは2つ、慶應大学さんと早稲田さんです。日本語を直接レギュラーフィールドに書いて、あとはフィールド880とコントロールサブフィールド$6でカタカナヨミとローマ字の対応がこんな感じでとれるかなぁというふうに思いました。カタカナのところは$1を書いて、ローマ字は(Bという形であれば、そのフィールドがローマ字なのかカタカナなのかというのは一応機械は分かるだろうというふうに思ったわけです。実際にいくつか乗せてみるとまあまあ入れるかなぁと思いますが、250、版を書くところのヨミといったところはローマ字にすると落ちてしまうのですが、日本語をダイレクトに書ければ当然書けるだろうという書き方です。300あたりはページ数であれば半角変換をかけてやればいいのですが、一冊とか一巻とか全何巻なんてのが入ってきてしまうので、なかなか一様には変換出来ないところだと思います。こんな形で考えてみました。発表までの間、何度か見直してみたのですが、いくつか問題はあります。例えばOccurrence Numberは二桁なんですが99までいってしまったらどうしようとか、それからどうもLCの仕様を見るとリンク関係は一対一の対応じゃないとまずいのかなぁと、これは実は一対二の対応になってしまいますので、ここだけ見ると掟破りなのかなぁと考えられます。この他に早稲田さんがやってる$8を使うという方法も実は検討対象にはなるかなぁと考えております。今見ていただいているのは私どもの商品データなので生の商売用のデータですが、こういった形で乗せていくことができそうだなぁ、とできれば問題点も含めて今後のいろんな議論のきっかけになればいいなぁと考えております。

[入江]ありがとうございました。何かご意見があれば。

[酒井]慶應大学の酒井でございます。880の問題については実はLCでも一度ディスカッションペーパーというところで、一度880をなくそうじゃないかという議論があったんです。それが98年だと思います。ただその後の結論というのが佐藤さんも私もつかんでいません。途中ではメーリングリストでその方がいいじゃないか、もっとパワフルにシステムを展開できるという人が約一名いたところまではつかんでいるのですが、多分その結論が出なくて、このモデルA,Bそしていろんな例が出てきて、とりあえずいろんな形ができるよというところまでで終わっているんだと思います。ですから、これから私たちがしなくてはいけないのは、日本ではこういうふうに考えられる、私たちはこうしたいと提案していかないと、その他の方々に任せているだけでは国内交換フォーマットに関してもそうですけれども、我々としてはこう考えているということを出していかないと、外国にいらっしゃる方たちが我々の作った書誌を使えない状況というのは、ずっと続いてしまうと思います。そういった意味でも我々の提案は重要だと思います。

[入江]お手元にピンクの紙がいっているかと思いますが、森本さんのTRCデータをRLINに搭載したデータをどう思うのかといった講演会が12月にあります。それはアメリカにいらっしゃる日本語のカタロガーの方がどういうふうに日本語の目録を利用されているか、そこでの問題点等が説明していただけるということです。参考にしながら考えていきたいと思っています。

| 1 | 2 | 3 | TOP |