Schlagwort-Archiv: linked open data

Was heisst eigentlich „maschinenlesbar“ – und weiss das auch der Gesetzgeber?

Schreibe eine Antwort

Wenn man sich durch Gesetzestexte rund um Daten und ihre Verfuegbarkeit graebt, faellt einem irgendwann auf, dass da zwar von „Daten“ und auch „maschinenlesbaren Daten“ geschrieben wird – damit aber ganz unterschiedliche Bedeutungen verbunden sein koennen. Vor ein paar Wochen ist mir das wieder aufgefallen, als ich eine kleine Anfrage zum Stand von Linked Open Data in Hamburg (Drucksache 23/1881) zugeschickt bekam, die „maschinenlesbar“ geradezu wahllos interpretiert hatte.

In „Open Data, wie es zu Covid haette sein koennen“ bin ich im Januar 2022 schon ein wenig auf die verschiedenen Ebenen von Maschinenlesbarkeit eingegangen. Damit ich das nicht alles wiederholen muss, empfehle ich, den Artikel vorher zu lesen. Ich warte solange 🙂

Beim Blick in Gesetze fallen nun verschiedene Definitionen fuer Maschinenlesbarkeit auf. Manchmal steht da gar nichts dazu (aber immerhin in der Gesetzesbegruendung, so wie beim EGovG), manchmal gehen die Definitionen mehr ins Detail:

Die Behörden des Bundes mit Ausnahme der Selbstverwaltungskörperschaften stellen unbearbeitete maschinenlesbare Daten, die sie zur Erfüllung ihrer öffentlich-rechtlichen Aufgaben erhoben haben oder durch Dritte in ihrem Auftrag haben erheben lassen, zum Datenabruf über öffentlich zugängliche Netze bereit.

§ 12a EGovG

Im Sinne dieses Gesetzes […]
3. sind Daten vorhandene Aufzeichnungen, unabhängig von der Art ihrer Speicherung, […]
5. liegt ein maschinenlesbares Format vor, wenn die Daten durch Software automatisiert ausgelesen und verarbeitet werden können,
6. ist offenes Format ein Dateiformat, das nichtproprietär und plattformunabhängig ist und der Öffentlichkeit ohne Einschränkungen, die der Nutzung von Daten hinderlich wären, zugänglich gemacht wird,
7. ist förmlicher offener Standard ein in Textform niedergelegter Standard, in dem die Anforderungen für die Sicherstellung der Interoperabilität der Software niedergelegt sind,

§ 3 Nr. 3 und 5–7 DNG

Im Sinne dieses Gesetzes ist
1. ein maschinenlesbares Format ein Dateiformat, das so strukturiert ist, dass Softwareanwendungen bestimmte Daten, einschließlich einzelner Sachverhaltsdarstellungen und deren interner Struktur, leicht identifizieren, erkennen und extrahieren können,
2. ein offenes Format ein Dateiformat, das plattformunabhängig ist und der Öffentlichkeit ohne Einschränkungen, die der Weiterverwendung von Informationen hinderlich wären, zugänglich gemacht wird,
3. ein anerkannter, offener Standard ein schriftlich niedergelegter Standard, in dem die Anforderungen für die Sicherstellung der Interoperabilität der Software niedergelegt sind.

§ 5 Abs. 3 LTranspG Rheinland-Pfalz

Das koennte man amuesant finden, sorgt aber in der Praxis bisweilen zu ganz unterschiedlichen Auslegungen auch der Verwaltung beim Vollzug, was denn nun damit vom Gesetzgeber gemeint war. Und damit auch fuer eine sehr unterschiedliche Wiederverwendbarkeit: Kann ich diese „Daten“ auch ohne grossen Aufwand weiterverarbeiten, oder muss ich erst einmal viel Energie investieren, um sie in eine nutzbare Fassung zu bringen?

Diese Begriffsvielfalt ruehrt vermutlich auch von der Doppeldeutigkeit her, mit der wir im Alltag von „Daten“ sprechen. Wenn man nachfragt, was damit eigentlich gemeint ist, laeuft es meistens auf eine von zwei Definitionen hinaus:

  1. Irgendwas, was digital gespeichert ist und von einer Maschine interpretiert und dargestellt werden kann
  2. Eine Menge von Sachverhalten, die maschinell und automatisiert ausgewertet werden kann

Diese Unterscheidung sieht auf den ersten Blick etwas haarspalterisch und detailverliebt aus. Bei genauerem Hinsehen eroeffnet das aber ein besseres Verstaendnis fuer die fundamentalen Missverstaendnisse, die daraus im Alltag entstehen koennen – aber auch in der Gesetzgebung.

Sichtweise 1: Alles, was als Bits und Bytes daherkommt, sind Daten (Daten als Symbole)

Das ist die Trivial-Interpretation des Daten-Begriffs, die immer noch erstaunlich weit verbreitet ist. Auf der Smart-Country-Convention lauschte ich 2025 einem Panel zu Open Data, auf dem einer der Diskutanten behauptete, dass man ja den Fokus bei Open Data nicht nur auf „Daten-Daten“ richten sollte, sondern man koenne ja auch mit „Text-Daten“ arbeiten, weil das koenne ja kuenftig alles „die KI“ richten.

Dass man sowas auf solch einem Panel sagen kann, ohne irgendeinen Einspruch gegen die These oder die Erfindung des Begriffs „Daten-Daten“ zu erfahren, ist fuer sich schon beachtlich. Andererseits erklaert die weite Verbreitung dieser Vulgaerdefinition von Daten aber sowohl die teilweise sinnentstellende Verwendung von „Maschinenlesbarkeit“ als auch die Erwartung an „KI“ – gemeint waren hier wohl Spielarten von LLM – als Heilsbringer.

Konkret bis zum Ende durchgedacht, faellt mit der Definition „alles, was als digitale Symbole vorliegt, sind Daten“ naemlich auch der Begriff der Maschinenlesbarkeit in sich zusammen. In diesem Bild geht es allein darum, dass irgendetwas von der Maschine binaer entgegengenommen und dann auf irgendeine Weise einer Person dargestellt wird. Eine MP3 mit einem Musikstueck: Daten. Ein Foto: Daten. Eine eingescannte Tabelle, die dann als Bild in eine Worddatei eingefuegt wird: Daten. Dieselbe Word-Datei, als PDF ausgegeben (aber immer noch nur mit einem Scan der Tabelle): Daten.

Mit dieser Definition wird jede digitale Zeichenkette, die nicht gerade zufaelliges Rauschen ist, sondern auf irgendeine Weise als Dateiformat interpretiert und dargestellt werden kann, zu „Daten“. Das ist maximal die unterste Stufe der 5-Sterne-Definition fuer offene Daten: Ich kann das Ding ueber Computernetzwerke verschicken, ein Rechner kann es irgendwie darstellen, aber eine maschinelle Auswertung einzelner Sachverhalte darin bedarf einer menschlichen Interpretation.

Vermutlich kommt daher auch die Begeisterung fuer „die KI“: Nachdem man Sachverhalte ueber Jahrzehnte in Schrottformaten hin- und hergeschoben hat, die laufend menschlicher und haendischer Interpretation beduerfen und bei denen die automatisierte Weiterverarbeitung hoechst muehsam ist, haben wir jetzt eine Silver Bullet, die das bestimmt alles loesen wird. Also, zwar nicht deterministisch, sondern auf stochastischen Methoden basierend, aber es wirkt am Ende so, als komme ein Ergebnis heraus. Schliesslich schlaegt einem „die KI“ das voller Ueberzeugung vor.

Sichtweise 2: Daten als maschinell verarbeitbare Sachverhalte oder Fakten

Diese Sichtweise steht im Fuenf-Sterne-Modell fuer die Stufen 3–5: Es reicht nicht mehr, dass das Dokument nur irgendwie darstellbar ist, sondern es muessen auch einzelne Sachverhalte maschinell auswertbar sein. Das ist der Wortlaut, der sich beispielsweise im oben zitierten Landestransparenzgesetz RLP findet. Der Begriff „Daten“ steht damit nicht mehr fuer „da ist irgendwas binaer gespeichert“, sondern fuer „eine Menge von Sachverhalten, die eine Maschine ohne weiteres Zutun erkennen und auswerten kann“.

In der Praxis heisst das folgerichtig mindestens, dass auch einzelne Sachverhalte maschinenlesbar codiert sein muessen – das ist die etwas umstaendliche Definition von „eine Tabelle ist nicht nur ein Scan oder im PDF codiert, sondern liegt als weiterverarbeitbares CSV vor“. Idealerweise geht die „Identifizierung und Erkennung von Sachverhaltsdarstellungen“ durch Software aber noch weiter: Mit Linked-Data-Prinzipien koennen auch semantische Zusammenhaenge maschinell auswertbar codiert werden. Mehr dazu wie oben angerissen im Open-Data-bei-Covid-Artikel von vor vier Jahren.

Eselsbruecke: Nicht ueber Daten sprechen

Was ich gerne vorschlage, wenn Begriffe (z.B. „Digitale Souveraenitaet“ *hust) von verschiedenen Leuten ganz unterschiedlich und sich widersprechend verwendet werden, ist eine Runde Tabu zu spielen: Lass mal darueber diskutieren, aber niemand darf „Daten“ sagen.

Das hat mir geholfen, die altbekannte DIKW-Pyramide ein wenig anzupassen. Die schlaegt urspruenglich eine Hierarchie vor, wie man von „Data“ ueber „Information“ und „Knowledge“ zu „Wisdom” kommt. Da „Data“ aber jetzt verboten ist, ersetzen wir das durch „Facts“:

Bearbeitung nach Longlivetheux: DIKW Pyramid, CC BY-SA 4.0

Zusaetzlich fuehren wir eine Y-Achse ein, die angibt, welche Ebene der Pyramide in Symbolen (also Bits und Bytes, als Ersatzbegriff fuer diese Definition von „Daten“) codiert ist. Das Beispiel des Scans einer Tabelle als Foto in einem PDF liegt digital vor, es handelt sich aber um Informationen fuer menschlichen Konsum, deren weitere maschinelle Verarbeitung einer Aufarbeitung bedarf. Wenn man genAI-Bro ist, kann man natuerlich sagen, dass einem das Lieblingssprachmodell das alles nach Excel uebersetzen kann. Das ignorieren wir aber mal, denn so eine Tabelle lag ja bereits einmal als Spreadsheet vor, vielleicht sogar im CSV-Format.

Wenn wir die Tabelle bekommen, sind einzelne Fakten oder Sachverhalte maschinell auswertbar und verarbeitbar. Ich muss zwar immer noch zuordnen, was in welcher Spalte zu finden ist und ggf. auch Einheiten zuordnen (stehen die Zahlen in Spalte F fuer Minuten oder fuer °C, bzw. welche Spalten von Zahlen und damit verbundenen Einheiten gehoeren logisch zusammen?), ich muss aber diese Sachverhalte nicht mehr fuer die Weiternutzung erst aufbereiten.

Exkurs: Ich habe mittlerweile auch wirklich eine Abneigung gegen den Begriff der „Veredelung von Daten“ entwickelt. Der ist eng mit der Behauptung von Daten als dem neuen Oel verbunden, die Clive Humby 2006 in die Welt gesetzt hatte: Wie Rohoel seien „Rohdaten“ an sich wenig nuetzlich, aber durch ihre „Veredelung“ koenne eine Vielzahl wertvoller Produkte geschaffen werden. Der Vergleich ist ohnehin aus vielen Gruenden total Banane, wenn man mehr als fuenf Minuten ueber ihn nachdenkt: Daten sind anders als Oel nicht-rivalisierende Gueter, sie verbrauchen sich nicht etc.pp. Und genauso ist es stets eine Entscheidung, auf welche Weise man Informationen speichern kann: Niemand wird gezwungen, „Daten“ erstmal als Rohoel oder Klaerschlamm oder Rizinusoel zu speichern, das man erst einmal irgendwie kompliziert „raffinieren“ muss. Man kann’s halt auch gleich von Anfang an moeglichst „raffiniert“ speichern, himmihergottnochamal.

So, geht schon wieder. Die von vorneherein „edle“ Speicherung bringt uns dann naemlich dazu, auch Semantik zu codieren und Linked-Data-Prinzipien zu verwenden. Damit werden die Zusammenhaenge zwischen Faktentupeln so codiert, dass sie als propositionales Wissen nach Regeln der Logik maschinell auswertbar sind – und im Gegensatz zu Sprachmodellen geht das deterministisch (es kommt jedes Mal dasselbe raus und nicht einmal dies und einmal das) und ohne dafuer Energiemengen ganzer Volkswirtschaften einfach so mal eben zu verbraten.

PS zu diesem Abschnitt: Ich bin heute nicht so ganz gluecklich damit, dass ich beim Zusammenbasteln der Darstellung das PDF auf Stufe 2 der angepassten DIKW-Pyramide gesetzt hatte. Das ergibt nur dann Sinn, wenn man diese „Information“-Stufe als „normalerweise nur durch Menschen auswertbar“ annimmt – oder eben zulaesst, dass man Sprachmodelle draufwirft, womit die maschinelle Auswertung hier aber im Gegensatz zu allen anderen Stufen nicht mehr deterministisch passieren kann.

Und was sagen jetzt der Gesetzgeber und die Verwaltung?

Ganz unterschiedliche Sachen. Das EGovG definiert den Begriff im Gesetz gar nicht, das Datennutzungsgesetz ist… interpretationsoffen, je nachdem, wie man interpretiert, ob „Daten“ nun Symbole oder Sachverhalte sind. In der Gesetzesbegruendung wird die Wichtigkeit von Maschinenlesbarkeit mit Verweis auf die Europaeische Open-Data-Richtlinie hervorgehoben und auch eine ausfuehrlichere Definition mit Verweis auf Erwaegungsgrund 35 der Open-Data-Richtlinie ausgefuehrt – dort steht naemlich:

Ein Dokument sollte als maschinenlesbar gelten, wenn es in einem Dateiformat vorliegt, das so strukturiert ist, dass Softwareanwendungen die konkreten Daten einfach identifizieren, erkennen und extrahieren können. Daten in Dateien, die in maschinenlesbarem Format strukturiert sind, sollten als maschinenlesbare Daten gelten. Ein maschinenlesbares Format kann offen oder proprietär sein. Es kann einem formellen Standard entsprechen oder nicht. Dokumente, die in einem Dateiformat kodiert sind, das eine automatische Verarbeitung einschränkt, weil die Daten nicht oder nicht ohne Weiteres aus ihnen extrahiert werden können, sollten nicht als maschinenlesbar gelten. Die Mitgliedstaaten sollten die Anwendung in der Union oder international anerkannter offener, maschinenlesbarer Formate — wo dies möglich und angemessen ist — fördern. Bei der Entwicklung technischer Lösungen für die Weiterverwendung von Dokumenten sollte gegebenenfalls der europäische Interoperabilitätsrahmen berücksichtigt werden.

Erwaegungsgrund 35 der Richtlinie (EU) 2019/1024

Das ist leider auch nicht so einfach verdaulich. Die Open-Data-Richtlinie spricht allgemein von „Dokumenten“ (egal in welcher Form) im Besitz oeffentlicher Stellen, d.h. vom Papierdokument ueber die Fachverfahrensdatenbank und andere digital codierte Dokumente bis zu einer Steintafel kann damit alles gemeint sein (Artikel 2 Nr. 6). „Daten“ werden nicht ausdruecklich definiert, durch die Definition der Maschinenlesbarkeit in Artikel 2 Nr 13 in Verbindung mit den Erwaegungsgruenden liegt aber nahe, dass damit die Definition „Daten als Sachverhalte“ innerhalb von Dokumenten gemeint ist:

Im Sinne dieser Richtlinie bezeichnet der Ausdruck […]
13. „maschinenlesbares Format“ ein Dateiformat, das so strukturiert ist, dass Softwareanwendungen konkrete Daten, einschließlich einzelner Sachverhaltsdarstellungen und deren interner Struktur, leicht identifizieren, erkennen und extrahieren können;

Ein Dokument kann also auch digital vorliegen, und Sachverhalte darin sind „Daten“. Warum man das nicht 1:1 so wie in der Open-Data-Richtlinie bzw. der Gesetzesbegruendung ins DNG und EGovG geschrieben hat, weiss ich auch nicht. Das DNG verwendet den „Daten“-Begriff in § 3 direkt nacheinander so, wie die Open-Data-Richtlinie zuerst „Dokumente“ und dann „Sachverhalte“ bezeichnet. Das ist unnoetig verwirrend und mir ist nicht klar, ob dahinter eine Absicht steckte oder ob das ein Unfall war.

Diese Unschaerfe hatte offenbar mittlerweile Folgen, weil andere wiederum das DNG als Vorlage fuer weitere Gesetze verwendet haben. Oben hatte ich § 5 LTranspG Rheinland-Pfalz zitiert, das woertlich die Definition aus PSI- bzw. Open-Data-Richtlinie mit den Sachverhalten uebernommen hatte. Meiner Lesart nach haette man dieses Landestransparenzgesetz ohne Probleme anpassen koennen, um damit auch Open Data abfruehstuecken zu koennen. Die Landesregierung hatte sich aber ohne Not dazu entschlossen, ein eigenes Open-Data-Gesetz zu stricken, weil sie zwischen Dokumenten „fuer menschlichen Konsum“ und Daten „fuer maschinelle Verarbeitung“ unterscheiden wollten. Dort steht als Definition nun nur mehr:

Daten sind vorhandene Aufzeichnungen, unabhängig von der Art ihrer Speicherung. […]
Maschinenlesbar sind Daten, wenn sie in einem Format vorliegen, das ihre automatisierte Auslesung und Verarbeitung durch Software ermöglicht.

§ 3 ODGRP

Der Gesetzesentwurf und seine Begruendungen sind noch an vielen anderen Stellen hanebuechen (ich durfte das auf Arbeit kommentieren und es fiel mir schwer, freundlich zu bleiben). Die Gesetzesbegruendung (PDF, Seite 36 „zu Absatz 4“) legt nahe, dass beim Entwurf Leute die Formulierungen aus dem DNG abgekupfert haben, ohne sie so ganz zu verstehen – so auch bei der Begruendung auf Seite 24, warum das schon alles so seine Richtigkeit habe weil’s ja ans DNG angelehnt sei. Dass dann auch noch davon gesprochen wird, dass Offene Daten deswegen so wertvoll seien, weil sie Grundlage fuers Training generativer KI-Modelle sein koennten, passt perfekt zum Rest des Gesetzes.

Grosse Teile der Antworten auf die kleine Anfrage in Hamburg, die Ausloeser fuer diese Ueberlegungen war, kann ich mir auch nur so erklaeren: Irgendwo hat man Definitionen gelesen, was „Daten“ und „maschinenlesbar“ sein soll, interpretiert dann das hinein, was sich auf die eigenen Vorstellungen mappen laesst und spielt reihenweise Fluesterpost, an deren Ende dann halt auch mal wirklicher Unsinn rauskommt. Verwaltungsdigitalisierung als Hoehlengleichnis oder so.

Was lernen wir daraus?

  • Die Definitionen in der Open-Data-Richtlinie sind ganz okay…
  • …wurden aber in EGovG und DNG ziemlich schludrig uebersetzt, so dass die Interpretation des Sinnzusammenhangs eigene praktische Erfahrungen im Umgang mit „Daten“ erfordert (also maschinelle Verarbeitung von Sachzusammenhaengen, nicht nur „Powerpoint und Excel klicken“)
  • andere schreiben nun wiederum vom DNG ab
  • vermutlich ohne die Definitionen in der Open-Data-Richtlinie verstanden zu haben
  • das fuehrt zu seltsamen Antworten und unnoetigen Gesetzen und generell der Verfestigung von Bloedsinnsideen wie der Unterscheidung von „Textdaten und Daten-Daten“
  • man sollte sagen koennen, was man meint, ohne den Begriff „Daten“ zu verwenden (als lustige Uebung fuer zwischendurch)
  • (man sollte vielleicht auch mehr rausgehen oder in eine Huette im Wald ziehen)
  • (aber das hat nichts mit dem Datenbegriff zu tun)
  • auf jeden Fall sollten beim Staat viel mehr Leute arbeiten, die praktische Erfahrungen mit all diesem Zeug haben, damit sie bessere Gesetze dafuer schreiben und es besser praktisch in die Tat umsetzen koennen
  • es koennte sich lohnen, die Formulierung im DNG nochmal zu praezisieren, damit da nicht weiter schludrig abgeschrieben wird
  • alternativ (und langfristig sicher auch sinnvoll) koennte man diejenigen, die sowas schludrig abschreiben und sich nicht auskennen, sowas nicht mehr machen lassen sondern sie z.B. rausschicken oder in eine Huette im Wald ziehen lassen.
Aufnahme eines Betonbaus als Zugang zu einer Tiefgarage, darueber ein Sparkassen-Lichtreklamen-Logo

Wo sind Sparkassen nahe an Tiefgaragen – Schoener leben mit Linked Open Data

Eine Antwort

Wenn man (aus welchen Gruenden auch immer) wissen wollte, wo in der Gegend Sparkassen nahe an Tiefgaragen liegen, dann liegt es natuerlich sehr nahe, auszurufen „aha, das ist ein Fall fuer Open Data!“ und damit auch gleich ziemlich richtig zu liegen.

Titelfoto: Peter Nath, 2014 09 21 OG Sparkassenareal und noerdl Innenstadt 34, CC BY 4.0

Mit der Overpass-API lassen sich naemlich nicht nur Features – wie zum Beispiel Hydranten – aus OpenStreetMap abfragen, man kann auch komplexere Abfragen nach Dingen in einem bestimmten Abstand zu anderen Dingen dort machen. Die Beispielliste fuehrt lustigerweise ein Query nach Banken auf, die weit weg von Polizeistationen liegen. Das laesst sich fuer unseren Zweck natuerlich leicht anpassen.

So sah meine schnell zusammengeschusterte Abfrage nach Banken aus, die maximal 30 Meter um eine gemappte Tiefgarage liegen:

[out:json][bbox:{{bbox}}][timeout:25];
// gather results
//nwr["amenity"="bank"]["name"="Sparkasse"]->.sparkassen;
nwr["amenity"="bank"]->.banken;
nwr["parking"="underground"]->.tiefgaragen;

nwr.banken(around.tiefgaragen:30);
// print results
out geom meta;

He warte, wir wollten Sparkassen!

Aber Moment mal: Das filtert doch nach allen in OpenStreetMap verzeichneten Banken, nicht nur nach Sparkassen! Ja, richtig – in der Zeile obendrueber ist ein Filter, der nur die Banken beruecksichtigt, die „Sparkasse“ heissen. Aber der beruecksichtigt eben nur Banken, die exakt Sparkasse in genau dieser Schreibweise heissen.

Manche Sparkassenfilialen sind in OpenStreetMap auch einfach nur als Sparkasse getaggt, andere heissen so wie die jeweilige Kreis- oder Stadt- oder sonstige Sparkasse. Ob name = Sparkasse Neu-Ulm - Illertissen (Brückenhaus) schon zu ausfuehrlich ist, mag ich nicht beurteilen. Wenn man alle Banken sucht, in deren name Sparkasse vorkommt, koennte man die Abfrage mit einem Regulaeren Ausdruck bauen, beispielsweise mit einer Suche nach nwr["amenity"="bank"][name~".*(S|s)parkasse.*"]. Das Problem dabei: Solch eine Anfrage an die Overpass-API laeuft schnell in einen Timeout, sobald der abzufragende Kartenausschnitt etwas groesser ist.

Der Unterschied zwischen Namen, Betreiber und Marke

Beim Blick auf den Screenshot oben mit der Filiale am Brueckenhaus faellt aber der Key operator= auf, in dem hier explizit die Sparkasse Neu-Ulm – Illertissen (mit exakt diesem etwas seltsam aussehenden Namen) als Betreiberin eingetragen war. Und wenn man das Tagging-Schema fuer Banken genauer betrachtet, wird dort der Key brand= vorgeschlagen, mit dem die „Marke“ einer Einrichtung angegeben werden kann.

Das vereinfacht die Suche nach bestimmten Banken, ohne irgendwelche Wildcard-Suchen auf den Namen machen zu muessen – wenn die Bank denn ausfuehrlich getaggt worden ist:

  • name bezeichnet den Eigennamen genau dieser Bankfiliale. Vielleicht reicht hier eh nur „Sparkasse“, andere schreiben sonst noch was dazu, so ist das eben in OSM.
  • operator ist die Betreiberin – hier eben die jeweilige oeffentlich-rechtliche Sparkasse mit ihrem Kreis- oder Stadt- oder sonstigen Namen
  • brand ist die (Dach)Marke der Bank – und das ist hier tatsaechlich immer „Sparkasse“

Ist „Aldi Sued“ dasselbe wie „ALDI SÜD“?

Alles erledigt, jetzt koennen wir filtern, wuerde man meinen – oder? Die deutschsprachige Beschreibung von brand weist aber darauf hin, dass der Markenname gemaess der jeweiligen Namenskonventionen eingetragen werden soll. Als Beispiel: Aldi-Supermaerkte werden im Name-Tag als „Aldi“ oder „Aldi Nord“ oder „Aldi Sued“ getaggt. Die Schreibweise der Marke sei jedoch „ALDI Nord“ oder „ALDI SÜD“. Das muss man natuerlich dann erst einmal wissen, sowohl beim Tagging als auch bei der Abfrage.

Mit Linked Open Data ist aber auch dieser Fallstrick ueberhaupt kein Problem mehr, und sowohl die Wiki-Beschreibungen von brand als auch von operator verweisen jeweils auf die optionalen Keys operator:wikidata und brand:wikidata, mit denen beiden die eindeutige Wikidata-ID zugewiesen werden kann. Fuer eine Sparkassenfiliale kommt also neben brand=Sparkasse einfach brand:wikidata=Q13601825 dazu. Und schon lassen sich tatsaechlich nur Sparkassen anzeigen, die nahe an Tiefgaragen liegen – sofern denn brand und wikidata-ID der Marke getaggt wurden:

[out:json][bbox:{{bbox}}][timeout:25];
// gather results
nwr["amenity"="bank"]->.banken;
(
  nwr.banken["brand"="Sparkasse"];
  nwr.banken["brand:wikidata"="Q13601825"];
)->.sparkassen;
nwr["parking"="underground"]->.tiefgaragen;

nwr.sparkassen(around.tiefgaragen:30);
// print results
out geom meta;

(Randbemerkung, weil ich die letzten Stunden Wikidata-IDs und operators und brands auf OpenStreetMap nachgetragen habe: Fuer Sparkassen ist das schoen aufdroeselbar. Bei Genossenschaftsbanken, die mal als „Volksbank“, mal als „Raiffeisenbank“ firmieren und fuer die es keine Wikidata-ID fuer die jeweilige „Marke“ zu geben scheint, wird das schon wieder komplexer. Ein neues Rabbit Hole!)

Hydrantenmapping in OpenStreetMap – Schoener leben mit Fast-Linked-Open-Data

Eine Antwort

Ich hatte neulich zweieinhalb Wochen Urlaub und bin dabei unvermittelt in eine ganze Reihe von Rabbit Holes gefallen, in die ich mich ueber den Urlaub hinweg reingegraben habe. Das ueberrascht niemanden, die/der mich kennt, aber ich fand die Zusammenhaenge dazwischen so spannend, dass ich das mal aufschreiben wolle.

Alles fing mit einem Abend in der Feuerwehr an. Wir sollten ueber mehrere Abende alle Hydranten im Ortsgebiet anfahren, kontrollieren, spuelen und – wo noetig – Maengel aufschreiben. Fehlt ein Hinweisschild eines Unterflurhydranten, laesst sich ein Hydrant nicht vernuenftig oeffnen – oder aber auch, sind neue hinzugekommen, die wir nicht in unserem Hydrantenplan haben. In einer idealen Welt gaebe es natuerlich einen gut funktionierenden Austausch zwischen Gemeinde, Wasserversorger und Feuerwehr, so dass alle immer denselben Zustand dokumentiert haben. Aber ich muss ja niemandem erzaehlen, dass wir nicht in einer perfekten Welt leben.

Wo sind Hydranten – von analog zu digital?

Als ich 1999 zur Feuerwehr kam, bestand der Hydrantenplan aus einer fotokopierten Ortskarte, in die mit roter und blauer Farbe die Ueber- und Unterflurhydranten haendisch hineingemalt worden waren. Kurz darauf erstellten zwei Kollegen quasi ein „Lookbook“, in dem jeder der Hydranten mit einem Foto des Umfelds und einer kurzen Beschreibung je eine Karteikarte in einem Ordner bekam, die dann alle alphabetisch nach Strassennamen sortiert waren.

Beide Ansaetze haben Vor- und Nachteile: Bei der Uebersichtskarte sieht man stets den geographischen Kontext – gerade Unterflurhydranten tarnen sich aber gelegentlich recht gut in ihrer Umgebung, so dass man sie nicht immer leicht findet. Das Umfeldfoto hilft beim Auffinden, dafuer kann man ohne eine Kontext-Karte umliegende andere Hydranten uebersehen, die in einer anderen, aber nahen Strasse liegen.

Wegen eines anderen Urlaubs-Rabbitholes kam ich daher recht schnell auf die Idee, Umfeldfotos und Karte mit Koordinaten zu verbinden – und was laege da naeher, als eine gute Vermessung mit Hilfe von OpenStreetMap und Wikimedia Commons!

Die ersten Hydranten habe ich ganz klassisch nur per Smartphone positioniert. Da wir im temporaerhaus aber seit diesem Jahr einen echtzeitkinematikfaehigen simpleRTK2B-GNSS-Empfaenger samt passender Antenne haben, wollte ich das natuerlich etwas genauer haben 😉 Und so kam es zu einem unvorhergesehenen Projekt zwischen temporaerhaus und Feuerwehr Altenstadt.

Und was mappt man da?

RTK-Mapping: Positioniere Antenne ueber Hydranten, warte auf RTK-Fix, trage Position und Tags in OSM ein. Links ein alter Erhard-Ueberflurhydrant, rechts ein Unterflurhydrant.

Eigentlich alles, was in emergency=fire_hydrant auf OSM beschrieben ist. Um moeglichst alles abzudecken, kann man recht einfach zwischen Tags fuer alle Hydranten und Erweiterungen jeweils fuer Ueber- und Unterflurhydranten unterscheiden:

Fuer alle Hydranten

refDie Hydrantennummer auf dem Hinweisschild oder dem Hydranten selbst – sofern vorhanden
fire_hydrant:pressureDas laesst sich quasi nie ermitteln, d.h. hier einfach yes
fire_hydrant:positiongreen fuer Gruenflaeche, lane fuer die Fahrbahn, sidewalk fuer den Gehweg und parking_lot fuer Parkplaetze. Insbesondere bei Unterflurhydranten ist es super gut zu wissen, ob er auf einer Parkflaeche liegt!
water_sourcein der Regel main, also die abhaengige Loeschwasserversorgung
survey:dateDas Datum, an dem du diesen Hydranten eingetragen hast, YYYY-MM-DD
Auf solch einem Hinweisschild ist normalerweise haeufig eine Identfikationsnummer zu sehen. Hier aber leider nicht. Immerhin laesst sich der Leitungsdurchmesser 80 mm durch das „80“ rechts vom „H“ ablesen.

Speziell fuer Unterflurhydranten

fire_hydrant:typeunderground
fire_hydrant:diameterDas ist der Wert auf dem zugehoerigen Hydrantenschild – sofern das vorhanden ist! Falls keines vorhanden ist, siehe…
fire_hydrant:diameter:signed=noWenn kein Hinweisschild vorhanden ist. Dadurch lassen sich auch leicht die Hydranten ohne Schilder spaeter ermitteln

Speziell fuer Ueberflurhydranten:

fire_hydrant:typepillar
couplingsDie Anzahl der Festkupplungen, z.B. 2 oder 3
couplings:typeHier in der Regel storz
couplings:diametersNach den deutschen Kupplungsbezeichnungen, z.B. B;B oder B;B;A oder gar C;C;B (ja, das gibt es, und das festzustellen, ist spannend!)
manufacturer…irgendwann lernt man dann auch die Hersteller anhand der Logos oder Aufschriften zu unterscheiden und kann entweder den Hersteller oder die Wikidata-ID des Herstellers eintragen…
Links ein alter VAG-Hydrant mit „DN 80“ im Guss, rechts ein Erhard-nach-1996-Hydrant mit „DN 80“ auf dem Typenschild – das sagt aber nichts ueber die Versorgungsleitung aus.

Zu beachten bei Ueberflurhydranten: Die haben zwar bisweilen auch einen Rohrdurchmesser angegeben – bei den alten Hydranten im Guss im Hydrantenkoerper, bei den neueren auf den Typenschildern ausgewiesen. Dieser Durchmesser gilt aber nur fuer das Steigrohr, nicht fuer die Wasserversorgung selbst. Im OSM-Wiki wird daher davon abgeraten, diesen Durchmesser als Leitungsdurchmesser zu taggen!

Auch nur eine Karte – aber auswertbar

Darstellung in der OpenFireMap

Zunaechst hat man damit auf den ersten Blick nicht viel gegenueber der alten handgemalten Karte gewonnen: Die Hydranten sind in OpenStreetMap eingetragen, und in Ansichten wie z.B. dem „Humanitaer“-Layer kann man sie in der gerenderten Karte auf openstreetmap.org auch anzeigen – wobei die nicht einmal zwischen Ueber- und Unterflurhydranten in der Darstellung unterscheidet.

Auf OSMHydrant oder der OpenFireMap bekommt man jedoch schon jetzt eine genauere Darstellung und bei OSMHydrant per Klick auf den Hydranten auch weitere Informationen. Damit alleine liesse sich schon auf einem Alarmmonitor im Feuerwehrhaus anzeigen, welche Wasserentnahmestellen es im Umfeld eines Einsatzorts bei einem Brandalarm gibt!

Zu beachten: Die OpenFireMap wird nur woechentlich am Dienstag aktualisiert. Von der Eintragung bis zur Anzeige im Kartenlayer kann also bis zu einer Woche vergehen.

Links ein alter VAG-Hydrant mit nur zwei C-Abgaengen und einem B-Abgang – ungewoehnliche Konstellation, die wir bei der Erhebung „Hutzelmaennchen“ genannt haben. Man beachte die Oeffnungsvorrichtung oben, die nicht einmal einen Sechskant fuer den Hydrantenschluessel Typ B hat. Rechts ein moderner VAG Nova Niro 365 mit zwei B-Abgaengen.

Die eigentliche Magie beginnt aber, wenn man die so hinterlegten Daten weiter direkt aus der Overpass-API auswertet, beispielsweise mit OverpassTurbo. Beispielsweise koennen wir uns alle Unterflurhydranten ausgeben lassen, fuer die wir angegeben haben, dass sie keinen angegebenen Leitungsdurchmesser haben – also das zugehoerige Hinweisschild fehlt:

node["emergency"="fire_hydrant"]["fire_hydrant:type"="underground"]["fire_hydrant:diameter:signed"="no"]({{bbox}});

Genauso koennen wir spaeter so alle Hydranten abfragen, als JSON exportieren und weiterverarbeiten – beispielsweise, um eine Kartei mit einer Karte pro Hydrant daraus zu erstellen. Oder aber auch, um die „besonderen“ Hydranten zu identifizieren, die beispielsweise nur zwei C-Abgaenge haben.

Und auch die Versorgung von Gebaeuden laesst sich dadurch auswerten. OSMHydrant bietet einen ersten Eindruck, indem man dort Umkreise um Hydranten zeichnen kann – das hilft schon fuer einen groben Ueberblick. In der Realitaet lassen sich Schlauchleitungen aber nicht in Luftlinie von einem Hydranten verlegen, sondern muessen Strassen folgen – und koennen z.B. auch nicht einfach eine Bahnlinie queren.

Wunderbar passend bloggte Supaplex030 genau zum Zeitpunkt der Erhebung, wie man solch eine Analyse auch mit dem freien GIS QGIS erstellen und dabei entlang von Strassenzuegen arbeiten kann. So laesst sich beispielsweise pruefen, welche Strecken beispielsweise mit einer oder zwei Einpersonenhaspeln oder dem Rollschlauchmaterial auf einem Loeschfahrzeug entlang kartierter Wege erschliessen lassen – und wo die Strecken zu weit dafuer sind. Ein Bonuslevel waere natuerlich die Verbindung mit einem Digitalen Hoehenmodell, wo eine Haspel nicht mehr so einfach bergauf gefahren werden kann – aber prinzipiell geht auch das 😉

Bonuslevel: Fotos machen!

Ein modernerer Erhard-Hydrant mit zwei B-Abgaengen, Modellserie nach 1996

Was in so einer Karte dann aber noch fehlen wuerde, ist das Umfeldfoto, wie es in der frueheren, mit Word erstellten Kartei zu finden waere. Das koennen wir aber beheben!

Wir haben beim Einmessen auch Fotos eines jeden Hydranten mit der Hauskamera aus dem Technikpool des temporaerhaus gemacht und auf Wikimedia Commons in die Kategorie Fire hydrants in Altenstadt (Iller) geladen, die ich dafuer angelegt hatte. In der OpenStreetMap lassen sich solche Fotos ueber Photo Linking mit Objekten verknuepfen. Hier habe ich jedem Hydranten ueber den Tag wikimedia_commons die jeweilige Datei zugeordnet, z.B. File:2025 Altenstadt (Iller) Hydrant Memminger Straße 54.jpg

Hydranten, die zwar schon vermessen, aber noch nicht mit einem Foto versehen sind, lassen sich natuerlich auch einfach mit Overpass Turbo abfragen – man muss die Suche lediglich erweitern, dass kein wikimedia_commons-Tag vorhanden ist:

node["emergency"="fire_hydrant"][!"wikimedia_commons"]({{bbox}});

Spaeter lassen sich diese Fotos so extrahieren und weiterverwenden. Sowohl Hydranten als auch Gebaeuden liesse sich auch ein URL zu Panoramax zuordnen, einer Freien Alternative zu Google StreetView – damit liesse sich noch mehr Kontext herstellen, aber auch die direkte Ansicht einer Adresse vom Strassenniveau aus waere auf dem Einsatzmonitor moeglich, wenn ein Alarm eingeht!

Und jetzt… verlinkt?

Schon mit diesem Informationsbestand ist deutlich mehr moeglich, als das in den bisherigen Hydrantenkartierungen meiner Feuerwehr der Fall war:

  1. Die Koordinaten sind – vor allem durch die RTK-Vermessung – viel praeziser
  2. Wir haben Metadaten zu den Schildern (oder ihrer Abwesenheit), dem Nenndurchmesser der Zuleitung (sofern erfassbar), den Abgangsgroessen und vielem mehr
  3. Wir koennen diese Informationen automatisiert weiterverarbeiten
  4. Auswaertige Kraefte koennen ohne weiteres auf diesen Bestand in OSM zugreifen
  5. und auch andere MapperInnen koennen dazu beitragen, den Bestand zu verbessern, falls z.B. irgendwo ein Hydrant errichtet wurde, den wir gar nicht auf dem Schirm hatten!

Ein typischer Einwand koennte hier sein, dass ja der Datenbestand in der OSM jederzeit boeswillig veraendert werden koennte. Das ist prinzipiell richtig. In der Realitaet kommt das aber beruhigend selten vor. Dennoch koennte es sinnvoll sein, einen eigenen, geprueften Informationsbestand vorzuhalten – der auch Annotationen haben koennte, die in OSM nicht so gedacht sind.

Ein „Tele-Hydrant“ von Hawle. Der telefoniert nicht etwa, sondern er kommt ohne Standrohr aus: Ein Rohr mit zwei B-Abgängen lässt sich einfach herausziehen.

Man koennte beispielsweise all die eingetragenen und geprueften Koordinaten fuer sich vorhalten und periodisch mit OSM vergleichen: Kam etwas hinzu, wurde etwas veraendert, muss ich das pruefen, um meinen Informationsbestand valide zu halten? Was hierfuer in meiner Gemeinde fehlt, ist eben der ref-Identifier, den OSM hier eigentlich vorsieht. Weder die Hydrantenschilder noch die Hydranten selbst haben irgendwo eine ID angegeben, mit der man den Hydranten identifizieren koennte. Zu pruefen waere hier, ob es irgendwo tatsaechlich eine offizielle Nummer gibt, die man „nur“ anbringen und dann einpflegen muesste.

Man koennte hier natuerlich Wikidata missbrauchen, alle Hydranten dort als Datenobjekte anlegen und das als Identifier nutzen – das hielte ich aber schon fast fuer eine Zweckentfremdung des Projekts. Eine eigene Wikibase-Instanz fuer die Feuerwehr, um den bestaetigten Stand festzuhalten, faende ich… lustig! Das ordne ich mal unter „Seitenprojekt des Seitenprojekts“ ein, wenn mir mal langweilig sein sollte 😀

Spannend finde ich zuletzt aber, dass die gewachsene Cottage Industry rund um „Datenverwaltung in Feuerwehren“ eine sehr unterschiedliche Haltung zu so einer Verlinkung faehrt. Einzelne Softwaresysteme erlauben wohl eine Verbindung zu OSM, andere scheinen darauf zu setzen, dass man z.B. Hydranten rein in ihrem Oekosystem pflegt, auf dass man z.B. eine Tablet-Version ihrer Software kauft, die die Anzeige dieser Daten ermoeglicht. Das Charmante am OSM-Mapping finde ich, dass man damit zumindest nach aussen jegliche dieser Lock-Ins aufbricht: Egal woher eine ueberoertliche Unterstuetzung kommt und welche Systeme sie verwendet: Wenn sie OSM auswerten kann, bekommt sie zumindest die grundlegenden, wichtigen Informationen.

Und das zeigt fuer mich wieder einmal: Die ganzen Loesungen, die auf Vermarktung und Verwirtschaftlichung ausgerichtet sind, machen das Ergebnis meist eher nur shitty. Die Erfassung aller Hydranten in einer – zugegeben, im Kernort nur um die 4000 BewohnerInnen starken – Kommune hat mich einen Mittwochabend und einen Sonntagnachmittag gekostet. Eine Befahrung fuer Panoramax waere an einem weiteren entspannten Nachmittag moeglich und haengt gerade nur daran, dass die 360°-Kamera des temporaerhaus wegen eines Defekts die letzten Wochen ausgefallen war. Wenn wir nur allen Menschen mehr Freizeit ermoeglichen wuerden, waere so viel Cooleres, Besseres moeglich. Und ganz nebenher kann man dabei lernen, verschiedene Hydrantenhersteller auf einen Blick zu erkennen und etwas ueber das Hydrantenkartell zu lernen 😀

Wer war wie oft bei Lanz? – Schoener Leben mit Linked Data

Schreibe eine Antwort
Post by @dzu@hostsharing.coop
View on Mastodon

Ich habe mittlerweile ein kleines Hobby daraus gemacht, Abfragen zusammenzustellen, die Wikidata beantworten kann, bei denen ein Sprachmodell aber regelmaessig auf die Nase faellt.

Im Februar kam beispielsweise auf Mastodon die Frage auf, wie haeufig eigentlich welche Gaeste – und vor allem von welcher Partei – in den politischen Talkshows im Fernsehen eingeladen werden. Ein anekdotischer Kurz-Ausschnitt von Bluesky wirkte so, als gebe es da eine Tendenz. Aber viel besser als Anekdoten und Tendenzen ist natuerlich, der Sache datengetrieben auf den Grund zu gehen.

Ganz schnell kam in dem Thread auch jemand auf eine SPARQL-Abfrage, die mit Hilfe von Spinach erstellt wurde: Wie haeufig wurden Menschen einer gewissen Parteizugehoerigkeit zu Markus Lanz, Staffel 17 eingeladen. Die Abfrage ist schon nicht ganz verkehrt, nur tauchen da auch noch Kommunistischer Bund, SED und PDS auf – denn PolitikerInnen koennen im Lauf der Zeit nacheinander mehrere Parteizugehoerigkeiten haben. Sarah Wagenknecht wuerde hier beispielsweise fuer mehrere Parteien zaehlen, auch wenn sie „nur“ als Vertreterin des nach ihr benannten Buendnis eingeladen war.

Darueber bin ich aber dann auf das Modellierungsschema fuer TV-Serien und die Uebersicht aktuell laufender, in Wikidata abgebildeter Serien gestolpert. Und neben damals Pauline und aktuell den Pfefferkoernern sind es vor allem die Polit-Talkshows in den oeffentlich-rechtlichen, die dort abgebildet werden.

Ich hatte mich vor allem fuer Markus Lanz interessiert, deren Presseseite abgegrast um die Sendedaten und Gaeste in eine verarbeitbare Form umzuwandeln, und mich dann nach langer Zeit einmal wieder mit OpenRefine beschaeftigt, um daraus am Rande von Mit Wikipedia unterwegs in Neu-Ulm alles vorzubereiten, um fehlende Lanz-Episoden in Wikidata nachzutragen.

Das Schoene dabei ist: Viele der Talkshowgaeste sind „Dauerbrenner“ – es ist sehr selten, dass jemand zum allerersten Mal in einer der Shows landet. Hier mal jemand von der BundesschuelerInnen-Vertretung, dort mal jemand aus der Wirtschaft, das ist sehr ueberschaubarer haendischer Aufwand, fuer diese fehlenden Personen ein zugehoeriges Wikidata-Objekt anzulegen.

Kristina Dunz 2020 bei Hart aber Fair: © Raimond Spekking / CC BY-SA 4.0 (via Wikimedia Commons), Hart aber fair – 2020-02-10-4310, CC BY-SA 4.0

Und weil Menschen wie Raimond Spekking mit beeindruckender Ausdauer Menschen und Dinge fuer Wikimedia Commons fotografieren, ist es gar nicht so unwahrscheinlich, dass eine Person in Koeln bei der Aufzeichnung von „Hart aber Fair“ Raimond vor die Linse gelaufen ist – und dann gibt es auch ein passendes Foto dazu.

Mit den nachgetragenen Episoden konnte ich also eine Top-Gaesteliste fuer Markus Lanz ausgeben lassen, fuer die vergangene „Staffel 17“ (2024/25) absteigend sortiert nach Anzahl der Auftritte dort:

Diese Liste ist immer noch nicht perfekt. Zwar wird nur die Parteizugehoerigkeit ausgegeben, die kein Enddatum hat und es wird bei mehreren Eintraegen die mit einem Preferred Rank bevorzugt. Ex-Linken-MdB tauchen nur mehr mit ihrer aktuellen Partei auf – ganz unten kommt einem aber Juergen Trittin zweimal des Weges, bei dem auch noch die Mitgliedschaft im Kommunistischen Bund auf Wikidata verzeichnet ist – ohne Enddatum.
Das koennte man ohne weiteres Zutun auch noch eingrenzen, indem nur Parteien gewertet werden, die noch existieren, also kein Aufloesungsdatum in ihrem Datenobjekt haben. Oder bei Herrn Trittin die Mitgliedschaft bei den Gruenen als Preferred Rank setzen. „Schoener“ faende ich es natuerlich, wenn dort aber auch ein Enddatum zur Mitgliedschaft stuende – dafuer fehlt mir aber leider eine einsehbare Quelle.

Drei Dinge an diesem Ansatz finde ich so schoen, dass das einfach in die Rubrik „Schoener Leben mit Linked Data“ gehoert:

1.: Linked (Open) Data ist mehr als die Summe der einzelnen Teile!

Ich konnte bei der Vervollstaendigung dieser Abfrage auf unglaublich viel Vorarbeit anderer zurueckgreifen. Angefangen vom Modellierungsschema, aber vor allem auch die Vor-Arbeit bei den Datenobjekten der jeweiligen Personen, die bereits die Parteizugehoerigkeit und viele weitere Eigenschaften mitbringen.

Ich kann so etwas natuerlich immer auch von Hand machen: Eine Liste anlegen, in der ich Personen Parteien zuordne, und dann laeuft das fuer meine Auswertung. Aber nur dort. Und wenn jemand mal die Partei wechselt, muss ich das entsprechend anpassen. Oder, noch schlimmer, Faelle abfangen, in denen jemand im Zeitraum X zu einer Partei gehoert, im Zeitraum Y zu einer anderen. Und damit kommen wir zum zweiten schoenen Punkt:

2.: Jeder Beitrag zu Linked (Open) Data staerkt das Gesamtsystem – selbst dann, wenn ich irgendwann keine Lust mehr habe!

Als ich Talkshowfolgen nachgetragen habe, wollte ich damit eine Auswertung ueber Parteizugehoerigkeiten machen. Da aber die Personen-Datenobjekte viele weitere Eigenschaften maschinenauswertbar mitbringen, habe ich damit die Moeglichkeit zur Beantwortung vieler weiterer Fragestellungen geschaffen. Wer moechte, kann nun auch Statistiken ueber das Alter der Eingeladenen erstellen. Oder ueber das Geschlechterverhaeltnis. Oder zu sonstigen Fragestellungen, die mal auftauchen koennten.

Und da dieses Projekt nicht in einem git-Repo von mir herumliegt, ist es auch sehr viel einfacher fuer die tausenden Mitwirkenden z.B. bei Wikidata, ganz im Vorbeigehen dafuer zu sorgen, dass diese Informationen aktuell bleiben. Egal ob Parteizugehoerigkeit, das Nachtragen weiterer Folgen, das haengt alles nicht mehr alleine von mir ab, oder davon, dass ich einen Pull-Request fuer mein Projekt annehme.

Und schon die aktive Nutzung dieser Informationen sorgt fuer Qualitaetskontrolle im Vorbeigehen. Gerade solche Punkte wie die angeblich noch bestehende Mitgliedschaft von Juergen Trittin wird bei so einer Nutzung offenkundig – und kann nun direkt im Datenbestand korrigiert werden (wenn man denn die dafuer notwendige Sekundaerquelle findet).

3.: Versuch das mal mit ’nem Sprachmodell

Die Standarderwiderung gerade ist ja, dass man das doch sicher auch per LLM machen koenne. Und ich lade herzlich dazu ein, das mal zu versuchen und dann davon zu berichten 😀

Denn, die Besonderheit bei diesen Auswertungen: Die sind meist in dieser Granularitaet bislang von sonst niemandem gemacht worden. Das heisst, sie liegen nicht als fertige Liste im Web vor. Das heisst, ein Sprachmodell findet die nicht, um sie per RAG in seine Ausgabe zu konfabulieren. All-Time-Spitzenlisten fuer alle Polittalkshows gibt es im Web (auch dort an der Spitze: Elmar Thevessen). Aber nicht fuer einzelne Talkshows, oder fuer einen bestimmten, frei waehlbaren Zeitraum.

Das heisst andersherum auch: Je mehr Wissen der Welt wir als semantische Daten in einem Wissensgraphen erfassen, desto mehr dieses Wissens koennen wir auch verlaesslich, deterministisch und mit im Vergleich zu einem LLM laecherlichen Energieaufwand abrufen. Die Antwort wird nicht immer perfekt sein. Aber dann lassen sich die Fehler und Unvollstaendigkeiten in den Ausgangsdaten transparent und nachvollziehbar korrigieren.

Ein cooler Schritt in die Richtung, der das Nachtragen nicht nur von Talkshowfolgen erleichtern wuerde, waere zum Beispiel, wenn der oeffentlich-rechtliche Rundfunk die Informationen ueber solche Sendungen gleich in einem semantischen Format ausgeben wuerde. Bonus fuer die Verlinkung der Wikidata-Datenobjekte oder andere Identifier der Gaeste. Aber schon der erste Schritt waere schon gigantisch 🙂

What is in a street name – Schoener leben mit Linked Data

2 Antworten

Eines meiner Lieblingsbeispiele, wenn ich ueber Linked Open Data spreche, sind Strassennamen. Das klingt auf den ersten Blick weit hergeholt, aber wer jemals groessere Mengen an Adressen mit einem Computer verarbeiten wollte, ist vermutlich irgendwann ueber die Liste der Falsehoods programmers believe about addresses gestolpert.

Die Quadrate in Mannheim (anstatt Strassennamen) sind dabei eher die Ausnahme. Dass in einer Gemeinde – in der Regel nach Eingemeindungen – mehrere Straßen mit demselben Namen existieren, oder dass in einer Ortschaft gar keine Strassennamen vergeben wurden, kommt dagegen relativ haeufig vor. Hilgermissen als Gemeinde mit 2200 BewohnerInnen, aber keinem einzigen Strassennamen, ist angesichts seiner Groesse so besonders, dass das DLF Nova einen Rundfunkbeitrag wert war. Neben Hilgermissen gibt es aber viele weitere kleine Oertchen, in denen die Haeuser einfach nur eine Hausnummer haben. Und egal, ob es einen Strassennamen gibt oder nicht: Sobald Menschen eine Adresse in irgendein Computersystem eingeben, wird es schnell haarig und fehlerhaft.

Adlitz: Schilder in die naechsten Staedte, aber keine Strassenschilder. Roehrensee, CC BY-SA 4.0, via Wikimedia Commons

Bei den Ortschaften ohne Strassennamen liegt das meist am Verwirrungsfaktor. Wir haben uns so sehr daran gewoehnt, dass eine Adresse aus Strasse, Hausnummer, Postleitzahl und Ortschaft liegt, dass es sich falsch anfuehlen wuerde, einfach nur „5, 95491 Adlitz“ zu schreiben – obwohl das eigentlich richtig waere.
Vermutlich alle diese Doerfer ohne Strassennamen wurden spaetestens durch die Gebietsreformen in den 1960er- und 70er-Jahren der naechstgroesseren Gemeinde zugeschlagen und verwenden auch die Postleitzahl dieser (oder einer anderen) groesseren Gemeinde. Daher liegt es nahe, diese Adresse stattdessen „Adlitz 5, 95491 Ahorntal“ zu schreiben.

Auch wenn das fuer die Postzustellung oder fuer die eigene Orientierung keinen praktischen Unterschied macht – richtig ist das nicht, und bei der maschinellen Auswertung kann so etwas zu Problemen fuehren. (Dass es zwar eine Gemeinde Ahorntal gibt, aber gar keinen Ort, der so heisst, ist noch einmal eine ganz andere Geschichte, die hier aber keine grosse Rolle spielt).

Denn, wie auch bei gesprochener Sprache sind wir als Menschen ganz gut darin, Mehrdeutigkeiten oder unpraezise Ausdruecke einfach passend zum Kontext einzuordnen. Wir lesen nicht einfach nur, was irgendwo steht und interpretieren das nur buchstaeblich, sondern wir interpretieren ohne gross darueber nachdenken zu muessen, was gemeint gewesen sein koennte. Aber bloederweise gehen wir andersherum auch beim Schreiben davon aus, dass ein Gegenueber schon wissen wird, was eigentlich gemeint ist. Und dass dieses Gegenueber nicht etwa ein Computer ist, der das Geschriebene vergleichsweise woertlich auslegt. Und dann wird’s wild.

Ganz offizielles Strassenschild – der Platz heisst aber offiziell „Augsburger-Tor-Platz“! Foto: -stk, CC BY-SA 4.0, via Wikimedia Commons

Zuletzt bin ich darueber gestolpert, als WikipedianerInnen aus dem WikiMUC und dem temporaerhaus gemeinsam bei einem Editathon die tausenden Feuerwehren in Bayern in Wikidata einpflegen wollten. Der Landesfeuerwehrverband hat eine Liste aller bayerischen Feuerwehren auf seiner Website, und die wird ganz offensichtlich von Menschen gepflegt, mit der Schreibweise der Adressen, die sie gewohnt sind. Mal wird im Strassen-Feld der Name des Ortsteils dem Strassennamen vorangestellt („Schwaighausen, Unterharter Straße 3“), mal steht im Gemeinde-Feld eine Kombi aus Ortsteil und Gemeinde („Triefenstein OT Homburg“) oder aber irgendwann ist womoeglich beim Feuerwehrhaus das Hausnummernschild abgefallen und alle sind sich einig, dass die Hausnummer „neben HsNr. 7“ scho so basst. Das ist schliesslich eine Feuerwehr, die kann man selbst in einem kleinen Dorf mit nur einer Garage fuer den Tragkraftspritzenanhaenger nicht so einfach uebersehen. Meist ist da ja irgendwas an die Wand gemalt oder es ist eine E57 auf dem Dach, also bittschoen, das wird man ja wohl finden, und die Feuerwehrdienstleistenden brauchen eh keine Hausnummer, wenn die Sirene mal geht, damit sie zu ihrem Feuerwehrhaus kommen.

Wenn dazu noch inoffizielle Abkuerzungen und vielfaeltige Interpretationen von Getrennt- oder Zusammenschreibung kommen, wird es endgueltig wild. Das temporaerhaus hat eine Adresse in der „Augsburger Straße“ – allein in unserer Community wurden sehr lange verschiedenste Varianten von „Augsburger-Str.“ ueber „Augsburgerstr.“, jeweils dann mit Varianten mit scharfem s oder Doppel-S verwendet (bis ich das nicht mehr ausgehalten und darum gebeten habe, dass wir das alle so schreiben, wie es richtig™ ist, damit ich besser schlafen kann).

Offizieller NameWas man so findet
Maximilian-Straßer-StraßeMaximilian-Strasse-Straße
Bürgermeister-Wolfgang-Brügel-StraßeBgm.W.-Brügel-Str.
St.-Ulrich-StraßeSt. Ulrich Str.
Dr.-Appelhans-WegDr.-Appelhansweg
Sankt-Johannes-Baptist-StraßeSt.- Joh.- Bapt.- Str.

Meine These ist, dass selbst bei den Datenbestaenden innerhalb einer Stadtverwaltung je Strasse im Schnitt deutlich mehr als zwei Schreibweisen ueber alle Systeme hinweg existieren, und bislang konnte das noch niemand widerlegen. Oft ist nicht einmal auf allen Strassenschildern der richtige Name der Strasse angebracht. Die „falschen“ Schilder sind bisweilen erkennbar alte Exemplare, die moeglicherweise vor einer Vereinheitlichung der Schreibweise aufgehaengt wurden. Aber nicht nur „neue“ Strassenschilder stimmen nicht immer mit dem amtlichen Namen ueberein, auch in Liegenschaftsverzeichnissen, Excel-Listen und moeglicherweise auch Fachverfahren tummeln sich mit grosser Sicherheit verschiedene Schreibweisen derselben Strasse.

Das kann automatisierte Auswertungen… schwierig machen. Der Versuch, aus den Adressen der Feuerwehren ueber Nominatim Geokoordinaten zu ermitteln, lief bei beeindruckend vielen der Eintraege gegen die Wand. Und selbst wenn man in einer Kommunalverwaltung ueberhaupt gleichzeitigen Zugriff auf alle Speicherorte haette, wo Strassennamen vorkommen: Eine Suche „gib mir alle Informationen, die irgendwie mit der Sankt-Johannes-Baptist-Straße zusammenhaengen“ wird spaetestens mit einer so kreativen Abkuerzung wie „St.- Joh- Bapt.- Str.“ (man beachte die Leerzeichen!) herausfordernd.

Nicht nur bei alten Strassenschildern schleichen sich Falschschreibungen ein. Diese Strasse heisst korrekt „Warmwässerle“. Foto: Looniverse, CC BY-SA 4.0, via Wikimedia Commons

Mit dem Konzept von Linked Data koennte man das ganz anders umsetzen. Die Sankt-Johannes-Baptist-Straße koennte ein Datenobjekt mit dem URI ld.bayern.de/location/street/081513121337 haben. Die 081513121337 koennte dabei eine hierarchische Bedeutung haben und dadurch Rueckschluesse auf Regierungsbezirk, Landkreis und Gemeinde geben – es koennte aber auch eine ganz beliebige, fortlaufende Nummer sein, so wie bei Wikidata. Und dieses Datenobjekt hat dann passende Eigenschaften – beispielsweise:

  • Ein Label mit dem Namen der Strasse. In mehrsprachigen Gebieten koennen das auch mehrere Label sein, mit maschinenlesbarer Bezeichnung, welche Sprache das jeweils ist
  • in welcher Verwaltungsgliederung es liegt – also z.B. die zugehoerige Gemeinde, mit einem Link zum Datenobjekt dieser Gemeinde. Moeglicherweise auch feiner granular mit Bezeichnung des genauen Ortsteils
  • weitere Identifier, z.B. die Nummer im Strassenverzeichnis der Gemeinde
  • moeglicherweise eine Auszeichnung, ob es sich um eine amtliche (gewidmete) Strasse mit offiziellem Strassennamen handelt, oder sowas wie den „Resis-Traktor-Weg“, den zwar alle so kennen und benutzen, den es aber „offiziell“ nicht gibt
  • Geoinformationen wie einen Linienzug, der die Strasse auf einer Karte definiert, oder einen Link auf ein solches Geofeature-Datenobjekt
  • die Information, nach wem oder was die Strasse benannt ist – zum Beispiel mit einem Link auf das Wikidata-Objekt

Oder ganz praktisch:

schema.org/nameSankt-Johannes-Baptist-Straße
schema.org/identifier081513121337
schema.org/containedInPlaceld.bayern.de/municipality/09775164
geosparql#hasGeometrygeo.ld.bayern.de/location/street/geometry/081513121337
schema.org/postalCode89264
P138Q40662 (Johannes der Täufer)

Solch eine Datenhaltung hat gleich in mehreren Aspekten grossen Charme. Die Idee ist, dass – egal wo in der Kommunalverwaltung ein Strassenname eingegeben werden soll – per Autovervollstaendigung anhand des Namens das passende Datenobjekt aus diesem Linked-Data-Strassenregister gesucht wird. Auf der „Bildschirmvorderseite“ und ueberall, wo es in Texten und Adressen in der Folge um diese Strasse geht, wird stets das Label, also der Strassenname angezeigt. Der ist dadurch immer auch der „richtige“, aber sonst aendert sich weiter nichts.

Bei der Speicherung wird aber immer der URI auf diese Strasse abgelegt. Und das heisst, dass viel verlaesslichere Datenabfragen moeglich sind: Ueber alle Dinge – Firmen, Gebaeude, Einrichtungen – in genau dieser Strasse. Ueber alle Strassen in einer Gemeinde. Oder auch – falls auch das passend codiert ist – ueber alle Strassen in einem bestimmten Ortsteil, ganz ohne Namenskonventionen, wie der Ortsteil anzugeben ist. Und wird einmal eine Strasse umbenannt, zum Beispiel, weil ein Namensgeber spaeter als unwuerdig befunden wird, muss nur im Linked-Data-Strassenverzeichnis das Label geaendert werden, und in kuerzester Zeit ist diese Aenderung einheitlich an allen Stellen vollzogen.

Hildegards gibt es viele – gemeint ist hier Q234410 (Wikipedia). Foto: Looniverse, CC BY-SA 4.0, via Wikimedia Commons

Wenn ueber Linked Data eindeutig bezeichnet wird, nach wem oder was eine Strasse benannt ist, ist auch viel leichter nachvollziehbar, nach welchem Frieden die Friedenstrasse in Neu-Ulm benannt ist, ohne dafuer zum Strassenschild gehen und die Legendentafel darunter lesen zu muessen. Auch die OpenStreetMap hat eine passende Eigenschaft NamedAfter, in die man die passende Wikidata-ID eintragen kann. Mit MapComplete kann man das relativ komfortabel fuer die Strassen in der eigenen Stadt eintragen.

Hier sieht man dann auch die Magie verlinkter Datenbestaende in der Praxis. Denn weil die Datenobjekte der Personen, nach denen eine Strasse benannt wurde, meist auch weitere Informationen wie z.B. das Geschlecht angeben, laesst sich mit Linked Open Data auch ganz durchautomatisiert und ohne weiteres Zutun darstellen, wie eigentlich das Geschlechterverhaeltnis bei der Strassenbenennung ist – so wie auf dieser interaktiven Karte von Frankfurt. Vor beinahe 11 Jahren hatte unsere Open-Data-Ehrenamtsgruppe das noch mit viel Handarbeit machen muessen und die Karte war auch irgendwann tot und die Daten versauerten – der EqualStreetNames-Ansatz laesst sich mit wenig Handarbeit uebertragen, und die Datenpflege in Linked Open Data hilft am Ende allen auf der ganzen Welt, auch wenn das Kartenprojekt einmal untergehen sollte!

Noch nicht ganz fertig: Eine interaktive Karte zur Geschlechterverteilung bei der Strassenbenennung in Neu-Ulm

Letzte Woche war ich beruflich fuer einen Vortrag (Slides) auf der TRANSFORM-Konferenz in Bern, wo ich viele inspirierende Diskussionen ueber Linked Data fuehren konnte. In einem Gespraech mit einem beeindruckend tief in der Materie arbeitenden Menschen von der Schweizerischen Bundeskanzlei liess ich nebenher das Strassenbeispiel als praktische Anwendung von LOD mit Nutzen fuer die Verwaltung fallen. Und mein Gegenueber blickte mich ueberrascht an – ich weiss rueckblickend nicht, ob es verwundert oder gar mitleidig war – und sagte lapidar, dass es das in der Schweiz natuerlich bereits gebe.

Fuer jede einzelne Strasse.

Ich versuchte, nicht sogleich aufzuspringen und mich in den naechstgelegenen Fluss zu stuerzen, sondern liess mir zeigen, dass in der Tat, es fuer jede Strasse in der Schweiz ein Datenobjekt gibt, zum Beispiel fuer den Philosophenweg in Bern, samt der zugehoerigen Geometrie. Und falls das Verlangen fuer die Sache nach dem Fluss nicht nachlasse, faende ich natuerlich auch die Aare als Datenobjekte, wobei es sich hier zu meinem Wohl explizit um Badegewaesser handle.

Die jeweils uebergeordnete Entitaet „Bern“ verlinkt natuerlich auch auf das Wikidata-Item zu Bern. Wie sich das halt gehoert, wenn man Dinge bitte gleich richtig macht.

Es faellt mir schwer, den Zustand meines Emotiotops in diesem Moment zu beschreiben. Aehnlich ging es mir spaeter, als ein Mitarbeiter der Statistik bei der Stadt Zuerich mich neugierig fragte, wie viele kommunale Statistikabteilungen in Deutschland denn in ihren Prozessen mit Linked Data arbeiten wuerden, so wie sie, ganz natuerlich.

Zack. Bumm. Geht einfach. Screenshot von https://geo.ld.admin.ch/sparql/

Ich habe dann versucht, ueber diesen mentalen Zustand hinwegzukommen, indem ich eine SPARQL-Abfrage gebaut habe, um mir die Geometrien aller 822 Strassen in Bern ausgeben zu lassen, was in rund einer Sekunde… einfach so ging. Alle Haltestellen in Bern bekommt man in 0,225 Sekunden. Auch einfach so. Ganz selbstverstaendlich. Und ganz nebenbei, wenn in der Schweiz Linked Open Data veroeffentlicht wird, folgt das – natuerlich – verbindlich dem URI-Schema *.ld.admin.ch/*. Und es sei auch alles dafuer technisch notwendige ausgerollt, damit das funktioniert und dauerhaft stabile URIs sicherstelle, wie sich das ja auch gehoert. Nicht etwa, dass sich irgendwie Namen und damit auch URIs von Ministerien aendern (wie das bis heute selbst in DCAT-AP.de geschieht!) und dann fuehren auf einmal sowohl Website-URLs wie auch URIs ins Nirvana. Also so, wie das heute in Deutschland immer noch gang und gaebe ist und woran auch ueberraschend viele Digital-Lobby-Organisationen ueberhaupt gar keinen Anstoss nehmen.

Waere das bei uns auch so ganz normal, koennte man mal eben im Vorbeigehen ganz viele andere Schmerzen einfach so loesen.

Auszug aus dem Strassenverzeichnis von 1954, das die Open-Data-Community im temporaerhaus freundlicherweise von der Stadt Neu-Ulm bekommen hatte – der Ist-Zustand besteht immer noch aus Texten, manchmal eben auch auf Schreibmaschine geschrieben. Weitergeholfen fuer die Ueberfuehrung in Linked Open Data hat das dennoch immens!

Wer datenjournalistisch Sachverhalte auf Karten darstellen moechte, kennt naemlich dieses Problem auch: Geographische Raumbezuege sind haeufig nur eben als textliche Beschreibungen zugaenglich. Egal ob es darum geht, Unfallschwerpunkte auf einer Karte darzustellen, wie Jan-Georg Plavec berichtet (LinkedIn), oder um regelmaessig wiederkehrende Aufgaben wie die Darstellung von Wahlergebnissen auf einer Karte: Oft gibt es die Voraussetzungen fuer solch eine Kartendarstellung gar nicht maschinenlesbar.

Der Zuschnitt der Wahlkreise bei einer Wahl ist dabei noch vergleichsweise einfach: Das ist eine Liste von Kommunen oder Stadtbezirken, und dafuer gibt es meistens irgendwelche Geoshapes, die sich dafuer halbwegs angenehm verwursten lassen (Beispiel: Die Liste der Stimmkreise in Bayern). Sobald es aber um die Wahl- bzw. Stimmbezirke innerhalb einer Gemeinde geht, kann es anstrenged werden. Die liegen naemlich viel zu oft immer noch nur als Listen der in ihnen befindlichen Strassen vor. Und selbst an diese Listen zu kommen, kann aufwaendig sein, wie diese Dokumentation bei der OpenStreetMap zeigt.

Hat nichts mit Stimmbezirken zu tun, aber erwaehnt nochmal die Hildegardstr.: In dieser Version des Neu-Ulmer Strassenverzeichnis von 1978 sind auch die vorherigen Strassennamen erkennbar. Nochmals vielen Dank an die Stadt Neu-Ulm!

Aus Sicht der Wahlbehoerde ist das auch nachvollziehbar. Denn von einer Kartendarstellung hat sie ja fuer die Aufstellung des Stimmverzeichnis erst einmal gar nichts: Wenn ihr die Liste der jedem Wahllokal zugehoerigen Strassen vorliegt, kann sie aus dem Meldeverzeichnis die jeweiligen Listen der Wahlberechtigten erstellen – fuer ihren Auftrag hat sie damit alle Informationen, die sie braucht. Wenn es eine geographische Darstellung der Wahlbezirke anhand der Strassenlisten gibt, ist das womoeglich nur ein Zusatzaufwand. Manchmal leistet man sich den, manchmal aber auch nicht. Und wenn es eine geographische Darstellung gibt, heisst das immer noch nicht, dass die dafuer notwendigen Daten auch z.B. von Datenjournalist*innen wiederverwendet werden koennen.

Bei der Recherche gefunden: Eine immerhin (geo)graphische Darstgellung der Wahlbezirke in Regensburg, im PDF der Wahlbezirke sortiert nach Strassennamen. Das Dokument ist mit LaTeX generiert und ich bin jetzt total neugierig, wie die das machen!

Waeren die Strassen aber Datenobjekte, mit verknuepfter Geometrie, waere in beide Richtungen vieles so viel einfacher. Fuer den Zuschnitt der Stimmbezirke waeren Neuordnungen quasi live moeglich: Mit Drag und Drop auf der Karte (und der nur verwaltungsintern zugaenglichen Linked-Data-Verknuepfung zu Meldedaten) liessen sich Neuzuschnitte und die Auswirkungen auf die Gesamtzahl der Wahlberechtigten ganz einfach simulieren – oder auch durch mathematische Optimierungsverfahren Vorschlaege machen. Und ist die Ausdehnung einmal festgelegt, waere es ueberhaupt kein Problem mehr, diesen Zuschnitten geographische Umringe zuzuordnen.

Wir muessten dafuer nur die Informationen aus der Textform in das Linked-Data-Prinzip ueberfuehren. Das ist keine Zauberei, sondern einfach nur Infrastrukturarbeit, fuer die es den notwendigen Sachverstand fuer IT-Architektur und Datenstrukturen braucht. Und die bereits auf mittlere Sicht allen Beteiligten beeindruckend viel Handarbeit sparen und Fehlerquellen vermeiden wuerde.

The History of Wikidata (and how to learn more)

Schreibe eine Antwort

Je laenger ich Wikidata und die Konzepte von Linked Open Data und was alles dazugehoert kenne, desto faszinierter werde ich davon. Derweil brauchte ich wirklich lang, um das zu verstehen – bei meinem ersten Kontakt 2012 war ich etwas ratlos, die deutschlandweiten Wikidata-Workshops im damaligen Verschwoerhaus ab 2016 haben wir das aber umso naeher gebracht, und spaetestens ab ca. 2019 war ich bei meiner Erkundungswanderung durch die Ulmer Stadtverwaltung ueberzeugt: Wer Open Data haben will, muss Linked Data mitdenken – alles andere ist Augenwischerei.

Leider ist es nicht ganz so leicht, sich in die Thematik einzuarbeiten. Ich habe die letzten Wochen aber zwei Hilfestellungen gefunden, die das vielleicht erleichtern koennten. Das schlimme ist ja, dass man das kaum mehr einschaetzen kann, sobald man selbst nahe genug dran ist – von aussen wirkte alles hoechst kryptisch und verschlossen und unverstaendlich. Hat man die Schwelle aber einmal ueberschritten, ist ja alles klar.

Denny Vrandečić, Lydia Pintscher und Markus Kroetzsch haben auf The Web Conference 2023 ein Paper zur Geschichte von Wikidata veroeffentlicht und es gibt die Inhalte auch in einem unterhaltsamen Video:

Ausserdem laeuft aktuell ein wie ich finde gut gemachter MOOC-Selbstlernkurs des Hasso-Plattner-Instituts zu Knowledge Graphs. Die Teilnahme ist kostenlos, und wer jetzt sofort mitmacht, kann auch noch die bewerteten Zwischenuebungen mitmachen. Was ich bislang gesehen habe, gefaellt mir sehr gut und stellt auch gelungen die Verbindungen zwischen den abstrakten Konzepten von Knowledge Graphs, dem Semantic Web Stack und den urspruenglichen Ideen des Semantic Web her – das ist etwas, was beim 5-Sterne-Modell teilweise zu implizit angenommen wird.

Der GovTech-Campus und der lange Schatten des New Public Management

Schreibe eine Antwort
Der frisch präsentierte Digitalbeirat Ende November 2022 – kann natürlich nichts für den GovTech-Campus

Jetzt will’s die Bundesregierung wissen mit der Digitalisierung. Vergangenen Mittwoch stellte Digitalminister Wissing den Beirat für die Umsetzung der Digitalstrategie vor. Mehrere Ministerien haben Konsultationsprozesse für ihre Digitalvorhaben gestartet – wenngleich vereinzelt wohl nicht allzu umfangreiches Feedback gewollt war. Neben den Digitallaboren, Experimentierräumen und anderen Flaggschiffen existiert zudem seit Anfang diesen Jahres der GovTech-Campus in Berlin. Auf diesen lud der Bundes-CIO Markus Richter unlängst die Podcaster Philip Banse und Ulf Buermeyer ein, die in der Lage der Nation (Ausgabe 313, Kapitel 6 ab 36:53) begeistert von ihrem Besuch dort berichten.

Das ist aus zwei Gründen bemerkenswert. Erstens wegen des GovTech-Campus selbst, seiner Organisation als eingetragener Verein, in dem Unternehmen für mehrere tausend Euro Mitglied werden können, und der Tatsache, dass dort Ministerien und privatwirtschaftliche Dienstleister unter demselben Dach sitzen und „gemeinsam“ IT-Dienstleistungen entwickeln. Die Lage hebt das als positives Beispiel hervor.
Zweitens, weil eher im Nebensatz erwähnt wird, dass es seit vielen Jahren auch eine aktive digitale Zivilgesellschaft in diesem Bereich gibt. Die ehrenamtliche Zivilgesellschaft hat im Konzept des GovTech-Campus aber gar keinen Raum, und wird in der Lage auch nur im Rahmen von Hackathons erwähnt, die an den Bedürfnissen vorbei entwickeln würden.

Derweil kann man argumentieren, dass die Situation, in der die öffentliche Hand bei ihren Digitalisierungsbestrebungen stets auf externe Dienstleister angewiesen ist und mit der Zivilgesellschaft allenfalls im Rahmen von Hackathons interagieren kann, eine Konsequenz des New Public Management ist. In diesem Denkmodell wird die Bevölkerung zu „Kund*innen“ des Staats, der sich – auch in genuinen Aufgaben der Daseinsvorsorge – wie ein Unternehmen verhalten soll. Das heißt zum Beispiel, dass Abteilungen sich untereinander ihre Leistungen in Rechnung stellen. Aber auch, dass Leistungen der öffentlichen Hand an Unternehmen oder eigene Gesellschaften ausgelagert werden. Ein Engagement außerhalb dieser Wirtschaftslogik ist gar nicht vorgesehen – das heißt, die umfangreiche praktische Digitalisierungsexpertise aus dem Ehrenamt zerschellt regelmäßig an der staatlichen Organisationspraxis.

Schon für die Anforderungsbeschreibung von Digitalprojekten braucht es externe Beratung

Wünschewand beim OpenCityCamp 2012

Das hatte gerade für die Digitalisierung fatale Folgen. Anstatt IT-Architekturkompetenzen auf allen Ebenen der föderalen Verwaltung aufzubauen, bestimmt seit Jahren eine Reihe externer Dienstleister, wohin der Staat digitalisiert. Was auf den ersten Blick wie eine Effizienzsteigerung klingt – denn natürlich sollen nicht über 11000 Kommunen jeweils ihre eigene Softwarelösungen entwickeln – führte über die Jahre zu einem weitreichenden Kompetenzverlust schon bei der Bestimmung, was eigentlich die Anforderung an die zu bauenden Softwarearchitekturen sind. Als Nebeneffekt kann es dann auch schon einmal vorkommen, dass die beschaffte Software am Ende gar nicht für den gedachten Einsatzzweck taugt und das Projekt für die Katz war. Lilith Wittmann nennt das in ihrer kritischen Besprechung des GovTech-Campus die „Beratertreppe“: Die laufende Externalisierung von Kompetenzen wurde zur selbstverstärkenden Spirale, so dass seit Langem schon für die Erstellung der Ausschreibungen für ein Softwareprodukt externe Beratung herangezogen werden muss.

Diese Erfahrung haben in den vergangenen Jahrzehnten auch immer wieder Ehrenamtliche aus der Zivilgesellschaft gemacht. Analog zur Civic-Tech-Bewegung in den Vereinigten Staaten entstanden in den späten 2000er-Jahren auch in Deutschland Gruppen Freiwilliger, die am praktischen Beispiel aufzeigten, was mit den Mitteln der Informationstechnik eigentlich möglich wäre. Als Instrument der Selbstermächtigung und zivilgesellschaftlichem Gegenstück zu Open Government entstanden Transparenz fördernde Auswertungen offener Daten, aber auch ausgereifte Beispiele, wie die öffentliche Hand ihre Leistungen für die Bevölkerung noch besser benutzbar machen kann.

All diese Gruppen stießen jedoch früher oder später auf die immer selben strukturellen Hürden, wenn es darum ging, dass der Staat ihre Ideen auch aufgreift und sich zu eigen macht. In ihrem Buch „A civic technologist’s practice guide“ beschreibt die ehemalige leitende 18F-Mitarbeiterin Cyd Harell zwei notwendige Schritte für die erfolgreiche Anwendung von Civic Tech: „Showing what’s possible, and doing what’s necessary“. Dieser Pfad, dass Ehrenamtliche aus der Zivilgesellschaft zeigen, was möglich wäre, und der Staat dann das Notwendige tut, um sich diese Beispiele zu eigen zu machen, scheint in Deutschland aber fast nirgendwo vorgesehen zu sein. Meist ist man entweder zivilgesellschaftliche „Kund*in“ des Staats und kann allenfalls im Rahmen von Anhörungen und Feedbackrunden Jahr für Jahr dieselben Post-Its auf Metaplanwände kleben – oder man muss selbst Dienstleister*in werden und sich beauftragen lassen, der eigenen Idee irgendwo im Wildwuchs der Verwaltungs-IT ein Gärtchen bestellen zu dürfen. 

Für gestaltende Zivilgesellschaft ohne wirtschaftliches Interesse gibt es in diesem Denkmodell keinen Raum

kleineAnfragen.de: 2014–2020

Für die Unterstützung der Umsetzer-Rollen gab es über die Jahre verschiedene Ansätze: Inkubatorprogramme, Förderlinien, Kooperationen mit Umsetzungspartnern aus der Wirtschaft. Das waren aber allesamt lediglich unterschiedliche Geschmacksrichtungen entweder von Firmengründungen oder kurz- bis mittelfristigen finanziellen Förderungen, damit Weiterentwicklung und vor allem Wartung und langfristiger Betrieb wenigstens nicht in der Freizeit der Beteiligten passieren musste. Wir haben im Ergebnis bis heute keinen Ansatz, um langfristig einen Pfad zu ebnen, dass die öffentliche Hand selbst fertige, von der öffentlichen Hand direkt übernehmbare Produkte wie kleineanfragen.de auch selber betreiben könnte, und sei es über Konstrukte wie die kommunalen Rechenzentrumsverbünde. An die Stelle von Civic Tech aus einer engagierten Bürgerschaft und einer Verwaltung, die selbst in der Lage ist, aus deren Erfahrungen zu lernen, ist GovTech getreten – also die vollständige Abhängigkeit von Firmen, die teils den Staat als einzigen Kunden für ihre Produkte haben.

Das ist auch eine Erfahrung der Zivilgesellschaft aus jahrelanger Beschäftigung im Austausch mit der Verwaltung – sei es bei selbst organisierten Barcamps oder der Beteiligung an Hackathon-Formaten. Und hier zeigt sich eine weitere problematische Konsequenz dieser Kompetenzauslagerung durch den Staat. Eher im Nebensatz erwähnt Philip Banse, dass es neben dem ebenfalls auf dem GovTech-Campus vertretenen Digital Service des Bunds auch Ehrenamtsnetzwerke wie Code for Germany gebe – aber die würden ja eher Hackathons machen und an den Bedarfen der öffentlichen Hand vorbei entwickeln.

Aus Sprints werden Marathons – aber warum sollen Ehrenamtliche laufen, und nicht der Staat?

Voll gut: Hackathons, um neue Fähigkeiten zu erwerben oder auf politische Missstände aufmerksam zu machen. Eher nicht so gut: Hackathons, um mal eben Aufgaben des Staats lösen zu wollen. Open Knowledge Foundation Deutschland from Deutschland, Jugend hackt Ulm 2018 (46355412802), CC BY 2.0

Indes waren es gerade die Ehrenamtlichen des Code-for-Germany-Netzwerk, die auf den Nachhall des großen Corona-Hackathons der Bundesregierung 2020 in Form einer Wiederentdeckung von Hackathons durch die öffentliche Hand und seinen Partnerorganisationen wie Tech4Germany (aus dem der oben erwähnte Digital Service hervorging) eher verhalten reagierten. Viele der Code-for-Germany-Aktiven haben über die Jahre hinweg Begegnungen mit Hackathonformaten gehabt  – und merkten über die Zeit, dass sie zwar an Erfahrung dazulernten, wie die Verwaltung funktioniert, aber immer wieder auf dieselben Probleme und Hilflosigkeiten dieser Verwaltung stießen, die schon auf den Austauschformaten mehrere Jahre zuvor adressiert werden sollen hätten. Die Erfahrung der Code-for-Germany-Ehrenamtlichen zeige, „dass es weniger um die Prototypen als viel mehr [um] Erkenntnisse auf einer strukturellen Ebene“ gehe, heißt es in einer Handreichung des Netzwerks vom Sommer 2020. 

Zum einen geht es bei Hackathons wegen des immer noch vielfach genutzten Wettbewerbscharakters nämlich viel zu häufig um den Start neuer Projekte. Häufig werden also Ideen neu erfunden, an denen andere Gruppen bereits – beispielsweise aus eigener Betroffenheit – zur Verbesserung einer konkreten Situation gearbeitet haben und nun Unterstützung zur Weiterentwicklung und Wartung gebrauchen könnten. Zum anderen laufen auch die „Verstetigungsprogramme“ bis heute meist auf die finanzielle Unterstützung der Ideengeber*innen oder die Entwicklung der Ideen in ein Geschäftsmodell hinaus. Aus dem Sprint werde ein Marathon, hieß es im Nachgang des Corona-Hackathons – ohne dabei die Frage zu stellen, warum denn nun ausgerechnet die Zivilgesellschaft einen Marathon laufen soll, und nicht der Staat.

Die ausgearbeiteten Lösungen aus dem Digitalen Ehrenamt liegen meist schon vor – haben aber selten Chance, zu verfangen

Austauschformat, 2017. Open Knowledge Foundation Deutschland from Deutschland, Datensummit 2017 – Tag 1 im BMVi (33974368270), CC BY 2.0

Ganz ähnlich lief dies auch ein Jahr später beim „Update Deutschland“-Hackathon, der auch Länder und Kommunen als „Zielgruppe“ identifiziert hatte und mit deren Unterstützung durchgeführt wurde. Der überfällige Aufbruch der Verwaltungsdigitalisierung sollte auch hier aus der Zivilgesellschaft kommen, die aber gleichzeitig unpolitisch von den veranstaltenden Institutionen in Anspruch genommen und in wirtschaftliche Wirkmuster gelenkt werden sollte, wie Daniel Staemmler und Sebastian Berg konstatierten. Bemerkenswert war, dass auch Kommunen an dem Format teilnahmen, die bislang den Input aus der örtlichen Ehrenamtsszene häufig links liegengelassen hatten. Analog zu kleineanfragen.de lagen auf mehrere der bei Update Deutschland gestellten „Challenges“ der teilnehmenden Verwaltungen bereits seit Jahren tragfähige Vorschläge aus der Zivilgesellschaft vor – die aber bislang von der öffentlichen Hand nicht umgesetzt wurden.

So stellte eine Kommune die Herausforderung vor, die Beschlüsse des Gemeinderats „erlebbarer, einfacher auffindbar und transparenter“ zu machen. Das Ratsinformationssystem der Kommune habe in der Regel Schnittstellen, um diese Informationen abrufen und beispielsweise auf einer Karte darstellen zu können. Bei der beschriebenen Schnittstelle handelt es sich um den seit 2012 durch Ehrenamtliche bei Code for Germany entwickelten Standard OParl. Und die Ironie der Challenge ist, dass, wie gerade erst von Nora Titz beschrieben, am Anfang dieser Standardisierung genau solche grafischen Aufbereitungen der Ratsinformationen standen – damals mit Scrapern aus den Informationssystemen extrahiert und beispielsweise auf Karten dargestellt. Die für die Öffentlichkeit nutzbaren, im Ehrenamt entwickelten Frontends für die Auswertung der OParl-Daten konnten bis heute nicht von der öffentlichen Hand übernommen, geschweige denn betrieben werden. Teilweise scheint es ihr schon schwerzufallen, die beim Ratsinformationssystem-Anbieter bestellte OParl-Schnittstelle auch auf ihre korrekte Installation zu überprüfen und abzunehmen. Die OParl-Schnittstelle der Challenge-gebenden Stadt war zum Zeitpunkt des Hackathons gar nicht aktiviert – und ist es auch zum Zeitpunkt dieses Artikels noch nicht. Es existiert zwar ein fertiges Validierungsskript, mit dessen Hilfe man die Standardkonformität der Schnittstelle in Minutenschnelle prüfen kann. Um dieses Skript bei der Abnahme im Verwaltungsnetz ausführen zu können, bedarf es aber der internen Fähigkeiten, den Validator auf Verwaltungsrechnern selbst zum Laufen zu bringen. Danach braucht es noch etwas Verständnis, die Ausgaben interpretieren zu können und sich vom Dienstleister nicht einreden zu lassen, dass der Fehler bei einem selber liege. Was engagierten Freiwilligen mit grundlegenden Kenntnissen eine spielerische Fingerübung weniger Minuten ist, stellt die Verwaltung teilweise heute noch vor große Herausforderungen. Der Staat baut hier nicht die notwendigen Kompetenzen in der Breite auf, um die gratis vom Ehrenamt gelieferten Skripte auch selbstbestimmt ausführen zu können. Stattdessen sind diese Ehrenamtlichen letztlich dazu gezwungen, selbst als bezahlte Dienstleister*innen aufzutreten, wenn sie wollen, dass ihre Ideen auch in die Tat umgesetzt werden.

Vorhandenes Wissen aufgreifen und dokumentieren – nach den Bedürfnissen des Ehrenamts!

CC0 Matthias Wörle im Auftrag von Wikimedia Deutschland

Die überstarke Begeisterung des Staats für Hackathons scheint mittlerweile – zum Glück! – endlich abzuflauen. Offen bleibt aber die Frage, wie Ehrenamt und Zivilgesellschaft sich überhaupt wirkungsvoll mit ihrer Expertise einbringen können. Der Anspruch kann dabei nicht sein, auch als Zivilgesellschaft ein Büro am GovTech-Campus zu haben. Schon die Existenz eines GovTech-Marktes ist mehr Indikator eines grundsätzlichen Problems, als dass diesem Markt mit einem Austauschcampus noch niederschwelligerer Zugang geschaffen werden soll. Es kann auch nicht die Aufgabe Ehrenamtlicher sein, werktags mit am Tisch zu sitzen, wenn Vergabeverfahren für staatliche IT-Lösungen nun möglicherweise noch weniger nachvollziehbarer als bisher zwischen Verwaltung und Dienstleistern ausgehandelt werden. Vielmehr geht es darum, den Wissensschatz der ehrenamtlichen Digitalen Zivilgesellschaft aktiv zu suchen und in die Verwaltung selbst zu transferieren. 

Wikimedia Deutschland hat gemeinsam ergänzt um Interviews mit der Deutschen Stiftung für Ehrenamt und Engagement vergangene Woche im Politikbrief „Digitales Ehrenamt: Zivilgesellschaftliche Teilhabe im Digitalen Raum“ sechs Forderungen aufgestellt, wie dieses Engagement besser vom Staat gewürdigt und gefördert werden sollte. Eine der Forderungen ist der systematische Transfer ehrenamtlicher Expertise. Der Staat sollte nicht etwa Dienstleister*innen auf seinen GovTech-Campus zu sich einladen und damit weiter Kompetenzen externalisieren, sondern strategisch interne IT-Fähigkeiten aufbauen. Das vorhandene Wissen im digitalen Ehrenamt muss durch aufsuchende Beteiligung und den Bedürfnissen der Freiwilligen folgend aufgegriffen und dokumentiert werden, um es verwaltungsintern verwendbar und anwendbar zu machen. Damit könnte endlich eine Brücke über die nach wie vor bestehenden Wissensklüfte geschlagen werden – damit kommende Generationen ehrenamtlich Aktiver hoffentlich künftig nicht mehr zu ihrer Frustration auf dieselben strukturellen Hürden stoßen, an denen diese Partizipation bislang scheiterte.

//edit am 24. Januar 2023, Rolle der DSEE im Politikbrief von WMDE korrigiert

Abfragen im dezentralen Semantic Web. Oder: Baut viele SPARQL-Endpunkte statt grosser Datenplattformen

Schreibe eine Antwort

Wie Abfragen ueber verteilte Wissensquellen aussehen (nicht eine Super-Datenplattform!), ist in diesem Video von 2018 schoen erklaert (danke MarcelOtto). Ein praktisches Beispiel eines federated query mit Wikidata hatten @saerdnaer und @Wikidatafacts als kleine Fingeruebung fuer den kleineren Massstab bei einem Wikidata-Workshop in Ulm entwickelt.

(quelle:internet)

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:

Replying to @LilithWittmann 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.

5⋆ #OpenData 2022. pic.x.com/xwpsoktwvo

Open Data und das auf den Kopf gestellte Nutzungsversprechen

Eine Antwort

Tori Boeck hatte im Februar einen Artikel ueber ein sich nun seit Jahren hartnaeckig haltendes Muster in der deutschen Open-Data-Szene veroeffentlicht: Alles scheint sich um „Anwendungsfaelle“ zu drehen, und dass die tatsaechliche Nutzung offener Daten (neben der schieren Zahl veroeffentlichter Datensaetze) ein Erfolgskriterium sei.

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.

Wolfram Eberius, Cfg-summit-20211127-codefor-berlin-02, CC BY-SA 4.0

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?

Tbachner, Container Terminal Dortmund 12.01.2013, CC BY 3.0

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.

Open Data, wie es zu Covid haette sein koennen

Eine Antwort
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. rnd.de/politik/eine-g… In der Omikron-Welle ist nicht nur die Belegung der Intensivstationen entscheidend – für die Beurteilung des Geschehens braucht es dringend einen tagesaktuellen Überblick über die Normalstationen. rnd.de
Eine gute Datenlage kann Leben retten
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…

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:

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.x.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.

5-Sterne-Schema aus den 2000ern. Quelle.

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.
The biggest shift in tech for the next years isn’t blockchains or „AI“ or quantum computing or some other buzzword. Or at least it shouldn’t, mustn’t be.

The biggest shift has to be to change away from „Innovation“ as the main driver of work towards care and maintenance.

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.