朝日文字について

[守岡知彦 / MORIOKA Tomohiko]

>>>>> In [utf-2000 : No.00334] 
>>>>>	"江渡さん" = Kouichirou Eto <2003 ＠ eto.com> wrote:

江渡さん> 守岡さんのメールにあった朝日文字についてちょっと考えてみたの
江渡さん> ですが、UTF-2000モデルの原理的に考えると、文字について問題が
江渡さん> ある場合は、全てその問題を解決可能とするべきだと思います。つ
江渡さん> まり朝日文字についても、変換可能であるのならば、変換の手段を
江渡さん> 提供するべきだと思います。

私もそう思いますし、多分、師さんもそのつもりじゃないでしょうか。

私がここで対象にしてるのは XEmacs UTF-2000 とか libchise に附属するよ
うな文字データベースの基本セットについてです。私は、この種のものは多く
の人が使いそうな辞書的な性格のものになるのではないかと思っています。そ
して、その範囲をどうするのが良いかということです。

XEmacs UTF-2000 にせよ libchise にせよ、文字定義の拡張可能性は当然の前
提なので、もし基本セットに収録しないとしたら、後付けすることになります
（例えば、現状では CHISE-ids database はそうなってますよね）。


江渡さん> もともと文字について様々な問題が山積みになっていて、そういっ
江渡さん> た問題に小手先の対処を積み重ねても本質的な問題解決にならない
江渡さん> という認識からUTF-2000モデルが生まれたわけなので、つまり文字
江渡さん> についての問題があるのならその問題は全て解決する、というのが
江渡さん> 理想的な方向性なのだと思います。

UTF-2000 モデルは理想的なものではなくて、現実的な第一歩として構想した
ので、この経緯は私の認識とはちょっと違いますが、それを指向するのは良い
と思います。

但し、「フレームの問題」という知識処理上の法則?が存在しているので、理
想の追求には時間計算量か空間計算量の爆発という壁が待ち受けていると思い
ます。

江渡さん> もし合意可能な文字集合だけを対象とすればいいのなら、わざわざ
江渡さん> 文字データベースのような高コストの手法を採用する必要はない。

おっしゃる通り、UTF-2000 モデルは合意可能な文字集合だけを対象にするの
をやめて、自由に文字を使えることを目指して作ったものです。ただ、私はこ
れを高コストなものとは思っていません。時間計算量のオーダーは符号化文字
モデルと同じにできるはずで、十分にうまく実装すれば速度的問題はないはず
です。また、『全ての文字の全ての性質』を収録したデータベースを作ろうと
したらサイズが爆発するでしょうが、あるテキストで使う文字・性質の集合は
十分な局所性を持つとすればうまく行くはずだということがいえます。
Unicode でも気の効いた処理をするにはデータベースが必要で、その点でもコ
ストは同等だと思っています。

もちろん、データベースを作るための人的コストは高いです。でも、これは文
字集合を作る人が引き受けて来たコストです。UTF-2000 モデルは、この点で
もデータの品質が揃ってなくてもそれなりに処理できる枠組を提供可能である
と思います（というか、データの品質を表現・処理対象にできるというか）。


江渡さん> しかし現実には私達のリソースは限られていて、全ての問題を一
江渡さん> projectの範囲で解決できるはずもない。そこでやはり文字データ
江渡さん> ベースに委譲のような仕組みを導入するのがいいんじゃないでしょ
江渡さん> うか。朝日文字のようなデータを取り込みたい人がいたら、自分で
江渡さん> そのデータベースを作って、MIX-INして使えるような仕組みを提供
江渡さん> する。

そう思います。現状の XEmacs UTF-2000 では複数のデータソースが使えない
ので、文字データベースを書き換える必要がありますが、当初の予定では複数
のデータソースをサポートする予定だったので、これはいずれ実装したいと思っ
ています。

また、現状でも XEmacs UTF-2000 では実質的にそうしたことができていると
思います。


江渡さん> また同時にできればネットワーク透過のメカニズムもあるといいと
江渡さん> 思います。そういうったデータベースをネットワーク上でなんらか
江渡さん> の形で公開しておくと、他のプログラムからも透過的にそれを利用
江渡さん> できるようになるとか。

これも予定では 2001 年度にできてるはずだったんですよね。うぐぐ。でまあ、
そのために PostgreSQL を使おうとしてた訳ですが、これはあんまり受けが良
くないんですよね。Wittern さんの実装がそれなりのパフォーマンスで動いた
ら他もやるにせよ PostgreSQL 系実装もありにしたいなあと思ってるんですが。

他にも LDAP も気になってます。でも、専用プロトコルの方が良いかな？

いずれにせよ、複数データソースをサポートするのが先かなと思います。


江渡さん> ただ一番問題なのは、解決の手法を提供することができたとしても、
江渡さん> そういった問題が存在すること自体を知らない場合はどうしようも
江渡さん> ない、ということ。

江渡さん> 例えばある朝日文字を入力したいとして、でも当然文字が無いから
江渡さん> 入力できない。

江渡さん> 朝日文字とは朝日新聞が勝手に作った省略字形だから、文字コード
江渡さん> 表の中には存在しない。しかしその人は、それが朝日文字だとは知
江渡さん> らないので、その文字自身を入力しなくちゃいけないと思い、悩む
江渡さん> わけです。この場合、朝日文字というデータベースをMIX-INすると
江渡さん> その文字が使えるようになるというメカニズムを提供したとしても、
江渡さん> その人がその入力したい文字が朝日文字なんだよというのは事前に
江渡さん> 知ってなくちゃいけない。この問題だけは解決できないですね。

;; 知識データベース（ナレッジベース）... ぼそ。


江渡さん> > ちょっと細かいですが、字形は時代よりもむしろメディア（筆記
江渡さん> > 具とか）への依存度が強いので、所謂「旧字」は、文字通り「古
江渡さん> > い字（形）」という意味ではなかったりします。
江渡さん> > 
江渡さん> > 守岡さんの「<-simplified-ideograph」という属性のつけ方は、
江渡さん> > 新字・旧字に付随する時間性を排除する意図があるのではないか
江渡さん> > と、勝手に思っていたりします。

むしろ画数増えてるものとかもあるので、<-simplified-ideograph というの
もいまいちかもという気もします。<-authorised-ideograph というのも『新
字・旧字』関係にはそぐわない気もするし、<-modern-ideograph というのも
時間性を想起させて良くないと思いますし。

ところで、漢字は時間軸に沿って書体が変化して来たとなんとなく思いがちな
んですが、どうもそうじゃないみたいなんですね。ある書体がどの時代まで遡
れどの地域で発生したというようなことは言えても、甲骨文字とかを除けば、
その書体が発生した移行はずっとその書体は維持・改良され続けるということ
が多いようで、その点では古代文字や過去の文字にはならず、現在に生きてい
る書体の一種になってしまうようです。例えば、篆書はその１例で、戦国時代
の秦地方（割と辺境）に存在した大篆を簡略化した小篆に起因し、秦の始皇帝
が標準書体として中国全土に押しつけて現在に至るという感じみたいです。文
字学者が字説に合うように字形を変えたり、書家がかっこよくデザインしたり
して変化したり、しなかったりという感じだそうで。

江渡さん> そうですね。問題が深いというのはよくわかりました。
江渡さん> 私が言っていたのはいわゆる常用漢字、当用漢字のレベルを意図し
江渡さん> ていました。どこかのある時点で、明確に規定できるような形で意
江渡さん> 図的に変化が導入されたのならば、その変化情報そのものを扱える
江渡さん> のではないかと思ったのです。

比較的、明確に規定できるもの、オーソライズされた標準書体に関してはいえ
ると思います。歴史上オーソライズされた標準書体と言えそうなのは、篆書、
隷書、康煕体、現代の簡略字かなと思います。この中で多分、一番ドラスティッ
クな変化は篆書から隷書への変化でしょうから、これをうまく書けたら良いな
あと思うんですが、その前にいろいろ勉強しないとまずそうなので大変そうで
す。

-- 
守岡 知彦 (MORIOKA Tomohiko) <tomo ＠ kanji.zinbun.kyoto-u.ac.jp>