The basic context of an ODRL Policy is that only an explicitly permitted use may be executed. Any use not explicitly permitted is prohibited by default. An ODRL Policy only permits the action explicitly specified in a Permission and all other actions are implicitly prohibited. An action defined in a Prohibition should only refine (or directly relate to) the semantics of an action defined in one of the Permissions in the ODRL Policy.
+The basic context of an ODRL Policy is that only an explicitly permitted use may be executed. Any use not explicitly permitted is prohibited by default. An ODRL Policy only permits the action explicitly specified in a Permission and all other actions are implicitly prohibited. An action defined in a Prohibition SHOULD only refine (or directly relate to) the semantics of an action defined in one of the Permissions in the ODRL Policy.
For example, an ODRL Policy that has the action “present” Permission and may also have the action “print” Prohibition (as these actions are related hierarchically in the ODRL Vocabulary [[!vocab-odrl]]).
Note that ODRL Profiles can be developed and used to refine the basic context of an ODRL Policy. Hence, the application of an ODRL Profile must be understood by the consuming community and systems.
@@ -110,19 +110,19 @@As the Information Model diagram shows the key Permission, Prohibition and Duty entities are subtypes of the abstract Rule class and they have the same relationships to the other key entities (Action, Constraint, Asset, and Party). The core difference is in their semantics:
As the Information Model diagram shows the key Permission, Prohibition and Duty entities are subtypes of the abstract Rule class. These Rules have the same relationships to the other key entities (Action, Constraint, Asset, and Party). The core difference is in their semantics:
Permission says that the assignee MAY perform an action,Duty says that the assignee MUST perform an action, andProhibition says that the assignee MUST NOT perform an action.Permission says that the Party MAY perform an action,Duty says that the Party MUST perform an action, andProhibition says that the Party MUST NOT perform an action.The Rule class also makes it possible to easily extend the Information Model in Profiles by adding policy expressions (as subclasses of Rule) that are not possible by default.
The cardinalities shown in the ODRL Information Model allow for the greatest flexibility in expressing associations between the key entities. However, Policy Types and ODRL Profiles may express narrower and/or specific cardinalities on these entities.
A Permission MAY allow a particular Action to be executed on a related Asset, e.g. “play the audio file abc.mp3”. A Constraint like “at most 10 times” might be added to specify the Permission more precisely. The Party that grants this Permission is linked to it with the Role assigner, the Party that is granted the Permission is linked to it with the Role assignee, e.g. “assigner VirtualMusicShop grants the Permission to assignee Alice”. Additionally, a Permission MAY be linked to Duty entities.
Similar to Permissions, a Duty states that a certain Action MUST be executed by the Party with the Role assignee for the Permission to be valid, e.g. “Alice must pay 5 EUR in order to get the Permission to play abc.mp3″.
A Permission MAY allow a particular Action to be executed on a related Asset, e.g. “play the audio file abc.mp3”. A Constraint such as “at most 10 times” might be added to specify the Permission more precisely. The Party that grants this Permission is linked to it with the Role assigner, the Party that is granted the Permission is linked to it with the Role assignee, e.g. “assigner VirtualMusicShop grants the Permission to assignee Alice”. Additionally, a Permission MAY be linked to Duty entities.
Similar to Permissions, a Duty states that a certain Action MUST be executed by the Party with the Role assignee for the Permission to be valid, e.g. “Alice must pay 5 Euros in order to get the Permission to play abc.mp3″.
The Prohibition entity is used in the same way as Permission, with the difference that it MUST NOT refer to Duties and that the Action MUST NOT be exercised, e.g. “Alice is forbidden to use abc.mp3 commercially”.
The Policy entity is the top-level entity and contains the following attributes:
The Policy entity contains the following attributes:
uid: the unique identification of the Policy entity (REQUIRED)type: indicates the semantics of the Policy entity (REQUIRED). These are further described in the ODRL Vocabulary [[!vocab-odrl]] and ODRL Profiles.profile: the identifier of the ODRL Profile that this Policy conforms to (OPTIONAL)The uid attribute MUST be a unique identifier.
The range of values for the Policy entity’s type attribute will be described in the ODRL Vocabulary [[!vocab-odrl]] or in ODRL Profiles. This value MAY also impose further constraints on the Information Model, such as are exemplified in the Scenarios for types Offer and Agreement. It is important that the type attribute be clearly understood in policy expressions as the semantics MAY impose restrictions on the expression language constructs such as cardinalities between entities.
Other attributes MAY be added to the Policy entity to support additional functions and requirements. Typically, these will be from different community vocabularies. For example, to indicate the issued date or valid dates of the Policy entity, use of the Dublin Core Metadata Terms would be recommended.
The range of values for the Policy entity’s type attribute will be described in the ODRL Vocabulary [[!vocab-odrl]] or in ODRL Profiles. This value MAY also impose further constraints on the Information Model. It is important that the type attribute be clearly understood in policy expressions as the semantics MAY impose restrictions on the expression language constructs such as cardinalities between entities. For example, the ODRL Agreement Policy Type stipluates that it must contain two Parties (an assigner and assignee).
Example Use Case: A Policy of type Set states that the Asset http//example.com/asset:9898 is the target of the Permission read and the Prohibition reproduce. No parties or other elements are involved.
The ODRL Information Model supports flexibility in the information structures to declare ODRL expressions. A Policy MAY contain multiple Rules, and each Rule MAY contain multiple Assets, Parties, Actions, Constraints, and Duties. A Policy MAY also contain Assets, Parties, and Actions at the Policy level, and these apply to all of the enclosing Rules in the Policy.
+ +At the core atomic level, an ODRL Rule (Permission and/or Prohibition) would typically contain one Asset, one or more Parties, one Action, and potentially one Constraint and/or Duty, as shown in the below example:
+ +
+{
+ "@context": {
+ "odrl": "http://www.w3.org/ns/odrl/2/"
+ }
+ "type": "odrl:Agreement",
+ "uid": "http://example.com/policy:8888",
+ "permission": [{
+ "target": "http://example.com/music/1999.mp3",
+ "assigner": "http://example.com/org/sony-music",
+ "assignee": "http://example.com/people/billie",
+ "action": "odrl:play",
+ "constraint": "...",
+ "duty": "..."
+ }]
+ }]
+}
+
+
+As multiple Assets, Parties, and Actions are support for each Rule, then the following (snippet) example with two Assets:
+ +
+ "permission": [{
+ "target": "http://example.com/music/1999.mp3",
+ "target": "http://example.com/music/PurpleRain.mp3",
+ "assigner": "http://example.com/org/sony-music",
+ "assignee": "http://example.com/people/billie",
+ "action": "odrl:play",
+ "constraint": "...",
+ "duty": "..."
+ }]
+
+
+Would then be mapped to two atomic Rules:
+ +
+ "permission": [{
+ "target": "http://example.com/music/1999.mp3",
+ "assigner": "http://example.com/org/sony-music",
+ "assignee": "http://example.com/people/billie",
+ "action": "odrl:play",
+ "constraint": "...",
+ "duty": "..."
+ }]
+ "permission": [{
+ "target": "http://example.com/music/PurpleRain.mp3",
+ "assigner": "http://example.com/org/sony-music",
+ "assignee": "http://example.com/people/billie",
+ "action": "odrl:play",
+ "constraint": "...",
+ "duty": "..."
+ }]
+
+
+ The processing model for Permission/Prohibition Rules with multiple Assets, Parties, and Actions to generate atomic Rules includes:
+An ODRL Policy MAY also declare multiple Assets, Parties, and Actions at the Policy level. This indicates that these are all common to all the enclosing Rules, as shown in the below example:
+ +
+{
+ "@context": {
+ "odrl": "http://www.w3.org/ns/odrl/2/"
+ }
+ "type": "odrl:Agreement",
+ "uid": "http://example.com/policy:8888",
+ "target": "http://example.com/music/1999.mp3",
+ "assigner": "http://example.com/org/sony-music",
+ "action": "odrl:play",
+ "permission": [{
+ "assignee": "http://example.com/people/billie"
+ },
+ {
+ "assignee": "http://example.com/people/murphy"
+ }]
+ }]
+}
+
+
+To fully expand the Rules, the Policy-level Assets, Parties, and Actions MUST be added to all the Rules in the Policy. As shown below, the policy-level target, assigner, and action are added to the two permission Rules:
+ +
+{
+ "@context": {
+ "odrl": "http://www.w3.org/ns/odrl/2/"
+ }
+ "type": "odrl:Agreement",
+ "uid": "http://example.com/policy:8888",
+ "permission": [{
+ "target": "http://example.com/music/1999.mp3",
+ "assigner": "http://example.com/org/sony-music",
+ "action": "odrl:play",
+ "assignee": "http://example.com/people/billie"
+ },
+ {
+ "assignee": "http://example.com/people/murphy"
+ "target": "http://example.com/music/1999.mp3",
+ "assigner": "http://example.com/org/sony-music",
+ "action": "odrl:play",
+ }]
+ }]
+}
+
+
+ The processing model for Policies with multiple Assets, Parties, and Actions includes:
+Additional attributes MAY be added to the Policy entity to support additional functions and requirements. Typically, these will be from different community vocabularies. For example, to indicate the issued date or valid dates of the Policy entity, use of the Dublin Core Metadata Terms would be recommended.
...more to be added here...
+ +The undefined attribute is used to indicate how to process unsupported Actions. That is, if an ODRL expression contains an Action that is not from a known (or supported) ODRL vocabulary, how should the action be treated in the context of the whole ODRL Policy.
The undefined attribute is used to indicate how to process unsupported Actions. That is, if an ODRL expression contains an Action that is not from a known (or supported) ODRL vocabulary, how should the action be treated in the context of the whole ODRL Policy?
The undefined attribute MUST take one of the following values:
ODRL supports a simple inheritance mechanism in which a (child) Policy may inherit all the information structures of another (parent) Policy. The inheritance is aimed at including data structures between Policies.
The inheritAllowed attribute in the Policy entity is used to indicate if the Policy expression can be used in any inheritance relationship. If present, the value of the inheritAllowed attribute MUST take one of the following values:
false: the Policy expression can not be used for inheritanceIf the inheritAllowed attribute is not explicitly set, its default value of true will be used.
The following attributes SHOULD be used in a child policy that is inheriting from a parent policy in which that parent policy MUST allow inheritance (vai the inheritAllowed attribute) :
The following attributes SHOULD be used in a child policy that is inheriting from a parent policy in which that parent policy MUST allow inheritance (via the inheritAllowed attribute) :
inheritFrom: the identifier of the parent Policy from which this child Policy inherits fromThe inheritFrom association in the (child) Policy will uniquely identify (via a UID) the (parent) Policy from which the inheritance will be performed.
The inheritRelation attribute in the (child) Policy will uniquely identify (via a UID) the context of inheritance from the (parent) Policy. For example, this may indicate the business scenario, such as subscription, or prior arrangements between the parties (that are not machine representable). Such terms SHOULD be defined in the ODRL Vocabulary [[!vocab-odrl]] or ODRL Profiles. For example, an Assigner and Assignee may have a historical arrangement related to the specific use of content they make available to each other. The business model (identified with a URI) is used in the inheritRelation attribute in their subsequent ODRL policies they exchange. This will require the ODRL policy to be interpreted with the additional information identified by the URI. For example, this may include additional permission actions or constraints (etc) that is documented in their business model arrangement.
Both the inheritFrom association and inheritRelation attribute may be used independently.
The following restrictions apply when using inheritance:
Policy to one or more Child Policy entities. No Child Policy can inherit from two or more Parent Policy entities.)Policy entities.)Policy MUST override the Parent Policy. i.e.: If the same Action appears in the Parent, then it is replaced by the Child version, otherwise the Parent Actions are added to the Child’s Actions.Policy to the Child PolicyPolicy to the Child Policy.Example Use Case: This example explains the use of inheritance by means of two parent Policies and two child Policies.
-On the one side, the instance of the child Policy http://example.com/child_policy:2222 inherits from the parent Policy http://example.com/parent_policy:1111, allowing to reproduce the parent's target Asset http://example.com/asset:1111, and allowing the Party http://example.com/assignee:88 to read the child's target Asset http://example.com/asset:2222. Moreover, due to the inheritance relation, the child Policy inherits from the parent that the Party http://example.com/assignee:88 can also reproduce http://example.com/asset:1111.
-
-On the other side, the instance of the child Policy http://example.com/child_policy:1111 inherits from the parent Policy http://example.com/parent_policy:2222, allowing to distribute the parent's target Asset http://example.com/asset:3333, and allowing the Party http://example.com/assignee:88 to play and distribute the child's target Asset http://example.com/asset:4444. In this case, the child Policy overrides the parent one, meaning that as the same Action appears in the parent and in the child (i.e., distribute), then it is replaced by the child version, so that the Party http://example.com/assignee:88 can also distribute http://example.com/asset:3333.
-
-Note that, following the definition of inheritance provided above, the child Policy http://example.com/child_policy:1111 cannot inherit from parent Policy http://example.com/parent_policy:1111, even if inheritance is allowed from this Policy, because no child Policy can inherit from two or more parent Policy entities.
-
{
- "@context": {
- "odrl": "http://www.w3.org/ns/odrl/2/"
+Example Use Case:Consider the below (parent) Policy that has been expressed primarly for inheritance purposes:
+
+
+{
+ "@context": {
+ "odrl": "http://www.w3.org/ns/odrl/2/"
}
- "type": "odrl:Set",
- "uid": "http://example.com/parent_policy:1111",
- "inheritAllowed": true,
- "permission": [{
- "target": "http://example.com/asset:1111",
- "action": "odrl:reproduce",
- "assigner": "http://example.com/owner:1818"
+ "type": "odrl:Set",
+ "uid": "http://example.com/policy:3333",
+ "target": "http://example.com/asset:3333",
+ "assigner": "http://example.com/boss:0001",
+ "permission": [{
+ "action": "odrl:use"
}]
-}
+}
-
-{
-"@context": {
- "odrl": "http://www.w3.org/ns/odrl/2/"
- }
- "type": "odrl:Set",
- "uid": "http://example.com/parent_policy:2222",
- "inheritAllowed": true,
- "permission": [{
- "target": "http://example.com/asset:3333",
- "action": "odrl:distribute",
- "assigner": "http://example.com/owner:1919"
- }]
-}
-
-{
-"@context": {
- "odrl": "http://www.w3.org/ns/odrl/2/"
+
+The below (child) Policy includes the inheritFrom attribute pointing to the above (parent) Policy. The (child) policy also includes its own specific policy-level asset, and two Permission Rules.
+
+
+{
+ "@context": {
+ "odrl": "http://www.w3.org/ns/odrl/2/"
}
- "type": "odrl:Set",
- "uid": "http://example.com/child_policy:2222",
- "inheritFrom": "http://example.com/parent_policy:1111",
- "permission": [{
- "target": "http://example.com/asset:2222",
- "action": "odrl:read",
- "assigner": "http://example.com/owner:1818",
- "assignee": "http://example.com/assignee:88"
+ "type": "odrl:Agreement",
+ "uid": "http://example.com/policy:4444",
+ "inheritFrom": "http://example.com/policy:3333",
+ "target": "http://example.com/asset:5555",
+ "permission": [{
+ "assignee": "http://example.com/guest:0001",
+ "action": "odrl:display"
+ }],
+ "permission": [{
+ "assignee": "http://example.com/guest:0002",
+ "action": "odrl:print"
}]
-}
+}
+
+
-{
-"@context": {
- "odrl": "http://www.w3.org/ns/odrl/2/"
+After the inheritance is performed - where the (parent) Policy information structures are added to the (child) Policy - the resultant Policy is shown below:
+
+
+{
+ "@context": {
+ "odrl": "http://www.w3.org/ns/odrl/2/"
}
- "type": "odrl:Set",
- "id": "http://example.com/child_policy:1111",
- "inheritFrom": "http://example.com/parent_policy:2222",
- "permission": [{
- "target": "http://example.com/asset:4444",
- "action": "odrl:play",
- "assigner": "http://example.com/owner:1919",
- "assignee": "http://example.com/assignee:88"
+ "type": "odrl:Agreement",
+ "uid": "http://example.com/policy:4444",
+ "target": [
+ "http://example.com/asset:5555",
+ "http://example.com/asset:3333" ]
+ "assigner": "http://example.com/boss:0001",
+ "permission": [{
+ "assignee": "http://example.com/guest:0001",
+ "action": "odrl:display"
+ }],
+ "permission": [{
+ "assignee": "http://example.com/guest:0002",
+ "action": "odrl:print"
+ }],
+ "permission": [{
+ "action": "odrl:use"
}]
-}
-
+}
+
+
+
+
+The processing model for ODRL Policy Inheritance includes:
+
+ - A (child) Policy with an inheritFrom attribute MUST first verify that the (parent) Policy does not contain the inhertiAllowed attribute with the value "false".
+ - The (child) Policy MUST access the (parent) Policy and replicate the following in the (child) Policy:
+
+ - All policy-level Assets, Parties, Actions.
+ - All Permission and Prohibition Rules.
+
+ - The (child) Policy can then be further expanded (into atomic Rules) by following the processing models defined in the Policy Structure section.
+
+
- The Party entity is the object of an ODRL policy and can be any form of identifiable entity. The Party performs (or does not perform) actions or has a function in a Duty (i.e., assigns the Party to the Rule by associating it with the role it plays in the Rule). The Party entity can be any form of identifiable entity, such as a person, group of people, organisation, or agent. An agent is a person or thing that takes an active role or produces a specified effect.
The Party entity is the object of an ODRL policy and can be any form of identifiable entity, such as a person, group of people, organisation, or agent. An agent is a person or thing that takes an active role or produces a specified effect. The Party performs (or does not perform) actions or has a function in a Duty (i.e., assigns the Party to the Rule by associating it with the role it plays in the Rule).
The Party entity contains the following attributes:
uid: the unique identification of the party (REQUIRED)The Permission entity has the following relations:
Asset: the Permission entity MUST refer to an Asset (where at least one, and only one, relation value is target) on which the linked Action SHOULD be performed (REQUIRED)Action: the Permission entity MUST refer to exactly one Action that indicates the granted operation on the target Asset (REQUIRED)Action: the Permission entity MUST refer to exactly one Action that indicates the granted operation on the target Asset (REQUIRED) (Note: this is after the Rule has folowed the processing models defined in the Policy Structure section.)Party: the Permission MAY refer to one or more Party entities linked via the Role entity (OPTIONAL)Constraint: the Permission MAY refer to one or more Constraints which affect the validity of the Permission - it only becomes effective if all of the referred Constraints are true (OPTIONAL). For example; the Action play is only permitted for a certain period of time.Duty: the Permission MAY refer to one or more Duty entities that indicate a requirement that SHOULD be fulfilled in return for receiving the Permission (OPTIONAL)The Prohibition entity indicates the Actions that are prohibited to be performed on the Asset.
The Prohibition entity has the following relations:
Asset: the Prohibition entity MUST refer to an Asset (where at least one, and only one, relation value is target) on which the Action is prohibited (REQUIRED)Asset: the Prohibition entity MUST refer to an Asset (where at least one, and only one, relation value is target) on which the Action is prohibited (REQUIRED) (Note: this is after the Rule has folowed the processing models defined in the Policy Structure section.)Action: the Prohibition entity MUST refer to exactly one Action that is prohibited (REQUIRED)Party: the Prohibition MAY refer to one or more Party entities linked via the Role entity (see Section 2.3.1) (OPTIONAL)The Constraint entity indicates limits and restrictions to the Permission, the Prohibition and the Duty entity. Constraints express a rule for comparing two operands by one operator. If the two operands match the result of the constraint is TRUE.
- For example, the “number of usages” (name) must be “smaller than” (operator) the “number 10” (rightOperand).
leftOperand) must be “smaller than” (operator) the “number 10” (rightOperand).
If multiple Constraint entities are linked to the same Permission, Prohibition, or Duty entity, then all of the Constraint entities MUST be satisfied. That is, all the Constraint entities are (boolean) anded. In the case where the same Constraint is repeated, then these MUST be represented as a single Constraint entity using an appropriate operator value (for example, isAnyOf).
The Constraint entity contains the following attributes:
name: a name that identifies the left operand of the operation (REQUIRED)leftOperand: a name that identifies the left operand of the operation (REQUIRED)operator: an operator function (REQUIRED)rightOperand: the right operand of the operation (REQUIRED if no rightOperandReference)rightOperandReference: the right operand of the operation (REQUIRED if no rightOperand)
- The name identifies the left operand of the logic operation for the Constraint, it SHOULD include the entity it constrains and how its value for a comparison has to be retrieved/generated. It MAY include the datatype of the value and it MAY include references to resources for retrieving/generating the value.
+ The leftOperand identifies the left operand of the logic operation for the Constraint, it SHOULD include the entity it constrains and how its value for a comparison has to be retrieved/generated. It MAY include the datatype of the value and it MAY include references to resources for retrieving/generating the value.
The operator identifies the comparative operation such as “greater than” or “equal to”.
The actual value of the constraint that is to be compared to the name is either represented with the rightOperand or rightOperandReference. The rightOperand represents the literal value (such as "10" or "http://example.com/c100") and rightOperandReference represents a URI that MUST be dereferenced to obtain the actual value. Only one of these MUST appear in the constraint.
The actual value of the constraint that is to be compared to the leftOperand is either represented with the rightOperand or rightOperandReference. The rightOperand represents the literal value (such as "10" or "http://example.com/c100") and rightOperandReference represents a URI that MUST be dereferenced to obtain the actual value. Only one of these MUST appear in the constraint.
The dataType indicates the type of the rightOperand/Reference, such as “decimal” or “datetime” and the unit indicates the unit value of the rightOperand/Reference, such as “EU dollars”.
The status provides the current value of the Constraint variable (i.e. current value of name). This is useful in cases where the current status of Constraints needs to be captured and expressed in the ODRL Information Model.
The status provides the current value of the Constraint variable (i.e. current value of leftOperand). This is useful in cases where the current status of Constraints needs to be captured and expressed in the ODRL Information Model.
Example Use Case: The Party http://example.com/myPix:6161 wants to assign the Permission distribute directly to the potential buyer of the permission who will pay 100 EUR for this grant. The distribute Permission is also constrained to a specific country, i.e., Italy. The potential assignee may then distribute the target Asset http://example.com/wallpaper:1234 according to the nextPolicy target Asset linked directly from this Duty. In this case, the next Policy Asset stipulates that the potential assignee may only offer the display Permission to downstream consumers.