Skip to content

Öppen Länkad Data - Del 2 Ontologier och kodlistor i praktiken – Hur vi modellerar kraftsystemets unika begrepp

10 juni 2026

Artikelserie om Öppen Länkad Data:
Del 1: Grunden och sammanhanget – Länk.
Del 2: Ontologier och kodlistor i praktiken – Länk.
Del 3: Från JSON till kunskapsgraf – Länk.
Del 4: Från lokal katalog till Europa – Länk.

I vårt första inlägg introducerade vi konceptet Öppen Länkad Data och hur vi på Svenska kraftnät använder det för att göra vår öppna data maskinförståelig. Men hur översätter man egentligen ett komplext, fysiskt kraftsystem och dess finansiella marknader till en digital datamodell? Svaret ligger i att skapa egna ontologier och kontrollerade kodlistor.

När vi byggde vår nya plattform, Svenska kraftnät Data Service, insåg vi snabbt att existerande globala standarder behövde kompletteras. Kraftsystemet rör sig snabbt, och begrepp som "avropad kapacitet för aFRR" eller specifika nordiska elområden kräver en exakt definition för att inte misstolkas av externa system och aktörer på marknaden.

Vad är en ontologi i datasammanhang?

Enkelt uttryckt är en ontologi en formell, digital ordlista som beskriver en specifik domän. Den talar om vilka typer av saker som finns (klasser), vilka egenskaper dessa saker har (properties), och hur de relaterar till varandra.

Ontologierna och kodlistor återfinns med särskilda beskrivningar här. 

För vår öppna data har vi etablerat två huvudsakliga namnrymder (namespaces) för våra ontologier:

  1. Base-ontologin (https://data.svk.se/ontology/base#) Denna hanterar de generella byggstenarna för tidsserier. Här definierar vi universella begrepp som validFromDateTime (starttid i UTC) och hur ett pris kopplas till en specifik valuta eller enhet (hasPricePerUnit).

  2. Elmarknadsontologin (https://data.svk.se/ontology/emdo#) Detta är vår domänspecifika ontologi för elmarknaden (Electricity Market Data Ontology). Det är här vi definierar vad en CapacityMarketObservation (en observation på kapacitetsmarknaden) faktiskt innehåller.

Genom att använda dessa ontologier blir varje kolumn i våra datatabeller semantiskt definierad. När vårt API skickar med fältet volume, berättar schemat samtidigt att detta fält motsvarar egenskapen emdo:procuredCapacityValue. En maskin kan då följa länken och läsa ut den formella definitionen: "Det numeriska värde som representerar upphandlad effekt för en viss observation."

Kontrollerade kodlistor: Att ge strängar en global adress

Ett av de vanligaste problemen med traditionella API:er är variationer i textsträngar. Skriver en utvecklare SE1, Se1 eller Sverige Elområde 1? För en maskin är detta tre helt olika saker.

För att lösa detta har vi byggt kontrollerade kodlistor (vokabulärer) baserade på W3C-standarden SKOS (Simple Knowledge Organization System). Varje unikt begrepp får en permanent webbadress (URI).

I praktiken innebär det att i stället för att bara returnera texten "SE2", mappar vår plattform detta till en specifik resurs: https://data.svk.se/ontology/codelist/biddingzone#SE2

När en maskin (eller en utvecklare) besöker den URL:en möts de av strukturerad metadata som talar om:

  • Etikett (Label): Att det på svenska heter "Elområde 2" och på engelska "Bidding Zone SE2".

  • Sammanhang: Att det tillhör kodlistan för elområden (biddingZoneScheme).

Vi har skapat motsvarande kodlistor för:

  • Reservprodukter: T.ex. aFRRCapacityMarket, mFRR och FCR.

  • Reservriktningar: up (upp reglering) och down (ned reglering).

  • Enheter: Både för valuta/effekt (EUR-MW) och ren effektenhet (MW).

Varför detta skapar semantisk interoperabilitet

Genom att separera data (siffrorna och värdena) från definitionerna (ontologierna och kodlistorna) uppnår vi tre stora fördelar:

  • Smidigare harmonisering: Om det sker regeländringar på den europeiska elmarknaden uppdaterar vi definitionen i ontologin eller kodlistan en gång. Alla historiska och framtida datapunkter som länkar till den resursen ärver automatiskt den nya, korrekta betydelsen.

  • Länkbart med Europa: Eftersom våra ontologier bygger på webbstandarder (RDF/OWL), kan de i framtiden enkelt giftas samman med europeiska standarder som CIM (Common Information Model) eller data från ENTSO-E.

  • Flerspråkighet utan datadubblering: API-svaret innehåller bara de korta tekniska nycklarna, men eftersom kodlistorna är flerspråkiga kan ditt system automatiskt översätta gränssnittet till engelska eller svenska baserat på metadatan.

Nästa del: Hur ser det ut i praktiken?

Nu när vi har koll på teorin bakom ontologier och kodlistor är det dags att titta på den tekniska implementationen. I nästa del av serien gör vi en djupdykning i vårt API. Vi visar exakt hur ett JSON-svar från Svenska kraftnät Data Service ser ut under huven, hur CSVW-schemat fungerar, och hur du som utvecklare kan transformera våra tabeller till en rik kunskapsgraf.