Kerngegevens krijgen een plek in de informatiemodellen

Dit is een statische kopie van het eerdere discussie.kinggemeenten.nl.
Nieuwe discussies kunnen in de GitHub repository 'StUF standaarden' als issue worden opgevoerd.

3 reacties / 0 nieuw
Henri Korver
Kerngegevens krijgen een plek in de informatiemodellen

In de expertgroep informatiemodellen december jongstleden is besloten alternatieve sleutels op te nemen in de informatiemodellen naast de unieke aanduiding van een objecttype, zie deze link.  Dit lijkt mij een prima stap om de informatiemodellen en StUF dichter bij elkaar te brengen.

Gevraagd wordt aan de expertgroep StUF wat de implicaties voor StUF t.a.v. kerngegevens zijn als we in de informatiemodellen alternatieve sleutels opnemen. En of zij met voorgestelde planning eens zijn.

Robert Melskens

Tijdens de StUF Expertgroep van 18 januari 2017 wordt positief gereageerd op het voornemen alternatieve sleutels op te nemen in de informatiemodellen. Wel vindt er discussie plaats over de term 'kerngegevens' en 'alternatieve sleutels'.

Daarnaast is er ook discussie over het feit of je met een kerngegeven een object kunt identificeren.
Er werd in dat kader opgemerkt dat kerngegevens indertijd zijn opgevoerd om de gegevens te benoemen die er bij het opvoeren van object minimaal in moeten zitten.
Tenslotte ontstaat ook nog discussie over de plaats waar je de kerngegevens aanscherpt, in het koppelvlak of op sectormodel niveau.

Over de termijn die de werkgroep Informatiemodellen stelt aan het opnemen van kerngegevens in de Informatiemodellen vindt geen discussie plaats. Het wordt geaccepteerd dat dit iets voor de langere termijn is.

De StUF Expertgroep besluit tenslotte om in de communicatie naar de werkgroep Informatiemodellen de term 'kerngegevens' niet meer te gebruiken. Daarvoor in plaats zal de term 'matchinggegevens' worden gebruikt.

 

John Rooijakkers

De (voormalige) "kerngegevens" hebben naar mijn mening twee verschillende doelstellingen:

1. Identificatie van het object indien een unieke sleutel (bv BSN) niet voorhanden is.

2. Verificatie van het object indien een unieke sleutel (bv BAG-ID) wel voorhanden is.

De tweede doelstelling is van belang indien een typefout in de unieke sleutel kan leiden tot het gebruik van het verkeerde object. De kans daarop bij een BSN is daarop erg klein, maar bij een BAG-ID erg groot.

Wellicht dat we dus kunnen spreken over "identificerende en validerende" gegevens.