DCAT-AP-DONL 2.0

More details about this document
Laatst gepubliceerde versie:
https://dataoverheid.github.io/dcat-ap-donl/
Laatste werkversie:
https://dataoverheid.github.io/dcat-ap-donl/
History:
Commit history
Redacteurs:
Casper le Gras (Kennis- en exploitatiecentrum voor Officiële Overheidspublicaties)
Willem ter Berg (Kennis- en exploitatiecentrum voor Officiële Overheidspublicaties)
Kees Trautwein (Logius)
Former editors:
Jan Meijer (Kennis- en exploitatiecentrum voor Officiële Overheidspublicaties)
Huub van Oers (Dienst Uitvoering Onderwijs)
Feedback:
GitHub dataoverheid/dcat-ap-donl (pull requests, new issue, open issues)

Samenvatting

Dit document beschrijft de specificatie van het toepassingsprofiel van DCAT 2 voor data.overheid.nl. Het is een doorontwikkeling van DCAT-AP-DONL 1.1 dat rekening houdt met het toepassingsprofiel DCAT-AP 2.1 van de EU.

1. Introductie

De Data Catalog vocabulaire (DCAT) is een standaard met als doel gepubliceerde gegevens en gegevensdiensten te beschrijven. Daardoor kunnen potentiële gebruikers beoordelen of de aangeboden gegevens voor hen relevant zijn en geschikt zijn voor hun gebruik. Dit selectieproces kan ook (gedeeltelijk) automatisch uitgevoerd worden. De geselecteerde bronnen kunnen dankzij de DCAT beschrijvingen efficiënt benaderd worden voor gebruik, of na detailonderzoek alsnog worden verworpen.

Daarnaast is het gebruikelijk om DCAT beschrijvingen op centrale systemen te verzamelen – bekend als "harvesting" – om overzichten te maken van alle aangeboden informatie in een bepaald domein, bijvoorbeeld een land of volgens andere criteria. Deze centrale DCAT registers maken het eenvoudig voor gebruikers om door een groot aanbod te zoeken naar nuttige gegevens en data services.

data.overheid.nl is zo'n DCAT dataportaal van de Nederlandse overheid. Een voorbeeld van een ander portaal is die van de EU, namelijk data.europa.eu. De EU leest de DCAT data van data.overheid.nl, daardoor zijn alle datasets van data.overheid.nl ook op data.europa.eu te vinden. Het gebruik van DCAT maakt dit soort cummulatieve verzamelingen mogelijk.

Het doel van het DCAT-AP-DONL profiel is om betere beschrijvingen te verzamelen in data.overheid.nl. Het is ietwat uitgebreider dan de onderliggende DCAT-AP 2.1 en DCAT 2.0 profielen van het W3C, zodat het vinden van de juiste gegevens en gegevensdiensten nog makkelijker wordt.

Dit toepassingsprofiel blijft in ontwikkeling. Commentaren, problemen, wensen e.d. kunnen als issue worden gemeld op de Github pagina.

Noot

2. Overzicht van het toepassingsprofiel

Het volgende diagram geeft een overzicht van de basis functionaliteit van DCAT 2 en dient als startblok voor het begrijpen van de construcie. LET OP, er zijn dus meer klassen, eigenschappen en relaties dan weergegeven zoals te zien in klassen.

DCAT 2.0 in het kort
Figuur 1 DCAT 2.0 in het kort.

2.1 Relatie andere profielen

In deze nieuwe versie zijn de nieuwe mogelijkheden van het toepassingsprofiel van de EU (DCAT-AP 2.1) meegenomen, samen met aanpassingen op basis van ervaring welke is opgedaan sinds DCAT-AP-DONL 1.1. DCAT-AP-DONL 2.0 is compatible met bovenstaande standaarden, wat betekent dat een profiel dat voldoet aan DCAT-AP-DONL 2.0 ook verwerkt kan worden binnen DCAT 2.0 en DCAT-AP 2.1. Het is ook backwards-compatible met DCAT-AP-DONL 1.1 waardoor beschrijvingen uitwisselbaar zijn tussen beide profielen. Eigenaren van bestaande DCAT-omschrijvingen volgens het DCAT-AP-DONL 1.1 profiel kunnen overwegen hun omschrijving te optimaliseren om hun databronnen beter te beschrijven.

DCAT-AP-DONL 2.0 positionering
Figuur 2 DCAT-AP-DONL 2.0 positionering

Om zoveel mogelijk scenario's te ondersteunen, verplichten de originele DCAT 2.0 van het W3C en het toepassingsprofiel van de EU (DCAT-AP 2.1) weinig. Omdat data.overheid.nl alleen de Nederlandse overheid betreft kunnen we meer informatie van gebruikers vragen. Daarmee worden gegevens beter vindbaar.

Op dit moment is DCAT v3 bij W3C in ontwikkeling, deze gaat verder in op het gebruik van versiebeheer bij datasets en distributies. Na het vaststellen van deze standaard zal er waarschijnlijk een nieuw DCAT-AP profiel verschijnen. Daarna zal gekeken worden of het DCAT-AP-DONL profiel ook bijgewerkt zal worden.

2.2 Verschillen

2.2.1 Introductie van klasse dcat:DataService

Met een Dataservice kan men toegang krijgen tot (een selectie of bewerking van) gegevens van een of meer datasets, speciaal bedoeld voor geautomatiseerde koppelingen tussen systemen. Voorbeelden zijn API- of WMS services.

De DataService klasse is geïntroduceerd in versie 2 van DCAT. Het biedt uitgebreidere mogelijkheden om geautomatiseerde toegang tot gegevens te beschrijven dan mogelijk is in de klasse dcat:Distributie. In deze nieuwe versie van het toepassingsprofiel is de DataService klasse optioneel. Dat betekent dat het mogelijk blijft om dataservices te beschrijven met de klasse Distributie.

2.2.2 Nieuwe eigenschappen

In het toepassingsprofiel worden nieuwe eigenschappen aangegeven met de tag nieuw.

2.3 Namespaces

Dit toepassingsprofiel maakt gebruik van de namespaces zoals weergegeven in de onderstaande tabel.

Prefix URI
adms http://www.w3.org/ns/adms
dcat http://www.w3.org/ns/dcat
dcatap http://data.europa.eu/r5r/
dct http://purl.org/dc/terms/
foaf http://xmlns.com/foaf/0.1/
overheid http://standaarden.overheid.nl/owms/terms
prov http://www.w3.org/ns/odrl/2/
rdfs http://www.w3.org/2000/01/rdf-schema
skos http://www.w3.org/2004/02/skos/core
spdx http://spdx.org/rdf/terms
xsd http://www.w3.org/2001/XMLSchema
voaf http://purl.org/vocab/vann/
vcard http://purl.org/vocommons/voaf%23
time http://www.w3.org/2006/time

2.4 Omschrijving eigenschappen

Naam van de eigenschap

Dit is de originele engelstalige naam zoals gebruikt in de W3C specificatie van DCAT 2.0, DCAT-AP 2.1 en DCAT-AP-DONL 1.1.

Definitie

Dit is de Nederlandstalige definitie van de eigenschap.

RDF-eigenschap

Dit is de (technische) naam van de eigenschap die van toepassing is voor de uitwisseling van de DCAT data.

Bereik

Beschrijft de mogelijke waarden van de eigenschap.

Kardinaliteit

Geeft aan of de eigenschap eigenschap 0, 1 of meerdere keren mag voorkomen. Hierbij wordt gebruik gemaakt van de schrijfwijze x..y, waarbij x het minimaal aantal voorkomens aangeeft en y het maximaal aantal. Bijvoorbeeld 1..n geeft aan dat de eigenschap een of meer keer mag voorkomen. Overigens stelt W3C specificatie van DCAT 2.0 geen eisen aan de cardinaliteit van de eigenschappen, maar DCAT-AP 2.1 wel.

Gebruik

Beschrijft of een eigenschap aanwezig moet zijn, wordt aangegeven met een van de onderstaande termen.

Terminologie Nederlands Definitie
Mandatory Verplicht Deze eigenschap moet aanwezig zijn om aan dit applicatieprofiel te voldoen.
Recommended Aanbevolen Deze eigenschap is erg waardevol, maar de aanwezigheid is niet verplicht, meestal omdat de eigenschap niet in alle gevallen betekenis heeft. Er wordt sterk aangeraden deze eigenschap in te vullen waar dat kan.
Optional Optioneel Deze eigenschap wordt ondersteund en kan worden ingevuld naar wens

2.5 Overerving

DCAT 2 bevat verschillende klassen waarin dezelfde informatie opgenomen kan worden. Bij overerving wordt informatie uit de ene klasse automatisch overgenomen naar de andere. DCAT-AP-DONL 2 ondersteunt dit niet.

2.6 Ondersteuning voor meertaligheid

In language en resource language kunnen de talen worden beschreven die worden gebruikt in de inhoud van de resource of distributie. Zo zal een dataset over straatmeubilair waarin de waardes 'lantarenpaal' of 'bankje' worden gebruikt als resource language 'Nederlands' krijgen. Dit is ongeacht of deze taal of talen gebruikt worden in de metadata. Wanneer er meerdere talen worden gebruikt wordt de eigenschap herhaalt voor alle gebruikte talen. Wanneer de inhoud geen taal bevat, bijvoorbeeld omdat alle waardes nummeriek zijn, worden deze eigenschappen weg gelaten.

Eigenschappen als dct:title, dct:description en dct:rights kunnen waardes in verschillende talen bevatten. Voor elke vertaling wordt de eigenschap herhaalt met de toevoeging van een language tag om aan te geven in welke taal de waarde geschreven is. Elke taal mag slechts één keer voorkomen.

In dit data.overheid.nl profiel worden de volgende talen onderteund:

Taal Tag
Duits de
Engels en
Fries fy
Nederlands nl

Op data.overheid.nl worden teksten geïndexeerd, zodat eindgebruikers de datasets, dataservices of catalogi kunnen terugvinden op basis van één of meer woorden in de tekst.

2.7 Vindbaarheid

Het aantal DCAT beschrijvingen of verzamelingen van DCAT beschrijvingen zoals data.overheid.nl kan zo groot worden dat gebruikers niet meer handmatig door het aanbod kunnen zoeken. Het is dan noodzakelijk met behulp van zoekcriteria en filters uit het aanbod de juiste gegevens te kunnen vinden. De verschillende eigenschappen waarmee de gegevens in DCAT worden beschreven kunnen allemaal als zoekcriteria gebruikt worden. Hoofdfunctie van veel eigenschappen is om de gebruiker duidelijk te maken onder welke technische, juridische en andere voorwaarden de gegevens gebruikt kunnen worden. Dat is nuttig om te weten als de gebruiker de gegevensbeschrijving al gevonden heeft, maar deze waardes helpen zelden uit het grote aanbod een inhoudelijke keuze te maken. Voor dat doel bestaat een andere groep eigenschappen. Twee belangrijke eigenschappen daarbij zijn de titel en de beschrijving van de DCAT klasse. Vier andere eigenschappen die de vindbaarheid vergroten zijn keyword, theme, type en conformsTo, ieder met hun eigen krachten en zwaktes.

2.7.1 Tekstuele beschrijvingen

De eigenschappen title, keyword en description bevatten vrije tekst die door de opsteller van de DCAT beschrijving worden vastgesteld om de gegevens zo goed mogelijk te beschrijven. Deze teksten zijn in eerste instantie op menselijke gebruikers gericht, omdat mensen makkelijk betekenis aan tekst geven. Er mag slechts één titel en één beschrijving worden opgegeven (per taal), maar er kunnen meerdere keywords gebruikt worden door de eigenschap te herhalen.

Het gebruik van deze velden voelt heel natuurlijk aan, maar de vindbaarheid van deze drie velden is niet optimaal. De waardes in deze velden – en dus de gerelateerde gegevens – worden alleen gevonden als een gebruiker dezelfde woorden gebruikt als de opsteller. Dat blijkt in de praktijk vaak verkeerd te gaan. Ten eerste moet de gebruiker enige voorkennis hebben om de juiste termen te gebruiken. Bovendien moet de opsteller de teksten zo schrijven dat alle mogelijke, relevante zoektermen deze gegevens zullen vinden. Echter, het ligt in de lijn der verwachting dat sommige (toekomstige) gebruikers behoefte aan deze data hebben, die de opsteller niet kan voorzien of dat gebruikers tot een doelgroep behoren die de opsteller niet kent. Bovendien zijn voor een sluitende beschrijving al snel veel woorden nodig. Daardoor wordt de informatie lastiger te lezen en te begrijpen.

Een voorbeeld: Stel dat we een dataservice hebben met gegevens over lantaarnpalen in gemeente Vrolijkland. Het ligt voor de hand dat het woord "lantaarnpaal" als keyword wordt gebruikt. Om beter vindbaar te zijn, zouden we ook de keywords “straatverlichting” en “straatmeubilair” kunnen toevoegen. Als we daarnaast een distributie met gegevens over "bushokjes" hebben, dan gebruiken we daar het keyword “bushokje”. Dan moeten we daar eigenlijk ook hetzelfde keyword “straatmeubilair” aan toevoegen om consequent te zijn. En mogelijk het synoniem "bushuisje". En met enige komen we waarschijnlijk op extra keywords. Misschien willen we ook in de keywords aangeven dat het de gemeente Vrolijkland betreft, enzovoorts. Als iedere partij zijn eigen keywords moet verzinnen, ontstaat er een wildgroei aan keywords die telkens door iedere aanleverende partij moet worden toegevoegd. Dat is veel werk voor de aanleveraars en terwijl de gebruikers ondanks al dat werk allerlei gegevens niet zullen vinden omdat ze toevallig niet de juiste woorden gebruiken. Hoewel de keywords in een behoefte voorzien, hebben we ook een meer gestructureerde aanpak nodig.

2.7.2 Thema's uit een voorgedefinieerde lijst

Een oplossing voor het probleem met keywords, titels en beschrijvingen is het toevoegen van één of meer thema’s. Een thema maakt deel uit van een waardelijsten met een beperkte aantal mogelijk waardes waarvan de betekenis duidelijk beschreven is. Op die manier kan er eenvoudig getoond worden welke thema's beschreven en gevonden kunnen worden, wat zoeken en filteren van, gecumuleerde, DCAT beschrijvingen voorspelbaarder maakt.

Voorbeelden van thema’s zijn de Thema-indeling voor Officiële Publicaties, de lijst met Nederlandse overheidsinstellingen of de Clusterbegrippen van de Stelselcatalogus. Een extra voordeel van thema-lijsten is dat automatische systemen ze kunnen gebruiken omdat de waardes bekend zijn.

Een nadeel van thema’s is dat iedere waarde toegevoegd moet zijn aan de thema’s-taxonomie, anders is deze waarde niet beschikbaar. Dat betekent dat de juiste thema-lijsten aangeboden moeten worden. En deze thema-lijsten moeten goed onderhouden worden zodat de juiste waardes beschikbaar zijn voor de gebruikers. Dus ook met thema's houden keywords hun waarde omdat ze nieuwe waardes kunnen bevatten die niet in een thema zijn opgenomen.

Merk op dat DCAT-AP 2.1 en DCAT 2.0 het mogelijk maken in een catalog een thema-taxonomie te definiëren, die daarna door alle klassen - die onder de catalog vallen - gebruikt kunnen worden. Hiemee kunnen als het ware "lokale" en gespecialiceerde thema's worden toegevoegd. Maar het toevoegen van dit soort thema's heeft ook nadelen. Omdat data.overheid.nl catalogs van aanbieders niet overneemt, kan zo'n themeTaxonomy niet gedeeld worden met anderen. Maar ook buiten data.overheid.nl lijkt deze eigenschap slechts beperkt nuttig. Een “lokaal” geïntroduceerde” themataxonomie zal alleen bekend zijn bij alle gebruikers als zij zich deze lokale taxonomie eigen maken, wat flinke inspanningen kan vragen. Daarmee lijkt het gebruik van deze eigenschap alleen praktisch haalbaar als een catalog waarin deze taxonomie wordt gedefinieerd veel datasets of dataservices bevat waarbij er toegevoegde waarde is voor de gebruikers. In zijn algemeenheid lijkt het beter alleen breed gedragen thema-taxonomieën te gebruiken, omdat gebruikers anders niet begrijpen welke thema-waardes ze kunnen kiezen. Dan worden de gegevens alsnog niet gevonden.

2.7.3 Verwijzingen naar standaarden op het web

ConformsTo wordt gebruikt om aan te geven aan welke standaard de gegevens voldoen. Onder een standaard kan hier ook een verzameling afspraken vallen, de scope is breder dan alleen technisch, inhoudelijke standaarden. Omdat gegevens aan verschillende standaarden kunnen voldoen, kan het conformsTo attribuut worden herhaald. Een aantal standaarden worden al expliciet door het DCAT profiel uitgevraagd. Denk bijvoorbeeld aan mediaType of format. Er bestaan echter zeer veel standaarden op ieder niveau van het aanbod. De gegevens zelf kunnen bijvoorbeeld via een speciale methode zijn verzameld. Ook kan het zijn dat de gegevens op een bepaalde manier zijn weergegeven. Ook willen we kunnen aangeven via welke interface gegevens worden uitgewisseld. Maar ook de standaarden waaronder de gegevens zijn verzameld zouden weergegeven kunnen worden.

ConformsTo is breder toepasbaar dan Thema’s maar gestructureerder dan keywords. Dat wordt bereikt door de waarde van een ConformsTo niet te beperken tot een vooraf gedefinieerde waardelijst en zelfs niet tot Linked Data. ConformsTo bevat altijd een webadres. Bij voorkeur wordt er een URI gebruikt van de standaard zoals die in het Linked Data domein is gedefinieerd, omdat een definitie in het Linked Data domein hoogwaardig is. De URI heeft heldere definites en een partij die deze URI onderhoudt. Vaak zal het gegeven ook deel uitmaken van een groter geheel, wat via de standaard Linked Data methodieken leidt tot extra semantische informatie en connecties.

Maar er zijn zeer veel en zeer diverse strandaarden waaraan een gegevensverzameling kan voldoen. En lang niet altijd zal er een URI gedefineerd zijn. Een keuze is dan eigen definities te maken, maar dat brengt extra werk met zich mee en niet iedere partij wil dergelijke verplichtingen aan gaan. Daarom mag conformsTo ook een URI bevatten buiten het Linked Data domein, zolang die URI op het internet altijd leidt naar pagina's met informatie over de standaard. Het meest gebruikte voorbeeld is een verwijzing naar een webpagina waarop de betreffende standaard wordt beschreven.

Een nadeel van deze tweede waarde hebben we ook al gezien bij keywords. De waarde kan door iedere opsteller vrij gekozen worden. Daarmee wordt zoeken lastiger. Toch is de situatie hier wel beter. Ten eerste wordt de keuze van de opsteller beperkt. Voor veel standaarden zal er één specifieke website zijn waar de standaard gedefinieerd wordt, waardoor veel mensen dezelfde URI zullen gebruiken. Maar zeker bij breed gebruikte of juiste hele specifieke standaarden zullen opstellers vaak verschillende websites als meest representatief voor de standaard bestempelen.

Een groot voordeel t.o.v. keywords is dat ook deze URI hun eigen documentatie bevatten. Een verwijzing naar de website van de standaard geeft de gebruiker toegang tot de betekenis, gebruik en andere informatie over de betrokken standaard.

2.7.4 Eigenschap "Type" wordt niet gebruikt

In DCAT-AP-DONL_2 wordt type niet opgenomen omdat er op dit moment weinig toegevoegde waarde is t.o.v. Keyword, Theme en ConformsTo. In DCAT 2.0 en DCAT-AP 2.1 worden suggesties gedaan welke lijsten voor types gebruikt kunnen worden, maar deze waardes zijn voor data.overheid.nl weinig nuttig. Sommige waardelijsten overlappen met andere DCAT waardelijsten, anderen zijn gericht op andere toepassingen en lijken meer verwant aan mediatype. Weer anderen waardelijsten worden gebruikt voor de communicatiebehoeftes van een zeer beperkt toepassingsgebied. De EU definieert een lijst die het soort organisaties beschrijft. Door de beperkte bruikbaarheid van de gesuggereerde type-waardelijsten en de overlap met andere prospecties en de beschikbaarheid van ConformsTo en Theme, leidt Type tot veel verwarring, redundantie en fouten. Om deze redenen wordt dcat:type niet gebruikt in DCAT-AP-DONL_2.

3. Klassen

In dit hoofdstuk worden de klassen van het applicatieprofiel benoemd en beschreven.

DCAT-AP-DONL 2.0 klassen
Figuur 3 DCAT-AP-DONL 2.0 klassen

Ga snel naar:

3.1 Dataset (dcat:Dataset)

Subklasse van dcat:Resource

Een dataset is een gegevensverzameling. Op data.overheid.nl is deze samengesteld en gepubliceerd door een (overheids-)organisatie.

De klasse beschrijft de dataset als concept. Het staat dus los van de gegevensverzameling zelf, die mogelijk beschikbaar is in een of meerdere representaties, formaten of serialisaties.

De DCAT standaard heeft een ruime opvatting over de aard van de gegevens die een dataset kunnen vormen. Voor data.overheid.nl gaat het vooral over Open Data die afkomstig zijn van overheidsorganisaties, maar is hiertoe niet beperkt. De aard van de data zijn o.a. numeriek, tekstueel, afbeeldingen, geluid en andere multimedia. Naast data.overheid.nl zijn systemen zoals PLOOI vooral gericht op de publicatie van open documentaire data in het kader van de Wet open overheid, zoals PDF-bestanden. Hierbij worden weer andere standaarden dan DCAT gebruikt om de metadata van deze publicaties te beschrijven. Het is denkbaar dat collecties van documenten (bijvoorbeeld van een bepaalde organisatie of over specifieke onderwerpen) worden opgenomen in datasets, die vervolgens volgens de DCAT standaard worden gedocumenteerd en gepubliceerd op data.overheid.nl.

3.1.1 Eigenschappen

In de onderstaande tabel worden de eigenschappen van de dcat:Dataset beschreven.

Eigenschap Kardinaliteit Aanwezigheid Herkomst
identifier 1..1 Mandatory Resource
title 1..n Mandatory Resource
description 1..n Mandatory Resource
license 1..1 Mandatory Resource
creator nieuw 1..1 Mandatory Resource
publisher 1..1 Mandatory Resource
contact point 1..1 Mandatory Resource
theme/category 1..n Mandatory Resource
access-rights 0..1 Recommended Resource
keyword/tag 0..n Recommended Resource
release date 0..1 Recommended Resource
update/modification date 0..1 Recommended Resource
resource language 0..n Recommended Resource
landing page 0..1 Optional Resource
other identifier 0..n Optional Resource
conforms to nieuw 0..n Optional Resource
legal foundation 0..n Optional Resource
rights 0..n Optional Resource
qualified-attribution nieuw 0..n Optional Resource
distribution 0..n Recommended Dataset
frequency 0..1 Recommended Dataset
spatial/geographical coverage 0..n Optional Dataset
temporal coverage 0..1 Optional Dataset
3.1.1.1 distribution

De distributie van de dataset, waarin de data-eigenaar beschrijft hoe de data in de dataset toegankelijk is gemaakt.

Definitie Waarde
RDF Eigenschap dcat:distribution
Bereik dcat:Distribution
Kardinaliteit 0..n
Gebruik Recommended
3.1.1.2 frequency

Een indicatie van de frequentie waarmee de dataset wordt ververst.

Definitie Waarde
RDF Eigenschap dct:accrualPeriodicity
Bereik waardelijst mdr:Frequency
Kardinaliteit 0..1
Gebruik Recommended
3.1.1.3 spatial/geographical coverage

Het geografische gebied waarop de gegevens in de dataset betrekking hebben. Het veld kan worden gevuld met de benaming van een gebied in de vorm van een URI of de coördinaten ervan.

Voor de invulling van deze eigenschap wordt vereist dat een van de onderstaande opties gekozen wordt:

Naam Type Gebruik
waardelijst overheid:Koninkrijksdeel Waardelijst Recommended
waardelijst overheid:Provincie Waardelijst Recommended
waardelijst overheid:Waterschap Waardelijst Recommended
waardelijst overheid:Gemeente Waardelijst Recommended
GeoNames.org Waardelijst Optional
overheid:EPSG28992 (standaarden.overheid.nl) Syntaxcodeerschema Optional
overheid:PostcodeHuisnummer (standaarden.overheid.nl) Syntaxcodeerschema Optional

De voorkeur gaat uit naar het gebruik van een van de genoemde OWMS4.0 waardelijsten. Het is echter zo dat deze lijsten niet altijd een oplossing bieden voor het duiden van een geografisch gebied. Voor die gevallen worden een drietal alternatieven aangeboden.

Definitie Locatie
RDF Eigenschap dct:spatial
Bereik De naam of de coördinaten van een gebied.
Kardinaliteit 0..n
Gebruik Optional
Issue 3: Wat is het gewenste waardebereik voor dct:spatial in dataset? questionRespec

Deze kan een string literal zijn, zoals Gemeente Haarlem, maar ook een geografisch object.

3.1.1.4 temporal coverage

De tijdsperiode waar de dataset betrekking op heeft. Zie example-temporal-coverage voor een voorbeeld.

Definitie Waarde
RDF Eigenschap dct:temporal
Bereik dct:PeriodOfTime
Kardinaliteit 0..1
Gebruik Recommended

3.1.2 Niet overgenomen eigenschappen

De eigenschappen in de onderstaande tabel bestaan wel in de bovenliggende DCAT 2.0, DCAT-AP 2.1 en/of DCAT-AP-DONL 1.1 standaarden, maar worden niet overgenomen in dit profiel.

Eigenschap Herkomst
adms:sample DCAT
dcat:spatialResolutionInMeters DCAT
dcat:temporalResolution DCAT
dct:hasVersion DCAT-AP
dct:isVersionOf DCAT-AP
prov:wasGeneratedBy DCAT-AP
owl:versionInfo DCAT-AP
adms:versionNotes DCAT-AP
adms:status DCAT-AP
donl:authority DCAT-AP-DONL 1.1
donl:datasetStatus DCAT-AP-DONL 1.1
donl:metadataLanguage DCAT-AP-DONL 1.1
donl:datePlanned DCAT-AP-DONL 1.1
donl:sourceCatalog DCAT-AP-DONL 1.1

3.1.3 Voorbeelden

3.1.3.1 Minimale set van eigenschappen

Onderstaand voorbeeld beschrijft een dcat:Dataset met enkel de verplichte eigenschappen. Dit is de meest minimale representatie van een dcat:Dataset.

3.1.3.2 Niet publieke datasets

TODO: Access rights, licentie, vertaling, legal foundation.

3.1.3.3 Temporal coverage

3.2 Distributie (dcat:Distribution)

Een distributie beschrijft hoe een (deel van) een dataset te verkrijgen is. Meestal gaat het over een download-bestand. Verschillende distributies van dezelfde dataset verschillen van elkaar in o.a. taal, formaat, data-schema's en nauwkeurigheid (resolutie).

De aanbieder van een dataset kan distributies aanbieden in meerdere verschillende formaten en/of samenstellingen die zijn afgestemd op de behoeften van afnemers. Deze worden elk als afzonderlijke distributie beschreven en gerelateerd aan de dataset.

Als een dataset (ook) wordt aangeboden in de vorm van een webservice kunnen hierover aanvullende gegevens worden opgenomen in een dcat:DataService. Deze kan worden gerelateerd aan de bijbehorende distributie.

De distributie geeft aan dat er gegevens van een dataset beschikbaar zijn. Dat kan zijn via een directe download, een API of een webpagina. Een waarde in de eigenschap dcat:downloadURL geeft aan dat de gegevens in de distributie direct gedownload kunnen worden.

In het DCAT-AP-DONL 1.1 werden zowel de download-bestanden als de webservices om de data op te vragen, in de vorm van een distributie beschreven. Het nieuwe toepassingsprofiel biedt mogelijkheid om webservices te beschrijven in de klasse dcat:DataService. Deze heeft nu de voorkeur. Het blijft echter mogelijk en toegestaan om webservices te beschrijven als distributie.

3.2.1 Eigenschappen

In de onderstaande tabel worden de eigenschappen van de dcat:Distribution beschreven.

Eigenschap Kardinaliteit Aanwezigheid Herkomst
accessURL 1..1 Mandatory Distributie
format 1..1 Mandatory Distributie
title 1..n Mandatory Distributie
description 1..n Mandatory Distributie
license 1..1 Mandatory Distributie
access service nieuw 0..1 Recommended Distributie
download URL 0..1 Recommended Distributie
modified 0..1 Recommended Distributie
issued 0..1 Optional Distributie
language 0..n Optional Distributie
rights 0..n Optional Distributie
byteSize 0..1 Optional Distributie
conformsTo nieuw 0..n Optional Distributie
mediaType 0..1 Optional Distributie
checksum 0..1 Optional Distributie
documentation 0..n Optional Distributie
supportingRole 0..1 Optional Distributie
3.2.1.1 accessURL

Het web-adres (URL) van de site die toegang verschaft tot de data, aan de hand van bijvoorbeeld een webformulier, een zoekopdracht of een API-call. Het is niet vereist dat dit adres een directe link naar de data is. Hier mag ook verwezen worden naar een landings-pagina die de link naar de data aanbiedt. Er kan in dat geval met dcat:downloadURL een directe link naar de data aangeboden worden.

Wanneer de data via een dcat:DataService wordt aangeboden, dan staat in deze eigenschap de volledige API-call waarmee de data uit de service gehaald kan worden. Met dcat:accessService wordt dan de link gemaakt met de dcat:DataService.

Definitie Waarde
RDF Eigenschap dcat:accessURL
Bereik xsd:anyURI
Kardinaliteit 1..1
Gebruik Mandatory
Noot
3.2.1.2 format

Informatie over het bestandsformaat van de distributie volgens de indeling van het publicatiebureau van de EU.

Het bestandsformaat kan ook worden opgegeven in dct:MediaType, maar voor data.overheid.nl is dct:format lijdend. Het verschil tussen deze twee zit voornamelijk in gebruikte waardelijsten. De W3C raadt het gebruik van dct:MediaType aan en de EU het gebruik van dct:format dus voor de beste vindbaarheid kan men het beste beide invullen.

Definitie Waarde
RDF Eigenschap dct:format
Bereik waardelijst mdr:Filetype
Kardinaliteit 1..1
Gebruik Mandatory
Issue 8: Verschil tussen dct:format en dcat:mediaType Respec

Distributie heeft eigenschappen dct:format en dcat:mediaType. Voor dcat:mediaType wordt verwezen naar de waardelijst van IANA, zie https://www.iana.org/

Is het nodig om beide eigenschappen op te nemen?

3.2.1.3 title

De titel is belangrijk voor de herkenbaarheid van een distributie, dus kies deze zorgvuldig. Zie meertaligheid** voor het omgaan met verschillende talen.

Definitie Waarde
RDF Eigenschap dct:title
Bereik rdfs:Literal
Kardinaliteit 1..n
Gebruik Mandatory

Zie ook dct:title van dcat:Resource.

3.2.1.4 description

Een beschrijving van de distributie in aanvulling op de titel, waarmee eindgebruikers een goed beeld krijgen welke gegevens in de Distributie aanwezig zijn. Samen zijn deze het belangrijkste waarmee een gebruiker een distributie kan beoordelen, dus kies deze zorgvuldig. Zie meertaligheid voor het omgaan met verschillende talen.

Voor overige informatie over de Distributie is de eigenschap Documentation beschikbaar, waarin naar aanvullende webpagina's verwezen wordt.

Definitie Waarde
RDF Eigenschap dct:description
Bereik rdfs:Literal
Kardinaliteit 1..n
Gebruik Mandatory

Zie ook dct:description in dcat:Resource.

3.2.1.5 license

De formele of wettelijke toestemming waaronder de gegevens in de distributie gebruikt mogen worden.

Licenties kunnen complex zijn, wat de uitwerking en invulling van dit veld kan bemoeilijken. De licenties die van toepassing zijn op gegevensuitwisseling binnen de overheid zijn meestal vrij eenvoudig. Om die reden is gekozen voor een waardelijst die een aantal eenvoudige licenties bevat die met name naar de Creative Commons licenties verwijzen. Zie ook creativecommons.nl/uitleg/.

Er kunnen ook licentiegegevens op het niveau van de dataset (dcat:Resource) worden vastgelegd. Die mogen niet in tegenspraak zijn met de licentiegegevens van de onderliggende dcat:Distributions.

Definitie Waarde
RDF Eigenschap dct:license
Bereik waardelijst donl:License
Kardinaliteit 1..1
Gebruik Mandatory

Zie ook dct:license in dcat:Resource.

Issue 22: Invullen van dct:license en dct:rights Respec

dct:license en dct:rights zijn te vinden in resource én in dataservice. Wanneer moet je nu welke eigenschap invullen?

3.2.1.6 accessService nieuw

Alleen van toepassing wanneer de distributie via een dataservice bereikbaar is. De dataservice biedt dan toegang tot het bestand of de bestanden van deze distributie. Access service wordt niet ingevuld als de toegang tot de distributie. Dit kan in dcat:accessURL

Deze eigenschap is nieuw in DCAT2 en biedt aanbieders van datasets de mogelijkheid om extra informatie te verstrekken over datasets die via een dataservice worden aangeboden.

Definitie Waarde
RDF Eigenschap dcat:accessService
Bereik dcat:DataService
Kardinaliteit 0..1
Gebruik Recommended
3.2.1.7 downloadURL

De URL waarmee eindgebruikers het bestand direct kunnen downloaden in een van de beschikbare formaten. Dit formaat wordt aangegeven in de distributie in eigenschap dct:format en/of dcat:mediaType.

Wanneer dcat:accessURL al de directe link naar de data aanbiedt, hoeft deze eigenschap niet ingevuld te worden.

Definitie Waarde
RDF Eigenschap dcat:downloadURL
Bereik xsd:anyURI
Kardinaliteit 0..1
Gebruik Recommended
3.2.1.8 modified

De datum waarop de data-eigenaar de distributie voor het laatst heeft gewijzigd. Dat geldt zowel voor een wijziging van de inhoud van de distributie als voor de metadata van de distributie. Deze eigenschap moet een datum en tijd bevatten conform de ISO-8601 standaard.

Bij de eerstvolgende wijziging wordt de oude wijzigingsdatum overschreven.

Als de gegevens automatisch periodiek worden aangepast hoeft deze waarde niet telkens gewijzigd te worden. Gebruikers kunnen dan uitgaan van de waarde van dct:accrualPeriodicity die in de bovenliggende dcat:Dataset is opgenomen.

Definitie Waarde
RDF Eigenschap dct:modified
Bereik xsd:dateTime
Kardinaliteit 0..1
Gebruik Recommended

Zie ook dct:modified in dcat:Resource.

Issue 4: Property: update/modification date in Distributie: Verplicht of Aanbevolen? questionRespec

Het "update/modification date" veld is belangrijk om de kwaliteit van de aangeboden distributie te kunnen inschatten: Een oude dataset heeft minder waarde dan een nieuwere. Ook kan deze eigenschap niet worden afgeleid.
Dus het lijkt passend om op zijn minst deze property "aanbevolen" te maken.
Maar zijn er bezwaren om de property verplicht te maken? Zou dat leiden tot uitvak van datasets? Uitval lijkt op te lossen met een beschrijving hoe het veld in te vullen als de distributie er geen waarde voor heeft.

3.2.1.9 issued

De datum waarop de data-eigenaar de distributie voor de eerste keer heeft gepubliceerd. Deze eigenschap moet een datum en tijd bevatten conform de ISO-8601 standaard.

Als tijd niet bekend is, kan hier de tijd 00:00:00 worden ingevuld. Wanneer er geen tijdzone wordt opgegeven wordt er automatisch uitgegaan van de Nederlandse tijd.

Definitie Waarde
RDF Eigenschap dct:issued
Bereik xsd:dateTime
Kardinaliteit 0..1
Gebruik Optional

Zie ook dct:issued in dcat:Resource.

3.2.1.10 language

De natuurlijke taal van de gegevens in de distributie.

Niet alle data die aangeboden wordt is taalgebonden (denk aan cijfers, statistieken etc.), om deze reden is deze eigenschap optioneel. Zie meertaligheid voor het omgaan met verschillende talen.

Definitie Waarde
RDF Eigenschap dct:language
Bereik waardelijst donl:Language
Kardinaliteit 0..n
Gebruik Optional

Zie ook dct:language in dcat:Resource.

Issue 11: Verschillende talen Respec

De W3C maakt het mogelijk om de metadata zoals titel en beschrijving vast te leggen in verschillende talen. Op data.overheid.nl is nu maximaal een taal mogelijk.

Daarnaast is het mogelijk om de taal aan te geven van de dataset zelf.

De EU biedt ook de mogelijkheid om daarnaast ook apart de taal van de distributie aan te geven.

Wat is hier precies gewenst?

3.2.1.11 rights

De overige gebruiksrechten die niet worden gedekt met dct:license, zoals de copyright-statements. Deze eigenschap kan bijvoorbeeld gebruikt worden om aan te geven hoe de attributie moet plaatsvinden wanneer bij dct:license een CC-BY licentie is gekozen.

Voor iedere taal kan één aparte rights-statement worden opgenomen die wordt aangeduid door een "language tag" achter de literal te plaatsen. Zie meertaligheid voor het verder omgaan met verschillende talen.

Definitie Waarde
RDF Eigenschap dct:rights
Bereik rdfs:Literal
Kardinaliteit 0..n
Gebruik Optional

Zie ook dct:rights in dcat:Resource.

3.2.1.12 byteSize

De omvang van de distributie (het feitelijke bestand) in bytes. Deze eigenschap is alleen relevant wanneer de grootte van het bestand bekend is. Wanneer het bijvoorbeeld om realtime (of near-realtime) data gaat, die dus op elk moment kan veranderen, dan is de grootte minder goed te voorspellen. In dat geval is het aan te bevelen om deze eigenschap niet in te vullen.

Uiteraard is een negatieve omvang niet mogelijk. De waarde moet dus 0 of hoger zijn.

Definitie Waarde
RDF Eigenschap dcat:byteSize
Bereik xsd:decimal
Kardinaliteit 0..1
Gebruik Optional
3.2.1.13 conformsTo nieuw

Een vastgestelde standaard waaraan de data in de distributie voldoet. Deze property kan meerdere keren voorkomen. Wanneer een andere eigenschap al beschrijft dat er aan een standaard wordt voldaan, dan hoeft deze niet nog een keer opgenomen te worden in deze eigenschap (bijvoorbeeld de bestandsformaat-standaard wordt al gedekt via dct:format).

De gebruikte standaard kan heel divers zijn en verschillen per context. Denk bijvoorbeeld aan een standaard die beschrijft hoe de gegevens in de dataset zijn verzameld. Of aan een standaard hoe de gegevens zijn gecodeerd, of hoe de gegevens in een model passen, of welke representatie of view deze gegevens van het geheel bevatten, et cetera.

Verwijs naar standaarden door middel van een HTTPS adres.

Definitie Waarde
RDF Eigenschap dct:conformsTo
Bereik dct:Standard
Kardinaliteit 0..n
Gebruik Recommended
Noot

Zie ook dct:conformsTo in dcat:Resource.

3.2.1.14 mediaType

Informatie over de bestandsindeling (of MIME-type) van de distributie, volgens de indeling van IANA Mediatypes.

Definitie Waarde
RDF Eigenschap dcat:mediaType
Bereik waardelijst iana:Mediatypes
Kardinaliteit 0..1
Gebruik Optional
Issue 8: Verschil tussen dct:format en dcat:mediaType Respec

Distributie heeft eigenschappen dct:format en dcat:mediaType. Voor dcat:mediaType wordt verwezen naar de waardelijst van IANA, zie https://www.iana.org/

Is het nodig om beide eigenschappen op te nemen?

3.2.1.15 checksum

Met een checksum of controlegetal kan een afnemer eenvoudig vaststellen of een gedownload bestand identiek is aan het aangeboden bestand (en er dus geen problemen zijn ontstaan bij het downloaden of wijzigingen zijn geweest aan de data zelf).

De spdx:Checksum klasse bevat naast de berekende checksum-waarde ook een eigenschap die het gebruikte algoritme aangeeft. Hiervoor is een waardelijst opgezet.

Definitie Waarde
RDF Eigenschap spdx:checksum
Bereik spdx:Checksum
Kardinaliteit 0..1
Gebruik Optional

Het invullen van de klasse spdx:Checksum kan op de volgende manier. Voor een voorbeeld zie voorbeeld checksum.

URI Range Kardinaliteit
spdx:algorithm waardelijst spdx:ChecksumAlgorithm 1..1
spdx:checksumValue rdfs:Literal typed as xsd:hexBinary 1..1
Issue 10: checksum

Openstaande vraag: hoe ziet de vulling van checksum er precies uit? Ik zou verwachten dat behalve de waarde van de checksum ook het gebruikte hash-alogoritme om de waarde mee te berekenen wordt meegestuurd.

3.2.1.16 documentation

Een informatiepagina waar aanvullende informatie over deze distributie te vinden is.

Merk op dat eigenschap dct:description gebruikt kan worden om de betreffende distributie te beschrijven. Deze tekst wordt afgebeeld bij de distributie op data.overheid.nl. De eigenschap documentation verwijst met een hyperlink naar de webpagina die ook een beschrijving geeft van de distributie, mogelijk aangevuld met extra informatie die niet wordt opgenomen in dct:description. Denk aan hoe de gegevens geïnterpreteerd moeten worden, een beschrijving van het formaat van de gegevens of hoe de gegevens verkregen kunnen worden.

Een aantal data-eigenaren kiest ervoor om de documentatie als op zichzelf staande distributie toe te voegen aan de dataset. In die gevallen hoeft deze eigenschap niet ingevuld te worden. Vul in dat geval wel supportingRole in.

Definitie Waarde
RDF Eigenschap foaf:page
Bereik xsd:anyURI
Kardinaliteit 0..n
Gebruik Optional
Noot
3.2.1.17 supportingRole

Met deze eigenschap kan aangegeven worden wat voor ondersteunende rol deze distributie heeft als onderdeel van de dataset. Een distributie kan bijvoorbeeld als documentatie dienen van de dataset, terwijl een andere distributie de daadwerkelijke data aanbiedt. In dat geval kan de "documentatie" distributie een donl:supportingRole eigenschap opnemen om deze verhouding te duiden.

Definitie Waarde
RDF Eigenschap donl:supportingRole
Bereik waardelijst donl:SupportingRole
Kardinaliteit 0..1
Gebruik Optional
Issue 12: Wat te doen met `distribution type` in Distribution?

Deze lijkt achterhaald. Klopt dat?

3.2.2 Niet overgenomen eigenschappen

De eigenschappen in de onderstaande tabel bestaan wel in de bovenliggende DCAT 2.0, DCAT-AP 2.1 en/of DCAT-AP-DONL 1.1 standaarden, maar worden niet overgenomen in dit profiel.

Eigenschap Herkomst
dcat:packageFormat DCAT
dcat:compressFormat DCAT
dcatap:availability DCAT-AP

3.2.3 Voorbeelden

3.2.3.1 Minimale set van eigenschappen

Onderstaand voorbeeld beschrijft een dcat:Distribution met enkel de verplichte eigenschappen. Dit is de meest minimale representatie van een dcat:Distribution.

3.2.3.2 Distributie van een collectie van bestanden
3.2.3.3 Documentatie als op zichzelf staande distributie

TODO: Supportring Role

3.2.3.4 Checksum

3.3 Dataservice (dcat:DataService) nieuw

Subklasse van dcat:Resource

Een gegevensdienst of DataService is een computer service waar gegevens opgevraagd worden aan de hand van specificaties in een aanvraag. De gegevens die voldoen aan de meegegeven specificatie worden als antwoord teruggestuurd. Webservices zoals REST/JSON, WMS of XML interfaces zijn voorbeelden van dcat:DataService. Merk op dat als de specificatie slechts een deel van de gegevens beschrijft, alleen desbetreffende subset wordt opgestuurd. Ook is het mogelijk dat een dataservice niet één, maar meerdere datasets ontsluit.

Dataservice zijn speciaal bedoeld voor geautomatiseerde koppelingen tussen systemen, hoewel ze ook door - meestal technisch onderlegde - mensen gebruikt kunnen worden.

De DataService klasse is geïntroduceerd in versie 2 van DCAT. Het biedt uitgebreidere mogelijkheden om geautomatiseerde toegang tot gegevens te beschrijven dan mogelijk is in de klasse dcat:Distributie. In deze nieuwe versie van het toepassingsprofiel is de DataService klasse optioneel. Dat betekent dat het mogelijk blijft om dataservices te beschrijven met de klasse Distributie.

3.3.1 Eigenschappen

In de onderstaande tabel worden de eigenschappen van de dcat:DataService beschreven.

Eigenschap Kardinaliteit Aanwezigheid Herkomst
identifier 1..1 Mandatory Resource
title 1..n Mandatory Resource
description 1..n Mandatory Resource
license 1..1 Mandatory Resource
creator nieuw 1..1 Mandatory Resource
publisher 1..1 Mandatory Resource
contact point 1..1 Mandatory Resource
theme/category 1..n Mandatory Resource
access-rights 0..1 Recommended Resource
keyword/tag 0..n Recommended Resource
release date 0..1 Recommended Resource
update/modification date 0..1 Recommended Resource
resource language 0..n Recommended Resource
landing page 0..1 Optional Resource
other identifier 0..n Optional Resource
conforms to nieuw 0..n Optional Resource
legal foundation 0..n Optional Resource
rights 0..n Optional Resource
qualified-attribution nieuw 0..n Optional Resource
endpoint URL nieuw 1..1 Mandatory Dataservice
endpoint description nieuw 1..1 Mandatory Dataservice
serves dataset nieuw 0..n Recommended Dataservice
3.3.1.1 endpoint URL nieuw

De locatie of het endpoint van de service (over het algemeen een via HTTP raadpleegbaar adres).

Definitie Waarde
RDF Eigenschap dcat:endpointURL
Bereik rdfs:Resource
Kardinaliteit 1..1
Gebruik Mandatory
3.3.1.2 endpoint description nieuw

Een verwijzing naar de documentatie die de DataService beschrijft. Denk hierbij aan een verwijzing naar een Open Api Specification (Swagger), een OGC:WFS of OGC:WMS getCapabilities aanroep, een SPARQL Service Description en dergelijke.

Een gebruiker is gebaat bij een accurate en volledige beschrijving van de aangeboden service.

Definitie Waarde
RDF Eigenschap dcat:endpointDescription
Bereik rdfs:Resource
Kardinaliteit 1..1
Gebruik Mandatory
Noot
3.3.1.3 serves dataset nieuw

Een dataset die via deze dcat:DataService aangeboden wordt. Een dataservice kan nul, een of meer datasets aanbieden.

Definitie Waarde
RDF Eigenschap dcat:servesDataset
Bereik dcat:Dataset
Kardinaliteit 0..n
Gebruik Recommended

3.3.2 Voorbeelden

Naast de onderstaande voorbeelden, biedt het W3C enkele voorbeelden aan van hoe een dcat:DataService eruit ziet op www.w3.org/TR/vocab-dcat-2/#examples-data-service.

3.3.2.1 Minimale set van eigenschappen

Onderstaand voorbeeld beschrijft een dcat:DataService met enkel de verplichte eigenschappen. Dit is de meest minimale representatie van een dcat:DataService.

3.3.2.2 Een DataService die Datasets ontsluit

De gemeente Nijmegen heeft een publiek beschikbare OGC:WMS webservice waarmee de gemeente gemaakte luchtfoto's aanbiedt. Een van de aangeboden luchtfoto's is de "Luchtfoto 2022" (De gemeente maakt jaarlijks luchtfoto's). Deze luchtfoto's kunnen individueel (of als bundel) als dataset aangeboden worden. De behoefte bestaat om de relaties tussen de dataset en de webservice duidelijk vast te leggen.

Dit voorbeeld uit zich in de volgende RDF (niet relevante eigenschappen zijn weggelaten):

We zien hier de dataset https://opendata.nijmegen.nl/dataset/luchtfoto-2022 met een tweetal distributies. In de eigenschappen van de distributies is de relatie opgenomen via welke dataservice ze ontsloten worden. Daarnaast zien we de dataservice https://services.nijmegen.nl/geoservices/wms/extern_Luchtfoto. In de eigenschappen van deze dataservice is opgenomen dat deze de https://opendata.nijmegen.nl/dataset/luchtfoto-2022 dataset ontsluit.

3.4 Resource (dcat:Resource)

In de klasses dcat:Dataset, dcat:DataService en dcat:Catalog worden veel dezelfde eigenschappen gebruikt. Om niet al deze eigenschappen voor elke klasse opnieuw te hoeven definiëren is de superklasse dcat:Resource geïntroduceerd. Deze superklasse beschrijft deze gedeelde eigenschappen op één plaats, wat de specificatie van DCAT overzichtelijker maakt.

In een DCAT beschrijving kan een dcat:Resource niet voorkomen, alleen de hierboven genoemde, afgeleide klasses zijn toegestaan net als natuurlijk niet van Resource afgeleide klasses uit dit DCAT profiel.

3.4.1 Eigenschappen

In de onderstaande hoofdstukken worden de eigenschappen van de dcat:Resource beschreven.

3.4.1.1 identifier

De identifier van de resource volgens de eigenaar van de data. Dit is bij voorkeur URI die via HTTP raadpleegbaar is. Hier wordt de oorspronkelijke identificatie van de resource (dataset, dataservice of catalogus) genomen zoals de data-eigenaar deze gepubliceerd heeft.

Afgezien van deze identifier kan de betreffende dataset, dataservice of catalogus - in de loop van de tijd - ook andere identifiers krijgen. Deze worden overgenomen in adms:identifier. Een resource kan meerdere voorkomens van adms:identifier hebben.

Definitie Waarde
RDF Eigenschap dct:identifier
Bereik xsd:anyURI
Kardinaliteit 1..1
Gebruik Mandatory
3.4.1.2 title

De naam van de beschreven resource. Op data.overheid.nl wordt deze naam geïndexeerd, zodat eindgebruikers de desbetreffende dataset, dataservice of catalogus kunnen terugvinden op basis van één of meer woorden in de naam.

Een handige vuistregel is om de lengte van de titel te beperken tot ca. 100 tekens. Wanneer de behoefte bestaat om in meer tekens de dataset te beschrijven, dan kan dct:description gebruikt worden.

Zie meertaligheid voor het omgaan met verschillende talen.

Definitie Waarde
RDF Eigenschap dct:title
Bereik rdfs:literal
Kardinaliteit 1..n
Gebruik Mandatory
3.4.1.3 description

Een beschrijving de resource. data.overheid.nl toont de beschrijvende tekst bij de desbetreffende resource en gebruikt deze voor het opbouwen van de zoekindex. Dit betekent dus dat de vindbaarheid van de resource wordt bepaald door de kwaliteit van de tekst. Om ervoor te zorgen dat eindgebruikers de datasets goed kunnen vinden is het belangrijk dat de tekst goede trefwoorden bevat.

Zie meertaligheid voor het omgaan met verschillende talen.

Definitie Waarde
RDF Eigenschap dct:description
Bereik rdfs:literal
Kardinaliteit 1..n
Gebruik Mandatory
3.4.1.4 license

De formele of wettelijke toestemming waaronder de gegevens in de dataset gebruikt mogen worden.

Licenties kunnen complex zijn, wat de uitwerking en invulling van dit veld kan bemoeilijken. De licenties die van toepassing zijn op gegevensuitwisseling binnen de overheid zijn meestal vrij eenvoudig. Om die reden is gekozen voor een waardelijst die een aantal eenvoudige licenties bevat die met name naar de Creative Commons licenties verwezen. Zie ook creativecommons.nl/uitleg/.

Er kunnen ook licentiegegevens op het niveau van de dcat:Distribution worden vastgelegd. Die mogen niet in tegenspraak zijn met de licentiegegevens van de dcat:Dataset.

Definitie Waarde
RDF Eigenschap dct:license
Bereik waardelijst donl:License
Kardinaliteit 1..1
Gebruik Mandatory
Issue 22: Invullen van dct:license en dct:rights Respec

dct:license en dct:rights zijn te vinden in resource én in dataservice. Wanneer moet je nu welke eigenschap invullen?

3.4.1.5 creator nieuw

De organisatie die verantwoordelijk is voor het creëren van de beschreven bron. Zie eigenschappen dct:publisher en prov:qualifiedAttribution voor andere rollen.

Voor de invulling van deze eigenschap wordt vereist dat een concept uit een van de onderstaande waardelijsten gekozen wordt:

Naam Type Gebruik
waardelijst overheid:Organisatie Waardelijst Recommended
waardelijst donl:RelevantOrganization Waardelijst Optional

Hoewel de meeste overheidsorganisaties opgenomen zijn in de overheid:Organisatie waardelijst, zijn er twee argumenten om naast deze lijst nog een 'eigen' lijst te hanteren voor het invullen van het dct:creator eigenschap.

  1. Niet alle overheidsorganisaties zijn opgenomen in OWMS 4.0. Er moet dus een antwoord zijn voor (overheids)organisaties die niet in de OWMS taxonomie opgenomen zijn.
  2. Hoewel data.overheid.nl primair een register van overheidsdata is, neemt het ook maatschappelijk relevante data op in het register van private partijen. Om te kunnen verwijzen naar deze private partijen moet tenminste een van de waardelijsten deze mogelijkheid bieden.

Het heeft de voorkeur dat de OWMS 4.0 lijst gebruikt wordt voor het invullen van deze eigenschap. Wanneer deze lijst echter niet toereikend is, kan er gebruik gemaakt worden van de donl:RelevantOrganization taxonomie.

Staat uw organisatie in geen van beide lijsten? Neem dan contact op met data.overheid.nl. Het team van data.overheid.nl zal beoordelen of uw organisatie alsnog opgenomen kan worden in de donl:RelevantOrganization taxonomie.

Definitie Waarde
RDF Eigenschap dct:creator
Bereik De organisatie die verantwoordelijk is voor het creëren van de beschreven bron
Kardinaliteit 1..1
Gebruik Mandatory
Noot
Issue 23: Begrippenkader formuleren van eigenaar, verantwoordelijke, bronhouder, uitgever etc. Respec

Welke organisatie past in welk veld?

3.4.1.6 publisher

De organisatie die verantwoordelijk is voor de uitgifte/publicatie van de bron. Zie eigenschappen dct:creator en prov:qualifiedAttribution voor andere rollen.

Voor de invulling van deze eigenschap wordt vereist dat een concept uit een van de onderstaande waardelijsten gekozen wordt:

Naam Type Gebruik
waardelijst overheid:Organisatie Waardelijst Recommended
waardelijst donl:RelevantOrganization Waardelijst Optional

Hoewel de meeste overheidsorganisaties opgenomen zijn in de overheid:Organisatie waardelijst, zijn er twee argumenten om naast deze lijst nog een 'eigen' lijst te hanteren voor het invullen van het dct:creator eigenschap.

  1. Niet alle overheidsorganisaties zijn opgenomen in OWMS 4.0. Er moet dus een antwoord zijn voor (overheids)organisaties die niet in de OWMS taxonomie opgenomen zijn.
  2. Hoewel data.overheid.nl primair een register van overheidsdata is, neemt het ook maatschappelijk relevante data op in het register van private partijen. Om te kunnen verwijzen naar deze private partijen moet tenminste een van de waardelijsten deze mogelijkheid bieden.

Het heeft de voorkeur dat de OWMS 4.0 lijst gebruikt wordt voor het invullen van deze eigenschap. Wanneer deze lijst echter niet toereikend is, kan er gebruik gemaakt worden van de donl:RelevantOrganization taxonomie.

Staat uw organisatie in geen van beide lijsten? Neem dan contact op met data.overheid.nl. Het team van data.overheid.nl zal beoordelen of uw organisatie alsnog opgenomen kan worden in de donl:RelevantOrganization taxonomie.

Definitie Waarde
RDF Eigenschap dct:publisher
Bereik De organisatie die verantwoordelijk is voor de uitgifte/publicatie van de beschreven bron
Kardinaliteit 1..1
Gebruik Mandatory
Issue 23: Begrippenkader formuleren van eigenaar, verantwoordelijke, bronhouder, uitgever etc. Respec

Welke organisatie past in welk veld?

3.4.1.7 contact point

Aan de hand van deze informatie kunnen eindgebruikers op data.overheid.nl contact opnemen met de eigenaar van de dataset of dataservice. Bij het invullen van deze eigenschap is het belangrijk om een algemeen mailadres te gebruiken. Het is niet de bedoeling om hier gegevens van individuele personen op te nemen.

Een geldig dcat:contactPoint bevat op zijn minst de eigenschap vcard:fn en een van de vcard:hasEmail, vcard:hasTelephone of vcard:hasURL eigenschappen. Voor een voorbeeld zie #Contact Point

Definitie Waarde
RDF Eigenschap dcat:contactPoint
Bereik vcard:Kind
Kardinaliteit 1..1
Gebruik Mandatory
Issue 38: Vullen van contactpoint

Hoe gaat het veld contactpoint in resource gevuld worden?

Het is mogelijk om voor dcat:contactPoint een waardelijst te creëeren waarin leveranciers staan tezamen met het mailadres (Vcard), maar het invullen kan ook door de gebruiker worden gedaan.

3.4.1.8 theme/category

Een thema uit de overheid:TaxonomieBeleidsagenda (standaarden.overheid.nl).

data.overheid.nl gebruikt dcat:theme om de datasets, dataservices en catalogi naar onderwerp in te delen. Door de eigenschap verplicht te stellen, kunnen eindgebruikers de betreffende resource altijd terugvinden wanneer zij via het thema zoeken of navigeren. De homepage toont standaard alle beschikbare thema's. De thema-indeling is hiërarchisch georganiseerd, zodat datasets ook aan meer specifieke subthema's kunnen worden gekoppeld, bijvoorbeeld subthema Waterschappen onder het thema Bestuur.

Definitie Waarde
RDF Eigenschap dcat:theme
Bereik waardelijst overheid:TaxonomieBeleidsagenda
Kardinaliteit 1..n
Gebruik Mandatory
Noot
Issue 35: Hoe verhouden Theme, Types en ConformsTo zich tot elkaar? Respec
3.4.1.9 keyword/tag

Vrije keywords of termen die de resource beschrijven.

Het gaat hier om vrije tekst, niet te verwarren met dcat:theme. Bij deze laatste eigenschap komen de termen uit een controlled vocabulary (of vastgesteld begrippenkader of waardelijst), en hebben een meer formele status.

Voor beide vormen geldt dat deze de vindbaarheid van de desbetreffende resource kunnen verbeteren. Het is dus mogelijk om meerdere keywords toe te kennen aan een resource. Deze waarden moeten in afzonderlijke voorkomens van deze eigenschap worden aangeleverd.

In principe bestaat een tag uit slechts één woord of een kleine combinatie van maximaal twee/drie woorden. Zie meertaligheid voor het omgaan met verschillende talen.

Definitie Trefwoord
RDF Eigenschap dcat:keyword
Bereik rdfs:Literal
Kardinaliteit 0..n
Gebruik Recommended
3.4.1.10 landing page

De webpagina die toegang geeft tot de resource (dataset, dataservice of catalogus) en aanvullende informatie verschaft over de resource. Het gaat hierbij om de originele webpagina van de data-eigenaar.

Definitie Waarde
RDF Eigenschap dcat:landingPage
Bereik xsd:anyURI
Kardinaliteit 0..1
Gebruik Optional
3.4.1.11 access rights

Met deze eigenschap wordt het openbaarheidsniveau van de resource aangegeven. DCAT-AP 2.1 schrijft de mdr:AccessRights (publications.europa.eu) waardelijst voor. Bij data.overheid.nl bestaat de behoefte om ook te beschrijven waarom een bron beperkt of niet beschikbaar is. Om deze reden is de donl:AccessRights geïntroduceerd. Deze lijst bevat concepten die de openbaarheid van een bron beschrijven en wat de reden is, wanneer de openbaarheid niet publiek is.

Definitie Waarde
RDF Eigenschap dct:accessRights
Bereik waardelijst donl:AccessRights
Kardinaliteit 0..1
Gebruik Recommended
Issue 28: Hoe ziet onze taxonomie voor dct:accessRights eruit?
3.4.1.12 resource language

De natuurlijke taal van de data in de resource. Zie meertaligheid voor het omgaan met verschillende talen.

Definitie Waarde
RDF Eigenschap dct:language
Bereik waardelijst donl:Language
Kardinaliteit 0..n
Gebruik Recommended
Issue 11: Verschillende talen Respec

De W3C maakt het mogelijk om de metadata zoals titel en beschrijving vast te leggen in verschillende talen. Op data.overheid.nl is nu maximaal een taal mogelijk.

Daarnaast is het mogelijk om de taal aan te geven van de dataset zelf.

De EU biedt ook de mogelijkheid om daarnaast ook apart de taal van de distributie aan te geven.

Wat is hier precies gewenst?

Noot
3.4.1.13 other identifier

De verplichte eigenschap dct:identifier bevat de unieke identificatie van de dataset die de data-eigenaar heeft uitgegeven. Deze eigenschap bevat evt. andere unieke identifiers van de dataset zoals gegeven door catalogi als data.overheid.nl of andere partijen. Wanneer men voor de dataset van een ander een eigen identifier gebruiken wil, wordt aangeraden dit te doen door middel van other identifier.

In de adms:identifier wordt de identifier benoemd in skos:notation en de uitgever van de identifier in dct:creator.

Voor een voorbeeld zie #Other identifier

Definitie Waarde
RDF Eigenschap adms:identifier
Bereik adms:Identifier
Kardinaliteit 0..n
Gebruik Optional
Issue 24: Gebruik ID's

Dit wordt nog besproken binnen Europa

3.4.1.14 conforms to nieuw

De vastgestelde standaard waaraan de data van de beschreven resource voldoet. Hierbij kan worden gedacht aan het model, schema, ontology, view of profiel. Het opnemen van bestandsformaten is belangrijker in het veld dct:format en dct:mediaType van de distributies, dan in dct:conformsTo.

Definitie Waarde
RDF Eigenschap dct:conformsTo
Bereik dct:Standard
Kardinaliteit 0..n
Gebruik Optional
Issue 35: Hoe verhouden Theme, Types en ConformsTo zich tot elkaar? Respec
Issue 14: dct:conformsTo in dcat:Resource Respec

Het is niet helemaal duidelijk wat hier moet worden ingevuld in een specifieke resource zijnde een dcat:Dataset, dcat:DataService of dcat:Catalog.

Volgens W3C is het bereik dct:Standard.

3.4.1.16 release date

De datum waarop de beschreven resource is gepubliceerd.

data.overheid.nl registreert hier de eerste (vroegste) publicatiedatum waarop de data-leverancier deze dataset, dataservice of catalogus heeft gepubliceerd. Het gaat hier dus niet om de publicatiedatum van de metadata. Ook niet over de wijzigingsdatum van de dataset, dataservice of catalogus, hiervoor is de dct:modified eigenschap.

Definitie Waarde
RDF Eigenschap dct:issued
Bereik xsd:dateTime
Kardinaliteit 0..1
Gebruik Recommended
Noot
3.4.1.17 update/modification date

De datum waarop de beschreven resource is gewijzigd.

Het gaat hierbij om de meest recente datum waarop de dataset, dataservice of catalogus is gewijzigd. Nieuwe versies overschrijven automatisch de oude versies.

Deze eigenschap is niet/minder waardevol wanneer de data continue, of volgens een vast schema, veranderd. In dat geval kan beter dct:accrualPeriodicity gebruikt worden.

Definitie Waarde
RDF Eigenschap dct:modified
Bereik xsd:dateTime
Kardinaliteit 0..1
Gebruik Recommended
Noot
3.4.1.18 rights

De overige gebruiksrechten die niet worden gedekt met dct:license, zoals de copyright-statements. Deze eigenschap kan bijvoorbeeld gebruikt worden om aan te geven hoe de attributie moet plaatsvinden wanneer bij dct:license een CC-BY licentie is gekozen.

Zie meertaligheid voor het omgaan met verschillende talen.

Definitie Waarde
RDF Eigenschap dct:rights
Bereik rdfs:Literal
Kardinaliteit 0..n
Gebruik Optional
Issue 22: Invullen van dct:license en dct:rights Respec

dct:license en dct:rights zijn te vinden in resource én in dataservice. Wanneer moet je nu welke eigenschap invullen?

3.4.1.19 qualified attribution nieuw

Een organisatie, anders dan de dct:creator of dct:publisher die ook een verantwoordelijkheid draagt voor de resource.

In het bereik prov:Attribution wordt in de eigenschap prov:hadRole de rol van de organisatie benoemd. Hier kan worden gekozen uit de ISO-waardelijst ISO-19115 RoleCode.

In prov:agent wordt de naam van de organisatie opgenomen. Omdat dit niet altijd overheidsorganisaties zullen zijn hoeft deze waarde niet uit een de organisatie waardelijsten (owms:Organisatie en/of donl:RelevantOrganization) te komen.

Definitie Waarde
RDF Eigenschap prov:qualifiedAttribution
Bereik prov:Attribution
Kardinaliteit 0..n
Gebruik Optional
Issue 31: Voorstel voor een AgentRole taxonomie

Voorstel maken voor hoe de AgentRole taxonomie vorm zou kunnen krijgen.

Issue 23: Begrippenkader formuleren van eigenaar, verantwoordelijke, bronhouder, uitgever etc. Respec

Welke organisatie past in welk veld?

Issue 25: Voorbeeld voor qualified_attribution

Volgens de specificatie wordt deze eigenschap als volgt gedefinieerd:
Deze eigenschap verwijst naar een persoon of organisatie, anders dan contact point, resource creator of publisher die ook een verantwoordelijkheid draagt voor de resource.
Maar wat zijn voorbeelden hiervan, deze toevoegen aan de specificatie.

3.4.2 Niet overgenomen eigenschappen

De eigenschappen in de onderstaande tabel bestaan wel in de bovenliggende DCAT 2.0, DCAT-AP 2.1 en/of DCAT-AP-DONL 1.1 standaarden, maar worden niet overgenomen in dit profiel.

Eigenschap Herkomst
dct:relation DCAT
dct:isReferencedBy DCAT
dcat:qualifiedRelation DCAT
odrl:hasPolicy DCAT
dct:type DCAT-AP

3.4.3 Voorbeelden

3.4.3.1 Contact point
3.4.3.2 Other identifier
3.4.3.3 Qualified attribution

TODO: Syntax en inhoud.

Voorbeeld overgenomen van W3C

Bevat een verwijzing naar een wettelijke grondslag conform de Juriconnect standaard.

3.5.1 Eigenschappen

In de onderstaande tabel worden de eigenschappen van de donl:LegalFoundation beschreven.

Eigenschap Kardinaliteit Aanwezigheid Herkomst
title 1..1 Mandatory Legal foundation
legal domain 1..1 Mandatory Legal foundation
juriconnect code 1..1 Mandatory Legal foundation
3.5.1.1 title

De naam van de wettelijke grondslag. Deze naam is uitsluitend bedoeld voor presentatie doeleinden. Het is geen vereiste dat hier de formele naam van de wet of van het wetsartikel wordt opgenomen. "Wet BAG" kan als titel fungeren, terwijl de formele titel "Wet basisregistratie adressen en gebouwen" zou zijn.

Definitie Waarde
RDF Eigenschap dct:title
Bereik rdfs:Literal
Kardinaliteit 1..1
Gebruik Mandatory
3.5.1.3 juriconnect code

De Juriconnect code die verwijst naar de daadwerkelijke wettelijke grondslag. wetten.overheid.nl ondersteund Juriconnect 1.3.

Definitie Waarde
RDF Eigenschap donl:juriconnectCode
Bereik rdfs:Literal
Kardinaliteit 1..1
Gebruik Mandatory

3.5.2 Voorbeelden

3.5.2.1 Minimale set van eigenschappen

Onderstaand voorbeeld beschrijft een donl:LegalFoundation met enkel de verplichte eigenschappen. Dit is de meest minimale representatie van een donl:LegalFoundation.

3.6 Catalogus (dcat:Catalog)

Noot

Subklasse van dcat:Dataset.

dcat:Catalog maakt het mogelijk om structuur aan te brengen in een DCAT beschrijving zonder de eigenschappen van de dcat:Resource te veranderen. Instanties van de klasses dcat:Dataset, dcat:DataService, dcat:CatalogRecord en dcat:Catalog zelf kunnen volgens eigen criteria verzameld worden in een overkoepelende dcat:Catalog. Naast het opdelen van complexe DCAT beschrijvingen in samenhangende delen, wordt ook het omgekeerde mogelijk: Verschillende beschrijvingen kunnen in één DCAT gecombineerd worden.

Het gebruik van de term 'catalogus' kan verwarring opleveren. In het Nederlands (resp. Engels) is een catalogus (resp. catalogue) een register of lijst waarin een verzameling voorwerpen of termen is opgenomen, vaak met een korte omschrijving of definitie en een aantal bijzonderheden. In de informatietechnologie worden diverse soorten catalogi opgesteld, zoals termenlijsten of taxonomieën. Een dcat:Catalog is een verzameling dcat klasses, dus een verzameling van dcat:Datasets, dcat:Distributies of andere catalogi. Een dcat:catalogus is niet geschikt om de meer algemene rol van een catalogus te vervullen. DCAT kan wel gebruikt worden om een dergelijke catalogus (en het ontsluiten ervan) te beschrijven met dcat:Dataset, dcat:Distribution en dcat:DataService.

In grote datacatalogi als data.overheid.nl of data.europa.eu wordt DCAT
informatie van een groot aantal datasets en aanbieders verzameld. Een dcat:catalogus kan dan bijvoorbeeld worden gebruikt om de datasets van één aanbieder te groeperen. Een voorbeeld hiervan is: alle data van de gemeente Arnhem. dcat:Catalogue stelt geen eisen aan de indeling van een DCAT beschrijving, dus ook andere catalogs zijn mogelijk zoals de meest populaire data van het jaar.

Het laatste voorbeeld is de catalogus op basis van een gedeeld onderwerp. Hiermee kunnen gegevens waarvan door de aanbieders niet met behulp van een dcat:theme, dcat:keyword, dct:conformsTo of op een andere wijze is aangegeven dat ze een bepaald onderwerp betreffen, toch in een catalog over dat onderwerp worden opgenomen, zonder dat de oorspronkelijk aangeleverde gegevens gewijzigd hoeven te worden. Met de juiste attributen kan deze catalog zelf worden voorzien van de juiste thema's, keywords etc. Een voorbeeld hiervan zou een catalog kunnen zijn waarmee de impact van de Corona pandemie zichtbaar wordt. Toen de pandemie uitbrak waren er vanzelfsprekend geen DCAT beschrijvingen waarin COVID was opgenomen. Een COVID catalogus zou gegevens kunnen bevatten met medische data en sterftecijfers, maar economische of sociale data. Eventueel kan met de hand of op basis van meerdere filters een Corona catalogus aangemaakt.

Issue 21: Wat is een catalogus in DCAT nu precies

Er lijkt onduidelijkheid te zijn rondom de definitie van dcat:Catalog. Wat is het precies en wanneer wordt het gebruikt?

3.6.1 Eigenschappen

De onderstaande tabel geeft een overzicht van de herkomst en de toepassing van alle eigenschappen in deze klasse. Hierbij wordt ook aangegeven hoe het Europese toepassingsprofiel (DCAT-AP-EU) gebruik maakt van de eigenschap. Eigenschappen zonder waarde zijn/worden niet overgenomen in het toepassingsprofiel.

Eigenschap Kardinaliteit Aanwezigheid Herkomst
identifier 1..1 Mandatory Resource
title 1..n Mandatory Resource
description 1..n Mandatory Resource
license 1..1 Mandatory Resource
creator nieuw 1..1 Mandatory Resource
publisher 1..1 Mandatory Resource
contact point 1..1 Mandatory Resource
theme/category 1..n Mandatory Resource
access-rights 0..1 Recommended Resource
keyword/tag 0..n Recommended Resource
release date 0..1 Recommended Resource
update/modification date 0..1 Recommended Resource
resource language 0..n Recommended Resource
landing page 0..1 Optional Resource
other identifier 0..n Optional Resource
conforms to nieuw 0..n Optional Resource
legal foundation 0..n Optional Resource
rights 0..n Optional Resource
qualified-attribution nieuw 0..n Optional Resource
distribution 0..n Recommended Dataset
frequency 0..1 Recommended Dataset
spatial/geographical coverage 0..n Optional Dataset
temporal coverage 0..1 Optional Dataset
homepage 1..1 Mandatory Catalogus
dataset 0..n Recommended Catalogus
service nieuw 0..n Recommended Catalogus
catalog nieuw 0..n Recommended Catalogus
themes 0..1 Optional Catalogus
3.6.1.1 homepage

De homepage van de catalogus. Een catalogus kan op meerdere dataportals worden gepubliceerd. Deze eigenschap verwijst naar de originele homepage. Dat is in de regel de homepage van de maker van de catalogus.

Let op, dit is dus iets anders dan dcat:landingPage.

Definitie Waarde
RDF Eigenschap foaf:homepage
Bereik xsd:anyURI
Kardinaliteit 1..1
Gebruik Mandatory
3.6.1.2 dataset

De (metadata van de) dataset(s) die is/zijn opgenomen in de catalogus.

Het lijkt logisch dat een catalogus tenminste één dataset bevat, omdat een catalogus op zich niet zo interessant is. Desondanks geven we hier de cardinaliteit 0..n, omdat een catalogus ook als resource in een andere catalogus kan voorkomen zonder verdere inhoud. In dat geval verwijst de catalogus door naar de homepage op een ander dataportaal die de inhoud wel toont. Een ander voorbeeld is een catalogus die alleen dataservices ontsluit.

Zie ook de discussie op github.com/SEMICeu/DCAT-AP/issues/180.

Definitie Waarde
RDF Eigenschap dcat:dataset
Bereik dcat:Dataset
Kardinaliteit 0..n
Gebruik Recommended
3.6.1.3 service nieuw

De (metadata van de) dataservice die voorkomt in de catalogus. Dataservice is een nieuwe resource in DCAT2.

Definitie Waarde
RDF Eigenschap dcat:service
Bereik dcat:DataService
Kardinaliteit 0..n
Gebruik Recommended
3.6.1.4 catalog nieuw

De (metadata van de) catalogus die voorkomt in de catalogus. Deze eigenschap maakt dus mogelijk om een catalogus te beschouwen als een resource en deze op te nemen in een catalogus.

Definitie Waarde
RDF Eigenschap dcat:catalog
Bereik dcat:Catalog
Kardinaliteit 0..n
Gebruik Recommended
3.6.1.5 themes

De themalijst die van toepassing is op alle resources in deze catalogus. Deze zal binnen dit toepassingsprofiel altijd verwijzen naar de overheid:TaxonomieBeleidsagenda (standaarden.overheid.nl).

Definitie Waarde
RDF Eigenschap dcat:themeTaxonomy
Bereik rdfs:Resource
Kardinaliteit 0..1
Gebruik Optional

3.6.2 Niet overgenomen eigenschappen

De eigenschappen in de onderstaande tabel bestaan wel in de bovenliggende DCAT 2.0, DCAT-AP 2.1 en/of DCAT-AP-DONL 1.1 standaarden, maar worden niet overgenomen in dit profiel.

Eigenschap Herkomst
dct:hasPart DCAT
dct:isPartOf DCAT

3.7 Catalogusrecord (dcat:CatalogRecord)

Noot

Een Catalogusrecord geeft informatie over de registratie van één dcat:Resource in een catalogus. Alle records samen bevatten de administratieve metadata van een DCAT beschrijving. Met name het versiebeheer van ieder dcat:Resource in de DCAT beschrijving kan hiermee worden bijgehouden en uitgewisseld.

Deze klasse is optioneel en niet alle catalogi maken hiervan gebruik, omdat het niet altijd nuttig is de historie van wijzigingen in een DCAT beschrijving uit te wisselen. Ze maakt het catalogi mogelijk om een onderscheid te maken tussen de metadata over een dataset of dataservice en metadata over een voorkomen van een dataset of dataservice in een catalogus. Eigenschap publicatiedatum van een dataset beschrijft bijvoorbeeld de datum waarop de data-eigenaar de gegevens in eerste instantie heeft gepubliceerd, terwijl de publicatiedatum van het catalogus record de datum beschrijft waarop de dataset is opgenomen in de catalogus.

CatalogRecord kan met conformsTo aangeven aan welk toepassingsprofiel de metadata over de DCAT-resource voldoet. Dat kan belangrijk zijn bij de uitwisseling van de metadata van datasets (of andere DCAT-resources) tussen dataportalen. Het kan voorkomen dat de metadata moet voldoen aan een specifieke toepassingsprofielen van DCAT.

3.7.1 Eigenschappen

Eigenschap Kardinaliteit Aanwezigheid Herkomst
primary topic 1..1 Mandatory Catalogusrecord
modified 1..1 Mandatory Catalogusrecord
listing date 1..1 Recommended Catalogusrecord
conformsTo nieuw 0..1 Recommended Catalogusrecord
source metadata 0..1 Optional Catalogusrecord
3.7.1.1 primary topic

Betreft de verwijzing naar de dcat:Dataset, dcat:DataService of dcat:Catalog die met dit record beschreven wordt.

Definitie Waarde
RDF Eigenschap foaf:primaryTopic
Bereik dcat:Resource (dataset, dataservice or catalog)
Kardinaliteit 1..1
Gebruik Mandatory
3.7.1.2 modified

De datum waarop het record in de catalogus voor het laatst is gewijzigd.

Definitie Waarde
RDF Eigenschap dct:modified
Bereik xsd:date
Kardinaliteit 1..1
Gebruik Mandatory
Noot
3.7.1.3 listing date

De datum waarop het record in de catalogus voor het eerst is toegevoegd.

Definitie Waarde
RDF Eigenschap dct:issued
Bereik xsd:date
Kardinaliteit 1..1
Gebruik Recommended
Noot
3.7.1.4 conformsTo nieuw

Een verwijzing naar het DCAT applicatieprofiel waar de metadata van de dcat:Resource aan voldoet.

Definitie Waarde
RDF Eigenschap dct:conformsTo
Bereik dct:Standard
Kardinaliteit 0..1
Gebruik Recommended
Noot
3.7.1.5 source metadata

Een verwijzing naar de bron waar de metadata van de dcat:Resource vandaan komt.

Definitie Waarde
RDF Eigenschap dct:source
Bereik xsd:anyURI
Kardinaliteit 1..1
Gebruik Optional
Noot

3.7.2 Niet overgenomen eigenschappen

De eigenschappen in de onderstaande tabel bestaan wel in de bovenliggende DCAT 2.0, DCAT-AP 2.1 en/of DCAT-AP-DONL 1.1 standaarden, maar worden niet overgenomen in dit profiel.

Eigenschap
dct:title
dct:description
dct:language
adms:status

4. Waardelijsten

4.1 Beheer

TODO: Beheer van waardelijsten en beheer van de inhoud van de waardelijsten beschrijven.

4.2 Overzicht

Binnen dit toepassingsprofiel worden de onderstaande waardelijsten toegepast.

4.2.1 donl:AccessRights

Bevat concepten die de mate van openbaarheid beschrijven van een bron. Deze waardelijst bestaat uitsluitend uit concepten die afgeleid zijn van de concepten uit de mdr:AccessRights (publications.europa.eu) taxonomie die op Europees niveau toegepast wordt.

Noot

Elk donl:AccessRights concepts (Github.com/dataoverheid) bevat een skos:broader eigenschap met daarin een verwijzing naar het bovenliggende mdr:AccessRights (publications.europa.eu) concept.

Serialisatie Adres
Turtle https://raw.githubusercontent.com/dataoverheid/dcat-ap-donl/main/taxonomy/access-rights.ttl

4.2.2 donl:Language

Deze taxonomie bevat concepten die de taal van een bron (data of metadata) beschrijven. Alle concepten komen uit de mdr:Language (publications.europa.eu).

Er is geen ondersteuning voor alle talen uit de mdr:Language (publications.europa.eu). Alleen de voor data.overheid.nl relevante taalconcepten zijn overgenomen.

Serialisatie Adres
Turtle https://raw.githubusercontent.com/dataoverheid/dcat-ap-donl/main/taxonomy/languages.ttl

4.2.3 donl:License

Deze taxonomie bevat concepten die de licentie beschrijven die van toepassing is op een bron. Deze waardelijst bevat voornamelijk, maar niet uitsluitend, CreativeCommons licenties. Deze taxonomie is gespitst op het aanbieden van data via een "open" licentie.

In DCAT-AP-DONL 1.1 werden van een aantal CreativeCommons licenties alleen de 4.0 versies aangeboden. In dit profiel worden de 3.0 versies van deze licenties ook aangeboden. Dit omdat blijkt dat veel data nog via een van de 3.0 varianten beschikbaar wordt gesteld.

Serialisatie Adres
Turtle https://raw.githubusercontent.com/dataoverheid/dcat-ap-donl/main/taxonomy/licences.ttl

4.2.4 donl:RelevantOrganization

Zie ook: overheid:Organisatie

Serialisatie Adres
Turtle https://raw.githubusercontent.com/dataoverheid/dcat-ap-donl/main/taxonomy/organizations.ttl

4.2.5 donl:Role

Deze taxonomie bevat concepten die beschrijven in welke capaciteit een persoon of organisatie betrokken is (of is geweest) bij een bron.

Het DCAT-AP 2.1 beveelt de ISO-19115 RoleCode taxonomie aan. Deze is echter niet in linked data vorm beschikbaar. Om deze reden biedt dit profiel zelf een skos:ConceptScheme aan met daarin opgenomen de CI_RoleCode concepten.

Deze lijst moet gebruikt worden bij het invullen van het prov:hadRole eigenschap, wat onderdeel is van het prov:qualifiedAttribution eigenschap, die vanuit dcat:Resource aangeboden wordt.

Serialisatie Adres
Turtle https://raw.githubusercontent.com/dataoverheid/dcat-ap-donl/main/taxonomy/roles.ttl

4.2.6 donl:SupportingRole

Bevat concepten die beschrijven wat voor ondersteunende rol een bron dient voor een andere bron (het kan bijvoorbeeld aangeven dat een distributie documentatie bevat van een dataset). Deze waardelijst heette in DCAT-AP-DONL 1.1 donl:DistributionType.

De lijst is aanzienlijk ingekort aangezien een aantal 'types' herleidbaar zijn uit andere metadata-eigenschappen. Zo zijn de concepten DOWNLOAD en WEBSERVICE niet meegenomen uit de oude lijst aangezien deze informatie al geduid wordt door middel van de eigenschappen dcat:downloadURL en/of dcat:accessService die op dcat:Distribution niveau aanwezig zijn.

Noot
Serialisatie Adres
Turtle https://raw.githubusercontent.com/dataoverheid/dcat-ap-donl/main/taxonomy/supporting-roles.ttl

4.2.7 iana:Mediatype

Bevat concepten die de mimetype van een bron beschrijven. Deze lijst is raadpleegbaar via IANA Mediatypes.

Serialisatie Adres
XML https://www.iana.org/assignments/media-types/media-types.xml

4.2.8 mdr:Filetype

Bevat concepten die het bestandsformaat van een bron beschrijven. Dit is een Europese taxonomie raadpleegbaar via mdr:Filetype (publications.europa.eu).

Serialisatie Adres
RDF/XML https://publications.europa.eu/resource/authority/file-type

4.2.9 mdr:Frequency

Bevat concepten die beschrijven met welke frequentie een bron verwacht bijgewerkt te worden. Dit is een Europese taxonomie raadpleegbaar via mdr:Frequency (publications.europa.eu).

Serialisatie Adres
RDF/XML https://publications.europa.eu/resource/authority/frequency

4.2.10 overheid:Gemeente

Deze taxonomie bevat concepten die de gemeenten van de Nederlandse overheid beschrijven. Deze lijst komt uit de OWMS 4.0 en is raadpleegbaar via overheid:Gemeente (standaarden.overheid.nl).

Serialisatie Adres
XML https://standaarden.overheid.nl/owms/terms/Gemeente.xml
RDF/XML https://standaarden.overheid.nl/owms/terms/Gemeente.rdf
N3 https://standaarden.overheid.nl/owms/terms/Gemeente.n3

4.2.11 overheid:Koninkrijksdeel

Deze taxonomie bevat concepten die de koninkrijksdelen van het Koninkrijk der Nederlanden beschrijven. Deze lijst komt uit de OWMS 4.0 en is raadpleegbaar via overheid:Koninkrijksdeel (standaarden.overheid.nl).

Serialisatie Adres
XML https://standaarden.overheid.nl/owms/terms/Koninkrijksdeel.xml
RDF/XML https://standaarden.overheid.nl/owms/terms/Koninkrijksdeel.rdf
N3 https://standaarden.overheid.nl/owms/terms/Koninkrijksdeel.n3

4.2.12 overheid:Organisatie

Deze taxonomie bevat concepten die de overheidsorganisaties van de Nederland beschrijven. Deze lijst komt uit de OWMS 4.0 en is raadpleegbaar via overheid:Organisatie (standaarden.overheid.nl).

Serialisatie Adres
XML https://standaarden.overheid.nl/owms/terms/Organisatie.xml
RDF/XML https://standaarden.overheid.nl/owms/terms/Organisatie.rdf
N3 https://standaarden.overheid.nl/owms/terms/Organisatie.n3

4.2.13 overheid:Provincie

Deze taxonomie bevat concepten die de provincies van de Nederlandse overheid beschrijven. Deze lijst komt uit de OWMS 4.0 en is raadpleegbaar via overheid:Provincie (standaarden.overheid.nl).

Serialisatie Adres
XML https://standaarden.overheid.nl/owms/terms/Provincie.xml
RDF/XML https://standaarden.overheid.nl/owms/terms/Provincie.rdf
N3 https://standaarden.overheid.nl/owms/terms/Provincie.n3

4.2.14 overheid:Waterschap

Deze taxonomie bevat concepten die de waterschappen van de Nederlandse overheid beschrijven. Deze lijst komt uit de OWMS 4.0 en is raadpleegbaar via overheid:Waterschap (standaarden.overheid.nl).

Serialisatie Adres
XML https://standaarden.overheid.nl/owms/terms/Waterschap.xml
RDF/XML https://standaarden.overheid.nl/owms/terms/Waterschap.rdf
N3 https://standaarden.overheid.nl/owms/terms/Waterschap.n3

4.2.15 overheid:TaxonomieBeleidsagenda

Bevat concepten die de beleidsagenda van de Nederlandse overheid vertegenwoordigen. Deze lijst komt uit de OWMS 4.0 en is raadpleegbaar via overheid:TaxonomieBeleidsagenda (standaarden.overheid.nl).

Er wordt nog onderzocht hoe de mapping van de overheid:TaxonomieBeleidsagenda (standaarden.overheid.nl) naar de mdr:DataTheme (publications.europa.eu) aangeboden gaat worden.

Serialisatie Adres
XML https://standaarden.overheid.nl/owms/terms/TaxonomieBeleidsagenda.xml
RDF/XML https://standaarden.overheid.nl/owms/terms/TaxonomieBeleidsagenda.rdf
N3 https://standaarden.overheid.nl/owms/terms/TaxonomieBeleidsagenda.n3

4.2.16 spdx:ChecksumAlgorithm

Bevat concepten die beschrijven welk algorithme gebruikt is om tot een hash te komen die als checksum dient van een bron. Alle concepten komen uit de spdx:ChecksumAlgorithm.

spdx:ChecksumAlgorithm is niet als LinkedData beschikbaar. Om deze reden biedt data.overheid.nl deze lijst zelf als LinkedData aan.

Serialisatie Adres
Turtle https://github.com/dataoverheid/dcat-ap-donl/raw/main/taxonomy/algorithms.ttl

A. Scenarios

Hoe kan DCAT worden gebruikt in de volgende scenarios?

Invullen van thema-eigenschappen

Thema's zijn de belangrijkste inhoudelijke eigenschap waarop informatie op DONL eenduidige doorzocht kan worden. De thema eigenschap is gedefinieerd voor dcat:Dataset, dcat:DataService en voor dcat:Catalog. Er zijn meerdere thema waardes toegestaan per beschrijving.

Zoals te lezen is in de paragraaf Vindbaarheid kunnen op DONL alleen thema's worden gekozen die door DONL zelf worden aangeboden. In lokale DCAT beschrijvingen kunnen andere thema-taxonomieën worden gebruikt, zelfs per dcat:Catalog gedefinieerd, maar omdat DONL geen externe catalogi inleest, kunnen er op die manier geen thema-lijsten worden toegevoegd. DONL gaat de lijst met aangeboden thema-taxonomiën in de toekomst actief te onderhouden en indien nodig uit te breiden.

Op dit moment zijn er tweede thema-lijsten waaruit waardes gekozen kunnen worden:

Naam themalijst Type Gebruik
overheid:TaxonomieBeleidsagenda (standaarden.overheid.nl) Waardelijst Mandatory
Clusterbegrippen Stelselcatalogus Logius Waardelijst Recommended

Uit de Taxonomiebeleidsagenda kiest u een waarde die beschrijft op welke gebied de gegevens betrekking hebben. Probeer hierbij zo specifiek mogelijk te zijn.

Clusterbegrippen

Kies ook één of meer clusterbegrippen die aangeven welke informatie in uw gegevens belangrijk is. Het zal voorkomen dat geen van de Clusterbegrippen verwijst naar informatie in uw gegevens. In dat geval vult u geen Clusterbegrip in. Als u vindt dat er een Clusterbegrip ontbreekt in de lijst, kunt u contact opnemen met Stelselcatalogus om dat eventueel te laten toevoegen.

In onderstaand voorbeeld zijn zes waardes uit de taxonomie belaidsagenda en de Clusterbegrippen opgenomen om de aangeboden gegevens in de data service goed te beschrijven.

Gesloten data beschrijven met DCAT

Organisaties die geen overheid zijn

Invullen creator en publisher

Wat doe ik als ik een REST/JSON wil omschrijven in DCAT?

Wat doe ik als ik een Excel wil delen?

DCAT beschrijving voor intern gebruik ontwikkelen

DCAT dient als vocabulaire om het delen van data tussen verschillende partijen makkelijker te maken. Maar het kan ook erg goed worden gebruikt om interne data te beschrijven. Binnen organisaties kunnen verschillende afdelingen immers als partij worden gezien. En overzicht is op elk niveau waardevol.

Wanneer interne data in DCAT beschreven wordt, wordt het delen van deze zelfde informatie met de buitenwereld een stuk makkelijker. Dit heeft dezelfde structuur en er is dus geen vertaling meer nodig.

Mocht DCAT-AP-DONL 2.0 niet voldoen aan de interne behoeftes is het makkelijk uit te breiden en aan te passen. Goede bronnen hiervoor zijn DCAT 2.0 en DCAT-AP 2.1.

Er kan bijvoorbeeld worden gekozen om de eigenschap dct:license achter wege te laten. Of er kunnen ter verrijking eigenschappen worden toevoegt.

Wanneer de data niet naar buiten wordt gecommuniceerd kan men ook andere waardelijsten gebruiken. De TaxonomieBeleidsagenda

wordt op data.overheid.nl verplicht om consistentie te behouden, maar een eigen thema waardelijst kan voor intern gebruik veel krachtiger zijn. Ook kan bijvoorbeeld met eigen waardes voor AccessRights binnen een organisatie direct duidelijk worden gemaakt wie er wel en wie geen toegang heeft tot de data.

Let er wel op dat wanneer men aangepaste beschrijvingen toch met de buitenwereld wil delen, er een oplossing moet zijn om deze aan te kunnen laten sluiten. Interne eigenschappen kunnen vervallen, maar voor waardelijsten zal een mapping nodig zijn.

Ook kan men door middel van dcat:Catalog een eigen structuur of hiërarchie creëren.

Interne DCAT beschrijving uitwisselen met DONL

Het delen van DCAT beschrijvingen van interne data kan gewenst zijn om transparantie in de organisatie en processen te verhogen. Maar ook om te delen dat je gesloten data hebt, dat in overleg misschien gedeeld kan worden.

Denk in het eerste geval bijvoorbeeld aan het kenbaar maken dat je als organisatie een personeelsbestand hebt. En denk bij het tweede aan de microdata van het CBS dat niet openbaar is. Men kan een aanvraag doen om deze toch in te kunnen zien en te gebruiken.

Met alleen een DCAT beschrijving is de data meestal niet direct toegankelijk. Het is wel goed mogelijk dat er toch gevoelige informatie in staat. Dit kan in de description zijn, of één van de (eigen toegevoegde) velden of waardelijsten. Let hier erg goed op!

Denk verder aan welke informatie er gedeeld moet worden met een geïnteresseerde in de data. Naast het weghalen van de gevoelige informatie kan het waardevol zijn om voor het nieuwe publiek informatie toe te voegen. Bijvoorbeeld eigenschappen als AccessRights en documentation zullen belangrijker worden. Ook kan het de moeite waard zijn de titelen description te herschrijven. En zal het contact punt voor extern anders zijn dan intern.

In dit toepassingsprofiel is voor elke klasse te vinden welke eigenschappen er verplicht zijn.

B. Termenlijst

Applicatieprofiel

Dit data.overheid.nl DCAT-applicatieprofiel hanteert dezelfde definitie als die van application profile die in §1,2 van DCAT-AP 2.1 is opgenomen:

The Application Profile is intended to facilitate data exchange and therefore the classes and properties defined in this document are only relevant for the data to be exchanged; there are no requirements for communicating systems to implement specific technical environments. The only requirement is that the systems can export and import data in RDF in conformance with this Application Profile.

DCAT beschrijving

Met behulp van het DCAT-AP-DONL profiel kan iedere partij de aangeboden gegevens beschrijven, zowel aangeboden als data service en als aangeboden als distributies.

DONL

DONL is de afkorting voor http://data.overheid.nl. Deze voorziening biedt zowel met behulp van een website als via API’s een overzicht van het gegevens aanbod van de Nederlandse overheid.

Gebruiker

Een gebruiker is een persoon of automatisch systeem die/dat gebruikt maakt van DONL om gegevens te vinden. Een gebruiker gebruikt de zoekfunctionaliteit en sorteer mogelijkheden van DONL om uit het aanbod een relevante selectie te maken. Met de DCAT-beschrijvingen uit die selectie kan de gebruiker daarna in detail bekijken of de beschreven gegevens voldoen.

Open data

Open data is een verzamelnaam voor gegevensverzameling die gratis beschikbaar worden gesteld voor ieder gebruik, wat wordt aangegeven met een overeenkomstig licentie. Er zijn zeer veel aanbieders van Open Data. Veel overheden, waaronder de Nederlandse streven ernaar zoveel gegevens als Open Data aan te bieden. Twee drijvende gedachte achter de Open Data beweging zijn dat Open Data de transparantie bevorderd en er toepassingen mogelijk worden die niet door de eigenaren van de gegevens voorzien (kunnen) worden. Veel Open Data wordt aangeboden als Linked Data. Hiervoor wordt ook de term Linked Open Data, LOD, gebruikt.

Opsteller

De opsteller maakt een een DCAT beschrijving van het aanbod van zijn of haar organisatie zodat die gegevens door anderen gebruikt kunnen worden. Binnen de afbakening van dit profiel zal deze beschrijving gedeeld worden met DONL zodat geïntereseerden relatief eenvoudig van het bestaan op de hoogte gebracht kunnen worden.

Resource

We gebruiken dcat:Resource of resource in dit document regelmatig als een verzamelnaam voor drie veel gebruikte klasses in een DCAT beschrijving: dcat:catalog, dcat:dataset en dcat:dataService. Zij zijn alledrie afgeleid van de dcat:resource klasse en worden daarom soms met die naam aangeduid. Verder wordt uitgelegd bij de definite van dcat:resource dat in DCAT geen instanties van resource mogen voorkomen, alleen van deze drie subklasses. Merk op dat dcat:distributie niet is afgeleid van dcat:resource en dus niet onder deze aanduiding valt.

URI

C. Contributors

Accounts die een bijdrage hebben geleverd via de Github repository.

D. Lijst met issues

E. Lijst met figuren

F. Referenties

F.1 Informatieve referenties

[CLUSTERBEGRIPPEN]
Clusterbegrippen Stelselcatalogus Logius. Logius. URL: https://www.stelselcatalogus.nl/clusterbegrippen
[DATA_EU]
data.europa.eu. The Publications Office of the European Union. URL: https://data.europa.eu/en
[DCAT_20]
DCAT 2.0. World Wide Web Consortium. URL: https://www.w3.org/TR/vocab-dcat-2
[DCATAP_21]
DCAT-AP 2.1. The Publications Office of the European Union. URL: https://joinup.ec.europa.eu/collection/semantic-interoperability-community-semic/solution/dcat-application-profile-data-portals-europe/release/210
[DCATAPDONL_11]
DCAT-AP-DONL 1.1. Kennis- en exploitatiecentrum voor Officiële Overheidspublicaties. URL: https://dcat-ap-donl.readthedocs.io/en/latest/
[DONL]
data.overheid.nl. Kennis- en exploitatiecentrum voor Officiële Overheidspublicaties. URL: https://data.overheid.nl/
[DONL_ACCESSRIGHTS_CONCEPTS]
donl:AccessRights concepts (Github.com/dataoverheid). Kennis- en exploitatiecentrum voor Officiële Overheidspublicaties. URL: https://github.com/dataoverheid/dcat-ap-donl/tree/main/term/access-rights
[DONL_SUPPORTINGROLE_CONCEPTS]
donl:SupportingRole concepts (Github.com/dataoverheid). Kennis- en exploitatiecentrum voor Officiële Overheidspublicaties. URL: https://github.com/dataoverheid/dcat-ap-donl/tree/main/term/supporting-roles
[EPSG28992]
EPSG:28992. NSGI. URL: https://epsg.io/28992
[GEONAMES]
GeoNames.org. URL: https://www.geonames.org/
[HTTPS_EN_HSTS]
HTTPS en HSTS. Forum Standaardisatie. URL: https://www.forumstandaardisatie.nl/open-standaarden/https-en-hsts
[IANA_MEDIATYPES]
IANA Mediatypes. Internet Assigned Numbers Authority. URL: https://www.iana.org/assignments/media-types/media-types.xhtml
[ISO19115_ROLECODE]
ISO-19115 RoleCode. International Organization for Standardization. URL: https://standards.iso.org/iso/19115/resources/Codelists/gml/CI_RoleCode.xml
[ISO8601]
ISO-8601. International Organization for Standardization. URL: https://www.iso.org/iso-8601-date-and-time-format.html
[JURICONNECT]
Juriconnect. Kennis- en exploitatiecentrum voor Officiële Overheidspublicaties. URL: https://www.koopoverheid.nl/standaarden/juriconnect
[JURICONNECT_13]
Juriconnect 1.3. URL: https://www.juriconnect.nl/downloadreg.asp?bestand=Juriconnect%5FStandaard%5FBWB%5F1%5F3%2Epdf&type=pdf
[MDR_ACCESSRIGHTS]
mdr:AccessRights (publications.europa.eu). The Publications Office of the European Union. URL: https://publications.europa.eu/resource/authority/access-right
[MDR_DATATHEME]
mdr:DataTheme (publications.europa.eu). The Publications Office of the European Union. URL: https://publications.europa.eu/resource/authority/data-theme
[MDR_FILETYPE]
mdr:Filetype (publications.europa.eu). The Publications Office of the European Union. URL: https://publications.europa.eu/resource/authority/file-type
[MDR_FREQUENCY]
mdr:Frequency (publications.europa.eu). The Publications Office of the European Union. URL: https://publications.europa.eu/resource/authority/frequency
[MDR_LANGUAGE]
mdr:Language (publications.europa.eu). The Publications Office of the European Union. URL: https://publications.europa.eu/resource/authority/language
[OWMS_40]
OWMS 4.0. Kennis- en exploitatiecentrum voor Officiële Overheidspublicaties. URL: https://standaarden.overheid.nl/owms/terms
[OWMS_EPSG28992]
overheid:EPSG28992 (standaarden.overheid.nl). Kennis- en exploitatiecentrum voor Officiële Overheidspublicaties. URL: https://standaarden.overheid.nl/owms/4.0/doc/syntax-codeerschemas/overheid.epsg28992
[OWMS_GEMEENTE]
overheid:Gemeente (standaarden.overheid.nl). Kennis- en exploitatiecentrum voor Officiële Overheidspublicaties. URL: https://standaarden.overheid.nl/owms/terms/Gemeente
[OWMS_KONINKRIJKSDEEL]
overheid:Koninkrijksdeel (standaarden.overheid.nl). Kennis- en exploitatiecentrum voor Officiële Overheidspublicaties. URL: https://standaarden.overheid.nl/owms/terms/Koninkrijksdeel
[OWMS_ORGANISATIE]
overheid:Organisatie (standaarden.overheid.nl). Kennis- en exploitatiecentrum voor Officiële Overheidspublicaties. URL: https://standaarden.overheid.nl/owms/terms/Organisatie
[OWMS_POSTCODEHUISNUMMER]
overheid:PostcodeHuisnummer (standaarden.overheid.nl). Kennis- en exploitatiecentrum voor Officiële Overheidspublicaties. URL: https://standaarden.overheid.nl/owms/4.0/doc/syntax-codeerschemas/overheid.postcodehuisnummer
[OWMS_PROVINCIE]
overheid:Provincie (standaarden.overheid.nl). Kennis- en exploitatiecentrum voor Officiële Overheidspublicaties. URL: https://standaarden.overheid.nl/owms/terms/Provincie
[OWMS_SYNTAXCODEERSCHEMA]
overheid:SyntaxCodeerschema (standaarden.overheid.nl). Kennis- en exploitatiecentrum voor Officiële Overheidspublicaties. URL: https://standaarden.overheid.nl/owms/4.0/doc/syntax-codeerschemas
[OWMS_TAXONOMIEBELEIDSAGENDA]
overheid:TaxonomieBeleidsagenda (standaarden.overheid.nl). Kennis- en exploitatiecentrum voor Officiële Overheidspublicaties. URL: https://standaarden.overheid.nl/owms/4.0/doc/waardelijsten/overheid.taxonomiebeleidsagenda
[OWMS_WATERSCHAP]
overheid:Waterschap (standaarden.overheid.nl). Kennis- en exploitatiecentrum voor Officiële Overheidspublicaties. URL: https://standaarden.overheid.nl/owms/4.0/doc/waardelijsten/overheid.waterschap
[SPDX_CHECKSUMALGORITHM]
spdx:ChecksumAlgorithm. The Software Package Data Exchange (SPDX). URL: http://spdx.org/rdf/terms#ChecksumAlgorithm
[TOOI]
TOOI - Thesaurus en Ontologie Overheidsinformatie. Kennis- en exploitatiecentrum voor Officiële Overheidspublicaties. URL: https://tardis.overheid.nl