Sicherlich ist Tesla nicht das einzige Softwaretool, das es ermöglicht, komplexe Experimente zusammenzustellen, zu konfigurieren, auszuführen und am Ende weiterzugeben, auf dass sie auf identische oder evtl. sogar modifizierte Weise ausgeführt werden können. Vielmehr sind vor allem in jüngerer Zeit eine Reihe von Tools entworfen worden, die genau dies ermöglichen sollen. Im Rahmen der britischen MyGrid-Initiative ist sogar eine Social-Network-Plattform entstanden (myExperiment), auf deren Basis Experimente, die innerhalb verschiedener Arbeitsumgebungen entworfen wurden, auf einfache Weise veröffentlicht und weitergegeben werden können. Für die nahe Zukunft streben wir auch an, dass Tesla als eine dieser Arbeitsumgebungen aufgenommen wird.
Dass wir mit der Entwicklung von Tesla (mit dessen konkreter Implementation wir irgendwann 2006 begonnen haben) auf dem richtigen Weg sind, wurde mir aber vor allem durch einen Beitrag von Ted Pederson in der Computational Linguistics (September 2008) klar. Da die Zeitschrift dankenswerterweise inzwischen den Open-Access-Pfad eingeschlagen hat, kann man den Artikel hier legal einsehen. Der Artikel ist betitelt mit “Empiricism Is Not a Matter of Faith” und führt auf sehr unterhaltsame Weise – durch die Parabel vom Zigglebottom-Tagger, einem Software-Werkzeug, das in einem Journalartikel gepriesen wird, in der Wirklichkeit aber nicht auf die angegebene Weise funktioniert – vor, dass Vertrauen in veröffentlichte Forschungsergebnisse zwar gut ist, Kontrolle aber besser wäre. Kontrolle von Software ist schlecht möglich, wenn man als Basis lediglich einen Journalartikel in Prosaform vorliegen hat. Notwendig ist vielmehr, dass die Software, über die geschrieben wurde, selbst in einer Form veröffentlicht wird, die ihre Benutzung durch die wissenschaftliche Community ermöglicht. Diese Form muss gewissen Ansprüchen genügen, so sollte die Funktionsweise und die Handhabung in einer Weise dokumentiert sein, mit der Außenstehende (also nicht-Mitentwickler) in die Lage versetzt werden, die Software zu überprüfen. Soweit Pedersen.
Soll nicht nur die Software, sondern auch die durch sie erlangten Ergebnisse kontrolliert werden, so ist außerdem eine Weitergabe der durch die Software prozessierten Ausgangsdaten notwendig. Besteht die Software nicht aus einem monolithischen Block, sondern aus mehreren, miteinander interagierenden autonomen Einheiten, dann müssen selbstverständlich alle Einheiten, als auch die Spezifikation ihrer Interaktion weitergegeben werden. Das führt uns wieder an den Schlussabsatz des letzten Posts, in dem von einer Verpackung für Experimente die Rede war. Eine solche Verpackung ist eigentlich nichts anderes, als eine eingefrorene Version des experimentellen Aufbaus, bestehend aus
- den Rohdaten
- dem Code der prozessierenden Software-Einheiten
- der Konfiguration der Software-Einheiten
- der Konfiguration ihrer Interaktion
Der Aufbau selbst wird auch als Workflow bezeichnet, insofern bedarf es einem Workflow-Management-Systems (WMS) zur Erzeugung und Verwaltung und Ausführung solcher Einheiten. Und – ihr werdet es erraten haben – Tesla enthält ein solches WMS, mit dem Experimente über textprozessierende Daten verwaltet werden können. Mehr dazu in Kürze.
OpenEdition schlägt Ihnen vor, diesen Beitrag wie folgt zu zitieren:
Jürgen Hermes (27. Oktober 2011). Empirismus, Vertrauen und Management. TEXperimenTales. Abgerufen am 3. Dezember 2024 von https://doi.org/10.58079/uq2q
Eine Antwort auf „Empirismus, Vertrauen und Management“
[…] Das erste zentrale Thema, an dem ich mich in meinen Posts abgearbeitet habe, ist die für die Wissenschaft zentrale Forderung nach einer Reproduzierbarkeit von Ergebnissen. Zunächst habe ich ein grundsätzliches Problem, das mit dieser Forderung einhergeht, in einer Art Parabel dargelegt (1). Im anschließenden Post bin ich darauf eingegangen, auf welche Weise es gelöst werden könnte (2). […]