RE: Rights Automation Community Group - comments on draft Standard

Thanks, Nigel, our team reviewed that section as well. I thought it would just be a cursory review but we had lots of thoughts and comments and only made it through the Parties section. We'll continue on in coming weeks.

Here are our notes on the Parties section of the Supply Chain Metamodel:

Internal/External

Since an Internal Party is defined as "A Party that belongs to the Assignee and its affiliated or enumerated organisations as specified by the governing license," does ODRL prescribe how to specify specific affiliates related to a license?


Parties

In ODRL, a Party can be an entity or a person. As such, the Party Roles example has both the vendor and the bank labelled as Providers. The vendor delivers data to the bank (external distribution), the bank delivers data to its end users (internal distribution).

Is it sufficient to consider the bank and its individual users simply as Consumers? Does their need to be some distinction made between delivering data to entities and to persons?


Service Facilitator

This definition limits a Service Facilitator to a party that "assists in the delivery of data services." What if a third party is involved in the calculation/creation of a new data product, is this the activity of a Service Facilitator or something else?

Put another way, the Originator is defined as the party that generates/owns a resource. What if a different party generates, but does not own, the resource. Are they a Service Facilitator?


Originator vs. Administrator

An Originator is the "Assigner of rights and obligations" for Resources that they generate/own. But, an Administrator "assists in the assignment of rights," so there's some potential overlap between the two. Would it make sense to put the "assignment of rights" action only in the Administrator role? That way there would be no confusion, and a party that owns and manages rights for a particular product would be both the Originator and the Administrator of that product.


Third-party Payors

Do we need to include a definition of a party that pays for data use on behalf of someone else?


Resources vs. Assets

I personally find it hard to express the difference between a Resource (some commodity (e.g. API calls, bandwidth, data) access to which (or to some part of which) may be controlled by a Rule) and an Asset (a Resource, a collection of Resources, or the part of a Resource controlled by a Rule).

Perhaps a diagram or example of how the two relate and differ would be useful in the profile?


Consumer

Scope Note suggestion: "Designates the role a vendor or market data function within an organisation plays in receiving data from its suppliers." Should we change "suppliers" to "Providers"?


Best,
Mark



From: Phelan, Nigel <nigel.phelan@jpmorgan.com>
Sent: November 25, 2020 10:08 AM
To: 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.