全国で障がい児向けのICT教育支援や、特別支援学校卒業後の就職支援に関心のある人が集まりコミュニケーションする「学校ICTサポーターズサロン」公立学校(主に特別支援学校)でのICT教育支援活動報告や、学校の先生からのQ&A、実際にEdTechの研究開発、イベント・コンテスト情報、まだ表に出していない話など非公開FBグループでしています。

■ アプリの概要 4919(食育) for Ikoma は、成長期の小中学生が毎日食べる「給食」にフォーカスを当て、子供の食育をサポートするアプリです。 子供が毎日食べる給食の献立やカロリー、アレルゲン、栄養バランスなどを手元のスマートフォンでかわいいイラストともに手軽に確認することができます。 □ 給食献立をいつでもスマホの中に 4919 for Ikoma は、いつでもどこでも給食の献立を確認できるアプリ。 給食において誰もが感じたことがある「こんなのがあったらいいのに」を形にしました。 ・ 食物アレルギーをもった子供のいる家庭 ・ 給食と晩ごはんが被りがちな家庭 で、4919 for Ikoma は活躍します。 冷蔵庫にA3の献立表を貼って、毎日小さい文字を確認する なんてことは必要ありません。 買い物に来て、今日の献立なんだったかしら？ と悩む心配もありません。 □ オープンデータを活用 4919 for Ikoma で表示される給食情報は、奈良県生駒市が公開する小学校献立表オープンデータを活用しています。 ※ 生駒市が公開するオープンデータは こちら(https://data.city.ikoma.lg.jp/data/dataset/1487379933) から確認いただけます。 □ 4919 が生駒市を動かした！ 生駒市主催のアプリコンテスト「IkomaCivicTechAward2016」へ、4919 for Ikoma を応募し、最優秀賞を受賞しました。そこから、生駒市や給食センターとの連携が始まり、なんと半年後（2017年9月）に、全国初となるアレルゲン情報を含んだCSV形式での給食献立オープンデータの配布が実現しました。 □ 生駒市公認の給食献立アプリに！ 2017年11月から、給食センターが配布する紙の献立表へQRコードの記載が始まり、紙の献立表からアプリのダウンロード出来るようになりました。 ・ 生駒市報道発表資料：http://www.city.ikoma.lg.jp/0000011334.html

大阪市のオープンデータを利用して、現在地や指定住所の近くの施設をGoogle Map上に表示させています。大阪市に転入されてきた人など、自宅や会社の周辺にどの様な施設があるのかを確認してもらえる様にWEBアプリを作成しました。今後は大阪市のオープンデータだけでなく、銀行や郵便局、コンビニなどといった身近な施設も表示させていこうと考えています。 なお、スマートフォンやタブレットでも利用し易い様に、レスポンシブデザインを採用しています。

LinkDATA.orgを利用したハッカソンの実施、可視化ツールを使用したハッカソンの実施、非営利セクターとしての取り組みなど

声優LODの構築およびそれを用いた声優のキャスティングに向けて、声優、TVアニメおよびキャラクターについてRDF化を行った作品である。

OpenWorks（オープンワークス）は、街中で発見した問題の共有・様々な要望をお聞きし、解決を図る仕組みです。

日本の国家予算の歳出金額を、あなたのすきなように増やしたり減らしたりできます。 また、それによる増税、減税の見込みを（簡易的ですが）計算することもできます。 ※学校での利用実例 「消費税率が上がったことで増えた税収を、どのように使うか学生自身で考えてみる。そして発表する。」という授業で利用されています。 ※活用オープンデータ ・財務省の予算関連データ ・同　租税関連データ

自治体オープンデータ推進協議会関西会議の第２回を開催します。今回のテーマは、「オープンデータで市民参加・協働モデル」ということで、Code for JAPANの関代表、千葉市広報課の松島課長をお招きして、お話をお聞きし、意見交換をしたいと思います。また最後に、先日行われたインターナショナルオープンデータデイの関西地区での主催者の皆さんより、リレー報告をしてもらう予定です。

放置自転車の時系列変化を地図上に可視化するアプリケーションです。 スマホで放置自転車の台数を投稿すると、その情報がリアルタイムにLOD化され地図上に可視化されます。

世界最高精度の犯罪予測アルゴリズムを開発した。このアルゴリズムを基軸とした先端防犯プラットフォームを提案する。「カン・コツ」に頼ったパトロール活動をより効率化し、受動的な事後対応にとどまらない予測に基づく能動的な防犯、というパラダイムシフトに挑戦する。そして今までバラバラだった、警察、自治体と全国の防犯ボランティア団体の知見をシームレスにつなぎ、安心・安全社会への礎とする。

代替食材情報を、RDFとして整理してみます。

福岡市のBrigadeです。一緒にやっていく方を募集！

明石観光協会が公開している明石焼（玉子焼）部会加盟店一覧のCSVデータをLODにして公開しました。 元データ：http://www.yokoso-akashi.jp/news/495 CC BY:明石観光協会

地図データと寺社仏閣・仏像のデータ組み合わせたマップアプリを作成するアイディアです。

We are advocating three disaster prevention initiatives as “Disaster Management Tranceformation(DX)”. （防災に関する3つの取り組みを「防災トランスフォーメーション」として提唱しています。）

開港5都市まちづくり景観会議に加盟する港まちデータです。

『忙しいビジネスマンの心の止まり木』 出張先での打ち合わせまでの数時間、帰りの電車までの数時間・・・ 「時間がないので肩肘張った観光はできないが、折角遠くに来たからには、空き時間でその土地ならではのものを見てみたい」と思うのは出張族の常。 「AKIJIKAN（空き時間）」はそんなビジネスマンの想いを形にしたスマホ特化型WEBサービスです。 エマージェンシーモードを搭載し、いざという時には、切り替えにより最寄りの避難所を表示します。 また、総務省公共クラウドを利用しているオープンデータプラットフォームを利用しているので、すでに全国対応。 現在のところ、北海道森町や室蘭市、鯖江市や品川区、琵琶湖付近などなどで動作確認ができています。 情報が無い場合はぜひ、自治体に掛け合いましょう。 忙しいビジネスマンの方々、ちょっとした観光に、また、緊急時の避難場所の確認に、ぜひ活用してください。

世界のカメラ愛好家の方々に京都へ来ていただき、舞妓さん撮影の機会を提供しています。 撮影者は花街の顧客になり花街文化の魅力を撮影。 芸妓さん舞妓さんが写真をチェックしOKのものだけをネット公開しています。 世界のカメラ愛好家は花街の顧客になり、 さらに、 クリエイターとして成長しながら花街の魅力を世界へ伝え、花街の経済活性化に貢献。 という持続可能な地域文化発信のエコシステムを実現しました。 そのエコシステムのコアとなるのは、オープンデータ化された写真データです。 2018年9月30日現在で、6600枚の写真がストックされています。

明石工業高等専門学校4学科（機械工学科、電気情報工学科、都市システム工学科、建築学科）と専攻科の平成27年度シラバスと時間割をLODにして公開しました。

英会話のトレーニングをしている話者の音声データを人工知能APIで解析し、SPARQLクエリを用いた分析により英会話能力を自動採点することで、さらに英会話能力を向上させるために必要な学習ポイントを明らかにするアプリケーションのアイデアです。こちらは、IBM BluemixとMicrosoft Azureを用いた実装方法のアイデアです。

赤ちゃんを持つ親御さんが抱える悩み・問題点を収集し、それをオープンデータ化することで問題の共有化・解決を図る。また、実際に集められた問題を解決するためのアプリなども開発する。例えば、ベビーシッターを雇うための支援アプリにおける雇う側雇われる側のマッチングシステムの開発や、様々な公園の情報として景観や危険な部分などを画像付きで表示するシステム等があげられる。

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

スマートフォン内蔵のセンサーを利用して、ソーシャルゲーム利用者を対象にサプリメントの日常的な効果を検証する。

＜概要＞ 現在の農業の問題点の一つとして若手の農家が減少していること に着目し、若手の未農業経験者が農業に参入することを敬遠して いる側面があります。 そこで、新規就農者支援するプラットフォームの作成により未農業経験者の 農業参入を支援するためのアイデアである。 ＜詳細＞ Ｉターン・Ｕターンの若手を農業に参入しやすくする。 　・農業技術獲得の支援する。 　・農地に対して、複数人で分担による共同作業 ＜必要とされるデータ＞ 　・農作物一覧 　　様々な土壌に最適な農作物の紹介 　　各農作物における標準的な作付等のスケジュール 　　農作物ごとの作付面積単位での標準的な収入見込み 　・農作物作成ノウハウ 　　種の手配から肥料・農薬等のタイミング、品質を確保させるための 収穫方法など ＜提供するサービス＞ 　・農業版「Yahoo!知恵袋」による若手農家とベテラン農家のコミュニケ 　　ーションサービス 　　（ベテラン農家にもインセンティブがいるかもしれない） 　・農業版「じゃらん」「asoview!」による、若手農家が閑散期に 　　旅行ができるサービス 　　（ポイント等の割引制度を設けて、次回作付時の肥料購入や 　　　農機具追加の際に割引く） 　・農業版「メルカリ」による、農機具のやりとりを実施 　・人と人とのマッチング 　　（農家イケメンコンテスト、生産者－購入者(飲食店)の直販） 　・高収益を挙げる農業のコツ（ｅラーニング、セミナー…） ＜想定されるUI＞ 　・スマホアプリ 　　気象情報とのマッシュアップにより、大雨・暴風・霜・低温等の 　　注意報・警報をプッシュ通知して、若手農家に早急な対策を提案 　　できるようにする。 ＜チャネル＞ 　農業系の高校・高専の学生へのアプローチは自然発生的獲得できるとして、 　それ以外の若者へのリーチとして、下記の観点で提案したい。 　・ハローワーク（職を求める方々） 　・テーマパーク（農業とは一見無関係だが、若者が集う場所） 　・給食献立表（学校給食にて地の農家との交流も含める）

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