ASDL:Datenbank
From Wiki
Endbericht des ASDL-Projekts
Inhaltsverzeichnis | Hauptseite des ASDL-Projekts
Contents |
Aufbau der DB
Die Interaktion des Reasoning-Agenten mit der Datenbank erfolgt über bereits implementierte Daffodil-Funktionen. Im folgenden nun eine beschreibung der Tabellen des ASDL-Projktes. Zur Übersicht dient nebenstehende Grafik - diese ist allerdings nicht als (korrektes) ER-Modell zu interpretieren! Auf Strukturen wie Fremdschlüssel (referentielle Integrität) wurde bei der konkreten Modellierung bewusst verzichtet. Das Modell ließe sich mit Sicherheit (besonders im Hinblick auf die Tabelle ASDL_Extractedterms) besser designen - allerdings ist das Design im Laufe des Projektes gewissermaßen gewachsen und spiegelt die Arbeitsweise des ASDL-Tools sehr gut wieder.
ASDL_Cases
Die Haupttabelle des ASDL-Projektes ist die Tabelle ASDL_Cases. Hier sind alle Cases (=Fälle) gespeichert. Der Vergleich des aktuellen Case, wo die adaptive Benutzerunterstützung stattfinden soll, mit den in der Datenbank hinterlegten Cases ergibt die ähnlichsten zum aktuellen Case. Diese ähnlichsten Fälle (besser die hinterlegten Suggestions (=Vorschläge) zu diesen Fällen) bilden die Grundlage für die Vorschläge die dem Benutzer gemacht werden. Erweist sich die gelieferte Suggestion als gut, wird der aktuelle Case mit seinen Parametern in die Tabelle Cases mit Verweis auf die gute Suggestion aufgenommen.
Felder:
- Case_ID: Fortlaufende eindeutige ID des Cases
- Hits: Zahl der gefundenen Dokumente
- Operators: Zahl der Operatoren in der Anfrage (alle vier Felder; AND und OR)
- QueryTermsAuthor: Verwendete Autoren in der Anfrage
- QueryTermsTitle: Verwendete Titel in der Anfrage
- QueryTermsFreeText: Verwendeter Freitext in der Anfrage
- QueryTermsYear: Verwendete Jahre in der Anfrage
- Answeringtime: Zeit bis zur Antwort (der letzten Digitalen Bib)
- DLList_ID: ID auf Fremdtabelle DLList
- Extractedterms_ID: ID auf Fremdtabelle Extractedterms
- Suggestion_ID: ID auf Fremdtabelle Suggestions
- Timestamp: Timestamp
ASDL_DLList
Die angefragten digitalen Bibliotheken und die Zahl der gelieferten Antworten wird in der Tabelle ASDL_DLList gespeichert.
Felder:
- DLList_ID: Schlüssel zur ASDL_Cases Tabelle
- DLName: Name der Digitalen Bibliothek
- Count: Zahl der gelieferten Antworten
ASDL_Extractedterms
Daffodil bietet Tools/Werkzeuge zur Unterstützung des Anwenders – durch diese Tools erzeugeten Informationen nutzt das ASDL-Tool auch um Vorschläge zu adaptieren. Die Schlüsseltabelle hierfür ist ASDL_Extractedterms – von hier wird jeweils in eine Untertabelle, wie z.B. ASDL_Terms für die extrahierten Terme, verwiesen. Die Arbeitsweise der Tools/Werkzeuge ist nicht Bestandteil dieses Endberichts - genauere Informationen gibt es in der DAFFODIL-Dokumentation.
Anmerkung: Bei ablsolut korrekter Arbeitsweise der Extraktionsklasse "TermExtractor" sollte für einen Case in dieser Tabelle immer gleiche IDs in einer Zeile gebildet werden.
Felder:
- Extractedterms_ID: Schlüssel zur ASDL_Cases Tabelle
- Terms_ID: Schlüssel zur ASDL_Terms Tabelle
- Authors_ID: Schlüssel zur ASDL_Authors Tabelle
- Conferences_ID: Schlüssel zur ASDL_Conferences Tabelle
- Journals_ID: Schlüssel zur ASDL_Journals Tabelle
Im folgenden nun die Tabellen, die die Ergebnisse aufnehmen. Werden mehrere Ergebnisse (z.B. mehrere Terme) geliefert, so wird jedes Ergbnis einzeln abgespeichert - allerdings haben alle die gleiche ID.
ASDL_Conferences
Hier werden die extrahierten Konferenzen gespeichert.
Felder:
- Conference_ID: Schlüssel zur ASDL_Extractedterms_Terms-Tabelle
- Conference: Name der Konferenz
- Count: Häufigkeit
ASDL_Authors
Hier werden die extrahierten Autoren gespeichert.
Felder:
- Author_ID: Schlüssel zur ASDL_Extractedterms_Terms-Tabelle
- Author: Name des Autoren
- Count: Häufigkeit
ASDL_Journals
Hier werden die extrahierten Journale gespeichert.
Felder:
- Journal_ID: Schlüssel zur ASDL_Extractedterms_Terms-Tabelle
- Journal: Name des Journals
- Count: Häufigkeit
ASDL_Terms
Hier werden die extrahierten Terme gespeichert.
Felder:
- Term_ID: Schlüssel zur ASDL_Extractedterms_Terms-Tabelle
- Term: Name des Terms
- Count: Häufigkeit
ASDL_Suggestion
Die ASDL_Suggestion enthält die Informationen über die eigentlichen Vorschläge in mehreren Sprachen. Eine englische Suggestion muss immer vorhanden sein.
Felder:
- Suggestion_ID: Schlüssel zur ASDL_Cases-Tabelle
- LANGUAGE: Sprache der Suggestion in Kurzform (de = Deutsch, en = Englisch, ...)
- TipText: Kurze Beschreibung des Vorschlages
- Explanation: Lange Beschreibung des Vorschlages. Das %-Zeichen wird bei einigen Suggestions durch z.B. den am häufigsten extrahierten Autoren ersetzt. Somit lassen sich auch die Suggestion-Texte ein wenig anpassen.
ASDL_SuggestionClass
Sind die Vorschläge ausführbar, so ist die jeweilige Klasse in der Tabelle ASDL_SuggestionClass hinterlegt.
Felder:
- Suggestion_ID: Schlüssel zur ASDL_Cases-Tabelle
- JavaClass: Verweis auf entsprechende Klasse, z.B. "de.unidue.daffodil.asdl.suggestions.BrowseConferencesSuggestion" (für Ausführbarkeit notwendig!)
Festgestelle Probleme
Die Datenbank MySQL 3.23 hat aus Sicht der Autoren einige Mängel:
- Neue Tabellen werden im Format „latin1_swedish_ci“ erstellt was einige Sonderzeichen von Daffodil unterstützten Sprachen ausschließt. Hier währe eine Umkonfiguration auf „utf8_unicode_ci“ zu überdenken. Dies wurde an den für das ASDL-Tool notwendigen Stellen (ASDL_Suggestion) gemacht.
- Strukturen wie Fremdschlüssel sind nicht möglich – damit auch kein „sauberes“ Datenbankdesign.
- Anfangs war keine benutzerfreundliche Applikation zur Administration von MySQL-Datenbanken verfügbar. Diese wurde durch PHP-MyAdmin nachgeliefert.
- Die Möglichkeiten von MySQL 3.23 sind aber mehr als ausreichend, um das ASDL zu realisieren. Funktionen, die die Datenbank nicht bietet, wurden im Programmcode emuliert.
Ein Update der Datenbanken könnte einigen Code überflüssig machen. So ist z.B. zu überprüfen, ob das Löschen von Cases (zur Zeit durch Hilfsfunktion realisiert) nicht besser durch einen Trigger (verfügbar ab MySQL 5.0) erfolgen könnte.
Generische Fälle
Beim Case-Based-Reasoning (CBR) ist eine gewisse Startdatenbasis notwendig. Gibt es keine früheren Cases (Fälle) und deren Lösung, kann der CBR-Zyklus nicht funktionieren. Daher musste auch unsere Lösung eine solche Startdatenbasis enthalten.
Das Problem hier ist die Datenbasis so zu gestallten, dass brauchbare – wenn nicht sogar gute Vorschläge zum aktuellen Problem generiert (oder hoch gewichtet) werden, ohne Kenntnis über den speziellen Suchhorizont zu haben. So ist es dem Leser wahrscheinlich klar, dass wenn er nach "Evolutionstheorie" sucht eine Eingrenzung des Autors auf "Charles Darwin" möglicherweise sinnvoll ist. Dies lässt sich natürlich auch in unserem System als Fall abbilden, nützt aber nicht viel, wenn nach "Elektromagnetismus" gesucht wird.
Dieses Teilproblem wurde druch die generischen Fälle gelöst. Die Informationen über Fälle sind in den Kontextdaten beschrieben. Im Rahmen dieser Überlegungen zerfallen die Kontextdaten in 3 Klassen:
- Kontroll-Daten
Eignen sich, um einen Fall auf Aussagefähigkeit zu untersuchen. Beispiel: Namen der angefragten Digitalen Bibliotheken.
- Allgemein-Daten
Eignen sich allgemein, um einen Vorschlag zu geben. Beispiel: Zahl der gesuchten Autoren.
- Spezielle Daten
Eignen sich „für den speziellen Fall“ um einen Vorschlag zu geben. Beispiel: Name eines Autors (in der Antwortmenge).
Für die Startdatenbasis sind (mit den bereits angestellten Überlegungen) nur Allgemein-Daten brauchbar. Nach einer analyse der Informationsgrundlage stellt man fest, dass Hits und Operatoren, sowie die Zahl der Autoren, Titel, Freitextwörter und Jahr sich für diesen allgemeinen Zweck eigneten. Alle anderen Informationen sind gewissermaßen „egal“. Mit diesen Überlegungen wurde das Ähnlichkeitsmaß so modifiziert, das es auch mit dem Parameter „egal“ umgehen konnte. Dann wurden generische Fälle passend zu den vorhandenen Empfehlungen formuliert. Diese wurden dann noch zu konkreten DDL-SQL Statements passend für die ASDL Tabellen umgewandelt.
Anmerkung: $ bedeutete für Textfelder, -1 für Zahlenfelder „egal“.
Die generischen Fälle sind so konzipiert, dass sie relativ niedrig gerankt werden. Sollte eine Anpassung notwendig sein, so ist sie an zentraler Stelle möglich. Mit diesem niedrigen Ranking sollten die generischen mit der Zeit von konkreten Fällen (durch Feedback der Benutzer auf generische oder konkrete Fälle - oder besser: deren Lösung) überdeckt werden. Sollte das nicht erfolgreich sein, sind im Anhang Skripte, die eine Manipulation der generischen Fälle recht einfach machen.
