Copyright ODRL Initiative 2005-2009. All Rights Reserved.
This document describes the ODRL Version 2.0 Core Model Specification. The model incorporates new features and requirements for the ODRL rights expression language.
This is the second 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 and 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/.
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.
1. Overview
2. ODRL Core Model
3. Expression Semantics
4. Scenarios (Informative)
5. Profiles (Informative)
Acknowledgements
References
The ODRL rights expression language (REL) 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 rights-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].
Figure 2.1 below shows the complete version 2.0 ODRL Core Model. The subsequent sections describes each entity of the Core Model in greater detail.
Figure 2.1 - ODRL Core Model Version 2.0 |
The Rights
entity is the top-level
entity and contains the following attributes:
uid
: the unique identification
of the rights expression (REQUIRED)type
: indicates the semantics
of the rights expression instance (REQUIRED). These are further
described in the ODRL profiles.conflict
: indicates the
precedence between Permission
s and Prohibition
s (OPTIONAL)undefined
: indicates how to
handle undefined Action
s (OPTIONAL)inherit
: indicates if the Rights
expression can be inherited (see section
2.2.1) (OPTIONAL)The uid
attribute MUST follow the
URI specifications and be globally unique.
The range of values for the rights expression type
attribute will be described in the Common
Vocabulary document or in community profiles. This value may also impose
further constraints on the expression language constructs, such as Offer
, Agreement
and inherit
.
The conflict
attribute is used to
resolve conflicts arising from the merging of licenses, 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 license 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 rights 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 license - and the license remains
validignore
: the Action
is to be ignored and not part of the license - and the license remains
validinvalid
: the Action
is unknown - and the license is invalidIn the support
case, even though the Action
is unknown, the license still is valid and
the consuming parties or system of the license 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 license still is valid and
the consuming parties or system of the license may be made aware of the
unknown Action
.
In the invalid
case with the unknown Action
, the license is invalid and the consuming
parties or system of the license 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
.
The Asset
entity is aimed at
identifying the content that is the subject of the rights expression.
The Asset
entity is the Target
of the Permission
and/or Prohibition
entities, and possibly,
indirectly of the Duty
entity (via Object
).
The Asset
entity contains the
following attributes:
uid
: the unique identification
of the Asset
(REQUIRED)inherit
: the unique
identification of the Asset
whose rights will be inherited (OPTIONAL)The ODRL Core Model does not provide additional descriptive
metadata for the Asset
entity. It is
recommended to use already existing metadata standards, such as Dublin Core,
LOM,
or MPEG
7 that are appropriate to the content type or purpose.
The inherit
attribute in the Asset
entity indicates an inheritance of rights
information between rights expressions [ODRL-REQ#1.20]. The inherit
item in the Asset
(Child Asset
) will uniquely identify another
Asset
(Parent Asset
)
which has an associated rights expression instance.
The following restrictions apply when using inheritance:
Asset
to one or more Child Asset
s.
No Child Asset
can inherit from two or more
Parent Asset
s.)Asset
s.)Asset
will always
override the Parent Asset
. 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.Asset
to the Child Asset
The inherit
attribute in the Rights
entity is used to indicate if the Rights
expression can be used in any inheritance
relationship. If present, the value of the inherit
attribute MUST take one of the following values:
true
: the Rights
expression can be used for inheritancefalse
: the Rights
expression can not be used for inheritanceIf the inherit
attribute is not
explicitly set, its default value will be used instead. The default
value of the inherit
attribute is true
.
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 rights transactions [ODRL-REQ#1.5].
The Party
entity contains the
following attributes:
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 vCard or CIQ.
The Party
entity undertakes the same
three roles with both the Permission
and Prohibition
entities:
Party
entity can transfer Permission
s and Prohibition
s
by being the Assigner
(supplier) of such.Party
entity can receive Permission
s and Prohibition
s
by being the Assignee
(consumer) of such.
Note, the Assignee
can also represent a
group of people and/or legal entities, but only one member of the group
receives the set of Permission
s.Party
entity can receive Permission
s and Prohibition
s
by being the Assignees
(consumers) of
such. In this case, the Party
entity MUST
identify a group of people and/or legal entities. Each member of the
group receives the same set of Permission
s
and Prohibition
s [ODRL-REQ#1.13].The Party
entity undertakes three
roles with the Duty
entity:
Party
entity can be responsible
for undertaking a Duty
by being the Assignee
(debtor) of such.Party
entity can be entitled to
receive the outcomes of a Duty
by being the
Assigner
(creditor) of such. Note, the Assigner
can also represent a group of people
and/or legal entities, but only one member of the group is the
beneficiary of the Duty
.Party
entity can be entitled to
receive the outcomes of a Duty
by being the
Assignees
(creditors) of such. In this
case, the Party
entity MUST identify a
group of people and/or legal entities. Each member of the group is the
beneficiary of the Duty
.Finally, the Party
entity undertakes
an additional role with the Asset
entity:
Party
entity can be related to
an Asset
by being the Rightsholder
(owner) of such. This role allows
expressing that someone simply "owns" an Asset
.The Permission
entity indicates the Action
s that the Assignee/s
is permitted to perform on the Target
Asset
. In other words, what the Assigner
(supplier) has granted to the Assignee
(consumer). Any ODRL rights expression MUST contain at least one Permission
.
The Permission
entity has the
following relations:
Action
s: the Permission
entity MUST contain exactly one Action
that indicates the granted operation on the Target
Asset
(REQUIRED)Asset
: the Permission
entity MUST also contain exactly one Asset
which is the Target
of the Permission
(REQUIRED)Constraint
s: one or more Constraint
s MAY optionally constrain the Permission
s, e.g. if the Action
play
is only permitted for a certain period
of time (OPTIONAL)Duties
: the Permission
MAY refer to one or more Duty
entities that
indicate a requirement that must be fulfilled in return for receiving
the Permission
(OPTIONAL)The Action
entity (when related to a
Permission
entity) indicates the operations
(e.g. play
, copy
,
etc.) that the Assignee/s
(i.e. the
consumer) is permitted to perform on the Target
Asset
. The Action
entity (when related to a Prohibition
entity) indicates the operations that the Assignee/s
(again the consumer) is prohibited to perform on the Target
Asset
.
The Action
entity contains 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 restriction 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
).
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 rights
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 an expressed in the ODRL Core Model.
The Duty
entity indicates a
requirement that must be fulfilled in return for being entitled to the
containing Permission
entity [ODRL-REQ#1.8].
The Duty
entity is related to a Party
entity via the role Assignee
who is responsible for fulfilling the Duty
,
and to an OPTIONAL Assigner
entity who is
entitled to receive the outcomes of the Duty
.
If there is no direct Assignee
, then the
Assignee
of the linked Permission
is responsible for fulfilling the Duty
(and
may be the same Party
).
The Assigner
can be indicated directly
between Party
and Duty
,
if not, then the Assigner
will be assumed
as the same as the Permission
Assigner
.
The Duty
entity has the
following relations:
Action
: indicates the operation
(e.g. pay
) that must be performed on the Object
entity (REQUIRED)Object
: indicates the item that is
subject of the Duty
(REQUIRED)Constraint
s: a Duty
MAY contain one or more Constraint
s [ODRL-REQ#1.10] (OPTIONAL)The Object
entity contains the
following attributes:
measure
: indicates a measure,
such as a currency ("AUD", "EUR") from a well defined vocabulary
(REQUIRED)value
: indicates the value of
the measure, for example 50, 10 or 0.5 (REQUIRED)The Object
of a Duty
MAY also be an Asset
entity.
The Duty
entity contains 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 develop existing) profiles to
capture additional/refined semantics.
The Duty
entity MAY contain the relax
boolean attribute that indicates if the
Duty
may be fulfilled at anytime, including
after the containing Permission
has been
utilised by the Assignee/s
. The default relax
boolean setting for all Duty
entities is false
meaning that the Duties must be fulfilled before the rights can be
exercised. If the value is true
then the Duty
can be fulfilled at anytime, but still must
be fulfilled.
The Prohibition
entity indicates the
Action
s that the Assignee/s
(or consumer/s) is/are prohibited to perform on the Target
Asset
[ODRL-REQ#1.7]. Prohibition
s are issued by
the supplier of the Asset
- the Assigner.
The Prohibition
entity has the
following relations:
Action
: the Prohibition
MUST refer to one Action
, for
example copy
(REQUIRED)Asset
: the Prohibition
entity MUST also refer to one Asset
which is the Target
of the Prohibition
s (REQUIRED)Constraint
s: one or more Constraint
s can optionally constrain Prohibition
s (OPTIONAL)A number of normative rights expressions features supported by the ODRL Core Model are discussed in this section.
The NextRights
association allows
for the specification of downstream (or transfer) rights to subsequent Assignee/s
. The NextRights
is expressed as a direct relationship between the pertinent Action
and a Rights
expression (that is the set of rights that the Assignee/s
must only use for downstream assignment). The NextRights
rights expression may not contain an Asset
entity. In this case the Asset
is assumed to
be the same as in the current (upstream) rights expression. When an Asset
entity is included in the NextRights
expression, then it is assumed that
this Asset
is a subset (or strongly related)
to the upstream Asset
. For example, the
upstream Asset
maybe a collection of five
tracks on a music Album, and the downstream Asset
is one specific track. For a Next Rights example please refer to Section
4 Scenarios.
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. |
Figure 3.1 shows a possible use of Extended Relations. In this
case, two Permission
Action
s
are linked via an XOR
(exclusive or)
relationship (related to a common Asset
.
This indicates that one of the Action
s, and
only one, can be used for the Permission
.
Figure 3.1 - Extended Relations Example |
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. For a Extended Relations
example please refer to Section 4 Scenarios.
This section shows a number of rights expression scenarios. In
these examples, the different rights 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
rights 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
.
The Set
shows a rights expression, stating
that the Asset
urn:asset:9898
is target of the Permission
s publish
and the Prohibition
to modify
. No parties or other elements are
involved. This Set
could be used, for
example, as a rights template or an instant license.
Figure 4.1 - An instance of a Set |
The following shows the instance of an Offer
.
The Offer
contains the music file urn:music:4545
that is offered by the Party
urn: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 4.2 - An instance of an Offer |
The following shows the instance of an Agreement
.
The Agreement
contains all entities shown in
the Offer
scenario above. A new Party
element urn:billie:888
has been added. This Party
accepted the
previous Offer
and thus is now the buyer of
the Permission
s play
and copy
, i.e. is related as assignee of the
Permission
s and Duty
elements.
Figure 4.3 - An instance of an Agreement |
The following shows the instance of a Request
.
The Party
urn:guest:0589
Requests the Permission
to display
the Asset
urn:news:0099
.
Figure 4.4 - An instance of a Request |
The following shows the instance of a Ticket
.
The Ticket
expresses the Permission
for the party urn:player:9876
to play
the game urn:game:4589
.
The Ticket
is valid until the end of the year
2010.
Figure 4.5 - An instance of a Ticket |
The following shows the instance of an Offer
with NextRights
. The party urn: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 Asset
according to the NextRights
linked directly from this Action
. In this case, the linked Asset
may only be display
ed
to downstream consumers.
Figure 4.6 - An instance of an Offer and Transfer Rights |
The following shows the instance of an Offer
with a Permission
Extended
Relation
. The Offer
includes two Permission
s copy
and print
that are tied together by a logical XOR
operator, i.e. either the Permission
print or the Permission
copy may be
performed but not both. The print
Permission
may only performed 5 times. Note that
each of the Permission
s may have their
individual constraints, target, etc.
Figure 4.7 - An instance of an Extended Relation |
The following shows the instance of an Agreement
with both a Permission
and a Prohibition
. The party urn:sony:10
assigns the Permission
play
to the Party
billie:888
at the same time they are prohibited from utilising the Asset
as a ringtone
.
Additionally, in case of any conflict, the conflict
attribute is set to perm
indicating that the
Permission
s will take precedence.
Figure 4.8 - An instance of an Permission and Prohibition Right |
The following shows the instance of an Child Agreement urn:exp:9999
inheriting from a Parent Agreement urn:exp:5531
. The inherit
attribute of the Asset
of the Child
Agreement has the same identifier as the Asset
in the Parent Agreement (linked via the dashed line). In this
inheritance example, the Parent Agreement allows the Billie Party
to print
the
parent Asset
and the Child Agreement allows
the Class:IT01 Party
(a group of
people) to print
the child Asset
and for the Billie
Party
to print
the parent Asset
. That is, the Child
Agreement includes all the entities of the Parent
Agreement.
Figure 4.9 - An instance of an Inheritance Rights |
The ODRL Core Model represents a broad need for rights 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:
The editors gratefully acknowledge feedback and contributions to this document from:
[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. ftp://ftp.rfc-editor.org/in-notes/rfc2119.txt
|
[UML] | Unified Modeling Language (UML), Management
Group, 2003. http://www.omg.org/technology/documents/formal/uml.htm
|