Austausch Format Änderungsvorschläge Diskussion

Tatsächlich gibt es viele Elemente des AF, die auf Kompaktheit abzielen:

• Defaultwerte (Spracheinstellungen)
• Abkürzungen
• Regeln

--rae

Nein, die Möglichkeiten sind auf keinen Fall schon ausgeschöpft. Weitere Komprimierungsmöglichkeiten wäre z.B. die Einführung von Grammatiken. Auch gibt es noch diverse Redundanzen, die man implizit auflösen könnte, wenn man gewisse Annahmen trifft oder z.B. der Funktion zum Erzeugen der abgeleiteteten Worte mehr Informationen übergibt. Ein Beispiel:

Die Regeln, mit denen die abgeleiteten Worte gebildet werden, ordnen diese Worte in einer definierten Reihenfolge an, z.B. Singular Nominativ, Singular Genitiv, Singular Dativ, Singular Akkusativ, Plural Nominativ, Plural Genitiv, Plural Dativ und Plural Akkusativ. Würde man der Ableitungsfunktion z.B. die Attribute in geeigneter Form übergeben, so wäre die Unterscheidung zwischen Regeln für alle Formen, nur-Plural-Formen und nur-Singular-Formen nicht mehr notwendig.

Das AF hat einige Elemente die Anwendungs-spezifisch sind. Ist das notwendig? Wäre es nicht mit geringem Aufwand möglich, das AF zu einem allgemeinen Austauschformat zu machen? Wenn ja, würde sich das nicht lohnen?

--rae

Ich denke, es würde sich schon lohnen. Daß das Format anwendungsspezifisch ist, liegt natuergemäß daran, das es anhand einer Anwendung entworfen wurde.

Was meinst Du eigentlich mit Anwendungsspezifisch? Die Felder mit den Informationen für Frontends?

--hl

1) Betrachten wir den Abschnitt 'definitions'. Die Einträge 'characterset' und 'checksum' sind allgemeingültig und könnten so bei jeder Form von Datenaustausch verwendet werden. Die Einträge 'language' und 'foreignlanguage' aber nicht, sie sind so etwas wie Defaultwerte, die für die nachfolgenden Datensätze gelten. Sie müssen in einem mehrsprachigen Datenbank in entsprchende Feldinhalte umgewandelt werden. Wenn das aber so ist, dann könnte man einen neuen Abschnitt 'defaults' machen, dort Feld=Feldinhalt eintragen (z.B. language=german foreignlanguage=englisch oder abgekürzt lg=de flg=en) und diesen Mechanismus generell nutzen. Bei einem Austausch von "nur Substantiven" könnte man so den Worttyp als default vorgeben und ihn sich bei den einzelnen Datensätzen sparen. So entstünde ein allgemeiner Mechanismus, der das Format noch kompakter machen kann (eine Option für den "Schreiber" des Formats).

Gleichzeitig würde es aber auch die Information 'language' und 'foreignlanguage' aus der Definition des Austauschformates heraus in die Ebene der Felder und Feldinhalte übertragen, wo sie hingehört. So wären dann auch Datensätze mit explizitem "lg=de|flg=en|...." möglich bzw. erlaubt. Diese beiden Felder würden ihren Sonderstatus verlieren und mit Standardmechanismen behandelt.

Ähnliche Überlegungen der Verallgemeinerung kann man bei den Abkürzungen für Felder und Feldinhalte anstellen.

2) Das gleiche gilt für die Regeln, die letztlich so etwas wie optionale, dynamische Felder realisieren (wenn man vom generativen Aspekt der Regel absieht). Letztlich geht es hier um Felder, bei denen die Reihenfolge das Feld definiert. Wenn man das durchdenkt, dann könnten bestimmte Datenbankauszüge überhaupt auf Feldnamen in den Datensätzen verzichten, weil in einer (allgemeinen Regel) definiert ist, wie

           Gauner/Spitzbube|s|m/m|%0, %0/%0, %0n|maskulin 2/maskulin 3

auf

           wo: Gauner/Spitzbube|ty: s|la: m/m|br: %0, %0/%0, %0n|ru: maskulin 2/maskulin 3

zuzuordnen ist. Zumindest hätte das in einem allgemeinen Datenaustauschformat große Bedeutung, wenn man fixformatige, simple Datensätze überträgt.

Im Grunde genommen könnte man das Austauschformat aus zwei unabhängigen Teilen aufbauen. Der eine beschreibt das Format (Abschnitt, Trennzeichen, Defaults, Abkürzungen, Regeln) ohne jemals auf die Anwendung oder sprachliche Inhalte Bezug zu nehmen. Der andere (anwendungsspezifische) Teil beschreibt die Felder und Inhalte im Rahmen unserer Anwendungen. Dabei würde sich am Wesen des Formates kaum etwas ändern und auch die Umstellungen in der Syntax könnte man gering halten.

3) Wichtig ist mir das deshalb, weil ich ja in der Datenbank mit anderen Feldinhalten und Abkürzungen arbeite und dritte Anwender auch eigene Systeme verwenden. Es muss also eine Übersetzung stattfinden. Eine Übersetzung zwischen den Systemen ist aber leichter für mich, wenn das Austauschformat nicht mit den bestimmten Darstellungsform (Feldnamen, Inhaltskürzel) einer Applikation verheiratet ist, sondern ein neutraler Modul ist.

Kannst du mit diesen Ideen etwas anfangen?

--rae

Ich habe es mal etwas nummeriert:

1) language und foreignlanguage sind nur mittelbar Defaultwerte: Ich arbeite mit n+1 Dateien, wobei n die Anzahl der Sprachen darstellt. Dabei verwende ich eine lexikalischen Datei, die die Basisworte enthält sowie für jede Sprache eine eigene Datei, die sich auf die lexikalische Datei bezieht. Die Variablen language und foreignlanguage geben nur an, welche Sprachdatei geladen werden soll(en). Würde es Sinn machen, innerhalb des AF die Sprache zu wechseln? Wenn ja, würde es Sinn machen, die angabe der Sprache in den Wortbereich zu ziehen. Zur Zeit soll mit dem AF maximal ein Sprachpaar erfasst werden, nicht die Gesamtheit der Datenbasis.

--hl

Der Wb3Prototyp enthält alle Sprachen in einer einzigen Datei, daher gibt es dort ein Feld WB3.lang, das diese Information enthält. Aus der Sicht des WB3 schauen diese Definitionen also wie Defaultwerte aus.

Zusätzliche Fragen: Was ist der Produktname für deine Übersetzungssoftware? Was bedeutet lexikalisch in deiner Welt? Was sind Basisworte?

--rae

Produktname? Wie gesagt, der Arbeitstitel lautet z.Zt. Translator. Fuer den öffentlichen Namen muß ich mich erst mal markenrechtlich schlau machen (es gibt da in München ...). Ein Basiswort ist bei mir eine universelle Version der Lexeme aus der Linguistik. Wenn es z.B. in einer Sprache 20 verschiedene Begriffe für das deutsche Wort Schnee gibt, dann enthält die lexikalische Datei mindestens 20 verschiedene Worte für den Begriff Schnee. Diese werden durch das Feld de eindeutig definiert. Da das russische Wort für rot einen anderen Farbton umschreibt wie das deutsche Wort rot, gibt es auch dieses Begriff mehrfach in der lexikalischen Datei, mit der jeweils eindeutigen Beschreibung.

2) Die Feldnamen fortzulassen, würde bedingen, daß alle Elemente fest an einer Position definiert sind, wodurch jeder Eintrag alle Felder enthalten müßte. Dies wäre ein Nachteil, da die Anzahl der Felder später nur mit Problemen veränderbar wäre und sich bei manueller Bearbeitung der Daten unnötige Fehler einschleichen würden. Daß die Daten in den Beispielen einen identischen Aufbau haben, liegt an der ungeschickten Auswahl der Beispiele. In den kompletten Dateien sind die Daten zwar nicht bunt durcheinandergewürfelt, aber doch nicht ganz so homogen, da ich bei der Bearbeitung ab und zu ein Formtief hatte.

--hl

Das würde ich auch gar nicht vorschlagen. Aber wenn jemand das Austauschformat z.B. verwenden wollte um nur eine einfache Wortliste zu erzeugen, dann hätte er in jeder Zeile nur ein Feld und überall den Feldnamen dabei. In solchen Fällen wäre eine "Regel" für die Zeile als ganzes praktisch. Ich sehe das als reine Option.

--rae

Grummel --- wieso habe ich das Problem mit den Listen wohl erwaehnt? (;-) ). Also eine Definition in der Art

                           fixedLine=bw|ty

wenn die Liste lediglich das Wort und den Worttyp umfasst?

3) Damit die Daten in mehrere Projekte uebernommen werden können, werden wir nicht darum herumzukommen, einige Grundwerte fest zu definieren. Wir können ja erstmal meine Begriffe und Kürzel an deine anpassen, da diese bei meinem Programm zentral liegen --- der Änderungsaufwand würde sich also in Grenzen halten, da ich nur eine Funktion im Parser ändern müßte.

--hl

Das wäre zwar eine einfache Lösung, aber wenn die nächste oder übernächste Applikation käme, dann würde sich das Problem wieder stellen und einen Zwang zu einem gemeinsamen Datenformat erzeugen. Mir wäre es lieber, wenn es eine flexible Zuordnung von Feldern zwischen Datenbank und den Applikationen gäbe.

--rae

Was spricht dagegen, die Realisierung des Parsers dem einzelnen Entwickler zu überlassen? Wenn ihn nur ein bestimmter Subset aus der Datenbank interessiert, kann er den Rest einfach ignorieren und wenn er zusätzliche Informationen unterbringen will, muß er hat dafür ein Feld definieren und dieses publik machen. Der Rest kann dann entscheiden, ob das Feld für die eigene Applikation brauchbar ist oder nicht. Es muß nur sichergestellt sein, daß bei einem reexport keine Informationen verloren gehen. Wenn also jemend die Datenbasis importiert und nur die Worte für seine Applikation benötigt, dann ist das ok. Er muß nur dafür sorgen, daß, wenn er die Daten seiner Applikation wieder exportiert, eine Datei mit den vollen Informationen generiert wird (wobei die Informationen bei den neuen Worten natürlich nur aus dem Wort selbst bestehen würde).

Die Verwendung von Defaultwerten halte ich für eine gute Idee, da die Datei bei geeigneter Sortierung dadurch wirklich kompakter werden kann. Allerdings sollte man da vielleicht einen speziellen Datensatz definieren. Dadurch könnte man die Defaultwerte on the fly ändern, ohne für jeden Wert eine separate Eingabedatei zu verwenden. Eine weitere Möglichkeit für Defaultwerte könnte z.B. ein vor das Wort gesetztes + sein. Dieser Wert wäre dann bis auf weiteres auch der Defaultwert.

Der Begriff Translator ist sicher nicht markenfähig, weil es ein normales englische Wort ist, das Du nicht schützen kannst. Ich hatte z.B. teilweise Probleme mit meinen Marken INFOWARE und INFOLAND, weil sie zu viel offensichtliche Bedeutung tragen. In Österreich sind sie durchgegangen, in Deutschland nicht. Aber wir können ja bis du einen Produktnamen hast (wie wärst mit LATRA = LAnguage TRAnslator), vom TranslatorProjekt sprechen.

F

In welcher Sprache führst du die lexikalische Datei? -- hl

A

Momentan im mixed mode --- je nach dem in welcher Sprache ein neues Wort definiert wird. Ich wollte die Sprache in dem Feld de noch extra markieren, hatte aber bisher noch keine brauchbare Idee -- rae

http://babelfish.altavista.com/translate.dyn