RE: Rights Automation Community Group - comments on draft Standard

Looks good from this side.  One clarification on this point (quoting myself):


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.



B> I do take your point. The original intention was to identify companies like Data BP who act as "licensing facilitators" employed by originators to manage the licensing of their data. I suspect that reporting and notification duties are in scope of this outsourcing - though Mark B could confirm this! But I do wonder if we would be straying too far from normal usage in applying this to an internal function. I don't know.

N> I think we misinterpreted the function being described, thinking it related to data access controls rather than IP licencing.  This might suggest that the description needs a little adjustment to clarify the intent.  Regarding the internal vs. external point, what I was trying to say is that IP licensing could be performed directly by an Originator, by a Provider or by an Administrator.  Do we get duplication in rules/duties in the ODRL if we need to deal with the case where any one of these could be performing the IP licensing function for a given Resource?  If so, could that be addressed by saying that whoever is doing the IP licensing is performing the Administrator role at that point (and using a few constraints on the rules to, for example, say that the Administrator doesn’t need to Notify the Originator when the Administrator and Originator are the same Entity)?  If we did feel that was a better way to model things, then it would be necessary to remove the stipulation that the Administrator is always an external entity.


Nigel

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

From: Benedict Whittam Smith [mailto:ben@deonticdata.com]
Sent: 07 December 2020 21:45
To: Phelan, Nigel (CIB Tech, GBR) <nigel.phelan@jpmorgan.com>; public-md-odrl-profile@w3.org
Subject: Re: Rights Automation Community Group - comments on draft Standard

 Hi Nigel and Michelle,

Many thanks for these comments. My thoughts inline below:

________________________________
From: Phelan, Nigel <nigel.phelan@jpmorgan.com<mailto:nigel.phelan@jpmorgan.com>>
Sent: Wednesday, November 25, 2020 3:07 PM
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



B> I've added Licensing Party<https://secureweb.jpmchase.net/readonly/https:/w3c.github.io/market-data-odrl-profile/md-odrl-profile.html#licensing-party> and Affiliated Party<https://secureweb.jpmchase.net/readonly/https:/w3c.github.io/market-data-odrl-profile/md-odrl-profile.html#affiliated-party> as sub-classes of Internal Party. I've also provided the corresponding properties to the Permission class: licensee<https://secureweb.jpmchase.net/readonly/https:/w3c.github.io/market-data-odrl-profile/md-odrl-profile.html#licensee> and affiliates<https://secureweb.jpmchase.net/readonly/https:/w3c.github.io/market-data-odrl-profile/md-odrl-profile.html#affiliates> so that we can type the parties involved.



B> I've also specified a users<https://secureweb.jpmchase.net/readonly/https:/w3c.github.io/market-data-odrl-profile/md-odrl-profile.html#users> constraint on the Permission class so we can effect the distinction in compliance tests.



 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



B> I've added Professional Party<https://secureweb.jpmchase.net/readonly/https:/w3c.github.io/market-data-odrl-profile/md-odrl-profile.html#professional-party>, Non-Professional Party<https://secureweb.jpmchase.net/readonly/https:/w3c.github.io/market-data-odrl-profile/md-odrl-profile.html#non-professional-party>, and Educational Party<https://secureweb.jpmchase.net/readonly/https:/w3c.github.io/market-data-odrl-profile/md-odrl-profile.html#educational-party> as sub-classes of External Party. We can use the users constraint as above.



B> I'd like to tackle website consumers within the scope of a distribution action - or at least when we discuss the wider issue of distribution.



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.



B> I think we can use the users<https://secureweb.jpmchase.net/readonly/https:/w3c.github.io/market-data-odrl-profile/md-odrl-profile.html#users> constraint on a rule, which expects a party type as its value.



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



B> I've improved the definition of Service Facilitator <https://secureweb.jpmchase.net/readonly/https:/w3c.github.io/market-data-odrl-profile/md-odrl-profile.html#service-facilitator> which I hope now meets your intent.



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.



B> I do take your point. The original intention was to identify companies like Data BP who act as "licensing facilitators" employed by originators to manage the licensing of their data. I suspect that reporting and notification duties are in scope of this outsourcing - though Mark B could confirm this! But I do wonder if we would be straying too far from normal usage in applying this to an internal function. I don't know.



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.



B> I've turned to first and last which I hope may be clearer, and I've tried to tighten the distinction between Source, Resource, and Asset. I'm describing a resource in all three cases, but only the first is a Source and the last, an Asset (i.e. a Resource controlled by a Rule).



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



B> Looking forward to more 🙂



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.

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.