The set of patterns provided here show how the terms defined in the Market Data Profile for ODRL should be combined to model the permissions, prohibitions, obligations, and constraints specified in the licenses controlling the use of market data.
The core intended audience for this document are the authors of ODRL policies and the implementors of systems interpreting them. The objective is to match the former's intentions with the latter's expectations.
In order to make sure we are compliant with our licensing, it is important to communicate to a user a clear understanding of their rights. If any activity to use data is permitted in ODRL, it is necessary to validate that any associated conditions are met and obligations fulfilled.
A valid Permission is defined in ODRL as the right to exercise an Action over an Asset.
To be valid, all the Permission's Constraints must be satisfied and Duties fulfilled.
A Permission effectively models a rights assignment in a license.
A user at ABC Bank Ltd has been granted access to use Dataset A in a display application only. Their access must be reported each quarter to Euro Exchange AG.
In licensing terms, this describes who is granting the rights and who is allowed to exercise them. The assignment may be restricted by location or entity, individual, or business function. It may also need to be qualified by who is excluded from the rights.
In ODRL, an assigner grants a right and the assignee exercises it.
Deciding which organisations, or who in an organisation, has the right to exercise a permission can be a complex calculation. The Market Data Profile for ODRL provides some support to help automate this determination of contract scope.
At its simplest, the rights transfer is to the licensee and its affiliated organisations. These can be explicitly listed in the contract.
We can model that by using the licensee property to identify the licensee and the includes property to create an approved list of affiliated organisations (each identified using a URI and preferably an LEI).
Sometimes affiliates qualify by meeting some condition. Usually, this is an ownership threshold.
Affiliates can then be dynamically identified by specifying the minimum holding required to qualify an organisation as an affiliate.
Some Parties may be explicitly excluded from the contract. This can be achieved by identifying them with the excludes property.
Often only parts of an organisation may exercise a permission. These may be locations, departments, business functions, trading desks, or individuals. The Market Data Profile for ODRL provides the locations, lines of business, and geography constraints to reflect the most common distinctions.
Furthermore, the Organisation Ontology provides the sub-organisation, unit, and member (for people) properties to further constrain the applicability of a permission.
The Market Data Profile for ODRL, however, does not seek to standardise the description of all these entities and requires only than they be identified by URIs.
An ESG data supplier is granting rights to ABC Bank Ltd and its majority owned affiliates to access their data in London only.
| Context: | When deciding which Parties can exercise a permission. |
|---|---|
| Definition: | Use the licensee property to identify the licensee. Use the includes property to make an explicit list of approved affiliates and the excludes property to list proscribed parties.Use the minimum holding property to specify the threshold to dynamically generate the affiliates list.Use the locations, lines of business, and geography constraints to segment parties. |
| Constraints: | md:licensee, md:includes, md:excludes, md:minHolding, locations, lines of business, geography |
Only the licensee
[] a odrl:Permission ;
odrl:assignee [
a odrl:Party ;
md:licensee <http://www.example.org/Organisation_A> ;
] ;
...
The licensee and a list of approved organisations
[] a odrl:Permission ;
odrl:assignee [
a odrl:Party ;
md:licensee <http://www.example.org/Organisation_A> ;
] , [
a odrl:Party ;
md:includes <http://www.example.org/Organisation_B> , <http://www.example.org/Organisation_C ; # Approved list
] ;
...
Only the French-based, buy-side operations of the licensee and its approved organisations
[] a odrl:Permission ;
odrl:assignee [
a odrl:Party ;
md:licensee <http://www.example.org/Organisation_A> ;
md:linesOfBusiness md:buySide ;
md:geography m49:250 ; # France
] , [
a odrl:Party ;
md:includes <http://www.example.org/Organisation_B> , <http://www.example.org/Organisation_C ; # Approved list
md:linesOfBusiness md:buySide ;
md:geography m49:250 ; # France
] ;
...
The licensee and those affiliates in which it is has a holding greater or equal to 50%, except Organisation T
[] a odrl:Permission ;
odrl:assignee [
a odrl:Party ;
md:licensee <http://www.example.org/Organisation_A> ;
] , [
a odrl:Party ;
md:minHolding 0.5 ;
md:excludes <http://www.example.org/Organisation_T> , <http://www.example.org/Organisation_C ; # Proscribed list
] ;
...
Only Trading Desk X
[] a odrl:Permission ;
odrl:assignee [
a odrl:Party ;
md:includes <http://www.example.org/TradingDesk_X> ;
] ;
...
This pattern models the case of an internal owner of data to distribute this to an external party. It can be expanded to identify what the recipient of the data is permitted to do with it once it is received.
Distribution occurs when an Internal Party (acting as a Provider) transfers an asset to an External Party.
It is a moment of great sensitivity to data owners and vendors, which is reflected in the licenses they agree with their subscribers.
When offering distribution permissions, data owners and vendors should apply a Next Policy duty to identify a Policy specifying the Permissions that third-party recipients can execute over the transferred asset.
ABC Bank Ltd is allowed to send data to ZYX Client Ltd but only for internal display.
| Context: | When Parties providing a Distribute action wish to control a third-party recipient's use of their Asset. |
|---|---|
| Definition: | Use a Next Policy duty to specify a policy controlling the third-party's use of the transferred asset. |
| Duty Action: | odrl:NextPolicy |
In the following example, Organisation A can ensure that if Organisation B distributes the asset A1 to an external party, they can only offer a Display permission to that third-party.
This distribution permission is granted by Organisation A ...
[] a odrl:Permission ;
md:assigner <http://www.example.org/Organisation_A> ;
md:assignee <http://www.example.org/Organisation_B> ;
odrl:action [ a md:Distribute ] ;
odrl:target ex:A1 ;
odrl:duty ex:D1 ;
...
... on the condition that any third-party receiving the asset ...
ex:D1 a odrl:Duty ;
md:subject <http://www.example.org/Organisation_B> ;
md:object [ a md:ExternalParty ] ;
odrl:action [ a odrl:NextPolicy ] ;
odrl:target ex:O1 .
... is offered by Organisation B only ...
ex:O1 a odrl:Offer ;
odrl:permission ex:P1 .
... a display permission
ex:P1 a odrl:Permission ;
md:assigner <http://www.example.org/Organisation_B> ;
md:assignee [ a md:ExternalParty ] ;
...
odrl:action [ a md:Display ] ;
odrl:target ex:A1 ;
...
The Offer Policy does not provide any executable permissions. In fact, the identity of any third-party is likely unknown when the license is agreed between Organisation A and Company B.
The offer instead provides a policy specification to which any future Agreement between Organisation B and third-parties must be compliant.
This pattern covers the use of data in non-display applications (versus display). In order to comply with non-display policies, it is necessary to identify the category or business purposes for which the data will be used, as they may incur separate fees for each purpose.
The Non-display action covers data use by machines (as opposed to people). It does not cover display nor distribution to third-parties. But it does cover everything else, including the Derive and Automated Trading actions.
Such various uses are frequently segmented by data providers by the purpose (i.e. business activity) that the use serves. This is captured using a purposes constraint on the action.
ABC Bank Ltd is using NDA Application 1 for the purpose of Automated Trading and NDA Application 2 for index creation. Both will need licensing and reporting to Euro Exchange AG.
| Context: | When a permission allows a Non-display action. |
|---|---|
| Definition: | Uses a purposes constraint on the action to specify the business activity that a permission supports. |
| Constraint: | md:purposes |
The purposes constraint specifies the activities in pursuit of which the permission can be exercised. To use the permission in support of any other activity would be non-compliant.
In the following examples, the permission P1 can only be used to calculate indices; P2 supports the maintenance and testing of a business continuity environment; and P3 allows automated trading but only as a broker.
Non-Display for the purposes of calculating indices
[] a odrl:Permission ;
...
odrl:action [
a md:Derive ;
md:purposes [ a md:CalculatingIndex ] ;
] ;
...
Non-Display for the purposes of maintaining and testing a business continuity environment.
[] a odrl:Permission ;
...
odrl:action [
a md:Non-Display ;
md:purposes [ a md:BusinessContinuity ] ;
] ;
...
Non-Display for the purposes of automated trading as a broker
[] a odrl:Permission ;
...
odrl:action [
a md:AutomatedTrading ;
md:purposes [ a md:Brokerage ] ;
] ;
...
Licenses often distinguish between derived data that still carries some informational traces of its source data and that which doesn't. The former is likely to be much more tightly controlled by a license than the latter.
The derivation type constraint on a Derive action allows us to distinguish between the two cases.
Its possible values, Irreversible and Non-Substitutive, together ensure that there is no "informational leakage" from the source dataset to the derived dataset.
When these two conditions are met, the IP in the derived dataset often belongs to the owner of the algorithm used to generate it, not to the owner of the source data. Such derived datasets (sometimes called new original works) are controlled by new permissions.
The use of a new original work may still be constrained by the Administrator of the source data using a NextPolicy duty to apply new, administrator-specified, permissions to the derived dataset.
If both conditions are not met, the derived dataset will likely still be controlled by the source dataset's permissions.
| Context: | When the type of derivation determines the permissions applicable to the derived dataset. |
|---|---|
| Definition: | Uses a derivation types constraint on the Action to specify the type of derivation performed. |
| Constraint: | md:derivationTypes |
The permission in the following example allows the derived dataset OP1 (identified by the output property) to be generated from the dataset A1 so long as the derivation is irreversible and non-substitutive.
[] a odrl:Permission ;
...
odrl:action [
a md:Derive ;
md:purposes [ a md:CalculatingIndex ] ;
md:derivationTypes [ a md:Irreversible , md:Non-Substitutive ] ;
] ;
odrl:target ex:A1 ;
odrl:output ex:OP1 ;
...
The Administrator of the source Asset can control the use of the derived asset by placing a Next Policy duty targeting the output of a Derive action.
| Context: | When a new asset is created through an irreversible and non-substitutive derivation. |
|---|---|
| Definition: | Uses a Next Policy duty to specify an Offer Policy controlling the use of the derived asset. |
| Duty Action: | odrl:NextPolicy |
The permission from the previous example now has a Next Policy Duty D2 that allows the distribution of the derived dataset OP1 under the permission P2.
The output of the derivation OP1 ...
[] a odrl:Permission ;
md:assigner <http://www.example.org/Source_Data_Administrator> ;
md:assignee <http://www.example.org/Data_Consumer> ;
odrl:action [
a md:Derive ;
md:purposes [ a md:CalculatingIndex ] ;
md:derivationTypes [ a md:Irreversible , md:Non-Substitutive ] ;
] ;
odrl:target ex:A1 ;
odrl:output ex:OP1 ;
odrl:duty ex:D2 ;
... is controlled by the policy O2 ...
ex:D2 a odrl:Duty ;
md:subject <http://www.example.org/Data_Consumer> ;
md:object <http://www.example.org/Data_Consumer> ;
odrl:action [ a odrl:NextPolicy ] ;
odrl:target ex:O2 .
... which provides the permission P2 ...
ex:O2 a odrl:Offer ;
odrl:permission ex:P2 .
... which allows OP1 to be distributed to third-parties
ex:P2 a odrl:Permission ;
md:assigner <http://www.example.org/Source_Data_Administrator> ;
md:assignee <http://www.example.org/Data_Consumer> ;
odrl:action [ a md:Distribute ] ;
odrl:target ex:OP1 ;
If the administrator wished to control the third-party's use of the index, then it could apply the Distribution Pattern described above.
Any use of a third-party service facilitator will likely need to be covered either by extending the rights of the sponsor or by the service facilitator itself agreeing to meet the licensing requirement.
A Service Facilitators's use of an asset is governed by one of two patters. Either they must use their own permissions or they can use the permissions of their client. The data license determines which pattern applies.
The distinction can be modelled with the users constraint. If a service facilitator can use their client's permissions, then they must be identified by the user constraint on those permissions.
Often the consent of the data originator is required before use by a Service Facilitator. The mechanics of this are described in the Request and Consent Pattern below.
ABC Bank Ltd is using the services of a calculation agent to calculate indices on their behalf. The calculation agent has licensing agreements in place with the data provider.
| Context: | When a service facilitator can use their client's permissions. |
|---|---|
| Definition: | Employ a users constraint on the client permission that identifies the service facilitator. |
| Constraint: | md:users |
The permission belonging to Organisation A in the following example can be used by Service Facilitator X. Such a permission would likely have a duty requiring the consent of the Administrator before Service Facilitator X could exercise the permission as discussed in the Request and Consent Pattern.
Without this users constraint, only the assignees of the permission (in this case, Organisation A) could exercise it. Service Facilitator X would need their own permission in which they were the assignee.
[] a odrl:Permission ;
md:assignee <http://www.example.org/Organisation_A> ;
md:users <http://www.example.org/Service_Facilitator_X> ;
...
Data providers may require entitlement controls, whether by individual user ID’s or through an entitlement tool like DACs, to ensure their data is protected and usage can be reported as required.
Providers are sensitive to the systems that control access to their data. Do they authenticate and authorise every user? Or do they at least uniquely identify them. This distinction is made by the Controls constraint.
They're also concerned by "line-of-sight": who is making the decisions about access. We can specify the responsible party by using the system provider property.
This question of system responsibility can reach down to the consuming application. For example, display permissions for vendor-managed terminals can be modelled by setting the vendor as the system provider on both the controls constraint (i.e the vendor manages access control) and the display action (i.e the vendor provides the display terminal).
A user at ABC Bank Ltd's request to access Dataset A must be permissioned via their entitlements system to ensure compliance with Euro Exchange AG's reporting requirements.
| Context: | When a provider wants to ensure that the technical infrastructure exists to protect their data. |
|---|---|
| Definition: |
Employ a controls constraint on the client permission to specify the level of access control required. Use the system provider property to indicate who is responsible for providing and controling the technical infrastucture behind an Activity. |
| Constraints: | md:controls , md:systemProvider |
The first permission simply requires all data access to be authenticated and authorised. The second requires the access controls to be managed by the data provider. The third models a vendor-supplied terminal.
Access must be authenticated and authorised:
[] a odrl:Permission ;
...
md:controls [
a md:CLosedUserGroup ;
] ;
...
Access must be authenticated and authorised by the vendor:
[] a odrl:Permission ;
...
odrl:controls [
a md:ClosedUserGroup ;
md:systemProvider <http://www.example.org/Vendor_A> ;
] ;
...
Vendor terminal display:
[] a odrl:Permission ;
...
odrl:controls [
a md:ClosedUserGroup ;
md:systemProvider <http://www.example.org/Vendor_A> ;
] ;
odrl:action [
a md:Display ;
md:systemProvider <http://www.example.org/Vendor_A> ;
] ;
...
White labelling is a form of distribution in which the recipient of derived data brands it as their own. It extends both the Distribution and the Derived Data patterns described above.
The derivations are usually done by a calculation agent or analytics provider who holds the licensing relationship with the Provider of the original data.
That provider will likely charge a permium for white label distribution. If the derivations are not irreversible and non-substitutive, they will also seek to protect their IP by applying controls or data host constraints on the third-party.
| Context: | When derived data is distributed to and branded by a third-party. |
|---|---|
| Definition: |
Extends both the Distribution and the Derived Data patterns. Provide a White Label distribution permission between the source data provider and derived data provider. Combine the controls and system provider constraints to indicate who is responsible for providing the technical infrastucture controlling the access to and use of the branded data. Use the data host constraint if the derived data provider is offering a white label platform. |
| Actions: | md:WhiteLabel |
| Constraints: | md:controls , md:systemProvider , md:dataHost |
In the first code example below, the provider of the source data allows the calculation agent to white label their derived data so long as the derivation is irreversible and non-substitutive.
The second permits the calulation agent to provide a white label platform for their derived data so long as the data is hosted and controlled by them. The derivations do not need to be irreversible and non-substitutive.
The output of the calulation agent's derivation OP2 ...
[] a odrl:Permission ;
md:assigner <http://www.example.org/Source_Data_Administrator> ;
md:assignee <http://www.example.org/Calculation_Agent> ;
odrl:action [
a md:Derive ;
md:purposes [ a md:CreatingTradedProduct ] ;
md:derivationTypes [ a md:Irreversible , md:Non-Substitutive ] ;
] ;
odrl:target ex:A1 ;
odrl:output ex:OP2 ;
odrl:duty ex:D3 ;
... is controlled by the policy O3 ...
ex:D3 a odrl:Duty ;
md:subject <http://www.example.org/Data_Consumer> ;
md:object <http://www.example.org/Data_Consumer> ;
odrl:action [ a odrl:NextPolicy ] ;
odrl:target ex:O3 .
... which provides the permission P3 ...
ex:O3 a odrl:Offer ;
odrl:permission ex:P3 .
... which allows OP2 to be white labelled to third-parties
ex:P3 a odrl:Permission ;
md:assigner <http://www.example.org/Source_Data_Administrator> ;
md:assignee <http://www.example.org/Calculation_Agent> ;
odrl:action [ a md:WhiteLabel ] ;
odrl:target ex:OP2 ;
The output of the calulation agent's derivation OP3 ...
[] a odrl:Permission ;
md:assigner <http://www.example.org/Source_Data_Administrator> ;
md:assignee <http://www.example.org/Calculation_Agent> ;
odrl:action [
a md:Derive ;
md:purposes [ a md:CreatingTradedProduct ] ;
md:derivationTypes [ a md:Irreversible , md:Non-Substitutive ] ;
] ;
odrl:target ex:A1 ;
odrl:output ex:OP3 ;
odrl:duty ex:D4 ;
... is controlled by the policy O4 ...
ex:D4 a odrl:Duty ;
md:subject <http://www.example.org/Data_Consumer> ;
md:object <http://www.example.org/Data_Consumer> ;
odrl:action [ a odrl:NextPolicy ] ;
odrl:target ex:O4 .
... which provides the permission P4 ...
ex:O4 a odrl:Offer ;
odrl:permission ex:P4 .
... which allows OP3 to be white labelled to third-parties whose use of the asset ...
ex:P4 a odrl:Permission ;
md:assigner <http://www.example.org/Source_Data_Administrator> ;
md:assignee <http://www.example.org/Calculation_Agent> ;
odrl:action [ a md:WhiteLabel ] ;
odrl:target ex:OP3 ;
odrl:duty ex:D5 ;
... is controlled by the policy O5 ...
ex:D5 a odrl:Duty ;
md:subject <http://www.example.org/Data_Consumer> ;
md:object <http://www.example.org/Data_Consumer> ;
odrl:action [ a odrl:NextPolicy ] ;
odrl:target ex:O5 .
... which provides the permission P5 ...
ex:O5 a odrl:Offer ;
odrl:permission ex:P5 .
... which allows the white label partner to display the derivations ...
... so long as the calculation agent hosts the data and controls access to it.
ex:P4 a odrl:Permission ;
md:assigner <http://www.example.org/Source_Data_Administrator> ;
md:assignee <http://www.example.org/Calculation_Agent> ;
odrl:controls [
a md:ClosedUserGroup ;
md:systemProvider <http://www.example.org/Calculation_Agent> ;
] ;
odrl:action [
a md:Display ;
md:systemProvider <http://www.example.org/Calculation_Agent> ;
] ;
odrl:target ex:OP3 .
A Duty is defined in ODRL as the obligation to exercise an Action.
The Party exercising the action is the Subject of the Duty. The Party affected is the Object.
If the specified action must be exercised more than once to fulfill the Duty, then the count constraint should be used to indicate the number of times the action must be taken.
A Duty may also specify a target to indicate the Entity to which the action applies.
Some duties can be activated by events. If so, the duty should specify its activation condition in the form of a constraint that when satisfied, activates the Duty.
Some duties may be activated by the passage of time. If so, the duty should specify its activation condition in the form of a time interval constraint (e.g. monthly) that when satisfied, activates the Duty.
Just eight types of Duty capture most of the obligations found in market data licenses: Attachments, Requests and Consents, Notifications, Invoices and Payments, Explicit Agreements, and Reporting.
Duties remain inactive until some condition is met. In most cases, this condition is specified by a Constraint on the Duty known as an activation condition. When the Constraint is satisfied, the Duty is activated and must be fulfilled.
Duties without an activation condition are simply activated when the Subject of the Duty exercises its Action.
There are two types of activation condition: those fired by the state-of-the world and those triggered by the passage of time.
Market data licenses are sensitive to two key changes:
Distribute PermissionUse Permission
Both can be modelled using Constraints which, if satisfied, activate their parent Duty.
The following Constraint triggers whenever new instances of the class External Party (i.e. any individuals or applications) become a recipient of the Asset.
md:recipients [ a md:ExternalParty ] ;
This activation condition is frequently used in the Attachment Pattern.
If we want an activation condition that triggers only when a new Organisation receives the data (and not for each individual belonging to that organisation), then we can extend the template by adding a unit of count so:
md:recipients [
a md:ExternalParty ;
odrl:unitOfCount org:Organization ;
] .
This activation condition is usually used in the Agreement Pattern and Notification Pattern.
The Constraints triggered by new users operate analogously to the recipient constraints above except that we use the users property. Usually, we're only interested in new Organisations:
md:users [
a md:InternalParty ;
odrl:unitOfCount org:Organization ;
] .
We can be more specific about the role of the Organisation. This activation condition is only triggered by Service Facilitators using a data Consumer's permissions:
md:users [
a md:ExternalParty ;
odrl:unitOfCount org:Organization ;
md:role [ a md:ServiceFacilitator ] ;
] ;
These activation conditions are used in the Notification Pattern.
Many activities required by Duties in market data licenses are activated by the clock or calendar. For example, reporting may need to be done monthly. Payment schedules are often similar.
If a duty is activated on a recurring interval of time (e.g. monthly or every 14 days), then the time interval property from the ODRL Common Vocabulary must be used to specify the interval.
The interval itself must be defined using the OWL Time Ontology. Often this is effected using its has XSD Duration property.
[] odrl:timeInterval [
a time:ProperInterval ;
time:hasXSDDuration "P1M"^^xsd:duration
] .
State Modifiers help manage the Deontic State of Duties.
Unless qualified by a state-modifier, Duties must be immediately Fulfilled on becoming Active else they fall into the Unfulfilled state (and so invalidating their parent Permission).
The deadline property provides a grace period in which the duty's Action can be exercised without it falling into the Unfulfilled state. The duty simply remains Active while the modifier holds. Of course, if the action is taken, then it immediately becomes Fulfilled.
Usually a state-modifier specifies an interval. The deadline may additionally specify a time reference from which the interval must be counted. Else, the countdown starts on activation.
When there are no activation conditions, the interval count property controls the number of times a duty's action may be exercised within a given time interval.
In this example, the Subject has 30 days to exercise a duty's Action before it becomes Unfulfilled.
Like time-based activation constraints, the interval must be defined using the OWL Time Ontology.
[] md:deadline [
a time:ProperInterval ;
time:hasXSDDuration "P30D"^^xsd:duration
] .
In this example, the Subject can exercise a duty's Action twice in a year
[] md:intervalCount [
a md:IntervalCount ;
time:hasXSDDuration "P1Y"^^xsd:duration
odrl:count 2
] .
Market data licenses can require Attributions, Disclaimers, or Proscriptions to be attached to data when it is transferred from one Party to another.
The wording of these could be specified in the policy using the wording property of the Attribution. Alternatively, a link to most recent wording should be provided using the url property.
| Definition: | Requires and specifies an Attribution, Disclaimer, or Proscription to be attached to the data whenever the recipient is an External Party. |
|---|---|
| Subject: | The Party that attaches the Attribution, Disclaimer, or Proscription - usually the Party making the transfer. |
| Object: | The Party that receives the Attribution, Disclaimer, or Proscription - usually the recipient of the transfer. |
| Action: | md:Attach |
| Target: | md:Attribution, md:Disclaimer, or md:Proscription |
| Target Properties: | md:wording - providing the wording of the attribution, disclaimer, or proscription; and/or schema:url - linking to the required wording. |
| Activation: | Third-party Recipient. |
Attribution duties require the Subject to attach a declaration of the IP Owner's title to the Asset.
The duty is usually activated when the Asset is transferred to a third-party, i.e. the recipient constraint is triggered by any instance of an External Party.
[] a odrl:Duty ;
md:subject <http://www.example.org/transferer> ;
md:object <http://www.example.org/recipient> ;
md:recipients [ a md:ExternalParty ] ; # Activation condition
odrl:action [
a md:Attach ;
] ;
odrl:target [
a md:Attribution ;
md:wording "The market data is the property of Chicago Mercantile Exchange Inc. or it’s licensors as applicable. All rights reserved, or otherwise licensed by Chicago Mercantile Exchange Inc."
] .
Disclaimers must sometimes be attached to derived data to clarify (usually distance) the relationship between the IP Owner of the source Asset and the derived Asset.
Disclaimer duties follow the same pattern as Attribution Duties except the value of the target property is now an Disclaimer
[] a odrl:Duty ;
md:subject <http://www.example.org/transferer> ;
md:object <http://www.example.org/recipient> ;
md:recipients [ a md:ExternalParty ] ; # Activation condition
odrl:action [
a md:Attach ;
] ;
odrl:target [
a md:Disclaimer ;
schema:url <http://www.example.org/disclaimer_wording>
] .
Proscriptions are written instructions on the use of an Asset that must sometimes be attached the Asset before its distribution.
When the instructions are legally binding, and must be formally agreed with the recipient, use the Agreement Pattern below instead of this one.
Proscription duties follow the same pattern as Attribution Duties except the value of the target property is now a Proscription
Some licenses require additional legally binding agreements to be in place before a Permission can be exercised. This requirement is captured in an Agreement Duty.
For example, a license from a data Provider (a.k.a. vendor) might require a license from the data Originator to be in place before usage can start. This is common in non-display use cases. The license required may be indicated by the url property.
Market data licenses can also require Proscriptions to be legally binding before an Asset can be transferred.
The wording of these can be specified in the policy using the wording property of the Proscription.
These duties are usually activated at the organisational level - when an organisation, not individual users, use or receive the Asset.
| Definition: | Requires and specifies a License or Proscription to be agreed in a legally binding manner. |
|---|---|
| Subject: | The Party that seeks the Agreement - usually the Party using or distributing the data. |
| Object: | The Party that accedes to the Agreement - usually the Originator of the data or its recipient. |
| Action: | md:Agree |
| Target: | md:License or md:Proscription |
| Target Properties: | md:wording - providing the wording of the proscription; and/or schema:url - linking to the wording of the proscription or to the license. |
| Activation: | Third-party Recipient , or New User. |
Agreement duties require the Subject to come to a legally binding agreement with the Object over the Target of the duty.
For when a License must be agreed before an Asset is used. Usually attached to a Permission from a Provider that requires direct licensing with the Originator.
[] a odrl:Duty ;
md:subject <http://www.example.org/consumer> ;
md:object <http://www.example.org/originator> ;
md:users [ # Activation condition
a odrl:Assignee ;
odrl:unitOfCount org:Organization ;
] ;
odrl:action [
a md:Agree ;
] ;
odrl:target [
a md:License ;
schema:url <http://www.example.org/license>
] .
For when a Proscription (or License) must be agreed before an Asset is transferred. Usually attached to a Permission that allows distribution of an Asset.
[] a odrl:Duty ;
md:subject <http://www.example.org/transferer> ;
md:object <http://www.example.org/recipient> ;
md:recipients [ # Activation condition
a md:ExternalParty ;
odrl:unitOfCount org:Organization ;
] ;
odrl:action [
a md:Agree ;
] ;
odrl:target [
a md:Proscription ;
md:wording "..."
] .
Data Originators and Providers sometimes require notification of particular events or changes in the state-of-the-world.
The type of change that triggers the Duty is specified using the an activation condition. Common use cases are when an Internal Party first exercises the Permission or when the Asset is accessed by an External Party (e.g. a Service Facilitator).
Frequently, it's the Provider (or Originator) that receives the notification.
| Definition: | Requires a Notification be sent when the activation condition is met. |
|---|---|
| Subject: | The Party that provides the notification - usually the Party playing the role of Data Consumer. |
| Object: | The Party that receives the Notification - usually the Party playing the role of data Originator or Provider. |
| Action: | md:Notify |
| Target: | md:Notification |
| Target Properties: | schema:url pointing to the URL/email that the notification must be posted; md:users, indicating the users that must be identified, or md:recipients, indicating the recipients. |
| Activation: | New User , or Third-party Recipient. |
Notification duties require the Subject to notify the Object of some change in the state-of-the-world.
Usage notification requires the Subject to notify the Object that they have started to use the Asset - i.e. when the parent Permission is first exercised. In the example below, the Provider must be notified when the parent permission is used at a new Location
A URL (or email) to the which the fulfilled notification rule can be posted should be provided as a property of the Notification.
The duty is activated when the users constraint is satisfied.
[] a odrl:Duty ;
md:subject <http://www.example.org/consumer> ;
md:object <http://www.example.org/provider> ;
md:users [ # Activation condition
a md:InternalParty ;
odrl:unitOfCount md:Location ;
] ;
odrl:action [ a md:Notify ] ;
odrl:target [
a md:Notification ;
md:users [
a md:InternalParty ;
odrl:unitOfCount md:Location ;
] ;
schema:url <http://www.example.org/rules/internal_party_notifications> ;
] .
External-Party notification requires the Subject to notify the Object that an External Party (usually playing the role of a Service Facilitator) is exercising the Permission and to identify them.
The duty is activated when the users constraint is satisfied.
The targeted Notification indicates that it requires the identifier for the Service Provider.
[] a odrl:Duty ;
md:subject <http://www.example.org/transferer> ;
md:object <http://www.example.org/provider> ;
md:users [ # Activation condition
a md:ExternalParty ;
odrl:unitOfCount org:Organization ;
md:role [ a md:ServiceFacilitator ] ;
] ;
odrl:action [
a md:Notify ;
odrl:target [
a md:Notification ;
schema:url <http://www.example.org/rules/service_facilitator_notifications>
md:users [
a md:ExternalParty ;
odrl:unitOfCount org:Organization ;
md:role [ a md:ServiceFacilitator ] ;
] ;
] .
This Notification Duty presupposes the Service Facilitator's right to use the Permission following notification.
To make this assumption explicit, the Permission should have a users constraint that allows Service Facilitators to exercise it (alongside Internal Parties).
Often this assumption is not true - Service Facilitators can not use the Consumer's Permission and must license separately. If so, an Agreement Duty should be applied targeting the required license.
Data Originators and Providers often require reports on the use of their Assets, especially for realtime data.
The Usage Report should indicate a URL (or email) to the which the report should be posted, and use the unit of count and time interval properties to indicate the type and period of usage that must be reported. Where reporting is multi-dimensional (e.g. reporting User IDs against Locations), the first dimension (e.g. Location) must be specified by the unit of count property while the second dimension (e.g. User ID) must be indicated by the secondary count property.
The duty is usually activated on a periodic constraint.
| Definition: | Requires a Usage Report be sent when the activation condition is met. |
|---|---|
| Subject: | The Party providing the usage report - usually the Party playing the role of Data Consumer. |
| Object: | The Party receiving the usage report - usually the Party playing the role of data Originator or Provider. |
| Action: | md:Report |
| Target: | md:UsageReport |
| Target Properties: | schema:url pointing to the URL/email that the report must be posted; odrl:unitOfCount specifying the unit of reporting (e.g. user, application, or location); md:secondaryCode the second dimension of reporting (if required); odrl:timeInterval specifying the time period covered by the report; and md:reportingCode identifying the product to be reported against. |
| Activation: | Usually Periodic. |
Reporting duties require the Subject to report to the Object their use of the Asset targeted by the parent Permission.
In this example, reporting User ID against Location must be done monthly, 30 days in arrears, under the reporting code SMGL2SSX.
[] a odrl:Duty ;
md:subject <http://www.example.org/consumer> ;
md:object <http://www.example.org/provider> ;
odrl:timeInterval [
a time:ProperInterval ;
time:hasXSDDuration "P1M"^^xsd:duration
] ;
md:deadline [
a time:ProperInterval ;
time:hasXSDDuration "P30D"^^xsd:duration
] ;
odrl:action [ a md:Report ] ;
odrl:target [
a md:UsageReport ;
md:reportingCode “SMGL2SSX” ;
odrl:unitOfCount [ a md:Location ] ;
md:secondaryCount [ a md:UserID ] ;
odrl:timeInterval [
a time:ProperInterval ;
time:hasXSDDuration "P1M"^^xsd:duration
] ;
schema:url <http://www.example.org/rules/reports> ] ;
] .
Some duties come in pairs. A Consent action is preceded by a Request action, i.e. consent should be requested.
Often consent is required for distribution to a third-party or use by a service provider. In these cases, the data Originator must provide the consent.
But there are also cases - like an Audit - where the consent of the Data Consumer is required (though withholding it would invalidate the parent permission).
| Definition: | Requires and specifies an Appeal that the Subject must request of the Object. |
|---|---|
| Subject: | The Party making the request - usually the Consumer, except in the case of Audits, where the Originator or Provider makes the request. |
| Object: | The Party that must consent to the request. |
| Action: | md:Request |
| Target: | md:Appeal |
| Target Properties: | schema:url pointing to the URL/email to which the appeal must be posted; and for transfers, the md:recipients who must be identified. |
| Activation: | For transfers, Third-party Recipient. If no activation condition is set (e.g. an audit request), at the discretion of the Subject. |
| Definition: | Requires and specifies an Appeal to which the Subject must consent. |
|---|---|
| Subject: | The Party to which the Appeal has been make. For redistribution, the Originator of the Asset to be distributed. For audits, the Consumer |
| Object: | The Party making the request. |
| Action: | md:Consent |
| Target: | md:Appeal |
| Target Properties: | schema:url pointing to the URL/email to which the consent must be posted; and for transfers, the md:recipients who must be identified. |
| Activation: | For transfers, Third-party Recipient. If no activation condition is set (e.g. an audit request), at the discretion of the Subject. |
Often consent is required for distribution to a third-party or to a service provider. In these cases, usually the data Originator must provide the consent.
This example presupposes that the Asset is being transferred to the Service Provider under a Distribution Permission and that the service provider will then use their own permissions to process the Asset. If the service provider were to use the Consumer's Use Permissions, no distribution is required, and the users constraint should be used in place of the md:recipients constraint.
[] a odrl:Duty;
md:subject <http://www.example.org/originator> ;
md:object <http://www.example.org/consumer> ;
md:recipients [ # Activation condition
a md:ExternalParty ;
odrl:unitOfCount org:Organization ;
md:roles [ a md:ServiceFacilitator ]
] ;
odrl:action [ a md:Consent ] ;
odrl:target [
a md:Appeal ;
schema:url <http://www.example.org/rules/service_facilitator_appeals>
md:recipients [
a md:ExternalParty ;
odrl:unitOfCount org:Organization ;
md:role [ a md:ServiceFacilitator ] ;
] ;
] ;
odrl:duty :R1 .
:R1 a odrl:Duty;
md:subject <http://www.example.org/consumer> ;
md:object <http://www.example.org/originator> ;
odrl:action [
a md:Request ;
] ;
odrl:target [
a md:Appeal ;
schema:url <http://www.example.org/rules/service_facilitator_appeals>
md:recipients [
a md:ExternalParty ;
odrl:unitOfCount org:Organization ;
md:role [ a md:ServiceFacilitator ] ;
] ;
] .
Audit requests require the consent of the data Consumer. Withholding this, however, may invalidate the parent Permission.
In this example, the deadline modifier gives the Consumer 30 days to consent.
The effective interval modifier limits the Originator to requesting an audit at most twice in a year.
If the request is on the basis of reasonable suspicion, then the basis property should be added to the Appeal indicating reasonable suspicion
[] a odrl:Duty;
md:subject <http://www.example.org/consumer> ;
md:object <http://www.example.org/originator> ;
md:deadline [
a time:ProperInterval ;
time:hasXSDDuration "P30D"^^xsd:duration
] ;
odrl:action [
a md:Consent ;
md:purposes [ a md:Audit ] ;
] ;
odrl:target [
a md:Appeal ;
schema:url <http://www.example.org/rules/audit_appeals> ;
] ;
odrl:duty :R1 .
:R1 a odrl:Duty;
md:subject <http://www.example.org/originator> ;
md:object <http://www.example.org/consumer> ;
md:intervalCount [
a md:IntervalCount ;
time:hasXSDDuration "P1Y"^^xsd:duration ;
odrl:count 2
] ;
odrl:action [
a md:Request ;
md:purposes [ a md:Audit ] ;
] ;
odrl:target [
a md:Appeal ;
schema:url <http://www.example.org/rules/audit_appeals>
] .
Like Requests and Consents, Invoice and Compensate duties form a pair. A Compensate action is preceded by a Invoice action, i.e. payments should be invoiced.
Each target a Payment that must specify the amount to be paid and currency. The latter should be specified using instances of the Wikidata Currency Class.
If applicable, the Payment must also indicate the unit of count.
| Definition: | Requires and specifies a Payment for which the Subject must invoice the Object. |
|---|---|
| Subject: | The Party raising the invoice - usually the Provider. |
| Object: | The Party that must make the Payment - usually the Consumer. |
| Action: | md:Invoice |
| Target: | md:Payment |
| Target Properties: | odrl:payAmount specifying the amount to be paid and odrl:unit indicating the currency of payment. |
| Activation: | Usually Periodic. |
| Definition: | Requires and specifies a Payment which the Subject must make to the Object. |
|---|---|
| Subject: | The Party that must make the payment. |
| Object: | The Party to which the payment is made. |
| Action: | odrl:Compensate |
| Target: | md:Payment |
| Target Properties: | odrl:payAmount specifying the amount to be paid; odrl:unit indicating the currency of payment; odrl:unitOfCount providing the unit of payment (e.g. per user); odrl:timeInterval specifying the time period covered by the payment. |
| Activation: | Usually Periodic with a deadline. |
In this example, the Consumer must pay the Provider $5,350.00 per month per consuming application, 30 days in arrears. The provider should invoice for this.
[] a odrl:Duty;
md:subject <http://www.example.org/consumer> ;
md:object <http://www.example.org/provider> ;
odrl:timeInterval [
a time:ProperInterval ;
time:hasXSDDuration "P1M"^^xsd:duration
] ;
md:deadline [
a time:ProperInterval ;
time:hasXSDDuration "P30D"^^xsd:duration
] ;
odrl:action [ a odrl:Compensate ] ;
odrl:target [
a md:Payment ;
odrl:payAmount 5350.00
odrl:unit <https://www.wikidata.org/wiki/Q4917>
odrl:unitOfCount [ a md:Application ] ;
odrl:timeInterval [
a time:ProperInterval ;
time:hasXSDDuration "P1M"^^xsd:duration
] ;
] ;
odrl:duty :R1 .
:R1 a odrl:Duty;
md:subject <http://www.example.org/provider> ;
md:object <http://www.example.org/consumer> ;
odrl:action [ a odrl:Invoice ] ;
odrl:target [
a md:Payment ;
odrl:payAmount 5350.00
odrl:unit <https://www.wikidata.org/wiki/Q4917>
odrl:unitOfCount [ a md:Application ] ;
odrl:timeInterval [
a time:ProperInterval ;
time:hasXSDDuration "P1M"^^xsd:duration
] ;
] .
Sometimes, for example, when an effective interval is being specified, we need to indicate interval than run from a specified data and/or to one. We rely on some properties from the Time Ontology to do so.
[] tpl:effectiveInterval [
a time:ProperInterval ;
time:hasBeginning [
time:time:inXSDDate "2020-01-01T00:00:00Z"^^xsd:dateTime
] .
time:hasEnd [
time:time:inXSDDate "2022-01-01T00:00:00Z"^^xsd:dateTime
] .
] .