Open Digital Rights Language (ODRL) 3.0 Proposal

1. Introd­uction

Formal Semantics spec [odrl-formal-semantics]

1.1. Terminology

TODO

1.2. Namespaces

Commonly used namespace prefixes used in this specification:

@prefix dcterms:       <http://purl.org/dc/terms/> .
@prefix odrl:          <http://www.w3.org/ns/odrl/2/> .
@prefix odrl3proposal: <https://w3id.org/force/odrl3proposal#> .
@prefix report:        <https://w3id.org/force/compliance-report#> .
@prefix rdf:           <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix skos:          <http://www.w3.org/2004/02/skos/core#> .
@prefix xsd:           <http://www.w3.org/2001/XMLSchema#> .

2. Use Cases

2.1. UC1 - Dynamic Asset Collection Materialization

In ODRL terms, an Asset Collection is defined as a single resource representing a set of member resources, considering that all members of the set are subject to a rule if this rule is defined with the asset collection as its target. To materialise which Assets belong to an Asset Collection, ODRL has the partOf property. However, if this materialisation is still to be done to enforce policies over a collection, i.e., there is still no information in the state of the world of which Assets are partOf the Asset Collection, a solution is required to materialise which resources are members of the collection depending on the relation between said resources and the collection.

2.2. UC2 - Dynamic Right Operand Constraint Value

An ODRL Constraint has two operands to which comparisons can be made with one relational operator:

• Left Operand: An instance of odrl:LeftOperand, linked via the odrl:leftOperand property.

• Operator: A comparison operator from the odrl:Operator class.

• Right Operand: Either a static value (odrl:rightOperand) or a dynamic reference (odrl:rightOperandReference) that must be dereferenced at evaluation time.

The problem is that there is not enough information to dereference a value from the IRI of the odrl:rightOperandReference relation. There is a need for a solution that deterministically can fetch the value, such that proper comparisons can be made.

Note: Publication that introduced this problem and gave a theoretical solution(that requires major changes to ODRL 2.2): Akaichi et al., 2024, 'Interoperable and Continuous Usage Control Enforcement in Dataspaces'.

Note: As of 09/07/2025, there exists no formal method to materialize left operand values from their classes. This issue is known by the ODRL Community Group, more specific the people working on the ODRL Formal Semantics specification [odrl-formal-semantics].

3. Requirements

3.1. R1 - Define Asset Collection membership relation

To solve UC1, there is the need to describe the relation between the Asset Collection and its Asset members, which is needed to materialise which Assets belong to an Asset Collection using ODRL’s partOf property. For example, if we have an Asset Collection

@prefix ldp: <http://www.w3.org/ns/ldp#> .

ex:assetCollection a odrl:AssetCollection ;
    odrl:source <http://localhost:3000/container/> ;
    odrl3proposal:relation ldp:contains .

the term odrl3proposal:relation can be used to describe the relation of an Asset Collection with its members, which in this example is classified by the ldp:contains property. In this case, when the members of the Asset Collection, whose source is <http://localhost:3000/container/>, need to be materialised using the ldp:contains relation, if

@prefix ldp: <http://www.w3.org/ns/ldp#> .

<http://localhost:3000/container/> a ldp:Container;
    ldp:contains <http://localhost:3000/container/resource1.ttl> ;
    ldp:contains <http://localhost:3000/container/resource2.txt> ;
    ldp:contains <http://localhost:3000/container/resource3.png> .

then the following ODRL’s partOf memberships can be materialised

<http://localhost:3000/container/resource1.ttl> odrl:partOf <http://localhost:3000/container/> .
<http://localhost:3000/container/resource2.txt> odrl:partOf <http://localhost:3000/container/> .
<http://localhost:3000/container/resource3.png> odrl:partOf <http://localhost:3000/container/> .

3.2. R2 - Dynamic ODRL Specification

To solve UC2, there is a need for enough information and an algorithm to deterministically dereference the Right Operand Reference Value.

3.2.1. Proposed solution

Introduction of the class Operand Reference with two properties:

• reference: The IRI that has to be derefenced.

• path: A SHACL Property path, which is used to derive a value from a focus node (in this case the referenced IRI)

When the reference source is derefenced and the SHACL Property Path is executed on the source, this will always produce one value under the following assumptions (which MUST be conformed to):

• The source to be derefenced MUST be a valid RDF Document

• The SHACL Property Path MUST always, when followed, resolve into a single value.

As the policy remains static and the source can change over time, this solution proposes a method to add dynamic right operand values.

Note: Theoretical solution provided by the following publication(that requires major changes to ODRL 2.2): Akaichi et al., 2024, 'Interoperable and Continuous Usage Control Enforcement in Dataspaces'.

Example: Constraint with dynamic Right Operand value being resolved Dynamic constraint: If the current date time is less than the right operand value, the constraint is satisfied.

@prefix ex: <http://example.org/> .

<urn:uuid:constraint:ab67b414-d0c8-48f6-8554-524130561f84> a odrl:Constraint;
  odrl:leftOperand odrl:dateTime ;
  odrl:operator odrl:lt ;
  odrl:rightOperandReference ex:operandReference1 .

ex:operandReference1 a odrl3proposal:OperandReference ;
    odrl3proposal:reference ex:externalSource ;
    odrl3proposal:path ex:updatedValue .

External source hosted at http://example.org/externalSource contains following data (represented as text/turtle)

@prefix ex: <http://example.org/> .

ex:externalSource ex:updatedValue "2018-02-12T11:20:10.999Z"^^<http://www.w3.org/2001/XMLSchema#dateTime> .

So when following the SHACL Property Path, the Literal ("2018-02-12T11:20:10.999Z"^^<http://www.w3.org/2001/XMLSchema#dateTime>) is retrieved. This literal can then be compared against the left operand of the constraint.

4. ODRL 3.0 Proposal

4.1. Adding new terms to the ODRL vocabulary

4.1.1. Relation

4.1.2. Scope

4.1.3. Operand Reference

4.1.4. Path

4.1.5. Reference

4.2. Changing existing terms of the ODRL vocabulary

<urn:uuid:e30bcd34-0d5c-43d1-b229-bf68afcae5ae> a odrl:Set ;
    odrl:uid <urn:uuid:e30bcd34-0d5c-43d1-b229-bf68afcae5ae>

5. Supporting Materials

• FORCE: https://w3id.org/force/

• ODRL Compliance Report: https://w3id.org/force/compliance-report

  • repo: https://w3id.org/force/compliance-report/repo

• test suite: https://w3id.org/force/test-suite

  • repo: https://w3id.org/force/test-suite/repo

• github repository for an ODRL Evaluator: https://w3id.org/force/evaluator