This report contains a collection of cut and pasted definitions (as excerpted directly from each of the specifications) in order to demonstrate how each of the various "rights languages" is defined.
The table below demonstrates how, although not all of the Rights Languages I could find have both "rights" and "permissions", they certainly all have "rights." (None have only "permissions.")
Also of note is the universal trait of placing "conditions" on those "rights" and/or "rights and permissions."
| Name | Rights | Permissions | Other Notable Characteristics |
|---|---|---|---|
| MPEG | X |
| conditions, obligations |
| XRML 2.1 | X |
| conditions, resources |
| ODRL | X | X | conditions, constraints, requirements |
| XMCL | X | X | conditions |
| DRMEBOOKS | X | X | conditions |
| PRISM Rights Language | X | X |
|
| DPRL | X |
| conditions, fees |
MPEG 21 Overview - Approved - Rights Expression Language (ISO/IEC JTC1/SC29/WG11/N4801)
(http://mpeg.telecomitalialab.com/standards/mpeg-21/mpeg-21.htm)
6.5 MPEG-21 part 5 - Rights Expression Language
Following an extensive requirements gathering process which started in January 2001, MPEG issued a Call for Proposals during its July meeting in Sydney for a Rights Data Dictionary and a Rights Expression Language. Responses to this Call were processed during the December meeting in Pattaya and the evaluation process established an approach for going forward with the development of a specification, expected to be an International Standard in late 2003.
A Rights Expression Language is seen as a machine-readable language that can declare rights and permissions using the terms as defined in the Rights Data Dictionary.
The REL is intended to provide flexible, interoperable mechanisms to support transparent and augmented use of digital resources in publishing, distributing, and consuming of digital movies, digital music, electronic books, broadcasting, interactive games, computer software and other creations in digital form, in a way that protects digital content and honours the rights, conditions, and fees specified for digital contents. It is also intended to support specification of access and use controls for digital content in cases where financial exchange is not part of the terms of use, and to support exchange of sensitive or private digital content.
The Rights Expression Language is also intended to provide a flexible interoperable mechanism to ensure personal data is processed in accordance with individual rights and to meet the requirement for Users to be able to express their rights and interests in a way that addresses issues of privacy and use of personal data.
A standard Rights Expression Language should be able to support guaranteed end-to-end interoperability, consistency and reliability between different systems and services. To do so, it must offer richness and extensibility in declaring rights, conditions and obligations, ease and persistence in identifying and associating these with digital contents, and flexibility in supporting multiple usage/business models.
MPEG IPMP Requirements (Intellectual Property Management and Protection in MPEG Standards)
(http://mpeg.telecomitalialab.com/standards/ipmp/index.htm)
6 MPEG-7: Descriptions are as valuable as content
MPEG-7 specifies a different kind of coding than MPEG standards, as it does not define content representation for reproduction, but for content management (including search and retrieval, filtering of broadcasts, database asset management). MPEG-7 defines descriptions of content, from very low-level (colors, shapes, sound characteristics, segmentations in space and time) to very high level (written content descriptions, semantic information, the classical 'metadata'). Special attention has been given to Intellectual Property, which comes in a number of different forms in MPEG-7, from describing rights pertaining to content to protecting the value of MPEG-7 descriptions themselves.
MPEG-7 defines the following elements: Descriptors (Ds), Description Schemes (DSs) a Description Definitions Language (DDL - based on XML Schema Language) and again a Systems layer. Included is also a binary, streamable representation of Descriptions and the DDL, called BiM (Binary format for MPEG-7).
Like in MPEG-2 and in MPEG-4, MPEG has worked with all of its constituent industry sectors, among which rights holders, to define the requirements. An excerpt of the MPEG-7 Requirements Document V.12 [6] highlighting MPEG-7ıs IPMP requirements follows here:
1. No legal status of descriptions - MPEG-7 Descriptions by nature have no legal bearing. The standard shall be designed in such a way that this is as clear as possible. Note: The greatest concern amongst the creative sectors is associated with the dangers inherent in the misrepresentation of legal attribution to information relating to intellectual property.
2. Describing content rights - MPEG-7 shall provide a mechanism for pointing to content rights (rights owners, contractual information). Ds and DSs shall not directly describe content rights. Note: Rights ownership can change regularly which precludes the accurate declaration of this information in MPEG-7 applications. Allocation a unique identifier to each content element could be the answer. A resolution service could ensure that parties needing this information have appropriate access to it. [Note that MPEG-4 already allows this, RK]
3. Relationship to content management and protection measures - MPEG-7 shall accommodate, and not by design interfere with, rights management information and technological protection measures used to manage and protect content. Note: In accordance with the World Intellectual Property Organization (WIPO) treaties it is prohibited to circumvent, alter or remove
* Rights Management Information associated with content.
* Technical Protection Measures managing and protecting copyright material.
4. Applications distinguishing between legitimate and illegitimate content - a. MPEG-7 shall support applications that distinguish between legitimate and illegitimate content. b. The MPEG-7 standard shall be constructed so as to allow clear and unambiguous reference, in external specifications, agreements and in legislation, to the clauses in the MPEG-7 standard that address the requirement (a) above. Notes: While it is understood how (a) could be done inside trusted domains, further work is needed to investigate how this can be implemented outside trusted domains. On (b): The ability to reference the relevant part of the MPEG-7 standard in contracts, laws etc., will allow the enforcement of this feature where appropriate..
5. Authentication of descriptions - MPEG-7 shall offer a mechanism to allow for the authentication of MPEG-7 Descriptions. Note: This could be useful for companies specializing in selling Descriptions and for their customers.
6. Management and protection of descriptions - MPEG-7 shall support the management of intellectual property in Descriptions and protection from unauthorized access, use and modification Note: Descriptions may embody content that requires management and protection.
7. Management and protection of Ds and DSs - MPEG-7 shall support the management of intellectual property in Ds and DSs and protection from unauthorized access, use and modification. Note: The design of Ds and DSs may be intellectual property requiring management and protection.
8. Usage rules - MPEG-7 shall contain Ds/DSs that provide information on how content may be used. Note: Such a feature may provide considerable consumer benefit by, for example, providing pre-purchase information. It may also enable different creative sectors to achieve interoperability between the providers of similar services. However, it should be noted that MPEG-7 cannot override the usage rules associated with the content itself which will be governed by the usage rules of its own management and protection system.
9. Usage history - MPEG-7 shall contain Ds/DSs that provide information on how content has been used, in accordance with privacy rules. Note: 1) Such a usage history may be anonymous. 2) Such a description scheme can be used to record how often a film in a home database has been viewed.
10. Identification of content - MPEG-7 shall enable the identification of content by international identification conventions. Note: Each of the creative sectors can manage content identification at its own discretion through MPEG-7 Ds and DSs. Such identification is preferably accomplished as in the MPEG-4 IP Identification Data Set.
11. Identification of content in descriptions - Where the description contains content, MPEG-7 shall enable the identification of that content by international identification conventions. Notes: 1) For example, it is possible that a representation of the content, such as a thumbnailı of an image or the MIDI file of a sound recording will be used as the basis for constructing a Description for search purposes. In these examples, it may be necessary to identify the contentı in the Description. Such identification is preferably accomplished as in the MPEG-4 IP Identification Data Set. 2) There may be a need to be able to identify Descriptions.
12. Identification of descriptions - MPEG-7 may need to enable the unique identification of Descriptions. Note: This is for further discussion.
Again, we see the distinction between identification of IP (in this case in content as well as descriptions of content) and the protection of IP. Additional elements like audit trails make it possible to not only protect, but also manage the content and the descriptions. With the abundance of electronic content, good descriptions will be as important as the content itself, and descriptions will certainly hold significant value.
The author of this paper believes that the provisions in MPEG-4 can resolve most of the requirements above. The requirements for identification are very similar as in MPEG-4, and so will the solutions be: references to external registration bodies, together with unique IDs assigned by these. Also the protection and management can and probably will be similar. If we view MPEG-7 descriptions as just another form of content (³one manıs metadata is another manıs data²), then the existing DRM tools can be used for their authentication and protection. Additional Description Schemes are probably needed, e.g. for requirement 9 (usage history).
One requirement cannot be resolved using existing tools: the usage rules, requirement 8. Hence, a requirement to develop a rights description language comes not only from the MPEG-4 project, but also from MPEG-7 (and, as we will see, it has also surfaced in the context of MPEG-21).
XrML 2.1
(http://www.oasis-open.org/committees/rights/documents/xrml200205.zip)
This document explains the basic concepts for issuing rights in a machine-readable language and describes the language syntax and semantics. It does not provide specifications for security in trusted systems, propose specific applications, or describe the details of the accounting systems required.
One of the goals of this document is to develop an approach and language that can be used throughout industry to stipulate rights to use resources and the conditions under which those rights may be exercised and by whom. This document does not address the agreements, coordination or institutional challenges involved in achieving that goal.
ODRL (Open Digital Rights Language)
(http://www.w3.org/TR/odrl/)
The Rights include Permissions which can then contain Constraints, Requirements, and Conditions. Permissions are the actual usages or activities allowed over the Assets (eg Play a video Asset). Constraints are limits to these Permissions (eg Play the video for a maximum of 5 times). Requirements are the obligations needed to exercise the Permission (eg Pay $5 each time you Play the video). Conditions specify exceptions that, if become true, expire the Permissions and renegotiation may be required (eg If Credit Card expires then all Permissions are withdrawn to Play the video).
The Parties include end users and Rights Holders. Parties can be humans, organisations, and defined roles. End users are usually the asset consumers. Rights Holders are usually parties that have played some role in the creation, production, distribution of the Asset and can assert some form of ownership over the Asset and/or its Permissions. Rights Holders may also receive royalties.
With these three core entities, the foundation model can then express Offers and Agreements. Offers are proposals from Rights Holders for specific Rights over their Assets. Agreements are when Parties enter into contracts or deals with specific Offers. The model can also then express revoking of any Offers or Agreements.
The representation of Offers and Agreements is important core aspect of ODRL. This makes clear what the purpose of the rights expressions is achieving. Many different Offers can be created to meet various business models for assets. Offers can be linked, creating a hierarchy of options for end users. Agreements are the transformation of an Offer into a license for rights over an asset by parties. Also, there is no requirement that Offers be made prior to Agreements. After human interactions, Agreements can be created to express the accepted terms and conditions.
XMCL (the eXtensible Media Commerce Language)
(http://www.w3.org/TR/xmcl/)
XMCL is a "rights specification language", as defined by the Association of American Publishers [DRMEBOOKS]. The purpose of XMCL is for interchange of business rules to be applied to media between business systems (e.g. web store fronts, customer tracking and management) and trusted delivery and playback systems (e.g. a DRM implementation that will enforce the rights described in the XMCL document). Through the use of XMCL business systems are completely free of knowledge of specific trusted system implementations. This separation of the business systems and the trusted system allow businesses to support one or more trusted systems and provides the option of changing trusted systems as conditions change without changes to the business systems.
XMCL describes the minimum, self-complete set of business rules under which digital media is licensed for consumer use. These business rules support multiple business models including rental, subscription, ownership, and video on demand/pay-per-view. When a business system authorizes a customer transaction for digital media, it generates a XMCL document that is then acted upon and enforced by a specific trusted system. The generated XMCL document is submitted to the trusted system through the APIs of the trusted system (e.g. HTTP POST, RPC call, API call).
Digital Rights Management for Ebooks: Publisher Requirements Version 1.0(DRMEBOOKS)
(link goes to website -- Here is PDF document
Association of American Publishers, Inc, November, 2000.(see also: http://www.publishers.org/digital/drm.pdf)
Below equals: Digital Rights Management for Ebooks: Publisher Requirements Copyright İ 2000, Association of American Publishers, Inc. All Rights Reserved. Page 33 and 34
Legal Requirements Applicable to DRM Standards
Publishers require that DRM standards support applicable legislation. Moreover, DRM technology should be extensible to maintain compliance with new laws. Key requirements include:
· The DRM system shall support accessibility requirements in compliance with all applicable legislation.31
· The DRM system shall support consumer privacy in compliance with all applicable legislation.32
· The DRM system shall support applicable United States copyright law including ³fair use² as described in Section 107 of the United States Copyright Act of 1976. 33
· The DRM system shall support the Digital Millennium Copyright Act.34 Specific DRM Requirements Areas
RE: Rights Language Reqs
Rights Specification Language (RSL) Requirements
Rights specification language (RSL) refers to the mechanisms for describing the author/publisher rights associated with an ebook. This is a complex area, but an essential one for publishers. Publishers want to pursue a variety of business models such as superdistribution, pay-per-view, and free previews, and it is the DRM rights specification language that must be flexible enough to support these (and other) models.
Publishers require multiple mechanisms for specifying digital rights, and the RSL must be sufficiently flexible to support new and emerging business models that may change over time. For simple rights scenarios, check boxes may be sufficient, for example:
VIEW = YES PRINT = YES COPIES = 3 DELETE = NO SUPERDISTRIBUTE = NO
...The RSL must support changing business models and/or individual rights conditions over time. Rights specification should be dynamic, not static. It should be possible for a publisher to change the rights associated with an ebook after the ebook has been published. The rights specification language and supporting infrastructure should support these dynamic rights. For example, a publisher may decide, after a book has been offered with PRINT = NO rights, to offer PRINT = YES rights for a higher price. A related requirement: the RSL shall support republishing with new rights and/or upgrading existing rights.
...The RSL shall support specification of rights at the digital object level. Publishers require that the RSL support a variety of business models associated with selling portions (digital objects) of a digital work or collections of portions of a digital work.35 Each of the portions may carry a unique set of rights. Moreover, the rights associated with a collection of portions may vary 35 For an expanded treatment of digital object requirements and the relationship of the digital object to the overall ebook work, see the companion AAP numbering standards document, Numbering Standards for Ebooks, Version 1.0.
See table of specific requirements for any RSL pages 36-42
PRISM Digital Rights Language
(http://www.prismstandard.org/techdev/prismspec11.asp#_Toc1894470)
6.4 PRISM Rights Language
The PRISM WG put only the most commonly-needed rights elements into the PRISM namespace. For more involved treatment of rights and permissions in PRISM descriptions, elements from another namespace must be used. Because of the considerable activity around specifying rights and permissions, the PRISM working group could not recommend an existing standard to follow, as they were able to do with XML, RDF, and the Dublin Core. Therefore the working group has defined a small, simple, extensible language for expressing common rights and permissions. That language is known as the PRISM Rights Language (PRL). This section specifies that language. Note that implementations of PRISM MAY also implement PRL, but it is not mandatory. The PRISM Working Group expects PRL to be supplanted in time, once the activity around many different rights languages has settled down.
DPRL (The Digital Property Rights Language)
(http://xml.coverpages.org/DPRLmanual-XML2.html)
The Digital Property Rights Language Manual is a work in progress specifying a language for describing rights, conditions, and fees for using digital works. The Digital Property Rights Language (DPRL) is intended to support commerce in digital works, that is, publishing and selling electronic books, digital movies, digital music, interactive games, computer software and other creations distributed in digital form. It is also intended to support specification of access and use controls for secure digital documents in cases where financial exchange is not part of the terms of use...
...The digital property rights language describes distinct categories of uses for digital works in terms of "rights," including rights to copy a digital work, or to print it out, or to loan it, or to use portions of it in derivative works. DPRL also describes conditions and fees (if any) relevant to such uses.
Before describing the language itself, this introduction first discusses the commercial context for DPRL. It discusses the intended audience for this manual and how usage rights would actually appear to creators, publishers, and consumers of digital works. Finally, it describes our design goals and assumptions for the language.
For variety in expression, we use the words digital property rights, digital rights, and usage rights synonymously. Similarly, we use the words digital property rights language, digital property language, digital rights language, and rights language synonymously. We also use the terms digital publications, digital documents, and digital works synonymously...
...Different publishing and distribution systems require different kinds of subsystems and capabilities. The digital property language is primarily concerned with those systems that are directly involved in buying, selling, and using digital works. These systems would generally be implemented as trusted systems.
A trusted system is a system that can hold digital works and which can be trusted to honor the rights, conditions, and fees specified for a work. Trusted systems can take different forms, such as "trusted players" that play digital works, or "trusted readers" for reading digital works or "trusted servers" that may provide access to digital works on a network. Recognizing that different applications require different kinds of trusted systems and different levels of security, we use the terms trusted system and repository interchangeably to refer generically to systems relied on to keep documents secure and to honor usage rights.