Open Standaard voor Linkende Overheden (OSLO) specificaties v1.1

Open Standaard voor Linkende Overheden (OSLO)

specificaties v1.1

OSLO METADATA versie

datum

auteurs

0.9.0

07032013

Buyle Raf, De Vocht Laurens

0.9.5

15042013

Buyle Raf, De Vocht Laurens, Van der Spiegel Goedele

1.0.0

29052013

Buyle Raf, De Vocht Laurens, Van der Spiegel Goedele

1.0.1

04122013

Buyle Raf, De Vocht Laurens, Van der Waal Johan

1.1.0

16052014

Buyle Raf, De Vocht Laurens, Van der Waal Johan

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, “VICTOR 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/isaopenmetadatalicencev11 Aansprakelijkheid VICTOR 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

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 ISAprogramma 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 Optin 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 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 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 email 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) 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

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.

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 ICToplossingen 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.

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. VICTOR wenst die te verankeren via twee sporen. Enerzijds ijvert ze voor een breed draagvlak en biedt ze een referentiebestektekst aan als de facto standaard. Anderzijds probeert ze ook OSLO een decretale basis te geven. Alignering met andere/hogere standaarden VICTOR wil geen solitaire Vlaamse standaard uitwerken. Ze toetst deze daarom ook aan de internationale standaarden. Hiervoor werkt het OSLOproject samen met het ISA (the Interoperability Solutions for European Public Administrations programme) Programma van de Europese Commissie om de OSLOstandaard conform te maken aan de kernspecficiaties van de Europese Commissie. Via o.a. World Wide Web Consortium (W3C) zal de OSLOstandaard

maximaal afgestemd worden op internationale webstandaarden en best practices. Toepassingen die conform zijn met de OSLOstandaard, 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 OSLOstandaard verzekerd.

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.

1.1.2 Licentie OSLO valt onder “ISA Open Metadata Licence v1.12 ” licentie (of een latere versie, vrijgegeven door de Europese Commissie).

1.2 Stakeholders Om de consensus met de industrie te vrijwaren werd het OSLOconsortium 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 egovernement 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 usecases.

1.2.2 Centrale Overheden De centrale overheden worden op het Vlaamse niveau vertegenwoordigd door ‘egovernment en ICTBeheer’ (eIB CORVE), het Agentschap voor Geografische Informatie Vlaanderen (AGIV), ‘Afdeling Monitoringsystemen en Crisicommunicatie’ (AMC), de Vlaamse Toezichtcommissie voor het elektronische bestuurlijke gegevensverkeer (VTC) en op Federaal niveau door de FOD voor Informatie en Communicatietechnologie (Fedict).

1.2.3 Academische partners en standardisatiecommissies 1.2.3.1 iMinds MMlabMICT iMindsUGentMultimedia 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.

iMinds Media en ICT (MICT) een onderzoeksgroep verbonden aan de Vakgroep Communicatiewetenschappen van de Universiteit Gent die zowel fundamenteel sociaalwetenschappelijk onderzoek als toegepast en beleidsgericht onderzoek uit in het domein van de nieuwe media en informatie en communicatietechnologieën. 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 ISAprogramma 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 ISAwerkgroepen 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. VICTOR is sinds 2012 vertegenwoordigd in de standardisatiecomissie (GLD, Government Linked Data Working Group). Via o.a. W3C zal de OSLOstandaard 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 overheid en industrie: CEVI, Remmicom en Schaubroeck. Het heeft steun van Stad Antwerpen en Gent (Digipolis),de Coördinatiecel Vlaams egovernment (CORVE), VICTOR en werkgroep Lokaal EGovernment (gecoöpteerd lid) 1.2.4 Beheersstructuur OSLO

1. Initiatiefnemer: V-ICT-OR 2. Opdrachtgever: OSLO Consortium 3. Coördinatiecommissie OSLO Dit is de werkgroep lokaal e-government 4. OSLO consortium 1. de coördinatiecel Vlaams e-government,(CORVE eIB), 2. Stad Gent-Stad Antwerpen (Digipolis), 3. V-ICT-OR 4. Infront, 5. Remmicom, 6. CEVI, 7. Schaubroeck 8. BCT 9. werkgroep Lokaal E-Government (gecoöpteerd lid) 5. Klankbordgroep 1. Agentschap voor Geografische Informatie Vlaanderen (AGIV),

2. de Vlaamse Toezichtcommissie voor het elektronische bestuurlijke gegevensverkeer (VTC), 3. Afdeling Monitoring en Control (AMC Bestuurszaken), 4. Federale Overheidsdienst voor Informatie- en Communicatietechnologie (Fedict), 5. Europese Commissie (Interoperability Solutions for European Public Administrations). 6. Adviesraden (diverse overlegstructuren) Vertegenwoordigers leveranciers Vertegenwoordigers lokale besturen 7. Partners De academische partners die het traject mee bewaken zijn Multimedia Lab (MMLab - iMinds, MICT - iMinds) en de vakgroep Bestuur en Beleid van de Hogeschool Gent. ●

Besluitvorming:

Stuurgroep bekrachtigt de adviezen van de werkgroepen. Bekrachtigt de projectkaarten incl. budget verantwoordelijk voor de scope van het project Iedere organisatie binnen het consortium heeft 1 stem ⅔ meerderheid is noodzakelijk voor besluitvorming

● ●

Financier: Projectduur:

OSLO Consortium 1 september 2013 - 1 september 2014 Commitment wordt aangegaan voor minimaal 1 jaar ● Afspraken: Stuurgroepleden zijn gerechtigd het OSLO logo te voeren per jaargang (OSLO 2013-2014)

8. Werkgroep: Dienstverlening Tools Governance Referentie implementatie Piloten Werkgroepen rapporteren online maandelijks voortgang aan de stuurgroep 9. Review platform: VDI coordinatiecommissie, GDI Stuurgroep 10.

Staten Generaal: Eind Mei; platform

11. 12. 13.

Overlegstructuren Verslaglegging Projectadministratie

Werkgroepen V-ICT-OR V-ICT-OR

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 specificatie3 . 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.

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.

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:

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

Tekst

Label

Tekst

Omschrijving

Tekst

Lijst

Tekst

Bron

Tekst

Versie

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. attribuut

datatype


Sleutel

Tekst

Type

Tekst

Bron

Tekst

Laatste wijziging

Datum/tijd

Revisie

Identificatie

Actief

Bool

Het attribuut ‘Actief’ wijst erop of deze entifier nog gebruikt wordt voor de entiteit waar het naar verwijst. Het attribuut ‘Revisie’ zorgt voor een link naar de vernieuwde identifier, indien van toepassing.

Voorbeeld Type RRK, KSZ, KBO, … Bron FOD buitenlandse zaken, Kruispuntbank Sociale Zekerheid, FOD Economie, Stad Kortrijk of via url’s ibz.rrn.fgov.be, kszbcss.fgov.be, economie.fgov.be, kortrijk.be 2.3.2.3 Herkomst Om onderbouwde beslissingen te kunnen nemen op het vlak van kerndata (cfr. masterdata 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


Bron

Tekst

KSZ, RRK, KBO(V)KBO, CRAB, GRB, AAPB, eigen bestuur, bestuur, derden (niet limitatieve lijst)

Betrouwbaarheid

Tekst

Datum laatste wijziging

Datum/tijd

Betrouwbaarheid kan de volgende waarden aannemen: gekoppeld (LINKED), eenmalig (ONCE) of manueel (MANUAL). 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.

Voorbeeld Betrouwbaarheid LINKED, ONCE, NEVER Bron ibz.rrn.fgov.be, kszbcss.fgov.be, economie.fgov.be, kortrijk.be, agiv.be, financien.belgium.be 2.3.2.4 Optin Optin en optout zijn termen die aangeven hoeveel controle de burger heeft over het gebruik van zijn gegevens. Optin 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 (eloket, loket, e.a.) te laten aangeven of deze gegevens mogen hergebruikt worden binnen een ander proces (bv. emailadres bibliotheek hergebruiken voor kinderopvang) schep je kansen voor het gebruik. attribuut

datatype


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.

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


Aanschrijfvorm

Tekst

Roepnaam

Tekst

RRK4

Telefoon

Tekst

Mobiel

Tekst

Fax

Tekst

Social

Tekst

Website

Tekst

Opmerking

Tekst

Optin

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 weburl 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.

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


Naam

Tekst

RRK, KSZ, wachtregister

Voornaam

Tekst


Andere voornamen

Tekst


Adellijke titel

Tekst


Geslacht

Tekst (Lijst)


Geboortedatum

Datum/tijd


Nationaliteit

Tekst (Lijst)


Datum overlijden

Datum/tijd


Burgerlijke staat

Tekst


Geboorteplaats

Tekst


Plaats van overlijden

Tekst


Wettelijk Samenwonend

Bool


Identificatie

Identificatie


relatie

doelentiteit


Is gedomicilieerd op

Verblijfsobject


Verblijft op

Verblijfsobject

lokale verrijking

Te bereiken op

Contact

Heeft Juridische onbekwaamheid

Code

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 onderscheiding5 . 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 ISO31661 Alpha3 of NIS en een beschrijving. Alternatief kan een ongestructureerde nationaliteit opgegeven worden (enkel tekst). Burgerlijke staat De term burgerlijke staat wordt in zijn enge betekenis gebruikt, d.w.z. ongehuwd, gehuwd, enz…. We refereren hiervoor naar de codetabellen6 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 woonplaats7 . ‘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 rijksregister8 (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 identificatienummer9 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 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 Onderrichtingen10 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

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 gezin11 in het rijksregister is. De plaats in het gezin kan met de volgende codes ingebracht worden (niet exhaustief12 ): ● 01 alleenstaand referentiepersoon van het gezin ● 02 echtgenoot, echtgenote ● 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 nieuwsamengestelde 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 rijksregister13 (code en omschrijving). Alternatief kan een ongestructureerd verband opgegeven worden (enkel tekst). 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 codetabellen14 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 ‘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


Geldigheidsperiode

Tijdspanne

relatie

doelentiteit


Type

Code

Behoort tot

Persoon


Refereert

Persoon


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. 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


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


Heeft KBOlocatie

Verblijfsobject

(V)KBO

Te factureren op

Verblijfsobject

Ontvangt post op

Verblijfsobject

Ontvangt leveringen op

Verblijfsobject

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.

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)KBOniveau 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 ('18000101') 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. BTWplicht) werden stopgezet én dat alle administratieve formaliteiten werden afgerond.

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#for ms!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#for ms!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 ● 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 meegegeven. Ingeval buitenlandse BTWplichtige ondernemingen wordt er bij voorkeur gewerkt

met de internationale identificatienummer15 . 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 BTWnummer, het nummer van het Rijksregister voor Rechtspersonen (RRRPnummer of Nationaal Nummer) én het RSZnummer. 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 maatschappelijke 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. ● 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 facturatieadressen 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 facturatieadressen 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 ● 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.

Oefent primair uit Oefent secundair uit De codes voor (primaire en secundaire) activiteiten worden gedefinieerd door de Nacebelcodes . De NACEcode 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. 16

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 typerelaties 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.

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


Geldigheidsperiode

Tijdspanne

relatie

doelentiteit


Groepeert

Organisatie

Behoort tot

Organisatie

Type

Code

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, email, 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 emailadres 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.

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, emailadressen 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


Functie

Tekst

Geldigheidsperiode

Tijdspanne

Type

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 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 KBOtabel 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


Persoon

Persoon

Organisatie

Organisatie

Contact

Contact

Type

Code

Is beschikbaar op

Verblijfsobject

Ontvangt post op

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.

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


Geldigheidsperiode

Tijdspanne

relatie

doelentiteit


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


Geldigheidsperiode

Tijdspanne

relatie

doelentiteit


Heeft geometrie

Geometrie

Heeft gebouw

Gebouw

Heeft perceel

Perceel

Adresseert

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


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).

GRB is een verzameling van geografische gegevens die in verschillende entiteiten ondergebracht worden. Elke entiteit wordt benoemd met een 3letter 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 GRBentiteiten opgenomen en niet hier. Bijvoorbeeld koeltorens, watertorens, e.d. worden opgenomen als kunstwerk (entiteit Knw).18 attribuut

datatype


Geldigheidsperiode

Tijdspanne

GRB

Bouwjaar

Datum/tijd

Identificatie

identificatie

GRB

relatie

doelentiteit


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.

attribuut

datatype


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


Verrijkt

Uitgebreid Adres

Bakent administratief af

Administratieve Afbakening

Land Het “Publications Office of the European Union”19 beveelt ISO 31661 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 31663 code gebruikt worden. 20

2.5.6 Uitgebreid adres

attribuut

datatype


Provincie

Tekst

Deelgemeente

Tekst

Postbus

Tekst

Locatienaam

Tekst

Locator (type)

Tekst

Volledig adres

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) Uitgebreid Adres:

provincie = OostVlaanderen 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. SchattemanGryp 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.

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: 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.

Basisadres: land = BE gemeente = BRUSSEL postcode = 1000 straatnaam = Anspachlaan huisnummer = 1 Uitgebreid Adres: postbus = 10001

Mappingtabel OSLO CRAB INSPIRE OSLO

CRAB

INSPIRE

UPUS42

Land

Admin unit level 1 (almost always a country)

country 40.14.0.0.0

Gemeente

gemeente

Admin unit level 5 town 40.16.0.0.0 (almost always a city or town)

Postcode

postKantonCode

Post Code

Straatnaam

straatNaam

Thoroughfare (a road, a thoroughfarename waterway etc.) 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)


busnumber extention designation 40.28.0.0.0

Locator


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

postcode 40.13.0.0.0

door indicator 30.32.0.0.2 Provincie

Admin unit level 2 (usually a county or state)

Deelgemeente

Address area (usually a town 40.16.0.0.0 city area or village)

Postbus

PO Box (a Delivery Service Type specialisation of locator 40.19.0.0.1 (‘Postbus’) designator) Delivery Service Indicator 40.19.0.0.2 PO Box Number or bpack station name

Locatienaam

Locator name (a proper Building/Construction name for a building or Level 1 30.26.1.0.0 room within a building)

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/admingeo/ Lijst van de huidige codes voor de deelgemeenten (NIScode fusiegemeente + letter) 40000: provincie OostVlaanderen ● 4 Provincie OostVlaanderen ● 0000 de code slaat op de volledige provincie 32000: arrondissement Diksmuide

● 3 Provincie WestVlaanderen ● 2 Arrondissement Diksmuide ● 000 de code slaat op het volledige arrondissement 23105: gemeente Affligem ● 23 Arrondissement HalleVilvoorde ● 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.

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


Streefdatum

Datum/tijd

Identificatie

Identificatie

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


Bevindt zich in

Status

Resulteert in

Code resultaat

Behoort tot

Dienstverlening

Volgt

Juridisch kader

Voorziet

Rol

Vereist

Initiatie

Levert

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. 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: nietontvangen, ontvangen, in behandeling, on hold, afgehandeld, afgebroken door initiator Een eerste interne status is Nietontvangen. 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 ddddjjjj." Resulteert in 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 OSLOmodel 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 initiatiedatum). ● 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.

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 naleven21 . klant: ● een individuele klant (burger) of een groep van klanten(organisatie). ● interne of externe klant. attribuut

datatype


Naam

Tekst

Inhoud

String

Geldigheidsduur

Tijdspanne

Identificatie

Identificatie

Type

Code

relatie

doelentiteit


Heeft toepassingsgebied

Locatie

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

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 backoffice 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 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


Identificatie

Identificatie

relatie

doelentiteit


Identificatie

bekrachtigt

machtiging

volgt

dienstverlening

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 ACM22 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, 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


Type

Code

relatie

doelentiteit


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


Vervult

Rol

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 OSLOmodel 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/corebusinessvocabulary 100 ● Dienstverlening: https://joinup.ec.europa.eu/asset/core_public_service/asset_release/corepublicservice vocabulary0

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 XMLschema 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 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: UnqualifiedDataTypesSchemaModule:2

udt

UN/CEFACT23

Datatypes

http://www.w3.org/ns/corevocabulary/ BasicComponents

cvb

ISA24

Basis componenten

http://www.w3.org/ns/corevocabulary /AggregateComponents

cva

ISA

Geaggregeerde componenten

urn:oslo:names:specification:schema:xsd :CommonBasicComponents1

ovc

OSLO

OSLO Basis componenten

urn:oslo:names:specification:schema:xsd :AggregateComponents1

ova

OSLO

OSLO Geaggregeerde componenten

[OASIS] Universal Business Language v2.1. http://docs.oasisopen.org/ubl/UBL2.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/CCTSVersion3.pdf [UN/CEFACT] UN Centre for Trade Facilitation and eBusiness 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 RDFschema 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 RDFschema 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 RDFschema. Een bijkomend voordeel is dat de set eigen definities in het OSLO RDFschema 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 GLD25

Organisaties

http://www.w3.org/ns/regorg

rov

W3C GLD

Geregistreerde Organisaties

http://www.w3.org/ns/person

person

ISA26

Personen

http://www.w3.org/ns/locn

locn

ISA27

Locaties

http://purl.org/vocab/cpsv

cpsv

ISA28

Publieke dienstverlening

http://purl.org/dc/terms/

dcterms DCMA29

Metadata

http://schema.org/

schema schema.org30

Markup, Metadata

http://www.w3.org/2006/vcard/ns

vcard

W3C

Contactgegevens

http://www.w3.org/ns/adms

adms

WRC GLD31

Standaarden, Codelijsten en Taxonomien

http://www.w3.org/2006/time

time

W3C32

Tijdsaanduiding

http://www.w3.org/ns/prov

prov

W3C33

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

person (OvpersonType)

person:Person

Organisatie

organization (OvorganizationType)

oslo:Organization

Hoedanigheid

membership (OvmembershipType)

oslo:Membership

Persoonsrelatie

PersonRelation (PersonRelationType)

oslo:PersonRelation

Organisatierelatie

OrganizationRelation oslo:OrganizationRelation (OrganizationRelationType)

Agent

(abstract) OvAgentType

dcterms:Agent

Locatie

Location (CvLocationType)

locn:Location

Verblijfsobject

ResidenceObject (OvresidenceobjectType)

oslo:ResidenceObject

Gebouw

building (OsloBuildingType) oslo:Building

Perceel

parcel (OsloParcelType)

oslo:Parcel

Basis Adres

address (OsloBaseAddressType)

oslo:BaseAddress

Dienstverlening

PublicService (OvPublicServiceType)

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)

identifier (OvidentifierType)

adms:identifier (adms:Identifier)

Code (alle types)

code (OvcodeType)

oslo:Code

Herkomst

provenance (OvprovenanceType)

prov:Entity

Contact

contact (OvcontactType)

oslo:contact (vcard:VCard)

Geometrie

geometry (cvb:GeometryType)

locn:geometry

Uitgebreid Adres (bij Basis Adres)

extendedAddress (OsloAddressType)

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 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

cvb:IssueDate

dcterms:issued

Revisie

ovc:revisionOf

prov:wasRevisionOf

Actief

ovc:isActive

oslo:isActive

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

Conceptueel

XML Schema

RDF

Naam

cvb:FamilyName

person:familyName

Voornaam

cvb:GivenName

person:givenName

Code (alle types)

Persoon

Andere voornamen cvb:PatronomycName

person:patronymicName

Geslacht

cvb:GenderCode

schema:gender

Adellijke titel

oslo:nobelityTitle

oslo:nobelityTitle

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

legalCohabetation (ovc:IndicatorType)

oslo:legalCohabetation

Burgerlijke staat

civilClass (ovc:OvcodeType)

oslo:civilClass

Juridische onbewkwaamheid

legalIncompetence (ovc:OvcodeType)

oslo:legalIncompetence

Is gedomicilieerd op domicile

oslo:domicile

Verblijft

residence

oslo:residence

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

Conceptueel

XML Schema

RDF

Maatschappelijke naam

cvb:LegalName

rov:legalName

Persoonsrelatie

Organisatie

Commerciële naam cvb:AlternativeName

dcterms:alternative

Afgekorte naam

cvb:AlternativeName

dcterms:alternative

Type

ovc:companyTypeOvbusi rov:orgType nessCode (ovc:OvcodeType)

Vestiging

isBranch (ovc:IndicatorType)

oslo:isBranch

Oprichtingsdatum

establishmentDate (ovc:OsloDateType)

oslo:establishmentDate

Datum stopzetting

shutdownDate (ovc:OsloDateType)

oslo:shutDownDate

KBO soort

kind (ovc:IndicatorType)

oslo:kind

KBO rechtsvorm

ovc:legalFormCode

oslo:legalFormCode

KBO rechtstoestand

ovc:legalStatusCode (ovc:legalStateEnumTyp e)

rov:companyStatus

KBO reden stopzetting

reasonShutdown (ovc:ReasonShutDownE numType)

oslo:reasonShutDown

KBO ovc:FunctionPhase Hoedanigheidsfase

oslo:functionPhase

KBO Hoedanigheid ovc:Function

oslo:function

KBO Status

ovc:companyStatusOvbu oslo:companyStatus sinessCode (ovc:OvcodeType)

activiteit

companyActivityOvbusin essCode (ovc:OvcodeType)

rov:companyActivity

KBO nummer

ovc:KBONumber

rov:registration

facturatielocatie

invoiceLocation oslo:invoiceLocation (OvresidenceobjectType)

KBO locatie

authenticLocation oslo:authenticLocation (OvresidenceobjectType)

leveringslocatie

deliveryLocation oslo:deliveryLocation (OvresidenceobjectType)

post locatie

mailingLocation oslo:mailingLocation (OvresidenceobjectType)

Organisatierelatie Conceptueel

XML Schema

RDF

behoort tot

from (OvorganizationType)

oslo:fromOrganization

groepeert

to (OvorganizationType)

oslo:toOrganization

geldigheid

ovc:validityPeriod

oslo:validityPeriod

Conceptueel

XML Schema

RDF

functie

ovc:membershipFunction oslo:membershipFunction

Hoedanigheid

geldigheidsperiode ovc:validityPeriod

org:memberDuring

type

ovc:membershipType (OvcodeType)

oslo:membershipType

ontvangt post op

mailingLocation oslo:mailingLocation (OvresidenceobjectType)

persoon

person (OvpersonType)

org:member

organisatie

organisation (OvorganizationType)

org:organization

beschikbaar op

availableAt oslo:availableAt (OvresidenceobjectType)

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

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

Conceptueel

XML Schema

RDF

uitgebreid adres

ovc:extendedAddress (OsloAddressType)

oslo:extended_address

bakent administratief af

ovc:adminUnit (OvcodeType)

oslo:adminUnit

Conceptueel

XML Schema

RDF

Streefdatum

ovc:targetDate

oslo:targetDate

Type

type (OvcodeType)

dcterms:type

Vereist

hasInput (OvDocumentType)

cpsv:hasInput

Levert

produces

cpsv:produces

Basisadres

Dienstverlening

(OvProductType) 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

Conceptueel

XML Schema

RDF

Type

roleType (OvcodeType)

dcterms:type

bestaat uit

permission (OvPermissionType)

oslo:hasPermission

vervult

agent (ovc:OvagentType) oslo:hasActor

Rol

Machtiging Conceptueel

XML Schema


RDF oslo:validityPeriod

Status Conceptueel

XML Schema

RDF

Type

statusType (OvcodeType)

oslo:statusType

Heeft statuscode

statusCode (OvcodeType)

oslo:statusCode

Toelichting

description

dcterms:description

Wijzigingsdatum

modificationDate

dcterms:modified

Initiatie

Conceptueel

XML Schema

RDF

Naam

name

dcterms:title

Inhoud

content (OvContentsType)

dcterms:description

Lokaliseert

location (locn:CvlocationType)

dcterms:spatial

Conceptueel

XML Schema

RDF

Type

productType (OvcodeType)

oslo:productType

Naam

name

dcterms:title

Inhoud

content (OvContentsType)

dcterms:description

Product

Geldigheidsperiode ovc:validityPeriod

oslo:validityPeriod

Heeft coverage toepassingsgebied (locn:CvlocationType)

dcterms:coverage

Locatie Conceptueel

XML Schema

RDF


oslo:validityPeriod

Heeft geometrie

locn:geometry

geometry (cvb:GeometryType)

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 schemainstantie 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): 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: Brickley Dan Hetzelfde antwoord in OSLO XML:

Brickley Dan

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 OCR34 kan voorkomen) wordt dit aangegeven. 4.1.1 email Gebruik enkel kleine letters, geen spaties. [email protected] 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 Een uitzondering hierop zijn speciale telefoonnummers die enkel lokaal geldig zijn:

0800 222 333 of 070 344 369 Naslagwerken ● ●

NBN Z 01002 (2002); Taalboek Nederlands (1996), p. 380 ITU, De Internationale Telecommunicatieunie 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/letterscards/send/best_practices.html . Naslagwerken ● ● ● ●

BIPT De Wereldpostvereniging (UPU), UPU Standard S42a Comité Européen de Normalisation (CEN), CEN 141421 Bureau voor Normalisatie, NBN EN 141421 De Internationale Organisatie voor Standaardisatie (ISO) , ISO 191601 (draft)

elementen

voorbeelden

verplicht

Naam

Paul Janssens

Functie Afdeling

Afdeling Kwaliteit

indien van toepassing

Organisatie Bedrijf

bpost


Gebouw, verdieping ...

Centraal gebouw verdieping 2 indien van toepassing

Straat, nummer en

Dendermondestraat 55

busnummer Postcode en gemeente

2018 ANTWERPEN

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.04153.09 4.1.6 Ondernemingsnummer Het ondernemingsnummer bestaat uit 10 cijfers en begint met een 0. Het formaat voor uitwisselling: 0xxx.xxx.xxx (1xxx.xxx.xxx in de verre toekomst) Het is belangrijk om enkel de cijfers te serialiseren. Om aan te geven of het om een onderneming of een vestiging gaat, gebruik de boolean isVestiging. 4.1.7 Vestigingsnummer Het vestigingsnummer bestaat uit 10 cijfers en begint met een 2. Het formaat voor uitwisselling: 2xxx.xxx.xxx Het is belangrijk enkel de cijfers te serialiseren. 4.1.8 Datum en tijd

Gebruik maken van XSD:DateTime formaat. "YYYYMMDDThh:mm:ss“ bvb. 20020530T16:45:00 Tijdsnotatie is optioneel: “YYYYMMDD” is ook geldig

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%20glob ale%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. 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 ● 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

5. Aanbeveling voor OSLO services De Richtlijnen voor Services beschrijven op het technische vlak de wijze waarop deze data ontsloten of uit gewisseld kunnen worden. De beschreven specificaties maken het mogelijk voor lokale besturen en hun dienstenleveranciers om services te implementeren in eigen toepassingen. Bij het uitwerken van de service wordt geen voorkeur voor het type webservice naar voren geschoven. Het is zowel mogelijk om uit te wisselen met een REST als een SOAP service. Op basis van de beschreven services rondom contactinformatie is het mogelijk geworden om ook voor andere services vanuit OSLO op basis van deze richtlijnen te gaan werken. Hierdoor ontstaat een eenduidige ontsluiting van persoons, organisatie, adres gegevens zoals OSLO dit beoogt. De specificatie van de service kan teruggevonden worden op: http://purl.org/oslo/services_specification

4.1 Colofon OSLO kwam tot stand met medewerking van: organisatie

naam

domein

AGIV

Jan Laporte

lokalisatie

AGIV

Tom Van Herck

lokalisatie

AGIV

Ziggy Vanlishout

lokalisatie

AGIV

Bjorn Devidts

lokalisatie

AMC

Thomas D’haenens

contactinformatie, dienstverlening

AMC

Yvan Samson


BCT

Math Huntjens

dienstverlening

BCT

Raf Withofs

formattering

CEVI

Daniëlle Koole

CORVE

Bart Misseeuw

contactinformatie

CORVE

Bruno Devrieze

CORVE

Geert Mareels

CORVE

Hans Arents

Stad Gent

Jan Godderis

contactinformatie

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

Digipolis Antwerpen

Stefan Marckx

lokalisatie

Digipolis Gent

Ann Bernaert


Digipolis Gent

Jo De Ruyver

lokalisatie

Digipolis Gent

Dirk Van Gasse


Digipolis Gent

Franky De Pestel

lokalisatie, dienstverlening

Digipolis Gent

Katrien Leire


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

Gent

Jo Dujardin


Gent

Diedrik Gaus

lokalisatie

HoGent

Pieter Sellenslagh

iMinds MMLAb

Miel Vander Sande

contactinformatie

iMinds MMlab

Pieter Colpaert

iMinds MICT

Mathias Van Compernolle

Stad SintNiklaas

Jo Crappé

contactinformatie

Infront

Maarten Verhaert

contactinformatie

Internet Society Belgium

Rudi Vansnick

ISACA

Marc Vael


KnokkeHeist

Dimitri Lefevre


contactinformatie

Kortrijk

Hans Verscheure


Remmicom

Jan Buelens


Schaubroeck

Wim Van Acker

Schaubroeck

Willem Van Hoecke

lokalisatie

Schaubroeck

Jelle De Vreese


VICTOR

Eddy Van der Stock


VICTOR

Ivan Stuer


VICTOR

Louis Massagé

VICTOR

Goedele Van der Spiegel

VLO

Herwig Hoskens

VTC

Anne Teughels


VTC

Caroline Vernaillen


Zwevegem

Luc Velghe

contactinformatie


Projectleiding ● Raf Buyle, VICTOR (project management) ● Laurens De Vocht, MMLabiMinds (technische verantwoordelijkheid) ● Johan Van der Waal (adviseur convenant) ● Erik Mannens, MMLabiMinds (technische verantwoordelijkheid)

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 ISAwerkgroepen 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. 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 uptodate 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 toplevel wetenschappelijke partners, multinationals en gebruikerspartners die de resultaten van SemanticGov onmiddellijk kunnen opnemen. url: http://islab.uom.gr/semanticgov/

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.kszbcss.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 personen35 . Voor meer informatie, zie http://www.kszbcss.fgov.be/nl/bcss/services/content/websites/belgium/services/service_institut ion/service_regional/service_01/service_04.html.

Concreet bestaan de Kruispuntbankregisters uit het BISregister (voor personen die niet in het RijksRegister opgenomen zijn, maar waarover een dossier beheerd wordt door de sociale zekerheid) en het RADregister (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.

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 ○ 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 ingeschreven36 . 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 KBOgegevens beperken”. Dit zijn: ○ Ondernemingen die hun gegevens onvoldoende up to date houden; ○ Procesmatige fouten of vertragingen in het KBOnetwerk (nl. verwerking van gegevens vanuit Ondernemingsloketten, griffies, notarissen, BTW, RSZ, Rijksregister…); ○ Historische fouten die in KBO werden opgeladen bij oprichting in 200337 ■ Voor meer informatie over de algemene kwaliteit van de gegevens opgenomen in KBO, verwijzen we naar ● http://www.corve.be/producten/magdadiensten/ondernemingsgegevens/k waliteit.php ● http://www.victor.be/nieuws/hogeschoolpubliceertonderzoeksrapporto verdevkbo 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 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 GDIdecreet 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 GDIVlaanderen. Het acroniem ‘CRAB’ staat voor ‘Centraal Referentieadressenbestand’. Het CRAB is het adressenproject van het samenwerkingsverband GDIVlaanderen 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 CRABproject 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 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 GRBdecreet. 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 uptodate 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_tcm460126738.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 ISO3166, de internationale standaard voor de specificatie van landen. De ISO3166 standaard omvat drie onderdelen:

- ISO31661: 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 ISO3166 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 ISO31661 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.

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

4.3.2 Contactinformatie

4.3.3 Lokalisatie

4.3.4. Dienstverlening

Partners In dit consortium zetelen BCT, de coördinatiecel Vlaams egovernment (CORVE), Stad Gent (Digipolis), Stad Antwerpen (Digipolis), Remmicom, CEVI, Schaubroeck, VICTOR.

Naast deze consortiumpartners werden een aantal experts betrokken. Het gaat om onder meer het Agentschap voor Geografische Informatie Vlaanderen (AGIV), de afdeling Monitoringsystemen en Crisiscoördinatie van het Departement Bestuurszaken (AMC), de Vlaamse Toezichtcommissie voor het elektronische bestuurlijke gegevensverkeer (VTC), de Federale Overheidsdienst voor Informatie en Communicatietechnologie (Fedict), bpost en de Europese Commissie (Interoperability Solutions for European Public Administrations). De lokale besturen werden betrokken via de stuurgroep lokaal egovernment, die de verschillende beroepsfederaties vertegenwoordigd. Daarnaast zetelen Gent, Antwerpen, Kortrijk, KnokkeHeist en Zwevegem in het permanente overlegorgaan. Rond specifieke usecases stemmen we uitgebreid af met andere lokale besturen. De academische partners die het traject mee bewaken zijn Multimedia Lab (MMLab iMinds) een onderzoeksgroep binnen de Universiteit Gent die wereldwijd onderzoek voert naar datastandaarden, Media en ICT (MICT) een onderzoeksgroep verbonden aan de Vakgroep Communicatiewetenschappen van de Universiteit Gent die zowel fundamenteel sociaalwetenschappelijk onderzoek als toegepast en beleidsgericht onderzoek uit in het domein van de nieuwe media en informatie en communicatietechnologieën en de vakgroep Bestuur en Beleid van de Hogeschool Gent die instaat voor de vertaalslag van OSLO naar het beleid..

Open Standaard voor Linkende Overheden (OSLO) specificaties v1.1

Recommend Documents