CEP-AI システム（太陽光発電事業化支援サービス）は、地域の企業・団体と共に太陽光発電を普及・運営するに、事業の実施を効率的に進める事を目的とし、地理情報システムを活用して効率的な事業の推進を支援するサービスである。システムの構成内容は、太陽光発電事業における業務フローに沿った4 つの機能から構成されており、将来的にはこれらの機能を他の自然エネルギー、交通情報、防災情報、不動産などへの分野拡張し、スマートシティやオープンシティを推進するためのプラットフォームとして事業展開していく。

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

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

#オープンデータソフトクリーム

オープンデータを活用して、東京の「祭り」を盛り上げよう！

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

地震大国である日本において、地震を観測しよく知ること、防災や減災に向けて研究をすすめることはとても重要である。 しかし、研究に必要な地震動のデータは「地震」や震度、災害規模といった情報を元に探すことはできない。それどころか、地震にはIDや名称はなく、地震そのものを一意に特定することは難しい。 地震LODでは、地震を特定するための語彙を提供し、地震の観測や研究に必要なデータの流通を目指す。 今回は、地震の語彙、および気象庁で命名された地震データセットの作成、また実際に観測した地震動のデータセットの作成を行う。 https://seismic.balog.jp/ontology/jp-earthquake.ttl https://seismic.balog.jp/ontology/jma-earthquake-named.ttl https://seismic.balog.jp/ontology/jma-observers.ttl

LODチャレンジに応募したい方のために、LODチャレンジ実行委員へ直接相談できる場と、チームで集まって作業できる場所を提供いたします。

D3.jsとweb上のデータソースを使ったグラフを作成、共有できるアプリです。

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

誰にとっても「まさか！」の異常事態に遭遇することは辛いことです。何かが起きて、「こんなこと、予想もしていなかった」が実はとても怖いこと。冷静で適切な判断が難しくなるからです。どのような判断を要するのか、必要な知識は何か、そのときの判断が基となりその後の展開はどうなるのか？　予めそんな情報に触れておけば、まさかを少しだけ軽減できるかも知れません。そのためのきっかけを提供します。

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

近年メディアでも取り上げられるようになってきた行政のさっ処分問題。 さっ処分されてしまうペットたちを減らすため、 ペットショップに行く前に、まずは動物愛護センターで・・・ そんな話はよく聞きますが、いざペットの里親になりたい！と思った時、 ペットショップに行く前に、自分の県のどこにどんな動物愛護団体があって、 その団体にどんな子がいるのかを調べるのは今の情報がまとまっていない状態ではとても大変です。 これを簡単に検索できるアプリがあれば、 よりそのような環境にいる子と里親さんとの出会いの場が広がるのではないでしょうか。 　

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

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

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

PixelCrayons is an esteemed digital consulting and engineering firm, providing comprehensive software solutions to a diverse clientele, including enterprises, independent software vendors, digital agencies, and startups. Established in 2004 and based in India, PixelCrayons has delivered exceptional service to over 5,400 clients across more than 38 countries, achieving an impressive client retention rate of over 97%. The company is renowned for its agile/DevOps development methodologies, SLA-driven approach, and punctual project delivery. For more details, check out our latest services - Digital Transformation Services Social Media Marketing Services Blockchain Development Services digital marketing consulting services PPC Management services Digital Marketing Services SEO Services

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