（訳注：この記事は本家OKFn.org記事の日本語訳です）

データのために「バージョン管理」を行う能力は重要な関心事です。様々な選択肢がありますが、最も魅力的なもののひとつは、Git やMercurial のように、コード用の既存ツールを再利用することです。この投稿では、私たちが暫くの間使用してとても効果的だということが分かったツールを利用する、データの格納とバージョン管理のための単純な「データ・パターン」について記述しています。

序章

行われた変更を格納し、それを他の人と共有する、データのバージョンとリビジョンを管理する能力、とりわけ分散的な手法は（オープン）データ・コミュニティにとって大きな便益となるでしょう。私はその理由を以前（こちらの初期の記事を参照）議論しましたが要約すると：

• 効率的な分散型の共同作業が可能です。私のデータセットを取り出し、変更し、それを再び私と（同時に他の人とも！）共有することができます。
• 出所をより良く（つまり、どの変更がどこから来たのか）追跡することが可能です。
• シンプルで効率的なやり方で、更新内容を共有し、データセットを同期させることができます。例えば、ファイル全体を再取得しなくても過去数か月のGDPや雇用データを取得する自動的なやり方で。

「データのためのリビジョン管理」問題に取り組む方法はいくつかあります。ここでのアプローチは、私たちがGit とMercurial のようにコードのために設計された既存の強力な分散型バージョン管理システムを利用し、データにそれらを適用することができるということを意味する形式でデータを取得することです。そのため、データのための最良のGithubは、実際のところGithub それ自身かもしれません。もちろん、Git(hub)の上にデータ特有のインターフェースを重ね表示したいかもしれません。 これは私たちがhttp://data.okfn.org/で行っていることにほかなりません。

このアプローチには制約があり、私は、これらといくつかの代替モデルについて以下に論述します。これは特に、「小さな(あるいはミクロな)データ」、例えば10MB あるいは100K行以下の場合に最適です。（ひとつの代替モデルはマックス・オグデンが最近始めた非常に面白いDatプロジェクトで見つけることができます- 彼とは、この話題について何度も話し合いました。）

しかしながら、ツール類に成熟と力があってますます発展しそうであり、そして多くのデータは小さいという事実から、私たちはこのアプローチは非常に魅力的であると考えています。

パターン

パターンの本質は次のとおりです：

1. 行指向のテキスト、および特にCSV(*1)（コンマ区切り変数）ファイルとしてデータを格納すること。「行指向のテキスト」は、テーブルの列（あるいは個別のセル）のようなデータの個々の単位が１行(*2)に相当することを単に示します。
2. データを格納し管理するのにGit やMercurial のように最適な種類（すなわちコード）のバージョン管理を使用してください。

Git とMercurial のような強力な分散型バージョン管理ツールがそれによって有効に（なぜなら、それらのツールはたいてい行（ライン）指向のテキストであるコードのために構築されるからです）動作することができるので、行指向のテキストは重要です。しかしながら、それは単なるバージョン管理ではありません：これらの種別のファイル（grepからエクセルまで！）を管理し操作するためのツールには多数の、こなれたセットがあります。

基礎的なパターンに加えて、追加できる、いくつかの特別オプションがあります：

• GitHub（やGitorious、あるいはBitbucket等々）にデータを格納する。下記の全ての例はこのアプローチをとっています。
• datapackage.jsonファイルを加えて、集めたデータをSimple Data Format のデータ・パッケージに変えます。これはライセンス、出所およびスキーマ（このカラムは数字、これは文字列）といった不可欠な情報の小さなセットを提供します。
• データの処理と管理に使ったスクリプトを加えてください。このようにして、あらゆるものがひとつのリポジトリにうまくまとまります。

このアプローチの何が良いのでしょうか？

行指向のファイルの管理および操作のために存在する、ツールのセットは巨大で成熟しています。特に、Git やMercurial のような強力な分散バージョン管理システムは、既にコード周りの分散型でピア・ツー・ピアの共同作業を行うための非常に堅牢な方法であり、このパターンはそのモデルをとり、それをデータに適用可能にします。ここに、なぜそれが良いのか、いくつかの具体的な例があります。

出所のトラッキング

Git とMercurial はコミットメッセージとdiff（差分）によって、個々の貢献の完全な履歴を提供します。

コミットメッセージの例

ピア・ツー・ピアの共同作業

データをフォーク（分岐）したり、プル（取り込み）することは、個々の貢献者がそれに関して同時に作業することを可能にします。

プル・リクエストのタイムライン

データのレビュー

Git やMercurial の使用によって、コードレビュー用ツールは、データ調査のために転用することができます。

プル・スクリーン

シンプルなパッケージング

リポジトリ・モデルは、単一の場所にデータ、コードおよびメタデータを格納する、シンプルな方法を提供します。

データ用のリポジトリ

アクセシビリティ

このようなデータ格納および、バージョン管理手法は非常にローテクなものです。フォーマットとツールは両方とも非常に成熟していてユビキタスです。例えば、すべてのスプレッドシートおよびすべてのリレーショナル・データベースはCSVを扱うことができます。すべてのunixプラットフォームにはこれらの種類のファイルに使えるgrep、sed、cut のようなツール一式があります。

例

私たちは、このアプローチと共に長い間使用しています：2005年、私たちは最初にSubversion そして次にMercurial にCSVを格納しました。次に、3年前にGit（そしてGithub）に切り替えた時、私たちはそこに格納し始めました。2011年に、私たちは上記のパターンによって管理されたデータセットの全体のリストを含んでいるGithub 上でデータセットの組織化を始めました。ここに、いくつか具体例があります：

• 国、地方、そして世界のGDPが世界銀行から集められ、そして標準化されたCSVへと変わりました。データをクリーンにするために使用されるPython のスクリプトは、scripts に含まれています。
• スタンダード・アンド・プアーズの500種株価指数（米国のトップ500の公にリストされた株価のインデックス）中の会社の一覧。データを処理するためのPython スクリプトと出典からクリーンにされたデータを複製する方法に関する手順を含んでいます。このデータセットは、悪い差分（例えば再アレンジされたカラム）を含めて、差分がどのように見えるかという面白い事例を提供します。

メモ：ほとんどのこれらの例はGithub 内で管理されているCSVを示すだけでなく、同時にシンプル・データ形式のデータ・パッケージです。-その中にあるdatapackage.json を参照してください。

付録

制限と選択肢

行指向のテキストおよびそのツールはもちろんデータ保存およびバージョン管理に対する完全な解決策からはほど遠いものです。それらはすべての形およびサイズのデータセット用には動作しません。また、いくつかの点で、それらは、表形式のデータへの変更を追跡しマージするには厄介なツールです。例えば:

• 行指向のテキストとして保存されたデータ上の単純な操作が非常に大きな変更セットにつながる場合があります。例えば、２つの項目（=カラム）の順序の入れ替えはすべての行の変更につながります。diff（差分）、マージ等が行指向だとすれば、これは不幸なことです(*3)。
• それは、小さめのデータ（例えば<100k の列、<50mb のファイル、最適なのは<5mb のファイル）に対していちばんうまく動作します。Git とMercurial は、大きなファイルの扱いはさほどうまくなく、diffのような機能はより大きなファイル(*4)ではさらに厄介になります。
• それは、多くの同じ記録（理想的には表形式のデータ）から構成されたデータにとっていちばんうまく動作します。行指向のストレージと適切なツールのためには、行指向のCSV構造に適したデータのレコード構造を必要とします。あなたのCSVがあまり行指向で無い（例えば、項目内に多数の改行がある）場合、diffやマージで問題を引き起こすので、パターンはそれほどよくありません。
• CSVは多くの情報、例えば項目（全て文字列です）の種別についての情報を欠いています。
  その単純性を危険にさらしたり、純粋なデータとしての利用がもはやできなくなることを犠牲にせずに、メタデータをCSVに加える方法はありません。しかしながら、個別のファイル内にこの種の情報を追加することができます。それこそデータ・パッケージ標準がそのdatapackage.jsonファイルで提供するものです。

最も基本的な制限は、とりわけ行指向のdiff とマージの、その原子単位が行でない（それはセル、あるいは何らかの２カラムを入れ替えるような変換）構造データへの適用で発生します。

下記で議論されている最初の問題は、テーブルへのシンプルな変更がファイルの全行への変更として扱われる、明確な事例です。完璧な世界であれば、便利な構造とそれをサポートする強健なツールの全体セットの両方があるでしょう。例えばCSVの２カラムの入れ替えをシングルの単純な変更と認識する、あるいは個々のセルのレベルで機能するツールです。

基本的に、リビジョンシステムはdiff フォーマットおよびマージプロトコルの周辺に構築されます。これらを正しくすれば、残りの多くは後からついてきます。基本的な３つの選択肢は次のとおりです：

1. 行指向のテキストにシリアライズしてGit のような偉大なツールを利用（上述の通り）。
2. 原子構造（例えば文書）を識別し、そのレベル(CouchDB やRDBMS のための標準的な列レベルでの copy-on-write（書き込みの都度コピーする）を考えてください)でdiff を適用する。
3. 変換を記録する（例えば、リファイン）。

オープン・ナレッジ財団では、私たちは、2.のラインに沿ったシステムを構築しました、また2.と3.の両方の調査および研究に関係しています – dataprotocols.org 上のデータのための変更および同期を参照してください。これらの選択肢は絶対に詳しく調査する価値があります – また、例えば、マックス・オグデン（彼と私はこの話題に関して多くの大きな議論をしています）は、Dat と呼ばれる刺激的なプロジェクト(「スリープ」プロトコルを使用する共同的なデータ・ツール)に現在取り組んでいます。

しかしながら、ここまでの私たちの経験は、行指向のアプローチがそれらの他の行（少なくともより小さなサイズのファイル用の!）に沿ったどんな現在利用可能なオプションにも打ち勝つということです。

data.okfn.org

数年間このようにGithubにデータを格納してきて、私たちは最近 http://data.okn.org/ をローンチしました。それは明示的にこのアプローチに基づいています：

• データは https://github.com/datasets のGitHub上のGit リポジトリに格納されたCSVです。
• データセットはすべてdatapackage.json のメタデータを持つデータ・パッケージです。
• フロント・エンド・サイトは、非常に単純です – 単にカタログとAPIを提供し、Githubからデータを直接プルします。

なぜ、行指向なのか

行指向のテキストはコードの自然な形式で、したがって巨大な数の優れたツールがサポートしています。しかし、行指向のテキストは、一般的なレコード指向のデータを格納するための最もシンプルで簡潔な形式であり、たいていのデータはレコードになることができます。

最も基礎的な構造化データには、項目用の区切り文字およびレコード用の区切り文字が必要です。コンマまたはタブ区切り値(CSV、TSV)ファイルはこの符号化の非常に単純で自然な実装です。それらは、スペース、改行に加えて最も自然な区切り文字でレコードを区切ります。項目区切り文字として、スペースはあまりに一般的すぎるので、自然とコンマまたはタブに頼ることになります。

バージョン管理システムには、動作の原子単位が必要です。データ用のバージョン管理システムは、とても有効に原子単位としてレコードを扱うことができます。行指向のテキストをレコード指向のデータの符号化に使用することで、私たちはレコード指向のコードのバージョン管理のために構築された既存ツールの形式でバージョン管理システムを自動的に得られます。

• (*1)ファイル中の区切り文字は必ずしもコンマである必要はないので、CSVという場合に、実際は「DSV」を意味するということに注意してください。しかしながら、列終端は改行(あるいはキャリッジリターンと改行)であるべきです。
• (*2)CSVにはひとつの行にひとつの列があるとは限りません。引用符のある項目に改行があることがあります。しかしながら、ほとんどのCSVはひとつの列にひとつの行です。CSVは入手可能な中では、可能な限り単純な構造化データ形式です。
• (*3)具体的な例として、マージ機能は、レコードの様々なセット、すなわち行に影響する２つの変更セットの調和においておそらくとてもうまく動作するでしょう。しかしながら、各々カラムを移動させる２セットの変更はうまくマージしないでしょう。
• (*4)より大きなデータについては、私たちは、Git（そして例えばGitHub）をs3のような単純なファイル記憶装置と交換することを提案します。s3が基礎的なcopy-on-writeのバージョン管理をサポートできることに注意してください。しかしながら、copy-on-writeであるため、それは相対的にかなり非効率です。

原文(2013/7/2 Open Knowledge Foundation Blog 記事より)：
Original post Git (and Github) for Data / Rufus Pollock, licensed under CC BY 3.0.

（訳注：この記事は本家OKFn.org記事の日本語訳です）

Golden spiral, by Kakapo31 CC-BY-NC-SA

オープンデータの可能性はこの１０年間私たちを魅惑しています。

私はTheyWorkForYou のようなサイトを構築することで、政府を実際に利用可能なものにしたいと思いながら過ごしてきました。

しかし、そのような興奮は最終的には重要なことではありません。

重要なのはスケール（規模の拡大）です。どのような組織構造がこの運動を爆発的に加速させるでしょうか？

自律成長しているボランティア・コミュニティを作ることによってでしょうか、あるいは資金フローを作り出すことによってでしょうか？

この投稿は、機能しているものも（まだ）機能していないものも含め、手短にそして挑発的に俯瞰します。

現在機能しているもの

1) 新しいデータを登録するためにコミュニティを形成する。OpenStreetMap とMusicBrainz は２つの大きな事例です。これが機能するのはコミュニティがデータの発生源であるからです。しかしながら、これまでのところどちらも私が思ったほどにはその産業の支配力を持っていません。

2) オープンデータの上流側の生成者にツールを売る。これは、中央政府のためにCKAN が行っている（そして新しいScraperWiki のCKAN ツールが支援している）ことです。これはmySociety が行っていることであり、FixMyStreet のインストール一式を地方自治体に売る場合は、その結果としてRSSフィードで道路の陥没を公表します。

3) オープンデータを（ひっそりと）利用。あらゆる組織がこれを行っていますが、決してそのことを話しません。これはブルームバーグのような全く古いデータ再販業者の鍵です。これはScraperWiki のプロフェッショナル・サービスの顧客のうちのほとんどが私たちに依頼するものです。社会に対する価値は巨大で目に見えません。大きな欠点は、それがオープンデータの供給をスケールさせるのを支援しないということです。

4) 下流側の利用者にツールを売る。これは必ずしもオープンデータに固有の話ではありません。スプレッドシートやビジネス・インテリジェンスのような既存のソフトウェアはオープンなあるいはクローズドなデータと共に使用することができます。多くのオープンデータがウェブ上にあります。したがって、ウェブ・データをうまく使える新しいScraperWiki のようなツールは特にこれに適しています。

まだ機能していないもの

5) 協働的なキュレーションScraperWiki が、スクレイピング用のコードの編集に基づいてオープンデータ・キュレーション・コミュニティを作る大胆な試みとして始められました。その最初の形式(今後はScraperWiki クラッシックと呼びます)では、これはスケールしませんでした。なぜそれはスケールしなかったのか、ここに、オープンデータモデルの点から、いくつかの理由があります。

a. それは上流側ではありませんでした。あなたがいかなる出所を与えても、人々は自分が直接出所から取得するデータを最も信頼します。例えば、スクレイピングされたデータを電話を使って、手動で集められた新しいデータで補うことなどによって、これは部分的に上流側になることもできます。

b. それは内密なものではありません。理論的には、商品のデータも一緒になって公開で議論することで得るべきものは多数ありますが、それはほとんどの組織の本能に反します。

c. 既存の文化はそう多くはありません。フリー・ソフトウェア運動は、約15年後にオープン・ソース運動によって、そして25年後にGithubのようなツールによって開発準備が整った協働の豊かな文化を構築しました。少数の例外(特にOpenCorporates)を除いて、まだオープンデータのキュレーションプロジェクトはありません。

6) 多目的のデータ市場（特に主としてオープンデータを再利用しているもの）はまだ立ち上がっていません。いつかはできるかもしれませんが、それにはまずデータの整形や同期のためのうまく採用された、より高レベルの標準（おそらくCSVファイルを基にしたdat のようなもの）がまず必要だと思います。

これからが期待されるもの

今後、多数の輩出が期待される、すばらしく刺激的なモデルです。

7) 上流側に労働/金銭を与えて、よりよいデータの作成を支援する。これは全く新しいものです。その唯一かつ最も優雅な例は英国の国立公文書館の制定法データベースのキュレーティングです。彼らは、商用の法令関連出版社と政府の他の部分から支持されたスタッフの助けを借りて仕事をします。

これは人々が最も信頼し、データの品質を改善する最大の能力を持っている上流側に金銭を生み出すので、賢明なやり方です。

8) バイラルなオープンデータのライセンス設定。MySQLは、組込システム・メーカーにGPLdソフトウェアのプロプライエタリなデュアル・ライセンスを提示することで、この種のやり方として多大な利益を出しました。データでは、これにOKFNのOpen Database License を使用することができるでしょう。オープンデータを自分のクローズドデータと混ぜたい場合に、組織はお金を払うでしょう。私はこれを積極的に利用している人は知りませんが、OpenCorporates のクリス・タガートは数年前に私にこのモデルを教えてくれました。

9) 株式会社が、戦略的優位性のためにデータをリリースする。会社は戦略的な利得のために自らのデータの公開を始めています。これは非常に新しいもので、これからがより期待できます。

何か見逃していますか？あなたはオープンデータをスケールさせ、何１０億もの利益をもたらすのはどんなモデルだと思いますか？

原文(2013/7/18 Open Knowledge Foundation Blog 記事より)：
Original post 9 models to scale open data – past, present and future / Francis Irving, licensed under CC BY 3.0.

（訳注：この記事は本家OKFn.org記事の日本語訳です）

「はい、政府は他の人々のデータをオープンにすべきです」

伝統的に、オープン・ナレッジ財団は個人に関わらないデータをオープンにする活動をしてきました。公的機関からの受託研究論文、財政支出データといったものです。個人のデータが国勢調査のような何らかの共有されたデータセットの一部である場合、個人のプライバシーが保護され、公表された集計データは共有され、公共の資産であることを保証するために、大量の検討や努力がなされました。

しかし時代は変わります。政府や企業が集めるデータは次第に増えつつあります。（本人がそれに気付いているかどうかに関わらず）個人に関わる大量のデータです。データの収集と共有によるプライバシーへのリスクは恐らく以前よりも大きくなっています。データが「ビッグ」か「スモール」かに関わらず、データ解析はこれまでに無い洞察を導き出す可能性を持っています。しかしながら、個別のデータセットが連結されたり、対応付けられたりするので、その洞察の中には個人のプライバシーを犠牲にするものがあるかもしれません。

オープンデータおよびビッグデータの両方とも今ちょうどホットな話題です。そしてこのような時に、組織はあらゆる問題についての必要な検討を行うこと無しに、そのような話題に関係したいという誘惑に駆られがちです。ビッグデータの現在の潜在成長力とオープンデータの経済的便益を組み合わせる誘惑によってプライバシーへの関心が無視されるかもしれないので、ビッグデータとオープンデータの交差は多少気懸かりな点です。プライバシー・インターナショナルが開発のためのデータに関する最近の記事でこの点に注意を促していることは正しいのですが、もちろん他の領域も影響を受けます。

本日（訳注：2013/8/27）、私たちはオープンデータとプライバシーに関して進みつつある議論を支援するために、いくつかの用語を提案したいと思います。

私たちのデータとは、個人の要素を持たず、共有物の意識が明確なデータです。例えば次のようなものです。バスは私の都市でどこを走っているのか、政府は私の税金を何に使うと決めたのか、国勢調査やその集計結果はどのように組み立てられているのか。オープン・ナレッジ財団において、私たちのデフォルトの立場は、私たちのデータがオープンデータであるべきということです。それは私たちがみな利益を得ることができ、またそうすべき共有資産です。

私のデータとは個人的な私に関する情報で、誰が集めたかに関わらず、何らかの方法で私のことを識別することができます。それは、私の直接の許可なしに他の人によってオープンにされたり公表されるべきではありません。しかし、それは、私（私は自分が望めば、利用可能な形式で私に関するデータにアクセスできるべきであり、それを私自身が共有する権利を持っているべきです）には「オープン」であるべきです。

変換されたデータとは個人に関する情報で、個人が識別可能な要素を除去するためにデータを匿名化、収集する努力が行われたものです。

私たちは、変換されたデータが私たちのデータとしてオープンに公表できるかどうかを確認するために引き続き行う必要のある、いくつかの明確なステップが存在すべきだ、ということを提案します。どのような考察が行われるべきかを述べる、オープンデータ用のプライバシー原則のセットはよい出発点になるでしょう。そこには、データが関係しているすべてのグループの代表およびデータの変換方法にまつわるデータプライバシー専門家を含む重要なステークホルダーに意見を求めることなどが含まれるでしょう。いくつかのデータセットについては、市民のために合理的なレベルのプライバシーを維持することができるようにこれを十分に変換することが可能だとは、証明するのが難しいかもしれません。これらのデータセットはシンプルに非公開とすべきです。他のものについては、データがオープンに公表されるのに適している状態になる前に、受入れ可能なプライバシー標準を達成するために、変換に関してさらなる研究が必要だということかもしれません。データの公表が必須となる前に、リスクに対する保証は考慮され管理されます。変換が関係のある個人に十分なプライバシーを提供し、原則が厳守された場合、データはオープンデータとして公表することができます。

私たちは「私たちのデータ」のうちのいくつかは個人の要素を持つだろうと述べておきます。例えば、議会のメンバーは公共圏に入る肯定的な選択を行ない、議員に関する情報のいくつかを市民は漏れなく利用可能です。このタイプのデータは、比較する標準は公益とは異なるかもしれませんが、私たちが公開前に提案するオープンデータのプライバシー原則に照らして依然として考慮されるべきです。

これは、オープンデータおよびプライバシーの領域を調査するシリーズ投稿の一部です。私たちは、これは非常に重要な問題であると感じています。これらの問題に興味を持っているか、オープンデータ用のプライバシー原則の開発を支援したい場合は、ワーキンググループ・メーリング・リストに参加してください。私たちはメーリング・リスト、下記コメント欄等での提案や考察、もしくは私たちや一緒に作業しているオープン・ライツ・グループとの2013年秋のOKConや他のイベントでの意見交換を歓迎します。

原文(2013/8/27 Open Knowledge Foundation Blog 記事より)：
Original post Open Data Privacy / Laura James, licensed under CC BY 3.0.