link grammar
1.0.0
버전 5.12.5
링크 문법 파서는 영어, 태국, 러시아어, 아랍어, 페르시아어 및 제한된 기타 언어의 언어 적 (자연어) 구조를 보여줍니다. 이 구조는 문장의 단어들 사이의 유형 링크 (모서리)의 그래프입니다. 하나는 이러한 다른 형식으로 변환하기 위해 규칙 모음을 적용하여 링크 문법에서보다 기존의 HPSG (구성 요소) 및 종속성 스타일 구문 분석을 얻을 수 있습니다. Link Grammar는 문장의 "Syntactico-Semantic"구조로 약간 더 깊어지기 때문에 가능합니다. 기존의 구문 분석에서 일반적으로 사용할 수있는 것보다 상당히 세밀하고 상세한 정보를 제공합니다.
링크 문법 파싱 이론은 원래 1991 년 Carnegie Mellon University의 언어학 및 컴퓨터 과학 교수 인 Davy Temperley, John Lafferty 및 Daniel Sleator에 의해 개발되었습니다. 이 이론에 관한 세 가지 초기 출판물은 최고의 소개 및 개요를 제공합니다. 그 이후로, 아이디어를 더 탐구, 검토 및 확장하는 수백 개의 간행물이 더 많이있었습니다.
원래 Carnegie-Mellon 코드 기반을 기반으로하지만 현재 링크 문법 패키지는 극적으로 진화되었으며 이전 버전과 크게 다릅니다. 수많은 버그 수정이있었습니다. 성능은 몇 배 순서로 향상되었습니다. 이 패키지는 완전히 스레드 된 완전히 스레드되고 완전히 UTF-8이 활성화되어 있으며 보안을 위해 문지르면서 클라우드 배포가 가능합니다. 영어의 구문 분석 범위는 극적으로 향상되었습니다. 다른 언어가 추가되었습니다 (특히 태국어와 러시아어). 형태, 방언 및 세밀한 체중 (비용) 시스템에 대한 지원을 포함하여 새로운 기능의 뗏목이있어 벡터-배출 형 동작을 허용합니다. 형태를 위해 맞춤화 된 새롭고 정교한 토큰 화기가 있습니다. 형태 학적으로 모호한 단어에 대한 대체 분할을 제공 할 수 있습니다. 사전은 런타임에 업데이트 될 수 있으므로 문법에 대한 지속적인 학습을 수행하는 시스템이 동시에 구문 분석 할 수 있습니다. 즉, 사전 업데이트와 구문 분석은 상호 스레드 안전입니다. 단어 클래스는 regexes로 인식 할 수 있습니다. 임의의 평면 그래프 구문 분석이 완전히 지원됩니다. 이를 통해 평면 그래프 공간의 균일 한 샘플링이 가능합니다. 변경 사항에 대한 자세한 보고서는 Changelog에서 찾을 수 있습니다.
이 코드는 LGPL 라이센스에 따라 릴리스되므로 제한 사항이 거의없이 개인 및 상업용으로 자유롭게 사용할 수 있습니다. 라이센스 조건은이 소프트웨어에 포함 된 라이센스 파일에 나와 있습니다.
자세한 내용은 기본 웹 페이지를 참조하십시오. 이 버전은 원래 CMU 파서의 연속입니다.
버전 5.9.0 기준으로 시스템에는 문장을 생성하기위한 실험 시스템이 포함되어 있습니다. 이들은 문법적으로 유효한 문장이 될 때마다 단어가 야생 카드 위치로 대체되는 "공백 채우기"API를 사용하여 지정됩니다. 추가 세부 사항은 Man Page : man link-generator ( man Subdirectory)에 있습니다.
이 생성기는 OpenCog Language Learning Project에서 사용됩니다.이 프로젝트는 인공 신경망 (딥 러닝)에서 발견되는 것과 다소 유사하지만 명시 적으로 상징적 인 표현을 사용하는 브랜드 및 혁신적인 정보 이론 기술을 사용하여 Corpora의 링크 문법을 자동으로 학습하는 것을 목표로합니다.
파서에는 다양한 프로그래밍 언어의 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 (Verb-Wall)는 문장의 헤드 벤트를 링크하고 Wd 링크는 헤드 명사를 가리 킵니다. Xp 링크는 후행 구두점에 연결됩니다. Ds**c 링크는 명사를 결정자에 연결합니다. 명사가 단수이며 명사가 자음으로 시작되었음을 다시 확인합니다. (여기서 필요하지 않은 PH 링크는 'a'와 ''와 구별되는 음성 합의를 강요하는 데 사용됩니다). 이 링크 유형은 영어 링크 문서에 문서화되어 있습니다.
디스플레이의 하단은 각 단어에 사용되는 "분리"의 목록입니다. 분리는 단순히 링크를 형성하는 데 사용 된 커넥터 목록입니다. 그들은 "연설의 일부"의 매우 세밀한 형태로 작용하기 때문에 특히 흥미 롭습니다. 따라서, 예를 들어 : 분리 S- O+ 전이 동사를 나타냅니다. 그 동사는 피사체와 대상을 모두 취합니다. 위의 추가 마크 업은 'is'가 전이 동사로 사용될뿐만 아니라 더 미세한 세부 사항을 나타냅니다. 단수 주제를 취하고 문장의 머리 동사로 사용되었습니다 (사용 가능). 부동 소수점 값은 분리의 "비용"입니다. 그것은이 특정 문법적 사용의 로그 확률에 대한 아이디어를 대략적으로 포착합니다. 음성 부품의 부품이 단어 주식과 상관 관계가있는 한, 미세 입자는 말의 부품 부분이 훨씬 더 미세한 차이와 의미의 그라데이션과 관련이 있습니다.
Link-Grammar Parser는 또한 형태 학적 분석을 지원합니다. 다음은 러시아의 예입니다.
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 링크는 직렬 동사 구조에서 두 동사 'ขึ้น'와 'กล่าว'를 연결합니다. 링크 유형의 요약은 여기에 문서화되어 있습니다. 태국 링크 문법에 대한 전체 문서는 여기에서 찾을 수 있습니다.
태국 링크 문법은 또한 포즈 태그 및 이름이 지정된 입력을 허용합니다. 각 단어는 링크 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[!]
태국 사전에 대한 전체 문서는 여기에서 찾을 수 있습니다.
태국 사전은 POS 및 명명 된 엔티티의 LST20 태그 세트를 받아 기본 NLP 도구와 링크 파서 사이의 간격을 연결합니다. 예를 들어:
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, EG 주석 가이드 라인 및 데이터 통계에 대한 자세한 내용은 여기를 참조하십시오.
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]
확장 된 개요 및 요약은 링크 문법 위키 백과 페이지에서 찾을 수 있으며, 대부분의 수입, 이론의 주요 측면을 다루고 있습니다. 그러나 주제에 대해 발표 된 원본 논문을 대체 할 수 없습니다.
기본 링크 문법 웹 사이트에 나열된 더 많은 논문과 참조가 있습니다.
C/C ++ API 문서도 참조하십시오. Python3, Java 및 Node.js를 포함한 다른 프로그래밍 언어의 바인딩은 바인딩 디렉토리에서 찾을 수 있습니다. (두 세트의 JavaScript 바인딩이 있습니다 : 하나는 라이브러리 API 세트와 명령 줄 파서의 다른 세트입니다.)
| 콘텐츠 | 설명 |
|---|---|
| 특허 | 사용 약관을 설명하는 라이센스 |
| changelog | 최근 변화의 개요. |
| 구성 | GNU 구성 스크립트 |
| Autogen.sh | 개발자의 유지 보수 도구 구성 |
| 링크-그램/*. c | 프로그램. (ANSI-C로 작성) |
| ---- | ---- |
| 바인딩/오토이트/ | 선택적인 자동 설정 언어 바인딩. |
| 바인딩/자바/ | 선택적 자바 언어 바인딩. |
| 바인딩/JS/ | 선택적 자바 스크립트 언어 바인딩. |
| 바인딩/lisp/ | 선택적 일반적인 LISP 언어 바인딩. |
| 바인딩/node.js/ | 옵션 Node.js 언어 바인딩. |
| 바인딩/ocaml/ | 선택적 OCAML 언어 바인딩. |
| 바인딩/파이썬/ | Python3 언어 바인딩 옵션. |
| 바인딩/파이썬-예고/ | 링크 그래머 테스트 스위트 및 파이썬 언어 바인딩 사용 예제. |
| 바인딩/SWIG/ | 다른 FFI 인터페이스의 경우 SWIG 인터페이스 파일. |
| 바인딩/발라/ | 옵션 발라 언어 바인딩. |
| ---- | ---- |
| 데이터/en/ | 영어 사전. |
| 데이터/en/4.0.dict | 사전 정의가 포함 된 파일. |
| 데이터/en/4.0. Knowledge | 후 처리 지식 파일. |
| 데이터/en/4.0. 구성 요소 | 구성 지식 파일. |
| 데이터/en/4.0.affix | 부착 (접두사/접미사) 파일. |
| 데이터/en/4.0.regex | 정규 표현 기반 형태 추측 자. |
| 데이터/en/tiny.dict | 작은 예제 사전. |
| 데이터/en/단어/ | 단어 목록으로 가득 찬 디렉토리. |
| 데이터/en/corpus*.batch | 예제 테스트에 사용되는 Corpora. |
| ---- | ---- |
| 데이터/루/ | 본격적인 러시아 사전 |
| 데이터/th/ | 본격적인 태국 사전 (10 만 명 이상) |
| 데이터/AR/ | 상당히 완전한 아랍어 사전 |
| 데이터/fa/ | 페르시아 (Farsi) 사전 |
| 데이터/de/ | 작은 프로토 타입 독일 사전 |
| 데이터/lt/ | 작은 프로토 타입 리투아니아 사전 |
| 데이터/ID/ | 작은 프로토 타입 인도네시아 사전 |
| 데이터/vn/ | 작은 프로토 타입 베트남 사전 |
| 데이터/HE/ | 실험적인 히브리 사전 |
| 데이터/kz/ | 실험 카자흐 사전 |
| 데이터/tr/ | 실험적인 터키 사전 |
| ---- | ---- |
| 형태/AR/ | 아랍어 형태 분석기 |
| 형태/fa/ | 페르시아 형태 분석기 |
| ---- | ---- |
| 디버그/ | 라이브러리 디버깅에 대한 정보 |
| MSVC/ | Microsoft Visual-C 프로젝트 파일 |
| mingw/ | MSYS 또는 Cygwin에서 Mingw 사용에 대한 정보 |
시스템은 기존 tar.gz 형식을 사용하여 배포됩니다. 명령 줄에서 tar -zxf link-grammar.tar.gz 명령을 사용하여 추출 할 수 있습니다.
최신 버전의 Tarball은 다음에서 다운로드 할 수 있습니다.
https://www.gnucash.org/link-grammar/downloads/
다운로드 중에 데이터 세트가 부패하지 않았는지 확인하고 제 3자가 코드 내부에 악의적 인 변경을 수행하지 않도록 파일에 디지털 서명되었습니다. 서명은 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
설치하려면 사용자를 "루트"로 변경하고 말하십시오
make install
ldconfig
liblink-grammar.so 라이브러리를 /usr/local/lib , 헤더 파일 /usr/local/include/link-grammar 및 사전을 /usr/local/share/link-grammar 로 설치합니다. ldconfig 실행하면 공유 라이브러리 캐시가 재건됩니다. 설치가 성공했는지 확인하려면 (뿌리가 아닌 사용자로서) 실행하십시오.
make installcheck
Link-Grammar 라이브러리에는 특정 라이브러리를 configure 하면 자동으로 활성화 된 옵션 기능이 있습니다. 이러한 라이브러리는 대부분의 시스템에서 선택 사항이며 추가 기능이 원하는 경우 configure 실행하기 전에 해당 라이브러리를 설치해야합니다.
라이브러리 패키지 이름은 다양한 시스템마다 다를 수 있습니다 (필요한 경우 Google을 참조하십시오 ...). 예를 들어, 이름에는 -dev 대신 -devel 포함되거나 전혀 없을 수 있습니다. 라이브러리 이름은 접두사 lib 없을 수 있습니다.
libsqlite3-dev (sqlite-backed dictionary 용)libz1g-dev 또는 libz-devel (현재 번들 minisat2 에 필요)libedit-dev (편집자 참조)libhunspell-dev 또는 libaspell-dev (및 해당 영어 사전).libtre-dev 또는 libpcre2-dev (libc Regex 구현보다 훨씬 빠르며 freebsd 및 cygwin에 대한 정확성에 필요).libpcre2-dev 사용하는 것이 좋습니다. 건물 섹션에 지정된 특정 시스템에서 사용해야합니다. libedit-dev 설치된 경우 화살표 키를 사용하여 입력을 링크 패러 도구로 편집 할 수 있습니다. 위와 아래쪽 화살표 키는 이전 항목을 기억합니다. 당신은 이것을 원합니다. 테스트 및 편집이 훨씬 쉬워집니다.
Node.js 바인딩의 두 가지 버전이 포함되어 있습니다. 하나의 버전은 라이브러리를 랩핑합니다. 다른 하나는 emscripten을 사용하여 명령 줄 도구를 포장합니다. 라이브러리 바인딩은 bindings/node.js 에 있고 emscripten 래퍼는 bindings/js 에 있습니다.
이들은 npm 사용하여 제작되었습니다. 먼저 Core 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 발행하기 전에 (아래 참조) 필요한 파이썬 버전을 PATH 사용하여 호출 할 수 있는지 확인해야합니다.
파이썬 바인딩의 사용은 선택 사항 입니다. 파이썬과 함께 링크-그램을 사용할 계획이라면 필요하지 않습니다. 파이썬 바인딩을 비활성화하려면 다음을 사용하십시오.
./configure --disable-python-bindings
linkgrammar.py 모듈은 Python에서 높은 수준의 인터페이스를 제공합니다. example.py 및 sentence-check.py 스크립트는 데모를 제공하고 tests.py 단위 테스트를 실행합니다.
make install pythondir=/where/to/install 말함으로써 수행 할 수 있습니다 기본적으로 Makefile 은 Java 바인딩을 구축하려고합니다. Java 바인딩의 사용은 선택 사항 입니다. Java와 함께 Link-Grammar를 사용하지 않을 경우에는 필요하지 않습니다. 다음과 같이 비활성화하여 Java 바인딩 구축을 건너 뛸 수 있습니다.
./configure --disable-java-bindings
jni.h 찾지 못하거나 ant 찾지 못하면 Java 바인딩이 구축되지 않습니다.
jni.h 찾기에 대한 메모 :
일부 일반적인 Java JVM 분포 (특히 태양에서 나온 것)는이 파일을 비정상적인 위치에 배치하여 자동으로 찾을 수 없습니다. 이를 해결하려면 환경 변수 JAVA_HOME 올바르게 설정되어 있는지 확인하십시오. 구성 스크립트 구성 $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 의 사용은 비표준이며 대부분의 시스템 도구는 설치된 패키지를 찾지 못할 것입니다.
표준 GNU configure --prefix 옵션을 사용하여 /usr/local 설치 대상을 과도하게 입수 할 수 있습니다. 예를 들면 다음과 같습니다.
./configure --prefix=/opt/link-grammar
pkg-config (아래 참조)를 사용하면 비표준 설치 위치를 자동으로 감지 할 수 있습니다.
추가 구성 옵션은 인쇄됩니다
./configure --help
이 시스템은 32 및 64 비트 Linux 시스템, FreeBSD, MACOS 및 Microsoft Windows 시스템에서 테스트되었으며 잘 작동합니다. 특정 OS 의존성 노트가 다음과 같습니다.
최종 사용자는 Tarball을 다운로드해야합니다 (포장 풀기 및 서명 확인 참조).
현재 GitHub 버전은 개발자 (수정, 새로운 기능 또는 개선을 기꺼이 제공하는 사람을 포함하여)를위한 것입니다. 마스터 브랜치의 끝은 종종 불안정하며 개발 중이므로 코드가 잘못 될 수 있습니다. 또한 기본적으로 설치되지 않은 개발 도구를 설치해야합니다. 이러한 이유로 인해 Github 버전의 사용은 일반 최종 사용자에게는 권장되지 않습니다.
복제 : git clone https://github.com/opencog/link-grammar.git
또는 지퍼로 다운로드하십시오.
https://github.com/opencog/link-grammar/archive/master.zip
링크-그램을 구축하기 전에 설치가 필요한 도구 :
make ( gmake 변형이 필요할 수 있음)
m4
gcc 또는 clang
autoconf
libtool
autoconf-archive
pkg-config ( pkgconf 또는 pkgconfig 로 명명 될 수 있음)
pip3 (파이썬 바인딩 용)
선택 과목:
swig (언어 바인딩 용)
flex
Apache Ant (Java 바인딩 용)
graphviz (Word-Graph 디스플레이 기능을 사용하려면)
GitHub 버전에는 configure 스크립트가 포함되어 있지 않습니다. 그것을 생성하려면 사용하십시오.
autogen.sh
오류가 발생하면 위에 상장 된 개발 패키지를 설치하고 시스템 설치가 최신 상태인지 확인하십시오. 특히, autoconf 또는 autoconf-archive 누락되면 이상하고 오도 된 오류가 발생할 수 있습니다.
진행 방법에 대한 자세한 내용은 시스템을 작성하는 섹션과 관련 섹션을 계속 유지하십시오.
디버그 모드를 구성하려면 다음을 사용하십시오.
configure --enable-debug
일부 검증 디버그 코드와 여러 데이터 구조를 제대로 인쇄 할 수있는 기능을 추가합니다.
디버깅에 유용 할 수있는 기능은 Word Graph 디스플레이입니다. 기본적으로 활성화됩니다. 이 기능에 대한 자세한 내용은 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
pcre2 기존 libc Regex 구현에 필요한 수준의 REGEX 지원이 없기 때문에 필요한 패키지입니다.
일부 패키지는 이전 섹션에서 언급 한 것과 다른 패키지를 가지고 있습니다.
minisat (Minisat2) pkgconf (pkg-config)
평범한 바닐라 링크 문법은 위에서 설명한 것처럼 Apple MacOS에서 잘 컴파일하고 실행해야합니다. 현재보고 된 문제는 없습니다.
Java 바인딩이 필요하지 않은 경우 다음과 거의 반드시 구성해야합니다.
./configure --disable-java-bindings
Java 바인딩을 원한다면 JDK_HOME 환경 변수를 <Headers/jni.h> 어디에 있든 설정하십시오. Java_home 변수를 Java 컴파일러의 위치로 설정하십시오. 개미가 설치되어 있는지 확인하십시오.
GitHub (GitHub 저장소의 건물 참조)에서 빌드하려면 홈브류를 사용하여 나열된 도구를 설치할 수 있습니다.
Windows에서 Link-Grammar를 컴파일 할 수있는 세 가지 방법이 있습니다. 한 가지 방법은 Windows 용 Linux 호환 레이어를 제공하는 Cygwin을 사용하는 것입니다. 다른 방법은 MSVC 시스템을 사용하는 것입니다. 세 번째 방법은 GNU 툴셋을 사용하여 Windows 프로그램을 컴파일하는 MingW 시스템을 사용하는 것입니다. 소스 코드는 Vista ON의 Windows 시스템을 지원합니다.
Cygwin Way는 현재 명령 완료 및 기록을 갖는 라인 편집을 지원하고 X-Windows에 표시되는 Word-graph를 지원하기 때문에 현재 최상의 결과를 생성합니다. (MINGW에는 현재 libedit 가 없으며 MSVC 포트는 현재 명령 완료 및 기록 및 철자도 지원하지 않습니다.
MS Windows에서 Link-Grammar를 작동시키는 가장 쉬운 방법은 Windows 용 Linux와 같은 환경 인 Cygwin을 사용하여 POSIX 시스템에서 Windows로 실행할 수 있도록하는 것입니다. Cygwin을 다운로드하여 설치하십시오.
LIBC Regex 구현이 충분하지 않기 때문에 pcre2 패키지의 설치가 필요합니다.
자세한 내용은 mingw/readme-cygwin.md를 참조하십시오.
Link-Grammar를 구축하는 또 다른 방법은 GNU 툴셋을 사용하여 Windows 용 Posix Compliant 프로그램을 컴파일하는 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]
이것은 프로그램을 시작합니다. 이 프로그램에는 많은 사용자 확장 가능한 변수와 옵션이 있습니다. 링크 파서 프롬프트에서 !var 입력하여 표시 할 수 있습니다. 입력 !help 몇 가지 추가 명령이 표시됩니다.
사전은 이름이 2 글자 언어 코드 인 디렉토리로 정렬됩니다. Link-Parser 프로그램은 해당 언어 디렉토리를 해당 순서대로 직접 또는 디렉토리 이름 data 아래에서 검색합니다.
/usr/local/share/link-grammar ).Link-Parser가 원하는 사전을 찾을 수없는 경우 Verbosity Level 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 로컬이 설치되지 않았거나 구성되지 않습니다. Shell Command locale -a en_US.utf8 로케일로 나열해야합니다. 그렇지 않은 경우, 운영 체제에 따라 dpkg-reconfigure locales 및/또는 update-locale 또는 apt-get install locales 또는 이들의 조합 또는 변형을 실행해야합니다.
결과 빌드를 테스트하는 방법에는 여러 가지가 있습니다. 파이썬 바인딩이 구축되면 테스트 프로그램을 파일에서 찾을 수 있습니다 ./bindings/python-examples/tests.py 실행되면 통과해야합니다. 자세한 내용은 bindings/python-examples 디렉토리의 readme.md를 참조하십시오.
언어 데이터 디렉토리에는 여러 번의 테스트/예제 문장이 있으며, 일반적으로 이름은 corpus-*.batch 다음 명령은 Parser를 corpus-basic.batch 라는 파일로 실행합니다.
link-parser < corpus-basic.batch
Corpus-Basic.batch의 상단 근처의 !batch 배치 모드를 켭니다. 이 모드에서는 초기 * 로 표시된 문장을 거부해야하며 A * 로 시작하지 않는 문장을 수락해야합니다. 이 배치 파일은 파일 corpus-biolg.batch 및 corpus-fixes.batch 와 마찬가지로 몇 가지 오류를보고합니다. 이것을 해결하기위한 작업이 진행 중입니다.
corpus-fixes.batch 파일에는 Link-Grammar의 원래 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
바인딩/파이썬 디렉토리에는 파이썬 바인딩에 대한 단위 테스트가 포함되어 있습니다. 또한 Link-Grammar 라이브러리를 강조하는 몇 가지 기본 확인을 수행합니다.
파서에는 API (응용 프로그램 프로그램 인터페이스)가 있습니다. 이를 통해이를 자신의 응용 프로그램에 쉽게 통합 할 수 있습니다. API는 웹 사이트에 문서화되어 있습니다.
FindLinkGrammar.cmake 파일은 CMAKE 기반 빌드 환경에서 컴파일을 테스트하고 설정하는 데 사용될 수 있습니다.
컴파일 및 연결을보다 쉽게 만들기 위해 현재 릴리스는 PKG-Config 시스템을 사용합니다. Link-Grammar 헤더 파일의 위치를 결정하려면 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`
이 릴리스는 파서에 액세스하는 세 가지 방법을 제공하는 Java 파일을 제공합니다. 가장 간단한 방법은 org.linkgrammar.linkgrammar 클래스를 사용하는 것입니다. 이것은 파서에 매우 간단한 Java API를 제공합니다.
두 번째 가능성은 lgservice 클래스를 사용하는 것입니다. 이는 TCP/IP 네트워크 서버를 구현하여 구문 분석 결과를 JSON 메시지로 제공합니다. JSON 용도로 클라이언트 가이 서버에 연결하여 구문 분석 된 텍스트를 얻을 수 있습니다.
세 번째 가능성은 org.linkgrammar.lgremoteclient 클래스, 특히 Parse () 메소드를 사용하는 것입니다. 이 클래스는 JSON 서버에 연결하는 네트워크 클라이언트이며, 응답을 Parseresult API를 통해 액세스 할 수있는 결과로 다시 변환합니다.
Apache ant 설치되면 위에서 설명한 코드가 구축됩니다.
네트워크 서버는 다음과 같이 말함으로써 시작할 수 있습니다.
java -classpath linkgrammar.jar org.linkgrammar.LGService 9000
위의 내용은 포트 9000에서 서버를 시작합니다. 포트가 생략되고 텍스트가 인쇄됩니다. 이 서버는 TCP/IP를 통해 직접 연락 할 수 있습니다. 예를 들어:
telnet localhost 9000
(또는 텔넷 대신 NetCat을 사용하십시오). 연결 후 다음을 입력하십시오.
text: this is an example sentence to parse
반환 된 바이트는 문장의 구문 분석을 제공하는 JSON 메시지입니다. 기본적으로 텍스트의 Ascii-Art 구문 분석은 전송되지 않습니다. 이것은 양식의 메시지를 보내면 얻을 수 있습니다.
storeDiagramString:true, text: this is a test.
파서는 형태에 근거하여 알지 못하고 추측 할 수없는 단어를 만나면 초기 단계에서 맞춤법 검사기를 실행합니다. 구성 스크립트 구성 Aspell 또는 Hunspell 맞춤법 검사기를 찾습니다. Aspell Devel 환경이 발견되면 Aspell이 사용됩니다. 그렇지 않으면 Hunspell이 사용됩니다.
!spell=0 플래그가있는 링크 패러 클라이언트에서 런타임에 주문 추측이 비활성화 될 수 있습니다. 자세한 내용을 보려면 !help 받으십시오.
주의 : Aspell 버전 0.60.8 및 다른 사람들은 메모리 누출이있을 수 있습니다. 프로덕션 서버에서 주문 추측의 사용은 강력하게 낙담합니다. Parse_Options 에서 주문 추측을 비활성화하는 ( =0 )를 유지하는 것은 안전합니다.
여러 스레드에서 Link-Grammar를 사용하는 것이 안전합니다. 스레드는 동일한 사전을 공유 할 수 있습니다. 구문 분석 옵션은 모든 스레드가 공유하는 글로벌 인 Verbosity를 제외하고는 스레드별로 설정할 수 있습니다. 유일한 글로벌입니다.
자음/모음 전 A/음성 결정자는 새로운 pH 링크 유형에 의해 처리되어 결정자를 바로 다음 단어에 연결합니다. 상태 : 버전 5.1.0 (2014 년 8 월)에 도입되었습니다. 많은 특수 케이스 명사가 완성되었지만 대부분 완료되었습니다.
리투아니아, 터키 및 기타 무료 워드 주문 언어와 같은 일부 언어에는 방향 링크가 필요합니다. 목표는 링크가 어떤 단어가 헤드 워드인지, 어떤 종속적인지를 명확하게 나타내는 것입니다. 이것은 단일 소문자 문자로 연결된 커넥터를 접두사로하여 '헤드'및 '종속적'을 나타냅니다. 연결 규칙은 H가 아무것도 없거나 d와 일치시키고 d는 h 또는 아무것도 일치시키는 것입니다. 이것은 버전 5.1.0 (2014 년 8 월)의 새로운 기능입니다. 웹 사이트는 추가 문서를 제공합니다.
영어 링크 그래머 링크는 지향적이지 않지만, 의존성 문법의 표준 개념과 완전히 일치하는 사실상의 방향이 그들에게 주어질 수 있습니다.
의존성 화살표에는 다음과 같은 속성이 있습니다.
반 반사형 (단어는 그 자체에 의존 할 수 없으며 그 자체로 가리킬 수 없습니다.)
anti-symmetric (Word1이 Word2에 의존하는 경우 Word2는 Word1에 의존 할 수 없음) (예 : 결정자는 명사에 의존하지만 그 반대도 마찬가지).
화살표는 전이적이거나 반항적이지 않습니다. 단일 단어는 여러 머리에 의해 지배 될 수 있습니다. 예를 들어:
+------>WV------->+
+-->Wd-->+<--Ss<--+
| | |
LEFT-WALL she thinks.v
즉, 주제, "그녀", 왼쪽 벽에서 직접, WD 링크를 통해, 그리고 벽에서 뿌리 동사까지, 그리고 주제까지의 경로가 있습니다. B 및 R 링크와 유사한 루프가 형성됩니다. 이러한 루프는 가능한 구문 분석 수를 제한하는 데 유용합니다. 제약 조건은 "No Links Cross"메타 규칙과 함께 발생합니다.
몇 가지 관련 수학적 개념이 있지만 방향 LG를 상당히 포착하지는 않습니다.
LG는 하나의 벽 (하나의 "상단"요소) 만 허용한다는 점을 제외하고는 방향 LG 그래프가 DAG와 비슷합니다.
방향성 LG 그래프는 LG 화살표가 일반적으로 전이적이지 않다는 점을 제외하고는 엄격한 부분 순서와 유사합니다.
방향성 LG 그래프는 Catena가 엄격하게 반 번역이라는 점을 제외하고는 Catena와 유사합니다. 모든 단어의 경로는 Catena에서 독특합니다.
기본 LG 논문은 구문 분석 그래프의 평면성을 요구합니다. 이것은 의존성이 자연 언어로 거의 교차하지 않는다는 매우 오래된 관찰에 근거합니다. 인간은 단순히 링크가 교차하는 문장으로 말하지 않습니다. 그런 다음 평면성 제약을 부과하면 결과 구문 분석에 대한 강력한 엔지니어링 및 알고리즘 제약 조건을 제공합니다. 고려할 총 구문 분석 수는 급격히 줄어들므로 구문 분석의 전체 속도가 크게 증가 할 수 있습니다.
그러나이 평면 규칙에는 가끔 비교적 드문 예외가 있습니다. 이러한 예외는 거의 모든 언어에서 관찰됩니다. 이러한 예외는 아래에서 영어에 대해 제공됩니다.
따라서 평면 제약을 이완시키고 거의 엄격한 다른 것을 찾는 것이 중요하지만 여전히 드물게 예외를 허용하는 것이 중요합니다. Richard Hudson이 "Word Grammar"이론에서 정의한 다음 Ben Goertzel이 옹호 한 "랜드 마크 전시 성"의 개념은 그러한 메커니즘 일 수 있습니다.
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에서 이미 구현 된 실제 작업 예입니다. 모든 링크 교차로 이런 방식으로 구현 될 수 있습니다! 따라서 우리는 비평선 다이어그램을 얻기 위해 실제로 현재 구문 분석 알고리즘을 포기할 필요가 없습니다. 우리는 그들을 수정할 필요조차 없습니다! 만세!
다음은 작업 예입니다. "나는 모든 것을보고 듣고 싶습니다." 이것은 '모든 것'을 가리키는 두 개의 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'에서 'Everything'에서 Js 링크를 원하지만이 Js 링크는 결합에 대한 링크를 교차합니다 (xxx로 표시). 다른 예는 대부분의 링크가 하향 링크를 연결하여 연결하도록 허용해야한다고 제안합니다.
평면-관리 작업은 Js 링크를 2로 나누는 것입니다. Jj 부분과 Jk 부분; 둘은 함께 사용하여 연결을 넘어갑니다. 이것은 현재 영어 사전에서 구현되어 있으며 작동합니다.
이 작업은 실제로 완전히 일반적이며 모든 종류의 링크 교차로 확장 될 수 있습니다. 이것이 작동하기 위해서는 더 나은 표기법이 편리 할 것입니다. 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. 비슷하게:
"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. 즉. 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
Book review.
“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.
See also:
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).
심판 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...
