8/3(五)工作日誌

網頁版大致完成了，
最後treeview顯示的部分我還要再做一些修改。
應該這兩天就可以完成。
還要老師交代的paper我會做一個整理再讓老師過目，
不知道老師是否有時間修改我的論文內容部分，
讓我能夠對這部分做訂正。

7/27(五)工作日誌

web的介面顯示直方圖的功能最近有找到套件並完成，
不過treeview的部分還要再試一下。
另外一開始的使用介面還要再做一些修正，
預計下個禮拜應該可以完成。
還有這一陣子會把老師之前要我看的paper，
把相關的部分看一看做個整理，
看能否加到related work的部分，使論文更充實。
目前所能做的應該就是這些。

7/19(四)工作日誌

最近在將web版的介面給完成，
之前視窗程式中顯示結果的直方圖，
我有找到一個套件來顯示出來。
不過免費的版本如果點圖的話就會連到官方網站。
這是比較美中不足的地方。
其他在圖的呈現部份都還不錯。
還有我也有在看論文的內容，
持續有在做修改。
之後就要將web的介面能設計的更好看好用一些。

7/5(四)工作日誌

今天將web介面中找feature的程式改成主控台的應用程式，
剩下一開始得到url以及最後輸出的方法要想。
不過這也是最難克服的兩個部分。
希望下禮拜結束前可以完成這個部分，
之後再詢問老師須要改進那裡。

7/2(一)工作日誌

今天開始著手寫web介面，
因為之前做的是視窗程式，
所以要改成主控台應用程式才可呼叫。
今天改了一小部分，
並試著從一個網頁的意見當中，
一直抓取下一個網頁的意見。
希望這個部分能盡快完成。

6/28(四)工作日誌

今天從老師那邊知道論文還有很多問題，
之後這一段時間會將related work做好統整後再充實內容。
還有將introduction寫得更完善。
在系統部分就和阿岡一樣加入使用者能在web線上使用的考量，
來多加敘述及描寫。
能做的就盡量多做以符合老師的要求。

6/27(三 )工作日誌

今天將related work及sytem architecture的部份加了一些內容。
也上傳到google document了。
而上傳的同時發現在google document的圖的部份，
在word的顯示上沒有問題，
但一到線上就會亂掉了，
這個地方我想之後會用小畫家存成整個圖檔再修正吧。
還有老師前天回覆的系統架構的部份，
我不太了解老師指的是哪一個部份，
可否請老師說明的清楚一些，
我再跟老師報告。

6/26(二)工作日誌

今天將之前看的一些paper在研讀一番，
看看好的conference的論文的寫作技巧，
再對照自己的論文，
看有哪些地方可以再加強。
這幾天應該就會繼續這樣的工作，
讓論文能夠更完整一些。

6/25(一)工作日誌

今天主要都在修改論文的內容，
看還有那些地方可以加強修正，
之後就將投影片的內容也更著做修改。
最近應該就會先把這些部分給完成，
再看老師有什麼建議可以再加強。

6/22(五)工作日誌

今天交給老師初稿後，
就將google document的內容更新。
並將references也做更新。
之後就在仔細看看論文當中有沒有哪裡還可以再加強的地方，
或者有哪些錯誤要修正。
這幾天會再仔細看看內容，
如果有更動，隨時會上傳至google document上

6/21(四)工作日誌

今天的時間都花在改論文上，
每個章節都有再做修飾及加強。
還有實驗的部分，
我對評估算出的評價多加了一個統計的檢定方法，
為paired t test，
這是一種檢定兩組樣本有無顯著不同的方法，
加了這個檢定我想應該可以讓實驗更加完整。
也證明計算的方法是有效的。

6/20(三)工作日誌

放假的期間將評價的評估以及計算時間的實驗完成，
評價的評估結果還算不錯，
平均起來一個feature和標準答案不會相差到0.5。
證明這個計算的方法是可行的。
而計算時間的部分我總共計算了40家旅館。
每增加五家旅館時間就會有顯著的下降，
從前五家的800多秒到最後的300秒。
今天就把論文整個做修改，
重新檢視之前寫不好的地方，
還有格式上的問題，
也做了改善。

6/15(五)工作日誌

今天主要是在改論文的introduction的部分，
還有參考一些好的會議的論文，
看看好的論文是怎麼寫的。
好加強自己不足的部分。
這個連假會把之前提到的實驗給做完，
再加在論文的實驗部分。

6/14(四)工作日誌

之前透過持續增長的pattern而減少計算時間的想法，
跑了二十家的旅館後，
計算時間從一開始前十家旅館的十分鐘以上，
到後十家旅館的八分鐘左右，
有了顯著的下降。
之後我會再多做幾家，
希望時間可以控制在可以接受的範圍內。
明天會在用之前想的評估方法來評估計算出的分數好壞。

郭泓志 6/13 好投強打

台灣球員大聯盟首轟

6/13(三)工作日誌

今天被老師指導論文的缺失後，
回去就開始著手改進。
之後會再更仔細的編排論文的章節及寫作技巧。
然後我評估分數的分法初步的構想是，
將yahoo上旅館的feature的分數當作標準答案，
然後將我找到的feature中有包括yahoo上的feature的分數兩兩相減，
再除以總共所做的旅館個數。
基本yahoo上的feature都是大方向如service、location這種feature，
所以我應該都能抓到，
而我想評估的方法就大致上會是這樣。

6/12(二)工作日誌

今天把另一個耳機的feature extraction的實驗做好，
recall結果為0.8677，
precision在name entity前後分別為0.403及0.4183。
之後算了20家旅館的評價分數，
明天再算十家，
然後評估分數到底算得好不好。
另外把老師交代的論文樣版做了大部分，
google documnet的鏈結都弄好了，
reference也大部分都有了，
有幾篇找不到，明天再花時間仔細找找。
abstract的部分之後寫好了再補上。

6/11(一)工作日誌

今天將一個耳機產品的答案標好，
並計算其precision及recall，
recall為0.73左右。
而precision在named entity前後分別為0.3718及0.3984
效果雖然沒有hotel哪麼好，
不過也算是有效果。
之後的時間修改了計算評價分數正規化的方法，
然後抓了之後要做實驗的旅館的網頁。
這幾天就要計算算出的評價分數效果到底好不好。
如果效果不錯，
而且在計算的時間上真的能夠經由計算一定數量的旅館之後，
而將時間控制在可接受的範圍內，
希望可以還是使用目前的方法來計算。

6/8(五)工作日誌

今天將別的類別的產品的reviews網頁抓好，
我是想做再amazon.com上關於耳機的reviews。
由於網站不同，
網頁上意見的tag也不同。
所以之後就要做修改能夠抓出amazon.com上網頁的意見。
還有標出這些意見的標準答案。
預計這個周末應該可以完成。

6/7(四)工作日誌

今天大部分的時間是在修改程式，
將一開始選擇旅館的介面改成加入新的旅館才會顯示，
而之前跑過的旅館則由旁邊的下拉式選單則可選取。
之後幾天想試試看當算過越多旅館的分數後，
是不是再計算新的旅館的分數的時間，會大幅的減少。
還有嘗試做新的domain，看看擷取feature的效果如何。

6/6(三)工作日誌

今天看了extracting semantic orientations of phrases這一篇，
這一篇是用supervised的方法來決定phrase的semantic orientation，
而且文中提到就算沒有training過的phrase或字也能決定。
但這篇paper決定的是positive、negative、neurtal這三個類別。
先用人去對phrase標出這三個類別，然後再用他的方法訓練，
之後測試再做分類。
但要標出這三個類別比標出是幾顆星容易得多。
因為這三個類別可以說都有明確的界線，
但要套用在我算分數的方法，可能不是這麼適合。

6/5(二)工作日誌

今天報告完之後就修改了老師指出的投影片的問題，
然後就看了之前老師寄給我的paper，
其中有兩篇是比較相關的，
分別是mutliple aspect ranking
以及extracting semantic orientations of phrases from dictionary這兩篇。
而mutliple aspect ranking這篇用的方法，
是將一個餐廳的意見來做訓練，
然後將固定的feature建一個類似vector的record。
如一個餐廳的feature有food、service、price三個feature。
他就會針對一個意見建一個如<5,5,5>record來做訓練
其中5是代表五顆星的意思。
不過就我的觀點來看，這對固定的feature可以這樣來做ranking的動作。
可是當feature是變動時，應該不能用這種方法來訓練。
另一篇的方法我明天會再研讀，看會不會有新的想法。

6/4(一)工作日誌

今天把明天要報告的投影片做修改，
之後就把上次demo後老師所指出的最後輸出介面，
做出老師指示的介面。
將選取的旅館相同的feature並排顯示，
其餘的feature分別以pros、cons表示。
之後我會再修正一開始的選取功能，
以利一開始的閱讀，
而不會造成混淆。

6/1(五)工作日誌

今天大部分的時間都花在修介面和寫論文。
介面的部分要設計出一個不雜亂又能清楚顯示的方法，
還要再衡量一下。
而今天先把所選取的旅館以及其feature找出，
並將其共同的找出，這部分沒有太大的問題。
之後的時間我就稍微看了一下學長給我的論文，
希望在related work的部分可以再多充實一些。

5/31(四)工作日誌

今天demo完後就帶kayed到台北處理機票的事，
回來後就再修了一下論文。
然後就思考了老師說的介面的部分要怎麼修改，
預計明天可以開始進行。

5/30(三)工作日誌

下午花了一些時間把最後輸出結果的介面再做一些修正，
之後的時間就都花在論文的修改，
把實驗及problem definition的部分多寫了一些，
還有把之前的部分再重新檢視做改善。
因為英文不好，
句子可能不是很通順，文法也可能用得很奇怪。
所以花了很多時間在檢查。

5/29(二)工作日誌

今天花了一天的時間，
把之前找到的畫直條圖的元件整合到系統中。
由於是網路上找到的東西，
看method及有那些屬性就花了我不少時間。
最後的結果為，
可以先選擇兩家旅館，
之後畫面會顯示出兩家旅館相同及不同的feature，
而算出來的appraisal則會以直條圖呈現。

5/28(一)工作日誌

今天和老師討論了最後的介面，
要改成web介面的話，
我的視窗程式就要先改成主控台的應用程式，
這一方面的修改就要再仔細思考要怎麼修改。
之後的時間我就去找要能夠方便比較旅館間的feature的元件，
找到了一個可以秀出直方圖的元件。
之後就是要將這個元件套入系統中並能呈現出好的結果。

5/25(五)工作日誌

今天把程式的介面做一些修改，
因為下禮拜的demo，
所以把整個畫面弄得簡單一些。
之前因為測試方便，
把許多button都分隔出來，
今天主要的時間就是在做這些修正。
還有今天在做測試時，
突然Bellagio這家hotel跑不出feature來，
(而且就只有這家)
為了找這個bug也花了蠻多時間，
最後只好先放棄，
先改做別家hotel。

5/24(四)工作日誌

下午和學長討論了一些用wordnet來對同義詞作分群，
討論的結果是如果把所有抓到的feature都拿來作分群的話，
效果應該會不太好。
應該先挑出一些關鍵常出現的feature，
然後根據這些feature來找同義字，
再看找到的feature中有沒有這些同義字，
再來進一步做分群的動作。
而今天發現wordnet中可以將查詢同義字的結果存成檔案，
如此一來我可以先挑出要找同義字的關鍵feature，
如room、clerk等...
然後將這些關鍵feature的同義字檔案拿來當作分群的依據，
如此我就不用直接連結wordnet的API，
也省去許多麻煩。
而也能得到一樣的效果。
所以之後應該就會看看要挑出哪些關鍵feature的分群效果會較好

5/23(三)工作日誌

今天參考了之前看過的paper，
將論文的第一、二章的內容再衝什一些。
看related work的部分就花了蠻多的時間，
然後就把修改的論文上傳到google document。
請老師有空時再做修改訂正。
之後就把程式的小地方修改一下，
還有繼續研究wordnet的ductionary檔案。

5/22(二)工作日誌

今天將論文的實驗及系統架構部分做修改，
另外還有修改投影片的部分。
之後就在查詢有關wordnet的部分，
有找到一個c#的wordnet open source，
但整個file有些複雜難懂，
而且後來發現是要在Linux下才能run。
所以之後就直接研究wordnet的dictionary，
看了蠻久的時間，
有發現了一些規則，
但要套進系統中做分群的動作，
應該還要一段時間才行。

5/21(一)工作日誌

今天把五個實驗的結果做個整理比較，
之後就根據整理的結果寫在論文上。
我總共做了五家旅館，
每間旅館各取前100則意見，
抓取feature的結果和劉兵的方法做比較之後，
recall都一樣，
precision平均高了6%。
recall都一樣的原因是因為，
依照min support抓出來的feature都是一樣的，
而我改善的方法是從這些抓出來的feature以name entity來去除多餘的feature，
所以precision會提高。
另外今天把修改過後的第1、2張放到了google document上。

5/18(五)工作日誌

今天把第五家旅館的答案給標好。
跑實驗的結果如下，
precision及recall分別為60%及77%。
結果還算OK，
之後就把系統架構的部份再做一些補充，
下禮拜應該就可以寫實驗的部分了。
之後想在跟老師討論一下關於算分數的部分，
要怎麼做評估。

5/17(四)工作日誌

由於kayed要回埃及了，
之前他有說希望可以帶他買些禮物之類的。
所以今天帶kayed出去逛了一整個下午，
因此時間沒有很多，
之後就接著標之前標到一半的答案，
但還沒有標完。
預計明天就可以完成，並做實驗。
還有坤墇有給我一個用WordNet功能的library。
不過是C++的library。
要了解及套在系統中不是那麼的容易。
所以這一部分我想等實驗做完以及論文的初稿寫完後，
再盡力完成。

5/16(三)工作日誌

今天把第五家旅館的答案標了一半，
還有重新檢查了一下之前標的答案，
之後再做實驗的結果，
precision及recall都有一些提高。
大概高了5、6%左右。
這是因為之前覺得有些不是feature的字就沒有把他算進去。
但其實有可能是這旅館的特色。
像我做Las Vegas的旅館時，
一開始標答案並沒有算show這個字，
後來發現Las Vegas的旅館有些都有自己的show。
像是treasure island的海盜船秀之類的...
所以答案應該改正。
還有之前說的要用wordnet來做分群。
原本以為很簡單，
但要透過程式來呼叫並不是哪麼容易，
後來想用裏面的字典來找同義字，
但是裡面的字典有些複雜，
要找出規則並不簡單，
看來這一部分如果要做的話還要再花些時間了。

5/15(二)工作日誌

今天將第四家旅館的答案給標好，
結果算出來後不會差得太多，
precision及recall分別是44%及77%。
另外在計算分數的部分，
就算再加了新的意見進來，
由於之前已計算過的pattern，
總時間也只要在幾分鐘內就可完成，
比之前算一家旅館就要半小時以上好太多了。
這樣的時間應該是可以接受的。
之後就將系統架構的部分寫了大半。
還有將introduction及related work再做一些補充。

5/14(一)工作日誌

今天把算分數的pattern先記錄下來，
當有新的意見進來時，
如果之前紀錄的pattern有包含了新進意見的pattern，
則不用再透過網路去計算。
如此一來則可以大幅減少計算的時間。
然後就將論文的系統架構中的這一個部分，
做了一些修改編寫。
還有將系統的介面部分做一些加強改進。
因為一開始系統沒有考慮到選擇飯店的部分，
所以做修改花了蠻多時間，
預計明天可以完成這個部分。

5/11(五)工作日誌

今天標好第三個旅館的答案，
擷取feature的效果和之前一樣，
沒有太大的差異。
之後就將系統的class做一些整合修正，
還有將擷取到feature之後，
對於含有這些feature的句子的呈現做了一些改善。

5/10(四)工作日誌

今天幫資料庫增加了一些查詢的function，
讓介面能夠更方便的使用。
由於.NET和資料庫的繫結有些複雜，
所以花了一些時間。
另外開始標第三家旅館的標準答案，
希望明天可以再做兩家旅館的實驗。
另外有鑑於透過網路來對pattern算分數的方法，
真的是有些慢，
今天想到我應該把算過得pattern都先記錄起來，
之後如果遇到之前沒有算過的pattern再去做query，
如此可以節省不少時間。

5/9(三)工作日誌

今天將計算feature的分數的方法寫了大部分，
預計這兩天應該可以寫完系統架構的初稿，
之後就會請kayed先幫我看一看related work及系統架構這兩章，
然後再請老師修改訂正。
還有今天也把第二家旅館的標準答案給標完，
並測試擷取feature的效果，
precision及recall幾乎和之前做的一樣，
大概是5成多及7成多快8成。
這樣的效果還能接受，
接下來就是盡快將論文的初稿寫好，
再來看是否可以將實驗結果做改善。

5/8(二)工作日誌

今天將feature pruning的部分寫完，
這個地方我大部分跟劉兵是相同的做法，
差別是我還有用Name Entity的工具來去除不必要的feature，
但做了這個之後效果就會差得很多，
在實驗結果的部分我會做說明。
還有今天開始標第二家旅館的答案，
預計明天可以標完，
之後再加緊把剩下的旅館都做出來跑實驗。

5/7(一)工作日誌

今天的時間主要都花在寫論文上，
把系統架構的frequent explicit features generate這一小節給完成。
在這個禮拜希望能夠把系統架構這整個章節給完成，
再寫一些實驗的部分，
另外要將算分數的pattern的地方做修正，
以得到更正確的分數，
還有要將剩下的旅館意見的正確答案標一標，
理想的情形是要能標到五個旅館的答案，
希望這些能在這個禮拜完成。

5/4(五)工作日誌

今天看了一下extracting appraisal expressions這篇paper，
這篇paper的目的是要找出含有appraisal意味的句子，
而有appraisal意味的句子的判別方法，
是由別的paper所制定的條件來判別，
他們再用他們的方法將這些句子找出來，
但用的方法不是很好懂，
且評估的作法我也看不太懂，
但我覺得跟我要做的目的有些差別。
或許我應該要再仔細的了解這一篇paper才能找到可用的地方。
另外今天也將系統架構的部分再多寫了一點。

5/3(四)工作日誌

今天將name entity的工具加到系統中，
把人名、地名、時間等不必要的item去除，
而再計算precision及recall後，
效果還算可以，達到51%及74%。
而用PMI-IR algorithm算分數的方法，
今天也有了結果，
結果還算可以，
每個feature的分數看起來和意見中的感覺相差不會太大，
但有一兩個feature除外，這點就還要再找一下原因，
所以之後的工作可能就是加緊論文的寫作部分，
還有將一些小地方做修改加強。

5/2(三)工作日誌

今天把turney的PMI-IR algorithm中的pattern給抓出來，
在測試效果時分數是有算出來，
但想更進一步了解這樣的pattern到底好不好時，
因為request太多，被altavista檔掉了，
這方面可能還要再想方法解決。
另外今天找到了name enity的工具，
之後要將name enity的tool套至系統中，
將地名及人名的term給去掉，以提升precision。

5/1(二)工作日誌

雖然precision和recall不是說非常的好，
不過由於之前寫得一些結構，
再做一些修改之後就可以抓出turney的pattern出來，
所以這兩天會在這部份著手，
之後就可以算出feature的分數出來，
再看看效果如何。
另外今天看了一些登凱之前給我的reference，
是有關TERMINOLOGY FINDING的paper，
大概看了一下後，
也將論文的related word部份再多補充了一些，
還有寫了一部分的系統架構。

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以及系統的部分做些補充。
還有因為我的論文和劉兵的題目其實非常相似，
主要就是差在最後的延伸，
因此在整個作法的前面部分其實是幾乎一樣的，
要怎麼寫作，也是一個需要好好構思的地方。

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。
所以這個部分的話會跟他再討論，做一些確認。
這一部分完成後，所有的前處理大概就完成了。
希望在下禮拜前能完成這些動作。

2/13(二)工作日誌

今天早上對程式的部分稍做一些修改，trace要用的associate rule的方法。
之後覺得還是應該要用chunking以及word stemming之後產生的rule才會比較好。
Chunking的部分問了一下登凱應該是可以找到。他說他哪邊可能有。
不過還要再找一下。
Stemming的部分有找到一些演算法。
不過還要再測試一下看哪種的效果較好。
Meeting完後帶kayed去了一下大賣場買他過年要吃的食物。
順便也帶他逛了一下這邊的百貨公司。
這好像是他第一次到大賣場逛，所以我們逛了挺久的。
到八點左右才回來。
感覺他對於能出去晃晃也是挺開心的，希望能幫助他解解悶。

2/12(一)工作日誌

今天把之前看的paper做一些整理，以做為將來reference的整理。
並從中學習paper的寫法以及架構的鋪陳。
所以也順便把自己寫的內容再多做一些修改及編寫。
資料方面也看了一下自己抓的內容及標答案。
發現到reviews的文章真的相當口語，有些東西查字典也不見的查的到。
有時也可能是user寫錯字，這種情形當然在我們自己寫blog時也常發生。
不過我的目的只是要找出敘述中的feature，所以基本上是還好。
然後看了一下坤墇請大家標的文章，選了一篇來玩玩。
發現這真的是個大工程，一篇文章所要耗費的時間其實不是很短。
而且有關正反面意見的句子可能就一兩句而已，標起來實在挺累人。
不過以後我有空會多幫忙他標些文章的，希望可以減輕他一些負擔。

2/9(五)工作日誌

今天由於白天家中有些事情，所以白天耽擱了一些時間。
只有利用晚上將data的部分做一些處理，雖然之前已經有準備一些data了。
不過只準備了一小部分用來當前處理的測試，晚上將之後要用的data都準備好。
總共是500則user對於紐約的旅館reviews。
並且標記了一些在reviews的敘述當中的feature，也就是要當作產生rule以及正確答案的對照。
另外也寫了一小部分的related work。

2/8(四)工作日誌

今天報完paper後由於老師的指導使得我對投影片的作法，以及報paper的方式，了解自己的不足。
這是以後要再多改進的地方，之後就把論文的introduction的部分再做修改訂正，
之後寫了一部分的related work。
至於今天報的paper基本上跟我要做的domain真的很相似，連future work的部分剛好就是我現在做的data。
因此這幾天應該要好好思考是不是可以從這一篇paper來改進，或者是用目前做的方法來產生summary。
再進一步來比較產生summary的效果如何。
但是標資料的部分真的很累人，光是目前在做的部分的資料標記應該就會花蠻多時間了。
所以這一部分也是要再思考的。

2/7(三)工作日誌

今天大致上是把明天要報的paper仔細的看一次，大體上都沒什麼問題。
然後再把投影片的部分做最後的調整及修改。
白天花了蠻長的時間做這些動作 ，也由於再把paper仔細看過一次，所以對於拍賣網站的意見，
有了更深入的了解，而將自己的方法套用到這個domain上感覺是可行的。
但詳細的做法還要再想一想，目前只是有個觸發，但具體的說法還不能說清楚。
晚上把老師之前修改的論文訂正到我的檔案，但發現老師好像把我原本的內容給刪除掉了。
所以我不太清楚被刪掉的內容是該如何做訂正，還是就全部刪除。
關於這一個部分我覺得用pbwiki來做訂正論文好像不是相當適宜。

2/6(二)工作日誌

今天把要報的論文的細節部分給弄清楚，投影片也做得差不多了，基本上這篇論文的做法其實很簡單。
而實驗的部分這一篇paper是用評估的方法來做，他們先設定一個假設，假設一個feedback comment在含有禮貌性的句子的情況下，變異數會比較小，最後再定一個式子並透過這個式子來成立他們的假設不過基本上對於summary的方法，好像也沒有什麼標準答案，所以這樣來做衡量，應該是可行的。

而之後在論文的部分，應該要開始標出reviews中的feature了，預計可能會找個一千則reviews，然後從這些review中的句子找出含有feature的句子，並標示出那些term是feature，這個部分雖然不會用到什麼技術，但也是相當耗時間的動作。

2/5(一)工作日誌

今天主要是在看下次要報的paper，而我決定 的paper topic為Social Summarization of Text Feedback for Online Auctions and Interactive Presentation of the Summary，作者是一群日本人，因為看到一半，所以只能先簡述一下這一篇的內容。這一篇paper主要是想要對拍賣網站上關於feedback意見做一個summary的動作，當然拍賣網站的意見非常多，要全部抓下來做分析是不可能的，所以他們的作法是針對幾個特定的seller，並擷取他們最近的幾則feedback，例如20則等，總共有1000個意見，而每個意見當然有一句以上的敘述，而敘述大概是3000多個左右，然後由他們研究出的Social Summarization method來找出非禮貌性的敘述，也就是說可以找出user非慣例性的禮貌回答，而是真正代表內心心意的回答，之後再將這些敘述做一個Summarization的動作，而根據這個summary我們還可以看出一個seller在網路上的特性等。
基本上我目前對這篇paper的認知大概是如此，而實際的做法等…我就是在下次的meeting中會報告給大家聽。

2/2(五)工作日誌

基本上今天時間都花在尋找以及看一些paper上，我在sigir’06上找到一篇關於text clustering的paper。覺得這一篇對於我之後找到feature再做clustering的動作上可能會有一些幫助，如此也可以使得我的系統在擷取feature上面，不會跟劉兵的完全一 樣。這一篇的大意是說作者研究了一個新的clustering algorithm，並在其中使用了EM的概念，對於text clustering有更好的效果。而細節的部分我還沒詳細看。所以沒辦法再多說明。

另外，找到了一篇關於拍賣網站上的feedback的summarization的paper，由於之前和老師討論到的關於拍賣網站上的意見分析，剛好發現有人有做相關這方面的研究，所以想看看別人在這方面是做了些什麼，同樣的細節部分我也還沒多看，而下次的報告中我應該是從這兩篇挑出一篇來報告。

而我還有找到一篇韓家威的paper，topic是Discovering Interesting Patterns Through User’s Interactive Feedback，原本想說可能會跟我做的有些相關，但稍微看了一些，似乎這一篇一樣是從feedback中找出frequent的pattern，並依此認定它是interesting的pattern，如此看來，可能跟我想要做的有些出入了。

1/29(一)工作日誌

由於天氣突然變冷的關係，我有點感冒，今天蠻長的時間都在睡覺，剩下來的時間找了一下word stemming的演算法。
發現單靠演算法為基礎的話效果可能並不是很好，應該要有字典輔助可能效果才會較佳。而之前找的porter的演算法，似乎已經是很有名的有關word stemming的演算法了，但實際的效果並不如預期，甚至可以說差很多，這也是我不太了解的地方。
而預官考試剩下三天，這兩天可能大部分的時間會花在準備考試上吧。

1/26(五)工作日誌

今天其實主要看預官的時間比較多，做了一些憲法和英文的題目，發現自己英文真的不太好，寫出來的分數都不太好，挫折感很大。
而憲法也是背了就忘，題目也做得不是很順。國文就直接放棄了吧，報酬率實在太低。

然後有稍微看了一下承道的演算法，應該是可以用在系統中，不過當然還是要再做一些修改，所以之後系統的部分，會在這方面著手吧。而word stemming的演算法還在search當中，這方面應該是不會太難解決，而考完預官之後，會研究一下老師之前說的IR的方法，希望可以拿來當做計算分數的方法。

1/25(四)工作日誌

今天看了一下參考的論文，了 解一下之後的架構要怎麼寫，introduction算是完成了一部分，接下來就是related work了。而系統方面，之前找的word stemming的程式，試用了好幾個單字，但效果真的不是很好，trace裡面的code發現它主要是根據一個單字的結尾來判斷，但光是這樣可能並不會有很好的效果，所以可能要再找其它的word stemming演算法來試試。
另外，associate rule的部分，突然想到承道之前做軟工的計畫中有寫一個產生associate rule的演算法，這幾天可能會去trace看看，是否符合我的需求。如果OK的話應該就會依照他的演算法來產生associate rule。

1/24(三)工作日誌

基本上前處理的部分應該還要加上word stemming，如此產生的rule才不會太多，以及產生一些並不是真正可以產生feature的rule。
因此在網路上找了有關word steming的tool，但找到的tool不知是我用的方法不對，還是演算法本身的問題，我傳一個字串received進去，回傳的值竟是receic，跟原本想的原形似乎不太相同。這部分就還要再修改一下，所以會再根據source code來做修正吧。

晚上則把論文的introduction再多寫了一些，預計明天可以完成這個部分，往後面的章節進行，以上大概就是今天的進度。

1/23(二)工作日誌

今天主要是在找有關於stop word remove以及word stemming的tool ，但並沒有找到合適的。這兩個tool找到之後，再套入系統中，則前處理就算差不多了，接下來應該就可以進入較核心的關於找feature的部分了。因此associate rule的tool也要開始找了還有測試了一下坤墇給的斷句程式，那個較適合我的系統。

而晚上則在準備預官的東西，看了一些計概以及憲法的東西還有孫子兵法，今天大致上做了這些。

1/22(一)工作日誌

早上寫了proposal的部分，將introduction 寫了幾段，大意是說隨著網路的普及化，網站上對於一事物的意見越來越多而這些意見對使用者而言雖然是豐富的資訊，但由於這些資訊越來越多，會使得使用者瀏覽所有意見的意願下降，而適當的對這些意見做分析產生評價化的動作，不僅可以方便使用者，對於廠商來說也是一項利多，可以讓他們知道何處該改進以及競爭對手的優缺點在那。

而系統方面由於坤墇的幫忙，完成了斷句的部分，效果大至上是OK，經過POS 之後的效果應該也還可以，因此之後就是要依照associate rule的產生來尋找feature的規則了。

1/19(五)工作日誌

今天看了一下雅虎的評價意見，覺得大家寫的意見真的都差不多。不過可能看得還不夠多，或許之後可能會再得到一些新的想法，對於整個系統的方面，由於老師說要web的介面，所以之後時間上充裕的話，可能會找一些ajax的書來參考，對於這個新的語言，已經聽了很久，對其功能，其實也是很想試試。希望到時能有新的斬獲。

題外話，由於預官考試而看了孫子兵法，覺得這個著作能被古今中外所推崇，真的不是沒有道理。其內容讓我學到不少。

1/18(四)工作日誌

今天早上就是meeting，而內容的部分就不再累述，寫工作日誌的確是逼自己有產出的方法。
1. 關於論文的部分，下午有一個小的想法，對於一個事物找到的feature的部分，假設已經有算出分數了，而分數的算法基本上應該也都是靠形容這一個feature的句子所得到的，如一個名為view的feature，透過所有這個feature的形容的句子來計算而得到分數，而每個句子有其各自的分數，那我想最後的output可以不只是有這個分數，還可以用最接近這個分數的句子的集合，來為這個feature做一個簡單的summarization，或許這樣會令結果有趣一些。不知道老師的看法如何?

2. 另外由於2/1就要預官的考試，所以這段時間可能需要抽一些時間來準備考試，還請老師見諒。

至1/17的工作日誌

1/12
今天和老師討論了一個多小時，有了一些新的啟發，簡短敘述如下幾點：
1. 對於最後量化的動作，在計算方面上或許可以想成是一個learning的問題，如此一來可能可以 用一些在IR上應用的model來解決，如language model、mixture model等。
2. 對於整個題目的延伸方面，不只是在單一的產品或店家上面，可以應用在像是拍賣的評價機制，對於拍賣網站上的評價意見中，套用找出feature以及量化的動作，再應用統計分析的方法，來看是否有一些如outlier或者是其他有趣的pattern來探討整個評價的機制。

1/15
今天的工作內容向老師簡述如下：
1. 對於網頁擷取的部分，是打算先將入口網站上有關於使用者意見的檔案存下來，再依照regular expression對html檔做存取，把使用者的意見抓下來。下午研究了一下，關於這部分應該是沒太大的問題。但我是將固定格式取出。
2. 而使用者的意見部分，原本是打算就存成普通的txt檔，但考量在之後還有許多的處理動作，存成資料庫之後會比較好管理，
因此之後就都在研究關於應用程式和資料庫連結及編輯的方法，雖然.net上有說明文件，但比想像中的複雜一些，所以花了較長時間，希望明天可以把這部分解決，繼續之後的處理。
3. proposal的部分預計明天開始編寫。

1/16
今天主要是在研究資料庫和應用程式的連結，簡述如下：
１. 對於資料庫的連結大致上是沒有問題了，新增、刪除、以及存取記錄上都OK，但發現抓取想要的網頁的部分有一些問題，因此做了一些修改，而對於資料庫的查詢輸出的方法則還在構思當中。
2.晚上開始寫proposal，真正開始寫才真的覺得棘手，發現很難表達要表達的意思，用中文都覺得有些困難，但這是自己應該要加強的，之後應該多參考其他paper的寫作方法再繼續修正改進，覺得這個部分是比implement更困難的。

1/17
今天的工作內容簡述如下：
1. 白天主要還是在implement整個系統，對於資料庫的欄位屬性部分做了一些思考，因此做了資料庫部分的修改而之前找的POS tool，今天做了一些測試，效果還可以，只是要先讀取其內建的模組，所以效率有點慢，不過這都是處理的部分，所以我覺得應該沒有關係。之後可能就要再修改斷句tool，方便自己使用。
2. 晚上就參考了一些之前看的論文，覺得其實introduction應是較麻煩的地方，之後可能會先從related work來寫作，如此寫作的速度可能會快一些。