Re: 詞庫整體規畫（一些舊信供參考）

[thhsieh@tlug.sinica.edu.tw]

謝謝果正兄的整理 :-)) 以下是我的一些個人意見，謹供參考。
大家如果有意見也請盡量提出，一同討論。

tsi.src 若要新增欄位的話，我認為基本上分為兩種:

1. 未來可能進入 run-time database 者，以 libtabe 而言，就是會進入
   .db data structer。

2. 純粹 comment，未來不需要進入 run-time database 者。這種 comment
   就可以用 # 來 mark 以來，附加在所有欄位之後，例如:

   <欄位1> <欄位2> .... <詞條> <詞頻> <注音> <其他欄位> .... # <純粹 comment>

同時，我建議盡量做到 backward compatibility, 也就是新增的欄位是可
有可無的，而不需要每個詞條都必須包含所有的欄位。

: ◎ 注記的方式：
: 
: > 假設我們的詞有幾個來源：
: >
: > L-舊的 libtabe tsi.src
: > M-教育部國語辭典
: > E-輕鬆輸入法詞庫
: > A-中研院分詞標準
: >
: > 那麼新的 tsi.src 中每個詞條就多一個「來源」的欄位，紀錄長度是 1-4。
: > 如果一個詞是 tsi.src 本來沒有但後來從國語辭典加進來的，而這個辭在
: > 輕鬆輸入法的詞庫也有，但在分詞標準沒有，就是 ME，依此類推。這
: > 是可讀性比較高的作法。如果要省空間的話就用一個 8-bit 字元也可以，
: > 反正只要四個 bits 就可以紀錄這些訊息。

這個我建議可以擺在 <純粹 comment>。故不需要考慮幾個 byte 的問題。

: ◎ 破音字的問題：
: 
: >> 是不是可以考慮一個簡單一點的做法？
: >> 例如，現在 libtabe 中已有某讀音中每個字字頻排序表，例如:>
: >> ㄎㄜ4:  客 課 刻 克 ....
: >
: > 破音字的發音，如果不標頻率，至少要照頻率排序過，才能避免打「
: > ㄎㄜˋ」跑出「可」來。如果使用者打「ㄎㄜˋ」，固然「可」是含
: > 有這個音的最高頻字，但是「ㄎㄜˋ」不是這個字的主要發音。如果
: > 單音節詞選字時可以避開該音節不是主要發音的字，只從那個音是主
: > 要發音的字裡面挑，應該就比較不會遇到這種問題了。

未來如果我們重新計算字頻、詞頻時，看要不要每個字/詞的各種讀音
出現頻率都計算進去。如果要的話，則詞頻欄位需要擴充。目前的格
式是這樣:

可 <number>  ㄎㄜ3 ㄎㄜ4

我建議未來可擴充為:

可 <number1>,<number2>  ㄎㄜ3 ㄎㄜ4

也就是兩個詞頻數值中間以沒有空白的逗號相連，其中 <number1> 為
ㄎㄜ3 的詞頻，<number2> 為 ㄎㄜ4 的詞頻。這裡最好要有 backward
compatibility, 萬一多個音但只有一個詞頻時，則程式就自動認定這
兩個音是相同的詞頻，或者前者為 <number>, 後者為 0。就看我們的
implementation。同時，詞頻越高的音應排在越前面。

這部分應屬於 run-time database 的一部分。

: ◎ 拆詞的問題：
[deleted ....]

這就直接 depend on 我們的演算法，也就是 bims 的演算法。什麼樣
的演算法，所需納入的詞條形式與類別都不相同。做為一個完整的詞
庫，我們應盡量納入各種類別的詞條，讓 AP 視其需要選用。

因此，我提議這裡要增加 tsi.src 的加注欄位，並擺在第一個欄位:

<類別欄位> <詞條> <詞頻> <注音> <# comment>

擺在第一欄位有兩個好處:

1. 因為我們的 tsi.src 都會 sort 一遍，如此相同類別的詞就會自
   動被放在資料檔中的同一個區段，未來如果我們要將它拆成數個檔，
   不同類別不同檔案存放時，會很方便。

2. AP 在讀取 tsi.src 時，可以讓它們直接檢查第一個欄位，以判斷
   這樣的詞要不要拿去用，而不需要 scan 整行之後才知道要不要拿
   這個詞，如此可以增進效率。

這個欄位未來可以進入 run-time database, 也就是當 AP 可以處理
詞性、詞類別時，就可以直接拿去用。另外，若考慮 backward compatibiliy,
這個欄位可以是 optional。如果沒有這個欄位的話，以 tsi.src 的
角度來講，是強烈建議各 AP 都要收這個詞；以可以處理詞性、詞類
別的 AP 來講，則是 implementation dependent。

因為此欄位可有可無，因此我建議此欄位要有特別的記號，以供判斷。
例如程式在 scan 第一個欄位，發現該欄位的第一個字元是 ! 時，就
知道它是類別欄位，否則為詞條欄位或其他東東。而 "!" 字元就是類
別欄位的特別記號。

: ◎ 詞庫運用的問題：
: 
: >> 我目前的策略是這樣的， gen_inp 是以輸入法表格為導向的模組，而 bimsphone
: >> 是以「音」為導向，且使用 libbims 為核心的模組，以此做為二者功能上的區
: >> 分。至於未來是否要在 gen_inp 中加入可以使用 libtabe 詞庫的部分，目前
: >> 沒有計畫，除非我們可以先弄清楚上述提到的問題 :-))
: >
: > 增加這樣的功能說難不難, 說簡單也不簡單.
: >     
: > tsi.db 是跟輸入法無關, 只有詞的一些資料.  yin.db 剛好相反, 是跟注音輸入
: > 法共存.  比方說要做一個倉頡的詞"倉"輸入法, 只要用類似原理做出一個 cj.db,
: > 斷詞演算法等的差異並不大.
: >       
: > 難的是, 每套輸入法的重根規則不同, 只能一個個對付.

我現在知道為什麼果正兄希望將詞條與注音或其他欄位分開成不同檔案
了 :-))

以下是我臨時想到，不確定是最好的想法:

假設有兩個檔案，一個是 tsi.src, 一個是 keystroke.src, 前者是放
詞條，後者是放注音，或者是其他輸入法的字鍵碼，則:

1. tsi.src 的格式如下:

   <類別欄位> <詞條> <詞條編號> <詞頻> <# comment>

2. keystroke.src 的格式如下:

   <詞條編號> <字鍵碼> <各字鍵碼的使用頻率> <# comment>

注意，這裡的 <詞頻> 就只有一個數字了，也就是該詞在一般用法中實際
出現的頻率。

那前面出現的各讀音的「音頻」: <number1>,<number2> ... 要放那裡呢？
我想就放在 keystroke.src 的 <各字鍵碼的使用頻率> 欄位吧。而那個
<字鍵碼> 以注音輸入而言自然就是注音碼囉。不過，我想 <各字鍵碼的使用頻率>
這個欄位恐怕只有在注音輸入時才會遇到吧，其他輸入法可能就不需要了。

這裡很重要一點是 <詞條編號> 欄位，這是模仿 I18N 的 charmap 的做法，
在 I18N 中每個字都會有一個編號，也就是 Unicode 的編號，而在 locale
data 中每個字就用 Unicode 編號來代表，因此，當我們的 locale 要換字
集時，就換掉 charmap 就好，不需要連同 locale data 都重寫。

這裡也是模仿這樣的精神，如果我們要將詞庫用在別種輸入法上，就換掉
keystroke.src 即可。但這裡要小心的是，每一個詞條都要有一個獨一無
二的編號。因此我們還要再做一項工作，就好像那些國字整理小組或 Unicode
consoltium 所做的一樣，整理詞條，指定編號，可能還需要同化某些詞條 ....
etc ....

哇! 這麼多工作，要不要定一個計畫表啊? 要不然恐怕會頭昏喔 :-)) 

以上只是我的 purposal, any comment?


T.H.Hsieh

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