Nltk: Integrieren Sie einen genaueren Satzteiler, Tokenizer und/oder Lemmatizer für Englisch?

+1 @nschneid Der Großteil von Rebeccas Arbeit ist in HPSG, das ich gerne in NLTK integrieren würde, aber es ist eine harte Nuss. @goodmami , @fcbond und die DELPH-IN-Gruppe haben mit https://github.com/delph-in/pydelphin einiges an Arbeit geleistet

Möglicherweise ist ein Python-Wrapper für Repp den Code wert =)

Es gibt eine zur Wort-Tokenisierung und dies und dies zur Satzteilung.

Wenn ich zitierende Artikel betrachte, sehe ich dies und das für verschiedene Genres von Webtexten. Auch dies für die News-Domain.

@nschneid Nach einigem Durchforsten des REPP-Codes gibt es ziemlich viele LISP-Regeln, die in einer separaten Datei geschrieben sind. Vielleicht könnten wir als erstes versuchen, sie alle in einer einzigen Textdatei zu organisieren und dann einen Wrapper zu schreiben, um diese Regeln zu lesen. Oder vielleicht ist es einfacher, das gesamte Tool selbst zu umhüllen, wie wir es mit nltk.tag.stanford :

alvas<strong i="8">@ubi</strong>:~/repp$ cat test.txt
Tokenization is widely regarded as a solved problem due to the high accuracy that rulebased tokenizers achieve. 
But rule-based tokenizers are hard to maintain and their rules language specific. 
We show that high accuracy word and sentence segmentation can be achieved by using supervised sequence labeling on the character level combined with unsupervised feature learning. 
We evaluated our method on three languages and obtained error rates of 0.27 ‰ (English), 0.35 ‰ (Dutch) and 0.76 ‰ (Italian) for our best models.

alvas<strong i="9">@ubi</strong>:~/repp$ cat test.txt|src/repp -c erg/repp.set 
Tokenization is widely regarded as a solved problem due to the high accuracy that rulebased tokenizers achieve .
But rule-based tokenizers are hard to maintain and their rules language specific .
We show that high accuracy word and sentence segmentation can be achieved by using supervised sequence labeling on the character level combined with unsupervised feature learning .
We evaluated our method on three languages and obtained error rates of 0.27 ‰ ( English ) , 0.35 ‰ ( Dutch ) and 0.76 ‰ ( Italian ) for our best models .

alvas<strong i="10">@ubi</strong>:~/repp$ cat test.txt|src/repp -c erg/repp.set --format triple
(0, 12, Tokenization)
(13, 15, is)
(16, 22, widely)
(23, 31, regarded)
(32, 34, as)
(35, 36, a)
(37, 43, solved)
(44, 51, problem)
(52, 55, due)
(56, 58, to)
(59, 62, the)
(63, 67, high)
(68, 76, accuracy)
(77, 81, that)
(82, 91, rulebased)
(92, 102, tokenizers)
(103, 110, achieve)
(110, 111, .)

(0, 3, But)
(4, 14, rule-based)
(15, 25, tokenizers)
(26, 29, are)
(30, 34, hard)
(35, 37, to)
(38, 46, maintain)
(47, 50, and)
(51, 56, their)
(57, 62, rules)
(63, 71, language)
(72, 80, specific)
(80, 81, .)

(0, 2, We)
(3, 7, show)
(8, 12, that)
(13, 17, high)
(18, 26, accuracy)
(27, 31, word)
(32, 35, and)
(36, 44, sentence)
(45, 57, segmentation)
(58, 61, can)
(62, 64, be)
(65, 73, achieved)
(74, 76, by)
(77, 82, using)
(83, 93, supervised)
(94, 102, sequence)
(103, 111, labeling)
(112, 114, on)
(115, 118, the)
(119, 128, character)
(129, 134, level)
(135, 143, combined)
(144, 148, with)
(149, 161, unsupervised)
(162, 169, feature)
(170, 178, learning)
(178, 179, .)

(0, 2, We)
(3, 12, evaluated)
(13, 16, our)
(17, 23, method)
(24, 26, on)
(27, 32, three)
(33, 42, languages)
(43, 46, and)
(47, 55, obtained)
(56, 61, error)
(62, 67, rates)
(68, 70, of)
(71, 75, 0.27)
(76, 77, ‰)
(78, 79, ()
(79, 86, English)
(86, 87, ))
(87, 88, ,)
(89, 93, 0.35)
(94, 95, ‰)
(96, 97, ()
(97, 102, Dutch)
(102, 103, ))
(104, 107, and)
(108, 112, 0.76)
(113, 114, ‰)
(115, 116, ()
(116, 123, Italian)
(123, 124, ))
(125, 128, for)
(129, 132, our)
(133, 137, best)
(138, 144, models)
(144, 145, .)

Möglicherweise gibt es auch Einschränkungen in der Werkzeugkette, wenn sie auch den HPSG-Parser erreicht. Vielleicht wäre es besser, direkt das ACE http://sweaglesw.org/linguistics/ace/ mit der pyDelphin Schnittstelle zu verwenden.

Nebenbei bemerkt gibt es auch diese aus dem Moses MT-Toolkit: https://github.com/moses-smt/mosesdecoder/tree/master/scripts/tokenizer . Für diese wäre es gut, für eine bessere Konsistenz zwischen nltk.translate und mosesdecoder

Als Referenz gibt es auch Penn Treebank Tokenizer , die Kunst der Tokenisierung und bio/medizinische Tokenizer

@alvations Ich glaube nicht, dass wir viel gewinnen würden, wenn wir einen vollständigen Parser wie ACE nur für die Tokenisierung verwenden, es sei denn, Sie möchten auch eine morphologische Analyse oder eine Pronomenerkennung oder einen Quantifiziererbereich oder etwas anderes. Ich glaube nicht, dass es allzu schwierig wäre, einen REPP-Tokenizer in pyDelphin zu implementieren, der nicht die vollständigen Grammatiken oder Parser benötigt (siehe das neu erstellte delph-in/pydelphin#43), oder vielleicht könnte eine solche Implementierung so sein eigenständiges Modul (dh getrennt von pyDelphin), was die Einbindung in NLTK erleichtern würde.

Aber REPP ist im Grunde nur ein System von regulären Ausdrücken mit ein paar zusätzlichen Feinheiten, daher denke ich, dass der Hauptvorteil von NLTK darin besteht, dass es die für die DELPH-IN-Grammatiken entwickelten Systeme verwenden kann. In dem von @nschneid verlinkten Papier heißt es jedoch, dass Dridan und Oepen „zwei Drittel der verbleibenden Tokenisierungsfehler“ in den PTB-Daten eliminieren, verglichen mit dem damals leistungsstärksten Standardsystem durch Verwendung von REPP. In einer ähnlichen Anmerkung haben Fokkens et al.

@nschneid für den http://stackoverflow.com/questions/34416365/unpacking-tuple-like-textfile

Welche Implementierung sollten wir verwenden, um REPP in NLTK einzuschließen?

@goodmami Inzwischen ist die langsamere, aber einfacher zu wartende Option, die LISP + Perl + Boost-Regexes neu zu schreiben, aber ich denke, wir können dies stattdessen in pyDelphin belassen. Einige Anmerkungen: http://stackoverflow.com/questions/34048609/converting-c-boost-regexes-to-python-re-regexes Es wird langsam für mich und ich beende meine Doktorarbeit. Ich werde mein Bestes geben, wenn ich in Zügen / Bussen reise, die beim Versuch, Regexes zu portieren, einige Zeit kosten sollten =)

Ich habe keine besonderen Einwände gegen REPP, aber es könnte sich lohnen, andere Tools zu erkunden, die es gibt.

Zum Beispiel ist https://github.com/armatthews/TokenizeAnything in Python geschrieben und behauptet, für die meisten Sprachen etwas Vernünftiges zu tun. (Es ist eine ziemlich junge Implementierung, basiert aber auf https://github.com/redpony/cdec/blob/master/corpus/tokenize-anything.sh, das es schon eine Weile gibt.) @armatthews , meinst du das

Eine weitere Frage im weiteren Sinne ist, welche Optionen/Funktionen der Tokenizer unterstützen soll. Ich denke, es wäre z. B. nützlich zu haben:

• eine Option zum Trennen von clitics wie "'s" und "n't" oder nicht auf Englisch ( --no_english_apos in TokenizeAnything)
• versetzt zurück in die ursprüngliche Zeichenfolge

+1 für TokenizeAnything. Es gibt auch https://github.com/jonsafari/tok-tok von @jonsafari.

Ich habe einen kleinen Wrapper für REPP geschrieben: https://github.com/alvations/nltk/blob/repp/nltk/tokenize/repp.py. Werde eine PR machen, sobald die translate Module stabiler sind.

tok-tok.pl in Python portiert: https://github.com/alvations/nltk/blob/repp/nltk/tokenize/toktok.py auch.

@alvations, also haben Sie eine REPP-Binärdatei verpackt, anstatt einen REPP-Prozessor zu implementieren? Es wäre dann gut, einen Link bereitzustellen, wo jemand eine solche Binärdatei bekommen könnte. Und ich habe die REPP-Binärdatei nicht direkt verwendet --- wissen Sie, wie portabel sie ist?

@goodmami Ich würde die Informationen auf https://github.com/nltk/nltk/wiki/Installing-Third-Party-Software veröffentlichen, sobald ich etwas Zeit für eine PR habe. Ich habe den Wrapper geschrieben, während ich in einem Zug ohne WLAN feststeckte =)

Ich bin mir jedoch nicht sicher, ob REPP außerhalb von Linux funktioniert, möglicherweise müssen wir Rebecca oder Stefan fragen, ob sie versucht haben, REPP auf einem Windows/Mac zu installieren. Irgendwann möchte ich REPP immer noch neu implementieren, aber so viel Zeit kann ich noch lange nicht mehr investieren.

Wenn jemand anderes daran interessiert ist, andere Tokenizer/Stemmer/Lemmatizer neu zu implementieren/zu verpacken, würde ich die folgende Liste von Tools vorschlagen, die ein good-first-contribution für NLTK erzeugen würden.

• Moses-Tokenizer + De-Tokenizer
• Elefant
• Alles tokenisieren

Entschuldigung, dass ich das Problem fälschlicherweise geschlossen habe. Es ist jetzt wieder geöffnet.

Jetzt, da Moses Tokenizer und Detokenizer funktionieren (#1551, #1553), möchte jede mutige Seele versuchen, Elephant mit sklearn zu implementieren?

Ab #1860 sieht es so aus, als ob der TreebankTokenizer, den wir als Standard word_tokenize() ziemlich veraltet ist und URL- und Datums-Parsing nicht wirklich unterstützt wird.

Schaut man sich die TreebankTokenizer Regexes und MosesTokenizer Regexes genauer an, gibt es keine einfache Lösung.

Für TreebankTokenizer ist es möglicherweise einfacher, die Doppelpunkte unter https://github.com/nltk/nltk/blob/develop/nltk/tokenize/treebank.py#L76 von den Kommas zu

Für Moses sieht es so aus, als hätte sich der Standard-Tokenizer nicht darum gekümmert, die Zahlen zusammenzuhalten:

$ echo 'This is a sentence with dates like 23/12/1923 and 05/11/2013, and an URL like https://hello.world.com' > test.in

$ ~/mosesdecoder/scripts/tokenizer/tokenizer.perl -l en < test.in 
This is a sentence with dates like 23 / 12 / 1923 and 05 / 11 / 2013 , and an URL like https : / / hello.world.com

Vielleicht müssen wir einen moderneren Tokenizer als NLTK-Standard word_tokenize() in Betracht ziehen?

Vielleicht müssen wir einen moderneren Tokenizer als NLTK-Standard word_tokenize() in Betracht ziehen?

Betrachten Sie #2202? :)

Außerdem scheint der aktuelle Fehler (ich meine Nr. 1214) das Tokenizer-Label zu vermissen

@alvations fehlt