The Market Data Profile for ODRL provides the additional vocabulary and semantics needed to express the rights and obligations controlling the use of market data using ODRL.
ODRL is a machine-readable Rights Expression Language. Capturing the rules and obligations contained in market data licenses in ODRL allows for the automated checking of compliance along the data supply chain.
This standard is conceived as a living document. The Market Data Profile for ODRL will continue to evolve as the data supply chain develops and the opportunities for automating compliance increase.
To balance future flexibility with present implementations, all terms defined in the profile are assigned permanent identifiers. Any changes to the definition of a term must be versioned under a new identifier.
Similarly, any changes to the ontology itself, including any term-level changes, must be versioned under a new identifier for the ontology.
Term-level changes should be identified using a two-part version number. Changes in the first part indicate a breaking change: a change in the extension of the term or in its logical relationships that could result in an incorrect decision if the old and new values are treated as equivalent.
Changes in the second part indicate a safe change: an editorial change that clarifies the concept that the term represents without changing its extension. The old and new values can be treated as equivalent for the purposes of making a compliance decision.
Terms may be deprecated by using OWL annotations. Term with newer versions should be deprecated. To ease the weight of legacy terms on implementors, policy writers are discouraged from using deprecated terms.
Under this scheme, the ontology itself can only be changed by adding, deprecating, or removing terms but not by altering them. To help implementors keep up-to-date, editors of this profile should package and publish sets of changes as a new version of the ontology. Again, a two-part version number is required.
Changes to the first part indicate that the new ontology contains new terms or breaking changes in existing terms. Changes to the second part alert both policy writers and processors to editorial changes without logical consequence.
To allow terms to be removed, policy writers must use the latest version of the ontology. Implementors are encouraged to publish their conformance to it.
The aim of this versioning strategy is to maximise the opportunities for “practical” compatibility when the implementation (i.e. processing) and instance data (i.e. the ODRL policies) are operating on different versions of the ontology. Failure is scoped to an individual decision at runtime and occurs only when a breaking term is met.
Once met, processing must stop. No sound decision can be made by an ODRL processor and responsibility for the decision lies beyond the system.
Intermediate artifacts (e.g. branches or beta releases) should be represented by a suffix consisting of a hyphen and free-form qualifier.
The Market Data Profile for ODRL operates within the context of the market data supply chain.
By market data, we mean the price and trade-related data for financial instruments (e.g. equity prices) and the data derived from it (e.g. indices). The supply chain is then the sum of the interactions between the parties creating, providing, and consuming market data.
To unlock the standard"s potential we must situate the profile within a metamodel that describes the entities, parties, and activities that define these interactions. They are of direct relevance to decisions on the compliant use of market data.
The data supply chain generates and consumes data. To track its progress, we need to distinguish
between the original information as it is created (e.g. on a trading venue) and the data as it is
traded and consumed (i.e. commercially packaged by timeliness, geography, or other dimension and
subject to rights and obligations). The former is a Source
and the latter is an
Asset
.
Definition: | A Source is a representation of the information as it is created and
recorded. |
---|---|
Version: | 0.9 |
Editorial Note: | Informationally complete: independent of all aspects of commercialisation and/or delivery such as timeliness, method of delivery, or book depth. |
Editorial Note: | An abstract concept. |
Label: | Source |
Identifier: | https://www.w3.org/community/md-odrl-profile#source-0-9 |
Sub-class Of: | prov:Entity |
Definition: | An Asset is some commodity (e.g. API calls, bandwidth, data) the use of
which is controlled by rights and obligations. |
---|---|
Version: | 0.9 |
Example: | In the context of market data, an Asset could be the the pricing and
trading data generated by the trade in one or more financial instruments on an
exchange, or indices derived from that data. |
Editorial Note: | Assets are sensitive to their means of delivery and informational
completeness. A real-time version of the data may be a different Asset
than the delayed version. Book depth too can distinguish between
Assets . |
Editorial Note: | Assets can be transformed through some calculation but still remain the
same Asset . It only becomes a new Asset through
calculation if the transformation is irreversible (i.e. the original data cannot be
recovered) and non-substitutive (i.e. the altered data cannot be used in place of
the original), thus creating a new Source which can then be packaged as
new Assets . |
Example: | The operation of currency conversion does not change the identity of an
Asset . |
Example: | Augmenting an Asset with additional symbology does not change the
identity of that Asset . |
Example: | Co-mingling Assets does not change the identities of the combined
Assets . |
Example: | Normalising an Asset does not change the identity of that
Asset . |
Label: | Asset |
Identifier: | https://www.w3.org/community/md-odrl-profile#asset-0-9 |
Sub-class Of: | prov:Entity , odrl:Asset |
Definition: | Identifies the Party playing the role of Provider in relation to
an Asset . |
---|---|
Version: | 0.9 |
Note: | To improve interoperability, the parties should be identified using
Legal Entity Identifiers [[LEI]] where possible. |
Label: | providers |
Identifier: | https://www.w3.org/community/md-odrl-profile#providers-0-9 |
Domain: | Asset |
Range: | odrl:Party |
In the example below the Asset :A1
is provided by the CME:
:A1 a md:Asset ; md:providers lei:LCZ7XYGSLJUHFXXNXD88 . # CME
Definition: | Identifies the Party that owns the intellectual property rights over an
Asset . |
---|---|
Version: | 0.9 |
Note: | Can be used to specifiy the IP owner of any derived works by qualifying the
output Asset of a Permission to Derive data.
|
Note: | To improve interoperability, the parties should be identified using
Legal Entity Identifiers [[LEI]] where possible. |
Label: | IP owners |
Identifier: | https://www.w3.org/community/md-odrl-profile#ipowners-0-9 |
Domain: | Asset |
Range: | odrl:Party |
In the example below the intellectual property rights over the Asset :A1
are
owned by the CME:
:A1 a md:Asset ; md:ipOwner lei:LCZ7XYGSLJUHFXXNXD88 . # CME
Definition: | Identifies the original Asset or Source that the
subject Asset refines. |
---|---|
Version: | 0.9 |
Editorial Note: | New Assets can be created by constraining and/or aggregating other
Assets or Sources . |
Label: | refines |
Identifier: | https://www.w3.org/community/md-odrl-profile#refines-0-9 |
Domain: | Asset |
Range: | Asset , Source |
In the example below the Asset :A2
is a Delayed
version of the
Asset :A1
:
:A2 a md:Asset ; md:refines :A1 ; md:timelinessOfDelivery [ a md::Delayed ] .
Definition: | Identifies a Compound ID that identifies a Source or
Asset in a manner that can be understood along the supply chain.
|
---|---|
Version: | 0.9 |
Label: | compound IDs |
Identifier: | https://www.w3.org/community/md-odrl-profile#compound-ids-0-9 |
Domain: | Source , Asset |
Range: | Compound ID |
The example below identifies the Eurodollar Futures Contract traded on Globex.
The many ways to describe Assets
that are of relevance to market data licenses are
enumerated in Constraints on Assets below.
Most of the Assets of interest to market data licenses describe the pricing and trading of
financial instruments. These instruments are traded at Venues
managed by
Exchanges
.
Knowing which venue generated a Source can help in tracing the rights and obligations that control the use of the data.
Definition: | An organisation that manages one or more Venues |
---|---|
Version: | 0.9 |
Note: | To improve interoperability, Exchanges should be identifed by their
operating MIC codes [[ISO10383]]. |
Label: | Exchange |
Identifier: | https://www.w3.org/community/md-odrl-profile#exchange-0-9 |
Definition: | A multilateral system in which multiple buying and selling interests can interact in a way that results in contracts. |
---|---|
Version: | 0.9 |
Scope Note: | Includes regulated markets; Organised Trading Facilities (OTF) and Multilateral Trading Facilities (MTFs) as defined in MiFID II; and Alternative Trading Systems (ATS) as defined by the SEC. [[ATS]] [[EXCHANGE]] [[MiFID]] [[ECN]] |
Note: | MIC codes [[ISO10383]] should be used to identify a specific
Venue . |
Note: | When Providing Trading Venues, reporting the number of venues on which an Asset is made available can decide data costs. |
Label: | Venue |
Identifier: | https://www.w3.org/community/md-odrl-profile#venue-0-9 |
Sub-class Of: | Units of Count |
Definition: | Identifies the Exchange operating the venue using
MIC market identifier codes, specifically the operating MIC code. [[ISO10383]] |
---|---|
Version: | 0.9 |
Label: | operating MIC code |
Identifier: | https://www.w3.org/community/md-odrl-profile#operatingmic-0-9 |
Domain: | Venue |
Range: | Operating MIC Code |
Definition: | Identifies the Venue using MIC market identifier codes, specifically the market MIC code. [[ISO10383]] |
---|---|
Version: | 0.9 |
Label: | MIC code |
Identifier: | https://www.w3.org/community/md-odrl-profile#miccode-0-9 |
Domain: | Venue |
Range: | MIC Code |
Sources in market data are rarely identified by universally unique identifiers (aka URIs) that can be understood along the supply chain. In the case of exchange data, however, they do have a product code that is unique to the specific Venue that generates the Source.
Combining these in a compound ID creates a unique identifier that can be understood by the supply chain.
Definition: | The combination of a context and an identifier
(that is unique within that context) to deliver a globally unique identifier. |
---|---|
Version: | 0.9 |
Editorial Note: | For market data, the context will usually be the Venue that generates the Source. |
Note: | Use the identifier property provided by DCMI Metadata Terms vocabulary. |
Label: | Compound ID |
Identifier: | https://www.w3.org/community/md-odrl-profile#compoundid-0-9 |
Sub-class Of: | prov:Entity |
Definition: | Identifies the context in which the specified identifier is unique. |
---|---|
Version: | 0.9 |
Label: | context |
Identifier: | https://www.w3.org/community/md-odrl-profile#context-0-9 |
Domain: | Compound ID |
Range: | Venue |
This example identifies the Eurodollar Futures Contract traded on Globex:
[] a md:CompoundID; md:context [ a md:Venue ; rdfs:label "Globex" ; md:operatingMic mic:XCME ; md:mic mic:GLBX ] ; dc:identifier. "GE" .
The rights and obligations controlling the use of data often require counting things (q.v. Report or Compensate duties).
Definition: | Things to be counted. |
---|---|
Version: | 0.9 |
Label: | Units of Count |
Identifier: | https://www.w3.org/community/md-odrl-profile#units-of-count-0-9 |
Sub-class Of: | prov:Entity |
In addition to Venues, we may also want to make a count of:
Definition: | An idenitifier for a user (human or machine) used for authenticated access to the Asset. |
---|---|
Version: | 0.9 |
Label: | User ID |
Identifier: | https://www.w3.org/community/md-odrl-profile#user-id-0-9 |
Sub-class Of: | Units of Count |
In the following Duty, usage must be reported by User ID
.
[] a odrl:Duty; ... odrl:action [ a md:Report ; odrl:unitOfCount md:UserID ] ; md:targets [ a md:Usage ] ; ...
Definition: | An idenitifier for a human user with authenticated access to the Asset. |
---|---|
Version: | 0.9 |
Example: | Also known as Access ID |
Label: | Person ID |
Identifier: | https://www.w3.org/community/md-odrl-profile#person-id-0-9 |
Sub-class Of: | User ID |
Definition: | An idenitifier for a machine user with authenticated access to the Asset. |
---|---|
Version: | 0.9 |
Label: | Machine ID |
Identifier: | https://www.w3.org/community/md-odrl-profile#machine-id-0-9 |
Sub-class Of: | User ID |
Definition: | Any mechanism (fixed or portable) that displays the Asset to an individual person. |
---|---|
Version: | 0.9 |
Scope Note: | Does not include wallboards or any other mechanisms that display to groups of people. |
Label: | Device |
Identifier: | https://www.w3.org/community/md-odrl-profile#device-0-9 |
Sub-class Of: | Units of Count, Display Type |
Definition: | Any mechanism (fixed or portable) that displays the Asset to groups of people or publicly. |
---|---|
Version: | 0.9 |
Scope Note: | As opposed to a Device that displays to an individual. |
Label: | Wallboard |
Identifier: | https://www.w3.org/community/md-odrl-profile#wallboard-0-9 |
Sub-class Of: | Units of Count, Display Type |
Definition: | Any person with access to the Asset. |
---|---|
Version: | 0.9 |
Label: | Person |
Identifier: | https://www.w3.org/community/md-odrl-profile#person-0-9 |
Sub-class Of: | Units of Count |
Definition: | The place (or site) at which the Asset is accessed. |
---|---|
Version: | 0.9 |
Label: | Location |
Identifier: | https://www.w3.org/community/md-odrl-profile#location-0-9 |
Sub-class Of: | Units of Count |
Definition: | A service provided by a Party that involves distributing an Asset to External Parties. |
---|---|
Version: | 0.9 |
Scope Note: | Applies to both the redistribution of third-party data (e.g. exchange data in the case of a bank) and the distribution of derived data (e.g. benchmarks and indices). |
Label: | Distribution Service |
Identifier: | https://www.w3.org/community/md-odrl-profile#distribution-service-0-9 |
Definition: | Identifies the Assets that are delivered in a
Distribution Service . |
---|---|
Version: | 0.9 |
Label: | provides |
Identifier: | https://www.w3.org/community/md-odrl-profile#provides-0-9 |
Domain: | Distribution Service |
Range: | Asset |
Parties play roles in ensuring the validity of Rules. To support the interoperability of Rules, they should be idenified using Legal Entity Identifier codes [[LEI]] where possible.
Market data licenses are very sensitive to who has access to the data they control. The key distinction is between Parties that belong to the Assignee (and its affiliated or enumerated companies) and those that don"t (aka third-parties).
We can capture this by "typing" Parties into Internal-type and External-type parties. This distinction is, of course, relative to the Assignee.
Furthermore, the rights and obligations applicable to the licensee can sometimes differ from those offered to their affiliates. So we must express the distinction too.
In distribution use cases, the type of recipient is often significant. We differentiate between
professional
, non-professional
, and educational
parties, and
between existing
and prospective clients
.
Definition: | The Licensing Party and its affiliated or enumerated organisations as
specified in the governing license. |
---|---|
Version: | 0.9 |
Scope Note: | Also covers the members of a banking group that licenses through an umbrella association. |
Label: | Internal Party |
Identifier: | https://www.w3.org/community/md-odrl-profile#internal-party-0-9 |
Sub-class Of: | odrl:Party |
Disjoint with: | External Party |
The following Permission can only be executed by Internal Parties
.
[] a odrl:Permission; ... md:users [ a md:InternalParty ] ; ...
Definition: | The Party that is the signatory of the governing license and is directly bound by it. |
---|---|
Version: | 0.9 |
Scope Note: | A narrower terms than Assignee as Licensing Party identifies
only the signatory, not all the parties bound by the rights and obligations assigned
under the license (the Assignees). |
Label: | Licensing Party |
Identifier: | https://www.w3.org/community/md-odrl-profile#licensing-party-0-9 |
Sub-class Of: | Internal Party |
Disjoint with: | Affiliated Party |
Definition: | The Parties designated as Assignees by virtue of their relationship
with the Licensing Party as specified and enumerated in the governing
license. |
---|---|
Version: | 0.9 |
Label: | Affiliated Party |
Identifier: | https://www.w3.org/community/md-odrl-profile#affiliated-party-0-9 |
Sub-class Of: | Internal Party |
Disjoint with: | Licensing Party |
Definition: | A Party that is neither the Licensing Party nor one of the
affiliated or enumerated organisations as specified by the governing license. |
---|---|
Version: | 0.9 |
Scope Note: | The opposite (i.e. set complement) of Internal Party |
Scope Note: | Captures the concept of third parties. |
Label: | External Party |
Identifier: | https://www.w3.org/community/md-odrl-profile#external-party-0-9 |
Sub-class Of: | odrl:Party |
Disjoint with: | Internal Party |
Definition: | A Party that is neither a Non-Professional Party nor an
Educational Party . |
---|---|
Version: | 0.9 |
Label: | Professional Party |
Identifier: | https://www.w3.org/community/md-odrl-profile#professional-party-0-9 |
Sub-class Of: | External Party |
Disjoint with: | Non-Professional Party , Educational Party , Existing Client Party , Prospective Client Party |
Definition: | A Party that is both a natural person (rather than a corporation, partnership, or other organisation) and acts only on their personal account. |
---|---|
Version: | 0.9 |
Scope Note: | Non-professional parties may not offer paid-for nor formal advice. |
Label: | Non-Professional Party |
Identifier: | https://www.w3.org/community/md-odrl-profile#non-professional-party-0-9 |
Sub-class Of: | External Party |
Disjoint with: | Professional Party , Educational Party , Existing Client Party , Prospective Client Party |
Definition: | A formally accredited educational institution using market data solely for the purpose of education or training. |
---|---|
Version: | 0.9 |
Label: | Educational Party |
Identifier: | https://www.w3.org/community/md-odrl-profile#educational-party-0-9 |
Sub-class Of: | External Party |
Disjoint with: | Non-Professional Party , Professional Party , Existing Client Party , Prospective Client Party |
Definition: | A Party that is a current consumer of Distribution Services provided by the Assignee. |
---|---|
Version: | 0.9 |
Label: | Existing Client Party |
Identifier: | https://www.w3.org/community/md-odrl-profile#existing-client-party-0-9 |
Sub-class Of: | External Party |
Disjoint with: | Non-Professional Party , Professional Party , Educational Party , Prospective Client Party. |
Definition: | A Party that the Assignee is engaging with in order to procure such Party as a consumer of Distribution Services provided by the Assignee. |
---|---|
Version: | 0.9 |
Label: | Prospective Client Party |
Identifier: | https://www.w3.org/community/md-odrl-profile#prospective-client-party-0-9 |
Sub-class Of: | External Party |
Disjoint with: | Non-Professional Party , Professional Party , Educational Party , Existing Client Party. |
Party Roles describe the part a Party (or set of Parties) plays as a data Asset moves along the market data supply chain.
Many Parties play different roles at different times. A large financial institution regularly acts
as an Originator
, Administrator
, Provider
, and
Consumer
of data assets.
In the example of an Exchange delivering an Asset to a vendor for onward distribution to a bank, the sequence of parties and their roles would look as follows:
Originator
assigns rights and as a Provider
delivers data to the vendor, acting as a Consumer
.
Administrator
, assigns rights, and as a
Provider
, delivers data to the bank, acting as a Consumer
.
Administrator
, then assigns rights
and, acting as a Provider
, delivers data to its end users, who are
Consumers
of the data.
Note: the rights and obligations controlling the use of the Asset could be changed by the vendor (and those controlling the use of the derived data by the bank) so long as the new rights and obligations are conpliant (i.e. at least as strict) as the original ones specified by the Originator.
Definition: | Abstract class that acts as the super-class for the concrete Roles played by Parties in the market data supply chain in relation to an Asset |
---|---|
Version: | 0.9 |
Label: | Party Role |
Identifier: | https://www.w3.org/community/md-odrl-profile#party-role-0-9 |
Definition: | The role a Party plays in creating a Source and acting as an Assigner of the rights and obligations controlling its commercialisation and use. |
---|---|
Version: | 0.9 |
Scope Note: | Applies to all Parties (not just exchanges) deriving or curating a new creative work and acting as the Assigner for this work. |
Note: | Originators may use an Administrator to manage their rights assignments
and a Service Facilitator to destribute the data. |
Label: | Originator |
Identifier: | https://www.w3.org/community/md-odrl-profile#originator-0-9 |
Sub-class Of: | Party Role |
In Range Of: | role |
We can imagine an Originator so:
Definition: | The role a Party plays in delivering and/or or providing access to an
Asset for Consumers . |
---|---|
Version: | 0.9 |
Scope Note: | Designates the role a vendor plays in providing data to its customers. |
Scope Note: | Describes the role the market data function within a financial institution plays in providing data to its internal customers. |
Scope Note: | The rights and obligations controlling the use of the Asset are supplied by
the Administrator or Originator . |
Label: | Provider |
Identifier: | https://www.w3.org/community/md-odrl-profile#provider-0-9 |
Sub-class Of: | Party Role |
In Range Of: | role |
We can imagine a Provider so:
Definition: | The role a Party plays in receiving an Asset and acting as the Assignee of the rights and obligations controlling the use of that Asset. |
---|---|
Version: | 0.9 |
Scope Note: | Designates the role a vendor or market data function within an organisation plays in
receiving data from its Providers and the rights and obligations
controlling its use from their Adminstrators . |
Scope Note: | Describes the role the end-user of market data (e.g. trading desk or back office) plays in using the data provided to it. |
Label: | Consumer |
Identifier: | https://www.w3.org/community/md-odrl-profile#consumer-0-9 |
Sub-class Of: | Party Role |
In Range Of: | role |
We can imagine a Consumer so:
Definition: | The role an external organisation plays when contracted by the Assignee to deliver a business function using the assignee's data access rights. |
---|---|
Version: | 0.9 |
Scope Note: | Covers third-parties assisting in the delivery of data services for the Assignee such as generating derived data or distributing data. |
Scope Note: | Includes the activities of a 'calculating agent'. |
Note: | When a Service Facilitator is used to create new original works, the Assignee, who
owns the IP in the new data product, should be considered the
Originator as it is they who can assign rights over it. |
Label: | Service Facilitator |
Identifier: | https://www.w3.org/community/md-odrl-profile#service-facilitator-0-9 |
Sub-class Of: | Party Role |
In Range Of: | role |
We can imagine a Service Facilitator so:
Assignees frequently require notification of (or consent for) the
use of a Service Facilitator
. We can model this as a notification (or request
consent) Duty where the Notify action is taken on a per-service provider basis.
[] a odrl:Duty; ... odrl:action [ a md:Notify ; odrl:unitOfCount [ a md:ExternalParty ; md:roles [ a md:ServiceFacilitator ] ] ; ] . ...
Definition: | The role an organisation plays in assisting in the the assignment or management of rights. |
---|---|
Version: | 0.9 |
Label: | Administrator |
Identifier: | https://www.w3.org/community/md-odrl-profile#administrator-0-9 |
Sub-class Of: | Party Role |
In Range Of: | role |
We can imagine an administrator so:
Definition: | Specifies the supply-chain Party Role (s) played by a Party in
relation to a data Asset. |
---|---|
Version: | 0.9 |
Label: | roles |
Identifier: | https://www.w3.org/community/md-odrl-profile#roles-0-9 |
Domain: | odrl:Party |
Range: | Party Role |
An Activity is something that occurs over a period of time and acts upon or with Entities. An activity has a start time and an end time; can be influenced or informed by other activities; and can be generated by something. It"s a concept central to tracking provenance.
We can usefully connect rights and provenance by identifying the activities that are of significance in
market data licenses. The actual use and processing of data (Usage
) is one example. The
implementation of access control policies (Controls
) is another.
Reasonable Suspicion
, a trigger for Audit
activities, also shares the above
properties, and so can usefully be modelled as an activity.
Definition: | The Assignee"s access to and processing of the Asset. |
---|---|
Version: | 0.9 |
Label: | Usage |
Identifier: | https://www.w3.org/community/md-odrl-profile#usage-0-9 |
Sub-class Of: | prov:Activity |
Disjoint with: | Audit , Reasonable Suspicion , Control , Derivation |
Definition: | Computing an index value based on the performance of an identified set of constituents. |
---|---|
Version: | 0.9 |
Label: | Calculating Index |
Identifier: | https://www.w3.org/community/md-odrl-profile#calculating-index-0-9 |
Sub-class Of: | Usage |
Disjoint with: | Creating Traded Product , Trading , Training , Technical Support , Data Management , Product Development , Marketing , Business Continuity , Regulatory Requirement |
Definition: | To create financial instruments (e.g. derivatives) in order to then trade them. |
---|---|
Version: | 0.9 |
Label: | Creating Traded Product |
Identifier: | https://www.w3.org/community/md-odrl-profile#creating-traded-product-0-9 |
Sub-class Of: | Usage |
Disjoint with: | Calculating Index , Trading , Training , Technical Support , Data Management , Product Development , Marketing , Business Continuity , Regulatory Requirement |
Definition: | The activity of buying and selling financial instruments. |
---|---|
Version: | 0.9 |
Label: | Trading |
Identifier: | https://www.w3.org/community/md-odrl-profile#trading-0-9 |
Sub-class Of: | Usage |
Disjoint with: | Calculating Index ,Creating Traded Product , Training , Technical Support , Data Management , Product Development , Marketing , Business Continuity , Regulatory Requirement |
Definition: | Providing a Venue/trading platform on which buy and sell orders from multiple parties are matched |
---|---|
Version: | 0.9 |
Scope Note: | Broker crossing networks and dark pools are examples of alternative trading systems (ATS), and are thus trading platforms. |
Scope Note: | Includes alternative trading systems (ATS) as defined by 300a of the SEC regulation on Alternative Trading Systems [[ATS]]: any organization, association, person, group of persons, or system that constitutes, maintains, or provides a market place or facilities for bringing together purchasers and sellers of securities or for otherwise performing with respect to securities the functions commonly performed by a stock exchange. |
Scope Note: | Includes multilateral trading facilities (MTF) as defined in MiFID II [[MiFID]]: multilateral systems, operated by an investment firm or a market operator, which bring together multiple third-party buying and selling interests in financial instruments (in the system and in accordance with non- discretionary rules) in a way that results in a contract. |
Scope Note: | Includes organised trading facilities (OTF) as defined in MiFID II [[MiFID]]: multilateral systems which are not a regulated market or an MTF and in which multiple third-party buying and selling interests in bonds, structured finance products, emission allowances, or derivatives are able to interact in the system in a way that results in a contract. |
Scope Note: | Includes systematic internalization (SI) as defined in MiFID II [[MiFID]]: dealing on an organised, frequent, systematic, and substantial basis on one"s own account when executing client orders outside a regulated market, an MTF, or an OTF, without operating a multilateral system. |
Scope Note: | Includes any exchange registered as a National Securities Exchange (as defined in Section 3(a)(1) of the Exchange Act [[EXCHANGE]]) |
Scope Note: | Includes any Electronic Communications Network (as defined by Rule 600(b)(23) of Regulation NMS [[ECN]]) |
Note: | As trading venues, the trading platforms described here may well have mic codes associated with them. |
Label: | Providing Trading Venue |
Identifier: | https://www.w3.org/community/md-odrl-profile#providing-trading-venue-0-9 |
Sub-class Of: | Trading |
Disjoint with: | Trading as Principal , Brokerage |
Definition: | Trading on behalf of the firm’s own accounts, not on behalf of a client. |
---|---|
Version: | 0.9 |
Scope Note: | Market making is considered to be trading as principal. |
Example: | Proprietary trading. |
Example: | Trading firms. |
Label: | Trading as Principal |
Identifier: | https://www.w3.org/community/md-odrl-profile#trading-as-principal-0-9 |
Sub-class Of: | Trading |
Disjoint with: | Providing Trading Venue , Brokerage |
The following Permission allows the user to trade automatically as
principal
(using a purpose constraint).
[] a odrl:Permission; ... odrl:action [ a md:TradeAutomatically ; md:purpose [ a md:TradingAsPrincipal ] ] ; ...
Definition: | Acting on behalf of another person’s name and for another person’s account or acting in one’s own name and for another person’s account (i.e. trading to execute orders on behalf of clients). |
---|---|
Version: | 0.9 |
Scope Note: | Offering smart order routing is considered facilitating customer business. |
Label: | Brokerage |
Identifier: | https://www.w3.org/community/md-odrl-profile#brokerage-0-9 |
Sub-class Of: | Trading |
Disjoint with: | Providing Trading Venue , Trading as Principal |
Definition: | Training the Assignee’s users or subscribers in the use of a Distribution Service |
---|---|
Version: | 0.9 |
Label: | Training |
Identifier: | https://www.w3.org/community/md-odrl-profile#training-0-9 |
Sub-class Of: | Usage |
Disjoint with: | Calculating Index ,Creating Traded Product , Trading , Technical Support , Data Management , Product Development , Marketing , Business Continuity , Regulatory Requirement |
Definition: | The provision of technical assistance (by support staff) relating only to performance issues. |
---|---|
Version: | 0.9 |
Scope Note: | Excludes assistance in placing or adjusting an order. |
Label: | Technical Support |
Identifier: | https://www.w3.org/community/md-odrl-profile#technical-support-0-9 |
Sub-class Of: | Usage |
Disjoint with: | Calculating Index ,Creating Traded Product , Trading , Training , Data Management , Product Development , Marketing , Business Continuity , Regulatory Requirement |
Definition: | Oversight by support staff of internal data quality control and assurance (i.e., monitoring systems to ensure an accurate flow of data). |
---|---|
Version: | 0.9 |
Scope Note: | Covers quality assurance and administration. |
Scope Note: | Excludes assistance in placing or adjusting an order. |
Label: | Data Management |
Identifier: | https://www.w3.org/community/md-odrl-profile#data-management-0-9 |
Sub-class Of: | Usage |
Disjoint with: | Calculating Index ,Creating Traded Product , Trading , Training , Technical Support , Product Development , Marketing , Business Continuity , Regulatory Requirement |
Definition: | Developing new Distribution Services or further developing existing ones |
---|---|
Version: | 0.9 |
Label: | Product Development |
Identifier: | https://www.w3.org/community/md-odrl-profile#product-development-0-9 |
Sub-class Of: | Usage |
Disjoint with: | Calculating Index ,Creating Traded Product , Trading , Training , Technical Support , Data Management , Marketing , Business Continuity , Regulatory Requirement |
Definition: | Marketing Distribution Services to potential users or subscribers. |
---|---|
Version: | 0.9 |
Label: | Marketing |
Identifier: | https://www.w3.org/community/md-odrl-profile#marketing-0-9 |
Sub-class Of: | Usage |
Disjoint with: | Calculating Index ,Creating Traded Product , Trading , Training , Technical Support , Data Management , Product Development , Business Continuity , Regulatory Requirement |
Definition: | Demonstrating Distribution Services to potential users or subscribers. |
---|---|
Version: | 0.9 |
Editorial Note: | Demonstrations are time limited activities. Demonstrations in a public forum must be at time-limited events like conferences or trade shows. |
Label: | Demonstrations |
Identifier: | https://www.w3.org/community/md-odrl-profile#demonstrations-0-9 |
Sub-class Of: | Marketing |
Definition: | Maintaining and testing a business continuity environment. |
---|---|
Version: | 0.9 |
Note: | If the business continuity environment becomes the live environment, then the normal permission must be used to execute business, not this one. |
Label: | Business Continuity |
Identifier: | https://www.w3.org/community/md-odrl-profile#business-continuity-0-9 |
Sub-class Of: | Usage |
Disjoint with: | Calculating Index ,Creating Traded Product , Trading , Training , Technical Support , Data Management , Product Development , Marketing , Regulatory Requirement |
Definition: | Activities undertaken solely for the purposes of satisfying regulatory requirements. |
---|---|
Version: | 0.9 |
Label: | Regulatory Requirement |
Identifier: | https://www.w3.org/community/md-odrl-profile#regulatory-requirement-0-9 |
Sub-class Of: | Usage |
Disjoint with: | Calculating Index ,Creating Traded Product , Trading , Training , Technical Support , Data Management , Product Development , Marketing , Business Continuity |
This Permission allows the user to store and display the data only for the
purposes of satisfying a regulatory requirement
.
[] a odrl:Permission; ... odrl:action [ a md:Store , md:Display ; md:purpose [ a md:RegulatoryRequirement ] ] ; ...
Definition: | An examination of the Assignee's use of the Asset and/or the systems involved in its receipt, use, and distribution, for the purpose of determining the Assingee's compliance to the controlling license. |
---|---|
Version: | 0.9 |
Label: | Audit |
Identifier: | https://www.w3.org/community/md-odrl-profile#audit-0-9 |
Sub-class Of: | prov:Activity |
Disjoint with: | Usage , Reasonable Suspicion , Control , Derivation |
Definition: | A reasonable suspicion that the Assignee is misusing the Asset. |
---|---|
Version: | 0.9 |
Label: | Reasonable Suspicion |
Identifier: | https://www.w3.org/community/md-odrl-profile#reasonable-suspicion-0-9 |
Sub-class Of: | prov:Activity |
Disjoint with: | Usage ,Audit , Control , Derivation |
Definition: | The access control measures that manage the availability of the Asset to the Assignee"s users and processes. |
---|---|
Version: | 0.9 |
Label: | Control |
Identifier: | https://www.w3.org/community/md-odrl-profile#control-0-9 |
Sub-class Of: | prov:Activity |
Disjoint with: | Usage ,Audit , Reasonable Suspicion , Derivation |
Definition: | Control that ensures that only uniquely identified users can access the Asset. |
---|---|
Version: | 0.9 |
Note: | Covers both human and machine access. |
Label: | Restricted User Group |
Identifier: | https://www.w3.org/community/md-odrl-profile#restricted-user-group-0-9 |
Sub-class Of: | Control |
Definition: | Control that ensure that only authenticated and authorised users can access the Asset. |
---|---|
Version: | 0.9 |
Label: | Closed User Group |
Scope Note: | Usually effected by an entitlements system. |
Identifier: | https://www.w3.org/community/md-odrl-profile#closed-user-group-0-9 |
Sub-class Of: | Restricted User Group |
For usage, see Example 11.
Definition: | The processes by which an Asset (or assets) is transformed into a new asset through calculation. |
---|---|
Version: | 0.9 |
Label: | Derivation |
Identifier: | https://www.w3.org/community/md-odrl-profile#derivation-0-9 |
Sub-class Of: | prov:Activity |
Disjoint with: | Usage ,Audit , Reasonable Suspicion , Control |
Definition: | A derivation activity that uses calculations that cannot be perfomred in reverse (i.e., the source Asset cannot be reverse engineered from the derived asset). |
---|---|
Version: | 0.9 |
Label: | Irreversible Derivation |
Identifier: | https://www.w3.org/community/md-odrl-profile#irreversible-0-9 |
Sub-class Of: | Derivation |
Definition: | The derived asset cannot be used in the place of the source asset (i.e., cannot substitute for it in any calculations). |
---|---|
Version: | 0.9 |
Label: | Non-Substitutive Derivation |
Identifier: | https://www.w3.org/community/md-odrl-profile#non-substitutive-0-9 |
Sub-class Of: | Derivation |
The following Permission allows the user to derive indices so long as the
derivations are Irreversible
and Non-Substitutive
.
[] a odrl:Permission; ... odrl:action [ a md:Derive ; md:purpose [ a md:CalculateIndex ] ; md:derivationTypes [ a md:Irreversible ] , [ a md:Non-Substitutive ] ; ] ; ...
Definition: | The Party that provides and controls the technical infrastucture that implements an Activity. |
---|---|
Version: | 0.9 |
Label: | System Provider |
Identifier: | https://www.w3.org/community/md-odrl-profile#system-provider-0-9 |
Domain: | prov:Activity |
Range: | odrl:Party |
Vendor terminals can be modelled by specifying the access control system and display systems as being managed by the Provider. If no data is stored locally, the data host constraint should also be set.
[] a odrl:Permission; ... odrl:controls [ a md:ClosedUserGroup ; md:systemProvider [ a md:Provider ] ; ] ; odrl:action [ a md:Display ; md:systemProvider [ a md:Provider ] ; ] ; ...
Valid Permissions allow the specified Actions to be taken over their target Asset.
Validity requires all active Duties be fulfilled and all Constraints satisfied.
Permission functions specify the role a Party plays in a Permission
.
Definition: | Specifies the Party that is the signatory to the license and is directly bound by it. |
---|---|
Version: | 0.9 |
Label: | licensee |
Identifier: | https://www.w3.org/community/md-odrl-profile#licensee-0-9 |
Sub-Property Of: | Assignee |
Domain: | odrl:Permission |
Range: | odrl:Party |
Definition: | Provides an enumerated list of the affiliates of the licensee who are associated with the license through their relationship with the licensee. |
---|---|
Version: | 0.9 |
Note: | The relationship is usually one involving a percentage of ownership; in many cases, the Provider specifies the minimum percentage required for an entity to be considered an Affilliate. |
Note: | Usually the same rules apply to both the licensee and its affiliates. But a recipients constraint can be used to enforce any differences. |
Label: | affiliates |
Identifier: | https://www.w3.org/community/md-odrl-profile#affiliates-0-9 |
Sub-Property Of: | Assignee |
Domain: | odrl:Permission |
Range: | odrl:Party |
Definition: | To supply an Asset to a Party. |
---|---|
Version: | 0.9 |
Scope Note: | Redistribution is the case where the Asset is transferred to a third party. In this case, the recipients constraint can be set to External Party. |
Note: | The recipient's use of the Asset can be controlled by using a duty to impose a Next Policy that specifies the Permissions, Prohibitions, and/or Duties to which the recipient must adhere in their use of the asset. |
Label: | Distribute |
Identifier: | https://www.w3.org/community/md-odrl-profile#distribute-0-9 |
Sub-class Of: | odrl:Action, prov:Activity |
Definition: | To copy an Asset and then supply it to a Party. |
---|---|
Version: | 0.9 |
Scope Note: | Usually applied to documents, parts of documents, charts, or similarly formatted artifacts. |
Label: | Reproduce |
Identifier: | https://www.w3.org/community/md-odrl-profile#reproduce-0-9 |
Sub-class Of: | odrl:Distribute, |
Definition: | To create a tangible and permanent rendition of an Asset. |
---|---|
Version: | 2.2 |
Conforms To: | ODRL Common Vocabulary |
Scope Note: | For example, creating a permanent, fixed (static), and directly perceivable representation of the Asset, such as printing onto paper. |
Note: | Exercising this action can be used as a unit-of-count. |
Label: | |
Identifier: | https://www.w3.org/TR/odrl-vocab/#term-print |
Sub-class Of: | Reproduce, Units of Count |
Definition: | To format an Asset - usually a document - for presentational purposes. |
---|---|
Version: | 0.9 |
Scope Note: | A Prohibition on formatting a document would mean that it must be presented "as is". |
Label: | Format |
Identifier: | https://www.w3.org/community/md-odrl-profile#format-0-9 |
Sub-class Of: | Reproduce |
Definition: | To store an Asset for future use (including distribution). |
---|---|
Version: | 0.9 |
Label: | Store |
Identifier: | https://www.w3.org/community/md-odrl-profile#store-0-9 |
Sub-class Of: | odrl:Action, prov:Activity |
Definition: | To download an Asset to store and use it with a local application. |
---|---|
Version: | 0.9 |
Scope Note: | Applicable in the context of terminal use. |
Note: | Exercising this action can be used as a unit-of-count. |
Label: | Download |
Identifier: | https://www.w3.org/community/md-odrl-profile#download-0-9 |
Sub-class Of: | Action, Units of Count |
Definition: | To transform an Asset into a different format without changing its informational content. |
---|---|
Version: | 0.9 |
Scope Note: | Describes converting an Asset into a different format for consumption by a system. |
Label: | Transform |
Identifier: | https://www.w3.org/community/md-odrl-profile#transform-0-9 |
Sub-class Of: | Action |
Definition: | Use of an Asset in any way by an Internal Party. |
---|---|
Version: | 0.9 |
Scope Note: | Allows for both human and machine use of an Asset. Use Display if only human use is allowed; Non-Display for machine use. |
Scope Note: | Does not permit the distribution of an Asset to an External Party. |
Note: | Often constrained by the purpose (e.g Trading, Marketing) for which the Asset is used. |
Label: | Use |
Identifier: | https://www.w3.org/community/md-odrl-profile#use-0-9 |
Sub-class Of: | odrl:Action, prov:Activity |
Super-class Of: | Display, Non-Display |
Definition: | To view an Asset via a graphical user interface, device, or other display medium. |
---|---|
Version: | 0.9 |
Scope Note: | Applicable to human as opposed to machine use of an Asset. |
Note: | Can be constrained to individual display by setting display types to Device, or, for public display, to Wallboard. |
Synonyms: | View |
Label: | Display |
Identifier: | https://www.w3.org/community/md-odrl-profile#display-0-9 |
Sub-class Of: | Use |
Definition: | Machine use of an Asset to automate any process except Display or Distribution. |
---|---|
Version: | 0.9 |
Scope Note: | If the Asset is to be seen, then a seperate permission to Display is required. |
Example: | Automated valuations. |
Example: | Calculating risk figures. |
Example: | Profit and loss calculations. |
Example: | Benchmarking. |
Example: | Automated risk management and position exciting functions. |
Example: | Quantitative analysis. |
Example: | Portfolio management. |
Example: | Fund administration. |
Example: | Operations control programs. |
Example: | Investment analysis. |
Example: | Surveillance programs. |
Label: | Non-Display |
Identifier: | https://www.w3.org/community/md-odrl-profile#non-display-0-9 |
Sub-class Of: | Use |
Super-class Of: | Trade Automatically, Derive |
Definition: | To use an Asset in an automated trading system. |
---|---|
Version: | 0.9 |
Note: | The distinction between trading as a principal, as a broker, or providing a platform can be specidied using a purpose constraint. |
Example: | Semi-automated or automated order/quote generation. |
Example: | Order pegging. |
Example: | Systematic internalisation. |
Example: | Price referencing for trading purposes. |
Example: | Mid-point trading. |
Example: | Smart order routing to facilitate trading. |
Example: | Market making. |
Example: | Execution management. |
Example: | Quoting and trading of financial derivatives. |
Label: | Trade Automatically |
Identifier: | https://www.w3.org/community/md-odrl-profile#trade-automatically-0-9 |
Sub-class Of: | Non-Display |
Definition: | To generate new data from an Asset using a mathematical, logical, or other type of transformation, e.g. arithmetic formula, composition, or aggregation. |
---|---|
Version: | 0.9 |
Scope Note: | Includes performing analytics. |
Note: | Frequently, it"s important to specify whether the transformation is Irreversible and Non-Substitutive using the derivation types constraint. |
Note: | Where derivations are used to create new works (a.k.a. Derived Works) that are intended for distribution to third-parties, a Next Policy Duty must be specified. |
Label: | Derive |
Identifier: | https://www.w3.org/community/md-odrl-profile#derive-0-9 |
Sub-class Of: | Non-Display |
Active Duties must be fulfilled for their associated Permissions to be valid. If a duty is left unfulfilled, then the permission becomes invalid and can no longer be exercised.
Duties are fulfilled when the subject
takes the Action
for the object
of the duty. The Duty may also have a target
that specifies the Asset
,
Party
, or Activity
over which the Action
is taken.
Duty functions specify the role a Party plays in fulfilling a Duty. There are two: the
subject
who must exercise the duty"s action and the object
who receives the
effect of the action.
Definition: | Specifies the Party that must execute the Action specified by a Duty. |
---|---|
Version: | 0.9 |
Example: | Where the action is Notify, the subject is the notifying Party. |
Example: | Where the action is Report, the subject is the reporting Party. |
Example: | Where the action is Request, the subject is the requesting Party. |
Example: | Where the action is Consent, the subject is the consenting Party. |
Example: | Where the action is Compensate, the subject is the compensating Party. |
Example: | Where the action is Invoice, the subject is the invoicing Party. |
Example: | Where the action is Attach, the subject is the attaching Party. |
Label: | subject |
Identifier: | https://www.w3.org/community/md-odrl-profile#subject-0-9 |
Domain: | odrl:Duty |
Range: | odrl:Party |
Definition: | Specifies the Party that is affected by the Action specified by a Duty. |
---|---|
Version: | 0.9 |
Example: | Where the action is Notify, the object is the notified Party. |
Example: | Where the action is Report, the object is the Party that receives the report. |
Example: | Where the action is Request, the object is the requested Party. |
Example: | Where the action is Consent, the object is the Party that receives the consent. |
Example: | Where the action is Compensate, the object is the compensated Party. |
Example: | Where the action is Invoice, the object is the invoiced Party. |
Example: | Where the action is Attach, the object is the Party that receives the attachment. |
Label: | object |
Identifier: | https://www.w3.org/community/md-odrl-profile#object-0-9 |
Domain: | odrl:Duty |
Range: | odrl:Party |
Definition: | The target property indicates the Asset, Activity, or Party that is the primary subject to which the Rule action directly applies. |
---|---|
Version: | 0.9 |
Scope Note: | This property is a direct generalisation of the ODRL target relation to add Activities and Parties to its domain. |
Label: | targets |
Identifier: | https://www.w3.org/community/md-odrl-profile#targets-0-9 |
Domain: | odrl:Duty |
Range: | odrl:Party, Asset, prov:Activity |
Definition: | A declaration of the Assigner's ownership of the Asset. |
---|---|
Version: | 0.9 |
Note: | The wording of the declaration will usually be specified by the wordingproperty. |
Label: | Attribution |
Identifier: | https://www.w3.org/community/md-odrl-profile#attribution-0-9 |
Sub-class Of: | Asset |
Definition: | A clarification of the Assigner"s relation to the Asset. |
---|---|
Version: | 0.9 |
Note: | The wording of the clarification will usually be specified by the wording property. |
Label: | Disclaimer |
Identifier: | https://www.w3.org/community/md-odrl-profile#disclaimer-0-9 |
Sub-class Of: | Asset |
Definition: | A written instruction forbidding some action . |
---|---|
Version: | 0.9 |
Note: | The wording of the instruction will usually be specified by the wording property. |
Label: | Proscription |
Identifier: | https://www.w3.org/community/md-odrl-profile#proscription-0-9 |
Sub-class Of: | Asset |
Definition: | Specifies the wording required by an Attribution, Disclaimer, or Proscription. |
---|---|
Version: | 0.9 |
Label: | wording |
Identifier: | https://www.w3.org/community/md-odrl-profile#wording-0-9 |
Domain: | Attribution , Disclaimer , Proscription |
Range: | xsd:string |
Definition: | The subject makes the object aware of of a relevant change in the state of the world specified by the target relation. |
---|---|
Version: | 0.9 |
Example: | Where the target is a Usage activity, the subject makes the object aware that they have now started using the asset. |
Example: | Where the target is a Reasonable Suspicion, the subject makes the object aware that they now have a reasonable suspicion that the asset is being misused. |
Example: | Where the target is a Party playing the role of Service Facilitator, the subject makes the object aware that a service facilitator now has access to the asset. (See Example 1.) |
Label: | Notify |
Identifier: | https://www.w3.org/community/md-odrl-profile#notify-0-9 |
Sub-class Of: | odrl:Action, prov:Activity |
Definition: | The subject provides a report to the object on a relevant and on-going state of affairs specified by the target relation. |
---|---|
Version: | 0.9 |
Example: | Where the target is a Controls activity, the subject reports to the object on their implementation of access controls. |
Example: | Where the target is a Usage activity, the subject reports to the object on their usage of the Asset. The duty should specify the unit of count to use in the report. (See Example 2) |
Label: | Report |
Identifier: | https://www.w3.org/community/md-odrl-profile#report-0-9 |
Sub-class Of: | odrl:Action, prov:Activity |
Reporting usage requires a unit of count such as device
,
user-account
, or location
to specify what must be reported. The example
below calls for reporting by device (once):
[] a odrl:Duty; odrl:action [ a md:Report ; odrl:unitOfCount [ a md:Device ] ; md:reporting-code 1754 ] ; md:targets [ a md:Usage ] .
Definition: | A unique identifier that points to the data package or information product that the use of a Permission must be reported against. |
---|---|
Version: | 0.9 |
Scope Note: | Also known as a Product Code. |
Example: | The Reporting Code “SMGL2SST” identifies Display to a Closed User Group of the Information Product “Spot Market Germany (Frankfurt/Xetra®) Level 2” without automatic Updating. |
Label: | reporting code |
Identifier: | https://www.w3.org/community/md-odrl-profile#reporting-code-0-9 |
Domain: | Report |
Definition: | The subject makes the object aware of a desired state of the world specified by the target relation. |
---|---|
Version: | 0.9 |
Example: | Where the target is an Audit activity, the subject requests the object to Consent to an audit. |
Example: | Where the target is a Party playing the role of Service Facilitator, the subject requests the object to Consent to a service facilitator accessing the asset. (See Example 3.) |
Label: | Request |
Identifier: | https://www.w3.org/community/md-odrl-profile#request-0-9 |
Sub-class Of: | odrl:Action, prov:Activity |
Definition: | The subject accedes to a desired state of the world specified by the target relation. |
---|---|
Version: | 0.9 |
Example: | Where the target is an Audit activity, the subject consents to be audited by the object. |
Example: | Where the target is a Party playing the role of Service Facilitator, the subject consents to the object"s use of a service facilitator. (See Example 3.) |
Label: | Consent |
Identifier: | https://www.w3.org/community/md-odrl-profile#consent-0-9 |
Sub-class Of: | odrl:Action, prov:Activity |
Duties
can be chained so that one duty can activate another duty.
Request
and Consent
duties can follow this pattern. A
Permision
may point to a consent duty which might itself point to a request duty.
While the request duty remains unfulfilled, the consent duty remains inactive. The permission remains valid. But if the request is made, then either the consent must be given (and so the consent duty fulfilled), or the request retracted, else the permission be invalidated.
The request duty is itself activated by the recipients
constraint just like the
notification duty in Example 1.
[] a odrl:Duty; odrl:action [ a md:Consent ; ] ; md:targets [ a md:ServiceProvider ] ; odrl:duty :R1 .
:R1 a odrl:Duty; md:recipients [ a md:ExternalParty ; md:roles [ a md:ServiceFacilitator ] ] ; odrl:action [ a md:Request ; ] ; md:targets [ a md:ExternalParty ; md:roles [ a md:ServiceFacilitator ] ] .
Definition: | The subject pays the object. |
---|---|
Version: | 0.9 |
Note: | The compensation action must be decorated with the payment amount and the unit (or currency) of payment. It may also specify the unit of count which acts as a multiplier of the payment amount. |
Label: | Compensate |
Identifier: | https://www.w3.org/community/md-odrl-profile#compensate-0-9 |
Sub-class Of: | odrl:Action, prov:Activity |
The following example requires $1,150 to be paid per location once:
[] a odrl:Duty; odrl:action [ a md:Compensate ; odrl:unitOfCount [ a md:Location ] ; odrl:payAmount 1150.00 ; odrl:unit currency:USD ; # USD ] .
Definition: | The subject bills the object. |
---|---|
Version: | 0.9 |
Label: | Invoice |
Identifier: | https://www.w3.org/community/md-odrl-profile#invoice-0-9 |
Sub-class Of: | odrl:Action, prov:Activity |
Invoice
Action
is specified, it will likely be used as an
activation condition for a compensation duty, i.e. payment need only be made on receipt of an
invoice.
[] a odrl:Duty; odrl:action [ a md:Compensate ; odrl:unitOfCount [ a md:Location ] ; odrl:payAmount 1150.00 ; odrl:unit currency:USD ; # USD ] ; odrl:duty :I1 .
:I1 a odrl:Duty; odrl:action [ a md:Invoice ; ] .
Definition: | The subject attaches the rubric specified by the target relation. |
---|---|
Version: | 0.9 |
Example: | Where the target is an Attribution, the rubric describes the object's ownership of the asset. The precise phrasing may be specified by a wording property on the attribution. |
Example: | Where the target is a Disclaimer, the rubric clarifies the object's relation to the asset. The precise phrasing may be specified by a wording property on the disclaimer. |
Example: | Where the target is a Proscription, the rubric instructs the object not to do something as specified by a wording property on the proscription. |
Label: | Attach |
Identifier: | https://www.w3.org/community/md-odrl-profile#attach-0-9 |
Sub-class Of: | odrl:Action, prov:Activity |
In this example, a Duty
requires and specifies an Attribution
to be
attached to the data whenever the recipient
is an External Party
.
[] a odrl:Duty ; md:recipients [ a md:ExternalParty ] ; 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." ] .
The follwing Duty
, usually associated with Derivations
, requires and
specifies a Disclaimer
to be attached to the data irrespective of whether the
recipient
is an Internal
or External Party
.
[] a odrl:Duty ; md:recipients ( [ a md:InternalParty ] [ a md:ExternalParty ] ) ; odrl:action [ a md:Attach ; ] ; odrl:target [ a md:Disclaimer ; md:wording "CME Group Market Data is used under license as a source of information for certain [LICENSEE/LICENSEE GROUP] products. CME Group has no other connection to [LICENSEE/LICENSEE GROUP] products and services and does not sponsor, endorse, recommend or promote any [LICENSEE/LICENSEE GROUP] products or services. CME Group has no obligation or liability in connection with the [LICENSEE/LICENSEE GROUP] products and services. CME Group does not guarantee the accuracy and/or the completeness of any Market Data licensed to [LICENSEE/LICENSEE GROUP] and shall not have any liability for any errors, omissions, or interruptions therein. there are no third-party beneficiaries of any agreements or arrangements between CME Group and [LICENSEE/LICENSEE GROUP]." ] .
Definition: | The subject must come to a legally binding agreement with the object that enforces the rubric specified by the target relation. |
---|---|
Version: | 0.9 |
Label: | Agree |
Identifier: | https://www.w3.org/community/md-odrl-profile#agree-0-9 |
Sub-class Of: | odrl:Action, prov:Activity |
Assets are segmented primarily for commercial or technical reasons. These segmentations can be by the type of the content (e.g. access to just French equities or only the index values, not the constituents and weightings); by temporal reach (e.g. access to only three years of historical data); or by the mode of delivery. The first we call a content segmentation
; the second, a temporal segmentation
; and the last, a delivery segmentation
.
Definition: | Specifies the timing of the permitted receipt or onwards delivery of an Asset. |
---|---|
Version: | 0.9 |
Editorial Note: | Usually specified as an interval (or intervals) relative to the data"s Origination Time, Publication Time, Issue Time, or Market Close (or some other specified moment). |
Editorial Note: | These intervals are frequently identified as Realtime, Delayed, or Embargoed. |
Editorial Note: | Unless explicitly prohibited, Permissions over shorter intervals carry across to longer intervals (e.g. Realtime data also covers Delayed, and Embargoed data) |
Label: | timeliness of delivery |
Identifier: | https://www.w3.org/community/md-odrl-profile#timeliness-of-delivery-0-9 |
Domain: | Asset |
Range: | Proper Interval |
Definition: | Specifies the method by which updates to the Asset are delivered. |
---|---|
Version: | 0.9 |
Note: | If the method is snapshot, then the number of snaps permitted can be specified using the count property and a time interval. (See Example 10.) |
Label: | method of update |
Identifier: | https://www.w3.org/community/md-odrl-profile#method-of-update-0-9 |
Domain: | Asset |
Range: | Update Method |
Definition: | The period during which the Asset has been, or continues to be, updated. |
---|---|
Version: | 0.9 |
Note: | If the Asset continues to be updated while a subsciption holds, use the Service Period interval. |
Label: | period of update |
Identifier: | https://www.w3.org/community/md-odrl-profile#period-of-update-0-9 |
Domain: | Asset |
Range: | Proper Interval |
Definition: | Specifies how frequently updates to the Asset are delivered. |
---|---|
Version: | 0.9 |
Label: | frequency of update |
Identifier: | https://www.w3.org/community/md-odrl-profile#frequency-of-update-0-9 |
Domain: | Asset |
Range: | Update Frequency |
Definition: | Categorises a Asset by the financial asset class(es) it describes. |
---|---|
Version: | 0.9 |
Label: | asset classes |
Identifier: | https://www.w3.org/community/md-odrl-profile#asset-classes-0-9 |
Domain: | Asset |
Range: | Asset Class |
In the following example the Asset :A1
describes Commodity Futures:
:A1 a md:Asset; md:assetClasses cfi:FCEPSX . # Commodity Futures for Extraction Resources with Physical Delivery
Definition: | Measures the book depth offered by an Asset. |
---|---|
Version: | 0.9 |
Label: | depth of market |
Identifier: | https://www.w3.org/community/md-odrl-profile#depth-of-market-0-9 |
Domain: | Asset |
Range: | Market Depth |
Definition: | The geographic subject matter and focus of an Asset. |
---|---|
Version: | 0.9 |
Scope Note: | A characteristic of the Asset rather than its source/origin or any limitations on its distribution. |
Label: | geographic coverage |
Identifier: | https://www.w3.org/community/md-odrl-profile#geography-0-9 |
Domain: | Asset |
Range: | UN M49 Codes |
Definition: | The amount of an Asset. |
---|---|
Version: | 0.9 |
Scope Note: | If a qualititive measure is needed use the values Insubstantial or Substantial. Else specify a numeric value (as rdf:value) and a unit of count. |
Label: | amount |
Identifier: | https://www.w3.org/community/md-odrl-profile#amount-0-9 |
Domain: | Asset |
Range: | Quantity |
Definition: | The temporal coverage offered by an Asset. |
---|---|
Version: | 0.9 |
Scope Note: | Usually used to specify the date range of Historical data. |
Label: | temporal coverage |
Identifier: | https://www.w3.org/community/md-odrl-profile#temporal-0-9 |
Domain: | Asset |
Range: | time:ProperInterval |
Temporal constaints specify access to historical data using the temporal property. The interval allowing access to the latest three years of historical data would look so:
[] md:temporal [ a time:ProperInterval ; time:hasXSDDuration "P3Y"^^xsd:duration ] .
Definition: | Given the Asset Class, further specifies the type of content provided by the Asset |
---|---|
Version: | 0.9 |
Editorial Note: | The valid values for content type depend on the Asset Class of the Asset |
Label: | content types |
Identifier: | https://www.w3.org/community/md-odrl-profile#content-types-0-9 |
Domain: | Asset Class |
Range: | Content Type |
The Asset :A3
describes the Values and Constituents (content type) of an Index of
Equities (asset class):
:A3 a md:Asset; md:assetClasses [ a cfi:TIEXX ; # Index of equities md:contentType ( [ a md:Value ] [ a md:Constituents ] ) ; ] .
Definition: | Identifies the Control activities that protect the Asset from unauthorised access. |
---|---|
Version: | 0.9 |
Label: | controls |
Identifier: | https://www.w3.org/community/md-odrl-profile#controls-0-9 |
Domain: | odrl:Rule |
Range: | Control |
In the example below the Permission is only valid if the controls
Constraint is satisfied by use of a closed user group
to manage access to the
Asset
.
[] a odrl:Permission ; md:controls [ a md::ClosedUserGroup ] .
Definition: | Specifies the Parties who can access the Asset which is the target of the parent Permission following the exercise of its Action. |
---|---|
Version: | 0.9 |
Note: | Can be used either to constrain a Distribute action to a specified set of parties or to trigger linked Duties that control distribution. |
Label: | recipients |
Identifier: | https://www.w3.org/community/md-odrl-profile#recipients-0-9 |
Sub-Property Of: | odrl:function |
Domain: | Distribute , odrl:Duty |
Range: | Party |
Definition: | Specifies the Parties who can exercise the Rule. |
---|---|
Version: | 0.9 |
Label: | users |
Identifier: | https://www.w3.org/community/md-odrl-profile#users-0-9 |
Sub-Property Of: | odrl:function |
Super-Property Of: | odrl:assignee |
Domain: | odrl:Rule |
Range: | Party |
Definition: | Specifies the Party that physically stores the Asset. |
---|---|
Version: | 0.9 |
Note: | A vendor-hosted feed (i.e. a hosted request/response API) can be modelled by setting the value to an External Party with the role of Provider. |
Note: | Web hosting can similarly be modelled as a display permission in which the data host is set to an External Party with the role of Provider. |
Note: | A deployed feed can be modelled by setting the value to an Internal Party with the role of Consumer. |
Label: | data host |
Identifier: | https://www.w3.org/community/md-odrl-profile#data-host-0-9 |
Sub-Property Of: | odrl:function |
Domain: | odrl:Permission |
Range: | odrl:Party |
Definition: | Enumerates the Distribution Services in the delivery of which the Permissions can be exercised. |
---|---|
Version: | 0.9 |
Label: | distribution services |
Identifier: | https://www.w3.org/community/md-odrl-profile#distribution-services-0-9 |
Domain: | odrl:Rule |
Range: | Distribution Service |
Definition: | Specifies the Quantity of the Asset than can be combined with other assets in executing the rule. |
---|---|
Version: | 0.9 |
Label: | commingle |
Identifier: | https://www.w3.org/community/md-odrl-profile#commingle-0-9 |
Domain: | odrl:Rule |
Range: | odrl:Quantity |
Beyond the recipients constraint that can be used to constrain a Distribute actions, there are additional ways to constrain Actions:
Definition: | The Activities in persuit of which the Action is taken. |
---|---|
Version: | 0.9 |
Label: | purposes |
Identifier: | https://www.w3.org/community/md-odrl-profile#purposes-0-9 |
Domain: | odrl:Action |
Range: | prov:Activity |
Users who want to use this (traditionally fee-waivered) display
Permission can
do so only for the purposes
of technical support
,
quality assurance
, or product development
. They must belong to a
closed user group
and be directly employed by the Assignee or its affiliated or
enumerated organisations.
[] a odrl:Permission ; md:controls [ a md::ClosedUserGroup ] ; md:recipients [ a md::InternalParty ] ; md:purposes ( [ a md:TechnicalSupport ] [ a md:QualityAssurance ] [ a md:ProductDevelopment ] ) ; odrl:action [ a md::Display ] .
Definition: | Specifies the types of derivation activity undertaken in exercising the Derive action |
---|---|
Version: | 0.9 |
Label: | for derivation types |
Identifier: | https://www.w3.org/community/md-odrl-profile#derivation-types-0-9 |
Domain: | Derive |
Range: | Derivation |
Definition: | Classifies the display application as being either for individual use (i.e., a device) or public display (i.e., a wallboard). |
---|---|
Version: | 0.9 |
Label: | for display types |
Identifier: | https://www.w3.org/community/md-odrl-profile#display-types-0-9 |
Domain: | Display |
Range: | Display Type |
Definition: | Specifies the locations where the users of the Rule must be based. |
---|---|
Version: | 0.9 |
Label: | locations |
Note: | Locations can range from regions, countries, cities down to individual offices with addresses. |
Identifier: | https://www.w3.org/community/md-odrl-profile#locations-0-9 |
Sub-Property Of: | odrl:function |
Domain: | odrl:Rule |
Definition: | Specifies the lines of business belonging to an assignee that can exercise the Rule. |
---|---|
Version: | 0.9 |
Label: | lines of business |
Note: | Lines of business can range from activities (like buy-side vs. sell-side), departments, down to individual desks. |
Identifier: | https://www.w3.org/community/md-odrl-profile#lines-of-business-0-9 |
Sub-Property Of: | odrl:function |
Domain: | odrl:Rule |
The financial instruments that an Asset describe may belong to an Asset Class
(e.g. equities or bonds).
Definition: | The type of financial instrument(s) described by a Asset. |
---|---|
Version: | 0.9 |
Note: | It is recommended that the values are selected from ISO 10962:2021: Classification of Financial Instruments (CFI) codes [[ISO10962]]. See also the Wikipedia entry. |
Label: | Asset Class |
Identifier: | https://www.w3.org/community/md-odrl-profile#asset-class-0-9 |
Definition: | The methods by which an Asset is updated over time. |
---|---|
Version: | 0.9 |
Label: | Update Method |
Identifier: | https://www.w3.org/community/md-odrl-profile#update-method-0-9 |
Sub-class Of: | prov:Entity |
Definition: | An update is provided only in response to a request (like an API call). |
---|---|
Version: | 0.9 |
Editorial Note: | Also known as “one-shot”. |
Note: | The number of requests (or snaps) permitted can be specified using the count property and a time interval. |
Label: | Snapshot |
Identifier: | https://www.w3.org/community/md-odrl-profile#snapshot-0-9 |
Sub-class Of: | Update Method |
In the following example, an Asset
permits only three requests per day:
[] a md:Asset ; md:methodOfUpdate [ a md:Snapshot ; odrl:count 3 odrl:timeInterval [ a time:ProperInterval ; time:hasXSDDuration "P1D"^^xsd:duration ] ; ] .
Definition: | All changes are captured and continuously transmitted either individually or in batches. |
---|---|
Version: | 0.9 |
Label: | Streaming |
Identifier: | https://www.w3.org/community/md-odrl-profile#streaming-0-9 |
Sub-class Of: | Update Method |
Definition: | Multiple updates are delivered together in bulk. |
---|---|
Version: | 0.9 |
Label: | Time Series |
Identifier: | https://www.w3.org/community/md-odrl-profile#time-series-0-9 |
Sub-class Of: | Update Method |
Definition: | The frequency by which an Asset is updated over time. |
---|---|
Version: | 0.9 |
Label: | Update Frequency |
Identifier: | https://www.w3.org/community/md-odrl-profile#update-frequency-0-9 |
Definition: | Any and every change in value is provided in an update. |
---|---|
Version: | 0.9 |
Label: | Tick-by-Tick |
Identifier: | https://www.w3.org/community/md-odrl-profile#tick-by-tick-0-9 |
Sub-class Of: | Update Frequency |
Definition: | Updates are sampled and/or conflated. |
---|---|
Version: | 0.9 |
Note: | Only selected updates are delivered from the whole tick-by-tick dataset at specified intervals (e.g. every one minute throughout every day, at the end of every day, week, month, quarter or year) or on specific events (e.g. on daily market open and/or close, end of session, quarterly results etc). |
Label: | Sampled |
Identifier: | https://www.w3.org/community/md-odrl-profile#sampled-0-9 |
Sub-class Of: | Update Frequency |
Definition: | Represents the depth of the order book offered by an asset. |
---|---|
Version: | 0.9 |
Note: | Market depth can be qualified to specify the exact depth of market offered by using the position from and position to properties. (See Example 11). |
Label: | Market Depth |
Identifier: | https://www.w3.org/community/md-odrl-profile#market-depth-0-9 |
Definition: | Market Price includes the content relating to at least the best bid and best ask/offer in the market. |
---|---|
Version: | 0.9 |
Editorial Note: | Also known as “Level 1” data. |
Note: | If more prices beyond the best bid are offered, the book depth can be specified by
using the positionTo and positionFrom properties. |
Label: | Market Price |
Identifier: | https://www.w3.org/community/md-odrl-profile#market-price-0-9 |
Sub-class Of: | Market Depth |
Definition: | The Full Order Book includes content relating to the bids and
asks/offers at all price points and from all participants in the market. |
---|---|
Version: | 0.9 |
Editorial Note: | Also known as "market by order", the "detailed order book", or "Level 2"/"Level 3" data. |
Label: | Full Order Book |
Identifier: | https://www.w3.org/community/md-odrl-profile#full-order-book-0-9 |
Sub-class Of: | Market Depth |
Definition: | Denotes the bid depth from which the Asset offers prices. |
---|---|
Version: | 0.9 |
Label: | position from |
Identifier: | https://www.w3.org/community/md-odrl-profile#position-from-0-9 |
Domain: | Market Depth |
Range: | xsd:integer |
Definition: | Denotes the bid depth up to which the Asset offers prices (inclusive). |
---|---|
Version: | 0.9 |
Label: | position to |
Identifier: | https://www.w3.org/community/md-odrl-profile#position-to-0-9 |
Domain: | Market Depth |
Range: | xsd:integer |
In this example, the Market Price
Asset
provides a book depth of
ten:
[] a md:Asset; md:depthOfMarket [ a md:MarketPrice ; md:positionFrom 1 ; md:positionTo 10 ; ] .
Definition: | The type of application on which the asset is displayed |
---|---|
Version: | 0.9 |
Scope Note: | Used to constrain a display action to allow either individual or public presentation. |
Label: | Display Type |
Identifier: | https://www.w3.org/community/md-odrl-profile#display-type-0-9 |
Definition: | The amount of an Asset. |
---|---|
Version: | 0.9 |
Label: | Quantity |
Identifier: | https://www.w3.org/community/md-odrl-profile#quantity-0-9 |
Definition: | A small part of an Asset. |
---|---|
Version: | 0.9 |
Scope Note: | By virue of its very smallness, an insubstantial part of an Asset may have more permitted uses than the whole. |
Scope Note: | Indicates dissaggregation is permitted when used in a Commingle constraint. |
Note: | This is a qualitative measure. If a quantative measure is needed, constrain the amount by a unit of count. |
Label: | Insubstantial |
Identifier: | https://www.w3.org/community/md-odrl-profile#insubstantial-0-9 |
Sub-class Of: | Quantity |
Definition: | A large part of an Asset, up to and including the whole. |
---|---|
Version: | 0.9 |
Scope Note: | By virue of its very largeness, an substantial part of an Asset may not have more permitted uses than the whole. |
Scope Note: | Indicates aggregation is permitted when used in a Commingle constraint. |
Note: | This is a qualitative measure. If a quantative measure is needed, constrain the amount by a unit of count. |
Label: | Substantial |
Identifier: | https://www.w3.org/community/md-odrl-profile#substantial-0-9 |
Sub-class Of: | Quantity |
Definition: | Covers all the lines-of-business managed by a Party including the buy-side, sell-side, and treasury functions. |
---|---|
Version: | 0.9 |
Label: | Enterprise |
Identifier: | https://www.w3.org/community/md-odrl-profile#enterprise-0-9 |
Definition: | A sub-division of a Party that focusses on buying financial instruments for money-management purposes. |
---|---|
Version: | 0.9 |
Scope Note: | Common buy-side activities include asset management. |
Scope Note: | Common buy-side institutions include hedge funds, pension funds, and mutual funds. |
Label: | Buy-Side |
Identifier: | https://www.w3.org/community/md-odrl-profile#buy-side-0-9 |
Sub-class Of: | Enterprise |
Definition: | A sub-division of a Party that focusses on supporting the sale of financial instruments to buy-side clients. |
---|---|
Version: | 0.9 |
Scope Note: | Common sell-side activities include underwriting, market making, providing clearing services, and generating research material and analysis. |
Scope Note: | Investment banks are sell-side institutions. |
Label: | Sell-Side |
Identifier: | https://www.w3.org/community/md-odrl-profile#sell-side-0-9 |
Sub-class Of: | Enterprise |
Definition: | The treasury function is responsible for ensuring that a financial organisations's assets match its liabilities. |
---|---|
Version: | 0.9 |
Scope Note: | The treasury function must maintain the capital adequacy ratios and reserve ratios required by regulation. |
Scope Note: | |
Label: | Treasury |
Identifier: | https://www.w3.org/community/md-odrl-profile#treasury-0-9 |
Sub-class Of: | Enterprise |
There are some moments in time which are of particulat interest and demand definition. The following are especially useful in calculating the timeliness of data.
Definition: | The moment information condensces into data. |
---|---|
Version: | 0.9 |
Example: | The instant a price is struck and recorded. |
Label: | Origination Time |
Identifier: | https://www.w3.org/community/md-odrl-profile#origination-time-0-9 |
Sub-class Of: | time:Instant |
Definition: | The instant data is released by the Originator for distribution. |
---|---|
Version: | 0.9 |
Label: | Publication Time |
Identifier: | https://www.w3.org/community/md-odrl-profile#publication-time-0-9 |
Sub-class Of: | time:Instant |
Definition: | The instant data is distributed from the Originator |
---|---|
Version: | 0.9 |
Label: | Issue Time |
Identifier: | https://www.w3.org/community/md-odrl-profile#issue-time-0-9 |
Sub-class Of: | time:Instant |
Definition: | The time published by the venue specifying when a market closes. |
---|---|
Version: | 0.9 |
Label: | Market Close |
Identifier: | https://www.w3.org/community/md-odrl-profile#market-close-0-9 |
Sub-class Of: | time:Instant |
Definition: | The moment an invoice is received by the payee. |
---|---|
Version: | 0.9 |
Label: | Receipt of Invoice |
Identifier: | https://www.w3.org/community/md-odrl-profile#receipt-of-invoice-0-9 |
Sub-class Of: | time:Instant |
Definition: | The moment a license is terminated. |
---|---|
Version: | 0.9 |
Label: | Termination |
Identifier: | https://www.w3.org/community/md-odrl-profile#termination-0-9 |
Sub-class Of: | time:Instant |
Equally there are some time intervals which are of particulat interest and demand definition. Again, these are especially useful in describing the timeliness of data.
Definition: | Data received, used, or delivered with minimum latency after its time of origination, publication, or issue. |
---|---|
Version: | 0.9 |
Label: | Realtime |
Identifier: | https://www.w3.org/community/md-odrl-profile#realtime-0-9 |
Sub-class Of: | time:ProperInterval |
We can specify the precise meaning of Realtime
defined in a license. Here
Realtime
is data delivered within 10 minutes of Issue Time
:
[] a md:Asset; md:timelinessOfDelivery [ a time:ProperInterval , md:Realtime ; time:intervalBefore [ a time:ProperInterval ; md:timeReference [ a time:TimeInstant , md:TimeOfIssue ] ; md:timeReference [ a time:Instant , md:TimeOfIssue ] ; time:hasXSDDuration "PT10M"^^xsd:duration ] ; ] .
Definition: | Data received, used, or delivered at or after a specified time interval following its time of origination, publication, or issue. |
---|---|
Version: | 0.9 |
Label: | Delayed |
Identifier: | https://www.w3.org/community/md-odrl-profile#delayed-0-9 |
Sub-class Of: | time:ProperInterval |
In this example, Delayed
data is specified as running from ten minutes through to eight
hours following Issue Time
.
[] a md:Asset; md:timelinessOfDelivery [ a time:ProperInterval , md:Delayed ; time:intervalAfter [ a time:ProperInterval ; md:timeReference [ a time:TimeInstant , md:TimeOfIssue ] ; md:timeReference [ a time:Instant , md:TimeOfIssue ] ; time:hasXSDDuration "PT10M"^^xsd:duration ] ; time:intervalBefore [ a time:ProperInterval ; md:timeReference [ a time:TimeInstant , md:TimeOfIssue ] ; md:timeReference [ a time:Instant , md:TimeOfIssue ] ; time:hasXSDDuration "PT8h"^^xsd:duration ] ; ] .
Definition: | Stored data that relates to events in the past. |
---|---|
Version: | 0.9 |
Editorial Note: | Usually the events described occured at least a calendar day in the past (or 24 hours in 24-hour markets). |
Note: | Usually held in the form of a time series |
Label: | Historical |
Identifier: | https://www.w3.org/community/md-odrl-profile#historical-0-9 |
Sub-class Of: | time:ProperInterval |
In this example, Historic
data is specified as being between eight hours of Issue Time
and three years.
[] a md:Asset; md:temporal [ a time:ProperInterval , md:Historical ; time:intervalAfter [ a time:ProperInterval ; md:timeReference [ a time:TimeInstant , md:TimeOfIssue ] ; md:timeReference [ a time:Instant , md:TimeOfIssue ] ; time:hasXSDDuration "PT8H"^^xsd:duration ] ; time:intervalBefore [ a time:ProperInterval ; md:timeReference [ a time:TimeInstant , md:TimeOfIssue ] ; md:timeReference [ a time:Instant , md:TimeOfIssue ] ; time:hasXSDDuration "PT3Y"^^xsd:duration ] ; ] .
Definition: | Data received, used, or delivered on or after a specified instant or future event. |
---|---|
Version: | 0.9 |
Editorial Note: | Used to describe end-of-day data. |
Label: | Embargoed |
Identifier: | https://www.w3.org/community/md-odrl-profile#embargoed-0-9 |
Sub-class Of: | time:ProperInterval |
In this example, end-of-day data is defined as data embargoed
until
market close
at 4pm CST.
[] a md:Asset; md:timelinessOfDelivery [ a time:ProperInterval , md:Embargoed ; time:after [ a time:Instant , md:MarketClose ; time:inDateTime [ a time:DateTimeDescription ; time:hour "16"^^xsd:int ; time:timeZone <https://www.wikidata.org/wiki/Q2086913> # CET ] ; ] ; ] .
Definition: | The period across which a subsciption holds. |
---|---|
Version: | 0.9 |
Label: | Service Period |
Identifier: | https://www.w3.org/community/md-odrl-profile#service-period-0-9 |
Sub-class Of: | time:ProperInterval |
The Market Data Profile for ODRL refers to the following namespaces:
Prefix | Namespace | Description |
---|---|---|
odrl | http://www.w3.org/ns/odrl/2/ | [[odrl-model]], [[odrl-vocab]] |
prov | http://www.w3.org/ns/prov# | [[PROV-O]] |
xsd | http://www.w3.org/2001/XMLSchema# | [[xmlschema11-2]] |
dct | http://purl.org/dc/terms/ | [[dc-terms]] |
time | http://www.w3.org/2006/time# | [[owl-time]] |
lei | urn:lei: | [[LEI]] |
mic | urn:iso:std:iso:10383:-1:tech:# | [[ISO10383]] |
cfi | urn:iso:std:iso:10962:-1:tech:# | [[ISO10962]] |
currency | urn:iso:std:iso:4217:-1:tech:# | [[ISO4217]] |
Policy writers should use the latest version of any external standards. Implementors should determine the identity of versioned external terms based on the effective date of the policy in which they are used.
The Market Data Profile for ODRL refers to the following external terms:
Term | Namespace | Description | Note |
---|---|---|---|
Entity | prov | A physical, digital, conceptual, or other kind of thing with some fixed aspects; entities may be real or imaginary. | |
Activity | prov | Something that occurs over a period of time and acts upon or with entities; it may include consuming, processing, transforming, modifying, relocating, using, or generating entities. | |
Party | odrl | An entity or a collection of entities that undertake Roles in a Rule. | The use of Global Legal Entity Identifiers to identify parties is recommended. [[ISO4217]] |
Rule | odrl | An abstract concept that represents the common characteristics of Permissions, Prohibitions, and Duties. | |
Permission | odrl | The ability to perform an Action over an Asset. | |
Duty | odrl | The obligation to perform an Action. | |
Constraint | odrl | A boolean expression that refines the semantics of an Action and Party/Asset or declare the conditions applicable to a Rule. | |
Action | odrl | An operation on an Asset. | |
Next Policy | odrl | To grant the specified Policy to a third party for their use of the Asset. | |
Assigner | odrl | The Party is the issuer of the Rule. | The use of Global Legal Entity Identifiers to identify assigners is recommended. [[ISO4217]] |
Assignee | odrl | The Party is the recipient of the Rule. | The use of Global Legal Entity Identifiers to identify assignees is recommended. [[ISO4217]] |
unit of count | odrl | The unit of measure used for counting the executions of the Action of the Rule. | |
payment amount | odrl | The amount of a financial payment. | The amount must be specified as an xsd:decimal. |
unit | odrl | The unit of measurement of the specified value. | Where the unit is specfying a currency, the ISO standard should be used. [[ISO4217]] |
count | odrl | Numeric count of executions of the Action of the Rule. | |
output | odrl | The output property specifies the Asset which is created from the output of the Action. | |
time interval | time | A temporal entity with an extent or duration. |
Market data licenses can say the same things in many different ways. The following table is intended to help map common license terms to the terms specified in this standard.
License Term | Standard Term | Note |
---|---|---|
View | Display |