Re: 詞庫整體規畫

[thhsieh@tlug.sinica.edu.tw]

: > "#" 還是保留給 comment 用，而 ! 開頭者的 word 就是註記，後頭加的  
: > symbol 就是代表此詞條的屬性。如 NL 是「名詞 (Name)」「地方 (Location)」，
: > 所以合起來就是「地名」。
:   
:   我記得以前蔡志浩兄曾提到把這些注記硬塞入一個 byte 中，這樣會不
:   會比較好處理？各位程設的功力都比我高，腦力激盪一下吧！^_^
:   * 大意是加此，我會再查一下 archives。

我覺得這裡用什麼格式來表示並不重要，也不會 cost memory usage and/or
performance。我目前的構想只是在詞庫中加一些標記，表示這個詞屬於何種
類別，而讓外部程式可以「選用」。這裡的外部程式包括 libtabe/tsiadd。

因此，這些注記可能到了 libtabe 內部運作時就沒什麼特殊意義了，除非它
的演算法改變，可以聰明到處理詞性時，則也許會將這些注記納入程式運作中。
但就現階段而言，這個注記只是用來決定: tsiadd 在編譯時要不要這個詞？

是否要硬塞入一個 byte？我覺得那是將來程式運作時必須納入注記時才要考
慮 (因為要考慮記憶體的使用量)。然而，從直觀來看一個 byte 只能代表
256 個值，似乎不太夠 ....

因此，在詞庫的 source 階段 (也就是 tsi.src 中)，我們可以自由一點，
用比較 human readable 的方式來標注記。

:  這裡另加入我個人的意見，那就是可不可能將詞庫就只有詞條本身，至於
:  其它詞頻、注音、注記的部份獨立出來，大家的看法如何？構想還很粗糙   
:  ，目的是可以將詞庫內容的整理簡單化，讓更多的朋友能夠參與，另外就
:  是其它的輸入法要運用的話可能會比較方便。

我不是很贊成。如果說在現階段的 review 工作可以簡化工作，這我同意，
但未來弄成一個 product (or, package) 時，這種資料分離不見得有好處。
可能會造成維護上的困難 (改了這個檔，忘了改那個檔，或沒有小心維持
consistancy ....)

: > 再來討論該加那些註記？我們有必要定得很詳細嗎？還是只針對一些特
: > 別的詞 (如贅詞、人名、地名、專有名詞 ....) 先來定？後者的話比
: > 較容易，若前者的話就要很小心了，恐怕得經過詳細討論、try and error
: > 之後才能有完善的定案。
: 
:   這個就大家想想怎麼樣比較好，不過，如果是以一個 byte 來當注記
:   的話，要寫入什麼內容，空間應該是夠的。

這裡要小心點，我想要再細分一下了: 我們要做什麼功能的注記？我原先
只是希望做一個詞條類別注記，讓 AP 在使用我們的詞庫時，可以挑選它
要的詞去用。而果正兄所討論的注記，似乎是偏功能取向的，程式 (libtabe)
本身在 run time 在使用詞條時的各詞條的詞性。

我原先的想法是，這樣的注記不需要編入 .db 檔的資料結構中。而果正
兄可能是希望將它編入 .db 檔中？

: > 我的建議是，先從後者開始做，一方面比較簡單，同時也俱備實驗性質，
: > 可以用來檢驗我們這樣定好不好。缺點是，將來我們若要再加入新的詞類
: > 時，恐怕需要再從頭 review。從頭 review 到底好還是不好，我覺得要
: > 看是從那個角度來看，浪費時間精力是不好，但好死不死剛好發現 bug 
: > 的話就是好，而且在從頭 review 的話因為注音都已填補完畢，同時絕
: > 大部分的錯誤也已更正，故理論上速度會很快，而且我們可以更專心地
: > 去做分類工作。
: 
:   我的意思也是最後再來做整批的處理，因為目前需要討論出注記的標準
:   出來，可能需要一點時間。大家覺得如何？

我覺得「大略的」現在可能可以開始做，像是疑似贅詞的詞條，看起來可刪、
卻又不好直接刪去，這時就在 mailing list 上提出來，我來加上注記。其他
更詳細的等以後慢慢規劃再說。

當然，注記的標準要先討論出來 :-))


T.H.Hsieh

To Unsubscribe: send mail to majordomo@linux.org.tw
with "unsubscribe xcin" in the body of the message