[Kanji-database-developers] CHISE IDSを色々といぢっています。

[守岡知彦 / MORIOKA Tomohiko]

>>>>> In <3ay8g2kiv8.fsf%kawabata.taichi ＠ lab.ntt.co.jp> 
>>>>>	川幡 太一 <kawabata.taichi ＠ lab.ntt.co.jp>( Taichi KAWABATA ) wrote:

> 先週、IRGの会合に参加してきてみました。

> どうやって漢字決めてるのかなーと期待していってみたんですが、なんと、
> 広い会議室の中で各国代表の２０人くらいが、候補漢字を一つ一つプロジェ
> クタに出して、議論していくという不毛なものでした。何度も確認してもう
> 重複はないはずの漢字リストのはずなのに、中国とかはいまだに「直」とか
> を出して日本に訂正されたりして、いい加減です。どうも、自国の漢字しか
> 眼中になくて、包摂対象となる日本の字形なんて知らないみたい。

らしいですね。

> 例のExtension-Bの重複騒動も宣なるかな。

川幡さんのお楽しみのネタが尽きずという訳ですね。:-)


> そこで「IDS使って漢字チェックやりましょうよ」と提案して、CHISEのを紹
> 介したんですが、割と賛同を得られました。やはり、部首・画数・起筆だけ
> で、漢字を特定するのにみなさん、限界を感じているみたい。画数も大騒動
> で、例えば「りっしんべん」を３画とするか４画にするかでマカオがもめる
> し。

素晴しいです。

> そういう流れのなかで、IDSとして、CHISEのをサンプル提供しようかと思っ
> たんですけど、見直してみて、やはり冗長な所が多いなーと思いました。
> CDPフォントの図形なんかもあまり大っぴらにできないので、他のIDS置換で
> きるところはできるだけ置換したいし。

> IDSはその構造上、一つの漢字を複数の方法で表現できてしまうんですが、
> できるだけ曖昧さを防ぐ一つの方便として、「最小化」（できるだけ短くす
> る）を提唱しようかと思っています。そうやってCHISEのIDSを見ると、「な
> ぜこれがまとまってないの？」と疑問に思うような所が多いんですよね。合
> 成するにしても、IDSでは文字の繋がりまではちゃんと表現できないので、
> 可能な限り、すでにある大きめのコンポーネントを多用した方が良いかと思
> うのです。

このあたり、はじめた頃から論点として挙げてた問題ですが、未だできてなかっ
たりするのが(^_^;;;

それはともかく、CHISE にとっての漢字構造情報の多用途性を鑑みると、最小
化方法として、少なくとも

・字源的最小化
・視覚的最小化

が考えられます（ex. 旗）。両者とも厳密に定義するにはいろいろ突っ込みど
ころはあると思いますが、とりあえず、視覚的最小化とは、なるべく左右上下
に並ぶようにすることとしましょう。

また、この両者に対し、部品をどの程度 unify するかの方法が組合わさると
いえます。

ところで、任意の IDS に対し、指定した方法で正規化するアルゴリズムが存
在すれば良い訳ですが、字源的最小化は heuristics はあるとしても、本質的
には無理だといえます。一方、視覚的最小化の場合ある程度可能なのではない
かと思われるので、それを定義すると良いなあと思います。

また、視覚的最小化が可能であるなら、より情報が多い字源的最小化 IDS で
マスターを保持するのが望ましいと考えられます。

そういう訳で、私としては CHISE-IDS のデータは字源的最小化 IDS にしたい
と思います。

なお、部品の unification に関しては、部品の文字定義に従って、例えば、
Unicode に正規化することは基本的に容易です（著しく違うもの、IDS 的に異
なるものを unify してる場合に、それを考慮するのはちょっと面倒です。で
も、不可能ではないといえます）。


> そういうわけで、今、少しずつ、

> cat IDS-UCS-Basic.txt IDS-UCS-Ext-A.txt IDS-UCS-Ext-B-* > ids.txt

> として作ったファイルに対して、最小化処理を施しています。その過程で、色々
> とバグも見つけたので、それも可能な限り修正しました。

-------------- next part --------------
U+4EAD の場合 ?亠口冖 が「高」の省略形、U+4EAE の場合 ?亠口冖 が
「京」の省略形と考えられます。どっちも元は高い建物だといえるので、
?亠口冖 は意味のある単位になっており、また、『はしご高』形態になった
場合、視覚的最小化した場合、こういう切れ方をするといえるので、これを
??亠口?冖x にしない方が良いと思います。
-------------- next part --------------

U+4EB5 のような例は賛成です（?衣? にすべきなのかも）。

-------------- next part --------------

U+4F7E のような場合ですが、IDS-UCS-*.txt に関しては、

・Unicode 例示字形（Ext-B は ISO 例示字形）を表現する
・部品が =ucs ＠ unicode 素性もしくは =ucs ＠ iso 素性を持つ時、=ucs を持つ
  親（ないしは先祖）部品(*1) を用いる

としたいと思います。

(*1) <-denotational 素性、もしくは、<-subsumptive 素性を手繰って、文字
     の抽象-具象関係の木を順番に根本に辿った時に見つかった、最初に
     =ucs 素性を持った文字

そういう訳で、このような例は賛成です。

-------------- next part --------------

こういった観点から鑑みて、大部分は賛成できます。


> 今後も、どんどん直していく予定ですが、できるだけそちらの作業とシンクロ
> を取りたいので、宜しければ、そちらのファイルにも以下のパッチを適用して
> 頂きたく、検討を宜しくお願いしたいのですが、よろしいでしょうか？。

> 無理ならこちらでブランチとして管理していきたいと思います。宜しく考慮の
> 程、お願いします。

賛成できない部分に関して、私としては、川幡さん的に望ましい IDS 正規化
アルゴリズムを提案してもらって、マスターから自動生成できるようにするの
が望ましいと思いますが、cvs.m17n.org:/cvs/chise の ids module に枝を作
るのもありだと思います。

;; CHISE-DB for WWW みたいなサービスをなるべく早く用意したいと思ってい
;; る今日この頃です。

もちろん、ポリシー的に問題ない部分に関してはなるべく共有したいと思いま
す。また、ブランチする場合も、cvs.m17n.org:/cvs/chise の ids module に
作る方がうれしいです。

という訳で、いかがでしょうか？

-- 
┯━…‥・懐かしい未来の記憶をふと思い出しかけた・‥…━━┯━━━┯━
││ ─ │  ─  ／    ─   ┼─     ┬                ─   ─┼ ┬┴─
┼┼─┼|〓━─┼ 守岡 知彦 (MORIOKA Tomohiko) <tomo ＠ m17n.org> ─ ─┬
┻┻━┻━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━━━