link grammar
1.0.0
バージョン5.12.5
リンク文法パーサーは、英語、タイ、ロシア語、アラビア語、ペルシャ語、および半ダースの他の言語の限られたサブセットの言語（自然言語）構造を示しています。この構造は、文の単語間のタイプされたリンク（エッジ）のグラフです。これらの異なる形式に変換するためにルールのコレクションを適用することにより、リンク文法からより従来のHPSG（構成要素）および依存関係スタイルの分析を取得できます。これは、Link Grammarが文の「Syntactico-Semantic」構造に少し「より深く」「より深く」進むため、これは可能です。従来のパーサーで一般的に利用可能なものよりもかなり微調整された詳細情報を提供します。
リンク文法の理論は、当初、カーネギーメロン大学の言語学とコンピューターサイエンスの教授であるデイビーテンペリー、ジョンラファティ、ダニエルスリートールによって1991年に開発されました。この理論に関する3つの最初の出版物は、最高の紹介と概要を提供します。それ以来、アイデアをさらに探索、調べ、拡張している何百もの出版物がありました。
元のカーネギー・メロンコードベースに基づいていますが、現在のリンク文法パッケージは劇的に進化しており、以前のバージョンとは大きく異なります。無数のバグ修正がありました。パフォーマンスは数桁改善されました。パッケージは完全にマルチスレッドされ、完全にUTF-8が有効になっており、セキュリティのためにスクラブされており、クラウドの展開を可能にします。英語の解析は劇的に改善されました。他の言語が追加されています（最も顕著なのはタイとロシア語）。形態、方言、細かい重量（コスト）システムのサポートなど、多くの新機能があり、ベクター埋め込みのような動作が可能になります。形態に合わせて調整された新しい洗練されたトークナイザーがあります。形態学的に曖昧な言葉のための代替分裂を提供できます。辞書は実行時に更新でき、文法の継続的な学習を実行するシステムも同時に解析することができます。つまり、辞書の更新と解析は相互にスレッドセーフです。単語のクラスは、正規表現で認識できます。ランダムな平面グラフ解析は完全にサポートされています。これにより、平面グラフのスペースを均一にサンプリングできます。変更されたものの詳細なレポートは、変更ログにあります。
このコードはLGPLライセンスの下でリリースされているため、プライベートと商業用の両方で自由に利用可能になり、制限はほとんどありません。ライセンスの条件は、このソフトウェアに含まれるライセンスファイルに与えられます。
詳細については、メインのWebページをご覧ください。このバージョンは、元のCMUパーサーの継続です。
バージョン5.9.0の時点で、システムには文を生成するための実験システムが含まれています。これらは、結果が文法的に有効な文であるときはいつでも、単語がワイルドカードの場所に置き換えられる「ブランクの記入」APIを使用して指定されます。追加の詳細は、Manページ： man link-generator （The man Subidirectory）にあります。
このジェネレーターは、OpenCog Language Learning Projectで使用されます。これは、人工ニューラルネット（ディープラーニング）に見られるが、明示的に象徴的な表現を使用して、真新しく革新的な情報理論的手法を使用して、コーパスのリンク文法を自動的に学習することを目的としています。
パーサーには、さまざまなプログラミング言語のAPIが含まれており、それを使用するための便利なコマンドラインツールが含まれています。典型的な出力は次のとおりです。
linkparser> This is a test!
Linkage 1, cost vector = (UNUSED=0 DIS= 0.00 LEN=6)
+-------------Xp------------+
+----->WV----->+---Ost--+ |
+---Wd---+-Ss*b+ +Ds**c+ |
| | | | | |
LEFT-WALL this.p is.v a test.n !
(S (NP this.p) (VP is.v (NP a test.n)) !)
LEFT-WALL 0.000 Wd+ hWV+ Xp+
this.p 0.000 Wd- Ss*b+
is.v 0.000 Ss- dWV- O*t+
a 0.000 Ds**c+
test.n 0.000 Ds**c- Os-
! 0.000 Xp- RW+
RIGHT-WALL 0.000 RW-
このかなり忙しいディスプレイは、多くの興味深いものを示しています。たとえば、 Ss*bリンクは動詞と被験者を接続し、被験者が単数形であることを示します。同様に、 Ostリンクは動詞とオブジェクトを接続し、オブジェクトが単数形であることも示します。 WV （動詞壁）のリンクは文のヘッドヴァーブを指し、 Wdリンクはヘッドノーンをポイントします。 Xpリンクは、後続の句読点に接続します。 Ds**cリンクは名詞を決定者に接続します。それは再び名詞が特異であることを確認し、名詞は子音で始まることも確認します。 （ここでは必要ないPHリンクは、「A」を「an」と区別するために、音声契約を強制するために使用されます）。これらのリンクタイプは、英語のリンクドキュメントに文書化されています。
ディスプレイの下部は、各単語に使用される「分離」のリストです。分離は、リンクを形成するために使用されたコネクタの単なるリストです。それらは「スピーチの一部」の非常にきめの細かい形として機能するため、特に興味深いものです。したがって、たとえば、分離的なS- O+ 、被験者とオブジェクトの両方をとる動詞を推移的な動詞と示します。上記の追加のマークアップは、「IS」が推移動詞として使用されているだけでなく、細かい詳細を示していることを示しています。単数形の被験者を採取し、文の頭の動詞に使用された（使用可能です）ことを示します。浮動小数点値は、分離の「コスト」です。これは、この特定の文法的使用のログ確率のアイデアを非常に捉えています。スピーチの部分が単語の意味と相関するように、微調整の部分は、より細かい区別と意味のグラデーションと相関しています。
リンク文法パーサーは、形態分析もサポートしています。これがロシア語の例です：
linkparser> это теста
Linkage 1, cost vector = (UNUSED=0 DIS= 0.00 LEN=4)
+-----MVAip-----+
+---Wd---+ +-LLCAG-+
| | | |
LEFT-WALL это.msi тест.= =а.ndnpi
LLリンクは、ステム 'ナーを接尾辞'� 'に接続します。 MVAリンクは接尾辞のみに接続します。ロシア語では、ステムではなく構文構造をすべて運ぶのは接尾辞であるためです。ロシアのレクシスはここに文書化されています。
タイ辞書は現在完全に開発されており、言語全体を効果的にカバーしています。タイの例：
linkparser> นายกรัฐมนตรี ขึ้น กล่าว สุนทรพจน์
Linkage 1, cost vector = (UNUSED=0 DIS= 2.00 LEN=2)
+---------LWs--------+
| +<---S<--+--VS-+-->O-->+
| | | | |
LEFT-WALL นายกรัฐมนตรี.n ขึ้น.v กล่าว.v สุนทรพจน์.n
VSリンクは、シリアル動詞構造で2つの動詞「ขึ้น」と「กล่าว」を接続します。リンクタイプの概要はここに記録されています。タイリンク文法の完全なドキュメントは、こちらをご覧ください。
Thai Link Grammarは、POSタグ付きおよび名前付きエンティティタグ付き入力も受け入れます。各単語は、リンクPOSタグで注釈を付けることができます。例えば：
linkparser> เมื่อวานนี้.n มี.ve คน.n มา.x ติดต่อ.v คุณ.pr ครับ.pt
Found 1 linkage (1 had no P.P. violations)
Unique linkage, cost vector = (UNUSED=0 DIS= 0.00 LEN=12)
+---------------------PT--------------------+
+---------LWs---------+---------->VE---------->+ |
| +<---S<---+-->O-->+ +<--AXw<-+--->O--->+ |
| | | | | | | |
LEFT-WALL เมื่อวานนี้.n[!] มี.ve[!] คน.n[!] มา.x[!] ติดต่อ.v[!] คุณ.pr[!] ครับ.pt[!]
タイ辞書の完全なドキュメントはこちらをご覧ください。
タイ辞書は、基本的なNLPツールとリンクパーサーの間のギャップを埋めるために、POSおよび名前付きエンティティのLST20タグセットを受け入れます。例えば：
linkparser> linkparser> วันที่_25_ธันวาคม@DTM ของ@PS ทุก@AJ ปี@NN เป็น@VV วัน@NN คริสต์มาส@NN
Found 348 linkages (348 had no P.P. violations)
Linkage 1, cost vector = (UNUSED=0 DIS= 1.00 LEN=10)
+--------------------------------LWs--------------------------------+
| +<------------------------S<------------------------+
| | +---------->PO--------->+ |
| +----->AJpr----->+ +<---AJj<--+ +---->O---->+------NZ-----+
| | | | | | | |
LEFT-WALL วันที่_25_ธันวาคม@DTM[!] ของ@PS[!].pnn ทุก@AJ[!].jl ปี@NN[!].n เป็น@VV[!].v วัน@NN[!].na คริสต์มาส@NN[!].n
上記の各単語には、LST20 POSタグとNEタグが注釈が付けられていることに注意してください。リンクPOSタグとLST20タグセットの両方の完全なドキュメントは、こちらをご覧ください。 LST20の詳細、たとえば注釈ガイドラインとデータ統計は、こちらをご覧ください。
any言語は、均一にサンプリングされたランダム平面グラフをサポートします。
linkparser> asdf qwer tyuiop fghj bbb
Found 1162 linkages (1162 had no P.P. violations)
+-------ANY------+-------ANY------+
+---ANY--+--ANY--+ +---ANY--+--ANY--+
| | | | | |
LEFT-WALL asdf[!] qwer[!] tyuiop[!] fghj[!] bbb[!]
ady言語も同様に行われ、ランダムな形態学的分裂を実行します。
linkparser> asdf qwerty fghjbbb
Found 1512 linkages (1512 had no P.P. violations)
+------------------ANY-----------------+
+-----ANY----+-------ANY------+ +---------LL--------+
| | | | |
LEFT-WALL asdf[!ANY-WORD] qwerty[!ANY-WORD] fgh[!SIMPLE-STEM].= =jbbb[!SIMPLE-SUFF]
拡張された概要と要約は、リンク文法ウィキペディアページにあります。これは、理論のインポートの主要な側面のほとんどに触れています。ただし、トピックに掲載された元の論文に代わるものではありません。
プライマリリンク文法Webサイトにリストされているペーパーと参照がさらにたくさんあります
C/C ++ APIドキュメントも参照してください。 Python3、Java、node.jsなど、他のプログラミング言語のバインディングは、Bindingsディレクトリにあります。 （JavaScriptバインディングには2つのセットがあります。1つはライブラリAPI用のセット、もう1つはコマンドラインパーサー用のセットです。）
| コンテンツ | 説明 |
|---|---|
| ライセンス | 利用規約を説明するライセンス |
| Changelog | 最近の変化の大要。 |
| 設定します | GNU構成スクリプト |
| autogen.sh | 開発者の構成メンテナンスツール |
| Link-Grammar/*。c | プログラム。 （ANSI-Cで書かれています） |
| ---- | ---- |
| Bindings/autoit/ | オプションの自動車言語バインディング。 |
| Bindings/Java/ | オプションのJava言語バインディング。 |
| バインディング/js/ | オプションのJavaScript言語バインディング。 |
| バインディング/lisp/ | オプションの一般的なLISP言語バインディング。 |
| bindings/node.js/ | オプションのnode.js言語バインディング。 |
| バインディング/ocaml/ | オプションのOCAML言語バインディング。 |
| Bindings/Python/ | オプションのPython3言語バインディング。 |
| Bindings/Python-Examples/ | リンク - 文法テストスイートおよびPython言語のバインディングの使用例。 |
| バインディング/swig/ | 他のFFIインターフェイス用のSWIGインターフェイスファイル。 |
| バインディング/ヴァラ/ | オプションのヴァラ言語バインディング。 |
| ---- | ---- |
| データ/en/ | 英語辞書。 |
| data/en/4.0.dict | 辞書の定義を含むファイル。 |
| data/en/4.0.knowledge | 後処理知識ファイル。 |
| データ/EN/4.0.CONSTITUENTS | 構成要素の知識ファイル。 |
| data/en/4.0.affix | fix（prefix/suffix）ファイル。 |
| data/en/4.0.regex | 正規表現ベースの形態推測者。 |
| data/en/tiny.dict | 小さな例辞書。 |
| data/en/words/ | 単語リストでいっぱいのディレクトリ。 |
| data/en/corpus*.batch | テストに使用される例Corpora。 |
| ---- | ---- |
| データ/ru/ | 本格的なロシア語辞書 |
| データ/th/ | 本格的なタイ語辞書（100,000語以上） |
| データ/ar/ | かなり完全なアラビア語辞書 |
| データ/fa/ | ペルシャ（ファルシ）辞書 |
| データ/de/ | 小さなプロトタイプドイツ語辞書 |
| データ/lt/ | 小さなプロトタイプリトアニア語辞書 |
| データ/ID/ | インドネシアの小さなプロトタイプ |
| データ/vn/ | 小さなプロトタイプベトナム辞書 |
| データ/彼/ | 実験的なヘブライ語辞書 |
| データ/kz/ | 実験的なカザフ語辞書 |
| データ/TR/ | 実験的なトルコ語辞書 |
| ---- | ---- |
| 形態/ar/ | アラビア語の形態分析装置 |
| 形態/fa/ | ペルシャの形態分析装置 |
| ---- | ---- |
| デバッグ/ | ライブラリのデバッグに関する情報 |
| MSVC/ | Microsoft Visual-Cプロジェクトファイル |
| Mingw/ | MSYSまたはCygwinでMINGWを使用することに関する情報 |
システムは、従来のtar.gz形式を使用して配布されます。コマンドラインでtar -zxf link-grammar.tar.gzコマンドを使用して抽出できます。
最新バージョンのターボールは、以下からダウンロードできます。
https://www.gnucash.org/link-grammar/downloads/
ファイルは、ダウンロード中にデータセットの破損がないことを確認し、第三者によるコード内部に悪意のある変更が行われないようにするために、デジタル的に署名されています。署名は、GPGコマンドで確認できます。
gpg --verify link-grammar-5.12.5.tar.gz.asc
（日付を除く）同一の出力を生成するはずです。
gpg: Signature made Thu 26 Apr 2012 12:45:31 PM CDT using RSA key ID E0C0651C
gpg: Good signature from "Linas Vepstas (Hexagon Architecture Patches) <[email protected]>"
gpg: aka "Linas Vepstas (LKML) <[email protected]>"
あるいは、MD5チェックサムを検証できます。これらは暗号化のセキュリティを提供しませんが、単純な腐敗を検出できます。チェックサムを確認するには、コマンドラインでmd5sum -c MD5SUMを発行します。
gitのタグは、以下を実行することで検証できます。
gpg --recv-keys --keyserver keyserver.ubuntu.com EB6AA534E0C0651C
git tag -v link-grammar-5.10.5
リンク文法共有ライブラリとデモンストレーションプログラムをコンパイルするには、コマンドラインで、次を入力します。
./configure
make
make check
インストールするには、ユーザーを「root」に変更し、言います
make install
ldconfig
これにより、 liblink-grammar.soライブラリが/ /usr/local/include/link-grammar /usr/local/libにインストールされます/usr/local/share/link-grammar ldconfigを実行すると、共有ライブラリキャッシュが再構築されます。インストールが成功したことを確認するには、（ルート以外のユーザーとして）実行します
make installcheck
Link-Grammarライブラリには、特定のライブラリをconfigureている場合に自動的に有効にされるオプションの機能があります。これらのライブラリはほとんどのシステムでオプションであり、追加の機能が必要な場合、対応するライブラリを実行configure前にインストールする必要があります。
ライブラリパッケージ名はさまざまなシステムで異なる場合があります（必要に応じてGoogleに相談してください...）。たとえば、名前には-devの代わりに-develが含まれているか、完全に存在しない場合があります。ライブラリ名には、プレフィックスlibがない場合があります。
libsqlite3-dev （sqlite-backed辞書用）libz1g-devまたはlibz-devel （現在バンドルされたminisat2に必要です）libedit-dev （editlineを参照）libhunspell-devまたはlibaspell-dev （および対応する英語辞書）。libtre-devまたはlibpcre2-dev （libc regexの実装よりもはるかに速く、freebsdとcygwinの正しさに必要です）。libpcre2-devを使用することを強くお勧めします。特定のシステムで使用する必要があります（建物セクションで指定されています）。libedit-devがインストールされている場合、矢印キーを使用して、Link-Parserツールへの入力を編集できます。上下の矢印キーは、以前のエントリを思い出します。あなたはこれが欲しいです。テストと編集をはるかに簡単にします。
node.jsバインディングの2つのバージョンが含まれています。 1つのバージョンがライブラリをラップします。もう1つは、emscriptenを使用してコマンドラインツールをラップします。ライブラリのバインディングはbindings/node.jsにあり、Emscriptenラッパーはbindings/jsにあります。
これらはnpmを使用して構築されています。まず、コアCライブラリを構築する必要があります。次に、次のことを行います。
cd bindings/node.js
npm install
npm run make
これにより、ライブラリバインディングが作成され、小さな単位テストも実行されます（合格するはずです）。例はbindings/node.js/examples/simple.jsにあります。
コマンドラインラッパーの場合、次のことを行います。
cd bindings/js
./install_emsdk.sh
./build_packages.sh
Python3バインディングはデフォルトで構築されており、対応するPython開発パッケージがインストールされていることを条件としています。 （Python2バインディングはサポートされなくなりました。）
これらのパッケージは次のとおりです。
python3-develpython3-dev注： configure （以下を参照）を発行する前に、必要なPythonバージョンをPATHを使用して呼び出すことができることを検証する必要があります。
Pythonバインディングの使用はオプションです。 Link-GrammarをPythonで使用する予定がない場合、これらは必要ありません。 Python Bindingsを無効にしたい場合は、以下を使用してください。
./configure --disable-python-bindings
linkgrammar.pyモジュールは、Pythonで高レベルのインターフェイスを提供します。 example.pyおよびsentence-check.pyスクリプトはデモを提供し、 tests.pyユニットテストを実行します。
make install pythondir=/where/to/installと言うことで実行できますデフォルトでは、 MakefileはJava Bindingsを構築しようとします。 Javaバインディングの使用はオプションです。 Link-GrammarをJavaで使用する予定がない場合、これらは必要ありません。次のように無効にすることにより、Javaバインディングの構築をスキップできます。
./configure --disable-java-bindings
jni.hが見つからない場合、またはantが見つからない場合、Javaバインディングは構築されません。
jni.hの発見に関するメモ：
いくつかの一般的なJava JVM分布（特に、太陽からのもの）は、このファイルを自動的に見つけることができない異常な場所に配置します。これを改善するには、環境変数JAVA_HOMEが正しく設定されていることを確認してください。 configureスクリプトは$JAVA_HOME/Headersおよび$JAVA_HOME/includeでjni.hを探します。また、 $JDK_HOMEの対応する場所を調べます。 jni.hまだ見つからない場合は、 CPPFLAGS変数を使用して場所を指定します。たとえば、たとえば、
export CPPFLAGS="-I/opt/jdk1.5/include/:/opt/jdk1.5/include/linux"
または
export CPPFLAGS="-I/c/java/jdk1.6.0/include/ -I/c/java/jdk1.6.0/include/win32/"
/optの使用は非標準であり、ほとんどのシステムツールはそこにインストールされているパッケージを見つけることができないことに注意してください。
/usr/localインストールターゲットは、標準のGNU configure --prefixオプションを使用して過剰に導入できます。だから、たとえば：
./configure --prefix=/opt/link-grammar
pkg-config （以下を参照）を使用することにより、非標準のインストール場所を自動的に検出できます。
追加の構成オプションが印刷されます
./configure --help
このシステムはテストされており、32および64ビットLinuxシステム、FreeBSD、MacOS、およびMicrosoft Windows Systemsでうまく機能しています。特定のOS依存ノートが続きます。
エンドユーザーはターボールをダウンロードする必要があります（開梱と署名の確認を参照）。
現在のGitHubバージョンは、開発者を対象としています（修正、新機能、または改善を提供する意思がある人を含む）。マスターブランチの先端はしばしば不安定であり、開発中のように悪いコードを持つことがあります。また、デフォルトではインストールされていない開発ツールをインストールする必要があります。これらの理由により、GitHubバージョンの使用は、通常のエンドユーザーにとっては落胆しています。
クローンIT： git clone https://github.com/opencog/link-grammar.git
またはzipとしてダウンロードしてください：
https://github.com/opencog/link-grammar/archive/master.zip
リンク文法を構築する前にインストールが必要なツール：
make （ gmakeバリアントが必要になる場合があります）
m4
gccまたはclang
autoconf
libtool
autoconf-archive
pkg-config （ pkgconfまたはpkgconfigという名前の場合があります）
pip3 （Pythonバインディング用）
オプション：
swig （言語バインディング用）
flex
アパッチアリ（ジャワバインディング用）
graphviz （単語グラフ表示機能を使用する場合）
githubバージョンには、 configureスクリプトが含まれていません。それを生成するには、使用してください。
autogen.sh
エラーが発生した場合は、上記の開発パッケージをインストールしていること、およびシステムのインストールが最新であることを確認してください。特に、 autoconfまたはautoconf-archiveの欠落は、奇妙で誤解を招くエラーを引き起こす可能性があります。
進む方法の詳細については、セクションを続行して、システムとその後の関連セクションを作成します。
デバッグモードを構成するには、使用します。
configure --enable-debug
いくつかの検証デバッグコードと関数を追加します。
デバッグに役立つ機能は、単語グラフディスプレイです。デフォルトで有効になっています。この機能の詳細については、Word-Graphディスプレイを参照してください。
現在の構成には、 gccを使用すると、見かけの標準C ++ライブラリの混合問題があります（修正を歓迎します）。ただし、FreeBSDの一般的な慣行はclangでコンパイルすることであり、この問題はありません。さらに、アドオンパッケージは/usr/localの下にインストールされます。
したがって、 configureの呼び出し方法は次のとおりです。
env LDFLAGS=-L/usr/local/lib CPPFLAGS=-I/usr/local/include
CC=clang CXX=clang++ configure
既存のlibc Regex実装には必要なレベルのRegexサポートがないため、 pcre2必須パッケージであることに注意してください。
一部のパッケージには、前のセクションで言及されているものとは異なる名前があります。
minisat （MinISAT2） pkgconf （pkg-config）
Plain-Vanilla Link Grammarは、上記のように、Apple Macosを順調にコンパイルして実行する必要があります。現時点では、報告された問題はありません。
Java Bindingsが必要ない場合は、ほぼ確実に構成する必要があります。
./configure --disable-java-bindings
Java Bindingsが必要な場合は、JDK_HOME環境変数<Headers/jni.h>どこにでも設定してください。 Java_home変数をJavaコンパイラの場所に設定します。アリがインストールされていることを確認してください。
Githubから構築したい場合（GitHubリポジトリの建物を参照）、HomeBrewを使用してそこにリストされているツールをインストールできます。
Link-GrammarをWindowsにコンパイルできる3つの異なる方法があります。 1つの方法は、WindowsにLinux互換性レイヤーを提供するCygwinを使用することです。別の方法は、MSVCシステムを使用することです。 3番目の方法は、GNUツールセットを使用してWindowsプログラムをコンパイルするMINGWシステムを使用することです。ソースコードは、VistaからWindowsシステムをサポートしています。
Cygwin Wayは現在、コマンドの完了と履歴を使用したライン編集をサポートし、X-Windowsに表示されるWord-Graphもサポートするため、最良の結果を生み出しています。 （現在、Mingwにはlibeditがありません。MSVCポートは現在、コマンドの完了と履歴、およびスペルをサポートしていません。
MS Windowsでリンク文法が機能する最も簡単な方法は、WindowsにLinuxのような環境であるCygwinを使用して、POSIXシステムで実行されているソフトウェアをWindowsにポートできるようにすることです。 Cygwinをダウンロードしてインストールします。
LIBC Regexの実装が十分に能力がないため、 pcre2パッケージのインストールが必要であることに注意してください。
詳細については、Mingw/readme-cygwin.mdを参照してください。
Link-Grammarを構築する別の方法は、GNUツールセットを使用してWindows用のPOSIXに準拠したプログラムをコンパイルするMINGWを使用することです。 MINGW/MSYS2を使用することは、おそらくWindows用の実行可能なJavaバインディングを取得する最も簡単な方法です。 msys2.orgからmingw/msys2をダウンロードしてインストールします。
LIBC Regexの実装が十分に能力がないため、 pcre2パッケージのインストールが必要であることに注意してください。
詳細については、MINGW/README-MINGW64.MDを参照してください。
Microsoft Visual C/C ++プロジェクトファイルは、 msvcディレクトリにあります。道順については、readme.mdファイルを参照してください。
プログラムを実行するには、コマンドを発行します（それがあなたの道にあると仮定します）：
link-parser [arguments]
これにより、プログラムが開始されます。このプログラムには、多くのユーザーセット可能な変数とオプションがあります。これらは、Link-Parserプロンプトに!varを入力することで表示できます。入力!helpいくつかの追加コマンドを表示します。
辞書は、名前が2文字の言語コードであるディレクトリに配置されています。 Link-Parserプログラムは、その順序でそのような言語ディレクトリを直接またはディレクトリ名dataで検索します。
/usr/local/share/link-grammar ）。Link-Parserが目的の辞書を見つけることができない場合は、冗長レベル4を使用して問題をデバッグします。例えば：
link-parser ru -verbosity=4
他の場所はコマンドラインで指定できます。例えば：
link-parser ../path/to-my/modified/data/en
標準以外の場所で辞書にアクセスする場合、標準のファイル名は引き続き想定されています（つまり、 4.0.dict 、 4.0.affixなど）。
ロシアの辞書はdata/ruにあります。したがって、ロシアのパーサーは次のように開始できます。
link-parser ru
Link-Parserに引数を提供しない場合、現在のロケールセットアップに従って言語を検索します。そのような言語ディレクトリが見つからない場合、デフォルトは「en」になります。
これに似たエラーが表示された場合：
Warning: The word "encyclop" found near line 252 of en/4.0.dict
matches the following words:
encyclop
This word will be ignored.
次に、UTF-8ロケールがインストールされていないか、構成されていません。シェルコマンドlocale -a 、 en_US.utf8ロケールとしてリストする必要があります。そうでない場合は、オペレーティングシステムに応じて、 dpkg-reconfigure localesまたはupdate-localeまたはapt-get install locales必要があります。
結果のビルドをテストする方法はいくつかあります。 Pythonバインディングが構築されている場合、テストプログラムはファイルに表示されます./bindings/python-examples/tests.py実行時に実行する必要があります。詳細についてはbindings/python-examplesディレクトリのreadme.mdを参照してください。
また、言語データディレクトリにはテスト/例の文の複数のバッチがあり、通常はcorpus-*.batchパーサープログラムは、多数の文でシステムをテストするためにバッチモードで実行できます。次のコマンドは、 corpus-basic.batchというファイルでパーサーを実行します。
link-parser < corpus-basic.batch
corpus-basic.batchの上部近くのライン!batchバッチモードをオンにします。このモードでは、初期*でラベル付けされた文は拒否されるべきであり、 *で始まっていない文は受け入れる必要があります。このバッチファイルは、ファイルcorpus-biolg.batchおよびcorpus-fixes.batchと同様に、いくつかのエラーを報告します。これらを修正するための作業が進行中です。
corpus-fixes.batchファイルには、リンク文法の元の4.1リリース以降に修正された数千の文が含まれています。 corpus-biolg.batchには、Biolgプロジェクトの生物学/医療テキスト文が含まれています。 corpus-voa.batchには、Voice of Americaのサンプルが含まれています。 corpus-failures.batchには、多数の障害が含まれています。
次の数値は変更される可能性がありますが、現時点では、これらの各ファイルで観察すると予想されるエラーの数は、ほぼ次のとおりです。
en/corpus-basic.batch: 88 errors
en/corpus-fixes.batch: 371 errors
lt/corpus-basic.batch: 15 errors
ru/corpus-basic.batch: 47 errors
Bindings/Pythonディレクトリには、Python Bindingsのユニットテストが含まれています。また、リンク文法ライブラリを強調するいくつかの基本的なチェックを実行します。
パーサーにはAPI（アプリケーションプログラムインターフェイス）があります。これにより、独自のアプリケーションに簡単に組み込むことができます。 APIはWebサイトに文書化されています。
FindLinkGrammar.cmakeファイルを使用して、Cmakeベースのビルド環境でコンパイルをテストおよびセットアップできます。
コンパイルとリンクを簡単にするために、現在のリリースではPKG-Configシステムを使用します。リンク文法ヘッダーファイルの位置を決定するには、 pkg-config --cflags link-grammarのライブラリの位置を取得すると、 pkg-config --libs link-grammarなど、たとえば、典型的なメイクファイルにはターゲットが含まれる場合があります。
.c.o:
cc -O2 -g -Wall -c $< `pkg-config --cflags link-grammar`
$(EXE): $(OBJS)
cc -g -o $@ $^ `pkg-config --libs link-grammar`
このリリースは、パーサーにアクセスする3つの方法を提供するJavaファイルを提供します。最も簡単な方法は、org.linkgrammar.linkgrammarクラスを使用することです。これにより、パーサーに非常にシンプルなJava APIが提供されます。
2番目の可能性は、LGServiceクラスを使用することです。これにより、TCP/IPネットワークサーバーが実装され、JSONメッセージとしての結果が解析されます。 JSONで利用可能なクライアントは、このサーバーに接続して、解析されたテキストを取得できます。
3番目の可能性は、org.linkgrammar.lgremoteclientクラス、特にparse（）メソッドを使用することです。このクラスは、JSONサーバーに接続し、応答をParseresult APIを介してアクセス可能な結果に変換するネットワーククライアントです。
Apache antがインストールされている場合、上記のコードが構築されます。
ネットワークサーバーは、次のように言うことで開始できます。
java -classpath linkgrammar.jar org.linkgrammar.LGService 9000
上記は、ポート9000でサーバーを起動します。ポートが省略され、ヘルプテキストが印刷されます。このサーバーは、TCP/IPを介して直接連絡できます。例えば：
telnet localhost 9000
（または、Telnetの代わりにNetCatを使用してください）。接続後、入力してください。
text: this is an example sentence to parse
返されたバイトは、文の解析を提供するJSONメッセージになります。デフォルトでは、テキストのASCII-ART Parseは送信されません。これは、フォームのメッセージを送信することで取得できます。
storeDiagramString:true, text: this is a test.
パーサーは、形態学に基づいて知らないと推測できない単語に遭遇する場合、初期段階でスペルチェッカーを実行します。 Configureスクリプトは、AspellまたはHunspellのスペルチェッカーを探します。 Aspell Devel環境が見つかった場合、Aspellが使用されます。
呪文の推測は、ランタイム時に、 !spell=0フラグを持つリンクパーサークライアントで無効になる場合があります。詳細については、 !helpを入力してください。
注意：Aspellバージョン0.60.8以降、おそらく他の人にはメモリリークがあります。生産サーバーでの呪文推測の使用は、強く落胆しています。 Parse_Optionsで呪文推測を無効に保つ（ =0 ）。
複数のスレッドでLink-Grammarを使用しても安全です。スレッドは同じ辞書を共有する場合があります。解析オプションは、すべてのスレッドで共有されるグローバルである冗長性を除いて、スレッドごとに設定できます。それは唯一のグローバルです。
A/子音/母音の前の音声決定因子は、新しいpHリンクタイプによって処理され、その直後の単語に決定者をリンクします。ステータス：バージョン5.1.0（2014年8月）で導入されました。多くの特別ケースの名詞は未完成ですが、ほとんどが行われています。
リトアニア語、トルコ語、その他の無料の単語順序言語など、一部の言語には方向性リンクが必要です。目標は、リンクがどの単語であるかを明確に示すことです。これは、コネクタに「ヘッド」と「依存」を示す単一の小文字の文字を1つの小文字の文字でプレフィックスすることによって達成されます。リンケージルールは、HがNothingまたはDのいずれかに一致し、DがHまたは何も一致しないようなものです。これは、バージョン5.1.0（2014年8月）の新機能です。ウェブサイトは追加のドキュメントを提供します。
英語のリンク文法リンクは指向ではありませんが、依存関係文法の標準的な概念と完全に一致する事実上の方向性を与えることができるようです。
依存関係の矢印には、次のプロパティがあります。
反射反射（単語はそれ自体に依存することはできません。それ自体を指すことはできません。）
抗対称（word1がword2に依存する場合、word2はword1に依存することはできません）（したがって、例えば、決定者は名詞に依存しますが、その逆はありません）
矢印は推移的ではなく、反transitiveでもありません。単一の単語は、いくつかの頭によって支配される場合があります。例えば：
+------>WV------->+
+-->Wd-->+<--Ss<--+
| | |
LEFT-WALL she thinks.v
つまり、左の壁から直接、WDリンクを介して、間接的に壁から根の動詞まで、そしてそこから被験者への主題への道が「彼女」に向かう道があります。同様のループがBおよびRリンクを使用して形成されます。このようなループは、可能な数の分割数を制約するのに役立ちます。制約は、「No Links Cross」メタルールと組み合わせて発生します。
いくつかの関連する数学的概念がありますが、方向性LGを完全にキャプチャするものはありません。
方向LGグラフは、LGが1つの壁（1つの「上」要素）のみを許可することを除いて、DAGに似ています。
方向性LGグラフは、LG矢印が通常推移的ではないことを除いて、厳密な部分的な順序に似ています。
CatenaはCatenaが厳密に反動的であることを除いて、Catenaに似ている方向性LGグラフは、Catenaでは、あらゆる単語への道が一意です。
基本的なLG論文は、解析グラフの平面性を義務付けています。これは、依存関係が自然言語でほとんど交差しないという非常に古い観察に基づいています。人間は単にリンクが交差する文で話さない。平面性の制約を課すと、結果として得られる偏見に強力なエンジニアリングとアルゴリズムの制約が提供されます。考慮すべき区画の総数が大幅に減少するため、解析の全体的な速度が大幅に増加する可能性があります。
ただし、この平面性ルールには時折、比較的まれな例外があります。このような例外は、ほぼすべての言語で観察されます。これらの例外の多くは、以下の英語のために与えられています。
したがって、平面性の制約を緩和し、ほぼ同じように厳しいものを見つけることが重要であるように思われますが、それでもまれな例外を許可しています。リチャード・ハドソンが「単語文法」の理論で定義し、その後ベン・ゴエルツェルによって提唱された「ランドマークトランジテーション」の概念は、まさにそのようなメカニズムかもしれません。
ftp://ftp.phon.ucl.ac.uk/pub/word-grammar/ell2-wg.pdf
http://www.phon.ucl.ac.uk/home/dick/enc/syntax.htm
http://goertzel.org/prowlgrammar.pdf
実際には、平面性の制約により、パーサーの実装に非常に効率的なアルゴリズムを使用できます。したがって、実装の観点からは、平面性を維持したいと考えています。幸いなことに、私たちのケーキを持ってそれを食べるための便利で明確な方法があります。標準の電気エンジニアリング表記を使用して、紙の上に非平面図を描くことができます。この表記は、LGコネクタに非常に簡単に適合します。以下は、現在のLG English Dictionaryに既に実装されている実際の作業例です。すべてのリンク交差点をこのように実装できます！したがって、非平面図を取得するために現在の解析アルゴリズムを実際に放棄する必要はありません。それらを変更する必要さえありません！ハーレイ！
これが実用的な例です：「私はすべてを見て耳を傾けたい」。これは、「すべて」を指す2つのJリンクが必要です。目的の図は次のように見える必要があります。
+---->WV---->+
| +--------IV---------->+
| | +<-VJlpi--+
| | | +---xxx------------Js------->+
+--Wd--+-Sp*i+--TO-+-I*t-+-MVp+ +--VJrpi>+--MVp-+---Js->+
| | | | | | | | | |
LEFT-WALL I.p want.v to.r look.v at and.j-v listen.v to.r everything
上記は本当に「at」から「すべて」へのJsリンクを持ちたいと思っていますが、このJsリンクは、接続詞へのリンクを交差させます（xxxでマークされます）。他の例は、ほとんどのリンクがダウンリンクを越えて接続詞に渡ることを可能にする必要があることを示唆しています。
平面的に維持される動作はJk Jsリンクを2つに分割することです。JJパーツとJjパーツ。 2つは一緒に使用され、接続詞を越えます。これは現在、英語辞書に実装されており、機能します。
このワークアラウンドは実際には完全に一般的であり、あらゆる種類のリンク交差に拡張できます。これが機能するためには、より良い表記が便利です。 perhaps uJs- instead of Jj- and vJs- instead of Jk- , or something like that ... (TODO: invent better notation.) (NB: This is a kind of re-invention of "fat links", but in the dictionary, not in the code.)
Given that non-planar parses can be enabled without any changes to the parser algorithm, all that is required is to understand what sort of theory describes link-crossing in a coherent grounding. That theory is Dick Hudson's Landmark Transitivity, explained here.
This mechanism works as follows:
First, every link must be directional, with a head and a dependent. That is, we are concerned with directional-LG links, which are of the form x--A-->y or y<--A--x for words x,y and LG link type A.
Given either the directional-LG relation x--A-->y or y<--A--x, define the dependency relation x-->y. That is, ignore the link-type label.
Heads are landmarks for dependents. If the dependency relation x-->y holds, then x is said to be a landmark for y, and the predicate land(x,y) is true, while the predicate land(y,x) is false. Here, x and y are words, while --> is the landmark relation.
Although the basic directional-LG links form landmark relations, the total set of landmark relations is extended by transitive closure. That is, if land(x,y) and land(y,z) then land(x,z). That is, the basic directional-LG links are "generators" of landmarks; they generate by means of transitivity. Note that the transitive closure is unique.
In addition to the above landmark relation, there are two additional relations: the before and after landmark relations. (In English, these correspond to left and right; in Hebrew, the opposite). That is, since words come in chronological order in a sentence, the dependency relation can point either left or right. The previously-defined landmark relation only described the dependency order; we now introduce the word-sequence order. Thus, there are are land-before() and land-after() relations that capture both the dependency relation, and the word-order relation.
Notation: the before-landmark relation land-B(x,y) corresponds to x-->y (in English, reversed in right-left languages such as Hebrew), whereas the after-landmark relation land-A(x,y) corresponds to y<--x. That is, land(x,y) == land-B(x,y) or land-A(x,y) holds as a statement about the predicate form of the relations.
As before, the full set of directional landmarks are obtained by transitive closure applied to the directional-LG links. Two different rules are used to perform this closure:
-- land-B(x,y) and land(y,z) ==> land-B(x,y)
-- land-A(x,y) and land(y,z) ==> land-A(x,y)
Parsing is then performed by joining LG connectors in the usual manner, to form a directional link. The transitive closure of the directional landmarks are then computed. Finally, any parse that does not conclude with the "left wall" being the upper-most landmark is discarded.
Here is an example where landmark transitivity provides a natural solution to a (currently) broken parse. The "to.r" has a disjunct "I+ & MVi-" which allows "What is there to do?" to parse correctly. However, it also allows the incorrect parse "He is going to do". The fix would be to force "do" to take an object; however, a link from "do" to "what" is not allowed, because link-crossing would prevent it.
Fixing this requires only a fix to the dictionary, and not to the parser itself.
Examples where the no-links-cross constraint seems to be violated, in English:
"He is either in the 105th or the 106th battalion."
"He is in either the 105th or the 106th battalion."
Both seem to be acceptable in English, but the ambiguity of the "in-either" temporal ordering requires two different parse trees, if the no-links-cross rule is to be enforced. This seems un-natural. Similarly:
"He is either here or he is there."
"He either is here or he is there."
A different example involves a crossing to the left wall. That is, the links LEFT-WALL--remains crosses over here--found :
"Here the remains can be found."
Other examples, per And Rosta:
The allowed--by link crosses cake--that :
He had been allowed to eat a cake by Sophy that she had made him specially
a--book , very--indeed
"a very much easier book indeed"
an--book , easy--to
"an easy book to read"
a--book , more--than
"a more difficult book than that one"
that--have crosses remains--of
"It was announced that remains have been found of the ark of the covenant"
There is a natural crossing, driven by conjunctions:
"I was in hell yesterday and heaven on Tuesday."
the "natural" linkage is to use MV links to connect "yesterday" and "on Tuesday" to the verb. However, if this is done, then these must cross the links from the conjunction "and" to "heaven" and "hell". This can be worked around partly as follows:
+-------->Ju--------->+
| +<------SJlp<----+
+<-SX<-+->Pp->+ +-->Mpn->+ +->SJru->+->Mp->+->Js->+
| | | | | | | | |
I was in hell yesterday and heaven on Tuesday
but the desired MV links from the verb to the time-prepositions "yesterday" and "on Tuesday" are missing -- whereas they are present, when the individual sentences "I was in hell yesterday" and "I was in heaven on Tuesday" are parsed. Using a conjunction should not wreck the relations that get used; but this requires link-crossing.
"Sophy wondered up to whose favorite number she should count"
Here, "up_to" must modify "number", and not "whose". There's no way to do this without link-crossing.
Link Grammar can be understood in the context of type theory. A simple introduction to type theory can be found in chapter 1 of the HoTT book. This book is freely available online and strongly recommended if you are interested in types.
Link types can be mapped to types that appear in categorial grammars. The nice thing about link-grammar is that the link types form a type system that is much easier to use and comprehend than that of categorial grammar, and yet can be directly converted to that system! That is, link-grammar is completely compatible with categorial grammar, and is easier-to-use. See the paper "Combinatory Categorial Grammar and Link Grammar are Equivalent" for details.
The foundational LG papers make comments to this effect; however, see also work by Bob Coecke on category theory and grammar. Coecke's diagrammatic approach is essentially identical to the diagrams given in the foundational LG papers; it becomes abundantly clear that the category theoretic approach is equivalent to Link Grammar. See, for example, this introductory sketch http://www.cs.ox.ac.uk/people/bob.coecke/NewScientist.pdf and observe how the diagrams are essentially identical to the LG jigsaw-puzzle piece diagrams of the foundational LG publications.
If you have any questions, please feel free to send a note to the mailing list.
The source code of link-parser and the link-grammar library is located at GitHub.
For bug reports, please open an issue there.
Although all messages should go to the mailing list, the current maintainers can be contacted at:
Linas Vepstas - <[email protected]>
Amir Plivatsky - <[email protected]>
Dom Lachowicz - <[email protected]>
A complete list of authors and copyright holders can be found in the AUTHORS file. The original authors of the Link Grammar parser are:
Daniel Sleator [email protected]
Computer Science Department 412-268-7563
Carnegie Mellon University www.cs.cmu.edu/~sleator
Pittsburgh, PA 15213
Davy Temperley [email protected]
Eastman School of Music 716-274-1557
26 Gibbs St. www.link.cs.cmu.edu/temperley
Rochester, NY 14604
John Lafferty [email protected]
Computer Science Department 412-268-6791
Carnegie Mellon University www.cs.cmu.edu/~lafferty
Pittsburgh, PA 15213
Some working notes.
Easy to fix: provide a more uniform API to the constituent tree. ie provide word index. Also, provide a better word API, showing word extent, subscript, etc.
There are subtle technical issues for handling capitalized first words. This needs to be fixed. In addition, for now these words are shown uncapitalized in the result linkages. This can be fixed.
Maybe capitalization could be handled in the same way that a/an could be handled! After all, it's essentially a nearest-neighbor phenomenon!
See also issue 690
The proximal issue is to add a cost, so that Bill gets a lower cost than bill.n when parsing "Bill went on a walk". The best solution would be to add a 'capitalization-mark token' during tokenization; this token precedes capitalized words. The dictionary then explicitly links to this token, with rules similar to the a/an phonetic distinction. The point here is that this moves capitalization out of ad-hoc C code and into the dictionary, where it can be handled like any other language feature. The tokenizer includes experimental code for that.
The old for parse ranking via corpus statistics needs to be revived. The issue can be illustrated with these example sentences:
"Please the customer, bring in the money"
"Please, turn off the lights"
In the first sentence, the comma acts as a conjunction of two directives (imperatives). In the second sentence, it is much too easy to mistake "please" for a verb, the comma for a conjunction, and come to the conclusion that one should please some unstated object, and then turn off the lights. (Perhaps one is pleasing by turning off the lights?)
When a sentence fails to parse, look for:
Poor agreement might be handled by giving a cost to mismatched lower-case connector letters.
An common phenomenon in English is that some words that one might expect to "properly" be present can disappear under various conditions. Below is a sampling of these. Some possible solutions are given below.
Expressions such as "Looks good" have an implicit "it" (also called a zero-it or phantom-it) in them; that is, the sentence should really parse as "(it) looks good". The dictionary could be simplified by admitting such phantom words explicitly, rather than modifying the grammar rules to allow such constructions. Other examples, with the phantom word in parenthesis, include:
This can extend to elided/unvoiced syllables:
Elided punctuation:
Normally, the subjects of imperatives must always be offset by a comma: "John, give me the hammer", but here, in muttering an oath, the comma is swallowed (unvoiced).
Some complex phantom constructions:
See also GitHub issue #224.
Actual ellipsis:
Here, the ellipsis stands for a subordinate clause, which attaches with not one, but two links: C+ & CV+ , and thus requires two words, not one. There is no way to have the ellipsis word to sink two connectors starting from the same word, and so some more complex mechanism is needed. The solution is to infer a second phantom ellipsis:
where the first ellipsis is a stand in for the subject of a subordinate clause, and the second stands in for an unknown verb.
Many (unstressed) syllables can be elided; in modern English, this occurs most commonly in the initial unstressed syllable:
Poorly punctuated sentences cause problems: for example:
"Mike was not first, nor was he last."
"Mike was not first nor was he last."
The one without the comma currently fails to parse. How can we deal with this in a simple, fast, elegant way? Similar questions for zero-copula and zero-that sentences.
Consider an argument between a professor and a dean, and the dean wants the professor to write a brilliant review. At the end of the argument, the dean exclaims: "I want the review brilliant!" This is a predicative adjective; clearly it means "I want the review [that you write to be] brilliant." However, taken out of context, such a construction is ungrammatical, as the predictiveness is not at all apparent, and it reads just as incorrectly as would "*Hey Joe, can you hand me that review brilliant?"
"Push button"
"Push button firmly"
The subject is a phantom; the subject is "you".
One possible solution is to perform a one-point compactification. The dictionary contains the phantom words, and their connectors. Ordinary disjuncts can link to these, but should do so using a special initial lower-case letter (say, 'z', in addition to 'h' and 'd' as is currently implemented). The parser, as it works, examines the initial letter of each connector: if it is 'z', then the usual pruning rules no longer apply, and one or more phantom words are selected out of the bucket of phantom words. (This bucket is kept out-of-line, it is not yet placed into sentence word sequence order, which is why the usual pruning rules get modified.) Otherwise, parsing continues as normal. At the end of parsing, if there are any phantom words that are linked, then all of the connectors on the disjunct must be satisfied (of course!) else the linkage is invalid. After parsing, the phantom words can be inserted into the sentence, with the location deduced from link lengths.
A more principled approach to fixing the phantom-word issue is to borrow the idea of re-writing from the theory of operator grammar. That is, certain phrases and constructions can be (should be) re-written into their "proper form", prior to parsing. The re-writing step would insert the missing words, then the parsing proceeds. One appeal of such an approach is that re-writing can also handle other "annoying" phenomena, such as typos (missing apostrophes, eg "lets" vs. "let's", "its" vs. "it's") as well as multi-word rewrites (eg "let's" vs. "let us", or "it's" vs. "it is").
Exactly how to implement this is unclear. However, it seems to open the door to more abstract, semantic analysis. Thus, for example, in Meaning-Text Theory (MTT), one must move between SSynt to DSynt structures. Such changes require a graph re-write from the surface syntax parse (eg provided by link-grammar) to the deep-syntactic structure. By contrast, handling phantom words by graph re-writing prior to parsing inverts the order of processing. This suggests that a more holistic approach is needed to graph rewriting: it must somehow be performed "during" parsing, so that parsing can both guide the insertion of the phantom words, and, simultaneously guide the deep syntactic rewrites.
Another interesting possibility arises with regards to tokenization. The current tokenizer is clever, in that it splits not only on whitespace, but can also strip off prefixes, suffixes, and perform certain limited kinds of morphological splitting. That is, it currently has the ability to re-write single-words into sequences of words. It currently does so in a conservative manner; the letters that compose a word are preserved, with a few exceptions, such as making spelling correction suggestions. The above considerations suggest that the boundary between tokenization and parsing needs to become both more fluid, and more tightly coupled.
Compare "she will be happier than before" to "she will be more happy than before." Current parser makes "happy" the head word, and "more" a modifier w/EA link. I believe the correct solution would be to make "more" the head (link it as a comparative), and make "happy" the dependent. This would harmonize rules for comparatives... and would eliminate/simplify rules for less,more.
However, this idea needs to be double-checked against, eg Hudson's word grammar. I'm confused on this issue ...
Currently, some links can act at "unlimited" length, while others can only be finite-length. eg determiners should be near the noun that they apply to. A better solution might be to employ a 'stretchiness' cost to some connectors: the longer they are, the higher the cost. (This eliminates the "unlimited_connector_set" in the dictionary).
Sometimes, the existence of one parse should suggest that another parse must surely be wrong: if one parse is possible, then the other parses must surely be unlikely. For example: the conjunction and.jg allows the "The Great Southern and Western Railroad" to be parsed as the single name of an entity. However, it also provides a pattern match for "John and Mike" as a single entity, which is almost certainly wrong. But "John and Mike" has an alternative parse, as a conventional-and -- a list of two people, and so the existence of this alternative (and correct) parse suggests that perhaps the entity-and is really very much the wrong parse. That is, the mere possibility of certain parses should strongly disfavor other possible parses. (Exception: Ben & Jerry's ice cream; however, in this case, we could recognize Ben & Jerry as the name of a proper brand; but this is outside of the "normal" dictionary (?) (but maybe should be in the dictionary!))
More examples: "high water" can have the connector A joining high.a and AN joining high.n; these two should either be collapsed into one, or one should be eliminated.
Use WordNet to reduce the number for parses for sentences containing compound verb phrases, such as "give up", "give off", etc.
To avoid a combinatorial explosion of parses, it would be nice to have an incremental parsing, phrase by phrase, using a sliding window algorithm to obtain the parse. Thus, for example, the parse of the last half of a long, run-on sentence should not be sensitive to the parse of the beginning of the sentence.
Doing so would help with combinatorial explosion. So, for example, if the first half of a sentence has 4 plausible parses, and the last half has 4 more, then currently, the parser reports 16 parses total. It would be much more useful if it could instead report the factored results: ie the four plausible parses for the first half, and the four plausible parses for the last half. This would ease the burden on downstream users of link-grammar.
This approach has at psychological support. Humans take long sentences and split them into smaller chunks that "hang together" as phrase- structures, viz compounded sentences. The most likely parse is the one where each of the quasi sub-sentences is parsed correctly.
This could be implemented by saving dangling right-going connectors into a parse context, and then, when another sentence fragment arrives, use that context in place of the left-wall.
This somewhat resembles the application of construction grammar ideas to the link-grammar dictionary. It also somewhat resembles Viterbi parsing to some fixed depth. Viz. do a full backward-forward parse for a phrase, and then, once this is done, take a Viterbi-step. That is, once the phrase is done, keep only the dangling connectors to the phrase, place a wall, and then step to the next part of the sentence.
Caution: watch out for garden-path sentences:
The horse raced past the barn fell.
The old man the boat.
The cotton clothing is made of grows in Mississippi.
The current parser parses these perfectly; a viterbi parser could trip on these.
Other benefits of a Viterbi decoder:
One may argue that Viterbi is a more natural, biological way of working with sequences. Some experimental, psychological support for this can be found at http://www.sciencedaily.com/releases/2012/09/120925143555.htm per Morten Christiansen, Cornell professor of psychology.
Consider the sentence "Thieves rob bank" -- a typical newspaper headline. LG currently fails to parse this, because the determiner is missing ("bank" is a count noun, not a mass noun, and thus requires a determiner. By contrast, "thieves rob water" parses just fine.) A fix for this would be to replace mandatory determiner links by (D- or {[[()]] & headline-flag}) which allows the D link to be omitted if the headline-flag bit is set. Here, "headline-flag" could be a new link-type, but one that is not subject to planarity constraints.
Note that this is easier said than done: if one simply adds a high-cost null link, and no headline-flag, then all sorts of ungrammatical sentences parse, with strange parses; while some grammatical sentences, which should parse, but currently don't, become parsable, but with crazy results.
More examples, from And Rosta:
"when boy meets girl"
"when bat strikes ball"
"both mother and baby are well"
A natural approach would be to replace fixed costs by formulas. This would allow the dialect/sociolect to be dynamically changeable. That is, rather than having a binary headline-flag, there would be a formula for the cost, which could be changed outside of the parsing loop. Such formulas could be used to enable/disable parsing specific to different dialects/sociolects, simply by altering the network of link costs.
A simpler alternative would be to have labeled costs (a cost vector), so that different dialects assign different costs to various links. A dialect would be specified during the parse, thus causing the costs for that dialect to be employed during parse ranking.
This has been implemented; what's missing is a practical tutorial on how this might be used.
A good reference for refining verb usage patterns is: "COBUILD GRAMMAR PATTERNS 1: VERBS from THE COBUILD SERIES", from THE BANK OF ENGLISH, HARPER COLLINS. Online at https://arts-ccr-002.bham.ac.uk/ccr/patgram/ and http://www.corpus.bham.ac.uk/publications/index.shtml
Currently tokenize.c tokenizes double-quotes and some UTF8 quotes (see the RPUNC/LPUNC class in en/4.0.affix - the QUOTES class is not used for that, but for capitalization support), with some very basic support in the English dictionary (see "% Quotation marks." there). However, it does not do this for the various "curly" UTF8 quotes, such as 'these' and “these”. This results is some ugly parsing for sentences containing such quotes. (Note that these are in 4.0.affix).
A mechanism is needed to disentangle the quoting from the quoted text, so that each can be parsed appropriately. It's somewhat unclear how to handle this within link-grammar. This is somewhat related to the problem of morphology (parsing words as if they were "mini-sentences",) idioms (phrases that are treated as if they were single words), set-phrase structures (if ... then ... not only... but also ...) which have a long-range structure similar to quoted text (he said ...).
See also GitHub issue #42.
"to be fishing": Link grammar offers four parses of "I was fishing for evidence", two of which are given low scores, and two are given high scores. Of the two with high scores, one parse is clearly bad. Its links "to be fishing.noun" as opposed to the correct "to be fishing.gerund". That is, I can be happy, healthy and wise, but I certainly cannot be fishing.noun. This is perhaps not just a bug in the structure of the dictionary, but is perhaps deeper: link-grammar has little or no concept of lexical units (ie collocations, idioms, institutional phrases), which thus allows parses with bad word-senses to sneak in.
The goal is to introduce more knowledge of lexical units into LG.
Different word senses can have different grammar rules (and thus, the links employed reveal the sense of the word): for example: "I tend to agree" vs. "I tend to the sheep" -- these employ two different meanings for the verb "tend", and the grammatical constructions allowed for one meaning are not the same as those allowed for the other. Yet, the link rules for "tend.v" have to accommodate both senses, thus making the rules rather complex. Worse, it potentially allows for non-sense constructions. If, instead, we allowed the dictionary to contain different rules for "tend.meaning1" and "tend.meaning2", the rules would simplify (at the cost of inflating the size of the dictionary).
Another example: "I fear so" -- the word "so" is only allowed with some, but not all, lexical senses of "fear". So eg "I fear so" is in the same semantic class as "I think so" or "I hope so", although other meanings of these verbs are otherwise quite different.
[Sin2004] "New evidence, new priorities, new attitudes" in J. Sinclair, (ed) (2004) How to use corpora in language teaching, Amsterdam: John Benjamins
See also: Pattern Grammar: A Corpus-Driven Approach to the Lexical Grammar of English
Susan Hunston and Gill Francis (University of Birmingham)
Amsterdam: John Benjamins (Studies in corpus linguistics, edited by Elena Tognini-Bonelli, volume 4), 2000
書評。
“The Molecular Level of Lexical Semantics”, EA Nida, (1997) International Journal of Lexicography, 10(4): 265–274.オンライン
The link-grammar provides several mechanisms to support circumpositions or even more complicated multi-word structures. One mechanism is by ordinary links; see the V, XJ and RJ links. The other mechanism is by means of post-processing rules. (For example, the "filler-it" SF rules use post-processing.) However, rules for many common forms have not yet been written. The general problem is of supporting structures that have "holes" in the middle, that require "lacing" to tie them together.
For a general theory, see catena.
For example, the adposition:
... from [xxx] on.
"He never said another word from then on."
"I promise to be quiet from now on."
"Keep going straight from that point on."
"We went straight from here on."
... from there on.
"We went straight, from the house on to the woods."
"We drove straight, from the hill onwards."
Note that multiple words can fit in the slot [xxx]. Note the tangling of another prepositional phrase: "... from [xxx] on to [yyy]"
More complicated collocations with holes include
"First.. next..."
"If ... then ..."
'Then' is optional ('then' is a 'null word'), for example:
"If it is raining, stay inside!"
"If it is raining, [then] stay inside!"
"if ... only ..." "If there were only more like you!"
"... not only, ... but also ..."
"As ..., so ..." "As it was commanded, so it shall be done"
"Either ... or ..."
"Both ... and ..." "Both June and Tom are coming"
"ought ... if ..." "That ought to be the case, if John is not lying"
"Someone ... who ..."
"Someone is outside who wants to see you"
"... for ... to ..."
"I need for you to come to my party"
The above are not currently supported. An example that is supported is the "non-referential it", eg
"It ... that ..."
"It seemed likely that John would go"
The above is supported by means of special disjuncts for 'it' and 'that', which must occur in the same post-processing domain.
参照：
http://www.phon.ucl.ac.uk/home/dick/enc2010/articles/extraposition.htm
http://www.phon.ucl.ac.uk/home/dick/enc2010/articles/relative-clause.htm
"...from X and from Y" "By X, and by Y, ..." Here, X and Y might be rather long phrases, containing other prepositions. In this case, the usual link-grammar linkage rules will typically conjoin "and from Y" to some preposition in X, instead of the correct link to "from X". Although adding a cost to keep the lengths of X and Y approximately equal can help, it would be even better to recognize the "...from ... and from..." pattern.
The correct solution for the "Either ... or ..." appears to be this:
---------------------------+---SJrs--+
+------???----------+ |
| +Ds**c+--SJls-+ +Ds**+
| | | | | |
either.r the lorry.n or.j-n the van.n
The wrong solution is
--------------------------+
+-----Dn-----+ +---SJrs---+
| +Ds**c+--SJn--+ +Ds**+
| | | | | |
neither.j the lorry.n nor.j-n the van.n
The problem with this is that "neither" must coordinate with "nor". That is, one cannot say "either.. nor..." "neither ... or ... " "neither ...and..." "but ... nor ..." The way I originally solved the coordination problem was to invent a new link called Dn, and a link SJn and to make sure that Dn could only connect to SJn, and nothing else. Thus, the lower-case "n" was used to propagate the coordination across two links. This demonstrates how powerful the link-grammar theory is: with proper subscripts, constraints can be propagated along links over large distances. However, this also makes the dictionary more complex, and the rules harder to write: coordination requires a lot of different links to be hooked together. And so I think that creating a single, new link, called ???, will make the coordination easy and direct. That is why I like that idea.
The ??? link should be the XJ link, which-see.
More idiomatic than the above examples: "...the chip on X's shoulder" "to do X a favour" "to give X a look"
The above are all examples of "set phrases" or "phrasemes", and are most commonly discussed in the context of MTT or Meaning-Text Theory of Igor Mel'cuk et al (search for "MTT Lexical Function" for more info). Mel'cuk treats set phrases as lexemes, and, for parsing, this is not directly relevant. However, insofar as phrasemes have a high mutual information content, they can dominate the syntactic structure of a sentence.
The current parse of "he wanted to look at and listen to everything." is inadequate: the link to "everything" needs to connect to "and", so that "listen to" and "look at" are treated as atomic verb phrases.
MTT suggests that perhaps the correct way to understand the contents of the post-processing rules is as an implementation of 'lexical functions' projected onto syntax. That is, the post-processing rules allow only certain syntactical constructions, and these are the kinds of constructions one typically sees in certain kinds of lexical functions.
Alternately, link-grammar suffers from a combinatoric explosion of possible parses of a given sentence. It would seem that lexical functions could be used to rule out many of these parses. On the other hand, the results are likely to be similar to that of statistical parse ranking (which presumably captures such quasi-idiomatic collocations at least weakly).
ref。 I. Mel'cuk: "Collocations and Lexical Functions", in ''Phraseology: theory, analysis, and applications'' Ed. Anthony Paul Cowie (1998) Oxford University Press pp. 23-54.
More generally, all of link-grammar could benefit from a MTT-izing of infrastructure.
Compare the above commentary on lexical functions to Hebrew morphological analysis. To quote Wikipedia:
This distinction between the word as a unit of speech and the root as a unit of meaning is even more important in the case of languages where roots have many different forms when used in actual words, as is the case in Semitic languages. In these, roots are formed by consonants alone, and different words (belonging to different parts of speech) are derived from the same root by inserting vowels. For example, in Hebrew, the root gdl represents the idea of largeness, and from it we have gadol and gdola (masculine and feminine forms of the adjective "big"), gadal "he grew", higdil "he magnified" and magdelet "magnifier", along with many other words such as godel "size" and migdal "tower".
Instead of hard-coding LL, declare which links are morpho links in the dict.
Version 6.0 will change Sentence to Sentence*, Linkage to Linkage* in the API. But perhaps this is a bad idea...
