Applied OGC RAINBOW: Creating and publishing an indicator definition

In this tutorial we will use OGC RAINBOW to create and publish a formal definition of a computed indicator — one that is derived from three distinct observable properties — and make it accessible as linked data.

The scenario

We will define and publish a Composite Drought Indicator (CDI), a well-established index used in drought monitoring and early-warning systems. The CDI is relevant to multiple Sustainable Development Goals:

• SDG 2 – Zero Hunger (food-security implications of drought)
• SDG 13 – Climate Action (drought as a climate impact)
• SDG 15 – Life on Land (vegetation and ecosystem stress)

The CDI is computed from three observable properties measured at a monitoring station:

Observable property	Description
Soil Moisture Anomaly (SMA)	Deviation of soil moisture from the long-term mean
Rainfall Anomaly (RA)	Deviation of precipitation from the climatological normal
Vegetation Condition Anomaly (VCA)	NDVI-derived measure of vegetation stress

A single computation activity takes these three observations as inputs and produces the CDI value as output. We will capture this dependency as a provenance chain — a machine-readable record of what data was used, how it was processed, and what was produced — using an OGC Block.

Expressing the indicator this way has a concrete purpose: when a CDI value appears in a dataset, the provenance chain can travel with it. Any system or person consuming that data can follow the chain to understand exactly what the value represents, which inputs were used to compute it, and by what method — without relying on out-of-band documentation or shared conventions agreed informally. The meaning is preserved in the data itself.

Once the chain is written and validated, we will upload and publish it using a locally deployed OGC Definitions Service.

What you will learn

• How to deploy the OGC Definitions Service using Docker
• How to describe a computed indicator as a provenance chain with OGC Blocks
• How to validate a JSON document and convert it to an RDF graph (a process called semantic uplift) using bblocks-client-python
• How to upload data to Apache Fuseki and browse it via the Prez interface

Prerequisites

• A working Docker environment with the docker compose plugin. Installation instructions are available on the Docker Desktop website.
• A working Python 3 environment (3.9 or later recommended). We recommend the official distribution from python.org.

Linked data: key terms

If you are new to linked data, these terms will appear throughout the tutorial:

• RDF (Resource Description Framework) — the W3C standard for representing information as a graph of linked statements. Each statement is a triple: a subject, a predicate, and an object (e.g. CDI was generated by CDI computation).
• Turtle — a compact, human-readable text format for writing RDF graphs.
• JSON-LD — a way of giving JSON documents RDF semantics by attaching a context that maps JSON property names to standard vocabulary terms, so that a plain JSON file can be read as an RDF graph.
• SPARQL — the query language for RDF graphs, analogous to SQL for relational databases.

How this tutorial is organized

Section	What it covers
Section 1: Deploy the OGC Definitions Service	Setting up Fuseki, Prez, and nginx-ld locally with Docker
Section 2: Define the indicator	Writing and validating the provenance chain for the CDI
Section 3: Upload and view the data	Loading data into Fuseki and browsing it as linked data

Ready? Continue to Section 1.