Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Organisatie #29 #23

Open
fterpstra opened this issue Oct 31, 2024 · 0 comments
Open

Organisatie #29 #23

fterpstra opened this issue Oct 31, 2024 · 0 comments
Assignees
Labels
enhancement New feature or request PLDN issue gemigreerd uit PLDN github

Comments

@fterpstra
Copy link
Contributor

pldn/nederlands-profiel-voor-stelselcatalogi#29

GeraldGrootRoessink commented on Jun 4, 2022
Vanuit de sessies "Metadata" (zie https://github.com/pldn/nederlands-profiel-voor-stelselcatalogi/tree/main/sessies/metadata) een uitzoekpunt: welke organisatierollen onderkennen we bij het opstellen van een begrippenkader en hoe duiden we die aan met properties?

Eerste idee: gebruik de rollen zoals onderkend bij de basisregistraties (niet de afnemer):

Opdrachtgever: het verantwoordelijke ministerie
Toezichthouder: wie toetst compliance/adherence eisen, afspraken en wetten?
Bronhouder: verantwoordelijk voor inwinnen, instand houding en kwaliteit
Verstrekker: verantwoordelijk voor ter beschikking stellen aan afnemer en service daaromtrent
Overigens, de huidige draft van DCAT 2.0 heeft het alleen over Publisher en Creator, die, denk ik, samenvallen met Verstrekker respectievelijk Bronhouder hierboven.

Ten tweede, een stelling:
Als een begrippenkader betrekking heeft op de gegevens in de registratie dan is de bronhouder van de registratie verantwoordelijk voor een goede beschrijving van de gegevens, dus ook voor de begrippen. De verstrekker van de registratie maakt vervolgens een mooi gegevensproduct voor een afnemer. Het is niet de bedoeling dat de verstrekker daarbij een nieuwe taal uitvindt. Bij het maken van een gegevensproduct kan het begrippenkader aan scherpen, maar alleen de bronhouder is bevoegd om dat door te voeren. Dus de bronhouder van het begrippenkader is per definitie gelijk aan de bronhouder van het register.

De organisatierollen van Toezichthouder en Opdrachtverstrekker zijn registerverantwoordelijkheden en geen begrippenkaderverantwoordelijkheden.

Als derde een opmerking over de verstrekker van het begrippenkader. Het is in niet ongewoon dat Logius de begrippen van een basisregistratie publiceert. Nog een stelling: voor een begrippenkader is dat de enige rol die expliciet gemaakt hoeft te worden. De property ligt voor de hand: dct:publisher.

@CasperKoop
Contributor
CasperKoop commented on Jun 13, 2022
In het laatste overleg hebben we besproken dat dct:publisher inderdaad gebruikt gaat worden.

Daarnaast gebruiken we Qualified Attribution waarin de rol van de organisatie toegevoegd moet worden. Dat wil zeggen prov:agent voor de organisatie en dcat:hadRole voor de rol, zie voorbeeld.

Dat betekend dat we de volgende situatie hebben voor de door Gerald beschreven rollen:

Organisatie Rol
Opdrachtgever prov:qualifiedAttribution met rol Funder
Toezichthouder prov:qualifiedAttribution met rol Custodian
Bronhouder prov:qualifiedAttribution met rol Owner
Verstrekker dcat:publisher
dct:creator gebruiken we niet, dat is een proces binnen de bronhouder. Zoals bv bij basisadministraties de gemeentes.

@RiX012
RiX012 commented on Jul 14, 2022
Op zich een prima uitwerking. We moeten wel scherp zijn op ons uitgangspunt dat we er niet te veel ontologiën bijslepen. Dus kijken op prov en dcat echt nodig zijn.

@pmaria
Collaborator
pmaria commented on Jul 14, 2022
Ik mis hier een abstractere beschrijving (dus nog zonder binding naar RDF vocabulaires) van hoe dit model eruit gaat zien.
Zonder dit vind ik het lastig te beoordelen.

@architolk architolk assigned ArjenSantema and keestrautwein on Aug 4, 2022
@architolk architolk added the bug label on Aug 4, 2022
@architolk
Collaborator
architolk commented on Aug 4, 2022
In de werkgroep van Kees is dit uitgewerkt, nu aan Arjen om door te voeren.

@RiX012
RiX012 commented on Jan 27, 2023
Zou van mij best een enhancement mogen zijn inderdaad

@Bakkej Bakkej added enhancement and removed bug labels on Feb 2, 2023

@fterpstra fterpstra added enhancement New feature or request PLDN issue gemigreerd uit PLDN github labels Oct 31, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request PLDN issue gemigreerd uit PLDN github
Projects
None yet
Development

No branches or pull requests

3 participants