名前問題

2002年 12月 10日 (火) 16:39:00 JST

>>>>> In [chise-ja : No.00075] 
>>>>>	"g新部さん" = NIIBE Yutaka <gniibe ＠ m17n.org> wrote:

g新部さん>  > XEmacs UTF-2000 → XEmacs + libchise = XEmacs/CHISE

g新部さん> 「XEmacs を libchise に載せるのは難しいかも? 」 という声が
g新部さん> あったと思います。XEmacs/CHISE は libchise の API は持つが, 
g新部さん> 現在の実装を(しばらくは)そのままというのも妥当だろうと。

今の XEmacs/UTF-2000 実装は XEmacs の char-table や database 機構の
code を利用したり密接な関係を持ってたりするので、libchise でこの方面に
独自実装を持ち、そっちで XEmacs/UTF-2000 を書き直すとなると、今まで以
上に XEmacs 本家との距離が開きます。私としては、ある程度の時点で
XEmacs/UTF-2000 を本家に feedback したいと思っているので、当面は code
の差があまり大きくならない方向で作業したいと考えています（但し、実際に
はさらに整理作業が必要だし、また、patch を送っても reject される可能性
もあります）。もし、将来、全てが順調にいって、XEmacs community の理解
が得られるか、逆にすっかり決別して(^_^;; という自体になった時に、
libchise で書き換えることはあるかも知れませんが、それなりに労力もかか
るので当面はこの件は見送りたいと思います。

g新部さん> それから, 思い出しつつ, WiLiKi に書いていこう(それで固まっ
g新部さん> たら cvs.m17n.org へ)と思いますが, Tomoyo は別のプロジェク
g新部さん> トだったと記憶しています。

g新部さん> UTF-2000 は最初, 以下のような話から始まったと思います。

g新部さん> 	o 符号化文字集合の寄せ集めとしての Mule ってどうでしょ
		  うか?
g新部さん> 	o 符号化文字集合の寄せ集めとしての Unicode ってどうで
		  しょうか?
g新部さん> 	o 文字の集合は文字の集合として, 文字は文字のオブジェク
g新部さん> 	  トとして,エンコーディングはエンコーディグとして扱い
g新部さん> 	  たいものだ。

g新部さん>      ===> 文字オブジェクトを扱うこととし, 内部エンコーディ
g新部さん>      ングはそれとは独立に UTF-8 のマルチバイト表現を用いる。
g新部さん>      符号化された整数値と文字オブジェクトとの間の対応関係を
g新部さん>      別に管理する。
g新部さん> 	.... GNU Emacs UTF-2000 試験実装 (1998) 

g新部さん> それで, そこから XEmacs UTF-2000 の実装へと進み, 文字オブジェ
g新部さん> クトとしてあつかう属性のデータ整備が始まりました。

g新部さん> CHISE モデルの文字オブジェクト(弁別可能な属性の集合)に必要
g新部さん> とされるものは, おそらく現在の XEmacs UTF-2000 の枠組みより
g新部さん> 広いと思います。

その通りです。また、文字（オブジェクト）の性質を扱う UTF-2000 のコンセ
プトから、文字や文字属性間の関係の集合を扱う文字知識データベースのコン
セプトに発展して来ています。

g新部さん> XEmacs UTF-2000 では, CHISE の枠組みから見れば, まだ, 文字
g新部さん> オブジェクトの扱いに関して, 十分な設計がされ, 実装されてい
g新部さん> るというわけではありません。

試行錯誤しながらやって来たので、そろそろ一度概念を整理して、再設計すべ
き時に来てるといえます。

g新部さん> XEmacs UTF-2000 では, 文字オブジェクト中心なので, 文字オブ
g新部さん> ジェクトは固定のものです。あるコンテクストでは, 別の弁別可
g新部さん> 能な属性が浮かび上がってくるというようなのは扱えません。
g新部さん> 文章の中で文として単語として使われてくるなかで, 初めてその
g新部さん> 弁別可能な属性が見えてくるというようなのが扱えません。これ
g新部さん> を扱いたいものだということで, 文字オブジェクトの(動的な)多
g新部さん> 義性を扱う仕組みを与えるもの tomoyo だったような気がします。
g新部さん> ちがったっけ?

XEmacs UTF-2000 は文字の性質を動的に変更する機構を持っており、文字オブ
ジェクトは固定のものではないです。とはいえ、現実には非常に不十分という
か全くもって不十分です。

また、Mule や XEmacs UTF-2000 や多くの Unicode 実装はある text stream
を読み込んだ時点に内部表現に変換しますが、その点についての不満がありま
した。UTF-2000 モデルの視点では、text stream から符号化文字列ないしは
文字オブジェクト列への変換は、code が表す意味を解釈し、曖昧性を解消し、
ひとつの文字オブジェクトで代表させるという乱暴!?な処理です。とするなら、
それを静的に一度にやるのはあんまり良い事ではなく、なんらかの処理のため
に解釈が必要になった時にはじめてその状況に応じて行う方が良いという考え
が浮かびます。で、それをやろうというのが TOMOYO (1) ですし、Ruby の多
言語化の話が出て来た時にそういう話を押し込みたいと思ったのですが、うま
く行きませんでした（当り前だけど）。

ところで、CHISE project の構想が出たのは m17n-2001 が最初だと思います。
この発表資料は後で WWW 頁の方に置いておきます。

これによれば、

・CHISE (CHaracter Information Service Environment)
	character information server

・TOMOYO (Text Object Manipulator and Outfit for YOurself)

ということで、CHISE が server およびデータベース、TOMOYO が client 
（つまり、XEmacs UTF-2000 の後継）みたいです。また、

Plan of 知世 (CHISE)

(1) private character database
	based on dbm like simple database

(2) local character database server
	(based on PostgreSQL?)

(3) distributed server system
	- How to sync
	- Check conflicts and report

Plan of 知世 (TOMOYO)

(0) Complete UTF-2000
    (a) complete XEmacs UTF-2000
		and send MEGA patch
		to xemacs-patches :-)
    (b) implement GNU Emacs 21 UTF-2000

(1) Multiple representation in one system

(2) Character definition editor

(3) Network representation

Related Plan

・Develop high quality character data
	not depended on any character codes

・Integrate glyph, shape and type setting information
	into the character database system

・Searchable image based document database
	(especially for classical Chinese documents,
		such as 拓本, 稀覯本)

なんてことが書いてあります。今の実装、概念、計画等でいえば、

CHISE (1) は XEmacs UTF-2000 の外部データベース機能 → libchise 構想

CHISE (2) はなかなか前に進まない PostgreSQL ベースの文字データベースサー
	  バー構想。2001年度未踏では別に TopicMaps サーバー構想があり
	  ましたが、現在では TopicMaps サーバー構想と一体のものとなっ
	  ていて、現在、主に Wittern さんが作業中です。
	  PostgreSQL/CHISE 構想は私と Wittern さんの間では盛り上がって
	  いるものの、CHISE Project 主流派の間では却下の声多し。

CHISE (3) は今の所手つかずです。私と Wittern さんは PostgreSQL ベース
	  のものをイメージしてますが、最近では libchise をベースにすべ
	  しとの声が強くなりつつあります。

TOMOYO (0-a) は char-table/syntax-table との統合は成ったものの、正規表
	     現は未だ成らず。また、pdump 問題もあり。政治面は手つかず。

TOMOYO (0-b) は未だ手つかず。

TOMOYO (1) も未だ手つかず。TOMOYO (0-b) の中でやることを考えていたみた
	   いだけど、今なら libchise の中でやる方が良いかも。やるとす
	   ればだけど。

TOMOYO (2) も未だ手つかず。ただ、私の気持上の親戚筋としては、視覚化プ
	   ロジェクトが始動中。

TOMOYO (3) は多分、TEI P5 & TopicMaps に結実すると良いなあと思ってます。
	   また、CHISE-Ω がらみで LaTeX ベースの文字参照・定義形式や
	   書記系定義みたいなのを作ることになるかも。

RP (1) は果てなき道ですね。2001 年度には漢字構造情報データベースが登場
       しました。他にも発音関連データの整備が必要ですが、ちゃんとやる
       には音韻学や音韻史に詳しい人の助けが必要な所です。字義記述に関
       しても手つかずで、まず記述に関する基礎研究が必要でしょう。

RP (2) に関しては KAGE と CHISE-Ω のプロジェクト参加があり、今年度か
       ら急速に進みそうな感じです。

RP (3) は今の所 CHISE プロジェクトとは別ですが、SVG ベースで細々とやっ
       てます。また、大阪大学の坂内先生と共同で説文解字繋伝の SVG によ
       る画像マークアップの実験をやってます。このデータベースは CHISE
       の文字データベースと統合したいと思ってます。

という感じだと思います。

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