Open Standaard voor Lokale Overheden (OSLO) specificaties v1.0

Open Standaard voor Lokale Overheden (OSLO) specificaties v1.0

OSLO METADATA Versie datum auteurs 0.9.0 07-03-2013 Buyle Raf, De Vocht Laurens 0.9.5 15-04-2013 Buyle Raf, De Vocht Laurens, Van der Spiegel Goedele 1.0.0 29-05-2013 Buyle Raf, De Vocht Laurens, Van der Spiegel Goedele Gebruik van de OSLO specificatie is vrij. Elke natuurlijke persoon, rechtspersoon of groepering verbindt zich ertoe bij elk gebruik van de OSLO specificatie een bronvermelding op te nemen. De licentiegever, V-ICT-OR vzw behoudt alle intellectuele eigendomsrechten. Copyright Deze specificatie is vrijgegeven onder de ISA Open Metadata Licence v1.0 en kan geconsulteerd worden via https://joinup.ec.europa.eu/category/licence/isa-open-metadatalicence-v11 Aansprakelijkheid V-ICT-OR vzw levert het product in de staat zoals het zich bevindt en is niet verantwoordelijk voor de schade, opgelopen door de licentienemer en/of door derden als gevolg van het gebruik van het product onder de bepalingen van deze licentie. De meest recente versie van deze paper is beschikbaar via http://purl.org/oslo/specification OSLO Open Standaard voor Lokale Overheden 2

Inhoudstafel 1. Inleiding 1.1 Over OSLO 1.1.1 Aanleiding en doelstelling 1.1.2 Essentie van het probleem 1.1.3 Hoe zijn we te werk gegaan 1.1.2 OSLO Conformance (Overeenstemming met OSLO) 1.1.2 Licentie 1.2 Stakeholders 1.2.1 Lokale besturen 1.2.2 Centrale Overheden 1.2.3 Academische partners en standardisatiecommissies 1.2.3.1 iminds - MMlab 1.2.3.2 HoGent 1.2.3.3 Europese ISA-programma 1.2.4 Consortium 2. Conceptueel model 2.1 Algemeen entiteiten, attributen en relaties 2.2 Scope 2.3 Data- en metadata 2.3.1 Datatype 2.3.1.1 Tekst 2.3.1.2 Datum/tijd 2.3.1.3 Tijdspanne 2.3.2 Metadatatype 2.3.2.1 Code 2.3.2.2 Identificatie 2.3.2.3 Herkomst 2.3.2.4 Opt-in 2.4 Contactinformatie 2.4.1 Agent 2.4.2 Contact 2.4.3 Verblijfsobject 2.4.4 Persoon Adellijke titel Nationaliteit Burgerlijke staat Wettelijk Samenwonend Identificatie OSLO Open Standaard voor Lokale Overheden 3

Is gedomicilieerd op Geslacht Verblijft op Is te bereiken op 2.4.5 Persoonsrelatie Afstamming Referentiehuishouden Gezin Voogd Burgerlijke staat 2.4.5. Organisatie Maatschappelijke naam Commerciële naam Afgekorte naam Vestiging Oprichtingsdatum Datum stopzetting Reden stopzettting Rechtsvorm Rechtstoestand KBO hoedanigheid en KBO hoedanigheidsfase Identificatie KBO soort Heeft KBO locatie Ontvangt post op Te factureren op Ontvangt leveringen op Heeft KBO status Oefent primair uit Te bereiken op 2.4.6 Organisatierelatie 2.4.7. Hoedanigheid Functie Type 2.5 Lokalisatie 2.5.1 Locatie 2.5.2 Verblijfsobject 2.5.3 Perceel 2.5.4 Gebouw 2.5.5 Basis Adres Land 2.5.6 Uitgebreid adres 2.6 Dienstverlening 2.6.1 Dienstverlening OSLO Open Standaard voor Lokale Overheden 4

Streefdatum Identificatie Type Bevindt zich in Resulteert in Is onderdeel van Volgt Voorziet Vereist 2.6.2 Product Naam Inhoud Geldigheidsduur Type Heeft toepassingsgebied Lokaliseert naam inhoud 2.6.3 Juridisch kader 2.6.4 Machtiging 2.6.6 Agent 3.1 Inleiding 4.1 Formattering 4.1.1 e-mail 4.1.2 Telefoonnummer 4.1.3 Social Media 4.1.4 Adres 4.1.5 Rijksregisternummer 4.1.6 Ondernemingsnummer 4.1.7 Datum en tijd 4.3 Informatieveiligheid 4.3.1 Wettelijke voorschriften en beperkingen 4.3.1.1 Gebruik van het rijksregisternummer en gegevens uit het rijksregister 4.3.1.2 Verwerken van persoonsgegevens 4.3.2 Maatregelen om de veiligheid van persoonsgegevens te garanderen 4.3.2.1 Klasseer de vertrouwelijkheid van de gegevens in kwestie : 4.3.2.2 Maak een ontwerp voor het toegangsbeheer van de gegevens 4.3.2.3 Vraag indien nodig toestemming van de persoon en wettelijk bepaalde doeleinden 4.3.2.4 documenteer en bewaak de integriteit van uw kerndata 4.1 Colofon 4.2 Referenties: standaarden 4.2.1 ISA - Core Public Service 4.2.2 W3C - Government Linked Data (GLD) OSLO Open Standaard voor Lokale Overheden 5

4.2.3 Standaard Uitwisseling Formaat (StUF) 4.3.4 Infrastructure for Spatial Information in the European Community (INSPIRE) 4.4.4. Belgian Streets and Addresses (BeSt Add) 4.4.5 Universal Postal Union (UPU) 4.4.7 Basisregistraties Adressen en Gebouwen (BAG) 4.4.8 SemanticGov 4.2 Referenties: authentieke bronnen 4.2.1 Authentieke bronnen persoonsgegevens Rijksregister Kruispuntbank Sociale Zekerheid Structuur van het bisnummer 4.2.2 Authentieke bronnen ondernemingsgegevens KBO Kruispuntbank ondernemingen Kwaliteit van gegevens in KBO en VKBO VKBO (Verrijkte kruispuntbank Ondernemingen) 4.2.3 Authentieke bronnen adresgegevens CRAB GRB Het Grootschalig Referentiebestand (GRB) 4.2.4 Bronnen productgegevens IPDC (Interbestuurlijke producten en dienstencatalogus) 4.2.4 Authentieke bron nationaliteiten 4.3 Detaildiagramma conceptueel model 4.3.1 Overzicht 4.3.2 Contactinformatie 4.3.3 Lokalisatie 4.3.4. Dienstverlening OSLO Open Standaard voor Lokale Overheden 6

1. Inleiding 1.1 Over OSLO 1.1.1 Aanleiding en doelstelling een betere en elektronische dienstverlening Burgers en bedrijven klagen vaak terecht over een inefficiënte overheid. Vaak moeten gegevens telkens opnieuw worden ingediend wanneer men aanklopt bij verschillende diensten. Medewerkers hebben behoefte aan een geïntegreerde werkomgeving, beleidsmakers zijn op zoek naar informatie die beleidsbeslissingen kunnen ondersteunen. De wil om het beter te doen is er, doch het lijkt bijzonder moeilijk om gegevens met elkaar te delen. Gemeenten staan voor de uitdaging om betere én elektronische dienstverlening te realiseren met inzet van ICT, terwijl ze ook moeten bezuinigen. Een bijkomende problematiek is dat ICT door de jaren heen zeer versnipperd is uitgebouwd bij lokale overheden, waardoor er verschillende toepassingen gebruikt worden op de gemeentelijke diensten. Gegevensuitwisseling tussen deze verscheidenheid aan applicaties van verschillende leveranciers is niet altijd evident. Het bewust omgaan met kerndata krijgt stilaan weerklank bij lokale besturen, maar vergt diepgaand inzicht in de eigen data en datastromen. Met kerndata bedoelen we gegevens die voorkomen in verschillende applicaties en processen en die daarom het best centraal ter beschikking gesteld kunnen worden (denk aan persoonsgegevens, adressen, statussen van een melding, ). Deze kerndata kunnen hun oorsprong vinden zowel in authentieke gegevensbronnen als in lokale processen. Ook de centrale overheden wisselen steeds maar meer data uit met de gemeenten. Sommige data worden decentraal beheerd, andere in Brussel. Uitwisseling tussen de eigen applicaties en deze zogenaamde authentieke bronnen loopt niet altijd van een leien dakje. OSLO Open Standaard voor Lokale Overheden 7

1.1.2 Essentie van het probleem Elkaar begrijpen In de zoektocht naar uitwisselbaarheid van gegevens besteedt men dikwijls enkel aandacht aan de verpakking waarin de gegevens worden doorgegeven (technische standaarden zoals XML of SOAP). Dit is noodzakelijk, maar zeker niet voldoende. Het lijkt alsof je wel de dozen standaardiseert, maar niet de bouten en moeren die er in zitten. Slimme ICT-oplossingen vragen daarnaast ook om een semantische interoperabiliteit: van elkaar weten wat bedoeld wordt. Over semantiek en semantische interoperabiliteit Semantiek gaat over betekenissen. Het gaat daarbij niet om de semantiek van de inhoud van de gegevens, maar om de betekenis van de onderdelen ervan. Semantiek slaat dus enerzijds op de definitie van 'essentiële' begrippen en hun belangrijke onderlinge relaties en anderzijds op het bepalen van woordenlijsten of ontologien. OSLO focust op het eerste en verwijst daarbij naar bestaande 'lijsten' om maximaal bestaande inspanningen omtrent catalogi te benutten. Begrippen die de structuur van de gegevens aanduiden, kunnen een ambigue betekenis hebben. Wat bedoelen we bijvoorbeeld precies met het begrip adres? Gaat het hier om een domicilie adres waar iemand juridisch woont? Of is het een lokaal verrijkt verblijfsadres, waarnaar alle informatieve correspondentie wordt gestuurd? Ook context bepaalt mee de betekenis van een begrip. De contactgegevens van een persoon bijvoorbeeld bevatten andere data, afhankelijk van de hoedanigheid (natuurlijke persoon, verantwoordelijke binnen een bedrijf of voorzitter van een vereniging) waarin men die persoon wil contacteren. Om de juiste contactgegevens van een persoon door te geven, moeten we dus de context kennen waarbinnen die gegevens worden gevraagd. Semantische interoperabiliteit gaat over de mogelijkheid om informatie uit te wisselen en te delen. Twee overheidsorganisaties zijn semantisch interoperabel als ze weten hoe ze de gegevens van de ander precies moeten interpreteren en ze elkaars informatie direct kunnen hergebruiken. Semantische interoperabiliteit is een voorwaarde voor samenwerking en hergebruik van gegevens binnen de overheid. OSLO Open Standaard voor Lokale Overheden 8

1.1.3 Hoe zijn we te werk gegaan De eerste fase van het OSLO project was de inventarisatiefase. We hebben daarin de bestaande authentieke gegevensbronnen en veelgebruikte datamodellen binnen lokale overheden geïnventariseerd. Een belangrijk aandachtspunt waren de hindernissen m.b.t. adoptie van authentieke bronnen binnen de processen. Het resultaat geeft een overzicht van de verschillende problemen m.b.t. gegevensintegratie en toepassing van authentieke bronnen en hun impact op de werking van lokale besturen. Op basis hiervan werden de problemen geclusterd en werden de prioriteiten vastgelegd. ontwikkelen van de standaard Het probleem situeert zich op het niveau van de kerndata m.b.t. personen, organisaties en adressen. De datastandaard focust zich dan ook op deze entiteiten en moet het in de toekomst mogelijk maken om gegevens uit te wisselen tussen verschillende toepassingen (binnen en buiten de lokale besturen). Er werden vijf werkgroepen opgericht: contactinformatie, lokalisatie, en dienstverlening aangevuld met datakwaliteit en informatieveiligheid. Op technisch vlak is de OSLO standaard een canoniek datamodel, een gedeeld dataformaat voor de uitwisseling van data tussen services. Hierdoor moet men geen vertalers voorzien tussen alle individuele formaten, maar één vertaler tussen elk formaat en het canonieke formaat. We adviseren dan ook om het interne model te ontkoppelen van het uitwisselingsformaat 1. Historiek valt vandaag buiten scope van OSLO (temporele aspecten zijn bewust buiten de scope gehouden), waar nodig is een geldigheidsperiode (van tot datum- opgenomen). OSLO biedt hierbij een generiek model voor de structuur van de data, niet voor de inhoud. OSLO zal de data niet inhoudelijk vastleggen, maar wil wel een richting geven. Wanneer er bestaande 'gecontroleerde lijsten' beschikbaar zijn, is het advies van OSLO om deze te gebruiken. Verankeren van de standaard Het objectief van OSLO 1.0 is een datastandaard ontwikkelen. V-ICT-OR wenst die te verankeren via twee sporen. Enerzijds ijvert ze voor een breed draagvlak en biedt ze een referentie-bestektekst aan als de facto standaard. Anderzijds probeert ze ook OSLO een decretale basis te geven. Alignering met andere/hogere standaarden 1 minimaal door gebruik te maken van een andere namespace, OSLO Open Standaard voor Lokale Overheden 9

V-ICT-OR wil geen solitaire Vlaamse standaard uitwerken. Ze toetst deze daarom ook aan de internationale standaarden. Hiervoor werkt het OSLO-project samen met het ISA (the Interoperability Solutions for European Public Administrations programme) Programma van de Europese Commissie om de OSLO-standaard conform te maken aan de kernspecficiaties van de Europese Commissie. Via o.a. World Wide Web Consortium (W3C) zal de OSLO-standaard maximaal afgestemd worden op internationale webstandaarden en best practices. Toepassingen die conform zijn met de OSLO-standaard, zullen door de conformiteit met de specificaties van het ISA Programma beter in staat zijn om gegevens uit te wisselen met applicaties die conform zijn met de ISA standaarden. Door de samenwerking met W3C en het ISA Programma is de duurzaamheid van de OSLO-standaard verzekerd. OSLO Open Standaard voor Lokale Overheden 10

1.1.2 OSLO Conformance (Overeenstemming met OSLO) Er wordt een onderscheid gemaakt tussen publishers en consumers van data. In een volgende versie komt er een aanbeveling rond formatering van sleutels en velden. Bijvoorbeeld: telefoon, rijksregisternummer... Een publisher of consumer die ook de juiste formatering omvat zal dan 4 sterren krijgen. Publishers Conceptuele Overeenstemming De data wordt gepubliceerd samen met een voor mensen leesbare mapping van termen gebruikt door de publisher naar OSLO termen. Conceptuele Overeenstemming + De data wordt gepubliceerd samen met een mapping die door machines automatisch kan verwerkt worden (bvb. een script of een XSLT) van de termen gebruikt door de publisher naar de termen van OSLO. XML of RDF Overeenstemming De data is gepubliceerd aan de hand van XML elementen en types (het OSLO XML schema) of RDF klassen gedefinieerd in de OSLO namespace. XML of RDF Overeenstemming + Inclusief herkomst. Volledige Overeenstemming De data is gepubliceerd zowel in RDF en XML formaten beschreven volgens OSLO en het typische formaat kan bepaald worden door content negotiation via een service (niet filetransfer). Dit betekent dat de consumer met dezelfde call kan definiëren welk type formaat deze wil terugkrijgen van de publisher. Consumers XML of RDF Overeenstemming Alle data die is gepubliceerd aan de hand van OSLO XML elementen en types of OSLO RDF klassen en properties kan worden geïnterpreteerd en verwerkt Volledige Overeenstemming Alle data die is gepubliceerd aan de hand van zowel OSLO RDF klassen en properties en OSLO XML elementen en types kan worden geïnterpreteerd en verwerkt. OSLO Open Standaard voor Lokale Overheden 11

1.1.2 Licentie OSLO valt onder ISA Open Metadata Licence v1.1 2 licentie (of een latere versie, vrijgegeven door de Europese Commissie). 1.2 Stakeholders Om de consensus met de industrie te vrijwaren werd het OSLO-consortium samengesteld op basis van een lidmaatschap. Zowel overheden als private dienstenleveranciers tekenden hier op in. Dit lidmaatschap dekt niet alleen de kosten van de standaardisatie, maar verzekert ons bovendien van een krachtig engagement van de partners. 1.2.1 Lokale besturen Lokale besturen worden vertegenwoordigd door de stuurgroep lokaal e-governement en maken deel uit van de OSLO werkgroepen om het model aan de praktijk te kunnen toetsen. In het permanent overlegorgaan zitten Digipolis Gent en Antwerpen, alsook Kortijk. Daarnaast wordt er met verschillende lokale besturen afgestemd rond specifieke use-cases. 1.2.2 Centrale Overheden De centrale overheden worden op het Vlaamse niveau vertegenwoordigd door e-government en ICT-Beheer (e-ib - CORVE), Proces- en Informatiebeleid (PIB), het Agentschap voor Geografische Informatie Vlaanderen (AGIV) en op Federaal niveau door de FOD voor Informatie- en Communicatietechnologie (Fedict). 1.2.3 Academische partners en standardisatiecommissies 1.2.3.1 iminds - MMlab iminds-ugent-multimedia Lab (MMLab, www.mmlab.be) is een onderzoeksgroep binnen de Universiteit van Gent (faculteit Ingenieurswetenschappen, vakgroep Elektronica en Informatiesystemen).en is één van de stichtende onderzoekspartners binnen iminds. MMlab is technische partner van OSLO. 2 https://joinup.ec.europa.eu/category/licence/isa-open-metadata-licence-v11 OSLO Open Standaard voor Lokale Overheden 12

1.2.3.2 HoGent De vakgroep Bestuur en beleid is een onderzoeksgroep binnen de Hogeschool Gent (geassocieerde faculteit Handelswetenschappen en Bestuurskunde) en staat in voor de vertaalslag van OSLO naar het beleid. 1.2.3.3 Europese ISA-programma ISA staat voor Interoperability Solutions for European public Administrations programme. Belangrijkste doel is een elektronische gegevensuitwisseling tussen publieke diensten in Europese landen. Door een betrokkenheid in de ISA-werkgroepen en het delen van projectresultatren wensen we maximaal kennis uit te wisselen tussen OSLO en projecten in andere lidstaten. 1.2.3.4 W3C Het World Wide Web Consortium (W3C) creëert de Webstandaarden. V-ICT-OR is sinds 2012 vertegenwoordigd in de standardisatiecomissie (GLD, Government Linked Data Working Group). Via o.a. W3C zal de OSLO-standaard maximaal afgestemd worden op internationale webstandaarden en best practices. Voor alle concepten die gebruikt worden in de open wereld (buiten de publieke sector), zoals bv. organisatie, persoon, telefonnummer is er een relatie met de concepten van ISA, die op hun beurt een relatie hebben met deze van W3C. 1.2.4 Consortium In het consortium zetelen toonaangevende spelers uit de industrie: BCT, Belgacom, CIPAL, Fusebox, Infront, Remmicom en Schaubroeck. Het heeft steun van Digipolis Antwerpen, Digipolis Gent en de Coördinatiecel Vlaams e-government (CORVE). OSLO Open Standaard voor Lokale Overheden 13

2. Conceptueel model 2.1 Algemeen Het conceptueel model definieert de gegevens binnen OSLO, hoe deze gegevens gestructureerd zijn en wat de relaties zijn tussen die gegevens. Dit conceptueel model vormt de basis van de formele specificatie 3. We hebben er bewust voor gekozen om het model weer te geven als een combinatie van een domeinmodel en een vereenvoudigd ERD (dit laat toe om aandachtspunten met betrekking tot identificatie en types te duiden). entiteiten, attributen en relaties In het conceptueel model worden entiteiten, attributen en relaties onderscheiden. Een entiteit kan worden gezien als een object, een concreet of abstract "iets" dat deel uitmaakt van het datamodel. Voorbeelden hiervan zijn: een persoon, een organisatie, een adres. Een entiteit heeft een eenduidige naam en een kernachtige omschrijving. Een relatie geeft het verband weer tussen twee of meer entiteiten, zoals "een persoon is gedomicilieerd op"; gedomicilieerd op is hier de relatie tussen de entiteiten persoon en verblijfsobject. Een attribuut is een eigenschap van een entiteit of relatie. Zo heeft een persoon (onder andere) een voornaam, een naam, een geboorteplaats en een geboortedatum. Attributen kennen een datatype. De kardinaliteit (het aantal keer dat een relatie/associatie voor kan/mag komen) is enkel toegepast indien het absoluut noodzakelijk is. Verder zijn er geen restricties opgelegd. In de volgende secties wordt elke entiteit voorgesteld gevolgd door een definitie van zijn attributen (met datatype) en hun relaties. Elke entiteit bestaat uit een aantal attributen die ofwel letterlijke waarden (literals) kunnen zijn ofwel sleutels (foreign keys) voor de entiteiten van andere entiteiten waarmee ze gerelateerd zijn. In dit conceptueel model wordt de bepaling van de sleutels (primary keys) niet gedefinieerd. Dit is afhankelijk van de specifieke implementatie. In de beschrijving wordt maximaal gebruik gemaakt van sleutels uit authentieke bronnen. 3 Voor de formele specificatie van de velden (validatie, invoermasker) verwijzen we naar hoofdstuk 3. OSLO Open Standaard voor Lokale Overheden 14

2.2 Scope We werken het model uit op basis van drie logische domeinen Contactinformatie Lokalisatie Dienstverlening De prioriteit van het consortium ligt op het vlak van contactinformatie. Het is voornamelijk in dit domein dat lokale besturen baat hebben bij de standaard. Dienstverlening is in deze versie van de standaard op een eerder hoger niveau uitgewerkt en vooral gebruikt als toetsing van de domeinen contactinformatie en lokalisatie. Het domein dienstverlening laat toe om een overzicht te maken van beleidsinfo van het bestuur of een PIP (my page) voor de burger. Het is voornamelijk in die optiek dat het hoofdstuk rond dienstverlening moet gelezen worden. Contactinformatie Dit domein is opgebouwd rond de entiteiten natuurlijke persoon en organisatie. Natuurlijke personen omvatten alles wat betrekking heeft tot een mens van vlees en bloed, met een identiteit (naam en voornamen), geboorteplaats en -datum en geslacht en nationaliteit(en). Organisaties omvatten alle zelfstandig, geordend samenwerkingsverbanden, met uitzondering van familiale verbanden, tussen natuurlijke en/of rechtspersonen. Organisaties kunnen zowel bedrijven kunnen zijn als verenigingen met of zonder rechtspersoonlijkheid. Lokalisatie Het domein Lokalisatie omvat alles nodig om de plaats, door adressering of georeferentie, van objecten in de openbare ruimte aan te duiden, te verwerken en toe te passen. Dienstverlening Het domein Dienstverlening omvat alle processen met een welgedefinieerde aanleiding en een welgedefinieerd resultaat, waarvan kwaliteit en doorlooptijd bewaakt moeten worden, bij een transactie tussen persoon en bestuur, tussen organisatie en bestuur en interbestuurlijk. OSLO Open Standaard voor Lokale Overheden 15

2.3 Data- en metadata 2.3.1 Datatype In de beschrijving van letterlijke waarden (literals) worden een aantal datatypes gebruikt. 2.3.1.1 Tekst Dit is een vrij type veld, waar alles in kan worden opgeslagen zonder een bepaalde formattering op te leggen (geen betekenis). Eventueel kan een lijst met toegelaten waarden gekoppeld worden. Dit wordt dan aangegeven als Tekst (Lijst). 2.3.1.2 Datum/tijd Dit type zorgt voor een correcte formattering van datum en tijd bij uitwisseling. 2.3.1.3 Tijdspanne Bestaat uit een begin- en einddatum of een begindatum en een aanwijziging hoe lang een gegeven geldig is (begin en einddatum). 2.3.2 Metadatatype 2.3.2.1 Code De code wordt gebruikt om te verwijzen naar de sleutel die voorkomt in een bepaalde lijst die gepubliceerd is door een bepaalde bron. Deze entiteit wordt typisch gebruikt om types, statussen of andere attributen met een vooraf gedefinieerd aantal mogelijkheden. Omwille van de betrouwbaarheid is een vrije invulling van zulke velden dan ook niet gewenst en vooraf overeengekomen codes vereenvoudigen de uitwisseling van gegevens. Code bron en versie zijin optioneel en hoeven in de meeste gevallen niet uitgewisseld te worden. De lijst moet dan wel zo nauwkeurig mogelijk omschreven worden (zodat bron en versie expliciet duidelijk zijn) volgens de aanbevolen lijstspecificatie bij elk type code. Deze twee manieren om codes uit te wisselen worden toegelicht aan de hand van een voorbeeld: OSLO Open Standaard voor Lokale Overheden 16

Code: C18.01.02 Label: Other printing Lijst: NACE Bron: European Commission Versie: Rev 2 In geval de lijst gespecificeerd werd in de OSLO Specificatie, dan wordt een beknopte notatie aangeraden. Code: C18.01.02 Label: Other printing Lijst: European Commission NACE Rev 2 Lijst is een verplicht veld en moet steeds uitgewisseld worden opdat de uitgewisselde codes een traceerbare betekenis krijgen. Optioneel kan, naast het label, een lange omschrijving opgenomen worden. attribuut datatype mogelijke authentieke bron Code Label Omschrijving Lijst Bron Versie Tekst Tekst Tekst Tekst Tekst Tekst 2.3.2.2 Identificatie De identificatie dient om de link met de gerelateerde concepten en de authentieke bron te bewaren zodat het mogelijk is om bij elke uitwisseling steeds na te gaan wat de oorsprong is van bepaalde gegevens en van wanneer deze precies dateren. In het informatiemodel en de specificaties is deze weergegeven als een attribuut om de leesbaarheid (samenhang) te vergroten. In de praktijk (technische schema s) is de identificatie een aparte entiteit met een eigen herkomst. Dit maakt het mogelijk om bv. bij een onderneming aan te geven dat de identificatie (sleutel) afkomstig is uit de VKBO maar de kenmerken een lokale verrijking zijn. OSLO Open Standaard voor Lokale Overheden 17

attribuut datatype mogelijke authentieke bron Sleutel Type Bron Laatste wijziging Tekst Tekst Tekst Datum/tijd 2.3.2.3 Herkomst Om onderbouwde beslissingen te kunnen nemen op het vlak van kerndata (cfr. master-data management) is het essentieel om de bron en de datum van de laatste wijziging van de entiteiten te kennen. We nemen deze op in herkomst. Daarnaast is het objectief van herkomst om de betrouwbaarheid van een entiteit na te gaan. Deze entiteit kan dan ook gekoppeld worden aan entiteiten van het model: Persoon, Organisatie, Contact, Dienstverlening, Verblijfsobject. We hebben er voor gekozen om de herkomst te definiëren op niveau van een entiteit (logische clusters, die brongewijs samenhoren). Herkomst op niveau van individuele kenmerken bleek niet haalbaar voor lokale besturen. Wanneer één attribuut aangepast wordt, moet de herkomst van de entiteit aangepast worden. attribuut datatype mogelijke authentieke bron Bron Betrouwbaarheid Datum laatste wijziging Tekst Tekst Datum/tijd KSZ, RRK, KBO(V)KBO, CRAB, GRB, AAPB, eigen bestuur, bestuur, derden (niet limitatieve lijst) Betrouwbaarheid kan de volgende waarden aannemen: gekoppeld, eenmalig of manueel. De bedoeling is dat op basis van dit veld een betrouwbaarheid kan worden afgeleid als combinatie van de bron, hoe de gegevens gesynchroniseerd werden en wanneer de laatste wijziging was. OSLO Open Standaard voor Lokale Overheden 18

2.3.2.4 Opt-in Opt-in en opt-out zijn termen die aangeven hoeveel controle de burger heeft over het gebruik van zijn gegevens. Opt-in is daarbij de meest strenge optie: enkel wie ervoor kiest ( zich intekent ), zal hergebruik van zijn/haar gegevens toelaten. Door de gebruiker bij de verzameling van zijn gegevens (e-loket, loket, e.a.) te laten aangeven of deze gegevens mogen hergebruikt worden binnen een ander proces (bv. e-mailadres bibliotheek hergebruiken voor kinderopvang) schep je kansen voor het gebruik. attribuut datatype mogelijke authentieke bron Type Tekst (Lijst) Niet Beperkt tot proces: de gegevens mogen hergebruikt worden in kader van deze specifieke dienstverlening Intern: deze gegevens mogen hergebruikt worden binnen binnen alle processen van het lokaal bestuur Extern: de gegevens mogen door derden (extern aan het bestuur) hergebruikt worden. OSLO Open Standaard voor Lokale Overheden 19

2.4 Contactinformatie Hieronder volgt een overzicht van alle entiteiten en hun relaties. Voor een meer gedetailleerde versie van het diagramma verwijzen we naar het addendum. 2.4.1 Agent Agent is een supertype van PERSOON, ORGANISATIE en HOEDANIGHEID. Een agent is een entiteit die een rol kan aannemen in dienstverlening. De aanleiding van dit concept is om er enerzijds voor te zorgen dat er een ontkoppeling is tussen het domein contactinformatie en dienstverlening die zorgt voor meer stabiliteit van de standaard. De agent laat toe om in het domein dienstverlening abstractie te nemen van de entiteiten persoon, organisatie en hoedanigheid. Toekomstgericht is dit een goede praktijk daar dit toelaat om andere agents in te voeren zonder impact op het schema van de dienstverlening. Een mogelijk voorbeeld is het invoeren van een authentieke service die kan optreden als behandelaar in een dossier (algoritme). 2.4.2 Contact Dit type verrijkt een Persoon, Organisatie of Hoedanigheid met contactinformatie. attribuut datatype mogelijke authentieke bron Aanschrijfvorm Tekst Roepnaam Tekst RRK 4 Telefoon Mobiel Fax Social Tekst Tekst Tekst Tekst 4 De roepnaam is een veld dat voorzien is in het rijksregister, maar wordt zelden gebruikt. in het rijksregister wordt hier naar verwezen als pseudoniem (vb. artiestennaam) of verklaarde naam (vb. vreemdelingen worden ingeschreven in het vreemdelingenregister en die hun identiteit niet kunnen bewijzen). In de praktijk zal dit typisch een gegeven zijn dat op het lokaal niveau verrijkt wordt. OSLO Open Standaard voor Lokale Overheden 20

Website Opmerking Opt-in Tekst Tekst Tekst (Lijst) De aanschrijfvorm is de wijze van aanschrijven (adressering en aanhef) van personen waarop zij op grond van hun titel, maatschappelijke positie of functie aanspraak kunnen maken. De roepnaam of alias is de naam waar iemand in de vertrouwelijke sfeer gewoonlijk mee wordt aangesproken. Telefoon, Mobiel en Fax zijn niet verplichte attributen die meerdere keren mogen voorkomen. De formattering van deze velden zit op niveau van service beschrijving (zie hoofdstuk Gebruik) Social slaat op het gebruik van sociale media. Hierbij kan bvb. de gebruikersnaam (in combinatie met de naam van het social medium) uitgewisseld worden of de web-url van het publieke profiel van de gebruiker. Er is geen beperking op het aantal keer dat een attribuut mag voorkomen. Voorbeeld: Linkedin Account van een gebruiker. Url: http://www.linkedin.com/profile/view?id=155801872 of Netwerk: Linkedin, Id: 155801872 2.4.3 Verblijfsobject Zie sectie m.b.t. Lokalisatie. OSLO Open Standaard voor Lokale Overheden 21

2.4.4 Persoon De entiteit Persoon omvat kenmerken die een natuurlijk persoon beschrijven. Het begrip natuurlijk persoon benadert de mens niet als een biologische entiteit maar als een juridische. attribuut datatype mogelijke authentieke bron Naam Tekst RRK, KSZ, wachtregister Voornaam Tekst RRK, KSZ, wachtregister Andere voornamen Tekst RRK, KSZ, wachtregister Adellijke titel Tekst RRK, KSZ, wachtregister Geslacht Tekst (Lijst) RRK, KSZ, wachtregister Geboortedatum Datum/tijd RRK, KSZ, wachtregister Nationaliteit Tekst (Lijst) RRK, KSZ, wachtregister Datum overlijden Datum/tijd RRK, KSZ, wachtregister Burgerlijke staat Tekst RRK, KSZ, wachtregister Geboorteplaats Tekst RRK, KSZ, wachtregister Plaats van overlijden Tekst RRK, KSZ, wachtregister Wettelijk Samenwonend Bool RRK, KSZ, wachtregister Identificatie Identificatie RRK, KSZ, wachtregister relatie doelentiteit mogelijke authentieke bron Is gedomicilieerd op Verblijfsobject RRK, KSZ, wachtregister Verblijft op Verblijfsobject lokale verrijking Te bereiken op Heeft Juridische onbekwaamheid Contact Code OSLO Open Standaard voor Lokale Overheden 22

De waarden voor deze attributen zijn terug te vinden in de authentieke bronnen, waar van toepassing. De originele sleutel van deze data wordt dan gekoppeld aan Persoon via de Identificatie. Adellijke titel De adellijke titel is een eeraanbrengende onderscheiding 5. Geboorteplaats De geboorteplaats specificeert de geboorteplaats (administratief). Wanneer de persoon in een Belgische gemeente geboren is, zelfs in een afgeschafte gemeente (bv. door fusie), dan moet de N.I.S.-omschrijving (en code) van deze gemeente gebruikt worden. Wanneer de persoon in het buitenland geboren is, dan dient men de benaming voluit te schrijven. Daarnaast wordt de landencode opgegeven. Alternatief kan een ongestructureerde geboorteplaats opgegeven worden (enkel tekst). voorbeeld: - N.I.S.-omschrijving: ANTWERPEN (BERENDRECHT) - N.I.S.-CODE: 11212, Plaats van overlijden Plaats van overlijden specificeert de plaats en datum van het overlijden ( gerechterlijke beslissing tot verklaring van overlijden). Wanneer de persoon in een Belgische gemeente overleden is, zelfs in een afgeschafte gemeente (bv. door fusie), dan moet de N.I.S.- omschrijving (en code) van deze gemeente gebruikt worden. Wanneer de persoon in het buitenland overleden is, dan dient men de benaming voluit te schrijven. Daarnaast wordt de landencode opgegeven. Alternatief kan een ongestructureerde plaats van overlijden opgegeven worden (enkel tekst). Nationaliteit De nationaliteit:schept een specifieke band tussen een natuurlijk persoon en een bepaalde staat. Deze wordt ingegeven via ISO-3166-1 Alpha-3 of NIS en een beschrijving. Alternatief kan een ongestructureerde nationaliteit opgegeven worden (enkel tekst). Burgerlijke staat 5 Voor mogelijke waarden of voorbeelden verwijzen we naar de onderrichtingen voor het bijhouden van de informatiegegevens van het Rijksregister (http://www.ibz.rrn.fgov.be/fileadmin/user_upload/registre/nl/instructies/onderrichtingen_ 20120901.pdf, I.T. 012). OSLO Open Standaard voor Lokale Overheden 23

De term burgerlijke staat wordt in zijn enge betekenis gebruikt, d.w.z. ongehuwd, gehuwd, enz. We refereren hiervoor naar de codetabellen 6 van het rijksregister (code en omschrijving). Alternatief kan een ongestructureerde nationaliteit opgegeven worden (enkel tekst), typisch wanneer de bron onvoldoende granulair is. De beschouwde burgerlijke staten zijn : 10 ongehuwd 20 gehuwd 25 nietigverklaring van het huwelijk 26 putatief huwelijk 30 weduwnaar (weduwe) 40 gescheiden 41 echtscheiding uitgesproken met toepassing van de wet van 30 juni 1994 50 scheiding van tafel en bed en van goederen 51 scheiding van tafel en bed en van goederen uitgesproken met toepassing van de wet van 30 juni 1994 60 ontbinding van het huwelijk op een bijzondere wijze 80 partnerschap 81 beëindiging partnerschap 90 onbepaald Burgerlijke staat wordt opgenomen als kenmerk en als type persoonsrelatie. Dit laat toe om dit kenmerk ook op te nemen wanneer er geen relaties beschikbaar zijn. Wettelijk Samenwonend De wetgever biedt op deze manier de mogelijkheid een officieel karakter te geven aan de vormen van samenwoning ten einde een relatieve juridische zekerheid te verzekeren voor de samenwonenden. Onder wettelijke samenwoning wordt de toestand van samenleven van twee personen verstaan die de verklaring van wettelijke samenwoning hebben afgelegd bij de ambtenaar van de burgerlijke stand van de gemeenschappelijke woonplaats 7. 6 Voor mogelijke waarden of voorbeelden verwijzen we naar de onderrichtingen voor het bijhouden van de informatiegegevens van het Rijksregister (http://www.ibz.rrn.fgov.be/fileadmin/user_upload/registre/nl/instructies/onderrichtingen_ 20120901.pdf, I.T. 120). 6 7 Voor mogelijke waarden of voorbeelden verwijzen we naar de onderrichtingen voor het bijhouden van de informatiegegevens van het Rijksregister (http://www.ibz.rrn.fgov.be/fileadmin/user_upload/registre/nl/instructies/onderrichtingen_ 20120901.pdf, I.T. 123). OSLO Open Standaard voor Lokale Overheden 24

Wettelijk samenwonend wordt opgenomen als kenmerk en als type persoonsrelatie. Dit laat toe om dit kenmerk ook op te nemen wanneer er geen relaties beschikbaar zijn. Juridische onbewaamheid Deze informatie heeft tot doel voor een persoon die wordt vertegenwoordigd of bijgestaan zijn toestand op te nemen, alsook de rechtvaardiging van zijn toestand. We refereren hiervoor naar de codetabellen van het rijksregister 8 (code en omschrijving). Alternatief kan een ongestructureerde nationaliteit opgegeven worden (enkel tekst). De verschillende mogelijke toestanden worden opgenomen met de volgende codes : 50 de persoon is ontvoogd (voor niet gehuwde minderjarigen) 61 de persoon is geplaatst onder statuut van verlengde minderjarigheid 62 de persoon is hersteld in zijn rechten 63 de persoon is onbekwaam verklaard 65 de persoon is ten huize afgezonderd 67 de persoon is geplaatst in een instelling 68 onder voorlopige bewindvoering 69 bijstand gerechtelijk raadsman. De rechtsmacht die de beslissing heeft genomen, wordt niet opgenomen in OSLO. Identificatie De identifier is de sleutel waarmee gerefereerd wordt naar de de entiteit persoon. Voor een uitgebreide beschrijving van de identificatie verwijzen we naar de definitie (hoofdstuk 2.3.2.2). Binnen de context van een natuurlijke persoon adviseren we om, indien beschikbaar, gebruik te maken van het identificatienummer 9 van het Rijksregister van de natuurlijke personen, of het nationaal nummer, genoemd. Het gebruik van het rijksregisternummer is aan strikte wettelijke voorwaarden onderworpen, we verwijzen hiervoor naar het hoofdstuk m.b.t. informatieveiligheid (hoofdstuk 4.3). Indien er geen rijksregisternummer beschikbaar is, kan een alternatieve sleutel gebruikt worden. Hierbij wordt dan typisch de referentie naar de (lokale) bron meegegeven. Is gedomicilieerd op 8 Voor mogelijke waarden of voorbeelden verwijzen we naar de onderrichtingen voor het bijhouden van de informatiegegevens van het Rijksregister (http://www.ibz.rrn.fgov.be/fileadmin/user_upload/registre/nl/instructies/onderrichtingen_ 20120901.pdf, I.T. 111). 9 voor de structuur van het rijksregister en bisnummer verwijzen we naar hoofdstuk 4.2.1 OSLO Open Standaard voor Lokale Overheden 25

Een domicilie is het "officiële adres", het adres waar men volgens de bevolkingsregisters woont. Dit kan verschillen van de feitelijke verblijfplaats (zie verblijfplaats). Zo hebben veel studenten hun domicilie nog thuis, maar verblijven zij in feite in de stad waar ze studeren. Voor de precieze omschrijving van het begrip hoofdverblijfplaats moet verwezen worden naar de Algemene Onderrichtingen 10 betreffende het houden van de bevolkingsregisters Geslacht Daarvoor worden codes gebruikt volgens ISO/IEC 5218: 0 = onbekend (ONB), 1 = man (M), 2 = vrouw (V), 9 = niet van toepassing (NVT). Verblijft op De verblijfplaats is het correspondentieadres waarnaar eventuele briefwisseling wordt gestuurd (feitelijke verblijfplaats). Zo hebben veel studenten hun domicilie nog thuis, maar verblijven zij in feite in de stad waar ze studeren. Het betreft een lokaal verrijkt gegeven. Wanneer de woonplaats tevens de verblijfplaats is, moet er geen verblijfplaats gemeld worden. Is te bereiken op Dit type verrijkt een Persoon, Organisatie of Hoedanigheid met contactinformatie. We verwijzen hiervoor naar hoofdstuk 2.3.1 10 Voor mogelijke waarden of voorbeelden verwijzen we naar de onderrichtingen voor het bijhouden van de informatiegegevens van het Rijksregister (http://www.ibz.rrn.fgov.be/fileadmin/user_upload/registre/nl/instructies/onderrichtingen_20120901.pdf, I.T. I.T. 018 I.T. 019 I.T. 020 I.T. 022 I.T. 023 I.T. 026). OSLO Open Standaard voor Lokale Overheden 26

2.4.5 Persoonsrelatie We voorzien volgende types personenrelatie tussen personen: Afstamming De afstamming is de juridische band tussen een kind en zijn vader of moeder. De informatie afstamming, in het rijksregister gekenmerkt door het informatietype 110, bevat in hoofdzaak de identiteit van de ouders en de wijze van afstamming. In de standaard beperken we ons tot de relatie ouder / kind (van het kind naar de ouder). Referentiehuishouden Een referentiehuishouden is een eenheid van personen die allen dezelfde referentiepersoon hebben, zoals vastgelegd in het rijksregister. De informatie "samenstelling van het gezin" vertoont twee aspecten met de relatie behoort tot wordt elk lid van het gezin opgenomen (een relatie tussen de entiteit persoon en de entiteit persoonsrelatie). Als type wordt de plaats in het gezin van de verschillende leden van het gezin opnomen (voorbeeld: zoon, dochter), dit ten opzichte van de referentiepersoon. de relatie refereert geeft aan wie de referentiepersoon van het gezin 11 in het rijksregister is. De plaats in het gezin kan met de volgende codes ingebracht worden (niet exhaustief 12 ): 01 alleenstaand referentiepersoon van het gezin 02 echtgenoot, echtgenote 11 Voor mogelijke waarden of voorbeelden verwijzen we naar de onderrichtingen voor het bijhouden van de informatiegegevens van het Rijksregister (http://www.ibz.rrn.fgov.be/fileadmin/user_upload/registre/nl/instructies/onderrichtingen_ 20120901.pdf, I.T. 140 en I.T. 141). 12 voor een exhautieve lijst verwijzen we naar Voor mogelijke waarden of voorbeelden verwijzen we naar de onderrichtingen voor het bijhouden van de informatiegegevens van het Rijksregister (http://www.ibz.rrn.fgov.be/fileadmin/user_upload/registre/nl/instructies/onderrichtingen_ 20120901.pdf, I.T. 141- $347 - plaats in het gezin). 12 OSLO Open Standaard voor Lokale Overheden 27

03 zoon, dochter 04 schoonzoon, schoondochter 05 kleinzoon, kleindochter 06 vader, moeder We refereren hiervoor naar de codetabellen van het rijksregister (code en omschrijving). Alternatief kan een ongestructureerd verband opgegeven worden (enkel tekst). Gezin De term verwijst naar de personen die het feitelijke gezin vormen en hoeven niet noodzakelijkerwijze behoren tot het referentiehuishouden. Het gezin is een lokaal verrijkte relatie, en geeft dus een andere kijk op de gezinssamenstelling dan deze in het rijksregister. voorbeeld: bij de inschrijving van kinderen op een sportkamp (kinderopvang lokaal bestuur), dienen ingeval nieuw-samengestelde gezinnen ook kinderen die niet tot het referentiehuishouden behoren, ingescheven te kunnen worden. Voor het type relatie refereren we naar de codetabellen van het rijksregister van het referentiehuishouden (code en omschrijving). Alternatief kan een ongestructureerd verband opgegeven worden (enkel tekst). Voogd Een voogd is in het recht een handelingsbekwame (rechts)persoon die instaat voor de persoon en de goederen van een onbekwame of minderjarige. Deze informatie heeft tot doel voor een persoon die wordt vertegenwoordigd of bijgestaan zijn toestand op te nemen, alsook de rechtvaardiging van zijn toestand en de rechtsmacht die de beslissing heeft genomen. De relatie wordt gelegd vanuit de persoon die vertegenwoordigt of bijstaat. Enkel de actuele toestand wordt doorgegeven (geen historiek). We refereren hiervoor naar de codetabellen van het rijksregister 13 (code en omschrijving). Alternatief kan een ongestructureerd verband opgegeven worden (enkel tekst). 13 Voor mogelijke waarden of voorbeelden verwijzen we naar de onderrichtingen voor het bijhouden van de informatiegegevens van het Rijksregister (http://www.ibz.rrn.fgov.be/fileadmin/user_upload/registre/nl/instructies/onderrichtingen_ 20120901.pdf, I.T. 113). OSLO Open Standaard voor Lokale Overheden 28

10 : voor niet ontvoogde minderjarigen of onder statuut van verlengde minderjarigheid : adres van de vader (of van de moeder) indien het verschilt van dat van de minderjarige; 21 : wettig beheerder (een ander persoon dan de vader of de moeder) : identificatienummer of naam en adres; 22 : voogd : identificatienummer of naam en adres; 23 : persoon die het hoederecht bezit : identificatienummer of naam en adres; 24 : voorlopige bewindvoerder; 25 : gerechtelijke raadsman; 26 : curator. Burgerlijke staat De term burgerlijke staat wordt in zijn enge betekenis gebruikt, d.w.z. ongehuwd, gehuwd, enz. We refereren hiervoor naar de codetabellen 14 van het rijksregister (code en omschrijving). Alternatief kan een ongestructureerde burgerlijke staat opgegeven worden (enkel tekst). De beschouwde burgerlijke staten zijn : 10 ongehuwd 20 gehuwd 25 nietigverklaring van het huwelijk 26 putatief huwelijk 30 weduwnaar (weduwe) 40 gescheiden 41 echtscheiding uitgesproken met toepassing van de wet van 30 juni 1994 50 scheiding van tafel en bed en van goederen 51 scheiding van tafel en bed en van goederen uitgesproken met toepassing van de wet van 30 juni 1994 60 ontbinding van het huwelijk op een bijzondere wijze 80 partnerschap 81 beëindiging partnerschap 90 onbepaald 14 Voor mogelijke waarden of voorbeelden verwijzen we naar de onderrichtingen voor het bijhouden van de informatiegegevens van het Rijksregister (http://www.ibz.rrn.fgov.be/fileadmin/user_upload/registre/nl/instructies/onderrichtingen_ 20120901.pdf, I.T. 120). 14 OSLO Open Standaard voor Lokale Overheden 29

Burgerlijke staat wordt opgenomen als kenmerk en als type persoonsrelatie. Dit laat toe om dit kenmerk ook op te nemen wanneer er geen relaties beschikbaar zijn. attribuut datatype mogelijke authentieke bron Geldigheidsperiode Tijdspanne relatie doelentiteit mogelijke authentieke bron Type Code Behoort tot Persoon RRK, KSZ, wachtregister Refereert Persoon RRK, KSZ, wachtregister 2.4.5. Organisatie Het domein Organisatie omvat alle zelfstandig, geordende samenwerkingsverbanden, met uitzondering van familiale verbanden, tussen natuurlijke en/of rechtspersonen die bepaalde activiteiten uitvoeren. Dit kan gaan om een rechtspersoon: een juridische constructie waardoor een abstracte entiteit (organisatie) op kan treden als een persoon in het rechtsverkeer, gelijk een natuurlijk persoon dat kan doen. Dat wil zeggen, een rechtspersoon kan bezittingen en schulden hebben, contracten sluiten, rechtszaken aanspannen of aangeklaagd worden. enerzijds Economische of sociale actoren die op Belgisch grondgebied willen ondernemen, zullen als onderneming gekend zijn in KBO. anderzijds kan een organisatie ook een buitenlandse onderneming zijn, of een lokale verrijking natuurlijke persoon als onderneming (eenmanszaken), feitelijke verenigingen: maken geen deel uit van de (V)KBO. Context Belgisch recht: een feitelijke vereniging ontstaat van zodra twee of meer personen het idee ontwikkelen om gezamenlijk een ideëel doel te verwezenlijken. Doordat de feitelijke vereniging geen juridische grond heeft, kan zij geen verbintenissen aangaan, geen eigendommen bezitten, geen schenkingen of legaten aanvaarden en zijn het de individuele leden die zich persoonlijk verbinden tot de verplichtingen van de vereniging. OSLO Open Standaard voor Lokale Overheden 30

Het attribuut bron (entiteit herkomst) zal aangeven wat de herkomst van de gegevens is. Voor de ondernemingen waarvoor de bron (V)KBO is, zijn een aantal regels van toepassing, deze worden per attribuut opgelijst. We opteren er voor om maximaal gebruik te maken van authentieke bronnen. Wanneer er geen authentieke gegevensbronnen beschikbaar zijn, adviseren we om, waar mogelijk, maximaal gebruik te maken van bestaande catalogi (voorbeeld: zoals de rechtstoestand). attribuut datatype mogelijke authentieke bron Maatschappelijke naam Tekst (V)KBO Commerciële naam Tekst (V)KBO Afgekorte naam Tekst (V)KBO Vestiging Bool (V)KBO Oprichtingsdatum Datum/tijd (V)KBO Datum stopzetting Datum/tijd (V)KBO KBO reden stopzettting Tekst (V)KBO KBO rechtsvorm Tekst (Lijst) (V)KBO KBO rechtstoestand Tekst (Lijst) (V)KBO KBO hoedanigheidsfase Code (V)KBO KBO soort Tekst (Lijst) (V)KBO Identificatie Identificatie (V)KBO Type Code relatie doelentiteit mogelijke authentieke bron Heeft KBO-locatie Verblijfsobject (V)KBO Te factureren op Ontvangt post op Ontvangt leveringen op Verblijfsobject Verblijfsobject Verblijfsobject OSLO Open Standaard voor Lokale Overheden 31

Heeft KBO status Code (V)KBO Oefent primair uit Code (V)KBO Oefent secundair uit Code (V)KBO Heeft KBO Hoedanigheid Code (V)KBO Te bereiken op Contact Maatschappelijke naam Voor een onderneming De officiële naam van een onderneming, zoals verschenen in het staatsblad. Commerciële naam De commerciële naam is de gekende handelsnaam van een onderneming of vestigingseenheid. Afgekorte naam De officiële afgekorte benaming of roepnaam van een onderneming met ondersteuning van meertaligheid. OSLO Open Standaard voor Lokale Overheden 32

Vestiging Deze indicatie bepaalt ondubbelzinnig of men een Onderneming of een Vestigingseenheid behandelt. Mogelijke waarden: 1 = Onderneming 2 = Vestiging VKBO raadt businessgewijs aan de dimensies ONDERNEMING en VESTIGINGSEENHEID zoveel mogelijk te scheiden: de eerste is een juridische dimensie (WIE), de tweede een geografische dimensie (WAAR). De identificatiesleutels (van beide dimensies) en hun attributen worden op (V)KBO-niveau evenwaardig behandeld. Oprichtingsdatum De datum waarop de onderneming is opgericht. Regels voor ondernemingen: Voor rechtspersonen die opgericht worden met een authentieke akte, is dit de datum waarop de akte gedagtekend wordt. Voor rechtspersonen zonder authentieke akte (onderhands, bepaald bij wet of KB's,...) is dit de datum waarop de rechtspersonen erkend worden ten opzichte van derden. Voor ondernemingen van natuurlijke personen is dit de datum waarop de natuurlijke persoon met de onderneming wenst te starten. De datum wordt ingevuld bij creatie en wordt niet meer gewijzigd. De datum wordt opgegeven door de gebruikers (niet automatisch bepaald). Ongeveer 1,5% van de ondernemingen/vestigingen in KBO hebben een fictieve startdatum ('1800-01-01') vermits de echte startdatum niet gekend was bij oprichting KBO (in 2003). Datum stopzetting Datum waarop de onderneming is stopgezet. Deze datum is enkel ingevuld als de onderneming officieel stopgezet is, dit betekent dat alle activiteiten en hoedanigheden (bv. BTW-plicht) werden stopgezet én dat alle administratieve formaliteiten werden afgerond. OSLO Open Standaard voor Lokale Overheden 33

Wanneer een onderneming stopgezet is, zullen ook alle onderliggende gegevens stopgezet worden. De uitzonderingen daarop zijn rechtstoestand en toelating. Een onderneming die stopgezet is, kan nog opnieuw geactiveerd worden nl. als de activiteiten van de onderneming alsnog worden hernomen. Reden stopzettting Als een onderneming wordt stopgezet, geeft deze code de reden van stopzetting aan. Rechtsvorm onderscheid tussen een onderneming, feitelijke vereniging en andere samenwerkingsverbanden, verwerken we door gebruik te maken van alternatieve catalogi. voor ondernemingen met al bron (V)KBO De rechtsvorm van een bedrijf, onderneming of organisatie, is de juridische vorm waarin de onderneming is gegoten. Voor een overzicht van deze nomenclatuur verwijzen we naar de codetabel van FOD Economie. (http://economie.fgov.be/nl/modules/publications/publicaties_kbo/les_donnees_juridiques.jsp#fo rms!a1) Rechtstoestand De rechtstoestand van de onderneming op een bepaald moment van zijn levenscyclus (bv. Bekendmaking van de onderneming, Opening faillissement ), Fusie door overneming ). Rechtstoestanden zijn niet van toepassing voor vestigingseenheden. Voor een overzicht van deze nomenclatuur verwijzen we naar de codetabel van FOD Economie. (http://economie.fgov.be/nl/modules/publications/publicaties_kbo/les_donnees_juridiques.jsp#fo rms!a1) KBO hoedanigheid en KBO hoedanigheidsfase Hoedanigheden bevatten de hoedanigheden die worden uitgeoefend alsook de verkregen toelatingen. De hoedanigheidinformatie staat voor 'hoedanigheden' die de onderneming uitoefent zoals OSLO Open Standaard voor Lokale Overheden 34

ambachtsman werkgever RSZ BTW plichtig geregistreerd aannemer handelsonderneming werkgever RSZ PPO echte 'toelatingen' in de zin van erkenning vergunning Voor een hoedanigheid of toelating zijn de volgende fases bekend in KBO: dossier in onderzoek hoedanigheid verworven hoedanigheid stopgezet hoedanigheid geweigerd hoedanigheid geannuleerd De hoedanigheid (en de fase) wordt geregistreerd in KBO door de bevoegde instrumenterende overheid zoals daar zijn BTW, RSZ, Ondernemingsloket (OLK), Vennootschapsbelasting (VEB), PPO, SCO, GRI, etc. We wisselen codes en indien van toepassing ook omschrijving uit. Dit zou moeten volstaan als referentie. Type Het type organisatie maakt gebruik van een codetabel die toelaat om een lijst met type organisties te definiëren. Identificatie De identifier is de sleutel waarmee gerefereerd wordt naar de de entiteit organisatie. Voor een uitgebreide beschrijving van de identifier verwijzen we naar de definitie (hoofdstuk 2.3.2.2). Binnen de context van een onderneming adviseren we om, indien beschikbaar, gebruik te maken van het identificatienummer van de (V)KBO: het ondernemingsnummer of vestigingsnummer. Indien er geen ondernemingsnummer of vestigingsnummer beschikbaar is, kan een alternatieve sleutel gebruikt worden. Hierbij wordt dan typisch de referentie naar de (lokale) bron OSLO Open Standaard voor Lokale Overheden 35

meegegeven. Ingeval buitenlandse BTW-plichtige ondernemingen wordt er bij voorkeur gewerkt met de internationale identificatienummer 15. Ondernemingsnummer of Vestigingsnummer. De unieke identificatie van een onderneming, toegekend door KBO. Afhankelijk van de dienst en context staat het ondernemingsnummer soms ook voor de unieke identificatie van een vestigingseenheid (vestigingseenheidnummer). Het ondernemingsnummer is een uniek identificatienummer toegekend aan de ondernemingen door KBO (Kruispuntbank van Ondernemingen), beheer door de FOD Economie (= de Federale Overheidsdiensten Economie, KMO, Middenstand en Energie). Het ondernemingsnummer vervangt het vroegere Handelsregisternummer, het BTW-nummer, het nummer van het Rijksregister voor Rechtspersonen (RRRP-nummer of Nationaal Nummer) én het RSZ-nummer. KBO soort Deze indicatie bepaalt ondubbelzinnig of men een Natuurlijk Persoon of een Rechtspersoon behandelt. Onder type onderneming verstaan we de buitenlandse en Belgische ondernemingen die in België willen ondernemen en dit ofwel in eigen naam via een onderneming van natuurlijke persoon zoals bvb. zelfstandige handelaars; ofwel via een rechtspersoon of organisatie zonder rechtspersoonlijkheid zoals bvb. handelsvennootschappen. Mogelijke waarden: 1 = Natuurlijk Persoon 2 = Rechtspersoon Heeft KBO locatie Dit is het officiële adres van de maatshappelijke zetel of vestiging, toegekend door KBO (publicatie staatsblad). Indien alternatieve adressen vereist zijn (ten gevolge van een correctie of het een onderneming betreft dat niet in de KBO opgenomen is), dient er gebruik gemaakt te worden van het contactadres. 15 Systeem voor de uitwisseling van BTW-informatie (VIES) geldigverklaring BTW-nummer http://ec.europa.eu/taxation_customs/vies/ OSLO Open Standaard voor Lokale Overheden 36

Adres van de maatschappelijke zetel: officiëel adres van de maatschappij (voor een rechtspersoon of organisatie zonder rechtspersoonlijkheid is dit het officiële adres van de maatschappij) Adres van de vestigingseenheid (het adres van een vestigingseenheid is steeds een Belgisch adres). Ontvangt post op Dit is het lokaal verrijkte adres van de maatschappelijke zetel of vestiging, afwijkend van KBO (publicatie staatsblad) dat typisch gebruikt wordt indien er alternatieve adressen vereist zijn (ten gevolge van een correctie of het een onderneming betreft dat niet in de KBO opgenomen is). Te factureren op Dit is het lokaal verrijkte adres van de maatschappelijke zetel of vestiging, afwijkend van KBO (publicatie staatsblad) dat typisch gebruikt wordt indien er specifieke facturatie-adressen vereist zijn. Ontvangt leveringen op Dit is het lokaal verrijkte adres van de maatschappelijke zetel of vestiging, afwijkend van KBO (publicatie staatsblad) dat typisch gebruikt wordt indien er specifieke facturatie-adressen vereist zijn. Heeft KBO status Deze status duidt aan in welk stadium van zijn levenscyclus de onderneming zich bevindt binnen KBO (bv. actief, stopgezet, afgesloten, juridisch gecreërd).juridisch gecreërd is enkel van toepassing op de onderneming zelf. Een onderneming rechtspersoon wordt eerst "op papier" aangemaakt, op dat moment wordt een ondernemingsnummer toegewezen en heeft die onderneming status 'juridisch gecreërd'. Zolang een onderneming de status 'juridisch gecreërd' heeft kunnen er geen vestigingseenheden aangemaakt worden. 'juridisch gecreërd' is niet van toepassing op vestigingseenheden. Op een bepaald moment in het administratief proces krijgt de onderneming dan status 'Actief'. Mogelijke statussen zijn: AC: actief ST: stopgezet AF: afgesloten JU: juridisch gecreëerd OSLO Open Standaard voor Lokale Overheden 37

AN: geannuleerd (bvb. correctie van ooit gecreëerde dubbels, t.t.z. verschillende ondnr voor eenzelfde vzw) BK: bekendgemaakt De volgende statussen worden voorzien : voor een onderneming van natuurlijke persoon : actief stopgezet afgesloten geannuleerd (bvb. gecreëerde dubbels) bekendgemaakt voor een onderneming van rechtspersoon : Juridisch gecreëerd: ingeschreven in KBO (uniek nummer toegewezen) actief (opgericht) stopgezet / ontbonden afgesloten geannuleerd bekendgemaakt voor een vestigingseenheid : actief = vestigingseenheidnummer in gebruik stopgezet = vestigingseenheid is niet verder overgedragen afgesloten = vestigingseenheidnummer niet meer in gebruik geannuleerd (dubbel gebruik tegenover andere vestigingseenheid) Via de (lijst (versie en bron van codetabel) kunnen nieuwe lijsten gekoppeld worden. OSLO Open Standaard voor Lokale Overheden 38

Oefent primair uit Oefent secundair uit De codes voor (primaire en secundaire) activiteiten worden gedefinieerd door de Nacebelcodes 16. De NACE-code is een cijfercode die door de Europese Unie en haar lidstaten toegekend wordt aan een bepaalde klasse van economische activiteiten (al dan niet commercieel). Dit is bedoeld als hulpmiddel bij het opstellen van economische statistieken en overzichten. De Europese nomenclatuur vormt het referentiekader voor de productie en de verspreiding van statistieken met betrekking tot economische activiteiten in Europa Het type code voorziet dat we met verschillende versies van Nacebel kunnen werken (bv. 2003 en 2008) en dat we alternatieve catalogi kunnen gebruiken die meer gericht zijn op wegwijsinformatie (bv. de bedrijvengids van Intercommunale Leiedal). Doordat activiteit een code is kan de instrumenterende overheid mee uitgewisseld worden via de bron en de naam van de lijst evt. aangevuld met een versie. Dit zal een belangrijke indicatie voor de kwaliteit zijn. Te bereiken op Dit type verrijkt een Persoon, Organisatie of Hoedanigheid met contactinformatie. We verwijzen hiervoor naar hoofdstuk 2.3.1 2.4.6 Organisatierelatie De organisatierelatie laat toe om type-relaties tussen organisaties te definiëren. Hierbij wensen we éénduidig aan te geven of het een vestiging gaat of een deelorganisatie. voorbeeld: een vestiging van Belfius Bank in Mariakerke behoort tot de Maatschappelijke zetel van Belfius Bank de maatschappelijke zetel van Belfius Bank groepeert een aantal vestigingen Vestiging Is een type organisatierelatie: relatie tussen een maatschappelijke zetel van een onderneming en zijn vestigingen. 16 http://statbel.fgov.be/nl/statistieken/gegevensinzameling/nomenclaturen/nacebel/ OSLO Open Standaard voor Lokale Overheden 39

Deelorganisatie Is een type organisatierelatie. Voorbeelden: een relatie tussen een organisatie en zijn afdelingen een historische relatie tussen ondernemingen (overnames, fusies, splistingen) Deze relaties hebben typisch een bepaalde geldigheidsduur. Er kan met behulp van deze entiteit een hierarchische structuur weergegeven worden. De preciese toedracht en semantiek van de relaties valt buiten het domein van deze standaard. attribuut datatype mogelijke authentieke bron Geldigheidsperiode Tijdspanne relatie doelentiteit mogelijke authentieke bron Groepeert Behoort tot Type Organisatie Organisatie Code OSLO Open Standaard voor Lokale Overheden 40

2.4.7. Hoedanigheid De contactgegevens van een persoon bevatten andere data, afhankelijk van de hoedanigheid (natuurlijke persoon, verantwoordelijke binnen een bedrijf of voorzitter van een vereniging) waarin men die persoon wil contacteren. Om de juiste contactgegevens van een persoon door te geven, moeten we dus de context kennen waarbinnen die gegevens worden gevraagd. Dit is toegelicht in de onderstaande figuur: Jan (natuurlijke persoon) heeft contactgegevens waarop hij te bereiken is (telefoon, e-mail, social). Jan heeft en mandaat als penningmeester bij de organisatie gezond sporten, we noemen dit de hoedanigheid (Jan had naast penningmeester ook nog andere hoedanigheden kunnen hebben : voorzitter ouderraad, mandataris binnen de stad of CEO van een onderneming). Op de website van gezond sporten staat er als functie schatbewaarder (dit is de functie van Jan die op zijn visitekaartje staat, op het niveau van de hoedanigheid, een vrij tekstveld). Voor het type functie maken we echter gebruik van een vaste lijst. We gebruiken hierbij de functie penningmeester (dit is handig om vanuit de CRM van de stad alle penningmeester aan te schrijven). Als penningmeester heeft Jan een e-mailadres bij de organisatie gezond sporten, een ander telefoonnumer en een specifiek postadres. De organisatie gezond sporten heeft op haar beurt eigen contactgegevens waaronder een website, Facebookpagina en een algemeen telefoonnummer. Figuur: Voorbeeld modellering natuurlijke persoon en relatie met organisatie. OSLO Open Standaard voor Lokale Overheden 41

Een hoedanigheid bepaalt een relatie tussen een natuurlijke persoon en een organisatie. Het de functie die men vervult binnen een Organisatie als Persoon. Functie omschrijft de hoedanigheid, te vergelijken met wat er typisch op een visitekaartje staat (dit attribuut heeft verder geen formele betekenis). voorbeeld: directeur Het hoedanigheidstype is een lijst met vaste waarden. voorbeeld: zaakvoerder (bvba) De contactgegevens kunnen daarbij verschillen per hoedanigheid: een persoon kan meerdere hoedanigheden kan hebben voorbeeld: medewerker brandweer, voorzitter ouderraad, medewerker Stad verschillende adressen, e-mailadressen en telefoonnummers In sommige gevallen kan de contactinformatie van een organisatie vervallen. Typisch wanneer er maar één contacpersoon gekend is en de informatie opgenomen is bij de hoedangheid. attribuut datatype mogelijke authentieke bron Functie Geldigheidsperiode Type Tekst Tijdspanne Code Functie Functie omschrijft de hoedanigheid, te vergelijken met wat er typisch op een visitekaartje staat (dit attribuut is een vrij veld en heeft verder geen formele betekenis). voorbeeld: business development manager, managing partner, algemeen directeur e.a. Type Is een formele lijst van functies. voorbeeld: (onderneming, bvba) zaakvoerder Onderstaande paragraaf geeft een overzicht van mogelijke bronnen van types Ondernemingen (V)KBO OSLO Open Standaard voor Lokale Overheden 42

Voor hoedanigheden binnen ondernemingen adviseren we om te werken op basis van van de informatie m.b.t. de functie (= oprichter, zaakvoerder, afgevaardigd bestuurder enz.) die een persoon óf Onderneming (= functiehouder) uitoefent bij een bepaalde onderneming. De onderliggende data wordt aangeleverd vanuit een KBO-tabel die wordt gevoed door de notarissen, griffies en ondernemingsloketten die de functies registreren (bij creatie of mutatie van een onderneming) die door een persoon of onderneming worden uitgeoefend binnen een bepaalde onderneming. Ambtenaren en feitelijke verenigingen Er is geen authentieke bron beschikbaar. Er wordt typisch gewerkt met een lokaal opgebouwde codelijst. relatie doelentiteit mogelijke authentieke bron Persoon Organisatie Contact Type Is beschikbaar op Ontvangt post op Persoon Organisatie Contact Code Verblijfsobject Verblijfsobject 2.5 Lokalisatie Het domein Lokalisatie omvat alles nodig om de plaats, door adressering of georeferentie, van objecten in de openbare ruimte aan te duiden, te verwerken en toe te passen. Voor een overzicht van alle entiteiten en hun relaties verwijzen we naar het addendum. OSLO Open Standaard voor Lokale Overheden 43

2.5.1 Locatie Een locatie bestaat uit een geometrie en een bepaalde geldigheidsduur en fungeert als ontkoppelpunt tussen business objecten (natuurlijke personen, organisaties, e.a.) en de authentieke geografische gegevens. Dit moet toelaten om het probleem van volatiele sleutels (die wijzigen ondanks het feit dat de locatie zelf ongewijzigd blijft) te ondervangen. Voorbeeld: wanneer de panden in een straat hernummerd worden. Bij een rechtstreeks koppeling aan een natuurlijke persoon of onderneming lijkt het alsof deze verhuisd is (subsidieregeling). attribuut datatype mogelijke authentieke bron Geldigheidsperiode Tijdspanne relatie doelentiteit mogelijke authentieke bron Geometrie Geometrie 2.5.2 Verblijfsobject Een VERBLIJFSOBJECT is de kleinste binnen één of meer panden gelegen en voor woon -, bedrijfsmatige, of recreatieve doeleinden geschikte eenheid van gebruik die ontsloten wordt via een eigen afsluitbare toegang vanaf de openbare weg, een erf of een gedeelde verkeersruimte, onderwerp kan zijn van rechtshandelingen en in functioneel opzicht zelfstandig is. Een verblijfsobject is een specifiekere vorm van locatie. Een verblijfsobject heeft naast een geometrie ook voorziening voor een Adres, Gebouw en Perceel. attribuut datatype mogelijke authentieke bron Geldigheidsperiode Tijdspanne relatie doelentiteit mogelijke authentieke bron Heeft geometrie Geometrie OSLO Open Standaard voor Lokale Overheden 44

Heeft gebouw Heeft perceel Adresseert Gebouw Perceel Adres 2.5.3 Perceel Een kadastraal perceel is een min of meer groot deel van het grondgebied gelegen in een zelfde gemeente of gehucht, gekenmerkt door eenzelfde aard of soort van bebouwing en toebehorend aan een zelfde persoon (hetgeen geen onverdeeldheden uitsluit, eenzelfde recht kan gedeeld worden door meerdere titularissen). 17 Van een kadastraal perceel wordt enkel de identifier sleutel bijgehouden: de CaPaKey De CaPaKey is de unieke (kadastrale) perceelsidentificatie die de Algemene Administratie van de Patrimoniumdocumentatie (A.A.P.D.) toekent aan elk kadastraal perceel in België. Deze perceelsidentificator wordt genoteerd als vast formaat (fixed format) en is een samenvoeging van de deelsleutels kadastrale afdelingscode, kadastrale sectiecode en kadastraal perceelsnummer. relatie doelentiteit mogelijke authentieke bron Identificatie Identificatie Kadastrale legger Voor de geometrie verwijzen we bij voorkeur naar het grootschalig referentiebestand (GRB), als referentiesleutel kan de CaPaKey gebruikt worden. De geometrische voorstelling van percelen volgens het AAPD (Cadmap Cadgis) of een eigen percelenkaart kan voorlopig als alternatief gebruikt worden. Dit in afwachting van de gebiedsdekkendheid en het verplichte gebruik van het GRB. De kaart van het AAPD vandaag nog bekend is als Cadmap, zal volgend jaar een naamsverandering ondergaan nl. Cadgis. 2.5.4 Gebouw Voor gebouwen aligneren we ons maximaal op gebouwen uit Het Grootschalig Referentiebestand (GRB) (AGIV). 17 bron: AGIV http://www.agiv.be/gis/knowhow/?artid=149 OSLO Open Standaard voor Lokale Overheden 45

GRB is een verzameling van geografische gegevens die in verschillende entiteiten ondergebracht worden. Elke entiteit wordt benoemd met een 3-letter acronym. Zo worden de gebouwen verzameld in de entiteit Gbg, wat staat voor gebouw aan de grond. Een gebouw aan de grond (gbg) is een duurzaam bouwsel, vast met het aardoppervlak verbonden, dat een voor mensen toegankelijke ruimte omsluit. Een gelijkvloerse toegang voor ondergrondse of hangende constructies wordt eveneens als gebouw aan de grond beschouwd. Bepaalde duurzame bouwsels die aan bovenstaande definitie beantwoorden, worden echter in andere GRB-entiteiten opgenomen en niet hier. Bijvoorbeeld koeltorens, watertorens, e.d. worden opgenomen als kunstwerk (entiteit Knw). 18 attribuut datatype mogelijke authentieke bron Geldigheidsperiode Tijdspanne GRB Bouwjaar Datum/tijd Identificatie identificatie GRB relatie doelentiteit mogelijke authentieke bron Geometrie geometrie GRB Perceel perceel GRB Status code GRB 2.5.5 Basis Adres Om adressen te modelleren zijn er twee entiteiten die elkaar aanvullen: Basis Adres en Uitgebreid Adres. Basis Adres is maximaal gealigneerd op gegevens uit het CRAB, maar kunnen aangevuld worden met lokaal verrijkte gegevens op basis van andere (authentieke) bronnen. 18 bron AGIV: http://download.agiv.be/producten/detail?id=388&title=grb_gbg_gebouw_aan_de_grond OSLO Open Standaard voor Lokale Overheden 46

attribuut datatype mogelijke authentieke bron Geldigheidsperiode Tijdspanne CRAB Land Tekst (Land) Indien bron CRAB: default België Gemeente Tekst CRAB Postcode Numeriek CRAB Straatnaam Tekst CRAB Huisnummer (Nummeraanduiding) Tekst CRAB Locator (busnummer) Tekst CRAB Identificatie Identificatie CRAB relatie doelentiteit mogelijke authentieke bron Verrijkt Bakent administratief af Uitgebreid Adres Administratieve Afbakening Land Het Publications Office of the European Union 19 beveelt ISO 3166-1 20 codes aan voor landen in alle gevallen behalve: 'UK' in preference to the ISO 3166 code GB for the United Kingdom; 'EL' in preference to the ISO 3166 code GR for Greece.17 Indien een land niet meer bestaat kan de ISO 3166-3 code gebruikt worden. 19 http://publications.europa.eu/code/en/en-5000500.htm 20 http://www.iso.org/iso/country_codes OSLO Open Standaard voor Lokale Overheden 47

2.5.6 Uitgebreid adres attribuut datatype mogelijke authentieke bron Provincie Deelgemeente Postbus Locatienaam Locator (type) Volledig adres Tekst Tekst Tekst Tekst Tekst Tekst Postbus, is de PObox, dient als aanduiding voor postadres, locatienaam duidt bijvoorbeeld op de gegeven naam van een appartement of een alleenstaande woning. Locator slaat op alle andere aanduidingen van de plaats. Mogelijke types locator: gebouwnummer, ingangnummer, trap, deur, vleugel, verdieping. Provincie is een veld dat makkelijk kan afgeleid worden op basis van postcode, indien deze waarde niet ter beschikking is uit de brongegevens. Voorbeelden Hieronder volgen enkele use cases van Bpost toegepast op het OSLO model. 1. Meerdere adresnotaties De heer X Kerkstraat 26 bus 3 9000 Gent De heer X eerste verdieping appartement 8 Kerkstraat 26 9000 Gent Adres: land = BE gemeente = GENT postcode = 9000 straatnaam = Kerkstraat huisnummer = 26 Locator (bus) = 3 of Locator (appartement) = 8 (afhankelijk van de gemeente) OSLO Open Standaard voor Lokale Overheden 48

Uitgebreid Adres: provincie = Oost-Vlaanderen deelgemeente (adresgebied)= bvb. Mariakerke, Ledeberg... Locator(verdieping) = 1 Locator (appartement) = 8 volledig adres = Eerste verdieping appartement 8 Kerkstraat 26 (bus 3) 9000 Gent 2. Gebouw met adres dat bestaat uit een reeks nummers en appartementen met aparte huisnummers + busnummers S. Schatteman-Gryp Ottergemsesteenweg 625 bus 109 9000 Gent Basisadres: land = BE gemeente = GENT postcode = 9000 straatnaam = Ottergemsesteenweg huisnummer = 625 locator(bus) = 109 Verblijfsobject dat gebouw aan basisadres verbindt: land = BE gemeente = GENT postcode = 9000 straatnaam = Ottergemsesteenweg locator (gebouwnummer) = 607-701 Beide adressen worden gekoppeld aan een eigen verblijfsobject. Die twee verblijfsobjecten zijn dan gekoppeld aan dezelfde entiteit gebouw. OSLO Open Standaard voor Lokale Overheden 49

3. Gebouw dat bestaat uit twee delen met eigen nummer en een aparte nummering van appartementen. Het gebouw zelf omvat de reeks van nummers van de delen. Kerkstraat 14 bus 1 9000 Gent Individueel verblijfsobject Basisadres: land = BE gemeente = GENT postcode = 9000 straatnaam = Kerkstraat huisnummer = 14 locator (appartement) = 1 Verblijfsobject dat het volledige gebouw aanduidt Basisadres: OSLO Open Standaard voor Lokale Overheden 50

land = BE gemeente = GENT postcode = 9000 straatnaam = Kerkstraat Uitgebreid adres: locator (gebouwnummer) = 14-16 4. Fysieke locatie appartement nr. 24 links op eerste verdieping van blok 10 van het gebouwnummer 360A in Mainstreet heeft busnummer 3 Basisadres: postcode = 1000 straatnaam = Mainstreet huisnummer = 6 locator (appartement) = 24 locator (bus) = 3 Uitgebreid adres: straatnaam = straatnaam locator (gebouw) = 360A 5. Verschillende adres representaties voor hetzelfde fysieke leveringspunt. OSLO Open Standaard voor Lokale Overheden 51

Basisadres: land = BE gemeente = BRUSSEL postcode = 1000 straatnaam = Anspachlaan huisnummer = 1 Uitgebreid Adres: postbus = 10001 OSLO Open Standaard voor Lokale Overheden 52

Mappingtabel OSLO - CRAB - INSPIRE OSLO CRAB INSPIRE UPU-S42 Land Admin unit level 1 (almost always a country) Gemeente gemeente Admin unit level 5 (almost always a city or town) country 40.14.0.0.0 town 40.16.0.0.0 Postcode postkantoncode Post Code postcode 40.13.0.0.0 Straatnaam straatnaam Thoroughfare (a road, a waterway etc.) thoroughfarename 40.21.0.0.0 Huisnummer (Nummeraanduidi ng) huisnummer Locator designator (a building number, entrance number etc.) streetnumber or plot 40.24.0.0.0 Locator subadres (kan zowel nummer van het appartement als busnummer bevatten, afhankelijk van ingave door de gemeente) Locator designator (a building number, entrance number etc.) busnumber extention designation 40.28.0.0.0 Locator Locator designator (a building number, entrance number etc.) mail recipient dispatch information 30.* building wing type 30.29.0.0.1 wing indicator 30.29.0.0.2 stairwell type 30.30.0.0.1 stairwell indicator 30.30.0.0.2 floor type 30.31.0.0.1 floor indicator 30.31.0.0.2 door type 30.32.0.0.1 door indicator 30.32.0.0.2 OSLO Open Standaard voor Lokale Overheden 53

Provincie Admin unit level 2 (usually a county or state) Deelgemeente Postbus Locatienaam Address area (usually a city area or village) PO Box (a specialisation of locator designator) Locator name (a proper name for a building or room within a building) town 40.16.0.0.0 Delivery Service Type 40.19.0.0.1 ( Postbus ) Delivery Service Indicator 40.19.0.0.2 PO Box Number or bpack station name Building/Construction Level 1 30.26.1.0.0 Volledig adres gemeente + straatnaam + huisnummer + postcode + huisnummer + subadres Niet beschikbaar Geografische aanduiding (Administratieve afbakening) niscode Admin unit (any level) Administratieve Afbakening Dit is een type code, zoals een NISCode om een bepaalde geografische zone aan te duiden. Bijvoorbeeld een arrondissement, kiesdistrict of een deelgemeente: http://statbel.fgov.be/nl/statistieken/gegevensinzameling/nomenclaturen/admin-geo/ Lijst van de huidige codes voor de deelgemeenten (NIS-code fusiegemeente + letter) 40000: provincie Oost-Vlaanderen 4 Provincie Oost-Vlaanderen 0000 de code slaat op de volledige provincie 32000: arrondissement Diksmuide 3 Provincie West-Vlaanderen 2 Arrondissement Diksmuide 000 de code slaat op het volledige arrondissement 23105: gemeente Affligem OSLO Open Standaard voor Lokale Overheden 54

23 Arrondissement Halle-Vilvoorde 105 Gemeente Affligem (nieuwe gemeentenaam zodat het nummer niet meer overeenkomt met de alfabetische plaats) 71022E: deelgemeente Stokrooie 7 Provincie Limburg 1 Arrondissement Hasselt 022 Fusie gemeente Hasselt E Deelgemeente Stokrooie (oude code voor de fusies: 71056) of een lokaal verrijkte indeling zoals wijk of politiezone. OSLO Open Standaard voor Lokale Overheden 55

2.6 Dienstverlening Om klanten goed te kunnen informeren over de status van hun dienstverlening moeten de procesverantwoordelijken hun administratie hier op afstemmen. Elke hoeveelheid werk, waarvan kwaliteit en doorlooptijd bewaakt moet worden, wordt vastgelegd als dienstverlening. Door elke dienstverlening te koppelen aan een klant of een adres afkomstig uit de authentieke bronnen, is het mogelijk om een overzicht van de dienstverlening voor een klant samen te stellen en alle lopende dienstverleningen op te vragen. Om te kunnen sturen op basis van beleidsinformatie is het essentieel om op een meer uniforme wijze relevante informatie te verzamelen. Teneinde een relevant inzicht te verwerven is het essentieel om een link te kunnen leggen tussen de gegevens in de verschillende toepassingen en domeinen, kerndata is hierbij essentieel. De focus van dienstverlening is voornamelijk gericht op een indicatie van het dossierverloop, en de wettelijke parameters (bvb. wettelijke doorlooptijd) vallen vandaag buiten het kader van deze specificatie. 2.6.1 Dienstverlening Het domein Dienstverlening omvat alle processen met een welgedefinieerde aanleiding en een welgedefinieerd resultaat, waarvan kwaliteit en doorlooptijd bewaakt moeten worden, bij een transactie tussen persoon en bestuur, tussen organisatie en bestuur maar ook interbestuurlijk. We focussen hierbij op het digitaliseren van de statuswijzigingen van de dienstverlening (niet op de workflow van de onderliggende processen). Een dienstverlening kan bestaan uit verschillende andere dienstverleningen. Elke dienstverlening heeft een streefdatum. Die kan bepaald worden door wettelijke termijnen (bijvoorbeeld bij het afleveren van een stedenbouwkundige vergunning), maar ook door engagementen die het bestuur genomen heeft naar zijn burgers inzake dienstverlening. attribuut datatype mogelijke authentieke bron Streefdatum Identificatie Datum/tijd Identificatie OSLO Open Standaard voor Lokale Overheden 56

Type Code Streefdatum De datum waarop de afleverende overheid de het product van de dienstverlening wenst af te leveren. Identificatie De identificatie is de sleutel waarmee gerefereerd wordt naar de de entiteit dienstverlening. Voor een uitgebreide beschrijving van de identifier verwijzen we naar de definitie (hoofdstuk 2.2.2.2). Hierbij wordt dan typisch de referentie naar de (lokale) bron meegegeven. Type Het type geeft aan wat de aard van de dienstverlening is (code en omschrijving). Vandaag is er geen authentieke bron of gestandaardiseerde lijst beschikbaar. voorbeelden: informatie, klacht, melding, suggestie relatie doelentiteit mogelijke authentieke bron Bevindt zich in Resulteert in Behoort tot Status Code resultaat Dienstverlening Volgt Voorziet Vereist Levert Juridisch kader Rol Initiatie Product Bevindt zich in De status is procesgericht en geeft aan in welke fase het proces zich op dat moment bevindt. Per status houden we een wijzigingsdatum bij. Zo kan een historiek opgebouwd worden. OSLO Open Standaard voor Lokale Overheden 57

We voorzien tevens een toelichtingsveld, die extra informatie kan bevatten voor de burger (voorbeeld: het dossier wordt momenteel voorgelegd voor advies aan de brandweer. We verwachten op antwoord op (...)) of voor de interne diensten (voorbeeld: wachten op gegevens van de burger). Een status wordt getypeerd door een type en een statuscode. Type Type geeft aan of de status intern of extern gericht is. Externe status wordt gebruikt om met de buitenwereld te communiceren zoals aanvragers. Interne status wordt gebruikt om het proces intern aan te sturen. Dienstverlening heeft altijd één actuele status. Voor externe communicatie wordt altijd de laatste externe status gebruikt. Heeft statuscode De statuscode geeft de procesfase weer. Er wordt geen inhoudelijke waardering meegegeven. Het gaat om objectieve fasen. Vandaag is er geen authentieke bron of gestandaardiseerde lijst beschikbaar. voorbeelden: extern: ontvangen, in behandeling, on hold, afgehandeld, afgebroken door initiator intern: niet-ontvangen, ontvangen, in behandeling, on hold, afgehandeld, afgebroken door initiator Een eerste interne status is Niet-ontvangen. Er kunnen al gegevens gekend zijn van een proces dat komende is, maar het dossier is nog niet officieel ingediend door de klant. De status ontvangen (geregistreerd) wordt bijvoorbeeld bereikt nadat een webformulier is ingevuld of de postintake is geboekt. De status in behandeling genomen wordt bereikt nadat door de behandelende afdeling alle benodigde stukken en gegevens zijn ontvangen. De status On hold kan als een burger bijkomende informatie moet geven vooraleer het dossier verder kan behandeld worden. De laatste status is steeds afgehandeld. Bij het bereiken van de laatste status moet de behandelaar ook aangeven wat het resultaat is. Het kan ook zijn dat een zaak voortijdig wordt afgebroken, op het moment dat nog niet alle statussen zijn doorlopen. Dit wordt als Resultaatcode opgenomen wanneer een proces afgebroken wordt. De status is "Agehandeld", met als resultaat "Afgebroken", en in de toelichting van de Status kan dan bvb. staan "De aanvrager heeft de bouwvergunning ingetrokken op dd-dd-jjjj." Resulteert in OSLO Open Standaard voor Lokale Overheden 58

Het resultaat geeft aan wat de uiteindelijke beslissing is van een klantvraag (code en omschrijving). Vandaag is er geen authentieke bron of gestandaardiseerde lijst voor het resultaat van een klantvraag. De toelichting bij de laatste status geldt ook als toelichting voor het resultaat. In toepassingen wordt vaak geen onderscheid gemaakt tussen statussen en resultaten. Elke dienstverlening kent meerdere statussen, maar heeft altijd maar één resultaat, bijvoorbeeld vergunning geweigerd of vergunning verleend. Is onderdeel van De relatie is onderdeel van geeft het verband tussen een dienstverlening en deeldienstverleningen ingeval een samengestelde klantvraag. Voorbeeld: het organiseren van een straatfeest, met vergunningen, het parkeervrij maken van de straat, subsidies, uitlenen van materiaal, Volgt De relatie volgt legt vast aan welk juridisch kader deze onderhevig is. Voorziet De relatie voorziet geeft aan welke actoren betrokken zijn in de dienstverlening. Ze worden in het OSLO-model opgenomen als rol. Vereist Elke dienstverlening wordt getypeerd door een initiatie. De relatie vereist geeft aan wat de dienstverlening initieert. De initiatie kan een klantvraag zijn, maar kan ook van een andere orde zijn, zoals een wettelijke verplichting. De initiatie heeft een naam en een inhoudsveld waar alle nodige informatie in kan meegegeven worden. Voorbeeld: De initiatie kan een email zijn van een burger met aanvraag van materiaal. De naam bevat de korte omschrijving, bv. aanvraag materiaal buurtfeest. De omschrijving omvat de nodige informatie om de dienstverlening te kunnen afhandelen. De status is ontvangen, met een bepaalde datum (analoog aan de initiatie-datum). In het kader van een aanvraag van een stedenbouwkundige vergunning worden deeldienstverleningen opgestart. Denk aan advies aanvragen bijvoorbeeld. De initiatie is dan een wettelijke verplichting. De doorlooptijden worden ook bepaald door wettelijke termijnen. OSLO Open Standaard voor Lokale Overheden 59

2.6.2 Product Diensten en goederen die een klant kan ontvangen om een bepaalde behoefte te vervullen, rechten uit te putten of een wettelijke verplichting door de klant te doen naleven 21. klant: een individuele klant (burger) of een groep van klanten(organisatie). interne of externe klant. Attribuut datatype mogelijke authentieke bron Naam Inhoud Geldigheidsduur Identificatie Type Tekst String Tijdspanne Identificatie Code Relatie doelentiteit mogelijke authentieke bron Heeft toepassingsgebied Locatie 21 definitie gebaseerd op King en Stad Antwerpen OSLO Open Standaard voor Lokale Overheden 60

Naam Naam van het product (typisch afgeleid van het type). Inhoud Het inhoudsveld is een verzamelveld voor elke relevante informatie inzake het product. Dit kan een ongestructureerde tekst (omschrijving) zijn of een gestructureerde mededeling (xml). Geldigheidsduur Het product heeft een bepaalde geldigheidsduur. Deze staat los van de datum dat het product aangemaakt werd, en kan eindig zijn in de tijd. Type Alle producttypes zijn gekend en worden gepubliceerd aan de hand van productcatalogi. Het volstaat om een referentie naar de juiste catalogus te voorzien om een bepaald product te karakteriseren. De toepassing van de dienstverlening zorgt dat voor een correct interpretatie. externe producten Vandaag is er een gestandaardiseerde catalogus: de interbestuurlijke producten- en dienstencatalogus (IPDC). Deze biedt een overzicht van de overheidsdienstverlening. Elke overheidsdienst kan hiervan gebruik maken bij zijn communicatie naar de overheidsklant. Voor de federale producten Voor de Vlaamse producten Voor de lokale en provinciale producten Elk product heeft een unieke sleutel. De types die IPDC gebruikt: financieel voordeel financiële verplichting fysische voorziening beschikbaar stellen van materiaal advies & begeleiding bewijzen toelatingen OSLO Open Standaard voor Lokale Overheden 61

Interne producten met een interne klant. Interne producten hebben als afnemer de interne klant: individu die deel uitmaakt van de organisatie stad X bestuursorgaan of mandataris en zijn vanuit die optiek back-office producten (niet voor buitenwereld). Vandaag is er geen authentieke catalogus of lijst met interne producten beschikbaar. De lijst met interne producten van Antwerpen kan als best practice gezien worden. Heeft toepassingsgebied Het toepassingsgebied is de perimeter waar de dienst beschikbaar en juridisch bruikbaar is. Voorbeelden Federaal: 01000 Vlaanderen: 02000 Provincie: de 5 Vlaamse provincies Gemeente: de 308 Vlaamse gemeenten We verwijzen hier naar de administratieve afbakening (een onderdeel van locatie), typisch een NISCODE. Indien het toepassingsgebied niet volledig overeenstemt met een NIScode kan een geometrie worden doorgeven via de entiteit locatie. Intiatie Lokaliseert De relatie heeft locatie legt vast waar de Initiatie betrekking op heeft. Voor de definitie van een locatie verwijzen we naar hoofdstuk 2.4.1. Voorbeelden: Door het koppelen van een adres (bijvoorbeeld een subsidie) Door het koppelen van een gebouw Door het koppelen van een perceel Door het koppelen van een wijk of buurt (melden overlast) Door het zetten van een punt (melding van een put in het wegdek) Door het tekenen van een polygoon (bijvoorbeeld een buurtfeest, inname openbaar domein) naam OSLO Open Standaard voor Lokale Overheden 62

korte omschrijving van de initiatie. inhoud Het inhoudsveld is een verzamelveld voor elke relevante informatie inzake de initatie. OSLO wil structureren naar vorm, maar niet naar de inhoud van het veld. Dus elk bestuur is vrij om te kiezen dit in te vullen als een vrije omschrijving of een gestructureerd formaat onder de vorm van xml. 2.6.3 Juridisch kader De machtigingen zijn afgeleid van het juridisch kader, i.e. een set van wetten, decreten en richtlijnen die een bepaalde dienstverlening of machtiging documenteren. Het juridisch kader dat hier bedoeld wordt, is specifiek in het kader van de machtigingen die gebruikt worden om rollen te typeren in het kader van een bepaalde dienstverlening. Attribuut datatype mogelijke authentieke bron Identificatie Identificatie Relatie doelentiteit mogelijke authentieke bron Identificatie Bekrachtigt Volgt machtiging dienstverlening OSLO Open Standaard voor Lokale Overheden 63

2.6.4 Machtiging Binnen dienstverlening zijn er vershillende actoren (natuurlijke persoon, ambtenaar, gemandateerde voor een onderneming) die een specifieke rol opnemen. In een aantal van deze dienstverleningen moet deze rol afgetoetst worden met een formele lijst. een lokale ambtenaar die uitreksels uit het strafregister mag opvragen (rol behandelaar) een persoon die een mandaat heeft in een vennootschap (rol aanvrager) architect voor een bouwaanvraag (rol betrokkene) Binnen de dienstverlening wensen we te refereren naar een document of lijst die deze rol bekrachtigd. Deze lijsten kunnen lokale bronnen zijn of kruispuntdatabanken (typisch met een geldigheidsperiode). Mogelijke bronnen een lokale ambtenaar die uitreksels uit het strafregister mag opvragen rol behandelaar referentie naar een document een persoon die een mandaat heeft in een vennootschap rol aanvrager ophalen via MAGDA diensten (CORVE). In geval de machtiging voor een onderneming spreken we van een funtiehouder zoals deze gedefinieerd is in de (V)KBO. Het betreft het ondernemingsnummer van de onderneming waarvoor het INSZ of OndernemingsNummer functiehouder is. een ambtenaar rol behandelaar In geval de machtiging voor een geregistreerde ambtenaar, betreft het een natuurlijke persoon die aangesteld is in een door de overheid beheerde dienst. De bron is ondermeer het ACM 22 platform van de Vlaamse Overheid. 2.6.5 Rol Een dienstverleningsdossier kent een aantal typische rollen. Het gaat om een generieke benaming van de aard van de rol. Typisch denken we aan initiator, of verantwoordelijke. Vandaag is er geen authentieke bron of gestandaardiseerde lijst beschikbaar. Het gaat hier zowel om rollen langs de kant van de 'klant' als langs de kant van een 'lokaal bestuur'. De link ligt hier ook duidelijk met de entiteiten natuurlijke personen, organisaties, 22 ACM staat voor Access Control Management OSLO Open Standaard voor Lokale Overheden 64

mandaten,... maar geeft elk van deze betrokkenen een generieke rol binnen een dienstverleningscontext, die voor elke dienstverlening anders kan zijn... Voorbeelden rol: Begunstigde Aanvrager Initiator Behandelaar Betrokkene Beheerder Goedkeurder Attribuut datatype mogelijke authentieke bron Type Code Relatie doelentiteit mogelijke authentieke bron bestaat uit machtiging 2.6.6 Agent Een persoon of organisatie kan al dan niet onder een bepaalde hoedanigheid, zij het privé of in naam van een organisatie, een bepaalde rol aannemen bij een bepaalde dienstverlening. Dit geeft aanleiding tot bijkomende relaties die betrekking hebben op Dienstverlening. Agent is dus geen tussenentiteit maar een abstractie en wordt zelf nooit gebruikt in de beschrijving. Enkel de instanties zelf worden gebruikt: Persoon hoedanigheid en Organisatie. Relatie doelentiteit mogelijke authentieke bron Vervult Rol OSLO Open Standaard voor Lokale Overheden 65

3. Formele specificatie 3.1 Inleiding De specificatie heeft niet als doel om bestaande datastructuur te herontwerpen maar een gemeenschappelijke laag te vormen tussen verschillende systemen. Het is een technologie neutrale specificatie, dit betekent dat er een ontkoppeling is van implementatie en data beschrijving. In het OSLO-model staat betekenisvol verwerken van ontvangen informatie met gegevens van andere bronnen centraal. Het model zorgt voor een correcte representatie van de data volgens verwachte interpretatie van de gebruikers. Twee essentiële componenten hierbij zijn: Sterk herbruikbare (meta)data en referentiedata Accurate beschrijvingen van de (meta)data. Een vergelijkbare formele specificatie werd reeds ontwikkeld door ISA. ISA staat voor Interoperability Solutions for European Public Administrations Programme en heeft als doel elektronische gegevensuitwisseling tussen publieke diensten in Europese landen. OSLO is een uitbreiding (extentie) op de Europese standaard. De OSLO standaard is meer grannulair en houd rekening met kruispuntsystemen van de centrale overheden (Federaal en Vlaams). De formele specificatie van ISA is beschreven in onderstaande documenten, voor OSLO zullen vergelijkbare documenten opgesteld worden: Personen, Locaties, Business: http://joinup.ec.europa.eu/asset/core_business/asset_release/core-business-vocabulary- 100 Dienstverlening: https://joinup.ec.europa.eu/asset/core_public_service/asset_release/core-public-servicevocabulary-0 OSLO Open Standaard voor Lokale Overheden 66

We hebben naast een OSLO XML schema, het OSLO conceptueel model beschreven volgens Linked Data standaarden, in het bijzonder RDF. Dit is een methode om gepubliceerde data te beschrijven om verschillende heterogene data met elkaar in verband te kunnen brengen. Uiteindelijk kan het XML Schema en de RDF vocabulary gebruikt worden als model of validatie voor implementaties van de conceptuele specificatie van OSLO. Figuur 7 Relatie ISA tot XML RDF kan niet zomaar geplaatst worden tegenover XML, eventueel wel tegenover XSD. XML is een serialisatie (syntax) zoals JSON bijvoorbeeld. Het datamodel dat hoort bij XML is (uiteraard) een boomstructuur. De validatie van het datamodel (de boomstructuur) hangt af van het XML schema (XSD). RDF is een datamodel gebaseerd op een graafstructuur en essentieel daarbij is dat de entiteiten geïdentificeerd worden aan unieke URI's. Voor RDF bestaan er verschillende serialisaties waaronder ook XML. De XSD mag niet gebruikt worden als intern datamodel (gelinkt aan een DBMS bvb.): enkel voor uitwisseling. Er moet dus een mapping gemaakt worden naar het interne datamodel. De verantwoordelijkheid voor die mapping ligt bij de implementatie. De OSLO XSD is dus in feite een canonical model (canoniek model). Het doel van een canoniek model is om een woordenlijst van herbruikbare veelvoorkomende objecten en definities op zakelijk- of dienstverlening niveau te definiëren om interoperabiliteit tussen verschillende systemen te maximaliseren. 3.2 Opbouw van het XML-schema Aan de basis ligt een Identificatie klasse, die is gebaseerd op de gelijknamige UN/CEFACT klasse [UN/CEFACT] en is gedefinieerd in de ADMS namespace [ADMS]. In de de OSLO XML specificatie worden componenten uit de Core Vocabularies XML hergebruikt. Het idee hierachter is dat de OSLO XML specificatie zo maximaal gealigneerd is op de Core OSLO Open Standaard voor Lokale Overheden 67

Vocabularies XML. Aan de basis van de Core Vocabularies XML is een bibliotheek van veelgebruikte informatie elementen die voorzien is door de Universal Bussiness Language bibliotheek (UBL) [OASIS]. Met dit design zorgt de Core Vocabularies voor optimale herbruikbaarheid van elementen gedefinieerd door de Core Component Technical Specification [CCTS] van UN/CEFACT (de basis van UBL). Voor de contactinformatie te modelleren wordt gebruik gemaakt van VCard componenten zoals gespecifieerd in [RFC6350] door het IETF. Uit de beschikbare componenten werd een subset geselecteerd die gealinieerd is met het OSLO Conceptueel model. Namespace Prefix Beheer Domein urn:un:unece:uncefact:data:specification:u nqualifieddatatypesschemamodule:2 http://www.w3.org/ns/corevocabulary/ BasicComponents http://www.w3.org/ns/corevocabulary /AggregateComponents urn:oslo:names:specification:schema:xsd:c ommonbasiccomponents-1 urn:oslo:names:specification:schema:xsd:a ggregatecomponents-1 udt UN/CEFACT 23 Datatypes cvb ISA 24 Basis componenten cva ISA Geaggregeerde componenten ovc OSLO OSLO Basis componenten ova OSLO OSLO Geaggregeerde componenten [OASIS] Universal Business Language v2.1. http://docs.oasis-open.org/ubl/ubl-2.1.pdf [CCTS] United Nations Centre for Trade Facilitation and Electronic Business. Core Components Technical Specification Version 3.0 http://www.unece.org/fileadmin/dam/cefact/codesfortrade/ccts/ccts-version3.pdf [UN/CEFACT] UN Centre for Trade Facilitation and e-business http://www.unece.org/cefact/ [ADMS] The Asset Description Metadata Standard, http://joinup.ec.europa.eu/asset/adms/description [RFC6350] http://tools.ietf.org/html/rfc6350 3.3 Opbouw van het RDF-schema 23 http://www.unece.org/cefact.html 24 http://joinup.ec.europa.eu/asset/core_business/asset_release/core-business-vocabulary-100 OSLO Open Standaard voor Lokale Overheden 68

Het RDF schema maak optimaal gebruik van bestaande schema s en vocabularies. Dit is belangrijk zodat toepassingen en andere afgeleide schema s zo makkelijk gelinkt kunnen worden aan het OSLO RDF-schema zonder dat daarvoor eerst complexe mappings gemaakt moeten worden tussen vocabularies voor courant gebruikte object, types en kenmerken in de beschrijving van de uitgewisselde gegevens. Bovendien garandeert hergebruik van bestaande schema s compatibiliteit en herkenbaarheid op langere termijn van het OSLO RDF-schema. Een bijkomend voordeel is dat de set eigen definities in het OSLO RDF-schema beperkt blijft zodat deze makkelijk te ondersteunen blijft. De namespace van OSLO is: http://purl.org/oslo/ns/ http://purl.org/oslo/ns/vocabulary (XML Schema) en het aanbevolen prefix is oslo. Daarnaast worden nog de namespaces gebruikt die weergegeven zijn in de onderstaande tabel. Namespace Prefix Beheer Domein http://www.w3.org/ns/org org W3C GLD 25 Organisaties http://www.w3.org/ns/regorg rov W3C GLD Geregistreerde Organisaties http://www.w3.org/ns/person person ISA 26 Personen http://www.w3.org/ns/locn locn ISA 27 Locaties http://purl.org/vocab/cpsv cpsv ISA 28 Publieke dienstverlening http://purl.org/dc/terms/ dcterms DCMA 29 Metadata http://schema.org/ schema schema.org 30 Markup, Metadata http://www.w3.org/2006/vcard/ns vcard W3C Contactgegevens http://www.w3.org/ns/adms adms WRC GLD 31 Standaarden, Codelijsten en Taxonomien 25 http://www.w3.org/2011/gld/wiki/main_page 26 http://joinup.ec.europa.eu/asset/core_person/description 27 http://joinup.ec.europa.eu/asset/core_location/home 28 http://joinup.ec.europa.eu/asset/core_public_service/home 29 http://dublincore.org/about/organization/ 30 http://schema.org/docs/schemas.html 31 https://dvcs.w3.org/hg/gld/raw-file/default/adms/index.html OSLO Open Standaard voor Lokale Overheden 69

http://www.w3.org/2006/time time W3C 32 Tijdsaanduiding http://www.w3.org/ns/prov prov W3C 33 Herkomst 3.4 Mapping tussen de schema s Voor de mapping maken we onderscheid tussen objecten en kenmerken. Voor de objecten is er een onderscheid tussen primaire objecten en secundaire objecten. Primaire objecten zijn objecten die de gebruikers van de xml en rdf schema s typisch als een geheel uitwisselen en dus ook kenmerken omvatten. Alle primaire objecten zijn gekoppeld aan een identifier. De secundaire objecten zijn objecten die gekoppeld zijn aan de primaire objecten en deze verrijken. Kenmerken worden toegekend aan een object en hebben steeds een datatype dat zoveel mogelijk overeenkomt met het voorgestelde datatype uit het conceptuele model. In RDF wordt er momenteel enkel gewerkt met een datatype Literal. Dit is een teksttype dat eender welke inhoud kan bevatten. Om bijvoorbeeld een datum aan te geven zal dit teksttype beperkt worden door er het overeenkomstig XSD basistype aan toe te kennen. In het geval van een datum is dit xsd:datetime. 3.4.1 Primaire Objecten Conceptueel XML Schema RDF Persoon Organisatie Hoedanigheid Persoonsrelatie Organisatierelatie person (OvpersonType) organization (OvorganizationType) membership (OvmembershipType) PersonRelation (PersonRelationType) OrganizationRelation (OrganizationRelationType) person:person oslo:organization oslo:membership oslo:personrelation oslo:organizationrelation Agent (abstract) OvAgentType dcterms:agent Locatie Location (CvLocationType) locn:location Verblijfsobject ResidenceObject (OvresidenceobjectType) oslo:residenceobject Gebouw building (OsloBuildingType) oslo:building 32 http://www.w3.org/tr/owl-time/ 33 http://www.w3.org/tr/prov-o/ OSLO Open Standaard voor Lokale Overheden 70

Perceel parcel (OsloParcelType) oslo:parcel Basis Adres Dienstverlening address (OsloBaseAddressType) PublicService (OvPublicServiceType) oslo:baseaddress cpsv:publicservice Initiatie input (OvDocumentType) cpsv:input Product output (OvProductType) cpsv:output 3.4.2 Secundaire Objecten Conceptueel XML Schema RDF Identificatie (voor alle objecten) Code (alle types) Herkomst identifier (OvidentifierType) code (OvcodeType) provenance (OvprovenanceType) adms:identifier (adms:identifier) oslo:code prov:entity Contact contact (OvcontactType) oslo:contact (vcard:vcard) Geometrie Uitgebreid Adres (bij Basis Adres) geometry (cvb:geometrytype) extendedaddress (OsloAddressType) locn:geometry oslo:extendedaddress Rol Role (OvRoleType) oslo:role Juridisch kader Rule (OvRuleType) cpsv:rule Status Status oslo:status Machtiging permission (OvPermissionType) oslo:permission 3.4.3 Kenmerken Alle object kenmerken die niet gekoppeld zijn aan andere objecten worden in onderstaande tabel weergegeven. Voor RDF zijn de weergegeven kenmerken de aanbevolen keuze. Toch voor maximale interoperabiliteit is het vereist om de OSLO Open Standaard voor Lokale Overheden 71

aanbevolen keuze te gebruiken (cfr. richtlijnen overeenstemming met OSLO in dit document). Identificatie Conceptueel XML Schema RDF Sleutel cvb:identifier dcterms:identifier Type cvb:identifiertype dcterms:type Bron cvb:issuingauthority, cvb:issuingauthorityid adms:schemeagency, dcterms:publisher Wijzigingsdatum IssueDate dcterms:issued Code (alle types) Conceptueel XML Schema RDF Code ovc:code dcterms:identifier Label ovc:label rdfs:label Omschrijving cvb:content dcterms:description Lijst cvb:list dcterms:ispartof (Bron) cvb:listagency adms:schemeagency (Versie) cvb:listversion adms:version Persoon Conceptueel XML Schema RDF Naam cvb:familyname person:familyname Voornaam cvb:givenname person:givenname Andere voornamen cvb:patronomycname person:patronymicname Geslacht cvb:gendercode schema:gender Adellijke titel oslo:nobelitytitle oslo:nobelitytitle OSLO Open Standaard voor Lokale Overheden 72

Geboortedatum cvb:birthdate schema:birthdate Geboorteplaats ovc:placeofbirth person:placeofbirth Datum overlijden cvb:deathdate schema:deathdate Plaats overlijden ovc:placeofdeath person:placeofdeath Nationaliteit ovc:nationality schema:nationality Wettelijk samenwonend Burgerlijke staat Juridische onbewkwaamheid legalcohabetation (ovc:indicatortype) civilclass (ovc:ovcodetype) legalincompetence (ovc:ovcodetype) oslo:legalcohabetation oslo:civilclass oslo:legalincompetence Is gedomicilieerd op domicile oslo:domicile Verblijft residence oslo:residence Persoonsrelatie Conceptueel XML Schema RDF Type type (OvcodeType) dcterms:type behoort tot from (OvpersonType) oslo:fromperson refereert to (OvpersonType) oslo:toperson geldigheid ovc:validityperiod oslo:validityperiod Organisatie Conceptueel XML Schema RDF Maatschappelijke naam cvb:legalname rov:legalname Commerciële naam cvb:alternativename dcterms:alternative Afgekorte naam cvb:alternativename dcterms:alternative Type ovc:companystatusovbu sinesscode rov:companytype OSLO Open Standaard voor Lokale Overheden 73

Vestiging Oprichtingsdatum Datum stopzetting (ovc:ovcodetype) isbranch (ovc:indicatortype) establishmentdate (ovc:oslodatetype) shutdowndate (ovc:oslodatetype) oslo:isbranch oslo:establishmentdate oslo:shutdowndate KBO soort kind (ovc:indicatortype) oslo:kind KBO rechtsvorm ovc:legalformcode oslo:legalformcode KBO rechtstoestand KBO reden stopzetting KBO Hoedanigheidsfase ovc:legalstatuscode (ovc:legalstateenumtyp e) reasonshutdown (ovc:reasonshutdowne numtype) ovc:functionphase rov:companystatus oslo:reasonshutdown oslo:functionphase KBO Hoedanigheid ovc:function oslo:function KBO Status activiteit facturatielocatie KBO locatie leveringslocatie post locatie ovc:companystatusovbu sinesscode (ovc:ovcodetype) companyactivityovbusin esscode (ovc:ovcodetype) invoicelocation (OvresidenceobjectType) authenticlocation (OvresidenceobjectType) deliverylocation (OvresidenceobjectType) mailinglocation (OvresidenceobjectType) oslo:companystatus rov:companyactivity oslo:invoicelocation rov:registration oslo:deliverylocation oslo:mailinglocation Organisatierelatie OSLO Open Standaard voor Lokale Overheden 74

Conceptueel XML Schema RDF behoort tot from (OvorganizationType) oslo:fromorganization groepeert to (OvorganizationType) oslo:toorganization geldigheid ovc:validityperiod oslo:validityperiod Hoedanigheid Conceptueel XML Schema RDF functie ovc:membershipfunction oslo:membershipfunction geldigheidsperiode ovc:validityperiod org:memberduring type ontvangt post op ovc:membershiptype (OvcodeType) mailinglocation (OvresidenceobjectType) oslo:membershiptype oslo:mailinglocation persoon person (OvpersonType) org:member organisatie beschikbaar op organisation (OvorganizationType) availableat (OvresidenceobjectType) org:organization oslo:availableat Verblijfsobject Conceptueel XML Schema RDF geldigheid ovc:validityperiod oslo:validityperiod heeft gebouw ovc:parcel oslo:parcel heeft perceel ovc:building oslo:building adresseert ovc:address oslo:address OSLO Open Standaard voor Lokale Overheden 75

Adres (bij Basisadres en Uitgebreid Adres) Conceptueel XML Schema RDF land cvb:adminunitfirstline oslo:country gemeente cvb:postname locn:postname postcode cvb:postcode locn:postcode straatnaam cvb:thoroughfare locn:thoroughfare huisnummer cvb:locatordesignator oslo:locatordesignator locator LocatorDesignator oslo:locatordesignator provincie cvb:adminunitsecondline oslo:province deelgemeente cvb:cvaddressarea oslo:addressarea postbus cvb:pobox oslo:pobox locatienaam cvb:locatorname oslo:locatorname volledig adres cvb:fullcvaddress oslo:fulladdress Basisadres Conceptueel XML Schema RDF uitgebreid adres bakent administratief af ovc:extendedaddress (OsloAddressType) ovc:adminunit (OvcodeType) oslo:extended_address oslo:adminunit Dienstverlening Conceptueel XML Schema RDF Streefdatum ovc:targetdate oslo:targetdate Type type (OvcodeType) dcterms:type Vereist hasinput (OvDocumentType) cpsv:hasinput OSLO Open Standaard voor Lokale Overheden 76

Levert produces (OvProductType) cpsv:produces Bevindt zich in status (OvStatusType) oslo:status Resulteert in result (OvcodeType) oslo:result Volgt ovc:rule cpsv:follows Voorziet ova:role oslo:hasrole behoort tot requires (OvPublicServiceType) dcterms:requires Rol Conceptueel XML Schema RDF Type roletype (OvcodeType) dcterms:type bestaat uit permission (OvPermissionType) oslo:haspermission vervult agent (ovc:ovagenttype) oslo:hasactor Machtiging Conceptueel XML Schema RDF geldigheidsperiode ovc:validityperiod oslo:validityperiod Status Conceptueel XML Schema RDF Type Heeft statuscode statustype (OvcodeType) statuscode (OvcodeType) oslo:statustype oslo:statuscode Toelichting description dcterms:description Wijzigingsdatum modificationdate dcterms:modified Initiatie OSLO Open Standaard voor Lokale Overheden 77

Conceptueel XML Schema RDF Naam name dcterms:title Inhoud Lokaliseert content (OvContentsType) location (locn:cvlocationtype) dcterms:description dcterms:spatial Product Conceptueel XML Schema RDF Type producttype (OvcodeType) oslo:producttype Naam name dcterms:title Inhoud content (OvContentsType) dcterms:description Geldigheidsperiode ovc:validityperiod oslo:validityperiod Heeft toepassingsgebied coverage (locn:cvlocationtype) dcterms:coverage Locatie Conceptueel XML Schema RDF geldigheidsperiode ovc:validityperiod oslo:validityperiod Heeft geometrie geometry (cvb:geometrytype) locn:geometry 3.4.4 Validering en compatibiliteit Om de compatibiliteit to maximaliseren kunnen toepassingen een XSLT opstellen gebaseerd op de bovenstaande mappingtabellen. Nadeel van zo n mapping is dat deze complex te onderhouden is. Een alternatief is om een programma of script te ontwikkelen die een schema en de schema-instantie parset en dan een 'nieuwe' RDF opbouwt (de feitelijke graaf) om die dan te serialiseren in een formaat naar keuze zoals opnieuw XML bijvoorbeeld. Er bestaat een commerciële tool om een XSD om te zetten naar RDF (1:1): OSLO Open Standaard voor Lokale Overheden 78

http://www.incunabulum.de/projects/it/xsdimport Topbraid Composer (Standard): http://www.topquadrant.com/products/tb_composer.html Syntax valideren: http://www.w3.org/rdf/validator/ http://owl.cs.manchester.ac.uk/validator/ Om consistentie te checken wordt typisch een reasoner gebruikt zoals Pellet, HermiT, FacT++. Er zijn verschillende manieren om de integriteit te valideren maar die zijn nog niet gestandaardiseerd. Een mogelijk manier is om om de structuur gebaseerd op de RDF/XML representatie te valideren met een aangepast XML Schema of met de Pellet Integrity Constraints Validator. 3.4.4 Voorbeeld Eenzelfde persoon kan volgens RDF en het OSLO XML Schema worden uitgewisseld. Indien een dienstverlener de persoonsgegevens ter beschikking wil stellen dan kan dit bijvoorbeeld via een url: GET http://dienstverlener.be/oslo/personen/123456789 Afhankelijk van de context van de gebruiker en de toepassing zal het opvragen van deze url de gegevens van de persoon teruggeven in RDF of geformatteerd volgens het OSLO XML Schema. Het antwoord in RDF/XML: <rdf:rdf xmlns:person="http://www.w3.org/ns/person#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> <person:person rdf:nodeid="123456789"> <person:familyname>brickley</person:familyname> <person:givenname>dan</person:familyname> <!-- etc... --> </person:person> </rdf:rdf> Hetzelfde antwoord in OSLO XML: <operson:person xmlns:xsi= http://www.w3.org/2001/xmlschema-instance xmlns:operson="http://oslo.v-ict-or.be/vocabulary/person" OSLO Open Standaard voor Lokale Overheden 79

xmlns:cva="http://www.w3.org/ns/corevocabulary/aggregatecomponents" xmlns:cvb="http://www.w3.org/ns/corevocabulary/basiccomponents" xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:commonbasiccomponents-2"> <cbc:familyname>brickley</cbc:familyname> <cvb:givenname>dan</cvb:givenname> <!-- etc... --> </operson:person> OSLO Open Standaard voor Lokale Overheden 80

4. Gebruik 4.1 Formattering Formattering De formattering zijn de afspraken die de opbouw van een specifiek veld (bv. een telefoonnummer) in het uitwisselingsformaat vastleggen. Wanneer de formattering afwijkt van de representatie (bv. bij het afdrukken, wat later problemen met OCR 34 kan voorkomen) wordt dit aangegeven. 4.1.1 e-mail Gebruik enkel kleine letters, geen spaties. jan.vandevelde@vlaanderen.be 4.1.2 Telefoonnummer Gebruik steeds de internationale notatie, wat problemen bij ondermeer digitale telefooncentrales kan voorkomen. Wanneer bij het telefoonnummer ook het landnummer wordt gegeven, vervalt het eerste cijfer (0) van het netnummer. Het landnummer wordt voorafgegaan door het plusteken, dat staat voor het toegangsnummer tot het internationale net. Dat toegangsnummer wordt niet vermeld, aangezien dit niet overal 00 is. Plusteken, landnummer, netnummer en abonneenummer worden van elkaar gescheiden door een spatie. Voor de weergave van het abonneenummer gelden dezelfde regels als bij de nationale nummers. Voorbeelden: + 32 11 32 43 54 + 32 2 345 67 89 + 32 486 98 76 54 (mobiel) Soms - bijvoorbeeld in Italiaanse telefoonnummers - moet ook het eerste cijfer (0) van het netnummer gekozen worden. In die gevallen valt de 0 niet weg. Voorbeeld: + 39 055 28 82 28 34 Optical character recognition (OCR), optische tekenherkenning is een transformatie waarbij uit een afbeelding van een tekst door middel van patroonherkenning alle tekens uit de afbeelding als zodanig worden herkend. OSLO Open Standaard voor Lokale Overheden 81

Een uitzondering hierop zijn speciale telefoonnummers die enkel lokaal geldig zijn: 0800 222 333 of 070 344 369 Naslagwerken NBN Z 01-002 (2002); Taalboek Nederlands (1996), p. 380 ITU, De Internationale Telecommunicatie-unie Recommendation E.123 (02/01) 4.1.3 Social Media optie 1 de gebruikers identificatie (user id) wordt opgegeven samen met de url van het medium userid = laurensdv url = http://www.linkedin.com/ optie 2 enkel de publieke url van de gebruiker wordt opgegeven url = http://www.linkedin.com/in/laurensdv 4.1.4 Adres We verwijzen voor de representatie naar de best pratices van bpost www.bpost.be/site/nl/residential/letters-cards/send/best_practices.html. Naslagwerken BIPT - De Wereldpostvereniging (UPU), UPU Standard S42a Comité Européen de Normalisation (CEN), CEN 14142-1 Bureau voor Normalisatie, NBN EN 14142-1 De Internationale Organisatie voor Standaardisatie (ISO), ISO 19160-1 (draft) elementen voorbeelden verplicht Naam Paul Janssens Functie - Afdeling Afdeling Kwaliteit indien van toepassing OSLO Open Standaard voor Lokale Overheden 82

Organisatie - Bedrijf bpost indien van toepassing Gebouw, verdieping... Straat, nummer en busnummer Centraal gebouw verdieping 2 Dendermondestraat 55 indien van toepassing Postcode en gemeente 2018 ANTWERPEN indien van toepassing Naam van het land voor post naar het buitenland (Frankrijk... ). 4.1.5 Rijksregisternummer uitwisseling Het identificatienummer bij het Rijksregister van de natuurlijke personen wordt uitgewisseld als een Tekst, zonder punten of koppelteken. 94090415309 representatie Het identificatienummer bij het Rijksregister van de natuurlijke personen wordt uitgewisseld zoals op volgende wijze afgedrukt op de keerzijde van de elektronische identiteitskaart: 94.09.04-153.09 4.1.6 Ondernemingsnummer Het ondernemingsnummer bestaat uit 10 cijfers en begint met een 0. Het formaat voor uitwisselling: 0xxx.xxx.xxx 4.1.7 Datum en tijd Gebruik maken van XSD:DateTime formaat "YYYY-MM-DDThh:mm:ss bvb. 2002-05-30T16:45:00 Tijdsnotatie is optioneel: YYYY-MM-DD is ook geldig OSLO Open Standaard voor Lokale Overheden 83

4.3 Informatieveiligheid 4.3.1 Wettelijke voorschriften en beperkingen Voor het verwerken en uitwisselen van gegevens tussen overheden zijn er een aantal wettelijke voorschriften en beperkingen. In het kader van OSLO zijn volgende bepalingen van bijzonder belang. 4.3.1.1 Gebruik van het rijksregisternummer en gegevens uit het rijksregister Om gegevens op te slaan, te verwerken of uit te wisselen afkomstig van het rijksregister: hebt u een machtiging nodig van het sectoraal comité van het rijksregister wordt de machtiging aangevraagd en verleend voor een welbepaald doel, hergebruik voor een ander doel vereist een nieuwe machtiging. de machtiging moet aangevraagd worden door de wettelijk bepaalde rol van erkend consulent informatieveiligheid de commissie voor de bescherming voor de persoonlijke levenssfeer heeft een globale machtiging verleend aan de gemeenten om gegevens in het rijksregister te verwerken. Niet alle gebruik is toegelaten. Dit document beschrijft de modaliteiten waaronder dit kan : http://www.vvsg.be/lists/nieuws/attachments/1766/2013-02- 13%20globale%20machtiging%20privacycommissie.pdf. Om van deze machtiging gebruik te maken moet een bestuur over een consulent informatieveiligheid en een veiligheidsplan beschikken. 4.3.1.2 Verwerken van persoonsgegevens Aanleggen en verwerken van bestanden met persoonsgegevens is geregeld door de Wet tot bescherming van de persoonlijke levensfeer ten opzichte van de verwerking van persoonsgegevens ook gekend als de privacywet. Deze wet vindt je hier : http://www.ejustice.just.fgov.be/cgi_loi/change_lg.pl?language=nl&la=n&table_na me=wet&cn=1992120832. OSLO Open Standaard voor Lokale Overheden 84

In het kort zijn volgende bepalingen en beperkingen van toepassing voor het aanleggen van bestanden met persoonsgegevens : men mag enkel persoonsbestanden verwerken met een welbepaald en gerechtvaardigd doeleinde hergebruik voor andere doeleinden vereist een nieuwe aangifte men mag ook niet meer gegevens verzamelen dan nodig voor het aangegeven doeleinde kort gezegd mogen persoonsgegevens enkel verwerkt worden indien, ofwel de persoon waarvan gegevens verzameld worden zijn toestemming hiervoor geeft, ofwel als een wet of een openbaar belang dit vereist. vooraleer men een bestand met persoonsgegevens aanlegt en verwerkt moet de verantwoordelijke hiervan aangifte doen bij de commissie voor de bescherming van de persoonlijke levenssfeer, ook wel kort CBPL of privacycommissie genoemd. aangiftes door een overheid worden gedaan door de consulent informatieveiligheid. 4.3.2 Maatregelen om de veiligheid van persoonsgegevens te garanderen 4.3.2.1 Klasseer de vertrouwelijkheid van de gegevens in kwestie : Bepaal minimaal of de verwerking van de gegevens geregeld wordt door : de wet voor de bescherming van de persoonlijke levenssfeer en/of de wettelijke bepalingen om gegevens uit het rijksregister te gebruiken. Wanneer je informatie behandelt met betrekking tot het domein contactinformatie (personen, organisaties, hoedanigheden) of gegevens die relaties hebben met dit domein, is uw data mogelijk onderhevig aan de privacywetgeving. Neem contact op met uw veiligheidscoördinator of de Vlaamse toezichtscommissie. 4.3.2.2 Maak een ontwerp voor het toegangsbeheer van de gegevens Voor persoonsgegevens neem je best volgende beschermingsmaatregelen: voorzie een lijst van gegevensbestanden en de doelstellingen waarvoor deze gegevens gerechtvaardigd kunnen verwerkt worden OSLO Open Standaard voor Lokale Overheden 85

voorzie een lijst van rollen of functies en de gegevens die deze kunnen bekijken/verwerken voorzie ten allen tijde een lijst waar men kan controleren wie toegang heeft tot welke gegevens als het om erg gevoelige gegevens gaat, voorzie dan een controlespoor van wie welke verwerking heeft gedaan voor deze gegevens 4.3.2.3 Vraag indien nodig toestemming van de persoon en wettelijk bepaalde doeleinden Als u persoonsgegevens verwerkt en de toestemming van de persoon is nodig (zie boven), voorzie een opt-in clausule, die toelicht welke gegevens bewaard worden, hoelang ze bewaard worden en voor welk doeleinde ze bewaard worden. Voorzie dat de persoon zijn gegevens kan (laten) corrigeren en kan laten verwijderen indien gerechtvaardigd. voorbeeld: vraag de gebruiker bij de intake (bijvoorbeeld: e-loket of balie) expliciet of zijn/haar contactgegevens mogen hergebruikt worden, en maak het toepassingsgebied specifiek. Geef de gebruiker duidelijk aan hoe hij/zij deze kan wijzigen of kan uitschrijven. We voorzien volgende niveau s: beperkt tot proces (beperkt tot de dienstverlening waarvoor de contactgegevens verstrekt werden) intern (enkel gebruik door de administratie van de gemeente) extern (publicatie op website, bijvoorbeeld voor contactpersonen van verenigingen) 4.3.2.4 documenteer en bewaak de integriteit van uw kerndata De integriteit geeft de mate aan waarin de informatie actueel en correct is. Voorzie alle OSLO-kerndata van metadata m.b.t. de herkomst (bron en betrouwbaarheid). betrouwbaarheid: gekoppeld aan een (authentieke) bron éénmalig ingeladen uit een (authentieke) bron manuele bijwerking bron: KSZ, RRK, (V)KBO, CRAB, GRB, bestuur, derden OSLO Open Standaard voor Lokale Overheden 86

OSLO Open Standaard voor Lokale Overheden 87

4. Addendum 4.1 Colofon OSLO kwam tot stand met medewerking van: Machtiging organisatie naam domein AGIV Jan Laporte lokalisatie AGIV Tom Van Herck lokalisatie AGIV Ziggy Vanlishout lokalisatie BCT Math Huntjens dienstverlening BCT Raf Withofs formattering Belgacom Freddy De Meersman contactinformatie, lokalisatie, dienstverlening bpost Pascal Desmarets lokalisatie bpost Xavier Querriau lokalisatie CIPAL Koen Renders contactinformatie CIPAL Kurt Erauw contactinformatie, lokalisatie, dienstverlening CIPAL Rudi Slechten contactinformatie CORVE Bart Misseeuw contactinformatie CORVE CORVE CORVE Bruno Devrieze Geert Mareels Hans Arents CORVE, Stad Gent Jan Godderis contactinformatie OSLO Open Standaard voor Lokale Overheden 88

CORVE Katrien De Smet contactinformatie, lokalisatie, lokalisatie CORVE Valère Bouserie contactinformatie Digipolis Antwerpen Jos Mostmans dienstverlening Digipolis Antwerpen Katrien Behiels contactinformatie Digipolis Antwerpen Kris Van de Water informatieveiligheid Digipolis Antwerpen Paul Van der Cruyssen contactinformatie Digipolis Antwerpen Stefan Marckx lokalisatie Digipolis Gent Ann Bernaert contactinformatie, dienstverlening Digipolis Gent Jo De Ruyver lokalisatie Digipolis Gent Dirk Van Gasse informatieveiligheid Digipolis Gent Franky De Pestel lokalisatie, dienstverlening Digipolis Gent Katrien Leire contactinformatie, dienstverlening ECG (Puurs) Francois Casteels contactinformatie, dienstverlening, formattering, lokalisatie European Commission ISA Stijn Goedertier lokalisatie, dienstverlening European Commission ISA Nikolaos Loutas lokalisatie Fedict Johan Boogaerts contactinformatie Fusebox (Eguila) Stefaan Ponnet contactinformatie, lokalisatie, dienstverlening, Gent Jo Dujardin informatieveiligheid Gent Diedrik Gaus lokalisatie Hamme (OCMW) Jan Pieters dienstverlening HoGent Pieter Sellenslagh iminds Miel Vander Sande contactinformatie Infront Jo Crappé contactinformatie Infront Maarten Verhaert contactinformatie OSLO Open Standaard voor Lokale Overheden 89

Internet Society Belgium Rudi Vansnick ISACA Marc Vael informatieveiligheid Knokke-Heist Dimitri Lefevre contactinformatie, dienstverlening Kortrijk Hans Verscheure Kortrijk Luk Van Beneden contactinformatie, dienstverlening Thomas More (BICC) Hans Tubbax Remmicom Ilse Van Reet contactinformatie Remmicom Jan Buelens contactinformatie, dienstverlening Schaubroeck Wim Van Acker contactinformatie, dienstverlening Schaubroeck Willem Van Hoecke lokalisatie V-ICT-OR Kris Gielen V-ICT-OR Eddy Van der Stock informatieveiligheid V-ICT-OR Ivan Stuer informatieveiligheid V-ICT-OR VLO Louis Massagé Herwig Hoskens VTC Anne Teughels informatieveiligheid VTC Caroline Vernaillen informatieveiligheid Zwevegem Luc Velghe contactinformatie Projectleiding Raf Buyle, V-ICT-OR (project management) Laurens De Vocht, MMLab-iMinds (technische verantwoordelijkheid) Erik Mannens, MMLab-iMinds (technische verantwoordelijkheid) Goedele Van der Spiegel, V-ICT-OR (project management) OSLO Open Standaard voor Lokale Overheden 90

4.2 Referenties: standaarden Voor de uitwerking van deze specificatie werden volgende bronnen geraadpleegd. 4.2.1 ISA - Core Public Service ISA staat voor Interoperability Solutions for European public Administrations programme. Belangrijkste doel is een elektronische gegevensuitwisseling tussen publieke diensten in Europese landen. Door een betrokkenheid in de ISA-werkgroepen en het delen van projectresultatren wensen we maximaal kennis uit te wisselen tussen OSLO en projecten in andere lidstaten. url: http://ec.europa.eu/isa/ 4.2.2 W3C - Government Linked Data (GLD) Het W3C is in oktober 1994 opgericht met als doel het Web tot zijn volle potentieel te ontwikkelen, gemeenschappelijke protocollen te ontwikkelen, die de groei van het Web bevorderen en interoperabiliteit garanderen. Een aantal best practices uit de Government Linked Data (GLD) werkgroep zullen als inspiratie voor onze standaard dienen. url: http://www.w3.org/2011/gld/wiki/main_page 4.2.3 Standaard Uitwisseling Formaat (StUF) Het Standaard Uitwisseling Formaat (StUF) is de Nederlandse standaard voor het opvragen en uitwisselen van gegevens voor overheidsinstanties waaronder gemeenten. Het heeft dezelfde doelen als de OSLO standaard en zal als voorbeeld dienen. http://www.kinggemeenten.nl/media/197602/stuf_30.pdf 4.3.4 Infrastructure for Spatial Information in the European Community (INSPIRE) INSPIRE is een verzameling van standaarden met als doel het uitwisselen van geografische gegevens binnen de Europese Unie. Deze standaard zal als overkoepelende standaard fungeren; OSLO moet hiermee conform zijn. OSLO Open Standaard voor Lokale Overheden 91

http://inspire.jrc.ec.europa.eu/documents/data_specifications/inspire_dataspecification_ad_ v3.0.pdf 4.4.4. Belgian Streets and Addresses (BeSt Add) BeSt Add is een adresmodel om de communicatie tussen gewestelijke adressenregistraties beter te doen verlopen. Dit model zal als inspiratie dienen voor onze standaard. 4.4.5 Universal Postal Union (UPU) Sinds 1874 verzorgt de Universal Postal Union (UPU), met hoofdkwartier in de Zwitserse hoofdstad Bern, de coöperatie tussen spelers in de postsector. Het is het primaire forum dat ervoor zorgt dat er een universeel netwerk van up-to-date producten en diensten is. Op die manier verzorgt de organisatie een adviserende, bemiddelende rol en voorziet technische ondersteuning waar nodig. Het zet de standaard voor internationale briefwisseling en maakt aanbevelingen om de groei van post, pakjes en financiele diensten te verbeteren voor de klant. 4.4.7 Basisregistraties Adressen en Gebouwen (BAG) De BAG is een registratie waarin gemeentelijke basisgegevens over alle gebouwen en adressen in Nederland zijn verzameld. De BAG is een belangrijk onderdeel van het stelsel van basisregistraties. De BAG biedt u een overzicht van alle gebouwen in Nederland en een adressenbestand van hoge kwaliteit van heel Nederland. http://bag.vrom.nl/ 4.4.8 SemanticGov SemanticGov richt zich op het bouwen van een infrastructuur noodzakelijk om publieke administraties semantisch web services te kunnen laten aanbieden. Hoewel dit cutting edge infrastructuur is, adresseert SemanticGov reeds lang bestaande uitdagingen van publieke administraties zoals het realiseren van interoperabiliteit tussen publieke administraties en zowel binnen een land als tussen landen. Dit maakt het ontdekken van diensten van publieke administraties door de klanten makkelijker en faciliteert de uitvoering van complexe diensten waar vaak verschillende publieke administraties betrokken zijn in de workflow of processen. De infrastructuur die SemanticGov gebruikt is een totaal herontwerp van diensten van publieke administraties en stelt een verschuiving van paradigma van de modus operandi van vandaag voor. Het consortium bestaat uit een complementaire set van top-level wetenschappelijke partners, multinationals en gebruikerspartners die de resultaten van SemanticGov onmiddellijk kunnen opnemen. url: http://islab.uom.gr/semanticgov/ OSLO Open Standaard voor Lokale Overheden 92

4.2 Referenties: authentieke bronnen In het model wordt maximaal gebruik gemaakt van authentieke bronnen. Hieronder een oplijsting van de authentieke waarnaar verwezen wordt in de tekst. 4.2.1 Authentieke bronnen persoonsgegevens De wet van 8 december 1992 tot bescherming van de persoonlijke levenssfeer ten opzichte van de verwerking van persoonsgegevens is van toepassing op deze bronnen: http://www.juridat.be/cgi_loi/loi_n.pl?cn=1992120832 De toepasbaarheid van deze wet heeft verstrekkende gevolgen voor alle processen die gebruik maken van persoonsgegevens. Rijksregister Voor meer informatie, zie http://www.ibz.rrn.fgov.be/index.php?id=141&l=1. Deze bron wordt geregeld door de wet van 8 augustus 1983 tot regeling van een Rijksregister van de natuurlijke personen: http://www.juridat.be/cgi_loi/loi_n.pl?cn=1983080836. Het RijksRegister (RR) is authentieke bron van het rijksregisternummer voor alle natuurlijke personen die in het Rijksregister zijn opgenomen. Kruispuntbank Sociale Zekerheid Voor meer informatie, zie http://www.ksz-bcss.fgov.be/nl/bcss/home/index.html De wet van 15 januari 1990 houdende oprichting en organisatie van een Kruispuntbank van de sociale zekerheid is van toepassing: http://www.juridat.be/cgi_loi/loi_n.pl?cn=1990011531. Kruispuntbankregisters Niet alle natuurlijke personen waarvan de sociale zekerheid een dossier beheert, zijn ingeschreven in het Rijksregister en beschikken over een rijksregisternummer (het betreft hier voornamelijk de personen die niet of niet meer in België verblijven). Daarom beheert de Kruispuntbank een gegevensbank (de zogenaamde Kruispuntbankregisters) die complementair is aan het Rijksregister en die identificatiegegevens bevat over deze personen 35. Voor meer informatie, zie http://www.kszbcss.fgov.be/nl/bcss/services/content/websites/belgium/services/service_institution/service_regi onal/service_01/service_04.html. 35 http://www.kszbcss.fgov.be/nl/bcss/services/content/websites/belgium/services/service_employer/service_01/service_04.html OSLO Open Standaard voor Lokale Overheden 93

Concreet bestaan de Kruispuntbankregisters uit het BIS-register (voor personen die niet in het RijksRegister opgenomen zijn, maar waarover een dossier beheerd wordt door de sociale zekerheid) en het RAD-register (voor personen die uit het RijksRegister geradieerd of geschrapt zijn). De Kruispuntbankregisters zijn authentieke bron voor het InschrijvingsNummer Sociale Zekerheid (INSZ) van natuurlijke personen opgenomen in de Kruispuntbankregisters. OSLO Open Standaard voor Lokale Overheden 94

Structuur van het rijksregisternummer Het rijksregisternummer (RN) bestaat uit 11 cijfers volgens een bepaalde structuur. eerste 6 cijfers = geboortedatum volgens het formaat JJMMDD Voor de personen die niet aan de hand van een akte hun volledige geboortedatum op het niveau van het gemeentebestuur of het rijksregister kunnen bewijzen, wordt enkel het geboortejaar in aanmerking genomen met een volgnummer (vb. 560000, 560001, 560002, ). volgende 3 cijfers = dagteller van de geboortes oneven voor het mannelijke geslacht even voor het vrouwelijke geslacht laatste 2 cijfers = check digit Structuur van het bisnummer TOP Het bisnummer (Kruispuntbanknummer) bestaat uit 11 cijfers volgens een bepaalde structuur. eerste 6 cijfers = geboortedatum in omgekeerde volgorde: JJMMDD Het derde en vierde cijfer geven de geboortemaand aan, vermeerderd met 40 indien het geslacht van de persoon gekend is op het moment van toekenning van het nummer, of vermeerderd met 20 indien het geslacht van de persoon niet gekend is op het moment van toekenning van het nummer. volgende 3 cijfers = dagteller van de geboortes oneven voor het mannelijke geslacht even voor het vrouwelijke geslacht laatste 2 cijfers = check digit 4.2.2 Authentieke bronnen ondernemingsgegevens KBO Kruispuntbank ondernemingen Voor mee informatie, zie http://statbel.fgov.be/nl/ondernemingen/kbo/over/index.jsp. De volgende ondernemingen moeten zich laten inschrijven in de KBO: rechtspersonen naar Belgisch recht de vestigingseenheden, organisaties en diensten naar Belgisch recht die een missie in het algemeen belang uitvoeren of verbonden zijn aan de openbare orde en die beschikken over een financiële autonomie en een verschillende boekhouding dan de rechtspersonen naar Belgisch recht waarvan ze afhangen OSLO Open Standaard voor Lokale Overheden 95

rechtspersonen naar buitenlands of internationaal recht die beschikken over een zetel in België of zich moeten inschrijven in uitvoering van een verplichting die is opgelegd door de Belgische wetgeving verenigingen zonder rechtspersoon die zich moeten inschrijven in uitvoering van een verplichting die is opgelegd door de Belgische wetgeving natuurlijke personen die als zelfstandige: een economische en professionele activiteit uitoefenen in België op een regelmatige manier, in hoofd of bijberoep zich moet inschrijven in uitvoering van een verplichting opgelegd door de Belgische wetgeving Ook alle vestigingseenheden moeten bij de KBO worden ingeschreven 36. KBO is de authentieke bron van het ondernemingsnummer als authentieke sleutel voor ondernemingen en vestigingen. Kwaliteit van gegevens in KBO en VKBO De kwaliteit van gegevens opgenomen in KBO wordt door heel wat Vlaamse instellingen die er gebruik van maken, als een belangrijk probleempunt aanzien. Er zijn drie belangrijke elementen die de kwaliteit van KBO-gegevens beperken. Dit zijn: Ondernemingen die hun gegevens onvoldoende up to date houden; Procesmatige fouten of vertragingen in het KBO-netwerk (nl. verwerking van gegevens vanuit Ondernemingsloketten, griffies, notarissen, BTW, RSZ, Rijksregister ); Historische fouten die in KBO werden opgeladen bij oprichting in 2003 37 Voor meer informatie over de algemene kwaliteit van de gegevens opgenomen in KBO, verwijzen we naar http://www.corve.be/producten/magdadiensten/ondernemingsgegevens/kwaliteit.php http://www.v-ict-or.be/nieuws/hogeschool-publiceert-onderzoeksrapportover-de-v-kbo VKBO (Verrijkte kruispuntbank Ondernemingen) Voor meer informatie, zie http://www.corve.be/producten/magdadiensten/ondernemingsgegevens/ VKBO maakt authentieke gegevens over ondernemingen onderling uitwisselbaar. Dit gebeurt door het koppelen van de authentieke gegevens aan het unieke ondernemingsnummer. Zo wordt een elektronische koppeling mogelijk van alle beschikbare informatie over één 36 Bron: http://statbel.fgov.be/nl/ondernemingen/kbo/over/inschrijving/index.jsp 37 Bron: http://www.corve.be/producten/magda-diensten/ondernemingsgegevens/kwaliteit.php OSLO Open Standaard voor Lokale Overheden 96

onderneming: de basisgegevens uit de moederdatabank (de federale KBO) en gegevens uit tal van andere databanken (RSZ, jaarrekening, Vlaamse dossierbestanden, vergunningen, enz.) VKBO is GEEN bron van authentieke sleutels, doch zorgt louter voor een ontsluiting van gegevens over ondernemingen en vestigingen opgenomen in authentieke bron KBO. 4.2.3 Authentieke bronnen adresgegevens CRAB Voor meer informie zie http://www.agiv.be/gis/projecten/?artid=797 Het CRAB is op 1 juni 2011 erkend als de eerste authentieke geografische gegevensbron in Vlaanderen. Naast de reeds vermelde gebruiksplicht zijn alle gebruikers voortaan ook verplicht om fouten en tekortkomingen te melden. Een authentieke geografische gegevensbron, zoals bedoeld in hoofdstuk V van het GDI-decreet is een door de Vlaamse Regering erkende gegevensbron die voldoende kwaliteitsgaranties biedt, een duidelijk beheer kent en verplicht te gebruiken is door de deelnemers aan GDI-Vlaanderen. Het acroniem CRAB staat voor Centraal Referentieadressenbestand. Het CRAB is het adressenproject van het samenwerkingsverband GDI-Vlaanderen en vormt het antwoord van het AGIV op de hierboven toegelichte adresproblematiek. Het gaat over een bestand met huisnummers en straatnamen, maar wat het CRAB werkelijk bijzonder maakt is dat het ook de positie van deze adressen, de zogeheten adresposities, bevat. Van elk van de ruim 2,5 miljoen huisnummers in Vlaanderen wordt in het CRAB een xycoördinaat opgeslagen. Het CRAB-project beoogt: één generiek bruikbare standaard op het vlak van definitie en codering tot stand te brengen; één correct en actueel bestand met alle volledige adressen voor Vlaanderen aan te maken; informatie over de geografische ligging van adressen te integreren (adresposities). GRB Het Grootschalig Referentiebestand (GRB) Voor meer informatie zie http://www.agiv.be/gis/projecten/?catid=95 OSLO Open Standaard voor Lokale Overheden 97

Het Grootschalig Referentie Bestand (GRB) is een authentieke geografische gegevensbron in wording die een unieke en objectgerichte kaart levert met precieze informatie van gebouwen, administratieve percelen, wegen, waterlopen en spoorbanen. De gegevens worden zodanig in detail opgenomen dat zij kunnen voorgesteld worden op een schaal tussen 1/250 en 1/5.000. De opmaak, beheer en toegang tot het GRB is geregeld in het GRB-decreet. Het AGIV beheert de gegevens in de centrale databank en zorgt voor de toegang tot de verschillende informatieproducten. 4.2.4 Bronnen productgegevens IPDC (Interbestuurlijke producten en dienstencatalogus) Voor meer informatie zie http://www.corve.be/projecten/lokaal/ipdc/index.php IPDC is strikt genomen GEEN authentieke bron. De interbestuurlijke producten- en dienstencatalogus (IPDC) biedt een overzicht van de overheidsdienstverlening. Elke overheidsdienst kan hiervan gebruik maken bij zijn communicatie naar de overheidsklant. De producten worden aangemaakt en up-to-date gehouden door het overheidsniveau dat de regelgeving over het product bepaalt. Welk overheidsniveau de producten aflevert, is daarbij niet bepalend. Om de producten te onderhouden zijn er drie redactiegroepen: Voor de federale producten: de federale kanselarij Voor de Vlaamse producten: de Vlaamse Infolijn Voor de lokale en provinciale producten: de redactiegroep lokale en provinciale besturen (vrijwilligers) Elk product heeft een unieke sleutel. 4.2.4 Authentieke bron nationaliteiten voor meer informatie zie: http://www.fedict.belgium.be/nl/binaries/digiflow%2020110427%20nl_tcm460-126738.pdf Het verbeteren van de data kwaliteit van de gegevens in KBO, de kruispuntbank voor ondernemingen, ligt aan de oorsprong van het oprichten van een authentieke bron voor landencodes. Een groep van experten heeft het kader en een aantal tekortkomingen onderzocht. Voor het representeren van landen zijn binnen de Belgische overheid NIS codes gebruikelijk. Daarnaast worden bij een aantal overheden gebruik gemaakt van ISO-3166, de internationale standaard voor de specificatie van landen. OSLO Open Standaard voor Lokale Overheden 98

De ISO-3166 standaard omvat drie onderdelen: - ISO-3166-1: o Definieert de landen (en gebieden van algemene interesse) o Definieert 3 type van codes: Alpha2 Tekst, 2 posities Geadviseerd voor het specifiëren van een adres Alpha3 Tekst, 3 posities Geadviseerd voor het specifiëren van een nationaliteit Num3 Numeriek, 3 posities Het gebruik van landencodes in verschillende business contexten en het gebruik van de NIS codes en ISO-3166 standaard hebben aanleiding gegeven voor het opstellen van een authentieke bron. In deze authentieke bron worden territoria (niet alle gebieden met een representatiecode zijn een land) gedefinieerd. Voor elk territorium zijn de representatiecodes van de ISO-3166-1 standard en de NIS code opgenomen. Indien van toepassing zijn splitsingen, fusies en naamswijzigingen van territoria gedefinieerd. Het gebruik van de representatiecodes in de context van adres, nationaliteit en plaats heeft aanvullend geleid tot het opnemen van nationaliteiten en van landen die kunnen gebruikt worden in de context van adres en plaats. Voor het samenstellen van de inhoud van de authentieke bron is samengewerkt met het rijksregister, KSZ, KBO en ADSEI. FOD Buza heeft de informatie aangevuld met de data voor de herkenning door de Belgische diplomatie. Via de governance procedure is de inhoud door de hogergenoemde partijen gevalideerd. OSLO Open Standaard voor Lokale Overheden 99

4.3 Detaildiagramma conceptueel model 4.3.1 Overzicht Onderstaande schets geeft een impressie van het voorlopige datamodel op 21/12/2012. De groene markering geeft aan welke velden vandaag (gedeeltelijk) beschikbaar zijn in de kruispuntsystemen van centrale overheden (authentieke bronnen). Andere velden zijn een verrijking (op lokaal niveau). De meest recente versie van het dit diagramma kan geconsulteerd worden via: http://purl.org/oslo/model OSLO Open Standaard voor Lokale Overheden 100

4.3.2 Contactinformatie OSLO Open Standaard voor Lokale Overheden 101