w3c
Refine refinements
In section 2.5, the diagram:
The relationship "refinement" from [Party Collection | Asset Collection | Action ] implies a bounded relationship between the target/assignee/action and the constraint/logical constraint.
Since applying the Constraint is inherent to the Rule defining/using it (only applicable in the context of the Rule?), the relationship between the source/action, Rule, and the Constraint should (for clarity) be separated.
I propose that a better illustration of the relationship is (illustrating with the party collection):
Rule -----> [Refinement] ---> [ Party Collection ]
|-----------> [ Constraint ]]
| ^ ^
| | |
└-----------> [ Logical Constraint ]]
(IMHO, would recommend to create more examples with explicit naming references to nodes, having only implicit names and unravelled definitions might mislead the reader).
Submitted by @joshcornejo
Hi @joshcornejo Figure 2 maps directly and consistently from the Model in Figure 1 . In your proposal, it implies there is a "refinement" property between Rule and PartyCollection.
Hard to recall from March what was the source of the issue, but I think the problem (at least for me) is that JSON has implicit/invisible/unnamed nodes (which create some confusion).
I am trying to clarify what would be the proper way of articulating the refinement (as I am only refining the party/asset/action in the context of the rule).
ex:someRange a time:ProperInterval;
time:after "1970-01-20T18:33:36.9180000Z"^^xsd:dateTime;
time:before "2040-01-22T23:24:54.8490000Z"^^xsd:dateTime.
ex:someRule1 terms:created "1970-01-20T18:33:36.9180000Z"^^xsd:dateTime;
terms:creator "[email protected]"^^xsd:anyURI;
terms:description "some description"@en;
terms:valid ex:someRange;
a odrl:Permission;
odrl:assigner ex:PartyCollection1. #simple when there is no refinement
ex:someRule2 terms:created "1970-01-20T18:33:36.9180000Z"^^xsd:dateTime;
terms:creator "[email protected]"^^xsd:anyURI;
terms:description "some description"@en;
terms:valid ex:someRange;
a odrl:Permission;
odrl:assigner ex:PartyRefinedReference. # <-- use ODRL assigner
ex:PartyRefinedReference a odrl:PartyCollection;
odrl:assigner ex:PartyCollection1; # <-- use ODRL assigner again ??
odrl:refinement ex:Refinement1.
Not Simon's SHACL, but I've found this
odrl:AssetCollectionShape
a sh:NodeShape ;
sh:targetClass odrl:AssetCollection ;
sh:xone ( odrl:WithRefinementShape odrl:WithoutRefinementShape ) .
odrl:WithRefinementShape
a sh:NodeShape ;
sh:property [
sh:path odrl:source ;
sh:minCount 1 ;
sh:maxCount 1 ;
] ;
sh:property [
sh:path odrl:refinement ;
sh:minCount 1 ;
] .
odrl:WithoutRefinementShape
a sh:NodeShape ;
sh:property [
sh:path odrl:source ;
sh:maxCount 0 ;
] ;
sh:property [
sh:path odrl:refinement ;
sh:maxCount 0 ;
] .
As I suspected (because it was also my understanding), it looks from the above that the model assumes that an odrl:Asset and odrl:AssetCollection are not references to an Asset, but to an envelop that lives within the policy and the refinement modifies the Asset.
ex:someRule1 terms:created "1970-01-20T18:33:36.9180000Z"^^xsd:dateTime;
terms:creator "[email protected]"^^xsd:anyURI;
terms:description "some description"@en;
terms:valid ex:someRange;
a odrl:Permission;
odrl:assigner ex:PartyCollection1. # THIS belongs to the ODRL model
ex:PartyCollection1 a odrl:PartyCollection;
some:otherProperty ex:ActualParty. # <-- THIS the actual party
ex:someRule2 terms:created "1970-01-20T18:33:36.9180000Z"^^xsd:dateTime;
terms:creator "[email protected]"^^xsd:anyURI;
terms:description "some description"@en;
terms:valid ex:someRange;
a odrl:Permission;
odrl:assigner ex:PartyRefinedReference. # This belongs to the ODRL model
ex:PartyRefinedReference a odrl:PartyCollection;
some:otherProperty ex:ActualParty; # <-- THIS is the same party
odrl:refinement ex:Refinement1.
In this case, this is going to sprawl a lot of IRI and duplication happens when ex:ActualParty now has other roles
ex:someRule3 terms:created "1970-01-20T18:33:36.9180000Z"^^xsd:dateTime;
terms:creator "[email protected]"^^xsd:anyURI;
terms:description "some description"@en;
terms:valid ex:someRange;
a odrl:Permission;
odrl:informedParty ex:PartyRefinedReference1. # This belongs to the ODRL model
ex:PartyRefinedReference1 a odrl:PartyCollection;
some:otherProperty ex:ActualParty; # <-- THIS is the same party
odrl:refinement ex:Refinement1.
If I consider a JSON Policy as just a piece of text to be interpreted, there is "no problem", as JSON doesn't have the concepts of explicit linkage and the content is effectively just text.
If you want to represent the policy in JSON-LD or RDF (a semantic graph), now there is an IRI to represents your target/action/function as a unique node in that graph.
I can't see how to reference this example with the current properties (2 permissions, one prohibition needs refinement on the asset).
I have internal intermediary nodes to represent the duality between refined and unrefined:
<rule> -> <intermediary node> -> [unrefined element | refined element -> refinement ] }
That intermediary node deals with the treatment of the (xone - from the SHACL), but leaves me with a weird choice on the output (in RDF):
ex:someRule2. terms:created "1970-01-20T18:33:36.9180000Z"^^xsd:dateTime;
a odrl:Permission;
odrl:assigner ex:Party1; # <-- use ODRL assigner for unrefined element
odrl:assigner ex:Party1RefinedReference. # <-- use ODRL assigner for refined, pointing at an enveloped Party
ex:PartyRefinedReference a ex:PartyWrapper, odrl:PartyCollection;
odrl:assigner ex:Party1; # <-- enveloped Party
odrl:refinement ex:Refinement1.
Continuing my analysis:
If I slightly modify examples 14 and 15 (to use the same action and same constraint/refinement)
{
"@context": "http://www.w3.org/ns/odrl.jsonld",
"@type": "Offer",
"uid": "http://example.com/policy:6163",
"profile": "http://example.com/odrl:profile:10",
"permission": [{
"target": "http://example.com/document:1234",
"assigner": "http://example.com/org:616",
"action": "distribute",
"constraint": [{
"leftOperand": "spatial",
"operator": "eq",
"rightOperand": { "@value": "de", "@type": "iso:3166" }
}]
}]
}
{
"@context": "http://www.w3.org/ns/odrl.jsonld",
"@type": "Offer",
"uid": "http://example.com/policy:6163",
"profile": "http://example.com/odrl:profile:10",
"permission": [{
"target": "http://example.com/document:1234",
"assigner": "http://example.com/org:616",
"action":
[{ // <-- adds an "implicit node"
"rdf:value": { "@id": "distribute",
"refinement": [{
"leftOperand": "spatial",
"operator": "eq",
"rightOperand": { "@value": "de", "@type": "iso:3166" }
}]
}]
}]
}
Is there an equivalent dereferencing for an Asset or Party?
"target":
[{
"rdf:value": { "@id": "ex:Asset1", // <-- using rdf:value, although it is only called out for odrl:Action
"refinement": [{
"leftOperand": "spatial",
"operator": "eq",
"rightOperand": { "@value": "de", "@type": "iso:3166" }
}]
}]
Hi @joshcornejo .. I want to conclude this ticket...but I need to clarify what the actual "errata" is.
From the original request (see above)...is the issue that Figure 2 is not correct ?
This was one of the first times I ran into the refinement problem .
Once issue 64 is fixed, this will be fixed too.
As per the decision here: https://github.com/w3c/odrl/blob/master/meetings/2025/meeting-2025-06-09.md this issue is closed