エスペラントは日本語と同様に語順が比較的自由です。対格(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に実装する先行研究
左右両刀遣い
プログラマの美徳は、再利用にあります。出来るだけプログラミングせずに結果を得ることが良いプログラミングです。そこでひねもすエスペラントのHPSG上での実装をググってみたのですが、これがまたペンペン草も生えていない状況の様子です。何せ、日本のGoogleで全言語のページを対象に”HPSG Esperanto”と検索すると、困ったことにermitejo.comのページが引っ掛かるのですから、暗澹たる気分になります。
といっても対格の存在ゆえに語順が自由な言語は他にもあります。例えば、ギリシア語です。この方面での先行研究として、論文をGoogleでざっと調べた限りでは、北陸先端科学技術大学院大学・情報科学研究科の東条研究室の以下の研究が見つかりました。
- 仙田圭介氏「HPSGによるユークリッド『原論』の構文木の作成」(PDF)
- 中嶋健一郎氏「HPSGを用いた古典ギリシア語文法の拡張」(PDF)
ギリシア語ではなく古典ギリシア語というところが素敵なところですが、ともあれ補語（主語）と主辞（動詞句）が左右どちらに存在しても問題ないように、文法規則(skemo; 英schema)を記述していることが判りました。
左辺・右辺を、主辞・補語のどちらと単一化するか
といってもそれは予想の範囲内であって、問題はその計算機上での実装の実際です。例えばLiLFeSで英語を実装する例だと、左辺を補語に、右辺を主辞に決め打ちで用いています。しかしエスペラントの自由語順ではそうは問屋が卸しません。かといって何も考えずに左右を逆転したらしたで、意味解析に差し障りがあります。補語(SYNSEM|LOCAL|CAT|VAL|SUBJや、SYNSEM|LOCAL|CAT|VAL|COMPS)は斜格性(oblikveco; 英obliqueness)の低い順番にリストとして並べることとされており、かつ、その順番は意味上の主体・客体を示す素性構造(SYNSEM|RESTR|RELN|…)の各々と構造共有しているためです。
そこで、上記研究では（左右を問わない規則については）右辺主辞版の規則と左辺主辞版の規則の両方を用意するという迫り方をしています。コードを読むこと能わないのですが、論文の記述を見る限りではLiLFeSのコードでは「$LEFT = $SUBJ, $RIGHT = $HEAD.」と「$LEFT = $HEAD, $RIGHT = $SUBJ.」という2つの単一化部のみ差し替えた規則を用意したようです。
左右両対応の文法規則の作り方
基本的には上記研究に倣って規則を用意することとしましたが、ダミアン先生も『Perlベストプラクティス』で仰るように、コピペは厳禁です。そこで、純文法的な記述と、左辺と右辺をどう主辞・補語に割り当てるかといった処理部は分離することとしました。
規則のコンパイル時に結合し、（現在単語辞書でやっているように）予めStorable::nstoreしておいたPerlのデータ構造をStorable::retrieveすれば、結果は同じでもコードの量は約半分で済みます。つまりエンバグの機会も半分になります。
結局、まだあまり心象が湧かないのですが、記述を分けることによって見通しが良くなりますし、実際に使用する際の結果は同等（でなければリファクタリングではない）です。一番のキモとなる規則ではありますが、あまり深く悩む物でもないので、さっくりとPerlで書いてみました。
LiLFeSでは確定節の中身で左右の辺を主辞・補語に割り当てる処理を行っていますが、Perlですとサブルーチンで行うしかないため、泥臭い処理ですが語順を示す素性ORDER（予約語に被りそうな臭いが充満しています！）を勝手に拡張することとしました。
foreachで規則群を回すループに於いて、規則の語順を参考にして以下のいずれか、ないし両方のDTRS素性を用意します。
- {DTRS => { HEAD_DTR => $maldekstro, SUBJ_DTR => $dekstro }}
- {DTRS => { HEAD_DTR => $dekstro, SUBJ_DTR => $maldekstro }}
あとは、上記子ノードと文法規則（例えばhead subject schema）との単一化を試行するといった処理になります。
my $skemo_de_kapo_kaj_subjekto = { # head subject schema
PHON => [ 'TAG_0', 'TAG_1', ],
SYNSEM => { LOCAL => { CAT => { HEAD => 'TAG_2',
VAL => { SUBJ => [],
COMPS => ['TAG_3'],
SPR => ['TAG_4'], }}},
CONT => { INDEX => 'TAG_5' }},
DTRS => { HEAD_DTR => 'TAG_6',
SUBJ_DTR => 'TAG_7', },
TAG => [
'BOTTOM',
'BOTTOM',
'BOTTOM',
'BOTTOM',
'BOTTOM',
'BOTTOM',
{ PHON => 'TAG_1',
SYNSEM => { LOCAL => { CAT => { HEAD => 'TAG_2',
VAL => { SUBJ => ['TAG_7'],
COMPS => ['TAG_3'],
SPR => ['TAG_4'], }},
CONT => { INDEX => 'TAG_5'}}}},
{ PHON => 'TAG_0',
SYNSEM => { LOCAL => { CONT => { INDEX => 'TAG_5'}}}},
],
ORDER => 'ambaux',
};……なんだかクロージャで何とかなりそうな予感がします。また、構造共有を上記の通り少々姑息な手段で実装しています。内部的には単一化処理時にリファレンス渡しで処理しているので構造共有先の書き換え等々も問題ないのですが、これらがいいか悪いかはまた日を改めて考察する予定です。
ところで、VSO式ないしOSV式の語順、つまりVとOの語順を問わないどころか間にSが入ってしまっている場合はどうでしょうか。VとN(O)でVPを作り、VPとN(S)でS(文)を作ることが出来なくなりますが、ここでも変に長距離依存等を持ち出さず、上記先行研究のようにVとN(S)で”unsaturated S”を作り、これとN(O)でSを作るという句構造で処理するのが良いようです。この辺についても、その是非を含めて今後考察してゆきたいものです。
その他諸々
歯の浮くような例の1番目の文はSVO式であり、エスペラントでも最も一般的な語順です。日本語の一般的な語順はSOV式ですので、訳としては「私は彼女を愛している」の方が厳密には妥当です。以下、語順を崩す場合には、想定される語順よりも前に置いた語ほど強調することとなります。しかし、語順倒置による修辞上の効果は意味解析や文脈解析（談話解析）の範疇ですので、この記事ではひとまず採り上げません。
また、エスペラントと言えど完全に語順が自由という訳ではなく、例えば否定のneは否定する語・句・節の直前に置かねばなりませんし、直接疑問文を導くĈuは文頭に置かねばなりません。これもさしあたっては「動詞が目的語を取って動詞句となる」「動詞句が名詞句を取って文となる」という最も中核となる文法とは異なりますので、別の機会に考察してみます。
なお、私は歴史学で文学の学士号を帯びているだけで博士でも修士でも理系ですらもなく、かつ、企業の研究員でもない一介の金融系SEに過ぎません。ゆえに、そろそろ専門的な風味を帯びてきたこうした記事には、勘違いや誤った記述を含んでいる可能性が低くありませんので、悪しからずご了承ください。その場合には、コメント等でご指摘いただければ幸いです。
記事の配信