Archiv des Autors: stk

Über stk

Medieninformatik-Student mit Visionen. Geht aber trotz Helmut Schmidts eindringlicher Aufforderung deswegen nicht zum Arzt.

Probleme mit DCAT-AP.de, heute: Lizenzen

Manchmal trifft man ja auf Dinge, bei denen man gar nicht glauben kann, dass sie einem nicht schon viel frueher aufgefallen sind. Und vor allem aber, dass das nicht schon laengst jemand anders aufgezeigt hat.

Aktuelles Beispiel sind die Lizenzdefinitionen in DCAT-AP.de, der nationalen Implementierung von DCAT-AP als Beschreibungsstandard fuer Open Data. Ich war schon im Fruehjahr 22 darueber gestolpert, dass DCAT-AP.de sprechende URIs fuer die Lieferanten von Daten definiert – was auch heisst, dass sich diese URIs immer wieder mal aendern. Das BMI hiess dort 2018 beispielsweise bundesministeriumDesInnern, 2020 bundesministeriumDesInnernFuerBauUndHeimat, 2022 bundesministeriumDesInnernUndHeimat – und im August 2025 in der aktuellsten Version und nach der Umbenennung des Ministeriums ist es dort immer noch das bundesministeriumDesInnernUndHeimat. Ein reines bundesministeriumDesInnern gibt es dort immer noch nicht als Datenlieferant – ebensowenig wie das BMDS oder das BMFTR.

Einschub: Auch Wikidata macht diese Abbildung nicht ganz so perfekt. Das zugehoerige Datenobjekt ist dort immer dem Wikipedia-Artikel zum derzeit aktuellen BMI zugeordnet und schleppt quasi die Versionshistorie mit. In der Gemeinsamen Normdatenbank ist jede „Instanz“ des BMI mit einem eigenen Identifier bezeichnet; im Identifier fuer das vormalige Bundesministerium des Innern und fuer Heimat sind sowohl das „neue“ BMI (fuer den „Innern“-Teil“) als auch das „neue“ BMLEH (fuer den „Heimat“-Teil) als Nachfolgeinstanzen des „alten“ BMI angegeben. So waere das meines Erachtens auch fuer DCAT-AP.de richtig.

Als ich vergangene Woche bei einem Workshop die Liste der Lizenzen auf DCAT-AP.de vermutlich erstmals so richtig angesehen habe, war ich aber wirklich ueberrascht. Denn neben Lizenzen, die vermutlich aus historischen Gruenden mitgeschleift werden, finden sich dort ein paar Definitionen, die meines Erachtens nie richtig sein konnten und dort auch nicht hingehoeren – aber in der Praxis in Gebrauch zu sein scheinen.

Historisches, oder: Die Datenlizenz Deutschland als DDR der Lizenzen.

Bei Lizenzen, die historisch mal irgendwo in Gebrauch waren, kann man das nachsehen. Schliesslich soll solch eine Liste ja alle Faelle abdecken, die tatsaechlich real im Umlauf sein koennten. Die Datenlizenz Deutschland 1.0 ist seit dem Juli 2014 formell ueberholt (die Datenlizenz Deutschland 2.0 prinzipiell auch schon immer, aber darum geht es hier nicht), aber es koennen immer noch Datensaetze im Umlauf sein, die mit der DL-DE 1.0 lizenziert wurden.
Das ist quasi analog zu einem Eintrag „Geburtsland: Deutsche Demokratische Republik“ in den Urkunden von Menschen: Das gibt’s in der Realitaet, das ist auch formell korrekt so, und es ist auch sinnvoll, das maschinenlesbar abbildbar zu machen, solange das die Realitaet beschreibt (selbst wenn das nicht mehr lebende Personen betrifft). Das heisst aber natuerlich nicht, dass es sinnvoll oder geboten waere, solch einen Eintrag bei einer jetzt gerade neu geborenen Person vorzunehmen. Weil das waere ja Quatsch. Bei bereits geborenen Menschen, fuer die das zutrifft: Prima. Neuvergabe: Nein.

Analog gilt das auch fuer Lizenzen, die mal fuer Datensaetze vergeben worden sind, deren Neuvergabe aber im Konflikt mit der EU-Open-Data-Richtlinie stuende. Die NC-Variante der CC-Lizenzen („nur zu nichtkommerziellen Zwecken“) geht ohnehin meist am Ziel vorbei (PDF), fuer Open Data ist sie jedenfalls gemaess der Open-Data-Richtlinie nicht passend und sollte daher auch nicht fuer neu hinzukommende Datensaetze ueberhaupt zur Auswahl stehen.

Unsinniges, oder: Lizenzangaben, die so nie sein duerften

Wirklich am Kopf kratzen musste ich mich aber bei den Definitionen eigentlich „okayer“ Lizenzen gemaess der DCAT-AP.de-Liste. Die CC-BY-Lizenz gibt es beispielsweise in mehreren „Geschmacksrichtungen“: Der seit November 2013(!) ueberholten, aber vielfach noch verwendeten Version 3.0 (als cc-by-de/3.0), der zu bevorzugenden, aktuellen Variante CC BY 4.0 (als cc-by/4.0) und einer… ja, was eigentlich? Einer „allgemeinen“ Variante moechte man meinen, die als cc-by bezeichnet wird – die aber nicht klarstellt, welche Version eigentlich gemeint ist. Und das koennte ein Problem sein.

Gleich mehrere Lizenzen verweisen naemlich im Feld Lizenztext nicht etwa auf den kanonischen URL der jeweils bezeichneten Lizenz, sondern jeweils auf eine Uebersichtsseite bei opendefinition.org. cc-by verweist auf https://opendefinition.org/licenses/cc-by/, und dort findet sich eine Auflistung aller fuenf Versionen dieser Lizenz. Welche Version gemeint ist? Man weiss es nicht.
Genauso ist es bei der CC-0 1.0: Die wird in DCAT-AP.de cc-zero genannt (ohne Version, also nicht etwa cc-zero/1.0) und verweist ebenfalls auf eine Beschreibungsseite bei opendefinition.org und nicht auf die Freigabeerklaerung/Lizenz selbst. Solange es nur diese eine Version gibt, ist das vermutlich nicht schlimm. Korrekt ist das aber trotzdem nicht, weil hinter dem Lizenztext-Eintrag findet sich schlicht nicht der Lizenztext.

Noch kaputter ist das bei der (ohnehin zu vermeidenden, siehe oben) vermeintlich „allgemeinen“ Fassung von cc-by-nc, die auf http://creativecommons.org/licenses/by-nc/ verweist: Dieser URL liefert laut Internet Archive seit etwa 2010 einen Fehler 404; zuvor fand sich dort mal ein directory listing der darunter zu findenden verschiedenen Versionen der Lizenz. Als kanonischer URL fuer eine „allgemeine“ Fassung war das aber wohl erstens nie gedacht und ist auch weder fuer Altbestaende noch fuer neue Datensaetze sinnvoll.

Was heisst das in der Praxis – fuer Verwendende?

Wann immer man irgendwo auf einen Datensatz mit cc-by oder cc-by-sa oder cc-by-nc in den Metadaten trifft, duerfte es sich um einen Datensatz mit „ungueltiger“ Lizenz handeln. Es ist nicht klar, welche Version genau gemeint ist. Sorry, Linie uebertreten, Versuch ungueltig. cc-by-nd verweist immerhin eindeutig auf die (seit nun fast 12 Jahren ueberholte) Lizenzversion 3.0, sinnvoll ist das aber ueberhaupt nicht.

Was heisst das in der Praxis – fuer Open-Data-Stellen?

Spannend ist jetzt die Frage, wie Datenbereitstellende oder Betreibende von Datenportale mit dieser Liste umgehen sollen. Ich habe letzte Woche erfahren, dass manchmal der Eindruck entsteht, dass man in einem Datenportal auch alle Lizenzen annehmen muesse, die in dieser Liste stehen. Schon durch das DDR-Beispiel sollte klar sein, dass das nicht sinnvoll ist.

Aus meiner Sicht ergeben sich daher folgende Handlungsempfehlungen:

  • Govdata.de, CCOD und weitere beratende Stellen muessen klarstellen: Die DCAT-AP.de-Lizenzliste ist keine „Positivliste“ aller auch jetzt noch zulaessigen Lizenzen fuer neue Datensaetze.
  • Ebenso: Explizite Positiv-Empfehlungen, was als Standard gesetzt werden soll. Das ist CC-0 1.0 und CC BY 4.0 (mit expliziter Versionierung). Letzteres mit der verpflichtenden Namensnennung idealerweise nur dann, wenn es sich bei dem zu lizenzierenden Gegenstand auch zweifelsfrei um urheberrechtlich geschuetzte Inhalte handelt, nicht nur um Daten, die allenfalls dem Datenbankherstellerrecht unterliegen.

Fuer Stellen, die Datenportale betreiben und/oder Daten von anderen per Harvesting konsumieren:

  • Fuer manuelle Pflege, solange es das noch gibt: Analog zum Open-Data-Kompass des ehemaligen BMDV (Archivlink) sollen die Lizenzen CC-0 1.0 und CC BY 4.0 bevorzugt angezeigt werden; „Lizenzen“ mit unklarer Geltung wie z.B. die DL-DE sollen allenfalls mit Warnhinweis ueberhaupt anwaehlbar sein. Idealerweise mit Verweis auf zentral (s.o.) gepflegte Erklaerungen, warum diese Lizenzen ein Problem sein koennten.
  • Auch die „komischen“ Lizenzen koennen per Harvesting akzeptiert werden, sollten aber Ausloeser fuer eine Qualitaetssicherungs-Massnahme in Richtung der Quelle sein. D.h., wenn irgendwo etwas mit z.B. cc-by eingesammelt wird, sollte das einen automatischen Hinweis in Richtung dieser Stelle triggern: Das ist eventuell nicht das, was ihr machen solltet. Ziel muss sein, solche Schroedinger-Datensaetze in einen definierten Zustand zu heben.

Und wer auch immer die Liste in DCAT-AP.de pflegt:

  • in DCAT-AP.de muss „aufgeraeumt“ werden. Insbesondere die Legacy-Lizenzen, aber auch die Definitionen mit unklarer Definition muessen als deprecated markiert werden: Die dienen der Beschreibung, was mal vorgekommen ist, sollen aber nicht fuer neue Datensaetze verwendet werden.
  • und auch die CC-0 1.0 muss „richtig“ vergeben werden. Keine Ahnung, was das fuer einen Rattenschwanz nach sich zieht, aber der derzeitige Zustand ist… seltsam.

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

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 😀

Wetterstation im Rathauspark Wien: Turmfoermig mit einem umlaufenden Dach, unter dem Dach drei runde Messinstrumente fuer Temperatur, Luftdruck und Luftfeuchtigkeit

Smart-City-Bullshit: Messen, dass es heiss ist, ohne Aussicht auf Besserung

Titelbild: Gugerell, Wien 01 Rathauspark db, CC0 1.0

Es ist Mittwoch Abend, ich sitze nach einem wahren Backofentag am offenen Fenster, und draussen hat es immer noch ueber 30 Grad. Parallel titelt der Standard, dass die Revitalisierungs- und Begruenungsmassnahmen in Paris einen fuehl- und auch messbaren Unterschied ausmachen: In den Quartieren, wo aus Parkplaetzen Baumpflanzungen gemacht wurden, „Gartenstrassen“ entstanden, Fassaden und Daecher begruent wurden, liegt die Temperatur um 1 bis 4 Grad unter den Temperaturen in den Quartieren, wo das noch nicht geschehen ist.

Waehrenddessen glueht draussen (metaphorisch!) der Asphalt. Was noch mehr glueht ist meine Abneigung und Verachtung gegen Smart-City-Bullshit, und die Situation heute ist wieder mal ein Anlass, zu erzaehlen, warum.

Ich bin immer noch der Ueberzeugung, dass kaum ein Foerderprojekt mehr langfristigen Flurschaden fuer Digitalisierung, aber auch fuer Beteiligung angerichtet hat als die „Modellprojekte Smart Cities“. Das kann man an vielen Beobachtungen festmachen, aber geradezu frappierend ist der Umgang der „Smart Cities“ mit Klimawandel und städtischer Hitze.

Irgendetwas mit Hitze und Hitzeplan und Hitzeinseln zu machen ist tatsaechlich so etwas wie ein Pattern in Smart-City-Vorhaben, mit eigenem Artikel beim „Smart City Dialog“. Muenster, Dortmund, Dresden, Solingen, (natuerlich auch) Ulm und viele weitere Staedte haben irgendwelche Klimasensorik ausgebracht. Dagegen waere eigentlich auch gar nichts einzuwenden, wenn das ganz klassisch ein Vorhaben einer BuergerInnen-Bewegung waere, die mit solider Datenbasis dem nicht-handelnden Staat in den Hintern treten und ihn dazu bewegen wollte, endlich einmal das Richtige und Gebotene zu tun.

Aber, das ist ja der Punkt: Wer hier misst ist die Verwaltung, ist der Staat selbst. Und wozu? Die Bevoelkerung und vulnerable Gruppen sollen fruehzeitig vor zu erwartender starker Hitze gewarnt werden koennen. Man wolle Hitzeinseln identifizieren. Die Messungen sollen irgendwie analysiert werden, hier und dort wird (natuerlich) „KI“ erwaehnt, irgendwas soll dann in einen „Hitzeplan“ einfliessen, und natuerlich gibts Dashboards und Apps. Am Ende soll dann irgendwie evidenzbasiert entschieden werden, wie mit Hitze weiter verfahren werden soll.

Was dann natuerlich sofort die Frage aufwirft, warum man denn nicht laengst bekannter Evidenz folgt und, sagen wir mal, verdammt nochmal grossraeumig Flaechen entsiegelt und die Stadt begruent, ihr verdammten Smart-Shity-Powerpoint-Kackbratzen. Die geforderte Evidenz faende man z.B. in Santamouris (2004), dass man Daecher begruenen koennte, oder Bernatzky (1982!), dass ein kleiner staedtischer Park die Temperatur um 3–3,5°C senkt.

Wo sind also nun die Ergebnisse? Was ist in der Zwischenzeit „evidenzbasiert“ passiert? Sind denn mehr Baeume gepflanzt, Fassaden und Daecher begruent worden durch die „smarte“ Messung? Oder wenigstens gezielter? Oder sind die ganzen Sensornetzwerke nur das moderne Gegenstueck zur klassischen Outdoor-Wetterstation beim Optiker an der Wand oder an irgendeiner oeffentlichen Saeule, wo man nun nicht mehr nur draufschauen und sagen kann „tatsaechlich, es ist echt heiss!“, sondern das geht auch vom Smartphone aus? Und „vulnerable Gruppen“ bekommen dann eine Push-Notification „servus, du kannst draussen fei grad nicht ueberleben, bleib lieber drin“ und das war’s?

Ich mag den Begriff „un-formation gathering“ fuer dieses Muster – in dem Artikel auf „KI“ gemuenzt, aber 1:1 passend fuer Smart-City-Uebersprungshandlungen:

Many […] applications promise to generate new insights, may it be regarding forest health, biodiversity indicators or crop quality. Yet, in most cases of possible protective climate or biodiversity action we as humanity already have sufficient scientific actionable insight. Getting more information is never bad, but the grave implications of AI use might not justify mere theoretical curiosity. Such research could even have a delaying effect, if decision-makers use it to wait for more detailed but practically meaningless results. I call these kinds of results, i.e. the information produced by an obsessive focus on getting more data – without taking action on the sufficient knowledge already available – unformation, which must be called out and prevented, especially when used as pretext for inaction.

Es ist natuerlich einfacher, Mehrheiten fuer den Rollout irgendwelcher „smarter“ Sensorik zu gewinnen als fuer harte Fragen, z.B. welche Parkplaetze wegfallen sollen. Und perfiderweise nimmt man gleichzeitig einer widerstaendigen Zivilgesellschaft den Wind aus den Segeln: Anstatt dass diese selbstbestimmt(!) Zahlen, Daten und Fakten zu den Auswirkungen ueberhitzender Staedte sammelt und endlich Taten einfordert, wird sie durch „Beteiligung“ zu Tode umarmt, denn sie macht ja beim staatlichen Projekt mit und gibt ihm den Anschein zivilgesellschaftlicher Legitimation.

Und andersherum wird auch nicht eine konkrete Massnahme durch Messungen begleitet, um spaeter nachweisen zu koennen: Wir haben Dinge getan, und jetzt koennen wir auch durch Messungen nachweisen, wie die Wirkung aussieht. Das waere ja auch fein. Aber es wird gemessen, anstatt die konkreten wirksamen Massnahmen anzugehen. Auch nicht spaeter, nach einer initialen Messung der Ausgangslage. Es gibt nur ein diffuses Versprechen, dass irgendwann, irgendwas passieren koennte.

Wie im Artikel zu „un-formation gathering“ beschrieben: Es wird Zeit, solche Uebersprungshandlungen zu benennen und stets nachzubohren, welche der laengst als wirksam bekannten Massnahmen denn nun in Folge stattgefunden haben. Es nicht durchgehen zu lassen, dass die Smart-Shitty-Abteilung die Haende in Unschuld waescht, weil „sie sammelt ja nur Daten“ und fuer die Umsetzung seien andere zustaendig.

Licenses, „Signals“ and genAI Scrapers

Note: As usual in this blog, this is the place where I publish personal musings and ramblings. Usually, this is a place to sketch things out, akin to thinking aloud. For this text, this is even more the case than usual. So far, I have written down this text in one session. It has not yet been adorned with pretty illustrations.

The age of “AI“ is upon us. And when people talk about “AI”, nowadays this can mean anything from the whole research field, to diverse flavours of Machine Learning, to “something magic that automates stuff”. Recently, it’s mostly generative systems like LLMs with all their side effects.

There’s a whole catalogue of baggage that comes with producing, disseminating and using generative systems, and enough people have written about these that I feel more than comfortable to skip right to the debate that popped up yesterday when Creative Commons released their CC Signals proposal. I think that the thinking behind those licenses is very flawed and gnaws at the very foundations behind the ideas of Digital Commons in more than one instance. Of the groups of humans onto which the costs of training genAI models are externalized, it solely addresses creators, leaving everybody else by the wayside. I’d rather bin the whole idea, start anew from scratch, actually sketch out an idea of a world we’d like to live in and work from there.

However, I was intrigued by the critiques that have popped up since yesterday, because they seem to delve in rather different directions and sometimes seem to accept power imbalances and societal constructs as immutable givens. The discussion is, of course, still ongoing. Nonetheless, I felt I should write down what popped into my mind after diving into the proposal.

What are CC Signals?

That proposal – and the discussion that followed on Mastodon and the Github issues – seems to center around one specific side effect, namely the practice of scraping huge swaths of the Web to gather material that is then used to train generative models. Be it text for LLMs, imagery and videos for image generators, or all of the above for hybrid models.

People who actually produced the works that are now being scraped to produce generative models have been… rather unamused by this practice. Creative Commons (the organization) appears to have been compelled by this sentiment to propose so-called Signals that are independent of the existing CC Public Licenses. They may be used in conjunction with CCPL, but do not need to, as far as I can tell from the writeups.

This kind of makes sense, since one open question is whether traditional licenses such as CCPL even make a legal difference when it comes to the question whether a third party may scrape and analyse corpora on the Web. More on that later.

The proposed Signals have four dimensions which I will try to summarize here as closely as possible:

  • Credit: This signals an expectation that the provenience of source material is credited (“appropriate credit based on the method, means and context of your use“)
  • Direct Contribution: This signals an expectation of “monetary or in-kind support to the Declaring Party”, “based on a good faith valuation” (of the source material and the effort to maintain it)
  • Ecosystem Contribution: As in the Direct Contribution, but this time providing monetary or in-kind support to “the ecosystem”. The expectation outlined in the accompanying writeup (PDF) is that this shall “support the commons as a whole”
  • Open: This sets the expectation that the resulting “AI System” shall be “Open” (intentional scare quotes). The accompanying writeup speaks of “reciprocity”, and the ways of satisfying this requirement is explicitly listed as adhering to the OSAID or the MOF Class II or Class I

Much could be written about the creeping re-definition of the term “Open” alone. First through introducing the term (“AI systems released under free and open-source licences”) into the AI Act (see also Recital 102, Recital 103, Recital 104 and Recital 107 of the AI Act). Then through the OSAID and the MOF. And now through CC explicitly referencing OSAID and MOF as “open”. And this all probably goes back even way longer.

Alas, we’re navigating through a hype-driven water park where Red Herrings abound. In my opinion, each and every of the proposed Signals introduces a rat’s tail of consequences that might work against a society where we freely share resources. So let’s dissect this piece by piece.

“AI” is more than generative systems

Just to get this out of the way and keep it in mind: When we’re trying to regulate or deal with “AI” in a legal sense, this encompasses more than just generative systems. The AI Act seems to explicitly include symbolic AI systems in its scope (Article 3, Recital 12).

I have not seen any definition within the CC Signals proposal what they actually mean to be “AI”. The language suggests that it is aimed towards trained models, but also announces categories such as TDM, training and inference. This all might very well encompass long-standing practices of scraping websites, building a formal knowledge base from the text on that site and using something as old-school as Prolog for inference. Just to set one’s environment variables, one might say.

Why Signals anyway? What’s with Licenses?

One question I’ve seen thrown around a bit since yesterday goes along the line of “why not create licenses that somehow regulate re-use for genAI training?”

Part of this question had already been answered some two years ago by Creative Commons in a blog post titled “Understanding CC Licenses and Generative AI”. The gist: All the Open Cultural Licenses we have come to use and like are based on copyright. They are applied to creative works, be that a piece of software code, this very blog post, a photo or video somebody made, a song, a painting… the list goes on. Under current copyright legislation, any of these creative works have the label “all rights reserved” slapped onto them. If somebody wants to reuse such a creative work in a way that requires permission under copyright, Open Cultural Licenses have been a way of granting a standardized license to everybody that grants them the rights to reuse under certain conditions. Naming the original creator, linking to the terms of the license? Those are clauses of many of the licenses that any re-user has to fulfill, otherwise the license is void.

The important part is the thing with reuse in a way that requires permission under copyright. Copyright has expanded… quite a bit over the past century. Often, this has been framed as a service to creators who shall live off their creative works. It is worth keeping in mind, though, that the actual benefiters of ever expanding copyright are usually the publishers. As Lawrence Lessig put it in 2003: “The publishers, such as the recording industry or the movie industry, aren’t so much defending the
rights of creators, they’re defending a certain business model.“

Despite that “feature creep” of copyright legislation, there have always been nices carved out that are not covered by it, in the form of limitations and exceptions – and that has been a good thing so far. Be it quotations, accessibility, research, private copies, freedom of panorama: Within the EU they all rely on those limitations and exceptions. Current efforts towards a right to repair seek to carve out new niches like this.

And, lastly, we have seen an exception for Text and Data Mining (TDM) within the EU. Up to that point, actors who scraped resources on the Web for analysis or providing better access to factual information (decoupled from protected creative expression!) within those resources ran a risk of being dragged to court. Open Data Activists were subjected to lawsuits when re-arranging information that is publicly available on the Web as recently as 2021. Legally, this last case is a bit different from TDM in the narrower sense, but I think it serves as an example how copyright legislation has been preventing us as a society to access and re-use information that ought in not only my opinion be freely reusable, by anybody.

Coming back to the point: Be it the TDM in the EU or Fair Use in the USA, there is reason to believe that those exceptions might apply to scraping and using information on the Web for anything AI, including for training generative AI models. Which means that this might be reuse that does not require permission under copyright. And therefore, any restriction within Open Cultural licenses, such as crediting a source, Share-Alike clauses or the dreaded Non-Commercial clause of the CCPL have no bite.

It is worth keeping in mind that Open Cultural Licenses have been and continue to be a “hack” of IP legislation. IP legislation and copyright assume a society in which creative works are meant to be licensed in exchange for currency or goods, and even need to be sold in order to meet one’s basic needs.
I have always understood the idea of Digital Commons to be an example in which we – or, more accurately, a bourgeois subset of society that can actually afford to do so and is not dependent on income from their creativity – provide creative works as Commons to the whole society. In order to demonstrate how a world could look like in which anybody can reuse such works for any purpose and how sharing and collectively caring for the Commons could be an alternative to established practices which we have come to take for granted and natural.
But more on that later.

I see your TDM exception, I raise with the TDM Opt-Out

Of course, I cannot just mention the TDM exception without mentioning the rights reservation mechanism that was introduced alongside it. Article 4 (3) DSMCD states that the exception applies on condition that “the use of works and other subject matter referred to in that paragraph has not been expressly reserved by their rightholders in an appropriate manner, such as machine-readable means in the case of content made publicly available online.”

How this rights reservation could look like in practice is part of an ongoing discussion. There has been an… original court decision that discusses how any human-readable declaration might also be machine-readable – because, the court reasoned, if those AI systems are as powerful as the vendors claim, they should have no problems at all to recognize a rights reservation declaration that has been scribbled onto a napkin, right? (This is yet another rabbit hole I do not have the time to dive into for this article. Unfortunately or fortunately :D)

Relevant for the Signals proposal: The stance of Creative Commons from 2021 is that the CC licenses “cannot be construed or interpreted as a reservation of a right in the context of Article 4 of the EU Directive on Copyright in the Digital Single Market (EU 2019/790) or any of its national transposition instruments.”

One could, of course, craft a new version of the CCPL that includes a module for TDM opt-out. I have no idea what effect this would have on fair use or any other exception outside the EU. Any such clause would, however, opt out of TDM for any purpose, with the exception of research “on a not-for-profit base or in the context of a public-interest mission recognized by the State.” (Recital 12 of the DSMCD).

Careful consideration would be necessary how not to “accidentally” craft a license regime that could be used by corporations to flat-out forbid any civic tech activists from scraping and republishing data from them in order to facilitate better access to information. And this goes right at the heart of the dilemma: All the proposals that I’ve seen so far that seek to use IP legislation to reign in genAI scraping are trying to use a legal tool that traditionally gives way more leverage to the wealthy and powerful.

Adversarial models: How to shoot your self in the foot, online.

After having set the scene, let’s finally look at the proposed Signals themselves. What I like to do in such cases is to Monkey’s Paw the heck out of them: Let’s assume this all is in place and construct some undesired consequences that come to mind.

Credit and where it might be due

We have become accustomed to crediting when using creative works that have been released under Open Cultural Licenses. Kudos at this point to all the licenses: They have been able to shape a cultural assumption that this is the way it ought to be!

However, when creating joint works that incorporate many sources – especially datasets – this has proven tedious to implement in practice. OpenStreetMap only incorporates data that comes with a waiver allowing them to credit contributions on an external page, not directly below the slippymap. And it might be rather obvious why this is the case.

The actual benefit of this attribution practice can also be called into question in certain circumstances. If you purchase a Smart Watch, or a modern automobile, or any sufficiently “smart” household appliance, chances are high that that product uses Free and Open Source Software that requires the vendor to deliver the respective license and attribution to you.

You might feel like you’re having a slow weekend and finally read all those licenses and attributions. Tapping through the display on your blender, or scrolling down the in-vehicle screen of a car, you are free to review sometimes thousands of pages that somebody took the pain to compile (and keep up to date) in order to adhere to the license. I have yet to find out how this strengthens the F/LOSS ecosystem, but here we are.

Things get even murkier when we talk about TDM in order to, say, craft knowledge bases for symbolic systems. Let’s say I have done that and now perform SPARQL queries on the end result. The sources of which parts of the graph do I have to display for appropriately crediting?

I can, to some degree, see the point when a LLM uses RAG for its output, as is mentioned in CC’s PDF writeup. That is, however, decoupled from the TDM and training stages that the Signals proposal claims to address. (This part also brings up memories from way back when some actors claimed that indexing the Web for search engines constitutes copyright violation – yet another rabbit hole.)

However, citing a source when using RAG kind of re-frames the whole reasoning behind why one should cite a source. In the case of re-using actual creative works, this is based on the author’s moral rights that are secured by copyright. We might be operating under the assumption that there is still a moral right to have my name cited if the text I produce here ends up being a mere drop in the bucket for any statistical analysis (again, let’s not get distracted by laser-focusing on genAI, let’s look at the general mechanism).

On the other hand, if I cite a source in making an argument, or if a scientist cites sources in an analysis, neither they nor I do that because this is a commonly accepted moral obligation. Instead, they and I cite sources because it is a method of underpinning the argument one tries to make. It enables others to reproduce the line of thinking and elevates a mere statement to something that could be knowledge.

There is also a whole load of practical considerations tied to the Credit Signal. From link rot to maintaining the credit repository to source disambiguation – even in everyday science applications, it is not always possible to link back to a canonical source even for some document that one “knows where it came from”. Mix in different steps of aggregation and you’ll end up with some form of crediting that is of no use to the “Declaring Party” and just drags along a cumbersome metadata catalogue.

All of this looks to me like a mere distraction. It does not solve anything that I can identify and invites bike-shedding discussions on how to actually implement it. This time could be better spent.

Direct and Ecosystem Contributions: Turning Commons into Commodities and introducing false incentives

I must confess, I find it very hard to wrap my head around the Direct and Ecosystem Contribution Signals. And even more so considering this proposal comes from Creative Commons. CC claims that this is some kind of “reciprocity” and that “A Thriving Commons Requires Reciprocity”.

I am tempted to slap a big [CITATION NEEDED] onto every of these statements. The PDF mentions that the Commons are based on an assumption “that we are all in this together”, that “knowledge and creativity are building blocks of our culture, rather than just commodities from which to extract value,” and that the social concept of reciprocity that CC proposes to introduce “is not transactional”.

How one can start at this point and end up with not one, but two Signals that are very, very much based on transactions, remunerating one side of the transaction monetary or in-kind, and going so far as trying to valuate the “good” that is being exchanged, is beyond me.

My first reaction to this was pretty much the same I had when first thinking about the TDM opt-out mechanism and how there is an entryway to monetizing stuff on the Web: Cool, now we have constructed an incentive to flood the Web with slop even more.

I believe that any financial incentive will be gamed. Maybe this will end up choking genAI vendors, maybe it won’t. But I can’t see how “we,” just ordinary denizens of the Web won’t bear the brunt of the whole Web getting even more enshittified.

But let’s assume this were to actually work, in the way it seems to have been intended. What could be the outcomes?

Releasing creative works to the public under CC licenses has, so far, been mostly an endeavour for people who can afford to do that. One might assume that they are at the wealthier end of the global spectrum – be it monetary or in free time (which usually can be exchanged for another). The proposed Signals open the possibility for these people to get some remuneration out of it. Nice, right? Lets put aside for a moment (sarcasm marker!) the issue that neither the click workers in the Global South that are exploited in the production process of genAI get anything out of this proposal, nor do the infrastructure administrators onto whom the costs of constantly scraping the Web for ever more genAI training are being externalized.

So, ignoring those pesky details, we do have some redistribution of funds between the genAI vendors (assuming they adhere to the Signals) and some of the more wealthy people, on a global scale. There might also be some redistribution between some genAI vendors and “The Ecosystem™”. Even nicer, right?

Just one question:

How?

What is the idea how this would work in practice? That’s a valid question, right? And I truly believe it pays to think this idea through to the end.
Does anybody remember Micropayments? Like Flattr? Feels like a blast to the past, huh? Or, wait, maybe that is not the right approach. What are other alternatives that already do this distribution? Oh, right. Collecting societies. You know, GEMA, MPLC, all those names that sound rather familiar to anybody who followed the copyright wars over the past, let’s say, two to three decades.

Or, of course, we could think about just creating our own collecting society! Independent from the baggage of the others! Something nobody has considered before… apart from, say, C3S, which had been proposed so long ago that its Blog with their launch announcement has already been offline for over ten years. Others might remember the Kulturwertmark (de) proposed by Chaos Computer Club in 2011.

This all feels like reinventing a wheel that has already been discussed way more deeply, without having analyzed the insights from way back when. Some already privileged people might benefit from the mechanism behind that. Others, who are also exploited in the process of genAI training, are not. It’s unclear how this is supposed to work in practice. We might gravitate towards creating new structures for that, which follow the form and shape of existing structures that have not proven to be beneficial to the idea of the Commons up to now.

Open: Reframing “Openness” beyond recognition

Lastly, the “Open” Signal. Le sigh.

Much has been written on the ongoing reframing of the term “Open” when it comes to genAI models. See, for instance, “Open (For Business): Big Tech, Concentrated Power, and the Political Economy of Open AI”, or “Rethinking open source generative AI: open-washing and the EU AI Act”. Other takes seem to have no squalms applying the term to constructs like “you can download a trained model and fiddle around a bit with its weights“.

Gone seem to be the ideas that this might all be about power structures and how to rebalance them. Granted, yes, I know, I know, even ideas like Free and Open Source Software have never been able to actually seize and distribute the Means of Production to the actual “masses”. Just like with Open Cultural Works, this has been mostly a court for a privileged few, so far.

One might argue that even this limited redistribution already kind of fulfills at least the first steps towards another vision of how we produce stuff as a society. How this makes another mode of production thinkable. How not all of society needs to partake in this production for the results being available to potentially everybody, without gatekeepers in the way. One has to remain optimistic, right? See the strange reciprocity argument: Even if 99,99% of all people just use Open Cultural Works in any sense (reading Wikipedia, using OpenStreetMap etc pp) without ever contributing back, that’s fine as long as there are enough other people contributing and maintaining the Commons without expectation of remuneration.

However, the main point for me is that this is at least somehow about shifting power dynamics. And it looks like, while “Openness” is in danger of becoming yet another Magic Concept or has already become one, the popularization of “Openness” has gone hand in hand with gutting anything power-relating from the term.

Personally, I find the OSAID definition and the MOF (maybe excluding Class I) highly problemativ and regressive. At most, many of the systems adhering to these definitions might have been called “freeware,” you know, back in the day. And even if those models were published in a way that could be replicated by anybody – even out of the select few who can now compile their own Linux kernel etc, only the tiniest fraction would be GPU-rich and electrical-power-rich enough to actually recreate any generative AI system even theoretically, and then we’re at the question whether we’d actually want even more actors going around scraping the Web at scale, putting even more external costs on the people running, you know, the actual infrastructure we have come to rely on and now we’re at the point of asking what is this “Openness” even supposed to mean anymore?

What I found very interesting is the question of how the enclosure of the produced models even works, in practice. Assuming, a model and its parameters have been published somewhere – regardless whether on purpose or “by accident”. How could a vendor slap a license on it and expect me to adhere to it? “The Mirage of Artificial Intelligence Terms of Use Restrictions” is one paper that dives into this question, not surprisingly also the IPO back in 2020. I had a hunch back in February that turned out to be right: The most likely framework within which any license could apply to a trained generative model is… the EU Sui Generis Right for Database Creators. Because training a model likely constitutes a substantive investment, and the SGDR is supposed to protect that investment.

So we have a situation in which scraping the Web for training purposes might not be subject to copyright law, but the resulting product is. Based on a controversial piece of legislation that has stood in the way of access to knowledge for everybody time and again. I’m not saying that this would solve anything, but maybe, just maybe, advocating for reforming SGDR might be a better idea than fiddling around with ever shoddier definitions of “Openness”.

Other Side Effects and introducing unwanted expectations

This has become far too long already, but some points should still be considered. This whole proposal looks to me as if it raises expectations that all this genAI stuff can be dealt with by just expanding on licenses, copyright and existing structures. It seems to normalize expectations of “crediting” that have proven to be a fractal broccoli of practical problems and of a moral right to determine not only how creative expressions (that are subject to copyright law) can be re-used, but also factual tidbits embedded in them, or statistical analyses. As described by Denny Vrandečić over a decade ago, popularizing such notions can lead to more restrictions to re-using data. And those notions are not only received by you and me who might be fed up with the current genAI hype, but also, say, public institutions looking for a way out of providing information to the public in re-usable form.

Also, even starting to think about how this could be enforced in practice dishes out yet another fractal broccoli. How would one identify somebody who does not adhere to a Signal, or an opt-out clause? Maybe, through some massaging, one can make some trained model to spit out a paragraph that looks like a direct lift from one’s work. But how did it end up there, especially in the age of “synthetic datasets” (i.e., building a Human Centipede AI)? Even if synthetic datasets were not a thing, let’s say I see crawlers that trawl my servers. Looking at how they try to hide behind residential IP ranges, what’s the idea what should happen then? Are we now arguing for Data Retention to get hold of the perpetrators?

Not to get me wrong: I am absolutely not arguing that the Web ought to be a free-for-all for genAI vendors. Not in the slightest. The point I am trying to make is that the approach I see in the Signals proposal has the potential to roll back the clock on achievements we made towards a sharing culture where we end up with more for everybody, and towards a Web that is not just yet another commercial marketplace. I fail to see any vision in the proposal what a future world based on Digital Commons could look like. It looks more like wanting to go incremental steps, starting from the status quo and taking all the constructs that are already in place as granted, normal and the way they ought to be. Simultaneously turning the Commons into Commodities, for whatever reason.
And, frighteningly, in more than one place, people now start arguing explicitly or at least in consequence for measures that have been considered “the weapon of the enemy” for decades.

We could instead talk about how the costs that are currently being externalized – on creators, but also on click workers and infrastructure maintainers – be internalized for the genAI vendors. The Signals proposal only addresses creators, and in a oddly skewed way. Maybe we should talk about taxation more. Or other means that redistribute the current gains of genAI vendors – if there even are any, who knows, maybe it’s just about capitalization – not only to creators, but to everybody. Which might lead to mundane things like school toilets being fixed. Or other goals we might like to have as a society.

Automation will create wealth, but under current economic conditions much of that wealth will flow to the owners of the automated systems, leading to increased income inequality.

Russell and Norvig. Artificial intelligence: a modern approach.

Then, of course, we would have to not just swim with the hype current and tack on some new wallpaper onto crumbling walls, but try to shift the conversation about genAI in general. How mechanisms for redistributing the gains and internalizing costs might be a desirable way forward even if they stand in the way of unshackled genAI futurism. Questioning whether unshackled genAI futurism is desirable in itself, instead of taking it as an immutable and logical way forward. How just fine-tuning the sham “Openness” dial or sprinkling some magic “for the common good” spices over that stew just doesn’t cut it.

And, not least, how a way towards more Commons, more sharing, more wealth for everybody could look like. I don’t know, maybe enabling way more people to have enough free time that they don’t need to spend at work or flooding the Web with slop in order to crunch a few pennies from genAI scrapers so they have a roof over their head and enough to eat might be an interesting idea. You know, just taking this idea of the Commons and look how this could not be just a luxury endeavor for a select few.

(Current, further reading: The Signpost from June 24th reviews recent research yet again. A valuable resource that tends to fly under the radar way too often.)

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

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 🙂

How to do a firmware reset on the Rode Wireless Go II if it does not charge anymore but you only have Linux machines

Addendum some weeks later: Apparently, this worked when upgrading the Firmware from version 2.0.5 to 2.5.0. When I tried updating another set running 2.4.something recently, the workaround did not work, unfortunately.

I recently came across an annoying bug with the Røde Wireless Go II set we use at work: The receiver was completely discharged every time it came out of the charging case (which is supposed to keep it charged).

This was not that big an issue when using it as a USB audio interface with its wireless microphones, but was enough of a hassle when I wanted to use the set standalone today that I looked into whether this is a known issue.

Turns out: Yes. Both the receiver and the transmitters can have this bug, with users reporting the devices arriving dead on arrival with completely discharged batteries and not wanting to charge anymore.

This is very frustrating (and not a good look on Røde) all by itself, but the remedy is yet another hassle. The number one source on a fix is a reddit post from some two years ago, and judging from the comments, it has helped quite a lot of annoyed customers. The fix is to… download the Rode Central software and do a factory reset and firmware upgrade.

The software is available for Windows and MacOS, but there is apparently no Linux version. Sleuthing around the Webs did not provide any pointers, so I downloaded the Android version, connected (initially) the receiver via USB-C, fired up the App, clicked through the firmware update dialogue and… was stuck with this screen:

Please use the desktop version of RØDE Central to install this update.

So, no luck with the mobile version? I’d have to find a Windows Laptop or Macbook somewhere, persuade the owner to install the Røde software in order to perform a firmware upgrade on a set of wireless microphones to make them charge again?!

Okay. Well.

I had almost accepted my fate when by pure chance I found a workaround to perform the firmware upgrade even from the Android App. I did not think quickly enough to take screenshots when getting the receiver to upgrade, so the screenshots are from when I upgraded the transmitters as well. The “trick” (if you can even call that a trick) is this:

When the app first notifies you that there is a “Firmware Update Required”, you are presented with two buttons. One is tapping on “Got it” – which will lead you to the error message above that tells you to use the desktop version.

But, if, out of curiosity or an urge to keep no path unchecked, you tap on the small message below that reads “How to prepare for the firmware update”, you will at first encounter a step-by-step preparation guide. That tells you to always update all of the devices, not just one of them, have the devices charged, etc.

And then, and only then, if you tap again on the familiar “Got it” button…

…you can actually update the firmware. From an Android device. Without having to look for some Linux workaround (that usually ends up in yak shaving for at least hours)

In the end, it worked. The standalone setup worked. And only as I am writing this down (so that, maybe, others can be led towards the right path just as I had been led toward the first steps by that Reddit post) I am realizing that I didn’t check whether the set still works via USB. I’ll keep my fingers crossed.

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

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: -stkCC 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: LooniverseCC 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: LooniverseCC 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.

Der ICE-Steckdosenhack

Seitdem ich im Juli 2022 angefangen habe, in Berlin zu arbeiten und dafuer staendig zwischen Berlin und Sueddeutschland hin- und herzufahren, hatte ich mich immer wieder ueber Laptopnetzteile geaergert. Anfangs hatte ich derer zwei: Eins fuer mein privates Thinkpad (Flachstecker 20 Volt) und eines fuer den Arbeitslaptop (damals Dell, Hohlstecker). Das war etwas unkommod.

Im Februar 2023 fiel mir auf, dass es mittlerweile Adapter mit USB-C-PD-Triggern fuer diverse typische Laptopladebuchsen gibt. Ein PD-Trigger sagt dem USB-C-Netzteil (mit Power Delivery) „hallo, ich bin ein Geraet, das gerne z.B. 60 Watt in Form von 20V bei 3A haette, kommen wir da zamm?“, und wenn das Netzteil das kann, dann geht sich das tatasaechlich zamm. Auf der anderen Seite des Triggers kann diese Leistung dann in die richtige mechanische Form fuer den benoetigten Laptop-Ladebuchsentyp verwandelt werden.

Dank Fleaz bekam ich einen passenden Trigger-Adapter fuer mein Thinkpad, ueber ebay holte ich mir einen fuer den Arbeitslaptop, und ab dem Zeitpunkt hatte ich immer nur ein USB-C-PD-Steckernetzteil mit einem USB-C-auf-C-Kabel dabei, das dann wahlweise den einen oder den anderen Laptop lud, und nebenher auch noch per USB-A andere Geräte.

Eigentlich ganz nett, in der Praxis machte das dann aber bei Zugfahrten mehr Probleme als erwartet. Das Steckernetzteil steckte nun etwas unkommod und klobig zwischen den ICE-Sitzen in der Steckdose, und das USB-C-Kabel ragte seinerseits aus diesem Netzteil nach vorne heraus. Wenn die Person auf dem Fensterplatz den Sitz verliess und dabei ueber das Kabel stieg (also in der Regel halt ich, der zu faul war, dann das komplette Netzteil auszustecken), fuehrte das oefter mal zu mechanischen Beanspruchungen. Kurz gesagt: Ich habe alle drei Monate den USB-C-Steckverbinder eines neuen Kabels abgerissen und war dann stromlos.

Dieses Problem loeste sich ein wenig, als ich ein neues Arbeitslaptop mit USB-C-Netzteil bekam. Der Netzteilpart liegt dann einfach auf dem Boden herum, das Kabel mit dem USB-C-Stecker geht in den Laptop oder den PD-Trigger fuer mein Thinkpad, und zwischen Steckdose ist ein duennes Netzkabel, fertig. Praktisch.

Der Netzstecker war aber kein Schuko-Stecker mehr wie bei meinen alten Netzteilen, sondern ein Eurostecker. Und der wackelte haeufiger mal in der Steckdose und hatte einfach keinen Kontakt, und man musste dann komisch in der Steckdose herumwackeln und -bohren und den Stecker in genau diese eine Position legen, in der er Kontakt mit der Steckdose bekam. Das war jetzt einfach nur auf eine andere Weise nervig. Laut Infos von Bahn-Insidern habe ein namhafter Zughersteller hier einfach ein paar Cent pro Steckdose gespart und deswegen sind die raeudig. Diplomatischer ist das in diesem Zeit-Interview formuliert.

Die Loesung fuer dieses Problem ist simpel, billig und funktioniert: Man gehe in einen Elektrodiscounter und kaufe sich einen Zweierpack Adapterstecker von Schuko-Stecker auf zweimal Euro-Steckdose. Zweierpack deswegen, weil das die guenstigste Variante ist, die ich fand – bei Media Markt hatte ich 2,99 EUR dafuer bezahlt und hatte dann noch einen zum Weitergeben uebrig.

Das funktioniert deswegen besser, weil die Kontakte eines Schukosteckers auf der ganzen Laenge von 19 mm elektrisch leitend sind und einen groesseren Durchmesser von 4,8 mm haben. Beim Eurostecker sind nach Norm nur die vorderen 9 mm der Kontaktstifte leitend und haben einen Durchmesser von „nur“ 4 mm. Und das macht wohl den Unterschied. Mit dem Adapter hatte ich die Kontaktprobleme seither nicht mehr – und man kann die Steckdose einfacher mit der Sitznachbarin teilen. Man muss sich nur daran erinnern, den Adapter fuer Zugfahrten einzustecken. Oder man hat Glueck und faehrt, wenn man den Adapter vor der Urlaubsreise vergessen hat, mit Zuegen wie dem Railjet, wo zwei Multinormsteckdosen mit gutem Kontakt zwischen den Sitzen einfach ganz normal sind 😉

(Die Veroeffentlichung dieses Artikels im Blog hat derweil ein geschmeidiges halbes Jahr gebraucht, weil ich so lange gebraucht habe, um die PD-Trigger im Objektfotostudio zu fotografieren und auf Commons zu laden. In der Zwischenzeit habe ich einen der beiden Adapterstecker bereits versehentlich in einer ICE-Steckdose zurueckgelassen.)

Wir haben Server zuhause

Irgendwann habe ich geseufzt und mir eingestanden: Okay, es ist soweit.

Angefangen hatte das alles ganz harmlos. Im Maerz 2020, kurz bevor das alles ganz anders wurde, hatte ich mir einen Raspberry Pi 4 gekauft. Ich kann mittlerweile gar nicht mehr nachvollziehen, wie viele RasPis in welchen Varianten ich ueber die Jahre wann besessen habe und vor allem wo manche davon seither hingewandert sind. Die waren auch super, als vertiefender Einstieg in den Umgang mit Linux und Hardware, um mal testweise einen Miniserver fuer ein Projekt zu haben, oder (meistens) um irgendwas mit Digital Signage zu machen.

Die anderen Pis, die seither bei mir herumlagen, waren auch vorwiegend Reserve, um einen Node fuer info-beamer als Digital-Signage-Loesung zu haben, ganz sporadisch habe ich sie als Retrospielekonsole oder andere Sachen benutzt. Die meiste Zeit lagen sie aber einfach herum.

Mit diesem Pi sollte das aber anders werden. Ich wollte endlich mal Home Assistant als selbst betriebene (und kontrollierbare) Heimautomatisierungsplattform ausprobieren. Zunaechst nur fuer ein bisschen Sensorik fuer die Temperatur in der alten WG, dann kamen ein billiger Zigbee-Stick (den ich erst einmal umflashen musste) und IKEA-Zigbee-Leuchten dazu, dann Bewegungsmelder und erste Automatisierungen, dann Stromverbrauchsmessung mit Shelly, der Drucker im Netzwerk kann auch irgendwie gemanaged werden… man kennt das ja. Jedenfalls hatte ich auf dem Pi Home Assistant OS fuer Raspberry Pi installiert und dann lag der irgendwo und hing an Strom und Netzwerk (und ich kann mich ehrlich gesagt gar nicht mehr erinnern, wo in der WG der rumhing) und machte einfach, 24/7.

In die neue WG in Neu-Ulm habe ich einfach 1:1 das meiste umgezogen und immer wieder was dazugebaut, zum Beispiel „smarte“ Heizkoerperthermostate zum Gas sparen, weil ich damals noch nicht wusste, dass der viel ausschlaggebendere Part die richtige Einstellung der Brennwerttherme ist – aber das waere etwas fuer einen anderen Post.

Es fing mit Home Assistant an und dann baut man eine Kuechen-Arbeitsflaechenbeleuchtung mit der Fraese, LED-Streifen und WLED. Wer kennt es nicht.

So haette das eigentlich weitergehen koennen mit dem Pi, auf dem Home Assistent vor sich hin werkelt, wenn ich nicht irgendwann das Dokumentenverwaltungssystem paperless-ngx kennengelernt haette. Wobei das vermutlich gar nicht stimmt – ich kann gar nicht mehr sagen, wann ich das kennengelernt hatte, es muss spaetestens im Spaetsommer 2023 gewesen sein und es blieb erst einmal bei Neugier und Interesse. Der ausschlaggebende Faktor war eher, dass ich irgendwann beschlossen habe, dass ich das haben will. Eventuell endgueltig ausgeloest durch den Vortrag auf der MRMCD2024, eventuell durch Berichte, wie man sich mit ausgedienten Thin Clients einen kleinen Server aufbaut, der aehnlich viel/wenig Energie wie ein Raspberry braucht, aber gleich mehrere Dienste auf einmal fahren kann – also beispielsweise auch paperless-ngx parallel zu Home Assistant, alle in ihrer eigenen Virtualisierung.

Im November letzten Jahres habe ich also nach einer unnoetig intensiven Recherchephase 50 Euro in die Hand genommen, und mir einen gebrauchten Dell Wyse 5070 Thin-Client gekauft. Dass ich das hier schreibe, traegt vermutlich nur weiter dazu bei, dass die Teile stark nachgefragt und die Preise relativ hoch bleiben. Andererseits erhaelt man hier fuer einen vergleichbaren Preis eines RasPi 4 ein Geraet, das:

  1. sein eigenes Gehaeuse mitbringt
  2. eventuell sogar ein Netzteil
  3. je nach Angebot von Haus aus mit mehr RAM als der preisaehnliche Pi daherkommt, den man aber bis 32 GB erweitern kann
  4. bei minimal mehr Energiekonsum deutlich mehr Rechenpower hat
  5. passiv gekuehlt ist – das ist der Pi natuerlich auch, die meisten „kleinen“ Rechner haben aber aktive Belueftung
  6. eine x86-Architektur hat, d.h. da laeuft einfach „normales“ Linux drauf, ohne irgendwelche Architekturbesonderheiten beruecksichtigen zu muessen

Eine schoene Uebersicht, wie man RAM erweitern, eine andere SSD einbauen und das BIOS auf den aktuellen Stand bringen kann, hatte ich vorher schon bei Heckpiet gefunden. Mein Angebot kam ohne Netzteil, aber da ich irgendwann mal keine Lust mehr hatte, fuer mein altes Dell-Arbeitsnotebook und mein persoenliches Thinkpad je ein Netzteil mitzuschleppen, hatte ich mir bereits passende USB-PD-Adapter zugelegt, so dass ich die Kiste einfach mit einem USB-C-Netzteil testen konnte.

Die ersten Wochen habe ich mich einfach an Proxmox als Host-System herangetastet und Dinge ausprobiert. Durch ein weihnachtliches Schrottwichteln und noch herumliegende Sachen kam ich an eine passendere groessere M2-SATA-SSD und 16 GB RAM (also nochmal deutlich mehr als der groesste Pi 4), so dass ich mich nach der Eingewoehnungszeit daran machte, Home Assistant auf die neue alte Maschine umzuziehen und parallel mit ein paar anderen Diensten zu spielen – durch die Proxmox Helper Scripts hat man ganz schnell mal eben testweise nicht nur paperless installiert, sondern nach was einem sonst noch der Sinn ist.

Und dann war auch der Moment gekommen, um die „alte“ Installation vom Pi auf den neuen Server umzuziehen… und dann natuerlich laengere Zeit Fehler auszubuegeln, weil nicht alles so reibungslos ging wie erhofft (ich hatte beispielsweise den Billig-Zigbee-Stick durch einen moderneren ersetzt – das bedeutete aber wohl auch, das ganze Zigbee-Netz mit allen Geraeten neu einzurichten).

Nun bin ich also offiziell einer dieser Menschen, die „einen Server betreiben“. Also einen obsoleten Thin Client im Wohnzimmerschrank. Mit Proxmox-Virtualisierung drauf. Von dem man aber immerhin einfach gar nichts mitbekommt, weil er keine Geraeusche macht und einfach nur laeuft, so wie der Pi vorher. Das mit dem „Server betreiben“ fuehlt sich immer noch seltsam an. Aber seither habe ich tatsaechlich auch paperless-ngx, um meinen Papierkram besser zu ordnen. Und mittlerweile auch noch ein paar Sachen mehr. Und das fuehlt sich ehrlich gesagt wirklich zufriedenstellend an!

(Das illustrierende Artikelbild ist gar nicht der 5070, sondern ein Fujitsu Esprimo Q920. Ich hatte die letzten Tage festgestellt, dass es auf Wikimedia Commons kaum Fotos der aktuellen Thin Clients gibt und dachte, ich fotografiere mal welche. Ich kam nicht dazu, „meinen“ zu fotografieren, aber habe wenigstens gestern als Commons-Objektfotografie ein paar Fotos eines im temporaerhaus liegenden Q920 gemacht – nur um dann festzustellen, dass das genau genommen gar kein Thin Client ist, sondern ein nochmal deutlich leistungsfaehigerer Mini-PC, dafuer eben mit mehr Energieverbrauch und aktiver Lueftung. Auf meinen Aufruf von heute morgen hin haben aber Menschen sogleich neue Fotos u.A. der kleineren Variante 3040 hochgeladen. Vielen Dank dafuer!)