Sollte man nicht lieber in dem SENSE Attribut nur eine genormte Liste zur verfügung stellen? So dass man z.B. alle Wörter finden kann die zur Domäne "Kochkunst" gehören, ohne dass man auch noch "Kochk.", "Kochen", ... mit durchsuchen muss?

1. wie viele ORTH Felder kann es wirklich geben?
(Die Frage stellt sich, ja immer, ob man evtl. entweder Speicherplatz durch spaltenbasiertes Speichern (also NULL values in spalten), oder Prozessorzeit durch zeilenbasiertes Speichern verschwendet. Denn das was Zeilenbasiert ist, muss nacher durch Joins wieder zusammengefügt werden, ist aber in der Anzahl sehr flexibel)

2. Kann es mehrere PRON felder geben die womöglich auch noch zu bestimmten ORTH Feldern assoziert werden müssen?

3. Welche Attribute gibt es bei dem SENSE Eintrag? hier sind nur "usage" und "domain" anwesend. Wie flexibel muss das sein? Kann ein Eintrag auch direkt mehrere Attribute haben?


Im Moment wäre mein Ansatz eher so:
Man konzentriert sich auf die Werte, die man wirklich braucht, und zwar so wie wir (also Wadoku Instanz) sie brauchen. Man modelliert sich seine Welt, für die Datenbank und schreibt dann verschiedene Transformmechanismen wie man die Daten hinterher rausgeben möchte (TEI, edict, edict xml, ander Binäre Formate etc.).

Es scheint für mich im Moment zwei Vorteile zu haben:

1. Man kann so etwas in mehren kleinen Schritten durchführen (Schemaevulotionsbasiert) und muss nicht alle Daten auf einen Schlag in ein Komplett anderes Format transformieren, mit dem wenig Erfahrung existiert.

2. Man ist sehr flexibel was die spätere Ausgabe anbetrifft.

Mein größter Kritikpunkt am TEI ist:
Wenn man schon anfangen muss, das TEI zu erweitern, dann bewegt man sich wieder vom TEI weg. Es scheint dann also als ob das TEI nicht flexibel genug ist, die Anforderungen direkt zu erfüllen. Ergo kann man auch etwas eigenes machen und versuchen die Probleme die beim TEI auftreten, gar nicht erst auftreten zu lassen, bzw. erst dann zu lösen wenn man die Daten als Paket herausgeben möchte.

Leibe Community und Betreiber,

ich stimme vielen Argumenten bzgl. der Qualität zu.

Ich nehme jetzt mal einfach an, dass die ganzen Wörterbucheinträge nicht mehr in einem proprietären Dictionary-Format vorliegen (wie z.B. dieses EPWING, obwohl es die Spezifikationen öffentlich zugänglich gibt) sondern mittlerweile in einem Datenbankmanagementsystem in Form einer Datenbank gespeichert sind. Es wäre ein leichtes Qualitätsbedenken und den Communitywunsch nach Aktualität zu befriedigen.

Zur Qualität:
a. Gremium Ansatz:
Man könnte das Schema derart erweitern, dass es ein Final oder QC Wert für jeden Eintrag enthält. Entweder kann man jetzt verhindern, wenn jemand (mit der dazugehörigen Berechtigung und Kompetenz) den Eintrag als Final markiert hat, dass man ihn weiter verändern kann. Oder wenn man ihn ändert wird der alte Eintrag konseviert und der neue als "dirty" markiert.

b. Community Ansatz:
Andernfalls könnte man auch mit einer gewissen Qualitatspunkte Schranke arbeiten. Wo jeder den Eintrag bewerten kann der ihn abgefragt hat.

Jedes Jahr kann dann ein qualitätsgeprüftes Wörterbuch (in verschiedenen Formaten) ausgegeben werden. Also z.B. alle als Final markierten Einträge oder alle mit einem gewissen Qualitätswert.

Zum Downloadwunsch:
Jedes DBMS bietet mittlerweile die Möglichkeit einen "Dump" anzufertigen, allen voran die freien wie MySQL, PostgreSQL, etc. wo dies sogar als Backupmittel dient. Aber auch die kommerziellen wie Oracle oder IBM DB2 bieten sogar verschiedenste Möglichkeiten daten zu exportieren. Nun kann man einmal in der woche (im Monat?) automatisch einen Dump erstellen lassen und ihn zur Verfügung stellen. Diese Dumps sind dann natürlich nur auf eigene Gefahr.

Das einzige was mir als Gegenargument im Moment einfällt sind die mitunter hohen Traffic-Kosten, die entstehen könnten.

Sollte die nötige Datenbankexpertise fehlen (obwohl ich das eigentlich nicht glaube) biete ich an, an so einem Projekt mitzuarbeiten.