２つ公開しました

[守岡知彦 / MORIOKA Tomohiko]

>>>>> [chise-ja : No.00540] にて
>>>>> "KAMICHI, Koichi" <kamichi ＠ fonts.jp> さま曰く:
> 
> なんか名前と関連字がごっちゃになっているような気もしますが、重要なの
> は関連字です。

> > 隷定字とか合文とかではしばしば UCS に対応しなかったり（合文の場合、
> > 文字列には対応するかも知れないけど）、何に対応するか不明なものが出
> > て来るので、IDS 風な命名もできると良いかなと思います。
> 
> グリフへの命名は自由ですよ（といいながら英小文字と数字とマイナスだけ
> ですが）。ですので、かつてのkageの部品名のようにu2ff0-u4e00-u4e02の
> ようなグリフ名も付けられます。

自由に付けれるというのは微妙で、自動割当して隠蔽するか、意味のある命名
規則を定めるかのどちらかが良いと思います。


> グリフにつける名前は、あくまでDB上で同時に区別できるグリフ識別子であっ
> て、検索に用いるつもりはあまりありません。今はucsベースの名前のグリ
> フがほとんどですが、いずれは引用元や機関名、文献名などに数字をくっつ
> けたような名前が増えることを想定しています。名前を勝手に付けられるの
> で、その代わり関連字のほうを制約をつけて検索に用いるということになり
> ます。

http://glyphwiki.org/wiki/Special:Search?search=字

みたいに参照すれば言い訳ですね？

関連字にメタデータが付いて、それを使って検索できたら良いですね。

> UCS１字をあてて検索の便を図る目的の「関連字」は、無節操になるのがい
> やだったので、ひとまずUCS1字にしましたが、部品関係のグリフでUCSに
> 対応できないものの扱いに困っています。合字もそうです。
> 
> IDSというのは一つの解だと思いますが、一般にはちょっと複雑ですね。部
> 品列挙でもいいのかもしれません。理屈で言えばIDSでも表現できないもの
> がありますよね。

その他オペレーターを使えば、何でも表現できますが、悲しいですね。(^_^;

> ところで合字、合文で３字以上が組み合わさっているというサンプルは沢山
> あるのでしょうか？

;; 合文の長さ毎の甲骨文字数
(let (dest mcl ret len)
  (map-char-attribute
   (lambda (char val)
     (when (setq mcl (char-feature char '<-Oracle-Bones))
       (dolist (mc mcl)
	 (setq len
	       (if (setq ret (char-feature mc 'ideographic-combination))
		   (length ret)
		 1))
	 (if (setq ret (assq len dest))
	     (setcdr ret (1+ (cdr ret)))
	   (setq dest
		 (cons (cons len 1)
		       dest)))
	 ))
     nil)
   '=zinbun-oracle)
  (sort dest
	(lambda (a b)
	  (> (cdr a)(cdr b)))))

によれば、現状では、対応する現代字の情報を持つ 1098 文字中、

((1 . 820) (2 . 309) (3 . 43) (4 . 3))

で、現代字だと３字になるのが 43 文字、４字になるのが 3 文字とのことで
す。まあ、多いとはいえないですが、無視はできないかも知れないです。

;; 最終的には、この２倍強になるんじゃないかと思います。


> もう一つ考えていたのは、そもそもUCSというのは一般的な文字カタログの
> １つ、という意味合いで用いています。ですので、UCS以外の文字カタログ
> を利用するというのもいいのかと思います。たとえば甲骨文であれば、その
> 学会なり研究機関での附番カタログがありますよね。

現状では、甲骨文字に関する附番カタログの存在を知らなかったりします。
(^_^;

甲骨に関する附番カタログはあるんですが。

> それらはより実情を反映していると考えられますので、それを用いてもいい
> と思います。ただし、そうなると同じ文字と解釈できるものが記述方法が複
> 数存在してしまうことになります。

甲骨文字の場合、そもそもひとつのカタログ中で重複出現することがある
（説文部首ベースの場合）なので、複数の記述方法への対応は必須であると思
います。

> いくつかの文字カタログが利用可能で、１つの字を複数のカタログで表現可
> 能で、それらが同じ対象として結び付けられている…、ってchiseモデルで
> すね。

Chaon モデルであれば問題ないでしょうね。

alias といったのはそうしたことを想定してます。

つまり、decode-char や find-char みたいなことができたら良いなと思いま
す。

また、Unicode の JIS2004 例示字形とか GB 例示字形とかも指定できたらう
れしいです。


> ただ、ISO 10036もそうですが、グリフが重複してはならないわけではなく
> て、ユーザが自分の目的とする外字集合をグリフウィキで管理できることが
> 目的であり、その過程ですでに目的の字が登録されていればラッキーという
> 解釈もできます。反面グリフウィキは文字データベースの意味合いも狙って
> いますから、登録されているグリフ同士の関連付けはやはり必要ではありま
> す。

なんで、関連の種類（関連に関するメタデータ）は付けれた方が良いと思いま
す。

現状では、CHISE DB と１対１にリンクするには難があるように思えます。


> > また、こういう場合、後で UCS で符号位置ができたりするかも知れないので、
> > alias が付けられると良いなと思います。
> 
> 長い目で見た場合の関連字の動的な変化は、考える必要があると認識しています。
> 
> また、aliasは今計画中の状況です。alias先のグリフのバージョン変化をどう対
> 応させるかに悩んでいます。
> 
> http://glyphwiki.org/wiki/GlyphWiki:%e4%bb%8a%e5%be%8c%e3%81%ae%e3%82%b9%e3%82%b1%e3%82%b8%e3%83%a5%e3%83%bc%e3%83%ab#i1

何事もシステマティックにという教えに従えば、

素性名1=値1&素性名2=値2&...

のような感じに任意の粒度での指定ができたらうれしいと思います。


> > * 関連字
> > 
> > 甲骨文字に対する隷定字のような場合、そもそも何に関連するか謎なことは結
> > 構あると思うので、関連字が必須なのはちょっときつすぎる気がします（便宜
> > 的に適当なものを入れたら、結局、役に立たなくなる気が）。
> 
> 逆に、関連させないとして、その１つ１つを検索するときの手段というのは
> 何でしょうか。たとえば、出土場所や出土品に付けられた記号番号＋附番、
> などが想定されると思いますが、その情報が、すなわち先ほどの「カタログ」
> だと思うので、これを関連字として定義できる仕組みを模索しています。

Chaon モデルに基づくならば、素性（グリフのメタデータ）でしょうね。

ちなみに、出土品（CHISE DB での source 素性）はその一種だと思います。
なお、出土場所は、文字・字形の素性ではなく、出土品の属性だと思います。
ただ、そのリレーションを使って検索はできた方が良いとは思います。

;; もっとも、甲骨文字の場合、出土場所の情報はあんまり意味ないかも。


> > それから、オプションで良いので、関連の種類を入れられるようにして頂
> > けると嬉しいです（できれば、CHISE の関係素性と相互変換可能な命名規
> > 則を用いて頂けるとうれしい気がします）。
> 
> 本当は、グリフウィキのグリフ１つ＝chise-dbの文字オブジェクト１つ、と
> したいところですが、字形の分解能や関連付けの関連付けの次元の違いによ
> り完全に同期を取るのは難しいと思います。なんとかくっつける方法を考え
> たいところです。なぜくっつけたいか、というと、文字データベースとして
> 備えるべき文字に対するメタ情報をchise-dbに肩代わりしてもらいたいと思っ
> ているためです。

思うに、究極的には CHISE DB と同様な Chaon モデル的な素性の集合として
参照できれば良いんですが、それをするとなると、CHISE DB と同様なものを
中に抱えることになりそうですね。あるいは、いっそ一体化すればすっきりす
る？(^_^;

それができないとすれば、多分、関連字による検索は CHISE が要求する水準
にならないような気がするので、結局、GlyphWiki の関連字とか検索機能は無
視して、CHISE DB に１対１対応するような命名規則を作って、名前で何とか
するしかないんじゃないかという予感はあります。

しかしながら、おそらく、モデル的には、Chaon モデルに基づき、文字素性で
はなく字形素性（ないしは、グリフ素性）を付けれるようにし、素性（の集合）
に基づく名前解決機構（検索の仕組み）を GlyphWiki が備え、CHISE DB にグ
リフ・字形素性との対応の情報を書くというのが、妥当なんじゃないかという
気がします。

;; 文字素性としては必要でも、グリフ素性・字形素性にはなり得ないもの
;; （その逆も）はあると思うので。


> ローカルな話で恐縮ですが、かつて、「フォントに関心のある人は多いけど、
> 実 際に作成するほど手を動かしてくれる、そして、センスのある人はなか
> なか集まらないだろう」という話がありました。ということで、グリフウィ
> キもまだ公開したてではありますが、苦戦すると思います。どんなプロモー
> ションをすればよいかのアイデアがあれば教えてください…。その第1弾は
> 「じんもんこん」です。みなさん京都でお会いしましょう(^^;;

よろしくです。

;; もう来てらっしゃるのかな？

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