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.

Avertissement : la suite est un exemple pédagogique visant à illustrer le principe du “machine learning”. Il ne se veut pas exact par rapport au fonctionnement du monde bancaire.

Une méthode qui pourrait aider la banque à faire son choix serait, à l’aide d’experts du crédit, de développer un “arbre de décision” : si le requérant a un salaire en CDI de plus de x% du remboursement mensuel, compter le nombre de défaut de payement des autres crédits. Si ce montant est inférieur à Y, accorder le crédit. Sinon, si le montant moyen de ses comptes d’épargne est supérieur à Z, accorder également, etc.

Définir un tel arbre peut être complexe, et parfois arbitraire, mais relèverait de la “programmation (informatique) traditionnelle” : on fournit à un ordinateur un programme (l’arbre de décision avec toutes ses branches, ses conditions et ses seuils) et des données (le montant du crédit demandé, le salaire, les avoirs, le montant des autres crédits en cours…), et il fournira un “output” (accorder ou non le crédit).

Programmation traditionnelle vs Machine Learning

Une approche plus puissante est d’utiliser l’apprentissage machine, ou “machine learning”. Le principe de base consiste à fournir à l’ordinateur un grand nombre de données sur le passé (appelées observations), concernant les crédits déjà accordés par la banque, puis de lui fournir le résultat (ou un “label”), à savoir le fait que le client ait pu ou non rembourser son crédit (on pourrait être plus fin en définissant des catégories : “a remboursé son crédit sans difficulté”, “a eu entre A et B retards de payements”, …, “a été en défaut de payement”). Sur base de ceci, le machine learning consiste à entraîner l’ordinateur pour qu’il soit capable de produire un programme qui pourra, sur base des données d’une future demande, prédire si oui ou non le client remboursera ses dettes.

Les données en question, on peut les voir comme un grand tableau, avec une ligne par crédit accordé par le passé (observation), et une colonne pour chaque donnée, que l’on appelle “feature” ou “variable”: le montant du crédit, le salaire, le montant des autres crédits, le nombre de retard de payements… et peut-être aussi des features moins avouables (le genre du/de la client(e), ou le montant des dépenses en pharmacies dans les 6 derniers mois…). On peut très bien ajouter des features sans savoir si elles auront un quelconque impact sur le résultat, et laisser l’ordinateur le découvrir. 

Pour être plus précis, l’ordinateur ne va pas créer un programme “à partir de rien”: on va en fait choisir un algorithme de machine learning (Decision Tree, Random Forest, Gradiant Boosting…) et l’entrainement permettra de choisir les paramètres de l’algorithme (qui peuvent être plusieurs milliers, voire plusieurs millions dans le cas de la “deep learning”, une des familles les plus récentes des algorithmes de machine learning). Cet algorithme “paramétré” pourra ensuite être utilisé en production lorsqu’une nouvelle demande de crédit sera soumise à la banque.

Classification, regression, clustering

L’exemple que nous avons donné ci-dessus illustre les algorithmes de “classification” : à partir des données d’entrée (features) associées à des labels connus, on entraîne le modèle à déterminer une catégorie, ou une classe, pour un nouvel arrivant : “accorder le crédit”, “refuser le crédit”. Il est aussi possible d’utiliser un algorithme de régression: à partir des features et des labels, déterminer une valeur numérique (montant à accepter, taux du crédit…). Ces deux groupes (classifications et régression) font partie de la famille des méthodes supervisées, parce qu’un résultat attendu (le label) est fourni pour les données d’entrainement. 

Il existe aussi une famille de méthodes non-supervisées, lorsqu’on ne fournit pas de label. On parle principalement de “clustering“, le but étant d’arriver à déterminer automatique des groupes de clients (dans notre cas) ayant des caractéristiques similaires.

Avec des graphes ?

Dans ce blog (voir par exemple ici ou ici), nous avons souvent montré la puissance de l’analyse réseau, qui consiste à ne plus considérer les données comme des individus ayant chacun un certain nombre de caractéristiques, mais comme des entités liées entre elles par des relations. Dans notre cas, on pourrait considérer un modèle simple avec des comptes bancaires et des personnes, les relations entre comptes bancaires représentant les transactions, et celles entre personnes et comptes, l’appartenance. On peut facilement ensuite enrichir le modèle avec les domiciles des personnes et les numéros de téléphones, comme illustré ci-dessous.

Cette (nouvelle) façon de voir le problème permet de donner des perspectives supplémentaires à notre analyse. Voici quelques méthodes permettant d’augmenter les performances de notre moteur de décision. 

Pattern based features

En analyse réseau, on identifie souvent des “patterns“, ou des schémas, qui sont pertinents, spécifiquement pour le business étudié. On pourrait par exemple imaginer qu’une transaction entre deux personnes domiciliées à la même adresse ne doit pas être considérée de la même façon qu’entre deux personnes non-apparentées. On pourrait dès lors exclure ces montants – qui peuvent être vus comme des mouvements d’équilibrage internes entre les membres d’un même foyer – des dépenses totales du client. Dans un langage comme “Cypher” (le langage de requêtage de la base de données graph Neo4j), une telle transaction “t” pour un client “c” serait identifiée comme telle: 

(c:Client)-[:OWNS]->(:BankAccount)-[t:TRANSFERS]->(:BankAccount)<-[:OWNS]-(:Client)-[:LIVES_AT]->(:Address)<-[:LIVES_AT]-(c)

Dans cet exemple, “(c:Client)” désigne un nœud de type “Client”, nommé “c”, identique au dernier nœud du pattern ; et -[:OWNS]-> désigne l’appartenance d’un compte à une personne.

Cette description correspond au chemin ci-dessous : 

Dans le secteur de la lutte contre la fraude, on pourrait être intéressé par les personnes ayant effectué des virements vers des personnes ayant été convaincues de fraude par le passé, voire vers personnes vivant à la même adresse que des personnes négativement connues : 

• (c:Client)-[:OWNS]->(:BankAccount)-[:TRANSFERS]->(:BankAccount)<-[:OWNS]-(:Client {isFraudster:True})
• (c:Client)-[:OWNS]->(:BankAccount)-[:TRANSFERS]->(:BankAccount)<-[:OWNS]-(:Client)-[:LIVES_AT]->(:Address)<-[:LIVES_AT]-(:Client {isFraudster:True})

Où (:Client {isFraudster:True}) désigne un nœud de type “Client” ayant un attribut “isFraudster” de valeur “True”.

Sur base de ces patterns, on peut ajouter des nouvelles features aux données décrites plus haut dans cet article, soit booléennes (existe-t-il pour ce client des transactions vers des clients “fraudeurs”), soit numérique (fréquence des “auto-transferts”, ou ratio entre ceux-ci et les autres). Il n’est de nouveau pas nécessaire d’être sûr que la valeur soit corrélée avec le risque de défaut de payement : on laissera aux algorithmes de machine learning le soin de découvrir si elle est pertinente ou non.

Graph based features

L’avantage des méthodes décrites dans la section précédente est qu’elles permettent de rajouter des features qui sont très pertinentes et spécifiquement sélectionnées pour le domaine en question. La contrepartie est qu’elles peuvent être difficiles à identifier et à implémenter. Il existe cependant de nombreux algorithmes génériques pour les graphes, qui peuvent s’appliquer à très faibles coût, tout en proposant des métriques pertinentes. En particulier, les différentes méthodes de calcul de centralité (degree centrality, betweenness centrality, closeness centrality, PageRank…) donnent à chaque nœud (ou à chaque nœud d’un type spécifique) une valeur numérique qui peut être utilisée comme feature.

D’un autre côté, les méthodes de détection de communauté (Louvain, Label Propagation…) attribuent une catégorie (ou une communauté) à chaque nœud.  On peut l’utiliser directement, si l’algorithme de machine learning supporte les features catégoriques, ou indirectement, en comptant par exemple le ratio entre les transferts entre comptes appartenant à la même communauté et ceux des communautés distinctes.

Les algorithmes plus courts chemins peuvent également être pertinents : on peut par exemple considérer la distance du client à un client fraudeur, ou en défaut chronique de payement, si l’on part du postulat, certes moralement discutable, qu’une personne a plus de chances d’être en défaut de payement si elle est entourées de nombreuses personnes chroniquement en défaut de payement.

Notons que ces méthodes se servent en général uniquement de la topologie du réseau, et pas des attributs (ou éventuellement d’uniquement un attribut désignant un “poids” ou une distance). Toute la connaissance n’est donc pas utilisée.

Graph embeddings

En dehors des méthodes qui peuvent fournir des métriques dont la sémantique est en générale claire (un nœud avec un grand “PageRank” sera considéré comme “plus important” qu’un nœud en ayant un petit), il existe une série des méthodes (fastRP, node2Vec, GraphSAGE) qui permettent de calculer pour chaque nœud un nombre déterminé de valeurs (on parle de vecteur), qui offrent une sorte de résumé de la position du nœud au sein du graphe. Il s’agit du même principe que pour le “word embedding” en NLP.

Si l’on choisit de calculer un graph embedding de taille 16, on obtiendra donc 16 features utilisables par les algorithmes traditionnels de machine learning. Aucune de ces nouvelles colonnes ne sera interprétable en tant que tel. L’ensemble n’aura pas non plus de sémantique humainement compréhensible, mais on observe qu’elle peuvent néanmoins être pertinentes pour un algorithme de machine learning. On peut donc voir le “graph embedding” comme une sorte de fonction de hashing pour chaque nœud, dont la valeur n’est pas interprétable par un être humain, mais l’est par un ordinateur (plus précisément un algorithme de machine learning).

Graph native learning

Les méthodes présentées ci-dessus consistent à “faire rentrer un rond dans un carré”: on fait en sorte de faire rentrer dans un modèle tabulaire des données graphes qui ne le sont fondamentalement pas. Ceci permet de profiter de l’arsenal extrêmement bien développé et mature qu’est le machine learning, au détriment de la richesse du modèle graphe. 

Mais il existe depuis peu (dans Neo4J, depuis les premières versions de la librairie GDS, en 2020 ; mais la littérature est bien plus ancienne) des méthodes de machine learning spécifiquement dédiées aux graphes, qui ne nécessitent pas cette transformation tabulaire. 

La principale méthode est celle de la prédiction de lien (link prediction) : elle consiste à estimer si des relations ne sont pas manquantes dans le graphe. Par exemple, dans un graphe qui établit des interactions connues entre des molécules (médicaments, polluants…), on pourra suggérer d’étudier des interactions non-identifiées. Idem pour des interactions entre des clients et des produits (achetés, aimés, consultés…), qui permettra de faire des recommandations pertinentes aux clients.

Conclusions

Dans un rapport récent, Gartner estime que d’ici 2025, les technologies de graphe seront utilisées dans 80% des innovations en analytique, pour seulement 10% en 2021. Il y a donc un énorme potentiel de progression pour les technologies de graphe, et il est clair que le machine learning occupera une place considérable dans cette (r)évolution. Mais il ne sert à rien de mettre la charrue avant les bœufs : une transition vers le “Graph Machine Learning” ne peut pas être réussie si l’on ne maîtrise ni les technologies graphes (et les bases de données orientées graphe) ni le machine learning. Et pour beaucoup d’entreprises ou d’administrations, il reste un travail considérable pour prendre ce train en marche. Mais il n’est pas trop tard!

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.

Les bases de données (orientées) graphes sont très souples, et d’un point de vue modélisation, sont capables de modéliser facilement tout ce qui peut l’être avec une RDBMS (bases de données relationnelles, telles que Oracle, Postgresql ou MySQL). La réciproque n’est pas forcément vraie, en tout cas pour l’aspect “facilement”. La tentation peut dès lors être grande, pour des développeurs qui aiment la nouveauté, de vouloir tout faire dans un modèle graphe. C’est loin d’être toujours la meilleure solution et il conviendra, avant de se lancer dans un changement de paradigme, de se poser les bonnes questions. Nous allons au travers des 7 sections suivantes, essayer de contribuer modestement à cette réflexion.

Notons tout d’abord que, comme mentionné dans notre article précédent, la question n’est souvent pas de choisir un RDBMS ou une Graph DB, mais plutôt de voir comment ces deux modèles peuvent se compléter, et quel sera le champ d’application de ceux-ci.

Il s’agit ici de quelques pistes de réflexion ; les différents aspects ici ne sont ni exclusifs, ni exhaustifs, et l’ordre n’est pas pertinent.

1. Relations au centre de tout

La condition de base pour pouvoir utiliser une Graph DB, c’est que les données puissent être séparées clairement entre nœuds (ou entités) et relations (ou lien) entre ceux-ci. Chaque donnée sera soit un attribut d’un nœud, soit un attribut d’une relation (soit un type de nœud ou de relation). Mais ceci est également vrai pour un modèle relationnel, puisqu’une des premières étapes de l’analyse classique consiste à décrire le schéma “entité-relation”.

Dans un modèle graphe, on s’attendra à ce que les relations aient un rôle au moins aussi important que les entités, si pas plus. Et qu’elles aient un sens fondamental, par rapport au business, et pas uniquement parce que la relation est nécessaire d’un point de vue technique, pour permettre l’implémentation du modèle.

Prenons pour exemple un cas où l’on doit implémenter un annuaire de personnes, où chaque personne peut avoir plusieurs numéros de téléphone (et supposons qu’un même numéro ne peut pas être attribué à plusieurs personnes). Dans un modèle relationnel, on parlerait d’une relation “one-to-many”. Il serait assez artificiel de considérer que les personnes et les numéros de téléphone sont des entités, entre lesquelles on établit une relation. Cette relation n’aurait pas réellement de sens “business”. Le focus ici n’est pas sur la relation, mais plutôt sur l’information, multi-valuée dans ce cas-ci. Un modèle RDBMS à deux tables (People et PhoneNumbers) fera très bien l’affaire.

Par contre, un service de police ou de renseignement qui veut suivre des téléphones pourrait clairement considérer les téléphones et les personnes comme des entités, car les relations auront ici un rôle fondamental : quel téléphone appelle quel téléphone (relation), quand et combien de temps (attribut de la relation), qui possède quel téléphone (relation) à quel moment (attribut de la relation).

2. Beaucoup de relations “many-to-many”

Une particularité d’une relation “many-to-many” dans un modèle RDBMS est qu’elle implique une complexité d’implémentation importante.

Reprenons l’exemple de notre blog précédent, illustré ci-contre, où l’on modélisait la relation entre des travailleurs et leurs employeurs. Une implémentation dans un modèle RDBMS requiert deux tables représentant les entités (“Workers” et “Companies”), une table représentant la relation (“Works_for”), et la gestion fastidieuse d’une série de clés primaires et étrangères à utiliser dans chaque requête.

Une relation dans une Graph DB est représentée beaucoup plus naturellement, sans gestion de clés “artificielles” ou de tables techniques intermédiaires.

Au plus le nombre de relations “many-to-many” est important dans le modèle de données, au plus grand est le bénéfice de l’utilisation d’une Graph DB.

3. Beaucoup de “joins” entre des grandes tables

Outre le fait que l’utilisation des “join tables” ajoute une grande complexité, tant en lisibilité du modèle qu’en lisibilité des requêtes, chaque “JOIN” dans une requête SQL nécessite de parcourir une des deux tables de la jointure. Ce parcours, dans le meilleur des cas (si la clé de jointure est indexée), nécessitera un temps logarithmique par rapport à la taille de la table.

Ce n’est pas un problème si la table parcourue est petite. Il peut par exemple s’agir d’une table de traduction, qui convertit un code en un label (code pays > pays, code département > nom de département…). C’est nettement plus problématique si l’on veut connaître tous les produits achetés par un client particulier : il faudra sans doute d’abord parcourir toutes les commandes pour trouver celles du client, puis tous les produits, sans compter la “join table” que l’on aura entre les commandes et les clients. Cette opération, pourtant toute simple du point de vue business, nécessite une requête SQL aussi complexe que la suivante :

SELECT p.name
FROM product AS p
JOIN prod_2_com AS pc ON pc.prod_id = p.id
JOIN command AS c ON pc.com_id = c.id
JOIN user AS u ON c.user_id = u.id
WHERE u.name = "Smith" 

Dans un modèle Graph DB, on aura au niveau du nœud “Client”, directement accès à la liste des commandes, qui, elles-mêmes, donneront un accès à la liste des produits concernés. Le temps de parcours dépendra donc uniquement du nombre de commandes du client concerné (et pas de l’ensemble global des commandes), et, pour chaque commande, du nombre de produits associés. La requête Cypher, langage de Neo4J, réalise la même opération que la requête SQL ci-dessus, avec une complexité largement inférieure, et une performance incomparablement meilleure, à tout le moins pour des grosses bases de données :

MATCH (u:USER {name:"Smith"})--(:COMMAND)--(p:PRODUCT)
RETURN p.name

Si, dans la représentation du modèle pour une RDBMS, on se rend compte qu’il y a un grand nombre de “JOIN” entre des grandes tables, il sera pertinent d’étudier la possibilité d’une Graph DB.

4. Recherches locales

L’exemple donné dans la section précédente illustre très bien aussi le point suivant. Ce qui nous a intéressé, c’était, partant d’une entité clairement identifiée (le client “Smith” comme “starting point”), d’explorer son environnement immédiat (ses commandes, puis ses produits). C’est une situation où les Graph DB excellent.

Dans une situation qui nécessite de parcourir l’intégralité de certains attributs pour en agréger un résultat (calculer le montant moyen d’une commande, ou les clients les plus fidèles ayant dépensé le plus d’argent), une Graph DB a par contre très peu de chances de concurrencer une DB relationnelle.

5. Recherches de “patterns”

La recherche de “patterns” ne part typiquement pas d’un point connu, mais recherche toutes les occurrences d’une forme particulière de séquences de relations.

Continuons notre exemple ci-dessus, et supposons que l’entreprise vende des produits, mais également des parties de ceux-ci (des rasoirs et des lames de rasoir, des machines et des pièces de rechange…), et qu’une relation “PART_OF” soit présente dans les données. Il sera, avec une Graph DB comme Neo4J, facile de recherche l’ensemble des clients “prudents”, qui ont acheté un appareil ainsi que ses pièces de rechanges, dans la même commande ou non :

MATCH 
   (u:USER)--(:COMMAND)--(p1:PRODUCT),
   (u)--(:COMMAND)--(p2:PRODUCT),
   (p1)-[:PART_OF])-(p2)
RETURN u.name, p1.name, p2.name

La même requête en SQL aurait été d’une complexité sans nom, tant en terme d’écriture qu’en terme de vélocité d’exécution.

6. Besoin de flexibilité

Une base de données comme Neo4j apporte beaucoup de flexibilité à deux niveaux :

• Elle est “schema-less”, ce qui signifie que :
  1. Les attributs ne sont pas figés. C’est à la création d’un nœud qu’on détermine ses attributs, il n’est pas nécessaire que ceux-ci aient été figés à l’avance, ni qu’ils soient les mêmes que dans les autres nœuds du même type.
  2. Le type de nœud ne l’est pas non plus. S’il existe un nœud “Worker” à la création de l’application, on peut décider par la suite de rajouter un label “Manager”, simplement en rajoutant ce label sur des nœuds existant ou en créant de nouveaux nœuds avec ce label.
• Les extrémités d’une relation ne sont pas figées. Une relation “DEPENDS_ON” peut à la fois relier deux nœuds “People” ou deux nœuds “Package”.

Cette flexibilité peut être un grand atout, car elle permet de faire évoluer le modèle de données, sans avoir de conséquence sur ce qui tourne déjà. Mais elle peut être aussi vue comme une faiblesse : il sera facile de créer accidentellement un nœud avec un attribut “name”, et un autre avec un attribut “Name”, qui risque de passer alors sous le radar de requêtes basées sur “name”. Ou de créer une relation entre deux nœuds pour lesquels cette relation n’a pas de sens (PART_OF entre deux clients, par exemple). La responsabilité de la cohérence se reposera alors sur la couche applicative.

Notons que les Graph DB ne sont pas les seules à offrir beaucoup de flexibilité ; c’est également en général le cas de bases de données “Key-value” (Redis…), ou des Document stores (MongoDB…)

7. Requêtes orientées “chemins”

Supposons qu’un employé A d’une entreprise doivent transmettre une information stratégique à un employé B, et qu’il doive du coup absolument passer par la ligne hiérarchique : il faut donc identifier “N+x” de A qui serait le “N+y” de B, où “x” et “y” ne sont pas connus. Ou imaginons que l’on gère les dépendances entre l’ensemble des modules produits par une entreprise de développement, et que l’on ait besoin d’identifier tous les modules qui seront impactés, directement ou indirectement, par la mise à jour prévue d’un module. Ou encore une chaîne de production, qui doit connaître le “chemin critique” de production d’un objet, ou encore l’ensemble des produits dont la production serait mise à l’arrêt par l’entretien d’une machine de la chaîne.

Ce type de situation nécessite l’identification d’un chemin, c’est-à-dire une succession de relations, dont on ne connaît souvent pas à l’avance le nombre. En SQL, il faudrait donc une requête pour laquelle le nombre de “JOIN” n’est pas fixé. À notre connaissance, il n’existe pas de solution standard à ce problème (le “CONNECT BY” de Oracle et le “RECURSIVE” de Postgre ne s’utilisent pas du tout de la même façon).

Dans Neo4j, on pourra très facilement identifier le plus court chemin entre deux nœuds, ou l’ensemble des plus courts chemins, voire même l’ensemble des chemins possibles, en faisant alors attention au risque d’explosions combinatoire. On pourra aussi identifier l’ensemble des chemins entre deux nœuds, ne comportant que des relations d’un type donné, comprenant entre 5 et 10 sauts.

Conclusions

Cette liste n’est bien sûr pas exhaustive, et n’est pas à prendre au pied de la lettre. Les différents éléments seront parfois contradictoires : on peut avoir un modèle avec beaucoup de relations many-to-many, sur lesquelles il sera nécessaire de faire de nombreuses opérations d’agrégation. Il faudra alors mettre en balance différents arguments ; Quelles sont les opérations qui devront être réactives, liées à une interface utilisateur, et quelles sont celles qui se feront “en batch” la nuit, sans nécessité d’interactivité ? Est-il préférable d’avoir une application très performante, ou plutôt basée sur une technologie bien maîtrisée par l’entreprise ? Chacun aura sa propre réponse.

On pourrait encore identifier beaucoup d’autres situations ou une Graph DB offre des avantages ; ou des situations où il ne faut surtout pas s’en servir. Les liens ci-dessous permettront au lecteur de continuer la réflexion.

Il est à notre sens clair que, bien que les Graph DB ne soient pas adaptées ou optimales dans toutes les situations, elles ont de solides avantages dans de nombreuses circonstances, y compris dans d’innombrables applications ou le choix d’une RDBMS a été fait, soit par ignorance d’alternatives, soit par peur face à un changement de paradigme.

Inspirations

• https://medium.com/neo4j/how-do-you-know-if-a-graph-database-solves-the-problem-a7da10393f5
• https://linkurio.us/blog/unlocking-value-connected-data/
• https://www.infoworld.com/article/3251829/nosql/why-you-should-use-a-graph-database.html
• http://radar.oreilly.com/2013/07/why-choose-a-graph-database.html

Dans le second article, nous avons vu que le graphe pouvait être découpé en sous-graphes, soit en considérant les composantes connexes, soit en y calculant des communautés.

Dans ce troisième et dernier article, nous allons nous intéresser dans un premier temps à la notion d’homophilie, pour ensuite parler du concept de projection d’un graphe (biparti).

Homophilie

En sociologie, le terme “homophilie” (déjà exploité dans un blog précédent) désigne le fait pour une personne d’avoir plus d’affinité avec les personnes similaires à elle-même (“qui se ressemble s’assemble”). Par extension, en théorie des réseaux, on dira qu’un réseau est homophile si, dans le voisinage immédiat d’un nœud, on aura tendance à trouver des nœuds similaires à ce nœud. La notion de similarité peut vouloir dire beaucoup de choses : pour des personnes, partager des centres d’intérêts, une ethnie, un niveau de formation ou socio-économique, une religion… pour des entreprises, être actif dans le même secteur, dans la même région, voire même être également enclins à frauder.

Nous allons ici voir dans quelle mesure le marché du travail belge est “homophile”, et cela selon deux caractéristiques : la province de l’employeur, et ses codes NACE. Nous nous poserons donc la question suivante : un travailleur employé par une société située en province X (ou exerçant dans le domaine X) va-t-il, s’il change d’employeur, favoriser une entreprise de la même province (ou du même domaine) ?

Homophilie par province

Aperçu général

En premier lieu, nous allons évaluer, pour chaque province, la proportion de travailleurs qui travaillent dans cette province, puis changent de travail pour un employeur dans une autre province. Le nombre obtenu pourrait ainsi être interprété comme une mesure de la “fidélisation” d’une province.

Il nous faut donc calculer deux valeurs pour chaque province :

• Le nombre de personnes qui, sur la période étudiée, y ont eu un emploi
• Le nombre de personnes qui, après un emploi dans cette province, ont trouvé un emploi dans une autre.

Requêtes Cypher

MATCH (c:Company)--(p:People)
RETURN c.Province, COUNT(DISTINCT p)

MATCH (c1:Company)-[r1]-(w:People)-[r2]-(c2:Company) 
WHERE 
   c1 <> c2 
   AND r1.START <= r2.START 
   AND coalesce(c1.Province, "null") <> c2.Province
RETURN c1.Province, COUNT(DISTINCT p)

Combinées, ces données nous permettent d’obtenir le graphique suivant :

Notons que la colonne “Bruxelles” est particulière : c’est dans la capitale que la plupart des entreprises actives sur tout le territoire (ministères, chaînes de magasins…) ont leur siège social. Le fait que son employeur soit renseigné à Bruxelles ne veut donc pas dire que l’on travaille dans cette ville.

Le graphique nous indique que 63% des personnes ayant travaillé dans le Brabant Flamand ont ensuite trouvé un emploi ailleurs, alors que seuls 46 % des travailleurs liégeois ont quitté leur province. En termes d’homophilie, on peut donc estimer que Liège est plus “homophile” que le Brabant Flamand : dans le “voisinage” de Liège (les autres employeurs des travailleurs d’employeurs liégeois), on trouve une plus grande proportion d’entreprises Liégeoises qu’on ne trouve d’entreprises (flamo-)brabançonnes dans le voisinage du Brabant Flamand.

Notons que ce constat ne dit rien des raisons : les liégeois ne sont pas nécessairement “pantouflards”, il se peut que les conditions de travail y soient si bonnes que rares sont ceux qui veulent aller voir ailleurs.

Aperçu détaillé

Si l’on veut une vue plus détaillée de cette notion d’homophilie provinciale, on peut aussi comparer, pour chaque province P, les deux répartitions suivantes :

• La répartition du voisinage de P, c’est-à-dire les provinces où travaillent tous les travailleurs qui ont d’abord travaillé pour une entreprise situé en province P
• La répartition générale des travailleurs par province.

Pour la répartition générale, nous allons calculer le nombre de personnes ayant eu, au cours de ce 15 dernières années, un emploi dans chaque province.

Comme nous souhaitons obtenir une distribution, la somme de toutes nos colonnes doit être égale à 1 (ou 100%). Nous divisons donc chaque colonne par la somme de toutes les colonnes. Cette valeur est supérieure à la population totale, car chaque travailleur ayant travaillé dans deux provinces sera compté 2 fois. Ce qui compte, ce n’est pas la hauteur absolue d’une colonne, mais sa hauteur par rapport aux autres colonnes.

Nous obtenons le graphique ci-contre.

Requêtes Cypher

MATCH (c:Company)--(p:People)
RETURN c.Province, COUNT(DISTINCT p)

Nous calculons ensuite, pour chaque province P, le nombre de personnes qui, après un emploi dans cette province P, ont eu un autre emploi dans cette même province, ce qui nous donne la série de graphiques ci-dessous.

Requête Cypher

MATCH (c1:Company)-[r1]-(p:People)-[r2]-(c2:Company) 
WHERE c1 <> c2 AND r1.START <= r2.START
RETURN c1.Province, c2.Province, COUNT(DISTINCT p)

Notons qu’il est difficile de comparer la vue générale que nous avons montrée ci-dessus avec cette série de graphiques, pour plusieurs raisons :

• La série de graphiques montre comment se sont comportés ceux qui ont changé de travail. On ne compte donc pas ceux qui n’ont jamais changé d’employeurs, ce qui représente un peu plus de 42 % des travailleurs, comme mentionné dans notre premier blog .
• Un travailleur qui a d’abord travaillé à Bruxelles, pour ensuite partir à Namur et puis à Mons, en Hainaut, sera repris à la fois dans les transferts Bruxelles-Namur, mais également Bruxelles-Hainaut. On ne peut donc pas sommer les migrations entre une province et les autres pour connaitre le nombre de personnes ayant quitté la province.
• Si la hauteur absolue d’une colonne dans le graphique général a un sens (proportion de travailleurs ayant quitté la province), elle n’en a pas vraiment la série de graphiques qui suit.

Quelques observations peuvent être faites :

• La répartition du voisinage de Bruxelles diffère peu de la répartition globale des travailleurs : cela s’explique très probablement par ce qui a déjà été évoqué, la plupart des grandes structures ayant leur siège social à Bruxelles
• En dehors de Bruxelles, le voisinage d’une province reste majoritairement dans la même région (Flandre ou Wallonie)

Homophilie par secteur (Code NACE)

Nous avons réalisé une analyse similaire sur base des Code NACE (décrits dans notre premier article), précisant le secteur d’activité, à nouveau en excluant les contrats d’intérim. Nous nous posons la question suivante : le “voisinage d’un secteur” (à savoir les entreprises dans lesquelles travaillent les travailleurs d’entreprises du dit secteur) est-il différenciable de l’ensemble de la population des entreprises ?

Nous présentons pour ce faire les graphiques accessibles dans ce document joint.

Pour chaque page, correspondant à un code NACE (de premier niveau), on trouve sur la première ligne la comparaison entre la distribution des codes NACE des entreprises en général (en bleu) et la distribution des entreprises employant au moins un travailleur ayant été embauché par une entreprise du code NACE concerné. À gauche, la comparaison se fait sur base du nombre d’entreprises. À droite, sur base du nombre de travailleurs. En titre, le coefficient de correlation (selon la méthode de Pearson) indique à quel point le voisinage du secteur analysé diffère de la distribution globale. Proche de 1, il sera quasiment indifférenciable, plus on s’en éloigne, plus spécifique sera le voisinage du secteur analysé.

Les graphiques du bas, indiquent, pour chaque code NACE, le ratio entre les deux colonnes du graphique du haut. Il s’agit d’une autre façon de voir les secteurs surreprésentés (au dessus de la ligne pointillée rouge) et sous-représentés (en dessous de la ligne).

Nous constatons que pour quasiment tous les secteurs, ce même secteur est sur-représenté dans le voisinage, montrant que le phénomène d’homophilie est observé. La sur-représentation présente cependant des grandes variations : à peine perceptible pour le commerce (code G), très importante pour des secteurs très spécialisés (et concernant très peu de monde), comme les activités extra-territoriales (code U) ou l’extraction (code B).

Nous laissons au lecteur le choix d’aller plus loin dans l’analyse, en identifiant par exemple des secteurs “associés” (souvent sur-représentés ensemble).

Projection biparti

Lorsque l’on a un graphe biparti, c’est-à-dire un graphe avec deux types de nœuds A et B (comme par exemple travailleur et employeur) et des arcs qui vont uniquement entre un nœud du type A et un nœud du type B (comme par exemple les relations de travail), on peut réaliser ce qu’on appelle une projection biparti. Il s’agit d’un graphe qui ne comportera que des nœuds d’un type A (resp. B), et qui aura un arc entre deux nœuds x₁ et x₂ s’il existe dans le graphe d’origine un nœud du type B (resp. A), lié à x₁ et à x₂. Il existe toujours deux projections d’un graphe biparti : une pour chaque type de nœud. Dans le cas qui nous occupe, nous aurons un graphe reprenant la totalité des employeurs, et un lien entre deux employeurs s’il existe une personne ayant travaillé pour les deux employeurs, et un graphe reprenant la totalité des travailleurs, avec un lien entre deux travailleurs s’ils ont un jour été collègue (en supposant deux personnes collègues si elles ont travaillé pour un même employeur, mais pas nécessairement en même temps).

Les arcs créés dans la projection biparti sont souvent associée à un poids, qui peut par exemple avoir pour valeur le nombre de nœuds “compressés” dans la projection : il peut s’agit du nombre de travailleurs partagés dans le cas de la projection sur les employeurs, ou du nombre d’entreprises dans lequel les deux extrémités de la relation ont été collègues.

Pour l’analyse qui suit, nous n’avons pas considéré les travailleurs intérimaires, qui, par nature, changent souvent d’employeurs, et pourraient fausser les impressions. Nous n’avons par ailleurs considéré que la composante géante (voir notre article précédent). Par définition, il n’y aura pas de travailleurs en commun entre deux entreprises faisant partie de deux composantes connexes distinctes.

Nous n’avons pas pu réaliser l’analyse qui suit dans la base de donnée Neo4j, n’ayant trouvé aucune fonctionnalité permettant de réaliser les projections voulues. Nous avons utilisé la librairie igraph.

Projection par entreprise

La première projection que nous avons réalisée est la projection par entreprise. Elle comporte un peu plus de 530 000 employeurs, et 22 millions de liens. En regardant le poids de ces liens (indiquant dont le nombre de travailleurs partagés), on en trouve 18.6 millions ayant la valeur 1. Il y a donc 18.6 millions de couples d’employeurs ne partageant qu’un seul travailleur. Les valeurs les plus intéressantes se trouvent à l’autre extrémité : il existe deux employeurs se partageant 37 350 travailleurs ! Nous y trouvons ensuite un triplet d’employeurs qui se partagent deux par deux, respectivement, 11 000, 10 000 et 7 000 travailleurs.

Le premier est le fait d’une société nationale, qui a une structure juridique séparée pour la gestion de ses ressources humaines. Chaque travailleur y est déclaré dans les deux structures. Le second concerne un organisme de gestion d’artistes, divisé en plusieurs structures juridiques distinctes. On trouve aussi un chaîne de grands magasins de près de 140 000 salariés (dont un très grand nombre de jobistes), partageant 5 800 travailleurs avec un ministère de 250 000 salariés. Il n’est bien sûr pas surprenant que deux aussi gros employeurs partagent autant de personnel. L’essentiel de ce que l’on voit par la suite est du même acabit : de très gros employeurs, liés entre eux par un nombre de salariés qui est dans l’absolu élevé, mais pas relativement au nombre d’employés respectif. Une analyse plus approfondie, où l’on placerait en poids la proportion de personnel partagé (par exemple, avec la distance de Jaccard) apporterait un autre éclairage. On pourrait par exemple détecter des transferts d’entreprises, des rachats ou des fusions. Nous n’irons pas plus loin ici dans cette analyse.

Projection par travailleur

La projection par travailleur pose un problème de taille : elle est très largement plus volumineuse que celle par entreprise. Nous sommes parvenus à déterminer qu’elle devait comporter un peu plus de 7 millions de nœuds, et pas loin de 400 millions d’arcs, mais, en utilisant la libraire igraph sur un serveur ayant à sa disposition 64 GB de mémoire, nous n’avons pas réussi à la calculer. Cependant, nous voulions principalement mettre en évidence les couples de personnes partageant de nombreux employeurs.

Cliquer ici pour voir comment nous avons malgré tout pu contourner cette limitation

Dès lors, nous pouvions d’entrée de jeu éliminer de nos données tous les employeurs ayant moins de deux travailleurs. En effet, un employeur avec un seul travailleur ne pourra par définition pas être un employeur commun entre deux personnes. Cette simplification n’aura aucun impact sur la projection, ces employeurs supprimés n’étant jamais considérés comme “en commun” entre deux travailleurs, et donc n’apparaissent dans aucun poids.

Dans le même ordre d’idée, si nous voulons trouver tous les couples de travailleurs partageant au moins, mettons, 10 employeurs, nous pouvons également éliminer tous les travailleurs ayant moins de 10 employeurs (pour avoir 10 employeurs en commun avec un autre travailleur, il faut avoir soi-même au moins 10 employeurs). Cette dernière simplification supprimera des nœuds dans la projection résultante, mais uniquement des nœuds qui, dans la projection, ne seront liés à aucun nœud avec un poids supérieur ou égale au seuil fixé (10 dans notre exemple). L’illustration ci-dessous montre un graphe biparti (vert et orange), pour lequel on veut réaliser la projection “verte”, avec un seuil fixé à 4.

Avec la première simplification, le nœud orange “i” (degré = 1, inférieur à 2) est supprimé. Avec la seconde simplification, le nœud vert “3” (degré = 3, inférieur au seuil 4) est supprimé lui aussi. Les deux projections (complète et simplifiée) sont ensuite montrées sur la droite. On y voit qu’en dehors de la suppression du nœud 3, les poids sur les arcs sont identiques.

Le résultat de cette projection nous montre que bon nombre de travailleurs partagent un grand nombre d’employeur avec d’autre salariés. Par exemple, 32 couples de travailleurs (au total, 24 travailleurs), partagent deux par deux plus de 30 employeurs (jusqu’à 46), comme illustré ci-dessous, où chaque nœud représente un travailleur, et les labels sur les arcs le nombre d’employeurs commun entre deux travailleurs.

Une analyse plus approfondie ce ces différents clusters mets en avant certains secteurs : le cluster de gauche concerne des employés embauchés essentiellement en tant que travailleurs occasionnels dans le secteur de la collecte de fruits et légumes ; celui du milieu des entreprises des arts du spectacles. Il s’agit de deux secteurs pour lesquels on change fréquemment d’employeur entre chaque “prestation” (une saison de collecte ou une tournée de spectacle).

Pour chacune des relations affichées sur le réseau ci-dessus, nous avons également calculé la distance de Jaccard, qui indique le ratio entre le nombre de voisins communs entre deux nœuds, et le nombre total de voisins de ces deux nœuds. Il se situe à chaque fois entre 25 et 45 %. Ceci indique que nous ne sommes donc pas dans une situation similaire à celle évoquée ci-dessus (pour la projection par employeur), ou deux “super-employeurs” avaient toutes les chances de partager quelques salariés, mais bien dans des situations ou deux travailleurs partagent une partie importante de leurs employeurs. Il y a donc fort à parier que, dans beaucoup de cas, il s’agisse de personnes qui cherchent du travail ensemble. Ceci pourrait être corroboré en menant une analyse plus fine, et en ne considérant qu’un employeur n’est commun entre deux travailleurs que si les périodes d’engagement coïncident. Nous avons mené cette observation manuellement pour les relations les plus fortes, et observé que c’était le cas dans la majorité des relations de travail.

Conclusions

Cette série d’articles a mis en lumière la puissance que l’analyse réseau, en combinaison avec une base de données orientée graphes, pouvait offrir. La gamme de résultats est très large : on peut à la fois obtenir des métriques offrant une vue très générale (le nombre de travailleurs à un moment donné, le nombre moyen d’employeurs par travailleur…), mais également isoler facilement des comportements qui sortent du lot (travailleurs changeant anormalement souvent d’employeur, employeurs ayant du personnel extrêmement fidèle…). L’analyse réseau est donc à la fois un excellent complément de l’analyse statistique classique, mais est également un outil de très grande valeur pour détecter la fraude ou les erreurs et autres problèmes de qualité dans les données.

Il va de soi que, en combinaison avec des experts soit du marché de l’emploi, soit en statistiques, de nombreuses autres observations pourraient être faites. Certaines de celles-ci pourraient également être obtenues avec des techniques statistiques classiques, mais beaucoup nécessiteraient un travail démesuré, voire même seraient tout simplement impossibles.

Nous allons maintenant examiner deux façons de découper le réseau en plusieurs “sous-réseau” : dans un premier temps une découpe par “composante connexe”, ensuite par détection de communauté.

Rappelons que nous considérons un graphe (ou réseau) selon le modèle présenté ci-contre : nous avons deux types de nœuds (travailleurs et employeurs) ; la relation entre un travailleur et un employeur indique les dates de début et fin (si applicable) de contrat, ainsi qu’un “worker code”, décrivant une série de catégories présentées dans l’article précédent.

1. Composante connexe

En partant d’un travailleur donné, on peut, en parcourant le graphe, trouver tous ses collègues, actuels ou anciens, via le lien “travailleur→employeur”, puis “employeur→travailleur”. Si, à partir de ces collègues, on re-parcourt le graphe de la même façon, on obtiendra les “collègues de collègues” du travailleur de départ. En continuant de la sorte tant que l’on tombe sur des travailleurs que l’on n’a pas encore rencontrés, on parcourt ainsi une “composante connexe“, soit un ensemble (maximal) de nœuds pour lequel il existe un chemin entre chaque paire de nœuds. Tous les nœuds d’un graphe ne font pas nécessairement partie de la même composante connexe : si deux travailleurs font partie de deux composantes connexes distinctes, il n’existe pas de chemin “(ex-)collègue de (ex-)collègue de (ex-)collègue …” entre ces deux travailleurs.

Le graphe ci-contre illustre un réseau composé de trois composantes connexes : une en haut à gauche, composée de 4 nœuds ; une seconde en bas à droite, de 5 nœuds ; une dernière, plus importante, entre les deux.

Composante géante

On appellera “composante géante” la plus grande composante connexe d’un graphe. Si on effectue ce calcul sur notre graphe de Dimona, on obtiendra une composante effectivement géante : elle est composée de 8 149 146 de nœuds, dont 581 065 entreprises et  7 568 081 travailleurs.

En d’autres mots, si l’on considère toutes les relations de travail de ces 15 dernières années, 99.5% des travailleurs ayant été actifs sur cette période sont “(ex-)collègue de (ex-)collègue de (ex-)collègue …” entre eux, via 95 % des entreprises. Ceci en considérant que deux personnes sont collègues si elles ont eu le même employeur, simultanément ou non. Le monde du travail (belge) peut donc être vu comme un “petit monde”, théorisé par Milgram dans son paradoxe éponyme.

Diamètre

En analysant de plus près cette composante géante, on voit que son diamètre, soit le nombre de relations du plus long “plus court chemin” entre deux nœuds, est de 20. Ce qui veut dire que, pour 99.5% des travailleurs actifs sur la période, il n’est jamais nécessaire de passer par plus de 9 (ex-)collègues intermédiaires pour “connecter” deux travailleurs.

En moyenne, il faut 1.5 collègues intermédiaires pour chaque paire de travailleurs (longueur moyenne du plus court chemin entre deux nœuds : 5), et dans 99 % des cas, 3 travailleurs intermédiaires sont suffisants (percentile 0.99 = 8, comme entre A et E, dans la figure ci-dessus).

Si l’on prend deux travailleurs (faisant partie de la composantes géantes, soit pour l’essentiel n’étant pas le seul salarié d’une entreprise) au hasard, il y a 59% de chances qu’ils aient un collègue en commun, en prenant la définition large de collègue, voulant dire “ayant eu un employeur en commun, mais pas nécessairement en même temps”.

Notons qu’une partie de ce qui explique ce “petit monde” est ce qu’on appelle les “super-connecteurs” : il s’agit de nœuds ayant un degré très élevé. Tous les enseignants (du même régime linguistique) sont par exemple employés par le même ministère.

Notons également que même si l’on s’intéresse à une période plus petite, la composante géante reste importante : si l’on ne considère que les relations de travail entre 2013 et 2017, la composante fera alors 6 253 490 nœuds, dont 5 907 213 travailleurs, soit 99% des 5 966 745 travailleurs actifs sur cette période-là. On descend à 96% en ne regardant que les relations de travail en 2017.

Requêtes Cypher

Autres composantes connexes

Le réseau complet de Dimona, sur base des relations de 2003 à 2017, est composé de 28 224 composantes connexes. Nous venons de voir que la très grande majorité des nœuds font partie de la même composante connexe.

À l’autre extrémité, nous avons un grand nombre de composantes connexes toutes petites : 22 013 d’entre elles sont composées de deux nœuds, donc un travailleur et un employeur. Ce qui veut donc dire que l’on a 22 013 travailleurs qui n’ont eu qu’un seul employeur durant les 15 ans de notre analyse, et dont ils ont été l’unique employé. On peut imaginer que pour beaucoup d’entre eux, il s’agit de personnes qui, au lieu de choisir un statut d’indépendant, ont préféré créer leur propre société pour s’y engager. Ceci pourrait être confirmé en croisant ces données avec celles de la Banque Carrefour des Entreprises, organisme officiel auprès duquel doivent s’inscrire toutes les entreprises (y compris ceux qui ne sont pas des employeurs, comme les indépendants, les professions libérales…), et y préciser le noms des fondateurs, gérants ou administrateurs.

On trouve également 4 300 partitions de taille 3 (deux employeurs et un travailleur, ou un employeur et deux travailleurs) et un peu plus de 1 100 partitions de taille 4.

Restent ensuite un peu moins de 800 partitions de taille variant entre 5 et 61.

Nous pouvons identifier quelques “patterns” :

• “Schéma en étoile” : un seul travailleur, et de 3 (121 fois) à 6 (3 fois) sociétés. Notons que l’on trouve aussi ce schéma dans la composante connexe géante : nous avons ainsi 25 travailleurs ayant été le seul travailleur de plus de 10 entreprises sur les 15 dernières années (mais ces travailleurs ont été également engagés par d’autres employeurs).
  Requête Cypher
  MATCH (n1:Company)--(p:People)
WHERE size((n1)--()) = 1
WITH p, COUNT(DISTINCT n1) as nb_comp WHERE nb_comp >= 10
RETURN p, nb_comp
ORDER BY nb_comp DESC
LIMIT 100
  
  Nous voyons principalement deux explications à ces étoiles :
  • “Faux indépendants” : schéma similaire à celui décrit plus haut, si ce n’est que la personne a ici choisi de créer plusieurs sociétés, sans jamais engager d’autre personnes qu’elle-même (et sans jamais, sur la période considérée, avoir travaillé pour un autre employeur).
  • “Salarié partagé” : l’observation d’un certain nombre de ces cas montre également des groupes d’entreprises dont l’essentiel de l’activité est basée sur des personnes non-salariées et qui se partagent un salarié pour accomplir des tâches administratives. On trouve ainsi beaucoup de fabriques d’églises, ou des syndics de copropriétés, mais également des sociétés créées par des indépendants, non par pour s’y engager eux-mêmes, mais pour y engager une personne à temps partiel.

• “Entreprise étrangère temporaire” : Une série importante de “clusters” nous faisant penser à un groupe de travailleurs étrangers, venus en Belgique pour créer une société, puis repartir peu de temps après. Le fait qu’il s’agisse de travailleurs “temporaires” explique qu’ils n’aient pas d’autres relations dans Dimona, leur historique de travail s’étant déroulé à l’étranger. Quelques éléments en attestent. On trouve :
  • Des schémas avec essentiellement des travailleurs étrangers : plus de 2000 clusters sans aucun travailleur ayant la nationalité belge,
  • 620 clusters avec aucun travailleur ayant un numéro NISS, mais uniquement un numéro BIS. Il s’agit donc de travailleurs temporaires. (cf explications dans notre premier article)
  • 224 clusters où il s’est écoulé moins d’un an entre le premier engagement et la fin du dernier contrat. Pour 320 cas, il y a eu moins de deux ans.
• “Travailleurs très fidèles” : Une quarantaine de cas d’entreprises avec entre 5 et 9 travailleurs, presque tous avec un numéro NISS. Nous sommes donc dans le cas d’entreprise avec un personnel très fidèle : sur 15 ans, aucun des travailleurs n’a eu d’autre employeur que celui-là.

Fidélité

Une partie des composantes connexes nous donnent des exemples d’entreprises avec un personnel très fidèle. Une autre façon de le calculer est de recherche des entreprises où il y a une longue période durant lequel tout le personnel qui a un jour été présent a travaillé simultanément. Autrement dit, entre l’engagement le plus tardif et le premier départ, il s’est écoulé une longue période.

On trouve par exemple 103 entreprises d’au moins 5 travailleurs où ce délai est de 10 ans, et 353 entreprises où ce délai est de 5 ans.

Requête Cypher

2. Détection de Communautés

En général, quand on observe un réseau, on constate qu’il n’est pas “uniforme” : il y a des “zones” plus denses, avec beaucoup de connexions entre les nœuds de ces zones, et il y a moins de connexions entre deux nœuds faisant partie de “zones” distinctes. Dans la terminologie de la théorie des graphes, on parle de “communautés”. Typiquement, si on regarde le réseau constitué de l’ensemble des connaissances d’une personne, où un lien entre deux personnes indiquent qu’elles se connaissent, on observera en général une série de communautés, correspondant à des groupes de la vie réelle par rapport à la personne dont on analyse le réseau : les membres de famille, les collègues, les camarades de classe … Plus de détails peuvent être trouvés dans ce blog.

Nous avons appliqué un algorithme de détection de communautés (méthode par propagation de labels) sur notre graphe, et avons regardé dans quelle mesure on pouvait caractériser les différentes communautés. Pour ce faire, nous avons examiné deux caractéristiques de chaque entreprise (la province de son siège social et son ou ses code(s) NACE), pour comparer la distribution de ces données au sein d’une communauté par rapport à la distribution pour l’ensemble de la population.

Nous constatons que la plupart des communautés détectées par l’algorithme ont un “comportement” assez éloigné de la moyenne nationale. Ce qui veut dire que les travailleurs, lorsqu’ils changent de travail, ont tendance à changer soit pour un employeur localisé dans la même province, soit travaillant dans le même secteur. Ce n’est en soi pas une découverte surprenante, mais l’analyse réseau permet de le formaliser.

Les données des 100 plus grosses communautés sont visibles dans ce document. On peut par exemple y voir que la plus grande communauté détectée (54.000 employeurs, 750.000 travailleurs) est composée très largement d’entreprises localisées en Flandre Occidentale. En effet, comme le montre le graphique ci-dessus, alors que 10% des entreprises en Belgique sont localisées dans cette province (colonne bleue), 71% des entreprises de la communauté concernées y sont. Dans le même ordre d’idées, la troisième communauté comprend trois fois plus d’entreprises de l’Horeca (Hotels, restaurants, cafés) que la moyenne nationale.

La 8^ème communauté, représentée ci-dessous, combine deux aspects : les 580 entreprises qui la composent sont quasi exclusivement localisée en Wallonie et à Bruxelles (soit les deux régions de Belgique où l’on parle majoritairement français), et travaillent dans le secteur de l’enseignement.

La suite…

Dans le troisième blog de cette série, nous examinerons deux notions : celle d’homophilie, et celle de projection. La première nous permettra de voir à quel point les travailleurs changent de région de travail ou de domaine d’activité. La seconde permettra de calculer un certaine forme de proximité entre deux travailleurs, au travers du nombre d’employeurs qu’ils ont eu en commun.