Lage.Bonn

Vision

🇬🇧 English: VISION.md

Zeigen, wie es einer Stadt geht, wer sich um ihre Probleme kümmert und welche Möglichkeiten angeboten werden — aus offenen, prüfbaren, quellengetrennten Daten.

Lage ist heute ein deterministischer Bonner Nachrichten-Aggregator: holt lokale Feeds und offene Verwaltungs-APIs, geo-taggt sie bis auf Ortsteil-Ebene, dedupliziert über Quellen hinweg und gibt einen Atom-Stream aus. Das ist der Boden, nicht die Decke. Dieses Dokument beschreibt, wohin das Projekt steuert und warum.

Wie es hilft — drei User Journeys (Minimum Lovable Product)

Erst der Nutzen. Das MLP ist nicht „ein Feed, der funktioniert" — es sind drei Momente, von denen eine Bewohnerin ihrer Nachbarin erzählen würde. Jeder bildet eine der drei zivilen Fragen ab, die das System beantwortet, und stützt sich auf genau eine Design-Festlegung, sodass das Liebenswerte das Ehrliche ist.

1. „Was ist gestern am Münsterplatz wirklich passiert?"

Lena, 34, sah auf dem Heimweg eine Demo und über Nacht drei widersprüchliche Posts dazu. Sie öffnet Lage, tippt auf das Ereignis in der Karte.

Sie sieht ein Ereignis — keine fünf Duplikate — mit nebeneinandergestellten Darstellungen: 2.000 (Polizei) · 5.000 (Veranstalter) · 37 geo-getaggte Posts (unbestätigt). Jede Zahl ist eine Behauptung mit Quelle und sichtbarem Verifizierungs-Badge; die Polizei-PM ist verlinkt, nicht erneut gehostet.

Liebenswerter Moment: Das Werkzeug sagt ihr nicht, wer recht hat. Es zeigt ihr die Lücke, ehrlich gekennzeichnet, und traut ihr zu, sie zu lesen. (Festlegung: Ereignis ≠ Bericht ≠ Behauptung.)

2. „Wer ist für dieses Schlagloch zuständig, und tut jemand etwas?"

Tomas, 51, umfährt seit Wochen denselben Krater auf der Adenauerallee. Er findet die Stelle in der Karte und tippt auf das Anliegen.

Er bekommt den Open311-Status (in_bearbeitung), den zuständigen Akteur (Tiefbauamt Bonn) und — weil ein Bauprojekt verlinkt ist — den Beschluss des Rates hinter der anstehenden Kanalsanierung, als Link direkt in den OParl-Datensatz. Eine klare Kette von meiner Straße zu wer was entschieden hat.

Liebenswerter Moment: ein Rechenschaftspfad, der bei einer echten, zitierbaren Entscheidung endet, nicht bei einem toten „gemeldet"-Status. (Festlegung: Verlinken, nicht kopieren — OParl bleibt Source of Truth.)

3. „Gibt es für mich etwas zum Radfahren in Bonn?"

Amara, 28, will mehr radeln, aber die Radwege wirken festgefahren. Sie öffnet den Indikator Radverkehrsanteil: 24% heute, Ziel 35%.

Direkt neben der Zahl die Angebote, die ihn adressieren: die Lastenrad-Förderung (Umweltamt) und die Beteiligungsfrist für den nächsten Radverkehrsplan. Der Indikator hört auf, eine einsame Statistik zu sein, und wird zur Tür zum Handeln.

Liebenswerter Moment: Zustand der Stadt und Möglichkeiten der Bürgerin stehen in derselben Ansicht — eine Zahl, mit der sie etwas tun kann. (Festlegung: Provenienz ist erstklassig — jeder Indikator und jedes Angebot trägt Quelle und Datum.)

Das Problem

Diese drei Momente sind heute schwer. Wer seine Stadt verstehen will, muss ein Dutzend Tabs gleichzeitig offen halten — das Polizei-Presseportal, die Lokalzeitung, das Ratsinformationssystem, den Baustellen-Feed, den Wetterwarndienst — und sie dann von Hand abgleichen. Schlimmer noch: Die Quellen widersprechen sich. „5.000 Demonstrierende" sagt der Veranstalter; „2.000" sagt die Polizei. Heute geht diese Divergenz verloren: Wer zuletzt oder am lautesten liest, gewinnt.

Lages Wette: Die Divergenz ist das Produkt. Ein Transparenzwerkzeug sollte widersprüchliche Darstellungen nicht zu einer „Wahrheit" verflachen; es sollte sie nebeneinanderstellen, jede an ihre Quelle gebunden, und die lesende Person urteilen lassen.

Drei Fragen, ein Graph

Das Zielmodell beantwortet drei zivile Fragen aus einem einzigen verlinkten Graphen:

  1. Wie geht es der Stadt? — Indikator-Zeitreihen (Modal Split, SDG-Indikatoren für Kommunen), räumlich und zeitlich verankert.
  2. Wer kümmert sich darum? — Akteur (Verwaltungseinheiten, Initiativen, Unternehmen), per Zuständigkeitsrelationen verbunden mit Anliegen (Open311-Meldungen), Bauprojekt und Ereignis, mit dem Beschluss des Rates dahinter, wo es einen gibt.
  3. Welche Möglichkeiten werden geboten? — Angebot (Leistungen, Veranstaltungen, Beteiligung), die einen bestimmten Indikator oder ein Anliegen adressieren.

Siehe docs/future/SCHEMA.md für den vollständigen Entitätskatalog und docs/future/STANDARDS.md für die Standards, auf die jeder Typ abgebildet wird.

Design-Festlegungen

Diese sind tragend. Sie beschränken jedes künftige Feature.

  • Ereignis ≠ Bericht ≠ Behauptung. Ein Ereignis (eine Demo, ein Unfall, ein Fest) ist bewusst dünn und trägt nur Unstrittiges: was, wo, wann. Alles, was eine Quelle darüber sagt, ist ein Bericht. Jede strittige Einzelaussage (Teilnehmerzahl, Ursache, Schuld) ist eine Behauptung, an einen Bericht gebunden. „5.000" steht nie als Tatsache im Graphen — nur als „5.000 laut Veranstalter / 2.000 laut Polizei".
  • Provenienz ist erstklassig. Jede Entität trägt eine Quelle und einen Beobachtungs-/Gültigkeitszeitpunkt, über PROV-O-Relationen an ihren Ursprung gebunden. Ohne Quellenkanten kein Vertrauen.
  • Verlinken, nicht kopieren. OParl bleibt Single Source of Truth für Ratsbeschlüsse; urheberrechtlich geschützter Text (Pressemitteilungen, Artikel) wird als Link + Metadaten + eigene Kurzfassung gespeichert, nie als Volltext.
  • Verifizierungsstufen sind sichtbar. Jeder Bericht und jede Behauptung trägt amtlich / redaktionell / unbestaetigt / auto-extrahiert. Maschinell extrahierter Output darf nie wie eine amtliche Aussage aussehen — weder im Graphen noch im Frontend.
  • DSGVO by design. Social-Media-Posts zu politischen Ereignissen sind Art.-9-Daten. Roh-Posts werden nicht gehortet — nur verlinkt oder aggregiert, mit einer Löschfrist (validTo) im Modell selbst, nicht nachträglich angebaut.
  • Kein erfundener Standard. Deutsche Civic-Begriffe sind Bequemlichkeits-Aliasse, die über @context auf NGSI-LD, schema.org, PROV-O, CPSV-AP, ORG auflösen. Lokal lesbar, global interoperabel.

Roadmap (Richtung, keine Daten)

Das Zielmodell ist ein Ziel, nicht der nächste Sprint. Die Brücke vom heutigen Atom-Aggregator verläuft grob so:

  • Jetzt — deterministische Kuratierung: fetch → geo-tag → dedup → Atom + Per-Panel-JSON-API + SvelteKit-Frontend. Kein LLM, kein Umschreiben von Quelltext.
  • Zustand entkoppeln — zentrales Postgres (cnpg) ersetzt Single-Pod-SQLite, damit der Collector unabhängig skalieren kann. Siehe docs/adr/0001.
  • Strukturierte Civic-Quellen ergänzen — OParl (Beschluss-Rückgrat), Open311 (Anliegen), DATEX II / GTFS-RT (Mobilität) über schlanke Adapter je Quelle, die aufs Civic-Schema mappen und Provenienz anhängen.
  • Quellentrennung — Ereignisse, Berichte und Behauptungen als eigenständige verlinkte Entitäten modellieren; den „wer sagt was"-Vergleich im Frontend sichtbar machen.
  • Extraktions-Pipeline — LLM/NLP macht aus Freitext (Pressemitteilungen, Artikel, Mastodon-Posts) Kandidaten für Ereignisse und Behauptungen, hart getaggt auto-extrahiert, hinter menschlicher Prüfung, bevor sie live gehen. Schreibt nie direkt die öffentliche API.

Was dies nicht ist

  • Kein operatives Lagebild für Einsatzkräfte (CAP/EDXL/TAK bewusst außerhalb des Scopes — docs/future/STANDARDS.md §6).
  • Kein Faktencheck, der Sieger kürt. Es zeigt konkurrierende Darstellungen; es rangiert sie nicht nach Wahrheit.
  • Kein Content-Host. Es verlinkt und fasst zusammen; es republiziert nicht.

Das vertiefte Design liegt in docs/future/ (deutsch). Diese Datei ist das Warum; jene sind das Wie.