Refine refinements

[riannella]

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

[riannella]

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.

[joshcornejo]

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 "ex@ex.com"^^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 "ex@ex.com"^^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.

[joshcornejo]

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 "ex@ex.com"^^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 "ex@ex.com"^^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 "ex@ex.com"^^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.

[joshcornejo]

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.

[joshcornejo]

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" }
            }]
        }]