Open Data Protocols の仕様を駆け足で紹介します。いろいろなデータを扱うときに困ってしまうのが、フォーマットがバラバラ、という事態です。データファイルのフォーマットというと CSV やら JSON やら XML やら、、、色々あります。 Open Data Protocols が取り組んでいるのは、機械的にデータを処理するときに可搬性のある方法を構築していこう、という感じのことです。

ホームページの説明では（いきなり "a the" なのは残念。。。）：

This site is a the home of simple protocols and formats for working with open data. Our mission is both to make it easier to develop tools and services for working with data, and, to ensure greater interoperability between new and existing tools and services.

日本語にするとこんな感じでしょうか。

このサイトは、オープンデータを扱うためのシンプルなプロトコルとフォーマットの出発点となるものです。私たちのミッションは、データを扱うツールやサービスの開発を簡単にすることと、新旧のツールやサービスをまたいでも素晴らしい相互運用性を保証することの両方です。

実際には、JSON でメタデータを定義して実データは CSV で管理する、ということになります。簡単な表形式のデータをターゲットにしています。複雑なグラフ構造や依存関係を持つようなデータは、おそらく対象にしていませんので注意しましょう。

この記事では、Simple Data Format (SDF)、JSON Table Schema、CSV Dialect Description Format (CSVDDF) を順々に見ていきます。

Simple Data Format (SDF)
JSON Table Schema
CSV Dialect Description Format (CSVDDF)
終わりに

Simple Data Format (SDF)

Simple Data Format の仕様は下記のページにあります。現在は 1.0 beta です。

http://www.dataprotocols.org/en/latest/simple-data-format.html

HTTP 越しでアクセスすることに焦点を当て、表計算ソフトや関係データベースとやり取りするような表形式のデータを表現することに注力しています。キーとなるのは次の３点です。

データは CSV 形式
データファイルのスキーマを含む情報を記述した単一の JSON ファイル (datapackage.json)
他の Data Protocols 仕様を含む、既存の取り組みを再利用できること

ということで、Simple Data Format の最小のデータセットは、次の２ファイルから成ります。

data.csv: CSV 形式のデータファイル (名前は任意)
datapackage.json: CSV のスキーマを含む、データセットの情報

サンプルとしては以下のようになります。

data.csv

var1,var2,var3
A,1,2
B,3,4

datapackage.json

{
  "name": "my-dataset",
  "resources": [
    {
      "path": "data.csv",
      "schema": {
        "fields": [
          {
            "id": "var1",
            "type": "string"
          },
          {
            "id": "var2",
            "type": "integer"
          },
          {
            "id": "var3",
            "type": "number"
          }
        ]
      }
    }
  ]
}

resources -> schema -> fields と辿っていくとフィールド定義に辿り着きます。つまり、次のような Python のコードでフィールドを列挙できます。

#!/usr/bin/env python

import json

DATA_PACKAGE = 'datapackage.json'

with open(DATA_PACKAGE) as fp:
    dp = json.load(fp)
    fields = dp['resources'][0]['schema']['fields']
    for field in fields:
        print "{}\t{}".format(field['id'], field['type'])

詳細な仕様書は以下のページにあります。

http://www.dataprotocols.org/en/latest/data-packages.html

この記事の以降の部分では、メタデータの JSON の仕様、実データの CSV の仕様を見て行きます。

JSON Table Schema

SDF では JSON で表形式を定義します。基本的な構造は下記のようになります。

{
  # fields は順序付けされたフィード定義（フィールド・ディスクリプター）の一覧です。
  # それぞれが表形式における個別の「列」を表します。
  "fields": [
    # ひとつのフィールド・ディスクリプター
    {
      "id": "フィールドを識別する名前／ID",
      "label": "人間にとって可読性の高い名称",
      "type": "データ型を特定する文字列",
      "format": "フォーマットを特定する文字列",
      "description": "フィールドの説明"
      ...
    },
    ... フィールド・ディスクリプターが続く
  ]
}

"fields" は必須で、ハッシュの一覧でなければなりません。ハッシュには "id" が必要です。これはフィールド間で重複してはいけません。 "format" は基本的には日付に関するものです。"DD.MM.YYYY" などを想定しています。

要するに、id と type をきちっと定義して、管理用に label もあると嬉しい。いろんな人が関わるデータなら description に説明も記述してあると親切。文字列の書式が予め定義できるものなら format で明示しておきましょう。ということになります。 description に日本語を使うかどうかはとても悩ましい部分になるかもしれません。（基本的にはすべて英語の方が相互運用性は高まるはずです）

"type" は json-schema をベースにしています。 ElasticSearch で使われるマッピングも参考にしています。一覧で列挙すると以下のものがあります。

string
number
integer
date
time
datetime
boolean
binary
object
geopoint
geojson
array
any

類似のものとしては、Google の DSPL や BigQuery があるそうです。 DSPL は知りませんでしたが、Dataset Publishing Language の略だそうです。 Google ってこんなこともやってるんですね。

https://developers.google.com/public-data/

CSV Dialect Description Format (CSVDDF)

続いて CSV の区切り文字などに関することです。フィールドの値にカンマが存在する場合、何らかの方法でエスケープする必要があります。二重引用符で囲むことが一般的ですが、そうすると今度は二重引用符をエスケープする必要が出てきます。

インターネットにおけるデータ交換方式、という観点からは RFC で規定されています。

RFC 4180 (Common Format and MIME Type for Comma-Separated Values (CSV) Files)

しかし、一般に広く普及している形式は Microsoft Excel が書き出す形式であり、RFC 4180 と等価ではありません。記号のエスケープルールや、暗黙的な型変換に違いがあります。 Wikipedia の記事でも同様のことが言及されています。

Comma-Separated Values - ja.wikipedia.org:: レコードにコンマやダブルクォートが含まれている場合、エスケープされている場合でも、ソフトによって解釈が異なり、区切り方が変わることがある。その結果、データが破壊されることや、修正の手間が生じることがある。レコードにタブ文字が含まれている場合よりも、レコードにコンマやダブルクォートが含まれている場合のほうが多い。従って、CSVの代わりに、タブ区切りテキスト形式（TSV）を使うことで問題を避けられることがある。

また、数値をダブルクォートで囲まない場合、小数点の記号と混同される地域もあります。たとえば、Windows のパソコンでロケールをフランス語にして Excel を使うと、カンマが小数点の区切り文字になります。

小数点 - ja.wikipedia.org:: また非英語圏の国においては、コンマ (,) が小数点として用いられ、ピリオド (.) が3桁ごとの位取りに用いられる。すなわち、日本と逆である。

したがって、「CSV なら簡単」と思われがちですが、細かい部分に違いがあります。注意しましょう。

さて、CSVDDF の場合ですが、プログラミング言語の Python や Ruby で簡単に処理でき、データベースソフトの MySQL や PostgreSQL で一括処理できるように設計されているそうです。 Python の csv.Dialect と似た感じらしく、以下の設定を制御できます。

delimiter: フィールドの区切り文字
doublequote: フィールド内に出現する引用符の制御
lineterminator: 行末の表現
quotechar: 値の引用に使う文字
skipinitialspace: 区切り文字の直後の空白の処理方法

CSVDDF としては、データの文字エンコーディングには関知しないようです。一方で、SDF としては UTF-8 でのエンコードと規定されています。エクセルとの親和性は難しい課題になりそうです。

終わりに

Open Data Protocols の仕様をザーッと見てみました。 JSON でスキーマを定義して、データは CSV で保持する、というスタイルなので、比較的簡単に導入できる場合が多いと思います。 Datasets in Git として各種データセットを共有していたり、 Link Data のサイトでも使えるようになったそうで、オープンデータを扱うときには知ってると便利そうです。

オープンデータに関しては経済産業省も力を入れているようで、昨年度の報告書も刊行されましたし、各種委員会の活動も行われているそうです。

実際、総務省や気象庁もデータのオープン化を進めています。

統計におけるオープンデータの高度化 (総務省)
過去の気象データ・ダウンロード (気象庁)

アメリカでは Exective Order (大統領令) としてデータのオープン化が推進されていますので、その波が日本にもやってくるんじゃないかなぁと思います。

STOIC のように、表形式のデータさえ用意すれば簡単なアプリケーションを構築できてしまうサービスもありますので、データを分かりやすく管理しておくことで活用の幅がグッと広がりそうですね。蛇足として、 OData; Open Data Protocol とは関係が無さそうなので、検索エンジンで情報を拾うときは大変そうなのが難点だったり。

Ars longa, vita brevis

2013年6月18日

Open Data Protocols

Simple Data Format (SDF)

JSON Table Schema

CSV Dialect Description Format (CSVDDF)

終わりに

0 件のコメント:

自己紹介