Met de opkomst en toenemende complexiteit van IT-toepassingen is het documenteren van data en programma’s meer dan ooit van vitaal belang voor een goed ‘data governance‘, ongeacht de betrokken sector.
Begin jaren 2000 hebben we meegewerkt aan het opzetten van de glossaria van de sociale zekerheid en hebben we de verdere ontwikkeling ervan gevolgd. De concepten in deze blogpost zijn ons dus niet onbekend, aangezien sommige kenmerken sinds de jaren 2000 niet zijn veranderd.
Na het definiëren van het concept van een “data catalog” of “metadata management systeem”, schetsen we de organisatie, belangrijkste functies [1] en best practices. Ter afsluiting stellen we een reeks generaliseerbare methodologische aanbevelingen op.
Metadata Management Systeem of “Data Catalog”: definitie en beheerstrategie
“Meta-informatie” wordt vaak gedefinieerd als “informatie over informatie”. We hanteren hier de volgende definitie: een metadata management systeem is een geautomatiseerd documentair systeem ontworpen om een set informatie of data te beschrijven, te interpreteren en zo het beheer ervan te vergemakkelijken. Dergelijke systemen gebruiken is van strategisch belang wanneer informatie een instrument is om actie op de realiteit te ondernemen [2].
Een metadata management systeem behoort tot de managementstrategie. De bijbehorende kosten komen voort uit analyse, ontwerp, ontwikkeling of aanschaf van software en onderhoud. De verwachte winsten zijn een betere interpretatie van de informatie, gemakkelijker hergebruik van reeds bestaande toepassingen, een grotere geloofwaardigheid van het systeem en lagere beheerkosten (correcties achteraf in de database, vergoeding van schade veroorzaakt door de verspreiding van onjuiste gegevens, etc.)[3].
Metadata Management Systeem of “Data Catalog”: functies
Data Ingestion, Rollen, IAM, beheer van de regels
We presenteren achtereenvolgens de volgende functionaliteiten: rollen en impact, beheer van meertalige velden, versiebeheer, implementatie van overervingsmechanismen, toepassing van het WOPM-concept (Write Once Publish Many), standaarden, Graph Databases, publicatie als een REST API, multibasezoeksysteem, deployment van een workflow voor documentvalidatie (eventueel inclusief gesuperviseerde Machine Learning in de Data Catalogs) en een paar woorden over de software.
Een Data Catalog moet automatisch gevoed of vergeleken worden met andere gerelateerde systemen: dit staat bekend als “data ingestion”. Zo werden in het begin van de jaren 2000 de glossaria van de sociale zekerheid gecreëerd, waarin de uitwisseling van informatie tussen de RSZ en de dienstverleners enerzijds en de werkgevers of erkende sociale secretariaten anderzijds werd gedocumenteerd. Deze glossaria werden gevoed met de eerste basisinformatie, die toen gestructureerd werd in Word, met behulp van een PERL-programma. Er bestaan andere, modernere methoden hiervoor, afhankelijk van de context.
Een Data Catalog is bedoeld voor IT- en business managers die verantwoordelijk zijn voor het beheer van databases, bijvoorbeeld via een portaal dat toegankelijk is voor burgers voor het elektronisch indienen van aangiften bij de overheid. Het doel is dat iedereen op een gemeenschappelijke basis werkt. Hierbij worden toegangsrechten beheerd via een IAM.
Het doel van dit metadata management systeem is om de daaropvolgende procedures voor het invoeren, vertalen en valideren van documentatie gedeeltelijk te automatiseren, de integriteit ervan te versterken en de versies ervan te beheren in overeenstemming met juridische wijzigingen. De bedoeling is om “de kennis en de processen die deze genereren” te modelleren. Het woordenboek bevat daarom zowel beschrijvende informatie (bijvoorbeeld het definitiedomein van een veld) als functionele informatie (bijvoorbeeld de formele specificatie van controles om inkomende aangiften te testen). Bovendien kunnen de schema’s van uitgewisselde berichten tussen burgers en de overheid of andere partijen worden gegenereerd vanuit de Data Catalog.
Beheer van meertalige velden
Technische documentatie moet verdeeld worden in de verschillende nationale talen. Hetzelfde geldt in elke supranationale context. Gecontroleerde meertalige tabellen (gevalideerd door vertalers, juristen en IT) maken het mogelijk om bij de inbreng van de definities de informatie te integreren in één taal en de equivalenten in de andere talen te bekomen. Dit alles kan indien nodig op specifiek niveau worden ingevuld (zie hieronder: overerving). Op die manier wordt de manuele werkbelasting geminimaliseerd, wordt het inbrengproces versneld en wordt de coherentie van het geheel versterkt.
Versiebeheer
Versiebeheer is fundamenteel op administratief gebied [3]. De wetgeving wijzigt vaak en alle opeenvolgende versies moeten ten minste gedurende de verjaringstermijn worden bewaard (bij het behandelen van achterstallige betalingen is het bijvoorbeeld essentieel om eerdere definities uit de database te kunnen halen, aangezien geregistreerde verklaringen de wettelijke status van “bewijskracht” hebben, d.w.z. dat ze als “bewijs” kunnen worden gebruikt in een rechtsprocedure). Het is daarom cruciaal om precies vast te stellen welke wijzigingen er in elke nieuwe versie zijn aangebracht ten opzichte van de vorige. Deze “delta” wordt overigens verspreid onder het standaardformaat, zodanig dat de wijzigingen semigestructureerd geïntegreerd kunnen worden in de toepassingen die de databases omkaderen. Elk item dat de beschrijving van gegevens voor een bepaalde versie specificeert, verwijst naar het corresponderende bestand (in de door de gebruiker gekozen taal) met details van de gewijzigde velden ten opzichte van de direct voorgaande versie, inclusief de geschiedenis van verwijderde documenten.
Validatieworkflow (en supervised ML)
Vanwege de juridische, sociale en financiële belangen die op het spel staan, moet elke nieuwe versie worden gevalideerd door de betrokken IT- en juridische experts. Om deze validatie te structureren, begeleidt een workflowsysteem de implementatie van de Data Catalog. Dit maakt deel uit van een jaarlijks updateschema waarin de perioden voor bijwerking, validatie, acceptatie en productie nauwkeurig zijn vastgelegd. De workflow wordt centraal “gestuurd” door een team dat zich aan deze taak wijdt en ontplooit zich op gedecentraliseerde wijze, zoals bijvoorbeeld in het kader van het extranet van de sociale zekerheid (Figuur 1). Telkens een nieuwe versie aangemaakt wordt, wordt de historiek bijgehouden van de uitwisselingen tussen de verschillende verantwoordelijken, zodat men het interpretatieproces kan opvolgen. Aan de hand van een view kunnen de beheerders het aantal “fiats” volgen dat vereist is voor de publicatie van een nieuwe versie. Dit biedt een overzicht van verschillende onderling verbonden Data Catalogs.
Figuur 1. Documentatie over de glossaria van de sociale zekerheid: IT- en bedrijfsworkflow
Daarnaast zijn er nu ook gecontroleerde supervised ML-functies met menselijke tussenkomst om metadatawijzigingen te valideren op basis van wijzigingen aan de data (op voorwaarde dat deze eerst zijn gevalideerd door de bedrijfsregels van de corresponderende databases, om te voorkomen dat metadata worden gegenereerd op basis van onjuiste gegevens).
Overerving en hergebruik in een meertalige context
Het metadata management systeem kan ontworpen zijn om enkele tientallen administratieve databases te documenteren met een groot aantal gemeenschappelijke velden, waarvan sommige kenmerken identiek zijn (bijvoorbeeld formaat) en andere verschillend (bijvoorbeeld verplichte of optionele aard van een veld). Een overervingsmechanisme moet daarom geïntegreerd worden.
Overerving (Figuur 2) wordt gedefinieerd als de relatie tussen een generieke klasse A (die we hier “stereotype” noemen of algemeen vocabulaire dat weinig evolueert) en al zijn instanties {a1, a2, …an}, waarbij de properties (p1, p2, …pk) van klasse A een subset zijn van de properties van elk object dat uit klasse A wordt geïnstantieerd. Tijdens de instantiëring kan deze subset van generieke eigenschappen worden aangevuld met een andere subset van eigenschappen die specifiek zijn voor elke instantie (p1+pa1, p2+pa2, …pk+pan). Dit mechanisme kan worden toegepast op een willekeurig aantal “meta”-niveaus.
Figuur 2. Documentatie over de glossaria van de sociale zekerheid: overervingsprincipe
De waarden van de generieke properties (“naam”’, “definitiedomein”, “beschrijving”, “type”, “lengte”) van het stereotype “rekeningnummer” worden dus opgeslagen in een “gecontroleerde” tabel van generiek gestructureerde data, vooraf vertaald en gevalideerd door de juristen en IT.
De generieke en specifieke waarden worden vervolgens samengevoegd tot een semigestructureerd veld. Deze functionaliteiten bieden voordelen in termen van updatetijd (elke generieke waarde moet slechts eenmaal gecodeerd worden) en in termen van consistentie. Het systeem garandeert dat gemeenschappelijke data dezelfde waarden krijgen en voorkomt menselijke fouten die inherent zijn aan handmatige invoering.
WOPM (Write Once Publish Many), Standaarden, Graph Database en publicatie in de vorm van REST API
De toepassing omvat gestructureerde lijsten (postcodes, activiteitencategorieën, …) die in de praktijk verspreid moeten worden voor documentaire doeleinden (in de geest van een metadata management systeem) maar ook met het oog op het testen van de aangiften gestuurd door de burgers en die opgeslagen zijn in de databases. Om aan beide te voldoen, moet de toepassing worden ontworpen volgens het WOPM-concept (“Write Once Publish Many”), zodat dezelfde gestructureerde tabel (bijvoorbeeld een lijst met postcodes) automatisch in verschillende formaten wordt gegenereerd: voor mensen leesbare en voor machines leesbare formaten. Dezelfde bron kan zo gebruikt worden binnen onderling afhankelijke toepassingen.
Vandaag bestaan er, met de komst van het “Semantische Web”, talrijke standaarden op dit gebied. Sommige bieden generieke syntaxis voor het gebruik van metadata, zoals DCAT, een EU-aanbeveling. Op technisch niveau kunnen deze standaarden worden aangevuld met XML of JSON, die vooral handig zijn voor het samenvoegen van tabellen (Figuur 4), en andere formaten.
Een graph database (Figuur 3) brengt de status van relaties tussen verschillende datacatalogi in beeld, en het deel van de metadata dat al dan niet compleet is. Afhankelijk van hoe volledig ze zijn, kun je beslissen of je een datacatalogus wel of niet publiceert in de vorm van een REST API binnen een instelling (Figuur 3).
Figuur 3. Gebruik van een graph database om de volledigheid te controleren van een Data Catalog – Bron: Collibra website
De Data Catalog kan worden gepubliceerd in de vorm van een REST API en zelf andere REST API’s hosten of aansluiten op reeds bestaande commerciële software. Bepaalde standaarden, zoals de hierboven genoemde JSON (afbeelding 4), vergemakkelijken deze koppelingen aan (1).
Figuur 4. Voorbeeld van het koppelen van twee metadatasystemen via JSON (Bron zie opmerking 3)
Multibase zoeksysteem
Een “multibase” zoeksysteem (Figuur 5) moet worden opgezet, waarmee “full text” kan worden gezocht in het geïntegreerde documentensysteem op basis van specifieke parameters met behulp van Booleaanse logica, evenals sorteer- en filtersystemen. De output van de zoekfunctie kan in verschillende formaten worden gepresenteerd, afhankelijk van het beoogde gebruik (menselijk leesbaar of machinaal leesbaar).
Figuur 5. Voorbeeld van multibase, multilingual en multifield searches met opties (bron: social security glossaries)
Voortdurende beoordeling en onderhoud van de kwaliteit van gegevens en metadata
Het handhaven van de kwaliteit van data en metadata is van fundamenteel belang. Er zijn twee complementaire benaderingen. We kunnen werken met een complete data quality tool om problemen aan te pakken die al aanwezig zijn in de databases, inclusief profilering-, standaardiserings- en matchingfuncties (curatieve aanpak). Om te voorkomen dat dezelfde fouten zich ad infinitum bij de bron herhalen, kunnen we gebruik maken van backtracking en ATMS (preventieve aanpak), bedacht bij Smals Research om de oorzaken van kwaliteitsproblemen bij de bron op te lossen (zie ReUse-catalogus). De kwaliteit van data en de bijbehorende metadata continu verbeteren is cruciaal (zie het competentiecentrum Data Quality’ op de Smals-website, inclusief REST API’s uit de Smals Software ReUse-catalogus) (5).
Software
Op softwareniveau bestaan er buiten “home made”-oplossingen zoals de glossaria van de sociale zekerheid, waarnaar verschillende figuren van deze blogpost verwijzen, ook “open source” development environments zoals Egeria die ontwikkelingen vereisen, of commerciële instrumenten zoals Collibra, Altan, en andere tools.
Metadata Management Systeem: methodologische aanbevelingen
De metadata management systemen hebben drie potentiële hinderpalen. De eerste hangt samen met het feit dat deze systemen oneindig uitbreidbaar zijn. Dit is voornamelijk het geval wanneer in te vullen velden “vrij” zijn, waarbij de natuurlijke taal zijn eigen metataal is. Dit brengt aanzienlijke beheerkosten met zich mee wanneer er een groot aantal manuele updates zijn. De tweede valkuil bestaat erin dat de metadata zelf foutief en onzeker kunnen zijn: wanneer ze contextueel zijn, kan de validatie ervan niet aan strikte integriteitsbeperkingen worden onderworpen. De derde hinderpaal hangt samen met het tijdsverschil tussen de bijwerking van een data en van de bijbehorende metadata, waarbij deze laatste, vooral als het voorkomt onder tekstuele vorm, meestal pas aangemaakt wordt op het einde van een min of meer lange analysefase.
Zo roepen verschillende auteurs de onlosmakelijke praktische problemen op die het “misbruik” van metadata met zich meebrengt in een doortastende communicatie “The Metadata Myth” [4]. Wat betreft geospatiale databases die worden beheerd door het Bureau of Census en de National Aeronautics and Space Administration (NASA) resulteerde de implementatie van een federaal metadatasysteem waarvoor elk nieuw record de integratie van ongeveer 300 metadata vereiste, in de volgende problemen: buitensporige kosten in termen van personeel en middelen, zware updates, esoterische documentatie en, ten slotte, een aanzienlijke vermindering van de data-uitwisseling. NASA heeft dit systeem echter niet verlaten, maar wel vereenvoudigd en geherstructureerd.
Op basis van onze ervaring op dit gebied stellen wij de volgende vijf aanbevelingen voor:
- Identificeer een minimumset van verplichte metadata.
- Geef voorkeur aan automatisch gegenereerde meta-informatie (of bijvoorbeeld op basis van lijsten van gecontroleerde waarden), deze informaties zijn immers minder “duur” in termen van updates en zijn daarbij ook betrouwbaarder (cfr. supervised ML onder de hierboven aangegeven voorwaarden).
- Creëer verschillende niveaus van metadata, aangepast aan verschillende toepassingen (generieke en specifieke metadata, bijvoorbeeld).
- Leg directe verbanden tussen gedocumenteerde toepassingen en de bijbehorende metagegevens (principe van integriteit en consistentie).
- Pas KPI’s toe gedurende de gehele levenscyclus van de Data Catalog om verschillende belangrijke statistieken te monitoren, zoals het raadplegingspercentage voor verschillende delen van de Data Catalog (6).
Naast de toepassing die in dit artikel wordt gepresenteerd, zijn deze aanbevelingen van toepassing op elke empirische database waarvan de interpretatie strategisch is, als instrument om te handelen op de werkelijkheid, en dus op elke “Data Catatog”.
Deze blogpost werd geschreven door Isabelle Boydens, Data Quality Expert bij Smals Research. Dit artikel is geschreven onder haar eigen naam en weerspiegelt op geen enkele wijze de standpunten van Smals.
[1] O. Olesen-Bagneux, The Entreprise Data Catalog :Improve Data Discovery, Ensure Data Governance, and Enable Innovation. Boston, O’Reilly, 2023.
[2] “In mei 1999, tijdens haar interventie in Kosovo, bombardeerde de NAVO per ongeluk de Chinese ambassade in Belgrado: de cartografische databanken die toen gebruikt werden om raketten te leiden, gaven een verouderde en dus onbruikbare kaart van de stad weer” BOYDENS I., L’océan des données et le canal des normes.” In CARRIEU-COSTA M.-J., BRYDEN A. en COUVEINHES P. eds, Les Annales des Mines, Reeks “Responsabilité et Environnement” (themanummer: “La normalisation : principes, histoire, évolutions et perspectives”), Paris, n° 67, juli 2012, p. 22-29 (link naar het artikel – Inhoud van nummer 67 van Annales des Mines).
[3] Marcus Christie, Suresh Marru, Sudhakar Pamidighantam, Isuru Ranawaka, and Dimuthu Wannipurage. 2023. Airavata Data Catalog: A Multi-tenant Metadata Service for Efficient Data Discovery and Access Control. In Practice and Experience in Advanced Research Computing (PEARC ’23), July 23–27, 2023, Portland, OR, USA. ACM, New York, NY, USA https://doi.org/ 10.1145/3569951.3597572 [4]Foreman T. W., Wiggins H. V., Porter D.L., Metadata Myth : Misunderstanding the Implications of Federal Metadata Standards. Proceedings of the First IEEE Metadata Conference. Maryland: IEEE, 1996 (http://www.llnl.gov/liv_comp/metadata/ieee-md.4-96.html). [5] BOYDENS I., “Strategic Issues Relating to Data Quality for E-government: Learning from an Approach Adopted in Belgium“. In ASSAR S., BOUGHZALA I. en BOYDENS I., eds., “Practical Studies in E-Government: “Best Practices from Around the World”, New York, Springer, 2011, p. 113-130 (hoofdstuk 7). BOYDENS I., HAMITI G. en VAN EECKHOUT R., A service at the heart of database quality. Presentation of an ATMS prototype. In Le Courrier des statistiques, Parijs, INSEE, 2023, nr. 6, 11 p. (gepubliceerd op 2/10/2023). Link naar het artikel. [6] Asmae Boufassil; Fadwa Bouhafer; Mohamed Cherradi; Anass El Haddadi, Data Catalog: Approaches, Trends, and Future Directions. In 17th International Conference on Signal-Image Technology & Internet-Based Systems (SITIS), IEEE: 21 March 2024, DOI: 10.1109/SITIS61268.2023.00067
Leave a Reply