Eine kleine Geschichte der Bundesrepublik Deutschland

… Kleine Datengeschichten. Kleine Visualisierungsgeschichten. Kleine Forschungsgeschichten …

Von Patrick Sahle und Jana Klinger.

Hinter allem steckt eine Geschichte. Jedes Thema ist geeignet, um historische Zusammenhänge aufzuzeigen, denn alles hat eine historische Dimension. In unserem digitalen Informations-Ökosystem sind überall Informationen und Daten. Daraus lassen sich Geschichten erzählen. “Erzählen” ist aber nicht nur gesprochene oder geschriebene Sprache, sondern kann auch verschiedenste Visualisierungen meinen. Bilder und Diagramme zeigen Zusammenhänge und erzählen Geschichte(n). Es folgt ein willkürliches Beispiel.

Wikipedia ist eine Enzyklopädie für alles. Viele Dinge in der Welt haben einen Artikel. Ähnliche Dinge haben ähnlich strukturierte Artikel. Gruppen von Dingen haben Listen dieser Dinge. Das geht oft in eine erstaunliche Detailtiefe. So haben z.B. sogar einzelne Schiffe eigene Artikel in Wikipedia. Einzelne U-Boote auch. Viele U-Boote der Bundeswehr haben einen eigenen Artikel (Beispiel: U9 ). Hinzu kommen Artikel zu Bootsklassen (Beispiel: Klasse 201) und schließlich auch eine “Liste von Unterseebooten der Bundeswehr“. Das sind Informationssammlungen, aus denen sich vielleicht eine Geschichte erzählen lässt.

Im Sommersemester 2020 (dem ersten Corona-Semester) haben wir uns an der Bergischen Universität Wuppertal im Rahmen einer Übung “Informationsvisualisierung in den Geisteswissenschaften” mit der Frage beschäftigt, wie aus Daten Diagramme werden und wie bestehende Visualisierungen kritisch untersucht und eigene Schaubilder entwickelt werden können. Grundsätzlich sollte jede/r Teilnehmer/in ein eigenes Projekt verfolgen. Die Frage nach den U-Booten nach 1945 diente dabei als Fallbeispiel, als möglicher Ausgangs- und Anknüpfungspunkt für eigene Projekte und als Angebot zur Beteiligung für alle, denen partout nichts eigenes einfallen wollte.

Am Beispiel kann man gut die allgemeinen Prozesse von (ich greife jetzt mal hoch) “data science” und “information visualization” durchspielen. Denn natürlich wollten wir nicht einfach ein Diagramm “zeichnen”, sondern dies datengestützt und algorithmisch erzeugen. Es ist wichtig zu beachten, dass unser Szenario grundsätzlich darauf ausgerichtet ist, nicht einfach aus einem gegebenen Datensatz eine Visualisierung zu entwickeln, sondern einen automatischen Prozess zu etablieren, der jederzeit neu angestoßen werden kann. Eine Veränderung der Datengrundlage würde dann automatisch zu einer Aktualisierung des Diagramms führen. In einer idealen Welt sind Datengrundlage und Analyse ganz voneinander getrennt und nur funktional verbunden (die Analyse bedient sich bei der Datengrundlage). In so einem Szenario können Visualisierungen dynamisch reagieren, Veränderungen abbilden und stets aktuell sein. Das ist ein prinzipieller, theoretischer Anspruch. Ob dieses Versprechen in der Wirklichkeit eingehalten werden kann, wird man sehen.

Die typischen Arbeitsschritte von data science und information visualization, die allerdings nicht streng sukzessive ablaufen, sondern teilweise in Schleifen verlaufen und wiederholt werden müssen, sind unter anderem …

• Identifikation einer geeigneten Datenquelle
• Datengewinnung
• Datenbereinigung
• Entwicklung einer Fragestellung
• Konzeptionelle Entwicklung einer Visualisierung
• Technische Entwicklung einer Visualisierung
• Evaluation, Kritik, Überlegungen zu weiteren Entwicklungsmöglichkeiten

In diesem Prozess entstehen Daten und Dateien, die wir der Transparenz und Nachvollziehbarkeit halber im Repository der Digital Humanities an der Bergischen Universität Wuppertal abgelegt haben. Startpunkt dieser Dokumentation ist das gitlab-repo https://git.uni-wuppertal.de/dhsfu/uboote-brd

Die Datenquelle

Wie bereits erwähnt haben die meisten U-Boote einen eigenen Artikel. Aber nicht alle. Manche sind im Artikel zu ihrer technischen Klasse zusammengefasst. Kerninformationen laufen in einem Listenartikel zusammen. Die dort enthaltenen Tabellen zu den U-Booten sind händisch erstellt, speisen sich also nicht automatisch aus den Einzelartikeln und deshalb können die Informationen auch manchmal von diesen abweichen. Wenn wir davon ausgehen, dass der Listenartikel einigermaßen zuverlässige Daten enthält und auch in Zukunft weiter gepflegt und aktualisiert wird, dann können wir ihn trotzdem als Ausgangspunkt für die Informationsbeschaffung benutzen. Die “Liste der U-Boote” enthält zwei Tabellen, die für uns interessante Angaben enthalten, nämlich: Bezeichnung des Schiffes, Klasse, Datum der Indienststellung und Datum der Außerdienststellung.

Das sind alles relativ gut strukturierte, einheitliche Daten, mit denen man eigentlich gut arbeiten können sollte.[1] Zusätzlich gibt es ein freies textuelles Anmerkungsfeld, über dessen Nutzung wir uns später Gedanken machen können. Einzelne Angaben sind mit weiteren Wikipedia-Artikeln verlinkt, so dass in der Linkverfolgung zusätzliche Informationen erhoben werden könnten. Das betrifft hier vor allem das einzelne Boot (sofern es einen eigenen Artikel gibt) und die technische Klasse des Bootes. Über die Klasse ließen sich grundsätzlich Informationen zu Länge, Breite, Verdrängung, Besatzung, Antrieb, Bewaffnung und einiges mehr einsammeln. Über die einzelnen Bootsartikel käme man systematisch zu näheren Informationen, z.B. zu Schicksal und Verbleib. Die Bootsartikel (oder Beschreibungen der Boote in den Artikeln zur Klasse) sind aber weniger gleichmäßig strukturiert, so dass man hier nicht Detailinformationen in der ganzen Breite der Untersuchungsmenge gewinnen kann.

Datengewinnung

“Harvesting” ist das Zauberwort. Andere sagen “web scraping” dazu. Ausgehend vom Listenartikel haben wir mit einem Skript die Datentabelle ausgelesen und in gleichmäßig strukturierte Datensätze verwandelt. Grundsätzlich ist es egal, welche Technologie bzw. welche Programmiersprache man hier einsetzt. Aktuell erfreut sich in diesem Anwendungsbereich vor allem Python großer Beliebtheit. Wir haben aber XSLT den Vorzug gegeben, weil es sich bei der Zielressource um eine baumartig strukturierte Datei handelt. Eine Wikipedia-Seite ist eine HTML-Seite ist eine XHTML-Seite ist eine XML-wohlgeformte Datei. Deshalb “passt” die Logik der X-Technologien gut zu den vorliegenden Daten. Beim Harvesting unterscheide ich grundsätzlich zwischen “front door harvesting” und “back door harvesting”. Der Traum der Datenverarbeitung sind transparente, einfach zu nutzende APIs (Application Programming Interfaces), also Schnittstellen, mit denen andere Skripte mit Anwendungen kommunizieren und Daten austauschen können. Auch die Wikipedia hat selbstverständlich solche APIs, an denen ein Datenkunde seine Datenpakete an der Laderampe auf der Rückseite des Geschäfts abholen kann. Die uns interessierende Seite würde man mit

https://de.wikipedia.org/w/api.php?action=parse&format=xml&page=Liste_von_Unterseebooten_der_Bundeswehr

… bestellen und bekäme dann eine weiter verarbeitbare XML-Datei zurück. Aus verschiedenen Gründen bevorzuge ich aber manchmal das frontdoor harvesting. Ich gehe in den Laden den wir Browser nennen und sage – via https-Aufruf – nur “Gib mal die Seite X” und bekomme dann exakt das, was ich auch im Schaufenster gesehen habe. Schon in die Abfrage innerhalb einer XML-Verarbeitung durch XSLT eingebaut klingt das dann so:

doc(https://de.wikipedia.org/wiki/Liste_von_Unterseebooten_der_Bundeswehr)

Einfacher geht es nicht.

Man hat dann, wie gesagt, eine XML-Datei, die man weiter verarbeiten (Fachwort: parsen) kann. Aus der Seite werden dabei die Informationen ausgelesen, die uns interessieren. Ich spreche mal deutschen Pseudocode:

• gehe zu den uns interessierenden Tabellen
• für jede Tabellenzeile lege einen Datensatz an
• für jede Zelle der Zeile bilde ein Element und fülle es mit den entsprechenden Angaben

Das ist das Grundgerüst und im Prinzip ganz einfach. Im Detail stecken hier so einige Teufel. Unschön sind z.B. Zellen, die über mehrere Zeilen gehen (wie bei den U-Boot-Typen). Da muss man dann ein paar Umwege gehen Verfeinerungen einbauen. Für diesen Fall muss man z.B. vorher abfragen, wie viele Zellen es eigentlich in der Zeile gibt und wenn es eine Zeile mit fehlender Zelle ist, an der entsprechenden Stelle abfragen, was denn in der vorhergehenden vollständigen Zeile steht. Dies ist nur ein Beispiel. Das Parsing der Ausgangsdaten muss grundsätzlich so lange verfeinert werden, bis die gewünschten Ergebnisse erreicht sind. Im Prinzip sehen die dann aber ganz einfach so aus:

<boote>
   <boot>
      <name>U 2365 - S 170 (U-Hai)</name>
      <klasse>XXIII</klasse>
      <dienstStart>15. August 1957</dienstStart>
      <dienstEnde>24. September 1966</dienstEnde>
   </boot>

Datenbereinigung

Ein großer Teil des Aufräumens passiert schon beim Harvesting. Aus Gründen werden z.B. zusätzlich Kurznamen extrahiert oder die Klassentypen direkt mit Angaben zur Länge und zur Verdrängung ergänzt. Die menschenfreundlichen Datumsangaben (“15. August 1957”) werden um eine computerfreundliche Form ergänzt (1957-08-15). Außerdem passiert hier etwas, über das man sich in methodischer Hinsicht durchaus streiten darf: Im Hinblick auf die spätere Visualisierung wird erstens der zeitliche Abstand zu einem gesetzten Zeitpunkt (hier: 1.1.1945) berechnet und dieser zweitens in eine Distanz auf einer bestimmten Skala umgerechnet. Das ist eigentlich methodisch doppelt unsauber, denn die gesammelten Daten sollten eigentlich nicht auf die Nutzung in einer Visualisierung vorausschauen und sie sollten es ganz sicher nicht im Hinblick auf deren spezifische Skaleneigenschaften tun. Wir verbuchen diese Praxis unter “quick’n’dirty”. Die Daten sehen deshalb tatsächlich nicht wie im obigen Fake, sondern so aus:

<boote>
   <boot>
      <name kurz="U 2365">U 2365 - S 170 (U-Hai)</name>
      <klasse laenge="35" tonnen="258">XXIII</klasse>
      <dienstStart distanzZu45="4609" aufSkala750="226.19" norm="1957-08-15">
         15. August 1957</dienstStart>
      <dienstEnde distanzZu45="7936" aufSkala750="317.28" norm="1966-09-24">
         24. September 1966</dienstEnde>
   </boot>

Vom Prinzip her ist das harvesting- und parsing-Skript (HarvestData.xsl) jederzeit auf die Wikipedia-Seite anwendbar und erzeugt eine perfekte Datengrundlage für die Visualisierung. In der quick’n’dirty-Praxis hat man aber nicht immer Lust, noch die letzten Säuberungsaktionen in allgemeingültige Algorithmen zu übersetzen. Der Unterschied zwischen der erzeugten Datei und einer manuell nachgesäuberten Datengrundlage zerbricht also streng genommen den vollautomatisierten Workflow. Wir wollen aber mal nicht so streng sein. Außerdem ist die endgültige Daten-Datei (UBootDaten_clean.xml) auch zu didaktischen Zwecken ein wenig “schöner” formatiert.

Entwicklung einer Fragestellung

Daten sind “allgemein”. Sie können viele Fragen beantworten. In der Theorie. In der Wirklichkeit können bestimmte Daten aber nur bestimmte Fragen beantworten und legen bestimmte Daten bestimmte Fragen nahe. Die Tabelle der U-Boote ergibt für sich genommen noch keine einfache Erzählung. Man liest, dass Boote zu bestimmten Zeitpunkten in Dienst gestellt wurden und wieder aus dem Dienst genommen wurden. Man sieht, dass es eine Abfolge verschiedener Klassen gab, die sich z.B. in ihrer Größe unterschieden und vielleicht mal weniger und mal mehr erfolgreich waren. Das hätte man gerne übersichtlicher und auf einen Blick erfassbar. Die naheliegende Fragestellung ist, wie sich der Bestand an Booten und die verschiedenen Bootstypen entwickelt haben. Vielleicht lässt sich das dann auch in Beziehung zu den großen historischen Entwicklungslinien der Nachkriegsbundesrepublik setzen.

Konzeptionelle Entwicklung einer Visualisierung

Für eine historische Visualisierung bietet sich eine Zeitachse an. Auf der könnten die Boote dargestellt werden. Hier wäre eine Einzeichnung jedes einzelnen Bootes mit seiner Dienstzeit denkbar. Wir schreiben also ein kleines Skript, das eine Grafik-Datei erzeugt:

Unser XSLT-Skript schreibt eine SVG-Datei. Dabei ist unser SVG komplett individuell berechnet, greift also nicht auf bestehende Bibliotheken zurück. Dem Vorteil totaler Freiheit und Autonomie steht der Nachteil gegenüber, wirklich alles selbst bestimmen und berechnen zu müssen. Für diese Dokumentation ist außerdem zu beachten, dass SVG-Grafiken nicht in das WordPress-Blogsystem eingebunden werden können. Wir müssen deshalb hier leider mit Screenshots arbeiten. Dieselben sind aber mit den Original-SVG-Grafiken auf dem Server des Lehrstuhls verlinkt. Dort stehen dann auch alle dynamischen Funktionen, wie Zooming oder Hovern zur Verfügung. Hier ist zu betonen, dass der simple “Tooltip-Mechanismus” gerade bei dieser Art von Visualisierungen besonders wichtig ist, weil er dem unmittelbar Sichtbaren bereits eine zweite Informations- bzw. Explorationsschicht gibt. Eine dritte Schicht läge in weiter ausgebauten Infoboxen, eine vierte in der Verlinkung mit weiterführenden Ressourcen …

Der erste Entwurf einer algorithmischen Zeichnung zeigt schon einige Vor- und Nachteile dieses Ansatzes. Jedes Boot ist mit seiner Dienstzeit sehr gut zu erkennen. Durch die Verwendung von Farben für die verschiedenen Klassen wird auch die technische Entwicklung gut sichtbar. Auf die gehobenen Weltkriegsboote (braun) folgen die “scheiternden” Klassen 201 und 202 (grün) und dann die erst scheiternden, aber dann doch funktionierenden Klassen 205 und 206 (blau), die dann erst nach der Jahrtausendwende durch eine ganz neue Entwicklung (Klasse 212A, violett) abgelöst wurden. Die einzelnen Boote, den Zusammenhang der Dienstzeiten und Klassen sieht man hier sehr gut. Die sehr unterschiedliche Größe der Boote sieht man nicht. Und man kann nicht überblicken, wie viele Boote eigentlich zu welcher Zeit einsatzbereit waren. Deshalb haben wir uns entschiedenen, einen anderen Weg einzuschlagen, der einem etwas konventionelleren Ansatz folgt und letztlich die Idee des Liniendiagramms wieder aufnimmt.

Technische Entwicklung des Diagramms

Hierzu ist schon alles nebenbei gesagt: Ein XSLT-Skript nimmt unsere erstellten Daten und verwandelt sie in eine SVG-Datei. Im Kurs hatte sich gezeigt, dass SVG eine sehr einfach zu erlernende Technologie ist. Wie bei den meisten Web-Technologien bedeutet dies aber eigentlich Zweierlei. Die grundlegende Funktionsweise und erste Schritte, mit denen man schon produktiv arbeiten kann, sind sehr leicht zu lernen. Dahinter verbergen sich dann weite Möglichkeiten und die Komplexitäten einer professionellen Anwendung – die man nur allmählich und entlang eigener Projekte vertiefen kann. Unser SVG ist damit ein weitgehend “unprofessionelles” SVG – aber letztlich zählt nur das Ergebnis. Im Kurs haben viele Studierende SVG “von Hand” geschrieben, XSLT haben nur die eingesetzt, die diese Sprache schon vorher kannten oder sich selbst beigebracht haben. Bei SVG habe ich allerdings Wert darauf gelegt, dass keine Programme wie InkScape oder Adobe Illustrator eingesetzt werden. Beide erleichtern zwar als WYSIWYG-Editoren das Zeichen, hinterlassen aber keinen menschenlesbaren Code, so dass ein tieferes Verständnis der Logik und Funktionsweise von SVG eher erschwert wird.

Unser Ergebnis

Diagramme sind fast nie “perfekt”. Eigentlich gibt es immer etwas zu verbessern, zu ergänzen, zu diskutieren oder zu revidieren. Das folgende Diagramm markiert deshalb eher nur einen stabilisierten Diskussionstand, allerdings nach bereits dutzenden Iterationen und Veränderungen.

Nun sieht man sehr gut die Entwicklung des Bestandes, denn die verbindende Linie bildet die Summe der Boote im Dienst ab. Bei jeder Indienststellung (ausgefüllter Kreis) steigt der Bestand, bei jeder Außerdienststellung (leerer Kreis) sinkt er. Werden zeitgleich mehrere Boote in Dienst oder außer Dienst gestellt, kommt es zu entsprechenden Sprüngen. Für eine genauere individuelle Betrachtung der Boote gibt es wiederum Tool Tips.

Nachteilig an dieser Lösung sind Zeiträume schnellen Indienst- und Außerdienststellens wie in den späten 1960er Jahren, weil hier der Blick in die Details erschwert wird. Allerdings kann man in SVG natürlich beliebig hineinzoomen, um genauer hinzuschauen. Und es bleibt eine valide Aussage: Hier passiert viel. Die Grafik verwendet ähnliche Farben, um die Klassen zu unterscheiden. Außerdem wird die Größe der Kreise variiert um die Unterschiede zwischen Kleinst-U-Booten, den die meiste Zeit üblichen kleinen Booten und den jetzt wieder größeren Booten sichtbar zu machen.

Überlegungen zur Farbgebung erfordern eigentlich einen gesonderten Bericht, denn auch mit Farben wird erzählt. Nähe und Distanz von Farben sind hier z.B. sehr bewusst danach gewählt, wie Klassen wiederum Gruppen bilden und wie stark sie sich voneinander unterscheiden. Außerdem wird hier natürlich der fundamentale Unterschied zwischen den “alten” (zunächst versenkten und später wieder gehobenen) Weltkriegsbooten und den technischen Neuansätzen deutlich gemacht. Fragen der Farbgebung und einer möglichst “schönen” Legende waren im Kurs eine gesonderte Aufgabe, die hier von Elia Hildebrand gelöst worden ist, dem insofern die entsprechenden Credits zustehen. Jana Klinger hat an vielen Stellen an der SVG-Umsetzung mitgearbeitet. Ann-Kathrin Haustein hat bei der Erfassung und Berechnung von Daten geholfen, die nicht automatisch ausgelesen wurden.

Die Daten kommen aus der Wikipedia. Sie sind halbautomatisch in eine Visualisierung überführt worden. Was liegt näher, als das Diagramm wieder im Wikipedia-Artikel einzufügen, dessen Zahlen hier veranschaulicht werden? In einer idealen Welt würde sich die Visualisierung automatisch aus sich ändernden Daten speisen und selbst aktualisieren. Eine solche Dynamisierung wird allerdings auf absehbare Zeit nicht möglich sein, weil verschiedene technische Restriktionen eine vollständige Automatisierung verhindern. Tatsächlich war es noch nicht einmal einfach, das Diagramm überhaupt in den Wikipedia-Artikel einzubringen.[2]

Verfeinerungen und Erweiterungen?

Was bleibt zu tun, was kann noch besser gemacht werden? Bei Diagrammen geht es auch um Ästhetik und Design. Hier ist wahrscheinlich noch Luft nach oben. Wieso sehen z.B. die Skalen und Skalenbeschriftungen für mich noch nicht perfekt aus? Grundsätzlich können auch immer noch mehr Informationen in eine Grafik eingefügt und noch mehr Details gegeben werden. Die Tool Tipps könnten zu echten Infoboxen ausgebaut werden. Die Hover-Funktion könnte auch weitere Informationsschichten z.B. für die Geschichte der einzelnen Boote sichtbar machen.

In dieser Diagrammform wäre die Visualisierung aller vollständigen Einzelgeschichten schwierig, weil ja nicht jedes Boot einen eigenen “Platz” in der vertikalen Anordnung hat. Wir haben deshalb alle Schicksale wiederum in den ersten (gestapelten) Entwurf integriert und dort zusätzlich einen Schalter eingebaut, der diese Informationsschicht “togglet” also sichtbar und unsichtbar schaltet. Technisch erweitert sich das Arsenal der Mittel zur Diagrammerstellung um eine minimale Menge Javascript. Inhaltlich ergibt sich eine neue Tiefendimension und eine Zusammenschau der Geschichten vor und nach den eigentlichen Dienstzeiten. Auch hier ist wieder eine differenzierende Farb- und Formensprache zu finden. Hellgrün sind hier andere Verwendungszeiträume, Grau sind “Latenzzeiten” (durchgezogene Linien für Bauzeiten und “in Abwrackung”; gestrichelte Linien für “bestellt” oder “noch nicht in Anschlussverwendung), Gelb sind passive Verwendungen (z.B. als Ersatzteilspender), Rot sind Verwendungen als Museumsboot. Sichtbar wird jetzt einerseits, dass die unterschiedlichen Bau- und Indienststellungszeitpunkte eher zufällig sind und auf blockweise Bestellvorgänge zurückgehen,[3] dass manchmal früher geplante Boote erst später in Dienst gestellt werden konnten, und wo Boote ein Nachleben als Museumsboote oder sogar im aktiven Dienst anderer Länder gefunden haben.

Der Phantasie für noch mehr Information, mehr Dynamik und mehr Interaktion sind insgesamt kaum Grenzen gesetzt. Mit JavaScript-Schalthebeln wie dem eben ansatzweise eingeführten könnten Informationsschichten noch weiter gefiltert oder Diagramme angereichert werden. Aber bis zu welchem Punkt ist das sinnvoll? Und wie lange stehen Aufwand und Nutzen noch in einem guten Verhältnis?

Visualisierung als Reduktion

Visualisierungen dienen auch dazu, Informationen zu reduzieren und Geschichten auf den Punkt zu bringen. In diesem Sinne sind wir vielleicht schon zu weit gegangen? Im Prinzip des “overview and detail” haben wir zwar schon einen Überblick über die Entwicklung der deutschen Rüstung am Beispiel der U-Boote und zugleich die Möglichkeit, sich die einzelnen Boote im Detail anzusehen, aber vielleicht liegt eine gute “Geschichte” in der deutlichen Vereinfachung. Denn worum geht es hier: Die U-Boote der Bundesmarine zeigen plastisch die Geschichte der Bundesrepublik zwischen Kriegsende, Wiederbewaffnung, Kaltem Krieg, Wiedervereinigung, Friedensdividende und politischer Neuausrichtung (?).

Diagramme als Bilder sprechen nicht nur die Sprache der Statistik, sondern auch im Rahmen der Bildsprache. Gegen die Richtschnur des linearen Sprechens und der linearen Zeichenketten steht hier die Topografie der Zweidimensionalität im Vordergrund. Dies ernstgenommen, kommt es zu einer eigenen Ausdrucksweise und zu einer anderen “Ästhetik”, die man für gelungen oder misslungen, für besser oder schlechter lesbar, für ausdrucksstärker oder unverständlich halten mag:

Fußnoten

[1] Im Arbeitsprozess können jedoch vereinzelt auch Unstimmigkeiten auftreten. So zum Beispiel beim Datum der Außerdienststellung der U-Boote U13 und U14. Hier ist in dem Listenartikel vom 23.09.1997 die Rede. In den Einzelartikeln dagegen vom 26.03.1997. Der Artikel zur Klasse der Boote gibt als Datum ebenfalls den 26.03.1997 an. Wie geht man nun mit diesen widersprüchlichen Angaben um? Zunächst sollte geprüft werden, ob eine der Angaben mit externen Belegen versehen ist. Dies ist bei diesem Beispiel jedoch auf keiner der drei Seiten (Gesamtliste, Klasse, Einzelartikel) der Fall.
In einem nächsten Schritt lohnt es sich, die Versionsgeschichten der Artikel genauer anzusehen. So lässt sich prüfen, ob in einem der Artikel zu einem bestimmten Zeitpunkt (möglicherweise unter Angaben von Gründen) das Datum der Außerdienststellung vom 23.09. zum 26.03. geändert wurde (oder umgekehrt). Die Versionsgeschichten der Einzelartikel zu den U-Booten U13 und U14 verraten, dass beide Artikel am 22. Dezember 2016 erstellt wurden und von Beginn an als Datum der Außerdienststellung den 26.03.1997 nennen.
In der ersten Version des Listenartikels der U-Boote (vom 20. August 2004) wird für U13 und U14 noch kein Datum der Außerdienststellung angegeben. Dies wurde jedoch schon wenige Tage später, am 23. August 2004, nachgeholt. Hier wird der 23.09.1997 als Datum der Außerdienststellung genannt, wie es auch in der aktuellen Version des Artikels noch der Fall ist.
Ein Blick in die Versionsgeschichte des Klassenartikels verrät, dass dieser Artikel am 5. August 2004 erstellt wurde, und damit ähnlich alt ist wie der Listenartikel. Schon in der ersten Version des Artikels ist zu den U-Booten U13 und U14 ein Datum der Außerdienststellung angegeben: der 23.09.1997. Und jetzt wird es interessant! Denn in der aktuellsten Version dieses Artikels wird als Datum der Außerdienststellung der 26.03.1997 genannt. Es muss also irgendwo in der Versionsgeschichte des Artikels zur U-Boot-Klasse 206 der Zeitpunkt zu finden sein, an dem das Datum der Außerdienststellung vom 23.09. zum 26.03. geändert wurde.
Tatsächlich lässt sich dieser Punkt auf die Zeit vom 3.-5. Juni 2010 festsetzen. In der betreffenden Woche ist in dem Artikel viel passiert, da verkündet wurde, dass diejenigen U-Boote der Klasse 206A, die sich noch im Dienst befanden, mit sofortiger Wirkung außer Fahrbereitschaft genommen und in Kürze außer Dienst gestellt werden würden. Die Tabelle mit den Informationen zu den U-Booten der Klasse 206(A) wurde daraufhin in wenigen Tagen von verschiedenen Benutzer:innen bearbeitet und aktualisiert, wobei zwischenzeitlich auch das Datum der Außerdienststellung der U-Boote U13 und U14 fälschlicherweise zum Juni 2010 geändert wurde. Dieser Fehler wurde kurz darauf wieder korrigiert, jedoch wurde dann nicht, wie zuvor, der 23.09.1997 als Datum der Außerdienststellung eingetragen, sondern stattdessen der 26.03.1997.
Es liegt also der Verdacht nahe, dass in dem Anfang Juni 2010 im Artikel zur U-Boot-Klasse 206 herrschenden Chaos, versehentlich das Datum der Außerdienststellung vom 23.09.1997 zum 26.03.1997 geändert wurde. Dieser Verdacht wird noch dadurch erhärtet, dass die Person, die im Klassen-Artikel das Datum der Außerdienststellung zum 26.03.1997 änderte, eine halbe Stunde später auch den Listenartikel bearbeitet hat, ohne hier jedoch das Datum der Außerdienststellung ebenfalls vom 23.09.1997 zum 26.03.1997 zu ändern.
Letztendlich bleibt es also bei der begründeten Vermutung, dass es sich beim 23.09.1997 um die verlässlichere (weil früher angegebene und nur unter fadenscheinigen Umständen geänderte) Angabe handelt.

[2] Bilder für die Wikipedia sollten zunächst bei wikimedia commons hochgeladen und mit Informationen zum Bild und zu seiner Lizenz versehen werden. Das ist im Prinzip unproblematisch, das Ergebnis sieht man hier: https://commons.wikimedia.org/wiki/File:UBoote_BRD_v1.svg. Die Schwierigkeiten liegen darin, dass man nicht einfach jede Art von SVG-Grafik (sinnvoll) hochladen kann. Aus Sicherheitsgründen sollte z.B. kein Javascript-Code enthalten sein. Die größte Hürde stellt aber der Konverter von wikimedia dar, der aus einem SVG-File eine Rastergrafik (für SVG typischerweise dann PNG) erstellt weil in den Wikipedia-Artikel SVG-Bilder in der Regel nicht unmittelbar und nativ, sondern stattdessen ein Vorschaubild angezeigt werden sollen. Das Konversionsskript hat leider seine Eigenheiten: es verweigert z.B. die Verarbeitung von circle-Elementen (Kreise) ohne unmittelbare (sondern in die CSS-Angaben ausgelagerte) Radius-Angaben und ist insgesamt sehr empfindlich, was die Verletzung von XML-Wohlgeformtheit oder -Validität betrifft. Das ist im Prinzip verständlich, macht damit aber einen großen Unterschied zur Praxis der gängigen Browser, die solche SVG-Dateien klaglos und korrekt anzeigen. Unverständlich ist, dass der Konverter eine den Browsern diametral entgegengesetzte Politik verfolgt, was die Verwendung des Attributs href im Code betrifft. Während die Verwendung von “xlink:href” vom W3C inzwischen als “deprecated” deklariert ist, verlangt die Wikipedia die veraltete Methode inklusive Deklaration des Namensraumes. Ähnlich eigenwillig verhält es sich mit den Schriftarten in SVG-Grafiken. Hier will der Konverter nur solche zulassen, die allgemein auf den Wikimedia-Servern installiert sind. Und das sind – gelinde gesagt – “exotische” Fonts. Zwar gibt es Ersatzschriften für Arial oder Times New Roman, aber kein SVG-Designer würde wohl auf die Idee kommen, seine Schriften initial nach der Font-Liste der Wikimedia auszuwählen. Im Ergebnis ist die Situation im Jahr 2021 deshalb trotz des rührigen internen “Wikiprojekt SVG” so, dass selbst “einfache” und “saubere” SVG-Grafiken nochmals erheblich überarbeitet werden müssen, bevor sie in der Wikipedia eingebunden werden können. Wir haben in diesem Prozess sehr viel recherchieren und lernen müssen und viele dutzend Male das SVGCheck-Tool bemühen müssen, bis alles nach dem Geschmack des Konverters war.

[3] Es ist uns nicht gelungen, den Bestellzeitpunkt für die Boote der Klasse 206 und einige der Klasse 212A zu ermitteln. Wikipedia macht hierzu keine Angaben und auch in den ansonsten leicht zu recherchierenden Parlamentsprotokollen findet man diese Information nicht. Wir freuen uns über entsprechende Hinweise.

---

---