Linked Open Data - Part 1 The Foundation and Context – What is semantic data and how does it work behind the scenes?
At Svenska kraftnät, we are proud to present a major milestone in the evolution of our open data platform (Svenska kraftnät Data Service). Behind the scenes, we have implemented full support for Linked Open Data. This means our data is no longer just machine-readable – it is now also machine-understandable, semantically interconnected, and ready to be seamlessly integrated into global data transmission networks
In this three-part article series (and an extra part on DCAT), we will dive into how we have transformed our data platform:
-
Part 1: The Foundation and Context – What is semantic data and how does it work behind the scenes? (This post)
-
Part 2: Ontologies and Code Lists in Practice – How we model the unique concepts of the power system. Link.
-
Part 3: From JSON to Knowledge Graph – A deep dive into the technology, API responses, and how to consume the data. Link.
-
Part 4: From Local Catalog to Europe – How our data is harvested and discoverable across borders. Link.
Why are traditional APIs and tables no longer enough?
Traditional open data is often published as isolated islands. You download a CSV file or call a REST API, and you get a JSON response containing columns or keys like bidding_zone, reserve_product, or volume.
For a human developer, it is usually possible to guess what these mean. But to a machine, "bidding_zone": "SE1" is just a text string. The machine does not know that SE1 represents the geographical bidding zone in northen Sweden, what unique rules apply there, or how it relates to the wider European synchronous area.
When data lacks an inherent, globally unique definition, "data silos" are created. Integrations then require extensive manual mapping, and the risk of misunderstandings between different systems is high.
The Solution: Linked Open Data
By introducing Linked Open Data, we assign a global, unique identifier to every single data point in the form of a URI (Web address). When data has a URI, machines can follow links between different data sources – in exactly the same way you click links between different web pages.
For our new platform, this means we have developed a formal description of our domain. We have built:
-
Our own ontologies: Formal data models (within namespaces such as
https://data.svk.se/ontology/emdo#for electricity market data andbase#for core time series) that define exactly what a data point is, its data types, and how they relate to one another. -
Standardised code lists: Controlled vocabularies (e.g., for bidding zones and reserve products) where each concept (such as
aFRRCapacityMarketorSE2) has its own unique URI, enriched with metadata and multilingual labels.
Behind the Scenes: How we link tabular data (CSVW)
Many of our large datasets – such as procured volumes and prices on the capacity markets – are fundamentally delivered as tables (data tables in our data warehouse). To make this data linked without sacrificing the performance of traditional databases, we use the W3C standard CSV on the Web (CSVW).
This means that when you perform a query in our API, you do not just receive the raw data records. You also get a comprehensive schema directly within the API response or via a linked metadata file.
This schema maps the technical column names to our ontologies:
-
The column
reserve_directionis no longer just a text string. It is formally defined by the propertyhttps://data.svk.se/ontology/emdo#hasReserveDirectionand points directly into our controlled code list for reserve directions. -
Each unique row in the table is assigned a unique URI, a so-called graph address (e.g., based on a unique
soda_hashbyte), allowing the entire row to be transformed into a component of a global knowledge graph (RDF). -
Example of a global, unique identifier to a specific record:
data.svk.se/sv/dataset/fcr_activated_energy/resource/c0a75ee4-2cf3-43f2-9168-2c8627aef0ef/graph/1be63634863f9d6e8fa047390f7e1ff4
What does this mean for you as a user?
For the regular visitor to our portal, everything runs as usual – only faster and more stable. But for system architects, developers, data scientists, or analysts, this opens up entirely new possibilities:
-
No more guesswork: The API responses are self-describing. Want to know exactly what we mean by
volumeorstart_time_utc? The machine can look up the definition in the ontology in real time. -
Multilingualism directly in the metadata: Our ontologies contain explanations and labels in both Swedish and English directly within the definitions.
-
Ready for AI and semantic queries: Data can be loaded straight into graph databases (Triplestores) and queried using SPARQL, or correlated with energy data from other European Transmission System Operators (TSOs) utilizing similar standards.
Next up in the series
We have laid the foundation for a semantic energy data network. In our next blog post, we will take a closer look at our ontologies. We will demonstrate how we have modelled concepts like CapacityMarketObservation and how our code lists for price units and bidding zones are structured to ensure maximum interoperability.