[Trennmuster] neuer Arbeitsansatz

[Stephan Hennig]

Am 05.11.2016 um 00:20 schrieb Guenter Milde:
> On  4.11.16, Stephan Hennig wrote:
> 
>> Kannst du zum besseren Verständnis bitte Beispiele für
> 
>>   süsssauer
>>   süssauer
> 
>> angeben? 
> 
> -1-;-2-;süss=sau-er;süss=sau-er;-5-
> -1-;-2-;-3-;-4-;sü{ss/ss=s}au-er


Danke!


> Die Frage ist, 
> 
> * ob alle Felder eines Eintrags den gleichen "Schlüssel" haben
>   sollen.
> * ob Einträge die sich aus Einträgen mit anderem Schlüssel generieren lassen
>   (z.B. -1-;Faß=brau-se aus Fass=brau-se) weggelassen werden können/sollen.


Von mir zweimal ja.

>> Wenn automatische Transformationen schon stattfinden, halte ich es für
>> sinnvoll, den Vorgang modular zu gestalten und beliebige
>> Transformationen durch Nutzer zu unterstützen.  Beispiele wären
> 
>>   * Ableiten bzw. Extrahieren von de-1901
>>   * Ableiten bzw. Extrahieren von de-1901-CH
>>   * Unterbinden von Trennungen markiert mit ...
>>   *                  -"-                    ..
>>   *                  -"-                    .
>>   *      "       "  Sprechsilben in de-1996
>>   *      "       "  sämtlichen Stammtrennungen
>>   * Ableiten von ss-Schreibungen
>>   * Ableiten von sz-Schreibungen
>>   * beliebige weitere individuelle Manipulationen, etwa Unterbinden
>>     der Trennung ti-on u. ä.
>>   * Ableiten von Ligaturmustern
>>   * Ableiten von Rund-s-Mustern
>>   * ...
> 
> Hier geht es zunächst um eine Spezifikation des neuen Datenformats, nicht
> darum was wir alles damit machen können.


Mir ist nicht klar, ob die Wortlisten der einzelnen Varietäten aus der
(neuen) Urliste abgeleitet werden sollen oder aus der Langform?  Wenn
ersteres zutrifft und gleichzeitig die Langform ß-Ersatzschreibungen
enthalten soll, dann wird die Ableitung der Ersatzschreibungen
möglicherweise doppelt an zwei verschiedenen Stellen implementiert.  Das
wäre nicht schön.  Daher bringe ich die Modularisierung hier ins Spiel.


> Wir brauchen dazu die Transformationen um das bisherige Wortlisten-Format
> (Langform) zu rekonstruieren. 
>   Diese müssen auch relativ schnell sein, da die Auswirkung jeder
> (mittelgroße) Änderung in den "wortlisten" auf die generierte Wortliste
> vor einem Kommit geprüft werden soll(te).


Hm.  Für die Erzeugung der Patgeneingabe wären Filter sinnvoll, die die
Eingabe zeilenweise abarbeiten und das Ergebnis der Transformation für
jede Eingabezeile in die Ausgabe schreibt.  Ein SZ-Filter würde dann
jeweils das ungeänderte Wort und bei Bedarf zusätzlich eine
SZ-Schreibung ausgeben.  Für die Erzeugung des Langformats wiederum wäre
diese Art der Verkettung nicht sinnvoll.  Dort sollten die anzuwendenden
Filter der Reihe nach auf jedes Wort angewendet werden, was mit
Sicherheit langsam wird.

Im Sinne der Modularisierung wäre es für die Erzeugung der Langform
vielleicht sinnvoll, die einzelnen Varietäten einzeln (und schnell) zu
erzeugen, die Ergebnisse jeweils in assoziativen Feldern zu speichern
mit dem Ausgangswort als Schlüssel und hinterher die jeweiligen
Komponenten pro Schlüssel wieder zusammenzuklauben.  Hinterher wäre dann
noch ein Sortierdurchlauf nötig (oder über die Schlüssel kann gleich in
sortierter Reihenfolge iteriert werden, keine Ahnung, ob das in Perl
oder Python möglich wäre).  Mal wieder ein Gedankensplitter.


>> Vorschlag, es existiert eine Steuerdatei, die die Reihenfolge und
>> vollständigen Aufrufe der Module für eine bestimmte Zielvarietät
>> enthält.  Diese Steuerdatei wird von einem (möglichst) in Shell
>> geschriebenen Skript abgearbeitet.  Die Ausführungszeit mag bei einem
>> solchen generischen Ansatz etwas leiden, aber Muster werden ja nicht so
>> häufig erzeugt.
> 
> Die Steuerdatei könnte genausogut so wie bisher das Makefile sein.


Der Nachteil von Make ist, dass sich damit nicht einfach ein
Zwischenschritt einfügen lässt.  Man müsste entweder das vorhergehende
oder nachfolgende Ziel ebenfalls anpassen.  Außerdem ist für einen
Filterschreiber (Anwender) unerheblich, wie die Verkettung technisch
erfolgen soll (teilweise per Pipe oder nur über temporäre Dateien und
wie die Dateien dann jeweils heißen).  Es wäre schön, wenn ein Anwender
lediglich den vollständigen Aufruf des neuen Filters sowie die Position
innerhalb der Verarbeitungskette bekannt machen muss.  Beides ließe sich
in einer einfachen Textdatei übersichtlich angeben.

Viele Grüße,
Stephan Hennig