Abstract

The ODRL permissions and obligations expression language provides a flexible and interoperable information model, vocabulary, and encoding mechanisms for describing statements about digital content usage. The ODRL Information Model describes the underlying concepts, entities, and relationships that form the foundational basis for the semantics of the ODRL statements .

Status of This Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This is a work in progress. No section should be considered final, and the absence of any content does not imply that such content is out of scope, or may not appear in the future. If you feel something should be covered, please tell us.

This document was published by the Permissions & Obligations Expression Working Group as a First Public Working Draft. This document is intended to become a W3C Recommendation. If you wish to make comments regarding this document, please send them to public-poe-comments@w3.org (subscribe, archives). All comments are welcome.

Publication as a First Public Working Draft does not imply endorsement by the W3C Membership. 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.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

This document is governed by the 1 September 2015 W3C Process Document.

1. Introduction

This section is non-normative.

The ODRL Information Model defines the underlying semantic model for permissions and obligations statements describing digital content usage. The information model covers the core concepts, entities and relationships that provide the foundational model for content usage statements.

The ODRL Information Model is formally specified using UML notation [uml].

2. Relationship to the W3C ODRL Community Group Reports

This section is non-normative.

The basis for the deliverables for the Permissions & Obligations Expression Working Group are the reports created by the W3C ODRL Community Group. The ODRL Community Group has developed a family of specifications to support innovative expression of digital asset usage for the publication, distribution and consumption of content services. The final outputs of the ODRL Community Group were the ODRL Version 2.1 specifications that were a major update for ODRL and superseded the original ODRL Version 1.1 [odrl] (published as a W3C NOTE)

The following documents are part of the ODRL Community Group report series:

The ODRL Information Model was derived from the ODRL V2.1 Core Model Community Group report. Details of the differences between the W3C Working Group deliverables and the ODRL Community Group Reports are maintained in the Appendix. All new ODRL implementations are expected to use the deliverables of the Permissions & Obligations Expression Working Group.

3. Conformance

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words MAY, MUST, OPTIONAL, and REQUIRED are to be interpreted as described in [RFC2119].

4. Information Model

The basic context of an ODRL Policy is that only an explicitly permitted use may be executed. Any use not explicitly permitted is prohibited by default. Based on that context, an ODRL Policy must contain at least one Permission and may contain Prohibitions. An ODRL Policy only permits the action explicitly specified in a Permission and all other actions are implicitly prohibited. An action defined in a Prohibition should only refine (or directly relate to) the semantics of an action defined in one of the Permissions in the ODRL Policy.

The above says that "an ODRL Policy MUST contain at least one Permission" but the UML model shows 0..*

For example, an ODRL Policy that has the action “present” Permission and may also have the action “print” Prohibition (as these actions are related hierarchically in the ODRL Vocabulary).

Note that ODRL Profiles can be developed and used to refine the basic context of an ODRL Policy. Hence, the application of an ODRL Profile must be understood by the consuming community and systems.

The figure below shows the ODRL Information Model. The Policy is the central entity that holds an ODRL policy together.

ODRL Information Model
Fig. 1 ODRL Information Model

A Permission allows a particular Action to be executed on a related Asset, e.g. “play the audio file abc.mp3”. A Constraint like “at most 10 times” might be added to specify the Permission more precisely. The Party that grants this Permission is linked to it with the Role assigner, the Party that is granted the Permission is linked to it with the Role assignee, e.g. “assigner VirtualMusicShop grants the Permission to assignee Alice”. Additionally, a Permission MAY be linked to Duty entities.

Similar to Permissions, a Duty states that a certain Action MAY be executed by the Party with the Role assignee for the Permission to be valid, e.g. “Alice must pay 5 EUR in order to get the Permission to play abc.mp3″.

Need to clarify that Duties MUST be performed but at what point in time is not specified (by default).

The Prohibition entity is used in the same way as Permission, with the two differences that it does not refer to Duties and (obviously) that it forbids the Action, e.g. “Alice is forbidden to use abc.mp3 commercially”.

Need to clarify that Prohibitions cannot have Duties.

The following sections describes each entity of the Information Model in greater detail.

4.1 Policy

The Policy entity is the top-level entity and contains the following attributes:

The uid attribute MUST be a unique identifier.

The range of values for the Policy entity’s type attribute will be described in the ODRL Vocabulary document or in community profiles. This value MAY also impose further constraints on the Information Model, such as are exemplified in the Scenarios for types Offer and Agreement. It is important that the type attribute be clearly understood in policy expressions as the semantics MAY impose restrictions on the expression language constructs such as cardinalities between entities.

Conflict is not only used for resolving merge issues but also between perms/prohibits in the same policy.

The conflict attribute is used to resolve conflicts arising from the merging of policies, specifically when there are conflicting Actions in the Permissions and Prohibitions. If present, the conflict attribute MUST take one of the following values:

If the conflict attribute is not explicitly set, its default value will be used instead. The default value of the conflict attribute is invalid.

Need to clarify conflicting values of the conflict attribute. That is, one policy says perm and the other prohibit.

The undefined attribute is used to indicate how to support Actions that are not part of any profile in the policy expression system. If present, the undefined attribute MUST take one of
the following values:

In the support case, even though the Action is unknown, the policy still is valid and the consuming parties or system of the policy MUST be made aware of the unknown Action. This MAY be via a user interface that displays the unknown Action for human readability.

In the ignore case, even though the Action is unknown, the policy still is valid and the consuming parties or system of the policy MAY be made aware of the unknown Action.

In the invalid case with the unknown Action, the policy is invalid and the consuming parties or system of the policy MUST be made aware of this.

If the undefined attribute is not explicitly set, its default value will be used instead. The default value of the undefined attribute is invalid.

Other attributes MAY be added to the Policy entity to support additional functions and requirements. Typically, these will be from different community vocabularies. For example, to indicate the issued date or valid dates of the Policy entity, use of the Dublin Core Metadata Terms would be recommended.

4.1.1 Inheritance

We need to make clear exactly what gets inherited and what gets overriden (if anything)

The inheritAllowed attribute in the Policy entity is used to indicate if the Policy expression can be used in any inheritance relationship. If present, the value of the inheritAllowed attribute MUST take one of the following values:

  • true: the Policy expression can be used for inheritance
  • false: the Policy expression can not be used for inheritance

If the inheritAllowed attribute is not explicitly set, its default value will be used instead. The default value of the inherit attribute is true.

Only if the inheritAllowed attribute has the value true can the inheritFrom and inheritRelation attributes be specified.

The inheritFrom attribute in the (child) Policy will uniquely identify (via a UID) the (parent) Policy from which the inheritance will be performed.

The inheritRelation attribute in the (child) Policy will uniquely identify (via a UID) the type of inheritance from the (parent) Policy. For example, this may indicate the business scenario, such as subscription, or prior arrangements between the parties (that are not machine representable). Such terms MAY be defined in the ODRL Vocabulary or Community Profiles. For example, an Assigner and Assignee may have a historical arrangement related to the specific use of content they make available to each other. The business model (identified with a URI) is used in the inheritRelation attribute in their subsequent ODRL policies they exchange. This will require the ODRL policy to be interpreted with the additional information identified by the URI. For example, this may include additional permission actions or constraints (etc) that is documented in their business model arrangement.

Both the inheritFrom and inheritRelation attribute MAY be used independently.

The following restrictions apply when using inheritance:

  • Single inheritance is only supported. (One Parent Policy to one or more Child Policy entities. No Child Policy can inherit from two or more Parent Policy entities.)
  • Inheritance can be to any depth. (Multiple levels of Children Policy entities.)
  • Inheritance cannot be circular.
  • The Child Policy MUST override the Parent Policy. i.e.: If the same Action appears in the Parent, then it is replaced by the Child version, otherwise the Parent Actions are added to the Child’s Actions.
  • No state information is transferred from the policy in the Parent Policy to the Child Policy

4.1.2 Profile

The profile attribute in the Policy entity is used to indicate the identifier (URI) of the ODRL Profile for which the policy expression conforms to. This attribute is OPTIONAL, but if the attribute appears, then any consuming system MUST understand the identified ODRL Profile – and all the rules from the Profile MUST apply to the policy expression. If multiple ODRL Profiles are required, then it is recommended that a new identifier be created to identify the combination of Profiles (and document the combined Profiles).

Since the ODRL Vocabulary represents broad needs for policy expressibility, different communities will require less or more concepts from the Information Model and terms from the ODRL Vocabulary. Community profiles of the ODRL model are expected to be developed that adequately document these requirements in respect to the Information Model and Vocabulary. Some requirements for communities developing ODRL Profiles include:

  • Document any additions to the Information Model
  • Document any aspects of the Information Model that will have different default values or interpretations
  • Document which aspects of the Information Model are not being used (deprecated)
  • Document new Vocabulary terms
  • Document deprecated Vocabulary terms
  • Declare the ODRL Profile identifier (URI)
  • Declare your communities namespace URI (see the various Encoding specifications)
  • Share the Community ODRL Profile with the W3C ODRL Community Group for feedback and comments

It is recommended that the ODRL Profile URI be the same as the Namespace URI, but this is not mandatory.

4.2 Asset

The Asset entity is the subject of an ODRL policy expression that permissions and prohibitions are applied to. The Asset entity can be any form of identifiable resource, such as data/information, content/media, applications, or services. Furthermore, it can be used to represent other Asset entities that are needed to undertake the Policy expression, such as with the Duty entity. The Asset entity is referred to by the Permission and/or Prohibition entities, and also by the Duty entity.

The Asset entity contains the following attribute:

The identification of the Asset entity is a key foundation of the ODRL Policy language. However, there are some use cases where the ODRL Policy expression MAY be embedded inside the target Asset. In these cases, it MAY be more appropriate to provide, or infer, a link to the Asset entity (as the complete Asset uid may not be known at the time) through the local context. Use of such inference and context MUST be documented in the relevant ODRL community Profile.

Since ODRL policies could deal with any kind of asset, the ODRL Information Model does not provide additional metadata to describe Asset entities of particular media types. It is recommended to use already existing metadata standards, such as Dublin Core Metadata Terms that are appropriate to the Asset type or purpose.

The Relation entity is used to associate the Asset entity with the relevant Permission, Prohibition, and Duty entities

4.2.1 Relation

The Relation entity is an association class and can be used to link to an Asset from either Permission, Duty or Prohibition, indicating how the Asset MAY be utilised in respect to the entity that links to it.

The Relation entity contains the following attribute:

  • relation: indicates the relationship of the Asset to the linked entity (REQUIRED)

The default value for the relation attribute is target which indicates that the Asset is the primary object to which the Permission, Duty or Prohibition actions apply.

Note

Target is formally defined in the ODRL Vocabulary

Other values for the Relation entity MAY be defined in the ODRL Vocabulary and community Profiles.

4.3 Party

Need to define Party more generically, not based on role

The Party entity is the object of an ODRL policy that performs (or not performs) actions or has a role in a Duty. The Party entity can be any form of identifiable entity, such as a person, group of people, organization, or agent. An agent is a person or thing that takes an active role or produces a specified effect.

The Party entity contains the following attribute:

The ODRL Information Model does not provide additional metadata for the Party element. It is recommended to use already existing metadata standards, such as vCard [RFC6350], that are appropriate to the Party type or purpose.

The Role entity is used to associate the Party entity with the relevant Permission, Prohibition, and Duty entities.

4.3.1 Role

The Role entity is an association class and can be used to link to a Party from either Permission, Duty or Prohibition, indicating which role the Party takes with respect to the entity that links to it.

The Role entity contains the following attributes:

  • function: the functional role the Party takes (REQUIRED)

The function attribute MUST support the following values:

  • assigner: indicates that the Party has assigned the associated Permission, Duty, or Prohibition. In other words, the Party grants a Permission or requires a Duty to be performed or states a Prohibition.
  • assignee: indicates that the Party has been assigned the associated entity, i.e. they are granted a Permission or required to perform a Duty or have to adhere to a Prohibition.
Note

Assignee and Asignee are formally defined in the ODRL Vocabulary

Other values for the function attribute MAY be defined in the ODRL Vocabulary and community Profiles.

The scope attribute MAY be used to indicate the context under which to interpret the Party entity. If present, the scope attribute MAY take one of the following values:

  • individual: indicates that the Party entity is a single individual. The linked Permission, Duty or Prohibition is applicable for that individual only.
  • group: indicates that the Party entity represents a group. The group consisting of many individual members. The linked Permission, Duty or Prohibition is applicable for each member of that group. For example, a (constrained) Permission to play a movie 5 times is valid for each Party member or the Duty to pay 3 EUR has to be fulfilled by each Party member.

Other values for the scope attribute MAY be defined in the ODRL Vocabulary and community Profiles.

4.4 Permission

The Permission entity indicates the Actions that the assignee is permitted to perform on the associated Asset. In other words, what the assigner (supplier) has granted to the assignee (consumer).

An ODRL policy expression MAY contain at least one Permission. It is important to verify the semantics of the Policy type attribute as this MAY indicate additional constraints on the Policy expression structure.

If several Permission entities are referred to by a Policy, then all of them are valid.

The Permission entity has the following relations:

4.5 Duty

The Duty entity indicates a requirement that MUST be fulfilled in return for being entitled to the referring Permission entity. While implying different semantics, the Duty entity is similar to Permission in that it is an Action that can be undertaken. If a Permission refers to several Duty entities, all of them have to be fulfilled for the Permission to become valid. If several Permission entities refer to one Duty, then the Duty only has to be fulfilled once for all the Permission entities to become valid.

The Duty entity contains the following attributes:

The Duty entity has the following relations:

A Duty entity does not, by itself, specify any conditions on when the Duty Action MUST or MAY be performed, such as to compensate before viewing the movie. Such conditions MAY be expressed through Constraint entities.

Need to clarify that Duties must be performed but when is not specified by default.

To support cases where the Duty MAY be performed for each Action on an Asset (for example, pay-per-view) then the use of a Constraint (e.g. count=1) on the Permission (e.g. play) can express these semantics.

4.6 Prohibition

The Prohibition entity indicates the Actions that the assignee is prohibited to perform on the related Asset. Prohibitions are issued by the supplier of the Asset – the Party with the Role assigner. If several Prohibition entities are referred to by a Policy, all of them must be satisfied.

The Prohibition entity has the following relations:

4.7 Action

The Action entity (when related to a Permission entity) indicates the operations (e.g. play, copy, etc.) that the assignee (i.e. the consumer) is permitted to perform on the related Asset linked to by Permission. When related to a Prohibition, the Action entity indicates the operations that the assignee (again the consumer) is prohibited to perform on the Asset linked to by Prohibition. Analogously, when related to a Duty, it indicates the operation to be performed.

Action contains the following attribute:

As its value, the name attribute MAY take one of a set of Action names which are formally defined in profiles. The ODRL Vocabulary defines a standard set of potential terms that MAY be used. Communities will develop new (or extend existing) profiles to capture additional and refined semantics.

4.8 Constraint

The Constraint entity indicates limits and restrictions to the Permission, the Prohibition and the Duty entity. Constraints 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).

If multiple Constraint entities are linked to the same Permission, Prohibition, or Duty entity, then all of the Constraint entities MUST be satisfied. That is, all the Constraint entities are (boolean) anded. In the case where the same Constraint is repeated, then these MUST be represented as a single Constraint entity using an appropriate operator value (for example, isAnyOf).

The Constraint entity contains the following attributes:

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. The dataType indicates the type of the rightOperand, such as “decimal” or “datetime” and the unit indicates the unit value of the rightOperand, such as “EU dollars”.

When processing policy expressions, these Constraint names MAY 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 are defined in the ODRL Vocabulary or community profiles.

The status provides the current value of the Constraint variable (i.e. current value of name). This is useful in cases where the current status of Constraints needs to be captured and expressed in the ODRL Information Model.

5. Scenarios

This section is non-normative.

This section shows a number of policy expression scenarios. In these examples, the different policy expression types that are used are for illustrative purposes only and are not part of this normative specification. Also, the specific Action and Constraint names (etc.) used in these examples are for illustrative purposes only. Please note that formal policy expression types and other entities are defined in the ODRL Vocabulary specification, or in community profiles.

Note

Need to clarify if these Scenarios need to be udated.

5.1 Set

The following shows an instance of a set Policy. The Set shows a policy expression, stating that the Asset http//example.com/asset:9898 is the target of the Permission reproduce and the Prohibition to modify. No parties or other elements are involved. This set could be used, for example, as a template or an instant license.

An instance of a Set Policy
Fig. 2 An instance of a Set Policy

5.2 Offer

The following shows the instance of an offer Policy. The offer contains the music file http//example.com/music:4545 that is offered by the Party http//example.com/sony:10 with the Permissions to play and copy the file. The Permission copy is only granted once. The two Permissions are offered for a payment of AUD$0.50.

An instance of an Offer Policy
Fig. 3 An instance of an Offer Policy

5.3 Agreement

The following shows the instance of an agreement Policy. The agreement contains all entities shown in the offer scenario above. A new Party element http//example.com/billie:888 has been added. This Party accepted the previous offer and thus is now the buyer of the Permission play and copy, i.e. is now linked as assignee of the Permissions and Duty entities.

An instance of an Agreement Policy
Fig. 4 An instance of an Agreement Policy

5.4 Request

The following shows the instance of a request Policy. The Party http//example.com/guest:0589 has requested the Permission to display the target Asset http//example.com/news:0099.

An instance of an Request Policy
Fig. 5 An instance of an Request Policy

5.5 Ticket

The following shows the instance of a ticket Policy. The ticket expresses the play Permission for the target Asset http//example.com/game:4589. The Ticket is valid until the end of the year 2010. Any valid holder of this ticket may exercise this Permission.

An instance of an Ticket Policy
Fig. 6 An instance of an Ticket Policy

5.6 Offer and Next Policy

The following shows the instance of an offer Policy showing the nextPolicy structure. The party http//example.com/sony:99 assigns the Permission distribute directly to the potential buyer of the permission who will pay $EU1,000. The distribute Permission is also constrained to the country Italy. The potential assignee may then distribute the target Asset according to the nextPolicy target Asset linked directly from this Duty. In this case, the next Policy Asset stipulates that the potential assignee may only offer the display Permission to downstream consumers.

An instance of an Offer and Next Policy
Fig. 7 An instance of an Offer and Next Policy

5.7 Privacy

The following shows the instance of an privacy Policy.

The target Asset is Personal Data and the assignee is allowed to distribute the Asset only for the purpose of contacting the subject of the Personal Data. The purpose value is taken from the P3P privacy purpose vocabulary.

Additionally, the assigner (the Party who the personal data is about) has stipulated that the assignee must delete the Asset after a 30 day period (retention policy).

An instance of an Privacy Policy
Fig. 8 An instance of an Privacy Policy

5.8 Permission and Prohibition

The following shows the instance of an agreement Policy with both a Permission and a Prohibition. The party http//example.com/sony:10 assigns the Permission play to the Party http//example.com/billie:888 at the same time they are prohibited from utilising the target Asset as a mobile:ringtone. Additionally, in case of any conflict, the conflict attribute is set to perm indicating that the Permission entity will take precedence.

An instance of an Permission and Prohibition Policy
Fig. 9 An instance of an Permission and Prohibition Policy

5.9 Inheritance

The following shows the instance of a (child) Policy http//example.com/policy:9999 inheriting from another (parent) Policy http//example.com/policy:5531. The inheritFrom attribute of the (child) Policy has the same identifier as the (parent) Policy. In this inheritance example, the (parent) Policy allows the Party http//example.com/billie:888 to print the (parent’s) target Asset. The (child) Policy allows the Party http//example.com/class:IT01 (a group of people) to display the (child’s) target Asset. Since the (child) Policy also inherits from the (parent) Policy, then the Party http//example.com/class:IT01 can also print the (parent’s) target Asset.

Is this last statement true?

An instance of an Inheritance Policy
Fig. 10 An instance of an Inheritance Policy

5.10 Social Network

The following shows the instance of an agreement Policy for a Social Network scenario.

The target Asset are photos posted to a Social Network site and the assigner is the owner of the photos. The assignee is a Party group and represents the football network members on the social network, who are each allowed to display the photos.

An instance of an Social Network Policy
Fig. 11 An instance of an Social Network Policy

5.11 Multiple Assets

The following shows an instance of a set Policy utilising multiple Asset entities.

The index Permission is granted to the target Asset. As well, the x:collection Asset specifies which database the index outcome should be stored in.

An instance of an Multiple Assets Policy
Fig. 12 An instance of an Multiple Assets Policy

6. Experimental Features

This section is non-normative.

Note

Should this section be included in a W3C REC?

This section contains advanced ODRL features. Although not part of the normative specification, they provide an opportunity for communities to experiment with and provide feedback on experiences that may be included in future ODRL versions.

6.1 Extended Relations

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:

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 Actions The related party MAY NOT perform at least one of the Actions The related party MUST perform at least one of the Actions The related Permission/Prohibition/Duty is restricted by at least one of the Constraints
AND The related party MUST perform all of the Actions The related party MAY NOT perform all of the Actions The related party MUST perform all of the Actions The related Permission/Prohibition/Duty is restricted by all of the Constraints
XOR The related party MAY perform only one of the Actions The related party MAY NOT perform only one of the Actions The related party MUST perform only one of the Actions The related Permission/Prohibition/Duty is restricted by only one of the Constraints.

Note that Extended Relations are not needed to assign two or more Permissions to a Party entity. In this case simply use as many Assignee relations between Party and Permission as needed.

6.2 Abstract Policy Expression

As the Information Model diagram shows the key Permission, Prohibition and Duty entities are very similar since they have (more or less) the same relationships to the other entities. They core difference is in their semantics:

In an implementation that interprets ODRL, it may make sense to introduce a common superclass Rule, as shown in the (abbreviated) Model below.

Abstract Policy Expression
Fig. 13 Abstract Policy Expression

By implementing Permission, Prohibition and Duty as subclasses of Rule, the redundancy of having very similar, but separately developed classes in an application’s source code can be avoided. Furthermore, Rule makes it possible to easily extend the Information Model in Profiles by adding policy expressions (as subclasses of Rule) that are not possible by default.

Include Rule in the normative Information Model? Rule appears in the Ontology as an abstract class already

6.3 Remedies

In the ODRL Information Model, Duties are only directly related to Permissions, meaning that for a Permission to become effective, the related Duty should be performed. For some use cases though, it might be useful to attach a Duty to a Prohibition, meaning that if a Prohibition is violated, the Duty has to be performed as a kind of remedy or consequence for the violation.

Not only can a Prohibition have a Duty attached to it as a remedy, even Duties themselves may have remedies, e.g. “For the Permission to play audio file xyz to become effective, you have to perform the Duty ‘pay 2€’. If you don’t perform this Duty (even though you’ve played yxz), you have to remedy this by performing the Duty ‘pay 5€'”.

In order to distinguish between a Duty that has to be fulfilled as a requirement and one that has to be fulfilled as a remedy, different relation names are introduced as shown in the Figure below.

Remedy Model
Fig. 14 Remedy Model

The relation between Permission and Duty, which was unnamed before, is now named hasRequirement. This is needed not only to make the different semantics clearer, but also because a Duty can refer to yet another Duty as a requirement, e.g. “If you want to print this written article, you have the Duty to attach a particular image of the author, and if you do that, you have the Duty to attribute the image to the photographer”.

7. Privacy Considerations

This section is non-normative.

Note

An ODRL policy can be of type "Privacy".

Need to add this section for the W3C Horizontal Review on Privacy Considerations.

Need to address the W3C PING Privacy Questions

A. Acknowledgements

The POE Working Group gratefully acknowledges the contributions of the ODRL Community Group and the earlier ODRL Initiative. The output of the ODRL Community Group was fundamental to the current model.

In particular the editors would like to thank:

for their past editorial contributions.

B. Changes from the ODRL Community Group Reports

Significant technical changes in this specification from the ODRL Community Group's draft are:

C. References

C.1 Normative references

[RFC2119]
S. Bradner. IETF. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119
[uml]
Open Management Group. OMG. OMG Unified Modeling Language. 1 March 2015. Normative. URL: http://www.omg.org/spec/UML/

C.2 Informative references

[RFC6350]
S. Perreault. IETF. vCard Format Specification. August 2011. Proposed Standard. URL: https://tools.ietf.org/html/rfc6350
[odrl]
Renato Iannella. W3C. Open Digital Rights Language (ODRL) Version 1.1. 19 September 2002. W3C Note. URL: https://www.w3.org/TR/odrl
[odrl2-req]
Susanne Guth; Renato Iannella. ODRL Initiative. ODRL Version 2 Requirements. 13 February 2005. Working Draft. URL: https://www.w3.org/2012/09/odrl/archive/odrl.net/2.0/v2req.html
[odrl21-json]
Jonas Öberg; Stuart Myles; Lu Ai. W3C. ODRL Version 2.1 JSON Encoding. 5 March 2015. W3C Community Group Final Specification. URL: https://www.w3.org/community/odrl/json/2.1/
[odrl21-model]
Renato Iannella; Susanne Guth; Daniel Paehler; Andreas Kasten. W3C. ODRL Version 2.1 Core Model. 5 March 2015. W3C Community Group Final Specification. URL: https://www.w3.org/community/odrl/model/2.1/
[odrl21-onto]
Mo McRoberts; Víctor Rodríguez Doncel. W3C. ODRL Version 2.1 Ontology. 5 March 2015. W3C Community Group Final Specification. URL: https://www.w3.org/ns/odrl/2/ODRL21
[odrl21-vocab]
Renato Iannella; Michael Steidl; Susanne Guth. W3C. ODRL Version 2.1 Common Vocabulary. 5 March 2015. W3C Community Group Final Specification. URL: https://www.w3.org/community/odrl/vocab/2.1/
[odrl21-xml]
Renato Iannella. W3C. ODRL Version 2.1 XML Encoding. 5 March 2015. W3C Community Group Final Specification. URL: https://www.w3.org/community/odrl/xml/2.1/