Introductie
In deze story staat een korte introductie over linked data. Vervolgens gaat deze verder in op het datamodel wat ontwikkeld is voor de Proof of Value (PoV) opstelling voor het Research Center van Alliander.
Voor meer detail over linked data en ook introductie voor ontwikkelaars, kijk ook eens naar de uitstekende introductie bij het Kadaster. Deze story is specifiek voor de PoV bij Alliander.
Linked Data
Vaak wordt er binnen organisaties gebruik gemaakt van tabulaire data. Deze data is dan opgeslagen in cellen in rijen en kolommen. Bij Linked data gaat dat een beetje anders en slaat de data op in de vorm van "Triples". Een triple beschrijft een data-feit welke bestaat uit een subject, predicaat en een object. Het is een verbintenis van twee objecten (het subject en het object) met een relatie daartussen (het predicaat). Op deze manier bouw je een netwerk van relaties tussen klassen om zo een graaf structuur te beschrijven.
Hieronder staat een voorbeeld triple:
De informatie die je ziet afgebeeld is nu misschien nog een beetje cryptisch, maar zometeen wordt dat duidelijker.
Zoals je ziet bevat de triple twee nodes en een edge. De nodes kunnen van alles zijn, netzoals data alles kan beschrijven. De relatie tussen de nodes heeft ook een waarde. Hij beschrijft de semantische koppeling tussen de twee nodes. Dat kan heel veel lading hebben (een complexe definitie tussen een relatie) of heel simpel zijn ("is van het type").
Ook de nodes kunnen semantisch worden beschreven. Een van de krachtigste eigenschappen van linked data is dat de metadata op dezelfde manier wordt opgeslagen: ook middels triples. Op deze manier kun je de data samen beschrijven met de betekenis van die data; semantisch rijk.
Hieronder zie je dezelfde triple als erboven, maar dan ook met de modeldefinities eraan gekoppeld. Merk op dat dit ook triples zijn.
Zoals je ziet is er nu veel meer informatie afgebeeld over de data. Zo wordt duidelijk dat een "liander:GeenTransportbeperking" een bijbehorende opmerking heeft (rdfs:comment) met daarbij textuele uitleg. Ook zie je dat de "GeenTransportbeperking" dus een type is van "liander:TransportBeperking". Het is dus een mate van beperking. De objecten die beginnen met "liander:" komen uit het model van deze PoV. De node met nummer "396" komt uit de begrippenlijst van Liander. Deze heeft dus een andere definitie, maar deze komt sematisch overeen met die van deze PoV. Daarom zijn ze in dit geval gekoppeld als zijnde dezelfde definitie (owl:sameAs).
Zoals je ziet kun je op deze manier een heel netwerk bouwen van klassen met hun definities en relaties.
Hergebruik van standaarden
Linked data bestaat dus uit triples en worden semantisch beschreven. Deze manier van modeleren verschilt in feite nog niet veel van traditionele data modelering. Ook in de tabulaire wereld worden tabellen goed beschreven met metadata om toch wijs te worden van soms cryptische kolomnamen. Het is alleen wel ingewikkeld om deze data gemakkelijk te delen en te koppelen met andere datasets. Het helpt om de data conform dezelfde "taal" te beschrijven om verwarring te voorkomen. Als twee partijen data willen delen en ze nemen elk hun eigen definities over die data mee, dan is samenwerken moeilijk. "Betekent dit dataveld killowattuur (kWh) of wattuur?", "Heeft deze transformator 1 functie of meerdere?", "Wat verstaan we eigenlijk onder een transformator?". Door een "ontologie" te gebruiken waar partners het over eens zijn, wordt de samenwerking ineens veel gemakkelijker. De data staat meteen op dezelfde eenduidige manier semantisch rijk beschreven.
Eigen ontologie of industriestandaard?
Het loont dus om een standaard te gebruiken. Echter de standaarden komen ook in alle soorten en smaken. Sommige standaarden zijn heel generiek opgesteld en kunnen vrijwel alles omvatten. Andere zijn voor een niche en zijn slecht te generaliseren. Zo ook zijn er standaarden die overleven door veel gebruik (goede adoptie) terwijl ze misschien niet de beste zijn. Hoe kies je nu een goede standaard? Dit is een lastige vraag en is niet altijd gemakkelijk te beantwoorden. De voor en nadelen dienen door de data governance in de organisatie te worden afgewogen. Over het algemeen is het verstandig om een standaard te kiezen die een groot deel van het domein al beschrijft en de missende elementen zelf, of met een domein specifiek team toe te voegen.
Common Information Model (CIM)
In deze PoV is gekozen om zo veel mogelijk te modeleren naar de CIM standaard. Deze standaard beschrijft heel veel klassen uit het energie domein. Nu heeft Liander natuurlijk ook data die gaat over gas. Daarvoor gebruiken we een extentie op CIM die voortkomt uit het Cerise project. Echter voor alle informatie die we nu modeleren en niet onder CIM kunnen passen defineren we onze eigen klassen en relaties. In het specifiek maken we gebruik van de ontologie die het TNO heeft ontwikkeld. Dit is een linked data vorm van de CIM standaard. Deze is te vinden op de ontologie pagina van het TNO.
Het model bekijken
Het model is beschikbaar via een HTML interface op de website van het TNO. Daar kun je door de klassen heen lopen om de definities op te halen en de relaties te onderzoeken.<img src=https://ontology.tno.nl/cerise/cim-profile/diagrams/cim_BaseReading.jpg>
Ook is het mogelijk de ontologie in software te laden zoals Protege om op die manier de data te bekijken. Ook zijn er visuele tools beschikbaar zoals WebVowl om een visuele weergave van het model te bekijken.
<img src=https://iamlabdemo.triply.cc/Alliander/Open-datasets/assets/64061235fbfa3f7c64e35ffe>
Ik zit in een standaard... en nu?
Er is natuurlijk geen standaard die alles beschrijft. Er zijn altijd verschillende eisen ook aan een ontologie. Sommige zijn gericht op het logistieke process over domeinen heen, andere zijn heel uitgebreid op een specifiek onderwerp. Het hangt dus ook zeker van de wensen af van de organisatie welke ontologie op welk niveau wordt gebruikt. Het is namelijk erg gemakkelijk om verschillende ontologieen gezamenlijk met elkaar te gebruiken. Zo kun je de data gebruiken (semantisch rijk beschreven) vanuit een andere ontologie door deze aan je eigen data te koppelen.
Hieronder zie je een voorbeeld. De data die hier wordt gebruikt is van Liander, het Kadaster en de energielabels van het RVO. Deze zijn aan elkaar gekoppeld middels linked data en de ontologie van het Kadaster en de ontologie van Liander (van deze PoV: gebaseerd op CIM).
In het midden zie je een node met een postcode. Dit is een datapunt wat het postcode gebied beschrijft. Binnen deze postcode zijn "Standaard Jaarverbuik" metingen beschikbaar. Dit zijn gemiddelde verbruikwaarden van gas en elektriciteit van al het kleinverbruik binnen dit postcode gebied. Van deze metingen zijn aansluitigsgegevens beschikbaar zoals het type aansluiting. Maar binnen dit postcodegebied is ook gegevens van de panden en verblijfsobjecten. Deze gegevens komen vanuit het Kadster. Door te koppelen via de postcode kunnen we de gegevens van deze verblijfsobjecten rechtstreeks bij het Kadaster ophalen. De data is dus daar opgeslagen en wordt bij het uitvoeren van de query opgehaald.
Conclusie
We zijn dus in staat geweest om informatie te koppelen van veel verschillende partijen zonder heel veel werk te hoeven doen om deze aan elkaar te linken. Doordat ze op deze manier zijn gemodeleerd en een duidelijke zelfde taal spreken is het gemakkelijk om de informatie op te halen op het moment van bevragen. De andere partijen (Kadaster in dit voorbeeld) hebben alleen hun data aan het publiek open gesteld via Linked Data, en dat stelt andere partijen (of burgers) in staat om deze gemakkelijk te bevragen en hun eigen analyses uit te voeren. Er zijn geen verdere dataconversies meer nodig. Omdat we over dezelfde semantische deler spreken (een verblijfsobject) kunnen we zonder vertaling informatie ophalen.