統計表からRDFへ

平成25年3月11日

特定非営利活動法人 リンクト・オープン・データ・イニシアティブ

1.はじめに

欧米で国及び地方政府系でのデータ公開の方法としてリンクト・オープン・データ(LOD)が普及するにつれて、国及び地方政府系で所有し、これまでcsvやExcelデータとして公開されていた統計データもLODとして公開するという動きが始まっている[1]。LODとは、従来のWWWおよびセマンティックウェブの技術を用いて、WWWにおいてウェブページが互いに関係づけられるのと同様に、個々のデータを互いにリンクづけ、新たな関連の発見も含めてデータの利活用度を飛躍的に高めることを目的とするものであるが[2]、統計データの利活用においても、LODの役割が期待されている。

本報ではExcelデータのような統計表をLOD化するにあたって考慮すべき点やW3Cにおける本関連技術の現状、また予想される技術課題などについて述べる。LODおよびRDFについての詳細な説明は省略するので、それらについては他の文献等を参照されたい。

2.基本的な視点:統計表とRDFグラフ

国勢調査のような調査活動の結果は、個票と呼ばれる調査結果から個人が特定されるような情報を除いて統計値が計算され、表形式にまとめられ、xlsやcsvのようなフォーマットで公開される[3]。ここで具体的な統計数値の意味は、それに付随する各種属性のセットで表現されると考える。たとえば、図1に示すような、「平成22年工業統計表『工業地区編データ 経済産業省大臣官房調査統計グループ』(平成24年4月27日公表)」の「第1表 都道府県別、産業中分類別統計表」において、ExcelセルI10の意味は、「食料品製造業」という産業分類における全国合計の「従業者数」であるが、このとき表側および表頭にある「食料品製造業」や「従業者数」はもちろんのこと、正確には「全国計」、「実数(人)」に加えて、他の表も同様な構造を持つために、「平成22年工業統計表『工業地区編データ 経済産業省大臣官房調査統計グループ』(平成24年4月27日公表)」や、「第1表 都道府県別、産業中分類別統計表」もこのセルI10の数値の属性として考慮されなければならない。

図1 統計表の例(平成22年工業統計表の一部)

さらに、たとえば図1に示すように、事業所数、従業者数、製造品出荷額等、現金給与総額等々の別次元の各種データがここでは二次元の表に圧縮されて表現されているという視点も重要である。また、統計データ相互の関連には、独立変数的なもの(事業者数と従業者数など、深い関係が隠れているかもしれないが、それを明らかにするには詳細なデータ分析を必要とするもの)と、明らかに従属変数的なもの(従業者数人口比率や製造品出荷額構成比など)も同列に区別なく表現されている。リレーショナルデータベース(RDB)であれば、正規化され別テーブルとなるべきデータセットが表面上渾然と表形式にまとめられていることに留意すべきである。

一方、LODにおけるRDF(Resource Description Framework)のモデルはRDFグラフと呼ばれるグラフ構造である。ここでグラフというのは、二つのノードと両者を結合するリンクを最小単位とする構造のことである。図2にRDFグラフの例を示す。RDFグラフはラベル付き非循環グラフである。すなわちリンクにも名前が付与されており、そのリンクには方向があるが双方向ではない(双方向にする場合には、逆方向のリンクを別の名前をつけて付与する)。RDFのモデルはこのように単純なものであるため、表現方法として柔軟であり、根本的には表形式をこのようなグラフ構造に変換するのになんの問題もない。ただし、知識表現方法として原理的であればあるほど、どんな知識でも表現することはできてもその効率は悪くなる(表現に多くの記述を必要とする)というのが一般的であり、表形式からRDFグラフへの変換時の欠点として、表現効率の悪さが指摘できる。しかし、本来表形式に馴染まないデータで、表形式ではスパースになって0値ばかりが挿入されるようなデータでは、逆にグラフ構造のほうが表現効率がよくなる。

図2 RDFグラフの例

“Information Management: A Proposal”というタイトルを有するhttp:/…/Proposal/というリソースの著者はTim Berners-Leeという名前の人であることが述べられている。

3.なぜ表からRDFグラフか?

なぜ表形式になっているものをわざわざRDFグラフにするのだろうか? その利点はなにか? 実はそれはRDFの利点を生かしてRDFとしての利用を考えない限り、表になっているものをわざわざRDFに直す必要性はない。一般にRDFの利点として次のような点があげられる。

  1. URLを用いてグローバルに唯一な名前を定義し、その意味するところを定義できる。
    たとえば、図2においてTim Berners-Leeという名前の人はブランクノードで表現されているが、それが人(eg:Person)の実現体(instance)であるということは、RDFにおいて世界に通用させることができる。
  2. 背後に厳密なモデル論、意味論があるために、誤解の余地がない。またそのため、機械の助けをかりて様々な自動処理が可能となる。
    たとえば、図2ではeg:Documentとeg:Personの実現体ならば両者をeg:authorというリンクで結合することができるということが書いてある。したがって、ある著者のすべての出版物をRDFデータベース(RDFストア)から抽出したり、逆にeg:authorで結合されているノードについて片方は出版物であり、もう片方は人であると推論したりすることができる。
  3. 様々なデータの関係を、組織を超えてリンクとして定義できるため、組織を超えたデータの利用が可能となる。
    たとえば、市町村の様々なデータがすでにLODとして提供されていた場合、企業など各組織の所有するデータを市町村データとリンクすることで、市町村データを経由して政府統計データと民間のデータなど互いに当初無関係であったデータ間の関係も抽出することが可能となる。

現在、たとえば図1における表の各種属性は、その表のみにおいてしか意味がない。しかもその意味は表の構造に依存している。つまり、公表された統計データを民間調査会社等がダウンロードして利用する場合、各々の目的に応じてExcelデータの個々のセルの値を抽出し利用するが、それは全くその時々の表そのものに依存しており、表の意味、属性の意味は定義されておらず、機械処理をするにしても常に個別に処理されなければならない。データの属性をRDF化し、表の構造をRDF化することで、個々の表に依存しない汎用の機械処理を可能とすることができる。

表形式にはすでに作成者の意図が含まれているため、正規化されていない場合には、異なる表間での関連データを抽出することは容易ではない。また、組織を超えて、複数のデータの関係を抽出することは不可能かあるいは間違いを起こしやすい。たとえば、統計データにおける個票データはそのデータの持つ共通属性や異なりを考慮して、統計値に整理され、表形式に表現され、コンパクトな利用形態で提供されるが、ここにはすでに何を統計値とするか、どのような表形式にするかという時点ですでに表作成者による意味が付与されていることに注意しなければならない。RDF化することで、属性の意味を明確にし、データ相互の関連を明示的に定義することができ、組織を超えた統計データの利用が可能となることを期待できる。

4.統計データ共有化の現状

国際決済銀(BIS) 、欧州中央銀行(ECB) 、ユーロスタット(Eurostat) 、国際通貨基金(IMF) 、経済協力開発機構(OECD) 、世界銀行(WB) 、国際連合(UN)のような国際組織は各国の統計情報の集積と配布を行っているが、統計情報交換の効率化を主な目的に、SDMXイニシアティブを2001年に立ち上げ、統計データとメタデータの交換規約(Statistical Data and Metadata eXchange, SDMX)を制定した。SDMX第1版には統計のデータモデルに加えて、今日SDMX-EDIと呼ばれるところの、元々はGESMES/TSデータフォーマットの規約とXMLベースのSDMX-MLの規約が含まれるが、これらは2005年にISO標準TS 17369として受け入れられた。さらに第2版[4]ではメタデータとレジストリ・インタフェース仕様が追加されISOとなっている[5]

日本ではSDMXの普及は遅れており、平成22年報告の「オープンガバメントを実現するシステムの可能性等についての調査研究」(経済産業省)において、csvからSDMXへの変換APIが試験的に提供されたが、政府のe-Stat等のデータがSDMXで提供されるというわけではなく、先の評価結果としても「SDMXは,処理アプリケーションがないことがネックとなり評価は低い」となっていることからわかるとおり、玉子が先かニワトリがさきか、の状況を脱し切れていない。

第1節で述べたように、世界的にオープンデータ・ガバメントの動きが盛んになるにつれて、SDMXのRDF化の要求が立ち上がり、2010年イギリスのサニンデール(Sunningdale)で開かれた英国国民統計局(ONS)主催の、SDMX とセマンティックウェブによる統計データセット公開に関するワークショップに始まり、引き続きオランダのティルブルフ(Tilburg)で開かれたオープンデータ・ファウンデーション(ODaF)欧州2010ワークショップ[6]での協力共同作業の結果として、W3Cワーキングドラフトとして2012年に「RDF データキューブ語彙[7]が提案された。この仕様書を見ると分かるように、RDF データキューブ語彙はSDMXの情報モデルや考え方をそのまま踏襲しつつ、そのRDF化が行われているのが特徴である。

SDMX-MLはXMLベースの構文である。LODで用いられるRDF/XMLもXMLベースのRDF構文であるが、RDFではそこにグラフという意味論が持ち込まれている。XMLの機械可読ではあっても機械理解可能ではないというXMLの欠点を補強しつつ、セマンティックウェブの技術を利用して「データのウェブ」を追求したのがRDFを含むLODであり、我々としては統計情報のLOD化においては当然のことながら、SDMX+RDFとも言えるRDF データキューブ語彙の推進を意図するものである。

5.経済産業省統計データのRDF化における指針

RDF データキューブ語彙のW3Cワーキングドラフト7を参考に、経済産業省統計データの一部をRDF化した試案について述べる。

5.1統計データ数値のアノテーション

表における一つのセルの中の数値、たとえば表1におけるExcelセルI10の値1122817は、それを説明するメタデータが十分に与えられて一つの独立した意味を持った値になると考える。すなわち、この例では表側にある「全国計」「食料品製造業」、表頭にある「従業者数」「実数(人)」はもちろんのこと、表のタイトルに含まれる「都道府県別産業中分類別統計」や統計表全体を説明する「平成22年工業統計表『工業地区編データ 経済産業省大臣官房調査統計グループ』」も重要なメタデータと考える。なぜならば、これらのデータのどれが欠けても、データの意味が一意に決まらないからである。

データは数値であるが、それが意味を持つためには、それが何の数値であるか、単位は何か、スケールがあるとすればそれは何か等々の情報が必要になる。また、「全国計」とは何か、「北海道」とは何かについても、それがRDFとして機械可読のみならず、URIとして機械理解可能でなければならない。前者は統計データ(数値)へのアノテーションであり、後者はそのアノテーションに関するリンクトデータである。

5.2トップダウン注釈かボトムアップ注釈か?

たとえば表1におけるExcelセルI10の値1122817を人が通常読書するように見ていけば、最初に「平成22年工業統計表『工業地区編データ 経済産業省大臣官房調査統計グループ』」を見て、次に「都道府県別産業中分類別統計」を見て、読むべき表を確定したのち、「全国計」「食料品製造業」および「従業者数」「実数(人)」を見てセルI10の値1122817を読むことになる。図3はこれを素直にRDFグラフに表現したものである。

図3 正確でないトップダウン注釈の例

しかし、産業統計にはこれ以外にも「産業編」、「用地・用水編」、「市区町村編」等々の表があって、「工業地区編」においても「都道府県別産業中分類別統計」以外に「工業地区別産業中分類別統計」、「工業地区別事業所数ウェイト順による産業細分類別統計」、「工業地区別出荷額ウェイト順による産業細分類別統計」など、類似の表がある。したがって、たとえば「食料品製造業」のノードは、「平成22年工業統計表『工業地区編』、都道府県別産業中分類別統計」の表以外にもあり、しかも「全国計」以外にも各地区や都道府県にもリンクされなければならない。「平成22年工業統計表『工業地区編』、都道府県別産業中分類別統計」中の「食料品製造業」ノードと「平成22年工業統計表『工業地区編』、工業地区別産業中分類別統計」中の「食料品製造業」ノードを区別するためには、そのノードの名前を「平成22年工業統計表『工業地区編』、都道府県別産業中分類別統計、食料品製造業」と「平成22年工業統計表『工業地区編』、工業地区別産業中分類別統計、食料品製造業」とせねばならず、実用上煩雑すぎて問題がある。ここで、RDFグラフのノードはそれ自身でグローバルに世界において唯一に確定されなければならないということを注意しておく。もしこの二つの「食料品製造業」ノードを「都道府県別産業中分類別統計」と「工業地区別産業中分類別統計」で共有するものとすれば、そこから引かれる二つの表中のセルへのリンクを両者で識別する手段を考えなければならない。これは複数の表を同じ土俵で扱おうとすることから必然的に生じる問題である。RDFではノードは世界で唯一に確定されなければならず、リンクはなるべく数少なく世界に共有されるものを用いるというのがプラクティスである。したがってこれを一般的に解決するには、包括的なノードからリンクされる下流のノードはすべて上流のノードの意味を合わせ持つとせざるをえない。すなわち、図4のようになる。

図4 正確なトップダウン注釈の例

一方、人が通常表を見るようにリンクづけするのではなく、データ中心の考え方でリンクづけする方法もある。図5はそのようなボトムアップ注釈の例である。

図5 ボトムアップ注釈(データ中心注釈)の例

この方法では、セルの値から出発してその属性となるノードにリンクづけしていくが、どんなに類似のセルに該当するノードが多くあっても、その統計数値のアノテーションとなる属性まで含めて完全に同一のものがないかぎり、RDFグラフとしての問題は起こらずノードは識別可能である。そして属性となるノード、ここでは「食料品製造業」とか「都道府県別産業中分類別統計」はそこに数多くのリンクが集中することはあっても名前が煩雑になることはない。RDFデータベース(RDFストア)にはSPARQLというデータベースに対する問い合わせ言語によるデータ検索機能がついているのが通常であり、アノテーションとなる属性を指定して、その属性を持つある数値を検索するということが可能である。我々はここでは、このボトムアップ注釈(データ中心注釈)の方法を採用する。

5.3ノードのURI

どんな対象であってもRDF化において最初に考慮すべきことは、ノードにどういうURIをつければよいかという問題である。RDFグラフにおいてリンク元ノードは必ずURIを持たなければならない。以下にヒースとバイツァーによるLinked Dataの一部を抜粋する。

Linked Dataにおける第1原則はURIがデータセットに含まれる事物を示す名前として使われるということである。ここでいう事物とは、人物、建物、飼っている犬といった現実世界に実際に存在する事物だけでなく、科学的な概念のような抽象的なものも含む。・・・ 事物の名前としてhttp://URIを用いることは、保有するドメインネームを使って利用するhttp://名前空間を決め、Webサーバを運用し、データセットにおいて事物を特定するためにその名前空間内でURIを発行することである。

RDFでは、XML名前空間の規約に従って、URIをプレフィックスとローカル名に分ける。このプレフィックスを名前空間と呼んで、その名前空間の中ではローカル名は唯一でなければならず、プレフィックス+ローカル名であるURI は世界において唯一でなければならない。HTTP URIを発行するには、ドメイン名が必要であり、プレフィックスにはこのドメイン名にかかわるHTTP URI部が一部あるいは全部に用いられる。ドメイン名は自由に取得できる種類もあれば、取得する主体がしっかりとした団体組織でなければならないものもあるが、いずれにしてもドメイン名を所有しコントロールできる組織しかそのドメイン名を含むURIを発行できない。

表側にある「食料品製造業」とか「繊維業」というのは総務省統計局と財団法人統計情報研究開発センターによる日本標準産業分類[8]であり、これらにはコードが振られている。また、「全国計」にはコード00、「北海道」にはコード01が振られているが、コード00は特別としてもこれらは総務省による全国地方公共団体コード[9]であり、本来はこれらの権威ある組織が出しているURIを利用するというのが正しい態度である。しかし、現在そういうものはまだない[10]。そこでこれらについては近い将来本来あるべき姿としてしかるべきURIが発行されることを期待しつつ、その時に遅滞なく切り替えることを考慮して、今はとりあえず発行できる権限を有し、流用できるドメイン名を有しているという条件から仮に経産省オープンデータにおけるURIである、「http://datameti.go.jp/」というURIを利用することにする。すなわち、産業分類については「食料品製造業」(コード09)であれば「http://datameti.go.jp/scheme/jsic/2007/C09」とし、「北海道」(コード01)であれば「http://datameti.go.jp/scheme/standard-area-code/C01」とする。ここでschemeは政府等の発行コードという意図で使っており、jsic/2007は総務省統計局の日本標準産業分類(平成19年11月改定)に基づくコード体系ということを意味する。一方、地方公共団体コード用URIには発行年月日を示す情報がないが、これは年度のないhttp://datameti.go.jp/scheme/standard-area-code/C01を常にカレントで最新のコードを示すものとして、それとは別に改定年度を含むURIを用意して、これが2003年4月1日発行のコードであれば、http://datameti.go.jp/scheme/standard-area-code/ C01000-20030401に完全に等しいものと解釈することを可能にするようなこと(owl:sameAsでリンクする)を前提としているためである。

コードをURIに用いた場合には特に、人への可読性を保証するために、rdfs:labelを用いて、その日本語名や英語名を必ず注釈することが必須である。また、一般にそれが何であるかの人への情報はrdfs:commentを用いて注釈することが望ましい。これらのプロパティではURIではなく文字列情報で注釈することができる。

一方属性にはコードがないものもある。「平成22年工業統計表『工業地区編』、都道府県別産業中分類別統計」とか「平成22年工業統計表『工業地区編』、工業地区別産業中分類別統計」のようなタイトル的なものは、ドメイン名とタイトルを利用してそのままURI化すればよい。たとえば、「http://datameti.go.jp/lod/kougyou-toukei/平成22年工業統計表工業地区編都道府県別産業中分類別統計」などでよいが、URIでなく日本語を含むIRIだと処理系によっては問題が起こる可能性があること、またせっかくコード類についてはこれまですべて英数字で統一されているので、これらのURIについても日本語記述を避けて、「http://datameti.go.jp/lod/kougyou-toukei/h22-k7-data-j-1000」とする。ここでlodは政府等の発行コードではないことを意図しており、h22-k7-data-jは平成22年工業統計表工業地区編をダウンロードしたときのExcelファイル名をそのまま流用し、1000はその中での都道府県別産業中分類別統計のシートの名前である。そしてこのURIのノードにも、rdfs:labelを用いて人間可読な名前を追記することにする。

コードがないものの中でも、データの単位については特別な注意を払うべきである。単位については「RDF データキューブ語彙」においても議論されているので、後述の節にて詳しく述べる。

5.4プロパティのURI

ノードのURI化では独自ドメイン名を含むURI発行が必然的に多くなるが、プロパティ(リンク)のURI化においては、なるべくすでに存在するものを見つけてきて流用するというのがLODのベストプラクティスである。そうすることによって、他者へのリンク、他者からのドメインへのノードへのリンクも格段に容易になる。

RDF データキューブ語彙」では、そこで用いられる名前空間として以下のものを挙げているが、これらの名前空間中の語彙は汎用性が高く、いろいろなところで利用されている。これらの名前空間の語彙のプロパティにはリンク元のノードに型付けの情報があるもの(rdfs:domain定義があるもの)とないもの、またリンク先のノードに型付けの情報があるもの(rdfs:range定義があるもの)とないものがあるが、これらの定義がある場合には特に型付けの宣言をしなくても処理系によっては自動的に型付けされる場合があることを注意しておく。

表1 よく用いられる名前空間と語彙

prefix名前空間URI語彙
rdf http://www.w3.org/1999/02/22-rdf-syntax-ns# RDF core
rdfs http://www.w3.org/2000/01/rdf-schema# RDF Schema
skos http://www.w3.org/2004/02/skos/core# Simple Knowledge Organization System
foaf http://xmlns.com/foaf/0.1/ Friend Of A Friend
void http://rdfs.org/ns/void# Vocabulary of Interlinked Datasets
scovo http://purl.org/NET/scovo# Statistical Core Vocabulary
dc http://purl.org/dc/elements/1.1/ Dublin Core
qb http://purl.org/linked-data/cube# The Data Cube vocabulary

これらの語彙中のいくつかのプロパティについて、以下に説明する。

rdf:type
リンク元(サブジェクトと呼ぶ)ノードがリンク先(オブジェクトと呼ぶ)に型付けされることを述べる。図2の例ではブランクノードはeg:Personに型付けされている。Turtleでは単に「a」と表記される。犬であることを「a dog」というがごとくである。
rdfs:domain
サブジェクトは必ずプロパティでなければならず、オブジェクトは必ずクラスでなければならないが、このプロパティが用いられたときのサブジェクトはこのクラスに型付けされることを述べる。
rdfs:range
サブジェクトは必ずプロパティでなければならず、オブジェクトは必ずクラスでなければならないが、このプロパティが用いられたとき、そのオブジェクトはこのクラスに型付けされることを述べる。
rdfs:subPropertyOf
サブジェクトもオブジェクトも必ずプロパティでなければならないが、サブジェクトのプロパティはオブジェクトのプロパティの持つ性質(rdfs:domainrdfs:range)を受け継ぐことを述べる。
skos:narrower
サブジェクトもオブジェクトも必ずskosで言うところの概念(skos:Concept)でなければならないが、このプロパティのサブジェクトの概念はオブジェクトの概念よりもより狭い(カバーする範囲が狭い)ことを述べる。
skos:broader
skos:narrowerの逆。同様のものにrdfs:subClassOfがあるが、rdfs:subClassOfの意味論は集合論的にきっちり規定されているのに対して、skos:narrowerskos:broaderはそれほどではなく、厳密ではないが使いやすいといえる。
foaf:name
名前を指示するプロパティであり、サブジェクトはOWLのエンティティであれば何でもよく、オブジェクトはリテラルであれば何でもよい。
foaf:gender
性別を指示するプロパティであり、サブジェクトはfoaf:Agentの型でなければならず、オブジェクトはリテラルである。実際には“male”あるいは“female”などの文字列を用いる。
void:subset
データセットについて部分集合を指示する。このプロパティのサブジェクトもオブジェクトもvoid:Datasetに型付けられる。
scovo:datasetOf
このプロパティのサブジェクトはscovo:Datasetに型付けされ、オブジェクトはscovo:Itemに型付けされる。
dc:creator
リソースの作成者を指示する。
dc:title
リソースのタイトルを指示する。

新しい分野においてLOD化をする場合には、どうしても独自のプロパティが必要になり、プロパティのURI発行をせざるを得ないこともある。そのような場合でも、既存でより基本的な名前空間の語彙(たとえば、rdf:typerdfs:subClassOfskos:narrowerskos:broaderなど)となるべく関係づけて定義することで、その意味を人と機械に理解可能にすることができる。

以下は先に述べた都道府県コードのノード(クラスktsh-sac:Prefectureの実現体)にリンクするためのプロパティ(ktsh-sac:refPrefecture)を定義するTurtle記述例である。

ktsh-sac:refPrefecture a qb:DimensionProperty, sdmx:CodedProperty ;
    rdfs:label "reference area (prefecture)"@en ;
    rdfs:label "都道府県"@ja ;
    rdfs:subPropertyOf sdmx-dimension:refArea ;
    qb:codeList ktsh-sac:PrefectureCode ;
    rdfs:range ktsh-sac:Prefecture ;
    qb:concept sdmx-concept:refArea .

ここではこのプロパティはクラスqb:DimensionPropertysdmx:CodePropertyの実現であって、同時にそれはsdmx-dimension:refAreaのサブプロパティであると述べられている。こうすることで、これらのプロパティを処理可能な処理系は、その機能を生かして新たなプロパティktsh-sac:refPrefectureも処理がしやすくなる。

6.RDF データキューブ語彙とSDMX

第4節で述べたように、W3Cでは統計データを含む表構造のデータに適応可能な規約「RDF データキューブ語彙」を提案中である(2013年3月時点ではワーキングドラフト)。この仕様では、ISO標準である統計データの交換規約SDMXの考え方を取り入れ、それをRDFフォーマットとLODで扱うための方法を提案している。表を多次元空間でとらえるデータキューブという考え方、コードリスト、データフローなどという用語は、SDMXからきているものである。

RDF データキューブ語彙」仕様書では、RDF とリンクトデータの手法を用いて統計データを公開可能にすることについて次のような利点を挙げている。

データキューブでは、統計データセットは何らかの論理空間中の点とされる観測値の集まりから構成されると考える。一つのキューブは次元、属性、測度の集まりとして定義される。これらの各要素はデータキューブのコンポーネントと呼ばれる。

RDF データキューブ語彙のUMLクラス図を図6に示す。これはRDFグラフではないことを注意しておく。

図6 RDF データキューブ語彙のUMLクラス図

実際の特定の領域における観測値の次元コンポーネント、測度コンポーネント、属性コンポーネントは、それぞれqb:DimensionPropertyqb:MeasurePropertyqb:AttributePropertyのインスタンスを定義して、それらのプロパティを用いて指定する。たとえば、図5においてブランクノードが観測値であり、今次元コンポーネントとして産業中分類「食料品製造業」を持つとしたとき、ブランクノードからこの次元へのリンクをつけるために、ktsh:refSangyoChuBunruiという名前のプロパティを次のように定義する。

ktsh:refSangyoChuBunrui a qb:DimensionProperty ;
    rdfs:label "日本標準産業分類(中分類)"@ja ;
    rdfs:range jsic:JsicConcept .

ここからktsh:refSangyoChuBunruiは次元コンポーネントのためのプロパティであり、それは観測値の次元としてjsic:JsicConceptの実現を持つということがわかる。産業中分類「食料品製造業」をhttp://datameti.go.jp/scheme/jsic/2007/C09 (jsic:C09)というURIを持つノードとしたとき、これはjsic:JsicConceptに型付けされる。

同様に、次元コンポーネントとして都道府県「全国計」を持つとしたとき、ブランクノードからこの次元へのリンクをつけるために、ktsh-sac:refPrefectureという名前の、次元コンポーネントへのプロパティを次のように定義する。

ktsh-sac:refPrefecture a qb:DimensionProperty ;
    rdfs:label "reference area (prefecture)"@en ;
    rdfs:label "都道府県"@ja ;
    rdfs:subPropertyOf sdmx-dimension:refArea ;
    rdfs:range ktsh-sac:Prefecture ;
    qb:concept sdmx-concept:refArea .

ここでktsh-sac:refPrefecturesmdx-dimension:refAreaのサブプロパティであることが述べてある。SDMX標準には「内容指向のガイドライン (COG)」が含まれる。それは統計上の共通の概念とコードリストを定義しているが、RDFデータキューブにおいても、このSDMXの概念を再利用可能とすることを目的に、以下のものが定義される。

sdmx-concept
COG 定義の各コンセプトに対する SKOS コンセプト[11]
sdmx-code
COG 定義の各コードリストに対する SKOS コンセプトとそのスキーマ[12]
sdmx-dimension
次元として用いられる各 COG コンセプトに相当するコンポーネント・プロパティ[13]
sdmx-attribute
属性として用いられる各 COG コンセプトに相当するコンポーネント・プロパティ[14]
sdmx-measure
測度として用いられる各 COG コンセプトに相当するコンポーネント・プロパティ[15]

さて、図5の数値1122817は従業員数を表す。そこで観測値から数値(リテラル)へのリンクのプロパティとしてktsh:numberOfEmployeeqb:MesurePropertyの実現として次のように定義する。

ktsh:numberOfEmployees a qb:MeasureProperty ;
    rdfs:label "従業者数(人)"@ja ;
    rdfs:subPropertyOf sdmx-measure:obsValue ;
    sdmx-attribute:unitMeasure ktsh:UnitOfPerson ;
    rdfs:range xsd:integer .

この定義は図5のRDFグラフとは一致しないが、RDF データキューブ語彙においては観測値(図5のブランクノード)から引かれるリンクそのものに単位の定義がファセットのようにつくことになっている。ここではsdmx-attribute:unitMesurektsh:UnitOfPersonとして記述してある。

これまでのところで、図5を書き直せば、以下に示すような図になる。

図7 URLによるRDFグラフ表示

ただし、ここでは「平成22年工業統計表『工業地区編』」のノードと「都道府県別産業中分類別統計」のノードが一つにまとめられていること、単位はプロパティktsh:numberOfEmployeesに定義してあることに注意されたい。もし「従業員数(人口比率)」のプロパティがほしければ、単位を変えたプロパティを別途用意する必要がある。

ここでは、観測値は依然とブランクノードになっているが、そしてそのままでもRDFグラフとしての問題は起こらないが、LODベストプラクティスとしては、ブランクノードの仕様は避けるべきとされており(処理系での扱いが難しくなり、かつ外から直接このノードを指定することができない)、適切なURIを付与することが望ましい。

7.おわりに

統計データをRDF化してLODとして公開するためのプラクティスについて、報告した。SDMXはすでにISO標準になっているが、「RDF データキューブ語彙」は現在ワーキングドラフトであり、その詳細は今後変更される可能性がある。この報告の範囲では特に問題は起こっていないが、今後実運用が進むにつれて、修正追加の可能性はある。我々も統計データのLOD化について大いに努力する所存である。

なお、「RDF データキューブ語彙」の統計データの特徴として、多次元空間の中である次元を固定せずにデータ部分集合を定義したり取り出したりするためのものとして、スライスというものがある。いわば、表の行や列に相当するものであり、表構造の見方を一般化したものであるが、本報告ではこのスライスは用いていないことを注意しておく。

参考文献

ヒース, バイツァー:Lined Data, (監訳武田) 近代科学社 (2013)

[1]
以下を参照されたい。http://oecd.270a.info/http://fao.270a.info/
[2]
詳しくは [ヒース, バイツァー, 2013]を参照のこと。
[3]
たとえば以下を参照。http://www.kantei.go.jp/jp/singi/it2/cio/dai19/19siryou02_06.pdfhttp://www.nstac.go.jp/services/anonymity-shugyo.html
[4]
http://sdmx.org/wp-content/uploads/2012/11/SDMX_2-1_User_Guide_draft_0-1.pdf
[5]
以上はhttp://circa.europa.eu/Public/irc/dsis/edamis/library?l=/reference_documents/general_information/sdmx_basic_pagepdf/_EN_1.0_&a=dより。
[6]
http://odaf.org/events/odaf_europe_2010.php
[7]
http://www.w3.org/TR/vocab-data-cube/
[8]
http://www.stat.go.jp/index/seido/sangyo/19index.htm
[9]
http://www.soumu.go.jp/denshijiti/code.html
[10]
総務省は独自のドメイン名soumu.go.jpを持っているが、これらのコードについて世界で唯一となるURIを発行していない。ただし、市区町村コードのURI化は現在策定中である。
[11]
http://purl.org/linked-data/sdmx/2009/concept
[12]
http://purl.org/linked-data/sdmx/2009/code
[13]
http://purl.org/linked-data/sdmx/2009/dimension
[14]
http://purl.org/linked-data/sdmx/2009/attribute
[15]
http://purl.org/linked-data/sdmx/2009/measure