RE: Rights Automation Community Group - comments on draft Standard - Resources

Thanks, Ron, I certainly agree. My purpose in listing those two specific rights was just to illustrate what I thought was the difference between the definition of an Asset and the definition of a Resource. I certainly wasn’t trying to produce an exhaustive list of specific rights.

Sorry for the confusion.

Best,
Mark


From: Ron Troy <rtroy56@gmail.com>
Sent: December 8, 2020 9:15 PM
To: Mark Bird <mark.bird@databp.com>
Cc: Phelan, Nigel <nigel.phelan@jpmorgan.com>; public-md-odrl-profile@w3.org
Subject: Re: Rights Automation Community Group - comments on draft Standard - Resources

Hi,

I don't know whether it's appropriate for me to respond this or any other way, and I freely admit my ignorance about a lot of this effort, but as someone who has managed Market Data in IB's, and also been a data contract compliance auditor for TR, and defended audits, I have a 'problem' with something just stated;


  1.  The right to distribute Product X internally to display terminals
  2.  The right to use that same Product X in a non-display trading application

What a firm has the right to do may or may not include these two uses, among many others.  A firm may be licensed to do these, or;
1. Wallboard display.
2. Pass on to external non-pro clients or even display openly on a website perhaps with no controls at all.
3. Be used for Risk Management purposes, and / or government reporting / regulatory compliance.
4. Periodic portfolio evaluation, perhaps for a fund (traded or not) and priced, perhaps, daily on various media.
5. Data (say real time) that you receive may be usable for one purpose, like display but it will likely be a contract violation to use that stream for EOD valuation (along with being a very poor choice).

Regards,

Ron

Ron Troy

rtroy56@gmail.com<mailto:rtroy56@gmail.com>

On Tue, Dec 8, 2020 at 7:00 PM Mark Bird <mark.bird@databp.com<mailto:mark.bird@databp.com>> wrote:
This week our group focused on the Resources section of the profile. Most of our discussion focussed on the concept of “Asset” and the way that it differs from the base term Resource. I’m typing out loud a bit here, but we settled our understanding on the definition of Asset (a Resource, a collection of Resources, or the part of a Resource controlled by a Rule) as meaning that an Asset has two fundamental components:


  1.  The data product itself
  2.  A specific right (and its accompanying obligations) that the Consumer has to that data product.

At first this was counterintuitive to me, and I was going to argue that Asset is the wrong word, because I’m used to thinking of an Asset as a tangible thing that I can do something with. One of my colleagues pointed out, though, that a firm that has these two license rights:


  1.  The right to distribute Product X internally to display terminals
  2.  The right to use that same Product X in a non-display trading application

In a very real sense has two distinct Assets, even though they’re both based on the same data product.

So, to confirm my understanding, is it correct to say that an Asset is comprised of both a reference to a specific Resource, and also a particular license right the Consumer has to that Resource?

If that is correct, the introductory paragraphs in the Resources section reads: The data supply chain provides resources (usually data resources). To track their progress and ensure compliance, we need to make three distinctions: the original data created by the Originator (1); the resource packaged by timeliness, geography, or other dimension before Rules are applied to control its use (2); and the controlled resource that is received by a Consumer (3). The first is a Source and the last is an Asset. All are Resources.

The sentence that reads “The first is a Source and the last is an Asset” is confusing, since there are three things referred to. I believe that Source refers to the original data created by the Originator, and Asset refers to the controlled resource received by a Consumer. So, shouldn’t there be a specific term for the middle thing, “the resource packaged by timeliness, geography, or other dimension before Rules are applied to control its use?”

This term might actually be more useful, or at least more frequently used, then Source, since Source data applies only to a very specific case at the top of the distribution chain. The term I have in mind would describe the data product when a Provider is in the act of distributing it, but before it’s been received and constrained by the specific rights of the Consumer.

One final and separate comment: In an Editorial note we read “[a Resource] only becomes a new Resource 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).” We in the community group discussed the definition of derivation and agreed that everybody in the industry understands it to be irreversible and non-substitutive. But the gadfly in my group said “well yes but what if some particular Originator wants to define it slightly differently?”

I’ve been trying to think of how to frame this comment as a suggestion. Maybe it’s that certain notes could be prefaced with something like “It’s generally understood in the industry that…” or something along those lines. This would add weight to the definition by pointing to common usage.

Best,
Mark


From: Phelan, Nigel <nigel.phelan@jpmorgan.com<mailto:nigel.phelan@jpmorgan.com>>
Sent: December 4, 2020 10:39 AM
To: public-md-odrl-profile@w3.org<mailto:public-md-odrl-profile@w3.org>
Subject: RE: Rights Automation Community Group - comments on draft Standard

We have some further feedback (slowly working through the draft...)

2.1.2.1.4 (Party Role/Administrator)

Based on the discussions in the last meeting, we think this is a licensing agent type role, which might be performed by an originator, or a provider, or might be outsourced by one of those to a third party; the comments below still apply; we think the role still exists even if the function is retained by the originator or the provider, and the duties and constraints would be similar (although additional duties could be imposed if the work was handled by a third party).  We are trying to simply the ODRL here by avoiding the need for duplicate duties in the case where a provider might be handling the licensing or it might have been handed to a third party – it feels cleaner to say “whoever is handling the licensing, regardless of other roles they might perform, has the following duties/constraints”.

2.3 (Activities)

Firstly, we feel that “Activities” isn’t the best name for this; these feel more like “Events”.  You have a “Data Use” event, or an “Audit” event, for example, which may be used as triggers in certain rules.  How do others feel about this?  Are we missing the intent, here?

We feel that “Usage”, “Audit” and “Derivation” would then be first class “Events”, but that “Trading (and sub classes)”, “Training”, “Technical Support”, “Quality Assurance”, “Product development” and “Marketing” are types of “Usage” event (i.e. purposes for which the asset may be used).

For “Control”, we think that “Closed User Group”, “Provider Managed” and “Consumer Managed” are relevant concepts, but don’t really fit in this section.  There may be “Control Events” – like granting user access rights or revoking them, but a “Closed User Group” is a thing, not an activity or a state change.  Maybe Control belongs in “Other Things of Interest”, or as a section in its own right?

2.3.1.3 (Reasonable Suspicion)
Isn’t the actual event here a “Licensing Breach”?  The Licensor has “reasonable suspicion” that the contract terms are being violated and seeks to impose a remedy?

2.3.1.4.1 (Closed User Group)
We prefer the term “Restricted User Group” (closed somewhat implies not subject to change, which feels wrong).  Also the description is a bit too prescriptive about the form of controls on users – most contracts use more open ended working like a need for “adequate technical controls”, without specifying the form they take.  Perhaps “uniquely identified users” would be better?  Furthermore, should this be users, or entities?  Could users be “applications”?

2.3.1.5 (Derivation)
Aren’t “Irreversible” and “Non-Substitutive” attributes of Derivations, rather than sub-classes (or perhaps they are Constraints)?  Most contracts I’ve seen require that a derivation possess both properties to be acceptable.  The newly created asset would still be a derived work if it lacked these attributes, but the contract wouldn’t actually grant you the ability to do anything with it.  You would, however, have some innate rights in the derived work if the calculations performed incorporated your own IP as well, so it could be the case that nobody else could do anything with it without a license grant from yourself, so you can’t quite treat it as a copy of the original data, over which originator/provider have control.


Nigel & Michelle

________________________________
Nigel Phelan | Corporate & Investment Bank | Market Data Services | J.P. Morgan

From: Phelan, Nigel (CIB Tech, GBR)
Sent: 25 November 2020 15:08
To: 'public-md-odrl-profile@w3.org<mailto:public-md-odrl-profile@w3.org>' <public-md-odrl-profile@w3.org<mailto:public-md-odrl-profile@w3.org>>
Subject: Rights Automation Community Group - comments on draft Standard

Hi Ben – Michelle and I have been reviewing the standard this week; it’s taking a while and we expect to continue providing feedback on it in the coming weeks as we get further through it, but we had some initial comments on content up to section 2.2.2

2.1.1 – Party Types

We feel that some contracts require further differentiation of party types than simply “Internal Party” and “External Party”.  We see the following distinction:

Internal

  *   Licensee consumers who are covered by the License entity
  *   Licensee affiliates, who sometimes have lesser rights than the Licensee consumers
 External

  *   Professional consumers – described as using for business purposes, which can include commercial use
  *   Non-professional consumers – described as using for personal or non-commercial use
  *   Public website consumer – where there are typically no distinctions between the capacities in which an individual may be using the data

All of these are defined with different obligations on the use case, permissioning and commonly contracts require that you distinguish them in constraints or duties.  We think it is relevant to have these different categories to allow differentiation on the use cases.  How could we model this?  Does it make more sense to introduce qualifiers on Party Types or to subclass the Internal Party and External Party types?  The external case could potentially be handled by using duties that apply to external parties performing particular roles (assuming we define those roles), but the internal ones do look more like distinct subclasses of internal party.

2.1.2 Party Roles

We query the definition of “Service Facilitator”.  The existing definition suggests that it refers to entities that are “assisting in the delivery of data services”; we feel that there are cases where it would be more appropriate to talk about them being an external organisation contracted by a Party to use the Party’s data access rights to perform a business function (which might encompass generating derived data for the Party, fitting the existing definition, but might involve other activities).

On “Administrator” you state this must be an external entity.  We may be missing the intent here; we were thinking this is the function that controls downstream access to the data assets and potentially has reporting / notification duties.  If so, we would see this as potentially either an external or an internal party.  Some duties might only apply in the case where it was an external party, but that could be accommodated by qualifying the duty by party type.

2.2.1 Resource Types
The use of “former” and “latter” is slightly confusing here; you identify three cases:

  *   the original data resource created by the Originator
  *   the resource "at rest" in an organisation before Rules are applied to control its use
  *   the contolled(typo) resource that is received by a Consumer

Is the intended interpretation that the first two are of type “Source” and the third “Asset”, or is the at rest resource something other than a Source (in which case, what is it?).  We note that there are licensing terms related to the storage of historical time series data that might require you to distinguish between the first two cases.


That’s all we have come up with to date.



Nigel

________________________________
Nigel Phelan | Corporate & Investment Bank | Market Data Services | J.P. Morgan


This message is confidential and subject to terms at: https://www.jpmorgan.com/emaildisclaimer including on confidential, privileged or legal entity information, malicious content and monitoring of electronic messages. If you are not the intended recipient, please delete this message and notify the sender immediately. Any unauthorized use is strictly prohibited.

Received on Wednesday, 9 December 2020 12:54:34 UTC