link grammar
1.0.0
Version 5.12.5
L'analyseur de grammaire de liaison présente la structure linguistique (langue naturelle) de l'anglais, du thaï, des sous-ensembles russes, arabes, persans et limités d'une demi-douzaine d'autres langues. Cette structure est un graphique des liaisons dactylographiées (bords) entre les mots d'une phrase. On peut obtenir le HPSG (constituant) plus conventionnel et les analyses de style de dépendance à partir de la grammaire de liaison en appliquant une collection de règles à convertir à ces différents formats. Cela est possible car la grammaire de liaison va un peu plus "plus profonde" dans la structure "syntactico-sémantique" d'une phrase: elle fournit des informations beaucoup plus à grain et détaillées que ce qui est couramment disponible dans les analyseurs conventionnels.
La théorie des analyses de grammaire de liaison a été initialement développée en 1991 par Davy Temperley, John Lafferty et Daniel Sleator, au moment des professeurs de linguistique et d'informatique à l'Université Carnegie Mellon. Les trois premières publications sur cette théorie fournissent la meilleure introduction et vue d'ensemble; Depuis lors, il y a eu des centaines de publications en explorant, examinant et étendant les idées.
Bien que sur la base de la base de code Carnegie-Mellon d'origine, le package de grammaire de liaison actuel a considérablement évolué et est profondément différent des versions antérieures. Il y a eu d'innombrables corrections de bogues; Les performances se sont améliorées de plusieurs ordres de grandeur. Le package est entièrement multi-thread, entièrement activé UTF-8 et a été frotté pour la sécurité, permettant le déploiement cloud. La couverture de l'analyse de l'anglais a été considérablement améliorée; D'autres langues ont été ajoutées (notamment, thaï et russe). Il y a une série de nouvelles fonctionnalités, notamment le support de la morphologie, des dialectes et un système de poids (coût) à grain fin, permettant un comportement de type vecteur. Il y a un nouveau tokenizer sophistiqué adapté à la morphologie: il peut offrir des divisions alternatives pour les mots morphologiquement ambigus. Les dictionnaires peuvent être mis à jour au moment de l'exécution, permettant des systèmes qui effectuent l'apprentissage continu de la grammaire pour analyser également en même temps. C'est-à-dire que les mises à jour du dictionnaire et l'analyse sont mutuellement enfile. Les classes de mots peuvent être reconnues avec des experts. L'analyse de graphe planaire aléatoire est entièrement prise en charge; Cela permet un échantillonnage uniforme de l'espace des graphiques planaires. Un rapport détaillé de ce qui a changé peut être trouvé dans le Changelog.
Ce code est publié dans le cadre de la licence LGPL, ce qui le rend libre à la fois pour une utilisation privée et commerciale, avec peu de restrictions. Les termes de la licence sont donnés dans le fichier de licence inclus dans ce logiciel.
Veuillez consulter la page Web principale pour plus d'informations. Cette version est une continuation de l'analyseur CMU original.
À partir de la version 5.9.0, le système comprend un système expérimental pour générer des phrases. Ceux-ci sont spécifiés à l'aide d'une API "Rempliez les blancs", où les mots sont remplacés dans des emplacements de joker, chaque fois que le résultat est une phrase grammaticalement valable. Des détails supplémentaires figurent dans la page de l'homme: man link-generator (dans le sous-répertoire man ).
Ce générateur est utilisé dans le projet d'apprentissage du langage d'OpenGOG, qui vise à apprendre automatiquement les grammaires de liens des corpus, en utilisant des techniques théoriques de l'information neuves et innovantes, quelque peu similaires à celles trouvées dans les réseaux neuronaux artificiels (Deep Learning), mais en utilisant des représentations explicitement symboliques.
L'analyseur comprend des API dans divers langages de programmation différents, ainsi qu'un outil de ligne de commande pratique pour jouer avec. Voici une sortie typique:
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-
Cet affichage plutôt occupé illustre beaucoup de choses intéressantes. Par exemple, le lien Ss*b relie le verbe et le sujet et indique que le sujet est singulier. De même, le lien Ost relie le verbe et l'objet, et indique également que l'objet est singulier. Le lien WV (verbe-mur) pointe sur le verbe de tête de la phrase, tandis que le lien Wd pointe vers le nom de tête. Le lien Xp se connecte à la ponctuation de fuite. Le lien Ds**c relie le nom au déterminant: il confirme à nouveau que le nom est singulier, et aussi que le nom commence par une consonne. (Le lien PH , non requis ici, est utilisé pour forcer l'accord phonétique, distinguant «A» de «an»). Ces types de liens sont documentés dans la documentation de liaison anglaise.
Le bas de l'écran est une liste des "disjuds" utilisés pour chaque mot. Les disjusts sont simplement une liste des connecteurs qui ont été utilisés pour former les liens. Ils sont particulièrement intéressants car ils servent de forme extrêmement à grains de fine «partie du discours». Ainsi, par exemple: le disjoncteur S- O+ indique un verbe transitif: c'est un verbe qui prend à la fois un sujet et un objet. Le balisage supplémentaire ci-dessus indique que «est» est non seulement utilisé comme verbe transitif, mais il indique également des détails plus fins: un verbe transitif qui a pris un sujet singulier, et a été utilisé (est utilisable comme) le verbe de tête d'une phrase. La valeur à virgule flottante est le "coût" du disjoncteur; Il capture très grossièrement l'idée de la probabilité logarithmique de cette utilisation grammaticale particulière. Tout comme des parties de discours est en corrélation avec les moyens de mots, des parties de discours de grains fins sont également en corrélation avec des distinctions beaucoup plus fines et des gradations de sens.
L'analyseur de grammaire Link soutient également l'analyse morphologique. Voici un exemple en russe:
linkparser> это теста
Linkage 1, cost vector = (UNUSED=0 DIS= 0.00 LEN=4)
+-----MVAip-----+
+---Wd---+ +-LLCAG-+
| | | |
LEFT-WALL это.msi тест.= =а.ndnpi
Le lien LL relie la tige «тест» au suffixe «а». La liaison MVA se connecte uniquement au suffixe, car, en russe, ce sont les suffixes qui portent toute la structure syntaxique, et non les tiges. Le lexis russe est documenté ici.
Le dictionnaire thaïlandais est désormais pleinement développé, couvrant effectivement l'ensemble de la langue. Un exemple en thaï:
linkparser> นายกรัฐมนตรี ขึ้น กล่าว สุนทรพจน์
Linkage 1, cost vector = (UNUSED=0 DIS= 2.00 LEN=2)
+---------LWs--------+
| +<---S<--+--VS-+-->O-->+
| | | | |
LEFT-WALL นายกรัฐมนตรี.n ขึ้น.v กล่าว.v สุนทรพจน์.n
La liaison VS relie deux verbes 'ขึ้น' et 'กล่าว' dans une construction verbale en série. Un résumé des types de liens est documenté ici. Une documentation complète de la grammaire Thai Link peut être trouvée ici.
La grammaire de liaison thaïlandaise accepte également les entrées marquées par Pos et nommées. Chaque mot peut être annoté avec la balise POS de liaison. Par exemple:
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[!]
Une documentation complète pour le dictionnaire thaïlandais peut être trouvée ici.
Le dictionnaire thaïlandais accepte les tagsets LST20 pour POS et les entités nommées, pour combler l'écart entre les outils NLP fondamentaux et l'analyseur de liaison. Par exemple:
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
Notez que chaque mot ci-dessus est annoté avec des balises POS LST20 et des balises NE. La documentation complète pour les balises POS de liaison et les tagsets LST20 se trouvent ici. Plus d'informations sur LST20, par exemple, les directives d'annotation et les statistiques de données, peuvent être trouvées ici.
La any prend en charge les graphiques planaires aléatoires uniformément échantillonnés:
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[!]
La langue ady fait de même, effectuant des fractionnements morphologiques aléatoires:
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]
Un aperçu étendu et un résumé se trouvent dans la page Wikipedia de la grammaire de liaison, qui aborde la plupart de l'importation, principaux aspects de la théorie. Cependant, il ne remplace pas les articles originaux publiés sur le sujet:
Il y a beaucoup plus d'articles et de références répertoriées sur le site Web de grammaire du lien principal
Voir également la documentation de l'API C / C ++. Les liaisons pour d'autres langages de programmation, y compris Python3, Java et Node.js, peuvent être trouvées dans le répertoire de liaisons. (Il y a deux ensembles de liaisons JavaScript: un ensemble pour l'API de la bibliothèque et un autre ensemble pour l'analyseur de ligne de commande.)
| Contenu | Description |
|---|---|
| LICENCE | La licence décrivant les conditions d'utilisation |
| Changelog | Un recueil de changements récents. |
| configurer | Le script de configuration GNU |
| autogen.sh | L'outil de maintenance de configuration du développeur |
| link-grammar / *. C | Le programme. (Écrit en ANSI-C) |
| ---- | ---- |
| liaisons / autoit / | Liaisons en langue automatique facultative. |
| reliures / java / | Régales en langue Java facultative. |
| reliures / js / | Liaisons linguistiques JavaScript facultatives. |
| reliures / lisp / | CONSALLAGES DES LANGES COMMUNES FORMÉELLES. |
| liaisons / node.js / | Liaisons linguistiques Node.js facultatives. |
| liaisons / OCAML / | Liaisons en langue OCAML facultatives. |
| reliures / python / | Liaisons linguistiques Python3 facultatives. |
| liaisons / python-exemples / | Suite de test de grammaire de liaison et exemple de liaison du langage Python. |
| reliures / swig / | Fichier d'interface SWIG, pour d'autres interfaces FFI. |
| reliures / vala / | Régaux en langue Vala facultatifs. |
| ---- | ---- |
| data / en / | Dictionnaires en anglais. |
| data / en / 4.0.dict | Le fichier contenant les définitions du dictionnaire. |
| data / en / 4.0.knowledge | Le fichier de connaissances post-traitement. |
| data / en / 4.0.constituants | Le fichier de connaissances constitutives. |
| data / en / 4.0.affix | Le fichier APPIX (préfixe / suffixe). |
| data / en / 4.0.regex | Deviner de morphologie basé sur l'expression régulière. |
| data / en / tiny.dict | Un petit exemple de dictionnaire. |
| data / en / words / | Un répertoire plein de listes de mots. |
| data / en / corpus * .batch | Exemple de corpus utilisés pour les tests. |
| ---- | ---- |
| données / ru / | Un dictionnaire russe à part entière |
| données / th / | Un dictionnaire thaïlandais à part entière (plus de 100 000 mots) |
| données / ar / | Un dictionnaire arabe assez complet |
| data / fa / | Un dictionnaire persan (farsi) |
| données / de / | Un petit prototype dictionnaire allemand |
| données / lt / | Un petit prototype dictionnaire lituanien |
| data / id / | Un petit prototype dictionnaire indonésien |
| données / vn / | Un petit prototype dictionnaire vietnamien |
| données / il / | Un dictionnaire hébreu expérimental |
| données / kz / | Un dictionnaire kazakh expérimental |
| data / tr / | Un dictionnaire turc expérimental |
| ---- | ---- |
| morphologie / ar / | Un analyseur de morphologie arabe |
| morphologie / fa / | Un analyseur de morphologie perse |
| ---- | ---- |
| déboguer/ | Informations sur le débogage de la bibliothèque |
| msvc / | Fichiers de projet Microsoft Visual-C |
| Mingw / | Informations sur l'utilisation de Mingw sous MSYS ou Cygwin |
Le système est distribué à l'aide du format tar.gz conventionnel; Il peut être extrait à l'aide de la commande tar -zxf link-grammar.tar.gz sur la ligne de commande.
Un tarball de la dernière version peut être téléchargé à partir de:
https://www.gnnucash.org/link-grammar/downloads/
Les fichiers ont été signés numériquement pour s'assurer qu'il n'y a pas eu de corruption de l'ensemble de données pendant le téléchargement et pour s'assurer qu'aucune modification malveillante n'a été apportée aux internes du code par des tiers. Les signatures peuvent être vérifiées avec la commande gpg:
gpg --verify link-grammar-5.12.5.tar.gz.asc
qui devrait générer une sortie identique à (sauf pour la date):
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]>"
Alternativement, les sombres de contrôle MD5 peuvent être vérifiés. Ceux-ci ne fournissent pas de sécurité cryptographique, mais ils peuvent détecter une corruption simple. Pour vérifier les sujets de contrôle, émettez md5sum -c MD5SUM sur la ligne de commande.
Les balises dans git peuvent être vérifiées en effectuant ce qui suit:
gpg --recv-keys --keyserver keyserver.ubuntu.com EB6AA534E0C0651C
git tag -v link-grammar-5.10.5
Pour compiler la bibliothèque partagée et le programme de démonstration partagés Link-Grammar, sur la ligne de commande, Type:
./configure
make
make check
Pour installer, modifier l'utilisateur en "root" et dire
make install
ldconfig
Cela installera la bibliothèque liblink-grammar.so dans /usr/local/lib , les fichiers d'en-tête dans /usr/local/include/link-grammar , et les dictionnaires dans /usr/local/share/link-grammar . L'exécution ldconfig reconstruia le cache de la bibliothèque partagée. Pour vérifier que l'installation a été réussie, exécutez (en tant qu'utilisateur non root)
make installcheck
La bibliothèque Link-Grammar a des fonctionnalités facultatives qui sont activées automatiquement si configure détecte certaines bibliothèques. Ces bibliothèques sont facultatives sur la plupart des systèmes et si la fonctionnalité qu'ils ajoutent est souhaitée, les bibliothèques correspondantes doivent être installées avant d'exécuter configure .
Les noms de packages de bibliothèque peuvent varier sur divers systèmes (consultez Google si nécessaire ...). Par exemple, les noms peuvent inclure -devel au lieu de -dev , ou être sans elle. Les noms de la bibliothèque peuvent être sans le préfixe lib .
libsqlite3-dev (pour dictionnaire soutenu par Sqlite)libz1g-dev ou libz-devel (actuellement nécessaire pour le minisat2 groupé)libedit-dev (voir editline)libhunspell-dev ou libaspell-dev (et le dictionnaire anglais correspondant).libtre-dev ou libpcre2-dev (beaucoup plus rapide que l'implémentation regex libc et nécessaire pour l'exactitude sur freebsd et cygwin).libpcre2-dev est fortement recommandée. Il doit être utilisé sur certains systèmes (comme spécifié dans leurs sections de bâtiment). Si libedit-dev est installé, les touches de flèche peuvent être utilisées pour modifier l'entrée dans l'outil de liaison-battant; Les touches de flèche haut et bas rappellent les entrées précédentes. Vous voulez ça; Cela facilite les tests et l'édition.
Deux versions des liaisons Node.js sont incluses. Une version enveloppe la bibliothèque; L'autre utilise Emscripten pour envelopper l'outil de ligne de commande. Les liaisons de la bibliothèque sont dans bindings/node.js tandis que l'emballage Emscripten est dans bindings/js .
Ceux-ci sont construits à l'aide de npm . Tout d'abord, vous devez créer la bibliothèque Core C. Ensuite, faites ce qui suit:
cd bindings/node.js
npm install
npm run make
Cela créera les liaisons de la bibliothèque et exécutera également un petit test unitaire (qui devrait passer). Un exemple peut être trouvé dans bindings/node.js/examples/simple.js .
Pour l'emballage en ligne de commande, faites ce qui suit:
cd bindings/js
./install_emsdk.sh
./build_packages.sh
Les liaisons Python3 sont construites par défaut, à condition que les packages de développement Python correspondants soient installés. (Les liaisons Python2 ne sont plus prises en charge.)
Ces forfaits sont:
python3-develpython3-dev Remarque: Avant d'émettre configure (voir ci-dessous), vous devez valider que les versions Python requises peuvent être invoquées à l'aide de votre PATH .
L'utilisation des liaisons Python est facultative ; Vous n'en avez pas besoin si vous ne prévoyez pas d'utiliser Link-Grammar avec Python. Si vous aimez désactiver les liaisons Python, utilisez:
./configure --disable-python-bindings
Le module linkgrammar.py fournit une interface de haut niveau dans Python. Les scripts example.py et sentence-check.py fournissent une démo et tests.py exécute des tests unitaires.
make install pythondir=/where/to/install Par défaut, les Makefile S tentent de construire les liaisons Java. L'utilisation des liaisons Java est facultative ; Vous n'en avez pas besoin si vous ne prévoyez pas d'utiliser Link-Grammar avec Java. Vous pouvez sauter la construction des liaisons Java en désactivant comme suit:
./configure --disable-java-bindings
Si jni.h n'est pas trouvé, ou si ant n'est pas trouvée, les liaisons Java ne seront pas construites.
Notes sur la recherche de jni.h :
Certaines distributions Java JVM courantes (notamment celles de Sun) placent ce fichier dans des emplacements inhabituels, où il ne peut pas être trouvé automatiquement. Pour y remédier, assurez-vous que la variable d'environnement JAVA_HOME est correctement définie. Le script de configuration recherche jni.h dans $JAVA_HOME/Headers et dans $JAVA_HOME/include ; Il examine également les emplacements correspondants pour $JDK_HOME . Si jni.h ne peut toujours pas être trouvé, spécifiez l'emplacement avec la variable CPPFLAGS : donc, par exemple,
export CPPFLAGS="-I/opt/jdk1.5/include/:/opt/jdk1.5/include/linux"
ou
export CPPFLAGS="-I/c/java/jdk1.6.0/include/ -I/c/java/jdk1.6.0/include/win32/"
Veuillez noter que l'utilisation /opt est non standard et que la plupart des outils système ne parviendront pas à trouver des packages installés.
La cible d'installation /usr/local peut être excessive à l'aide de l'option standard configure --prefix ; Ainsi, par exemple:
./configure --prefix=/opt/link-grammar
En utilisant pkg-config (voir ci-dessous), les emplacements d'installation non standard peuvent être détectés automatiquement.
Des options de configuration supplémentaires sont imprimées par
./configure --help
Le système a été testé et fonctionne bien sur les systèmes Linux 32 et 64 bits, FreeBSD, MacOS, ainsi que sur Microsoft Windows Systems. Des notes spécifiques dépendantes du système d'exploitation suivent.
Les utilisateurs finaux doivent télécharger le tarball (voir déballage et vérification de signature).
La version GitHub actuelle est destinée aux développeurs (y compris tous ceux qui sont prêts à fournir un correctif, une nouvelle fonctionnalité ou une amélioration). La pointe de la branche principale est souvent instable et peut parfois y avoir un mauvais code car il est en cours de développement. Il a également besoin d'installation d'outils de développement qui ne sont pas installés par défaut. Pour cette raison, l'utilisation de la version GitHub est découragée pour les utilisateurs finaux réguliers.
Clone It: git clone https://github.com/opencog/link-grammar.git
Ou téléchargez-le comme zip:
https://github.com/opencog/link-grammar/archive/master.zip
Outils qui peuvent nécessiter une installation avant de pouvoir créer un lien-grammaire:
make (la variante gmake peut être nécessaire)
m4
gcc ou clang
autoconf
libtool
autoconf-archive
pkg-config (peut être nommé pkgconf ou pkgconfig )
pip3 (pour les liaisons Python)
Facultatif:
swig (pour les liaisons linguistiques)
flex
ANT APACH (pour les liaisons Java)
graphviz (si vous souhaitez utiliser la fonction d'affichage de Graph Word)
La version GitHub n'inclut pas de script configure . Pour le générer, utilisez:
autogen.sh
Si vous obtenez des erreurs, assurez-vous d'avoir installé les packages de développement classés ci-dessus et que l'installation de votre système est à jour. En particulier, la manquante autoconf ou autoconf-archive peut provoquer des erreurs étranges et trompeuses.
Pour plus d'informations sur la façon de procéder, continuez à la section créant le système et les sections pertinentes après.
Pour configurer le mode de débogage , utilisez:
configure --enable-debug
Il ajoute un code et des fonctions de débogage de vérification qui peuvent imprimer assez plusieurs structures de données.
Une fonctionnalité qui peut être utile pour le débogage est l'affichage de mot-graphique. Il est activé par défaut. Pour plus de détails sur cette fonctionnalité, voir l'affichage de Word-Graph.
La configuration actuelle a un problème de mélange de bibliothèque C ++ standard apparent lorsque gcc est utilisé (un correctif est le bienvenu). Cependant, la pratique courante sur FreeBSD est de compiler avec clang , et elle n'a pas ce problème. De plus, les packages complémentaires sont installés sous /usr/local .
Voici donc comment configure doit être invoquée:
env LDFLAGS=-L/usr/local/lib CPPFLAGS=-I/usr/local/include
CC=clang CXX=clang++ configure
Notez que pcre2 est un package requis car l'implémentation regex libc existante n'a pas le niveau nécessaire de support Regex.
Certains packages ont des noms différents de ceux mentionnés dans les sections précédentes:
minisat (MINISAT2) pkgconf (PKG-CONFIG)
La grammaire de liaison en vanille en simple doit très bien se compiler et fonctionner sur les macOS Apple, comme décrit ci-dessus. À l'heure actuelle, il n'y a aucun problème signalé.
Si vous n'avez pas besoin des liaisons Java, vous devez presque sûrement vous configurer avec:
./configure --disable-java-bindings
Si vous voulez des liaisons Java, assurez-vous de définir la variable de l'environnement JDK_HOME partout où <Headers/jni.h> est. Définissez la variable Java_Home sur l'emplacement du compilateur Java. Assurez-vous que la fourmi a installé.
Si vous souhaitez construire à partir de GitHub (voir la construction du référentiel GitHub), vous pouvez installer les outils qui y sont répertoriés à l'aide de Homebrew.
Il existe trois façons différentes dont le grammaire Link peut être compilé sous Windows. Une façon consiste à utiliser Cygwin, qui fournit une couche de compatibilité Linux pour Windows. Une autre façon consiste à utiliser le système MSVC. Une troisième façon consiste à utiliser le système MINGW, qui utilise le Set Toolset GNU pour compiler les programmes Windows. Le code source prend en charge les systèmes Windows à partir de Vista.
La manière Cygwin produit actuellement le meilleur résultat, car il prend en charge l'édition de ligne avec l'achèvement et l'historique des commandes et prend également en charge l'affichage du graphe de mots sur X-Windows. (Mingw n'a actuellement pas libedit , et le port MSVC ne prend actuellement pas en charge la complétion et l'historique des commandes, ainsi que l'orthographe.
La façon la plus simple de faire fonctionner Link-Grammar sur MS Windows est d'utiliser Cygwin, un environnement de type Linux pour Windows, ce qui permet de porter le logiciel fonctionnant sur des systèmes POSIX à Windows. Téléchargez et installez Cygwin.
Notez que l'installation du package pcre2 est requise car l'implémentation Regex LiBC n'est pas suffisamment capable.
Pour plus de détails, voir Mingw / Readme-Cygwin.md.
Une autre façon de créer Link-Grammar consiste à utiliser Mingw, qui utilise le ensemble d'outils GNU pour compiler les programmes conformes à POSIX pour Windows. L'utilisation de MingW / MSYS2 est probablement le moyen le plus simple d'obtenir des liaisons Java réalisables pour Windows. Téléchargez et installez MINGW / MSYS2 à partir de MSYS2.org.
Notez que l'installation du package pcre2 est requise car l'implémentation Regex LiBC n'est pas suffisamment capable.
Pour plus de détails, voir Mingw / Readme-Mingw64.md.
Les fichiers de projet Microsoft Visual C / C ++ peuvent être trouvés dans le répertoire msvc . Pour les instructions, consultez le fichier readme.md là-bas.
Pour exécuter le programme, émettez la commande (en supposant que c'est sur votre chemin):
link-parser [arguments]
Cela commence le programme. Le programme dispose de nombreuses variables et options sédables par les utilisateurs. Ceux-ci peuvent être affichés en entrant !var à l'invite de lien-parser. Entrée !help affichera quelques commandes supplémentaires.
Les dictionnaires sont organisés dans des répertoires dont le nom est le code de langue à 2 lettres. Le programme Link-Parser recherche un tel répertoire linguistique dans cet ordre, directement ou sous des data de noms de répertoire:
/usr/local/share/link-grammar ).Si Link-Parser ne peut pas trouver le dictionnaire souhaité, utilisez le niveau de verbosité 4 pour déboguer le problème; Par exemple:
link-parser ru -verbosity=4
D'autres emplacements peuvent être spécifiés sur la ligne de commande; Par exemple:
link-parser ../path/to-my/modified/data/en
Lorsque vous accédez aux dictionnaires dans des emplacements non standard, les noms de fichiers standard sont toujours supposés ( c'est-à-dire 4.0.dict , 4.0.affix , etc. ).
Les dictionnaires russes sont en data/ru . Ainsi, l'analyseur russe peut être démarré comme:
link-parser ru
Si vous ne fournissez pas d'argument à Link-Parser, il recherche une langue en fonction de votre configuration locale actuelle. S'il ne peut pas trouver un tel répertoire linguistique, il est par défaut "en".
Si vous voyez des erreurs similaires à ceci:
Warning: The word "encyclop" found near line 252 of en/4.0.dict
matches the following words:
encyclop
This word will be ignored.
Ensuite, vos lieux UTF-8 ne sont pas installés ou non configurés. Le locale -a devrait répertorier en_US.utf8 comme un lieu. Sinon, vous devez alors dpkg-reconfigure locales et / ou exécuter update-locale ou éventuellement apt-get install locales , ou COMBINATIONS OU VARIANTS DE CEUX, SAVECE SADE SAVECT OUVRE VOTRE SYSTÈME D'OPMOCATION.
Il existe plusieurs façons de tester la construction résultante. Si les liaisons Python sont construites, un programme de test peut être trouvé dans le fichier ./bindings/python-examples/tests.py - lors de l'exécution, il doit passer. Pour plus de détails, voir Readme.md dans le répertoire bindings/python-examples .
Il existe également plusieurs lots de phrases de test / exemple dans les répertoires de données linguistiques, ayant généralement les noms corpus-*.batch le programme Parser peut être exécuté en mode batch, pour tester le système sur un grand nombre de phrases. La commande suivante exécute l'analyseur sur un fichier appelé corpus-basic.batch ;
link-parser < corpus-basic.batch
La ligne !batch près du haut de Corpus-Basic.batch allume le mode lot. Dans ce mode, les phrases étiquetées avec une * initiale * doivent être rejetées et celles qui ne commencent pas par A * doivent être acceptées. Ce fichier de lots rapporte quelques erreurs, tout comme les fichiers corpus-biolg.batch et corpus-fixes.batch . Le travail est en cours pour les résoudre.
Le fichier corpus-fixes.batch contient plusieurs milliers de phrases qui ont été corrigées depuis la version 4.1 d'origine de Link-Grammar. Le corpus-biolg.batch contient des phrases en biologie / texte médical du projet Biolg. Le corpus-voa.batch contient des échantillons de Voice of America; Le corpus-failures.batch contient un grand nombre d'échecs.
Les chiffres suivants sont susceptibles de changer, mais, pour le moment, le nombre d'erreurs que l'on peut s'attendre à observer dans chacun de ces fichiers est à peu près la suivante:
en/corpus-basic.batch: 88 errors
en/corpus-fixes.batch: 371 errors
lt/corpus-basic.batch: 15 errors
ru/corpus-basic.batch: 47 errors
Le répertoire Bindings / Python contient un test unitaire pour les liaisons Python. Il effectue également plusieurs vérifications de base qui soulignent les bibliothèques de liens-grammaires.
Il existe une API (interface du programme d'application) à l'analyseur. Cela facilite l'incorporer dans vos propres applications. L'API est documentée sur le site Web.
Le fichier FindLinkGrammar.cmake peut être utilisé pour tester et configurer la compilation dans des environnements de construction basés sur CMake.
Pour faciliter la compilation et la liaison, la version actuelle utilise le système PKG-Config. Pour déterminer l'emplacement des fichiers d'en-tête de liaison-grammaire, disons pkg-config --cflags link-grammar pour obtenir l'emplacement des bibliothèques, disons pkg-config --libs link-grammar Ainsi, par exemple, un makefile typique peut inclure les cibles:
.c.o:
cc -O2 -g -Wall -c $< `pkg-config --cflags link-grammar`
$(EXE): $(OBJS)
cc -g -o $@ $^ `pkg-config --libs link-grammar`
Cette version fournit des fichiers Java qui offrent trois façons d'accéder à l'analyseur. Le moyen le plus simple consiste à utiliser la classe org.linkgrammar.linkgrammar; Cela fournit une API Java très simple à l'analyseur.
La deuxième possibilité consiste à utiliser la classe LGService. Cela implémente un serveur de réseau TCP / IP, fournissant des résultats Parse comme messages JSON. Tout client compatible JSON peut se connecter à ce serveur et obtenir du texte analysé.
La troisième possibilité consiste à utiliser la classe org.linkgrammar.lGremoteClient, et en particulier la méthode parse (). Cette classe est un client réseau qui se connecte au serveur JSON et convertit la réponse en résultats accessibles via l'API PARSERESULT.
Le code décrit ci-dessus sera construit si ant Apache est installée.
Le serveur réseau peut être démarré en disant:
java -classpath linkgrammar.jar org.linkgrammar.LGService 9000
Ce qui précède démarre le serveur sur le port 9000. Il est omis, le texte d'aide est imprimé. Ce serveur peut être contacté directement via TCP / IP; Par exemple:
telnet localhost 9000
(Alternativement, utilisez NetCAT au lieu de Telnet). Après la connexion, tapez:
text: this is an example sentence to parse
Les octets retournés seront un message JSON fournissant les analyses de la phrase. Par défaut, l'analyse ASCII-Art du texte n'est pas transmise. Cela peut être obtenu en envoyant des messages du formulaire:
storeDiagramString:true, text: this is a test.
L'analyseur exécutera un vérificateur de sorts à un stade précoce, s'il rencontre un mot qu'il ne sait pas, et ne peut pas deviner, basé sur la morphologie. Le script de configuration recherche les vérificateurs de sorts Aspell ou Hunspell; Si l'environnement de développement d'Aspell est trouvé, alors Aspell est utilisé, sinon Hunspell est utilisé.
La supposition des sorts peut être désactivée au moment de l'exécution, dans le client de lien-parser avec l'indicateur !spell=0 . Entrez !help pour plus de détails.
ATTENTION: Aspell version 0.60.8 et éventuellement d'autres ont une fuite de mémoire. L'utilisation de l'apogée dans les serveurs de production est fortement découragée. Garder les handicapés de sort ( =0 ) dans Parse_Options est sûr.
Il est sûr d'utiliser Link-Grammar dans plusieurs threads. Les threads peuvent partager le même dictionnaire. Les options d'analyse peuvent être définies sur une base par thread, à l'exception de la verbosité, qui est un monde, partagé par tous les threads. C'est le seul mondial.
Les déterminants phonétiques A / an avant les consonnes / voyelles sont gérés par un nouveau type de liaison de pH, reliant le déterminant au mot la suivant immédiatement. Statut: introduit dans la version 5.1.0 (août 2014). Principalement fait, bien que de nombreux noms de cas spéciaux ne soient inachevés.
Des liens directionnels sont nécessaires pour certaines langues, telles que les langues lituaniennes, turques et autres langages de mot libre. L'objectif est d'avoir un lien indique clairement quel mot est le mot de tête et lequel est à charge. Ceci est réalisé en préfixant les connecteurs avec une seule lettre en bas de cas : H, D, indiquant «tête» et «dépendante». Les règles de liaison sont telles que H correspond à rien ou à D, et D correspond à H ou rien. Il s'agit d'une nouvelle fonctionnalité dans la version 5.1.0 (août 2014). Le site Web fournit une documentation supplémentaire.
Bien que les liens-grammaires de langue anglaise ne soient pas orientés, il semble qu'une direction de facto puisse leur être donnée qui est complètement cohérente avec les conceptions standard d'une grammaire de dépendance.
Les flèches de dépendance ont les propriétés suivantes:
Anti-réflexive (un mot ne peut pas dépendre de lui-même; il ne peut pas pointer de lui-même.)
Anti-symétrique (si Word1 dépend de Word2, alors Word2 ne peut pas dépendre de Word1) (donc, par exemple, les déterminants dépendent des noms, mais jamais vice-versa)
Les flèches ne sont ni transitifs, ni anti-transitifs: un seul mot peut être gouverné par plusieurs têtes. Par exemple:
+------>WV------->+
+-->Wd-->+<--Ss<--+
| | |
LEFT-WALL she thinks.v
Autrement dit, il y a un chemin vers le sujet, "elle", directement du mur de gauche, via le lien WD, ainsi que indirectement, du mur au verbe racine, et de là vers le sujet. Des boucles similaires se forment avec les liens B et R. Ces boucles sont utiles pour contraindre le nombre possible de Parses: la contrainte se produit en conjonction avec le méta-règle "No Links Cross".
Il existe plusieurs notions mathématiques connexes, mais aucune ne capture tout à fait LG directionnel:
Les graphiques LG directionnels ressemblent à Dags, sauf que LG n'autorise qu'un seul mur (un élément "supérieur").
Les graphiques LG directionnels ressemblent à des ordres partiels stricts, sauf que les flèches LG ne sont généralement pas transitives.
Les graphiques directionnels LG ressemblent à catena, sauf que les carena sont strictement anti-transitifs - le chemin vers n'importe quel mot est unique, dans une carena.
Les documents LG fondamentaux exigent la planarité des graphiques d'analyse. Ceci est basé sur une très vieille observation que les dépendances ne traversent presque jamais dans les langues naturelles: les humains ne parlent tout simplement pas en phrases où les liens se croisent. L'imposant des contraintes de planarité fournit alors une forte contrainte d'ingénierie et algorithmique sur les panais résultants: le nombre total de Parses à considérer est fortement réduit, et donc la vitesse globale de l'analyse peut être considérablement augmentée.
Cependant, il existe des exceptions occasionnelles et relativement rares à cette règle de la planarité; De telles exceptions sont observées dans presque toutes les langues. Un certain nombre de ces exceptions sont données pour l'anglais ci-dessous.
Ainsi, il semble important de détendre la contrainte de planarité et de trouver quelque chose d'autre qui est presque aussi strict, mais permet toujours des exceptions peu fréquentes. Il semblerait que le concept de «transitivité historique» telle que définie par Richard Hudson dans sa théorie de la «grammaire des mots», puis préconisée par Ben Goertzel, pourrait bien être un tel mécanisme.
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
En pratique, la contrainte de planarité permet d'utiliser des algorithmes très efficaces dans la mise en œuvre de l'analyseur. Ainsi, du point de vue de la mise en œuvre, nous voulons garder la planarité. Heureusement, il existe une façon pratique et sans ambiguïté d'avoir notre gâteau et de le manger aussi. Un diagramme non planaire peut être dessiné sur une feuille de papier en utilisant la notation standard de l'ingénierie électrique: un symbole drôle, partout où les fils se croisent. Cette notation est très facilement adaptée aux connecteurs LG; Vous trouverez ci-dessous un exemple de travail réel, déjà implémenté dans le dictionnaire anglais LG actuel. Tous les traversées de liens peuvent être implémentées de cette manière! Nous n'avons donc pas à abandonner les algorithmes d'analyse actuels pour obtenir des diagrammes non planaires. Nous n'avons même pas à les modifier! Hourra!
Voici un exemple de travail: "Je veux regarder et tout écouter." Cela veut deux liens J pointant vers «tout». Le diagramme souhaité devrait ressembler à ceci:
+---->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
Ce qui précède veut vraiment avoir un lien Js de 'at' à 'tout', mais ce lien Js traverse (affronte - marqué par xxx) le lien vers la conjonction. D'autres exemples suggèrent que l'on devrait permettre à la plupart des liens de traverser les liens vers le bas aux conjonctions.
Le travail travaillé par la planarité consiste à diviser le lien Js en deux: une partie Jj et une partie Jk ; Les deux sont utilisés ensemble pour traverser la conjonction. Ceci est actuellement mis en œuvre dans le dictionnaire anglais, et cela fonctionne.
Cette contribution est en fait complètement générique et peut être étendue à tout type de traversée de liens. Pour que cela fonctionne, une meilleure notation serait pratique; 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. De la même manière:
"He is either here or he is there."
"He either is here or he is there."
A different example involves a crossing to the left wall. That is, the links LEFT-WALL--remains crosses over here--found :
"Here the remains can be found."
Other examples, per And Rosta:
The allowed--by link crosses cake--that :
He had been allowed to eat a cake by Sophy that she had made him specially
a--book , very--indeed
"a very much easier book indeed"
an--book , easy--to
"an easy book to read"
a--book , more--than
"a more difficult book than that one"
that--have crosses remains--of
"It was announced that remains have been found of the ark of the covenant"
There is a natural crossing, driven by conjunctions:
"I was in hell yesterday and heaven on Tuesday."
the "natural" linkage is to use MV links to connect "yesterday" and "on Tuesday" to the verb. However, if this is done, then these must cross the links from the conjunction "and" to "heaven" and "hell". This can be worked around partly as follows:
+-------->Ju--------->+
| +<------SJlp<----+
+<-SX<-+->Pp->+ +-->Mpn->+ +->SJru->+->Mp->+->Js->+
| | | | | | | | |
I was in hell yesterday and heaven on Tuesday
but the desired MV links from the verb to the time-prepositions "yesterday" and "on Tuesday" are missing -- whereas they are present, when the individual sentences "I was in hell yesterday" and "I was in heaven on Tuesday" are parsed. Using a conjunction should not wreck the relations that get used; but this requires link-crossing.
"Sophy wondered up to whose favorite number she should count"
Here, "up_to" must modify "number", and not "whose". There's no way to do this without link-crossing.
Link Grammar can be understood in the context of type theory. A simple introduction to type theory can be found in chapter 1 of the HoTT book. This book is freely available online and strongly recommended if you are interested in types.
Link types can be mapped to types that appear in categorial grammars. The nice thing about link-grammar is that the link types form a type system that is much easier to use and comprehend than that of categorial grammar, and yet can be directly converted to that system! That is, link-grammar is completely compatible with categorial grammar, and is easier-to-use. See the paper "Combinatory Categorial Grammar and Link Grammar are Equivalent" for details.
The foundational LG papers make comments to this effect; however, see also work by Bob Coecke on category theory and grammar. Coecke's diagrammatic approach is essentially identical to the diagrams given in the foundational LG papers; it becomes abundantly clear that the category theoretic approach is equivalent to Link Grammar. See, for example, this introductory sketch http://www.cs.ox.ac.uk/people/bob.coecke/NewScientist.pdf and observe how the diagrams are essentially identical to the LG jigsaw-puzzle piece diagrams of the foundational LG publications.
If you have any questions, please feel free to send a note to the mailing list.
The source code of link-parser and the link-grammar library is located at GitHub.
For bug reports, please open an issue there.
Although all messages should go to the mailing list, the current maintainers can be contacted at:
Linas Vepstas - <[email protected]>
Amir Plivatsky - <[email protected]>
Dom Lachowicz - <[email protected]>
A complete list of authors and copyright holders can be found in the AUTHORS file. The original authors of the Link Grammar parser are:
Daniel Sleator [email protected]
Computer Science Department 412-268-7563
Carnegie Mellon University www.cs.cmu.edu/~sleator
Pittsburgh, PA 15213
Davy Temperley [email protected]
Eastman School of Music 716-274-1557
26 Gibbs St. www.link.cs.cmu.edu/temperley
Rochester, NY 14604
John Lafferty [email protected]
Computer Science Department 412-268-6791
Carnegie Mellon University www.cs.cmu.edu/~lafferty
Pittsburgh, PA 15213
Some working notes.
Easy to fix: provide a more uniform API to the constituent tree. ie provide word index. Also, provide a better word API, showing word extent, subscript, etc.
There are subtle technical issues for handling capitalized first words. This needs to be fixed. In addition, for now these words are shown uncapitalized in the result linkages. This can be fixed.
Maybe capitalization could be handled in the same way that a/an could be handled! After all, it's essentially a nearest-neighbor phenomenon!
See also issue 690
The proximal issue is to add a cost, so that Bill gets a lower cost than bill.n when parsing "Bill went on a walk". The best solution would be to add a 'capitalization-mark token' during tokenization; this token precedes capitalized words. The dictionary then explicitly links to this token, with rules similar to the a/an phonetic distinction. The point here is that this moves capitalization out of ad-hoc C code and into the dictionary, where it can be handled like any other language feature. The tokenizer includes experimental code for that.
The old for parse ranking via corpus statistics needs to be revived. The issue can be illustrated with these example sentences:
"Please the customer, bring in the money"
"Please, turn off the lights"
In the first sentence, the comma acts as a conjunction of two directives (imperatives). In the second sentence, it is much too easy to mistake "please" for a verb, the comma for a conjunction, and come to the conclusion that one should please some unstated object, and then turn off the lights. (Perhaps one is pleasing by turning off the lights?)
When a sentence fails to parse, look for:
Poor agreement might be handled by giving a cost to mismatched lower-case connector letters.
An common phenomenon in English is that some words that one might expect to "properly" be present can disappear under various conditions. Below is a sampling of these. Some possible solutions are given below.
Expressions such as "Looks good" have an implicit "it" (also called a zero-it or phantom-it) in them; that is, the sentence should really parse as "(it) looks good". The dictionary could be simplified by admitting such phantom words explicitly, rather than modifying the grammar rules to allow such constructions. Other examples, with the phantom word in parenthesis, include:
This can extend to elided/unvoiced syllables:
Elided punctuation:
Normally, the subjects of imperatives must always be offset by a comma: "John, give me the hammer", but here, in muttering an oath, the comma is swallowed (unvoiced).
Some complex phantom constructions:
See also GitHub issue #224.
Actual ellipsis:
Here, the ellipsis stands for a subordinate clause, which attaches with not one, but two links: C+ & CV+ , and thus requires two words, not one. There is no way to have the ellipsis word to sink two connectors starting from the same word, and so some more complex mechanism is needed. The solution is to infer a second phantom ellipsis:
where the first ellipsis is a stand in for the subject of a subordinate clause, and the second stands in for an unknown verb.
Many (unstressed) syllables can be elided; in modern English, this occurs most commonly in the initial unstressed syllable:
Poorly punctuated sentences cause problems: for example:
"Mike was not first, nor was he last."
"Mike was not first nor was he last."
The one without the comma currently fails to parse. How can we deal with this in a simple, fast, elegant way? Similar questions for zero-copula and zero-that sentences.
Consider an argument between a professor and a dean, and the dean wants the professor to write a brilliant review. At the end of the argument, the dean exclaims: "I want the review brilliant!" This is a predicative adjective; clearly it means "I want the review [that you write to be] brilliant." However, taken out of context, such a construction is ungrammatical, as the predictiveness is not at all apparent, and it reads just as incorrectly as would "*Hey Joe, can you hand me that review brilliant?"
"Push button"
"Push button firmly"
The subject is a phantom; the subject is "you".
One possible solution is to perform a one-point compactification. The dictionary contains the phantom words, and their connectors. Ordinary disjuncts can link to these, but should do so using a special initial lower-case letter (say, 'z', in addition to 'h' and 'd' as is currently implemented). The parser, as it works, examines the initial letter of each connector: if it is 'z', then the usual pruning rules no longer apply, and one or more phantom words are selected out of the bucket of phantom words. (This bucket is kept out-of-line, it is not yet placed into sentence word sequence order, which is why the usual pruning rules get modified.) Otherwise, parsing continues as normal. At the end of parsing, if there are any phantom words that are linked, then all of the connectors on the disjunct must be satisfied (of course!) else the linkage is invalid. After parsing, the phantom words can be inserted into the sentence, with the location deduced from link lengths.
A more principled approach to fixing the phantom-word issue is to borrow the idea of re-writing from the theory of operator grammar. That is, certain phrases and constructions can be (should be) re-written into their "proper form", prior to parsing. The re-writing step would insert the missing words, then the parsing proceeds. One appeal of such an approach is that re-writing can also handle other "annoying" phenomena, such as typos (missing apostrophes, eg "lets" vs. "let's", "its" vs. "it's") as well as multi-word rewrites (eg "let's" vs. "let us", or "it's" vs. "it is").
Exactly how to implement this is unclear. However, it seems to open the door to more abstract, semantic analysis. Thus, for example, in Meaning-Text Theory (MTT), one must move between SSynt to DSynt structures. Such changes require a graph re-write from the surface syntax parse (eg provided by link-grammar) to the deep-syntactic structure. By contrast, handling phantom words by graph re-writing prior to parsing inverts the order of processing. This suggests that a more holistic approach is needed to graph rewriting: it must somehow be performed "during" parsing, so that parsing can both guide the insertion of the phantom words, and, simultaneously guide the deep syntactic rewrites.
Another interesting possibility arises with regards to tokenization. The current tokenizer is clever, in that it splits not only on whitespace, but can also strip off prefixes, suffixes, and perform certain limited kinds of morphological splitting. That is, it currently has the ability to re-write single-words into sequences of words. It currently does so in a conservative manner; the letters that compose a word are preserved, with a few exceptions, such as making spelling correction suggestions. The above considerations suggest that the boundary between tokenization and parsing needs to become both more fluid, and more tightly coupled.
Compare "she will be happier than before" to "she will be more happy than before." Current parser makes "happy" the head word, and "more" a modifier w/EA link. I believe the correct solution would be to make "more" the head (link it as a comparative), and make "happy" the dependent. This would harmonize rules for comparatives... and would eliminate/simplify rules for less,more.
However, this idea needs to be double-checked against, eg Hudson's word grammar. I'm confused on this issue ...
Currently, some links can act at "unlimited" length, while others can only be finite-length. eg determiners should be near the noun that they apply to. A better solution might be to employ a 'stretchiness' cost to some connectors: the longer they are, the higher the cost. (This eliminates the "unlimited_connector_set" in the dictionary).
Sometimes, the existence of one parse should suggest that another parse must surely be wrong: if one parse is possible, then the other parses must surely be unlikely. For example: the conjunction and.jg allows the "The Great Southern and Western Railroad" to be parsed as the single name of an entity. However, it also provides a pattern match for "John and Mike" as a single entity, which is almost certainly wrong. But "John and Mike" has an alternative parse, as a conventional-and -- a list of two people, and so the existence of this alternative (and correct) parse suggests that perhaps the entity-and is really very much the wrong parse. That is, the mere possibility of certain parses should strongly disfavor other possible parses. (Exception: Ben & Jerry's ice cream; however, in this case, we could recognize Ben & Jerry as the name of a proper brand; but this is outside of the "normal" dictionary (?) (but maybe should be in the dictionary!))
More examples: "high water" can have the connector A joining high.a and AN joining high.n; these two should either be collapsed into one, or one should be eliminated.
Use WordNet to reduce the number for parses for sentences containing compound verb phrases, such as "give up", "give off", etc.
To avoid a combinatorial explosion of parses, it would be nice to have an incremental parsing, phrase by phrase, using a sliding window algorithm to obtain the parse. Thus, for example, the parse of the last half of a long, run-on sentence should not be sensitive to the parse of the beginning of the sentence.
Doing so would help with combinatorial explosion. So, for example, if the first half of a sentence has 4 plausible parses, and the last half has 4 more, then currently, the parser reports 16 parses total. It would be much more useful if it could instead report the factored results: ie the four plausible parses for the first half, and the four plausible parses for the last half. This would ease the burden on downstream users of link-grammar.
This approach has at psychological support. Humans take long sentences and split them into smaller chunks that "hang together" as phrase- structures, viz compounded sentences. The most likely parse is the one where each of the quasi sub-sentences is parsed correctly.
This could be implemented by saving dangling right-going connectors into a parse context, and then, when another sentence fragment arrives, use that context in place of the left-wall.
This somewhat resembles the application of construction grammar ideas to the link-grammar dictionary. It also somewhat resembles Viterbi parsing to some fixed depth. Viz. do a full backward-forward parse for a phrase, and then, once this is done, take a Viterbi-step. That is, once the phrase is done, keep only the dangling connectors to the phrase, place a wall, and then step to the next part of the sentence.
Caution: watch out for garden-path sentences:
The horse raced past the barn fell.
The old man the boat.
The cotton clothing is made of grows in Mississippi.
The current parser parses these perfectly; a viterbi parser could trip on these.
Other benefits of a Viterbi decoder:
One may argue that Viterbi is a more natural, biological way of working with sequences. Some experimental, psychological support for this can be found at http://www.sciencedaily.com/releases/2012/09/120925143555.htm per Morten Christiansen, Cornell professor of psychology.
Consider the sentence "Thieves rob bank" -- a typical newspaper headline. LG currently fails to parse this, because the determiner is missing ("bank" is a count noun, not a mass noun, and thus requires a determiner. By contrast, "thieves rob water" parses just fine.) A fix for this would be to replace mandatory determiner links by (D- or {[[()]] & headline-flag}) which allows the D link to be omitted if the headline-flag bit is set. Here, "headline-flag" could be a new link-type, but one that is not subject to planarity constraints.
Note that this is easier said than done: if one simply adds a high-cost null link, and no headline-flag, then all sorts of ungrammatical sentences parse, with strange parses; while some grammatical sentences, which should parse, but currently don't, become parsable, but with crazy results.
More examples, from And Rosta:
"when boy meets girl"
"when bat strikes ball"
"both mother and baby are well"
A natural approach would be to replace fixed costs by formulas. This would allow the dialect/sociolect to be dynamically changeable. That is, rather than having a binary headline-flag, there would be a formula for the cost, which could be changed outside of the parsing loop. Such formulas could be used to enable/disable parsing specific to different dialects/sociolects, simply by altering the network of link costs.
A simpler alternative would be to have labeled costs (a cost vector), so that different dialects assign different costs to various links. A dialect would be specified during the parse, thus causing the costs for that dialect to be employed during parse ranking.
This has been implemented; what's missing is a practical tutorial on how this might be used.
A good reference for refining verb usage patterns is: "COBUILD GRAMMAR PATTERNS 1: VERBS from THE COBUILD SERIES", from THE BANK OF ENGLISH, HARPER COLLINS. Online at https://arts-ccr-002.bham.ac.uk/ccr/patgram/ and http://www.corpus.bham.ac.uk/publications/index.shtml
Currently tokenize.c tokenizes double-quotes and some UTF8 quotes (see the RPUNC/LPUNC class in en/4.0.affix - the QUOTES class is not used for that, but for capitalization support), with some very basic support in the English dictionary (see "% Quotation marks." there). However, it does not do this for the various "curly" UTF8 quotes, such as 'these' and “these”. This results is some ugly parsing for sentences containing such quotes. (Note that these are in 4.0.affix).
A mechanism is needed to disentangle the quoting from the quoted text, so that each can be parsed appropriately. It's somewhat unclear how to handle this within link-grammar. This is somewhat related to the problem of morphology (parsing words as if they were "mini-sentences",) idioms (phrases that are treated as if they were single words), set-phrase structures (if ... then ... not only... but also ...) which have a long-range structure similar to quoted text (he said ...).
See also GitHub issue #42.
"to be fishing": Link grammar offers four parses of "I was fishing for evidence", two of which are given low scores, and two are given high scores. Of the two with high scores, one parse is clearly bad. Its links "to be fishing.noun" as opposed to the correct "to be fishing.gerund". That is, I can be happy, healthy and wise, but I certainly cannot be fishing.noun. This is perhaps not just a bug in the structure of the dictionary, but is perhaps deeper: link-grammar has little or no concept of lexical units (ie collocations, idioms, institutional phrases), which thus allows parses with bad word-senses to sneak in.
The goal is to introduce more knowledge of lexical units into LG.
Different word senses can have different grammar rules (and thus, the links employed reveal the sense of the word): for example: "I tend to agree" vs. "I tend to the sheep" -- these employ two different meanings for the verb "tend", and the grammatical constructions allowed for one meaning are not the same as those allowed for the other. Yet, the link rules for "tend.v" have to accommodate both senses, thus making the rules rather complex. Worse, it potentially allows for non-sense constructions. If, instead, we allowed the dictionary to contain different rules for "tend.meaning1" and "tend.meaning2", the rules would simplify (at the cost of inflating the size of the dictionary).
Another example: "I fear so" -- the word "so" is only allowed with some, but not all, lexical senses of "fear". So eg "I fear so" is in the same semantic class as "I think so" or "I hope so", although other meanings of these verbs are otherwise quite different.
[Sin2004] "New evidence, new priorities, new attitudes" in J. Sinclair, (ed) (2004) How to use corpora in language teaching, Amsterdam: John Benjamins
See also: Pattern Grammar: A Corpus-Driven Approach to the Lexical Grammar of English
Susan Hunston and Gill Francis (University of Birmingham)
Amsterdam: John Benjamins (Studies in corpus linguistics, edited by Elena Tognini-Bonelli, volume 4), 2000
Book review.
“The Molecular Level of Lexical Semantics”, EA Nida, (1997) International Journal of Lexicography, 10(4): 265–274. En ligne
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.
Le ??? 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...
