Concept URI-strategie

CONCEPT Nationale URI-Strategie voor Linked Data van de Nederlandse overheid

Status

Concept op basis van de "Aanzet tot een nationale URI-Strategie voor Linked Data van de Nederlandse overheid" Boek/URI-strategie.

Dit is WORK IN PROGRESS. De wiki houdt wijzigingen bij. Wil je meeschrijven? Graag! Vraag een account aan bij Support, log in en schrijf mee. Als dit document wordt vastgesteld zal een stabiele versie worden gepubliceerd. Doel is om de aanbeveling van de URI-strategie compact en direct toepasbaar op te schrijven.

Auteurs

Aan deze versie is geschreven door:

• Hans Overbeek - KOOP

Vertaling

To do: De definitieve versie vertalen naar het Engels zodat we internationaal feedback kunnen krijgen op onze ideeën.

Doelstelling

In Linked Data worden resources aangeduid, geïdentificeerd, met URIs: Uniform Resource Identifiers. URIs zijn de kleinste deeltjes waar Linked Data uit bestaat. Daarbij zijn veel keuzes te maken, bijvoorbeeld voor het patroon waarmee URIs worden gemunt en hoe je informatie over de resources publiceert. Die keuzes zijn van invloed op de bruikbaarheid en toegevoegde waarde van de Linked Data die ermee wordt gemaakt.

Om het maken van deze keuzes te vergemakkelijken doet de Nationale URI-strategie aanbevelingen aan iedereen die Linked Data publiceert.

Scope

De URI-strategie is primair gericht op referentie-data. Data waar niet naar wordt gelinkt valt buiten de scope. Om dit toe te lichten onderscheiden we drie categorieën informatiebronnen:

1. Standaarden die primair een referentiemodel publiceren (bijvoorbeeld een ontologie)
2. Authentieke registraties van referentieobjecten (bijvoorbeeld de Basisregistraties)
3. Data in 'gewone' Applicaties (bijvoorbeeld sensordata)

De URI-strategie is bedoeld voor Modellen en Referentieobjecten van zowel Standaarden als Authentieke registraties. Dus niet in eerste instantie voor de 'gewone' Data (onderste rij) of concepten in 'gewone' Applicaties (laatste kolom). Dit is eerder uitgebreider behandeld in Boek/URI-strategie.

Uitgangspunten

'Geen register, geen URI'

URIs voor referentiegegevens zijn alleen praktisch bruikbaar als je weet welke resource door welke URI wordt identificeert. Iemand die een URI gebruikt die hij niet zelf heeft gemunt weet alleen welke resource wordt geïdentificeerd als hij ergens op basis van de URI een beschrijving van de resource kan vinden. Omgekeerd weet hij alleen welke URI de ander aan een bepaalde resource heeft gegeven als hij op basis van een aantal eigenschappen van een resource die URI kan opzoeken.

Kortom: je kunt alleen URIs munten voor begrippen of objecten die vastliggen in een register. Dit belangrijke inzicht vatten we samen in het adagium: 'Geen register, geen URI'.

Het register vervult de volgende functies: - het registreert eigenschappen van resources (registratie) - het kent elke resource een unieke identifier toe: de URI (het munten) - het geeft op basis van een URI informatie over de resource terug (resolver) - het geeft op basis van resource-eigenschappen een URI terug (zoekfunctie)

Gebruik http-URIs

Zoals Tim Berners Lee uitlegt in Design Issue "Linked Data", is het nuttig om http-URIs te munten. Http-URIs zijn namelijk opvraagbaar in elke browser. De resolver van het register dat de http-URIs munt kan op het domein van de http-URIs informatie teruggeven aan een gebruiker die middels de URI om informatie vraagt.

Een tweede voordeel van het gebruik van http-URIs is dat het patroon van http-URIs is gebaseerd op het Domain Name System (DNS) dat domeinen toewijst aan partijen. De eigenaar van een domein kan http-URIs op dat domein munten en ervoor zorgen dat op dat domein een resolver informatie over de resources geeft die door de gemunte URIs worden geïdentificeerd. Op die manier krijgen derde partijen vertrouwen om de URIs te gaan gebruiken.

De Nationale URI-strategie beperkt zich tot aanbevelingen voor http-URIs.

Als het om vertrouwen gaat wordt vaak aangedrongen op het gebruik van 'https' in plaats van 'http'. Voor de URI is het echter niet relevant of deze op http of https is gebaseerd. De syntactische regels voor het URI-patroon zijn gelijk, dus bieden dezelfde mogelijkheden en binnen een Linked Data toepassing wordt de URI alleen gebruikt als een identificerende reeks tekens. Https speelt alleen een rol als er berichten worden uitgewisseld, bijvoorbeeld als een gebruiker de URI aanbiedt bij een resolver. De resolver kan op een http-request antwoorden met https, zodat het uitwisselen van de gegevens veilig blijft. Omdat veel URIs voor upper ontologies (denk bijvoorbeeld aan RDF, OWL, SKOS en Dublin Core) al http-URIs hebben en het aanmaken van aliassen in https ook nadelen heeft is de aanbeveling om http-URIs te blijven gebruiken en de resolvers met https te laten reageren. Een en ander wordt bediscussieerd in een blog bij W3C: HTTPS AND THE SEMANTIC WEB/LINKED DATA.

Respecteer namespaces

Door de opzet van http bieden http-URIs een elegante methode voor de vorming van namespaces. Het eerste deel van een http-URI bestaat namelijk uit een internetdomein dat middels DNS 'eigendom' is van een persoon of organisatie. Door alleen URIs te vertrouwen die zijn gemunt door de eigenaar van het domein in de namespace, voorkom je dat dezelfde URI wordt uitgegeven voor verschillende resources. Als registerhouder moet je dan ook een eenmaal gemunte URI niet meer dan 1 resource laten identificeren en alleen URIs munten op je eigen domein. Bijvoorbeeld het Dublin Core Metadata Initiative gebruikt de namespace "http://purl.org/dc/terms/" om de termen uit de Dublin Core vocabulary te munten. Het is tegen de conventies om zelf een term te munten op dat domein, bijvoorbeeld: "http://purl.org/dc/terms/translator".

Anticipeer op het gebruik van QNames

URIs kunnen in sommige gevallen lang worden en zijn, door de vaak cryptische onderdelen, soms moeizaam leesbaar voor menselijke gebruikers. In veel omgevingen is het mogelijk om een deel van een http-URI te vervangen door een kortere alias. Deze alias kan met een dubbele punt (":") voor de rest van de URI geplaatst worden waardoor een kortere string ontstaat die QName wordt genoemd.

Zo worden Dublin Core termen uitgegeven in de namespace http://purl.org/dc/terms/. Meestal wordt de prefix dcterms gebruikt als alias voor de namespace. http://purl.org/dc/terms/title heeft dan QName dcterms:title. Veel gebruikte prefixes zijn op te zoeken via prefix.cc.

Bij grote aantallen en handig gekozen aliassen kan dat ruimte besparen en het resultaat is vaak beter te lezen en te schrijven door menselijke gebruikers. URIs worden hoofdzakelijk gebruikt door software, maar niet exclusief! Bedenk dat veel data, dus ook Linked Data voortdurend door mensen geanalyseerd en toegepast wordt.

Overige uitgangspunten

Tot slot een aantal algemene principes die gehanteerd zijn:

1. Sluit aan bij internationale best-practices. Alleen ga je sneller, maar samen kom je verder. Door aan te sluiten op internationale ontwikkelingen profiteer je van oplossingen die wereldwijd bedacht worden. Ook is Europese regelgeving van steeds groter belang voor de Nederlandse overheid.
2. Sluit aan bij bestaande ontwikkelingen. De strategie raakt vele partijen en systemen en kan niet in een keer als iets nieuws worden ingevoerd. Kijk daarom goed naar wat er op het gebied van standaardisatie en authentieke registraties toch al gebeurt en maak daar maximaal gebruik van.
3. Houd rekening met afwijkende strategieën. Ook als er systemen worden gemaakt die om wat voor reden dan ook niet de nationale strategie volgen, moet hiermee gelinkt kunnen worden.
4. Houd het zo simpel mogelijk, maar niet simpeler. Bij een te complexe benadering zal de strategie niet of onvoldoende worden toegepast, bij een te eenvoudige benadering zal de strategie niet voldoende opleveren.

Alle aanbevelingen in deze Nationale URI-strategie zijn gericht op:

Persistentie.

Persistentie betekent dat oplossingen ook stand houden als de organisatie eromheen wijzigt. Ook al moeten we accepteren dat we nog niet alles weten en dat voortschrijdend inzicht tot andere keuzes kan leiden. Zie ook: "Cool URIs don't change". Persistentie betekent niet voor de eeuwigheid, maar 'zo lang als nodig'. Bedenk dat de URIs alleen gebruikt zullen worden als anderen ze dusdanig vertrouwen dat ze er bedrijfskritische applicaties afhankelijk van durven te maken.

Schaalbaarheid

Schaalbaarheid is van belang om beheerkosten te kunnen blijven overzien, ook als toepassingen groeien. Het is onvoorspelbaar hoeveel applicaties er in de toekomst zullen ontstaan. Elk onderdeel van de strategie zal dan ook schaalbaar moeten worden opgezet.

Begrijpelijkheid.

Begrijpelijkheid is noodzakelijk om te zorgen dat afspraken makkelijk worden opgepakt en overgenomen.

Vertrouwen.

Vertrouwen is nodig om organisaties te bewegen om zelf strategisch te kiezen voor het gebruik en publicatie van Linked Data.

Machine-leesbaarheid.

Machine-leesbaarheid zorgt ervoor dat er met Linked Data ook werkende oplossingen kunnen worden gebouwd.

Menselijke leesbaarheid.

Menselijke leesbaarheid is ook belangrijk om te zorgen dat men oplossingen vertrouwt en begrijpt. Maar als de machine de data niet goed gebruiken kan, dan werkt het überhaupt niet.

 …en bij voorkeur in die volgorde.

URI-patroon

Het aanbevolen patroon voor http-URIs is:

http://{domain}/{type}/{concept}/{reference}

{domain}

Het {domain} deel bevat het internet domein en eventueel een pad binnen dat domein:

{domain} = {internet domain}/{path}.

Het {domain} dient twee doelen. Ten eerste is het een belangrijk instrument om unieke identificaties te verkrijgen: twee objecten, die beheerd worden in twee verschillende databases, kunnen toevallig dezelfde identificatie krijgen (bijvoorbeeld een kadastraal perceel met id 010101 en een rechtspersoon met id 010101). Als nu zowel het Kadaster als het Nieuw HandelsRegister (NHR) besluit om deze objecten als linked data te publiceren, worden er toch twee unieke URIs gevormd: de een begint bijvoorbeeld met http://brk.nl/ en de ander met http://nhr.nl/. Ten tweede zorgt een goedgekozen domein voor herkenbaarheid en vertrouwen. Kadastrale percelen met een URI als http://data.brk.nl/perceel/010101 hebben een betrouwbaarder uitstraling dan bijvoorbeeld http://data.vindhethier.eu/perceel/010101.

Het {path} kan worden gebruikt als binnen een register verschillende verzamelingen objecten leven, waarbij dubbele id's kunnen voorkomen. Het {path} kan dan gebruikt worden om extra namespaces te creëren.

Aanbevelingen voor het {domain}

1. Één taak: het register

   Het {domain} is bij voorkeur exclusief gereserveerd voor publicatie van het register en het resolven van de URIs van het register. Als het domein namelijk een onderdeel is van een uitgebreider domein, waarop ook nog andere publicaties plaatsvinden, dan kan er vroeger of later sprake zijn van de noodzaak tot her-organisatie van de publicaties, met alle gevolgen van dien voor de persistentie van de URIs in het register.

2. Geen organisatienaam in het {domain}

   Het is sterk af te raden om in het {domain} een organisatienaam op te nemen, hoe verleidelijk dat ook vanuit marketing oogpunt kan zijn. Opnieuw is persistentie hierbij het belangrijkste argument. Organisaties kunnen immers gesplitst, gefuseerd, of hernoemd worden en zij krijgen dan doorgaans een nieuwe naam en kiezen een nieuw internetdomein. Het hernoemen van de URIs verstoort de persistentie. Het blijven gebruiken van het oude domein – iets waar puur technisch niets op tegen zou zijn – kan echter de indruk wekken dat de data ook verouderd is. Registers zullen over het algemeen blijven bestaan zolang ze een bepaald nut dienen. Als het register daadwerkelijk wordt opgeheven of overgaat in een nieuw register, dan zijn de modellen en referentieobjecten in het oude register doorgaans ook daadwerkelijk uit de tijd.

3. Terughoudend met {path}

   Probeer het gebruik van {path} zo veel mogelijk te vermijden. Hoe korter de URI, hoe handiger in gebruik. Hoe minder informatie in de URI, hoe kleiner de kans dat er later op teruggekomen moet worden.

{type}

Het {type} geeft aan om wat voor soort URI het gaat. Dit kan zijn:

'id'

identifier van een object (individual/instance) in een register.

'doc'

documentatie (metadata) over het object in het register.

'def'

definitie van een term in een ontologie.

Aanbevelingen voor {type}

1. Gebruik 303 redirect van de 'id'-URI naar de 'doc'-URI.

   In 'Cool URIs for the Semantic Web' wordt in sectie 4.2 uitgelegd hoe dit bedoeld is.

2. Gebruik Hash-URIs voor termen uit het model

   In een Linked Data applicatie is het onderscheid tussen model en content soms moeilijk te maken. In een relationele database is dat onderscheid doorgaans duidelijker: tabellen en kolommen geven het model aan en de inhoud van de tabellen vormen de content. In Linked Data kun je echter een klasse ook beschouwen als een instance (namelijk van de klasse rdfs:Class). Om de gebruiker van een register meer duidelijkheid te verschaffen over welke termen echt tot het model behoren en welke termen gezien kunnen worden als inhoud van het register, verdient het aanbeveling om de URIs van de eersten als hash-URI (#-URI) te definiëren: http://{domain}/def#{term}. Dit heeft als bijkomend voordeel dat de URI http://{domain}/def alle termen uit het model oplevert.

   In 'Cool URIs for the Semantic Web' wordt uitgelegd hoe dit bedoeld is in sectie 4.1.

   Als de ontologie erg omvangrijk is, kan ook gekozen worden om geen gebruik te maken van hash-URIs.

{concept}

Het {concept} geeft de menselijke lezer een indicatie van het soort concept dat de URI identificeert. Het {concept} is belangrijk om twee redenen. Ten eerste kan het een uitkomst bieden als objecten binnen de registratie geen unieke identifiers hebben, maar wel uniek zijn per soort object. Bijvoorbeeld gemeente Utrecht en provincie Utrecht. Ten tweede, en dit is belangrijker, levert het een begrijpelijker URI op. Een menselijke lezer kan vermoeden dat http://bagregister.nl/id/pand/01010101 de URI van een pand uit de BAG is.

Een mogelijk nadeel van het opnemen van {concept} in de URI is dat hiermee betekenis in de URI wordt opgenomen, terwijl betekenisloze IDs over het algemeen eenvoudiger persistent te maken zijn.

Aanbevelingen voor {concept}

1. {concept} betekent niets.

   Het is zeer onverstandig om {concept} enige betekenis toe te kennen voor de machine. URIs zijn in technische zin opaque. Het is dus niet zo dat het {concept} per se de klasse is waartoe een object behoort. Het helpt alleen de menselijke lezer, bijvoorbeeld de beheerder van een semantisch model, om de URIs te herkennen.

2. Denk ook bij het kiezen van {concept} aan persistentie.

   Als het in een registratie denkbaar is dat objecttypen (klassen) van naam veranderen, maar dan nog wel dezelfde klasse vertegenwoordigen, is het niet verstandig dit onderdeel in de URI op te nemen. Neem in dat geval een hogere klasse op. Volgens sommigen betekent het veranderen van het type van een instance per definitie dat er niet langer sprake is van dezelfde instance, maar van een andere instance, van het andere type. Voorbeeld: stel dat het Centraal Orgaan opvang Asielzoekers (COA) wordt omgevormd van zelfstandig bestuursorgaan (zbo) naar agentschap. En dat we als URI van het COA zouden kiezen voor: {domein}/id/zbo/coa. Dan wordt dat na de omvorming {domein}/id/agentschap/coa. Zouden we kiezen voor {domein}/id/organisatie/coa dan hoeven we de URI niet aan te passen, maar kunnen we ook geen onderscheid meer maken tussen de COA als ZBO en de COA als agentschap.

{reference}

De {reference} is de identificerende naam of code van het individuele object. Wat betreft {reference} geeft de URI strategie veel vrijheid, aangezien de eisen in verschillende toepassingen sterk uiteen kunnen lopen. Een {reference} kan zijn: een identificerend nummer, een alfanumerieke code, een woord of naam, etc. Elk register heeft wel een manier om de individuele objecten in de verzameling uniek aan te duiden. Deze unieke aanduiding kan worden opgenomen in de {reference}.

Aanbevelingen voor {reference}

1. Namen of nummers?

   Er is vaak discussie over het gebruik van 'betekenisloze' identifiers versus 'betekenisvolle' identifiers. Zolang computers geen bewustzijn hebben is elke URI voor de machine een betekenisloze string. Voor mensen kan ook een betekenisloze string betekenis krijgen: 020 (Amsterdam of Ajax), 013 (Tilburgs poppodium), 9292 (OV-informatie), nummer 14 (Johan Cruijff).

   Namen of nummers, voor beiden is wat te zeggen. Nummeren heeft als voordeel dat het nauwkeuriger lijkt en er geen homoniemen voor kunnen komen. Maar je verliest herkenbaarheid en hanteerbaarheid voor mensen, zonder steeds de labels bij de hand te hebben.

   • In de praktijk zijn de URIs voor de concepten in vrijwel alle semantische standaarden betekenisvol en bevatten zij doorgaans het volledige label (naam) waarmee de term voor de mens wordt aangeduid (meestal als CamelCase geschreven zodat er geen spaties in voorkomen).
   • Bij grote aantallen objecten wordt het ondoenlijk om voor elk object een herkenbare unieke naam te bedenken. We gaan dan - vrijwel vanzelf - nummeren.
   • Tussen deze twee uitersten zit een grijs gebied. Voor kleine, stabiele sets met objecten (bijvoorbeeld provincies) is het voordelig om de hele naam in de URI op te nemen, bij iets grotere sets, met meer mutaties, komen vaak lange namen voor die de URI onhandelbaar maken. Het kan dan een oplossing zijn om, als tussenvorm tussen volledige naam en een betekenisloos nummer, een afkorting in de URI te gebruiken.

2. Vermijd speciale tekens in een URI.

   Het is theoretisch mogelijk om allerlei speciale tekens in een URI te gebruiken, zoals ronde haken, komma's en zelfs single quotes. Wees echter zeer terughoudend in het gebruik van speciale tekens. Veel software heeft moeite om hier goed mee om te gaan. Bedenk dat URIs worden gebruikt op verschillende platformen en in uiteenlopende software. Hoe meer speciale tekens gebruikt worden, hoe groter de kans op problemen met de interoperabiliteit. Beperk je tot het gebruik van hoofdletters, kleine letters, cijfers, en eventueel hyphen en underscore ("-") als scheidingsteken.

3. Begin niet met een cijfer

   Als {reference} met een cijfer begint ontstaan ongeldige QNames, als het gedeelte tot de {reference} wordt vervangen door een alias en een ":". Bijvoorbeeld: als in de URI http://voorbeeld.com/id/object/12345 de namespace http://voorbeeld.com/id/object/ vervangen wordt door alias vb ontstaat de ongeldige QName vb:12345, want het LocalPart mag niet beginnen met een cijfer.

Weergave van een feit, begrip of aanwijzing, geschikt voor overdracht, interpretatie of verwerking door een persoon of apparaat

Ga naar de pagina met de definitie van 'Data'

Weergave van een feit, begrip of aanwijzing, geschikt voor overdracht, interpretatie of verwerking door een persoon of apparaat

Ga naar de pagina met de definitie van 'Data'

Weergave van een feit, begrip of aanwijzing, geschikt voor overdracht, interpretatie of verwerking door een persoon of apparaat

Ga naar de pagina met de definitie van 'Data'

Weergave van een feit, begrip of aanwijzing, geschikt voor overdracht, interpretatie of verwerking door een persoon of apparaat

Ga naar de pagina met de definitie van 'Data'

Een Uniform Resource Identifier (URI), is een internet-protocolelement, gebaseerd op eerdere voorstellen van Tim Berners-Lee. Het is een unieke benaming van een bron, een stuk informatie, data of dergelijke.

Ga naar de pagina met de definitie van 'URIs'

Zie ook bij data usability en bij vindbaarheid.

Ga naar de pagina met de definitie van 'bruikbaarheid'

Weergave van een feit, begrip of aanwijzing, geschikt voor overdracht, interpretatie of verwerking door een persoon of apparaat

Ga naar de pagina met de definitie van 'data'

Weergave van een feit, begrip of aanwijzing, geschikt voor overdracht, interpretatie of verwerking door een persoon of apparaat

Ga naar de pagina met de definitie van 'data'

Weergave van een feit, begrip of aanwijzing, geschikt voor overdracht, interpretatie of verwerking door een persoon of apparaat

Ga naar de pagina met de definitie van 'data'

Weergave van een feit, begrip of aanwijzing, geschikt voor overdracht, interpretatie of verwerking door een persoon of apparaat

Ga naar de pagina met de definitie van 'data'

Weergave van een feit, begrip of aanwijzing, geschikt voor overdracht, interpretatie of verwerking door een persoon of apparaat

Ga naar de pagina met de definitie van 'gegeven'

Weergave van een feit, begrip of aanwijzing, geschikt voor overdracht, interpretatie of verwerking door een persoon of apparaat

Ga naar de pagina met de definitie van 'gegeven'

Weergave van een feit, begrip of aanwijzing, geschikt voor overdracht, interpretatie of verwerking door een persoon of apparaat

Ga naar de pagina met de definitie van 'gegeven'

Weergave van een feit, begrip of aanwijzing, geschikt voor overdracht, interpretatie of verwerking door een persoon of apparaat

Ga naar de pagina met de definitie van 'gegeven'

Weergave van een feit, begrip of aanwijzing, geschikt voor overdracht, interpretatie of verwerking door een persoon of apparaat

Ga naar de pagina met de definitie van 'gegevens'

Weergave van een feit, begrip of aanwijzing, geschikt voor overdracht, interpretatie of verwerking door een persoon of apparaat

Ga naar de pagina met de definitie van 'gegevens'

Weergave van een feit, begrip of aanwijzing, geschikt voor overdracht, interpretatie of verwerking door een persoon of apparaat

Ga naar de pagina met de definitie van 'gegevens'

Weergave van een feit, begrip of aanwijzing, geschikt voor overdracht, interpretatie of verwerking door een persoon of apparaat

Ga naar de pagina met de definitie van 'gegevens'

Formele definitie van de klassen, eigenschappen en relaties van een datastructuur en de bijbehorende constraints als een knowledge graph

Ga naar de pagina met de definitie van 'ontologies'

Resource Description Framework (RDF) is een standaardmodel voor gegevensuitwisseling op het web. RDF heeft functies die het samenvoegen van gegevens vergemakkelijken, zelfs als de onderliggende schema's verschillen, en het ondersteunt specifiek de evolutie van schema's in de loop van de tijd zonder dat alle gegevensgebruikers moeten worden gewijzigd.

Ga naar de pagina met de definitie van 'RDF'

De Web Ontology Language (OWL) is de standaard van W3C voor het definiëren van ontologieën voor het wereldwijd web. Deze ontologieën worden door de formele semantiek gekenmerkt, gebaseerd op de standaard RDF voor objecten van W3C.

Ga naar de pagina met de definitie van 'OWL'

Simple Knowledge Organization System (SKOS) is een internationale standaard voor het maken van taxonomieen en thesauri

Ga naar de pagina met de definitie van 'SKOS'

Het World Wide Web Consortium is een organisatie die de webstandaarden voor het wereldwijde web ontwerpt, zoals HTML, XHTML, XML, CSS en de Web Content Accessibility Guidelines. Het wordt geleid door Tim Berners-Lee, de originele bedenker van het HTTP-protocol en HTML, waar het web oorspronkelijk en nog steeds grotendeels op gebaseerd is.

Ga naar de pagina met de definitie van 'W3C'

Schaalbaar of schaalbaarheid is de mogelijkheid om de capaciteit van een ICT-configuratie eenvoudig groter te maken als er meer capaciteit nodig is bij één (of meer) van de componenten binnen een configuratie (denk aan server-, geheugen-, opslagcapaciteit, etc)

Ga naar de pagina met de definitie van 'Schaalbaarheid'

Basisregistratie Handelsregister (NHR).

Ga naar de pagina met de definitie van 'NHR'

Een gemeente is een groep van woonkernen (dorpen, steden) met het bijbehorende gebied die samen worden bestuurd door een politiek apparaat

Ga naar de pagina met de definitie van 'gemeente'

Een provincie is een deelgebied van een land met een eigen regionale regering

Ga naar de pagina met de definitie van 'provincie'

Een provincie is een deelgebied van een land met een eigen regionale regering

Ga naar de pagina met de definitie van 'provincie'

Een provincie is een deelgebied van een land met een eigen regionale regering

Ga naar de pagina met de definitie van 'provincies'

Een provincie is een deelgebied van een land met een eigen regionale regering

Ga naar de pagina met de definitie van 'provincies'