1 · Einführung und Ziele¶
Aufgabenstellung¶
Das Land Schleswig-Holstein ist nach dem Datennutzungsgesetz (DNG) verpflichtet, öffentliche Verwaltungsdaten als Open Data bereitzustellen. Die Open Data Infrastruktur (ODI) ist die technische Plattform, die diesen Auftrag umsetzt: Sie ermöglicht Behörden und anderen öffentlichen Stellen, strukturierte Datensätze hochzuladen, maschinell zu prüfen und standardkonform zu veröffentlichen.
Die ODI nimmt Daten in verschiedenen Formaten entgegen – tabellarische Daten (CSV), Geodaten, Echtzeitdaten von IoT-Sensoren sowie Daten aus bestehenden Fachverfahren und Fachportalen. Nach einer inhaltlichen Validierung stellt die Plattform jeden Datensatz in mehreren Formaten bereit: als Download im Portal, über REST-APIs, als Linked Open Data (SPARQL), als Geodienste (WFS/WMS) und als Echtzeit-Stream (SensorThings/MQTT). Das zentrale Verzeichnis ist ein DCAT-AP-konformer Datenkatalog, der die Datensätze auffindbar und maschinenlesbar macht.
Entwickelt wird die ODI von Dataport AöR im Auftrag des Landes Schleswig-Holstein. Der gesamte Quellcode ist unter der EUPL-1.2-Lizenz auf openCode veröffentlicht.
Ausführliche rechtliche und funktionale Anforderungen beschreibt der Bereich Datennutzungsgesetz (DNG).
Qualitätsziele¶
Die folgenden fünf Qualitätsziele haben für die Architektur der ODI den höchsten Stellenwert. Sie prägen konkrete Entwurfsentscheidungen – von der Wahl der Validierungsbibliothek bis zur Katalog-Fassade.
| Priorität | Qualitätsziel | Bedeutung für die ODI |
|---|---|---|
| 1 | Datenqualität | Jeder Datensatz wird vor der Veröffentlichung inhaltlich gegen ein Frictionless-Schema geprüft. Ungültige Daten gelangen nie in den Katalog – das ist technisch erzwungen, nicht nur konventionell. |
| 2 | Offenheit & Interoperabilität | Die ODI verwendet ausschließlich offene Standards: DCAT-AP für Metadaten, OGC WFS/WMS für Geodaten, OGC SensorThings für Echtzeitdaten, RDF/SPARQL für Linked Open Data. Der Quellcode ist Open Source. |
| 3 | Nachvollziehbarkeit | Jeder Datensatz erhält eine unveränderliche datasetId. Berechtigungen werden als explizite Claims im JWT dokumentiert. Verwaltungen können Veröffentlichungen damit nachweisen. |
| 4 | Betreibbarkeit | Die Plattform ist cloud-native nach dem 12-Factor-Prinzip, deploybar per GitOps (FluxCD) und überwacht durch Grafana, Loki und VictoriaMetrics. Ein Dienst kann unabhängig neu gestartet werden, ohne andere zu beeinflussen. |
| 5 | Erweiterbarkeit | Neue Datentypen, Ausgabeformate oder Katalog-Technologien können ergänzt werden, ohne das Gesamtsystem zu ändern. Die Katalog-Technologie (CKAN oder Piveau) ist hinter einer stabilen Fassade gekapselt. |
Stakeholder¶
| Stakeholder | Erwartung / Interesse |
|---|---|
| Datenbereitsteller (Verwaltung SH) | Einfacher, sicherer Upload-Prozess; automatische Prüfung vor Veröffentlichung; klare Fehlermeldung bei Problemen. |
| Datennutzer (Bürger:innen, Entwickler:innen, Drittportale) | Vollständige, aktuelle und maschinenlesbar strukturierte Datensätze; stabile REST-APIs und SPARQL-/WFS-Endpunkte; offene Lizenzen. |
| Betrieb (Dataport, Cluster-Administration) | Automatisiertes Deployment ohne manuelle Deploy-Schritte; klare Monitoring-Signale; Secrets out-of-band verwaltet; Stage als 1:1-Spiegel der Produktion. |
| Auftraggeber (Land Schleswig-Holstein) | DNG-Konformität; Betrieb in der EU (IONOS); Open Source auf openCode; keine Abhängigkeit von US-Hyperscalern. |
| Entwicklungsteam (Dataport) | Klare Service-Grenzen; unabhängig deploybare Dienste; lokale Entwicklung per Docker Compose; gemeinsame CI-Templates. |
| Open-Source-Community | Nachnutzbarkeit des Quellcodes für andere Bundesländer oder Kommunen; saubere, dokumentierte Schnittstellen. |