Column (No. 9)

[付録] オープンデータのデータ仕様

 現在のオープンデータの仕様は一部を除き「フラット型」とか「カラム型」と呼ばれる形式で公開されています。これに対し、リンクトオープンデータ (Linked Open Data: LOD1)で公開すべきと言う議論があります。LODについて調べると、「セマンティックウエブ」だの識別子はURIだの何だのと難しく書いてありますが、本質は単純な内容なのでここで説明しておきます。

 オープンデータは今やかなり多くの自治体などから公開されていますが、担当の職員の方は大変な苦労をしていると思います。それなのに、余り使われていないと不満も感じているのでしないでしょうか。その原因は幾つかあると思いますが、データモデルの観点から言うとフラット型とかカラム型と呼ばれる形式で公開しているのも一つの原因ではないかと思っています。フラット型やカラム型とは何かという正確な定義はないのですが、ここでは以下と定義します。

  • csv等の形式に代表される表形式
  • 各csvファイルは独立しており、相互にリンクしていない
  • 各項目に登録できるのは文字列だけ (勿論、数字を並べて数値として利用する事は構いません)
  • データ上は項目の一つひとつが独立しており、項目間の関係は利用者が理解して使う

つまり、シートが一枚しかなく関数なども使っていない表計算ソフトのファイルだと理解してもらって構いません。表計算ソフトで業務をこなしたことがある方と経験があると思いますが、このフラット型のデータには多くの制約があります。例えば以下の点ですね。

  • 幾つの値があるか分からない項目を表現できない
    例えば、会社一覧というcsvがあり、その項目に通称というものがあった場合などです。東日本旅客鉄道には、JR東日本、JR Ease、JR東、JREなど多様な呼び方がありますが、これを一つの項目に入れる事は基本的にできません。
  • 項目の値に注釈をつける事ができない
    これは、技術的には値にメタデータを定義すると言います。例えば、室温という情報に、何時にどの温度計で測定したなどの情報を付加する事はできません。もしやるとすれば、温度とは別に「測定時刻」などの項目を追加する事で対応する事になります。よく使うメタデータの例としては、「確認済み」というフラグを付けるケースです。例えば、人事データに社員の住所を登録する時、単に人間が打ち込んだ住所なのか、住民票などで確認した住所なのかを区別したい場合があるわけです。

この様な制約を回避するために、オブンデータを作成する際に以下の対応が必要です。

  • フラット型ではリンクを使わないので、ひとつのcsvファイルに必要な情報を盛り込む必要がある
    これは、オープンデータの担当者は各部局や、時には外部の組織を回ってデータをかき集めないとならない事を示しています。
  • 値の数を制限する
    例えば前記の会社一覧の例では、通称をひとつに限るなどという事になります。もし、この方法を採用すると登録できない通称が出てくるので、例えばコールセンターなどではこのデータは使えない事になります
  • メタデータを表現する項目を追加する
    項目間の関係を利用者が理解して使う必要があるため、項目の使い方などを書いた説明書などの情報がcsvとは別に必要という事になります。

これらの対応を行うには、データの利用方法を予め想定するという事を意味します。利用方法を想定するという事は利用者を限定するという事です。利用者を限定するという事は、オープンデータの利用が少ないという事になります。

 これを回避する方法がLODという事になります。

 フラット型と異なる点は以下の通りです。

  • 複数のデータセットは一括して扱われ、データ間はリンクされている

これは、表計算ソフトで考えると、複数のシートがあり、シート間がリンクされているという事です。例えば前記の会社一覧の例でいうと、会社一覧というシートと通称一覧というシートがあり、東日本旅客鉄道の通称の項目をクリックすると通称一覧の該当の行が表示されるイメージです。

 リンクを使うと、単に複数の値を持つ項目を表現できるだけでなく、データ登録の担当部門を分けるという事が可能となります。例えば公共施設で言うと、施設の情報と所管分門の情報の両方が必要となりますが、施設一覧は施設管理部門が登録し、部門一覧は人事部門が登録するなどが出来る様になます。施設一覧には部門名や部門番号などの部門を識別できる項目をひとつ登録しておけば、電話番号や所在場所などの細かな情報の登録する必要はありません。必要に応じて、部門一覧を参照すれば良いのですから。つまり、既存のオープンデータは利用者に合わせてデータ収集して加工するのに対し、LODはデータを出す側に合わせてデータをありのまま登録する事になります。

 尚、LODでは項目名などをURIで表現しようというのは、項目の定義を明確化して誤解しない様にしよう、コンピュータで処理しやすい様にしようという話であり、このコラムに書いてあるメリットとは全く別の観点です。一般の方は忘れて良いと思います。個人的にはcsvのままでリンクしても利用しやすいオープンデータになるのではないかと思っています。

  1. LOD: このコラムではLinked Open Dataを意味していますが、データ仕様の議論ではLevel of Detailの事をLODと言う場合もあるので注意が必要です。Level of Detailは、Level of Developmentの略と言う場合もあり、建物の設計や建築が進むに従い概略の設計図から段々と詳細な設計になる事を指しています。 ↩︎