Constraint/Refinement Semantics

@riannella

@riannella put a comment on a repo:

"The spatial constraint should be on the Action not the Parties."

Aren't these constraints written in English equivalent:

"Party must be refined, such as is located at X to perform Action"
"Action can only be performed from location X"

Either way, the refinement looks the same.

@vroddon

See some previous discussion: https://lists.w3.org/Archives/Public/public-odrl/2024May/0035.html

@vroddon We should add this the the Best Practices document

I think from an implementation perspective, the client will know the location of the assignee, but not where the action is performed (e.g. the evaluator or the enforcement agent can't know).

In the real world, I can cook anywhere, but the refinement "cook in X house" is only complete for evaluation when the party performing the action is in X house", because "cooking" on it's own is always depending on the party.

It is also different when you refine:

"Distribution can only take place Monday-Friday"
"Party can only distribute Monday-Friday"

In that case the affinity of the refinement seems closer to the action/verb?

There is also the 3rd option of rule constraint

"This rule is constrained to Monday-Friday"

... which represents the same outcome, although they all have slightly different origins?

But, both rule constraint or action refinement depend on the Party for the evaluation of spatial location, so it seems there is more affinity to refine the Party?

As per the specification, all rules represent transitive actions, and to be complete they depend on a subject (party) and an object (asset).

I disagree :-)

Consider the real-world scenario of streaming services...

I watch "ABC iView" here in Australia. I cannot watch it if I am not in Australia.

When I am in Hong Kong, and try to use "ABC iView" it tells me that I am not in Australia and cannot use the service.
Now - importantly - it does not really know that I am in HK, but the application knows that the the request from was IP address(es) outside the known AU allocations (I think thats how it works - hence the (illegal) use of VPN!)

So it is the Permission ( action = "stream") that is Constrained to a region.

Then, If I stream a program that says I must be over 18 years old...then the system must know that it is me.
So the Party is refined to an intrinsic characteristic of Parties. (age - narrow the semantics)

I think that the example of streaming still refers to the location of the Party executing the action. The location of the client (tv, STB or browser) is what determines if the action can/can't be executed. To evaluate the action as "performed in" requires the location of the performer, which is then equivalent to say that the performer "must be in" to act?

From the "18+" statement: Knowledge of "who am I?" and "where am I?" are both still transitive to the noun, as the party "is the subject" in the triple?

There are more complex cases where perhaps Action refinements (because they are refinements and not constraints, even if the tag says 'constraint', right?) are useful - the action of "output to a printing device" now requires the location of the printer, not that of the party asking for the execution (as the party can be "at home" printing to "the CEO's printer"), but in current syntax and evaluation thought process, the Evaluator can only know the location of the Party or the location of the Device?

IMHO, from the specification, Action "refinements" the examples are examples of constraints, and the use of the word refinement creates diversion?

I can recall that we went thru this issue in detail during the POE WG (2017-18) when we introduced "refinement" as a new property (but still a Constraint object).

In any case, I believe ODRL users may find this point confusing. Therefore, adding examples to the Best Practices document would be helpful — even if they do not fully satisfy all concerns.

Please let me know what you think. Do you find my text acceptable AND useful?

3.3.9 How to determine whether "constraining a rule", "refining an action" is best?
Consider the following two examples. In the first example, the permission is only active in Germany.

 {
     "@context": "http://www.w3.org/ns/odrl.jsonld",
     "@type": "Set",
     "uid": "http://example.com/policy:339a",
     "permission": [{
        "target": "http://example.com/document:1234",
        "assigner": "http://example.com/org:616",
        "action": "distribute",
	"constraint": [{
           "leftOperand": "spatial",
           "operator": "eq",
           "rightOperand":  "https://www.wikidata.org/resource/Q183"
       }]
    }]
 }

In the following example, the permission is active everywhere, but the refinement may not satisfied and the permission not granted if the action is done in Germany.

 {
     "@context": "http://www.w3.org/ns/odrl.jsonld",
     "@type": "Set",
     "uid": "http://example.com/policy:339b",
     "permission": [{
        "target": "http://example.com/document:1234",
        "assigner": "http://example.com/org:616",
        "action": [{
           "rdf:value": { "@id": "odrl:distribute" },
    	    "refinement": [{
               "leftOperand": "spatial",
               "operator": "eq",
               "rightOperand":  "https://www.wikidata.org/resource/Q183"
           }]
         }]
    }]
 }

Although both approaches may lead to the same operational outcome, it is important to distinguish their semantics: Constraints define conditions under which a Rule is applicable, whereas Refinements narrow or qualify the semantics of an Action.

An analogy may help clarify this distinction. Consider German law: it is applicable within Germany. Here, territorial scope determines whether the rule applies at all — this corresponds to the first approach (using a Constraint). By contrast, consider a universal physical law (e.g., the rotation of water due to the Coriolis effect): the law applies everywhere, but its manifestation differs between hemispheres. This corresponds to the second approach (using a Refinement), where the action is qualified rather than conditionally triggered.

In most practical, human-centered business scenarios, the first approach — expressing applicability conditions through Constraints — will generally be more natural and semantically appropriate.

@simonstey

This is good Victor...but we need to clarify "both approaches may lead to the same operational outcome"...

And I would always welcome's @simonstey views

There is a lot of prior discussion here:
https://lists.w3.org/Archives/Public/public-odrl/2022Apr/
w3c/poe#282

I was thinking about this yesterday evening, and a thought came to mind:

"The dog can cook on Friday evenings"

Just because the sentence is syntactically correct and follows grammar and can be understood semantically, doesn't mean that it leads to a real, tangible outcome.

I think the purpose of a standard is to prevent ad hoc writing, since triples and RDF can produce "beautiful" but useless statements.

Yes, thats why we need clear guidance as to when to use constraints and when to use refinements.

The SDO that wrote your dog example could have said that the "cooker" must be of type "human" :-)

See #60

This is an extremely useful thread, but with somewhat unclear conclusions and with no definite proposals. I would rather vow for having implementation-supported examples that are non-controversional, which doesn't seem to be the case. But this is a relevant input towards ODRL 3.0, though...

Navigation Menu

Repository navigation

Constraint/Refinement Semantics #145

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Constraint/Refinement Semantics #145

Description

Activity

riannella commented on Feb 20, 2026

joshcornejo commented on Feb 20, 2026

riannella commented on Feb 22, 2026

joshcornejo commented on Feb 23, 2026

riannella commented on Feb 24, 2026

vroddon commented on Feb 24, 2026

riannella commented on Feb 25, 2026

joshcornejo commented on Feb 25, 2026

riannella commented on Feb 26, 2026

riannella commented on Mar 7, 2026

vroddon commented on May 3, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions