This document is a work-in-progress and may be updated and/or replaced by other documents at any time.
The intention is to promote this draft document amongst multiple communities interested in the expression of Digital Rights Management statements and semantic interoperability across these communities.
ODRL will be standardised via an appropriate, open, and non-competitive organisation with an open process for the future maintenance of the standard.
ODRL has no license requirements and is available in the spirit of "open source" software.
Comments are welcome to the editors from all interested parties.
Change Bars (in the PDF document only) indicate modifications from the previous version.
Digital Rights Management (DRM) involves the description, layering, analysis, valuation, trading and monitoring of the rights over an enterprise's assets; both in physical and digital form; and of tangible and intangible value. DRM covers the digital management of rights - be they rights in a physical manifestation of a work (eg a book), or be they rights in a digital manifestation of a work (eg an ebook). Current methods of managing, trading and protecting such assets are inefficient, proprietary, or else often require the information to be wrapped or embedded in a physical format.
A key feature of managing online rights will be the substantial increase in re-use of digital material on the Web as well as the increased efficiency for physical material. The pervasive Internet is changing the nature of distribution of digital media from a passive one way flow (from Publisher to the End User) to a much more interactive cycle where creations are re-used, combined and extended ad infinitum. At all stages, the Rights need to be managed and honoured with trusted services.
Current Rights management technologies include languages for describing the terms and conditions, tracking asset usages by enforcing controlled environments or encoded asset manifestations, and closed architectures for the overall management of rights.
The Open Digital Rights Language (ODRL) provides the semantics for DRM in open and trusted environments whilst being agnostic to mechanisms to achieve the secure architectures.
It is envisaged that ODRL will "plug into" an open framework that enables peer-to-peer interoperability for DRM services. However, ODRL can also be used as an mechanism to express rights statements on its own and to plug into existing DRM architectures/frameworks.
Digital Rights Management (DRM) has traditionally been flavoured with security and encryption as a means to solve these issues, that is, Digital Rights Enforcement. This is the first-generation of DRM and represents a substantial narrowing of its real and broader capabilities. Second-generation DRM systems will provide these additional functions and support end-to-end supply chain DRM services.
DRM systems should be based on and designed around open functional architectures and a robust and extensible information model. See [IANNELLA] for an overview of DRM Architectures and [ERICKSON] for DRM-enabled digital object models. The layers and relationships of rights can also quickly become very complex [HIGGS] and DRM systems must be designed to cater for this intricacy.
This document, along with its normative references, includes all the specification necessary for the implementation of interoperable ODRL applications.
The key words must, must not, required, shall, shall not, should, should not, recommended, may, and optional in this specification are to be interpreted as described in [RFC2119] which defines the significance of each particular requirement.
Examples used in this document are for demonstration purposes only.
ODRL complements existing analogue rights management standards by providing digital equivalents, and supports an expandible range of new services that can be afforded by the digital nature of the assets in the Web environment. In the physical environment, ODRL can be used to enable machine-based processing for Rights management.
ODRL is a standard vocabulary for the expression of terms and conditions over assets. ODRL covers a core set of semantics for these purposes including the rights holders and the expression of permissible usages for asset manifestations. Rights can be specified for a specific asset manifestation (format) or could be applied to a range of manifestations of the asset.
ODRL is focused on the semantics of expressing rights languages and definitions of elements in the data dictionary. ODRL can be used within trusted or untrusted systems for both digital and physical assets. However, ODRL does not determine the capabilities nor requirements of any trusted services (eg for content protection, digital/physical delivery, and payment negotiation) that utilises its language. Clearly, however, ODRL will benefit transactions over digital assets as these can be captured and managed as a single rights transaction. In the physical world, ODRL expressions would need an accompanying system with the distribution of the physical asset.
ODRL defines a core set of semantics. Additional semantics can be layered on top of ODRL for third-party value added services.
ODRL does not enforce or mandate any policies for DRM, but provides the mechanisms to express such policies. Communities or organisations, that establish such policies based on ODRL, do so based on their specific business or public access requirements.
ODRL depends on the use of unique identification of assets. This is a very difficult problem to address and to have agreement across many sectors and is why identification mechanisms and policies of the assets is outside the scope of ODRL. Sector-specific versions of ODRL may address the need to infer information about the asset manifestation from its unique identifier.
The ODRL model is based on an analysis and survey of sector specific requirements (including models and semantics), and as such, aims to be compatible with a broad community base. ODRL intends to meet the common requirements for many sectors and has been influenced by the ongoing work and specifications/models of the following groups:
ODRL proposes to be compatible with the above groups by defining an independent and extensible set of semantics. ODRL does not depend on any media types as it is aimed for cross-sector interoperability.
The ODRL specification contains three main sections:
The formal Expression Language and Data Dictionary elements are defined in:
The next release will include details on:
The models for the ODRL language contain the structure and core semantics for the expressions. These models provide the overall framework for the expressions into which elements (from DRM data dictionaries) can be applied.
Note: The figures in this section cover both the Expression Language entities (shown as shadowed rectangles with "EX" in the top left corner) and the Data Dictionary elements (shown as rectangles with "DD" in the top left corner).
ODRL is based on an extensible model for rights expressions which involves a number of core entities that are related to each other. This ODRL Foundation Model is shown in Figure 1.
The top-level Rights entity consists of an aggregation of the following entities:
A Permission is the allowed activities over an Asset. Permissions may also be bound by Constraints and oblige Requirements from parties. Assets have Rights Holders (which are identifiable parties holding intellectual property rights over the asset).
Typically, these expressions allow for generic Rights to be declared over assets. Additionally, ODRL can support expressions when individual parties reach an Agreement (ie a specific instance of an expression) between a set of Permissions over Assets and Parties.
Most entities in the model can support a specific Context. A Context, which is relative to the entity, can describe further information about that entity or the relationship between entities. For example, the Context of an Agreement may specify the date of the transaction, the Context of a Party may specify their role.
The general description of the Party and Asset entities is outside the scope of ODRL. What is in scope is that these entities must be referenced by using unique identification mechanisms (such as [URI], [DOI], [ISBN] etc). Both of these entities contain a mechanism to refer to their unique identifiers, as well as a Context.
The Asset entity (sometimes referred to as a Work, Content, Creation, or Intellectual Property), is viewed as a whole entity. If the Rights are assigned at the Asset's subpart level, then such parts would require to also be uniquely identifiable. However, ODRL can specify constraints on subparts of the asset. Additionally, Assets can be identified as to their layer of intellectual property as defined by the IFLA model [IFLA]. These include Work, Expression, Manifestation, and Item. This features allows rights to be expressed over non-tangible assets.
These eight core Entities together allow for a wide and flexible range of ODRL expressions to be declared. The entities (except for Asset and Party) are further explained in the following sections, including XML pseudo-examples.
The ODRL Foundation Model can be expressed using XML. A pseudo-example is shown Example 1.
Complete and formal syntactical examples are given in Section 4 "ODRL XML Syntax".
ODRL supports the expression of Permissions. This is the recognised set of activities allowed over the Asset. The ODRL Permission Model is shown in Figure 2.
The Permission entity consists of an aggregation of three abstract entities. The abstract entities (depicted as clouds in Figure 2) are solely used to group similar permissions, and include:
Note: The listed elements above (eg Display, Print etc) are defined in full in Section 3 "ODRL Data Dictionary Semantics" and form the basis of the ODRL Data Dictionary.
Additionally, the Permissions support:
A Permission must be associated with one or more Assets. A Permission can be associated with zero or more Constraints.
A Permission that is not specified in any Rights Expressions is not granted. That is, no assumptions should be made in regard to Permissions if they are not explicitly mentioned in the ODRL expression.
The ODRL Permission Model can be expressed using XML. A pseudo-example is shown in Example 2 in which permissions for display, print (with a constraint), and annotate have been granted.
<permission> <display/> <print> <constraint> ... </constraint> </print> <annotate/> </permission> |
Complete and formal syntactical examples are given in Section 4 "ODRL XML Syntax".
ODRL supports the expression of Rights Constraints. This is the recognised set of restrictions on the Permissions over the Asset. The ODRL Constraint Model is shown in Figure 3.
The Constraints entity consists of an aggregation of six abstract entities. The abstract entities (depicted as clouds in Figure 3) are solely used to group similar constraints, and include:
Note: The listed elements above (eg Individual, Group etc) are defined in full in Section 3 "ODRL Data Dictionary Semantics" and form the basis of the ODRL Data Dictionary.
A Constraint is associated with one Permission. If a Constraint appears at the same level as a number of Permissions, then the Constraint applies to all of the Permissions. Most Constraints can also have zero or more other Constraints. However, the Bounds and Temporal constraints do not permit sub-constraints.
For Permissions with multiple constraints, all constraints must be honoured and no conflicts should arise. An error must be generated if the latter is true.
Any Constraint that is expressed but cannot be performed by the consuming system, must not be granted. That is, if a system does not understand how to guarantee that a specified constraint be honoured it must not grant the permission at all.
The ODRL Constraint Model can be expressed using XML. A pseudo-example is shown in Example 3 in which the display permission is constrained to a particular CPU and may only be printed up to 5 times.
<display> <constraint> <cpu/> </constraint> </display> <print> <constraint> <count start="1" end ="5"/> </constraint> </print> |
Complete and formal syntactical examples are given in Section 4 "ODRL XML Syntax".
ODRL supports the expression of Rights Requirements. This is the recognised set of preconditions that must be met in order to obtain the related permissons. The ODRL Requirements Model is shown in Figure 4.
The Requirement entity consists of one abstract entity. The abstract entity (depicted as a cloud in Figure 4) and is solely used to group similar Fee requirements, and includes:
Note: The listed elements above (eg PrePay etc) are defined in full in Section 3 "ODRL Data Dictionary Semantics" and form the basis of the ODRL Data Dictionary.
A Requirement can be associated with one or many Permissions. If a Requirement appears at the same level as a number of Permissions, then the Requirement applies once to all of the Permissions. For Permissions with multiple Requirements, all Requirements must be honoured and no conflicts should arise. An error must be generated if the latter is true.
The ODRL Data Dictionary also defines the common reusable Payment entity, A payment consists of the amount to pay, the currency of the amount, the taxation due (as a percentage) and a taxation code.
Any Requirement that is expressed but cannot be performed by the consuming system, must not be granted. That is, if a system does not understand how to guarantee that a specified Requirement has been met, then it must not grant the permission at all.
The ODRL Requirement Model can be expressed using XML. A pseudo-example is shown in Example 4 in which the play permission requires a $AUD20 fee (plus 10% tax) to be paid per use.
Complete and formal syntactical examples are given in Section 4 "ODRL XML Syntax".
ODRL supports the identification of Rights Holders. The Rights Holder is a recognised Party and any set of entitlements that they are due for the use of their Asset. The ODRL Rights Holder Model is shown in Figure 5.
The Rights Holder entity consists of one abstract entity: The abstract entity (depicted as a cloud in Figure 5) is solely used to group similar Rights Holder royalty entitlements, and include:
Note: The listed elements above (eg Percentage etc) are defined in full in Section 3 "ODRL Data Dictionary Semantics" and form the basis of the ODRL Data Dictionary.
A Rights Holder can contain one or more Parties, and can be associated with one or many Assets. Parties can also be nested to indicate dependencies. For example; to support Rights Holder Sonya receiving 10% of Rights Holder Fiona's royalty (who may receive a fixed amount).
The ODRL RightsHolder Model can be expressed using XML. A pseudo-example is shown in Example 5 in which two identified parties share royalties with 90% to one and 10% to the other for each net transaction over their asset.
Complete and formal syntactical examples are given in Section 4 "ODRL XML Syntax".
ODRL supports expressing additional information about entities and related entities. The ODRL Context Model is shown in Figure 6.
The Context entity is an aggregation of seven other entities and includes:
Note: The listed elements above (eg UID etc) are defined in full in Section 3 "ODRL Data Dictionary Semantics" and form the basis of the ODRL Data Dictionary.
The Context is used for a number of different purposes and can be associated with any entity. When declaring Assets, it is used to indicate the unique identifier for the asset. When declaring Parties, it is used to indicate the unique identifier for the party, what role they may have played, and their name. The whole rights expression can also have a Context to indicate the unique identifier for the expression as well as when it was created. The Agreement entity can also have a Context to indicate the location of the transaction.
The ODRL Context Model can be expressed using XML. A pseudo-example is shown in Example 6 in which the context for a party is described.
Complete and formal syntactical examples are given in Section 4 "ODRL XML Syntax".
ODRL supports expressing agreements made between parties for specific rights over assets. The ODRL Agreement Model is shown in Figure 7.
The Agreement entity is an aggregation of four other entities and includes:
The Agreement entity allows for detailed expressions of particular parties who have negotiated and agreed to a set of particular permissions over some assets.
The ODRL Agreement Model can be expressed using XML. A pseudo-example is shown in Example 7 in which an agreement, with context, is described between a party and a set of permissions over an asset.
Complete and formal syntactical examples are given in Section 4 "ODRL XML Syntax".
The ODRL expression language also supports a number of grouping mechanisms for entities into containers. The groupings in the containers imply explicit semantics and must be supported.
There are three types of containers defined:
A new structure, called "container" maybe utilised to aggregate other entities to enforce the above semantics. The container structure will have an attribute ("and", "ex-or", "in-or") to indicate the container type. The default container type is "and". Additionally, when no container structure is used, the default of "and" is implied.
The container semantics only applies to the immediate children of the container.
Typically the container structure is used to aggregate permissions, constraints, and requirements but can be used on other entities.
The ODRL Container structure can be expressed using XML. A pseudo-example is shown in Example 8 in which the play permission is constrained to either (or both) the CPU of Storage device and the requirement is to either pay up front ($AUD200) or per use ($AUD1.50).
Complete and formal syntactical examples are given in Section 4 "ODRL XML Syntax".
The ODRL expression language also supports the ability to explicitly link expression fragments. The links between the expression fragments imply explicit semantics and must be supported. The linking allows for ODRL expressions to be constructed by reusing existing expressions and allowing explicit links between fragments. Each ODRL fragment can be uniquely identified.
In the usual case, entities appearing in an ODRL rights expression is assumed to be related. That is, a Permission entity that appears with an Asset entity are assumed to be related (ie this expresses the Asset's permissions). When explicit linking is used, then the link relationships take precedence. The examples in the next section show how these cases can be expressed.
The ODRL Link structure can be expressed using XML. A pseudo-example is shown in Example 9 in which the sell permission only applies to ASSET-01 and the lend permission applies to both ASSET-01 and ASSET-02.
Complete and formal syntactical examples are given in Section 4 "ODRL XML Syntax".
This section details the semantics of all the ODRL data dictionary elements that is used within the ODRL expression language. The ODRL data dictionary elements form the basis of the language and can be extended (see Section 5 "ODRL Extensibility") by additional elements. Each element in the data dictionary is defined using the following attributes defined by ISO-11179:
The data dictionary elements are defined below in the following five sections:
The Elements are defined in Table 1: Permission Elements.
The Elements are defined in Table 2: Constraint Elements.
The Elements are defined in Table 3: Requirement Elements.
The Elements are defined in Table 4: Rights Holder Elements.
The Elements are defined in Table 5: Context Elements.
The role values may be selected from existing vocabulary schemes, including |
|||
The link must be a URI and resolve to (at least) well formed XML. |
ODRL is expressed in schema-valid XML syntax. This syntax is formally specified by the XML Schemas defined in Appendix A and Appendix B. These are the normative references for the ODRL expression language and data dictionary (respectively).
Note: If the human language needs to be specified for any elements containing string values, then the use of the standard "xml:lang" attribute is recommended.
ODRL utilises two XML Schemas. One schema defines the Expression Language elements and constructs (see Appendix A), the other defines the Data Dictionary elements (see Appendix B). Both must be used to support valid ODRL expressions. Further, the Data Dictionary schema is dependent on the Expression Language schema as the former defines elements that are constrained by the expression language model.
The Expression Language schema defines abstract elements that are utilised as the "place holder" for data dictionary elements. For example, the Expression Language schema defines:
<xsd:element name="permissionElement" type="o-ex:permissionType" abstract="true"/>
which allows permission elements to be defined in the Data Dictionary schema, such as:
<xsd:element name="display" substitutionGroup="o-ex:permissionElement"/>
The Data Dictionary schema utilises the "substitutionGroup" mechanism from XML Schema to ensure that only the appropriate elements can be used in the correct position in the Expression Language.
ODRL supports XML Namespaces to indicate the scope and identity of its elements and other content description elements.
The version 0.9 XML Namespace URI for the ODRL Expression Language is:
http://odrl.net/0.9/ODRL-EX
The version 0.9 XML Namespace URI for the ODRL Data Dictionary is:
http://odrl.net/0.9/ODRL-DD
NOTE: These URIs should be considered experimental until the ODRL specification is formalised by an appropriate body and new XML Namespaces and URIs are assigned.
ODRL uses XML Schema ID and IDREF to refer from XML fragments to other fragments as described in Section 2.9 "Expression Linking". This is used to express the relationship between the core ODRL entities such as Asset, Permission, and Agreement. Such elements can be identified with the "id" attribute then referred to via "idref" attribute.
It is important to recognise that as the ODRL expressions become more complicated, the need to partition and express linkages becomes paramount in order to have manageable and reusable rights expressions. The linking mechanism allows for quite complex expressions to be generated whilst preserving the interpretability of the overall rights language.
The XML syntax will be explained via a serious of scenarios covering different content sectors (ebooks, video, education).
Corky Rossi (an author) and Addison Rossi (an illustrator) publish their ebook via "EBooksRUS Publishers". They wish to allow consumers to purchase (a requirement to pay $AUD20.00 plus 10% tax) the ebook which is restricted to a single CPU only and they are allowed to print a maximum of 2 copies. They will also allow the first 5 pages (Units) of the ebook to be viewed online for free (no requirement). Note the use of the NumberOfPages entity from the ONIX namespace to indicate the unit type.
The revenue split is 60% to the Author, 10% to the Illustrator and 30% to the Publisher. Their identities are shown from an X.500 repository and their roles indicated using the ONIX and MARC terms.
The XML encoding of this scenario in ODRL is shown below:
<?xml version="1.0" encoding="UTF-8"?>
<o-ex:rights xmlns:o-ex="http://odrl.net/0.9/ODRL-EX"
xmlns:o-dd="http://odrl.net/0.9/ODRL-DD"
xmlns:onix="http://www.editeur.org/onix/ReferenceNames"
xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance"
xsi:schemaLocation="http://odrl.net/0.9/ODRL-DD http://odrl.net/0.9/ODRL-DD-09.xsd
http://odrl.net/0.9/ODRL-EX http://odrl.net/0.9/ODRL-EX-09.xsd">
<o-ex:asset>
<o-ex:context>
<o-dd:uid o-dd:idscheme="DOI">10.999999/ebook/rossi-000001</o-dd:uid>
<o-dd:name>Why Cats Sleep and We Don't</o-dd:name>
</o-ex:context>
</o-ex:asset>
<o-ex:permission>
<o-dd:display>
<o-ex:constraint>
<o-dd:cpu/>
</o-ex:constraint>
</o-dd:display>
<o-dd:print>
<o-ex:constraint>
<o-dd:count o-dd:end="2"/>
</o-ex:constraint>
</o-dd:print>
<o-ex:requirement>
<o-dd:prepay>
<o-dd:payment>
<o-dd:amount o-dd:currency="AUD">20.00</o-dd:amount>
<o-dd:taxpercent o-dd:code="GST">10.00</o-dd:taxpercent>
</o-dd:payment>
</o-dd:prepay>
</o-ex:requirement>
</o-ex:permission>
<o-ex:permission>
<o-dd:display>
<o-ex:constraint>
<o-dd:unit o-dd:type="onix:NumberOfPages">
<o-ex:constraint>
<o-dd:range o-dd:min="1" o-dd:max="5"/>
</o-ex:constraint>
</o-dd:unit>
</o-ex:constraint>
</o-dd:display>
</o-ex:permission>
<o-ex:rightsholder>
<o-ex:party>
<o-ex:context>
<o-dd:uid o-dd:idscheme="X500">c=AU;o=Rights Dir;cn=Corky Rossi</o-dd:uid>
<o-dd:role o-dd:idscheme="ONIX">A01</o-dd:role>
</o-ex:context>
<o-dd:percentage>60</o-dd:percentage>
</o-ex:party>
<o-ex:party>
<o-ex:context>
<o-dd:uid o-dd:idscheme="X500">c=AU;o=Rights Dir;cn=Addison Rossi</o-dd:uid>
<o-dd:role o-dd:idscheme="ONIX">A12</o-dd:role>
</o-ex:context>
<o-dd:percentage>10</o-dd:percentage>
</o-ex:party>
<o-ex:party>
<o-ex:context>
<o-dd:uid o-dd:idscheme="X500">c=AU;o=Rights Dir;cn=EBooksRUS</o-dd:uid>
<o-dd:role o-dd:idscheme="MARC">pbl</o-dd:role>
</o-ex:context>
<o-dd:percentage>30</o-dd:percentage>
</o-ex:party>
</o-ex:rightsholder>
</o-ex:rights>
Following from Ebook Scenario #1 (above), a consumer (Mary Smith) decides to purchase the ebook under the conditions outlined. The ODRL expression below shows the Agreement generated. The Agreement has a context (with identifier and date). The Permission now shows the details of the constraint that is specific to the consumer. (In this case, the CPU identifier is saved with the license.)
The XML encoding of this scenario in ODRL is shown below:
<?xml version="1.0" encoding="UTF-8"?>
<o-ex:rights xmlns:o-ex="http://odrl.net/0.9/ODRL-EX"
xmlns:o-dd="http://odrl.net/0.9/ODRL-DD"
xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance"
xsi:schemaLocation="http://odrl.net/0.9/ODRL-DD http://odrl.net/0.9/ODRL-DD-09.xsd
http://odrl.net/0.9/ODRL-EX http://odrl.net/0.9/ODRL-EX-09.xsd">
<o-ex:agreement>
<o-ex:context>
<o-dd:uid o-dd:idscheme="DOI">10.999999/license/1234567890-ABCDEF</o-dd:uid>
<o-dd:dateEvent o-dd:date="2001-06-01"/>
<o-dd:location>Sydney, Australia</o-dd:location>
<o-dd:remark>Transacted by Example.Com</o-dd:remark>
</o-ex:context>
<o-ex:asset>
<o-ex:context>
<o-dd:uid o-dd:idscheme="DOI">10.999999/ebook/rossi-000001</o-dd:uid>
</o-ex:context>
</o-ex:asset>
<o-ex:permission>
<o-dd:display>
<o-ex:constraint>
<o-dd:cpu>
<o-ex:context>
<o-dd:uid o-dd:idscheme="GUID">
WebBuy:CPD-ID:ER-393939-DSS-787878</o-dd:uid>
</o-ex:context>
</o-dd:cpu>
</o-ex:constraint>
</o-dd:display>
<o-dd:print>
<o-ex:constraint>
<o-dd:count o-dd:end="2"/>
</o-ex:constraint>
</o-dd:print>
<o-ex:requirement>
<o-dd:prepay>
<o-dd:payment>
<o-dd:amount o-dd:currency="AUD">20.00</o-dd:amount>
<o-dd:taxpercent o-dd:code="GST">10.00</o-dd:taxpercent>
</o-dd:payment>
</o-dd:prepay>
</o-ex:requirement>
</o-ex:permission>
<o-ex:party>
<o-ex:context>
<o-dd:uid o-dd:idscheme="DOI">10.999999/users/msmth-0001111</o-dd:uid>
<o-dd:name>Mary Smith</o-dd:name>
</o-ex:context>
</o-ex:party>
</o-ex:agreement>
</o-ex:rights>
The ebook for an "Electronic Book Exchange" voucher is entitled "XML: A Manager's Guide". The rights owner is Addison-Wesley.
There is an agreement with the Distributor of this book (a company called "XYZ"). They have rights to Sell up to 5000 copies of the book. The have "Narrow" rights for Sell.
Another licensed end user for this book is "John Doe". All his permissions start from the beginning of 2001 and finish at the end of 2004. He has rights to view the book for a total of 30 days. He can print up to 5 copies on a "trusted printer". He can print up to 5 pages between page 1 and 100 every week - up to a total of 100 pages - on an any printer. He can also extract 5000 bytes every week up to a total of 1,000,000 bytes onto the Clipboard (memory). He has a right to Give the book away after one year of the permissions starting.
Note the use of the NumberOfPages and NumbeOfBytes entities from the ONIX and EBX namespaces. Note the use of id and idref for indicating the relationships between the agreements/rightsholder and the asset.
The XML encoding of this scenario in ODRL is shown below:
<?xml version="1.0" encoding="UTF-8"?>
<o-ex:rights xmlns:o-ex="http://odrl.net/0.9/ODRL-EX"
xmlns:o-dd="http://odrl.net/0.9/ODRL-DD"
xmlns:onix="http://www.editeur.org/onix/ReferenceNames"
xmlns:ebx="http://www.ebxwg.org/ebook/vocab/"
xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance"
xsi:schemaLocation="http://odrl.net/0.9/ODRL-DD http://odrl.net/0.9/ODRL-DD-09.xsd
http://odrl.net/0.9/ODRL-EX http://odrl.net/0.9/ODRL-EX-09.xsd">
<o-ex:context>
<o-dd:uid o-dd:idscheme="DOI">10.999999/voucher/2001/1234567890</o-dd:uid>
<o-dd:dateEvent o-dd:date="2001-05-01" o-dd:event="issued"/>
</o-ex:context>
<o-ex:asset o-ex:id="a001">
<o-ex:context>
<o-dd:uid o-dd:idscheme="ISBN">872-2345-981</o-dd:uid>
<o-dd:name>XML: A Manager's Guide</o-dd:name>
</o-ex:context>
</o-ex:asset>
<o-ex:rightsholder>
<o-ex:asset o-ex:idref="a001"/>
<o-ex:party>
<o-ex:context>
<o-dd:uid o-dd:idscheme="URI">http://publishers.net/registry/AWL</o-dd:uid>
<o-dd:name>Addison-Wesley</o-dd:name>
<o-dd:reference>http://www.addison-wesley.com</o-dd:reference>
</o-ex:context>
</o-ex:party>
</o-ex:rightsholder>
<o-ex:agreement>
<o-ex:asset o-ex:idref="a001"/>
<o-ex:party>
<o-ex:context>
<o-dd:uid o-dd:idscheme="URI">http://distributors.net/registry/xyz</o-dd:uid>
<o-dd:name>XYZ Company</o-dd:name>
<o-dd:role o-dd:idscheme="MARC">dst</o-dd:role>
</o-ex:context>
</o-ex:party>
<o-ex:permission o-ex:narrow="true">
<o-dd:sell>
<o-ex:constraint>
<o-dd:count o-dd:end="5000"/>
</o-ex:constraint>
</o-dd:sell>
</o-ex:permission>
</o-ex:agreement>
<o-ex:agreement>
<o-ex:asset o-ex:idref="a001"/>
<o-ex:party>
<o-ex:context>
<o-dd:uid o-dd:idscheme="URI">http://people.net/registry/john-doe-9999</o-dd:uid>
<o-dd:name>John Doe</o-dd:name>
</o-ex:context>
</o-ex:party>
<o-ex:permission>
<o-ex:constraint>
<o-dd:datetime o-dd:start="2001-01-01" o-dd:end="2004-12-31"/>
</o-ex:constraint>
<o-dd:display>
<o-ex:constraint>
<o-dd:accumulated>P30D</o-dd:accumulated>
</o-ex:constraint>
</o-dd:display>
<o-dd:print>
<o-ex:container o-ex:type="and">
<o-ex:constraint>
<o-dd:count o-dd:end="5"/>
<o-dd:printer>
<o-ex:context>
<o-dd:uid o-dd:idscheme="GUID">Trust:Print:4747474742222</o-dd:uid>
</o-ex:context>
</o-dd:printer>
</o-ex:constraint>
<o-ex:constraint>
<o-dd:unit o-dd:type="onix:NumberOfPages">
<o-ex:constraint>
<o-dd:count o-dd:end="100"/>
</o-ex:constraint>
</o-dd:unit>
<o-dd:printer/>
</o-ex:constraint>
<o-ex:constraint>
<o-dd:unit o-dd:type="onix:NumberOfPages">
<o-ex:constraint>
<o-dd:range o-dd:min="1" o-dd:max="100"/>
</o-ex:constraint>
</o-dd:unit>
<o-dd:interval>P7D</o-dd:interval>
<o-dd:printer/>
</o-ex:constraint>
</o-ex:container>
</o-dd:print>
<o-dd:copy>
<o-ex:constraint>
<o-dd:memory>
<o-ex:constraint>
<o-dd:unit o-dd:type="ebx:NumberOfBytes">
<o-ex:constraint>
<o-dd:range o-dd:min="1" o-dd:max="100"/>
</o-ex:constraint>
</o-dd:unit>
<o-dd:interval>P7D</o-dd:interval>
<o-dd:printer/>
</o-ex:constraint>
</o-dd:memory>
</o-ex:constraint>
</o-dd:copy>
<o-dd:give>
<o-ex:constraint>
<o-dd:datetime o-dd:start="2002-01-01"/>
</o-ex:constraint>
</o-dd:give>
</o-ex:permission>
</o-ex:agreement>
</o-ex:rights>
A video has three rights holders. Massimo Canale receives 75% of the transactions and Simona Canale receives the other 25%. Additionally, Maria Canale receives 10% of Simona's share. (Note the nesting of the last two parties.)
The video is offered at two different levels of quality (30 and 90dpi) and each has a different per use fee.
Note the use of the "resolution" entity from the MPEG7 namespace to indicate the Quality aspect of the asset.
The XML encoding of this scenario in ODRL is shown below:
<?xml version="1.0" encoding="UTF-8"?>
<o-ex:rights xmlns:o-ex="http://odrl.net/0.9/ODRL-EX"
xmlns:o-dd="http://odrl.net/0.9/ODRL-DD"
xmlns:mpeg7="http://www.mpeg7.org/2001/MPEG-7_Schema"
xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance"
xsi:schemaLocation="http://odrl.net/0.9/ODRL-DD http://odrl.net/0.9/ODRL-DD-09.xsd
http://odrl.net/0.9/ODRL-EX http://odrl.net/0.9/ODRL-EX-09.xsd">
<o-ex:asset>
<o-ex:context>
<o-dd:uid o-dd:idscheme="DOI">10.9999999/video/383838383</o-dd:uid>
<o-dd:name>XML: The Movie</o-dd:name>
</o-ex:context>
</o-ex:asset>
<o-ex:rightsholder>
<o-ex:party>
<o-ex:context>
<o-dd:uid o-dd:idscheme="X500">c=IT;o=Registry;cn=Massimo Canale</o-dd:uid>
</o-ex:context>
<o-dd:percentage>75</o-dd:percentage>
</o-ex:party>
<o-ex:party>
<o-ex:context>
<o-dd:uid o-dd:idscheme="X500">c=IT;o=Registry;cn=Simona Canale</o-dd:uid>
</o-ex:context>
<o-dd:percentage>25</o-dd:percentage>
<o-ex:party>
<o-ex:context>
<o-dd:uid o-dd:idscheme="X500">c=IT;o=Registry;cn=Maria Canale</o-dd:uid>
</o-ex:context>
<o-dd:percentage>10</o-dd:percentage>
</o-ex:party>
</o-ex:party>
</o-ex:rightsholder>
<o-ex:permission>
<o-dd:play>
<o-ex:constraint>
<o-dd:quality o-dd:type="mpeg7:resolution">
<o-ex:constraint>
<o-dd:range o-dd:max="30"/>
</o-ex:constraint>
</o-dd:quality>
</o-ex:constraint>
<o-ex:requirement>
<o-dd:peruse>
<o-dd:payment>
<o-dd:amount o-dd:currency="ITL">1000</o-dd:amount>
</o-dd:payment>
</o-dd:peruse>
</o-ex:requirement>
</o-dd:play>
<o-dd:play>
<o-ex:constraint>
<o-dd:quality o-dd:type="mpeg7:resolution">
<o-ex:constraint>
<o-dd:range o-dd:max="90"/>
</o-ex:constraint>
</o-dd:quality>
</o-ex:constraint>
<o-ex:requirement>
<o-dd:peruse>
<o-dd:payment>
<o-dd:amount o-dd:currency="ITL">5000</o-dd:amount>
</o-dd:payment>
</o-dd:peruse>
</o-ex:requirement>
</o-dd:play>
</o-ex:permission>
</o-ex:rights>
An online lecture (software application) is offered (execute) for a per-use fee of $AUD2.00 which must be constrained to a certain network. Additionally, for a fee of $AUD1000.00 the lecture can be lent to (up to) 100 individuals.
The rights holder receives 50% of the execute fee and 25% of the lend fee. (Note the linking between the party entity and the permission entities.)
The XML encoding of this scenario in ODRL is shown below:
<?xml version="1.0" encoding="UTF-8"?>
<o-ex:rights xmlns:o-ex="http://odrl.net/0.9/ODRL-EX"
xmlns:o-dd="http://odrl.net/0.9/ODRL-DD"
xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance"
xsi:schemaLocation="http://odrl.net/0.9/ODRL-DD http://odrl.net/0.9/ODRL-DD-09.xsd
http://odrl.net/0.9/ODRL-EX http://odrl.net/0.9/ODRL-EX-09.xsd">
<o-ex:asset>
<o-ex:context>
<o-dd:uid o-dd:idscheme="DOI">10.9999999/learnobject/uni/aa/7373722</o-dd:uid>
<o-dd:name>XML: The Lecture</o-dd:name>
</o-ex:context>
</o-ex:asset>
<o-ex:rightsholder>
<o-ex:party>
<o-ex:context>
<o-dd:uid o-dd:idscheme="X500">c=AU;o=UniA;cn=Prof Bean</o-dd:uid>
</o-ex:context>
<o-ex:container o-ex:type="and">
<o-dd:percentage>50</o-dd:percentage>
<o-ex:permission o-ex:idref="p001"/>
</o-ex:container>
<o-ex:container o-ex:type="and">
<o-dd:percentage>25</o-dd:percentage>
<o-ex:permission o-ex:idref="p002"/>
</o-ex:container>
</o-ex:party>
</o-ex:rightsholder>
<o-ex:permission o-ex:id="p001">
<o-dd:execute>
<o-ex:constraint>
<o-dd:network/>
</o-ex:constraint>
<o-ex:requirement>
<o-dd:peruse>
<o-dd:payment>
<o-dd:amount o-dd:currency="AUD">2.00</o-dd:amount>
</o-dd:payment>
</o-dd:peruse>
</o-ex:requirement>
</o-dd:execute>
</o-ex:permission>
<o-ex:permission o-ex:id="p002">
<o-dd:lend>
<o-ex:constraint>
<o-dd:individual>
<o-ex:constraint>
<o-dd:count o-dd:start="1" o-dd:end="100"/>
</o-ex:constraint>
</o-dd:individual>
</o-ex:constraint>
<o-ex:requirement>
<o-dd:prepay>
<o-dd:payment>
<o-dd:amount o-dd:currency="AUD">1000.00</o-dd:amount>
</o-dd:payment>
</o-dd:prepay>
</o-ex:requirement>
</o-dd:lend>
</o-ex:permission>
</o-ex:rights>
To be completed in the next revision (Version 0.95).
ODRL defines both the core structure of the expression language and a set of core elements as part of the ODRL data dictionary. Additional data dictionaries can be defined and used within the ODRL framework
[AAP] Digital Rights Management for Ebooks: Publisher Requirements, Version 1.0, Association of American Publishers, 2000.
[DCMI] Dublin Core Metadata Initiative
[DIG35] DIG35 Specification - Metadata for Digital Images - Version 1.0, August 30, 2000
[DOI] Digital Object Identifier
[EBX] Electronic Book Exchange
[FPI] Information Technology SGML Support Facilities Registration Procedures for Public Text Owner Identifiers, ISO/IEC 9070, Second Edition, International Organization for Standardization, April, 1991.
[GUID] Globally Unique Identifier
[IFLA] Functional Requirements for Bibliographic Records
[IMS] IMS Global Learning Consortium
[INDECS] Interoperability of Data in Ecommerce Systems
[ISBN] International Standard Book Number
[ISTC] International Standard Textual Work Code
[ISO3166] Country Names and Code Elements
[ISO8601] ISO (International Organization for Standardization). Representations of dates and times
[MARC] MARC Code List for Relators
[MPEG] Moving Picture Experts Group (WG 4,7,21)
[PRISM] Publishing Requirements for Industry Standard Metadata, 2001
[RFC2119] Key words for use in RFCs to Indicate Requirement Levels
[URI] Uniform Resource Identifiers (URI): Generic Syntax
[VCARD] vCard MIME Directory Profile
[X500] Technical Overview of Directory Services Using the X.500 Protocol, 1992
[XML] Extensible Markup Language 1.0
[XML NAMESPACE] Namespaces in XML
[XML SCHEMA] XML Schema Part 1: Structures, Part 2: Datatypes
[ERICKSON] A Digital Object Approach to Interoperable Rights Management, John S Erickson, D-Lib Magazine, June 2001, Volume 7 Number 6
[HIGGS] Rights Management: Managing the Layers of Rights and Roles in the Knowledge Based Economy, Peter Higgs, 2000, IPR Systems Report.
[IANNELLA] Digital Rights Management (DRM) Architectures, Renato Iannella, D-Lib Magazine, June 2001, Volume 7 Number 6
The editors wish to acknowledge contributions and feedback to this document from:
The version 0.9 XML Namespace URI for the ODRL Expression Language is:
http://odrl.net/0.9/ODRL-EX
The actual location of the XML Schema is:
http://odrl.net/0.9/ODRL-EX-09.xsd
The XML Schema is documented at:
http://odrl.net/0.9/ODRL-EX-09-DOC/index.html
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema targetNamespace="http://odrl.net/0.9/ODRL-EX"
xmlns:o-ex="http://odrl.net/0.9/ODRL-EX"
xmlns:xsd="http://www.w3.org/2000/10/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="qualified" version="0.9">
<xsd:element name="rights" type="o-ex:rightsType"/>
<xsd:element name="party">
<xsd:complexType>
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:element ref="o-ex:context" minOccurs="0"/>
<xsd:element ref="o-ex:rightsHolderElement" minOccurs="0"/>
<xsd:element ref="o-ex:party" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element ref="o-ex:container" minOccurs="0" maxOccurs="unbounded"/>
</xsd:choice>
<xsd:attributeGroup ref="o-ex:IDGroup"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="permission">
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="o-ex:permissionType">
<xsd:attribute name="exclusive" type="xsd:boolean" use="optional"/>
<xsd:attribute name="narrow" type="xsd:boolean" use="optional"/>
<xsd:attributeGroup ref="o-ex:IDGroup"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
<xsd:element name="constraintElement" type="o-ex:constraintType" abstract="true"/>
<xsd:element name="requiremetElement" type="o-ex:requirementType" abstract="true"/>
<xsd:element name="rightsHolderElement" type="o-ex:rightsHolderType" abstract="true"/>
<xsd:element name="permissionElement" type="o-ex:permissionType" abstract="true"/>
<xsd:element name="contextElement" type="o-ex:contextType" abstract="true"/>
<xsd:element name="context">
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="o-ex:contextType">
<xsd:attributeGroup ref="o-ex:IDGroup"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
<xsd:complexType name="rightsType">
<xsd:choice maxOccurs="unbounded">
<xsd:element ref="o-ex:asset" maxOccurs="unbounded"/>
<xsd:element ref="o-ex:permission" maxOccurs="unbounded"/>
<xsd:element name="agreement" minOccurs="0" maxOccurs="unbounded">
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="o-ex:agreementType">
<xsd:attributeGroup ref="o-ex:IDGroup"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
<xsd:element name="rightsholder" minOccurs="0" maxOccurs="unbounded">
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="o-ex:rightsHolderType">
<xsd:attributeGroup ref="o-ex:IDGroup"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
<xsd:element ref="o-ex:context" minOccurs="0"/>
</xsd:choice>
</xsd:complexType>
<xsd:element name="container">
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="o-ex:containerType">
<xsd:attribute name="type" use="required" value="and">
<xsd:simpleType>
<xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="and"/>
<xsd:enumeration value="in-or"/>
<xsd:enumeration value="ex-or"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
<xsd:complexType name="containerType">
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:element ref="o-ex:container" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element ref="o-ex:permission" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element ref="o-ex:permissionElement" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element ref="o-ex:constraintElement" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element ref="o-ex:requiremetElement" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element ref="o-ex:rightsHolderElement" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element ref="o-ex:constraint" minOccurs="0" maxOccurs="unbounded"/>
</xsd:choice>
</xsd:complexType>
<xsd:complexType name="contextType">
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:element ref="o-ex:contextElement" minOccurs="0" maxOccurs="unbounded"/>
</xsd:choice>
</xsd:complexType>
<xsd:complexType name="permissionType">
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:element ref="o-ex:permissionElement" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element ref="o-ex:container" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="requirement" minOccurs="0" maxOccurs="unbounded">
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="o-ex:requirementType">
<xsd:attributeGroup ref="o-ex:IDGroup"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
<xsd:element ref="o-ex:constraint" minOccurs="0" maxOccurs="unbounded"/>
</xsd:choice>
</xsd:complexType>
<xsd:complexType name="requirementType">
<xsd:sequence minOccurs="0" maxOccurs="unbounded">
<xsd:element ref="o-ex:requiremetElement" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element ref="o-ex:container" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="constraintType">
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:element ref="o-ex:constraintElement" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element ref="o-ex:container" minOccurs="0" maxOccurs="unbounded"/>
</xsd:choice>
</xsd:complexType>
<xsd:complexType name="assetType">
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:element ref="o-ex:context"/>
</xsd:choice>
</xsd:complexType>
<xsd:complexType name="rightsHolderType">
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:element ref="o-ex:context" minOccurs="0"/>
<xsd:element ref="o-ex:party" maxOccurs="unbounded"/>
<xsd:element ref="o-ex:asset" minOccurs="0"/>
</xsd:choice>
</xsd:complexType>
<xsd:complexType name="agreementType">
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:element ref="o-ex:party" maxOccurs="unbounded"/>
<xsd:element ref="o-ex:asset" maxOccurs="unbounded"/>
<xsd:element ref="o-ex:permission" maxOccurs="unbounded"/>
<xsd:element ref="o-ex:context" minOccurs="0"/>
</xsd:choice>
</xsd:complexType>
<xsd:element name="asset">
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="o-ex:assetType">
<xsd:attributeGroup ref="o-ex:IDGroup"/>
<xsd:attribute name="type">
<xsd:simpleType>
<xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="work"/>
<xsd:enumeration value="expression"/>
<xsd:enumeration value="manifestation"/>
<xsd:enumeration value="item"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
<xsd:attributeGroup name="IDGroup">
<xsd:attribute name="id" type="xsd:ID"/>
<xsd:attribute name="idref" type="xsd:IDREF"/>
</xsd:attributeGroup>
<xsd:element name="constraint">
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="o-ex:constraintType">
<xsd:attributeGroup ref="o-ex:IDGroup"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
</xsd:schema>
The version 0.9 XML Namespace URI for the ODRL Data Dictionary is:
http://odrl.net/0.9/ODRL-DD
The actual location of the XML Schema is:
http://odrl.net/0.9/ODRL-DD-09.xsd
The XML Schema is documented at:
http://odrl.net/0.9/ODRL-DD-09-DOC/index.html
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema targetNamespace="http://odrl.net/0.9/ODRL-DD"
xmlns:xsd="http://www.w3.org/2000/10/XMLSchema"
xmlns:o-dd="http://odrl.net/0.9/ODRL-DD"
xmlns:o-ex="http://odrl.net/0.9/ODRL-EX"
elementFormDefault="qualified" attributeFormDefault="qualified" version="0.9">
<xsd:import namespace="http://odrl.net/0.9/ODRL-EX"
schemaLocation="http://odrl.net/0.9/ODRL-EX-09.xsd"/>
<xsd:element name="payment">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="amount">
<xsd:complexType>
<xsd:simpleContent>
<xsd:extension base="xsd:decimal">
<xsd:attribute name="currency" type="xsd:NMTOKEN" use="required"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
</xsd:element>
<xsd:element name="taxpercent" minOccurs="0">
<xsd:complexType>
<xsd:simpleContent>
<xsd:extension base="xsd:decimal">
<xsd:attribute name="code" type="xsd:NMTOKEN" use="required"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="display" substitutionGroup="o-ex:permissionElement"/>
<xsd:element name="print" substitutionGroup="o-ex:permissionElement"/>
<xsd:element name="play" substitutionGroup="o-ex:permissionElement"/>
<xsd:element name="execute" substitutionGroup="o-ex:permissionElement"/>
<xsd:element name="sell" substitutionGroup="o-ex:permissionElement"/>
<xsd:element name="lend" substitutionGroup="o-ex:permissionElement"/>
<xsd:element name="give" substitutionGroup="o-ex:permissionElement"/>
<xsd:element name="lease" substitutionGroup="o-ex:permissionElement"/>
<xsd:element name="modify" substitutionGroup="o-ex:permissionElement"/>
<xsd:element name="copy" substitutionGroup="o-ex:permissionElement"/>
<xsd:element name="annotate" substitutionGroup="o-ex:permissionElement"/>
<xsd:element name="prepay" type="o-dd:feeType" substitutionGroup="o-ex:requiremetElement"/>
<xsd:element name="postpay" type="o-dd:feeType" substitutionGroup="o-ex:requiremetElement"/>
<xsd:element name="peruse" type="o-dd:feeType" substitutionGroup="o-ex:requiremetElement"/>
<xsd:complexType name="feeType">
<xsd:sequence>
<xsd:element ref="o-dd:payment"/>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="fixedamount" type="o-dd:feeType" substitutionGroup="o-ex:rightsHolderElement"/>
<xsd:element name="percentage" substitutionGroup="o-ex:rightsHolderElement">
<xsd:simpleType>
<xsd:restriction base="xsd:decimal">
<xsd:minInclusive value="0"/>
<xsd:maxInclusive value="100"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
<xsd:element name="uid" substitutionGroup="o-ex:contextElement">
<xsd:complexType>
<xsd:simpleContent>
<xsd:extension base="xsd:string">
<xsd:attribute name="idscheme" use="required">
<xsd:simpleType>
<xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="URI"/>
<xsd:enumeration value="DOI"/>
<xsd:enumeration value="X500"/>
<xsd:enumeration value="ISBN"/>
<xsd:enumeration value="ISTC"/>
<xsd:enumeration value="ISO3166"/>
<xsd:enumeration value="FPI"/>
<xsd:enumeration value="GUID"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
</xsd:element>
<xsd:element name="name" type="xsd:string" substitutionGroup="o-ex:contextElement"/>
<xsd:element name="role" substitutionGroup="o-ex:contextElement">
<xsd:complexType>
<xsd:simpleContent>
<xsd:extension base="xsd:string">
<xsd:attribute name="idscheme" use="optional">
<xsd:simpleType>
<xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="MARC"/>
<xsd:enumeration value="ONIX"/>
<xsd:enumeration value="MPEG7"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
</xsd:element>
<xsd:element name="remark" type="xsd:string" substitutionGroup="o-ex:contextElement"/>
<xsd:element name="dateEvent" substitutionGroup="o-ex:contextElement">
<xsd:complexType>
<xsd:attribute name="date" type="xsd:date"/>
<xsd:attribute name="event" type="xsd:string"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="location" type="xsd:string" substitutionGroup="o-ex:contextElement"/>
<xsd:element name="reference" type="xsd:uriReference" substitutionGroup="o-ex:contextElement"/>
<xsd:element name="individual" substitutionGroup="o-ex:constraintElement">
<xsd:complexType>
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:element ref="o-ex:constraint"/>
<xsd:element ref="o-ex:context" minOccurs="0"/>
</xsd:choice>
</xsd:complexType>
</xsd:element>
<xsd:element name="group" substitutionGroup="o-ex:constraintElement">
<xsd:complexType>
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:element ref="o-ex:constraint"/>
<xsd:element ref="o-ex:context"/>
</xsd:choice>
</xsd:complexType>
</xsd:element>
<xsd:element name="cpu" substitutionGroup="o-ex:constraintElement">
<xsd:complexType>
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:element ref="o-ex:constraint"/>
<xsd:element ref="o-ex:context"/>
</xsd:choice>
</xsd:complexType>
</xsd:element>
<xsd:element name="network" substitutionGroup="o-ex:constraintElement">
<xsd:complexType>
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:element ref="o-ex:constraint"/>
<xsd:element ref="o-ex:context"/>
</xsd:choice>
</xsd:complexType>
</xsd:element>
<xsd:element name="screen" substitutionGroup="o-ex:constraintElement">
<xsd:complexType>
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:element ref="o-ex:constraint"/>
<xsd:element ref="o-ex:context"/>
</xsd:choice>
</xsd:complexType>
</xsd:element>
<xsd:element name="storage" substitutionGroup="o-ex:constraintElement">
<xsd:complexType>
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:element ref="o-ex:constraint"/>
<xsd:element ref="o-ex:context"/>
</xsd:choice>
</xsd:complexType>
</xsd:element>
<xsd:element name="memory" substitutionGroup="o-ex:constraintElement">
<xsd:complexType>
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:element ref="o-ex:constraint"/>
<xsd:element ref="o-ex:context"/>
</xsd:choice>
</xsd:complexType>
</xsd:element>
<xsd:element name="printer" substitutionGroup="o-ex:constraintElement">
<xsd:complexType>
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:element ref="o-ex:constraint"/>
<xsd:element ref="o-ex:context"/>
</xsd:choice>
</xsd:complexType>
</xsd:element>
<xsd:element name="software" substitutionGroup="o-ex:constraintElement">
<xsd:complexType>
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:element ref="o-ex:constraint"/>
<xsd:element ref="o-ex:context"/>
</xsd:choice>
</xsd:complexType>
</xsd:element>
<xsd:element name="count" substitutionGroup="o-ex:constraintElement">
<xsd:complexType>
<xsd:attribute name="start" use="optional">
<xsd:simpleType>
<xsd:restriction base="xsd:decimal">
<xsd:minInclusive value="0"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
<xsd:attribute name="end" use="optional">
<xsd:simpleType>
<xsd:restriction base="xsd:decimal">
<xsd:minInclusive value="0"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
</xsd:complexType>
</xsd:element>
<xsd:element name="range" substitutionGroup="o-ex:constraintElement">
<xsd:complexType>
<xsd:attribute name="min" type="xsd:decimal" use="optional"/>
<xsd:attribute name="max" type="xsd:decimal" use="optional"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="datetime" substitutionGroup="o-ex:constraintElement">
<xsd:complexType>
<xsd:attribute name="start" type="xsd:date" use="optional"/>
<xsd:attribute name="end" type="xsd:date" use="optional"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="accumulated" type="xsd:duration" substitutionGroup="o-ex:constraintElement"/>
<xsd:element name="interval" type="xsd:duration" substitutionGroup="o-ex:constraintElement"/>
<xsd:element name="country" substitutionGroup="o-ex:constraintElement">
<xsd:complexType>
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:element ref="o-ex:constraint"/>
<xsd:element ref="o-ex:context"/>
</xsd:choice>
</xsd:complexType>
</xsd:element>
<xsd:element name="quality" substitutionGroup="o-ex:constraintElement">
<xsd:complexType>
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:element ref="o-ex:constraint"/>
</xsd:choice>
<xsd:attribute name="type" type="xsd:QName"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="format" substitutionGroup="o-ex:constraintElement">
<xsd:complexType>
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:element ref="o-ex:constraint"/>
</xsd:choice>
<xsd:attribute name="type" type="xsd:QName"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="unit" substitutionGroup="o-ex:constraintElement">
<xsd:complexType>
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:element ref="o-ex:constraint"/>
</xsd:choice>
<xsd:attribute name="type" type="xsd:QName"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="recontext" substitutionGroup="o-ex:constraintElement">
<xsd:complexType>
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:element ref="o-ex:constraint"/>
</xsd:choice>
<xsd:attribute name="value" type="xsd:boolean" use="required"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="watermark" substitutionGroup="o-ex:constraintElement">
<xsd:complexType>
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:element ref="o-ex:context"/>
<xsd:element ref="o-ex:constraint"/>
</xsd:choice>
</xsd:complexType>
</xsd:element>
</xsd:schema>