B2Cサービスである「旅ぷら」に掲載している全国27都道府県の公式観光スポットコンテンツを活用し、ホテル、旅館、民宿等宿泊施設がおもてなしサービスを容易に提供できるB2B2Cサービス「旅コン」（旅のコンシェルジュサービス）を準備中です。サービス開発に興味を持って頂ける方、販路開拓にご協力頂ける方、オープンデータ化に向けた取り組みにご協力頂ける方を集っております。

シビックプライド「横浜をもっと好きになる。」に関するアイデア

オガルコはスマホで給食献立が見られるサービス ミートソースのシミをつけて帰ってくるのは元気に育（おが）っている証拠。 でも、ママのお気に入りの服だとちょっとがっかり。 朝の忙しい時間でも、スマホから献立が見られれば、ミートソースの日は「濃い色の服を着て」学校に送り出せる・・・ 学校でカレーライスだったのに、夜もカレーライスにしてしまった・・・ そんな声が友人から上がったことからスタートしたオガルコは、給食の献立を、冷蔵庫まで行かなくても、スマホで手軽に見れるようになったら、子供の服を選ぶ時、出先で急な買い物する時に、便利「かも」しれないということから制作しました。 さらに出張に行っている頑張るパパも、オガルコで我が子が何を食べているか、帰ってきた時の会話に。「パパの頃は揚げパンがもう少し油っぽかったぞ!!」 意外と子供の給食献立を見ている人は多いと聞きます。しかし、それらは紙だったり、学校のサイトにあるPDFだったり。 ちょっと「手軽」ではなかったりします。 手軽に・簡単に・スマホでがコンセプトです。 これは、 保育園マップ→保育所数が少ない・待機児童がほぼ無い 「都会の問題が田舎の問題とは限らない」そんな考え方から、「田舎でも使えるサービスを」というもくろみもあります。 また、田舎では技術者がいない・少ないため、「アイデアのハウモリ」・「技術のダッピスタジオ(Code for Sapporo)」と、北海道のシビックテック団体関係者のマッシュアップサービスです。 自治体や学校では学校給食の献立オープンデータはほとんど無いように思えます。 それは、利用頻度があるのにこれまで利用するサービスがなかったから。 このオガルコが広まり、5374や保育園マップのようになればいいなあと考え、Code for Kanazawaさんの5374の運営に影響を受け、ogaruco.netのサブドメインを無償で提供しています。 ※現在は、それに、みんなが「あったら便利っぽい」ものをどんどん追加しています。永遠の「開発中」オガルコです。 「おがる」とは、北海道地方の方言で「育つ」という意味。おがる子供。オガルコもどんどんいろんな方の利用やカスタマイズで、田舎の便利なサービスとしておがっていけばいいなあと思います。 ぜひ興味のあるかた、改造したい方は、ハウモリgithubから利用ください!! https://github.com/howml/ogaruco

2014年11月27日に行われた [アイデアソン]旧東海道再発見！アプリと歩こう～シビックテックが結ぶ宿場町～において発表されたアイデアです。

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

【エントリー部門】アイディア部門【応募者属性】社会人【応募者名】 ナカヤ　タエ【エントリー作品の権利指定】 CC BY-NC-ND【エントリー作品のURL】http://la-bonheur.co.jp/ 【利用しているオープンデータ】現在はなし 　（活用希望）【利用しているパートナーリソース】一般社団法人離婚準備支援協会【エントリー作品の詳細説明】３組に１組離婚するといわれている昨今。結婚後の女性は常に離婚のリスクにさらされている。結婚・離婚産業では離婚率の割に離婚予防や離婚後のフォローができていない現状がある。未病と呼ばれる段階の結婚生活がスタートする前から離婚を意識する迄のリスク予防や、結婚後や離婚後に起こりうる危機を予測しアドバイスする事で、女性を離婚のリスクから守らなければならない。 弊社はRe婚相談所を相談窓口とした直接支援と連動したアプリ・SNSの活用で結婚生活や離婚に悩む女性への支援をする一方、結婚・離婚業各者から集めたデータやオープンデータを活用し問題の解決や離婚予防、離婚後のリスク回避の為に役立つ情報提供をしていく。 また、幸せな結婚生活を維持し、幸せな夫婦・家族をふやす為の研究を「Ｌａ＃Ｂｏｎｈｅｕｒ」という機関で行う。そのための１つ目のツールとして夫婦の価値観を可視化するための円満ピザチェックというチェックツールをシステム化中。 　結婚生活に不満を抱え主観的幸福度が低下している女性から、心から幸せを感じられる生産性の高い女性への変換を増やし、政府の掲げている主観的幸福度の向上という課題にチャレンジする。Ｂｏｎｈｅｕｒの女性活躍支援により、結婚生活に幸せを感じられるようになった輝く女性が１億総活躍社会をリードしゆく新しい人材へと変わっていくように結婚・離婚産業一丸となる為の中間支援としてデータ活用を目指していきたい。アイデアを活かすため御指導頂きたい。

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

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

政府統計の中で一番アクセスが多い貿易統計を、全部入りのＣＳＶとしてダウンロードできるようにしてあります。発表されてから一週間以内にＣＳＶ化しています。 2016年11月までデータをいれました。

舞妓さんの撮影会を実施し写真のオープンデータ化をすすめています。 この魅力的な写真をSNSで発信していますが、画面が小さくリアルな迫力には大きく欠けます。 そこで、大画面の4Kテレビに、4K画質の舞妓さんの姿を放映して迫力ある映像を実現するためにアプリ「Maiko TV 4K」を開発しました。 4KテレビとApple TV 4Kを組み合わせると迫力の4K映像が実現します。 また、iPhone／iPad用アプリ「Maiko TV」も同時にリリースしています。 世界の多くの方々に見ていただく機会を作ることで『オープンデータで地域文化「京都の花街文化の魅力」の発信が持続するエコシステム』の質を高め持続力を強固なものにします。

地域の課題を解決するためのアイディアを考えよう！ ～アーバンデータチャレンジ2014×Linked Open Data チャレンジ Japan 2014～ のアイデアソンの成果です．

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

現在日本には国公立、私立全てを併せて780校ほどの大学があるが、そこでの教育内容に関しては、シラバスという形式で、その科目の詳細が公開されている。しかし各大学で公開レベルやフォーマット、スキーマなどが統一されておらず、学外からそれらを閲覧することするら困難である。本プロジェクトでは、大学のシラバスをオープン化し、大学教育を俯瞰することを目指す。

サービスというものは無形で属人的な部分があります。そにてそのサービス内容であるContentには提供する側と受け手側の価値観の違い、情報の非対称性の問題があります。今回それを限りなく見える化し、幅広く一般のサービスデザインのイノベーションを促進するデザインフレームワークを提供するものです。これにより今後のオープン化された情報がＬＯＤという情報の共有基盤上にデータとＡＩアプリケーションとのメタ・メタレベルでの融合を図ることができます。つまり意志や意図、意味による文脈的結合です。 詳細な内容はリンクＵＲＬの関連ページをご参照ください。具体的には、その観光スポットを紹介するムービーや概要を示すものをContentとして定義し、それに地理情報や観光サービス情報やWikiなどの情報＝metaContentとし、その情報リソースのＵＲＬなどをメタデータとします。 ここで、更に加えるに上述の旅行者の行為を促す動的な意味‐意図情報をメタメタデータと定義し付加します。これは観光関連での事例ですが、データセットをこのような基本構造をもたせることで、サービスやコンテンツ設計のイノベーションを興すことができます。サービス提供側と受け手の価値観を見えるかしマッチングさせ個別対応をコストアップなしに実現すること、関連するデータがＬＯＤのようなオープンな気情報基盤で実現することが本アイデア提案の狙いです。 イノベーションのもう一つの側面は、コンテンツ作りの生産性を著しく向上、個別対応を行うときに、その変更や再編集をできる限り自動化することです。本アイデア提案に使用されているＭＭオーサリングツールはノンプログラミングでメタデータを生成します。今回そのメタデータにさらなるメタメタデータなるものを付加し、データ自身に動的な意味合いを与えることができます。 今後のサービス設計やコンテンツ設計にはＡＩの導入がどんどん行われてきますが、今回のようなデータ、メタデータ、メタメタデータ構造（スキーマ）を標準化しＬＯＤに登録公開することで、データに関する意味や意図に基づいたデザインを行う基本的なフレームワークを提供します。今回の対象素材はマレーシア　クアランプールですが、ＬＯＤチャレンジ2014でデータセット部門で提案した「神奈川名所31」に関しても同様の作業を進めていきます。既に提案応募時点でcept,Contextメタ情報を書き込む入れ物を用意してあります。 更新: 2017年1月15日 説明追加情報 http://idea.linkdata.org/idea/idea1s2190i

横浜市内在住の有志の自宅に設置された加速度センサーユニットで観測された地震波形を、加速度データとして展開。 加速度データを利用することで、震度の計測ができ、また建物内で複数箇所に設置されることで波形の比較ができ、震源方向の予測や建造物による揺れ方の違いなどの調査が可能となる。

昨年は会場規模、参加人数ともに世界最大規模での開催となりました。今年も大さん橋で開催します。

横浜市18区のデータです。

全国のレッサーパンダの戸籍みたいなものを目指して。

オリンパスのオープンプラットフォームカメラ OLYMPUS AIR A01 http://olympus-imaging.jp/product/opc/a01/ に対応したアプリ。 2015 OPC HACK & MAKE AWARD アプリ部門賞受賞

〜 地方の歴史を観光資源に 〜 金沢の街は戦災を免れ、百万石の財力が作った寺社仏閣、江戸時代の道筋や用水などが多く残っています。 古地図を見ながら歩けば、それまでは気にならなかった「路傍に残る石組み」「道幅の変化」「ちょっとした高低差」など普通に歩くだけでは気づくことが出来ない昔の姿が感じられます。 そして古地図には無い道や用水の暗渠化などから街の発展を知るという楽しみもあります。 検索機能では、茶の湯に携わってる方ならご存知の「千　宗室」や「本阿弥光甫」など有名人の屋敷があった場所もわかるほか、「大工」や「石切」「板前」「いしゃ」「外科」「掃除坊主」「馬のり」などいろいろな職業の人を探すのも楽しいです。 時代小説に出てきたあの人がどこに住んでいたのか　など検索してみるのもいいと思いますよ。 金沢市民のみならず、金沢へ観光に来た方も、このアプリを片手に金沢の旅を楽しんでみてはいかがでしょうか。 ●「古今金澤」の特徴 ＜絵図上での現在位置表示機能＞ 古い絵図では重要なものが大きめに描かれていたり向きが正確ではなかったり、場所ごとに細かなズレがあり全体として現在の地図と重なることはありません。 「古今金澤」では金沢工業大学との共同研究で得られた正確な補正データを使い、独自のズレ補正によって現在位置を表示しています。 ＜強力な検索機能＞ 絵図にくずし字で記載されている寺社名や人名の検索が可能で、検索結果は現在の地図と絵図上に表示。 また、絵図上に書かれたくずし字を長押しすると書かれた文字がふき出しで表示され、ふき出しをタップするとWeb検索ができます。 江戸時代の金沢について書かれた金澤古蹟志（かなざわこせきし）に記載された場所の検索も可能で、その場所についての記述内容を閲覧できます。 ＜古絵図との写真撮影機能＞ 古い町並みが残っている金沢。昔からある道路や今は地中に隠れてしまった用水等の写真を、その場の古絵図・現在の地図と共に写真に収めることができます。撮影した写真は簡単にFacebookやTwitterで共有可能です。 ●利用しているオープンデータ 石川県金沢市が公開している下記 ・　歴史のまちしるべ標柱一覧 ・　坂道標柱一覧 ・　用水・字地・街道標柱一覧 ・　寺院・文化財等の解説文 ●その他許可をいただき利用させていただいているデータ ・寛文七年金沢図（石川県立図書館　様） 　デジタル化されたデータを利用させていただきました。 ・位置補正データ（金沢工業大学 環境・建築学部建築系建築デザイン学科 増田研究室） 　古地図と現在地図の位置情報について共同研究させいていただきました。 ・古地図上の人名データ（金沢城調査研究所 木越所長　様） 　古地図上にくずし字で記載された寺社や人名を全て活字にしたデータを利用させていただいております。 　これらを古地図にマッピングし、くずし字で記載された人名を長押しすることで活字が表示されます。 　表示された活字をタップすればGoogle検索できます。 ・金澤古蹟志（金沢市立玉川図書館） 　江戸時代に加賀藩に仕えていた武士が記載した金沢の百科事典とも言われる歴史書。地名の由来や逸話などが十二編３４巻にまとめられています。 　金沢市立玉川図書館のサーバで公開されている金沢古蹟志へのリンクを張らせていただいております。 　https://www2.lib.kanazawa.ishikawa.jp/reference/kosekishi.htm ・金澤古蹟志との関連場所データ（金沢歴活主宰　安藤 竜 様） 　金澤古蹟志に記載されている内容から関連する場所を見つけ出し、金澤古蹟志の記載箇所と位置情報のリンクデータを作成していただきました。

アイデア：「こども110番の家」をもとにしたデータセット(API) http://idea.linkdata.org/idea/idea1s1391i 新潟市東区内で、店先に「こども110番の家」の看板が掛っている店舗位置情報をリスト化(途中) ※手元に情報がなかったので、対象地域の店舗を順番に回って「こども110番の家」看板有無を確認して周った。リスト化対象の店舗についての情報は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」」に記します。

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

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