Weiterentwicklung des Open-Data-Angebots des Parlaments

(1)

www.parlament.gv.at

OFFENES PARLAMENT – OFFENE DATEN

www.parlament.gv.at/SERV/OGD [email protected]

(2)

2 / 24

Inhaltsverzeichnis

Weiterentwicklung des Open-Data-Angebots des Parlaments ... 3 Crowdsourcing-Prozess: „Weiterentwicklung des Open-Data-Angebots“ ... 4 Empfohlene Handlungsfelder des Crowdsourcing-Prozesses... 6

Handlungsfeld 1: Programmschnittstelle 7

Handlungsfeld 2: Linked Open Data und Semantik 9

Handlungsfeld 3: Parlamentarierprofile 11

Handlungsfeld 4: Gesetzeshistorie 15

Handlungsfeld 5: Plenarsitzungen 17

Handlungsfeld 6: Normierung von parlamentarischen Anfragen 19

Handlungsfeld 7: Rechtssicherheit 20

Handlungsfeld 8: Historische Daten 22

Handlungsfeld 9: Developer Hub 23

(3)

3 / 24

Weiterentwicklung des Open-Data-Angebots des Parlaments

Die einfache Nutzung öffentlicher Daten des Gesetzgebungsprozesses ist ein wesentlicher Bestandteil der Transparenz von parlamentarischen Abläufen. „Art. 32 B-VG (Öffentlichkeit der Sitzungen des Nationalrates), Art. 33 B-VG (sachliche Immunität) und Art. 37 Abs. 3 B-VG (Öffentlichkeit der Sitzungen des Bundesrates und sachliche Immunität) werden seit jeher weit ausgelegt und die geschäftsordnungsrechtlichen Bestimmungen - insbesondere die §§ 14, 22 und 52 iVm 23a sowie der ab 1. August 2021 in Geltung stehende § 23b GOG-NR und die §§

7, 17 und 65 GO-BR - stellen sicher, dass die Informationen über parlamentarische Verhandlungen und Beratungen in weitest möglichem Umfang öffentlich zugänglich sind.“¹ Seit 2013 bietet die Parlamentsdirektion ein umfassendes Daten-Angebot zur Weiterverarbeitung an. Dieses Angebot wird laufend entsprechend der rechtlichen Möglichkeiten – Stichwort Datenschutz und Urheberrecht – weiterentwickelt. Die EU-Richtlinie über Offene Daten und die Weiterverwendung von Informationen des öffentlichen Sektors (PSI-Richtlinie) gibt Mindestanforderungen vor, die seitens der Parlamentsdirektion bereits erfüllt werden. Der Qualitätsanspruch an öffentliche Daten steigt stetig und drückt sich zunehmend in Nachfragen und Vorschlägen der Open Data Community gegenüber der Parlamentsdirektion aus. Dementsprechend ist die Parlamentsdirektion bemüht, diesen Wünschen nachzukommen – so wurde z.B. eine XML-API eingerichtet. Da die Verbesserungen und deren Kommunikation an die Community aber auch immer eine Ressourcenfrage sind, gibt es dabei immer noch Nachholbedarf.

Die Neugestaltung des Webauftritts bietet nun den geeigneten Rahmen für eine Evaluierung des Status Quo, um infolge in einer fokussierten Gesamtschau die bestehenden Datensätze für eine breite Nutzung optimal aufzubereiten und zu erweitern. Auf diese Weise soll dem Bedarf nachhaltig und koordiniert entsprochen werden, anstatt anlassbezogen stückweise

„nachzuarbeiten“.

1 Aus der Stellungnahme des RLW zum Informationsfreiheitsgesetz

(4)

4 / 24

Crowdsourcing-Prozess: „Weiterentwicklung des Open-Data-Angebots“

Da die österreichische OGD-Community hoch organisiert und stark engagiert ist, lag es zum Start des Open-Data-Angebots des Parlaments nahe, auf dieses breite Wissen zurückzugreifen, um die Herausforderungen der Nutzer besser zu

verstehen. Im Sinne der bestehenden Policy, eine bestmögliche Verwertung von veröffentlichen Daten durch Dritte zu ermöglichen, werden nun erneut Stakeholder sowohl aus dem Datenjournalismus, dem öffentlichen als auch dem privaten Sektor und der Wissenschaft in die Weiterentwicklung unseres Open-Data-Angebots eingebunden.

Der Prozess besteht aus vier Teilen:

 Sammeln von Ideen und Vorschlägen über die Plattform Crowdsourcing Österreich

 Präsentation der Ergebnisse in einer Videokonferenz

 Erstellen eines Arbeitsprogramms zur Einarbeitung in das Gesamtkonzept „Digitales Parlament: Webrelaunch“ zur Umsetzung bis Herbst 2022 (GoLive Website)

 Dauerhafte Bindung der OGD Community für innovativen Input und als eine Form von kommunikativem Community Management über das Projekt hinaus

Um auf das Wissen der Community strukturiert zurückzugreifen, wurde die hausinterne Crowdsourcing-Plattform crowdsourcing-oesterreich.gv.at genutzt. Den Teilnehmenden wurden folgende Fragen gestellt:

 Sind Sie mit dem heutigen Open Data Angebot des österreichischen Parlaments zufrieden? Wo sehen Sie Verbesserungsbedarf?

 Welche Anwendungen würden Sie gerne schreiben? Welche Daten benötigen Sie dafür?

 Welche Erwartungen haben Sie an Open-Data-Schnittstellen? Welche Formate sollten zur Verfügung gestellt werden?

 Welche Daten sollten auf der Website des österreichischen Parlaments selbst visualisiert werden?

(5)

5 / 24 Insgesamt haben sich bis zum Ende des Prozesses 60 Personen registriert. 17 Vorschläge wurden rechtzeitig eingebracht. Die Ergebnisse waren durchgehend konstruktiv und gingen detailliert auf die bisherigen Möglichkeiten und gewünschte Änderungen ein. Einem Nutzer konnte direkt bei der Verwendung der bestehenden Daten geholfen werden. Ein weiterer Teilnehmer wies die Parlamentsdirektion auf einen Fehler im bestehenden Daten Angebot hin.

Ein Wermutstropfen an dem Prozess ist, dass ausnahmslos männliche Teilnehmer Vorschläge einbrachten. Nach Ende des Prozesses wurde die Kommentarfunktion zum weiteren Austausch genutzt.

(6)

6 / 24

Empfohlene Handlungsfelder des Crowdsourcing-Prozesses

Seit 2013 stellt das Parlament Metadaten und Links auf Dokumente als offene Daten zur Weiterverarbeitung über einen RSS-Feed zur Verfügung. Dieser ist nur bedingt zur maschinellen Weiterverarbeitung der Daten geeignet. Daher werden seit 2018 diese offenen Daten auch über eine API als XML-Daten angeboten.

Wie auch in den praktischen Ausführungen der EU-PSI-Direktive erwähnt wird, wurde eine

„Open-Data by default“ oder „Open-Data first“ Strategie von einigen Teilnehmern des Prozesses angeregt. Das heißt, alle Daten und Dokumente werden grundsätzlich immer über eine Schnittstelle zur Verfügung gestellt, außer es stehen rechtliche Einwände entgegen.

Heute werden zwar die Volltextdokumente der Stenographischen Protokolle von Plenarsitzungen lizenziert zur Verwendung angeboten und deren Metadaten sowie die Links auf die Volltextdokumente können über einen RSS-Feed und im XML-Format abgerufen werden. Das Angebot der noch nicht zur Weiterverwendung freigegebenen bzw. im XML- Format abrufbaren Daten ist jedoch noch umfangreich und reicht von Biografien der ParlamentarierInnen bis hin zu den Daten aus der parlamentarischen Redezeitverwaltung.

Um eine hohe Qualität der neuen Website zu gewährleisten, sollte „die Parlaments-Website auf die Open-Data-Schnittstellen aufbauen“ und „anstatt Informationen in Dokumentform zu veröffentlichen, sollten sie wo immer möglich in Form strukturierter und angereicherter Daten zur Verfügung gestellt werden.“² Schon heute werden viele Daten in strukturierter Form oder zumindest in html-Format, das ein Parsen der Informationen ermöglicht, angeboten. Der Prozess hat jedoch gezeigt, dass einerseits bestehende Angebote (RSS-Feed, XML-API) oft nicht genutzt werden und andererseits die vorhandenen Möglichkeiten (Parsen von HTML- Seiten) noch deutlich vereinfacht werden können. Die Parlamentsdirektion konnte auf Grund der Anforderungen neun Handlungsfelder für die zukünftige Open-Data-Strategie identifizieren.

2 Zitate aus dem Crowdsourcing-Prozess werden kursiv ohne der Nennung der Autoren zitiert

(7)

7 / 24

Handlungsfeld 1: Programmschnittstelle

Ziel: Alle Daten werden strukturiert über eine API mit detailliert beschriebenen Metadaten zur Verfügung gestellt.

Ausgangspunkt:

Das derzeitige Open-Data-Angebot wurde weitgehend gelobt. Dennoch werden nicht alle Informationen, Daten und Dokumente, die das Parlament derzeit schon auf der Website veröffentlicht, auch als Open Data angeboten. Eine RSS-Schnittstelle ist nicht optimal, um die Daten weiterzuverarbeiten. Die derzeit angebotenen Daten machen oft weiterhin das Parsen von HTML-Seiten oder PDF-Dokumenten notwendig. Ebenfalls wird die Datengrundlage für Budgetanalysen derzeit nicht als Open-Data veröffentlicht.

Eingelangte Anregungen

Die Teilnehmer am Crowdsourcing-Prozess regten an, Daten des Gesetzgebungsprozesses und persönliche Daten von Abgeordneten in XML- und JSON-Format über eine API (z.B.

REST API) zur Verfügung zu stellen. Ein weiterer Teilnehmer regte zudem an, alle Orte, die in Dokumenten oder Biographien erwähnt werden, sowie die Sitzplätze der Abgeordneten zu georeferenzieren und über eine SPARQL-Schnittstelle zu etablieren. Sowohl eine XML- und JSON-REST-API als auch die SPARQL-API würde die Möglichkeit bieten, gezielt detaillierte Abfragen z.B. von mehreren Gesetzestexten zu tätigen.

„Wichtiger als die Technik“ sei jedoch die detaillierte Beschreibung der Metadaten auf OpenAPI Specification und data.gv.at.

Dazu muss erwähnt werden, dass der Parlamentsdirektion das Problem bewusst ist und schon einiges mehr umgesetzt wurde (z.B. XML-API) als aus Ressourcengründen dokumentiert und beschrieben werden konnte. Es ist uns dementsprechend bewusst, dass die Verbesserung dieses Punktes bereits enormes Potenzial darstellt.

(8)

8 / 24 Einordnung der Anregungen und weiteres Vorgehen

 Bereits teilweise vorhanden:

 Parlamentarische Materialien als XML über API

 Umsetzbar und geplant:

 JSON über API

 Georeferenzierungen

 Datengrundlage der Budgetanalysen über API

 Detaillierte Beschreibung der Metadaten

 Bessere Kommunikation des vorhandenen Angebots

 Nicht umsetzbar:

 SPARQL-Schnittstelle; die Ressourcen der Parlamentsdirektion sind nicht unbegrenzt vorhanden. Deshalb scheint die Konzentration auf die REST-API geboten.

(9)

9 / 24

Handlungsfeld 2: Linked Open Data und Semantik

Ziel: Alle Dokumente sind klar strukturiert, beschrieben und werden verlinkt angeboten.

Ausgangspunkt

Linked Open Data und semantische Beschreibungen nach einem bestimmten Standard bietet die Parlamentsdirektion bisher nicht an. Eine bessere Beschreibung sowie Verlinkung der einzelnen Angebote wäre möglich und sollte Ziel sein.

Linked Open Data ist der ‚Goldstandard’ der Datenverarbeitung und bietet die Möglichkeit, Entwicklungen und Sachverhalte darzustellen. Zwei Teilnehmer empfahlen, alle Dokumente der Gesetzgebungsprozesse durch den XML-Standard Akoma Ntoso zu beschreiben. Dieser wurde speziell für parlamentarische Arbeit, Gesetzgebung und Daten der Judikative entworfen.

Ein Teilnehmer schlug vor, sich am Standard der deutschen Open Knowledge Foundation, Oparl, zu orientieren. An welchen Standards sich die semantische Beschreibung orientieren wird, ist noch offen. Klar ist, dass dies ein wichtiger Schritt für die Verbesserung des Open- Data-Angebots sowie der Website selbst ist.

Darüber hinaus wurde mehrmals der Wunsch geäußert, die Kompatibilität mit der Seite ris.bka.gv.at und parlament.gv.at zu verbessern. Derzeit gibt es keinen gemeinsamen Identifikator bzw. eine einheitlich gehaltene Ordnungsnummer von Gesetzen und Regierungsvorlagen auf diesen beiden Seiten. Daher ist momentan „keine automatisierte Zuordnung möglich“. Die Verlinkungen sind somit nicht maschinell lesbar. Dies war auch eine zentrale Herausforderung des ManyLaws-Projekts und sollte daher auch für zukünftige Projekte forciert werden.

Für die Weiterverarbeitung von Daten der Website ist eine klare Struktur der Informationen unerlässlich. Schreibweisen von Institutionen, Organisationen und Personen müssen einheitlich gehalten werden. Laufende Verbesserungen wie z.B. die einheitliche Bezeichnung von Ministerien werden auch in Zukunft fortgesetzt werden. Dies ist jedoch schwierig zu bewerkstelligen, wo sie nicht von der Parlamentsdirektion eingegeben werden wie z.B. bei Stellungnahmen. Datumsangaben sollen einheitlich gehalten und maschinell lesbar zur Verfügung gestellt werden. Dies ist auch heute schon der Fall.

(10)

 Bereits vorhanden:

 Einheitliche Schreibweise von Ressorts

 Einheitliche Datumsangaben

 Semantische Beschreibung und Standard dafür; ob das Akoma Ntoso oder OPARL sein wird, ist noch nicht entschieden.

 Linked Open Data

 Bessere Kompatibilität mit RIS

 Teilweise nicht umsetzbar:

 Einheitliche Schreibweise für Organisationen und Personen, da z.B. bei Stellungnahmen zu Ministerialentwürfen Daten aus Ressorts kommen

(11)

11 / 24

Handlungsfeld 3: Parlamentarierprofile

Ziel: Ausgewählte Metadaten über die ParlamentarierInnen werden in strukturierter Form über eine API angeboten.

Ausgangspunkt

Die Profile der Abgeordneten sind auf der Website des Parlaments veröffentlicht. Die Daten sind (weitgehend) in einer Datenbank erfasst, werden bisher jedoch größtenteils noch nicht als Open Data angeboten. Dies kann im Zuge einer Erweiterung der API umgesetzt werden.

Durch eine genaue Beschreibung der Metadaten und der strukturierten Aufbereitung der Informationen mit Datumsangaben soll in Zukunft das Parsen der Parlamentarierprofile weitgehend obsolet werden.

Es gibt derzeit keinen Anhaltspunkt dafür, dass die Open-Data-Veröffentlichung der namentlichen Abstimmungen und der Verknüpfung mit Biografien der Abgeordneten politisch gewünscht wird. Eine Abstimmungsanlage zur Dokumentation und Veröffentlichung des Stimmverhaltens ist derzeit nicht vorhanden und soweit erkennbar, politisch auch nicht erwünscht.

Biografien der ParlamentarierInnen sollen auch über eine API in XML und/oder JSON angeboten werden.

Diese XML-API soll die Informationen, die heute schon auf der Website im HTML-Format veröffentlicht werden, in getrennten Feldern jeweils mit Anfangs- und Enddatum inkludieren:

Fotos mit Metadaten und Urheberrechtsangaben Akad. Grade (vor- und nachgestellt)

Vornamen und Nachnamen Geburtsdatum, Geburtsort Beruf

Kontaktdaten, getrennt nach Feldern für Organisation, Adressbestandteile, E-Mail, Telefon etc.

Biografie als Textfeld, oder noch besser falls geplant: Einzelne Einträge bei Politische Funktionen, Beruflicher Werdegang, Bildungsweg etc. maschinenlesbar mit Anfangs- und Enddatum nach Feldern getrennt.

Ausschussmitgliedschaften, bitte historisch mit Funktionen sowie Anfangs- und Enddatum.

(12)

12 / 24 Angabe bei jedem Profil, welcher Wahlkreis, welche Wahlpartei und welche Klubmitgliedschaft, von wann bis wann. Daraus ergibt sich auch die Möglichkeit nachzuvollziehen, wenn jemand innerhalb einer Legislaturperiode das Mandat oder den Klub wechselt oder in einer weiteren Wahl für eine andere Wahlpartei kandidiert.

Stimmverhalten bei namentlichen Abstimmungen, mit Link auf das jeweilige Stenografische Protokoll

Falls tatsächlich ein Abstimmungscomputer angeschafft wird, sollte auch das Abstimmungsverhalten für jede Abstimmung pro Abgeordnetem aufgezeichnet und ausgegeben werden (mit Link auf das jeweilige Stenografische Protokoll)

Bereichssprecher für welches Thema - historisch mit Anfangs- und Enddatum und in welchem Klub.

Links zu allen Videos mit Reden des/der jeweiligen Abgeordneten, mit Datum, Uhrzeit (von- bis), Sitzung, TOP, sonstige Metadaten und ggf. Embed-Code

Links zu allen transkribierten Redebeiträgen in den Stenographischen Protokollen (wie Video- Links)

Liste gemäß § 9 Bezügebegrenzungs-BVG:

Jahr

Einkommenskategorie

Alle Rechtsträger und alle Funktionen in den einzelnen Kategorien in getrennten Feldern (mit Vermerk, aus welchen Funktionen Vermögensvorteile erzielt werden), möglichst mit Anfangs- und Enddatum für jede Funktion.

Sonstiges:

Mitgliedschaften und Funktionen in Parlamentsklubs (jeweils von/bis pro Funktion)

Mitgliedschaften und Funktionen in der Delegation zur Parlamentarischen Versammlung des Europarats (jeweils von/bis pro Funktion)

Mitgliedschaften und Funktionen in bilateralen parlamentarischen Gruppen (jeweils von/bis pro Funktion)

Fonds, Stiftungen, Kommissionen etc. (jeweils von/bis pro Funktion)

Mitgliedschaften und Funktionen in Parlamentarierkonferenzen, falls verfügbar (jeweils von/bis pro Funktion)

(13)

13 / 24 Es sollte auch weiterhin möglich sein, die Verhandlungsgegenstände, an denen ein Abgeordneter mitgewirkt hat sowie Protokolle der Plenarsitzungen strukturiert über einzelne Abgeordnete abzufragen.

Darüber hinaus wurde der Vorschlag eingebracht, das Abstimmungsverhalten und die Anwesenheit bei Abstimmungen von einzelnen Abgeordneten elektronisch zu erfassen. Dafür wäre „ein elektronisches Abstimmungssystem (…) als Basis für eine strukturierte Aufzeichnung der Abstimmungen notwendig.“

(14)

 XML-API

 Auf Website: Verknüpfung mit Redebeiträgen der ParlamentarierInnen – als Video und Stenographisches Protokoll

 Veröffentlichung aller vorliegenden Parlamentarierdaten über API

Strukturierte Erfassung und Veröffentlichung bisher nicht strukturiert erfasster Daten (z.B. BereichssprecherInnen)

 Veröffentlichung historischer Daten ab 1996 (davor nicht strukturiert vorhanden) über API

 Links zu Videos und Stenographischen Protokollen über API

 Die Bereitstellung von Embedcodes im Rahmen des Webrelaunches wird derzeit diskutiert; eine Verhinderung des Einbettens von Content gibt es weder derzeit noch zukünftig; die Parlamentsdirektion wird derartige Anliegen auch gerne unterstützen

 Derzeit nicht umsetzbar:

 Vollständige CC-BY Lizensierung aller Biographie-Daten insbesondere der Videos und Fotos der Abgeordneten.

 Stimmverhalten der Parlamentarier; dafür würde die Parlamentsdirektion die Erfassung des Stimmverhaltens mittels Abstimmungsanlage dokumentieren müssen. Ob eine solche kommt, ist eine politische Entscheidung, keine Entscheidung der Verwaltung.

 Veröffentlichung der Funktionen der ParlamentarierInnen in internationalen Organisationen, Klubs etc.; diese Informationen werden derzeit nicht gesammelt und auch nicht publiziert. Aufgrund der Ressourcenfrage ist dies derzeit auch nicht geplant.

(15)

15 / 24

Handlungsfeld 4: Gesetzeshistorie

Ziel: Die Entstehung von Gesetzen wird vollständig und verlinkt veröffentlicht.

Ausgangspunkt

Unterschiedliche Versionen von Gesetzesentwürfen, angenommene und abgelehnte Anträge sowie Erläuterungen zu Gesetzen und Gesetzesänderungen enthalten wichtige Informationen zur Entstehung des Gesetzes und somit zu dessen Auslegung. Einzelne Stationen von Gesetzesinitiativen werden schon jetzt über eine API veröffentlicht.

Im Zuge des Webrelaunches ist eine verbesserte Darstellung von Verknüpfungen einzelner Verhandlungsgegenstände bzw. der Geschichtsseiten von Gesetzen geplant. Diese werden in Zukunft über eine API angeboten. Gleiches gilt für Begutachtungsentwürfe: diese sollen mit Stellungnahmen und Regierungsvorlagen verknüpft und über die API abrufbar sein. Bei Stellungnahmen von nicht öffentlichen Institutionen sind jedoch datenschutz- und urheberrechtliche Aspekte zu beachten.

Es sollen nicht nur einzelne Gesetze sondern vollständige „Gesetzesinitiativen“ abgebildet werden. Es sollten also in „strukturierter Form sämtliche relevanten Informationen eines Gesetzes(vorhabens)“ angeboten werden.

Um diese zentralen Informationen zugänglicher zu machen, sollen diese zumindest in einem XML-Format angeboten werden. Dies würde Nutzern eine verbesserte Textgegenüberstellung von Gesetzen bzw. eine Darstellung der historischen Entwicklung ermöglichen. Als best practice Beispiel wurde hier des Bundesgit genannt.

Kritisiert wurde, dass viele Datensätze von Begutachtungsentwürfen unvollständig oder nicht verlinkt sind. „So fehlen etwa bei Stellungnahmen oder Petitionen die Anzahl der Unterstützenden. Es gibt auch keine Möglichkeit nur über die RSS-Schnittstelle auch gleich an die Stellungnahmen zu kommen, stattdessen kommt man erstmal nur auf die Begutachtungsentwürfe selbst. Und oftmals sind eben vorhandene Daten nicht über die Schnittstellen abrufbar sondern nur über HTML-Parsing der Webseiten automatisiert zu bekommen. Ebenfalls fehlt etwa die Zuordnung zwischen Begutachtungsentwürfen und Regierungsvorlagen“.

(16)

 Einzelne Stationen von Gesetzesentwürfen über API abrufbar

 Geschichtsseiten der Gesetzesmaterien über API

 Stellungnahmen über API (vorbehaltlich einer urheberrechtlichen Prüfung)

 Zuordnung/Verlinkung im Begutachtungsverfahren (Ministerialentwürfe, Stellungnahmen, Regierungsvorlagen) und Bereitstellung über API

(17)

17 / 24

Handlungsfeld 5: Plenarsitzungen

Ziel: Tagesordnungspunkte sind mit Verhandlungsgegenständen verknüpft und einzelne Reden und Stenographische Protokolle sind maschinell lesbar.

Ausgangspunkt

Tagesordnungen sind bereits jetzt mit Verlinkungen zu den Verhandlungsgegenständen als HTML verfügbar, gleiches gilt für die Verlinkungen auf den einzelnen Parlamentarierprofilen.

Diese Informationen sollen künftig auch als XML über die API angeboten werden.

Die Protokolle der Sitzungen werden bereits jetzt gegliedert in Einzelreden als HTML abgebildet. Auch hier gilt, dass diese künftig über die API abrufbar sein sollen. Auch Bezüglich der Unterscheidbarkeit von Reden und Anträgen in den Protokollen wird es eine Lösung geben.

Im Rahmen des Prozesses wurde vorgeschlagen, dass Tagesordnungspunkte zeitnah veröffentlicht und mit Verhandlungsgegenständen und Namen verlinkt werden und über eine XML-API angeboten werden. „In weiterer Folge wäre auch eine Einbindung aller Abstimmungen zu diesem TOP zweckdienlich.“ Es besteht der Wunsch, dass getrennte Abstimmungen über Teile von Verhandlungsgegenständen ausgewiesen werden. Dies ist heute schon über die Stenographischen Protokolle möglich.

Mehrfach wurde angeregt, die Stenographischen Protokolle als Einzelreden auch in einem strukturierten Format über eine API zur Verfügung zu stellen. Der Akoma Ntoso XML Standard würde gezielte Abfragen ermöglichen.

Angemerkt wurde, dass momentan unsichtbare Unicodes das Auslesen der Reden unnötig erschweren. Derzeit sind die Redetexte schwer von den Rohtexten von Anträgen zu unterscheiden. Die Kennzeichnung von Zwischen- und Ordnungsrufen kann aktuell nicht maschinell ausgewertet werden. Hier würde „eine Splittung auf verschiedene Datenfelder den Text der Reden simpler halten.“ Für Datum und Uhrzeitangaben sollen getrennte Felder genutzt werden.

(18)

 Verlinkungen auf Verhandlungsgegenstände in Tagesordnungen und bei Parlamentarierprofilen – allerdings nur als HTML

 Einzelreden von ParlamentarierInnen in HTML

 Verknüpfung der Verhandlungsgegenstände über API

 Stenographische Protokolle/Einzelreden der Abgeordneten über API, wobei die Art der Lizenzierung noch zu klären ist

 Saubere Trennung von Redetext und Anträgen

 Kennzeichnung getrennter Abstimmungen über Teile von Gesetzesvorschlägen

 (Regierungsvorlagen, Initiativanträgen,…) und Bereitstellung über API

 Kennzeichnung von Zwischen- und Ordnungsrufen

 Getrennte Datums- und Uhrzeitangaben

(19)

19 / 24

Handlungsfeld 6: Normierung von parlamentarischen Anfragen

Ziel: Anfragen und Anfragebeantwortungen werden in normierten Formaten dargestellt.

Ausgangspunkt

Parlamentarische Anfragen und Anfragebeantwortungen beinhalten wichtige Informationen.

Dafür nutzen jeder Klub und jedes Ministerium eigene Vorlagen und stellt diese als PDF zur Verfügung. Dementsprechend uneinheitlich ist ihr Aussehen und die Darstellung. Eine Vereinheitlichung wäre wünschenswert, ist aber nur schwer umsetzbar. Darüber hinaus ist die Antwort alleine ohne Wiederholung der Fragestellung oft wenig hilfreich.

Es wurde angeregt, ein einheitliches Schema mit aufeinanderfolgenden Fragen und Antworten kompakt in einem Dokument einzuführen um Beantwortungen nachvollziehbarer zu gestalten.

Um dies zu bewerkstelligen, bedarf es einer normierten Form von parlamentarischen Anfragen und Anfragebeantwortungen sowie Rechtssicherheit für die Weiterverarbeitung.

„Anfragebeantwortungen und etwaige Anhänge sollten von Ministerien, zusätzlich zum bislang benutzten PDF Format, wenn immer möglich auch in einem maschinenlesbaren, nicht firmeneigenen Datenformat veröffentlicht werden (etwa als XML-, JSON- oder CSV-Datei)“.

Einordnung der Anregungen und weiteres Vorgehen

 Zentrale Informationen wie einbringende/r Abgeordnete, Datum der Anfrage, Frist für Beantwortung einheitlich und strukturiert über API

 Die Bereitstellung der eigentlichen Texte (vorbehaltlich einer eingehenden urheberrechtlichen Prüfung)

 Vereinheitlichung der Darstellung und Gegenüberstellung von Anfragen und Anfragebeantwortungen; da die Parlamentsdirektion auf die Anlieferung der Dokumente von Ressorts und Klubs angewiesen ist, ist hier kein ‚Quick Win‘ zu erwarten; ein Austausch mit den involvierten Parteien zur Optimierung ist jedoch angedacht.

(20)

20 / 24

Handlungsfeld 7: Rechtssicherheit

Ziel: Rechtssicherheit für die Parlamentsdirektion sowie für die Nutzer der Daten Ausgangspunkt

Aktuell bestehen Unsicherheiten, welche Informationen maschinenlesbar zur Verfügung gestellt werden dürfen. Bisher bestehen z.B. datenschutzrechtliche Bedenken, ob Anfragen und Anfragebeantwortungen zur automatisierten Weiterverarbeitung angeboten werden dürfen. Rechtssicherheit könnte etwa durch eine entsprechende gesetzliche Grundlage für die Datenveröffentlichung hergestellt werden.

Die zur Verwendung freigegebenen nicht-amtlichen/freien Werke werden derzeit mit der Creative-Commons-Lizenz CC-BY-AT 3.0 angeboten.

„Ein zentrales Element von Open Data ist eine freie Lizenz, die Nutzerinnen und Nutzern die freie kommerzielle und nichtkommerzielle Weiterverwendung dieser Inhalte einräumt – gegebenenfalls unter bestimmten Bedingungen wie Nennung des Autors, der Lizenz, und der Angabe, ob Änderungen des Originals vorgenommen wurden.“

Die auf data.gv.at bisher für nicht gemeinfreie Daten angewandte Creative-Commons-Lizenz soll aktualisiert werden. Diese erlaubt das Vervielfältigen und Verbreiten sowie das Bearbeiten von Daten für beliebige Zwecke bei gleichzeitiger Nennung des Dateneigentümers.

Ein Teilnehmer argumentiert: „die Aufnahme von Informationen der Legislative in das Informationsfreiheitsgesetz würde eine solche Rechtssicherheit bringen, da dadurch Interes- sierten die Möglichkeit gegeben wird, einen entsprechenden Informationszugang zu beantragen.“

Ein weiterer Teilnehmer schlug vor, dass „alle Abgeordneten dem Parlament das Recht einräumen, sämtliche Inhalte und Werke, die sie im Rahmen ihrer parlamentarischen Tätigkeit erstellen und die öffentlich zugänglich gemacht werden, der Öffentlichkeit (über die Parlamentsverwaltung) unter einer freien Lizenz zur Verfügung zu stellen.

Regierungsmitglieder und andere relevante Personen (etwa die Präsidentin des Rechnungshofs) sollten dem Parlament ebenso eine Zustimmung zur Weiterverwendung von im Rahmen parlamentarischer Prozesse erstellten Werken einräumen, sollte dies nötig sein.“.

Dies würde jedoch datenschutzrechtliche Probleme noch nicht lösen. Klar ist, dass die lizenzierte Weitergabe von Daten, Rechtssicherheit für die Parlamentsdirektion sowie den Nutzer voraussetzt. Dazu bedarf es einer erneuten Prüfung des Rechts-, Legislativ- und Wissenschaftlichen Diensts (RLW-Dienst) der Parlamentsdirektion.

(21)

 Auswahl an Daten als amtliche bzw. freie Werke

 Auswahl an Daten mit CC-Lizenzierung

 Aktualisierung der Lizenzen, sofern möglich. Im Fall von urheberrechtlichen Bedenken, soll eine möglichst offene Lizenz genutzt werden.

 Erneute Prüfung der Datenveröffentlichung durch RLW-Dienst nach Erlass des Informationsfreiheitsgesetzes

 Herstellung möglichst großer Rechtssicherheit für Parlamentsdirektion und Nutzer und Nutzerinnen des Angebots, insbesondere hinschlicht datenschutzrechtlicher Aspekte des Open-Data-Angebots z.B. über entsprechende Lizenzierungen.

 Einholen von Zustimmungserklärungen zur Absicherung gegenüber Urheberrechtsbedenken

 Abschließendes Ausräumen aller datenschutzrechtlichen Bedenken

(22)

22 / 24

Handlungsfeld 8: Historische Daten

Ziel: Historische Dokumente sind strukturiert und maschinenlesbar aufbereitet Ausgangspunkt

Die Website des österreichischen Parlaments bietet viele historische Dokumente und Informationen an. Diese sollen, wenn möglich strukturiert, aufbereitet werden, was –

abgesehen von Parlamentarierdaten – letztlich aber nur für Daten ab 1996 möglich sein wird.

Daten aus der Zeit davor sind meist nur als PDF-Dokumente verfügbar. Im Zuge des Web Relaunches wird jedoch nochmals geprüft, welche Daten strukturiert zu Verfügung stehen und über eine API angeboten werden können.

Die Teilnehmer regten die Auslieferung historischer Datenbestände über als strukturierte Daten über eine API an. Z.B. sollen Klub- und Ausschussmitgliedschaften auch für die Vergangenheit abgebildet werden.

Von Interesse war auch das Historische Abstimmungsverhalten.

Einordnung der Anregungen und weiteres Vorgehen

 Daten ab 1996 als HTML

 Daten von ParlamentarierInnen seit 1918 als HTML

 Bereitstellung der Daten ab 1996 über API

 Bereitstellung der Parlamentarierdaten ab 1918 über API

 Historisches Abstimmungsverhalten; diese Informationen liegen nicht vor

 Daten vor 1996 z.B. zu Ausschussmitgliedschaften, Stenographischen Protokollen etc.; hierfür müssten diese Daten erst bearbeitet und in eine entsprechende Struktur eingepflegt werden

(23)

23 / 24

Handlungsfeld 9: Developer Hub

Ziel: Open-Data-Angebot wird detailliert beschrieben und der Austausch mit der Community fortgesetzt.

Ausgangspunkt

Das Parlament bietet derzeit keinen eigenen Developer-Hub für seine offenen Daten an. Die Datenveröffentlichung erfolgt über data.gv.at, dort finden sich auch die Metadatenbeschreibungen etc. Ob es einen eigenen Developer-Hub des Parlaments braucht oder eine bessere Pflege der Daten auf data.gv.at ausreichend wäre, wird noch zu diskutieren sein. Da der Austausch und die Darstellung der angebotenen Daten schon heute auf data.gv.at und auf der Website umgesetzt wird, ist die Schaffung eines Parallelangebots zumindest zu hinterfragen.

Einige Teilnehmende schlugen einen Developer Hub nach britischem Vorbild vor. Dieses Portal zeigt übersichtlich, welche Daten wie zur Verfügung gestellt werden und bietet eine Feedback Möglichkeit. Die Möglichkeit des interaktiven Austauschs unter den Nutzern wurde empfohlen.

Darüber hinaus wäre eine ‚Bedienungsanleitung’ zur Weiterverwendung hilfreich, sodass die Rohdaten auch einer breiteren Öffentlichkeit zugänglich sind. In den Kommentaren ist die Idee entstanden, dieses Portal im Zuge von Hackathons in Schulen zu bewerben. Daraus könnte sich ein spannendes Folgeprojekt zur Demokratiebildung auf Basis des Open-Data-Angebots entwickeln.

Auf jeden Fall bietet ein Developer Hub die Möglichkeit, den konstruktiven Austausch mit der aktiven Community fortzusetzen.

(24)

 Daten über data.gv.at

 Austausch mit Community

 Beschreibung der Metadaten

 Bessere Wartung der Daten auf data.gv.at

 Bessere Beschreibung der API und "Gebrauchsanleitung"

 Aktive Verbesserung des Angebots auf data.gv.at

 Eigener Open-Data-Hub; die Schaffung einer Zweigleisigkeit neben data.gv.at scheint nicht sinnvoll, kann aber natürlich noch diskutiert werden