卒業研究Iの進捗状況

1997年10月14日

川合研B4 伊戸川 暁

  1. (現状に於ける)コンセプト
    公開による保存
    Networkを介して（できるだけ離れたところに） mirror/ダウンロードしてもらえば、 災害時にも強いだろう（という希望的観測）。
    自主管理
    B.Kahleのように、よそのserverの内容をarchiveしてあげるという 行き方もあるようだが、 本来自分の所の内容は自分でarchiveすべきであると考える。 但し、自分のところでarchiveしたdata/metadataを、 他所とやりとりすることは 当然否定しない。
    二面性
    内側に対しては版管理システム（のようなもの）として振る舞い、
    外側に対しては情報を発信する。
    (WWWを通じての発信を想定しているが、無論CDなどに焼いてもよい)
    そしてその中間に、蓄積したファイル及びそれを管理する部分がある。
    key technology:
    metedata、公開鍵暗号(、database技術)

  2. metadata
    1. metadataとは何ぞや
      dataに関するdata。
      e.g. 題名・作成日・著者名・ファイル形式など。
      ここにrertension schedule情報を入れて自動管理させるあたりが、 本研究の新機軸である。
    2. 世界の状況
      ここ1年ばかり進展がめざましく、URCやらRDFやら、各種の提案が なされているが、まだ標準と呼べるものは確立していないようだし、 私の研究目的に特化したようなmetadataシステムは、 見た限りでは提案さえなかった（ようだ）。
      #∴今なら一介の学部生でも好き勝手が言える。
    3. 本システムに於けるmetadata
      SGML式の表記(外部表現)
      のちに標準が固まった時に移行しやすいだろう
      入れ子構造
      階層構造を表現
      revision管理
      文書の命名法はserial numberとする
      永続性を重視→URNを意識
      文書間構造のfilesystemからの分離 →文書の重要度に応じて保存先を変えることができる(重要)
      本体とmetadataの物理的な位置関係
      一体型／分離型
      revision情報の管理
      file/directory名が変わってもたどれるようにしたい
      (僕自身、名前をコロコロと変えるので)
      #RCSとの連動を図れないか？
      記憶媒体情報
      retension scheduleの記述
      dir.単位/file単位
      保存年限
      作成時から一定の時間を経過した後
      一定の時間、アクセスが無いとき
      等々のvariation
      機密扱いか否か(see 3)
      どれを残すか？ 最後のバージョンだけ？ 最初と最後？ 全部？
      etc.
      ※具体例は別紙を参照のこと。

  3. 公開鍵暗号
    1. 真正性の保証
      (少なくとも)公開する情報にはsignatureをつける。
    2. 機密保持
      暗号化した文書をよそのserverに置かせてもらう。 とりあえず実装にはpgpを使う予定。
    3. 問題点
      鍵の引き継ぎをどうするか？

  4. database技術
    metadataを生で扱うといかにも効率が悪そうなので、 この辺りの勉強がもう少し必要そう。
    #でも、本質的な部分ではない（と思っている）ので、 あまり勉強していない…。いいツールをご存知の方、御教示下さい。

  5. 実装（の予定）
      基本的に、shellから専用のcommand群をしようするというinterfaceで済ます予定。
    1. retension scheduleの設定
      設定ファイルによる設定
      directory（或いはfile）ごとに、retension scheduleを記しておく
      コマンドによる対話的な設定
      #システム施行前に現存する文書群を見て、 retension scheduleをsuggestしてくれる機能があると便利そうだが…。
    2. record manager
      metadataに記されたretension scheduleに基づいて、 文書/metadataの移動や処分を行う。
      基本的に自動とするが、手動の余地も当然残す。
      定期的にworking dir.を見て回り、変更のあったもののみを収集 (或いは複数作る)。
      各文書/dir.(/metadata?)はserial numberで識別
      #retension scheduleによっては(e.g. logfile)、 currentのを消してあげる
      廃棄の日を過ぎたものを消す
      「archives行き」になったものに公開のための処置を施す
      #metadataのみの変更をどうするか？
      #「current且つarchivesの一部として公開」の扱い？
    3. 専用command群
      metadataの書き換えを伴うcpやmvなど。
    4. その他
      索引づけ、よそとの情報交換、Web serverとの連絡など
      差し当たりWeb周りは簡単なcgi-scriptで済ませるが、 将来的には専用のserverも欲しい

  6. 今後の予定
    実は、殆んど実装が進んでないのです。
    10月中
    大急ぎで実装
    11月
    それを少し動かして論文につなげる
    少なくとも卒研関係のデータは本システムで管理しよう

  7. 名前募集
    本システムの、気の利いた名前を募集します。
    但し、先に自分でいいのを思いついてしまったなどの理由により、 必ずしも採用されるとは限りませんので、あしからず。

itogawa@graco.c.u-tokyo.ac.jp