Waar we het in deze specificatie over regels hebben, bedoelen we óók algoritmes.
Doel van dit DCAT profiel is om beschrijvingen van regels te verzamelen in regels.overheid.nl die compatibel zijn met het DCAT-AP-DONL profiel voor data.overheid.nl.
Het volgende diagram geeft een overzicht van de basis functionaliteit van het beoogde DCAT-AP-RONL profiel en dient als overzicht van de te definieren beschrijvingen.
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
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 Data Catalog Vocabulary (DCAT) - Version 2 profielen van het W3C, zodat het vinden van de juiste gegevens en gegevensdiensten nog makkelijker wordt.
Noot: bron
Deze tekst is de introductie van het DCAT-AP-DONL 2.0 toepassingsprofiel .
Doel van dit DCAT profiel is om beschrijvingen van regels te verzamelen in regels.overheid.nl die compatibel zijn met het DCAT-AP-DONL profiel voor data.overheid.nl.
Dit toepassingsprofiel blijft in ontwikkeling. Commentaren, problemen, wensen e.d. kunnen als issue worden gemeld op de Github pagina.
1.2 Algoritmeregister
1.2.1 Nederlandse Algoritme Transparantie Standaard
De Nederlandse Algoritme MetaStandaard is een gestandaardiseerde manier om informatie te verzamelen over hoe de overheid algoritmische tools gebruikt. Met deze standaard registreert de Nederlandse Overheid algoritmes.
1.2.2 Registratie
De overheid werkt steeds meer digitaal en gebruikt daarvoor steeds vaker algoritmes. Omdat digitalisering niet vanzelfsprekend goed gaat, werkt de overheid aan transparante en verantwoorde inzet van die algoritmes. Zodat de informatie over de algoritmes die de overheid gebruikt voor iedereen beschikbaar is: burgers, hun belangenbehartigers, de media en toezichthouders.
Het ministerie van Binnenlandse Zaken en Koninkrijksrelaties bouwt door aan het Algoritmeregister dat in december 2022 is gelanceerd.
Het Algoritmeregister is in ontwikkeling. De informatie verandert nog vaak. Nieuwe algoritmes worden toegevoegd en algoritmes worden geactualiseerd. Ook bouwt het ministerie van Binnenlandse Zaken en Koninkrijksrelaties steeds door aan het Algoritmeregister. Dit doet het team op een open manier.
Die open ontwikkeling betekent dat de inhoud door de tijd heen zal wijzigen, bijvoorbeeld:
De reeds gepubliceerde beschrijving van algoritmes wordt gewijzigd en/of uitgebreid.
Een aantal overheidsorganisaties heeft op dit moment al algoritmes gepubliceerd. Het doel is om alle overheidsorganisaties met relevante algoritmes aangesloten te hebben. Uiteindelijk zal registratie ook wettelijk verplicht worden.
1.2.3 Linked Open Data
Platform Linked Data Nederland (pldn) heeft obv een aantal best practices een praktische gids voor het publiceren van linked open data gemaakt. Een 9-stappen Roadmap. Er is een eerste poging gedaan om voor het Algoritmeregister die stappen te volgen. Tot nader order is de uitwerking daarvan in de Docusaurus van regels.overheid.nl gepubliceerd. Hier te vinden: https://regels.overheid.nl/docs/linked-data/Algoritmeregister
1.3 Producten en diensten
1.3.1 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.4 Voorzieningen
Voorzieningen, bij de overheid ook wel ‘regelingen’ genoemd, zijn alle vormen van ondersteuning aan inwoners die geboden worden door nationale of gemeentelijke overheden en charitatieve instellingen. Het vindbaar maken van voorzieningen en het vereenvoudigen van het doen van een aanvraag dragen bij aan het gebruik maken van deze voorzieningen.
1.4.1 Harmonisator
In het eerste halfjaar 2022 is er een onderzoek uitgevoerd naar een Gemeentelijk Gegevenswoordenboek (GGw). Daarbij werd een grote verscheidenheid aan gegevensstructuren zichtbaar op tal van plaatsen in de informatievoorziening van de overheid. De behoefte aan "harmonisatie" van al deze modellen kwam duidelijk naar voren, waartoe het concept van de "Harmonisator" is ontwikkeld. Ook de Voorzieningen zoals bedoeld door regels.overheid.nl steunen op gegevensstructuren. Het eindverslag van dat verkennend onderzoek naar het GGw is hier te vinden.
1.4.2 MVP
We maakten een kleine Voorzieningen-applicatie en API, op grond van voorbeelden van de gemeente Vught. Zo wordt de samenhang zichtbaar tussen de aanpak van de "Harmonisator" en de ontwikkeling van een generiek bruikbare en duurzame Voorzieningen-applicatie, die aansluit op de principes en het gedachtegoed van regels.overheid.nl. De kern hiervan is dat eerst de begrippen, relaties en definities helder zijn vastgelegd, als stevig fundament voor tal van toepassingen van gegevens- en informatiegebruik.
De objecttypen en hun samenhang bij Voorzieningen. Een voorziening doorloopt een levenscyclus langs de weg: behoefte, ontwikkeling, aanbieding/promotie, aanvraag, gebruik, bijstelling en afbouw.
Gegevens van organisaties en personen (actoren) kunnen uit het generieke gegevensmodel 'Samenwerken' (coöperatie, afkorting 'co') worden gehaald.
De categorisering en clustering van voorzieningen kan volgens standaard thema-indelingen, b.v. van data.overheid.nl worden toegepast.
Het model is voorbereid op het toepassen van regels op de beschikbaarheid van een voorziening (regels.overheid.nl).
De gegevens over de rechten op een voorziening worden in de entiteit 'Voorziening_Regelset' opgenomen.
De entiteit 'Ingezetene' fungeert als (toekomstige) datakluis, mogelijk volgens principes van NL Wallet.
Figuur 2Conceptueel gegevensmodel Voorzieningen, gemaakt met Sparx EA.
1.4.3 Demo
Er is een demo-omgeving voor de voorzieningen-toepassing. Deze Scriptcase- applicatie gebruikt een kopie van de database in de ontwikkelomgeving. De structuur en inhoud kan/zal - zonder aankondiging vooraf - geregeld worden gewijzigd. Je kan dus om te testen wel records aanmaken of wijzigen maar deze worden niet definitief bewaard. Met de API kan je dan al deze gegevens ophalen, toevoegen of wijzigen.
2. Overzicht van het toepassingsprofiel
2.1 DCAT 2.0
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.
In deze 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-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 2.1) weinig. Omdat regels.overheid.nl alleen de Nederlandse overheid betreft kunnen we
meer informatie van gebruikers vragen. Daarmee worden regels beter vindbaar.
3. Wetsanalyse
Wetgeving is een belangrijk instrument om de samenleving in goede banen te leiden; het is geen doel op zich maar een middel om maatschappelijke doelen te realiseren. Om wetgeving op een effectieve, rechtmatige en uitlegbare manier te kunnen uitvoeren, moet het nodige gebeuren. Dat geldt nog sterker als in de uitvoering ICT-toepassingen worden ingezet. Uitvoeringsorganisaties van de rijksoverheid zoals het Uitvoeringsinstituut Werknemersverzekeringen, de Dienst Uitvoering Onderwijs en de Belastingdienst hebben inmiddels omvangrijke ICT-landschappen om de steeds groter wordende stroom aan beslissingen die zij nemen over burgers en bedrijven af te handelen.
Een goede vertaling van wetgeving naar de uitvoeringspraktijk vraagt om een aanpak waarbij alle stappen voor het interpreteren, preciseren en nader invullen van wetgeving expliciet en op een gestructureerde manier worden vastgelegd. Dat zorgt ervoor dat de keuzes die worden gemaakt bij het vertalen van wetgeving naar uitvoering helder zijn en dat besluiten die op grond van die keuzes worden gemaakt, uit te leggen en te verantwoorden zijn. Een ander voordeel van zo’n aanpak is dat bij wijziging van de wetgeving gemakkelijker te bepalen is welke aanpassingen nodig zijn in de ICT-systemen. Dat maakt uitvoeringsorganisaties wendbaarder bij de implementatie van wetgeving.
Wetsanalyse is een aanpak die dit ondersteunt; de beschrijving en toepassing ervan staan in dit boek centraal. Het boek bestaat uit twee delen. Het eerste deel behandelt de theorie van Wetsanalyse. Om de context te schetsen wordt in hoofdstuk 2 ingegaan op de karakteristieken van wetgeving die maken dat (het inrichten van) de uitvoering vaak bewerkelijk is. Vervolgens worden in hoofdstuk 3 de verschillende stappen in de aanpak van Wetsanalyse beschreven:
Bepalen van het werkgebied het bepalen van de scope van de wetgeving en het uitvoeringsbeleid waarop Wetsanalyse toegepast wordt, bijvoorbeeld voor het bouwen van een ICT-systeem of een uitvoeringstoets op concept wetgeving.
Zichtbaar maken van de structuur in wetgeving door het identificeren van de juridische ‘grammatica’ van wetgeving met behulp van een juridisch analyseschema.
Vastleggen van de betekenis van wetgeving door het definiëren van de begrippen voor iedere formulering in de wetgeving met de daarbij behorende eigenschappen en te maken concrete voorbeelden die de betekenis van elk begrip verduidelijken en aanscherpen.
Valideren van de analyseresultaten met behulp van concrete voorbeelden en juridische scenario’s worden de analyseresultaten uit de vorige stappen getoetst.
Signaleren van ontbrekend uitvoeringsbeleid waar interpretaties en uitvoeringsaspecten naar voren komen die nog niet in uitvoeringsbeleid zijn vastgelegd, gaat een signaal naar de verantwoordelijken zodat dit alsnog gebeurt. Dit is essentieel voor de rechtmatigheid van elke beslissing of berekening. Alles moet terug te voeren zijn op wetgeving of officieel vastgesteld uitvoeringsbeleid.
Opstellen van het kennismodel ondersteund door modelleervaardigheden wordt de betekenis van de wetgeving en het uitvoeringsbeleid overzichtelijk en samenhangend vastgelegd in een model, zodat deze kennis beschikbaar is voor implementatie in de uitvoeringspraktijk.
Hoofdstuk 4 behandelt het juridisch analyseschema dat gebruikt wordt bij Wetsanalyse en waarin verschillende juridische elementen die in wetgeving voorkomen in samenhang gerangschikt zijn. Deze elementen vormen de klassen die bij Wetsanalyse aan formuleringen in de wetgeving worden toegekend. Het indelen van formuleringen in juridische klassen biedt ondersteuning bij het expliciet maken van de betekenis van die formuleringen. Hoofdstuk 5 gaat in op de multidisciplinaire samenwerking tussen juristen, informatieanalisten en ICT-ontwikkelaars die essentieel is voor een optimaal resultaat van Wetsanalyse. Zij voeren aan de hand van concrete voorbeelden en scenario’s steeds samen het gesprek over de uitkomsten van de analyse en de interpretatie die daarbij aan de wetgeving is gegeven. Dit is van groot belang voor de kwaliteit van de analyse en daarmee voor de juistheid van de uiteindelijke uitvoering van de wetgeving. In hoofdstuk 5 worden ook enkele aanbevelingen gedaan voor succesvolle toepassing en implementatie van Wetsanalyse.
Het tweede deel van het boek bestaat uit twee grote casus waarin de praktische toepassing van Wetsanalyse wordt getoond. In hoofdstuk 6 wordt de inkomensafhankelijke bijdrage in artikel 43 Zorgverzekeringswet (Zvw) uitgewerkt. Deze bijdrage wordt geheven door de Belastingdienst. Voor hoofdstuk 7 is uitwerking van het wetsvoorstel Modernisering elektronisch bestuurlijk verkeer (afdeling 2.3 Awb) gekozen. Dit wetsvoorstel zorgt voor aanpassing van de regels voor digitale communicatie tussen burgers en overheid aan de eisen van de tijd. Deze verschillende casus laten zien dat Wetsanalyse op zowel algemene als domeinspecifieke wetgeving toepasbaar is, en zowel op bestaande wetgeving als op wetgeving in wording.
Met dit boek wordt beoogd de aanpak voor Wetsanalyse breed bekend te maken voor iedereen die in werk of studie te maken heeft met toepassing of uitvoering van wetgeving. Hoewel de nadruk ligt op digitale uitvoering van wetgeving bij uitvoeringsorganisaties van de rijksoverheid, kan het ook van waarde zijn in het juridisch en informatiekundig onderwijs op hogescholen, universiteiten en postacademische opleidingen. Het doel is steeds een brug te slaan tussen de taal van juristen en de techniek van de ICT.
3.1 Uitnodiging om bij te dragen
Het boek beschrijft de aanpak en toepassing van Wetsanalyse naar de stand van begin 2021. Wetsanalyse zal echter zich blijven vernieuwen onder invloed van ontwikkelingen in wetgeving, rechtstoepassing en technologie. De lezers worden nadrukkelijk uitgenodigd om met Wetsanalyse aan de slag te gaan en ervaringen en ideeën te delen, om zo samen te werken aan het verfijnen en doorontwikkelen van Wetsanalyse. Net zoals samenwerking essentieel is in de concrete toepassing van Wetsanalyse: steeds multidisciplinair en stapsgewijs.
3.2 Regelspraak
De taal voor het vastleggen van regels die direct omgezet kunnen worden in werkende software. Één van de pijlers van wendbare wetsuitvoering.
3.3 ALEF
De Belastingdienst heeft in het kader van het agile toepassen van de wet een tool ontwikkeld voor het opstellen en toetsen van regels. Het opstellen van de regels gebeurt op basis van bestaande specificaties of code, maar idealiter (en ook steeds vaker) worden hiervoor de resultaten van de Wetsanalyse gebruikt.
Deze tool heet ALEF (Agile Law Execution Factory) en is gebaseerd op Jetbrains MPS. In ALEF worden specificaties opgesteld in samenwerking met de domeinexperts. Deze specificaties bestaan uit regels, datadefinities en testgevallen. Dit wordt zoveel mogelijk door de domeinexperts zelf gedaan. De regels zijn opgesteld in de taal RegelSpraak. Dit is een gecontroleerde Nederlandse taal die zowel voor juristen als voor computersystemen goed leesbaar is.
Issue 1: Make DCAT application profile suitable for metadata ALEF specifications documentation documentationquestion
Een TNO programma dat werkt aan theoretische modellen voor normatieve systemen en de praktische toepassing daarvan, ondersteund met prototypes voor technische ondersteunen op basis van open standaarden en open source software.
De basis van het programma bestaat uit een protocol voor het uitvoeren van normatieve taken (Calculemus) en een expliciete normatieve taal om interpretaties van juridische bronnen vast te leggen (Flint). Flint is ontwikkeld om in de toepassing van normen in het sociale, ethische en juridisch domein te representeren op een wijze die normen begrijpelijk maak voor mensen, en geschikt voor automatisch redeneren door machines.
De aanpak is actie-georiënteerd (normen worden gebruikt om gedrag te reguleren) en richt zich op het zo expliciet mogelijk beschrijven van de interpretatie van bij een normatief vraagstuk betrokken partijen. Het herkennen en oplossen van meningsverschillen maakt nadrukkelijke deel uit van de aanpak.
De methode wordt onder meer toegepast om:
praktische juridische kaders te ontwikkelen voor maatwerk in dienstverlening,
het versterken rechtspositie burgers in bestuursrechtelijke procedures,
kennisuitwisseling mogelijk maken tussen organisaties die gebruik maken van verschillende methoden voor het representeren en gebruiken van normen en regels.
Flint is een actie-gerichte interpretatiemethode waarin normen worden uitgedrukt als handelingen, feiten of plichten. Flint is ontwikkeld om alle toestanden en toestandsovergangen waarin normen een rol spelen expliciet te kunnen beschrijven met een referentie naar gebruikte bronnen.
FLINT-frames zijn geen regels, hoewel FLINT-frames (relatief losse/informele/op natuurlijke taal gebaseerde) interpretaties van voorschriften kunnen vertegenwoordigen.
We onderzoeken met welke metadata een Flint interpretatie van de wettelijke grondslag(en) die bij de producten en diensten horen kan worden beschreven.
RuleSpeak® is een verzameling richtlijnen voor het formuleren van bedrijfsregels op een bedrijfsvriendelijke en precieze manier. Het is geen taal of syntax maar eerder een verzameling voorschriften voor Nederlandstalige formulering van bedrijfsregels gebaseerd op ervaringen in de praktijk.
Bedoeling:
Het vergroten van de helderheid en consistentie in het communiceren van regels tussen mensen uit de bedrijfspraktijk of als eisen (requirements) voor de ontwikkeling van IT systemen.
Het effectief verkrijgen, verwoorden en behouden van bedrijfskennis en criteria om beslissingen te nemen.
De kern is Expliciete declaratieve regels. Business logica is niet een proces maar onafhankelijk van de volgorde en een evaluatie van de feitelijk toestand. Wij kijken naar de feiten van een situatie en wat de (juridische) gevolgen van die feitelijke situatie is. Het grootste voordeel is dat grote complexiteit daarmee aangepakt kan worden, en je de, gebruikelijke, procesmatige stap voor stap bouwaanpak vermijdt.
4. Klassen
In dit hoofdstuk worden de klassen van het applicatieprofiel benoemd en beschreven.
4.1 Introductie
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.
4.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 "distributieklasse" aanbieden om te beschrijven:
functionele ontwerpen / koppelingen naar functionele ontwerpen in een Github-register (documentatie)
algoritmes / code / applicaties waar regels worden uitgevoerd, gepubliceerd in een Github-register (uitvoering)
Het is belangrijk om vast te stellen: wat wordt opgeslagen/beschreven als onderdeel van de "regelset" 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 regelsetbeschrijving.
Elke regelset heeft een URI nodig die kan worden gebruikt om te linken in openbare communicatie/brieven.
5. Waardelijsten
Binnen dit toepassingsprofiel worden de onderstaande waardelijsten toegepast.
6. Conformiteit
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.
