要約

  • 1992年7月のRFC 1357は、計算機科学の技術報告書について、書誌記録を電子メールで送る形式を提案した。書式の版、発行機関と報告書のID、記録の作成日、同じIDを繰り返す終端が必須で、題名、著者、要約、入手方法は任意だった。
  • 訂正や撤回は、同じIDを持つ完全な記録を新しい改訂番号で送り直す。本文の入手方法はFTP、郵送、支払いなどを文章で書けたが、ファイルを自動取得する命令の形式は定義されていなかった。

郵送していたのは、まず知らせだった

当時、研究機関は新しい技術報告書を知らせるため、書誌事項を印刷して郵送していた。RFC 1357の冒頭は、その費用と遅さを問題にする。受け取る側にとっても紙の一覧は扱いにくい。後から検索したいなら、結局コンピューターへ入力し直す必要がある。Danny Cohenが編集した提案は、知らせを最初から機械で読める普通のテキストにした。

書式の野心は控えめだった。作成も処理も、手作業でも自動化でもよい。送信先がどんな目録を運営するかは指定しない。各項目を英字のタグと二つのコロンで始め、行を79文字以内に収める。専用ソフトを持たない担当者もテキストエディターで書ける。図書館の運用を一つにそろえるより、別々の図書館へ同じ形の通知を届けることを優先した。

必須項目は四つある。冒頭のBIB-VERSIONは書式の版、二番目のIDは発行機関の記号とその機関が付けた報告書番号、三番目のENTRYは記録を作った日付、末尾のENDは冒頭のIDの再掲だ。機関記号と番号の間には//を置く。人間には題名の方が便利でも、更新を処理する機械には先に同一性が要る。そのため題名も著者も任意項目に置かれた。

発行機関は何を一つの「出版物」と数えるかを決め、自分の番号を振る。研究者が書いた題名が変わっても、書誌記録を置き換える相手は番号から分かる。この順序には代償がある。形式上は完全でも、題名や要約のない通知は読む側にとって貧弱だ。行政上の確かさと、内容を見つけやすいことは同じではない。

撤回の知らせも、全部書き直す

RFC 1357では訂正を差分だけで送らない。改訂番号を上げ、現在有効な内容をすべて書いた記録を送る。受信側は古い一件を新しい一件へ置き換えられる。何通ものメールをつなぎ合わせて「いまの正解」を作る手間を、送信側が全件再送することで減らした。RFCに載る例は約1750文字。短い書誌通知なら、繰り返し送っても扱える量だった。

撤回も同じ規則で行う。文書中の例ではIDは残し、ENTRYの日付と改訂番号を新しくし、題名を空にする。以前の入手方法も新しい記録から消える。収蔵目録に残るのは「その番号の報告書について、後の告知が来た」という管理上の手掛かりだ。題名を消す場面ほど、番号の役割は大きい。

番号の前半、発行機関記号にも衝突の危険があった。別々の研究室が同じ記号を使えば、各室が独自に付けた番号が混ざる。Cohenは記号と機関名をメールで調整する役を引き受けた。IANAでの登録についても協議中だと書かれている。RFCが示すのは調整の提案と協議の段階である。試験用の機関記号や実験版の書誌形式を、受信側の恒久的なデータベースへ入れないという扱いも定めた。

手に入るのは、まず入手方法

RETRIEVAL欄には決まったコマンドがない。RFCの例は、カラー画像つきの全文なら返信用封筒を郵送し、ASCII版なら匿名FTPで取得するよう案内する。ほかに代金を送る方法や担当者へメールする方法も書ける。ファイルの自動取得に必要な情報形式は、将来定めるべき課題として残された。目録を電子化しても、報告書の運び方は一つではなかった。

権利も二段階だった。書誌記録の配布に制限を置かず、報告書本体の配布制限は別の仕組みで守る。受信箱に通知が入った時点で分かるのは、発行側がその報告書を告知したことだ。本文の所在、入手条件、実際に受け取れたかは後続の確認にかかる。

RFC 1357の小さな逆説は、題名のない報告書を電子メールが整然と運べたことにある。厳密には運んだのは報告書ではなく、その機関が付けた番号と説明の最新版だった。図書館は早く知らせを受け取れるようになった。同時に、どの版を信じ、どの経路で本を取り寄せるかという仕事も受け取った。

出典