BSD/Linux Day開催案内
HOURIN Hiroyuki
開催直前の案内となりましてすみませんが、12月に開催されるInternet
Week 2003においてjusが主催する「BSD/Linux Day」のご案内です。当日申し
込みでも参加できますので、皆さんのご来場をお待ちしています。
======================================================================
BSD/Linux Day 開催のお知らせ
======================================================================
日本UNIXユーザ会は12月に開催されるInternet Week2003において、BSD及
びLinuxを中心とするオープンソースシステムに関する議論を行う場として
「BSD/Linux Day」を開催します。このイベントでは、参加者とともに活発
な議論を行い、オープンソースに関わる多くの人々の今後に有益な示唆を示
すことができればと考えております。皆さんふるってご参加ください。
最新情報はjusのWebサイト(http://www.jus.or.jp/)をご覧ください。また、
InternetWeek 2003については http://internetweek.jp/ をご覧ください。
◇◆開催概要◇◆
主催: 日本UNIXユーザ会
日時: 2003年12月2日(火) 9:30～17:00
場所: パシフィコ横浜 303
〒220-0012 神奈川県横浜市西区みなとみらい1-1-1
http://www.pacifico.co.jp/
定員: 200名
参加費(通常料金): jus会員 4000円、一般 6000円、学生 3000円
対象者: BSDあるいはLinuxに関心のある人すべて
参加方法: 当日直接現地受け付け（パシフィコ横浜IW2003総合受付）にお越し
ください。
問合せ先: 日本UNIXユーザ会
E-Mail: off...@jus.or.jp
◇◆プログラム◇◆
1セッション90分(OS Updateを除く)、全部で4セッションを行います。
OS Updateを除く各セッションとも、前半はテーマに関する現状の説明(1件
につき10分以内、合計30分程度)、後半は参加者を交えた自由討論です。皆さ
んの発言で盛り上げましょう。
9:30-9:35 開会のあいさつ 法林浩之(日本UNIXユーザ会会長)
9:35-10:35 OS Update (Chairperson 湯川隆広(日本UNIXユーザ会/株式会社創夢))
・BSD系
FreeBSD 梅本肇(The FreeBSD Project)
NetBSD 蛯原純(株式会社創夢/The NetBSD Project)
OpenBSD 佐藤広生(東京理科大学)
KAME 山本和彦(IIJ)
・Linux系
Debian 鵜飼文敏(Debian Project)
Momonga 田淵貴昭(Momonga Project)
Gentoo 小町守(Gentoo Project)
USAGI 関谷勇司(USAGI Project)
BSDあるいはLinuxと言ってもその選択肢は多岐に渡り、どのOSやdistribution
を選択すれば良いか迷う場面も多いでしょう。また、BSDのみ、あるいは、
Linuxのみが紹介される場面はあっても、両方の紹介となるとあまり機会があ
りません。
このセッションでは、BSD系/Linux系のいくつかのOS/distribution
や、関連ソフトウェアについて、手短にその特徴や最新情報などの紹介を行います。
10:45-12:15 組み込みOS (Chairperson 坂下秀(株式会社アクタスソフトウエア))
・ 組み込みBSD 堀内岳人(株式会社ブレインズ)
・ 組み込みLinux 山口つかさ(IT-STEP)
・ その他組み込み系OS 宿口雅弘(三菱電機マイコン機器ソフトウエア株式会社)
家庭電化製品等に搭載されるコンピュータソフトウェアは従来さまざまな制
約により専用ソフトウェアが用いられて来ましたが、ハードウェアの進化や、
ネットワーク接続の必要性などからunix系のOSが用いられる場面も増えて来
ています。
このセッションでは、いくつかの組み込みOSを紹介し、必要となる要件や現
状、展望に関して議論します。
12:15-13:30 お昼休み
13:30-15:00 日本語入力(Chairperson 太田純(株式会社リコー))
・ATOK 藤吉誠(株式会社ジャストシステム)
・POBox 増井俊之(独立行政法人 産業技術総合研究所)
・DixChange 野首貴嗣(DixChange Project/凸版印刷株式会社)
・libAgent: 市村元信(OpenI18N.org/Momonga Project/早稲田大学)
オープンソースシステム利用が進む中で、特にエンドユーザ用アプリケーショ
ンにおける正確で使いやすい日本語入力環境が求められています。
このセッションでは日本語入力の使い勝手に大きな影響を与える日本語入力シ
ステムについて、それぞれ方式の異なるいくつかの入力システムに関する特徴・
現状の紹介を受け、より正確な日本語・人名等を入力するために求められる条
件等を議論します。
15:10-16:40 次世代OS～beyond UNIX～(Chairperson 砂原秀樹(奈良先端大))
・中島達夫(早稲田大学)
・松本尚(国立情報学研究所)
モバイル、マルチメディア、グリッドコンピューティングなど、当初UNIXが想
定していた役割とは異なる役割がオペレーティングシステムに求められて来て
います。そのような観点から、次世代のオペレーティングシステムについて考
える時期に来ていると言えるでしょう。
このセッションでは、中島氏に次世代オペレーティングシステムに求められ
る機能とオープンソースコミュニティの役割について述べていただき、松本氏
に次世代オペレーティングシステムの一つの例としてSSS-PCについて紹介して
いただきます。
16:40-16:45 閉会のあいさつ 法林浩之(日本UNIXユーザ会会長)
司会: 法林浩之(インターネット総合研究所)
記録: 能城茂雄(奈良先端大)、太田敏文
===============================================================================
[名前] 法林 浩之 (ほうりんひろゆき) [本頁] http://www.suplex.gr.jp/~hourin/
[住所] hou...@suplex.gr.jp (生活) / hou...@ico-g.com, hou...@iri.co.jp (会社)
「こんな簡単な作業、朝飯前ですよ」「じゃ朝飯まで続けてくれ」「今22:30なのに…」
===============================================================================
Ken Tikarano
# 太田さんお疲れ様でした。
Unixの日本語入力をよくするにはどう瘢雹すればという瘢雹話かと
思っていたのですが・髟阡・・嗚・ぢマンセ・踉・・・ぢ俺様の入力スタイルはこう瘢雹だの
発表会になってしまいましたね。
フリ・踉擦瞭?楔貽・呂悩蚤腓量簑蠅櫓踉鮫書の貧・・紊気世隼廚・逅擦里任垢・・・・
そう瘢雹いう瘢雹議論はう髟阡擦陸苳詞では無理でした。
ところでフリ・踉擦瞭?楔貽・呂箸い・逅擦漠・綜・・ぢは欠かせないと思う瘢雹のですが・髟阡・・w)本人が来ているのにもかかわらず代理発表という瘢雹のは物足りないはなしです。
まう髟阡仕槌サ瓩砲箸辰童・譴亟?鵬薪戮眛韻源・鮓世辰討い襪箸い・逅擦箸海蹐覆里任靴腓・逅擦・・・・
Anthyを出していれば・髟阡撒掴世諒・・發發・逅殺苳晒し前向きになっていたのではないかと。
なお・髟阡・・綜・・ぢは「AI変換」を・・・覆・箸皃踉斬験的にはサポ・踉札箸靴討い襪呂困任后・・w)ただ・髟阡札蹈献奪・世韻妊如・・タがないという瘢雹・・・屬任垢・・・・学習も出来るみたいです。
# 用語の問題からか?・髟阡参颱苳詞ではそこまでの話にはいきませんでしたが...
http://lists.sourceforge.jp/mailman/archives/anthy-dev/2003-April/000125.html
# 最後に・髟阡・・圻竢粤入力を初めて見ましたが・髟阡擦海・逅擦い辰討浪燭任垢・・・ぢ年間でう髟阡擦梁・戮漠・w)・いう瘢雹のはちょっと厳しいですね。ロ・踉札淹?・・ぢ王苳嗣・・漢字変換に対して・髟阡殺苳晒なくとも
# スピ・踉札斌未離瓮螢奪箸魎兇犬襪海箸呂・・・りませんでした。
# う踉擦匯妣苳殺髟阡擦箸茲个譴詈・瞭・呂鮓・燭な、任后・・w)w)?w)力野 健
tika...@geocities.co.jp
Junn Ohta
tika...@geocities.co.jpさんは書きました。
> BSD/Linux Dayの日本語入力セッションに参加してきました。
> # 太田さんお疲れ様でした。
力量のないチェアパースンですみません。(^^;
> Unixの日本語入力をよくするにはどうxxすればというxx話かと
> 思っていたのですがxxxマンセxxx俺様の入力スタイルはこうxxだの
> 発表会になってしまいましたね。
以降化け化けで読めませんでした。投稿しなおしていた
だけるとありがたいです。
--
太田純(Junn Ohta) (株)リコー/新横浜事業所
oh...@sdg.mdd.ricoh.co.jp
Ken Tikarano
> 以降化け化けで読めませんでした。投稿しなおしていた
> だけるとありがたいです。
以下、最初の投稿です。化けなければいいのですが...
-----
BSD/Linux Dayの日本語入力セッションに参加してきました。
# 太田さんお疲れ様でした。
Unixの日本語入力をよくするにはどうすればという話かと
思っていたのですが、SKKマンセー＋俺様の入力スタイルはこうだの
発表会になってしまいましたね。
フリーの日本語入力で最大の問題は辞書の貧弱さだと思うのですが、
そういう議論はあの場では無理でした。
ところでフリーの日本語入力というとAnthyは欠かせないと思うのですが、
本人が来ているのにもかかわらず代理発表というのは物足りない話です。
まあ田畑氏にとって見れば既に何度も同じ事を言っているというところなのでしょうが、
Anthyを出していれば、議論の方向ももう少し前向きになっていたのではないかと。
なお、Anthyは「AI変換」を少なくとも実験的にはサポートしているはずです。
ただ、ロジックだけでデータがないという状態ですが、学習も出来るみたいです。
# 用語の問題からか?、会場ではそこまでの話にはいきませんでしたが...
http://lists.sourceforge.jp/mailman/archives/anthy-dev/2003-April/000125.html
# 最後に、T-code入力を初めて見ましたが、こういっては何ですが3年間であの速度と
# いうのはちょっと厳しいですね。ローマ字+仮名漢字変換に対して、少なくとも
# スピード面のメリットを感じることはありませんでした。
# ぜひ師匠とよばれる方の入力を見たい物です。
Junn Ohta
tika...@geocities.co.jpさんは書きました。
> 以下、最初の投稿です。化けなければいいのですが...
こんどは大丈夫でした。何が原因だったのでしょう...。
> Unixの日本語入力をよくするにはどうすればという話かと
> 思っていたのですが、SKKマンセー＋俺様の入力スタイルはこうだの
> 発表会になってしまいましたね。
私がSKK嫌いのために:-)知識が足りず、逆にSKKの話題
を退けることができなくてあのような体たらくになっ
てしまいました。どうもすみません。というわけでこ
こで少し続けましょうか。(^^;
> フリーの日本語入力で最大の問題は辞書の貧弱さだと思うのですが、
> そういう議論はあの場では無理でした。
これだけ年月がたってもPubdicとPubdic+だけ、しかも
Pubdic+は狩野さんがあれだけ頑張ったにもかかわらず
満足のいく結果にはならなかったわけです。私の印象は
「それなりのお金を投入しないと無理だろうな」という
ものですね。
# たとえば陽の目をみないまま腐っているWXGをどこか
# が買い取ってフリーにしてしまう、とか...。
> ところでフリーの日本語入力というとAnthyは欠かせないと思うのですが、
> 本人が来ているのにもかかわらず代理発表というのは物足りない話です。
> まあ田畑氏にとって見れば既に何度も同じ事を言っているというところなのでしょうが、
> Anthyを出していれば、議論の方向ももう少し前向きになっていたのではないかと。
jusからチェアパースンをやってくれという話がきたと
きに、準備の途中でAnthyの名前は出したんですけどね。
jusというコミュニティとあまり接点がなかったのでし
ょう。最近はどこででも開発ができるし、古くからのコ
ミュニティに参加するメリットはあまりないですから。
そういった意味で、BSD/Linux Dayのようなイベントも、
もっと広いところからさまざまな動きをすくい上げてく
る仕組みをもたないとだめかなあ、と思います。
個人的にはAnthyも評価してみたいとは思っているので
すが、いまのところ自分のふだんの環境では動かないの
で傍観してます。
> なお、Anthyは「AI変換」を少なくとも実験的にはサポートしているはずです。
> ただ、ロジックだけでデータがないという状態ですが、学習も出来るみたいです。
これについては、それこそデータがなければ何の意味も
ないというのが私の感覚なんです。頑張って作っている
人には申し訳ないんですけど、作るならまずデータ。ロ
ジックはそのあとでいい。ただしこれは個人ではまず無
理かなと。
> # 最後に、T-code入力を初めて見ましたが、こういっては何ですが3年間であの速度と
> # いうのはちょっと厳しいですね。ローマ字+仮名漢字変換に対して、少なくとも
> # スピード面のメリットを感じることはありませんでした。
ログ採りはある意味きびしいんですよ。自分がふだん使
うタームと違うものを入力しなければなりませんから。
自分で書きものをするときは能城さんもたぶんもっと高
速なんでしょう。ただ、それはそれとして、私も可能性
は理解しつつも自分ではやりたくない。(^^;
> # ぜひ師匠とよばれる方の入力を見たい物です。
前田くんは高速です。チャットのスピードで入力できま
すから。あれくらいだとローマ字入力より速いかなと実
感できます。
ただ、会場で増井さんがおっしゃっていた「SKKで入力
していたら漢字かな交じりのほうがひらがなだけ入力す
るより速くて自分でびっくりした」というのも見てみた
いです。私はまちがいなくひらがなのほうが速いですか
らね。
Hiroshi Fujishima
>>>>> tika...@geocities.co.jp (Ken Tikarano) wrote:
> フリーの日本語入力で最大の問題は辞書の貧弱さだと思うのですが、
> そういう議論はあの場では無理でした。
SKK の辞書はけっこう豊富だと思います。
http://openlab.ring.gr.jp/skk/dic-ja.html
http://openlab.ring.gr.jp/skk/registdic.cgi
http://openlab.ring.gr.jp/skk/registassoc.cgi
--
Hiroshi Fujishima
Hiroshi Fujishima
> ただ、会場で増井さんがおっしゃっていた「SKKで入力
> していたら漢字かな交じりのほうがひらがなだけ入力す
> るより速くて自分でびっくりした」というのも見てみた
> いです。私はまちがいなくひらがなのほうが速いですか
> らね。
個人辞書にある単語は TAB で補完できるからですね。
--
Hiroshi Fujishima
File: skk.info, Node: 見出し語の補完, Next: 見出し語を補完しながら▼モードへ, Prev: 見出し語関連, Up: 見出し語関連
見出し語の補完
--------------
▽モードで TAB を押すと、見出し語 (▽モードにおける入力文字列) に対する
補完が行われます。今、TABを押す直前に▽モードで入力された文字列をσと呼ぶ
ことにします。このとき、個人辞書 (1) の送りなしエントリの中で、先頭がσと
一致し長さがσよりも長い見出し語を捜して、そのような語がもしあれば、σの
代わりにその語が表示されます。
見出し語の補完を上手に利用すると、打鍵数を減らすことができます。
個人辞書では最近更新されたエントリほど上位に来るようになっています (2)
。したがって、▼モードで変換を行った語の見出し語について、時間的に新しい
ものから先に補完が行われます。例えば、`斉藤'、`佐藤' の順で変換した後、
`さ' をキーにして見出し語の補完を行うと、最初に `さとう' が、その次に`さ
いとう' が補完されます。補完が意図したものでなかったときにはTABの直後に
`.' (ピリオド) をタイプすると 2 番目の見出し語が表示されます。以降、同様
に `.' を続けてタイプすると、見出し語の候補が順次表示されます。意図した見
出し語を通りすぎたときは `,' (コンマ) で前の候補に戻ります。
S a t o u SPC C-j
------ Buffer: foo ------
佐藤
------ Buffer: foo ------
S a
------ Buffer: foo ------
▽さ
------ Buffer: foo ------
TAB
------ Buffer: foo ------
▽さとう
------ Buffer: foo ------
`.'
`さとう' の次に補完される見出し語は、個人辞書の内容に依存します。
------ Buffer: foo ------
▽さいとう
------ Buffer: foo ------
`,'
------ Buffer: foo ------
▽さとう
------ Buffer: foo ------
SPC
------ Buffer: foo ------
▼佐藤
------ Buffer: foo ------
C-j
------ Buffer: foo ------
佐藤
------ Buffer: foo ------
なお、個人辞書の検索は、見出し語を得るために行われるので、一旦SPC を入力
して▼モードに入れば普通の変換動作に入ります。
また、2回目以降の補完のときに、`.' の代わりに C-u TAB を入力すると、見出
し語補完の動作が変化します。具体的には、最初の補完キーを捨てて最後に補完
された語を補完キーとし、新しい補完を開始します。つまり上記の例では `さ'
に対し、最後に補完された語は、`さとう' なので、以後の補完は、`さとう' を
含む語 (例えば、`さとうせんせい'など) について行われます。
--------- Footnotes ---------
(1) 共有辞書は検索されません。それは、共有辞書では一般的に先頭の文
字を共通にする見出し語が多すぎて、望みの補完が行える確率が低いからです。
(2) *Note 辞書ファイルを指定する変数::
Junn Ohta
po...@nature.tsukuba.ac.jpさんは書きました。
> > フリーの日本語入力で最大の問題は辞書の貧弱さだと思うのですが、
> ...
> SKK の辞書はけっこう豊富だと思います。
おわかりだとは思うのですが、SKKの辞書には品詞情報
が含まれていないので、語数は多くてもほかの日本語入
力プログラムでは利用できません。SKKで使うにしても、
同音語のいずれを選ぶかの指針がありません。
なので、貧弱という評価を覆すほどのものではないと思
うのですが、いかがでしょうか?
Takao Ono
# SKK 使ってます.
<bqorc3$aek$1...@ns.src.ricoh.co.jp>の記事において
oh...@src.ricoh.co.jpさんは書きました。
ohta> > SKK の辞書はけっこう豊富だと思います。
ohta> おわかりだとは思うのですが、SKKの辞書には品詞情報
ohta> が含まれていないので、語数は多くてもほかの日本語入
ohta> 力プログラムでは利用できません。SKKで使うにしても、
ohta> 同音語のいずれを選ぶかの指針がありません。
SKK の辞書が他の日本語入力プログラムで利用できないというのは, 辞
書の評価としては方向がずれているような気がします. 本来「辞書」と
いうのは「その辞書を使う日本語入力プログラム」とセットで評価すべ
きじゃないんでしょうか?
# ちなみに, 今の SKK ならコメントの形で辞書に品詞情報を入れること
# ができます.
あと, 「同音語のいずれを選ぶかの指針」については, SKK ではシステム
が「どれを選んだらいいか」を判断することはないのでシステムに対す
る必要性はありません. ユーザに対する必要性だったらコメントで入れ
ておけばいいわけだし, そんなものを付けなくてもユーザが知っている
はず.
ohta> なので、貧弱という評価を覆すほどのものではないと思
ohta> うのですが、いかがでしょうか?
ちょっと「辞書に対する評価」なのかなぁと疑問を持ったもので.
--
名古屋大学大学院 情報科学研究科 計算機数理科学専攻
小野 孝男
Shinji KONO
In article <bqorc3$aek$1...@ns.src.ricoh.co.jp>, oh...@src.ricoh.co.jp (Junn Ohta) writes
> おわかりだとは思うのですが、SKKの辞書には品詞情報
> が含まれていないので、語数は多くてもほかの日本語入
> 力プログラムでは利用できません。SKKで使うにしても、
> 同音語のいずれを選ぶかの指針がありません。
品詞情報を入れなくて済むので語数が多くなるんですよね...
pubdic project ってのもあったんだけど、結構、間違いとかも
あって難しかったかなぁ。
> なので、貧弱という評価を覆すほどのものではないと思
> うのですが、いかがでしょうか?
まぁ、そうなんだけど... みんな日常的に変換しているわけだから、
それで自然に辞書が集まるようにするってのは割と良い発想なんで
すよね。SKKの辞書はそういう意味では良くできるんだけど...
---
Shinji KONO @ Information Engineering, University of the Ryukyus,
河野真治 @ 琉球大学工学部情報工学科,
Junn Ohta
ta...@hirata.nuee.nagoya-u.ac.jpさんは書きました。
> SKK の辞書が他の日本語入力プログラムで利用できないというのは, 辞
> 書の評価としては方向がずれているような気がします.
「フリーの日本語入力で最大の問題は辞書の貧弱さだと
思うのですが」に対して「SKKの辞書はけっこう豊富だ
と思います」という方向のずれた回答があったので、こ
ちらも同じ方向にずらして回答したのです。だからフォ
ローとしてはつじつまが合っているわけなのですが...。
> 本来「辞書」と
> いうのは「その辞書を使う日本語入力プログラム」とセットで評価すべ
> きじゃないんでしょうか?
互いの依存性が大きければそうですけど、そうでなけれ
ば(Pubdicのように)辞書そのものを評価してもまったく
問題ないと思います。
> # ちなみに, 今の SKK ならコメントの形で辞書に品詞情報を入れること
> # ができます.
そうおっしゃるけど、そのスペースにまともに品詞情報
を入れようという人はいないのでしょう? だったらここ
で言及するほどの意味はなさそう。
> あと, 「同音語のいずれを選ぶかの指針」については, SKK ではシステム
> が「どれを選んだらいいか」を判断することはないのでシステムに対す
> る必要性はありません. ユーザに対する必要性だったらコメントで入れ
> ておけばいいわけだし, そんなものを付けなくてもユーザが知っている
> はず.
誤解されたかな? 「同音語のいずれを選ぶかの指針」は
あくまでシステムに対する指針です。SKKでは辞書にそ
ういう指針はないし、あってもシステムが使ってくれな
い。なのでシステムはすべての同音語候補をユーザーに
提示するしかない。文法情報や意味情報を使う日本語入
力プログラムでは辞書にそういう指針があって、システ
ムはその指針を使ってあらかじめ絞り込んだ同音語候補
をユーザーに提示できる。そういうことです。
Takao Ono
SKK に限定した話にしちゃいました. ごめんなさい.
<bqp76s$dtt$1...@ns.src.ricoh.co.jp>の記事において
oh...@src.ricoh.co.jpさんは書きました。
ohta> fj.comp.input-methodの記事<0312051317...@flame.hirata.nuee.nagoya-u.ac.jp>で
ohta> ta...@hirata.nuee.nagoya-u.ac.jpさんは書きました。
ohta> > SKK の辞書が他の日本語入力プログラムで利用できないというのは, 辞
ohta> > 書の評価としては方向がずれているような気がします.
ohta> 「フリーの日本語入力で最大の問題は辞書の貧弱さだと
ohta> 思うのですが」に対して「SKKの辞書はけっこう豊富だ
ohta> と思います」という方向のずれた回答があったので、こ
ohta> ちらも同じ方向にずらして回答したのです。だからフォ
ohta> ローとしてはつじつまが合っているわけなのですが...。
ん～, 「フリーの日本語入力で最大の問題は辞書の貧弱さだと思う」っ
て解釈に難しい点があるような気がしますが....
「フリーの辞書が貧弱なのがフリーの日本語入力システムを開発する際
の問題である (もちろん他にも問題はあるけど)」という解釈と, 「現時
点で存在するフリーの日本語入力システムには辞書が貧弱であるという
問題がある (もちろん他にも問題はあるけど)」という解釈のどちらもで
きそうです, リテラルには.
ohta> > # ちなみに, 今の SKK ならコメントの形で辞書に品詞情報を入れること
ohta> > # ができます.
ohta> そうおっしゃるけど、そのスペースにまともに品詞情報
ohta> を入れようという人はいないのでしょう? だったらここ
ohta> で言及するほどの意味はなさそう。
御意. SKK というシステムには不要なものですし, 「SKK の辞書を他の
システムで使えるように整備する」という方向は (今のところ) 向いて
いないですから.
ohta> > あと, 「同音語のいずれを選ぶかの指針」については, SKK ではシステム
ohta> > が「どれを選んだらいいか」を判断することはないのでシステムに対す
ohta> > る必要性はありません. ユーザに対する必要性だったらコメントで入れ
ohta> > ておけばいいわけだし, そんなものを付けなくてもユーザが知っている
ohta> > はず.
ohta> 誤解されたかな? 「同音語のいずれを選ぶかの指針」は
ohta> あくまでシステムに対する指針です。SKKでは辞書にそ
ohta> ういう指針はないし、あってもシステムが使ってくれな
ohta> い。なのでシステムはすべての同音語候補をユーザーに
ohta> 提示するしかない。文法情報や意味情報を使う日本語入
ohta> 力プログラムでは辞書にそういう指針があって、システ
ohta> ムはその指針を使ってあらかじめ絞り込んだ同音語候補
ohta> をユーザーに提示できる。そういうことです。
あ, 「指針」がシステムとユーザのどちらに対する指針かはちょっと迷っ
たんですが, 文脈を考えるとユーザに対する指針ってのは変なのでシス
テムに対する指針だろうなとは解釈していました. 太田さんに誤解され
たとすれば, それは私の書き方の問題です.
それはさておき, 「SKK では... システムが使ってくれない」はちょっ
と誤解を呼ぶかも. SKK の設計思想からすれば, もっと積極的に「シス
テムは使わない」と言ってしまった方がよかったような気がします.
# 「辞書にそういう指針はないし, あってもシステムが使ってくれない」
# なので, 辞書が先に存在しているような雰囲気を感じました.
--
名古屋大学大学院 情報科学研究科 計算機数理科学専攻
小野 孝男
P.S.
どちらかというと「システムがあって, それに適した辞書を作る」じゃ
ないかな?
Junn Ohta
ta...@hirata.nuee.nagoya-u.ac.jpさんは書きました。
> 「フリーの辞書が貧弱なのがフリーの日本語入力システムを開発する際
> の問題である (もちろん他にも問題はあるけど)」という解釈と, 「現時
> 点で存在するフリーの日本語入力システムには辞書が貧弱であるという
> 問題がある (もちろん他にも問題はあるけど)」という解釈のどちらもで
> きそうです, リテラルには.
どちらに解釈しても原因のところは同じなので、あまり
区別しなくてもよいかな、と。(^^;
かつて岩波版Wnn辞書なんてのがありまして、それを入
れて賢くなるレベルになら、Pubdic+で到達できる可能
性はあったのですが...。
> それはさておき, 「SKK では... システムが使ってくれない」はちょっ
> と誤解を呼ぶかも. SKK の設計思想からすれば, もっと積極的に「シス
> テムは使わない」と言ってしまった方がよかったような気がします.
そうですね。その部分は訂正します。
> P.S.
> どちらかというと「システムがあって, それに適した辞書を作る」じゃ
> ないかな?
私の感覚では辞書が先。その辞書にあるどの情報をどう
使うかはシステムの勝手ですけどね。
まあ、たとえば「走る」という動詞があって、それをそ
のシステムではどういう内部構造で表現すれば効率的な
変換が可能かというあたりを考える余地はもちろんある
わけですが、どちらかといえば内部構造よりもその辞書
に含まれるべき情報量のほうが私にとっては重要である
わけでして...。
“AI”変換というとゴヘイがあったりしますが、それで
も共起情報を使って同音語の絞り込みを行う、またその
絞り込み結果を形態素解析に反映する程度のことは日本
語入力プログラムにやってほしいし、そのためには最低
限それが可能になる程度の情報が辞書にはほしいなあと
Takashi SAKAMOTO
BSD/Linux Day に参加しようと思っていたら、寝過ごした愚か者です。
"Ken Tikarano" <tika...@geocities.co.jp> wrote in message
news:d62eb3ef.03120...@posting.google.com...
> oh...@src.ricoh.co.jp (Junn Ohta) wrote in message
news:<bqk711$oqt$1...@ns.src.ricoh.co.jp>...
> フリーの日本語入力で最大の問題は辞書の貧弱さだと思うのですが、
> そういう議論はあの場では無理でした。
フリーの日本語入力を語る場合には、次の問題があると思うのです。
(1) 辞書の問題
(2) 変換エンジンの問題 (1 と切離せないかもしれない)
(3) UI の問題 (2 と切離せないかもしれない)
(4) UI とアプリケーションの間のプロトコルの問題
(5) アプリケーションの問題
私は (4) の問題、XIM の問題が大きいと思っています。
# Wnn には辞書サーバと UI の間のプロトコルがかなりやばいので
# 直せないかどうか freewnn を読んでたりします...
- XIM の spec は曖昧過ぎて読んでもサーバが作れない、
- 適切なサーバ及びクライアントのサンプルコード(reference sample)
が存在しない、
- Xlib に変なバグが残っている(いた？)、
(XIM server 側での input method の on/off とか)
結局、アプリケーションは何を基準にして良いのか分からないから
日本語入力は一つ一つに対して細かな修正を繰り返す羽目になる
のだ、と。
素人考えかもしませんが、そう思いました。
# 私は Wnn の変換効率は、辞書を問題にしないといけない程悪いとは思
# えないです。ぬるい使い方しかしてないのが問題なのかもしれませんが。
--
---
Takashi SAKAMOTO (PXG0...@nifty.ne.jp)
Junn Ohta
PXG0...@nifty.ne.jpさんは書きました。
> フリーの日本語入力を語る場合には、次の問題があると思うのです。
> (1) 辞書の問題
> (2) 変換エンジンの問題 (1 と切離せないかもしれない)
> (3) UI の問題 (2 と切離せないかもしれない)
> (4) UI とアプリケーションの間のプロトコルの問題
> (5) アプリケーションの問題
> 私は (4) の問題、XIM の問題が大きいと思っています。
(3)や(4)のあたりはIIIMFとかuimとかで改善されるので
はないかと思っていました。その方面はあまり詳しくな
いのですが...。
その方面で前進があったら
> # Wnn には辞書サーバと UI の間のプロトコルがかなりやばいので
このあたりもそれに合わせて修正していくことになるの
でしょうね。まあAnthyができてからWnnに手を入れても
コストに見合う結果が得られるかどうかはまた別の問題
でしょうけど。
> # 私は Wnn の変換効率は、辞書を問題にしないといけない程悪いとは思
> # えないです。ぬるい使い方しかしてないのが問題なのかもしれませんが。
「一階」と「一回」、「仕様」と「使用」、「書く」と
「各」あたりは文脈をみて出し分けてほしいですよね。
そうなるとWnnやCannaではちょっとヌルい...。
Junn Ohta
ko...@ie.u-ryukyu.ac.jpさんは書きました。
> 品詞情報を入れなくて済むので語数が多くなるんですよね...
# 英辞郎...ってちょっと違うか。(^^;
> まぁ、そうなんだけど... みんな日常的に変換しているわけだから、
> それで自然に辞書が集まるようにするってのは割と良い発想なんで
> すよね。SKKの辞書はそういう意味では良くできるんだけど...
辞書にない単語を入力したときは、その単語に期待する
読みでは入力できなかったわけでしょう? だったらその
単語を辞書に入れようと思ったら、いわゆる単語登録と
同じだけの手間がかかるわけです。Pubdicのときはみん
なミニマムな辞書からひいひい言いながら単語登録して
いく方法で頑張ったんじゃなかったかな。
でもそれはやっぱりたいへん。なので「自然に辞書が集
まる」というのは予想するほどうまくはいかないだろう
と思うのです。
あと、そうやって集めた単語に適切に品詞情報を振るの
もとってもたいへんです。ひとつひとつの単語について
じっくり考えなければならない。ローラー作戦で時間を
かければどうにかなるという問題ではなさそう。
Takashi SAKAMOTO
"Junn Ohta" <oh...@src.ricoh.co.jp> wrote in message
news:bqq46c$m0c$1...@ns.src.ricoh.co.jp...
> > (3) UI の問題 (2 と切離せないかもしれない)
> > (4) UI とアプリケーションの間のプロトコルの問題
> > (5) アプリケーションの問題
> > 私は (4) の問題、XIM の問題が大きいと思っています。
>
> (3)や(4)のあたりはIIIMFとかuimとかで改善されるので
> はないかと思っていました。その方面はあまり詳しくな
> いのですが...。
私は UI まで全て何かそういう単一のアプリケーションで吸収しなけれ
ばならないのか？と疑問に思うのです。
(4) さえ規定すれば、後はそれぞれが自由に実装するのが良いので
はないか、と。
IIIMF はちらっと見ただけなんですが、何故に Java？とだけ感じた記憶
があります。あと、internet/intranet で辞書を共有する意義が分かりま
せんでした。
> このあたりもそれに合わせて修正していくことになるの
> でしょうね。まあAnthyができてからWnnに手を入れても
> コストに見合う結果が得られるかどうかはまた別の問題
> でしょうけど。
別の問題ではありますね…。が、レガシーと切り捨ててしまう程に Wnn や
Canna というのは駄目なものか？というのが気にかかるのです。
# 仮名漢字変換の技術…研究っていうのは、あの当時からそんなにも
# 進んだものなのか？とか。google では hit しませんね…。
# 私が知っているのは、最長一致法とか、そのあたりまでです。
> 「一階」と「一回」、「仕様」と「使用」、「書く」と
> 「各」あたりは文脈をみて出し分けてほしいですよね。
> そうなるとWnnやCannaではちょっとヌルい...。
うーむ、どんな状況でも対応できるように単漢字変換しかしない身の愚かさ
ということですか... > 私
Junn Ohta
PXG0...@nifty.ne.jpさんは書きました。
> 私は UI まで全て何かそういう単一のアプリケーションで吸収しなけれ
> ばならないのか？と疑問に思うのです。
> (4) さえ規定すれば、後はそれぞれが自由に実装するのが良いので
> はないか、と。
そうでしょうね。ただ、そこだけ切り分けて規定できる
ようなものなのか、私にはよくわかりません。
> レガシーと切り捨ててしまう程に Wnn や
> Canna というのは駄目なものか？というのが気にかかるのです。
形態素解析の面では、WnnにもCannaにも不備はあるけど
やってること自体は間違ってない。それは今でも通用す
るし、レガシーではないです。
ただ、辞書側に持たせる情報が決定的に足りない。共起
情報や意味情報、ジャンル情報などをもたせることによ
って同音語候補が絞り込めれば、よりよい変換結果を最
初に出すことができるし、形態素解析の評価関数に反映
すれば形態素解析そのものの品質も向上できるだろう、
ということです。
Takashi SAKAMOTO
"Junn Ohta" <oh...@src.ricoh.co.jp> wrote in message
news:bqqa51$nt5$1...@ns.src.ricoh.co.jp...
> そうでしょうね。ただ、そこだけ切り分けて規定できる
> ようなものなのか、私にはよくわかりません。
その点だけを見れば、X Input Method Protocol は良くやっていたと
思います。
# document/reference sample の不備が全てを打ち消していますが…。
> 形態素解析の面では、WnnにもCannaにも不備はあるけど
> やってること自体は間違ってない。それは今でも通用す
> るし、レガシーではないです。
なるほど、です。
> ただ、辞書側に持たせる情報が決定的に足りない。共起
> 情報や意味情報、ジャンル情報などをもたせることによ
> って同音語候補が絞り込めれば、よりよい変換結果を最
> 初に出すことができるし、形態素解析の評価関数に反映
> すれば形態素解析そのものの品質も向上できるだろう、
> ということです。
なるほど…これはまさにその通りですね…。そこで最初の pubdic
しかないのは…という問題に戻るわけですか。
やっと理解しました。
# 遅いぞ… > 私。
NOKUBI Takatsugu
<bqq73t$245$1...@news511.nifty.com>の記事において
PXG0...@nifty.ne.jpさんは書きました。
>> > > (3) UI の問題 (2 と切離せないかもしれない)
>> > > (4) UI とアプリケーションの間のプロトコルの問題
>> > > (5) アプリケーションの問題
>> > > 私は (4) の問題、XIM の問題が大きいと思っています。
>> >
>> > (3)や(4)のあたりはIIIMFとかuimとかで改善されるので
>> > はないかと思っていました。その方面はあまり詳しくな
>> > いのですが...。
>>
>> 私は UI まで全て何かそういう単一のアプリケーションで吸収しなけれ
>> ばならないのか？と疑問に思うのです。
>> (4) さえ規定すれば、後はそれぞれが自由に実装するのが良いので
>> はないか、と。
uim がカバーする範囲は 3, 4 だけでなくて、単純な mapping 的変換(ハン
グルの入力やピンインなど)といったものであれば、uim の中で閉じた実装が
できるようになっています。t-code や SKK も uim の中で実装しています。
そういった単純な変換機能も提供した上でなおかつ、API を抽象化して変換
エンジンに依存せずにそれらを利用可能にするものが uim、だと理解しています。
実は BSD/Linux Day の発表に合わせて、tty ベースで uim を動作させる実
装を作ってみたのですが、だいたい 2日ぐらいの負荷で完成できました。昔似
たことを ONEW でやったときには1週間ちょっとかかったのですが、素性の良
い API の整備は重要なことだと思います。
http://www.daionet.gr.jp/~knok/screen/uim.html
# しかし時間がなくてお披露目するチャンスはありませんでしたが...
そのあたり、きっと Windows は多分良くできた framework があるんだろう
なあと想像しています。
>> IIIMF はちらっと見ただけなんですが、何故に Java？とだけ感じた記憶
>> があります。あと、internet/intranet で辞書を共有する意義が分かりま
>> せんでした。
Java なのは Sun で作成されている実装だからじゃないでしょうか ^^;
>> 別の問題ではありますね…。が、レガシーと切り捨ててしまう程に Wnn や
>> Canna というのは駄目なものか？というのが気にかかるのです。
Wnn や Canna に直接手をいれたり、コードの一部をひっぱってきたり、と
いうことが容易なのかどうか、というところが問題なのではないでしょうか。
その辺り自分はよく知らないのですが、少なくとも田畑さんはコードの再利用
よりも一から実装しなおす方を選んだようなので、なにかしらの扱いにくさは
きっとあるんじゃないかなあ、と想像しています。
--
野首 貴嗣
E-mail: kn...@daionet.gr.jp
kn...@namazu.org / kn...@debian.org
--
--
野首 貴嗣
E-mail: kn...@daionet.gr.jp
kn...@namazu.org / kn...@debian.org
Takashi SAKAMOTO
"NOKUBI Takatsugu" <kn...@daionet.gr.jp> wrote in message
news:br6178$gv8$1...@daio-b.daionet.gr.jp...
> uim がカバーする範囲は 3, 4 だけでなくて、単純な mapping 的変換(ハン
> グルの入力やピンインなど)といったものであれば、uim の中で閉じた実装が
> できるようになっています。t-code や SKK も uim の中で実装しています。
はい、知っています。
> そういった単純な変換機能も提供した上でなおかつ、API を抽象化して変換
> エンジンに依存せずにそれらを利用可能にするものが uim、だと理解しています。
私はその API こそが重要であり、その部分の層を厚くすることは alternative
の登場を妨げるのではないか、と思っています。
# alternative を実装したい、API だけ欲しいという望みはあって良い筈です。
# alternative が実際に実装されるかどうかは別として、ですが。
もし、protocol や interface を用意するとすれば、もっとも低レベル…私は
gtk の immodule のようなものを想像しますが…で、一度レイヤを切り、更に
その下で「変換エンジンとつなぐ部分のレイヤ」を切るべきではないかと思う
のです。
# これはポリシーや設計思想の違いだと思いますが。
# で、きちんとした reference sample で API の client 側から見たもの、server
# 側から見たものを用意し、かつ document を整備する、と。
> 実は BSD/Linux Day の発表に合わせて、tty ベースで uim を動作させる実
> 装を作ってみたのですが、だいたい 2日ぐらいの負荷で完成できました。昔似
> たことを ONEW でやったときには1週間ちょっとかかったのですが、素性の良
> い API の整備は重要なことだと思います。
>
> http://www.daionet.gr.jp/~knok/screen/uim.html
>
> # しかし時間がなくてお披露目するチャンスはありませんでしたが...
はい、そのページは既に拝見しています。が、それがもし gtk immodule のよう
なもので動作できるとすればどうでしょうか？
自由に UI を切り替えることも可能にするとすれば如何でしょうか？
> そのあたり、きっと Windows は多分良くできた framework があるんだろう
> なあと想像しています。
Windows の実装は immodule に近いと思います。(IME は API の定義、
API の実装は dll によって自由に切り替えられる)
kn...@daionet.gr.jp
Takashi SAKAMOTO wrote:
> > そういった単純な変換機能も提供した上でなおかつ、API を抽象化して変換
> > エンジンに依存せずにそれらを利用可能にするものが uim、だと理解しています。
>
> 私はその API こそが重要であり、その部分の層を厚くすることは alternative
> の登場を妨げるのではないか、と思っています。
ここでいう alternative は何に対してのものでしょうか。変換エンジンで
しょうか。もしそうだとすると、なぜそれが妨げる理由につながるのか、ちょっ
とよくわかりません。
> > 実は BSD/Linux Day の発表に合わせて、tty ベースで uim を動作させる実
> > 装を作ってみたのですが、だいたい 2日ぐらいの負荷で完成できました。昔似
> > たことを ONEW でやったときには1週間ちょっとかかったのですが、素性の良
> > い API の整備は重要なことだと思います。
> >
> > http://www.daionet.gr.jp/~knok/screen/uim.html
> >
> > # しかし時間がなくてお披露目するチャンスはありませんでしたが...
>
> はい、そのページは既に拝見しています。が、それがもし gtk immodule のよう
> なもので動作できるとすればどうでしょうか？
immodule と tty を繋ぐようなものができるかどうか、という話でしょうか。
実のところ immodule の仕組みもよくわかってないので可能かどうかはわかり
ません。
> > そのあたり、きっと Windows は多分良くできた framework があるんだろう
> > なあと想像しています。
>
> Windows の実装は immodule に近いと思います。(IME は API の定義、
> API の実装は dll によって自由に切り替えられる)
なるほど、そうなんですか。
会場では SKK を使っているという話をしたのですが、実はずいぶん前に
Anthy へ移行しようとして、変換効率とかそういったところとはまったく関係
ない理由で挫折し、いまに至っています。その問題はいまは解決されているの
で、昨日から anthy を再度使いはじめています。
# というわけでこの記事も Powerd by anthy.