ODRL Version 2.0 Core Model

You are viewing an old revision of this post, from 14 November, 2011 @ 12:21. See below for differences between this version and the current revision.

Draft Specification: X November 2011 – Barcelona Edition

Editors:
Renato Iannella, Semantic Identity, riATsemanticidentity.com
Susanne Guth, Vodafone, susanne.guthATvodafone.com
Daniel Paehler, University of Koblenz, tulkasATuni-koblenz.de
Andreas Kasten, University of Koblenz, andreas.kastenATuni-koblenz.de

Status of this document

The W3C ODRL Community Group publishes a Draft Specification to indicate that the document is believed to be stable and to encourage implementation by the wider community. The W3C ODRL Community Group expects to advance this document to Specification once demonstrable interoperability has been achieved.

Discussion of this document takes place on the W3C ODRL Community Group mailing list (see Contributor Archive). Feedback from the public is encouraged and can be send to public-odrl@w3.org (see Public Archive).

This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than “work in progress”. Publication as a Draft Specification does not imply endorsement by the W3C ODRL Community Group.

Table of contents


1. Overview

The ODRL policy expression language has benefited from a robust underlying information model that has captured its semantics and provided extensibility paths for various communities. ODRL Version 2.0 is a major update for ODRL and will supersede Version 1.1.[ODRL11]

The ODRL Core Model is designed to be independent from implementation mechanisms and is focussed on the optimal model and semantics to represent policy-based information.

The following documents are planned for ODRL Version 2.0:

  • ODRL V2.0 – Requirements [ODRL-REQ]. The Requirements document represents requirements for the language that have been gathered since ODRL Version 1.1 has been released. Not all requirements are aimed to be met.
  • ODRL V2.0 – Core Model (this document)
  • ODRL V2.0 – Common Vocabulary. This document specifies the terms (vocabulary) used by the Core Model for policy expression needs across communities [ODRL-VOCAB]. (This was called the “data dictionary” previously.)
  • ODRL V2.0 – Core Model – XML Encoding. The XML Encoding document specifies the serialisation of the Core Model in XML [ODRL-XML].
  • ODRL V2.0 – Core Model – RDF/XML Encoding. The RDF/XML Encoding document will specify the serialisation of the Core Model in RDF/XML.

The updated model is based on additional semantics and requirements gathered from the DRM community, the latest research on security, access control, obligation management as well as the past experiences in implementations and research of ODRL. The requirements for Version 2.0 are documented [ODRL-REQ] and will be directly referenced in this document to ensure that they have been adequately addressed (where applicable).

The model shall be formally specified using UML notation [UML] [ODRL-REQ-6] and shall utilise the key words “MUST”, “MAY”, “REQUIRED”, and “OPTIONAL” in accordance to [RFC2119].

To make keywords easily distinguishable, this document uses syntax highlighting (formatted coded typeface) to indicate Core Model entities, the entities’ attributes, and concrete values for the attributes.

2. ODRL Core Model

Figure 2.1 below shows the complete version 2.0 ODRL Core Model. Policy is the central entity that holds an ODRL policy together. In its encoded form, e.g. in an XML document, it makes the policy addressable from the outside word via its uid attribute. Policy can refer to Permissions and Prohibitions.

A Permission allows 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 MAY 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″.

The Prohibition entity is used in the same way as Permission, with the two differences that it does not refer to Duties and (obviously) that it forbids the Action, e.g. “Alice is forbidden to use abc.mp3 commercially”.

ODRL Core Model

Figure 2.1 – ODRL Core Model Version 2.0

The following sections describes each entity of the Core Model in greater detail.

2.1 Policy

The Policy entity is the top-level entity and 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 Common Vocabulary and ODRL Profiles.
  • conflict: indicates the precedence between Permissions and Prohibitions (OPTIONAL)
  • undefined: indicates how to handle undefined Actions (OPTIONAL)
  • inheritAllowed: indicates if the Policy entity can be inherited (OPTIONAL)
  • inheritFrom: the identifier from which this Policy inherits from it’s parent Policy (OPTIONAL)
  • inheritRelation: the identifier for the relationship type of this inheritance structure (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 Common Vocabulary document or in community profiles. This value MAY also impose further constraints on the Core 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.

The conflict attribute is used to resolve conflicts arising from the merging of policies, specifically when there are conflicting Actions in the Permissions and Prohibitions. If present, the conflict attribute MUST take one of the following values:

  • perm: the Permissions will always takes precedence
  • prohibit: the Prohibitions will always takes precedence
  • invalid: the policy is not valid

If the conflict attribute is not explicitly set, its default value will be used instead. The default value of the conflict attribute is invalid.

The undefined attribute is used to indicate how to support Actions that are not part of any known profile in the policy expression system. If present, the undefined attribute MUST take one of
the following values:

  • support: the Action is to be supported as part of the policy – and the policy remains valid
  • ignore: the Action is to be ignored and not part of the policy – and the policy remains valid
  • invalid: the Action is unknown – and the policy is invalid

In the support case, even though the Action is unknown, the policy still is valid and the consuming parties or system of the policy MUST be made aware of the unknown Action. This may be via a user interface that displays the unknown Action for human readability.

In the ignore case, even though the Action is unknown, the policy still is valid and the consuming parties or system of the policy MAY be made aware of the unknown Action.

In the invalid case with the unknown Action, the policy is invalid and the consuming parties or system of the policy MUST be made aware of this.

If the undefined attribute is not explicitly set, its default value will be used instead. The default value of the undefined attribute is invalid.

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.

2.1.1 Inheritance

The inheritAllowed attribute in the Policy entity is used to indicate if the Policy expression can be used in any inheritance relationship [ODRL-REQ-1.20]. If present, the value of the inheritAllowed attribute MUST take one of the following values:

  • true: the Policy expression can be used for inheritance
  • false: the Policy expression can not be used for inheritance

If the inheritAllowed attribute is not explicitly set, its default value will be used instead. The default value of the inherit attribute is true.

Only if the inheritAllowed attribute has the value true can the inheritFrom and inheritRelation attributes be specified.

The inheritFrom attribute 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 type of inheritance from the (parent) Policy. For example, this may indicate the business scenario, such as subscription. Such terms MAY be defined in the Common Vocabulary or community Profiles.

The following restrictions apply when using inheritance:

  • Single inheritance is only supported. (One Parent Policy to one or more Child Policy entities. No Child Policy can inherit from two or more Parent Policy entities.)
  • Inheritance can be to any depth. (Multiple levels of Children Policy entities.)
  • Inheritance cannot be circular.
  • The Child 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.
  • No state information is transferred from the policy in the Parent Policy to the Child Policy

2.2 Asset

The Asset entity is aimed at identifying the content that is the subject of an ODRL policy, e.g. a media file or ebook. Furthermore, it can be used to represent other Asset entities that are needed to undertake the Policy expression, such as with the Duty entity. The Asset entity is referred to by the Permission and/or Prohibition entities, and also by the Duty entity.

The Asset entity contains the following attribute:

  • uid: the unique identification of the Asset (REQUIRED)

The identification of the Asset entity is a key foundation of the ODRL Policy language. However, there are some use cases where the ODRL Policy expression may be embedded inside the target Asset. In these cases, it may be more appropriate to provide, or infer, a link to the Asset entity (as the complete Asset uid may not be known at the time) through the local context. Use of such inference and context should be well documented in the relevant ODRL community Profile.

Since ODRL policies could deal with any kind of asset, the ODRL Core Model does not provide additional metadata to describe Asset entities of particular media types. It is recommended to use already existing metadata standards, such as Dublin Core Metadata Terms that are appropriate to the Asset type or purpose.

The Relation entity is used to associate the Asset entity with the relevant Permission, Prohibition, and Duty entities

2.2.1 Relation

The Relation entity is an association class and can be used to link to an Asset from either Permission, Duty or Prohibition, indicating how the Asset MAY be utilised in respect to the entity that links to it.

The Relation entity contains the following attribute:

  • relation: indicates the relationship of the Asset to the linked entity (REQUIRED)

The default value for the relation attribute is target which indicates that the Asset is the primary object to which the Permission, Duty or Prohibition actions apply.

Other values for the Relation entity may be defined in the Common Vocabulary and community Profiles.

2.3 Party

The Party entity is aimed at identifying a person, group of people, or organisation. The Party MUST identify a (legal) entity that can participate in policy transactions [ODRL-REQ-1.5].

The Party entity contains the following attribute:

  • uid: the unique identification of the party (REQUIRED)

The ODRL Core Model does not provide additional metadata for the Party element. It is recommended to use already existing metadata standards, such as IETF vCard that are appropriate to the Party type or purpose.

The Role entity is used to associate the Party entity with the relevant Permission, Prohibition, and Duty entities.

2.3.1 Role

The Role entity is an association class and can be used to link to a Party from either Permission, Duty or Prohibition, indicating which role the Party takes with respect to the entity that links to it.

The Role entity contains the following attributes:

  • function: the functional role the Party takes (REQUIRED)
  • scope: defines how the role shall be interpreted under different contexts. (OPTIONAL)

The function attribute MUST take one of the following values:

  • assigner: indicates that the Party has assigned the associated Permission, Duty, or Prohibition. In other words, the Party grants a Permission or requires a Duty to be performed or states a Prohibition.
  • assignee: indicates that the Party has been assigned the associated entity, i.e. they are granted a Permission or required to perform a Duty or have to adhere to a Prohibition.

Other values for the function attribute MAY be defined in the Common Vocabulary and community Profiles.

The scope attribute MAY be used to indicate the context under which to interpret the Party entity. If present, the scope attribute MAY take one of the following values:

  • individual: indicates that the Party entity is a single individual. The linked Permission, Duty or Prohibition is applicable for that individual only.
  • group: indicates that the Party entity represents a group. The group consisting of many individual members. The linked Permission, Duty or Prohibition is applicable for each member of that group. For example, a (constrained) Permission to play a movie 5 times is valid for each Party member or the Duty to pay 3 EUR has to be fulfilled by each Party member.

Other values for the scope attribute MAY be defined in the Common Vocabulary and community Profiles.

2.4 Permission

The Permission entity indicates the Actions that the assignee is permitted to perform on the associated Asset. In other words, what the assigner (supplier) has granted to the assignee (consumer).

An ODRL policy expression MAY contain at least one Permission. It is important to verify the semantics of the Policy type attribute as this MAY indicate additional constraints on the Policy expression structure.

If several Permission entities are referred to by a Policy, then all of them are valid.

The Permission entity has the following relations:

  • Asset: the Permission entity MUST refer to an Asset (where at least one relation value is target) on which the linked Action may be performed (REQUIRED)
  • Action: the Permission entity MUST refer to exactly one Action that indicates the granted operation on the target Asset (REQUIRED)
  • Party: the Permission MUST refer to one or more Party entities linked via the Role entity (see Section 2.3.1) (OPTIONAL)
  • Constraint: the Permission MAY refer to one or more Constraints which affect the validity of the Permission, e.g. if the Action play is only permitted for a certain period of time (OPTIONAL)
  • Duty: the Permission MAY refer to one or more Duty entities that indicate a requirement that MAY be fulfilled in return for receiving the Permission (OPTIONAL)

2.5 Duty

The Duty entity indicates a requirement that MAY be fulfilled in return for being entitled to the referring Permission entity [ODRL-REQ-1.8]. While implying different semantics, the Duty entity is similar to Permission in that it is an Action that can be undertaken. If a Permission refers to several Duty entities, all of them have to be fulfilled for the Permission to become valid. If several Permission entities refer to one Duty, then the Duty only has to be fulfilled once for all the Permission entities to become valid.

The Duty entity contains the following attributes:

  • uid: a unique identification for this Duty. Used to refer a single Duty to multiple Permission entities (OPTIONAL)

The Duty entity has the following relations:

  • Action: indicates the operation (e.g. pay) that MAY be performed (REQUIRED). Note: It is assumed that the assigned Party has the appropriate permissions to perform this action.
  • Party: a Duty MAY refer to Party entities with different Roles (see Section 2.3.1). If no explicit Party is linked to as assignee or assigner, the Parties with the respective Roles are taken from the referring Permission. (OPTIONAL)
  • Asset: a Duty entity MAY refer to an Asset (where at least one relation value is target) related to fulfilling the Duty. For example, a pay Action must be linked to a target Asset that indicates the amount to pay. The mechanisms to perform this linking/packaging are defined by community Profiles. (OPTIONAL)
  • Constraint: a Duty MAY link to one or more Constraints [ODRL-REQ-1.10] (OPTIONAL)

A Duty entity does not, by itself, specify any conditions on when the Duty Action MUST or MAY be performed, such as to pay before viewing the movie. Such conditions MAY be expressed through Constraint entities.

2.6 Prohibition

The Prohibition entity indicates the Actions that the assignee is prohibited to perform on the related Asset [ODRL-REQ-1.7]. Prohibitions are issued by the supplier of the Asset – the Party with the Role assigner. If several Prohibition entities are referred to by a Policy, all of them are valid.

The Prohibition entity has the following relations:

  • Asset: the Prohibition entity MUST refer to an Asset (where at least one relation value is target) on which the Action is prohibited (REQUIRED)
  • 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)
  • Constraint: the Prohibition MAY refer to one or more Constraint entities (OPTIONAL)

2.7 Action

The Action entity (when related to a Permission entity) indicates the operations (e.g. play, copy, etc.) that the assignee (i.e. the consumer) is permitted to perform on the related Asset linked to by Permission. When related to a Prohibition, the Action entity indicates the operations that the assignee (again the consumer) is prohibited to perform on the Asset linked to by Prohibition. Analogously, when related to a Duty, it indicates the operation to be performed.

Action contains the following attribute:

  • name: indicates the Action entity term (REQUIRED)

As its value, the name attribute MAY take one of a set of Action names which are formally defined in profiles. The ODRL Common Vocabulary defines a standard set of potential terms that may be used. Communities will develop new (or extend existing) profiles to capture additional and refined semantics.

2.8 Constraint

The Constraint entity indicates limits and restrictions to the Permission, the Prohibition and the Duty entity [ODRL-REQ-1.9]. Constraints express mathematical terms with two operands and one operator. For example, the “number of usages” (name) 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).