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.

Cet article fait suite à la Partie 1, qui présente les fondamentaux des technologies graphes, algorithmes et applications. Cette seconde partie est consacrée aux bases de données orientées graphe et aux graphes de connaissances, leurs différences et leurs outils.

Les bases de données orientées graphe

A l’instar d’une base de données relationnelle, l’objectif d’une base de données orientée graphe est de pouvoir stocker et gérer des données de manière persistante et d’effectuer des requêtes complexes. La différence étant que les données sont stockées sous la forme d’un graphe, à savoir un ensemble de nœuds interconnectés par le biais d’arcs.

Les bases de données orientées graphe ont plusieurs avantages par rapport aux bases de données relationnelles classiques, car le modèle de graphe permet une traversée simple et optimisée des données via les arcs, là où l’exploration de relations dans une base de données relationnelle peut demander un nombre important de jointures. Plus de détails sur les avantages des bases de données orientées graphe, ainsi que les cas de figure où les utiliser, se trouvent dans les articles de blog [1] et [2].

Les trois composants de toute base de données orientée graphe sont : nœuds, arcs et propriétés. Ces propriétés peuvent être placées soit sur les nœuds, soit sur les arcs, ou sur les deux. Si nous considérons le petit exemple illustratif dans la Figure 1, le nœud « Paul » peut par exemple être associé à des propriétés telles que sa date de naissance et son adresse, pour les nœuds représentant des films on peut y associer les propriétés telles que l’année de sortie, le budget et son identifiant IMDb, et sur les relations « A_VU » entre un utilisateur et un film, on pourrait associer des propriétés telles que la date de visionnage et la note (sur 5) que l’utilisateur donne au film.

Il est à noter que les algorithmes de graphe que nous avons présentés dans la Partie 1 ne sont souvent que peu ou pas implémentés dans les logiciels de bases de données orientées graphe, à quelques exceptions près (Neo4j et TigerGraph disposent d’une libraire « Graph Data Science (GDS) » contenant plusieurs algorithmes). Il est donc généralement nécessaire d’exporter le graphe (ou une partie de celui-ci) vers un outil d’analyse.

Les outils pour bases de données orientées graphe

Passons rapidement en revue quelques-uns des outils les plus connus. Notez que tous les outils listés ci-après sont compatibles avec les propriétés ACID. Il existe un grand nombre d’outils pour la gestion de base de données graphe, cet article n’en mentionne qu’une partie. N’hésitez pas à aller jeter un coup d’œil à une liste plus détaillée trouvable ici.

1. Neo4j

Neo4j offre l’avantage d’avoir un format de graphe natif, ce qui rend très efficace la traversée du graphe (et donc, les requêtes). Les requêtes se font en Cypher, un langage facile à prendre en main, et Neo4J est bien documenté et dispose d’une grande communauté. Neo4J dans sa version « community » est gratuit, mais une version payante existe (Neo4j Enterprise), et la version gratuite peut poser quelques soucis de scalabilité face à de très grandes quantités de données.

2. ArangoDB

ArangoDB propose un modèle de données flexible (multi-modèle), intégrant un modèle graphe, un modèle document (basé sur des objets JSON) et un modèle clé-valeur. Il dispose de son propre langage de requêtes AQL (Arango Query Language) qui peut être plus compliqué à prendre en main que Cypher en raison du multi-modèle sous-jacent à ArangoDB. C’est un logiciel payant, bien qu’une version open source existe (community edition), mais est (évidement) plus limitée que la version payante.

3. TigerGraph

TigerGraph est un outil payant, optimisé pour pouvoir être utilisés sur de très grandes bases de données. Les requêtes se font via le langage GSQL, qui est un langage permettant d’effectuer de nombreuses tâches, mais plus compliqué à prendre en main que Cypher. TigerGraph dispose de nombreux algorithmes implémentés via la librairie GDS.

4. Memgraph

Memgraph est un outil particulier en ce sens qu’il stocke les données directement en mémoire (dans la RAM). Cela lui permet d’avoir des très hautes performances pour le requêtage, mais en contrepartie cela rend son utilisation difficile, ou du moins coûteuse en termes d’infrastructure, lorsque le graphe est de grande taille, puisqu’il faut avoir suffisamment de RAM que pour stocker les données. Memgraph s’utilise donc généralement lorsque les performances sont la première priorité. Les requêtes se font en Cypher.

5. GraphDB

GraphDB utilise un modèle de graphe bien spécifique appelé Resource Description Framework (RDF). Ce framework, qui sera discuté un peu plus en détails dans la section relative aux graphes de connaissances, a son langage de requête propre nommé SPARQL. Il existe en version gratuite open-source (graphDB Free) et en version entreprise payante (graphDB Enterprise).

6. Apache TinkerPop et ses implémentations

Il s’agit d’un framework open-source qui vise à définir un modèle de base de données graphes, ainsi qu’un langage de requête nommé « Gremlin ». Il est utilisé dans de nombreux logiciels de gestion de base de données orientées graphe, tels que JanusGraph (un logiciel open-source), Amazon Neptune qui propose d’autres modèles que celui de TinkerPop tels que RDF, ou encore des outils de gestion de base de données non spécialisés en graphe, tels qu’Azure Cosmos DB.

Les graphes de connaissances

Avant de s’intéresser aux pratiques et outils, commençons dans un premier temps par définir ce qu’est un graphe de connaissances et ce qui le distingue d’une base de données orientée graphe. Il s’agit d’un graphe qui met l’accent sur la sémantique et sur l’inférence. Chaque nœud représente un concept et chaque arc une relation. Comme nous l’avons déjà vu dans les articles de blog [3, 4], un graphe de connaissances se définit comme un graphe remplissant trois conditions [5] :

1. L’intégration d’informations en provenance de différentes sources hétérogènes.

Un graphe de connaissances rassemble et combine des données issues de diverses sources (structurées ou non) de manière cohérente.

2. L’utilisation d’une ontologie.

Une ontologie décrit de façon formelle les concepts et les relations présentes dans le graphe, ainsi que les éventuelles contraintes et règles. Il s’agit donc d’un modèle structuré qui fournit les fondations sémantiques afin de permettre des opérations de raisonnement et des tests de cohérence. Par exemple, un schéma d’ontologie (voir Figure 2), également appelé graphe ontologique, fournit une représentation des types d’entités et des relations d’un graphe de connaissances, fournissant ainsi une structure conceptuelle sans contenir de données spécifiques.

3. L’inférence d’informations implicites sur base d’informations explicites.

Il est possible de trouver des informations qui n’étaient pas présentes dans les données initiales sur base de règles d’inférence (Voir Figure 3).

Un aperçu du modèle RDF (Resource Description Framework)

Initialement conçu pour la description formelle de ressources web et leurs métadonnées, le modèle RDF est fréquemment utilisé pour les graphes de connaissances car il permet un raisonnement sémantique robuste et une très grande interopérabilité.

Un document en RDF prend la forme d’un ensemble de triplets RDF, chaque triplet est une association : sujet (ressource à décrire), prédicat (propriété de la ressource), objet (donnée ou autre ressource).

Par exemple :

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

Ces triplets représentent donc aussi bien des relations entre nœuds (par exemple : la relation entre Alice et Bob) que des propriétés (l’âge d’Alice).

Une spécificité de RDF est qu’il nécessite que chaque élément d’un triplet (à l’exception de l’objet s’il s’agit d’une valeur simple, tel que la valeur 30 pour l’âge d’Alice) soit identifié par un URI (Uniform Resource Identifier) ou IRI (Internationalized Resource Identifier). Cela permet une grande interopérabilité car cela évite la création de doublons lorsque plusieurs sources d’information sont combinées. Si nous reprenons les triplets utilisés précédemment, nous obtenons le fragment suivant (en langage turtle) :

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

L’utilisation de RDF implique donc d’avoir un URI afin de pouvoir identifier tous les concepts (sujets, prédicats et objets) du graphe à l’instar d’une clé primaire dans les bases de données relationnelles.

De plus, il existe deux outils permettant d’ajouter de la signification sémantique aux données RDF, en décrivant les relations afin de permettre le raisonnement, à savoir RDFS (RDF Schema) et OWL (Web Ontology Language). Comme nous l’avons vu, RDF impose que chaque concept soit identifié par un URI. RDFS et OWL fournissent un ensemble prédéfini d’URI pour des concepts fréquemment utilisés, auxquels on peut faire référence dans RDF. Ceci permet d’une part d’avoir un vocabulaire commun standardisé, ce qui facilite l’intégration d’autres bases de données, et d’autre part d’établir des règles d’inférence. En effet, puisque OWL et RDFS proposent des concepts standardisés, cela permet à des « raisonneurs » basés sur OWL (tels que FaCT++ ou HermiT) d’inférer les relations implicites de façon systématique ou de détecter des contradictions, sur base de l’ontologie.

Les requêtes sur une base de données RDF se font via SPARQL.

Les alternatives à RDF, et les outils pour travailler avec un graphe de connaissances

Bien évidemment, un graphe de connaissances ne nécessite pas forcément l’utilisation du modèle RDF. Un graphe sera considéré comme graphe de connaissances tant que les 3 conditions décrites en début de section sur les graphes de connaissances sont remplies. Il est donc parfaitement possible de créer un graphe de connaissances dans un outil classique de gestion de base de données orientée graphe, tant que l’implémentation combine des données de plusieurs sources, qu’elle est conforme à une ontologie et qu’elle peut être utilisée pour de l’inférence sémantique.

La principale force du modèle RDF est son niveau de standardisation élevé. D’une part, via son exigence d’identification par URI, ainsi que son vocabulaire et son langage de requête standardisés, elle permet une haute interopérabilité. D’autre part, les extension RDFS et OWL permettent d’offrir une richesse sémantique rendant possible un raisonnement automatique. En contrepartie, sa complexité limite son adoption dans des applications business où cette rigueur sémantique n’est pas forcément nécessaire et où l’utilisation d’un modèle de graphe plus simple (tel que Neo4j ou TigerGraph) suffit. L’utilisation de modèles plus simples offre l’avantage d’être plus facile et rapide à mettre en place et d’offrir des performances de requêtage optimisées, mais au prix de la perte de la richesse sémantique offerte par RDF.

Cette section présente des outils (de façon non exhaustive) relatifs à RDF mais, comme mentionné, les outils précédemment cités pour les bases de données orientées graphe restent valides pour créer un graphe de connaissances tant que les conditions sont remplies.

Voici une liste de quelques outils liés aux graphes de connaissances en RDF :

• La conception d’ontologies : l’outil open-source Protégé est fréquemment utilisé pour créer des ontologies. Le site schema.org fournit un grand nombre de schéma et vocabulaires standards pour différents domaines, mais est généralement plutôt utilisé pour des graphes de connaissances relatifs aux données web.
• La transformation de données vers RDF : l’outil R2RML permet de transformer des données relationnelles vers RDF. Nous pouvons aussi mentionner D2RQ, qui donne accès à une base de données relationnelle via un graphe de connaissances RDF virtuel.
• Le stockage de données : en plus des solutions mentionnées précédemment (GraphDB et Amazon Neptune), nous pouvons aussi mentionner BlazeGraph et Apache Jena (open-source) ou encore Stardog et AllegroGraph (solutions commerciales).
• Les raisonneurs OWL : il existe de nombreux raisonneurs OWL. Tous ne sont cependant pas forcément activement maintenus ou toujours utilisables. La liste de raisonneurs OWL la plus récente que nous ayons pu trouver date de 2023 et est accessible ici [6].

Terminons par mentionner le framework RDF4J (framework Java) et rdflib (libraire python) permettant d’interagir avec des données RDF.

Conclusion

Terminons par une rapide synthèse des concepts clés qui séparent un graphe mathématique d’une base de données orientée graphe et d’un graphe de connaissances.

Un graphe mathématique est un ensemble de nœuds et d’arcs facilement représentable sous forme matricielle afin d’y appliquer des algorithmes. C’est la structure sous-jacente de toute base de données orientée graphe ou graphe de connaissances.

Une base de données graphe comporte un ensemble de nœuds, d’arcs et de propriétés. L’accent est mis sur le stockage de grandes quantités de données au sein d’une structure graphe et sur l’optimisation du requêtage.

Un graphe de connaissances a pour but de représenter le savoir au sein d’un graphe mettant l’accent sur :

• La sémantique : Le graphe suit une ontologie et les relations ont une signification.
• L’intégration : Diverses sources de données sont liées dans un graphe unifié.
• L’inférence : La capacité à dériver des connaissances via un raisonnement.

Il est donc concentré sur l’intégration et l’enrichissement sémantique des données.

Il va sans dire que cet article ne fait qu’effleurer la surface de la vaste littérature des graphes et leurs applications diverses, et que nombreux points mériteraient un développement plus poussé et feront d’ailleurs sans doute l’objet de futurs articles.

Références

[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”

Ce post est une contribution individuelle de Pierre Leleux, data scientist et network data analyst chez Smals Research. Cet article est écrit en son nom propre et n’impacte en rien le point de vue de Smals.

Grâce à leur capacité à comprendre et exploiter les relations complexes entre les données, les technologies relatives aux graphes ont actuellement le vent en poupe, gagnant en popularité dans de nombreux domaines de l’intelligence artificielle et la gestion de données. Plusieurs articles ont d’ailleurs déjà été postés sur ce blog concernant différentes technologies de graphes, notamment sur les bases de données orientées graphe (graph database) [1, 2, 3] et les graphes de connaissances (knowledge graph) [4, 5, 6].

Mais que recouvre réellement le terme « graphe » ? Entre les modèles mathématiques qui servent de fondation, les bases de données orientées graphe et les graphes de connaissances, il peut être difficile de s’y retrouver et d’identifier les outils adaptés à ses besoins. Ajoutez à cela le fait que travailler sur des données organisées en réseau peut sembler complexe à première vue et que l’utilisation d’algorithmes de graphe ne fait pas partie des compétences de base de la plupart des data engineers et data scientists, et tout cela peut rendre décourageant la création et l’exploitation de données et de modèles de graphes.

Cet article a donc pour objectif de faire le point sur les technologies graphes, en explorant les 3 aspects mentionnés ci-dessus :

• Les graphes d’un point de vue théorique, leurs propriétés, leurs applications principales ;
• Les bases de données orientées graphe, spécialisées dans le stockage et l’exploitation de données connectées ;
• Les graphes de connaissances qui structurent le savoir de manière sémantique.

Le but est donc de présenter ces concepts, les frontières – parfois floues – qui les séparent, ainsi que de mettre en lumière leurs utilisations et les outils et logiciels qui y sont associés.

Cet article est divisé en deux parties. Cette première partie est consacrée aux graphes dans leur forme mathématique fondamentale, comment les encoder et les exploiter, ainsi qu’aux principaux algorithmes et leurs applications. La seconde partie portera sur les bases de données orientées graphe et graphes de connaissances et les outils qui y sont associés.

Retour aux fondamentaux : les graphes en tant que structure mathématique

Avant toute chose, commençons par définir ce qu’est un graphe. Cette base théorique est cruciale car c’est dessus que se construisent les concepts de base de données orientée graphe et de graphe de connaissances. À tout moment, ces concepts plus avancés peuvent être ramenés à leur forme mathématique sous-jacente et, par extension, tous les modèles et algorithmes présentés ci-dessous sont applicables à des bases de données orientées graphe et graphes de connaissances.

Dans sa forme la plus fondamentale, un graphe est une structure mathématique constituée d’un ensemble de nœuds et d’arcs qui joignent des nœuds deux à deux. Les nœuds représentent typiquement des objets ou des personnes, et les arcs représentent des liens entre ces objets ou personnes. Par exemple, dans le cas d’un réseau social, un arc peut représenter un lien d’amitié entre deux utilisateurs.
Le graphe peut être soit dirigé soit non-dirigé. Dans le cas d’un graphe non-dirigé, les relations entre les nœuds sont toujours réciproques (par exemple, un lien d’amitié sur Facebook) alors que dans un graphe dirigé, un arc allant d’un nœud i à un nœud j n’implique pas forcément d’arc de sens opposé (par exemple, un site internet A ayant un hyperlien qui pointe vers un site B).

Suivant la situation ou l’application, un graphe peut aussi être pondéré ou non. Un graphe est dit pondéré lorsqu’un poids est associé à chaque arc, qui varie d’un arc à l’autre, et qui permet de donner plus de « force » à certains arcs. L’interprétation de ces poids dépend du contexte, ces poids peuvent par exemple représenter un degré d’affinité, de similarité, de dépendance, etc.

Un graphe est généralement représenté par une matrice carrée de dimension (n × n), où n est le nombre de nœuds du graphe, appelée matrice d’adjacence (notée A). L’élément en position (i, j) dans la matrice vaut le poids de l’arc allant du nœud i au nœud j s’il existe, et 0 sinon (voir Figure 1). La matrice d’adjacence est simplement une matrice binaire lorsque le graphe n’est pas pondéré.

Dans l’exemple illustratif, il y a un arc de poids 3 allant du nœud 1 au nœud 3, et un arc de poids 5 allant dans le sens inverse. La matrice A contient donc la valeur 3 en position (1,3) et la valeur 5 en position (3,1).

Il est à noter que les matrices d’adjacence contiennent souvent une très large majorité de zéros, et sont donc généralement encodées via des matrices creuses (sparse matrix) afin d’optimiser la mémoire.

Cette représentation d’un graphe sous forme d’une matrice facilite fortement l’utilisation d’algorithmes sur le graphe, car nombre d’algorithmes de graphe, parfois complexes sous forme d’équations, peuvent souvent être résumés à une série d’opérations matricielles élémentaires. Ceci rend leur exécution très efficace dans des langages de programmation scientifiques optimisés pour les calculs matriciels, tels que R, MATLAB, Julia ou Python (numpy, scipy).

Utilisations d’algorithmes de graphe et applications pratiques

Pour mieux comprendre l’intérêt d’un graphe, commençons dans un premier temps par regarder les grandes catégories d’algorithmes de graphe, avec, pour chaque catégorie, quelques exemples d’utilisation pratique de ceux-ci.

• Déterminer le chemin optimal permettant de joindre une paire de nœuds.

Il peut simplement s’agir de minimiser le nombre de transitions nécessaires pour passer d’un nœud à l’autre, ou alors, si un coût est associé à chaque arc, de trouver le chemin associé au coût le plus faible. Le coût peut-être défini en tant que poids d’un arc, ou encodé dans une seconde matrice (matrice de coût, indépendante de la matrice d’adjacence). La façon dont le coût d’un arc est déterminé dépend de l’application, en fonction de ce que l’on souhaite minimiser. Il peut s’agir, par exemple, d’une mesure de longueur de l’arc (telle que la longueur d’une route), une mesure de temps (le temps nécessaire pour franchir l’arc) ou un coût financier. Ce genre d’algorithme peut être utilisé en logistique pour optimiser le transport. Les algorithmes les plus connus en la matière étant les algorithmes de Dijkstra, A*, ou encore l’algorithme de Bellman-Ford.

• Établir des mesures de similarité ou de distance entre des nœuds d’un graphe.

Suivant le contexte, il peut être intéressant d’établir une mesure de similarité entre deux nœuds d’un graphe afin de déterminer à quel point ils sont proches l’un de l’autre. L’utilisation de mesures de similarité est une approche souvent utilisée dans les applications de recommandation. En construisant un graphe de consommation qui lie les utilisateurs aux produits qu’ils ont consommés, mesurer la similarité entre les nœuds permet d’identifier, pour un utilisateur donné, des utilisateurs ayant un profil de consommation similaire, en se basant sur leurs liens avec les produits. Typiquement, un produit sera recommandé à un utilisateur soit parce qu’il a été consommé par de nombreux utilisateurs similaires (user-based recommendation) soit car le produit est similaire à ceux déjà consommés par l’utilisateur (item-based recommendation). Les mesures de similarité les plus connues se basent généralement sur des mesures de voisinage commun (le nombre de voisins en commun que possèdent deux nœuds), telles que l’indice de Jaccard ou la similarité cosinus, mais d’autres méthodes permettent de prendre aussi en compte le voisinage indirect, telles que le kernel de Katz [12] (aussi connu sous le nom de « von Neumann kernel »). Pour voir quelques mesures de similarité classiques et leur utilisation en recommandation, voir [13].

L’opposé d’une mesure de similarité est une mesure de dissimilarité, qui augmente à mesure que les deux nœuds sont différents. Une mesure de distance est, par définition, une dissimilarité, puisqu’elle augmente lorsque deux nœuds sont éloignés. La mesure de dissimilarité la plus connue et la plus intuitive entre deux nœuds est la longueur du plus court chemin qui les sépare.

• Mesurer la centralité.

Une mesure de centralité d’un nœud ou d’un arc, parfois aussi appelée mesure de prestige, sert à quantifier à quel point un nœud ou un arc est important au sein d’un graphe. La mesure de centralité la plus connue est, de loin, le score calculé par l’algorithme PageRank [14]. Initialement développé et utilisé par le moteur de recherche Google pour hiérarchiser les pages web, PageRank se base sur une marche aléatoire sur un graphe où chaque nœud représente une page web et chaque arc dirigé représente un hyperlien entre deux pages. L’algorithme PageRank trouve de nombreuses applications au-delà de la hiérarchisation de pages web :

“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]

Un autre algorithme très connu, similaire à PageRank, est l’algorithme HITS (Hyperlink-Induced Topic Search) [16].

Lorsque l’on parle de centralité, PageRank est souvent l’algorithme présenté, cependant, la centralité peut se comprendre de plusieurs manières. Il peut par exemple s’agir d’un nœud ou d’un arc constituant un intermédiaire critique pour la communication et la transmission d’information au sein du réseau. Repérer des nœuds centraux peut par exemple permettre d’optimiser la diffusion d’information dans un réseau ou de détecter des nœuds ou des arcs vitaux au graphe (dont la disparition nuirait fortement à la transmission d’information dans le graphe). Des mesures fréquentes de centralité de nœuds ou d’arcs se basant sur ce principe utilisent généralement des mesures « d’intermédiarité » (betweenness centrality).

La centralité peut aussi se comprendre comme la mesure de la représentativité d’un nœud au sein d’une communauté (en termes de proximité vis-à-vis des autres nœuds du graphe), se mesurant ici plutôt avec une mesure de proximité (closeness centrality). Il est à noter que nous avons déjà mentionné l’utilisation de différents algorithmes de centralité dans un cadre de détection de fraude dans des articles de blog précédents, notamment PageRank (sous forme d’un algorithme de diffusion) [7] et la betweenness centrality [8].

• Partitionner le graphe.

Plus connu sous le nom de « clustering », le partitionnement de graphe consiste à regrouper des nœuds en communautés (clusters) tels que les nœuds au sein d’une communauté sont « similaires » et deux nœuds appartenant à des communautés différentes sont dissimilaires. Ce partitionnement peut se faire de plusieurs manières. Par exemple en utilisant une mesure de similarité ou de dissimilarité entre les nœuds du graphe, puis en exécutant un algorithme de clustering tel que le k-médoïdes sur base de ces (dis-)similarités.

Ou alors, en travaillant directement sur le graphe en cherchant à détecter des zones denses dans celui-ci. Cela peut se faire via de la propagation de label [17], ou via l’optimisation d’une fonction objectif mesurant la qualité du partitionnement, telle que la modularité. L’algorithme d’optimisation de la modularité le plus célèbre est la méthode de Louvain [18].

Nous avions déjà mentionné l’utilisation des méthodes de partitionnement de graphes dans plusieurs articles de blog [9, 10], ces algorithmes sont utilisés notamment en communication et marketing afin de pouvoir réaliser des annonces ciblées.

• Extraire des caractéristiques ou des représentations.

Une des limites des modèles de machine learning classique est qu’ils considèrent uniquement les données (variables continues et catégorielles) relatives aux observations, et ignorent l’information qui pourrait être tirée des relations entre les observations. Si des relations existent entre ces données, un graphe peut être construit, et les modèles de machine learning peuvent être enrichis via l’ajout de nouvelles variables extraites du graphe (il y a aussi un article de blog à ce sujet [11]). Ces nouvelles variables peuvent par exemple être une mesure de centralité (variable continue) ou le résultat d’un partitionnement (variable catégorielle), ou encore être obtenues via des méthodes de graph embedding (variables continues). Le graph embedding vise à obtenir une représentation des nœuds dans un espace multidimensionnel. Cet espace est calculé de sorte que, si deux nœuds sont proches dans le graphe, ils le seront aussi dans cet espace. Cet espace peut par exemple s’obtenir via des méthodes travaillant directement sur le graphe (node2vec [19], fastRP [20]) ou en travaillant sur base de similarités (kernelPCA [21]) ou de distances (t-SNE [22]) par exemple. Voir Figure 3 pour un exemple de représentation en 2 dimensions d’un graphe pondéré simple.

• Prédire des liens.

Le concept de prédiction de lien est relativement explicite, il s’agit d’estimer la probabilité qu’un lien existe entre 2 nœuds. Cela permet de détecter des potentiels arcs manquants (graphe incomplet), ou de prédire l’apparition de nouveaux arcs. Les algorithmes de recommandations sont un exemple courant de prédiction de lien utilisateur-produit, mais ces algorithmes peuvent aussi servir à détecter des potentielles interactions encore inconnues à l’intérieur de réseaux biologiques. Ce genre de prédiction se fait souvent via des méthodes basées sur des similarités entre nœuds, de la factorisation matricielle, des modèles probabilistes ou des réseaux de neurones artificiels [23].

Quels outils ?

Comme mentionné précédemment, la représentation de graphes sous forme matricielle permet de les exploiter de façon efficace via des langages de programmation scientifiques. Cependant, il existe aussi des librairies ou logiciels permettant de créer et exploiter des données de graphe.

Voici quelques exemples de librairies dédiées au travail sur les graphes. Ces librairies permettent de créer un objet graphe, qui peut être construit de plusieurs manières. Il peut être construit à vide, avant d’y ajouter manuellement des nœuds et des arcs, ou alors à partir d’une matrice d’adjacence ou d’une liste d’arcs, ou bien encore directement depuis des fichiers contenant une description du graphe sous la forme d’une liste de nœuds et d’arcs. Quelques exemples de librairies orientées graphe incluent igraph, networkx, graph-tool ou networkit pour Python, igraph pour R et Graphs pour Julia.

Pour un utilisateur ayant déjà des connaissances dans l’un de ces langages, ces libraires ont l’avantage d’être intuitives et faciles à prendre en main, et contiennent de nombreux algorithmes de graphe pré-implémentés.

Il existe aussi de nombreux logiciels prévus pour l’analyse du contenu de bases de données orientées graphe, tels que Gephi ou Cytoscape (pour une liste plus détaillée, nous vous invitons à vous référer à l’un de nos précédents articles sur le sujet : [3]). Il s’agit bien de logiciels créés pour des analyses ponctuelles ou des explorations visuelles des relations dans des ensembles de données, mais qui ne sont pas conçus pour intégrer et gérer de grandes quantités de données de manière continue comme le ferait une base de données orientée graphe.

Conclusion

Dans la première partie de cet article dédié aux différentes technologies basées sur les graphes, nous avons fait une rapide présentation de la théorie des graphes, ainsi que des principaux algorithmes de graphe et leurs applications. La seconde partie se penchera sur les bases de données orientées graphe et les graphes de connaissances, les différences entre ces concepts ainsi que les outils qui y sont associés.

Références

Quelques articles de blog Smals Research concernant les graphes :

[1] Graph DB vs RDBMS

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

[3] Explorer une base de données orientée graphes

[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

Sources scientifiques :

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

Ce post est une contribution individuelle de Pierre Leleux, data scientist et network data analyst chez Smals Research. Cet article est écrit en son nom propre et n’impacte en rien le point de vue de Smals.

Sinds 2017 vestigen we op deze pagina’s de aandacht op het gebruik van Graph Databases (hier, hier en hier). Gartner voorspelt dat in 2025 de graph-technologieën zullen worden gebruikt in 80% van de innovaties in het gebied van data en analytics, tegenover 10% in 2021, waardoor snelle besluitvorming in een organisatie mogelijk wordt. 

Graph databases worden in twee grote domeinen gebruikt:

• Analytics, waarbij complexe berekeningen worden uitgevoerd op grote hoeveelheden gegevens (identificatie van structuren, gemeenschappen, karakteristieke nodes, ontbrekende relaties, anomalieën, paths, enz.);
• Verkenning, waarbij agenten kunnen zoeken naar een bepaalde node of relatie en vervolgens de directe omgeving ervan kunnen verkennen in een onderzoekscontext.

Het is natuurlijk gebruikelijk om de twee te combineren: een eerste analysefase identificeert situaties die moeten worden onderzocht (vermoedelijke fraude, incidenten of zwakheden in een infrastructuur, etc.), en elk geval kan dan lokaal worden verkend om tot een beslissing te komen. Verder in dit artikel zullen we ons richten op het verkennende aspect. 

In de verkennende fase ligt een van de belangrijkste voordelen van graph databases in het feit dat het datamodel en de echte wereld goed op mekaar kunnen afgestemd worden. Over het algemeen vertegenwoordigen de nodes of entiteiten concepten die duidelijk zijn voor businessmensen (mensen, bedrijven, documenten, servers, etc.) en hebben de relaties een natuurlijke semantiek (werkt voor, behoort tot, is verbonden met, etc.). Als gevolg hiervan kan een generieke grafische interface vaak worden gekoppeld aan een database en in handen worden gegeven van experts zonder IT-kennis, met slechts een beetje configuratie en parametrisatie vooraf, maar geen ontwikkeling. Dit zal niet het geval zijn in relationele databases, waar een tabel zowel een entiteit als een relatie kan vertegenwoordigen, en een attribuut soms echte informatie zal vertegenwoordigen, en soms een primaire of vreemde sleutel (foreign key).

Knowledge graphs zijn een typisch voorbeeld van een algemene grafische interface die veel toegevoegde waarde kan bieden zonder dat er specifieke ontwikkeling voor nodig is.

Om deze mogelijkheid te illustreren bestuderen we hieronder een aantal tools, van de eenvoudigste tot de meest complexe, die kunnen worden gebruikt om gegevens te visualiseren die zijn opgeslagen in een Neo4J graph-georiënteerde database.  

JavaScript libraries

Er bestaan veel libraries die een netwerk kunnen weergeven (vis.js, D3, Sigma.js, …). Maar sommige stellen je in staat om rechtstreeks te interageren met Neo4j. Zo kun je in JavaScript een Cypher query (de querytaal van Neo4j) hebben, dat naar de Neo4j-server wordt gestuurd en waarvan het resultaat op het scherm kan worden weergegeven:

• Neovis.js (uitbreiding van vis.js, gratis);
• Popoto.js (uitbreiding van D3.js, gratis);
• Cytoscape.js, waarschijnlijk de meest geavanceerde opensource library, aanvulling op CytoScape Desktop, die hieronder aan bod komt;
• KeyLines, zeer geavanceerde commerciële oplossing voor bedrijven.

Deze oplossingen voldoen niet direct aan de hierboven genoemde mogelijkheid van een tool die enkel geconfigureerd hoeft te worden, omdat ze veel ontwikkelingswerk vereisen voordat ze in productie kunnen worden genomen. Anderzijds maakt het feit dat ze rechtstreeks met Neo4j kunnen communiceren de ontwikkeling ongetwijfeld eenvoudiger, maar impliceert ook dat directe toegang tot Neo4j vanuit de browser beschikbaar moet zijn, en dat de informatie voor de connectie aanwezig is in de JavaScript-code, of wordt opgevraagd bij de gebruiker.

Ingestion

Met een groot aantal producten kun je Neo4j-gegevens opnemen in je eigen datasysteem, ofwel door alle gegevens eruit te halen of door een Cypher query uit te voeren om het resultaat op te halen.

Er zijn bijvoorbeeld twee opensource tools voor netwerkanalyse: 

• Gephi, met een toegewezen plugin. Er is keuze tussen het importeren van alle nodes en relaties die behoren tot één of meerdere geselecteerde types, of alleen het resultaat van een Cypher query. Helaas is het proces nogal moeizaam en vereist het een goede kennis van Cypher, wat deze oplossing ongeschikt maakt voor gebruik door een businessexpert. Het is bijvoorbeeld nodig om een query op te geven met de nodes die geïmporteerd moeten worden, gevolgd door een andere query met de relaties. Het zal daarom bijzonder complex zijn om het hele netwerk binnen een maximale afstand van 3 van een “doel”-node te importeren.
  Bovendien worden de gegevens na het importeren volledig losgekoppeld van de database. Tenzij ze opnieuw worden geïmporteerd, is het niet mogelijk om de buren van een node in de werkruimte op te vragen.

• Cytoscape, met een toegewijde plugin (Cytoscape Neo4j Plugin). Op papier is dit een geavanceerdere oplossing dan Gephi: gegevensintegratie via een query is veel flexibeler en zodra een deel van het netwerk is geïmporteerd, kun je met slechts twee klikken zoeken naar de buren van een node in de werkruimte. Dit is dus een echte verkenningstool. Er zijn echter drie beperkingen:
  • Tijdens onze tests werden de nodes correct geïmporteerd, maar de relaties niet en werden deze zeer willekeurig geïmporteerd;
  • Een visualisatie kan niet verrijkt worden met een nieuwe query (die een nieuwe visualisatie creëert), wat de interactiviteit aanzienlijk beperkt;
  • Cytoscape is eigenlijk een tool ontworpen voor bio-informatica en chemie. Hoewel het zeer krachtig is, is het ook complex en moeilijk in handen te leggen van niet-technische gebruikers.

Naast deze opensource oplossingen zijn er een groot aantal professionele en commerciële platforms met zeer uitgebreide analysemogelijkheden, die zich richten op een ‘graph’ benadering en waarmee een groot aantal gegevensformaten kan worden geïmporteerd, waaronder Neo4j. Over het algemeen bedoeld voor organisaties (veiligheid, intelligence, enz.) met onderzoeksbehoeften, dupliceren ze daarom Neo4j gegevens (wat synchronisatie bemoeilijkt) en combineren ze deze mogelijk met andere gegevens. Bijvoorbeeld (meer details hier) :

• Hume (GraphAware)
• Virtualitics
• Kineviz GraphXR
• Siren
• Graphistry

Exploratie

Laten we nu eens kijken naar een aantal toepassingen waarmee je direct kan aansluiten op een Neo4j database om deze te verkennen, zonder de gegevens te kopiëren naar een intern systeem, en zonder dat er enige ontwikkeling voor nodig is, althans in het begin.

Eerst is er het basistool dat (gratis) wordt meegeleverd met Neo4j: Neo4j Browser. Dit is een tool voor ontwikkelaars en datawetenschappers, waarmee ze queries kunnen testen en de resultaten kunnen bekijken, met beperkte uitbreidingsmogelijkheden (weergave van de buren van een node). Je moet altijd beginnen met een Cypher-query en je kunt een node alleen uitbreiden door alle buren weer te geven.

Neo4j Bloom

Neo4j Bloom is een (betalende) optie van de Enterprise versie van Neo4j (ook betalend), en is een tool voor business experts. Ze kunnen zoeken naar informatie in ‘full text’, selectief uitbreiden (alleen buren van een bepaald type toevoegen, of gekoppeld via een relatie van een bepaald type), en zelfs grafisch ‘patterns’ definiëren om naar te zoeken, zonder dat er ook maar één regel Cypher voor nodig is.

Bloom is gratis beschikbaar met Neo4j Desktop (lokaal geïnstalleerde versie), maar alleen voor het verkennen van lokale graphs, en zonder de mogelijkheid om visualisaties op te slaan, waardoor deze gratis versie ongeschikt is voor gebruik in een professionele context.

yWorks Neo4j Explorer

Ontwikkeld door hetzelfde bedrijf als yFiles en yEd, biedt yWorks Neo4j Explorer een eenvoudige interface (gratis), die full text zoeken, selectieve uitbreiding en zelfs de mogelijkheid biedt om ChatGPT te gebruiken voor het genereren van een Cypher query voor een specifieke behoefte. Er is echter geen echte mogelijkheid om een visualisatie op te slaan of te delen.

yWorks Explorer kan gebruikt worden door de cloudversie te kiezen of door het te installeren in Neo4j Desktop. Merk op dat in de cloudversie, de verbinding met de database wordt gemaakt vanuit de browser, en het dus mogelijk is om toegang te krijgen tot een interne of lokale database.

Graphileon

Graphileon, of het nu cloud (betaalversie) of desktop (gratis, maar gedeprecieerd) is, is op dit moment nog niet echt toegankelijk voor iedereen, omdat het een Cypher query als startpunt vereist. Maar het biedt wel de mogelijkheid om een ‘app’ te creëren, waarmee ontwikkelaars knoppen aan de interface kunnen toevoegen met een geprogrammeerde actie, waardoor de functionaliteit wordt uitgebreid. De mogelijkheden van de tool zijn echter relatief beperkt en vereisen vaak technische vaardigheden, zoals de noodzaak om JavaScript te bewerken om stijlen aan te passen (kleuren, vormen, icoontjes, enz.).

Het extra voordeel is de scheiding tussen een ‘admin’-gebruiker, die de verbinding met de DB configureert, en de ‘klassieke’ gebruiker, die geen technische informatie over de database hoeft te kennen.

Tom Sawyer Graph Database Browser

Van zo’n softwareleverancier had je misschien een tool verwacht die vergelijkbaar is met de concurrenten die op deze pagina worden gepresenteerd, maar Neo4j’s verkenning is helemaal anders. Een verouderde interface, stijl parametriseringsopties die JavaScript-achtige codebewerking vereisen, Cypher queries als het enige startpunt, geen full text search (behalve voor objecten die al in de werkruimte staan), geen selectieve uitbreiding… Als het een gratis tool was geweest, had het een geldig alternatief kunnen zijn, maar Tom Sawyer Graph Database Browser biedt alleen betaalde opties. De waarde van deze leverancier zit ongetwijfeld in de andere producten in de catalogus.

Linkurious Enterprise

Naar onze mening de meest geavanceerde van de tot nu toe geteste tools. Voor eindgebruikers biedt Linkurious Enterprise een eenvoudig te hanteren interface voor leken, krachtige zoek-, filter- en stijlaanpassingsmogelijkheden en visualisaties die kunnen worden opgeslagen, georganiseerd, gedeeld, geëxporteerd of becommentarieerd. Admins kunnen het beheer van gebruikers, groepen en toegangsrechten verfijnen en eventueel koppelen aan AD of LDAP.

Het is jammer dat er geen tool is zoals die van Bloom, waarmee (relatief) uitgebreide queries kunnen worden gebouwd zonder kennis van Cypher. Maar dit wordt gecompenseerd door de mogelijkheid voor admins om Cypher queries te definiëren, eventueel met parameters, waardoor gebruikers krachtige zoekopdrachten of uitbreidingen kunnen uitvoeren, zonder enige technische kennis.

Een geavanceerde API maakt ook een hoge mate van automatisering mogelijk. Het is bijvoorbeeld mogelijk om automatisch een weergave te maken en vervolgens een ‘widget’ (interactieve mini-weergave) te maken die vervolgens in een toepassing kan worden geïntegreerd.

In tegenstelling tot de meeste tools die in dit artikel worden genoemd, is er geen gratis versie van Linkurious, zelfs geen beperkte.

Graphlytic

Waarschijnlijk het enige echte alternatief voor Bloom of Linkurious, biedt Graphlytic een gratis versie, via Neo4j Desktop of on-premise, maar met één gebruiker. We zitten echter nog steeds een niveau lager qua mogelijkheden: beperkte samenwerkingsaspecten, geen echte selectieve exploratie, geen parametrische queries.

Er is echter een Query builder, die nog steeds beperkt is maar potentieel heeft, de mogelijkheid om de stijl (nodegrootte, kleuren, randstijlen en -dikte, pijlvormen, enz.) zeer gedetailleerd aan te passen en de aanwezigheid van de API of verbinding met een SSO (niet getest).

Conclusie

Er bestaan dus een aantal alternatieven voor gegevensverkenning in Neo4j (en vaak ook andere modellen zoals MemGraph of AllegroGraph). Deze variëren van eenvoudige, gratis tools binnen het bereik van kleine organisaties, zoals yWorks of Graphlytic, tot veel uitgebreidere oplossingen, maar tegen prijzen die alleen grote organisaties zich kunnen veroorloven, zoals Bloom of Linkurious. Maar bij de keuze van een geschikte tool moet er ook rekening gehouden worden met een aantal criteria waarmee die niet in detail werden besproken: wat is het pricing model, is de tool compatibel met de software en netwerkinfrastructuur van het bedrijf, hoe zit het met GDPR, enz.

Een eerste evaluatie met een gratis tool zal al deze beperkingen aan het licht brengen, om zo met kennis van zaken de ideale tool te kunnen kiezen.

Deze post is een individuele bijdrage van Vandy Berten, gespecialiseerd in data science bij Smals Research. Dit artikel is geschreven onder zijn eigen naam en weerspiegelt op geen enkele wijze de standpunten van Smals..

Depuis 2017, nous mettons en avant dans ces pages (ici, là, ou encore ici) l’utilisation de bases de données orientées graphes (ou Graph Databases). Gartner prédit que d’ici 2025, les technologies graphes seront utilisées dans 80 % des innovations en données et analytique, contre 10 % en 2021, facilitant la prise de décision rapide au travers d’une organisation. 

Les bases de données graphes ont deux grandes familles d’application :

• L’analytique, dans laquelle des calculs complexes sont effectués sur de grands volumes de données (identification de structures, de communautés, de nœuds caractéristiques, de relations manquantes, d’anomalies, de chemins…) ;
• L’exploration, permettant à des agents de rechercher un nœud ou une relation particulière, pour ensuite explorer son voisinage proche dans un contexte d’investigation.

Il est bien sûr fréquent de combiner les deux : une première phase d’analytique permet d’identifier des situations à examiner (suspicion de fraude, d’incident ou de faiblesse dans une infrastructure…), chaque cas pouvant ensuite être exploré localement pour prendre une décision. Dans la suite de cet article, nous allons nous focaliser sur l’aspect exploratoire. 

Dans la phase exploratoire, un des avantages majeurs des bases de données orientées graphe est la proximité forte entre le modèle de données et le monde réel. Généralement, les nœuds ou entités vont représenter des concepts clairs pour les gens de métier (personnes, entreprises, documents, serveurs…) et les relations auront une sémantique naturelle (travaille pour, appartient à, est connecté à…). Ce qui a pour conséquence qu’une interface graphique générique peut souvent être connectée à une base de données et mise dans les mains d’experts sans connaissances IT, avec uniquement un peu de configuration et paramétrisation au préalable, mais pas de développement. Ceci ne sera pas vrai dans les bases de données relationnelles, ou une table peut autant représenter une entité qu’une relation, et attribut représentera tantôt une réelle information, tantôt une clé primaire ou étrangère.

Les Knowledge graphs sont typiquement un exemple où une interface graphique générique pourra offrir une grande plus-value sans nécessiter de développement spécifique.

Pour illustrer cette possibilité, nous allons parcourir un certain nombre d’outils, des plus simples aux plus élaborés, qui permettent de visualiser des données stockées dans une base de données orientée graphe Neo4J. 

Librairies JavaScript

Il existe de nombreuses librairies capables d’afficher un réseau (vis.js, D3, Sigma.js, …). Mais certaines permettent directement d’interagir avec Neo4j. On peut donc avoir, dans le JavaScript, une requête Cypher (le langage de requêtes de Neo4j), qui sera envoyée au serveur Neo4j, et dont le résultat pourra être affiché à l’écran :

• Neovis.js (Extension de vis.js, gratuit) ;
• popoto.js (Extension de D3.js, gratuit) ;
• Cytoscape.js, probablement la librairie open-source la plus évoluée, compagnon de CytoScape Desktop que nous évoquerons plus bas ;
• KeyLines, solution commerciale très évoluée à destination des entreprises.

Ces solutions ne répondent pas directement à la possibilité évoquée ci-dessus d’un outil qu’il suffit de paramétrer, puisqu’elles nécessitent des développements importants avant une mise en production. Par ailleurs, le fait qu’elles puissent communiquer directement avec Neo4j rend sans doute les développements plus faciles, mais implique aussi qu’un accès direct à Neo4j depuis le navigateur est ouvert, et que les informations de connexion sont présentes dans le code JavaScript, ou demandées à l’utilisateur.

Ingestion

Une large gamme de produits permettent d’ingérer des données Neo4j dans leur propre système de données, soit en aspirant la totalité des données, soit en exécutant une requête Cypher pour en récupérer le résultat.

Nous pouvons par exemple citer deux outils open-source destinés à de l’analyse réseaux : 

• Gephi, avec un plugin dédié. On a le choix entre l’importation de la totalité des nœuds et relations appartenant à un ou des type(s) sélectionné(s), ou uniquement le résultat d’une requête Cypher. Le processus est malheureusement assez laborieux et nécessite de bonnes connaissances de Cypher, ce qui ne permet pas de mettre cette solution dans les mains d’un expert métier. Il est par exemple nécessaire de fournir une requête listant les nœuds à importer, puis une autre requête listant les relations. Il sera de fait particulièrement complexe d’importer l’ensemble du réseau à une distance de maximum 3 d’un nœud “cible”.
  Par ailleurs, une fois les données importées, elle seront complètement découplées de la base de données. Il ne sera pas possible, à moins d’un nouvel import, de récupérer les voisins d’un nœud présent dans l’espace de travail.

• Cytoscape, avec un plugin dédié (Cytoscape Neo4j Plugin). Sur le papier, il s’agit d’une solution plus avancée que celle de Gephi : l’intégration des données via une requête est beaucoup plus souple, et une fois qu’une partie du réseau est importée, on peut en deux clics aller chercher les voisins d’un nœud présent dans l’espace de travail. On a donc un véritable outil d’exploration. Néanmoins, trois limitations sont à noter :
  • Lors de nos tests, si les nœuds étaient correctement importés, ça n’était pas le cas des relations, importées de façon très aléatoire ;
  • On ne peut pas enrichir une visualisation avec une nouvelle requête (qui créera une nouvelle visualisation), ce qui limite fortement l’interactivité ;
  • Cytoscape est à la base un outil conçu pour la bioinformatique et la chimie. S’il est extrêmement puissant, il est également complexe, et difficile à mettre dans les mains d’utilisateurs peu techniques.

En dehors de ces solutions open-source, il existe un grand nombre de plateformes professionnelles et commerciales, aux possibilités d’analyse très étendues, se focalisant sur une approche “graphe” et permettant d’importer un grand nombre de formats de données, dont Neo4j. En général à destination d’organisation (sécurité, renseignement…) ayant des besoins d’investigation, elles dupliqueront donc les données de Neo4j (compliquant la synchronisation) et les combineront potentiellement à d’autres. On peut par exemple citer (plus de détails ici) :

• Hume (GraphAware)
• Virtualitics
• Kineviz GraphXR
• Siren
• Graphistry

Exploration

Intéressons-nous maintenant à des applications qui permettront directement de se connecter à une base de données Neo4j pour l’explorer, sans copier les données dans un système interne, et sans demander de développement, du moins dans un premier temps.

Citons tout d’abord l’outil de base fourni (gratuitement) avec Neo4j : Neo4j Browser. Il s’agit d’un outil à destination des développeurs ou data-scientists, permettant de tester des requêtes et d’en visualiser le résultat, avec des possibilités d’expansion (affichage des voisins d’un nœud) limitées. Il faut toujours commencer par une requête Cypher, et on ne peut étendre un nœud qu’en affichant la totalité de ses voisins.

Neo4j Bloom

Neo4j Bloom est une option (payante) de la version Enterprise de Neo4j (payante aussi), il s’agit là d’un véritable outil à destination d’experts métier. Il pourront rechercher des informations en “full text”, étendre sélectivement (ajouter uniquement les voisins d’un certain type, ou lié via une relation d’un certain type), et même définir graphiquement des “patterns” à rechercher, sans nécessiter la moindre ligne de Cypher.

Bloom est disponible gratuitement avec Neo4j Desktop (version installée localement), mais uniquement pour explorer des graphes locaux, et sans possibilités de sauvegarder ses visualisations, rendant cette version gratuite peu compatible avec une utilisation dans un contexte professionnel.

yWorks Neo4j Explorer

Développé par la même société que yFiles ou yEd, yWorks Neo4j Explorer offre (gratuitement) une interface simple, permettant une recherche full-text, une expansion sélective et offre même la possibilité d’utiliser ChatGPT pour générer une requête Cypher répondant à un besoin spécifique. On regrettera cependant ne pas y trouver de réelle possibilité de sauvegarder ou de partager une visualisation.

On peut utiliser yWorks Explorer soit en utilisant la version cloud, soit en l’installant dans Neo4j Desktop. Il est à noter que dans la version cloud, la connexion à la base de données se fait depuis le navigateur, et qu’il est donc possible d’accéder à une base de données interne ou locale.

Graphileon

Graphileon, version cloud (payant) ou desktop (gratuite, mais est dépréciée) n’est à ce stade pas réellement accessible à tous, parce qu’elle nécessite une requête Cypher comme point de départ. Mais on offre la possibilité de créer une “app”, permettant à des développeurs de rajouter des boutons à l’interface ayant une action programmée, ce qui étendra les fonctionnalités. Les possibilités de l’outil sont cependant relativement limitées, nécessitant par ailleurs souvent des compétences techniques, comme la nécessité d’éditer du JavaScript pour modifier les styles (couleurs, formes, icônes…).

Le petit plus est la séparation entre un utilisateur “admin”, qui configure la connexion à la DB, et l’utilisateur “classique”, qui n’a ainsi pas besoin de connaître les informations techniques de la base de données.

Tom Sawyer Graph Database Browser

De la part d’un tel éditeur de logiciel, on aurait pu s’attendre à un outil comparable à ses concurrents présentés sur cette page, mais en ce qui concerne l’exploration de Neo4j, il n’en est rien. Une interface vieillotte, des possibilités de paramétrisation des styles nécessitant d’éditer un code à la JavaScript, des requêtes Cypher comme seul point de départ, pas de recherche full-text (à part dans objets déjà présents dans l’espace de travail), pas d’expansion sélective… S’il s’agissait d’un outil gratuit, il aurait pu constituer une alternative valable, mais Tom Sawyer Graph Database Browser ne propose que des options payantes. La valeur de cet éditeur est sans doute à trouver dans les autres produits de son catalogue.

Linkurious Enterprise

À notre sens le plus évolué des outils testés jusqu’ici. Pour les utilisateurs finaux, Linkurious Enterprise propose une interface facile à prendre en main pour les non-initiés, des possibilités puissantes de recherche, de filtrage ou de personnalisation des styles ; des visualisations qui peuvent être sauvegardées, organisées, partagées, exportées ou commentées. Pour les administrateurs, la possibilité de gérer finement les utilisateurs, groupes, droits d’accès, en les liant potentiellement à un AD ou LDAP.

On regrettera l’absence d’un outil tel que celui proposé par Bloom, permettant de construire des requêtes (relativement) élaborées sans nécessiter la connaissance de Cypher. Mais ceci est compensé par la possibilité pour les administrateurs de définir des requêtes Cypher, éventuellement paramétriques, permettant aux utilisateurs des recherches ou extensions puissantes, sans connaissances techniques.

Une API avancée permet par ailleurs une grande automatisation. On peut par exemple créer automatiquement une visualisation, pour en créer ensuite un “widget” (mini-vue interactive) que l’on pourra ensuite intégrer dans une application.

Contrairement à la majorité des outils cités dans cet article, il n’existe pas de version gratuite de Linkurious, même limitée.

Graphlytic

Sans doute la seule réelle alternative à Bloom ou Linkurious, on aura avec Graphlytic une version gratuite, soit via Neo4j Desktop, soit en on-premise, mais avec un seul utilisateur. On reste cependant un niveau en dessous en termes de possibilités : aspects collaboratifs limités, pas vraiment d’exploration sélective, pas de requêtes paramétriques.

On notera cependant un “Query builder”, encore limité mais avec du potentiel, la possibilité de personnaliser le style (taille de nœuds, couleurs, styles et épaisseur de bords, formes de flèches…) de façon fine, la présence du API ou la connexion à une SSO (non testés).

Conclusions

Il existe donc un certain nombre d’alternatives permettant l’exploration de données dans Neo4j (ainsi que, souvent, d’autres modèles comme MemGraph ou AllegroGraph). Cela va d’outils simples et gratuits à la portée de petites organisations, comme yWorks ou Graphlytic, à des solutions beaucoup plus élaborées, mais à des prix que seules des grosses structures peuvent s’offrir, comme Bloom ou Linkurious. Mais il faudra bien sûr tenir compte d’un ensemble de critères non détaillés ici ; quel est le modèle de “pricing”, l’outil est-il compatible avec l’infrastructure logicielle et réseau de l’entreprise, qu’en est-il par rapport au GDPR…

Une première évaluation avec un outil gratuit permettra de mettre en évidence toutes ces contraintes, de sorte de choisir l’outil idéal en toute connaissance de cause.

Ce post est une contribution individuelle de Vandy Berten, spécialisé en data science chez Smals Research. Cet article est écrit en son nom propre et n’impacte en rien le point de vue de Smals.

Presentation

Enorme taalmodellen moeten worden getraind met enorme datasets. Om die te verzamelen wordt op geen bron meer of minder gekeken: The Pile, zowat de grootste dataset van Engelstalige tekst die vandaag bestaat, tikt ongeveer 825 GB aan. De volledige Engelstalige Wikipedia maakt er deel van uit, voor 6.3 GB, oftewel 0.7% van de collectie. Andere databronnen zijn CommonCrawl , OpenWebText , maar er worden ook tekstfragmenten gebruikt afkomstig van Github, ArXiv, PubMed, StackExchange, OpenSubtitles, zelfs het Europees Parlement.

Veel van die datasets zijn met eenvoudige webscraping scripts verzameld. Of dat allemaal wel mag volgens copyright- en privacywetgevingen allerhande, is een ingewikkelde vraag met een nog ingewikkelder antwoord en dus maakt men daar voor het gemak in eerste instantie vaak abstractie van. Kwaliteitschecks en fijnmazige filters zijn tijdrovend als je ze accuraat wil maken, en in de wedloop om het grootste taalmodel sneuvelen die dus helaas ook maar al te vaak.

Gegeven de enorme verscheidenheid aan bronnen, websites, tekstformatteringen en dataverzamelingsmethodes, is het zo haast onvermijdelijk geworden dat in datasets van die grootteorde toch nog persoonsgegevens of auteursrechtelijk beschermde teksten terechtkomen – zelfs als men moeite doet om enigszins correct te handelen. Reden genoeg om zelf eens in zo’n dataset te duiken en te kijken wat we daarin terugvinden.

OSCAR

OSCAR is een meertalige dataset die regelmatig wordt gebruikt voor niet-Engelstalige taalmodellen. De Nederlandstalige subset ervan kan dienen als basis van een Nederlandstalige tekstgenerator. OSCAR is op zijn beurt afgeleid van CommonCrawl, een grootschalige dataset van scraped websites, waarvan de makers wel aangeven dat robots.txt en HTML no-follow specificaties gehonoreerd werden, maar waar verder weinig meer mee gebeurd is dan gegevensopslag. OSCAR groepeert die per taal, voegt wat extra preprocessing toe, en zet de tekstfragmenten in willekeurige volgorde, om zo copyrightproblemen te vermijden. We doen hier geen uitspraak over de vraag of dat wel voldoende is voor dat doel. Een bijkomend effect daarvan is wel dat de inhoudelijke relatie tussen opeenvolgende tekstfragmenten in deze dataset dus verloren is gegaan. (De laatste paper van de auteurs probeert daar alsnog een mouw aan te passen.)

We bekijken de Nederlandstalige gegevens uit de eerste versie van deze dataset uit 2019 (toegang tot versie 2021 of versie 2022 vereisen registratie of aanvraag). Deze is vrij beschikbaar in de dataset repository van Huggingface, dat ook een eerste preview van de inhoud voorziet. Bij Huggingface vermeldt men summier dat de dataset persoonlijke of gevoelige informatie kan bevatten, en dat de training van een AI-model op basis van deze dataset gevoelig kan zijn voor biases, zonder dieper in te gaan op deze problematiek. De verantwoordelijkheid hiervoor wordt bij de gebruiker van de dataset gelegd.

De Nederlandstalige subset van OSCAR bestaat uit 126.064.721 tekstfragmenten van één tot enkele zinnen lang, die we kunnen samengevoegen tot 1 tekstbestand met een grootte van ongeveer 40GB. In wat volgt doorzoeken we deze dataset naar gegevens die als persoonlijk of gevoelig beschouwd zouden kunnen worden. Het valt aan te nemen dat die gegevens grotendeels zijn gescrapet zonder medeweten van de originele auteurs of van de websites waarop ze oorspronkelijk gepubliceerd waren. We tonen telkens een selectie van wat we zoal terugvinden ter illustratie, maar om de mogelijke privacy- en copyrightproblemen niet erger te maken dan ze al zouden kunnen zijn, maskeren we in dit artikel de gevonden gevoelige gegevens alsnog en markeren we ze rood.

Gevoelige gegevens in OSCAR

Door gewoon reguliere expressies toe te passen, die je vaak kan copy-pasten van het internet, kunnen we al veel boven water halen. Om emailadressen te detecteren, gebruiken we een relatief eenvoudig patroon, waarmee we 685.968 potentiële matches terugvinden (let wel dat veel algemene emailadressen, bijvoorbeeld van helpdesks of infolijnen of grote organisaties, herhaaldelijk voorkomen):

grep -a -e "[a-zA-Z0-9._]\+@[a-zA-Z]\+.[a-zA-Z]\+" oscar_nl_full.txt

• Ik gooide enkele nieuwe data online! Wie zin heeft kan zich inschrijven door te mailen naar e*******s@gmail.com
• Ontdek hoe je een WordPress thema vindt dat echt bij jou past! www.speciaalgeselecteerd.nl jouw gids voor WordPress thema s Door: S******* v** N******** Datum: 1-1-2016 E-mail: s********@innonet.nl WordPress
• De hoofdleiding bestaat uit D***** V******, G***** G*******, M**** W****** en F***** V*** B*****, hen kan je contacteren via 0497****** (D*****), 0493****** (G*****), 0477****** (M****) en 0498****** (F*****). Een mailtje naar i***@c*********.be is ook altijd mogelijk. Zij zullen jullie graag helpen met vragen, opmerkingen of klachten.

Veel emailadressen lijken afkomstig van contactpagina’s op websites van bedrijven, organisaties, maar je herkent ook overduidelijk verenigingen, lokale initiatieven, jeugdbewegingen, en forumgebruikers die hun persoonlijke contactgegevens achterlaten, waaronder telefoonnummers. Het volgende patroon zoekt naar cijfercombinaties die eruit zien als een Belgisch telefoonnummer, in de meest voorkomende schrijfwijzen. (Het patroon is iets te algemeen opgesteld, met als nadeel dat we er ook onderdelen van niet-telefoonnummers mee vinden.) Dat leidt alleszins al tot 289.461 potentiële matches:

grep -a -P "(((\+|00)32[ ]?(?:\(0\)[ ]?)?)|0){1}(4(60|[789]\d)\/?(\s?\d{2}\.?){2}(\s?\d{2})|(\d\/?\s?\d{3}|\d{2}\/?\s?\d{2})(\.?\s?\d{2}){2})" oscar_nl_full.txt 

• Tijdens de openingstijden kan je via de Live Chat of via de telefoon 07******** vragen stellen aan één van onze medewerkers.
• […] Heeft u vragen over onze werkwijze, prijzen of materialen dan zijn we bereikbaar op de nummers 03/***.**.** en 03/***.**.**. Ook kunt u een e-mail sturen naar [email protected] of het contactformulier invullen.
• Op 22 september vertrekken we op speel-weekend naar Ronse. Wil je nog mee? Als de bliksem bellen naar R******* 0496/**.**.**
• Propere betonnen palen 8 stuks, geen beton/cement aan de onderkant van de paal- lengte 2.05m. Bieden vanaf €7/stuk. Tel 0478/******

Ook hier vinden we veel contactgegevens van bedrijven, maar een aanzienlijk deel zijn ook persoonlijke telefoonnummers afkomstig van berichten die mensen postten op online marktplaatsen of zoekertjeswebsites. Bankrekeningnummers, BTW-nummers e.d. duiken ook op tussen de gevonden data. Om te blijven focussen op persoonsgerelateerde data, gaan we nog op zoek naar Twitter of Instagram handles. Deze kunnen bijvoorbeeld afkomstig zijn van conversaties op Twitter en Instagram zelf, van internetfora waar mensen erover spreken, of van de footers van webpagina’s met links naar sociale media. Afgezien van enkele bedrijven wiens naam of product met een @ begint, gaan achter de meeste gevonden handles echte, actieve mensen of organisaties schuil. We vinden zo 131.364 potentiële matches:

grep -a -e " @[a-zA-Z0-9]\+" oscar_nl_full.txt

• Vandaag waren we op bezoek bij Leo Timmers, maker van Een huis voor Harry, het Prentenboek van het Jaar 2019! En we gingen Billy ontmoeten, de kat waar Harry op geïnspireerd is. Ik had dus de dag van m’n leven. @v*********** #cat #books #brussels #reading #catsofbrussels #eenhuisvoorharry 
• […] R***** twitterde dit naar mij en @p********, afgelopen zondagmiddag. We hadden het over de blogs die Ruud had willen schrijven die dag: drie stuks maar liefst. De blogs kwamen er inderdaad niet. Nooit meer. R***** overleed maandagavond [datum]. Ik heb een goede vriend verloren.
• Zeg @******** wat willen jullie nou in de omgangsvorm: ‘u’ of ‘je’? Maak een keuze! https://t.co/********
• @******** En niet alleen dat. Het kenteken *-***-** staat mooi op beeld. Kijk dus uit voor deze asociale weggebruiker, mede-weggebruikers. @ [datum]

Er duikt duidelijk een heel palet aan persoonsgebonden informatie in deze dataset op, zoals ook nummerplaten, berichten over ziekte of overlijden, politieke voorkeuren, informatie over wanneer personen waar geweest zijn, en nog heel wat meer. Met hetzelfde gemak vinden we ook beledigingen tegen personen terug, verwensingen allerhande, racistische fragmenten, … we kunnen alleszins heel lang bezig blijven als we hierop enige grip willen krijgen in zo’n dataset.

Een heel ander gevoelig onderwerp is erotische inhoud. Er zijn alvast 2.459.800 matches voor woorden die beginnen met “seks” of “sex” in dit eerste deeltje van de dataset. Voorbeelden daarvan geven we terwille van de goede smaak niet mee, maar u mag de auteur op zijn woord geloven dat de meeste gevonden tekstfragmenten niet van droog-wetenschappelijke papers of schoolse seksuele opvoeding afkomstig zijn. Op een totaal van 126 miljoen zinnen, kunnen we zo schatten dat zulke inhoud ongeveer 2% van het totaal uitmaakt in deze dataset. 

Kom ik er in voor?

Dat kunnen we gemakkelijk achterhalen:

grep -a -e "Joachim Ganseman" oscar_nl_full.txt  

• De 27e Internationale Olympiade Informatica vond plaats in Almaty, Kazachstan. De Belgische ploeg werd gevormd door Damien Galant (5e middelbaar), Robin Jadoul, Mattéo Couplet en Nico Ekkart (allen 6e middelbaar). Zij werden begeleid door Damien Leroy en Joachim Ganseman. […]
• […] De bouwstenen voor artificiële intelligentie (AI) liggen klaar, maar ze staan op los zand. Dhr. Joachim Ganseman van Smals Research bestudeerde de zwaktes van AI. In zijn artikel op de Research-blog bespreekt hij een aantal uitdagingen voor de toekomst.
• Joachim Ganseman wordt onderscheiden voor de ijver waarmee hij als jonge doctoraatsstudent de Belgische informatica-olympiade heeft gesticht, coördineert en communiceert in beide landshelften, met bijzondere inspanningen voor de toegankelijkheid voor alle leerlingen, ongeacht voorkennis.

In 7 tekstfragmenten komt mijn volledige naam voor, voornamelijk in verband met mijn engagement bij de Belgische Informatica-olympiade van 2011 tot 2018. Geen info die iets schandaligs of schaamtelijks bevat, integendeel, maar ik was niet op de hoogte. Als je ooit met naam en toenaam in de krant of op een website van een grotere organisatie hebt gestaan, lijkt de kans alleszins groot dat je naam in dat verband ook in de OSCAR dataset voorkomt. Het blijft dus erg belangrijk om in het achterhoofd te houden dat dat wat eenmaal op het internet staat, er erg moeilijk terug af gaat.

Misschien kan het een goed idee zijn om, naar analogie van Have I Been Pwned die je waarschuwt voor paswoordlekken, een gelijkaardige dienst te hebben bij dataset repositories waarmee gebruikers kunnen checken of hun persoonlijke informatie voorkomt in datasets? Tijd en middelen ontbreken om zoiets zelf verder uit te werken, maar we laten het hier staan als een interessante suggestie.

En dan?

We moeten nog vermelden dat de makers van de CommonCrawl en OSCAR datasets zelf niet Nederlandstalig zijn. Zij hebben dan ook niet onmiddellijk manieren ter beschikking om de verzamelde fragmenten in het Nederlands (en in de meeste van de andere 165 talen in OSCAR) op hun inhoudelijke merites te gaan beoordelen, en presenteren deze datasets “as is”.

Gegeven het feit dat persoonsgebonden gegevens gemakkelijk te vinden zijn op het internet voor wie een beetje zoekt – en zeker op sociale media of op marktplaatsen waar ze gretig uitgewisseld worden – is het niet verwonderlijk dat deze gegevens ook terechtkomen in datasets verzameld via webscraping, als er een breed net wordt uitgegooid en weinig wordt gefilterd.

Smals Research is een technisch team zonder juristen in haar rangen; we laten uitspraken over het wettelijke kader rond webscraping, auteursrechten, en de gebruiksvoorwaarden van websites, in een internationale context, dan ook liever over aan mensen die daar meer van kennen dan wij. Het is in onze sector wel algemeen bekend dat de persoonsgegevens van EU-ingezetenen beschermd worden door de GDPR. Dat houdt onder andere in dat zij de inzage en verwijdering van hun gegevens moeten kunnen vragen, en informatie moet kunnen krijgen over het gebruik ervan. Het wordt natuurlijk moeilijk om dat recht effectief uit te oefenen, als gegevens op elk moment in een externe database kunnen worden overgenomen, zonder medeweten van die persoon of zelfs van de website waarop ze gepubliceerd waren.

Wie van zulke datasets gebruik maakt om AI systemen te trainen, is technisch gesproken de daarin begrepen persoonsgegevens aan het verwerken, en lijkt zo alvast automatisch een verantwoordelijkheid te hebben ten aanzien van die betreffende personen. Het is daarnaast niet ondenkbaar dat een verkeerd of slecht getraind AI-systeem deze gegevens expliciet opneemt in het resulterend model, en ze aanwendt om bepaalde beslissingen te nemen, wat een risico op bias met zich meebrengt. Tot slot weet je nooit of er ergens een slecht beveiligde website gescrapet werd door de dataset-maker, waardoor er misschien login-gegevens of paswoorden voorkomen in de dataset.

Een alternatieve werkwijze

De onderzoeksgroep Computationele Linguïstiek van de Universiteit van Groningen bouwde een eigen variant van een Nederlandstalig GPT-2 model. Zij zijn natuurlijk wél Nederlandstalig, en waren ook selectiever in het kiezen van hun trainingsdata. In hun paper lezen we dat die bestaat uit de Nederlandstalige Wikipedia (2.0GB), een grote hoeveelheid E-books (6.5GB), een dataset van nieuwsartikels die weliswaar nog van 2007 dateert (2.9GB) aangevuld met artikels van andere nieuwswebsites (2.1GB). Na het wegfilteren van duplicaten is dat goed voor een trainingsdataset van 13GB aan Nederlandstalige tekst. Gegeven deze bronnen is het aannemelijk dat hun dataset alvast correcter geschreven Nederlands bevat van een inhoudelijk hogere standaard.

De eigenlijke dataset vonden we na een korte zoektocht niet onmiddellijk terug, dus het is moeilijk de inhoud verder te bekijken – wie weet waar ze ergens beschikbaar zou zijn, mag het steeds laten weten. Het valt alleszins te verwachten dat de inhoud van deze dataset minder problematisch zal zijn op het vlak van persoonlijke gegevens dan OSCAR. Langs de andere kant stelt zich, met een dataset afkomstig van krantenartikels en e-books, misschien wel nog een copyrightprobleem.

Kieskeurig zijn qua trainingsdata heeft weliswaar een keerzijde. Een generatief taalmodel getraind op een selecte dataset is gelimiteerder qua teksten die het kan produceren. Tekstfragmenten die lijken op sociale-media-posts zullen moeilijk gegenereerd kunnen worden door een model dat niet getraind werd op data afkomstig van sociale media, en een hoge aandeel e-books leidt ook tot prozaïscher teksten. Tot slot maakt het groot aandeel van oudere nieuwsartikels ook dat het getrainde model teksten “uit die tijd” zal produceren, en relatief minder woordenschat en zinswendingen kent over recente trends, technologische uitvindingen of politieke ontwikkelingen.

Conclusie

We hebben hier slechts één Nederlandstalige dataset onder de loep genomen, maar het spreekt voor zich dat dezelfde problemen zich stellen in gelijkaardige datasets voor andere talen.

Het valt op dat enkele eenvoudige filters, bijvoorbeeld om emailadressen, rekeningnummers, persoonlijke profielinformatie of andere persoonsgegevens te detecteren, al een heel deel van deze problematische inhoud zouden kunnen wegfilteren. Een sluitende garantie geven dat er niets fouts meer voorkomt is haast onmogelijk in datasets van deze grootteorde, maar hier hebben we toch kunnen illustreren dat er soms wel érg weinig moeite gedaan lijkt te zijn om de datasets een beetje op te schonen. 

Propere datasets maken, deze inhoudelijk onderzoeken en daarbij in de diepte graven, kost natuurlijk tijd en moeite – enkel om problematische stukjes weg te vijlen die in hun geheel maar een klein deeltje uitmaken van de hele dataset, wat dus waarschijnlijk ook maar een kleine impact zou hebben op het daaruit resulterende taalmodel. Het is moeilijk hard te maken dat zulk monnikenwerk zich economisch terugverdient, en garanties dat je effectief alles verwijdert zijn er evenmin.

Toch is het belangrijk dat er voldoende aandacht geschonken wordt aan de kwaliteit van de onderliggende datasets. Als dat niet werkbaar is vanwege hun grootte, moet je je minstens een idee vormen van de impact van mogelijke onregelmatigheden erin. Een data protection impact assessment is net daarvoor bedoeld, en is in sommige gevallen verplicht.

Het blind hergebruiken van een dataset die je zelf niet hebt samengesteld, is een slecht idee. Dat geldt bij uitbreiding eigenlijk ook voor het indirect gebruik ervan via een derde partij of een externe software-library. Dit is overigens een algemeen advies dat geldt voor elke toepassing van machine learning. Wie beter wil doen en ethiek wat hoger in het vaandel wil dragen, vindt goede startpunten in de paper Datasheets for Datasets en bij initiatieven zoals AI Now.

______________________

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

Als het doel is om een functioneel alternatief te voorzien voor gevoelige data, zijn tools voor de creatie van synthetische data bij uitstek geschikt. Ze kunnen immers meer dan enkel de bestaande gegevens door elkaar gooien: ze zijn gemaakt om de structuur van gegevens aan te leren, waarna je willekeurig veel nieuwe gegevens volgens dezelfde structuur kan aanmaken. In combinatie met generatoren voor totaal fictieve gegevens, hebben we daarmee alles voorhanden om niet alleen de originele gegevens te verbergen, maar ook om te zorgen dat wat in de plaats komt, realistisch oogt.

Dat betekent echter niet dat het een kwestie is van een druk op de knop. Eén en ander hangt af van allerlei randvoorwaarden en aannames over de inhoud en structuur van de gegevens. Afhankelijk van de beoogde toepassing of het doel, kan het nodig zijn om extra beperkingen en filters op te leggen, of misschien net om bepaalde delen van de gegevens buiten beschouwing te laten. In dit artikel kijken we vooral naar die praktische bekommernissen: wat kom je zoal tegen als data professional die synthetische data moet aanmaken?

Setup

Wie een dataset wil scramblen, heeft uiteraard toegang nodig tot de originele gegevens. Het spreekt voor zich dat het uploaden van gevoelige data naar een cloud service of zelfs het gebruik van een Docker container voorzien door een derde partij, slechts mogelijk is als er grondig is nagedacht over GDPR-compliance, eventueel een Data Protection Impact Assessments (DPIA) is opgesteld, en best ook met de DPO is overlegd. We doen zelf geen enkele uitspraak over de geschiktheid van eender welke tool vis-à-vis de GDPR-wetgeving. Voor al wat volgt gaan we ervan uit dat we werken met tabulaire, tekstuele of numerieke gegevens, die lokaal beschikbaar zijn – met andere woorden, een grote spreadsheet.

De markt

In een vorig artikel vermeldden we al enkele spelers vanuit de optiek van AI-projecten en software testing. Hier ligt onze focus meer op de privacybescherming en data science. Voor het analyseren en synthetiseren van tabulaire gegevens is er een heel sterk groeiende markt. Enkele interessante spelers zijn de volgende – en er zijn er ongetwijfeld nog veel meer:

• Mostly.ai
• YData
• Tonic
• Gretel
• Synthesized.io

Open source tools zijn er minder en zijn vaak afkomstig van projecten die op universiteiten zijn begonnen. Benerator vermelden we apart omdat deze al langer bestaat en ook een uitgebreid commercieel aanbod heeft. Jongere open source initiatieven zijn onder andere:

• Synthetic Data Vault (SDV)
• Mimesis
• Synthia
• Data Responsibly‘s DataSynthesizer
• MITRE’s Synthea / SyntheticMass (toegespitst op eHealth)

SDV is momenteel de populairste van de open source tools, en we gebruiken deze voor al wat volgt. In onze Quick Review vind je meer uitleg over deze tool.

Het stappenplan

Het plan van aanpak om synthetische data te produceren is bij de meeste tools heel gelijkaardig. We kunnen het onderverdelen in 6 grote stappen:

1. Upload en inlezen van de gegevens. Met name de tekst-encodering kan hier wel eens voor problemen zorgen als de gegevens uit oudere bronnen afkomstig zijn. Problemen hiermee moeten opgelost worden voordat men aan de volgende stappen begint.
2. Analyse en typering van de gegevens. Voor elke kolom: welke zijn de minima, maxima, de waarden die voorkomen, zijn er missende waarden, etc. Omdat de computer niet weet wat de achterliggende betekenis van de gegevens is, is het vaak nodig om in deze stap manueel correcties uit te voeren:
   • Niet alle getalwaarden kan je zomaar beschouwen als “hoeveelheden” die je vrij kan optellen of aftrekken. Sommige zijn categoriën, zoals NACE codes of postcodes, andere zijn misschien onderdeel van een datum.
   • Ontbrekende gegevens zal je in sommige gevallen kunnen gelijkstellen met 0 of met een reeds aanwezige default categorie, maar vaak wil je ze misschien beschouwen als een klasse apart. Een ontbrekende geboortedatum wilt immers niet zeggen dat iemand geboren is in het jaar 0.
3. Transformatie van gegevens. Hierbij worden o.a. ontbrekende gegevens afgesplitst, of categorische variabelen omgezet in een getal-encodering om compacter voorgesteld te worden. Deze stap gebeurt vooral achter de schermen, maar het is vaak mogelijk om manueel configuratie-opties toe te voegen: van sommige kolommen willen we bijvoorbeeld forceren dat de waarden altijd uniek zijn, andere kolommen willen we misschien negeren.
4. Een generatief model trainen. Dit kunnen zowel “klassieke” statistische modellen zijn als deep-learning varianten. Sommige modellen zijn enigszins in staat om diepere verbanden tussen de gegevens te reproduceren, maar dit blijft erg afhankelijk van de hoeveelheid gegevens en hun distributie.
5. Genereren van nieuwe gegevens. Bij gebruik van een generatief model staat er in principe geen limiet op de hoeveelheid gegevens die aangemaakt kan worden.
6. Evalueren en visualiseren van de resultaten. De meeste commerciële tools genereren een mooi eindrapport met daarin een verslag van het hele proces en enkele samenvattende grafieken die toelaten om in een oogopslag te zien of er anomalieën zijn, en of er nog andere correcties toegevoegd dienen te worden. Bij open-source tools is dat vaak beperkt tot enkele metrieken en moet je verdere gegevensanalyse zelf bijprogrammeren.

Gegevens

Wie de tools liefst niet uittest op eigen (gevoelige) data, vindt veel datasets op Kaggle. Zelf maakten we voor onze testen onder andere gebruik van een variant op de Adult Census Income dataset.

Praktische bekommernissen

Telgegevens

Sommige datasets bevatten tellingen. Dat kan het resultaat zijn van een COUNT() functie in de SQL-query voor data-extractie. Om dan een correcte inschatting te kunnen maken van de distributies van de andere variabelen, is het nodig om deze telling ongedaan te maken en de tabel te “unrollen”. Een nieuw gegenereerde tabel moet nadien natuurlijk terug “opgeteld” worden om terug in het originele formaat te staan. Op deze manier kan men desgewenst ook garanderen dat de resulterende tabel ook effectief hetzelfde aantal records voorstelt als in de originele database, zelfs al is er een ander aantal combinaties van variabelen. De kolom met de telvariabele wordt uiteraard niet meegenomen in het generatief model.

Behoud van alle mogelijkheden

Voor sommige toepassingen kan het nodig zijn dat een gesynthetiseerde dataset zeker ook alle mogelijke waarden bevat die voorkomen in de originele dataset – bij wijze van representativiteit voor de originele dataset. Maar met name als bepaalde waarden erg zeldzaam zijn, bestaat er een reëel risico dat ze niet genoeg doorwegen bij de training van het generatief model, waardoor ze achteraf bijna nooit gegenereerd worden. De meeste generatieve modellen laten het conditioneel samplen van gegevens toe: datapunten kunnen gegenereerd worden waarvoor de waarde van een of meerdere variabelen vaststaan. De distributie van de andere waarden volgt dan een conditionele distributie, gegeven deze vaste waarden. Doe dat voor elke waarde die voorkomt in de originele dataset, en men kan garanderen dat elke waarde (alleszins onafhankelijk) voorkomt. Dit vraagt weliswaar wat extra programmeerwerk om gedaan te krijgen, en bovendien impliceert dit ook dat een outputdataset een bepaalde minimumgrootte zal hebben.

Duplicaten en overlap

Het genereren van nieuwe gegevens gebeurt door te samplen uit een generatief model – te vergelijken met het trekken van een lottocombinatie. Zeker als er veel gegevens worden gesynthetiseerd, is het altijd mogelijk dat er twee keer hetzelfde tussenzit. Is dat ongewenst, dan moet een optie toegevoegd worden om duplicaten te verwijderen – en nadien opnieuw gegevens bij te genereren totdat de gewenste grootte opnieuw is bereikt. Eventueel kan men ook forceren dat gesynthetiseerde gegevens zeker niet mogen voorkomen in de originele dataset – dat de twee datasets dus volledig disjunct zijn. Dat laatste voegt echter weinig toe qua privacybescherming: zonder kennis van de originele dataset, kan men steeds bogen op een zekere plausible deniability dat een synthetisch record identiek zou zijn aan een record uit de echte dataset.

Trainingstijd

Zeker bij grote datasets met veel variabelen, en bij gebruik van deep learning tools kan het een lange tijd in beslag nemen om een generatief model te trainen. Dat maakt het moeilijk om iteratief te werk te gaan bij het verfijnen van de opties. Het kan nuttig zijn om tijdens de ontwikkeling, de dataset ten grondslag van de training te beperken tot enkele duizenden willekeurig geselecteerde records. Daarbij mogen we al wat hierboven al werd vermeld natuurlijk niet uit het oog verliezen – bijvoorbeeld, ook hier kan het nuttig zijn om een extra optie te hebben die garandeert dat een selectie uit de trainingset nog steeds minstens 1 datapunt bevat voor elke waarde van elke variabele.

Afhankelijke kolommen

Een kolom die volledig (lineair) afhankelijk is van een of meerdere andere kolommen, moeten we verwijderen en achteraf terug herberekenen. Dat is typisch het geval bij wiskundige afhankelijkheden: een kolom die een som is van twee andere kolommen, of een percentage van een andere kolom voorstelt. We kunnen best niet hopen dat een generatief model dat verband zelf aanleert. Het is veel zekerder om zulke afhankelijke kolommen gewoon te verwijderen uit de dataset, en nadat een nieuwe dataset is gegenereerd, deze kolommen terug te berekenen op basis van de gesynthetiseerde data en dan pas toe te voegen.

Constraints

Iemands geboortedatum valt altijd vroeger dan iemands sterfdatum. Dat is logisch, maar als men voor een fictief persoon een nieuwe geboortedatum en sterfdatum genereert uit het generatief model dat werd getraind op de distributies van alle geboorte- en sterfdata in een dataset, dan kan het voorvallen dat deze logische beperking niet altijd gerespecteerd blijft. Het kunnen opleggen van constraints – de ene variabele is altijd groter of kleiner dan een andere, of altijd positief of negatief, etc. – is een belangrijke feature. Eenvoudige beperkingen, zoals zonet aangehaald, zijn eventueel nog eenvoudig te implementeren door “rejection sampling”: voldoet een gesynthetiseerd record niet aan alle constraints, wordt het gedeleted en wordt een nieuw gegenereerd, totdat alle records voldoen. Worden de constraints ingewikkelder of strikter, dan kan het nodig zijn om zelf de nodige filters te programmeren, of om een post-processing stap te definiëren waarin correcties uitgevoerd kunnen worden.

Kolommen bevriezen

Willen we een dataset scramblen met een kolom geslacht en een kolom woonplaats, dan is het eigenlijk voldoende om enkel de kolom met woonplaatsen door elkaar te husselen om een goed gemengde dataset te bekomen. Het geslacht is daar onafhankelijk van, en kunnen we even goed negeren. Het bevriezen van kolommen, in feite gewoon het verwijderen voor de verwerking en terug eraan plakken na het einde, kan zo een grote tijdswinst opleveren. Het is weeral een kolom minder waarvan de distributie aangeleerd moet worden. 

Kolommen bevriezen, impliceert weliswaar een voorwaarde: ofwel dat de gesynthetiseerde dataset even lang moet zijn als de originele zodat de dimensies overeenkomen, ofwel dat de gegevens in de bevroren kolom(men) helemaal willekeurig verdeeld zijn, dus op geen enkele manier gesorteerd of gegroepeerd, zodat de bevroren kolom(men) zonder effect op de gegevensdistributie kunnen verkort of verlengd worden. Dat laatste kan echter moeilijk te bewijzen zijn.

Maar zeker als het de bedoeling is dat een gesynthetiseerde dataset even groot is als de originele, wat toch vaak voorkomt, is het een enorm grote tijdswinst als van een dataset met 60 kolommen, er slechts 6 moeten gesynthetiseerd worden om een voldoende gescramblede dataset te krijgen. Bovendien zal een generatief model met minder kolommen meestal ook accurater getraind kunnen worden, dus is het resultaat waarschijnlijk zelfs kwalitatief beter. Eventueel kan de synthetische dataset achteraf nog eens geshuffled worden om enige overgebleven structurele gelijkenis met de originele dataset te verbergen. 

Rapportering en grafieken

De gescramblede dataset moet nog vergeleken worden met het origineel, om te verifiëren dat de procedure wel goed verlopen is en of er bepaalde parameters beter aangepast zouden kunnen worden. Het visualiseren van datasets is een uitdaging op zich, waarbij rekening moet worden gehouden met het type van variabele en de waarden die ze kan aannemen. Boxplots zijn vaak een goede keuze voor continue variabelen, en staafdiagrammen voor categorische variabelen. Daarbij moet aandacht worden besteed aan de assen, die overeen moeten komen om in een oogopslag te kunnen vergelijken. Het kan nodig zijn hier en daar extra te groeperen of aggregeren om grafieken van complexe categorische variabelen overzichtelijk te houden. Voor de verbanden tussen twee variabelen kan men verschillende vormen van bivariate plots, heatmaps en correlatiematrices benutten. Werkt men in Python dan zijn matplotlib en seaborn nuttige grafische libraries.

Conclusie

Met synthetische data generatoren hebben we een krachtige tool in handen om data scrambling te kunnen doen. We kunnen er bovendien meer mee dan enkel de gegevens door elkaar haspelen: desgewenst interpoleren ze ook tussen minimum- en maximumwaarden, of tussen datums, en zo kunnen ze ook fictieve gegevens genereren volgens dezelfde structuur als de originele dataset. Het aanmaken van een echt goede synthetische dataset vergt vaak een iteratieve aanpak, om het achterliggend generatief model te finetunen.

We merken in de praktijk dat er heel wat extra checks en balances komen kijken bij het werken met echte datasets. Het is zelden zo dat een generatief model gegenereerd uit een willekeurige dataset met default parameters, vanaf de eerste keer optimaal is. Met name erg ongelijke distributies zorgen voor problemen in het leerproces en voor statistische instabiliteit in het resulterende generatief model. Bij wijze van voorbeeld: als een dataset slechts 1 persoon bevat met een zeldzame ziekte, en het is toevallig een 43-jarige Limburger, dan riskeren we dat het systeem leert dat alle personen met deze ziekte per definitie 43-jarige Limburgers moeten zijn. Bovendien merken we dat we de beste resultaten bekomen als een dataset weinig variabelen heeft, en voor elke waarde van elke variabele veel datapunten (rijen, samples). Dit alles maakt dat we de beste resultaten vaak bekomen door zoveel mogelijk kolommen te bevriezen, en het aantal te scramblen kolommen te beperken tot het minimum noodzakelijke om het doel van scrambling te bereiken. Die oefening kan voor elke dataset anders zijn.

Een vraag die regelmatig terugkomt is: kunnen we dezelfde analytics op de dusdanig gescramblede / gesynthetiseerde dataset loslaten en leidt dat dan tot dezelfde conclusies? Het antwoord is: het hangt ervan af hoe diep je wilt gaan. De structuur van de gegevens wordt in het generatief model immers approximatief aangeleerd. Daarbij merken we:

• De statistieken en verdeling van individuele variabelen (minimum, maximum, gemiddelde etc.) blijven meestal relatief goed behouden,
• De verbanden tussen twee variabelen (correlatie etc.) blijven matig behouden, en hoe gelijkmatiger en stabieler deze variabelen zijn verdeeld hoe beter dat dat lukt,
• De verbanden tussen meerdere variabelen (regressies etc.) blijven relatief slecht behouden of gaan verloren.

Voor complexe analyses zijn scrambled of synthetische data dus zeker geen drop-in replacement voor de echte data. Ze zijn wel erg nuttig voor het testen of ontwikkelen van data processing scripts of analyse-pipelines, omdat we wel een goed beeld hebben van welke waarden er allemaal voorkomen en in welk bereik deze vallen.

We hebben nog heel wat andere potentiële struikelblokken die we in de praktijk kunnen tegenkomen niet besproken. Er kunnen afhankelijkheden bestaan tussen rijen – bijvoorbeeld, een tabel die verschillende records bevat per persoon. Er kunnen ook verbanden zijn in de tijd – bijvoorbeeld datasets die bestaan uit opeenvolgende kwartalen, of datasets waarin de datums die voorkomen alleen maar werkdagen zijn en nooit weekenddagen, wat maakt dat je niet zomaar eender welke datum kan synthetiseren. Een dataset kan ook bestaan uit meerdere tabellen die met elkaar verbonden zijn. Zulke complexere problemen zijn mogelijk nog voer voor een vervolg-artikel later dit jaar.

______________________

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

Leximancer est un outil commercial qui dans une grande quantité de texte, identifie les sujets les plus importants, les regroupe en concepts connexes, et visualise les relations entre eux. L’utilisateur peut affiner les résultats à chaque étape intermédiaire. Parmi les domaines d’application possibles se trouvent la criminalistique ou l’inspection numérique, l’analyse des questionnaires à grande échelle ou encore les revues de presse/littérature.