Use Cases for the POE (Permission and Obligations Expression) Working Group

This Working Group has been chartered to create recommendations for expressing permissions and obligations statements for digital content. This goal requires to collect uses cases of how currently permissions and obligations are expressed. The use cases below describe a business scenario and which means, including any technology, are used for expressions and communicating them.

Use cases will illustrate different sizes of scenarios, from a small particle in a larger one to comprehensive and complex scenarios.

Submitting a Use Case

A use case should be submitted by:

• Develop the use case based on the template below
• If you are not a member of the POE WG:
  • The use case must be emailed to the public POE Comments list (You may be requested to verify your email address if this is your first post to a W3C list.)
  • The posted use case will be copied to this Use Case page by a member of the POE Working Group
• If you are a member of the POE WG then copy the new UC to end of this wiki page

Use Case Template

(As of 2016-04-04)

The provided use cases (should) follow this template.
Labels in dark red should be considered as required, all others as optional.

• Title
• Contributor (Name of company or organization, specific departments and the name of a contact person may be appended)
• Located in (Name of the city and country the business headquarter of the contributor is located in)
• Industry/business sector (The industry or business sector of the contributor.)
• Website (URL of the contributor's website)
• Use case web page(s) (URL(s) of web pages relevant for this use case)
• Description (Free-text overview of the use case)
• Natural Language Expression (Free-text used to communicate the permissions and/or obligations. Could be language as used in contracts.)
• Formal Language Expression (Free-text used to communicate the permissions and/or obligations in a formal context, e.g. typical language used in a specific metadata field. May be a text template-like style.)
• Technical Expression(s) (This is highly optional, provide it only if a technical expression is used already.
  Any technical syntax used currently to communicate the permissions and/or obligations. Should include a reference to any specification of the used technical means. Should include details about data modelling and transformations between different policies (permissions and/or obligations) and the relationship with targets.)
• Contributor's evaluation (The contributor's ...)
  • Pros (... view on positive aspects of how this use case is currently executed.)
  • Cons (... view on negative aspects of how this use case is currently executed.)
  • POE requirements (... list of requirements which should be covered by the POE recommendation.)

1. Requirement 1
2. Requirement 2
3. ...

Use Case Template for Copy & Paste

Any contributor of a use case is invited to copy the template below and to add the use case's details.

• Title:
• Contributor:
• Located in:
• Industry/business sector:
• Website:
• Use case web page(s):
• Description:
• Natural Language Expression:
• Formal Language Expression:
• Technical Expression(s):
• Contributor's evaluation
  • Pros
  • Cons
  • POE requirements

1. Requirement 1
2. Requirement 2
3. ...

Dummy Use Case 1 (simple)

• Title: License to print a text and to pay a fee
• Contributor: The Text Source (TTS)
• Located in: Paris, France
• Industry: Text publisher
• Website: tts.example.com
• Description: The Text Source (TTS) distributes a text to its business partners and grants to any partner which has a contract with TTS the right to print it under the condition of paying a fee of 100 EUR.
• Natural Language Expression: TTS grants any TTS contract holder the right to print this text under the condition to pay a fee of 100 EUR.
• Contributor's evaluation
  • POE requirements:

1. All the requirements of ODRL
2. In addition: Indicating the due date of the payment

Dummy Use Case 2 (rich)

• Title: Spatial constraint on distributing a photo
• Contributor: Example Photo Agency (EPA)(by Michael S.)
• Located in: Frankfurt, Germany
• Industry: photo agency
• Website: epa.example.com
• Use case web page(s): http://dev.iptc.org/RightsML-Simple-Example-Geographic
• Description: The Example Photo Agency (EPA) distributes an image and grants any party which has a picture contract with the EPA the right to distribute the image, but only inside Germany.
• Natural Language Expression: The EPA offers any EPA picture contract holder the option to distribute a picture within Germany.
• Formal Language Expression (using ODRL terms):The EPA (assigner) offers any EPA picture contract holder (assignee) the option to distribute (action) a picture (target-asset) within Germany (constraint).
• Technical Expression(s)
  • Data Model
    - EPA is an entity having the right to grant licenses to licensees
    - the licensee is an anonymous entity but it is required that it has signed a basic contract with EPA. This intity should be defined as any member of the group of EPA business partners.
    - the action granted to the licensee is named "distribution" and covers the act of of distributing, displaying and/or performing a photo to licensed recipients - as defined by IPTC's RightsML 1.1 [1]. It does not include "public" distribution, as defined by in the ODRL 2.1 Common Vocabulary.
  • ODRL Code
    This is the XML serialization of this use case as ODRL policy:

<o:Policy uid="http://example.com/RightsML/policy/idGeog1"
 type="http://www.w3.org/ns/odrl/2/Set"
 xmlns:o="http://www.w3.org/ns/odrl/2/">
   <o:permission>
      <o:asset uid="urn:newsml:example.com:20090101:120111-999-000013"
       relation="http://www.w3.org/ns/odrl/2/target"/>
      <o:action name="http://iptc.org/std/RightsML/2011-10-07/distribute"/>
      <o:constraint name="http://www.w3.org/ns/odrl/2/spatial"
       operator="http://www.w3.org/ns/odrl/2/eq"
       rightOperand="http://cvx.iptc.org/iso3166-1a3/DEU"/>
      <o:party uid="http://epa.example.com/cv/party/epa"
       function="http://www.w3.org/ns/odrl/2/assigner"/>
      <o:party uid="http://epa.example.com/cv/policy/group/epapartners"
       function="http://www.w3.org/ns/odrl/2/assignee"/>
   </o:permission>
</o:Policy>

• Contributor's evaluation
  • Pros: almost perfect as all business requirements can be expressed
  • Cons: it is not possible to show what a violation of this permission would trigger.
  • POE requirements:

1. All the requirements of ODRL
2. An action taken by the party granting the license if the permission is violated

Use Cases

POE.UC.01 Permissions and obligations for language resources

• Title: Permissions and Obligations for Language Resources
• Contributor: Víctor Rodríguez on behalf of W3C Linked Data For Language Technology Community Group
• Industry: Language resources industry
• Description: Language resources (lexicons, dictionaries, translation memories, etc.) are indexed in language resource catalogs like CLARIN, META-SHARE nodes, LRE Map, OLAC, or Linghub. These resources are offered under a number of licenses which declare permissions and obligations some of which might be captured by ODRL expressions. So far they are represented with XML (see the XML Schema) and with ODRL (plus required vocabulary) as described here.The most representative licenses are the META-SHARE licenses and the CLARIN licenses. The specificities of this domain may be of interest for the ODRL specification in general, in particular the following features:

1. Policy template The first practice is to associate a permissions expression to a resource by making a reference. The resource digital catalog often contains expressions like:

<a_resource> dct:license <https://example.com/uri.of.an.odrl.expression/> .

Where the ODRL expression (which may be an instant license or not) DOES NOT contain any mention to the resource. Extending the idea above, the second practice is to further specify values of a policy template.

<a_resource> dct:license <https://example.com/an.odrl.template/> .
<a_resource> xxx:license_country "Italy" .
<a_resource> xxx:license_price 100 .

The values "Italy" and "100" replace variables within the template. By doing so, a few templates satisfy many users.

• Requirement: "Be able to qualify a policy as Template (possibly as a new type of Policy)"
• Requirement: "Be able to specify variables within a policy and values for that variables"

2. Ability to group parties, assets and policies Some entities are recurrently referenced jointly.

1. Assets: "Dictionary EN-ES", "Dictionary DE-EN", "Dictionary DE-ES" might be published as independent resources, but policies may apply to all of them.
2. Parties: Some kinds of parties are mentioned very recurrently in actual licenses/policies. For example, "academic users" (users belonging to an entity of academic nature), "non-academic users" or having membership in a particular institution. For example within the CLARIN licenses for language resources Clarin conditions, one of the requirements is AFFIL "The user needs to be affiliated with some community, e.g. a community of researchers through a university or research institution (x=EDU) or a community of language research and technology researchers more generally (x=META)".
3. Policies: One resource is sometimes offered to each individual with an specific license ('explicit' licenses, as they are called by META-SHARE). These expressions are sometimes managed globally (deprecate all, etc.).

• Requirement: The current ODRL group mechanism, which only applies to Parties, might be extended to Assets and Policies as well.

3. Information on the rightsholder In order to facilitate the task of asking for additional permissions to the due rightsholder, rights expressions must include not only the resource creator but also the current rightsholder. Thus, there is a need for specifying who is the original IPR rightsholder and who is the current rightsholder of the rights that have been transferred. This might be a polemic feature and perhaps it should be left aside

4. Inform and Redeposit This clause obliges the assignee to inform the assigner on the usages given to the resources. Also, a common obligation consists of redepositing newly created resources from an existing resource (derivative)

• Requirement: Add vocab elements to represent these.

5. Content negotiation in URI-identified ODRL expressions Example: if the URL "http://company.com/odrlpolicy1" is HTTP requested, content negotiation should be implemented to return the HTML/RDF as requested. This feature should be optional, possibly supporting policy templates.

• Requirement: Provide mechanism to relate ODRL policies to textual versions, possibly at a finer grain (specific permission to specific piece of text)
• Requirement: Describe policy template fulfilling mechanism. For example,

Example: if the URI "http://company.com/odrlpolicytemplate1, then the template should be retrieved. Example: if the URI "http://company.com/odrlpolicytemplate1?price=1000&currency=EUR" is HTTP queried, the full policy should be obtained (and not the template)

A number of requirements was found in the work within the Linked Data For Language Technologies (LD4LT) W3C Community Group.
. Many of them are expressable already in ODRL. The rest of the features have been further discussed within the POE group here.

POE.UC.02 Linked Data (specific version and generic version)

• Title: Conditional Access to Linked Data
• Contributor: Victor Rodríguez and Nandana Mihindukulasooriya (UPM) on behalf of the ODRL Linked Data profile editors.
• Industry/business sector: Transversal
• Website: Requirements towards an ODRL Linked Data profile
• Use case web page(s): ODRL Linked Data profile
• Description: 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 eur cent."
• Natural Language Expression: 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 eur cent.
• Formal Language Expression:
• Technical Expression(s):

Expressed with a non up-to-date version of ODRL, but enough to transmit the idea, the following expression would express that policy:

prefix rdfs:  http://www.w3.org/2000/01/rdf-schema# .
prefix dct:   http://purl.org/dc/terms/ .
prefix rdf:   http://www.w3.org/1999/02/22-rdf-syntax-ns# .
prefix gr:    http://purl.org/goodrelations/ .
prefix odrl:  http://www.w3.org/ns/odrl/2/ .

http://conditional.linkeddata.es/ldr/policy/ee32f675-ccae-4ca9-a544-3c07abf0b16e
        a                odrl:Offer ;
        rdfs:comment     "Individual triples are available upon payment of 1 euro cent" ;
        rdfs:label       "License1Cent" ;
        odrl:permission  [ 
                           odrl:action odrl:reproduce ;
                           odrl:target ex:graph1 ;
        ] , [
		           odrl:action odrl:reproduce ;
		           odrl:target ex:graph2 ;
		           odrl:constraint [
			                  odrl:operator odrl:lteq ;
			                  odrl:dateTime "2016-12-31"^^xsd:date
		]
        ] , [ 
                           odrl:action  odrl:reproduce ;
                           odrl:target ex:graph3 ;
                           odrl:duty    [ 
                                          rdfs:label            "Pay" ;
                                          gr:UnitOfMeasurement  rdf:Statement ;
                                          gr:amountOfThisGood   "1" ;
                                          odrl:action           odrl:pay ;
                                          odrl:target           "0.01 EUR"
                                        ]
                         ] .

This expression might be processed in the context of a wider architecture as in the following figure.

• Contributor's evaluation
  • Pros A large community would become adopter of POE specifications
  • Cons Some of the requirements might be too intimately related to one specific domain. Domain-specific vocabulary should perhaps constitute a profile. Integration with the W3C LDP Next Community Group might be desirable.
  • POE requirements As preliminary work, a detailed list of requirements has been identified at https://www.w3.org/community/odrl/wiki/Call_for_requirements_towards_an_ODRL_Linked_Data_profile.

RA - Specific requirements derived from the example above:

• RA1: The CRUD operations should be inequivocally described (i.e., only one term to declare "Read" access, and not the many that now could be interpreted). Maybe also in tighter relationship with the Linked Data Platform vocabulary.
• RA2: Richer manners of expressing payments and prices are required. In the ConditionalLinkedData example, an externa schema (GoodRelations) was taken.
• RA3: The range of syntactically valid expressions is too large to grant that any valid expression will be parsed. This is promising too much. A more constrainted syntax is needed (avoiding recursions, a limit in the nested elements, etc.)
• RA4: A default policies for actions must be implicitly declared (if nothing said about 'delete', then allow 'delete', etc.).

General requirements derived from more general situations handling linked data

The situations in which a POE expression might be applicable to Linked Data resources is very wide. Some specific user stories can be conceived. The overall load of requirements might be too wide but satisfying the maximum number of them would be helpful.

S - Specific user stories

• S1: Monetary Benefit. As owner of a dataset, I want to be able to charge consumers for using my data. This fee should depend on the nature of use as well as data they actually want to consume.

• S2: Granularity. As owner of a dataset, I want to be able to define policies for different levels of granularity of data. It should be possible to operate on triple level, subgraph level, as well as on the entire RDF graph representing the data itself.

• S3: Licensing. As owner of a dataset, I want to be able to define licensing conditions for that dataset. Those conditions must be as expressive as common license vocabularies (cf. Creative Commons, etc.), i.e. pre-defined data licenses like PDDL, CC-Family, ODC, etc. must be representable.

• S4: Actions relevant to Linked Data. As owner of a dataset, I want to be able to use/restrict actions which are relevant to Linked Data scenarios. Such actions include (but are not limited to): querying data, aggregating data, reading data, etc..

• S5: Defining Preconditions for Policies. As owner of a dataset, I want to be able to define preconditions for my policies. It should be possible to state, that certain policies only apply within certain scenarios (i.e. when their precondition(s) hold). Those policies can include both permissions as well as prohibitions.

• S6: Clustering Policies in Sets of Policies. As owner of a dataset, I want to be able to cluster a policies into sets of policies. Those policy sets may adhere to different conflict resolution strategies than their containing policies.

• S7: Defining Remedies. As owner of a dataset, I want to be able to define remedies for violated prohibitions or duties (cf. ODRL Remedies)

• S8: Extended Relations. As owner of a dataset, I want to be able to define more complex policies by combining permissions, prohibitions, constraints and duties using extended relations (cf. ODRL Extended Relations)

• S9: Temporal Constraints. As owner of a dataset, I want to be able to define fine-grained temporal constraints for my policies. It should be possible to define absolute as well as relative timeframes in terms of days, minutes, dates, etc. and to define that certain policies are only valid within those timeframes.

• S10: Specifying Default Behavior for missing Information. As owner of a dataset, I want to be able to define not only conflict resolution strategies for my policies and policy sets, but also default behavior in terms of missing information. E.g., I want to be able to state that, if the execution a certain action is not explicitely prohibited, it is permitted.

• S11: Specifying Default Behavior for Parties. As owner of a dataset, I want to be able to state whether policies defined for a group of assignees affect shall affect policies defined for single assignees. E.g., If everyone is prohibited to use my dataset but Alice is allowed to use it, does the more general policy "overrule" the more specific one?

• S12: Implicitely affected Actions. As owner of a dataset, I want to know which actions are implicitely affected by permissions/prohibitions of others. I'm not only interested in the subsumption hierarchy of actions (e.g. use is more general than read) but also in part-of relationships of actions (e.g. to share something involves distributing it). To satisfy my needs, the ODRL core model should be extended by appropriate relationships between actions.

• S13: Precedence Relationship. As owner of a dataset, I want to be able to define precedences among permissions, prohibitions and duties. This would allow to easily map policies into defeasible logic (cf. A Modelling and Reasoning Framework for Social Networks Policies (Section 9.1))

• S14: Responsibility. The consumer of a dataset is entirely responsible, to the exclusion of the dataset author and any other persons, for compliance of the use and reuse of the data with the regulations set by the dataset owners, and with the local regulations regarding use, including those regarding import, export, and use of encryption software.

WS - Requirements in a wide sense

• WSS Specification
  • WSS1 Granularity: Existing access control strategies for RDF, resources are specified at several different levels of granularity. Namely, triples, named graphs, views, triple patterns, graph patterns with filters and graph patterns without filters, ontology concepts, ontology individuals, and graph nodes and edges.
  • WSS2 Underlying Formalism: Access control languages should be based on formal semantics, as it decouples the meaning of the policies from the actual implementation.
  • WSS3 Reasoning: It should be possible to propagate policies based on the semantic relations between authorisation subjects, objects and access rights.
  • WSS4 Condition Expressiveness: When it comes to access control, it should be feasible to specify conditions under which a request will be permitted or prohibited.
  • WSS5 Attributes, Context & Evidences: As the requester many be unknown to the system prior to submitting a request, access should be based on properties pertaining to the requester, commonly know as attributes, instead of traditional identities. It should also be feasible to dynamically activate policies based on context.
  • WSS6 Heterogeneity & Interoperability: Access control for open distributed environments, such as the web, needs to be able to support a wide variety of disparate policies, resources and users. One of the primary goals of standardisation is to maximize interoperability.
• WSE Enforcement
  • WSE1 Negotation: In order to protect user privacy, it should be possible for both the service provider and the requester to define polices and exchange credentials until and agreement has been reached. The process is commonly known as negotiation.
  • WSE2 Explanations: Rather than simply granting or denying access, the policy should also provide details of how the decision was reached. Such explanations would be of benefit to both the requester and the policy owner, making it easier for the requester to understand what is required of them and for the policy owner to troubleshoot potential problems.
  • WSE3 Conflict Resolution: Conflicts between both explicit and implicit policies should be resolved automatically.
• WSA Administration
  • WSA1 Delegation: It should be feasible to temporarily transfer access rights to other users.
  • WSA2 Consistency & Safety: In order to ensure the access control system is complete and accurate, insertion and deletion of policies should be controlled. It should not be possible to elevate your own privileges or to assign permissions that would make data inaccessible to everyone.
  • WSA3 Usability: The specification and the maintenance of access control policies should be as simple as possible.
  • WSA4 Understandability: It should be easy to understand the interplay between policies.
• WSI Implementation
  • WSI1 Effectiveness: In order to work in practice, access control enforcement and administration needs to be efficient.
  • WSI2 Distributed: In order to ensure scalability, it should be possible to cater for the distributed specification and enforcement of access control policies.
  • WSI3 Flexibility & Extensibility: The system should be capable of handling frequent changes to policies, user, access rights and resources. In addition, in order to provide support for different scenarios and future enhancements, the enforcement frameworks should be flexible and extensible.

POE.UC.03 Published article with embargoed dataset

• Title: Published article with embargoed dataset
• Contributor: Phil Archer & Keith Jeffery on behalf of the VRE4EIC Project
• Located in: EU, coordinator is ERCIM
• Industry/business sector: STEM Publishing
• Website: http://www.vre4eic.eu/
• Use case web page(s): N/A
• Description: Description: 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.
• Natural Language Expression: The data supporting this paper is not currently available except to the researchers who created it. It will be openly and freely available on (date).
• Formal Language Expression:
• Technical Expression(s):
• Contributor's evaluation
  • Pros
  • Cons
  • POE requirements

1. The ability to express that permissions & obligations apply for a defined period of time.

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

• Title: Technical documents rules for business process regulatory compliance
• Contributor: Serena Villata (joint work with Guido Governatori) in the context of the MIREL Project
• Located in: EU, coordinator is University of Luxembourg
• Industry/business sector: business process regulatory compliance
• Website: http://www.mirelproject.eu/
• Use case web page(s): N/A
• Description: Technical documents describe how to handle and what are the functionalities of a certain product or process. 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.
• Natural Language Expression: Data will be available soon.
• Formal Language Expression:
• Technical Expression(s):
• Contributor's evaluation
  • Pros
  • Cons
  • POE requirements

1. Ability to express the permissions, obligations and prohibitions present in these documents in a machine-processable way
2. Ability to express rules of the kind "IF a, b, c hold, THEN d is obligatory/permitted/forbidden" where the conditions a, b, c may be of different kind (e.g., actions, facts) and they are connected using the standard operators AND, OR. Negation can also be applied to the conditions. d is the normative effect of the rule.
3. Ability to check the compliance of a certain process and the tasks composing it with respect to the regulations, i.e., the set of permitted/obliged/prohibited actions.
4. Ability to track which version of the regulation exposes a certain permission/prohibition/obligation and whether it is still in force in the latest version of the regulation.

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

• Title: Determine an identifier representing the audience who can access a digital resource
• Contributor: Mo McRoberts, BBC
• Located in: EU
• Industry/business sector: Media
• Website: http://www.bbc.co.uk/
• Use case web page(s):
• Description: 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.
• Natural Language Expression: The media asset (or other digital resource) may be played back/viewed by members of the group with the given URI
• Formal Language Expression:
• Technical Expression(s):

The below expression, provided as Turtle, describes an episode of a television programme which has an embeddable player associated with it. The media may be accessed, via the embeddable player, by those people who are members of "Example Educational Licensing Scheme A"

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix dct: <http://purl.org/dc/terms/> .
@prefix dcmitype: <http://purl.org/dc/dcmitype/> .
@prefix odrl: <http://www.w3.org/ns/odrl/2/> .
@prefix mrss: <http://search.yahoo.com/mrss/> .

</0b4479e5664643feb6df3f2f8aed831d#episode>
    mrss:player </0b4479e5664643feb6df3f2f8aed831d/player> ;
    a po:Episode ;
    rdfs:label "BBC News"@en-gb .

</0b4479e5664643feb6df3f2f8aed831d/player>
    dct:format <http://purl.org/NET/mediatypes/text/html> ;
    dct:license </terms#id> ;
    a dcmitype:MovingImage, foaf:Document .

</terms#id>
    a odrl:Policy ;
    rdfs:label "Accessible only to members of Example Educational Licensing Scheme A"@en-gb ;
    odrl:permission </terms#play> .

</terms#play>
    a odrl:Permission ;
    odrl:action odrl:play ;
    odrl:assignee <http://example.com/schemes/educational-licensing-a#members> .

<http://example.com/schemes/educational-licensing-a#members>
    a odrl:Group ;
    rdfs:label "Members of Example Educational Licensing Scheme A"@en-gb .

• • POE requirements

1. One is able to create a policy document granting permission to a group (or a person) to perform an action

POE.UC.06 OpenPHACTS

• Title: Tracking permissions related to merged datasets
• Contributor: Phil Archer for the Big Data Europe Project
• Located in: EU
• Industry/business sector: Pharmacological data
• Website: http://openphacts.org
• Description: 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.

• Requirements:

1. association of permissions and obligations alongside provenance details for datasets throughout a tool chain;
2. association of permissions and obligations with subsets of data, i.e. P&OEs do not necessarily become merged when datasets are merged.

POE.UC.07 News Permissions and Restrictions

• Title: Can I Use this Piece of News Content?
• Contributor: Stuart Myles
• Industry/business sector: News and Media
• Use case web page(s):
• Description: 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 such factors 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. For example, "No use in UK after 7 days".

What Do Editors Want?

Ideally, not to worry about rights… 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).

• Natural Language Expression:

RH.1: Create a policy

"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.

RH.2: Identify a set of content

"Identify one or more items of content to be treated as a set". (RH.2 may well be outside the scope of POE). The Rights Holder defines one or more content items which are to be treated as a set. The set must have a unique identifier. Examples of how to identify the set include

• List the content item identifiers ("Here's a fixed set of content")
• All of the content items which match a search or query ("All of the content which does or will match these search criteria")
• All of the content items which are manually selected by the Rights Holder ("The content set contains everything I say is in it")

(The latter two methods - query and manual selection - are an open-ended set, which can grow over time).

RH.3: Associate a policy with a set of content

"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.

E.1 Identify a use

"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.

E.2 Determine whether a use is permitted for a particular content item =

"I can use the item, as long as my contract permits me to and any editors note for the item doesn't say I cannot". 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".

E.2.1 The first step is to identify which policies apply to this content item, i.e. to which content sets does this item belong? And what policies apply to those content sets? (It is typical for a contract to apply to all of the members of a content set but for one particular item to have a supplemental policy to provide additional restrictions).

E2.2 The second step is to evaluate whether the set of policies permit the desired use. If none do, then the use is not permitted: result "no". (That which is not specifically permitted is forbidden).

E2.3 If one or more of the policies permits the use, do any of the policies restrict the use? (It could be that the general contract permits the use of a piece of content but that a policy attached to this particular item does not permit the particular use, e.g. because of the location of the action). If a policy restricts the use, then the use is not permitted: result "no".

E2.4 Finally, if the use is permitted by E2.2 and not restricted by E2.3, then are there any duties which must be fulfilled in order to unlock the use. If so, then the Editor must decide whether to comply with the duties: result "maybe". If there are no duties required to unlock the use, then the use is permitted: result "yes".

See also IPTC's RightsML Processing Model

• Formal Language Expression:
• Technical Expression(s):
• Contributor's evaluation
  • Pros
  • Cons
  • POE requirements

1. POE must support all of the requirements of ODRL 2.1
2. POE must allow for the identification of a "policy bundle" - a set of permissions and restrictions with constraints, together with any duties that 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.
3. POE must allow for the identification of a "use bundle" - a set of actions with context in which that action is to be performed. 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.

POE.UC.08 Atomic Understanding of Common Licenses

• Title: Atomic Understanding of Common Licenses
• Contributor: Phil Archer
• Located in: EU
• Industry/business sector: Public Sector Information
• Website: http://www.europeandataportal.eu/
• Use case web page(s): N/A
• Description: The European Data Portal 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 reusers can assess whether or not a particular combination of datasets is permissible and, if so, under what conditions. A local copy of their work is available at File:Edp-licence-compatibility-published v1 0.xlsx with the original source available on the European Data Portal itself as Licence Assistant: European Data Portal Licence Compatibility Matrix.

It is noteworthy that this use case was repeated by the BigDataEurope project during a side event at the European Data Forum 2016

• Requirements

1. Ability to express permissions and obligations provided in natural language in a machine-processable way.
2. The ability to link from those atomic Ps & Os to the original source document.
3. The ability to express the provenance of the interpretation of the original document, recognizing that the original source remains normative.

POE.UC.09 Base Product

• Title: Multiple Permissions for a Single Price
• Contributor: Ben Whittam Smith on behalf of Thomson Reuters
• Located in: Global
• Industry/business sector: Data provision
• Website: http://www.thomsonreuters.com
• Description: 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.
• Requirements

1. The pricing is not set at the individual permission level, but at the package (odrl:Policy?) level.

POE.UC.10 Pay-by-Use

• Title: Pay-by-Use
• Contributor: Ben Whittam Smith on behalf of Thomson Reuters
• Located in: Global
• Industry/business sector: Data provision
• Website: http://www.thomsonreuters.com
• Description: 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 everytime it is printed or included in a PDF.
• Requirements

1. A way of identifying the 'unit-of-count' that can act as a constraint on the compensation duty.
2. A user account is a very common 'unit-of-count'. A 'physical ID' is often used if you want to charge for each device (work PC, home laptop, smartphone) accessing the service.
3. The 'unit-of-count' concept goes beyond just payment. For example, it is also applicable to defining what should be tracked (odrl:acceptTracking) or reported (odrl:inform).

• Technical Expression:

:duty1 a odrl:Duty ;
    odrl:action odrl:compensate ;
    odrl:compensatedParty <> ;
    odrl:compensatingParty <> ;
    odrl:constraint :constraint1-1, :constraint1-2 .
 
:constraint1-1 a odrl:Constraint ;
    odrl:payAmount odrl:rightOperand ""^^xsd:decimal ;
    odrl:unit <http://cvx.iptc.org/iso4217a:USD> .
 
:constraint1-2 a odrl:Constraint ;
  	:unitOfCount :userAccount .

POE.UC.11 Third-Party Rights Management

• Title: Third-Party Rights Management
• Contributor: Ben Whittam Smith on behalf of Thomson Reuters
• Located in: Global
• Industry/business sector: Data provision
• Website: http://www.thomsonreuters.com
• Description: There are some common obligations (odrl:Duty) 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 (ike a 'Restriction On Distribution Statement').
• Requirements

1. Some new actions (and associated roles): contract, acknowledge copyright, acknowledge.
2. We also need some additional roles associated with existing actions (for example, a compensatingParty to complement the existing odrl:compensatedParty).

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

• Title: Tracing Permissions and Obligations through Aggregations and Derivations
• Contributor: Ben Whittam Smith on behalf of Thomson Reuters
• Located in: Global
• Industry/business sector: Data provision
• Website: http://www.thomsonreuters.com
• Description: 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?

• Requirements

1. Guidance on how to automatically generate the policies of data sets through aggregation and derivation.

POE.UC.13 Delegation

• Title: Delegation
• Contributor: Ben Whittam Smith on behalf of Thomson Reuters
• Located in: Global
• Industry/business sector: Data provision
• Website: http://www.thomsonreuters.com
• Description: Assigners are often corporate entitites. 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 asignement (as no rights are being assigned?) but a delegation.
• Requirements

1. A way to express a delegation of rights rather than an assignment of rights.

POE.UC.14 A Vote for Extended Relations

• Title: A Vote for Extended Relations
• Contributor: Ben Whittam Smith on behalf of Thomson Reuters
• Located in: Global
• Industry/business sector: Data provision
• Website: http://www.thomsonreuters.com
• Description: 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.
• Requirements

1. A means of expression the option to provide either a list of Access IDs OR Physical IDs.

:duty1 a odrl:Duty ;
    odrl:action odrl:inform ;
    odrl:timeInterval "15"^^xsd:gDay
    odrl:operation odrl:xor
    odrl:constraint :constraint1, :constraint2 .
 
  :constraint1 a odrl:Constraint ;
  	:unitOfCount :AccessIDList .
 
  :constraint2 a odrl:Constraint ;
  	:unitOfCount :PhysicalIDList .

POE.UC.15 Real-time Vs Delayed Data

• Title: Real-time Vs Delayed Data
• Contributor: Ben Whittam Smith on behalf of Thomson Reuters
• Located in: Global
• Industry/business sector: Data provision
• Website: http://www.thomsonreuters.com
• Description: 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).
• Requirements

1. Enable a constraint to express the distinction;
2. Specifify the delay (often 15 minutes in financial markets).

POE.UC.16 Accessing Historical Data

• Title: Accessing Historical Data
• Contributor: Ben Whittam Smith on behalf of Thomson Reuters
• Located in: Global
• Industry/business sector: Data provision
• Website: http://www.thomsonreuters.com
• Description: 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.
• Requirements

1. Additional sub-properties of odrl:rightOperand to cover access period and access interval.

  :constraint1 a odrl:Constraint ;
  	:accessInterval "---01"^^xsd:gDay .
 
  :constraint2 a odrl:Constraint ;
  	:accessPeriod "P7Y"^^xs:duration.

POE.UC.17 Asset in a set

• Title: Policy refers to n Assets within a specific set of Assets
• Contributor: James Birmingham on behalf of Digital Catapult
• Located in: UK
• Industry/business sector: Data
• Website: https://www.digitalcatapultcentre.org.uk
• Description: 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.
• Requirements

1. An Offer must be able to Target a "set of Assets".
2. An Offer must be able to specify the number of Assets from the set it is referring to.

POE.UC.18 Policy Assertion

• Title: A new Type of Policy: Assertion
• Contributor: Renato Iannella
• Industry/business sector: All
• Description: 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 rightsholder or other roles.
• Requirements

1. A new policy Type "Assertion".
2. A new party role "rightsHolderParty"

POE.UC.19 Relative Time Constraints

• Title: A time constraint is a based on a relative point in time
• Contributor: Michael Steidl
• Located in: London, UK
• Industry/business sector: news industry
• Website: https://iptc.org
• Description: Example 1: Organisers of sport events grant the use of photos or videos relative to the end of a sport event/game. (Note: the live publishing of photos/videos may be granted by a different license.)
  Example 2: Speakers at a conference circulate a document with their speech in advance and they permit to publish it only after the speech has ended.
• Natural Language Expression: Example 1: "Photos of this game can be published only 30 minutes after the game has ended."
  Example 2: "The text of this speech can be published only after the speech has ended."
  • POE requirements

1. R1: the dateTime constraint must take also relative points in time or a new relativeDateTime constraint must be created taking only relative points in time
2. R2: R1 may be optionally extended by adding an explicit period to the relative point in time.

POE.UC.20 POE expression-external declaration of a payment amount

• Title: POE expression-external declaration of a payment amount
• Contributor: Víctor Rodríguez-Doncel
• Industry/business sector: language resources
• Website: http://www.meta-net.eu/meta-share/licenses
• Description: 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. See an introduction here metashare.
  These resources are described with small pieces of metadata, according to their schema. The maintainers of the 32 repositories can edit simple metadata records (property-value) but they are not skilled to edit ODRL expressions. They would like 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.
   

The burden of knowing the ODRL model is alleviated in this manner.

• POE Requirements

1. POE.UC.01.R14 - Ability to specify the fee in a duty to pay within and outside the POE expression
2. POE.UC.01.R16 - Ability to define policy templates: ODRL policies with the special feature of value variables should be a "policy template"
3. POE.UC.01.R18 - Ability of policies to be retrieved by URL: if the URL identifying a policy is requested, it should return a (machine/human) readable representation of the policy (format as preferred by the request).
4. Ability to combine the variables in a "policy template" with values outside the template to make a complete policy.

POE.UC.21 Constraints imposed on properties of key entities of the data model

• Title: Constraints imposed on properties of key entities of the data model
• Contributor: Víctor Rodríguez-Doncel
• Industry/business sector: agnostic
• Description: It is a frequent case that a constraint must be evaluated against a property of the asset, e.g. of the assignee or of other external entities. The exact subject of such an evaluation is currently not encoded; it has to be inferred from the textual semantics of each of the 25 constraint terms in the current ODRL 2.1 Vocabulary
  These style of constraints is insufficient to cover new usages of ODRL and they are unclear in terms of their semantics.
  By the small change of adding the subject of the constraint ot a constraint, the current ODRL expecification would have an important boost in expressivity without compromising a possible evaluation by a machine.

• POE Requirements

1. POE.UC.21.R01 - Ability to specify in a constraint: the entity for (further) evaluation (assignee, assigner, context_time, context_history, context_deliverychannel).
2. POE.UC.21.R02 - Ability to specify in a constraint: the property of the entity for evaluation (foaf:age etc.).

• Example of a possible implementation

The asset "ex:AdultContent" can only be read by assignees whose age is greater or equal to 18. ...

 _:myPolicy
       a odrl:Set ;
       odrl:permission [
              odrl:action odrl:read ;
              odrl:target ex:AdultContent ;
              odrl:constraint [
                      odrl:entity odrl:assignee
                      odrl:leftOperand foaf:age ;
                      odrl:geq 18 ;
              ] ;
       ] .

...

POE.UC.22 Technical documents rules for business process regulatory compliance (Update UC 4.0)

• Title: Technical documents rules for business process regulatory compliance
• Contributor: Serena Villata (joint work with Guido Governatori) in the context of the MIREL Project
• Located in: EU, coordinator is University of Luxembourg
• Industry/business sector: business process regulatory compliance
• Website: http://www.mirelproject.eu/
• Use case web page(s): N/A
• Description: 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.
• Natural Language Expression: Data will be available soon.
• Formal Language Expression:
• Technical Expression(s):
• Contributor's evaluation
  • Pros
  • Cons
  • POE requirements

1. Ability to express rules of the kind "IF a, b, c hold, THEN d is obligatory/permitted/forbidden" where the conditions a, b, c may be of different kind (e.g., actions, facts) and they are connected using the standard operators AND, OR. Negation can also be applied to the conditions. d is the normative effect of the rule.
2. Ability to combine rules (i.e., conditions) in more complex ones involving time constraints and deontic constraints over entities of different types.
3. Ability to manage conflict resolution over different versions of the policies (e.g., rules of v1 of the code and rules of v2 of the code are merged together, but if a conflict arises then v2 duties, i.e., amendments, have the priority over duties of v1).

Use Cases (Since FPWD)

POE.UC.23 Deletions Must be Propagated

• Title: Deletions Must be Propagated from Source
• Contributor: Brian Ulicny
• Located in: Boston, MA
• Industry/business sector: Data Provision
• Website: http://www.thomsonreuters.com
• Use case web page(s):
• Description: 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.
• Natural Language Expression: If a record r is deleted in source s, it must be deleted in any dataset derived or copied from s.

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

• Title: Synchronization in a multilayer music description environment
• Contributor: Laboratorio di Informatica Musicale (LIM), Department of Computer Science, Università degli Studi di Milano
• Located in: Italy
• Industry/business sector: Education
• Website: http://www.lim.di.unimi.it
• Use case web page(s): http://emipiu.di.unimi.it
• Description:

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.

• Natural Language Expression

Let us consider an IEEE 1599 document that describes the Triumphal March from Aida, Act II by Giuseppe Verdi. Such a document contains multiple descriptions of the music piece:

• the symbolic score, namely an XML description of all its music events, e.g. all notes and rests;
• multiple audio tracks, referring to different recordings;
• multiple graphical resources, each one corresponding to a scanned score page. Please note that graphical files can be aggregated to form a given score version (of course, multiple versions are allowed);
• additional media materials, such as lyrics, scanned playbills, etc.

Multiple scenarios can be identified, thus creating different user profiles.

First, a user could enjoy all the descriptions of the piece at high quality, but only from measure 1 to 16 (i.e. a high-quality preview). Another user could have access to all resources and descriptions, for the total extent of the piece, but only at a lower quality. Another user could play all the audio tracks – or only the tracks he/she has paid for – and jump from one to another in real time with no gap in the performance, but with no access to any graphical representation of the score. In this way, synchronization is still granted (it is required to jump from a track to another), but so-called “score following” is not supported. Finally, a user cold be granted the right to access to single resources, but to view/play them separately, with no synchronization.

• Related requirements:

1. Ability to express the synchronization permission;
2. Ability to represent who is the synchronization producer rightsholder;
3. Ability to consider an offer applied to many assets (POE.UC.17);
4. Ability to consider an asset as a set of more detailed basic fragments (e.g., any score is composed by staff systems, each staff system by staves, each staff by voices, each voice either by chords or rests, each chord by single noteheads);
5. Ability to characterize each fragment through a number of suitable attributes. For example, the declaration of measure numbers allows to infer which is the measure range contained by each score page, depending on the score version;
6. Ability to characterize each attached media through a number of suitable attributes. This allows, for instance, the automatic identification of the quality level of an audio or a graphical file (format, compression type and rate, resolution, etc.).

The mentioned requirements are used to check and validate the constraints expressed in the license.

POE.UC.25 Magazine Media Permissions

• Title: How can I Use this Magazine Media Content Asset?
• Contributor: Dianne Kennedy, Idealliance
• Industry/business sector: Magazine Media
• Website: http://www.prismstandard.org
• Description:

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:

• Magazine media companies wish to define the ability of editors and staff to modify content.
• Magazine media companies wish to define the ability of editors and staff to translate textual content by language.
• Magazine media companies also want to note the following duties:
  • Payment (e.g. "You can use this photo online for EUR80").
  • Attribution (e.g. "Credit Kyoto News")
  • Notification (e. g. “University of North Carolina”)
  • Approval (e.g. “Major League Baseball”)
• Magazine media companies wish to define their ability to use content for promotional purposes.
• Magazine media companies wish to restrict the primary distribution of their content by:
  • Geography/Spatial (e.g. " only") (US, CA)
  • Time (e.g. "No distribution before dd/mm/yyyy ")
  • Territory/Reciepent (e.g. "North America")
  • Editorial Delivery Channel (e.g. “Print only”)
  • Promotional Delivery Channel (e. g. “email”)
• Magazine media companies wish to define their ability to grant use of content to third party aggregator/syndicators.
• Magazine media companies wish to express to third party aggregator/syndicators any legal restrictions on the redistribution of content.

• Natural Language Description:

This sample use case for magazine media involves an article licensed from party 01203 from the licensee database The article is licensed for the publication in print and mobile for distribution in the US and Canada. The licensing party must be notified when the article is published. The article cannot be distributed until April 22, 2016 and rights expire on November 30, 2016. Editorial modification is permitted but consent must be obtained.

The content is also licensed for promotional purposes. Again consent must be obtained. Third party distribution is not allowed. The promotional materials containing article content e cannot be distributed until March 1, 2016 and promotional usage rights expire on November 1, 2016.

• Formal Language Description:

The policy for the use of this article is made up of 3 permissions with their constraints and duties.

1. The publisher is allowed to publish the content. However the publisher is constrained to publish as editorial content only in the US and Canada between the dates of April 30, 2016 and November 30, 2016. The content can be published on any platform.The licensing party must be notified when the article is published.
2. The publisher is allowed to modify the content but permission must be obtained for the final edited version from the licensing party.
3. The publisher is allowed to use the content for promotional purposes between March 1 and November 1, 2016. Permission must be obtained for the final edited version from the licensing party.

• Technical Language Description:

PRISM Metadata Expression:

Note: the PRISM Licensing Terms metadata is designed to map into ODRL/POE policy statements in the future. PRISM uses only permissions with constraints and duties. Prohibitions are not included in the PRISM licensing terms metadata model. A community vocabulary very close to the default will be used. PRISM allows for either literal or referential values to be used.

<permission present=“yes” >
 <constraints country=“US, CA” 
            mediaPlatform=“all” 
            purpose=“editorial” 
            embargoDate=“04222016”  
            expirationDate=“11302016” />
 <duties inform=“pty01203”/>
</permission>
<permission modify=“yes” />
 <constraints purpose=“editorial” />
 <duties obtainConsent=“pty01203”/>
</permission>
<permission present=“yes” />
  <constraints purpose=“promotional”
            promotionalPlatform=“email” 
            embargoDate=“03012016”  
            expirationDate=“11012016” />
 <duties obtainConsent=“pty01203”/>
</permission>

• Contributor's Evaluation:

Pros: Mapping from PRISM (today) to POE seems possible

Cons: Purpose (Promotional vs Editorial) use must be considered. See requirements below.

POE requirements:

1. POE must support all of the requirements of ODRL 2.1
2. POE must allow for the identification of a "policy bundle" - a set of permissions with constraints, together with any duties that must perform. The set may be associated with one or more sets of content. Therefore the policy bundle must have a unique identifier.
3. POE must allow for the identification of a "use bundle" - a set of actions with context in which that action is to be performed. 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. purpose="promotional"). 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.

POE.UC.26 Data Quality Policy

• Contributor: Antoine Isaac <aisaac@few.vu.nl> Riccardo Albertoni <riccardo.albertoni@ge.imati.cnr.it>

Example from the W3C Working Group Data on the Web Best Practices (https://www.w3.org/2013/dwbp/), more specifically for the Data Quality Vocabulary (https://www.w3.org/TR/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 (99). The odrl:assignee is the Party is the recipient of the policy statement and the odrl:assigner is the Party is the issuer of the policy statement.

For discussion about this example see http://lists.w3.org/Archives/Public/public-odrl/2016Feb/0000.html

NB: The latest version of this example can be seen on the latest DQV draft or the latest DQV published version.

 # relevant metric, dimension, and category definitions  
 :accessibility a dqv:Category .
 :availability a dqv:Dimension .
 :sparqlEndpointUptime a dqv:Metric .

 # dataset and distribution
 :myDataset a  dcat:Dataset ;
   dcat:distribution :myDatasetSparqlDistribution ;
 :myDatasetSparqlDistribution a dcat:Distribution .

 # concrete metric values
 :myDatasetSparqlDistribution dqv:hasQualityMeasurement :measurement1 .
 :measurement1 a dqv:QualityMeasurement ;
   dqv:isMeasurementOf :sparqlEndpointUptime ;
   dqv:value "99"^^xsd:double .

 # the parties
 :serviceProvider a odrl:Party.

 # the quality policy itself
 :policy1 a odrl:Offer, dqv:QualityPolicy ;
   odrl:permission [
     a odrl:Permission ;
     odrl:target :myDataset ;
     odrl:action odrl:read ;
     odrl:assigner :serviceProvider;    
     odrl:duty [
       a odrl:Duty;
       odrl:assignee :serviceProvider;
       odrl:target :myDatasetSparqlDistribution ;
       odrl:constraint [
         a odrl:Constraint ;
         prov:wasDerivedFrom :sparqlEndpointUptime;
         odrl:percentage  "99"^^xsd:double ;
         odrl:operator odrl:gteq
       ]     
     ]
  ]

NB: 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.

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

• Contributor: Antoine Isaac <aisaac@few.vu.nl> Riccardo Albertoni <riccardo.albertoni@ge.imati.cnr.it>

Example from the project http://rightsstatements.org/ where we're trying to solve some modeling issues on rights statements for digital cultural collections.

In Turtle RDF. I spare you the namespace declarations...

  <http://rightstatements.org/rs/ic-edu> a dcterms:RightsStatement , odrl:Policy ;
    skos:prefLabel "In Copyright - Educational Use Only"@en ;
    skos:definition "This digital object is protected by copyright and/or related rights. For educational uses, no additional copyright permission is required from the copyright holder. Please refer to the Data Provider for additional information."@en ;
    dc:creator: "Digital Public Library of America and Europeana Rights Working Group" ;
    dcterms:hasVersion "1.0" ;
    dcterms:modified "2014-12-18" ;
    dc:identifier "ic-edu" ;
    skos:relatedMatch premiscopy:cpr ;
    odrl:permission [
           odrl:action odrl:use ;
           odrl:constraint [
             odrl:operator odrl:eq ;
             odrl:purpose <http://rightstatements.org/purpose/education> # This would be preferably from an existing namespace, not ours.
           ]
    ] .

POE.UC.28 to POE.UC.36 Use Cases from Book Industry Study Group (BISG)

See GoogleDoc

restrictions

POE.UC.37 Representing regulations using ODRL

• Title: Representing regulations using ODRL
• Contributor: Sabrina Kirrane & Sushant Agarwal
• Industry/business sector: legal
• Description: The new EU General Data Protection Regulation (GDPR) will soon replace the older data protection directive. Currently, the knowledge to comply with the regulation is only available in a human-readable format. If this knowledge is translated into machine-readable rules then computer based systems can ease data protection information retrieval as well as the process of checking GDPR compliance.

We define the GDPR profile as follows: The GDPR is represented as an instance for Policy, while personal data is an instance of the Asset class. While, the controllers, processors, data subjects, supervisory authorities can be expressed as instances of the Party class and data processing as an instance of the Action class whereas GDPR obligations are defined as instances of the Duty class. For the ODRL vocabulary, if all duties are fulfilled then the controller/processor comply with the regulation and is allowed to process personal data .

Using the existing ODRL model, it is difficult to express: 1) the discretional (optional) duties, 2) dispensation scenarios, 3) Sub-obligations which are not independent and 4) constraints related to Action, Asset and Party.

We propose the following minor modifications in the core model:

• We add Article and Paragraph subclasses to the Policy class. In our use case scenario we also need to be able to relate articles and paragraphs to each other. For instance, the obligation to ensure that information given to data subjects is transparent as defined in Article 12 para 1 cannot be checked in isolation as it is related to other obligations defined in Article 15-22 and 34. References can also relate to explicit paragraphs and can be implicit in nature.

Article 12 Transparent information, communication and modalities for the exercise of the rights of the data subject 1.The controller shall take appropriate measures to provide any information referred to in Articles 13 and 14 and any communication under Articles 15 to 22 and 34 relating to processing to the data subject in a concise, transparent, intelligible and easily accessible form, using clear and plain language, in particular for any information addressed specifically to a child. The information shall be provided in writing, or by other means, including, where appropriate, by electronic means. When requested by the data subject, the information may be provided orally, provided that the identity of the data subject is proven by other means.

• We add the following subclasses to the Constraint class:

-"Discretional" for the duties which are recommended but not obligatory

Article 12 Transparent information, communication and modalities for the exercise of the rights of the data subject . . . 7.The information to be provided to data subjects pursuant to Articles 13 and 14 may be provided in combination with standardised icons in order to give in an easily visible, intelligible and clearly legible manner a meaningful overview of the intended processing. Where the icons are presented electronically they shall be machine-readable.

-"Dispensation" for modelling the exception scenarios

Article 9 Processing of special categories of personal data 1.Processing of personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, or trade union membership, and the processing of genetic data, biometric data for the purpose of uniquely identifying a natural person, data concerning health or data concerning a natural person's sex life or sexual orientation shall be prohibited. 2.Paragraph 1 shall not apply if one of the following applies: (a) the data subject has given explicit consent to the processing of those personal data for one or more specified purposes, except where Union or Member State law provide that the prohibition referred to in paragraph 1 may not be lifted by the data subject;

-"Feature" for the sub-obligations

Article 12 Transparent information, communication and modalities for the exercise of the rights of the data subject 1.The controller shall take appropriate measures to provide any information referred to in Articles 13 and 14 and any communication under Articles 15 to 22 and 34 relating to processing to the data subject in a concise, transparent, intelligible and easily accessible form, using clear and plain language, in particular for any information addressed specifically to a child. The information shall be provided in writing, or by other means, including, where appropriate, by electronic means. When requested by the data subject, the information may be provided orally, provided that the identity of the data subject is proven by other means.

• We define additional relations for Asset-Constraint (e.g. pseudonymisation and encryption personal data), Party-Constraint (e.g. joint controllers) and Action-Constraint (e.g. direct marketing).

See more in the Best Practices draft wiki