Skip to content

Linked Open Data - Part 3 From JSON to Knowledge Graph – A Deep Dive into the Technology and API Responses

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.

Welcome to the third part of our series on how Svenska kraftnät Data Service introduces Linked Open Data. We have discussed the theory and how we model the power system using ontologies. Now, it is time to roll up our sleeves and look at the source code. What does an API response look like under the hood, and how do you transform our tables into a living knowledge graph?

When you query our platform via our Datastore API (for example, to fetch prices and volumes from the aFRR capacity market), you receive a JSON response. However, unlike traditional APIs, this response contains a hidden superpower: an embedded semantic structure.

The Anatomy of a Smart API Response

Let us look at a real-world example of what a snippet from our API response looks like. When you request market data, you receive an object containing three critical components: records (the raw data), fields (technical data types), and schema (the semantic map).

A simplified response looks like this:

{
  "success": true,
  "result": {
    "resource_id": "6351d2cc-1657-43eb-b112-b8408c700529",
    "records": [
      {
        "_id": 1,
        "start_time_utc": "2022-06-14T10:00:00",
        "bidding_zone": "SE2",
        "reserve_product": "aFRRCapacityMarket",
        "price": 50.0,
        "price_unit": "EUR-MW",
        "volume": 40.0,
        "volume_unit": "MW",
        "soda_hashbyte": "e66e16846297fa5bd772bf7fcfdc30a4"
      }
    ],
    "schema": [
      {
        "@id": "https://data.svk.se/ontology/emdo#hasBiddingZone",
        "@type": ["http://www.w3.org/2002/07/owl#ObjectProperty"],
        "http://www.w3.org/2000/01/rdf-schema#label": [{"@language": "en", "@value": "has bidding zone"}]
      }
    ]
  }
}

If you only read the records array, it looks like any standard data table. The magic happens when we overlay the CSVW schema (CSV on the Web). This metadata schema defines exactly how these flat JSON keys should be expanded into global web addresses (URIs).

How the Transformation Happens: From Table Row to RDF Triples

Linked Data is built on the principle of triples: Subject -> Predicate -> Object. Thanks to the CSVW schema published alongside the data, your application knows precisely how to translate the JSON row above into a component of a global knowledge graph.

Here are three concrete examples of how our platform instructs a machine to interpret the data:

1. The Subject (Whom is the data about?)

Each row in the table becomes a unique node in the graph. The schema defines an aboutUrl based on the row's unique identifier (soda_hashbyte):

  • Raw Data: "soda_hashbyte": "e66e16846297fa5bd772bf7fcfdc30a4"

  • Semantic URI (Subject): https://data.svk.se/dataset/afrr_capacity_market/resource/.../graph/e66e16846297fa5bd772bf7fcfdc30a4

2. The Predicate (What type of property is it?)

The key bidding_zone in the JSON response is mapped via the schema's propertyUrl directly to our electricity market ontology:

  • JSON Key: bidding_zone

  • Ontology URI (Predicate): https://data.svk.se/ontology/emdo#hasBiddingZone

3. The Object (Which value or resource is referenced?)

Instead of leaving the plain text string "SE2", the schema utilizes a valueUrl to guide the machine to the correct resource within our controlled code list:

  • Raw Data: "SE2"

  • Code List URI (Object): https://data.svk.se/ontology/codelist/biddingzone#SE2

The End Result: The Machine Sees the Graph

Once a semantic parser (or your own code) processes the API response and its associated CSVW schema, the flat JSON data is transformed into a standardized RDF format. The machine can now extract the following logical chain:

Row [e66e168] -> [has bidding zone] -> [Bidding Zone SE2 (Sundsvall)]

Row [e66e168] -> [has price unit] -> [Euro per Megawatt (EUR-MW)]

Row [e66e168] -> [has start time] -> "2022-06-14T10:00:00" (xsd:dateTime)

Furthermore, because the entire row is declared as a emdo:CapacityMarketObservation, systems immediately understand the financial and technical rules that apply to this data point.

How Can You Consume This Data Today?

The beauty of our implementation is that you do not have to refactor your existing systems.

  • For traditional integrations: You can continue reading result.records as standard JSON in your Python, Go, or C# applications.

  • For semantic integrations: You can use ready-made CSVW libraries (available in most modern programming languages) to automatically parse the API response, merge it with the metadata schema, and generate RDF (Turtle, JSON-LD, or N-Triples). This data can then be ingested directly into your internal knowledge graph or other graph database.

Series Summary

By stepping into the world of Linked Open Data, Svenska kraftnät has laid the groundwork for a more interconnected and intelligent energy sector. We have:

  1. Released data from isolated silos and provided it with a global context.

  2. Established a shared vocabulary through our custom ontologies and multilingual code lists.

  3. Implemented the W3C CSVW standard to deliver this in a high-performance manner directly through our API.

We are only at the beginning of this journey, and we look forward to seeing how you – developers, researchers, and analysts – leverage these new capabilities to build the energy solutions of tomorrow. The final part on how to discover our data catalog on other portals is the last piece of the puzzle. 

The full specification of our ontologies, code lists, and CSVW schemas is available directly on the Svenska kraftnät Data Service. Link.