1 / 40

AllegroGraph で作る セマンティック Web アプリケーション

AllegroGraph で作る セマンティック Web アプリケーション. 慶應義塾大学理工学研究科 藤井 遼 roy@ae.keio.ac.jp. 目次. これは誰？ これが Franz だ！ AllegroGraph 概観 デモ 考察. これは誰？. Who is 藤井 遼 ? （ General). 慶應義塾大学大学院 理工学研究科 開放環境科学専攻　 1 年 ただの学生です 専門 機械学習 自然言語処理 データマイニング Not 計算機科学. Who is 藤井 遼 ? （受賞暦 ). 2007 年度

deon
Download Presentation

AllegroGraph で作る セマンティック Web アプリケーション

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. AllegroGraphで作るセマンティックWebアプリケーション 慶應義塾大学理工学研究科 藤井 遼 roy@ae.keio.ac.jp

  2. 目次 • これは誰？ • これがFranzだ！ • AllegroGraph概観 • デモ • 考察

  3. これは誰？

  4. Who is 藤井 遼?（General) • 慶應義塾大学大学院 理工学研究科 開放環境科学専攻　1年 • ただの学生です • 専門 • 機械学習 • 自然言語処理 • データマイニング • Not計算機科学

  5. Who is 藤井 遼?（受賞暦) • 2007年度 データ解析コンペティション学生部門入賞 • 結果が出てないのに 賞をもらって申し訳ない • しかも何故か事前に設定　　　されていない賞をもらった

  6. Who is 藤井 遼?（About Lisp) • 第2世代Lisper • 数理システムでアルバイト中 • Lispでコーディング中 • Franz, Inc.に今夏internshipしてきた • 今回の話題

  7. What is“Lisper the Second Generation”? • Lisper, as the child of Lisper • 父親もLisper • ただの造語です • 初めて読んだ「コンピュータの本」がSICP • 授業の宿題から研究用コードまで、ほとんどCL

  8. まとめ：藤井 遼とは • ちょっとLisp環境に恵まれていた • ちょっとLispに詳しい • ただの学生

  9. これがFranzだ！

  10. この発表の内容 • Franz, Inc.でやってきたinternshipの内容をお話したいと思います • AllegroGraphのクールなdemoを作ろう！ • Demoの紹介なので、実質は宣伝です

  11. Internship概要 • 期間 • 2008/8/7 ~ 2008/9/22 • 夏休みの間中、ほぼ6週間 • うち、コーディングしてたのはほぼ4週間 • 遊びに行ったところ • San Francisco • Redwood National Park • Google • 仕事ほっぽらかして遊びに行っても大丈夫！（嘘

  12. 知られざるFranz, Inc.の実態 • とても静かなオフィスです • というか人が居ない • 自宅で働く人も多いみたい • そこらへんにSymbolicsマシンが転がってる • 初めて見ました

  13. AllegroGraph概観

  14. AllegroGraphとは • セマンティックWebアプリケーション • 何億ものtripleを高速に処理 • 便利な機能がいろいろ • ACL/Javaで使える • Allegro Prologによる論理的検索 • もちろん、functionalな検索インターフェイスも

  15. AllegroGraphの機能 • よくあるオントロジとそれにまつわる検索 • 位置関係 • 時間関係 • 社会関係分析 • 継承・同値・逆の関係 • データベースの合併

  16. 基本手続きと例（１） • 位置関係(geospatial-reasoning) • 地点(lon,lat)から radius km離れた地点を探せ • Function: (get-triples-haversine-km subtype pred lon lat radius&key …) • 時間関係(temporal-reasoning) • 時点pt1より前の時点pt2 • Functor: (point-before ±pt1 ±pt2) • 社会関係分析(social-network-analysis) • 人物pを含み、互いに知り合いであるグループ（clique）を探す • Function: (cliques p generator…)

  17. 基本手続きと例（２） • 継承・同値・逆の関係(rdfs++-reasoning) • subClassOf, inverseOf, etc. • オントロジとのfedereation-triple-storeを作る • Function: (apply-rdfs++-reasoning) • データベースの合併（federation） • 複数のtriple storeを合体して、ひとつのデータベースのごとく扱う • 共有されているweb上のdbを合体させる • Function: (federation-triple-store namestores &key)

  18. デモ

  19. おでかけ提案システム • 離れた場所に住んでいる人たちが、映画を見に行く • SNA • 他にも誰か誘える人は居ないか • 彼らが「共通に」楽しむことが出来る映画を推薦 • geospatial • 映画の後に近所の店で飯を食う • temporal • みんなが特定の上映開始時間に集合する • 乗り換え情報 • 個人の予定 • みんなの負担（時間＆料金）を平等に！ • rfds++ • 「学友」「同僚」の親クラスは「知り合い」 • 映画ジャンルの継承関係？

  20. デモ • うまくいったら貧弱なデモ画面をご覧ください • もしダメだったらバックアップファイルで 雰囲気だけでも • Google Transitに問い合わせるので遅い • さすがに4週間でフルの乗り換えシステムは無理 • 今後直接運行データをクエリする予定

  21. 各要素のクエリ • 映画の推薦 • メンバー全員がある程度「好き」なものを探す • メンバーの推薦 • 知り合い関係の中から、映画を「好き」そうな人を探す

  22. 映画が「好き」？ • 推薦アルゴリズムは？ • デモの本質じゃないので突っ込まないでください • 今回は、以下のようにした • 各個人は好きな映画の「属性」をいくつか持つ • 映画がその属性を持てばスコアを＋１ • 個人の持つ「属性」は、映画鑑賞履歴から推定する • 「属性」＝ジャンル・キーワード • 適当なのは十分承知しています

  23. 各要素のクエリ • 映画館の推薦 • 求める映画を上映いる映画館の中から、メンバーの 乗り換え時間・費用の平均・分散が小さいものを選ぶ • 用事があって上映時間に間に合わない場合、 乗り換えコストは無限大とする • レストランの推薦 • 映画ほど嗜好が安定しないので、履歴は無視 • ユーザの要望を全て満たすレストランの中から 地理的条件が良いものを選ぶ

  24. 映画から、食事から？ • 映画館とレストランは近所だといいな • いい映画館の近所に中華料理屋がなかったら!? • 二つの方策 • movie-first-search • 映画、メンバ、映画館、レストラン、の順に探す • restaurant-first-search • レストラン、映画館、映画、メンバ、の順に探す • 引数の特定度から、「答えが見つかりそう」な方策を選びまずはそれを試す • 片方で失敗したら、もう片方も試す

  25. データベース • 映画 • imdbのサブセット • レビューなど、不要なものは捨てた • 327932本のデータ • うち「上映」されているのは220本 • 映画館 • SF Bay Areaの60箇所

  26. データベース • レストラン • SF Bay Areaの2000店のデータ • 人 • 2000人 • 約30人ほどの知人 • 映画鑑賞履歴 • 趣味 • 「実はあいつ嫌い」 • 架空データ

  27. 人間関係捏造の涙ぐましい努力 • 鑑賞履歴がランダムだと、友達と趣味が合わない！ • つまりメンバ推薦不能 • でも普通、友達って趣味が合うから友達のはずなんだが • 以下のように人間達を創る • 人間の群れを作る • 学校・会社・サークル等の小グループに分ける • グループ内はclique、そして共通の興味を持つ • 映画鑑賞は興味にバイアスを受ける • ただし、一人の人間は複数のグループに属す • 映画推薦に興味を使わないことでリアリティを保つ

  28. 性能 • デモ用のクエリ一回につき • 答えが見つからないことはまずない • 計算にかかる時間は最悪でも10sec以下 • 残りは全部Google Transitへの問い合わせ（笑） • 乗り換えの概算をdbに入れたりしてこれでも早くなった • 最適解（？）は保証されない • beam-searchしているため • 乗り換えと好み、どちらが大事か決められない • triple-storeのサイズ • (triple-count) => 20,473,486

  29. 考察

  30. メリットとデメリット • セマンティックWebを使うメリット・デメリット • ここでの「セマンティックWeb」は、 tripleで表現されてRDFで共有できるようなデータ構築方法を指す • セマンティックWebアプリの中でも、AllegroGraphを使って作るメリット・デメリット • AllegroGraph以外使ったこと無いので、 比較論では無いことをご容赦ください • 「デメリット」というよりは、「解決すべき課題」

  31. セマンティックWebのメリット(1) • データ共有、外部データの利用が容易 • RDF • きちんとした仕様 • 述語に関する演算 • subClassOf, sameAs, etc. • 直感的に分かりやすい

  32. セマンティックWebのメリット(2) • RDBMとの比較 • テーブルという構造単位が無い • 行（属性）毎のデータ型定義は無い • 標準形への分割の必要が無い • プロトタイピングに強い • データの定義がプログラムで宣言的に表れない • 脳内定義だから修正が楽 • あとで宣言的に書けるマクロを被せればいい • 修正中にテスト用データを作り直す必要が無い • 属性を自在に足したり引いたりできる

  33. (defun make-random-person (gender age-mean) (destructuring-bind (first middle last) (make-person-name gender) (with-blank-nodes (person) (add-triple person !rdf:type !foaf:Person) (add-triple person !foaf:firstName (resource-symbol first "ex")) (add-triple person !foaf:middleName (resource-symbol middle "ex")) (add-triple person !foaf:lastName (resource-symbol last "ex")) (add-triple person !foaf:gender (resource-symbol gender "foaf")) (add-triple person !foaf:age (value->upi (+ (random 10) age-mean) :int)) セマンティックWebのメリット(3) 住所・今日の予定を足したいな… (iterate-cursor (triple (get-triple :p !rdf:type :o !foaf:Person)) (let ((person (subject triple))) ;; geo (multiple-value-bind (lat lon city) (make-random-latlon) (add-triple person !g:isAt (longitude-latitude->upi *default-striping* lon lat)) (add-triple person !ex:nearestCity city)) ;; temporal (multiple-value-bind (start-time-string end-time-string) (make-random-booking) (with-blank-nodes (start end interval) (add-triple start !t:time (date-string-to-upi start-time-string)) (add-triple end !t:time (date-string-to-upi end-time-string)) (add-triple interval !t:startpoint start) (add-triple interval !t:endpoint end) (add-triple person !ex:booked interval))) person))) 既存のクエリの変更は不要 すぐに新しいクエリを作れる 足したコードを既存のpersonに 対してtop-levelで実行すれば テストデータの修正も出来る

  34. セマンティックWebのデメリット • 共有されているデータが無い • 公開されているオントロジはあまり多くない • 無料で、となると更に少ない • 多くの企業は、情報を秘密にしておくほうが自身の利益になると信じている • メリットがお題目になっている • 活発に研究がなされている • 技術的に枯れていない • 仕様が変更される可能性

  35. AllegroGraphのメリット(1) • Lispで使える • Javaでも使える • 検索言語としてのProlog • 書き方間違えると凄く遅いので注意 • 検索言語としてのSPARQL • 使ったこと無いので分かりません＞＜

  36. AllegroGraphのメリット(2) • 実用に耐える高速な検索 • 実用的なプリミティブ • Geospatial • Temporal • SNA • RDF++,OWL

  37. AllegroGraphのメリット(3) • プライマリキーは（明示的には）要らない • 「ノード」はオブジェクトとして扱える • blank-node • make-instanceに初期値をkeywordで渡すより、　　　個人的にはコードの視覚的圧迫が少なくて好き • 外部とコミュニケーションする際は、　　　　　　　　　あったほうがいい場合も（後述）

  38. AllegroGraphのデメリット(1) • まだ活発に開発中 • 仕様が変わるかも • 2.0から3.0への移行時の変更例 ;; in AllegroGraph 2.x ;; グローバル変数 *use-reasoner* の値でreasonerを使うかを判断 (setf *use-reasoner* t) ;; in AllegroGraph 3.x ;; reasonerはtriple-storeオブジェクトの「中」に含まれる ;; reasonerを使えるdbを返す新たな関数が定義された (apply-rdfs++-reasoner) (apply-rdfs++-reasoner my-db)

  39. AllegroGraphのデメリット(2) • federationに関する課題 • 2つのDBを合併し、その間に関係を足す場合 • 挿入と検索を交互にやると遅い • federation-triple-storeには直接add-triple出来ない • blank-nodeをキーに出来ない 「あるtheater」で「あるfilm」が 「何時から何時まで」上映されるか、 Scheduleを投入したいのだけど…？ movie federation film(imdb) theater

  40. まとめ • RDBMSで開発するなんてやめよう • 直感的なモデルで開発するほうが楽しいし • triple-storeの方がなんかLispっぽい • Lisperが実世界を相手に大規模な開発を　　するなら、AllegroGraphをご検討ください

More Related