a83c770b93
Vertiefte Probe (WP17 Sitzung 50): BW stimmt 'pro Artikel'
('Damit ist Artikel 1 einstimmig zugestimmt'), nicht pro Drucksache.
Das ist andere Datenmodellierung als NRW (Drucksache→Vote) und BUND
(Beschlussempfehlung→Vote). Ein BW-Parser braucht entweder:
- Aggregations-Heuristik: alle Artikel angenommen → DS angenommen
- Schema-Erweiterung um 'artikel'-Spalte fuer per-Artikel-Records
Implementer muss vor Start mit Maintainer abstimmen, welcher Weg
gegangen wird. BW bleibt Stub bis Designwahl getroffen ist.
104 lines
4.3 KiB
Python
104 lines
4.3 KiB
Python
"""Baden-Württemberg (BW) — Plenarprotokoll-Parser STUB (#106 Folge, ADR 0009).
|
|
|
|
**Status: noch nicht implementiert.** Dieser Modul-Stub enthaelt
|
|
Recherche-Findings vom 2026-04-28, sodass die Implementer-Session
|
|
direkt produktiv loslegen kann. Der Stub wird **nicht** in
|
|
``app.protokoll_parsers.PROTOKOLL_PARSERS`` registriert — der
|
|
Auto-Ingest-Cron ueberspringt BW solange.
|
|
|
|
## Recherche
|
|
|
|
| Feld | Wert |
|
|
|---|---|
|
|
| **Doku-System** | PARLIS |
|
|
| **Base-URL** | https://parlis.landtag-bw.de |
|
|
| **Familie** | eigenstaendig (PARLIS-spezifisch, eigene Pattern) |
|
|
| **Format** | PDF; URL-Pattern bekannt mit 4-stelliger Sitzungs-Nr |
|
|
|
|
## URL-Discovery
|
|
|
|
```
|
|
https://www.landtag-bw.de/files/live/sites/LTBW/files/dokumente/WP{wp}/Plp/{wp}_{n:04}.pdf
|
|
```
|
|
|
|
Verifiziert HTTP 200 fuer WP17 Sitzungen 0001, 0050, 0100. WP17 endet
|
|
ungefaehr Sitzung 130 (404 ab ~150). Pattern: 4-stellige Sitzungs-Nr
|
|
mit fuehrenden Nullen (anders als NRW `MMP18-N` ohne Padding).
|
|
|
|
## Anchor-Phrasen-Befunde (vom Sample WP17 Sitzung 50)
|
|
|
|
Stichprobe-Analyse von `17_0050.pdf` (618 KB, ~617k Zeichen):
|
|
|
|
| Pattern | Treffer | Kommentar |
|
|
|---|---:|---|
|
|
| ``angenommen`` | 1 | nur in einer Rede, **kein** Beschluss-Anchor |
|
|
| ``abgelehnt`` | 5 | gemischt Reden/Beschluesse |
|
|
| ``einstimmig`` | 7 | als Anchor-Phrase brauchbar |
|
|
| ``Drucksache 17/\d+`` | 35 | Drucksachen-Nrn werden referenziert |
|
|
| ``namentliche Abstimmung`` | 3 | namentliche Abstimmungen kommen vor |
|
|
| ``zugestimmt`` | 19 | **dominierende Vote-Phrase** |
|
|
| ``einstimmig zugestimmt`` | 5 | hochsignifikante Anchor-Phrase |
|
|
| ``Damit ist [...] einstimmig`` | 2 | NRW-aehnliche Anchor-Form |
|
|
| ``Wer dem [...] seine Zustimmung gibt`` | 0 | Bundestag-Pattern, in BW NICHT genutzt |
|
|
|
|
**Konsequenz fuer Parser:** BW-Vote-Sprache ist:
|
|
- ``Damit ist [Artikel/Antrag X] einstimmig (zu)gestimmt`` als
|
|
Haupt-Anchor (statt NRW ``angenommen``)
|
|
- ``Drucksache 17/N`` als DS-Pattern (analog NRW)
|
|
- Detaillierte Fraktions-Auflistung pro Vote ist **deutlich** weniger
|
|
vorhanden als in NRW — der Parser kann oft nur ``einstimmig`` /
|
|
``mit Mehrheit`` extrahieren, kein ja/nein/enthaltung-Breakdown.
|
|
- Fuer namentliche Abstimmungen (3/Sitzung) ist eigene Logik noetig
|
|
(separate Tabelle im PDF).
|
|
|
|
## **WICHTIG — Datenmodell-Inkompatibilitaet**
|
|
|
|
Vertiefte Probe (Sitzung 17_0050):
|
|
- Anchor-Phrase ``Damit ist Artikel 1 einstimmig zugestimmt`` (3x)
|
|
- ``Damit ist Artikel 2 mehrheitlich zugestimmt`` (1x)
|
|
- Aber **keine direkten** ``Damit ist Drucksache X angenommen``-Anchors
|
|
|
|
**BW stimmt pro Gesetzentwurf-Artikel ab**, nicht pro Drucksache. Das
|
|
ist eine andere Datenmodellierung als NRW (Drucksache → Vote) und
|
|
BUND (Beschlussempfehlung → Vote). Ein BW-Parser muesste:
|
|
|
|
1. Pro Gesetzentwurf alle Artikel-Anchors sammeln
|
|
2. Aggregat bilden: Gesetzentwurf X = wenn alle Artikel angenommen
|
|
3. Drucksache aus dem zugehoerigen Gesetzentwurf-Header oben rueckwaerts
|
|
suchen (nicht trivial — der Bezug ist mehrere Seiten zurueck)
|
|
|
|
Alternative-Modellierung: Schema ``plenum_vote_results`` um optionalen
|
|
``artikel``-Spalten-Pfad erweitern, um pro-Artikel-Records zu speichern.
|
|
|
|
**Empfehlung fuer Implementer:** vor Parser-Start mit Maintainer
|
|
abstimmen, ob BW-Datenmodell ggf. eigenen Tabellen-Anbau noetig macht
|
|
oder eine BW-spezifische Aggregations-Heuristik (alle Artikel zugestimmt
|
|
→ Gesetzentwurf-DS=angenommen) genuegt.
|
|
|
|
## Bezug
|
|
|
|
- Architektur: ADR 0009 (Plenarprotokoll-Parser-Registry)
|
|
- Roadmap: ``docs/protokoll-parser-roadmap.md``
|
|
- Referenz-Implementation: ``app/protokoll_parsers/nrw.py``
|
|
(38 Tests, 19/19-Fixture-Garantie)
|
|
- Folge-Issue: https://repo.toppyr.de/tobias/gwoe-antragspruefer/issues/151 (Titel: "protokoll-parser: BW (Baden-Württemberg)")
|
|
|
|
## Aufwand
|
|
|
|
Geschaetzt 1-3 Tage konzentrierte Arbeit:
|
|
- 2-4h URL-Discovery + Format-Inspektion (Sample-Protokoll inhaltlich anschauen)
|
|
- 4-8h Anchor-Phrasen-Reverse-Engineering + Parser-Implementierung
|
|
- 4h Tests mit Fixture-Pinning
|
|
- 1h Eintrag in PROTOKOLL_PARSERS + auto-ingest-protocols.sh
|
|
"""
|
|
from __future__ import annotations
|
|
|
|
|
|
def parse_protocol(path: str) -> list[dict]:
|
|
"""STUB — siehe Modul-Docstring."""
|
|
raise NotImplementedError(
|
|
"BW-Plenarprotokoll-Parser ist noch nicht implementiert. "
|
|
"Siehe app/protokoll_parsers/bw.py-Docstring fuer Recherche-Findings "
|
|
"und docs/protokoll-parser-roadmap.md."
|
|
)
|