4

value

4

hogehoge

Update:Jan 18, 2016

hogehoge 応募取り下げ
1

value

1


下記URLで投稿したアイデア「Linked Open Dataの価値を高めるLinked Open処理」の実装のアイデアを投稿します。 http://idea.linkdata.org/idea/idea1s1645i (当初は実装を行い、基盤技術部門で投稿する予定でしたが、開発が期限に間に合わなかったため、アイデア部門に投稿させてください)
4

value

4

2

value

2


僕たちは、選挙投票率を向上させるには、現在あまり関心のない人に関心を持ってもらうことが重要だと考えました。しかし、選挙そのものを支援する類のアプリケーションでは、新たに選挙に行く人を増やすことは難しいと考えられます。そこで、投票年齢引き下げに着目し、主に学生に向けて選挙への関心を高める為の教材を開発することに意義を見出しました。アプリケーションは複数人で行う事を想定しており、個人では行えないので注意してください。
4

value

4

2

value

2


青島の猫と島民の方々の暮らしを守るとともに、持続可能な観光として発展させるためのアイディアです。
2

value

2


ITに明るくない方も参加できるオープンデータ作りのワークショップを開催するというアイディアです。
2

value

2

Ueda/UHビューア

Update:Jan 17, 2016

このアイディアは、長野県上田市内において現在販売中の中古住宅情報をアプリ上で表示することにより、それらを視覚的に確認することができるアプリについて構想したものです。それにより、上田市内においての住宅の新規契約・新規購入の際の情報提供をより増加させることが可能となり、契約者側の情報取得の簡易化、販売者側の提供する情報の充実化を実現し、契約後の諸問題(交通問題・周辺施設問題)の発生数低減を目指します。
3

value

3

AED SLナビ

Update:Jan 17, 2016

このアイディアは、AEDを必要とする緊急時に使用者の現在地を起点とした範囲で、最短のAED設置場所への案内を行うことができるアプリについて構想したものです。このアプリを用いることにより、利用者は緊急時に迅速にAED設置場所に辿り着くことができ、それを用いて救助活動を行うことでロスタイムの減少、及び救助成功確率の向上を見込むことができます。また、使用者の利便性向上に配慮しアプリ単体での利用だけでなく、他の緊急時アプリなどの追加機能での提供も実現したいと考えます。
4

value

4


今ほしい情報だけを、即座に選りすぐって届けてくれるお助けアプリ。情報の中で迷子にならないために、確実で新鮮な情報だけをプッシュ通知。 移動中には、目的地までの道中にある施設・設備情報、Q&A情報(口コミ、ランキング)を地図に沿って可視化します。 【エントリー部門】 アイディア部門 【応募者属性】 社会人 【応募者名】 坂本寛、安藤剛寿、宮崎勝、北村光貴、出口貴博、林田芳代子(6名) 【エントリー作品のURL】 http://www.slideshare.net/masarumiyazaki/makasetegoo 【エントリー作品の権利指定】 CC BY 【利用しているオープンデータ】(今後、オープンデータ化を希望) 1 「らくらくおでかけネット」 2 「Google Maps」プレイスライブラリ 【利用しているパートナーリソース】 1 「QAコネクト」 http://oshiete.goo.ne.jp/qaconnect   (1)「教えて!goo」に投稿されたユーザーのQAを検索できる。   (2)様々なサービス・アプリ事業者へ無償提供。昨年3,000万QA,月間2.7億アクセス 2 「社会・人口統計体系インジケータ」 http://ind.geonames.jp/   (1)日本語の地名に対して、基盤を与える(地名をそのままURIに)   (2)時間・場所・指標をcubeで可視化(ex.平成10年12月に東京に雪が降ったのは5日)   (3)JSON形式で表示 【エントリー作品の詳細説明】 ★こんなことありません? →電車の乗り換えの際、徒歩10分かかった(乗り替えに便利な車両位置を教えて!)。 →目的地がバリアフリー対応でも、そこまでの経路に階段や坂が多い(車いすやベビーカーでも行きやすい道を教えて!)。 →バリアフリーの新年会会場を探す際、HPには明記が無いのに、問合せると実はバリアフリー対応だった(問合せずに知りたい!) ★そこで役に立つのが! 目的地と、その道中にある施設や設備、Q&A情報(口コミ、ランキング)が、現在地とともに地図上でビジュアライズ化できるアプリ。 ★どんなことができるの? 1 欲しい情報をアプリに事前に登録しておくことで、現在地や行動予測に沿った情報を、プッシュ通知で即座に確認できる。 2 誰かが検索したことのあるものを優先通知。ランキング付けし有力情報を可視化。次の行動を直感的に選択できる。 3 商業施設や駅構内などにいるとき、目的地の階数、最短ルートやバリアフリールートなどについて、3D画像(cube)で可視化。 ★目指すこと  今ほしい情報にたどり着く時間を短縮し、実生活をより豊かなものにしたい。日々の選択や判断を助ける機能を持つこのアプリで、心にゆとりをもって行動してほしい。
8

value

7


各国から日本のことあるいは日本語を学びに多くの留学生が毎年やってきます.しかし,いつの時代も留学生の方々は日本で困った時に似たような行動をとることがあるらしいと聞き,日本で成果する上で障害となりうることをあらかじめまとめておくことでより,効率的な学習や充実した生活を過ごしてもらえるのではないかと考えました. そこで,毎年日本に訪れる留学生たちに「日本にきて困ったこと」と「それを解決するにはこの場所が良かった」や「日本語を学ぶにはここに行くべき」や「困った時は絶対ここ」など留学生から見た日本に関するデータを集めたを集めたいと思っています.
2

value

2

暇ツイートLOD

Update:Jan 17, 2016

SNSデータをマーケティングに活かすことをテーマとして,LODデータを作成して係る地図マップを作成する. 具体的には,Twitter APIを用いて「暇」という単語が含まれる位置情報付きツイートを収集し, このツイートをテキストマイニングすることで,暇とつぶやいている方のニーズ(暇な人は何を求めているのか)を明らかにする. さらに,暇なつぶやきが多い地域の近隣施設情報をgoogle placesを用いて抽出する. 最後に,LOD Browserを用いて,このニーズ及び近隣施設情報を可視化(地図マップ化)する.
1

value

1


日本の医療費を削減するために、 個人のライフスタイルを変化させるサービスです。 近年、自動車保険の分野で、PHYD(Pay How You Drive)自動車保険というものが発売されました。 ハンドル操作、速度、加減速、等の運転行動に関するデータから、事故リスクとそれに見合った保険料を算出する仕組みです。 これにより、加入者は、保険料のキャッシュバックを動機付けとし、安全運転を心がけ、 社会全体として交通事故に伴う損害を削減するという、 保険会社、個人、社会、全てに有益な、美しい仕組みです。 この仕組みを医療に応用する試みが英国で始まりつつあります。 まだコンセプト段階ですが、社会の流れとして、5年ほどで実現するのではないかと予想します。 外資に、この仕組みの全てを握られる前に、布石を打つべく、 必要なデータとサービスは何か?について、アイデアをまとめました。
3

value

3


LGBT当事者が自分の性に対する認識をするのは中学生・高校生頃の年齢。そして、認識による自傷・自殺行為に陥るケースは非当事者の二倍ほどというデータがある。その中で、学校関係者のLGBTへの理解度も教員により、差があり、教師が知らないうちに当事者の学生が傷ついたり、相談することが出来無いケースがある。 学校内でどの教員であれば、LGBTに対する偏見・差別なく学生を支援してくれるかを可視化することで、当事者の学生がカミングアウトする相手を選び、適切な支援を受けることが出来るようにしたい。 また、進学先を探す際に、そのデータをもとにカミングアウトできる環境かを学生が確認できるようにしたい。FacebookのプロフィールページをLGBTへの理解を示すレインボーカラーにしている人や、LGBT啓発に関する講演・講習を受けたことをSNS上にアップすることで、その学校関係者をLGBTに理解がある人として、認識できるようにしたい。また、それに合わせて既存のNPOなどと連携し、教育関係者への啓発活動・LGBTへの理解があることの認定講座などを行いたい。 まずは、私が住んでおり、LGBTへの啓発活動やNPOによる活動が一定量行われている横浜市から試作していきたいと考える。
1

value

1


 美術館の特別展と、グルメフェスタと、イルミネーションを一日で楽しみたい…そんな望みを手軽に叶えるアプリです! 【ユーザー】効率よく遊ぶ!  ネット上に散らばるイベント情報を一つのアプリに集約。カテゴリー別・開催時間別で地図上に表示するので、イベントを無駄なく回れます。 【イベント実施者】幅広く告知!  主催者個人のHPやTwitterよりも広範囲にイベントを告知。周辺のイベントを巻き込んだ、地域一丸フェスティバルの企画も容易に。 ※アプリのサンプル画面はURL参照
7

value

7

TASガイド

Update:Jan 17, 2016

このアイディアは、各地の観光地情報を統合したオープンデータを用いることによりスマートフォンのアプリ上で、観光ルートの自動生成や利用者の目的に応じた観光地案内を実現可能とするためのアプリについて構想したものです。このアプリの利用により、利用者は自分で観光ルート設定せずともアプリでの案内により観光が可能となります。それに加えて現地での各種交通網を利用した、より効率的で低コストな移動方法を案内することで観光を円滑に行うことができます。
4

value

4


イセキホリダーは都市近辺に埋もれていた文化遺産を巡るスタンプラリーアプリである。 埋蔵文化財の存在が知られている土地(周知の埋蔵文化財包蔵地)は全国で約46万カ所あり,毎年9千件程度の発掘調査が行われてる。http://www.bunka.go.jp/seisaku/bunkazai/shokai/maizo.html 発掘された文化財は国民の共有財産であり、各自治体などで保管されているが、倉庫などに保管されている文化財が多く、公開が充分にされているとはいいがたい。 本スタンプラリーは各発掘調査をまとめた発掘調査報告書の抜粋と位置情報を基に、周辺の遺跡を巡るアプリである。本アプリを通して考古学の裾野を広げられることが期待できる。
4

value

3


まだ誰も知らないまちの人ならではの秘密スポット、知っている人に聞いてみよう、宝残しアルバム
1

value

1


徘徊が危惧されるお年寄にビーコンペンダントを持ってもらう。市民から見守りアプリをインストールしてくれる人を募集する。行方不明になったらサイトアクセス、最後の見守位置を表示。
1

value

1


ベビーシッター・ペットシッターの位置エリアがわかる。すぐにスマホで依頼&予約できる。
1

value

1


古民家、空き家と都市計画が合わさったMAP、取り壊される物件をまち歩きでめぐる。取り壊した方がいいところを知る。
1

value

1


病院の混み具合などのライブ情報の発信。今、自分がどこにいるかを発信することで、仲間が病院に集まり話ができる。自分の治療履歴やリハビリ情報を他院に伝え、くり返しを防ぐ。
1

value

1


さいたまの歴史について学ぶ講座「さいたまスタディーズ」で学んだ、古代から現代のさいたまのうつり変りを地図を通してみてみる。または、残っている写真から昔の姿を現存する建物上に投影する。
1

value

1


ちょっと昔のさいたまの情報をまとめたガイドです。 ・本にのるほどじゃなけどみんなが知っているご近所のこと ・こんな写真があったよ ・この建物は実は古い ・「へー知らなかった!」な豆知識
1

value

1


外出先(公共施設・駅・ビル・商業施設等)の便所がバリアフリーか否か表示されるアプリを作る。さらに便所が洋式か和式か、便器は何台あるのかわかるアプリを作る(外国人の人にも優しい)。これら情報について、その建物を利用した人も便所の情報を送信し、最新の便所地理情報が共有されるシステムを構築する。
1

value

1


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

value

1


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

value

1


1.概要 従来のLODを物理世界とつなげるプラットフォーム「サイバー・フィジカルLOD:CPLOD」を提案します。CPLODは、LODにつぎの機能を加えたものです。 ・物理世界との双方向接続 ・リアルタイム性 ・秘密の制御 これらの機能によってLODを身の回りのあらゆる情報処理へ適用できるようにし、クラウド、モバイル、IoTをオープンな仕様で連携させ、少子高齢化、地球環境の変化などの課題にITを活用できるようにします。 2.セールスポイント:ITデバイスの総連携によりITの可能性を使い切る 現在のITデバイス(クラウド、モバイル、IoTなど)は、十分な発展をとげ、様々な問題を解決するツールとなる可能性を秘めています。たとえば、個人の身の回りのデバイスを連携させれば、社会や家族の負担を少なくしながら高齢者を見守り、介助するようなシステムを作れるでしょう。 あるいは、市町村、都道府県、国といった様々なレベルでリアルタイムに地域の状況のセンシングを行って情報を共有できるシステムや、全住民が参加するコラボレーションツールのようなシステムを作ることができるでしょう。縮小していく経済に対応しながら、資源やエネルギーを効率化し、拡大する失業、高齢化、少子化などの対策をとるツールとするといったことが可能となるはずです。 しかし、現在このようなシステムはまだありません。その原因は、任意のデバイスや人を連携させることができないという、分断化にあると考えます。ITの分断化には3種のタイプがあります。 (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」」に記します。
1

value

1


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

value

2

Show More