Open Government Data

OGD bedeutet dabei mehr als freier Zugang: Die Daten müssen nichtdiskriminierend, wiederverwendbar, weiterverteilbar und technisch nutzbar bereitgestellt werden.

Im Bereich der Parlamentsdokumentation gelten OGD als zentrales Werkzeug für Transparenz, Bürgernähe und Innovation. Zu typischen Inhalten zählen Informationen zu Gesetzesvorlagen, parlamentarischen Abläufen, Abstimmungsergebnissen, Drucksachen, Abgeordnetenprofilen sowie strukturierte Metadaten. Ziel ist es, demokratische Prozesse nachvollziehbar zu machen, Nachnutzung zu ermöglichen und gesellschaftlichen Mehrwert durch datengestützte Anwendungen zu schaffen.

Ziele und Nutzen von Open Government Data

Der primäre Zweck von OGD im Parlament besteht in der Steigerung von Transparenz: Durch die offene Bereitstellung von Abläufen, Dokumenten und Abstimmungen werden demokratische Entscheidungen überprüfbar. Sie haben die Möglichkeit, parlamentarische Prozesse und Maßnahmen direkt nachzuvollziehen.

Ein wesentliches Ziel ist auch die Partizipation. Forschende, Medien, Unternehmen und die Zivilgesellschaft können auf OGD zugreifen, eigene Analysen durchführen und sich in politische Entwicklungen einbringen. Daraus entstehen innovative Plattformen, Visualisierungen und Monitoringsysteme.

OGD fördert Innovation, beispielsweise durch die Entwicklung neuer Anwendungen wie Abstimmungs-Tracker, Policy-Monitoring oder Themenportale. Unternehmen und gemeinnützige Organisationen können auf OGD aufsetzen, um digitale Angebote für Transparenz, Analytik und Monitoring bereitzustellen.

Ein weiteres Motiv ist Effizienz: Durch die standardisierte, offene Bereitstellung von Daten lassen sich Mehrfachanfragen verringern, Prozesse automatisieren und die Zusammenarbeit mit Öffentlichkeit sowie weiteren Behörden erleichtern.

Typische Datensätze in der Parlamentsdokumentation

Zu den häufigsten Arten von OGD im Parlament gehören:

• Gesetzesentwürfe, Anträge, Beschlussvorlagen, Ausschussberichte
• Plenarprotokolle, Tagesordnungen, Redebeiträge, Anhörungsunterlagen
• Abstimmungs- und Wahlergebnisse mit zulässigen, differenzierten Angaben z. B. nach Fraktionen oder – je nach gesetzlichen Regelungen – namentlich, wobei bei geheimen Abstimmungen nur aggregierte Ergebnisse bereitgestellt werden
• Abgeordnetenprofile inklusive Mandaten, Ausschuss- und Fraktionszugehörigkeit – im gesetzlichen Rahmen und unter Beachtung datenschutzrechtlicher Vorgaben
• Sitzungsdaten inklusive Kalender, Anhörungen, Expertenrunden, ggf. als iCalendar (ICS) oder JSON
• Relationen zwischen Vorgängen, Dokumenten, Aktiven und Gremien
• Geodaten z. B. zu Wahlkreisen, Gremienräumen (GeoJSON, GeoPackage)

Empfehlenswert ist es, neben klassischen Formaten wie PDF technologieoffene, barrierefreie und maschinenlesbare Formate wie XML, JSON, CSV oder GeoJSON bereitzustellen. Persistente Identifikatoren (wie DOI, URN:NBN, ARK, Handle oder sogenannte "cool URIs"/w3id) gewährleisten Referenzierbarkeit, müssen aber im Sinne einer PID-Policy mit Standards zur Auflösung, Versionierung und Langzeitverfügbarkeit einhergehen. Eine einfache URL wird ohne zusätzlichen Resolver oder PID-Policy nicht als persistent betrachtet.

Formate, Standards und Schnittstellen

Eine nachhaltige OGD-Strategie im parlamentarischen Kontext orientiert sich an etablierten Spezifikationen und Best Practices:

• Datenformate: Neben PDF (offener ISO-Standard, aber für maschinelle Verarbeitung ungeeignet) müssen immer strukturierte Formate wie CSV, TSV, XML, JSON bereitgestellt werden. Für reine Texte ist HTML sinnvoll, für Barrierefreiheit PDF/UA, und für Geodaten GeoJSON oder OGC-kompatible Formate.
• Metadatenstandards: Für Kataloge sind DCAT-AP (europaweit) und DCAT-AP.de führend. Ergänzend sollten schema.org/Dataset, Dublin Core (DCMI), PROV-O, Data Quality Vocabulary (DQV), und für mehrsprachige Metadaten BCP 47 genutzt werden.
• Fachspezifische Standards: Akoma Ntoso ist Standard für rechtliche Dokumente. OParl (regional eingesetzt, insbesondere in Deutschland) unterstützt ratsbezogene Parlamentsdaten; Popolo (kaum noch aktiv gepflegt) diente historisch als Basis, Alternativen wie Open Civic Data Identifiers (OCD) gewinnen an Bedeutung.
• Semantische Beschreibung: Verwenden Sie kontrollierte Vokabulare (z. B. EuroVoc, GND), SKOS für thesaurigerepräsentationen, eindeutige URIs und Linked Data-Technologien (z. B. RDF, JSON-LD, SPARQL). Prüfen Sie die Integration von Wikidata (Q-IDs) und die Verlinkung zu amtlichen Quellen (etwa gesetze-im-internet.de, BGBl).
• Schnittstellen: APIs sollten mindestens REST mit OpenAPI-Spezifikation bieten, GraphQL mit eigenem SDL/Schema. Ergänzen Sie um Bulk-Downloads, differenzierte Feeds (Delta-/Diff-Feeds), Änderungsbenachrichtigungen (z. B. OAI-PMH), ETag/If-None-Match/Last-Modified für schlanke Synchronisierung, und Versionierung für langlebige APIs. Atom, RSS, WebSub und Server-Sent Events (SSE) eignen sich für Benachrichtigungsdienste.
• Datenpaketierung: Frictionless Data Packages inkl. Table Schema, UTF-8-Kodierung und deklarierte CSV-Dialekte verbessern Übertragbarkeit. Vereinbaren Sie einheitliche Zeitzonen (ISO 8601/RFC 3339) für Zeitpunkte und -intervalle.
• Qualitätssicherung: Automatisieren Sie Validierungen (z. B. SHACL, JSON Schema), ergänzen Sie DQV-Metriken (Vollständigkeit, Konsistenz), und bieten Sie öffentliche Konformitätstests. Prüfsummen (z. B. SHA-256) gewährleisten Integrität, digitale Signaturen (PGP, JWS, Sigstore) sichern Authentizität.

APIs sollten immer umfassend und transparent dokumentiert werden. Ergänzen Sie Filtersysteme, Paginierung, Sortierung sowie Snapshots und Änderungsprotokolle.

Lizenzen und rechtliche Aspekte

Die sichere und rechtlich einwandfreie Nachnutzung von Parlaments-OGD setzt folgende Bedingungen voraus:

• Lizenzmodelle: Setzen Sie offene Standardlizenzen ein, wie CC0, DL-DE Zero 2.0 (rechtlich nicht identisch zu CC0, aber vergleichbar), CC BY 4.0 oder DL-DE BY 2.0. Je nach Datenbestand kann die Lizenz für Metadaten (CC0/DL-DE Zero empfohlen) und Inhalte unterschiedlich gewählt werden. Jede Lizenz muss maschinenlesbar (z. B. per URI, rel=license, RDFa/JSON-LD, SPDX, ODRL) deklariert werden. Für Drittinhalte (z. B. Bilduploads) beachten Sie gesonderte Bedingungen.
• Urheber- und Datenbankrecht: Prüfen Sie, ob Werke als amtliche Werke (§5 UrhG) nutzungsfrei gestellt sind oder Datenbankherstellerrechte bestehen (sui generis nach §87a-h UrhG/EU-Richtlinie). Der Haftungsausschluss sowie der Verzicht auf Endorsements (z. B. keine amtliche Unterstützung von Nachnutzern) sind zu dokumentieren.
• Datenschutz: Rechtsgrundlagen für die Veröffentlichung sind insbesondere Art. 6 Abs. 1 lit. e oder c DSGVO, ergänzend Parlaments- und Landesgesetze (das EGovG bindet primär Bundesbehörden, Parlamente oft nicht direkt). Spezielle Kategorien personenbezogener Daten (Art. 9 DSGVO, z. B. politische Meinung oder Abstimmungsverhalten) bedürfen jeweils expliziter gesetzlicher Grundlage oder „offenkundig öffentlich gemacht“ (Art. 9 Abs. 2 lit. e/g). Berücksichtigen Sie Datenminimierung, Zweckbindung, Betroffenenrechte, Lösch- und Sperrkonzepte sowie ggf. Datenschutzfolgenabschätzungen (Art. 35 DSGVO).
• Barrierefreiheit: Ihre Angebote unterliegen den aktuellsten Standards, insbesondere Barrierefreiheit nach EN 301 549 (aktuelle Version), WCAG 2.2 AA, BITV 2.0 und PDF/UA für barrierefreie PDF-Dokumente. Daten sollten auch als barrierefreie HTML-Alternativen bereitstehen, Tabellendaten zugänglich gemacht sowie Audiotranskripte und Untertitel angeboten werden.
• Gesetzlicher Rahmen: Die wichtigsten Regelwerke sind das Datennutzungsgesetz (DNG), die EU-Open-Data-Richtlinie, einschlägige Transparenz- und Open-Data-Gesetze der Länder sowie ggf. spezialgesetzliche Vorschriften. Das Informationsfreiheitsgesetz (IFG) dient als wesentliche Grundlage für individuellen Zugang, beeinflusst aber mittlerweile auch die Offenlegung und Priorisierung, insbesondere durch Transparenzanträge.
• Langzeitarchivierung: Legen Sie Verfahren gemäß OAIS, BagIt/PREMIS fest, nutzen Sie DOI/ARK-Konzepte für archivalische Persistenz und dokumentieren Sie Lösch- sowie Retentionsrichtlinien.

Versehen Sie jede Veröffentlichung klar mit Nutzungsbedingungen, Lizenz-, Datenschutz- und Haftungshinweisen, sowie Informationen zur Archivierungsstrategie.

Datenqualität und Metadaten

Der Wert von OGD hängt direkt von Datenqualität und Metadaten ab. Relevant sind:

• Veröffentlichungsturnus und nachvollziehbare Aktualisierungen
• Pflichtelemente (Feldbeschreibungen, Wertelisten, Typisierung, Zeitangaben mit begin/end)
• mehrsprachige Metadaten mit BCP 47-Tags
• Versionierungskonzepte (Memento, Versions-DOIs, URI-Versionierung)
• Änderungsprotokolle mit Zeitstempeln (Provenienz nach PROV-O)
• Empfehlungen zur Zitation (PIDs, dauerhafte Links)
• Erfassung von Datenherkunft, Status (Entwurf, gültig, archiviert)
• Nutzung anerkannter Referenzquellen wie Wikidata, GND, EuroVoc sowie amtlicher Gesetzesquellen (BGBl, gesetze-im-internet.de)
• Öffentliche Validierungen, Qualitätsmetriken nach DQV und 5-Sterne-Modell von Linked Open Data

Best Practices für die Datenbereitstellung

Empfohlen werden für Parlamente und Verwaltungen insbesondere folgende Schritte:

• Durchführung einer detaillierten Dateninventur und Nutzerzentrierung, Priorisierung nach Mehrwert und Re-Use-Potenzial
• „Open by default“-Strategie: Möglichst früh und kontinuierlich Daten freigeben, Feedback-Schleifen aufbauen
• Umfassende Dokumentation (Datenfelder, Beispiele, OpenAPI, Beispielskripte/SDKs, Kontakt zu Data Stewards)
• Feedback- und Request-Kanäle, öffentliche Roadmap, Issue-Tracker, konsistente Deprecation-Policy mit Zeitplan
• Monitoring: Uptime/Verfügbarkeit, SLA/SLO, Fehlertracking, offene Statusseite
• Verantwortlichkeiten in Governance-, Review- und Release-Prozessen klären
• Kontinuierliche Datenprüfung (Prüfsummen, digitale Signaturen), Versionierungs- und Qualitätssicherungschecks
• Berücksichtigung aktueller IT-Sicherheitsmaßnahmen (z. B. DDoS-Schutz, Abuse-Mitigations, Rate-Limits, SBOM, Vulnerability Disclosure Policy, CORS)
• Transparente Quotenregelungen mit Ausnahmen für Forschung und Gemeinwohlprojekte

Best Practices für Nutzende

Für die optimale Nutzung offener Parlamentsdaten sollten Sie folgende Empfehlungen beachten:

• Prüfen Sie jede Lizenz, befolgen Sie Nachnennungs- und Quellenvorgaben präzise
• Verwenden Sie persistente IDs aus Datenquellen, vermeiden Sie eigene ID-Schemata oder Scraping
• Implementieren Sie Caching und Delta-Updates, um effizient mit Aktualisierungen zu arbeiten
• Beachten Sie Kontext und Status aller Daten (vorläufig/final, öffentlich/geheim)
• Verarbeiten Sie personenbezogene Daten stets datenschutzkonform und nur im zulässigen Umfang
• Reichen Sie Fehlermeldungen oder Verbesserungsvorschläge direkt an die Datenhalter zurück

Häufige Missverständnisse

Missverständnisse bei OGD von Parlamenten entstehen häufig an folgenden Stellen:

• PDFs sind offene ISO-Standards, aber als primäre Datenquelle ungeeignet: Für strukturierte, automatisierte Weiterverarbeitung sind zusätzliche maschinenlesbare Formate erforderlich.
• Offene Lizenzen bedeuten Nachnutzungsrechte, aber fast immer unter Bedingungen (z. B. Namensnennung). Die Lizenzbedingungen müssen stets beachtet werden.
• Nicht alle Datensätze dürfen aus Datenschutz-, Geheimhaltungs- oder Schutzgründen offen gelegt werden (z. B. bei geheimen Abstimmungen oder besonderen Personaldaten).
• Erwartungshaltung für Echtzeitdaten ist oft zu hoch; Qualität und Konsistenz der Updates sind wichtiger als Frequenz.
• Persistente Identifikatoren erhöhen die Referenzierbarkeit, aber dauerhaft archiviert werden Daten nur durch institutionelle Verfahren und Ablieferung.

Integration in Informationsmanagementsysteme

Informationsmanagementsysteme wie jene von GLOMAS dienen als Datenquelle für OGD-Portale. Export und Abgleich sollten automatisiert und systematisiert erfolgen, etwa durch regelmäßige Extraktion im DCAT-AP-Format zu Katalogen wie CKAN, GovData.de oder data.europa.eu.

Ein präzises Mapping der internen auf öffentliche Metadatenschemata ist unverzichtbar. Die Verwahrung und Veröffentlichung von Identifikatoren (z. B. URN:NBN, ARK, DOI, Handle) muss durch eine PID-Policy und Redirect-Strategien unterstützt werden; Konzept- und Versions-IDs sind zu unterscheiden. Content Negotiation (html/json/rdf) oder Well-known-Endpunkte erleichtern Zugriff und Verlinkbarkeit.

APIs sollten versioniert, ausfallsicher und robust gegen Missbrauch geplant werden (z. B. durch Monitoringsysteme und Fallbacks). Interne Register für Abgeordnete können durch Verknüpfung mit Normdatenquellen (Wikidata, GND) und offenen Identifikatoren erhöhten Nutzen stiften.

Sicherheit, Interoperabilität, DSGVO-konforme Analytik, Kontinuität durch Backups und Nachweisbarkeit durch digitale Signaturen und Prüfsummen sind unerlässlich.

Erfolgskriterien und Monitoring

Der Umsetzungserfolg von Parlaments-OGD lässt sich multidimensional messen:

• Nutzungsmetriken: Downloads, API-Aufrufe, Besucherstatistik
• Plattform-Betriebswerte: SLA/SLO, Verfügbarkeit/Uptime, Reaktionszeit
• Datenaktualität: Time-to-Publish, Regelmäßigkeit der Updates
• Nachnutzung: Entwicklung von Drittprojekten, Erwähnungen, Zitationen
• Qualitätsindikatoren: Validierungsraten, Fehlerquote, Konsistenzberichte
• Partizipation: Feedback, Community Contributions, Pull-Requests
• Änderungs- und Versionsverfolgung: Protokolle, Fehlerkorrekturen

Transparente Monitoring- und Fehlertrackingverfahren inklusive öffentlicher Statusseite und Roadmap erhöhen die Attraktivität und Akzeptanz der Angebote.

Umsetzungsschritte und nachhaltiger Betrieb

Die Einführung eines Parlaments-OGD umfasst in der Regel folgende Stufen:

1. Priorisierung der bereitzustellenden Datensätze und Identifikation mit Blick auf Mehrwert und Zweckbindung
2. Juristische Prüfung (Lizenzen, Datenschutz, Rechte), Einschluss von Drittmaterialien
3. Entwicklung widerspruchsfreier, dokumentierter Metadatenmodelle mit stabilen und versionierten PIDs
4. Auswahl offener Plattformen (z. B. CKAN, OParl, DCAT-AP.de-Kataloge) und Einrichtung technischer Schnittstellen
5. Veröffentlichung erster (Pilot-)Datensätze mit Beispielen und maschinenlesbaren Lizenzen
6. Aufbau von Governance-Strukturen, klarer Verantwortlichkeiten, öffentlicher Roadmap und Issue-Management
7. Etablierung automatisierter Qualitätssicherung, Monitoring, Reporting und fortlaufender Weiterentwicklung

Langzeitarchivierung und Retention laufen nach OAIS, BagIt/PREMIS sowie Version-DOI-Konzepten ab. Sichern Sie Formatschnittstellen für künftige Migrationen (z. B. WARC-Archivierung, Exportprofile XML/CSV+Codebook).

Beispielanwendungen

Typische Beispiele für Parlaments-OGD sind:

• Monitoring der Abstimmungsergebnisse nach Fraktionen/Gremien, inkl. offener/namentlicher Abstimmungen
• Visualisierungen zu Gesetzgebungsverläufen und Protokoll-Statusanzeigen
• Volltextsuche mit Filter, Themen- und Zeitreihenanalyse in Plenarprotokollen
• Sitzungs-Feeds (ICS/JSON) für Kalenderintegration und Event-IDs
• Forschungs- und Beispieldatensätze für Policy-Analysen und maschinelles Lernen
• Konkrete Umsetzungen: Deutscher Bundestag DIP-API, data.europarl.europa.eu-Feeds, OParl v1.1 API, Open Civic Data Identifiers
• Verlinkungen zu amtlichen Quellen: BGBl, gesetze-im-internet.de

Häufige Fragen zu Open Government Data

Was ist der Unterschied zwischen Open Data und Open Government Data?

Open Data umfasst alle nutzbar veröffentlichten Datensätze, unabhängig vom Herausgeber. Open Government Data bezeichnet explizit Daten, die von Behörden und öffentlichen Einrichtungen bereitgestellt werden und den Open-Data-Prinzipien entsprechen.

Sind PDFs als OGD zulässig?

PDF ist ein offener ISO-Standard und für barrierefreie Präsentationen (PDF/UA) geeignet, jedoch für strukturierte, maschinelle Weiterverarbeitung ungeeignet. Ergänzende Formate wie CSV, XML oder JSON sind deshalb für OGD verpflichtend; zugängliche HTML-Alternativen werden empfohlen.

Welche Lizenz soll ich wählen?

Empfohlen werden offene Standardlizenzen wie CC0, DL-DE Zero 2.0 (funktional ähnlich zu CC0, aber rechtlich nicht identisch), CC BY 4.0 oder DL-DE BY 2.0. Verschiedene Datensätze oder Metadaten können unterschiedliche Lizenzen erfordern. Jede Lizenz sollte maschinenlesbar mit URI im Metadatensatz erfasst werden.

Dürfen personenbezogene Daten von Abgeordneten veröffentlicht werden?

Die Veröffentlichung personenbezogener Daten basiert auf Art. 6 Abs. 1 lit. e DSGVO, ggf. Art. 6 Abs. 1 lit. c DSGVO und einschlägigen Parlaments- oder Landesgesetzen. Bei besonderen Kategorien (z. B. politische Meinung, namentliche Abstimmung) gelten Art. 9 DSGVO sowie spezielle Rechtsgrundlagen oder das Kriterium „offenkundig öffentlich gemacht“. Amtliche Funktionen, Mandate oder Gremienzugehörigkeit dürfen im notwendigen Umfang publiziert werden. Private Kontaktdaten und sensible Angaben dürfen nicht veröffentlicht werden.

Wie oft sollten Datensätze aktualisiert werden?

Das richtet sich nach dem jeweiligen Fachprozess. Im Parlament werden z. B. Sitzungsprotokolle nach abschließender Freigabe publiziert. Wesentlich sind nachvollziehbare, dokumentierte Veröffentlichungsfrequenzen und redaktionelle Prozesse.

Was tun bei Fehlern in veröffentlichten Daten?

Korrigieren Sie Fehler schnellstmöglich und führen Sie nachvollziehbare Changelogs sowie Versionshistorien. Informieren Sie betroffene Nutzergruppen aktiv und machen Sie Korrekturmechanismen transparent.

Welche Plattform eignet sich für ein Open-Data-Portal?

CKAN ist weit verbreitet; DCAT-AP-konforme Kataloge sowie offene Schnittstellen (OParl, OpenAPI für REST, RDF) spielen ebenfalls eine zentrale Rolle. Wählen Sie eine skalierbare, erweiterbare Lösung mit guter Dokumentation, Monitoring und Rechteverwaltung.

Welche Standards empfehlen Sie speziell für Parlamentsdaten?

Für Datenkataloge sind DCAT-AP/DCAT-AP.de erste Wahl. Für juristische Dokumente wird Akoma Ntoso genutzt. OParl (v1.1) ist für deutsche Ratsdaten gängig, Popolo ist veraltet; Alternativen sind OCD-IDs oder Wikidata-Verknüpfungen. Linked Data-Technologien (RDF, JSON-LD) und externe Vokabulare (EuroVoc, GND) fördern Interoperabilität.

Wie stelle ich langfristige Stabilität sicher?

Nutzen Sie persistente PIDs (z. B. ARK, DOI, Handle, URN:NBN) und etablieren Sie Redirects, klare PID-Policies, API-Versionierung, Backups, Zitierempfehlungen und eine öffentliche Statusseite. Dokumentieren Sie Deprecation-Policies, Verantwortlichkeiten und Wartungszyklen.

Kann die Nutzung eingeschränkt werden (z. B. Rate-Limits)?

Transparente technische Begrenzungen, etwa durch Rate-Limits oder Nutzerquoten, sind erlaubt, um den stabilen Betrieb zu sichern. Sie müssen klar dokumentiert sein. Lizenzbedingungen und technische Zugriffslimits sind voneinander unabhängig. Forschende oder gemeinnützige Projekte können Sonderkontingente erhalten.

‍