3/30(五)工作日誌

今天測試了一下劉兵第一篇得做法，
先用250篇意見來做測試，
support訂1%就跑了幾小時。
是可以跑出一些關鍵的名詞出來，
如price、staff、room等...
不過時間實在太久。
發現應該先去掉stopword。
如此可以大幅減少item，增加效率。
所以這幾天會先修改一下input的item。
來看看跑出來的效率及效果如何。

3/29(四)工作日誌

今天把劉兵在KDD'04的哪一篇再看一次，
但有些地方寫得不是很清楚，
看他的reference找到了同樣作者但是是發表在AAAI'04上。
其實這一篇跟KDD'04哪篇基本上是完全一樣的，
但內容寫得更加詳細。
發現到其實透過associate rule找feature時。
這一篇的做法只是將frequent的noun、noun phrase。
再經過一些刪除的方法，
將多餘的feature去除。
這點是我之前都沒有發現的，
因為先看了第二篇，
所以就有了先入為主是以rule找feature的想法。
如此，我想先試試這樣的效果如何。
如果還可以的話就先用這個方法。
畢竟最後的目標是不相同的。
比precision及recall並不是我的目標。

3/28(三)工作日誌

今天先試試看沒有標記[feature]的item測試看看
由於一個transaction中不能有重覆的item，
所以將句子以及其POS tag分開當作item的話，
可能會有許多重覆的item產生。
如一個句子有複數的very的話，哪item就會有重覆的情形。
所以我就將一個word以及其POS tag當作一個item。
先試了一下用110個意見，共544個句子。
support訂40%，confidence訂60%。
rule就已高達數十萬條。
這樣要過濾也相當困難。
因此這兩天應該會先把要當feature的字訂出來，
然後用有包含feature的transaction去跑。
如此產生的rule應該會少掉許多，
也比較會是想要的rule。

3/27(二)工作日誌

meeting完後，
將丁昭廷報的paper下載來看一下做法。
這篇在產生feature時的確是先產生feature word list。
也就是keyword list。
而keyword list中還包含了opinion word。
也就是說這篇paper是把feature word
以及opinion word放在一起考量，
也就是觀察這兩種word同時出現的pattern。
而如果只有其中一種出現的句子，
也就是他們所謂的implicit feature。
而實驗中和劉兵比較的哪一篇作法，
是劉兵的第一篇做法，
劉的做法是將pos後的句子直接丟到associate rule
algorithm來產生rule。
但內文中沒有明確的說明rule是什麼樣子。
從文章中我覺得他就是把frequent的rule直接當成feature來用。
如(item1)，(item2)->(NN feature)
imply後的就是feature了。
而他有提到兩個刪除多餘rule的方法。
所以應該是unsupervised的做法。
但我要做的東西基本上目標應該是不同的，
我的重點應該是在最後算分數的動作上，
如此產生的summary會有蠻大的不同，
而不是全部都拿來當summary。

3/26(一)工作日誌

今天由於生病，相當不舒服。
只有把老師修改過的論文部分，
做一些訂正。
明後天希望可以把訂正的部分做好，
還有多增加一些內容。
這禮拜結束前預計要將feature找出來，
並做好標記的動作，
以產生預期的rule。

3/23(五)工作日誌

跟老師討論後了解了要產生rule的item，
應該要是什麼型式了。
之後就要做修改，跑看看結果如何，
還有最後計算分數的式子，
初步的構想，是結合Turney的PMI algorithm。
所以之後的時間我就將之後要coding的部分，
再做一個整合及構想，
以及再看了一下Turney的paper。

3/22(四)工作日誌

今天研究了一下最後的feature value的式子。
算是有一個初步的構想了。
明天再跟老師討論看可不可行。
然後今天有找了一下associate rule的tool。
網路上是有挺多這方面的tool。
不過input以及output都不盡相同。
我還要再研究一下最適合我的，
畢竟要換tool的話，]
哪我之前的input也就要跟著做變動了，
還是先研究一下哪個較方面好用。
例如我找到的一個tool就有點麻煩。
他要輸入的變數就不光是support及confidence。
還有很多不太了解的變數，
希望這禮拜能夠解決這個問題。

3/21(三)工作日誌

跟承道討論了一下關於support的問題，
他說有可能是我的input編碼要做排序，
之後我就試試看做了排序後的結果。
結果仍是一樣，只要support訂的太低，
也就是pattern會產生太多的話，
rule的產生就會有問題，
這一點可能是rule的左右邊可能出了問題。
也就是pre-condition以及post-condition的部分。
但我想也可能是程式的問題。
如今也不太可能去改他的code。
而且就我所知，associate rule應該不會有這問題才對。
所以可能就要試試別的tool了。
在網路上找到劉兵在1998年的CBA method，
詳細的方法我是還沒看，不過網路上也只能下載demo版的。
正式版的還要去跟他require，
可能之後又要再寫一封文情並茂的mail給他吧。
另外發現微軟的新搜尋引擎，加入了人的互動，還蠻有趣的。
http://www.msdewey.com/

3/20(二)工作日誌

今天試了一下產生的rule，
用幾十句話丟進去的結果來看。
大概就會有數百個pattern以及上百條rule。
不過這都不是太大的問題。
跑出來的時間其實都算快。
但如果我把support設到6%以下時，
algorithm就會出現問題。
這一點還要在check一下是什麼原因。
畢竟劉兵的論文support是設在1%，
所以之後幾天可能就會把這個部分解決，
看會有什麼feature會跑出來。
再進行下一部分同義詞分群的動作。

3/19(一)工作日誌

今天將要把當作associate的item的input的部分做了修正。
因為我的associate mining的algorithm不能有重複的item，
而這部分就要將pos後的tag做修正。
像是一個句子中可能有很多的very這個term出現
ex:... very(RB) ... very(RB)
而我要做的就是像下面的修改
ex:... very(RB1) ... very(RB2)
如此要丟進algorithm的item就不會有重複的了。
但這樣的item種類還是很多，
明天就要先將word做stemming之後再丟進algorithm看看。
如此一來產生的rule應該會少很多。
而寄給作者的內容我就放在mail中，
謝謝老師的幫忙了。

3/16(五)工作日誌

今天寫了一封mail給"mining and summarizing customer reviews"的作者，
請教它們關於要產生associate rule的item的詳細格式如何。
希望他們會有回音，如果沒有的話就只好照之前所想的去try。
再看效果如何，再慢慢做調整。
還有今天將chunking前的處理再做一些修正。
之前發現分割使用者意見的地方有一些小bug。
所以今天做了一些改正，讓分割意見時不會出錯。
另外今天也將論文的系統做法的部分寫了一部分。

3/15(四)工作日誌

今天的時間大部分仍是花在了解要產生的rule前的item上，
反覆看了幾次paper，
我想應該是要把一些常出現的詞性的tag就當作item。
例如staff service is good
而丟進algorithm的item應該為 is good
如此一來應該可以節省很多不必要的rule，
而且產生的時間也會快很多。
不過為了確保起見，
我想明天可能會寫個email，問問作者到底是不是如此。
這樣應該比自己假設會好很多。
另外今天也將related work的部分多寫了一些。

3/14(三)工作日誌

今天花了蠻多時間在了解要產生rule的item的格式到底該如何。
因為要產生rule不是難事，但產生的rule要有用才是問題。
所以看了一整天劉兵的paper，有一點覺得很納悶。
他上面提到他的item有可能是POS後的tag以及原本的word。
但這一點讓我不得其解，
我以為POS後的tag以及原本的word應該是同一個item。
不知道這樣做的用意到底為何，或者是我曲解了他的意思。
這個地方不弄清楚的話，下面也很難進行。
未來幾天一定要快點把這裡弄懂才行。

3/13(二)工作日誌

今天把related work的部份再寫了一段，
是關於opinion summarization的。
看了幾篇之前看過的文章，以及它們的related work，
這部分著實花了不少時間。
還有將chunking的ouput修正為自己想要的格式，
以做為associate rule的input，做意見之間的分割就花了一下午，
後來用regular expression完成。
之後用一些測試的檔案跑了一下，試一試產生的rule如何。
但如果把support調太低，pattern就非常的多，跑rule就會花不少時間。
測試的檔案我只有用四句話，而support為20%的話，
pattern就可以有上百個。
當然其中有很多的rule是不需要的，
這一點還要再回去看一下要怎麼去除不必要的rule。
未來這幾天應該就會在這方面做改進。

3/12(一)工作日誌

今天的時間都花在chunking的程式編寫上。
由於input以及ouput的輸出要做調整，所以花了挺多時間在try。
而試的過程並不是很順利，因此耗了整個晚上。
不過後來跟坤墇討論一下，算是有想出方法解決。
預計明天花一些時間就可以解決了。
之後有寫一下論文的做法部分。
想了一下這禮拜大概可以做到什麼進度。
預計將系統做法寫一半，related work寫完以及測試產生的rule結果如何。

3/9(五)工作日誌

今天將經過chunking過後的句子，會產生重複的地方寫了程式來做編號區別。
花了一些時間，預計禮拜一就可以完成。
之後再將feature的tag標好，就可以做試驗看產生的rule好不好。
也寫了一下論文的系統做法部分。
還有確定一些reference的paper。
預計下禮拜可以寫出系統做法的部分應該可以寫到一半左右。
而最後算分數的式子也在思考當中，應該也是在下禮拜時會有一個初步的雛形吧。

3/8(四)工作日誌

今天把模糊集合的定義大體上看了一下。
由於之前沒有修過類神經，所以這方面對我來說是新的東西。
不過模糊集合在定義上不是很難。
基本上是在說可以把一件事不只用二分法來做分類。
而是可以讓這件事介於0和1之中。
如此的應用方法，我覺得可以用在我的計算分數的方式上。
例如將一個句子中出現的"clean is good"的clean good給一個0.7分的分數。
以此類推將可以歸類為clean這個feature的句子的分數通通得到後。
在套用至模糊集合的歸屬函數，則可以得到clean的分數。
這只是目前粗略的想法，等想到仔細的式子時再跟老師討論。

3/7(三)工作日誌

今天下午再看了一下code，之後就去找承道討論。
發現原來是我的input出錯。
在input的pattern方面不應該有重複的item出現。
但我是將一個句子中的term經過POS轉換後成為我要產生rule的input。
但一個句子有時會有重複的term，如”the”這種term。
就回去看了一下paper，是我當時疏忽了。
劉兵的做法是將有重複的POS會標示1、2、3。
如POS的tag為[NN]term1 [NN]term2 -> [NN1]term1 [NN2]term2
如此就不會有重複的問題了。
雖然也可以用別的pattern來解，但是如此可以省去寫code的時間。
所以這部分應該算是解決了。

3/6(二)工作日誌

今天花了些時間和學長討論有關最後feature的計算方式。
發現到機器學習中有個歸屬函數的部分或許可以應用在這邊。
如此的話就不會只是根據單純的形容詞來給分這麼簡單，會是更深入的式子。
所以之後我會先更深入的了解一下這部分，再繼續和學長討論。
如果覺得大致上可行的話再跟詢問老師的意見。
而程式的部分在傳值時發生了一些問題。
所以明天晚上會去找一下承道學長，了解問題是出在哪邊。
這樣應該會比自己找出來快一些。

3/5(一)工作日誌

今天幾乎所有的時間都是花在associate rule的程式的撰寫上。
為了能夠讓其他的class之間能夠有更好的銜接，所以花了一些時間。
預計明天應該可以寫完這個部分的code，在測試一下產生的rule到底如何。
之後思考了一下整個系統還欠缺的工具，接下來就是把這些工具套在系統中。
邊coding邊編寫論文內文。
希望這個禮拜結束時能完成論文的系統架構部分。

3/2(五)工作日誌

今天主要的時間花在論文的系統架構寫作以及程式coding
在論文的編寫部分，我把架構圖整理了一下，之後做了一些內容的編寫。
也順便確定各步驟的做法。
程式的部分是先將associate rule所要用到的資料結構寫了一下，大致上是快完成了。
然後順便Check了一下之前對於抓取網頁內容的部分。
發現有一些內容可以再過濾的好一些，就做了一些修正。
預計在下禮拜三之前把associate rule的部分完成，以及把論文的系統架構完成一半。

3/1(四)工作日誌

目前的進度大致是將論文的Introduction部分修改好，這幾天再做一些潤飾後會在po上去。
Related work的部分也寫了大概一半，不過下禮拜是打算先把做法的部分先完成。
因為 Related Work的變動可能會比較多，在還沒確認所有的reference之前。
還有之前找到的chunking也要做修改，由於登凱也會用到這個tool。
所以這個部分的話會跟他再討論，做一些確認。
這一部分完成後，所有的前處理大概就完成了。
希望在下禮拜前能完成這些動作。