|
（約3000字）
近年、ビッグデータでオープンデータ（linked data）でIoTだといわれます。[2993]の続きです。
・Wikipedia「Linked data」
http://en.wikipedia.org/wiki/Linked_data
・Wikipedia「Internet of Things」
http://en.wikipedia.org/wiki/Internet_of_Things
・東京メトロ「オープンデータ活用コンテスト編」（2014/9/11）
http://www.tokyometro.jp/corporate/newsletter/pdf/newsletter20140911_contest.pdf
> 今回初めて東京メトロ全線の列車位置、遅延時間の情報（方向、列車番号、列車種別（各停、急行、快速等）、始発駅・行先駅、車両の所属会社、在線位置（ホーム、駅間の２区分）、遅延時間（５分以上の遅延を「遅延」として表示））を、すでに東京メトロのホームページで公開している時刻表、乗降人員、バリアフリー施設等の情報に加えて、オープンデータ化します。
・東京メトロ「「オープンデータ活用コンテスト」応募状況編」（2014/12/2）
http://www.tokyometro.jp/corporate/newsletter/2014/85.html
http://www.tokyometro.jp/corporate/newsletter/article_pdf/metroNews20141202_l1.pdf
> ※これらのほか、募集期間中にご要望の多かった、路線・駅のナンバリングマークのデータについても、追加で公開いたしました。
・ITPro「東京メトロ「オープンデータコンテスト」、281件の応募」（2014/12/2）
http://itpro.nikkeibp.co.jp/atcl/news/14/120202094/
> 応募アプリは、Google Play、App Store、Windowsストアのほか、応募者が設定した任意のWebサイトで公開されている。また、YouTubeで「東京メトロオープンデータ活用コンテスト」と検索すると、応募者が制作したアプリの紹介動画を見られる。同社の開発者サイトからもダウンロードのリンク先をたどれる。
> 同社は2015年1月下旬に審査会を行い、2月中旬に表彰式を行う。
> 東京大学大学院情報学環教授の坂村健YRPユビキタス・ネットワーキング研究所所長ら5人が審査員を務める。
いきなり余談で恐縮ですが、東京メトロの「ニュースレター」の一覧ページがPDFだけだったものが、最近はHTMLを挟むように変わったのも、あるいは開発者コミュニティからのフィードバックを受けてのものなのかもしれません。
※リンク先のタイトルが簡易に「抽出」できないのは面倒ですからね。このフォーラムではPDFには未対応です。
応募作については賞が決まってから見ようと思っています。関係者や応募者の方には申し訳ないですが、いかにも「アプリ」なアプリしか出てこないだろうと、タカをククっております。
・「高を括る」
http://thesaurus.weblio.jp/content/%E9%AB%98%E3%82%92%E6%8B%AC%E3%82%8B
※いえ、ばかにしているわけではないんです。きちんと取り組んで、きちんと革新的なサービスやアプリを生み出すのは非常に難しいことで、それをわずかばかりの賞金で買い付けようだなんて、なんてムシのいい、と感じています。
・「虫のいい」
http://www.weblio.jp/content/%E8%99%AB%E3%81%AE%E3%81%84%E3%81%84
本題としては、いままで非公開だったデータを単に公開したからといって「オープンデータ」と呼ぶのはいかがではないだろうか（そんなことでよいのだろうか、の意）、という話です。
※かなり否定的な話ですので応募者の意欲をそぐかもしれず、コンテストの応募締切を過ぎるまで出すまい、と思っていました。とはいえ、審査には影響しないことでしょう。
・（1）そんなデータはいらない
・（2）データは「人が見る」ものでなく「自動的に使われる」もの
・（3）データからデータを作り出す
（1）ですが、時刻表がないと利用できないような、待ち時間の長い、あるいは時隔がランダムなダイヤは、都市交通としては失格といえましょう。同様に、乗車位置（乗車口、号車）を気にしないと乗車できない（「おもてなし」と特急列車[2968]など）のも、ユニバーサルデザインにはほど遠い状況といえます。データとしてはあってもよいですが、いわば「お客様」自身が「そんなデータはいらない（なくても大丈夫）」と感じられるような環境を作っていくことが重要といえます（メタ認知[2547]など）。そこを、「気の利いたアプリひとつ」で何とかしようというのは、実際、何とかならないこともないでしょうが、根本的には無理のある話です。何かに何かをつけたしていくというのは、どこかで必ず無理が出ます（[2811]など）。
（2）は、これこそがオープンデータ、Linked dataならではの利点です。マシンリーダブル（machine-readable）ともいいますが（[2991]）、プログラム上で「気の利いた抽出処理」をすることなく、最初からデータとして読めるというのが重要なことです。そして、これは最終的に（プログラムの出力として）も、マシンリーダブルなデータとして出ていく、それがまた別のプログラムによって利用されていくという、人手を介さないデータの流通があってこそ、さらに活きてくるのです。「アプリ」と称するものは、要はユーザーインターフェース（UI）であって、そこから先にデータの流れはありません。ユーザーの操作や入力をサービス側にフィードバックさせて云々するなど、データの流通が終わらないような活用法を生み出せてこそナンボだと思います。そのフィードバックされて生まれたデータがまた、自社のサービス内で閉じてしまって外には出ていかないとなれば、それもケチな話です。他には、例えば鉄道会社が公表した乗降人員のデータが、Wikipediaに自動的に書き込まれるような仕組みを作ることも、データの流通の一例です。
（3）は、（1）を言い換えたような話になります。「遅れ時分」のデータなどいらないんだ、そんなもの（※）、ということで、データを総合的に判断して「いつも通りに出かけてよい」か「別の路線に乗ったほうがよい」かをユーザーに提示するような、一段上の処理ができてこそ、プログラムらしいプログラムといえましょう。計画ダイヤ上、遅れ時分が75分だったとしても、1分後に所望の行き先の電車が到着して、発車後も駅間停車したりしなければ、それでいいんです（[2531]など）。もし、これを実現しているアプリがあれば、迷わずグランプリに選びたいところです。
※逆に、そこまで至っていない「いかにもなアプリ」しか応募されなかったのであれば、グランプリは「該当なし」にすべきであるとも思います。どんなアプリに賞を出すか（出さないという判断ができるか）によって、主催者や審査員のレベルもまた、シビアに評価されてしまうのです。いい加減な審査を1回でもしてしまうと、「これくらいでいいんだ」という評価が定まってしまい、それより高度なコンテストは実施できなくなってしまいます。
| 
