Open fsamwel opened 3 years ago
@MelvLee @JohanBoer @CathyDingemanse willen we wel dat kadastraleAanduiding wordt geleverd om te misbruiken voor het appartementsnummer? Of moet er eigenlijk alleen appartementsnummer worden geleverd?
@MelvLee @JohanBoer @CathyDingemanse we hebben nu in isOvergegaanIn en isOntstaanUit, en dus ook in mijn voorstel in dit issue de toevoeging "kadastraalOnroerendeZaak" opgenomen in de properties. Dus:
"isOntstaanUit": {
"aard": {
"code": "20",
"waarde": "Splitsen perceel"
},
"kadastraalOnroerendeZaakIdentificatie": "59020131170000",
"indicatieVervallenKadastraalOnroerendeZaak": true
},
Is die toevoeging wel nodig? Hadden we niet kunnen volstaan met:
"isOntstaanUit": {
"aard": {
"code": "20",
"waarde": "Splitsen perceel"
},
"identificatie": "59020131170000",
"indicatieVervallen": true
},
Of moet in bijbehorendeAppartementsrechten "indicatieSluimerend" eigenlijk "indicatieSluimerendeKadastraalOnroerendeZaak" worden?
@MelvLee @JohanBoer @CathyDingemanse we hebben nu in isOvergegaanIn en isOntstaanUit, en dus ook in mijn voorstel in dit issue de toevoeging "kadastraalOnroerendeZaak" opgenomen in de properties. Dus:
"isOntstaanUit": { "aard": { "code": "20", "waarde": "Splitsen perceel" }, "kadastraalOnroerendeZaakIdentificatie": "59020131170000", "indicatieVervallenKadastraalOnroerendeZaak": true },
Is die toevoeging wel nodig? Hadden we niet kunnen volstaan met:
"isOntstaanUit": { "aard": { "code": "20", "waarde": "Splitsen perceel" }, "identificatie": "59020131170000", "indicatieVervallen": true },
Of moet in bijbehorendeAppartementsrechten "indicatieSluimerend" eigenlijk "indicatieSluimerendeKadastraalOnroerendeZaak" worden?
@MelvLee ik denk dat de onderste zonder de toevoeging beter is. Wat vind jij?
@Frank er moet denk ik ook een feature komen dat de indicatie alleen voor een sluimerend appartementsrecht moet worden toegevoegd (en niet bij perceel). Ik zal hiervoor een aparte issue aanmaken. Het geldt nl ook voor bijbehorende appartementsrechten, bijbehorende grondpercelen, ontstaan uit en overgegaan in.
@MelvLee @JohanBoer @CathyDingemanse willen we wel dat kadastraleAanduiding wordt geleverd om te misbruiken voor het appartementsnummer? Of moet er eigenlijk alleen appartementsnummer worden geleverd?
Ik zou het appartementsrechtvolgnummer leveren. @kad-pothot Eens?
@MelvLee @JohanBoer @CathyDingemanse we hebben nu in isOvergegaanIn en isOntstaanUit, en dus ook in mijn voorstel in dit issue de toevoeging "kadastraalOnroerendeZaak" opgenomen in de properties. Dus:
"isOntstaanUit": { "aard": { "code": "20", "waarde": "Splitsen perceel" }, "kadastraalOnroerendeZaakIdentificatie": "59020131170000", "indicatieVervallenKadastraalOnroerendeZaak": true },
Is die toevoeging wel nodig? Hadden we niet kunnen volstaan met:
"isOntstaanUit": { "aard": { "code": "20", "waarde": "Splitsen perceel" }, "identificatie": "59020131170000", "indicatieVervallen": true },
Of moet in bijbehorendeAppartementsrechten "indicatieSluimerend" eigenlijk "indicatieSluimerendeKadastraalOnroerendeZaak" worden?
Tweede optie heeft mijn voorkeur, zonder de kadastraalOnroerendeZaak toevoeging. Ik hanteer de DRY principe, Don't Repeat Yourself.
@MelvLee @JohanBoer @CathyDingemanse willen we wel dat kadastraleAanduiding wordt geleverd om te misbruiken voor het appartementsnummer? Of moet er eigenlijk alleen appartementsnummer worden geleverd?
Ik zou het appartementsrechtvolgnummer leveren. @kad-pothot Eens?
Ik zou op dit moment kiezen voor alleen het volgnummer. Nu het een schema component wordt, is het makkelijker om te evolven. Vraag: Is het handig om dit volgnummer ook toe te voegen aan de Filiatie schema component?
@MelvLee @JohanBoer @CathyDingemanse willen we wel dat kadastraleAanduiding wordt geleverd om te misbruiken voor het appartementsnummer? Of moet er eigenlijk alleen appartementsnummer worden geleverd?
Ik zou het appartementsrechtvolgnummer leveren. @kad-pothot Eens?
Ik zou op dit moment kiezen voor alleen het volgnummer. Nu het een schema component wordt, is het makkelijker om te evolven. Vraag: Is het handig om dit volgnummer ook toe te voegen aan de Filiatie schema component?
@MelvLee Is misschien wel consistenter op die manier @CathyDingemanse Eens, kunnen we altijd nog uitbreiden als daar vraag naar is
Samenvatting :
Bij de laatste wijziging wil ik aangeven dat we afwijken van eigen conventie om in de naam aan te geven waarnaar je verwijst. Als een property ïdentificatie" wordt genoemd is het de identificatie van de resource waar de property in zit. Als we binnen de schema-component "Filiatie" nu alleen de identificatie property opnemen heb je weer domeinkennis nodig om te weten dat dit de identificatie van een Kadatsraal Onroerende Zaak is. Het is een kleine wijziging en is indien gewenst zo gedaan, maar volgens mij gaan we daar spijt van krijgen.
Samenvatting :
* Aan de component KadastraalOnroerendeZaak wordt de property indicatieSluimerend (boolean) toegevoegd. * Aan de component KadastraalOnroerendeZaak wordt de property indicatieSluimerend (boolean) ook toegevoegd bij "BijbehorendeAppartementsrechten". * Aan de component KadastraalOnroerendeZaak wordt appartementsrechtVolgnummer toegevoegd bij "BijbehorendeAppartementsrechten". * In de component Filiatie wordt indicatieVervallenKadastraalOnroerendeZaak aangepast naar indicatieVervallen * Aan de component Filiatie wordt appartementsrechtVolgnummer toegevoegd. * In de component Filiatie wordt kadastraalOnroerendeZaakIdentificatie aangepast naar identificatie.
Bij de laatste wijziging wil ik aangeven dat we afwijken van eigen conventie om in de naam aan te geven waarnaar je verwijst. Als een property ïdentificatie" wordt genoemd is het de identificatie van de resource waar de property in zit. Als we binnen de schema-component "Filiatie" nu alleen de identificatie property opnemen heb je weer domeinkennis nodig om te weten dat dit de identificatie van een Kadatsraal Onroerende Zaak is. Het is een kleine wijziging en is indien gewenst zo gedaan, maar volgens mij gaan we daar spijt van krijgen.
Als ik naar de plekken kijk waar Filiatie wordt gebruikt (isOvergegaanIn en isOntstaanUit) dan zou ik de conclusie trekken dat Filiatie een soort KOZ is. Er is nu al een property die ze beide (indicatieVervallen) hebben en er komen er twee (1 1/4 effectief) bij, nl indicatieSluimerend en appartementsrechtVolgnummer. Mocht mijn conclusie toch niet correct zijn en is Filiatie meer een relatie tussen twee KOZen, dan zou ik eerder een nieuwe schema component als gegevensgroep introduceren (iets in de geest van KadastraalOnroerendeZaakFiliatie) dan alle KOZ properties in Filiatie te prefixen met kadastraalOnroerendeZaak. Maar een andere naam dan KadastraalOnroerendeZaakFiliatie mag ook als deze ook kan worden hergebruikt voor bijbehorendePercelen en bijbehorendAppartementsrechten. Er was al een vraag van mij of bij die twee properties appartementsrechtnummer niet moet worden toegevoegd. Mijn extra vraag is dus of indicatieVervallen en indicatieSluimerend ook niet daar moet worden toegevoegd.
Misschien begrijp ik wat dingen niet omdat ik niet bij de discussie over filiatie was, maar......
dan zou ik de conclusie trekken dat Filiatie een soort KOZ is
Dit klopt volgens mij niet.
is Filiatie meer een relatie tussen twee KOZen
Dit is volgens mij het geval
een nieuwe schema component als gegevensgroep introduceren (iets in de geest van KadastraalOnroerendeZaakFiliatie)
Dat schemacomponent heb ik gemaakt en dat heet nu Filiatie (Want er is alleen filiatie tussen KadastraalOnroerendeZaken) Echter de identificatie die daar in staat verwijst naar een KadastraalOnroerendeZaak en niet naar de filiatie.
Er was al een vraag van mij of bij die twee properties appartementsrechtnummer niet moet worden toegevoegd.
Niet bij BijbehorendePercelen lijkt mij. Bij BijbehorendeAppartementsrechten zou kunnen, maar voegt dat ook iets toe op die plek (@CathyDingemanse ? @kad-pothot ? @fsamwel ? )
Mijn extra vraag is dus of indicatieVervallen en indicatieSluimerend ook niet daar moet worden toegevoegd.
(@CathyDingemanse ? @kad-pothot ? @fsamwel ?)
Misschien begrijp ik wat dingen niet omdat ik niet bij de discussie over filiatie was, maar......
dan zou ik de conclusie trekken dat Filiatie een soort KOZ is
Dit klopt volgens mij niet.
is Filiatie meer een relatie tussen twee KOZen
Dit is volgens mij het geval
een nieuwe schema component als gegevensgroep introduceren (iets in de geest van KadastraalOnroerendeZaakFiliatie)
Dat schemacomponent heb ik gemaakt en dat heet nu Filiatie (Want er is alleen filiatie tussen KadastraalOnroerendeZaken) Echter de identificatie die daar in staat verwijst naar een KadastraalOnroerendeZaak en niet naar de filiatie.
Er was al een vraag van mij of bij die twee properties appartementsrechtnummer niet moet worden toegevoegd.
Niet bij BijbehorendePercelen lijkt mij. Bij BijbehorendeAppartementsrechten zou kunnen, maar voegt dat ook iets toe op die plek (@CathyDingemanse ? @kad-pothot ? @fsamwel ? )
Mijn extra vraag is dus of indicatieVervallen en indicatieSluimerend ook niet daar moet worden toegevoegd.
(@CathyDingemanse ? @kad-pothot ? @fsamwel ?)
OK. Duidelijk, filiatie = relatie tussen KOZen. Rest nog de vraag of het handig is om een schema component te definieren voor deze groep KOZ kenmerken zodat we in Filiatie een property kadastraalOnroerendeZaak van deze type kunnen definieren of dat we al de kenmerken prefixen en plat in Filiatie opnemen. Ik heb gekeken of wij hiervoor wat hebben in de Design Decisions en daar kom ik twee rules tegen die mogelijk hierover wat zeggen:
Als ik de DDs goed begrijp, dan is het prefixen van de kenmerken in dit geval geen goed idee. Klopt mijn interpretatie?
DD1.12 zegt dat als properties in een gegevensgroep of resource zitten de naam van deze gegevensgroep of resource niet herhaald mag worden in de namen van de properties.
Ik denk dat deze DD overigens duidelijker kan dus daar ga ik een poging toe doen,
DD1.8 vind ik ook niet zo duidelijk dus ook die ga ik proberen te verhelderen.
Deze heeft inderdaad een sterke relatie met DD1.12 en hiermee wordt gedoeld op properties die een of meer identificaties bevatten van gerelateerde resources en die direct zijn opgenomen in de resource vanwaaruit de relatie loopt.
Om bijv. in de resource 'kadastraalOnroerendeZaken' te kunnen verwijzen naar een 'zakelijkGerechtigde' kun je deze embedded opnemen of binnen een '_link'. Je kunt echter ook de identificatie(s) van de zakelijkGerechtigde(n) direct als property opnemen van de resource 'kadastraalOnroerendeZaken'. In dat laatste geval moet je die property niet slechts 'identificatie' of 'identificaties' noemen. Nee, je moet dan in de naam duidelijk maken waarop de identificaties betrekkening hebben. In ditgeval noem je die property dus 'zakelijkGerechtigdeIdentificaties'. Dus als volgt:
"kadastraalOnroerendeZaken": [
{
...
"zakelijkGerechtigdeIdentificaties": [
"1234567890"
],
Geen van beide DD's zeggen dus dat je kenmerken niet mag prefixen.
Rest nog de vraag of het handig is om een schema component te definieren voor deze groep KOZ kenmerken zodat we in Filiatie een property kadastraalOnroerendeZaak van deze type kunnen definieren of dat we al de kenmerken prefixen en plat in Filiatie opnemen. Als ik de DDs goed begrijp, dan is het prefixen van de kenmerken in dit geval geen goed idee. Klopt mijn interpretatie?
Ik zie niet in hoe het plat opnemen van filiatiekenmerken in de kadastraleOnroerendeZaak het beter gaat maken. Volgens mij voegt de het feit dat dit een groep is iets toe. Zojuist ook tot de conlusie gekomen dat dit een "filiatie" ook een array moet zijn omdat een KOZ kan zijn overgegaan in (of ontstaan uit) meerdere andere KOZzen.
Ik denk dat het voor de developer niet duidelijk is waar de identificatie op slaat, maar we gaan er niet eindeloos over discussieren. Ik zal in de schemacomponent "Filiatie" de property die naar de kadastraleOnroerendeZaak verwijst die betrokken is bij de filitie "identificatie" noemen zonder prefix.
Rest nog de vraag of het handig is om een schema component te definieren voor deze groep KOZ kenmerken zodat we in Filiatie een property kadastraalOnroerendeZaak van deze type kunnen definieren of dat we al de kenmerken prefixen en plat in Filiatie opnemen. Als ik de DDs goed begrijp, dan is het prefixen van de kenmerken in dit geval geen goed idee. Klopt mijn interpretatie?
Ik zie niet in hoe het plat opnemen van filiatiekenmerken in de kadastraleOnroerendeZaak het beter gaat maken. Volgens mij voegt de het feit dat dit een groep is iets toe. Zojuist ook tot de conlusie gekomen dat dit een "filiatie" ook een array moet zijn omdat een KOZ kan zijn overgegaan in (of ontstaan uit) meerdere andere KOZzen.
Ik denk dat het voor de developer niet duidelijk is waar de identificatie op slaat, maar we gaan er niet eindeloos over discussieren. Ik zal in de schemacomponent "Filiatie" de property die naar de kadastraleOnroerendeZaak verwijst die betrokken is bij de filitie "identificatie" noemen zonder prefix.
Wat ik bedoel met platslaan:
"isOntstaanUit": {
"aard": {
"code": "20",
"waarde": "Splitsen perceel"
},
"kadastraalOnroerendeZaakIdentificatie": "59020131170000",
"indicatieVervallenKadastraalOnroerendeZaak": true
},
vs het introduceren van een nieuwe gegevensgroep:
"isOntstaanUit": {
"aard": {
"code": "20",
"waarde": "Splitsen perceel"
},
"kadastraalOnroerendeZaak": {
"identificatie": "59020131170000",
"indicatieVervallen": true
}
},
Ah, die had ik niet zo begrepen. Duidelijk. Het introduceren van die nieuwe groep elimineert de noodzaak van de prefix. Vind ik een mooie oplossing.
Deze issue ging om het opnemen van IndicatieSluimerend. Dat hebben we na overleg uitgesteld.
Alle andere wijzigingen die in de discussie voorbijgekomen zijn heb ik nu wel doorgevoerd in PR #847
Dit issue blijft openstaan om in 1.4 alsnog indicatieSluimerend op te nemen :
@JohanBoer alleen het leveren van indicatieSluimerend aan bijbehorendeAppartementsrechten (hoofddoel van dit issue) kan nog niet, het kan al wel worden toegevoegd aan de onroerende zaak. Waarom doe je dat nog niet?
@JohanBoer alleen het leveren van indicatieSluimerend aan bijbehorendeAppartementsrechten (hoofddoel van dit issue) kan nog niet, het kan al wel worden toegevoegd aan de onroerende zaak. Waarom doe je dat nog niet?
Ik was in de veronderstelling dat we alleen in de specificaties opnemen wat we kunnen leveren. Als straks blijkt dat deze properties (om welke reden dan ook) alsnog niet te leveren zijn, dan moeten we ze weer deprecaten. Daarbij kweek je ook nu al de verwachting dat we deze properties leveren als ze in de specificaties zitten.
Ik denk dat indicatieSluimerend nu al wel kan worden geleverd in de onroerende zaak, alleen niet in de bijbehorendeAppartementsrechten. @kad-pothot dat klopt toch?
Zou kunnen, maar dan moeten we dat 2 keer aanpassen. Eerst nu voor de grondpercelen, en daarna nog een keer voor de appartementsrechten. Ook lijkt het mij voor gebruikers beter om indicatieSluimerend pas te krijgen wanneer we dit ook bij appartementsrechten kunnen leveren.
In overleg 30-6 besloten: indicatieSluimerend wordt in een volgende versie opgenomen, zowel voor grondpercelen als voor appartementsrechten.
Final Check op hoe dit te implementeren. Na de opmerking van 23-06 is de structuur aangepast. Volgens mij kunnen we nu :
....zodat ik de filiatie functionaliteit beter kan begrijpen.
In geval van ondersplitsing van een appartementsrecht blijft het oude appartementsrecht actueel, maar wordt het sluimerend. Deze is dan niet vervallen en kan nog wel worden geraadpleegd, maar is wel gesplitst.
Dit kan nu worden afgeleid uit het feit dat er isOvergaanIn is, maar dat is niet erg duidelijk en vereist veel domeinkennis.
Daarom toevoegen property indicatieSluimerend aan kadastraal onroerende zaak.
Daarnaast moet het in de lijst bijbehorende appartementsrechten duidelijker zijn welke appartementsrechten relevant of interessant zijn om verder te onderzoeken. Nu worden alleen identificaties geleverd, maar er moeten naast de identificatie ook indicatieSluimerend en kadastraleAanduiding worden geleverd. Kadastrale aanduiding wordt geleverd, zodat het appartementsnummer getoond wordt
Dus in plaats van:
wordt het: