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

In dit artikel illustreren we de problematiek waarop Master Data Management (MDM) een antwoord biedt. Vervolgens definiëren we deze tak van de informatica aan de hand van voorbeelden en tonen we de verbanden met data governance en datamanagement. We stellen ook een implementatiemethode voor, evenals de bijbehorende architecturen met hun voor- en nadelen. 

De probleemstelling

Master Data Management heeft als doel twee soorten problemen op te lossen.

Enerzijds kunnen bepaalde gegevens verspreid, gedupliceerd en heterogeen zijn in verschillende semantisch met elkaar verbonden toepassingen en databases (DB’s).

Anderzijds kunnen gegevens tussen verschillende DB’s verschillen (bijvoorbeeld wat betreft het formaat of het definitiedomain) of in een verschillend tempo evolueren. Dit kan leiden tot ernstige bedrijfsproblemen. Zo vormen een gebrek aan traceerbaarheid tussen onderling afhankelijke databases of een gebrek aan “AI-ready” gegevens, een belemmering voor de efficiënte implementatie van AI-projecten, die momenteel in opkomst zijn.

Master Data Management is dus een vakgebied dat zich richt op het elimineren van inconsistenties en operationele storingen en het verbeteren van de kwaliteit van de gegevens en de dienstverlening.

Definitie en voorbeelden

Master Data Management is meer een vakgebied dan een softwareprogramma en is gebaseerd op data governance en datamanagement. 

Bij data governance legt het management van een instelling verschillende zaken vast. Een verantwoordingskader op hoog niveau moet de voorwaarden voor het beheer van masterdata vastleggen (“policy settings”). Deze masterdata zijn van fundamenteel belang voor het bedrijf (bijvoorbeeld het adres van de werkgever of het bedrijf) en worden gedeeld tussen verschillende databases. Daartoe moeten rollen worden vastgesteld op verschillende niveaus: business- en technisch beheer van MDM, van het meta-informatiesysteem, van de datakwaliteit, van de architectuur, enz. Ten slotte wordt een passende organisatie opgezet voor de evaluatie, creatie, consumptie en controle van de data.

Op basis van de policy settings maakt datamanagement het mogelijk om op iteratieve en incrementele wijze masterdata te identificeren, definiëren en modelleren via een eerste case study die door de betrokken business wordt gevalideerd, met het oog op een bredere aanpak die drie gelijktijdige assen omvat.

In de eerste plaats moet een meta-informatiesysteem of transversale woordenlijst (“glossarium”) met data met een hoge toegevoegde waarde (“Data Catalog”) worden opgezet, een onderwerp waarover we in maart 2025 een blogartikel in het Frans en het Nederlands hebben gepubliceerd (6). De Data Catalog kan ook data beheren die niet tussen databases wordt gedeeld en waarvan de documentatie belangrijk is.

Ten tweede moet een aanpak worden geïmplementeerd die gericht is op de kwaliteit van de data (6, 7, 8, 9, 10, 11). Deze omvat twee soorten methoden. Correctieve methoden (9), via datakwaliteitsinstrumenten (Batch en Rest API in de ReUse-catalogus), maken het mogelijk om problemen (afwijkingen, vermoedelijke dubbele vermeldingen, te verwijderen adressen, enz.) aan te pakken wanneer deze zich al in de databases voordoen. Preventieve methoden (7, 8, 11) maken het mogelijk om het ontstaan van afwijkingen te voorkomen door de oorzaak (of oorzaken) ervan op te sporen tussen instellingen en verzenders in de informatiestromen (bijvoorbeeld problemen met de interpretatie van de wet, het ontstaan van een nieuw concept (virusmutaties, …), inconsistente definities, bugs, …) en deze structureel aan de bron te verwijderen, zodat ze niet meer/niet in de data voorkomen (in de toekomst, zie ReUse-catalogus).

Onderstaande figuur illustreert op schematische wijze de twee methoden, die op elkaar kunnen inwerken.

Ten derde zorgt een Master Datamanagement-systeem voor de keuze van een integratie tussen de betreffende databases en de datacatalogus (of meta-informatiesysteem). Er bestaan verschillende architecturen, die we later zullen bespreken.

Deze belangrijke stappen maken het mogelijk om gesynchroniseerde gegevens in verschillende projecten en toepassingen transversaal te beheren. Het doel van de MDM-aanpak is om inspanningen te bundelen en de synchronisatie, kwaliteit, uitwisseling en controle van data tussen de verschillende silo’s te waarborgen. En dit vrijwel in realtime of in uitgestelde modus (wanneer een goedkeuringsworkflow nodig is voor de validatie van wijzigingen en versies).

Bijvoorbeeld (2, 5): MDM maakt het mogelijk om gevallen te behandelen waarin twee verschillende termen in dezelfde betekenis worden gebruikt en moeten worden geharmoniseerd (bv. te betalen bedrag, verschuldigd bedrag) of gevallen waarin eenzelfde term verschillende betekenissen kan hebben (zo kan loon bijvoorbeeld brutoloon, basisloon, loon en salaris, of nettoloon betekenen, enz.). In onze Belgische context moet ook rekening worden gehouden met de harmonisatie tussen de termen in de verschillende gebruikte talen, wat een extra factor van complexiteit is. Er is namelijk geen noodzakelijk één-op-één verband tussen de verschillende termen in de verschillende landstalen voor een bepaald concept.

Masterdata zijn dus de kleinste samenhangende sets van identifiers en attributen die op unieke wijze de belangrijkste entiteiten van een instelling of onderneming beschrijven en worden gebruikt in verschillende conceptueel en functioneel met elkaar verbonden databases en businessprocessen.

Masterdatamanagement: implementatiemethode

Aangezien een Master Datamanagement-project in de eerste plaats een businessproject is, omvat het, voordat een IT-systeem wordt geïmplementeerd, de volgende, vaak iteratieve stappen (1, 3, 4): 

• Bepaal de omvang van het project (begin met een “bescheiden” essentieel project, dat incrementeel en iteratief kan zijn, “nice to have”)
• Een agenda (planning) voor de implementatie opstellen, een continu project (ontwerp en onderhoud) ondersteund door de hiërarchie, met inbegrip van de volgende punten:
• Accent leggen (analyse) en identificeren:
  • De gebruikers van de data, hun doelstellingen
  • De authentieke bronnen
  • De belangrijkste concepten en de masterdata (unieke identificatie, hoofdcategorieën, …). Let op: soms zijn compromissen nodig, de keuze van de masterdata is niet noodzakelijkerwijs deterministisch
  • Gebeurtenissen/processen die van invloed kunnen zijn op de masterdata (bijwerking, delen en verwijderen als gevolg van wetgevende wijzigingen of de werkelijke situatie – bijvoorbeeld: mutaties van virussen en veranderingen in medische concepten, enz.)
  • De bijbehorende organisatie (bijv. validatieworkflow)
  • Het beheer van versies van masterdata en metadata (6)
  • De kwaliteit van de data: evaluatie en verbetering (6, 7, 8, 9, 10, 11) – zie hierboven
  • Beveiliging en privacy
• Definieer KPI’s of metrics om de resultaten van de MDM-aanpak te valideren, meten en opvolgen, bijvoorbeeld:
  • Kwaliteitsbarometers DmfA: opvolging van anomalieën, financiële indicatoren (AR-KB 2017), … (11)
  • Metingen van de traceerbaarheid tussen semantisch gekoppelde databases.
• Zoals hierboven vermeld, stapsgewijs een referentiekader of glossarium van data of een meta-informatiesysteem (6) opstellen, rekening houdend met de belangrijke functionaliteiten voor een latere productie:
  • Versiebeheer (planning) van masterdata en metadata (evoluerende wetgeving, verjaringstermijn, bewijskracht, opkomst van nieuwe concepten, …)
  • Validatieworkflow
  • Meertaligheid
  • Erfenis
  • Standaard en uitwisselingsformaat (“Write Once Publish Many”)
  • Multibase en meertalig zoeken
• Een strategie voor evolutie en change management opstellen voor de overgang van de huidige situatie (“AS IS”) naar de toekomstige situatie (“TO BE”)
• Rollen en business- en IT-teams (MDM, Data Quality, Architectuur, …) opstellen
• Standaarden definiëren (aanbevolen voor analyse: (12))
• Een methode bepalen voor de integratie van de betrokken databases; via het referentiekader of glossarium voor transversale data, dat we in het volgende punt zullen bekijken: de integratiearchitecturen, met hun voor- en nadelen op het vlak van:
  • datakwaliteit (10)
  • beveiliging en privacy
  • prestaties
  •  mate van intrusiviteit in de betrokken informatiesystemen

Integratiearchitecturen tussen databases en eventueel gekoppelde Data Catalogs, met hun voor- en nadelen 

De volgende schema’s zijn aangepast uit (5) en gewijzigd in overeenstemming met de huidige oplossingen (1, 2, 3, 4)

1. Virtuele directories 

Met een virtuele directory maakt het dataregister (in het midden van het schema, in het rood) het mogelijk om, op basis van een kennisbank met toegangsrechten, data uit de brondatabases over te dragen naar de gebruikers. Er zijn overeenkomsten met de KSZ, een stellair netwerk dat de uitwisseling van data tussen instellingen mogelijk maakt. Wat de sociale zekerheid betreft, kunnen gegevensgebruikers een glossarium van de data (of “Data Catalog” in het schema) raadplegen in de verschillende versies, online op het portaal van de sociale zekerheid (6). Dit is een goede oplossing in de genoemde context.

• Voordelen: eerbiediging van de privacy, veiligheid, de brondata hoeven niet te worden gewijzigd
• Nadelen: mogelijke prestatieproblemen, de dataproducenten moeten hun Data Catalog delen, uniformiseren, in hetzelfde tempo bijwerken en toegankelijk maken voor de gebruikers.   

2. Consolidatie

Bij consolidatie worden de brondata in één keer (“one shot”) naar een gemeenschappelijke database gekopieerd. Er staat geen “Data Catalog” op het schema, omdat de gemeenschappelijke database vervolgens wordt gedesynchroniseerd van de “brondata” die zij geacht wordt te vertegenwoordigen. Deze oplossing wordt niet aanbevolen. Ze werd in het verleden in de toepassing gebracht voor het beheer van zorgpremies, maar werd later opgegeven. 

• Voordelen: eenvoudig voor data-producenten: de brondatabases hoeven niet te worden gewijzigd
• Nadelen: de brondatabases en hun Data Catalog kunnen in hun eigen tempo evolueren en de gemeenschappelijke database in een ander tempo (“ghost factory”, bron van redundantie): er doen zich problemen voor op het vlak van de kwaliteit van de ‘geconsolideerde’ data, het delen van een “gemeenschappelijke Data Catalog” heeft geen zin meer.

3. Samenwerking

Bij samenwerking delen de brondatabases de gemeenschappelijke “masterdata” in een nieuwe database en blijven ze hun niet-gemeenschappelijke data beheren. Voor gemeenschappelijke data die in één exemplaar worden beheerd (dus zonder redundantie), wordt een “Data Catalog” ter beschikking gesteld van alle datagebruikers en gezamenlijk bijgewerkt door de dataproducenten. Dit is een goede oplossing als de brondatabases moeten worden geherstructureerd omdat ze bijvoorbeeld technisch en conceptueel verouderd zijn

• Voordelen: de masterdata zijn op één plek toegankelijk (wat goed is voor de datakwaliteit) en hun ‘Data Catalog’ is gemeenschappelijk, het voor datagebruikers toegankelijke deel wordt verspreid. De privacy en veiligheid zijn gewaarborgd. Elke data-producent blijft zijn eigen data beheren en deze worden niet gedeeld.
• Nadelen: de brondatabases moeten worden geherstructureerd, mogelijke prestatieproblemen.

4. Centralisatie

Voorlopige conclusies 

Wat de voorgestelde architecturen betreft (en rekening houdend met alle voorafgaande stappen die in dit artikel zijn geïllustreerd), lijkt de virtuele directory met “Data Catalog” de beste oplossing. Als een (herstructurering van) de brondatabases nodig is, kan samenwerking worden overwogen. 

In een volgende blogartikel over Master Data Management zullen we kijken naar de lessen die in België en in het buitenland zijn geleerd over het gebruik van Master Data Management op basis van de tools en implementatiemethoden, en zullen we een typologie van MDM-tools geven met een kritische en constructieve blik. 

Referenties

(1) DUBOIS P. et al. (University of Paris), Harnessing Data Integrity: A Study of Master Data Management Best Practices. MZ Computing Journal, vol 5, issue 1, 2023.

(2) Hype Cycle for Data and Analytics Governance 2025, Gartner, 19 June 2025 – ID G00827117.

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

(4) SINGH A. et al., Best Practices for Creating and Maintaining Material Master Data in Industrial Systems In International journal of research and analytical reviews, vol 10, issue 1, Janvier 2023.

(5) TRIGAUX J.-C., Master Data Management – Mise en place d’un référentiel de données. Bruxelles,  Smals Research, Deliverable 2009/TRIM4/01. 

(6) BOYDENS I., De kern van data governance: ‘data catalogs’ of Metadata Management Systemen, Brussel, Smals Research, blogartikel, 19/03/2025 (link beschikbaar naar de Franstalige versie).

(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.

(8) BOYDENS I., HAMITI G. en VAN EECKHOUT R., Data Quality: “Anomalies & Transactions Management System” (ATMS), prototype & “work in progress”, Brussel, Smals Research, blogartikel, 02/12/2020, last update 04/07/2025. (link beschikbaar naar de Franstalige versie).

(9) BOYDENS I., CORBESIER I. en HAMITI G., Data Quality Tools : retours d’expérience et nouveautés, Brussel, Smals Research, blogartikel, 07/12/2021.

(10) BOYDENS I., Dix bonnes pratiques pour améliorer et maintenir la qualité des données, Brussel, Smals Research, blogartikel, 16/06/2014, last update: december 2021.

(11) BOYDENS I., Data Quality & Back Tracking : depuis les premières expérimentations à la parution d’un Arrêté Royal, Brussel, Smals Research, blogartikel, 14/05/2018.

(12) XLS en het FedVoc-bestand gepubliceerd op GitHub van BelgIF GitHub – belgif/fedvoc: Federal Vocabularies

Dans cet article, nous illustrons la problématique à laquelle répond la gestion des Master Data (« Master Data Management (MDM) »). Nous définissons ensuite cette branche de l’informatique sur la base d’exemples et montrons ses liens avec la gouvernance et la gestion de données (“data governance” et “data management”). Nous présentons également une méthode de mise en œuvre ainsi que des architectures associées avec leurs avantages et inconvénients. 

La problématique à résoudre

La gestion des Master Data vise à résoudre deux types de difficultés.

D’une part, certaines données peuvent être dispersées, dupliquées et hétérogènes dans différentes applications et bases de données (DB) sémantiquement liées entre elles.

D’autre part, d’une DB à l’autre, les données peuvent diverger (quant au format ou au domaine de définition, par exemple) ou évoluer à des rythmes différents. En conséquence, des problèmes métier graves peuvent se poser. On observe ainsi un manque de traçabilité entre bases de données interdépendantes ou encore, l’absence de données de qualité « AI ready », ce qui constitue un obstacle à la mise en place efficace des projets d’IA croissants à l’heure actuelle.

Les buts de la gestion des Master Data sont donc l’élimination des incohérences et des dysfonctionnements opérationnels ainsi que l’amélioration de la qualité des données et du service rendu.

Définition et exemples

Le Master Data Management est davantage une discipline métier qu’un logiciel et repose sur la gouvernance des données et le data management. 

La gouvernance des données (“data governance”) est la spécification par la direction de l’institution de plusieurs éléments. Un cadre de responsabilité de haut niveau doit spécifier les modalités de gestion des Master Data (« policy settings »). Celles-ci sont fondamentales pour le business (par exemple : adresse de l’employeur ou de l’entreprise) et sont partagées entre plusieurs bases de données. A cette fin, des rôles doivent être identifiés à différents niveaux : gestion métier et technique du MDM, du système de méta-information, de la qualité des données, de l’architecture, … Enfin, une organisation appropriée pour l’évaluation, la création, la consommation et le contrôle des données est mise en place.

Le « data management » permet, sur la base des  « policy settings », de manière itérative et incrémentale, l’identification, la définition et la modélisation des Master Data, via un premier “case study” validé par le métier concerné, en vue d’une approche plus large, ce qui comporte trois axes concommitants.

En premier lieu, un système de méta-information ou glossaire transversal de données à haute valeur ajoutée (« data catalog ») doit être mis en place, sujet à propos duquel nous avons publié un article de blog en français et néerlandais en mars 2025 (6). Le catalogue de données peut aussi gérer les données non partagées entre bases de données et dont la documentation est importante.

En second lieu, une approche focalisée sur la qualité des données (6, 7, 8, 9, 10, 11) doit être mise en place. Elle inclut deux types de méthodes. Les méthodes curatives (9), via des data quality tools, (Batch et Rest API sur le catalogue ReUse) permettent de traiter les problèmes (anomalies, présomptions de doublons, adresses à nettoyer,…) quand ils sont déjà présents dans les bases de données. Les méthodes préventives (7, 8, 11) permettent quant à elles de prévenir l’émergence d’anomalies en en détectant la cause (ou les causes) entre institutions et expéditeurs dans les flux d’information (par exemple, problème d’interprétation de la loi, émergence d’un nouveau concept (mutations de virus, …), définitions incohérentes, bugs, …) et en les supprimant structurellement à la source, de sorte qu’elles ne se présentent plus/pas dans les bases de données (à venir, voir Catalogue ReUse).

La figure ci-dessous illustre les deux méthodes schématiquement, lesquelles peuvent interagir entre elles.

Enfin, en troisième lieu, un système de Master Data Management assure le choix d’une intégration entre les DB concernées et le catalogue de données (ou système de méta-information), il existe différentes architectures, que nous verrons plus loin.

Ces étapes importantes permettront de gérer transversalement des données synchronisées dans différents projets et applications. L’objectif de l’approche MDM est de mutualiser les efforts et d’assurer la synchronisation, la qualité, le partage et le contrôle des données à travers les différents silos. Et ce, quasiment en temps réel ou en mode différé (quand un workflow d’approbation s’impose pour la validation des modifications et des versions).

Par exemple (2, 5) : le MDM permettra de traiter les cas où deux termes différents sont utilisés dans le même sens et doivent être harmonisés (montant à payer, montant dû) ou encore, ceux où un même terme peut avoir plusieurs sens différents (ainsi, salaire peut signifier salaire brut, salaire de base, salaire et traitements, ou encore, salaire net, …). Dans notre contexte belge, il faudra prendre également en considération l’harmonisation entre les termes des différentes langues usitées, ce qui est un facteur de complexité supplémentaire. En effet, il n’y a pas de relation biunivoque nécessaire, pour un concept donné, entre les différents termes des différentes langues nationales.

Plus rigoureusement, on distingue des données suivantes dans le cadre du MDM (pour plus de facilté, nous parlerons par la suite de Master Data) :

• • Master Data  : le plus petit nombre d’ensembles cohérents d’identifiants et d’attributs qui décrivent de manière unique les entités principales d’une institution ou d’une entreprise et sont utilisés dans plusieurs bases de données et processus métier liés conceptuellement et fonctionnellement entre eux.
  • Data “non master” : donnée (provisoirement) non partagée par plus d’une base de données à un instant t (exemple fictif : nom de l’ouvrier affilié à l’ONVA, Office National des Vacances Annuelles – prélève et redistribue les pécules des ouvriers)
  • Reference Data :  taxonomies, listes de codes partagés (exemple : codes pays) – bijlage – annexes dans les glossaires de la sécurité sociale
  • Operationnal Data : données sensibles potentiellement constituées des trois premières et d’un traitement confidentiel, demandant un échange sécurisé (exemple : le montant de prestations de maladie professionnelles dues au travailleur T, dont le n° de RN est … pour l’instant t.).

Master Data Management : méthode de mise en oeuvre

Sachant qu’un projet de Master Data Management est avant tout un projet métier, avant la mise en place d’un système informatique, il comporte les étapes suivantes souvent itératives (1, 3, 4) : 

• Définir l’étendue du projet (commencer par un projet “modeste” essentiel, qui peut être incrémental et itératif, “nice to have”)
• Définir un agenda haut niveau (planning) de mise en œuvre, projet continu (conception et maintenance) soutenu par la hiérarchie, ce qui inclut les points suivants :
• Mettre du relief (analyse), et identifier :
  • Les utilisateurs des données, leurs objectifs
  • Les sources authentiques
  • Les concepts principaux, et les Master Data (identifiant unique, catégories principales, …). Attention : des compromis sont parfois nécessaires, le choix des Master Data n’est pas nécessairement déterministe
  • Les événements/processus pouvant affecter les Master Data (mise à jour, partage, et suppression, dus à l’évolution de la législation ou du réel appréhendé – par exemple : mutations de virus et évolution des concepts en médecine, …)
  • l’organisation associée (p. ex. workflow de validation)
  • La gestion des versions des Master Data et des métadonnées (6)
  • La qualité des données : évaluation et amélioration (6, 7, 8, 9, 10, 11) – voir supra
  • La sécurité et la vie privée
• Définir des KPI ou métriques pour valider, mesurer et suivre les résultats de l’approche MDM, par exemple : 
  • Baromètres de qualité DmfA: suivi des anomalies, indicateurs financiers (AR-KB 2017), … (11)
  • Mesures de la traçabilité entre bases de données sémantiquement liées entre elles.
• Établir de façon incrémentale, comme évoqué plus haut, un référentiel ou glossaire des données ou système de méta-information (6) en retenant les fonctionnalités importantes pour une mise en production ultérieure :
  • Gestion des versions (planning) des Master Data et des métadonnées (législation évolutive, durée de prescription, force probante, émergence de nouveaux concepts, …)
  • workflow de validation
  • Multilinguisme
  • Héritage
  • Standard et format d’échange (« Write Once Publish Many”)
  • Recherche multibase et multilingue
• Établir une stratégie d’évolution, de gestion du changement pour le passage de la situation antérieure ou actuelle (« AS IS ») à la situation à venir (« TO BE »)
• Établir des rôles et des équipes business et IT (MDM, Data Quality, Architecture, …)
• Définir les standards (recommandé pour l’analyse : (12))
• Établir une méthode d’intégration des bases de données concernées ; via le référentiel ou glossaire transversal des données, ce que nous allons voir au point suivant : les architectures d’intégrations, avec leurs avantages et inconvénients sur le plan :
  • de la qualité des données (10)
  • de la sécurité et de la vie privée
  • de la performance
  • du caractère plus ou moins intrusif dans les systèmes d’information concernés

Architectures d’intégration entre bases de données et data catalogs éventuellement liés, avec leurs avantages et inconvénients 

Les schémas qui suivent sont adaptés de (5) et modifiés selon les solutions actuelles (1, 2, 3, 4)

1. Les répertoires virtuels 

Avec un Répertoire virtuel, l’annuaire des données (au centre du schéma, en rouge) permet, en fonction d’une base de connaissance sur les autorisations de consultation, le transfert des données des bases de données sources vers les consommateurs. Il y a des similarité avec la BCSS qui est un réseau stellaire permettant l’échange de données entre institutions. S’agissant de la sécurité sociale, les consommateurs de données peuvent consulter un glossaire des données (ou “data catalog” dans le schéma) au fil des versions, en ligne sur le portail de la sécurité sociale (6). Il s’agit d’une bonne solution dans le contexte évoqué.

• Avantages : respect de la vie privée, sécurité, les bases de données sources ne doivent pas être modifiées
• Désavantages : questions de performance éventuelles, les producteurs de données doivent partager leur data catalog, l’unifier, en assurer la mise à jour au même rythme et le rendre accessible aux consommateurs.   

2. la consolidation

Dans la consolidation, les bases de données sources sont copiées dans une base de données commune en une seule fois (“one shot”). Aucun “data catalog” ne se trouve sur le schéma car la base de données commune est ensuite désynchronisée des bases de “données sources” qu’elle est censée représenter. Cette solution n’est pas conseillée. Elle fut appliquée par le passé à la gestion des bons de cotisations en soins de santé, puis abandonnée. 

• Avantages : simple pour les producteurs de données : les bases de données sources ne doivent pas être modifiées
• Désavantages : les bases de données sources et leur data catalog peuvent évoluer à leur propre rythme et la base de donnée commune à un autre rythme (“ghost factory”, source de redondance) : des problèmes se posent au niveau de la qualité des données “consolidée”, partager un “data catalog commun” n’a plus de sens

3. La coopération

Avec la coopération, les bases de données sources partagent les “Master Data” communes dans une nouvelle base de données et continuent à gérer leurs données qui ne sont pas communes. Pour les données communes qui sont gérées en un seul exemplaire (donc, sans redondance), un “data catalog” est mis à disposition de tous les consommateurs de données et mis à jour de manière collégiale par les producteurs de données. Il s’agit d’une bonne solution si les bases de données sources demandent une restructuration parce que, par exemple, elles sont devenues obsolètes techniquement et conceptuellement.

• Avantages : les Master Data sont accessibles en un endroit unique (ce qui est bon pour la qualité des données) et leur “data catalog” est commun, la partie accessible pour les consommateurs de données est diffusée. Le respect de la vie privée et la sécurité sont assurés. Chaque producteur de données continue à gérer les données qui lui sont propres et ne sont pas partagées.
• Désavantages : les bases de données sources doivent être restructurées, questions de performance éventuelles

4. La centralisation

Avec la centralisation, les bases de données sources partagent leurs Master Data dans une nouvelle base de données unique sur laquelle les producteurs de données n’ont plus seuls le pouvoir. Cette nouvelle base de données est gérée selon une organisation collégiale coordonnée et imposée aux producteurs de données. Un seul “data catalog” en définit le contenu harmonisé (on le voit représenté en rouge dans le schéma et à l’extérieur, accessible à toutes les parties, producteurs et consommateurs). Ce « data catalog » est également géré de manière collégiale et coordonnée, imposée aux producteurs de données.

Pour les raisons évoquées (dans les inconvénients ci-dessous), au sein du domaine d’application de l’administration publique, cette solution n’est pas conseillée. Elle est parfois pratiquée dans le secteur privé au sein d’une multinationale, par exemple (elle fut appliquée dans les années 1990 chez AT&T Laboratories aux USA).

• Avantages : les Master Data et leur catalogue sont accessibles en un endroit unique (ce qui est bon pour la qualité des données) et leur data catalog est commun
• Inconvénients : les bases de données sources doivent être restructurées et perdent leur pouvoir sur les données dont elles avaient la gestion seules, il y a des questions potentiellement graves de vie privée, de sécurité et de performance (beaucoup de requêtes)

Conclusions provisoires 

En ce qui concerne les architectures proposées (et toutes les étapes préalables illustrées dans cet article étant prises en compte), le répertoire virtuel avec “data catalog“ semble la meilleure solution. Si un (reengineering) de bases de données source est requis, la coopération peut-être envisagée. 

Dans un prochain article de blog sur le Master Data Management, nous envisagerons les “lessons learned” en Belgique et à l’étranger sur le recours aux Master Data Management selon les outils et les méthodes de mise en oeuvre, ainsi qu’une typologie des MDM Tools avec un regard critique et constructif. 

Références

(1) DUBOIS P. et al. (University of Paris), Harnessing Data Integrity: A Study of Master Data Management Best Practices. MZ Computing Journal, vol 5, issue 1, 2023.

(2) Hype Cycle for Data and Analytics Governance 2025, Gartner, 19 June 2025 – ID G00827117.

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

(4) SINGH A. et al., Best Practices for Creating and Maintaining Material Master Data in Industrial Systems In International journal of research and analytical reviews, vol 10, issue 1, Janvier 2023.

(5) TRIGAUX J.-C., Master Data Management – Mise en place d’un référentiel de données. Bruxelles,  Smals Research, Deliverable 2009/TRIM4/01. 

(6) BOYDENS I., Au coeur de la “data governance”: les “data catalogs” ou systèmes de méta-information, Bruxelles, Smals Research, article de blog, 19/03/2025 (inclut un lien vers la version néerlandaise).

(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.

(8) BOYDENS I., HAMITI G. et VAN EECKHOUT R., Data Quality : “Anomalies & Transactions Management System” (ATMS), prototype & “work in progress”, Bruxelles, Smals Research, article de blog, 02/12/2020, last update 04/07/2025. (inclut un lien vers la version néerlandaise).

(9) BOYDENS I., CORBESIER I. et HAMITI G., Data Quality Tools : retours d’expérience et nouveautés, Bruxelles, Smals Research, article de blog, 07/12/2021.

(10) BOYDENS I., Dix bonnes pratiques pour améliorer et maintenir la qualité des données, Bruxelles, Smals Research, article de blog, 16/06/2014, last update : décembre 2021.

(11) BOYDENS I., Data Quality & Back Tracking : depuis les premières expérimentations à la parution d’un Arrêté Royal, Bruxelles, Smals Research, article de blog, 14/05/2018.

(12) XLS et le fichier FedVoc publié sur le GitHub de BelgIF GitHub – belgif/fedvoc: Federal Vocabularies

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

Annexe (3)

Les agents IA ont le vent en poupe. Mais que sont-ils exactement ? Que peuvent-ils nous apporter et à quoi devons-nous faire attention ? Cet article de blog offre un aperçu des possibilités, des risques et des applications concrètes des agents IA.

Que sont les agents IA?

On peut décrire les agents IA comme des entités logicielles autonomes ou semi-autonomes qui utilisent l’IA pour percevoir, prendre des décisions, exécuter des actions et atteindre des objectifs. Tout comme une agence de voyage qui organise et réserve tout un voyage de manière indépendante en fonction de vos souhaits, les agents IA illustrent le concept d'”agency” : la capacité de prendre des décisions et d’agir de manière indépendante dans un contexte numérique.

Voici les caractéristiques typiques des agents IA :

• Autonomie : exécuter des tâches de manière indépendante, avec peu ou pas d’intervention humaine.
• Objectifs complexes : être capable de déterminer efficacement les étapes intermédiaires pour atteindre des objectifs complexes.
• Environnements complexes : la capacité à s’adapter à des circonstances changeantes et à des imprévus, tels que des objectifs modifiés, de nouvelles informations ou des outputs inattendus d’un système externe.

Les caractéristiques ci-dessus s’appliquent à des degrés divers aux agents IA, ce qui signifie que l'”agency” doit être considérée comme un spectre : plus ces caractéristiques sont présentes, plus un agent est capable d’effectuer des tâches complexes de manière autonome.

L’anatomie des agents IA

Les agents IA se composent généralement de plusieurs éléments qui, ensemble, rendent possible leur comportement intelligent :

• Le modèle d’IA pour le raisonnement : la capacité à planifier une série d’actions pour atteindre des objectifs et à prendre des décisions même avec des données incomplètes. On observe ici une tendance des “chat models” classiques vers des “reasoning models” qui sont mieux à même de découper les problèmes en étapes plus petites, de corriger les erreurs et d’essayer plusieurs stratégies.
• La base de connaissance : connaissances spécifiques à un domaine, souvent obtenues grâce à des techniques de Retrieval-Augmented Generation (RAG).
• La mémoire : capacité à mémoriser des informations sur les étapes ou interactions précédentes. Cela peut être à court terme (au cours d’une session) ou à plus long terme (sur plusieurs sessions). La mémoire permet aux agents IA de fournir des réponses cohérentes, de se souvenir des décisions précédentes et de rendre l’interaction plus fluide.
• Les outils : des outils tels que les moteurs de recherche, les bases de données ou les API peuvent être reliés à de grands modèles de langage (LLM). Sur la base d’une description des outils, le modèle peut alors déterminer quel outil doit être utilisé pour effectuer une tâche donnée, ainsi que les paramètres d’entrée.

Ces différents composants sont configurés et orchestrés avec des outils dédiés comme LangGraph, LlamaIndex, CrewAI, etc.

Les agents IA peuvent être activés de différentes manières. Souvent, c’est par le biais d’un input textuel ou vocal, comme dans une interface de chat. Mais un trigger peut également provenir automatiquement d’un processus : par exemple, la création d’un nouveau fichier, la réception d’un e-mail ou une modification dans une base de données. Cette flexibilité rend les agents IA utilisables dans des workflows très variés.

Une évolution intéressante est la “multi-agent collaboration” : plusieurs agents IA travaillent ensemble, chacun avec sa propre spécialisation ou tâche. Grâce à la communication mutuelle et à la répartition des tâches, ils peuvent traiter des problèmes complexes plus efficacement qu’un agent unique. Pensez par exemple à une équipe d’agents qui rédigent ensemble un rapport, où un agent collecte les données, un autre les analyse et un troisième rédige le rapport.

Bien que les agents IA deviennent toujours plus autonomes, la présence d’un “human in the loop” reste essentielle. En effet, une supervision humaine permet non seulement de détecter rapidement les erreurs ou les comportements indésirables, elle renforce également la confiance et la fiabilité du système, notamment dans les applications critiques où la précision et l’éthique jouent un rôle majeur.

Avantages et applications

Nous avons établi de quels éléments un agent IA est composé. Voyons maintenant quels avantages il peut offrir :

• Automatisation des tâches : les agents IA peuvent effectuer de manière autonome des tâches répétitives et chronophages, ce qui permet aux collaborateurs de se concentrer sur des tâches plus stratégiques.
• Assistance à la prise de décision : par l’analyse rapide de grandes quantités de données et la fourniture d’informations pertinentes, les agents IA peuvent aider à prendre des décisions plus éclairées et mieux fondées.
• Interaction intelligente avec les utilisateurs : les agents IA peuvent communiquer de manière naturelle et contextuelle par texte ou par voix, ce qui permet des interactions plus fluides et plus personnalisées avec les utilisateurs finaux.

Les domaines d’application suivants pourraient bénéficier d’une valeur ajoutée potentielle grâce aux agents IA :

• Environnements utilisateurs : dans les environnements orientés vers le client, les agents IA peuvent être utilisés pour des helpdesks automatisés, des chatbots ou des recommandations personnalisées.
• Traitement de l’information : les agents IA sont particulièrement adaptés à l’analyse et à la structuration de grandes quantités d’informations. Ils peuvent résumer des documents, détecter des tendances ou extraire des informations pertinentes à partir de sources de données complexes.
• Applications créatives : dans les secteurs créatifs, les agents IA peuvent aider à rédiger des rapports, générer des textes pour les réseaux sociaux ou même participer à la conception de nouvelles campagnes. Ils font alors office de sparring-partner créatif ou d’assistant productif.

Défis et risques

Bien que cette technologie dispose d’un potentiel considérable, il est essentiel de prendre en compte certains points importants :

• Imprévisibilité : les agents IA peuvent être imprévisibles en raison de leur nature non déterministe ; ils fournissent parfois des résultats inattendus ou incohérents, difficiles à reproduire et à comprendre.
• Problèmes liés aux LLM : les modèles de langage peuvent “halluciner”, faire des erreurs de planification ou de raisonnement, et faire de mauvais choix lors de la sélection d’outils ou de l’identification d’entités.
• Debugging complexe : en raison de la nature “black box” des modèles de langage, il est difficile de déterminer pourquoi un agent a pris une décision particulière. Plus l’agent IA est complexe, plus il est difficile d’identifier la cause exacte des erreurs. Des outils de traçage spécialisés ne sont donc pas un luxe.
• Coût et lenteur : particulièrement dans les situations où la planification et la replanification sont continues ou lorsque l’agent doit effectuer de nombreuses étapes, le résultat final peut se faire attendre et les coûts liés à l’utilisation de grands modèles de langage peuvent augmenter.
• Défis liés à la production : la création d’un premier prototype demande généralement peu d’efforts. Le véritable défi réside dans la mise en œuvre fiable et performante dans un environnement de production réel.

Etant donné que, dans de nombreux cas, nous ne pouvons pas nous fier aveuglément aux résultats des agents IA, une intervention humaine est encore souvent nécessaire pour garantir la fiabilité et la qualité.

Examples pratiques

Voici quelques exemples concrets d’agents IA illustrant les possibilités offertes :

1. Research agent : on voit émerger de plus en plus de systèmes destinés à effectuer des recherches, qui ne se limitent pas aux outils payants des grands fournisseurs (cf OpenAI Deep Research), mais comprennent également des alternatives ouvertes. L’objectif d’un tel agent de recherche est d’obtenir rapidement des informations sur un sujet donné. L’agent rédige des rapports de manière autonome, avec une contribution humaine pour la structure du rapport et la possibilité d’ajuster l’output. Un web search est utilisé comme outil pour collecter des informations sur le sujet donné et sur les thèmes spécifiques de chaque section. On utilise le reasoning pour planifier la structure du rapport, réfléchir aux sections générées et suggérer des questions de follow-up afin de poursuivre l’analyse à l’aide de l’outil de recherche web.
2. Agentic IDE: l’IA agentielle fait de plus en plus son apparition dans le développement de logiciels. Des outils tels que GitHub Copilot “agent mode” font appel à des techniques d’IA non seulement pour fournir des suggestions pendant la programmation, mais également pour accomplir des tâches complètes de manière autonome. Pensez par exemple à la génération de code, à la refactorisation de plusieurs fichiers, à la rédaction de scripts de test et même à la correction automatique d’erreurs dans le cadre d’une approche itérative par essais et erreurs. L’agent comprend l’objectif global de la tâche, exécute les actions par étapes et reformule son approche si nécessaire, tout comme le ferait un programmeur humain. Il agit ainsi comme un assistant de programmation intelligent qui permet aux développeurs de travailler plus rapidement et de manière plus cohérente.
3. Smart search : chez Smals, nous explorons les possibilités d’une fonction de recherche intelligente dans le contexte d’un environnement de travail. Dans la situation actuelle, les utilisateurs doivent naviguer parmi plus de 30 critères de recherche pour obtenir un résultat satisfaisant. L’objectif de cette expérience est de rendre la recherche beaucoup plus conviviale en permettant aux utilisateurs de formuler leur requête en langage naturel. L’agent peut désambiguïser la question (s’agit-il par exemple d’une entité ou d’une personne ?) et convertir ensuite la question désambiguïsée en une requête JSON structurée permettant d’appeler une API de recherche.

Quand (ne pas) l’utiliser?

Les agents IA peuvent être intéressants dans des situations où les solutions traditionnelles et déterministes ne suffisent pas. Pensez à des contextes impliquant de grandes quantités de données non structurées, en langage naturel ou avec des conditions changeantes où un comportement adaptatif est souhaitable. Les agents IA peuvent également apporter une valeur ajoutée dans le cadre de prises de décision complexes ou en tant qu’assistants dans des tâches comportant de nombreuses variables.

La checklist ci-dessous peut vous aider à déterminer si un agent IA est approprié :

Quand un agent IA est-il une bonne idée ?

La tâche est complexe et difficile à formaliser complètement

Le travail implique l’utilisation du langage naturel ou de données non structurées

La tâche est fréquente et prend actuellement beaucoup de temps

Le contexte change régulièrement ou est incertain

Il y a une valeur ajoutée évidente (gain de temps, meilleure qualité, évolutivité)

Quand vaut-il mieux s’abstenir ?

✘ La tâche exige une grande précision et une absence totale d’erreurs (par exemple, dans le domaine médical ou financier)

✘ Le domaine est strictement réglementé ou contient des données personnelles sensibles

✘ La tâche nécessite une intuition humaine, de l’empathie ou des considérations éthiques

✘ La tâche est simple et peut être facilement résolue à l’aide de systèmes classiques basés sur des règles

Attention : les agents IA ne sont pas toujours tenus de fonctionner de manière totalement autonome. Dans la plupart des cas, leur efficacité est maximale dans un rôle d’assistance, comme un copilote intelligent qui prépare des analyses, émet des suggestions ou effectue un travail préparatoire, tandis que la responsabilité finale reste entre les mains de l’homme.

Conclusion

Les agents IA ont clairement le vent en poupe. Ils promettent des gains d’efficacité considérables et de nouvelles possibilités dans des domaines aussi variés que le service à la clientèle, la recherche, le développement de logiciels et la gestion de l’information. Grâce à leur capacité de raisonnement, à leur accès aux connaissances et à l’utilisation d’outils, ils peuvent atteindre un haut niveau d’autonomie.

Il est toutefois important d’aborder cette technologie avec la prudence nécessaire. Les agents IA sont encore en cours de développement et sont confrontés à des défis fondamentaux en matière de fiabilité, de transparence et de performance. Dans de nombreux cas, l’intervention et la supervision humaines restent indispensables.

Quiconque expérimente aujourd’hui les agents IA acquiert des connaissances précieuses sur la manière dont ces systèmes peuvent être intégrés dans les processus et les organisations. Les années à venir seront déterminantes pour l’évolution de cette technologie. Peut-elle passer du statut de gadget à un rôle à part entière dans le fonctionnement quotidien des organisations ? Les agents IA ont le potentiel d’apporter une valeur ajoutée évidente, à condition qu’ils soient utilisés à bon escient.

Ce post est une contribution individuelle de Bert Vanhalst, IT consultant chez Smals Research. Cet article est écrit en son nom propre et n’impacte en rien le point de vue de Smals.

AI agents zijn volop in opmars. Maar wat zijn het precies? Wat kunnen ze voor ons betekenen, en waar moeten we voor oppassen? Deze blogpost geeft een overzicht van de mogelijkheden, risico’s en concrete toepassingen van AI agents.

Wat zijn AI agents?

AI agents kunnen omschreven worden als autonome of semiautonome software-entiteiten die AI gebruiken om waar te nemen, beslissingen te nemen, acties uit te voeren en doelen te bereiken. Net als een reisbureau dat op basis van jouw wensen zelfstandig een hele reis samenstelt en boekt, illustreren AI agents het concept van “agency”: het vermogen om zelfstandig beslissingen te nemen en te handelen binnen een digitale context.

Dit zijn de typische kenmerken van AI agents:

• Autonomie: zelfstandig taken uitvoeren met weinig tot geen menselijke tussenkomst.
• Complexe doelen: tussenstappen efficiënt kunnen bepalen om complexe doelen te kunnen bereiken.
• Complexe omgevingen: het vermogen om zich aan te passen aan veranderende omstandigheden en onverwachte zaken, zoals bijgestuurde doelen, nieuwe informatie of onverwachte output van een extern systeem.

De bovenstaande kenmerken zijn in mindere of meerdere mate van toepassing op AI agents, wat maakt dat “agency” gezien moet worden als een spectrum: hoe sterker deze eigenschappen aanwezig zijn, hoe beter een agent in staat is om complexe taken autonoom uit te voeren.

De anatomie van AI agents

AI agents bestaan doorgaans uit meerdere bouwstenen die samen hun intelligent gedrag mogelijk maken:

• Reasoning model (redeneervermogen): het vermogen om een opeenvolging van acties te plannen om doelstellingen te bereiken, en beslissingen kunnen nemen zelfs met onvolledige gegevens. Hier zien we een trend van de klassieke “chat models” naar “reasoning models” die beter in staat zijn om problemen op te splitsen in kleinere stappen, fouten kunnen verbeteren en meerdere strategieën kunnen uitproberen.

• Knowledge base: domein-specifieke kennis die vaak opgehaald wordt via Retrieval-Augmented Generation (RAG) technieken.

• Geheugen: het vermogen om informatie over eerdere stappen of interacties te onthouden. Dit kan zowel op korte termijn zijn (binnen een sessie) als op langere termijn (over meerdere sessies heen). Geheugen stelt AI agents in staat om consequente antwoorden te geven, eerdere beslissingen te onthouden en de interactie vloeiender te maken.

• Tools: tools, zoals zoekmachines, databanken of API’s, kunnen gekoppeld worden aan grote taalmodellen (LLM’s). Op basis van een beschrijving van de tools kan het model dan bepalen welke tool er moet gebruikt worden om een bepaalde taak uit te voeren, tezamen met de input-parameters.

Deze verschillende componenten worden geconfigureerd en georchestreerd met behulp van specifieke tools zoals LangGraph, LlamaIndex, CrewAI, etc.

AI agents kunnen op verschillende manieren worden geactiveerd. Vaak gebeurt dit via tekst- of spraakinput, zoals in een chatinterface. Maar een trigger kan ook automatisch komen vanuit een proces: bijvoorbeeld de aanmaak van een nieuw bestand, het binnenkomen van een e-mail, of een wijziging in een database. Deze flexibiliteit maakt AI agents inzetbaar in uiteenlopende workflows.

Een interessante evolutie is “multi-agent collaboration”: hierbij werken meerdere AI agents samen, elk met een eigen specialisatie of taak. Door onderling te communiceren en taken te verdelen, kunnen ze complexe problemen efficiënter en effectiever aanpakken dan een enkelvoudige agent. Denk bijvoorbeeld aan een team van agents die samen een rapport opstellen, waarbij een agent data verzamelt, een andere analyseert en een derde het rapport schrijft.

Hoewel AI agents steeds autonomer worden, blijft een “human in the loop” essentieel. Menselijke supervisie helpt niet alleen om fouten of ongewenst gedrag tijdig te detecteren, maar verhoogt ook het vertrouwen en de betrouwbaarheid van het systeem – zeker in kritieke toepassingen waar nauwkeurigheid en ethiek een grote rol spelen.

Voordelen en toepassingen

Nu we weten uit welke bouwstenen AI agents zijn opgebouwd, kunnen we eens kijken welke voordelen ze kunnen bieden:

• Automatisering van taken: AI agents kunnen repetitieve en tijdrovende taken zelfstandig uitvoeren, waardoor medewerkers zich kunnen focussen op meer strategisch werk.

• Ondersteuning bij besluitvorming: door snel grote hoeveelheden data te analyseren en relevante inzichten aan te reiken, kunnen AI agents helpen bij het nemen van betere en beter onderbouwde beslissingen.

• Intelligente interactie met gebruikers: AI agents kunnen op een natuurlijke en contextbewuste manier communiceren via tekst of spraak, wat leidt tot vlottere en persoonlijkere interacties met eindgebruikers.

In de volgende toepassingsdomeinen kunnen AI agents potentieel een meerwaarde bieden:

• Gebruikersomgevingen: in klantgerichte omgevingen kunnen AI agents ingezet worden voor geautomatiseerde helpdesks, chatbots of gepersonaliseerde aanbevelingen.

• Informatieverwerking: AI agents zijn bijzonder geschikt voor het analyseren en structureren van grote hoeveelheden informatie. Ze kunnen documenten samenvatten, trends detecteren of relevante informatie extraheren uit complexe databronnen.

• Creatieve toepassingen: in creatieve sectoren kunnen AI agents ondersteuning bieden bij het opstellen van rapporten, het genereren van teksten voor sociale media of zelfs het meedenken over nieuwe campagnes. Ze functioneren hierbij als creatieve sparringpartner of productieve assistent.

Uitdagingen en Risico’s

Hoewel de technologie veel potentieel heeft, is het cruciaal om stil te staan bij enkele belangrijke aandachtspunten:

• Onvoorspelbaarheid: AI agents kunnen onvoorspelbaar zijn vanwege hun niet-deterministische aard; ze leveren soms onverwachte of inconsistente resultaten die moeilijk te reproduceren en te begrijpen zijn.

• Problemen met LLM’s: taalmodellen kunnen “hallucineren”, fouten maken bij het plannen of redeneren, en verkeerde keuzes maken bij de selectie van tools of het identificeren van entiteiten.

• Complexe debugging: vanwege de black-box-aard van taalmodellen is het moeilijk om te achterhalen waarom een agent een bepaalde beslissing gemaakt heeft. Hoe complexer de AI agent, hoe moeilijker het is om de exacte oorzaak van fouten te identificeren. Gespecialiseerde tracing tools zijn hierbij geen overbodige luxe.

• Kost en traagheid: vooral in situaties waarbij continu gepland en herpland wordt of de agent veel stappen doorloopt kan de finale output op zich laten wachten en kunnen de kosten voor het gebruik van grote taalmodellen oplopen.

• Productie-uitdagingen: een eerste prototype bouwen kost doorgaans relatief weinig moeite. De échte uitdaging ligt in het betrouwbaar en performant inzetten in een echte productie-omgeving.

Aangezien we in veel gevallen niet blindelings kunnen vertrouwen op de output van AI agents, is er momenteel nog vaak een menselijke tussenkomst nodig om betrouwbaarheid en kwaliteit te waarborgen.

Praktische voorbeelden

Om de mogelijkheden te illustreren volgen hieronder enkele concrete voorbeelden van AI agents:

1. Research agent: meer en meer zien we systemen opduiken om reseach uit te voeren, niet enkel betalende tools van de grote leveranciers (cf OpenAI Deep Research), maar ook open alternatieven. Het doel van zo’n research agent is om snel inzicht te krijgen in een bepaalde topic. De agent stelt zelfstandig rapporten op, met menselijke input voor de structuur van het rapport en de mogelijkheid om de output bij te sturen. Web search wordt ingezet als tool om informatie te verzamelen over de opgegeven topic en over de specifieke topics van elke sectie. Er wordt gebruik gemaakt van reasoning om de structuur van het rapport te plannen en om te reflecteren over de gegenereerde secties en follow-up vragen te suggereren om verdere analyse uit te voeren met behulp van de web search tool.

2. Agentic IDE: meer en meer zien we agentic AI opduiken bij softwareontwikkeling. Tools zoals GitHub Copilot “agent mode” schakelen AI-technieken in om niet enkel suggesties te geven tijdens het programmeren, maar ook om volledige taken autonoom af te ronden. Denk hierbij aan het genereren van code, uitvoeren van refactorings over meerdere bestanden, schrijven van testscripts en zelfs het automatisch verbeteren van fouten in een iteratieve trial-and-error aanpak. De agent begrijpt het bredere doel van de taak, voert stapsgewijs acties uit en herformuleert zijn aanpak indien nodig – net zoals een menselijke programmeur dat zou doen. Hierdoor fungeert hij als een intelligente programmeerassistent die ontwikkelaars sneller en consistenter laat werken.

3. Smart search: binnen Smals verkennen we de mogelijkheden van een slimme zoekfunctie in de context van een werkomgeving. In de huidige situatie moeten gebruikers hun weg vinden in meer dan 30 zoekcriteria om tot een goed resultaat te komen. Het doel van dit experiment is om het zoeken veel gebruiksvriendelijker te maken door gebruikers toe te laten hun zoekopdracht te formuleren in natuurlijke taal. De agent kan de vraag desambiguëren (gaat het bijvoorbeeld over een entiteit of een persoon?) en de gedesambigueerde vraag vervolgens omzetten naar een gestructureerde JSON-query waarmee een search-API kan aangeroepen worden.

Wanneer (niet) gebruiken?

AI agents kunnen interessant zijn in situaties waar traditionele, deterministische oplossingen tekortschieten. Denk aan contexten met grote hoeveelheden ongestructureerde data, natuurlijke taal, of veranderende omstandigheden waar adaptief gedrag wenselijk is. Ook voor complexe besluitvorming of als assistent in taken met veel variabelen kunnen AI agents meerwaarde bieden.

Om te beoordelen of een AI agent gepast is, kan onderstaande checklist helpen:

Wanneer is een AI agent een goed idee?

De taak is complex en moeilijk volledig te formaliseren

Er wordt gewerkt met natuurlijke taal of ongestructureerde data

De taak komt frequent voor en kost vandaag veel tijd

De context verandert regelmatig of is onzeker

Er is een duidelijke meerwaarde (tijdswinst, betere kwaliteit, schaalbaarheid)

Wanneer beter niet?

✘ De taak vereist hoge nauwkeurigheid en foutloosheid (bv. medisch, financieel)

✘ Het domein is strikt gereguleerd of bevat gevoelige persoonsgegevens

✘ De taak vraagt menselijke intuïtie, empathie of ethische afwegingen

✘ De taak is eenvoudig en goed oplosbaar via klassieke regelgebaseerde systemen

Let op: AI agents hoeven niet altijd volledig autonoom te opereren. In veel gevallen zijn ze het meest effectief in een assisterende rol – als slimme copiloot die analyses voorbereidt, suggesties doet of voorbereidend werk levert, terwijl de eindverantwoordelijkheid bij de mens blijft.

Conclusie

AI agents zitten duidelijk in de lift. Ze beloven enorme efficiëntiewinsten en nieuwe mogelijkheden in uiteenlopende domeinen, van klantendiensten en research tot softwareontwikkeling en informatiebeheer. Dankzij hun redenerend vermogen, toegang tot kennis en toolgebruik kunnen ze een hoog niveau van autonomie bereiken.

Toch is het belangrijk om deze technologie met de nodige voorzichtigheid te benaderen. AI agents zijn nog volop in ontwikkeling en kampen met fundamentele uitdagingen rond betrouwbaarheid, transparantie en performantie. In veel gevallen is menselijke tussenkomst en supervisie nog onmisbaar.

Wie vandaag experimenteert met AI agents, bouwt waardevolle kennis op over hoe deze systemen kunnen geïntegreerd worden in processen en organisaties. De komende jaren zullen bepalend zijn voor hoe deze technologie evolueert. Kan ze van hype evolueren naar een volwaardige, ingebedde rol in de dagelijkse werking van organisaties? AI agents hebben het potentieel om een duidelijke meerwaarde te leveren, mits we ze verstandig inzetten.

Dit is een ingezonden bijdrage van Bert Vanhalst, IT consultant bij Smals Research. Dit artikel werd geschreven in eigen naam en neemt geen standpunt in namens 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.

[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

Deze blogpost volgt op deel 1, die de grondbeginselen van graphtechnologieën, hun algoritmes en toepassingen toelicht. Dit tweede deel is gewijd aan graph databases en aan knowledge graphs, hun verschillen en tools.

Graph databases

Zoals bij een relationele database is ook bij een graph database het doel om gegevens op een persistente manier op te slaan en te beheren en om complexe query’s uit te voeren. Het verschil is dat de gegevens worden opgeslagen in de vorm van een graph, d.w.z. een verzameling nodes die onderling verbonden zijn door bogen.

Graph databases hebben een aantal voordelen ten opzichte van traditionele relationele databases, omdat het graph model eenvoudige, geoptimaliseerde doorloop van gegevens via bogen mogelijk maakt, terwijl het verkennen van relaties in een relationele database een groot aantal joints kan vereisen. Meer details over de voordelen van graph databases en de situaties waarin ze gebruikt kunnen worden, zijn te vinden in de blogposts [1] en [2].

De drie componenten van een graph database zijn nodes, bogen en properties. Deze eigenschappen kunnen ofwel op de nodes, ofwel op de bogen, ofwel op beide worden geplaatst. Laten we eens kijken naar het voorbeeld in Figuur 1, de node “Paul” kan bijvoorbeeld gelinkt worden met eigenschappen zoals zijn geboortedatum en adres, voor de nodes die films voorstellen kunnen we eigenschappen associëren zoals het jaar van uitgave, het budget en de IMDb identifier, en op de “RATED” relaties tussen een gebruiker en een film kunnen we eigenschappen associëren zoals de kijkdatum en de waardering (op 5) die de gebruiker aan de film geeft.

Merk op dat de graph algoritmes die we in deel 1 hebben gepresenteerd vaak niet zijn geïmplementeerd in graph database software, met een paar uitzonderingen (Neo4j en TigerGraph hebben een “Graph Data Science (GDS)” library die verschillende algoritmes bevat). Over het algemeen is het daarom nodig om de graph (of een deel ervan) te exporteren naar een analysetool.

Tools voor graph databases

Laten we eens snel kijken naar enkele van de bekendste tools. Merk op dat alle hieronder genoemde tools compatibel zijn met ACID-eigenschappen. Er bestaan een groot aantal tools voor het beheren van graph databases, en deze post noemt er maar een paar. Bekijk hier gerust een uitgebreidere lijst.

1. Neo4j

Neo4j biedt het voordeel van een native graphformaat, wat het doorlopen van de graph zeer efficiënt maakt (en dus ook de query’s) De query’s gebeuren via Cypher, een taal die gemakkelijk te leren is, Neo4J is bovendien goed gedocumenteerd en beschikt over een grote community. Neo4J is in zijn “community”-versie gratis, maar een betalende versie bestaat ook (Neo4J Enterprise), de gratis versie kan een aantal schaalbaarheidsproblemen opleveren bij zeer grote hoeveelheden data.

2. ArangoDB

ArangoDB biedt een flexibel datamodel (multimodel), met een graphmodel, een documentmodel (gebaseerd op JSON-objecten) en een key-value model. Het heeft zijn eigen querytaal, AQL (Arango Query Language), die ingewikkelder kan zijn om te leren dan Cypher vanwege het multimodel dat aan de grondslag ligt van ArangoDB. Het programma is betalend, hoewel er ook een opensourceversie bestaat (community edition), maar die is (uiteraard) beperkter dan de betalende versie.

3. TigerGraph

TigerGraph is een betalende tool, die geoptimaliseerd is voor gebruik op zeer grote databases. De query’s gebeuren via de taal GSQL, die het mogelijk maakt om verschillende taken uit te voeren, maar die ingewikkelder is dan Cypher. TigerGraph beschikt over verschillende algoritmes die geïmplementeerd zijn via de GDS library.

4. Memgraph

Memgraph is een speciale tool in die zin dat hij gegevens direct in het geheugen bewaart (in RAM). Dit levert zeer hoge prestaties op voor query’s, maar maakt het aan de andere kant moeilijk te gebruiken, of op zijn minst kostbaar in termen van infrastructuur, als de graph groot is, omdat je genoeg RAM moet hebben om de gegevens op te slaan. Memgraph wordt daarom over het algemeen gebruikt als prestaties de hoogste prioriteit hebben. Query’s worden gedaan in Cypher.

5. GraphDB

GraphDB gebruikt een zeer specifiek graphmodel dat het Resource Description Framework (RDF) wordt genoemd. Dit framework, dat meer in detail zal worden besproken in de sectie Knowledge graphs, heeft zijn eigen querytaal die SPARQL heet. Er bestaat een gratis opensourceversie (graphDB Free) en een betalende enterpriseversie (graphDB Enterprise).

6. Apache TinkerPop en de implementaties ervan

Het gaat om een opensource framework voor het definiëren van een graph database en een querytaal die “Gremlin” heet. Het wordt gebruikt in veel graph database management software, zoals JanusGraph (opensource software), Amazon Neptune dat andere modellen biedt dan die van TinkerPop zoals RDF, of nog andere tools voor databasebeheer die niet gespecialiseerd zijn in graphs, zoals Azure Cosmos DB.

Knowledge graphs

Laten we, voordat we naar werkwijzen en tools kijken, eerst definiëren wat een knowledge graph is en hoe deze verschilt van een graph database. Het is een graph die zich richt op semantiek en inferentie. Elke node vertegenwoordigt een concept en elke boog een relatie. Zoals we al hebben gezien in de blogposts [3, 4], wordt een knowledge graph gedefinieerd als een graph die aan drie voorwaarden voldoet [5]:

1. De integratie van informatie uit verschillende heterogene bronnen.

Een knowledge graph verzamelt en combineert gegevens uit verschillende (on)gestructureerde bronnen op een coherente manier.

1. Het gebruik van een ontologie.

Een ontologie beschrijft formeel de concepten en relaties die aanwezig zijn in de graph, evenals eventuele beperkingen en regels. Het is dus een gestructureerd model dat de semantische basis biedt voor logische bewerkingen en coherentietesten. Een ontologieschema (zie Figuur 2), ook bekend als een ‘ontology graph’, biedt bijvoorbeeld een representatie van de entiteittypes en relaties van een knowledge graph, en biedt zo een conceptuele structuur zonder specifieke gegevens te bevatten.

1. Inferentie van impliciete informatie op basis van expliciete informatie.

Het is mogelijk om informatie te vinden die niet aanwezig was in de oorspronkelijke gegevens op basis van inferentieregels (zie Figuur 3).

Een overzicht van het RDF-model (Resource Description Framework)

Het RDF-model, oorspronkelijk ontworpen voor de formele beschrijving van web resources en de metadata ervan, wordt vaak gebruikt bij knowledge graphs omdat het robuust semantisch rederneren en een zeer hoge interoperabiliteit biedt.

Een RDF-document heeft de vorm van een set RDF-triples waarbij elk triple een associatie is: subject (te beschrijven bron), predicaat (eigenschap van de bron), object (gegevens of andere bron).

Bijvoorbeeld:

:Alice :knows :Bob .
:Alice :livesIn :Paris .
:Alice :age 30 .

Deze semantic triples vertegenwoordigen dus zowel relaties tussen nodes (bijvoorbeeld de relatie tussen Alice en Bob) als eigenschappen (de leeftijd van Alice).

Kenmerkend voor RDF is dat elk element van een triple (met uitzondering van het object als het een simpele waarde is, zoals de waarde 30 voor de leeftijd van Alice) door een URI (Uniform Resource Identifier) of IRI (Internationalized Resource Identifier) moet worden geïdentificeerd. Dit zorgt voor een hoge mate van interoperabiliteit, omdat het voorkomt dat er duplicaten ontstaan wanneer verschillende informatiebronnen worden gecombineerd. Als we teruggaan naar de eerder gebruikte triples, krijgen we het volgende fragment (in Turtle-taal):

<http://example.org/Alice> <http://example.org/knows> <http://example.org/Bob> .
<http://example.org/Alice> <http://example.org/livesIn> <http://example.org/Paris> .
<http://example.org/Alice> <http://example.org/age> "30"^^<http://www.w3.org/2001/XMLSchema#integer> .

Het gebruik van RDF impliceert daarom een URI om alle concepten (subjecten, predikaten en objecten) in de graph te kunnen identificeren op dezelfde manier als een primaire sleutel in relationele databases.

Bovendien bestaan er twee hulpmiddelen om semantische betekenis toe te voegen aan RDF-gegevens door relaties te beschrijven om redeneren mogelijk te maken, namelijk RDFS (RDF Schema) en OWL (Web Ontology Language). Zoals we al hebben gezien, vereist RDF dat elk concept wordt geïdentificeerd door een URI. RDFS en OWL bieden een voorgedefinieerde set URI’s voor veelgebruikte concepten waarnaar verwezen kan worden in RDF. Dit maakt het mogelijk om een gestandaardiseerd gemeenschappelijk vocabularium te hebben, wat de integratie met andere databanken vergemakkelijkt, en om inferentieregels op te stellen. Aangezien OWL en RDFS gestandaardiseerde concepten aanbieden, kunnen OWL-gebaseerde ‘reasoners’ (zoals FaCT++ of HermiT) op een systematische manier impliciete relaties afleiden of tegenstrijdigheden detecteren op basis van de ontologie.

Query’s op een RDF database worden gedaan via SPARQL.

Alternatieven voor RDF en tools voor het werken met een knowledge graph

Natuurlijk is het voor een knowledge graph niet noodzakelijk om het RDF-model te gebruiken. Een graph wordt als een knowledge graph beschouwd als voldaan is aan de 3 voorwaarden die beschreven zijn aan het begin van het hoofdstuk over knowledge graphs. Het is dus perfect mogelijk om een knowledge graph te creëren in een klassieke graph databasemanagementtool, zolang de implementatie data uit verschillende bronnen combineert, voldoet aan een ontologie en gebruikt kan worden voor semantische inferentie.

De voornaamste kracht van het RDF-model is zijn hoge standaardisatieniveau. Enerzijds laat het een hoge mate van interoperabiliteit toe dankzij de URI-identificatievereiste en de gestandaardiseerde woordenschat en querytaal. Anderzijds bieden de RDFS- en OWL-uitbreidingen een schat aan semantische informatie voor automatisch redeneren. Omgekeerd beperkt de complexiteit het gebruik in zakelijke toepassingen waar deze semantische nauwkeurigheid niet noodzakelijk is en waar het gebruik van een eenvoudiger graphmodel (zoals Neo4j of TigerGraph) volstaat. Het gebruik van eenvoudigere modellen heeft het voordeel dat ze eenvoudiger en sneller op te zetten zijn en optimale query prestaties bieden, maar ten koste van het verlies van de semantische rijkdom die RDF biedt.

In deze sectie worden (niet-exhaustieve) tools met betrekking tot RDF voorgesteld, maar zoals vermeld blijven de tools die eerder werden vermeld voor graph databases geldig voor het creëren van een knowledge graphs zolang aan de voorwaarden wordt voldaan.

Hier is een lijst van enkele tools gerelateerd aan knowledge graphs in RDF:

• Ontwerp van ontologieën: de opensourcetool Protégé wordt vaak gebruikt om ontologieën te creëren. De website Schema.org biedt een groot aantal standaard schema’s en vocabulaires voor verschillende domeinen, maar wordt over het algemeen gebruikt voor knowledge graphs met betrekking tot webgegevens.
• Gegevens omzetten naar RDF: de tool R2RML kan gebruikt worden om relationele gegevens om te zetten in RDF. Ook het vermelden waard is D2RQ, dat toegang biedt tot een relationele database via een virtuele RDF knowledge graph.
• Dataopslag: naast de hierboven genoemde oplossingen (GraphDB en Amazon Neptune), kunnen we ook BlazeGraph en Apache Jena (opensource) vermelden, alsook Stardog en AllegroGraph (businessoplossingen).
• OWL reasoners: er bestaan veel OWL reasoners. Ze worden echter niet allemaal actief onderhouden of zijn niet altijd bruikbaar. De meest recente OWL reasoners lijst die we konden vinden dateert uit 2023 en is hier beschikbaar [6].

Tot slot willen we nog het RDF4J framework (Java framework) en rdflib (python library) vermelden voor interactie met RDF data.

Conclusie

Laten we afsluiten met een korte samenvatting van de belangrijkste concepten die een wiskundige graph onderscheiden van een graph database en een knowledge graph.

Een wiskundige graph is een verzameling van nodes en bogen die gemakkelijk kan worden voorgesteld in matrixvorm zodat er algoritmes op kunnen worden toegepast. Het is de onderliggende structuur van elke graph database of knowledge graph.

Een graph database bestaat uit een set van nodes, bogen en properties. De nadruk ligt op het opslaan van grote hoeveelheden gegevens binnen een graph structuur en het optimaliseren van query’s.

Een knowledge graph heeft als doel om kennis binnen een graph weer te geven met de nadruk op:

• Semantiek: de graph volgt een ontologie en relaties hebben betekenis.
• Integratie: verschillende databronnen zijn gekoppeld in een uniforme graph.
• Inferentie: het vermogen om kennis af te leiden door redeneren.

Daarom is het gericht op de integratie en de semantische verrijking van data.

Het spreekt voor zich dat deze post slechts een tipje van de sluier oplicht van de uitgebreide literatuur over graphs en de verschillende toepassingen ervan. Vele punten moeten nog verder uitgewerkt worden en zullen ongetwijfeld het onderwerp zijn van toekomstige blogposts.

Referenties

[1] Graph DB vs RDBMS

[2] Sept (bonnes) raisons d’utiliser une Graph Database

[3] Les graphes de connaissance, incontournable pour l’intelligence artificielle

[4] Smals KG Checklist: déterminer si un graphe de connaissances peut résoudre un problème concret

[5] Ehrlinger, L., & Wöß, W. (2016). Towards a definition of knowledge graphs. SEMANTiCS 2016, 48(1-4), 2.

[6] Abitch, K., (2023). “OWL Reasoners still useable in 2023”

Dit is een ingezonden bijdrage van Pierre Leleux, data scientist et network data analyst bij Smals Research. Dit artikel werd geschreven in eigen naam en neemt geen standpunt in namens Smals.

Dankzij hun vermogen om complexe relaties tussen gegevens te begrijpen en te benutten, worden graphtechnologieën steeds populairder op veel gebieden van kunstmatige intelligentie en gegevensbeheer. Deze blog heeft al meerdere artikels gepubliceerd over verschillende graphtechnologieën, waaronder graph databases [1, 2, 3] en knowledge graphs [4, 5, 6].

Maar wat betekent de term ‘graph’ eigenlijk? Tussen de wiskundige modellen die als basis dienen, graph databases en knowledge graphs, kan het moeilijk zijn om je weg te vinden en de tools te identificeren die het best passen bij je behoeften. Hierbij komt nog het feit dat werken met graph data op het eerste gezicht complex kan lijken en dat het gebruik van graphalgoritmes niet tot de kernvaardigheden van de meeste data engineers en data scientists behoort. Dit alles kan het creëren en exploiteren van graph data en modellen tot een ontmoedigend vooruitzicht maken.

Dit artikel geeft daarom een overzicht van graphtechnologieën, waarbij de drie bovengenoemde aspecten worden verkend:

• Graphs vanuit een theoretisch oogpunt, hun eigenschappen en hun belangrijkste toepassingen;
• Graph databases, gespecialiseerd in de opslag en exploitatie van gekoppelde gegevens;
• Knowledge graphs, die kennis semantisch structureren.

Daarom is het de bedoeling om deze concepten en de – soms vage – grenzen ertussen te presenteren, en hun toepassingen en de bijbehorende tools en software te belichten.

Dit artikel is opgesplitst in twee delen. Het eerste deel richt zich op graphs in hun fundamentele wiskundige vorm, hoe ze kunnen worden gecodeerd en geëxploiteerd, en de belangrijkste algoritmes en de toepassingen ervan. Het tweede deel richt zich op graph databases en knowledge graphs, en de bijbehorende tools.

Back to basics: graphs als wiskundige structuur

Laten we eerst definiëren wat een graph is. Deze theoretische basis is cruciaal aangezien de concepten van graph databases en knowledge graphs op deze basis zijn gebouwd. Deze meer geavanceerde concepten kunnen op elk moment worden teruggebracht tot hun onderliggende wiskundige vorm en bij uitbreiding zijn alle modellen en algoritmes die hieronder worden gepresenteerd toepasbaar op graph databases en knowledge graphs.

In zijn meest basale vorm is een graph een wiskundige structuur die bestaat uit een verzameling nodes en arcs die de nodes paarsgewijs verbinden. Nodes stellen meestal objecten of mensen voor en bogen stellen links tussen deze objecten of mensen voor. In het geval van een sociaal netwerk kan een boog bijvoorbeeld een vriendschapsband tussen twee gebruikers voorstellen.

De graph kan zowel gericht als ongericht zijn. In het geval van een ongerichte graph zijn de relaties tussen nodes altijd wederkerig (bijvoorbeeld een vriendschapslink op Facebook), terwijl in een gerichte graph een boog die van node i naar node j gaat, niet noodzakelijk een boog in de tegenovergestelde richting impliceert (bijvoorbeeld een website A die een link heeft naar een website B).

Afhankelijk van de situatie of toepassing kan een graph al dan niet gewogen zijn. Een graph is als gewogen omschreven als er aan elke boog een gewicht wordt toegekend dat varieert van boog tot boog en dat het mogelijk maakt om bepaalde bogen een grotere “kracht” te geven. De interpretatie van deze gewichten hangt af van de context; ze kunnen bijvoorbeeld een mate van verwantschap, gelijkenis, afhankelijkheid, enz. weergeven.

Een graph wordt over het algemeen voorgesteld door een vierkante matrix van dimensie (n × n), waarbij n het aantal nodes in de graph voorstelt, genaamd een adjacency matrix (aangeduid als A). Het element op positie (i, j) in de matrix is het gewicht van de boog van node i naar node j als deze bestaat, en anders 0 (zie figuur 1). De adjacency matrix is gewoon een binaire matrix als de graph ongewogen is.

Hier gaat een boog van gewicht 3 van node 1 naar node 3 en een boog van gewicht 5 in de tegenovergestelde richting. De matrix A bevat daarom de waarde 3 op positie (1,3) en de waarde 5 op positie (3,1).

Merk op dat adjacency matrices vaak grotendeels nullen bevatten en daarom over het algemeen worden gecodeerd met behulp van sparse matrices om het geheugen te optimaliseren.

Deze voorstelling van een graph in matrixvorm maakt het veel eenvoudiger om algoritmes op de graph te gebruiken, aangezien veel graphalgoritmes, die soms complex zijn in de vorm van vergelijkingen, vaak gereduceerd kunnen worden tot een reeks elementaire matrixbewerkingen. Dit maakt hun uitvoering zeer efficiënt in wetenschappelijke programmeertalen die geoptimaliseerd zijn voor matrixberekeningen, zoals R, MATLAB, Julia of Python (numpy, scipy).

Gebruiken van graphalgoritmes en praktische toepassingen

Om het nut van een graph beter te begrijpen, kijken we eerst naar de hoofdcategorieën van graphalgoritmes, met voor elke categorie een paar voorbeelden van het praktische gebruik ervan.

• Het optimale pad bepalen om een paar nodes te verbinden.

Hierbij kan het gaan om het minimaliseren van het aantal overgangen dat nodig is om van de ene node naar de andere te gaan of, als er kosten zijn verbonden aan elke boog, het vinden van het pad met de laagste kosten. De kosten kunnen gedefinieerd worden als het gewicht van een boog, of gecodeerd worden in een tweede matrix (kostenmatrix, onafhankelijk van de adjacency matrix). De manier waarop de kosten van een boog worden bepaald hangt af van de toepassing, afhankelijk van wat je wilt minimaliseren. Dit kan bijvoorbeeld een maat voor de lengte van de boog zijn (de lengte van een weg), een maat voor de tijd (de tijd die nodig is om de boog over te steken) of financiële kosten. Dit type algoritme kan worden gebruikt in de logistiek om transport te optimaliseren. De bekendste algoritmes zijn de algoritmes Dijkstra, A* en Bellman-Ford.

• Maatstaven bepalen voor gelijkenis of afstand tussen nodes in een graph.

Afhankelijk van de context kan het nuttig zijn om een similariteitsmaat te bepalen tussen twee nodes in een graph om te bepalen hoe dicht ze bij elkaar liggen. Similariteitsmaten worden vaak gebruikt in aanbevelingstoepassingen. Door een consumptiegraph te ontwerpen die gebruikers koppelt aan de producten die ze hebben geconsumeerd, maakt het meten van de similariteit tussen nodes het voor een bepaalde gebruiker mogelijk om gebruikers met een gelijkaardig consumptieprofiel te identificeren, gebaseerd op hun connecties met de producten. Een product wordt meestal aanbevolen aan een gebruiker omdat het door veel vergelijkbare gebruikers is geconsumeerd (user-based recommendation) of omdat het product vergelijkbaar is met producten die de gebruiker al heeft geconsumeerd (item-based recommendation). De bekendste similariteitsmaten zijn over het algemeen gebaseerd op common-neighbour maten (het aantal buren dat twee nodes gemeen hebben), zoals de Jaccard-index of cosinus-similariteit, maar andere methoden houden ook rekening met indirecte buren, zoals de Katz-kernel [12] (ook bekend als de “von Neumann kernel”). Zie [13] voor enkele klassieke similariteitsmaten en het gebruik ervan in aanbevelingen.

Het tegenovergestelde van een similariteitsmaat is een dissimilariteitsmaat, die toeneemt naarmate twee nodes verder van elkaar verwijderd zijn. Een afstandsmaat is per definitie een dissimilariteit, omdat deze toeneemt naarmate twee nodes verder van elkaar verwijderd zijn. De bekendste en meest intuïtieve maat voor dissimilariteit tussen twee nodes is de lengte van het kortste pad tussen hen.

• De centraliteit meten.

Een maat voor de centraliteit van een node of boog, soms ook een prestige measure genoemd, wordt gebruikt om te kwantificeren hoe belangrijk een node of boog is binnen een graph. De bekendste maat voor centraliteit is de score die wordt berekend door het algoritme PageRank [14]. PageRank werd oorspronkelijk ontwikkeld en gebruikt door de zoekmachine Google om webpagina’s te rangschikken. Het is gebaseerd op een willekeurige beweging in een graph waarin elke node een webpagina voorstelt en elke gerichte boog een hyperlink tussen twee pagina’s voorstelt. Het PageRank-algoritme kent naast het rangschikken van webpagina’s heel wat andere toepassingen:

“Google’s PageRank method was developed to evaluate the importance of web-pages via their link structure. The mathematics of PageRank, however, are entirely general and apply to any graph or network in any domain. Thus, PageRank is now regularly used in bibliometrics, social and information network analysis, and for link prediction and recommendation. It’s even used for systems analysis of road networks, as well as biology, chemistry, neuroscience, and physics.” – Gleich (2014) [15]

Een ander bekend algoritme dat lijkt op PageRank is het HITS-algoritme (Hyperlink-Induced Topic Search) [16].

Als we het over centraliteit hebben, is PageRank vaak het algoritme dat wordt voorgesteld, maar centraliteit kan op verschillende manieren worden begrepen. Het kan bijvoorbeeld verwijzen naar een node of boog die een kritieke intermediair is voor communicatie en informatieoverdracht binnen het netwerk. Centrale nodes identificeren kan het bijvoorbeeld mogelijk maken om informatie optimaal te verspreiden in een netwerk of om nodes of bogen op te sporen die van vitaal belang zijn voor de graph (waarvan de verdwijning de informatieoverdracht in de graph ernstig zou belemmeren). Veel voorkomende maatstaven voor node- of boog-centraliteit op basis van dit principe gebruiken over het algemeen tussen-maatstaven (betweenness centrality).

Centraliteit kan ook worden beschouwd als een maat voor de representativiteit van een node binnen een gemeenschap (in termen van nabijheid tot de andere nodes in de graph), in dit geval gemeten door middel van een maat van nabijheid (closeness centrality). Merk op dat we het gebruik van verschillende centraliteitsalgoritmes in een fraudedetectiecontext al hebben vermeld in eerdere blogposts, met name PageRank (in de vorm van een verspreidingsalgoritme) [7] en betweenness centrality [8].

• De graph partitioneren.

Beter bekend als “clustering”, bestaat graph partitioning uit het groeperen van nodes in communities (clusters) zodat nodes binnen een community “similair” zijn en twee nodes die tot verschillende communities behoren “dissimilair” zijn. Dit partitioneren kan op verschillende manieren gebeuren. Door bijvoorbeeld een maat voor similariteit of dissimilariteit tussen de nodes in de graph te gebruiken en vervolgens een clusteralgoritme zoals k-medoids uit te voeren op basis van deze (dis)similariteiten.

Een andere manier is om direct op de graph te werken en te proberen dichte gebieden binnen de graph te detecteren. Dit kan worden gedaan met behulp van labelpropagatie [17], of door het optimaliseren van een objectieve functie die de kwaliteit van de partitionering meet, zoals modulariteit. Het bekendste algoritme voor modulariteitsoptimalisatie is de Louvain-methode [18].

We hebben het gebruik van ‘graph partitioning’-methodes al genoemd in verschillende blogposts [9, 10]. Deze algoritmes worden met name gebruikt in communicatie en marketing om gerichte advertenties te produceren.

• Kenmerken of representaties extraheren.

De traditionele modellen voor machine learning hebben als limiet dat ze alleen rekening houden met de gegevens (continue en categorische variabelen) die betrekking hebben op de waarnemingen, en de informatie negeren die kan worden afgeleid uit de relaties tussen de waarnemingen. Indien er relaties bestaan tussen deze gegevens, kan er een graph worden geconstrueerd en kunnen de machine learning modellen worden verrijkt door nieuwe variabelen uit de graph toe te voegen (er is ook een blogpost over dit onderwerp [11]). Deze nieuwe variabelen kunnen bijvoorbeeld een maat voor centraliteit zijn (continue variabele) of het resultaat van partitionering (categorische variabele), of ze kunnen worden verkregen met behulp van ‘graph embedding’-methoden (continue variabelen). Graph embedding moet leiden tot een representatie van de nodes in een multidimensionale ruimte. Deze ruimte wordt zo berekend dat als twee nodes dicht bij elkaar liggen in de graph, ze ook dicht bij elkaar liggen in deze ruimte. Zo’n ruimte kan worden verkregen met methoden die direct op de graph werken (node2vec [19], fastRP [20]) of door te werken op basis van bijvoorbeeld similariteiten (kernelPCA [21]) of afstanden (t-SNE [22]). Zie figuur 3 voor een voorbeeld van een tweedimensionale weergave van een eenvoudige gewogen graph.

• Links voorspellen.

Het concept van linkvoorspelling is relatief eenvoudig: het gaat om het inschatten van de waarschijnlijkheid dat er een link bestaat tussen twee nodes. Dit maakt het mogelijk om potentieel ontbrekende bogen (incomplete graph) te detecteren, of om het verschijnen van nieuwe bogen te voorspellen. Aanbevelingsalgoritmes zijn een veelvoorkomend voorbeeld van het voorspellen van links tussen gebruikers en producten, maar deze algoritmes kunnen ook worden gebruikt om potentiële, nog onbekende interacties binnen biologische netwerken te detecteren. Dit type voorspelling wordt vaak verricht met behulp van methoden gebaseerd op overeenkomsten tussen nodes, matrixfactorisatie, probabilistische modellen of kunstmatige neurale netwerken [23].

Welke hulpmiddelen?

Zoals hierboven vermeld betekent de weergave van graphs in matrixvorm dat ze efficiënt gebruikt kunnen worden in wetenschappelijke programmeertalen. Er bestaan echter ook library’s of softwares die gebruikt kunnen worden om graphs te creëren en te exploiteren.

Enkele voorbeelden van library’s voor het werken met graphs. Deze library’s kunnen worden gebruikt om een graph object te maken dat op verschillende manieren kan worden opgebouwd. Het kan leeg worden opgebouwd, voordat handmatig nodes en bogen worden toegevoegd, of vanuit een adjacency matrix of een lijst van bogen, of rechtstreeks vanuit bestanden die een beschrijving van de graph bevatten in de vorm van een lijst van nodes en bogen. Voorbeelden van graph-georiënteerde library’s zijn igraph, NetworkX, graph-tool of NetworKit voor Python, igraph voor R en Graphs voor Julia.

Voor gebruikers die al een van deze talen kennen, hebben deze library’s het voordeel dat ze intuïtief en gemakkelijk te leren zijn en veel voorgeïmplementeerde graph algoritmes bevatten.

Conclusie

In het eerste deel van deze blogpost hebben we ons toegespitst op de verschillende graph tools, we hebben de graphtheorie kort ingeleid, alsook de voornaamste toepassingen en algoritmes voor graphs. Het tweede deel richt zich op graph databases en knowledge graphs, het verschil tussen deze concepten en de bijbehorende tools.

Referenties

Enkele blogposts van Smals Research over graphs:

[1] Graph DB vs RDBMS

[2] Sept (bonnes) raisons d’utiliser une Graph Database

[3] Een graph database verkennen

[4] Les graphes de connaissance, incontournable pour l’intelligence artificielle

[5] Les graphes de connaissance : quelques applications

[6] Smals KG Checklist: déterminer si un graphe de connaissances peut résoudre un problème concret

[7] Un fraudeur ne fraude jamais seul

[8] Un fraudeur ne fraude jamais seul, partie 2

[9] Ce qu’un réseau social peut nous apprendre

[10] Facebook : peut-on vraiment cacher sa liste d’amis ?

[11] Améliorer le Machine Learning avec des données graphes

Wetenschappelijke bronnen:

[12] Katz, L. (1953). A new status index derived from sociometric analysis. Psychometrika, 18(1), 39-43.

[13] Fouss, F., Pirotte, A., Renders, J. M., & Saerens, M. (2007). Random-walk computation of similarities between nodes of a graph with application to collaborative recommendation. IEEE Transactions on knowledge and data engineering, 19(3), 355-369.

[14] Page, L., Brin, S., Motwani, R., & Winograd, T. (1998). The pagerank citation ranking: Bringing order to the web. Technical report, Stanford Digital Libraries.

[15] Gleich, D. F. (2015). PageRank beyond the web. siam REVIEW, 57(3), 321-363.

[16] Kleinberg, J. M. (1999). Authoritative sources in a hyperlinked environment. Journal of the ACM (JACM), 46(5), 604-632.

[17] Raghavan, U. N., Albert, R., & Kumara, S. (2007). Near linear time algorithm to detect community structures in large-scale networks. Physical Review E—Statistical, Nonlinear, and Soft Matter Physics, 76(3), 036106.

[18] Blondel, V. D., Guillaume, J. L., Lambiotte, R., & Lefebvre, E. (2008). Fast unfolding of communities in large networks. Journal of statistical mechanics: theory and experiment, 2008(10), P10008.

[19] Grover, A., & Leskovec, J. (2016). node2vec: Scalable feature learning for networks. In Proceedings of the 22nd ACM SIGKDD international conference on Knowledge discovery and data mining (pp. 855-864).

[20] Chen, H., Sultan, S. F., Tian, Y., Chen, M., & Skiena, S. (2019, November). Fast and accurate network embeddings via very sparse random projection. In Proceedings of the 28th ACM international conference on information and knowledge management (pp. 399-408).

[21] Schölkopf, B., & Smola, A. J. (2002). Learning with kernels: support vector machines, regularization, optimization, and beyond.

[22] Van der Maaten, L., & Hinton, G. (2008). Visualizing data using t-SNE. Journal of machine learning research, 9(11).

[23] Lü, L., & Zhou, T. (2011). Link prediction in complex networks: A survey. Physica A: statistical mechanics and its applications, 390(6), 1150-1170.

Dit is een ingezonden bijdrage van Pierre Leleux, data scientist et network data analyst bij Smals Research. Dit artikel werd geschreven in eigen naam en neemt geen standpunt in namens Smals.