ガイドライン考
− 電子文書のガイドラインを考える、あるいは埋文CALS −

報告書電子化のガイドラインを再検討する(since 01.11.10)。なお技術的補足説明が必要な話が多いが、いずれ拡充することとしたい。
※電子化に関連した問題はmarginBlogで論ずることも多いので、そちらもどうぞ。

データ仕様[03.6.26…03.9.17修正]

挿図データ仕様

写真データ仕様

HTML中心の報告書電子化[03.5.18]

 編集段階からHTML化を中心に据えると、HTML版報告書の作成は容易なものとなる。そのコストは、ほぼ在来型の紙印刷版編集コスト(DTPコスト)と同等とみなせる。

 テキスト部分についてのデジタル化は容易だが、問題は図版の扱いである。現在の原則としては、133dpi(ppi)のグレースケール(アンチエイリアス)をメインにしている。仮に通常のA4図版の全頁サイズを16.4×24cmだとすると、133dpiで、858×1256ピクセルになる。全頁サイズの図版は通常のディスプレイでは一度に表示できないので、ちょっとしたJavaScriptの仕掛けで縮小表示(とりあえず50%表示)も出来るようにしておく。元々サイズが小さい図版なら、その必要はないかもしれない。

 通常の写真図版については、768×512ピクセル(約40万画素相当)を基準にする。写真と挿図については、全てサムネイル画面も用意する。

 以上のような事で、通常の報告書HTML版が、約150KB/頁で作成できる(頁数の基準は後述)。もちろん、容量は圧縮率によるから、オンラインを念頭におけばもう少し節約してもよい。

 ただ、以上のままだと印刷の欲求に上手く答えられない。Webページの印刷は可能だけど、色々と問題点がある。そこで図版を600dpi2値にした通常レイアウトのDTPを行い(但し、レイアウトには凝らない)、PDF版も作成する。PDFの容量は概ね50KB/頁になる(写真頁含んだトータル)。なお、HTML版で述べた頁数は、PDF版の頁数を基準にしている。

 HTML版とPDF版合わせて、約200KB/頁ということになる(当然ながら容量は一例)。100頁級で、20MB。1000頁級で200MB、3000頁級で600MBということになる。これを、各調査機関の公式Webサイトで公開して、それぞれ電子図書館化すれば良いわけである。

デジタルデータ長期保存の問題は、別項「超長期保存のための戦略」で論じてある。[03.7.18]


▼以下は2001年度以前の旧稿であるが、当面はこのままとする。

電子整理と電子資料

 調査の事業が終了した時、報告書として求められているのは、無論、考古学的報告書であり、その限りにおいては前項のような電子化が可能であり、実例もある。しかし整理作業や調査の事業としての成果の全てではない。要するに、報告書作成の前資料が膨大にある。スライドは良い例で、普通はスライドフォルダに整理される。図も、原図、鉛筆トレース図、版下用の図等があったりする。また、写真や図の整理台帳もある。こうした諸々の資料を、よく整理されたものとして保存するため、電子化が有効である。いわば、電子資料である。そのための過程が電子整理といえる。保存されるデータは、電子アーカイブとなる。電子整理と電子資料は、アーカイブとして公認されることで、初めて生きてくる。

 写真はデジタルカメラ化を基本とし、フィルムを残す場合は(かなり高性能なデジカメが用意できない限りフィルムを残す)ポジだけでよい。既存のフィルムを含め、保存に値する全てのスライド等はフォトCD化する(なおフォトCD画像はそのままでは使えないが、色調等の調整は、実際の使用時でよい…使うかどうか分らないものまで全部完璧に調整済みにしておくのはコストが嵩みすぎる)。

 図作成は、用意できるシステムや慣熟度によって大きく異なるが、昨今ではデジタル化は珍しいことでもない。CAD系にしろ、ポストスクリプト系にしろ、画像データベースで整理可能なはずである(トレースの元図もアーカイブの対象)。文書系は、テキスト、RTF、PDF、HTML等の互換性フォーマットを利用する。全てのファイル(電子資料)は、グループウェアのシステムで共有・アクセスできるようにする。

グループウェア

 日常的な連絡や相談、共有したい文書のオンライン公開、電子掲示板(電子会議室)、スケジュール共有(ないし/及びガントチャート)などを、メール・グループウェア等で行うと、業務の電子化に大きく貢献する。いずれも非公開で、ユーザIDとパスワードを要するシステムである(普通は、使用ブラウザ等にパスワードを記憶させておく)。関係者が多岐にわたる現場などでは、有効に機能すると思われる。

 デジタル写真を通常利用することも、実効的である。これも現場の期間中に毎日アップロードして、写真データベースを情報共有できると良い。なお、最近の高画質な300万画素機以上なら、報告書使用も可能と考える(もちろんピント・被写界深度等が良好な写真で、扱いはL版程度まで)。

 グループウェア(簡単には掲示板)やオンライン写真データベースには、無料サービスも多いから、験してみるとよい。今後、整理作業まで含めて、プロジェクト関係者間のオンライン連絡網と情報共有システムは、予算に組み込まれるべきである。

建設CALS

 建設CALS(現実には電子行政の一環)の受発注者間の情報交換に関わる要素は、ごく大雑把にいうと以下のようなものである。ここでは、前三者に焦点をあてる。

 図書類は、報告書(REPORT)の他、施工計画(PLAN)や打合せ簿(MEET)、写真、図面、その他で構成されている(←厳密な表現ではない)。ファイルフォーマットは、受発注者間で共通に出来る場合までは拘束しないスタンスだが、当然共通フォーマット指向も強い。

 文書はXMLを計画しているらしいが、実際の運用はPDFになっているようである。現状でXMLが成功しているのは写真だけと思われる。写真用のXMLの項目は土木工事に最適化したものだが、参考になるし、援用?も可能かもしれない。図面フォーマットは様々だが(DXFも可)、共通フォーマットとしてSXFが始動している。

CD-Rのフォーマット

 電子納品の媒体はディスクだが(オンライン納品は計画されていない…入札は別として)、最右翼はCD-Rである。ただしISO9660の詳細は必ずしも定まっていない。ISO9660レベル1という説は根強いが、基準で文書ファイル名に全角を許している場合があり、矛盾している。全角や、せめて半角小文字を自由に使うための方法は3つ提案できる。

  1. ISO9660 Joliet
  2. ISO9660レベル2アップル拡張
  3. ISO9660レベル2で、文字種のISOチェックを行わない

 Joliet(よくJulietと間違える人がいるが、Jolietである)だと、Macでは8+3形式の部分しか見えず、溢れた部分は~1等になってしまう。但しOS XからはJolietに正式対応したので、今後は気にならなくなるかもしれない(エンドユーザーのOS X化が一巡したら)。
 アップル拡張はMacのリソースやクリエータを反映させた上、全角・半角小文字混在も可能(字数はレベル2の範囲内)にする。PC側は、Jolietと同じくWin95以降なら対応する。また、レベル2といいながらISO規格チェックを行わなければ、字数制限内で英字小文字や全角を使えるかもしれない(ライティングソフトによる問題かもしれない)。現状では、アップル拡張か、文字種制限を勝手にはずしたレベル2が良いだろう(この件は未確認)。Jolietの方が字数制限がゆるいが、レベル2でも充分な字数と思われる(半角31字以内)。


<WebSiteTop   …since 01.11.10