文系のための「調査データの構造」（２）

どのような調査でも、調査の段階は大きく分けて二つの段階に分けることができる。
第一段階は情報収集の段階であり、第二段階は情報構築の段階である。
研究段階の分析と解釈は、再構築された情報を用いて行うのが常である。

紙媒体が中心であった時代には、主として分析と解釈に焦点を当てられてきたが、
その背景には、紙媒体の物理的な限界があると考えられる。
全データを記載しても、必要な情報を得難いにも関わらず、紙面をかなり圧迫する。

しかしながら、デジタルデータを用いるようになるとこの状況は大きく変わる。
記録媒体の大容量化、検索システムの高度化、情報通信速度の高速化、
こうした技術革新は、紙媒体の持つ物理的限界を簡単に克服してしまった。

問題は、こうした技術革新に多くの人がついて行けていない現状...。

一般的に研究「資料」は費やした人的、金銭的、時間的コストに価値があるが、
一方、構築された「情報」は認知度と共有性に価値がある。
情報は、公開し、共有することで価値が産まれる。これ超基本。

珍しいデータや貴重なデータをハードディスクに放置しても意味が無い。
著作権と個人情報が関係しないデータであれば、積極的に公開した方が良い。
もちろん、きちんと整理された状態で公開しないといけないが。

このように言うと、多くの人は納得してくれるのであるが、残念なことに、
自分が他人のデータを使うことには何の抵抗も感じないが、
自分が他人のためにデータを公開することを拒否する人は非常に多い。

近年、欧米を中心に過去の資料のデジタル化と公開化が進められていて、
それに伴って、歴史的な資料の再発見が相次いでいるが、日本では少ない。
デジタル化と情報公開は、一緒に考える必要があるのだが...色々と中途半端。

さて、最初から話が逸れそうになったが、要するに、分析と解釈だけの時代は終わり、
現在は、分析と解釈に至るまでに、どのような資料が収集され、情報が構築されたかが、
重要視されつつあるということ。この問題は改めて考える必要がある。

情報を体系的に管理することは、研究データの消失の危険性を低減し、
また、データ改ざんの問題を未然に防ぐこともできる。
第三者が後に研究過程を復元できるような試みは必須条件になりつつある。

本ブログで紹介する方法は、データ公開の要請に迅速に対応できる方法にもなる。
前回の話では、第一段階として、一次取得データの管理方針について述べたが、
今回の話では、第二段階として、二次加工データの管理方針について述べる。

一次取得データの話でも述べたように、取得した生データは直接加工しない。
これはオリジナルの状態で保存する。再度、取り直しができるとは限らない。
二次加工データは、一次取得データから必要な物のみをコピーして編集したデータ。

まずは、データの構造を考えてみる。以下は、その模式図。

二次加工データは、「調査成果」というまとまりで管理され、
さらに調査成果のまとまりを「版」としたサブディレクトリを複数持つ。
版は、調査次数（年度）に対応するかもしれないが、対応する必要は無い。

各「版」の中には、各々の「作業」に応じたサブディレクトリが作られる。
例えば、図面、文章、集計表、測量図、写真、動画、音声...など。
要するに、日付毎で取得されたデータを種別毎に再割り振りする感じ。

ここで重要なポイントは、元データは、一次取得データから「コピー」すること。
間違っても「移動」してはいけない。データの重複が生じても構わない。
一次取得データは、何があっても直接には触らないこと。

コンピュータのデータは、見た目が変わらなくても、
ちょっとした操作で、メタデータが書き換えられることがある。
データを得た時の情報を可能な限り維持することが重要。

あとは、フォルダ名とファイル名の付け方。何を注意するのだったか？
確か、半角英数でスペースと記号は使わないのだった。
そうそう、使って良いのは「_」の記号だけだった。

さてさて、これで、調査データの管理方法の初歩的な方針は理解できたはず。
ただし、このブログで示した方針は、あくまで全体的な概要であって、
より厳密に情報管理を行うためには検討すべき問題が山積している。

ファイル名やフォルダ名の付け方について、あまり詳しく述べていないが、
具体的に、どのような名称を付けるべきか？という問題や、
各フォルダには、メタデータが必要かもしれないという問題もある。

また、二次加工データに関しては、作業記録のログの記録方法や、
編集で行われた個別操作の記録の取得方法なども必要かもしれない。
では、ソフトウェアに依存するような操作の場合はどうするべきか？

実は、こうした内容こそ、各分野における情報標準の問題として議論すべきなのだが...。
まぁ、愚痴を言った所で、現状が変わる気配は全く無いので、
このままデファクトで標準を作ってしまうのは有りかもしれない。

ところで、前回の話と今回の話を合わせて見てみると、
全体的に複雑に見えたかもしれない。
これをもっと簡単にするには？という要望があるかもしれない。

本ブログでは、入門編からPython というプログラミング言語を使っているが、
要するに、前回と今回の記事で述べた方針を、Pythonで実装してしまおう、
というちょっとした意図があってのこと。

まだまだ、先は長いけれど、「えっ、パイソン？それって蛇？」って人には、
一応、文系のための「情報管理」の話を最初から読み進めることを推奨。
これから、少しずつ、難しくなっていく。