ODRL Version 2.0 Core Model

You are viewing an old revision of this post, from 26 September, 2011 @ 3:30. See below for differences between this version and the current revision.

(this is a test!)

Draft Specification: 17 February 2011

This version:
http://odrl.net/2.0/DS-ODRL-Model-20110217.html
Latest version:
http://odrl.net/2.0/DS-ODRL-Model.html
Previous version:
http://odrl.net/2.0/DS-ODRL-Model-20101015.html
Editors:
Renato Iannella, Semantic Identity, riATsemanticidentity.com
Susanne Guth, Vodafone, susanne.guthATvodafone.com
Helge Hundacker, University of Koblenz, hundackerATuni-koblenz.de
Daniel Paehler, University of Koblenz, tulkasATuni-koblenz.de
Andreas Kasten, University of Koblenz, andreas.kastenATuni-koblenz.de

Abstract

This document describes the ODRL Version 2.0 Core Model Specification. The model incorporates new features and requirements for the ODRL policy expression language.

Status of this document

This is the fifth public Draft Specification of the ODRL V2.0 Core Model Specification document produced by the ODRL Version 2.0 Working Group.

The ODRL Initiative publishes a Draft Specification to indicate
that the document is believed to be stable and to encourage
implementation by the wider community. The ODRL Version 2.0 Working
Group expects to advance this document to Specification once the Working
Group has developed Working Drafts for the ODRL Version 2.0 Common
Vocabulary and at least one Encoding and demonstrated at least two
interoperable implementations.

Comments on this document should be sent to editors.
Discussion of this document takes place on the public working group
mailing list odrl-version2@odrl.net
(archived at http://odrl.net/pipermail/odrl-version2_odrl.net/)
and in the public ODRL Initiative Wiki.

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 ODRL Initiative.

This document uses the following visual indicators for substantial differences from the previous version:

  • Green background – Previous content has been updated
  • Yellow background – New content has been added
  • Pink background and strikeout – Previous content has been deleted

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 will specify the
    potential terms (vocabulary) used by the Core Model for policy
    expression needs across communities. (This was called the “data
    dictionary” previously.)
  • ODRL V2.0 – Core Model – XML Encoding. The XML Encoding
    document will specify the serialisation of the Core Model in XML,
    including the normative XML Schema for the new Model and examples.
  • 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 new 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”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”,
“SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in
accordance to [RFC2119].

To make keywords easily distinguishable, this document
uses syntax highlighting based on the following rules:

  • Core Model entities (classes in the UML diagram) begin
    with a capital letter and are formatted
    in bold fonts, e.g. Party,
    Asset or Role.
  • The entities’ attributes begin with a lower-case letter and are
    formatted in bold fonts, e.g. uid,
    type or function.
    Attribute names comprising several words are written in “camelCase”,
    i.e. each new word begins with a capital letter, e.g.
    inheritFrom or
    rightOperand.
  • The concrete values that the attributes can take begin with
    lower-case letters and formatted in typewriter font, e.g.
    invalid,
    assigner or true.
    CamelCase is also used for values, where necessary.

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 should 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 Version 2.0
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 or other inheritance structures such as expression, manifestation. 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 will always
    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 should 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 should 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
    may 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 should 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)
  • relax: indicates if the
    Duty may be fulfilled at any time (OPTIONAL)

If set, the relax attribute MUST take one of the
following values:

  • true: this means that the
    Duty may be fulfilled at any time, including
    after the containing Permission has been
    utilised by the Party with the Role
    assignee
  • false: the
    Duty must be fulfilled before the
    Permission can be exercised

If not explicitly set, relax takes
the default value false. Note that
the Duty has to be fulfilled eventually,
regardless of the value of relax.

The Duty entity has the
following relations:

    • Action: indicates the operation
      (e.g. pay) that should 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 should be performed, such as to pay before viewing the movie. Such conditions should 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 an operation that has to be performed.

Action contains the following attribute:

  • name: indicates the
    Action entity term (REQUIRED)

As its value, the name attribute
SHOULD 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/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 several
Constraints are linked to by the same entity,
all of them are valid.

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 the left operand of the operation (REQUIRED)
  • operator: an operator function
    (REQUIRED)
  • rightOperand: the right operand
    of the operation (REQUIRED)
  • status: the current value of
    the left operand (OPTIONAL)

The name identifies the left
operand of the mathematical operation for the Constraint
such as “Number of Usages” and “Expiration Date” etc. The operator identifies the comparative operation
such as “greater than” or “equal to”. The rightOperand
identifies the value that is being compared. When processing policy
expressions, these Constraint names shall be
directly linked to a procedure that can determine the outcome of the
operations, such as the number of already performed usages and the
current date. The name and operator would be defined in the Common
Vocabulary or community profiles.

The status provides the current
value of the Constraint variable (i.e.
current value of name) [ODRL-REQ#1.3].
This is useful in cases where the current status of Constraints
needs to be captured and expressed in the ODRL Core Model.

3. Scenarios (Informative)

This section shows a number of policy expression scenarios. In
these examples, the different policy expression types
that are used are for illustrative purposes only and are not part of
this normative specification. Also, the specific Action
and Constraint names (etc.) used in these
examples are for illustrative purposes only. Please note that formal
policy expression types and other
entities will be defined in the ODRL Common Vocabulary specification, or
in community profiles.

3.1 Set

The following shows an instance of a set Policy.
The Set shows a policy expression, stating
that the Asset http//example.com/asset:9898
is the target of the Permission reproduce and the Prohibition
to modify. No parties or other elements are
involved. This set could be used, for
example, as a template or an instant license.

instance set
Figure 3.1 – An instance of a Set Policy

3.2 Offer

The following shows the instance of an offer Policy.
The offer contains the music file http//example.com/music:4545 that is offered by the Party http//example.com/sony:10 with
the Permissions to play
and copy the file. The Permission
copy is only granted once. The two Permissions are offered for a payment of
AUD$0.50.

instance Offer
Figure 3.2 – An instance of an Offer Policy

3.3 Agreement

The following shows the instance of an agreement Policy.
The agreement contains all entities shown in
the offer scenario above. A new Party element http//example.com/billie:888
has been added. This Party accepted the
previous offer and thus is now the buyer of
the Permission play
and copy, i.e. is now linked as assignee of the
Permissions and Duty
entities.

instance Agreement
Figure 3.3 – An instance of an Agreement Policy

3.4 Request

The following shows the instance of a request Policy.
The Party http//example.com/guest:0589
has requested the Permission to display the target Asset http//example.com/news:0099.

instance Request
Figure 3.4 – An instance of a Request Policy

3.5 Ticket

The following shows the instance of a ticket Policy.
The ticket expresses the play Permission
for the target Asset http//example.com/game:4589.
The Ticket is valid until the end of the year 2010. Any valid holder of this ticket may exercise this Permission.

instance Ticket
Figure 3.5 – An instance of a Ticket Policy

3.6 Offer and Next Policy

The following shows the instance of an offer Policy
showing the nextPolicy structure. The party http//example.com/sony:99 assigns the Permission
distribute directly to the potential buyer of
the permission who will pay $EU1,000. The distribute
Permission is also constrained to the
country Italy. The potential assignee may then distribute
the target Asset 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.

instance next rights
Figure 3.6 – An instance of an Offer and Next Policy
Policy

3.7 Privacy

The following shows the instance of an privacy Policy.

The target Asset is Personal Data and the assignee is allowed to distribute the Asset only for the purpose of contacting the subject of the Personal Data. The purpose value is taken from the P3P privacy purpose vocabulary.

Additionally, the assigner (the Party who the personal data is about) has stipulated that the assignee must delete the Asset after a 30 day period (retention policy).

instance Privacy
Figure 3.7 – An instance of an Privacy Policy

3.8 Permission and Prohibition

The following shows the instance of an agreement Policy
with both a Permission and a Prohibition. The party http//example.com/sony:10
assigns the Permission play
to the Party http//example.com/billie:888
at the same time they are prohibited from utilising the target Asset as a mobile:ringtone.
Additionally, in case of any conflict, the conflict
attribute is set to perm indicating that the
Permission entity will take precedence.

instance perm prohibit
Figure 3.8 – An instance of an Permission and
Prohibition Policy

3.9 Inheritance

The following shows the instance of a (child) Policy http//example.com/policy:9999 inheriting from another (parent) Policy http//example.com/policy:5531. The inheritFrom
attribute of the (child) Policy has the same identifier as the (parent) Policy. In this
inheritance example, the (parent) Policy allows the Party http//example.com/billie:888 to print the (parent’s)
target Asset. The (child) Policy allows the Party http//example.com/class:IT01 (a group of
people) to display the (child’s) target Asset. Since the (child) Policy also inherits from the (parent) Policy, then the Party http//example.com/class:IT01 can also print the (parent’s)
target Asset.

instance inherit
Figure 3.9 – An instance of an Inheritance Policy

3.10 Social Network

The following shows the instance of an agreement Policy for a Social Network scenario.

The target Asset are photos posted to a Social Network site and the assigner is the owner of the photos. The assignee is a Party group and represents the football network members on the social network, who are each allowed to display the photos.

instance social network
Figure 3.10 – An instance of an Social Network Policy

3.11 Multiple Assets

The following shows an instance of a set Policy utilising multiple Asset entities.

The index Permission is granted to the target Asset. As well, the x:collection Asset specifies which database the
index outcome should be stored in.

instance Multiple Assets Policy
Figure 3.11 – An instance of an Multiple Assets Policy

4. Profiles (Informative)

The ODRL Core Model represents a broad need for policy
expressibility. As a result, different communities will require less or
more elements from the Core Model. Community profiles of the ODRL model
are expected to be developed that adequately document these changes in
respect to the Core Model. Some requirements of this process include:

  • Document any additions to the Core Model
  • Document any aspects of the Core Model that will have
    different default values
  • Document which aspects of the Core Model are not being used
    (deprecated)
  • Declare your communities namespace (see Encoding
    specifications)
  • Share the Community profile with the ODRL Initiative for
    feedback and comments

5. Experimental Features (Informative)

This section contains advanced ODRL features. Although not part of the normative specification, they provide an opportunity for communities to experiment with and provide feedback on experiences that may be included in future ODRL versions.

5.1 Extended Relations

Extended Relations may tie Permission, Prohibition,
Duty, and Constraint
entities together with an AND, OR or XOR relationship.
Only entities of the same type can be linked with this model. For
example, a Permission and Prohibition cannot be linked together within this
model. The Extended Relations model supports the following attribute:

  • operation: MAY be set with one
    of the mathematical values AND, OR and XOR. (OR is the default if not specified.)

The following table outlines the semantics of Extended Relations
with respect to each of the main entity types.

Permission Prohibition Duty Constraint
OR The related party MAY perform any (at least)
one of the Actions
The related party MAY NOT perform at least one of
the Actions
The related party MUST perform at least one of the Actions The related Permission/Prohibition/Duty is
restricted by at least one of the Constraints
AND The related party MUST perform all of the Actions The related party MAY NOT perform all of the Actions The related party MUST perform all of the Actions The related Permission/Prohibition/Duty is
restricted by all of the Constraints
XOR The related party MAY perform only one of the Actions The related party MAY NOT perform only one of the Actions The related party MUST perform only one of the Actions The related Permission/Prohibition/Duty is
restricted by only one of the Constraints.

Note that Extended Relations are not needed to assign two or more
Permissions to a Party
entity. In this case simply use as many Assignee
relations between Party and Permission as needed.

5.2 Consequences and Remedies for Duties

When assigning a Duty the policy assumes that the assignee will either perform the Duty (and then get access to the Asset) or not perform the Duty (and hence, not get access to the Asset). There is one exception in that Duty entity may contain the relax boolean that indicates the duty may be fulfilled at anytime, including after the Permission has been utilised by the assignee.

However, there is no concept of compensation for not performing the Duty. That is some type of consequence of not performing the Duty or a remedy if something went wrong. One possible solution would be to allow there to be Duty for Duties, making it clear the consequence of not performing that Duty within the specified terms.

5.2 Abstract Policy Expression

As the Core Model diagram shows (see Figure 2.1), the key Permission, Prohibition and Duty entities are very similar since they have (more or less) the same relationships to the other entities. They core difference is in their semantics:

  • Permission says that the assignee
    may do something,
  • Duty says that the assignee should do something, and
  • Prohibition says that they should not do it.

In an implementation that interprets ODRL, it may make sense to introduce a common superclass AbstractPolicy, as shown in the (abbreviated) Model in Figure 5.1.

Core Model with Abstract Policy Expression
Figure 5.1 – ODRL Abstract Policy Model

By implementing Permission, Prohibition and Duty as subclasses of AbstractPolicy, the redundancy of having very similar, but separately developed classes in an application’s source code can be avoided. Furthermore, AbstractPolicy makes it possible to easily extend the Core Model in Profiles by adding policy expressions (as subclasses of AbstractPolicy) that are not possible by default, e.g. InterpretedAsPermission in cases where the ODRL policy was derived from a legal situation or document that was ambiguous.

5.3 Remedies

In the ODRL Core Model, Duties are only directly related to Permissions, meaning that for a Permission to become effective, the related Duty should be performed. For some use cases though, it might be useful to attach a Duty to a Prohibition, meaning that if a Prohibition is violated, the Duty has to be performed as a kind of remedy or consequence for the violation.

Not only can a Prohibition have a Duty attached to it as a remedy, even Duties themselves may have remedies, e.g. “For the Permission to play audio file xyz to become effective, you have to perform the Duty ‘pay 2€’. If you don’t perform this Duty (even though you’ve played yxz), you have to remedy this by performing the Duty ‘pay 5€’”.

In order to distinguish between a Duty that has to be fulfilled as a requirement and one that has to be fulfilled as a remedy, different relation names are introduced as shown in the Figure 5.2.

Remedy
Figure 5.2 – Remedy Model

The relation between Permission and Duty, which was unnamed before, is now named hasRequirement. This is needed not only to make the different semantics clearer, but also because a Duty can refer to yet another Duty as a requirement, e.g. “If you want to print this written article, you have the Duty to attach a particular image of the author, and if you do that, you have the Duty to attribute the image to the photographer”.

Acknowledgements

The editors gratefully acknowledge feedback and contributions to
this document from:

  • Vicky Weissman, Mark Strembeck, Alapan Arnab, Steven Rowat,
    Eetu Luoma, Jaime Delgado, Ruediger Grimm, Stuart Myles, Francis Cave, Rigo Wenning, Hassan Abdel-Rahman, Jonas Zitz
  • Members of the Version 2.0 Working Group

References

[ISO4217]

ISO 4217 currency and funds name and code elements.
Specification, International Organization for Standardization
(ISO), 07 July 2008.

http://www.iso.org/iso/support/faqs/faqs_widely_used_standards/widely_used_standards_other/currency_codes/currency_codes_list-1.htm

[ODRL11] R. Iannella (ed). Open Digital Rights Language
(ODRL), Version 1.1. Technical Specification, ODRL Initiative, 8
August 2002.http://odrl.net/1.1/ODRL-11.pdf
[ODRL-REQ] S. Guth & R. Iannella (eds). Open Digital
Rights Language (ODRL) Version 2.0 Requirements (Working Draft), ODRL
Initiative, http://odrl.net/2.0/v2req.html,
24 November 2004.
[RFC2119] Key words for use in RFCs to Indicate
Requirement Levels, S. Bradner. The Internet Society, March 1997. http://tools.ietf.org/html/rfc2119
[UML] Unified Modeling Language (UML), Object Management
Group, 2003. http://www.omg.org/technology/documents/formal/uml.htm

Valid HTML 4.0 Strict

 

Post Revisions:

Changes:

26 September, 2011 @ 3:30Current Revision
Title
ODRL Version 2.0 - Core Model  ODRL Version 2.0 Core Model
Content
<span class="Apple-style-span" style="color: #000000;font-size: 22px;line-height: 32px">(this is a test!)</span>  
<span class="Apple-style-span" style="color: #000000;font-size: 22px;line-height: 32px">Draft Specification: 17 February 2011</span>  
<dl><dt>This version:</dt><dd><a href="http:// odrl.net/2.0/ DS-ODRL-Model- 20110217.html" >http://odrl.net/ 2.0/DS-ODRL-Model- 20110217.html< /a></dd><dt>Latest version:</dt><dd><a href="http:// odrl.net/2.0/ DS-ODRL-Model.html" >http://odrl.net/ 2.0/DS-ODRL- Model.html</a> </dd><dt>Previous version:</dt><dd><a href="http:// odrl.net/2.0/ DS-ODRL-Model- 20101015.html" >http://odrl.net/ 2.0/DS-ODRL-Model- 20101015.html< /a></dd><dt>Editors: </dt><dd>Renato Iannella, Semantic Identity, ri<img src="http://odrl.net/ images/at.gif" alt="AT" />semanticidentity.com< /dd><dd>Susanne Guth, Vodafone, susanne.guth<img src="http://odrl.net/ images/at.gif" alt="AT" />vodafone.com< /dd><dd>Helge Hundacker, University of Koblenz, hundacker<img src="http://odrl.net/ images/at.gif" alt="AT" />uni-koblenz.de< /dd><dd>Daniel Paehler, University of Koblenz, tulkas<img src="http://odrl.net/ images/at.gif" alt="AT" />uni-koblenz.de< /dd><dd>Andreas Kasten, University of Koblenz, andreas.kasten<img src="http://odrl.net/ images/at.gif" alt="AT" />uni-koblenz.de</dd></dl>  
<p class="copyright">Copyright <a href="http:// odrl.net/">ODRL  
  <h3>Final Specification: 24 April 2012</h3>
  <h4>Location: http://www.w3.org/ community/odrl/ two/model/</h4>
  <p>&nbsp;</p>
  <dl>
   <dt>Editors:</dt>
   <dd>Renato Iannella, Semantic Identity, ri<img src="https:// www.w3.org/community/odrl/ files/2011/11/at.gif" alt="AT">semanticidentity.com</dd>
   <dd>Susanne Guth, Vodafone, susanne.guth<img src="https:// www.w3.org/community/odrl/ files/2011/11/at.gif" alt="AT">vodafone.com</dd>
   <dd>Daniel Paehler, University of Koblenz, tulkas<img src="https:// www.w3.org/community/odrl/ files/2011/11/at.gif" alt="AT">uni- koblenz.de</dd>
Initiative</a> 2005-2011. All Rights Reserved. See the <a href="http:// odrl.net/IAB/ process.html">ODRL Process Document</a> for Policy and Usage terms.</p>  <dd>Andreas Kasten, University of Koblenz, andreas.kasten<img src="https:// www.w3.org/community/odrl/ files/2011/11/at.gif" alt="AT">uni- koblenz.de</dd>
  </dl>
<hr />  <hr>
<h2>Abstract</h2>  
This document describes the ODRL Version 2.0 Core Model Specification. The model incorporates new features and requirements for the ODRL policy expression language.  
<h2>Status of this document</h2> <h2>Status of this document</h2>
This is the <strong>fifth</strong> public Draft Specification of the ODRL V2.0 Core Model Specification document produced by the ODRL Version 2.0 Working Group.  
The ODRL Initiative publishes a Draft Specification to indicate  
that the document is believed to be stable and to encourage  
implementation by the wider community. The ODRL Version 2.0 Working  
Group expects to advance this document to Specification once the Working  
Group has developed Working Drafts for the ODRL Version 2.0 Common  
Vocabulary and at least one Encoding and demonstrated at least two  
interoperable implementations.  
Comments on this document should be sent to editors.  
Discussion of this document takes place on the public working group  
  <p>This specification was published by the <a href="//www.w3.org/ community/odrl/">W3C ODRL Community Group</a>. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the <a href="//www.w3.org/ community/about/agreements/ cla/”">W3C Community Contributor License Agreement (CLA)</a> there is a limited opt-out and other conditions apply. Learn more about <a href="//www.w3.org/ community/”">W3C Community and Business Groups</a>.</p>
  <p>The <a href="//www.w3.org/ community/odrl/">W3C ODRL Community Group</a> publishes a Final Specification to indicate that the document is believed to be mature and stable for implementation by the wider community. This Final Specification is now endorsed by the <a href="//www.w3.org/ community/odrl/">W3C ODRL Community Group</a> as appropriate for widespread deployment and that promotes the Community Groups's mission.
  </p>
  <p>
  Discussion and feedback of this document takes place on the W3C ODRL Community Group mailing list (see <a href="http:// lists.w3.org/ Archives/Public/ public-odrl-contrib/ ">Contributor Archive</a>). Feedback from the public is encouraged and can be send to <a href="mailto: public-odrl@w3.org">public- odrl@w3.org</a> (see <a href="http:// lists.w3.org/ Archives/Public/ public-odrl/">Public Archive</a>).</p>
  <blockquote><p>
  <strong><br />
  Copyright © 2012 the Contributors to the Final Specification, published by the <a href="//www.w3.org/ community/odrl/">W3C ODRL Community Group</a> under the <a href="http:// www.w3.org/community/about/ agreements/final/">W3C Community Final Specification Agreement (FSA)</a>. A human-readable <a href="http:// www.w3.org/community/about/ agreements/fsa- deed/">summary</a> is available.</strong>
  </p></blockquote>
mailing list <a href="mailto: odrl-version2@odrl.net">odrl- version2@odrl.net</a> <h2><a name="contents">Table of contents</a></h2>
(archived at <a href="http:// odrl.net/pipermail/ odrl-version2_ odrl.net/">http://odrl.net/ pipermail/odrl- version2_odrl.net/</a>)  
and in the public <a href="http:// odrl.net/wiki/ tiki-index.php">ODRL Initiative Wiki</a>.  
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 ODRL Initiative.  
This document uses the following visual indicators for substantial differences from the previous version:  
<ul> <ul>
<li>  
<div class="diff-chg">Green background - Previous content has been updated</div></li>  
  <li><a href="#section-1">1. Overview</a> </li>
  <li><a href="#section-2">2. ODRL Core Model</a> </li>
<li>   <ul>
   <li><a href="#section-21">2.1 Policy</a> </li>
   <li><a href="#section-22">2.2 Asset</a> </li>
   <ul><li><a href="#section-221">2.2.1 Relation</a></li></ul>
   <li><a href="#section-23">2.3 Party</a> </li>
   <ul><li><a href="#section-231">2.3.1 Role</a></li></ul>
   <li><a href="#section-24">2.4 Permission</a> </li>
   <li><a href="#section-25">2.5 Duty</a> </li>
   <li><a href="#section-26">2.6 Prohibition</a> </li>
   <li><a href="#section-27">2.7 Action</a> </li>
   <li><a href="#section-28">2.8 Constraint</a> </li>
   </ul>
  <li><a href="#section-3">3. Scenarios (Informative)</a> </li>
  <li><a href="#section-4">4. Profiles (Informative)</a> </li>
  <li><a href="#section-5">5. Experimental Features (Informative)</a></li>
<div class="diff-new">Yellow background - New content has been added</div></li> <li><a href="#section- Acknowledgements" >Acknowledgements</a> </li>
<li>  
<div class="diff-del">Pink background and strikeout - Previous content has been deleted</div></li>  
  <li><a href="#section- References">References</a> </li>
</ul> </ul>
<h2><a name="contents"></a>Table of contents</h2>  
<ul>  
<li><a href="#section-1">1. Overview</a></li>  
<li><a href="#section-2">2. ODRL Core Model</a></li>  
<ul>  
<li><a href="#section-21">2.1 Policy</a></li>  
<li><a href="#section-22">2.2 Asset</a></li>  
<ul>  
<li><a href="#section-221">2.2.1 Relation</a></li>  
</ul>  
<li><a href="#section-23">2.3 Party</a></li>  
<ul>  
<li><a href="#section-231">2.3.1 Role</a></li>  
</ul>  
<li><a href="#section-24">2.4 Permission</a></li>  
<li><a href="#section-25">2.5 Duty</a></li>  
<li><a href="#section-26">2.6 Prohibition</a></li>  
<li><a href="#section-27">2.7 Action</a></li>  
<li><a href="#section-28">2.8 Constraint</a></li>  
</ul>  
<li><a href="#section-3">3. Scenarios (Informative)</a></li>  
<li><a href="#section-4">4. Profiles (Informative)</a></li>  
<li><a href="#section-5">5. Experimental Features (Informative)</a></li>  
<li><a href="#section- Acknowledgements" >Acknowledgements</a></li>  
<li><a href="#section- References">References</a></li>  
</ul>  
<hr />  <hr>
<h2><a name="section-1"></a>1. Overview</h2> <h2><a name="section-1"></a>1. Overview</h2>
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.<a href="#section- References">[ODRL11]</a>  
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.  
  <p>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.<a href="#section- References">[ODRL11]</a></p>
  <p>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.</p>
The following documents are planned for ODRL Version 2.0:  <p>The following documents are part of the ODRL Version 2.0 series:</p>
<ul> <ul>
<li>ODRL V2.0 - Requirements <a href="#section- References">[ODRL-REQ].</a>   <li>ODRL V2.0 - Requirements <a href="#section- References">[ODRL-REQ].</a> 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.</li>
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.</li>  
<li>ODRL V2.0 - Core Model <em>(this document)</em></li>  <li>ODRL V2.0 - Core Model <em>(this document)</em></li>
<li>ODRL V2.0 - Common Vocabulary. This document will specify the  
potential terms (vocabulary) used by the Core Model for policy  
expression needs across communities. (This was called the "data  
dictionary" previously.)</li>  
<li>ODRL V2.0 - Core Model - XML Encoding. The XML Encoding  
document will specify the serialisation of the Core Model in XML,  
including the normative XML Schema for the new Model and examples.</li>  
<li>ODRL V2.0 - Core Model - RDF/XML Encoding. The RDF/XML  
Encoding document will specify the serialisation of the Core Model in  
RDF/XML.</li>  
</ul>  
The new 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 <a href="#section- References">[ODRL-REQ]</a> and will be  
directly referenced in this document to ensure that they have been  
adequately addressed (where applicable).  
   <li>ODRL V2.0 - Common Vocabulary. This document specifies the terms (vocabulary) used by the Core Model for policy expression needs across communities <a href="#section- References">[ODRL-VOCAB]</a>. (This was called the "data dictionary" previously.)</li>
   <li>ODRL V2.0 - XML Encoding. The XML Encoding document specifies the serialisation of the Core Model in XML <a href="#section- References">[ODRL- XML]</a>.</li>
The model shall be formally specified using UML notation <a href="#section- References">[UML]</a> [ODRL-REQ#6] and shall utilise the  <li>ODRL V2.0 - RDF Encoding. The RDF Encoding document will specify the serialisation of the Core Model in W3C Semantic Web languages.</li>
key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",  
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in  
accordance to <a href="#section- References">[RFC2119]</a>.  
To make keywords easily distinguishable, this document  
uses syntax highlighting based on the following rules:  
<ul>  
<li>Core Model entities (classes in the UML diagram) begin  
with a capital letter and are formatted  
in bold fonts, e.g. <code>Party</code>,  
<code>Asset</code> or <code>Role</code>.</li>  
<li>The entities' attributes begin with a lower-case letter and are  
formatted in bold fonts, e.g. <code>uid</code>,  
<code>type</code> or <code>function</code>.  
Attribute names comprising several words are written in "camelCase",  
i.e. each new word begins with a capital letter, e.g.  
<code>inheritFrom</code> or  
<code>rightOperand< /code>.</li>  
<li>The concrete values that the attributes can take begin with  
lower-case letters and formatted in typewriter font, e.g.  
<code>invalid</code>,  
<code>assigner</code> or <code>true</code>.  
CamelCase is also used for values, where necessary.</li>  
</ul> </ul>
  <p>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 <a href="#section- References">[ODRL-REQ]</a> and will be directly referenced in this document to ensure that they have been adequately addressed (where applicable).</p>
  <p>The model shall be formally specified using UML notation <a href="#section- References">[UML]</a> <a href="#section- References">[ODRL-REQ-6]</a> and shall utilise the key words "MUST", "MAY", "REQUIRED", and "OPTIONAL" in accordance to <a href="#section- References">[RFC2119]</a>.
  </p>
  <p>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.</P>
<h2><a name="section-2"></a>2. ODRL Core Model</h2> <h2><a name="section-2"></a>2. ODRL Core Model</h2>
Figure 2.1 below shows the complete version 2.0 ODRL Core Model. <code>Policy</code> 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 <code>uid</code> attribute. <code>Policy</code> can  
refer to <code>Permission</code>s and <code>Prohibition</code>s.  
A <code>Permission</code>  
<em>allows</em> a particular <code>Action</code> to be executed  
on a related <code>Asset</code>, e.g. "play the audio  
file abc.mp3". A <code>Constraint</code> like "at  
most 10 times" might be added to specify the <code>Permission</code> more precisely.  
The <code>Party</code> that grants this <code>Permission</code> is linked to it with the <code>Role</code> <code>assigner</code>,  
  <p>Figure 2.1 below shows the complete version 2.0 ODRL Core Model. <code>Policy</code> 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 <code>uid</code> attribute. <code>Policy</code> can refer to <code>Permission</code>s and <code>Prohibition</code>s.
the <code>Party</code> </p>
that is granted the <code>Permission</code> is linked to it  
with the <code>Role</code> <code>assignee</code>,  
e.g. "<code>assigner</code>  
VirtualMusicShop grants the <code>Permission</code>  
to <code>assignee</code> Alice".  
Additionally, a <code>Permission</code> may be linked to  
<code>Duty</code> entities.  
Similar to  
<code>Permission</code>s, a <code>Duty</code>  
states that a certain <code>Action</code> <em>should</em> be  
  <p>
  A <code>Permission</code> <em>allows</em> a particular <code>Action</code> to be executed on a related <code>Asset</code>, e.g. "play the audio file abc.mp3". A <code>Constraint</code> like "at most 10 times" might be added to specify the <code>Permission</code> more precisely. The <code>Party</code> that grants this <code>Permission</code> is linked to it with the <code>Role</code> <code>assigner</code>, the <code>Party</code> that is granted the <code>Permission</code> is linked to it with the <code>Role</code> <code>assignee</code>, e.g. "<code>assigner</code> VirtualMusicShop grants the <code>Permission</code> to <code>assignee</code> Alice". Additionally, a <code>Permission</code> MAY be linked to <code>Duty</code> entities.
  </p>
  <p>
  Similar to <code>Permission</code>s, a <code>Duty</code> states that a certain <code>Action</code> MAY be executed by the <code>Party</code> with the <code>Role</code> <code>assignee</code> for the <code>Permission</code> to be valid, e.g. "Alice must pay 5 EUR in order to get the <code>Permission</code> to play abc.mp3". </p>
executed by the <code>Party</code> with the <code>Role</code> <code>assignee</code> for the <code>Permission</code> to be valid, e.g. "Alice must pay 5 EUR  <p>The <code>Prohibition</code> entity is used in the same way as <code>Permission</code>, with the two differences that it does not refer to <code>Duties</code> and (obviously) that it <em>forbids</em> the <code>Action</code>, e.g. "Alice is forbidden to use abc.mp3 commercially".
in order to get the <code>Permission</code> to play abc.mp3".  
The <code>Prohibition</code> entity is used in the same way  
as <code>Permission</code>, with the two differences that it  
does not refer to <code>Duties</code> and (obviously) that it  
<em>forbids</em> the <code>Action</code>, e.g. "Alice is  
forbidden to use abc.mp3 commercially".  
<div class="diff-chg">  
  </p>
<table align="center"> <table align="center">
<tbody>   <tbody>
<tr align="center">  
<td><img src="images/core- model-feb11.png" alt="ODRL Core Model Version 2.0" width="700" /></td>  
   <tr align="center">
   <td>
   <p><a href="https:/ /www.w3.org/community/odrl/ files/2011/11/ core-model.png"><img src="https:// www.w3.org/community/odrl/ files/2011/11/ core-model.png" alt="ODRL Core Model" width="640" class="aligncenter size-full wp-image-244" /></a></p>
   </td>
</tr>   </tr>
<tr align="center">   
   <tr align="center">
   <td>
<td><strong>Figure 2.1 - ODRL Core Model Version 2.0</strong></td>   <p><b>Figure 2.1 - ODRL Core Model Version 2.0</b></p>
   </td>
</tr>   </tr>
</tbody>   </tbody>
</table> </table>
</div>  
The following sections describes each entity of the Core Model in  <p>The following sections describes each entity of the Core Model in greater detail.</p>
greater detail.  
<h3><a name="section-21"></a>2.1 Policy</h3> <h3><a name="section-21"></a>2.1 Policy</h3>
The <code>Policy</code> entity is the top-level  <p>The <code>Policy</code> entity is the top-level entity and contains the following attributes:</p>
entity and contains the following attributes:  
<ul> <ul>
<li><code>uid</code>: the unique identification  
of the <code>Policy</code> entity (REQUIRED)</li>  
<li><code>type</code>: indicates the semantics  
of the <code>Policy</code> entity (REQUIRED). These are further  
described in the Common Vocabulary and ODRL Profiles.</li>  
<li><code>conflict</code>: indicates the  
   <li><code>uid</code>: the unique identification of the <code>Policy</code> entity (REQUIRED)</li>
   <li><code>type</code>: indicates the semantics of the <code>Policy</code> entity (REQUIRED). These are further described in the Common Vocabulary and ODRL Profiles.</li>
   <li><code>conflict</code>: indicates the precedence between <code>Permission</code>s and <code>Prohibition</code>s (OPTIONAL)</li>
precedence between <code>Permission</code>s and <code>Prohibition</code>s (OPTIONAL)</li>   <li><code>undefined</code>: indicates how to handle undefined <code>Action</code>s (OPTIONAL)</li>
<li><code>undefined</code>: indicates how to  
handle undefined <code>Action</code>s (OPTIONAL)</li>  
<li><code>inheritAllowed</code>: indicates if the <code>Policy</code> entity can be inherited (OPTIONAL)</li>  <li><code>inheritAllowed</code>: indicates if the <code>Policy</code> entity can be inherited (OPTIONAL)</li>
<li><code>inheritFrom</code>: the identifier from which this <code>Policy</code> inherits from it's parent <code>Policy</code> (OPTIONAL)</li>   <li><code>inheritFrom</code>: the identifier from which this <code>Policy</code> inherits from it's parent <code>Policy</code> (OPTIONAL) </li>
<li><code>inheritRelation</code>: the identifier for the relationship type of this inheritance structure (OPTIONAL)</li>   <li><code>inheritRelation</code>: the identifier for the relationship type of this inheritance structure (OPTIONAL) </li>
</ul> </ul>
The <code>uid</code> attribute MUST be a unique identifier.  <p>The <code>uid</code> attribute MUST be a unique identifier.</p>
<div class="diff-chg">  
The range of values for the <code>Policy</code> entity's <code>type</code> attribute will be described in the Common  
Vocabulary document or in community profiles. This value may also impose  
  <p>The range of values for the <code>Policy</code> entity's <code>type</code> 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 <code>Offer</code> and <code>Agreement</code>. It is important that the <code>type</code> attribute be clearly understood in policy expressions as the semantics MAY impose restrictions on the expression language constructs such as cardinalities between entities. </p>
further constraints on the Core Model, such as are exemplified in the Scenarios for types <code>Offer</code> and <code>Agreement</code>. It is important that the <code>type</code> attribute be clearly understood in policy expressions as the semantics may impose restrictions on the expression language constructs such as cardinalities between entities. <p>The <code>conflict</code> attribute is used to resolve conflicts arising from the merging of policies, specifically when there are conflicting <code>Action</code>s in the <code>Permission</code>s and <code>Prohibition</code>s. If present, the <code>conflict</code> attribute MUST take one of the following values:</p>
</div>  
The <code>conflict</code> attribute is used to  
resolve conflicts arising from the merging of policies, specifically  
when there are conflicting <code>Action</code>s in the <code>Permission</code>s and <code>Prohibition</code>s.  
If present, the <code>conflict</code> attribute MUST  
take one of the following values:  
<ul> <ul>
<li><code>perm</code>: the <code>Permission</code>s   <li><code>perm</code>: the <code>Permission</code>s will always takes precedence</li>
will always takes precedence</li>  
<li><code>prohibit</code>: the <code>Prohibition</code>s   <li><code>prohibit</code>: the <code>Prohibition</code>s will always takes precedence</li>
will always takes precedence</li>  
<li><code>invalid</code>: the policy is not valid</li>  <li><code>invalid</code>: the policy is not valid</li>
</ul> </ul>
If the <code>conflict</code> attribute is not  
explicitly set, its default value will be used instead. The default  
value of the <code>conflict</code> attribute is <code>invalid</code>.  
The <code>undefined</code> attribute is used to  
indicate how to support <code>Action</code>s that are not  
part of any known profile in the policy expression system. If present,  
the <code>undefined</code> attribute MUST take one of  
  <p>If the <code>conflict</code> attribute is not explicitly set, its default value will be used instead. The default value of the <code>conflict</code> attribute is <code>invalid</code>.</p>
  <p>The <code>undefined</code> attribute is used to indicate how to support <code>Action</code>s that are not part of any known profile in the policy expression system. If present, the <code>undefined</code> attribute MUST take one of
the following values:  the following values:</p>
<ul> <ul>
<li><code>support</code>: the <code>Action</code>  
is to be supported as part of the policy - and the policy remains   <li><code>support</code>: the <code>Action</code> is to be supported as part of the policy - and the policy remains valid</li>
valid</li>  
<li><code>ignore</code>: the <code>Action</code>  
   <li><code>ignore</code>: the <code>Action</code> is to be ignored and not part of the policy - and the policy remains valid</li>
is to be ignored and not part of the policy - and the policy remains  <li><code>invalid</code>: the <code>Action</code> is unknown - and the policy is invalid</li>
valid</li>  
<li><code>invalid</code>: the <code>Action</code>  
is unknown - and the policy is invalid</li>  
</ul> </ul>
In the <code>support</code> case, even though the <code>Action</code> is unknown, the policy still is valid and  
the consuming parties or system of the policy MUST be made aware of the  
unknown <code>Action</code>. This may be via a user  
  <p>In the <code>support</code> case, even though the <code>Action</code> is unknown, the policy still is valid and the consuming parties or system of the policy MUST be made aware of the unknown <code>Action</code>. This MAY be via a user interface that displays the unknown <code>Action</code> for human readability.</p>
  <p>In the <code>ignore</code> case, even though the <code>Action</code> is unknown, the policy still is valid and the consuming parties or system of the policy MAY be made aware of the unknown <code>Action</code>.</p>
  <p>In the <code>invalid</code> case with the unknown <code>Action</code>, the policy is invalid and the consuming parties or system of the policy MUST be made aware of this.</p>
  <p>If the <code>undefined</code> attribute is not explicitly set, its default value will be used instead. The default value of the <code>undefined</code> attribute is <code>invalid</code>.</p>
  <p>Other attributes MAY be added to the <code>Policy</code> 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 <code>Policy</code> entity, use of the <a href="http:// dublincore.org/documents/ dcmi-terms/">Dublin Core Metadata Terms</a> would be recommended.
interface that displays the unknown <code>Action</code> </p>
for human readability.  
In the <code>ignore</code> case, even though the <code>Action</code> is unknown, the policy still is valid and  
the consuming parties or system of the policy MAY be made aware of the  
unknown <code>Action</code>.  
In the <code>invalid</code> case with the unknown <code>Action</code>, the policy is invalid and the consuming  
parties or system of the policy MUST be made aware of this.  
If the <code>undefined</code> attribute is not  
explicitly set, its default value will be used instead. The default  
value of the <code>undefined</code> attribute is <code>invalid</code>.  
Other attributes may be added to the <code>Policy</code> 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 <code>Policy</code> entity, use of the <a href="http:// dublincore.org/documents/ dcmi-terms/">Dublin Core Metadata Terms</a> would be recommended.   
<h4><a name="section- 211"></a>2.1.1 Inheritance</h4> <h4><a name="section- 211"></a>2.1.1 Inheritance</h4>
The <code>inheritAllowed</code> attribute in the <code>Policy</code> entity is used to indicate if the <code>Policy</code> expression can be used in any inheritance  <p>The <code>inheritAllowed</code> attribute in the <code>Policy</code> entity is used to indicate if the <code>Policy</code> expression can be used in any inheritance relationship [ODRL-REQ-1.20]. If present, the value of the <code>inheritAllowed</code> attribute MUST take one of the following values:</p>
relationship [ODRL-REQ#1.20]. If present, the value of the <code>inheritAllowed</code>  
attribute MUST take one of the following values:  
<ul> <ul>
<li><code>true</code>: the <code>Policy</code>  
expression can be used for inheritance</li>  
<li><code>false</code>: the <code>Policy</code>   <li><code>true</code>: the <code>Policy</code> expression can be used for inheritance</li>
expression can not be used for inheritance</li>  
   <li><code>false</code>: the <code>Policy</code> expression can not be used for inheritance</li>
</ul> </ul>
If the <code>inheritAllowed</code> attribute is not  
explicitly set, its default value will be used instead. The default  
value of the <code>inherit</code> attribute is <code>true</code>.  
  <p>If the <code>inheritAllowed</code> attribute is not explicitly set, its default value will be used instead. The default value of the <code>inherit</code> attribute is <code>true</code>.</p>
Only if the <code>inheritAllowed</code> attribute has the value <code>true</code> can the <code>inheritFrom</code> and <code>inheritRelation</code> attributes be specified.  <p>Only if the <code>inheritAllowed</code> attribute has the value <code>true</code> can the <code>inheritFrom</code> and <code>inheritRelation</code> attributes be specified.</p>
The <code>inheritFrom</code> attribute in the (child) <code>Policy</code> will uniquely identify (via a UID) the (parent)  
<code>Policy</code> from which the inheritance will be performed.  
  <p> The <code>inheritFrom</code> attribute in the (child) <code>Policy</code> will uniquely identify (via a UID) the (parent) <code>Policy</code> from which the inheritance will be performed.</p>
The <code>inheritRelation</code> attribute in the (child) <code>Policy</code> will uniquely identify (via a UID) the type of inheritance from the (parent) <code>Policy</code>. For example, this may indicate the business scenario, such as <em>subscription</em> or other inheritance structures such as <em>expression, manifestation</em>. Such terms may be defined in the Common Vocabulary or community Profiles.  <p> The <code>inheritRelation</code> attribute in the (child) <code>Policy</code> will uniquely identify (via a UID) the type of inheritance from the (parent) <code>Policy</code>. For example, this may indicate the business scenario, such as <em>subscription</em>. Such terms MAY be defined in the Common Vocabulary or community Profiles.</p>
The following restrictions apply when using inheritance:  <p>The following restrictions apply when using inheritance:</p>
<ul> <ul>
<li>Single inheritance is only supported. (One Parent <code>Policy</code> to one or more Child <code>Policy</code> entities.   <li>Single inheritance is only supported. (One Parent <code>Policy</code> to one or more Child <code>Policy</code> entities. No Child <code>Policy</code> can inherit from two or more Parent <code>Policy</code> entities.)</li>
No Child <code>Policy</code> can inherit from two or more  
Parent <code>Policy</code> entities.)</li>  
<li>Inheritance can be to any depth. (Multiple levels of Children <code>Policy</code> entities.)</li>  <li>Inheritance can be to any depth. (Multiple levels of Children <code>Policy</code> entities.)</li>
<li>Inheritance cannot be circular.</li>  <li>Inheritance cannot be circular.</li>
<li>The Child <code>Policy</code> will always  
override the Parent <code>Policy</code>. i.e.: If the  
same <code>Action</code> appears in the Parent, then it  
is replaced by the Child version, otherwise the Parent <code>Action</code>s are added to the Child's <code>Action< /code>s.</li>   <li>The Child <code>Policy</code> MUST override the Parent <code>Policy</code>. i.e.: If the same <code>Action</code> appears in the Parent, then it is replaced by the Child version, otherwise the Parent <code>Action</code>s are added to the Child's <code>Action< /code>s.</li>
<li>No state information is transferred from the policy in the Parent <code>Policy</code> to the Child <code>Policy</code></li>  <li>No state information is transferred from the policy in the Parent <code>Policy</code> to the Child <code>Policy</code></li>
</ul> </ul>
<h3><a name="section-22"></a>2.2 Asset</h3> <h3><a name="section-22"></a>2.2 Asset</h3>
<div class="diff-chg">  
The <code>Asset</code> 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 <code>Asset</code> entities that are needed to undertake the Policy expression, such as with the <code>Duty</code> entity.  
The <code>Asset</code> entity is referred to by the  
  <p>The <code>Asset</code> 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 <code>Asset</code> entities that are needed to undertake the Policy expression, such as with the <code>Duty</code> entity. The <code>Asset</code> entity is referred to by the <code>Permission</code> and/or <code>Prohibition</code> entities, and also by the <code>Duty</code> entity.</p>
<code>Permission</code> and/or <code>Prohibition</code> entities, and also by the <code>Duty</code> entity. <p>The <code>Asset</code> entity contains the following attribute:</p>
</div>  
The <code>Asset</code> entity contains the  
following attribute:  
<ul> <ul>
<li><code>uid</code>: the unique identification   <li><code>uid</code>: the unique identification of the <code>Asset</code> (REQUIRED)</li>
of the <code>Asset</code> (REQUIRED)</li>  
</ul> </ul>
<div class="diff-new">  
The identification of the <code>Asset</code> 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 <code>Asset</code>.  
  <p>
  The identification of the <code>Asset</code> 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 <code>Asset</code>. In these cases, it MAY be more appropriate to provide, or infer, a link to the <code>Asset</code> entity (as the complete <code>Asset</code> <code>uid</code> may not be known at the time) through the local context. Use of such inference and context MUST be documented in the relevant ODRL community Profile.
  </p>
In these cases, it may be more appropriate to provide, or infer, a link to the <code>Asset</code> entity (as the complete <code>Asset</code> <code>uid</code> 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. <p>Since ODRL policies could deal with any kind of asset, the ODRL Core Model does not provide additional metadata to describe <code>Asset</code> entities of particular media types. It is recommended to use already existing metadata standards, such as <a href="http:// dublincore.org/documents/ dcmi-terms/">Dublin Core Metadata Terms</a> that are appropriate to the <code>Asset</code> type or purpose.</p>
</div>   
Since ODRL policies could deal with any kind of asset, the ODRL  
Core Model does not provide additional metadata to describe  
<code>Asset</code> entities of particular media types. It is  
recommended to use already existing metadata standards, such as <a href="http:// dublincore.org/documents/ dcmi-terms/">Dublin Core Metadata Terms</a> that are appropriate to the <code>Asset</code> type or purpose.  
<div class="diff-new">  
  <p>
The <code>Relation</code> entity is used to associate the <code>Asset</code> entity with the relevant <code>Permission</code>, <code>Prohibition</code>, and <code>Duty</code> entities The <code>Relation</code> entity is used to associate the <code>Asset</code> entity with the relevant <code>Permission</code>, <code>Prohibition</code>, and <code>Duty</code> entities
</div>  </p>
<div class="diff-new">  
<h4><a name="section- 231"></a>2.2.1 Relation</h4> <h4><a name="section- 231"></a>2.2.1 Relation</h4>
The <code>Relation</code> entity is an association class and can be used to link to an  
<code>Asset</code> from either <code>Permission</code>,  
<code>Duty</code> or <code>Prohibition</code>,  
indicating how the <code>Asset</code> <em>should</em> be utilised in  
respect to the entity that links to it.  
  <p>The <code>Relation</code> entity is an association class and can be used to link to an <code>Asset</code> from either <code>Permission</code>, <code>Duty</code> or <code>Prohibition</code>, indicating how the <code>Asset</code> MAY be utilised in respect to the entity that links to it. </p>
The <code>Relation</code> entity contains the following attribute:  <p>The <code>Relation</code> entity contains the following attribute:</p>
<ul> <ul>
<li><code>relation</code>: indicates the relationship of the <code>Asset</code> to the linked entity (REQUIRED)</li>  <li><code>relation</code>: indicates the relationship of the <code>Asset</code> to the linked entity (REQUIRED)</li>
</ul> </ul>
The default value for the <code>relation</code> attribute is <code>target</code> which indicates that the <code>Asset</code> is the primary object to which the <code>Permission</code>,  <p>The default value for the <code>relation</code> attribute is <code>target</code> which indicates that the <code>Asset</code> is the primary object to which the <code>Permission</code>, <code>Duty</code> or <code>Prohibition</code> actions apply.</p>
<code>Duty</code> or <code>Prohibition</code> actions apply.  
Other values for the <code>Relation</code> entity may be defined in the Common Vocabulary and community Profiles.  <p>Other values for the <code>Relation</code> entity MAY be defined in the Common Vocabulary and community Profiles.</p>
</div>  
<h3><a name="section-23"></a>2.3 Party</h3> <h3><a name="section-23"></a>2.3 Party</h3>
The <code>Party</code> entity is aimed at  
  <p>The <code>Party</code> entity is aimed at identifying a person, group of people, or organisation. The <code>Party</code> MUST identify a (legal) entity that can participate in policy transactions [ODRL-REQ-1.5].</p>
identifying a person, group of people, or organisation. The <code>Party</code> MUST identify a (legal) entity that can <p>The <code>Party</code> entity contains the following attribute:</p>
participate in policy transactions [ODRL-REQ#1.5].  
The <code>Party</code> entity contains the  
following attribute:  
<ul> <ul>
<li><code>uid</code>: the unique identification   <li><code>uid</code>: the unique identification of the party (REQUIRED)</li>
of the party (REQUIRED)</li>  
   <li><code>scope</code>: defines how the role shall be interpreted under different contexts. (OPTIONAL)</li>
</ul> </ul>
The ODRL Core Model does not provide additional metadata for the  
<code>Party</code> element. It is recommended to use already existing metadata  
standards, such as <a href="http:// tools.ietf.org/html/draft- ietf-vcarddav- vcardrev">IETF vCard</a> that are appropriate to the <code>Party</code> type or purpose.  
  <p>The ODRL Core Model does not provide additional metadata for the <code>Party</code> element. It is recommended to use already existing metadata standards, such as <a href="http:// tools.ietf.org/html/draft- ietf-vcarddav- vcardrev">IETF vCard</a> that are appropriate to the <code>Party</code> type or purpose.</p>
The <code>Role</code> entity is used to associate the <code>Party</code> entity with the relevant <code>Permission</code>, <code>Prohibition</code>, and <code>Duty</code> entities.  <p>The <code>Role</code> entity is used to associate the <code>Party</code> entity with the relevant <code>Permission</code>, <code>Prohibition</code>, and <code>Duty</code> entities.</p>
<h4><a name="section- 231"></a>2.3.1 Role</h4> <h4><a name="section- 231"></a>2.3.1 Role</h4>
The <code>Role</code> entity is an association class and can be used to link to a  
<code>Party</code> from either <code>Permission</code>,  
<code>Duty</code> or <code>Prohibition</code>,  
indicating which role the <code>Party</code> takes with  
respect to the entity that links to it.  
  <p>The <code>Role</code> entity is an association class and can be used to link to a <code>Party</code> from either <code>Permission</code>, <code>Duty</code> or <code>Prohibition</code>, indicating which role the <code>Party</code> takes with respect to the entity that links to it.</p>
The <code>Role</code> entity contains the following  <p>The <code>Role</code> entity contains the following attributes:</p>
attributes:  
<ul> <ul>
<li><code>function</code>: the functional role the   <li><code>function</code>: the functional role the <code>Party</code> takes (REQUIRED)</li>
<code>Party</code> takes (REQUIRED)</li>  
<li><code>scope</code>: defines how the role shall  
be interpreted under different contexts. (OPTIONAL)</li>  
</ul> </ul>
The <code>function</code> attribute MUST take one of the  <p>The <code>function</code> attribute MUST take one of the following values:</p>
following values:  
<ul> <ul>
<li><code>assigner</code>: indicates that the  
<code>Party</code> has assigned the associated  
<code>Permission</code>, <code>Duty</code>,  
or <code>Prohibition</code>. In other words, the  
<code>Party</code> grants a <code>Permission</code>  
or requires a <code>Duty</code> to be performed or states  
a <code>Prohibition< /code>.</li>  
<li><code>assignee</code>: indicates that the  
<code>Party</code> has been assigned the associated entity, i.e.  
they are granted a <code>Permission</code> or required  
to perform a <code>Duty</code> or have to adhere to a  
   <li><code>assigner</code>: indicates that the <code>Party</code> has assigned the associated <code>Permission</code>, <code>Duty</code>, or <code>Prohibition</code>. In other words, the <code>Party</code> grants a <code>Permission</code> or requires a <code>Duty</code> to be performed or states a <code>Prohibition< /code>.</li>
<code>Prohibition< /code>.</li> 
   <li><code>assignee</code>: indicates that the <code>Party</code> has been assigned the associated entity, i.e. they are granted a <code>Permission</code> or required to perform a <code>Duty</code> or have to adhere to a <code>Prohibition< /code>.</li>
</ul> </ul>
Other values for the <code>function</code> attribute may be defined in the Common Vocabulary and community Profiles.  <p>Other values for the <code>function</code> attribute MAY be defined in the Common Vocabulary and community Profiles.</p>
The <code>scope</code> attribute MAY be used to indicate the context under which to interpret the <code>Party</code> entity. If present, the  
<code>scope</code> attribute MAY take one of the  
following values:  
  <p>The <code>scope</code> attribute MAY be used to indicate the context under which to interpret the <code>Party</code> entity. If present, the <code>scope</code> attribute MAY take one of the following values:</p>
<ul> <ul>
<li><code>individual</code>: indicates that the <code>Party</code> entity is a single individual. The linked  
<code>Permission</code>, <code>Duty</code>  
or <code>Prohibition</code> is applicable for that individual  
   <li><code>individual</code>: indicates that the <code>Party</code> entity is a single individual. The linked <code>Permission</code>, <code>Duty</code> or <code>Prohibition</code> is applicable for that individual only.
   </li>
   <li><code>group</code>: indicates that the <code>Party</code> entity represents a group. The group consisting of many individual members. The linked <code>Permission</code>, <code>Duty</code> or <code>Prohibition</code> is applicable for each member of that group. For example, a (constrained) <code>Permission</code> to play a movie 5 times is valid for each <code>Party</code> member or the <code>Duty</code> to pay 3 EUR has to be fulfilled by each <code>Party</code> member.
only.</li>   </li>
<li><code>group</code>: indicates that the <code>Party</code> entity represents a group. The group consisting of many individual members. The linked <code>Permission</code>, <code>Duty</code>   
or <code>Prohibition</code> is applicable for each member of that group.  
For example, a (constrained) <code>Permission</code> to  
play a movie 5 times is valid for each <code>Party</code>  
member or the <code>Duty</code> to pay 3 EUR has to be  
fulfilled by each <code>Party</code> member.</li>  
</ul> </ul>
Other values for the <code>scope</code> attribute may be defined in the Common Vocabulary and community Profiles.  <p>Other values for the <code>scope</code> attribute MAY be defined in the Common Vocabulary and community Profiles.</p>
<h3><a name="section-24"></a>2.4 Permission</h3> <h3><a name="section-24"></a>2.4 Permission</h3>
  <p>The <code>Permission</code> entity indicates the <code>Action</code>s that the <code>assignee</code> is permitted to perform on the associated <code>Asset</code>. In other words, what the <code>assigner</code> (supplier) has granted to the <code>assignee</code> (consumer). </p>
  <p>An ODRL policy expression MAY contain at least one <code>Permission</code>. It is important to verify the semantics of the <code>Policy</code> <code>type</code> attribute as this MAY indicate additional constraints on the Policy expression structure.
  If several <code>Permission</code> entities are referred to by a <code>Policy</code>, then <em>all of them</em> are valid.</p>
The <code>Permission</code> entity indicates the <code>Action</code>s that the <code>assignee</code>  <p>The <code>Permission</code> entity has the following relations:</p>
is permitted to perform on the associated <code>Asset</code>.  
In other words, what the <code>assigner</code>  
(supplier) has granted to the <code>assignee</code>  
(consumer).  
<div class="diff-chg">  
An ODRL policy expression <em>should</em> contain at least one <code>Permission</code>. It is important to verify the semantics of the <code>Policy</code> <code>type</code> attribute as this <em>may</em> indicate additional constraints on the Policy expression structure.   
If several <code>Permission</code> entities are referred to by a  
<code>Policy</code>, then <em>all of them</em> are valid.  
</div>  
<div class="diff-chg">  
The <code>Permission</code> entity has the  
following relations:  
<ul> <ul>
<li><code>Asset</code>: the <code>Permission</code>  
   <li><code>Asset</code>: the <code>Permission</code> entity MUST refer to an <code>Asset</code> (where at least one, and only one, <code>relation</code> value is <code>target</code>) on which the linked <code>Action</code> MAY be performed (REQUIRED)</li>
   <li><code>Action</code>: the <code>Permission</code> entity MUST refer to <em>exactly one</em> <code>Action</code> that indicates the granted operation on the target <code>Asset</code> (REQUIRED)</li>
  
entity <em>must</em> refer to an <code>Asset</code> (where at least one <code>relation</code> value is <code>target</code>)   <li><code>Party</code>: the <code>Permission</code> MUST refer to one or more <code>Party</code> entities linked via the <code>Role</code> entity (see Section 2.3.1) (OPTIONAL) </li>
on which the linked <code>Action</code> may be performed  
(REQUIRED)</li>  
<li><code>Action</code>: the <code>Permission</code>  
entity <em>must</em> refer to <em>exactly one</em> <code>Action</code>  
that indicates the granted operation on the target <code>Asset</code>  
(REQUIRED)</li>  
<li><code>Party</code>: the <code>Permission</code>  
<em>may</em> refer to one or more <code>Party</code> entities linked via the  
<code>Role</code> entity (see Section 2.3.1) (OPTIONAL)</li>  
  
  
   <li><code>Constraint</code>: the <code>Permission</code> MAY refer to one or more <code>Constraint</code>s which affect the validity of the <code>Permission</code>, e.g. if the <code>Action</code> <code>play</code> is only permitted for a certain period of time (OPTIONAL)</li>
<li><code>Constraint</code>: the 
<code>Permission</code> <em>may</em> refer to one or more  
<code>Constraint</code>s which affect the validity of the  
<code>Permission</code>, e.g. if the  
<code>Action</code> <code>play</code>  
is only permitted for a certain period of time (OPTIONAL)</li>  
<li><code>Duty</code>: the <code>Permission</code>  
<em>may</em> refer to one or more <code>Duty</code> entities that  
indicate a requirement that <em>may</em> be fulfilled in return for receiving  
the <code>Permission</code> (OPTIONAL)</li>  
   <li><code>Duty</code>: the <code>Permission</code> MAY refer to one or more <code>Duty</code> entities that indicate a requirement that MAY be fulfilled in return for receiving the <code>Permission</code> (OPTIONAL)</li>
</ul> </ul>
</div>  
<h3><a name="section-25"></a>2.5 Duty</h3> <h3><a name="section-25"></a>2.5 Duty</h3>
The <code>Duty</code> entity indicates a  
requirement that <em>should</em> be fulfilled in return for being entitled to the  
referring <code>Permission</code> entity [ODRL-REQ#1.8].  
While implying different semantics, the <code>Duty</code>  
entity is similar to <code>Permission</code> in that it is an Action that can be undertaken.  
If a <code>Permission</code> refers to several  
<code>Duty</code> entities, <em>all of them</em> have to  
be fulfilled for the <code>Permission</code> to become  
valid. If several <code>Permission</code> entities refer to one  
<code>Duty</code>, then the Duty only has to be fulfilled <em>once</em> for all the <code>Permission</code> entities to become valid.  
  <p>The <code>Duty</code> entity indicates a requirement that MAY be fulfilled in return for being entitled to the referring <code>Permission</code> entity [ODRL-REQ-1.8]. While implying different semantics, the <code>Duty</code> entity is similar to <code>Permission</code> in that it is an Action that can be undertaken. If a <code>Permission</code> refers to several <code>Duty</code> entities, <em>all of them</em> have to be fulfilled for the <code>Permission</code> to become valid. If several <code>Permission</code> entities refer to one <code>Duty</code>, then the Duty only has to be fulfilled <em>once</em> for all the <code>Permission</code> entities to become valid.
  </p>
The <code>Duty</code> entity contains the following  <p>The <code>Duty</code> entity contains the following attributes:</p>
attributes:  
<div class="diff-chg">  
<ul> <ul>
<li><code>uid</code>: a unique identification for this  
<code>Duty</code>. Used to refer a single <code>Duty</code> to multiple <code>Permission</code> entities (OPTIONAL)</li>   <li><code>uid</code>: a unique identification for this <code>Duty</code>. Used to refer a single <code>Duty</code> to multiple <code>Permission</code> entities (OPTIONAL)</li>
</ul> </ul>
</div>  
<div class="diff-del"> <p>The <code>Duty</code> entity has the following relations:</p>
<ul> <ul>
   <li><code>Action</code>: indicates the operation (e.g. <code>pay</code>) that MAY be performed (REQUIRED). Note: It is assumed that the assigned Party has the appropriate permissions to perform this action.
<li><code>relax</code>: indicates if the  </li>
<code>Duty</code> may be fulfilled at any time (OPTIONAL)</li>  
   <li><code>Party</code>: a <code>Duty</code> MAY refer to <code>Party</code> entities with different <code>Role</code>s (see Section 2.3.1). If no explicit <code>Party</code> is linked to as <code>assignee</code> or <code>assigner</code>, the <code>Parties</code> with the respective <code>Role</code>s are taken from the referring <code>Permission</code>. (OPTIONAL)</li>
   <li><code>Asset</code>: a <code>Duty</code> entity MAY refer to an <code>Asset</code> (where at least one, and only one, <code>relation</code> value is <code>target</code>) related to fulfilling the <code>Duty</code>. For example, a <code>pay</code> <code>Action</code> must be linked to a target <code>Asset</code> that indicates the amount to pay. The mechanisms to perform this linking/packaging are defined by community Profiles. (OPTIONAL)</li>
  
   <li><code>Constraint</code>: a <code>Duty</code> MAY link to one or more <code>Constraint</code>s [ODRL-REQ-1.10] (OPTIONAL)</li>
</ul> </ul>
</div>  
<div class="diff-del">  
If set, the <code>relax</code> attribute MUST take one of the  
following values:  
<ul>  
<li><code>true</code>: this means that the  
<code>Duty</code> may be fulfilled at any time, including  
after the containing <code>Permission</code> has been  
utilised by the Party with the <code>Role</code>  
<code>assignee</code></li>  
<li><code>false</code>: the  
<code>Duty</code> must be fulfilled before the  
<code>Permission</code> can be exercised</li>  
  <p>
  A <code>Duty</code> entity does not, by itself, specify any conditions on when the <code>Duty</code> <code>Action</code> MUST or MAY be performed, such as to <code>pay</code> before viewing the movie. Such conditions MAY be expressed through <code>Constraint</code> entities.
  </p>
  <p>
  To support cases where the <code>Duty</code> MAY be performed for each <code>Action</code> on an <code>Asset</code> (for example, pay-per-view) then the use of a <code>Constraint</code> (e.g. count=1) on the <code>Permission</code> (e.g. play) can express these semantics.
</ul>  </p>
If not explicitly set, <code>relax</code> takes  
the default value <code>false</code>. Note that  
the <code>Duty</code> has to be fulfilled eventually,  
regardless of the value of <code>relax</code>.  
</div>  
The <code>Duty</code> entity has the  
following relations:  
<ul>  
<ul>  
<li><code>Action</code>: indicates the operation  
(e.g. <code>pay</code>) that <em>should</em> be performed (REQUIRED). Note: It is assumed that the assigned Party has the appropriate permissions to perform this action.</li>  
<li><code>Party</code>: a <code>Duty</code>  
<em>may</em> refer to <code>Party</code> entities with  
different <code>Role</code>s (see Section 2.3.1). If no explicit  
<code>Party</code> is linked to as <code>assignee</code>  
or <code>assigner</code>, the <code>Parties</code>  
with the respective <code>Role</code>s are taken from the  
referring <code>Permission</code>. (OPTIONAL)</li>  
</ul>  
</ul>  
<div class="diff-chg">  
<ul>   
<li><code>Asset</code>: a <code>Duty</code>  
entity <em>may</em> refer to an <code>Asset</code> (where at least one <code>relation</code> value is <code>target</code>)  
related to fulfilling the <code>Duty</code>. For example, a <code>pay</code> <code>Action</code> must be linked to a target <code>Asset</code> that indicates the amount to pay. The mechanisms to perform this linking/packaging are defined by community Profiles. (OPTIONAL)</li>  
</ul>  
</div>  
<ul>   
<li><code>Constraint</code>: a <code>Duty</code>  
<em>may</em> link to one or more <code>Constraint</code>s [ODRL-REQ#1.10]  
(OPTIONAL)</li>  
</ul>   
<div class="diff-new">  
A <code>Duty</code> entity does not, by itself, specify any conditions on when the <code>Duty</code> <code>Action</code> <em>must</em> or <em>should</em> be performed, such as to <code>pay</code> before viewing the movie. Such conditions <em>should</em> be expressed through <code>Constraint</code> entities.   
</div>  
<h3><a name="section-26"></a>2.6 Prohibition</h3> <h3><a name="section-26"></a>2.6 Prohibition</h3>
  <p>The <code>Prohibition</code> entity indicates the <code>Action</code>s that the <code>assignee</code> is prohibited to perform on the related <code>Asset</code> [ODRL-REQ-1.7]. <code>Prohibition</code>s are issued by the supplier of the <code>Asset</code> - the <code>Party</code> with the <code>Role</code> <code>assigner</code>. If several <code>Prohibition</code> entities are referred to by a <code>Policy</code>, <em>all of them</em> are valid.</p>
The <code>Prohibition</code> entity indicates the  <p>The <code>Prohibition</code> entity has the following relations:</p>
<code>Action</code>s that the <code>assignee</code>  
is prohibited to perform on the related <code>Asset</code>  
[ODRL-REQ#1.7]. <code>Prohibition</code>s are issued by  
the supplier of the <code>Asset</code> - the  
<code>Party</code> with the <code>Role</code>  
<code>assigner</code>. If several  
<code>Prohibition</code> entities are referred to by a  
<code>Policy</code>, <em>all of them</em> are valid.  
The <code>Prohibition</code> entity has the  
following relations:  
<div class="diff-chg">  
<ul> <ul>
<li><code>Asset</code>: the <code>Prohibition</code>  
   <li><code>Asset</code>: the <code>Prohibition</code> entity MUST refer to an <code>Asset</code> (where at least one, and only one, <code>relation</code> value is <code>target</code>) on which the <code>Action</code> is prohibited (REQUIRED)</li>
   <li><code>Action</code>: the <code>Prohibition</code> entity MUST refer to <em>exactly one</em> <code>Action</code> that is prohibited (REQUIRED)</li>
   <li><code>Party</code>: the <code>Prohibition</code> MAY refer to one or more <code>Party</code> entities linked via the <code>Role</code> entity (see Section 2.3.1) (OPTIONAL) </li>
entity <em>must</em> refer to an <code>Asset</code> (where at least one <code>relation</code> value is <code>target</code>)  <li><code>Constraint</code>: the <code>Prohibition</code> MAY refer to one or more <code>Constraint</code> entities (OPTIONAL)</li>
on which the <code>Action</code> is prohibited  
(REQUIRED)</li>  
<li><code>Action</code>: the <code>Prohibition</code>  
entity <em>must</em> refer to <em>exactly one</em> <code>Action</code>  
that is prohibited (REQUIRED)</li>  
<li><code>Party</code>: the <code>Prohibition</code>  
<em>may</em> refer to one or more <code>Party</code> entities linked via the  
<code>Role</code> entity (see Section 2.3.1) (OPTIONAL)</li>  
<li><code>Constraint</code>: the  
<code>Prohibition</code> <em>may</em> refer to one or more  
<code>Constraint</code> entities (OPTIONAL)</li>  
</ul> </ul>
</div>  
<h3><a name="section-27"></a>2.7 Action</h3> <h3><a name="section-27"></a>2.7 Action</h3>
The <code>Action</code> entity (when related to a  
<code>Permission</code> entity) indicates the operations  
(e.g. <code>play</code>, <code>copy</code>,  
etc.) that the <code>assignee</code> (i.e. the  
consumer) is <em>permitted</em> to perform on the related <code>Asset</code>  
linked to by <code>Permission</code>.  
When related to a <code>Prohibition</code>,  
the <code>Action</code> entity indicates the  
operations that the <code>assignee</code>  
(again the consumer) is <em>prohibited</em> to perform on the  
<code>Asset</code> linked to by <code>Prohibition</code>.  
Analogously, when related to a <code>Duty</code>, it  
indicates an operation that <em>has to be</em> performed.  
<code>Action</code> contains the following attribute:  
<ul>  
<li><code>name</code>: indicates the  
<code>Action</code> entity term (REQUIRED)</li>  
</ul>  
As its value, the <code>name</code> attribute  
SHOULD take one of a set of <code>Action</code> <em>names</em>  
  <p>The <code>Action</code> entity (when related to a <code>Permission</code> entity) indicates the operations (e.g. <code>play</code>, <code>copy</code>, etc.) that the <code>assignee</code> (i.e. the consumer) is <em>permitted</em> to perform on the related <code>Asset</code> linked to by <code>Permission</code>. When related to a <code>Prohibition</code>, the <code>Action</code> entity indicates the operations that the <code>assignee</code> (again the consumer) is <em>prohibited</em> to perform on the <code>Asset</code> linked to by <code>Prohibition</code>. Analogously, when related to a <code>Duty</code>, it indicates the operation to be performed.</p>
which are formally defined in <em>profiles</em>. The ODRL <em>Common Vocabulary</em> <p><code>Action</code> contains the following attribute:</p> <ul> <li><code>name</code>: indicates the <code>Action</code> entity term (REQUIRED)</li> </ul>
defines a standard set of potential terms that may be used. Communities  
will develop new (or extend existing) <em>profiles</em> to capture  
additional/refined semantics.  
  <p>As its value, the <code>name</code> attribute MAY take one of a set of <code>Action</code> <em>names</em> 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. </p>
<h3><a name="section-28"></a>2.8 Constraint</h3> <h3><a name="section-28"></a>2.8 Constraint</h3>
The <code>Constraint</code> entity indicates  
limits and restrictions to the <code>Permission</code>,  
the <code>Prohibition</code> and the <code>Duty</code>  
entity [ODRL-REQ#1.9]. <code>Constraint</code>s express  
mathematical terms with two operands and one operator. For example, the  
"number of usages" (<code>name</code>) must be  
"smaller than" (<code>operator</code>) the "number 10"  
(<code>rightOperand</code>).  
<div class="diff-del">If several  
<code>Constraint</code>s are linked to by the same entity,  
<em>all of them</em> are valid.</div>  
<div class="diff-new">  
If multiple <code>Constraint</code> entities are linked to the same <code>Permission</code>,  
<code>Prohibition</code>, or <code>Duty</code> entity, then all of the <code>Constraint</code> entities must be satisfied. That is, all the <code>Constraint</code> entities are (boolean) <em>and</em>ed. In the case where the same <code>Constraint</code> is repeated, then these <em>must</em> be represented as a single <code>Constraint</code> entity using an appropriate <code>operator</code> value (for example, <code>isAnyOf</code>). <p>The <code>Constraint</code> entity indicates limits and restrictions to the <code>Permission</code>, the <code>Prohibition</code> and the <code>Duty</code> entity [ODRL-REQ-1.9]. <code>Constraint</code>s express mathematical terms with two operands and one operator. For example, the "number of usages" (<code>name</code>) must be "smaller than" (<code>operator</code>) the "number 10" (<code>rightOperand</code>).
</div>  
The <code>Constraint</code> entity contains the  
following attributes:  
<ul>  
<li><code>name</code>: a name that identifies  
the the left operand of the operation (REQUIRED)</li>  
<li><code>operator</code>: an operator function  
(REQUIRED)</li>  
<li><code>rightOperand</code>: the right operand  
of the operation (REQUIRED)</li>  
<li><code>status</code>: the current value of  
the left operand (OPTIONAL)</li>  
</ul>  </p>
The <code>name</code> identifies the left  
operand of the mathematical operation for the <code>Constraint</code>  
such as "Number of Usages" and "Expiration Date" etc. The <code>operator</code> identifies the comparative operation  
such as "greater than" or "equal to". The <code>rightOperand</code>  
identifies the value that is being compared. When processing policy  
expressions, these <code>Constraint</code> names <em>shall</em> be  
directly linked to a procedure that can determine the outcome of the  
operations, such as the number of already performed usages and the  
current date. The <code>name</code> and <code>operator</code> would be defined in the Common  
Vocabulary or community profiles.  
The <code>status</code> provides the current  
value of the <code>Constraint</code> variable (i.e.  
current value of <code>name</code>) [ODRL-REQ#1.3].  
This is useful in cases where the current status of <code>Constraint</code>s  
needs to be captured and expressed in the ODRL Core Model.  
  <p> If multiple <code>Constraint</code> entities are linked to the same <code>Permission</code>, <code>Prohibition</code>, or <code>Duty</code> entity, then all of the <code>Constraint</code> entities MUST be satisfied. That is, all the <code>Constraint</code> entities are (boolean) <em>and</em>ed. In the case where the same <code>Constraint</code> is repeated, then these MUST be represented as a single <code>Constraint</code> entity using an appropriate <code>operator</code> value (for example, <code>isAnyOf</code>). </p>
  <p>The <code>Constraint</code> entity contains the following attributes:</p> <ul> <li><code>name</code>: a name that identifies the the left operand of the operation (REQUIRED)</li> <li><code>operator</code>: an operator function (REQUIRED)</li> <li><code>rightOperand</code>: the right operand of the operation (REQUIRED)</li> <li><code>status</code>: the current value of the left operand (OPTIONAL) </ul>
  <p>The <code>name</code> identifies the left operand of the mathematical operation for the <code>Constraint</code> such as "Number of Usages" and "Expiration Date" etc. The <code>operator</code> identifies the comparative operation such as "greater than" or "equal to". The <code>rightOperand</code> identifies the value that is being compared. When processing policy expressions, these <code>Constraint</code> names MAY be directly linked to a procedure that can determine the outcome of the operations, such as the number of already performed usages and the current date. The <code>name</code> and <code>operator</code> are defined in the ODRL Common Vocabulary or community profiles.</p>
  <p>The <code>status</code> provides the current value of the <code>Constraint</code> variable (i.e. current value of <code>name</code>) [ODRL-REQ-1.3]. This is useful in cases where the current status of <code>Constraint</code>s needs to be captured and expressed in the ODRL Core Model.</p>
<h2><a name="section-3"></a>3. Scenarios (Informative)</h2> <h2><a name="section-3"></a>3. Scenarios (Informative)</h2>
This section shows a number of policy expression scenarios. In  
these examples, the different policy expression <code>type</code>s  
that are used are for illustrative purposes only and are not part of  
this normative specification. Also, the specific <code>Action</code>  
and <code>Constraint</code> names (etc.) used in these  
examples are for illustrative purposes only. Please note that formal  
policy expression <code>type</code>s and other  
entities will be defined in the ODRL Common Vocabulary specification, or <p>This section shows a number of policy expression scenarios. In these examples, the different policy expression <code>type</code>s that are used are for illustrative purposes only and are not part of this normative specification. Also, the specific <code>Action</code> and <code>Constraint</code> names (etc.) used in these examples are for illustrative purposes only. Please note that formal policy expression <code>type</code>s and other entities are defined in the ODRL Common Vocabulary specification, or in community profiles.</p>
in community profiles.  
<div class="diff-chg">  
<h3>3.1 Set</h3> <h3>3.1 Set</h3>
  <p>The following shows an instance of a <code>set</code> <code>Policy</code>. The <code>Set</code> shows a policy expression, stating that the <code>Asset</code> <code>http//example.com/ asset:9898</code> is the <code>target</code> of the <code>Permission</code> <code>reproduce</code> and the <code>Prohibition</code> to <code>modify</code>. No parties or other elements are involved. This <code>set</code> could be used, for example, as a template or an <em>instant license</em>.</p>
The following shows an instance of a <code>set</code> <code>Policy</code>. <table align="center"> <tbody> <tr align="center">
The <code>Set</code> shows a policy expression, stating  
that the <code>Asset</code> <code>http//example.com/ asset:9898</code>  
is the <code>target</code> of the <code>Permission</code> <code>reproduce</code> and the <code>Prohibition</code>  
to <code>modify</code>. No parties or other elements are  
involved. This <code>set</code> could be used, for  
example, as a template or an <em>instant license</em>.  
  <td> <p><a href="https:/ /www.w3.org/community/odrl/ files/2011/11/ instance-set.png"><img src="https:// www.w3.org/community/odrl/ files/2011/11/ instance-set.png" alt="Set Instance" width="640" class="aligncenter size-full wp-image-255" /></a></p> </td>
<table align="center">  </tr>
<tbody>  
<tr align="center"> <tr align="center">
<td><img src="images/instance- set-feb11.png" alt="instance set" /></td>  
</tr>  
<tr align="center">  
<td><strong>Figure 3.1 - An instance of a Set Policy</strong></td>   <td> <p><b>Figure 3.1 - An instance of a Set Policy</b></p> </td> </tr> </tbody> </table>
</tr>  
</tbody>  
</table>  
<h3>3.2 Offer</h3> <h3>3.2 Offer</h3>
The following shows the instance of an <code>offer</code> <code>Policy</code>.  
  <p>The following shows the instance of an <code>offer</code> <code>Policy</code>. The <code>offer</code> contains the music file <code>http//example.com/ music:4545</code> that is offered by the <code>Party</code> <code>http//example.com/ sony:10</code> with the <code>Permission</code>s to <code>play</code> and <code>copy</code> the file. The <code>Permission</code> <code>copy</code> is only granted once. The two <code>Permission</code>s are offered for a payment of AUD$0.50.</p>
The <code>offer</code> contains the music file <code>http//example.com/ music:4545</code> that is offered by the <code>Party</code> <code>http//example.com/ sony:10</code> with <table align="center"> <tbody> <tr align="center"> <td> <p><a href="https:/ /www.w3.org/community/odrl/ files/2011/11/ instance-offer.png"><img src="https:// www.w3.org/community/odrl/ files/2011/11/ instance-offer.png" alt="Offer Instance" width="640" class="aligncenter size-full wp-image-250" /></a></p> </td> </tr> <tr align="center"> <td> <p><b>Figure 3.2 - An instance of an Offer Policy</b></p> </td> </tr> </tbody> </table>
the <code>Permission</code>s to <code>play</code>  
and <code>copy</code> the file. The <code>Permission</code>  
<code>copy</code> is only granted once. The two <code>Permission</code>s are offered for a payment of  
AUD$0.50.  
<table align="center">  
<tbody>  
<tr align="center">  
<td><img src="images/instance- offer-feb11.png" alt="instance Offer" width="800" /></td>  
</tr>  
<tr align="center">  
<td><strong>Figure 3.2 - An instance of an Offer Policy</strong></td>  
</tr>  
</tbody>  
</table>  
<h3>3.3 Agreement</h3> <h3>3.3 Agreement</h3>
The following shows the instance of an <code>agreement</code> <code>Policy</code>.  
The <code>agreement</code> contains all entities shown in  
  <p>The following shows the instance of an <code>agreement</code> <code>Policy</code>. The <code>agreement</code> contains all entities shown in the <code>offer</code> scenario above. A new <code>Party</code> element <code>http//example.com/ billie:888</code> has been added. This <code>Party</code> accepted the previous <code>offer</code> and thus is now the buyer of the <code>Permission</code> <code>play</code> and <code>copy</code>, i.e. is now linked as <code>assignee</code> of the <code>Permission</code>s and <code>Duty</code> entities.</p>
the <code>offer</code> scenario above. A new <code>Party</code> element <code>http//example.com/ billie:888</code> <table align="center"> <tbody> <tr align="center"> <td> <p><a href="https:/ /www.w3.org/community/odrl/ files/2011/11/ instance-agreement.png"><img src="https:// www.w3.org/community/odrl/ files/2011/11/ instance-agreement- 1024x824.png" alt="Agreement Instance" width="640" height="515" class="aligncenter size-large wp-image-247" /></a></p> </td> </tr> <tr align="center"> <td> <p><b>Figure 3.3 - An instance of an Agreement Policy</b></p> </td> </tr> </tbody> </table>
has been added. This <code>Party</code> accepted the  
previous <code>offer</code> and thus is now the buyer of  
the <code>Permission</code> <code>play</code>  
and <code>copy</code>, i.e. is now linked as <code>assignee</code> of the  
<code>Permission</code>s and <code>Duty</code>  
entities.  
<table align="center">  
<tbody>  
<tr align="center">  
<td><img src="images/instance- agreement-feb11.png" alt="instance Agreement" width="800" /></td>  
</tr>  
<tr align="center">  
<td><strong>Figure 3.3 - An instance of an Agreement Policy</strong></td>  
</tr>  
</tbody>  
</table>  
<h3>3.4 Request</h3> <h3>3.4 Request</h3>
The following shows the instance of a <code>request</code> <code>Policy</code>.  
The <code>Party</code> <code>http//example.com/ guest:0589</code>  
has requested the <code>Permission</code> to <code>display </code> the <code>target</code> <code>Asset</code> <code>http//example.com/ news:0099</code>.  <p>The following shows the instance of a <code>request</code> <code>Policy</code>. The <code>Party</code> <code>http//example.com/ guest:0589</code> has requested the <code>Permission</code> to <code>display </code> the <code>target</code> <code>Asset</code> <code>http//example.com/ news:0099</code>.</p>
<table align="center">  
<tbody>  
<tr align="center">  
<td><img src="images/instance- request-feb11.png" alt="instance Request" width="800" /></td>  
</tr>  
<tr align="center">  
<td><strong>Figure 3.4 - An instance of a Request Policy</strong></td>  
</tr>  
</tbody>  
</table>  
  <table align="center"> <tbody> <tr align="center"> <td> <p><a href="https:/ /www.w3.org/community/odrl/ files/2011/11/ instance-request.png"><img src="https:// www.w3.org/community/odrl/ files/2011/11/ instance-request.png" alt="Request Instance" width="640" class="aligncenter size-full wp-image-254" /></a></p> </td> </tr> <tr align="center"> <td> <p><b>Figure 3.4 - An instance of a Request Policy</b></p> </td> </tr> </tbody> </table>
<h3>3.5 Ticket</h3> <h3>3.5 Ticket</h3>
The following shows the instance of a <code>ticket</code> <code>Policy</code>.  
The <code>ticket</code> expresses the <code>play</code> <code>Permission</code>  
for the <code>target</code> <code>Asset</code> <code>http//example.com/ game:4589</code>.  
The <code>Ticket</code> is valid until the end of the year 2010. Any valid holder of this ticket may exercise this <code>Permission</code>.  <p>The following shows the instance of a <code>ticket</code> <code>Policy</code>. The <code>ticket</code> expresses the <code>play</code> <code>Permission</code> for the <code>target</code> <code>Asset</code> <code>http//example.com/ game:4589</code>. The <code>Ticket</code> is valid until the end of the year 2010. Any valid holder of this ticket may exercise this <code>Permission</code>.</p>
<table align="center">  
<tbody>  
<tr align="center">  
<td><img src="images/instance- ticket-feb11.png" alt="instance Ticket" /></td>  
</tr>  
<tr align="center">  
<td><strong>Figure 3.5 - An instance of a Ticket Policy</strong></td>  
</tr>  
</tbody>  
</table>  
  <table align="center"> <tbody> <tr align="center"> <td> <p><a href="https:/ /www.w3.org/community/odrl/ files/2011/11/ instance-ticket.png"><img src="https:// www.w3.org/community/odrl/ files/2011/11/ instance-ticket.png" alt="Ticket Instance" width="640" class="aligncenter size-full wp-image-257" /></a></p> </td> </tr> <tr align="center"> <td> <p><b>Figure 3.5 - An instance of a Ticket Policy</b></p> </td> </tr> </tbody> </table>
<h3>3.6 Offer and Next Policy</h3> <h3>3.6 Offer and Next Policy</h3>
The following shows the instance of an <code>offer</code> <code>Policy</code>  
showing the <code>nextPolicy</code> structure. The party <code>http//example.com/ sony:99</code> assigns the <code>Permission</code>  
<code>distribute</code> directly to the potential buyer of  
the permission who will pay $EU1,000. The <code>distribute</code>  
<code>Permission</code> is also constrained to the  
country Italy. The potential <code>assignee</code> may then <code>distribute</code>  
  <p>The following shows the instance of an <code>offer</code> <code>Policy</code> showing the <code>nextPolicy</code> structure. The party <code>http//example.com/ sony:99</code> assigns the <code>Permission</code> <code>distribute</code> directly to the potential buyer of the permission who will pay $EU1,000. The <code>distribute</code> <code>Permission</code> is also constrained to the country Italy. The potential <code>assignee</code> may then <code>distribute</code> the <code>target</code> <code>Asset</code> according to the <code>nextPolicy</code> <code>target</code> <code>Asset</code> linked directly from this <code>Duty</code>. In this case, the next Policy <code>Asset</code> stipulates that the potential <code>assignee</code> may only offer the <code>display</code> <code>Permission</code> to downstream consumers.</p>
the <code>target</code> <code>Asset</code> according to the <code>nextPolicy</code> <code>target</code> <code>Asset</code> linked directly from this <code>Duty</code>. In this case, the next Policy <code>Asset</code> stipulates that the potential <code>assignee</code> may only offer the <code>display</code> <code>Permission</code> <table align="center"> <tbody> <tr align="center"> <td> <p><a href="https:/ /www.w3.org/community/odrl/ files/2011/11/ instance-offernextpolicy.png"><img src="https:// www.w3.org/community/odrl/ files/2011/11/ instance-offernextpolicy- 1024x586.png" alt="Offer Next Policy Instance" width="640" class="aligncenter size-large wp-image-251" /></a></p> </td> </tr> <tr align="center"> <td> <p><b>Figure 3.6 - An instance of an Offer and Next Policy Policy</b></p> </td> </tr> </tbody> </table>
to downstream consumers.  
<table align="center">  
<tbody>  
<tr align="center">  
<td><img src="images/instance- offernextpolicy-feb11.png" alt="instance next rights" width="800" /></td>  
</tr>  
<tr align="center">  
<td><strong>Figure 3.6 - An instance of an Offer and Next Policy  
Policy</strong></td>  
</tr>  
</tbody>  
</table>  
<h3>3.7 Privacy</h3> <h3>3.7 Privacy</h3>
The following shows the instance of an <code>privacy</code> <code>Policy</code>.  <p>The following shows the instance of an <code>privacy</code> <code>Policy</code>.
The <code>target</code> <code>Asset</code> is Personal Data and the <code>assignee</code> is allowed to <code>distribute</code> the <code>Asset</code> only for the <code>purpose</code> of contacting the subject of the Personal Data. The purpose value is taken from the <a href="http:// www.w3.org/TR/ P3P11/#PURPOSE">P3P privacy purpose vocabulary</a>. The <code>target</code> <code>Asset</code> is Personal Data and the <code>assignee</code> is allowed to <code>distribute</code> the <code>Asset</code> only for the <code>purpose</code> of contacting the subject of the Personal Data. The purpose value is taken from the <a href="http:// www.w3.org/TR/ P3P11/#PURPOSE">P3P privacy purpose vocabulary</a>.
Additionally, the <code>assigner</code> (the <code>Party</code> who the personal data is about) has stipulated that the <code>assignee</code> must <code>delete</code> the <code>Asset</code> after a 30 day period (retention policy). Additionally, the <code>assigner</code> (the <code>Party</code> who the personal data is about) has stipulated that the <code>assignee</code> must <code>delete</code> the <code>Asset</code> after a 30 day period (retention policy).
<table align="center">  
<tbody>  
<tr align="center">  
<td><img src="images/instance- privacy-feb11.png" alt="instance Privacy" width="800" /></td> <table align="center"> <tbody> <tr align="center"> <td> <p><a href="https:/ /www.w3.org/community/odrl/ files/2011/11/ instance-privacy.png"><img src="https:// www.w3.org/community/odrl/ files/2011/11/ instance-privacy- 1024x607.png" alt="Privacy Instance" width="640" class="aligncenter size-large wp-image-253" /></a></p> </td> </tr> <tr align="center"> <td> <p><b>Figure 3.7 - An instance of an Privacy Policy</b></p> </td> </tr> </tbody> </table>
</tr>  
<tr align="center">  
<td><strong>Figure 3.7 - An instance of an Privacy Policy</strong></td>  
</tr>  
</tbody>  
</table>  
<h3>3.8 Permission and Prohibition</h3> <h3>3.8 Permission and Prohibition</h3>
The following shows the instance of an <code>agreement</code> <code>Policy</code>  
with both a <code>Permission</code> and a <code>Prohibition</code>. The party <code>http//example.com/ sony:10</code>  
assigns the <code>Permission</code> <code>play</code>  
to the <code>Party</code> <code>http//example.com/ billie:888</code>  
  <p>The following shows the instance of an <code>agreement</code> <code>Policy</code> with both a <code>Permission</code> and a <code>Prohibition</code>. The party <code>http//example.com/ sony:10</code> assigns the <code>Permission</code> <code>play</code> to the <code>Party</code> <code>http//example.com/ billie:888</code> at the same time they are <em>prohibited</em> from utilising the <code>target</code> <code>Asset</code> as a <code>mobile: ringtone</code>. Additionally, in case of any conflict, the <code>conflict</code> attribute is set to <code>perm</code> indicating that the <code>Permission</code> entity will take precedence.</p>
at the same time they are <em>prohibited</em> from utilising the <code>target</code> <code>Asset</code> as a <code>mobile: ringtone</code>. <table align="center"> <tbody> <tr align="center"> <td> <p><a href="https:/ /www.w3.org/community/odrl/ files/2011/11/ instance-permprohibit.png"><img src="https:// www.w3.org/community/odrl/ files/2011/11/ instance-permprohibit.png" alt="Permission Prohibition Instance" width="640" class="aligncenter size-full wp-image-252" /></a></p> </td> </tr> <tr align="center"> <td> <p><b>Figure 3.8 - An instance of an Permission and Prohibition Policy</b></p> </td> </tr> </tbody> </table>
Additionally, in case of any conflict, the <code>conflict</code>  
attribute is set to <code>perm</code> indicating that the  
<code>Permission</code> entity will take precedence.  
<table align="center">  
<tbody>  
<tr align="center">  
<td><img src="images/instance- permprohibit-feb11.png" alt="instance perm prohibit" width="800" /></td>  
</tr>  
<tr align="center">  
<td><strong>Figure 3.8 - An instance of an Permission and  
Prohibition Policy</strong></td>  
</tr>  
</tbody>  
</table>  
<h3>3.9 Inheritance</h3> <h3>3.9 Inheritance</h3>
The following shows the instance of a (child) <code>Policy</code> <code>http//example.com/ policy:9999</code> inheriting from another (parent) <code>Policy</code> <code>http//example.com/ policy:5531</code>. The <code>inheritFrom</code>  
attribute of the (child) <code>Policy</code> has the same identifier as the (parent) <code>Policy</code>. In this  
inheritance example, the (parent) <code>Policy</code> allows the <code>Party</code> <code>http//example.com/ billie:888</code> to <code>print</code> the (parent's)  
<code>target</code> <code>Asset</code>. The (child) <code>Policy</code> allows the <code>Party</code> <code>http//example.com/ class:IT01</code> (a group of  
  <p>The following shows the instance of a (child) <code>Policy</code> <code>http//example.com/ policy:9999</code> inheriting from another (parent) <code>Policy</code> <code>http//example.com/ policy:5531</code>. The <code>inheritFrom</code> attribute of the (child) <code>Policy</code> has the same identifier as the (parent) <code>Policy</code>. In this inheritance example, the (parent) <code>Policy</code> allows the <code>Party</code> <code>http//example.com/ billie:888</code> to <code>print</code> the (parent's) <code>target</code> <code>Asset</code>. The (child) <code>Policy</code> allows the <code>Party</code> <code>http//example.com/ class:IT01</code> (a group of people) to <code>display</code> the (child's) <code>target</code> <code>Asset</code>. Since the (child) <code>Policy</code> also inherits from the (parent) <code>Policy</code>, then the <code>Party</code> <code>http//example.com/ class:IT01</code> can also <code>print</code> the (parent's) <code>target</code> <code>Asset</code>.
people) to <code>display</code> the (child's) <code>target</code> <code>Asset</code>. Since the (child) <code>Policy</code> also inherits from the (parent) <code>Policy</code>, then the <code>Party</code> <code>http//example.com/ class:IT01</code> can also <code>print</code> the (parent's) <table align="center"> <tbody> <tr align="center"> <td> <p><a href="https:/ /www.w3.org/community/odrl/ files/2011/11/ instance-inherit.png"><img src="https:// www.w3.org/community/odrl/ files/2011/11/ instance-inherit- 1024x513.png" alt="Inheritance Instance" width="640" class="aligncenter size-large wp-image-248" /></a></p> </td> </tr> <tr align="center"> <td> <p><b>Figure 3.9 - An instance of an Inheritance Policy</b></p> </td> </tr> </tbody> </table>
<code>target</code> <code>Asset</code>.  
<table align="center">  
<tbody>  
<tr align="center">  
<td><img src="images/instance- inherit-feb11.png" alt="instance inherit" width="800" /></td>  
</tr>  
<tr align="center">  
<td><strong>Figure 3.9 - An instance of an Inheritance Policy</strong></td>  
</tr>  
</tbody>  
</table>  
<h3>3.10 Social Network</h3> <h3>3.10 Social Network</h3>
The following shows the instance of an <code>agreement</code> <code>Policy</code> for a Social Network scenario.  <p>The following shows the instance of an <code>agreement</code> <code>Policy</code> for a Social Network scenario.
The <code>target</code> <code>Asset</code> are photos posted to a Social Network site and the <code>assigner</code> is the owner of the photos. The <code>assignee</code> is a <code>Party</code> <code>group</code> and represents the <em>football network members</em> on the social network, who are each allowed to <code>display</code> the photos. The <code>target</code> <code>Asset</code> are photos posted to a Social Network site and the <code>assigner</code> is the owner of the photos. The <code>assignee</code> is a <code>Party</code> <code>group</code> and represents the <em>football network members</em> on the social network, who are each allowed to <code>display</code> the photos.
<table align="center">  
<tbody>  
<tr align="center">  
<td><img src="images/instance- socialnetwork-feb11.png" alt="instance social network" width="800" /></td> <table align="center"> <tbody> <tr align="center"> <td> <p><a href="https:/ /www.w3.org/community/odrl/ files/2011/11/ instance-socialnetwork.png"><img src="https:// www.w3.org/community/odrl/ files/2011/11/ instance-socialnetwork.png" alt="Social Networks Instance" width="640" class="aligncenter size-full wp-image-256" /></a></p> </td> </tr> <tr align="center"> <td> <p><b>Figure 3.10 - An instance of an Social Network Policy</b></p> </td> </tr> </tbody> </table>
</tr>  
<tr align="center">  
<td><strong>Figure 3.10 - An instance of an Social Network Policy</strong></td>  
</tr>  
</tbody>  
</table>  
</div>  
<div class="diff-new">  
<h3>3.11 Multiple Assets</h3> <h3>3.11 Multiple Assets</h3>
The following shows an instance of a <code>set</code> <code>Policy</code> utilising multiple <code>Asset</code> entities.  <p>The following shows an instance of a <code>set</code> <code>Policy</code> utilising multiple <code>Asset</code> entities.
The <code>index</code> <code>Permission</code> is granted to the <code>target</code> <code>Asset</code>. As well, the <code>x:collection</code> <code>Asset</code> specifies which database the  The <code>index</code> <code>Permission</code> is granted to the <code>target</code> <code>Asset</code>. As well, the <code>x:collection</code> <code>Asset</code> specifies which database the <code>index</code> outcome should be stored in.</p>
<code>index</code> outcome should be stored in.  
<table align="center">  
<tbody>  
<tr align="center">  
<td><img src="images/instance- multipleassets-feb11.png" alt="instance Multiple Assets Policy" width="800" /></td>  
</tr>  
<tr align="center">  
<td><strong>Figure 3.11 - An instance of an Multiple Assets Policy</strong></td>  
</tr>  
</tbody>  
</table>  
</div>  
  <table align="center"> <tbody> <tr align="center"> <td> <p><a href="https:/ /www.w3.org/community/odrl/ files/2011/11/ instance-multipleassets.png"><img src="https:// www.w3.org/community/odrl/ files/2011/11/ instance-multipleassets.png" alt="Multiple Assets Instance" width="640" class="aligncenter size-full wp-image-249" /></a></p> </td> </tr> <tr align="center"> <td> <p><b>Figure 3.11 - An instance of an Multiple Assets Policy</b></p> </td> </tr> </tbody> </table>
<h2><a name="section-4"></a>4. Profiles (Informative)</h2> <h2><a name="section-4"></a>4. Profiles (Informative)</h2>
The ODRL Core Model represents a broad need for policy  
expressibility. As a result, different communities will require less or  
more elements from the Core Model. Community profiles of the ODRL model  
are expected to be developed that adequately document these changes in  
respect to the Core Model. Some requirements of this process include:  
  <p>The ODRL Core Model represents a broad need for policy expressibility. As a result, different communities will require less or more elements from the Core Model. Community profiles of the ODRL model are expected to be developed that adequately document these changes in respect to the Core Model. Some requirements of this process include:</p>
<ul>   <ul>
<li>Document any additions to the Core Model</li>  <li>Document any additions to the Core Model</li>
<li>Document any aspects of the Core Model that will have  
different default values</li>  
   <li>Document any aspects of the Core Model that will have different default values</li> <li>Document which aspects of the Core Model are not being used (deprecated)</li>
  <li>Document Vocabulary terms</li>
   <li>Declare your communities namespace (see Encoding specifications)</li>
<li>Document which aspects of the Core Model are not being used  <li>Share the Community profile with the ODRL community for feedback and comments</li> </ul>
(deprecated)</li>  
<li>Declare your communities namespace (see Encoding   
specifications)</li>  
<li>Share the Community profile with the ODRL Initiative for  
feedback and comments</li>  
</ul>  
<h2><a name="section-5"></a>5. Experimental Features (Informative)</h2>  
This section contains advanced ODRL features. Although not part of the normative specification, they provide an opportunity for communities to experiment with and provide feedback on experiences that may be included in future ODRL versions.  <h2><a name="section-5"></a>5. Experimental Features (Informative)</h2> <p>This section contains advanced ODRL features. Although not part of the normative specification, they provide an opportunity for communities to experiment with and provide feedback on experiences that may be included in future ODRL versions.</p>
<h3><a name="section-51"></a>5.1 Extended Relations</h3> <h3><a name="section-51"></a>5.1 Extended Relations</h3>
<code>Extended Relations</code> may tie <code>Permission</code>, <code>Prohibition</code>,  
<code>Duty</code>, and <code>Constraint</code>  
entities together with an <code>AND</code>, <code>OR</code> or <code>XOR</code> relationship.  
Only entities of the same type can be linked with this model. For  
  <p><code>Extended Relations</code> may tie <code>Permission</code>, <code>Prohibition</code>, <code>Duty</code>, and <code>Constraint</code> entities together with an <code>AND</code>, <code>OR</code> or <code>XOR</code> relationship. Only entities of the same type can be linked with this model. For example, a <code>Permission</code> and <code>Prohibition</code> cannot be linked together within this model. The Extended Relations model supports the following attribute:</p>
  <ul> <li><code>operation</code>: may be set with <em>one</em> of the mathematical values <code>AND</code>, <code>OR</code> and <code>XOR</code>. (<code>OR</code> is the default if not specified.)</li> </ul>
example, a <code>Permission</code> and <code>Prohibition</code> cannot be linked together within this <p>The following table outlines the semantics of Extended Relations with respect to each of the main entity types.</p>
model. The Extended Relations model supports the following attribute:  
<ul>  
<li><code>operation</code>: MAY be set with <em>one</em>  
of the mathematical values <code>AND</code>, <code>OR</code> and <code>XOR</code>. (<code>OR</code> is the default if not specified.)</li>   
</ul>  
The following table outlines the semantics of Extended Relations  
with respect to each of the main entity types.  
<table width="100%" border="1" cellspacing="1" cellpadding="3">  
<tbody>  
<tr>  
<td></td>  
<td><code>Permission</code></td>  
<td><code>Prohibition</code></td>  
<td><code>Duty</code></td>  
<td><code>Constraint</code></td>  
</tr>  
<tr>  
<td><code>OR</code></td>  
<td>The related party MAY perform <em>any</em> (<em>at least</em>)  
one of the <code>Action< /code>s</td>  
<td>The related party MAY NOT perform <em>at least</em> one of  
the <code>Action< /code>s</td>  
<td>The related party MUST perform <em>at least</em> one of the <code>Action< /code>s</td>  
<td>The related <code>Permission< /code>/<code> Prohibition< /code>/<code>Duty</code> is  
restricted by <em>at least</em> one of the <code>Constraint< /code>s</td>  
</tr>  
<tr>  
<td><code>AND</code></td>  
<td>The related party MUST perform <em>all</em> of the <code>Action< /code>s</td>  
<td>The related party MAY NOT perform <em>all</em> of the <code>Action< /code>s</td>  
<td>The related party MUST perform <em>all</em> of the <code>Action< /code>s</td>  
<td>The related <code>Permission< /code>/<code> Prohibition< /code>/<code>Duty</code> is  
restricted by <em>all</em> of the <code>Constraint< /code>s</td>  
</tr>  
<tr>  
<td><code>XOR</code></td>  
<td>The related party MAY perform only <em>one</em> of the <code>Action< /code>s</td>  
<td>The related party MAY NOT perform only <em>one</em> of the <code>Action< /code>s</td>  
<td>The related party MUST perform only <em>one</em> of the <code>Action< /code>s</td>  
<td>The related <code>Permission< /code>/<code> Prohibition< /code>/<code>Duty</code> is  
restricted by only <em>one</em> of the <code>Constraint< /code>s.</td>  
</tr>  
</tbody>  
</table>  
Note that Extended Relations are not needed to assign two or more  
<code>Permission</code>s to a <code>Party</code>  
entity. In this case simply use as many <code>Assignee</code>  
relations between <code>Party</code> and <code>Permission</code> as needed.  
<div class="diff-del">  
<h3><a name="section-52"></a>5.2 Consequences and Remedies for Duties</h3>  
When assigning a <code>Duty</code> the policy assumes that the <code>assignee</code> will either perform the <code>Duty</code> (and then get access to the <code>Asset</code>) or not perform the <code>Duty</code> (and hence, not get access to the <code>Asset</code>). There is one exception in that <code>Duty</code> entity may contain the <code>relax</code> boolean that indicates the duty may be fulfilled at anytime, including after the <code>Permission</code> has been utilised by the <code>assignee</code>.  
However, there is no concept of <em>compensation</em> for not performing the <code>Duty</code>. That is some type of <em>consequence</em> of not performing the <code>Duty</code> or a <em>remedy</em> if something went wrong. One possible solution would be to allow there to be <code>Duty</code> for <code>Duties</code>, making it clear the consequence of not performing that <code>Duty</code> within the specified terms.  
</div>  
<div class="diff-new">  
  <table border="1" cellspacing="2" cellpadding="5" width="100%"> <tr> <td>&nbsp;</td> <td><code>Permission</code></td> <td><code>Prohibition</code></td> <td><code>Duty</code></td> <td><code>Constraint</code></td> </tr> <tr> <td><code>OR</code></td> <td>The related party may perform <em>any</em> (<em>at least</em>) one of the <code>Action< /code>s</td> <td>The related party MAY NOT perform <em>at least</em> one of the <code>Action< /code>s</td> <td>The related party MUST perform <em>at least</em> one of the <code>Action< /code>s</td> <td>The related <code>Permission< /code>/<code> Prohibition< /code>/<code>Duty</code> is restricted by <em>at least</em> one of the <code>Constraint< /code>s</td> </tr> <tr> <td><code>AND</code></td> <td>The related party MUST perform <em>all</em> of the <code>Action< /code>s</td> <td>The related party MAY NOT perform <em>all</em> of the <code>Action< /code>s</td> <td>The related party MUST perform <em>all</em> of the <code>Action< /code>s</td> <td>The related <code>Permission< /code>/<code> Prohibition< /code>/<code>Duty</code> is restricted by <em>all</em> of the <code>Constraint< /code>s</td> </tr> <tr> <td><code>XOR</code></td> <td>The related party MAY perform only <em>one</em> of the <code>Action< /code>s</td> <td>The related party MAY NOT perform only <em>one</em> of the <code>Action< /code>s</td> <td>The related party MUST perform only <em>one</em> of the <code>Action< /code>s</td> <td>The related <code>Permission< /code>/<code> Prohibition< /code>/<code>Duty</code> is restricted by&nbsp;only <em>one</em> of the <code>Constraint< /code>s.</td> </tr> </table>
  <p>Note that Extended Relations are not needed to assign two or more <code>Permission</code>s to a <code>Party</code> entity. In this case simply use as many <code>Assignee</code> relations between <code>Party</code> and <code>Permission</code> as needed.</p>
<h3><a name="section-52"></a>5.2 Abstract Policy Expression</h3> <h3><a name="section-52"></a>5.2 Abstract Policy Expression</h3>
As the Core Model diagram shows (see Figure 2.1), the key <code>Permission</code>, <code>Prohibition</code> and <code>Duty</code> entities are very similar since they have (more or less) the same relationships to the other entities. They core difference is in their semantics:  
<ul>  
<li><code>Permission</code> says that the <code>assignee  
</code> <em>may</em> do something,</li>  
<li><code>Duty</code> says that the <code>assignee</code> <em>should</em> do something, and</li>  
<li><code>Prohibition</code> says that they <em>should not</em> do it.</li>  
</ul>  
In an implementation that interprets ODRL, it may make sense to introduce a common superclass <code>AbstractPolicy</code>, as shown in the (abbreviated) Model in Figure 5.1.  
<table align="center">  
<tbody>  
<tr align="center">  
<td><img src="images/exp- abstractmodel-feb11.png" alt="Core Model with Abstract Policy Expression" /></td>  
</tr>  
<tr align="center">  
<td><strong>Figure 5.1 - ODRL Abstract Policy Model</strong></td>  
</tr>  
</tbody>  
</table>  
  <p> As the Core Model diagram shows (see Figure 5.1), the key <code>Permission</code>, <code>Prohibition</code> and <code>Duty</code> entities are very similar since they have (more or less) the same relationships to the other entities. They core difference is in their semantics:</p> <ul> <li><code>Permission</code> says that the <code>assignee </code> <em>may</em> do something, </li> <li><code>Duty</code> says that the <code>assignee</code> <em>should</em> do something, and </li> <li> <code>Prohibition</code> says that they <em>should not</em> do it. </li> </ul> <p>In an implementation that interprets ODRL, it may make sense to introduce a common superclass <code><i>Rule</i></code>, as shown in the (abbreviated) Model in Figure 5.1. </p>
  <table align="center"> <tbody> <tr align="center"> <td> <p><a href="https:/ /www.w3.org/community/odrl/ files/2011/11/ exp-abstractmodel.png"><img src="https:// www.w3.org/community/odrl/ files/2011/11/ exp-abstractmodel.png" alt="Abstract Policy Expression" width="640" class="aligncenter size-full wp-image-245" /></a></p> </td> </tr> <tr align="center"> <td> <p><b>Figure 5.1 - ODRL Abstract Policy Model</b></p> </td> </tr> </tbody> </table>
By implementing <code>Permission</code>, <code>Prohibition</code> and <code>Duty</code> as subclasses of <code>AbstractPolicy</code>, the redundancy of having very similar, but separately developed classes in an application's source code can be avoided. Furthermore, <code>AbstractPolicy</code> makes it possible to easily extend the Core Model in Profiles by adding policy expressions (as subclasses of <code>AbstractPolicy</code>) that are not possible by default, e.g. <code>InterpretedAsPermission</code> in cases where the ODRL policy was derived from a legal situation or document that was ambiguous.   <p> By implementing <code>Permission</code>, <code>Prohibition</code> and <code>Duty</code> as subclasses of <code><i>Rule</i></code>, the redundancy of having very similar, but separately developed classes in an application's source code can be avoided. Furthermore, <code><i>Rule</i></code> makes it possible to easily extend the Core Model in Profiles by adding policy expressions (as subclasses of <code><i>Rule</i></code>) that are not possible by default. </p>
<h3><a name="section-53"></a>5.3 Remedies</h3> <h3><a name="section-53"></a>5.3 Remedies</h3>
In the ODRL Core Model, <code>Duties</code> are only directly related to <code>Permission</code>s, meaning that for a <code>Permission</code> to become effective, the related <code>Duty</code> should be performed. For some use cases though, it might be useful to attach a <code>Duty</code> to a <code>Prohibition</code>, meaning that if a <code>Prohibition</code> is violated, the <code>Duty</code> has to be performed as a kind of remedy or consequence for the violation.  <p> In the ODRL Core Model, <code>Duties</code> are only directly related to <code>Permission</code>s, meaning that for a <code>Permission</code> to become effective, the related <code>Duty</code> should be performed. For some use cases though, it might be useful to attach a <code>Duty</code> to a <code>Prohibition</code>, meaning that if a <code>Prohibition</code> is violated, the <code>Duty</code> has to be performed as a kind of remedy or consequence for the violation. </p>
Not only can a <code>Prohibition</code> have a <code>Duty</code> attached to it as a remedy, even <code>Duties</code> themselves may have remedies, e.g. "For the <code>Permission</code> to play audio file xyz to become effective, you have to perform the <code>Duty</code> 'pay 2'. If you don't perform this <code>Duty</code> (even though you've played yxz), you have to remedy this by performing the <code>Duty</code> 'pay 5'".  <p> Not only can a <code>Prohibition</code> have a <code>Duty</code> attached to it as a remedy, even <code>Duties</code> themselves may have remedies, e.g. "For the <code>Permission</code> to play audio file xyz to become effective, you have to perform the <code>Duty</code> 'pay 2&euro;'. If you don't perform this <code>Duty</code> (even though you've played yxz), you have to remedy this by performing the <code>Duty</code> 'pay 5&euro;'". </p>
In order to distinguish between a <code>Duty</code> that has to be fulfilled as a requirement and one that has to be fulfilled as a remedy, different relation names are introduced as shown in the Figure 5.2.  <p> In order to distinguish between a <code>Duty</code> that has to be fulfilled as a requirement and one that has to be fulfilled as a remedy, different relation names are introduced as shown in the Figure 5.2. </p>
<table align="center">  
<tbody>  
<tr align="center">  
<td><img src="images/exp- remedy-feb11.png" alt="Remedy" width="800" /></td>  
</tr>  
<tr align="center">  
<td><strong>Figure 5.2 - Remedy Model</strong></td>  
</tr>  
</tbody>  
</table>  
  <table align="center"> <tbody> <tr align="center"> <td> <p><a href="https:/ /www.w3.org/community/odrl/ files/2011/11/ exp-remedy.png"><img src="https:// www.w3.org/community/odrl/ files/2011/11/ exp-remedy.png" alt="Remedy" width="640" class="aligncenter size-full wp-image-246" /></a></p> </td> </tr> <tr align="center"> <td> <p><b>Figure 5.2 - Remedy Model</p> </td> </tr> </tbody> </table>
The relation between <code>Permission</code> and <code>Duty</code>, which was unnamed before, is now named <code>hasRequirement</code>. This is needed not only to make the different semantics clearer, but also because a <code>Duty</code> can refer to yet another <code>Duty</code> as a requirement, e.g. "If you want to print this written article, you have the <code>Duty</code> to attach a particular image of the author, and if you do that, you have the <code>Duty</code> to attribute the image to the photographer".   <p> The relation between <code>Permission</code> and <code>Duty</code>, which was unnamed before, is now named <code>hasRequirement</code>. This is needed not only to make the different semantics clearer, but also because a <code>Duty</code> can refer to yet another <code>Duty</code> as a requirement, e.g. "If you want to print this written article, you have the <code>Duty</code> to attach a particular image of the author, and if you do that, you have the <code>Duty</code> to attribute the image to the photographer". </p>
</div>  
<h2><a name="section- Acknowledgements" ></a>Acknowledgements</h2> <h2><a name="section- Acknowledgements" ></a>Acknowledgements</h2>
The editors gratefully acknowledge feedback and contributions to  
this document from:  
<ul>  
<li>Vicky Weissman, Mark Strembeck, Alapan Arnab, Steven Rowat,  
Eetu Luoma, Jaime Delgado, Ruediger Grimm, Stuart Myles, Francis Cave, Rigo Wenning, Hassan Abdel-Rahman, Jonas Zitz</li>  <p>The editors gratefully acknowledge feedback and contributions to this document from:</p> <ul> <li>Vicky Weissman, Mark Strembeck, Alapan Arnab, Steven Rowat, Eetu Luoma, Jaime Delgado, Ruediger Grimm, Helge Hundacker, Stuart Myles, Francis Cave, Rigo Wenning, Hassan Abdel-Rahman, Jonas Zitz</li> <li>Members of the W3C ODRL Community Group</li> </ul>
<li>Members of the Version 2.0 Working Group</li>  
</ul>  
<h2><a name="section- References">< /a>References</h2> <h2><a name="section- References">< /a>References</h2>
<table width="100%" border="0" cellspacing="0" cellpadding="5">  <table border="0" cellspacing="0" cellpadding="5" width="100%"> <tbody>
<tbody>  
  <TR class="r0"> <TD vAlign="top" align="right" ><B>[ODRL-11]</B></TD> <TD>R. Iannella (ed). Open Digital Rights Language (ODRL) Version 1.1. W3C Note, 19 Sept 2002. <A href="http:// www.w3.org/TR/odrl/"> http://www.w3.org/ TR/odrl/</A></TD></TR>
<tr class="r0"> <tr class="r0">
<td colspan="1" align="right" valign="top">  
<div class="diff-del">  
<strong>[ISO4217]</strong>  
</div></td>  
<td colspan="1">  
<div class="diff-del">  
ISO 4217 currency and funds name and code elements.  
Specification, International Organization for Standardization  
(ISO), 07 July 2008.  
<a href="http:// www.iso.org/iso/ support/faqs/ faqs_widely_used_standards/ widely_used_standards_other/ currency_codes/ currency_codes_ list-1.htm">  
http://www.iso.org/ iso/support/faqs/ faqs_widely_ used_standards/ widely_used_ standards_other/currency_ codes/currency_ codes_list-1.htm</a>  
</div></td>  
  <td colspan="1" valign="top" align="right" ><b>[ODRL-REQ]</b></td>
   <td colspan="1">S. Guth &amp; R. Iannella (eds). Open Digital Rights Language (ODRL) Version 2.0 Requirements (Working Draft), ODRL Initiative, <a href="http:// odrl.net/2.0/ v2req.html"> http://odrl.net/ 2.0/v2req.html</a>, 24 November 2004. <br> </td> </tr>
   <tr>
   <TD vAlign="top" align="right" ><B>[ODRL-VOCAB]</B></TD>
   <TD>S. Guth &amp; R. Iannella (eds). Open Digital Rights Language (ODRL) Version 2.0 - Common Vocabulary. Final Specification, W3C ODRL Community Group, 19 April 2012.<BR><A href="http:// www.w3.org/community/odrl/ two/vocab/">http: //www.w3.org/ community/odrl/ two/vocab/</A></TD>
   </TR>
   <tr>
   <tr>
   <TD vAlign="top" align="right" ><B>[ODRL-XML]</B></TD>
   <TD>R. Iannella (ed). Open Digital Rights Language (ODRL) Version 2.0 - XML Encoding. Final Specification, W3C ODRL Community Group, 19 April 2012.<BR><A href="http:// www.w3.org/community/odrl/ two/xml/">http: //www.w3.org/ community/odrl/ two/xml/</A></TD>
   </TR>
</tr>  <tr>
<tr class="r0">  
<td colspan="1" align="right" valign="top"> <strong>[ODRL11]< /strong></td>  
<td colspan="1">R. Iannella (ed). Open Digital Rights Language  
(ODRL), Version 1.1. Technical Specification, ODRL Initiative, 8  
August 2002.<a href="http:// odrl.net/1.1/ ODRL-11.pdf" >http://odrl.net/1.1/ODRL- 11.pdf</a></td>  
</tr>  
<tr class="r0">  
<td colspan="1" align="right" valign="top"> <strong>[ODRL- REQ]</strong></td>   
<td colspan="1">S. Guth &amp; R. Iannella (eds). Open Digital  
Rights Language (ODRL) Version 2.0 Requirements (Working Draft), ODRL  
Initiative, <a href="http:// odrl.net/2.0/ v2req.html"> http://odrl.net/ 2.0/v2req.html</a>,  
24 November 2004.</td>  
</tr>  
<tr class="r0">  
<td colspan="1" align="right" valign="top"> <strong>[RFC2119]< /strong></td>  
<td colspan="1">Key words for use in RFCs to Indicate  
Requirement Levels, S. Bradner. The Internet Society, March 1997. <a href="http:// tools.ietf.org/ html/rfc2119" >http://tools.ietf.org/html/ rfc2119</a></td>  
</tr>  
<tr class="r0">  
<td colspan="1" align="right" valign="top"> <strong>[UML]< /strong></td>  
<td colspan="1">Unified Modeling Language (UML), Object Management  
Group, 2003. <a href="http:// www.omg.org/technology/documents/ formal/uml.htm" >http://www.omg.org/ technology/documents/formal/ uml.htm</a></td>  
</tr>  
</tbody>  
</table>  
<a href="http:// validator.w3.org/check?uri= referer"><img src="http://www.w3.org/ Icons/valid-html40" alt="Valid HTML 4.0 Strict" width="88" height="31" /></a>  
&nbsp;  
  <tr class="r0"> <td colspan="1" valign="top" align="right" ><b>[RFC2119]</b></td> <td colspan="1">Key words for use in RFCs to Indicate Requirement Levels, S. Bradner. The Internet Society, March 1997. <a href="http:// tools.ietf.org/ html/rfc2119" >http://tools.ietf.org/ html/rfc2119</a> <br> </td> </tr>
  <tr class="r0"> <td colspan="1" valign="top" align="right" ><b>[UML]</b></td> <td colspan="1">Unified Modeling Language (UML), Object Management Group, 2003. <a href="http:// www.omg.org/technology/documents/ formal/uml.htm" >http://www.omg.org/ technology/documents/ formal/uml.htm</a> <br> </td> </tr> </tbody> </table>

Note: Spaces may be added to comparison text to allow better line wrapping.