Information Model as sub-set of ODRL

[DominikPinsel]

Hello everyone,

please correct my if I'm wrong. As far as I understand the Information Model and ODRL - and I don't understand ether of them that well - it looks like both models are not as compliant as its intended.

The IDSA Position Paper Usage Control V3 says:

The design preserves the structure of the introduced terminology, resulting in the compliance of every IDS Usage Policy with ODRL recommendations. Nevertheless, not all ODRL terms are part of the IDS Usage Control language as the requirements slightly differ.

Based on this text I assume that parts of the Information Model are intended to work as a sub-set of ODRL. This would mean that the Information Model Rules can be represented in ODRL, but not everything that is describable in ODRL needs to be representable in an IDS Rule.

I opened this issue because I assume the IDS Permission cannot be mapped to the ODRL Permission. And based on the initial assumption, that the IDS is intended as subset of ODRL, this would be an issue.

Please have a look at the ODRL Permission

A Permission allows an action, with all refinements satisfied, to be exercised on an Asset if all constraints are satisfied and if all duties are fulfilled.

The Permission class is a subclass of, and inherits all the properties from, the Rule class - and has the following additional property semantics:

• A Permission MUST have one target property value of type Asset. (Other relation sub-properties MAY be used.)
• A Permission MAY have none or one assigner and/or assignee property values (of type Party) for functional roles. (Other function sub-properties MAY be used.)
• A Permission MAY have none, one, or more duty property values of type Duty.

[...]

The duty property expresses an agreed obligation that MUST be fulfilled. That is, the duty property asserts a pre-condition between the Permission and the Duty. See the Duty with a Permission section for more details.

In the IDS Information Model a Permission may have multiple Pre- and PostDuty values.

If one wants to translate IDS to ODRL there is no available field, where the Post-Duty may be written to. Therefore the Permission is no sub-set of ODRL, but extends it. And this would be the issue.

[juliapampus]

@hosseinzadeha

[hosseinzadeha]

Dear @DominikPinsel, first of all thank you for your concern. The ODRL Language is very simple and easy to use but it is not covering all the issues in IDS world. Therefore, the IDS Usage Control Language was initially defined as a profile of ODRL Language. So we could extend the ODRL concepts. Later on, IDS language grew even more and now they match in many cases, however, they have few differences.

As you truly mentioned, the preduties and postduties are IDS Language terms. Though, the concept exists in ODRL too. Please check the following example for odrl:PolicyUsage:

Duty property with a Permission

Example Use Case: The Party http://example.com/assigner:sony makes an Offer to play the target asset http://example.com/music/1999.mp3. The permission includes a duty for the compensate action that has a refinement of payAmount of $EU5.00. The duty also has a constraint of event is less than policyUsage, meaning the duty rule must be exercised (ie the compensation) before the permission rule can be exercised.

EXAMPLE 22
{
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "@type": "Offer",
    "uid": "http://example.com/policy:88",
    "profile": "http://example.com/odrl:profile:09",
    "permission": [{
        "assigner": "http://example.com/assigner:sony",
        "target": "http://example.com/music/1999.mp3",
        "action": "play",
        "duty": [{
           "action": [{
              "rdf:value": { "@id": "odrl:compensate" },
              "refinement": [{
                 "leftOperand": "payAmount",
                 "operator": "eq",
                 "rightOperand": { "@value": "5.00", "@type": "xsd:decimal" },
                 "unit": "http://dbpedia.org/resource/Euro"
              }]
            }],
            "constraint": [{
                "leftOperand": "event",
                "operator": "lt",
                "rightOperand": { "@id": "odrl:policyUsage" }
            }]
        }]
    }]
}  

In the example above, one can specify "when" a duty shall be executed; event lt odrl:policyUsage demands the duty to be executed before the action being performed and supposedly, event gt odrl:policyUsage would refer to the duty to be executed after the action being performed. For the sake of simplicity, the terms preduty and postduty were introduced. still, we can translate them to ODRL as explained.

[riannella]

I am happy to help out resolving this. Can you show some examples of the pre and post-duties?

[hosseinzadeha]

Hi, I am glad that you joined this discussion. The followings are two examples; one for delete data after it is used and another one to replace the value of jsonpath "$.bufget" with a defined string value "XXXX" before it is used. The policies are specified in the IDS namespace and are compatible to the IDS Information Model V4.0.

{ 
    "odrl:permission": [{    
        "odrl:target": {
            "@id":"http://example.com/data/1234"
        },    
        "ids:action": [{
            "@id":"USE"
        }], 
        "ids:postDuty": [{    
            "@type":"ids:Duty",  
            "ids:action": [{
                "@id":"idsc:DELETE",     
                "odrl:refinement": [{    
                    "odrl:leftOperand": { "@id": "idsc:DATE_TIME"},  
                    "odrl:operator": { "@id": "idsc:BEFORE"}, 
                    "odrl:rightOperand": [{
                        "@type": "ids:Instant", 
                        "ids:dateTime": {
                            "@value": "2021-12-30T14:16",
                            "@type": "xsd:datetimeStamp"

                        } 
                    }] 
                }]
            }]
        }] 
    }] 
} 

and

{ 
    "odrl:permission": [{    
        "odrl:target": {
            "@id":"http://example.com/data/1234"
        },    
        "ids:action": [{
            "@id":"USE"
        }], 
        "ids:preDuty": [{    
            "@type":"ids:Duty",  
            "ids:action": [{
                "@id":"idsc:REPLACE",     
                "odrl:refinement": [{
                    "odrl:leftOperand": { "@id": "idsc:REPLACE_WITH"},  
                    "odrl:operator": { "@id": "idsc:DEFINES_AS"}, 
                    "odrl:rightOperand": [{"@value": "$.budget", "@type": "xsd:string"}] 
                },{     
                    "odrl:leftOperand": { "@id": "idsc:JSON_PATH"},  
                    "odrl:operator": { "@id": "idsc:DEFINES_AS"}, 
                    "odrl:rightOperand": [{"@value": "XXXX", "@type": "xsd:string"}] 
                }]
            }]
        }] 
    }] 
} 

[DominikPinsel]

Thanks a lot for all the answers and sorry for not replying :) I've now a lot more to read about ODRL and it's profiles. My issue regarding the pre- and post-duty is resolved. Therefore I will close this issue.

_{Dominik Pinsel dominik.pinsel@daimler.com, Daimler TSS GmbH, legal info/Impressum}

[riannella]

Did you still want me to comment on the above examples? (and the concept of pre/post Duties?)

[hosseinzadeha]

@riannella I initially explained why the IDS preduties and postduties were introduced. As far as I know, these concepts will be kept in the IDS policy language for now. However, any comment/feedback is appreciated.

[riannella]

Ok...thanks... I am assuming that both pre/postDuty have an odrl:Duty object and hence expect to follow the odrl rules to determine if a duty has been satisfied? Ie; the name "pre" and "post" are helpful for the reader, but the Duty refinement must express these "pre" and "post" rules explicitly?

[hosseinzadeha]

Right, these two elements help the readers (and the policy enforcement technologies) to know whether the duty actions (e.g. modify, delete, etc) must be executed before or after the rule actions(e.g. use, display, read, etc.). Currently, this is the only way that the sequence of executing the duty actions and the main rule actions are expressed in IDS language.