Re: Market Data Profile for ODRL

Hi Josh,

Many thanks for these. My thoughts inline below. Tricky stuff!

________________________________
From: Cornejo, Joshua <Joshua.Cornejo@refinitiv.com>
Sent: Saturday, November 14, 2020 3:28 PM
To: public-md-odrl-profile@w3.org <public-md-odrl-profile@w3.org>
Subject: Market Data Profile for ODRL


Hello,



I've had some time to review the link<https://w3c.github.io/market-data-odrl-profile/md-odrl-profile.html>. Taking into consideration (my limited understanding of Market Data and) the ODRL standard, and how it provides generic rights management, here are my comments:



Party types:

To prevent an explosion of standard classes, I would rather summarise them all as property instances of the odrl:Party with a property md:role:



:P1   a                                   odrl:Party;

dcterms:identifier                  "CME"@xsd:string;

odrl:uid                            <http://www.permid.org/1-4295899615>; # identifies the party uniquely

# other properties

md:role                             md:internalParty,

md:externalParty,

md:originator,

md:provider,

md:consumer,

md:serviceFacilitator,

md:administrator.



Each of the roles then becomes an instance of a class md:Role (for example, this is how odrl:leftOperand works in the standard). The language allows for multiple values in a Party without duplication of classes (e.g., An external party that is originator and administrator), the ontology for the instances then can be defined as:



md:serviceFacilitator a                   md:Role ;

rdf:type                            skos:Concept ;

      rdfs:isDefinedBy                    md: ;

      rdfs:label                          "The role an external organisation contracted in assisting in the delivery of data services."@en ;

      skos:definition                     "TBD."@en ;

      skos:note                           "Example: TBD."@en ;

      skos:scopeNote                      "Non-Normative"@en ;

.

B> Lots going on here!


B> 1. Standard classes (and sub-classes) are good - or, at least it's easy to define compliance relationships for them.


B> 2. Standard classes are expressive. If we turn to individuals/instances too soon, we lose the ability to capture the fact that an affiliate (for example) is a type of internal user.


B> 3. I've tried to "type" parties that are stable (or change slowly) in relation to the licensee and use roles for things that change frequently. An internal user will remain an internal user, but a consumer can become a provider at any moment.


Resources:

2.2.1.1.3 / 4: Attribution and Disclaimer, I would consider them properties, rather than classes?


B> We'll likely define compliance mostly in terms of class membership so a class-based definition maybe more efficient that a Boolean property.


B> Really, I'm keeping my options open at the moment. Let's see what results we get once we start testing this assumption.



2.2.2.2. md:refines. I would think that checking compliance by refining the Resource could lead to confusion and complications (instead, ODRL refines via a constraint in 2 ways – more later):



R2          a                             md:Resource ;

md:refines                          :R1 ;

md:timelinessOfDelivery             md:delayed.



R3          a                             md:Resource ;

md:refines                          :R2 ;

md:timelinessOfDelivery             md:realTime.



odrl:AssetCollection uses odrl:refinement, and would look as follows:



R2          a                             md:Resource ; #md:Resource should be a subclass of odrl:AssetCollection or have the odrl:refinement property

md:refines                          :R1 ;

odrl:refinement                     :Ref1.



Ref1        a                             odrl:Constraint ;

odrl:leftOperand                    md:timelinessOfDelivery ;

odrl:operand                        odrl:eq ;

odrl:rightOperand                   md:delayed.



B> Actually, I think both come to the same thing. I'm just applying some syntactic sugar. See more under Constraints below.


Activities:

Considering the supply chain process (e.g. Supplier sends ODRL to Vendor, Vendor packages products and generates new ODRL, etc), the Activities appear to imply interaction? e.g. "We've had this contract going for two years, but I now have reasonable suspicion that you are misusing my assets?". I'll need to re-read the intentions of ODRL standard to digest this, and take into consideration you could have originator - provider - consumer chains (i.e. As an originator, can I suspect that your consumer is misusing my assets?, and how that flows to you as a provider?).


B> As Nigel points out, these are perhaps more easily thought of as events. The interaction side of things is handled in the duties: e.g. if you start using my data, you must notify me.


B> So why activities rather than events? Partly because these things occur across time - a reasonable suspicion has a start data and, hopefully, an end date. Also, if we describe them as activities, then we neatly click into the PROV-O ontology for provenance, with which we can further describe and manage them. In fact, I have explicitly sub-classed these activities from PROV-O's Activity.



Entities:

No comments.



Duties:

No comments.



Constraints:

I'm not sure that this follows the way the ODRL standard specifies them, I would suggest the examples are a bit more explicit.



C1          a                             odrl:Constraint ;

odrl:leftOperand              odrl:LeftOperand;

odrl:operand                  odrl:Operator ;

odrl:rightOperand             odrl:RightOperand.



Rule1       a                             odrl:Prohibition ;

odrl:target                   R1 ;

            odrl:refinement               C1 ;

odrl:action                   A1.



Example:

# the asset in question is defined

:A1         a                             odrl:Asset ;

#the asset references the collection AC1

odrl:partOf                   :AC1.



# option 1 - are we refining via a permission or prohibition?

:R1         a                             odrl:Permission ;

odrl:refinement               :C1 ;

odrl:target                   :A1.



# option 2 - are we refining via an asset collection?

:AC1        a                             odrl:AssetCollection ;

odrl:refinement               :C1.



# the constraint doesn’t change in either option

:C1         a                             odrl:Constraint

odrl:leftOperand              md:methodOfUpdate ;

            odrl:operator                 odrl:eq;

            odrl:rightOperand             :Ro1.



# the right operand

:Ro1        a                             md:Snapshot ; # md:Snapshot a odrl:RightOperand

odrl:count                    3 ;

odrl:timeInterval [

a                       time:ProperInterval ;

                  time:hasXSDDuration     "P1D"^^xsd:duration

                ].



B> Hands up! I take your point. Put at its gentlest, I'm applying some syntactic sugar. Where the right operand is a test of class membership, we can infer that the operator is odrl:isA; when it's a literal we can infer odr:eq; and when it's a set, we can infer odrl:isAnyOf.


B> If we can infer the operator, then we can write the constraint as if it were a "simple property". We can drop all the complex syntax (and so simplify the compliance rules).


B> Put a little more firmly, I don't really want to use ODRL's 'rule language' - I'd rather leave that up to the implementors. There are plenty of rules that ODRL can't express - two hops along. a graph? So, let's take the hit early - wrap everything up as a test of class membership, and let the implementors decide how they're going to test for that.


B> Again, this is something I'm testing. Let's see if it flies.


Time:

No comments.





Regards,



____________________________________________

Joshua Cornejo

Rights Management @ [signature_1785956687]



Phone: +44 2075 426166

joshua,cornejo@refinitiv.com<mailto:elisabeth.modin@refinitiv.com>



[signature_924450296]