Konzept Open Data Portal Baden-Württemberg Workshops am 27. und 28.08.2012 Unvollständige Diskussionsgrundlage ,

Ziele der Workshops Weiterführung der bisherigen Entwicklungen im Bereich Open Data Gegenseitiger Wissenstransfer Erarbeitung und Diskussion der Grundlagen für ein von allen Beteiligten getragenes Konzept zu einem Open Data Portal BW ,

Themen Zielgruppen Stärken und Schwächen von Open Data Chancen und Risiken / Herausforderungen Im Land bestehende Daten- und Informationsportale Warum dann noch ein Open Data Portal BW? Warum nicht gleich das nationale Open Government Data Portal mitnutzen? Merkmale eines Open Data Portals BW Daten- und Informationsangebot im ODP BW Rechtsform Nutzungsbestimmungen Steuerung und Koordinierung Weitere Fragen

Weitere Themen Technik Metadaten Daten, Dokumente und Anwendungen Struktur Format Kategorien Formate Daten, Dokumente und Anwendungen Erfassung Metadaten Portalfunktionen Rollen und use-cases Portalarchitektur und -design

Bürgerinnen und Bürger (Akteure der Privatheit und Familie) Wirtschaft (Akteure des Marktes) Politik und Verwaltung (Akteure des Staates) Einrichtungen und Organisationen der Zivilgesellschaft (Akteure des öffentlichen Bereichs) Medien (Garant des öffentlichen Bereichs sowie Kontrolleure des staatlichen und wirtschaftlichen Bereichs) Wissenschaft (Akteure der Wissensproduktion und Hochschulausbildung) Bildungsträger (Akteure der Aus- und Weiterbildung) 1. Stimmen die Zielgruppen? 2. Weitere Zielgruppen? Zielgruppen Auflistung in Anlehnung an die klassischen Gesellschaftsbereiche Markt (wirtschaftlicher Bereich) Zivilgesellschaft (öffentlicher Bereich) Familie (privater Bereich) Staat (staatlicher Bereich) ,

Stärken und Schwächen von Open Data Erhöhte staatliche Transparenz Intransparenz durch Transparenz Vereinfachter Zugang zu Verwaltungsdaten und -informationen Aufwand und Unsicherheiten bei der Bereitstellung und Verwendung Verbesserte Grundlage für Bürgerbeteiligung Datenkomplexität Verbesserte Nachvollziehbarkeit von Informationen Unsichere Datenqualität Daten aus vertrauenswürdiger Quelle Verfügbarkeit der Daten Erleichterte Aufgabenerfüllung einzelner Zielgruppen Mangelnde Vergleichbarkeit Weiterverwendung und -verbreitung von Verwaltungsdaten 1. Weitere Stärken? 2. Weitere Schwächen? ,

Chancen und Risiken / Herausforderungen Image- und Akzeptanzgewinn (ÖV) Veränderung der Rolle von Organisationen (Wir, Wis, Med, Ziv, ÖV) Innovation und ökonomischer Mehrwert durch Weiterverarbeitung (Wir, ÖV) Existierende Qualifikationen unzureichend (Bü, ÖV, Ziv, Med) Unterstützung der Organisationen in der Verfolgung ihrer Ziele (Ziv) Überforderung, begrenzte Motivation und Zeit, Desinteresse und Informationsverdrossenheit (Bü) Zugang zu relevanten Informationen als Grundlage zur Mitwirkung an politischen Entscheidungen und Prozessen (Bü) De-Anonymisierung von Daten (ÖV) Ergänzung und Verbesserung wissenschaftlicher Ergebnisse (Wis) Datenqualität (Wir) 1. Weitere Chancen? 2. Weitere Risiken / Herausforderungen? ,

Es gibt im Land bereits viele, teilweise mächtige Daten- und Informationsportale Geoportal Umweltportal Geoportal Raumordnung Landesinformationssystem, Regionalstatistik Register im Justizbereich Weitere Daten- und Informationsportale/-quellen? ,

Warum dann ein Open Data Portal BW? Freie Suchmaschinen führen zu eher zufälligen Trefferlisten Suchanfragen zu gleichen Daten unterschiedlicher Gebietskörperschaften führen erst recht nicht zu befriedigenden Ergebnissen Nicht nur finden, was man sucht – und das ganz einfach -, sondern auch das, was man zwar nicht sucht, aber trotzdem sinnvoll und nützlich findet Zufallsgesteuerte Transparenz birgt das Risiko der Intransparenz Die Publikation von Daten ist nicht immer in den verwaltungsinternen Prozessen verankert Publizierte Daten und Informationen sind bisher nicht nach einheitlichen Kriterien beschrieben Heterogene Datenstrukturen, die zudem im Verborgenen bleiben, verhindern eine Weiterverwendung und Weiterverbreitung (sowohl durch beispielweise Existenzgründer als auch durch die öffentliche Hand selbst, etwa für linked open data) Einfache und fachübergreifende einheitliche Nutzungsbestimmungen fehlen 1. Stimmen die Gründe? 2. Gibt es weitere Gründe? ,

Warum nicht gleich auf das nationale Open Government Data Portal? Aufwand für alle Beteiligten wäre nicht geringer Noch höhere Komplexität (u. a. der Abstimmungs-, Kommunikations- und Redaktionsprozesse) Abhängigkeit von Dritten Innovationsführerschaft von Baden-Württemberg bei Serviceportalen ginge verloren Je mehr wir uns im Land einig sind, desto größer ist unser Einfluss auf nationale Entwicklungen 1. Stimmen die Gründe? 2. Sehen Sie weitere Gründe? ,

Merkmale eines Open Data Portals BW Ressortübergreifendes Portal erschließt Daten und Informationen aller Behörden und Einrichtungen des Landes und – optional – der Kommunen („Eine Adresse – alle Daten“) Differenzierung nach Daten (Gruppen von inhaltlich zusammenhängenden Datenfeldern, die in der Regel in von Maschinen verarbeitbarer Form bereitstehen). Dokumenten (können Daten, Text-, Bild- und/oder Audioinformationen enthalten und müssen nicht von Maschinen verarbeitbar sein) Anwendungen (Programme, die Daten der öffentlichen Hand nutzen) Einheitliche Metadatenstruktur für die Beschreibung von Daten, Dokumenten und Anwendungen als Voraussetzung für konsistenten Metadatenkatalog strukturierte Suche weitestgehend automatisierbaren Austausch von Metadaten zwischen Portalen Transparente, einfache und einheitliche Nutzungsbestimmungen Klare, einfache, barrierefreie Navigation Offen für innovative Weiterentwicklungen 1. Stimmen die Merkmale? 2. Weitere Merkmale? ,

Daten- und Informationsangebot Start mit Grundangebot an Daten und Anwendungen (potenzielle Nachfrage, besonders interessante Angebote) und weiteren Daten, Dokumenten und Anwendungen unter dem Aspekt der Transparenz und Informationsfreiheit Inhalte des Prototyps (Link auf Dokument) Erste Vorschläge der Ressorts und Kommunen (Link auf Dokument) Weitere Vorschläge (Link auf Dokument) Nach Inbetriebnahme gezielte nachfrageorientierte Ergänzungen 1. Stimmt dieser Ansatz? 2. Weitere Vorschläge? ,

Daten- und Informationsangebot 1. Nach welchen Kriterien publizieren die Ressorts heute Daten und Dokumente? 2. Wer entscheidet über die Publikation? Gibt es eine zentrale Steuerung / Koordinierung? 3. Gibt es für die Publikation Prozessbeschreibungen, Leitfäden und/oder andere interne Regelungen? Beispiele? 4. Wer prüft die Daten hinsichtlich möglicher Schutzrechte? 5. Wer legt die Nutzungsbestimmungen fest? Gibt es dafür interne Standards? 6. Gibt es technische Standards (z.B. Datenstrukturen und –formate)? 7. Wo werden die Daten gehalten? 8. Welche Gründe gibt es für gemeinsame Empfehlungen? In welchen Bereichen? 9. Welche Gründe gibt es dagegen? ,

Rechtsform Portalbetrieb öffentlich-rechtlich Portal wird durch konkludente Widmung zu öffentlicher Sache Datenbereitstellung grundsätzlich öffentlich-rechtlich privatrechtliches Handeln bleibt möglich Zwischen Datenbereitsteller und Nutzer sowie zwischen Portal und Nutzer entstehende Beziehungen sind öffentlich-rechtlich 1. Stimmen die Vorstellungen? 2. Was ist noch zu beachten? ,

Nutzungsbestimmungen CC-Lizenzen kommen aus dem anglo-amerikanischen Rechtsraum und sind nicht ohne Anpassung auf das deutsche Urheberrecht bzw. das öffentlich-rechtliche Sachenrecht (Widmungsrecht) übertragbar Bund-Länder-Arbeitsgruppe entwickelt kurzfristig zunächst eine Standardnutzungsbestimmung, deren Anwendung den Datenbereitstellern aller Ebenen empfohlen werden kann schlanke, einfache Lösung (umfassende Weiterverwendung mit Namensnennung, Haftung) an europäischer Entwicklung orientiert nur unverzichtbare Inhalte (Nutzungsrechte, Nutzungsbedingungen, Haftung) In einem weiteren Schritt geplant sind Varianten nach den Fallgruppen Geldleistungspflicht/-freiheit (nur deklaratorisch) und private/kommerzielle Weiterverwendung und Weiterverbreitung (jeweils in Kombination), ohne damit den Anspruch einfacher und schlanker Regelungen aufzugeben In diesem Kontext ist auch der Regelungsbedarf zur De-Publikation zu klären Vorschlag: Ergebnisse der Bund-Länder-Arbeitsgruppe übernehmen Die Beibehaltung von Nutzungsbestimmungen, die die Datenbereitsteller bereits verwenden, bleibt möglich Datenbereitsteller entscheiden eigenverantwortlich über Nutzungsbestimmungen ihrer Daten 1. Stimmen die Vorstellungen? 2. Welche Gesichtspunkte muss die Bund-Länder-Arbeitsgruppe beachten? ,

Steuerung und Koordinierung Steuerung: Lenkungsausschuss service-bw Koordinierung Ressorts auf Arbeitsebene: AG ODP BW Betrieb: unter dem Dach von service-bw 1. Passt die Struktur? 2. Steuerung durch LA service-bw ausreichend für Einbeziehung der Kommunen und der Zivilgesellschaft? 3. Ansprechpartner der Ressorts und Kommunen für das Konzept? 4. Koordinierung Kommunen auf Arbeitsebene? ,

Weitere Fragen 1. Kommunikation in die Ressorts und Kommunen (Informieren, zur Beteiligung aktivieren etc.)? 2. Einbeziehung der Angebote an Daten, Dokumenten und Anwendungen Dritter? 3. Einbeziehung der Zielgruppen (z. B. Akteure der Wirtschaft und der Zivilgesellschaft) in die konzeptionelle Arbeit? 4. Ressourcenaufwand? 5. Finanzierung 6. Handbücher und Leitfäden ,

UAG Technik ,

Metadaten Datensätze – Basismetadaten Metadaten Eintrag Pflicht Bezeichner Titel x title Eindeutiger Bezeichner name Beschreibung notes Kategorie group Schlagwörter   tags Kontaktinformation Daten Name/Stelle (Ersteller creator) author Kontaktinformation Daten URL author_url Kontaktinformation Metadaten Name/Stelle (publisher) maintainer Kontaktinformation Metadaten URL maintainer_url Veröffentlichungsdatum extras:date_released Änderungsdatum extras:date_updated Webadresse zu weiteren Informationen über den Datensatz url Lizenz license_id ,

Metadaten Datensätze – Basismetadaten / Abgleich mit Prototyp Metadaten Eintrag Pflicht Prototyp ODP BW Titel x / x Titel des DS Eindeutiger Bezeichner lfd. Nummer Beschreibung - / x Kurzbeschreibung Kategorie Schlagwörter - / x  Kontaktinformation Daten Name/Stelle (Ersteller creator) Eigentümer des DS Kontaktinformation Daten URL Info zum DS bei Kontaktinformation Metadaten Name/Stelle (publisher)  - / x DS beschr. Stelle Kontaktinformation Metadaten URL Kontakt (beschr. St.) Veröffentlichungsdatum Publiziert oder aktualisiert am Änderungsdatum - / s.o.  Webadresse zu weiteren Informationen über den Datensatz - / -  Link auf Seite der Datenquelle Lizenz Lizenztyp, N.beding. Folie 20 , Seite 20

Metadaten Datensätze – Ressourcen und Extras Metadaten Eintrag Pflicht Bezeichner Ressourcen x resources URL url Format format Beschreibung description Sprache language URL Dokumentation doc SHA2-Prüfsumme   hash Geographische Abdeckung extras:geographical_coverage Geographische Granularität extras:geographical_granularity Zeitraum von extras:temporal_coverage_from Zeitraum bis extras:temporal_coverage_to zeitliche Granularität extras:temporal_granularity ,

Metadaten Datensätze – Ressourcen und Extras / Abgleich mit Prototyp Metadaten Eintrag Pflicht Prototyp ODP BW Ressourcen x / x implizit gegeben URL Link auf Datenquelle Format Format des DS Beschreibung - / - Datensatzattribute (Feldbezeichnungen) Sprache - / x language URL Dokumentation ? SHA2-Prüfsumme - / -  Hash des DS, Prüfsumme Geographische Abdeckung  - / x Geografische Abdeckung Geographische Granularität Geografische Auflösung Zeitraum von Zeitraum bis zeitliche Granularität Zeitliche Auflösung Folie 22 , Seite 22

Metadaten Datensätze – Erweiterbarkeit Metadaten Eintrag Pflicht Bezeichner URL Originalmetadateneintrag extras:metadata_original URLs für weitere Schlagwortquellen extras:tag_sources URLs für Thesauri extras:thesauri (e.g. EuroVoc) Weitere Schlüssel/Wert-Paare, nur wenn nötig. Schlüssel muss eine Linked Data URI sein. z.B. extras: “http://ogdd.de/lod/version“:3.0 ,

Metadaten Datensätze – Erweiterbarkeit / Abgleich mit Prototyp Metadaten Eintrag Pflicht Prototyp ODP BW URL Originalmetadateneintrag noch nicht enthalten URLs für weitere Schlagwortquellen URLs für Thesauri Weitere Schlüssel/Wert-Paare, nur wenn nötig. Schlüssel muss eine Linked Data URI sein. Folie 24 , Seite 24

Metadaten Datensätze - Delta nach Abgleich mit Prototyp Herkunft (Bz) Datensatzbeschreibung zuletzt geändert am (Bz) Bezeichnung des Metadatenstandards (D) Kurze URL (C) Eigentümer des Datensatzes (B) Kontakt Eigentümer (B) Herausgeber des Datensatzes (B) Kontakt Herausgeber (B) Aktualisierungsturnus (Bo) Hierarchieebene / Bezugsebene (D) Datenqualität (D) Zeichensatz (C) Größe des Datensatzes (C) A: Pflichtfeld GDI-BW, Anzeige im Frontend B: Pflichtfeld GDI-BW, erweiterte Anzeige im Frontend Bo: wie B, aber optional Bz: wie B, bisher aber zurückgestellt C: kein Pflichtfeld GDI-BW, Erfassung optional, erweiterte Anzeige im Frontend D: Pflichtfeld GDI-BW, keine Anzeige im Frontend

Metadaten Dokumente – Basismetadaten 2626 Metadaten Eintrag Pflicht Bezeichner Wertebereich Titel x title frei Eindeutiger Bezeichner name URL Beschreibung notes Kategorie group Festgelegte Liste Schlagwörter   tags Kontaktinformation Dokumente Name/Stelle (Ersteller/creator) author Kontaktinformation Dokumente URL author_url Kontaktinformation Dokumente Metadaten Name/Stelle (publisher) maintainer Kontaktinformation Dokumente Metadaten URL maintainer_url Veröffentlichungsdatum extras:date_released ISO 8601 Datum Änderungsdatum extras:date_updated ,

Metadaten Dokumente – Lizenz, Ressourcen, Erweiterbarkeit 2727 Metadaten-Eintrag Pflicht Bezeichner Wertebereich Lizenz x license_id Festgelegte Liste mit IDs Ressourcen resources URL url Format format Festgelegte Liste Beschreibung description frei Sprache language SHA2-Prüfsumme   hash Hex String, wahlweise URL zu Zertifikat Sektoren extras:sectors Öffentlicher Sektor Privater Wirtschaftssektor Andere Verwendete Datensätze extras:used_datasets JSON-Format Liste mit URLs auf Metadaten ,

Metadaten Anwendungen – Basismetadaten 2828 Metadaten Eintrag Pflicht Bezeichner Wertebereich Titel x title frei Eindeutiger Bezeichner name URL Beschreibung notes Schlagwörter   tags Kontaktinformation Name/Stelle (Ersteller/creator) author Kontaktinformation URL author_url Kontaktinformation Metadaten Name/Stelle (publisher) maintainer Kontaktinformation Metadaten URL maintainer_url Veröffentlichungsdatum extras:date_released ISO 8601 Datum Änderungsdatum extras:date_updated Webadresse zu weiteren Informationen url ,

Metadaten Anwendungen – Basismetadaten / Abgleich mit Prototyp 2929 Metadaten Eintrag Pflicht Prototyp ODP BW Titel x / x Eindeutiger Bezeichner Lfd. Nummer Beschreibung - / x Kurzbeschreibung Schlagwörter Kontaktinformation Name/Stelle (Ersteller/creator) x / (x) noch nicht enthalten (dagegen AP) Kontaktinformation URL Kontaktinformation Metadaten Name/Stelle (publisher) Anwendung beschreibende Stelle Kontaktinformation Metadaten URL Kontakt (beschreibende Stelle) Veröffentlichungsdatum x / - noch nicht enthalten Änderungsdatum   Webadresse zu weiteren Informationen - / -  Link auf Erläuterungen zur Anwendung Metadaten Eintrag Pflicht Bezeichner Wertebereich Titel x title frei Eindeutiger Bezeichner name URL Beschreibung notes Schlagwörter   tags Kontaktinformation Name/Stelle (Ersteller/creator) author Kontaktinformation URL author_url Kontaktinformation Metadaten Name/Stelle (publisher) maintainer Kontaktinformation Metadaten URL maintainer_url Veröffentlichungsdatum extras:date_released ISO 8601 Datum Änderungsdatum extras:date_updated Webadresse zu weiteren Informationen url Folie 29 , Seite 29

Metadaten Anwendungen – Lizenz, Ressourcen, Erweiterbarkeit 3030 Metadaten-Eintrag Pflicht Bezeichner Wertebereich Lizenz x license_id Festgelegte Liste mit IDs Ressourcen resources URL url Beschreibung description frei SHA2-Prüfsumme   hash Hex String, wahlweise URL zu Zertifikat Typ resource_type Festgelegte Liste App Screenshot Sektoren extras:sectors Verwendete Datensätze extras:used_datasets JSON-Format Liste mit URLs auf Metadaten ,

Metadaten Anwendungen – Lizenz, Ressourcen, Erweiterbarkeit / Abgleich mit Prototyp 3131 Metadaten-Eintrag Pflicht Prototyp ODP BW Lizenz x / - noch nicht enthalten Ressourcen x / x implizit enthalten URL URL (Link auf Anwendung) Beschreibung - / x Kurzbeschreibung SHA2-Prüfsumme - / -  Typ Sektoren Verwendete Datensätze Folie 31 , Seite 31

Kategorien noch zu ergänzen ,

Erfassung Metadaten Import von Metadaten aus anderen Portalen Einsatz von Programmen („Harvester“), die gezielt und kontrolliert in enger Absprache mit den Portalverantwortlichen Metadaten weitestgehend ohne manuellen Aufwand „einsammeln“ Nutzung der Erfahrungen beim Aufbau des Prototyps eines nationalen ebenenübergreifenden Open Government Data Portals Erfassung der Metadaten durch Datenbereitsteller über ein Webformular Erfassung der Metadaten zu einzelnen Daten Automatisierte Übertragung durch Datenbereitsteller über API 1. Stimmen die Vorstellungen? 2. ist API-Variante nötig? ,

Rollen und Use-Cases (1) Portalnutzer Daten und Dokumente suchen, sichten, herunterladen Daten auswerten, verknüpfen, aggregieren, visualisieren Auswertungs- und Visualisierungsergebnisse speichern und exportieren Anwendungen suchen, sichten, nutzen Anwendungsergebnisse speichern und exportieren Registrieren, Nutzerprofil verwalten Einträge in Blog und Forum Datenbereitsteller Metadaten zu eigenen Daten, Dokumenten und Anwendungen erstellen, editieren, aktualisieren, ausblenden, löschen alle: im Portal registrieren, anmelden, abmelden Folie 34 , Seite 34

Rollen und Use-Cases (2) alle: im Portal registrieren, anmelden, abmelden Portalredakteur Portalinhalte erstellen, editieren, aktualisieren, löschen Metadaten zu Daten, Dokumenten und Anwendungen löschen Qualität der Metadaten sichern Blog und Forum moderieren Kommentare moderieren / freischalten Nutzer blockieren Vorschläge zu Daten, Dokumenten und Anwendungen verwalten Nutzung überwachen und Berichte erstellen Administrator Links in Metadaten pflegen (Linkchecker) Nutzer verwalten Metadatenschema verwalten Harvester administrieren Folie 35 , Seite 35

Rollen und Use-Cases (3) 1. Stimmen die Rollen und Use-Cases? 2. Was muss ggf. verändert oder ergänzt werden? 3. Wie wird die Qualität der Metadaten gesichert (Manuell erfasste und maschinell importierte Metadaten, Vermeidung von Dubletten etc.)? 4. Umgang mit Forumsbeiträgen, Blogkommentaren etc.? 5. Müssen wir sonst etwas beachten? Folie 36 , Seite 36

Portalarchitektur und -design 1. Was müssen wir bei der Architektur des Portals im Verbund mit den die Daten haltenden Systemen beachten? Portal Frontend Datenkatalog Backoffice Datenhaltung Sicherheitsaspekte Verbindung zu anderen Portalen …. 2. Was müssen wir beim Portaldesign beachten? Funktionen Navigation Suche Seitengestaltung ,

Die politischen Ziele und das liebe Geld Koalitionsvertrag Seite 79: Transparenz des Regierungshandelns im Netz „In einem umfassenden Informationsfreiheitsgesetz werden wir gesetzliche Regelungen treffen, damit Bürgerinnen und Bürger unter Beachtung des Datenschutzes grundsätzlich freien Zugang zu den bei den öffentlichen Verwaltungen vorhandenen Informationen haben. Wir werden unser Regierungshandeln daran orientieren, die zugrunde liegenden Daten und Dokumente weitestmöglich öffentlich zugänglich zu machen. Hier orientieren wir uns am Grundsatz „Open Data“.“ Finanzierungsvorbehalt: Die Umsetzung des zu erarbeitenden Konzepts für ein Open Data Portal Baden-Württemberg steht unter einem ausdrücklichen Finanzierungsvorbehalt. In den Planansätzen für das Haushaltsjahr 2013/2014 konnten dafür bisher keine Mittel veranschlagt werden. Dies ist innerhalb des für den Einzelplan 03 gesetzten Limits auch nicht möglich. Folie 38 Folie 38 , Seite 38