Meyers Konversationslexikon

Text archives Help


Re: [Meyers] Vorverarbeitung?


Chronological Thread 
  • From: Laeuter <laeuter AT mathematik.uni-leipzig.de>
  • To: meyers AT lists.franken.de
  • Subject: Re: [Meyers] Vorverarbeitung?
  • Date: Thu, 11 Sep 2003 09:40:46 +0200
  • List-id: Meyers Konversationslexikon <meyers.lists.franken.de>

> Ja, das habe ich z.T. auch. Sowie "o" an dritter oder vierter Stelle
> durch "0" ersetzen.

Kann ich gut einbauen, kam mir aber noch nicht oft vor.

> "IL" ist eigentlich immer "II." etc.

Ja, die römischen Zahlen kann man gut korrigieren, baue ich ein.

> und dann die ganzen s- und f-Verwechselungen...
>
> > - Zusammenziehen von bis zu 12 Buchstabengruppen (unter Weglassung von
> > Bindestrichen, Leerzeichen und Punktuation), bis ein bekanntes Wort
> > entsteht (*).
> > - Berichtigen von Wörtern (*).
>
> Das sind interessante Ansätze.

Wie die Beispieldateien zeigen, werden sowohl s/f als auch U/u bei
vielen Wörtern gut korrigiert. Deswegen nutze ich für diese
Erkennungsfehler keine Muster mehr.

> > Der resultierende Text wird ausgegeben, wahlweise mit Markierung von
> > unbekannten Wörtern und korrigierten Stellen.
>
> Gut, aber die Eintragsgrenzen sind jetzt erst einmal komplett
> verschwunden? Ich denke, es wäre gut, wenn mal als allererstes die
> Grenzen der Einträge (händisch) festlegt und gleichzeitig die
> Worttrennungen am Zeilenende aufhebt.

Wenn wir die automatische Vorverarbeitung vor den Download setzen, kommt
man händisch nicht an die Stelle, wo man Formatierungen einfügen kann.
Für meinen Geschmack kommen zu viele Worttrennungen mitten in der
ASCII-Zeile, als dass die fehlerhaften Trennungen am Zeilenende eine
Sonderbehandlung bekommen sollten. Zumal beide Trennungen von meinem
Vorverarbeitungsprogramm so weit wie möglich weggenommen werden.
Die Grenzen der Einträge sind doch in der downgeloadeten Datei nicht
ansatzweise herausgehoben, so dass man für die wenigen Einträge pro
Seite diesen Hieb auf die Enter-Taste spendieren kann.
Zum Thema der Einträge könnte ich mir nur noch vorstellen, sich den
letzten Eintrag zu merken und nach einem Wort zu suchen, das
alphabetisch einen nicht zu großen Sprung macht. Das Programm könnte
hier eine Trennzeile einfügen (die man im Fehlerfall wieder löschen
müsste). Das habe ich aber noch nicht implementiert, und ich weiß auch
nicht, wie zuverlässig das funktionieren würde.

> > Nun sollte man einen solch wichtigen Eingriff in die Datenbank nur
> > machen, wenn man *wirklich* den Eindruck hat, dass die bestmögliche
> > Arbeit geleistet wurde und damit die Produktivität tatsächlich
> > verbessert wird. Wie gewährleisten wir das?
>
> Der korrigierte Text darf nicht schlimmer werden, als er vorher war.
> Wenn ich mein Skript über 14/768 nach einer Vorformatierung laufen
> lasse, dann kommt das dabei heraus (einige Features könnte ich von
> deinem Skript gut gebrauchen, denke ich):

Wenn ich mir das Resultat ansehe, besteht die Vorformatierung
anscheinend aus dem Durchlesen des Texts, denn einige behobene
Trennungen sind mitten in der Zeile. Zweimal durch den Text durchgehen
mag ich ehrlich gesagt nicht.

Ich sehe durchaus, dass die automatische Korrektur u. a. bei den Autoren
der Literaturangaben einiges verpfuscht.

Um die Vorverarbeitung zu verbessern, würde ich gerne wissen, wie das
aktuelle Programm im Vergleich zur bisherigen Arbeitsweise abschneidet.
Wäre es zuviel verlangt, zwei von den Beispielseiten zu korrigieren,
einmal auf die Art, die jeder bisher gewöhnt war und einmal von der
automatisch korrigierten Version (vorher # per Suchen&Ersetzen löschen,
_ vielleicht auch)? Und immer die Zeit messen. Wenn dann jeder seine
Erfahrungen an die Liste schickt, weiß man vielleicht eher, was im
Programm besser zu machen ist.

Viele Grüße,
Martin Läuter.





Archive powered by MHonArc 2.6.19+.

Top of page