De componenten van het MDM werden geïntroduceerd in een vorig blogartikel, en op basis van enquêtes bij bedrijven (zie referenties hieronder) bespreken we hier de aandachtspunten ervan. Is een dedicated MDM-tool noodzakelijk?

We komen niet terug op de ‘best practices’ die in het vorige blogartikel werden genoemd en waarmee rekening moet worden gehouden om ‘AI Ready Data’ te verkrijgen. We herhalen wel eerst enkele belangrijke punten over Master Data Management. Vervolgens bespreken we de verschillende ‘kritieke elementen’ met betrekking tot de implementatie van een MDM, om af te sluiten met enkele suggesties.

MDM: de key points

‘Master Data Management’ (MDM) is een ‘business’-discipline waarvan de implementatie gebaseerd is op een technologie (keuze van een MDM-architectuur, een MDM-tool) waarbij semantisch met elkaar verbonden datasets tussen databases worden uitgewisseld voor toepassingsdoeleinden.

De aanpak is gebaseerd op data governance om geïsoleerde gegevenssilo’s te voorkomen. Een ‘data catalog’ (of meta-informatiesysteem) is ook onmisbaar. Deze zorgt voor een volledige en actuele definitie van de data (via een IT en business validation workflow, versiebeheer met het genereren van delta’s tussen versies van metagegevens en de overeenkomstige applicaties). In onze sector hebben de wettelijke redenen voor het bijhouden van versies tussen metagegevens te maken met de verjaringstermijn, de periode waarin de gegevens en metagegevens moeten worden bewaard in geval van rechtszaken en nog lopende dossiers. Deze termijn kan in de sociale zekerheid variëren van 5 tot 30 jaar, of zelfs meer. 

Een ‘data quality’-aanpak stroomopwaarts en stroomafwaarts van de uitwisselingsarchitectuur is eveneens essentieel om de kwaliteit van de ‘brondatabases’ te waarborgen, maar ook om de door de business gevalideerde ‘golden records’ te identificeren. De ‘golden records’ worden uitgewisseld om de traceerbaarheid van de Master Data (‘data lineage’) tussen databases te garanderen. De volgende figuur illustreert de toepassing van regels (vastgesteld door de business) om een golden record te identificeren per type cluster van vermoedelijke duplicaten (geïdentificeerd via een ‘matching’-procedure).

Op basis hiervan is het mogelijk om deze regels binnen enkele uren toe te passen op miljoenen records die vermoedelijke duplicaten bevatten, via performance management (de geschiedenis van de ‘niet-geselecteerde’ records wordt altijd bewaard voor het geval de eigenaars van de database de regels achteraf willen aanpassen). De volgende afbeelding toont een voorbeeld van het opstellen van een ‘golden record’ via de ‘data quality tool’ Trillium. 

Vervolgens moeten de gegevens worden overgedragen via een te bepalen MDM-architectuur (zie volgende afbeelding). We hebben de voor- en nadelen hiervan geïdentificeerd in ons vorig blogartikel. Deze zullen worden aangevuld in het deel over aandachtspunten.

Invoering van MDM: aandachtspunten

De interviews in de onderstaande referenties wijzen op verschillende aandachtspunten bij het opzetten van een MDM-systeem. 

De kwaliteit van de gegevens

Alle onderstaande referenties benadrukken zonder uitzondering dat een ‘continue data quality’-aanpak in de praktijk ontbreekt en moet worden geïmplementeerd voor alle brondatabases, voordat het ‘golden record’ wordt geïdentificeerd: profilering (data audit), standaardisatie (bijvoorbeeld het opschonen van adressen) en matching (bijvoorbeeld deduplicatie). 

Integratie van de gegevens

Behalve de architectuur van het type ‘virtual directory’ vereisen alle andere architecturen een integratie van de gegevens. In de privésector van multinationals (4) wordt vaak gekozen voor centralisatie en wordt deze ook opgelegd. Deze aanpak is door veiligheid en privacy niet haalbaar in het kader van e-government, gezien de gevoeligheid van de beheerde gegevens.

Er zijn echter specifieke beveiligde toepassingen op dit gebied die gegevensintegratie vereisen, bijvoorbeeld het SumEHR (Summarized Electronic Health Record of ‘patiëntendossier’), waarvan hier een schematische weergave wordt gegeven (JC Trigaux, 2009) met de uitwisseling van ‘golden records’ en het genereren van een unieke identificatiecode binnen de SumEHR-toepassing.

Maar in 2025 blijkt uit een bericht aan artsen dat de kwaliteit van de gegevens niet altijd optimaal is. 

MDM-tools

Daarnaast zijn er volgens de hieronder genoemde referenties, wanneer een MDM-tool met gegevensintegratie wordt gebruikt (wat de meeste van deze tools bieden), mogelijke synchronisatieproblemen, omdat sommige gegevens in batches worden overgedragen en andere continu. Er kunnen ook heterogene standaardisatiekwesties aan de orde komen  die een belemmering vormen voor de traceerbaarheid van gegevens. MDM-tools worden soms ook traag geïntegreerd en brengen hoge kosten met zich mee (sommige tools worden gefactureerd per geïntegreerde ‘golden record’). Sommige tools zijn ondoorzichtig wat betreft de identificatie van het ‘golden record’. Bovendien heeft de gebruiker, zodra de gegevens zijn geïntegreerd, niet noodzakelijkerwijs nog controle over deze gegevens. 

Het gebruik van de cloud (meestal privé: Microsoft Azure, Google Cloud, Amazon Web, enz.) biedt goedkopere oplossingen dan een on-prem-ontwikkeling, maar is dit een haalbare aanpak in het kader van e-government?

Enkele van de bekendste MDM-tools zijn: Profisee, Pilog Group, Semarchy, … Sommige daarvan maken deel uit van bedrijven die verschillende softwareprogramma’s (data catalog tools, data quality tools, MDM tools, …) hebben verzameld in de vorm van een ‘suite’, die niet noodzakelijkerwijs onderling compatibel zijn: Informatica bijvoorbeeld. Er bestaan ook open source MDM-tools (met cloud of on-prem), waaronder bepaalde betaalde modules, zoals bijvoorbeeld Altrocore. Maar gezien de omvang van de databases die binnen de e-government in België worden beheerd, kunnen deze tools vragen oproepen over de ‘schaalbaarheid’.  In elk geval moet bij de aanschaf van een MDM-tool eerst een data governance en een organisatie met bijbehorende rollen worden opgezet, een test op een representatieve PoC worden uitgevoerd en een planning worden opgesteld.

Een ‘in house’ oplossing? Een voorbeeld op het gebied van sociale zekerheid

Zou naast de oplossingen die op de markt beschikbaar zijn, ook een ‘in house’ oplossing overwogen kunnen worden? We geven hier een voorbeeld uit het domein van de sociale zekerheid. In het kader van een architectuur van het type ‘virtual directory’, die een beveiligde gegevensuitwisseling met toegangsbeheer via de directory garandeert, naar het voorbeeld van de kruispuntbank van de sociale zekerheid, beschikken we over een ‘data catalog’, namelijk de ‘glossaria van de sociale zekerheid’, waarvan hier een voorbeeld is met betrekking tot de DmfA (Déclaration Multifonctionnelle – Multifunctionele Aangifte).  De data catalog oplossing voorziet in een documentatie van de uitgewisselde gegevens, inclusief versiebeheer van metadata, een validatieworkflow en beheer van meertaligheid. Deze mechanismen zorgen ook voor de actualisering van de toepassingen die verband houden met de betreffende databases, met IT- en businessvalidatie voor elk van deze databases. Dit meta-informatiesysteem draagt momenteel bij aan de jaarlijkse inning en herverdeling van 95 miljard euro aan sociale bijdragen en uitkeringen. Deze data catalog wordt momenteel langzaam gemigreerd naar de ‘glossaria egov 3.0’. Ten slotte zou het competentiecentrum ‘data quality’ van Smals het mogelijk maken om de kwaliteit van de brondatabanken en de tussen instellingen uitgewisselde ‘golden records’ te beheren.

Voorlopige conclusie

Een ‘in house’ oplossing, zoals hierboven beschreven, zou zeker aanpassingen ten opzichte van het bestaande systeem vereisen. De haalbaarheid en algemene toepasbaarheid ervan zouden moeten worden onderzocht. Maar het is misschien een optie om te overwegen naast de commerciële “MDM-tools” als er in onze omgeving een Master Data Management moet worden geïmplementeerd.

Commerciële tools, ook al dekken sommige een klein deel van de publieke sector af – zoals Semarchy (1) – richten zich vooral op multinationals die producten of diensten verkopen, zoals Procter & Gamble (P&G), Coca-Cola, General Electric of Wal-Mart (4). 

Daarnaast blijft het nuttig om de ontwikkeling van de hierboven genoemde open source-tools te blijven volgen, waarvan de volwassenheid nog zou kunnen toenemen. 

Referenties

(1) GARTNER : rapports (2024, 2025) et en particulier Voice of the Customers for Master Data Management, Gartner, 30 juin 2025, Peer Lessons Learned for Master Data Management Solution Implementation, Gartner, août 2025.

Interviews bij klanten en leveranciers van MDM-tools

(2) LEPENIOTIS P, Master data management: its importance and reasons for failed implementations. Doctoral Thesis, Sheffield Hallam University Press (UK), 2020.

Analyse van MDM in twee Engelse handelsondernemingen (VK): interviews, gegevensaudits, enz.

(3) PANSARA R. (MDM Specialist, TESLA, USA), Master Data Management Challenges, In International Journal of Computer Science and Mobile Computing, Vol.10 Issue.10, October- 2021, p. 47-49.

(4) PANSARA R.,Strategies for Master Data Management Integration and Their Benefits, In Scholars Journal of Engineering and Technology, 2024, p. 40-47.

Bibliografische opzoeking, case study’s, peilingen en interviews in de volgende Amerikaanse multinationals: Procter & Gamble (P&G), Coca-Cola, General Electric, Wal-Mart.

(5) SMITH H. A. et al. (Queen’s School of Business, Queen’s University, Canada), Developments in Practice XXX: Master Data Management: Salvation Or Snake Oil ? In Communications of the Association for Information Systems, Volume 23, Article 4, pp. 63-72, juillet 2008.

Interviews bij IT Managers van 15 industriële organisaties

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.

Les composantes du MDM ayant été introduites dans un précédent article de blog, à partir d’enquêtes auprès d’entreprises (voir références ci-dessous), nous en évoquons ici les points d’attention. Un outil de MDM dédié est-il indispensable ?

Nous ne revenons pas sur les “bonnes pratiques” évoquées dans le précédent article de blog qui doivent être prises en compte afin d’obtenir des “AI Ready Data“. Nous rappelons toutefois dans un premier temps quelques points importants relatifs au Master Data Management. Dans un second temps, nous passons en revue les différents “éléments critiques” relatifs à la  mise en place d’un MDM, pour conclure sur quelques pistes.

MDM : les points importants

Le “Master data management” (MDM) est une discipline “business” dont la mise en production repose sur une technologie (choix d’une architecture de MDM, d’un outil de MDM) où des ensembles de données liées sémantiquement entre elles sont transmises entre bases de données pour des besoins applicatifs.

L’approche repose sur une gouvernance des données pour éviter les silos de data isolées. Un “data catalog” (ou système de méta-information) est également indispensable. Il en assure la définition complète et à jour (via un worklow de validation IT et business, une gestion des versions avec génération de deltas entre versions de méta-données et des applications correspondantes). Dans notre secteur, les raisons légales du maintien de versions entre méta-données tiennent à la durée de prescription, période durant laquelle les données et métadonnées doivent être conservées, en cas de procès et de dossiers encore ouverts. Cette durée peut varier dans le domaine de la sécurité sociale entre 5 à 30 ans, voir plus. 

Une approche “data quality” en amont et en aval de l’architecture d’échange est également indispensable afin d’assurer la qualité des bases de données “sources”, mais aussi pour identifier les “golden records” validés par le business. Les “golden records” seront échangés de façon à assurer la traçabilité des Master Data (“data lineage”) entre bases de données. La figure suivante illustre l’application de règles (établies par le business) afin d’identifier un golden record par type de clusters de présomptions de duplicats (identifiés via une procédure de “matching“).

Sur cette base, il est possible d’appliquer ces règles en quelques heures sur des millions de records représentant des sous-ensembles de duplicats présumés, via une gestion de la performance (on conserve toujours l’historique des records “non retenus” au cas où les propriétaires de la base de données souhaiteraient adapter les règles a posteriori). La figure suivante montre un exemple d’établissement d’un “golden record” via le “data quality tool” Trillium. 

Ensuite, les données doivent être transférées via une architecture de MDM (voir figure suivante), à choisir. Nous en avons identifié les avantages et inconvénients dans notre précédent article de blog. Ces derniers seront complétés dans la partie relative aux points d’attention.

Mise en place du MDM : points d’attention

Les interviews reprises dans les références ci-dessous indiquent plusieurs points d’attention lors de la mise en place d’un système de MDM. 

La qualité des données

Toutes les références ci-dessous sans exception insistent sur le fait qu’une approche “data quality continue” manque dans la pratique et doit être mise en place pour toutes les bases de données sources, avant l’identification du golden record : profiling (audit des données), standardization (par exemple, nettoyage d’adresses) et matching (par exemple, déduplication). 

L’intégration des données

À part l’architecture de type “répertoire virtuel”, toutes les autres demandent une intégration des données. Dans le secteur privé des multinationales (4), la centralisation est souvent choisie et imposée. Cette approche n’est pas viable dans le cadre de l’e-government pour des raisons de sécurité et de vie privée, vu la sensibilité des données gérées.

On trouve toutefois dans ce domaine des applications spécifiques sécurisées nécessitant une intégration des données, par exemple, le SumEHR (Summarized Electronic Health Record ou “dossier du patient”) dont voici une présentation schématique (JC Trigaux, 2009) avec l’échange de golden records et la génération d’un identifiant unique au sein de l’application SumEHR.

Mais en 2025, un message adressé aux médecins indique que la qualité des données n’est pas toujours au rendez-vous. 

Les outils de MDM

À cela s’ajoutent, selon les références citées ci-dessous, lorsque l’on utilise un outil de MDM avec intégration des données (ce que proposent la plupart de ces outils), des problèmes potentiels de synchronisation, certaines données étant transférées en batch, d’autres en continu. Des questions de standardisation hétérogènes peuvent également se présenter, constituant un obstacle à la  traçabilité des données. Les outils de MDM présentent aussi parfois une certaine lenteur d’intégration ainsi qu’un coût important (certains facturent leur outil par “golden record” intégré). Certains d’entre eux sont opaques quant à l’identification du “golden record”. Par ailleurs, une fois les données intégrées, l’utilisateur n’a plus nécessairement de prise sur celles-ci. 

Le recours au cloud (privé la plupart du temps : Microsoft Azure, Google Cloud, Amazon Web, …) offre des solutions moins chères qu’un développement on-prem, mais est-ce une approche viable dans le cadre de l’e-government ?

Citons quelques outils de MDM parmi les plus connus : Profisee, Pilog Group, Semarchy, … Certains d’entre eux font partie de firmes ayant cumulé sous forme de “suite” les acquisitions de logiciels divers (data catalog tools, data quality tools, MDM tools, …), qui ne sont pas nécessairement compatibles entre eux : Informatica, par exemple. Il existe également des outils de MDM open source (avec cloud ou on-prem), incluant certains modules payants, comme Altrocore, par exemple. Mais par rapport au volume des bases de données gérées au sein de l’e-government en Belgique, ces derniers peuvent poser des questions de “passage à l’échelle”.  Dans tous les cas, en cas d’acquisition d’un outil de MDM, il faut préalablement avoir mis en place une data governance et une organisation, des rôles associés, effectué un test sur un PoC représentatif et prévoir un planning.

Une solution “in house” ? Un exemple dans le domaine de la sécurité sociale

A côté des solutions du marché, une solution “in house” pourrait-elle être envisagée ? Nous en présentons un exemple dans le domaine de la sécurité sociale. Dans le cadre d’une architecture de type “répertoire virtuel” assurant un échange sécurisé des données via l’annuaire avec gestion des accès, à l’instar de la banque carrefour de la sécurité sociale, nous disposons d’un “data catalog”, à savoir les “glossaires de la sécurité sociale”, dont voici un exemple s’agissant de la DmfA (Déclaration Multifonctionnelle – Multifunctionele Aangifte) documentant les données échangées avec gestion des versions de méta-données, worfkow de validation, gestion du multilinguisme. Ces derniers assurent également la mise à jour des applicatifs liés aux bases de données concernées avec validation IT et business pour chacune d’entre elles. Ce système de méta-information contribue actuellement au prélèvement et à la redistribution annuels de 95 milliards d’euros de cotisations et prestations sociales. Ce data catalog est en cours de lente migration vers des “glossaires egov 3.0“. Enfin, le centre de compétence “data quality” dont dispose Smals permettrait de gérer la qualité des bases de données sources ainsi que les golden records échangés entre institutions.

Conclusion provisoire

Une solution “in house”, telle que présentée ci-dessus, demanderait certainement des adaptations par rapport à l’existant. Son caractère réaliste et généralisable devrait être examiné. Mais il s’agit peut-être d’une piste à envisager à côté des “outils de MDM” commerciaux, si un Master Data Management doit être mis en place dans notre environnement.

En effet les outils commerciaux, même si certains d’entre eux couvrent pour une petite part de marché le secteur public, comme Semarchy (1), s’adressent surtout aux multinationnales vendant des produits ou services, telles que Procter & Gamble (P&G), Coca-Cola, General Electric ou encore, Wal-Mart (4). 

A côté de cela, il restera utile de suivre l’évolution des outils open source, évoqués plus haut, dont la maturité pourrait prendre de l’ampleur. 

Références

(1) GARTNER : rapports (2024, 2025) et en particulier Voice of the Customers for Master Data Management, Gartner, 30 juin 2025, Peer Lessons Learned for Master Data Management Solution Implementation, Gartner, août 2025.

Enquêtes auprès de clients et de fournisseurs d’outils de MDM.

(2) LEPENIOTIS P, Master data management: its importance and reasons for failed implementations. Doctoral Thesis, Sheffield Hallam University Press (UK), 2020.

Analyse du MDM dans deux entreprises commerciales anglaises (UK) : interviews, audits de données, …

(3) PANSARA R. (MDM Specialist, TESLA, USA), Master Data Management Challenges, In International Journal of Computer Science and Mobile Computing, Vol.10 Issue.10, October- 2021, p. 47-49.

(4) PANSARA R.,Strategies for Master Data Management Integration and Their Benefits, In Scholars Journal of Engineering and Technology, 2024, p. 40-47.

Recherche bibliographique, case studies, sondages et interviews dans les mulitinationales américaines suivantes : Procter & Gamble (P&G), Coca-Cola, General Electric, Wal-Mart.

(5) SMITH H. A. et al. (Queen’s School of Business, Queen’s University, Canada), Developments in Practice XXX: Master Data Management: Salvation Or Snake Oil ? In Communications of the Association for Information Systems, Volume 23, Article 4, pp. 63-72, juillet 2008.

Interviews auprès d’IT Managers de 15 organisations industrielles.

Ce post est une contribution d’Isabelle Boydens, Data Quality Expert chez Smals Research. Cet article est écrit en son nom propre et n’impacte en rien le point de vue de Smals

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 {a₁, a₂, …a_n}, waarbij de properties (p₁, p₂, …p_k) 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 (p_1+pa1, p_2+pa2, …p_k+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, Infosphere, …

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

Avec l’émergence et la complexité croissantes des applications informatiques, la documentation des données et des programmes est plus que jamais vitale, pour une bonne « data governance » quel que soit le secteur d’activité concerné.

Au seuil des années 2000, nous avons contribué à la mise en place des glossaires de la sécurité sociale et avons suivi leur développement par la suite. Pour cette raison, les concepts de cet article de blog nous sont familiers car certaines fonctionnalités n’ont pas changé depuis les années 2000.

Après une définition du concept de « Data Catalog » ou « système de méta-information ». nous en présentons dans les grandes lignes l’organisation, les fonctions principales [1] et les bonnes pratiques. En conclusion, nous dégageons un ensemble de recommandations méthodologiques généralisables.

Les systèmes de méta-information ou « Data Catalog » : définition et stratégie de gestion

« Méta-information » est souvent défini comme « information sur l’information ». Nous retenons ici la définition suivante : un système de méta-information est un système documentaire automatisé destiné à décrire un ensemble d’informations ou de données et ce faisant, à les interpréter en vue d’en faciliter la gestion. Le recours à de tels systèmes est stratégique lorsque l’information est un instrument d’action sur le réel[2].

La conception d’un système de méta-information s’inscrit dans le cadre d’une stratégie de gestion. Les coûts correspondants émanent des opérations d’analyse, de conception, de développement ou d’acquisition de software et de maintenance. Les bénéfices escomptés tiennent à une meilleure interprétation de l’information, à une réutilisation plus aisée des applications préexistantes, à une crédibilité accrue du système et à une diminution des coûts de gestion (corrections a posteriori de la base de données, réparation des préjudices dus à la diffusion de données incorrectes, …)[3].

Les systèmes de méta-information ou « Data Catalog » : fonctions

Data Ingestion, Rôles, IAM, gestion des règles

Nous présentons successivement les fonctionnalités suivantes : rôles et impact, gestion de champs multilingues, gestion des versions, mise en place de mécanismes d’héritage, application du concept de WOPM (Write Once Publish Many), standards, Graph Databases, publication en tant que REST API, système de recherche multibases, déploiement d’un worfklow de validation documentaire (incluant éventuellement du Machine Learning supervisé dans les Data Catalogs) et quelques mots sur les softwares.

Un Data Catalog doit être alimenté ou croisé automatiquement avec d’autres systèmes connexes : on appelle cela “data ingestion”. Ainsi, quand les glossaires de la sécurité sociale documentant les échanges d’information entre l’ONSS et les organismes prestataires, d’une part et les employeurs ou secrétariats sociaux agréés, d’autre part, créés au seuil des années 2000, l’alimentation des premières informations de base alors structurées en Word, fut réalisée via un programme PERL. D’autres méthodes plus modernes existent à cette fin en fonction du contexte.

Un Data Catalog s’adresse à la fois aux informaticiens et responsables business en charge de la gestion des bases de données, par exemple via un portail  accessible aux citoyens en charge de l’envoi des déclarations électroniques à l’administration, l’objectif étant que tous travaillent sur une base commune. Il s’agit que les droits d’accès soient gérés via un IAM.

Ce système de méta-information vise à automatiser partiellement les procédures ultérieures de saisie, de traduction et de validation de la documentation, à en renforcer l’intégrité et à en gérer les versions au fil des modifications législatives. Il s’agit de modéliser la connaissance et les processus qui l’engendrent : ainsi, le dictionnaire inclut à la fois des informations descriptives (par exemple, le domaine de définition d’un champ) et fonctionnelles (par exemple, la spécification formelle des contrôles destinés à tester les déclarations entrantes). Par ailleurs, les schémas des messages échangés entre les citoyens et l’administration ou toute autre partie peuvent être générés à partir du Data Catalog.

Gestion de champs multilingues

La documentation technique doit être diffusée dans les différentes langues nationales. Il en est de même dans tout contexte supranational. Des tables contrôlées multilingues (validées par les traducteurs, les juristes et l’IT) permettent, lors de la saisie des définitions, d’intégrer l’information dans une langue et d’obtenir ses contreparties dans les autres langues. L’esnsemble pourra être complété au niveau spécifique si nécessaire (voir plus loin : héritage). Ceci permet de minimiser la charge de travail manuel, d’accélérer le processus de saisie et de renforcer la cohérence de l’ensemble.

Gestion des versions

La gestion des versions est fondamentale dans le domaine  administratif[3]. En effet, la législation évolue fréquemment et toutes ses versions successives doivent être conservées au moins durant la période de prescription (par exemple, lorsqu’il s’agit de traiter des arriérés, il est fondamental de pouvoir retrouver les définitions antérieures de la base de données, les déclarations enregistrées ayant un statut légal de « force probante », c’est-à-dire qu’elles peuvent faire office de « preuve » lors d’un litige devant les tribunaux). Il est dès lors crucial d’identifier précisément les modifications apportées à chaque nouvelle version par rapport à la précédente. Ce « delta » est par ailleurs diffusé sous format standard, de telle sorte que les modifications puissent être intégrées de façon semi-structurée dans les applicatifs encadrant les bases de données. Chaque item spécifiant la description d’une donnée pour une version considérée renvoie à la fiche correspondante (dans la langue choisie par l’utilisateur) avec la mention des champs modifiés par rapport à la version immédiatement antérieure, en ce compris l’historique des documents supprimés.

Workflow de validation (et ML supervisé)

En raison des enjeux légaux, sociaux et financiers correspondants, chaque nouvelle version doit être validée par les informaticiens et les juristes concernés par celle-ci. En vue de structurer cette validation, un système de workflow guide le déploiement du data catalog. Celui-ci s’inscrit dans le cadre d’un planning annuel de mise à jour, spécifiant de façon rigoureuse les périodes de mise à jour, de validation, de mise en acceptation et de mise en production. Le workflow est « piloté » de façon centralisée par une équipe dédiée à cette tâche et se déploie sur un mode décentralisé dans le cadre de l’extranet de la sécurité sociale, par exemple (Figure 1). Lors de la création de chaque nouvelle version, l’historique des échanges entre les différents responsables est conservé, de façon à garder un suivi du processus d’interprétation. Une vue permet aux gestionnaires de suivre le nombre de « fiats » requis pour la publication d’une nouvelle version. Ceci permet d’avoir une vue sur différents data catalogs interconnectés.

Figure 1. Documentation des glossaires de la sécurité sociale : workflow IT et Business

A cela s’ajoutent actuellement des fonctions de ML supervisé avec intervention humaine pour valider les modifications de méta-données à partir des modifications de data (à condition que celles-ci aient préalablement été validées par les business rules des bases de données correspondantes pour éviter de générer une méta-donnée à partir d’une donnée incorrecte).

Héritage et réutilisation dans un contexte multilingue

Le système de méta-information est éventuellement destiné documenter plusieurs dizaines de bases de données administratives répertoriant de nombreux champs communs dont certaines caractéristiques sont identiques (format, par exemple) et d’autres, distinctes (caractère obligatoire ou facultatif d’un champ, par exemple). Un mécanisme d’héritage doit dès lors être mis en place.

L’héritage (Figure 2) se définit comme la relation entre une classe A générique (que nous appelons ici « stéréotype » ou vocabulaire commun peu évolutif) et l’ensemble de ses instances {a₁, a₂, … a_n}, où les propriétés (p₁, p₂, …p_k) de la classe A constituent un sous-ensemble des propriétés de chaque objet instantié à partir de la classe A. Lors de l’instantiation, ce sous-ensemble de propriétés génériques peut être complété par un autre sous-ensemble de propriétés spécifiques à chaque instance (p_1+pa1, p_2+pa2, …p_k+pan). Ce mécanisme est applicable à un nombre arbitraire de niveaux « méta ».

Figure 2. Documentation des glossaires de la sécurité sociale : principe de l’héritage

Les valeurs des propriétés génériques (« nom », « domaine de définition », « description », « type », « longueur ») du stéréotype « numéro de compte » sont ainsi stockées dans une table « contrôlée » de données structurées génériques prétraduites et prévalidées par les juristes et l’IT.

Les valeurs génériques et spécifiques sont ainsi concaténées en un champ semi-structuré. Ces fonctionnalités apportent des avantages en terme de temps de mise à jour (chaque valeur générique ne devant être encodée qu’une seule fois) et en terme de cohérence. Le système permet d’assurer que les données communes reçoivent les mêmes valeurs et d’éviter les erreurs humaines inhérentes à l’encodage manuel.

WOPM (Write Once Publish Many), Standards, Graph Database et publication sous forme de REST API

L’application inclut des listes structurées (codes postaux, catégories d’activité, …) qui, dans la pratique, doivent être diffusées à des fins documentaires (dans l’esprit d’un “système de méta-information”) mais aussi en vue de tester les déclarations envoyées par les citoyens et stockées dans les bases de données. Afin de rencontrer les deux fonctions, l’application doit être conçue dans l’optique du concept WOPM (« Write Once Publish Many ») de façon à générer automatiquement une même table structurée (liste de codes postaux, par exemple) sous différents formats : formats lisibles par l’humain et par la machine. La même source peut ainsi être utilisée au sein d’applications interdépendantes.

A l’heure actuelle, dans la mouvance du « Web sémantique », les normes en la matière sont devenues nombreuses. Les unes offrent des syntaxes génériques permettant le déploiement de méta-données, tel que DCAT, recommandation de l’UE. A ces normes, sur le plan technique, peuvent s’ajouter XML ou JSON, particulièrement utile pour la fusion de tables (Figure 4) et d’autres formats encore.

Une graph database (Figure 3) permet de visualiser l’état des relation entre différents « Data Catalogs » et pour ceux-ci, la part des méta-données complétées ou pas. En fonction de leur état plus ou moins complet, on peut décider de la publication d’un “data catalog” sous forme de REST API au sein d’une institution (Figure 3).

Figure 3. intérêt d’une graph database pour suivre la complétude d’un data Catalog Source : Collibra website

Le Data Catalog peut être publié sous forme de REST API et accueillir lui-même d’autres REST API ou « plugger » des logiciels commerciaux préexistants, certains standards comme JSON cité plus haut (Figure 4) favorisent ces liens (1).

Figure 4. Exemple de mapping de 2 systèmes de méta-données via JSON (Source voir note 3)

Système de recherche multibases

Un outil de recherche «multibase » (Figure 5) doit être mis en place, permettant une recherche « full text » à travers le système documentaire intégré sur base de paramètres spécifiques avec recours à la logique booléenne de même que des systèmes de tri et de filtrage. L’output de l’outil de recherche peut se présenter sous différents formats en fonction des usages poursuivis (lisible par l’homme ou par la machine).

Figure 5. Exemple de recherches multibases, multilingues et multichamps avec options (source : glossaires de la sécurité sociale)

Evaluation continue et maintien de la qualité des données et des méta-données

Un maintien de la qualité des données et des méta-données est fondamental. Deux approches complémentaires existent. On peut travailler via un data quality tool complet afin de traiter les problèmes déjà présents dans les bases de données incluant les fonctions de profiling, standardization et matching (approche curative). On peut pour que les mêmes erreurs ne reviennent pas “ad infinitum” à la source, procéder via back tracking et ATMS (approche préventive), inventée au sein de Smals Research pour résoudre à la source les causes des problèmes de qualité (voir catalogue Reuse). Améliorer de manière continue la qualité des données et des méta-données correspondantes est crucial (voir le centre de compétence “data quality” sur le web site de Smals incluant des REST API sur le catalogue Software ReUse de Smals) (5).

Softwares

Au niveau software, outre des solutions « home made », comme les glossaires de la sécurité sociale auxquels plusieurs images de cet article de blog réfèrent, il existe des environnements de développement « open source » comme Egeria demandant du développement, ou bien des outils commerciaux, comme Collibra, Altan, Infosphere, …

Les systèmes de méta-information : recommandations méthodologiques  

Les systèmes de méta-information comportent potentiellement trois écueils. Le premier est lié à ce que ces systèmes sont extensibles à l’infini., surtout lorsque les champs à compléter sont « libres », le langage naturel étant son propre méta-langage. Ceci implique des coûts importants en termes de gestion, lorsque les mises à jour manuelles sont nombreuses. Le second écueil tient à ce que les méta-données peuvent être elles-mêmes erronées et incertaines : lorsqu’elles sont d’ordre contextuel, leur validation ne peut faire l’objet de contraintes d’intégrité rigoureuses. Le troisième écueil tient au décalage temporel entre la mise à jour d’une donnée et de la méta-donnée correspondante, cette dernière, surtout lorsqu’elle se présente sous une forme textuelle, n’étant généralement créée qu’au terme d’une phase d’analyse.

Ainsi, dans une communication retentissante, “The Metadata Myth…”[4], plusieurs auteurs évoquent les inextricables difficultés pratiques que soulève “l’usage abusif” des méta-données. Dans le domaine des bases de données géospatiales exploitées par le Bureau of census et la National Aeronautics and Space Administration (NASA), la mise en place d’un système de méta-information fédéral pour lequel chaque nouvel enregistrement nécessitait l’intégration d‘environ 300 méta-données a entraîné les avatars suivants : coûts exorbitants en personnel et en ressources, lourdeur des mises à jour, ésotérisme de la documentation et finalement, réduction considérable de l’échange des données. Cependant, la NASA n’a pas abandonné ce système qui a toutefois fait l’objet d’une simplification et d’une restructuration.

Sur base des expériences en la matière, nous proposons les cinq recommandations suivantes :

• l’identification d’un ensemble minimal de méta-données obligatoires.
• une préférence pour les méta-informations générées automatiquement (ou sur base de listes de valeurs contrôlées par exemple) car ces informations sont moins “coûteuses” en termes de mise à jour et plus fiables (cfr ML supervisé sous les conditions indiquées plus haut).
• la création de plusieurs niveaux de méta-données adaptés en fonction des usages (méta-données génériques et spécifiques, par exemple).
• La mise en place de liens directs entre les applicatifs documentés et les méta-données correspondantes (principe d’intégrité et de cohérence).
• Appliquer tout au long du cycle de vie du Data Catalog des KPI pour monitorer différentes métriques importantes, comme le taux de consultation des différentes parties du Data Catalog (6).

Au delà de l’application présentée dans cet article, ces recommandations s’appliquent à toute base de données empiriques dont l’interprétation est stratégique, en tant qu’instrument d’action sur le réel et donc, à tout « Data Catatog » .

Ce post est une contribution d’Isabelle Boydens, Data Quality Expert chez Smals Research. Cet article est écrit en son nom propre et n’impacte en rien le point de vue de Smals.

[1] O. Olesen-Bagneux, The Entreprise Data Catalog :Improve Data Discovery, Ensure Data Governance, and Enable Innovation. Boston, O’Reilly, 2023.

[2] « En mai 1999, pendant son intervention au Kosovo, l’Otan a bombardé par erreur l’ambassade de Chine à Belgrade : les bases de données cartographiques alors utilisées pour guider les missiles répertoriaient un plan de la ville obsolète et, donc, inadéquat” BOYDENS I., L’océan des données et le canal des normes. In CARRIEU-COSTA M.-J., BRYDEN A. et COUVEINHES P. éds, Les Annales des Mines, Série “Responsabilité et Environnement” (numéro thématique : “La normalisation : principes, histoire, évolutions et perspectives”), Paris, n° 67, juillet 2012, pp. 22-29 (lien vers l’article – sommaire du numéro 67 des 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. et BOYDENS I., éds., “Practical Studies in E-Government : Best Practices from Around the World”, New York, Springer, 2011, p. 113-130 (chapitre 7). BOYDENS I., HAMITI G. et VAN EECKHOUT R., A service at the heart of database quality. Presentation of an ATMS prototype. In Le Courrier des statistiques, Paris, INSEE, 2023, n°6, 11 p. (publié le 2/10/2023). Lien vers l’article.

[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