Puh, ich weiß, über Excel in der Bioinformatik gab es hier schon einen Beitrag in dieser Serie. Und zuvor auch schon mal in anderem Kontext. Und jetzt, nach einer kleinen Blogpause, noch ein Artikel?
Ja, denn im Laborjournal, einer Zeitschrift, die im deutschsprachigen Raum in ziemlich vielen biochemisch arbeitenden Laboren gelesen wird, stand im letzten Jahr ein Kommentar zu Excel in der Bioinformatik. Und weil ein Laborjournalartikel bestimmt Beachtung finden wird, kann ich mir nicht verkneifen einen Teil zu unterstreichen und einen Teil zu kritisieren – in der Hoffnung, dass wenigstens ein paar in meiner Leserschaft bei ihrer nächsten Publikation von EXCEL oder anderen Klick-und-Paste-Programmen fernzuhalten und einen kleinen Beitrag zur wissenschaftlichen Reproduzierbarkiet / Nachvollziehbarkeit zu leisten. Und auch zur Rechtfertigung, wurde ich doch unlängst von Nutzern unserer Rechner darauf hingewiesen, dass es schade ist, keinen Service zu bieten, sodass die Ergebnisse in EXCEL geladen werden könnten.
Sehen wir davon ab, dass Tabellenkalkulationsprogramme wirklich super Werkzeuge sind und guten CSV-Import anbieten (und man eigentlich erwarten darf, dass Bioinformatiker in der Lage sein sollten im Netz zu suchen und eine Bibliothek zu verwenden, die das Ausschreiben in ihr favorisiertes Format direkt ermöglicht), klingt ja schon durch: Das ist nicht sinnvoll! Und warum es nicht sinnvoll ist, wird deutlich, wozu es – außer Gliederung und Präsentation von Daten – genutzt wird. Nämlich, um einfache Bezüge, Vergleiche und Rechnungen durchzuführen. Aber das ist doch genau das, wofür Tabellenkalkulationsprogramme da sind, oder?
Wer je eine komplexe Tabelle von Dritten erhalten hat, weiß, dass die Deutung mitunter schwierig sein kann und Weiterarbeit fehleranfällig. Das Laborjournal zitiert denn auch einen Fall, in dem eine Veröffentlichung zurückgezogen werden musste, weil Dinge durcheinander gerieten. Betroffen ist also nicht nur die längst nicht bewältigte automatische Re-Formattierung von Gen-Bezeichnungen, die Monat-für-Monat weiter für viele fehlerhafte Veröffentlichungen “sorgt” (wie auf dieser schönen Seite regelmäßig evaluiert wird). Denn das wäre traurig genug, immer mit dasselbe untaugliche Werkzeug zu nutzen.
Der Rat aus dem Laborjournal …
… ist auch meiner:
Die vielleicht beste Alternative, um große Datenmengen zu analysieren, bieten Skript-basierte Programmiersprachen für statistische Berechnungen und Grafiken wie Python (python.org) und R (r-project.org). Auch ohne lokale Installation lassen sie sich in Cloud-Oberflächen wie der Open-Source-App Jupyter Notebook nutzen (jupyter.org). Anfänglich sicher gewöhnungsbedürftig und aufwendig liegen ihre Vorzüge auf der Hand: Alle Nutzer wissen genau, was wie an welcher Stelle durch wen geschieht. Autokorrektur-Funktionen existieren nicht. Jeder Arbeitsablauf lässt sich auditieren. Selbst vorgefertigte Funktionen können begutachtet werden. Alle Software-Versionen sind dokumentiert und Modifikationen in einem Quellcode-Archiv hinterlegt.
Wobei regelmäßigen Besuchern des Blogs sicher aufgefallen ist, dass ich Jupyter-Notebooks nicht uneingeschränkt empfehle …
Wie auch immer, an einem Punkt muss ich deutlich widersprechen:
Diejenigen, die unmöglich auf Tabellenkalkulationen verzichten können, finden in den Open-Source-Programmen LibreOffice und Gnumeric vielleicht attraktive Alternativen. Im Gegensatz zu Microsoft Excel sind sie weniger anfällig für Autokorrektur-Fehler (PLoS Comput Biol., doi: 10.1371/journal.pcbi.1008984), ihre Automatikfunktionen können leicht abgeschaltet werden und sie sind kostenlos verfügbar.
Oft reicht es auch schon, Gen-Listen als simple Text-Dateien in csv-, tsv- oder txt-Formaten zu speichern. Formatierungsfehler macht das unmöglich. Darüber hinaus lassen sich Excel-Dateien mit Web-Tools wie Truke (maplab.imppc.org/truke) und Escape Excel (apostl.moffitt.org) auf Konvertierungsfehler überprüfen. Noch mehr Tipps zu Tabellenkalkulationen bietet der Biostatistiker Karl Broman von der University of Wisconsin-Madison auf seiner Homepage: kbroman.org/dataorg.
Ist doch klar, oder? Wenn ein Teil des Problems mit Tabellenkalkulationsprogramm Nr. 1 ist, dass man Bezüge und Rechnungen nicht immer mit dem Auge kontrollieren kann und automatisierte Kontrolle meist extrem schwer ist bzw. die Fähigkeiten der Anwenderbasis überfordernd ist, ist dann zu erwarten, mit Tabellenkalkulationsprogramm Nr. 2 eine nachhaltige Lösung des Problems zu erreichen? Oder läuft man nicht Gefahr, dieselben Fehler wieder zu machen und zu übersehen?
Aber halt! Da steht doch, es gibt Tools, die einem Sicherheit geben? Stehen ja im Artikel! Doch hier wird versucht, den Teufel mit dem Beelzebub auszutreiben. Die Stunde automatisch dokumentierender Workflows – inklusive des Erstellens publikationsreifer Abbildungen! – hat geschlagen, manuelles Herumfrickeln ist und bleibt fehleranfällig. Sich als ArbeitsgruppenleiterIn darauf zu verlassen, dass Menschen keine Fehler beim manuellen Pflegen von Daten machen ist fahrlässig.
Aber das ist doch so laaaangwierig und kompliziert!
Ok, ok. Die an dieser Stelle fällige Aufforderung ein wenig Skriptingfähigkeit draufzuschaffen bewirkt bei der “reinen” Experimentatorenfraktion häufig Abwehrreaktionen. Verständlich, sind diese komisch-kryptischen Codeschnipsel der Bioinformatiker doch abschreckend. Andererseits sind ein paar Tage mit einem einführenden Buch (freies Beispiel für pandas (einer Bibliothek für die Programmiersprache Python), freies Beispiel für R) sehr gut investierte Zeit für den Anfang einer wissenschaftlichen Karriere (falls es an eurer Uni keine entsprechenden Kurse geben sollte). Also, keine Angst vorm Skripten, lernt coden! Es ist immer wieder nützlich im wissenschaftlichen Alltag und wer es kann, hat nicht nur Vorteile im Publikationswettbewerb, sondern kann auch helfen verlässlichere Publiktionen “rauszuhauen”.
Behaupten kann man viel, aber wenn seit Jahr und Tag überall dasselbe geschrieben steht (nicht zu vergessen viele Videos, die auch ins selbe Horn pusten (Beipspiel)), kann man sich die Sache ja mal überlegen, oder?
Kommentare (17)