Skip to content

Linked Open Data - Part 2 Ontologies and Code Lists in Practice – How We Model the Unique Concepts of the Power System

10 June 2026

Ariticle series on Linked Open Data
Part 1: The Foundation and Context – Link.
Part 2: Ontologies and Code Lists in Practice – Link.
Part 3: From JSON to Knowledge Graph – Link.
Part 4: From Local Catalog to Europe – Link.

In our previous post, we introduced the concept of Linked Open Data and how we at Svenska kraftnät use it to make our open data machine-understandable. But how do you actually translate a complex, physical power system and its financial markets into a digital data model? The answer lies in creating dedicated ontologies and controlled code lists.

When building our new platform, Svenska kraftnät Data Service, we quickly realized that existing global standards needed to be supplemented. The power system moves fast, and concepts like "procured capacity for aFRR" or specific Nordic bidding zones require precise definitions to ensure they are not misinterpreted by external systems.

What is an Ontology in the Context of Data?

Simply put, an ontology is a formal, digital dictionary that describes a specific domain. It defines the types of things that exist (classes), the attributes these things possess (properties), and how they relate to one another.

Ontologies and code lists with descriptions are located here.

For our open data, we have established two primary namespaces for our ontologies:

  1. The Base Ontology (https://data.svk.se/ontology/base#) This handles the general building blocks for time series data. Here, we define universal concepts such as validFromDateTime (start time in UTC) and how a price is linked to a specific currency or unit (hasPricePerUnit).

  2. The Electricity Market Ontology (https://data.svk.se/ontology/emdo#) This is our domain-specific ontology for the electricity market (Electricity Market Data Ontology). This is where we define what a CapacityMarketObservation actually contains.

By utilizing these ontologies, every column in our data tables becomes semantically defined. When our API delivers the field volume, the schema simultaneously explains that this field corresponds to the property emdo:procuredCapacityValue. A machine can then follow the link to read the formal definition: "The numerical value representing procured power for a given observation."

Controlled Code Lists: Giving Strings a Global Address

One of the most common issues with traditional APIs is the variation in text strings. Does a developer write SE1, Se1, or Sweden Zone 1? To a machine, these are three completely different things.

To resolve this, we have built controlled code lists (vocabularies) based on the W3C standard SKOS (Simple Knowledge Organization System). Every unique concept is assigned a permanent web address (URI).

In practice, instead of just returning the text "SE2", our platform maps this to a specific resource:

https://data.svk.se/ontology/codelist/biddingzone#SE2

When a machine (or a developer) visits that URL, they are met with structured metadata that specifies:

  • Label: That it is called "Elområde 2" in Swedish and "Bidding Zone SE2" in English.

  • Context: That it belongs to the official code list for bidding zones (biddingZoneScheme).

We have created corresponding code lists for:

  • Reserve Products: E.g., aFRRCapacityMarket, mFRR, and FCR.

  • Reserve Directions: up (upward regulation) and down (downward regulation).

  • Units: Both for price/capacity (EUR-MW) and pure power units (MW).

Why This Achieves Semantic Interoperability

By decoupling the data (the numbers and values) from the definitions (the ontologies and code lists), we achieve three major benefits:

  • Seamless Harmonization: If regulatory changes occur in the European electricity market, we update the definition within the ontology or code list once. All historical and future data points linking to that resource automatically inherit the new, correct meaning.

  • European Connectivity: Because our ontologies are built on open web standards (RDF/OWL), they can easily be interconnected in the future with European standards like CIM (Common Information Model) or data from ENTSO-E.

  • Multilingualism Without Data Duplication: The API response only needs to contain short technical keys. Since the underlying code lists are multilingual, your system can automatically localize the user interface to English or Swedish using the metadata.

Next Up: How Does It Look in Practice?

Now that we have covered the theory behind ontologies and code lists, it is time to look at the technical implementation. In the third part of this series, we will take a deep dive into our API. We will show you exactly what a JSON response from Svenska kraftnät Data Service looks like under the hood, how the CSVW schema operates, and how you as a developer can transform our tables into a rich knowledge graph.