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.
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.
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.
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.
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.
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.
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.
In het toepassingsprofiel worden nieuwe eigenschappen aangegeven met de tag nieuw.
De eigenschappen behorend tot de klasse dcat:DataService
zijn nieuw.
Nieuw is access service zodat een distributie naar dcat:DataService
s kan verwijzen.
Nieuw is conforms to om de vindbaarheid van datasets te verbeteren.
Nieuw zijn creator en qualified-attribution om een beter onderscheid te kunnen maken tussen welke rollen verschillende partijen hebben rondom de dataset.
Legal foundation is een aangepaste versie van de overheid:grondslag
uit DCAT-AP-DONL 1.1.
Dit toepassingsprofiel maakt gebruik van de namespaces zoals weergegeven in de onderstaande tabel.
Prefix | URI |
---|---|
adms | |
dcat | |
dcatap | |
dct | |
foaf | |
overheid | |
prov | |
rdfs | |
skos | |
spdx | |
xsd | |
voaf | |
vcard | |
time |
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 |
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.
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.
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.
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.
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.
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.
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.
In dit hoofdstuk worden de klassen van het applicatieprofiel benoemd en beschreven.
Ga snel naar:
dcat:Dataset
dcat:Distribution
dcat:DataService
donl:LegalFoundation
dcat:Resource
dcat:Catalog
dcat:CatalogRecord
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.
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 |
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 |
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 |
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 |
Waardelijst | Optional | |
Syntaxcodeerschema | Optional | |
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.
GeoNames.org is een internationale database van locatiegegevens. Wanneer een locatie niet in de OWMS4.0 waardelijsten staat, dan kan deze database geraadpleegd worden om alsnog een locatiereferentie op te nemen.
overheid:EPSG28992 (standaarden.overheid.nl) is een overheid:SyntaxCodeerschema (standaarden.overheid.nl) waarmee coordinaten in het EPSG:28992 stelsel opgenomen kunnen worden. Deze optie maakt het mogelijk om bijvoorbeeld een 'bounding-box' op te nemen als locatiegegeven.
overheid:PostcodeHuisnummer (standaarden.overheid.nl) is een overheid:SyntaxCodeerschema (standaarden.overheid.nl) waarmee verwezen kan worden naar een (of een set van) combinaties van postcodes en huisnummers.
Definitie | Locatie |
---|---|
RDF Eigenschap | dct:spatial |
Bereik | De naam of de coördinaten van een gebied. |
Kardinaliteit | 0..n |
Gebruik | Optional |
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 |
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 |
Onderstaand voorbeeld beschrijft een dcat:Dataset
met enkel de verplichte eigenschappen. Dit is de meest minimale representatie van een dcat:Dataset
.
TODO: Access rights, licentie, vertaling, legal foundation.
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.
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 |
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 |
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 |
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
vandcat:Resource
.
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
indcat:Resource
.
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:Distribution
s.
Definitie | Waarde |
---|---|
RDF Eigenschap | dct:license |
Bereik | waardelijst donl:License |
Kardinaliteit | 1..1 |
Gebruik | Mandatory |
Zie ook
dct:license
indcat:Resource
.
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 |
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 |
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
indcat:Resource
.
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
indcat:Resource
.
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
indcat:Resource
.
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
indcat:Resource
.
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 |
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 |
Zie ook
dct:conformsTo
indcat:Resource
.
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 |
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 |
| 1..1 |
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 |
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 |
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 |
Onderstaand voorbeeld beschrijft een dcat:Distribution
met enkel de verplichte eigenschappen. Dit is de meest minimale representatie van een dcat:Distribution
.
TODO: Supportring Role
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.
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 |
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 |
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 |
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 |
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.
Onderstaand voorbeeld beschrijft een dcat:DataService
met enkel de verplichte eigenschappen. Dit is de meest minimale representatie van een dcat:DataService
.
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.
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.
In de onderstaande hoofdstukken worden de eigenschappen van de dcat:Resource
beschreven.
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 |
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 |
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 |
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 |
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.
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.
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 |
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.
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.
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
Het regelingelement dat de wettelijke grondslag vormt voor de dataset. Zie Legal Foundation voor een verdere omschrijving van donl:LegalFoundation
Definitie | Waarde |
---|---|
RDF Eigenschap | donl:grondslag |
Bereik | donl:LegalFoundation |
Kardinaliteit | 0..n |
Gebruik | Optional |
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 |
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 |
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 |
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 |
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 |
TODO: Syntax en inhoud.
Voorbeeld overgenomen van W3C
Bevat een verwijzing naar een wettelijke grondslag conform de Juriconnect standaard.
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 |
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 |
Het domein waarnaar verwezen wordt die de Juriconnect verwijzing bevat. Dit zal in de meeste gevallen wetten.overheid.nl zijn.
Definitie | Waarde |
---|---|
RDF Eigenschap | foaf:homepage |
Bereik | xsd:anyURI |
Kardinaliteit | 1..1 |
Gebruik | Mandatory |
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 |
Onderstaand voorbeeld beschrijft een donl:LegalFoundation
met enkel de verplichte eigenschappen. Dit is de meest minimale representatie van een donl:LegalFoundation
.
Webapplicaties zouden bovenstaande voorbeeld kunnen vertalen naar:
<a href="https://wetten.overheid.nl/jci1.3:c:BWBR0023466&z=2022-05-01&g=2022-05-01"> Wet BAG </a>
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.
Wanneer is een catalogus een dcat:Catalog?
Wanneer is een catalogus een dcat:Dataset?
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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.
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 |
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 |
|
Kardinaliteit | 1..1 |
Gebruik | Mandatory |
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 |
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 |
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 |
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 |
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 |
TODO: Beheer van waardelijsten en beheer van de inhoud van de waardelijsten beschrijven.
Binnen dit toepassingsprofiel worden de onderstaande waardelijsten toegepast.
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.
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 |
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 |
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 |
Zie ook:
overheid:Organisatie
Serialisatie | Adres |
---|---|
Turtle | https://raw.githubusercontent.com/dataoverheid/dcat-ap-donl/main/taxonomy/organizations.ttl |
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 |
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.
Serialisatie | Adres |
---|---|
Turtle | https://raw.githubusercontent.com/dataoverheid/dcat-ap-donl/main/taxonomy/supporting-roles.ttl |
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 |
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 |
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 |
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 | |
RDF/XML | |
N3 |
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).
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 | |
RDF/XML | |
N3 |
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 | |
RDF/XML | |
N3 |
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 | |
RDF/XML | |
N3 |
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.
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 |
Hoe kan DCAT worden gebruikt in de volgende scenarios?
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 |
---|---|---|
Waardelijst | Mandatory | |
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.
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.
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.
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.
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.
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 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.
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 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.
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.
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.
Accounts die een bijdrage hebben geleverd via de Github repository.
Issue 3: Wat is het gewenste waardebereik voor dct:spatial in dataset?
Issue 8: Verschil tussen dct:format en dcat:mediaType
Issue 22: Invullen van dct:license en dct:rights
Issue 4: Property: update/modification date in Distributie: Verplicht of Aanbevolen?
Issue 11: Verschillende talen
Issue 8: Verschil tussen dct:format en dcat:mediaType
Issue 10: checksum
Issue 12: Wat te doen met `distribution type` in Distribution?
Issue 22: Invullen van dct:license en dct:rights
Issue 23: Begrippenkader formuleren van eigenaar, verantwoordelijke, bronhouder, uitgever etc.
Issue 23: Begrippenkader formuleren van eigenaar, verantwoordelijke, bronhouder, uitgever etc.
Issue 38: Vullen van contactpoint
Issue 35: Hoe verhouden Theme, Types en ConformsTo zich tot elkaar?
Issue 28: Hoe ziet onze taxonomie voor dct:accessRights eruit?
Issue 11: Verschillende talen
Issue 24: Gebruik ID's
Issue 35: Hoe verhouden Theme, Types en ConformsTo zich tot elkaar?
Issue 14: dct:conformsTo in dcat:Resource
Issue 19: LegalFoundation naar Overheid:Grondslag
Issue 22: Invullen van dct:license en dct:rights
Issue 31: Voorstel voor een AgentRole taxonomie
Issue 23: Begrippenkader formuleren van eigenaar, verantwoordelijke, bronhouder, uitgever etc.
Issue 25: Voorbeeld voor qualified_attribution
Issue 21: Wat is een catalogus in DCAT nu precies
Figuur 1 DCAT 2.0 in het kort.
Figuur 2 DCAT-AP-DONL 2.0 positionering
Figuur 3 DCAT-AP-DONL 2.0 klassen