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 ;

..



Resources:

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



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.



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



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

                ].



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]