「ファクト」のLODから「個性」のLODへ：自分史や見解・判断の公開

Webの生みの親であるティム・バーナーズ＝リーはLinked Open Dataに関する4つの原則を定義している。

1. あらゆるデータの識別子としてURIを使用する。
2. 識別子には（URNや他のスキームではなく）HTTP URIを使用し、参照やアクセスを可能にする。
3. URIにアクセスされた際には有用な情報を標準的なフォーマット（RDFなど）で提供する。
4. データには他の情報源における関連情報へのリンクを含め、ウェブ上の情報発見を支援する。 

この形式で、現在、様々なタイプのデータがLODとして公開されている。これらのデータの多くは「ファクト系」のデータである。例えば、総務省統計局の人口動態データ等はその典型例である。LODでは、様々な分野のデータが公 開されることで、それらを融合したアプリケーションが期待される。LODチャレンジの目的の一つは、多分野・異分野のLOD公開データを融合した新しいア プリケーションの模索であろう。

一方で、FacebookやTwitterに代表されるSNSの発展により、「個人の発言」がインターネットという公的な場に向けて発信することが容易に、かつ日常的になっている。これらの情報はインターネット上に保存され機能的にはURIで再現できるため、LODの条件を満たす。すなわち、SNSによる個人発信情報もLODになりえる。

しかし、一般にはSNSによる個人発言はLODとして利用されることは少ないであろう。その一番の理由は、情報の価値である。 個人発言でLODとして利活用される価値のある情報はあまり多くないと思われる。

ここで提案するのは、データと連動した個人発信情報である。例えば、あるデータにおいて研究者が発見した事象、すなわちデータに対する個人の見解といったものである。単純な個人発言と異なり、ファクトをベースとしたデータに紐づいた発言は、そこに価値が発生する。実際、それを理論立てて構成することで文書化したものが学術論文である。学術論文は、原則的には単数または複数の著者が記述した「個人見解」である。しかし、再現性や査読による信頼性といった「客観性」が高いために、LODとしての価値が生まれる。

データと連携した個人発言（すなわち個人見解や個人判断）のLOD化として重要なのは、それがが宇術論文と同じように「客観的な検証可能である」ということだ。もし、特定のデータを切り出して、それにコメントを付与してLODとして公開するのであれば、本質的にはSNSによる個人発言のLOD化と変わらない。そこには、客観的な検証方法がない。

そのために、ここでは「アプリケーション上で表示されるデータをURIとしてLOD化する」という方法を提案したい。具体的なアプリケーションを使って、この方法を説明する。

現在、私の研究室では、Webで時系列データを閲覧するためのアプリケーションSTARStouchを開発しており、STARStouchによりいくつかのデータを公開済みである。例えば、我が国の科学衛星であるGEOTAIL衛星データをSTARStouchにより公開している（こちら）。データの閲覧方法はHELPを見ていただくとして、このツールにより科学衛星データを自由に閲覧できる。このアプリケーションを使って、「アプリケーション上で表示されるデータをURIとしてLOD化する方法』を説明したい。

 

 この図は、STARStouchにより公開されているある時刻のあるデータである。このデータでは、100kHzのあたりに頻繁に出現するスペクトル波形がある（TYPE III太陽バーストという）。私が、「TYPE III太陽バーストが頻発する現象を発見した！」と、この画像をLODとして公開するとする。（場合によっては、Twitterでつぶやくというのでもよい。）

この分野の専門家以外は、その事実を信じるしかない。データを閲覧する方法も知らないユーザとしては、専門家の見解を検証する手立てがない。

では、こちらはどうだろうか。 上の図と全く同じデータがWebブラウザ上に表示されているはずである。そして、こちらの場合は、アプリケーション上にデータが表示されているので、容易に時間方向にデータをずらす（時間軸をずらす）ことで他の時刻のデータを確認することができる。（ぜひ、試していただきたい。マウスでスライドするだけなので簡単に操作できる。）

たとえば、こんな風に上記の時刻をズームアウト（長い時間で表示する）すれば、上記の時刻が特別な時刻ではなかったことがわかる。（同じような現象が定期的に発生している。）

それによって、実は、TYPE III太陽バーストはその前後の時刻にも頻出しており、上の画像の時刻が特別というわけではないことが分かる。つまり、専門家である私の見解は、専門家でなくても容易に「誤りだ」と見抜けるわけである。

個人の見解を、信頼できる再利用性の高いLODとして公開することは、これまでは難しかった。本提案手法によって、ファクトデータをLODとして公開するという発想から、ファクトとコメントをセットにすることで客観性の高い見解をLODとして公開にするというこれまでにはなかったLODの活用が期待できる。

この発想をさらに広げると、「データ（ファクト）」と関連する情報を一つのアプリケーション上に併記して、それをURIで表すことでLOD公開が可能である。

例えば、この図では、データ（カラーの部分）とその期間のデータを対象として出版された学術論文（図の一番下）がWebアプリケーション上に併記されている。このURIを上記と同じ方法でアプリケーション上で公開することで、データをURIで公開するだけではなく、データとそれに付随する情報（この場合は学術論文情報）を公開できる。

データと付随する情報をセットで、アプリケーション上でLOD公開する手法は、さらに様々な発展がきたいできる。たとえば、データ（ファクト）と個人史（個人情報）をセットで公開することができる。たとえば、下図は総務省統計局が公開している携帯電話の普及数を示すグラフである。このデータはLODとして数値データとして公開されているが、これを上記の方法によりアプリケーション上で表示できる。

さらに、この図の上に個人情報を掲載することで、公開データを用いたLOD情報に個人情報を重ねて表示することができる。例えば、以下の画像は、携帯電話普及グラフの上に自分が保有してきた移動体通信端末（携帯電話）情報を重ねてアプリケーション上に表示している例である。



個人の情報を作成することは手間がかかるが、上記の場合にはYahooやGoogleのカレンダーで利用されているiCalendar形式データをアプリケーションの読み込むことで、容易に実現できる。LODとして公開されている元の数値データ（総務省統計局）ではこのようなことを実現するには手間がかかるが、WebアプリケーションをLOD化すること飛躍的に簡単に、個々人が自分の情報とLOD公開情報を重ねることができる。

上記のアプリケーションの場合は、必要に応じてファクトの上に個人情報（個人史）を重ねた状態を、さらにLODとして容易に公開できる。この場合には、そのLODの上に、さらに別の個人が情報を重ねて表示できる。一つのファクトの上に、多くの個別の情報が重なり、LODを用いたLODが実現するわけである。これは、LODによる集合地の形成にも結び付く可能性を秘めている。



3次元空間での科学データとソーシャルデータの融合

Google Earthは、様々な地球環境情報を３次元空間に表示できる。例えば、図１～図3は大阪大学に設置されたNICT（情報通信研究機構）の気象レーダが観測した大阪平野の降雨分布である。時々刻々変化する大阪平野の局所的豪雨の状況を3次元的に表示している。一般の雨は例えば大阪平野を覆うように広く降るが、近年、図１のように限られてたエリアで数㎞～数１０㎞にわたり強く降る局所的豪雨（いわゆるゲリラ豪雨）が注目されている。

図1　大阪平野の局所的豪雨（真上から見た図） 

図2　大阪平野の局所的豪雨（斜め上から見た図）

図3　大阪平野の局所的豪雨（横から見た図）

このように、気象センサーや環境センサーの情報をリアルタイムに3次元空間上に可視化することは、個人が特定の位置（大阪平野の特定の場所）から見ていても理解することが難しい「空間情報」を把握するためには有効である。

ここで興味深いのは、気象レーダによる降雨観測は、あくまで「上空の雨」を観ているということである。一般には、気象レーダは数㎞以上の高度の降雨を観測する。言い換えると、「気象レーダで雨が降っているからと言って、必ずしも地上で雨が降っているとは限らない」わけだ。

そこで、地上の降雨を測定するのが雨量計である。雨量計としては、図4に示す気象庁のAMeDAS（アメダス）が有名であるが、実は高速道路や鉄道などにも設置されている。民間では、NTT DocomoがAMeDASとほぼ同じセンサーを国内に広く展開している。AMeDASは国内に1200点以上、NTT Docomoは4000点の雨量計を展開している。

図4　気象庁AMeDAS（アメダス）の配置図

国内に1000点以上配備されている気象庁の雨量計であるが、実はその数は十分ではない。図5は、図1～図3の気象レーダによる局所的豪雨とAMeDASの雨量計の配置を比較している。これを見ると、雨量計の数（配置）は局所的豪雨をとらえるには十分ではないことがわかる。実際、図７の２０１２年７月２６日の例でも明らかである。気象レーダは、京都・宇治近郊の局所的豪雨（１０㎞以下の空間スケール）をとらえているが、AMeDASで見るとこの日は「晴天（雨はほとんど降っていない）」のである。

図５　気象レーダによる局所的豪雨とAMeDAS雨量計配置（１）

図６　気象レーダによる局所的豪雨とAMeDAS雨量計配置（２）

図７　２０１２年７月２６日のAMeDASデータと気象レーダデータ（大阪大学）

このように、各種のセンサー情報をデータベース化し、分析・可視化する技術はビッグデータ技術の中心の一つとして注目を集めているが、「データは必ずしも事実を反映しているわけではない」のである。LODを考える際、データの信頼性（言い換えるとデータの適用範囲）を十分に理解しないと、誤った解釈や判断につながることがある。

雨量計の個数は数千点であるが、一方で日本人の数は１億２千万人である。日本人が何らかのセンサーの役割を果たすと考えると、強力なセンサーとなることがわかる。いわゆるヒューマンセンサーという考え方である。近年、ビッグデータ処理において、このヒューマンセンサーを考える事例が多い。。ここでは、ソーシャル情報をヒューマン気象センサーとして、既存の気象センサーデータと融合して可視化することを提案する。

気象（降雨・豪雨）を扱うことができるヒューマンセンサーデータ（ソーシャル情報）として、Twitter情報を考える。Twitter情報には位置情報・時刻情報が含まれるため、センサー情報を3次元時系列空間で可視化した際に、同時に3次元時系列空間に併記することができる。ここでは、特定の日時で大阪平野またはその近郊において「雨」という文字列を含むつぶやきをした端末（多くはスマートフォン）の位置情報を、その時刻に従って３次元空間に可視化する。

可視化結果が図８～図１１である。これらの図は、時々刻々変化する局所的豪雨の様子を示しているが、見事なまでにつぶやきの領域が気象レーダによる降雨領域の移動と一致している。

図８　局所的豪雨観測（気象レーダ）とその時刻の「雨」を含むTwitter発信位置（１）

図９　局所的豪雨観測（気象レーダ）とその時刻の「雨」を含むTwitter発信位置（２）

 図１０　局所的豪雨観測（気象レーダ）とその時刻の「雨」を含むTwitter発信位置（３）

図１１　局所的豪雨観測（気象レーダ）とその時刻の「雨」を含むTwitter発信位置（４）

もちろん、Twitter情報（ヒューマンセンサー情報）にはノイズが必ず含まれる。雨が降っていなくても「雨が降っている」と偽ることは容易である。また、「雨宮さん（人名）」や「雨見山（群馬県）」などの固有名詞が含まれることもある。しかし、上記の通り、ヒューマンセンサーの魅力はその数であり、ノイズ（SN比）を考慮しても有効に機能することがある。

気象データやTwitterデータの多くは、残念ながら現在はLOD公開されていない。しかし、これらの情報が広くLOD化されることにより、可視化技術と組み合わせることで「地域可視化」が進むであろう。LODの重要な目標は、「データの適用範囲」に配慮しつつも、制限なくできるだけ多くのデータがLODの形で公開されることである。