docs(#106,#126): Plenarprotokoll-Parser-Roadmap pro Bundesland
Format-Hints, URL-Patterns und Aufwand-Schaetzung pro BL fuer kuenftige Phase-2-Implementierungen. Dokumentiert was pro Landtag zu tun ist: - NRW: produktiv (38 Tests, Fixture-Garantie 19/19) - BUND: XML-Endpoint fuer namentliche Abstimmungen empfohlen statt PDF - MV/TH: ParlDok-Plattform, Synergien - BB/BY/BE/BW/HB/HE/HH/LSA/NI/RP/SH/SL/SN: je 1-3 Tage Reverse-Engineering - BUND-XML, MV/TH-Synergie und HE-HTML als naechste empfohlene Picks Cron-Erweiterung pro neuem BL: ein PROTO_TARGETS-Eintrag in scripts/auto-ingest-protocols.sh, kein Cron-Edit noetig.
This commit is contained in:
parent
05b6b45e1b
commit
fc9155de58
151
docs/protokoll-parser-roadmap.md
Normal file
151
docs/protokoll-parser-roadmap.md
Normal file
@ -0,0 +1,151 @@
|
||||
# Plenarprotokoll-Parser Roadmap pro Bundesland
|
||||
|
||||
Stand 2026-04-28. Architektur fertig (ADR 0009), NRW-Parser produktiv,
|
||||
Cron-Infrastruktur (`scripts/auto-ingest-protocols.sh`) BL-erweiterbar.
|
||||
Pro weiterem BL ist ein eigener Parser zu implementieren — das ist
|
||||
deterministische Reverse-Engineering-Arbeit, keine LLM-Calls, keine Kosten.
|
||||
|
||||
## Pattern fuer neue BL
|
||||
|
||||
1. **Sample-PDF/HTML/XML besorgen** und Vote-Anchor-Phrasen identifizieren.
|
||||
2. **`app/protokoll_parsers/<bl>.py`** anlegen mit `parse_protocol(path) -> list[dict]`
|
||||
nach Vertrag aus ADR 0009.
|
||||
3. **Eintrag in `PROTOKOLL_PARSERS`** (in `__init__.py`).
|
||||
4. **Tests** in `tests/test_protokoll_parsers_<bl>.py`.
|
||||
5. **`PROTO_TARGETS`** in `scripts/auto-ingest-protocols.sh` ergaenzen.
|
||||
6. **Backfill** einmal manuell laufen lassen.
|
||||
|
||||
## Pro Bundesland: bekannter Stand
|
||||
|
||||
### NRW ✅ produktiv
|
||||
|
||||
- URL: `https://www.landtag.nrw.de/portal/WWW/dokumentenarchiv/Dokument/MMP{wp}-{n}.pdf`
|
||||
- Format: PDF mit deterministischen Anchor-Phrasen ("Damit ist X angenommen/abgelehnt")
|
||||
- Parser: `app/protokoll_parsers/nrw.py`
|
||||
- Tests: 38 Tests, Fixture-Garantie 19/19 auf MMP18-119
|
||||
|
||||
### Bundestag (BUND) — anderer Vote-Sprache als NRW
|
||||
|
||||
- URL: `https://dserver.bundestag.de/btp/{wp}/{wp}{n:03}.pdf` (z.B. `20184` = WP20 Sitzung 184)
|
||||
- Format: PDF, ~1 MB pro Sitzung, ~600k Zeichen Text.
|
||||
- **Vote-Anchor-Phrasen unterscheiden sich von NRW:**
|
||||
- Bundestag nutzt: „Wer dem Gesetzentwurf seine Zustimmung gibt, den
|
||||
bitte ich, sich zu erheben", „Damit ist der Gesetzentwurf in zweiter
|
||||
Beratung angenommen", „... mit den Stimmen der Koalition gegen die
|
||||
Stimmen der Opposition abgelehnt"
|
||||
- „angenommen" und „überwiesen" haeufig in „in zweiter Beratung
|
||||
angenommen" oder „zur federführenden Beratung an den Ausschuss"
|
||||
- Vote-Daten: bei „namentliche Abstimmung" als separate XML-Datei
|
||||
unter `https://dserver.bundestag.de/.../btp{wp}-{n}-namentlich.xml`
|
||||
(alternative datenquelle, strukturiert!)
|
||||
- **Empfehlung:** Statt PDF-Parsen den XML-Endpoint fuer namentliche
|
||||
Abstimmungen nutzen — dort liegt fraktions-aggregiertes Vote bereits
|
||||
als Struktur vor.
|
||||
- Aufwand: ~1-2 Tage
|
||||
|
||||
### MV — ParlDok 8.x SPA
|
||||
|
||||
- URL-Pattern: `https://www.dokumentation.landtag-mv.de/parldok/dokument/{id}/{slug}.pdf`
|
||||
- Format: PDF, aber `{id}` ist nicht-vorhersagbar — braucht Listen-API
|
||||
von ParlDok-Suche
|
||||
- Workaround: Suche via Plenarprotokoll-Filter, Liste der IDs holen
|
||||
- Aufwand: ~2 Tage (URL-Discovery + Parser-Bau)
|
||||
|
||||
### Bayern (BY) — Pfad-Pattern noch zu verifizieren
|
||||
|
||||
- Format: PDF
|
||||
- URL aus dokukratie-yml ziehen (nicht direkt dokumentiert)
|
||||
- Aufwand: ~2 Tage
|
||||
|
||||
### Brandenburg (BB)
|
||||
|
||||
- URL-Pattern: `https://www.landtag.brandenburg.de/...` mit eigenem Schema
|
||||
- Format: PDF mit Vote-Tabellen
|
||||
- Aufwand: ~2-3 Tage (Tabellen-Parsing aufwendiger als reine Text-Anchors)
|
||||
|
||||
### Berlin (BE)
|
||||
|
||||
- Pardok-Plattform (analog LSA, BE)
|
||||
- URL via Search-API
|
||||
- Aufwand: ~2 Tage
|
||||
|
||||
### Bremen (HB), Hamburg (HH), Saarland (SL)
|
||||
|
||||
- Stadtstaaten, kleinere Landtage
|
||||
- Format-Recherche pro Stadt; oft PDFs mit weniger formalen Anchors
|
||||
- Aufwand: je ~1-2 Tage
|
||||
|
||||
### Hessen (HE)
|
||||
|
||||
- Webseiten-Plenarprotokolle z.T. als HTML strukturiert (semantische
|
||||
Tags pro Beschluss)
|
||||
- Wenn HTML zugaenglich: einfacher als PDF
|
||||
- Sample-URL muss recherchiert werden
|
||||
- Aufwand: ~1-2 Tage
|
||||
|
||||
### Niedersachsen (NI)
|
||||
|
||||
- nilas-Portal Login-protected (siehe `feedback_silent_excepts.md`)
|
||||
- Plenarprotokolle ggf. auf eigener Seite ohne Login
|
||||
- Aufwand: ~2-3 Tage (Login-Workaround pruefen)
|
||||
|
||||
### Rheinland-Pfalz (RP)
|
||||
|
||||
- OPAL_extern, abweichend zu NRW-OPAL
|
||||
- PDF-URLs dokumentiert in dokukratie-yml
|
||||
- Aufwand: ~2 Tage
|
||||
|
||||
### Sachsen (SN)
|
||||
|
||||
- ASP.NET-Webforms — Postback-Handling fuer Suche noetig
|
||||
- Plenarprotokoll-Liste via XML-Export
|
||||
- Synergie mit bestehendem `app/sn_xml_export`-Workflow moeglich
|
||||
- Aufwand: ~1-2 Tage
|
||||
|
||||
### Sachsen-Anhalt (LSA)
|
||||
|
||||
- Padoka-Plattform (analog BE)
|
||||
- URL via Search-API
|
||||
- Aufwand: ~2 Tage
|
||||
|
||||
### Schleswig-Holstein (SH)
|
||||
|
||||
- Starfinder-CGI-Backend
|
||||
- Format: PDF
|
||||
- Aufwand: ~2 Tage
|
||||
|
||||
### Thüringen (TH)
|
||||
|
||||
- ParlDok-Plattform (analog MV)
|
||||
- Synergien mit MV-Parser hoch
|
||||
- Aufwand: ~1-2 Tage (nach MV)
|
||||
|
||||
### Baden-Württemberg (BW)
|
||||
|
||||
- PARLIS-Eigensystem
|
||||
- Format: PDF
|
||||
- Aufwand: ~2 Tage
|
||||
|
||||
## Implementations-Reihenfolge nach Aufwand-Nutzen
|
||||
|
||||
1. **MV + TH** parallel (gleiche ParlDok-Plattform, Synergien)
|
||||
2. **BUND** (XML-Endpoint!) — strukturierte Daten leichter als PDF-Parser
|
||||
3. **HE** wenn HTML-Plenarprotokolle existieren
|
||||
4. Rest nach Bedarf
|
||||
|
||||
## Cron-Erweiterung pro neuem BL
|
||||
|
||||
In `scripts/auto-ingest-protocols.sh` einen `PROTO_TARGETS`-Eintrag
|
||||
ergaenzen:
|
||||
|
||||
```bash
|
||||
PROTO_TARGETS=(
|
||||
"NRW|18|https://www.landtag.nrw.de/.../MMP18-{n}.pdf"
|
||||
"BUND|20|https://dserver.bundestag.de/btp/20/20{n:03}.pdf"
|
||||
...
|
||||
)
|
||||
```
|
||||
|
||||
Format-Spec: `BL_CODE|WAHLPERIODE|URL_MIT_{n}_PLACEHOLDER`. Das Skript
|
||||
erkennt automatisch das letzte ingestete Protokoll dieses BL/WP und
|
||||
inkrementiert.
|
||||
Loading…
Reference in New Issue
Block a user