This document includes a set of use cases and requirements, compiled by the Permissions & Obligations Expression (POE) Working Group, that motivate the expression of statements about digital content usage. All use cases provide realistic examples describing how people and organisations may (or want to be able to) specify statements about digital content usage. The requirements derived from these use cases will be used to guide the development of the POE WG recommendation deliverables for the Information Model, Vocabulary, and Encodings.

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 https://www.w3.org/TR/.

This is work in progress. The final version of this document planned to be published as a Working Group Note.

This document was published by the Permissions & Obligations Expression Working Group as a Working Draft. 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 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. The group does not expect this document to become a W3C Recommendation. 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. Organization of this Document

This document is organized as follows:

2. Use Cases

2.1 POE.UC.01: Permissions and obligations for language resources

Víctor Rodríguez on behalf of W3C Linked Data For Language Technology Community Group

Language resources (lexicons, dictionaries, machine translation, etc.) are collected in repositories. Publishers would like to express what is permitted and what it is not.

Language resources are highly valuable resources now being massively translated to Linked Data. See the diagram here: Linguistic Linked Data Cloud. Different Language Resource Catalogs exist, like the one of CLARIN, or the one of META-SHARE, LRMAP, Linghub, etc. These resources need to be browsed and queried, and the permissions information must be in a machine-readable form in order to facilitate search-by-permission and in order to allow the automated processing of permission expressions.

Related Requirements: POE.R.DM.01, POE.R.DM.07, POE.R.DM.08, POE.R.V.01, POE.R.V.02, POE.R.V.11, POE.R.V.12, POE.R.E.01, POE.R.R.04, POE.R.R.09

2.2 POE.UC.02: Conditional Access to Linked Data

Víctor Rodríguez and Nandana Mihindukulasooriya (UPM) on behalf of the ODRL Linked Data profile editors.

A publisher of Linked Data (or in general a RDF dataset) wants to selectively make available parts (e.g. named graphs) of a dataset. Availability depend on ODRL policies, the context and the ODRL Request and ODRL Ticket. For example, given a dataset, one might want to serve it under the following conditions: "Anybody can access named graph ex:graph1, but can only access ex:graph2 during 2016. Individual triples in ex:graph3 can be accessed at the price of 1 € cent."

Related Requirements: POE.R.DM.11, POE.R.V.09, POE.R.R.06

2.3 POE.UC.03: Published article with embargoed dataset

Phil Archer & Keith Jeffery on behalf of the VRE4EIC Project

Researchers are strongly encouraged (and now routinely required) to publish data supporting their scholarly published papers. Irrespective of the terms under which the paper is published (although usually open access), the data is generally expected to be made freely and openly available. However, this may happen after an embargo period. The purpose of the embargo period is to allow the researcher or research team creating the dataset to have a publication based on it published before colleagues can access the dataset and generate their own publications.

Related Requirements: POE.R.DM.06, POE.R.DM.09

2.4 POE.UC.04: Technical documents rules for business process regulatory compliance

Serena Villata (joint work with Guido Governatori) in the context of the MIREL Project

Technical documents describe how to handle and what are the functionalities of a certain product or process (e.g., telecommunication codes). They are intended to provide information about what can/cannot be done with the product or within a certain process. Given the huge dimension of this kind of legal texts and their diffusion in the companies, the advantages of returning a machine-readable representation of such texts would allow to have in this representation a kind of summary of the main constraints expressed in the documents, with invaluable time saving for every person that is expected to read the whole document before obtaining this information. A specific usage of such a kind of texts is that of manually extracting the set of obliged/prohibited/permitted actions in order to check whether certain business processes are compliant with the legal text they should refer to. Moreover, issues related to the merging of updated versions of the documents, with amendments with respect to the policies and duties expressed in the former versions.

Related Requirements: POE.R.DM.04, POE.R.R.01, POE.R.R.02, POE.R.R.03, POE.R.R.07

2.5 POE.UC.05: Determine an identifier representing the audience who can access a digital resource

Mo McRoberts, BBC

The Research & Education Space platform, developed jointly by the BBC and partners, indexes Linked Open Data describing media that is available both to the public, and specifically for those in formal education, primarily in the UK. Even within this latter group, there are a range of different licensing schemes and access mechanisms which are not mutually-exclusive. For queries against the index to return appropriate results for a user, we must track which schemes they (or their institution) is a member of and filter based upon these, which therefore translates into a requirement for the metadata being indexed to include information identifying which are applicable (we term these "audience URIs"). Note that this is not an access-control mechanism (this should be implemented and enforced at the media location), rather a means of ensuring that an optimal user experience is delivered.

Related Requirements: POE.R.DM.12

2.6 POE.UC.06: OpenPHACTS

Phil Archer for the Big Data Europe Project

OpenPHACTS integrates pharmacological data from a wide range of sources and provides an API through which different identifiers for the same thing can be reconciled, reducing barriers to drug discovery in industry, academia and for small businesses. Some data is open but not all. It may come with a variation of a Creative Commons License; some data is visible to all users, some to members, some only to the original data owner.

Rather than attempt to make assertions about what an end user can or cannot do with the data available through its API, OpenPHACTS is careful to simply make clear to its users where data came from and under what terms. It is then up to the end user to assess whether their intended use is, or is not, compliant with those terms.

Related Requirements: POE.R.R.05, POE.R.R.06

2.7 POE.UC.07: News Permissions and Restrictions

Stuart Myles

In the news industry, rights holders and editors need to establish the permissions and restrictions associated with content.

What Do Rights Holders Want?
In general, rights holders will require that a set of permissions, restrictions, and duties be obeyed for a defined set of content. And they can require additional restrictions or duties for individual items within the larger content set. Rights holders wish to restrict the use of their content by factors such as:
  • Geography (e.g. "No use in China")
  • Time (e.g. "No archive after 3 days")
  • Distribution channel (e.g. "No mobile")
They also want to enforce duties such as:
  • Payment (e.g. "You can use this photo online for EUR80")
  • Attribution (e.g. "Credit Kyoto News")
Often, rights holders need to constrain the use of their content in complex ways, i.e., with combined constraints (e.g, "No use in UK after 7 days"). Generally, rights holders want to be able to:
Create a bundle of permissions, restrictions and duties
The rights holder creates a set of permissions and restrictions with constraints, together with any duties that the editor must perform, in order to unlock the permissions. The set may be associated with one or more sets of content. Therefore the policy bundle must have a unique identifier.
Identify one or more items of content to be treated as a set
The rights holder defines one or more content items which are to be treated as a set. The set must have a unique identifier.
Bind a policy to a set of content
The rights holder asserts that a given set of content is governed by a given policy. Note that a given content item might be a member of more than one set of content. Therefore, a given content item may have more than one policy associated with it.
What Do Editors Want?
Ideally, not to worry about rights at all. Essentially, editors want to know the answer to the question "Can I use this content in this way?" and, if the answer is yes, "Are there any duties?". It is not unusual for editors to have access to content that they are not permitted to republish. Or that they can only republish in certain ways (e.g., only in print but not on a mobile app). Editors want to be able to:
Create a bundle of action and context"
An editor identifies a content use in context, meaning a particular action they propose to take with pieces of content (e.g. "print", "distribute", "archive") and any relevant context for that action (e.g. location="France"). The types of context for an action correspond to possible constraints which could apply to the use of a piece of content. The use is not tied to one particular piece of content. The use must have a unique identifier.
Determine whether a use is permitted for a particular content item
At the point where an Editor wishes to use a particular piece of content in a particular way, the policies must be evaluated to determine whether it is permitted and whether there are any duties that must be fulfilled. The possible results are therefore: "yes", "no" or "maybe".

Related Requirements: POE.R.DM.09, POE.R.R.06

2.8 POE.UC.08: Atomic Understanding of Common Licenses

Phil Archer

The European Data Portal (EDP) harvests and republishes metadata from across Europe. It therefore has to handle a wide variety of inputs, including a variety of licenses attached to datasets (and datasets with no license attached). In order to manage this, the EDP has examined each of the most commonly found licenses and derived a set of atomic permissions and obligations expressed in those licenses with the intention that users can assess whether or not a particular combination of datasets is permissible and, if so, under what conditions. Their work itself is available on the European Data Portal as Licence Assistant: European Data Portal Licence Compatibility Matrix.

Related Requirements: POE.R.V.15, POE.R.R.08

2.9 POE.UC.09: Base Product

Ben Whittam Smith on behalf of Thomson Reuters

A bundled data product, which is sometimes called a 'base product', brings together a set of permissions that can be separately bought into a policy [or package] that is sold for a single price - or provided for free. It is important that the pricing is set at the aggregate level.

Related Requirements: POE.R.DM.05

2.10 POE.UC.10: Pay-by-Use

Ben Whittam Smith on behalf of Thomson Reuters

Sometimes things are paid for on a per-usage basis. For instance a SaaS product might charge per account (or per seat), or a definition in legal treatise might be charged for every time it is printed or included in a PDF.

Related Requirements: POE.R.V.03

2.11 POE.UC.11: Third-Party Rights Management

Ben Whittam Smith on behalf of Thomson Reuters

There are some common obligations that must be transmitted if you are acting as an intermediary between the data owner and the data user. Often the owner and the user must sign a contract, the user must acknowledge the copyright of the owner, and the user must acknowledge some other documentation (like a 'Restriction On Distribution Statement').

Related Requirements: POE.R.V.08, POE.R.V.10

2.12 POE.UC.12: Tracing Permissions and Obligations through Aggregations and Derivations

Ben Whittam Smith on behalf of Thomson Reuters

Data sets are often combined (aggregation) and analysed to generate new data sets (derivation). Big data analytics generates extended workflows of such operations. What policies control each step of the process? For example, a synthetic instrument might be generated by following a simple rule: (equity price on NYSE - equity opening price on NYSE) * equity weighting on MSCI Technology Index)

Let's say we know the three policies that control equity prices on the New York Stock Exchange, their opening prices, and their index weighting. Then what is the policy that controls the resulting synthetic instrument?

Related Requirements: POE.R.R.01, POE.R.R.02, POE.R.R.05

2.13 POE.UC.13: Delegation

Ben Whittam Smith on behalf of Thomson Reuters

Assigners are often corporate entities. They may want to restrict the right to exercise the actions they 'own' to particular groups within their own organisation, or even to an individual. This doesn't feel like an rights assignment (as no rights are being assigned?) but a delegation.

Related Requirements: POE.R.V.01, POE.R.V.16

2.14 POE.UC.14: A Vote for Extended Relations

Ben Whittam Smith on behalf of Thomson Reuters

Extended relations are an experimental feature of ODRL 2.1. In many cases, they would be necessary for commercial purposes. For example, it might be the case that on the 15th of every month the user must report usage by providing a list of either Access IDs OR Physical IDs. Extended relations would be a way of enabling this.

Related Requirements: POE.R.DM.10

2.15 POE.UC.15: Real-time vs. Delayed Data

Ben Whittam Smith on behalf of Thomson Reuters

Permissions often vary depending on whether the data is used in real-time (expensive and restrictive) or after a specified delay (cheaper and less restrictive).

Related Requirements: POE.R.DM.06, POE.R.DM.09

2.16 POE.UC.16: Accessing Historical Data

Ben Whittam Smith on behalf of Thomson Reuters

Access to historical data is often specified by the access period (how long can you go back in history) and access interval (how often can you sample the history). So a permission might be for access to 7 years of historical data but only on a monthly basis.

Related Requirements: POE.R.DM.06

2.17 POE.UC.17: Asset in a set

James Birmingham on behalf of Digital Catapult

In order to manage a common offer which is applied to many assets, a one-to-many relationship is more preferable than a one-to-one. If the offer can target a set of assets, it must also be able to state that what is offered is n items from the set rather than the whole set.

Related Requirements: POE.R.DM.08, POE.R.V.12

2.18 POE.UC.18: Policy Assertion

Renato Iannella

A common use case is for a general policy statement to be asserted. This is simply a party stating what policy terms they believe they have. Either an assignee can assert what terms they have over an asset and/or an assigner can assert what terms they have over an asset. An assertion does not grant any of the statements. A policy assertion may state that a party is a general rights holder or other roles.

Related Requirements: POE.R.V.01, POE.R.V.16

2.19 POE.UC.19: Relative Time Constraints

Michael Steidl

Sometimes it's required to be able to constrain the applicability of policies according to a relative point in time, e.g.:

Related Requirements: POE.R.DM.06

2.20 POE.UC.20: External Declaration of Payment Amount

Víctor Rodríguez-Doncel

META-SHARE is an open and secure network of repositories for sharing and exchanging language data, tools, and related web services. As of July 2016, it accounted more than 2700 resources. These resources are described with small pieces of metadata according to their schema.

While maintainers of META-SHARE's 32 repositories can edit simple metadata records, they are usually not skilled enough to edit ODRL expressions. Hence they would like to be able to:

  1. Point to a license template (referred by a well-known URI), with a placeholder to for the price.
  2. Add a metadata record indicating the specific price of the resource.

Related Requirements: POE.R.DM.03

2.21 POE.UC.21: Specifying the Scope of Constraints

Víctor Rodríguez-Doncel

Depending on the use case, it's often necessary to specify constraints on properties of different kinds of entities (e.g., assets, parties or any other external entities). The exact subject for which those constraints must hold is currently not encodable in ODRL, but has to be inferred from the textual semantics of each of ODRL's 25 constraint terms; which not only leads to ambiguities in terms of interpreted semantics, but might also prove to be not capable of fully covering new usages of ODRL.

Related Requirements: POE.R.DM.02

2.22 POE.UC.22: Technical documents rules for business process regulatory compliance


Removed -> Duplicate of POE.UC.04

2.23 POE.UC.23: Deletions Must be Propagated

Brian Ulicny

Many data providers require that if a record or element of the data is deleted in the source, it must be deleted in any copy and/or aggregation of that data. For example, arrest records must be expunged in public datasets if they are expunged by a court. Twitter requires that deleted tweets not be used in datasets, and so on.

Related Requirements: POE.R.DM.09

2.24 POE.UC.24: Synchronization in a multilayer music description environment

Laboratorio di Informatica Musicale (LIM), Department of Computer Science, Universitá degli Studi di Milano

IEEE 1599 is an international XML-based standard that aims to comprehensively describe music content by supporting the representation of heterogeneous music aspects within a single XML document. Moreover, IEEE 1599 lets spatio-temporal relationships emerge among such materials, thanks to the identification of music events inside a common data structure known as the spine: in this way, events can be described in different layers (e.g., a chord's graphical aspect and its audio performance), as well as multiple times within a single layer (e.g., different music performances of the same events). Consequently, the IEEE 1599 multilayer environment presents two complementary synchronization modes: inter-layer and intra-layer synchronization. Coupling these two categories of synchronization makes it possible to design and implement frameworks that allow new kinds of interaction with media contents and novel music-experience models, as shown in the Music Box area of the EMIPIU web framework (see URL above). Recognizing music events and their synchronization can be seen as an additional intellectual achievement that on one side does not affect the already existing IP rights on media contents, but on the other side requires adequate protection. Consequently, it is desirable to consider a new permission which allows the producer to synchronize different media contents with respect to the other possibly existing permissions, restrictions and duties associated with media contents.

Related Requirements: POE.R.DM.08, POE.R.DM.12, POE.R.V.12

2.25 POE.UC.25: Magazine Media Permissions

Dianne Kennedy, Idealliance

In the Magazine Industry, magazine media companies need the ability to communicate the legal terms of usage permissions (known as licensing terms) that are associated with content (article text and rich media). Specifically:

Related Requirements: POE.R.DM.10, POE.R.V.11

2.26 POE.UC.26: Data Quality Policy

Antoine Isaac, Riccardo Albertoni

Example from the W3C Working Group Data on the Web Best Practices [dwbp], more specifically for the Data Quality Vocabulary [vocab-dqv]. This example specifies that the serviceProvider grants the permission to access the dataset and commits to serve the data with a certain quality, more concretely, 99% availability of a SPARQL endpoint associated with the dataset. This is expressed as a duty on the service provider with a constraint that is defined using a DQV metric (:sparqlEndpointUptime) that has to be greater than a certain value (e.g., 99). The odrl:assignee is the recipient of the policy statement and the odrl:assigner is the issuer of the policy statement. For discussion about this example see http://lists.w3.org/Archives/Public/public-odrl/2016Feb/0000.html

The expression of constraints in ODRL seems quite unfit with expressing general constraints on values in RDF graphs, as we would require here. However, ODRL can be easily extended, and is schedule to undergo refinement in the context of the W3C Permissions & Obligations Expression Working Group. In the future DQV implementers should investigate whether a general constraint expression language like the coming SHACL provides a more appropriate mechanism to be used on top of ODRL permissions and duties.

Related Requirements: POE.R.DM.09

2.27 POE.UC.27: Europeana/DPLA In Copyright - Educational Use Only

Antoine Isaac, Riccardo Albertoni

Data providers who are also the rights holders of the digital objects in question may want to allow reuse of their digital objects for educational purpose only.

Related Requirements: POE.R.DM.09

3. Requirements

This section lists the requirements arising from the use-cases catalogued in this document. Specific requirements that have been de-prioritized or rejected have been left in the document for completeness, but are shown as struck out.

3.1 POE.R.DM - Data Model

3.1.1 POE.R.DM.01: Define how constraints on a party can be expressed

A single option for applying a constraint to a party (of a specific role) should be defined.


3.1.2 POE.R.DM.02: Define target of a constraint

It should be possible to define the target of a constraint inside a Permission, Prohibition or Duty: e.g. a constraint of human age applies to the Assignee, a constraint of play time applies to Assets (of type audio or video), etc.


3.1.3 POE.R.DM.03: Introduce policy template

The current data model assumes a policy instance includes all required data explicitly. This should be extended to policy instances which include explicit data and variables for values which are defined by parameters provided by an access to this template.


3.1.4 POE.R.DM.04: Support versioning policies

The Data Model should be extended to support the versioning of a policy. In addition to the existing identifiers of a policy means for expressing a version of this policy should specified.


3.1.5 POE.R.DM.05: Set a global price for all permissions of a policy

It should be possible to define the price for duty/duties of payment for all permissions of a policy in a global way - while currently the payment duty must be defined for each permission individually.


3.1.6 POE.R.DM.06: Support relative time constraints

Extend the temporal constraints by setting a time reference, any period in the rightOperand refers to this point in time. For a relativeTimePeriod constraint the rightOperand has to provide a time period as value.


3.1.7 POE.R.DM.07: Define a category property for class Party

A property of the class Party should define the category of the Party.


3.1.8 POE.R.DM.08: Add a category property to Asset

A new property of the class Asset should define the category of the Asset.


3.1.9 POE.R.DM.09: Complex Constraints

Express complex constraints such as 'No use in UK after 7 days'.


3.1.10 POE.R.DM.10: Extended Relations

Being able to tie Permission, Prohibition, Duty, and Constraint entities together with an AND, OR or XOR relationship


3.1.11 POE.R.DM.11: Remedies


3.1.12 POE.R.DM.12: Grouping party entities

Being able to assign multiple individuals of type Party to a Group for which permissions/prohibitions/duties can be specified.


3.2 POE.R.V - Vocabulary

3.2.1 POE.R.V.01: Add rights holder terms to Roles of a Party Vocabulary


3.2.2 POE.R.V.02: Add term for redepositing to Duty Vocabulary


3.2.3 POE.R.V.03: Add concept of 'unit-of-count' to Duty Constraint Vocabulary

Being able to define a 'unit-of-count' for duty actions, e.g., define what should be reported via odrl:inform (for each userAccount).


3.2.4 POE.R.V.08: Add terms to the Action Vocabulary


3.2.5 POE.R.V.09: Add Linked Data related actions to Action Vocabulary


3.2.6 POE.R.V.10: Add terms to the Roles of a Party Vocabulary

Add the role compensatingParty to the Party Role Vocabulary


3.2.7 POE.R.V.11: New Party Category Vocabulary

Create a new vocabulary with a basic set of terms for the requested new category property of the Party class.


3.2.8 POE.R.V.12: New Asset Category Vocabulary

Create a new vocabulary with a basic set of terms for the requested new category property of the Asset class.


3.2.9 POE.R.V.15: Reference to Source License

Ability to link from a Policy or a Permission to the original (text-based) license.


3.2.10 POE.R.V.16: Assertion Policy Type

It should be possible to define policies of type Assertion. An Assertion policy does not grant any permissions/prohibitions, but reflects policy terms that a party believes to have.


3.3 POE.R.E - Encoding

3.3.1 POE.R.E.01: Referring to external resources for defining payment fees

Define how to specify a fee by referring to an resource outside a policy document


3.4 POE.R.R - Processing Rules

3.4.1 POE.R.R.01: Define rules for matching permissions/prohibitions against specific use cases


3.4.2 POE.R.R.02: Define a language for controlling processing policies


3.4.3 POE.R.R.03: Define processing rules for versioned policies

Rules defining how different versions of a policy with the same identifier should be processed should be specified.


3.4.4 POE.R.R.04: Support to auto-generate a policy from a template plus provided parameter values


3.4.5 POE.R.R.05: Guidance on Rights Assignments through Aggregation and Derivation

Provide guidance and examples of managing rights assignments through aggregations.


3.4.6 POE.R.R.06: Guidance on Specifying Subsets of Assets

Provide guidance and examples of specifying subsets of data as the object of the odrl:target predicate.


3.4.7 POE.R.R.07: Guidance on Conflicting Permissions


3.4.8 POE.R.R.08: Guidance on the Provenance of Policies

Provide guidance and examples of expressing the provenance of the interpretation of the original document, recognising that the original source remains normative.


3.4.9 POE.R.R.09: Make policies accessible by URL

Encourage POE implementers to make policies accessible as a web resource by a URL and http content negotiation should be supported to deliver a specific request format.