子育て、介護でいらなくなったモノの交換（売買）、リアルタイム性重視、地域のコミュニティカフェ、空き家でうけわたしスマホで管理。

空き家を大活用アプリ。１人暮らしのおばあちゃんも無くなり空き家。管理大変で草がボーボーとなっている。だれが使ってくれたらなーというニーズと、若い家族など家を買いたいけど、転勤族であったりお金が足りない人をマッチングするアプリ。

1.概要 従来のLODを物理世界とつなげるプラットフォーム「サイバー・フィジカルLOD:CPLOD」を提案します。CPLODは、LODにつぎの機能を加えたものです。 ・物理世界との双方向接続 ・リアルタイム性 ・秘密の制御 これらの機能によってLODを身の回りのあらゆる情報処理へ適用できるようにし、クラウド、モバイル、IoTをオープンな仕様で連携させ、少子高齢化、地球環境の変化などの課題にITを活用できるようにします。 2.セールスポイント：ITデバイスの総連携によりITの可能性を使い切る 現在のITデバイス（クラウド、モバイル、IoTなど）は、十分な発展をとげ、様々な問題を解決するツールとなる可能性を秘めています。たとえば、個人の身の回りのデバイスを連携させれば、社会や家族の負担を少なくしながら高齢者を見守り、介助するようなシステムを作れるでしょう。 あるいは、市町村、都道府県、国といった様々なレベルでリアルタイムに地域の状況のセンシングを行って情報を共有できるシステムや、全住民が参加するコラボレーションツールのようなシステムを作ることができるでしょう。縮小していく経済に対応しながら、資源やエネルギーを効率化し、拡大する失業、高齢化、少子化などの対策をとるツールとするといったことが可能となるはずです。 しかし、現在このようなシステムはまだありません。その原因は、任意のデバイスや人を連携させることができないという、分断化にあると考えます。ITの分断化には３種のタイプがあります。 (1)APIやプロトコルなどの、規格の乱立による分断 企業やグループによる囲い込みや、異なる目的のプロトコルの存在によって、ユーザが自分の使いたいデバイスを自由に連携させることができません。特定メーカーのデバイスとそのメーカーの認証を受けたデバイスを連携させてスマートハウスを実現するといった試みは存在します。しかし、あらゆるメーカーのあらゆるデバイスを連携させることはできません。 (2)規格の不在 IT化を推進するメーカーやユーザがいない分野や、異なる分野をつなぐ用途には、IT化のための規格を作る動きがありません。たとえば高齢者の生活を支えるために、介護サービス産業・行政・ボランティア・ご近所・出入り業者などの、地域社会の様々なステークホルダが現場で連携するようなITシステムを作ろうとしたとき、様々なシステムを連携させるための規格を作るのは誰でしょうか。本来は現場でシステムを作る人たちが規格を作ることができれば理想的です。しかし、規格を作るというスキルは現状では期待できません。 (3)世代交代（陳腐化）への対応 APIやプロトコルは新しい技術が生まれるたびに更新され、その周期は人の一生や人の世代交代といった時間軸に比べれば著しく短いものです。黎明期をとっくに過ぎたITですが、まだ数十年以上にわたる連続運用には耐えられません。過去と未来の連携を可能とする必要があります。 たとえば、つぎのようなユースケースを実現可能としなければなりません。 ・10年後のシステムに対して、家屋の10年点検時に確認すべき項目を指示する。 ・築20年のスマートハウスシステムに、新しいデバイスを接続する。 ・30年後のシステムが現在のセンシングデータを参照する。 そこで私たちは、LODのアーキテクチャを使って、この分断化の問題を解決し、あらゆるITデバイスを連携させることと、この目的のために、LODに不足している機能を追加することを提案します。 3.提案者 先端IT活用推進コンソーシアム（AITC） ビジネスAR研究部会（http://aitc.jp/wg/ar/） 連絡先：リーダー　大林勇人、サブリーダー　中川雅三、吉田光輝 4.実装方法 4.1.物理世界との双方向接続 CPLODでは、デバイス上のサービスをRDFデータにマッピングし、RDFデータを書いたり読んだりすることでサービスを利用できるようにします。 メモリマップドI/Oの考え方を、RDFデータに適用するというアイデアです。 ・サービスのユーザがサービスへのリクエストをあらわすデータをRDFストアへ書き込むと、サービスの提供者はそれを読み出して実行する。 ・サービスの提供者がサービスの結果をRDFストアへ書き込むと、サービスのユーザがそれを読み出して利用する。 単純な例を示します。 ・指定した場所の照明をオン・オフする 照明のユーザは、つぎのような形で居間の照明を"ON"とするリクエストをRDFストアに書き込みます。 DELETE{ ?sw :制御要求 ?current . } INSERT{ ?sw :制御要求 "ON" . } WHERE { ?sw :所在 :居間 . ?sw :種別 :照明スイッチ . OPTIONAL { ?sw :制御要求 ?current . } } 照明制御を提供するサービスは、制御要求データを監視し、値が変化したときに、その値を照明スイッチへ反映します。 ・指定した場所の温度を取得する。 温度計のユーザは、つぎのような形で温度データを取得します。 SELECT{ ?temp } WHERE { ?sensor :所在 :居間 . ?sensor :種別 :温度計 . ?sensor :測定値 ?temp . } 温度計のデータを提供するサービスは、温度データを取得するたびにRDFへ値を書き込みます。 語彙とデータ構造を定義してゆくことで、もっと複雑なサービスのインタフェースもRDFデータとして定義することもできます。たとえば、つぎのようなリクエストをSPARQLで表現できるだろうと考えています。 ・Aさんが歩いている付近の街灯を点灯する。 ・河川が氾濫の警戒水位に近づいている地域の低地にある家に住んでいる住人全員へ、警戒を促すメールを送信する。 4.2.APIにLODを使うメリット LODによってつぎのようなメリットが得られ、先に述べた3つの分断化をすべて解決することができます。 (1)プロトコル、データ構造、メタデータの記述方法を統一できる。 プロトコルはHTTP、語彙はRDFで統一できます。 メタデータを記述するオントロジーを定義することで、データ構造や機能の意味も機械可読な形で記述可能です。このことにより、つぎの利点が生まれます。 1)LODへアクセスするライブラリを用意するだけで、任意のOS、任意のプログラミング言語からAPIを利用することができる。 既存のAPIの多くは、特定のOSや特定の言語にしか対応していません。 2)世界中のすべての情報やサービスを扱える。 IRIを使って独自の語彙を作り、オントロジーを定義することで、あらゆる用途に応用できます。 既存のAPIについて、LOD へマッピングする語彙をそれぞれが衝突しないように定義することができます。 3)異なる用途のために作られたAPI群を同時に利用することができる。 既存のAPIはOSや言語に依存するため、異なるOSや言語で実装されたAPIを同時に使うことができません。 　　 (2)現場からのボトムアップによる規格化が可能である。 これまでの規格は、少数の企業やグループが時間をかけて作るトップダウンな方式で作成されてきました。 このような作り方では、実社会の多様な活動分野それぞれに対応したり、必要なときに迅速に対応できるような規格化は不可能です。実際の問題解決を行う現場の人々が試行錯誤しながらAPIを作り、様々な提案から有力なものが進化していって「規格」となるという、ボトムアップな規格化（デファクトスタンダード）が現実的な手段となるはずです。 LODでは名前空間を厳格に区別し、語彙を厳密に定義できます。現場の人々は、LODでAPIを設計することで、規格の記述が完了します。LODを使うことによって、多様な規格の乱立という初期状態を整然と実現し、それらを統合したり、変換したりしていくつかの規格に収束させることができるようになります。 (3)IRIで名前空間を分けることができるため、世代によって変遷するAPIを共存させることができます。 機械可読なメタデータにより、異なるAPIや、異なる世代のAPIの間の自動変換技術を開発することもできるようになります。LODは十分に抽象化され、厳密に定義されているため、数十年後でも現在定義したデータを容易に扱うことができるはずです。 4.3.LODに欠けている機能の追加 これまでに述べたことを現在のLODで実現するには、つぎの課題があります。 (1)リアルタイム性 論理的には、上記の方法だけで、既存のRDFストアとSPARQLを使って任意のAPIを実現することができます。しかし、SPARQLクエリの処理オーバヘッドが大きく、システム負荷を抑えながら、リクエストへの応答性能を確保することが困難です。例えば、先述の「居間の照明制御」の例では、照明を制御するデバイスは、自分宛の制御要求が書き込まれるまで、SPARQLクエリを繰り返し実行しつづけなければなりません。 多数のデバイスをRDFストアに接続したとき、膨大な量のSPARQLクエリが繰り返し実行されることになり、大きな負荷が生じ、応答性能も低下することになります。 (2)アクセス権限の制御 LODでは、すべてのデータを公開します。しかしすべてを公開する前提では、あらゆるサービスをLOD化することはできません。プライバシー情報へのアクセスや、セキュリティ確保が必要なサービス利用では、個別のデータやサービスを、相手によって公開したり非公開としたりする制御をできるようにする必要があります。 CPLODでは、上記の課題をLODにふさわしい形でRDFストア機能を拡張します。 (1)WebSocketによる、RDFデータ変化の通知 RDFストアにWebSocketインタフェースを設けます。 ・読み出しインタフェース：指定したRDFデータ項目の変化を通知する。 ・書き込みインタフェース：指定したRDFデータの書き換えを通知する。 サービス提供デバイスは、WebSocketによってRDFストアへ接続し、リクエストの監視と、提供データの更新を行うことで、リアルタイム性を確保します (2)アクセス権限を制御するメタデータ設計及びSPARQLの改造 すべてのRDFストア内データについて、個別にアクセス権限を設定する語彙を定義し、その語彙にしたがってアクセス許可を制御する機能をSPARQLクエリエンジンに実装します。 具体的にはRDFデータにアクセス権限を示すデータを付加してアクセス制御します。アクセス権限を示すデータ自身もRDFで記述します。 ・クラスのプロパティに権限を設定 ・インスタンスのプロパティに権限を設定 ・IRIにアクセス権限を設定 といった記述方法を定めています。 アクセス権限はつぎの3レベルです。 ・レベル1:外部へ公開可 ・レベル2:推論に利用可だが、外部への公開不可 ・レベル3:推論に利用不可かつ、外部へも公開不可 5.進捗状況及び今後の予定 開発シナリオとして、2段階を予定しています。 (1)概念を実証するために、モックアップを作成する。 モックアップでは、既存のRDFストアをそのまま使い、RDFストアへのラッパーとしてCPLODの機能拡張を実装します。ラッパーによる実装はつぎの欠点がありますが、実装が比較的単純で、動作を短期間に評価できるメリットがあります。 ・最高のパフォーマンスを得られない：ラッパーが外部からのSPARQLリクエストを解釈し、既存のRDFストアへのSPARQLリクエストを自動生成します。SPARQLの解釈や生成のオーバヘッドが発生します。 ・完全なアクセス権限制御をできない：プロパティパスなどのRDFストア内部で多重のリンクをたどる処理が実行されるとき、途中のリンクに対する権限チェックを実装することができません。 (2)本格的な実装を行う。 SPARQLクエリの処理エンジンを、CPLOD仕様へ改造します。 現在は(1)のモックアップが、一部の動作を開始したところです。 詳細は以下の「6.現時点のモックアップ「空間OS」」に記します。

海老名市長選・海老名市議選 全立候補者のマニフェストをワードクラウドで見ることができるアプリです。

秦野市議選 全立候補者のマニフェストをワードクラウドで見ることができるアプリです。

埼玉県知事選の立候補予定者のマニフェストをワードクラウドで見ることができるアプリです。

2013年、2014年に引き続き、オープンデータ＆オープンイノベーションで通勤問題解決を目指します。 今年度は昨年実施した「鉄道事業者をまたがる駅のバリアフリールート検索」に継続着手します。 1.プロジェクト名を正式に決定しました。 プロジェクトTRAIN：Tsukin Rakuraku Assist INformation 2.問題意識 ※昨年度のものを継承します。 現在、既に鉄道各社は自社の駅バリアフリーマップを公開していますが、二つの大きな問題があると考えています。 (1)マップを見ても、バリアフリーなルートを探すのが大変難しい。 ・（例えば車椅子が通れない）段差がどこにあるのかがわからない。 ・どのルートが該当するかもわからない。 ・複数のルートがある場合でも、より負担の少ないルートがわからない。 (2)鉄道会社ごとに作られているため、ターミナル駅で鉄道会社をまたがるバリアフリールートがわからない。 ・例えば、渋谷駅の「井の頭線の開札」から「副都心線の開札」までのバリアフリールートは、このまま誰も何もしないと永遠に計算できない可能性が高い。 3.解決策 ※昨年度のものを継承します。 上記の問題を解決するため立ち上がりました！まずはターミナル駅で、複数の鉄道会社の改札間のバリアフリールートを検索するプロトタイプを開発します。 プロトタイプ完成後、メンバーを増やしつつ楽しくフィールドワークやデータ整備を進めたり、鉄道会社にアイデアをPRしつつ、カバーする駅を広げていきます。 データトポロジについては、昨年は独自設計でしたが、今後の普及展開や他団体との連携等を見据えて、国土交通省「歩行空間データネットワークデータ整備仕様案（平成22年9月版）」のデータトポロジを採用することにしました。 4.参加メンバー（敬称略） ・年岡晃一 ・木田和海（リーダー） ・浅野優 ・板垣真太郎 ・植田順 ・大林勇人 ・小副川健 ・東修作 ・宮武志保

外国人旅行者の函館観光を支援するまちあるきアプリを開発しています。外国人旅行者にとって重要な情報である、多言語対応されている観光スポット情報、無料Wi-Fiスポット情報、外国人旅行者向けのまちあるきコース情報を組み合わせたサービスを提供することで、外国人旅行者の現地での観光を支援します。

大災害時に役立つ避難誘導システムのアイデアです。電話回線やwifi等が断絶していても、GPS等で位置情報を把握し、定期的に同期して取り込んでいた避難所、支援所の位置データ等に基づき、誘導してくれます。

LODチャレンジ応募のために、検討中。

【概要】 こども達が安心して暮らせる街作りの一環として、 近所、通学路付近の「こども110番の家」の位置情報やその付帯情報(店の営業時間など)を可視化するアイデア。 親子で近所を散歩しながらスマホを利用して上記情報を閲覧し、「こども110番の家」の場所を確認、そしていざという時の対応を親子で確認するためのツールとしての利用を想定。 【現状の課題】 1.全国的にこどもを狙った犯罪が増えている。 2.近所のどこに「こども110番の家」があるのか知る術がない。 　①こどもも含め、近隣住民に聞いてみても 　　「聞いたことはあるが、どこにあるかは分からない」とのこと。 　②Webで検索しても見つからない。 3.日頃から練習、シミュレーションでもしていない限り、 　こどもはいざというときに「こども110番の家」のお店、住宅に逃げ込みづらい。 4.情報の更新頻度が低い 「こども110番の家」の看板のあるお店でその登録店舗の所在が 　記されている地図(紙)を発見！しかし平成２２年版だった。 　以降、更新されていないとのこと。 ※ご近所の「こども110番の家」のお店の方や、知り合いの小学校の先生、新潟市内で小学生ぐらいの子供を持つ親にヒアリングさせていただいた結果をもとにしています。 ※2016/1/16時点、ヒアリング数はまだそんなに多くありません。市内/市外にかかわらず「うちの地域はこういう運用でうまく情報共有できてるよ」などの情報、ご意見等ありましたら是非ともいただければと思います。 【データセットに関するアイデア】 1.「こども110番の家」の位置情報のデータ化 2.登録形態は店舗、住宅など。店は店名までデータとして持つが、 　住宅の場合は位置情報までとする(表札情報まではデータ化しない)。 3.店舗の場合は営業時間、定休日情報も持つ。 4.店舗の場合は、平均常駐店員数、防犯係有無、防犯カメラ有無など 　最低限の防犯体制の情報もあるといい。 5.「こども110番の家」だけでなく、後述のセーフティーステーション 　などの類似活動,施設も掲載。 【アプリに関するアイデア】 1.「こども110番の家」の位置情報をマップ上に表示 2.現在地から最寄りの「こども110番の家」までルート案内。 3.店舗の登録も多い(というかほとんど？)ので、営業時間もわかるように。 　リアルタイムで営業時間中の「こども110番の家」を 　検索できるようにする。 　→逃げ込もうとしたら閉店してた！とならないように。 4.スタンプラリー機能などを持たせて、こどもが遊び感覚で楽しく 　継続的に「こども110番の家」を確認できるように。 　スタンプを貯めて、その達成率をクラス/学年対抗で競わせるなど。　 　(ibeaconを登録店舗、住宅に設置し、近くにまで行くとスタンプがたまるなど) 5.地域ごとの登録数、更新頻度の可視化。 　住みやすい地域の一つの指標として。 【今後の展開(案)】 1.地域住民と「こども110番の家」の方とのコミュニケーションを増やし、 　地域住民間の連携を深める。地域内の人と人のつながり(和)の醸成。 【備考】 1.「こども110番の家」はお店、住宅などの形態があります。 2.「こども110番の家」以外に、類似の活動があります。 　(1)セーフティーステーション ...CVS (Convenience Store) の活動 　※他にもあれば是非教えてください。

東日本大震災時の液状化現象による被害や，旭化成建材の杭打ち偽装などを受け、地質や地盤が注目を浴びている。今後大規模震災が起こると予想されている中、地盤との関わりが深い防災についても見直す必要があるが，国民の防災意識は決して高くはないのが現状である。ゆえに，本作品では，地盤情報及び地盤に関する有意な情報をLinkさせることにより，国民の防災意識向上に資するLODを作成するアイデアについて提案する。

＜新しい番組表のスタイルを提案！＞放送局のウェブページや、ポータルサイトなどでは、テレビの番組表サービスが提供されています。しかし、従来の番組表サービスでは、それぞれの番組が持つ話題性などを知ることはできません。そのため、ユーザは「知っている番組」や「いつも見ているジャンルの番組」ばかりを見てしまいがちです。今回提案する番組表サービスProgram Impact Viewerは、外部のオープンデータなどの情報を用いることで、それぞれの番組がどのような話題性やユーザとの関連性を含んでいるのかを示してくれます。ユーザの見る（録る）番組の選択をサポートすることで、結果的に、ユーザが触れる場組の幅を拡げ、新しい体験や知識を提供できるのではないかと考えています。

自治体Twitterデータを活用したインフォグラフィックです。

減災インフォが収集している自治体Twitterに関する技術的な説明です。

時間や場所を選ばずに、コワーキングスタイルで仕事をする人のための情報マップ 場所だけではなく、イベントや人の情報をリンクすることで、人とのつながりを可視化し、仕事の質の向上につなげることができるデータとなる。

突然の混雑に困った経験のあるアナタにコンザツーチ！ 周辺のイベント情報から混雑を予測し、巻き込まれる前にスマホへ通知！混雑を効率よく回避するサービスのアイディアです。

災害時に備えて各自治体、避難所で用意している備蓄物資を地図に可視化します。 住民に対して十分な蓄えになっているのか？ 避難所（物資の保存場所）を中心に、周辺の人口分布を加味したカバー範囲を表示します。 避難日数や時間帯に応じて変動するカバー範囲も確認することができます。

多忙な営業マンの訪問効率を上げるための渋滞情報をベースとした訪問ルート編成アプリです。

We propose a Tokyo 2020 mobile app based on Linked Open Data (LOD). LOD facilitates data integration on the Web. Our app would offer a unique entry point to query and traverse multiple connected data entities that are related to the Olympic Games. London 2012 was considered the first data Olympics. We would like to make Tokyo 2020, with the permission of Rio, in the first LOD Olympics.

身体障がい者用のトイレがあるところをマップ表示し、詳細情報が確認できるようにします。

日本国中どこにでもある自動販売機にプラスアルファの機能を考えました。自動販売機は、人の目が届く場所に設置されるケースが多いので、情報発信のための活用や「犯罪の予防」と「被害の防止」のための防犯機能、販売情報を収集しPOSとしての様々な活用方法などオープンデータと人々のコミュニティを「つなぐ」というLODに着目してみました。

人類は「調理」することを覚え、「料理」を作り、「文化」に昇華させ、世界遺産として登録、保護するようになりました。 紀元前1600年くらいからレシピを粘土板に記録し始め、今日では書籍やWebサイト・スマホアプリなどに形を変えながら広くシェアされています。 　とはいえ毎日発生することであり、様々な料理が作れるようになったことで「何が食べたくて、何を作るか？」という悩みを抱え続けています。 　その問題にちょっと楽しく、かつ食卓を囲む前から家族のコミュニケーションを取れるようなサービスを考えてみました。

鯖江市の百景ギャラリーです。

マウスオーバーすると写真が回転して詳細情報や地図へのリンクが表示されるアプリ「パタパタフォトギャラリー」の作り方の解説ページです。

１ こども部屋で おかたづけすると ２ パパママみんなのスマホにお知らせ ３ どこにいても できたね共有 （会社のパパや　遠いじじばばとも　みんなで子育て） おかたづけ ＝こころのヘルスケア 離れていても　みんなで見守ってるよ 光センサー 加速度センサー タッチセンサー 使用シーン バリエーション ◯ 学校用お名前ホルダー ◯ 病院内リストバンド　◯ シニア見守りグッズ　◯ アトラクション（exp.密室脱出ゲーム）　

くらし、観光、子育てに関して、ハッカソンやアイディアソンをするための基礎データを整理しました。 各分野のアプリ事例、ニーズの高いデータ、KnowledgeConnectornに載っている事例一覧、公的統計等を整理したデータです。後半は、共通語彙基盤の簡単な解説になっています。

昨年度に引き続き、オープンデータ＆オープンイノベーションで通勤問題解決を目指します。 今年度は「鉄道事業者をまたがる駅のバリアフリールート検索」に取り組みます。 1.問題意識 現在、既に鉄道各社は自社の駅バリアフリーマップを公開していますが、二つの大きな問題があると考えています。 (1)マップを見ても、バリアフリーなルートを探すのが大変難しい。 ・（例えば車椅子が通れない）段差がどこにあるのかがわからない。 ・どのルートが該当するかもわからない。 ・複数のルートがある場合でも、より負担の少ないルートがわからない。 (2)鉄道会社ごとに作られているため、ターミナル駅で鉄道会社をまたがるバリアフリールートがわからない。 ・例えば、渋谷駅の「井の頭線の開札」から「副都心線の開札」までのバリアフリールートは、このまま誰も何もしないと永遠に計算できない可能性が高い。 2.解決策 上記の問題を解決するため立ち上がりました！まずはターミナル駅（渋谷駅）で、京王井の頭線改札口、東京メトロ銀座線改札、JR玉川口改札の間のバリアフリールートを検索するプロトタイプを開発します。 プロトタイプ完成後、メンバーを増やしつつデータ整備を進めたり、鉄道会社にアイデアをPRしつつ、カバーする駅を広げていきます。 3.参加メンバー（敬称略） ・年岡晃一 ・木田和海（リーダー） ・浅野優 ・板垣真太郎 ・小副川健 ・大林勇人 今年度から参加 ・植田順 4.開発内容 4.1.データ設計 (1)データトポロジ GISで一般的に用いられている、エッジ（今回はWay）とポイント（今回はPoint）といった2種類のクラスで、駅構内の施設や通路を表現する方式を採用。 (2)クラス定義 下記（記事）参照。 4.2.データ収集 2015年1月11日（日）午後に渋谷駅にてフィールドワークを実施して、京王井の頭線改札口、東京メトロ銀座線改札、JR玉川口改札の間のバリアフリールート検索に必要なデータを収集。 4.3.開発するアプリケーション (1)データ収集のためのツール (2)バリアフリールート表示アプリケーション