Het is mede gebaseerd op het toepassingsprofiel van DCAT-AP-3.0 van de EU voor uitwisseling tussen gegevenscatalogi in Nederland. DCAT-AP-NL-3.0 is een doorontwikkeling van DCAT-AP-DONL-2.0.
Status van dit document
Dit is een werkversie die op elk moment kan worden gewijzigd, verwijderd of vervangen door andere documenten. Het is geen door het TO goedgekeurde consultatieversie.
1. Niet-normatieve deel
Dit onderdeel is niet normatief.
1.1 Introductie
1.1.1 DCAT-AP NL
Om gestandaardiseerd metadata uit te wisselen tussen verschillende dataportalen heeft Europa het DCAT-AP-3.0 ontwikkeld. DCAT-AP-3.0 is gebaseerd op de "Data Catalog Vocabulary" (DCAT) -specificatie DCAT-AP-3.0, die wordt ontwikkeld door de Dataset Exchange Working Group. DCAT is een RDF-vocabulaire die ontworpen is om de interoperabiliteit tussen op het web gepubliceerde datacatalogi te vergemakkelijken. Dit profiel faciliteert de uitwisseling van metadata van verschillende domeinen tussen Nederlandse datacatalogi van (semi)overheidsorganisaties op lokaal, regionaal en landelijk nivo en tussen Nederlandse datacatalogi en EU datacatalogi, Het definieert het schema en geeft voorbeelden voor het gebruik ervan.
DCAT stelt een dataprovider in staat om datasets en dataservices in een catalogus te beschrijven met behulp van een standaardmodel en vocabulaire dat het gebruik en de aggregatie van metadata uit meerdere catalogi vergemakkelijkt. Dit kan de vindbaarheid van datasets en dataservices vergroten. Het maakt het ook mogelijk om een gedecentraliseerde benadering te hebben voor het publiceren van datacatalogi en maakt federatief zoeken naar datasets in catalogi op meerdere sites mogelijk met behulp van hetzelfde querymechanisme en dezelfde structuur.
In DCAT worden klassen en eigenschappen van andere gevestigde vocabulaires (ADMS, FOAF) hergebruikt. DCAT maakt gebruik van een bewezen set gemeenschappelijke metadata genaamd "Dublin Core", die in 2009 als ISO 15836-standaard werd gepubliceerd.
Dit document beschrijft het Nederlandse applicatieprofiel op DCAT-AP-3.0. Dit Nederlandse applicatieprofiel - DCAT-AP NL- beantwoordt de vraag over hoe DCAT-AP-3.0 in de praktijk wordt toegepast Nederland.
Noot: bron
Deze tekst is de introductie van het DCAT-AP-NL 3.0 toepassingsprofiel .
Dit toepassingsprofiel blijft in ontwikkeling. Commentaren, problemen, wensen e.d. kunnen als issue worden gemeld op de Github Issues pagina.
1.2 Producten en diensten
1.2.1 European Legislation Identifier (ELI)
De European Legislation Identifier (ELI) is een systeem om wetgeving online beschikbaar te maken in een gestandaardiseerd formaat, zodat deze over de grenzen heen toegankelijk, uitgewisseld en hergebruikt kan worden. Dit initiatief, gezamenlijk genomen door de EU-landen en instellingen, is vastgelegd in de conclusies van de Raad van 6 november 2017 over de Europese wetgevingsidentificatiecode (2017/C 441/05).
ELI is gebaseerd op een vrijwillige overeenkomst tussen de EU-landen. Het bevat technische specificaties over:
web-ID's (URI's) voor juridische informatie
metadata die specificeren hoe juridische informatie moet worden beschreven
een specifieke taal voor het uitwisselen van wetgeving in machine leesbare formaten
Noot
1.2.2 Core Public Service Vocabulary Application Profile
Alle diensten van de overheid zien er in de kern hetzelfde uit. In de figuur hieronder zie je wat van de kenmerken van overheidsdiensten, die we tot nu toe allemaal op onze eigen manier vastleggen. Neem notie van de Dataset aan de Output kant én Regelset bij de Wettelijke grondslag en Voorwaarde.
De Core Public Service Vocabulary Application Profile (CPSV-AP) is een herbruikbare en gemeenschappelijke dataset om Europese overheidsdiensten te beschrijven. Het doel is om de beschrijving van publieke diensten te harmoniseren en een goed niveau van interoperabiliteit te garanderen. Het is een EC-oplossing.
Issue 6: in Dublin Core gegevensset alleen output vd dienst? enhancement
Via Mariette Lokin:
Waarom wordt in Dublin Core de gegevensset alleen als output gezien van de dienst? Er moeten toch ook gegevens in (om de regels te kunnen laten ‘werken’)? Moet daar niet nog ergens een linkje gelegd worden in de plaat?
1.2.3 Samenwerkende Catalogi
De Samenwerkende Catalogi (SC) is een set afspraken over het uitwisselen van informatie over producten en diensten van de overheid op het internet. Door productinformatie te labelen met afgesproken labels en waarden kan deze hergebruikt worden. Zo kan bijvoorbeeld een gemeente ook producten en diensten van de provincie, het waterschap of het Rijk op de eigen website aanbieden.
Overheidsorganisaties publiceren informatie over hun productie en diensten volgens de Samenwerkende Catalogi-standaard. Dit betekent dat zij een product of dienst binnen hun eigen website de juiste metadata geven en op een machine-leesbare wijze beschikbaar stellen volgens deze standaard.
Deze informatie wordt dagelijks verzameld in een landelijke virtuele catalogus. Deze catalogus, die informatie over ruim 50.000 producten en diensten bevat, is dus altijd up-to-date. Deze catalogus is vervolgens te raadplegen via een open koppelvlak (API) zodat deze functionaliteit in elke website of voorziening kan worden geïntegreerd.
1.2.4 De Uniforme Productnamenlijst (UPL)
De Uniforme Productnamenlijst is een lijst met uniforme naamgeving voor de producten en diensten die de Nederlandse overheid biedt aan burgers en bedrijven. De nadruk daarbij ligt op producten en diensten waarbij er interactie met burgers en bedrijven is, zoals een aanvraag, melding of verplichting. Producten en diensten zoals onderhoud van de groenvoorziening of het wegennet zijn daarom niet in de UPL opgenomen. Iedere overheidsorganisatie is vrij om te bepalen wat haar producten en diensten zijn en welke naam zij daaraan geeft. Met name bij gemeenten zorgt dat voor een veelvoud aan producten en diensten, die eigenlijk in essentie hetzelfde zijn.
Om de vindbaarheid en het hergebruik van productinformatie te verbeteren is de Uniforme Productnamenlijst (UPL) ontwikkeld. De lijst zorgt voor synergie in het heterogene productaanbod. De uniforme productnamen worden gebruikt om op een eenduidige manier de productinformatie van de overheid in voorzieningen te integreren, ongeacht bestuurslaag, naamgeving of granulariteit.
Omdat het producten- en dienstenaanbod van de Nederlandse overheid regelmatig verandert, wordt de UPL vier keer per jaar bijgewerkt. Daarbij worden soms productnamen als ‘vervallen’ gemarkeerd. In sommige gevallen wordt de productnaam ‘opgevolgd’ door een nieuwe productnaam. Oude productnamen worden nooit weggegooid, maar blijven beschikbaar in de volledige historische productnamenlijst
1.3 De LegitiMaat
In opdracht van het ministerie van BZK hebben experts De LegitiMaat ontwikkeld. Dit is een visitatie-instrument om de geautomatiseerde uitvoering van wetten door de overheid op een gestandaardiseerde manier inzichtelijk te maken en te (laten) beoordelen. De LegitiMaat gaat uit van drie perspectieven: juridisch, ontwikkel en accountperspectief.
1.3.1 Het bereik van De LegitiMaat
De LegitiMaat gaat het om het gehele proces van wet tot aan individueel besluit en daarna, reactie van de ontvangers (telefoontjes, klachten, bezwaren) en de keteneffecten. Het is maatschappelijk zeer relevant dat dit proces beter inzichtelijk wordt. Daarmee verhogen we de transparantie. Met De LegitiMaat kan beoordeeld worden of de wetten, de algemene beginselen van behoorlijk bestuur en het verbod van discriminatie zijn nageleefd.
Als de overheid besluiten neemt in individuele gevallen waarbij het gaat om grote aantallen en veel vergelijkbare repeterende taken, gaat dit vaak geautomatiseerd. Hiervoor moet de wet vertaald worden en moet bepaald worden hoe de wet wordt uitgevoerd. Na gesprekken met de professionals hebben we dit proces in de volgende stappen onderscheiden.
Deze procesplaat is een illustratie, geen voorschrift. Elke organisatie zal het proces op een eigen manier hebben ingericht. Dat blijft in stand. De procesplaat en de onderverdeling in De LegitiMaat, is een manier om het gesprek te voeren én zijn een opmaat voor de standaardisatie van metadateren van regelspecificatie sets m.b.v. dit applicatieprofiel.
Issue 5: Inrichting en uitvoering beter van elkaar scheiden (ie figuur 2) enhancement
Via Marien Krouwel.
Figuur 2 kan duidelijker door inrichting en uitvoering beter van elkaar te scheiden: niet voor ieder besluit wordt nieuwe code gecreëerd, liever niet zelfs.
1.3.2 Aanpak
Verplichte velden voor regels.overheid.nl over de linkerkant van de flow zijn relaties met wetgeving, maar er kunnen 3 extra relaties zijn:
uitvoeringsbeleid (bron: [PUC], eigen website organisatie)
analyseren (zoals gepubliceerd in analysetools, wetsanalyse-editors, enz.)
werkinstructies (gepubliceerd in [PUC] of online in handboeken)
Voor de items aan de rechterkant van de stroom moeten we een klasse distributie aanbieden om te beschrijven:
functionele ontwerpen / koppelingen naar functionele ontwerpen in een Git-based-register (documentatie)
algoritmes / code / applicaties waar regels worden uitgevoerd, gepubliceerd in een Git-based-register (uitvoering)
Het is belangrijk om vast te stellen: wat wordt opgeslagen/beschreven als onderdeel van de regelspecificatie set en waaraan kan worden gekoppeld.
Hieruit volgt dat alle objecten aan de linkerkant van regels in de stroom moeten worden gekoppeld.
Alle objecten aan de rechterkant kunnen deel uitmaken van de regelspecificatie set.
Elke regelspecificatie set heeft een URI nodig die kan worden gebruikt om te linken in openbare communicatie/brieven.
2. Structuur van het toepassingsprofiel
2.1 DCAT als universeel vocabulaire
Het toepassingsprofiel in dit document is gebaseerd op de specificatie van de Data Catalog Vocabulary (DCAT), ontwikkeld onder verantwoordelijkheid van de Government Linked Data Working Group van W3C. DCAT is een RDF-vocabulaire dat is ontworpen om interoperabiliteit tussen gegevenscatalogi gepubliceerd op het web te vergemakkelijken. Waar nodig worden aanvullende klassen en eigenschappen uit andere bekende vocabulaires hergebruikt.
Het DCAT vocabulaire bestaat uit klassen en eigenschappen.
Klassen beschrijven dingen: Ze hebben niet allemaal een URI, maar het wordt aanbevolen om ze van een URI te voorzien. Een klasse beschrijft (complexe) dingen met vergelijkbare characteristieken zoals personen, organisaties, datasets of API's.
Klassen hebben eigenschappen: De eigenschappen zijn de attributen die deze dingen beschrijven. Sommige eigenschappen komen in meer dan één klasse voor, een titel bijvoorbeeld is een veel voorkomend attribuut. Andere eigenschappen zijn zeer gespecialiseerd, zoals een bestandsformaat dat alleen zinvol is voor een gegevensbestand.
Eigenschappen kunnen eenvoudig of complex zijn: sommige eigenschappen worden direct beschreven in bijvoorbeeld door mensen leesbare tekst of een datum (deze eigenschappen zijn ookwel owl:DatatypeProperty) en andere eigenschappen bevatten relaties naar andere objecten (een owl:ObjectProperty).
Over het algemeen kan een klasse herkend worden aan de schrijfwijze: De naam van een eigenschap begint met een kleine letter zoals dcat:dataset, terwijl de naam van een klasse begint met een hoofdletter zoals dcat:Dataset.
Klassen en eigenschappen worden gebruikt om de metadata op een gestructureerde manier aan te leveren.
2.2 Overzicht Klassen
Het volgende diagram geeft een overzicht van de basis functionaliteit van DCAT-AP-3.0 en dient als startblok voor het begrijpen van de constructie. LET OP, er zijn dus meer klassen, eigenschappen en relaties dan weergegeven zoals te zien in Klassen.
Deze tekst van DCAT als universeel vocabulaire en Overzicht klassen is de integraal overgenomen van het DCAT-AP-NL 3.0 toepassingsprofiel .
2.3 Relatie andere profielen
In deze versie zijn de nieuwe mogelijkheden van het toepassingsprofiel van de EU (DCAT-AP-3.0) meegenomen,
samen met aanpassingen op basis van ervaring welke is opgedaan sinds DCAT-AP-DONL-1.1. DCAT-AP-RONL is compatible met
bovenstaande standaarden, wat betekent dat een profiel dat voldoet aan DCAT-AP-RONL ook verwerkt kan worden binnen
Data Catalog Vocabulary (DCAT) - Version 2 en DCAT-AP 2.1.
Om zoveel mogelijk scenario's te ondersteunen, verplichten de originele Data Catalog Vocabulary (DCAT) - Version 2 van het W3C en het
toepassingsprofiel van de EU (DCAT-AP-3.0) weinig. Omdat regels.overheid.nl alleen de Nederlandse overheid betreft kunnen we
meer informatie van gebruikers vragen. Daarmee worden regels beter vindbaar.
3. Klassen
In dit hoofdstuk worden de belangrijkste klassen van het applicatieprofiel benoemd en beschreven. Deze klassen vormen de kern van het applicatieprofiel. De eigenschappen en de bijbehorende beperkingen die van toepassing zijn in de context van dit profiel worden in tabelvorm weergegeven. Elke rij komt overeen met één eigenschap. De eigenschappen worden in sub paragrafen verder toegelicht.
De niet beschreven klassen en eigenschappen behoren conform DCAT-AP-NL-3.0 toegepast te worden.
3.1 Regelset - ronl:RulesSet
Een regelspecificatie set is een zinvolle verzameling van samenhangende regelspecificaties, die beheerd of gepubliceerd wordt door één organisatie, en in één of meer formaten beschikbaar of downloadbaar is.
Issue 7: Juriconnect / ELI link naar bron van de regel illusteren enhancement
Via Mariette Lokin:
Ik mis ergens een veldje waar een Juriconnect (of op termijn ELI) link naar de bron van de regel gezet kan worden. Of zit het individuele regelniveau niet in dit profiel (zie ook alleen sets en services…). En zo nee, is/komt daar nog een apart profiel voor?
3.1.1 Eigenschappen
In de onderstaande tabel worden de eigenschappen van de ronl:Rulesset beschreven.
De identifier van de resource volgens de eigenaar van de regelspecificatie set. Dit is bij voorkeur URI die via HTTP raadpleegbaar is. Hier wordt de
oorspronkelijke identificatie van de resource genomen zoals de eigenaar deze gepubliceerd heeft. Voor de invulling van deze eigenschap wordt vereist dat een concept uit de waardelijst overheid:UPL gekozen wordt.
Afgezien van deze identifier kan de betreffende regelspecificatie set - 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.
Neem notie van de optionele mogelijkheid om deze identifier óók te linken met de Core Public Service Vocabulary Application Profile (CPSV-AP), een herbruikbare en gemeenschappelijke dataset om Europese overheidsdiensten te beschrijven. Het doel is om de beschrijving van publieke diensten te harmoniseren en een goed niveau van interoperabiliteit te garanderen. Het is een EC-oplossing. Deze worden overgenomen in cpsv:publicserviceidentifier. Een resource kan meerdere voorkomens van cpsv:publicserviceidentifier hebben.
Definitie
Waarde
RDF Eigenschap
dct:identifier
Bereik
xsd:anyURI
Kardinaliteit
1..1
Gebruik
Mandatory
3.1.1.2 title
De naam van de beschreven resource. 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 regelspecificatie set te beschrijven, dan kan dct:description gebruikt worden.
Definitie
Waarde
RDF Eigenschap
dct:title
Bereik
rdfs:literal
Kardinaliteit
1..n
Gebruik
Mandatory
3.1.1.3 description
Een beschrijving de resource. Om ervoor te zorgen dat eindgebruikers de regelspecificatie set goed kunnen vinden is het belangrijk dat de tekst goede trefwoorden bevat.
Definitie
Waarde
RDF Eigenschap
dct:description
Bereik
rdfs:literal
Kardinaliteit
1..n
Gebruik
Mandatory
3.1.1.4 license
De formele of wettelijke toestemming waaronder de regelspecificatie set gebruikt mogen worden.
Voor de licenties die van toepassing zijn op de piblicatie van regelspecificatie sets binnen de overheid zijn beperken we ons tot de Creative Commons licenties. Zie ook creativecommons.nl/uitleg/.
Er kunnen ook licentiegegevens op het niveau van de ronl:Distribution en/of ronl:RulesServiceworden vastgelegd. Die mogen niet in tegenspraak zijn met de licentiegegevens van de ronl:RegelSet.
Aan de hand van deze informatie kunnen eindgebruikers op regels.overheid.nl contact opnemen met de eigenaar van de regelspecificatie set 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.
regels.overheid.nl gebruikt dcat:theme om de regelspecificatie sets naar onderwerp in te delen. Door de eigenschap verplicht te stellen, kunnen eindgebruikers de betreffende regelspecificatie set 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 regelspecificatie sets ook aan meer specifieke subthema's kunnen worden gekoppeld, bijvoorbeeld subthema Waterschappen onder het thema Bestuur.
Wetsanalyse wordt binnen de overheid op uiteenlopende wijze toegepast. Een constante die wordt gedeeld, is de noodzaak de wet uit te voeren volgens de bedoeling van de wetgever. Dit betekent handelen volgens de beginselen van behoorlijk bestuur en de uitvoering zo soepel mogelijk aanpassen aan nieuwe politieke inzichten. Dat begint met de analyse die daarbij worden gebruikt inzichtelijk te maken.
Deze eigenschap bevat de analyse waarmee de toepasselijke wet- & regelgeving door de eigenaar naar de uitvoeringspraktijk is vertaald en die (uiteindelijk) in de vorm van de regelspecificatie set is gepubliceerd.
Regelbeheer wordt eveneens binnen de overheid op uiteenlopende wijze toegepast. Deze eigenschap bevat de methode en/of techniek die door de eigenaar is gebruikt bij de totstandkoming van de onderhavige regelspecificatie set.
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.
Definitie
Trefwoord
RDF Eigenschap
dcat:keyword
Bereik
rdfs:Literal
Kardinaliteit
0..n
Gebruik
Recommended
3.1.1.11 release date
De datum waarop de beschreven resource is gepubliceerd.
regels.overheid.nl registreert hier de eerste (vroegste) publicatiedatum waarop de leverancier deze regelspecificatie set heeft gepubliceerd. Het gaat hier dus niet om de publicatiedatum van de metadata. Ook niet over de wijzigingsdatum van de regelspecificatie set, hiervoor is de dct:modified eigenschap.
Het viel mij op dat er diverse keren xsd:datetime wordt gebruikt met verwijzing naar ISO 8601:2004. Deze is echter vervallen en vervangen door ISO 8601-1:2019 en ISO 8601-02:2019. Daarbij vroeg ik mij af of er ook nog een tijdzone in de notatie zou moeten zitten. Zeker rondom zomer- en wintertijd is er vaak onduidelijkheid. Ik kan me ook voorstellen dat in veel gevallen het tijdstip helemaal niet relevant is en beter weggelaten kan worden?
3.1.1.12 update/modification date
De datum waarop de beschreven resource is gewijzigd.
Het gaat hierbij om de meest recente datum waarop de regelspecificatie set is gewijzigd. Nieuwe versies worden náást de oudere versies geregistreerd.
Het viel mij op dat er diverse keren xsd:datetime wordt gebruikt met verwijzing naar ISO 8601:2004. Deze is echter vervallen en vervangen door ISO 8601-1:2019 en ISO 8601-02:2019. Daarbij vroeg ik mij af of er ook nog een tijdzone in de notatie zou moeten zitten. Zeker rondom zomer- en wintertijd is er vaak onduidelijkheid. Ik kan me ook voorstellen dat in veel gevallen het tijdstip helemaal niet relevant is en beter weggelaten kan worden?
3.1.1.13 distribution
De distributie van de regelspecificatie set, waarin de eigenaar beschrijft hoe de regelspecificatie(s) in de regelset toegankelijk is gemaakt.
Definitie
Waarde
RDF Eigenschap
ronl:distribution
Bereik
ronl:Distribution
Kardinaliteit
1..n
Gebruik
Mandatory
3.1.1.14 landing page
De webpagina die toegang geeft tot de regelspecificatie set en aanvullende informatie verschaft. Het gaat hierbij om de originele webpagina van de eigenaar.
Definitie
Waarde
RDF Eigenschap
dcat:landingPage
Bereik
xsd:anyURI
Kardinaliteit
0..1
Gebruik
Optional
3.1.1.15 other identifier
De verplichte eigenschap dct:identifier bevat de unieke identificatie van de regelspecificatie set die de eigenaar heeft uitgegeven. Deze eigenschap bevat evt. andere unieke identifiers van de regelspecificatie set zoals gegeven door catalogi als regels.overheid.nl of andere partijen. Wanneer men voor de regelspecificatie set 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.
Een distributie beschrijft hoe een (deel van) een regelspecificatie set te verkrijgen is. Verschillende distributies van dezelfde regelspecificatie set verschillen van elkaar in o.a. taal, formaat, schema's en/of anderszins.
De aanbieder van een regelspecificatie set 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 regelspecificatie set.
Als een regelspecificatie set (ook) wordt aangeboden in de vorm van een webservice kunnen hierover aanvullende gegevens worden opgenomen in een ronl:RulesService. Deze kan worden gerelateerd aan de bijbehorende distributie.
3.2.1 Eigenschappen
In de onderstaande tabel worden de eigenschappen van de ronl:Distribution beschreven.
Het web-adres (URL) van de site die toegang verschaft tot de distributie van de regelspecificatie set, aan de hand van bijvoorbeeld een webformulier, een zoekopdracht of een API-call. Het is vereist dat dit adres een directe link naar de distributie zélf is.
Wanneer de regelspecificatie set (ook) via een ronl:RulesService wordt aangeboden, dan staat in deze eigenschap de
volledige API-call waarmee de regelspecificatie set via de service kan worden uitgevoerd. Met dcat:accessService
wordt dan de link gemaakt met de ronl:RulesService.
Definitie
Waarde
RDF Eigenschap
dcat:accessURL
Bereik
xsd:anyURI
Kardinaliteit
1..1
Gebruik
Mandatory
Noot
3.2.1.2 title
De titel is belangrijk voor de herkenbaarheid van een distributie, dus kies deze zorgvuldig.
Definitie
Waarde
RDF Eigenschap
dct:title
Bereik
rdfs:Literal
Kardinaliteit
1..n
Gebruik
Mandatory
3.2.1.3 specification
Een nadere beschrijving van de distributie in aanvulling op de titel, waarmee afnemers een goed beeld krijgen welke regelspecificaties in de distributie aanwezig zijn.
Definitie
Waarde
RDF Eigenschap
ronl:specification
Bereik
rdfs:Literal
Kardinaliteit
1..n
Gebruik
Mandatory
3.2.1.4 specificationType
Bevat termen die het type van een ronl:Distribution beschrijven.
Voorbeelden zijn:
functionele ontwerpen / koppelingen naar functionele ontwerpen in een Git-based-register (documentatie)
algoritmes / code / applicaties waar regels worden uitgevoerd, gepubliceerd in een Git-based-register (uitvoering)
Alleen van toepassing wanneer de distributie via een regelservice bereikbaar is. Access service wordt niet ingevuld als de toegang tot de distributie. Dit kan in dcat:accessURL.
Definitie
Waarde
RDF Eigenschap
dcat:accessService
Bereik
dcat:DataService
Kardinaliteit
0..1
Gebruik
Recommended
3.3 Regelservice - ronl:RulesService
Beschrijft de webservice(s) die voor het oproepen van de geautomatiseerde uitvoering van regelspecificatie sets als communicatiemechanisme beschikbaar zijn.
Deze ronl:RulesService is een variant op de dcat:DataService klasse die in versie 2 van DCAT is geïntroduceerd. Het biedt uitgebreidere mogelijkheden om geautomatiseerde toegang tot executeerbare regelspecificatie set(s) te beschrijven dan mogelijk is in de klasse ronl:Distribution.
De ronl:RulesService klasse is evenals de dcat:DataService klasse optioneel. Dat betekent dat het mogelijk is om executeerbare regelspecificatie sets óók te beschrijven met de klasse ronl:Distribution.
3.3.1 Eigenschappen
In de onderstaande tabel worden de eigenschappen van de ronl:RulesService beschreven.
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
Een verwijzing naar de documentatie die de RulesService 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
3.3.1.3 serves rulesset
Een regelset die via deze ronl:RulesService aangeboden wordt. Een regelservice kan nul, een of meer regelsets aanbieden.
Definitie
Waarde
RDF Eigenschap
ronl:servesRulesSet
Bereik
ronl:RulesSet
Kardinaliteit
0..n
Gebruik
Recommended
4. Waardelijsten
Binnen dit toepassingsprofiel worden de onderstaande waardelijsten toegepast.
4.1 ronl:Analysis
Deze taxonomie bevat concepten die de gebruikte (wets)analyse van een ronl:RulesSet beschrijven.
Tot nader order publiceren we de waarden in onderstaande tabel.
Waarde
Wetsanalyse (JAS)
Wetsanalyse (JRM)
FLINT
4.2 ronl:Method
Deze taxonomie bevat concepten die de gebruikte methode en/of techniek van een ronl:RulesSet beschrijven.
Tot nader order publiceren we de waarden in onderstaande tabel.
Waarde
AKN4EU
ALEF
Avola
Beinformed
Blawx
Blueriq
Catala
CircuLaw
Concordia Legal
DataLex
DEMO
Gegevensstandaard Persoonlijke Financiën
LEOS
OpenFisca
Regelspraak
RuleManagement Methode
RuleSpeak
Sparkwise
USoft
4.3 ronl:License
Deze taxonomie bevat concepten die de licentie beschrijven die van toepassing is op een ronl:RulesSet, ronl:Distribution óf ronl:RulesService. Gebruik van Creative Commons Licenties (CC) is vereist. Aanbevolen wordt om steeds de meest recente versie van een licentie te gebruiken. In het geval geen (her)gebruik volgens een CC-licentie mogelijk is, mag de waarde ‘Niet Open' gebruikt worden.
Tot nader order publiceren we de waarden in onderstaande tabel.
Waarde
CC BY
CC BY-SA
CC BY-NC
CC BY-NC-SA
CC BY-ND
CC BY-NC-ND
Niet Open
4.4 iana:Mediatype
Bevat concepten die de mimetype van een bron beschrijven. Deze lijst is raadpleegbaar via IANA Mediatypes.
Bevat termen die het type van een ronl:Distribution beschrijven.
Tot nader order publiceren we de waarden in onderstaande tabel.
Waarde
Wetsanalyse
Functioneel Ontwerp
Software code
UX Design
Communicatiemiddel
Werkinstructie
Kwaliteitseisen
Bestuurlijke Informatie
Overig
4.6 overheid:UPL
Deze taxonomie bevat de Uniforme Productnamenlijst, een lijst met uniforme naamgeving voor de producten en diensten die de Nederlandse overheid biedt aan burgers en bedrijven. De nadruk daarbij ligt op producten en diensten waarbij er interactie met burgers en bedrijven is, zoals een aanvraag, melding of verplichting. Deze lijst komt uit de OWMS 4.0 en is raadpleegbaar via overheid:UPL (standaarden.overheid.nl).
Naast onderdelen die als niet normatief gemarkeerd zijn, zijn ook alle diagrammen, voorbeelden, en noten in dit document niet normatief. Verder is alles in dit document normatief.
