Firefoxのプロキシ設定「プロキシなしで接続」において
IPでネットワークを指定するときの方法
× 192.168.1.*
○ 192.168.1.0/24
なんかワイルドカードだと上手く動かない。
CIDR（Classless Inter-Domain Routing）じゃないと駄目っぽい。
2009年7月25日土曜日
2009年7月23日木曜日
危篤
四年間付き合っていた私のパートナーが危篤状態に陥りました。
いえ、Let's noteなんですけどね。
前々から外傷は酷かったです。
基板が見えちゃったり、キーボードが浮いちゃったり。
けど、多少肥満気味ながらも(HDD残量3GB程度...DVD焼いたら成仏しかけました)頑張って働いてくれてました。
しかし、とうとう躁鬱病も患い始めました。
ええ、顔がいきなり暗くなったり明るくなったり。
あたかも、寿命がきた蛍光灯が明滅を繰り返すがごとく、モニタがプッツンプッツン落ち始めました。
入院させたくとも代理がいないので、離れることも出来ず。。。
かといって、いつ昇天召されるか分からない人をアチコチ連れて行くのも賭けですし。。。
いい加減、新しい相棒を確保せねば；；
いえ、Let's noteなんですけどね。
前々から外傷は酷かったです。
基板が見えちゃったり、キーボードが浮いちゃったり。
けど、多少肥満気味ながらも(HDD残量3GB程度...DVD焼いたら成仏しかけました)頑張って働いてくれてました。
しかし、とうとう躁鬱病も患い始めました。
ええ、顔がいきなり暗くなったり明るくなったり。
あたかも、寿命がきた蛍光灯が明滅を繰り返すがごとく、モニタがプッツンプッツン落ち始めました。
入院させたくとも代理がいないので、離れることも出来ず。。。
かといって、いつ昇天召されるか分からない人をアチコチ連れて行くのも賭けですし。。。
いい加減、新しい相棒を確保せねば；；
2009年7月19日日曜日
AS3 in Amazon ☆ Product Advertising APIのHMAC-SHA256署名への対応
Python側での対応が終わったので、次はFlexアプリケーションにてAmazonの署名リクエストを行うように対応。
私の検索方法が悪かったのか、参考になるWebページがあまり見つからなくて困った(>_<) 結局、一番分かり易い、というかクリティカルなところを解決してくれたのはAmazonのコミュニティだった。
やっぱり大事なんだな、こういうところ。
AS3でHMAC-SHA256署名を行うにあたり、まずは以下のパッケージを導入する必要がある。
as3crypto
zipファイルをダウンロードして解凍。
com以下を作業用ディレクトリにコピペ。
後は、このパッケージのHMAC、SHA256、Base64クラスをインポートして、HMAC-SHA256でハッシュ化した後、Base64エンコードする。
この辺の手順については、RHC2104の仕様とか全然読んでない；；
Pythonの時にお世話になった以下のページを参考にハッシュ化とエンコードを行った。
Amazon Product Advertising APIの署名認証をPythonでやってみる
以下、参考までにAS3のソースを公開。
BeteArrayをnewしてから、writeUTFBytesで中身を書き込むのが味噌。
as3cryptoのテストコードではHexというクラスをnewして、Hex.toArray("署名したいドキュメント")でByteArray型の値を生成していたんだけど、こちらを使うとSignatureが不正になってしまった。
SignatureのURLエンコードはreplaceメソッドで手作業。。。
最初はescape関数を使ってたんだけど、+が上手く%2Bに変換されないんだよね。
エラー続発につき、とりあえず+と=だけ変換するように改良。
ちなみに、ダウンロード終了後に呼び出すイベントハンドラ、onAmazonRequestCompleteメソッドには複数の引数を与えてる。
これは、以下のように、イベントハンドラの中で、さらにfunctionをreturnすることで可能となる。
難産だった。。。
私の検索方法が悪かったのか、参考になるWebページがあまり見つからなくて困った(>_<) 結局、一番分かり易い、というかクリティカルなところを解決してくれたのはAmazonのコミュニティだった。
やっぱり大事なんだな、こういうところ。
AS3でHMAC-SHA256署名を行うにあたり、まずは以下のパッケージを導入する必要がある。
as3crypto
zipファイルをダウンロードして解凍。
com以下を作業用ディレクトリにコピペ。
後は、このパッケージのHMAC、SHA256、Base64クラスをインポートして、HMAC-SHA256でハッシュ化した後、Base64エンコードする。
この辺の手順については、RHC2104の仕様とか全然読んでない；；
Pythonの時にお世話になった以下のページを参考にハッシュ化とエンコードを行った。
Amazon Product Advertising APIの署名認証をPythonでやってみる
以下、参考までにAS3のソースを公開。
/*** Import ***/
import com.hurlant.crypto.hash.HMAC;
import com.hurlant.crypto.hash.SHA256;
import com.hurlant.util.Base64;
/*** Field Variables ***/
private var requestUri:String = "ecs.amazonaws.jp"
private var requestPath:String = "/onca/xml"
private var amazonSecretKey:String = "AWSの秘密鍵"
/*** AWS Access Method ***/
private function sendAmazonRequest(var1:int, asin:String):void{
var amazonloader:URLLoader = new URLLoader()
// タイムスタンプの作成：ISOフォーマット、UTC(世界標準時)
// make Timestamp: ISO format, UTC
var timestamp:String = makeTimeStamp()
// バイトコード順にソートしつつ、クエリを連結
// クエリをそれぞれescape関数でURLエンコードしておく（×escapeMultiByte）
// sort query by the byte code ascending, and join them
// query is urlencoded by 'escape' method (not escapeMultiByte)
var query:String = "AWSAccessKeyId=Amazonへのアクセスキー&"
+ "ItemId=" + asin + "&"
+ "Operation=ItemLookup&"
+ "ResponseGroup=" + escape("Medium,Images,EditorialReview,Reviews") + "&"
+ "Service=AWSECommerceService&"
+ "Timestamp=" + escape(timestamp) + "&"
+ "Version=" + "2008-08-19";
// 署名の生成
// make Signature
var signatureText:String = ["GET", requestUri, requestPath, query].join("\n") // 署名する文書 Document for signature
var signature:String = makeSignature(signatureText, amazonSecretKey)
// URLエンコードした署名をクエリの最後に追加
// リクエストURLの完成
// add urlencoded Signature to query tail
// complete request Url
query += "&Signature=" + signature.replace(/\+/g,'%2B').replace('=', '%3D')
var requestUrl:String = "http://" + requestUri + requestPath + "?" + query
// amazonへアクセス（onAmazonRequestCompleteにてダウンロード完了後の処理を行う）
// access to Amazon (after download complete, onAmazonRequestComplete() executed)
amazonloader.addEventListener(Event.COMPLETE, onAmazonRequestComplete(var1, amazonloader));
amazonloader.load(new URLRequest());
}
private function makeTimeStamp():String{
// ISOフォーマットでタイムスタンプを生成 YYYY-MM-DDTHH:mm:ss
// 世界標準時（UTC）を採用
var timestamp:String = timeStamper.getUTCFullYear() + "-"
+ to2size(timeStamper.getUTCMonth() + 1) + "-"
+ to2size(timeStamper.getUTCDate()) + "T"
+ to2size(timeStamper.getUTCHours()) + ":"
+ to2size(timeStamper.getUTCMinutes()) + ":"
+ to2size(timeStamper.getUTCSeconds())
return timestamp
}
private function to2size( data:Number ):String{
// 日付や時分秒が10未満の場合、2桁となるよう左に0を挿入
var strData:String = data.toString() // 返却する文字列
if (data < 10) {
strData = "0" + strData
}
return strData
}
private function makeSignature(signatureText:String, key:String):String{
// HMAC-SHA256署名の作成
// 署名する文書と、ハッシュキーを引数として受取り、String型の署名データを返す
// generate HMAC-SHA256 signature
// accept "document for signature(String)" and "signature key(String)" as variables
// return signature(String)
//HMAC-SHA256署名を行うクラス
var hmac256:HMAC = new HMAC(new SHA256());
// 署名する文書のバイトデータ ByteArray for signatured document
var signatureTextBytes:ByteArray = new ByteArray();
signatureTextBytes.writeUTFBytes(signatureText)
// 署名用のハッシュキーのバイトデータ ByteArray for signature key (AWS secret key)
var keyBytes:ByteArray = new ByteArray();
keyBytes.writeUTFBytes(key)
// HMAC-SHA256署名を行い、ダイジェストを生成
// generate Digest (HMAC-SHA256)
var digest256:ByteArray = hmac256.compute(keyBytes, signatureTextBytes);
// ダイジェストをBase64でString型にエンコード
// encode Digest(ByteArray) to String by Base64encoding
var signature:String = Base64.encodeByteArray(digest256)
return signature
}
BeteArrayをnewしてから、writeUTFBytesで中身を書き込むのが味噌。
as3cryptoのテストコードではHexというクラスをnewして、Hex.toArray("署名したいドキュメント")でByteArray型の値を生成していたんだけど、こちらを使うとSignatureが不正になってしまった。
SignatureのURLエンコードはreplaceメソッドで手作業。。。
最初はescape関数を使ってたんだけど、+が上手く%2Bに変換されないんだよね。
エラー続発につき、とりあえず+と=だけ変換するように改良。
ちなみに、ダウンロード終了後に呼び出すイベントハンドラ、onAmazonRequestCompleteメソッドには複数の引数を与えてる。
amazonloader.addEventListener(Event.COMPLETE, onAmazonRequestComplete(var1, amazonloader));
これは、以下のように、イベントハンドラの中で、さらにfunctionをreturnすることで可能となる。
// AmazonのXMLのNamespaceをnewしておく。リクエスト時の"Version"との一致が必須
// make Amazon XML Namespace instance. Namespace Version needs to be as same as "Version" at request
private var ns:Namespace = new Namespace("http://webservices.amazon.com/AWSECommerceService/2008-08-19");
// ダウンロード終了イベントを受け取るメソッド
// Method accepting download complete event
private function onAmazonRequestComplete(var1:int, amazonloader:URLLoader):Function{
// 実際にイベントを処理するfunctionを返す
// return function which handles Event actually
return function(e:Event):void{
default xml namespace = ns;
var response : XML = new XML(amazonloader.data);
// 以下、XML操作...
// And read and write XML...
}
}
難産だった。。。
2009年7月18日土曜日
google-code-prettify の導入
今までベタ貼りしていたソースコードをもっと見やすくしようと、
ソースコードを綺麗に表示してくれるJavascriptを導入。
色々種類があったけど、とりあえず見た目がシンプルなものをチョイス。
google-code-prettify
導入の際にお世話になったのが、こちらのサイト。
ソースコード を色づけして 表示 する - 八発白中
意外なのがBloggerにJavascriptのアップロード機能がついてなかったこと。
Google app engineとかあるから、できるようなイメージで居たんだけど。。。
他、Googleのサービスをあさっても、jsをアップロードできそうなサービスが見当たらなかったので、仕方なく手元のWebサーバにアップロードしてお茶を濁す。
しかし、納得いかんなぁ。。。なんでapp engineがOKで、jsが駄目なんだろ？
とりあえず、テストしてみた。
おぉ綺麗☆
もっと早く入れとけば良かったなぁ。
ソースコードを綺麗に表示してくれるJavascriptを導入。
色々種類があったけど、とりあえず見た目がシンプルなものをチョイス。
google-code-prettify
導入の際にお世話になったのが、こちらのサイト。
ソースコード を色づけして 表示 する - 八発白中
意外なのがBloggerにJavascriptのアップロード機能がついてなかったこと。
Google app engineとかあるから、できるようなイメージで居たんだけど。。。
他、Googleのサービスをあさっても、jsをアップロードできそうなサービスが見当たらなかったので、仕方なく手元のWebサーバにアップロードしてお茶を濁す。
しかし、納得いかんなぁ。。。なんでapp engineがOKで、jsが駄目なんだろ？
とりあえず、テストしてみた。
#include
/*
九九の表を表示する
*/
int main(void){
int i, j;
printf(" ");
for (i=1; i<10; i++){
printf("%2d ",i);
}
printf("\n");
for (i=1; i<10; i++){ // i の段
printf("%2d ", i);
for (j=1; j<10; j++){
printf("%2d ", i*j); // i x j の値を表示
}
printf("\n");
}
return 1;
}
おぉ綺麗☆
もっと早く入れとけば良かったなぁ。
[Python] Amazonへの署名付きリクエスト
再びAmazonへのリクエストネタ。
今まではAmazonへのリクエストはアクセスキー（秘密鍵とは別）さえあれば、本の詳細情報やレビューとかの公開されたデータは、誰でもリクエストで取得できた。
けど、8月15日から全てのリクエストについて、署名なしリクエストは受けてくれなくなるそう。
しょうがないので、以下のサイトを参考に対応。
Amazon Product Advertising APIの署名認証をPythonでやってみる
以下が更新したAmazonリクエスト取得用メソッド。
色々なタイプのデータを取りに行くので、こんな形にしてる。
英語がめちゃくちゃなのは・・・もはや標準仕様ということで＜汗
==================================================
import urllib
import hashlib, hmac, base64
from datetime import datetime
AWS_SECRET_ACCESS_KEY = 自分の秘密鍵
AWS_ACCESS_KEY_ID = 自分のアクセスキー
AWS_JP_URI = 'ecs.amazonaws.jp'
AWS_JP_ENDPOINT = '/onca/xml'
AWS_VERSION = '2008-08-19'
def getAmazonXML(search_options):
"""
与えられたオプションからAmazonへのリクエストを作成・実行
XMLを取得する
Makes a request to Amazon from the given search_options and executes it.
XML is acquired.
"""
# 全てのリクエストに共通するリクエストパラメータ
# Common request parameter to all Amazon request
options = {'Service' :'AWSECommerceService',
'AWSAccessKeyId' : AWS_ACCESS_KEY_ID,
'Version' : AWS_VERSION,
'Timestamp' : datetime.utcnow().isoformat(),
}
# optionsにsearch_optionsを追加（連想配列の結合はupdate()）
# search_options is added to options (if samekey exists, updated)
options.update(search_options)
# リクエストはバイト順にソートした上でURLエンコード
# その後、正規表現より+を%20(quote処理)に変更
# Request is sorted based on bytedata, and urlencoded.
# And "+" is replaced with "%20"(quote)
query = urllib.urlencode(sorted(options.items())).replace("+", "%20")
# 署名の作成
# generate signature
text = '\n'.(['GET', AWS_JP_URI, AWS_JP_ENDPOINT, query]) # target of signature
signature = base64.b64encode(hmac.new(AWS_SECRET_ACCESS_KEY, text, hashlib.sha256).digest())
# 署名のリクエストへの追加とURLエンコード
# make url for Japan Amazon ECS
request_url = "http://" + AWS_JP_URI + AWS_JP_ENDPOINT
request_url += "?" + query + "&" + urllib.urlencode({'Signature': signature})
# リクエストの実行
# execute request
xml = urllib.urlopen(request_url).read()
return xml
==================================================
なんか、随分メンドくさくなっちゃったな。。。
ってか、あとAS3も対応しなきゃいけないんだった。。。あう。
今まではAmazonへのリクエストはアクセスキー（秘密鍵とは別）さえあれば、本の詳細情報やレビューとかの公開されたデータは、誰でもリクエストで取得できた。
けど、8月15日から全てのリクエストについて、署名なしリクエストは受けてくれなくなるそう。
しょうがないので、以下のサイトを参考に対応。
Amazon Product Advertising APIの署名認証をPythonでやってみる
以下が更新したAmazonリクエスト取得用メソッド。
色々なタイプのデータを取りに行くので、こんな形にしてる。
英語がめちゃくちゃなのは・・・もはや標準仕様ということで＜汗
==================================================
import urllib
import hashlib, hmac, base64
from datetime import datetime
AWS_SECRET_ACCESS_KEY = 自分の秘密鍵
AWS_ACCESS_KEY_ID = 自分のアクセスキー
AWS_JP_URI = 'ecs.amazonaws.jp'
AWS_JP_ENDPOINT = '/onca/xml'
AWS_VERSION = '2008-08-19'
def getAmazonXML(search_options):
"""
与えられたオプションからAmazonへのリクエストを作成・実行
XMLを取得する
Makes a request to Amazon from the given search_options and executes it.
XML is acquired.
"""
# 全てのリクエストに共通するリクエストパラメータ
# Common request parameter to all Amazon request
options = {'Service' :'AWSECommerceService',
'AWSAccessKeyId' : AWS_ACCESS_KEY_ID,
'Version' : AWS_VERSION,
'Timestamp' : datetime.utcnow().isoformat(),
}
# optionsにsearch_optionsを追加（連想配列の結合はupdate()）
# search_options is added to options (if samekey exists, updated)
options.update(search_options)
# リクエストはバイト順にソートした上でURLエンコード
# その後、正規表現より+を%20(quote処理)に変更
# Request is sorted based on bytedata, and urlencoded.
# And "+" is replaced with "%20"(quote)
query = urllib.urlencode(sorted(options.items())).replace("+", "%20")
# 署名の作成
# generate signature
text = '\n'.(['GET', AWS_JP_URI, AWS_JP_ENDPOINT, query]) # target of signature
signature = base64.b64encode(hmac.new(AWS_SECRET_ACCESS_KEY, text, hashlib.sha256).digest())
# 署名のリクエストへの追加とURLエンコード
# make url for Japan Amazon ECS
request_url = "http://" + AWS_JP_URI + AWS_JP_ENDPOINT
request_url += "?" + query + "&" + urllib.urlencode({'Signature': signature})
# リクエストの実行
# execute request
xml = urllib.urlopen(request_url).read()
return xml
==================================================
なんか、随分メンドくさくなっちゃったな。。。
ってか、あとAS3も対応しなきゃいけないんだった。。。あう。
2009年7月17日金曜日
SwitchProxy → Multiproxy Switch
FireFox3.5にバージョンアップしてSwitchProxyが使えなくなってからというもの、家で学校で開発用で、とプロキシをいちいち手動で設定し直していました。
いい加減、耐え切れなくなってきちんと検索したら見つかりました。
Multiproxy Switch
名前、変わってたのね。。。
道理で見つからないのね。。。
開発は別の人ですが、機能、見た目は同じでした。
ようやくストレスから解消されそうです。
いい加減、耐え切れなくなってきちんと検索したら見つかりました。
Multiproxy Switch
名前、変わってたのね。。。
道理で見つからないのね。。。
開発は別の人ですが、機能、見た目は同じでした。
ようやくストレスから解消されそうです。
2009年7月16日木曜日
「遇う」ときは「遇う」
普段滅多に会わない友人と、一度「遇う」と、連続して「遇う」ことが多い。
いつもは別の友人に立て続けに「遇う」んだけど、
今回は、同じ日に同じ子に、二度偶然「遇った」。
ちょっと新鮮な気がする。
その子とは久しぶりに可愛いものトークで盛り上がれて楽しかった。
ちなみに本日のメインキャスト。
大阪、三角公園近くの300均で買った「ひよこドーナッツ」
携帯スタンドと携帯ストラップ、大小取り揃えております☆
基本、可愛いアイテムにハッスルする人間なので、
こういう話題で盛り上がれるとスゴク心が癒されます。
何かもう、今日は色々やりとげた気持ちで一杯です。
え、研究？
勿論、進んでないよ＜泣
いつもは別の友人に立て続けに「遇う」んだけど、
今回は、同じ日に同じ子に、二度偶然「遇った」。
ちょっと新鮮な気がする。
その子とは久しぶりに可愛いものトークで盛り上がれて楽しかった。
ちなみに本日のメインキャスト。
大阪、三角公園近くの300均で買った「ひよこドーナッツ」
携帯スタンドと携帯ストラップ、大小取り揃えております☆
基本、可愛いアイテムにハッスルする人間なので、
こういう話題で盛り上がれるとスゴク心が癒されます。
何かもう、今日は色々やりとげた気持ちで一杯です。
え、研究？
勿論、進んでないよ＜泣
2009年7月15日水曜日
ぷちショック
AWSに繰り返しアクセスするようなインタフェースを作ってるんですが、
Amazonへのアクセス速度が遅い事にイライラ。
ローカルサーバからXMLファイルを取得する形に変えれば、とりあえずデモは早くなるんじゃないかと思ってシステムを改良。
改悪でした。
Amazonのアクセス速度の方が4倍近く早い。
複数のデータをとるときは、Amazonに連続したアクセスへのインターバルがあるせいでローカルのを取ってきた方が早いんだけど、最初の一歩はAmazonの方が断然早。
コードがPythonなのが悪いのか、我が家のApacheがのんびりなのか。。。
あう゛ぅ……。
とりあえず、これで据え置きして、アクセス速度の向上は今度やろう。。。
はぁ……。
Amazonへのアクセス速度が遅い事にイライラ。
ローカルサーバからXMLファイルを取得する形に変えれば、とりあえずデモは早くなるんじゃないかと思ってシステムを改良。
改悪でした。
Amazonのアクセス速度の方が4倍近く早い。
複数のデータをとるときは、Amazonに連続したアクセスへのインターバルがあるせいでローカルのを取ってきた方が早いんだけど、最初の一歩はAmazonの方が断然早。
コードがPythonなのが悪いのか、我が家のApacheがのんびりなのか。。。
あう゛ぅ……。
とりあえず、これで据え置きして、アクセス速度の向上は今度やろう。。。
はぁ……。
2009年7月14日火曜日
Skype v.s. Apache
今更ながら引っかかりました。
Skypeが起動してるとApache が起動しない件 : karate style
焦った。本気焦った。
ミーティングで動かせなくなるかと思った。。。
怖かったよぅ。。。
とりあえず以下のスキルを習得したのでまあ良かったことにする。
■Windowsのイベントビューアを見る
（コントロールパネル＞管理ツール＞イベントビューア）
■netstat -oanでポートのListen状態を調べる
ずっとWindows使ってたけど、開発環境を整えたことはあまり無かったから意外と知らんなぁ。。。
Skypeが起動してるとApache が起動しない件 : karate style
焦った。本気焦った。
ミーティングで動かせなくなるかと思った。。。
怖かったよぅ。。。
とりあえず以下のスキルを習得したのでまあ良かったことにする。
■Windowsのイベントビューアを見る
（コントロールパネル＞管理ツール＞イベントビューア）
■netstat -oanでポートのListen状態を調べる
ずっとWindows使ってたけど、開発環境を整えたことはあまり無かったから意外と知らんなぁ。。。
2009年7月7日火曜日
第15回WI2研究会 終了
今回の研究会は、私にとってエンジン的な存在になりそうです。
MYCOMでは新しい道が見えた。
そこを走り出すための活力をWI2で得た。
そんな感じ。
それから、被験者実験の実験計画の重要さについて、よく勉強できました。
今やろうとしている実験についても、その辺りきちんと埋めていきたいです。
お世話になった先生方、本当にありがとうございました。
で。
とりあえず、出発前の目標についてそれぞれ達成度を確認しますかね＜笑
１．全部の発表についてメモをとる
２．１セッションにつき１回は絶対に質問する
３．名刺を１０枚獲得してくる＜笑（要は話せってコト）
1は90点かな。大体全部はとったけど、質問とかタイプが間に合わないところもあったし。
次回からはテープレコーダ持っていこうか＜笑
2は80点。チュートリアルが質問できなかったけど、これは何ていうか。。。
私自身のレベルを上げないとね。
チュートリアルで-30点だけど、2日目にたっぷり質問できたので+10点してあげて80点てところかな。
的確な質問ができなかったのが残念。
なんか「こうしたら良いのに」ってところが上手く表現できないんだよね、大向さんも「場数を踏めば」と仰ってくださったので、まずは研究室の中でもっともっと練習練習。
3は100点。色んな人に挨拶できたし話せたし、良かった良かった。
内向的、かつ人見知りが激しい私にしては画期的♪
あとは実になる話をできる人間にならないとね。
総合得点は90点。
WI2は本当に楽しかった。
けど、この楽しさはきっと聴講生というお客様身分なのもあるんだろうな。
きっと発表者として上がったら見えるものがまた違うんだろう。
次回10月の第16回WI2には講演者として参加したいけど。。。
ちょっと日程的に厳しそうだなぁ＜汗
もっと生産性を上げないと現時点ですらヤバい。。。
がんばるぞー！
MYCOMでは新しい道が見えた。
そこを走り出すための活力をWI2で得た。
そんな感じ。
それから、被験者実験の実験計画の重要さについて、よく勉強できました。
今やろうとしている実験についても、その辺りきちんと埋めていきたいです。
お世話になった先生方、本当にありがとうございました。
で。
とりあえず、出発前の目標についてそれぞれ達成度を確認しますかね＜笑
１．全部の発表についてメモをとる
２．１セッションにつき１回は絶対に質問する
３．名刺を１０枚獲得してくる＜笑（要は話せってコト）
1は90点かな。大体全部はとったけど、質問とかタイプが間に合わないところもあったし。
次回からはテープレコーダ持っていこうか＜笑
2は80点。チュートリアルが質問できなかったけど、これは何ていうか。。。
私自身のレベルを上げないとね。
チュートリアルで-30点だけど、2日目にたっぷり質問できたので+10点してあげて80点てところかな。
的確な質問ができなかったのが残念。
なんか「こうしたら良いのに」ってところが上手く表現できないんだよね、大向さんも「場数を踏めば」と仰ってくださったので、まずは研究室の中でもっともっと練習練習。
3は100点。色んな人に挨拶できたし話せたし、良かった良かった。
内向的、かつ人見知りが激しい私にしては画期的♪
あとは実になる話をできる人間にならないとね。
総合得点は90点。
WI2は本当に楽しかった。
けど、この楽しさはきっと聴講生というお客様身分なのもあるんだろうな。
きっと発表者として上がったら見えるものがまた違うんだろう。
次回10月の第16回WI2には講演者として参加したいけど。。。
ちょっと日程的に厳しそうだなぁ＜汗
もっと生産性を上げないと現時点ですらヤバい。。。
がんばるぞー！
2009年7月6日月曜日
第15回WI2研究会 2日目セッション4「Webサービス」
お昼は市立大学の人たちと例のオープンしたてのパン屋で食べました。
日曜日なのでお子ちゃま多数＜笑
WI2もこのセッションで終わり。
非常にためになる研究会でした。
===============
■学術研究プラットフォームのサービス提案
岡本さん
・YahooJapanで10年勤務
学術成果のプラットフォームを作りたいと考えるようになった。
・問題意識
インターネットの学術利用→ 専門分野の横断、研究者と市民の接続
→メディアの限界
→プラットフォームへの転換
学者や専門化がそれぞれ自分個人のウェブを管理し、最新の専門知識を競うように公開する時代が来れば良いと思う。
・基本コンセプト
インセンティブデザイン＝良い物を作れば作ってくれる→使わざるを得ない状況においていく
ユーザビリティ＝Web標準から遅れている
アビリゲート＝データを一元化しすぎると×（ブックマークはココ、ブログはアッチみたいな）サービスを取り込んでいく
インテリジェンス＆インタラクション！
・管理対象データの区分
Relation＝研究者同士の関連
Event＝研究会情報
Task＝TODO
Output＝上手く統合して行きたい
Process＝成果よりはプロセスをはっきり示すべきでは？
・インセンティブデザイン
自分自身に関る情報を整理→機械的な学習も必要
情報の発見
労力の削減→各種申請書類フォーマットへの対応
支援の獲得→プロセスの発表に対して、一般市民がDonateされる、Donateは謝辞や還元される
・課題
持続性 ビジネスモデル的な問題
商用利用禁止規定
依然クローズな基盤データ環境 APIを公開してくれない
質問1
プロセスを見せるのは面白い。研究者がサボってるかどうかもよく分かる。どう見せる？
→Twitter的なもので良い。等身大の研究者像を伝える。意外と研究者のブログでも研究については発信されていないから。
質問2
財閥系からの支援が得にくい。どうやって儲ける？
→ビジネスモデル的には難しい。当面は別の仕事で食っていく。透明な資金を集める。日本人は300万人の研究者がいる。学術産業をちゃんと立ち上げるべき。
質問3
国のやる仕事と民間のやる仕事は新しいところでレイヤーを引かないといけない。どのレベルまでやる事を期待している。
→基盤データを作るのは国の仕事（営利ビジネスとは立ち行かない）NIIやJSTにはデータプロバイダーとしてやってほしい
■XMLデータベースを用いた柔軟なUGCサービスの提案
NTTサイバースペース研究所 榎本さん
・XMLデータベース
なかなか市場が広がらない。。。
→蓄積して利用していく方向で広げていこう
モデルが違えば柔軟性も違う
→ユーザ生成コンテンツ（UGC）を構造化できるんじゃない？
イベント情報の共有サービス
http://www.craigslist.org/
http://tokyo.kijiji.co.jp/
・提案の骨子
うまく使えば、メンテフリーなシステムが作れるんじゃないか？
→テンプレートの利用
データの構造の異種性を超えられるんじゃない？
→自動レイアウト
質問1
新しい項目を増やすと検索のフィールドも増えていくのは面白い。ただ増えすぎた場合はどうするの？
→構造化をまずしてもらう。セットで使えるようなのをインテリジェントに求めるなどしたい。
質問2
スキーマの型は？
→基本的にテキストしている。型の推測か、ユーザが定義するか、方法は考えている。
質問3
教育分野にて、大学生のシラバスに使えるのでは？
→よく知らないのでまた教えてほしい
質問4
インタフェース周りがよく分からない。
→ユーザがよく使うものは残り、そうでないものは淘汰されていく。スキーマの進化があるんじゃないか？
ボトムアップにできていくところは面白い。
■Pirka'r: ブラウザ間非互換問題を解決するWebデザイナ向けツール
三菱総合研究所 飯尾さん
・様々なブラウザで問題なく閲覧できるコンテンツ作成支援
ユーザ視点で問題を見つめなおしてみるべき。
・Web標準のコンポーネント
HTML、CSS、Javascritp
同じコンテンツでも表現や動作に違いが出る（becauseブラウザ戦争など）
・WaSPのアプローチ（伽藍方式）：ブラウザベンダに注意
・バザール方式：問題のあるコンテンツを探して警告
・20万サイトを調査、142種類の非互換性（自動チェックできるのが）→3割のサイトに問題を発見
・原因の分析
オーサリングツールの問題（HPビルダー）
発注者側の意識 特定ブラウザだけ対応すりゃいいや
作成者の意識 テストに工数をかけたくない
最近はWebブラウザも増えたし、携帯からのアクセスも増えた
→支援ツールPirka'r http://pirkar.ashikunep.org/
1.標準準拠チェック
2.ブラウザ互換性チェック
3.マルチブラウザ視認チェック
？？チェックするだけ？修正候補は出してくれない？？
質問1
コミッタになれそうな人はいるのか？
→まずはJavaScriptでチェック。共同会社がひっぱってきてくれる予定
質問2
現場でWebデザインしているとIE6だと例外構造を出したりする必要がある。全部に対応しようとしている？それともばしっと？
→前の方。
■飽きずに継続利用できる情報推薦の実現に向けた試み
中央大学大学院 稲村さん
・協調フィルタリングなどの既存の推薦手法は、ユーザが感じる「飽き」という感性的な側面まで考慮していない
→「飽き」を感じる感性モデルを明らかにする
お弁当の献立作成をモデルにする！
メニューの固定化。マンネリ化。。。
・お弁当
複数のおかずからなる
素材
味 五味五色五法
色
素材
お弁当を特徴ベクトルで表現する
おかずID（素材ID、味ID、色ID、調理法ID）
今回は素材IDのみに着目
・素材IDの類似度をcos角度で求める＝マンネリ度
ガウス関数：間隔が短いとマンネリ度を感じるが、長いと感じない
シグモイド関数：ある程度似たものが続いてもマンネリを感じないが、あまりに際限なく続くとマンネリを感じる
・評価実験
提案モデル→最初の頃は累積データが少ないので過敏な結果になったが、割と近似できた
被験者によってマンネリの感じ方は大きな差がある
おかずによってマンネリ度に与える重みも違う
お弁当の色の変化もマンネリ感に影響を与える
質問1
マンネリが減っていく方のモデルは？次にカレーを何時出すか？
→マンネリを感じさせないところは調べられたけど、次においしく食べれるときの検出はしていない。
質問2
評価実験って実際に食わせてます？
→見せただけ
質問3
何故、お弁当を選んだのか？
→弁当作りの得意な子がいた
これはお弁当作成支援システムなのか？
→そう
■街メタファを用いたブックマーク整理支援システムの開発
東京農工大学 田端さん
・ソーシャルブックマークサービス
ユーザがブックマークの整理を積極的に行わない → 無秩序化
（↑整理作業に動機付けがないから）
→整理作業にゲーム性を与えて動機付けにする！
・街メタファの導入（都市建設シミュレーション：シムシティ）
都市を発展させながらブックマーク整理
ブックマークをドラッグし、その種類を選択（スポーツ、経済など）→スタジアムのアイコンがたつ
→関連性の近い建物が集中するほど発展する
→発展するとビルになったり、あばら屋になったりする。
建物がそれぞれベクトルを持ち、距離に応じて計算を行う→発展度
最終発展度と比較して、発展度が高ければ発展！低ければ衰退。。。
どのような配置が、整理された状態か？実際に作ってみた！
旅行サイトの集合とポータルサイトの集合に分かれた。
天気と旅行サイトは近かった。
質問1
背景に地図を持ってくる意味がよく分からない。街の区画をはっきりさせた方が見易くないか？
→今作ってる最中で、今後検討する。
質問2
ポータルサイトなんかは持ってるデータが多様すぎる。クラスタリングすると二次元平面上への表現が難しくないか？
→区画というもので対応したい。
ユーザがインタラクションして、何となく位置を決めるだけなのか？グループウェアに拡張する？
→する予定で居る。
===========
「飽きずに継続利用できる情報推薦」ってのはうちの研究室の先輩がやってるのにちょっと似てるかも。
先輩がやってるのは、「飽きる前にユーザの興味の揺れを感知して、新しい興味に振り向ける推薦」
……うーん、解明しようとしている内容は違うけど、ゴール的には一緒なのかな。
後で見せよう♪
この研究室ではこのテーマを今後深めていくらしいので楽しみ。
きちんと覚えておこー！
Pirka'rは結構面白そう。
推奨コードの提示機能までついてるのは、CSSに然程詳しくない身としてはかなり嬉しい。
ちょうど研究紹介サイトを新しく作り直さないといけない所だったので、ぜひぜひ使わせてもらおうと画策中♪
街メタファの導入については、品川先生の研究室の学生さんだったので、後で品川先生と話す機会があったときにちょっと疑問に思ったところを聞いてみた。
「これ初期投資が大変じゃないですか？」
そう、やってることは面白そうなんだけど、なんか最初に配置させる作業が面倒くさそうなんだよね。。。
品川先生曰く、デフォルトの配置などを提供できたら良いが、そのための理想的なデフォルト配置の情報もまだ足りない。まずは基礎的なデータを集めて行く事が必要とのこと。
あとビジュアルももうちょっと……、被験者実験前にアイコン画像が粗いのを何とかしたら、大分結果に反映されそうだなぁ。
まだまだ先は長そうなので、がんばって欲しいです。
これにてWI2の発表は全て終了。
みなさまお疲れ様でした！！
日曜日なのでお子ちゃま多数＜笑
WI2もこのセッションで終わり。
非常にためになる研究会でした。
===============
■学術研究プラットフォームのサービス提案
岡本さん
・YahooJapanで10年勤務
学術成果のプラットフォームを作りたいと考えるようになった。
・問題意識
インターネットの学術利用→ 専門分野の横断、研究者と市民の接続
→メディアの限界
→プラットフォームへの転換
学者や専門化がそれぞれ自分個人のウェブを管理し、最新の専門知識を競うように公開する時代が来れば良いと思う。
・基本コンセプト
インセンティブデザイン＝良い物を作れば作ってくれる→使わざるを得ない状況においていく
ユーザビリティ＝Web標準から遅れている
アビリゲート＝データを一元化しすぎると×（ブックマークはココ、ブログはアッチみたいな）サービスを取り込んでいく
インテリジェンス＆インタラクション！
・管理対象データの区分
Relation＝研究者同士の関連
Event＝研究会情報
Task＝TODO
Output＝上手く統合して行きたい
Process＝成果よりはプロセスをはっきり示すべきでは？
・インセンティブデザイン
自分自身に関る情報を整理→機械的な学習も必要
情報の発見
労力の削減→各種申請書類フォーマットへの対応
支援の獲得→プロセスの発表に対して、一般市民がDonateされる、Donateは謝辞や還元される
・課題
持続性 ビジネスモデル的な問題
商用利用禁止規定
依然クローズな基盤データ環境 APIを公開してくれない
質問1
プロセスを見せるのは面白い。研究者がサボってるかどうかもよく分かる。どう見せる？
→Twitter的なもので良い。等身大の研究者像を伝える。意外と研究者のブログでも研究については発信されていないから。
質問2
財閥系からの支援が得にくい。どうやって儲ける？
→ビジネスモデル的には難しい。当面は別の仕事で食っていく。透明な資金を集める。日本人は300万人の研究者がいる。学術産業をちゃんと立ち上げるべき。
質問3
国のやる仕事と民間のやる仕事は新しいところでレイヤーを引かないといけない。どのレベルまでやる事を期待している。
→基盤データを作るのは国の仕事（営利ビジネスとは立ち行かない）NIIやJSTにはデータプロバイダーとしてやってほしい
■XMLデータベースを用いた柔軟なUGCサービスの提案
NTTサイバースペース研究所 榎本さん
・XMLデータベース
なかなか市場が広がらない。。。
→蓄積して利用していく方向で広げていこう
モデルが違えば柔軟性も違う
→ユーザ生成コンテンツ（UGC）を構造化できるんじゃない？
イベント情報の共有サービス
http://www.craigslist.org/
http://tokyo.kijiji.co.jp/
・提案の骨子
うまく使えば、メンテフリーなシステムが作れるんじゃないか？
→テンプレートの利用
データの構造の異種性を超えられるんじゃない？
→自動レイアウト
質問1
新しい項目を増やすと検索のフィールドも増えていくのは面白い。ただ増えすぎた場合はどうするの？
→構造化をまずしてもらう。セットで使えるようなのをインテリジェントに求めるなどしたい。
質問2
スキーマの型は？
→基本的にテキストしている。型の推測か、ユーザが定義するか、方法は考えている。
質問3
教育分野にて、大学生のシラバスに使えるのでは？
→よく知らないのでまた教えてほしい
質問4
インタフェース周りがよく分からない。
→ユーザがよく使うものは残り、そうでないものは淘汰されていく。スキーマの進化があるんじゃないか？
ボトムアップにできていくところは面白い。
■Pirka'r: ブラウザ間非互換問題を解決するWebデザイナ向けツール
三菱総合研究所 飯尾さん
・様々なブラウザで問題なく閲覧できるコンテンツ作成支援
ユーザ視点で問題を見つめなおしてみるべき。
・Web標準のコンポーネント
HTML、CSS、Javascritp
同じコンテンツでも表現や動作に違いが出る（becauseブラウザ戦争など）
・WaSPのアプローチ（伽藍方式）：ブラウザベンダに注意
・バザール方式：問題のあるコンテンツを探して警告
・20万サイトを調査、142種類の非互換性（自動チェックできるのが）→3割のサイトに問題を発見
・原因の分析
オーサリングツールの問題（HPビルダー）
発注者側の意識 特定ブラウザだけ対応すりゃいいや
作成者の意識 テストに工数をかけたくない
最近はWebブラウザも増えたし、携帯からのアクセスも増えた
→支援ツールPirka'r http://pirkar.ashikunep.org/
1.標準準拠チェック
2.ブラウザ互換性チェック
3.マルチブラウザ視認チェック
？？チェックするだけ？修正候補は出してくれない？？
質問1
コミッタになれそうな人はいるのか？
→まずはJavaScriptでチェック。共同会社がひっぱってきてくれる予定
質問2
現場でWebデザインしているとIE6だと例外構造を出したりする必要がある。全部に対応しようとしている？それともばしっと？
→前の方。
■飽きずに継続利用できる情報推薦の実現に向けた試み
中央大学大学院 稲村さん
・協調フィルタリングなどの既存の推薦手法は、ユーザが感じる「飽き」という感性的な側面まで考慮していない
→「飽き」を感じる感性モデルを明らかにする
お弁当の献立作成をモデルにする！
メニューの固定化。マンネリ化。。。
・お弁当
複数のおかずからなる
素材
味 五味五色五法
色
素材
お弁当を特徴ベクトルで表現する
おかずID（素材ID、味ID、色ID、調理法ID）
今回は素材IDのみに着目
・素材IDの類似度をcos角度で求める＝マンネリ度
ガウス関数：間隔が短いとマンネリ度を感じるが、長いと感じない
シグモイド関数：ある程度似たものが続いてもマンネリを感じないが、あまりに際限なく続くとマンネリを感じる
・評価実験
提案モデル→最初の頃は累積データが少ないので過敏な結果になったが、割と近似できた
被験者によってマンネリの感じ方は大きな差がある
おかずによってマンネリ度に与える重みも違う
お弁当の色の変化もマンネリ感に影響を与える
質問1
マンネリが減っていく方のモデルは？次にカレーを何時出すか？
→マンネリを感じさせないところは調べられたけど、次においしく食べれるときの検出はしていない。
質問2
評価実験って実際に食わせてます？
→見せただけ
質問3
何故、お弁当を選んだのか？
→弁当作りの得意な子がいた
これはお弁当作成支援システムなのか？
→そう
■街メタファを用いたブックマーク整理支援システムの開発
東京農工大学 田端さん
・ソーシャルブックマークサービス
ユーザがブックマークの整理を積極的に行わない → 無秩序化
（↑整理作業に動機付けがないから）
→整理作業にゲーム性を与えて動機付けにする！
・街メタファの導入（都市建設シミュレーション：シムシティ）
都市を発展させながらブックマーク整理
ブックマークをドラッグし、その種類を選択（スポーツ、経済など）→スタジアムのアイコンがたつ
→関連性の近い建物が集中するほど発展する
→発展するとビルになったり、あばら屋になったりする。
建物がそれぞれベクトルを持ち、距離に応じて計算を行う→発展度
最終発展度と比較して、発展度が高ければ発展！低ければ衰退。。。
どのような配置が、整理された状態か？実際に作ってみた！
旅行サイトの集合とポータルサイトの集合に分かれた。
天気と旅行サイトは近かった。
質問1
背景に地図を持ってくる意味がよく分からない。街の区画をはっきりさせた方が見易くないか？
→今作ってる最中で、今後検討する。
質問2
ポータルサイトなんかは持ってるデータが多様すぎる。クラスタリングすると二次元平面上への表現が難しくないか？
→区画というもので対応したい。
ユーザがインタラクションして、何となく位置を決めるだけなのか？グループウェアに拡張する？
→する予定で居る。
===========
「飽きずに継続利用できる情報推薦」ってのはうちの研究室の先輩がやってるのにちょっと似てるかも。
先輩がやってるのは、「飽きる前にユーザの興味の揺れを感知して、新しい興味に振り向ける推薦」
……うーん、解明しようとしている内容は違うけど、ゴール的には一緒なのかな。
後で見せよう♪
この研究室ではこのテーマを今後深めていくらしいので楽しみ。
きちんと覚えておこー！
Pirka'rは結構面白そう。
推奨コードの提示機能までついてるのは、CSSに然程詳しくない身としてはかなり嬉しい。
ちょうど研究紹介サイトを新しく作り直さないといけない所だったので、ぜひぜひ使わせてもらおうと画策中♪
街メタファの導入については、品川先生の研究室の学生さんだったので、後で品川先生と話す機会があったときにちょっと疑問に思ったところを聞いてみた。
「これ初期投資が大変じゃないですか？」
そう、やってることは面白そうなんだけど、なんか最初に配置させる作業が面倒くさそうなんだよね。。。
品川先生曰く、デフォルトの配置などを提供できたら良いが、そのための理想的なデフォルト配置の情報もまだ足りない。まずは基礎的なデータを集めて行く事が必要とのこと。
あとビジュアルももうちょっと……、被験者実験前にアイコン画像が粗いのを何とかしたら、大分結果に反映されそうだなぁ。
まだまだ先は長そうなので、がんばって欲しいです。
これにてWI2の発表は全て終了。
みなさまお疲れ様でした！！
第15回WI2研究会 2日目セッション3「ユーザ行動分析とWebページ解析」
2日目午前の後半戦。
空腹との戦いでした。
============
■リアルタイム閲覧者ネットワークによる検索システムの提案
京都産業大学 松井さん
・背景と問題点
情報取得：検索サービス、コミュニケーションサービス
→Webページをライブで閲覧しているユーザのネットワークをリアルタイムで構築
・Wiredシステム
ライブ検索機能
ライブ閲覧者の発見
注目記事をすばやく発見
ページコミュニケーション機能
同じ興味を持つユーザからの支援
・システム概要
リアルタイムな閲覧人数に基づいて既存の検索エンジンによって返される結果をリランキング（人数順）
Firefoxアドオンで実現しているっぽい
同一ページ閲覧ユーザとコミュニケーションが行える
ページに入ると、そのページ内にいる別のユーザが緑色の●として浮いてチャットができる。
・アドオンのダウンロードページ
http://klab.kyoto-su.ac.jp/~matui
質問1
同じページを見ているからといって同じ興味を持つのか？探している者同士だとお互いにそのテーマが分かっていないのでは？
→アバウトに考えてるので、もうちょっと考察した方が良いとは考えている。
質問2
どういうユーザを想定しているのか？新しいコミュニケーションメディアを提案しているのか検索システムを提案しているのか？
→同列に考えいている
質問3
たくさんの人が使ったら破綻しちゃいそう。
→ユーザの表示上限数は提示できる。目的別のチャットルームを立てる。
質問4
同時閲覧しているかはサーバ管理。検索結果のコンテンツからさらにリンクをクリックとれる？
→とれる
質問5
実際にWebページをみているひとが一覧で出たサービスがあった気がするんだけど、
→検索と組み合わせてユーザの発見をやりやすくしている点は独自性がある。
■非タスク試行型対話システムにおける非同期並列的相互作用による言語獲得手法の提案
北海道大学 若原さん
・雑談のできるロボット＝非タスク志向型対話システム
・知識源としてWebを用いる→予め何でも知っているように見えるシステムができる
→コストが高い
・チャットルームを公開し多数のユーザに利用してもらう→人間との対話から学習する
→少しずつ話せるようにする
・非同期並列的相互作用
システムとユーザがきれいに交互というのが多くのシステム。
実際のチャット：必ずしも二者ではないし、交互でもない。
→内部状態を挟んで入力フェーズと出力フェーズが独立している
・入力フェーズ
4文字部分のWindowを使ってセグメント分割
セグメントを発話キャッシュに保存
・出力フェーズ
内部状態を常に監視し、内部状態でもっとも重みの高いセグメントを発話 （マルコフ連鎖）
・miniブログ上に人間と対話を行うシステムを実装
→Twitterにて公開 ＠hadzimmo
人間同士の対話から学習
全く白紙の初期状態→現在：学習開始から1ヶ月程度
キャッシュ：対話の開始から終了まで保持
対話の観測対象ユーザ数300人
対話に実際に参加9名
「おはよう」「おかえり」くらいは出来たらしい。他にも。
「デートしてください」「喜ん。。。wwww」
「おはようございます」「おめでとうございます」
「お、お疲れ様です」「仙台から乙ありでーす」
※ ちょっと笑える。おもろー！
・考察
学習量がたりない
整合性のない対話が多く見られた
・今後の課題
マルコフ連鎖に代わる発話生成方の開発
あいづちの挿入
ユーザの感情を判断
質問1
Twitterをターゲットにしたのは？
→チャットらしいチャットだと、話題が錯綜して対応できない。Twitterだと大体一つの話題でまとまっている。
Twitterは頻繁に会話にならない。あまり会話らしい会話ができない。
→今のままでは困難なので、Twitterに限らずにやっていきたい。
質問2
雑談を成立させようとすると、意味の塊が重要になってくる。表層を貯めていくと、意味に転換することを考えているのか？それともある程度データをためたら、内部に意味を組み込むようなフェーズに踏み込むのか？
→今のところ表層以外を考えていない。今後検討する。
質問3
ワンパターンな会話に陥ってしまわないか？
→出力リストの一番上のものだけを用いるのではなく、ランダムで出力している。
■情報探索プロセスにおける利用者の検索履歴活用行動の分析
筑波大学 松村さん
・モチベーション：Googleなどの検索システムが持つ多様な機能は、本当に情報探索に役立っているのか？
・利用者の情報探索プロセスを明らかにする
→今回は検索履歴の活用、どんなとき、何故、どのように使ってるのか
→検索履歴の有効な使い方を明らかにする
・実験 2007年8月～2008年5月
協力者：10名（図書館情報学、看護学、教育学、医学） エキスパート？？
フェーズ1 自分でテーマを決定、文献収集、適合判定 どんなテーマがあったの？？
フェーズ2 追加収集
ここまでは通常の検索システム
フェーズ3 履歴活用行動取得実験（ログ、発話思考法、インタビューなど）
履歴を見ながらやってもらった
タスク1 過去に自分が検索したテーマで5件
タスク2 過去に自分が検索していない、他者がやったテーマで3件
関連クエリ(検索キーワード)＝テーマ
適合だと思ったってのはどうやって抽出しているの？？
他者の関連文献について、入力キーワードの妥当性が確認できる
検索戦略の切り替え、自分他人の渡り歩き→行き詰ったとき、レスポンスがおそいとき
・今後
ミクロな分析からプロセス全体へ
質問1
ログの量に差はなかった？
→かなりあった。
■ユーザ関与を伴った推薦方式設計
大阪大学 甲斐さん
・モチベーション：推薦の精度はある程度向上した、今後は精度向上だけでなくユーザ満足度を向上させるべき
・ユーザ関与
ユーザが推薦仮定に介入し、推薦機構を制御すること
ユーザ負荷を下げる
MediaUnbound：35もの質問に答える必要がある
eHarmony：一時間程度かかるアンケート ユーザ負荷がかかるが
？？どういうユーザを対象にしているかによりけりで、負荷に耐えられるかどうかは何を得たいかによるのでは？？
・提案手法
推薦過程に関与すると言う好意事態が満足度に影響するのでは
音楽推薦システムを実装、
どのような関与を用いるか
どうのような推薦アルゴリズムを用いるか？
・Rating（好き、嫌い）
・コンテキスト入力（いつ、どこで、誰と）：ユーザの嗜好は状況によって違う
・コンテンツ属性指定（推薦してほしいコンテンツの属性を明示的に指定）
・プロファイル編集（ユーザプロファイルの可視化）
推薦結果にRatingするのは全部同じ。
関与を反映しているグループと反映していないグループの2とおり。
ベイズ推定を用いた内容に基づくフィルタリング
ユーザが好きな曲・好きでない曲のコンテンツ属性の頻度を学習
各楽曲をユーザが好む確率を学習
？？夜好きな曲っていう曲の属性情報はどうやって求めている？？
・分析項目
満足度
関与の度合い
推薦精度
被験者の音楽に対する興味の度合い
質問1
コンテンツ量が増大した場合、コンテンツの属性をどうやって対応するのか？
→ユーザに評価してもらう。またランダムに幾つかとって評価してもらい、それで補完していく。
質問2
負荷に耐えられるかどうかは何を得たいかによるのでは？
→実験で真剣さについても検討する。
■Webページ間の共通性の発見に基づく多層的な発見に基づく多層的なWeb閲覧セッションの抽出
兵庫県立大学 木村さん
・閲覧履歴を多層的に表現する手法
・Web閲覧セッションとする
→ラベルを付与し、一繋がりを1セッションとする
・上位階層の発見
となりあうセッション同士をTF-IDFで主な用語を抜き出し、重なった用語の中で分散が最小の語を上位階層ワードとする
・下位階層の発見
各ページの候補キーワードの和集合を求め、なんちゃらかんちゃら
・実験
セッション切れ目に失敗が多い
質問1
情報推薦に結び付けたいとはどうやった形なのか？推薦に利用するとなるとどういう風な粒度でどういう風にとるのかが影響するのでは？
→割と楽観的に考えている。ゴールを先に決めておくべきだった。
研究で整理された事項が、役立つようにしてほしい。
質問2
将来像があまり明確でないようだが、、、グルーピングした結果をユーザに見せてあげて推薦するのか、取った情報を裏方として使うのか？
→裏方として考えている。
その場合、かなり精度が必要になる。インタラクションしながらだと、もうちょっと気持ち悪さはないのでそちらを考えてはどうか？
質問3
内容に加えてアクセスや時間は活用するの？
→していない。
■ソーシャルブックマークの分析に基づく競合Webページの発見
兵庫県立大学 湯本さん
・目的：ソーシャルブックマークを用いて競合ページを発見し、その情報を用いて対象ページの価値判断を支援する
競合Webページの定義：分類できる最も細かいカテゴリが対象ページと同じWebページ
タグの親子関係を求め、代表タグ集合（ページに付与された主要なタグのうち、子を持たないトピックタグ）を形成する
↑親子関係そのものはソーシャルブックマークから調べる
・提案手法
1.対象ページの代表タグ集合を取得
2.代表タグ集合内のタグが用いられるページ集合を取得
3.ランキングするっぽい
ブックマークされていないWebページ：自動タグ付け（Tf-idfなどを使う）
競合Webページへのリンクを提示してあげる。
？？Googleでいう関連ページのことかな？？
・予備実験
代表タグ集合によるページ集合の取得→条件の緩和が必要
自動タグ付けの精度確認→不正解のタグを含んでしまうことが多かった
質問1
タグを階層化するべきか？もともとタグはディレクトリ構造へのアンチテーゼでは？
→完全に全てを階層化するわけではない。
親子関係というのは完全なツリー構造なのではない？
→そのとおり。
競合Webページというより、分類が同種であるというニュアンスを持たせた方が良い。
============
ハジモ君は面白かった。
後でTwitter見に行ったけど。。。なかなか苦労していらっしゃるようで＜苦笑
一番興味があったのは「ユーザ関与を伴った推薦方式」
これは「設計」というよりも、ユーザ関与と推薦の精度の両者の「相関を定式化」する研究として捉えるべきかな。
大変興味深い研究。結果が楽しみ。
音楽を対象にしてるなら、Music Genome Projectとかも良い感じに使えそう。
ユーザが提供するデータが増えれば増えるほど勿論推薦の精度はあがる。
ただそれを嫌がったり面倒くさがるユーザが多いから、クリック履歴や閲覧履歴からこっそりユーザのデータを取ってくる方向に今は進んでいる。。。
見つかる.jpとかはそこを思いっきり踏み倒して、ユーザに面倒くさい入力を求める代わりに的確な商品の推薦を行うように工夫されている。（ファジィ理論も少しあるみたい）
あそこらへんのユーザ関与を「定式化」できれば推薦に良い指標が生まれそうだなぁ。
空腹との戦いでした。
============
■リアルタイム閲覧者ネットワークによる検索システムの提案
京都産業大学 松井さん
・背景と問題点
情報取得：検索サービス、コミュニケーションサービス
→Webページをライブで閲覧しているユーザのネットワークをリアルタイムで構築
・Wiredシステム
ライブ検索機能
ライブ閲覧者の発見
注目記事をすばやく発見
ページコミュニケーション機能
同じ興味を持つユーザからの支援
・システム概要
リアルタイムな閲覧人数に基づいて既存の検索エンジンによって返される結果をリランキング（人数順）
Firefoxアドオンで実現しているっぽい
同一ページ閲覧ユーザとコミュニケーションが行える
ページに入ると、そのページ内にいる別のユーザが緑色の●として浮いてチャットができる。
・アドオンのダウンロードページ
http://klab.kyoto-su.ac.jp/~matui
質問1
同じページを見ているからといって同じ興味を持つのか？探している者同士だとお互いにそのテーマが分かっていないのでは？
→アバウトに考えてるので、もうちょっと考察した方が良いとは考えている。
質問2
どういうユーザを想定しているのか？新しいコミュニケーションメディアを提案しているのか検索システムを提案しているのか？
→同列に考えいている
質問3
たくさんの人が使ったら破綻しちゃいそう。
→ユーザの表示上限数は提示できる。目的別のチャットルームを立てる。
質問4
同時閲覧しているかはサーバ管理。検索結果のコンテンツからさらにリンクをクリックとれる？
→とれる
質問5
実際にWebページをみているひとが一覧で出たサービスがあった気がするんだけど、
→検索と組み合わせてユーザの発見をやりやすくしている点は独自性がある。
■非タスク試行型対話システムにおける非同期並列的相互作用による言語獲得手法の提案
北海道大学 若原さん
・雑談のできるロボット＝非タスク志向型対話システム
・知識源としてWebを用いる→予め何でも知っているように見えるシステムができる
→コストが高い
・チャットルームを公開し多数のユーザに利用してもらう→人間との対話から学習する
→少しずつ話せるようにする
・非同期並列的相互作用
システムとユーザがきれいに交互というのが多くのシステム。
実際のチャット：必ずしも二者ではないし、交互でもない。
→内部状態を挟んで入力フェーズと出力フェーズが独立している
・入力フェーズ
4文字部分のWindowを使ってセグメント分割
セグメントを発話キャッシュに保存
・出力フェーズ
内部状態を常に監視し、内部状態でもっとも重みの高いセグメントを発話 （マルコフ連鎖）
・miniブログ上に人間と対話を行うシステムを実装
→Twitterにて公開 ＠hadzimmo
人間同士の対話から学習
全く白紙の初期状態→現在：学習開始から1ヶ月程度
キャッシュ：対話の開始から終了まで保持
対話の観測対象ユーザ数300人
対話に実際に参加9名
「おはよう」「おかえり」くらいは出来たらしい。他にも。
「デートしてください」「喜ん。。。wwww」
「おはようございます」「おめでとうございます」
「お、お疲れ様です」「仙台から乙ありでーす」
※ ちょっと笑える。おもろー！
・考察
学習量がたりない
整合性のない対話が多く見られた
・今後の課題
マルコフ連鎖に代わる発話生成方の開発
あいづちの挿入
ユーザの感情を判断
質問1
Twitterをターゲットにしたのは？
→チャットらしいチャットだと、話題が錯綜して対応できない。Twitterだと大体一つの話題でまとまっている。
Twitterは頻繁に会話にならない。あまり会話らしい会話ができない。
→今のままでは困難なので、Twitterに限らずにやっていきたい。
質問2
雑談を成立させようとすると、意味の塊が重要になってくる。表層を貯めていくと、意味に転換することを考えているのか？それともある程度データをためたら、内部に意味を組み込むようなフェーズに踏み込むのか？
→今のところ表層以外を考えていない。今後検討する。
質問3
ワンパターンな会話に陥ってしまわないか？
→出力リストの一番上のものだけを用いるのではなく、ランダムで出力している。
■情報探索プロセスにおける利用者の検索履歴活用行動の分析
筑波大学 松村さん
・モチベーション：Googleなどの検索システムが持つ多様な機能は、本当に情報探索に役立っているのか？
・利用者の情報探索プロセスを明らかにする
→今回は検索履歴の活用、どんなとき、何故、どのように使ってるのか
→検索履歴の有効な使い方を明らかにする
・実験 2007年8月～2008年5月
協力者：10名（図書館情報学、看護学、教育学、医学） エキスパート？？
フェーズ1 自分でテーマを決定、文献収集、適合判定 どんなテーマがあったの？？
フェーズ2 追加収集
ここまでは通常の検索システム
フェーズ3 履歴活用行動取得実験（ログ、発話思考法、インタビューなど）
履歴を見ながらやってもらった
タスク1 過去に自分が検索したテーマで5件
タスク2 過去に自分が検索していない、他者がやったテーマで3件
関連クエリ(検索キーワード)＝テーマ
適合だと思ったってのはどうやって抽出しているの？？
他者の関連文献について、入力キーワードの妥当性が確認できる
検索戦略の切り替え、自分他人の渡り歩き→行き詰ったとき、レスポンスがおそいとき
・今後
ミクロな分析からプロセス全体へ
質問1
ログの量に差はなかった？
→かなりあった。
■ユーザ関与を伴った推薦方式設計
大阪大学 甲斐さん
・モチベーション：推薦の精度はある程度向上した、今後は精度向上だけでなくユーザ満足度を向上させるべき
・ユーザ関与
ユーザが推薦仮定に介入し、推薦機構を制御すること
ユーザ負荷を下げる
MediaUnbound：35もの質問に答える必要がある
eHarmony：一時間程度かかるアンケート ユーザ負荷がかかるが
？？どういうユーザを対象にしているかによりけりで、負荷に耐えられるかどうかは何を得たいかによるのでは？？
・提案手法
推薦過程に関与すると言う好意事態が満足度に影響するのでは
音楽推薦システムを実装、
どのような関与を用いるか
どうのような推薦アルゴリズムを用いるか？
・Rating（好き、嫌い）
・コンテキスト入力（いつ、どこで、誰と）：ユーザの嗜好は状況によって違う
・コンテンツ属性指定（推薦してほしいコンテンツの属性を明示的に指定）
・プロファイル編集（ユーザプロファイルの可視化）
推薦結果にRatingするのは全部同じ。
関与を反映しているグループと反映していないグループの2とおり。
ベイズ推定を用いた内容に基づくフィルタリング
ユーザが好きな曲・好きでない曲のコンテンツ属性の頻度を学習
各楽曲をユーザが好む確率を学習
？？夜好きな曲っていう曲の属性情報はどうやって求めている？？
・分析項目
満足度
関与の度合い
推薦精度
被験者の音楽に対する興味の度合い
質問1
コンテンツ量が増大した場合、コンテンツの属性をどうやって対応するのか？
→ユーザに評価してもらう。またランダムに幾つかとって評価してもらい、それで補完していく。
質問2
負荷に耐えられるかどうかは何を得たいかによるのでは？
→実験で真剣さについても検討する。
■Webページ間の共通性の発見に基づく多層的な発見に基づく多層的なWeb閲覧セッションの抽出
兵庫県立大学 木村さん
・閲覧履歴を多層的に表現する手法
・Web閲覧セッションとする
→ラベルを付与し、一繋がりを1セッションとする
・上位階層の発見
となりあうセッション同士をTF-IDFで主な用語を抜き出し、重なった用語の中で分散が最小の語を上位階層ワードとする
・下位階層の発見
各ページの候補キーワードの和集合を求め、なんちゃらかんちゃら
・実験
セッション切れ目に失敗が多い
質問1
情報推薦に結び付けたいとはどうやった形なのか？推薦に利用するとなるとどういう風な粒度でどういう風にとるのかが影響するのでは？
→割と楽観的に考えている。ゴールを先に決めておくべきだった。
研究で整理された事項が、役立つようにしてほしい。
質問2
将来像があまり明確でないようだが、、、グルーピングした結果をユーザに見せてあげて推薦するのか、取った情報を裏方として使うのか？
→裏方として考えている。
その場合、かなり精度が必要になる。インタラクションしながらだと、もうちょっと気持ち悪さはないのでそちらを考えてはどうか？
質問3
内容に加えてアクセスや時間は活用するの？
→していない。
■ソーシャルブックマークの分析に基づく競合Webページの発見
兵庫県立大学 湯本さん
・目的：ソーシャルブックマークを用いて競合ページを発見し、その情報を用いて対象ページの価値判断を支援する
競合Webページの定義：分類できる最も細かいカテゴリが対象ページと同じWebページ
タグの親子関係を求め、代表タグ集合（ページに付与された主要なタグのうち、子を持たないトピックタグ）を形成する
↑親子関係そのものはソーシャルブックマークから調べる
・提案手法
1.対象ページの代表タグ集合を取得
2.代表タグ集合内のタグが用いられるページ集合を取得
3.ランキングするっぽい
ブックマークされていないWebページ：自動タグ付け（Tf-idfなどを使う）
競合Webページへのリンクを提示してあげる。
？？Googleでいう関連ページのことかな？？
・予備実験
代表タグ集合によるページ集合の取得→条件の緩和が必要
自動タグ付けの精度確認→不正解のタグを含んでしまうことが多かった
質問1
タグを階層化するべきか？もともとタグはディレクトリ構造へのアンチテーゼでは？
→完全に全てを階層化するわけではない。
親子関係というのは完全なツリー構造なのではない？
→そのとおり。
競合Webページというより、分類が同種であるというニュアンスを持たせた方が良い。
============
ハジモ君は面白かった。
後でTwitter見に行ったけど。。。なかなか苦労していらっしゃるようで＜苦笑
一番興味があったのは「ユーザ関与を伴った推薦方式」
これは「設計」というよりも、ユーザ関与と推薦の精度の両者の「相関を定式化」する研究として捉えるべきかな。
大変興味深い研究。結果が楽しみ。
音楽を対象にしてるなら、Music Genome Projectとかも良い感じに使えそう。
ユーザが提供するデータが増えれば増えるほど勿論推薦の精度はあがる。
ただそれを嫌がったり面倒くさがるユーザが多いから、クリック履歴や閲覧履歴からこっそりユーザのデータを取ってくる方向に今は進んでいる。。。
見つかる.jpとかはそこを思いっきり踏み倒して、ユーザに面倒くさい入力を求める代わりに的確な商品の推薦を行うように工夫されている。（ファジィ理論も少しあるみたい）
あそこらへんのユーザ関与を「定式化」できれば推薦に良い指標が生まれそうだなぁ。
第15回WI2研究会 2日目セッション2「評価・サービス統合」
遅刻しました。
ホント申し訳ないです。
まさか、ICOCAのチャージが0円になってるとは思わず、駅に駆け込もうとしたところで
ピンポーン☆
泣く泣く切符を買ってる間に電車は行ってしまいました。。。
私の阿呆。。。
幸先の悪いスタートでしたが、発表はきっちりと聞かせていただきました。
以下、メモです。
===============
■関連単語抽出アルゴリズムの改良と評価
九州大学 倉門先生
・提案手法
関連語の抽出：TF-IDFを用い、ある範囲内にある語のみに絞り、目的語に近い語に高い評価値を与える。
複数文書間の重み付け：文書頻度の逆数（IDF）を利用して、多くの文書に習われる単語の評価値を抑える
→語数の多いテキストの重みを抑えるために、正規化を行う
？？今まで正規化しなかったのか？？
・実験
従来手法、提案手法、従来手法＋局所的重み付け、従来手法＋大局的重み付け、TF、IDF。
元データはGoogleの検索結果の上位ページ：検索結果が不良となるクエリを用いるべき？
被験者４人、４パターンで確認。
→平均値は向上した。
質問1
限定する範囲は、段落をまたいだ場合でも有効なのか？
→今は有効になっている。今後は対応していきたい。
質問2
Googleのサジェストと真っ向からぶつかるところを目指している。瞬時に候補を出せるメリットがある。
→Googleサジェストの結果と比較すると、Googleの方が履歴を利用しているので真っ当な感じがする。
質問3
統計的なベーシックな手法だと感じた。クエリの分野マップを見たときに自分の研究はどこに位置していると思うか？
→今後関連研究についても詳しく調べる
質問4
実験について詳しく教えてほしい
提案手法のスコアが高い方がユーザが高く評価していると本当に言えるのか？
質問5
どういうページを検索したいんでしょうか？不良なページを使うと結局精度が下がってしまうのでは？
→かも知れない。
■ODPを利用したユーザプロファイル作成と個別化検索システムの評価
九州大学 中村さん
・研究背景
→検索システムの性能の向上が必要
・ODP Open Direcotry Project
話題の階層向上でWebページを分類した世界最大のWebディレクトリ
人手に寄ってWebページを分類
・提案手法
ODPの各ディレクトリに属するWebページの内容に着目
トップだけでなく、ODPの上位2階層を利用したユーザの興味・関心を細かく表現したユーザプロファイルの作成
・ユーザプロファイルの作成
ODPの各ディレクトリをインデックスとするベクトル
従来手法ではODPの各最上位ディレクトリをインデックスとしたベクトルで表現
→提案手法：下位ディレクトリ2層目まで。細かなプロファイリングが可能
1.ODPに属するWebページ群から単語を抽出
2.各単語が各ディレクトリにどのくらい関連しているか？
3.パーソナルドキュメントから単語を抽出（E-mailとか）
4.関連度を見る
一般のWeb検索エンジンで検索された結果をReranking
↑ベクトルの比較はcos類似度を用いる、これの順にランキング
各単語の関連度算出→エントロピー
ページベクトル：Webページのディレクトリへの関連度
最上位ディレクトリの選定
初期検索結果の上位10件、20件のタイトルとSNIPPET（紹介文）から単語を抽出
ODP最上位ディレクトリの関連度を求め、一番大きいのを選定
・評価実験
初期検索における適合率が50％以下のものを使用する。
？？この実験条件は不味くないか？？
ここでちょっと力尽きた。。。
質問1
ページを一つ選んだらそれを基準にRerankingする。最初に選んだページが本当にパーソナルデータであるのか？
→一応、全部に目を通してもらってから選んでもらっている。
複数のカテゴリにまたがるような文書がほしい場合は最大のディレクトリ一つをとるのは適切な結果をだせるのか？例えば証券システムがダウン場合、経済、システム対応の2つが見たい
→プロファイルのベクトルが両方のカテゴリに対して値を持っていれば、見つけることはできる
質問2
一番上のところでは粒度が粗すぎて、もっと下の方を見ないといけないのでは？
→階層構造なので、下が膨大になってしまうので
それは分かるが、そういう問題に立ち向かうにはこれと戦わないといけない
→今回1、2層と広げてみた。今後も掘り下げていきたいと思っている。
どういうユーザが対象のシステムなのか？
→検索のときに自分の見たいページをうまく見つけたいというユーザ全般。
リランキングしたいんであれば、もっと最初のところから入っていかないといけないのでは？
質問3
第一階層よりも第二階層の方が粒度が上がる？パーソナルデータから出たtf-idfを使った方が良いのでは？何故ODPを使ったのかがよく分からない。
→単にカテゴリを使おうと思った。
■拡張可能関係データベース管理システムを用いたWebサービス統合
山口大学 松井さん（同姓同名が研究室にいてビビッた。。。）
・提案手法
それぞれ存在するWebサービスへのアクセスをSQLによる問い合わせを行う
DBMSに全てのアクセスを集中させる。
PHP/PLでユーザ関数を記述する
→ユーザ自身の手で作るのは負担になるし、ソフトウェアの信頼性も下がる
Pg/WAFL：ユーザ定義関数のXMLによる仕様記述
※ とりあえず帰ってくるカラム名は自力で調べる必要があるっぽい
RSSリーダとかが実装例
？？XMLデータベースを使わないのか？？
・Webサービス
HTTPを用いた情報交換によりサービス
XMLで利用（SOAPなど）
・関連研究
EaRDB：ユーア定義関数を用いてWebサービスにアクセス。ユーザ定義関数の自動生成はできない。
YahooQueryLanguage：データソースのXMLによる記述を与える。複数のWebサービスへのアクセスは不可。
質問1
PgWAFLはWPLに比べるとアプリケーションよりの技術になっているのでは？あまり手間が減らないんじゃ？
→調査不足もあってWPLなどにあわせた記述にすべきだった。
RESTを対象としているところで結構ややこしいように思える。RSSについてもベンダ独自だったり、して大混乱する。Webアプリケーションの開発では統合的な記述としては解決できてないのでは？どの辺まで解決したいの？
SOAPはXMLのフォーマットで仕様記述が完全だけど、RESTは記述に限界がある。RESTを使うなら、その辺も考えて作らないといけない。
質問2
SQLの形でアクセスしようとしている。ユーザ定義関数を作るメリットは？
質問3：XMLで表現できる情報の空間とRDBで表現できる空間って違うようね？Amazonのデータは著者が複数帰ってきてその人数は分からない。その場合ユーザ定義関数はどうかけるのか？
→対応できない。
XMLとRDBの本質的な違いになる部分をちゃんと定義できるようにしてしまわないと難しい。
質問4
認証付きサービスについては考えているの？
質問5
全検索結果からのどこからどこまで取る？
→ページ数の指定はできる
全ての検索結果をえるのに何度もリクエストをしないといけない場合もある。それは大丈夫？
→ユーザ定義処理の中に繰り返し記述をする。
===============
関連単語の抽出とODPは、結構うちの研究室でも使えそうな技術だな。
Webサービス統合は魅力的な提案ではあるけど、やっぱり難しそう。
XMLDBを使えば良いのにと簡単に考えていたけど、その後先生たちから
・XMLDBの知名度や実用性
・XMLDBの形がアプリケーション実装者にとって嬉しい形なのか
という問題が挙がった。。。確かに。
それにWebサービス統合って、結局利用するアプリケーション依存、そこで拡張が激しくなってしまいそう。認証とかセキュリティの話が入ってくると尚更。
そういやRESTメインでやってたけど、確かGoogleAppsにSOAPじゃないと取れないデータがあった気が。。。ムツカシイなぁ。
ホント申し訳ないです。
まさか、ICOCAのチャージが0円になってるとは思わず、駅に駆け込もうとしたところで
ピンポーン☆
泣く泣く切符を買ってる間に電車は行ってしまいました。。。
私の阿呆。。。
幸先の悪いスタートでしたが、発表はきっちりと聞かせていただきました。
以下、メモです。
===============
■関連単語抽出アルゴリズムの改良と評価
九州大学 倉門先生
・提案手法
関連語の抽出：TF-IDFを用い、ある範囲内にある語のみに絞り、目的語に近い語に高い評価値を与える。
複数文書間の重み付け：文書頻度の逆数（IDF）を利用して、多くの文書に習われる単語の評価値を抑える
→語数の多いテキストの重みを抑えるために、正規化を行う
？？今まで正規化しなかったのか？？
・実験
従来手法、提案手法、従来手法＋局所的重み付け、従来手法＋大局的重み付け、TF、IDF。
元データはGoogleの検索結果の上位ページ：検索結果が不良となるクエリを用いるべき？
被験者４人、４パターンで確認。
→平均値は向上した。
質問1
限定する範囲は、段落をまたいだ場合でも有効なのか？
→今は有効になっている。今後は対応していきたい。
質問2
Googleのサジェストと真っ向からぶつかるところを目指している。瞬時に候補を出せるメリットがある。
→Googleサジェストの結果と比較すると、Googleの方が履歴を利用しているので真っ当な感じがする。
質問3
統計的なベーシックな手法だと感じた。クエリの分野マップを見たときに自分の研究はどこに位置していると思うか？
→今後関連研究についても詳しく調べる
質問4
実験について詳しく教えてほしい
提案手法のスコアが高い方がユーザが高く評価していると本当に言えるのか？
質問5
どういうページを検索したいんでしょうか？不良なページを使うと結局精度が下がってしまうのでは？
→かも知れない。
■ODPを利用したユーザプロファイル作成と個別化検索システムの評価
九州大学 中村さん
・研究背景
→検索システムの性能の向上が必要
・ODP Open Direcotry Project
話題の階層向上でWebページを分類した世界最大のWebディレクトリ
人手に寄ってWebページを分類
・提案手法
ODPの各ディレクトリに属するWebページの内容に着目
トップだけでなく、ODPの上位2階層を利用したユーザの興味・関心を細かく表現したユーザプロファイルの作成
・ユーザプロファイルの作成
ODPの各ディレクトリをインデックスとするベクトル
従来手法ではODPの各最上位ディレクトリをインデックスとしたベクトルで表現
→提案手法：下位ディレクトリ2層目まで。細かなプロファイリングが可能
1.ODPに属するWebページ群から単語を抽出
2.各単語が各ディレクトリにどのくらい関連しているか？
3.パーソナルドキュメントから単語を抽出（E-mailとか）
4.関連度を見る
一般のWeb検索エンジンで検索された結果をReranking
↑ベクトルの比較はcos類似度を用いる、これの順にランキング
各単語の関連度算出→エントロピー
ページベクトル：Webページのディレクトリへの関連度
最上位ディレクトリの選定
初期検索結果の上位10件、20件のタイトルとSNIPPET（紹介文）から単語を抽出
ODP最上位ディレクトリの関連度を求め、一番大きいのを選定
・評価実験
初期検索における適合率が50％以下のものを使用する。
？？この実験条件は不味くないか？？
ここでちょっと力尽きた。。。
質問1
ページを一つ選んだらそれを基準にRerankingする。最初に選んだページが本当にパーソナルデータであるのか？
→一応、全部に目を通してもらってから選んでもらっている。
複数のカテゴリにまたがるような文書がほしい場合は最大のディレクトリ一つをとるのは適切な結果をだせるのか？例えば証券システムがダウン場合、経済、システム対応の2つが見たい
→プロファイルのベクトルが両方のカテゴリに対して値を持っていれば、見つけることはできる
質問2
一番上のところでは粒度が粗すぎて、もっと下の方を見ないといけないのでは？
→階層構造なので、下が膨大になってしまうので
それは分かるが、そういう問題に立ち向かうにはこれと戦わないといけない
→今回1、2層と広げてみた。今後も掘り下げていきたいと思っている。
どういうユーザが対象のシステムなのか？
→検索のときに自分の見たいページをうまく見つけたいというユーザ全般。
リランキングしたいんであれば、もっと最初のところから入っていかないといけないのでは？
質問3
第一階層よりも第二階層の方が粒度が上がる？パーソナルデータから出たtf-idfを使った方が良いのでは？何故ODPを使ったのかがよく分からない。
→単にカテゴリを使おうと思った。
■拡張可能関係データベース管理システムを用いたWebサービス統合
山口大学 松井さん（同姓同名が研究室にいてビビッた。。。）
・提案手法
それぞれ存在するWebサービスへのアクセスをSQLによる問い合わせを行う
DBMSに全てのアクセスを集中させる。
PHP/PLでユーザ関数を記述する
→ユーザ自身の手で作るのは負担になるし、ソフトウェアの信頼性も下がる
Pg/WAFL：ユーザ定義関数のXMLによる仕様記述
※ とりあえず帰ってくるカラム名は自力で調べる必要があるっぽい
RSSリーダとかが実装例
？？XMLデータベースを使わないのか？？
・Webサービス
HTTPを用いた情報交換によりサービス
XMLで利用（SOAPなど）
・関連研究
EaRDB：ユーア定義関数を用いてWebサービスにアクセス。ユーザ定義関数の自動生成はできない。
YahooQueryLanguage：データソースのXMLによる記述を与える。複数のWebサービスへのアクセスは不可。
質問1
PgWAFLはWPLに比べるとアプリケーションよりの技術になっているのでは？あまり手間が減らないんじゃ？
→調査不足もあってWPLなどにあわせた記述にすべきだった。
RESTを対象としているところで結構ややこしいように思える。RSSについてもベンダ独自だったり、して大混乱する。Webアプリケーションの開発では統合的な記述としては解決できてないのでは？どの辺まで解決したいの？
SOAPはXMLのフォーマットで仕様記述が完全だけど、RESTは記述に限界がある。RESTを使うなら、その辺も考えて作らないといけない。
質問2
SQLの形でアクセスしようとしている。ユーザ定義関数を作るメリットは？
質問3：XMLで表現できる情報の空間とRDBで表現できる空間って違うようね？Amazonのデータは著者が複数帰ってきてその人数は分からない。その場合ユーザ定義関数はどうかけるのか？
→対応できない。
XMLとRDBの本質的な違いになる部分をちゃんと定義できるようにしてしまわないと難しい。
質問4
認証付きサービスについては考えているの？
質問5
全検索結果からのどこからどこまで取る？
→ページ数の指定はできる
全ての検索結果をえるのに何度もリクエストをしないといけない場合もある。それは大丈夫？
→ユーザ定義処理の中に繰り返し記述をする。
===============
関連単語の抽出とODPは、結構うちの研究室でも使えそうな技術だな。
Webサービス統合は魅力的な提案ではあるけど、やっぱり難しそう。
XMLDBを使えば良いのにと簡単に考えていたけど、その後先生たちから
・XMLDBの知名度や実用性
・XMLDBの形がアプリケーション実装者にとって嬉しい形なのか
という問題が挙がった。。。確かに。
それにWebサービス統合って、結局利用するアプリケーション依存、そこで拡張が激しくなってしまいそう。認証とかセキュリティの話が入ってくると尚更。
そういやRESTメインでやってたけど、確かGoogleAppsにSOAPじゃないと取れないデータがあった気が。。。ムツカシイなぁ。
第15回WI2研究会 懇親会にて
今回の飲み会は結構色んな人と話せてよかったですー。
ただやっぱり学生の多い席が一番落ち着きました；；
市立大の人たちはブログの要約やってたり主観的情報の抽出やってたり、
結構面白そうな研究しています。
主観的情報の抽出は私も興味あるところなので、是非彼には次回WI2で講演してもらいたいですねぇｗｗ
で、途中、杉原先生と斎藤先生に実験に関する講釈を受ける機会がありました。
大変勉強になりましたが、学生の席に戻ったときに「何か口から出てる」。。。
魂っぽいものが抜け出てたみたいです。
以下、杉原先生の話を個人的にまとめたもの。
酔った頭で内容を噛み砕いたんで、若干曲解も混じってるかと。。。
========
・個人を系とした斎藤先生の実験は、文化的な違いを無視して（正確には無視できるものと蓋然性の高い仮定をして）個人の経験による差異を掘り下げたもの。
社会を系とした松田先生の日本人の謙譲に関する実験は、国籍を見て、同一国籍内の個人差には重きを置いていないもの。
自分が何を掘り下げたいのかによって、対象として選ぶ被験者が、その選定基準が代わる。
・システムの有効性をみたいときはまた別。
そのシステムがどんな機能を持つか書き出して、その有効性を発揮できる対象を選ぶべき。
誰を対象にしたシステムなのか、そのためにどの機能を用意したのか、ここがアンクリアだと不味い。とりあえず学会や論文として叩かれる。
そして、それらを確立した上で、その機能がどう対象に影響を及ぼすのかを仮定として立てる。
☆機能と被験者はセットであるべき！
う～ん、私はどういう対象を選んでいるんだろう？？
ある程度ネットリテラシーがある人、即ち経験？精神状態？提示で誘導しているのか？
ちゃんと考え直さないと。
[※ここにあったものは削除しました。色々とすみません。。。]
========
こうして話が終わる頃には、私の口からエクトプラズムが……。
ついでに杉原先生にはパワポが欲しいとお願いしてみました。
せめて、参考文献だけでも欲しいわぁ。
ただやっぱり学生の多い席が一番落ち着きました；；
市立大の人たちはブログの要約やってたり主観的情報の抽出やってたり、
結構面白そうな研究しています。
主観的情報の抽出は私も興味あるところなので、是非彼には次回WI2で講演してもらいたいですねぇｗｗ
で、途中、杉原先生と斎藤先生に実験に関する講釈を受ける機会がありました。
大変勉強になりましたが、学生の席に戻ったときに「何か口から出てる」。。。
魂っぽいものが抜け出てたみたいです。
以下、杉原先生の話を個人的にまとめたもの。
酔った頭で内容を噛み砕いたんで、若干曲解も混じってるかと。。。
========
・個人を系とした斎藤先生の実験は、文化的な違いを無視して（正確には無視できるものと蓋然性の高い仮定をして）個人の経験による差異を掘り下げたもの。
社会を系とした松田先生の日本人の謙譲に関する実験は、国籍を見て、同一国籍内の個人差には重きを置いていないもの。
自分が何を掘り下げたいのかによって、対象として選ぶ被験者が、その選定基準が代わる。
・システムの有効性をみたいときはまた別。
そのシステムがどんな機能を持つか書き出して、その有効性を発揮できる対象を選ぶべき。
誰を対象にしたシステムなのか、そのためにどの機能を用意したのか、ここがアンクリアだと不味い。とりあえず学会や論文として叩かれる。
そして、それらを確立した上で、その機能がどう対象に影響を及ぼすのかを仮定として立てる。
☆機能と被験者はセットであるべき！
う～ん、私はどういう対象を選んでいるんだろう？？
ある程度ネットリテラシーがある人、即ち経験？精神状態？提示で誘導しているのか？
ちゃんと考え直さないと。
[※ここにあったものは削除しました。色々とすみません。。。]
========
こうして話が終わる頃には、私の口からエクトプラズムが……。
ついでに杉原先生にはパワポが欲しいとお願いしてみました。
せめて、参考文献だけでも欲しいわぁ。
第15回WI2研究会 1日目チュートリアル「ユーザ評価を見つめなおす」
第15回WI2研究会 チュートリアル……。
今回私がこの研究会に参加した最大の目的がここにありました。
チュートリアルがタイトルだけとは知らなかったのでガンガンメモりました。
===========
■定量調査・実験と定性的調査の基本的な考え方
北陸先端科学技術大学 杉原先生
・ユーザ行動分析が研究テーマ
現場に行って調査分析する（定量的調査、定性的調査）
・システム開発者は評価はそんなに拘らない
←→杉原先生
システムつくりはそこそこ、評価は大好き♪
・現場にとって真なるニーズ抽出法の提案
・調査、実験、実践的調査
・調査
定量的調査
質的調査
変数を一定に出来ない部分に、学問的に重要な変数が含まれている事が多い
・実験
条件を意図的に操作
・アクションリサーチ 実践的調査
研究者が現場に関与しながら
←→事例研究とよく対比される
・調査の基本的な考え方
周到な準備をした調査・実験だけが良い結果を導く
定量的調査の目的：平均的モデルを求める 文脈は無視される事が多い 仮説検証型研究
定性的調査：文脈をくみとる 仮説生成型
・尺度の種類、性質
順序尺度を感覚尺度に近づける必要がある→そういう風に実験計画を立てる
四則演算ができるのは比率尺度だけ
順序尺度は中央値を出すか、順序として出すか。だけ
・質のデータの示し方
冗長さが意外とダイナミクスの表示に大事
・理系の実験
比較対照が必要
手順、境界条件は規定済み
結果の再現性が重要視→最終的な目的が現象の制御である
・仮説検証方研究
境界は所属分野により暗黙的に決定（境界の見極めが重要）
ノイズは第3の変数として考察の対象になる
・心理実験と社会科学系の調査
手順、境界条件試行錯誤の
比較対象があると良いけど、新規性に注意！
手順の再現性が重要で結果の再現性はない
新規性が最重要、蓋然性の高い結論が重要視→最終的な目的が現象や概念の説明
・研究に求められるもの
新規性 研究そのもの
妥当性 データ
調べたい事をきちんと図る事が出来ているかということ
内的妥当性（その分野で）、外的妥当性（一般性）、理論的妥当性（自分の仮説と理論の一致）
信頼性
再現可能性→社会研究の場合結果そのものは再現されないことも多い
代表性
適切なサンプリングを行っているか
単なる特殊例ではないか？
論理性・一貫性 研究そのもの
・理系の場合は積み上げる。社会現象は掘り下げる。
社会現象を掘り下げると実は根っこが違う事が分かる
・定量的調査と定性的調査のプロセス比較
定量的調査：仮説構成→数量的データ→数量的データの分析
定性的調査：問題を収拾と分析が同時
厳密な意味ではやり直しがきかない
・質的調査
非干渉的技法
クオリティを高めるには・・・
密な記述が必要、
ユーザ：基本的に自分の都合だけで話す
研究者：キーワード的な概念を中心にご都合主義
結果を一般適することはできない
数を増やせば良いのか？否、それは定量的調査→深さ、豊かさを記述 複雑かつダイナミックな相互作用を取り扱うために向いた
・混合研究法
定量と定性の組み合わせ
・実験・定量調査の概念
・実験のメリット
実験条件を厳密に統制可能
因果関係を説明するための状況を人為的に作る
・実験のデメリット
変数を減らすためやや不自然な状況を作らざるを得ない
・被験者内計画と被験者外計画？
全ての条件に同一の被験者を参加させる→目的がばれる
1条件あたり20人が必要と言われる
かく乱変数が多く出てくる（反復による疲労や練習効果）
→ランダマイゼイション（実験の試行順序を被験者ごとに無作為に決める）
カウンタバランス（ランダムさに偏りが表れないよう各実験条件が均質化するように）
・参考文献リスト
実践的研究の進め
データはウソをつく
質的調査法入門
ユーザのための教育・心理統計と実験計画法
・枝葉話でしたが気に入った名文
『かすかな生が圧倒的な死と対峙していると言う密度の濃さ』
■ユーザの認知プロセスに着目したWebインタラクションの分析
愛知教育大学 斎藤先生
・実験的な質的な中間を分析している
認知的な視点から、学習教育的な視点へ
・経験や課題の違いによる情報探索行動の違い
どういう風にデータを分析している？被験者をどうとらえている？
・研究目的
1.認知的アプローチによるWeb情報探索プロセスの検討
2.問題解決について、Web検索の知識や経験の違いによるパフォーマンスやプロセスの違い
・被験者の選出
Webサーチ経験の多寡を基準に被験者を捕らえる
Webコンテンツの性質を感覚的に理解している
→ちょっとこれではもやっとしているので＜汗
経験の分類指標として「日常的なWeb利用、情報収集スタイル、検索エンジンに関する知識」
点数付けをして中間層を排除（単純に2分割ではなく）してグループ間の比較をし易くした
・課題の設定
事実発見課題 パフォーマンスを0/1で判断できる
日常的な課題 被験者によって知識の差がない課題
・パフォーマンスデータ
事実発見→発見できた人数：Expert＞Novice
プロセスに関するデータ→発話プロトコル：課題遂行中に頭に浮かんだ事をすべて声に出してもらった（プロトコルアナリシス）
行動データの収集：閲覧履歴、パソコン画面
・分析の仕方
科学的発見における空間探索のモデル Two space model(Simon & Lea, 1974)
実験の統制（探索の絞込み）
仮説空間（キーワード空間）→実験空間（Web空間、検索結果、ページ）
←
実験結果のフィードバック（探索結果のフィードバック）
・モデルに基づいて分析指標を提案
空間内の探索に関する指標
空間から空間に推移していくパターンの指標
・発話プロトコル
予測に関する発話、評価に関する発話
声に出し、書き起こし、コーディング(評価、予測のタグ付け)し、信頼性の確認（評定者によるコーディングの確認、結果の確認）
・行動データの分析
ProblemBehaviorGraph（PBG）
探索スキーマ
・WebにおけるExploratorySearchの分析
・研究目的
1. ExpcloratorySearchの分析
2. 視線データ
・被験者
Expert:図書館情報学専攻の大学院生
Novice:他専攻の学部生
・課題の設定
自由度の高い情報収集課題
・パフォーマンスデータ
前の＋
課題遂行後のインタビュー
視線データ
・Webページのどこをみているか？
Webページの何処を見ているか？
装置さえよければ取れる
！Webページの何を見ているか？
ページの位置≠特定の内容→コーディングでカバー
？？スクロールしちゃいけないねぇ
・相補的なデータの分析
行動データ
ブラウザログ
画面キャプチャ
視線データ
↓仮説をあてて、検証
発話プロトコル
課題遂行中・後
・レポート作成はサブタスクに分けにくい
インタビューデータの分析
→レポートに対する戦略の違い
・院生：参考文献リスト
・学部生：Webページをそのまま使おうとしている
・利用者の特性を要因とする場合
☆特性の定義やレベル分けの基準を客観的に分かるようにする→できるだけ量的な指標で基準の違いを示す
Moore(2007) SearchExperience研究のメタ分析
・課題の設定
Simulated Task：被験者間の比較が厳密
Open Ended Task：被験者の興味を反映したリアルな行動、難易度・情報量の統制が困難
どちらを選ぶかは自分が何を見たいかに関ってくるなぁ。。。ってことで。
■ゲーム理論的方法論に基づきユーザ特性を理解するための社会的心理学実験
NTTコミュニケーション科学基礎研究所 松田さん
・学生時代：社会心理学
・実験に対する熱い思いを買われ、杉原先生に呼ばれてきた。
●人間モデル
どんな結果が得られても「こうなりました」って書けばいいんでしょ？
→松田さん「このヤロー」
一回目の発表、中島さんのさんの67％って良い数字？多分良い。比較対照があればOKだったんじゃない？
・性に関する実験
1.男性が女性のイラストの魅力を評定
→ウエストとヒップの比が0.7がもっとも好まれる
2.嫉妬の性差
→男性：女性の肉体的な浮気を許せない
→女性：男性の精神的な浮気を許せない
人間モデルに照らすと明らかになる
1は子孫繁栄のため：ウェストが細いと妊娠してない→女性に対する魅力。
2も。女性は妊娠してしまうと自由に動けなくなる→父親への信頼度が重要。
・4枚カード問題
一方がひらがななら、他方は偶数でないといけない
「1」 「4」 「あ」 「イ」
対偶を利用した良い問題 → 「一方が奇数なら、他方はカタカナでないといけない」
両方カタカナだったり、両方偶数であるのはOKってことだよ！
●人を使う実験がめちゃめちゃになる理由
人はウソをつく。悪意のない嘘。
特に日本人は「謙譲」を美徳する民族なので。
ある問題をとかせる。
理論的には平均より上か下か？
何も無いと→「平均より下ですよー」が69.2%
金がかかると（予測が正解していたら100円上げます）→「平均より下ですよー」が23.2%。。。ｵｰｲ
・研究者倫理の問題
都合の良い評価実験データが得られる状況はデータの捏造と紙一重。
将来の研究者に負の遺産を残してはならない。
・実験者と参加者の間の相互作用
ギヤク効果（無自覚）→参加者が信じきり、効果が表れてしまう。。。
ピグマリオン効果→出切るというと伸びる
要求特性（自覚）→仮説を予測し、それに基づいて行動する
＊別の目的を装う＝質問紙にもあえて多様な質問項目を列挙する
＊意図的に操作できない測定法
評価懸念→知的能力・常識が試されていると懸念し、行動が変化
知人や指導学生を参加者にするとき、特に注意が必要
実験者効果→無自覚に実験者が参加者の行動を誘導してしまう
二重盲検方
・Deception（騙し）の人権倫理問題
インフォームドコンセプトに反する重大問題かも
論文では倫理委員会によるチェックが必要だったりする。。。
・参考文献
心理学研究法 高野
■フィールドマイニングの試み
大阪大学 松村先生
・もとはAI、コミュニケーション方面のひと
→分析の対象ブログ、2chもした。。。
→データマイニングの限界はどこだ？データありきの学問だよなぁ
→物理空間、フィールドを対象としたデータ分析
人間が気付くようなきっかけの方法論
行動を変化させるちょっとした工夫
・男子便器の目標→年間のトイレ掃除代が一億円くらい浮いたらしい
・ゴミ箱の口
・公演のベンチの真ん中に手すり→ホームレスが寝なくなる
・車道の絵→車の速度を下げる
・高速道の段々狭まっていく点々→車の速度を下げる
身近な道具もキッカケになる
・カメラ→撮れるものがないかと色々見るようになる
・ベビーカー→地面の段差に敏感になる
生活空間は見ているのに見ていない、聞こえているのに聞いていないことに溢れている
フィールドマイニングは人とモノと環境との関係を再構築する
→フィールドの変化がどう人の行動に変化を及ぼすか
・石橋らくがきマップ
全年齢を対象にしようと思うとオフラインな仕組みに
・外でランチ
実験をやったのが11月だったので、実用的ではなかったが外に関心は向けられた
・阪大坂を使った実験
福男
地元が炊き出ししてイベント化
次年度からは地元と市から予算が着くようになったらしい
・イメージマップを用いた
石橋という駅をもつ町のイメージ
子供がかなり集まったらしい
・ムーバブルチェア
動かせる椅子を放置して、利用の様子を観察
年齢などによって座る位置が変化した
・音を使った実験
音を聞かせてどこでやってる音かを当てさせる
・お店の落書き帳
ラン検定（連続性の検定）
■質問
to松村先生：フィールドマイニングのマイニングってどこにかかってるの？
最初は環境にいろいろセンサを取り付けるつもりだったのでこういう名前に。。。
フィールドマイニングの本来の語義は「穴をほること」です。
to松田さん：被験者を疑い出すとゴールが見えない。どこまでやれば良いかというラインはある？
出せない。結局それはみなが試行錯誤して続けていくしかない。
情報系の人がやってる実験は低い所で止まっているのではないか？
実験者効果がとくにでかいのでは？
変な基準で図ったデータが将来の人にリファらされると怖い。
to松村さん：ノーマンの行ってる認知系からプロダクトのデザインに行く。デザインの話なんだろう、それは工学者が必要とされるものだ。情報工学研究者として＋な部分、マイナスな部分を教えてほしい。
認められない。。。研究としての分野が難しい。投稿先や評価基準が分からない。もう趣味です。
to斎藤先生：エキスパートとNoviceの切り分けは統計的に見ればセーフ？
本当は指標がほしい
to皆さん：質問はない ヒューマンインタフェースの本場の学会ではチュートリアルが多い、ユーザ評価どうするか？
研究テーマになりそうな素材をなげて、評価もする
to斎藤先生：視線のデータをどう料理している？眼球運動のどういう特性を使っている。
視線データ、注視点、停留点
to斉藤先生：視線についてのデータをとるにはどのくらい勉強しないといけない？
眼球運動のデータを使って研究を行っていた人と一緒にやっている。
to杉原先生：明確な因果関係の把握は難しく、類推でしかないのでは？
質的な調査と量的な調査を組み合わせるべき→少ないデータでは因果関係をいえない
to松田さん：極度に被験者実験の条件を拘束すると、工学と実験のミッシングリングを埋められなくなるのでは？
ユーザ評価をやっつけでするなら、やらない方がいいじゃん
何でユーザ評価しないといけないのか。
===========
杉原先生の発表速過ぎ。。。
ほとんどメモれんかった。。。パワポが欲しいよ～っ(>_<)
斎藤先生の話はかなり具体的。
一通りの手順が明らかなので、参考にしたいと思います。
松田さんはとにかく面白い！しばらく研究室でネタにできそうｗｗ
あと二重盲検法について調べとこ。
松村さんの話は何か今年のMYCOMで聞いた気がするんだけど。。。後で飲み会で確認したら来てないそうなので、多分別の機会だったのかなぁ？うーん。。。
ちなみに質問を1回するという目標は達成できず。
レベル高すぎました；；
今回私がこの研究会に参加した最大の目的がここにありました。
チュートリアルがタイトルだけとは知らなかったのでガンガンメモりました。
===========
■定量調査・実験と定性的調査の基本的な考え方
北陸先端科学技術大学 杉原先生
・ユーザ行動分析が研究テーマ
現場に行って調査分析する（定量的調査、定性的調査）
・システム開発者は評価はそんなに拘らない
←→杉原先生
システムつくりはそこそこ、評価は大好き♪
・現場にとって真なるニーズ抽出法の提案
・調査、実験、実践的調査
・調査
定量的調査
質的調査
変数を一定に出来ない部分に、学問的に重要な変数が含まれている事が多い
・実験
条件を意図的に操作
・アクションリサーチ 実践的調査
研究者が現場に関与しながら
←→事例研究とよく対比される
・調査の基本的な考え方
周到な準備をした調査・実験だけが良い結果を導く
定量的調査の目的：平均的モデルを求める 文脈は無視される事が多い 仮説検証型研究
定性的調査：文脈をくみとる 仮説生成型
・尺度の種類、性質
順序尺度を感覚尺度に近づける必要がある→そういう風に実験計画を立てる
四則演算ができるのは比率尺度だけ
順序尺度は中央値を出すか、順序として出すか。だけ
・質のデータの示し方
冗長さが意外とダイナミクスの表示に大事
・理系の実験
比較対照が必要
手順、境界条件は規定済み
結果の再現性が重要視→最終的な目的が現象の制御である
・仮説検証方研究
境界は所属分野により暗黙的に決定（境界の見極めが重要）
ノイズは第3の変数として考察の対象になる
・心理実験と社会科学系の調査
手順、境界条件試行錯誤の
比較対象があると良いけど、新規性に注意！
手順の再現性が重要で結果の再現性はない
新規性が最重要、蓋然性の高い結論が重要視→最終的な目的が現象や概念の説明
・研究に求められるもの
新規性 研究そのもの
妥当性 データ
調べたい事をきちんと図る事が出来ているかということ
内的妥当性（その分野で）、外的妥当性（一般性）、理論的妥当性（自分の仮説と理論の一致）
信頼性
再現可能性→社会研究の場合結果そのものは再現されないことも多い
代表性
適切なサンプリングを行っているか
単なる特殊例ではないか？
論理性・一貫性 研究そのもの
・理系の場合は積み上げる。社会現象は掘り下げる。
社会現象を掘り下げると実は根っこが違う事が分かる
・定量的調査と定性的調査のプロセス比較
定量的調査：仮説構成→数量的データ→数量的データの分析
定性的調査：問題を収拾と分析が同時
厳密な意味ではやり直しがきかない
・質的調査
非干渉的技法
クオリティを高めるには・・・
密な記述が必要、
ユーザ：基本的に自分の都合だけで話す
研究者：キーワード的な概念を中心にご都合主義
結果を一般適することはできない
数を増やせば良いのか？否、それは定量的調査→深さ、豊かさを記述 複雑かつダイナミックな相互作用を取り扱うために向いた
・混合研究法
定量と定性の組み合わせ
・実験・定量調査の概念
・実験のメリット
実験条件を厳密に統制可能
因果関係を説明するための状況を人為的に作る
・実験のデメリット
変数を減らすためやや不自然な状況を作らざるを得ない
・被験者内計画と被験者外計画？
全ての条件に同一の被験者を参加させる→目的がばれる
1条件あたり20人が必要と言われる
かく乱変数が多く出てくる（反復による疲労や練習効果）
→ランダマイゼイション（実験の試行順序を被験者ごとに無作為に決める）
カウンタバランス（ランダムさに偏りが表れないよう各実験条件が均質化するように）
・参考文献リスト
実践的研究の進め
データはウソをつく
質的調査法入門
ユーザのための教育・心理統計と実験計画法
・枝葉話でしたが気に入った名文
『かすかな生が圧倒的な死と対峙していると言う密度の濃さ』
■ユーザの認知プロセスに着目したWebインタラクションの分析
愛知教育大学 斎藤先生
・実験的な質的な中間を分析している
認知的な視点から、学習教育的な視点へ
・経験や課題の違いによる情報探索行動の違い
どういう風にデータを分析している？被験者をどうとらえている？
・研究目的
1.認知的アプローチによるWeb情報探索プロセスの検討
2.問題解決について、Web検索の知識や経験の違いによるパフォーマンスやプロセスの違い
・被験者の選出
Webサーチ経験の多寡を基準に被験者を捕らえる
Webコンテンツの性質を感覚的に理解している
→ちょっとこれではもやっとしているので＜汗
経験の分類指標として「日常的なWeb利用、情報収集スタイル、検索エンジンに関する知識」
点数付けをして中間層を排除（単純に2分割ではなく）してグループ間の比較をし易くした
・課題の設定
事実発見課題 パフォーマンスを0/1で判断できる
日常的な課題 被験者によって知識の差がない課題
・パフォーマンスデータ
事実発見→発見できた人数：Expert＞Novice
プロセスに関するデータ→発話プロトコル：課題遂行中に頭に浮かんだ事をすべて声に出してもらった（プロトコルアナリシス）
行動データの収集：閲覧履歴、パソコン画面
・分析の仕方
科学的発見における空間探索のモデル Two space model(Simon & Lea, 1974)
実験の統制（探索の絞込み）
仮説空間（キーワード空間）→実験空間（Web空間、検索結果、ページ）
←
実験結果のフィードバック（探索結果のフィードバック）
・モデルに基づいて分析指標を提案
空間内の探索に関する指標
空間から空間に推移していくパターンの指標
・発話プロトコル
予測に関する発話、評価に関する発話
声に出し、書き起こし、コーディング(評価、予測のタグ付け)し、信頼性の確認（評定者によるコーディングの確認、結果の確認）
・行動データの分析
ProblemBehaviorGraph（PBG）
探索スキーマ
・WebにおけるExploratorySearchの分析
・研究目的
1. ExpcloratorySearchの分析
2. 視線データ
・被験者
Expert:図書館情報学専攻の大学院生
Novice:他専攻の学部生
・課題の設定
自由度の高い情報収集課題
・パフォーマンスデータ
前の＋
課題遂行後のインタビュー
視線データ
・Webページのどこをみているか？
Webページの何処を見ているか？
装置さえよければ取れる
！Webページの何を見ているか？
ページの位置≠特定の内容→コーディングでカバー
？？スクロールしちゃいけないねぇ
・相補的なデータの分析
行動データ
ブラウザログ
画面キャプチャ
視線データ
↓仮説をあてて、検証
発話プロトコル
課題遂行中・後
・レポート作成はサブタスクに分けにくい
インタビューデータの分析
→レポートに対する戦略の違い
・院生：参考文献リスト
・学部生：Webページをそのまま使おうとしている
・利用者の特性を要因とする場合
☆特性の定義やレベル分けの基準を客観的に分かるようにする→できるだけ量的な指標で基準の違いを示す
Moore(2007) SearchExperience研究のメタ分析
・課題の設定
Simulated Task：被験者間の比較が厳密
Open Ended Task：被験者の興味を反映したリアルな行動、難易度・情報量の統制が困難
どちらを選ぶかは自分が何を見たいかに関ってくるなぁ。。。ってことで。
■ゲーム理論的方法論に基づきユーザ特性を理解するための社会的心理学実験
NTTコミュニケーション科学基礎研究所 松田さん
・学生時代：社会心理学
・実験に対する熱い思いを買われ、杉原先生に呼ばれてきた。
●人間モデル
どんな結果が得られても「こうなりました」って書けばいいんでしょ？
→松田さん「このヤロー」
一回目の発表、中島さんのさんの67％って良い数字？多分良い。比較対照があればOKだったんじゃない？
・性に関する実験
1.男性が女性のイラストの魅力を評定
→ウエストとヒップの比が0.7がもっとも好まれる
2.嫉妬の性差
→男性：女性の肉体的な浮気を許せない
→女性：男性の精神的な浮気を許せない
人間モデルに照らすと明らかになる
1は子孫繁栄のため：ウェストが細いと妊娠してない→女性に対する魅力。
2も。女性は妊娠してしまうと自由に動けなくなる→父親への信頼度が重要。
・4枚カード問題
一方がひらがななら、他方は偶数でないといけない
「1」 「4」 「あ」 「イ」
対偶を利用した良い問題 → 「一方が奇数なら、他方はカタカナでないといけない」
両方カタカナだったり、両方偶数であるのはOKってことだよ！
●人を使う実験がめちゃめちゃになる理由
人はウソをつく。悪意のない嘘。
特に日本人は「謙譲」を美徳する民族なので。
ある問題をとかせる。
理論的には平均より上か下か？
何も無いと→「平均より下ですよー」が69.2%
金がかかると（予測が正解していたら100円上げます）→「平均より下ですよー」が23.2%。。。ｵｰｲ
・研究者倫理の問題
都合の良い評価実験データが得られる状況はデータの捏造と紙一重。
将来の研究者に負の遺産を残してはならない。
・実験者と参加者の間の相互作用
ギヤク効果（無自覚）→参加者が信じきり、効果が表れてしまう。。。
ピグマリオン効果→出切るというと伸びる
要求特性（自覚）→仮説を予測し、それに基づいて行動する
＊別の目的を装う＝質問紙にもあえて多様な質問項目を列挙する
＊意図的に操作できない測定法
評価懸念→知的能力・常識が試されていると懸念し、行動が変化
知人や指導学生を参加者にするとき、特に注意が必要
実験者効果→無自覚に実験者が参加者の行動を誘導してしまう
二重盲検方
・Deception（騙し）の人権倫理問題
インフォームドコンセプトに反する重大問題かも
論文では倫理委員会によるチェックが必要だったりする。。。
・参考文献
心理学研究法 高野
■フィールドマイニングの試み
大阪大学 松村先生
・もとはAI、コミュニケーション方面のひと
→分析の対象ブログ、2chもした。。。
→データマイニングの限界はどこだ？データありきの学問だよなぁ
→物理空間、フィールドを対象としたデータ分析
人間が気付くようなきっかけの方法論
行動を変化させるちょっとした工夫
・男子便器の目標→年間のトイレ掃除代が一億円くらい浮いたらしい
・ゴミ箱の口
・公演のベンチの真ん中に手すり→ホームレスが寝なくなる
・車道の絵→車の速度を下げる
・高速道の段々狭まっていく点々→車の速度を下げる
身近な道具もキッカケになる
・カメラ→撮れるものがないかと色々見るようになる
・ベビーカー→地面の段差に敏感になる
生活空間は見ているのに見ていない、聞こえているのに聞いていないことに溢れている
フィールドマイニングは人とモノと環境との関係を再構築する
→フィールドの変化がどう人の行動に変化を及ぼすか
・石橋らくがきマップ
全年齢を対象にしようと思うとオフラインな仕組みに
・外でランチ
実験をやったのが11月だったので、実用的ではなかったが外に関心は向けられた
・阪大坂を使った実験
福男
地元が炊き出ししてイベント化
次年度からは地元と市から予算が着くようになったらしい
・イメージマップを用いた
石橋という駅をもつ町のイメージ
子供がかなり集まったらしい
・ムーバブルチェア
動かせる椅子を放置して、利用の様子を観察
年齢などによって座る位置が変化した
・音を使った実験
音を聞かせてどこでやってる音かを当てさせる
・お店の落書き帳
ラン検定（連続性の検定）
■質問
to松村先生：フィールドマイニングのマイニングってどこにかかってるの？
最初は環境にいろいろセンサを取り付けるつもりだったのでこういう名前に。。。
フィールドマイニングの本来の語義は「穴をほること」です。
to松田さん：被験者を疑い出すとゴールが見えない。どこまでやれば良いかというラインはある？
出せない。結局それはみなが試行錯誤して続けていくしかない。
情報系の人がやってる実験は低い所で止まっているのではないか？
実験者効果がとくにでかいのでは？
変な基準で図ったデータが将来の人にリファらされると怖い。
to松村さん：ノーマンの行ってる認知系からプロダクトのデザインに行く。デザインの話なんだろう、それは工学者が必要とされるものだ。情報工学研究者として＋な部分、マイナスな部分を教えてほしい。
認められない。。。研究としての分野が難しい。投稿先や評価基準が分からない。もう趣味です。
to斎藤先生：エキスパートとNoviceの切り分けは統計的に見ればセーフ？
本当は指標がほしい
to皆さん：質問はない ヒューマンインタフェースの本場の学会ではチュートリアルが多い、ユーザ評価どうするか？
研究テーマになりそうな素材をなげて、評価もする
to斎藤先生：視線のデータをどう料理している？眼球運動のどういう特性を使っている。
視線データ、注視点、停留点
to斉藤先生：視線についてのデータをとるにはどのくらい勉強しないといけない？
眼球運動のデータを使って研究を行っていた人と一緒にやっている。
to杉原先生：明確な因果関係の把握は難しく、類推でしかないのでは？
質的な調査と量的な調査を組み合わせるべき→少ないデータでは因果関係をいえない
to松田さん：極度に被験者実験の条件を拘束すると、工学と実験のミッシングリングを埋められなくなるのでは？
ユーザ評価をやっつけでするなら、やらない方がいいじゃん
何でユーザ評価しないといけないのか。
===========
杉原先生の発表速過ぎ。。。
ほとんどメモれんかった。。。パワポが欲しいよ～っ(>_<)
斎藤先生の話はかなり具体的。
一通りの手順が明らかなので、参考にしたいと思います。
松田さんはとにかく面白い！しばらく研究室でネタにできそうｗｗ
あと二重盲検法について調べとこ。
松村さんの話は何か今年のMYCOMで聞いた気がするんだけど。。。後で飲み会で確認したら来てないそうなので、多分別の機会だったのかなぁ？うーん。。。
ちなみに質問を1回するという目標は達成できず。
レベル高すぎました；；
第15回WI2研究会 1日目第1セッション「情報抽出・分析」
7月4日、5日と広島市立大学で開かれた第15回Webインテリジェンスとインタラクション(SIG-WI2 ｼｸﾞｳｨｯﾂ) に参加してきました。
うちの大学も相当ド田舎にありますが、こちらもなかなか野趣に溢れておりました（失礼）
緑が多くて、ところどころに美術系の学生が作ったモニュメント（スターゲートみたいな）があって結構楽しかったです。
ただ、土日ということで学食・購買が一切空いていないのには閉口しましたが。。。
大学前のパン屋が2日前にオープンしてなければ、完全に昼食を食いっぱぐれるところでした。
会場は写真左手の小ホールでありました。
学生で聴講のみなので参加費はタダ♪
Proceedingと懇親会費だけ払ってきました。
うちの認知系のボスがProceedingを楽しみにしているようなので、ここで第一目的はクリアしました。
……まさかチュートリアルがタイトルだけとは思いませんでしたが；；
以下、午前のセッション「情報抽出・分析」のメモです。
個人的解釈、私的推測入り乱れてます。
「？？」は私が疑問に思った部分です。
==============
■ブログにおける話題語の出現理由の抽出と話題に関する詳細記事推薦
発表者：早稲田大学 中島さん
・話題語：ブログ上で一時的に急増した語
背景知識がないと何故その話題語が急増したのか分からない
→6つの情報：話題理由、意味、中心人物、場所、時間、情報源を抽出する
※ 多分、この6つを対象とした根拠は6W1H
・提案手法
（人物、場所、時間、手段）→（理由）→（詳細記事）の順序で抽出
1.まずWikipediaで定義文（「●●とは××である」）を獲得する
2.ブログ記事のフィルタリング→話題語を含む記事全て
3.除去する記事：話題語ばかりを含むスパム的記事があるので除去する→話題語の関連語をどの程度含むかを見る
4.記事本体の形態素解析→地域、人名、数タグをつける
5.並んだ名詞を連結させる。連結した語には元のタグを継承させる
6.タグを改めて人物、場所毎に抽出→最も出現数の高い語を抽出
？？日時と状況が必ずしも一致しないのでは？？
7.話題語を含む、中心人物、場所、時間、情報源を多く含む1文を抽出
8.記事を推薦
・評価実験
・ウィキペディアの話題語に対する網羅性：話題語に関する記事がウィキペディアに存在するか
45語を対象に調査→53％くらい網羅
・ウィキペディアから抽出された意味の評価
人手で評価した結果→90％以上が一致
・話題語の抽出情報と推薦記事の一致について
中心人物、話題理由、推薦記事（複数の要素による判断）は精度が高かった
場所（人名が場所と判断されてしまった）、時間（テレビ番組から書いてる人が多い）の精度は低かった
Googleブログでは詳細に書かれたブログ記事が存在しない場合も合った
アニメやドラマの場合、特殊な語が多かった
・関連研究（話題語に関する研究）
・ブログの係り受け：慶応大学の数原先生
・Yahoo!Japanブログ検索
[質問1]
ブログ記事よりもニュースを見せた方が良いような気がする
→テレビ番組や、うどんの日とかニュースにならない話題語もある。
ハニカミ王子とかそういうのをフォーカスした方が良い
[質問2]
時間についてブログエントリーの日付と、「今日」、「昨日」の単語の組み合わせの方が良いのでは？
→まだ実装できていない
話題語はブログによって増幅されたマスコミ報道になるのでは？
→ニュース記事にならない報道もある
[質問3]
この区分はかなりナイーブなものになるのでは？中心人物、場所と組織の違いはどうやって？（例：広島市立大学は組織？場所？）
→中心人物の場合、人名しかとっていない
[質問4]
現実の推薦では話題語としてアップされると、それにアクセスする人が増えて過剰に話題語の推薦順位があがる。
→自動的に時間で区切って、関連語による検索の重み付けを行う
話題語以外の語を使うと、その人の興味でひくとどうなるのか？
[質問5]
式の重み付けの手法について
→実験結果によって適切な値を決めた
■ブロガーの体験熟知度に基づくブログランキングシステム
京都産業大学 中島さん（前の発表者と同じ！）
・ブログの検索やランキングに対する要求の増大
ブログとWebページは違う。ブログは投稿直後は外部からのリンクが存在しない。Googleの検索方式だとこれを見つけるのは難しい。
・従来手法
ブログエントリに対するランキング：新着順やキーワード
ブログサイトに対するランキング：リンク数、アクセス数、投票数によるランキング
→目的トピックに関する最新エントリが存在するとは限らない
？？ブログサイトの知名度は低いが隠れた名文を探したいのか？→名文サイトは必然的に高いランキングを持つ気がするのだが？？
？？投稿数と投稿内容のレベルに相関性があるのか？あれば分野別にランキングを作った方が早いのでは？？
・提案手法のコンセプト
☆熟知度が高いブロガーが書いた記事は素人が書いた記事よりも価値が高い
中身よりも情報の発信者に対する権威が、エントリの信頼度を保証するのでは？
→対象トピックに関して詳しく書かれたエントリを数多く投稿したブロガーは熟知度が高い
・提案手法
1.熟知領域リストの作成
「ファン、マニア、フリーク」で検索してこれらの検索後の直前の語句のうち、出現頻度が高いものを辞書に登録
→500領域
独自開発した生活体験シソーラス(LETS)を用いて、そのカテゴリを熟知領域リストとして採用
→14000領域
熟知語そのものではなく、「赤ちゃん」にたいして「離乳食」「おむつ」といった関連語による重み付けも必要！
2.ブロガーの熟知度スコアの算出
熟知語と関連語と共起語数を用いて算出
スパム対策もしている
3.ブログランキングの算出
熟知語をリスト化→この熟知語リストからクリックすると、その側面からみたその熟知語を扱うブログが見れる
熟知ブロガーを熟知度に基づいてランキング
・ニュアンス比較について
ニュアンス（清清しい、感動、可愛い、怒り、恐怖など）とその関連語からブログ記事のニュアンスを判定
全ブロガーと熟知ブロガーのある語に対する感情の主成分を解析
・効果
ある検索ワードに関する結果だけでなく、関連ワードもリストアップするので、その関連ワードに依存した立場による記事が見れる
ニュアンス比較によりどういう感情をもってブログを書いているのかが分かる
・実験システムに関するデータ
ブロガー 70000以上
エントリ 140000以上
20個のキーワードに対して、熟知ブロガーとして妥当か判定91％
エントリは67％
学生は20人
・今後は信頼性の高さを提示できるようにしたい
・生活体験シソーラス
ブログやニュースなどの実テキストにしばしば表現される生活体験を体系的に整理・分類したシソーラス
概念の変化について扱う（移籍した野球選手etc）
自動的カテゴリ辞書管理システム：連想辞書の自動生成
成分解析エンジン：任意の入力テキストを分類するグラデーション・エンジン。広告や商品のレコメンデーションに応用している。
[質問1]
ブロガーの熟知度とエントリの妥当性の評価が分かれたのは何故？
[質問2]
頻繁にエントリを出しているブログでも内容がやばい場合もある
→フィルタリング、熟知ブロガー同士のリンク関係などを利用してうまく排除したい。
[質問3]
LETSはどうやって作る？
→候補は機械的に、最後の決定は人手である
ブログの信頼性の指標はすでにあるのでは？それと関連させることは考えていない？
→普段は違う意見のグループが、あるテーマについては合意が取れた場合、そのエントリは信頼性が高い。そういうところをみたい。
■キーワードの時系列データにもとづくブログ、ニュース、スパムの解析
島根県立大学 石田先生
・事項相関に基づきキーワード出現頻度の基本周期系列を抽出するアルゴリズム
・分析データ
実験データの取得期間：2008年1月1日から2009年5月15日
ブログ、ニュース、スパム
毎日ランキング上500をとり、出る単語を解析
それぞれの単語について各日に登場した回数の配列を求め、自己相関を求める
・自己相関の隣接差分積
時系列データの自己相関の局所的ピークを検出
・情報源に対する比較（定量的分析）
7日周期が多い
・ブログ：7日比べて14、21日周期も多い（月末、週一のテレビ番組）
長い場合は365日
・スパム：短い周期の頻度、スパマーが短い周期で類似文章を投稿
2日周期が多い
・ニュース：基本周期に沿っている
7日が突出している
・定性的分析
・週間キーワード（基本7、たまにずれる）
出現頻度リストについてブログは鋭く、スパムは平坦
・完全週間キーワード
？？休講ワードが出てきた？？これって完全週間なの？？
・週間ブログキーワード（特徴的なキーワードを適当に選定）
週末の運動に関するキーワードが多かった。
・年間キーワード（365日を周期としている）
[質問1]
自己相関とはどうやって求めているのか？
→単語の出現頻度を毎日だす（日数分の配列を用意して、それぞれにその日のその単語の出現頻度を入れる）。それに共分散を算出
どういうアプリケーションに応用したいのか？
→広告などのマーケティングに利用
[質問2]
がちがちなアルゴリズムになってないか？
→緩くしてしまうと、解釈が難しいデータになってしまった。
[質問3]
結果がある程度自明になってはないか？周期性が見つけられて、そこに何かがあるのが分かったら良いんだけど。そこらへんからどうやって人の活動を見出したいの？
→今後分析していきたい
[質問4]
フーリエ変換を使おうと思わなかったのか？
→自己相関を使う事を決めていた
スパムブログフィルタに使えないか？
→使える
■旅行ブログからの観光情報の自動抽出
広島市立大学大学院 石野さん（えらい美人！声もきれい！うぐいす嬢かと思った！！）
・2007年観光立国推進基本法が成立
データベースはあるが、人手で集めているので大変
→ブログから自動的に観光情報を抽出
網羅性、最新性、ブログ著者の属性からユーザに適した観光情報
・提案手法
1.旅行ブログの検出
旅行ブログの例：観光情報が含まれているかで判定
観光：余暇時間の中で、日常生活圏を離れて行う様々な活動であり、ふれあい、学び、遊ぶ事を目的とするもの
複数エントリにまたがる旅行エントリは、中日が検出できない。。。（最初の日と最後の日しか旅行とかかない）
→系列ラベリング問題として扱う
機械学習としてCRFを利用
2.旅行ブログからの観光情報抽出
地域名と土産者の対の抽出 Google7-gram？？（これがないと余計な文章を抽出してしまう）
→旅行ブログに含まれる地域名と土産物の両方を持っている文を抽出
→新たな土産物の対を抽出
・実験 検出編
まずYahoo!ブログから観光、旅行という単語を含むエントリを抽出
再現率は低かったが、精度が高かった。→ブログ数を増やすことで解決できる
再現率＝複数エントリに渡る旅行記の一部の場合、検出できない場合もある（こういう漏れのなさが再現率）
記載内容が少なくても難しい
検出誤り＝旅行ブログでないのに、旅行ブログとしてみてしまう
エントリの前後に旅行ブログがあったりする
地元紹介のエントリ？？これは取れても良いのでは？（地元の判別さえできればOK）
他人の旅行を紹介しているエントリ
・実験 観光情報の自動抽出
それぞれ任意に80000文を抽出
旅行ブログ
一般ブログ
一般ウェブ
[質問1]
土産ものと場所の対だけでなく、景色とかを扱う場合は、このままの手法で使えるか？
→有効であるものとないものに分けられる。食事をメインに扱いたい。
公共機関ではなく、ブログからの抽出の意義は？
→ユーザの主観的な感想が見たい。
踏み込んだ事が書いたブログじゃないと抽出する意味が無い。そこらへんまでやってるのか？
→（なんば先生）ブログ先生から抜く意義はパーソナライズにある。ブログを書いている著者のパーソナルデータから、さらにリコメンドできたら嬉しい。
[質問2]
旅行ブログでないと判定したものの中の地元紹介は何でだめなのか？ニッチな観光情報として使えるのでは？
→今回の目的には沿ってなかっただけ。
この手のブログはすっごいスパムが多い。。。偽情報とかはどう判別しているのか？
→今後。
？？ブログエントリにタグってついてないのかなぁ、それ利用できないのかなぁ？？
==============
ここまでが第一セッション。
目標である「１セッションにつき１回は絶対に質問する」はクリア☆
やっぱりWebマイニングの世界はテキストベースが多いんだなと改めて実感しました。
ブロガーの体験熟知度についてははうちの研究室で、pdfの推薦を考えている同期の研究の参考にもなりそうです。
生活体験シソーラスLETSはちょっと欲しい。。。
最後の旅行ブログの質問2について、彼女と同じ研究室の院生が、ブログからの主観的データの抽出を行っているそうなので、それと組み合わせると結構良い感じになりそうです。
10月のWI2でそっちの発表も聞けたら良いなぁ☆
うちの大学も相当ド田舎にありますが、こちらもなかなか野趣に溢れておりました（失礼）
緑が多くて、ところどころに美術系の学生が作ったモニュメント（スターゲートみたいな）があって結構楽しかったです。
ただ、土日ということで学食・購買が一切空いていないのには閉口しましたが。。。
大学前のパン屋が2日前にオープンしてなければ、完全に昼食を食いっぱぐれるところでした。
会場は写真左手の小ホールでありました。
学生で聴講のみなので参加費はタダ♪
Proceedingと懇親会費だけ払ってきました。
うちの認知系のボスがProceedingを楽しみにしているようなので、ここで第一目的はクリアしました。
……まさかチュートリアルがタイトルだけとは思いませんでしたが；；
以下、午前のセッション「情報抽出・分析」のメモです。
個人的解釈、私的推測入り乱れてます。
「？？」は私が疑問に思った部分です。
==============
■ブログにおける話題語の出現理由の抽出と話題に関する詳細記事推薦
発表者：早稲田大学 中島さん
・話題語：ブログ上で一時的に急増した語
背景知識がないと何故その話題語が急増したのか分からない
→6つの情報：話題理由、意味、中心人物、場所、時間、情報源を抽出する
※ 多分、この6つを対象とした根拠は6W1H
・提案手法
（人物、場所、時間、手段）→（理由）→（詳細記事）の順序で抽出
1.まずWikipediaで定義文（「●●とは××である」）を獲得する
2.ブログ記事のフィルタリング→話題語を含む記事全て
3.除去する記事：話題語ばかりを含むスパム的記事があるので除去する→話題語の関連語をどの程度含むかを見る
4.記事本体の形態素解析→地域、人名、数タグをつける
5.並んだ名詞を連結させる。連結した語には元のタグを継承させる
6.タグを改めて人物、場所毎に抽出→最も出現数の高い語を抽出
？？日時と状況が必ずしも一致しないのでは？？
7.話題語を含む、中心人物、場所、時間、情報源を多く含む1文を抽出
8.記事を推薦
・評価実験
・ウィキペディアの話題語に対する網羅性：話題語に関する記事がウィキペディアに存在するか
45語を対象に調査→53％くらい網羅
・ウィキペディアから抽出された意味の評価
人手で評価した結果→90％以上が一致
・話題語の抽出情報と推薦記事の一致について
中心人物、話題理由、推薦記事（複数の要素による判断）は精度が高かった
場所（人名が場所と判断されてしまった）、時間（テレビ番組から書いてる人が多い）の精度は低かった
Googleブログでは詳細に書かれたブログ記事が存在しない場合も合った
アニメやドラマの場合、特殊な語が多かった
・関連研究（話題語に関する研究）
・ブログの係り受け：慶応大学の数原先生
・Yahoo!Japanブログ検索
[質問1]
ブログ記事よりもニュースを見せた方が良いような気がする
→テレビ番組や、うどんの日とかニュースにならない話題語もある。
ハニカミ王子とかそういうのをフォーカスした方が良い
[質問2]
時間についてブログエントリーの日付と、「今日」、「昨日」の単語の組み合わせの方が良いのでは？
→まだ実装できていない
話題語はブログによって増幅されたマスコミ報道になるのでは？
→ニュース記事にならない報道もある
[質問3]
この区分はかなりナイーブなものになるのでは？中心人物、場所と組織の違いはどうやって？（例：広島市立大学は組織？場所？）
→中心人物の場合、人名しかとっていない
[質問4]
現実の推薦では話題語としてアップされると、それにアクセスする人が増えて過剰に話題語の推薦順位があがる。
→自動的に時間で区切って、関連語による検索の重み付けを行う
話題語以外の語を使うと、その人の興味でひくとどうなるのか？
[質問5]
式の重み付けの手法について
→実験結果によって適切な値を決めた
■ブロガーの体験熟知度に基づくブログランキングシステム
京都産業大学 中島さん（前の発表者と同じ！）
・ブログの検索やランキングに対する要求の増大
ブログとWebページは違う。ブログは投稿直後は外部からのリンクが存在しない。Googleの検索方式だとこれを見つけるのは難しい。
・従来手法
ブログエントリに対するランキング：新着順やキーワード
ブログサイトに対するランキング：リンク数、アクセス数、投票数によるランキング
→目的トピックに関する最新エントリが存在するとは限らない
？？ブログサイトの知名度は低いが隠れた名文を探したいのか？→名文サイトは必然的に高いランキングを持つ気がするのだが？？
？？投稿数と投稿内容のレベルに相関性があるのか？あれば分野別にランキングを作った方が早いのでは？？
・提案手法のコンセプト
☆熟知度が高いブロガーが書いた記事は素人が書いた記事よりも価値が高い
中身よりも情報の発信者に対する権威が、エントリの信頼度を保証するのでは？
→対象トピックに関して詳しく書かれたエントリを数多く投稿したブロガーは熟知度が高い
・提案手法
1.熟知領域リストの作成
「ファン、マニア、フリーク」で検索してこれらの検索後の直前の語句のうち、出現頻度が高いものを辞書に登録
→500領域
独自開発した生活体験シソーラス(LETS)を用いて、そのカテゴリを熟知領域リストとして採用
→14000領域
熟知語そのものではなく、「赤ちゃん」にたいして「離乳食」「おむつ」といった関連語による重み付けも必要！
2.ブロガーの熟知度スコアの算出
熟知語と関連語と共起語数を用いて算出
スパム対策もしている
3.ブログランキングの算出
熟知語をリスト化→この熟知語リストからクリックすると、その側面からみたその熟知語を扱うブログが見れる
熟知ブロガーを熟知度に基づいてランキング
・ニュアンス比較について
ニュアンス（清清しい、感動、可愛い、怒り、恐怖など）とその関連語からブログ記事のニュアンスを判定
全ブロガーと熟知ブロガーのある語に対する感情の主成分を解析
・効果
ある検索ワードに関する結果だけでなく、関連ワードもリストアップするので、その関連ワードに依存した立場による記事が見れる
ニュアンス比較によりどういう感情をもってブログを書いているのかが分かる
・実験システムに関するデータ
ブロガー 70000以上
エントリ 140000以上
20個のキーワードに対して、熟知ブロガーとして妥当か判定91％
エントリは67％
学生は20人
・今後は信頼性の高さを提示できるようにしたい
・生活体験シソーラス
ブログやニュースなどの実テキストにしばしば表現される生活体験を体系的に整理・分類したシソーラス
概念の変化について扱う（移籍した野球選手etc）
自動的カテゴリ辞書管理システム：連想辞書の自動生成
成分解析エンジン：任意の入力テキストを分類するグラデーション・エンジン。広告や商品のレコメンデーションに応用している。
[質問1]
ブロガーの熟知度とエントリの妥当性の評価が分かれたのは何故？
[質問2]
頻繁にエントリを出しているブログでも内容がやばい場合もある
→フィルタリング、熟知ブロガー同士のリンク関係などを利用してうまく排除したい。
[質問3]
LETSはどうやって作る？
→候補は機械的に、最後の決定は人手である
ブログの信頼性の指標はすでにあるのでは？それと関連させることは考えていない？
→普段は違う意見のグループが、あるテーマについては合意が取れた場合、そのエントリは信頼性が高い。そういうところをみたい。
■キーワードの時系列データにもとづくブログ、ニュース、スパムの解析
島根県立大学 石田先生
・事項相関に基づきキーワード出現頻度の基本周期系列を抽出するアルゴリズム
・分析データ
実験データの取得期間：2008年1月1日から2009年5月15日
ブログ、ニュース、スパム
毎日ランキング上500をとり、出る単語を解析
それぞれの単語について各日に登場した回数の配列を求め、自己相関を求める
・自己相関の隣接差分積
時系列データの自己相関の局所的ピークを検出
・情報源に対する比較（定量的分析）
7日周期が多い
・ブログ：7日比べて14、21日周期も多い（月末、週一のテレビ番組）
長い場合は365日
・スパム：短い周期の頻度、スパマーが短い周期で類似文章を投稿
2日周期が多い
・ニュース：基本周期に沿っている
7日が突出している
・定性的分析
・週間キーワード（基本7、たまにずれる）
出現頻度リストについてブログは鋭く、スパムは平坦
・完全週間キーワード
？？休講ワードが出てきた？？これって完全週間なの？？
・週間ブログキーワード（特徴的なキーワードを適当に選定）
週末の運動に関するキーワードが多かった。
・年間キーワード（365日を周期としている）
[質問1]
自己相関とはどうやって求めているのか？
→単語の出現頻度を毎日だす（日数分の配列を用意して、それぞれにその日のその単語の出現頻度を入れる）。それに共分散を算出
どういうアプリケーションに応用したいのか？
→広告などのマーケティングに利用
[質問2]
がちがちなアルゴリズムになってないか？
→緩くしてしまうと、解釈が難しいデータになってしまった。
[質問3]
結果がある程度自明になってはないか？周期性が見つけられて、そこに何かがあるのが分かったら良いんだけど。そこらへんからどうやって人の活動を見出したいの？
→今後分析していきたい
[質問4]
フーリエ変換を使おうと思わなかったのか？
→自己相関を使う事を決めていた
スパムブログフィルタに使えないか？
→使える
■旅行ブログからの観光情報の自動抽出
広島市立大学大学院 石野さん（えらい美人！声もきれい！うぐいす嬢かと思った！！）
・2007年観光立国推進基本法が成立
データベースはあるが、人手で集めているので大変
→ブログから自動的に観光情報を抽出
網羅性、最新性、ブログ著者の属性からユーザに適した観光情報
・提案手法
1.旅行ブログの検出
旅行ブログの例：観光情報が含まれているかで判定
観光：余暇時間の中で、日常生活圏を離れて行う様々な活動であり、ふれあい、学び、遊ぶ事を目的とするもの
複数エントリにまたがる旅行エントリは、中日が検出できない。。。（最初の日と最後の日しか旅行とかかない）
→系列ラベリング問題として扱う
機械学習としてCRFを利用
2.旅行ブログからの観光情報抽出
地域名と土産者の対の抽出 Google7-gram？？（これがないと余計な文章を抽出してしまう）
→旅行ブログに含まれる地域名と土産物の両方を持っている文を抽出
→新たな土産物の対を抽出
・実験 検出編
まずYahoo!ブログから観光、旅行という単語を含むエントリを抽出
再現率は低かったが、精度が高かった。→ブログ数を増やすことで解決できる
再現率＝複数エントリに渡る旅行記の一部の場合、検出できない場合もある（こういう漏れのなさが再現率）
記載内容が少なくても難しい
検出誤り＝旅行ブログでないのに、旅行ブログとしてみてしまう
エントリの前後に旅行ブログがあったりする
地元紹介のエントリ？？これは取れても良いのでは？（地元の判別さえできればOK）
他人の旅行を紹介しているエントリ
・実験 観光情報の自動抽出
それぞれ任意に80000文を抽出
旅行ブログ
一般ブログ
一般ウェブ
[質問1]
土産ものと場所の対だけでなく、景色とかを扱う場合は、このままの手法で使えるか？
→有効であるものとないものに分けられる。食事をメインに扱いたい。
公共機関ではなく、ブログからの抽出の意義は？
→ユーザの主観的な感想が見たい。
踏み込んだ事が書いたブログじゃないと抽出する意味が無い。そこらへんまでやってるのか？
→（なんば先生）ブログ先生から抜く意義はパーソナライズにある。ブログを書いている著者のパーソナルデータから、さらにリコメンドできたら嬉しい。
[質問2]
旅行ブログでないと判定したものの中の地元紹介は何でだめなのか？ニッチな観光情報として使えるのでは？
→今回の目的には沿ってなかっただけ。
この手のブログはすっごいスパムが多い。。。偽情報とかはどう判別しているのか？
→今後。
？？ブログエントリにタグってついてないのかなぁ、それ利用できないのかなぁ？？
==============
ここまでが第一セッション。
目標である「１セッションにつき１回は絶対に質問する」はクリア☆
やっぱりWebマイニングの世界はテキストベースが多いんだなと改めて実感しました。
ブロガーの体験熟知度についてははうちの研究室で、pdfの推薦を考えている同期の研究の参考にもなりそうです。
生活体験シソーラスLETSはちょっと欲しい。。。
最後の旅行ブログの質問2について、彼女と同じ研究室の院生が、ブログからの主観的データの抽出を行っているそうなので、それと組み合わせると結構良い感じになりそうです。
10月のWI2でそっちの発表も聞けたら良いなぁ☆
2009年7月4日土曜日
研究会にいってきます
明日７月４日から２日間に渡って広島で開かれるＷＩ２（Webインテリジェンスとインタラクション研究会）に参加してきます。
研究会そのものは初めてではないのですが、いつも同じ研究室の先輩同輩が一緒なので、今回初めて１人きりでの参加ということに妙にドキドキしてたります。
いや、実のところ大分ドキドキです。
発表しないのに＜笑
人と話すの下手くそなんですが、たくさん知り合いできたら良いな。
とりあえず今回の目標としては
１．全部の発表についてメモをとる
２．１セッションにつき１回は絶対に質問する
３．名刺を１０枚獲得してくる＜笑（要は話せってコト）
そして一番重要なのが笑顔を絶やさないこと。
ポジティブさが大事☆
研究会そのものは初めてではないのですが、いつも同じ研究室の先輩同輩が一緒なので、今回初めて１人きりでの参加ということに妙にドキドキしてたります。
いや、実のところ大分ドキドキです。
発表しないのに＜笑
人と話すの下手くそなんですが、たくさん知り合いできたら良いな。
とりあえず今回の目標としては
１．全部の発表についてメモをとる
２．１セッションにつき１回は絶対に質問する
３．名刺を１０枚獲得してくる＜笑（要は話せってコト）
そして一番重要なのが笑顔を絶やさないこと。
ポジティブさが大事☆
2009年7月1日水曜日
劇的ビフォーアフター 生け花編
ちょっと花を生けてきました＜笑
私がTAをしている講義で知り合った子が、生け花サークルの代表をやっていて
お稽古体験のお誘いを受けて行ってきました。
まあ、とっくに院生なんで（汗）ホントに遊びに行ったような感覚なんですけどね。
お稽古には小原流の先生が呼ばれていました。
あまり流派について詳しいことは分からないのですが、
国宝の装飾を行ったりと割と有名な流派みたいです。
今回やったのは「瓶にいける」形で、お盆ではなく縦長の花器にいけるというものです。
実はお盆に生ける方が簡単で、瓶に生けるのはちょっと難しいらしく、
あまり初心者向きではないという。。。＜汗
とりあえず30分奮闘した結果、こんな感じになりました。
まずは中央にあるメインの花（主枝、クルクマという花らしい）を生けるのですが、
こいつをどう立てたものか、最初からつまづきました＜汗
先生曰く、前後20度の傾きはOkとのことで、竹串で補強しつつ主枝を投入。
その後回りのミドルサイズの花（副枝、トルコキキョウ）を45度の傾きでさして、
あとは周りを飾っていきました。
盆の場合、剣山（針がびっしり並んだ奴）で固定できるのですが、
瓶の場合はそれが出来ないので、微妙なバランスで枝や花を重ねていきます。
これがかなり難しく、私の作品は、しょっちゅうバランスを崩して倒壊してました・・・(T_T)
出来たお花は、一旦バラして、家に持ち帰ってから生け直します。
再現不能かと思いましたが、案外うまく生けなおせました。
解像度の関係であまり変わらないように見えるかもしれませんが、
実際のバランスはやっぱりお稽古で生けたときの方が全然良かったですね。
ザ先生マジック＜笑
結構楽しかったので、出来ればまたお稽古したいです。
ただ、年甲斐を考えるとなかなか難しいものが。。。
ちなみにお世話になった生け花サークル様のサイトです。
↓↓
日花里
ありがとうございましたー☆
私がTAをしている講義で知り合った子が、生け花サークルの代表をやっていて
お稽古体験のお誘いを受けて行ってきました。
まあ、とっくに院生なんで（汗）ホントに遊びに行ったような感覚なんですけどね。
お稽古には小原流の先生が呼ばれていました。
あまり流派について詳しいことは分からないのですが、
国宝の装飾を行ったりと割と有名な流派みたいです。
今回やったのは「瓶にいける」形で、お盆ではなく縦長の花器にいけるというものです。
実はお盆に生ける方が簡単で、瓶に生けるのはちょっと難しいらしく、
あまり初心者向きではないという。。。＜汗
とりあえず30分奮闘した結果、こんな感じになりました。
まずは中央にあるメインの花（主枝、クルクマという花らしい）を生けるのですが、
こいつをどう立てたものか、最初からつまづきました＜汗
先生曰く、前後20度の傾きはOkとのことで、竹串で補強しつつ主枝を投入。
その後回りのミドルサイズの花（副枝、トルコキキョウ）を45度の傾きでさして、
あとは周りを飾っていきました。
盆の場合、剣山（針がびっしり並んだ奴）で固定できるのですが、
瓶の場合はそれが出来ないので、微妙なバランスで枝や花を重ねていきます。
これがかなり難しく、私の作品は、しょっちゅうバランスを崩して倒壊してました・・・(T_T)
出来たお花は、一旦バラして、家に持ち帰ってから生け直します。
再現不能かと思いましたが、案外うまく生けなおせました。
解像度の関係であまり変わらないように見えるかもしれませんが、
実際のバランスはやっぱりお稽古で生けたときの方が全然良かったですね。
ザ先生マジック＜笑
結構楽しかったので、出来ればまたお稽古したいです。
ただ、年甲斐を考えるとなかなか難しいものが。。。
ちなみにお世話になった生け花サークル様のサイトです。
↓↓
日花里
ありがとうございましたー☆
登録:
投稿 (Atom)
投稿
