三多摩地方を含む旧・神奈川県と埼玉県の自由民権運動における結社、人物、イベント、場所、地名をLinked Open Dataにして可視化しました。

湯河原という秘境の地をみんなに知ってほしい。 湯河原温泉の有名な足湯と温泉の魅力を伝えていきたいです

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」」に記します。

横浜市の市議会議員一覧です。

駅のホーム、道路、お店など、街には注意書きが溢れています。 そんな注意書きをスマホで撮って位置情報とともに多言語でデータベース化。

「Japanese Meteorite Map」は、日本に落ちた隕石を日本地図上に可視化し、主要な項目の検索、絞り込みできるWebサイトです。 日本に「どれくらい」、「どこに」隕石が落ちているかを知っている人があまりいないことに注目を当て、それを一目で解決すること目的としてこのサイトを作成しました。 日本地図上に隕石を割り当て、それぞれに情報を持たせることを考え、http://app.linkdata.org/app/app1s902こちらのデータにて実際に可視化することが可能となりました。 このサイトを利用することで、今までに落ちた隕石の「落ちた年」、「重量」、「分類」を絞り込みながら日本のどこに落ちたのかが一目でわかります。 2000年以降に落ちた総重量1ｋｇ以上の隕石を一目で見たい、などを可能にする機能があるので他にはない差別化ができます。

長野県は、北陸新幹線が整備され、主要駅までのアクセスはよくなり、観光客も増えました。一方で、観光地各所の距離が遠いのにもかかわらず、観光地までのバスや電車などの公共交通機関が十分に整備されていません。そこで、自転車があれば、徒歩では観光しにくい場所でも効率良く観光することができます。また、運動をして健康を保つきっかけとすることができ、環境にもお財布にも優しく地域貢献をすることができます。

■ 概要 キーボックス付きのキーホルダーとスマートフォンアプリへの通知を連動させるアイデアです。 キーボックスから鍵を取ったら「◯◯がお家に帰ってきました」、鍵を戻したら「◯◯がお家を出ました」というメッセージを家族に通知します。 ■ 機能 鍵を戻すと「お家に帰ってきました」をアプリへ通知する。 鍵を取ると「お家を出ました」をアプリへ通知する。 ■ 使用するもの <ハードウェア> ・キーボックス付きキーホルダー（QUALY社 Sparrow Keyring Wなど） ・Raspberry Pi ・センサー（感圧センサー SFE-SEN-09673 など） ・スマートフォン（iPhone, Androidなど） <サービス> ・Push通知を送信できるサービス（AWS SNSなど） ■ 実装例 感圧センサーを、キーボックスに取り付ける。キーホルダーが感圧センサーの上に乗るようにする。 Raspberry Piでpythonプログラムを実行し、感圧センサーの電圧を定期的に監視する。電圧の値変化から、キーホルダーの有る無しの状態の切り替わりを検知し、AWSへPush通知のリクエストを送る。 AWSには予めアプリを登録しておき、APIを叩くとPush通知が送られるようにしておく。

今夜くらいは少しだけ考えてみるシリーズの第5弾です。今回も「自分で試して考えてみる・議論する」ことができます。テーマは「就活ミスマッチの撲滅」です。学生は、個別企業へのアプローチの前に、本アプリを使って日本の産業や業界の特徴、仕事のことを定量的に把握できます。 さらに今回は「社会とのコミュニケーション機能」の追加を考えており、学生と企業の相互理解の実現を目指します。

東京メトロを分析してみました！ 東京メトロの乗降人員数を取得し、グラフ化（可視化）してみました。 時間があれば、現在の運行状況を定期的に取得し、kintoneへ蓄積し、 遅延に傾向がないか分析してみたいと思います。 東京メトロの乗降人員数を「kintone」に取り込みました。 「kintone」でグラフ出力してみましたが、データをエクセルに出力し、 「E2D3.js」にてグラフ化も行ってみました。

大学案内LODでは，各大学にある学部・学科などの教育内容を世に知らせるためのLinked Open Dataとして作成する． 各大学は，現在，アドミッションポリシー，カリキュラムポリシー，ディプロマポリシーの3ポリシーの作成が求められている． これらに基づき，入学から卒業に至るまでの教育内容，過去の入試や就職に関する実績の紹介多大な労力を投入して「大学案内」として作成し，さらに，進学情報を扱う各企業のWebページや大学ポートレートへの情報提供を行っている． 大学からの情報提供は，重複することも多く，各提供先への情報の正確性，更新頻度などの違いから，大学の内容を知る上で不正確な情報による誤解などが生じる危険性がある． そこで，本アイデアは，各大学の「大学案内」にあるような大学の教育内容と入試に関する情報をLOD化することで，著作権処理の手間を低減する． また，一元的に大学が発信する情報を統制可能とし，正確性や利便性を高めることを目的とするものである．

「プロジェクトTRAIN（通勤情報を可視化することによる通勤問題解決2015）」の活動として作成したデータです。 1.データ項目 国土交通省「歩行空間データネットワークデータ整備仕様案（平成22年9月版）」の主要なデータ項目を抜粋した簡易版の「歩行空間データ」を定義しました。 －経路の種類 －供用開始時間 －供用終了時間 －供用制限曜日 －方向性 －有効幅員 －縦断勾配1(%) －縦断勾配2(フラグ) －路面状況 －段差 －最小階段段数 －最大階段段数 －手すり －屋根の有無 －蓋のない溝や水路の有無 －視覚障害者誘導用ブロック －補助施設の設置状況 －エレベーター種別 －距離 2.データ収集 2015年12月26日（土）、2016年1月5日（火）にて大井町駅にてフィールドワークを実施して、JR東日本京浜東北線改札口、東京急行電鉄（東急）大井町線改札、東京臨海高速鉄道りんかい線改札の間の、段差の有無等のバリア情報を含むバリアフリー経路案内の基盤情報となる「歩行空間データ」を作成しました。 3.作成したデータ ・GeoJSON http://ejopendataportal.maps.arcgis.com/home/item.html?id=f72aab6aa2994e749afb2e12c5898f0b ・Shapefile http://ejopendataportal.maps.arcgis.com/home/item.html?id=88834f73fcf944fa88d34bf08f2ac0ed ・CSV http://ejopendataportal.maps.arcgis.com/home/item.html?id=e222b4e6588b4f4582e138f3af5504d0

私たちは平塚市の学生団体と話す機会がありました。平塚市はリトアニア人のホストタウンです。ホストタウンとは地域と経済、文化、教育などスポーツに限らない相互交流を行う地方公共団体のことです。学生団体は相互交流を行う中でお互いの国に対する認知度の低さが課題だと考えているそうです。そのため、学生団体は平塚市に大規模なイベントの開催を提言したそうです。そこで、私たちは別角度から平塚市の課題を考えました。これは私たちの実体験ですが、修学旅行に行った際に地元で有名な美味しいお店を探していました。インターネットやＳＮＳを使いましたが、なかなか見つけられませんでした。日本人の私たちですら日本の修学旅行先でお食事処を 探すことに苦労したのに、国外からくるリトアニア人はより大変だと思います。国土交通省観光庁が公開している訪日外国人消費動向調査の報告書を見たところ多い順に買物代の37.1%宿泊費の28.2%に続き、飲食費は20.1%でした。必須なうえに頻繁に取る食事についてのサービスは検索してもリトアニア人向けのものはありません。そこで私たちはリトアニア人が平塚市の食事処を探すのに困ることが課題だと考えました。リトアニアから平塚市まで来るのに半日以上もかかるため、移動だけでもかなり体力が奪われ、疲れが出ると思います。しかし、平塚に来てすぐに満足な食事を得ることができたのならば、平塚に対しての第一印象が良くなると思いました。第一印象が良ければその後の平塚観光も楽しめるはずです。そこで私たちはリトアニア人向けのアプリを開発することにしました。 全てリトアニア語で表記し、おすすめ、日本食、リトアニア食、フランス料理とジャンル別にお店が探せます。タップすることで一覧が表示され、それを選ぶとより詳しい情報が表示されます。マップは機内モードでも使えるように、駅を中心に書きます(オフラインで使えます)。日本食がよくわからないリトアニア人もいると思うので、日本食の簡単な説明をします。

サバイバルゲームやボルダリング・それらに関連する場所

生徒▶自由研究にも 先生▶課外授業にも　使えるよ！

Study Mailの国会版です。登録したキーワードや出席者などが国会の議事録に新しく登録されるとメールでお知らせします

エリア杯＋から見る、Splatoonの武器環境の入れ替わり移り変わりを見ていきたいと思いました。

ウェブアプリを中心に広く普及しているJSON形式のデータを効率的にJSON-LD形式にしてLOD化を加速させるアプリケーションの提案です。

わたしたちのサービス「ラクトレ」の特徴は、まちの落書きの位置情報を収集し可視化することにあります。アプリケーション利用者が街中で見つけた落書きの情報を「ラクトレ」に登録すると、マップ上で他のユーザーにその情報をシェアすることができます。アプリ利用者は町内会等と協力しながら、発見された落書きを消すイベントを開催します。取得されたデータは、他のオープンデータと掛け合わせられて、ほっと安心できる街を示す独自の指標である『ほっと指数』を算出することに用いられます。アプリケーション利用者は『ほっと指数』を上げていくことに注力します。『ラクトレ』は、オープンデータを活用しながら、自らが関わる地域の治安の悪さを改善し住みよい町にしていく活動を補助するアプリケーションです。

マンガ好きですか？ 「まんがそむりえ」 はマンガ推薦を行うLine Botです。 ユーザのほしいマンガの内容をLine上から対話形式で手軽にお聞きし、おすすめする本を返答します。 例えば、"完結"したマンガがほしい、"医療"をテーマにしたマンガがほしい、"3巻"ぐらいの巻数のマンガがほしい、といったユーザのほしいマンガをお聞きし、聞いた内容をもとにマンガを推薦します。 ぜひ「まんがそむりえ」を友達登録して、試してみてください。 ※ お知らせ ・2017/01/19 23:00 DBpedia Japaneaseのサーバが復活したようです。正常にBotも動作するようになりました。 ・2017/01/15 21:00 現在 DBpedia Japaneaseのサーバがダウンしているようで、Botが正常に動作していません。 復旧しましたら、このページでお知らせ致します。

AED検索用オープンデータ 各市町村に限定した一覧も本ページ後半のURLのように指定すれば取得可能です。

東北文化学園大学の情報デザイン演習で作成。

もちのクイズアプリです。 クイズはオープンデータにします。 クイズの元データは主にWikipediaです。

私たちの住む日本はたくさんのプレートの上にあり、他の国と比べても地震がとても多く発生しています。東日本大震災や熊本大震災は私たちの記憶に新しい大きな地震です。これらの地震については、テレビや新聞などですっかり見なくなりました。しかし、復興が完了したわけではありません。７年前に起きた東日本大震災でさえ現在でも避難生活を余儀なくされている人たちがいます。震災当時のような活発な復興支援活動を聞くことがなくなった今、私たちに何ができるのか。また同じように被災地の復興を願う人、興味はあるがボランティアに参加できない人はどうすれば協力できるのか。というような課題を私たちは見つけました。困っている人たちのために協力し、支えあう未来。何かと災害の多い日本は何度も支えあい、助け合ってきました。すでにできていると言う人もいるかもしれません。実際、災害当時は様々な募金活動やボランティアの呼びかけなどが行われていました。しかし、今では聞くことがなくなりました。話題というものは常に移り変わっていきます。困っている人たちはまだたくさんいるのに、私たちは様々な話題が生まれるうちにそのことを忘れてしまい、困っている人がいるけれど協力できていないのが現状ではないかと私たちは考えました。放射線汚染が気になり、安全が保障されていても東北の食材や商品を買わないなどは、協力どころか私たちの行動で被災した人たちを苦しめています。放射線の問題を解決するには、膨大な時間が必要になります。だからこそ、どんな小さなことでも困っている人の助けになるのなら私たちのできることをしなければと思いました。 ボランティアに興味はあるけど時間と移動費が・・・それなら ボランティア　×　手軽さ　＝　継続 被災地の復興支援通販サイトをサポートするアプリを作り、ボランティアに手軽さを、手軽だから続けられる！！継続的な支援で復興をさらにアシスト！！ 　前述に提議した課題である被災地の復興を願う人、ボランティアに参加する事ができない人たちへ今足りていないものは、”手軽さ“だと私たちは思い、スマートフォンを使った新しいボランティア通販アプリケーションを考え付きました。このアプリでは、被害にあった土地でとれる特産物や商品の購入を促し、実際に買ってもらうことで収益を生むことが目的です。決して無駄にならない誰かの助けにきっとなると思います。 ＊アプリの機能 　　・被災地の特産物や商品を購入することができる　　　　・購入者のレビューが書き込める 　　・その場所で有名な物（特産物など）を紹介 　　・場所、商品の種類ごとカテゴライズし機能性ＵＰ ＊画面デザイン アプリについて（ボランティアである説明や被災地の現状など） ＊このアプリを使用していただくために 　・Yahoo!ボランティア、actiboをはじめとしたボランティア募集サイト、ボランティア情報誌へ掲載 ・Twitter、FacebookなどのSNSで拡散

J-GLOBAL Knowledgeクエリソンで作成。 キーワードを入力して大学別論文数を降順表示。