This document presents a new profile called ODRL Data Spaces (ODS) that extends the ODRL core vocabulary and expression models to support data spaces over big data and streaming systems.

ODS serves as a Rights Expression Language tailored for the global data space lifecycle, allowing data assets to be annotated with machine-readable policies that dictate permissions, prohibitions, and obligations across multi-phase workflows.

Acknowledgments

This document is the result of a collaborative team effort within the Eunomia research framework. Development, specification, and maintenance of the ODS profile are led by researchers at the Universidad Politécnica de Madrid (UPM) & Information Processing and Telecommunications Center (IPTC):

• Joaquin Salvachúa
• Andrés Muñoz
• Gabriel Huecas
• Carlos Aparicio
• Rodrigo Menendez

ODS specifications

This section extends the ODRL Recommendation [ODRL22] by terms required by Data Spaces.

ODS specifications

This section extends the ODRL Recommendation [ODRL22] by adding specialized actions, party functions, and execution constraints required across the data space data lifecycle[cite: 1].

Introduction

The ODRL Data Spaces (ODS) profile provides a cohesive extension for policy definition regarding continuous access and usage control[cite: 1]. It establishes a unified execution container designed to maintain data sovereignty across heterogeneous software implementations[cite: 1].

Unlike static enforcement models, this profile addresses a multi-phase data space lifecycle segmented into three distinct functional stages[cite: 1]:

• Stage 1: Intake & Discovery – Data space offerings are structured via ODS profiles and published to metadata catalogs (such as Gaia-X), utilizing DCAT-AP metadata matching for discoverability[cite: 1].
• Stage 2: Agreement & Matching – Abstract policy offers are formally negotiated at a designated rendezvous point and instantiated into binding contracts[cite: 1].
• Stage 3: Operation Execution – Divided into three continuous phases[cite: 1]:
  • Pre-Operation: Access control validation handled at the provider domain (e.g., using Relationship-Based Access Control/ReBAC via OpenFGA)[cite: 1].
  • Ongoing Operation: Real-time streaming usage control (e.g., transpiled into Apache Flink Complex Event Processing scripts to evaluate logs against constraints)[cite: 1].
  • Post-Operation: Compliance tracking, retention validation, and enforcement of erasure constraints (such as cryptographic shredding)[cite: 1].

Actions for Rules

For the class Action (http://www.w3.org/ns/odrl/2/Action), used with Rules, these instances are defined.

Party Functions

For the class Party (http://www.w3.org/ns/odrl/2/Party), used with Rules, these instances are defined.

Examples

Machine Learning (ML) example

Company A wants to share a dataset with Company B[cite: 1]. Company A only allows Company B to use the data for generating a ML model[cite: 1]. Company B cannot transfer any data to internal or external parties[cite: 1].

{
  "@context": "http://www.w3.org/ns/odrl.jsonld",
  "@type": "Agreement",
  "uid": "http://example.com/policy:1010",
  "duc:provider": "http://oem.com/ids#me",
  "permission": [{
    "duc:consumer": "http://supplier.com/",
    "target": "http://oem.com/ids/inventory/dataset-1",
    "action": "duc:train"
  }],
  "obligation": [{
    "@type": "Duty",
    "target": "http://oem.com/ids/inventory/dataset-1",
    "action": "inform",
    "consequence": [{
      "target": "http://oem.com/ids/inventory/dataset-1",
      "action":[{
        "rdf:value": { "@id": "duc:KillJob" },
        "refinement": [{
          "leftOperand": "recipient",
          "operator": "eq",
          "rightOperand": {
            "@value": "flinkid00",
            "@type": "http://orion.fiware.org/Job"
          }
        }]
      }]
    }]
  }],
  "prohibition": [{
    "assignee": "http://supplier.com/",
    "target" : "http://oem.com/ids/inventory/dataset-1",
    "action": "print"
  }]
}