Geonovum / DCAT-AP-NL30

dcat3-ap-nl
2 stars 2 forks source link

INHOUDELIJK: Toevoegen URL Open Source Code repositories bij DataService #115

Closed ehotting closed 1 month ago

ehotting commented 2 months ago

Aangezien we als overheid in principe Open Source werken aan alle nieuwe software, lijkt het mij goed om daar een property voor op te nemen. (goeie description, en URL naar de repo)

Dit biedt tevens de mogelijkheid voor bijv. developer.overheid.nl (@dvh) om automatisch die repository op te nemen in de lijst van open source repositories etc.

idevisser commented 2 months ago

Graag even verduidelijking, ik vraag me af of een verwijzing naar de repo voor software toegevoegd kan worden als property van metadata van datasets en dataservices. Aan welke klasse zou je een property willen toevoegen? Kun je een voorbeeld geven?

ehotting commented 2 months ago

Klasse DataService lijkt me, maar ik ben geen specialist.

dvh commented 2 months ago

Het past inderdaad uitstekend in het rijtje met andere metadata over de DataService, zoals publisher.

@ehotting ik zou misschien wel ergens "open" in verwerken, want om naar gesloten repositories verwezen te worden voegt weinig waarde toe:

ehotting commented 2 months ago
  • Cardinality 0..n (moet dit niet 0..1 zijn?)

Lees het als snel voorbeeld / suggestie. Redenering is dat het nogal afhankelijk is van het team of men in een monorepo werkt of een hele reeks repositories heeft om een service de lucht in te helpen.

(Ook mijn link naar een repo is niet goed in dit voorbeeld, omdat dit een beschrijving is van de metadata zelf - was slechts bedoeld om een voorbeeld van een repo te geven die onderliggend is aan een DataService)

idevisser commented 2 months ago

Ik ben nog wel een beetje zoekende of dit past binnen het profiel. Als we dit willen toevoegen moeten we nog wat scherper krijgen wat het doel is om te verwijzen naar de repo. Kan de software door anderen worden hergebruikt zodat ze zelf API's kunnen aanbieden? Of gaat het meer om de eigenschappen van de API zodat de gebruiker weet wat hij moet vragen en wat hij terug krijgt? Staat dat dan niet in de specificatie van de API, of gebruik je de repo als specificatie? Willen we voor dataservices (en dan ook voor datasets en distributies) verwijzen naar software?

We gebruiken in het profiel bij voorkeur bestaande properties. Kunnen jullie eens kijken naar https://docs.geostandaarden.nl/dcat/dcat-ap-nl30/#dataservice-endpoint-description, https://docs.geostandaarden.nl/dcat/dcat-ap-nl30/#dataservice-application-profile, https://docs.geostandaarden.nl/dcat/dcat-ap-nl30/#dataservice-documentation en https://docs.geostandaarden.nl/dcat/dcat-ap-nl30/#dataservice-landing-page of het daar onder kan vallen?

groet Ine

idevisser commented 1 month ago

@ehotting @dvh kunnen jullie een reactie geven op mijn vragen?

ehotting commented 1 month ago

Vanuit de beleidslijn om Open Source te bevorderen is het nodig om deze Open Source code te 'discoveren'. Het is nu nergens aan op te hangen. Door een link naar de repo's op te nemen die de API's realiseren kunnen allerlei op discovery gebaseerde functionaliteiten worden gebouwd - o.a. de twee voorbeelden van doelen die je beschreef. Wat mij betreft moet je andersom denken: door het mogelijk te maken ontstaat het gebruik.

Naast de door jou genoemde voorbeelden voor gebruik denk ik ook aan transparantie, een belangrijke reden voor de overheid om aan te sturen op Open Source: domweg laten zien hoe het precies werkt.

idevisser commented 1 month ago

Het bevorderen van Open Source is een goed initiatief, maar dit valt buiten de scope van deze standaard. DCAT-AP-NL is voor het uitwisselen van metadata over data en data services, zodat deze gebruikt kunnen worden. Met welke software de datasets en dataservices zijn gemaakt, is niet van belang voor het gebruik van de data en dataservices. Wellicht past dit beter bij developper