Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

プラネタリウムなび紹介 20150912

73 views

Published on

2015/09/12
第一回 LOD Challenge Day KOBE
プラネタリウムなび紹介資料

Published in: Software
  • Be the first to comment

  • Be the first to like this

プラネタリウムなび紹介 20150912

  1. 1. プラネタリウム案内アプリ 「プラネタリウムなび」 の紹介 2015/9/12 CIJソリューションズ 加藤敦丈
  2. 2. 「プラネタリウムなび」とは •日本のプラネタリウムの情報を一覧できるWebアプリ •メーカー、機種名、ドームサイズ、現役機種/引退機種、 施設名などの条件にて絞込みが可能 •検索した施設への交通案内機能 (GoogleTransitへリンク) •誰得感漂うアプリケーション
  3. 3. 「プラネタリウムなび」とは http://museums-info.net/planetarium/navi/
  4. 4. プラネタリウムの条件を 指定して検索 検索条件に該当する 施設一覧を表示 施設詳細・保有装置情報 の表示 機種情報詳細 の表示 地図 レイアウトはMaronry によって動的に変わる 施設名を 指定して検索 各ウインドウは 開閉可能
  5. 5. 作成までの経緯 1.プラネタリウム巡りを趣味としている。 (「ツァイス巡り」完走) 2.プラネタリウム施設のまとまった情報が少ないことに 気づく。(当時) 3.ないなら作ろう。 4.どうせ情報を収集するならLODにすれば便利では。 (←心の声)
  6. 6. 作成までの経緯 5.作った。 6.データセット閲覧用のアプリもついでに作ろう。 7.作った。 (面倒だったので、先に作っていたアプリ 「動物園なび」のコードを流用) 8.せっかく作ったのでLODチャレンジに応募した。
  7. 7. 作成までの経緯 •プラネタリウムのデータセットを作成するのが本来の目 的で、閲覧用アプリは「ついで」だった。 •別途応募した「動物園なび」、および、そのデータセット が本命で、プラネタリウムのデータ・アプリは「ついで」 だった。 •「動物園なび」のほうがデータセットのサイズも大きく、ア プリの機能もリッチ。
  8. 8. 地図 姉妹アプリ 「動物園なび」。 本当はこちらが本命でした。
  9. 9. 作成までの経緯 •LODチャレンジ2012 「疾患連鎖LOD」 ライフサイエンス賞受賞 → チームで作成 仕様を元にコードを書いただけ
  10. 10. 作成までの経緯 •LODチャレンジ2013 「疾患コンパス」 アプリケーション部門優秀賞 → チームで作成 仕様を元にコードを書いただけ
  11. 11. 作成までの経緯 •LODチャレンジ2014 そろそろ「100%自作の作品」を作りたい → 「動物園LOD」「動物園なび」 「プラネタリウムLOD」「プラネタリウムなび」 を応募
  12. 12. アプリ部門にて 最優秀賞をなぜか受賞
  13. 13. 何が受けたのか?(自己分析) 1.アプリが一応ちゃんとまとまっていた。 2.データセットが一応破綻なくまとまっていた。 3.「動物園なび」のアプリ・データセットとまとめて評価さ れたのでは。 4.プラネタリウムというニッチなデータだったことが受けた のかも。
  14. 14. 何が受けたのか?(自己分析) LODの人 プラネタリウム の人 めずらしい ベン図による論理的分析
  15. 15. 何が受けたのか?(自己分析) 珍獣がもてはやされるのと同じ理屈
  16. 16. 何が受けたのか?(自己分析) LODの作成は 問題意識を持ち解決方法を模索する 意識が高い人 だけのものではない
  17. 17. コンテストで入賞すると けっこう儲かります
  18. 18. ここまでのまとめ •LODの作成はそんな大上段に構えるようなもので はない •そのLODを作れるのは自分だけかもしれない •自分で作るとなんか楽しい •うっかりなんかに入賞するとけっこう儲かる
  19. 19. 「プラネタリウムなび」の作りかた
  20. 20. 「プラネタリウムなび」の作りかた 1. プラネタリウムLODを整備、公開 2. 整備したLODを利用するアプリを作成、公開
  21. 21. プラネタリウムLOD整備 1. プラネタリウムの情報をGoogle Docに蓄積、整 理。 2. 整理した情報を、自作ツール(Javaアプリケーショ ン)にてRDF形式に変換。 3. 変換したRDFを、SparqlEPCUにて公開。
  22. 22. プラネタリウムLOD整備 •Subjectリソース(主語となるリソース)を、 種類毎に ・クラス(概念) ・インスタンス(実体) ・リソース(概念か実体か区別しなくてよいもの) に分類し、固有のURIを付与。
  23. 23. プラネタリウムLOD整備 Subjectリソース間の関連は矛盾が発生しないよう 設計しないといけない。
  24. 24. プラネタリウムLOD整備 設置館 機種 Has •当初のデータ構成 これは駄目
  25. 25. プラネタリウムLOD整備 •なぜなら •「実体」と「概念」がゴチャゴチャ •ある機体がある設置館から別の館に移動したよ うなケースを表現できない •機種のリプレースが発生したときどうする? •ドームサイズや座席数、座席種別、ドーム傾斜 角度を持つのは「設置館」でも「機種」でもない など。。。。。
  26. 26. プラネタリウムLOD整備 設置館 ドーム (実体) Has •現在のデータ構成 これなら一応OK 装置 (実体) Has 機種 (概念) Is メーカー MadeBy
  27. 27. プラネタリウムLOD整備 設置館 ドーム (実体) Has •こうしたいデータ構成 装置 (実体) Has 機種 (概念) Is メーカー MadeBy ドーム 情報 Has
  28. 28. プラネタリウムLOD整備 • 装置情報(インスタンス) • 機種情報(クラス) • ドーム情報(インスタンス) • 設置館情報(リソース) • メーカー情報(リソース) •現在のSubjectリソース種別
  29. 29. プラネタリウムLOD整備 •一度矛盾がないデータを作っておくと、利用条件 の制限が少なくなる(理想的には「なくなる」)ため、 再利用しやすい。 •せっかく作ったデータが再利用できないのは残念。 •ちょっと面倒でもここだけはちゃんと検討したほう がよい。 (Ontologyによる概念化が有用)
  30. 30. プラネタリウムLOD整備 •LODリソースは名前解決できることが望ましい。 (リソースに割り振られているURIにアクセスしたと き、情報が取得できる) •プラネタリウムLODのリソースには自前のドメイン を割り振り、自前のサーバにて名前解決可能とす るサービスを仮整備している。
  31. 31. プラネタリウムLOD整備 プラネタリウムLOD/動物園LODのデータについては 名前解決可能とした
  32. 32. プラネタリウムLOD整備 •データのRDF化には、ツールが何種類も整備され ているので、わざわざ自作ツールを用意する必要 はない。 (LinkData.org、LODRefineなど) •CSVデータはだいたいRDF化が可能。 ※データのメンテナンスコストは考慮が必要
  33. 33. クライアントアプリ作成 •HTML+JavaScript+cssにて構築。 •JavaScriptのライブラリとして、 jQuery、Google Maps API、Open Street Maps API、 Masonryを利用。
  34. 34. クライアントアプリ作成 •サーバーサイドは純粋にhttpdのみ。 •必要ファイルを全てローカルにダウンロードすれ ば、サーバがなくてもブラウザのみで動作するシ ンプルな構成。
  35. 35. クライアントアプリ作成 •利用データはLODのみ。 (固有のDB(MySQLなど)は未使用) ・プラネタリウムLOD(自分で整備) ・DBPedia日本語版
  36. 36. まとめ •アプリケーション自体はごくシンプルで、特別な・ 高度な技術は何一つ利用していない。 •逆に言えば、LOD利用アプリケーションを作成す るには特殊な技術は不要。
  37. 37. まとめ •LODを作る際はデータ構造に矛盾が生じないよう 気を配るとなんとかなる。 •ただし、メンテナンスコストは考慮したほうがよい。
  38. 38. まとめ •LODを整備すれば、さまざまなデータを利用した アプリケーションが、誰でも簡単につくれるように なる。 (「動物園なび」から「プラネタリウムなび」への 作り替えには一日程度しか掛けていない)
  39. 39. まとめ •整備するデータは大上段に構えた意識高いもの でなくてよい。 •どんどん誰得なLODを作りましょう。 •どんどん誰得なLOD利用アプリを作りましょう。

×