odrl:inheritFrom too generic to work for supply chains, add odrl:import and odrl:reference

[joshcornejo]

In the following scenario:

• Assigner ex:A has engaged with Assignee ex:B and ex:Agreement has been signed, as an example this agreement has 100 rules for 10 assets.
• ex:B wants to create new policies, but using odrl:inheritFrom means that each policy will have 100 rules and 10 assets to start plus those rules added through the new ex:Offer.

I propose the introduction of odrl:import to access ex:Agreement with odrl:reference as an explicit mechanism to selectively add rules.

ex:R1            a odrl:Permission;
         odrl:duty ex:R5.

ex:Agreement     a odrl:Agreement;
   odrl:permission ex:R1, ex:R2;
  odrl:prohibition ex:R3, ex:R4
   odrl:obligation ex:R5, ex:R6.

ex:Policy        a odrl:Offer;
       odrl:import ex:Agreement;
    odrl:reference ex:R1, ex:R4;     # <-- these are the only rules I want from the agreement
   odrl:permission ex:R7.            # <-- this is locally defined 

My final when theodrl:Offer becomes an odrl:Agreement, the responsibilities of all relationships are fulfilled:

ex:NewAgreement  a odrl:Agreement;
   odrl:permission ex:R1, ex:R7;
  odrl:prohibition ex:R4;
   odrl:obligation ex:R5.          

[riannella]

I would not generally inherit from an Agreement.
I would model the needs based on multiple Sets then use these to determine the final agreements needed.

[joshcornejo]

Building a set is useful when I am working on my internal policies, but it doesn't have a mechanism to link the rules to the source (agreement ... set -> offer).

Having to scan agreements from my suppliers to build my policies and create sets to then use as a baseline for my internal offers seems like an unnecessary step and effort in the chain.

A more practical approach is to have a mechanism that references the agreements and cherry-picks the rules to be used. These references to supplier agreements could expedite compliance as they could be carried across (opaque if necessary) further down.

[vroddon]

I would say that the use of RDF naturally solves the problem. Once a party, a rule, a policy or anything identifiable is identified, then it can be referenced again and again without further ambiguity.
The problem of verbosity is partially solved with Collections, but it is not general enough (e.g. there is no "PolicyCollection"). I believe the use of RDF containers should have been promoted (Bag,Seq,Alt).

[joshcornejo]

Although RDF might have the right generic constructs, my suggestion is to replicate inheritFrom, and that there is an identifiable property for the import - this will avoid ambiguity, and for non-ontologists, it will simplify any analysis. I've tried to have workarounds and they all turn too complicated for the user to understand what is going on.

Having generic RDF constructs also makes it now a multi-step, unnecessarily decorated statement ("from this policy, refine this rule (or rules)"), this might be useful(?) for machines, but if I have a thousand rules in various policies and it turns into a SPARQL query that now requires an "execution" (give me the results) and a "verification" (are the results what I need), even before I validate (does my policy make sense).

And If I am mixing policies from different suppliers to build my own, it can become impossible.

Sounds good as an exercise, if you have to deal with this daily, it will drive you mad.

[vroddon]

Suggested action: open a "feature request" document towards adding desired features in the next version of ODRL. Add this item to the next ODRL meeting agenda.

[vroddon]

Labeld as "New Feature" and closed (to be re-opened when new elements are to be discussed)