Copyright ODRL Initiative 2005-2011. All Rights Reserved. See the ODRL Process Document for Policy and Usage terms.
This document describes the ODRL Version 2.0 Core Model Specification. The model incorporates new features and requirements for the ODRL policy expression language.
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:
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:
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:Party
,
Asset
or Role
.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
.
invalid
,
assigner
or true
.
CamelCase is also used for values, where necessary.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 Permission
s and Prohibition
s.
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
Permission
s, 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".
Figure 2.1 - ODRL Core Model Version 2.0 |
The following sections describes each entity of the Core Model in greater detail.
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 Permission
s and Prohibition
s (OPTIONAL)undefined
: indicates how to
handle undefined Action
s (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 Action
s in the Permission
s and Prohibition
s.
If present, the conflict
attribute MUST
take one of the following values:
perm
: the Permission
s
will always takes precedenceprohibit
: the Prohibition
s
will always takes precedenceinvalid
: the policy is not validIf 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 Action
s 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
validignore
: the Action
is to be ignored and not part of the policy - and the policy remains
validinvalid
: the Action
is unknown - and the policy is invalidIn 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.
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 inheritancefalse
: the Policy
expression can not be used for inheritanceIf 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:
Policy
to one or more Child Policy
entities.
No Child Policy
can inherit from two or more
Parent Policy
entities.)Policy
entities.)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 Action
s are added to the Child's Action
s.Policy
to the Child Policy
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
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.
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.
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.
The Permission
entity indicates the Action
s 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
Constraint
s 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)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 exercisedIf 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 Role
s (see Section 2.3.1). If no explicit
Party
is linked to as assignee
or assigner
, the Parties
with the respective Role
s 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 Constraint
s [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.
The Prohibition
entity indicates the
Action
s that the assignee
is prohibited to perform on the related Asset
[ODRL-REQ#1.7]. Prohibition
s 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)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.
The Constraint
entity indicates
limits and restrictions to the Permission
,
the Prohibition
and the Duty
entity [ODRL-REQ#1.9]. Constraint
s 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
).
Constraint
s 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 Constraint
s
needs to be captured and expressed in the ODRL Core Model.
This section shows a number of policy expression scenarios. In
these examples, the different policy expression type
s
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 type
s and other
entities will be defined in the ODRL Common Vocabulary specification, or
in community profiles.
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.
Figure 3.1 - An instance of a Set Policy |
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 Permission
s to play
and copy
the file. The Permission
copy
is only granted once. The two Permission
s are offered for a payment of
AUD$0.50.
Figure 3.2 - An instance of an Offer Policy |
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
Permission
s and Duty
entities.
Figure 3.3 - An instance of an Agreement Policy |
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
.
Figure 3.4 - An instance of a Request Policy |
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
.
Figure 3.5 - An instance of a Ticket 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.
Figure 3.6 - An instance of an Offer and Next Policy Policy |
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).
Figure 3.7 - An instance of an Privacy Policy |
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.
Figure 3.8 - An instance of an Permission and Prohibition Policy |
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
.
Figure 3.9 - An instance of an Inheritance Policy |
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.
Figure 3.10 - An instance of an Social Network Policy |
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.
Figure 3.11 - An instance of an Multiple Assets Policy |
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:
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.
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 Action s |
The related party MAY NOT perform at least one of
the Action s |
The related party MUST perform at least one of the Action s |
The related Permission /Prohibition /Duty is
restricted by at least one of the Constraint s |
AND |
The related party MUST perform all of the Action s |
The related party MAY NOT perform all of the Action s |
The related party MUST perform all of the Action s |
The related Permission /Prohibition /Duty is
restricted by all of the Constraint s |
XOR |
The related party MAY perform only one of the Action s |
The related party MAY NOT perform only one of the Action s |
The related party MUST perform only one of the Action s |
The related Permission /Prohibition /Duty is
restricted by only one of the Constraint s. |
Note that Extended Relations are not needed to assign two or more
Permission
s to a Party
entity. In this case simply use as many Assignee
relations between Party
and Permission
as needed.
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.
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.
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.
In the ODRL Core Model, Duties
are only directly related to Permission
s, 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.
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".
The editors gratefully acknowledge feedback and contributions to this document from:
[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
|