2007/9/20
分類: 開発記 / タグ: HPSG, エスペラント, 処理概説, 構文解析, 車輪の再発明
コメント1件
エスペラントは日本語と同様に語順が比較的自由です。対格(akuzativo; 英accusative)の名詞句は述語(predikato; 英predicate)の目的語(objekto; 英object)であり、主格の名詞句は主語(subjekto; 英subject, nominative)となることによります。よって、以下のいずれも非文(nefrazo, 英nonsentence)とはなりません。
- Mi amas ŝin. 私は愛している、彼女を。 [SVO式]
- Mi ŝin amas. 私は彼女を愛している。 [SOV式]
- Amas mi ŝin. 愛している、私は彼女を。 [VSO式]
- Amas ŝin mi. 愛している、彼女を、私は。 [VOS式]
- Ŝin mi amas. 彼女を、私は愛している。 [OSV式]
- Ŝin amas mi. 彼女を愛している、私は。 [OVS式]
歯の浮くような例を挙げましたが、それはそれとして、エスペラント語日本語翻訳システム「Ermitejo」では、構文解析と意味解析に主辞駆動句構造文法(HPSG: Head-driven Phrase Structure Grammar)という近代的な文法を採用しています。より正直に述べるなら、採用を決めて実現可能性調査を終えた段階で、まさに文法を記述し始めて間もない段階です。
さてそこで問題となるのは、HPSGにこの自由語順言語をどう実装していくかというものです。
御多分に漏れず、HPSGは英語の実装についての研究が最も盛んであり、英語は語順が比較的固定されているので、英語のHPSGの文法（規則・制約・語彙辞書）をそのまま用いることは出来ません。日本語のHPSGによる実装の研究もありますが、限られた公開物を拝見する限りでは私の頭では理解が追いつきかねました。
そこで、備忘録を兼ねて以下に実装方法の考察を述べてみます。
(「語順が自由なエスペラントをHPSGで実装する」の続きを読む)
2007/9/14
分類: 公開, 開発記 / タグ: 処理概説, 形態素解析, 辞書引き, 音韻解析
ようやくversio 0.9.0で実装を始めた音韻関連の機能が整いつつあります。直近で更新した内容は、韻文中での発音に関する二点です。
修正点 versio 0.9.5の詳細と、実装方法の紹介
versio 0.9.5 (23-a publikigo, en 2007/09/11)
- 【機能追加】韻文中の「’」で終わる語の発音（アクセントを含む）を正しく表示するようにしました。例えば、esper’をこれまで「エスペル」と読んでいましたが、正しく「エスペール」と読むようにしました。
- 【機能追加】「l’」の後に母音が続く場合に、発音を後続の語と融合するようにしました。例えば、韻文中でl’ esperoではなくl’esperoと続けて書いたとき前提ですが、「ルエスペーロ」ではなく「レスペーロ」と読むようにしました。
前者では、アクセントを変更しないという点が曲者です。エスペラントの規則性ゆえに、実装も極めて論理的かつ簡素なものとなっていたのですが、こういう特例の存在により、優雅さとは程遠い泥臭い実装を行う羽目になります。前者ではl’を「ル」と読めるようになるのですが、l’armoをルアーモと読んでしまうために、ここでも特例を設けてラーモと読めるように処理を書き加えました。
エスペラントの字面から発音を得るロジック
良い機会なので、発音をカタカナやIPAで転記する処理の概要をご紹介します。あまり変なことを考えず、人間の頭の中で行っている処理を素直にコード化することが一番と言えます。
- まず、これまでの形態素解析で、既に語根や接辞の区切り文字を持った文字列が得られています。例えば、samideanojnという単語はsam/ide/an/o/j/nという文法上の区切りです。
- ここで、単純に「/」を区切り文字として、splitにより元の文字列というスカラを一旦リストに分解して配列に突っ込みます。
- この配列について、接尾辞や品詞語尾であった場合には、前の要素と結合するようにします。例えば、
('sam', 'ide', 'an', 'o', 'j', 'n')は('sam', 'ideanojn')になります。これはまだ文法上の区切りですが、続け読みが出来るように配慮された配列になっています。
- それぞれの要素について、「子音」「母音」「子音と母音」という音韻上の区切りを得ます。この際、文字が母音か子音かを判断しながら、文字を一つずつ処理していきます。内部処理では字上符付き文字をx後置式としているので、ここが私がうっかりはまった陥穽でした。
'sam'は('sa', 'm')に、'ideanojn'は('i', 'de', 'a', 'no', 'j', 'n')に分解されます。これで、それぞれの要素が一つの音に対応するような配列になりました。
- 上記を結合して
('sa', 'm', 'i', 'de', 'a', 'n', 'o', 'j', 'n')というリストを得て、配列に突っ込みます。
- アクセント位置を決定します。配列を後ろから辿って、二つめの母音がある要素がアクセント付きの場所です。
- 上記状態を、単純にIPAに置換します。エスペラントのアルファベートはIPAと1対1の関係にありますから、単純に
trすれば事足ります。アクセント位置には長母音の記号を与えて完成です。samとideanojとの間は空白を入れておきます。
- また、カタカナ発音にも置換します。カタカナ発音は子音と母音からなる二重ハッシュ構造を予め作っておき、ハッシュのキーをそれぞれ指定すれば事足ります。例えば、
'sa'は$japana->{'s'}{'a'}で「サ」が求まりますし、母音のみや子音のみの場合にはダミーのキーを与えて$japana->{'m'}{'_'}で「ム」、$japana->{'_'}{'i}で「イ」が求まるという次第です。長母音で「ー」を与えて完成です。
このように可能な限り手を抜いて楽をして発音させている無邪気な実装なので、世知辛いesper’などという文字列を与えたら、まず「’」なんてハッシュキーがないのでこけますし、これを無視したら母音が一つ足りないわけでエスペル（エがアクセント）と読もうとするしで大変です。
そこで、以下のように機能追加することによって、こうした言語現象にも対応出来るようにしました。
(「エスペラント発音解析の実装方法 (単語辞書引き機能 versio 0.9.5)」の続きを読む)
2007/9/10
分類: 公開, 開発記 / タグ: 処理概説, 字上符付き文字, 形態素解析, 辞書引き, 開発環境, 音韻解析
音韻関係のモジュールを先の辞書引き機能の改版に合わせて新規に作成したのですが、予想通り、初物の機能はなかなか安定しませんでした。それというのも、エスペラントの規則性を過大評価したというかこれに甘えてしまい、乏しいテストケースしか用意しなかったのが敗因と言えます。結果、連日連夜の改版を行うこととなりました。大多数の場合は問題なかったとはいえ、誤った発音が表示されたり、処理が異常終了したりすることがあり、反省しています。
もう少し具体的に述べますと、エスペラントの規則性に例外があるというのではなく（sam/ide/an/oやらといった場合は除きますが）、Perlで字上符付き文字を実装する際に手抜きをしており、これが後々尾を引いているといったところでしょうか。
実は、エスペラント語日本語翻訳システム「Ermitejo」は、21世紀、このUnicodeの時代に、字上符付き文字の内部処理を前時代的なx後置式の代用表記で行っています。関数名やら変数名やらをエスペラント式に名付けているだけなら特に問題がないのですが、取り扱うデータを代用表記すると、色々不都合が起きます。
普通に処理している場合には、外部から正書法ないし代用表記で突っ込まれたデータのアルファベートを変換して内部で使い、外部に表示する際には逆変換して正書法で返しているので問題はありませんでした。しかし、エスペラントの誇る1文字1音という原則が崩れ、「ĉ」の音「ʧ」を「cx」と2文字で表現することになりますので、音韻関係の機能の実装で舞台裏が拙さが露見したという次第です。
責任転嫁するつもりは毛頭ありませんが、コーディングに使っているエディタのサクラエディタがUTF-8への対応が甘く、なかなかこうした悪癖を改められないという思いもあります。サクラエディタは内部コードがUTF-8等ではなくShift-JISなので、UTF-8のファイルの読み書き自体は出来ますが、エスペラントの字上符付き文字等やIPA等は保存出来ないので、痛いところです。今更秀丸にも戻れませんが、さりとてサクラエディタの抜本的な書き直しを行える技量も時間も私には無いので、開発者の方々に声援を送ることしか出来ません。
【追記】kobake氏のウェブサイト「digital hole」にて、UNICODE版サクラエディタの開発が進められています。
ということで、そうした発音関係の修正を中心として、ここ数日での改版点の委細を以下に転記します。
(「字上符付き文字の葛藤 (単語辞書引き機能 versio 0.9.4)」の続きを読む)
記事の配信