link grammar
1.0.0
Versi 5.12.5
Parser tata bahasa tautan menunjukkan struktur bahasa Inggris (bahasa alami) bahasa Inggris, Thailand, Rusia, Arab, Persia dan terbatas dari setengah lusin bahasa lainnya. Struktur ini adalah grafik tautan yang diketik (tepi) antara kata -kata dalam kalimat. Seseorang dapat memperoleh HPSG yang lebih konvensional (konstituen) dan gaya ketergantungan dari tata bahasa tautan dengan menerapkan kumpulan aturan untuk dikonversi ke format yang berbeda ini. Ini dimungkinkan karena tata bahasa Link sedikit "lebih dalam" ke dalam struktur "sintactico-semantik" dari suatu kalimat: Ini memberikan informasi yang jauh lebih halus dan terperinci daripada apa yang biasanya tersedia di parser konvensional.
Teori penguraian tata bahasa tautan pada awalnya dikembangkan pada tahun 1991 oleh Davy Temperley, John Lafferty dan Daniel Sleator, pada saat profesor linguistik dan ilmu komputer di Universitas Carnegie Mellon. Tiga publikasi perdana pada teori ini memberikan pengantar dan tinjauan terbaik; Sejak itu, ada ratusan publikasi lebih lanjut mengeksplorasi, memeriksa dan memperluas ide -ide tersebut.
Meskipun berdasarkan basis kode Carnegie-Mellon asli, paket tata bahasa tautan saat ini telah berevolusi secara dramatis dan sangat berbeda dari versi sebelumnya. Ada perbaikan bug yang tak terhitung banyaknya; Kinerja telah meningkat dengan beberapa urutan besarnya. Paket ini sepenuhnya multi-threaded, sepenuhnya diaktifkan UTF-8, dan telah digosok untuk keamanan, memungkinkan penyebaran cloud. Cakupan parse bahasa Inggris telah ditingkatkan secara dramatis; Bahasa lain telah ditambahkan (terutama, Thailand dan Rusia). Ada rakit fitur baru, termasuk dukungan untuk morfologi, dialek, dan sistem bobot berbutir halus (biaya), yang memungkinkan perilaku seperti vektor. Ada tokenizer baru yang canggih yang disesuaikan untuk morfologi: ia dapat menawarkan perpecahan alternatif untuk kata -kata yang ambigu secara morfologis. Kamus dapat diperbarui pada run-time, memungkinkan sistem yang melakukan pembelajaran tata bahasa yang berkelanjutan juga untuk menguraikan pada saat yang sama. Artinya, pembaruan kamus dan parsing saling aman. Kelas kata dapat dikenali dengan regex. Parsing grafik planar acak didukung sepenuhnya; Ini memungkinkan pengambilan sampel seragam dari ruang grafik planar. Laporan terperinci tentang apa yang telah berubah dapat ditemukan di Changelog.
Kode ini dirilis di bawah lisensi LGPL, membuatnya tersedia secara bebas untuk penggunaan pribadi dan komersial, dengan beberapa batasan. Ketentuan lisensi diberikan dalam file lisensi yang disertakan dengan perangkat lunak ini.
Silakan lihat halaman web utama untuk informasi lebih lanjut. Versi ini merupakan kelanjutan dari Parser CMU asli.
Pada versi 5.9.0, sistem ini menyertakan sistem eksperimental untuk menghasilkan kalimat. Ini ditentukan menggunakan API "mengisi kekosongan", di mana kata-kata diganti ke lokasi kartu liar, setiap kali hasilnya adalah kalimat yang valid secara tata bahasa. Rincian tambahan ada di halaman pria: man link-generator (di subdirektori man ).
Generator ini digunakan dalam Proyek Pembelajaran Bahasa OpenCog, yang bertujuan untuk secara otomatis mempelajari tata bahasa tautan dari korpora, menggunakan teknik teori informasi baru dan inovatif, agak mirip dengan yang ditemukan dalam jaring saraf buatan (pembelajaran mendalam), tetapi menggunakan representasi simbolik secara eksplisit.
Parser termasuk API dalam berbagai bahasa pemrograman yang berbeda, serta alat baris perintah yang praktis untuk bermain dengannya. Inilah beberapa output khas:
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-
Tampilan yang agak sibuk ini menggambarkan banyak hal menarik. Misalnya, tautan Ss*b menghubungkan kata kerja dan subjek, dan menunjukkan bahwa subjeknya tunggal. Demikian juga, tautan Ost menghubungkan kata kerja dan objek, dan juga menunjukkan bahwa objek tersebut tunggal. Poin tautan WV (Dinding Kata Kerja) di kata kerja kepala kalimat, sedangkan tautan Wd poin di bajingan kepala. Tautan Xp terhubung ke tanda baca trailing. Tautan Ds**c menghubungkan kata benda ke penentu: itu sekali lagi menegaskan bahwa kata benda itu tunggal, dan juga bahwa kata benda dimulai dengan konsonan. (Tautan PH , tidak diperlukan di sini, digunakan untuk memaksa perjanjian fonetik, membedakan 'a' dari 'an'). Jenis tautan ini didokumentasikan dalam dokumentasi tautan bahasa Inggris.
Bagian bawah layar adalah daftar "disjuncts" yang digunakan untuk setiap kata. Disjunct hanyalah daftar konektor yang digunakan untuk membentuk tautan. Mereka sangat menarik karena mereka berfungsi sebagai bentuk "bagian pidato" yang sangat halus. Jadi, misalnya: S- O+ yang terputus-putus menunjukkan kata kerja transitif: itu adalah kata kerja yang mengambil subjek dan objek. Markup tambahan di atas menunjukkan bahwa 'IS' tidak hanya digunakan sebagai kata kerja transitif, tetapi juga menunjukkan detail yang lebih baik: kata kerja transitif yang mengambil subjek tunggal, dan digunakan (dapat digunakan sebagai) kata kerja kepala kalimat. Nilai titik mengambang adalah "biaya" yang terpisah; Ini secara kasar menangkap gagasan tentang probabilitas log dari penggunaan tata bahasa khusus ini. Sama seperti bagian-of-speech berkorelasi dengan maknanya kata, demikian juga bagian-bagian yang halus berkorelasi dengan perbedaan dan gradasi makna yang jauh lebih baik.
Parser tautan-grammar juga mendukung analisis morfologis. Berikut adalah contoh dalam bahasa Rusia:
linkparser> это теста
Linkage 1, cost vector = (UNUSED=0 DIS= 0.00 LEN=4)
+-----MVAip-----+
+---Wd---+ +-LLCAG-+
| | | |
LEFT-WALL это.msi тест.= =а.ndnpi
Tautan LL menghubungkan batang 'тест' ke akhiran 'a'. Tautan MVA hanya menghubungkan ke akhiran, karena, dalam bahasa Rusia, sufiks yang membawa semua struktur sintaksis, dan bukan batangnya. Lexis Rusia didokumentasikan di sini.
Kamus Thailand sekarang sepenuhnya dikembangkan, secara efektif mencakup seluruh bahasa. Contoh di Thailand:
linkparser> นายกรัฐมนตรี ขึ้น กล่าว สุนทรพจน์
Linkage 1, cost vector = (UNUSED=0 DIS= 2.00 LEN=2)
+---------LWs--------+
| +<---S<--+--VS-+-->O-->+
| | | | |
LEFT-WALL นายกรัฐมนตรี.n ขึ้น.v กล่าว.v สุนทรพจน์.n
Tautan VS menghubungkan dua kata kerja 'ขึ้น' dan 'กล่าว' dalam konstruksi kata kerja serial. Ringkasan jenis tautan didokumentasikan di sini. Dokumentasi lengkap tata bahasa tautan Thailand dapat ditemukan di sini.
Tata Bahasa Thai Link juga menerima input yang ditandai dan dinamai-entitas. Setiap kata dapat dijelaskan dengan tag tautan POS. Misalnya:
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[!]
Dokumentasi lengkap untuk Kamus Thailand dapat ditemukan di sini.
Kamus Thailand menerima tagset LST20 untuk PO dan entitas yang disebutkan, untuk menjembatani kesenjangan antara alat NLP mendasar dan parser tautan. Misalnya:
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
Perhatikan bahwa setiap kata di atas dianotasi dengan tag POS LST20 dan tag NE. Dokumentasi lengkap untuk tag POS tautan dan tag LST20 dapat ditemukan di sini. Informasi lebih lanjut tentang LST20, misalnya pedoman anotasi dan statistik data, dapat ditemukan di sini.
Bahasa any mendukung grafik planar acak yang sampel seragam:
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[!]
Bahasa ady juga, melakukan perpecahan morfologis acak:
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]
Tinjauan dan ringkasan yang diperluas dapat ditemukan di halaman tautan tata bahasa Wikipedia, yang menyentuh sebagian besar aspek impor, utama teori. Namun, itu bukan pengganti untuk makalah asli yang diterbitkan pada topik:
Ada lebih banyak makalah dan referensi yang tercantum di situs web tautan tautan utama
Lihat juga dokumentasi API C/C ++. Binding untuk bahasa pemrograman lainnya, termasuk Python3, Java dan Node.js, dapat ditemukan di direktori Bindings. (Ada dua set binding JavaScript: satu set untuk API perpustakaan, dan satu set lain untuk parser baris perintah.)
| Isi | Keterangan |
|---|---|
| LISENSI | Lisensi yang menggambarkan ketentuan penggunaan |
| Changelog | Ringkasan perubahan terbaru. |
| Konfigurasikan | Skrip konfigurasi GNU |
| Autogen.sh | Pengembang Konfigurasi Alat Pemeliharaan |
| Link-Grammar/*. C. | Program. (Ditulis dalam ANSI-C) |
| ---- | ---- |
| binding/autoit/ | Binding Bahasa Autoit Opsional. |
| binding/java/ | Binding Bahasa Java Opsional. |
| Bindings/JS/ | Binding Bahasa JavaScript Opsional. |
| binding/lisp/ | Binding Bahasa Lisp Umum Opsional. |
| binding/node.js/ | Binding bahasa node.js opsional. |
| binding/ocaml/ | Binding Bahasa OCAML Opsional. |
| Bindings/Python/ | Binding bahasa Python3 opsional. |
| Bindings/Python-examples/ | Contoh Uji Link-Grammar dan Contoh Penggunaan Bahasa Python. |
| binding/swig/ | File antarmuka Swig, untuk antarmuka FFI lainnya. |
| binding/vala/ | Binding Bahasa Vala Opsional. |
| ---- | ---- |
| data/en/ | Kamus Bahasa Inggris. |
| Data/EN/4.0.DICT | File yang berisi definisi kamus. |
| Data/EN/4.0. Knowledge | File pengetahuan pasca-pemrosesan. |
| Data/EN/4.0.STituen | File Pengetahuan Konstituen. |
| Data/EN/4.0.Affix | File imbuhan (awalan/sufiks). |
| Data/EN/4.0.Regex | Tebak morfologi berbasis ekspresi reguler. |
| data/en/tiny.dict | Kamus Contoh Kecil. |
| data/en/kata/ | Direktori penuh dengan daftar kata. |
| Data/en/corpus*.batch | Contoh korpora yang digunakan untuk pengujian. |
| ---- | ---- |
| Data/RU/ | Kamus Rusia yang lengkap |
| data/th/ | Kamus Thailand yang lengkap (100.000+ kata) |
| data/ar/ | Kamus Arab yang cukup lengkap |
| Data/FA/ | Kamus Persia (Farsi) |
| data/de/ | Kamus Jerman Prototipe Kecil |
| Data/LT/ | Kamus Lithuania Prototipe Kecil |
| Data/ID/ID | Kamus Prototipe Indonesia Kecil |
| Data/VN/ | Prototipe Kamus Vietnam Kecil |
| Data/He/ | Kamus Ibrani Eksperimental |
| Data/KZ/ | Kamus Kazakh Eksperimental |
| Data/TR/TR/ | Kamus Turki Eksperimental |
| ---- | ---- |
| Morfologi/AR/ | Seorang penganalisa morfologi Arab |
| Morfologi/FA/ | Seorang penganalisa morfologi Persia |
| ---- | ---- |
| Debug/ | Informasi tentang debugging perpustakaan |
| MSVC/ | File Proyek Microsoft Visual-C |
| Mingw/ | Informasi tentang penggunaan MINGW di bawah MSYS atau Cygwin |
Sistem ini didistribusikan menggunakan format tar.gz konvensional; Ini dapat diekstraksi menggunakan perintah tar -zxf link-grammar.tar.gz di baris perintah.
Tarball versi terbaru dapat diunduh dari:
https://www.gnucash.org/link-grammar/downloads/
File -file tersebut telah ditandatangani secara digital untuk memastikan bahwa tidak ada korupsi dataset selama diunduh, dan untuk membantu memastikan bahwa tidak ada perubahan jahat yang dilakukan pada kode internal oleh pihak ketiga. Tanda tangan dapat diperiksa dengan perintah GPG:
gpg --verify link-grammar-5.12.5.tar.gz.asc
yang harus menghasilkan output identik dengan (kecuali untuk tanggal):
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]>"
Bergantian, check-sum MD5 dapat diverifikasi. Ini tidak memberikan keamanan kriptografi, tetapi mereka dapat mendeteksi korupsi sederhana. Untuk memverifikasi check -sums, keluarkan md5sum -c MD5SUM di baris perintah.
Tag di git dapat diverifikasi dengan melakukan yang berikut:
gpg --recv-keys --keyserver keyserver.ubuntu.com EB6AA534E0C0651C
git tag -v link-grammar-5.10.5
Untuk mengkompilasi Program Perpustakaan dan Demonstrasi Bersama Link-Grammar, di baris perintah, ketik:
./configure
make
make check
Untuk menginstal, ubah pengguna menjadi "root" dan katakanlah
make install
ldconfig
Ini akan menginstal perpustakaan liblink-grammar.so ke /usr/local/lib , file header di /usr/local/include/link-grammar , dan kamus ke /usr/local/share/link-grammar . Menjalankan ldconfig akan membangun kembali cache perpustakaan bersama. Untuk memverifikasi bahwa instalasi berhasil, jalankan (sebagai pengguna non-root)
make installcheck
Perpustakaan Link-Grammar memiliki fitur opsional yang diaktifkan secara otomatis jika configure mendeteksi pustaka tertentu. Perpustakaan ini opsional pada sebagian besar sistem dan jika fitur yang mereka tambahkan diinginkan, pustaka yang sesuai perlu diinstal sebelum menjalankan configure .
Nama paket perpustakaan dapat bervariasi pada berbagai sistem (konsultasikan Google jika diperlukan ...). Misalnya, nama -nama tersebut dapat menyertakan -devel bukan -dev , atau tanpa itu sama sekali. Nama perpustakaan mungkin tanpa awalan lib .
libsqlite3-dev (untuk kamus yang didukung sqlite)libz1g-dev atau libz-devel (saat ini diperlukan untuk minisat2 yang dibundel)libedit-dev (lihat Editline)libhunspell-dev atau libaspell-dev (dan kamus bahasa Inggris yang sesuai).libtre-dev atau libpcre2-dev (jauh lebih cepat daripada implementasi libc regex, dan dibutuhkan untuk kebenaran pada freebsd dan cygwin).libpcre2-dev sangat disarankan. Itu harus digunakan pada sistem tertentu (sebagaimana ditentukan dalam bagian bangunan mereka). Jika libedit-dev diinstal, maka tombol panah dapat digunakan untuk mengedit input ke alat tautan-parser; Kunci panah atas dan bawah akan mengingat entri sebelumnya. Anda menginginkan ini; Itu membuat pengujian dan pengeditan lebih mudah.
Dua versi binding node.js disertakan. Satu versi membungkus perpustakaan; Yang lain menggunakan Emscripten untuk membungkus alat baris perintah. Binding perpustakaan berada di bindings/node.js sedangkan pembungkus emscripten ada di bindings/js .
Ini dibangun menggunakan npm . Pertama, Anda harus membangun perpustakaan Core C. Kemudian lakukan hal berikut:
cd bindings/node.js
npm install
npm run make
Ini akan membuat binding perpustakaan dan juga menjalankan tes unit kecil (yang seharusnya lulus). Contoh dapat ditemukan di bindings/node.js/examples/simple.js .
Untuk pembungkus baris perintah, lakukan hal berikut:
cd bindings/js
./install_emsdk.sh
./build_packages.sh
Binding Python3 dibangun secara default, asalkan paket pengembangan Python yang sesuai dipasang. (Binding Python2 tidak lagi didukung.)
Paket -paket ini adalah:
python3-develpython3-dev Catatan: Sebelum menerbitkan configure (lihat di bawah) Anda harus memvalidasi bahwa versi Python yang diperlukan dapat dipanggil menggunakan PATH Anda.
Penggunaan binding python adalah opsional ; Anda tidak memerlukan ini jika Anda tidak berencana untuk menggunakan tautan-tautan dengan Python. Jika Anda ingin menonaktifkan binding Python, gunakan:
./configure --disable-python-bindings
Modul linkgrammar.py menyediakan antarmuka tingkat tinggi di Python. Script example.py dan sentence-check.py menyediakan demo, dan tests.py menjalankan tes unit.
make install pythondir=/where/to/install Secara default, upaya Makefile untuk membangun binding Java. Penggunaan binding Java adalah opsional ; Anda tidak memerlukan ini jika Anda tidak berencana untuk menggunakan tautan-tautan dengan Java. Anda dapat melewatkan membangun binding java dengan menonaktifkan sebagai berikut:
./configure --disable-java-bindings
Jika jni.h tidak ditemukan, atau jika ant tidak ditemukan, maka binding Java tidak akan dibangun.
Catatan tentang menemukan jni.h :
Beberapa distribusi JVM Java yang umum (terutama, yang dari Sun) menempatkan file ini di lokasi yang tidak biasa, di mana ia tidak dapat secara otomatis ditemukan. Untuk memperbaiki ini, pastikan bahwa variabel lingkungan JAVA_HOME diatur dengan benar. Skrip configure mencari jni.h di $JAVA_HOME/Headers dan di $JAVA_HOME/include ; Ini juga memeriksa lokasi yang sesuai untuk $JDK_HOME . Jika jni.h masih belum dapat ditemukan, tentukan lokasi dengan variabel CPPFLAGS : jadi, misalnya,
export CPPFLAGS="-I/opt/jdk1.5/include/:/opt/jdk1.5/include/linux"
atau
export CPPFLAGS="-I/c/java/jdk1.6.0/include/ -I/c/java/jdk1.6.0/include/win32/"
Harap dicatat bahwa penggunaan /opt tidak standar, dan sebagian besar alat sistem akan gagal menemukan paket yang diinstal di sana.
Target Instalasi /usr/local dapat ditempa berlebihan menggunakan opsi-opsi configure --prefix GNU standar; Jadi, misalnya:
./configure --prefix=/opt/link-grammar
Dengan menggunakan pkg-config (lihat di bawah), lokasi instalasi non-standar dapat dideteksi secara otomatis.
Opsi konfigurasi tambahan dicetak oleh
./configure --help
Sistem ini telah diuji dan bekerja dengan baik pada sistem Linux 32 dan 64-bit, FreeBSD, MacOS, serta pada sistem Microsoft Windows. Catatan yang bergantung pada OS spesifik mengikuti.
Pengguna akhir harus mengunduh tarball (lihat verifikasi pembongkaran dan tanda tangan).
Versi GitHub saat ini ditujukan untuk pengembang (termasuk siapa pun yang bersedia memberikan perbaikan, fitur baru atau peningkatan). Ujung cabang master seringkali tidak stabil, dan kadang -kadang dapat memiliki kode buruk di dalamnya karena sedang dalam pengembangan. Ini juga perlu menginstal alat pengembangan yang tidak diinstal secara default. Karena alasan ini penggunaan versi GitHub tidak dianjurkan untuk pengguna akhir biasa.
Kloning itu: git clone https://github.com/opencog/link-grammar.git
Atau unduh sebagai zip:
https://github.com/opencog/link-grammar/archive/master.zip
Alat yang mungkin memerlukan instalasi sebelum Anda dapat membangun tautan-grammar:
make (varian gmake mungkin diperlukan)
m4
gcc atau clang
autoconf
libtool
autoconf-archive
pkg-config (dapat dinamai pkgconf atau pkgconfig )
pip3 (untuk binding ularin)
Opsional:
swig (untuk binding bahasa)
flex
Apache Ant (untuk binding Java)
graphviz (jika Anda ingin menggunakan fitur tampilan Word-Graph)
Versi GitHub tidak termasuk skrip configure . Untuk menghasilkannya, gunakan:
autogen.sh
Jika Anda mendapatkan kesalahan, pastikan Anda telah menginstal paket pengembangan di atas, dan bahwa instalasi sistem Anda terbaru. Terutama, kehilangan autoconf atau autoconf-archive dapat menyebabkan kesalahan yang aneh dan menyesatkan.
Untuk info lebih lanjut tentang cara melanjutkan, lanjutkan di bagian yang membuat sistem dan bagian yang relevan setelahnya.
Untuk mengonfigurasi mode debug , gunakan:
configure --enable-debug
Ini menambahkan beberapa kode debug verifikasi dan fungsi yang dapat mencetak beberapa struktur data.
Fitur yang mungkin berguna untuk debugging adalah tampilan kata-grafik. Diaktifkan secara default. Untuk detail lebih lanjut tentang fitur ini, lihat tampilan Word-Graph.
Konfigurasi saat ini memiliki masalah pencampuran perpustakaan C ++ standar yang jelas saat gcc digunakan (perbaikan diterima). Namun, praktik umum pada FreeBSD adalah untuk dikompilasi dengan clang , dan tidak memiliki masalah ini. Selain itu, paket add-on diinstal di bawah /usr/local .
Jadi inilah cara configure yang harus dipanggil:
env LDFLAGS=-L/usr/local/lib CPPFLAGS=-I/usr/local/include
CC=clang CXX=clang++ configure
Perhatikan bahwa pcre2 adalah paket yang diperlukan karena implementasi libc Regex yang ada tidak memiliki tingkat dukungan Regex yang diperlukan.
Beberapa paket memiliki nama yang berbeda dari yang disebutkan di bagian sebelumnya:
minisat (Minisat2) pkgconf (PKG-Config)
Tata bahasa link vanilla polos harus dikompilasi dan dijalankan pada macos apel dengan baik, seperti dijelaskan di atas. Pada saat ini, tidak ada masalah yang dilaporkan.
Jika Anda tidak memerlukan binding Java, Anda hampir pasti harus mengonfigurasi dengan:
./configure --disable-java-bindings
Jika Anda menginginkan binding Java, pastikan untuk mengatur variabel lingkungan JDK_HOME ke mana pun <Headers/jni.h> adalah. Atur variabel java_home ke lokasi kompiler java. Pastikan Anda telah menginstal semut.
Jika Anda ingin membangun dari GitHub (lihat bangunan dari repositori GitHub), Anda dapat menginstal alat yang terdaftar di sana menggunakan Homebrew.
Ada tiga cara berbeda di mana tautan dapat dikompilasi di windows. Salah satu caranya adalah dengan menggunakan Cygwin, yang menyediakan lapisan kompatibilitas Linux untuk Windows. Cara lain adalah menggunakan sistem MSVC. Cara ketiga adalah dengan menggunakan sistem MINGW, yang menggunakan GNU Toolset untuk mengkompilasi program Windows. Kode sumber mendukung sistem Windows dari Vista on.
Cygwin Way saat ini menghasilkan hasil terbaik, karena mendukung pengeditan baris dengan penyelesaian perintah dan sejarah dan juga mendukung penampilan grafik kata di X-Windows. (MINGW saat ini tidak memiliki libedit , dan port MSVC saat ini tidak mendukung penyelesaian perintah dan sejarah, dan juga ejaan.
Cara termudah untuk memiliki tautan-tautan yang bekerja pada MS Windows adalah dengan menggunakan Cygwin, lingkungan seperti Linux untuk Windows sehingga memungkinkan untuk port perangkat lunak yang berjalan pada sistem POSIX ke Windows. Unduh dan instal Cygwin.
Perhatikan bahwa instalasi paket pcre2 diperlukan karena implementasi LIBC Regex tidak cukup mampu.
Untuk detail lebih lanjut, lihat Mingw/Readme-Cygwin.md.
Cara lain untuk membangun tautan-tautan adalah dengan menggunakan MINGW, yang menggunakan toolset GNU untuk mengkompilasi program POSIX yang sesuai untuk Windows. Menggunakan MINGW/MSYS2 mungkin merupakan cara termudah untuk mendapatkan binding Java yang bisa diterapkan untuk Windows. Unduh dan instal mingw/msys2 dari msys2.org.
Perhatikan bahwa instalasi paket pcre2 diperlukan karena implementasi LIBC Regex tidak cukup mampu.
Untuk detail lebih lanjut, lihat Mingw/Readme-Mingw64.md.
File proyek Microsoft Visual C/C ++ dapat ditemukan di direktori msvc . Untuk petunjuk, lihat file readme.md di sana.
Untuk menjalankan masalah program perintah (seandainya ada di jalur Anda):
link-parser [arguments]
Ini memulai program. Program ini memiliki banyak variabel dan opsi yang dapat diselesaikan pengguna. Ini dapat ditampilkan dengan memasukkan !var di prompt tautan-parser. Memasuki !help akan menampilkan beberapa perintah tambahan.
Kamus diatur dalam direktori yang namanya adalah kode bahasa 2-huruf. Program Link-Parser mencari direktori bahasa seperti itu dalam urutan itu, secara langsung atau di bawah data nama direktori:
/usr/local/share/link-grammar ).Jika Link-Parser tidak dapat menemukan kamus yang diinginkan, gunakan Verbosity Level 4 untuk men-debug masalah; Misalnya:
link-parser ru -verbosity=4
Lokasi lain dapat ditentukan pada baris perintah; Misalnya:
link-parser ../path/to-my/modified/data/en
Saat mengakses kamus di lokasi non-standar, nama-nama file standar masih diasumsikan ( yaitu 4.0.dict , 4.0.affix , dll. ).
Kamus Rusia ada di data/ru . Dengan demikian, parser Rusia dapat dimulai sebagai:
link-parser ru
Jika Anda tidak menyediakan argumen ke tautan-parser, ia mencari bahasa sesuai dengan pengaturan lokal Anda saat ini. Jika tidak dapat menemukan direktori bahasa seperti itu, itu default untuk "en".
Jika Anda melihat kesalahan yang mirip dengan ini:
Warning: The word "encyclop" found near line 252 of en/4.0.dict
matches the following words:
encyclop
This word will be ignored.
Maka daerah UTF-8 Anda tidak diinstal atau tidak dikonfigurasi. Perintah Shell locale -a harus mendaftar en_US.utf8 sebagai lokal. Jika tidak, maka Anda perlu dpkg-reconfigure locales dan/atau menjalankan update-locale atau mungkin apt-get install locales , atau kombinasi atau varian dari ini, tergantung pada sistem operasi Anda.
Ada beberapa cara untuk menguji build yang dihasilkan. Jika binding Python dibangun, maka program pengujian dapat ditemukan dalam file ./bindings/python-examples/tests.py dijalankan, itu harus dilewati. Untuk detail lebih lanjut, lihat ReadMe.md di Direktori bindings/python-examples .
Ada juga beberapa kumpulan kalimat tes/contoh dalam direktori data bahasa, umumnya memiliki nama corpus-*.batch Program parser dapat dijalankan dalam mode batch, untuk menguji sistem pada sejumlah besar kalimat. Perintah berikut menjalankan parser pada file yang disebut corpus-basic.batch ;
link-parser < corpus-basic.batch
Garis !batch di dekat bagian atas corpus-basic.batch menyalakan mode batch. Dalam mode ini, kalimat yang diberi label dengan awal * harus ditolak dan yang tidak dimulai dengan * harus diterima. File batch ini memang melaporkan beberapa kesalahan, seperti halnya file corpus-biolg.batch dan corpus-fixes.batch . Pekerjaan sedang berlangsung untuk memperbaikinya.
File corpus-fixes.batch berisi ribuan kalimat yang telah ditetapkan sejak rilis tautan 4.1 tautan asli. corpus-biolg.batch berisi kalimat biologi/medis-teks dari proyek BIOLG. corpus-voa.batch berisi sampel dari Voice of America; corpus-failures.batch berisi sejumlah besar kegagalan.
Angka -angka berikut dapat berubah, tetapi, pada saat ini, jumlah kesalahan yang dapat diharapkan untuk diamati oleh masing -masing file ini secara kasar sebagai berikut:
en/corpus-basic.batch: 88 errors
en/corpus-fixes.batch: 371 errors
lt/corpus-basic.batch: 15 errors
ru/corpus-basic.batch: 47 errors
Direktori binding/python berisi uji unit untuk binding python. Ini juga melakukan beberapa cek dasar yang menekankan perpustakaan tautan-grammar.
Ada API (antarmuka program aplikasi) ke parser. Ini membuatnya mudah untuk memasukkannya ke dalam aplikasi Anda sendiri. API didokumentasikan di situs web.
File FindLinkGrammar.cmake dapat digunakan untuk menguji dan mengatur kompilasi di lingkungan build berbasis CMake.
Untuk membuat kompilasi dan menghubungkan lebih mudah, rilis saat ini menggunakan sistem PKG-Config. Untuk menentukan lokasi file header tautan-tautan, katakanlah pkg-config --cflags link-grammar untuk mendapatkan lokasi perpustakaan, katakanlah pkg-config --libs link-grammar dengan demikian, misalnya, makefile khas mungkin termasuk target:
.c.o:
cc -O2 -g -Wall -c $< `pkg-config --cflags link-grammar`
$(EXE): $(OBJS)
cc -g -o $@ $^ `pkg-config --libs link-grammar`
Rilis ini menyediakan file Java yang menawarkan tiga cara untuk mengakses parser. Cara paling sederhana adalah dengan menggunakan kelas org.linkgrammar.linkgrammar; Ini memberikan Java API yang sangat sederhana untuk parser.
Kemungkinan kedua adalah menggunakan kelas layanan LGS. Ini mengimplementasikan server jaringan TCP/IP, memberikan hasil parse sebagai pesan JSON. Setiap klien berkemampuan JSON dapat terhubung ke server ini dan mendapatkan teks parsed.
Kemungkinan ketiga adalah menggunakan kelas org.linkgrammar.lgremoteclient, dan khususnya, metode parse (). Kelas ini adalah klien jaringan yang terhubung ke server JSON, dan mengubah respons kembali ke hasil yang dapat diakses melalui Parseresult API.
Kode yang dijelaskan di atas akan dibangun jika ant Apache diinstal.
Server jaringan dapat dimulai dengan mengatakan:
java -classpath linkgrammar.jar org.linkgrammar.LGService 9000
Di atas memulai server pada port 9000. Ini port dihilangkan, teks bantuan dicetak. Server ini dapat dihubungi langsung melalui TCP/IP; Misalnya:
telnet localhost 9000
(Bergantian, gunakan netcat bukan telnet). Setelah menghubungkan, ketik in:
text: this is an example sentence to parse
Byte yang dikembalikan akan menjadi pesan JSON yang memberikan parse kalimat. Secara default, parse ascii-art dari teks tidak ditransmisikan. Ini dapat diperoleh dengan mengirim pesan formulir:
storeDiagramString:true, text: this is a test.
Parser akan menjalankan pemeriksaan ejaan pada tahap awal, jika menemukan kata yang tidak diketahui, dan tidak bisa menebak, berdasarkan morfologi. Skrip konfigurasi mencari perekam ejaan Aspell atau Hunspell; Jika lingkungan Devel Aspell ditemukan, maka Aspell digunakan, selain itu Hunspell digunakan.
Tebak mantra dapat dinonaktifkan saat runtime, di klien tautan-parser dengan !spell=0 Masukkan !help untuk lebih jelasnya.
Perhatian: Aspell Versi 0.60.8 dan mungkin yang lain memiliki kebocoran memori. Penggunaan penebangan mantra di server produksi sangat tidak dianjurkan. Menjaga penebangan mantra dinonaktifkan ( =0 ) di Parse_Options aman.
Aman menggunakan tautan-tautan di beberapa utas. Thread dapat berbagi kamus yang sama. Opsi parse dapat ditetapkan berdasarkan per-thread, dengan pengecualian verbositas, yang merupakan global, dibagikan oleh semua utas. Itu adalah satu -satunya global.
A/AN Penentu fonetik sebelum konsonan/vokal ditangani oleh tipe tautan pH baru, menghubungkan penentu ke kata segera mengikutinya. Status: Diperkenalkan dalam versi 5.1.0 (Agustus 2014). Sebagian besar dilakukan, meskipun banyak kata benda kasus khusus yang belum selesai.
Tautan terarah diperlukan untuk beberapa bahasa, seperti bahasa Lithuania, Turki, dan kata-kata order gratis lainnya. Tujuannya adalah untuk memiliki tautan dengan jelas menunjukkan kata mana yang merupakan kata kepala, dan mana yang tergantung. Ini dicapai dengan mengawali konektor dengan satu huruf kecil : h, d, menunjukkan 'kepala' dan 'tergantung'. Aturan keterkaitan sedemikian rupa sehingga H cocok dengan tidak ada atau D, dan D cocok dengan H atau tidak sama sekali. Ini adalah fitur baru dalam versi 5.1.0 (Agustus 2014). Situs web menyediakan dokumentasi tambahan.
Meskipun tautan tautan bahasa Inggris tidak berorientasi, tampaknya arah de facto dapat diberikan kepada mereka yang sepenuhnya konsisten dengan konsepsi standar tata bahasa ketergantungan.
Panah ketergantungan memiliki sifat berikut:
Anti-refleksif (kata tidak dapat bergantung pada dirinya sendiri; ia tidak dapat menunjuk pada dirinya sendiri.)
Anti-simetris (jika Word1 tergantung pada Word2, maka Word2 tidak dapat bergantung pada Word1) (jadi, misalnya penentu bergantung pada kata benda, tetapi tidak pernah sebaliknya)
Panahnya tidak transitif, atau anti-transitif: satu kata dapat diperintah oleh beberapa kepala. Misalnya:
+------>WV------->+
+-->Wd-->+<--Ss<--+
| | |
LEFT-WALL she thinks.v
Artinya, ada jalan menuju subjek, "dia", langsung dari dinding kiri, melalui tautan WD, serta secara tidak langsung, dari dinding ke kata kerja root, dan kemudian ke subjek. Loop serupa terbentuk dengan tautan B dan R. Loop semacam itu berguna untuk membatasi jumlah parse yang mungkin: kendala terjadi bersamaan dengan meta-aturan "no link cross".
Ada beberapa gagasan matematika terkait, tetapi tidak ada yang cukup menangkap Directional LG:
Grafik LG directional menyerupai DAG, kecuali bahwa LG hanya memungkinkan satu dinding (satu elemen "atas").
Grafik LG directional menyerupai pesanan parsial yang ketat, kecuali bahwa panah LG biasanya tidak transitif.
Grafik LG directional menyerupai catena kecuali bahwa Catena benar-benar anti-transitif-jalan menuju kata apa pun adalah unik, dalam catena.
Makalah LG dasar mengamanatkan planaritas grafik parse. Ini didasarkan pada pengamatan yang sangat lama bahwa ketergantungan hampir tidak pernah menyeberang dalam bahasa alami: manusia sama sekali tidak berbicara dalam kalimat di mana tautan menyeberang. Mengenakan kendala planaritas kemudian memberikan rekayasa yang kuat dan kendala algoritmik pada parse yang dihasilkan: jumlah total parse yang akan dipertimbangkan berkurang secara tajam, dan dengan demikian kecepatan parsing secara keseluruhan dapat sangat meningkat.
Namun, ada sesekali, pengecualian yang relatif jarang untuk aturan planaritas ini; Pengecualian tersebut diamati di hampir semua bahasa. Sejumlah pengecualian ini diberikan untuk bahasa Inggris, di bawah ini.
Dengan demikian, tampaknya penting untuk melonggarkan kendala planaritas, dan menemukan hal lain yang hampir sama ketatnya, tetapi masih memungkinkan pengecualian yang jarang. Tampak bahwa konsep "transitivitas tengara" sebagaimana didefinisikan oleh Richard Hudson dalam teorinya tentang "tata bahasa kata", dan kemudian dianjurkan oleh Ben Goertzel, mungkin saja mekanisme seperti itu.
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
Dalam praktiknya, kendala planaritas memungkinkan algoritma yang sangat efisien untuk digunakan dalam implementasi parser. Dengan demikian, dari sudut pandang implementasi, kami ingin menjaga planaritas. Untungnya, ada cara yang nyaman dan tidak ambigu untuk memiliki kue kami dan memakannya juga. Diagram non-planar dapat ditarik pada selembar kertas menggunakan notasi rekayasa listrik standar: simbol lucu, di mana pun kabel menyeberang. Notasi ini sangat mudah disesuaikan dengan konektor LG; Di bawah ini adalah contoh kerja yang sebenarnya, yang sudah diimplementasikan dalam Kamus Bahasa Inggris LG saat ini. Semua penyeberangan tautan dapat diimplementasikan dengan cara ini! Jadi kita tidak harus benar-benar meninggalkan algoritma parsing saat ini untuk mendapatkan diagram non-planar. Kami bahkan tidak perlu memodifikasinya! Hore!
Berikut adalah contoh yang berfungsi: "Saya ingin melihat dan mendengarkan semuanya." Ini menginginkan dua tautan J yang menunjuk ke 'semuanya'. Diagram yang diinginkan perlu terlihat seperti ini:
+---->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
Di atas benar -benar ingin memiliki tautan Js dari 'di' ke 'semuanya', tetapi tautan Js ini melintasi (bentrokan dengan - ditandai oleh xxx) tautan ke konjungsi. Contoh lain menunjukkan bahwa seseorang harus memungkinkan sebagian besar tautan untuk melintasi tautan ke bawah ke konjungsi.
Planarity-maintaining working-around adalah untuk membagi tautan Js menjadi dua: bagian Jj dan bagian Jk ; Keduanya digunakan bersama untuk melintasi konjungsi. Ini saat ini diimplementasikan dalam Kamus Bahasa Inggris, dan berhasil.
Kerja ini sebenarnya benar-benar generik, dan dapat diperluas ke segala jenis penyeberangan tautan. Agar ini berfungsi, notasi yang lebih baik akan lebih nyaman; 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. Demikian pula:
"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. Yaitu. 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
Ulasan buku.
“The Molecular Level of Lexical Semantics”, EA Nida, (1997) International Journal of Lexicography, 10(4): 265–274. On line
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.
Lihat juga:
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...
