知人のジャーナリストNさんが、自身で行かれたわけではないですが(もっと大きな海外イベントにはよく取材に行かれてましたが)、記事を見つけてメールしてくださいました:
> PC Watchの以下の記事を読んでいて、Mextractrを連想しました。
> 「メールから5秒でコンタクト情報をアドレス帳に取り込むOutlookアドイン」
> http://pc.watch.impress.co.jp/docs/2009/0304/demo01.htm
「似ている」ことは、XMLの標準規格の点からも裏付けられます。
Gdataが、Mextractrが主に使っているEvent Kind以外に、Contact Kind, Message Kind (および3種に共通するCommon Element)から成っているからです。
人名、所属、役職。働く場の住所。人か場所の電話番号。これらが基本的なContact情報のメタデータです。
他に、米国には、SMBXMLがあり、日本には、OCRメーカや葉書作成ソフトメーカ間で合意されたContact XMLというのがあります。米国版には、小切手の宛先や社会保障番号(Social Security Number)がほぼ必須情報として存在したり、国・地域や文化・商習慣によって要素や構造が少し違ってきます。
ともあれ、1名分のアドレス帳データをきっちり作るのには意外に時間がかかるもの。目の前に必要なデータが全部あって、正しく切り取ってコピペすれば良いだけであっても、1,2分はかかるでしょう。それが5秒というのだから、ビジネスマンの創造的思考を妨げず、知的生産性を拡大するのに役立ってくれそうです。
http://www.gwabbit.com/
トップページの動画を見るだけでどんな風に使えるのかがわかります。
http://www.gwabbit.com/faqs.php
を見ると、名寄せ支援機能があったり、 若干の学習機能があるかのような記述もみられます。
さらに詳細なところまで、米国在住が長かった弊社外部スタッフ(今のところ)のKさんが試用、評価してくれました。曰く、「文末付近の電話番号らしき数字列をトリガーとしてsignatureの場所を認識している」らしいので、現状、例えば、signature内に電話番号が入っていないと、全く認識されない、などの問題点があるようです。また、相手の引用文よりも下にあるsignatureは認識されないなど、不具合とおぼしきものもありました。
情報を正しく抽出できるかどうか、という観点での評価結果は以下の通り、とご指摘いただきました。
(a) 名前、e-mailアドレスはsignatureに書いてあれば、そこから優先して取得する。書いてない場合、または、認識できなかった場合、メールのヘッダーから取得する。
(b) 電話番号らしき数字が並んでいるものがあれば、その近辺をsignatureとして認識しているらしい。
Johnny Smithson | 姓、名 |
WiseStampCorp | 会社名 |
976.56.456425132 | 携帯電話 →この行が無いと不可 |
John@wisestamp.com | 電子メール |
http://www.wisestamp.com | webページ |
電話番号にはなり得ない数字(6桁以下?)が入っていると認識されない。
Johnny Smithson | 認識されず |
WiseStampCorp | 認識されず |
456-786 | 認識されず |
http://www.wisestamp.com | 認識されず |
(c) 姓名の直後に会社名が入っているのは、認識されるが、役職名が入っていると、signatureとして認識されなくなる。姓名の直後に地名が入っていると、それが会社名として認識される。
Kind regards, | |
John Johnson | 認識されず |
Manager | 認識されず |
Telephone: +44 870 444 1896 | 認識されず |
Mobile: +44 960 444 1896 | 認識されず |
Fax: +44 870 444 1898 | 認識されず |
Tony Carrith | 姓、名 |
Tokyo, Japan | 会社名 (誤認識) |
Mobile: +983-23832842 | 携帯電話 |
Email: tony@wisestamp.com | 電子メール |
(d) 1行になっているsignatureも認識される。
Jon Smithsony | WiseStampAgain | T: +675.51.23989132 | john@wisestamp.com | http://www.wise.se |
(e) 電話番号が2つある場合、一つ目を会社電話、二つ目を会社ファックスとして勝手に認識する。
Phone: 800-555-1234 (H); 800-555-7890 (O)
|
(f) 住所は全く認識されない。
Chuck Cherry | 姓、名 | |
Myanmar Hope Christian Mission, Inc. | 会社名 | |
308 South Oxford Road | 住所が認識されず | |
Springfield, IL 62704-1258 | 住所が認識されず | |
Phone: 800-555-1234 | 会社電話 | |
Email: example@example.com | 電子メール | |
Web: http://www.myanmarhope.org | webページ |
(g) 大学の部署、所属等は認識はされるものの、いくつか間違いがある。
John Johnson | 姓、名 |
Department of Physics, | 役職 (誤認識) |
Harvard University | 会社 |
Telephone: 617 444 1896 | 会社電話 |
Mobile: 617 444 1896 | 携帯電話 |
Fax: 617 444 1898 | 会社fax |
Johnny Smithson | 姓名 |
617-456-7859 | 会社電話 |
"Oh, so they have internet on computers now?" -- Homer Simpson かようにまだ改良すべき点は見受けられますが、是非頑張って欲しいもの、と思います。 ビジネスモデル的にはどうでしょうか。 アドレス帳という、知識編集の効率化、自動化に的を絞ったのは悪くないかもしれません。 ※ターゲットをとことん絞り抜け!というVCさんからの圧力による判断という匂いがしますが。。 ただ、私なら、企業のバックエンド、サーバ側、公衆ならクラウドの側にこの機能を置いて、様々なシステム、業務フローの中で常時編集と活用が進むように取り組むと思います。 なぁんて、全然人ごとじゃありません。 こちらは「イベント」のメタデータ自動認識から入ったけれど、コンタクト情報も合わせて認識できるエンジンを早期にリリースしたいです。コンタクト情報の塊を拾いつつ、即時に活用するアプリも育てていくことで、かけ算で御利益が高まっていきそう、だからであります。 例:イベントカレンダー向けにも、イベント会場やイベント主催者のコンタクト情報を集めて構造化しておくことで有用性が高まる。 |
Good!獲得数: 37
アクセス: 1770