1996.08.02 作成
1997.10.31 更新
以下のようなクライアントを作成することは禁止する。各種クライアント
が具備すべき要件については本ガイドラインの「特定クライアントの留意点」
を参照のこと。
NACSIS-CATは、オンライン・ネットワーク方式により全国規模の総合目録デー
タベース（図書・雑誌）を形成する図書館業務用システムである。入力作業を効率的に行な
うため、JAPAN/MARCやUS/MARCなどの標準的書誌データベースを参照するとと
もに、共同分担方式により目録作成作業の重複を防ぎ、図書館目録業務の省力
化と迅速化を図っている。
オンラインで総合目録データベースに登録したデータは、同時に図書館蔵書
目録データベースに取り込み、OPAC（利用者用オンライン目録）を構築するこ
とができる。オンライン以外では、定期版／個別版磁気テープサービスや個別
版CD-ROMサービスにより、各図書館で入力したデータを利用することができる。
また総合目録データベースは、NACSIS-IRや学術雑誌総合目録でも利用可能
である。これらは主に研究者や図書館員向けのサービスであるが、WWW上のサー
ビス「Webcat」では利用者を特定することなく、総合目録データベースを検索
することができる。
総合目録データベースを形成することで、資料の所在情報が蓄積され、これ
は図書館間で相互貸借業務を行なうシステムであるNACSIS-ILLで利用される。
NACSIS-ILLを効率的に運用するためには、参照するデータベースである
NACSIS-CATの総合目録データベースのデータには正確さが求められる。
データは各図書館が責任を持って入力しているもので、品質管理のかなりの
部分は各図書館側が荷なっている。新目録システムがクライアント・サーバ方
式になることで、図書館側のシステムと融合させた自由な形式のクライアント
が作成可能となるが、これまで現行のシステムで行なってきた、
データのチェックのかなりの部分については、新システムでは各クライアント
で行なうこととなる。データの品質を最低限守るための留意点については、本
ガイドラインのIIIに定める。
総合目録の書誌レコードを納めるファイルである。レコードの内容は、目録対 象資料のタイトル、著者名、出版者等の書誌情報である。このファイルのレコードは 各図書館の共有レコードとして登録され、同一の書誌に対する重複登録は許さ れない。登録、修正は各図書館で行なえるが、レコードの削除はできない（こ の作業はセンターで行なう）。総合目録書誌ファイルには以下の３種類がある。
レコードの検索はSEARCH,SCANメソッドにて行う。
SEARCHメソッドによる検索の結果はサーバのframeに保存される。
RETRIEVE,SCANメソッドはこのframeを対象に行われるので、
クライアントはframe名を管理する必要がある。
また、使用しないframeを維持し続けることは、サーバの負荷になるので、
使用しないframeについてはRELEASEFRAMEメソッドで開放することが望ましい。
responseにてレコードを受け取る場合は、
不用意にデータ量の多いresponseにならないように指定すること。
レコード情報の取得は、
| INSERT対象ファイル | 参照ファイル | SOURCEに記入するコード |
|---|---|---|
| BOOK | GPOMARC | GPO |
| JPMARC | JP | |
| TRCMARC | TRC | |
| UKMARC | UK | |
| USMARC | LC | |
| USMARCX | LCX | |
| その他(＊)またはなし | ORG | |
| SERIAL | JPMARCS | JP |
| USMARCS | LC | |
| その他(＊)またはなし | ORG |
| INSERT対象ファイル | 参照ファイル | SOURCEに記入するコード |
|---|---|---|
| NAME | JPMARCA | JP |
| USMARCA | LC | |
| その他またはなし | ORG | |
| TITLE | USMARCT | LC |
| その他またはなし | ORG |
リンクの形成はリンク元のレコードにリンク先のレコードのIDを記入することで
行う。
リンク元のレコードをINSERT,UPDATEする前にSEARCH,SCANでリンク先のレコードを
検索し、リンク先のレコードのIDを取得する必要がある。
また、相互参照になる"NAME<-->NAME","TITLE<-->TITLE"の参照の場合はリンク先の
レコードをリンク元とし、リンク元をリンク先として、リンクを形成する必要がある
ので、注意が必要である。
以下にリンク形成の幾つかのパタンについて、手順例を示す。
形成されたリンクを参照するためには、各々の参照対象ファイルの特定のフィー ルドを検索し、レコードを取得することで行なう。以下に参照の種類別に検索 対象フィールドの一覧をあげる。
| リンク参照の種類 | 検索元フィールド | 検索対象フィールド |
|---|---|---|
| BHOLD-->BOOK | BHOLD(BID) | BOOK(ID) |
| BHOLD-->RECON | BHOLD(BID) | RECON(ID) |
| BHOLD-->MEMBER | BHOLD(FANO) | MEMBER(ID) |
| SHOLD-->SERIAL | SHOLD(BID) | SERIAL(ID) |
| SHOLD-->MEMBER | SHOLD(FANO) | MEMBER(ID) |
| BOOK-->BOOK | BOOK(ID) | BOOK(PID) |
| BOOK-->BOOK | BOOK(PID) | BOOK(ID) |
| BOOK-->RECON | BOOK(ID) | RECON(PID) |
| BOOK-->RECON | BOOK(PID) | RECON(ID) |
| BOOK-->NAME | BOOK(AID) | NAME(ID) |
| BOOK-->TITLE | BOOL(UTID) | TITLE(ID) |
| BOOK-->BHOLD | BOOK(ID) | BHOLD(BID |
| BOOK-->MEMBER | BOOK(CRTFA,RNWFA) | MEMBER(ID) |
| RECON-->BOOK | RECON(ID) | BOOK(PID) |
| RECON-->BOOK | RECON(PID) | BOOK(ID) |
| RECON-->RECON | RECON(ID) | RECON(PID) |
| RECON-->RECON | RECON(PID) | RECON(ID) |
| RECON-->NAME | RECON(AID) | NAME(ID) |
| RECON-->TITLE | RECON(UTID) | TITLE(ID) |
| RECON-->BHOLD | RECON(ID) | BHOLD(BID) |
| SERIAL-->NAME | SERIAL(AID) | NAME(ID) |
| SERIAL-->MEMBER | SERIAL(CRTFA,RNWFA) | MEMBER(ID) |
| SERIAL-->SHOLD | SERIAL(ID) | SHOLD(BID) |
| SERIAL-->CHANGE | SERIAL(FID) | CHANGE(FID) |
| NAME<-->NAME | NAME(SAFID) | NAME(ID) |
| NAME<-->BOOK | NAME(ID) | BOOK(AID) |
| NAME<-->SERIAL | NAME(ID) | SERIAL(AID) |
| NAME<-->MEMBER | NAME(CRTFA,RNWFA) | MEMBER(ID) |
| TITLE<-->TITLE | TITLE(SAFID) | TITLE(ID) |
| TITLE<-->BOOK | TITLE(ID) | BOOK(UTID) |
| TITLE<-->MEMBER | TITLE(CRTFA,RNWFA) | MEMBER(ID) |
SEARCH,SCAN,RETRIEVE,INSERT,UPDATE,INDEXLIST
重複レコードの可能性のあるレコードの場合、サーバは警告をresponseとして
返すので、利用者に確認を促すことが望ましい。
BOOKにはDELETEメソッドは認められていない。従って、各図書館側では不要に なった書誌レコードについてはUPDATEメソッドで「削除予定レコード」に修正 する作業を行なう。実際のレコード削除は定期的にセンターで行なう。
SEARCH,RETRIEVE,SCAN,INDEXLIST,UPDATE
RECONは形式上は参照ファイルであるが、実際には目録カードから遡及入力された、特定の図 書館のデータであり、所蔵もリンクされていることから、総合目録データベー スの一部とみなしている。このレコードを利用する場合は、必ず目録対象資料 の記載にしたがった、書誌の修正を行なうことが義務づけられている。修正されたレコードは一定時間毎にBOOKに移され、RECONファイルからは削除される。BOOKに移されてからは、他のBOOKレコードと同様に扱う。逆に、RECONにはINSERTが認められていないため、一旦BOOKに移したレコードをRECONに戻すことは出来ない。
RECONの書誌に所蔵を登録する場合は、あらかじめ書誌レコードをUPDATEして おかなければならない。例え、修正すべき事項がない場合でも同様である。こ の操作をすることによって、BOOKへのレコードの移動が行なわれる。RECONファ イルにレコードが残ったままだと、重複書誌の作成を招く場合がある。
BOOK→RECONのリンク作成は可能である。まず、BOOKから親書誌リンクを張る 際、RECONファイルに該当するレコードがヒットした場合は、修正事項がなくてもRECON のレコードに対し、UPDATEを行なうことが必要となる。修正された書誌がバッ チでBOOKファイルに移されるまで、BOOK→RECON間に書誌リンクが存在するこ ととなる。また、RECONのレコードからBOOKにリンクを張る場合は、RECON のレコードのUPDATEを伴うので問題はない。
これらのことから、新規に書誌構造リンクを作成する際には、検索対象として BOOK,RECON双方のファイルを指定する必要がある。
前述したように、所蔵登録、あるいは書誌構造リンクのため、一旦Updateされ たRECONのレコードはバッチでBOOKに移される。しかし、それまでの間にいくらかのタ イムラグが存在することは避けられない。したがって、BOOKからのLookup時、 また、RECONからのLookup時に検索対象をRECONも含めておくことが必要となる。 また、新規書誌登録にともなう検索時にもRECONファイルを必ず検索し、該当する書誌がUpdate済み（BOOKへの移動待ち）でないことを確認する必要がある。 また、Update済みでない場合に、この書誌を修正して登録するか、 他の参照ファイルを利用するかは目録作成者の判断による。
SEARCH,SCAN,RETRIEVE,INSERT,UPDATE,INDEXLIST
重複レコードの可能性のあるレコードの場合、サーバは警告をresponseとして 返すので、利用者に確認を促すことが望ましい。
SERIALにはDELETEメソッドは認められていない。従って、各図書館側では不要に なった書誌レコードについてはUPDATEメソッドで「削除予定レコード」に修正 する作業を行なう。実際のレコード削除は定期的にセンターで行なう。
BHOLD,SHOLDのレコードはGETHANDLE時のIDによって指定できる
FANOが限定されているので注意が必要である。
更に指定可能なLOCがこの指定可能なFANOによって限定されるので注意が必要である。
指定可能なLOCはMEMBERファイルのLOCで確認できる。
SEARCH,SCAN,RETRIEVE,INSERT,UPDATE,INDEXLIST,DELETE
新システムではNULL値をやりとりしないため、旧システムでLOCなし(空値)で
登録していたものは、新システムではCATP上、「＠（１byte）」に置きかえてデー
タの交換をする。データベース上は空値(NULL)のままである。クライアントか
ら空値のLOCを含む所蔵レコードを送る際には、この文字に置きかえる必要が
ある。サーバから送られた「＠」については、表示の仕方等はクライアントの
判断にまかせる。空値についてこのような処理を行なうのは所蔵レコードの
「LOC」及び参加組織ファイルの「LOC」のみである。
従来のシステムと併用する場合などには注意が必要である。
指定可能なFANO,LOCでないレコードはINSERTはできない。 また、INSERT時にBID+FANO+LOCが同一のレコードが既に存在する場合は、 重複レコードとして登録できないので注意すること。
指定可能なFANOを持つレコード以外はUPDATEの対象レコードとして指定できない。 指定可能なFANO,LOCでないレコードにUPDATEはできない。 UPDATE時にBID+FANO+LOCが同一の他のレコードが既に存在する場合は 重複レコードとして登録できないので注意すること。
指定可能なFANOを持つレコード以外はDELETEの対象レコードとして指定できない。
新システムにおいては，クライアント作成に自由度を持たせており，従来のクライアントの他に機能を限定した目的別のクライアントシステムの作成も可能である。ただし，総合目録の共同分担目録の精神を具現するために，必ず１つは総合目録データベースを作成するためのクライアントを開発しなければならない。本ガイドラインでは，以下のようなクライアントを想定している。
基本となるクライアントであり，書誌・所蔵・典拠レコードを登録するクラ イアント及び雑誌所蔵レコード修正専用クライアント等が想定される。現シス テムではサーバで行っているコマンドによる画面遷移やレコード間の書誌的な 整合性のチェック等をクライアント側で行う必要があるので，特に注意するこ と。具体的なチェックの内容については、本ガインドラインの「主なオペレー ション」の項を参照のこと。
あらかじめ検索値と所蔵レコードを用意しておき，登録作業はクライアントが自動的に行うシステムを想定している。
ローカル目録検索と総合目録データベースとのシームレスな検索システム等を想定している。
また，新システムでは，現システムと比較して以下の諸点を変更することを予定している（ただし，変更の時期は未定である）。新クライアントの作成には，将来の変更をあらかじめ想定されることが望ましい。