Cette contribution se situe dans une série d’articles sur les graphes de connaissances (les « knowledge graphs » en anglais). Nous vous présentons le Smals KG Checklist, un outil qui vous aide à déterminer si un graphe de connaissances serait utile, voire indispensable, pour résoudre un problème dans votre organisation. Le Smals KG Checklist a été présenté au sein du SEMANTiCS 2021, un congrès scientifique et industriel autour des graphes de connaissances.

La différence entre les graphes et les graphes de connaissances

Nous avons déjà traité les graphes de connaissances et les (bases de données) graphes. Mais quelle est la différence entre les deux? Dans les grandes lignes, les bases de données graphes nous permettent de stocker des données représentées en graphe et les graphes de connaissances sont un type de graphe spécifique qu’on stocke dans des bases de données graphes. Autrement dit, tous les graphes de connaissances sont des graphes mais l’inverse n’est pas vrai.

Quelles sont donc les caractéristiques qui séparent les graphes de connaissances des autres graphes? C’est une question qu’on se pose souvent dans l’industrie et la recherche. En 2020, Hogan et al. ont publié un rapport plutôt académique qui traite le sujet des graphes de connaissances. Ils présentent plusieurs définitions de ce concept, ce qui ajoute à la confusion.  Par contre, toutes ces définitions nous permettent de synthétiser les caractéristiques d’un graphe de connaissances. C’est un graphe qui représente des entités (sous forme de nœuds) et leurs relations (sous forme de d’arêtes), et qui adhère à trois conditions :

1. Le graphe intègre des informations de différentes sources hétérogènes : bases de données, documents, connaissances reprises dans les têtes des experts, …
2. Un schéma qui décrit les types et relations utilisés dans le graphe de connaissances. Ce schéma, également nommé ontologie, fait partie du graphe de connaissances.
3. Le graphe est utilisé pour déduire des informations implicites à travers les informations explicites. C’est-à-dire, d’utiliser le graphe de connaissances pour découvrir des nouvelles relations, types, etc. en utilisant des algorithmes ou des applications.

La première condition est évidente. La traduction d’une base de données relationnelle vers une base de données graphe peut être utile pour optimaliser les requêtes, mais le résultat n’est pas un graphe de connaissances ; le résultat non seulement ne combine pas d’autres informations, mais il manque aussi au résultat une description détaillée des concepts et relations et enfin, le résultat n’est utilisé que pour optimaliser un processus existant. Ce sont les deux autres conditions qui sont plus complexes et nuancées.

Le Schéma (ou ontologie) d’un graphe de connaissances

La définition d’un schéma (ontologie) d’un graphe de connaissances est : « une spécification formelle et explicite d’une conceptualisation partagée ». Cette définition semble compliquée, mais il suffit de comprendre chaque partie de cette définition.

Nous prenons par exemple l’ONSS et la Banque-Carrefour des Entreprises (BCE). L’ONSS et la BCE ont des informations sur des entreprises, mais de points de vue différents. Si l’ONSS et la BCE décident de partager des informations sur des entreprises, ils auront besoin d’une ontologie pour éviter des malentendus. La conceptualisation partagée inclut donc le concept « entreprise » et ses relations, définitions, règles, etc. Les représentants des deux parties se mettent d’accord sur cette conceptualisation partagée en discutant et en réutilisant des informations existantes (législations, glossaires, etc.). Cette conceptualisation partagée reste « dans la tête » des représentants, donc il faut mettre ces accords quelque part : on parle alors de la spécification. La spécification contient les descriptions et définitions de la conceptualisation. Mais la spécification doit être explicite, c’est-à-dire enregistrée quelque part (p. ex., un fichier) et cette spécification doit être formelle (logique ou mathématique) pour que des logiciels puissent l’utiliser.

Il existe des normes pour créer ces schémas ; RDFS et OWL sont deux exemples. RDFS nous permet de créer des hiérarchies de concepts et de relations. OWL est beaucoup plus expressif et nous permet de créer des règles pour valider un graphe de connaissances. Les use cases d’une organisation nous informent quelle langue est préférable. Ces langues nous permettent de décrire que :

• Chaque entreprise est un agent ;
• Chaque personne est un agent ;
• Une entité ne peut pas être à la fois une personne et une entreprise (possible avec OWL) ;
• Si une entité a un numéro BCE, cette entité est une entreprise ;
• …

En ajoutant des descriptions en langage naturel, ce schéma rend les données sémantiques pour les logiciels et les utilisateurs. En donnant la requête « donne-moi une liste des agents », un logiciel est capable d’interpréter le schéma et d’inclure les personnes et les entreprises.

Les bases de données graphes comme Neo4j ont souvent une notion de types de nœuds, mais ne soutiennent pas les relations entre ces types, par exemple. La réalisation d’un knowledge graph non seulement nécessite la construction du schéma, mais aussi l’utilisation de ce schéma en utilisant :

• une extension d’une base de données graphe ou d’une application sur cette base de données graphe capable d’interpréter un schéma. Un exemple est le RDF & Semantics Plugin de Neo4j ; ou
• des bases de données graphes conçues pour les graphes de connaissances comme Stardog et Apache Jena.

Le schéma est donc un graphe qu’on ajoute au graphe de données et qui est interprété d’une manière spécifique.

Déduire des informations implicites

La troisième condition est que le graphe de connaissances soit utilisé pour déduire des informations implicites ou « cachées » dans le graphe, en utilisant :

• L’intelligence artificielle symbolique (exploitant le schéma) ;
• L’intelligence artificielle statistique (machine ou deep learning) ;
• Des applications qui « comprennent » les graphes grâce au schéma.

Nous avons déjà évoqué l’IA symbolique dans la section précédente. En effet, le langage de schéma permet aux logiciels de déduire des informations. Si l’entité représentant Christophe est du type Personne, cet entité est aussi du type Agent. Ce genre d’IA utilise des logiques formelles pour arriver à ces déductions. L’usage de l’IA symbolique nécessite un schéma.

L’IA statistique, appliquée au graphes, nous permet de prédire des liens entre des entités ou même de prédire les catégories d’une nouvelle entité. L’usage d’un schéma nous permet de fournir des graphes plus riches, en déduisant un maximum d’informations, à ces algorithmes.

Et puis nous avons les applications « intelligentes » qui « comprennent » les graphes de connaissances. Ces applications exploitent le schéma et/ou le langage de schéma pour faciliter les tâches. Pour la recherche facettée, que nous connaissons tous des ventes en ligne, les types et les valeurs des relations sont interprétées pour créer des critères de recherche. Des outils comme Ontodia, traités dans un product review, nous permettent d’explorer et d’analyser les contenus d’un graphe de connaissances d’une manière visuelle. Ontodia non seulement interprète le schéma pour guider les fouilles, mais l’outil interprète aussi les contenus du graphe pour choisir les visualisations. Ces outils permettent donc aux usagers de découvrir eux-mêmes des nouvelles informations dans le graphe de connaissances.

Le Smals KG Checklist

Reconnaitre la différence entre les graphes et les graphes de connaissances n’est pas évident, non seulement pour des informaticiens non-spécialistes mais aussi, et surtout, pour les organisations. Au sein de Smals et ses membres, par exemple, l’usage et les possibilités des bases de données graphes sont reconnus ; pour faciliter, entre autres, les analyses de réseau. Mais quand est-ce qu’un projet nécessite un graphe de connaissances ? Pour répondre à cette question, Smals Research a développé le Smals KG Checklist. A partir d’une problématique concrète, le but du Smals KG Checklist est de déterminer si une solution à cette problématique requiert les trois conditions remplies et le développement d’un graphe de connaissances est une piste valable.

La checklist, disponible en PDF sous licence Creative Commons, se compose de deux parties.  Dans la première partie, nous allons d’abord : 1) décrire la problématique, 2) identifier les parties prenantes, et 3) identifier les concepts clefs (partagés par les parties prenantes). Les réponses à ces trois questions nous donnent un cadre pour les discussions suivantes.

La quatrième question se compose de trois blocs, une pour chaque condition, et chaque bloc à sa propre couleur. Ces trois blocs requièrent l’usage de la deuxième partie de la checklist et nous y retrouvons les mêmes couleurs.

Le violet correspond au schéma du graphe de connaissances. Nous retrouvons, dans la Section I, la connaissance des experts, la réutilisation des ontologies, la formalisation des législations, … et même la réutilisation des schémas existants. Les schémas des bases de données (relationnelles) contiennent souvent une représentation de nos concepts et relations que nous pouvons « réutiliser ». Si une des cases de la Section I est remplie (ou, voir plus tard, une des cases de la Section V), cette condition est remplie.

Le vert correspond à l’intégration des informations et données. Dès que plusieurs cases dans ces sections sont cochées, cette condition est remplie. Mais d’où viennent ces informations et ces données ?

• Section II se focalise sur l’intégration des données structurées (bases de données, fichiers Excel, …)
• Section IV se focalise sur l’intégration des données non-structurées (documents, Tweets, …)
• Section III, au milieu des sections II et IV, se focalise sur les métadonnées (d’où viennent les informations, leurs dates de créations, …)

Remarquez que la Section I a deux couleurs. La connaissance des experts peut contribuer au schéma et au graphe, par exemple. Dès que nous intégrons des bases de données existantes, nous allons (souvent) utiliser les schémas de ces bases de données pour le schéma du graphe de connaissances (surtout quand nous devons créer le schéma nous-même).

L’orange correspond à la découverte des informations implicites. Les Section V, VI, et VII correspondent respectivement avec l’IA symbolique, l’IA statistique, et les applications. Remarquez que la Section V nécessite un schéma et que la section VII est à moitié remplie en orange. Nous pouvons argumenter que la consultation des entités sous forme de page Web (comme, par exemple la page de Bruxelles de la graphe de connaissances DBpedia) est utile pour les utilisateurs, mais pas vraiment une application intelligente. Nous essayons de capter les applications intelligentes : c’est à dire celles qui interprètent le graphe de connaissances. Si une des cases dans les Section V et VI est remplie et/ou des applications intelligentes sont identifiées, la condition est remplie.

Une fois que les trois blocs de la première partie sont complétés, nous sommes capables de répondre à la cinquième question : est-ce que les trois conditions sont remplies ? Si oui, il est probable qu’un graphe de connaissances soit une solution (élégante) à cette problématique. La sixième question, en gris, nous permet d’enregistrer des pistes pour élargir le graphe de connaissances.

Une démonstration

En conclusion

Cet article de blog est une contribution individuelle de Christophe Debruyne, spécialisé en knowledge graph chez Smals Research. Cet article est écrit en son nom propre et n’impacte en rien le point de vue de Smals.

Presentation

Een knowledge graph wordt gebouwd met data afkomstig uit verschillende bronnen, welke worden omgezet naar een graaf, waarna het geheel doorgaans in een graafdatabank wordt opgeslagen. Welke bronnen worden dan in een knowledge graph geïntegreerd? Voorbeelden van bronnen zijn bestaande (relationele) databanken die systemen ondersteunen, documenten (gescand en born-digital), en de kennis van personen. In dit artikel leggen we de nadruk op (relationele) databanken die bestaande systemen ondersteunen.

Heel wat bestaande systemen draaien bovenop (relationele) databanken. De informatie die in dergelijke systemen zit vervat is doorgaans moeilijk integreerbaar met andere bronnen die vereist zijn voor het bouwen van een knowledge graph. Of een organisatie kan bijvoorbeeld van mening zijn dat de bestaande systemen niet mogen vervangen worden door een graph databank, of wensen er niets aan te veranderen.

Het omzetten van data afkomstig uit een relationele databank (voor een specifiek doeleinde) naar een knowledge graph en deze in een graafdatabank opslaan leidt tot twee problemen: redundantie t.o.v. de originele data (en het beheer daarvan), en het bevragen van informatie dat mogelijks niet meer up-to-date is.

Een mogelijke oplossing hiervoor zijn virtual knowledge graphs. Virtual knowledge graphs laten toe om op een haast transparante manier de gegevens in een (relationele) databank als een graaf te benaderen. Achter de schermen zal zo’n systeem de bevragingen in een graph query-taal vertalen naar, bijvoorbeeld, SQL.

Mappings: relaties tussen een databank en een knowledge graph

Tijdens de omzetting van data naar een knowledge graph verplaatst het accent in de data van attributen naar dingen; een veldje stad met als inhoud “Brussel” wordt het concept van de stad Brussel met als naam “Brussel”, bijvoorbeeld. Dit aspect, dat gekend staat als “things, not strings”, maakt de graaf completer, expressiever, en meer betekenisvol dan de originele bronnen.

Om dit te realiseren, moeten we echter beschrijven hoe databanken zich tot de ontologie (vergelijkbaar met een schema) van een knowledge graph verhouden. Zulke beschrijvingen heten mappings en worden aan de hand van een speciaal taaltje beschreven. Een gestandardiseerd mapping taaltje is R2RML, wat staat voor RDB to RDF Mapping Language. R2RML werd in 2012 gepubliceerd en dient om gegevens in relationele databanken als RDF grafen te vertalen of te benaderen. RDF is een gestandaardiseerd graaf-datamodel en is een onderwerp dat we in een eerdere blog post hebben behandeld. RDF beschrijft dingen aan de hand van zogenaamde triples. Triples zijn van de vorm (subject, predicate, object) en verbinden een onderwerp (subject) met een voorwerp (object) aan de hand van een relatie (predicate). Een voorbeeld hiervan is: ex:Christophe ex:woontIn ex:Brussel.

Het voordeel van een standaard zoals R2RML is dat meerdere vrije en commerciële oplossingen deze ondersteunen, wat interoperabiliteit ten goede komt. Naast R2RML bestaan er andere taaltjes, maar in dit artikel leggen we het principe van virtual knowledge graphs aan de hand van R2RML uit. De oplossingen die we zullen aanhalen ondersteunen, naast R2RML, ook hun eigen taal.

Hoe gaat dit in zijn werk? Laten we vertrekken van een tabel Addresses met twee kolommen ID en city. Aan de hand van een mapping zullen we die tabel gebruiken om RDF triples te genereren. Een mapping bestaat uit:

• Exact 1 logische tabel (een query, tabel of view) die naar RDF zal worden vertaald. In dit geval alles uit de tabel Addresses.
• Exact 1 subject-map die de subject van onze triples zal genereren. In ons voorbeeld wordt de kolom ID gebruikt om unieke IRI’s voor steden te creëren. Een subject-map kan ook 1 of meerdere referenties naar typen bevatten. In het voorbeeld is hier een verwijzing naar dbpedia:Place dat voor elk subject x de triple x rdf:type dbpedia:Place gaat genereren.
• 0 of meedere predicate-object-maps die de overige predicaten en objecten zullen genereren. In ons voorbeeld nemen we de inhoud van de kolom city om een triple met predicaat foaf:name te generen.

Aan de hand van deze mapping en het tabel in ons voorbeeld worden de volgende triples genereerd:

@prefix foaf: <http://xmlns.com/foaf/0.1/> . 
@prefix dbpedia: <http://dbpedia.org/ontology/> . 
<http://foo.example/Addresses/1> 
  a dbpedia:Place ; 
  foaf:name "Brussels" ; 
. 

R2RML laat ons ook toe om relaties tussen twee logische tabellen te declareren. Dit passen we toe in het volgende voorbeeld. We hebben een tabel People met drie kolommen (ID, fname, en addr). Er is een vreemde sleutel van People(addr) naar Addresses(ID). De logical table van deze mapping bevat de naam van de tabel en hierdoor worden alle kolommen geselecteerd. De subject-map maakt van elke subject een entiteit van het type foaf:Person. De predicate-object-map legt verbanden tussen de subjects van deze triplesmap met subjects van de voorgaande triplesmap aan de hand van een expliciete verwijzing (i.e., rr:parentTriplesMap) en de JOIN condities. Een R2RML processor zal de twee logische tabellen aan de hand van die condities JOINen. In ons voorbeeld resulteert dit in triples met de predicate foaf:based_near.

Nemen we de twee triplesmaps en de twee tabellen, dan kunnen we de volgende RDF graaf genereren:

@prefix foaf: <http://xmlns.com/foaf/0.1/> . 
@prefix dbpedia: <http://dbpedia.org/ontology/> . 
<http://foo.example/Addresses/1> 
  a dbpedia:Place ; 
  foaf:name "Brussels" ; 
. 
<http://foo.example/Person/1> 
  a foaf:Person ; 
  foaf:name "Christophe" ; 
  foaf:based_near <http://foo.example/Addresses/1> ; 
. 
<http://foo.example/Person/2> 
  a foaf:Person ; 
  foaf:name "Kevin" ; 
. 

Merk op dat waar de vreemde sleutel tussen de twee tabellen initieel weinig betekenis had, de relatie tussen personen en plaatsen in de graaf expliciet wordt.

Relationele Databanken als RDF-grafen benaderen

R2RML mappings worden niet alleen gebruikt om RDF grafen uit relationele databanken te destilleren. In dit artikel worden de mappings gebruikt om de data in relationele databanken als RDF grafen te benaderen. Software zoals Ontop en Stardog vertalen bevragingen in SPARQL (de querytaal voor RDF) naar SQL.

We nemen als voorbeeld de volgende SPARQL-query:

PREFIX foaf: <http://xmlns.com/foaf/0.1/>
SELECT DISTINCT ?name WHERE {
  ?x foaf:name ?name .
}

Deze SPARQL-query vraagt naar alle unieke namen (via de predicaat foaf:name). Een virtuele knowledge graph analyseert de SPARQL-query en de mappings. De predicaat foaf:name wordt op twee plaatsen gebruikt (eens voor personen, en eens voor adressen). Aan de hand van die informatie herschrijft de virtual knowledge graph de SPARQL-query naar een SQL-query. Het antwoord op de SQL-query wordt dan gebruikt om een antwoord op de SPARQL-query te formuleren. Ontop, bijvoorbeeld, genereert de volgende SQL-query:

SELECT DISTINCT v5.Name2m2 AS Name2m2
FROM (
  SELECT DISTINCT v1.fname AS Name2m2 
    FROM People v1 WHERE v1.fname IS NOT NULL
  UNION ALL
  SELECT DISTINCT v3.city AS Name2m2 
    FROM Addresses v3 WHERE v3.city IS NOT NULL
) v5

De SQL-query bevraagt de twee tabellen, verzamelt de resultaten van de twee bevragingen in een unie, en gebruikt de unie voor de uiteindelijke bevraging. Tools zoals Ontop zijn dus “intelligent” genoeg om zo min mogelijk informatie voor de query te gebruiken.

Het gaat zelfs een stapje verder: virtual knowledge graphs kunnen ook over de ontologieën die in de mappings werden gebruikt redeneren. Dit moet worden ingesteld en de ontologieën moeten beschikbaar worden gesteld (e.g., als input).

De virtual knowledge graphs gebruiken de axioma’s (type-hiërarchieën, rollen-hiërarchieën, etc.) in ontologiën om impliciete informatie uit expliciete informatie te halen. De mogelijkheden zijn doorgaans beperkt tot de reeds vermelde soorten axioma’s of axioma’s die tot de expressiviteit van relationele databanken behoren. Natuurlijk redeneren ze niet over de informatie op niveau van de graaf. De axioma’s worden gebruikt om de SQL-query’s als dusdanig te herschrijven.

We illustreren dit met een voorbeeld. Laten we aannemen dat we in onze ontologie de volgende twee axioma’s hebben: alle entiteiten van het type foaf:Person zijn ook entiteiten van het type smals:Thing, en alle entiteiten van het type dbpedia:Place zijn ook entiteiten van het type smals:Thing. Die twee axioma’s laten ons toe om een eenvoudige klassenhiërarchie op te bouwen. We wijzigen onze mappings niet en vragen aan onze virtual knowledge graph: “Geef ons een lijst van alle dingen.”

PREFIX smals: <https://kg.smals.be/ontologies/smals#> 
SELECT DISTINCT ?x WHERE {
  ?x a smals:Thing .
} 

Wanneer de ontologie niet als input werd meegegeven, dan beschikken onze mappings niet over voldoende informatie om hier een antwoord op te geven. Ontop kan dus geen SQL-query genereren en geeft een leeg resultaat terug.

Wanneer we de ontologie expliciet als input meegeven, echter, dan wordt de volgende SQL-query gegenereerd om op bovenstaande SPARQL-query een antwoord te formuleren.

SELECT v9.ID1m1 AS ID1m1, v9.ID3m2 AS ID3m2, v9.v0 AS v0
FROM (
   SELECT v3.ID1m1 AS ID1m1, NULL AS ID3m2, 0 AS v0
   FROM (SELECT DISTINCT v1.ID AS ID1m1 FROM Addresses v1) v3
  UNION ALL 
   SELECT NULL AS ID1m1, v7.ID3m2 AS ID3m2, 1 AS v0
   FROM (SELECT DISTINCT v5.ID AS ID3m2 FROM People v5) v7
) v9

Ontop was in staat te achterhalen wat er allemaal met een smals:Thing overeenkwam en ging op zoek naar de corresponderende mappings. In dit voorbeeld had Ontop enkel nood aan de kolommen die voor de subjects van elke mapping werden gebruikt (zijnde ID van People en ID van Addresses). In de SQL-query zijn er dus twee kolommen die met deze twee ID’s overeenkomen, en een derde kolom voor de “boekhouding”; de waarde 0 voor Addresses en de waarde 1 voor People.

Virtual knowledge graphs vertalen SPARQL-query’s naar SQL-query’s die op hun beurt moeten verwerkt worden. Dit brengt ons naar enkele observaties:

• 1) Virtual knowledge graphs zijn, vergeleken met triplestores (graafdatabanken voor RDF), trager. De voordelen van virtual knowledge graphs zijn het bevragen van data in originele bronnen en het voorkomen van dataredundantie.
• 2) Het gebruik van ontologieën binnen de virtual knowledge graph laat ons toe meer informatie te bevragen, maar dit gaat natuurlijk ten koste van performantie. Men moet zich echter de vraag stellen of de voordelen zwaarder doorwegen dan de nadelen. Wensen we entiteiten via superklassen te benaderen, dan konden we deze ook expliciet in de mapping plaatsen.

Dat het ondersteunen van redeneren een negatieve impact op performantie heeft geldt ook voor triplestores. Voor virtual knowledge graphs moeten we echter rekening houden met het feit dat de resulterende SQL-query’s zeer complex kunnen zijn. Natuurlijk kunnen we ons voor een aantal problemen vrijwaren door de onderliggende databanken naargelang de vereisten te configureren (e.g., query timeout en max aantal JOINs).

Wanneer we van virtuele knowledge graphs gebruik maken, moeten we rekening houden met het feit dat niet alle SPARQL functionaliteit ondersteund kan worden. Sommige beperkingen hebben te maken met de onderliggende databank (de beschikbaarheid van REGEX-functionaliteit, bijvoorbeeld). Andere beperkingen hebben te maken met de manier hoe SPARQL-query’s naar SQL-query’s worden herschreven. Dit hangt af van de implementatie van de virtual knowledge graph.

Sommige beperkingen hebben mogelijks een belangrijke impact op het gebruik van de knowledge graph. De volgende SPARQL-query, bijvoorbeeld, vraagt naar alle leidinggevenden (+1, +2, …) van alle werknemers aan de hand van een zogenaamd arbitrair pad. Een arbitrair pad gaat op zoek naar 0-of-meerdere (*) of 1-of-meerdere (+) relaties tussen concepten van een bepaald patroon. In dit geval hebben we dus 1-of-meerdere smals:supervisor relaties tussen ?x en ?y.

PREFIX smals: <https://kg.smals.be/ontologies/smals#> 
SELECT DISTINCT * WHERE {
  ?x smals:supervisor+ ?y.
}

Voor triplestores is dit een makkelijke query. Virtual knowledge graphs ondersteunen dit echter (nog) niet. Om dit te kunnen oplossen moeten we zelf onze SPARQL-query herschrijven. Als we weten dat er maximaal 4 lagen in de hiërarchie zijn, dan kunnen we deze exhaustief neerschrijven:

PREFIX smals: <https://kg.smals.be/ontologies/smals#> 
SELECT DISTINCT * WHERE {
  { ?x smals:supervisor ?y } UNION                             # +1
  { ?x smals:supervisor/smals:supervisor ?y } UNION            # +2
  { ?x smals:supervisor/smals:supervisor/smals:supervisor ?y } # +3
}

Dit vergt natuurlijk achtergrondkennis omtrent de graaf  en een organisatie. Men zou kunnen denken dat dit op te lossen is aan de hand van de ontologie; namelijk door aan te geven dat smals:supervisor een transitieve relatie is. Op die manier zou men via ?x smals:supervisor ?y aan alle leidinggevenden van een persoon kunnen opvragen. Het probleem is dat transitiviteit niet tot de expressiviteit van courante virtual knowledge graph technologieën behoren. (*)

Dit brengt ons naar enkele nieuwe observaties:

• 3) Virtual knowledge graphs ondersteunen niet alle aspecten van SPARQL. Dergelijke beperkingen hebben als oorzaak de onderliggende relationele databank of de implementatie van de virtual knowledge graph.
• 4) Hoewel R2RML, de taal om relationele databanken naar RDF te vertalen, gestandaardiseerd is, is het gedrag van een virtual knowledge graph niet gestandaardiseerd. De beperkingen hangen af van de oplossing die men kiest (zie hier voor Ontop, en hier voor Stardog). De mappings zijn interoperabel, maar de oplossingen zijn dat niet.
• 5) De keuze van een oplossing hangt dus ook af van onze knowledge graph requirements.

Een laatste belangrijk punt is dat virtual knowledge graphs doorgaans aannemen dat de onderliggende relationele databases zich naar standaard SQL gedragen. Elke afwijking kan het proces verstoren. Dit hebben we zelf ondervonden toen we virtual knowledge graphs op een MS SQL Server database hebben toegepast. Een frappante beperking van MS SQL Server is dat deze geen LIMIT zonder ORDER BY toelaat, terwijl dit (hoewel te vermijden) eigenlijk mag. De SQL-query’s die virtual knowledge graphs genereren kunnen dan niet worden uitgevoerd, wat tot fouten leidt. Dit is spijtig, want een LIMIT zonder ORDER BY wordt door tal van graaf-exploratie tools, zoals Ontodia, gebruikt.

Een kleine studie

Binnen Smals Research hebben we virtual knowledge graphs toegepast op een MS SQL Server databank met informatie omtrent werknemers, softwareprojecten, hardware,… en hun relaties. Voor onze studie hebben we niet alleen een kleine ontologie, maar ook de nodige mappings in R2RML gemaakt. De mappings werden gebruikt om:

• RDF te genereren die in een triplestore werd opgeslagen aan de hand van Apache Jena (fuseki);
• Een Ontop installatie via Docker (ontop);
• Een Stardog installatie via Docker (stardog).

Voor de triplestore en Ontop hebben we ook omgevingen gecreëerd waar redeneren met de ontologie werd ingesteld (fuseki-r en ontop-r). Voor de triplestore hebben we RDFS redeneren ingesteld, en voor Ontop OWL QL. OWL reasoning in Apache Jena leidde tot problemen op een lokale machine (niet genoeg geheugen, want redeneren vergt resources). De triplestore draaide in een Docker omgeving op een standaard laptop. De MS SQL Server draaide op de infrastructuur van Smals. Dit is belangrijk om enige vertraging vanwege het netwerkverkeer in achting te nemen.

We hebben een aantal query’s geformuleerd die we op elk systeem 10-maal draaiden. Om cold-start problemen, zoals de eenmalige analyse van de mapping te vermijden, werd voor elk experiment een eenvoudige query eenmaal uitgevoerd. Hoewel niet extensief, diende dit experiment om een beter beeld te vormen van:

• welke de mogelijkheden van virtual knowledge graphs zijn, en
• welke de voor- en nadelen van bepaalde oplossingen zijn.

Query: een lijst van alle typen in de knowledge graph

Deze eenvoudige SPARQL-query laat ons toe om alle typen op te halen die in een is-een relatie werden gebruikt:

SELECT DISTINCT ?type WHERE {
  [] a ?type .
} ORDER BY ?type

Uit de resultaten zien we dat een native triplestore sneller is, en dat is geen verrassing. Het inschakelen van redeneren heeft doorgaans een impact op de performantie. Voor deze query doet Stardog het beter dan Ontop.

Query: een lijst van alle relaties in de knowledge graph

Deze eenvoudige SPARQL-query laat ons toe om alle relaties in de knowledge graph op te halen:

SELECT DISTINCT ?p WHERE {
  [] ?p [] .
} ORDER BY ?p

Wat blijkt? Stardog was niet in staat deze query op te lossen. In sommige gevallen is Stardog niet in staat variabelen op de plaats van relaties te gebruiken als de subject en object niet elders gebruikt wordt of geen constanten bevat.

Query: een lijst van alle personen met namen, en hun optionele +2

De volgende SPARQL-query is een meer “realistische” query. We wensen een lijst van alle personen, hun namen (via rdfs:label), en hun +2 waar relevant (want niet iedereen heeft een +2). De OPTIONAL is vergelijkbaar met een LEFT OUTER JOIN in SQL.

SELECT DISTINCT ?p ?l ?s WHERE {
  ?p a smals:Person ; rdfs:label ?l .
  OPTIONAL {
    ?p smals:supervisor [ smals:supervisor ?s ]
  }
}

Ontop en Fuseki zonder reasoning hebben best gelijkaardige resultaten. Ook hier heeft redeneren een impact. Stardog is wat trager dan Ontop, maar toch ietsjes sneller dan Ontop met redeneren.

Query: een lijst van alle personen, hun eventuele naam, en zonder +1

Deze SPARQL-query lijkt op het vorige voorbeeld, maar heeft een belangrijk verschil; namelijk een OPTIONAL + ! BOUND. We zijn op zoek naar personen zonder +1 en bereiken dit door een OPTIONAL en enkel de resultaten te weerhouden waarvoor de variabele in de OPTIONAL geen waarde heeft (m.a.w.: “not bound”). Dit is een vrij courant patroon in SPARQL-query’s.

SELECT DISTINCT ?p ?l WHERE {
  ?p a smals:Person .
  OPTIONAL { ?p rdfs:label ?l }
  OPTIONAL { ?p smals:supervisor ?s. }
  FILTER(!BOUND(?s))
}

Ook hier blijkt Ontop het beter te doen dan Stardog. En ook hier hebben Fuseki en Ontop gelijkaardige resultaten.

Vergelijking (**)

In onze studie blijkt Ontop het doorgaans (iets) beter te doen dan Stardog. Dat wil niet zeggen dat Stardog een slecht product is. Ontop is minder toegankelijk; alles werkt aan de hand van bestanden die geconfigureerd moeten worden. Stardog, daarentegen, biedt naast bestanden ook een studio-omgeving aan. Deze studio maakt het makkelijk om de (virtuele) knowledge graphs via een interface te beheren.

Ontop is een oplossing voor virtual knowledge graphs. Stardog, daarentegen, is ook een triplestore met (beperkte) BI functionaliteit. In Stardog kan men op een makkelijk wijze virtual knowledge graphs van verschillende databases met triplestores combineren. Omdat Ontop zich enkel tot virtual knowledge graph richt, is eenzelfde resultaat bekomen wat complexer. Het zal namelijk een combinatie van oplossingen vergen.

Waar Stardog makkelijk verschillende databanken (en databanktechnologieën) kan benaderen, moet men met Ontop hiervoor beroep doen op “middleware” zoals Dremio. Dremio is een platform dat ons toelaat bronnen als een virtuele dataset te benaderen. Met andere woorden; virtualisatie bovenop virtualisatie. 

Zowel Ontop en Stardog hebben hun eigen taaltje naast de ondersteuning voor R2RML. De taal die Stardog aanbiedt is, tezamen met de studio omgeving, best wel gebruiksvriendelijker. Het gebruikt van dat taaltje gaat echter ten koste van interoperabiliteit. Verder is hun taaltje niet gebaseerd op een graaf-datamodel, waardoor we die niet als een graaf kunnen bevragen.

Opportuniteiten

Naast het bevragen van relationele databanken als een graaf, biedt het gebruik van virtual knowledge graphs en R2RML ook nog andere voordelen:

1. De R2RML mappings zijn grafen, kunnen worden geannoteerd, en zelf als graaf bevraagd worden. In een complexe omgeving kunnen we dus nagaan waar informatie van entiteiten vandaan komt. Een SPARQL-query zoals “geef me alle mappings waar entiteiten van het type persoon worden gemaakt” zijn dus mogelijk.
2. De gegevens in verschillende databanken zijn conceptueel geïntegreerd. Dit laat ons toe om geïntegreerde data op het niveau van knowledge graphs te valideren, bijvoorbeeld aan de hand van SHACL (het onderwerp van een vorig artikel). 

Samenvatting

In dit artikel hebben we het onderwerp van virtuele knowledge graphs besproken. Virtual knowledge graphs laten ons toe om relationele databanken als een graaf te benaderen. Dit is handig als we wensen met de meest recente data te werken en data redundantie te reduceren. Daar tegenover staat dat virtual knowledge graphs wat trager zijn en niet alle mogelijkheden van de graaf-querytalen benut kunnen worden. De beperkingen van de virtual knowledge graphs liggen enerzijds aan de implementaties van oplossingen (m.a.w. vendor-specifieke beperkingen) en aan de onderliggende relationele databanken.

De meeste oplossingen ondersteunen een gestandaardiseerd taaltje om relationele databanken naar grafen af te beelden. Dit bevordert natuurlijk de interoperabiliteit. Het gedrag van een virtual knowledge graph is echter niet gestandaardiseerd en bestaande oplossingen moeten dus met de knowledge graph vereisten van een organisatie afgetoetst worden.

Voor dit artikel namen we enkel Ontop (vrije software) en Stardog (commercieel) onder de loep, maar er zijn natuurlijk ook nog andere oplossingen. De experimenten en vergelijkingen zijn beperkt en hadden de intentie om ons een aantal eerste inzichten te geven.

Indien up-to-date data belangrijk is en men met de best wel serieuze beperkingen (zoals het verlies in performantie, beperkingen in de soorten graafbevragingen die we kunnen stellen,…) kan leven, dan zijn virtual knowledge graphs een haalbare oplossing voor een organisatie. 

Door de beperkingen heeft men ook geen garantie dat tools voor knowledge graphs zonder enige aanpassing naar behoren zullen werken. Ontodia, bijvoorbeeld, maakt “out-of-the-box” gebruik van arbitraire paden. Arbitraire paden worden voor virtual knowledge graphs doorgaans niet ondersteund. Men moet dus de instellingen van Ontodia aanpassen.

En indien men wenst om aan graph analytics te doen, waarbij men grote hoeveelheden data en hun relaties wil analyseren, dan zijn virtual knowledge graphs absoluut niet aan te raden, en moet men opteren voor een kopie in een performante graafdatabank. Dus: hoe intensiever de toepassingen bovenop de knowledge graph, hoe minder haalbaar virtual knowledge graphs.

(*) Ultrawrap van Capsenta bleek dit te ondersteunen. Capsenta werd echter door data.world overgenomen. Deze technologie hebben we voor deze studie niet getest.

(**) Stardog herschrijft mappings in R2RML naar hun eigen taaltje. Tijdens het schrijven van dit artikel werd het echter duidelijk dat een recentere versie deze niet correct vertaalde, waardoor de virtual knowledge graph niet de juiste antwoorden teruggaf. We hebben Stardog hieromtrent gecontacteerd.

_________________________

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

Ontodia est une bibliothèque JavaScript open source permettant d’explorer et de visualiser les contenus d’un graphe de connaissances sous la forme de diagrammes interactifs. Ontodia ne requiert pas la connaissance des langages de requête de graphe, ce qui rend les graphes accessibles à tout type d’utilisateurs. Les diagrammes, qui sont esthétiquement agréables, peuvent être téléchargés en format SVG ou PNG. Smals Research a utilisé Ontodia non seulement pour montrer et expliquer le concept d’un graphe de connaissances au sein de Smals et auprès de ses clients, mais aussi dans des POCs.

Ontodia is een open source JavaScript-bibliotheek voor het verkennen en visualiseren van een knowledge graph aan de hand van interactieve diagrammen. Ontodia vereist geen kennis van graaf-querytalen, waardoor de knowledge graph voor alle soorten gebruikers toegankelijk wordt. De diagrammen, die esthetisch aantrekkelijk zijn, kunnen worden gedownload als SVG of PNG bestanden. Smals Research gebruikte Ontodia niet alleen om het concept van een knowledge graph binnen Smals en haar klanten toe te lichten, maar ook als onderdeel binnen een aantal POC’s.

Kennis en informatie in een bedrijfsorganisatorische context is doorgaans verspreid over databases, rekenbladen, documenten, etc. Daarnaast bezitten kenniswerkers ook domeinexpertise die niet in een systeem wordt opgeslagen. Maar wat als men die kennis en informatie wenst te integreren om, bijvoorbeeld, processen te automatiseren of nieuwe inzichten te verwerven? Knowledge graphs bieden hiervoor een oplossing.

In deze webinar werpt Christophe Debruyne zijn licht op het concept van de knowledge graphs en hun mogelijkheden. Hij behandelt daarvoor de volgende topics:

– Wat is een knowledge graph – Knowledge graphs versus andere initiatieven – Knowledge graphs versus andere AI technieken – Toepassingsgebied van knowledge graphs – Bouwen en onderhouden van een knowledge graph

Dans le contexte organisationnel d’une entreprise, les connaissances et les informations sont généralement réparties dans des bases de données, des tableurs, des documents, etc. Parallèlement, les travailleurs de la connaissance possèdent une expertise de domaine qui n’est pas stockée dans un système. Mais que faire dès lors si l’on souhaite intégrer ces connaissances et informations pour, par exemple automatiser des processus ou acquérir de nouvelles connaissances ? Les knowledge graphs offrent une solution à cet égard.

Dans ce webinaire, Christophe Debruyne fait la lumière sur le concept des graphes de connaissances et leurs possibilités. Il aborde les topics suivants :

– Qu’est-ce qu’un knowledge graph – Positionnement des knowledge graphs face à d’autres initiatives – Positionnement des knowledge graphs face à d’autres techniques d’IA – Domaine d’application des knowledge graphs – Construction et maintenance d’un knowledge graph

Recording

Presentation

SHACL valideert data, welke opgeslagen zijn als graaf-data in Resource Description Framework (RDF). RDF is net als SHACL een W3C standaard en een vaak onzichtbare gevestigde waarde om data te integreren. Details over RDF zijn voor dit artikel niet belangrijk, het volstaat te weten dat RDF een eenvoudig graaf-datamodel is en dat RDF ons toelaat “dingen” met International Resource Identifiers (IRI’s) te identificeren.^[1] Een bekend voorbeeld van een IRI is een Uniform Resource Locator (URL) om een document op het Web te identificeren en op te vragen. Een IRI kan een verwijzing naar externe gegevens bevatten en hierdoor laat RDF ons toe om een gedistribueerde graaf te bouwen. We zullen zien dat SHACL de IRI’s gebruikt om naar fouten in de graaf-data te wijzen.

Omdat SHACL van RDF gebruik maakt, wordt het vaak in de context van Linked Data voorgesteld. Desalniettemin is het beeld van SHACL wat genuanceerder; SHACL werd ontwikkeld om RDF graaf-data te valideren, ongeacht het Linked Data is. Door deze nuance in het achterhoofd te houden, wordt het makkelijker om opportuniteiten en cases te vinden. Dit artikel poogt deze nuance, aan de hand van voorbeelden, te belichten.

Een scenario als motivatie

Als gegevens uit verschillende systemen dienen gecombineerd te worden, dan moet men rekening houden met voorwaarden die over die systemen heen gelden. Omdat elk systeem normaliter enkel verantwoordelijk is voor de data die tot hun scope behoren, worden die voorwaarden niet door de afzonderlijke systemen afgetoetst. Het valideren van die voorwaarden is echter belangrijk om de kwaliteit van de gegevens in zijn geheel te vrijwaren.

We illustreren de problematiek met een eenvoudig voorbeeld. We hebben een aangiftesysteem (Systeem A) en een systeem voor het distribueren van voordelen (Systeem B). Elk systeem heeft een conceptueel schema waaruit delen van de applicatielaag en een database schema voortvloeien (zie onderstaand figuur).

Beide systemen delen concepten, in dit geval de concepten “dossier” en “dossiernummer”. Systeem B houdt de data van transacties bij, waaronder een verwijzing naar het dossier van een transactie. Systeem B hoeft de datum van aangifte niet bij te houden omdat dit niet tot de scope van het systeem behoort. Doch is het logisch dat, alvorens het tweede systeem een transactie kan uitvoeren (in dit geval het toewijzen van een voordeel), dat de datum van aangifte vóór eender welke transactie moet liggen. Men gaat er van uit dat alles binnen een organisatie vlot verloopt en er dus geen problemen zijn. Maar hoe controleren we dit?

Men kan controlescripts schrijven die de verschillende bronnen raadplegen, maar dan zitten de voorwaarden “verborgen” in de code van die scripts. Is er een manier om die voorwaarden “buiten” de systemen op een gestructureerde en transparante manier te beschrijven? Ja, SHACL biedt een oplossing op die vraag. Vooraleer we dit demonstreren, zullen we SHACL eerst toelichten.

SHACL

SHACL biedt ons een nieuwe manier om data op een open, gestructureerde, en transparante wijze te valideren. SHACL laat ons toe om voorwaarden aan de hand van open en gestandaardiseerde modellen buiten de eigenlijke programmatie te definiëren en te valideren. Omdat SHACL expressiever is dan de meeste databasetechnologieën, maakt SHACL complexe logische- en vormcontroles mogelijk.

We hebben reeds aangehaald dat SHACL RDF grafen valideert. De graaf die wordt gevalideerd wordt de data graph genoemd. De shapes graph bevat de voorwaarden beschreven met SHACL en wordt ook als een RDF graaf opgeslagen. De data graph en shapes graph worden door een validatieproces verwerkt en als resultaat hebben we een validation report. Het rapport is een RDF graaf met het resultaat: de data graph is conform of niet. Indien niet conform, dan bevat het rapport een lijst van problemen met gedetailleerde informatie en verwijzingen naar problemen.

De shapes graph bevat een verzameling shapes waaraan de data graph moet voldoen. Het proces verloopt in drie stappen. Voor elke shape S in de shapes graph gaat het proces:

1. Op zoek naar de zogenaamde focus nodes in de data graph. Elke shape definieert de focus nodes aan de hand van “targets”. Een shape voor transacties heeft als target “alle entiteiten van het type Transactie”, bijvoorbeeld. Deze stap geeft een verzameling terug.
2. Voor elk element in de verzameling focus nodes worden alle voorwaarden in de shape S afgetoetst. Elk probleem wordt aan een lijst toegevoegd. Voorbeelden van zulke voorwaarden zijn:
   1. Elke transactie behoort tot exact één dossier;
   2. De datum van een transactie moet groter zijn dan de datum van aangifte van het dossier dat tot die transactie behoort;
   3. …
3. De lijst van problemen wordt gebruikt om een validatierapport op te maken.

Hoewel men spreekt van een data- en shapes graph, hoeven deze graphs niet afzonderlijk bewaard te worden. Men kan de twee grafen in één grote (kennis)graaf opslaan. SHACL en het validatieproces zijn intelligent genoeg om de shapes uit de graaf te extraheren. 

Demonstratie

We zullen SHACL nu aan de hand van eenvoudig voorbeeld illustreren. We vertrekken van ons inleidend scenario en gaan er van uit dat onze gegevens reeds in een RDF graaf werden geïntegreerd. We zullen eerst nagaan of dossiers exact één datum van aangifte hebben. Onze data graph ziet er als volgt uit:

1.    @prefix ex: <http://www.example.com/ns#> .
2.    @prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
3.
4.    ex:D1 
5.      a ex:Dossier ;
6.    .
7.
8.    ex:D2
9.      a ex:Dossier ;
10.     ex:ingediendOp "2021-02-20" ;
11.   .
12.
13.   ex:D3
14.     a ex:Dossier ;
15.     ex:ingediendOp "2021-02-21"^^xsd:date ;
16.   .

Hier hebben we informatie over drie dossiers (ex:D1, ex:D2, en ex:D3). D1 heeft geen datum, D2 heeft een datum van het type string (default datatype), en D3 heeft een datum van het type datum. De graaf bevat verder (nog) niets. In onze shapes graph beschrijven we de voorwaarden voor een geldig dossier:

1.    @prefix ex: <http://www.example.com/ns#> .
2.    @prefix sh: <http://www.w3.org/ns/shacl#> .
3.    @prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
4. 
5.    ex:DossierShape
6.      a sh:NodeShape ;
7.      sh:targetClass ex:Dossier ;
8.      sh:property [
9.        sh:path ex:ingediendOp ;
10.       sh:datatype xsd:date ;
11.       sh:minCount 1 ;
12.       sh:maxCount 1 ;
13.     ] ;
14.   .

Op lijn 5 declareren we een nieuwe shape voor Dossiers. Deze shape gaat enkel entiteiten van het type Dossier valideren (lijn 7). In deze shape worden er voorwaarden op de relatie (property) ex:ingediendOp gedeclareerd. De voorwaarden voor deze relatie zijn:

• van het type xsd:date (lijn 10),
• minimaal één (lijn 11), en
• maximaal één (lijn 12).^[2]

Eens we de data graph en de shapes graph als input aan een SHACL processor geven, dan krijgen we het volgende validatierapport:

$ pyshacl -s shacl.ttl -m -f human data.ttl
Validation Report
Conforms: False
Results (2):
Constraint Violation in DatatypeConstraintComponent (http://www.w3.org/ns/shacl#DatatypeConstraintComponent):
        Severity: sh:Violation
        Focus Node: ex:D2
        Value Node: Literal("2021-02-20")
        Result Path: ex:ingediendOp
        Message: Value is not Literal with datatype xsd:date
Constraint Violation in MinCountConstraintComponent (http://www.w3.org/ns/shacl#MinCountConstraintComponent):
        Severity: sh:Violation
        Focus Node: ex:D1
        Result Path: ex:ingediendOp
        Message: Less than 1 values on ex:D1->ex:ingediendOp

Dit rapport werd gegenereerd met pySHACL (later verwijzen we naar andere implementaties). Deze implementatie biedt ons, voor de demonstratie, een vrij leesbaar rapport in een console omgeving. Men kan zien dat twee dossiers niet aan de voorwaarde voldoen. Het rapport bevat verder expliciete verwijzingen naar de problemen.

We breiden het voorbeeld uit met transacties. We nemen aan dat transacties een datum hebben. De datum van een transactie moet, in principe, groter zijn dan de aangiftedatum van het dossier van die transactie. Voor de tweede demonstratie gebruiken we de volgende data graph:

1.    @prefix ex: <http://www.example.com/ns#> .
2.    @prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
3. 
4.    ex:D3
5.      a ex:Dossier ;
6.      ex:ingediendOp "2021-02-21"^^xsd:date ;
7.    .
8. 
9.    ex:T1 
10.     a ex:Transactie ;
11.     ex:behoortTot ex:D3 ;
12.     ex:geregistreerdOp "2021-02-22"^^ex:date ;
13.   .
14. 
15.   ex:T2
16.     a ex:Transactie ;
17.     ex:behoortTot ex:D3 ;
18.     ex:geregistreerdOp "2021-02-21"^^ex:date ;
19.   .

We behouden dossier ex:D3 en voegen twee transacties ex:T1 en ex:T2 toe. Beide transacties behoren tot Dossier ex:D3. Merk op dat de registratiedatum van ex:T2 en de aangiftedatum van ex:D3 op dezelfde dag vallen. Dit zou niet mogen. Gelukkig kunnen we nu de voorwaarde op de geïntegreerde data aftoetsen. We maken een shape voor transacties die dit zal controleren:

1.    @prefix ex: <http://www.example.com/ns#> .
2.    @prefix sh: <http://www.w3.org/ns/shacl#> .
3.    @prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
4. 
5.    # ex:DossierShape hier 
6. 
7.    ex:TransactieShape
8.      a sh:NodeShape ;
9.      sh:targetClass ex:Transactie ;
10.     sh:property [
11.       sh:path ex:behoortTot ;
12.       sh:class ex:Dossier ;
13.       sh:minCount 1 ;
14.       sh:maxCount 1 ;
15.     ] ;
16.     sh:property [
17.       sh:path ( ex:behoortTot ex:ingediendOp ) ;
18.       sh:lessThan ex:geregistreerdOp ;
19.     ] ;
20.   .

We laten de kardinaliteit en data type van de registratiedatum even buiten beschouwing (deze voorwaarden lijken op het vorige voorbeeld). Op lijnen 10 tot en met 15 controleren of elke transactie tot exact één entiteit van het type Dossier behoort. Op lijnen 16 tot en met 19 vergelijken we twee waarden: de aangiftedatum van het dossier via een complex pad (“ingediend op” via “behoort tot”) en de registratiedatum. Het validatieproces geeft ons het volgend rapport:

$ pyshacl -s shacl.ttl -m -f human data.ttl
Validation Report
Conforms: False
Results (1):
Constraint Violation in LessThanConstraintComponent (http://www.w3.org/ns/shacl#LessThanConstraintComponent):
        Severity: sh:Violation
        Focus Node: ex:T2
        Value Node: Literal("2021-02-21", datatype=xsd:date)
        Result Path: ( ex:behoortTot ex:ingediendOp )
        Message: Value of ex:T2->ex:geregistreerdOp <= Literal("2021-02-21", datatype=xsd:date)

De transactie ex:T1 is correct en komt dus niet in het rapport voor. De node ex:T2 heeft echter een fout. Het rapport geeft aan dat de waarde van het pad niet kleiner is dan de waarde voor ex:geregistreerdOp. De boodschap van de fout leest dat de waarde van ex:geregistreerdOp kleiner of gelijk is aan de waarde van het pad.

Bovenstaand voorbeeld met samengestelde paden licht maar het tipje van de sluier met betrekking tot SHACL’s mogelijkheden. SHACL ondersteunt de combinatie van voorwaarden aan de hand van logische operatoren (and, or, not, …) en bevat een belangrijk aantal ingebouwde functies voor onder andere tekenreeksen, numerieke gegevens, en data. SHACL biedt verder ook ondersteuning voor het aanmaken van (domein-specifieke) voorwaarden. Dergelijke voorwaarden worden beschreven in SPARQL (de querytaal voor RDF grafen) die in constraint components worden ingekapseld. Omdat die op maat gemaakte voorwaarden in RDF beschreven worden, kunnen deze dan ook op verscheidene plaatsen worden bevraagd en hergebruikt. Met andere woorden: onze op maat gemaakte voorwaarden zijn zelf interoperabel.

Standaard is de ernst van alle problemen een “overtreding” (violation)–een kritisch probleem. Men kan echter de ernst van bepaalde voorwaarden aanpassen naar een “waarschuwing” (warning)  en “informatie” (info) voor niet-kritische problemen. Dit verandert niets aan het validatieproces en het is dus aan een volgend proces om deze te interpreteren. We kunnen problemen prioriteren, bijvoorbeeld.

Mogelijkheden en implementaties

SHACL is een open standaard en hierdoor hebben we toegang tot verschillende implementaties, zowel vrij als commercieel. Voorbeelden van open en vrije implementaties zijn Apache Jena, TopBraid SHACL API, en pySHACL. Apache Jena ondersteunt de basis van SHACL. TopBraid SHACL API (gebouwd bovenop Apache Jena) en pySHACL ondersteunen een deel van de “advanced features” (SHACL-AF) zoals geavanceerde afleidingsregels en functies. SHACL-AF werd nog niet gestandardiseerd en behoort dus niet tot de basisspecificatie. Interessant om weten is dat TopQuadrant (het bedrijf achter TopBraid SHACL API) bij de standaardisatie betrokken is. Men ziet tegenwoordig ook dat commerciële oplossingen SHACL ondersteunen. Neo4j’s graph database, bijvoorbeeld, voegt de ondersteuning van SHACL incrementeel aan hun suite toe.

SHACL wordt niet alleen opslagen in RDF grafen, maar wordt ook toegepast op RDF grafen. Dit brengt een aantal voordelen en mogelijkheden met zich mee:

• SHACL bevordert transparantie. De shapes graph en validatierapporten zijn onderdeel van de kennis die men binnen een organisatie deelt. We kunnen beiden dus als onderdeel van een kennisgraaf beschouwen en de SHACL voorwaarden bevragen aan de hand van graph query-talen. Hierdoor heeft men een holistisch beeld van welke gegevens er bestaan in de kennisgraaf, hoe deze er dienen uit te zien, en hoe deze dienen te worden gebruikt.
• Men kan SHACL shapes annoteren met metadata. Dit is mogelijk dankzij de RDF graaftechnologie waarmee SHACL is onderbouwd. We kunnen, voor elk onderdeel van de shapes graph, aanduiden vanwaar de voorwaarde komt, de rationale, waar documentatie gevonden kan worden, etc. Eens dergelijke informatie voorhanden is, dan kan een organisatie op een homogene manier de informatie bevragen. Bevragingen (i.e., queries) zoals “welke voorwaarden gelden omtrent het concept Dossier en vanwaar komen deze?” zijn dan eenvoudig te realiseren.
• SHACL kan op verschillende plaatsen en op verschillende manieren toegepast worden: ter validatie van een kennisgraaf in zijn geheel, ter validatie van inputgegevens alvorens deze te integreren, en ter validatie van gegevens die dienen gedeeld te worden.
• Als laatste hebben we de actieve community en werkgroep achter SHACL. SHACL zelf bestaat reeds een aantal jaren. De community, gedreven door een belangrijk aantal industriepartners, is actief en werkt aan uitbreidingen voor taken naast validatie, zoals het genereren van interfaces en het begeleiden van zoekopdrachten. De kans bestaat dat men dra dergelijke tools kan gebruiken of uitproberen.

Nadelen

Hoewel SHACL ons toelaat voorwaarden buiten een systeem te externaliseren op een open en gestandaardiseerde wijze, moet men ook een aantal mogelijke nadelen overwegen.

• Ten eerste maakt SHACL gebruik van RDF als graaf-datamodel. Hoewel SHACL best expressief is, dienen sommige voorwaarden in SPARQL geformuleerd te worden. De nodige expertise in RDF, SPARQL,… dient in een organisatie aanwezig te zijn of opgebouwd te worden, wat niet per se evident is.
• Ten tweede kan SHACL complex overkomen. Complexe voorwaarden blijven complex, ongeacht de taal of omgeving. Maar wanneer deze complexiteit wordt gecombineerd met een gebrek aan RDF expertise, dan kan de leercurve steil zijn. Verder werd de standaard intentioneel compact gehouden. SHACL biedt de vergelijkingsoperatoren “kleiner dan” en “kleiner dan of gelijk aan” aan, maar niet de inverse operatoren. Indien men nood heeft aan de inverse relaties, dan moet men de shapes herschrijven (e.g., aan de hand van de beschikbare logische operatoren) of zelf de voorwaarden maken.
• Als derde puntje hebben we de beperkingen van bepaalde implementaties.  De meeste bibliotheken werken op gematerialiseerde grafen. Dit wil zeggen dat de grafen in een RDF bestand of een RDF graafdatabase werden openslagen. Komt de data van andere bronnen zoals een relationele databank, dan brengt dit uitdagingen wat betreft dataduplicatie en latency met zich mee. Dataduplicatie spreekt voor zich; we hebben “dezelfde” data op twee verschillende locaties. Het is bijgevolg mogelijk dat onze validatierapporten ten opzichte van de originele databronnen gedateerd zijn (i.e., latency). Er zijn initiatieven om databronnen als virtuele (kennis)grafen te benaderen, en dit is het onderwerp van een volgend artikel.

Andere motiverende scenario’s

In deze tekst legden we de nadruk op gegevens over systemen heen die, eens geïntegreerd, dienden gecontroleerd te worden. De toepassing van SHACL in deze context had dus betrekking op gegevensbeheer en gegevenskwaliteit. Hier zullen we het even hebben over andere motiverende scenario’s voor SHACL.

Ten eerste hebben we voorwaarden “verborgen” in code. Het gebeurt vaak dat bepaalde voorwaarden , die wel in het conceptueel model beschreven worden (bijvoorbeeld met UML-notatie), niet door de onderliggende databasetechnologieën worden ondersteund. Hierdoor zijn deze voorwaarden dan verborgen in de applicatielaag (i.e., de code). Belanghebbenden die de database onder de loep nemen zijn dan niet noodzakelijk op de hoogte van de voorwaarden die op een hoger niveau werden beschreven. Daar applicaties vaak evolueren, kan het de moeite lonen om die voorwaarden buiten het systeem op een open, herbruikbare, en transparante manier te declareren om de kwaliteit van de data te vrijwaren.

SHACL laat ook ons toe om inputgegevens, e.g., van formulieren, te valideren alvorens deze te integreren. Men kan twee complementaire benaderingen observeren. De logische- en vormcontroles van opzichzelfstaande inputgegevens alvorens deze te integreren, en de controles van de inputgegevens samen met de rest van data alvorens deze te integreren. In de tweede benadering is de data graph de unie van de inputgegevens en de data.

Als laatste hebben we gegevensuitwisseling, ofte semantische interoperabiliteit. Gegevensuitwisseling is een derde scenario en een vervolg van het tweede. In dit geval representeert SHACL de verwachtingen van, en afspraken tussen, de betrokken partijen. Omdat SHACL de voorwaarden als RDF opslaat, kan men deze voorwaarden centraliseren, ter beschikking stellen, en bevragen. Dit is makkelijk te realiseren door de shapes een IRI te geven die men kan consulteren (e.g., een URL binnen een bedrijfsnetwerk).

Conclusies

SHACL laat ons toe om graafdata op een flexibele en expressieve wijze te valideren. Hoewel SHACL initieel complex is en kennis van RDF technologieën vereist, is SHACL een mogelijks waardevolle aanvulling om de kwaliteit van data te bewaken. Een mogelijke use case is om de data van verschillende bronnen in een graaf te integreren om dan daarop voorwaarden over systemen heen te valideren. Verder is SHACL een open standaard met bestaande tooling. Er bestaan vrije bibliotheken om met SHACL aan de slag te gaan. Verder wordt SHACL ook in bredere semantische oplossingen (zoals de producten van TopQuadrant en Poolparty) geïntegreerd. Bestaande bibliotheken vertrekken doorgaans van gematerialiseerde grafen (i.e., dataduplicatie). Als dit een probleem zou vormen, dan kan men virtuele knowledge graphs onder de loep nemen. Virtual knowledge graphs staan ook in 2021 op de radar van Smals Research.

Voetnoten

^[1] RDF is een onderwerp dat we  in een eerdere blog post hebben behandeld. RDF beschrijft dingen aan de hand van zogenaamde triples. Triples zijn van de vorm (subject, predicate, object) en verbinden een onderwerp (subject) met een voorwerp (object) aan de hand van een relatie (predicate). Een voorbeeld hiervan is: ex:Christophe ex:werkt_voor ex:SmalsResearch.

^[2] De combinatie van “minimaal één” en “maximaal één” leidt tot “exact één”. SHACL heeft, om de standaard niet te ingewikkeld te maken, bewust voor een beperkt aantal voorwaarden gekozen. SHACL biedt wel de mogelijkheid om eigen voorwaarden aan te maken.

_________________________

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

Un Rocketbook est un bloc-notes réutilisable dont les pages peuvent être numérisées et envoyées à l’aide d’une application mobile. L’application scanne la page et recherche les destinations cochées par l’utilisateur. L’utilisateur configure les destinations dans cette application. Les destinations soutenues par l’application incluent, entre autres, e-mail, Dropbox, Google Drive, OneNote et OneDrive. Slack et Trello sont également soutenus, avec lesquels on peut facilement lier les pages numérisées aux processus.

Ook kunnen updates doorheen de tijd informatie lekken. Dit illustreren we in Figuur 1 met een zeer eenvoudig voorbeeld, waar we de aantallen per categorie (e.g., personeelscategorie) bijhouden. Als een tegenstander weet dat een bedrijf drie nieuwe werknemers heeft aangeworven, dan kan de tegenstander afleiden over welke categorieën het gaat. Ook hier kan een tegenstander heel wat afleiden met achtergrondkennis of informatie omtrent personeelscategorieën die te vinden zouden zijn.

Verder werd er aangetoond dat men via een reeks bevragingen (of queries) makkelijk informatie omtrent individuele datapunten en zelfs de hele dataset kan te weten komen. Men kreeg het inzicht dat privacy enkel gevrijwaard kan worden als er op een adequate wijze ruis in de data of de antwoorden op bevragingen wordt geïntroduceerd.

Een bepaald techniek om dit te realiseren heet Differential Privacy (DP). Het concept en onderliggende formalisme van DP werden voor het eerst gepubliceerd in 2006 (Dwork et al. 2006) en had een enorme impact. Privacy werd geformuleerd in termen van het algoritme dat ruis introduceert in plaats van in eigenschappen van een dataset.

Over de jaren heen werd het concept van nader bestudeerd en won velerlei prijzen. Recentelijk wordt DP alsmaar meer in de publieke en privésector toegepast, waardoor deze zelfs op de radar van Gartner kwam. De uitdagingen van DP zijn de beschikbare tooling (bibliotheken, raamwerken, etc.) en de kennis die nodig is om DP op een adequate manier toe te passen. Zoals we echter kunnen zien, duiken er alsmaar initiatieven op om DP toegankelijker te maken.

In een eerste instantie zullen we het principe visueel voorstellen. Om een idee te vormen waar en hoe DP wordt toegepast, zullen we een aantal voorbeelden uit de praktijk aanhalen. Nadien nemen we de wiskundige grondslag met net voldoende diepgang door om het principe beter te vatten. Er zijn ook een aantal varianten op DP, en zelfs varianten in diens toepassing. Varianten zullen in dit artikel niet behandeld worden.

Wat is differential privacy?

In Figuur 2 lichten we het principe eenvoudig toe. Waarom zou een persoon zijn informatie willen delen, of zelfs deze op een eerlijke manier willen delen? Een persoon wil namelijk niet dat het delen van diens informatie voor zichzelf onmiddellijke, mogelijk nefaste gevolgen heeft. Een klassiek voorbeeld is het mogelijk mislopen van bepaalde kansen zoals een hypothecaire lening.

Laten we aannemen dat we twee datasets hebben; één waar de gegevens van de persoon zijn opgeslagen, en één waar diens gegevens niet in voorkomen—ze verschillen dus in één record van elkaar. In DP wordt een methode voorgesteld waar een bevraging door een onderzoeker (of tegenstander) vergelijkbare antwoorden moet teruggeven, ongeacht welke dataset wordt gebruikt. Een onderzoeker wenst een vraag te laten beantwoorden en stuurt deze naar een systeem (al dan niet deels menselijk), die we een “DP Guard” noemen. Die guard consulteert de originele data om een antwoord te formuleren en maakt gebruik van een mechanisme om een welbepaalde willekeur in dat antwoord te introduceren. Die willekeur, onder andere bepaald door een privacy-parameter  die de privacy loss bepaalt, moet aan DP voorwaarden voldoen. Het zijn namelijk die voorwaarden die er voor zorgen dat de antwoorden vergelijkbaar en de privacy gevrijwaard blijven. Belangrijk is dat de antwoorden dusdanig vergelijkbaar zijn dat een onderzoeker niet kan achterhalen welke dataset werd gebruikt.

Het principe achter DP is dat iemands deelname aan een dataset niet te achterhalen valt, en dat het eigenlijk ook niet uitmaakt. De antwoorden blijven grosso modo dezelfde, en dus ook de conclusies en inzichten die daaruit gehaald kunnen worden. Indien een persoon toch een lening niet zou krijgen, dan lag dit aan de hele dataset en niet aan die ene record.

De concepten van privacy en privacy loss (en andere termen die we zullen tegenkomen) zijn allemaal wiskundig onderbouwd en bewezen­­—we weten welke soorten willekeur voor welke soorten vragen aan de DP vereisten voldoen. De parameters maximaliseren niet alleen de bruikbaarheid en correctheid van de antwoorden, maar worden ook gebruikt om de privacy loss te berekenen. We gaan later zien hoe we daar een soort van “boekhouding” mee kunnen doen.

Dankzij de formele beschrijvingen van privacy, garandeert DP een aantal zaken. Ten eerste krijgt een onderzoeker de originele data nooit te zien. Ten tweede, is het, zonder kennis van de originele database, niet mogelijk om met post-processing de privacy loss op te krikken.

Toepassingen

We weten nu dat een mechanisme op een welbepaalde manier ruis in data en/of antwoorden kan introduceren. Details omtrent die ruis, en hoe deze kan ingesteld worden, zullen we pas in de volgende sectie behandelen.

In dit stukje van het artikel zullen we een aantal toepassingen van DP aanhalen. Een uitdaging van DP is dat het vaak voor specifieke doeleinden wordt toegepast (bijvoorbeeld om privacy in leeralgoritmes te vrijwaren). Hierdoor kan het moeilijk zijn om DP of diens toepassingen daarvan te veralgemenen of naar andere toepassingsgebieden te transponeren. Met de volgende drie toepassingen pogen we een brede waaier aan mogelijkheden toe te lichten.

• Microsoft Research ontwikkelde PrivTree. Hun doel was om de geolocaties van personen in databases te beschermen. Met andere woorden, hun doel was er voor te zorgen dat het gebruik van die geolocaties geen personen kan identificeren. Er zijn twee fasen in hun proces. In een eerste instantie delen ze de kaarten zodanig op zodat enige willekeur (ruis) die later toegevoegd zou worden de statistische eigenschappen van de databank zo goed als mogelijk bewaart. Men wilt bijvoorbeeld niet dat een verzameling punten dicht bij elkaar plots ver van elkaar worden verspreid (denk aan stadscentra versus woonwijken). In een tweede instantie wordt de ruis binnen elke partitie toegevoegd.
• Uber werkte samen met academici aan een oplossing voor DP. Ze wensten DP in hun data analyses te introduceren. Hun analisten maken voornamelijk gebruik van SQL om gegevens op te vragen. De oplossing die werd ontwikkeld had als oog om de bestaande infrastructuur te bewaren. Ze wensten geen beroep te doen op een softwarebibliotheek die DP in de resultaten injecteerden. In plaats daarvan, ontwikkelden ze een platform waar hun bestaande SQL queries automatisch werden herschreven (Johnson et al. 2020). Ze “injecteerden” als het ware DP in de queries. Op die manier hoefden analisten zich niet te veel zorgen maken over de technische aspecten van DP. Opmerkelijk was dat ze in staat waren om meer dan 90% van de duizenden queries die analisten hadden geformuleerd, te herschrijven.
• Apple gebruikt DP als onderdeel van hun service om populaire emoji’s te voorspellen. DP voorspelt de emoji’s natuurlijk niet, maar dit proces werd in de pijplijn geïntroduceerd om de privacy van gebruikers te vrijwaren. Interessant in dit voorbeeld is dat DP lokaal op iemands toestel werd toegepast. In tegenstelling tot de twee voorgaande voorbeelden waar data gecentraliseerd is en DP tijdens bevragingen werden toegepast, maken ze hier gebruik van DP in iemands data alvorens deze op te slaan. In zulk een setting gaat men er van uit dat men de gebruikers van het gecentraliseerde systeem niet kan vertrouwen; alle bevragingen en analyses maken sowieso gebruik van data met ruis.

Men kan nog aantal andere voorbeelden van DP aanhalen, maar deze drie voorbeelden geven al een vrij duidelijk plaatje waarvoor en hoe DP kan gebruikt worden; data analyses en AI (e.g., machine learning), met bibliotheken of een laag bovenop bestaande infrastructuur, op een lokale of gecentraliseerde wijze, enz. Men kan zich nu de vraag stellen hoe dit eigenlijk werkt.

Wiskundige grondslag

Hier lichten we het principe wat meer formeel toe. Een functie F voldoet aan DP voorwaarden en noemen we dus een mechanisme als voor alle mogelijke naburige datasets x en y (dat zijn datasets die zich in één rij verschillen), en voor alle mogelijke verzamelingen oplossingen van de functie F, die we OPL(F) zullen noemen, de volgende voorwaarde geldt:

Waar e de wiskundige constante 2.7182 (afgerond) is. In deze voorwaarde is ε de privacy-parameter^[2] en laat ons toe om het aandeel privacy te manipuleren.

• Hoe kleiner ε, hoe gelijkaardiger de outputs moeten zijn, dus hoe meer privacy;
• Hoe groter ε, hoe meer verschillend de outputs mogen zijn, met als resultaat minder privacy.

Deze formule zier er ingewikkelder uit dan het eigenlijk is. Deze formule legt een beperking op; namelijk dat de kansen (Pr in de figuur) dat alle koppels een bepaalde oplossing hebben op elkaar moeten lijken. En die gelijkwaardigheid wordt bepaald door ε. Verder is de voorwaarde symmetrisch omdat dit voor alle mogelijke paren van naburige datasets moet gelden. Dit principe wordt voor twee datasets in Figuur 3 op een zeer vereenvoudigde manier geïllustreerd.

Wat is functie F dan? F is de functie met een welbepaalde willekeur (randomness) en het is die willekeur die aan DP voorwaarden moet voldoen. De verschillende soorten willekeur die al dan niet aan de voorwaarden voldoen werden bestudeerd. Een Gaussiaanse kansverdeling voldoet niet aan de voorwaarden, bijvoorbeeld, en een Laplace kansverdeling (voor telfuncties) wel. Waarom de ene kansverdeling wel voldoet aan de voorwaarden en de andere niet is voor dit artikel niet belangrijk. Belangrijk is om te weten dat de wetenschappelijke gemeenschap de DP eigenschappen voor verschillende soorten functies en kansverdelingen hebben bewezen.

Laten we het voorbeeld van een eenvoudige telfunctie nemen. Dit kan men vergelijken met een SELECT COUNT(*) query in SQL. De telfunctie F, met DP, ziet er dan als volgt uit:

In de formule is f de telfunctie die de “echte” waarde teruggeeft, dus de telfunctie zonder DP. In ons voorbeeld is f de eigenlijke SQL query die door een database management systeem wordt beantwoord. De gevoeligheid van een functie wordt voorgesteld door s. De gevoeligheid geeft ons een indicatie hoe gevoelig functies zijn wanneer datasets zich in één record verschillen. De gevoeligheid van een telfunctie is telkens één, want het aanpassen van één record levert ten hoogste een verschil van één op—je telt er ten hoogste één meer of ten hoogste één minder op. Tot slot geeft Lap een steekproef terug gebruikmakende van een Laplaceverdeling met verschuiving 0 en schaal s/ε.

In Figuur 4 ziet men duidelijk het effect van e. Hoe groter ε, hoe groter de kans dat de waarde van F(x) meer naar de waarde van f(x) zal neigen. Bij kleinere waarden voor ε zal de kans dat resultaten verder van elkaar liggen groter worden, wat de privacy verhoogt.

Hier volgt een concreet voorbeeld. Laten we aannemen dat de functie f_b het aantal personen met een Belgische nationaliteit teruggeeft en de reële waarde van f_b(x) gelijk is aan 5. We berekenen F_b(x) met ε = 0.1, dan als volgt: 5 + Lap(1/0.1). In dit voorbeeld gebruik ik de rlaplace functie uit R’s rmutil bibliotheek om een steekproef te genereren.

> library("rmutil")
> rlaplace(1, 0, 1 / 0.1)
[1] -0.5499616

Het eerste argument is het aantal waarden dat ik wil genereren; we hebben er maar één nodig. Het tweede argument is de verschuiving; hier altijd nul. En het laatste argument is de schaal. Als we dit aan 5 optellen, dan hebben we als resultaat F_b(x) = 4.4500384. We hebben nu ruis in de waarde geïntroduceerd. Was de reële waarde 4 en werd een waarde toegevoegd? Of was de reële waarde 5 en werd een waarde afgetrokken? Een tegenstander kan dit niet achterhalen. Een decimale waarde voor een telfunctie houdt natuurlijk geen steek. Later zien we dat enige verfijning, zoals het afronden van waarden, geen effect heeft—de ε-DP voorwaarde blijft behouden.

We hebben een mechanisme voor een telfunctie toegelicht. Er bestaan ook mechanismen voor, onder andere, histogrammen, het kruisen van informatie, en statistische benaderingen (steekproeven, aggregaties, gemiddelden, etc.). Deze zullen we hier niet toelichten.

DP vormt het basisprincipe, en er bestaan reeds een aantal varianten en uitbreidingen op dit principe. DP is “streng” en varianten zullen doorgaans aspecten van DP verzwakken, zoals Approximate DP, in ruil voor meer flexibiliteit en efficiëntie.

Privacy loss en privacy budgetten beheren—de “boekhouding”

Wat als een onderzoeker meerdere vragen stelt? Het is waar dat de garantie dat privacy gevrijwaard wordt daalt naarmate meer vragen worden gesteld. DP laat echter toe hier een stokje voor te steken. De formeel bewezen eigenschappen van compositie (i.e., het combineren van vragen) helpen ons om de totale kost van (een reeks van) bevragingen te berekenen.

De sequentiële compositie toont aan dat als F₁ voldoet aan ε₁-DP, en F₂ voldoet aan ε₂-DP, dan voldoet het mechanisme F₃(x)=(F₁(x), F₂(x)) aan ε₁₊ε₂-DP. Zo bestaan er andere composities (parallel, geavanceerd, etc.) die hier buiten beschouwing worden gelaten. Belangrijk is dat we met composities van de privacy parameters aan privacy “boekhouding” kunnen doen.

Eke vraag heeft dus een (privacy) kost, en men kan de totale kost gebruiken om op een bepaald moment geen antwoord meer te bieden aan een reeks vragen, of zelfs onderzoekers een totaal budget aan te bieden waarmee ze dan (zorgvuldig) aan de slag gaan. Hoe dit effectief in zijn werk gaat en hoe de budgetten naderhand bijgevuld worden hangen af van de use case.

Post-processing

We hebben reeds aangehaald dat het, zonder kennis van de originele database, niet mogelijk is om met post-processing de privacy loss op te krikken. Met andere woorden, elke aanpassing of wijziging aan een dataset die aan DP met een waarde voor ε voldoen, garandeert dus ook DP met dezelfde ε. Dit is een belangrijke en bewezen eigenschap van DP dat DP zo aantrekkelijk maakt.

Onder post-processing verstaan we niet alleen de manipulaties door een onderzoeker (of tegenstander), maar ook de post-processing net voor het aanleveren van de data. De ruis, geïntroduceerd door een mechanisme, kan waarden opleveren die niet stroken met de realiteit. Voorbeelden zijn decimale en negatieve waarden bij telfuncties. Het is dus perfect OK om een dataset nadien te verfijnen om dergelijke “datakwaliteitsproblemen” aan te pakken. Het verfijnen van een dataset (zoals het afronden en elimineren van negatieve waarden waar nodig) hoort ook tot post-processing.

Aan de slag met DP

DP heeft een stevige wiskundige onderbouwing, doch is het interessant om weten dat maar recentelijk de industrie en de gemeenschap dit in grotere mate aan het oppikken is. Tot voor kort was één van de uitdagingen het bestaan van tooling (raamwerken en bibliotheken). Men moest dus beroep doen op personen met de juiste expertise (e.g., een statisticus) die data volgens DP voorwaarden leverden. Met de recente ontwikkelingen kwamen gelukkig ook een aantal open source alternatieve van grote en belangrijke spelers: onder andere Google, Facebook, Uber, en Harvard. Microsoft documenteerde hoe je Harvard’s oplossing kan gebruiken in MS Azure.

Voor dit artikel maak ik gebruik van Chorus. Chorus startte als samenwerking tussen Uber en de University of California, Berkeley. Omdat academici nu eenmaal regelmatig van instelling veranderen, wordt de code (beschikbaar met een zeer toegankelijke MIT licentie) nu onder “hoedanigheid” van de University of Vermont gehost.

Gebruikmakende van een tabel met 1001 fictieve personen (er waren geen personen met als land België aanwezig, dus heb ik er maar eentje toegevoegd), wens ik te weten hoeveel personen in België wonen, en hoeveel in (Volksrepubliek) China.

• SELECT COUNT(*) FROM person WHERE country = 'China'
• SELECT COUNT(*) FROM person WHERE country = 'Belgium'

De waarden van deze queries, alsook die met DP gebruikmakende van Chorus staan in Tabel 2. Zonder DP hebben we als reële waarden 181 en 1. Met een ε van 0.1 hebben we meer privacy, want de kans is groter dat de waarden verder van de reële waarden verwijderd zijn. Met een ε van 1 vergroten we de kans dat de waarden meer op de reële waarden lijken.

Men kan nu denken dat men met een ε = 1 met zekerheid de juiste waarden kan achterhalen door deze gewoon af te ronden, maar dat is niet correct. Zelfs als de onderzoeker (of tegenstander) weet dat ε = 1 en de kans groter is dat de waarde op de reële waarde lijkt, is de exacte waarde moeilijk te achterhalen. De ruis kan zowel positief als negatief zijn. Verder kan deze afwijking nog vrij belangrijk zijn. Ik illustreer dit met een voorbeeld in Figuur 5.

De kans op eenzelfde antwoord (bij het bevragen van dezelfde query) is dus ook klein. Dit illustreer ik nogmaals in Figuur 6 (onderaan), waar we voor ε = 1 nu de waarden 181.182 en 3.369 voor onze tel-queries hebben.

Het opzetten en gebruiken van Chorus was best eenvoudig. Het systeem ondersteunt standaard simpele queries—queries die maar één waarde teruggeven. Dit omdat queries die meerdere waarden teruggeven (bijvoorbeeld een histogram of een GROUP BY) meer aandacht vergen. Voeren we een GROUP BY op namen uit, dan lekken we de namen in de database! Dit vergt dus manueel nazicht.

DP toepassen op onderstaande histogram query vormt geen probleem, want we tonen enkel landsnamen en hun aantallen. Gaat dan, voor elk land, de privacy cost omhoog? Neen. Dergelijke histogrammen voldoen aan parallelle compositie, waardoor de kost dezelfde blijft. De reden waarom dit geldt is, zéér kort samengevat, dat elk individu in de dataset maar één keer geteld wordt.

• SELECT country, COUNT(*) FROM person GROUP BY country

Chorus biedt een oplossing aan om SQL queries, in de achtergrond, te herschrijven naar queries met ruis. Ook biedt het een zogenaamde accountant aan die de kost van een reeks queries berekent. Hoe je die kost gebruikt, wordt niet door Chorus voorgeschreven. Ook dit hangt van af van de use case.

Uitdagingen en opportuniteiten

Veruit de grootste uitdaging van DP is de kennis en expertise die men nodig heeft om DP op een correcte manier toe te passen. Niet alleen kennis van DP (de wiskundige grondslag), maar ook domeinkennis is nodig. Domeinkennis is nodig om, voor bepaalde mechanismen, doordachte beslissingen over de data te nemen zoals het bepalen van boven- en ondergrenzen voor bepaalde attributen. De aanwezigheid van uitschieters geeft informatie over de dataset, maar kan ook de ruis vertekenen. Computerwetenschappers (of statistici) moeten hieromtrent met business analisten samenwerken, dus.

DP werd ook toegespitst voor zeer specifieke doeleinden (gaande van specifieke toepassingen zoals het voorspellen van emoji’s tot specifieke taken zoals DP in leeralgoritmen). Dit maakt het voor buitenstaanders soms moeilijk om DP naar andere use cases te transponeren.

Daartegen staat dat, dankzij de solide wiskundige onderbouwing, het ook duidelijk is welke bevragingen “makkelijk” zijn, en welke op een doordachte manier moeten gebeuren. Eenvoudige queries die 1 waarde teruggeven, zoals onze tel-queries bijvoorbeeld, kunnen zonder problemen automatisch uitgevoerd worden. Het genereren van histogrammen vergt menselijke input (de query, code en parameters moeten uitgeschreven worden), én nazicht. In eenvoudige gevallen kan men dit “omzeilen” door onderstaande histogram

• SELECT country, COUNT(*) FROM person GROUP BY country

te herschrijven naar:

• SELECT COUNT(*) FROM person WHERE country = 'Belgium'
• SELECT COUNT(*) FROM person WHERE country = 'France'
• SELECT COUNT(*) FROM person WHERE country = 'Germany'
• …

Doch verhogen we in het tweede scenario onnodig de privacy cost, want voor histogrammen blijft de kost, vanwege de parallelle compositie, gelijk. De boodschap hier is dat de drempel voor DP laag kan zijn.

De tweede uitdaging is de beschikbare tooling. Tot voor kort werd DP door experten toegepast. Er bestaan commerciële toepassingen voor machine learning en data analytics waarin DP werd  geïntegreerd, maar niet iedereen is op zoek naar dergelijke oplossingen of klaar om naar een nieuwe toepassing over te schakelen. Organisaties wensen vaak ook hun bestaande systemen te behouden. Men kan DP toepassen in Python, R,… door de datamanipulatie en formules zelf neer te pennen, maar gelukkig verschijnt er alsmaar meer robuuste vrije software (aangeleverd door de voorgenoemde grote spelers). Men kan twee soorten initiatieven onderscheiden: “wrappers” die men bovenop bestaande databases kan plaatsen, zoals Chorus; en bibliotheken met abstracties en primitieven om DP in big data en data analytics omgevingen toe te passen, zoals Google’s Privacy on Beam.

Conclusies

Differential Privacy (DP) is een techniek om de privacy van personen te vrijwaren door een welbepaalde ruis in datasets en antwoorden van bevragingen te introduceren. De antwoorden op die bevragingen alsook de statistische eigenschappen van de dataset blijven grosso modo onveranderd en men krijgt nooit de originele data te zien. De aanwezigheid van de gegevens van een persoon heeft dus geen (grote) impact op de conclusies die men kan trekken.

DP introduceert ook concepten zoals privacy cost en privacy budget. Men kan met een bepaald budget een of meerdere bevragingen uitvoeren. Elke bevraging heeft een kost en men mag het budget niet overschrijden. Wenst men dat de resultaten dichter bij de reële waarden komen, dan moet men meer uit het budget gebruiken. Dit gaat dan ten koste van het aantal (grote) queries die men in een sessie kan stellen. Hoelang sessies duren, hoe snel men een budget terug kan opbouwen, enz. hangt af van de use case. Dit brengt ons naar het volgende punt.

Vanwege de complexe materie is enige kennis in DP én domeinkennis voor complexe vragen vereist. Voor eenvoudige vragen kan men DP zo goed als volledig automatisch toepassen. Computerwetenschappers, statistici, en bedrijfsanalisten moeten in het proces betrokken worden.

Hoewel het concept in 2006 werd geïntroduceerd, is het maar sinds kort dat tal van initiatieven opduiken. Dankzij de wetenschappelijke gemeenschap, de open source community, en belangrijke IT spelers die hun tooling vrij voorhanden maken, wordt de drempel om DP toe te passen lager.

Referenties

Dwork, Cynthia, Frank McSherry, Kobbi Nissim, and Adam Smith. 2006. “Calibrating Noise to Sensitivity in Private Data Analysis.” In Theory of Cryptography, eds. Shai Halevi and Tal Rabin. Berlin, Heidelberg: Springer Berlin Heidelberg, 265–84.

Johnson, Noah M, Joseph P Near, Joseph M Hellerstein, and Dawn Song. 2020. “Chorus: A Programming Framework for Building Scalable Differential Privacy Mechanisms.” In IEEE European Symposium on Security and Privacy, EuroS&P 2020, Genoa, Italy, September 7-11, 2020, IEEE, 535–51. https://doi.org/10.1109/EuroSP48549.2020.00041.

Voetnoten

[1] In de context van GDPR hebben “geanonimiseerd” en “pseudo-geanonimiseerd” (ofte “pseudonimisatie”) verschillende betekenissen. Het eerste gaat over data waar het herleiden van gegevens tot een natuurlijk persoon onmogelijk is. Het tweede betreft data waar men met behulp van extra gegevens (op een indirecte manier) informatie naar een natuurlijk persoon kan herleiden.

[2] Soms ook privacy-budget genoemd, dit hangt af van het gebruik (zie later).

Foto’s

Foto’s verwerkt in de illustraties zijn CC0 (via https://www.pexels.com/).

_________________________

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