Scalar constraint syntax cannot express per-axis semantics of multi-dimensional LeftOperands

[Daham-Mustaf]

Problem

Five LeftOperands in the ODRL Common Vocabulary define multi-dimensional
semantics, but the Constraint syntax (§2.5.1) is a scalar triple:

(leftOperand, operator, rightOperand)

This creates an unresolvable ambiguity: a single rightOperand slot
cannot bind a value to a specific axis.

Affected LeftOperands

LeftOperand	Definition (from Common Vocabulary)	Axes implied
absoluteSize	"Measure(s) of one or two axes for 2D-objects or one to three axes for 3D"	width, height, depth
absolutePosition	"A point defined with absolute coordinates for the position of the target Asset"	x, y, z, t
absoluteSpatialPosition	"four corners of a rectangle on a 2D-canvas or eight corners of a cuboid"	x, y, z
relativeSize	"relative percentage size of the target Asset"	width%, height%
relativePosition	"relative percentage position of the target Asset"	x%, y%

Example

A policy states:

absoluteSize lteq 1250

An ODRL processor cannot determine whether this constrains:

• width only
• height only
• both axes independently (width ≤ 1250 AND height ≤ 1250)
• some aggregate (e.g., total pixel count, diagonal)

Two conformant processors may interpret this differently,
breaking interoperability.

Consequence

It is currently impossible to express a constraint like
"width ≤ 1250 AND height ≤ 800" using absoluteSize, because the
scalar syntax provides one value slot but the LeftOperand
references two independent axes.

This affects at least three domains:

• Image/asset dimensions: delivery services like IIIF resolve
  width and height independently
• Canvas/viewport position: region-based constraints require
  per-axis coordinates (x, y, w, h)
• Geographic location: the ODRL Best Practices acknowledge that
  "the way of representing a geographic entity has not been
  standardized" (BP §4.1.5)

Scope

This issue describes the problem only. We are preparing a
profile-based solution and plan to present it at a peer-reviewed
venue in 2026. Community discussion is welcome.

Related: #107, #115

[vroddon]

One possible patch would be using the rdf:value construct.
ex:width lteq [ rdf:value 1250 ; ex:sizeType ex:absoluteSize ]
However, this is not prescribed in the Best Practices or elsewhere, therefore, still not making interoperability easier.
Indeed, representing n-ary relations would be a good-to-have feature in an ODRL3 --or an ODRL profile...

@AndreaCimminoArriaga hadn't you other geographical-related problems?

[riannella]

At the time, and even now, the idea was that an operational community would define the "semantics" for these rightOperands.

[joshcornejo]

I agree with Renato.

In an object-oriented world, you can mandate that the object, subject to the constraint, is capable of answering the question, or that the evaluator is capable of understanding the subject's properties and applying the constraint appropriately.

You will also see that in some standards (e.g. geolocation), where there are different ways of specifying a location, your processor will somehow have to work out the appropriate conversions (or if you want to get more cumbersome in a completely open world, different standards that can represent the same thing: geolocation vs ISO addresses).

Even more complex is when you reach operands like:

absolutePosition odrl:anyOf [ a list of specified locations, in different standards ]

[Daham-Mustaf]

@riannella and @joshcornejo Thank you both for the clarifications — this is very helpful.

It’s reassuring to hear that these semantics were intentionally left to operational communities. That actually matches what we are trying to do: rather than changing core ODRL, we’re working on a profile that makes the per-axis semantics explicit for a few spatial use cases.

We fully agree that handling multiple coordinate systems and representations is a hard problem. For now, we’re keeping the profile focused on structural decomposition (e.g. width vs height, x vs y) and leaving coordinate system choices to the consuming community.

[Daham-Mustaf]

Thanks @vroddon for raising this — the rdf:value pattern is a good example of what people often end up doing in practice.

We had a similar discussion on our side and reached roughly the same conclusion: it can work technically, but since it’s not covered in the Best Practices, different processors could still handle it in different ways.

That’s one of the reasons we’re leaning towards a profile-based approach, where the per-axis semantics are made explicit and shared, rather than relying on ad-hoc RDF patterns.

And yes, proper support for n-ary relations would definitely make this cleaner in a future ODRL version. For now, we’re just trying to see how far a profile can reasonably go within the current model.