Introductie

Deze Data Story bevat een introductie over de techniek en toepassingen van Linked Data. De focus ligt in deze story op het geven van een eerste introductie in Linked Data, en is dus voornamelijk bedoeld voor een lezer die nog niet eerder met deze techniek in aanraking is gekomen.

We beginnen bij de basis van een triple en bouwen dit op naar een kennisgraaf. Ook besteden we aandacht aan het vastleggen van definities en het gebruik van externe standaarden. In deze story zijn de voorbeelden gemaakt met behulp van het datamodel dat voor de Proof of Value van EDSN is gebruikt. We laten zien hoe dit is opgebouwd en laten voorbeelden zien van hoe de data eruit ziet.

Linked Data

Data wordt traditioneel vaak opgeslagen in de vorm van een tabel met rijen en kolommen.

In Linked Data wordt deze manier van data opslaan vervangen door een andere: het opslaan van data in de vorm van triples . Een triple bestaat, zoals de naam suggereert, uit drie delen. Deze delen zijn het subject, predicaat en object. Een voorbeeld van zo een triple is de volgende:

werknemer (subject) - heeftNaam (predicaat) - naam (object)

Als deze triple wordt ingevuld met data, kan dit er bijvoorbeeld als volgt uitzien:

12340000 (subject) - heeftNaam (predicaat) - Alex (object)

In het voorbeeld hieronder zie je een andere triple afgebeeld in de vorm van een netwerk. De triple laat wederom drie delen zien. Het subject is een specifieke postcode, het predikaat is bijvoorbeeld de opwekcapaciteit, en het object is de kleur die hoort bij die capaciteit. De drie delen van de triple worden weergegeven in een graaf als 2 nodes (de bolletjes) en een edge (de lijn tussen de bolletjes). Het subject en het object van de triple worden weergegeven aan de hand van de nodes en aan elkaar verbonden via edge die het predikaat weergeeft. De pijl wijst naar het object.

Je ziet dat deze termen soms worden voorgegaan door een term en een dubbele punt, zoals edsn-id:Postcode_1011AA. Deze termen worden prefixes genoemd, en ze geven aan uit welke dataset het subject, predikaat of object afkomstig is. Een prefix is een synoniem voor een URL die ervoor zorgt dat de data leesbaarder wordt. Door de combinatie van deze URL met de term krijgen we een URI (Uniform Resource Identifiers), een unieke verwijzing naar dit object.

Onthoud dit:

• Termen worden opgeslagen als URIs
• Relaties worden opgeslagen als triples

Deze triple is gegenereerd aan de hand van een SPARQL query. Om de achterliggende SPARQL query te zien, kan je kiezen voor TRY THIS QUERY YOURSELF.

Predikaten in het model

Met behulp van deze triples kan data gemakkelijk gemodelleerd worden. De onderstaande query geeft een wat uitgebreider voorbeeld weer, waarin alle predikaten die gelinkt zijn aan edsn-id:Postcode_1011AA zichtbaar zijn.

Je ziet dat dit subject een predikaat heeft ck:postcode met als object een Literal (in dit geval een string) die de daadwerkelijke postcode bevat. Een Literal is herkenbaar aan het grijze bolletje.

Daarnaast zijn er nog twee predikaten: ck:demand_constraint en ck:generation_constraint. We zullen later zien wat de definities zijn van deze predikaten. De objects van deze predikaten zijn beschreven als een andere Class, herkenbaar aan het paarse bolletje. In dit geval de Class RAGkind, met als mogelijke waardes ck:RAGkind.Amber en ck:RAGkind.Transparant.

Definities in het model

In de voorgaande voorbeelden hebben we al meerdere prefixes gezien. Eerder hebben we verteld dat prefixes beschrijven uit welke dataset het subject, predikaat of object afkomstig is.

Wij gebruiken twee verschillende datasets die omschreven zijn met de volgende prefixes:

• edsn-id: staat voor de instantiedata afkomstig van EDSN
• ck: staat voor het kennismodel van de capaciteitskaart Netbeheer Nederland.

Daarnaast zijn er veel externe standaarden met eigen prefixes, daarover later meer.

In het voorgaande voorbeeld zagen we de predikaten ck:demand_constraint en ck:generation_constraint. Het is echter niet meteen duidelijk wat deze termen betekenen. Gelukkig worden deze termen in het kennismodel beschreven en kunnen we ze samen met de data opvragen.

Definities worden in het kennismodel vastgelegd met het predikaat skos:definition, een algemeen gebruikte manier om definities vast te leggen.

In de netwerk visualisatie zien we de blauwe node als instantiedata, de paarse als Classes en de grijze als Literals. Omdat in een netwerk visualisatie de tekstvelden worden ingekort kunnen we deze ook tonen in een tabelvorm waar wel de hele tekst zichtbaar is. Dit voorbeeld staat eronder.

Kennismodel

Het voorbeeld van dit PostcodeArea item is onderdeel van een veel groter kennismodel. Het volgt de architectuur van het schema van de capaciteitskaart van Netbeheer Nederland, hier beschreven: https://netbeheer-nederland.github.io/im-capaciteitskaart/

In de onderstaande visualisatie is te zien hoe dit schema is verwerkt tot een Linked Data netwerk. Hierbij is te zien dat vanuit de Class ck:Substation meerdere predikaten verbinden naar andere Classes en naar Literals. Deze literals zijn bijvoorbeeld float, integer of string. Hier te herkennen aan een lichtblauwe node. En zo is verder te zien dat onder Substation via de predikaten ck:postcode_areas, ck:worksen ck:operators weer andere classes hangen, respectievelijk ck:PostcodeArea, ck:Work en ck:DistributionSystemOperator.

Voor ck:PostcodeArea en ck:Work gaat de hiërarchie nog een stapje verder en herkennen we de predikaten ck:demand_constraint en ck:generation_constraint uit de vorige voorbeelden. Onder een ck:Work vallen nog weer de predikaten ck:work_order_number en ck:request_date_time.

Is het je al opgevallen dat Classes starten met een hoofdletter en properties met een kleine letter?

Externe standaarden

Alle definities die hierboven zijn getoond zijn opgenomen in het kennismodel van de capaciteitskaart. Echter, er zijn vaak ook al definities beschikbaar via externe standaarden. In de wereld van de energie is CIM daarvan een bekend voorbeeld. Ook CIM heeft in Linked Data formaat definities vastgelegd en gebruikt daarvoor de URL https://ontology.tno.nl/IEC_CIM/# met als prefix cim:.

In ons kennismodel is geprobeerd deze externe vastgelegde definities te koppelen aan onze Classes. Dat is gedaan door met de predikaten skos:exactMatch of skos:broadMatch te linken naar een object wat vergelijkbaar is. Deze URI's zijn vaak gepubliceerd op het internet en dus kan daar de definitie opgehaald worden. Probeer maar eens te checken of de definities hetzelfde zijn.

Naast CIM zijn er nog twee externe standaarden gebruikt in het kennismodel, namelijk van netbeheer nederland onder de prefix nbnl: en ter illustratie ook de definitie van een postcode onder de prefix sor:. Beide zijn ook vindbaar via het internet, probeer maar uit.

Visualisaties

Er zijn in deze data story meerdere query resultaten afgebeeld: aan de hand van een graaf representatie en aan de hand van een tabel.

Dit zijn slechts twee van de mogelijke visualisaties die gebruikt kunnen worden om Linked Data weer te geven. Om te laten zien dat je ook statistische weergaves van je data kan laten zien, staat hieronder een voorbeeld van een staafdiagram. Er wordt bevraagd hoeveel voedingsgebieden er per netbeheerder in de data aanwezig zijn.

Via de knop TRY THIS QUERY YOURSELF kan je de query aanpassen om in plaats van aantal voedingsgebieden per netbeheerder het aantal postcodes per netbeheerder in een staafdiagram te tonen.

Conclusie

In deze story is toegelicht hoe Linked Data eruit ziet in de vorm van triples en een kennisgraaf. Er zijn visualisaties getoond in de vorm van een netwerk, een tabel en ook via een diagram.

Er is dieper in gegaan op hoe de data eruit ziet die gebruikt is voor de PoV van EDSN en hoe de definities hiervan zijn beschreven in het kennismodel. Er is zoveel mogelijk gebruik gemaakt van de kennis van de capaciteitskaart via https://netbeheer-nederland.github.io/im-capaciteitskaart/ en externe definities van CIM, NBNL en SOR. Doordat ze op deze manier zijn gemodelleerd en een duidelijke zelfde taal spreken is het gemakkelijk om de informatie op te halen op het moment van bevragen.