Een fabeltje over informatie en data
Samenvatting: De werelden van informatie en data (of gegevens) dichterbij elkaar brengen. Dat was één van de doelstellingen voor het ontwikkelen van de handreiking duurzame toegankelijkheid van gegevens. Daarom lag er een mooie kans toen dataprofessionals van DAMA NL in gesprek wilden met informatieprofessionals van het Nationaal Archief. Wat volgde kun je hieronder lezen.
Reacties
Hé Wouter,
In de praktijk ben ik er (nog) niet mee bekend. Wel een goed vraagstuk! Wellicht is het volgende een optie zonder mezelf erin te hebben verdiept.
Elk informatiesysteem heeft bij ons een applicatienummer. Dat is vastgelegd in het DSP (I-navigator). Een combinatie van het nummer uit de applicatie met voorafgaand het applicatienummer zorgt m.i. altijd voor een unieke nummering. En dan kunnen we meteen tot in de lengte van dagen achterhalen met welk informatiesysteem de informatie is gecreëerd of in is opgeslagen. Zou dat een oplossing kunnen zijn?
@stefanheirbaut1
Ha Stefan,
klinkt als een oplossing wat zou kunnen werken. Maar hoe krijg je het applicatienummer bij een zaak of document toegevoegd? Exporteer je dat dan uit de i-navigator naar een apart veld in je zaaksysteem? Doe je dat zichtbaar of ergens onder water? Communiceer je dat applicatienummer dan ook naar de burger/ondernemer toe? Of wordt het 1 nummer met de opbouw applicatienummer_zaaknummer?
@stefanheirbaut1
Hey Wouter,
Daar is vast een technische oplossing voor. Volgens mij moet bijvoorbeeld een preingesttool (RMTool?) in bulk een aanpassing kunnen doen. Maar dit is op basis van een aanname en zeker niet op feitelijke kennis. Wellicht heb ik iets teveel vertrouwen in de techniek :)
Dag Wouter,
Het is zinvol, noch relevant om een applicatie als bron aan te merken; sterker nog, het druist in tegen de Common Ground-gedachte om data van applicatie te scheiden. Een applicatie is daarom per definitie niet de bron van het informatieobject (ondanks dat een applicatie het object kan hebben gecreëerd) en zou dus ook niet in de identificatie moeten worden opgenomen.
Een veel logischere identificatie zou bijv. het gemeentenummer, OIN of RSIN zijn. Daarmee is een informatieobject direct te relateren aan het BG dat de juridische en technische validatie van het object heeft verzorgd. De identificatie van de data staat daarmee los van de applicatie. De criteria voor een goede identificatie zou m.i. in het MDTO moeten zijn vastgelegd. Ik zal eens bij de MDTO-expert in onze organisatie nagaan of dat ook het geval is.
IMRO had ooit best een goed identificatiemethode trouwens.
Grt,
Bastiaan
@bastiaanligt
Hoi Bastiaan,
Ik ben het met je eerste alinea volledig eens. In de common ground wereld is er mijn inziens maar sprake van 1 bron en dat is de datalaag van je organisatie. Maar je wilt nog steeds aan ieder object een uniek kenmerk koppelen.
Het gemeentenummer o.i.d. alleen is m.i. niet voldoende, dat geef je aan heel je archief mee, bij bv. overdracht naar een archiefinstelling. In het TMLO was wel een mogelijkheid om het gemeentenummer o.i.d. op het aggregatieniveau 'Archief' mee te nemen. In het MDTO weet ik het zo niet uit mijn hoofd.
Een losse component die unieke identificatienummers uitgeeft lijkt me dan veel logischer.
Een centraal DMS als documentenregister zou m.i. een goede optie zijn om op dat aggregatieniveau unieke kenmerken in te regelen. Alle applicaties zouden dan via API's de documenten moeten wegschrijven in het DMS en het betreffende documentnummer en document moet bevragen uit het DMS i.p.v. eigen documentnummers uitgeven.
Een zaakregistratiecomponent o.i.d. zou dat wellicht op zaakniveau kunnen doen, maar niet alle processen wordt zaakgewijs behandeld. Wellicht zou je die component kunnen uitbreiden voor alle processen?
Maar ik weet niet of deze gedachtegang technisch mogelijk is. ;-)
Gr. Wouter
@stefanheirbaut1
Ik heb vroeger geleerd dat een sleutel met betekenis géén best practise is. Een nummer waaraan je de applicatie kunt herkennen is volgens mij de verkeerde oplossing voor dit probleem. Los van de scheiding tussen applicatie en data, zijn applicaties ook tijdelijk en de data soms 'eeuwig'. Als ik het plat sla heb je nodig dat: a) elke applicatie die aan de wieg staat van een informatie-object daar een GUID aan kan toekennen, b) je beschikt over een (door services te bevragen) index waarin per informatie-object wordt bijgehouden waar dat object zich bevindt (cq het pad daar naar toe).