Open Data
Handleiding
Praktijkgerichte handleiding voor de publicatie en het beheer
van Open Data met behulp van 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
4.3/ Ontsluiting van geografische en locatiegebaseerde informatie in Vlaanderen ................................................................................. 26
4.3.1/ Positionering ............................................................................................................................................................................................................ 26
4.3.2/ Leidraad voor de publicatie van geografische gegevens ............................................................................................................... 27
4.3.3/ Technische impact ................................................................................................................................................................................................ 28
4.4/ Hoe begin je aan Open Data binnen je projecten? ............................................................................................................................................ 29
5/ Structureer uw dataset(s) en kies een open formaat of API ........................................................................................................................................ 31
5.1/ Minimale vereisten ................................................................................................................................................................................................................. 31
5.1.1/ Kwaliteit ....................................................................................................................................................................................................................... 31
5.1.2/ Consistentie ............................................................................................................................................................................................................... 31
5.2/ Standaarden, open formaten en API’s ....................................................................................................................................................................... 32
5.3/ Linked Open Data .................................................................................................................................................................................................................. 34
5.4/ Maturiteitsmodel voor Open Data ............................................................................................................................................................................ 34
6/ Publiceer uw dataset(s) ...................................................................................................................................................................................................................... 35
6.1/ Voorafgaande technische toetsing ............................................................................................................................................................................... 35
6.2/ Via eigen website (datadump of API) of upload naar CKAN ........................................................................................................................ 35
7/ Documenteer uw dataset(s) ............................................................................................................................................................................................................. 36
7.1/ ‘Open Data’ contactpunt .................................................................................................................................................................................................... 36
7.2/ Contactadres voor informatie en feedback ............................................................................................................................................................ 36
7.3/ Gebruiksvoorwaarden ......................................................................................................................................................................................................... 37
7.4/ Vergoedingen ............................................................................................................................................................................................................................ 37
7.5/ Garanties betreffende de beschikbaarheid ............................................................................................................................................................. 38
7.6/ Bijsluiter ...................................................................................................................................................................................................................................... 38
7.6.1/ De data zelf ............................................................................................................................................................................................................... 39
7.6.2/ Het proces ................................................................................................................................................................................................................. 39
7.7/ Taal van de website .............................................................................................................................................................................................................. 39
8/ Maak uw dataset(s) vindbaar .......................................................................................................................................................................................................... 40
8.1/ Metadata ...................................................................................................................................................................................................................................... 40
8.1.1/ Wat is metadata? ................................................................................................................................................................................................... 40
8.1.2/ Hoe metadata opmaken .................................................................................................................................................................................... 40
8.1.3/ Metadata richtlijnen ............................................................................................................................................................................................. 41
8.2/ Metadata toevoegen in CKAN ......................................................................................................................................................................................... 42
8.2.1/ Account aanmaken .............................................................................................................................................................................................. 42
8.2.2/ Dataset creëren ..................................................................................................................................................................................................... 42
4
8.2.3/ Metadata toevoegen via de CKAN API ...................................................................................................................................................... 49
9/ Evalueer uw Open Data praktijk ................................................................................................................................................................................................... 50
Bijlage 1: Master Data Management .................................................................................................................................................................................................... 51
Bijlage 2: Toevoegen van metadata via de CKAN API ............................................................................................................................................................... 55
Bijlage 3: Mapping metadata DCAT-CKAN ........................................................................................................................................................................................ 59
Bijlage 4: Overzicht aanbevelingen ..................................................................................................................................................................................................... 62
Woordenlijst ..................................................................................................................................................................................................................................................... 63
5
Open Data Handleiding
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
Open Data Handleiding
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.
Ook in het regeerakkoord 2014-20191 is volgende ambitie met betrekking tot Open Data opgenomen: “Open Data zijn de norm bij de Vlaamse
overheid en worden versneld in praktijk gebracht.”
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 (oktober 2014) zijn er meer dan 1.200 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 http://www.vlaanderen.be/publicaties/detail/het-regeerakkoord-van-de-vlaamse-regering-2014-2019
1/ Algemeen
7
Open Data Handleiding
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.2
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
2 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
Open Data Handleiding
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);3
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.
3 Deze uitzondering overlapt gedeeltelijk met de regeling betreffende de verwerking van persoonsgegevens (cf. infra).
2/ Selecteer uw dataset(s)
9
Open Data Handleiding
Voor milieu-informatie gelden een aparte reeks uitzonderingen, die echter vergelijkbaar zijn met de bovenstaande belangen.4
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.5 Het begrip ‘persoonsgegevens’ wordt als volgt
gedefinieerd: “iedere informatie betreffende een geïdentificeerde of identificeerbare natuurlijke persoon”.6 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.
4 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.
5 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.
6 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.
2/ Selecteer uw dataset(s)
10
Open Data Handleiding
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 studie7 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
7 http://datos.gob.es/datos/sites/default/files/files/Estudio_infomediario/121001%20RED%20007%20Final%20Report_2012%20Edition_vF_en.pdf
2/ Selecteer uw dataset(s)
11
Open Data Handleiding
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
2/ Selecteer uw dataset(s)
12
Open Data Handleiding
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.
2/ Selecteer uw dataset(s)
13
Open Data Handleiding
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 opgest eld 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”.8 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.9 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.10.
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).11
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.
8 Artikel 7 Decreet van 27 april 2007 betreffende het hergebruik van overheidsinformatie, B.S. 5 november 2007.
9 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.
10 Cf. infra.
11 Zie Omzendbrief VR 2012/31. Omzendbrief toegang/gebruik en hergebruik, http://vademecum.vandenbroele.be/entity.aspx?id=173.
3/ Kies een modellicentie
14
Open Data Handleiding
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 Zero12 verklaring, waarbij de instantie afstand doet van haar intellectuele eigendomsrechten, voor zover dit
wettelijk mogelijk is13. 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.14
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.
12 http://creativecommons.org/about/cc0
13 Zie juridische nota punt 3.2 met betrekking tot de geldigheid van de CC0-verklaring
14 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
Open Data Handleiding
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.
In de voorlaatste paragraaf wordt verdere toelichting verschaft over het ontsluiten van geografische en locatiegebaseerde informatie in
Vlaanderen.
Tot slot worden een aantal tips meegegeven om binnen bestaande of nieuwe projecten een Open Data behoefte te onderkennen en deze gegevens meteen mee te ontsluiten binnen de scope van het project.
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
Open Data Handleiding
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
4/ Ontsluit uw brongegevens
17
Open Data Handleiding
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 ontsluiten15, zie figuur hieronder:
15
Bij een “Open by default” benadering zal de ‘Open Data exit’ deel uitmaken van het verwerkingsproces
4/ Ontsluit uw brongegevens
18
Open Data Handleiding
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.
4/ Ontsluit uw brongegevens
19
Open Data Handleiding
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
4/ Ontsluit uw brongegevens
20
Open Data Handleiding
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.
4/ Ontsluit uw brongegevens
21
Open Data Handleiding
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.
4/ Ontsluit uw brongegevens
22
Open Data Handleiding
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 2014) 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:
4/ Ontsluit uw brongegevens
23
Open Data Handleiding
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 2014) hebben we nog geen enkele Open Data set die door deze stappen is gegaan.
4/ Ontsluit uw brongegevens
24
Open Data Handleiding
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.
4/ Ontsluit uw brongegevens
25
Open Data Handleiding
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 (Q4 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.
4.3 ONTSLUITING VAN GEOGRAFISCHE EN LOCATIEGEBASEERDE INFORMATIE IN
VLAANDEREN
4.3.1 POSITIONERING
In dit document hebben we tot nu toe een generieke aanpak voorgesteld op basis van de ETL technieken om gegevens te ontsluiten. Voor
bepaalde datastromen zoals geografische gegevens kunnen er extra stappen of andere specifieke stappen nodig zijn om deze gegevens te ontsluiten. Daarom hebben we een extra sectie toegevoegd die inzoomt op de verwerking van geografische gegevens (GIS, GEO) naar een Open
Data stroom.
Op basis van onze algemene ETL tekening, hebben we hier dus specifiek over databanken, bestanden en datawarehouses die ruimtelijke informatie bevatten en als input bron dienen voor het ontsluiten van geo-informatie, zoals hieronder is weergegeven:
4/ Ontsluit uw brongegevens
26
Open Data Handleiding
We zien deze aanpak vooral relevant voor scenario 3, 4 en 5, waar een volledig ETL proces zal doorlopen worden voor het ontsluiten en publiceren van geo-data. De algemene ETL technieken en scenario’s die in dit document zijn beschreven, blijven geldig voor de verwerking van
geografische gegevens, alleen zal er extra aandacht zijn voor de specifieke Europese INSPIRE16 (i.e. Infrastructure for Spatial Information in the
European Community) en Vlaamse GDI17 (i.e. Geografische Data Infrastructuur) richtlijnen die hiervoor bestaan. Vanuit INSPIRE en GDI worden
immers standaarden voor data modellen, protocollen, formaten en metadata aangereikt waarmee geografische gegevens ontsloten moeten
worden.
In het kader van Open Data zullen deze richtlijnen ook geldig blijven. De tekst in dit document is afgecheckt met deze richtlijnen, maar om de
mogelijke impact van deze richtlijnen te duiden geven we een leidraad mee die de beheerders van geografische informatie kunnen hanteren
bij het publiceren van hun gegevens.
4.3.2 LEIDRAAD VOOR DE PUBLICATIE VAN GEOGRAFISCHE GEGEVENS
In 1995 werd het samenwerkingsverband voor geografische informatie in Vlaanderen opgestart, het huidige GDI-Vlaanderen. Het samenwerkingsverband heeft tot doel de aanmaak, het beheer, de uitwisseling, het gebruik en het hergebruik van geografische gegevensbronnen en
geografische diensten te optimaliseren. Alle Vlaamse instanties maken hiervan deel uit. De stuurgroep GDI-Vlaanderen is het sturende orgaan
van het samenwerkingsverband en het Agentschap voor Geografische Informatie Vlaanderen (AGIV) het uitvoerend orgaan. Het samenwerkingsverband en het agentschap voor geografische informatie zullen in de loop van 2015 structureel geïntegreerd worden in een breder samenwerkingsverband en agentschap voor informatie.
Om gegevens vlot uitwisselbaar te maken tussen overheidsinstanties enerzijds en tussen overheidsinstanties en burgers, bedrijven en organisaties anderzijds worden deze toegevoegd aan de GDI. Voor toevoeging aan de GDI dient formeel een dossier tot toevoeging te worden
ingediend bij de stuurgroep GDI-Vlaanderen. Als norm geldt dat al de milieu-gerelateerde datasets en diensten, in het beheer van deelnemers
aan GDI-Vlaanderen, moeten toegevoegd worden aan de GDI (conform artikel 12 van het GDI-decreet18). Niet-INSPIRE-datasets, beheerd door
deelnemers aan GDI-Vlaanderen, moeten niet verplicht worden toegevoegd aan de GDI, tenzij de stuurgroep GDI-Vlaanderen heeft vastgesteld
dat de onderlinge uitwisseling ervan nodig is voor het uitvoeren van taken van algemeen belang. Data die niet worden toegevoegd aan de
GDI zullen wel een hergebruiksregeling moeten krijgen. Voor geografische gegevens wordt het hergebruik vastgelegd met een procedure via de
stuurgroep GDI-Vlaanderen.
Om na te gaan of jouw data onder de bepalingen van de INSPIRE-richtlijn of het GDI-decreet vallen en wat er dan precies van jou wordt
verwacht kan je volgende leidraad hanteren.
1) Bepalen van het type geografische gegevensbron:
i) Is INSPIRE van toepassing op mijn data? Controleer of jouw data opgenomen is in de bijlagen19 van de INSPIRE richtlijn. Indien
dit het geval is, zijn de INSPIRE en GDI richtlijnen van toepassing. De data dient toegevoegd20 te worden aan het samenwerkingsverband GDI-Vlaanderen. De stuurgroep GDI-Vlaanderen legt de gebruiksvoorwaarden en de regeling voor hergebruik vast.
ii) Je data staat niet in de INSPIRE lijst, maar is wel:
1) milieu-gerelateerd;
2) een officieel erkende authentieke gegevensbron;
3) een gezaghebbende gegevensbron;
4) een door de GDI-Vlaanderen stuurgroep geïdentificeerde relevante bron.
In dit geval zijn de GDI richtlijnen van toepassing. De data dient toegevoegd te worden aan de GDI-Vlaanderen. De stuurgroep
GDI-Vlaanderen legt de gebruiksvoorwaarden en de regeling voor hergebruik vast.
iii) Andere data: De beheerder is niet verplicht om de INSPIRE of GDI richtlijnen te volgen. Indien de beheerder en/of de gebruikers van mening zijn dat de gegevens waardevol zijn voor een brede doelgroep, is het aan te bevelen om de data toe te voegen
aan de GDI-Vlaanderen.
2) Indien de gegevensbron toegevoegd wordt aan de GDI dienen minimaal volgende verdere stappen doorlopen te worden:
i) Aanmaken van metadata volgens de ”GDI-Vlaanderen Best Practices voor Metadata”21 en publicatie van deze metadata in de
Geopunt catalogus22.
16 http://inspire.ec.europa.eu/
17 http://www.geopunt.be/voor-experts
18 http://www.geopunt.be/~/media/geopunt/geowijzer/inspire/documenten/vlaams%2520gdi-decreet%2520_geconsolideerd.pdf
19 http://www.geopunt.be/voor-experts/inspire
20 http://www.geopunt.be/geowijzer/gdi-vlaanderen/hoe%2520deelnemen
21 http://www.geopunt.be/~/media/geopunt/geowijzer/metadata/documenten/gdi-vlaanderen_best_practices_voor_metadata-v1_0.pdf
22 http://www.geopunt.be/catalogus
4/ Ontsluit uw brongegevens
27
Open Data Handleiding
ii) Voor INSPIRE data en authentieke Vlaamse geografische gegevensbronnen: Aanbieden van raadpleegdiensten
iii) Voor INSPIRE data en authentieke Vlaamse geografische gegevensbronnen: Aanbieden van overdrachtsdiensten
iv) Voor INSPIRE data: Harmonisatie van het datamodel met de overeenkomstige INSPIRE dataspecificatie23.
Indien u over geografische gegevens beschikt en u hebt vragen over de te volgen procedure bij het publiceren van deze gegevens, kan u altijd
contact opnemen met het Agentschap voor Geografische Informatie (AGIV) via [email protected].
4.3.3 TECHNISCHE IMPACT
De huidige wetgeving en richtlijnen voor de publicatie van geografische informatie beogen een optimale digitale uitwisseling van deze informatie. De Europese INSPIRE richtlijn is in werking getreden in 2007. De vertaling van deze wetgeving naar een Vlaamse context, onder de
vorm van het GDI-decreet, kwam in voege in 2009. Voor geografische informatie die onder het bereik van dit afsprakenkader valt:
dient het datamodel geharmoniseerd te worden met de INSPIRE data specificaties;
dient de metadata gedocumenteerd te worden volgens de GDI-Vlaanderen Best Practices voor Metadata;
en dient gebruik gemaakt te worden van gestandaardiseerde web service interfaces voor de publicatie.
De onderstaande figuur geeft een overzicht van de componenten die deel uitmaken van de GDI architectuur:
Impact op het ETL proces
Tot 2005 was ETL voor geografische informatie (Spatial ETL) in hoofdzaak het speelveld van de grote GIS ( Geografisch Informatiesysteem )
software leveranciers. Door de toename van het belang van locatie gebonden informatie de laatste jaren heeft de ondersteuning voor geografische informatie inmiddels ook zijn weg gevonden naar de meeste toonaangevende commerciële en open source DBMS (MS SQL Server, Oracle,
IBM DB2, PostgreSQL, MySQL, …). Deze DBMS bieden ondersteuning voor het opslaan en beheren van geografische gegevens en beschikken over
een basis set aan ruimtelijke functies om deze gegevens in te laden en verwerken. Aangezien deze functionaliteit in het DBMS geïntegreerd is,
is het een uitbreiding van de bestaande ETL functies en kan u de geografische gegevens op eenzelfde manier benaderen en verwerken als uw
andere gegevens. Voor data beheerders die enkel puntenlocaties (x,y) opslaan als attribuut van een object, zal deze basisondersteuning in de
meeste gevallen volstaan.
Indien u nood hebt aan meer geavanceerde Spatial ETL ( model transformatie, geocoderen, projecteren, generalisatie, etc. ) of complexere data
types (3D, raster, … ) wenst te ondersteunen is de kans groot dat de beschikbare set aan ETL functionaliteit ontoereikend is. In dit geval kan
23 http://inspire.ec.europa.eu/index.cfm/pageid/2
4/ Ontsluit uw brongegevens
28
Open Data Handleiding
u terugvallen op gespecialiseerde commerciële en open source software voor GIS (Quantum GIS, Gaia, ArcGIS, MapInfo, … ) en Spatial ETL (FME,
GDAL/OGR, GeoKettle, … ).
Impact op metadata
Om uw data en elektronische diensten binnen het samenwerkingsverband GDI-Vlaanderen te kunnen delen, dient u deze te beschrijven aan
de hand van metadata. De INSPIRE richtlijn legt een minimaal aantal velden vast die moeten beschreven worden volgende de ISO standaard
voor metadata ( ISO19115 voor data, ISO 19119 voor webservices ). Deze Europese reglementering werd voor Vlaanderen vertaald naar Best Practices voor het documenteren van metadata voor geografische informatie. Indien u deze Best Practices volgt, voldoet u ook meteen aan de ISO
en INSPIRE vereisten.
Om de aanmaak en het beheer van metadata voor geografische informatie te faciliteren wordt binnen Geopunt, het portaal voor geografische
informatie van de Vlaamse overheid, een web toepassing aangeboden om uw metadata te documenteren (het Geopunt-metadatacenter24).
De metadata omgeving beschikt naast een grafische web interface ook over een metadata service API. Deze API volgt de door INSPIRE aanbevolen Open Geospatial Consortium (OGC) standaard voor de publicatie van metadata ( “Catalog Service for the Web” of CSW standaard).
Elke dag worden de metadata van alle metadata leveranciers binnen GDI-Vlaanderen gesynchroniseerd met de Geopunt catalogus. Op deze
manier wordt een globaal overzicht verkregen van het aanbod aan geografische informatie binnen het GDI-Vlaanderen netwerk.
De Open Data catalogus gaat op regelmatige tijdstippen de Geopunt catalogus gaan oogsten. Op deze manier stroomt de metadata van het
aanbod aan geografische open data naadloos door naar de Open Data catalogus.
Impact op het publiceren van data
INSPIRE en GDI-Vlaanderen voorzien verschillende manieren om data elektronisch te publiceren. Er wordt onderscheid gemaakt tussen raadpleeg- en overdrachtsdiensten (INSPIRE View Services en Download Services).
Raadpleegdiensten richten zich in hoofdzaak op een laagdrempelige integratie van de geografische informatie in een cartografische (web)
toepassing. Op basis van een locatie kan de gebruiker een kaartuitsnede onder de vorm van een beeld (jpg, png, gif) opvragen. Om INSPIRE en
GDI-Vlaanderen conforme raadpleegdiensten te kunnen aanbieden, dient de technische richtlijn25 voor raadpleegdiensten (Technical Guidance
for the implementation of INSPIRE View Services ) gevolgd te worden. Deze richtlijn is gebaseerd op de OGC Web Map Service ( WMS ) en Web
Map Tile Service ( WMTS ) implementatiestandaarden.
De overdrachtsdiensten zijn voorzien voor het opvragen van de geografische data zelf. De mogelijkheid bestaat om data aan te bieden als een
aflaadbaar bestand of via een directe toegang tot de databank. Om INSPIRE en GDI-Vlaanderen conforme overdrachtsdiensten te kunnen aanbieden, dient de technische richtlijn25 voor overdrachtsdiensten ( Technical Guidance for the implementation of INSPIRE Download Services )
gevolgd te worden. Deze richtlijn is gebaseerd op de OGC Web Feature Service ( WFS ) voor directe toegang tot de databank, en op de IETF
ATOM standaard voor de publicatie van aflaadbare bestanden. Een WFS is een interface voor het opvragen en aanleveren van geografische
vectoriële data. De gegevens worden aangeleverd onder de vorm van een voor geografische gegevens specifiek XML schema, beter bekend als
GML (Geography Markup Language ). Indien er geopteerd wordt om de data als aflaadbaar bestand te delen, dient een ATOM feed opgezet te
worden die een overzicht biedt van de beschikbare bestanden. INSPIRE beveelt het gebruik van GML aan als bestandsformaat voor de uitwisseling van gegevens, daarnaast kan ook gebruik gemaakt worden van shapefile, DXF en KML ( Keyhole Markup Language ) als formaat om data
uit te wisselen.
Voor meer informatie of ondersteuning kan u altijd terecht bij het Agentschap voor Geografische Informatie (AGIV) via [email protected].
4.4 HOE BEGIN JE AAN OPEN DATA BINNEN JE PROJECTEN?
In deze sectie geven we wat extra tips hoe je binnen bestaande en / of nieuwe projecten een Open Data behoefte kan onderkennen en deze
meteen mee kan ontsluiten binnen de scope van het project. Hiermee willen we aantonen dat je niet altijd nieuwe projecten moet opstarten
om Open Data te ontsluiten.
24 https://metadata.geopunt.be/zoekdienst/apps/tabsearch/index.html?hl=dut
25 http://inspire.ec.europa.eu/index.cfm/pageid/5
4/ Ontsluit uw brongegevens
29
Open Data Handleiding
We onderscheiden hiervoor volgende opties:
Wijziging en / of uitbreiding functionaliteit bestaande applicatie / databases
Wat: Het toevoegen van een nieuwe/extra vereiste om een informatie stroom naar het Open Platform te ontsluiten en te publiceren.
Hoe: Door middel van een snelle beoordeling bepalen of de informatie stroom kan voldoen als Open Data stroom en dit als
scope uitbreiding voor te stellen binnen het nieuwe project. Het Open Data handboek bevat voldoende indicaties om deze beoordeling te maken.
Waarom: dit opnemen als vereiste binnen een bestaand project uitbreiding, zal minder kostbaar zijn dan dit daarna of afzonderlijk doen.
Bij het opstarten van een nieuw project om functionaliteit te informatiseren
Wat: standaard de behoefte opnemen om te bepalen welke informatie stromen er van de scope kunnen ontsloten worden als
open data
Hoe: voor elke informatie stroom die geïdentificeerd wordt binnen de scope van dit nieuwe project, kan bepaald worden of het
extern ontsloten kan worden als Open Data stroom. De verzameling van informatiestromen kunnen dan samen het Open Data
ontsluiting plan vormen en extra behoeftes formuleren naar de ETL technologie en aantal stromen.
Waarom: Een nieuw project biedt een ideaal moment om van in het begin al met Open Data rekening te houden dan achteraf
extra erbij te voorzien. Dit zal de totale kosten drukken en van in het begin een antwoord geven welke stromen en wanneer.
Bovendien zal de vraag toch komen, dus een niet te missen kans.
Voor uitbreidingen van informatie stromen op een bestaande Data warehouse omgeving:
Wat: Informatie stromen die nu naar een DWH omgeving leiden, extra omleiden naar het Open Data platform
Hoe: heel wat informatie stromen die nu naar een DWH lopen, kunnen ontsloten worden naar het Open Data platform. De technische scenario’s beschrijven de extra stappen en conformiteitsvoorwaarden die hiervoor nodig zijn
Waarom: Het inbouwen van een extra stap in een bestaand proces zal minder impact en geld kosten dan een compleet nieuwe
stroom opbouwen. Vaak kan de bestaand ETL scripts en technologie hiervoor gebruikt worden en de bestaande scheduling voor
ontsluiting gebruikt worden. Een kleine extra stap die zorgt voor veel toegevoegde waarde dus.
Vervangen van Public Reporting / Viewers door Open Data
Wat: heel wat entiteiten hebben zelf een publieke component voorzien om mensen toegang te bieden tot Open Data gegevens
(zelf al bestond de term toen nog niet). Heel wat van de functionaliteit van die platformen (bv. basis rapportering) kan opgevangen worden de mogelijkheden van CKAN of door aan de gebruiker de kans te geven het bestand in te lezen in hun eigen rapporteringstool of technologie.
Hoe: door het aanbieden van dezelfde informatie als Open Data en de publieke component eventueel af te schaffen.
Waarom: Hiermee kan de gebruiker zelf inspelen hoe hij de rapporten wil opmaken en bewaren, de overheid zal dan minder
tijd en moeite in componenten moeten steken voor basis rapportering. Dit promoot het gebruik van Open Data tegen een lagere
kost.
4/ Ontsluit uw brongegevens
30
Open Data Handleiding
STRUCTUREER UW DATASET(S) EN KIES
EEN OPEN FORMAAT OF API
5
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 of API’s 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. De “header row” moet de eerste lijn van de dataset vormen en ook niet meer dan 1 lijn beslaan. De titel is eenduidig, kort en mag geen spaties bevatten. Er moet zoveel mogelijk beroep gedaan worden op de standaard vocabularia om de titel te
nomineren, zie hiervoor de sectie “standaarden” verder in dit document. Voor CSV bestanden leggen we de nadruk om een internationaal aanvaard scheidingsteken tussen de velden (“delimiter”) te gebruiken. Een puntkomma symbool (“;”) is het meest aanvaard. Als de
instellingen op Belgische normen staan, is dit vaak een komma (“,”) en dat kan verwarring geven met numerieke waarden waar een “,”
vaak als decimaal teken wordt gebruikt. Daarom wordt ook aangeraden voor numerieke velden geen komma (“,”) maar een punt (“.”) te
gebruiken als decimaal teken.
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).
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;
Bepaal de status van de gegevens (draft, gevalideerd);
Hergebruik wat al bestaat binnen de instantie aan (meta)beschrijvingen van gegevens;
5/ Structureer uw dataset(s) en kies een open formaat of API
31
Open Data Handleiding
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;
Privacy wetgeving respecteren;
Anonimiseren van gegevens;
Aggregeren indien nodig (granulariteit).
Aanbeveling 9: Controleer minimale criteria inzake kwaliteit en consistentie alvorens een dataset wordt gepubliceerd op
het Open Data platform.
5.2 STANDAARDEN, OPEN FORMATEN EN API’S
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
5/ Structureer uw dataset(s) en kies een open formaat of API
32
Open Data Handleiding
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/
Bij de Vlaamse Overheid willen we minimaal datasets publiceren die voldoen aan de 3 sterren beschrijving volgens het maturiteitsmodel voor
Open Data (zie 5.6). 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).
Aanbeveling 10: gebruik zoveel mogelijk open formaat zoals CSV.
Gestructureerde data die niet in een open formaat (b.v. MS-Excel) beschikbaar zijn, kunnen toch gepubliceerd worden door gebruik te maken van de Datatank (software). Het Open Data platform is geïntegreerd met de Datatank voor conversie diensten van MS-Excel naar open
formaten.
Voor meer informatie over het gebruik van Databank voor conversie naar open formaten zie 6.2.2. Voor meer algemene informatie over de
Datatank software zie bijlage 2.
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).
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 de 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 de Datatank software op de pagina ‘Consuming Data’ (http://docs.thedatatank.
com/4.0/consuming_data).
Aanbeveling 11: indien u zelf een API bouwt raden wij aan een RESTful Web API aan te bieden en toegang te verlenen zonder het gebruik van een API key.
5/ Structureer uw dataset(s) en kies een open formaat of API
33
Open Data Handleiding
5.3 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 document26 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.
5.4 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)
26 http://www.opendataforum.info/files/URI_strategie.pdf
5/ Structureer uw dataset(s) en kies een open formaat of API
34
Open Data Handleiding
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)
35
Open Data Handleiding
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.27
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.
27 Cf. infra.
7/ Documenteer uw dataset(s)
36
Open Data Handleiding
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.28 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:
28 Zie http://microformats.org/rel-license.
7/ Documenteer uw dataset(s)
37
Open Data Handleiding
“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.
7/ Documenteer uw dataset(s)
38
Open Data Handleiding
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.
7/ Documenteer uw dataset(s)
39
Open Data Handleiding
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.
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.
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;
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);
8/ Maak uw dataset(s) vindbaar
40
Open Data Handleiding
Metadata evolutie: de huidige voorschriften zijn minimaal en zullen blijven evolueren.
Dit drijft de noodzaak om de metadata 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 RICHTLIJNEN
Metadata is cruciaal om datasets correct te kunnen identificeren en vindbaar te maken over alle platformen heen. Daarom stellen we voor dat
elke instantie voor elke gepubliceerde dataset een inspanning doet om een minimale set van metadata te voorzien.
In 2013 zijn er afspraken gemaakt tussen de Vlaamse overheid, de Federale overheid en een aantal steden zoals Gent en Antwerpen om zoveel
mogelijk een consistent beleid hierin te voeren.
Deze afspraken zijn gebaseerd op de Europese DCAT richtlijnen en vertaald naar een advies voor alle publicerende instanties, ongeacht de
(deel)regering, stad, provincie of gewest in België. Deze afspraken zijn opgenomen in Bijlage 4 (“Metadata mapping DCAT – CKAN”)
Het toepassen van deze richtlijnen geeft als positief gevolg dat waar je ook je dataset publiceert, je deze dataset in principe ook op andere
platformen eenvoudig en zelfs automatisch kan terugvinden. Hierdoor kan elke instantie kiezen waar Open Dataset te publiceren, maar kunnen deze datasets toch geoogst worden op een ander platform. Bijvoorbeeld kunnen alle Open Datasets van AGIV die aangeduid zijn als “Open
Data”, automatisch ook gepubliceerd worden op het Vlaamse Open Data platform, of hogerop naar naar het Europese Open Data portaal toe.
De mogelijkheden voor het invullen van metadata zijn afhankelijk van het soort platform dat men gebruikt. Voor Vlaanderen is momenteel de
keuze gevallen op het CKAN platform (zie verder). CKAN gebruikt echter een eigen aanpak naar metadata toe, waarbij men een aantal velden
verplicht maakt en een aantal vrije velden kunnen worden toegevoegd.
Het invullen van metadata is dan wel een vereiste voor het snel en eenvoudig terugvinden van datasets, toch hangt het af van het gebruikte
platform hoe deze metadata velden verplicht worden gemaakt en hoe deze moeten ingevuld worden. CKAN geeft een eigen aanpak, daarom
kunnen we hier enkel de grootste gemene deler van verplichte velden voorstellen als richtlijn.
De verplichte velden binnen CKAN zijn dan ook voorlopig beperkt tot volgend overzicht:
CKAN Veld (NL)
Veld (ENG)
link met DCAT
Tip
standaarden
Title
Title
dct:title (dcat:Dataset)
Bevat een eenduidige titel van de dataset.
Omschrijving
Description
dct:description (dcat:Dataset)
Bevat de omschrijving van de dataset, in tekst vorm. Probeer de omschrijving zo kort,
maar ook zo relevant mogelijk te houden. Het is niet de bedoeling hier de werking
van een entiteit of afdeling toe te lichten, enkel te duiden wat voor data hiermee
beschikbaar wordt gesteld.
Licentie
License
dct:license
(Dataset)
Het licentiemodel waar onder deze dataset wordt gepubliceerd. Kies een van de waarden uit de dropdown selectie. De waarden stemmen overeen met de standaardmodellen de die de Vlaamse overheid heeft voorzien.
In bijlage 3 hebben we een voorstel opgenomen hoe we de vrije velden van CKAN kunnen gebruiken om maximaal compatibel te zijn met de
afspraken gemaakt op Belgisch niveau conform de Europese DCAT richtlijnen. Per veld geven we aan hoe dit in CKAN te benoemen. Helaas is
dit nog niet afdwingbaar en dient bij het definiëren van de vrije velden bijzondere aandacht geschonken worden aan een correcte schrijfwijze. De Vlaamse overheid blijft in contact met het CKAN ontwikkelingsteam om in de toekomst deze lacune te sluiten.
Aanbeveling 21: Om een vlotte uitwisseling van dataset beschrijvingen mogelijk te maken, raden wij aan zoveel mogelijk
velden uit het op Belgisch niveau afgesproken DCAT profiel te gebruiken, zelfs binnen CKAN via vrije velden indien nodig.
Zie bijlage 3 voor een overzicht.
8/ Maak uw dataset(s) vindbaar
41
Open Data Handleiding
8.2 METADATA TOEVOEGEN IN CKAN
In dit hoofdstuk gaan we dieper in welke metadata kunnen toegevoegd worden gebruik makend van de “Creëer dataset” wizard in CKAN en
hoe we dit moeten doen.
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.
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 binnen CKAN:
8/ Maak uw dataset(s) vindbaar
42
Open Data Handleiding
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
één van de dropdown lijst
Dit manifesteert zich zo binnen CKAN:
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 gekozen modellicentie.
Het resultaat 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:
8/ Maak uw dataset(s) vindbaar
43
Open Data Handleiding
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
Er zijn 3 types van distributie en elk krijgt zijn eigen 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, …).
Data omzetten naar een ander formaat met behulp van Datatank software.
Datatank software ondersteunt de conversie van volgende formaten: xls(x), json, xml, csv, shp.
Wenst u Datatank software in te schakelen om uw dump (b.v. xls) te laten converteren naar andere formaten dan vinkt u ‘USE
THEDATATANK’ aan.
8/ Maak uw dataset(s) vindbaar
44
Open Data Handleiding
Voor de conversie van Excel files wordt u gevraagd 3 bijkomende parameters toe te voegen:
De naam van de ‘sheet’ (pagina in Excel)
In dit geval: ‘tabel’ (zie links onder).
Of er een header row is of niet (neem ‘0’ indien niet; ‘1’ indien wel). In het voorbeeld is de headerrow de rij met de jaartallen.
Op welke lijn de tabel begint. In dit geval op lijn 12, de lijn met de jaartallen.
OPGELET: vermits Datatank software index begint met 0, moet je dan 11 invoeren.
Voor de hierboven getoonde tabel geeft dat dan:
Het resultaat van het instellen van deze parameters is dat de xls dank zij theDatatank als volgt wordt getoond in CKAN:
Noteer de conversie mogelijkheden naar json, xml, csv en php aan de rechterkant.
8/ Maak uw dataset(s) vindbaar
45
Open Data Handleiding
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.
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.
8/ Maak uw dataset(s) vindbaar
46
Open Data Handleiding
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.
Dit zijn de velden die standaard worden aangeboden:
Label in pagina
CKAN field
DCAT mapping
waarden
ZICHTBAARHEID
Private
—
één van de dropdown lijst
AUTEUR
Author
—
String
AUTEUR EMAIL
author_email
—
Email
BEHEERDER
maintainer
—
String
BEHEERDER EMAIL
maintainer_email
—
Email
GROEP TOEVOEGEN
Groups
dcat:theme
één van de dropdown lijst
Verder laat CKAN toe extra metadata toe te voegen m.b.v. vrije velden.
8/ Maak uw dataset(s) vindbaar
47
Open Data Handleiding
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
Lijst met frequenties:
Jaarlijks
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
8/ Maak uw dataset(s) vindbaar
48
Open Data Handleiding
Lijst (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 3.
8/ Maak uw dataset(s) vindbaar
49
Open Data Handleiding
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
50
Open Data Handleiding
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
51
Open Data Handleiding
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
Bijlage 1: Master Data Management
52
Open Data Handleiding
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
Bijlage 1: Master Data Management
53
Open Data Handleiding
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.
Bijlage 1: Master Data Management
54
Open Data Handleiding
BIJLAGE 2 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 2: Toevoegen van metadata via de CKAN API
55
Open Data Handleiding
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”
}
]
}
Bijlage 2: Toevoegen van metadata via de CKAN API
56
Open Data Handleiding
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”
}
]
}
Bijlage 2: Toevoegen van metadata via de CKAN API
57
Open Data Handleiding
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”
Bijlage 2: Toevoegen van metadata via de CKAN API
58
Open Data Handleiding
BIJLAGE 3 METADATA DCAT-CKAN
Hieronder vindt u het over de verschillende overheden in België heen afgesproken DCAT profiel.
Er worden metadata voorzien op het niveau van de dataset zelf en op het niveau van de distributie.
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).
Zoals reeds aangehaald in het hoofdstuk rond metadata zijn er een aantal beperkingen binnen het CKAN platform om al deze velden verplicht
te maken tijdens manuele ingave of via upload script. Een aantal velden kunnen enkel via “vrije velden” worden ingegeven. Daarom hebben
we een extra kolom toegevoegd die aangeeft hoe dit in CKAN op te lossen.
Dataset
Verplichte velden voor een dataset zijn:
Property
URI
Range
Usage note
Card
CKAN
Description
dct:description
rdfs:Literal
This property contains a free-text account of the Dataset. This property can
1..n
Omschrij-
be repeated for parallel language versions of the description.
Title
dct:title
rdfs:Literal
This property contains a name given to the Dataset. This property can be
ving (1)
1..n
Titel (1)
repeated for parallel language versions of the name.
Use of Title Case.
(1): deze velden zijn sowiezo voorzien - en in dit geval ook verplicht - binnen CKAN.
Aanbevolen velden voor een dataset zijn:
Property
URI
Range
Usage note
Card
CKAN
contact point
dcat:contactPoint
v:VCard (will
This property contains contact information that can be used for flagging
0..n
Beheerder
be deprecated
errors in the Dataset or sending comments
(1)
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
Pagina
« Data
en Pagina
« Data en
hulpbronnen »
keyword/ tag
dcat:keyword
rdfs:Literal
This property contains a keyword or tag describing the Dataset.
0..n
Tags (1)
Publisher
dct:publisher
foaf:Agent
This property refers to an entity (organisation) responsible for making the
0..1
Organisatie
0..n
Groep Toe-
Dataset available.
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 themes.
voegen (1)
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 and/or additional information.
0..1
Pagina
« Data en
hulpbron-
Is the link to the leaflet ‘bijsluiter’ page.
nen »
(1): deze velden zijn sowieso voorzien binnen CKAN en kunnen niet gekozen worden.
Bijlage 3: Metadata DCAT-CKAN
59
Open Data Handleiding
Language
dct:language
dct:Linguis-
This property refers to a language of the Dataset. This property can be repea-
ticSystem
ted if there are multiple languages in the Dataset.
0..n
Taal (2)
0..1
Datum
One of (‘en’, ‘nl’, ‘fr’, ‘de’, ‘zxx’). Will be translated into URI’s.
release date
dct:issued
rdfs:Literal
This property contains the date of formal issuance (e.g., publication) of the
typed as xsd:da-
Dataset.
publicatie
(2)
teTime
update/ modi-
dct:modified
fication date
rdfs:Literal ty-
This property contains the most recent date on which the Dataset was chan-
ped as xsd:date
ged or modified.
0..1
Laatst
gewijzigd
(2)
or xsd:dateTime
(2): voorstel naamgeving in te geven als vrij veld in CKAN
Optionele metadata voor een dataset zijn:
Property
URI
Range
Usage note
Card
CKAN
conforms to
dct:conformsTo
dct:Standard
This property refers to an implementing rule or other specification.
0..n
Compliant
met stan-
Example: URI of OSLO.
Frequency
dct:accrualPerio-
dct:Frequency
This property refers to the frequency at which Dataset is updated.
dard (2)
0..1
Update
frequentie
dicity
(2)
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
0..n
Zie URI
0..n
extra veld:
other unique identifier in the context of the Catalogue.
other iden-
adms:identifier
adms:Identifier
tifier
This property refers to a secondary identifier of the Dataset, such as MAST/
ADS, DataCite, DOI, EZID or W3ID.
identifier
(zie VRIND
identifier)
spatial/
dct:spatial
dct:Location
This property refers to a geographic region that is covered by the Dataset.
0..n
needs further elaboration (NGI, AGIV, …)
coverage
temporal
Geografische Dek-
geographical
dct:temporal
coverage
dct:PeriodOf-
This property refers to a temporal period that the Dataset covers.
king (2)
0..n
Time
Dekking in
Tijd (2)
Use:
schema:startDate
schema:endDate.
Version
schema:version
rdfs:Literal
This property contains a version number or other version designation of the
0..1
Versie (2)
0..1
Versie
Dataset.
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 version of the Dataset.
Nota’s (2)
(2): voorstel naamgeving in te geven als vrij veld in CKAN
Bijlage 3: Metadata DCAT-CKAN
60
Open Data Handleiding
Distributie
Hier gaat het om de metadata toe te kennen aan de distributie (dump of api).
Verplichte velden voor een distributie zijn:
Property
URI
Range
Usage note
Card
CKAN
access URL
dcat:accessURL
rdfs:Resource
This property contains a URL that gives access to a Distribution of the
1..n
URL van
Dataset. The resource at the access URL may contain information about
distributiepa-
how to get the Dataset.
gina
Aanbevolen velden voor distributie zijn:
Property
URI
Range
Usage note
Card
CKAN
Description
dct:description
rdfs:Literal
This property contains a free-text account of the Distribution. This proper-
0..n
Omschrijving
ty can be repeated for parallel language versions of the description.
Format
dct:format
dct:MediaType-
This property refers to the file format of the Distribution.
(1)
0..1
Mediatype (2)
0..1
Licentie (1)
0..1
Aantal Bytes
OrExtent
Use file extension in lower case.
Licence
dct:license
dct:LicenseDocu-
This property refers to the license under which the Distribution is made
ment
available.
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.
(2)
typed as xsd:deTitle
dct:title
cimal
In bytes.
rdfs:Literal
This property contains a name given to the Distribution. This property can
0..n
Titel (1)
0..1
Datum Publi-
be repeated for parallel language versions of the description.
release date
dct:issued
rdfs:Literal ty-
This property contains the date of formal issuance (e.g., publication) of the
ped as xsd:date
Distribution.
catie (2)
or xsd:dateTime
update/ modi-
dct:modified
fication date
rdfs:Literal ty-
This property contains the most recent date on which the Distribution
ped as xsd:date
was changed or modified.
0..1
Laatst gewijzigd(2)
or xsd:dateTime
(1): deze velden zijn sowieso voorzien binnen CKAN en kunnen niet gekozen worden.
(2): voorstel naamgeving in te geven als vrij veld in CKAN
Optionele properties voor een distributie zijn:
Property
URI
Range
Usage note
Card
CKAN
Checksum
????
rdfs:Literal
This property contains the checksum
0..1
NVT
download
dcat:downloa-
rdfs:Resource
This property contains a URL that is direct link to a downloadable file in a
0..n
URL van
URL
dURL
media type
dcat:mediaType,
dct:MediaType-
This property refers to the media type of the Distribution if this is defined
0..1
Mediatype (2)
subproperty of
OrExtent
in IANA.
dct:RightsState-
This property refers to a statement that specifies rights associated with
0..1
Rechten (2)
ment
the Distribution.
skos:Concept
This property refers to the maturity of the Distribution
0..1
Status (2)
.
given format.
download
dct:format
Use mimetype. Will be transformed into URI.
Rights
dct:rights
Use to make the rights of the publisher explicit.
Status
adms:status
One of: ‘completed’,’under development’, ‘deprecated’, ‘withdrawn’. Will be
transformed into URI.
(1): deze velden zijn sowieso voorzien binnen CKAN en kunnen niet gekozen worden.
(2): voorstel naamgeving in te geven als vrij veld in CKAN
Bijlage 3: Metadata DCAT-CKAN
61
Open Data Handleiding
BIJLAGE 4 OVERZICHT AANBEVELINGEN
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/ 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.
3/ Controleer voor de data worden beschikbaar gemaakt of zij geen persoonsgegevens bevatten.
4/ Publiceer eerst die gegevens die al beschikbaar zijn en die een meerwaarde voor burgers, bedrijven of organisaties kunnen betekenen.
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.
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/ 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.
8/ Kies een scenario voor het ontsluiten van brongegevens met het oog op de publicatie als Open Data en pas dit toe.
9/ Controleer minimale criteria inzake kwaliteit en consistentie alvorens een dataset wordt gepubliceerd op het Open Data platform.
10/ Gebruik zoveel mogelijk open formaat zoals CSV.
11/ Indien u zelf een API bouwt raden wij aan een RESTful Web API aan te bieden en toegang te verlenen zonder het gebruik van een API key.
12/ Voorzie de nodige technische middelen om Open Data beschikbaar te maken.
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).
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.
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.
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.
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.
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.
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.
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.
21/ Om een vlotte uitwisseling van dataset beschrijvingen mogelijk te maken, raden wij aan zoveel mogelijk velden uit het op Belgisch niveau
afgesproken DCAT profiel te gebruiken, zelfs binnen CKAN via vrije velden indien nodig. Zie bijlage 3 voor een overzicht.
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.
Bijlage 4: Overzicht aanbevelingen
62
Open Data Handleiding
versie 19/11/2014
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
VRIND
Vlaamse Regio Indicatoren
Web API
API gebruik makend van web technologie, in veel gevallen via het http protocol.
Woordenlijst
63

aanvraagformulier

AA Media Group Accuraat mensen en middelen plannen Content

Begeleider ziekenhuis of andere instanties

AANMELDFORMULIER PAMEIJER Opsturen naar: secretariaat

BOA-S JS1025

Handleiding WooCommerce

Bevolkingsonderzoek darmkanker

QUICK-LOCK®

Prijslijst - Lighthouse ICT

programma - Nationaal Archief