distance

[守岡 知彦 / MORIOKA Tomohiko]

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

江渡さん> > えっと、一応、今回は UTF-2000 じゃなくて、その次に来る文字
江渡さん> > データベース・システムを核にしたいんですけども、開発が遅れ
江渡さん> > てて申し訳ないです。

江渡さん> まだ「UTF-2000」と「その次に来る文字データベース・システム」
江渡さん> の区別もついてないという状態です。用語法も理解してないという
江渡さん> 状態ですが、よろしくおねがいします。

補足というか、余談なんですが、私としては

UTF-2000:	モデルの名前
XEmacs UTF-2000: 実装の名前

で使い分けるように心がけてたんですが、私も含めてしばしば「UTF-2000」で
「XEmacs UTF-2000」を指すことがあって混乱してたと思います。

UTF-2000 モデル自体は文字オブジェクトをどう表現するかということには言
及してないものだと思うので、CHISE で目指しているデータベース・サーバー
に基づく環境と矛盾しません。

;; というか、UTF-2000 Project では目指してたような気がします。最初これ
;; をどうやるかを考えすぎてなかなか実装できなくて、これを後回しにして 
;; XEmacs UTF-2000 を作ったら案外実用になってしまって、なかなか外部デー
;; タベース化に移れなかったという経緯もあったり、にもかかわらず大風呂
;; 敷広げすぎて project が曖昧になったきらいがあると反省してます。

一方、CHISE project で目指しているデータベース・サーバーに基づく環境で
すが、ここで扱う文字データベースは UTF-2000 モデル的なものである必要が
ないと思っています。mapping table 的なもの（UTF-2000 モデルにおける単
一属性）や表、文字オブジェクト（define-char 形式、RDF 等）、RDB (SQL), 
階層構造 (TopicMaps 等), ネットワーク構造等の様々な view で情報をやり
とりできることが規模や目的の異なる各種アプリケーションにサービスを提供
する上で重要であると思っています。

そういう訳で、CHISE Project では文字表現モデルを UTF-2000 に限定すべき
ではなく、UTF-2000 を含めた各種モデルに対応すべきだと思っています。ま
た、この時、UTF-2000 を含めた各種モデル・形式間での対応をはっきりさせ、
なるべく roundtrip conversion が可能な枠組を作るべきだなあと思ってます。

PostgreSQL 化は理想的には、表および RDB 形式での文字表現モデルおよび形
式の開発と、mapping table との変換（自明）および define-char 形式との
変換手法の開発を含みます。ただ、あんまりシリアスにやると進まないので、
現行の define-char 形式に基づくものからでっちあげようという方針を考え
てます。

RDB と TopicMaps 化は Wittern さんに叩き台を出して頂けたら良いなあと思
いますが、今 TEI P5 の draft でお忙しいんですよね？ > Wittern さん


江渡さん> > CHISE のコンセプトは UTF-2000 以前に考えた、文字符号を前提
江渡さん> > としない文字処理を考えてみようという仮想実験に始まります。
江渡さん> > これはこんな思考の経過を辿りました：

江渡さん> これ読んで、だいぶわかってきました。

良かったです。

江渡さん> いろいろ話を聞いていて、ものすごくラジカルに違うんだろうなと
江渡さん> いうところまではわかったのですが、具体的にどう違うんだろうと
江渡さん> いうところがまだまったくわかってません。

「具体的」というのがどのレベルなのかが判らないですが、多分、ビット組合
せ・バイト列レベルには言及してないので、TRON みたいに独自のコードを作
ろうという話ではないはずです。

UTF-2000 モデルは文字符号化に関するもので、符号化文字モデルとの差異に
関して

http://www.kanji.zinbun.kyoto-u.ac.jp/projects/chise/papers/dc2000.pdf

とかで主張を行っています。

Wittern さんとか藤原さんは、多分、その上にある文字間の関係の表現とか構
造を問題にしていると思います。CHISE project における文字モデル化の焦点
のひとつはここにあります。これは文字符号とは違う層を見てるので、そもそ
も比べられないはずです。

江渡さん> おおざっぱに文字符号は、ファイルに保存する際の外部コードと、
江渡さん> メモリー内部で処理するための内部コードとがあると思うのですが、
江渡さん> ここで扱っている問題はこの区分でいうとそのどちらにあたるので
江渡さん> しょうか。それともそれを区別せずに議論しているということでしょ
江渡さん> うか?

XEmacs UTF-2000 に関していえば、こういう分類でいえば、内部コードを問題
にしています。

一方、CHISE Project では CHISE 環境全体を対象にすることになります。
（コード列も文字オブジェクトへのポインターとして解釈されます）

;; 内部と外部とかいうと、オートポイエーシスの概念が頭をよぎったりして、
;; つい「内部も外部もない（入力も出力もない；システムに外部はない）」
;; とか言いたくなっちゃうんですが、文字符号化の歴史（を含めた文字表現
;; の歴史）を見れば、そういう側面は多々あったと思います。つまり、『内
;; 部表現』として導入されたものは大抵それに留まらず『外部』との情報交
;; 換にも使われてきたと思います（例：シフト JIS）。また、Shift_JIS で
;; 符号化された XML 文書中の文字の XML 層での解釈は JIS X 0208:1990 で
;; はなく Unicode で行われ、その文書が表現する文字は Unicode のものと
;; は限らない、とか、Internet の mail 形式では STD 11 層では全てが
;; US-ASCII で解釈されるが、MIME 層では同じものが MIME-charset によっ
;; て様々な符号で解釈される、というように、メタ・ベース言語とか「表さ
;; れるもの」と「表すもの」は必ずしも一致しないという形式言語や記号の
;; 一般的な性質は文字表現でも当てはまります。その点でも、「内部コード」
;; 「外部コード」というのはちょっといまいちかなと思います。言い替えに
;; 過ぎないかも知れないけど、「シリアライズ」とかいう方が個人的には好
;; きです。

なんだか長々と脈絡なく書いてしまった気がしますがこのへんで。

かえって混乱させちゃったらごめんなさい。
-- 
===『幾千億の分子に分かれても ========================================
     決して忘れない。    
     この宇宙が終るまで』              守岡 知彦 (MORIOKA Tomohiko)
====================== Email: <tomo ＠ kanji.zinbun.kyoto-u.ac.jp> ======