chise-db

2005年 6月 15日 (水) 02:32:19 JST

>>>>> In [chise-ja : No.00429] 
>>>>>	Koichi KAMICHI <kamichi ＠ fonts.jp> wrote:

> chise-dbをいじればいじるほど、なんだか沼に足を踏み入れてしまったよう
> な気がする今日この頃です^^;４つほど教えていただけないでしょうか。

すいません。(^_^;;;

> １）featureとby_featureの対称性

> chise-db\character以下のfeatureとby_featureディレクトリ以下にDBファ
> イルがありますが、サイズからして両者の情報量は一致していないと思いま
> す。

> たとえば、0x4e00から0x9fa5までのint値を元に"=ucs"という素性を
> chise_ds_decode_charで探しても１つもエントリはありませんが、0x4e08と
> いうchar_idからは"=ucs"の素性に対して19976というint値が得られます。
> つまり対称になっていませんよね。

> これはアプリケーション側で、chise_ds_decode_charと
> chise_ds_foreach_char_feature_nameの双方からデータを探す必要がある、
> ということでしょうか？

=ucs の特殊事情です。UTF-2000 時代以来、system-char-id をなるべく UCS 
の code point に合わせるという小細工を弄してたのですが、こういう小細工
をすれば、system-char-id と =ucs の値が一致すれば =ucs の値を省略する
事が可能となり、実際にそうした小細工を弄して来ました。

lazy-loading 機構の導入以降、こうした小細工を行う意義はあまりなく、
対称性を欠き美しくないので、止めた方が良いかなと時々思いつつも、そのま
まで今日に至っているのですが、どうしましょうか？

という訳で、CCS 素性の場合、逆引表が存在するので、
chise_ds_foreach_char_feature_name を使って探索する必要はありません。
ただ、CCS 素性の継承関係は考慮する必要があります。
(<CHISE-SYSTEM-DB-DIRECTORY>/feature/property/mother; ごめんなさい、
API まだ作ってないです。今ならご要望に沿った仕様を作る事が可能です)

;; 関数 chise_ccs_decode と関数 chise_char_load_feature_value 等で継承
;; をサポートするか、別に継承サポート版を作るべきだと思っているのです
;; が、どっちの方針で行くか決心が付いてません。ご意見ください。


> ２）u+4e08「丈」

> このコードポイントについては、３つ関連オブジェクトがあります。そのう
> ち、筆押さえの無い字形２つが以下です。
> ==============================================
U+4E08 = B-A456 = J97-3E66

  http://mousai.kanji.zinbun.kyoto-u.ac.jp/char-desc?char=&J97-3E66;
> ==============================================
G0-5549 = J97-3E66 = C1-4437 = GT-00020 = UU+4E08

  http://mousai.kanji.zinbun.kyoto-u.ac.jp/char-desc?char=&C1-4437;
> ==============================================
> で、どうして２つに分かれるのかがわかりません。たとえばJIS90とJIS97で
> 分離しているのですが、90から97のときに字形は変わったのでしょうか？も
> しかして2画目の頭が真ん中から始まるのか、右寄りから始まるのか、の差
> でしょうか？

U+4E08 = B-A456 = J97-3E66 は筆押えのある字体とない字体を包摂した文字
オブジェクトです（U+4E08 = B-A456 = J97-3E66 の ->subsumptive 素性は
GT-00018（起筆あり）と GT-00020（起筆無し）の２つの文字オブジェクトを
含んでいます）。

現在、CCS 素性には包摂度の高い（抽象的な）もの（=jis-x0208 ＠ 1997, =ucs 
など）と包摂度の低い（具象的な）もの（=jis-x0208 ＠ 1990, =ucs ＠ unicode な
ど）の双方があります。でも、命名規則で表現できていません。このあたり命
名規則で体系化すべきなんじゃないかという気がします。そうすれば、現在、
=daikanwa や =cns11643-* や =gt などは具象 CCS しかないですが、抽象
CCS も使えるようになります。多分、その方が便利な事もある気がします。

案としては、

(a) prefix で表現する

    例えば、

      =CCS	その CCS の包摂規準で包摂するもの（抽象 CCS）
      ==CCS	その CCS の例示字形を指すもの（具象 CCS）

    とか（a-1 案）。ただ、そうすると、今の =CCS の多くは具象 CCS で、
    大変動になるのと、多くの CCS は包摂規準がないか曖昧だったりするの
    で、抽象 CCS が安定的に定義しにくいかも知れないことを考えると =CCS 
    で具象を指す方が良いかなという気もする。

    逆に

      =CCS	その CCS の例示字形を指すもの（具象 CCS）
      =^CCS	その CCS の包摂規準で包摂するもの（抽象 CCS）

    みたいなのも考えられる（a-2 案）。具象（例示字形）は出典 (domain) 
    が決まれば１つで、具象より具象なものは考えにくい気がするけど、抽象
    なものは、より抽象なものがある気がする。そうすると、=^^CCS,
    =^^^CCS みたいに抽象方向に伸ばせるようにしとくと良いのかも知れない。
    でも、抽象の抽象って謎かも。包摂規準にはちゃんと名前を付けて管理し
    た方が良いような気もする。あと、=ucs は 抽象 CCS が良い気がする。

    また、一方向写像が =>CCS であることを考えるなら、

      =CCS	その CCS の例示字形を指すもの（具象 CCS）
      ==>CCS	その CCS の包摂規準で包摂するもの（抽象 CCS）

    というようなのもありかも（a-3 案）。=>CCS で ==>CCS を指す sugar
    があれば、=>CCS が使えて自然かも。

(b) domain で表現する

    例えば、

      =CCS	その CCS の包摂規準で包摂するもの（抽象 CCS）
      =CCS@発行年 or =CCS@版名
		その CCS の例示字形を指すもの（具象 CCS）

    とか（b-1 案）。=jis-x0208@{1978|1983} みたいに入れ替わってる場合
    には、発行年はまずそう。

    @unified とか @abst とか @representative とか @concrete というよう
    な名前は嫌な気が（抽象・具象は相対的な関係の問題であって、絶対的な
    抽象 CCS, 具象 CCS があるとするのは良くないと思うので（抽象文字と
    かいっちゃうのと変わらない気がする））。

    とすると、

      =CCS@	その CCS の包摂規準で包摂するもの（抽象 CCS）
      =CCS	その CCS の例示字形を指すもの（具象 CCS）

    という風に特殊な空ドメインを用いてみるとか（b-2 案）。
    そうすれば、=jis-x0208 ＠ 1978@ = =jis-x0208@/1978 ないしは
    =jis-x0208@@1978 = =jis-x0208 ＠ 1978/ と表現できる。

私としては、（a-3 案）か（b-2 案）が良いかなと思います。また、その場合
も =ucs は抽象を指すことにしたいです。


> ３）ideographic-products

> この素性は初めて気がつきました。これはideographic-structureから自動
> 生成していると考えていいのでしょうか。

ids/install-ids.el の最後で呼ばれる関数 ids-update-index で生成されて
います。本当は自動更新したいんですけど。


> ４）もう遅いかもしれませんが…

> いろいろ使えるようになってきた結果、やはり手元のWindows（cygwin）
> 環境で使えたら良いのに、と思うのですが、素性名（＝DBファイル名）に記
> 号が使われていて、chise-dbのtarを展開するとファイル名エラーになって
> しまいます。なんとかwindows環境で使う方法は無いでしょうか？たとえば
> ファイル名をbase64かなにかでエンコードして、アプリケーション側でデコー
> ドするラッパーがあればできるかもしれませんが。

江渡さんがかつてどうにかしてたと思うのですが私は具体的な対策を知りませ
ん。

CHISE-core の配布を考えると、CHISE_DIR_VERSION が上がってしまいますが、
Windows 環境で使えない文字を（UNIX 系でも）quote するのは悪くないと思
います。

関数 CHISE_Attribute_Table_open を見ると、今の所、`/' と `%' だけが
quote されています（hard coding してるし(^_^;）。ここに問題のある文字
を追加すれば良いんだと思います。

;; `:' を追加すれば良いんでしょうか？

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