XDGの詳細
原則として、私たちはすでにXDGの最も重要な機能を検討しました。 残りは「グッズ」のカテゴリを通過します。 たとえば、属性のセットを指定し、特定の単語ではなく「クラス」に属性を設定できます。 さらに、単語は単にこのクラスのインスタンスとして宣言され、リストされた属性を自動的に受け取ります。重要なことから：依存する単語を結合することの量的および質的な質問が考え出されます（例では既にありましたが、明示的に言及したいと思います）。 そのため、動詞の場合、1つの主語、1つのオブジェクト、および好きなだけの状況（場所、時期、理由）があることを示すことができます。 添付された単語ごとに、一貫した属性の独自のセットが示されます。 同じ動詞が件名と人と数で一貫しているとしましょう。 はい、繰り返します。同じ単語を異なる文脈で何度も記述できます。 たとえば、「ダイニングルーム」は形容詞と名詞の両方です。
結果を出力するメカニズムも非常に柔軟です。 ツリーを画面に描画し、テキストまたはxmlファイルに出力できます。 原理（原子価原理、ツリー原理など）は、プロジェクトライブラリに追加して独立して開発できます。 このためには、もちろん、モーツァルト/オズをマスターする必要があります:)
このプロジェクトの作者であるラルフ・ドブスマンに感謝します。XDGについてはこれ以上掘り下げません。 XDGを詳しく知りたい人のためのちょっとしたヒント：マニュアルだけでなく、著者の論文もよく読んでください。 このマニュアルは、教科書としてはあまり適していません。読むのが難しいです。 そして、論文はセットであり、簡単な例で読者にXDGのアイデアをきちんと紹介します。
トリバンカ
さて、ツリーバンクのような重要な現象についてのいくつかの言葉。 残念ながら、私はまだそれらについてほとんど知識がありません-すべての手が届きません。文法のルールの由来はすでに説明しました。 それらは手で構成することも、既存のテキストから「なんとか」抽出することもできます。 単純な統計的アプローチ（悲しくなります）は、かなり従来の「ヒューリスティック」基準に基づいて、単純に元の形式のプレーンテキストを分析します。 たとえば、隣り合っている単語は、離れた場所にある単語よりも互いに依存している可能性が高くなります。 私は、あなたがそのような原則に遠く及ばないように思えます。 私自身は、この基準を使用します。提案された自然言語パーサーのアイデアについて、比類のないほど単純なパスカルのパーサーを作成することは可能ですか？ それができない場合、私の意見では、話すことは何もありません。
ただし、特別に準備されたテキストに対して統計的方法を設定することもできますが、これはまったく別の問題です。 Tribankは、手動で準備された解析済みの文（つまり、列の解析）のコレクションです。 私の意見では、このような銀行を使用して、ツリーを生成するためのルールを自動的に抽出する必要があります。
論理的には、トライバンクはフレーズ構造ツリーバンクと依存ツリーバンクに分けられます。 おそらく、第一種の銀行の最も有名な例は、 ペンツリーバンクであり 、その注釈構文は「Homsky」トライバンクの事実上の標準です。 依存関係のツリーバンクは最近の現象であり、これまでのところ明らかに少数です。 チェコ語のプラハ依存ツリーバンクは、おそらく最も言及されています。 もちろん、 他にもあります（タイトルに "dependency"という単語が含まれるプロジェクトを参照してください）。 ロシア人にとって、いつものように、ある種の仕事は「進行中」ですが、具体的なことはまだ何も言えません。
技術的な機能が豊富にあるため、まだTribunesに深く入りません。 注釈の実行方法、構文とは何か、具体的に記述されているものと記述されていないものなど。 一般的に、掘り起こすのではなく、頭で被写体を掘り下げることができるという感覚があります。 そのため、掘り下げるときは、あなたが探しているものを正確に知る方が良いでしょうが、私はまだ自分で決めていません。
しかし、私にとって興味深いのは、トライバンクからXDGの形式でルールを自動的に抽出する試みです。 確かに、この経験は非常に成功したとは言えません。 著者は、ルールは依然として「自由すぎる」と判明しており、XDKは相互に固執することを許可しすぎていると書いています。 トライバンクは十分な大きさではないかもしれませんが、それは言うのは難しいです。 彼はまた、XDGには「確率的」ルールは存在しないと書いています。 少なくとも一度トライバンクで何かが起こった場合、これはすでに数百の例から得られたルールと同じレベルのルールです。 ただし、これはXDGの問題ではないと思います。 ルールが非常にまれな場合は、文法にまったく挿入しないことをお勧めします。 彼らはまた、多くの規則があり、文法が「うねる」と文句を言います。 これに対して、特定の文ごとに文法を生成できるという私の古い論文を繰り返します。
おそらく私にとって、このトピックで最も難しい質問はこれにとどまります。たとえば、ルールがトライバンクから削除され、テキストの適切な分析が可能になったとします。 次は？ このようなパーサーは、テキストのさらなる分析に役立ちますか？ これについて説明します。
語用論
正直なところ、このトピックは予想外に忍び寄っていました:)最初にXDGを使用するためのアイデアについてお話ししたかったのですが、次回まで延期する方が良いでしょう。 そして、ここに、少し抽象的な哲学の余地が少しあります。文の構文についてはすでに説明しました。 構文を理解するということは、単語間の構文の依存関係のグラフを作成できることを意味します。 次のレベルの理解はセマンティクスです -文の意味を理解します。 「理解」の下ではさまざまなものを隠すことができますが、今のところはこの用語をそのままにしておきましょう。 次のレベルは、言語の使用を担当するプラグマティストです。
コンピュータープログラムを書くとき、コンピューターによるソーステキストのほとんどすべての処理は、あるタイプのテキストを別のタイプのテキストに変換する、つまり実際には機械翻訳に変換されます。 高水準言語のプログラムをCコードに変換すると、Cコードを自動的に最適化して、アセンブラーテキストまたは直接機械命令に変換できます。 テキストの入力時、テキストの出力時-これは、すべてのコンパイラ、トランスレータ、オプティマイザ、およびそれらのような他の人が行うことです。 しかし、このチェーンの最後に、すべてが開始された段階、つまりプロセッサによるプログラムの実行が発生します。 つまり、パッシブデータ（テキスト）のセットは、アクティブプロセスを開始する制御シーケンスに変わります 。 これがプログラミング言語の意味です。アクションを制御します。
自然言語ははるかに複雑です。 Pascalコンパイラを書いている場合、私は最終的な目標をしっかりと知っています。それは、Pascalプログラムを中央処理装置によって実行されるマシンコードプログラムに変換する機械翻訳者です。 パーサー（つまり、これまでのところ、パーサーのみ-比較的初期の単純なコンパイラモジュール！）を記述する場合、自然言語の場合、次のステップで次に何が起こるかを明確に決定する必要があります。 テキストのセマンティクス/意味の問題が正常に解決されたとしても、セマンティクスの背後で何が起こるかはまだ明確ではありません。
実際には、ワープロの3つのアプリケーションは明らかです。 最初：機械翻訳。 ここでは、語用論の問題は発生しません-テキストは別の言語に翻訳され、読者に次に何をすべきかを考えさせます:) 2番目：テキストに含まれる情報に基づく特定の「知識ベース」または「事実ベース」の補充。 第三：音声インターフェース。 実際、ここでは、自然言語（または、その狭いサブセット）がプログラミング言語に取って代わります。 ウィンドウを開き、ボタンをクリックして、アプリケーションを起動します。
ゲームやトレーニングから分析まで、他の多くのアプリケーションを思いつくことができます。 「食用-食用ではない」をプレイできます。「Xを食べました」と入力すると、Xに応じて、コンピューターはあなたを信じるか信じないかを書き込みます。 パーサーは、スペル認識システムまたは音声認識システムの一部として使用できます。たとえば、認識したときに、理解できない、「私の馬は馬に乗って」または「私の馬は馬に乗って」と言いました。 パーサーは、「私の馬が笑っている」ことをすぐに理解します-設計が正しくなく、システムが最初のオプションを選択するのに役立ちます。
問題は、それがどんなに奇妙に聞こえるかにかかわらず、さらなるユースケース（言語またはパーサー）がパーサー自体に痕跡を残すことです。 たとえば、「食用-食用ではない」と再生する場合、「I ate 'inedible' 」のような構造を処理しようとすると構文解析エラーが発生するように、文法（XDGなど）を構成できます。
あまり考えられない例は、機械翻訳システムです。 「彼らはキャンプをした」と「彼らは車をクラッシュさせた」というフレーズは、まったく同じ方法で理解されます-主題動詞オブジェクト。 しかし、さらに別の問題が発生します。「破壊される」ものは何ですか？ 最初の「壊れた」英語は「セットアップ」、2番目は「クラッシュ」と翻訳する必要があります。 つまり、構文を理解しているように見えましたが、翻訳はあまり役に立ちませんでした。 同時に、「セットアップ」と「クラッシュ」の違いを認識しないパーサーは、ロシア語のスペルをチェックするために完全に機能することに注意してください。 破壊され破壊された-庭、テント、車、カップ、心。 誰がそれが英語であるかを気にしますか？
これには、トリバンクからルールを自動的に抽出するためのいくつかの問題があります（間違えられる可能性があります）。このすべての作業は、正しい構文解析ツリーを取得するタスクに集中していますが、このツリーで次に何をするかについては説明しません。 パーサーのタスクは構文解析であり、セマンティクスについては、チェーン内の次のモジュールに理解させることです。 ただし、次のモジュール（たとえば、セマンティックアナライザー）がパーサーと同じくらい複雑な場合、そのようなパーサーの使用は何ですか？ 構文解析の段階で、タスクのフレームワーク内でテキストから可能な限り多くの情報を絞り出すのが良いと思われます。
パーサーの品質を「客観的に」評価する試みはありますが、通常はパーサーが正しい解析ツリーを生成するかどうかにかかっています。
それで、今日は終わりです。 明日（まあ、または気分がいつになるか:)）続行します。 または、次のパートで終わります:)