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>
Sent: Wednesday, November 25, 2020 3:07 PM
To: public-md-odrl-profile@w3.org <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://w3c.github.io/market-data-odrl-profile/md-odrl-profile.html#licensing-party> and Affiliated Party<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://w3c.github.io/market-data-odrl-profile/md-odrl-profile.html#licensee> and affiliates<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://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://w3c.github.io/market-data-odrl-profile/md-odrl-profile.html#professional-party>, Non-Professional Party<https://w3c.github.io/market-data-odrl-profile/md-odrl-profile.html#non-professional-party>, and Educational Party<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://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://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.