ファイルフォーマット¶

JSON¶

JSONはシンプルなファイルフォーマットで、どんなプログラミング言語からでも極めて簡単に読み込める。そのシンプルさ故に、XMLなどの他のフォーマットに比べてコンピューターで処理しやすい。

XML¶

XMLは、データ交換によく使われているフォーマットだ。データ構造を維持したりファイルを組み立てたりするのに便利だし、開発者がドキュメントの中にデータを組み込んだとしてもドキュメントを読むときの邪魔にならないからだ。

RDF¶

W3C勧告のフォーマットの一つであるRDFを使えば、複数のソースからのデータを組み合わせやすい形式でデータを表現できるようになる。RDFのデータはXMLやJSON形式で格納することもできるし、それ以外の方法でシリアライズすることもできる。RDFでは、URLを識別子として使うことを推奨している。そうしておけば、Web上の既存の open data との相互通信が便利になる。RDFはまだ広まっているとは言えないが、オープンガバメントの世界では流行しつつある。たとえば、イギリス政府とスペイン政府は共同でオープンデータプロジェクトを進めている。Webを発明したティム・バーナーズ=リーが最近、 five-star スキームを提案した。このスキームは、リンクしたRDFデータを、オープンデータへの取り組みに求められるゴールだとしている。

スプレッドシート¶

官公庁の多くは、Microsoft Excelなどのスプレッドシート形式のままで情報を残している。この形式のデータは、各カラムがどういう意味なのかという説明付きで扱える。

しかし、場合によってはスプレッドシートの中でマクロや数式が使われていたりして、そのせいでデータが扱いづらくなっていることもある。そんな場合は、スプレッドシートとともにその計算式に関するドキュメントも用意しておくことが望ましい。そのほうが、ユーザーがデータを読みやすくなるからだ。

カンマ区切りファイル¶

CSVファイルは非常に便利なフォーマットだ。コンパクトなので、同じような構造のデータを大量にやりとりするのに向いている。しかし、あまりにも質素なフォーマットなので、説明がなければまったく使いようがなくなってしまうこともよくある。各カラムの意味を推測するのはまず不可能だからである。そのため、カンマ区切りフォーマットの場合は各カラムがどんな意味なのかを表すドキュメントが特に重要になる。

さらに、ファイルの構造を尊重することが大事になる。たった一つのフィールドを省略してしまうだけで、そのファイルの残りのデータがすべて台無しになってしまう。何らかの方法でデータを修正しない限り、どうにもならない。残りのデータをどのように解釈すべきなのかが決められないからだ。

テキストドキュメント¶

WordやODF、OOXML、あるいはPDFと言った昔ながらのドキュメントフォーマットも、ある種のデータを表示するには十分だったりする。比較的安定したメーリングリストなどがその一例だ。見栄えはあまりよくないかもしれない。これが、最初にデータをとりまとめたときのフォーマットであることが多い。データ構造の一貫性を保つための仕組みはない。つまり、データ入力を自動化するのは難しいということだ。再利用できるようデータを表示するためのドキュメントを作るときには、テンプレートを使うようにしよう。そうすれば、少なくとも外部のドキュメントから情報を取り込むことくらいはできるようになる。

データの再利用を促すには、マークアップを可能な限り活用するといい。そうすれば、機械が通常のコンテンツと見出し(あるいはその他の何か)などを区別しやすくなる。データがさまざまな形式で存在するなら、ワープロ形式で表現するのは一般的に好ましくない。

プレーンテキスト¶

プレーンテキスト(.txt)は、コンピューターが簡単に読み込める形式だ。しかし、構造に関するメタデータはドキュメント内に含まれないことが一般的である。つまり、ドキュメントを解釈するためのパーサーを開発者が作らないといけないということだ。

プレーンテキストファイルを複数のOSで利用するときに、問題が発生することがある。MS WindowsやMac OS Xそしてその他Unix系のOSでは、行末に達したかどうかをコンピューターに伝える方法がそれぞれ違うのだ。

スキャン画像¶

ほとんどのデータに関して、最も適切でない表現方法だと言えるだろう。しかし、TIFFやJPEG-2000は、少なくともその画像が何なのかの説明を記録できるようになっている。その画像に関するドキュメントは、完全なテキストコンテンツとなる。この形式で表現するデータとして意味があるのは、もともと電子データでなかったもの(古い教会の記録や古文書など)を画像化する場合だ。何もないよりは、少なくとも画像だけでもあったほうがマシだというものだ。

プロプライエタリなフォーマット¶

専用システムなどでは、自前のデータフォーマットでファイルを保存したりデータを取り込んだりしているものもある。そんな場合は、そのフォーマットでデータを公開すれば十分だということもある。データを再利用するときにも同じシステムを使うであろうと思われる場合は特にそうだ。その独自フォーマットに関する情報が得られるところがあるのなら、常にそれを示しておかないといけない。たとえば開発元のWebサイトにリンクするなどだ。一般に、データを表すときにはできる限りプロプライエタリなフォーマットを避けるほうがよい。

HTML¶

最近は、さまざまなサイトでいろんなデータがHTML形式で公開されるようになってきた。データの構造が安定していて、かつそのスコープも限られるのなら、HTMLで十分だろう。場合によっては、ダウンロードして加工しやすい形式でデータを公開したほうがいいこともある。しかし、ウェブサイト上のページを参照するのはお手軽だしコストもかからないので、データを公開するときの最初の一歩としてはこの形式でもかまわない。

たいていは、HTMLドキュメントにデータを持たせるときにはtableを使うのが最適だろう。そして、各データフィールドが表示されてIDが与えられていれば、データを見つけたり操作したりするのがずっと楽になる。Yahooが開発したツール(http://developer.yahoo.com/yql/)を使うと、構造化された情報をウェブサイトから取り出せる。データがきちんとタグ付けされていれば、この手のツールの威力はさらに増す。

例: イギリスの交通量データ¶

アンドリュー・ニコルソンはソフトウェア開発者で、かつてイギリスでWestbury Easternバイパスの建設反対運動に参加した(そして、大成功を収めた)。アンドリューが興味を持ったのは、道路の交通量データにアクセスしてそれを利用し、自分たちの提案を正当化させたことだ。彼は、関連するデータのいくつかを、情報リクエストの自由を使って偶然知った。しかし、約書が提供したデータはプロプライエタリなフォーマットで、Saturnなる企業が作るソフトウェアでしか読めないものだった。この企業は、交通量のモデリングや予測に特化した企業だった。このソフトウェアには「読み込み専用」のバージョンが用意されていなかったので、アンドリューたちは結局そのソフトウェアのライセンスを購入せざるを得なくなった。教育機関向けの割引を使って、最終的に支払ったのは£500 (€600) だ。2010年4月の時点で、Saturnのソフトウェアパッケージの価格は最低 £13,000 (€15,000 以上)から始まる。庶民にはとても手の届かない値段だ。

オープンなフォーマットで情報にアクセスする権利を認めた情報法はないが、オープンガバメントデータの動きは政策の文書とともに始まった。公式情報を公開するときにはオープンなファイルフォーマットを使わないといけないというものだ。基準を定めたのはオバマ政権とOpen Government Directiveで、2009年12月に次のように言った。

現実的な範囲で妥当な制約に従う限り、政府機関が情報をオンラインで公開するときにはオープンなフォーマットを使わないといけない。データの取得やダウンロードそしてインデックス付けや検索を、一般的なWebの検索アプリケーションからできるようにする。オープンなフォーマットはプラットフォームに依存せず、機械可読であり、一般に公開するときい何も制約を課していない。そんなことをすればデータの再利用に支障が出るからだ。

Webサービス¶

頻繁に変わるデータで、一度に取得するデータサイズが限られている場合は、データをウェブサービス経由で公開するのが適している。ウェブサービスを作る方法はいろいろあるが、中でもよく使われているのがSOAPとRESTだ。SOAPのほうがRESTより優勢だが、RESTサービスは開発がとても楽だし使いやすいので、広く標準として使われている。

データベース¶

ウェブサービスと同様にデータベースも、データへの動的なアクセス機能を提供できる。データベースの利点は、ユーザーが自分の欲しいデータだけを取り出せるようにできるということだ。

リモートからデータベースにアクセスさせるというのには、セキュリティ的な問題もある。また、データベースの構造は各テーブルおよびフィールドの意味がきちんとドキュメント化されていなければ、うまく使えない。たいていは、データベースから取り出したデータを公開するためのウェブサービスを作るほうが比較的シンプルになるし安くつく。セキュリティ的な問題に対応するのも、こちらのほうが簡単だ。