|
IMKAD wordt vanaf versie 2.1 geheel modelgedreven beheerd. Dit betekent dat
alle uit te wisselen gegevens worden beheerd vanuit een beschrijvend model. In
dit beschrijvende model worden de voor het Kadaster relevante objecten in hun
onderlinge samenhang beschreven en gedocumenteerd. Objecten zijn bijvoorbeeld
kadastrale objecten (onroerend goed, schepen, luchtvaartuigen) en de rechten
daarop van (rechts)personen. 
Op basis van dit model wordt een technisch model van IMKAD gegenereerd in de
vorm van een XSD (XML Schema Definition), waarbij XML staat voor Extensible
Markup Language. Deze specificatie is vervolgens de basis voor de akte- en
productmodellen in de vorm van XSD’s voor akten respectievelijk
informatieproducten.
Beschrijvend model
Het beschrijvend model is zowel
toegankelijk vanuit een boomstructuur als vanuit een grafisch overzicht. Dit
model vormt de inhoudelijke documentatie van IMKAD.
Een voorbeeld van deze boomstructuur is: 
Een (vereenvoudigd) voorbeeld van het objectenoverzicht staat hieronder. Dit
overzicht geeft aan dat ZakelijkeRechten (bijvoorbeeld het eigendomsrecht) die
rusten op een KadastraalObject (bijvoorbeeld een perceel) Tenaamgesteld worden
in een Stukdeel (bijvoorbeeld een deel van een stuk in de vorm van een akte) op
naam van een Persoon. 
Zowel in de boomstructuur als in het overzichtsplaatje kan doorgeklikt worden
naar definities op objectniveau (bijvoorbeeld KadastraalObject of Persoon) en
nog dieper naar definities op gegevensniveau (bijvoorbeeld benamingRecht bij
ZakelijkRecht).
Uitwisselingsmodel
Bij het generen van het
uitwisselingsmodel is voor versie 2.1.0 een aantal ontwerpbeslissingen genomen.
Net als het model zelf worden deze ontwerpbeslissingen en de consequenties
daarvan, in het kader van de final draft review, voorgelegd aan onze
informatieleveranciers, informatieafnemers en andere betrokkenen. De
beslissingen worden in nauwe samenspraak met enkele andere partijen die
verantwoordelijk zijn voor een basisregistratie uitgewerkt. Het doel hiervan is
een set van ‘best practices’ voor de implementatie van informatiemodellen voor
basisregistraties.
De belangrijkste ontwerpbeslissingen zijn:
- IMKAD is gerealiseerd als sectormodel binnen de NEN3610
standaard. IMKAD 2.1.0 is niet expliciet op de voor gemeenten belangrijke StUF
standaard gebaseerd. Er is een initiatief voor harmonisatie tussen de NEN3610
standaard en StUF, maar een en ander is nog niet meegenomen in IMKAD 2.1.0
- Gegevens van objecten waarvan de authentieke gegevens hun
oorsprong vinden in andere basisregistraties worden uitgewisseld volgens de
structuur van de betreffende basisregistratie. Daartoe wordt in het technisch
model, de XSD, de gegevensstructuur van iedere voor het Kadaster relevante
basisregistratie gekopieerd naar een aparte ‘namespace’ binnen de IMKAD
specificatie. Een namespace is een URI (Unique Resource Identifier) die verwijst
naar de plaats op het internet waar de betreffende specificatie kan worden
gevonden. Een voorbeeld is www.kadaster.nl/schemas/IMKAD/GBApersoon/v22112011.
Het laatste cijfer geeft de datum van de laatste GBA aanpassing binnen IMKAD
aan.
- Het uitgangspunt voor het releasebeleid is het onderscheiden
van 3 typen releases:
1. Major releases, waarbij het eerste cijfer
van de release wijzigt. 2.x.x is een major release t.o.v. 1.x.x. Major release
hoeven niet backwards compatible te zijn. Een major release moet in de orde van
5 jaar of meer meegaan. Major releases ondergaan een uitgebreid extern
consultatietraject alvorens ze worden vastgesteld. Versie 2.1.0 is een major
release.
2. Minor releases, waarbij het tweede cijfer van de release
wijzigt. X.2.x is een minor release t.o.v. x.1.x. Minor releases zijn zoveel
mogelijk backwards compatible, maar kunnen wel nieuwe functionaliteit bevatten
die soms ook wettelijk nodig is. Minor releases worden vooraf afgestemd met
ketenpartners, maar ondergaan geen uitgebreid consultatietraject.
3.
Bugfixes, waarbij het derde cijfer van de release wijzigt. X.x.2 is een
bugfix t.o.v. x.x.1. Bugfixes zijn altijd backwards compatible en worden vaak
tussendoor doorgevoerd. Communicatie met ketenpartners gebeurt waar mogelijk
vooraf, maar als het niet anders kan, kan het ook achteraf.
- Bij het opzetten van modellen wordt structuur, proces en
inhoud gescheiden. Het schema geeft de model structuur. Vaak wordt de
processtatus of de inhoud van gegevens vastgelegd in code-omschrijvingstabellen,
ofwel waardelijsten.
- Waardelijsten hebben een eigen levenscyclus.
Bovendien worden dergelijke lijsten vaak buiten het Kadaster om beheerd. Zo
komen er bij een gemeentelijke herindeling bijvoorbeeld nieuwe gemeentecodes (in
Kadastertermen de burgerlijke gemeente en niet de Kadastrale gemeente) bij en
vervallen oude gemeentecodes, Dergelijke inhoudelijke wijzigingen worden los van
het uitwisselingsschema doorgevoerd.
- Wijzigingen die betrekking hebben op
de processtatus (bijvoorbeeld de status ‘voorlopig’ van een kadastrale grens)
moeten informatieleveranciers en -afnemers worden afgestemd. Dit soort wijzigen
worden releasematig doorgevoerd omdat dergelijke wijzigingen gevolgen kunnen
hebben voor de procesinrichting van ketenpartners.
Akte- en productmodellen en webservices
Aktemodellen,
productmodellen en webservices bevatten in de regel een deelverzameling van de
gegevens zoals beschreven in IMKAD. In sommige gevallen kunnen producten worden
verrijkt met andere informatie die aan het productmodel wordt toegevoegd. In het
geval van notariële akten bevat de akte-XML die wordt gebuikt in KIK gegevens
die weliswaar nodig zijn voor het geautomatiseerd kunnen toetsen van de
juridische geldigheid, maar die niet relevant is voor de Kadastrale Registratie
en daarmee ook niet voor IMKAD. Hierbij kan worden gedacht aan complexe
comparities (de samenstelling en hoedanigheid waarin twee of meer partijen bij
de notaris ‘verschijnen’ om een afspraak juridisch vast te leggen). Een
voorbeeld hiervan is een zaakwaarnemer die iemand vertegenwoordigt die eigenaar
is van een holding die weer eigenaar is van het bedrijf dat de betreffende
rechtshandeling uitvoert. Deze gedetailleerde informatie is voor veel afnemers
van Kadasterinformatie niet relevant.
De intentie is om alle huidige akte- en productmodellen en webservices op
enig moment over te brengen naar IMKAD 2.1.0. Deze modellen zijn nu nog
gebaseerd op IMKAD 1.0 of soms nog oudere versies. Uiteindelijk ontstaat zo één
standaard volgens welke het Kadaster informatie uitwisselt.
|
| laatste update:
30 november 2011
