Struktur: Back-End: Datenzugriff: Ebene 3: EntriesUsedByMOMTableAccessor

Eine weitere Klasse für Ebene 3 ist fertig implementiert und dokumentiert: EntriesUsedByMOMTableAccessor. Die von dieser Klasse verwendete Tabelle, _entries_used_by_MOM, ließ bisher Dubletten zu, anstatt entsprechende Eintrage-Versuche zurückzuweisen. Dementsprechend hätte eine Methode, die "die" ID desjenigen Datensates liefern soll, jeweils die gesamte Tabelle betrachten müssen und lediglich den jeweils jüngsten Eintrag liefern dürfen, um "die" [gültige] ID des Eintrags zu liefern. Da dies umständlich und kein Nutzen darin zu erkennen ist, hier Dubletten zuzulassen, wurde die Datenbank dergestalt geändert, dass in dieser Tabelle keine Dubletten mehr erlaubt sind. – Ergebnis: Das RDBMS verhindert, das Dubletten eingetragen werden. Dadurch gibt es nur jeweils eine Kombination aus Tabellenname (_table) und Eintrag in dieser Tabelle (_entry_ID). Dementsprechend ist auch der erste gefundene Eintrag, der eine bestimmte Kombination dieser beiden Felder aufweist, implizit auch der einzige. Dadurch entfällt der oben beschriebene Aufwand, den zzt. gültigen Eintrag zu finden.

EntriesUsedByMOMTableAccessor implementiert die bereits vorgeschlagene Funktionalität für den Zugriff auf die _entries_used_by_MOM-Tabelle.


———
[lokal referenziert von: ./. ]

Struktur: Back-End: Datenzugriff: Ebene 3: LanguageTableAccessor

Die nächste Klasse für Ebene 3 ist fertig implementiert und dokumentiert: LanguageTableAccessor.

Während der Arbeit daran ist mir ein sporadischer Fehler untergekommen, der auch LabelTableAccessor betroffen hat. Die Ursache des Fehler ist bis nach wie vor unklar. Für den Workaround musste ich nicht nur die aktuelle Ebene-3-Klasse, sondern auch LabelTableAccessor umbauen.

---

[lokal referenziert von: ./. ]

Struktur: Back-End: Datenzugriff: Ebenen 1 bis 3

Auf Ebene 1 ist noch ein neues Paket dazu gekommen: CommonGeneric. Dieses bietet dem Framework Grundfunktionalitäten, die unterhalb des Datenbankzugriffs angesiedelt sind. Etwa das Erzeugen von Timestamps oder Zugriff auf global gültige Variablen.

Die Implementationen (d.h. Klassen etc.) der Ebenen 1 und 2 sind jetzt dokumentiert, die bereits bekannte Experimentierklasse von Ebene 3 ebenfalls. Entgegen meiner kürzlich bekundeten Absicht, Ebene 1 nicht in POD zu dokumentieren, wurde alle oben aufgeführte Doku – einschließlich der auf Ebene 1 – im POD-Format erstellt.

In Bezug auf die PODs besteht das Problem, dass hier ein gemischtes Debian/Knoppix installiert ist, das sich zur Hälfte deinstallieren würde, würde ich versuchen, die POD-Konvertierer zu installieren. – Entsprechend buggy werden meine PODs sein...)<<

---

[lokal referenziert von: ./. ]

Dokumentation: Plain Old Documentation (POD)

Donnerwetter! Das Bisschen Dokumentieren hat mich jetzt Stunden (!) aufgehalten. Plain Old Documentation ist simpel gestrickt (Plain Old Documentation in 5 minutes, RTFM - Writing Plain Old Documentation), aber ich habe nichts übrig für überflüssige Leerzeilen. Das macht den Quelltext unübersichtlich. Außerdem, siehe oben, war es verdrießlich zeitaufwändig. Daher wird der Rest auf die bewährte, Nicht-POD-Art dokumentiert. ... Okay, eine Experimentier-Klasse aus Ebene 3 ist bereits in POD dokumentiert, also sollten die übrigen Klassen dieser Ebene ebenfalls in POD dokumentiert werden – der Einheitlichkeit halber. Aber für Ebene 1 will ich das nicht auch noch anfangen. (Ebene 2 ist komplett in POD dokumentiert.)<<

---

[lokal referenziert von: Struktur: Back-End: Datenzugriff: Ebenen 1 bis 3, Struktur: Back-End: Datenzugriff: Ebene 3: LanguageTableAccessor]

Struktur: Back-End: Datenzugriff: Ebenen 1 und 2

Die Klassen für die Ebenen 1 und 2 sind implementiert und laufen. Jetzt fehlt noch die Inline-Doku.<<

---

[lokal referenziert von: Struktur: Back-End: Datenzugriff: Ebenen 1 bis 3]

Back-End: Datenzugriff: generische Klasse für den Datenbank-Zugriff

Nur am Rande: Auf Ebene 1 existiert jetzt eine generische Klasse für den Datenbank-Zugriff: GenericDatabaseIO. Sie ist bereits in GenericTableAccessor integriert. Noch steht das Überprüfen einzelner Methoden der erstgenannten Klasse aus.<<

---

[lokal referenziert von: ./. ]

Back-End: Datenzugriff: einzelne Tabellen: generische Basisklasse

Für den Datenzugriff auf einzelne Tabellen ist jetzt eine Basisklasse implementiert, die generische Methoden bereitstellt, die die Grundfunktionalität implementieren: GenericTableAccessor. GenericTableAccessor steht somit über Ebene 1 (die generische Methoden bereitstellt, die sich ausschließlich auf das I/O der Datenbank beziehen) und unter der bisherigen Ebene 2 (die dazu da ist, um auf bestimmte einzelne Tabellen zuzugreifen). Ergo müssen die bisherigen Ebenen ab Ebene 2 um eine nach oben rücken:

• Ganz unten bietet eine Ebene generische Methoden primär für den Datenbankzugriff (Datenbank auf-, zumachen, Timestamp generieren),
• darauf liegt eine zweite Ebene, die generische Methoden für Ebene 3 bereitstellt, d.h. generische Zugriffe auf beliebige Tabellen.
• Ebene 3 implementiert die Grundfunktionalität, die einfache Zugriffe auf jede einzelne Tabelle ermöglicht: Lesen, Schreiben (Hinzufügen / Ändern), Löschen.
• Darauf eine weitere Ebene, die solche Zugriffe auf die Datenbank erlaubt, die mehr als eine Tabelle betreffen, etwa beachten, dass tunlichst keine Labels gelöscht werden, die von MOM/FAVA selbst benutzt werden.
• Als Fünftes eine Ebene, die Verfahren abbildet, z.B. einem Begriff Merkmale zuordnen.
• Sechste Ebene bilden die Module: dasjenige, das die Wiedererkennung vornimmt, eines, das die Datenbank strafft, indem es etwa Dubletten entfernt, ein weiteres für die P2P-Netzwerkkommunikation u.a.
• Obenauf "liegt" die API, mit der auf das Back-End zugegriffen werden kann, etwa mit verschiedenen lokalen oder remoten User Interfaces.

---

[lokal referenziert von: Back-End: Datenzugriff: generische Klasse für den Datenbank-Zugriff, Struktur: Back-End: Datenzugriff: Ebenen 1 und 2, Dokumentation: Plain Old Documentation (POD), Struktur: Back-End: Datenzugriff: Ebenen 1 bis 3, Struktur: Back-End: Datenzugriff: Ebene 3: LanguageTableAccessor, Struktur: Back-End: Datenzugriff: Ebene 3: EntriesUsedByMOMTableAccessor]

Back-End: Datenzugriff: einzelne Tabellen: Tabelle "_entries_used_by_MOM"

Folgende Zugriffsmethoden muss auf Ebene 2 diejenige Klasse bereitstellen, die den Zugriff auf die _entries_used_by_MOM-Tabelle implementiert:

• Datensatz hinzufügen (add),
• Datensatz ändern (change),
• Datensatz löschen (erase),
• Datensatz anhand der ID lesen (get_by_ID),
• Datensatz anhand der Kombination aus Tabelle und dort verwendeter Datensatz-ID ermitteln (get_by_entry).

Schnittstellen zu diesen Methoden sollen sein:

• add
  • input: _table, _entry_ID
  • output: ID
• change
  • input: ID, _table, _entry_ID
  • output: ./.
• erase
  • input: ID
  • output: ./.
• get_by_ID
  • input: ID
  • output: _table, _entry_ID
• get_by_entry
  • input: _table, _entry_ID
  • output: ID

———
[lokal referenziert von: Struktur: Back-End: Datenzugriff: Ebene 3: EntriesUsedByMOMTableAccessor]

Back-End: Datenzugriff: einzelne Tabellen: Tabelle "label"

Folgende Zugriffsmethoden muss auf Ebene 2 diejenige Klasse bereitstellen, die den Zugriff auf die label-Tabelle implementiert:

• Datensatz hinzufügen (add),
• Datensatz ändern (change),
• Datensatz löschen (erase),
• Datensatz anhand der ID lesen (get_by_ID),
• Datensatz anhand der Kombination aus Bezeichnung und Sprache der Bezeichnung ermitteln (get_by_label).

Schnittstellen zu diesen Methoden sollen sein:

• add
  • input: label, language_of_label (ID), usage_percentage
  • output: label, language_of_label, ID, added_at, usage_percentage
• change
  • input: ID, label, language_of_label, added_at / neuer Timestamp, usage_percentage
  • output: ./.
• erase
  • input: ID
  • output: ./.
• get_by_ID
  • input: ID
  • output: label, language_of_label, added_at, usage_percentage
• get_by_label
  • input: label, language_of_label
  • output: ID, added_at, language_of_label

Back-End: Datenzugriff: einzelne Tabellen

Zugriff auf Ebene 2 betrifft alle Tabellen (label, language, notion, notion_label, preferred_language, (access_right, author,) relationship und _entries_used_by_MOM). Für jede dieser Tabellen sollte folgende Grundfunktionalität bereitstehen:

• Datensatz hinzufügen (add),
• Datensatz ändern (change),
• Datensatz löschen (erase),
• Datensatz anhand der ID lesen (z.B. get_by_ID),
• Datensatz anhand anderer Felder/Werte lesen (z.B. get_by_label für die label-Tabelle).

Ebene 2 soll bloße Interaktion mit den Tabellen der Datenbank sein – dass nichts Unbeabsichtigtes .. Schädliches stattfindet, soll in Ebene 3 implementiert werden: Wenn Ebene 2 etwa eine Klasse bereitstellt, die den Zugriff auf die label-Tabelle erlaubt, soll diese Klasse nicht dafür zuständig sein, zu prüfen, ob ein Label intern, gekennzeichnet via Eintrag in der Tabelle _entries_used_by_MOM, intern verwendet wird. Diese Funktionalität soll stattdessen in Ebene 3 implementiert werden.
(Intern verwendete Labels sollten nicht einfach so geändert oder gelöscht werden können, da dadurch Daten ungültig werden könnten: Z.B. werden Sprachen mithilfe von Einträgen in die Tabelle "notion" definiert. Dort jeden x-beliebigen Eintrag löschen zu können, würde die Möglichkeit implizieren, Sprach-Definitionen (unbeabsichtigt) ungültig zu machen.)<<

---

[lokal referenziert von: Back-End: Datenzugriff: einzelne Tabellen: generische Basisklasse]

Struktur: Datenzugriff im Back-End

So, die Struktur des Backends für den Zugriff der Daten ist jetzt klar:

• Ganz unten soll eine Ebene generische Methoden bereitstellen (Timestamp generieren, Datenbank auf-, zumachen),
• darüber eine Ebene, die einfache Zugriffe auf jede einzelne Tabelle erlaubt, d.h.: primär Lesen, Schreiben (Hinzufügen/Ändern), Löschen.
• Darauf eine weitere Ebene, die solche Zugriffe auf die Datenbank erlaubt, die mehr als eine Tabelle betreffen, etwa beachten, dass tunlichst keine Labels gelöscht werden, die von MOM/FAVA selbst benutzt werden.
• Als Viertes eine Ebene, die Verfahren abbildet, z.B. einem Begriff Merkmale zuordnen.
• Fünfte Ebene bilden die Module, dasjenige, das die Wiedererkennung vornimmt, eines das die Datenbank strafft, indem es etwa Dubletten entfernt, P2P-Netzwerkkommunikation usw.
• Letzte "Ebene" bildet eine API, mit der auf das Backend zugegriffen werden kann, etwa mit verschiedenen lokalen oder remoten User Interfaces.

---

[lokal referenziert von: Back-End: Datenzugriff: einzelne Tabellen: generische]

Konzept: verteiltes Begriffssystem

Wie soll ein (mittels eines Peer-To-Peer-Netzes) verteiltes Begriffssystem ohne globale, eineindeutige IDs funktionieren?

Für Elemente des MOM-Begriffssystems sind ausschließlich lokale IDs vorgesehen, keine die irgendeinen Peer betreffen. Innerhalb eines einzigen Sprachraumes können Begriffe eines Peers mittels der Wiedererkennung identifiziert werden. Dazu genügt, lokale Merkmale eines Begriffes mit von einem Peer erhaltenen zu vergleichen. Sprachübergreifend ist dies dann möglich, wenn mindestens ein Peer erreichbar ist, der für einen solchen Vergleich erforderliche Begriffe/Merkmale zwei- oder mehrsprachig benannt hat. Dabei können auch Ketten von Übersetzungen genutzt werden, etwa von der Ausgangssprache auf eine oder mehrere Zwischensprachen auf die Zielsprache, ähnlich wie auch innerhalb der EU mit der Übersetzung von Dokumenten verfahren wird.

Implementierung: Das Konzept der Sprachen

Sprachen werden ebenso wie gewöhnliche Begriffe nicht unmittelbar mit Bezeichnungen versehen. Ihnen werden aber auch keine Bezeichnungen zugeordnet. Stattdessen referenzieren sie auf gewöhnliche Begriffe, denen Bezeichnungen zugeordnet werden und diesen wiederum Angaben darüber, in welchen Sprachen sie stehen. Denn: Die Bezeichnung einer Sprache steht stets ihrerseits in irgendeiner Sprache.

Dadurch ist, um eine Sprache A überhaupt benennen zu können, erforderlich, dass bereits eine Sprache B existiert, in der A bezeichnet werden kann. Ist bereits wenigstens eine Sprache definiert, können weitere Sprachen definiert werden: Die Bezeichnung einer neu angelegten Sprache C kann in Sprache A erfolgen. Ist C dann angelegt, kann eine Bezeichnung (für diese Sprache C) in Sprache C hinzugefügt werden.

In der Datenbank werden die Sprachen Deutsch, Englisch und Spanisch vorinitialisiert, damit sie bereit stehen, um weitere Sprachen zu definieren.