Re: Rights Automation Community Group - comments on draft Standard

Hi Nigel, Michelle,

Many thanks. Again, comments inline below:

________________________________
From: Phelan, Nigel <nigel.phelan@jpmorgan.com>
Sent: Friday, December 4, 2020 3:39 PM
To: public-md-odrl-profile@w3.org <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”.


B> OK - let's discus tomorrow.



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?


B> There is a second intent here. As I mentioned to Josh, I'm looking to link into the PROV ontology which provides us with a readymade way of tracking these activities. Hence sub-classing our activities from PROV's Activity.


B> I take your point about events - it's how I initially modelled these. But the temptation to link into the PROV ontology was too much.


B> But also, many of the things we're talking about have a start date (start using the data) and an end date (stop using the data). This is what a PROV Activity models. We then get the starting events and ending events for free from PROV.



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


B> Good point. Done - see usage<https://w3c.github.io/market-data-odrl-profile/md-odrl-profile.html#usage>.



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?


B> But maintaining controls - or managing a restricted user group - is an activity. And that's what the licensee is asking for. Maybe we could improve the naming?



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?


B> Satisfying a reasonable suspicion constraint can trigger an immediate audit in an audit duty. For now, I've kept license breaches (and terminations) out of scope of the standard.


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”?



B > Done - see Restricted User Group<https://w3c.github.io/market-data-odrl-profile/md-odrl-profile.html#restricted-user-group>. I've subclassed the stricter closed user group from this as I have a faint memory that it appears in DBAG distribution licenses. But if not, we can remove it.


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.


B > They will be used as constraints on Derive actions (when we come to them) as values of the derivation types<https://w3c.github.io/market-data-odrl-profile/md-odrl-profile.html#derivation-types> constraint.


B > I've seen "un-constrained" derivations allowed for internal use only. These derivations have their own permissions - usually less proscriptive than those controlling the original data.



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.