ScribbleLive

Ｑ．ユーザーの質が下がるのはタギングや重み付けなどの技術的な解決をするべきではないのか？それはできないのか？

休憩中

ここまでパートＡ

○質疑応答

Ｑ．実験結果のグラフの見方がわからない
Ａ．再現率と精度の両方が高いとよい結果

Ｑ．タグが収束するのはインターフェースによるものなのか、
　　それとも単純に多くの人が同じものを使うのか？

Ａ．インターフェースによるところが大きい。
　　これによってタグでコンテンツを探すのが難しくなってしまっている

・人間に頼る旧来の出版業界は10年間縮小しつづけている
・Ｗｅｂ企業の成功パターンは「人間と機械の共生」による「動的なメディア」

○歴史
ソクラテス
「静的な書物は動的な対話に劣る」と考えた。なので著書を残さなかった

1945年 ＭＥＭＥＸ

1960年 「人間と機械の共生」
リックライダーの論文

1963年 「情報産業論」
梅禎
脱工業化をこの時点で予言
京大コードの提唱者

1967年 ＫＪ法


1973年頃 暫定ダイナブック

1987年 Hyper Card

1991年 World Wide Web

1995年 Wiki

1999年頃 Blog

2003年 del.icio.us

2005年 はてなブックマーク

○欲しかったもの

・Webページに赤入れ
・さくさくWeblog
（web引用＋コメント）
・全部共有（コモンズ）

○位置づけ
・あのテーション
・ミニブログ
・引用箇所へのポインタを持つＳＢＭ


○デモ

ウィジェットがコメントの該当箇所に自動でスクロールして
どこにどういうコメントがついているのかがわかるようになっている

マークブラウザーと本文を比較できるようにしたところがインターフェースの肝

○マークブラウザ

・付箋メタファを捨てた

○Ｗｅｂに対話を
・ほとんどのＷｅｂページは、対話のない静的な存在だった
・Ｂｌｏｇコメント欄と本文の連携が弱い
・コモンズ・マーカーは、静的なWebを動的に変える

○Ｗｅｂに出会いを
・マークブラウザを使い仲間と「読み」を共有する
・マークブラウザの一覧性が


○仕事尾を楽しく
・原稿や甲制止への「赤入れ」は面倒でつらい作業だった。
・楽しい


○今後の展開

・マーク付けによる「Web Publishing」
・Ｂｌｏｇはメディア、マークもメディア
・グループでの情報共有（法人向け）
－新聞や雑誌の切り抜きのように社内での情報共有ができる

○開発陣
・ソフトカルチャー id:elm200
・アドバイザーとしてyuguiさん


○質疑応答

Ｑ．Ｗｅｂページの変更にどう対応するのか？
Ａ．静的なページのみに対応している。動的なページでページの内容が変わってしまうと、あわない部分にマークされてしまう。今後は対応していきたい

Ｑ．スケーラビリティは、大量にマークされると対応できないのでは？
Ａ．1ページにつき100～200入るようにしておけばいいのではないか。それ以上になった場合は別のページに飛ばすなどをして対応する。100個で十分なのではないか

Ｑ．全てのページに対応するのか？
Ａ．99％のサイトで動く

Ｑ．テキストだけでなく音声や絵などの入力形式も考えているのか
Ａ．今のところ難しい

Ｑ．校正するために特化したツール
Ａ．出版の校正用だとマーケットが小さすぎる
すごく専門性の高いサービスとしては作りこむのは長期的な視点で考えるかも

Ｑ．テキスト以外の別の種類の書き込みができるようにするのか？（アイコンなど）
Ａ．感情表現の文化をコモンズマーカー内で創ることもできるのではないか。ＡＡのように。

13:50-14:40
☆フランステレコム株式会社 (France Telecom R&D Tokyo)　
早稲田大学大学院 理工学研究科 情報・ネットワーク専攻 博士後期課程
井口　誠
「お前のモノ（ブックマーク）は俺のモノ、俺のモノ（ブックマーク）も俺のモノ」

休憩中
質疑応答は勉強不足でよくわかりませんでした。。。

ひらめいったー
http://ryo.hayamin.com/idea/top

はてブおせっかい（動いてません）
http://ryogrid.myhome.cx/osekkai/

○アジェンダ
・ＳＢＭ関連サービスの開発記
・今後のＳＢＭ

○開発に至った経緯
・はてブニュースというサイトを作った
・ベイズ推定によってはてブのホッテントリを自動推定
並べ替えてるだけ


■kikker　（動いてません）
http://ryogrid.myhome.cx:1234/
・学習するユーザーカスタイマイズドなニュースサイト

１．はてブＩＤとキーワードの登録
２．kikkerが推薦
３．推薦されたページを閲覧すると、kikkerがそのページを対象ユーザの趣向と学習する
・アルゴリズム
　－ベクトル計算、ページ内容のベクトルとユーザ趣向のベクトルの距離を計算

・ページ内の各単語ごとの重み
　－意味は見ていない

・ベクトルの抽出
１．キーワード集める
２．ページの内容を形態素解析して単語に分解
３．名詞だけ選択
４．各単語の重みとＴＦ・ＩＤＦで決定
５．重みの上位Ｎ個と手順1のキーワードでベクトルを構成

○形態素解析とは？
http://ja.wikipedia.org/wiki/%E5%BD%A2%E6%85%8B%E7%B4%A0%E8%A7%A3%E6%9E%90
Chasen(茶箋)


○ＴＦ・ＩＤＦとは？
・単語の文章中での重みの指標
・ある単語でiでのドキュメントjの中での重みを求めたい
・計算するために必要な情報
　－対象ドキュメント中の単語数
　－世界中に存在するテキストの数
　－対象単語を含むドキュメントの数
http://ja.wikipedia.org/wiki/Tf-idf


検索エンジンを使うとＯＫ
Yahoo!のＡＰＩ使う。以下を参照
http://chalow.net/2005-10-12-1.html


○ユーザーの趣向を評価するベクトル
・各ユーザーは自身の趣向を表現したベクトルをもつ。
　－見たページの趣向を自分に足しこむ
　－はてブでブクマしたページから学習
　－ユーザがKikkerに進められたページを閲覧するとkikkerが学習
　－自身でも指定可能　ユーザ登録のときに手動でベクトル設定できる


○ベクトル間の角度の計算方法
基本的なことだったので省略

○学習の仕組み
・ユーザが推薦されたページを見るたびに学習
　－ユーザが見たページのベクトルをそのユーザの趣向ベクトルに足しこむ

○問題点
・ベクトルの計算処理自体は妥当な処理時間で行えた
・単語の評価を求めるたびにYahooにクエリ投げてるので重くなる

○クエリを減らす工夫
・文章中の全てのキーワードをYahooに検索かけるのは無理
　－bulkfeedsのキーワード抽出ＡＰＩで間引きした
　　⇒クエリの数が減らせた。重みの情報は取れなかった
http://www.usamimi.info/~ryouchi/wiki/index.php?API%2FBulkfeeds


・chasenの辞書が載っている生起コストを使う
　　⇒クエリがゼロになった

以下を参照
http://labs.cybozu.co.jp/blog/kazuho/archives/2006/04/summarize.php


■はてブおせっかい
○サイトの概要
・各人のブックマーク履歴を利用して推薦を行う
・Kikkerと異なり、ページの内容の情報は使わない
・アルゴリズムはコラボレイティブフィルタ
・ユーザ登録不要


○コラボレイティブフィルタってなに？
類似性を見て、どれだけ似ているかを重み付けして、
閾値以上であれば見たほうがいいと推薦する


○問題点
・計算処理が遅すぎ
　－転置インデックスが使えなかった

・解決策
　－計算処理で利用するユーザとページをどうにかして間引く仕組みが必要か
⇒ユーザに関してはユーザのクラスタリングで対応できないだろうか？

○はてブまわりの人
・はてブのお気に入り機能をクラスタリングした上でグラフ化

※たまたまかもしれませんが、これ開いたらfirefox固まりました
http://www.coins.tsukuba.ac.jp/~i041184/distribute/hatebu_mawarinohito/hatebu_mawarinohito.html


■KOOKLE! JAPAN
・タグでよく登録されるページを検索できるようなサイト
~i041184/distribute/tag_directory/top_page.html

Paul Resnick, 1994, GroupLens: An Open Architecture for Collaborative Filtering of Netnews
~presnick/|
zpapers/cscw94/GroupLens.htm

☆みずほ情報総研の方が自己紹介中

■パネルディスカッション
吉川さん、宇佐美さん、横田さん、宮田さん、佐々木さん

・ソーシャルブックマークを使い出したきっかけ



・ソーシャルブックマークの魅力は？　＞横田さん
良質なはてなブックマークを選ぶ

見たページを検索しながらやっていた
ブックマークで効率化できた


・研究者との魅力　＞宮田さん、佐々木さん
コメントを隠しながらとか、タグの意味があまりないのではないか
コメントは評価しづらい、タグをクラスタリングして類似した言葉がまとめられる

・Buzzurlの満足しているところと課題　＞宇佐美さん
使う人が多くなればなるほど面白くなる
ユーザー数が爆発する段階まで至っていない
スパム的な登録が増えている
40～50％くらいはスパム
どうやって通常の投稿と分けるのかが課題

■社内ＳＢＭの実態についてのプレゼン みずほ情報総研　吉川さん

・最初ははてなブックマークを使って社内で情報共有していた
　－情報を公開しているのはまずい
・他の会社にも声かけたが、結局マイネットジャパンと一緒に作った

・newsingの認証部分の最低限な追加を行い、そのまま利用開始（6人）
・他の部署の30人くらいに使ってもらった。


・知っていて当然のニュースを共有するのに便利
・社員にＩＤ配っていても全員使ってくれない


○導入にあたっての工夫点

・セキュリティ対策（認証、アクセスログ）
・コメント機能（何回でも書けるように）
・デザインを社内向けに変更
・社内文章対応（右クリックで社内文書が登録できるように）
・システム管理機能の強化
・メルマガ機能
・タグエリアを複数に分割
　－組織タグ
　－カテゴリタグ
　あらかじめタグを用意しておく。タグは自由につけられるが、あまりつけないようにように


○利用状況
部間で使ったときのほうが効果的だった

・知らないニュースソースを知ることができた
・社内文書のクリップはあまり使われていない

○登録されたニュースを読む基準
・誰が登録したかが重要
・同じプロジェクトのメンバーが登録したニュースはプロジェクトチーム全体で共有できる

○大規模展開時に必要な機能
・ＵＩの改善や目的の共有などが必要
・全体に広める必要はないという意見が多数


■Buzzurl Plusの紹介　ＥＣナビ宇佐美さん

・社内でも大多数がブックマークを使わない

・ページを見た人の足跡が残るようになっている

・手軽にどんどんＳＢＭを新規に作って、使われないものは埋もれていくし、使われるものは残るというような状態にする


横田さんの感想とニッチなＳＢＭについて
ニッチなところからはじめて、少しずつ広めていったほうがよい


紙で配っている社内報をＳＢＭで代替できる
　－一部の業界紙がインターネットで見られないので、一部が紙で残るならあまり変わらないという感覚


Ｑ．buzzurlでの面白い使い方は？
Ａ．ブックマークにコメントすることができない
　　他の人のブックマークにコメントできるのでスレッドみたいに

Ｑ．レコメンドや社内フィルタリング
Ａ．宇佐美さん　ユーザ間のシンクロ率を掲載している
　　週に一回ユーザがブックマークしそうなサイトをメルマガで配信している
　　商品のブックマークだけだと継続して使い続けないのでレコメンデーションができない


商品でひも付けてレコメンドするよりも、いったんユーザ間の関連性に着目していく

Ｑ．時系列を見るＳＢＭの研究は？
Ａ．イノベーターやアーリーアダプターを見つけるための研究はあるが、
それ以外で時系列を使うものはない


Ｑ．類似度だけで推薦を行うとつまらないものになってしまうのでは？
Ａ．発見性や意外性を数値化する？？


Ｑ．社内ＳＢＭは部署ごとに分けたほうが情報が薄まらなくていいのでは？
Ａ．全体で1日10個程度に落ち着いているので問題ない

Ｑ．一般のＳＢＭと社内ＳＢＭはルールがかなり違うと思うが、どう管理しているか
部署間でもやり取りしたらまずい情報があるのでは？
Ａ．社内で今のところ問題は発生していない
　　周りに行動を見られるので、それを意識した行動を取るようになる
　　buzzurl plusの場合は社内の人を指名で質問したりすることがある
　　顔がお互い見えているとコミュニケーションの質が変わる

www.net.ss.titech.ac.jp;FILTER=%B5%DC%C5%C4%B9%E2%C6%BB;LOGIC=and