Closed marjoleinsteeman closed 1 year ago
Is dit onderscheid alleen relevant voor de API, of wil je dit ook in de specificatie/het informatiemodel zo terug laten komen?
Beide dacht ik; ik nam aan dat het één niet zonder het ander kon... Voordeel van het handhaven van een losse tabel is dat we daar een eigen extensie aan kunnen toevoegen :)
Meer in het algemeen vraag ik mij af of er een technische noodzaak is voor het in het informatiemodel handhaven van een identificatie als onderdeel van de tabel Situering? Bij nader inzien lijkt mij dit iets dat je in een toepassing doet, maar geen deel hoeft uit te maken van het informatiemodel. En zeker niet met de eis dat het een integer moet zijn.
We gaan niet splitsen (te veel impact op documentatie en het geeft in de huidige opzet een aanknopingspunt voor extensieblok). Het attribuut 'identificatie' is overbodig bij Situering, en vervalt.
In de huidige opzet van de API worden zowel geometrie als pandids opgehaald in het basis schema. Adressen komen pas in tweede instantie bij een volledige uitvraag van een erfgoedobject. Eigenlijk zou het mooier zijn om pandids ook pas in tweede instantie op te vragen. Om dit te kunnen doen moeten de locatiekenmerken worden 'gesplitst' in geokenmerken en locatiekenmerken, waarbij locatiekenmerken zowel de panden als de adressen omvat. Omgevingen hebben alleen geokenmerken. Deelobjecten hebben zowel geokenmerken als locatiekenmerken, in deze opzet.
Een tweede argument om dit te doen is een vereenvoudiging van het huidige model. Het is namelijk zo dat adressen eigenlijk als een meervoudig attribuut kunnen worden gemodelleerd (net als panden). Het attribuut 'situering' (bij, naast enz) is namelijk meestal niet van toepassing. Als het wel van toepassing is, dan is 1 adres voldoende. Met andere woorden het veld 'situering' kan als eenmalig attribuut van ErfgoedObject worden opgenomen.
Dit is misschien een forse ingreep, maar nu is wel het moment om dit nog ter sprake te brengen.