Yuichi Yoshida
oxy****@kmc*****
2005年 9月 25日 (日) 17:28:13 JST
吉田です。 > 田畑です。 > > anthy開発の項目のうち、僕のTODOっぽいものを列挙します。 > 適当な手段で優先順位のコメントをいただけると助かります。 > > (a)地名辞書の分離 > (b)接頭辞、接尾辞の指定方法の拡張 > (c)自立語、付属語の接続の統計情報の生成 > (d)形態素解析器の命名 > (e)開発者の募集 僕の中での優先順位は(c)>=(a)>(b)です。 (d)、(e)はレイヤーが違うので別枠で。 以下、各々に対するコメント。 -- > (a)地名辞書の分離 > cannadicの中にもanthyで追加したcompound.ctdにも多数の地名が > 含まれているのですが、これらを全部抜き出して別のファイルに > しようと思います。 > *地名の接尾辞は色々なパターンがあるので、(b)でやる予定の > 拡張を利用して正確な接尾辞を付けれるようにできるはずです。 > *郵便番号辞書から地名を取り出すスクリプトを田郷さんから > もらったので、そこから出た地名も追加します これは特に問題無いと思います。やってしまいましょう。 > (b)接頭辞、接尾辞の指定方法の拡張 > 例えば、次のような形式で接頭辞、接尾辞を詳細に指定 > できるようにすることを検討しています。 > ：おおさか #CN #<ふ*府 大阪 > 「#<」で接尾辞を指定 > 「#>」で接頭辞を指定 > 「#+」で指定した単語と同じ接頭辞、接尾辞パターンを持つ(継承) (c)で (名詞あるいは名詞をクラスタリングしたもの)x(接頭辞、接尾辞) の行列を作ることで、なんとかならないでしょうか。 接頭辞、接尾辞の指定だけなら、接頭辞、接尾辞付きの単語をそのまま登録してしまえば良いので、 この方式の肝は継承にあると思うのですが、あんまり再利用できる気がしないんですよねぇ。 継承が有効に働きそうな地名やら人名やらには既に、それ専用の接頭辞、接尾辞の品詞がありますし。 (c)を使うのでなくて手動でやるのであれば、地名の品詞を細分化するぐらいで良いかなという気がします。 > (c)自立語、付属語の接続の統計情報の生成 > (多分)wikipediaの文章を(d)の形態素解析器にかけて、文節を構成する > 自立語、付属語の統計を取ることになる予定です。 > 各文節に出てくる自立語の関係や同音異義語の出現など、色々なものが > 統計の対象として考えられますが、とりあえず自立語x付属語の行列を > 作って出現頻度を詰めれば効果がありそうな気がします。 本当はこの情報は分かち書きの時点でも使うべきなのでしょうが、 そこまで一気には作れないので、とりあえずは候補選択でだけ使うことを考えましょうか。 ちなみに分かち書きの時点でも使いたくなるのは次のような例 「映画で|揉みにいこう」 => 「映画でも|観に行こう」 自立語x自立語は当然やるとして、自立語x付属語が役に立つのはどういう場合でしょう。 > (d)形態素解析器の命名 > 考えても決まらないのでanthy-morphological-analyzerにしてしまおうと > 思います。 この名前を宣伝に使うわけでもないので、これでOKです。 > (e)開発者の募集 > anthyに限らず他の変換エンジンや新規開発のでも良いのですが、 > もう少し人が欲しいと思ってます。 > 変換エンジンの開発は敷居が高い上に評価されない領域であり、 > 僕らに出来ることはそれほど無いのですが、少しぐらいは手を > 打ちたいものです。 僕がHaskellでRubyを実装することができたのも、 Rubyの内部実装に関する詳細なドキュメントがあったからなので、 Anthy Hacking Guideのようなデベロッパ向けの文書をきちんと書けば、 或いは変換エンジンを作ってみようという方が現れるかもしれません。 多分、評価されていないということは無いと思いますよ。 anthyに関わったおかげで、僕自身は色々と交流が広がりましたし、 全然IMとは関係の無い集まりで、たまたまユーザの方がいらっしゃって、 その方に感謝されたこともありましたし。 それはさておき、コンパイラなどとは違って変換エンジンの教科書が無いのが、 変換エンジンの開発者が少ない一つの理由かもしれないですね。 ---- 吉田 悠一 oxy****@kmc***** http://mono.kmc.gr.jp/~oxy/
