libchise化の問題

[守岡知彦 / MORIOKA Tomohiko]

守岡です。

公約がなかなか実現できてなくてすみません。

とりあえず謝っときます。(^_^;;

>>>>> In [chise-ja : No.00379] 
>>>>>	"江渡さん" = Kouichirou Eto <ml2004 ＠ eto.com> wrote:

江渡さん> Ruby/CHISEのlibchise化をすすめているのですが、その過程で気付
江渡さん> いたことをメモしておきます。

江渡さん> Ruby/CHISEでは様々に高度な機能を実現するために、どうしても
江渡さん> libchiseだけでは機能が足りず、その部分をRubyによるハイブリッ
江渡さん> ド化でおぎなっています。具体的にはまず、libchiseと同等な動作
江渡さん> をするPureRuby版(Ruby/BDBを使用)のlibchise_rを作り、追加機能
江渡さん> はここに実装しました。その上でC言語によるextension、
江渡さん> libchise_cを作り、両者を中間層で統合するという戦略を取ってい
江渡さん> ます。libchise_cを使用している場合でも、必要な機能が無かった
江渡さん> 場合はlibchise_rにfallbackすることによって、全ての機能が動作
江渡さん> するようになってます。libchise_rだけでも完全に動作します。

江渡さん> これでなんとか動くようになったのですが、この戦略は大変面倒で
江渡さん> あり、かつメンテにコストがかかりそうです。かといって、
江渡さん> libchiseに機能を全て追加してしまうのがいいのかどうか、よくわ
江渡さん> かりません。さてどうするべきだろうか、というのがこのメールの
江渡さん> 主旨です。

御迷惑お掛けしてます。

江渡さん> 具体的に追加した機能を並べてみます。まず、each_ccs_name、使
江渡さん> 用可能なCCS の一覧がない。これはeach_feature_nameの逆写像な
江渡さん> ので本来はeach_feature_nameを用いて実現可能なはずですが…。

chise_ds_foreach_char_feature_name では余分に出てくるのが面倒ないしは
CCS の判定が面倒ということでしょうか？ char-feature が CCS かどうかの
述語があれば良いのかな？

江渡さん> CCSに対するeachがない。例えばJIS X 0208集合に含まれる全文字
江渡さん> といった検索をする場合があり、そのために使いました。

chise_feature_foreach_char_with_value などでは継承がサポートされてなく
て不便ということでしょうか？


江渡さん> IDSから文字を検索するためにcharacter/by_idsという新しい
江渡さん> directoryを作りました。定義からするとby_featureでもいいよう
江渡さん> な気がしますが、実際にはcode_pointからchar_idへのmappingだけ
江渡さん> に限っているため、文字列からchar_idへの対応をするdbは別の
江渡さん> treeにしたほうがいいだろうと判断しました。(by_idsでの検索が
江渡さん> 出来るのなら、by_nameによる検索などが出来ても良さそうな気も
江渡さん> してくるが…。)

現行の directory 構成に変更した時、単一の data source において char-id
の体系を単一にすることにしたので、by_feature/ に CHISE 的文字列をキー
にした逆引表があっても良いと思います。また、by_name や
by_sound ＠ ja%2Fon%2Fkan などを増やしたくなったり、あるいは、自動的に逆
引表を生成したりする時のことを考えれば、character/by_ids よりは
by_feature/ids が良いような気がします。


江渡さん> libchiseからは外れるかもしれませんが、やはりメタ文字DBが欲し
江渡さん> いです。現在はCCS間の継承関係はアドホックにライブラリに埋め
江渡さん> 込んでますが、本来はそのような情報は外に出したい。
江渡さん> chise-db/characterと並列に、ccsというdirectoryを作り、そこに
江渡さん> 置くのでどうでしょうか。前回この話が出たときは、データ構造を
江渡さん> どうするかの話でストップしたのでしたっけ。

<chise-ja:00242> によれば

・文字素性 → 属性値

	$CHISE-ROOT/feature/property/<name>

	但し、<name> は属性名


	例：文字素性属性 :type

	/usr/local/lib/chise/db/feature/property/type


・属性値 → 文字素性

	$CHISE-ROOT/feature/by-property/<name>

	但し、<name> は属性名


	例：final-byte から CCS 名への対照表

	/usr/local/lib/chise/db/feature/by-property/ccs-final-byte

;; foo-bar はその後 foo_bar に変えたので、by_property になる


   また、alias に関しては、素性属性 :true-name を用いて解決しようと思っ
   ています。例えば、XEmacs CHISE で

	(define-charset-alias 'ideograph-gt '=gt)

   とした場合、文字素性 ideograph-gt の属性 :true-name に =gt という値
   が入ることとします。これにより、属性 :true-name の有無で alias かど
   うかが判り、alias の場合には :true-name の値によって本名を調べるこ
   とができます。

ということで、directory 構成はとりあえず決めてた模様です。

形式は plain text でしょうか？


江渡さん> また上地さんからも話がありましたが、やはりchise-dbが独立して
江渡さん> 配付されているとうれしい。BDBファイルで配付するという案もあ
江渡さん> りますが、バイナリの互換性は無いのですよね。データ構造をどう
江渡さん> するかは悩み所ですが、当面はS式のままになるのかなと。

ちゃんと確認してないんですが、endian が違うはずの x86 Linux の BDB ファ
イルが Mac OS X で読めたような気もするので、実は portable なのではない
かという疑問があるのですがちゃんと調べてません。ご存知の方がいらっしゃ
いましたら是非情報をお寄せくださいませ。

とはいえ、配布用データ形式についてはちゃんと考えたいですね。XML 版の話
が止まってるので、現状では S 式しかないですね。一応、現在、XEmacs
CHISE 附属の文字定義ファイルは従来とは異なり Unicode の範囲内の UTF-8 
に収まるように符号化している（utf-8-mcs-er を使っている）ので、大域的
情報交換はできますが。

-- 
===『幾千億の分子に分かれても ========================================
     決して忘れない。    
     この宇宙が終るまで』              守岡 知彦 (MORIOKA Tomohiko)
====================== Email: <tomo ＠ kanji.zinbun.kyoto-u.ac.jp> ======