upsir-1.0.0 01.07.2015

Technisch/organisatorische Umsetzung der PSI Richtlinie

White Paper

upsir-1.0.0

Ergebnis der AG

Kurzbeschreibung Die Novelle der Richtlinie ber die Weiterverwendung von Informationen des ffentlichen Sektors, die innerstaatliche Umsetzung der Richtlinie im Informationsweiterverwendungs-gesetz, dessen Novelle und die sich darauf beziehenden jeweiligen neun Landesgesetze erfordern organisatorische und technische berlegungen zur Umsetzung.

Dieses White Paper fasst die angestellten berlegungen der BLSG Projektgruppe UPSIR zur PSI Umsetzung zusammen.

Autor(en): Christian Hirt

Projektteam / Arbeitsgruppe:

BLSG PG UPSIR

Beitrge von:

Mario Hillebrand

Mario Klier

Peter Krasser

Uwe Leissing

Oswald Mrth

Christoph Strasser

Gerald Streimelweger

Heike Wagner-Leimbach

Christof Zeller

Seite 2 / 15

upsir-1.0.0 01.07.2015

Technisch/Organisatorische Umsetzung der PSI Richtlinie

Inhaltsverzeichnis

0. Einleitung .............................................................................................................. 3 0.1. Allgemeine Information .............................................................................................. 3

0.1.1. Ziele 3 0.1.2. Nicht-Ziele ........................................................................................................................... 3

0.2. Zielgruppe .................................................................................................................. 3 0.3. Hinweis zum Dokument ............................................................................................. 3

1. Rahmenbedingungen ........................................................................................... 4 1.1. Umfeldanalyse ........................................................................................................... 4

1.1.1. Gesetzliche Grundlagen und Leitlinien ............................................................................... 4 1.1.2. Intention der PSI Richtlinie .................................................................................................. 4 1.1.3. Vorhandene Implementierungen ......................................................................................... 4

1.2. Prinzipien fr die Umsetzung der PSI-Richtlinie ......................................................... 5 2. Vorgaben fr die praktische Umsetzung ............................................................ 6

2.1. Auswirkungen der innerstaatlichen PSI Umsetzungen ............................................... 6 2.2. Mgliche Auswirkungen der B-VG nderung / IFG .................................................... 6 2.3. Auswirkungen der Leitlinie der Europ. Kommission zur PSI-RL ................................. 6

3. Praktische Umsetzung ......................................................................................... 8 3.1. Grundlegende Architektur .......................................................................................... 8 3.2. Verwaltungskonomische Startumsetzung ................................................................. 9

3.2.1. Datenauswahl ..................................................................................................................... 9 3.2.2. Datenmanagement ............................................................................................................. 9 3.2.3. Bestandslisten ..................................................................................................................... 9 3.2.4. Metadatenschnittstelle und API ........................................................................................ 10 3.2.5. Workflow und Portal .......................................................................................................... 12 3.2.6. Datenpool und Formate .................................................................................................... 13 3.2.7. Kennzeichnung von kostenpflichtigen Datenstzen ......................................................... 13

Anhang A: Beispiel fr PSI System- Architektur ................................................. 14 Anhang B: nderungsprotokoll ............................................................................ 15

Seite 3 / 15

upsir-1.0.0 01.07.2015

0. Einleitung

0.1. Allgemeine Information Die Novelle der Richtlinie ber die Weiterverwendung von Informationen des ffentlichen Sektors (Public Sector Information, kurz PSI)1, die innerstaatliche Umsetzung der Richtlinie im Informationsweiterverwendungsgesetz (kurz IWG), dessen Novelle und die sich darauf beziehenden jeweiligen neun Landesgesetze erfordern organisatorische und technische berlegungen zur Umsetzung. Die Europische Kommission hat im Sommer 2014 zustzlich noch Leitlinien2 zur PSI Richtlinie verffentlicht.

Am 28.11.2013 wurde daher rechtzeitig eine BLSG Projektgruppe (UPSIR) mit organisatorischer und technischer Agenda gestartet. Parallel dazu richteten die Bundeslnder eine juristisch besetzte Expertengruppe (Lnderexpertenkonferenz) zur Abklrung der gesetzlichen Fragestellungen ein. Beide Arbeitsgruppen vereinbarten einen intensiven Austausch von Erkenntnissen. Die Frist fr die Umsetzung der PSI-Richtlinie in innerstaatliches Recht endet am 18.07.2015.

0.1.1. Ziele Entwurf einer mglichst sterreichweit einheitlichen PSI Architektur unter

Einbeziehung vorhandener OGD Implementierungen und wahrscheinlicher Auswirkungen auf Grund der geplanten Informationsfreiheit (IFG).

Zusammenarbeit und Abstimmung mit der juristischen Expertengruppe Etablierung einer verbindlichen Schnittstelle fr Metadaten Erstellung eines White Papers zur Untersttzung der Klassifikation von Informationen

im Hinblick auf die Weiterverwendung Vorstellung von mglichen PSI Umsetzungsvarianten.

0.1.2. Nicht-Ziele Juristische Ttigkeiten. Erarbeitung von verbindlichen Vorgaben fr die Detailumsetzung innerhalb der

dezentralen PSI Instanzen (z.B. Bundeslnder).

0.2. Zielgruppe Dieses Dokument richtet sich an Beteiligte von E-Government Projekten, die sich mit der Konzeption und praktischen Umsetzung der Infrastruktur fr die PSI RL in Verbindung mit weiteren Verffentlichungen (wie z.B. INSPIRE, OGD, etc.) unter Einbeziehung einer Folgenabschtzung fr IFG befassen.

0.3. Hinweis zum Dokument Dieses Dokument enthlt eine Zusammenfassung der Ergebnisse der BLSG Arbeitsgruppe UPSIR. Weitere separat dokumentierte Ergebnisse der Arbeitsgruppe sind: Konvention XML Schnittstelle3 und White Paper PSI Klassifizierung.

1 http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2013:175:0001:0008:DE:PDF 2 http://eur-lex.europa.eu/legal-content/DE/TXT/PDF/?uri=CELEX:52014XC0724%2801%29&from=EN 3 http://reference.e-government.gv.at/AG-II-Architektur-XML-Metadat.3270.0.html

http://reference.e-government.gv.at/AG-II-Architektur-XML-Metadat.3270.0.html

Seite 4 / 15

upsir-1.0.0 01.07.2015

1. Rahmenbedingungen

1.1. Umfeldanalyse

1.1.1. Gesetzliche Grundlagen und Leitlinien Richtlinien ber die Weiterverwendung von Informationen des ffentlichen Sektors

(RL 2003/98/EG und RL 2013/37/EU) Leitlinien (Guidelines der EK) fr empfohlene Standardlizenzen, Datenstze und

Gebhren fr die Weiterverwendung von Dokumenten Informationsweiterverwendungsgesetz (IWG), BGBl. I. Nr. 135/2005 samt Novelle4 Neun Landesgesetze zur Umsetzung der PSI Richtlinie Entwurf zur nderung der Bundesverfassung BV-G hinsichtlich Informationsfreiheit

(IFG)

1.1.2. Intention der PSI Richtlinie Die Richtlinie des Europischen Parlaments und des Rate bzw. die Europische Kommission verfolgt mit der Novelle 2013 u.a. folgende Ziele (Auszug aus den Erwgungsgrnden der Richtlinie):

Sicherstellen dass sie den Mitgliedstaaten eine eindeutige Verpflichtung auferlegt, alle Dokumente weiterverwendbar zu machen, es sei denn, der Zugang ist im Rahmen der nationalen Vorschriften ber den Zugang zu Dokumenten eingeschrnkt oder ausgeschlossen [ EG8]

Das Ziel ist die Erleichterung der Erstellung unionsweiter Informationsprodukte und dienste anhand von Dokumenten des ffentlichen Sektors, sowie die Sicherstellung einer effektiven grenzberschreitenden Nutzung von Dokumenten [ EG33]

Zur Erleichterung der Weiterverwendung sollten ffentliche Stellen, soweit mglich und sinnvoll, die Dokumente in offenen, maschinenlesbaren Formaten und zusammen mit den zugehrigen Metadaten in hchstmglicher Przision und Granularitt in einem Format zugnglich machen, das die Interoperabilitt garantiert [ EG20]

1.1.3. Vorhandene Implementierungen Im Rahmen der Open Government Data (OGD) Initiative oder auch anderen Grundlagen (UIG, etc.) wurden in den letzten Jahren von den meisten Bundeslndern auf freiwilliger Basis recht unterschiedliche Implementierungen erstellt. Im internen Bereich der dezentralen Instanzen muss die vorhandene OGD Infrastruktur aufgrund der hnlichen Prozesse meist nur leicht adaptiert werden. Durch die normierte XML Metadatenschnittstelle (siehe auch 3.2.4 Metadatenschnittstelle und API) sind ebenso nur geringfgige Auswirkungen auf etwaige vorhandene Implementierungen in Richtung zentralem Metadatenportal data.gv.at zu erwarten. Ein Aufwand ist allerdings durch die PSI-Mglichkeit Kosten zu verrechnen gegeben. Eventuell knnen dazu auch vorhandene Shops genutzt werden.

4 http://www.parlament.gv.at/PAKT/VHG/XXV/ME/ME_00090/index.shtml

http://data.gv.at/http://www.parlament.gv.at/PAKT/VHG/XXV/ME/ME_00090/index.shtml

Seite 5 / 15

upsir-1.0.0 01.07.2015

1.2. Prinzipien fr die Umsetzung der PSI-Richtlinie Das zugrundeliegende Konzept und die grundlegende Architektur unterliegen folgenden Prmissen:

Kostengnstige und effiziente Umsetzung durch hohen Automatisierungsgrad und Einbeziehung vorhandener Strukturen

Die Datenhoheit (fr Daten und Metadaten) liegt immer beim Dateneigner! Die Datenhaltung (inkl. Metadaten) erfolgt durch den Dateneigner, wobei er sich

eines Dienstleisters bedienen kann. Darstellung (mglichst automatisiert) der Metadaten im eigenen Portal, um allen PSI

Anforderungen zu gengen. Metadaten werden bei Bedarf ber die normierte XML Metadaten-Schnittstelle (BLSG

Konvention) zur Verfgung gestellt. Jeder Nutzer (z.B. data.gv.at, EU, etc.) kann sich die maschinenlesbaren Metadaten

ber die XML Schnittstelle/API abholen.

http://data.gv.at/

Seite 6 / 15

upsir-1.0.0 01.07.2015

2. Vorgaben fr die praktische Umsetzung Die Gesetzesmaterie enthlt eine Reihe von Formulierungen, welche die konkrete Umsetzung einerseits erschweren, aber auch einen Implementierungsspielraum zulassen. Beispielsweise ist eine hufige Diktion soweit mglich und sinnvoll. Verschiedene Anhaltspunkte in den Gesetzen erlauben eine grundlegende Konzeption der praktischen PSI Umsetzung. Dazu wurden auch intensive Gesprche mit den juristischen Experten gefhrt.

2.1. Auswirkungen der innerstaatlichen PSI Umsetzungen Die gesetzliche Umsetzung fr die PSI Richtlinie erfolgt in sterreich als 9 + 1 Realisierung, d.h. neben dem Informationsweiterverwendungsgesetz des Bundes sind neun Landes-gesetze bindend. Der bislang vorliegende Entwurf des IWG bernimmt zum berwiegenden Teil und teilweise wrtlich die Bestimmungen der PSI Richtlinie, woran sich die jeweiligen Landesgesetzgeber ebenfalls orientiert haben. Fr die technisch/organisatorische Umsetzung ist es dabei sehr wichtig, dass sich die einzelnen Gesetze in den fr die Technik wichtigen Aspekten kaum unterscheiden. Die gefundenen Anhaltspunkte (Hinweis: diese stellen keine juristische Auslegung dar) knnen daher fr alle dezentralen Instanzen gleichartig genutzt werden.

ffentliche Stellen stellen Dokumente (i.S. der PSI RL), soweit mglich und sinnvoll, in einem offenen und maschinenlesbaren Format zusammen mit den zugehrigen Metadaten bereit [sinngem aus Entwurf IWG 6 (1)].

ffentliche Stellen haben praktische Vorkehrungen zur Erleichterung der Suche zu treffen: Bestandslisten der wichtigsten Dokumente, soweit mglich und sinnvoll, online verfgbar (Internet-Portale) in einem maschinenlesbaren Format sowie (wieder soweit mglich) mit einer sprachbergreifenden Suche [sinngem aus Entwurf IWG 9 (4)].

2.2. Mgliche Auswirkungen der B-VG nderung / IFG Die Informationsfreiheit (Verfassungsnderung und zugehrige Einfachgesetze, kurz IFG) ist zum Zeitpunkt der Ttigkeit der Projektgruppe UPSIR noch in einer Entwurfsphase. Um mit der Konzeption der UPSIR Architektur in keine Sackgasse fr zuknftige Anforderungen (als Frist fr das IFG wurde der 1.1.2016 genannt) zu laufen, wurde versucht die Auswirkungen abzuschtzen und in das Konzept miteinzubeziehen.

Verpflichtung zur Verffentlichung von Informationen von allgemeinem Interesse. Information ist jede amtlichen bzw. unternehmerischen Zwecken dienende Aufzeichnung unabhngig von der Art ihrer Speicherung [sinngem aus Entwurf B-VG nderung, Art 22a und Erluterungen].

Die Informationen von allgemeinem Interesse sind in einer fr jedermann zugnglichen Art und Weise und zwar bereits ohne ein konkretes Ansuchen zu verffentlichen, entsprechend dem Grundsatz des Open Government [sinngem aus Entwurf B-VG nderung, Art 22a und Erluterungen].

2.3. Auswirkungen der Leitlinie der Europ. Kommission zur PSI-RL Fnf thematische Datenkategorien sind von der EK als diejenigen eingestuft worden, denen Vorrang bei der Bereitstellung eingerumt werden sollte [sinngem nach PSI Leitlinien 2014, 3.1 Datenkategorien]:

Geodaten Umweltdaten

Seite 7 / 15

upsir-1.0.0 01.07.2015

Verkehrsdaten Statistikdaten Unternehmensdaten

Zustzlich dazu sind weitere Empfehlungen angefhrt:

Um die Nutzung von Daten des ffentlichen Sektors zu erleichtern wird empfohlen, die Datenstze online

o in hchstmglicher Przision und Granularitt zu verffentlichen o auf hchster Ebene der Verwaltungsstruktur zu verffentlichen o maschinenlesbar und in offenen Formaten zu verffentlichen o klassifiziert nach Standardvokabularen, Metadaten, Suchfunktion zu

verffentlichen o sowohl als Massendaten als auch per Programmierschnittstellen (API)

anzubieten o mit Erluterungen zu den Metadaten und standardisierten Glossaren zu

versehen o von den Weiterverwendern regelmig bewerten zu lassen; Beteiligung der

ffentlichkeit

[sinngem nach PSI Leilinien 2014, 3.2 Weitere Empfehlungen]

Seite 8 / 15

upsir-1.0.0 01.07.2015

3. Praktische Umsetzung

3.1. Grundlegende Architektur Auf Grund der unterschiedlichen IT-Umfelder der Bundeslnder (dezentrale PSI Instanzen) wird in UPSIR keine Detailarchitektur fr die PSI Umsetzung innerhalb der dezentralen Instanzen festgelegt. Ebenso gibt es keine verbindliche Festlegung der Werkzeuge, wie etwa Workflow-Komponenten oder Datenbanken. Eine mgliche Systemarchitektur ist beispielhaft im Anhang A angefhrt. Groes Augenmerk wird jedoch auf die Normierung der Metadatenschnittstelle gelegt. ber diese Schnittstelle kann unter anderem das nationale Metadatenportal die Metadaten der dezentralen Instanzen sammeln (harvesten). Wenn in den Instanzen neben PSI auch andere Metadaten (z.B. INSPIRE Metadaten) verarbeitet werden, dann ist es sinnvoll die XML Struktur der Schnittstelle auch innerhalb der Instanzen einzusetzen. In Bezug auf die Metadaten ist die UPSIR Architektur ein verteiltes System mit Multikanalzugang fr den Nutzer. Mittels UPSIR Architektur ist ein mehrstufiges System bis auf Europische Ebene aufzubauen. Die Daten selbst liegen jedoch immer beim Dateneigener oder (etwa bei kleineren ffentlichen Stellen) bei einem beauftragten Dienstleister.

Abbildung 1 Verteiltes System der Metadaten (UPSIR Architektur)

Seite 9 / 15

upsir-1.0.0 01.07.2015

3.2. Verwaltungskonomische Startumsetzung Aus heutiger Sicht ist kaum abschtzbar, wie viele und welche Informationen bzw. Dokumente i.S. der PSI RL zur Weiterverwendung in der ersten Zeit nach Frist 18.7.2015 abgefragt werden. Unter Bedachtnahme auf einen mavollen Mitteleinsatz wurde daher versucht eine zweckmige und ausbaufhige Startumsetzung zu konzipieren.

3.2.1. Datenauswahl Fr eine Startumsetzung sind zumindest vorzusehen:

Einbeziehung der vorhandenen OGD Datenstze Weitere Datenstze aus den fnf Kategorien der Leitlinien Informationen von allgemeinem Interesse aus den jeweiligen (z.B. Landes-) Web-

Sites u.a. Quellen.

Anmerkung: Die Kriterien fr die Unterscheidung zwischen (bislang freiwillig publizierten) OGD-Daten und PSI-Daten sind Lizenzen und eine eventuelle Kostenverrechnung. Alle Metadaten - gleich unter welchem Gesichtspunkt (PSI, IFG, OGD) sie verffentlicht werden haben gleichartige Metadatenstze und werden ber die XML Schnittstelle zur Verfgung gestellt.

3.2.2. Datenmanagement Unabhngig von der konkreten Implementierung, sind jedenfalls alle oder einzelne der folgenden Ttigkeiten erforderlich:

Klassifizierung und Bewertung5 Metadatenerstellung (nach BLSG Konvention XML Metadaten) Automatische Metadatenbernahme aus vorhandenen Systemen ber XML

Metadatenschnittstelle Teilweise bernahme der Metadateninformation in die PSI Portale der dezentralen

Instanzen Eventuelle Konvertierung der Daten (offene Formate, maschinenlesbar) Zur Verfgung stellen der Daten im jeweiligen Datenpool Freischaltung (damit weltweite Sichtbarkeit) durch Dateneigner Metadaten maschinenlesbar ber XML Metadatenschnittstelle bereitstellen (

https://www.data.gv.at/)

3.2.3. Bestandslisten Nach der PSI Richtlinie sind praktische Vorkehrungen zu treffen, die eine Suche nach den zur Weiterverwendung verfgbaren Dokumenten erleichtern. Neben den kompletten Metadatenstzen ist das die Darstellung einer Bestandsliste zur bersicht.

Die Auflistung aller Metadaten-Titel (hinterlegt mit Link auf Metadatensatz) inclusive Metadaten-Beschreibung ergibt eine Bestandsliste einer dezentralen Instanz

Die XML Metadatenschnittstelle erlaubt es einer zentralen Instanz (= nationales Portal data.gv.at), die Metadaten aller dezentralen Instanzen sterreichweit zu sammeln und aufzubereiten

Sinnvollerweise ist dieses nationale Metadaten-Portal eine gemeinsame Plattform fr PSI/IWG, IFG, OGD und u.U. auch UIG, usw.

Auf data.gv.at befindet sich dann die sterreichische PSI Bestandsliste

5 White Paper PSI Klassifikation 1.0.0

https://www.data.gv.at/http://data.gv.at/http://data.gv.at/

Seite 10 / 15

upsir-1.0.0 01.07.2015

Eventuelle Einrichtung von nutzerfreundlichen Suchfunktionen (9 IWG) zur sterreichischen Bestandsliste

3.2.4. Metadatenschnittstelle und API Eine nhere Beschreibung der Metadaten-Schnittstelle (inkl. XML Schema) ist auf dem E-Government Referenzserver abgelegt: http://reference.e-government.gv.at/AG-II-Architektur-XML-Metadat.3270.0.html

Diese Schnittstelle fr Metadaten wurde als BLSG Konvention verabschiedet und ist damit fr die bertragung von Metadaten bindend einzusetzen. Sinnvollerweise wird diese Schnittstelle nicht nur fr PSI, sondern auch fr zuknftige Metadaten nach IFG und fr OGD sowie mglicherweise auch noch fr weitere Verffentlichungen (z. B. UIG, ) genutzt.

Das nationale Portal data.gv.at holt sich ber diese XML Schnittstelle per API die Metadaten der dezentralen Instanzen ab. Die maschinenlesbaren Metadaten sind ber die API jedoch auch allgemein zugnglich.

Abbildung 2 UPSIR XML Metadatenschnittstelle

XML-Import/Export Schnittstelle (Metadaten-API) Die Umsetzung der Metadaten-API erfolgt analog zu den bisher schon von einigen Bundeslndern im OGD Bereich genutzten JSON-Harvestern. Zustzlich wird auch eine mgliche Depublizierung von Datenstzen auf data.gv.at untersttzt.

Die von data.gv.at angeforderten Daten werden vom datenbereitstellenden Portal (dezentrale Instanz) per XML in UTF8 angeboten und in data.gv.at importiert.

http://reference.e-government.gv.at/AG-II-Architektur-XML-Metadat.3270.0.htmlhttp://reference.e-government.gv.at/AG-II-Architektur-XML-Metadat.3270.0.htmlhttp://data.gv.at/http://data.gv.at/http://data.gv.at/http://data.gv.at/

Seite 11 / 15

upsir-1.0.0 01.07.2015

a) Aufbau des XML Response

Das root Element lautet und enthlt ein oder mehrere Kind-Elemente mit der Bezeichnung . Das Kind-Element spezifiziert die eindeutige ID eines publizierten Datensatzes (metadata_identifier).

Das Kind-Element enthlt das Attribut state. Es kann die Werte new, active und deleted annehmen.

new - ein hervorzuhebender Datensatz active - ein nicht hervorzuhebender (normaler) Datensatz deleted - verffentlichter Datensatz ist ungltig und soll von der Bestandsliste entfernt

werden

Die Ausprgungen new und active sind dabei nicht als technische Kriterien anzusehen. new dient dazu, um nach freien weichen Kriterien einen Datensatz in der Darstellung hervorheben zu knnen, sofern diese Ausprgung durch den abfragenden Metadatennutzer auch verwertet werden kann. new kann vom jeweiligen Datenlieferanten wahlweise automatisiert (zB Erstellungsdatum liegt zwischen der since_time und dem aktuellen Zeitpunkt) oder mittels manueller Selektion gesetzt werden.

Die Ausprgung deleted ist nur bei der Abfragemethode Deltasync zulssig.

Beispiel:

xyz-D3A6C0803D614A68AF45D1A809BC9EC9 xyz-E108DCC3130440768619F2185C37EF81 xyz-E8D2E799E4954929BBFA53672778F025

Anschlieend werden die einzelnen Datenstze einzeln von data.gv.at abgerufen und importiert.

Beispiel: http://data.xyz.gv.at/api/dataset/xyz-01229A8634394E5E93B076A0CC759088

b) Abfragemethoden

Fr den Datenabgleich gibt es die zwei Methoden Fullsync und Deltasync:

1. Abfragemethode Fullsync

Das datenbereitstellende Portal (dezentrale Instanz) liefert immer eine vollstndige Liste aller gltigen, zurzeit publizierbaren Datenstze. Datenstze die nicht in dieser Liste aufscheinen, sind aus dem zentralen Portal data.gv.at zu entfernen.

Abfrage aller Datenstze am datenbereitstellenden Portal Import neuer Datenstze Lschung von Datenstzen die auf data.gv.at publiziert sind, aber nicht in

der Liste aufscheinen

2. Abfragemethode Deltasync Fr den Import ruft data.gv.at die URL fr die Abfrage der Liste mit dem URL Parameter (GET) auf. Beim Parameter since_time= wird als Wert ein Timestamp im

http://data.gv.at/http://data.xyz.gv.at/api/dataset/xyz-01229A8634394E5E93B076A0CC759088http://data.gv.at/http://data.gv.at/http://data.gv.at/

Seite 12 / 15

upsir-1.0.0 01.07.2015

ISO-Format vergeben. Als Rckantwort wird eine Liste von eindeutigen IDs der Datenstze, die seit dem Wert since_time gendert, neu angelegt oder gelscht worden sind geliefert.

Beispiel:

xyz-D3A6C0803D614A68AF45D1A809BC9EC9 xyz-E108DCC3130440768619F2185C37EF81 xyz-E8D2E799E4954929BBFA53672778F025

Die vollstndige Implementierung der XML-Schnittelle (nach metadaten-md 1.0.0) und der API erlaubt es allen Nutzern (insbesondere data.gv.at) automatisch und maschinenlesbar den Abgleich (Akkumulation) der Metadaten der dezentralen Instanzen durchzufhren.

Innerhalb der dezentralen Instanzen kann die gleiche normierte XML-Struktur zur strukturierten Speicherung von Metadaten dienen, um eine redundante Eingabe in den verschiedenen Backoffice Systemen mglichst hintanzuhalten und einen hohen Automatisierungsgrad zu ermglichen.

3.2.5. Workflow und Portal Insbesondere in greren dezentralen Instanzen werden die Daten dezentral in Fachbereichen liegen. Um das Datenmanagement bewltigen zu knnen, kann eine Workflow-Steuerung (von Datenbewertung bis Freischaltung) sinnvoll sein. Eine konkrete Implementierung ist in UPSIR jedoch nicht vorgesehen bzw. normiert.

Abbildung 3 Interner Workflow

Nicht zuletzt aus Kostengrnden wird das PSI-Portal (= Website der dezentralen Instanz) ein Bestandteil der allgemeinen (Landes-)Website sein. Ein vorhandenes OGD-Portal

http://data.gv.at/

Seite 13 / 15

upsir-1.0.0 01.07.2015

(http://data.xyz.gv.at) wird adaptiert. Laut Leitlinien sollte dieses PSI-Portal auf hchster Ebene der (Landes-)Website sichtbar sein. Eine vorhandene OGD-Terminologie ist an PSI anzupassen (z.B. OGD Datenkatalog = Bestandsliste nach PSI/IWG), eine Erluterung bezglich PSI-IWG/IFG ist hinzuzufgen.

3.2.6. Datenpool und Formate Die eigentlichen Daten sollten in geeigneten offenen Formaten in Form von Dateien vorliegen. In den PSI Leitlinien der EK sind als Beispiele fr offene Formate CSV, JSON, XML, RFD angefhrt. Weitere Formatempfehlungen6 lassen sich aus dem OGD-Bereich ableiten u.a. auch fr PDF unter bestimmten Umstnden.

Hinweis: In UPSIR und insbesondere fr die Startumsetzung wurde das Anbieten von Diensten nicht nher spezifiziert, da zum Zeitpunkt der UPSIR die Frage der Datenqualitt und der notwendigen Infrastruktur-Performance noch nicht geklrt ist. Dienste werden insbesondere im Geodaten-Bereich eine Rolle spielen.

Grundstzlich sind die Dateien im Datenpool (und auch Dienste) in den Metadaten verlinkt. Im resource-Element (siehe XML Metadatenschema Schema) sind dafr die notwendigen Felder bereitgestellt. In den Instanzen ist dafr Sorge zu tragen, dass die Daten im Datenpool im Internet ffentlich zugnglich sind (Webserver und/oder FTP Server). Die interne Bedienung des Datenpools ist nicht spezifiziert. Falls eine Workflow-Untersttzung abgebildet wird, kann diese auch das Laden der Daten-Files in den Pool beinhalten. Auch eine zyklische automatische Aktualisierung des Datenpools kann erforderlich sein (Beispiel Luftgtedaten).

3.2.7. Kennzeichnung von kostenpflichtigen Datenstzen Die Unterscheidung zwischen PSI und OGD Datenstzen wird im Container Element terms durch den Lizenzeintrag (license-Element) erkennbar (OGD Datenstze haben immer die Lizenzform CC by x.x AT), PSI Datenstze knnen beliebige Lizenzen verwenden). Zustzlich wird fr kostenpflichtige Datenstze (nach PSI mglich, nach OGD nicht) die Verwendung eines normierten Linkeintrages http://data.[xyz].gv.at/entgelt/ im metadata_linkage-Element notwendig. Unter diesem URL ist eine Seite mit den Kosten zu erreichen.

6 OGD Metadaten 2.3, Seite 28 http://reference.e-government.gv.at/uploads/media/OGD-Metadaten_2_3_2015_02_19.pdf

http://data.noe.gv.at/http://data.noe.gv.at/http://data.[xyz].gv.at/entgelt/http://reference.e-government.gv.at/uploads/media/OGD-Metadaten_2_3_2015_02_19.pdf

Seite 14 / 15

upsir-1.0.0 01.07.2015

Anhang A: Beispiel fr PSI System- Architektur

Umsetzung Steiermark

Seite 15 / 15

upsir-1.0.0 01.07.2015

Anhang B: nderungsprotokoll

Version 1.0.0 Datum: 01.07.2015

0. Einleitung0.1. Allgemeine Information0.1.1. Ziele0.1.2. Nicht-Ziele0.2. Zielgruppe0.3. Hinweis zum Dokument1. Rahmenbedingungen1.1. Umfeldanalyse1.1.1. Gesetzliche Grundlagen und Leitlinien1.1.2. Intention der PSI Richtlinie1.1.3. Vorhandene Implementierungen1.2. Prinzipien fr die Umsetzung der PSI-Richtlinie2. Vorgaben fr die praktische Umsetzung2.1. Auswirkungen der innerstaatlichen PSI Umsetzungen2.2. Mgliche Auswirkungen der B-VG nderung / IFG2.3. Auswirkungen der Leitlinie der Europ. Kommission zur PSI-RL3. Praktische Umsetzung3.1. Grundlegende Architektur3.2. Verwaltungskonomische Startumsetzung3.2.1. Datenauswahl3.2.2. Datenmanagement3.2.3. Bestandslisten3.2.4. Metadatenschnittstelle und API3.2.5. Workflow und Portal3.2.6. Datenpool und Formate3.2.7. Kennzeichnung von kostenpflichtigen DatenstzenAnhang A: Beispiel fr PSI System- ArchitekturAnhang B: nderungsprotokoll