Open Data Handleiding 2.0

Open Data Handleiding 2.0 Praktijkgerichte handleiding voor de publicatie en het beheer van Open Data mbv het Vlaams Open Data Platform

Contactpersoon: Noël Van Herreweghe Programma-manager Open Data bij de Vlaamse overheid

http://www.vlaanderen.be/opendata [email protected] Skype: opendataforum_ LinkedIn: Open Data Group

1

Voorwoord In december 2010 organiseerde Geert Bourgeois, Vlaams minister van Bestuurszaken, de ViA rondetafel i-Vlaanderen over open overheid en ICT. Een van de belangrijkste conclusies was dat de deelnemers zeer sterk vragende partij waren om meer overheidsdata open te maken. Open Data zijn gegevens of informatie die door de overheid verzameld wordt in het kader van haar openbare taak, waar geen of minimale beperkingen op rusten, die elektronisch beschikbaar zijn en gebruik maken van open standaarden. Op 13 juni 2013 werd de nieuwe richtlijn met betrekking tot hergebruik van overheidsinformatie door het Europees Parlement goedgekeurd. De nieuwe richtlijn vergemakkelijkt het openstellen van overheidsdata en benadrukt dat overheidsinformatie kan bijdragen aan de economische groei en het scheppen van werkgelegenheid in de lidstaten van de Europese Unie.

Ook bij de Vlaamse overheid is Open Data de norm. De Vlaamse overheid heeft inderdaad een schat aan informatie op uiteenlopende terreinen, die openbaar is, maar waarvoor hergebruik niet is toegestaan. Hergebruik houdt in dat de data voor niet-commerciële zowel als commerciële doeleinden kunnen gebruikt worden, gratis of tegen een billijke vergoeding. Bij hergebruik moet u denken aan het gebruik van de data in toepassingen voor smartphones (Apps), websites, onderzoek, enz. Deze vormen van hergebruik zijn er nu ook al, maar kunnen een enorme impuls krijgen wanneer overheidsinformatie vrijelijk als Open Data ter beschikking komt. Het ontsluiten van informatie als Open Data is echter een activiteit die allerlei vragen met zich meebrengt, bijvoorbeeld over auteursrecht, intellectuele eigendom en aansprakelijkheid. Voorlichting, overleg en communicatie zijn daarom erg belangrijk. Een eerste stap in de juiste richting was het opzetten van het Open Data Forum. Dit forum is enerzijds een kennisplatform en geeft tegelijkertijd toegang tot het Open Data Portaal van de Vlaamse overheid (http://www.vlaanderen.be/opendata). Het Kennisplatform wil het delen van kennis en best practices rond Open Data tussen partners binnen en buiten de Vlaamse overheid stimuleren. Deze handleiding is een praktische gids waar u de belangrijkste achtergrondinformatie vindt over Open Data, samen met enkele richtlijnen voor het effectief ter beschikking stellen van Open Data.

Noël Van Herreweghe, programma-manager Open Data bij de Vlaamse overheid

2

Inhoudsopgave 1/ Algemeen ...................................................................................................................................................................................................................................................... 6 1.1/ Open Data .................................................................................................................................................................................................................................... 6 1.2/ Waarom een handleiding? ................................................................................................................................................................................................. 6 1.3/ Beleid en regelgeving ............................................................................................................................................................................................................ 6 1.4/ Het Vlaams Open Data Forum en het Vlaams Open Data Platform ......................................................................................................... 7 2/ Selecteer uw dataset(s) ....................................................................................................................................................................................................................... 8 2.1/ Algemene richtlijnen ............................................................................................................................................................................................................. 8 2.2/ Voorafgaande juridische toetsing ................................................................................................................................................................................ 8 2.2.1/ Intellectuele eigendomsrechten ..................................................................................................................................................................... 8 2.2.2/ Uitzonderingen op de openbaarheid van bestuur ........................................................................................................................... 9 2.2.3/ Bescherming van persoonsgegevens ......................................................................................................................................................... 10 2.3/ Criteria en prioriteiten ....................................................................................................................................................................................................... 10 2.3.1/ Wettelijke vereisten .............................................................................................................................................................................................. 11 2.3.2/ Eerder gepubliceerde gegevens ..................................................................................................................................................................... 11 2.3.3/ Waarde van de gegevens .................................................................................................................................................................................. 11 2.3.4/ Bereik van de gegevens ..................................................................................................................................................................................... 12 2.3.5/ Prioriteiten ............................................................................................................................................................................................................... 12 3/ Kies een modellicentie ......................................................................................................................................................................................................................... 14 3.1/ Voorafgaande beslissing omtrent vergoedingen .................................................................................................................................................. 14 3.2/ Voorafgaande beslissing omtrent de mogelijke categorieën van gebruik ............................................................................................ 14 3.3/ Keuze van een modellicentie ........................................................................................................................................................................................... 15 4/ Ontsluit uw brongegevens ................................................................................................................................................................................................................ 16 4.1/ Achterliggende gedachte: gebruik van ETL technieken .................................................................................................................................... 16 4.2/ Scenario’s voor het ontsluiten van brongegevens .............................................................................................................................................. 17 4.2.1/ Scenario 1: vertrekken van een bestaande publicatie ...................................................................................................................... 18 4.2.2/ Scenario 2: Vertrekken van een bestaande dataset .......................................................................................................................... 20 4.2.3/ Scenario 3: vertrekken van een database ............................................................................................................................................... 21 4.2.4/ Scenario 4: vertrekken van een bestaand bronsysteem ................................................................................................................. 23 4.2.5/ Scenario 5: Vertrekken van verschillende bronsystemen .............................................................................................................. 25

3

5/ Kies een open formaat ........................................................................................................................................................................................................................ 27 5.1/ Minimale vereisten ................................................................................................................................................................................................................. 27 5.1.1/ Kwaliteit ....................................................................................................................................................................................................................... 27 5.1.2/ Consistentie ............................................................................................................................................................................................................... 27 5.2/ Open formaten ........................................................................................................................................................................................................................ 28 5.3/ Standaarden .............................................................................................................................................................................................................................. 29 5.4/ Linked Open Data .................................................................................................................................................................................................................. 29 5.5/ API ................................................................................................................................................................................................................................................. 30 5.6/ Maturiteitsmodel voor Open Data ............................................................................................................................................................................ 30 6/ Publiceer uw dataset(s) ...................................................................................................................................................................................................................... 31 6.1/ Voorafgaande technische toetsing ............................................................................................................................................................................... 31 6.2/ Via eigen website (datadump of API) of upload naar CKAN ........................................................................................................................ 31 7/ Documenteer uw dataset(s) ............................................................................................................................................................................................................. 32 7.1/ ‘Open Data’ contactpunt .................................................................................................................................................................................................... 32 7.2/ Contactadres voor informatie en feedback ............................................................................................................................................................ 32 7.3/ Gebruiksvoorwaarden ......................................................................................................................................................................................................... 33 7.4/ Vergoedingen ............................................................................................................................................................................................................................ 33 7.5/ Garanties betreffende de beschikbaarheid ............................................................................................................................................................. 34 7.6/ Bijsluiter ...................................................................................................................................................................................................................................... 34 7.6.1/ De data zelf ............................................................................................................................................................................................................... 35 7.6.2/ Het proces ................................................................................................................................................................................................................. 35 7.7/ Taal van de website .............................................................................................................................................................................................................. 35 8/ Maak uw dataset(s) vindbaar .......................................................................................................................................................................................................... 36 8.1/ Metadata ...................................................................................................................................................................................................................................... 36 8.1.1/ Wat is metadata? ................................................................................................................................................................................................... 36 8.1.2/ Hoe metadata opmaken .................................................................................................................................................................................... 36 8.1.3/ Metadata overzicht ............................................................................................................................................................................................... 37 8.2/ Metadata toevoegen in CKAN ......................................................................................................................................................................................... 39 8.2.1/ Account aanmaken .............................................................................................................................................................................................. 40 8.2.2/ Dataset creëren ..................................................................................................................................................................................................... 40 8.2.3/ Metadata toevoegen via de CKAN API ...................................................................................................................................................... 45 9/ Evalueer uw Open Data praktijk ................................................................................................................................................................................................... 46

4

Bijlage 1: Master Data Management .................................................................................................................................................................................................... 47 Bijlage 2: Technische standaarden ....................................................................................................................................................................................................... 51 Vlaams Open Data Platform (CKAN) ..................................................................................................................................................................................... 51 The Data Tank .................................................................................................................................................................................................................................... 51 Vlaamse overheid Bedrijfsinformatieplatform (VOBIP) ............................................................................................................................................. 51 Programma Bedrijfsinformatie Vlaamse overheid (BIVO) .....................................................................................................................................

51

Bijlage 3: Toevoegen van metadata via de CKAN API ............................................................................................................................................................... 53 Woordenlijst ..................................................................................................................................................................................................................................................... 57

5

Open Data Handleiding 2.0

1

ALGEMEEN

1.1 OPEN DATA Open (Government) Data zijn gegevens of informatie die door de overheid verzameld worden in het kader van haar openbare taak, waar geen of minimale beperkingen op rusten, die elektronisch beschikbaar zijn en gebruik maken van open standaarden. Open Data zorgt voor grotere transparantie over de werking van de overheid, zorgt voor meer efficiëntie binnen en buiten de overheid en leidt tot innovatief hergebruik van overheidsdata door burgers, bedrijven en organisaties. Open Data stimuleert ook ondernemerschap, geeft aanleiding tot het ontwikkelen van innovatieve producten en diensten, biedt op het vlak van management, planning en wetenschap instrumenten voor alternatieve besluitvorming en draagt bij tot het ontwikkelen van een Vlaamse kenniseconomie. Open Data creëert ook meerwaarde voor de overheid zelf, zoals een betere publieke dienstverlening, administratieve lastenverlaging en een verhoogde interactie en samenwerking met burgers, bedrijven en organisaties. Het centraal aanbieden van Open Data zal ook aanleiding geven tot efficiëntiewinsten voor de overheidsinstanties zelf en bijdragen tot een verhoging van de datakwaliteit.

1.2 WAAROM EEN HANDLEIDING? Inhoudelijk wil deze handleiding richtinggevend zijn voor iedereen die gegevens wil ontsluiten als Open Data, en dus behoefte heeft aan een stappenplan dat kan dienen als leidraad voor het introduceren en vormgeven van een Open Data strategie binnen hun organisatie, vanaf het selecteren van gegevens tot een gerealiseerde Open Data stroom, vanaf de bron tot en met de publicatie van Open Data op het Open Data Platform. Het document is echter niet exhaustief. Aangepaste versies zullen aangekondigd worden op het Open Data Forum (www.vlaanderen.be/opendata). Dit Kennisplatform wil het delen van kennis en “best practices” rond Open Data tussen partners binnen en buiten de Vlaamse overheid stimuleren. Op het forum zijn onder meer blogs, nieuws, evenementen en interessante links te vinden. De menuknop “Data” op dit forum geeft toegang tot het Vlaams Open Data Portaal. Dit portaal geeft op zijn beurt toegang tot een groot aantal datasets die als Open Data beschikbaar zijn voor hergebruik, ook voor commerciële doeleinden, gratis of tegen een billijke vergoeding. De inhoud van de handleiding bij de modellicenties voor Open Data (goedgekeurd door het CAG op 12 december 2013, zie http://www.bestuurszaken.be/modellicenties-bij-het-aanbieden-van-open-data) is verwerkt en waar relevant opgenomen in deze handleiding.

1.3 BELEID EN REGELGEVING De Vlaamse Regering keurde op 23 september 2011 de conceptnota met betrekking tot Open Data goed (http://www.bestuurszaken.be/conceptnota). Deze nota schetst de beleidscontext en het regelgevend kader voor Open Data in Vlaanderen en bevat een visie en strategische krachtlijnen om met Open Data aan de slag te gaan. De 6 strategische krachtlijnen zoals geformuleerd door de conceptnota zijn de volgende: 1/Open Data wordt de norm binnen de Vlaamse overheid Open Data moet de norm worden, gesloten data kan enkel mits expliciete verantwoording; 2/Hergebruik van Open Data is toegestaan Hergebruik van Open Data is toegestaan, ook voor commerciële doeleinden, gratis of tegen een billijke vergoeding. Open Data maakt hierbij gebruik van eenvoudige, gestandaardiseerde licentiemodellen; 3/Open Data maakt gebruik van open standaarden Open Data is niet echt open indien geen gebruik wordt gemaakt van open standaarden. Open Data maakt gebruik van open formaten en open interfaces; 4/Open Data uit authentieke gegevensbronnen waar het kan De uitbouw van Vlaamse authentieke gegevensbronnen zal aanleiding geven tot betrouwbare en kwaliteitsvolle overheidsdata;

1/ Algemeen

6


5/Open Data volgens een integrale benadering Ook de lokale overheden in Vlaanderen zijn belangrijke leveranciers van data. Bovendien mag de link met het federale niveau niet vergeten worden. Samenwerking over de bestuurslagen heen biedt een sterke meerwaarde; 6/VO-bedrijfsinformatie in een centraal repertorium Datasets uit deze gegevens over de Vlaamse overheid kunnen na een concrete beslissing van de Vlaamse Regering als Open Data ter beschikking gesteld. De conceptnota is de aanleiding tot een Vlaams actieplan Open Data (goedgekeurd door de Vlaamse Regering op 19 juli 2013, zie http://www. bestuurszaken.be/vlaams-actieplan-open-data) en omvat een aantal concrete acties op basis waarvan Open Data binnen de Vlaamse overheid wordt aangepakt. Doelstelling van het actieplan is het realiseren van het Vlaamse Open Data beleid, voortbouwend op de strategische krachtlijnen uit de conceptnota en met een aantal aandachtspunten: de meerwaarde voor de overheid zelf, de economisch-maatschappelijke meerwaarde en de interactie met andere projecten en organisaties. Bij het ontsluiten van gegevens voor hergebruik door derden moeten de entiteiten bij de Vlaamse overheid rekening houden met bestaande regelgeving zoals: het Decreet Openbaarheid van bestuur; Het Decreet Hergebruik van overheidsinformatie; De Auteurswet en de Wet betreffende de rechtsbescherming van databanken; De Wet tot bescherming van de persoonlijke levenssfeer ten opzichte van de verwerking van persoonsgegevens (privacywet). Op 13 juni 2013 werd de nieuwe richtlijn met betrekking tot hergebruik van overheidsinformatie door het Europees Parlement goedgekeurd. Volgens de nieuwe richtlijnen moet data waar geen of minimale beperkingen in verband met privacy, beveiliging, patenten, copyright, tijdslimieten of andere op rusten de norm worden binnen de lidstaten van de Europese Unie. Naar aanleiding van deze herziene richtlijn zal het zal het wettelijk kader voor Open Data in de loop van 2014 worden aangepast.

1.4 HET VLAAMS OPEN DATA FORUM EN HET VLAAMS OPEN DATA PLATFORM Het Open Data Forum (http://www.vlaanderen.be/opendata) is in eerste instantie een kennisplatform. Het is een forum om kennis en “Best Practices” rond Open Data te delen tussen overheidsinstanties en belanghebbenden binnen en buiten de Vlaamse overheid. Op het forum zijn onder meer het laatste nieuws, blogs, aankondiging van evenementen en interessante links met betrekking tot Open Data te vinden. De menuknop “Data” (actief februari 2014) op dit forum geeft toegang tot het Vlaams Open Data Platform. Dit platform geeft toegang tot een groot aantal datasets die beschikbaar zijn voor hergebruik. Op vandaag (december 2013) zijn er meer dan 1.100 datasets als Open Data beschikbaar. De Vlaamse overheid maakte hiervoor gebruik van de CKAN software, een open source tool die wereldwijd door verschillende overheden gebruikt wordt. Begin 2014 wordt dit portaal geïntegreerd met de DATATANK, een Open Data beheersysteem dat de functionaliteiten van het Vlaams Open Data Platform fors zal uitbreiden.

1/ Algemeen

7


2

SELECTEER UW DATASET(S)

Een van de opmerkingen is vaak dat men niet goed weet welke datasets er (eerst) moeten ontsloten worden en in welke volgorde. In dit hoofdstuk geven we een aantal tips om deze selectie vanuit jullie standpunt te helpen maken.

2.1 ALGEMENE RICHTLIJNEN Hoe begin je nu aan Open Data? Het Open Data Handboek van OKFN, de Open Knowledge Foundation ( http://opendatahandbook.org/ nl_BE/), kan richtinggevend zijn in dit verband. Er zijn vier belangrijke stappen bij het openmaken van data. 1/Kies uw dataset(s). Kies de dataset(s) die u als open data beschikbaar wil maken; 2/Pas een open licentie toe. Bepaal welke intellectuele eigendomsrechten eventueel van toepassing zijn. Pas een geschikte ‘open’ licentie toe die de nodige rechten gunt en die de definitie van openheid ondersteunt. De Vlaamse overheid heeft generieke Open Data licenties gedefinieerd. (http://www.bestuurszaken.be/modellicenties-bij-het-aanbieden-van-open-data); 3/Maak de gegevens beschikbaar. In bulk en in een handig formaat. U kunt ook bijkomende manieren overwegen om gegevens beschikbaar te maken, met een API bijvoorbeeld. Het gebruik van een API is aangewezen wanneer in twee richtingen en / of real-time gecommuniceerd moet worden, de API wordt dan aangeboden op de Open Data set; 4/Maak de gegevens vindbaar. Publiceer een verwijzing naar de dataset of de dataset zelf op het Vlaams Open Data Platform. Vanuit een beleidsmatige focus kan er gebruik gemaakt worden van het volgende stappenplan: 1/Creëer een draagvlak. Overtuig het management, leg de beleidsbeslissing vast en verwerk Open Data in het informatiebeleidsplan; 2/Analyseer. Overtuig de medewerkers en onderzoek en beschrijf de mogelijkheden. Houd rekening met de juridische implicaties; 3/Test. Zet een pilot op; 4/Borg. Communiceer uw ervaringen; 5/Evalueer het proces en pas, wanneer nodig, het proces aan.

2.2 VOORAFGAANDE JURIDISCHE TOETSING Vooraleer de data open te stellen voor het publiek, moet de instantie nagaan of er geen juridische belemmeringen zijn voor deze openstelling. Hierbij moet in eerste instantie gedacht worden aan drie categorieën van belemmeringen: de intellectuele eigendomsrechten, de regels betreffende de verwerking van persoonsgegevens, en de mogelijke uitzonderingen op de openbaarheid van bestuur.

2.2.1 INTELLECTUELE EIGENDOMSRECHTEN Wanneer er intellectuele eigendomsrechten rusten op de data die een instantie wil ter beschikking stellen, moet de instantie nagaan of zij de rechthebbende is van die data of op één of andere manier het recht heeft verworven om de data te publiceren. Indien dit niet het geval is, moeten de nodige rechten eerst worden verkregen door middel van een overeenkomst met de rechthebbende. Voor ambtenaren of werknemers kan dit geregeld worden in het statuut of de arbeidsovereenkomst.1 Voor datasets, documenten of ander materiaal dat op bestelling wordt gecreëerd door een private partij voor de instantie, moet de overdracht van de intellectuele eigendomsrechten geregeld zijn in een overeenkomst. Het is dan ook aan te raden dat de instantie in elke overeenkomst met (of overheidsopdracht aan) een derde partij voor het maken van auteursrechtelijk beschermd materiaal een bepaling opneemt waarin de nodige rechten worden verleend aan de instantie om het materiaal als Open Data ter beschikking te stellen. Het kan daarbij

1 Voor de ambtenaren die onder het VPS vallen, is dit al zo. Zie het Besluit van de Vlaamse Regering van 13 januari 2006 houdende vaststelling van de rechtspositie van het personeel van de diensten van de Vlaamse overheid, B.S. 27 maart 2006.

2/ Selecteer uw dataset(s)

8


enerzijds gaan om een volledige overdracht van de rechten, zodat de instantie de rechthebbende wordt. Anderzijds kan er ook voor gekozen worden (bijvoorbeeld omdat de volledige overdracht te duur zou zijn, of omdat de private aannemer het materiaal ook zelf wil gebruiken) om een licentie op het verstrekken van de data te eisen. In het eerste geval kan men stellen dat de instantie ‘eigenaar’ wordt van het materiaal, terwijl in het tweede geval de instantie het recht krijgt om de data te verspreiden, maar de aannemer ‘eigenaar’ blijft.

Aanbeveling 1: Verifieer welke intellectuele eigendomsrechten rusten op de data die u ter beschikking wil stellen. Indien de instantie niet de rechthebbende is van deze intellectuele eigendomsrechten, sluit ze een overeenkomst af met de huidige rechthebbende. Voeg in elke toekomstige overeenkomst of overheidsopdracht met derde partijen voor het creëren van datasets of documenten een bepaling toe waarin de instantie de nodige rechten verkrijgt om de resultaten als Open Data beschikbaar te maken.

2.2.2 UITZONDERINGEN OP DE OPENBAARHEID VAN BESTUUR Ook al is de instantie volledig eigenaar van de data, dit houdt niet automatisch in dat zij deze ter beschikking mag stellen van het publiek. De bescherming van andere rechtmatige belangen kan in sommige gevallen vereisen dat de data niet publiek worden gemaakt. Deze belangen worden opgesomd in het decreet van 26 maart 2004 betreffende de openbaarheid van bestuur. Voor elke dataset waarvan beschikbaarstelling als Open Data wordt overwogen, moet dus eerst worden nagekeken of de uitzonderingen van het openbaarheidsdecreet gelden. In de volgende gevallen mogen de data niet worden beschikbaar gemaakt: 1/Als de openbaarmaking afbreuk doet aan een geheimhoudingsverplichting van de instantie; 2/Als de openbaarmaking afbreuk doet aan de bescherming van de persoonlijke levenssfeer (tenzij de betrokken persoon met de openbaarmaking instemt);2 3/Als de openbaarmaking afbreuk doet aan het geheim van de beraadslagingen van de Vlaamse Regering en de verantwoordelijke overheden die ervan afhangen, de organen van het Vlaams Parlement of van een instantie in Vlaanderen; 4/Als het om bestuursdocumenten gaat die uitsluitend ten behoeve van de strafvordering of de vordering van een administratieve sanctie werden opgesteld; 5/Als het om bestuursdocumenten gaat die uitsluitend ten behoeve van de mogelijke toepassing van tuchtmaatregelen worden opgesteld, zolang de mogelijkheid om een tuchtmaatregel te nemen blijft bestaan; 6/Als het om bestuursdocumenten gaat die informatie bevatten die door een derde werd verstrekt zonder dat hij daartoe verplicht werd en die hij uitdrukkelijk als vertrouwelijk heeft bestempeld (tenzij die persoon met de openbaarmaking instemt); 7/Wanneer het belang van de openbaarmaking niet opweegt tegen een economisch, financieel of commercieel belang van een instantie in Vlaanderen; 8/Wanneer het belang van de openbaarmaking niet opweegt tegen het vertrouwelijk karakter van de internationale betrekkingen van Vlaanderen, of de betrekkingen van Vlaanderen met de supranationale instellingen, met de federale overheid en met andere gemeenschappen en gewesten; 9/Wanneer het belang van de openbaarmaking niet opweegt tegen het vertrouwelijk karakter van commerciële en industriële informatie, wanneer deze informatie beschermd wordt om een gelegitimeerd economisch belang te vrijwaren (tenzij degene van wie de informatie afkomstig is met de openbaarheid instemt); 10/Wanneer het belang van de openbaarmaking niet opweegt tegen de rechtspleging in een burgerlijk of administratief rechtsgeding en de mogelijkheid een eerlijk proces te verkrijgen; 11/Wanneer het belang van de openbaarmaking niet opweegt tegen de vertrouwelijkheid van het handelen van een instantie voor zover die vertrouwelijkheid noodzakelijk is voor de uitoefening van de administratieve handhaving, de uitvoering van een interne audit of de politieke besluitvorming; 12/Wanneer het belang van de openbaarmaking niet opweegt tegen de openbare orde en de veiligheid.

2 Deze uitzondering overlapt gedeeltelijk met de regeling betreffende de verwerking van persoonsgegevens (cf. infra).


9


Voor milieu-informatie gelden een aparte reeks uitzonderingen, die echter vergelijkbaar zijn met de bovenstaande belangen.3

Aanbeveling 2: controleer of met de beschikbaarstelling van de data geen belangen worden geschonden die beschermd worden in het decreet van 26 maart 2004 betreffende de openbaarheid van bestuur.

2.2.3 BESCHERMING VAN PERSOONSGEGEVENS Volgens de conceptnota van de Vlaamse overheid gaat open data over het ter beschikking stellen van niet-persoonsgebonden overheidsgegevens. Voor elke beschikbaar making van bepaalde datasets moet dus worden nagegaan of deze datasets geen persoonsgegevens bevatten. Wanneer dit het geval is, wordt de data in principe niet beschikbaar gemaakt als open data.4 Het begrip ‘persoonsgegevens’ wordt als volgt gedefinieerd: “iedere informatie betreffende een geïdentificeerde of identificeerbare natuurlijke persoon”.5 Een identificeerbaar natuurlijk persoon is op zijn beurt “een persoon die direct of indirect kan worden geïdentificeerd, met name aan de hand van een identificatienummer of van één of meer specifieke elementen die kenmerkend zijn voor zijn of haar fysieke, fysiologische, psychische, economische, culturele of sociale identiteit”.

Aanbeveling 3: controleer voor de data worden beschikbaar gemaakt of zij geen persoonsgegevens bevatten.

2.3 CRITERIA EN PRIORITEITEN Houd tijdens het selectieproces rekening met de volgende parameters wanneer je datasets als Open Data wil publiceren: Wettelijke vereisten: Is er een decretale verplichting om gegevens als Open Data ter beschikking te stellen? Welke juridische belemmeringen kunnen bestaan? Eerder gepubliceerde gegevens: Is de informatie al openlijk beschikbaar of moet deze nog worden opengesteld? Waarde van de gegevens: Zijn de gegevens nuttig voor sociaal engagement en/of hebben ze commerciële waarde? Bereik van de gegevens: Zijn de gegevens bedoeld voor het grote publiek of voor specifieke doelgroepen? Elke parameter, met voorbeelden, wordt hieronder verder behandeld.

3 Zie artikel 15 van het decreet van 26 maart 2004 betreffende de openbaarheid van bestuur: § 1. De in artikel 4 genoemde milieu-instanties wijzen de aanvraag tot openbaarmaking af, voorzover die betrekking heeft op milieu-informatie, indien ze van oordeel zijn dat het belang van de openbaarheid niet opweegt tegen de bescherming van één van de volgende belangen: de bescherming van de persoonlijke levenssfeer, tenzij de betrokken persoon met de openbaarmaking instemt; het geheim van de beraadslagingen van de Vlaamse regering en van de verantwoordelijke overheden die ervan afhangen, het geheim van de beraadslagingen van de organen van het Vlaams Parlement, evenals het bij wet of decreet bepaalde geheim van de beraadslagingen van de organen van de instanties, genoemd in artikel 4, § 1, 3° tot 10°; het vertrouwelijk karakter van bestuursdocumenten die uitsluitend ten behoeve van de strafvordering of de vordering van een administratieve sanctie werden opgesteld; het vertrouwelijk karakter van bestuursdocumenten die uitsluitend ten behoeve van de mogelijke toepassing van tuchtmaatregelen werden opgesteld, zolang de mogelijkheid om een tuchtmaatregel te nemen blijft bestaan; de bescherming van de informatie die door een derde werd verstrekt zonder dat hij daartoe verplicht werd en die hij uitdrukkelijk als vertrouwelijk heeft bestempeld, tenzij die persoon met de openbaarmaking instemt; het vertrouwelijk karakter van de internationale betrekkingen van het Vlaamse Gewest of de Vlaamse Gemeenschap en van de betrekkingen van het Vlaamse Gewest of de Vlaamse Gemeenschap met de supranationale instellingen, met de federale overheid en met andere gemeenschappen en gewesten; het vertrouwelijk karakter van commerciële en industriële informatie, wanneer deze informatie beschermd wordt om een gelegitimeerd economisch belang te vrijwaren, tenzij degene van wie de informatie afkomstig is, met de openbaarheid instemt; de rechtspleging in een burgerlijk of administratief rechtsgeding en de mogelijkheid een eerlijk proces te verkrijgen: de vertrouwelijkheid van het handelen van een milieu-instantie, voor zover die vertrouwelijkheid noodzakelijk is voor de uitoefening van de administratieve handhaving, de uitvoering van een interne audit of de politieke besluitvorming; de openbare orde en veiligheid; de bescherming van het milieu waarop de informatie betrekking heeft. § 2. Voor zover de verzochte informatie betrekking heeft op emissies in het milieu, zijn de in § 1, 1°, 2°, 5°, 7°, 9° en 11°, genoemde uitzonderingsgronden niet van toepassing. Voor de in § 1, 3°, 4°, 6°, 8° en 10°, genoemde uitzonderingsgronden wordt in aanmerking genomen of de verzochte informatie betrekking heeft op emissies in het milieu. § 3. Voor informatie, bedoeld in het samenwerkingsakkoord van 21 juni 1999 tussen de federale Staat, het Vlaamse Gewest, het Waalse Gewest en het Brussels Hoofdstedelijk Gewest betreffende de beheersing van de gevaren van zware ongevallen waarbij gevaarlijke stoffen betrokken zijn, zijn de in § 1, 9° en 11°, genoemde uitzonderingen niet van toepassing. 4 De verhouding tussen open data en de bescherming van persoonsgegevens is zeer complex. De Vlaamse regering heeft dan ook principieel de keuze gemaakt om persoonsgebonden gegevens buiten beschouwing te laten en deze niet als open data beschikbaar te stellen. Op deze manier wordt de bescherming van persoonsgegevens maximaal gewaarborgd. 5 Artikel 1§1 Wet van 8 december 1992 tot bescherming van de persoonlijke levenssfeer ten opzichte van de verwerking van persoonsgegevens, B.S. 18 maart 1993.


10


2.3.1 WETTELIJKE VEREISTEN Zie paragraaf 2.2 met betrekking tot het wetgevend kader en de voorafgaande juridische aftoetsing.

2.3.2 EERDER GEPUBLICEERDE GEGEVENS Sommige gegevens zijn al elektronisch beschikbaar en kunnen dus relatief snel en gemakkelijk ook als Open Data set gepubliceerd worden. Voorbeelden hiervan zijn: Kadastrale informatie; Topografische kaarten; Verkeersinformatie; Weersvoorspelling.

2.3.3 WAARDE VAN DE GEGEVENS Sommige gegevens hebben vooral maatschappelijke waarde. Voorbeelden hiervan zijn: Wetten en parlementaire gegevens (bv. gegevens van stemming vertegenwoordigers); Gegevens voorafgaand aan de verkiezingen (bv. programma’s van politieke partijen); Gegevens van e-government en e-participation campagnes (bv. openbare raadplegingen, crowdsourcing). Andere gegevens hebben wellicht meer commerciële waarde: Wegenkaarten; Real-time verkeersinformatie; Real-time weerinformatie. Een recente studie6 toont aan dat er vooral interesse is in de volgende gegevens:

Hieruit blijkt dat mensen vooral op zoek zijn naar gegevens die op een kaart of map kunnen weergegeven worden, geografische gegevens dus. Alles wat kan gevisualiseerd worden op een kaart is bijzonder interessant, zeker omdat dit dan gemakkelijk in een smartphone of tablet applicatie te verpakken valt. Het betekent ook dat een groot deel van het publiek vooral handige en toegepaste applicaties zoekt die de vele informatiebronnen met elkaar verbinden en grafisch voorstellen. Ook informatie over bedrijven (business/financiële data) scoort hoog. Ook hier ziet men toegevoegde waarde om informatie van een bedrijf te kunnen vinden via Open Data, met vanzelfsprekend respect voor de privacy van dit bedrijf. Op de derde plaats zien we de socio-demografische / statistische informatie. Omgevingsgerelateerde informatie is vanzelfsprekend interessant voor iedereen. Gegevens met betrekking tot scholen, verkeer, vervuiling, criminaliteit, bereikbaarheid enz., kunnen belangrijk zijn bij bijvoorbeeld het zoeken naar een nieuwe woning. Deze eerste drie samen betekenen dat men vooral op zoek is naar applicaties die toegevoegde levenswaarde creëren of naar informatie die de

6 http://datos.gob.es/datos/sites/default/files/files/Estudio_infomediario/121001%20RED%20007%20Final%20Report_2012%20Edition_vF_en.pdf


11


interactie met de overheid kunnen faciliteren. Informatie uit verschillende bronnen samenbrengen en daardoor meerwaarde creëren is vooral de opdracht van bedrijven. Vlotte en toegankelijke beschikbaarheid van deze data is daarom cruciaal. Enigszins verassend is de statistiek met betrekking tot culturele informatie. Ofwel is informatie via andere kanalen beschikbaar, of schat het publiek de meerwaarde hiervan niet in. Overigens zijn de steden hier het meest actief rond.

2.3.4 BEREIK VAN DE GEGEVENS Sommige gegevens zijn specifiek gericht op het grote publiek en dus extra interessant: Verkeersinformatie; Openbaar vervoer; Verkiezingsgegevens. Andere gegevens zijn essentieel voor kleine groepen van mensen en nichemarkten: Informatie over faciliteiten en financiële steun voor mensen met speciale behoeften; Economische statistieken; Rechterlijke beslissingen.

2.3.5 PRIORITEITEN We kunnen gerust stellen dat er heel wat informatie geschikt is voor publicatie als Open Data en meestal al beschikbaar is via publicaties of documenten. Op voorwaarde dat voldaan is aan de wettelijke vereisten, stellen we onderstaand model voor om te bepalen wat voor elke overheidsinstantie relevant en bepalend kan zijn:

Het uitgangspunt is dat informatie en gegevens uit bestaande publicaties het makkelijkst kunnen gepubliceerd worden als Open Data. Immers, in de meeste publicatie zijn heel wat gegevens verwerkt en worden die getoond in de vorm van een grafiek of tabel. We stellen dus voor om in eerste instantie deze gegevens naar een Open Data set om te buigen en te publiceren. Bij iedere publicatie kan dit gepaard gaan met een Open Data set als aanvulling of voor detail analyse. Daarna is aan te raden om naar de bronsystemen te kijken en na te denken welke van die gegevens kunnen ontsloten worden. Dat zal dan wel een extra inspanning vragen om hieruit een Open Data set uit te distilleren, maar veel van die informatie is allicht al ergens gepubliceerd, dus hiermee wordt het ook op een gestructureerde manier als Open Data ter beschikking gesteld. Voorbeelden hier zijn: Lijst Parkings Lijst Openbare Toiletten Bushaltes


12


Treinhaltes Financiële gegevens (jaarcijfers bv) Cultuur Toerisme Openingsuren Adressen … De volgende stap is dat men bij elk nieuw project voor informatie verzameling of verwerking een extra stap voorziet die nagaat hoe die gegevens ook als Open Data set kunnen gepubliceerd worden. Het wordt dan een extra stap die standaard in elk project wordt ingebouwd en zorgt er meteen voor dat deze gegevens ook consistent als Open Data worden aangeboden. Door gegevens gestructureerd aan te bieden als Open Data kunnen ze ook makkelijk worden (her)gebruikt in eigen toepassingen en publicaties. Tot nu toe zijn we vooral aanbod gedreven bezig geweest, het is telkens de overheid die het initiatief neemt en beslist welke dataset wanneer ontsloten wordt. Het wordt extra interessant als de overheid ook datasets kan ontsluiten op vraag van burgers of bedrijven. Zo komt men in een vraaggedreven scenario, waar de overheid flexibel kan op inspelen. Het is immers zo dat de maatschappelijke waarde en impact van Open Data zal stijgen naarmate er meer aanbod is, maar vooral als er voldoende snel op de vraag kan ingespeeld worden. Er is immers heel wat vraag naar gegevens, voornamelijk in de volgende sectoren: Socio-economische informatie GEO data Business informatie Statistische informatie Wettelijke gegevens Het punt is dus dat je best op een makkelijke en eenvoudige manier kan beginnen door te focussen op bestaande publicaties, maar dat de (maatschappelijke) meerwaarde van Open Data toeneemt voor burger en / of overheid als je dit standaard gaat aanbieden bij elke informatie die je beschikbaar hebt en zeker als je vraaggedreven gaat werken.

Aanbeveling 4: publiceer eerst die gegevens die al beschikbaar zijn en die een meerwaarde voor burgers, bedrijven of organisaties kunnen betekenen.


13


3

KIES EEN MODELLICENTIE

Om het gebruik van Open Data zo veel mogelijk te stimuleren, en tegelijk de instanties te ondersteunen bij het beschikbaar maken van hun data, heeft de Vlaamse Regering modellicenties opgesteld die door alle instanties kunnen worden gebruikt. De combinatie van meerdere datasets wordt bemoeilijkt door de mogelijke verschillende licentievoorwaarden die erop van toepassing kunnen zijn. Het gebruik van uniforme licentievoorwaarden zorgt er voor dat Open Data optimaal kunnen worden gebruikt en kunnen leiden tot vernieuwende en waardevolle toepassingen. Bovendien besparen de instanties tijd en inspanningen door het gebruik van de eenvoudige licenties opgesteld door de Vlaamse overheid. De Vlaamse overheid heeft deze modellicenties op een dergelijke wijze opgesteld dat ze door alle instanties in Vlaanderen, ook op lokaal niveau, kunnen worden gebruikt voor het beschikbaar maken van hun data. Door het gebruiken van deze licenties bouwen de instanties mee aan een open overheid die participatie en innovatie ondersteunt.

3.1 VOORAFGAANDE BESLISSING OMTRENT VERGOEDINGEN De Vlaamse conceptnota open data vertrekt van het basisprincipe dat open data gratis of tegen een billijke vergoeding moet kunnen worden hergebruikt. De instantie moet dus voor elke dataset beslissen of zij deze gratis wil beschikbaar maken of een billijke vergoeding wil vragen. Indien gekozen wordt voor een billijke vergoeding, moet de instantie bepalen aan de hand van welke criteria deze vergoeding zal worden vastgelegd. Onder het huidige regelgevende kader is het maximum voor de totale inkomsten van deze vergoeding vastgelegd op maximaal “de kosten van verzameling, productie, vermenigvuldiging en verspreiding, vermeerderd met een redelijk rendement op investeringen”.7 De Europese richtlijn betreffende het hergebruik van overheidsinformatie raadt momenteel echter aan om de vergoeding te beperken tot de marginale kost voor de reproductie en verspreiding van de documenten.8 De toekomstige wijziging van deze richtlijn zal naar alle waarschijnlijkheid het principe van dergelijke marginale kost verplicht maken (met enkele uitzonderingen). Wanneer gekozen wordt voor het vragen van een billijke vergoeding, moet de instantie ook zorgen voor een procedure voor het betalen van die vergoeding door de gebruikers. Dit houdt onder meer in dat de betalingswijze moet worden vastgelegd, een rekeningnummer moet worden voorzien, e.d.9.

Aanbeveling 5: bepaal of voor het hergebruik van de data een vergoeding zal worden gevraagd. Leg criteria vast voor de berekening van deze vergoeding en organiseer de procedure voor de betaling van de vergoeding.

3.2 VOORAFGAANDE BESLISSING OMTRENT DE MOGELIJKE CATEGORIEËN VAN GEBRUIK Volgens het decreet van 27 april 2007 betreffende het hergebruik van overheidsinformatie en de conceptnota van de Vlaamse Regering moeten open data kunnen worden hergebruikt zowel voor niet-commerciële als commerciële doeleinden. Het blijft echter nog mogelijk om een onderscheid te maken tussen commercieel en niet-commercieel gebruik met betrekking tot de vergoeding. De afgrenzing van commercieel en niet-commercieel gebruik is niet altijd even eenvoudig, en het algemene principe van open data gaat ervan uit dat geen verschil wordt gemaakt tussen soorten gebruik. Daarom wordt de instanties in eerste instantie aangeraden geen onderscheid te maken tussen verschillende soorten gebruik. Indien de instantie toch om bepaalde redenen genoodzaakt is een onderscheid te maken tussen commercieel en niet-commercieel gebruik van de open data, is het belangrijk dat een duidelijke omschrijving van het begrip commercieel wordt opgesteld en meegedeeld aan de potentiële gebruikers. Voor deze omschrijving kan worden aangeknoopt bij de concepten van het winstoogmerk en de handelaar. Elke natuurlijke persoon of rechtspersoon die beroepshalve daden van koophandel verricht, wordt geacht de data voor commerciële doeleinden te gebruiken (tenzij hij het tegendeel kan bewijzen).10

Aanbeveling 6: indien het onderscheid tussen de vergoeding voor commercieel en niet-commercieel hergebruik noodzakelijk is, leg een duidelijke omschrijving van het begrip ‘commercieel’ vast, waarbij het gebruik door een handelaar met winstoogmerk als commercieel wordt beschouwd

7 Artikel 7 Decreet van 27 april 2007 betreffende het hergebruik van overheidsinformatie, B.S. 5 november 2007. 8 Considerans 14 Richtlijn 2003/98/EC van 17 november 2003 van het Europees Parlement en de Raad betreffende het hergebruik van overheidsinformatie, PB L 345, 90. 9 Cf. infra. 10 Zie Omzendbrief VR 2012/31. Omzendbrief toegang/gebruik en hergebruik, http://vademecum.vandenbroele.be/entity.aspx?id=173.

3/ Kies een modellicentie

14


3.3 KEUZE VAN EEN MODELLICENTIE Aan de hand van de beslissingen omtrent de soorten gebruik en de mogelijke vergoedingen kunnen de instanties een keuze maken uit vijf licentiemodellen (waarbij licentie 4a en 4b altijd samen moeten worden gebruikt): 1/Een Creative Commons Zero11 verklaring, waarbij de instantie afstand doet van haar intellectuele eigendomsrechten, voor zover dit wettelijk mogelijk is12. Hierdoor kan de gebruiker de data hergebruiken voor eender welk doeleinde, zonder een verplichting op naamsvermelding. 2/Gratis Open Data Licentie: onder deze licentie doet de instantie geen afstand van haar intellectuele rechten, maar mag de data voor eender welk doel hergebruikt worden, gratis en onder minimale restricties. 3/Open Data Licentie tegen Billijke Vergoeding: onder deze licentie stelt de instantie nog steeds haar data ter beschikking voor eender welk hergebruik, maar wil zij voor alle soorten hergebruik een billijke vergoeding ontvangen. 4a/Gratis Open Data Licentie voor Niet-Commercieel Hergebruik: om te voldoen aan het principe van Open Data, moet de data beschikbaar zijn onder minimale restricties voor zowel niet-commercieel als commercieel hergebruik. Eventueel kan wel een onderscheid gemaakt worden tussen de vergoedingen, wanneer de instantie dit wenst. Voor commercieel hergebruik kan dan een billijke vergoeding worden gevraagd, terwijl niet-commercieel hergebruik gratis wordt gemaakt. Deze licentie betreft het gratis niet-commercieel hergebruik. Licentie 4b wordt dan toepasselijk voor het commercieel gebruik. 4b/Open Data Licentie tegen Billijke Vergoeding voor Commercieel Hergebruik: wanneer een onderscheid wordt gemaakt op basis van het commercieel karakter van het hergebruik voor het vragen van een vergoeding, vormt deze licentie de tegenhanger van de Gratis Licentie voor Niet-Commercieel Hergebruik. Hierbij zijn dus de volgende combinaties mogelijk voor een bepaalde dataset: CC0 voor elk mogelijk hergebruik; Een gratis licentie voor elk mogelijk hergebruik; Een licentie tegen billijke vergoeding voor alle soorten hergebruik; De combinatie van een gratis licentie voor niet-commercieel hergebruik en een licentie tegen billijke vergoeding voor commercieel hergebruik.13 Al deze licenties zijn niet-transactioneel en moeten dus niet worden ondertekend door de licentienemer. Door het gebruiken van de data stemt hij in met de voorwaarden. Hierdoor kan de data volledig anoniem worden hergebruikt. Mogelijk wordt de identiteit van de gebruiker wel gevraagd in het kader van de betalingsprocedure voor het gebruik van de data tegen een billijke vergoeding. In dat geval blijft echter het verdere hergebruik van de data nog anoniem. De keuze voor één licentie voor elk mogelijk hergebruik is de beste oplossing om het eenvoudig karakter van de licentiemodellen te bewaren. De combinatie van twee licenties zou enkel moeten worden toegepast indien dit door de instanties echt noodzakelijk wordt geacht.

Aanbeveling 7: Gebruik voor het beschikbaar maken van de Open Data de modellicenties van de Vlaamse overheid. Kies bij voorkeur voor één licentie voor alle soorten hergebruik, zonder onderscheid tussen commerciële en niet-commerciële doeleinden.

11

http://creativecommons.org/about/cc0

12

Zie juridische nota punt 3.2 met betrekking tot de geldigheid van de CC0-verklaring

13 De combinatie van een gratis licentie voor commercieel gebruik en een licentie tegen een billijke vergoeding voor niet-commercieel gebruik is theoretisch mogelijk, maar zal in de praktijk hoogstwaarschijnlijk niet voorkomen.

3/ Kies een modellicentie

15


4

ONTSLUIT UW BRONGEGEVENS

In dit hoofdstuk wordt een aantal scenario’s beschreven op welke wijze je uit een bronsysteem data ontsluit, omvormt tot een Open Data stroom en aanbiedt op het Open Data Platform. Heel wat overheidsinstanties gebruiken nu al veel data om jaarverslagen, rapporten of andere documentatie te publiceren. Deze data kan ook als Open Data gepubliceerd worden. Het uiteindelijke doel is dus om een beperkt aantal scenario’s te definiëren die instanties kunnen gebruiken om met zo weinig mogelijk extra stappen en/of moeite een Open Data stroom te kunnen realiseren, naast de bestaande data stroom. Het voordeel van de scenario’s is dat die herkenbaar en breed toepasbaar zijn. Door die scenario’s uit te werken in combinatie met bestaande standaard technologieën, onderkennen we doorgaans een groot aantal situaties en een standaard aanpak als “best practice”. Deze scenario’s vormen een startpunt om de meest typische data stromen naar Open Data om te zetten.

4.1 ACHTERLIGGENDE GEDACHTE: GEBRUIK VAN ETL TECHNIEKEN We hebben onze inspiratie voor deze scenario’s overigens gehaald uit de Business Intelligence / Data Warehousing (BI / DWH) wereld. Daar worden reeds vele jaren technieken toegepast om informatie uit bronsystemen of databases te halen, (gedeeltelijk) op te kuisen, consistent te maken en te publiceren. Dit proces noemt men vaak het ETL proces:

Samengevat:

De technologie (i.e. ETL software) die gebruikt wordt voor klassiek datawarehouses kan ook gebruikt worden voor Open Data. Deze tools bieden mogelijkheden om informatie voor te bereiden op analyse of verwerking.

4/ Ontsluit uw brongegevens

16


Het zijn grotendeels dezelfde stappen die nodig zijn om de data als Open Data stroom te publiceren. Enkel de laatste stap, het laden van informatie in een data warehouse omgeving wordt vervangen door een andere stap, in het bijzonder het opladen van de gegevens (en hun metadata) naar het Open Data platform, die we dan ook “Publish” noemen.

Samengevat in procesvorm:

Dat betekent dat we voor een Open Data stroom grotendeels dezelfde ETL technologie kunnen hergebruiken of inzetten. Of anders gezegd, voor het opmaken van een Open Data stroom zijn geen nieuwe technieken, noch tools nodig. Indien er al een datawarehouse bestaat, is dit vaak ook een geschikte kandidaat om verder op te bouwen om (gedeeltelijk) Open Data aan te bieden. Hierdoor zal de consistentie van de intern gebruikte gegevens en de extern aangeboden gegevens (i.e. Open Data) makkelijker kunnen bewaakt worden. Bovendien kan ook een rapport (via BI-tool op een DWH) een geschikte bron zijn voor Open Data publicatie. Bouw dus zoveel mogelijk verder op bestaande technologie en voorzie telkens een stapje extra om de desbetreffende gegevens ook als Open Data Stromen te kunnen realiseren.

4.2 SCENARIO’S VOOR HET ONTSLUITEN VAN BRONGEGEVENS Dit alles wordt samengebracht in een aantal scenario’s die verder zullen beschreven worden en als startpunt voor een instantie kunnen dienen. Op dit moment zien we de volgende scenario’s: 1/Vertrekken van een bestaande publicatie: de instantie verzamelt de gegevens uit een bestaande publicatie (bv. tabel, grafiek) en publiceert die gegevens als Open Data stroom; 2/Vertrekken van een bestaande dataset: de instantie heeft bepaalde gegevens reeds opgemaakt, die nu ook als Open Data stroom kunnen gepubliceerd worden; 3/Vertrekken van een bron database: in dit scenario halen we de gegevens rechtstreeks uit een bron database die door de instantie


17


zelf is gemaakt en publiceren we bepaalde gegevens, mits de nodige omvormingen en controles, als een Open Data Stroom; 4/Vertrekken van een bestaand bronsysteem of pakket: vaak gebruiken instanties een commercieel pakket die een eigen database heeft. Die gegevens zijn vaak niet rechtstreeks benaderbaar of zitten in een vreemde vorm opgeslagen die door de leverancier is bepaald. In dit scenario gebruiken we technieken om die gegevens uit het pakket op te halen, om te vormen en als Open Data stroom te publiceren. Het verschil met scenario 3 is dat de pakketten vaak eisen dat je de gegevens via andere wegen ontsluit (bv. API of tools eigen aan het pakket), maar vaak kunnen die ook met klassieke ETL tools ontsloten worden; 5/Vertrekken van verschillende bronnen en consolideren van gegevens: dit scenario ligt dicht bij een datawarehouse techniek, waarin vaak gegevens al uit verschillende bronnen worden verzameld en in tijdelijke tabellen worden opgeladen. Van hieruit worden dan vaak de feitelijke data warehouses opgeladen. Het opladen zelf kan dan vervangen worden door een publiceren van een Open Data stroom; De scenario’s staan beschreven in oplopende complexiteit. Scenario 1 lijkt ons het meest toegankelijke voor alle instanties. Voor ieder volgend scenario neemt de complexiteit toe omdat het uitgangspunt is dat de gegevens minder eenvoudig te ontsluiten zijn en aldus er extra stappen nog zijn. Elk scenario steunt ook op de elementen die in verder in dit document worden beschreven, namelijk wat er nodig is om de gegevens Open Data consistent te maken en kwaliteitsvol te ontsluiten. Elk van deze scenario’s wordt hierna uitvoerig in detail besproken. In het volgende hoofdstuk gaan we dan dieper in op de technische tools die dit proces kunnen ondersteunen of automatiseren.

4.2.1 SCENARIO 1: VERTREKKEN VAN EEN BESTAANDE PUBLICATIE Wat In dit scenario vertrekken we van een bestaand proces waarin gegevens worden verzameld en bewerkt alvorens ze in een publicatie worden opgenomen. Denk aan al de publicaties die een overheid ter beschikking stelt (zie bijvoorbeeld http://www.vlaanderen.be/nl/publicaties) en de hoeveelheid gegevens die hiervoor verzameld zijn en uiteindelijk in de publicatie zijn opgenomen. Die gegevens zijn het resultaat van een aantal processtappen die door 1 of meerdere instanties zijn uitgevoerd vooraleer ze finaal zijn. Een voorbeeld hiervan is VRIND (http://www.vlaanderen. be/nl/overheid/werking-vlaamse-overheid/hoe-werkt-de-vlaamse-overheid/vrind-2012-cijfergegevens-en-indicatoren-over-de-vlaamse-samenleving). In deze publicatie zijn heel wat cijfergegevens verwerkt die ook als Open Data stroom interessant zijn voor verdere analyse en / of verwerking.

Wanneer Omdat de overheid publicaties zal blijven uitgeven, en instanties nu eenmaal heel wat gegevens verzamelen voor publicatie, lijkt ons dit het meest eenvoudige te zijn voor Open Data. Het zijn immers die gepubliceerde gegevens die we ook kunnen ombuigen tot een Open Data stroom, waar relevant uiteraard. Dit scenario kan dan ook gebruikt worden: Voor nieuwe publicaties, waarin een extra stap zal opgenomen worden in het proces om de gegevens ook als Open Data stroom beschikbaar te maken; Voor bestaande publicaties waarin het bestaande proces op de juiste plaats zal uitgebreid worden om de Open Data stroom mogelijk te maken (eerste maal) of aan te passen aan de realiteit. Eenmaal je het proces hebt opgezet om uit de publicatie een Open Data stroom op te halen en te publiceren, kan je dit herhaaldelijk toepassen. Zo wordt dan ook de Open Data stroom bijgewerkt bij een aanpassing van de publicatie.

Hoe Essentie is dat er in het proces een extra stap wordt voorzien om de data nu ook als Open Data te ontsluiten14, zie figuur hieronder:

14

Bij een “Open by default” benadering zal de ‘Open Data exit’ deel uitmaken van het verwerkingsproces


18


In het bestaande proces zal de IT afdeling een moment moeten identificeren wanneer de gegevens klaar zijn om naar de Open Data publicatie stap te brengen. We hebben in dit geval dus enkel een aantal “Publish” activiteiten uit te voeren. Hierbij een overzicht van uit te voeren stappen:

Extract Niet van toepassing in dit scenario

Transform Niet van toepassing in dit scenario

Publish Eenmaal de gegevens zijn afgezonderd, moeten ze bewerkt worden om aan de criteria van Open Data te voldoen: Metadata verzamelen Data set publiceren (bij voorkeur automatisch) Licentie model kiezen Op het platform eventuele conversies aanbieden en eventueel ook een API. Feedback lus opzetten, zorgen dat entiteit te bereiken is voor opmerkingen Voor regelmatige updates zorgen De laatste stap is dan de gegevens als Open Data stroom te publiceren op het Open Data platform, conform de richtlijnen die eerder in dit document zijn opgesteld.

Voorbeeld Een voorbeeld van dit scenario zijn de gegevens uit de VRIND publicatie, zie website http://www.vlaanderen.be/nl/overheid/werking-vlaamse-overheid/hoe-werkt-de-vlaamse-overheid/vrind-2012-cijfergegevens-en-indicatoren-over-de-vlaamse-samenleving en tekst:

“VRIND, de Vlaamse Regionale Indicatoren, is een jaarlijkse uitgave van de Studiedienst van de Vlaamse Regering over de resultaten van het Vlaamse beleid en de impact hiervan op de samenleving en de omgeving. VRIND geeft aan de hand van cijfermateriaal een beeld van wat de Vlaamse overheid doet, op welke beleidsdomeinen ze actief is en met welke resultaten. Voor elk domein geeft VRIND ook een schets van de recente sociaal-culturele, economische, ecologische en demografische ontwikkelingen in Vlaanderen” De gegevens worden typisch verzameld en samengesteld als onderdeel van de jaarlijkse publicatie cyclus. De gegevens die in VRIND gebundeld zijn, worden (bijna) allemaal ook reeds ontsloten via lokale statistieken/VOBIP Cognos publiek (zie http://aps.vlaanderen.be/lokaal/lokale_statistieken.htm) Dit was welliswaar zonder rekening te houden met de criteria van Open Data. Daarom werd een extra stap ingelast in de laatste fase van het proces, waarbij eerst de finale datasets apart werden gezet. Daarna is een script geschreven die de metadata van elk van de datasets aanvult en oplaadt op het CKAN platform. Het ging in totaal over meer dan 1.100 datasets. Deze werkwijze kan herhaald worden voor iedere publicatie en de gegevens kunnen ofwel manueel (indien relatief weinig datasets) of automatisch opgeladen worden. In het laatste geval kunnen de Open Data sets herhaaldelijk opgeladen worden bij wijziging of nieuwe informatie.


19


4.2.2 SCENARIO 2: VERTREKKEN VAN EEN BESTAANDE DATASET Wat Heel wat entiteiten publiceren momenteel al heel wat informatie op websites in een downloadbaar formaat zoals XLS (opm: indien PDF, zie scenario 1). Ook zien we dat er al veel investeringen zijn gebeurd om “viewers” te bouwen waarmee die informatie online kan geraadpleegd of gevisualiseerd worden (bv. BIVO, VOBIP publiek zie: http://vobippubliek.vlaanderen.be/cognos10). Dit impliceert dat de entiteit al een proces of IT ondersteuning heeft om die informatie voor te bereiden, te publiceren en te bekijken. Met dit scenario willen we een extra stap in dit proces toe voegen die de gegevens ook klaar maakt voor publicatie als Open Data stroom. Dat betekent dat er een minimaal aantal extra zaken moeten gebeuren, zoals metadata voorzien en de publicatie op het Open Data Platform.

Wanneer We veronderstellen dat de overheid blijvend informatie via downloads of “viewers” zal ter beschikking stellen en dat Open Data een extra kanaal is voor het vrijgeven van deze informatie. Dat betekent dat het onderliggende proces zal blijven bestaan en kan uitgebreid worden met een extra stap.

Hoe Zoals gesteld, veronderstellen we dat er een proces bestaat waarin de gegevens nu al worden klaargemaakt. We stellen voor een extra stap in te bouwen binnen dit proces om de data set nu extra om te bouwen tot een Open Data stroom.

In sommige gevallen zien we dat er naast de publicatie al publieke data wordt opgemaakt en met een bepaalde (web) viewer toepassing ter beschikking gesteld. Meestal voldoet deze publieke data echter niet volledig aan de criteria van Open Data, maar met minimale moeite en extra stappen kan dit wel een goede basis zijn om er snel een Open Data set van te maken. Dit scenario houdt echter rekening met een aantal extra stappen omdat er in het bestaande proces totaal anders mee omgesprongen wordt. Deze stappen zijn:

Extract Gegevens apart isoleren en filteren uit de database in eenduidige dataset. Dit kan eventueel een extra stap vereisen om gegevens rechtstreeks uit de database te halen. Het kan ook zijn dat we voor de Open Data set andere gegevens selecteren (bv. minder velden, geanonimiseerd) dan in het bestaande proces. Indien de gegevens uit de publicatie al voldoen aan de criteria van Open Data, dan hoeft deze stap uiteraard niet.

Transform Dit omvat een gedegen kwaliteitscontrole van de gegevens, zoals in elke datawarehouse omgeving wordt gedaan. Bijvoorbeeld door eenduidige benaming van velden en inhoud (bv. Geen cryptische afkortingen, geen 0 of 1 voor geslacht, M = Man, adressen consistent, namen voluit en in zelfde formaat, enzovoort). We veronderstellen echter dat deze controles en acties ook al in het bestaande verwerkingsproces zitten, dus eventueel moeten die stappen daar mee afgestemd worden. Het is geenszins de bedoeling om een apart proces naast het bestaande te creëren. Maar, ervaring leert dat er meestal specifieke gegevens gemaakt worden voor een geselecteerd publiek (lees: met toegangsrechten, niet publiek). Voor Open Data kan dat natuurlijk niet, dus daarom zullen er extra stappen nodig zijn om de gegevens klaar te maken. Indien de gegevens uit de publicatie al door een gelijkaardig proces zijn gegaan en voldoen aan de criteria van Open Data, dan hoeft deze stap uiteraard niet.

Publish


20


In ieder geval zijn volgende stappen altijd nodig in dit scenario, eenmaal de Open Data set is opgemaakt: Metadata verzamelen; Data set publiceren (bij voorkeur automatisch); Licentie model kiezen; Op het platform eventuele conversies aanbieden en eventueel ook een API; Feedback lus opzetten, zorgen dat entiteit te bereiken is voor opmerkingen; Voor regelmatige updates zorgen.

Voorbeeld Een mooi voorbeeld zijn de werkloosheidscijfers die gepubliceerd zijn op http://www.werk.be/cijfers en daar ook als XLS kunnen gedownload worden. Het basisidee is dan dat deze datasets ook op het Open Data platform ter beschikking komen en iedere maand automatisch bijgewerkt worden (i.e. publicatie van de nieuwste gegevens). Via de website hebben mensen toegang tot de gegevens volgens de mogelijkheden van de “viewer” die ingebouwd is in de website en soms beperkte download opties biedt (vanuit Open Data perspectief). Een tweede voorbeeld is (de publieke versie van) BIVO (dashboard Bedrijfsinformatie) waar al een visualisatie component is voorzien, op basis van Cognos Viewer. Ook deze “viewer” biedt een aantal mogelijkheden, rechtstreeks van de website te gebruiken en beperkte download opties (vanuit Open Data perspectief). In beide voorbeelden stellen we voor om de relevante gegevens ook volledig op te zetten als Open Data stroom en aldus extra te publiceren op het Open Data platform.

4.2.3 SCENARIO 3: VERTREKKEN VAN EEN DATABASE Wat In heel wat gevallen zitten de kerngegevens in een database die gemaakt is ter ondersteuning van een applicatie om een bedrijfsproces voor de entiteit te ondersteunen. Dat is meteen het vertrekpunt van dit scenario, namelijk gegevens uit een database ophalen en deze omvormen naar een Open Data stroom. De meeste databases gebruiken een structuur om gegevens op te slaan die niet meteen voor Open Data geschikt zijn. Alles is immers gericht om gegevens snel naar de applicatie te brengen in het kader van een opvraging, toevoeging of verwijderen van bestaande gegevens. Deze structuur noemt met vaak OLTP (= on-line transaction processing) en is vaak relationeel van opzet: gegevens zijn in verschillende tabellen gelinkt met elkaar via een relatie (key).

De basis van dit scenario is dus dat de gegevens eerst uit de database van de applicatie gehaald moeten worden, alvorens ze klaar gemaakt worden voor publicatie als Open Data set. Er is dus een extra verwerkingsproces nodig om deze gegevens op te halen en om te vormen of consistent te maken voor Open Data publicatie. In dit geval zijn ook de “Transformation” tools noodzakelijk.


21


Wanneer De assumptie in dit scenario is dat we een applicatie hebben die intern is ontwikkeld op één van de bestaande interne omgevingen (bv. Gebouwd in Java, .NET, APEX, etc) en de DB is één van de standaarden binnen de instantie (bv Oracle, SQLServer, PostGress voor Vlaamse overheid). Indien dit niet het geval is, dan stellen we voor om met scenario 4 verder te gaan. We gaan er ook van uit dat de vorige scenario’s niet van toepassing zijn als vertrekpunt. MAW, er zullen dus gegevens eerst moeten onttrokken worden uit databases alvorens te ontsluiten naar het Open Data platform.

Hoe In dit scenario komen de technieken van “Extract” en “Transform” volop van pas, omdat er geen bestaand verwerkingsproces is om van te vertrekken of in te haken. We vertrekken dan ook rechtstreeks van een database (via een query of tools).

Een kanttekening hierbij is dat we dit soort “technische” bewerkingen niet gelijkstellen met de “inhoudelijke” bewerkingen die meestal in de “Transform” stap gebeuren. Denk hierbij aan complexe transformaties zoals bv. het aaneenschakelen van de opeenvolgende inschrijvingen van een leerlingen uit verschillende systemen (lager, secundair, hoger, VDAB, ...) om de volledige studieloopbaan te construeren. Het resultaat is het gevolg van meerdere technische bewerkingen en stappen dat een logisch of inhoudelijk geheel vormt. Er kan dus meer dan 1 technische stap nodig zijn om de transformatie uit te voeren. We stellen de volgende stappen voor:

Algemeen Zorg eerst en vooral voor een logische data map waarin de fysische relaties van de DB zover mogelijk links gelaten worden. Dat heeft tot gevolg dat het maar zeer zelden tot nooit tot een directe publicatie van een extract uit de database naar Open Data zal gebeuren, maar het kan. In veruit de meeste gevallen zal je geen 1 op 1 kopie kunnen publiceren en zullen stappen nodig zijn om de DB kopie om te vormen naar een formaat dat op zich staat (i.e. keys vervangen door waarden, referenties invullen, consistent maken, M = Man, etc). Verder kunnen ook stappen nodig zijn om tabellen uit de database met elkaar te combineren tot je aan de logische data map komt. Eventueel moet dus ook “Tranformation” technologie worden gebruikt om de gegevens consistent te maken.

Extract De meeste database systemen hebben standaard technieken om tabellen uit te lezen en als flat file beschikbaar te maken. Bijvoorbeeld: Oracle: via EXPORT tool; Microsoft: SQL Server Import and Export Wizard; MySQL: via mysqldump tool; Postgres: SQL Dump procedure. Wanneer gegevens frequent wijzigen kan als alternatief een programma geschreven worden die via ODBC of JDBC drivers de gegevens uitleest uit het DBMS. ODBC (of direct SQL wat in feite hetzelfde is) zal toelaten om meer complexe extractie-logica te programmeren. Ten slotte kan ook gebruik gemaakt worden van de mogelijkheden binnen elke ETL toolset. Praktisch gezien is het voor complexe transformaties ook vaak aangewezen om de data, al dan niet tijdelijk, op te slaan in een databank en hierop dan verder te werken om de definitieve Open Data stroom te realiseren. Bij dergelijke procedures spelen altijd 2 dimensies: Ofwel altijd de volledige inhoud van de database overhalen en publiceren als Open Data stroom; Ofwel enkel de wijzigingen / delta ten aanzien van de vorige versie downloaden en samenvoegen met de Open Data stroom.


22


Transform Dit omvat een gedegen kwaliteitscontrole van de gegevens, zoals in elke datawarehouse omgeving wordt gedaan. Bijvoorbeeld door eenduidige benaming van velden en inhoud ( geen cryptische afkortingen gebruiken, geen 0 of 1 voor geslacht maar bijvoorbeeld M = Man gebruiken, adressen consistent opslaan, namen voluit schrijven en in hetzelfde formaat, enzovoort). Omdat we hier niet kunnen veronderstellen dat er al een proces is, moeten al deze transformatie stappen hier in uitgevoerd worden. In deze fase kunnen ook inhoudelijke verwerkingen gebeuren, zoals het anonimiseren van gegevens, of het samenvoegen van datasets om tot een eenduidige granulariteit te komen. Het is verkiesbaar om de geëxtraheerde gegevens zo snel en frequent mogelijk naar Open Data te vertalen, zodat gebruikers en burgers maximaal over de laatste nieuwe referentiegegevens beschikken. Zeker wanneer het over snel wijzigende gegevens gaat. Dit heeft als gevolg dat ook de transformaties die deze gegevens ondergaan in feite reproduceerbaar zijn en bij voorkeur automatisch moeten kunnen gebeuren.

Publish Nadat de gegevens klaar zijn voor publicatie als Open Data, rest ons nog de volgende stappen: Metadata verzamelen Data set publiceren (bij voorkeur automatisch) Licentie model kiezen Op het platform eventuele conversies aanbieden en eventueel ook een API. Feedback lus opzetten, zorgen dat entiteit te bereiken is voor opmerkingen Voor regelmatige updates zorgen

Voorbeeld Op het moment van schrijven (Q4 2013) hebben we nog geen enkele Open Data set die door deze stappen is gegaan.

4.2.4 SCENARIO 4: VERTREKKEN VAN EEN BESTAAND BRONSYSTEEM Wat Het vertrekpunt in dit scenario is dat de entiteit een of meerder operationele systemen of pakketten heeft van waaruit Open Data gegevens kunnen bekomen worden, mits een aantal bewerkingen, al of niet met tussenkomst van de leverancier of de dienstenleverancier die het pakket beheert voor de entiteit. De extra complexiteit is hier dus dat men met een pakket te maken heeft, waarin het niet is toegelaten om rechtstreeks de database te benaderen.

Wanneer Dit scenario is van toepassing wanneer de gegevens in een (commercieel) pakket zitten, waarbij soms niet rechtstreeks aan de database kan geraakt worden. Dit scenario is ook van toepassing als de entiteit een dienst betrekt van een derde partij (bv. Software As A Service), waarbij de dienst extern wordt aangeboden (bv Cloud toepassing).

Hoe Dit scenario is een uitbreiding van vorig scenario, met het verschil dat hier de database niet rechtstreeks benaderbaar is, zoals hieronder is voorgesteld:


23


Het advies bij een pakket is om gegevens nooit 1 op 1 te kopiëren en te publiceren. Vaak zijn de databases en veldnamen cryptisch omschreven en is de structuur van de database zo ontworpen dat het enkel voor online transacties is geoptimaliseerd. Bij upgrades wijzigt de structuur meestal en kan je dus herbeginnen. Verder zijn de volgende stappen relevant:

Extract We gaan er van uit dat de instantie met de leverancier van het pakket kan bespreken hoe de gegevens kunnen ontsloten worden: Via een procedure die bij het pakket hoort. Vaak leveren pakketleveranciers een programma of script die de gegevens kan uitlezen, zelfs met bepaalde parameters. Aangezien deze procedure door de leverancier is geschreven en onderhouden (bv. bij upgrade van het pakket), heb je zekerheid dat deze procedure “forward en backward compatible is”; Via APIs, indien het pakket dit aanbiedt. Dit betekent dat je een programma zal moeten schrijven die de APIs aanroept om de gegevens te verkrijgen. Let op: sommige APIs kunnen ook bewerkingen uitvoeren op de gegevens vooraleer ze aan te bieden, bv consolideren, aggregeren, enzovoort; Via een nieuw programma of script die de gegevens rechtstreek uitleest uit de database van het pakket. Men is dan wel afhankelijk van het database design van de leverancier, dat per versie of upgrade wel eens durft te wijzigen. Dat betekent dat je het programma dan iedere keer moet aanpassen. Deze aanpak is dan ook niet aan te bevelen. Bij dergelijke procedures spelen altijd 2 dimensies: Ofwel altijd de volledige inhoud van de database exporteren en publiceren als Open Data stroom; Ofwel enkel de wijzigingen / delta ten aanzien van de vorige versie exporteren en samenvoegen met de Open Data stroom.

Transform Dit omvat de transformatie en een gedegen kwaliteitscontrole van de gegevens, zoals in elke datawarehouse omgeving typisch wordt gedaan. Bijvoorbeeld door eenduidige benaming van velden en inhoud (bv. geen cryptische afkortingen, geen 0 of 1 voor geslacht, M = Man, adressen consistent, namen voluit en in zelfde formaat, enzovoort). Omdat we hier niet kunnen veronderstellen dat er al een proces is, moeten al deze transformatie stappen hier in uitgevoerd worden. In deze fase kunnen ook inhoudelijke verwerkingen gebeuren, zoals het anonimiseren van gegevens, of het samenvoegen van datasets om tot een eenduidige granulariteit te komen.

Publish Nadat de gegevens klaar zijn voor publicatie als Open Data, rest ons nog de volgende stappen: Metadata verzamelen; Data set publiceren (bij voorkeur automatisch); Licentie model kiezen; Op het platform eventuele conversies aanbieden en eventueel ook een API; Feedback lus opzetten, zorgen dat entiteit te bereiken is voor opmerkingen; Voor regelmatige updates zorgen.

Voorbeeld Een voorbeeld zijn contactgegevens, die vaak in commerciële pakketten (bv. CRM systeem) of eigen applicaties worden bijgehouden. Het ontsluiten van deze gegevens zal moeten gebeuren door middel van een procedure binnen het pakket of door een programma te schrijven die de API oproept en de DB uitleest. Dit is de makkelijkste stap. Het consistent maken van adresgegevens is de volgende stap en vaak ziet men nog verschillende formaten opduiken bij publicatie. Daarom raden we aan om hiervoor een bestaande modelleringsafspraak te gebruiken. Voor contactgegevens verwijzen we dan ook graag naar de OSLO standaarden (zie http://purl.org/oslo/) Op het moment van schrijven (Q4 2013) hebben we nog geen enkele Open Data set die door deze stappen is gegaan.


24


4.2.5 SCENARIO 5: VERTREKKEN VAN VERSCHILLENDE BRONSYSTEMEN Dit is een scenario voor ervaren instanties met Business Intelligence en datawarehouse technieken. Het scenario gaat er van uit dat de instantie al wat datawarehouses en rapporteringsomgevingen lopende heeft en dat er heel wat ervaring is met het ontsluiten van gegevens uit verschillende bronnen. Alle “Extract” en “Transform” technieken en tools zijn al in gebruik en hierin kunnen we deze hergebruiken.

Wat Vaak zijn gegevens die gepubliceerd worden in een datawarehouse het resultaat van een hele reeks bewerkingen, zowel naar inhoud toe als naar aggregatie toe. Eerst worden de relevante gegevens uit verschillende bronnen gehaald en consistent opgeslagen in een “Operational Data Store” (ODS) omgeving. Voor Open Data heeft dit als voordeel dat deze gegevens niet meer apart uit de bronsystemen moeten gehaald worden. Een ODS is ook de laagste vorm van granulariteit van de gegevens, dus een ideale bron om alle gegevens hier te ontsluiten. Daarna worden gegevens vaak bewerkt in fases en tussentijds opgeslagen in “staging” tabellen. Hierop lopen dan verschillende programma’s om de gegevens verder te aggregeren en consistent te maken alvorens op te laden in een datawarehouse. Voor Open Data kunnen we ook vertrekken van een Staging tabel en daar dan de Open Data stroom uit opmaken. Het grote voordeel is dan dat al de correcties en bewerkingen van de gegevens al gebeurd zijn.

Wanneer We gaan er hier van uit dat het Open Data team maximaal hergebruik maakt van een aantal bestaande voorzieningen binnen de instantie. Dit scenario is dus geldig als er al een ODS omgeving is en / of er een aantal Staging tabellen zijn als vertrekpunt. Het Open Data team kan dan gebruik maken van de “Extract” en “Transform” programma’s om zo meteen consistente Open Data stromen te maken. Wel is het zo, dat het Open Data team dan ook de aggregatie en granulariteit moet nakijken of aanpassen om de Open Data stromen zo fijn mogelijk te houden. Eventueel moet dus een aparte of specifieke Staging tabel voor Open Data gemaakt worden. In dat geval moet een extra programma binnen de technologie van de instantie voorzien worden.Wanneer er complexe transformaties uitgevoerd worden op de brongegevens, worden er daarom Staging tabellen toegevoegd. Voor het samenvoegen van gegevens uit verschillende entiteiten en op termijn 1 geconsolideerd bestand te publiceren (bv. 1 adressenbestand voor alle entiteiten, met een gelijk data model).

Hoe De volgende stappen zijn relevant:

Algemeen Algemeen stellen we voor om zoveel mogelijk de bestaande standaard ETL omgevingen en technologieën te hergebruiken voor Open Data. We zien geen nood om andere tools binnen te halen. Indien er geen technologie voorhanden is, verwijzen we graag naar bijlage 2 “Technische standaarden”, waar advies en tips worden aangereikt.

Extract We gaan er hier van uit dat alle Extract functionaliteit binnen de bestaande BI of DWH voorhanden is en we deze niet specifiek moeten opzetten voor een Open Data stroom.


25


Transform Ook hier gaan we uit van de bestaande BI of DWH omgevingen. Alle Open Datastromen kunnen dan uit de laatste Staging tabellen gehaald worden. Eventueel moet enkel een specifieke Staging Tabel voor Open Data opgemaakt worden, dat is te bekijken in functie van de granulariteit.

Publish Nadat de gegevens klaar zijn voor publicatie als Open Data, resten ons nog de volgende stappen: Metadata verzamelen. Omdat we hier van een bestaande DWH omgeving vertrekken, kan er al voldoende metadata voorhanden zijn in deze omgeving. Toch vragen we met aandacht de set van metadata na te kijken, omdat meestal niet alle Open Data metadata velden zullen voorzien zijn; Data set publiceren (bij voorkeur automatisch); Licentie model kiezen; Op het platform eventuele conversies aanbieden en eventueel ook een API; Feedback lus opzetten, zorgen dat entiteit te bereiken is voor opmerkingen; Voor regelmatige updates zorgen.

Voorbeeld Een voorbeeld van een uitgebouwde BI en DWH omgeving vinden we bij Departement Onderwijs & Vorming, meer bepaald in het Kenniscentrum project. Daar zijn alle tools en technieken zoals hier beschreven voorhanden. Er is echter op het moment van schrijven (Q1 2014) nog geen enkele informatiestroom of gegevens die als Open Data set al door deze stappen gegaan.

Aanbeveling 8: kies een scenario voor het ontsluiten van brongegevens met het oog op de publicatie als Open Data en pas dit toe.


26


5

KIES EEN OPEN FORMAAT

Vooraleer we datasets publiceren op het Open Data platform dienen deze datasets of Open Data stromen te voldoen aan een aantal minimale vereisten met betrekking tot kwaliteit en consistentie. In wat volgt worden aanbevelingen geformuleerd welke bestandsformaten te gebruiken om uw data te publiceren. Tot slot wordt een maturiteitsmodel voor Open Data toegelicht.

5.1 MINIMALE VEREISTEN In deze paragraaf worden er een aantal minimale vereisten bij het ontsluiten van brongegevens als Open Data vooropgezet. Deze vereisen zijn opgemaakt vanuit de volgende dimensies: Bewaken van de kwaliteit van een Open Data: het geheel van technische eigenschappen waaraan een Open Data stroom moet voldoen; Bewaken van de consistentie van een Open Data: bewaken van de innerlijke technische samenhang van de gepubliceerde gegevens. In de volgende paragrafen worden er per dimensie enkele praktische tips gegeven hoe men deze kan realiseren. Deze tips zijn niet exhaustief noch in een bepaalde volgorde te lezen:

5.1.1 KWALITEIT Om de technische kwaliteit van de gegevens in een Open Data stroom te bewaken, wordt er voorgesteld dat iedere dataset moet voldoen aan de volgende criteria: Iedere Open Data stroom moet een enige en unieke “Header row” hebben met een eenduidige beschrijving van de kolommen, in het Nederlands of Engels. Impliciet betekent dit ook dat de lay-out van de dataset vastligt en dus ook niet automatisch wijzigt wanneer er velden in de bron toegevoegd worden. Iedere Open Data stroom moet voldoende metadata beschrijving hebben en minimaal voldoen aan de velden die in dit document zijn opgenoemd; Iedere Open Data stroom moet voorzien in een proces om op regelmatige tijdstippen nieuwe of aangepaste gegevens te publiceren (een update proces). Historische gegevens zullen uiteraard stabiel blijven, maar kunnen ook ieder maand, jaar of andere periode aangevuld worden; Iedere Open Data stroom moet een versie nummer krijgen zodat deze eenduidig kan geïdentificeerd worden en mogelijke aanpassingen kunnen getraceerd worden (i.e. versiebeheer). Aanbeveling 9: controleer hoger vermelde criteria voor een dataset gepubliceerd wordt op het Open Data platform.

5.1.2 CONSISTENTIE Alle Open Data die gepubliceerd wordt, moet zoveel mogelijk consistent zijn over alle data stromen, en instanties heen. Als het niet kan over de instanties heen, dan minstens op niveau van de instantie zelf. Alle adressen moeten bijvoorbeeld altijd en voor iedereen op dezelfde manier ontsloten worden, anders zal een gebruiker of firma hier moeilijk een geconsolideerd beeld van kunnen vormen. Via de volgende parameters proberen we dit concreet te maken: 1/Open Datastromen moeten inzichtelijk zijn: Elke gebruiker van de Open Data Stroom moet de unieke oorsprong van de gegevens begrijpen; Elke werknemer die een Open Data stroom wil publiceren, moet eerst met de eigenaar van de data spreken om het proces en de bewerkingen op de gegevens goed te begrijpen. Eventueel kan dit in de metadata aan de consument meegedeeld worden; Bepaal de status van de gegevens (draft, gevalideerd). Hergebruik wat al bestaat binnen de instantie aan (meta)beschrijvingen van gegevens. Deze kunnen helpen om de processen nodig om een Open Data stroom te maken te vergemakkelijken, minimaal “Vraag Logisch en Fysisch Data Model op” en “Vraag bestaande data extracts op”;

5/ Kies een open formaat

27


Beschrijf het data model en metadata van in het begin. 2/Open Data Informatie moet juist en volledig (binnen de context) zijn: Bepaal (of bouw) validatie regels op basis van de data zelf; Check dummy & default waarden (bv M / V); Doe een aantal basiscontroles en verbeter eventuele fouten aan de bron (vb. adres); Identificeer verkeerde of ontbrekende velden; Kijk naar optimalisatie en vermijd dubbele gegevens op te nemen. 3/Open Data Informatie moet controleerbaar zijn: Monitor het verloop van bronsysteem naar Open Data stroom; Zet kwaliteitstesten op voor iedere stap in het proces; Zet volume testen op om te vermijden dat Open Data stromen te groot worden. Open Data wordt typisch klein gehouden met het oog op hergebruik in mobiele applicaties. Indien de stroom groter wordt (bv. voor GIS gegevens), vermeld dit duidelijk op het Open Data platform of in de metadata; Scheid online en batch verwerking, zodat de ontsluiting van Open Data stromen niet te belastend is voor de infrastructuur binnen de entiteit.. 4/Open Data Informatie moet veilig zijn: Vertrouwelijke gegevens uitfilteren zodanig dat een persoon en/of bedrijf op basis van een eenduidig feit niet kan getraceerd en dus geviseerd worden, tenzij deze gegevens zich al in de openbaarheid bevinden (bv. contact adressen kan wel); Privacy wetgeving respecteren; Anonimiseren van gegevens; Aggregeren indien nodig (granulariteit). Aanbeveling 10: Besteed de nodige aandacht aan hogervermelde criteria of de dataset zal bestempeld worden als onbetrouwbaar en dus niet gebruikt worden.

5.2 OPEN FORMATEN Bij de Vlaamse Overheid willen we minimaal datasets publiceren die voldoen aan de 3 sterren beschrijving uit het 5 sterren maturiteitsmodel. Dit betekent dat we gestructureerde data willen aanbieden in een bestandsformaat dat open (non-proprietary) is. Open formaten voor gestructureerde data zijn onder andere: CSV (http://en.wikipedia.org/wiki/Comma-separated_values) liefst in UTF–8 encoding); TSV (http://en.wikipedia.org/wiki/Tab-separated_values) liefst in UTF-8 encoding); XML (http://www.w3.org/XML); JSON (http://www.json.org/); ODF (http://en.wikipedia.org/wiki/OpenDocument); RDF/XML, turtle, N-triple, JSON-LD (http://en.wikipedia.org/wiki/Resource_Description_Framework). Open formaten voor geodata zijn onder andere: Shapefile (http://en.wikipedia.org/wiki/Shapefile); GeoJSON (http://geojson.org/); GML (http://www.opengeospatial.org/standards/gml); KML (https://developers.google.com/kml/); WKT (http://en.wikipedia.org/wiki/Well-known_text).


28


Aanbeveling 11: gebruik zoveel mogelijk een en hetzelfde formaat zoals CSV. Andere formaten kunnen immers automatisch opgemaakt worden (zie The Datatank). Gestructureerde data die niet in een open formaat (b.v. MS-Excel) beschikbaar is, kan toch gepubliceerd worden door middel van bijvoorbeeld de Datatank. Het Open Data platform is geïntegreerd met de Datatank voor conversie diensten van MS-Excel naar deze open formaten. De DataTank is een open source tool die gegevens publiceert. Deze gegevens kunnen worden opgeslagen in tekstbestanden zoals CSV, XML en JSON of in binaire structuren zoals SHP-bestanden en relationele databases. De DataTank zal de gegevens uitlezen en deze publiceren op het web met behulp van een URI als een identifier. Het kan vervolgens deze gegevens weergeven in het gewenste formaat, ongeacht wat de oorspronkelijke datastructuur was. Zie http://thedatatank.com/

5.3 STANDAARDEN Er bestaan heel wat standaarden voor het modelleren van gegevens en velden. Ook binnen de Vlaamse overheid zijn er al wat afspraken gemaakt. Hieronder is een lijst van Europese of internationale afspraken die kunnen toegepast worden op Open Data stromen: Algemene vocabularia: DCMI, zie http://dublincore.org; OSLO, zie http://www.v-ict-or.be/kenniscentrum/OSLO. Om mensen te beschrijven: vCard, zie http://en.wikipedia.org/wiki/VCard; Core Person Vocabulary zie https://joinup.ec.europa.eu/asset/core_person/description; Om organisaties te beschrijven: Registered Organisation Vocabulary, zie http://www.w3.org/TR/vocab-regorg/ of https://joinup.ec.europa.eu/asset/core_business/news/publication-core-business-vocabulary-regorg-w3c-standards-track Om adressen te beschrijven: vCard; Core Location Vocabulary , zie https://joinup.ec.europa.eu/asset/core_location/release/100 Voor het beschrijven van overheidsdiensten: Core Public Service Vocabulary van EU, zie https://joinup.ec.europa.eu/asset/core_public_service/description Voor het melden van niet-dringende problemen of suggesties Open311.org, zie http://open311.org/ Verder kunnen we ook verwijzen naar het initiatief van W3C organisatie dat hierin nog een stap verder gaat om zelfs afspraken te maken tussen overheden heen, zie http://www.w3.org/blog/2012/03/interoperable-governments/

5.4 LINKED OPEN DATA Voor diegenen die verder willen gaan dan de 3 sterren en zich willen integreren in het Linked Open Data web, geven wij in een apart document richtlijnen: hoe unieke ‘identifiers’ toe te kennen aan de entiteiten (organisaties, percelen, diensten, … ) waarvan/waarover u data wil publiceren; welke vocabularia (eigenschappen, relaties en klassen) bij deze beschrijving te gebruiken.


29


5.5 API U kan ook overwegen om uw datasets niet (of niet uitsluitend) aan te bieden via datadumps maar ook via een API. Een API heeft immers het voordeel dat: alleen die data worden teruggegeven die van belang zijn voor de afnemer op basis van een query, door het gebruik maken van een filter, voorgesorteerd volgens behoefte, … ; de meest actuele data kunnen worden teruggegeven. Een mogelijk nadeel is natuurlijk dat als de API / service niet beschikbaar is (technische storing…), de gegevens ook niet meer opgevraagd kunnen worden door de afnemer. Indien u zelf een API wil bouwen, raden wij aan een RESTful Web API aan te bieden en toegang te verlenen tot de service zonder het gebruik van een API key. Voor een goede beschrijving van REST en een RESTful web API verwijzen we naar het desbetreffende wikipedia artikel (http://en.wikipedia. org/wiki/Representational_State_Transfer#RESTful_web_services). Heel veel API aanbieders verwachten dat een potentiële gebruiker van de API/service zich eerst registreert. Na registratie wordt er dan een unieke key toegekend die met elke request naar de API moet meegegeven worden. Zo kan men beter monitoren door wie en hoe de service wordt gebruikt. In onze context gaat het echter om het lezen/herbruiken van Open Data en het gebruik van een API key is hier een hindernis die er niet hoort te zijn. Geen API key voor het ophalen van data dus. Indien een API veel gebruikt wordt, of een server zwaar belast, kan het interessant zijn om deze API te ontsluiten op een aparte machine. Hebt u al een data dump, dan is het voldoende om uw dataset te registreren op het Vlaamse Open Data Portaal, meer specifiek in CKAN. Door de integratie van ‘the Datatank’ software in het Open Data portaal, wordt er dan automatisch een API aangeboden volgens de hierboven aangehaalde REST principes. U vindt de API documentatie van ‘the Datatank’ op de pagina ‘Consuming Data’ (http://docs.thedatatank.com/4.0/ consuming_data).

5.6 MATURITEITSMODEL VOOR OPEN DATA Gegeven de scenario’s voor en de minimale vereisten bij het ontsluiten van brongegevens als Open Data zoals hiervoor beschreven, kunnen we steeds verbeteringen aanbrengen en groeien in consistentie en kwaliteit van de gegevens. Om dit inzichtelijk te maken, introduceren we hier een vrijblijvend maturiteitsmodel waar in graadmeters staan beschreven om een hogere vorm van kwaliteit te bewerkstelligen. Het 5-sterren maturiteitsmodel (http://5stardata.info/) voor het publiceren van Open Data geeft al een aantal kenmerken voor de kwaliteitsbewaking aan. We hebben dit model uitgebreid met een aantal extra parameters waaraan de Open Data sets moeten voldoen. Deze criteria zijn een toepassing bij al de regels die in dit document zijn opgesomd. Uiteraard moet een instantie niet meteen voor het 5-sterren model gaan, op dit moment ligt de grens op 3 sterren. Het overzicht van de verschillende maturiteitsniveaus is hieronder kort beschreven en daarna wordt per stermodel verder ingegaan hoe dit te realiseren. Maturiteitsniveau

Originele uitleg (Engels)

Bijkomende parameters

make your stuff available on the Web (whatever format) under an open license

Informatie zonder fouten en met basis kwaliteitschecks (per dataset) publiceren op het Vo Open Data platform, aangevuld met alle metadata vereisten

make it available as structured data (e.g., Excel instead of image scan of a table)

Idem 1 ster, maar nu ook met minimale consistentie checks over de data sets heen (i.e. op niveau van publicerende instantie)

use non-proprietary formats (e.g., CSV instead of Excel)

Idem 2 sterren, maar informatie wordt ontsloten onder een data management proces met bewaking van de gestelde kwaliteit en consistentie checks (i.e. op niveau van publicerende instantie)

use URIs to identify things, so that people can point at your stuff

Idem 3 sterren, informatie wordt gepubliceerd op basis van een Data Quality process, met de URI criteria zoals in een afzonderlijk document beschreven (minstens op instantie niveau)

link your data to other data to provide context

Idem 4 sterren, informatie wordt gepubliceerd op basis van Enterprise Data Quality met EA Governance, met de LOD criteria zoals in dit document beschreven (minstens op instantie niveau, liefst op algemeen niveau)


30


6

PUBLICEER UW DATASET(S)

Voor het publiceren van Open Data zijn niet veel technische investeringen nodig. Dit neemt echter niet weg dat de instantie moet zorgen dat de nodige technische middelen voorzien zijn om de Open Data beschikbaar te maken voor het publiek. Cruciaal hierbij is de keuze op welke wijze Open Data ter beschikking zal gesteld worden.

6.1 VOORAFGAANDE TECHNISCHE TOETSING Elke instantie moet er voor zorgen dat de nodige technische middelen voorzien zijn om de Open Data beschikbaar te maken voor het publiek. Het gaat hierbij om: Keuze van het domein: de instantie kan ervoor kiezen om haar eigen website te gebruiken voor de beschikbaarstelling van de data, of zij kan dit doen via een aparte website met een eigen domeinnaam. Keuze van de hosting: de instantie moet bepalen of de data op haar eigen servers wordt bewaard en toegankelijk gemaakt, dan wel of zij hiervoor gebruik maakt van servers van een derde partij. Keuze van de functionaliteiten: er moet worden nagegaan welke databank zal worden gebruikt; of bv. een forum of een betalingsmodule nodig is. Een schatting moet worden gemaakt van de nodige serverruimte, het totale dataverbruik; de nodige snelheid. Het beheer van de website en / of het portaal: iemand moet worden aangesteld die de website of het portaal beheert. Daarbij moet ook bepaald worden welke graad van beschikbaarheid men wil garanderen, en welk niveau van monitoring en beveiliging van de website nodig is. Het onderhoud van de diensten: indien data wordt beschikbaar gesteld via services, moet iemand worden aangesteld die de beschikbaarheid, functionaliteit en performantie van de diensten opvolgt en garandeert. Wanneer de instantie ervoor kiest om de data niet zelf beschikbaar te maken, maar deze taak toe te vertrouwen aan een andere instantie of derde partij die fungeert als verstrekker (vb. de verspreiding door het AGIV van geografische data toebehorend aan andere instanties), moeten deze technische beslissingen worden genomen in samenspraak tussen de instantie en de verstrekker.

Aanbeveling 12: voorzie de nodige technische middelen om Open Data beschikbaar te maken.

6.2 VIA EIGEN WEBSITE (DATADUMP OF API) OF UPLOAD NAAR CKAN De instantie maakt de keuze of zij haar Open Data beschikbaar maakt via de eigen officiële website, via een aparte website, of via de diensten van een derde partij-verstrekker. Om de vindbaarheid van de data voor de gebruiker te vergroten, is het belangrijk dat daarbij telkens een verwijzing naar de data wordt opgenomen op het Vlaams Open Data Platform (ckan).

Aanbeveling 13: maak de data beschikbaar via de eigen website of de website van een derde partij-verstrekker en plaats een link naar de vindplaats op het Vlaams Open Data Platform (ckan). Nadat de instantie beslist heeft hoe zij haar Open Data beleid zal inrichten, kan zij starten met de praktische uitvoering van de genomen beslissingen. Het betreft onder meer het verstrekken van de nodige informatie aan de potentiële gebruikers.

6/ Publiceer uw dataset(s)

31


7

DOCUMENTEER UW DATASET(S)

U hebt uw dataset nu gepubliceerd als datadump of via een API. Houd er rekening mee dat het voor een potentiële gebruiker van uw data niet altijd gemakkelijk is om te evalueren of uw data mogelijks relevant zijn. Om die reden is het aangewezen binnen uw organisatie een contactpunt ‘Open Data’ aan te duiden en aan de potentiële gebruiker van de data een contactadres voor informatie en feedback mee te delen. Bovendien is het van belang de potentiële gebruiker te informeren over de gebruiksvoorwaarden, de (eventuele) vergoedingen en de garanties betreffende de beschikbaarheid. Tot slot is het van belang ook een pagina (of bijsluiter) te publiceren die de gepubliceerde gegevens van de nodige context voorziet. Hierbij is het aangewezen deze informatie ter beschikking te stellen in meerdere talen.

7.1 ‘OPEN DATA’ CONTACTPUNT Hoewel het openstellen van overheidsdata geen grote taak is en enkel een beperkte inspanning en tijdsinvestering zal vragen van de instantie, kan de instantie deze taak efficiënter laten verlopen door het aanwijzen van één persoon of dienst die verantwoordelijk is voor het Open Data beleid binnen de instantie. Deze verantwoordelijkheid wordt gewoonlijk opgenomen door de persoon of dienst die verantwoordelijk is voor het interne informatiebeleid van de instantie, zodat een gestroomlijnd beleid kan worden gevoerd. Indien een andere persoon of dienst wordt aangewezen, houdt deze nauw contact met de verantwoordelijke voor het interne informatiebeleid. Naast de functie van beleidsverantwoordelijke voor Open Data, wordt ook aangeraden een contactpunt Open Data aan te duiden, al kan dit natuurlijk dezelfde persoon of dienst zijn. Deze persoon of dienst kan op drie manieren een rol spelen als aanspreekpunt rond Open Data. Ten eerste is een Open Data contactpunt intern belangrijk voor de stroomlijning van het Open Data beleid, maar kan het ook grote voordelen bieden bij de organisatie van datastromen binnen de instantie zelf. Doordat het contactpunt op de hoogte is van welke data er binnen de instantie aanwezig is, kan het ervoor zorgen dat data maar één keer wordt geproduceerd of aangekocht en verder wordt gedeeld binnen de instantie. Ten tweede kan het contactpunt zorgen voor een directe relatie met de Vlaamse overheid, waardoor de instantie haar vragen omtrent Open Data aan de Vlaamse overheid eenvoudig kan stellen, en andersom de Vlaamse overheid ook weet tot wie zij zich kan wenden om ondersteuning te bieden bij het Open Data beleid. Ten derde heeft het Open Data contactpunt een belangrijke functie ten opzichte van de burger: ook al is de data eenvoudig beschikbaar, het blijft immers steeds mogelijk dat burgers nog bepaalde vragen hebben omtrent het format van de data, de herkomst ervan, e.d. Hiervoor is het belangrijk dat de burger duidelijk weet waar hij terecht kan met dergelijke vragen.15

Aanbeveling 14: duid een persoon of dienst aan die verantwoordelijk is voor het Open Data beleid in de instantie. Creëer een Open Data contactpunt voor communicatie binnen de instantie, met de Vlaamse overheid en met de burger.

7.2 CONTACTADRES VOOR INFORMATIE EN FEEDBACK Ook al is een Open Dataset duidelijk omschreven in de bijbehorende metadata, de hergebruiker zal soms nog steeds nood hebben aan bijkomende informatie, bijkomende vragen willen stellen of fouten of onvolkomenheden in de data willen melden. Hiervoor heeft de hergebruiker uiteraard een adres nodig waar hij terecht kan voor dergelijke vragen of meldingen. De instantie kan hiervoor zorgen door een e-mail adres op de website te plaatsen waar men terecht kan voor informatie en/of feedback, of een webformulier te creëren dat online kan worden ingevuld. De beantwoording van de vragen en/of opmerkingen maakt deel uit van de taak van het ‘Open Data contactpunt’. Om het gebruik van de data, en in het bijzonder het leveren van feedback aan te moedigen, is het belangrijk dat de vragen en/of opmerkingen van de burger op korte termijn worden beantwoord.

Aanbeveling 15: plaats een contactadres of web formulier op de website voor het vragen van verdere informatie of het geven van feedback door de hergebruikers van de data.

15

Cf. infra.

7/ Documenteer uw dataset(s)

32


7.3 GEBRUIKSVOORWAARDEN In de voorbereidende fase heeft de instantie gekozen voor een bepaalde licentie onder dewelke zij haar data wil beschikbaar stellen. Om zo veel mogelijk harmonisatie en vereenvoudiging te bewerkstelligen, wordt bij voorkeur gebruik gemaakt van de Vlaamse modellicenties. Niet alleen wordt fragmentatie vermeden en wordt het gebruik van open data optimaal gestimuleerd, ook zorgt dit ervoor dat de instantie niet zelf moet investeren in het opstellen van eigen gebruiksvoorwaarden. Wanneer de Vlaamse modellicenties worden gebruikt, moet de instantie op een duidelijk zichtbare plaats aangeven dat de data worden beschikbaar gemaakt onder de toepasselijke ‘Vlaamse Open Data Licentie’, met daarbij een link naar de vindplaats van de licentie op de website van de Vlaamse overheid. Indien de instantie wenst dat de hergebruikers een specifieke bronvermelding toepassen, moet zij deze ook toevoegen. Voorbeelden van een licentiebepaling worden hieronder weergegeven voor de verschillende mogelijke licenties: “[Naam van de dataset] wordt ter beschikking gesteld onder een CC0 verklaring. De volledige tekst van de Engelse verklaring vindt u op http://creativecommons.org/publicdomain/zero/1.0/legalcode. Een vertaling van de CC0 verklaring vindt u op http://creativecommons.org/publicdomain/zero/1.0/ “[Naam van de dataset] is eigendom van [naam instantie]. [Naam van de dataset] wordt beschikbaar gemaakt onder de Vlaamse Gratis Open Data Licentie [link naar de licentie]. Bij elk gebruik moet de volgende bronvermelding worden opgenomen: [vereiste bronvermelding]. Voor verdere informatie, gelieve u te wenden tot [contact adres]”. “[Naam van de dataset] is eigendom van [naam instantie]. [Naam van de dataset] wordt beschikbaar gemaakt onder de Vlaamse Open Data Licentie tegen Billijke Vergoeding [link naar de licentie]. Bij elk gebruik moet de volgende bronvermelding worden opgenomen: [vereiste bronvermelding]. Voor verdere informatie, gelieve u te wenden tot [contact adres]”. “[Naam van de dataset] is eigendom van [naam instantie]. [Naam van de dataset] wordt beschikbaar gemaakt voor niet-commercieel gebruik onder de Vlaamse Gratis Open Data Licentie [link naar de licentie] en voor commercieel gebruik onder de de Vlaamse Open Data Licentie tegen Billijke Vergoeding [link naar de licentie]. Bij elk gebruik moet de volgende bronvermelding worden opgenomen: [vereiste bronvermelding]. Voor verdere informatie, gelieve u te wenden tot [contact adres]”. Door op een specifieke manier te verwijzen naar de Vlaamse Open Data Licentie, kan worden verkregen dat Google en andere zoekmotoren weten dat naar een licentie wordt verwezen, en dat het materiaal onder die licentie wordt ter beschikking gesteld.16 Hiervoor moet in html worden verwezen naar de Open Data Licentie via het “rel=license” attribuut in de link naar de licentie. De modellicenties zullen naast de juridische tekst ook in een machine-leesbare versie beschikbaar worden gemaakt, zodat Google, andere zoekmotoren en webcrawlers de licentie (en de voorwaarden ervan) ook automatisch kunnen herkennen.

Aanbeveling 16: gebruik de modellicenties van de Vlaamse overheid en plaats een link ernaar in de licentiebepaling bij de data, met gebruik van de “rel=licence” attribuut.

7.4 VERGOEDINGEN Hierboven werd reeds uiteengezet welke mogelijkheden de instanties hebben om voor hun open data een billijke vergoeding te vragen. Bij de implementatie hiervan is het essentieel dat de hergebruiker een duidelijk beeld krijgt van hoeveel hij zal moeten betalen voor het gebruik van de data, en dat de betaling snel en op een transparante wijze kan gebeuren. Het bedrag van de billijke vergoeding moet op een duidelijke plaats bij de dataset worden aangegeven. Wanneer dit bedrag bijvoorbeeld een vast bedrag is voor de volledige dataset, kan het bedrag worden vermeld naast de dataset. Wanneer het bedrag wordt berekend in functie van bijvoorbeeld het volume van de data dat wordt gebruikt, moet op een transparante wijze de berekening van de vergoeding worden uiteengezet. Dit kan bijvoorbeeld gebeuren door in de metadata of bij de verwijzing naar de licentie een link naar een informatiefiche over de vergoeding te voorzien. Deze informatiefiche maakt geen deel uit van de licentie, maar wordt als “bijsluiter” toegevoegd. Op deze manier kan zij op een meer flexibele manier worden gewijzigd. Uiteraard moet wel rekening worden gehouden met de rechtszekerheid van de gebruiker, en mag de prijs enkel worden aangepast mits een duidelijke en tijdige waarschuwing. De informatie over de vergoeding moet omvatten: de berekeningswijze en de motivatie van de gevraagde vergoeding; en de vergoedingswijze. Het vragen van een billijke vergoeding houdt ook in dat de hergebruiker pas toegang krijgt tot de data wanneer hij betaald heeft. Bijgevolg moet een registratiesysteem worden opgezet, waarbij de hergebruiker het paswoord voor toegang tot de data of de dienst pas krijgt wanneer de betaling werd ontvangen door de instantie. De bepaling hieromtrent op de website zou er als volgt kunnen uitzien:

16

Zie http://microformats.org/wiki/rel-license.


33


“Om toegang te krijgen tot de data, gelieve het aanvraagformulier [link naar online formulier of word-formulier dat moet worden doorgemaild] in te vullen en het bovenstaande bedrag te storten op rekeningnummer [...] met vermelding [...]. Zodra de betaling werd ontvangen, krijgt u een paswoord toegestuurd waarmee u toegang krijgt tot de gegevens”. De instantie kan ook overwegen om een betaling via kredietkaart te aanvaarden, waarna onmiddellijk na de verificatie van de betaling toegang kan gegeven worden tot de data. Aangezien de hergebruiker er op moet kunnen vertrouwen dat de prijs op de website de juiste is, moet telkens wanneer de prijs eventueel zou worden gewijzigd duidelijk worden aangegeven vanaf en tot wanneer de prijzen geldig zijn.

Aanbeveling 17: indien een vergoeding wordt gevraagd, toon de gebruiker op een duidelijke wijze hoeveel hij moet betalen en hoe hij de betaling moet uitvoeren om toegang te krijgen tot de data of dienst.

7.5 GARANTIES BETREFFENDE DE BESCHIKBAARHEID Wanneer de data online via een bulk download worden ter beschikking gesteld, is het natuurlijk belangrijk dat deze data effectief beschikbaar zijn en dat er geen ‘dode linken’ zijn of dat de website niet online is. De continuïteit wordt echter nog veel belangrijker wanneer de data via een dienst wordt beschikbaar gemaakt en bijvoorbeeld via een API of een plugin wordt geïntegreerd in een dienst of applicatie van de gebruiker. Daarom is het belangrijk dat de gebruiker wordt geïnformeerd over het ‘service level’ van de dienst die wordt verschaft. Wanneer de data via een derde partij-verstrekker wordt ter beschikking gesteld, is het belangrijk dat het mogelijke ‘service level’ wordt afgestemd tussen de instantie en de verstrekker, en zal de verstrekker de aangewezen partij zijn om de service level engagement op te stellen. Het is in beginsel niet vereist om deze service level engagement in de licentie te incorporeren. Aangeraden wordt dat de instantie de informatie eerder verschaft als een “bijsluiter” of een “informatiefiche” bij de dienst, via een link naar de betrokken informatie of via de metadata, zodat deze geen deel uitmaakt van de bindende licentie en ook eenvoudiger eenzijdig kan gewijzigd worden door de instantie wanneer de omstandigheden erom vragen. De volgende elementen kunnen worden opgenomen in deze informatiefiche: Een inspanningsverbintenis om de dienst permanent te laten functioneren, maar geen garantie op permanente 24/7 beschikbaarheid (eventueel een garantie van bv. 90% beschikbaarheid); Een waarschuwing dat de service stopgezet kan worden (bij voorkeur mits een voldoende lange “waarschuwingstermijn” of overgangsperiode; Een indicatie van de responstijd van de service; Een indicatie van de capaciteit van de dienst betreffende vb. aantal gelijktijdige verzoeken; Een waarschuwing dat de toegang tot de dienst zal worden afgesloten ingeval van overbelasting of misbruik door een gebruiker, met een omschrijving van wat als overbelasting wordt beschouwd (vb. 95% van de requests komt van één gebruiker). Het is niet verplicht om dergelijk service level engagement op te nemen. Bovendien heeft dergelijke informatie ook niet steeds evenveel zin of belang: wanneer een link naar een bulk download niet meer werkt, zal het service level immers enkel inhouden dat de instantie de link corrigeert wanneer zij op de hoogte gebracht wordt van het probleem. In elk geval, wanneer geen service level engagement wordt vastgelegd voor een distributiekanaal van de data, wordt geacht dat de instantie als een goede huisvader alle redelijke inspanningen levert om de data te verschaffen.

Aanbeveling 18: indien de data via een dienst wordt beschikbaar gemaakt, plaats een “informatiefiche” of service level engagement bij de dienst met uitleg over de performantie van de dienst en de verwachtingen die de gebruiker mag hebben van de werking van de dienst.

7.6 BIJSLUITER Enkele voorbeelden van zulk een bijsluiter pagina: http://aps.vlaanderen.be/sgml/largereeksen/704.htm met een toelichting bij de dataset “Participatie aan Pop -of Rockconcert door Vlamingen naar geslacht” http://epp.eurostat.ec.europa.eu/portal/page/portal/population/introduction voor een toelichting bij “EU population statistics”. Voor een eindgebruiker zijn er immers een aantal zaken van belang om uw data goed te kunnen verstaan.


34


7.6.1 DE DATA ZELF Beschrijf goed welke entiteiten er in uw dataset worden beschreven (personen, organisaties, events, …). Beschrijf ook de scope en de granulariteit van uw dataset, zowel op geografisch vlak als in de tijd. U heeft b.v. data m.b.t. gans Vlaanderen maar opgesplitst per provincie. U hebt deze data over de jaren 2009 t.e.m. 2012 met een opdeling per kwartaal. Licht verder toe welke eigenschappen en relaties u gebruikt in de dataset om de entiteiten te beschrijven. Beschrijf m.a.w. uw logisch datamodel. Maakt u gebruik van codes, zorg dan ook dat de betekenis daarvan gekend is.

7.6.2 HET PROCES Verder draagt het beschrijven van waarom deze data zijn verzameld en de daarbij gebruikte processen bij tot het geven van context. Beschrijf daarom wie de data verzamelt, met welke frequentie en wie de data beheert. Leg ook uit waarvoor en hoe de data worden gebruikt. Som eventueel de processen op die gebruik maken van deze data.

Aanbeveling 19: maak voor elke van uw datasets een begeleidende pagina die in duidelijk verstaanbare taal aangeeft waarover de data gaan, waarom ze zijn verzameld en waarvoor ze gebruikt worden.

7.7 TAAL VAN DE WEBSITE Uiteraard blijft de eerste taal waarin de data, diensten, licenties en informatie moeten worden getoond het Nederlands. Gelet op de groeiende nood aan data voor grensoverschrijdende toepassingen, wordt het echter steeds belangrijker om de data portalen en websites rond open data ook in andere talen ter beschikking te stellen. Voor zover mogelijk, wordt de instanties aangeraden om dan ook een minimale informatievoorziening in het Engels te organiseren. Om hieraan tegemoet te komen, zal de Vlaamse overheid ook een Engelse versie van de Open Data Licenties ter beschikking stellen waarnaar door de instanties kan worden verwezen.

Aanbeveling 20: plaats informatie over de data ook in het Engels op de website, en verwijs naar de Engelse versie van de Vlaamse Open Data licenties.


35


8

MAAK UW DATASET(S) VINDBAAR

U hebt uw dataset gepubliceerd maar wil ze nu ook beter vindbaar maken. Daarvoor heeft de Vlaamse Overheid een voorziening getroffen, het Open Data portaal dat een “gouden gids” functie aanbiedt. Dit Open Data portaal maakt gebruik van CKAN software (http://ckan.org/). Om uw dataset kenbaar te maken op dit Open Data portaal moet u een metadata fiche invullen. We beschrijven eerst de mogelijke metadata en daarna leggen we uit hoe die metadata fiche in te vullen in CKAN.

8.1 METADATA 8.1.1 WAT IS METADATA? Volgens Wikipedia is metadata de term om de karakteristieken van bepaalde gegevens te beschrijven. Het zijn dus eigenlijk data over data. De metadata bij een bepaald document (de gegevens) kunnen bijvoorbeeld zijn: de auteur, de datum van schrijven, de uitgever, het aantal pagina’s en de taal waarin de gegevens zijn opgesteld. Het expliciet opslaan van metadata bij de data waar het betrekking op heeft, heeft als voordeel dat de data makkelijker gevonden kan worden. Zo kan men in een zoekmachine die gebruik maakt van metadata bijvoorbeeld onmiddellijk zoeken naar documenten geschreven door een bepaalde auteur. Met full text-zoeken, dus zonder gebruik te maken van metadata, is dit moeilijker doordat ieder document waarin de naam van de auteur voorkomt gevonden wordt. Dit kunnen er veel meer zijn dan de documenten die daadwerkelijk door de persoon geschreven zijn. Voor het zoeken (en vinden) van Open Data wordt sterk gebruik gemaakt van metadata. In alle Open Data platformen zal er een laag van metadata nodig zijn om de bewuste dataset vindbaar te maken, zowel voor de cataloog zelf als op geaggregeerde platformen (bv. Van EU). Buiten het zoeken op een lokaal platform, biedt metadata ook de sleutel om Open Data sets te gaan zoeken op andere Open Data platformen. Daarom zijn er richtlijnen opgesteld welke metadata velden er voor de Open Data sets van Vlaanderen nodig zijn. We gebruiken een verfijning van het op Europees niveau gemaakte DCAT application profile for data portals in Europe (https://joinup.ec.europa.eu/asset/dcat_application_profile/description) gebaseerd op DCAT (Data Catalog Vocabulary, zie http://www.w3.org/TR/vocab-dcat/).

8.1.2 HOE METADATA OPMAKEN De creatie van metadata voor Open Data sets kan enerzijds worden ondersteund door (semi-) automatische processen, bijvoorbeeld: Document eigenschappen gegenereerd in (office)-hulpprogramma’s, zoals Aanmaakdatum; Ruimtelijke en temporele informatie zoals vastgelegd door camera’s, sensoren...; Informatie vanuit publicatie werkstroom, bijvoorbeeld de locatie of URL van de bron. Anderzijds, sommige kenmerken vereisen menselijke tussenkomst of opmaak: Waar gaan de gegevens over (eventueel gelinkt aan een onderwerp of bron van informatie; Hoe kan deze dataset gebruikt worden (bv. link met een modellicentie); Waar kan je meer informatie over de bron zelf vinden (bv. link naar een website of ander document); Attributen die de kwaliteit van de informatie beschrijven (bv. draft, ter review, nog niet gevalideerd, tijdelijk). Ook de aanpak voor het onderhouden van metadata moet aangepast zijn aan de gepubliceerde gegevens. Als de gegevens niet veel wijzigen, kunnen metagegevens relatief stabiel blijven of in bulk periodiek aangepast worden (bv. e-mail adres voor feedback lus). Als gegevens vaak veranderen (bv. real-time sensorgegevens), dan moeten de metagegevens nauw worden gekoppeld aan de werkstroom gegevens en wijzigingen moeten vrijwel ogenblikkelijke worden doorgevoerd. Verder zijn er continue veranderingen rondom de Open Data set die in de meta data blijvend moeten weerspiegeld worden: Organisaties durven wel eens veranderen, in elkaar opgaan of verantwoordelijkheden kunnen naar een andere organisatie of instantie verhuizen;

8/ Maak uw dataset(s) vindbaar

36


Nieuwe applicaties kunnen Open Data sets met elkaar verbinden en dus extra metadata gegevens nodig hebben of de noodzaak voor afstemming van metadata door verschillende instanties sturen (consistentie van metadata); Metadata evolutie: de huidige voorschriften zijn minimaal en zullen blijven evolueren. Dit drijft de noodzaak om de meta data voortdurend in de gaten te houden en aan te passen met de evolutie, maar we willen dit zo pragmatisch mogelijk inzetten zodat dit geen (permanente) aanslag op het budget pleegt.

8.1.3 METADATA OVERZICHT Hieronder vindt u het over de verschillende overheden (lokaal, gemeenschap, federaal) heen afgesproken DCAT applicatie profiel met het overzicht van de voorziene metadata. Er worden metadata voorzien op het niveau van de dataset zelf en dan ook nog op het niveau van de fysische dumps of de API, distributie genoemd. Per niveau wordt er dan nog een onderscheid gemaakt tussen verplichte, aanbevolen en optionele velden. Voor elk veld worden de volgende properties aangegeven: naam, uri of de unieke identifier, de waarde(n) die het veld kan bevatten, een uitleg hoe het veld te gebruiken en het aantal keren dat het veld mag/kan voorkomen (de cardinaliteit).

Dataset Verplichte velden voor een dataset zijn: Property

URI

Range

Usage note

Card

Description

dct:description

rdfs:Literal

This property contains a free-text account of the Dataset. This property can be repeated for

1..n

parallel language versions of the description.

Title

dct:title

rdfs:Literal

This property contains a name given to the Dataset. This property can be repeated for

1..n

parallel language versions of the name. Use of Title Case.

Aanbevolen velden voor een dataset zijn: Property

URI

Range

Usage note

Card

contact point

dcat:contactPoint

v:VCard (will

This property contains contact information that can be used for flagging errors in the

0..n

be deprecated

Dataset or sending comments

in new vCard dataset distri-

dcat:distribution

bution

standard.)

Initially only email address used.

dcat:Distribu-

This property links the Dataset to an available Distribution.

0..n

tion

keyword/ tag

dcat:keyword

rdfs:Literal

This property contains a keyword or tag describing the Dataset.

0..n

Publisher

dct:publisher

foaf:Agent

This property refers to an entity (organisation) responsible for making the Dataset available.

0..1

String can be used; will be transformed into URI. theme/ cate-

dcat:theme,

gory

subproperty of

skos:Concept

This property refers to a category of the Dataset. A Dataset may be associated with multiple

0..n

themes.

dct:subject Existing domains used on portals can be supplied as string. Will be transformed into URI’s. landing page

dcat:landingPage

foaf:Document

This property refers to a web page that provides access to the Dataset, its Distributions

0..1

and/or additional information. Is the link to the leaflet ‘bijsluiter’ page. Language

dct:language

dct:Linguis-

This property refers to a language of the Dataset. This property can be repeated if there are

ticSystem

multiple languages in the Dataset.

0..n

One of (‘en’, ‘nl’, ‘fr’, ‘de’, ‘zxx’). Will be translated into URI’s.


37


Property

URI

Range

Usage note

Card

release date

dct:issued

rdfs:Literal

This property contains the date of formal issuance (e.g., publication) of the Dataset.

0..1

This property contains the most recent date on which the Dataset was changed or modified.

0..1

typed as xsd:dateTime update/ modi-

dct:modified

fication date

rdfs:Literal typed as xsd:date or xsd:dateTime

Optionele metadata voor een dataset zijn: Property

URI

Range

Usage note

Card

conforms to

dct:conformsTo

dct:Standard

This property refers to an implementing rule or other specification.

0..n

Frequency

dct:accrualPerio-

dct:Frequency

Example: URI of OSLO. This property refers to the frequency at which Dataset is updated.

0..1

dicity Will be using the value vocabulary supplied at http://purl.org/cld/freq/ dutch translations of the labels: * Jaarlijks * Tweejaarlijks * Tweemaandelijks * Tweewekelijks * Doorlopend * Dagelijks * Onregelmatig * Maandelijks * Driemaandelijks * Halfjaarlijks * Halfmaandelijks * Halfweeklijks * Drie keer per maand * Drie keer per week * Drie keer per jaar * Driejaarlijks * Wekelijks Identifier

dct:identifier

rdfs:Literal

This property contains the main identifier for the Dataset, e.g. the URI or other unique

0..n

identifier in the context of the Catalogue. other iden-

adms:identifier

adms:Identifier

tifier spatial/

This property refers to a secondary identifier of the Dataset, such as MAST/ADS, DataCite,

0..n

DOI, EZID or W3ID. dct:spatial

dct:Location

This property refers to a geographic region that is covered by the Dataset.

0..n

geographical needs further elaboration (NGI, AGIV, …)

coverage temporal

dct:temporal

coverage

dct:PeriodOf-

This property refers to a temporal period that the Dataset covers.

0..n

Time Use: schema:startDate schema:endDate.

Version

schema:version

rdfs:Literal

This property contains a version number or other version designation of the Dataset.

0..1

Use semantic versioning: MAJOR.Minor.patch version notes

adms:versionNotes

rdfs:Literal

This property contains a description of the differences between this version and a previous

0..1

version of the Dataset.

Distributie Hier gaat het om de metadata toe te kennen aan de distributie (dump of api).


38


Verplichte velden voor een distributie zijn: Property

URI

Range

Usage note

Card

access URL

dcat:accessURL

rdfs:Resource

This property contains a URL that gives access to a Distribution of the Dataset. The re-

1..n

source at the access URL may contain information about how to get the Dataset.

Aanbevolen velden voor een distributie zijn: Property

URI

Range

Usage note

Card

Description

dct:description

rdfs:Literal

This property contains a free-text account of the Distribution. This property can be repea-

0..n

ted for parallel language versions of the description. Format

dct:format

dct:MediaType-

This property refers to the file format of the Distribution.

0..1

OrExtent Use file extension in lower case. Licence

dct:license

dct:LicenseDocu-

This property refers to the license under which the Distribution is made available.

0..1

ment For Flemish government: use one of the 4 licenses. byte size

dcat:byteSize

rdfs:Literal

This property contains the size of a Distribution in bytes.

0..1

typed as xsd:deTitle

dct:title

cimal

In bytes.

rdfs:Literal

This property contains a name given to the Distribution. This property can be repeated for

0..n

parallel language versions of the description. release date

dct:issued

This property contains the date of formal issuance (e.g., publication) of the Distribution.

0..1

rdfs:Literal ty-

This property contains the most recent date on which the Distribution was changed or

0..1

ped as xsd:date

modified.

rdfs:Literal typed as xsd:date or xsd:dateTime

update/ modi-

dct:modified

fication date

or xsd:dateTime

Optionele properties voor een distributie zijn: Property

URI

Range

Usage note

Card

Checksum

????

rdfs:Literal

This property contains the checksum

0..1

download

dcat:downloa-

rdfs:Resource

This property contains a URL that is direct link to a downloadable file in a given format.

0..n

URL

dURL

media type

dcat:mediaType,

dct:MediaType-

This property refers to the media type of the Distribution if this is defined in IANA.

0..1

subproperty of

OrExtent

.

Use mimetype. Will be transformed into URI.

dct:format Rights

dct:rights

dct:RightsState-

This property refers to a statement that specifies rights associated with the Distribution.

0..1

ment Use to make the rights of the publisher explicit. Status

adms:status

skos:Concept

This property refers to the maturity of the Distribution

0..1

One of: ‘completed’,’under development’, ‘deprecated’, ‘withdrawn’. Will be transformed into URI.

Aanbeveling 21: Om een vlotte uitwisseling van dataset beschrijvingen mogelijk te maken raden wij aan gebruik te maken van de hierboven opgesomde verplichte en aanbevolen velden uit het op Belgisch niveau afgesproken profiel van de DCAT standaard.

8.2 METADATA TOEVOEGEN IN CKAN Welke metadata kunnen toegevoegd worden gebruik makend van de “Creëer dataset” wizard in CKAN? Per veld/eigenschap geven we aan het label zoals getoond in de interface, de naam van het veld in CKAN, het overeenkomstig veld uit de “DCAT Application Profile for data portals in Europe specification” en de toegelaten/verwachte waarden voor dit veld.


39


Maar vooraleer u dit kan doen, moet u eerst op CKAN een account aanmaken.

8.2.1 ACCOUNT AANMAKEN Klik rechts bovenaan ‘registreer’ en dan komt u in volgend scherm.

Belangrijk: de gebruikersnaam mag alleen bestaan uit kleine alfanummerieke (ascii) karakters of ‘-_’. Bij succes krijgt u dit scherm te zien:

8.2.2 DATASET CREËREN Voor het creëren van een dataset moet u aangelogd zijn, gebruik makend van uw account gegevens. Wanneer u aangelogd bent, klik dan de button ‘Dataset aanmaken’.

Pagina: Creëer dataset U krijgt eerst een pagina om uw dataset te beschrijven. Dit zijn de velden die daarbij worden aangeboden: Label in pagina

CKAN field

DCAT mapping

waarden

TITEL

Title

dct:title (Dataset)

string (titlecase)

OMSCHRIJVING

Notes

dct:description (Dataset)

String

TAGS

Tags

dcat:keyword (Dataset)

multiple met separator ‘,’

LICENTIE

License

dct:license (Dataset)

één van de dropdown lijst

ORGANISATIE

owner_org

dct:publisher



40


In dit scherm geeft u de algemene kenmerken van de dataset in: de naam (bestaat uit kleine alfanummerieke (ascii) karakters of ‘-_’), een omschrijving, trefwoorden en de licentie (één te kiezen uit de aangeboden dropdown) waaronder de data ter beschikking staan. Het resultaat van zo’n editeeractie ziet u in het volgende scherm:

Daarna gaat u naar het volgende scherm “Data toevoegen”.

Pagina: Data toevoegen De volgende pagina laat u toe uw distributie(s) toe te voegen. Dit zijn de velden die u hierbij kan gebruiken: Label in pagina

CKAN field

DCAT mapping

waarden

BRON

url

accessURL (Distribution)

url

NAAM

Name

dct:title (Distribution)

string (titlecase)

OMSCHRIJVING

description

dct:description (Distribution)

String

FORMAAT

Format

dct:format (Distribution)

file extensie b.v. csv, xml, json


41


Er zijn 3 types van distributie en elk krijgt zijn eigen metadata scherm:

Scherm 2.1: data - link naar een al gepubliceerde datadump Hebt u al een datadump gepubliceerd, dan kiest u boven in dit scherm voor ‘Link naar een bestand’. U krijgt dan volgend scherm:

Het belangrijkste veld is “bron” waar u het (http) adres ingeeft waar de data kunnen gevonden/gedownload worden. Verder vult u bij formaat de file extensie in in lowercase (csv, xml, json, xls, xlsx, …).

Scherm 2.2: data via API Publiceert u uw data m.b.v. een API, dan klikt u op bovenaan op de keuze ‘link naar een api’. U krijgt dan volgend scherm:

In het bron veld geeft u aan op welk http adres de API aanspreekbaar is. Verder geeft u in het omschrijving veld de API documentatie in of waar deze te vinden is.


42


Scherm 2.3: upload van een datadump Een derde mogelijkheid bestaat erin dat u lokaal een datadump hebt maar deze nog wil publiceren. Voor dit publiceren wenst u gebruik te maken van CKAN. U kiest dan voor de optie “upload een bestand”. U laadt dan uw lokale file op in CKAN.

De overige metadata zijn gelijklopend aan die van de andere keuzes.

Als u de distributie(s) hebt ingegeven, gaat u naar het volgende (3e) scherm.

Pagina: Aanvullende data Deze pagina laat u toe om bijkomende metadata toe te voegen.


43


Dit zijn de velden die standaard worden aangeboden: Label in pagina

CKAN field

DCAT mapping

waarden

ZICHTBAARHEID

Private

—


AUTEUR

Author

—

String

AUTEUR EMAIL

author_email

—

Email

BEHEERDER

maintainer

—

String

BEHEERDER EMAIL

maintainer_email

—

Email

GROEP TOEVOEGEN

Groups

dcat:theme


Verder laat CKAN toe extra metadata toe te voegen m.b.v. Custom fields.

Custom: vrije velden Dit zijn vrij toe te voegen key/value paren. Wij stellen volgende mogelijkheden voor die in lijn zijn met het hierboven besproken DCAT profiel: Key

DCAT mapping

Waarden

Taal

dct:language

één van (nl, fr, de, en)

update frequentie

dct:accruelPeriodicity

één van het lijstje met frequenties (bij benadering) (cf. infra)

datum publicatie

dct:issued

datum (xsd:date format)

laatste gewijzigd

dct:modified

datum (xsd:date format)

Versie

—

MAJOR.Minor.patch (cf. semantic versioning)

versie nota’s

adms:versionNotes

String

dekking in tijd

dct:temporal

string, voorbeeld: 1992, 1995, 1998, 2001, 2004, 2007, 2010

geografische dekking

dct:spatial

string, voorbeeld: Vlaams Gewest + Brussel

compliant met standard

dct:conformsTo

cf. lijstje met voorbeelden van standaarden infra

aantal bytes

dcat:byteSize

de grootte van de distributie in bytes

Mediatype

dcat:mediaType

een MIME-type zoals gedefinieerd door IANA

Rechten

dct:rights

een string die de rechten van de publisher beschrijft

Status

adms:status

één van (‘completed’,’under development’, ‘deprecated’, ‘withdrawn’). Voor toelichting

Metadata waarde specificaties Lijstje met frequenties: Jaarlijks


44


Tweejaarlijks Tweemaandelijks Tweewekelijks Doorlopend Dagelijks Onregelmatig Maandelijks Driemaandelijks Halfjaarlijks Halfmaandelijks Halfwekelijks Drie keer per maand Drie keer per week Drie keer per jaar Driejaarlijks Wekelijks Lijstje (niet-exhaustief) met standaarden Naam

Organisatie

Link

core business vocabulary

ISA

https://joinup.ec.europa.eu/asset/core_business/description

core person vocabulary

ISA

https://joinup.ec.europa.eu/asset/core_person/description

core location vocabulary

ISA

https://joinup.ec.europa.eu/asset/core_location/description

core public service vocabulary

ISA

https://joinup.ec.europa.eu/asset/core_public_service/description

Oslo

V-ICT-OR

https://joinup.ec.europa.eu/catalogue/asset_release/oslo-open-standards-local-administrations-flanders-version–10?lang=nl

Semantic versioning De waarde in het “versie” veld bestaat uit 3 opeenvolgende getallen met een punt tussen, vb: 5.12.0, waarbij: de verschillende delen worden aangeduid (benoemd) als MAJOR.Minor.patch kort “M.m.p” de getallen sequentieel zullen verhogen en zo toegekend worden dat ze een “compatibiliteit” van het uitgewisselde bestand met andere versies uitdrukt. Een verschillende M ‘MAJOR’ versie wijst op incompatibiliteit. Eenzelfde M ‘MAJOR’ versie wijst op “compatibiliteit” waarbij de afnemer ervan mag uitgaan dat zijn geldende automatische verwerking van de gegevens nog steeds zal werken. Verschillen in m ‘minor’ wijst op “opwaarts compatibel” wat betekent dat een cliënt die de data correct interpreteerde voor een oudere (kleinere m) versie dat ook bij een recentere versie van de data (hogere m) zal doen, maar mist mogelijks nieuwe nuances.

8.2.3 METADATA TOEVOEGEN VIA DE CKAN API Het is ook mogelijk om de metadata creatie van uw datasets op een geautomatiseerde manier te laten verlopen gebruik makend van de CKAN API. De toelichting daarbij vindt u in bijlage.


45


9

EVALUEER UW OPEN DATA PRAKTIJK

Vlaanderen staat aan het begin van een onstuitbare evolutie naar open data. Dit houdt ook in dat het beleid rond open data naargelang de grotere beschikbaarheid van data of de grotere vraag ernaar eventueel zal worden bijgestuurd. Daarnaast moet ook steeds rekening worden gehouden met mogelijke aanpassingen in het wettelijke kader rond open data, bijvoorbeeld de aankomende wijziging van de Europese richtlijn betreffende het hergebruik van overheidsinformatie. Ten slotte is ook de ervaring in praktijk van de instanties een goede graadmeter voor het succes van het Vlaamse open data beleid. De Vlaamse overheid wil graag deel uitmaken van de open data kopgroep van de Europese Unie. Daarvoor moet zij dus de vinger aan de pols van het open data beleid houden. De Vlaamse overheid wil dan ook op regelmatige basis evalueren in welke mate het open data gedachtegoed is doorgedrongen in Vlaanderen. Daarvoor is de inbreng van de instanties die data ter beschikking stellen essentieel. De Vlaamse overheid hecht dan ook veel belang aan een goede interactie met de instanties, waarbij de instanties de mogelijkheid hebben om hun ervaringen en bezorgdheden te delen. Concrete informatie zoals hoe vaak bepaalde data werd gedownload, welke data werd gevraagd, hoe veel gebruik gemaakt werd van de diensten, is hierbij van grote waarde.

Aanbeveling 22: maak een evaluatie van het succes van de Open Data praktijk van uw instantie. Deel uw ervaringen met andere instanties via het Open Data Forum.

9/ Evalueer uw Open Data praktijk

46


BIJLAGE 1 MASTER DATA MANAGEMENT WAT Bestanden veranderen veel en verouderen snel. Jaarlijks muteert 30 tot 40% van de gegevens in een adressenbestand. Bovendien werken veel instanties met verschillende databases en worden mutaties en toevoegingen vaak door meerdere personen op meerdere afdelingen doorgevoerd. Hoe houdt u deze gegevens actueel en hoe legt u onderlinge verbanden tussen de diverse databestanden binnen de Vlaamse overheid? Master Data Management (MDM) is het integreren van data en databases tot één zuiver bestand van hoge kwaliteit en consistentie. Door het beschikbaar maken van accurate, betrouwbare en consistente informatie in alle bedrijfssystemen kan tijd en geld worden bespaard. Het voornaamste belang van Master Data Management (MDM) bestaat uit het op een eenduidige manier vastleggen en beheren van stamgegevens (master data) van een organisatie, in dit geval dus de Vlaamse overheid als geheel. Dit is noodzakelijk omdat master data in bijna alle gevallen opgeslagen is in verschillende (informatie)systemen binnen een organisatie en meerdere gebruikers het benutten. MDM zorgt ervoor dat de stamgegevens consistent zijn en liefst een centrale plaats binnen de organisatie krijgen. Alle informatiesystemen binnen de organisatie putten dan uit die ene centrale bron van master data. MDM zorgt er verder ook voor dat de beschrijvingen en definities van informatie overeenkomt met de beschrijvingen en definities die dezelfde informatie heeft bij burger of bedrijf. Ondersteunende processen bij MDM zijn o.a.: bron identificatie, het verzamelen van data, data transformatie, normalisatie, regeladministratie, fout detectie en correctie, data opslag, data distributie en het beheren van data.

RELEVANTIE VOOR OPEN DATA Binnen de overheid is de verantwoordelijkheid voor de verschillende applicaties – op een paar uitzonderingen na - verdeeld over meerdere instanties. Dit geldt ook voor de bijbehorende stamgegevens (i.e. master data). Veel entiteiten kampen met de uitdaging dat essentiële stamgegevens vaak in meerdere systemen zijn opgeslagen, bijvoorbeeld contacten, openingsuren, enzovoort. Binnen een instantie wordt vaak onvoldoende onderkend dat onjuist ingevoerde stamgegevens in één applicatie ernstige gevolgen kan hebben voor een andere applicatie. Rapportagesystemen ondervinden veel problemen als de master data niet consistent is. Hierbij kan worden gesteld dat datakwaliteitsproblemen die het gevolg zijn van inconsistente master data één van de belangrijkste redenen zijn dat veel Business Intelligence projecten niet het gewenste resultaat opleveren. Deze problematiek geldt ook voor Open Data, zei het nu dat hier niet de interne werking maar ook de burger de gevolgen van slechte stamgegevens zal ervaren. Als iedere entiteit gegevens zal ontsluiten via Open Data en iedere entiteit gebruikt daarvoor een andere manier om bv adressen te modelleren, dan zal de burger moeite hebben om dit alles aan elkaar te lijmen of er een consistente applicatie rond te schrijven. Daarom vragen we extra aandacht te besteden aan het opstellen en beheren van stamgegevens, op zijn minst op instantieniveau, liefst overheid breed. Het goede nieuws is dat de technieken om dit voor Open Data te realiseren niet zoveel anders zijn als voor applicaties en / of rapportagesystemen. Met andere woorden, het proces om stamgegevens te maken en beheren voor klassieke applicaties kan ook toegepast worden op de Open Data sets. Bovenstaande tekst is gebaseerd op http://ict-mdm.wikispaces.com/. De licentieovereenkomst van deze site (Creative Commons Attribution Share-Alike 3.0 License) laat toe om deze tekst over te nemen en aan te passen waar relevant.

STAPPEN IN EEN MDM PROCES De volgende stappen gelden algemeen voor het bewaken van de kwaliteit en consistentie van gegevens, en zijn dus ook van toepassing op het vinden en ontsluiten van Open Data stromen. Allicht worden ze op een of andere manier gebruikt voor het beheren van gegevens, misschien niet zo nadrukkelijk als ze hieronder staan beschreven. De lijst is dan ook in de eerste plaats te zien als een check list om de kwaliteit en de consistentie van gegevens en Open Data stromen te bewaken. Hoe groter het aantal gegevens en de entiteit, hoe formeler een proces moet ingeregeld worden. Ook op niveau van de Vlaamse overheid is het interessant om de volgende stappen in het achterhoofd te houden voor het beheer van alle Open Data stromen. 1/Identificeren van Open Data master-data. Aan de hand van een aantal criteria wordt vastgesteld welke data wel, en welke data niet als master data beschouwd en opgenomen wordt in een Open Data beheersproces. Denk hierbij aan de criteria voor ontsluiting die eerder in dit document zijn gelijst.

Bijlage 1: Master Data Management

47


2/Identificeren van de bronsystemen. Waar komt de master-data en haar metadata vandaan, en welke bronsystemen produceren ze. 3/Verzamelen en analyseren van metadata over master-data. Het verzamelen van de onderliggende metadata over de master data. Zie ook het eerdere hoofdstuk over metadata voor Open Data dat de nodige velden beschrijft. 4/Aanstellen van data stewards. Dit zijn mensen met zowel kennis van het huidige bronsystemen als Open Data om dezelfde regels te laten gelden op alle databronnen. 5/Opstellen van een data- governance programma en een data -governance Raad. Het programma dat bepaalt hoe, waar en met welke definities master data wordt vastgelegd. De eigenlijke manier van normalisatie die men gaat toepassen op de master data. De data governance raad bepaalt in overleg de normalisatie procedure die men gaat gebruiken. Zie volgende hoofdstuk voor een pragmatische aanpak van deze raad. 6/Ontwikkeling van een master-data model of logisch datamodel. Afhankelijk van de beschikbare databases en evt. datawarehouse, en de benodigde distributie van de informatie wordt voorgesteld een logisch en fysisch data model te maken dat onder het MDM proces beheerd wordt. We stellen voor om dit model uit te breiden met Open Data stromen. 7/Overweeg een tool. Waar veel gegevens beheerd worden, kan het aangeraden zijn om een MDM toolset te gebruiken. De extra gegevens voor Open Data stromen kunnen in deze tool beheerd worden wat een algemeen overzicht mogelijk maakt. 8/Ontwerpen van een ondersteunende infrastructuur. Voor entiteiten die veel gegevens beheren en die automatisch willen ontsluiten naar Open Data stromen, kan overwogen worden om gebruik te maken van ondersteunende infrastructuur om de ETL processen uit te voeren. Binnen de Vo is er al dergelijke infrastructuur beschikbaar, zie het stukje rond technische standaarden eerder in dit document. 9/Genereren en testen van stamgegevens. De stamgegevens zullen met behulp van handmatige of automatische inspectie getoetst moeten worden op kwaliteit en consistentie. Het zal vrijwel onmogelijk zijn om alle stamgegevens in een keer kloppend te krijgen en te houden. Vaak zitten er in de ETL toolsets wel mogelijkheden om dit te voorzien, maar soms kunnen specifieke testen nodig zijn (bv. voor het anoniem maken van Open Data gegevens). 10/Implementeren van onderhoudsprocessen. Geen enkel proces is statisch en zeker ook het beheren van MDM en Open Data stromen niet. Voorzie dan ook een proces voor het onderhouden van metadata, ETL functionaliteit om de kwaliteit van de gegevens in stand te houden.

ORGANISATORISCHE IMPACT EN AANPAK De aandachtige lezer zal begrijpen dat het opzetten van een gedegen MDM proces ook een impact zal hebben op het governance model van de ICT afdeling van de instantie in kwestie. We gaan er in eerste instantie van uit dat voor het beheer en publiceren van Open Data stromen er geen sprake kan zijn van extra mensen of werklast. Daarom stellen we hier een groeimodel voor dat zo veel mogelijk gealigneerd is met bestaande ICT opdrachten en nu ook voor Open Data beheer kan gebruikt worden.

Fase 1: Korte Termijn: Per instantie In deze stap voorzien we minimale inspanning om aan MDM te doen. Volgende kenmerken gelden: Geen unieke of aparte master data organisatie of team. Business en / of ICT van de instantie staat zelf in voor opmaak van standaarden en procedures om master data te maken of te beheren. Inspanning is verdeeld over alle personen van de instantie en is “best effort” opgezet


48


Fase 2: Middellange termijn: Federated (Open Data COE) In deze fase is er een COE (Center of Expertise) opgericht dat zich over alle MDM van de instantie ontfermt. Er zijn standaarden en afspraken op instantie die door een verantwoordelijke op dat niveau worden beheerd. Er is ook een overkoepelend aanspreekpunt voor alle MDM van de organisatie, maar deze persoon kan deze standaarden nog niet afdwingen, louter faciliterend optreden. Zo wordt naar een groot mogelijke gemene deler van standaarden en afspraken gewerkt.

Deze maturiteitsvorm vereist dus inderdaad verantwoordelijken voor MDM op verschillende niveaus, maar bewerkstelligt de standaardisatie ook wel.

Fase 3 (lange termijn): Volledig gecentraliseerd Op lange termijn worden alle afspraken en standaarden rond MDM samengebracht op het hoogste niveau van de organisatie. Geen sinecure, want dat betekent ook autoriteit en verantwoordelijkheid om de lagere niveaus deze afspraken te doen volgen. Het voordeel is


49


dat er een algehele consistentie is over alle informatie, wat de doorstroming faciliteert. Business mensen kunnen aanvragen doen voor wijzigingen of nieuwe definities aandragen aan het centrale team.


50


BIJLAGE 2 TECHNISCHE STANDAARDEN In dit hoofdstuk gaan we dieper in op de technische tools die kunnen helpen binnen de gestelde scenario’s. We gaan de tools voor Extract, Transform & Publish hier mappen op de standaarden van de Vlaamse overheid, zodat iedere entiteit kan inschatten welke tools er nodig zijn. Dit stukje richt zich in eerste plaats tot de Vlaamse overheid en haar instanties. Hierdoor kunnen we verwijzen naar de standaarden die hier gelden en daarom ook hergebruikt kunnen worden. Voor alle tools en standaarden verwijzen we verder naar e-IB die tot taak heeft zoveel mogelijk standaardisatie over de entiteiten te voorzien en ook een dienstverlening op elk van deze tools aan te bieden aan de entiteit. De beschreven tools in dit hoofdstuk zijn afgestemd met de standaarden op het moment van publicatie, maar kunnen op elk moment in tijd wijzigen. We voorzien verschillende richtlijnen: Voor eenvoudige rechttoe rechtaan conversies kan men gebruik maken van de mogelijkheden van het Vlaams Open Data platform en The Data Tank zelf. Voor eenvoudige “Extract” en “Transform” kan met VOBIP Light / Open Source tools zoals Pentaho gebruiken. Voor complexe “Extract” en “Transform” aanpak, wordt VOBIP sowieso naar voor geschoven. Daar zitten ook technische mensen die de scripts kunnen ontwikkelen en beheren. We zien dit meer in scenario 3 & 4. Voor viewer technologie wordt verwezen naar BIVO en het gebruik van de Cognos Viewer binnen het publiek toegankelijke gedeelte van de VOBIP omgeving. Klassieke ETL technologie zoals Datastage, Oracle warehouse Builder, Pentaho en Informatica bieden uitgebreide mogelijkheden voor complexe transformaties. Naast de “Extract” en “Transform” hebben deze tools meestal ook ingebouwde oplossingen voor het periodiek uitvoeren (scheduling) en publiceren (bv ftp APIs) van de Open Data. Deze tools vereisen wel tussenkomst van IT medewerkers voor installatie, configuratie, bouw en inregeling van de extract en zijn meestal ook onderhevig aan licenties. Binnen de Vlaamse overheid kan het VOBIP Datastage platform gebruikt worden om de kosten voor installatie en licenties beperkt te houden.

Vlaams Open Data Platform (CKAN) CKAN is werelds meest toonaangevende open source software voor het opzetten van een open data portaal. De Vlaamse overheid stelt een CKAN instantie ter beschikking voor het publiceren Vlaamse datasets. Dit platform moet de goeden gids worden voor Open Data van overheden in Vlaanderen, zowel entiteiten van de Vlaamse overheid als lokale besturen. In verschillende hoofdstukken van de handleiding wordt toegelicht hoe datasets te publiceren en metadata toe te voegen aan deze datasets door gebruik te maken van CKAN software. http://ckan.org/

The Data Tank De Data Tank is een open source tool die functioneert als datahub bij het publiceren van datasets in tekstbestanden zoals CSV, XML en JSON of in binaire structuren zoals SHP-bestanden en relationele databases. De Data Tank zal de gegevens uitlezen en deze publiceren op het web met behulp van een URI als een identifier. Het kan vervolgens deze gegevens weergeven in het gewenste formaat, ongeacht het oorspronkelijke formaat. Zie http://thedatatank.com/

Vlaamse overheid Bedrijfsinformatieplatform (VOBIP) Business Intelligence (BI) staat voor het verzamelen van informatie binnen de eigen omgeving. Het kan omschreven worden als het proces om gegevens om te zetten in informatie, die vervolgens leidt tot kennis. Business Intelligence heeft als doel een competitief voordeel te creëren en wordt als een waardevolle kerncompetentie beschouwd binnen een overheidsinstelling. Om binnen de Vlaamse overheid gebruik te maken van dergelijke BI-functionaliteiten, is er een gemeenschappelijk platform ingericht met de nodige hard- en software om data van verschillende bronnen te consolideren en integreren in ‘DataWarehouses’, op basis waarvan rapportering en analyse kan gebeuren. Dit platform heet het ‘Vlaamse overheid Bedrijfsinformatieplatform (VOBIP)’. Met dit platform kunnen entiteiten oplossingen voor business intelligence (BI) en enterprise planning implementeren, ontwikkelen en toegankelijk maken.

Programma Bedrijfsinformatie Vlaamse overheid (BIVO) Managers worden geconfronteerd met vragen, eisen en verwachtingen vanuit de samenleving en het politieke niveau. Om een flexibele Vlaamse overheid te realiseren, moeten managers een goed zicht hebben op hun organisatie en de juiste informatie krijgen om de

Bijlage 2: Technische standaarden

51


juiste beslissingen te nemen. Ook op het vlak van de interne organisatie. Het Departement Bestuurszaken consolideert en verspreidt informatie over deze acht thema’s: Personeel Organisatie Wetsmatiging ICT E-governement Facilitair management Vastgoed Overheidsopdrachten Het zijn echter de entiteiten van de Vlaamse overheid die informatie aanleveren. Om tot samenhangende bedrijfsinformatie te komen, is de afstemming van definities en tabellen met alle betrokkenen van belang. Rapporten en bijhorende datasets worden typisch getoond en als dataset ter beschikking gesteld aan de hand van COGNOS viewer binnen het publiek toegankelijk gedeelte van de VOBIP omgeving.

Bijlage 2: Technische standaarden

52


BIJLAGE 3 TOEVOEGEN VAN METADATA VIA DE CKAN API VOORWAARDE U hebt een API key nodig om via de CKAN API een actie te doen. Deze API key vindt u op uw profiel pagina, te vinden op http://ckan-001. corve.openminds.be/user/{uw_username}.

CKAN API Algemene info over de CKAN API vindt men op http://docs.ckan.org/en/latest/api.html

VOORBEELD UPLOAD Om een dataset via de api toe te voegen kan je via HTTP POST een json payload doorsturen. Hieronder vindt u een voorbeeld van zo’n json payload en het POST commando gebruik makend van curl, een command line tool om data te transfereren.

Bijlage 3: Toevoegen van metadata via de CKAN API

53


voorbeeld { “title”: “Aantal aangevraagde en goedgekeurde tewerkstellingspremies 50-plus”, “name”: “aantal-aangevraagde-en-goedgekeurde-tewerkstellingspremies-50-plus”, “url”: “http://aps.vlaanderen.be/sgml/largereeksen/5867.htm”, “notes”: “Aantal aangevraagde en toegekende tewerkstellingspremies 50-plus door de Vlaamse overheid.”, “private”: false, “isopen”: true, “license_id”: “cc-zero”, “tags”: [ { “vocabulary_id”: null, “display_name”: “arbeidsmarkt”, “name”: “arbeidsmarkt” }, { “vocabulary_id”: null, “display_name”: “tewerkstelling”, “name”: “tewerkstelling” } ], “resources”: [{ “format”: “xls”, “name”: “Aantal aangevraagde en goedgekeurde tewerkstellingspremies 50-plus in MS-Excel”, “url”: “http://www4.vlaanderen.be/dar/svr/Cijfers/Exceltabellen/arbeidsmarkt/algemeen/werkbel006.xls”, “resource_type”: “file” }], “author”: “VDAB, bewerking Departement WSE”, “maintainer”: “Myriam Vanweddingen”, “maintainer_email”: “[email protected]”, “groups”: [{“name”: “arbeidsmarkt”}], “owner_org”: “svr”, “extras”: [ { “value”: “arbeidsmarkt - algemeen”, “key”: “beleidsdomein” }, { “value”: “2006-2012”, “key”: “dimensie tijd” }, { “value”: “Vlaams gewest”, “key”: “dimensie ruimte” }, { “value”: “2012-09-07”, “key”: “laatst gewijzigd” } ] }


54


template { “title”: “”, “name”: “”, “url”: “”, “notes”: “”, “private”: false, “isopen”: true, “license_id”: “”, “tags”: [ { “vocabulary_id”: null, “display_name”: “”, “name”: “” }, { “vocabulary_id”: null, “display_name”: “”, “name”: “” } ], “resources”: [{ “format”: “”, “name”: “”, “url”: “”, “resource_type”: “” }], “author”: “”, “maintainer”: “”, “maintainer_email”: “”, “groups”: [{“name”: “”}], “owner_org”: “”, “extras”: [ { “value”: “”, “key”: “dekking in tijd” }, { “value”: “”, “key”: “geografische dekking” }, { “value”: “”, “key”: “laatst gewijzigd” } ] }


55


Toelichting Veld

Toelichting

url

dit is het http adres van de context-pagina (de bijsluiter)

license_id

één van de volgende waarden: notspecified, cc-zero, gratis-open-data-licentie, open-data-licentie-tegen-billijke-vergoeding, gratis-open-data-licentie-voor-niet-commercieel-hergebruik, gratis-open-data-licentie-voor-niet-commercieel-hergebruik + open-data-licentie-tegen-billijke-vergoeding-voor-commercieel-hergebruik

Format

lowercase file extensie (csv, tsv, xml, json, rdf, xls, …)

resource_type

file, file.upload, api

groups/name

één van de volgende waarden: arbeidsmarkt, bestuurszaken, buitenlands-beleid, buitenlandse-handel, cultuur, demografie, economie, energie, financien-en-begroting, gelijke -kansen, gezondheid, ict, landbouw, media, milieu-en-natuur, mobiliteit, monumenten-en-landschappen, onderwijs, ontwikkelingssamenwerking, ruimtelijke-ordening, sport, toerisme, welzijn-en-kansarmoede, wetenschap-en-innovatie

owner_org

de lijst van organisaties is te vinden op http://ckan–001.corve.openminds.be/organization en u kan daar uw eigen organisatie toevoegen.

CURL COMMANDO CURL is een open source command line tool om data over te brengen met URL syntax. Meer info op de curl website http://curl.haxx.se/ Voorbeeld van een ‘create’ actie: curl -d “@payload.json” http://ckan-001.corve.openminds.be/api/3/action/package_create -H “Authorization:api-key” Voorbeeld van een ‘delete’ actie: curl -d ‘{“id”: “aantal-aangevraagde-en-goedgekeurde-tewerkstellingspremies-50-plus”}’ http://ckan-001.corve.openminds.be/api/3/action/package_delete -H “Authorization:api-key”


56


WOORDENLIJST Term

Verklaring

API

Application Programming Interface, specificatie hoe met software componenten te communiceren

DWH

Data Ware House

ETL

Extract, Transform, Load: proces en techniek uit de datawarehouse wereld om gegevens consistent te verzamelen en te publiceren in een data warehouse

ETP

Extract, Transform, Publish: afgeleid proces van ETL, waarin dezelfde technieken worden gebruikt om informatie te verzamelen en consistent te maken. Enkel de laatste stap (Publish), bevat een aantal andere tools en technieken om de data set (ook) als Open Data te publiceren.

Gestructureerde

Data die binnen een file gelabeld zijn en bijgevolg gemakkelijk kunnen opgevraagd en verwerkt worden (machine-processable)

Data Master Data

Stamgegevens

MDM

Master Data Management

Open Data Platform

“Gouden Gids” platform waarin alle Open Data sets in gelijst worden, met referentie naar de dataset zelf. Voor Vo is dit platform op CKAN gebouwd

Open Data set

Dataset die voldoet aan alle criteria van Open Data (formaat, kwaliteit, machine leesbaar, etc) en die door derden kan gebruikt worden

Open formaat

Een gepubliceerde specificatie voor de opslag van digitale data, meestal onderhouden door een standaardisatie organisatie, die derhalve door iedereen kan worden gebruikt en geïmplementeerd.

REST

Representational state transfer (REST), een software-architectuur voor gedistribueerde systemen zoals het WWW

URI

Uniform Resouce Identifier

Vo

Vlaamse Overheid

VRIND

Vlaamse Regio Indicatoren

Web API

API gebruik makend van web technologie, in veel gevallen via het http protocol.

Woordenlijst

57

Open Data Handleiding 2.0

Recommend Documents