Architektur

Die Architektur des Upload-Tools folgt dem aus dem Software-Engineeringbekannten Ar-chitekturmuster des Model-View-Controllers (MVC). Ziel dieses Musters ist es, das Pro-gramm in drei Einheiten zu teilen: das Datenmodell (engl. model), das die Daten und meistens die Anwendungslogik enth¨alt, die Pr¨asentation (engl. view), d.h die Darstellung eines bestimmten Modells, auf der die Interaktion mit dem Benutzer stattfindet, und die Programmsteuerung (engl. controller), die die Benutzeraktionen entgegennimmt und ent-sprechende ¨Anderungen des zugeh¨origen Datenmodells umsetzt.

Im Fall des Upload-Tools ist dieses Muster im Rahmen einer webbasierten Client-Server-Architektur umgesetzt, wodurch ein Szenario erm¨oglicht wird, in dem mehrere Ontologie-entwickler verteilt an einem EFGT-Netz arbeiten. Abbildung 3.13 zeigt eine schematische Darstellung dieser Architektur.

Am Anfang der Benutzerinteraktion mit dem Upload-Tool wird das Programm ser-verseitig von einem Java-Servlet gesteuert, das die Sitzungen der verschiedenen Clients verwaltet. Es nimmt die vom Benutzer mittels des Formulars ¨ubertragenen Daten entge-gen und baut eine neue Sitzung auf. Aus dem ¨ubertragenen Eintraggschema und den Daten wird zun¨achst das zugeh¨orige Datenmodell aufgebaut, das ebenfalls in Java implementiert ist und im Server residiert. Das Datenmodell besteht aus folgenden Teilen:

• Das kompilierteTemplate, ein komplexes Objekt, das aus dem angegebenen

Eintrags-3.4 Die Implementierung: Das Upload-Tool 85 schema vom sogenanntenInterpreteraufgebaut wird. Das kompilierte Template stellt eine Art Zusammenstellung abstrakter Eintr¨age dar: Durch deren Auswertung und Belegung mit Daten entstehen dann generierte, konkrete Eintr¨age, die als einzelne Objekte der KlasseConcept implementiert sind.

• Die Originaldaten werden intern als Objekte repr¨asentiert, die f¨ur jedes Format von entsprechenden Parsern aufgebaut werden. Dabei werden Tabellen und als typisier-te Felder kodiertypisier-te Datypisier-ten als Objektypisier-te einer selbst entwickeltypisier-ten Klasse (DataLines) repr¨asentiert. XML-Daten werden intern als DOM-Datenstruktur gehalten, was mit Hilfe der Java-Bibliothek JDOM erfolgt. Den Klassen, die die Originaldaten halten, werden die im Template definierten Variablen ¨ubergeben, worauf die entsprechenden Variablenbelegungen aus der internen Datenstruktur extrahiert werden. Das Templa-te wird dann auf Anforderung mit diesen Belegungen instanziiert.

• Der Eintragsspeicher stellt den erweiterten Eintragsraum aus Abschnitt 3.3.2 be-reit, der die f¨ur die Alinierung n¨otigen Daten enth¨alt. Im Eintragsspeicher werden alle generierten Eintr¨age gehalten sowie alle im EFGT-Netz bestehenden Eintr¨age, die f¨ur den Abgleich relevant sind. Eine performante Alinierung wird dadurch un-terst¨utzt, dass spezielle Indexstrukturen aufgebaut werden (s.u.). Der Eintragsspei-cher ist zun¨achst leer und f¨ullt sich im Laufe der Auswertung des Templates auf.

• Einzelne Objekte einer speziellen Klasse repr¨asentieren die Alinierungsergebnisse, d.h. die Ergebnisse der jeweiligen Instanziierungen des Templates. Ein solches Ob-jekt fasst die Variablenbelegung, mit der das Template instanziiert worden ist, sowie resultierende Eintr¨age oder Warnungen zusammen und dient als Grundlage f¨ur die Darstellung dieser Ergebnisse im Client.

Die Semantik der in Abschnitt 3.3 entwickelten Integrationssprache wird durch die im Datenmodell enthaltenen Objekte und ihr Verhalten abgedeckt. Dies bedeutet, dass die Anforderungen an die Anwendungslogik (s. S. 63) im Datenmodell realisiert sind.

Sind einmal die vom Benutzer ¨ubertragenen Daten geparst und das Datenmodell ins-gesamt aufgebaut, so wird die Pr¨asentation der Daten als HTML-Seite generiert und an den Client zur¨uckgeschickt. In dieser Darstellung, in der sowohl die Daten als auch das Eintragsschema repr¨asentiert und manipulierbar sind, kann der Benutzer diverse Aktio-nen ausf¨uhren. W¨ahrend der Sitzung befindet sich das Steuerungsmodul f¨ur die Interak-tion mit dem Datenmodell im Client und ist Javascript (JS) implementiert. Der Zugriff

¨

uber JS auf die Java-Objekte des Datenmodells im Server erfolgt mit Hilfe einer speziel-len AJAX Bibliothek f¨ur Java mit dem Namen Direct Web Remotig (vgl. DWR, 2008).

DWR stellt einen Remote Procedure Call-Mechanismus (RPC) bereit, mit dem im Sinne des AJAX-Paradigmas asynchrone Requests des Clients an den Server abgesetzt werden k¨onnen: DWR erzeugt automatisch f¨ur einzelne Methoden einer Java-Klasse korrespondie-rende JS-Funktionen, die im Client aufgerufen werden k¨onnen. Ein spezielles Servlet nimmt von diesen JS-Funktionen gesendete Requests entgegen, ruft die passenden Methoden der

3.4 Die Implementierung: Das Upload-Tool 86

Abbildung 3.13: Schematische Darstellung der Architektur des Upload-Tools. Dargestellt sind die Komponenten, die w¨ahrend einer Sitzung aktiv sind.

entsprechenden Java-Objekte aus und gibt die R¨uckgabewerte zur¨uck an den Client, der sie in die Darstellung einbindet.

Die Funktionalit¨at und die Darstellung des Datenmodells im Client werden separat in Abschnitt 3.4.4 (s. S. 90 ff) beschrieben, da im Client die Interaktion mit dem Ontolo-gieentwickler stattfindet und dort den Anforderungen bez¨uglich effizienter Steuerung und Uberwachung nachgekommen werden muss.¨

Im Datenmodell sind besonders wichtige Komponenten der Interpreter und der Kon-zeptspeicher, da sie einen Großteil der Anwendungslogik zur Generierung und Alinierung von Eintr¨agen bereitstellen.

Der Interpreter

Der Interpreter wurde mit Hilfe des Java Compiler Generators JavaCC implementiert und ist daf¨ur zust¨andig, das kompilierte, instanziierbare Template aufzubauen. Die vom Inter-preter verstandene Sprache f¨ur Eintragsschemata weicht von der in Abschnitt 3.3 verwende-ten, abstrakten Syntax ab. Das gilt auch f¨ur die Darstellungen der Tabellen und typisierten Felder. Die konkrete Syntax, mit der Schemata und Daten zusammen in einem sogenannte Upload-Fileangegeben werden k¨onnen, wird in Abschnitt 3.4.3 (s. S. 88 ff) beschrieben. Die Parser f¨ur Tabellen und typisierte Felder basieren auf regul¨aren Ausdr¨ucken, wof¨ur auf die

3.4 Die Implementierung: Das Upload-Tool 87 entsprechende native Java-Bibliothek zur¨uckgegriffen wurde. Zum Parsen von XML-Daten wird die bereits erw¨ahnte Bibliothek JDOM eingesetzt. Diese stellt ebenfalls eine Imple-mentierung von XPath bereit, die im Auswertungsmechanismus f¨ur die XML-spezifischen Verweise (vgl. S. 81 ff) genutzt wird.

Rolle des Eintragsspeichers bei der Alinierung

Die Alinierung der generierten Eintr¨age mit dem EFGT-Netz erfolgt auf der Grundlage des Inhalts des Konzeptspeichers. Hierf¨ur werden alle in derselben Sitzung generierten Eintr¨age dieser Komponente hinzugef¨ugt. Ebenfalls werden alle beim Abgleich relevanten Eintr¨age aus dem EFGT-Netz geholt und im Speicher gehalten. Der Grund daf¨ur ist, dass spezielle Indexstrukturen aufgebaut werden, um einen schnellen Zugriff auf die logische und die Attributrepr¨asentation aller im Speicher enthaltenen Eintr¨age zu erm¨oglichen. Da die zu generierenden Eintr¨age auf bestehenden aufbauen, wird ¨ublicherweise innerhalb einer Sitzung mehrmals auf diese verwiesen. Durch die Aufnahme in den Eintragsspeicher und die dazugeh¨origen Indexstrukturen wird der Zugriff auf bestehende Eintr¨age optimiert.

Der Eintragsspeicher ist die einzige Komponente, die mit der Wissensressource kom-muniziert. Dies erfolgt ¨uber das vorhandene EFGT-Netz-Interface in seiner XML-Variante (s. Abschnitt 2.1.3, S. 40). Das bedeutet, das die n¨otige Information zur Auswertung des erweiterten ID-Strings im Template ebenfalls vom Konzeptspeicher bereitgestellt wird. Zur Ermittlung von Werten f¨ur die generischen Indizes im Template wird intern ein zus¨atzlicher Index von Teil-ID-Strings aufgebaut, die lokale Einf¨uhrungen darstellen (s. S. 70 in Ab-schnittSemantik von EFGT-Netz-Eintragsschemata). Die Auswertung von Query-Kompo-nenten erfolgt mit Hilfe der internen Indexstrukturen und einer Implementierung der Funk-tionlingSim(s. ebd.), die im Grunde linguistische Angaben bzgl. der Groß-Kleinschreibung, den Trennern, usw. normalisiert. Dieselbe Funktion wird beim Abgleich der als Attribute kodierten linguistischen Repr¨asentation der Konzepte verwendet.

Da im Moment f¨ur jede Sitzung ein eigener Konzeptspeicher aufgebaut wird, k¨onnen f¨ur den Benutzer unsichtbare Konflikte entstehen, wenn in mehreren parallelen Sitzungen mit ¨ahnlichen Daten gearbeitet wird. In der momentanen Implementierung wird diese Art von Konflikten erst beim Hochladen der best¨atigten Eintr¨age bemerkt, in diesem Fall wur-de also unn¨otige Arbeit in das ¨Uberpr¨ufen der Eintr¨age geleistet. Eine einfache L¨osung zu diesem Problem w¨are, Eintr¨age des Netzes f¨ur andere Sitzungen zu sperren, solange auf sie in einer laufenden Sitzung zugegriffen wird. Um die kollaborative Arbeit auf denselben Eintr¨agen zu erm¨oglichen, muss ein erweiterter Eintragsraum f¨ur alle parallel laufenden Sitzungen bereitgestellt werden. Dies w¨urde bedeuten, dass ¨Anderungen, die im Konzept-speicher durch eine bestimmte Sitzung hervorgerufen werden, an die anderen bestehen-den Sitzungen weitergegeben werbestehen-den m¨ussten und deren Alinierungsergebnisse betreffen k¨onnten. Dadurch w¨urde ein Observer-Architekturmuster umgesetzt, bei dem im Daten-modell auftretende ¨Anderungen automatisch an die Pr¨asentation weitergegeben w¨urden und zu deren Aktualisierung f¨uhren w¨urden. Wie bei Webanwendungen ¨ublich, ist dieses Muster im Upload-Tool nicht realisiert worden. Dies w¨are jedoch im Prinzip m¨oglich, da die hier verwendete Bibliothek DWR ebenfalls unterst¨utzt, dass Java-Objekte im Server

3.4 Die Implementierung: Das Upload-Tool 88 JS-Funktionen im Client aufrufen k¨onnen, womit auftretenden ¨Anderungen im Datenmo-dell an den Client weitergegeben werden k¨onnten. Nach den bisherigen Erfahrungen stellt jedoch die Verwendung eines separaten Eintragsspeichers f¨ur jede Sitzung keine signifikate Einschr¨ankung dar.