新CATクライアントシステム作成のためのガイドライン（第2版）
第2版 1997.11.28
誤植訂正 1998.1.31
DNMARC関連追加 1998.11.26
NCR2018対応に伴う語句等修正 2024.10.31
1. はじめに
本ガイドラインは，学術情報センター（以下，「センター」という）が開発している新目録システム（以下，「新CAT」という）対応クライアントシステムを作成するために必要な基本的事項（ファイル構成，CATPによるオペレーション等）を解説する。
また，本ガイドラインは，新CATで作成する総合目録データベースの品質を保持するためにクライアントが具備すべき要件，及び，サーバシステムへのいたずらな高負荷をもたらさないためにクライアントが具備すべき要件を規定する。
各メソッドについての詳細は「Cataloging information Access ＆ Transfer Protocol (CATP/1.0)仕様書 第2版」を参照する必要がある。
本ガイドラインは，今後とも追加・修正されることがある。最新のガイドラインについては，随時公表していく予定である。
2. 新目録システムの構成
2.1 NACSIS-CATの概要
NACSIS-CATは，オンライン・ネットワーク方式により全国規模の総合目録データベース（図書・雑誌）を形成する図書館業務用システムである。入力作業を効率的に行なうため，JAPAN/MARCやUS/MARCなどの標準的書誌データベースを参照するとともに，共同分担方式により目録作成作業の重複を防ぎ，図書館目録業務の省力化と迅速化を図っている。
オンラインで総合目録データベースに登録したデータを，それと同時にオンラインで図書館蔵書目録データベースに取り込み，OPAC（利用者用オンライン目録）を構築することができる。
また総合目録データベースは，WWW上のサービス「CiNii Research」では，利用対象者を特定することなしに総合目録データベースの公開利用を実現している。
総合目録データベースを形成することで蓄積された目録所在情報は，図書館間で相互貸借業務を行なうシステムNACSIS-ILLで活用されている。 NACSIS-ILLを効率的に運用するためには，ILLで参照する総合目録データベースのデータに正確さが求められている。
総合目録データベースのデータは，各図書館が責任を持って入力しているもので，データ品質管理作業のかなりの部分は各図書館側が荷なっている。新CATがクライアント・サーバ方式になることで，図書館側のシステムと融合させた自由な形式のクライアントが作成可能となるが，これまで現行のシステム側で行なってきた，機械的なデータチェックのかなりの部分については，新システムでは各クライアントで行なうこととなる。よって，クライアントの作成に当たっては，データの品質の低下を招かぬよう，十分配慮する必要がある。
2.2 ファイルの種類
NACSIS-CATにおけるファイルは，大きく5種類に分類される。ここでは各ファイルの概要について記述する。ファイルの詳細な運用については，本ガイドラインの「4.各ファイルの運用」に記述する。
2.2.1 総合目録書誌ファイル
総合目録の書誌レコードを納めるファイルである。レコードの内容は，目録対象資料のタイトル，著者名，出版者等の書誌情報である。このファイルのレコードは各図書館の「共有」レコードとして登録され，同一の書誌に対する重複登録は許されない。登録，修正は各図書館で行えるが，レコードの削除はできない（この作業はセンターで行なう）。総合目録書誌ファイルには，以下の3種類がある。
(1) BOOK
図書の書誌レコードを収めるファイル。
(2) RECON
東京大学で所蔵する図書目録の遡及レコードを収めたファイル。
目録カードのデータを利用して一括入力したレコードであるため，現物から入力することが原則のBOOKのレコードよりも，データ品質が落ちる。よって，BOOKとは別ファイルとして運用している。
年代の古い図書の書誌作成のための参照ファイル（「2.2.4」を見よ）的な用途に利用される。しかし，東京大学の所蔵レコードがリンクしていること，現物に従った修正が行なわれると BOOKに移されるという特殊な扱いとなっている。詳細な運用については，「4.2 RECONファイルの運用」に記述する。
(3) SERIAL
雑誌（逐次刊行物）の書誌レコードを収めるファイル。
2.2.2 総合目録所蔵ファイル
総合目録の所蔵レコードを納めるファイルである。レコードの内容は，リンクしている書誌に対する各図書館での配架場所，請求記号，登録番号，所蔵巻次等の所蔵状況に関する情報である。このファイルのレコードは，各図書館の「固有」レコードとして登録され，各々の図書館のレコードに限り，登録，修正，削除は自由に行なうことができる。
所蔵レコードは，必ず書誌レコードにリンクして登録されなければならない。単独での登録は許されない。総合目録所蔵ファイルには，以下の2種類がある。
(1) BHOLD
図書の所蔵レコードを収めるファイル。
(2) SHOLD
雑誌の所蔵レコードを収めるファイル。
2.2.3 総合目録典拠ファイル
総合目録の書誌レコード中の，検索要素である標目の形を管理するためのファイルである。レコードの内容は，統一された標目形と，検索が予想される参照形等である。このファイルのレコードは各図書館の共有レコードとして登録され，同一の標目に対する重複登録は許されない。登録，修正は各図書館で行なえるが，レコードの削除はできない（この作業はセンターで行なう）。総合目録典拠ファイルには，以下の２種類がある。
(1) NAME
著者名典拠レコードを収めるファイル。
(2) TITLE
著作典拠レコードを収めるファイル。
2.2.4 参照ファイル
総合目録書誌ファイル，典拠ファイルを作成するのに参照可能なファイルである。レコードの登録，更新は行えない。また，参照して総合目録の書誌・典拠レコードを作成する場合は，規定する記述方法に則りデータに修正を施してから，総合目録書誌・典拠ファイルに登録しなくてはならない。その際，必要なリンク形成（「3.8」）を行わなくてはならない場合があるので，注意すること。
参照ファイルは総合目録レコードを作成するためのものなので，OPAC等での図書館利用者への提供や，総合目録作業やILL作業以外でのデータのダウンロードを行ってはならない。参照ファイルは目的別に4つに分類され，計12種類がある（平成10年11月現在）。
(1) 主にBOOKレコード作成に用いるもの：USMARC, JPMARC, TRCMARC, UKMARC, DNMARC, GPOMARC, USMARCX
(2) 主にSERIALレコード作成に用いるもの：USMARCS, JPMARCS
(3) 主にNAMEレコード作成に用いるもの：USMARCA, JPMARCA
(4) 主にTITLEレコード作成に用いるもの：USMARCT
2.2.5 その他のファイル
(1) CHANGE
SERIALファイルのレコードのタイトル変遷の関係を表すレコードである。登録，更新は行えない。
(2) MEMBER
参加組織情報のファイルである。自館のレコードの一部フィールドについて更新が可能。
2.3 レコード間の関係（リンク）
各ファイル間のレコードの相互参照は，リンクを形成することで行なう。リンクは総合目録データベース内部にのみ存在し，参照ファイルには存在しない。ここでは，クライアントにて形成するリンク関係について列挙する。具体的なリンクの仕組，形成方法については，本ガイドライン「3.8 リンクの形成 」を参照のこと。
2.3.1 BHOLD--> BOOK
図書所蔵から図書書誌へのリンク。
BHOLDはBOOKまたはRECONに対して必ずリンクを形成しなくてはならい。
2.3.2 BHOLD--> RECON
図書所蔵から図書書誌へのリンク。リンク対象のRECONレコードがUPDATEで更新されていることが前提となる。(RECONはUPDATEされるとBOOKに移動する。)
BHOLDはBOOKまたはRECONに対して必ずリンクを形成しなくてはならい。
2.3.3 BHOLD--> MEMBER
図書所蔵から参加組織へのリンク。
BHOLDはMEMBERに対して必ずリンクを形成しなくてはならい。
2.3.4 SHOLD--> SERIAL
雑誌所蔵から雑誌書誌へのリンク。
SHOLDはSERIALに対して必ずリンクを形成しなくてはならい。
2.3.5 SHOLD--> MEMBER
雑誌所蔵から参加組織へのリンク。
SHOLDはMEMBERに対して必ずリンクを形成しなくてはならい。
2.3.6 BOOK--> BOOK
図書書誌から図書書誌へのリンク。2階層の書誌構造（親子関係）をあらわす。3階層になってしまうため，リンク元のBOOKは他のBOOK,RECONからのリンク対象になりえない。また，リンク対象のBOOKは他のBOOK,RECONへのリンク元にはなりえない。
2.3.7 BOOK--> RECON
図書書誌から図書書誌へのリンク。2階層の書誌構造(親子関係)をあらわす。このため，リンク元のBOOKは他のBOOK,RECONからのリンク対象になりえない。また，リンク対象のRECONは他のBOOK,RECONへのリンク元にはなりえない。なお，リンク対象のRECONレコードがUPDATEで更新されていることが前提となる。 (RECONはUPDATEされるとBOOKに移動する。)
2.3.8 BOOK--> NAME
図書書誌から著者名典拠へのリンク。
2.3.9 BOOK--> TITLE
図書書誌から著作典拠へのリンク。
2.3.10 RECON--> BOOK
図書書誌から図書書誌へのリンク。2階層の書誌構造(親子関係)をあらわす。このため，リンク元のRECONは，他のBOOK,RECONからのリンク対象になりえない。また，リンク対象のBOOKは，他のBOOK,RECONへのリンク元にはなりえない。
2.3.11 RECON--> RECON
図書書誌から図書書誌へのリンク。2階層の書誌構造(親子関係)をあらわす。このため，リンク元のRECONは，他のBOOK,RECONからのリンク対象になりえない。また，リンク対象のRECONは，他のBOOK,RECONへのリンク元にはなりえない。なお，リンク対象のRECONレコードがUPDATEで更新されていることが前提となる。 (RECONはUPDATEされるとBOOKに移動する。)
2.3.12 RECON--> NAME
図書書誌から著者名典拠へのリンク。
2.3.13 RECON--> TITLE
図書書誌から著作典拠へのリンク。
2.3.14 SERIAL--> NAME
雑誌書誌から著者名典拠へのリンク。
2.3.15 NAME<--> NAME
著者名典拠の相互リンク
2.3.16 TITLE<--> TITLE
著作典拠の相互リンク
3. 主なオペレーション
CATPを使った主なオペレーションについて解説する。各オペレーションにおいて，以下の事項について問題なく機能することを前提とする。
(1) センターが規定する文字種以外の，機種固有の外字を使用しないこと。また，センターが規定する全ての文字種の表示・入力ができること。
(2) センターが規定する全てのフィールドデータの表示・入力・削除ができること。
(3) 各フィールドについてセンターが規定する長さ，個数の表示・入力ができること。
3.1利用開始（handleの取得）
システムの利用開始には，GETHANDLEメソッドを使用してhandleを取得する必要がある。
CATPはステイトレスな通信を想定している。handle取得時にユーザ認証を行い，その後のセッションには，このhandleを指定してセッションを行う。ゆえに取得したhandle名はクライアントにて管理する必要がある。
3.2 検索（frameの作成)
レコードの検索は，SEARCH,SCANメソッドにて行う。
SEARCH,SCANメソッドによる検索の結果は，サーバのframeに保存される。frameの生成・削除・呼び出しは，クライアントで管理しなければならない。
frameの実体は，サーバのメモリ上に存在する。したがって，不要のframeは直ちにRELEASEFRAMEメソッドで開放する必要がある。また，必要以上に大きなframeは，利用者に絞り込みを促し，できるだけ小さなものにすること。
responseにてレコードを受け取る場合は，不用意にデータ量の多いresponseにならないように，クライアントで制限をかけられるようにすること。
3.3 レコード情報の取得
レコード情報は，以下の方法にて取得できる。
(1) SEARCH, SCANのresponse
(2) RETRIEVE
(3) UPDATE, INSERTのresponse
edit-type=9でのレコード情報の取得はサーバの負荷が高いため，多用しないことが望ましい。 また，必要以上の数のレコード情報を取得しないようにすること。
UPDATE,INSERTのresponseでのレコード情報の取得は，主にレコードの登録，更新後の確認の為にあるので，確認をしないクライアントの場合は取得をしないようにすること。
SEARCH, SCANのresponse, RETRIEVEで取得した情報を利用してUPDATEを行う場合，edit-type=2または9（9はサーバの負荷が高いので，2が望ましい)でレコード情報を取得すること。
3.4 レコードの登録（INSERT)
レコード登録にあたっては，重複書誌レコード・重複典拠レコードを作らないように注意すること。新規に書誌レコード・典拠レコードを登録する際は，必ず総合目録データベースを検索して，目的とする書誌・典拠が総合目録データベースに登録されていないことを利用者に確認させること。
また，センターの規定するレコードの作成基準から逸脱したレコードを作らないこと。
総合目録データベースから流用入力する場合は，混乱を避けるため，参照ファイルからの流用入力とは別のコマンドあるいは操作を用意することが望ましい。
3.5 レコードの修正（UPDATE)
修正の結果，重複書誌レコード・重複典拠レコードを作らないように注意すること。
また，センターの規定する作成基準から逸脱したレコードを作らないこと。
edit-type=2または9（9はサーバの負荷が高いので，2が望ましい）でレコード情報を取得して，その情報を基にレコードの修正をすること。この際，レコード上にあるフィールドをクライアントが扱えないことが原因で，削除しないように注意すること。但し，BHOLD，SHOLDは各参加機関が責任を持って管理するものなので，この限りではない。
3.6 レコードの削除（DELETE)
レコードの削除は，総合目録所蔵ファイルのレコードにしかできない。また，総合目録書誌・典拠ファイルのレコードは「削除予定レコード」に修正することにより，センターが削除するので注意すること。
3.7 流用入力（参照ファイルの利用）
参照ファイルを参照してレコードを登録する場合は，参 照ファイルのレコード情報を取得し，規則に則ってデータを登録すること。
3.8 リンクの形成
リンクの形成は，リンク元のレコードにリンク先のレコードのIDを記入することで行う。
リンク元のレコードをINSERT,UPDATEする前にSEARCH,SCANでリンク先のレコードを検索し，リンク先のレコードのIDを取得する必要がある。
親書誌がある場合，子書誌の登録の前に親書誌のリンク付けが終わっていることを確認すること。
3階層以上の書誌を作成しないように，親書誌リンクをする際には，当該レコードに子書誌がリンクされていないことを確認すること。
著者名典拠，著作典拠へのリンク処理を行う機能を具備すること。
また，相互参照になる"NAME<--> NAME","TITLE<--> TITLE"の参照の場合はリンク先のレコードをリンク元とし，リンク元をリンク先として，リンクを形成する必要があるので，注意が必要である。
以下にリンク形成の幾つかのパタンについて，手順例を示す。
3.8.1 BHOLD--> BOOK, BHOLD--> MEMBER(SHOLD--> SERIAL, SHOLD--> MEMBER)
BOOKへのリンクはBIDに，MEMBERへのリンクはFANOに記入する。
所蔵レコードのINSERT時は，リンクしたいBOOKのレコードをSEARCH,SCAN等で検索しておき，IDを取得しておく。MEMBERについてはあらかじめリンク可能なレコードはユーザIDによって決まっているので，あらかじめクライアントで値を保持しておいて，その値を記入すればよい。
(1) 書誌レコードのID取得
(2) レコードの存在の確認
登録しようとするレコードとFANO+BID+LOCが同一のものがあると，INSERTできないので，レコードの存在を確認する。この手順は取敢ずINSERTしてみて，エラーならば，INSERTではなく，UPDATE にするようにしてもよい。
(3) リンク先IDを記入してINSERT
UPDATEの際，特にリンク先を変更する必要がない場合は，取得したリンク先をそのまま使用してリンクを形成すればよい。
3.8.2 BOOK--> BOOK
BOOKからBOOKへのリンクの形成は，図書レコードの書誌構造を表すものなので，書誌構造的に矛盾を生じるようなリンクの形成を行ってはならない。
リンク先レコードにPTBLグループが存在する場合は，3階層の書誌構造リンクになってしまうのでリンクを形成してはならない。
またリンク元が既に他のレコードのリンク先になっている場合も，同様の理由でリンクを形成してはならない。リンク元が既に他のレコードのリンク先になっていないかどうかは，リンク元のIDでBOOK,RECONを検索対象ファイルとして検索を行うことで確認可能である。
リンク先のレコードを検索する場合は，_TITLE_という検索仮想フィールドがあるので，これを使用すると便利である。
3.8.3 BOOK--> NAME(BOOK--> TITLE, SERIAL--> NAME)
書誌レコードと典拠レコードとのリンクを形成することにより，典拠レコードの元に書誌レコードの集中化を行う。
NAMEレコードのリンク先のレコードを検索する場合は，_AUTH_という検索仮想フィールドがあるので，これを使用すると便利である。
TITLEレコードのリンク先のレコードを検索する場合は，_UTHDNG_という検索仮想フィールドがあるので，これを使用すると便利である。
3.8.4 NAME<--> NAME(TITLE<--> TITLE)
このリンク形成は相互リンクなので，どちらのレコードからもリンクを形成しなくてはならない。
INSERTの際は，INSERTすべきレコードのIDはINSERTの終了まで不明なので，INSERT終了後にresponseからIDを取得し，リンク先のレコードをUPDATEする方法が効率的である。
NAMEレコードのリンク先のレコードを検索する場合は，_AUTH_という検索仮想フィールドがあるので，これを使用すると便利である。
TITLEレコードのリンク先のレコードを検索する場合は，_UTHDNG_という検索仮想フィールドがあるので，これを使用すると便利である。
3.9 リンクの参照
形成されたリンクの参照は，各々の参照対象ファイルの特定のフィールドを検索し，レコードを取得することで行なう。以下に，参照の種類別に検索対象フィールドの一覧をあげる。
|
リンク参照の種類 |
検索元フィールド |
検索対象フィールド |
|
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 --> 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) |
3.10 終了（handleの解放)
利用を終了する場合，handleの開放を行わなくてはならない。 handleの開放はRELEASEHANDLEメソッドで行う。handleは一定期間使用されなかった場合，handleの使用が終了したものと判断され，自動的にhandleは開放される。が，いたずらな高負荷を招くので，handleを使用しないことがあらかじめ分かっている場合は，開放すること。
4. 各ファイルの運用
4.1 BOOKファイルの運用
4.1.1 可能なメソッド
SEARCH, SCAN, RETRIEVE, INSERT, UPDATE, INDEXLIST
4.1.2 INSERT, UPDATE時の重複レコード警告について
重複レコードの可能性のあるレコードの場合，サーバは警告をresponseとして返すので，利用者に確認を促すことが望ましい。
4.1.3 INSERT時の注意
書誌レコードを登録する際は，必ずユーザに検索をさせて，重複レコードが存在しないことを確認させなくてはならない。この作業を行わないクライアントは，書誌レコードを登録してはならない。
4.1.4 レコードの削除
BOOKにはDELETEメソッドは認められていない。従って，各図書館側では不要になった書誌レコードについては，UPDATEメソッドで「削除予定レコード」に修正する作業を行なう。実際のレコード削除は，定期的にセンターで行なう。
4.1.5 SOURCEについて
INSERT時，必須項目のSOURCEには以下の様にデータを記入する。
|
参照ファイル |
SOURCEに記入するコード |
|
DNMARC |
DN |
|
GPOMARC |
GPO |
|
JPMARC |
JP |
|
TRCMARC |
TRC |
|
UKMARC |
UK |
|
USMARC |
LC |
|
USMARCX |
LCX |
|
その他(＊)またはなし |
ORG |
＊総合目録書誌ファイル(BOOK,SERIAL)のデータをコピーして利用する場合等。
将来，新たな参照ファイルが導入された場合には，新しいコードも同時に設ける予定。
4.1.6 PUBFについて
出版の役割表示で制作に関わる場合，旧システムでは出版事項全体を( )で括っていたが，新システムではPUBFに"m"を記入する。PUBFの"m"を旧システムで表示すると，( )で括られて表示される。
NCR2018対応後は、PUBFに、"d"、"p"、"c"が追加された。
4.2 RECONファイルの運用
4.2.1 可能なメソッド
SEARCH, RETRIEVE, SCAN, INDEXLIST, UPDATE
4.2.2 BOOKとの関係
RECONは形式的には参照ファイルであるが，実際には目録カードから遡及入力された，特定の図書館のデータであり，所蔵もリンクされていることから，総合目録データベースの一部とみなしている。このレコードを利用する場合は，必ず目録対象資料の記載に従った，書誌の修正を行なうことが義務づけられている。修正されたレコードは一定時間毎にBOOKに移され，RECONファイルからは削除される。BOOKに移されてからは，他のBOOKレコードと同様に扱う。逆に，RECONにはINSERTが認められていないため，一旦BOOKに移したレコードをRECONに戻すことは出来ない。
4.2.3 所蔵登録時の注意
RECONの書誌に所蔵を登録する場合は，あらかじめ書誌レコードをUPDATEしておかなければならない。例え，修正すべき事項がない場合でも同様である。この操作をすることによって，BOOKへのレコードの移動が行なわれる。RECONファイルにレコードが残ったままだと，重複書誌の作成を招く場合がある。
4.2.4 書誌構造リンク作成時の注意
BOOK--> RECONのリンク作成は可能である。まず，BOOKから親書誌リンクを張る際，RECONファイルに該当するレコードがヒットした場合は，修正事項がなくてもRECONのレコードに対しUPDATEを行なう必要がある。修正された書誌がバッチでBOOKファイルに移されるまで，BOOK--> RECON間に書誌リンクが存在することとなる。また，RECONのレコードからBOOKにリンクを張る場合は，RECON のレコードのUPDATEを伴うので問題はない。
これらのことから，新規に書誌構造リンクを作成する際には，検索対象としてBOOK,RECON双方のファイルを指定する必要がある。但し，BOOKとRECONでは，BOOKの方の優先度を高くする必要がある。
4.2.5 書誌参照時の注意
前述したように，所蔵登録，あるいは書誌構造リンクのため，一旦UPDATEされたRECONのレコードはバッチでBOOKに移される。しかし，それまでの間にいくらかのタイムラグが存在することは避けられない。したがって，BOOKからのリンク参照時，また，RECONからのリンク参照時に検索対象をRECONも含めておくことが必要となる。また，新規書誌登録にともなう検索時にもRECONファイルを必ず検索し，該当する書誌がUPDATE済み（BOOKへの移動待ち）でないことを確認する必要がある。また，UPDATE済みでない場合に，この書誌を修正して登録するか，他の参照ファイルを利用するかは目録作成者の判断による。
4.2.6 表示上の注意
RECONは総合目録ではあるが，その性格上，BOOKと同時に表示する場合，明確に区別するようにすることが望ましい。（表示順や色などで区別する。）
4.3 SERIALファイルの運用
4.3.1 可能なメソッド
SEARCH, SCAN, RETRIEVE, INSERT, UPDATE, INDEXLIST
4.3.2 INSERT, UPDATE時の重複レコード警告について
重複レコードの可能性のあるレコードの場合，サーバは警告をresponseとして返すので，利用者に確認を促すことが望ましい。
4.3.3 INSERT時の注意
書誌レコードを登録する際は，必ずユーザに検索をさせて，重複レコードが存在しないことを確認しなくてはならない。この作業を行わないクライアントは，書誌レコードを登録することはできない。
4.3.4 レコードの削除
SERIALには，DELETEメソッドは認められていない。従って，各図書館側では不要になった書誌レコードについては，UPDATEメソッドで「削除予定レコード」に修正する作業を行なう。実際のレコード削除は，定期的にセンターで行なう。
4.3.5 SOURCEについて
INSERT時に必須項目のSOURCEには，以下の様にデータを記入する。
|
参照ファイル |
SOURCEに記入するコード |
|
JPMARCS |
JP |
|
USMARCS |
LC |
|
その他(＊)またはなし |
ORG |
＊総合目録書誌ファイル(BOOK,SERIAL)のデータをコピーして利用する場合等。将来，新たな参照ファイルが導入された場合には，新しいコードも同時に設ける予定。
4.3.6 PUBFについて
出版の役割表示で制作に関わる場合，旧システムでは出版事項全体を( )で括っていたが，新システムではPUBFに"m"を記入する。PUBFの"m"を旧システムで表示すると，( )で括られて表示される。
NCR2018対応後は、PUBFに、"d"、"p"、"c"が追加された。
4.4 BHOLD, SHOLDファイルの運用
BHOLD,SHOLDのレコードは，GETHANDLE時の利用者IDによって，指定できる FANOが限定されているので注意が必要である。
更に指定可能なLOCがこの指定可能なFANOによって限定されるので，注意が必要である。指定可能なLOCはMEMBERファイルのLOCで確認できる。
4.4.1 可能なメソッド
SEARCH, SCAN, RETRIEVE, INSERT, UPDATE, INDEXLIST, DELETE
4.4.2 LOCについての注意
新システムではNULL値をやりとりしない。旧システムでLOCなし(空値)で登録していたものは，新システムではCATP上「@（１byte）」に置きかえてデータの交換をする。データベース上は，空値(NULL)のままである。クライアントから空値のLOCを含む所蔵レコードを送る際には，この文字に置きかえる必要がある。サーバから送られた「@」については，表示の仕方等はクライアントの判断にまかせる。空値についてこのような処理を行なうのは，所蔵レコードの「LOC」及び参加組織ファイルの「LOC」のみである。
旧システムと併用する場合などには注意が必要である。
4.4.3 INSERT時の注意
指定可能なFANO,LOCでないレコードは，INSERTはできない。また，INSERT時にBID + FANO + LOCが同一のレコードが既に存在する場合は，重複レコードとして登録できないので注意すること。
4.4.4 UPDATE時の注意
指定可能なFANOを持つレコード以外は，UPDATEの対象レコードとして指定できない。指定可能なFANO,LOCでないレコードにUPDATEはできない。 UPDATE時にBID + FANO + LOCが同一の他のレコードが既に存在する場合は，重複レコードとして登録できないので注意すること。
4.4.5 DELETE時の注意
指定可能なFANOを持つレコード以外は，DELETEの対象レコードとして指定できない。
4.5 NAME,TITLEファイルの運用
4.5.1 可能なメソッド
SEARCH, SCAN, RETRIEVE, INSERT, UPDATE, INDEXLIST
4.5.2 INSERT, UPDATE時の注意
標目形の同じレコードが他に存在する場合，重複レコードとして登録できないので注意すること。
4.5.3 レコードの削除
NAME, TITLEには，DELETEメソッドは認められていない。従って，各図書館側では不要になった典拠レコードについては，UPDATEメソッドで「削除予定レコード」に修正する作業を行なう。実際のレコード削除は定期的にセンターで行なう。
4.5.4 SOURCEについて
INSERT時に必須項目のSOURCEには，以下の様にデータを記入する。
NAME
|
参照ファイル |
SOURCEに記入するコード |
|
JPMARCA |
JP |
|
USMARCA |
LC |
|
その他またはなし |
ORG |
TITLE
|
参照ファイル |
SOURCEに記入するコード |
|
USMARCT |
LC |
|
その他またはなし |
ORG |
4.6 CHANGEファイルの運用
CHANGEファイルのレコードは，雑誌の変遷情報を表すものである。新システムにおいては，変遷マップファイルを廃止した。変遷マップを表示するクライアントはCHANGE，及びSERIALファイルから変遷マップを作成すること。
CHANGEのレコードの登録・修正はセンターにて行うので，クライアントでは登録・修正はできない。
4.7 MEMBERファイルの運用
主に，使用可能なLOCの確認に利用する。新規登録はできず，更新については一部フィールドについてのみ可能である。
4.7.1 LOCについて
旧システムで空値の配置コードが使える場合，「@」で表現されているので注意すること。
5. 特定クライアントの留意点
新システムにおいては，クライアント作成に自由度を持たせており，従来のクライアントの他に機能を限定した目的別のクライアントシステムの作成も可能である。ただし，総合目録の共同分担目録の精神を具現するために，必ず１つは総合目録データベースを作成するためのクライアントを開発しなければならない。本ガイドラインでは，以下のようなクライアントを想定している。
(1) 総合目録データベース作成クライアント
(2) 所蔵自動登録クライアント
(3) 検索専用クライアント
また，以下のようなクライアントを作成することは禁止する。
(1) ダウンロード機能のみを持つクライアント
(2) 検索時に参照ファイルのみを対象とするクライアント
(3) 品質を維持する機能を欠いているクライアント
5.1 総合目録データベース作成クライアントが具備すべき要件
基本となるクライアントであり，書誌・所蔵・典拠レコードを登録するクライアント及び雑誌所蔵レコード修正専用クライアント等が想定される。旧システムではサーバで行っているコマンドによる画面遷移やレコード間の書誌的な整合性のチェック等を，クライアント側で行う必要があるので，特に注意すること。具体的なチェックの内容については，本ガインドラインの「3.主なオペレーション」の項を参照のこと。
5.2 所蔵自動登録クライアント
あらかじめ検索値と所蔵レコードを用意しておき，登録作業はクライアントが自動的に行うシステムを想定している。
5.2.1 書誌の同定
所蔵を登録する際は，必ず総合目録データベースを検索し，ヒット件数が１件であることを確認すること。
ヒット件数が複数の場合は，所蔵を登録してはならない。必ず，利用者に判断させること。
5.2.2 処理間隔と自動運転
自動登録は，人間の操作を想定して作成したサーバにとって，負荷の大きな処理である。したがって，各処理のサーバへの依頼間隔及び自動登録の１回当たりの総件数については，パラメータで変更することができるようにすること。
また，自動登録の負荷が大きい場合は，自動登録クライアントの利用時間を制限することを予定している。したがって，自動登録の開始はタイマー等で制御できるようにしておくことが望ましい。
5.2.3 書誌・典拠の自動登録の禁止
いかなることがあっても，書誌・典拠レコードの自動登録は認めない。
5.3 検索専用クライアント
ローカル目録検索と総合目録データベースとのシームレスな検索システム等を想定している。
5.3.1 簡略表示
ヒット件数が大きいときは，件数だけ表示する，あるいは一部だけ表示するなどして，不用意に大量データを回線上に流さないこと。
5.3.2 ローカル目録検索と併用
ローカルにヒットした場合は，自動的に総合目録データベースを検索しないようにすることが望ましい。
参照ファイルは，総合目録データベース作成を目的として使用するために導入しており，図書館利用者等へ公開した検索での使用は契約違反となるので，検索専用システムでは参照ファイルを検索対象としてはならない。
6. 総合目録データベースの将来の変更予定及びその他の留意点
6.1 総合目録データベースの将来の変更予定
また，新システムでは，以下の諸点を変更することを予定している（ただし，変更の時期は未定である）。新クライアントの作成には，将来の変更をあらかじめ想定されることが望ましい。
(1) UCSコードの採用による多言語対応
(2) ドイツマーク等（雑誌）の参照ファイルの追加
6.2 CATPの下位プロトコルについて
当面CATPは，HTTPプロトコルにおけるPOSTメソッドのオブジェクトボディ上に実装する。ただし，将来変更することもありえるので，あらかじめ想定しておくこと。
6.3 障害に対する留意点
障害への対応を図る上で，以下の機能を具備することが望ましい。
6.3.1 通信トレース機能
HTTPレベルまたはCATPレベルでの通信履歴を保存することができる機能を用意することが望ましい。
7. このガイドラインの入手法
以下の方法で，本ガイドラインの最新版を提供する予定である。
7.1 ホームページ
https://catill.bitbucket.io/guideline/guideline-cat.html ※2024.10.31修正
7.2 その他の入手法
以下に連絡すること。その他の入手法について相談に応じる。
国立情報学研究所 学術基盤推進部 学術コンテンツ課 NACSIS-CAT担当
TEL: 03-4212-2310 FAX: 03-4212-2375
E-MAIL: catadm@nii.ac.jp