Digital resources in the Social Sciences and Humanities OpenEdition Our platforms OpenEdition Books OpenEdition Journals Hypotheses Calenda Libraries OpenEdition Freemium Follow us
Kategorien
Artikel

Nachvollziehbar experimentieren mit Tesla (I)

Hier bin ich am Ende darauf gekommen, welche vier Elemente von textprozessierenden Experimenten dokumentiert werden müssen, um ihren Aufbau zu definieren. Zur Erinnerung: Es handelte sich um

  • die Rohdaten (Texte)
  • den Code der prozessierenden Software-Einheiten (Komponenten)
  • die Feinabstimmung der Komponenten (Konfiguration)
  • das Zusammenspiel von Rohdaten und Komponenten (Interaktion)

Wie so vieles in der Datenwelt ist auch ein Tesla-Experiment letztlich eine XML-Datei. XML ist zwar grundsätzlich durch Menschen interpretierbar, allzu viel Spaß hat man damit aber nicht. Deshalb besitzt Tesla auch graphische Editoren, welche die Erstellung und Wartung von Experimenten weniger fehleranfällig und einfacher nutzbar machen. Die Editoren sind zusammengefasst im Client von Tesla, der als Plugin für die Plattform eclipse realisiert wurde. Der Client bietet verschiedene Funktionalitäten, eine Übersicht bietet z.B. dieses Tutorial. Eine dieser Funktionen ist die Zusammenstellung eines Experiments, das an den Server geschickt werden kann, damit dieser es ausführt und die Ergebnisse wiederum dem Client zur Verfügung stellt. Auch diese Ergebnisse haben eine XML-Repräsentation, die von unterschiedlichen Visualisieren des Clients interpretiert werden können. Die Kommunikation kann im Groben so dargestellt werden (links der Client, rechts der Server):

Austausch zwischen Tesla-Client und Tesla-Server
Austausch zwischen Tesla-Client und Tesla-Server

Es wäre nun möglich, alle vier oben erwähnten Elemente irgendwie in die XML-Repräsentation des Experiments zu packen. Dieser Zustand ist allerdings nicht gerade wünschenswert, da hierdurch eine extreme Redundanz bei der Datenspeicherung aufträte: Eine Kopie von Texten und Komponenten würde innerhalb jedes Experiments, das sie benutzt, gespeichert. Der Code der Komponenten (inkl. aller Bibliotheken, von denen er abhängt) müsste darüber hinaus jedesmal in XML serialisiert werden (um ihn vor der Ausführung wieder zu deserialisieren). Deshalb sollte es genügen, Texte und Komponentencode einmalig vorzuhalten und aus dem Experiment heraus eindeutig zu referenzieren. Nur die veränderlichen Elemente eines Experiments müssen komplett in seine XML-Repräsentation aufgenommen werden. Darunter fallen die Konfiguration im Großen (Interaktion der Komponenten) und die Konfiguration im Kleinen (Feineinstellung der einzelnen Komponenten). Den vier Elementen werde ich wohl jeweils einen eigenen Post gönnen müssen.