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

  1. nicht verstanden wurde wofür git gut ist – für InformatikerInnen, gleich welcher Art, sehr ungewöhnlich
  2. offensichtlich ebenfalls unklar war wie eine Excel-Datei gespeichert wird (nämlich in einem nur teilweise offenem Format mit binären Restenerinnert 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):

  1. Adoption of a more appropriate or commonly used alias. For example, RNASEN was updated to DROSHA(drosha ribonuclease III) because of overwhelming community usage.
  2. Domain- or motif-based nomencla-ture. For example, TMEM206 (trans-membrane protein 206) is now PAC C1(proton activated chloride channel 1).
  3. 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.
  4. Location-based nomenclature. For example, TWISTNB (TWIST neigh-bor) is now POLR1F (RNA polymerase I subunit F).
  5. Pejorative symbols. For example, DOPEY1 was renamed to DOP1A (DOP1 leucine zipper like protein A).
  6. 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).
  7. 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 zu 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

  1. selbstverständlich durch entsprechende Konfiguration fehlerfrei zu erreichen gewesen wäre – die Konventionsänderung erkennt an, dass Menschen an der Stelle Fehler machen werden
  2. auch mit freien Tabellenkalkulationsprogrammen erreicht werden kann
  3. 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.

flattr this!

Kommentare (12)

  1. #1 echt?
    3. September 2020

    Für Excel spricht erst mal, dass es das Teil schon sehr lange gibt und diversen Programmiersprachen bereits die Luft ausgegangen ist.

    • #2 Christian Meesters
      3. September 2020

      Menschen machen Fehler. Wir alle. Geklickte Fehler sind volatile Fehler. Geschriebene und veröffentlichte Fehler sind nachvollziehbare Fehler.

      Ich kann nicht erkennen, dass Python oder R zu kurz auf dem “Markt” sind oder der Anspruch an Leute die *Informatik als Berufsbezeichnung auf der Brust haben, ihre Fähigkeiten zu schärfen und diese nutzen, überzogen ist. 😉

  2. #3 echt?
    3. September 2020

    Nimm mal alte Software, z.B. in Fortran. Der Code mag noch laufen, aber die Ansteuerung der Grafikkarte oder des Druckers?

    • #4 Christian Meesters
      3. September 2020

      Ja, das ist ein Problem. Doch ein anderes.

      edit: Denke das muss ich klar stellen, denn offenbar war dies im Beitrag unklar: Für Irgendjemanden mag es ein Problem sein, dass alte Software nicht mehr lauffähig ist. Es kann auch zu einem wissenschaftlichen Problem werden – dazu habe ich auch noch einen Beitrag im Köcher. Hier geht es vor allem um die Reproduzierbarkeit wissenschaftlicher Arbeit. Und die ist nicht gegeben, wenn nicht nachvollziehbar ist, wieso die Protagonisten zu ihren Aussagen kommen.

      Laborbücher sind das A&O des wissenschaftlichen Arbeitens der “LaborbiologInnen” – genauso sehr ist es wichtig, dass auch BioinformatikerInnen ihre Arbeiten penibel protokollieren. Das ist technisch nicht möglich (sehr wohl manuell), wenn man in einer graphischen Benutzeroberfläche arbeitet, die nicht mit-protokolliert (es gibt Programme, die das tun) und also nach einer Zeit X niemand mehr weiß, was eigentlich gemacht wurde. Bei potentiell zehntausenden von Einträgen in einer Tabelle ist das ohnehin schwierig. Insofern ist es gut, dass die Community entscheidet, pot. Fehlerquellen auszuschalten. Es wäre besser zusätzlich auf geeignetere Software zu setzen.

  3. #5 jyou
    3. September 2020

    Also ich find das erstmal Klasse, dass es da tatsächlich einen Wissenschaft gibt, die Sachen, die wahrscheinlich aus historischen Gründen suboptimal sind korrigiert.

    Ich hab Elektrotechnik studiert und stoße mich heut noch an der technischen Stromrichtung (Sorry Freunde, aber die Elektronen fließen nun mal von Minus nach Plus). Aber dadurch muss man nicht die böse (linke) Hand für die Regel verwenden. 🙂

  4. #6 Kai
    4. September 2020

    “nicht verstanden wurde wofür git gut ist – für InformatikerInnen, gleich welcher Art, sehr ungewöhnlich”

    Das finde ich jetzt etwas hart. Die Frage ist meiner Meinung nach sehr berechtigt. Das Problem liegt hier eher am Datenformat. Ich selbst verwende für alles wann immer möglich tab-separierte CSV Dateien. Die kann auch jeder einlesen (nur Excel at damit Probleme, aber das Programm kann auch einfach nix).

    Aber generell ist es doch eine berechtigte (und intelligente) Frage, warum ein Versionsverwaltungssystem wie Git für Sourcecode optimiert ist, aber nicht für Datenformate wie XML, JSON etc.

    Ansonsten scheinen ja mehr und mehr Menschen mittlerweile auf Python oder R umzusteigen. Insbesondere mit den Jupyter Notebooks ist das eine sehr angenehme Alternative zu Excel.

    Den Einwurf von “echt?” in dem Zusammenhang kann ich auch nicht verstehen. Programmiersprachen sind jetzt echt nix was sich täglich ändert. Ganz im Gegenteil zu Excel/Word/Powerpoint, wo ständig neue Versionen rauskommen, die dann Probleme mit alten Daten haben. Das sich Programmbibliotheken immer mal ändern, ist dank heutiger Paketverwaltungssysteme auch nicht mehr ganz so schlimm. Im optimalen Fall verwendet man gleich sowas wie Docker o.ä. will man wirklich sicherstellen, dass die Software für lange Zeit reproduzierbar bleibt.

    • #7 Christian Meesters
      4. September 2020

      Ich selbst verwende für alles wann immer möglich tab-separierte CSV Dateien.

      Das ist zwar nur ein “Quasi-Standard”, doch ohne weiteres von allen gängigen Tools zu lesen und zu schreiben. Interfaces in pandas oder R sind vorhanden.

      Aber generell ist es doch eine berechtigte (und intelligente) Frage, warum ein Versionsverwaltungssystem wie Git für Sourcecode optimiert ist, aber nicht für Datenformate wie XML, JSON etc.

      Doch, git arbeitet ausschließlich mit “Text” – XML oder JSON stellen kein Problem dar, vorausgesetzt, man formatiert einheitlich so, dass Information zeilenweise gegeben ist (was ja zumindest bei XML i.d.R. der Fall ist).

    • #8 Christian Meesters
      6. September 2020

      Ich habe lange überlegt, ob ich das

      Das finde ich jetzt etwas hart. Die Frage ist meiner Meinung nach sehr berechtigt.

      kommentiere. Aber ich mit Blick auf einen anderen Thread möchte ich mal behaupten, dass PIs in der *Informatik manchmal nicht auf dem aktuellen Stand sind (wie in anderen Disziplinen auch), weil sie sich selber nicht mehr mit den Dingen beschäftigen. Im konkreten Fall könnte ich durch Links belegen, dass die fragliche Person ahnungslos ist, würde sie aber bloßstellen. Ich könnte das aber auch bei anderen Protagonisten machen, möchte aber keine pers. Angriffe fahren, sondern zur Reflektion darüber anregen, ob man, um eigenen Qualitätsansprüchen gerecht zu werden, nicht mal ein wenig(!) selber nachvollziehen sollte. Vielleicht lesen mit der Zeit diesen Blog diejenigen, die sich diesen Schuh anziehen könnten.

  5. #9 Kai
    4. September 2020

    ” vorausgesetzt, man formatiert einheitlich so, dass Information zeilenweise gegeben ist (was ja zumindest bei XML i.d.R. der Fall ist).”

    Eben genau das ist der Punkt 😉 Aber fairerweise muss man sagen, dass dies kein Problem von Git ist. Git schreibt ja nicht vor, welche Art der Kollisionsauflösung und Textvergleiche man vornimmt. Eventuell gibt es sogar git-plugins, die XML und JSON semantisch vergleichen?

    • #10 Christian Meesters
      4. September 2020

      Gibt es. Ich denke wir sind uns schnell einig, wenn ich behaupte: Für bestimmte Projekte sind derlei Plugins absolut sinnvoll. In wissenschaftlicher Arbeitsweise sollte die Verwaltung und Protokollierung der Arbeit nicht davon abhängen, dass jemand die Dinge immer richtig macht.

  6. #11 AndreDom
    12. September 2020

    Könnte man zum Beispiel Git ode randere Versionsverwaltungssoftware mit Webseiten verzahnen, Instanzen/Identitäten festlegen und Webseiten-Versionen selektiv anzeigen lassen?

    Das klingt jetzt wohl seltsam. Meint aber, das man Informationseinheiten von Webseiten selektiv neuornden und den anzuzeigenden Inhalt neu bestimmen kann. Sozusagen auf Knopfdurck oder eh automatisiert und dynamisch.

    Das ist eigendlich eine blöde Frage, die ich mir auch sogleich selbst beantworten kann: Ja. Es ist alles nur eine Frage des Aufwandes, inwieweit man Webseiteninhalte automatisch und dynamisch auf zielgesetze Anforderungen verändern kann. Rein strukturel ist die digitale Technologie dazu im Stande. Und hinreichende Systempflege und Entwicklung wird das Ergebnis auch immer aufwändiger und “intelligenter” verwirklichen können.

    Die “Kopie” der Welt und Kopien von den Kopien, die jeweils unterschiedliche Versionen darstellen, sind ja kein Problem mehr, seitdem Speicher keine Mangelwahre mehr ist und Vernetzung erfüllend gegeben ist.

    Was bedeutet, das ich als User einen sehr auf meine Identitäten-Kategorie abgestimmte Version der digitalen Informationen über die Wirklichkeit bekommen kann, ander Menschen aber eine völlig andere.

    Und das also als Plattformübergreifende Funktion. Jede Plattform braucht dazu nur eine kleine Subroutine, die bestimmte Datenfelder in eine Versions-Kategorie zuordnet, sodass meine “Spiegel.de” Homepage und Anzeige anders aussieht, als die version anderer User.

    Oder die Version von bestimmten Wikipedia-Einträgen, die sich je nach Kategorie der User bestimmbar zur Anzeige zuordnen liesse … wenn man das so wollte.

    Da bekommt “Desinformation” eine ganz andere Bedeutung und einen ganz anderen Einfluß auf die Welt und die Politik.

    • #12 Christian Meesters
      12. September 2020

      Bitte: Hier geht es um Reproduzierbarkeit in der Wissenschaft. Konkret um die Frage, ob eine bestimmte Software geeignet ist die zur Nachvollziehbarkeit wissenschaftlicher Ergebnisse notwendige Transparenz zu schaffen.

      Ihr Kommentar, AndreDom, enthält derart viele Aspekte, dass eine sinnvolle Diskussion diesem Thread sprengen würde.