4/30(一)工作日誌

今天將implicit feature mining的初步方法做出來，
我的想法是找出feature後再去從含有這個feature的句子，
尋找最近的形容詞，並計算次數，
次數最多的就是最能代表這個feature的形容詞，
一開始我將次數設至少要在3以上，
而這樣的形容詞太少，
因此我改成2，
找出最能代表此feature的形容詞後，
從原本的review代進去看，只要有句子含有這個形容詞，
就會認為這個句子含有這個feature，
不過效果很差，幾乎可說是完全沒有提升，
因此關於這個方法可能還要再多想想了。

4/27(五)工作日誌

劉兵做的方法，基本上我已經是照樣做出來了，
而precision及recall分別是4成多及接近7成，
雖然和劉兵自己做的有些差距，
但我認為domain不同，
實驗的結果當然也會不同，
像之前movie review哪篇，
precision及recall也是只有5成多，
所以我想照劉兵的方法應該結果就是如此了。
而今天就是將擷取出的feature及review做一個好的結構，
以進行我之後要做的分析，
還有將之前寫的class再做一些修正及整合。

4/26(四)工作日誌

今天下載了老師說的三篇paper，
這幾天會在看看，是否有可以用的地方，
如果可以的話，再想辦法改進自己的東西。
另外系統的部分，正在做將feature找到後，
把最能代表每一個feature的形容詞找出來，
之後再依靠這些形容詞去找implicit的feature，
我的想法是如果一個意見當中有某個最能代表某意見的形容詞的話，
就算這個意見有含有這個feature，
當然決定形容詞的方法是很重要的，
這方面要在仔細的想一下，
再測試這樣的效果如何。
這個禮拜應該會將這些工作完成。

4/25(三)工作日誌

今天將系統所找到的feature做一些修正，
並將feature以及關於這個feature的opinion sentence，
做一個視覺化的動作，
能夠讓使用者自行決定哪些feature是他有興趣且想要看的，
可以自行勾選，
不過只是雛形而已，還不是作得很好。
這幾天可能會對這個部分做些研究，
並一邊觀察可以用哪些方法增加precision及recall。

4/24(二)工作日誌

今天針對找出的feature phrase做修正，
像front desk這種feature，
這兩個字連在一起才是有意義的，
而分開來則沒有意義，
所以要將這種feature的single term給去除，
不過由於feature找出的phrase不是很多，
所以能提升的precision很有限，
進一步觀察找到的feature，
發現在hotel的review中，常會提到way、day...
等等一些不相干的名詞，
我想接下來要如何去除這些不相干的名詞來提升準確率，
可能需要一些時間了。

4/23(一)工作日誌

今天把precision不高的原因做了研究，
發現我找到的所有feature跟所有正確的feature相比，
有一些出入，不只數量較少，而且有些找到的feature並不正確，
如果數量少就算了，因為有些feature的support非常低，
不正確的feature就是造成precision不高的最大原因，
之後就要想想要怎麼去除這些不正確的feature，
還有今天做了劉兵的compactness pruning的動作，
雖然之前老師說用sequential mining的話，
這個步驟就可以省略，
但我後來想一想，因為我有移除掉stopword，
如果找出的feature phrase在原本沒去除stopword的句子中，
其實隔很遠的話，哪這個feature的確是沒有用的，
而根據觀察的結果，這樣的動作也確實是必要的。

4/20(五)工作日誌

今天總算將precision及recall給算出來，
用的方法是先用劉兵的方法，
只採用noun及noun phrase的feature下去找，
而根據我標feature的過程中，
確實所有的feature都可以說是名詞性的，
之前報告的clean這個feature，其實應該可以包括在room下面，
因為通常說到room這個feature時都會同時說到clean。
而最後算出的 precision 及 recall 分別是42%及67%
這當然不是一個好的結果，
而我也去掉了一些地名及飯店名的feature，
不過這顯然還不太夠，所以造成precision如此的低，
之後就要好好想想要怎麼在這方面做改進了。

4/19(四)工作日誌

今天一時手殘，把標好的答案給刪掉了，
所以又花了一些時間重標答案，
之後就在想比對的誠是要怎麼寫，
原本以為不會太難，
沒想到花了蠻多時間，
今天結束時完成了一半，
還有在產生feature時，發現由於是做旅館的review，
所以也會跟著產生地名的feature，
所以之後要找告name entity的工具把這種feature給消除。

4/18(三)工作日誌

今天發現之前標答案的做法和劉兵有些出入，
我是想將含有feature的sentence取出，
再依照所找到的feature找出的sentence來計算precision和recall，
但劉兵的做法是把一個產品中的每一個review含有的feature找出，
再計算這個產品總共有多少feature，
然後依照feature list把review中的feature找出，
以此來計算precision和recall，
這樣的做法其實有些取巧，
如此一來如果在一個review中有的句子是implicit feature，
但在同個review中含有相同feature但是explicit feature，
這樣的話其實在這個review中，他還是會算成找到，
也因為這樣的做法precision應該也會跟著提高，
而今天我也因為發現這個原因，
所以要重標答案，
預計明天會有一個結果出來。

4/17(二)工作日誌

報告完後，我依照老師說明的將投影片做修改。
並加上reference，
然後去找了老師說的Social Summarization of Online Auction Feedbacks，
這一篇的確是我報告的，
我以為老師是說另一篇學弟報的別篇論文，
看了一下哪一篇的作法，
他的做法是將feature以及相對應的value找出，
來去除禮貌性的敘述。
但feature以及其value是人工觀察所產生的，
如果只有一部分是這樣做的話，
應該還可以接受，
但所有部分都是這樣產生的話，就太domain specific了，
不過這提供了我一個想法去找出非noun/noun phrase的feature，
所以這幾天會在這方面多思考，
看能不能想出確定的做法。

4/16(一)工作日誌

今天和老師討論後，
再確定了一次目標，是對於feature extraction的改進，
而透過演算法跑出來的feature，有蠻多其實是不必要的feature，
像是hotel的名字、一些特殊的地名如New York等...
這些我想可能就靠建rule的方式來去除，
而劉兵沒有做的implicit feature的部分，
我想了一個很簡單的方法，
明天meeting會跟大家報告，
至於還有沒有其他可以改善的方法，則還要再多想一想。
只是我蠻擔心如此一來我之後的工作進度會延誤很多，
原本預計五月前可以完成的系統，
現在可能無法如期完成。

4/13(五)工作日誌

今天主要的工作內容是將論文的related work的部分，
再做一些修改及增加。
還有對整個系統做一些整合的動作，
例如寫檔及刪除不必要的檔案等，
因為整個系統寫到現在也有一些大了，
之前寫的東西有些忘記，
今天主要就是將一些class再做更詳盡得註解，
另外去除一些已經不必要的class，
周末空閒時會盡量把答案標出來，
下禮拜就可以算出準確度，
並做一些改進修正的動作。

4/12(四)工作日誌

今天主要都是在做標記答案的工作，
由於意見還不少，
所以花了不少的時間，到目前大概標了一半左右，
但在標答案的過程中，也要每一句都要看過，
所以也發現其實大部分是feature的字也都有抓出來，
所以precision和recall應該不會是很低的結果。
還有最後算分數的結果，
我是想要從含有feature的句子中，
找到opinion word/phrase，
先稱之為opinion set，
再把這個set中每一個item帶進PMI的式子計算，
得出所有item的分數後，
把最高減最低得到範圍的區間，
再除以五得到五等份。
如此落在哪一等份的分數就是幾顆星。
這樣就是我目前最後算出評價的方法。

4/11(三)工作日誌

今天將產生pattern的演算法做了更改後，
由於可以控制產生pattern的長度。
使得效率大幅增加。
將support設到1%，在兩千多個transaction中，
也只需要1秒的時間，
而且也跑出了相當多的關鍵字，
我應該會跟劉兵一樣只取出noun或noun phrase，
之後再用opinion word將infrequent的feature取出，
如此一來，效果應該是也還可以，
這幾天就要快點將正確答案標出，來確認效果如何。

4/10(二)工作日誌

今天把Turney用PMI algorithm來計算semantic orientation
的方法給做出來。
但還沒跟整個系統做連結。
只是先試一試效果如何。
我是先implment一個測試的視窗。
然後可以輸入要得到分數的phrase，
則程式會傳送這個phrase到AltaVista search engine。
之後再計算phrase分別和"excellent"、"poor"
用NEAR這個在AltaVista的operator的hits數。
結果還算OK，一些phrase像是great service，
都會得到正向的分數。
之後要考慮的就是套入整個系統，
然後再把分數正規化到1~5之間。
之後將frequent feature做完一些後處理後，
就會開始標出正確答案，
來計算feature的precision及recall了。

4/9(一)工作日誌

今天把Turney的PMI algorithm中，
提到的altavista search engine試用了一下。
在論文中提到有用到operator "NEAR"，
用法為 term1 NEAR term2，
則會傳回這兩個term的距離在十個字以內的結果。
操作上沒有太大的問題，
但要如何透過程式呼叫並擷取結果的話可能就要再研究一下。
還有我想找到的frequent feature可能就會用人工來做刪除。
因為我只留下長度不超過三個字的feature，
所以用人來判斷其實也不會太累。
希望這個禮拜結束前可以把這部分給完成。
還有今天也試用了一下老師所說的slideshare，
明天meeting時再跟大家做一個報告。

4/4(三)工作日誌

把Turney的論文看過一次後，
覺得他所提出的PMI algorithm應該是可行的。
所以我想就依照這個演算法來求的feature的分數。
大致上的做法如下:
首先依照prior的演算法找出frequent的feature後，
將這些feature依照同義詞，
看能不能再做分群的動作，
之後產生一個feature word list。
分群完後到意見之中找出含有feature的句子。
再依照Turney的演算法將要算分數的phrase找出，
如1.JJ 2.NN or NNS 的phrase找出，
1. 2.是表示word的序數。
用PMI algorithm算出分數來，
再依據每個feature之中的各個句子的分數來決定feature的分數。

4/3(二)工作日誌

把stopword以及做了word stemming後，
item大幅地減少，
透過associate rule來找出pattern的速度也增快不少。
我先把目前所有抓的reviews來做實驗。
總共有544篇意見，
transaction大概有2500條。
用劉兵只找frequent pattern的方法。
的確可以跑出想要的feature。
但出現的feature我覺得有些少。
只有room、service、claen、staff等...
大概不到20個。
不過太多應該也不太好。
所以我想應該就會依靠這些feature來進行下一步分群的動作。

4/2(一)工作日誌

今天主要是將論文的部分做一些修改，
還有參考一下好的會議的論文的寫作技巧。
主要把introduction以及系統的部分做些補充。
還有因為我的論文和劉兵的題目其實非常相似，
主要就是差在最後的延伸，
因此在整個作法的前面部分其實是幾乎一樣的，
要怎麼寫作，也是一個需要好好構思的地方。