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.

[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).

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

Automatisering is een belangrijk wapen om het Mattheus-effect tegen te gaan. Het automatisch toekennen van bepaalde voordelen aan de hand van objectieve criteria zorgt idealiter voor een gelijke behandeling van alle burgers ongeacht stand en rang. Daarnaast zorgt automatisering ook voor tijdswinst, minder papier, en lagere kosten op lange termijn. Veel projecten waar Smals bij betrokken is, dragen daar aanzienlijk toe bij: ze besparen de overheid, burgers en bedrijven jaarlijks miljarden euro’s, om niet te zeggen tonnen papier, inkt en postzegels.

We schreven al uitvoerig over de talloze randvoorwaarden die opduiken als men Artificiële Intelligentie correct wil inzetten ([1], [2], [3], [4], [5], [6]), maar ook een gewone procesautomatisering, zelfs digitalisering, is niet zomaar vrijblijvend, en al zeker niet bij overheden. Automatisering is niet gelijk aan artificiële intelligentie, maar men geeft nog steeds een deel van de controle uit handen aan een machine. Naast winsten in snelheid en kostprijs, kan dat ook allerlei beperkingen introduceren. Door de schaalvergroting loopt het, als het fout loopt, ook ineens heel erg fout. Reden genoeg om reeds vanaf de planningsfase nauwgezet aandacht te besteden aan de bredere effecten van een automatiseringsproject.

Wil een geautomatiseerd proces goed werken, dan is het belangrijk dat het actief en “als een goede huisvader” wordt beheerd. Permanente monitoring is nodig zodat problemen snel gedetecteerd en opgelost kunnen worden. Manueel ingrijpen moet mogelijk blijven, het moet duidelijk zijn wie waarvoor verantwoordelijk is, en alles moet mee evolueren wanneer nodig. In het Engels wordt dat al eens aangeduid met (corporate) “governance“, vrij vertaald “deugdelijk bestuur”. Het is een vaag begrip, maar in dit artikel hoop ik het belang ervan te kunnen illustreren aan de hand van enkele spraakmakende voorbeelden uit het buitenland.

(afbeelding: “corporate governance”, (c) Asmi-corporatereporting.com, 2017, Licensed CC BY-SA 4.0 https://creativecommons.org/licenses/by-sa/4.0, via Wikimedia Commons)

Wat kan er zoal misgaan?

Frankrijk

De Franse Caisse des Allocations Familiale (CAF) nam in 2021 een nieuw systeem in gebruik voor de berekening van huisvestingstoelagen. Helaas was het systeem niet volledig compatibel met een ander systeem voor de registratie van sommige arbeidsprestaties, nodig om de hoogte van die uitkering te bepalen. Als gevolg kregen minstens 120.000 mensen een foutieve schuldvordering in de bus, automatisch aangemaakt, voor zogezegd teveel ontvangen uitkeringen. De toevloed aan reacties, en alle correcties die vaak manueel aangebracht moesten worden, zorgden voor veel extra werklast bij de dienst die al met veel vertragingen te kampen had, wat op zijn beurt aanleiding gaf tot stakingen. Negen maanden later wachtten nog steeds 32.000 mensen op de correctie van hun dossier.

Verenigd Koninkrijk

Het Verenigd Koninkrijk heeft geen rijksregister zoals België. Mensen moeten hun identiteit op een andere manier bewijzen: met een rijbewijs, bankrekening, telefooncontract of een internationaal paspoort. Dat zorgt al voor een eerste probleem, omdat net de meest kwetsbaren die het meeste belang hebben bij die diensten, door hun kleinere administratieve/digitale voetafdruk niet geauthenticeerd geraken. Daarnaast is identiteitsfraude een groot probleem.

Universal Credit is een geautomatiseerd sociaal vangnet voor de laagste inkomens, dat bestaat uit de fusie van 6 aparte uitkeringen. Hun doel om de zaken te vereenvoudigen hebben ze echter ook doorgetrokken in de berekeningswijze: die neemt enkel het inkomen van een vorige maand in rekening. Dat zorgt voor grote problemen bij mensen die onregelmatig betaald krijgen, of wanneer loon plots vervroegd uitbetaald wordt omwille van feestdagen: zij hebben in sommige maanden plots een hoger inkomen, in andere maanden geen, en krijgen daardoor heel erg fluctuerende uitkeringen. Het perverse effect daarvan is dat twee mensen met dezelfde job, gezinssamenstelling en jaarinkomen, toch verschillende uitkeringen kunnen krijgen, enkel en alleen omdat hun salaris op een ander moment wordt uitbetaald.

Een rechtszaak daarover werd door de Britse overheid verloren. Het maken van de opgedragen aanpassingen zal de kost van het geplaagde systeem, nu reeds lopend in de miljarden pond, alleen nog maar verder doen toenemen. Let wel dat het probleem hier niet zozeer bij de automatisering ligt, wel bij het ontwerp: de regering had expliciet besloten tot deze berekeningswijze, omdat ze gemakkelijker en efficiënter te implementeren was.

(afbeelding: Wordmark for Universal Credit, (c) UK Government, licensed under the Open Government Licence version 1.0 (OGL v1.0).

Australië

In Australië deed de RoboDebt affaire veel stof opwaaien. Frauduleus betaalde uitkeringen terugvorderen deden ze al langer, maar in 2015 maakten ze een cruciale verandering: het verifiëren van een “match” tussen de databanken sociale zekerheid (DHS) en financiën (ATO), werd geautomatiseerd. Dat nam effectief een stap van menselijke controle in de ketting weg. Het hoofddoel was om elke “match” op te volgen, daar waar ze vroeger slechts de meest flagrante inbreuken konden najagen omwille van het manuele werk. Dat leidde in het eerste jaar al tot een 40 keer hoger volume.

Helaas was niet elke “match” ook terecht. De uitkeringen werden immers in perioden van 14 dagen toegekend, terwijl de belastingdienst gegevens had per fiscaal jaar. Bij gebrek aan inkomstengegevens per 14 dagen werd een gemiddelde van het jaarinkomen toegepast, maar net zoals in het voorbeeld van UK, leidde dat tot ongewenste neveneffecten, en moesten burgers plots schulden gaan terugbetalen die ze nooit gemaakt hadden. In 2019 werd het systeem door de rechtbank onwettelijk verklaard, en in 2021 moest de overheid een schikking ter waarde van $1.8 miljard Australische dollar treffen met de bijna 500.000 gedupeerden. Ook hier lag de fout bij de wetgever, die niet voldoende had nagedacht over de aannames en mogelijke neveneffecten bij het opstellen van de berekeningswijze van het systeem.

USA

In de Verenigde Staten doken problemen op bij de automatisering van RAI. Dit Resident Assessment Instrument is een lange vragenlijst voor zwaar zorgbehoevenden. Aan de hand van het resultaat wordt o.a. berekend op hoeveel thuiszorg iemand een beroep mag doen. Ook in België wordt een variant ervan gebruikt die BelRAI heet. Het automatiseren daarvan moet heel omzichtig gebeuren. Als bijvoorbeeld de vraag of iemand voetproblemen heeft beantwoord wordt met “nee”, kan dat zijn omdat die gezond is, maar even goed omdat die geamputeerde voeten heeft – en die laatste behoeft uiteraard meer zorg.

In Arkansas liep het fout bij onderaannemers die een verkeerde versie van de vragenlijst hadden gebruikt, en daarnaast bepaalde ziektebeelden, zoals hersenverlamming, niet correct hadden verwerkt. Pas tijdens de rechtszaak werd duidelijk waar de fouten precies lagen, o.a. doordat de rechter verplichtte om de resultaten eens manueel na te rekenen. Het systeem bleek dermate complex, en de code werd zodanig afgeschermd, dat ook de bevoegde ambtenaren niet in staat waren geweest om de fout te ontdekken. Zo was het voor eindgebruikers nooit duidelijk waarom de evaluatie tot een bepaald resultaat leidde, wat het op zijn beurt erg moeilijk maakte een evaluatie aan te vechten of te overreden. Het gebruik van RAI op zich werd door de rechtbank wel als wettig beschouwd.

India

India heeft hetzelfde probleem als het Verenigd Koninkrijk, nl. dat het lange tijd geen eengemaakt burgerregister had en dat andere systemen (rijbewijzen, stembiljetten, geboorteaktes) onderling incompatibel zijn. Het bijhouden van gegevens op kaartjes en papieren is er ook geen sinecure voor de armeren en ongeletterden onder hun bevolking. In een ambitieus programma om iedere Indiër een sociaal identiteitsnummer te geven (zoals onze vroegere SIS-kaart), startte India het Aadhaar project, dat ook biometrische authenticatie op basis van de vingerafdruk omvat.

(afbeelding: “A sample of Aadhaar card”, by Pagelmp, licensed under the Creative Commons Attribution-Share Alike 4.0 International license. Source Wikimedia Commons.)

De praktijk blijkt echter weerbarstiger. Er zijn technologische vereisten om het te kunnen toepassen: een vingerafdruklezer en een stabiele internetverbinding. Bovendien zijn de vingerafdrukken niet altijd meer herkenbaar bij wie een leven lang handenarbeid heeft verricht. Ook fouten bij de manuele data-entry, wat tijd en geld kost om te laten corrigeren, zorgen voor problemen. Er duiken dan ook veel rapporten op van grote aantallen kwetsbaren die de toegang tot sociale diensten, onderwijs, vergunningen, kindergeld of voedselrantsoenen wordt ontzegd omdat ze door de mazen van het Aadhaar-systeem vallen.

Nederland

In Nederland viel de regering over de toeslagenaffaire. Vele duizenden gezinnen kwamen in grote problemen door onterechte beschuldigingen van subsidiefraude. De affaire is complex, maar aan de basis ligt de opsporingsdienst voor belastingfraude die zich danig heeft vergaloppeerd. Het probleem lag hier o.a. bij een gebrekkige training en validatie van een machine-learning model, dat een risicoclassificatie moest geven aan dossiers en daarbij zonder veel nadenken steunde op parameters zoals nationaliteit, die erg gevoelig zijn voor discriminatie. Daarnaast was de inhoud van verschillende onderliggende databanken, o.a. de Fraude Signalerings Voorziening, onoordeelkundig verzameld: een telefoontje naar de belastingdienst kon voldoende zijn om erin opgenomen te zijn als potentieel fraudeur. De opsporingsdienst vertrouwde echter quasi blindelings op de gegevens en risicoscores, en gebruikte ze als rechtvaardiging om drastisch te werk te gaan bij terugvorderingen, weigeringen van afbetalingsplannen, enz. Daarbij ontbrak het aan een richtinggevend kader van bovenaf, interne monitoring of audit, en mogelijkheden tot aantekenen van beroep. De databank werd op basis van inbreuken op de privacywetgeving stopgezet en de belastingdienst kreeg een stevige boete.

Conclusie

De bovenstaande verhalen hebben meestal 1 ding gemeen: alles gaat goed totdat op een bepaald moment ergens een bocht teveel wordt afgesneden zonder dat er tijdig wordt ingegrepen. Dat moet ons niet tegenhouden om te automatiseren, want er zijn ook duidelijke voordelen: voor de overheid qua schaalbaarheid, voor de burger o.a. door vermindering van administratie. Met dit artikel willen we vooral aandacht vestigen op de noodzaak om daarbij voldoende te investeren in planning en opvolging, om een goede grip te houden. Dat omvat ook een realistische blik, aandacht voor user experience en duidelijke adoptie van waarden en principes (transparantie, accountability, …).

Het grote verschil tussen een ambtenaar in persoon en een geautomatiseerd systeem, is dat een ambtenaar aanpassingen kan maken en verfijningen kan toebrengen nog voordat een beslissing genomen wordt, terwijl een algoritme enkel maar gecorrigeerd kan worden nadat het al een beslissing heeft gemaakt. Dat laatste veroorzaakt frustratie en een nood aan ingrijpen achteraf. Er is een risico dat bepaalde doelgroepen onevenredig het slachtoffer zijn van zulke fouten. Ook kan bij de gebruikers van geautomatiseerde systemen, een zekere verblinding, laksheid, of neiging tot het afschuiven van verantwoordelijkheid ontstaan: “de computer zegt het dus het zal wel zo zijn”. Er moeten dus toegankelijke procedures zijn om beroep aan te tekenen tegen een beslissing en correcties moeten eenvoudig doorgevoerd kunnen worden.

Daarnaast blijft het altijd mogelijk dat programmeurs de regels onvolledig of foutief inbrengen in een programma, of dat ze andere interpretaties en aannames hanteren dan de regelgevers. Er is dus nood aan een zekere waakzaamheid, transparantie en inspraak in het hele implementatieproces, zeg maar “project governance“. Ook de uitvoerende ambtenaren moeten blijven begrijpen wat er gebeurt en waarom. Daarbij hoort ook een goede methode om feedback te verwerken die vanop de werkvloer aangebracht wordt.

Er bestaat vooralsnog geen vaste manier om compliance of governance ontegensprekelijk te garanderen. Het zijn nog steeds vage begrippen, en ook nogal wat wetgeving blijft vaag: zo staat het woord “redelijk” maar liefst 38 keer in de GDPR, en het woord “passend” zelfs 125 keer, zonder verdere specificatie van wat we daar nu concreet onder moeten verstaan. In de VS worden basisregels voor bedrijfsbeheer opgelegd door de Sarbanes-Oxley Act. In België bestaan er de Code Lippens voor beursgenoteerde, en Code Buysse voor niet-beursgenoteerde ondernemingen. Ondertussen wordt in Europa verder gewerkt aan o.a. een Data Governance Act om een kader te scheppen voor verantwoord (her)gebruik van gegevens.

Deze en andere regulatorische raamwerken zijn misschien niet perfect sluitend. Ze adopteren, eventueel certifiëren, en regelmatig eraan toetsen, zorgt op korte termijn wel voor extra overhead en kosten, maar het legt de lat ook hoger en kan zo op lange termijn veel zorgen voorkomen. Het is ook meestal goede reclame. Uit alle aangehaalde voorbeelden blijkt natuurlijk ook dat daarvoor de nodige wil moet bestaan bij, en middelen ter beschikking gesteld moeten worden door, de bevoegde beleidsmakers.

______________________

Dit is een ingezonden bijdrage van Joachim Ganseman, IT consultant bij Smals Research.  Dit artikel werd geschreven in eigen naam en neemt geen standpunt in namens Smals.

Dit maakt het werk van de datawetenschapper of -analist er niet gemakkelijker op. Even een (deel van een) dataset hergebruiken voor een experiment, zelfs al blijft alles intern, is niet zomaar mogelijk. Strikt genomen mag ook het testen van software die persoonsgegevens moet verwerken, niet gebeuren met echte persoonsgegevens als die personen daar niet expliciet mee ingestemd hebben.

Mede daarom vindt het concept van “synthetic data” opgang. Om niet te moeten werken met echte gegevens, is het doel daarbij om een dataset te maken van fictieve gegevens, die de statistische eigenschappen van de oorspronkelijke gegevens simuleert. Dat kan eventueel ook toegepast worden op slechts een deel van een dataset, bijvoorbeeld om een dataset beter te balanceren, of om de onderdelen met privacygevoelige gegevens te maskeren of anonimiseren. Synthetische data kunnen ook nuttig zijn als simulatieomgeving voor het ontwikkelen van machine learning toepassingen.

Data genereren

Het aanmaken van data kan niet zomaar willekeurig gebeuren. Wat je kan wijzigen en hoe je het wijzigt hangt immers af van wat je er mee wil doen. Neem als praktisch voorbeeld het Belgische rijksregister. Dat bevat van iedere Belg o.a. de woonplaats. Stel dat we een fictief rijksregister aanmaken met 11 miljoen fictieve Belgen om een toepassing te testen die gelinkt moet worden aan het rijksregister. Je kan je wel inbeelden dat het in sommige toepassingen noodzakelijk is dat een opgegeven adres ook effectief bestaat, terwijl dat ergens anders misschien helemaal niet belangrijk is. Waar je dus voor de ene toepassing fictieve steden met fictieve straten zal kunnen genereren (pakweg de Gobelijnstraat in Zonnedorp), zal het voor andere toepassingen wel belangrijk zijn dat de adressen wel bestaan en voorkomen in de officiële databases van adressen en straten.

Daarnaast kan het nodig zijn ook de distributie van sommige gegevens te behouden. Dit is vaak zo bij ongelijk verdeelde kenmerken, zoals bloedgroep. Of nog een ander voorbeeld: als gemeentelijke bevolkingsaantallen een belangrijk te behouden aspect zijn, zal een synthetische dataset evenveel fictieve Antwerpenaren moeten bevatten als er ook echt wonen, misschien zelfs correct verdeeld over de districten en/of wijken als de toepassing daarom vraagt.

Wat betreft demografische data bestaan er enkele kant en klare tools waarmee een dataset gegenereerd kan worden – we denken aan Synthpop of Faker. Deze hebben eerst toegang nodig tot de bestaande gegevens om daar een analyse van te maken, zoals welke voornamen en achternamen voorkomen in welke hoeveelheden, en of er bepaalde correlaties bestaan in de gegevens (een typisch voorbeeld is de correlatie tussen voornaam en geslacht). Na deze analysefase kan dan een synthesefase volgen om een fictieve demografische dataset op te stellen. Deze manier van werken wordt ook gevolgd door algemenere tools zoals DTM Data Generator.

Anonimisering

Synthetische data wordt ook aangemaakt om de privacy te beschermen van de burger. Dit is bijvoorbeeld nuttig in epidemiologische studies. Een onderzoeker wil daarvoor toegang hebben tot de verzameling van medische dossiers in een bepaalde regio, om te bekijken hoe de verspreiding van een besmettelijke ziekte verloopt. Het spreekt voor zich dat de privacy van iedere patiënt gewaarborgd moet zijn: de onderzoeker in kwestie mag geen individuele medische gegevens inzien.

Zulke gegevens worden daarom vaak geaggregeerd gepubliceerd: samengeteld in grotere groepen, of in histogrammen, waarbinnen een enkel individu niet meer te identificeren is. Maar dat is niet altijd evident: stel dat een persoon mazelen heeft maar daarbovenop ook een zeldzame ziekte waarvan slechts 1 geval bekend is in die regio. Dan mag je nog de naam, leeftijd en geslacht verwijderen uit het bestand: iemand met de nodige achtergrondkennis kan achterhalen over wie het gaat. Er mag dus geen enkele unieke combinatie van gegevens voorkomen in een dataset wil ze een zekere mate van anonimiteit kunnen waarborgen (de veralgemening van dit principe staat bekend als k-anonimiteit). Dit wordt al snel moeilijker te verwezenlijken naarmate een dataset meer velden bevat of ongebalanceerder is.

Een volledig synthetische dataset kan wel een interessante oplossing bieden: zelfs als die de statistische eigenschappen nabootst van de reële data, dan nog is eender welk geïdentificeerd persoon sowieso onbestaand. SyntheticMass is zo’n dataset van 1 miljoen fictieve inwoners van Massachussets, met fictieve gezondheidsdossiers, echter wel volgens de bestaande verdelingen en distributies toegekend. Je kan die oefening zelf herhalen met de datagenerator Synthea.

Differential Privacy

Een ander maar gerelateerd probleem is dat iemand toch nog aan individuele informatie zou kunnen komen via een omweg, door een database te bestoken met queries en de output daarvan te vergelijken. Dit geeft aanleiding tot het concept differential privacy. Om in dit geval toch privacy te waarborgen, zal men willekeurige informatie (“noise”) toevoegen aan de query-output zodat de gevoelige info verborgen blijft zonder dat de statistische eigenschappen sterk wijzigen. DataSynthesizer , een project van een onderzoeksgroep aan NYU, is een tool voor het genereren van synthetische data die qua differential privacy bepaalde garanties probeert te geven.

Het zou ons hier te ver leiden om op deze problematiek dieper in te gaan, maar ik verwijs tot slot graag door naar het LINDDUN project van de KULeuven als startpunt voor diepgravender informatie over anonimisering, identificeerbaarheid, traceerbaarheid en informatielekken.

Toepassingen in AI

De naam zegt het al, in Generative Adversarial Networks (GAN, een type neuraal netwerk) zit een datagenerator verwerkt. Deze kan worden getraind om data te genereren die synthetisch maar nauwelijks van het origineel te onderscheiden is. Een spectaculaire toepassing is ongetwijfeld het kunnen aanmaken van foto’s van volledig fictieve, onbestaande personen – zo krijg je iedere keer dat je de pagina https://thispersondoesnotexist.com/ ververst, een foto van een onbestaand persoon te zien. (Er zijn ondertussen ook versies voor katten, paarden, moderne kunst en chemische moleculen).

Data augmentation is een beproefde techniek bij het trainen van neurale netwerken, om de robuustheid te verhogen als er niet voldoende trainingsdata is. Door allerlei transformaties uit te voeren op een beperkte set trainingsdata kan je toch nog aan genoeg gegevens geraken om een relatief robuust neural netwerk op te zetten. Dit is met name voor beeldverwerking erg nuttig, om het systeem te leren omgaan met variaties in rotatie, oriëntatie en schaling van een afbeelding. Er is geen tekort aan software libraries die met dit doel kunnen ingezet worden, zie bvb. albumentations, augmentor of imgaug. Gelijkaardige transformaties kunnen ook ingezet worden voor andere soorten data zoals audio.

Als echte data niet beschikbaar mag worden gesteld, kan een AI-model initieel getraind worden op een synthetische dataset die lijkt op het origineel. Door transfer learning toe te passen kan men dat model achteraf proberen finetunen voor de reële data. Dit blijkt onder andere nuttig bij de ontwikkeling van zelfrijdende auto’s, waar men de eerste trainingsuren liever in een simulator uitvoert dan op de echte weg. Verwant daarmee is een truc die men kan toepassen als geannoteerde data erg duur of zeldzaam is: men kan goedkoop synthetisch gelabelde data genereren, die combineren met ongeannoteerde echte data, en een vorm van semi-supervised learning toepassen. Het idee is gelijkaardig: een AI-model wordt geïnitialiseerd op synthetische data en dan bijgestuurd middels de echte data. Onder andere in spraakherkenning lijkt dit een veelbelovende piste om een AI-systeem te leren omgaan met een heel palet aan stemmen en dialecten, zonder van ieder denkbaar stemtimbre urenlange opnames te moeten verzamelen.

Andere gebruiken van synthetische data

Synthetische data is een ietwat wazige term en er is nog geen algemene consensus over een strikte definitie, of wat daar precies onder valt en wat niet. Als we het breed bekijken kunnen we nog allerlei andere toepassingen beschouwen waarbij gegevens met synthetische oorsprong een rol spelen.

In verse installaties of tutorials van software populeert men al eens een voorbeelddatabase met willekeurige data. Er bestaan specifieke tools om dat voor elkaar te krijgen, zie bvb. Fake2db of pydbgen in Python.

In software testing is Fuzzing een techniek waarbij automatisch gegenereerde data wordt gevoed aan een systeem om het te testen op o.a. robuustheid – ClusterFuzz is een bekend voorbeeld van het gebruik in de praktijk. Met wat goede wil kan men ook Mutation Testing zien als een techniek waarbij synthetische aanpassingen aan de bestaande code worden gemaakt, met als doel om te kijken of de tests hun werk wel goed doen. Als er regelmatig data aangemaakt moet worden voor een veelheid van scenario’s en verschillende soorten testen, kan het in grote projecten nuttig zijn om een Test Data Management platform te overwegen, waar een configureerbare test data generator een onderdeel van kan zijn.

Nogal wat simulatieomgevingen zijn synthetisch aangemaakt. Dat kan gaan van volledig virtuele werelden, zoals die in veel games ontworpen worden, tot simulaties waarbij wordt ge-extrapoleerd vanuit verschillende bestaande datasets – daarvan is de laatste Microsoft Flight Simulator een goed voorbeeld.

Conclusie

Synthetische data kunnen een erg nuttig substituut zijn in verschillende scenario’s waar de echte data niet zomaar vrijgegeven mag worden, of waar echte data te duur of te moeilijk is om aan te geraken.

Het aanmaken van synthetische data die nuttig is voor een specifieke toepassing, vraagt weliswaar enige achtergrondkennis. Hoe zal de data worden aangewend? Dat bepaalt immers de eigenschappen waaraan synthetische data moet voldoen. Bijgevolg is het haast nooit mogelijk om “blind” een generieke tool in te zetten om synthetische data aan te maken, en blijft een goed begrip van de echte data onontbeerlijk. Het doel is om een synthetische dataset te bekomen die representatief is voor het origineel. Daarbij moet niet alleen met de pure statistische metrieken maar ook met eventuele correlaties en diepere verbanden tussen verschillende gegevens rekening gehouden worden.

Bijkomende validaties kunnen daarom zeker geen kwaad. In het domein AI zien we sinds kort veel inspanning om tools te ontwikkelen voor o.a. detectie van bias en privacyrisico’s. De data-auditing capaciteiten daarvan zouden eventueel ook aangewend kunnen worden om te bevestigen dat een synthetische dataset representatief, bruikbaar en bovendien veilig is.

______________________

Dit is een ingezonden bijdrage van Joachim Ganseman, IT consultant bij Smals Research.  Dit artikel werd geschreven in eigen naam en neemt geen standpunt in namens Smals.

Comme nous l’avons vu dans la première partie de ce post, il n’y a jamais de projection biunivoque nécessaire entre un domaine d’application empirique et le système d’information correspondant. La métaphore de la carte et du territoire proposée par l’informaticien William Kent en fournit une illustration imagée dans son excellent ouvrage “Data and reality. Basic Assumption in Data Processing Reconsidered” :

“A message to mapmakers : highways are not painted red. Rivers don’t have county lines running down the middle and you can’t see contour lines on a mountain.” (I)  

Comme Kent l’indique, le processus de généralisation et d’abstraction d’une réalité est toutefois indispensable en vue de conférer un pouvoir opérationnel aux données dans le contexte informatique. Nous avons observé de ce fait, à travers la notion de “temporalités étagée”, qu’il y a, dans le domaine de l’administration publique, des interactions permanentes entre l’évolution asynchrone des trois ordres de réalité suivants :

• les textes légaux;
• les systèmes d’information administratifs censés les représenter et en assurer la mise en oeuvre opérationnelle
• et, enfin, de la réalité correspondante, le monde de la population assujetie à la législation.

La prise en compte de ces trois niveaux de réalité hétérogènes et de leurs interactions permet d’avoir une vue d’ensemble sur les données, préalable indispensable en vue d’en envisager la simplification. Nous en avons présenté, sur la base d’exemples dans la partie I de ce post, une schématisation originale référencée ci-dessous. Ce modèle,  que nous avons proposé pour la première fois dans (Boydens I., “Informatique, normes et temps”, … voir II) est cité et développé par David Bade, de l’Université de Chicago, dans sa recension parue en 2011 (III)  et fut récemment appliqué à grande échelle et cité lors de la  “Metadata and Semantics Research – 8th Research Conference, MTSR 2014“, qui s’est tenue à Karlsruhe (VII). Celle-ci permet de formuler des recommandations opérationnelles afin de simplifier et faciliter la gestion des données que nous allons présenter ici.

Transformation mechanisms to interpret administrative data 

(source : I. Boydens, “Strategic Issues Relating to Data Quality for E-government: Learning from an Approach Adopted in Belgium“. In Assar S., Boughazala I. et Boydens I., éds., “Practical Studies in E-Government : Best Practices from Around the World”, New York, Springer, 2011, p. 120.) 

I. Approche pragmatique : synergies et collaborations

Théoriquement, afin de faciliter et de simplifier la gestion d’un tel ensemble, deux positions extrêmes et caricaturales pourraient être formulées  :

• L’informatique, au service du législateur, peut tout faire, quelle que soit la complexité des lois, leur enchevêtrement au fil des ans et la quantité d’exceptions (point de vue juridique extrême)
• Si la loi était formulée de manière logique et univoque, sous une forme statique, déterministe et algébrique, aucun problème de qualité et d’interprétation de données ne se poserait sur le plan opérationnel (point de vue informatique extrême).

Face à ces deux assertions, il est possible de répondre que, d’une part, l’informatique ne peut pas tout modéliser à n’importe quel coût et que l’abondance d’exceptions et de définitions hétérogènes est ingérable pratiquement. Et d’autre part, nous pouvons affirmer que la loi doit nécessairement traiter une réalité complexe et évolutive, avec l’évolution parfois imprévisible des moeurs et des droits sociaux, au fil des négociations entre partenaires, réalité qui ne peut répondre a priori a un formalisme purement logique.

Aussi, nous efforcerons-nous, dans l’esprit des initiatives menées par l’ASA, d’avoir un point de vue réaliste, entre ces deux points de vues extrêmes. Nous insisterons sur les synergies nécessaires et les bonnes pratiques à adopter idéalement, tant sur le plan juridique, que sur le plan opérationnel de la gestion d’un système d’information. Une collaboration entre les différents intervenants étant la seule piste envisageable. A cette fin, nous nous inspirons d’initiatives récentes menées en 2015 tant en Belgique qu’à l’étranger (Union Européenne, OCDE, United Nations, …) et ce, tant dans les secteurs publics que privés.

2. Initiatives de simplification sur le plan juridique

Dans l’esprit pragmatique d’une synergie, plusieurs initiatives concernent tendantiellement davantage l’environnement juridique.

Une analyse d’impact de la réglementation, tel que le modèle AIR de l’ASA-DAV, permet potentiellement d’évaluer les conséquences transversales de certaines modifications sur l’environnement concerné.

A propos de la simplification des lois ou de la réglementation, il existe un arbitrage entre deux approches :

• l’élaboration de spécifications très détaillées qui peut demander un temps important de négociation et est moins résistante au changement;
• l’élaboration de spécifications plus génériques, éventuellement plus clairement négociées, plus résistantes au changement mais laissant la place à un certain flou dans la mise en oeuvre pratique.

La seconde piste peut être recommandée, quand la teneur des réalités à réglementer le permet, pour sa résistance au temps, sa généricité et sa simplicité, elle demande toutefois lors de sa traduction pratique et opérationnelle les précautions suivantes :

• une grande rigueur de mise en oeuvre pratique au niveau des business rules au sein des bases de données;
• une collaboration continue entre les intervenants concernés en vue de maintenir une interprétation cohérente et homogène;
• une prise en compte de la hiérarchie des normes, des conventions collectives particulières et sectorielles pouvant toujours spécifier un arrêté royal, par exemple.

3. Initiatives de simplification sur le plan des systèmes d’information administratifs et IT

Plusieurs recommandations concernent en particulier le niveau IT :

• une bonne gouvernance, afin d’éviter l’émergence de silos d’information hétérogènes (on parle de risque de “death by silos“) en établissant des liens entre équipes, la société privée Colruyt Group mais aussi le dernier rapport des Nations Unies en matière d’egovernment (année 2014) appellent le principe du “(wo)man in the middle” via des “overlapping teams”.
• la mise en oeuvre continue des bonnes pratiques en matière de data quality (voir notre post : “Dix bonnes pratiques en vue d’améliorer et de maintenir la qualité des données“, juin 2014) à haut potentiel en terme de ROI et de simplification structurelle de la gestion de l’information.
• la mise en oeuvre de certaines technologies qui en facilitent l’application, telles que l’harmonisation des systèmes d’accès à l’information (“electronic identity management“) pour le monitoring des services online.

4. En conclusion : nécessité d’un partenariat entre les niveaux législatif, administratif et IT

Afin d’assurer le lien entre les initiatives préconisées ci-dessus, il est fondamental :

• d’établir un contact permanent entre les juristes en charge de la réglementation et les analystes et spécialistes IT en charge des bases de données opérationnelles correspondantes afin de maintenir la cohérence entre l’évolution des lois et des systèmes d’information administratifs. A cet égard, l’ASA-DAV préconise la désignation, par service public fédéral et organisme public d’un “agent de simplicitation” en charge de la coordination de telles initiatives.
• qu’une collaboration étroite existe entre les initiatives de synergie IT (Gcloud, mutualisations technologiques) et les projets d’harmonisation administratifs comme la Loi “Only Once” du 5 mai 2014 relative à la collecte unique des données.

***

Références bibliographiques

I. Kent W., Data and reality. Basic Assumption in Data Processing Reconsidered. New York : Elsevier North-Holland Inc., 1981.p. I.

II.  Boydens I., Informatique, normes et temps. Bruxelles : Bruylant, 1999, 570 p.  (Cet ouvrage s’est vu décerner le prix de la Fondation L. Davin, conféré par l’Académie Royale des sciences, des lettres et des beaux-arts de Belgique, 1999).

III. Bade, D.: It’s about Time!: Temporal Aspects of Metadata Management in the Work of Isabelle Boydens”. Cataloging & Classification Quarterly 49(4), 2011, pp. 328–338.

IV. Boydens I., “Strategic Issues Relating to Data Quality for E-government: Learning from an Approach Adopted in Belgium“. In Assar S., Boughazala I. et Boydens I., éds., “Practical Studies in E-Government : Best Practices from Around the World”, New York, Springer, 2011

FOD Economie: Adreskwaliteit KBO

In het project rond de authentieke bron van de Kruispuntbank van Ondernemingen (KBO) slagen we er met behulp van de Data Quality Tools in om de adreskwaliteit te verbeteren door

Een illustratie hiervan op reële data vind je hier.

De klant bevestigt dat de resultaten behaald met de tools een meerwaarde betekenen ten opzichte van de resultaten die de afgelopen jaren reeds op het vlak van de verbetering van adreskwaliteit werden bereikt. Er wordt regelmatig overlegd met de klant, die al herhaaldelijk zijn tevredenheid heeft uitgedrukt.

RSZ, dienst Inning: 30bis, werfmeldingen

Ook de RSZ is tevreden met de voorlopige resultaten die op slechts 2 dagen tijd werden bereikt, en wil verder gaan met de detectie en resolutie van dubbels in de signaletiek van Orderers, Contractors, en Sub-contractors in de toepassing voor de werfmeldingen. Sommige bedrijven met zeer gelijkaardige benaming en adres werden tot 3000 keer geregistreerd!

Korte historiek

De Data Quality Tools werden aangekocht na doorgedreven testen in een tweefasig lastenboek. De testen omvatten naast het functionele ook de integratiemogelijkheden van de oplossing (succesvol met J2EE en WebLogic10, onder andere), en een kosten-batenanalyse.
Ondertussen werd een productiemiddel (Data Quality Run Set) gecreëerd; meer uitleg op het Intranet.

Toekomst?

Er lijkt zeker voldoende vraag te bestaan bij klanten en leden.
De KSZ zou nog vóór het einde van het jaar met behulp van onze Data Quality Tools de verbetering van het BIS-register en migratie naar de SOA-omgeving willen realiseren.
KBO zou nog de kwaliteit van namen en adressen van contactpersonen (functies en rollen) van bedrijven willen in kaart brengen en vergelijken met de inhoud van het Rijksregister waar mogelijk.
Het FAVV zou de kwaliteit van adressen van vestigingseenheden en activiteitscentra in kaart willen brengen en verbeteren.

Het moment is nu gekomen om deze investering maximaal te laten renderen, voor alle betrokken partijen.
De klantenbeheerders kunnen hun voelhoorns uitsteken bij de leden van Smals en de opportuniteiten ontdekken.
En minstens enkele analisten van TO&P dienen ervaring op te doen met de Data Quality Tools in het kader van concrete opdrachten, om het Data Quality Competency Center van voldoende capaciteit en beschikbaarheid te voorzien en zo een solide basis te vormen voor dit nieuwe service-aanbod van Smals. Een uitdaging!

Uiteraard zal men hierbij kunnen blijven rekenen op de know-how die door de Data Quality Cel werd opgebouwd.