Die IT-affinen unter Euch wissen, was git ist. Für alle Anderen gaanz kurz: Es ist ein Versionsverwaltungssystem, mit dem Änderungen in Texten nachvollzogen werden könne. Man kann einen alten Zustand eines oder mehrerer Text wiederherstellen. Man kann einen Zustand “einfrieren” und als Version herausgeben (zu “versionieren“)- so kann man sich auch später wieder auf diese Version berufen. Programmcode ist Text und für Entwicklungsarbeit an “Code” ist git eigentlich gedacht, denn es ermöglicht auch im Team zu entwickeln. Genauso gut ist es auch möglich andere Textdokumente und -sammlungen damit zu versionieren.
Nach dem Vorgeplänkel …
Vor einiger Zeit, so wurde mir erzählt, wohnte ein(e) BioinformatikerIn einer Einführung für ProfessorInnen und ArbeitsgruppenleiterInnen zum wissenschaftlichen Datenmanagement bei. Nach dem git-Teil (dem noch weitere Werkzeuge folgen sollten), fragte die Person, ob man Excel-Sheets auch mit git versionieren und verwalten kann.
Kann man prinzipiell schon, aber git wird nur erkennen ob eine Excel-Datei verändert wurde – nicht aber die Änderungen nachverfolgen und transparent machen können.
Es ist also klar, dass hier
- nicht verstanden wurde wofür git gut ist – für InformatikerInnen, gleich welcher Art, sehr ungewöhnlich
- offensichtlich ebenfalls unklar war wie eine Excel-Datei gespeichert wird (nämlich in einem nur teilweise offenem Format mit binären Resten – erinnert sich noch jemand an den Streit um die Einführung des Formats?) Klar kann man, ähnlich wie bei odt, entpacken und die resultierende XML-Datei zu großen Teilen gut versionieren – aber eben nur in großen Teilen, wobei der binäre Anteil vom Inhalt abhängen wird.
Offengestanden sehe ich in dieser Kombination schwarz für die Ausbildung von Studierenden. Na ja, solche Fehler können wir alle machen, aber …
Halt, zu schnell gedacht!
Doch ich habe in meiner Sommerpause gelernt, dass ich Blöd-Blogger™ mit meiner Forderung nach besserer Software als Excel zur Datenverwaltung in der Bioinformatik oder gar der Forderung nach sorgfältiger Wahl der Softwarewerkzeuge oder sogar nach Projektplanung, die diese Dinge berücksichtigt, nicht mehr satisfaktionsfähig bin: Mittlerweile wurde nämlich die Nomenklatur der Gene den Defaults von Excel angepasst[Brudford et al., 2020].
Stimmt nicht ganz, denn daneben werden noch andere Gründe aufgezählt (Hervorhebung durch mich):
- Adoption of a more appropriate or commonly used alias. For example, RNASEN was updated to DROSHA(drosha ribonuclease III) because of overwhelming community usage.
- Domain- or motif-based nomencla-ture. For example, TMEM206 (trans-membrane protein 206) is now PAC C1(proton activated chloride channel 1).
- Phenotype- or disease-based nomenclature. For example, CASC4(cancer susceptibility candidate 4) was renamed GOLM2 (golgi membrane protein 2), removing reference to the phenotype and making it consistent with its paralog GOLM1.
- Location-based nomenclature. For example, TWISTNB (TWIST neigh-bor) is now POLR1F (RNA polymerase I subunit F).
- Pejorative symbols. For example, DOPEY1 was renamed to DOP1A (DOP1 leucine zipper like protein A).
- Misleading or incorrect nomencla-ture. For example, OTX3 was initially erroneously named as an OTX fam-ily member and has been renamed DMBX1 (diencephalon/mesencepha-lon homeobox 1).
- Symbols that affect data handling and retrieval. For example, all symbols that autoconverted to dates in Microsoft Excel have been changed (for example, SEPT1 is now SEPTIN1; MARCH1 is now MARCHF1); tRNA synthetase symbols that were also common words have been changed (for example, WARS is now WARS1; CARS is now CARS1).
Da sind – fairerweise – viele gute Gründe. Außerdem bietet der EMBL-Blog eine gute Beschreibung des Hintergrundes. Insofern ist mein suggestiver Titel einzuschränken: Es gibt einen Einfluss von Microsoft Excel auf die Bioinformatik – aber den kann man schlecht quantifizieren. Andererseits ist befremdlich, dass Punkt 7 ohne Belege daherkommt – etwas überraschend aus dem Nichts.
Anders gesagt
Zwischen der Feststellung, dass der Einsatz einer in diesem Kontext unbrauchbaren Software zu Fehlern geführt hat[Ziemann et al., 2016] und dem Kotau gegenüber jener Software verstrichen ungefähr vier Jahre – persönliche Quellen sagen das NCBI schon vor sehr viel längerer Zeit auf derartige Probleme hingewiesen zu haben. Diese Zeit hat die Community eben nicht damit verbracht, darüber nachzudenken, wie man als Community besser arbeitet oder welche Standards man etablieren sollte, damit solche Fehler softwareseitig nicht vorkommen. Denn es ist klar, dass die manuelle Verwaltung (wohl gemeint mit “data handling” mit Excel) von Daten — auch wenn man einige Fehlerquellen wie das Umformatieren von Gen-Bezeichnungen durch Excel ausschaltet (in dem man die Bezeichnungen ändert) — weiterhin eine manuelle Verwaltung darstellt: Damit sind menschliche Fehler unausweichlich.
Wir müssen uns klar machen, dass die Funktionalität, die BioinformatikerInnen in Excel suchen
- selbstverständlich durch entsprechende Konfiguration fehlerfrei zu erreichen gewesen wäre – die Konventionsänderung erkennt an, dass Menschen an der Stelle Fehler machen werden
- auch mit freien Tabellenkalkulationsprogrammen erreicht werden kann
- oft im Wesentlichen in Übersicht und Aufbereitung sowie einfachen Vergleichsoperationen besteht.
Wegen des letzten Punktes vertrete ich die Auffassung, dass es sich um einen zentralen Teil der Datenanalytik handelt. Und den automatisiert man Besten. Automation verspricht Nachvollziehbarkeit – egal ob großskalig in einer Datenbank oder klein in einem dezidierten Skript, welches in einen workflow eingebaut wird. Skripte können außerdem gleich protokollieren, was sie tun. All das geht mit einem Tabellenkalkulationsprogramm nicht einfach so, weil ja niemand sehen kann, welche Schritte durchgeführt wurden, man sieht nur einen Ist-Zustand und vielleicht irgendwelche Gleichungen in Felder, die man anklickt. Selbstverständlich ist es möglich mit VBA vergleichbare Funktionalität zu erreichen, allerdings nur zum Preis eines Aufwands, der weit über den Einsatz von kleinen Skripten steht.
Damit erreicht man nicht im ersten Versuch fehlerfreie Datenverarbeitung – auch im Skript können Fehler sein. Doch wenn man das Skript versioniert und mit der wissenschaftlichen Veröffentlichung veröffentlicht (was nicht immer der Fall ist), dann können Fehler und die darauf beruhende Fehlinterpretation nachvollzogen und korrigiert werden. Wenn also Lehrende auf der Verwendung von Excel in ihren Arbeitsgruppen beharren (nichts gegen den gelegentlichen Einsatz von Excel oder anderen Tabellenkalkulationen – aber doch bitte nicht in automatisierbaren workflows), wo das eigene Feld schon längst bei big data angekommen ist, ist das ein Armutszeugnis. Umso mehr als zu der Lehre in der Bioinformatik die Fähigkeit einfache Skripte zu schreiben ein zentraler Bestandteil ist bzw. sein sollte.
Wie geht es weiter?
Ich habe mich entschieden meine kleine Serie umzuwidmen. Und knüpfte zwanglos an die Excel-Vorläuferbeiträge an. Es handelt sich bei Excel um ein fantastisches Programm (andere Tabellenkalkulationsprogramme sind auch nicht schlecht), dass aber in der wissenschaftlichen Datenverarbeitung nur sehr begrenzte Einsatzberechtigung hat und hier offenbar eine Quelle für Fehler war oder ist. Doch dabei soll es nicht bleiben.
Kommentare (12)