Omschrijving
Disclaimer: Voor Common Ground ben ik bezig om het Cloud Events te introduceren in het ICT landschap van gemeenten, en dan met name voor zaakgericht werken API's en gerelateerde API's (producten, organisatie, klantprofiel, etc.)
In de documentatie staan op verschillende plekken voorbeelden van URNs genoemd, bijvoorbeeld voor de source:
urn:nld:oin:00000001823288444000:systeem:BRP-component
urn:nld:kvknr:09220932.burgerzakensysteem
urn:nld:gemeente-nijmegen.burgerzakensysteem
urn:nld:gemeente-Bergen%20%28L%29.burgerzakensysteem
(ik zie overigens "." staan ipv ":" soms, weet niet zeker of dat de bedoeling is)
Ikzelf heb grote behoefte aan enige uitspraken over het gebruik van URNs. Het enige dat in de NL GOV profile staat is "SHOULD be a URN notation with 'nld' as namespace identifier.", dus zelfs het "nld" stukje is niet gestandaardiseerd.
Wellicht moet het uitgesplitst worden in verschillende issues, maar voor nu zet ik ze even hieronder:
1. Wat wordt de structuur van een URN voor bepaalde scenario's?
We hadden zelf onderstaande structuur bedacht, die (gelukkig) redelijk lijkt aan te sluiten bij de voorbeelden:
organisatie geeft aan bij wie het staat (idealiter vaste lijst)systeem geeft aan waar je het kunt ophalen (flexibel)component geeft aan in welk component de resource zit (idealiter vaste lijst, uit GEMMA/NORA) - Na discussie toegevoegd. In eerste instantie zou deze af te leiden zijn uit de resource maar er zijn wellicht toch kans op duplicaties dat wordt voorkomen met dit attribuut.resource geeft aan wat het is (idealiter vaste lijst, uit GEMMA/NORA)identificatie geeft aan hoe je dit specifieke item ophaalt (flexibel)
Maar dit is nog aan verandering onderhevig en niet alle elementen zouden verplicht zijn.
2. Erkennen van URN aliassen
Bijvoorbeeld als een gemeente een RSIN, KVK en OIN nummer heeft, zijn verschillende waarden van source mogelijk die naar dezelfde organisatie wijzen. Dit is lastig als je je "abonneert" op events die source meenemen. Je kan dan events missen als een alias gebruikt wordt.
Volgens mij is niet mogelijk om te standaardiseren op 1 type nummer. Dus laten we dit erkennen en beschrijven hoe we hiermee omgaan.
Voorbeeld: Verwijzen naar een persoon of organisatie
Bij het opstellen van een voorbeeld waar je beide punten hierboven terug ziet komen, is het verwijzen naar personen of organisaties:
Natuurlijk Persoon (landelijk register)
urn:nld:brp:bsn:<nummer>urn:nld:rni:bsn:<nummer>
Niet Natuurlijk Persoon (landelijk register)
urn:nld:hr:kvknummer:<nummer>urn:nld:hr:kvknummer:<nummer>:vestigingsnummer:<nummer>urn:nld:hr:rsin:<nummer>urn:nld:oinr:oin:<nummer>urn:nld:oinr:oin:<nummer>:suboin:<nummer>urn:nld:rior:rio:<nummer>
Partij (lokaal register bij gemeente, Open Klant)
urn:nld:rsin:00000001823288444000:kcc:kic:partijnummer:<nummer>
Betrokkene (lokaal register bij gemeente, Open Klant)
urn:nld:rsin:00000001823288444000:kcc:kic:betrokkenenummer:<nummer>
Medewerker (lokaal register bij gemeente, Open Organisatie)
urn:nld:rsin:00000001823288444000:org:or:medewerkernummer:<nummer>
Naam
Joeri Bekker
Email
No response
Organisatie
Maykin
Omschrijving
Disclaimer: Voor Common Ground ben ik bezig om het Cloud Events te introduceren in het ICT landschap van gemeenten, en dan met name voor zaakgericht werken API's en gerelateerde API's (producten, organisatie, klantprofiel, etc.)
In de documentatie staan op verschillende plekken voorbeelden van URNs genoemd, bijvoorbeeld voor de
source:(ik zie overigens "." staan ipv ":" soms, weet niet zeker of dat de bedoeling is)
Ikzelf heb grote behoefte aan enige uitspraken over het gebruik van URNs. Het enige dat in de NL GOV profile staat is "SHOULD be a URN notation with 'nld' as namespace identifier.", dus zelfs het "nld" stukje is niet gestandaardiseerd.
Wellicht moet het uitgesplitst worden in verschillende issues, maar voor nu zet ik ze even hieronder:
1. Wat wordt de structuur van een URN voor bepaalde scenario's?
We hadden zelf onderstaande structuur bedacht, die (gelukkig) redelijk lijkt aan te sluiten bij de voorbeelden:
organisatiegeeft aan bij wie het staat (idealiter vaste lijst)systeemgeeft aan waar je het kunt ophalen (flexibel)componentgeeft aan in welk component de resource zit (idealiter vaste lijst, uit GEMMA/NORA) - Na discussie toegevoegd. In eerste instantie zou deze af te leiden zijn uit deresourcemaar er zijn wellicht toch kans op duplicaties dat wordt voorkomen met dit attribuut.resourcegeeft aan wat het is (idealiter vaste lijst, uit GEMMA/NORA)identificatiegeeft aan hoe je dit specifieke item ophaalt (flexibel)Maar dit is nog aan verandering onderhevig en niet alle elementen zouden verplicht zijn.
2. Erkennen van URN aliassen
Bijvoorbeeld als een gemeente een RSIN, KVK en OIN nummer heeft, zijn verschillende waarden van
sourcemogelijk die naar dezelfde organisatie wijzen. Dit is lastig als je je "abonneert" op events diesourcemeenemen. Je kan dan events missen als een alias gebruikt wordt.Volgens mij is niet mogelijk om te standaardiseren op 1 type nummer. Dus laten we dit erkennen en beschrijven hoe we hiermee omgaan.
Voorbeeld: Verwijzen naar een persoon of organisatie
Bij het opstellen van een voorbeeld waar je beide punten hierboven terug ziet komen, is het verwijzen naar personen of organisaties:
Natuurlijk Persoon (landelijk register)
urn:nld:brp:bsn:<nummer>urn:nld:rni:bsn:<nummer>Niet Natuurlijk Persoon (landelijk register)
urn:nld:hr:kvknummer:<nummer>urn:nld:hr:kvknummer:<nummer>:vestigingsnummer:<nummer>urn:nld:hr:rsin:<nummer>urn:nld:oinr:oin:<nummer>urn:nld:oinr:oin:<nummer>:suboin:<nummer>urn:nld:rior:rio:<nummer>Partij (lokaal register bij gemeente, Open Klant)
urn:nld:rsin:00000001823288444000:kcc:kic:partijnummer:<nummer>Betrokkene (lokaal register bij gemeente, Open Klant)
urn:nld:rsin:00000001823288444000:kcc:kic:betrokkenenummer:<nummer>Medewerker (lokaal register bij gemeente, Open Organisatie)
urn:nld:rsin:00000001823288444000:org:or:medewerkernummer:<nummer>Naam
Joeri Bekker
Email
No response
Organisatie
Maykin