Ab 09:27 kommt im Video ein anschauliches Beispiel des dahinter liegenden Paradigmenwechsels. Anstelle von Apps, die auf hardcodierte APIs zugreifen muessen (und die dann wieder angeflanscht an zentralisierte Datensilos sind), werden Abfragen im dezentralen Modell lokal synthetisiert. Die notwendigen Daten kommen dann aus denjenigen verteilten Quellen, die fuer genau diese Frage notwendig sind.
In Ergaenzung (und technisch notwenige Voraussetzung) zum auf den Kopf gestellten Nutzungsversprechen von Open Data erlaubt diese Herangehensweise eine Abkehr von zentralisierten Superdatenplattformen. Die bisherige Idee war, dass es ja eine Vielzahl von Fachverfahren gebe, deren Daten in einzelnen Silos liegen. Um das aufzubrechen muessten Verfahren standardisiert werden und alle Daten in ein zentrales Silo anliefern. Was auch bedeutet, dass z.B. einzelne Kommunen oder Bezirke ihre bisherigen Fachverfahren fuer ein Thema aufgeben und sich der Mehrheit anschliessen muesten – und sei es mit Zwang. Im Gegenmodell waere die interne Datenhaltung oder zumindest das Ergebnis eines ETL-Prozesses der Fachverfahrensdaten ein Knowledge Graph – und ueber verteilte Knowledge Graphs lassen sich wie im Video demonstriert wunderbar Abfragen fahren, nur durch die Magie von 5-Sterne-Daten mit Semantik. Die Bausteine dafuer sind mittlerweile Jahrzehnte alt und gut abgehangen. Und eigentlich passt das auch viel besser in das Modell eines foederalen Staats, der nicht alles von oben her vereinheitlicht und nach oben hin an sich zieht, sondern auf den Ebenen auch Entscheidungsspielraeume laesst.
Lilith Wittmann ist wie immer gleich deutlich radikaler und sagt: Alles bis drei Sterne sollte eigentlich gar nicht mehr zaehlen, wir muessten noch weiter gehen und Open Data erst ab vier Sternen ueberhaupt „zaehlen“ lassen:
Das Problem ist aber: Wir haben seit 15 Jahren dieselbe Vision, bei der alles ab Schritt 4 in weiter Ferne erscheint. Und gerade in Deutschland kam nie irgendwas über 3⋆ hinaus.
Deshalb schlage ich heute eine neue Version von 5⋆ #OpenData vor.
Toris Post war mir jetzt endlich aufraffender Anlass, verschiedene Textstuecke zusammenzustellen, die ich seit einer Weile vor mir herschiebe, und im Mai war das nun endlich alles so weit, dass ich einen ersten Entwurf beim Kommunalen Open Data Barcamp vortragen konnte. Denn dieser Fokus „die oeffentliche Hand soll Open Data bereitstellen, damit Dritte irgendetwas damit tun“ ist einer der fundamentalsten Missverstaendnisse des letzten Jahrzehnts in dieser Szene. Und ich fuerchte, dieses Missverstaendnis sabotiert seit Jahren die eigentlich anzugehenden Aufgaben.
Eine Quelle dieses Missverstaendnis koennte das typische “Showing what’s possible“-Muster aus dem Digitalen Ehrenamt sein. An einem konkreten Beispiel wird gezeigt, was mit offenen APIs und/oder offenen Daten oder einem besseren User Interface moeglich waere. Dabei ist beinahe egal, ob man nun einen bestehenden Dienst besser macht (wie z.B. kleineanfragen.de das tat), oder ob man an einem ganz konkreten Beispiel (fuer das man irgendwie an Datenpunkte kam) ein anschaulich nutzbares Produkt baut, wie die Trinkwasser-App.
Ende November hatten wir im Netzwerk Code for Germany einmal versucht, typische Aktivitaeten der lokalen Open-Data-Arbeitsgruppen einzuordnen, und an vielen Stellen kam dieses „showing what’s possible“ zur Sprache. Menschen machen das aus den verschiedensten Beweggruenden: Weil sie selber einen praktischen Anwendungsfall fuer das Ergebnis haben. Weil sie zeigen wollen, was geht. Oder einfach auch nur aus Spass.
An vielen Orten entstanden genau so vor ca. 10 Jahren die ersten veroeffentlichten Datensaetze. In Ulm hatte die Gruppe Engagierter einzelne Datensaetze per Mail von der Stadtverwaltung erhalten, und beispielsweise die Geodaten der Stadtbezirke selber zum Download und ueber eine CouchDB ausgespielt, und in Click-that-Hood praktisch erfahrbar gemacht.
Andere Staedte sprangen auf den „Trend“ auf. Datensaetze wurden immer noch haendisch herausgesucht und veroeffentlicht – und meist orientierte man sich dabei an den Datensaetzen, die bereits anderswo veroeffentlicht oder gar in einen praktischen Anwendungskontext bezogen wurden. Und nebenbei glaubte man, dass Datenportale hermuessten, Metadatenbeschreibungen fuer jede Excel-Liste im Datenportal wurden umstaendlich gepflegt, und viel dergleichen haendische Arbeit mehr.
Auf der zivilgesellschaftlich engagierten Seite entstand dadurch der empfundene Druck, die bisherigen Konzeptprototypen und Showcases zu „redeployen“. Anderswo gab es nun auch Stadtbezirks-Geoshapes, Trinkwasserinformationen und dergleichen mehr. Also, war die Annahme, muesse man die aktuellen Daten nun auch in einen lokalen Ableger dieser Showcases einpflegen. Gleichzeitig stieg die Erwartung, dass diese Beispielvisualisierungen auch auf lange Frist unterhalten und gepflegt werden wuerden. Und an den Orten, an denen sich niemand auf die aufwaendig bereitgestellten Daten stuerzte, war die Enttaeuschung gross. Denn wofuer macht man sich ueberhaupt den Aufwand?
Eigentlich seltsam, denn die Metapher ging ja eigentlich schon lange dahin, dass die Bereitstellung offener Daten so etwas wie ein automatisierter Containerhafen werden sollte – derweil die Daten immer noch wie haendisches Stueckgut aus den Fachverfahren und Excel-Listen herausgetragen werden.
Und da sind wir eigentlich am Kernproblem: An viel zu vielen Stellen wird haendisches oder maessig automatisiertes 3-Sterne-Open-Data immer noch als akzeptables Zwischenziel angesehen.
Wir erinnern uns aus dem Covid-Daten-Beispiel: Bis zu 3-Sterne-Daten kommen als CSV daher – ohne Informationen, was eigentlich in welcher Spalte steht und was das sein soll. Ist es ein Datum? Ein Strassenname? Die Zahl der Infizierten am gestrigen Tag? Wenn ich das auswerten will, muss ich das meinem Parser erst einmal haendisch pro Spalte beibringen. Und wenn das RKI die Reihenfolge der Spalten aendert, faellt der Parser auf die Nase.
Ich glaube, dass all das damit zusammenhaengt, dass in der Regel intern gar nicht die Voraussetzungen vorhanden sind, um mit diesen Daten in groesserem Umfang etwas anzufangen. Die Listen sind Datenbasis fuer (haendisch erstellte) Reports, (haendisch erstellte) Schaubilder, aber es sind weder die notwendigen Werkzeuge noch die notwendigen Infrastrukturen vorhanden, um schon verwaltungsintern Daten ueberhaupt strukturiert abzulegen und dann an anderer Stelle damit zu arbeiten – idealerweise mit dem Ziel eines Knowlege Graphs fuer 5-Sterne-Open-Data.
Und gerade weil die notwendige Voraussetzung fuer die Herstellung eines solchen Zustands eine hervorragende IT-Infrastruktur auf dem Stand der Technik ist, muessen wir die bisherigen Herangehensweisen weitgehend auf den Kopf stellen. Bisherige Beispielkataloge, was denn ueberhaupt als Open Data veroeffentlicht werden koennte, orientieren sich meist daran, was anderswo da war. Das waren aber eben entweder die beruechtigten “Low Hanging Fruits”, oder eben Datensaetze fuer die genannten Proofs of Concept. Das ist aber meist komplett losgeloest von einer internen Nutzung, die ueberhaupt erst die Motivation und den Anlass geben koennte, die dafuer notwendigen Strukturen aufzubauen. Idealerweise wuerde eine Strategie nicht damit beginnen, die hunderten Fachverfahren zu kartieren und wie man deren Daten per ETL herauskratzen kann. Sondern (mit einer klaren Strategie zu Linked Open Data im Kopf!) praktische Anwendungsfaelle zu finden, in denen Einheit A intern Daten braeuchte, die Einheit B bislang unstrukturiert ablegt oder auf Zuruf aufbereitet – und dann beginnt, Prozesse fuer die automatische Verdatung zu bauen. Inklusive des Aufbaus der notwendigen Kompetenzen und des Unterbaus, um das selber machen zu koennen oder zumindest den Weg dahin kompetent selbst zu bestimmen. Open Data darf kein Mehraufwand sein, sondern faellt quasi als Abfallprodukt aus besseren Prozessen heraus – wer etwas veraktet, produziert automatisch Linked Data, das bereits behoerdenintern nachgenutzt werden kann. Der Open-Teil ist dann „nur“ noch eine Frage dessen, was nach aussen veroeffentlicht werden soll.
Die Digitalisierung des Gesundheitswesens ist ein Trauerspiel. Die Datenlage zu den Auswirkungen der Omikron-Welle ist ein Desaster. Dabei ist eine gute Datenlage der Dreh- und Angelpunkt im Kampf gegen Omikron, kommentiert Eva Quadbeck. https://t.co/UhTLwZHdN7
Die Digitalisierung des Gesundheitswesens sei ein Trauerspiel, titelt das Redaktionsnetzwerk Deutschland. Nachdem man dem Reflex nachgegeben hat, „was, nur des Gesundheitswesens?“ zu rufen, dachte ich mir, man koennte ja mal das mit dem Aufschreiben des besseren Gegenentwurfs machen, der mir seit Monaten im Kopf rumspukt.
Tatsaechlich beobachte nicht nur ich die (Daten)lage seit geraumer Zeit mindestens mit Irritation. Lena Schimmel schrieb kurz vor Weihnachten einen ganzen Thread, dass sie selbst erschreckend lange die eigentlich vom RKI veroeffentlichten Daten ueber Sequenzierungen gar nicht erst gefunden hatte:
Okay, das ist jetzt… peinlich? Lustig? Beruhigend? Beunruhigend? Irgendwie alles davon:
Ich hab ja kürzlich die Sequenzierungen des RKI auf GitHub gefunden und viel Arbeit hinein gesteckt, aus den Sequenzen die Varianten zu bestimmen.
Ich glaube, dass „wir“ als „die gesellschaftliche Open-Data-Lobby“ uns wieder viel viel mehr auf Linked Open Data als Ziel konzentrieren und das auch kommunizieren muessen. Bei all dem Einsatz, wenigstens CKAN oder irgendein Datenportal auszurollen, scheint das fernere Ziel ueber die Jahre immer mehr in Vergessenheit geraten zu sein.
Schon vom Nutzungsfaktor her duerfte dieses Ziel jedoch am Beispiel der Pandemie sehr klar zu vermitteln sein. Seit nun beinahe zwei Jahren setzen sich jeden Morgen viele DatenjournalistInnen an ihre Rechner und versuchen, aus den aktuellen Datenpunkten zum Infektionsgeschehen und den Impfungen Erkenntnisse zu ermitteln und diese nachvollziehbar aufzubereiten.
heute arbeite ich eigentlich nicht, aber das @rki_de fügt unnötige spalten ein, deren werte sich aus den vorhandenen daten berechnen lassen. pic.twitter.com/8uT9GarRzt
Ueber die Zeit hinweg ist es ein bisschen zu einem Running Gag geworden, dass das RKI dabei immer wieder mal Spalten vertauscht oder neue Daten hinzufuegt, so dass all die gebauten Parser auf die Nase fallen.
Derweil koennte die Lage mit verlinkten – oder wenigstens semantischen – Daten deutlich einfacher ablaufen. Man kann sich die 5-Sterne-Treppe fuer offene Daten am Beispiel der RKI-Berichte recht anschaulich klarmachen:
In der ersten Stufe (die Daten sind irgendwie da) sind die Informationen zwar irgendwie als digitale Symbole codiert, das kann aber auch ein PDF sein, oder im schlimmsten Fall ein PDF eines eingescannten Dokuments. Eine Maschine kann diese Symbole uebertragen und die dadurch codierten Inhalte aufbereiten und anzeigen, aber die Datenpunkte darin sind im unpraktischsten Fall nur fuer Menschen lesbar.
(Exkurs. Wenn wir ueber „Daten“ sprechen, werden schon diese beiden Definitionen haeufig wild durcheinander geworfen. Einerseits die Symbole oder „bits und bytes“, die Information codieren – so wie die Buchstaben, die diesen Satz bilden. Andererseits Datenpunkte, die z.B. verarbeitbare Information ueber einen Temperaturmesswertverlauf abbilden.)
In Stufe 2 und 3 sind auch die Datenpunkte fuer Maschinen interpretierbar, weil die Informationen mehr oder weniger strukturiert in einem proprietaeren (Excel) oder offenen (CSV) Format vorliegen. Die Zusammenhaenge bzw. die Semantik erschliessen sich jedoch immer noch nur der menschlichen Betrachterin, die diese Struktur selbst in die automatisierte Auswertung einbauen muss. Wenn das RKI ohne Ankuendigung die Reihenfolge der Spalten aendert, kann ein einmal geschriebenes Auswertungsskript diese Aenderung nicht ohne weiteres erkennen und wird erst einmal falsche Auswertungen ausgeben, bis es auf die veraenderte Datenlage angepasst ist.
Das ist der Punkt, der in Stufe 4 behoben wird: Dann ist naemlich auch die Semantik als weitere Ebene im Datensatz codiert. Ich muss nicht mehr als auswertende Person aus dem Originaldokument in menschlicher Sprache lesen und dann fuer das Auswertungsskript festlegen, dass Spalte B das Bundesland und Spalte N die Zahl der in einem Impfzentrum vollstaendig geimpften Personen unter 60 Jahren ist. Ich muss stattdessen dem Auswertungsskript fuer das (zugegeben, einfachere) Beispiel des Bundeslands „nur“ mitgeben, dass es in irgendeiner Spalte eine Beschreibung gemaess Language, Countries and Codes (LCC) erwarten kann, und da wird dann ein passender ISO-3166-2-Code mit dabei sein. In welcher Reihenfolge die Spalten dann ankommen, und ob das jetzt der Impf- oder der Inzidenzbericht ist, spielt eigentlich keine Rolle mehr.
Die Fallzahlen kommen aus einem Repo, die Geoshapes aus einem anderen, auf das als Dependency verlinkt werden kann. Ausserdem: Ich kann keine Karten zeichnen (deswegen brauche ich Shapes)
Im Vollausbau der Stufe 5 verlinkter Daten wird vielleicht am besten deutlich, was man mittlerweile haben koennte. Anstatt dass man sich jeden Morgen ein hoffentlich aktualisiertes Excel-File der Inzidenzen und Impfinformationen herunterlaedt, reicht das Gegenstueck zu einem git pull – alles liegt als von Tag zur Tag (bzw Veroeffentlichungsschnappschuss zu Veroeffentlichungsschnappschuss) versionierter Datenframe vor. Wenn ich den Datensatz einmal ausgecheckt habe, kann ich lokal die Updates bekommen, die Unterschiede von Schnappschuss zu Schnappschuss diffen, und auch in der Historie beliebig zurueckspringen, um Zeitreihen zu machen.
Da aber sowohl die Semantik im Datensatz codiert ist, als auch Links auf andere Datenquellen vorhanden sind oder von mir hergestellt werden koennen, kann ich sehr viel mehr automatisieren, was ich sonst zu Fuss machen muesste: Wenn in irgendeiner Spalte die Landkreise mit Kreisschluessel codiert sind, und ich meine Auswertung per Karte machen will, kann ich aus einer passenden anderen Datenquelle automatisch die Geometrien des NUTS-3-Level in Deutschland laden und mit dem RKI-Datensatz verknuepfen.
Das ist jetzt rein aus der Nutzungsperspektive gesehen, weil das mit die anschaulichste ist. Eigentlich viel spannender ist aber, die Konsequenzen durchzudenken, was es bedeuten wuerde, die dafuer notwendige Infrastruktur im Betrieb zu haben. Das heisst, dass Datenpunkte und Informationen nicht haendisch in der Gegend herumgetragen und zu Fuss alleine in Excellisten vorgehalten und gepflegt werden. Dass es definierte Schnittstellen und Datenfluesse gibt, die auch die behoerdeninterne Nutzung von fuer Entscheidungen relevanter Daten erlauben, ohne dass diese muehsam und fehleranfaellig zusammengekratzt werden muessen. Und nicht zuletzt auch, dass wir dafuer die ueber Jahrzehnte aufgebauten technischen Schulden der oeffentlichen IT-Infrastruktur abgebaut und die Architektur vorausschauend sparsamer weil effizienter(!) geplant und umgesetzt haben.
Es ist total schade, dass so viele der Visionen aus den 2000ern durch das jahrelange Klein-Klein der Umsetzung, die zu schliessenden Kompromisse mit Verwaltungen, und die perverse incentives fuer „Umsetzungen“ verkaufende Dienstleister so tief in die metaphorischen Sofaritzen verschwunden und in Vergessenheit geraten sind.
The current public funding schemes geared towards “digitalization” and “innovation” constitute perverse incentives. In the long run, they are not only expensive, but will pile up massive amounts of technical debt vastly exceeding the investments. https://t.co/dsb8ovKMvq
Manches davon ist natuerlich auch mittlerweile ueberholten Ueberlegungen von damals geschuldet. In der 5-Sterne-Treppe wird beispielsweise als erster Schritt ein „OL“ angegeben, das fuer eine Offene Lizenz stehen soll. Das halte ich mittlerweile fuer ueberholt und teilweise durch die viele Wiederholung auch ein wenig schaedlich. Denn die Diskussion z.B. bei Infektions- oder Impfdaten ist eigentlich gar nicht, ob sie unter der internationalen Creative-Commons-Lizenz oder der nutzlosen und ersatzlos abzuschaffenden Datenlizenz Deutschland „lizenziert“ werden. Denn das sind Faktendaten, und die gehoeren allesamt gemeinfrei gemacht.
tl;dr: Bitte einmal Linked Open Data als Ziel, zum mitnehmen, und etwas mehr freundliche Radikalitaet.
Ich bin gerade noch einmal ueber den Vortrag „CKAN: apt-get for the Debian of Data“ vom 26C3 im Dezember 2009 gestolpert. Rufus Pollock (Gründer von Open Knowledge International) und Daniel Dietrich (Mitgruender des deutschen Ablegers, der OKFde) erklaerten damals ihre Vision eines Netzwerks von Datenquellen.
Das heute, knapp 12 Jahre spaeter noch einmal anzusehen, war… spannend. Ich zucke heute ueber das “this is when nerds run things” am Anfang peinlich beruehrt zusammen, aber es lohnt sich total, noch einmal aufzurollen, was in der Zwischenzeit alles (nicht) passiert ist:
Der gesamte Vortrag denkt in (vermeintlich) notwendigen Lizenzen fuer Daten – “Free Data“ von Denny Vrandečić wird erst drei Jahre spaeter veroeffentlicht werden. An ganz vielen Stellen betont Pollock, dass es total wichtig sei, irgendeine Lizenz anzugeben – das haelt sich leider an vielen Stellen bis heute und klebt uns als Bewegung am Bein.
Ueberhaupt, die ganze Idee von CKAN: Versionierung, Packages etc., wo sind wir 12 Jahre spaeter? Man denke nur an die RKI-Daten waehrend der Covid-Pandemie. Oder auch die gesamte Idee mit Dependencies und weiteren herunterzuladenden Datenpaketen. Die schmeckt ein wenig wie Linked Open Data – und ich haette das sehr gerne in der Praxis. Habe ich aber noch nie gesehen. (Bei 53:20 ff. wird das am Beispiel der Postleitzahlen beschrieben)
„Schaut mal, die Briten nehmen schon CKAN um Open Data zu veroeffentlichen und wir hoffen, dass das die deutsche Politik ueberzeugt, ebenfalls Open Data herauszugeben“. Ohweh, das tut weh.
Generell, die ganze Begeisterung – Daten werden wichtiger als Code werden, mit Gibson-Zitaten, etc.pp. – das haengt sicher auch mit meiner romantischen Vergangenheitsverklaerung zusammen, aber da kommt schon ein wenig Nostalgie auf 😉
Ab 44:36 kommt eine hervorragende Frage: Jetzt taucht da ein Katalog mit Daten auf – ist das langfristig nicht sowas wie es Webkataloge vor Websuchmaschinen waren? Sollte das nicht alles von Maschinen erfassbar und bearbeitbar sein anstatt haendisch? Pollock erklaert ein bisschen herum, aber in dem Austausch ist IMO ein Kernproblem der ganzen Datenportale bis heute sehr klar vorhergesehen.
Vor allem auch: Wer vertritt all diese Visionen heute ueberhaupt noch, um eher industriegetriebenen Memes wie dem „Datenraum“ etwas entgegenzuhalten? Wo bleibt das Zukunftsversprechen von Linked Open Data, so dass ich morgens nur einen Update-Befehl ausfuehren muss, um das (versionierte, aktuelle) Paket z.B. fuer die Impfdaten des RKI zu bekommen?
Im Sueden dauert ja alles ein wenig laenger, was das Netz angeht — moechte man meinen. Alles findet nur in Berlin statt — moechte man meinen. Dieses Wochenende haben wir einmal beschlossen, einfach mal dagegenzuhalten. Und das im beschaulichen Ulm. Sportlich, aber es scheint aufzugehen 😉
Zugegeben, die Runde war ueberschaubar. Und eigentlich mit weniger TeilnehmerInnen, als ich mir erhofft und erwuenscht hatte, was nicht zuletzt wegen der wirklich grandiosen Fruehstuecks- und Mittagsbuffets (Danke an die MFG und die Stadt fuer das Sponsoring!) und des spontan parallel gebackenen Apple Crumble schade war. Impulse gab es jedoch nicht zu knapp.
Eine Veranstaltung, bei der Internet und WLAN funktioniert ist keine richtige Veranstaltung. #occulm12
Erst einmal kam jedoch der Treppenwitz jeder Netzveranstaltung: Das WLAN ging nicht. Nach Telefoniererei mit dem kiz-Helpdesk stellte sich das als Copy&Paste-Problem heraus und es gab kurzerhand einen neuen Gastzugang. Danke an die uulm, bei der sowas auch wochenends funktioniert 😉
Ich bin nach dem ersten Tag auch ganz gluecklich ueber die Sessions. Meine persoenlich groesste Befuerchtung (noch vor der Teilnehmerzahl) als Barcamp-erst-Mitveranstalter war, dass am Ende nur langweilige Sessions auf dem Plan stehen wuerden. Dem war nicht so, und Barcamp-typisch ergaben sich auch abends noch viele Randdiskussionen.
Vorher kamen jedoch die eigentlichen Sessions, die von Einfuehrungen in Linked Open Data ueber das Apps4De-Gewinnerprojekt LISA, Praxisbeispielen aus Friedrichshafen, Verkehrsumfragen und freie Funknetze bis zum Austausch ueber den OpenData-Portal-Prototypen des Landes und Anwendungen im OPNV reichten. Alle Sessions mit mehr oder weniger vollstaendigen Mitschrieben finden sich in unserem EduPad (aktuell noch mit Zertifikatswarnung, sorry hierfuer)
Eines kann man auch nicht ohne Stolz sagen: Ulm und die Region sind am Ball. Genauer gesagt sind wir in der etwas absurden Situation, jeder Menge Offenheit und Bereitschaft zu Datenoeffnung zu begegnen, aber gar nicht genuegend EntwicklerInnen und AnwenderInnen zu haben, um auch praktisch aus allen Quellen machen zu koennen. Nicht zuletzt deswegen wollten wir hier auch die Keimzelle zu etwas weiterem Wachstum der datalove-Arbeitsgruppe (oder Daten-EinzelkaempferInnen) saeen.
Und wie immer ist ein Barcamp erst endgueltig vorbei, wenn keineR mehr Lust hat, noch dazubleiben. Momentan ist kurz nach 2300 Uhr, und hier sitzen nach dem Sofa-Abendausklang bei Apple Crumble immer noch Leute vor ihren Laptops und hacken Dinge.
An offenen Daten der Region koennen wir derweil momentan nicht allzuviel machen: Wenn schon das WLAN funktioniert, muss natuerlich tatsaechlich das OpenData-Portal des Landes ausfallen — in dem auch die Haushaltsdaten liegen, die ich gerne weiter aufbereitet haette. Mal sehen, ob wir die bis morgen irgendwie aufgetrieben bekommen.
Passenderweise faellt soeben das OpenData-Portal BaWue aus. @wi00194 ruft kurzerhand den T-Systems-Teamleiter an :> #occulm12
