search

Geonovum / dcat2-ap-nl

DCAT-AP-NL
0 stars 0 forks source link

Voorstel: Onderzoekje of het vastleggen van het profiel in een technisch formaat mogelijk en wenselijk is #1

Open keestrautwein opened 1 year ago

keestrautwein commented 1 year ago

Zoals vanmiddag bij de kick-off besproken, wordt ons profiel in een RESPEC document vastgelegd. In de werkgroep DCAT-AP-DONL is de RESPEC met de hand geschreven, maar bleek uiteindelijk dat er behoefte was aan een meer gestructureerde aanpak. Met name bleken herhalende beschrijvingen zoals van attributen en classes moeilijk consequent uit te houden. Met enig kunst- en vliegwerk en veel handwerk is dat gelukt.

In de (later gestarte) "PLDN Werkgroep Nederlands profiel voor stelselcatalogi" is hetzelfde probleem opgelost door een deel van de specificatie vast te leggen in SHACL en SKOS. Uit deze technische bestanden en de gebruikelijke tekstuele bestanden wordt één RESPEC gegenereerd. De RESPEC is beschikbaar zoals gebruikelijk en de gegenereerde tabellen, etc zijn niet te onderscheiden van handmatig gemaakte tabellen. Behalve dat consistentie op deze manier eenvoudiger te verwezenlijken is, is een voordeel dat de oplevering behalve een tekstuele beschrijving ook SKOS en SHACL beschrijvingen bevat, die machine-leesbaar zijn en gebruikt kunnen worden door partijen die met het profiel willen werken.

In onze DCAT werkgroep zitten mensen die nauw betrokken zijn bij de generatie van de RESPEC van de "PLDN Werkgroep Nederlands profiel voor stelselcatalogi" . We zouden hen kunnen vragen of de tooling die daar gebruikt wordt ook voor onze DCAT werkgroep geschikt zou zijn.

Merk op dat de formele oplevering van DCAT-APv2.1.1 door SemicEU is voorzien van SHACL en andere Linked Data bestanden. Die zouden mogelijk als basis kunnen dienen voor bestanden in ons profiel.

Een tweede optie om de documentatie te genereren is volgens de Semic Style Guide (op Github). In deze grondig beschreven methode wordt een afgebakende subset van UML gebruikt om een model dan wel profiel te beschrijven waaruit met tooling allerlei documentatie gegenereerd kan worden, waaronder OWL en HTML bestanden. Hoe goed dit aan sluit bij RESPEC (of MIM) is mij op dit moment niet duidelijk.

Samenvattend:

De voordelen:

De nadelen:

Twee vragen:

Eerste vraag is: Lijkt het de werkgroep en vooral de verantwoordelijken een goed idee om een deel van de RESPEC te generen?

Zo ja, dan is de tweede vraag: Is het een goed idee om in een klein groepje kort te onderzoeken of dat mogelijk is? En wie willen daar deel van uitmaken? Aan de hand van de bevindingen van dit "onderzoeksgroepje" besluiten we dan of deze optie voor deze werkgroep de moeite waard is.

Bakkej commented 1 year ago

Aanvullend is het wellicht ook interessant data.vlaanderen eigenlijk dezelfde methode toepast voor het opstellen van profielen en andere data standaarden. Bijvoorbeeld bij DCAT-AP-VL Hier wordt de OSLO-Toolchain gebruikt om op basis van een UML model, een specificatie document te genereren (HTML) en daarbij ook een RDF representatie. Hoe dat precies werkt kan hier gelezen worden.

Wat je hiermee voorkomt is wat Kees ook al aangeeft en wat SEMIC in haar Style Guide de Editorial Synchronisation Problem noemt (erg interessant document). Hoe dit verder allemaal werkt bij semic staat beschreven in de toolchain manual

Daarnaast is dit ook iets waar MIM sterk in is. Daarmee zijn bijvoorbeeld delen van de volgende specificatiedocumenten gegenereerd:

Deze vier zijn met behulp van imvertor gegenereerd.

Er zijn ook nog andere tools zoals:

Deze laatste twee zijn voor de "PLDN Werkgroep Nederlands profiel voor stelselcatalogi" gebruikt.

keestrautwein commented 9 months ago

Zojuist vond ik bij Digilab een DCATv2 validator geschreven in SHACL op https://gitlab.com/digilab.overheid.nl/ecosystem/dcat-v2-validator en genoemd op de Digilab webpagina: https://digilab.overheid.nl/docs/ecosysteem/dcat-v2-validator/. De meest recente update van de validator is vorige maand.

Ik heb nog niet uitgezocht waar deze validator precies op gebaseerd is. Er is sprake van zowel DCATv2, als DCAT-AP als DCAT-AP-NL. Ik vermoed gegeven het bestaan van de DCAT-AP validator dat die als basis is gebruikt, o.a. omdat er een bestand dcat2-ap-eu-shacl.ttl wordt gebruikt.

Het ontwikkelen van een SHACL bestand voor DONLv2-AP-NL gaat waarschijnlijk veel sneller als we ons op bestaand werk kunnen baseren. Maar zoals gezegd heb ik nog niet gekeken naar de kwaliteit van dit bestand of het eerdere genoemde SIMEC bestand.

idevisser commented 8 months ago

Ik heb intern (Pano) gevraagd wat de opties zijn.

Zoals jullie ook noemen is een optie om vanuit MIM SHACL aan te maken. Nadeel daarvan is dat er geen bestaande vocabulaires hergebruikt kunnen worden, wat juist bij DCAT wel het geval is. In de volgende versie van MIM wordt er wel een stap gezet in deze richting om dit mogelijk te maken, maar dat gaat nog niet ver genoeg om dit volledig op te lossen. Verwachting is dat dit pas eind volgend jaar het geval is.

Andere optie is uit de (EU) SHACL de tabellen voor in respec genereren, zoals bij het NL profiel voor stelselcatalogi. Dit kan met github actions worden uitgevoerd. Geonovum gaat binnenkort het beheer hier van doen. Ook dit is nog niet direct te gebruiken, maar met enige aanpassingen en goed inrichten versiebeheer wel te gebruiken. De EU SHACL shapes worden hiervoor handmatig aangepast conform het NL profiel. Die kunnen dan voor validatie gebruikt worden.

sgort commented 2 weeks ago

LS, Wat is laatste stand van zaken hieromtrent, mede irt v3 onderweg https://docs.geostandaarden.nl/dcat/dcat-ap-nl30/ ?

PS De vraag omdat ik onderzoek of en zo ja, hoe een DCAT validatie valt toe te passen voor óók een DCAT AP voor regelspecificatie sets (ie https://regels.overheid.nl/publicaties/dcat-ap-ronl)