Als PO wil ik pand en adres expanden bij het bevragen van ADO

[CathyDingemanse]

...zodat ik invulling kan geven aan de in de GOALS canvas beschreven stories

Nu is nummeraanduiding, openbare ruimte en woonplaats embedded opgenomen bij ligplaats, standplaats en VBO. Daarnaast heeft de VBO geen adressen, maar een hoofd- en nevenadressen.
Stel voor om adres embedded op nemen bij ADO met hoofd en nevenadres als type (en links naar de nummeraanduiding, openbare ruimte en woonplaats).

@JohanBoer, graag een voorstel hoe dit er uit ziet!

Acceptatiecriteria

• [ ]
• [ ]

Definition of done

• functionele specificatie
• Open API specificatie
• gegenereerde code
• testgevallen

[strijm]

Update #48

[strijm]

Dit punt is in de specificatie verwerkt in pull request #58. Expand op pand kan d.m.v. de value 'maaktDeelUitVan' (dit is de formele relatie naam in IMBAG 2.0) van en expand op adres kan d.m.v. de value 'adres'. Expand op pand werkt overigens alleen voor verblijfsobjecten. Ligplaatsen en standplaatsen hebben geen relatie met pand(en).

[fsamwel]

graag link en embedded naam wijzigen naar maaktDeelUitVanPand

[fsamwel]

Namingconventie die daarachter zit is altijd zo duidelijk mogelijk te benoemen wat iets is. Voor een relatie is dat de naam van de relatie plus de naam van de gerelateerde resource, tenzij er een reden is om dat niet te doen.
Bijvoorbeeld:
ligt in + woonplaats = ligtInWoonplaats
ligt aan + openbare ruimte = ligtAanOpenbareRuimte
maakt deel uit van + pand = maaktDeelUitVanPand

Wanneer een property (niet link of embedded) alleen de identificatie van de gerelateerde resource bevat, wordt naam van de resource plus het woord "identificatie"gebruikt.
Bijvoorbeeld maakt deel uit van + pand + identificatie = pandIdentificatie

[fsamwel]

Aanvulling op deze namingconventie: als de relatie 1 keer kan voorkomen (kardinaliteit 0..1 of 1..1) dan wordt de naam van de resource in enkelvoud opgenomen; als de relatie meer dan 1 keer kan voorkomen (gedefinieerd als array), dan wordt de naam van de resource in meervoud opgenomen.

[JohanBoer]

Vooruitlopend op de besluitvorming in de naamgevingsconventie heb ik een pull request voorbereid dat de volgende naamgevingsconventie hanteert :

De properties die de identificatie van de gerelateerde resource bevatten volgens de conventie resourcenaamidentificatie. waarbij er meervoudsvorm wordt gebruikt als dit een array betreft. Als er sprake is van meerdere relaties tussen dezelfde resources wordt de relatie zo kort mogelijk opgenomen in de propertynaam (voorbeeld HoofdadresIdentificatie en NevenadresIdentificaties)

In de links is alleen de resourcenaam gebruikt, zonder de relatienaam. De links geven ook geen relatie weer, maar zijn een convenience (HAL) voor discoverability. Als er sprake van meervoud is dan wordt de resourcenaam ook in meervoud gesteld.
Voor embedded geldt dezelfde conventie

Hier is wel een dilemma. Op het moment dat we de keuze vrij laten tussen templated en non-templated URL's in de links en er worden non-templated URLS gebruikt, dan kan je in de _links geen onderscheid meer maken tussen de verschillende relaties (in dit voorbeeld: je hebt maar 1 array van adressen en daarin zit zowel het hoofdadres als de nevenadressen.

[JohanBoer]

Uitzondering op de bovenstaande conventie is het hoofdAdres in embedded van adresseerbaarObject een uitzondering omdat hier echt de functionele wens is om alleen het hoofadres te embedden.