かしわ進化論。

2010年11月8日月曜日

JPEG画像からGPS情報を取り出す

以前、ぼーっとテレビを見ていたところ、
有名人のブログからその人の行動を詳細に推測する番組が放映されていました。

その中で、
「スマートフォンで取った画像からGPS情報を取り出し、その位置を特定する」という技術が目についたので、少し調べてみました。

詳しく書かれているブログを発見したので、詳しいロジックはこちらをご覧ください。

実際に実装して簡単に調べてみたところ、
・有名人 → 有名な人はやはりそこらあたりしっかりと情報を守っている。
・ジオタグ付きiPhone写真 → 読み込み可能

・・・むむむ、やはり調査開始から30分では限界がありました。

なんとこのブログを書いた人、
知る人ぞ知る、「ナイスマンホ」で有名なマンホールマップシステムを作った人らしいです。
（マンホールマップでは実際にこの機能が実装されていました）

このシステムをうまく使えば、
いろいろな遊びができるのではと思いつつ、そんな気はさらさらないよという僕でした。

2010年11月6日土曜日

【論文紹介】モバイルサービスのタスク指向型メニュー搭載を目指して

著者：笹島　宗彦,　來村　徳信,　長沼　武史,　倉持　正治,　溝口　理一郎
keyword: モバイルサービス、オントロジー、ユーザモデル

この論文は、日常生活行動のオントロジー(意味づけされた階層辞書)に基づいてユーザの行動モデルを構築する方式を提案し、携帯電話から利用されるインターネットの現実的な利便性向上を目指した実証実験について述べている。

現在の携帯電話サービスは交通、地域、グルメなど各サービスが属するコンテンツ毎に分けられているため、ユーザは必要なサービスがどのコンテンツに所属するのかまず考えなければならない。

しかし、筆者らが提案したタスク指向型メニューは、ユーザの状況やしたいこと(電車に乗りたい、宿が満室、食事をしたい)をキーにしたメニューを表示し、ユーザに携帯電話サービス(乗換案内や宿泊施設情報、グルメ情報など)を提案する。

そして著者らは、タスク指向型メニューを実規模に拡大するための方式としてOOPSモデルを提案する。
1.はじめに、モバイルサービス事業者は、自分の言葉でモバイルサービスを受けるユーザのモデルを記述する。(どのデパートに行くか決める、買い物に行く、帰宅する、)
2.次に、モバイルサービス事業者のモデルを、オントロジー設計者がオントロジーを参照して定義された語彙に変換する。(デパートに行く→デパートに移動する)
3.そして、モバイルメニュー設計者は変換された語彙を用いてモバイルユーザの行動モデルを作成する。
4.最後に、モバイルサービス事業者が自身のサービスが当てはまる行動モデルを選択することで、実際のモバイルサービスに反映される。

膨大な数に及ぶユーザの行動を一般化し実タスクの規模に拡張するために、タスク概念(計画、診断、設計など)を体系化したタスクオントロジーを用いた。例えば、2004年度のi-modeサービスを構成するサービス名称9162件をタスクの種類に分類したところ、調べるが30.1%を占め、上位10種類の同士で全体の94.1%、上位20種類で97.5%を占める結果が得られた。つまり、少ない語彙で多くの対象を分類することが出来たと言える。
そして、NTT　DoCoMoが提供するi-modeサービス9,162件に対して、筆者らが構築したOOPSモデルに現れていない状況を想定したものは199(2.17%)に過ぎないという結果が得られ、現状のモバイルサービスをほぼすべて含むことができたと述べている。

筆者の笹島氏はこの研究を元に、タスクオントロジーを利用したアンビエントな車内空間の実現について研究している。車内、車外センサーとタスクオントロジーを組み合わせて運転者の状況、好み、性格を認識し、その時々に合わせて自動的に車内の温度や空調、ラジオ、音楽を変更するシステムの構築に取り組んでおり、オントロジーの実用化に向けて尽力されている。

2010年11月5日金曜日

【BreakTech】100年変わらないコンピュータの仕組み vol.1

【BreakTech Vol.1 】
＞＞アサカツ：かしわ進化論。では、

朝７時から学生とMr.Hによる役に立たないコンピュータ勉強会やってます★

今までネットワークについて学んできました。

前回はIP通信について学び、

WireSharkを通して情報が”ダダ漏れ”してる様子を

見てきました。

→WireShark

TCPとはなんぞや？

だってIPでパケットって送れてるやん！

実は、IPは相手の場所を特定して情報を”送っている”けど、

相手に”正確に届いた”ことを保証するものではないんです。

・・→ダダ漏れの理由はIP通信です！

そこで、”相手にすべてのパケット情報が正しく届いたこと”を

確認するのが”TCP”です。

送られるパケットは入れ子になっていて、

TCPのデータはRFC973に情報の書き方が整っています。

で、サーバーとクライアントの情報の通信は、

開始・終了時にどんなことが起こっているのかが、

しっかりwikipedia教科書には記されています。

この情報はコマンドプロンプトで

netstat

netstat -n

と打ち込むと情報がみえてきます。

プロトコル　ローカルアドレス　外部アドレス　状態

がわかります。

↓こんなかんじ。

さらにWireSharkでも見ることができます！

↓こんなかんじ～

ここからKing,euda,Luiの質問が始まる。

「なんでTimeOutの時間が設定してあるの？」

最後よーくみると、Windows 1min,Linux 4minと表示がある。

なにこれ？

みんなで考え・・・・

「最後のTIME-WAIT　は右が左にfinを送って

アックがもらえなかった時の場合に再送する可能性があり、

それに応対するためのものだ！」

ここまで順調に学んできましたが、、

eudaが疑問を呈します。。

「先生、WireSharkに表示されるFIN,ACKはいったいなんですか？？」

確かに、、、これいったいなに？？

調べ始めるとよくわからない。。

FIN、ACKとACKの冗長性なのか？どうやらFINを単体では送っていけないらしい。

ううんん。。よくわからない。。

Mr.Hも「僕はTCP屋さんじゃないんだよね～」

いやいや、僕らは大学院生ですｗ

FIN、ACKのことが分かる人、教えてください！

そいじゃーね！

チームの研究＠日本

仲間に入れてもらいました。
せっかくなので、自分の研究に関係のありそうなことを定期的に書いていこうと思います。

日本におけるチーム作業に関する研究は、社会学・心理学が中心となって行なわれています。

チーム作業に関する研究の主な流れとしては、
「チーム作業の評価指標がないから、それを作ろう」というものがほとんどです。
（１０年間くらい、全く変わっていない・・・。）

特に有名な人といえば、佐相邦英さん（電力中央研究所）、山口裕幸先生（九州大学）などが挙げられます。

今回紹介するのは、その２人が共著となっている
看護師チームのチームワーク測定尺度の作成と言う論文です。

この分野では割と有名なDickinson & McIntyreのモデルに基づいた看護師のチームワーク測定のための質問紙を、関係者によるブレイン・ストーミングを用いて作成し、それが妥当であることを統計処理を用いて立証しているという内容です。

理系的な立場からすれば、すごく不安になる部分が多いのですが、
（そもそも検証方法は妥当なのか未だに不安である）

理論部分は大変に参考になる論文でした。

ただし私の研究分野は、この論文で言うところの「チームワーク」ではなく
「タスクワーク」にあたるので、何かいい論文はないのかなと探しているところ。

何か、いいのがあったら教えてくださいね。