Open Digital Rights Language (ODRL) Version 2 Requirements

During two years of experience with the current ODRL Version 1.1 data model the following items were collected as additional required features of the data model.

It is intended to support the application of next rights to an implementable number of levels. The value chain of electronic goods and services has several participants: For example, content creators, content distributors, and content consumers. ODRL should enable content creators to specify usage rights and conditions for a reasonable number of lower levels, i.e. the content distributors, the consumers, etc.

While being passed along the value chain, electronic goods and services are sometimes aggregated or dis-aggregated. In education for example, lecture notes, slides, exercises, and exams are bundled to a teaching package for an entire course. ODRL must support that the rights of a single product, e.g. for an exercise, can be maintained and/or identified within the bundle.

The ODRL community asked for a language feature in ODRL that expresses and handles status information for state-based rights constraints. For example, a ring tone is purchased with a stated-based rights constraint, e.g. the ring tone may be used up to 100 times. If the customer has played the ring tone already 10 times, this is a status information that some DRM applications might need in the ODRL expression. Therefore, ODRL requires the additional expressiveness to describe the respective status information.

Support flexible negotiations with mechanisms to select/choose different options in offers and agreements and the semantics of such selections.

The distinction between rightsholder and consumer is not sufficient in some cases. For example, if a consumer buys a license but is not the person that consumes the resulting access rights, a third contract party, such as a beneficiary or end user, is required. To see more details about this requirement, please refer to [GS04].

   See current discussion about this requirement: [A], [B]

Provide mechanisms to express "fair use" exceptions of copyrights laws, which is an implemented concept e.g. in the U.S. and Australian laws, for example.

The current basic concept in ODRL is that rights that are not explicitly granted by an expression are not allowed. In contrast to this, the ODRL community asks for a language concept that is able to express the following: "Everything is allowed, except for XXX". Therefore, provide mechanisms that state what you are NOT allowed to do.

Provide language elements that can explicitly express right and duties of all contract parties. For example, expressing rights and duties for the rightsholder, e.g. that they must assure the delivery of a resource within the next 4 weeks. To see more details about this requirement, please refer to [GS04].

ODRL version 1.1. distinguishes between constraints, requirements, and conditions which can be assigned to ODRL permissions. Each of these clauses defines a certain side-condition for a respective permission. We believe that it would be more reasonable to distinguish between ODRL conditions/constraints on the one hand and ODRL requirements (which in essence define duties) on the other. ODRL conditions and ODRL constraints directly relate to a permission (e.g. do not play after 12/31/05; or play at most five times) whereas requirements are more of a precondition that has to be fulfilled before a right may actually be assigned to the corresponding beneficiary. ODRL requirements are classical duties, whereas ODRL conditions and ODRL constraints should be seen as constraints on permissions.

A corresponding data model would comply with the typical constraint data model of the access control community and ease the implementation and processing of expressions. To read more details about this requirement, please refer to [GS04].

A common type of expression used in contracts is the following: "the payment has to be made within four weeks after receipt of the shipment." With respect to ODRL 1.1 this expression is a requirement (the payment) that is narrowed by a constraint (within four weeks). To read more details about this requirement, please refer to [GS04].

A basic requirement is to keep ODRL simple. Its simpleness is the one of the key reasons that many initiatives use ODRL than other more complex rights expression languages.

As ODRL has already been accepted by standard organisations, such as the Open Mobile Alliance, further developments of the language require to be able to handle all language concepts of previous versions.

Formal semantics are required for the unambiguous implementation and processing of ODRL rights expressions. However, some pioneer work has already been done in this field [HKS04, PW04].

ODRL should explicitly support the use of right vocabularies from various sectors and communities. It should also support the reuse of other metadata vocabularies to supplement, e.g. the context element. For example, instead of using the context element to describe personal information, the vCard standard could be used.

All technical diagrams should be created with diagram types from the Unified Modeling Language.