Het wijzigingsdocument van RSGB3.0 is online te vinden bij de expertgroep Informatiemodellen op GemmaOnline (nl. bij het Eerstvolgend overleg staat het vergaderstuk 20150603 Wijzigingen RSGB 3.0. versus RSGB 2.0.zip).
Het wijzigingsdocument van RSGB3.0 staat op de agenda van de eerst volgende bijeenkomst van de expertgroep Informatiemodellen, namelijk op donderdag 25 juni. Het doel is om tijdens die bijeenkomst RSGB 3.0 goed te keuren. Eventuele op- en aanmerkingen kunnen uiterlijk 19 juni 2015 op het discussieplatform geplaatst worden in het Subforum Werkgroep RSGB3.0.
Vraagje: in het wijzigingsdocument wordt regelmatig als formaat DatumMogelijkOnbekend gegeven. Waarschijnlijk komt dit uit de voorstellen vanuit project Utrecht, maar ik ben even kwijt wat nu de betekenis is van dit formaat. Is het niet gewoon een datum die optioneel is (kan onbekend zijn)?
Ik ga in mijn reactie hier zowel in op je bovenstaande vraag als op de post die je geplaatst hebt t.a.v Semantische basis voor "geen waarde" (StUF:noValue)
In het project Utrecht wordt DatumMogelijkOnvolledig onderkend. Het betreft een datum waarvan de dag, de maand en het jaar bekend zijn, of alleen de maand en het jaar of alleen het jaar. In BRP komen we daarnaast DatumMetOnzekerheid tegen. Een voorbeeld is het attribuut overlijdensdatum met datatype DatumMetOnzekerheid. Dit is een optioneel attribuut in de BRP maar als dit attribuut is ingevuld weten we dat de persoon overleden is. Soms is niet te achterhalen wanneer de persoon precies overleden is, zelfs niet in welk jaar maar men weet wel dat de persoon overleden is op basis van bijvoorbeeld een overlijdensakte waarvan de overlijdensdatum niet meer te lezen is. In feite is dus ook het jaar niet bekend. DatumMetOnzekerheid bevat in de BRP dan allemaal nullen. Het betreft de situatie zoals ook beschreven is in rij 5 op pagina 6 van het document 'GAB omgaan met geen waarde'. In hetzelfde document wordt ook gesproken over een persoon die is overleden, maar waarbij er niets gezegd wordt over de datum waarop dat is gebeurd. Er bestaat dus wel een datum (een gangbare waarde), maar die is niet bekend of hierover zegt de leverende instantie niets (situatie 2, pagina 5). Ik neem aan dat hiermee bedoeld wordt dat de exacte datum niet bekend is maar alleen het jaar of de maand en het jaar. Dan wordt DatumMetOnzekerheid gevuld met alleen het jaar of maand en jaar.
Wij hebben in het RSGB gekozen voor het introduceren van het datatype DatumMogelijkOnbekend i.p.v. DatumMet Onzekerheid omdat dit meer in afstemming is qua naamgeving met DatumMogelijkOnvolledig.
Ik denk dat ik hiermee ook een deel van je vraag heb beantwoord t.a.v. de vraag die je in de andere post hebt geplaatst t.a.v de de waarden "waardeOnbekend", "geenWaarde" en "vastgesteldOnbekend zoals in StUF wordt onderscheiden.
In de catalogussen van de BR's kom je ook weleens tegen dat een gegeven de waarde onbekend of overig heeft. Voorbeeld is geslacht in de BRP. Dit attribuut is verplicht en kan de waarde man, vrouw of onbekend bevatten. In hoeverre StUF hiermee iets doet weet ik niet. Voor het RSGB hebben we ervoor gekozen om hierin de basisregistraties te volgen.
Verder ben ik nergens in het stelsel van basisregistraties tegengekomen dat er op semantisch niveau onderscheid wordt gemaakt in de waardeOnbekend", "geenWaarde" en "vastgesteldOnbekend.
En ik zou niet weten hoe ik dit op basis van de beschikbare informatie moet afleiden t.b.v. het RSGB.
Als ik jouw beschrijving van de beide types lees, dan zie ik geen reden hierin onderscheid te maken. In beide gevallen is er een datum (het is bekend dat er een datum is), maar is mogelijk niet bekend welke dag, (dag en) maand of zelfs het jaartal er in die datum staan. Moeten we dan niet één en hetzelfde type gebruiken?
Met betrekking tot de discussie over het ontbreken van een waarde: mijn conclusie is dan nu dat deze verschillende mogelijkheden binnen RSGB en dus binnen StUF-BG niet gebruikt worden. Waar relevant, zijn er in de domeinen zelf al waarden opgenomen voor het weergeven van het niet beschikken over een waarde. Dit kan dan worden meegenomen in de verStUFfing van het RSGB en moet dan bij de StUF-expertgroep worden ingebracht. Die discussie kan dan hier gesloten worden.
Er is m.i. wel degelijk een onderscheid . DatumMogelijkOnvolledig is altijd een periode volgens de Gregoriaanse kalender. En is als volgt gespecificeerd. Zie tabel hieronder waarbij iIn de 1e kolom het datatype staat, de 2e kolom de betekenis en 3e kolom hoe dit in xml te vertalen is (bron project Utrecht)
Keuze (minimaal en maximaal 1) uit de XML-Schema ‘primitive datatypes’:
xs:date
xs:gYearMonth
xs:gYear
Bij DatumMogelijkOnbekend zeggen hebben we het niet over de gregoriaanse kalender maar hebben we het over yyyy-mm-dd waarbij dd met nullen gevuld kan zijn als de dag onbekend is, mm-dd met nullen gevuld kan zijn als de maand onbekend is, yyyy-mm-dd met nullen gevuld is als het jaar onbekend is. In feite een veld met formaat N8 zoals dit ook al binnen de GBA werd toegepast voor overlijdensdatum e.d. maar in de BRP nu door expliciet is gemaakt door DatumMetOnzekerheid. Hoe dit vertaald wordt binnen StUF weet ik niet precies maar dan zal men waarschijnlijk wel gebruik gaan maken van waarde onbekend of vastgesteld onbekend in combinatie met een datumveld conform de gregoriaanse kalender.
Voor alle gegevens die altijd een waarde moeten hebben, bijv. Geboortedatum, is de waarde 'geenWaarde' niet mogelijk. Er zij ook gegevens waarbij de waarde 'geenWaarde' wel relevant is. Denk aan een overlijdensdatum, voorvoegsel geslachtsnaam en soms ook voornamen, een telefoonnummer, emailadres, bankrekeningnummer e.d. Als je een en ander gaat analyseren dan zou je in het RSGB kunnen specificeren of het onderscheid tussen geenWaarde en waardeOnbekend relevant is (overlijdensdatum) en zo niet wat de interpretatie van het ontbreken moet zijn: geenWaarde voor bijv. Voorvoegsel en waardeOnbekend voor bijv. Telefoonnummer. Zolang het RSGB een dergelijke analyse niet bevat, dient met het oog op de interoperabiliteit dit onderscheid in de berichten op de door StUF voorgeschreven manier gemaakt te kunnen worden
Het verschil wat je hier aan geeft is m.i. alleen een verschil in implementatie van wat semantisch hetzelfde is: het is een datum/periode van een dag, een maand, een jaar of zelfs een oneindige periode. Dat je die in het geval van de GBA weergeeft door nullen in te vullen voor de niet-significante delen van het gegeven en het in het andere geval weergeeft door een attribuut is semantisch niet interessant.
In mijn ogen verlies je je hier in implementatiedetails en creëer je daardoor twee varianten voor semantisch hetzelfde. De argumenten die je in je reactie noemt hebben allen te maken met implementatie en niet met semantiek. Ze beide formaten zijn volgens mij perfect uitwisselbaar, zonder verlies van semantiek.
Voor alle duidelijkheid, mijn reactie hierboven verwijst naar de meest recente reactie van Ellen en niet op die van Maarten waar hij onder terecht is gekomen.
Na het overleg van de expertgroep informatiemodellen van gisteren is het tot mij doorgedrongen dat Ellen en Remko ervan uit gaan dat een DatumMogelijkOnvolledig altijd minimaal een jaar moet hebben (of ik moet het toch verkeerd begrepen hebben). Als dat zo zou zijn, dan moet ik toegeven dat de semantiek van beide types verschillend is. Naar mijn mening is dat echter niet zoals het bedoeld is in de voorstellen van project Utrecht.
Nu weet ik inmiddels niet waar ik de definitieve documenten van project Utrecht kan vinden, maar Google levert mij in ieder geval een concept op op het discussieforum van KING: https://vng-realisatie.github.io/StUF-Standaarden/discussie/gemma/stuf-301-standaard/review-project-utrecht-voorstel-datum-tijd
In dit document staat (bij wat daarin nog datumOnvolledig heet):
"Keuze (nul of meer) uit de bovengenoemde XML-Schema datatypes:
• date,
• gYearMonth (indien dag onbekend),
• gYear (indien maand onbekend)
Indien er geen keuze is gemaakt en het veld leeg is dan is het jaar onbekend. In dat geval dient aangesloten te worden bij het voorstel ‘Omgaan met ‘geen waarde’’."
De laatste zin maakt duidelijk dat (in ieder geval op dat moment nog) het de bedoeling is om ook compleet onbekende datums (dus zonder jaartal) middels dit type kunnen worden uitgewisseld. Ik kan mij niet voorstellen dat deze optie (bewust) is uitgesloten in de definitieve voorstellen vanuit het project.
Aanvulling: zojuist via een bericht van Ruud Kathman in een andere discussie alsnog de juiste versie van de documenten kunnen vinden (http://www.noraonline.nl/images/noraonline/c/c3/GAB_mogelijk_onvolledige_datum_1.0.pdf). Daarin staat de tekst:
"Het voorstel ‘Geen waarde’, ook van het project ‘Utrecht’, beschrijft hoe in het algemeen aangegeven kan worden wat de reden is dat een gegeven geen waarde heeft, ongeacht het datatype van dat gegeven. Dat voorstel kan toegepast worden op mogelijk onvolledige datums, maar dat is niet verplicht. Beide voorstellen kunnen onafhankelijk van elkaar worden toegepast en zijn ook als onafhankelijke wijzigingsverzoeken te behandelen. Toepassing van het voorstel ‘Geen waarde’ maakt het overigens niet mogelijk om aan te geven wat de reden is dat van een datum een deel ontbreekt. Het is alleen geschikt om aan te geven wat de reden is dat een mogelijk onvolledige datum helemaal geen waarde heeft."
Bij toepassing van alle voorstellen van Project Utrecht is dus een onvolledige datum zonder jaartal mogelijk bij datumMogelijkOnvolledig.